Process management, integrated with your architecture.

Processes and IT systems are usually documented separately. As a result, the impact of system decisions on business departments often becomes apparent too late. We build a process layer connected to your architecture model, so that 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 remains usable.

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

01Process Architecture

Structure before modeling.

Before modeling begins, the process landscape requires an agreed-upon structure: a process framework comprising management, core, and supporting processes; a process hierarchy extending 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 span departmental boundaries. We define the level of detail for each process area and determine where modeling intentionally ends.

What you get: A single, agreed-upon structure that all teams use as a template, so that processes can be identified, compared, and reused.
  • Processing facility
  • Level 1–4 hierarchy
  • End-to-end processes
  • Modeling depth
Management processes Plan Source Deliver Serve order-to-cash, end-to-end process Supporting processes A single, agreed-upon structure with a defined level of detail
02Conventions & BPMN

A binding modeling convention.

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

What you get: Modelsthat are consistent across departments, with a level of quality that does not depend on the individual reviewer.
  • BPMN 2.0 Elements
  • Naming Rules
  • Review Checklist
  • Automated checks
Modeling conventionv2

How we name, draw, and publish.

  • “Check invoice”: verb plus object
  • “Invoice checking”: noun form
  • Role and system associated with each task
  • One yes/no question per gateway
  • At most 12 activities, followed by a subprocess
Applies toEvery published model
CheckedBefore approval
04Ownership & Governance

Clear accountability 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 based on 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 you get: Arepository where the published version is authoritative and up-to-date.
  • Process owners
  • Release Workflow
  • Review cycles
  • Versioning & Audit Trail
Release recordv3.2

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

DraftMarch 14
ReviewOwner and two experts
ApprovedApril 2
PublishedApril 3
Next reviewApril 2027
05Analysis & Improvement

From documentation to improvement.

Documented processes are the foundation, not the goal. We use them to compare the current and target states, prepare transformation programs such as ERP migrations—where processes and systems change simultaneously—and support standardization when the same process is carried out in several different ways. When process execution data is available, we incorporate it into the analysis rather than relying solely on the model.

What You Get: Improvementdecisions 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 organization that 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 upon rather than duplicates.

Explore the method
02

SAP Signavio

Where we implement the process layer in practice: modeling, 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, adherence to conventions, ownership coverage, and missing links to the architecture.

Request a review

Does that sound familiar?

Getting a stalled
repository back on track.

Many process repositories were created with considerable 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 modeled everything for the certification in 2021, and not much since then.”
“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 reflect how we actually work.”
“It is unclear who is responsible for most of our processes.”