Technical Lead & BPMN Educator·14 min read
Why process governance matters
Every organization has process documentation somewhere. SharePoint folders, Confluence pages, Visio files on a shared drive. The problem is rarely that documentation does not exist. The problem is that nobody maintains it.
After a few months, diagrams drift from reality. People invent workarounds that never make it back into the model. New hires read the documented process and then learn that "we do not actually do it that way." The documentation becomes a liability: it gives auditors and leadership a false picture of how work gets done.
Process governance is the set of roles, rules, and rituals that prevent this decay. It answers four questions:
Who is accountable for each process?
How often does each process get reviewed?
What happens when a process changes?
How do you know which processes need attention?
If you cannot answer these questions today, you do not have governance. You have a collection of diagrams.
The three pillars of process governance
Governance frameworks can get complex fast. Consultancies sell multi-layered models with steering committees, center-of-excellence charters, and RACI matrices for every decision. Most of that collapses under its own weight in organizations that do not have a dedicated BPM department.
A practical governance framework needs three pillars, no more:
1. Ownership
Every process has a named owner who is accountable for its accuracy, performance, and improvement. Ownership is assigned at the process group level (L1), not at the individual diagram level.
2. Review cycles
Processes are reviewed on a regular schedule. The frequency depends on how fast the process changes and how critical it is. Review produces a verdict: confirmed, updated, or flagged for redesign.
3. Maturity tracking
Each process is rated on a maturity scale that tells you where to invest. A process that is undocumented needs modeling. A process that is modeled but never reviewed needs governance. A process that is reviewed and measured is ready for optimization.
Pillar 1: Process ownership
What a process owner actually does
The process owner is the person who can answer "why does this process work this way?" and "what should change?" They are not necessarily the person who performs the process. They are the person accountable for its design and performance.
In practice, a process owner has five responsibilities:
Accuracy
The documented process reflects how work actually happens. When the process changes, the owner ensures the documentation is updated.
Performance
The owner tracks whether the process meets its objectives. This can be simple (cycle time, error rate) or qualitative (stakeholder satisfaction). The point is that someone watches.
Improvement
When performance gaps appear or when the business context changes, the owner drives redesign. They do not do the redesign alone, but they own the initiative.
Compliance
For regulated processes (ISO, SOX, GDPR), the owner ensures the process meets its control requirements and that evidence of compliance is maintained.
Communication
When a process changes, the people who perform it need to know. The owner ensures changes are communicated, not just modeled.
Process owner vs. process steward vs. process modeler
These roles often get conflated. Keeping them distinct prevents confusion:
| Role | Focus | Typical person |
|---|---|---|
| Process owner | Accountability for process performance and design | Department head, senior manager |
| Process steward | Day-to-day maintenance of documentation | Business analyst, team lead |
| Process modeler | Creating and updating BPMN diagrams | BPM analyst, consultant |
In smaller organizations, one person may fill all three roles. That is fine. The important thing is that the responsibilities are acknowledged, not that separate people hold each title.
How to assign owners
Ownership works best when assigned at the L1 (process group) level of your process landscape. Each L1 group gets one owner. That owner is accountable for all L2 processes within the group.
The wrong approach: assign ownership at the individual diagram level. With 50+ diagrams, ownership becomes unmanageable. People lose track of which diagrams they own, and orphaned diagrams appear within months.
The right approach: the L1 "Order Processing" group has one owner who is accountable for all five diagrams inside it. When a new diagram is added to the group, it automatically inherits the group owner.
"Do not assign process ownership as a side responsibility without adjusting workload. If someone owns 15 process groups "on top of their day job," governance will not happen. Start with the 5 most critical process groups and assign owners who have actual capacity to review them quarterly."
Pillar 2: Review cycles
A process review is a scheduled check where the process owner and relevant stakeholders confirm that the documented process still reflects reality. It is not an improvement workshop (though it often surfaces improvement ideas). The primary goal is accuracy.
Setting the review cadence
Not every process needs the same review frequency. A high-volume, fast-changing process (customer onboarding at a startup) needs quarterly review. A stable back-office process (fixed asset accounting) might need annual review.
| Review frequency | When to use | Example |
|---|---|---|
| Quarterly | High-change, customer-facing, or recently redesigned processes | Customer onboarding, lead qualification |
| Semi-annual | Moderate-change processes, cross-functional handoffs | Order fulfillment, incident management |
| Annual | Stable, well-established, low-risk processes | Fixed asset accounting, payroll processing |
What a review looks like
A process review is a 30 to 60 minute meeting with a clear structure:
1. Walkthrough
The process owner walks through the current documented process with the people who perform it. "Is this still how we do it?"
2. Delta identification
Participants flag where reality has drifted from documentation. New tools introduced, steps skipped, handoffs changed, workarounds invented.
3. Verdict
The review produces one of three outcomes: Confirmed (documentation matches reality), Updated (changes noted and assigned for modeling), or Flagged (the process needs redesign, not just a documentation update).
4. Action items
If updates are needed, assign them to a modeler with a deadline. If the process is flagged for redesign, it goes into the improvement backlog with a priority.
The version history trap
Reviews produce changes. Changes need to be tracked. Without version history, you lose the ability to answer "what changed, when, and why?"
This is where many teams struggle. If your process documentation lives in files on a shared drive, versioning is manual and error-prone. You end up with "Order_Processing_v3_FINAL_FINAL_reviewed.bpmn" and nobody knows which version is current.
A tool that tracks version history automatically removes this burden. Every save is a version. Every version has a timestamp and an author. You can compare any two versions to see what changed. Read our guide on process documentation best practices for more on keeping documentation current.
Pillar 3: Process maturity tracking
Maturity models tell you where each process stands and where to invest. The classic CMMI model has five levels, but most organizations need something simpler. Here is a four-level model that works in practice:
Level 1: Ad hoc
The process exists but is not documented. People do it from memory or habit. Knowledge lives in individual heads. If the person who knows the process leaves, the process breaks.
Level 2: Documented
The process is modeled in BPMN (or another notation) and accessible to the team. There is a shared understanding of how work should flow. But nobody checks whether reality matches the documentation.
Level 3: Governed
The process has an owner, is reviewed on a schedule, and changes are tracked with version history. The documentation stays current because someone is accountable for it.
Level 4: Measured and optimized
The process has performance metrics (cycle time, error rate, cost per transaction). The owner uses these metrics to drive continuous improvement. Changes are data-informed, not opinion-driven.
Using maturity to prioritize
Rate each L1 process group on this scale. The result is a maturity heat map that shows where your governance gaps are. The priorities are usually obvious:
Critical processes at Level 1 (ad hoc): immediate documentation needed.
Customer-facing processes at Level 2 (documented but not governed): assign owners and start reviews.
Regulated processes below Level 3: compliance risk. Fix first.
High-cost processes at Level 3: ready for Level 4 metrics and optimization.
"Do not try to bring every process to Level 4. That is neither realistic nor necessary. The goal is to bring critical processes to Level 3 (governed) and selectively invest in Level 4 for processes where optimization yields measurable business impact. A healthy portfolio has processes at every maturity level."
Implementation roadmap: 90 days to working governance
Governance does not require a multi-year transformation program. You can have a working framework in 90 days with three phases:
Days 1 to 30: Foundation
- 1.Build or validate your process landscape (L0 and L1 structure).
- 2.Assign process owners for the 5 to 10 most critical L1 groups.
- 3.Rate each L1 group on the maturity scale (ad hoc, documented, governed, optimized).
- 4.Choose a tool that supports ownership, versioning, and review tracking natively.
Days 31 to 60: First review cycle
- 5.Run the first review for each of the 5 critical process groups.
- 6.Document review outcomes (confirmed, updated, flagged).
- 7.Update documentation for processes that drifted.
- 8.Move flagged processes to the improvement backlog.
Days 61 to 90: Scale and sustain
- 9.Extend ownership to remaining L1 groups.
- 10.Set review cadence (quarterly, semi-annual, annual) per group.
- 11.Publish the maturity heat map to leadership. Use it as the basis for investment decisions.
- 12.Schedule the next review cycle. Governance that runs once is not governance.
Common mistakes
Mistake: Governance by committee
A steering committee that meets monthly to "review process governance" produces meeting minutes, not governance. Ownership must be individual and specific. One name per process group, not a committee.
Mistake: Treating governance as a project
Governance is a continuous practice, not a one-time initiative. If you staff a governance "project" with a start and end date, governance will end when the project does.
Mistake: Ownership without authority
A process owner who cannot request changes to systems, staffing, or procedures is a process documenter, not an owner. Ensure owners have the organizational mandate to act on review findings.
Mistake: Reviewing for compliance only
If reviews only check whether documentation exists (for ISO audits, for example), they become checkbox exercises. Reviews should verify accuracy, not just existence.
Mistake: Skipping the landscape
Without a process landscape, you cannot assign ownership systematically. You end up with some processes owned, others orphaned, and no way to see the gaps. Build the landscape first.
The role of the process excellence lead
In organizations with more than 20 process groups, someone needs to own the governance framework itself. This person does not own individual processes. They own the system that ensures all processes are owned, reviewed, and tracked.
This is the process excellence lead (sometimes called the BPM center of excellence lead, head of process management, or chief process officer in larger organizations). Their responsibilities include:
Maintaining the process landscape and keeping it current.
Ensuring every L1 group has an assigned owner.
Tracking review completion rates and following up on overdue reviews.
Publishing the maturity heat map and reporting to leadership.
Setting modeling standards (notation conventions, naming rules, level-of-detail guidelines).
Coaching process owners who are new to the role.
For more on the skills and career path of this role, see our guide on process consultant skills and becoming the process expert.
Choosing a tool that supports governance
A governance framework is only sustainable if your tool supports it. If assigning owners, tracking versions, and scheduling reviews requires manual effort outside the modeling tool, governance becomes overhead that people skip.
Look for these capabilities:
Process ownership assignment at the group level, visible in the landscape.
Automatic version history with timestamps and change attribution.
Review status tracking (last reviewed date, next review due, review outcome).
Permission controls so that only owners and authorized modelers can edit processes.
Export and sharing for stakeholder review without requiring licenses.
For a detailed comparison, take our tool finder quiz or browse all tool profiles.
FAQ
What is process governance?
Process governance is the set of roles, rules, and review cycles that keep process documentation accurate and aligned with how work actually happens. It ensures every process has an owner, gets reviewed regularly, and is tracked for maturity.
What does a process owner do?
A process owner is accountable for the accuracy, performance, and improvement of a set of processes. They ensure documentation stays current, track performance metrics, drive improvements, and communicate changes to the people who perform the process.
How often should processes be reviewed?
It depends on how fast the process changes. Customer-facing and high-change processes: quarterly. Cross-functional processes: semi-annually. Stable back-office processes: annually. Regulated processes should follow the cadence required by the applicable standard.
What is a process maturity model?
A maturity model rates each process on a scale from ad hoc (undocumented) to optimized (measured and continuously improved). It helps you prioritize where to invest in documentation, governance, and improvement.
Do I need a BPM center of excellence?
Not necessarily. Smaller organizations can manage governance with a single process excellence lead who maintains the landscape, tracks ownership, and follows up on reviews. A formal center of excellence becomes valuable when you have 20+ process groups and multiple process owners to coordinate.
How does process governance relate to ISO 9001?
ISO 9001 requires documented processes, defined responsibilities, and regular management review. A working governance framework covers these requirements naturally. The maturity model helps you identify which processes are compliant and which have gaps.
Continue reading
- Process Landscapes: From Value Chain to Detailed Processes (build the structure that governance depends on)
- Process Documentation Best Practices (how much detail to capture at each level)
- Process Consultant Skills (the skills behind effective governance roles)
- Becoming the Process Expert (career path for process excellence leads)