Industry practice
Start with the work, not the tool
When an organization gets interested in AI, the first instinct is usually to start with the tool. Someone sees a demo. A vendor arrives with a promising workflow. A team is asked, in so many words, where this could be used. In my experience leading large technology programs, that is the wrong first question. The right one is older and plainer: what is the work, how is it done today, and where does it actually break down?
I have learned to be suspicious of any program that cannot describe the current process without mentioning a product. If you cannot explain who does the work, what they look at, where they hand it off, and what “done well” looks like, you are not ready to insert a new capability. You are ready to draw a map.
Why the map comes first
Tools arrive with a story about how work should happen. Real work is less tidy. It is full of exceptions, informal shortcuts, and judgment calls that never made it into a diagram. If you start with the tool, you will automate the story, not the work. You may get a clean demo on the happy path and a quietly frustrated team everywhere else.
When I have led programs that lasted, we spent time sitting with the process before we talked seriously about models. We asked people to walk us through a normal week, then through a bad week. We looked at the handoffs between teams, because that is where work usually stalls. We paid attention to the cases people were proud of, and the cases they hoped no one would ask about. That mapping is not delay. It is how you find the few places where AI might help, and the many places where it would only add a step.
What to map
You do not need a formal methodology. You need a shared picture that a practitioner would recognize as true. At a minimum I want to know: What starts the work, and what finishes it? Who touches it in between, and what does each person decide? Where are the delays, the rework, and the exceptions? Which steps are repetitive, and which steps require judgment? If this work goes wrong, who notices, and how late?
The last question is the one teams skip. It is also the one that tells you whether an AI-supported step is safe to try. If no one will notice a bad output until a customer, a partner, or a downstream team feels it, you need a review step before you need a model. Write the map down in language the people who do the work would use. If they have to translate it, it is still a story.
Look for the work, not the novelty
The useful places to apply AI are often unglamorous. A repetitive review that already has a notion of “good.” A triage step that consumes time but does not require a rare expert for every case. A first draft that a person will revise. In each of these, the work already exists. The question is whether a model can take a slice of it without hiding the judgment that still needs a human.
The less useful places are often the most exciting in a demo: greenfield workflows that no one owns, or problems that are still being defined. A tool cannot compensate for a process that does not exist yet. In those cases, the work is to clarify the process. The tool can wait.
Design for exceptions
Every process I have spent time with has a happy path and a set of exceptions that take most of the effort. If you only map the happy path, you will build a system that works in the room and fails in the week. The map should say, clearly, which exceptions the system will handle, which ones a person will take, and what the handoff looks like.
This is also where cross-team adoption is won or lost. Exceptions often live at the boundary between teams. If the system cannot move those cases cleanly, each team will go back to its own side channel, and the platform will look unused for reasons that will be described, incorrectly, as resistance to change. In my experience, people are rarely resisting change in the abstract. They are protecting a way of handling the hard cases that the new path has not yet earned the right to replace.
Then choose the tool
Once the work is clear, choosing a tool becomes a much smaller decision. You can see whether you should build, buy, or wait. You can see whether a pilot is even the right next step. You can write a readiness check that is about the work, not about enthusiasm.
I have come to think of this as a rule: if the map is vague, the program is vague. Start with the work. Name the process as it really is, including the parts that are awkward to admit. Then, and only then, decide where a tool belongs in it.