Process management, integrated with your architecture.

In most organizations, processes and IT systems are documented separately. As a result, the impact of system decisions on business units often becomes apparent only at a late stage. We establish a process layer that is linked to your architecture model, so that both views are based on the same facts.

Learn More Discuss requirements
BPMN Conventions Process-Application Link

What We Do

A process landscape—
—that remains applicable.

Process repositories fail for predictable reasons: no standardized structure, no binding conventions, no clear accountability, and no connection to the systems on which the processes run. We address all four of these issues.

01Process Architecture

Structure before modeling.

Before modeling begins, the process landscape needs a coordinated structure: a process framework comprising management, core, and support processes; a process hierarchy extending down to the level at which the work is specifically described; 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 the modeling intentionally ends.

What You Get: A standardized structure into which all teams can model their work, so that processes can be identified, compared, and reused.
  • Process Center
  • Levels 1–4
  • End-to-End Processes
  • Level of detail
Management Processes Plan Buy Deliver Provide Care Order-to-Cash, End-to-End Process Support Processes A coordinated structure with a defined level of modeling detail
02Conventions & BPMN

A binding modeling convention.

The modeling convention determines whether diagrams created by different teams are comparable. We define the BPMN elements used, naming conventions, role and system mappings, criteria for subprocesses, and required attributes. The convention includes examples and a review checklist. Where the platform supports it, models are automatically validated before publication.

How You Benefit: Templatesthat are consistent across departments, with a level of quality that does not depend on the individual reviewer.
  • BPMN 2.0 Elements
  • Naming Conventions
  • Review Checklist
  • Automated Tests
Modeling Conventionsv2

How we name, draw, and publish.

  • "Check the bill": Noun plus verb
  • "Audit": noun form
  • Role and System for Each Task
  • One yes/no question per gateway
  • A maximum of 12 activities; after that, a subprocess
Applies toEvery published model
ReviewedPrior to release
04Responsibility & Governance

Clear accountability for each process.

A published model without clearly defined responsibilities is bound to become outdated. We establish process ownership with defined tasks, set up an approval workflow from draft to publication, determine review cycles based on process criticality, and ensure that the approved version is always accessible. Change requests follow a defined procedure, and all versions remain traceable for audits.

What You Get: A repository where the published version is authoritative and up to date.
  • Process Owners
  • Approval Workflow
  • Review Cycles
  • Version Control & Audit Trail
Release Logv3.2

Order-to-Cash: From Draft to Published Version.

DraftMarch 14
ReviewThe owner and two experts
PublishedApril 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 state with the target state, to prepare for transformation projects such as ERP migrations—where processes and systems change simultaneously—and to support standardization when the same process runs in multiple variations. Where process execution data is available, we incorporate it into the analysis rather than relying solely on the model.

How You Benefit: Improvementdecisions based on the documented landscape and, where possible, measured process data.
  • Actual vs. Target
  • Variant Analysis
  • Transformation Support
  • Process KPIs
Five documented variations of the same process Target Process coordinated, responsible for and measured

How It All Fits Together

Processes are part
of architecture.

We treat the process level as a view of the same organization that your architecture model already describes. The same objects, the same responsible parties, the same governance.

01

EA Practice & Methodology

The metamodel, the accountability model, and the governance framework, upon which the process layer is built rather than duplicating them.

View Method
02

SAP Signavio

Where we put the process layer into practice: modeling, collaboration, publishing, and integration with your architecture platform.

View Platform
03

A review of your repository?

A focused review of your process landscape: structure, adherence to conventions, coverage of responsibilities, and missing links to the architecture.

Request an Exam

Does this sound familiar?

Reactivate a dormant repository at
.

Many process repositories were built with considerable effort and then gradually abandoned. In most cases, the causes are structural in nature and can be resolved without having to start from scratch.

Talk to our process experts
"We modeled everything for certification in 2021; not much since then."
"Three departments document the same process in three different ways."
"No one can tell us on which systems this process is running."
"The published models no longer reflect the way we work."
"For most processes, it is unclear who is responsible for them."