"We didn't know what our process was until IT implemented it wrong." --Common business complaint
"When you get to 'business process' documentation, you aren't documenting business processes, you are recording business activities." --Common business saying
In my practice, I haven't seen many business processes documented. At the same time, I've seen many cases when the same business process was documented several times. A business analyst for each new project drew diagrams oriented to the needs of the project. Later, it was not obvious that the diagrams from different projects reflected the same process.
Why do IT projects have to "discover" business processes instead of reusing business descriptions (documentation) of those processes? Some people say that documenting processes is too difficult because of complex logic that process workers use. Well, if this logic is not documented, how would we know that the same logic is used in every process cycle? That is, how would we know that have a business process and not a business case where a human worker is dynamically re-designing the process every time it is performed? If, regrettably, we receive unstable results of such non-documented business process and need to improve it by analyzing reasons and consequences, isn't this a useless exercise because we cannot compare same to same because each processes "repetition" is unique?
We also can ask ourselves: If the process works and produces what is expected, why bother documenting it? In my opinion, people who act on this suggestion--that is, don't fix until it breaks--are either lazy or reckless.
Why does a non-documented process work? Either because the people involved know what to do or because the process manager knows the process by heart and manages workers appropriately. But this approach reminds me of a ship in the middle of the ocean piloted by a captain who has neither maps not navigation instruments. I would stay as far away from this ship as possible.
There are many examples of people who deliberately don't document business processes to safeguard their own role in the company. If you are a decision maker and you have spotted such a person, you should know who is the first candidate for redundancy in your company.
Anything that should be done more than once or that involves different workers over the time should be documented. If it isn't documented, it will be impossible to fix it. A transfer of tacit knowledge is ineffective; it's impossible to improve or manage it effectively because humans tend to forget reasons and dependencies. This is why documentation was created in the first place.
What does documenting a business process involve? If you document a business activity--someone has to do this and this--how can you prove that this activity describes process "A" and not process "B?" Are you saying that if the activity belongs to process A, nobody else may use it? I believe many would disagree with such an approach.
Here's another view related to a business process defined as a collection of activities. It doesn't matter how well you document this collection, it's not documentation of a process. The most important information about a process to be documented is the information about its business logic--that is, the. rules applied at each process step that manifest the decision for what should be done in the next step. Moreover, for the process to move from step to step, only certain values are important, not the activities that produce these values.
In this line of thought, if the process logic is documented, it becomes irrelevant whether particular values are produced by the work of John and Sally or by Susan and Peter. In other words, contrary to common opinion, people aren't a part of the business process description--only the skills required for particular process site should be documented.
The minimal documentation of a business process should include:
1) Input information
3) Process business logic
4) Expected values (results/effects) for each step of the process
5) Means for how those values may be accessed and used in the process logic
If you imagine a relatively wide structure of business processes where one process may be a super process and a sub-process for other processes, and the whole structure works as expected, one additional type of information will be needed. This is a quality of processes usually expressed in the form of service level agreements (SLAs). The SLAs should be applied to the business process as a whole and to each values acquisition at each step of each process. If this information is not documented upfront, the entire process structure will quickly get out of hand.
Business process documentation is a must-have attribute of business process management. This attribute survives a transformation from a manual business process into an automated procedure. The logic of such a procedure, as well as all input intermediary values and final results, must be documented in easily readable form. Otherwise, this piece of business logic and related business values may be lost--that is, forgotten--even before its developer leaves the company.
Final thought: Having documents and not updating them, and as a result, not reading them, is a threat to any company that uses business processes. However, if the business logic you realize includes a knowledge expert as an intermediary decision maker, that's not a business process and, therefore, has its own reasons as well as different content to be documented.
Merry Christmas to those who celebrate!