Designing Complementary Processes as a System

Complementary processes are designed as a system by connecting their triggers, information, authority and feedback loops, so that each practice reinforces the same service outcome rather than being optimised on its own. ESMi recommends starting by mapping the interfaces between processes and making decision rights explicit.

• Map process interfaces using representative cases, including material exceptions, then define the shared data and handoffs between processes. Capture a baseline first so any benefit can be demonstrated.
• Align priorities and clocks across processes, and put this on the shared agenda wherever ownership crosses boundaries. Judge the effect on flow, quality, risk and experience, not on activity volume.
• Review failures that cross process boundaries, because exceptions and workarounds often reveal more about the service than the normal route. In the article's example, incident, problem, change and configuration practices share evidence so that restoration learning leads to controlled prevention.
• Track interface failure, handoff time and end-to-end outcome as a set, agreeing a baseline, data source and owner for each and reviewing trends with both providers and consumers.
• Avoid three pitfalls: optimising each process separately, duplicating records without purpose, and leaving cross-process exceptions unowned. Evidence of a risk should lead to a named owner and a proportionate action.