Deciding on the Right Level of Business Process Documentation

One of the most ambiguous terms in business today is “process documentation”. It has become the key phrase looked for whether it’s a prospective employee looking for that process-centric organization, an employer trying to lure talented workers or a CEO providing proof of compliance to corporate auditors or assuring the Board of Directors that the organization has achieved a process maturity level consistent with its key goals and objectives. While the reasons for doing process documentation should be clearly communicated and accepted, it is equally as important that the type of documentation required be understood and consistent to meet the needs of the organization. When an organization does not fully understand the types of process documentation it has or needs, it is in danger of not only lacking what it needs for periodic reviews, audits, financial and operational compliance but also for sustaining the health of the organization. Monitoring and continuous improvement of business processes requires that they be documented to the level of detail needed to be effectively communicated, understood and applied.

The reasons for formally documenting business processes are varied and different levels of detail and tools may be required to adequately support them without creating unnecessary overhead. These reasons include:

1. Proof of financial and operational compliance
2. Provide better understanding of the business
3. Provide better understanding of the systems
4. Ensure consistent application of the process
5. Ensure consistent application of the business rules
6. Provide the means to establish benchmarks for monitoring and measuring process performance and results
7. Verification and reinforcement of business rules
8. Business improvement opportunities
9. Creation of specifications for new or enhanced systems
10. Training
11. Creation of work aids

Tools that can be used to document business processes include office tools such as Word, Excel, PowerPoint; simple diagramming tools; modeling tools that include a database, simulation and reporting capabilities; and BPM tools that include modeling, simulation, reporting and system interaction capabilities.

Documentation can take many forms including flow diagrams, written instructions, formal definitions/descriptions, screen prints, etc. Each level of the process hierarchy (process —> sub-process —> activity —> work procedure) requires a different level of documentation. If the purpose of the documentation is to identify the key business processes in the organization’s value chain and/or capture what each primary process is doing at a high level, then a process flow drawn with a simple diagramming tool supplemented with a table of process descriptions using a word-editor may be all that is required. This level of process is fairly static and only changes if there is a significant change in the organization’s focus or key objectives. A tool such as Word, Visio, Excel or PowerPoint is sufficient for this level of documentation.

Activities describe how a process is executed or performed.  This documentation describes the activity and its purpose, the business role that performs it, the technology used to enable or execute it, key metrics and the handoffs between roles and organizations. The ability to identify redundancy, duplication, gaps and bottlenecks is a key focus. Capturing this information can also be done using a simple diagramming tool. However, depending on the reason for the documentation, using a tool with sophisticated modeling capability and a database that provides reusability, standardization and reporting functionality may be a better choice.  These tools treat each artifact, whether it is a process, sub-process, activity, actor/role or application, as a unique object. This not only provides reusability and standardization but makes maintaining the documentation easier as changes to objects are automatically reflected everywhere it is used.

Work procedure documentation generally takes the form of user manuals which may include screen shots along with the detailed steps to perform the activity.  Depending on the level of information entered about the activity and the reporting capability of the tool, the work procedure document may be generated from the process documentation database. However, if the work procedure will be automated to interact with other systems, then a BPM tool should be used. Business processes should also be documented using a BPM tool when simulation capabilities are desired.

When considering the level of detail and type of process documentation required, the following questions should be asked:

• Will it be used primarily to understand the current state?
• Will it be used as input to functional/technical specifications?
• Will it be used for or as input to training manuals?
• Will it be used for or as input to user manuals?
• Is the process documentation an interim or final project deliverable?
• If not a project deliverable, does it support a deliverable?
• Are there existing company standards?
• Will the documentation be updated regularly?
• Will resources be available to keep the process documentation current?
• Will the documentation be formally signed off by the business user?
• What is the audience for the documentation?
• What level of detail is required to meet the objective?
• Would a cost analysis support the level of detail?

When considering the type of tool that should be used, these questions should be asked:

• How critical is the process documentation to the business?
• Are processes considered assets of the organization?
• Is there a need for an automated process repository?
• Does the tool need to interact with the organization’s systems?
• What functionality is required to support the type and level of documentation needed?
• Does the project plan include time to research and evaluate tools?
• Has training and ramp up time been budgeted?
• Is a business rules engine required?
• What is the process maturity level of the organization?
• What is the organization’s long term strategy for BPM?

The answers to these questions should lead to a better understanding of the type of documentation and tools needed to support the organization’s process documentation strategy.