Most process maps get built once, satisfy an audit, and die in a shared folder. The moment the org chart shifts or a system changes, the map is wrong — and everyone quietly stops trusting it. This page is our attempt to build something that stays true, because people are actually using it and correcting it.

Start wide, then get specific

Every process on this page starts as a SIPOC — Suppliers, Inputs, Process, Outputs, Customers — before it gets detailed. A SIPOC forces a team to agree on scope in five or six boxes before anyone argues about task-level mechanics. The useful trick is to fill it out backwards: Customers first, then Outputs, then Process, then Inputs, then Suppliers. Naming who the work is for and what they actually need, before mapping the steps, keeps the process honest to its purpose instead of just describing what people happen to do today.

Notation is a trust exercise

A map only works if two people read it the same way. We're deliberately not using strict BPMN — Business Process Model and Notation, the ISO/IEC 19510 standard — here. BPMN uses formal pools and swimlanes, precise task/event shapes, and exact gateway logic (exclusive, parallel, inclusive) to spell out branching decisions without ambiguity. It's the right tool when a systems integrator needs to wire an actual workflow engine to it, but it reads like an engineering spec to everyone else. Instead we pair the SIPOC scope with GTC's stage-gate structure and plain process-owner, input/output, and measurement fields — closer to the spirit of ISO 9001's "process approach," which cares less about which shape you draw than about whether ownership, inputs/outputs, and KPIs are actually documented for every step.

The map as the front door to change

A static map can describe a process. A live one can drive change — because most change efforts fail for the same reason: someone updates a policy without seeing what it touches upstream or downstream. A current map makes handoffs and dependencies visible before they become a rollout problem. It's also how you find real automation and AI candidates — you can't target a bottleneck, a manual re-entry step, or an RPA opportunity you can't see mapped out. And when a change does land, the map instantly scopes who and what systems are affected, which is most of the work of planning a rollout.

What "living" means on this page, concretely

The Live Status panel above the SIPOC grid pulls real counts directly from our R&D project database — not a snapshot from the last time someone remembered to export it. The feedback flyout on the right edge lets anyone looking at a step flag that it's wrong, out of date, or missing something, and it lands in a tracked queue our team actually reviews — logged in automatically through Azure AD, no manual sign-off needed. That's the whole idea: the map corrects itself because the people doing the work are the ones maintaining it.

Where this goes next

The near-term roadmap is to make each step clickable — click a high-level box here and drop straight into the detailed procedure, the system it runs in, and the metric that tracks it, rather than making someone go find a separate SOP. Combined with the feedback loop already live on this page, that turns this from a diagram you look at once into an operating reference the teams actually return to.