Most operations software is bought before anyone has written down how the operation works. The mapping is the cheap part, it takes two weeks, and it usually changes what you were about to buy.
The usual sequence is demonstration, contract, then discovery. A team sees a product, likes it, signs, and then spends the implementation phase finding out how their own operation works, at consulting rates, under a deadline set by a licence that has already started.
Reversing the first two steps costs a fortnight and changes the decision more often than not.
Not a swimlane diagram of the process as management describes it. A written account of the operation as it runs, assembled from the people who run it, containing at minimum:
Software encodes assumptions about how work is organised. Buying it is committing to those assumptions. Without a map you cannot know which of them conflict with how your operation actually runs, so you discover the conflicts one at a time during implementation, when the cost of each is highest.
The map turns that from a series of surprises into a comparison you can make on a page.
Three patterns recur.
The first: the product solves a real problem, and the real problem is downstream of a different one, so buying it would automate a step that should have been eliminated.
The second: two departments were going to buy two products because each described the same underlying need in its own vocabulary.
The third: the operation needs one integration and a change to a form, and the six-figure platform under consideration was scoped to a problem the business no longer has.
It is not a question of principle and it cannot be answered in the abstract. It is a question about how much of your operation is genuinely idiosyncratic, and that is exactly what a map measures.
An operation that is ninety percent standard should buy, and should spend its custom budget on the ten percent. An operation whose core process is the thing it competes on should not hand that process to a product roadmap it does not control. Most businesses do not know which they are until someone writes it down.
A diagnostic that can only be bought as the first phase of an implementation is not a diagnostic. It is a sales process, and everyone involved knows it, which is why the findings are discounted before they are read.
The audit stands on its own. If you take the document and implement it yourself, that is a finished outcome and there is nothing further to buy.
We hold to that because a diagnostic that cannot recommend against us is worthless as a diagnostic, and because the clients worth having are the ones who checked.
If you would rather not hire anyone, the method is not secret. Pick one process. Follow a single real unit of work through it end to end, in person, with the people who touch it. At every handoff ask two questions: where did this information come from, and what do you do when it looks wrong.
Write down the answers verbatim rather than summarised. Do it for five units of work. The pattern will be obvious by the third, and you will have a better basis for a purchasing decision than most implementation projects ever assemble.
Every operation has documentation that stopped being true at some point. This is a method for finding that point: extracting entities from records, building a graph of what should be, and reading the divergences against what is.
The pilot worked. A year later nothing is in production. The failure is almost never model quality. It is data nobody owns, permissions nobody granted, and a workflow nobody changed.
A seaweed supply operation running from Korean farms and factories to U.S. warehouses kept its truth in four disconnected spreadsheets. Discovery found 25 places the sources disagreed and 34 questions nobody had answered.