Is process modelling difficult? It sounds quite straightforward: processes are to be modelled—arrows and boxes—this happens, and then that happens. Let’s just get on with it! Why is it then, that so many projects dealing with process modelling struggle with this task? Why is it, that process models are often questioned and not valued? Why is it that process models are not being used by the business, and become outdated shortly after the project that originated its production have been completed? Cost as a barrier Process modelling, even when done well, has a significant cost. When done poorly, it represents a serious waste of money—and, even more importantly, it creates the potential for critical misunderstandings that could have even greater financial, regulatory, customer-experience, or public-profile impacts. Why bother with modelling? So, why do process modelling in the first place? What is it good for? Why should anyone get into it in the first place if it comes at a significant cost and could also potentially fail? Process modelling, in itself, does not do the trick. It’s not about the number of processes modelled in a certain period that defines success or failure—it’s the quality of process models that make them essential to the decision-making process of the business. Process models, captured in the right way, support an end-to-end view of the organisation’s processes, and are the basis for process-improvement projects. They are a means to reduce the complexity of the day-to-day operations and highlight aspects in focus, whether these are runtimes, system breaks, issues with responsibilities and hand-overs, or risk exposure and introduced countermeasures. Models to solve problems and embed strategy Process models can support the business in becoming more efficient and solving problems—that is, saving money in the long term. It does this directly by being the basis for improving process flows, and indirectly by providing evidence to comply with standards and regulations and, therefore, avoiding penalties from governing bodies. These examples show that process modelling is not just an operational task that needs to get done and over with—it’s far more than that. To make use of its overall potential, process modelling needs to be embedded in the organisation’s strategy. Only when process modelling and the use of the related information is embedded (e.g. project management frameworks and/or compliance management) will the real benefit (that means savings) be achieved. Process modelling turned bad… If this is what good looks like, what’s a picture of bad? It starts with poor modelling—that is, important information not being captured during the process mapping. Process stakeholders won’t see the value in using these process models, and will turn away, as they don’t provide any obvious benefit. The money spent on modelling is wasted. It’s even more problematic if the captured process information is inaccurate, leading the business to make wrong decisions based on incorrect data. This is especially true if aspects of risks and controls are mapped to processes to make this information the foundation to proof compliance with specific regulations. It is therefore mandatory that all related information is captured correctly. Keeping modelling current Here comes the next big challenge of process modelling. Once the information is captured—and let’s assume it was done correctly—it needs to be kept up to date. Without up-to-date data compliance, decisions being made based on the process information are at risk in the long term, with potentially serious consequences for organisations. Governance, ensuring process model reviews, approvals and organisation-wide communication are essential and will be discussed in this paper. So now what? Process modelling is a critical activity in every organisation, and represents a significant expenditure. What is the return-on-modelling? Is there a way to ensure the creation of consistently useful process models across the organisation and over time? Yes, there is. The Modelling Excellence framework ensures high-quality modelling, minimises the potential for waste and error, and maximises the usefulness of process models. An overview of the Modelling Excellence framework is shown in the download below which includes detailed descriptions of the nine elements that form the framework.
Ideation activities are sure to bring in a lot of ideas but in most situations, not all ideas are implemented. It is very important at the earliest phase of idea generation that there are already guidelines on how to choose which ideas are in the best interest of a project or an organization. Create, collect then select the best ideas It is important that as you are generating and collecting ideas, you are also applying the strategies on what to prioritize based on the needs and requirements of the group or the business. You need to set a list of criteria on how to choose the best ideas and here are some helpful guidelines to help you decide: Evaluation Do not just merely base on votes because oftentimes voting just speaks of the popularity of an idea and not about its workability. Also, there are ideas that may seem ridiculous at first but actually have a potential to be the most innovative ideas. It is always important to be discerning and evaluate ideas beyond the surface level. Communication By involving everyone, you are able to get to know what they think or what their perceptions are over the ideas. Communication encourages people to be more open and confident about their decisions and honest opinions. Profitability You cannot argue with this criterion. All businesses include profitability as a factor in any decision-making process. Knowing about the revenue opportunities that abound your product or service will help you choose the best ideas to implement. Usability The usability or functionality of an idea both short-term and long-term is very crucial. An idea is useless if it doesn’t fulfill a practical need. Long-term Value In relation to usability, you can gauge if the idea is one of the best if it works in the long run and becomes a necessity. Stability Businesses are unpredictable that’s why it’s important to consider an idea’s stability over time. It’s important for you to determine that an idea is not just simply a fad. Clarity Ideas should always be clear and concise. Uncertainties over an idea will just bring in a lot of assumptions which results to unexpected disasters. Eliminating Ideas Now that you have a long list of ideas, the hardest part is about to start – choosing what not to include. It is tough making decisions but your organizational skills will help you sort things out. Create a Go/No Go list where all ideas are listed and a set of criteria is included to help you determine if the ideas are retained or discarded. Grouping ideas into concepts After selecting which ideas to be implemented, the next step is to group these ideas into concepts. Before going further though, let us first differentiate an idea from a concept. An idea is defined as a thought, plan, or suggestion about an action while concept is defined as an idea of what something is or how it works. Simply put, a concept is like the final form of an idea which has gone through a process of refinement. After listing down your ideas, it’s time to group them and collectively assess what ideas work well together. Start with ideas that are related to each other, put them together in one column or side until all ideas have their own groups and label each group. Whatever ideas you choose to implement or eliminate, the bottom line is to stick with your criteria, be able to differentiate an idea from a concept, and be able to group and organize your ideas logically.
Innovation is defined as the process of turning ideas into solutions through certain methods referred to as the innovation process. Business innovation matters From a business perspective, innovation is what fuels the organization to change. With change as the only constant, any organization that does not change can soon fail. That is why organizations need to be able to adapt to changes, to constantly innovate and think long-term. To understand how the innovation process works in the business perspective, there are five concepts to remember: Challenge: This phase is where you plan the innovation project, involve stakeholders, and frame and communicate the innovation challenge. Ideate: This simply means generating ideas. Converge: This is where you take a wide range of ideas and eliminate or combine them into a compelling design. Prototype: This is where an early sample or model of a product or services is created to be replicated or learned from. Test: This is the phase where you try out the workability and efficacy of your prototype Creating value through innovation Increasing business value through innovation is important for the organization’s success. Innovation challenges faced by organizations can be addressed and examined by frameworks which lead to value being generated by the ideation process. Innovation performance frameworks such as the following help organizations create values through innovation: Product innovation strategy Portfolio management Idea-to-launch process Climate and culture The objective of business innovation The objective of business innovation is simple yet powerful: it is to create, deliver and capture value through innovation. Let’s examine what value creation, delivery and capture entail: Create Value Feasibility is one objective of business innovation. The important questions to ask are what the product or service does, how is it made, and how do you build it. Deliver Value Interest should also be considered. Who is the intended market of the product or service? How do you get them and catch their attention? How is the sale completed? Capture Value Profitability, repeatability, and scalability of a product or service should not be ignored. Business innovation is a deciding factor for an organization’s success or failure. Organizations that get comfortable with the norm or their usual ways of doing things and avoid changes get left behind and eventually fail. This is the powerful message of business innovation.
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.
Business Process Management and Governance Risk & Compliance Management: two separate worlds? Reading a newsletter of Leonardo Consulting you would not be surprised to find the word Business Process Management (BPM) in the headline. Not that common is the topic Governance, Risk & Compliance (GRC), which is indeed becoming more and more important: Quality standards (e.g. ISO 9000) in various business areas as well as laws and regulations that have been introduced and are binding. This article puts a spotlight on both Management areas in order to illustrate, how they are linked to each other. Business Process Management is well known as an approach to improving an organisation’s processes, by aligning all relevant aspects of an organisation promoting effectiveness and efficiency. Corporate Governance describes the regulation framework for a target-oriented, responsible and ethical administration and a regulated control of organisations in accordance with the existing law. Risk Management integrates the handling of risks that threaten the achievement of strategic and operational business objectives and therefore covers topics like risk identification, risk evaluation, risk mitigation and risk monitoring. The Compliance Management, last but not least, is the fulfilment of all relevant internal and external, binding and voluntary requirements of all stakeholders. So much for the definitions, but how are the GRC topics related with BPM? A good example is the Internal Control System (ICS). Being influenced by the US Sarbanes Oxley Act in 2002 which put a spotlight on risk inheriting processes and process steps as well as reasonable controls and their ongoing execution, the topic ICS became more and more common and important. See also the best-practice guidelines set by the Australian Stock Exchange (ASX) which requests companies to implement a risk-management process within their Risk & Control Management systems and its assessment. However the guideline is not compulsory for organisations to follow. But it makes it obvious: no business without business processes. And these processes and process steps inherit risks. Business Process Management is therefore an ideal basis for risk evaluation, risk mitigation and risk monitoring. The existing process knowledge should be used in order to support the Risk Management succeeding in these topics. Once the risks have been identified it is about setting up appropriate controls, mitigating the evaluated risks. If specific laws have to be followed, (e.g. SOx with a financial focus) the relevant process areas are clearly defined. BPM can support these compliance aspects by providing the process knowledge and, if any tools are used, the maintenance of the GRC related data as well as its communication. Risks and controls could be assigned to process steps and specified with responsibilities and information about application systems or tests to be executed to ensure the controls effectiveness. The BPM repository, if a tool including a database is used, would ensure a sustainable approach by offering GRC specific reports or having the data required to feed a workflow tool handling the risk evaluation as well as the testing of designed and implemented controls. These are just two examples for various business cases, where BPM and GRC are linked to each. In conclusion, it is worthwhile to look at BPM and GRC questions in a combined approach, as both management areas do contribute to each other in specific business areas and therefore the effectiveness and efficiency of both BPM and GRC related aspects could be increased.