Orsero | AI Envisioning Workshop

I had about a week to prepare, so I started by taking the room off the blank page. A survey went out to participants to collect the frictions they meet daily, which let me open the workshop on their words rather than on our slides. It also let me compose the tables by affinity of problem rather than by org chart. Reading the answers, I saw that a large share of contributions belonged to areas covered by other teams, so I redistributed them and opened each table by showing where its themes had landed. Telling people their input was already at work somewhere else in the room bought attention I would otherwise have had to earn during the day.

The day ran on four tables, one per business area, each with a service designer facilitating and a domain expert from the Data & AI team as technical support. Every table followed the same sequence: silent individual reflection, sharing at the table, then a vote to converge on one problem area. From there we mapped the process as it works today, marked the pain points on the map, and only at that point opened ideation. A plenary closed the round.

Starting an activity with individual reflection is a habit of mine, and in this room it mattered more than usual. The tables mixed analysts and process coordinators with the chief operating officer, the group CFO and the CEO. When seniority in a room is that uneven, silent writing followed by structured sharing is what gives quieter voices a way in. Writing alone before speaking protects the range of perspectives you invited people for.

Two choices did most of the work. The first was mapping the as‑is process before opening ideation: you cannot decide where AI belongs until the process it has to enter is visible on the table. The second was letting the AI expert speak last in each round, so that technical feasibility rationalised the ideas after they had formed instead of anchoring them from the start. Everything was done on paper, which kept senior stakeholders in the conversation rather than behind a laptop.

This was also the first time three teams inside Alkemy, my company, worked together on the same engagement: Business development, Data & AI, and Service Design. Sitting between them was part of my responsibility. The machine learning and data engineering courses I studied on my own time paid off here, not because I write models, but because I can follow the reasoning of the people who do. That shared language let me translate technical constraints into business terms for the client, and it earned me enough credibility with the AI team to push back on scope when a proposal drifted away from what the room had actually said.

After the workshop I rationalised the output against the data value chain, the framework the company uses for AI programmes. It runs in five steps: data strategy, data foundation, data analytics, data science and AI, and data activation, with culture and training cutting across all of them. Data without a strategy is noise, and a model that never reaches activation stays academic, so value only appears when an organisation walks the whole path instead of jumping to the AI step. There is nothing original in the framework itself; it is established practice. The difficult part is helping a client see why foundation work is worth funding when it produces no visible feature.

Each table produced one concept. Administration worked on reconciliation and order control, HR on payroll data validation, sales on demand forecasting, and operations on dynamic staff planning in the warehouses. Four different functions, three shared frictions underneath: fragmented systems, unstructured data, manual work.

In the report I documented every concept with the same four‑part structure, so that four ideas coming from four different rooms could be read and compared side by side:

• As‑is reporting: the macro pain point, its root causes, and its impact on daily work and on the business.
• Solutioning: the problem reframed, and the concept proposed against it.
• Data pipeline to‑be: the data the concept needs, from source to serving.
• Pilot proposal: scope, stakeholders to involve, expected deliverables.

That structure is what gave the client something to decide with. For every initiative it showed what building it would take, who had to be involved, and where it stood against the others on business impact and implementation complexity.

Then I placed the four concepts on the data value chain. All four sat on the same starting point: data that is clean, structured and shared across systems. That layer did not exist yet inside Orsero, and none of the four ideas could work without it. So the report added a fifth item next to the four concepts: a data foundation initiative.

That is the moment the picture changed for the client. They had come in with four things they wanted to build, and they left knowing that none of them would stand without the enabling layer underneath. The reframing did more than add a fifth line to the list. It moved the discussion from which use case to pick to where the group should point its resources first.