Experimenting without a criterion produces enthusiasm and no decision. An assessment produces a list of processes ranked by value and feasibility.
The difference isn’t duration. It’s outcome. An experiment ends with an impression, positive or negative. An assessment ends with a reasoned choice about what to do, in what order, with what prerequisites.
Many organizations have twelve or eighteen months of initiatives behind them, spread across different departments, and struggle to answer the simplest question: which process has actually changed.
What an assessment looks at
Five dimensions, examined together because it’s their intersection that determines feasibility.
Processes. Not the org chart: the actual flow of the work. Where an activity enters, which steps it passes through, where time and rework pile up, which exceptions recur and how often. This part is done by talking to the people who do the work, not only to those who coordinate it, because the gap between the formal procedure and actual practice is itself information.
Data. Which documents and which information sources would be needed, what state they’re in, who governs them. Volume, readability, presence of duplicates, certainty about versions. This is the dimension that most often scales back the initial ambitions.
Systems. What’s already in use, what interfaces it exposes, what constraints it imposes. A process that’s perfect on paper becomes impractical if the system supporting it doesn’t allow access to the data.
Constraints. Regulatory, contractual, security-related, union-related. These need to be established at the start because they can directly rule out some options, and finding that out after the design phase is expensive.
Skills and roles. Who would oversee the system, who would answer for it, what internal capacity exists for maintenance. A project with no internal owner doesn’t reach production, regardless of its technical quality.
The value-feasibility matrix
The result of the analysis needs to be made comparable. The tool is simple: every candidate process is placed against two axes.
Value is estimated on three components: activity volume, unit time absorbed, cost of current errors. It doesn’t need accounting-level precision. It needs an order of magnitude that lets you tell a process handling a thousand cases a year apart from one handling fifty.
Feasibility is assessed on four components: availability and quality of data, accessibility of the systems involved, clarity of the process rules, existence of an internal owner. This is the dimension where initial assessments tend to be most optimistic, and the one worth estimating more cautiously.
The placement produces four zones.
High value and high feasibility: these are the candidates for the first project. One or two are enough.
High value and low feasibility: keep them, but precede them with preparation work, typically on data or integration. Putting them first is the mistake that stalls programs.
Low value and high feasibility: useful as an exercise if you need to build internal trust, with the awareness that they won’t produce a significant return.
Low value and low feasibility: exclude them.
Why excluding is more useful than including
This is the part that generates the most resistance and produces the most value.
A list of twenty opportunities isn’t a decision. It’s a deferral, and its practical effect is to spread resources across too many fronts, with the result that none of them reach production.
Excluding means stating, with a written rationale, why a process isn’t a candidate right now. The recurring reasons are few: the document base isn’t usable in its current state, the system involved doesn’t expose the data, the process rules aren’t defined, there’s no owner available to oversee it, the volume doesn’t justify the maintenance cost.
Every reasoned exclusion has two effects. It avoids an investment destined to stall. And it produces a list of concrete prerequisites: if you want to bring that process back into the candidate pool, you know exactly what to do.
There’s a third, less expected and fairly frequent outcome. Some processes turn out to be solvable without artificial intelligence: a deterministic rule, a configuration change, a workflow review. Pointing that out is part of the job, even when it narrows the scope of a possible engagement.
The expected outcome
An assessment ends with four elements.
A map of candidate processes, ranked by value and feasibility, with reasoned exclusions.
A roadmap with explicit priorities, sequence and dependencies. Sequence matters as much as selection: some projects create the conditions for the ones that follow, in terms of data prepared, integrations built and skills acquired.
Indicators for each project, with a measurement of the starting state wherever it was possible to capture it.
The prerequisites to address, separated into what’s part of the project and what’s up to the organization.
It’s a document meant to drive a decision. If it doesn’t let you say which process to start with next month, it hasn’t achieved its purpose.
What an assessment doesn’t do
It doesn’t produce a working system. It produces an informed decision, which is a different thing and should be communicated as such.
It doesn’t eliminate uncertainty. Value estimates remain estimates, and some will turn out to be optimistic. It narrows the range, it doesn’t zero it out.
It doesn’t replace technical experimentation when the uncertainty is genuinely technical. In some cases the right conclusion is that a targeted test on a sample of real data is needed, with a defined verification goal and a limited duration. That’s different from experimenting without a criterion.
And it doesn’t work if the organization isn’t willing to exclude. An assessment that confirms every idea already circulating in the company hasn’t added anything.
In closing
A few weeks of structured analysis change how an organization approaches the following two years. Not because they reveal hidden opportunities, but because they put the known ones in order and make the constraints explicit.
The cost is contained and predictable. The cost of the alternative — parallel initiatives with no priority criterion — is spread out over time and harder to recognize.
If you’re weighing where to start, the assessment is where we begin: process analysis, verification of data and systems, a priority matrix and a roadmap with indicators.
