What are pretend processes? They're the confusing flowcharts and thirty-two chapter procedure documents that took months to write, but weren't used by anyone thereafter. They're typically difficult for business user to understand and out of date more often than not. Some people in the organisation know where to find them, some don't.

They are as much ‘business processes', as instructions for kit-set furniture written in a foreign language are ‘useful'. The pictures can be helpful, it's just hard to tell which way up they're meant to go.

These documents are static in nature and are produced by people who have little interest in ensuring that what they have captured continues to be managed on an ongoing basis as different forces collude to change the business process naged on an ongoing basis as an excuse for not bothering to manage processes. They aren't accessible for process participants, so even if they were easily understood, it's difficult to locate them.

So what are the costs of pretend processes? Is there even a problem? The organisation hasn't fallen over just because every last step of its activities aren't documented.

If key processes aren't defined, they can't be owned
Process owners can remain anonymous and avoid accountability for process failures, or worse avoid the leadership needed to coordinate process improvements across multiple teams. Process owners are replaced by ‘meetings'.

Multiple effort to understand the same processes
Without a central view of processes, or indeed ownership of processes, different areas can build understanding of the same processes separately, independently of other areas.

Different Areas working in opposition to each other
Without a single known view of an end to end process, the process efficiencies driven from different areas may work in natural opposition to each other. Sales Reps may seek to minimise information required from client visits, while from the marketing team's perspective, the more information gathered from each client the better.

Processes are continually rewritten
Most change projects need an understanding of current processes, because you can't change what you don't know. If processes can't be found or haven't been kept up to date for changes, there is no reliable understanding. So this knowledge needs to be recreated. In some cases this can take months and cost hundreds of thousands of dollars.

New staff – where do they find out how to perform their processes?
Processes that don't exist or can't be found can not be shared with new staff. Induction takes longer, and staff training is usually dependent on hands on training from the local process expert. Unfortunately this is that individual's view of the process, so any errors are propagated, and often can not give the ‘big picture' of why certain things are of key importance – such as things that can affect the end customer.

Process Knowledge Departing with Staff
Following on from the previous point, training of new staff comes with a significantly greater cost if it is the local expert that has departed and process knowledge has not been captured. The worst case scenario is that knowledge in certain processes must be rebuilt from scratch. Until this process knowledge is rebuilt the costs of processing delays are all hidden as normal operating costs. These can include errors that directly affect company bottom line - a delay to the release of a new product, or a customer lost due to repeated incorrect shipping of orders.

We need to hire business analysts to document our processes
Capturing processes is deemed a discipline requiring a specialist to assist with authoring. If you're designing a new house, you need plans drawn by an architect, if you are designing business processes, you need a business analyst to design process maps. The difference with business processes however, is that the end product needs to be a simple, useable guideline, accessible by all to help with performing a given set of tasks. The quality of process outputs should be designed against these criteria, not in their ability to be used as a technical document as part of a project or for use as a requirements document by other technical staff.

Coordinating updates to processes on the network / on the intranet
If processes aren't changeable by the process owners themselves this is both a barrier and a cost of change. This includes either:

• coordinating changes to processes published on the intranet - requiring meetings / involvement from web developers, or
  
  
• coordinating changes to static processes saved on a shared network.