For large commercial organisations
You did not underbuy. Six departments bought six good systems, each one healthy, each one reporting success. And the question your board asks — why did that take eleven days — cannot be answered by any of them, because the eleven days happened in the gaps between them.
A request comes in. It is logged in one system, assigned in a second, escalated in a third, and resolved in a fourth. Every one of those systems reports that its part went fine. Nobody owns the seams, so nobody reports on them, and the total time nobody measures is the number your customer experiences.
When something goes wrong, the reconstruction takes longer than the incident. Somebody exports three spreadsheets, joins them by hand, and produces an answer with a caveat about the join. The answer is usually roughly right and it always arrives after the decision had to be made.
The people closest to the work already know where it jams. They have said so, more than once, in meetings where the response was a request for data. The data lives in four systems that do not share a key, so the request is effectively a refusal, and everyone in the room understands that.
Meanwhile the improvement projects run on their own clock. One removes four minutes from a step that waits nine days for an approval, and it is reported as a win because the four minutes are the part that could be measured.
No single system owns the whole path a piece of work travels, so the waiting between systems — usually most of the elapsed time — is neither measured, owned, nor improvable.
This is why buying a seventh system does not help. Each one is a good record of its own segment, and every one of them is honest about what it can see. The elapsed time your customer feels is the sum of the segments plus all the waiting between them, and that second term is larger than the first in nearly every operation that has grown past a few hundred people.
The fix is not consolidation. Ripping out working systems to reach a single vendor is a multi-year programme that trades a measurement problem for a migration problem, and it usually arrives late enough that the operation has changed underneath it.
What is missing is a layer above the systems that knows what a request is trying to accomplish, where it currently sits, what should happen next, and how long it has been waiting for that thing to happen. Once that exists the waiting becomes visible, and once the waiting is visible it becomes somebody’s job.
Elapsed time from request to resolution, decomposed for the first time — measured by work time, wait time, blocked time and approval time separated, per step, against your own starting baseline.
Where the operation actually jams — measured by the step with the largest waiting time and the fastest-growing queue, named rather than nominated.
How long a piece of work sits before anybody touches it — measured by queue age at every handoff, including the tail — not the average, which hides the cases people remember.
Rework, which is usually invisible because it looks like normal volume — measured by the count of items that re-entered a step they had already passed.
Whether improvement effort landed anywhere that mattered — measured by end-to-end elapsed time before and after, rather than the improved step in isolation.
The number of escalations that reach an executive without a decision attached — measured by escalations carrying a named decision and named consequence, as a share of all escalations.
that this replaces your systems, or that it improves a process nobody is willing to change. If the constraint turns out to be an approval that one committee owns and will not delegate, this will show you that clearly and it will not move it for you.
Read access to the systems holding the state, and one person per process who can say what the work is for. That is most of the requirement for seeing the flow. Nothing has to move, nothing has to be migrated, and no system has to be replaced for the measurement to be real.
Writing anything back is a separate decision, made per step, and it does not happen because read access was granted. Those are two different permissions on purpose, because collapsing them is how a measurement project turns into a change nobody approved.
Identity comes from your identity provider. Access follows the groups you already maintain, which means offboarding somebody in your directory offboards them here, without a second list for somebody to forget.
Every consequential action carries a receipt: what was done, under whose authority, at what time, against which record, with what result. That record is yours, exportable, and it does not require us to produce it for you.
Operational access is not permission to train. Your operating data is not training material for anything that touches another organisation, and that is an architectural boundary rather than a policy sentence in a document you will never audit.
And where we have not been independently assessed, the page says so. The status vocabulary on our Trust Center is deliberately narrow so that "designed for" and "audited against" cannot be read as the same claim.
The review that matters is not about features. It is about what this can reach, what it can do without asking, who approved that, and what happens to the data when the relationship ends. Those four answers exist in writing and do not require a call to obtain.
Start with read-only. An observation scope with no execution authority is a materially smaller review than a platform adoption, and it produces the flow measurement that makes the larger review worth doing.
We do not claim certifications we do not hold. Where an obligation applies only under a specific contract or data class, it is marked as applicability-gated rather than presented as a standing capability.
One process that crosses at least two departments, chosen because the handoff between them is where everybody already suspects the time goes — observed first, with no authority to change anything.
Pick the process where the elapsed time embarrasses you and the reason is contested. Contested is the important word: if everyone already agrees on the cause, you do not need a measurement, you need a decision.
The observation phase changes nothing. It grants no authority to act. What it produces is the decomposition — work time, wait time, blocked time, approval time, rework — for a process that has probably never been decomposed. Several organisations should stop there and spend the next quarter on what it revealed.
Only after that is there a conversation about delegating a step, and it is one step, named, with a written grant you can withdraw the same afternoon.
It is a layer above them, and the test of that claim is what it asks for: read access and a process owner, not a migration. If a proposal asks you to move data out of the systems you have, it is a replacement wearing a smaller name, and you are right to refuse it. Nothing here works by replacing what you run.
It usually is, and it does not have to be solved first. A process is followed by the identifiers each system already uses, joined at the step boundaries rather than by a master record that does not exist. That produces the flow measurement without a data-unification programme in front of it. Where the join genuinely cannot be made, that gap is reported as a gap rather than estimated across.
For an observation scope they are approving read access to the systems holding one process, with no execution authority — a materially smaller review than a platform adoption. Bring them in at scoping rather than at go-live, and give them the architecture documentation and the authority model before the first connection. If read access to that scope is still refused, that is a real constraint and it is cheaper to find in week one.
It cannot act outside an authority grant you wrote, and a grant is short enough to read on one page. Anything outside it becomes an escalation naming the decision required and who has to make it, rather than a best guess executed on your behalf. Every action inside it carries a receipt, and the grant can be withdrawn without a contract change or a support ticket.
Observation does not collide with anything, because it changes nothing — and a transformation programme is one of the few situations where an independent baseline is worth more than usual. If the programme is working, the measurement will show it moving. If a workstream is improving a step that waits nine days for an approval, you would want to know that now rather than at the end-of-year review.