MENU Process Documentation Best Practice #1
#1 Make Sure Your Process Documentation Format Is Driven by Business Goals
When tasked with creating process documentation, the simplest path is to either buy software or download a template that can be used with Microsoft Office products (Word, Visio). That is certainly a convenient way to get started but it can also be a trap, leading you down a path toward a “successful” documentation initiative that delivers little or no business value.
There are three key questions to answer when considering what your process documentation should look like:
- What business goal or goals are we trying to achieve? (Function)
- What is the right level of detail to meet the above goal? (Form)
- What will be most “usable” by our target audience? (Fit)
Of these, the first is most important… and often the most overlooked. It’s easy to say, “I want a process map and SOPs,” and get started. But the work products are not an end in themselves. They are a medium to achieve consistent excellence and/or to satisfy regulators and/or to onboard employees, etc., etc. The Function should drive the Form.
For instance, if you are creating documentation to satisfy regulatory requirements, you probably want documentation components that focus on workflow and perhaps control points but have a lower level of detail. If the oversight agency requires extensive documentation for every process change, then unnecessary detail means you will experience excessive maintenance time/costs down the line.
On the other hand, if your goal is to eliminate exceptions/variations so that you have a clear work standard (and can train new employees to that standard) then you will want more detailed step-by-step instructions.
Or perhaps you are creating process documentation ahead of an ERP implementation. If so, your business goals probably include simplifying the processes before they become automated and creating documentation that will be the foundation for your business requirements.
These are three very different use cases for business process documentation. They require different outputs.
There are many elements your organization may incorporate into its process documentation. Orion’s sample packet contains 10 items:
This is not the “ideal” table of contents. Rather it is a menu of possibilities that contains more elements than any organization needs… and this sample does not even include IT-specific work products (e.g. use case diagrams) that some projects require.
Every process documentation packet should start with a clear statement of Purpose and Scope. It should end with your Documentation Governance standards. What goes in between? That’s what you have to decide based on your business goals. So, after the project is done:
- Who is going to use this process documentation?
- What do they need to accomplish for our business?
- What must we provide for them to enable item #2?
After you have considered those questions, select elements from the following list:
• System Map or SIPOC – Your business processes do not exist in a vacuum. Each is part of your larger business eco-system and often part of a cross-functional process. The SIPOC tool is a simple illustration of the Suppliers and Inputs that flow into the Process as well as the Outputs and downstream Customers, who may include internal customers (e.g. other departments). The System Map is an enhanced SIPOC that provides a 10,000-foot view of the value chain. It may include supplier and customer requirements. Include one of these tools in your packet if your employees would benefit from understanding the big picture.
• RACI – There are a few different ways to specify roles and responsibilities. You can use a simple table that includes each title and a list of responsibilities within this process. The RACI diagram specifies who is Responsible, Accountable, who can be Consulted, and who should be Informed during process execution. Use this tool if there has been a history of overlapping responsibilities or confusion over who makes decisions during process execution.
• Cross-Functional Process Map – This is the classic process map or “Swim Lane” flowchart of how work gets done. Almost every client Orion has worked with included this visual representation of work in their documentation packets.
Why? Because the cross-functional process map –more than any other tool– gives you an immediate sense for how work gets done from start to finish. In the diagram below, the green oval is the start point. In a real-world example, it would specify the trigger. The red oval is the endpoint. This could be a final action or a handoff to the next process.
In between, each row or swim lane is dedicated to a particular player, typically a job title or department name. Each rectangle describes an action with a simple verb-noun description. (The work details can be found in the Step-by-Step procedures.) The arrows trace the workflow. Simple. Clear. Easy to understand.
• Step-by-Step Procedures – This process narrative (or SOP) explains how work should be performed with clear how-to instructions, notes, exceptions and other information your practitioners need to get the job done. In advanced applications, this section can include videos and links to relevant forms. Combined with the cross-functional process map above, Step-by-Step Procedures are the heart of every business process documentation packet.
• Issues and Ideas – When exploring how a process is executed with the process performers, it is inevitable that you will unearth pain points and potential solutions. It is common to generate a dozen or more issues and ideas during each workshop. Even though this content will not be in the ongoing process documentation packet, it is a valuable by-product that many organizations now require during a documentation initiative.
• Performance Metrics – The Purpose and Scope section may include a performance target. (e.g. Invoices paid within 30 days.) Process documentation workshops will reveal additional key performance indicators (KPIs), including input metrics and work execution metrics. (Input metrics answer the question, “What should I be getting from my internal or external suppliers in order to do my job well?”)
• Process Risk Assessment – In some critical manufacturing processes (e.g. building a rocket that will carry humans into space), it is worthwhile to evaluate the likelihood of this process failing and assess the potential ramifications if it does fail.
• Control Points – Similar to the Process Risk assessment, a Control Point identifies a potential failure spot and specifies mitigations. This is most common in financial processes. A simple example would be if we are about to disperse more than $X,000 then you must get two signatures. Orion likes to indicate these control points on the Process Map with red triangles. A separate table describes the mitigation actions for each control point (triangle).
Again, every documentation packet should begin with a Purpose and Scope section that provides clarity on the process trigger, end point, and intended business outcome. Process Governance and Approvals should be on the final page. (More on that in Best Practice #6.)
After you select the other elements that will satisfy your organization’s business goal(s), make sure you use language, visuals, and formats that are accessible and relevant to intended users. Again, we must create business process documentation that fulfills the immediate business objective and delivers value to your team members year after year.