Why Stages is different
FOCUS ON KNOWLEDGE WORK
Some people are tempted to think that all processes are the same and therefore should all be modeled with the same notation and within the same tool. After all, standards like BPMN exist, so why not use it everywhere?
In our view, there are fundamental differences between typical business processes like order processing and value creation processes like a product development process (PDP) or software development, which are widely characterized as knowledge work.
The below table describes our findings.
NOTATION FOR KNOWLEDGE WORK
Stages adopts what we consider general best practices from BPMN:
- Modeling process activities in swimlane diagrams with the lanes representing different responsibilities or systems
- Support for process hierarchies of arbitrary depth via subprocesses
- Data objects to represent process results
- Conditional process flows via decisions and gateways
Knowledge work extensions for BPMN have been proposed several times, but none of them was ever adopted.
Stages implements the following concepts we consider critical for knowledge work processes, but are missing from BPMN:
- Value streams to capture the high-level outcomes and work products during value creation
- Guidance (practices, work instructions, tool descriptions, etc.) to describe not only WHAT needs to be done, but HOW it should be done
- Mappings to reference models and standards describing WHY certain activities need to be executed
- Roles and teams plus their required skills that are responsible, accountable, supporting, to be informed, or to be consulted in activities of a process (RASIC or RACI)
- Metrics and work product quality levels to express and measure the progress of a process and determine if its outcomes were achieved
- SIPOC (supplier, inputs, process, outputs, customer) tables to describe the interfaces and dependencies between different processes
- Lifecycles modeled as phases and milestones to express execution timing and program progress across multiple functions, disciplines, and processes
- Entry and exit criteria describing the conditions for the start or conclusion of processes, which is especially important for agile and other highly iterative processes
- Templates, checklists, and examples to increase the quality of process outputs and work products
FOCUS ON SIMPLICITY
Yet, with all the above powerful concepts being included, Stages still concentrates on providing WHO should do WHAT, WHEN, HOW, and WHY in a single consistent metamodel. The separation between WHAT and HOW is especially important for the definition of knowledge work, because it allows to reuse processes in different environments with variance in practices, tools, or metrics.
From an end user standpoint, BPMN is often described as complex to understand, mainly through its technical nature. Stages aims towards processes being easy to understand and follow by knowledge workers. People will continue to be the primary execution driver in value creation processes, even in fully digitized environments.
FEATURES FOR KNOWLEDGE WORK
With their inherent characteristic that “process diagrams are the process”, typical BPMN-based tools lack capabilities which truly model-based tools like Stages can offer.
Multiple perspectives: instead of just showing a static diagram, Stages can automatically visualize the process from different perspectives. For example, Stages can display all processes where a specific role is involved, or show all work products relevant for a specific milestone across multiple process disciplines. Different users need different levels of detail. Experienced users need less process details than newbies, but they need to get quickly to the information important for them.
Variance: every development program or project is different, so the execution teams should be able to derive their specific processes from a set of standard process templates and tailor them to their needs, ideally guided by rules and constraints. The resulting project-specific processes need to be version-controlled and further adjustable by detailed tailoring. Even if this level of specificity is not applicable, standard product development processes typically have several variants, e.g. if products are critical regarding functional safety and cybersecurity or not.
Compliance: almost all non-trivial products are subject to standards and regulations, not only for the resulting product, but also the process of how it was designed and developed. All requirements of a multitude of standards and regulations need to be traceable to activities, work products, and other elements of a process. This allows gap analyses on the project’s defined processes to make sure that all regulations are still being followed, even after tailoring the process.