Vesa Purho

In the first article of this series, I discussed how to identify a process and how to find out where it starts and ends. In this month’s article, I will go through the building blocks used to create the process flows.

Three basic elements are needed to build a process map: activity, role, and flow. There can be variations of the basic elements to give more specific meaning to them. In addition to these elements, you can use start and end symbols to show where the process starts (showing also the trigger of the process) and where it ends. A process typically has only one starting point, but it can have multiple ends depending on the decisions made in the process.

Activities show what happens in the process. An activity transforms an input into a different output, or at least the status of the deliverable going through the activity should be different after the activity. Activity name should be a verb in active form, for example “Create content specification” or “Approve specification.” However, it is not enough just to name the activity—you also need to write a description explaining in more detail what is actually happening. You can include an overview description, detailed steps, tools and templates, and work instructions used in the activity. If you are using process mapping tools that do not support entering detailed information to the activity itself, the description should be written for each activity separately. For example, you can create the process map using PowerPoint or Visio and embed the map into a Word document in which you create a table showing the detailed descriptions of the activities. The graphical representation of an activity is typically a rectangle.

How small a step should be in an activity and what steps should be combined into one activity is a question one often has to think about when drawing process diagrams. The main rule is that steps performed sequentially by one role belong to one activity. For example, creating a draft content specification may contain the steps “read product specification,” “interview SMEs,” and “study marketing material.” Because the steps may be performed in any order and contribute to the same deliverable, creating separate activities of them would just clutter the process diagram.

A specific type of an activity that is often used is a decision represented by a diamond symbol. Otherwise, the content is the same: description, steps, tools, checklists, and so on. The input to a decision is typically a deliverable to be reviewed/approved and the output is either approval or rejection with feedback on what should be changed.

All activities are performed by roles. A role in a process should not be tied to a job description but to a group of competencies that are needed to perform the activities assigned for a role. For example, if you have job titles like Junior Technical Writer, Technical Writer, and Senior Technical Writer who all write customer documents, the process role could be Author and the description of the role could be “an individual responsible for writing customer documents.” In real life, the role can then be fulfilled by any of the Technical Writer positions or even by SMEs if there are cases in which they are responsible for creating customer documents. You should not change your processes just because your company decides to change job titles. The activities still need to be performed by a person who has the competencies to perform them regardless of any specific job title. If absolutely necessary, the description of a role can contain information on the job titles that typically perform the role. A role can also represent a group of people like “documentation technical review team,” which could consist of SMEs, product managers, and marketing managers. A group role is especially useful when a document is sent for review to multiple persons at the same time, and there is no predetermined chain of review (workflow). If there is a predetermined workflow, then the roles should also be separated in the process map.

Roles are used to form the swimlanes in the swimlane process mapping methodology. Swimlanes can be drawn vertically or horizontally. Activities are placed in the swimlanes according to the role that performs the activity, or to be more precise, the role that has the responsibility for performing the activity. There can be supporting roles that participate in the activity, but the activity is placed on the role that is responsible for ensuring that the activity happens. The activity description can contain the information on other roles involved.

A flow is drawn between the activities. A flow has two functions; it shows the sequence of the activities, and it shows what deliverable is exchanged between the activities (as an output from the previous activity to an input to the following activity). You should rarely have just arrows connecting boxes. All the arrows should have the names of the deliverables going between the activities. For each of the deliverables, you should write at least a description explaining what the deliverable is, any templates for the deliverable, the quality criteria (at least for the main deliverables coming in and going out of the process; not needed for each deliverable inside the process), and the repository where the deliverable is stored, if applicable. If the deliverable can be in several states during the process, like draft, reviewed, and approved, you can indicate the state in the flow, for example “Content specification (draft),” but you don’t have to write a deliverable description for each of the different states. If there are some specifications on what constitutes a draft content specification, for example, those can be added to the description of the deliverable.

If needed, you can separate information flows and material flows. Material flow is used to show the flow of physical goods in supply chain processes, and materials can take a different route than the information of the material. For example, material can go from a warehouse to a customer, whereas the order information goes from sales to the customer. The separation can be done by using different colours or different line styles (solid vs. dotted lines).

In my next article, I will demonstrate how a simple process is built with the basic elements listed here.

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