03/Process telemetry
Know whether the documented process is what actually happens.
Real run data, checked against the process you designed.
Bring in run data from the systems the work happens in, compare it against the process you documented, and see precisely where the two have drifted apart.
Connecting run data
Bring in run data from the systems you already use
Run data arrives from the systems the work already happens in and is matched to the process model, so each execution is a path across a map you recognize.
- Warehouse, lake, S3, SQL, spreadsheet and webhook sources
- Runs matched to the designed process automatically
Gaps against the design
See where real runs differ from the documented process
Deviations are shown on the process itself, not in a table of exceptions, so the gap between the documented path and the real one is visible at a glance.
- Live data compared against the designed process
- Skipped, reordered and undocumented steps surfaced
Designed
Most common actual
Time and bottlenecks
See which steps are actually consuming the time
Volume, duration and rework across thousands of runs point at the steps worth changing, rather than the ones people complain about loudest.
- Bottleneck, rework and cycle-time patterns across runs
- Findings feed straight into process improvements
Documentation you can prove is accurate
The map is checked against real runs, not assumed.
Drift spotted while it is still cheap to fix
You see the process diverge while it still matters.
Effort aimed at the real bottleneck
Evidence decides what to change, not the loudest voice.
Related features
All featuresSimulation
Test a process design against realistic volumes and timings before anyone has to work that way.
This workflow
Vendor onboarding
Process improvements
One list of what to change: gaps from analysis, AI suggestions and options proven in simulation.
Common questions
Where does the run data come from?
From wherever it already lands: a data warehouse, a data lake or S3, a SQL database, a spreadsheet export, or an inbound webhook posted by the system doing the work. Nothing has to be re-instrumented first.
Is this process mining?
It covers the same ground as conformance checking, comparing real executions against a process model, with one difference that matters: the model is a process you captured and maintain in Sapeum, not one reverse-engineered from logs alone.
Do we need event logs already in place?
You need some record of what happened, in some system. If runs are already landing in a warehouse, a database or a spreadsheet, that is usually enough to start.
What happens when telemetry disagrees with the map?
That disagreement is the point. A deviation is either a map that is out of date or a process that is not being followed, and both are worth knowing. Either can be taken straight into a future-state design.
Can we see this per team or per region?
Runs carry the attributes they arrive with, so timing and deviation patterns can be read by whatever dimension your source data already has.