AI-first process design: Start with the desired outcome, test feasibility early

Redesigning a process around the possibilities of AI calls for a different approach from traditional process projects: starting with a broader outline, becoming more concrete along the way and testing feasibility much earlier than usual. Here is what has proven effective in our project work across core and support processes.

Why a greenfield approach to AI is both particularly important and challenging

The starting point is a simple question: What would this process look like if AI managed it and people intervened only where expert judgment was needed? The answer should be built around the desired future state, not the current one. That may sound familiar, but with AI it is harder than in previous process projects for three reasons.

First, people often lack a clear picture of what AI can do today and what it might be able to do in a year. Even those who work with it daily cannot answer every question, because its capabilities are evolving faster than experience with them.

Second, the current process holds people’s thinking back. Roles, approvals and documents are so familiar that they reappear in the future-state design even when they no longer serve a purpose. A first sketch of an AI-first process usually emerges quickly. It takes considerably longer for a team to truly internalize it.

Third, there can be a wide gap between ambition and reality: How boldly should you think when parts of the basic infrastructure are not yet running reliably? For us, ambitious but realistic means that the vision can be bold, but the first implementation step must work within the existing systems landscape.

Step 1: Map the current process at a high level only

At the outset, a SIPOC overview is usually sufficient to capture the current process: suppliers, inputs, process steps, outputs and customers, all on one page. This is much lighter than full process modeling—and that is precisely the point. Modeling every step in detail consumes significant time on activities that may no longer exist in the target process, while also reinforcing them in people’s minds. In our experience, a high-level overview pays off during greenfield discussions: the team talks about what the process should achieve, rather than what it does today.

The details are still needed later, but only for the process steps that remain in the target design. Wherever an agent will operate autonomously, the contextual knowledge must be complete: What exceptions are there? Which rules apply? Where is the data? Thoroughness is therefore not eliminated, but shifted - from documenting the current state to validating the target process.

Step 2: Bring the future to life

The target process is designed around the outcome: What should it ultimately deliver for customers or internal stakeholders, and what path would you choose if AI were the default? Handoffs, follow-up questions and review loops that currently sit between roles and departments are all open to reconsideration. People enter the process where expert judgment, accountability or personal interaction is needed. The result is rarely a fully automated process, but almost always one with significantly fewer steps and participants than today.

To help a team not only map the target process but also understand it, we have found the following practices effective:

• Provide inspiration and ideas before developing the team’s own example. Seeing what AI can already do in comparable processes opens up possibilities faster than any slide explaining the methodology.
• Use prototypes instead of presentations. A clickable mock-up that allows a professional to walk through their future working day sparks discussions that slides cannot.
• Establish a clear division of work with the AI team. Having subject-matter experts and developers build together in one room sounds appealing, but in our experience it has proved less productive. What has worked well instead is for the AI team to gain a precise understanding of how things work today and how they could work tomorrow, then build independently, seek expert input as needed and return with a prototype for a demo session. The exchange between business and technical experts itself works well, both in workshops and in one-to-one discussions.
• Have the team present the target process itself. Explaining the future-state process to colleagues requires the team to take ownership of it. It is a good test of whether they have truly internalized it.

Step 3: Think freely first, then test early

During the ideation phase, the rule is to impose as few constraints as possible. Concerns about data protection, employee co-determination or system limitations are collected and visibly set aside, but not discussed. Validating ideas at this stage can easily lead to a version of the current process that is only marginally better.

Once an idea becomes tangible—for example, as clickable process steps on an initial mock-up interface—the rule reverses. Now the hard questions need to be addressed: What personal data does the agent process, and on what legal basis? What is feasible within or close to the existing systems landscape, and what requires an interface that does not yet exist? Which steps are subject to employee co-determination? Waiting until the entire future-state process has been designed in detail risks discovering at the end that it is incompatible with applicable policies—and having to start over. That is why we have found it effective to test and refine each prototype rather than validate only once at the end.

A simple rule of thumb helps with validation: a solution is ruled out only if it violates applicable law or the EU AI Act. Most other issues are design challenges that can be resolved if the right people are involved early.

Step 4: Plan the path to operation

The sprint ends not just with a concept, but with an implementation plan: Which roles will change? Which systems and data need to be made available? What agreements need to be reached with the works council and data protection representatives? And what does the business case look like? We describe how such a business case can be developed in Ambition, process selection and the business case.