3. Success factor for practically effective process orientation - Process documentation as a means to an end for effective process orientation

In the fourth part of our blog series, "7 Success Factors for Sustainably Effective Process Orientation," we focus on the third success factor: user-oriented process documentation and process modeling. Together with Christian Sennewald (Lead Consulting Digital Transformation at Aeneis partner SHD System-Haus-Dresden GmbH), who has supported numerous clients on this very topic, we explore the success factor of "user-oriented process documentation and process modeling." To achieve the goal of an efficient customer focus, stable, compliant, and economically managed processes are of central importance—as are graphical modeling and documentation.

The fourth part of our blog series is therefore dedicated to the third success factor for sustainably effective process orientation: "User-oriented process documentation and process modeling." This success factor centers on the following questions:

Were the processes developed, agreed upon, introduced, trained, and practiced with representatives of all stakeholders and with clear goals?
Are the process diagrams easy to create and easy to understand?
Do they use simple conventions, focus on clarity, and provide information tailored to the target group and purpose?  
Are target groups supported through personalized views of processes and networked information?

As part of a seven-part series, we will discuss all seven success factors for sustainably effective process orientation in more detail every two weeks.

Overview of previous parts of the blog series: 7 Success Factors for Sustainably Effective Process Orientation:

• Part 1: 7 Success Factors for Practically Effective Process Orientation
• Part 2: 1. Success factor for practically effective process orientation – Defining process management goals and a future vision
• Part 3: 2. Success factor for practically effective process orientation – Clear customer and stakeholder focus via graphical process landscapes

Process documentation – The purpose alone determines the means

For many, process orientation simply means aligning with a defined business process, but for us, the potential goes far beyond that: as a target vision, process orientation embodies an efficient customer focus. Processes deliver services that are stable, compliant, and economically managed, delighting internal and, above all, external customers. A defined and agreed-upon process documentation is an essential means to this end.

However, processes only become alive and effective when the responsibilities for execution and management are embraced by everyone involved. This requires agreed-upon roles for process owners that are anchored in the organization and aligned with line management responsibilities. It also requires clear goals and priorities for processes, accessible and visible to everyone in a process map. Agreed-upon, simple conventions and BPM software that meets requirements and can scale with growth accelerate further implementation. A role concept linked to positions and organizational units, along with connected documents and IT systems/transactions to be used, helps everyone involved live out the processes and responsibilities. On this basis, processes can be effectively defined through to practical implementation and, most importantly, continuous improvement.

The following perspectives are helpful for process documentation:

What is the goal of the process documentation?

When looking at the target vision of your "process project," the focus is often on establishing a shared understanding of processes for upcoming IT support. It is crucial to determine whether the target system is standard software (e.g., ERP, CRM, or PLM) or if the process is being implemented in a customer-specific way, such as via a workflow engine.

In the first case, the goal is usually to harmonize process variants to reduce effort, often using reference process models that are reviewed against your own requirements. The "altitude" can vary significantly: from very granular individual tasks and transactions close to system usage, to end-to-end processes that also map tasks and decisions that are necessary but not—or only partially—supported by the system.

In the second case, how processes must be modeled depends heavily on the target platform. The spectrum ranges from simple, business-oriented BPMN processes that are enriched in the target system to become executable workflows (including interfaces and forms), to no-code or low-code solutions where the executable process is created during modeling (such as with our BPM|Flow solution), all the way to "full BPMN modeling."

Cases 1 and 3 require IT specialists to lead the technical implementation of the process in the respective target system in collaboration with the business department. In any case, the business process should be modeled as simply as possible and be easy to understand.

To achieve this, methods can be applied that separate the business process description from the technical description and, consequently, the IT-specific solution. Examples include working with "black pools" or "collapsed sub-processes," which represent a technical implementation in a SCIL layer (Service Contract Implementation Layer) and can, for instance, map different implementation variants per location. This Process Driven Architecture (PDA) approach promises efficient and effective software development, but it requires consistent implementation of methodological requirements and the use of BPMN notation.

Which "language" with which conventions makes sense and when?

The following requirements should be met:

1. Consistent and uniform representation of processes across all required levels
2. Easy to read and understand for the core target groups
   1. Process users/process teams (as a reading/comprehension aid for process execution)
   2. Process modelers and process management consultants (for modeling and IT implementation)
   3. Process owners and process managers (for approval, support, and control)
3. Simple and rapid development of modeling capabilities to build the process model

These requirements are best met by a significantly reduced symbol palette based on the BPMN 2.0 standard from the OMG (ISO/IEC 19510:2013). It is already taught today as part of training and university studies and is supported by all relevant systems with standard interfaces.

In our process workshops, we establish the necessary foundations using flipcharts and sticky notes, which then serve as our visible convention. Once the tools and the simplified symbol palette are understood and practiced, sticky notes aren't the only option for workshops. Reusable shapes are also well-received during creative sessions. Their great advantage lies in their durability and the ability to write on them. In a dynamic workshop setting, individual tasks are very often moved from swimlane to swimlane, and task names are frequently refined more than twice to build a shared understanding—and that is a good thing!

Once the tools and the simplified symbol palette are understood and practiced, sticky notes aren't the only option for workshops. Reusable shapes are also well-received during creative sessions. Their great advantage lies in their durability and the ability to write on them. In a dynamic workshop setting, individual tasks are very often moved from swimlane to swimlane, and task names are frequently refined more than twice to build a shared understanding—and that is a good thing. As an example of reusable shapes, we recommend the moderation kit from ProBoard, available at www.proboard.de.

How are processes surveyed and who is involved?

We distinguish between the following fundamental approaches, which serve different purposes and require different prerequisites. Depending on the goals and conditions, we differentiate between the classic "improve as-is processes" path and the solution-focused "develop to-be processes" path.

In the first case, processes are recorded and visualized through interviews or workshops with the participants. Then, weaknesses are systematically identified and evaluated based on their optimization potential. Improved to-be processes are developed and documented with implementation measures. If relevant data is available, this variant replaces the fact-based as-is process survey with process mining, and the process begins with a workshop discussion to improve goal-aligned variants.

The interview method is often problematic for process surveys because the interviewer's perception, perspective, and interpretation can lead to unnecessary loops or a falsely assumed shared understanding. In well-moderated workshops, conceptual and technical clarifications happen continuously, which usually leads to a shared perspective and a common understanding of the process. Generally, as-is survey methods focus on "deficiencies" and identify errors, problems, or risks, even when the discussion is framed as identifying potential for improvement. As a result, participants often feel there are "culprits," and it is not uncommon for them to defend why something was or still is necessary. While clear communication about changed goals and framework conditions can "alleviate" this, a strong solution focus is rarely achieved.

Goal-focused to-be process workshops

When facing significantly changed and demanding goals, and provided there is an existing understanding of the process, a to-be process can be developed creatively directly in a workshop. Starting from the end of the process, the workshop asks what each role must deliver in the preceding activity to ensure the successor can work effectively. In this way, existing routines are reflected upon rather than simply continued. This shifts the conversation toward goal-aligned solutions rather than problems.  

How are process interfaces coordinated?

Ideally, the process landscape has been developed top-down, as we explained in our second blog post. You can see the three most popular process maps from practice here. If the work was done systematically, the responsibilities for processes and the respective upstream and downstream processes, along with their owners, should be clear. If not, a method from Lean Six Sigma can provide clarity: the"SIPOC" model. In this model, information is compiled according to the following pattern:

S … Supplier > I … Input > S … Pro­cess > P … Out­put > O … Cust­o­m­er

In process documentation, the SIPOC model also provides a very simple and clear representation for processes at the next level down in the process model, especially when separate processes are required for reasons of independence or control. SIPOC is also a useful tool for mapping, aligning, analyzing, and optimizing end-to-end process chains. In the first step, interfaces (start/end events, inputs/outputs, quality, or service levels) can be clarified and agreed upon; these often represent quick wins for your process project.
The method is highly flexible and can even be used for detailed alignment between different functions at the task level.

As part of an overall approach, many of the aforementioned topics are developed and described in the company-specific BPM governance (Phase 4) for the subsequent process definition (Phase 5) in the process documentation.

Modeling, implementing, and executing processes

Once a process has been captured using the methods or approaches described above, the next step is to model it in a suitable tool. This is where the questions usually start in most projects: Where and in what format should the process be stored? Suggestions from workshop participants range from  

"Let's just save the photo of the whiteboard on the intranet or file system"

to

"I'll have time later to quickly transfer it into Visio and save it in the central document management system"

The latter would be the better choice compared to the alternative. However, when selecting a tool for process management, you should look for the following features:

• Use of a database-supported system to be able to evaluate the documented properties
• Simple tool support during the modeling phase. Tabular entry options for the process. The model (the graphic in BPMN format) is generated live "on the fly." With graphical modeling, an auto-layout feature ensures maximum productivity, just as selected process activities can be converted into a sub-process with a single mouse click. You should also ensure that supporting documents, IT systems, and roles can be selected directly from master data.  
• The ability to capture different scopes should be available. After all, the onboarding process at the corporate headquarters in Germany will likely be completely different from onboarding at the project office in Taiwan.
• An automatic and flexible layout and display option is important. Nowadays, no one has the time or inclination to manually draw arrows and connections or align individual shapes. Additionally, at the design stage, it is often not yet clear from which perspective the process model should be viewed. Is the focus on operational responsibility or the IT systems being used?
  The previous images illustrate this situation. It is the same process; however, the layout was changed at runtime between the two images using an auto-layout feature with a single mouse click. Switching between horizontal and vertical layouts is also frequently requested and can be done with a click. You can also choose to display relevant documents alongside the actual process steps.
• Evaluability – Another important aspect of process management is reporting functionality. Process management only truly comes to life with flexible query options and dynamic visualizations of relationships. Up until that point, we are just talking about process models documented in a fancy tool. But let’s be honest… everyone has heard the question, "Which processes are affected if system XYZ goes down?"

And this is exactly where operational process management begins. In a figurative sense, our customers reach into a black box called a "process-oriented integrated management system" and grab the relevant object. This could be "IT System XYZ" or a role, a person, a process, or a document. When you pull this object out of the black box, you can clearly see which other elements are linked to it and "attached." The interconnection of elements and the flexible reporting functionality are cornerstones for further building blocks that rely on active processes. Whether it’s business continuity, information security, audit management, or continuous process improvement: we offer suitable extension modules for all scenarios with the Aeneis BPM suite as a platform for your process-oriented digitalization. Introducing and executing processes also thrives on clear goals and benefits for the target groups. Easy to understand and tailored to the individual user through personalized views, process information helps with onboarding, covering for colleagues, or navigating rare, complex, or changed processes that are better found quickly than executed poorly. And perhaps the next step is a human workflow that further supports and relieves the users. Beyond good processes and a good BPM tool, all of this requires process owners who support and monitor process introduction and execution, implement process control, and analyze and improve process performance with the stakeholders in the event of deviations.

Recommendations for effective process modeling

The following best practices can be summarized from our projects and experience:

• Clarify the assignment and align the roles involved using an agreed-upon process profile.
• Capture processes in workshops with representatives from all involved roles.
• Align the level of detail with the target group and the purpose:
  • For a skilled worker, it is not necessary to document how to drill a hole. However, with varying qualifications and high turnover (e.g., onboarding in call center processes), more details are helpful.
  • For a digital workflow, details and attributes are mandatory,
    while for an agile development process, broad tasks, roles, and artifacts are sufficient.
• Use meaningful, real-world start and end events to link processes end-to-end.
• Use a noun + verb style for naming activities (a conscious linguistic shift to reduce confusion with functions).
  • Examples: "Brew coffee," "Check materials."
• Model in a structured and clear manner.
  • Use branching and merging gateways in pairs (to "bracket" a section).
  • Keep the number of incoming/outgoing arrows per element to a minimum; it is better to insert multiple gateways.
  • Break down models that are no longer legible when printed on A3 into collapsed sub-processes.
• Link relevant supplementary information and mandatory IT systems, inputs/outputs, etc., to the corresponding activities.
• Avoid the inclusive OR and specialized BPMN shapes – instead, work reliably with 8-10 BPMN elements.

The last point in particular easily leads to misunderstandings and errors or overwhelms readers. Modeling specifics for a BPMN engine should only be implemented for the usually small target group that requires them on a regular basis.

Best practices on our blog

For each of the 7 success factors, I will be presenting "best practices" in a series of follow-up posts together with colleagues from Intellior and our partner network. These practices are supported by the Aeneis BPM platform from Intellior and will help you achieve effective process orientation. We look forward to your comments, discussions, and experiences.