AI roadmap: a list of use cases is not a plan.

Start with the workflow as it runs today: who is involved, where the handoffs are, which data gets used, which errors are known. At SUMAX our time tracking was the basis, because it shows where the work lands day to day. Before that, process knowledge sat in spreadsheets and people's heads. As long as it's scattered like that, you can't judge any project honestly. To set the order, I ask three questions about every important workflow. Does it depend on a single person? Has nobody questioned it in years? Does it cost the most money? Where more than one answer is yes, that's where the first project goes.

Before tools for single tasks, you need a base that everyone uses: users, permissions and access. Who may work with which data is then settled once, not again in every tool. Security goes in from day one, because it's hard to bolt on later. A layer of our own sits between our applications and the AI models. It lets us switch models without touching a tool, and it books every call with its cost. A foundation is hard to show off, so it tends to slide down the roadmap. Then every new tool brings its own contracts, permissions and data flows, and the AI transformation turns into a collection of islands.

Value, data, checkability and the effort to run it go into the same assessment, and checkability weighs the most, because a result may only move on once it has been checked. If nobody on the team can judge the result reliably, the reviewer turns into a rubber stamp. Good first use cases are repetitive routine tasks with the data already in place. AI takes away grunt work, not people, and if you calculate AI ROI as headcount saved, you'll pick the wrong cases. Before the start, decide which results are acceptable and which cases go back to a person.

The pilot runs on real tasks with the people who will use the tool later. Feedback from the business team goes straight into the next version. That's how our own AI tools at SUMAX get built, and most of our people use them every month. A pilot without a decision date keeps running because nobody ends it, and the pilot graveyard grows. So every project has a fixed date on which it is expanded, reworked or ended. Only as many projects run at once as the team can carry, even when the tech could handle more.

Whatever gets expanded needs support, maintenance, cost tracking and error handling settled before launch. Without support an application goes stale with the next model change, and the team drifts back to the old way of working. You can only weigh cost against value if every call is booked. That's why our layer books each call with its cost to the application that made it. When a new model version comes out, the business review runs again. A project that gets ended is recorded with its reasons, so the next assessment can build on it.

Every project on the roadmap needs five entries.

1. The workflow: what work, who does it today, which of the three questions applies.
2. What it needs from the foundation, meaning permissions, data and access.
3. What a good result looks like and which cases go back to a person.
4. Who looks after the application once it's live and what it may cost per month.
5. The date of the call to expand, rework or end it.

If a field stays empty, the project waits. Whatever waits stays on the roadmap with its reason, so it isn't forgotten and doesn't quietly start anyway.