Technology
How do you know what breaks if you retire a system?
Ask the model. Every process step is held against the system that enables it, so "which processes rely on this?" and "what breaks if we turn it off?" are queries rather than a discovery project. The dependencies include the manual work around a system, which an architecture diagram does not show.
The work we would model first
Examples, not a fixed list. Bring the process you already argue about and we will start there.
- Application rationalisation and retirement decisions
- Migration and replatforming, and what depends on the old thing
- Integration mapping between systems and the work between them
- Change impact before a release, across processes rather than components
What technology gets out of it
- Dependencies visible per process, not guessed from a diagram
- Impact radius understood before a change is committed
- The manual workarounds around a system counted as dependencies
- Two options compared on the same basis, in the open
Bring one process you already argue about.
We will run it through Omni with you on your own material. You keep the model either way.