A new day, a new process modelling project. The project plan has been signed off, reference documentation was gathered, all stakeholders have been identified and now…now what? While process models increase in popularity and most businesses seem to agree that process models are indeed a good way of representing how an organisation creates and delivers value, there is little to no guidance on what a good process model is, how to create one and how to successfully go about executing a process modelling project.

While this guide does not claim to be a silver bullet for all your process modelling problems (look at our Modelling Excellence framework for that!), it aims to be a guide for Project Managers and BPM Professionals in every stage of the modelling journey, regardless of whether you’re just kicking off a new modelling project, are in the middle of a major project, or are just looking for a refresh. Please note that this guide does not address steps to set up or configure a process modelling tool. It is focused on the activity of process modelling.

Let’s get started!

This section includes topics that should be covered prior to kicking off any process modelling project. If a project is already underway, but struggling, we recommend revisiting this section to ensure the basics have been covered. If your project is already underway and going well, you may opt to skip ahead to the “Business Process Modelling” section.

It’s all about the purpose…

Firstly, ensure the purpose for modelling has been identified and agreed upon by all stakeholders.

Whether it is communication, training, process measurement, improvement or configuration of a workflow tool, any modelling effort must serve a purpose. Major decisions such as “What modelling tool is the right one?” as well as minor decisions such as “Should I include this detail in my model?” can easily, logically and consistently be answered once the purpose has been identified. Consequently, if a clear purpose for modelling cannot be identified, no time and money should be spent on modelling as the models would end up being waste.

The start of a process modelling project is also a good time to identify additional use cases for process models and pitch those to the stakeholders. The more use cases there are, the more robust the business case for process modelling becomes. Models that are re-used often are valuable to the organisation, rather than just useful for a one-off project.

This does not mean that creating models for one-off use is waste. Although we generally recommend maintaining and re-using process models as much as possible, there are many valid use cases for and circumstances under which organisations choose to create process models that will be deleted once the project is completed. We do however emphasise that this purpose needs to be clearly identified and agreed upon, so nobody comes looking for the model two years later and needs to then kick off another modelling project since the former models are either out-of-date or nowhere to be found.

Understanding the purpose of modelling will also help Modellers in the information elicitation and model validation stages of the project. They must always be prepared to explain what they are doing, why they are doing it and how it benefits the organisation. A strong pitch for modelling, tied back to the purpose, will help to keep stakeholders focused during workshops.

What is in scope and who is your audience?

Next, clarify what processes are in scope and who will use the models. (i.e. who the intended audience is). The project’s business case, conversations with stakeholders and an existing process architecture, if available, can provide good data points to identify processes that will have to be modelled. The scope is going to inform the number of process models required, as well as, together with an analysis of the intended model audience, the level of detail expected.

Getting to know the audience is critical to ensure process models are used after their creation. Generally, models that are used by the business should be less rigid on syntactic standards and more focused on communicating relevant information. On the other hand, models that have technical use cases (e.g. workflow automation), should adhere strictly to syntactic standards to eliminate ambiguity.

The combination of scope and audience then allows the Modeller to determine the level of detail that is required and if additional information, such as IT systems, data, KPIs or risks should be captured.

Starting the modelling journey

Prior to placing the first box on a blank canvas, Modellers must have a good understanding of existing process modelling standards and conventions.

The conventions must be fit for purpose - meaning they align with the previously identified modelling purpose, scope and audience. This is also a good time to draft a small set of conventions (if none exist) or to propose modifications to existing conventions. Depending on the tool being used, the Modeller also must identify how conventions will be enforced. This is either a manual process (if a simple tool such as Visio is used), or automatically ensured (if conventions have been implemented in more sophisticated tools such as ARIS or BIC).

What modelling tools will be used?

Speaking of tools, the Modeller needs to have a basic understanding of the tool being used. In the early stages of the project it’s sufficient to know the basics (i.e. how to place objects onto a canvas), but as the project progresses, additional skills and best practices should be learned to ensure Modellers know how to use the tool both effectively and efficiently.

Defining what quality looks like

Lastly, model quality needs to be defined to enable everyone on the project team to provide high quality models to the business. We recommend assessing models in three dimensions: semantic, syntactic and pragmatic quality. The weighting of each dimension will, again, depend on your modelling purpose. For communication, training and process improvement purposes, a process model that heavily focuses on semantic and pragmatic quality will be most useful whereas syntactic quality is not as important. If the project requires process models to be created in a sophisticated tool that allows exporting of BPMN XML files (to be used to configure a workflow tool), syntactic quality is of great importance since models that do not comply with the standard will not be able to be executed.

Note that by now not a single process model has been created (yet)!

The above is not meant to indicate that every project requires a two-week ramp-up phase before modelling can begin. It only takes a day or two to familiarise the team with the context of the project. It does emphasise that clarifying these questions in advance will save the team a lot of wasted time as well as a potentially failed project with little to no business buy-in.

Business Process Modelling

This section details the various phases in the lifecycle of a business process model - from creation to sign-off and maintenance. This section is a helpful tool for

1. new and old Modellers looking to build or refresh their skills, 
2. Architects needing to manage model quality and wanting to ensure a good approach to process modelling is selected,
3. Project Managers wanting to gain a deeper understanding of what is involved in the specific activities of a process modelling project.

Modelling 101

Following the clarification of the project’s context as described above, it is now time to create process models. Before diving into the details of any process, start by clarifying what the process does - what is its purpose and what an ideal outcome or output of the process looks like.

If the Modeller does not have subject matter expertise, this is the right time to gain a basic understanding of what the process is about by doing online research, crawling through the intranet and talking to Subject Matter Experts (SMEs). In-depth knowledge of the subject matter is usually not required. The Modeller’s task is to create business process models, not to execute the process itself. However, Modellers do need to know what questions to ask SMEs! Like the approach highlighted in this guide, we recommend gaining basic knowledge of the subject matter in terms of its purpose, scope and SME responsibilities prior to diving into the details of a specific process.

Gathering information

Modellers then need to determine how necessary information to create the process model from will be obtained. If current state processes are being modelled, analysing existing documentation such as procedure documents, workshop notes or user guides is often the first step. If future state processes are being modelled, industry best practice frameworks, potentially existing design documents and workshop notes are good sources to start with. This information can be used to draw up a rough draft of the business process model before going into workshops.

Like every business process, the model itself also will have boundaries. Identifying how the business process fits into the overall process architecture allows Modellers to easily establish the modelling boundaries, i.e. the scope of the process model. Consequently, no serious process modelling effort can be kicked off without having an architecture in place. The architecture is the only tool that can be used to consistently scope business processes and identify interfaces to other processes.

Depending on the process to be modelled, the triggers, inputs, outputs and related processes can be captured formally in scoping or IGEO diagrams – or this can be a quick, mental exercise. Whichever way it is done, properly scoping a process ensures Modellers do not get lost in the details of the process but are able to assess if their models still make sense and where possible gaps are.

Actors and factors in your process models

Next, determine the actors involved in the process and what the key steps are. If a high-level (“architecture level”) business process is being modelled, a lifecycle view of the business object that is transformed throughout the process can help to draft the model. For example, if the Modeller is looking at a purchasing process, logical steps are that a purchase order is:

1.  created,
2.  approved / rejected,
3.  modified,
4.  cancelled and
5.  closed.

We would expect to find steps and sub-processes related to all these stages in the model. Again, industry best practice frameworks can provide another good starting point to draft high-level process models.

The same approach can sometimes be taken for detailed models. Otherwise, existing documentation provides a good starting point to understand key steps of a process.

Using the initial information gathered, the Modeller can then perform document analysis on existing documentation or conduct workshops to add more detail to the process model until a draft version has been finalised that is ready to be validated. Whilst adding the detailed steps, Modellers must always apply critical thinking and common sense to ensure they do not model anything that is not part of the process.

While SMEs often describe what they do as a continuous series of activities, the Modeller must recognise the boundaries of the process and identify where an interface to a different process is appropriate. Similarly, SMEs often describe exceptions to the business process or provide other additional information that may or may not be required to be modelled – depending on the modelling purpose. Whilst adding these details to the model, Modellers can identify additional documentation that can be helpful to users, such as checklists or quick reference guides. The additional information should only be created if it helps to fulfil the modelling purpose.

The less information is available in form of existing documentation, the more Modellers will rely on workshops to elicit process information. However, even if no documentation is available, a rough draft of the business process should be created using the tips outlined above. This will help to facilitate elicitation workshops. It is much easier to start with an incorrect model that is reviewed with SMEs than to try and start with a blank page.

As the number of process models and the amount of content in each model increases, it can become difficult to keep track of all models. The top-down approach highlighted in this section ensures that no steps are duplicated and that interfaces between processes are identified early on. This is especially critical if multiple Modellers work on the same project.

Validating Process Models

All models must be validated with knowledgeable SMEs. Ideally these are experts that have existing experience in reading process models or have been identified as being supportive of the initiative. This makes the review process much faster and valuable for both the Modeller and the SME. This will reduce the number of validation iterations required.

Modellers can always expect several rounds of validation before a process model is signed off. However, beware of having too many review iterations. Looking at a process models long enough will always result in some minor changes that the SME would like the Modeller to perform. Modellers need to acknowledge that “…essentially, all models are wrong, but some are useful ”, and they need to know when a process model is good enough to serve its purpose.

If new SMEs or project stakeholders are present in the workshop, Modellers should ensure to start the session by checking on everybody’s experience in reading process models. Have they seen process models before or is a quick introduction of “How to read process models” required? A question that can be asked is: “Are you comfortable reading process models by yourself?”. Depending on the SME’s experience, the Modeller must adapt the workshop approach and either lead the workshop very tightly or take on more of an observing and facilitating role.

When reviewing process models with a different level of detail (e.g. starting with high-level architecture models and then drilling into one area to show detailed models), the Modeller must explain the different perspectives that these models represent. High-level models show a conceptual flow of the business process that often hides the underlying complexity. Detailed models show all possible paths through the process and display all interfaces to other processes.

Modellers then take SMEs through the process model by applying the same top-down approach they used when creating the model:

1. start by summarising the process,
2. identifying its purpose and key actors and steps
3. then begin the detailed step-by-step review.

If SMEs are comfortable reviewing process models by themselves, Modellers should observe their reactions to the model, encourage them to ask questions and point out inaccuracies.

To force interaction, questions can be asked such as:

1. “Do you agree with this model?”,
2. “Does this reflect what you’re doing?” or
3. “What is this model missing?”

Other content-specific questions are useful too, depending on the process being reviewed. Not every piece of feedback will be incorporated into the model. (such as the SME is talking about a recent one-off exception to the usual process flow). Modellers must always ensure to highlight what they are doing with the feedback. Failing to trace SME feedback to changes in the model will quickly demotivate SMEs as their comments do not seem to be used.

Modellers might find themselves in a situation where SMEs request to be sent process models to review them in their own time (i.e. provide commentary via hand-written notes or email). This approach is not recommended - with face-to-face review workshops the preferred feedback mechanism. Including SMEs in workshops and holding them accountable to review the models in person will be much more successful. A lot of time will be saved by responding to questions in real time and observing their reaction to the process model rather than trying to decipher handwritten notes or exchanging a string of emails. Comments provided during the workshop can provide valuable input into the modelling effort and provide a new perspective on a process. Specifically, how it is executed and where the model can be clarified to be easier to understand.

Sign-Off and Handover

Process models are finalised once sign-off from the appropriate party has been obtained. This can be the SME, their manager or a third party that was not involved during the validation process. Sign-off indicates that the business accepts the process model and confirms that they are accurate, up-to-date and fit-for-purpose. It also marks handover of the deliverable to the business.

Sign-off can be obtained verbally, electronically or literally by signing the printed process model. What level of sign-off is required highly depends on the overall modelling governance, the trust in the Modelling team and the modelling tool. Whilst the sign-off is a critical milestone, it should not be tedious to obtain sign-off. At this point, it is expected that the model is accurate and can be used by the business. Sign-off validates this but should not take so much time that models cannot fulfil their use cases.

Once models have been signed off, they can be published to the business if desired. Models can be published as soon as they’re ready, or in batches (e.g. once a section of the process architecture has been finalised). What approach is best again depends on the modelling purpose and the context of the project.

Maintaining Process Models

Maintaining process models post project completion is crucial to ensure models are used continuously by the business. Letting models become outdated is a sure path to making them irrelevant and losing most of the return on the modelling effort.
Models can be either maintained by a central organisational unit (a centre of excellence) or by the business themselves.
The latter (identifying business representatives to manage process models) is preferred because:

1. it builds BPM capability across the organisation,
2. ensures changes are performed as soon as the process changes in real life and
3. moves responsibility over to the business to encourage their buy-in and ongoing commitment.

Those representatives will of course have to be trained in process modelling (maybe starting with this guide?). A strong governance process should be in place to ensure centrally determined process modelling conventions are adhered to across the organisation. 

In this context, each Process Owner is responsible for ensuring their process models are kept up-to-date and relevant. However, they do not need to implement any updates themselves. Process models are key for Process Owners’ ability to execute the Target-Measure-Respond cycle. Understanding what it is that they own and how their process works is a necessary pre-requisite for the design and implementation of relevant metrics. The Process Owner ensures that responsibilities for reviewing and updating process models are clearly defined and they are likely to be the ones to provide the final sign-off. They should also trigger updates to process models when a process change was initiated and/or implemented.

Modelling Workshop Tips and Tricks

When modelling processes, Modellers should ensure that their models represent true business processes. If process models are used in IT system implementation projects, detailed steps in the systems are often mixed with steps outside of the system, creating a confusing picture of the business process and leading to inability to easily identify key steps in the process. Separating detailed, pure system-related steps from business activities such as approval steps or other decision points, assures that users can make sense of the models.

Process models must capture the complete business process to achieve good semantic quality. When talking about their work, SMEs tend to skip certain parts of the process that have become obvious to them. Modellers must always apply common sense and critical thinking to models to detect these gaps and cross-reference maps of similar process to check for missing steps. Another common error is to only capture the “happy path” of a business process.

Depending on the modelling purpose, Modellers will have to explicitly ask about and capture possible exception and error paths. However, beware of trying to capture every possible path in one map. This will likely lead to a confusing, spaghetti-like model that is not useable. If there are many possible paths, creating multiple models or revisiting the scope of the model can make sense.

While we are all enthusiastic about BPM and process modelling, the same cannot be expected of SMEs. Negative experiences in the past, high amounts of simultaneously occurring changes or simply uncertainty of what a modelling project is about can cause SMEs to have a negative view on modelling.

Whether deliberate or unintended, this negative view jeopardises modelling efforts as the information provided by SMEs will be of poor quality and information capture will likely take a longer time. Modellers can look at common change management techniques to help solve this problem, (e.g. being clear on the SME’s “what’s in it for me”) but there is no one-size-fits all approach.

Depending on the organisation, collaborative or authoritative approaches may work better. Regardless of the approach chosen, this problem must be resolved.

Conclusion

Process models are a great way of representing how value is created, accumulated and delivered within an organisation. They are easy to read and have become invaluable tools for business process improvement, user training and workflow system configuration projects. Well done process modelling sustainably creates value for the organisation. However, the time and cost intensive nature of a process modelling project requires a deep understanding of the modelling purpose. Too often, organisations spend vast amounts of money on process modelling, only to stop projects halfway through and lose most of the return-on-modelling.

This guide aims at ensuring this does not happen. By employing the techniques and methods mentioned in this article, Modellers will produce high quality process models that are not just useful, but valuable to the business.