Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

The value of business process documentation

user-pic
Vote 0 Votes
"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
2) Outcome
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!


WebSiteAdvert.jpg


ActualBookCover.jpg


Website counter

6 Comments

| Leave a comment

"Anything that should be done more than once or assumes different workers over the time, should be documented."

I definitely agree with you on that point. When a process only exists in someone's head the process doesn't really exist. There needs to be a plan/map for your business to follow so everyone is up to speed.

If you don't have time to document your business processes, then how well will you really know your business process and be able to manage that same business process?

It all comes down to "seat of the pants" management or business process management -- which one will lead you to success?

Businesses that are in it for the long haul eventually end up with business process management. Only some will get there inefficiently with a lot of waste because they chose to NOT document their business process.

I used to work at a big 4 accounting firm, performing audits of information system controls over financial reporting, and this is right on the money!

When I performed an audit, the first thing we would do is request the policy and procedure for each control under review. When we received bad procedures (or no procedures), the control almost always failed to be operating effectively because everything was inconsistent. Either it wasn't performed the same every time, or it wasn't performed at all.

I never came across a scenario where somebody didn't document a procedure in order to save their job. Mostly it was because the bureaucracy (it took forever to approve procedures) or because changes were made so frequently that technical writers couldn't keep up.

Whatever the reason, if people don't make time to document processes, they're going to regret it come audit season.

I have a few points to Jonathan.

1) Did you qualify that "received bad procedures (or no procedures), the control almost always failed to be operating effectively because everything was inconsistent" led to the fact of violation of Basel 2 or 3, MiFID, SoX regulations?

2) I think that by saying "somebody didn't document a procedure in order to save their job" you meant to say something like 'to save their work efforts'. In this case, let me refer you to the famous Agile Methodology and its flavours like Scrum and Lean that declare in open that the documentation of developed systems should be minimised. De-facto, this means that provided documentation (in majority of cases I saw) was at the level suitable the developer to understand what s/he did, nothing more.

3) Do you know any regulations (in audit area, at least) that specify what level of documentation must/should be provided for, e.g., financial electronic systems, processes, and procedures?

Michael,

1) I audited Federal information systems, so we held them to Federal standards like FIPS 200 and NIST SP 800-53. They also required there to be documentation in order to pass an audit, so yes, the control would fail due to lack of proper documentation. But I wanted to emphasize the fact that when there was no documentation, it failed to operate effectively too because nobody knew what was going on.

2) I was responding to your comment, "There are many examples of people who deliberately don't document business processes to safeguard their own role in the company." Although I acknowledge that this could potentially be a problem, I personally haven't come across that in my career.

3) The regulations that I followed were specific to Federal information systems. For practically all Federal audits, we used the NIST 800 series (mostly 800-53) along with some other regulations coming from OMB circulars and such.

Jonathan,

I would not expect finding cases of "minimising" documentation in Federal or even local Government offices; the same relates to the UK Government offices where I worked. Nonetheless, in private sector IT, I saw it too many times to ignore.

As I mentioned before, Agile Methodology related methods like Scrum or Lean even promote an idea of minimisation of documentation. As a consulting enterprise solutions architect, I face situations that even recent applications (less than 5-7 years old) are left in companies with no adequate specifications/documentation because its were deliberately minimised to deliver projects 'on time and on budget' while the original developers were sequentially lost due to downsizing during the crisis time or simply due to outsourcing.

Anyway, thank you for pointing to the standards.

Leave a comment

In this blog, Michael Poulin writes about business and technology ideas, concepts, methodologies and solutions leading to service-oriented enterprise, the primary instrument for obtaining business objectives in fast-changing environments.

Michael Poulin

Michael Poulin is an enterprise-level solution architect working in the financial industry in the U.K. and the United States.

He specializes in building bridges between business needs and technology capabilities with emphasis on business and technical efficiency, scalability, robustness and manageability. He writes about service orientation, application security and use of modern technologies for solving business problems. He contributes to OASIS SOA standards as an independent member and is listed in the the international "Who's Who of Information Technology" for 2001. View more

Subscribe

 Subscribe in a reader

Recently Commented On

Categories

Monthly Archives

Blogs

ADVERTISEMENT