Artificial Intelligence / Your Project
Which processes are truly worth automating?
Identify the right use cases for artificial intelligence in your company—and rule out the wrong ones before they end up costing you.You know you have to do something. Every department has an idea, a vendor has a demo, and no one has a written, quantified use case with its data and limitations. We lead the workshop that turns a desire into three candidates, and three candidates into an initial project —the one that paves the way for the next ones, not the one that makes the biggest impression.
Three Ways to Choose the Wrong First Use Case
They occur in almost every startup. None of them is a mistake; all of them set a project back.
Choose the most visible case
The agent on the public site, the assistant that management will see in the demo. They make a strong impression, yet they depend on everything that isn’t yet in place: a well-maintained knowledge base, reviewed permissions, and an owner. The first visible instance often fails for invisible reasons.
The first case is chosen for what it leads to.
Start with the technology you want to try
A model, a tool, a platform—and then we look for the problem that goes with it. The result is a working prototype that no one was expecting, and that fades away when its sponsor changes jobs.
First, the problem; then, the tool.
Trust the procedure rather than the person carrying it out
The procedure is said to have five steps; the person actually takes nine, including three to get around a system, and checks two things that no one has written down. Automating the procedure means automating a fiction. You see reality by watching someone do it, not by reading about it.
We observe the actual process; we do not automate the description of it.
Five Questions That Define a Process
Asked of each candidate, in this order. A process that answers “no” to any of the first three is not a primary use case —though it may become one later.
Is this a common procedure?
How many times a day, a week, or a month does this process run, and how many people spend time on it? A process that runs infrequently—even if it’s tedious—isn’t worth automating.
A good sign: dozens of instances per week, spread across several people. A bad sign: “It happens from time to time,” or when it affects only one person.Is the process boring?
Would the people who do this work be relieved to be relieved of it, or is this the part of their job they want to keep? Automating what people enjoy doing fails because of adoption, not because of the technology.
Good sign: copy, search, sort, cross-reference, follow up. Bad sign: advising, negotiating, deciding, creating, reassuring.Is the result verifiable?
For each task, do we know whether the result is correct? Invoice processing is verified against the purchase order; a meeting summary is verified by someone who was there. A process where we cannot tell if it was done correctly will never be corrected.
A good sign: a reference system, an existing oversight mechanism, or someone who knows. A bad sign: “We’ll see,” or a result that isn’t evaluated until months later.Does this data exist, and is it accessible?
Are the documents machine-readable, are the rights clearly defined, and is the data model clean? A use case for which no data exists is a data project before it is an artificial intelligence project—and sometimes that’s where you have to start.
A good sign: in Microsoft 365, in theERP, in Dynamics 365, with a homeowner. A bad sign: in two people’s minds, in misaligned scans, in ten versions.Do we know what will remain human?
Before we begin, can we determine what decision a person will make and when the system will hand over control? If no one can say, then the situation is too unclear or too risky.
Good signs: “The accountant still needs to approve it,” “The staff member sends it,” “The project manager checks the source.” A bad sign: “The system will decide,” or the hope of eliminating a position rather than a task.What does this case mean for future cases?
The first use case covers the costs of organization, rights review, and training. The candidate who leaves behind a well-organized body of work, reviewed rights, and a trained team makes the second and third use cases less expensive. This is the criterion that determines the winner between two candidates who have passed the five questions.
A good sign: a case that requires you to put away what three other cases will use.What We Don't Recommend Automating First
Three categories of processes that keep appearing on the lists of candidates, and that we are ruling out from the initial draft— as we write it, for good reason.
A decision that binds the company without oversight
Approving an insurance claim, granting a loan, dealing with an angry customer, firing an employee. A manager can prepare for these situations; they shouldn’t have to make these decisions alone, and an entry-level position isn’t the place to learn where to draw the line.
The process that changes every week
An organization undergoing restructuring, a procedure we’re in the process of rewriting, a system we’re going to replace in six months. Automating a moving target means rebuilding it every month.
The process for which data does not yet exist
No dedicated repository, no readable documents, no owner. The first project to undertake is a data project—and it has value in its own right, regardless of what happens with artificial intelligence later on.
A well-reasoned list of processes that should not be automated
It prevents a department from launching, six months later, the prototype that the workshop had rejected. And it specifies what needs to be changed—a reference framework, a standardized procedure, an owner—for the project to become a candidate again.
The Identification Workshop: How We Do It
Four sessions over a period of two to three weeks, with business and IT leaders in the same room. The deliverable is an initial written use case, along with a list of those that will follow.
Fundraising from those who...
One hour per department, with the people who actually carry out the processes—not just their managers. We make a list of what takes time, what’s annoying, and what involves duplicating work. We observe the work in action whenever possible.
Qualification, based on the five questions
Each candidate answers the five questions with the relevant people. Those who fail the first three are eliminated, with the reason provided in writing. The others receive a grade based on quality, effort, and data.
Architecture and Cost: An Overview
For the three or four remaining candidates: where the data is located, what needs to remain on your premises, the architecture we would be considering, and a rough estimate of the cost and timeline. Enough to make a choice, but not enough to place an order.
The Choice and the Roadmap
The first case, chosen for what it leads up to; the second and third, which will reuse its base; and the management’s decision, in writing. What follows is a project, with its own web assessment.
The workshop is a service with a written scope and a deliverable. It takes two to three weeks, involving four to six half-days with your teams, depending on the number of departments involved. What doesn’t cost anything is meeting with the engineers who would lead it—and who will then lead the project, because they’re the same people.
Where the first good cases are most often found
Seven problem categories, and within each one, the case that most often meets all five criteria. This isn’t a shopping list—it’s where we look first.
Find documents and answer frequently asked questions
Common, annoying, verifiable by the source. The most common scenario—and one that forces you to clean up.
Automate processesInvoices, emails, forms
Verifiable against theERP, measurable in minutes saved. The case where the return on investment is calculated the fastest.
Improving Customer ServiceAgent Help and Call Summary
Assists without taking over; is verified by the agent; prepares the way for the virtual agent who will take over next.
Leveraging KnowledgeThe assistant working on a confidential corpus
When knowledge is the asset: it is common, verifiable at the source, and it dictates the architecture.
Supporting Technical TeamsIT Support and Code
Repeated, traceable requests; source code whose confidentiality determines its location.
Observing the Physical WorldEnd-of-line inspection, equipment monitoring
Common and verifiable, but rarely the first instance: it requires images, sensors, and a vision partner.
Related pages
What comes after the workshop, and two articles that address the same issue from a different perspective.
From Planning to Day-to-Day Operations
What happens once a case is selected: assessment, prototype, production, and the deliverables you keep.
View the page ArchitecturesWhat kind of architecture is right for your project?
Seven questions, one tentative answer—including “I don’t know yet,” which refers back to this point.
View the page Use CasesThe entire library, organized by topic
Each case is written according to the same twelve-point template, while retaining what is human.
View the page ArticleIdentify processes that are suitable for automation
The reader-oriented method, along with the criteria we apply in the workshop.
Read the article ArticleWhy So Many Artificial Intelligence Projects Fail
Recurring issues, and what management can do to prevent them.
Read the article ArticleTraining Managers in the Age of Agents
What managers need to learn when part of the work is taken over by a digital assistant.
Read the articleLet's talk about your processes
Tell us what takes time, and for whom
Three frustrating processes, the departments involved, and what you’ve already tried. We’ll come back to what we’d prioritize, what we’d rule out, and the scope of an identification workshop at your office.
What we offer is the opportunity to meet the engineers who will do the work. The identification workshop is a service with a written scope and a deliverable. The discussion that precedes it, however, is free of charge.
Renens, Sion, Châtel-Saint-Denis
Microsoft Solutions Partner and Dell Technologies Gold Partner. The same engineers work in the workshop and on day-to-day operations.
Renens VD +41 21 806 37 15
Sion VS +41 27 552 00 22
Châtel-Saint-Denis FR +41 26 322 59 05