Part 2 of 2
A conversation with Jan Laš, CIO at HOPI, about what deploying a data agent looks like from the client’s side; the users who drifted away, the security work nobody planned for, and why he thinks about the future in terms of direction rather than destination.
Jan Laš joined HOPI as CIO with a pragmatic view of technology: it should solve real problems for real people, and the measure of success is whether those people actually use it. When we started working together on a data agent for HOPI’s logistics department, that pragmatism shaped almost every decision we made, sometimes in the direction I expected, and sometimes not.
I sat down with Jan to talk through what the project looked like from his side. Jan’s perspective is valuable precisely because it comes from the client’s seat rather than the consultant’s, and he tends to be more candid about the hard parts than most case studies allow.
The excitement problem
One of the first things I asked Jan about was user adoption, specifically how to pick the right people to bring in first. His answer was more candid than I was expecting.
“At the start, everyone has very high expectations, there’s this AI over-excitement. The moment you tell someone in the company that you’re going to do something with AI, they want in immediately. They think it’s going to be their big moment, something to be proud of. So onboarding people at the beginning is easy. The problem is that once the first obstacles appear, interest fades just as fast. The real challenge is choosing the right people from the start, the ones who will still be engaged when it gets difficult.”
– Jan Laš –
This matches exactly what we’ve seen across projects. The initial wave of enthusiasm is a poor signal for who will actually benefit from the agent long-term. Jan described how HOPI approached the selection problem: instead of targeting the people who were most excited about AI, they looked for the people who had the most to gain from faster access to data: those who lacked the technical skills for self-service reporting, or whose jobs made it impractical to run dashboards themselves.
“Our target group were the people who didn’t have the technical skills for self-service reporting, or who simply didn’t have the time; people whose jobs, often in the field or on the floor, didn’t allow them to sit down and work through a dashboard. We were trying to extend the pool of users who could get business insight from our data, not just deepen it for those who were already getting it.”
– Jan Laš –
He also described a second use case that I think is underappreciated: what he called the “pocket advisor” scenario. The image he painted was sitting in a board meeting, someone presents a figure that looks off, and instead of either accepting it or causing a disruption by asking someone to check, you quietly open Teams, type a quick question to the agent, and have a verified answer in seconds.
“Imagine you’re in a board meeting and someone puts up a number that doesn’t look right. Are they mistaken, or are they trying to mislead you? Instead of running a report later or quietly asking your CFO, you take out your phone, open Teams, type a quick question to the agent, and have a verified answer before the conversation moves on. That kind of instant access is something people hadn’t had before, and for the right users it was immediately compelling.”
– Jan Laš –
Picking a path in a landscape that changes every few weeks
One of the more uncomfortable truths about this kind of project is that the technology decisions you make at the start may look very different three months later. We changed implementation approaches during the HOPI project; something I raised with Jan when we talked about navigating the options in the Microsoft stack.
“My advice would be to seriously consider at least two or three approaches before committing. I came in with a strong opinion about the direction, then we went a different way, then you convinced me to change again, and each time we learned something we hadn’t anticipated. The pace of change in this space is such that what looks like the right answer today can look very different in three weeks. Agility isn’t optional.”
– Jan Laš –
That agility requirement is something I’ve come to believe is genuinely structural, not just a feature of this particular moment in time. The tools are evolving faster than most organizations’ procurement and architectural decision cycles. Jan’s framing captures it well: you pick a direction, you commit to it with enough conviction to actually build something, but you hold the specific technology choices loosely enough to change them when a better option appears.
“We decided to go in a certain direction. I think it’s a good direction. So let’s say we go West, I don’t know if we end up from Prague in Munich or in Paris, but definitely it’s a good direction.”
– Jan Laš –
On security: The work nobody puts in the project plan
Security was the area where the gap between the initial plan and the eventual reality was widest. When you start with a small, technically literate pilot group, the security requirements feel manageable. When you start expanding to warehouse managers, field teams, and people who have never had direct access to the data warehouse before, the picture changes considerably.
“We ended up spending a significant amount of time on security, more than we originally planned for, which made the project more expensive and extended the timeline. But once you start opening access beyond the small group who were already running their own reports, you have to be genuinely careful about what data is being shared and with whom. The moment we extended to warehouse managers, a whole new set of questions appeared: what could be exposed, what needed to be restricted, what we hadn’t thought to check.”
– Jan Laš –
There’s a story from that period that I think illustrates the point better than any diagram could. We had rolled the agent out to a small group of users and were monitoring the early responses carefully. One user came back and told us the tool was broken, it wasn’t returning any answers. When we looked at the error logs, what we found was that the agent was working exactly as intended: it was correctly refusing to return data the user didn’t have access to. The “broken tool” was the security model doing its job.
Small teams, longer than expected, and a few dead ends
When we talked about team size and timeline, the numbers from both sides of the project were more modest than people might expect given how the technology is sometimes positioned.
On our delivery side, the project involved three people, none of them full-time. On HOPI’s side, Jan described a similarly lean setup.
“On our side, two people from IT (neither of them full-time) and one business leader whose job was to own the scope and the metadata. That last role was critical: someone had to take responsibility for translating the business language, because the same thing gets called by three different names depending on who you ask. Sometimes by location, sometimes by the main customer stored there, sometimes something else entirely.”
– Jan Laš –
On timeline, the project ran to five months, though Jan was candid about why it took that long.
“It could have been shorter. We had breaks, we changed direction more than once, and there was no hard deadline pushing us. Under pressure, I think it could have been finished in under three months. But we wanted to properly evaluate the different technology options rather than just go with the first thing that worked. Sometimes that meant taking two steps back before moving forward again, and looking back, that was the right call.”
– Jan Laš –
Based on what we’ve learned since, a well-scoped first deployment now typically runs two to three months on our side. The HOPI project was longer partly because it was earlier in our own learning curve, and partly because the technology landscape shifted under us during the build.
Scaling up, checking in monthly, and not getting attached to the path
When I asked Jan about the future outlook for the project, his answer was characteristically grounded.
“Right now the focus is scaling up — more users, more departments. We started with warehousing and we’ll keep expanding. At the same time, we’re keeping an eye on what else is out there, because the options are changing fast. I think you need to check in roughly monthly: is this still the right technology, or is something better available? And you have to be honest with yourself about when to stay the course and when to change direction.”
– Jan Laš –
“If you ask me for a future outlook in this space, whatever I say could sound quite silly three weeks from now.”
– Jan Laš –
That humility about prediction from someone who is actively running the project, not theorizing about it is worth taking seriously. The organizations that are doing this well are the ones that have committed to a direction while staying genuinely open about the route. The ones that are struggling tend to be either too rigid (locked into a tool choice or architecture that no longer fits) or too tentative (running endless proofs of concept without ever committing to something production-worthy).
Jan’s framing: go West, accept that you might end up in Munich or Paris, is a better mental model for this kind of project than any roadmap I’ve seen.
My mission is to change your life in how you make everyday decisions based on proper data. I do this by helping corporate data leaders create and adopt data strategies built on Microsoft platforms using artificial intelligence. Over my 15+ year career, I have gained experience which I use to mentor clients and pass on to community as a speaker and data leader in the industry.
Jaroslav Reken
Co-Founder & Data Strategist
The post Deploying AI in logistics (the unfiltered version) appeared first on Joyful Craftsmen.