Process management, connected to your architecture.

Processes and IT systems are usually documented separately. As a result, the impact of system decisions on business departments often becomes visible too late. We build a process layer connected to your architecture model, so both views are based on the same facts.

Learn More Discuss your requirements
BPMN conventions Process-to-application linkage

What we do

A process landscape
that stays usable.

Process repositories fail for predictable reasons: no agreed structure, no binding convention, no clear ownership and no connection to the systems the processes run on. We address all four.

01Process architecture

Structure before modelling.

Before modelling begins, the process landscape needs an agreed structure: a process house with management, core and supporting processes, a process hierarchy down to the level at which work is described in detail, and end-to-end processes such as order-to-cash or hire-to-retire that cross departmental boundaries. We define the modelling depth for each process area and decide where modelling deliberately ends.

What it gets youOne agreed structure that all teams model into, so processes can be found, compared and reused.
  • Process house
  • Level 1–4 hierarchy
  • End-to-end processes
  • Modelling depth
Management processes Plan Source Deliver Serve order-to-cash, end-to-end process Supporting processes One agreed structure with a defined modelling depth
02Conventions & BPMN

A binding modelling convention.

A modelling convention determines whether diagrams from different teams are comparable. We define the BPMN elements in use, naming rules, role and system assignments, criteria for subprocesses and mandatory attributes. The convention includes examples and a review checklist. Where the platform supports it, models are checked automatically before publication.

What it gets youModels that read the same way across departments, with a quality level that does not depend on the individual reviewer.
  • BPMN 2.0 elements
  • Naming rules
  • Review checklist
  • Automated checks
Modelling conventionv2

How we name, draw and publish.

  • “Check invoice”: verb plus object
  • “Invoice checking”: noun form
  • Role and system attached to every task
  • One yes/no question per gateway
  • At most 12 activities, then a subprocess
Applies toEvery published model
CheckedBefore approval
04Ownership & governance

Clear ownership for every process.

A published model without clearly assigned responsibility inevitably becomes outdated. We establish process ownership with defined responsibilities, set up a release workflow from draft to publication, define review cycles by process criticality and ensure that the approved version is always easy to find. Change requests follow a defined procedure, and all versions remain traceable for audits.

What it gets youA repository in which the published version is authoritative and current.
  • Process owners
  • Release workflow
  • Review cycles
  • Versioning & audit trail
Release recordv3.2

Order-to-cash, from draft to published version.

Draft14 March
ReviewOwner and two experts
Approved2 April
Published3 April
Next reviewApril 2027
05Analysis & improvement

From documentation to improvement.

Documented processes are the foundation, not the goal. We use them to compare the as-is and target states, prepare transformation programmes such as ERP migrations, where processes and systems change at the same time, and support standardisation when the same process runs in several variants. Where process execution data is available, we incorporate it into the analysis rather than rely on the model alone.

What it gets youImprovement decisions based on the documented landscape and, where possible, on measured process data.
  • As-is vs. target
  • Variant analysis
  • Transformation support
  • Process KPIs
Five documented variants of the same process Target process agreed, owned and measured

How it connects

Process is part
of the architecture.

We treat the process layer as one view of the same organisation your architecture model already describes. Same objects, same owners, same governance.

01

EA Practice & Methodology

The meta model, ownership model and governance that the process layer builds on rather than duplicates.

Explore the method
02

SAP Signavio

Where we implement the process layer in practice: modelling, collaboration, publication and integration with your architecture platform.

See the platform
03

An assessment of your repository?

A focused review of your process landscape covering structure, convention adherence, ownership coverage and missing links to the architecture.

Request a review

Sound familiar?

Getting a stalled
repository moving.

Many process repositories were built with substantial effort and then gradually abandoned. In most cases the causes are structural, and they can be resolved without starting over.

Talk to our process experts
“We modelled everything for the certification in 2021, and little since.”
“Three departments document the same process in three different ways.”
“Nobody can tell us which systems this process runs on.”
“The published models no longer match how we actually work.”
“It is unclear who owns most of our processes.”