Many companies have recognized the benefits of business process management (BPM) lately. They understand how BPM, by ensuring process efficiency, can support the achievement of defined business goals and contribute to the overall success of an organization.

Most of these companies document their processes in one way or another. Even though it’s done with the best intentions, these BPM artefacts are often not fully utilized.

Why is this the case?

Current State – what can go wrong?

Because business process modelling is at the heart of process efficiency and quality  improvement projects, its quality and relevance are important to ensure their success.

Many business process modelling work packages deliver models with no clear governance strategy in place. In the absence of guidance from the governance strategy, process models can be created without understanding the process architecture, which leaves them with no clear context. The models tend to be updated with no clear responsible party who understands the impact of the changes made. Changes are approved by stakeholders that do not own the process – this can lead to models that are redundant, and re‐modelled instead of maintained.

In some organizations, the operations suffer  from  ‘change  fatigue’  due  to  the  lack  of  process governance; process improvement initiatives keep altering the day‐to‐day operations, with possible unintended negative impacts downstream. These changes might be good for the organization; however, in some cases, they are too frequent and, due to the lack of visibility, are not well planned.

The lack of clear communication and visibility within created models, in many cases, cause the organization to re‐work process models that could have been used. Some organizations, therefore, lose the benefits of having a well‐structured process repository to support the reusability of existing process information.

Due to project time constraints, many neglect to plan around process modelling. Project designers do not spend enough time understanding the techniques that should be used, the notation  that  best supports the outcome, or the stakeholders for whom the information is intended.

The long‐term goals of the process models are sometimes overlooked for short‐term gains  within portions of the process.

The drafted models are sometimes captured in an area where not all stakeholders have  access  to material. Having models on paper, or a non‐relational database tool, is a manual and intensive exercise for project stakeholders to review these models and leads to them not being utilized to  their  full potential. In these cases, models are often used for a project once and then become ‘shelf ware’.

Future State – possible solutions

Technique/Approach

First, it is really important to understand the overarching goal to be achieved through (process) modelling. The overall modelling setup and preferred notation depends on the desired outcome. If the overall enterprise architecture (EA) is within focus, one  might  consider  a  wide  range  of  models  that cover all relevant areas of the enterprise: business, application, information  and  technology architecture. The notation – whether it’s  pure  data  modelling,  UML,  ArchiMate,  or  something  else  – must be suitable to capture all related artefacts.

Alternatively, if BPM is within focus, other topics might become more relevant, such as the level of detail applied when modelling. If process models are supposed to support the generation of job descriptions, a level of detail is required that allows the mapping of application systems, as well as the input and output to specific process steps. This would include supporting information (such as templates and guidelines) that could, indeed, be linked to the actual documents where a process‐mapping tool is used. Similarly, if the process models are to be used to generate  test  cases,  they  would  be  modelled  in  two  levels  of detail: one for a general overview and understanding, and a lower one to allow specific testing of the various states of a process.

A top‐down modelling approach is highly recommended to clearly define the process architecture and to ensure a consistent levelling. A clearly defined and communicated process hierarchy ensures a proper structure not only of the process models, but also of the overarching database structure that, ideally, mimics the process levelling.

It is also recommended to set up a modelling competence center whose main focus is to define and communicate the agreed standards – it is critical that the stakeholders, for whom  the  models  are created, can easily understand the crafted models. The correct notation ensures easier participation.

Governance

It is essential that process accountability is understood and accepted. There is nothing worse  than spending an enormous effort to build a consistent process hierarchy, model all relevant data, align the architectures in focus, only then to walk away without ensuring this work will be reviewed and kept up‐ to‐date.

It is expensive and poor practice to remodel business process due to outdated processes. This results in stakeholders losing faith in the method and becoming less interested and participative. To ensure that this is not the case, process owners need to be  defined and held  accountable for looking after their processes (e.g. as part of their personal KPIs). Again, the more the processes are utilized and embedded in the daily operations, the more likely it is that the process models will be kept up‐to‐date. If process models are used to automatically create job descriptions (see Utilization below) that are accepted and communicated throughout an  organization,  then  the  foundation  processes  for  these  job  descriptions will most likely be subject to an ongoing review to ensure their timeliness.

A well‐defined set of gateways for process reviews should be established – that is, an approval process needs to be implemented. This will ensure that only reviewed and approved process updates are communicated throughout the organization. The alignment with other processes (i.e. the correct setup of process interfaces and the evaluation of process changes to other areas) will also be in focus. The impact on other process areas needs to be evaluated and managed.

Communication/Visibility

Well‐defined communication is essential to embed the process thinking throughout the organization – this leads, ideally, to increased efficiency by communicating responsibilities, dependencies, and organizational interrelations. This ensures that the process is visible to all stakeholders. The best processes, even those mapped out in detail with all required information, will not be followed if employees do not know where to find them! Handbooks are one possibility to communicate processes and ensure that employees are aware of important steps to be followed; they are even more important to highlight risk‐related process steps and implemented control actions. An online process portal within the organization’s intranet is even better than a printed or digital process guide.

By doing so, all employees will have access to the relevant information and, if needed, access to sensible information, like risks and controls, could be tailored.

A successful implementation not only communicates the process flows and  puts  them  into  an organizational context, but also integrates with other media. Links are provided to guidelines, templates, and draft documents stored in the organization’s document management system and, therefore, available at the particular process steps where they apply – easy to access and put into context!

Utilization

To ensure the maximum utilization of any process‐related work, the process must be the single source of truth for other activities. One example is using the process model to produce the test case for new application functionality. Once the process is tested and changes requested, the change should first be reflected in the process, which should then result in a new test case.

Another example is using the process to draft job descriptions. Some process modelling tools allow for roles to be assigned to a process step – which, in turn, indicates  the  responsibilities  for  that  role. Changes in the process would then lead to changes in the role’s job description. Furthermore, required access to applications could be revealed if application systems are also assigned to process steps. Modelled input and, especially, output would highlight the key responsibilities and tasks of a specific role.

The process‐modelling tool can also produce standard operating procedures (SOP) with the process as the base. These can become the operating standard for the organization.  The  SOPs  usually  include process responsibilities  (communicated via  an RASCI  chart), process  custodians,  stakeholders, and the sites or departments that these processes are relevant for. Also, to ensure a holistic view of a process model, a graphic of the process could be included and, depending on the scope of the SOP, topics such as risks and controls addressing governance, risk and compliance could be extracted from the process and reported via tables. Changes are captured in the process and a new procedure is produced.

The process could also be used to create the technical artefacts required for software development. The aim should be to implement software capabilities that are directly linked to requirements – a process‐ modelling tool can  help  with  this. The  requirements  are  captured  in  the  tool, which  then  guides  the process creation. This process is designed to the work instruction level that is linked to applications and screen design. With this information, a functional specification can be generated using a process‐ modelling tool. This artefact would serve as an input to the development phase of the work package.

As highlighted in this article, business process modelling can be a powerful tool to support the achievement of defined business goals. To be able to drive an organization’s  efficiency  and  produce valuable information, BPM must be set up correctly by considering various aspects of modelling technique, governance, communication and utilization.  As  described  above,  if  these  topics  are  taken care of, an organization will surely benefit from business process modelling.