Service
Enterprise architecture and process
A clear picture of where the organisation is, where it needs to be, and the processes that connect both to the daily work.
The problem
Most organisations of any size already have process maps, architecture diagrams and data definitions. The problem is rarely that nothing was documented. It is that the documents were produced for a programme that ended long ago, were never updated, and nobody trusts them enough to base a decision on them.
That leaves the organisation in the worst position available: it has paid for the work and cannot use it. When the next significant decision arrives, everything starts again, usually on a tighter timeline than last time.
The other side of the same coin is over-documentation. Layers that change at different rates are set out together, all the way down to procedure, and the whole structure inherits the fastest rate. Within eighteen months maintenance has become a full-time job producing nothing.
How I work this
Capability before process
A capability map says what the organisation must be able to do, independent of how it does it today and of who does it. It is the slowest changing layer and therefore the only one that tolerates being fixed early.
Four layers, decoupled
Business, data, application and technology, each with its own representation and its own rate of change. The alignment between them is made explicit; the layers themselves are not glued together.
Processes described in BPMN
Disciplined notation showing the flow of activities in a process, which roles are responsible at each step, key events and decisions. Discovery in collaboration with the people who do the work and know the process.
Segmentation by contribution
Not every process deserves the same investment. Differentiating processes get depth, commodity processes get a standard. This is what stops process work from spreading itself evenly across what matters and what does not.
Harmonisation after consolidation
Where five variants of the same process exist, someone has to decide which becomes the standard and state plainly what is lost in each case. That is a governance conversation, not just a documentation exercise.
What you get
- Capability map with current and target state assessment
- Architecture principles, written to be used in real decisions
- Baseline and target architecture across four layers, decoupled by rate of change
- BPMN process descriptions at deliberately chosen levels of abstraction, segmented by value contribution
- Harmonised target processes, with any remaining variation justified
- Gap analysis and a sequenced roadmap
Get in touch when
- A transformation programme has executive sponsorship but no coherent architecture underneath it
- Processes exist in people's heads, in slide decks, or in eleven incompatible Visio files
- A merger or consolidation requires one way of working from several
- An ERP or CRM programme is about to configure processes nobody has agreed on
- Maintaining the architecture feels like a full-time job producing nothing
Scope
Diagnosis
One to two days. A read on where the organisation stands and what would change most.
Capability map and architecture layers
Four to eight weeks, depending on size and number of stakeholders.
Process work in one domain
Six to twelve weeks for a single domain, from discovery to agreed target processes.
Full engagement
Three to six months. Target architecture, process descriptions and roadmap through to a decision.
Related
The processes established here are a precondition for Data and information architecture and for AI and agent readiness.
Does this sound familiar?
Tell me briefly where you are. The first conversation costs nothing and usually leaves the question clearer than it was, whether or not anything follows from it.
Get in touch