<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1907245749562386&amp;ev=PageView&amp;noscript=1">
Event_bg

The Leonardo Blog

All Posts

Getting the most out of Business Process Modelling

15_DEC_Blog_Modeling.jpg

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 wellstructured 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 longterm 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.

Why Measure Process Performance?

Related Posts

The Ultimate Guide to Process Modelling

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.

Moving From Continuous Improvement to Continuous Process Management

  Continuous process improvement is a common organizational aspiration, and it is one of the most difficult things an organization can attempt. The continuous aspect is quite a challenge, as is realizing business performance improvements—especially once the easy and obvious changes have been made. Organizations need an ‘internal improvement engine’ that replaces insistence with evidence.

Process Architecture vs the Organisation Chart

  In my working life I spend a lot of time working with client organizations to discover and capture useful models of their process architecture. In every country, industry sector, organization type and size, there is a common problem that bedevils every project. We all, and I include myself here, can too easily slip into the habit of the last 100 years (or you might argue 1,000 years) of visualizing the organization as its organization chart. Comments such as “What about the work they do in department X?” might just be a useful test for a developing process architecture, or they might indicate a lack of understanding of what the architecture represents.