The Noun-Verb Process Mapping Method

 

Introduction

This chapter provides a description of Triaster process maps, the reason they are used and what they are used for. It also introduces the terminology used to describe the various parts of a process map.

 

What is a Process?

A process is a transformation. It transforms inputs into outputs. For example, a process is the mechanism by which raw materials are converted into products.

The essence of process mapping is to recognise that organisations that perform this transformation well generally manage to meet or exceed customer expectation and those that do it best are invariably the most successful.

What is a Triaster Process Map?

A Triaster process map is one of many tools for describing the way things are done. It can be thought of as a ‘User Guide’ to your organisation; it is the manual that shows how your organisation operates.

Triaster process maps are produced using the Noun-Verb process mapping method. This is a powerful, yet very simple way to document a business process. It has been thoroughly proven in hundreds of organisations to deliver process diagrams that are useful to a widespread, non-specialist workforce, and at the same time to business analysts. The Noun-Verb Method perfectly balances out the need for simple, comprehensible process diagrams that are also at the same time sufficiently detailed to enable the identification and analysis of performance improvement opportunities.

To understand the Noun-Verb Method, it is helpful to first consider again the definition of a business process. The essence of a business process is that it transforms one thing to another. A Customer Order is transformed into a Delivered Product. A Supplier Invoice is transformed into a Supplier Payment. A Staff Vacancy is transformed into a New Employee. A process then is defined as:

a set of interrelated or interacting activities which transforms inputs into outputs

The Noun-Verb Method simply adopts this definition of a process, and applies it rigorously.

A process map drawn using the Noun-Verb method is a diagram that clearly identifies the main steps involved in performing the transformation and the items used and produced when the process is complete.

In Process Navigator, the term ‘Activity’ is used to describe something you do, and the term ‘Deliverable’ is used to describe something you produce. Activities are the steps of the process and are described using verbs, Deliverables are the items produced (or ‘delivered’) when each step of the process is complete and are described using nouns.

In Process Navigator, there are four other words with special meaning. These are: Inputs, Outputs, Suppliers and Customers. To help explain these terms, the diagram below shows part of a map of a recruitment process. In this diagram, the Activities are ‘Define job role’ and ‘Obtain sign off’. The other symbols are the Deliverables.

Outputs are the Deliverables produced by an Activity. These Outputs then become Inputs to other Activities; for example ‘Job specification’ is both an Output from ‘Define job role’ and an Input to ‘Pass to DH for approval’.

Suppliers are the people, organisations or Activities that produce the Inputs. Customers are the people, organisations or Activities that use the Outputs.

The rules of the Noun-Verb method are very simple:

  1. Each Input or Output is described using a noun, each Activity is described using a verb.
  2. Each separate page of a process map must have at least one Page Input (i.e. a Deliverable with no Suppliers on the same page) and at least one Page Output (i.e. a Deliverable with no Customers on the page).
  3. A recommendation rather than a rule is that in the process map itself, no 2 verbs can be directly connected, and no 2 nouns can be directly connected. This recommendation can be strongly or weakly enforced depending on the nature of the content being produced and the level of detail.

This basic discipline, of always specifying at least one Output (Noun) after every Activity (Verb), turns out to have highly beneficial knock-on effects throughout the model.

The first major benefit relates to the difference between Activity and Productivity. In the Noun-Verb Method, the verbs represent 'work performed'. The problem however is that a person can perform work all day long and not actually deliver anything of any value. The nouns represent 'product delivered', i.e. they explicitly identify the benefit of performing work. So, in the example map referenced above, the first verb "Initiate Recruitment" is in and of itself not at all valuable, in fact, it represents a cost to the organisation. The value of performing the work however is explicitly documented in the output that is delivered, in this case the "Recruitment Brief". In the Noun-Verb Method, the process author is required to document Activity and Productivity. As such, they are required to understand precisely why a given Activity does actually deliver something of value, and to record precisely what this is. Without the discipline of Noun-Verb, the tendency is to focus very heavily on the verbs, and the process map then simply becomes a list of things people do; it is what people deliver that matters most however, and the adoption of Noun-Verb requires equal focus on delivery.

A second major benefit of explicitly separating out nouns and verbs is that Investment and Return-on-Investment can be modelled. Clearly, the verbs in the process model represent areas of investment; a person has to be paid to perform a task, or machinery purchased and so on. The nouns on the other hand represent the return for making that investment. So, "Initiate Recruitment" might cost £700, and in return for this investment, a "Recruitment Brief" is received. Using the Noun-Verb Method it is possible to perform this analysis on a micro or macro level simply by aggregating costs.

A third major benefit comes from the recognition that the verbs in the model typically relate to the work people perform; as such, attributes relating to Responsibility, Accountability, Time, Effort etc. are typically stored in the model behind the verbs. The nouns however typically relate to the information sources in the organisation. One is therefore more interested in understanding the applications used to produce or store the output, the location of the template to produce it etc. By separating the nouns from the verbs, the handling of metrics that describe the model is made much clearer, more tractable and more useful.

The characteristics of the Noun-Verb entities are summarised in the table below.

Noun

Verb

Productivity

Activity

Return on Investment

Investment

Information (templates, applications, …)

People (management, responsibilities, …)

What are Process Interfaces?

An ‘Process Interface’ is the point at which work passes from one organisational unit to another. When documenting a business process, the four interfaces described below are generally the interfaces that are of most interest:

Worker Interface

This is the point at which a person completes a task and hands it to the next person in the process in order for them to continue production. Worker interfaces are generally obvious in physical production systems such as production lines. In business or administrative processes, Worker interfaces tend to correspond to in-trays and out-trays, e-mails, work instructions and letters. Worker interfaces are of keen interest to business analysts because much of the latent delay in completing tasks can be found in the interval between one worker finishing a task and the next worker beginning theirs.

Departmental Interface

A Departmental interface is a particular kind of worker interface. It is the point where an interface relates to two people from different departments. Departmental interfaces are also of specific interest to business analysts. Departmental interfaces often suffer from the worst side effects of organisational structure and hierarchy. In addition to the latent delay in handing over work from one person to the next, Departmental interfaces are characterised by conflicting priorities, management politics and an ‘us versus them’ mentality. It is striking how the human tendency to associate closely with colleagues of the same skills and background actually overrides the organisational requirement to produce saleable goods or services better than its competitors.

Customer Interface

The Customer interface is perhaps the most important interface. This is the point at which goods or services are moved from the ownership of the organisation into the ownership of the customer. The Customer interface is generally characterised by point of sales and delivery operations such as couriers, tills in shops, shopping channels and websites. The Customer interface is vital to an organisation’s future success, but surprisingly, in many organisations, little work is done to understand it. Organisational change really should begin by getting the Customer interface right, and moving from there back through the organisation so that the upstream processes support the customers’ requirements.

Supplier Interface

The modern corporate environment is not just one of companies competing with each other, but one of whole supply chains competing against whole supply chains. A company is only as strong as its weakest supplier. It is therefore important to establish the interface at which goods move from the ownership of the supplier to the ownership of the organisation. In addition, this interface should attain the level of quality and efficiency required by the Customer interface of the organisation that ultimately sells to the final consumer.

The modern perception of organisational interfaces is to view all worker interfaces as Customer/Supplier interfaces. Some of these will be internal customers; indeed any person that uses the outputs of another should be treated as that person’s customer. In most cases, it is not necessary to distinguish between internal and external customers as they both carry the same level of importance in the modern workplace.

It is also generally true to say that modern organisations actively seek to weaken the negative side effects of the departmental interfaces by strengthening the corresponding Customer interfaces. Cross-functional teams are drawn together from either side of the departmental interface in order to smooth the path of work passing through departmental boundaries. Individuals are encouraged to consider the needs of their customer before the operational requirements of their manager: a radical departure from traditional management.

Defining Interfaces with Process Navigator

Process Navigator enables individuals in an organisation to document the worker interfaces of which they are a part.

The Outputs an individual produces constitute their Customer interfaces. The Inputs an individual uses constitute their Supplier interfaces.

Process Navigator opens up communication channels and helps establish Customer/Supplier interfaces. This often means that the workforce will independently modify its working practices in order to improve the quality, timeliness and cost efficiency of the Deliverables it produces for its customers.

Process Navigator helps the business analyst understand the totality of a business process, as defined by its interfaces, without clouding the picture with unnecessary detail. It also enables the detail to be accessed when needed.  Process Navigator is a tool for hiding organisational complexity but, when necessary, for also revealing detailed operational working processes.

Why use Process Maps?

Process maps are a powerful tool for understanding and communicating the jobs you carry out during a normal working day, and because they are diagrams, they are easier and more pleasant to read than alternatives such as procedure manuals.

Process maps are used more and more to help an organisation capture a snapshot of its day-to-day working processes. Knowing how a company works today makes it possible to improve the way it works tomorrow, in a controlled, measurable, thoughtful way.

Understanding the steps taken to convert Inputs to Outputs enables better processes to be designed and affords a way in which workers can contribute to improving their own productivity and job satisfaction.

What is a Multi-Map?

A Multi-Map is a collection of the individual maps that logically make up a business process. It is two or more Process Navigator diagrams that form part of the same end-to-end process.

An example will help illustrate the concept of a Multi-Map. Suppose your company has a vacant position and therefore has a requirement to recruit someone for the position. The first process which would be the responsibility of the Human Resources Manager would be the following:

Once the Recruitment Brief is created, the Human Resources Department staff can begin the second part of the process.

These two maps, although produced on separate Process Navigator diagrams, by different workers, are logically part of the same process. See how the ‘Recruitment Brief’ Deliverable actually flows from the HR Manager’s process into the HR Department staff’s process?

The heart of the Multi-Map concept is the recognition that all Outputs must be used. Otherwise, why produce them? Also, all Inputs must have been produced. Otherwise, where did they come from?

Process Navigator has a set of very powerful tools, which help you create Multi-Maps quickly and easily. This functionality is described in Creating Multi-Maps.

Exploring the Myths about Process Mapping

There are several myths that surround Process Mapping.

Myth One - Process Mapping is Difficult

No, it isn’t! Guidance, support, training and a little time are needed to produce process maps, but documenting one’s own working processes is not difficult. Most e-mail systems are more complex than the software skills required to produce a process map with Process Navigator.

Many readers who were involved in IT in the 80s will recall how it was honestly believed that skilled typists would not be able to operate PCs when they were first introduced to the typing pool. This now seems rather ridiculous. The notion that people cannot produce their own process maps is equally as ridiculous – they just need the right tools.

Myth Two – A Process Map is Valuable in its Own Right

No, it isn’t! A process map is only valuable if it can be understood by the people who need to read it. In order to gain a sustained competitive advantage from producing a process map, the people who need to read it are those that do the work. It can only really be understood by those that do the work if they have made a direct contribution to its creation.

Myth Three – Process Mapping is a ‘one-off’ activity

It shouldn’t be! A process map should be reviewed as part of a regular continual improvement programme, on a monthly or quarterly basis.

Myth Four – Organisations can be changed from the Top-down

No, they can’t! Inspirational leaders can lead from the top and solid management can help achieve strategic objectives. However, real, permanent organisational change requires a combination of leadership from the top and buy-in at the bottom. Process Navigator enables such a buy-in.

Preparation

This section describes the preparation you will need to make prior to documenting your business processes using Process Navigator. 

Recommended Team Roles and Responsibilities

In a team-based approach to process mapping, there are 3 essential roles:

  1. Process Author
  2. Process Owner
  3. Business Analyst

In the Noun-Verb Process Mapping Method, each Verb is assigned a Process Owner. The responsibilities of the Process Owner will obviously vary from organisation to organisation, but specifically with reference to the Process Library, the responsibilities of the Process Owner are as follows:

  1. Ensure the Inputs and Outputs of the Verbs they own are correct.
  2. Ensure the value of any properties attaching to their Verbs are correct.
  3. Ensure each Verb in the Drill-down (sometimes called among other things the Activity Decomposition, Activity Hierarchy or Work Breakdown Structure) has a Process Owner who is aware of their responsibilities.
  4. Assign a Process Author to draw the process map resulting from a drill-down.

The Process Author's responsibilities are essentially those of compliance with policy:

  1. Each change to a process map is approved according to the project's Approval policy.
  2. Each process map is drawn in compliance with the Process Mapping policy.
  3. There are no orphans (this is a technical and easily enforced requirement that ensures that once a Process Owner has approved the Inputs and Outputs of a Verb, there is no deviation from this in the rest of the hierarchy).
  4. Each Verb in the diagram is assigned a Process Owner.

This is a small set of responsibilities, but collectively they are enormously powerful. They need only be combined with the responsibilities of the Business Analyst role in order enable a team-based mapping approach, and at the same time retain control and consistency. They are easy to understand and execute for any given Process, Owner or Author. And, most significantly of all, they contain the key to safely unlocking the benefits of Distributed Process Mapping.

In the Noun-Verb Method then, the responsibilities of the Business Analyst are:

  1. Ensure that every Output from every Verb is either:
    1. matched with a corresponding Input to a Verb, or;
    2. a terminating output, or;
    3. an Input to a process that has yet to be mapped.
  2. Ensure that every Input to every Verb is either:
    1. matched with a corresponding Output from a Verb, or;
    2. a triggering Input, or;
    3. an Input from a process that has yet to be mapped.

Put these responsibilities together, and you have complete control. In essence, the Process Owner is responsible for the development of the vertical process hierarchy (increasing levels of detail). The Process Author is responsible for the correctness of any individual map, and the Analyst is responsible for the correctness of the horizontal (often called cross-functional) flow from the triggering Input to the terminating Output.

It isn't uncommon for a single individual to perform all of these responsibilities, however, with increasing distribution of responsibility comes increasing benefits; better accuracy, faster content development, stronger ownership and increased communication between the players in a process to name a few.

It can also be seen that any process can be linked to any other process horizontally simply by relating the Output from one to the Input of another. Therefore, this breaks a very siginficant constraint relating to the physical size of the map. Oftentimes a Process Author will need to "snake" or "squeeze" elements onto a process map in order to get the process "on a page". This reduces aesthectic appeal and increases complexity. With the Noun-Verb method however a flow can simply stop at the border of the page it is on, and continue on the next page. Each map can therefore be printed easily, is easy to understand and is easy to maintain.

Six Questions to Ask

Process maps must contain real business information if they are to be valuable. The six questions presented in this section will help you identify the information your process maps should contain and set you on the road to improving the processes you undertake.

The questions are:        

  • What do I produce?
  • How do I produce them?
  • What raw materials do I need?

The process maps you produce should answer the three questions above.

There are three further questions to find the answers to:

  • Am I happy with my Suppliers?
  • Who are my Customers?
  • Are my Customers happy?

What Do I Produce?

This sounds like a simple question, but when you think about the range of things you do every day, you will discover there are a host of things you produce and in a wide range of formats.

For example, office administrators will produce letters in computer files and may produce a hard-copy print-out for the filing system. They will also produce updated diary entries, revised travel itineraries, new lists of things to do, organisation charts, meeting agendas… the list goes on and on.

It is only when you know what you produce that you can begin to consider how to produce it better.

TIP: In Process Navigator, the things you produce are shown as Deliverables on your process maps.

How Do I Produce Them?

This may also sound like a simple question, but it depends on the complexity of the processes you are involved in. ‘Complete end of year accounts’ as an Activity is rather complex and takes some defining, but ‘Check the payroll’, ‘Post the mail’, ‘Proof-read the report’ are all quite straightforward and don’t require much definition.

What Raw Materials Do I Need?

This is a similar question to ‘What do I produce?’ In order to carry out your Activities, there are a host of things you need. 

TIP: Process Navigator shows these as Input Deliverables on your process maps.

Am I Happy with My Suppliers?

Your suppliers will assume that you are satisfied until you tell them otherwise. Today’s buyers do not wait around for a slow response and will not buy again if the goods or service are below quality. The buyer’s attitude should permeate every aspect of your organisation. If you are not getting what you need from your suppliers, when you need it and at a good enough level of quality, it is your duty to help your suppliers to improve by telling them. If you are not getting what you need, then either the company is spending more than it should in the production process because you have to rectify mistakes, or the customer is not getting the best quality goods.  It is important to remember that Suppliers and Customers can be internal to your organisation as well as external to your organisation.

Who Are My Customers?

If you do not know who your customers are, how can you know if you are producing what they need? When you draw your process map, think about who uses the items you produce. Go and talk to them, check that they use what you produce in the form you have supplied.

Are My Customers Happy?

Your customers count for so much; they are the reason you have a job at all, and it is your job to make sure you give them what they need.

Customers do not have to be outside your company; your customers are anyone that uses your Outputs. If they are not happy with what you produce, then there is no stronger indication that what you produce, or the way you produce it, should change; so ask them!

Working Documents

Working documents enable you to gather and record the information you will need to map your processes. As you become more skilled with Process Navigator, you may very well be able to write this information directly into the diagram. Often, however, it is helpful to use intermediate working documents to help clarify a process before it is mapped.

Some of the most useful formats are listed in this section.

IPO Tables

IPO stands for Inputs Processing Outputs. Process Navigator follows precisely the same principles.

Inputs (noun)

Processing (verb)

Outputs (noun)

 

 

 

 

 

 

 

 

 

IPO tables originate from software engineering but can be equally usefully applied to the study of business processes.

A row from a sample IPO table is shown below.

Inputs (Deliverable)

Processing (Activity)

Outputs (Deliverable)

Vacant Position

Define Job Role

Job Specification

Job Specification

Pass to DH for approval

Recruitment Brief

IPO tables translate directly into Process Navigator maps. The following diagram shows how the IPO table above can be represented as a map.

A common extension to an IPO table is a SIPOC table, with Suppliers and Customers listed in the S and C columns.

Constructing an IPO Table

The preferred technique is to consider Outputs first, i.e. ask the question "What do I produce?"  Write down everything you can think of in the third column of your IPO table. Things you produce will cover a wide range of possibilities: written reports, updated databases, date-stamped documents, signed authorisations, electronic files, e-mails, minutes, diary entries…  the list goes on and on. You may also produce Outputs that are not tangible, such as improved communications, better team motivation, undocumented decisions and enhanced knowledge.

Once you have written down everything you produce, the next step is to ask, "How do I produce it?", i.e., by what mechanism do the Outputs you produce come into existence? Give the Activities a short descriptive name, and write this name in the middle column next to the Deliverable it produces.

The final step is to fill in column 1, the Inputs, with the things you need in order to carry out the Activities listed in the central column. This is in some ways the easiest part of the exercise, because the things you need will generally all be tangible.

Work Diary

A work diary is an extremely useful way of identifying Activities you carry out. Set yourself the task of recording how your time is spent every day for, say, a fortnight. You may well be amazed what it reveals! Anything you spend time on is an Activity. When used in conjunction with the IPO Table, a Work Diary will help identify additional Activities that produce intangible Deliverables and unproductive Activities that produce nothing.

A sample work diary may be as follows:

Time

Description

Activity

Deliverable

08.30 – 10.30

Checked e-mails and went to the team sales meeting

Hold sales meeting

?

10.30 – 12.30

Worked on the management strategy report

Produce Management Strategy Report

Strategy Report

13.15 – 13.45

Chatted to Francis about the trade conference next week to make sure all the travel arrangements were taken care of

?

?

13.45 – 16.00

Wrote the job specification for the new position that becomes available when Mike leaves

Produce Job Specification

Job Specification

16.00 – 17.00

Various e-mails and administration

 

?

Question marks in the Work Diary’s Activity and Deliverables column will generally require some thought and trigger some searching questions:

  • Shouldn't we be taking minutes after a sales team meeting so that decisions can be recorded and referred to? What is the point of having a sales meeting? What do we expect to deliver in a sales meeting?
  • Is ‘various e-mails and administration’ actually productive, i.e. does it contribute to the production of a Deliverable that my customer requires?
  • How do I know my chat with Francis was productive? What did we actually produce? Of which process was this a part?

Once the work diary is completed, transfer new information into the IPO Table. The IPO Table and the Work Diary will together capture the bulk of Activities you perform and the Deliverables you produce. This information can now be used to establish the worker interfaces of which you are a part. A worker interface is the point where a person completes a task and then hands it to the next person in the process in order for them to continue production.

Customer Interview

The role of the customer interview is to:

  • Establish agreement on the Deliverables at the Worker interface. 
  • Derive a common naming scheme for the Deliverables.
  • Determine if there are ways to change the Worker interface so that the customer can do their work more efficiently.
  • Establish the level of customer satisfaction with the Deliverables.
Establish Agreement on the Deliverables at the Worker Interface

The Supplier IPO tables and the Customer IPO tables are used to do this. The supplier marks all Outputs they think the customer uses. The customer marks all Inputs they think derive from the supplier.

An agreement is reached by discussing the differences between the two lists and resolving any mismatches.

Derive a Common Naming Scheme for the Deliverables

It doesn't particularly matter how this is done, but it is important that the supplier and customer both use the same names. Normally it will be easy to agree on a name, but if not, adopt the customer's naming scheme. A common naming scheme is essential for Process Navigator to work correctly.

Can the Interface be Changed to Improve Customer Efficiency?

The customer needs to report to the supplier in clear, non-critical terms, how altering the Worker interface would be of benefit to them. For example:

"You currently send me the list of new enquirers in paper format, and then I enter them onto a database. It would save me time, and reduce the number of errors, if I could receive them in a format where they could be loaded directly into the database."

Now, an immediate and often quite wrong response to this would be:

"But that would mean me entering the records onto the database instead of you, I'm not doing that!"

A much better response is for the supplier to consider where the list of new enquirers comes from and to pass the request up the process chain until it gets to the person who actually creates the list, something like:

“Helen gives me the list to check over any interesting prospects before I pass it onto you. I wonder if Helen could find out if the list can be entered directly onto the database, and then I wouldn't need to pass it to you at all!"

The important thing to bear in mind when interviewing a customer is to restrict the conversation to the Deliverables at the Worker interface. Don't get drawn into a conversation about the steps taken to produce the Deliverables; simply assess if changes to the worker interface would be of benefit to the customer.

A customer request to reduce their workload is not lazy; it can often indicate that relatively minor changes to the upstream processes can have significant benefits further downstream and it doesn't stop at the external supplier boundary. It is perfectly in order for the modern organisation to request its suppliers to undertake tasks that ultimately mean it is able to produce goods or services more efficiently.

Establish Customer Satisfaction

If an organisation repeatedly fails to meet external customer expectation, it will go out of business. Exceptions to this rule, of course, are natural or protected monopolies, in which case the customer simply has to suffer the service levels often associated with such organisations. However, in most organisations, if competitors can do a better job of satisfying your customers, then your customer will soon move on.

For this reason, the modern organisation must constantly seek to improve its levels of customer service. The mentality required to do this must encompass the entire organisation and apply equally to internal as well as external customers.

Working practices tend to become embedded in an organisation because “things have always been done that way” and little effort is given to reassessing if, in fact, things should be done that way now. Establishing customer satisfaction is one method of identifying where old ways of working need to be replaced by better ways. If there are aspects of the Worker interface that means a person takes longer, spends more or struggles to produce quality, then this should be identified and sorted out.

The customer interview is a good way of establishing satisfaction.

Comments