Writing process documents

From TechWriter Wiki

Introduction

This section provides some basic guidance on developing process documents.

Identifying processes

One of the most difficult tasks when developing process documents is working out exactly what constitutes a process. There are three primary things to consider:

1. Decomposition;
2. Level of detail;
3. Chunking.

Building a process decomposition

Often, a requirement is raised to provide process documents for an entire system or organization. In these cases, it is worth developing a process decomposition.

A process decomposition (sometimes called a process model) arranges all of the individual processes into a single, hierarchical (tree) structure. Taken as a whole, the process decomposition typically covers the entire operations of an organization or company, or the full scope of a project. The highest level of the hierarchy could be "Operate the company", with this activity being broken down into sub-processes of "Purchase raw materials", "Manufacture products" , and "Sell products". These sub-processes being broken down further, and so on, until the lowest level is reached (see Deciding on the correct level of detail below, for more information on this).

[Example TBD]

Note that when deciding on the correct level of detail for process documents, it is not strictly necessary for all process documents to be at the same level in the process decomposition. It may be the case that for some processes, the second level of decomposition is sufficiently detailed, but for others it is necessary to decompose the process to the sixth or seventh level before arriving at a level that can be meaningfully documented in a process document. As long as the process decomposition is available to identify the level at which the process documents exist, there should be no confusion.

It is worth developing a process decomposition for two primary reasons:

1. It provides a way of checking that all required processes have been identified and documented;
2. It provides a way for users to locate a specific process document. This is especially important where a documentation set includes a significant number of process documents (say, in excess of 40).

The difficulty in developing process decompositions is that it is sometimes difficult to find the correct place in the hierarchy for some processes - especially when the processes have been identified via a bottom-up approach.

A common source of confusion is 'master data' processes. Consider the process for defining product master data. Should this go under Purchasing, Manufacturing, or Sales? In fact, it relates to all three. Here, it is best to have a separate high-level branch of the hierarchy for Business Support, or even Data Maintenance.

Deciding on the correct level of detail

The most detailed level of the process documentation (that is, the lowest level of document identified in the process decomposition) should be at 'one level above the activity level'. This means that an activity in the process (a 'task box' on the process flowchart) should correspond to the execution of a single task. So what constitutes an activity? In brief, a activity is defined here as a task carried out by one person, from beginning to end, at one time (i.e., in a single 'sitting').

Using this definition, if a person enters a proposal into the system, waits for confirmation, and then confirms the proposal, that is two activities (1: Enter, 2: confirm) - with possibly another (external) activity in the middle. For ERP systems such as SAP, an activity is often the execution of a single transaction in the system.

When documenting a large application, system or organization, you will typically also be documenting procedures that describe how to execute the individual activities. The (lowest level of) process document should directly reference these procedures (in that an individual activity on the process document is documented itself in the form of a procedure).

Chunking

Chunking is arguably the most difficult part of developing process documents, and involves identifying the individual processes that comprise the entire process documentation set. The primary objective of chunking is to split operations into manageable chunks, with all 'chunks' being at a consistent level of detail. Each 'chunk' will then become a process.

Often, developing the process decomposition will drive the chunking, but sometimes it may be necessary to treat the process decomposition only as a 'first pass', with it being re-worked once the chunking is complete.

Chunking can be used to:

• Identify logical groupings of activities within the organization or system (for example, Commit order, Organize delivery, Inform parties);
• Identify sets of activities that take place at different times (for example, Daily balance, Monthly close, Annual close);
• Identify alternative activities within the process (for example, Maintain affiliate vendor, Maintain 3rd party vendor);
• Any combination of the above.

Deciding what constitutes a 'chunk' is very subjective. A useful rule of thumb is to limit process flowcharts to a single page. If it is longer than that then the chances are that it needs splitting. Limiting the flowchart to one page also greatly aids reader comprehension, as they can see the whole process at a glance - the more they have to flip between pages (or screens) the more difficult it is to follow the process. Bear in mind, however, that this is only a rule of thumb. It is not always necessary (or desirable) to split processes, and arbitrarily splitting a process just to adhere to a 'one process per page' guideline is unwise. It may be perfectly valid to have a single 50-step process flowchart split over several pages, if this makes the most sense - for example where the activities follow each other sequentially, without a break.

A useful approach is to just draw the process up as a single flowchart (print it out over several pages and tape them all together if you have to) and then look for logical breaks. Normally, they will be temporal splits - i.e. where the process pauses until something else happens. Sometimes it makes sense to split by organization or role involved - although it depends on the number of interactions between them. In other cases, it may make sense to chunk based on variations for different scenarios. For example, if a process consists of 20 steps, of which the first 10 steps are the same in all cases, but the last 10 are different for two distinct scenarios (or modes of operation), then you may want to have three processes: one for the first 10 steps, and then one process each the last 10 steps of each scenario. Here, it helps to think of the chunking as taking a 'Lego' approach - where blocks of activities are defined, and then these blocks assembled in different combinations to define the activities.

Try to avoid having overlapping processes (have a clean split from one to the next), and try to avoid having two processes covering the same activities from different perspectives (i.e. different roles) as it makes it difficult to tie them together and identify the touch-points.

Building watertight processes

The primary objective of a process document is to provide a clear, concise, and unambiguous description of how the business operates. When defining a process, ask questions similar to the ones outlined below:

• What needs to have happened before this process can be carried out?
• What data, information, or equipment is required for this process to be carried out?
• What triggers the process?
• What is the timing of the process? (When does it start? How long does it take? By when must it be complete?)
• For each task:
  • What is the task?
  • What is required (information or equipment) in order to execute the task, and where does the executor find this?
  • Who carries out the task?
  • Where is the task carried out?
  • What is the timing of the task? (Again: When does it start? How long does it take? By when must it be complete?)
  • What is the result of the task?
  • How does the flow of activity or control from one task to another take place?
    • Does the executor of one task need to tell the executor of the next task that they can now start their task?
    • How does information get passed from one task to another? Is there a form, or is there a system trigger?
• How do you know when the process is complete?
• What happens next?

The reader must never be left thinking, "And then what?". It is worth asking yourself (as the documenter of the process) this question, at every stage, and over and over again, until the question no longer needs to be asked.

Collecting the information

There are three basic ways of gathering the information required to write a process document. These are:

1. Gathering information from other available documentation;
2. Interviewing subject matter experts;
3. Holding process definition workshops.

Gathering information from other available documentation

This is probably the hardest way of writing process documents, and should only be undertaken if there is no other option. This approach will necessitate a more thorough review cycle than other methods.

Possible sources of information:

• Design documents;
• Work instructions (especially any 'Before you start' and 'Next steps' information);
• Job descriptions / roles and responsibilities;
• Workflow definitions;
• etc.

Interviewing subject matter experts

The difficulty with interviewing subject matter experts is identifying who are the experts. One option is the 'management level' expert who has possibly defined the process in the first place. This SME should be able to provide a high-level overview of the process as it should be executed. At the other end of the scale are the 'user level' experts. These are the people who are involved in the actual execution of the tasks within the process. These experts will be able to explain exactly how the process is carried out 'in the real world'.

Ideally, you should interview both types of expert, to get a full picture of the process. The problem is that there may well be a difference between how the 'management level' experts think the process is being carried out, and how the 'user level' experts are actually carrying it out. If there is such a discrepancy, you should check with the process owner as to which is correct. If users are not executing the process as it was designed this could be either because the users are circumventing the process - in which case the process owner needs to know about this (possibly to implement additional checks and controls) or because they have found a more efficient (and valid) way of working - in which case the process owner may want to consider officially adopting (and documenting) the adapted process.

See also: Working with SMEs

Process workshops

With process workshops, a selection of experts who know about, or are involved in the execution of, the process are gathered in a room, and work together to define the process. This is certainly the best approach, but it relies on a skilled facilitator to ensure that all participants actively contribute, and to drive the definition of the process to completion.

See also

• Process document contents