A process map provides an overview of an organization’s business processes and how they relate to each other and to customers. At the same time, it is the top level of representation of the business processes and the starting point for increasing efficiency and process management. Actually, every organization that wants to be process-oriented should have a useful process map.
In practice, however, this is often not the case. The process map is often characterized by “process islands”. The following examples illustrate this:
- Quality management mainly documents quality-relevant processes for certification (e.g. ISO).
- Only critical or important processes are modelled and anaylzed in a process analysis.
- For the introduction of IT systems, the processes in the respective functional area are modelled.
- Work instructions are only selectively documented as process descriptions.
Further challenges in the initial situation can be found here (in german language).
So, what is the best way to develop a meaningful process map as a basis for goal-oriented process work? My colleague Wieland Appelfeller of Münster University of Applied Sciences has published two articles on process maps in the Zeitschrift für Organisation. I was inspired by them and added my own experiences and examples.
1. Analysis and order clarification
Before starting the actual development of the process map, a few questions should be clarified to define the framework:
- What are the goals you want to pursue with the development of a process map? Clarity about the goals can avoid misunderstandings in the organization. In addition, aspects that are important later can be discussed in early phases. If, for example, it is planned to anchor an active process management in the company, this can already be taken into account during the development of the process map:
- Increasing the process orientation of an organization: The development of a process map can be the kick-off for a higher agility and customer orientation. But it is also helpful for the preparation of a comprehensive digitalization of processes.
- Structuring the process landscape: to be a structured overview of existing processes, the starting point for the introduction of a goal-oriented process management or a continuous improvement process (CIP)
- How should or will one later notice that the development of the process map was successful? The concretization of the success criteria can once again bring to light aspects that were not thought of at first glance.
- How should the process map be linked to the corporate strategy? The clarification of the relationship to the corporate strategy is also important, since a process map should of course be in line with it. On the other hand can also be a strong vehicle for supporting the development of a corporate strategy.
- How individual should the processes or the process map be and how complex should the creation of a process map and its introduction and implementation be? There are approaches for the development of a process map that are based on reference models. Such approaches tend to be simpler and require less effort. However, they have the disadvantage that the result is less individual and the important and insightful process of working together on the process map is shorter.
- Should/may a radical change in process thinking take place and what degree of process orientation should the company have in the target picture? This general condition to be clarified is very important. Because only if the frame of thinking can be chosen large and a radical change of the existing process landscape is possible, then a real change can be achieved. However, the company management should be aware that a change process will then be set in motion, which must be actively accompanied. What does not make sense at all is lip service to out-of-the-box thinking, which is then slowed down during implementation. This will lead to disappointments. If a radical change towards a comprehensive process organization is not desired, then the process map should be based strongly on existing structures and a change should be initiated by continuous process management.
- Which tool support is helpful for modeling and later management? There is a wide varienty of solutions on the market. They range from simple and often free modeling tools to tools that can be used to implement executable workflows. Even before the process map is drawn, the necessary and desirable functionalities can be considered when selecting the tool.
2. Selection of the approach for deriving the process map
Five basic approaches can be distinguished for the development of a process map. Based on the answers from the analysis, it should be defined which of the approaches is most suitable for the organization.
The goal-based approach focuses on the organizational goals. The processes are then the activities for achieving these goals. This approach is suitable, for example, for non-profit organizations such as universities. Core processes can be derived from the statutory obligations for universities regarding education or teaching, research and knowledge transfer.
In the object-based approach, the objects that are important for the organisation are the key variable. The processes are then the activities that are performed with these objects. Objects can be products, orders or customer(-groups). From this approach, a manufacturing company could derive a three core processes: a customer acquisition and maintenance process (often CRM), a product development process (often PLM) and an order processing process (often SCM). These core processes can then be further divided into different segments if necessary. For example, the SCM process can be divided into one for products and one for services, the PLM process into products and software or the CRM into retail and wholesale.
The activity-based approach develops the process map from the operational business. The processes are put together bottom-up to form a map. In doing so, an appropriate and, if possible, similar degree of abstraction is to be ensured. An example of this could be an investment fund company. Here, the most important activities are the launch and management of the funds that are offered and the management of the customer portfolios in which the customers store the funds. In this respect, the fund management process and the portfolio management process represent two important main processes.
In the function-based approach, processes are derived from the classic – but often not necessarily process-oriented – functional areas of an organization. Here, the operational functions such as purchasing, production or sales would then be the leading structure at the top level. Then the processes are detailed in the respective functions. With this approach the difficulty is that the classic organisational structure with the departments rather than the customer-oriented, often cross-functional processes are mapped.
The reference model-based approach is based on a derivation of the processes from a reference model. The standardized main processes can, of course, still be adapted to the specific conditions. A reference model can also be the process map of another company that has similar characteristics to your own. This has the advantage that experience already exists here and the benchmarking idea is also taken into account. However, it may not be possible to work out the competitive advantage of one’s own company so well and the important discussion in the company about the process orientation will be lost.
Of course, a combination of these 5 approaches can also be chosen. Thus, the activity and object-oriented approach can be combined very well. And a consideration of the objectives can also be helpful in addition to the individual approaches.
The choice of the approach to be pursued provides the rough framework for the development:
- What information needs to be collected in advance?
- What resources are likely to be needed in what time frame?
- And – depending on the expected change – what time frame is to be expected for implementation and communication?
Perhaps the modelling tool has already been selected, although this is not yet absolutely necessary for the process map itself. So the next step, the concrete definition of the processes on the first level (!) can be started.
3. Definition of core, management and support processes
In practice, the distinction between core, management and support processes has become established as a classification in a process map. This subdivision makes it possible to clarify the relationship to the customer as well as the relationship of the processes to each other.
Definition of the core processes
The starting point is the definition of the core processes. They represent the activities that create value for the organization. When defining the core processes, the relationship to customers and strategy is important, regardless of the basic approach chosen. Companies earn money with the core processes. The result of the core processes is therefore the value added provided to the customer, for which the customer pays the money. In terms of a core competence, the customer should ideally also notice the difference to competitors and the process should not be easy to imitate.
When defining core processes, care should be taken to ensure that they are defined as end-to-end processes. They should therefore start at the point of need and be thought through until the need is met. A simple example is a generic order processing process that starts when the order is received and ends when the customer delivers or pays. Functional (sub)processes, such as – to stay with the order processing process – the production process (manufacturing of the product) or the administrative order processing process (for example, in sales) have this characteristic, since they map the processes in a department and usually have a (end) customer reference only on one page at most. Therefore, when defining core processes, you should first start with the external customer and ask which objects are delivered to the customer with which activities to achieve which goal.
In some cases, it can also be useful to differentiate between different customer groups or different types of needs of a customer group. Then separate core processes can be defined, which allow a higher process orientation because they are specifically tailored to meet the customer’s needs. An example of this could be the fashion industry. A core process could be the supply of customer accessories, which can be procured or manufactured in a more standardized process and delivered from a warehouse. In contrast, fashionable seasonal clothing could be defined as a different core process, as procurement, production and delivery are more project in nature. If both product groups used the same processes, this would not meet the requirements of at least one product group.
Block arrows have proven to be useful for representing the core processes, which can be structured, i.e. subdivided or segmented, if necessary.
Definition of management and support processes
The following guideline helps to differentiate between management and support processes: The management processes aim to align and shape the core processes in the long term, while the support processes provide operational support for the core processes. The latter is often illustrated by internal customer-supplier relationships.
An important question for the definition of management processes is what is important to make the organization competitive in the long term. Using the example of quality management, it is easy to discuss whether the criteria for a management process are fulfilled: If quality management is primarily concerned with ensuring design quality – in other words, whether product development is aimed at developing products that can better meet customer needs in the long term than those of the competition – then quality management should be classified as a management process. At universities, quality management is aimed at continuously checking whether the range of courses offered meets the needs of the addressees. This is therefore the case here.
In contrast to this, quality management can be primarily aimed at ensuring the quality of execution – i.e. products or services have been made available within the framework of order processing as ordered by the customers – in which case there is something like an internal customer-supplier relationship between the order processing process and quality management. Quality management is therefore a supporting process. In contrast to the management processes, the identification of the support processes requires the question of what input or services the core and management processes require in order to run optimally.
Two points are again important at this point:
The difference between functions and processes: Especially in the case of support processes, there is a danger of becoming too attached to a function-oriented way of thinking. In order to achieve a consistent process orientation, the support processes should therefore primarily focus on the required objects (personnel, information, financial resources, etc.). The example of purchasing also makes it clear that activities of functions can appear at different points on the process map. For example, in repetitive manufacturing, the operative running-in of production material is most likely to be seen as part of the core process of order processing. Strategic purchasing, which develops the purchasing strategy and is responsible for managing supply chain risks, could be declared a management process. Finally, the purchasing of non-production material or project purchasing could be classified as a support process. Similarly, this could be declared for the marketing function.
The classification is not an indicator of importance: Sometimes managers argue in workshops that a process must be a core or management process, because the organization would not function without this process. This is of course not a convincing argument. Neither are support processes less important nor could an organization survive for a long time without a process at all. Classification is therefore not an evaluation of processes in terms of importance.
The process map should be developed in a workshop of the management with the most important executives. On the one hand, this ensures that many perspectives are included in the creation. On the other hand, the process map defines the target values of the processes and the relationship of the processes to each other. The participation of the managers, from whom a large part of the “process owners” will probably be recruited later on, can already lay the foundation for the implementation.
Once an initial process map has been developed, the following criteria can be used to check the quality:
Significance: The significance of a process map is given if the business objectives and strategy can be easily explained on the basis of the process map. This becomes visible through a consistent cross-functional definition of the processes. So if the corporate strategy is aimed at cost or innovation leadership, then this should be made clear somewhere in the process map.
Granularity: Here the question should be answered whether all processes mentioned on one level in the process map are actually on one level in the company. Managing rental vehicles and fuel cards is another level like managing and documenting money and service flows (accounting). The processes in a class should therefore be the same and should not overlap.
Consistency in the formulation: The consistency of the processes at the highest level should also be given when naming the processes. Therefore, the processes should contain at least one verb. It would be even better if an object (procure and provide material) is named in addition. For core processes even the target or the change of state of the objects can be named explicitly. An example for the core process teaching at a university could be “Education: From prospective students to qualified graduates who are connected to the university”.
It is easy to check whether these criteria are met. Simply ask people who were not involved in the creation to interpret the process map created. At the same time it can be checked whether the respondents are able to link the process map to their daily business.
A complete example of a process map of a university is shown in the following figure.
Define next steps
The process map stands and is the starting signal for further process work. The next steps should be:
Modelling of (sub)processes that are still missing or assignment of already modelled processes to core, management or support processes
If processes have been modeled for other purposes, such as certification, they may no longer fit into the new structure or may not be consistent. Here, the workaround could be to insert a second level. Here one can integrate the previous structure. One can also keep the processes in a separate repository and selectively include them as subprocesses in the new structure.
Assignment of (sub)processes to organizational units
The process map defines the top level of the process organization. Now the connection to the organizational plan, i.e. the organizational chart, must be created. The preferred way to create a process organization is that the “process owners” of the process map are also the managers in the organization chart. However, in many cases or at all levels, this will not be consistently implementable. Therefore, the processes or sub-processes must now be assigned to the organizational units in the organization chart and the interfaces must be defined.
Selection of a process management tool
At this point at the latest, the search for a suitable tool in which the processes are managed becomes the focus of attention. In addition to a modeling function, most tools have a repository with version management and change workflows. Other interesting functionalities are the execution of workflows. For example, release processes in procurement can be executed in a separate tool and the results can be fed back into the ERP system. Another possibility is process mining. Here processes can be analyzed for weak points or bottlenecks using transaction data.