Swimlane Process Mapping 101—Identifying Processes

Home/Publications/CIDM eNews/Information Management News 02.06/Swimlane Process Mapping 101—Identifying Processes

Swimlane Process Mapping 101—Identifying Processes
Vesa Purho
Nokia

This article begins a series concentrating on process mapping. I previously wrote an article about process development in the March 2004 edition of Information Management News, but this time I will be going into more detail on the actual mapping methodology. Although I will be concentrating on swimlane process mapping, most of the content is also valid when using other methods for mapping processes. In this article, I will discuss how to identify and set boundaries for a process. After all, before you can design what happens inside a process, you need to know where it starts and ends.

A process can be defined as “a series of activities transforming inputs into outputs”. But how do you know which of the activities that you perform belong to the same process? To identify a process, it is best to start with the outputs. One process produces one main output. For example, an authoring process produces one document; when you have multiple authoring processes running at the same time, you get multiple documents. If you have activities that concern the whole document set, like configuration management, those activities don’t belong to the authoring process as the object of the activities is not the same (one document vs. the whole document set). Also, activities that control the process, like documentation project management-related activities, are not part of the authoring or the configuration management process, but they form a process of their own.

In addition to the main output, a process can produce additional outputs that may be used by other processes. For example, when describing customer support processes, the main output is an answer to the customer’s question; additional outputs can be feedback to the knowledge base management process if the contact center agent notices that an article has incorrect information or that there would be a need to create a new article.

Once you have identified the different kinds of outputs coming from a process, you can name the process. After that, you should think about what inputs are needed to produce which outputs. The inputs can be divided into two different categories:
Source material—These are the inputs that are actually handled by the activities and transformed into outputs. For example, in an authoring process, product specifications and user information can be source material for the customer documents. For these inputs, you need to define which process produces them so you can ensure with the respective process developers that they really are produced at the time when needed for your process.
Controls—These are inputs that guide the execution of the activities. Style guides and templates can be considered controls. Naturally, there is also a process for producing style guides, but it is not as important from the process development and control point-of-view to identify the processes that create the controls.
Before you can say that a process has been fully identified, you must specify what triggers the process. Sometimes a process is triggered by an input. For example, the requirements management process starts when a requirement comes in. A process can also be triggered by an event in time: for instance, “a project progress report is written by the first Friday of each month” or “salaries are paid on the last day of a month unless it falls on a weekend or public holiday. In that case, they are paid on the last bank day before the last day of the month.” After the trigger has been identified, you can write your initial process definition statement which acts as a basis for further development. Here is an example definition of an authoring process for traditional user guide development:
Process name: User guide authoring process
Purpose: The purpose of the process is to plan and develop a user guide
Trigger: Approved documentation project plan
Inputs:
Source material: Product specifications, Information Plan (containing user & task analysis), expert knowledge
Controls: company style guide, document templates
Outputs: approved user guide

At this stage, you can also list the main activities if you want, but the detailed activity definition is done at the next phase. I will discuss the detailed process analysis in my next article.

If a company is using a modular documentation methodology, the authoring process should handle the development of one module since they are created as independent units. The change in cardinality principle (processes handling one instance of something are different from the processes handling multiple instances of the same thing) is very important for efficient process development and management. The principle may make some processes look very simple, with just a couple of activities, but some processes are very simple. They should not be made to look more complex than they really are.

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

We use cookies to monitor the traffic on this web site in order to provide the best experience possible. By continuing to use this site you are consenting to this practice. | Close