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.

Relevant when

A merger, consolidation or new group structure needs one way of working out of many, or each unit keeps its own and the systems are glued together
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

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

Systems don't follow strategy; they follow business capability, processes and data. I help you pin these down so decisions on technology and AI still hold up in five years.

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

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.

Does this sound familiar?

Where do things stand for you? The first conversation costs nothing and usually leaves the question clearer, whether or not it leads to a project.

Get in touch