In 1998 it found the answer. In 2026 it found out why there wasn’t one.
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
Executive Quick Read: A forward map can only contain what somebody already thought of. A trace can reach the question nobody had a reason to ask.
In 1998 that question was what time of day do orders come in. Nobody had asked it, because there was no reason to — until a sequence of eliminations left nowhere else to look.
Last week the same method ran again, on my own operation. It produced the same kind of question. This time the instrument could not answer it, and finding that out was the result.
Five to six hours across two days. That is what it cost.
Two ways to approach a problem
A forward map starts with an intended outcome and works backward to a plan. Define the goal, identify the gap, sequence the steps, execute. It is how nearly every improvement initiative is built.
It has one structural property worth naming. A forward map can only contain what somebody already thought of.
That is not a criticism of the people building it. It is arithmetic. If anyone had known about the condition actually blocking the outcome, they would have designed around it already. So by construction, the obstacle is the one element the map is guaranteed to be missing.
A trace starts somewhere else — at a failure, an anomaly, or a condition nobody can account for — and follows it, letting each answer determine the next question. It has no destination. That is the point.
Here is the difference in one image.
Rolling out the enterprise map and working out how to get across it is like dumping a thousand-piece puzzle on a table and assembling as you go. Every piece is real. Every piece is in front of you. Sorting them feels like progress.
And when you finish you have a picture of what exists, not of what is missing.
The piece that matters is the one that was never in the box. If it had been in the box, somebody would have placed it already and there would be no problem to solve.
That is also why people assume a diagnosis must proceed by elimination. If you believe the answer is somewhere in the pile, sorting the pile is the rational method. Elimination is what you do when you are confident the answer is already in front of you.
A trace does not assume that. It asks where the picture starts and where its edges are — which is not a question about any of the pieces.
This is not a new objection, and I want to date it before going further.
In January 2008 I published a fifty-page independent assessment of SAP’s procurement offering for the public sector. Part of it examined the structured checkpoint methodology SAP had built for managing implementations — which was, in its day, exactly what good governance was supposed to look like. Defined stages, formal reviews, decision points.
My conclusion then was that it was creative but still worked within the flawed confines of a traditional enterprise-based project.
Better discipline applied to an inaccurate representation of the operation is still an inaccurate representation. That was the objection eighteen years ago, and nothing since has changed it.
What follows is the method behind that objection, run twice. Twenty-eight years apart, same sequence, different results — and the difference is the useful part.
1998
A defence maintenance operation was delivering next-day parts fifty-one percent of the time against a ninety percent requirement.
Every visible indicator pointed at procurement. That is where the failure showed, so that is where everyone was looking.
I did not work through a sequence of eliminations. The first question I asked, before anything else, was: what time of day do the orders come in?
That was not intuition. It was logic about the measurement itself.
A next-day requirement is a duration, and a duration has a start point. Procurement’s clock begins when the order is received — not when someone decides they need the part, not when it is placed, but when it lands. Everything downstream is measured from that moment.
Time of day is ground zero. That is when the procurement clock starts ticking. If orders arrive after a cutoff, or arrive the following day, you are not going to hit your numbers no matter how well the rest of it runs.
Procurement cannot do anything with an order it has not received.
Nobody had established that boundary. The performance was being measured from a start point nobody had checked.
The orders arrived late in the afternoon. In batches.
Service technicians were batching part orders to the end of the day, because they were measured on call volume and stopping to submit a part order interrupted a service call. Rational behavior, in another function, one department away from the people being blamed, and in nobody’s process document.
And that answer was not the end of it. It was the first question that could be answered.
Knowing when orders actually arrived made the next question askable, and the one after that. Courier fragmentation. Customs clearance. Two finance line items that reconciled cleanly on their own while the margin disappeared in the gap between them. Each stage became visible only because the previous one had been resolved.
None of that was on anybody’s list at the start. It could not have been.
Delivery reached 97.3% in three months and held for seven years. Cost of goods fell twenty-three percent. Twenty-three full-time equivalents became three inside eighteen months — while the supply base widened rather than narrowed, because the coordination was redesigned rather than automated onto what was already there.
Notice who benefited. The technician got his day back. The buyer’s queue stopped arriving in one late block. Suppliers won more work rather than less. The operation got its delivery rate. Nobody traded against anybody.
That is not a negotiated outcome, and it is not something you can design for. A forward map optimizes for whoever commissioned it — and the technicians were not the customer. They would have absorbed whatever procurement decided.
Success was not a single event. It was a staged recovery that began with understanding a failure.
No forward map contains that finding, because the finding is about the service function’s performance metric. Nothing in a procurement improvement plan has a line for it.
2026
An unexplained pattern appeared in my own site traffic — a sharp rise from one country, in this case China. It could have been Brazil and nothing that follows would change. No campaign, no relationship, no published reason for it.
The same method. Start with the condition, eliminate, let each answer set the next question.
Is it concentrated in one place? No — it appeared across many locations. Single source eliminated.
Is it part of a wider regional trend? No — neighboring markets did not move with it. Regional trend eliminated.
Is one article driving it? No — consumption spread across recent and historical material. Single-article referral eliminated.
Is a new channel responsible? No referrer showed one. Identifiable channel eliminated.
What does the technical profile say? It narrowed the field without closing it.
Which left the question that mattered, arrived at exactly the way the 1998 question was arrived at — because everything else had been eliminated:
How deep are those sessions?
Someone working through an archive reads several pages per visit. Automated collection does not. That single measurement separates the two remaining explanations, and nothing else does.
I could not get it.
Not because the data does not exist. Because the analytics package I had been paying for since 2007 does not cross-tabulate. It reports traffic by location. It reports pages per visitor. It cannot report pages per visitor by location — and nearly every question worth asking requires two dimensions held together.
The trace did not fail to find an answer. It found the boundary of the instrument.
What is the same, and what is not
The two traces did not take the same route, and that is the part worth noticing.
In 1998 I went straight to the question. I knew where the clock started, so there was nothing to eliminate — the boundary of the measurement was the first thing to establish, and everything else followed from it.
In 2026 I had no idea where the clock started. Nobody does, for an unexplained pattern in traffic data. So the eliminations ran until a question surfaced: is it concentrated, is it regional, is it one article, is it a channel. Four removals, and the fifth question appeared.
Same destination, two routes. Know the operating logic and go straight to the ground-zero question. Do not know it, and eliminate until the question shows itself.
That is what domain knowledge actually buys. Not a better answer — a shorter path to the right question. Which is also why the method still works without it, and why the 2026 case is the more useful demonstration of the two.
But I want to be precise about the eliminations, because they are easily mistaken for the method itself. They are not. They are what you do when you cannot yet see where the picture starts. Each one removes a pile of pieces from the table, and none of them produces the answer. What they produce is a clearer view of the edge — and the question, when it comes, is about the edge and not about any of the pieces.
Which is why a trace that eliminates for a while and then asks how deep are those sessions is doing the same thing as one that opens with what time of day do the orders come in. Both are asking where the thing being measured actually begins.
What both share is the question itself: one nobody had a reason to ask, about a boundary nobody had checked.
The results are not identical either, and I am not going to pretend otherwise.
In 1998 the instrument could answer the question. The operation changed and the numbers moved.
In 2026 the instrument could not. The original anomaly is still unexplained, with a review date and a stated test for what would confirm or kill it.
That is a normal outcome for a trace, and it is the one people leave out of the case studies. A method that always finds the answer is not a method. It is a story told after the fact.
Why it is solving, not solved
The word matters more than it looks.
Solved is a state. It closes the file, and the moment it closes, the examining stops. Not the operation — the operation carries on changing. The people who understood why it worked move on. The market moves. The supply base narrows without anyone deciding to narrow it. Variations of an old disruption come back wearing different clothes.
What stays fixed is the answer. And the gap opens silently, because nothing signals it.
Which is the same failure as a control that never fires. A rule nobody has needed stops being read. A solution declared complete stops being questioned. In both cases the thing that would have caught the drift — continuing to examine — is precisely what the declaration switches off.
It is also why one case in my records looks different from all the others. A public sector procurement program I have followed since 2007 was revised roughly monthly, on the basis of what the people using it actually asked for, and changed platform once in nearly two decades. Nobody ever declared it solved. The examining never stopped, so the distance between what the system did and what the operation needed never grew wide enough to require starting over.
Set that against every case where something worked, was declared finished, and the next program arrived into whatever had drifted in the meantime.
So when I say the 1998 result held for seven years, I mean it as a duration and not as a verdict. It held while the conditions it was built for held. What happened in year eight is a question with an answer somewhere — and solved is the word that stops anybody asking it.
What five hours bought
No answer to the question I started with.
A replaced instrument. Properly configured, capable of the cross-tabulation the old one never could. Every question of that shape is now answerable going forward.
A structural finding I was not looking for. Somewhere in the data, the primary way this archive is found had shifted — from social distribution to search. That is a separate question for a separate day.
And several of my own errors, caught the same way everything else was: by the next question rather than by any rule. Two figures treated as independent confirmations turned out to be the same data at two levels of aggregation. A reading I talked myself out of was closer to right than the correction. And a signal I dismissed as thin was visible in a dataset I had not opened — I had judged the evidence using an instrument that could not see it, which is what the whole trace ended up being about.
The forward-map version does not exist
Consider what the goal-first equivalent looks like.
Objective: improve analytics capability. No trigger. No failure. No complaint. Nineteen years of adequate reporting on a site where nothing was broken.
That project does not get proposed, and if proposed it does not get funded.
The limitation had been there the entire time. It never caused a problem, because nobody had asked a question the tool could not answer. The moment somebody did, it surfaced immediately.
You cannot specify in advance what an examination will find. Which is exactly why it has to be done rather than planned — and why the first phase of any technology decision is not a technology decision.
Today’s takeaway
Trace backward from a failure and you find the cause. Map forward toward an outcome and you find failures of unknown origin after the fact.
Twenty-eight years apart, on entirely different problems, the same method reached the same kind of question — the one nobody had a reason to ask.
Once it produced a number that changed an operation. Once it produced the discovery that the tooling could not see what mattered.
Both were worth having. Only one of them would have made the brochure.
Keep the human at the wheel. Everything else is just faster.
-30-
This analysis draws on the Procurement Insights archive — an independent record carrying zero vendor sponsorships, published openly since 2007 and consolidating documented client work, lectures, and articles reaching back to 1998. Every claim is held to the Provenance Ledger™: a verify-before-publish discipline that traces each assertion to a primary source and never quietly edits the record once posted. That record is the evidence base for two working lenses — Invariant Physics™, the constant that however far the technology advances the operating logic must be in place first, and Implementation Physics™, its per-engagement application. Phase 0™ identifies and examines the unique and collective attributes within a wide range of seemingly disparate strands — the Strand Commonality™ theory, funded by the Government of Canada’s Scientific Research and Experimental Development program.
Getting it right rather than being right.
Jon W. Hansen, FCIPS — Procurement Insights | Hansen Models™
Related
Solving a 1998 Delivery Failure and a 2026 Traffic Anomaly With the Same Trace
Posted on September 6, 2026
0
In 1998 it found the answer. In 2026 it found out why there wasn’t one.
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
Executive Quick Read: A forward map can only contain what somebody already thought of. A trace can reach the question nobody had a reason to ask.
In 1998 that question was what time of day do orders come in. Nobody had asked it, because there was no reason to — until a sequence of eliminations left nowhere else to look.
Last week the same method ran again, on my own operation. It produced the same kind of question. This time the instrument could not answer it, and finding that out was the result.
Five to six hours across two days. That is what it cost.
Two ways to approach a problem
A forward map starts with an intended outcome and works backward to a plan. Define the goal, identify the gap, sequence the steps, execute. It is how nearly every improvement initiative is built.
It has one structural property worth naming. A forward map can only contain what somebody already thought of.
That is not a criticism of the people building it. It is arithmetic. If anyone had known about the condition actually blocking the outcome, they would have designed around it already. So by construction, the obstacle is the one element the map is guaranteed to be missing.
A trace starts somewhere else — at a failure, an anomaly, or a condition nobody can account for — and follows it, letting each answer determine the next question. It has no destination. That is the point.
Here is the difference in one image.
Rolling out the enterprise map and working out how to get across it is like dumping a thousand-piece puzzle on a table and assembling as you go. Every piece is real. Every piece is in front of you. Sorting them feels like progress.
And when you finish you have a picture of what exists, not of what is missing.
The piece that matters is the one that was never in the box. If it had been in the box, somebody would have placed it already and there would be no problem to solve.
That is also why people assume a diagnosis must proceed by elimination. If you believe the answer is somewhere in the pile, sorting the pile is the rational method. Elimination is what you do when you are confident the answer is already in front of you.
A trace does not assume that. It asks where the picture starts and where its edges are — which is not a question about any of the pieces.
This is not a new objection, and I want to date it before going further.
In January 2008 I published a fifty-page independent assessment of SAP’s procurement offering for the public sector. Part of it examined the structured checkpoint methodology SAP had built for managing implementations — which was, in its day, exactly what good governance was supposed to look like. Defined stages, formal reviews, decision points.
My conclusion then was that it was creative but still worked within the flawed confines of a traditional enterprise-based project.
Better discipline applied to an inaccurate representation of the operation is still an inaccurate representation. That was the objection eighteen years ago, and nothing since has changed it.
What follows is the method behind that objection, run twice. Twenty-eight years apart, same sequence, different results — and the difference is the useful part.
1998
A defence maintenance operation was delivering next-day parts fifty-one percent of the time against a ninety percent requirement.
Every visible indicator pointed at procurement. That is where the failure showed, so that is where everyone was looking.
I did not work through a sequence of eliminations. The first question I asked, before anything else, was: what time of day do the orders come in?
That was not intuition. It was logic about the measurement itself.
A next-day requirement is a duration, and a duration has a start point. Procurement’s clock begins when the order is received — not when someone decides they need the part, not when it is placed, but when it lands. Everything downstream is measured from that moment.
Time of day is ground zero. That is when the procurement clock starts ticking. If orders arrive after a cutoff, or arrive the following day, you are not going to hit your numbers no matter how well the rest of it runs.
Procurement cannot do anything with an order it has not received.
Nobody had established that boundary. The performance was being measured from a start point nobody had checked.
The orders arrived late in the afternoon. In batches.
Service technicians were batching part orders to the end of the day, because they were measured on call volume and stopping to submit a part order interrupted a service call. Rational behavior, in another function, one department away from the people being blamed, and in nobody’s process document.
And that answer was not the end of it. It was the first question that could be answered.
Knowing when orders actually arrived made the next question askable, and the one after that. Courier fragmentation. Customs clearance. Two finance line items that reconciled cleanly on their own while the margin disappeared in the gap between them. Each stage became visible only because the previous one had been resolved.
None of that was on anybody’s list at the start. It could not have been.
Delivery reached 97.3% in three months and held for seven years. Cost of goods fell twenty-three percent. Twenty-three full-time equivalents became three inside eighteen months — while the supply base widened rather than narrowed, because the coordination was redesigned rather than automated onto what was already there.
Notice who benefited. The technician got his day back. The buyer’s queue stopped arriving in one late block. Suppliers won more work rather than less. The operation got its delivery rate. Nobody traded against anybody.
That is not a negotiated outcome, and it is not something you can design for. A forward map optimizes for whoever commissioned it — and the technicians were not the customer. They would have absorbed whatever procurement decided.
Success was not a single event. It was a staged recovery that began with understanding a failure.
No forward map contains that finding, because the finding is about the service function’s performance metric. Nothing in a procurement improvement plan has a line for it.
2026
An unexplained pattern appeared in my own site traffic — a sharp rise from one country, in this case China. It could have been Brazil and nothing that follows would change. No campaign, no relationship, no published reason for it.
The same method. Start with the condition, eliminate, let each answer set the next question.
Is it concentrated in one place? No — it appeared across many locations. Single source eliminated.
Is it part of a wider regional trend? No — neighboring markets did not move with it. Regional trend eliminated.
Is one article driving it? No — consumption spread across recent and historical material. Single-article referral eliminated.
Is a new channel responsible? No referrer showed one. Identifiable channel eliminated.
What does the technical profile say? It narrowed the field without closing it.
Which left the question that mattered, arrived at exactly the way the 1998 question was arrived at — because everything else had been eliminated:
How deep are those sessions?
Someone working through an archive reads several pages per visit. Automated collection does not. That single measurement separates the two remaining explanations, and nothing else does.
I could not get it.
Not because the data does not exist. Because the analytics package I had been paying for since 2007 does not cross-tabulate. It reports traffic by location. It reports pages per visitor. It cannot report pages per visitor by location — and nearly every question worth asking requires two dimensions held together.
The trace did not fail to find an answer. It found the boundary of the instrument.
What is the same, and what is not
The two traces did not take the same route, and that is the part worth noticing.
In 1998 I went straight to the question. I knew where the clock started, so there was nothing to eliminate — the boundary of the measurement was the first thing to establish, and everything else followed from it.
In 2026 I had no idea where the clock started. Nobody does, for an unexplained pattern in traffic data. So the eliminations ran until a question surfaced: is it concentrated, is it regional, is it one article, is it a channel. Four removals, and the fifth question appeared.
Same destination, two routes. Know the operating logic and go straight to the ground-zero question. Do not know it, and eliminate until the question shows itself.
That is what domain knowledge actually buys. Not a better answer — a shorter path to the right question. Which is also why the method still works without it, and why the 2026 case is the more useful demonstration of the two.
But I want to be precise about the eliminations, because they are easily mistaken for the method itself. They are not. They are what you do when you cannot yet see where the picture starts. Each one removes a pile of pieces from the table, and none of them produces the answer. What they produce is a clearer view of the edge — and the question, when it comes, is about the edge and not about any of the pieces.
Which is why a trace that eliminates for a while and then asks how deep are those sessions is doing the same thing as one that opens with what time of day do the orders come in. Both are asking where the thing being measured actually begins.
What both share is the question itself: one nobody had a reason to ask, about a boundary nobody had checked.
The results are not identical either, and I am not going to pretend otherwise.
In 1998 the instrument could answer the question. The operation changed and the numbers moved.
In 2026 the instrument could not. The original anomaly is still unexplained, with a review date and a stated test for what would confirm or kill it.
That is a normal outcome for a trace, and it is the one people leave out of the case studies. A method that always finds the answer is not a method. It is a story told after the fact.
Why it is solving, not solved
The word matters more than it looks.
Solved is a state. It closes the file, and the moment it closes, the examining stops. Not the operation — the operation carries on changing. The people who understood why it worked move on. The market moves. The supply base narrows without anyone deciding to narrow it. Variations of an old disruption come back wearing different clothes.
What stays fixed is the answer. And the gap opens silently, because nothing signals it.
Which is the same failure as a control that never fires. A rule nobody has needed stops being read. A solution declared complete stops being questioned. In both cases the thing that would have caught the drift — continuing to examine — is precisely what the declaration switches off.
It is also why one case in my records looks different from all the others. A public sector procurement program I have followed since 2007 was revised roughly monthly, on the basis of what the people using it actually asked for, and changed platform once in nearly two decades. Nobody ever declared it solved. The examining never stopped, so the distance between what the system did and what the operation needed never grew wide enough to require starting over.
Set that against every case where something worked, was declared finished, and the next program arrived into whatever had drifted in the meantime.
So when I say the 1998 result held for seven years, I mean it as a duration and not as a verdict. It held while the conditions it was built for held. What happened in year eight is a question with an answer somewhere — and solved is the word that stops anybody asking it.
What five hours bought
No answer to the question I started with.
A replaced instrument. Properly configured, capable of the cross-tabulation the old one never could. Every question of that shape is now answerable going forward.
A structural finding I was not looking for. Somewhere in the data, the primary way this archive is found had shifted — from social distribution to search. That is a separate question for a separate day.
And several of my own errors, caught the same way everything else was: by the next question rather than by any rule. Two figures treated as independent confirmations turned out to be the same data at two levels of aggregation. A reading I talked myself out of was closer to right than the correction. And a signal I dismissed as thin was visible in a dataset I had not opened — I had judged the evidence using an instrument that could not see it, which is what the whole trace ended up being about.
The forward-map version does not exist
Consider what the goal-first equivalent looks like.
Objective: improve analytics capability. No trigger. No failure. No complaint. Nineteen years of adequate reporting on a site where nothing was broken.
That project does not get proposed, and if proposed it does not get funded.
The limitation had been there the entire time. It never caused a problem, because nobody had asked a question the tool could not answer. The moment somebody did, it surfaced immediately.
You cannot specify in advance what an examination will find. Which is exactly why it has to be done rather than planned — and why the first phase of any technology decision is not a technology decision.
Today’s takeaway
Trace backward from a failure and you find the cause. Map forward toward an outcome and you find failures of unknown origin after the fact.
Twenty-eight years apart, on entirely different problems, the same method reached the same kind of question — the one nobody had a reason to ask.
Once it produced a number that changed an operation. Once it produced the discovery that the tooling could not see what mattered.
Both were worth having. Only one of them would have made the brochure.
Keep the human at the wheel. Everything else is just faster.
-30-
This analysis draws on the Procurement Insights archive — an independent record carrying zero vendor sponsorships, published openly since 2007 and consolidating documented client work, lectures, and articles reaching back to 1998. Every claim is held to the Provenance Ledger™: a verify-before-publish discipline that traces each assertion to a primary source and never quietly edits the record once posted. That record is the evidence base for two working lenses — Invariant Physics™, the constant that however far the technology advances the operating logic must be in place first, and Implementation Physics™, its per-engagement application. Phase 0™ identifies and examines the unique and collective attributes within a wide range of seemingly disparate strands — the Strand Commonality™ theory, funded by the Government of Canada’s Scientific Research and Experimental Development program.
Getting it right rather than being right.
Jon W. Hansen, FCIPS — Procurement Insights | Hansen Models™
Share this:
Like this:
Related