Process document contents
From TechWriter Wiki
Contents |
Introduction
This article provides a suggestion for the contents of a typical process document. For any given project not all of this information will be required. Conversely, in some cases additional information may be required. You should consider this article as a 'picklist' of the sections that can be used, and pick those sections that you feel meet your (or your project's) requirements. You may also choose to group these sections differently from the way they are grouped below. For example, you could choose to list Monitoring and Controls under Governance, or group Governance and Roles and Responsibilities together, and so on.
Once the required information is decided upon for a set of process documents (typically for a project, system, or organization), it is essential that this set of information is provided consistently across all of the process documents in the set.
Note that the examples included below are (deliberately) not all taken from the same process. Rather, samples where taken from whichever process could best illustrate the requirements. You should therefore not attempt to 'stitch together' all of these examples and expect to end up with a coherent example of a single process document.
The Overview section
The Overview section provides a high-level introduction to the process.
Process summary
The Process summary should consist of a very brief (two or three paragraph) explanation of the process. The principle purpose of this section is to allow users quickly to determine the scope of the process - and subsequently determine whether or not they are referring to the correct document, before they get into the details.
Example:
Overview
This document describes the Customer Complaints process. This process covers all complaints received from customers, regardless of the type of customer, medium by which the complaint is received, or the nature of the complaint.
Complaints from customers are received by Customer Service. All complaints are logged in the system, and a Complaint Agent assigned to the complaint. The Complaint Agent coordinates the activities of all parties involved in investigating and resolving the complaint (for example, Customer Service, Manufacturing, Accounting, and so on), and provides feedback to the customer once the complaint has been addressed.
Purpose of the process
The Purpose of the process effectively identifies the reason for the existence of the process: what is it achieving, or controlling? This section should effectively address the question of "Why are we doing this?".
Example:
Purpose of the process
The primary purposes of the Customer Complaints process are:
- To ensure that all customer complaints are captured in the system;
- To ensure that all customer complaints are handled in a timely and effective manner;
- To facilitate effective tracking of customer complaint levels and resolution times.
Guiding Principles
The Guiding Principlesshould identify the key principles on which the process design was based. This will typically be the 'boundaries' that were set by Management as input to the high-level design of the process. This information is useful for framing any discussions about the document - for example, when changes to the process are being proposed, or if clarification is sought in the event of the the document being deemed unclear or ambiguous on any point.
Example:
Principles behind the process
The Invoice Customer process was developed according to the following key principles:
- Invoices are generated as soon as all necessary information is available (this will generally be after product dispatch, once final delivery volumes are known);
- Invoices are generated automatically where this is possible;
- Where all data used on the invoice is taken from the system (and has therefore been approved in other processes) additional approval of the invoice document is not required.
The Context of the Process section
The purpose of the Context of the Process is to allow readers to identify where this process fits into the bigger picture - soecifically in relation to other processes within the process model.
Position in the process model
This provides an excerpt of the Process Decomposition should be provided, including the current process, its parent and all other sub-processes of this parent, and (where applicable) the sub-processes of this process. (So effectively: this process, one level up, and one level down.) In some cases, and particularly for 'deep' hierarchies (with many levels) it may be worth providing more than one level up and/or down to give the readers a better understanding of the overall position of this process, without having to work their way back through the parent process in successive documents.
Example:
Context of the process
The following diagram identifies the position of the Account for Fixed Assets Process within the corporate Process Model:
Note that where the decomposition diagram includes a relatively large number of processes (nodes) it may be worthwhile highlighting the current process (that is, the one being described by the process document), as has been done in the example above.
Sub-process description
Where the process consists of (or contains) one or more sub-processes, it is a good idea to provide a brief (one or two paragraph) description of each of the sub-process, similar to the Overview provided for this process as a whole. Note that this would normally only be necessary where these sub-processes are documented in full within the same document (in which case the Process Description section will normally be repeated per sub-process.
Example:
Process decomposition
The Account for Fixed Assets Process consists of three sub-processes, as identified in the table below:
Sub-process Description 6.1.1.1
Manufactured Asset CapitalizationThis sub-process covers the capitalization of assets that have been manufactured within the corporation, such as new buildings or facilities. This sub-process is typically executed in response to the completion of a capital project. 6.1.1.2
Account for Acquired AssetsThis sub-process covers accounting for assets that have been purchased by the corporation. 6.1.1.3
Asset DisposalThis sub-process covers the disposal of existing capitalized assets, regardless of whether these were produced or procured. 'Disposal' here is taken to mean removal of the value of the asset from the corporate books, and therefore covers write-off, sale, or transfer.
Inputs and outputs
In some cases it is useful to provide a list of the inputs to, and outputs from, this process. Here, you should include both data sources that are referred to (read) and updated from (written) within this process, as well as details of triggers that initiate this process, and triggers of other processes that are initiated by this process. The purpose of providing this information here is to easily identify interdependencies between processes.
The Governance section
This section should identify the managerial responsibilities for the process. In particular it should identify the following:
- The Process Owner. This is the person who officially owns the design of the process. This, therefore, will be the person to whom requests for changes to the process should be made.
- the Accountable Line Manager. This is the person who is responsible for making sure that the process is followed correctly (i.e. the person who gets kicked if it goes wrong).
Example:
Process Owner
The Vendor Payment process is owned by the Corporate Financial Controller.
Accountable Line Manager
Accounts Payable Team Leaders are responsible for ensuring that the Vendor Payment process is executed correctly for vendors within their local jurisdiction.
The Roles and Responsibilities section
The Roles and Responsibilities' section provides a concise summary of the positions or organizations involved in the execution of the process, and lists their individual responsibilities.
Note that this same information will be provided in the Process Description. However, it is sometimes beneficial to pull out (actually, duplicate) this information in a separate section of its own, especially for complex processes, or those consisting of a number of sub-processes. Gathering this information into a single section allows users to quickly identify their own responsibilities. Conversely, it will allow people to quickly identify who is responsible for a particular activity, without having to scan through the process description itself. This section can also provide useful input to Role Description Documents and/or Change Description Documents where these are being produced separately.
Roles and Responsibilities table
Example:
Roles and responsibilities
The following personnel are involved in the execution of the Handle Payment Guarantees Process:
Role Responsibility Documentary Credit Coordinator
- Creating and updating financial documents;
- Reviewing all exceptions relating to Letter of Credit processing;
- Checking the need for LC confirmation, and obtaining exception approval.
Credit Releaser
- Releasing non-individually secured sales orders from credit blocks.
Customer Order Clerk
- Creating sales quotations;
- Creating sales orders;
- Assigning Financial Documents to sales orders;
- Notifying the Documentary Credit Coordinator if a Financial Document is not valid.
RACI charts
A RACI chart is a way of showing the people involved in a project, process or system. RACI stands for Responsible, Accountable, Consulted, and Informed and identifies, for each task or activity, the person, position, or organization responsible for carrying out the task, accountable for ensuring the task is carried out, consulted regarding the execution of the task, and informed about the execution of the task.
RACI charts are not really intended for documenting processes, but they can be an effective way of presenting processes, especially those where multiple people may be involved (in the capacities just mentioned) in the execution of the process tasks.
Example:
| Activity | Customer Service Manager | Accounts Receivable Manager | Documentary Credit Coordinator | Credit Releaser | Customer Order Clerk |
| Creating and updating financial documents | A | R | C | ||
| Reviewing all exceptions relating to Letter of Credit processing | A | R | C | I | |
| Checking the need for LC confirmation, and obtaining exception approval | A | R | C | I | |
| Releasing non-individually secured sales orders from credit blocks | A | I | R | I | |
| Creating sales quotations | A | R | |||
| Creating sales orders | A | R | |||
| Assigning Financial Documents to sales orders | A | C | I | R | |
| Notifying the Documentary Credit Coordinator if a Financial Document is not valid | A | I | R |
The Process Description section
The Process Description is the center piece of the process, and the section that will be referred to the most. Often the process description is the first section written (although strictly speaking the Principles behind the process should be developed first). The process description is also often used in business impact assessments, gap analysis workshops, and training.
Possible forms of presentation for the process description.
- Stage Table - use when no complex/conditional paths;
- When...Then Table - use when there are conditional responses;
- Flowchart (a.k.a. Flow Diagram) - use when there are conditional paths, or where graphics are required;
- Cycle Chart - use where process repeats itself.
Because a process is typically describing the interdependency between a number of discrete operations (even if this interdependency is limited to sequential execution), processes lend themselves very well to being documented in flowchart form.
Flowcharts make it very easy to identify the sequence of activities, and the flow of control and/or information between these activities. However, flowcharts are often limited by the amount of descriptive text that can be included on them. If an activity is represented by a single box (as is typically the case) then it is difficult to include anything other than a short, often abbreviated, indication of the activity. Most activities require (or at least benefit from) a more detailed explanation.
The alternative is to provide a detailed explanation in the form of a narrative - a descriptive text, typically provided in document form, and often as a series of steps. Because documents are not (normally) limited in length, the narrative can contain as much detail as is required.
However, it is often difficult to depict anything other than a purely linear sequence of activities in narrative form. Asking readers to negotiate conditional branches, complex interdependencies, or parallel activities can be difficult (but not impossible) in a purely textual narrative.
Therefore, both flowcharts and narratives have their advantages and disadvantages. Fortunately, the two complement each other very well, and so the ideal (and recommended) solution is to use both a flowchart and a narrative to document a single business process. The flowchart provides a concise representation of the activities and their interdependencies, and the narrative provides a more detailed explanation of these activities.
Flowcharts
Quite often it will be necessary to develop both a flow diagram and a stage table. This is because it is simply not possible to provide all of the information required in the boxes on the flowchart (due to space constraints), so the flowchart will contain a very short descriptive text in each box, and the stage table will contain the full, detailed explanation. This may sound like a duplication of information (not to mention effort), but it is an approach that works well, because readers just requiring a quick summary of the overall process can refer to the flowchart, and readers needing more information, or clarification on a step, can refer to the stage table.
If this approach (of having a flowchart and a stage table) is followed, then it is absolutely essential to make sure that the two documents match up, and that it is extremely easy to identify the position on the flowchart a stage relates to (and vice versa).
See also:
Top-to-bottom flowchart
With a top-to-bottom flow, the roles responsible for carrying out the task are shown along the top of the page. The actions are shown below the roles that carry them out, in the order in which they are carried out. Arrows are used to indicate the flow from one task to another.
In general, try to start with the first task in the upper-left corner of the flowchart. This means that the role that initiates the process will be shown on the left. This may not always be possible (for example, to ensure consistency of role ordering with other flowcharts), but the first task should always be in the top row.
Left-to-right flowchart
With a left-to-right flow, the roles responsible for carrying out the task are shown along the leftmost edge of the flowchart. The actions are shown horizontally aligned with these roles. Again, these are best shown in the order in which they are carried out, from left to right.
Again, try to start in the upper left corner of the flowchart, proceeding (as far as possible) to the bottom right corner of the flowchart.
Left-to-Right flows do not work particularly well when embedded in a portrait-format document, as they either need to be shrunk down to fit within the portrait page, or rotated, which is less convenient for the reader. They do work well for presentation on-screen (the physical screen is almost always in landscape layout) - for example, when included in a PowerPoint (or similar) presentation.
Narratives
Step tables
With a step table, the steps - which normally correlate to individual tasks - within the process are presented in a tabular form. Each step is numbered, to emphasize that the steps are carried out in the order shows (remember the difference between bulleted lists and numbered lists: numbered lists imply order, whereas bulleted lists do not). For easier scanning, it is often useful to show a short statement of the task in one column, and a more detailed description alongside it.
Example:
Process steps
The following table lists the primary steps in the Handle Customer Order Process:
Step Activity Description 1 Place order This process is triggered by the receipt of an order from a customer. This may be received by telephone, fax, or e-mail. 2 Enter customer order into the system The order is received by Customer Services, who records the order in the system via transaction VA01. 3 Organize delivery The Dispatcher is constantly monitoring the delivery queue, and will see the order once it has been accepted. The Dispatcher checks the delivery address and the required quantities, and arranges adequate transport for this. The registration number of the assigned truck are entered into the system via transaction VL01.
4 Pick, pack and dispatch ordered product On the day of the delivery, the Warehouse Operator is automatically notified of the delivery by the system. The Warehouse Operator retrieves the required products from the warehouse, and loads these onto the truck specified in the delivery instructions.
5 Record dispatch in the system The Warehouse Operator records the dispatch in the system via transaction VL02. This results in an order confirmation automatically being generated and sent to the customer. 6 Issue invoice Recording of the dispatch in the system automatically creates an outstanding receivable in the system. Each day, Customer Accounts creates invoices for all new outstanding receivables, and mails these to the customer, via transaction VF01. 7 Make payment via post The customer subsequently receives the invoice, and mails their payment to Customer Accounts, along with the remittance slip. 8 Clear payment against receivable Once the customer’s payment is received, Customer Accounts use it to clear the outstanding receivable on the customer’s account via transaction FLB1. If the customer has not specified the invoice number with their remittance, Customer Accounts attempts to manually match the payment. If they cannot, they contact the customer for the missing information.
In this example the role names are shown in bold. This makes it easier to for users scanning the document to easily identify the steps for which they are responsible. The transaction codes have also been placed in bold to allow these to easily be located. Both of these formatting conventions are optional.
Note where the step table is used in conjunction with a flowchart, the text used in the Activity column should be the same as the text shown on the flowchart (see the sample flowcharts above). This is to allow easy cross-referencing between the two. Other options are to include step numbers in each activity box on the flowchart, or to include the step numbers in the margin of the flowchart (although this can present problems when a single row (for a top-to-bottom flowchart) includes multiple steps. This example also illustrates the disparity between the amount of text needed to adequately describe the process step (the text in the Description column), and the amount of text that will comfortably fit within the activity block on the flowchart (the text in the Activity column).
Hybrid flowchart / narrative
The hybrid table includes both the process narrative (stage table) and the flowchart in a single illustration. Because the narrative text is included, the flowchart steps are reduced to numeric indicators. This is useful as it emphasizes the order in which the steps are carried out.
Because the length of the next tends to vary (and can be quite long if this is the only form of text) the spacing between the activities on the flowchart tends to be inconsistent, which results in a less aesthetically pleasing result. With (relatively) long processes this can also lead to the flowchart breaking over multiple pages, which reduced readability. The solution here is to still provide a detailed narrative, and only use the hybrid flow as a summary. One could then argue what the point in using the hybrid flow is. The main advantage would be that you can fit more roles on a hybrid flowchart (because they are much narrower, consisting solely of a number) than on a 'standard' flowchart.
The Monitoring and Controls section
Monitoring and Controls should describe the stewardship measures that are in place to ensure that the process is working (that is, that the process is achieving the desired result). This could include 'hard' controls to ensure that the process is being followed, or measurements to assess performance of the process. Note that this information is often embedded into the process steps (and therefore described in the Process description section). This section (Monitoring and Controls) simply provides a concise summary to allow those people primarily interested in controls to identify the controls without having to pick through the process description.
Measures used to control the process
List all of the controls that exist within the process, to ensure that the process is followed correctly. This may include:
- Proactive controls to ensure that only the required actions can be carried out (for example, access controls to ensure that only authorized users can perform the process activities);
- Retroactive controls to confirm that required actions have been carried out (for example, a control report of actions taken).
For each control, it is necessary to identify who is performing the control, and what they do if the control has been breached.
Example:
Measures used to control the process The following controls have been established to ensure correct execution of the Vendor Payment Process:
- Invoices will only be paid if the invoice quantity matches the goods receipt quantity, and the invoice value matches the purchase order value.
- All manual adjustments to invoices are captured on the Invoice Change Report, which is reviewed by the Accounts Payable Supervisor.
Measures used to assess the process
List all of the reports and statistics that are used to measure the efficiency or accuracy of the process. These may also be referred to as Key Performance Indicators, or KPIs. For each identified measure, provide a brief description of the measurement, and indicate how the measurement is taken. Again, it is important to identify who reviews the measurements, and what they do with these measurements.
Example:
Measures used to assess the process
The following measures are used to monitor and assess the execution of the Vendor Payment Process:
- The number of payments made by the due date. This figure is calculated automatically, and is available on the Payment Statistics Report, which should be generated on the 1st of every calendar month.
- The number of invoices blocked. This figure can be retrieved from the standard FB03 transaction at any time. It should be captured monthly, on the 1st of every calendar month.
The Accounting Entries section
Provide 'T-diagrams' for each set of accounting bookings that result from the process. T-diagrams show the debit and/or credit bookings that are made to an account for a specific event.
Because each activity may result in financial bookings, it may be necessary to provide this information at the activity level. In this case, make sure that the subheading used for each set of accounting entries is the same as the activity name as to allow easy reference between the two.
The Glossary
Process documents will often include terminology that may not be familiar to the readers of the document. These terms should be explained, to facilitate a better understanding of the overall document.
Where a separate (project, system, or organization) glossary document exists, it may be sufficient to provide a reference (hyperlink, if on-line) to this - especially if the readers of the document will have easy and ready access to the glossary. However, where a separate glossary does not exist (shame on you!) or where it cannot be assumed that the readers of the process document will have access to this glossary at the time of reading), it may be worthwhile including a glossary of terms (for those terms introduced in the process document) within the process document itself.
