Getting serious about process documentation
Consultants spend much of their time describing how things work in a business right now. We call it “documenting as-is processes”. The default tool and repository for this are PowerPoint and a file server, though processes are sometimes described only implicitly e.g. in software configurations and often they are not documented at all.
As a result of this, documentation is frequently out of date other than when projects are completed, inconsistent in terms of style, detail and depth and processes are inaccessible or unknown to other business and IT colleagues much of the time. There is also the unwelcome effect that front-line business staff are asked the same questions time after time to satisfy every project’s need to document the as-is processes. Organisations with a high level of resource churn may find that processes are not fully understood by anyone.
Without a clear, accurate and complete process baseline it can be extremely challenging to implement large-scale change projects.
Application developers often use tools such as IBM’s Rational System Architect® which support a huge variety of frameworks, models and standards. Typically, use of such tools is internal to the IT organisation and supports application development only but this need not be the case.
Wouldn’t it be better if the whole enterprise were to exploit architecture repository tools to document business processes?
The trick is to establish standards for process documentation that are:
- Mandatory across business and IT so that no area is undocumented
- Embedded so that ongoing changes are captured
- Lightweight so that only necessary detail is captured avoiding excess effort
- Standardised so that documentation is always interpreted correctly throughout the enterprise