The challenge
Every site ran the same kind of process and described it differently. Step boundaries lived in phase tags at one site, recipe strings at another, a SCADA state machine at a third and MES operation codes at a fourth. Step names didn’t match across sites, so nobody could line up a chromatography step at one plant against the same step at another.
That left two questions without good answers. On the floor: is the batch running right now on pace, and if not, which step is slipping? After the fact: across months of batches, where did the time actually go — the steps, the gaps between them, or downtime inside them?
The existing per-asset workbenches were built by hand, one formula at a time, and carried their own quirks. One used the start of the final step as the batch boundary instead of its end, which quietly moved time out of the batch and into the next transition. Phase tags could interpolate across gaps of more than a day and create capsules for steps that never ran. Scaling that by hand to every site would not have stayed consistent.
Our approach
- Canonical steps first We agreed on step names and one step pattern: a start condition and an end condition joined into a duration capsule, stamped with batch ID, step number, step name and step type. Only the comparison operator changed between historians, which is what made cross-site joins possible.
- One template, configured per site SPy generates the asset tree from a per-site Excel config: site settings, product settings and one row per step with only the tags that step needs. Every site was onboarded by filling in a config, not by rebuilding formulas.
- Steps, activity and transitions as separate conditions Step capsules, a downtime condition that overlaps the step rather than nesting inside it, and transitions between adjacent steps carrying previous and next step properties. Everything rolls up to root conditions that feed an OData table directly: capsules as rows, properties as columns.
- Batch identity where it could be trusted The batch-ID tag was only reliable on early steps, and a time-based join broke when batches overlapped. A Python stage propagates the ID step by step, builds each batch’s window from its own start and end, trims overlaps, and leaves a running batch open-ended so it is never truncated.
- A baseline worth comparing against Each step and transition gets a theoretical best: the minimum observed duration from completed batches, compared like for like. Every capsule carries its duration, that minimum and its overage, so live and historical batches are measured against the same target.
The outcome
Every site now reports the same steps under the same names from one template, with an estimated 22% capacity increase in the first campaign. The same model serves two jobs. A supervisor sees in-progress batches alongside completed ones and can spot a step running over its theoretical best while there is still time to act. An engineer can pull months of batches and drill from a slow one down to the step, transition or downtime window that caused it.
- The same step compared across sites, assets and products, no reconciliation
- Active time and downtime per step: slow processing or waiting
- Every step, transition and batch against its theoretical best
- Variance per step, not just the average duration
- Transitions reported as their own measure, not hidden in the batch