Why Stages is Different

Focus On Knowledge Work

It is easy to think all processes are the same and therefore should be modeled with the same notation and within the same tool. After all, standards such as BPMN exist, and applying those standards broadly makes sense on the surface. However, UL Solutions takes a different approach.

We see fundamental differences between typical business processes, such as order processing, and value creation processes such as a product development process (PDP) or software development, which are widely characterized as knowledge work.

The table below 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 have been 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 when modeling engineering processes

Even with all the above concepts 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 for the reuse of 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 due to its technical nature. Stages helps ease understanding for knowledge workers, because we know people will continue to be the primary execution driver in value creation processes, even in fully digitized environments.

Important features for knowledge work

With their inherent characteristic that “process diagrams are the process,” typical BPMN-based tools lack capabilities which model-based tools such as Stages can offer.

Multiple perspectives: Rather than 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 fewer process details than new users, but they need to quickly access the information important for them.

Variance: Every development program or project is different, so execution teams should be able to derive their specific processes from a set of standard process templates that can be customized, ideally within a set of by rules or constraints. The resulting project-specific processes should be version-controlled and further adjustable through detailed tailoring. Even if this level of specificity is not applicable, standard product development processes typically have several variants. For example, 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 help ensure all regulations are still being followed, even after tailoring the process.

Experience the difference

Excellence in value creation is the primary differentiator for most organizations. Businesses with innovative and attractive products typically win over their competitors in the marketplace. With a focus on knowledge work and a process management tool such as Stages, you can:

• Support high creativity knowledge work processes through human-friendly notation
• Embrace change through variant management and process tailoring
• Manage compliance to standards and regulations across all programs, projects, and teams