First we answer how the operation should work. Then what to build.
Most technology decisions in a complex operation are made before anyone has written down how the operation is supposed to run. We do that first, and the implementation follows from it.
The model
An operational problem comes in. What leaves is a decision, and sometimes a system.
Something in the operation is not holding: a handoff, a decision that arrives late, two systems that disagree.
- 01
Diagnose
Trace how work, decisions and information actually move, not how the process documents say they move.
- 02
Architect
Define lifecycle states, ownership, decision rights, handoffs, exceptions and system boundaries.
- 03
Implement
Configure, connect, extend or build only what the operating architecture requires.
- 04
Operate and improve
Measure how the operating model performs and keep changing it as the operation changes.
The order of the questions matters
How should this operation actually work?
What should we build?
Asked in that order, the second question gets a short answer and a defensible scope. Asked in reverse, you end up with software that encodes the confusion it was supposed to remove.
Four ways we can act on your systems
Connect, extend, replace or transform. Which one applies is an output of the architecture, not an opening position.
Connect
The systems are right but they do not talk. We build the integration and the state ownership rules between them.
Extend
The system of record is right but incomplete. We add the operational layer it is missing.
Replace
A system is actively holding the operating model back and has to go.
Transform
The operation needs a control layer that does not exist in any product you can buy.
None of these is decided before the operating model is understood.
What implementation can involve
These are the capability areas we build in. Each one is a page with the operational detail, and each one only gets built if the architecture calls for it.
FAQ
Does an engagement always end in software?
No. An Architecture Sprint can conclude that your current systems and processes are sufficient and that the problem is in ownership, decision rights or cadence. We deliver that conclusion and the reasoning behind it.
Do you replace our ERP?
Usually not. The common outcome is that the ERP keeps being the system of record for what it already owns, and we define the boundary and build the operational layer around it. Replacing a system is one of four options and it has to be justified.
Where does the diagnosis actually start?
With how work, decisions and information move today, including the parts that only exist in people's heads. That is usually where the operating model is being held together by hand.
What if we already know what we want built?
Then the sprint is short and it confirms or corrects the scope. What we will not do is implement a scope that cannot be traced back to an operational constraint.