Vesa Purho, Nokia

In my three previous articles, I went through the basic concepts of swimlane process mapping. Now it is time to introduce some advanced concepts. Just like information and applications, processes can also have architectures which can be modular.

Identifying your own processes and their interfaces is already one step towards a process architecture. A comprehensive process architecture consists of all processes and their interfaces within a company (enterprise process architecture). Through the architecture definition, it is possible to establish a common understanding of what processes exist in the company regardless of what function performs the processes. The truth is that, unless a company moves into a new business or outsources some activities, the same tasks need to be done within the company. Process architecture enables a stable framework for process development that survives through changes in organizational structure.

There can be hundreds of different processes within a company, and trying to draw a picture showing all of them and their interconnections can be an impossible task, at least if the picture is meant for humans to read. Therefore, it may be necessary to group the processes into process areas and, at the top level, show only the main inputs and outputs between the process areas. Division can be done, for example, according to product lifecycle: product creation processes, delivery processes, after sales processes (maintenance, user support), or according to some other division depending on the business. For example, if the company is in the software business and uses the Internet as the delivery channel, the delivery processes may not be as important as they are in a hardware company where logistics and warehousing play a major part in delivery.

One of the goals for process mapping and architecture is to identify common processes that can be applied by multiple functions so that resources are not wasted in developing and supporting duplicate ways of working in cases when just one common process could be used. But, naturally, there can be situations where, depending on the different businesses or products within the company, one needs to have variants of the same process. The input and trigger of the processes as well as the output can be the same, but some of the activities within the process can vary. Instead of treating the processes as completely different, you should treat them as variants of one process, just as an information module can have conditional parts.

By identifying the common processes and processes with variants, you can build up a process library which is categorized according to the architecture. When new business models are being developed, the process library can be used to identify those processes that can be used as they are with the new business and to understand for which processes you need to create a new variant. This saves time by avoiding reinventing the processes that do not need to be changed. For example, if you add a new information product type to your portfolio, you may still be able to use the same planning process, although, the testing and publishing processes would need new variants.

I think that moving into this level of process management requires you to be at a Level 3 of process maturity, or at least be very close. The main processes need to first be in place and documented before you can start identifying the architectures and variants.

This article is the personal opinion of the author and does not necessarily reflect the opinion or practice of Nokia.