subject: The Process Documentation Portfolio [print this page] The Process Documentation Portfolio The Process Documentation Portfolio
If an organization wants to get serious about documenting its processes, one of the first activities should be to determine what that process documentation should consist of. For many organizations, this is a difficult question because so few people in the organization have experience documenting processes in any form other than a simple (or complicated) flowchart. But a flowchart alone, even a great one, doesn't tell the whole story.
When an organization engages me and my team to document their processes, we have a standard approach to the work and a structured, defined set of documentation we deliver. Sometimes a client wants additional documents, other times fewer. Regardless of the engagement, we always have a foundation of standard documents to work from. That list of standard documents are as follows:
- Process Catalog
- Process/Procedure Flowcharts
- Data Flow Diagram
- Process Definition Document
- Logical Data Model
- Business Rules Matrix
- Process Language Glossary
- Process Documentation Repository
Process Catalog
At the very least, documenting processes should start with a list of the processes to be modeled.Even better would be to create a list of all of the organization's processes, regardless of which ones are modeled.I use the APQC's Process Classification Framework as a template or guideline for helping me make sure I've considered all processes which would generally be associated with a particular function.This categorized list of processes serves many functions throughout the documentation project and beyond.This includes keeping track of which processes to model, to tracking progress of modeling underway, to serving as the foundation for prioritizing process improvement projects.
Process/Procedure Flowcharts
Flowcharts are probably what most people think of when they think of process modeling.A flowchart is relatively easy to create - nearly anyone with a crayon can draw one.And, most of the time, even the most basic flowchart can effectively illustrate a process or procedure flow.
However, once an organization commits to a more deliberate and formal approach to process modeling, issues like quality, standardization, consistency, and control come into play.For these reasons, I recommend and use the industry standard, Business Process Modeling Notation (BPMN), as my modeling notation standard.
Three reasons for using BPMN are:
1. Business people prefer it - they find it easy to read and understand, plus, done correctly, it's usually free of technical acronyms and jargon
2. It's easy to learn and use - if you Google "BPMN" on the Web, you'll find thousands of references
3. Many commercial-grade, enterprise-class software suites for business process modeling (BPM), business process analysis (BPA), software requirements, and business process modeling software (BPMS) incorporate the BPMN standard into their proprietary modeling modules.
4. Because it's standardized with deeply detailed specifications for proper use (as described in the 400+ page specification published and maintained by the OMG),BPMN diagrams can be subjected to editing, compliance with modeling style guidelines, and other deliberate, quantitative, and qualitative controls and checks to ensure quality and consistency
Data Flow Diagram(s)
The focus of a Data Flow Diagram (DFD) is to more easily and concisely illustrate flows of data in a process.While a detailed BPMN diagram does specifically identify each discrete activity/step where data is created, read, updated, or deleted, a DFD can show a condensed view of all the data flow within a process.
In my experience, business people aren't usually the primary "beneficiaries" of Data Flow Diagrams.More commonly, it's thesoftware architects and programmers who have a use for a DFD.The DFD is another tool to help them identify data objects and elements - and where and when those objects and elements are manipulated.
Process Definition Document
The Process Definition Document (PDD) is a written description of the process.The sections commonly found in a PDD are
- Definition and Purpose of the Process
- Process Goal and Objectives
- Inputs and Outputs
- Resources (Capital, Equipment, and Human)
- Process Roles and Responsibilities
- Initating Business Events (Process "Triggers")
- Process Sequence (Procedure)
- Process Rules (Business Rules)
- Process Measurements
- Process Controls
- High-Level Process Diagram
- Validation (Process Owner and Stakeholder Acknowledgement and Agreement)
- Process Issues and Risks
- Outstanding Questions and Issues (with detailed Action Items and Statuses)
Logical Data Model
Data flow is a component of most business processes.In a typical business process, data is created, read, updated, and sometimes deleted.Defining this "C.R.U.D." model is essential to fully understanding how data is "processed." More importantly, computerization is common to most business processes, and many process modeling initiatives are (or should be) the prerequisite activity to defining software requirements for new or enhanced software.Thus, a Logical Data Model serves as the logical model for the subsequent physical database design the programmers will create or configure.The Logical Data Model should list all of the Objects and their individual elements or properties.These Objects and Properties are typically identified in process activities/steps to the point of specifying which specific Properties (data fields) require data entry, and which property values are valid.
Business Rules Matrix
The data objects that flow in and out of processes have "relationships" with each other.The Business Rules Matrix is used to compare those relationships.The comparison process asks, "For every Object A, how many Object B's can there be?""Can there be one?"Can there be more than one?""Can there be none?"And, if there can be none, "Under what situation(s) might that be true?"
For example, with an invoice, a question might be, "For each individual invoice, how any Line Items can be on it?"Most of the time, the answer will be "one or many."Obviously, if an Invoice would have no Line Items, curiosity alone would compel most people to ask, "Why?"
It's the questioning technique that exposes all the business rules.Besides notating them on the spreadsheet with a '1', 'M', or '0' (zero), it always helps to write a descriptive list of the rules to make it easier for business readers to understand.And, if you're modeling processes in support of software development, the Business Rules Matrix serves as a cross-reference to the Logical Data Model.Every object in the Business Rules Matrix should map to an Object in the Logical Data Model.
Process Language Glossary
Every organization has its similarities and unique differences in business process language, terms, phrases, synonyms, and slang.And many times, a process modeling project is an organization's first exposure to formal process management and improvement concepts - and process management frameworks.In those situations, the language of Lean Thinking, Six Sigma, Business Process Reengineering, Theory of Constraints, and Total Quality Management introduces a wide range of new terminology the organization needs to learn.In addition to defining the organization's unique language, the Process Language Glossary is the definitive list of all words, phrases, and acronyms related to process design, development, implementation, control, and improvement.
If for no other reason, the Process Language Glossary can be used to enable clarity and consistency.I typically see the same word used as both a noun and a verb - usually in different contexts.A word has one meaning in one context to one person but might have a different meaning in a different context to another person.Words within acronyms are often interchanged.
For example, on a recent project, there was the acronym, "SOA."Some people thought it stood for Sales Order Administrator.Others thought it stood for Sales Operations Administrator.While, on the surface, this might seem trivial, the two roles were actually distinct.Two different functional sub-departments had a defined SOA role, each with different responsibilities.In one, it was a Sales Order Administrator.In the other, it was Sales Operations Assistant.The Process Language Glossary listed the SOA acronym and, in its definition, identified and defined the two distinct roles
Process Documentation Repository
Given the range of tangible artifacts produced in a process documentation effort, there's a lot of stuff to keep organized and accessible.Most of the documentation is frequently revised, refined, and updated throughout the project.Because of this, it's important to keep track of versions, to ensure references and links are kept up-to-date, and to make it simple for anyone to access and view documentation.
Rather than just electronically (but arbitrarily) storing documents "on the shared drive," it's better to have a structured and disciplined documentation repository.There are many different techniques and software tools an organization can use to develop and manage a repository.Regardless of which technique/tool is used, the emphasis should always be on (A.) ease of identity, (B.) control and ease of access, and (C.) ease of use.
In addition, I always create and maintain "hard copies" of all documentation produced.Those hard copies are typically placed in one or more binders and I often create multiple binders to distribute to key stakeholders.While this represents more work on my part, my Clients always appreciate the binders - and use them far more often than they use electronic versions.
A Note about UML, its Diagrams, and its Artifacts
The Unified Modeling Language (UML) is another, well-adopted modeling notation which can be used, to some extent, to model business processes.However, in my experience, business people prefer the decidedly more "business-friendly" nature of the Business Process Modeling Notation.It's rare for me to expose UML diagrams to business people because so many have told me UML looks "too technical."I will, however, create UML diagrams for projects involving software development.While software architects and programmers typically appreciate BPMN diagrams, they are generally more familiar with UML.In time, with consistent use of BPMN in an organization, fewer UML diagrams and artifacts are used in the software development lifecycle.
Conclusion:
Not every organization or project calls for the full set of documentation listed above.Organizations and their reasons for documenting vary.For those organizations that understand and appreciate the far-reaching value of fully documented processes, a comprehensive, structured, focused, and disciplined process documentation approach is the foundation of an effective, continual process improvement culture - and a head start on establishing an enduring competitive advantage.
