Why Do We Need Business Process Documentation?

Version 1

    If you haven't answered this  question read on.

    If you haven't asked this question, why not?


    I guess people are notorious for finding the speck in the other person's  eye.  In my case, it's helping people define and optimize Business Processes.  I  understand the concept, and work regularly with partners who have Business  Process design tools.  But I noticed that I have very lax standards with my own  personal processes, like checking my next day schedule before leaving work, or  setting all my out-of-office assistants when going on a business trip or  vacation. Shame on me - I promise to work on that!


    One excuse I hear for not documenting processes is that the process is too  creative to be documented.  This may be true for creating a work of art, or even  developing a system management software program, but most things we do are  somewhat redundant and would benefit from process analysis.


    If you think a process can't be documented, that means that a human is  dynamically re-designing the process every time it is performed. That  represents a real risk to your business, because that person may not be here  tomorrow.


    Anything that is done more than once, or by multiple people, should be  documented, if for no other reason than consistency.

    Once a process is documented, it can be monitored, managed, and improved.   Running processes without process documentation is like running programs without  the source code.  It works as long as it works, but who can fix it when it  doesn't work?  Who can even determine what went wrong?


    Computers can enable good process management, or they can interfere with it.   When you get a cool new software program, the temptation is to start using it  before you really understand how to use it effectively.  If it's good software,  it should provide process documentation for how to effectively use it.  Really  good software would provide really good process documentation, with graphical  diagrams, and monitoring/management interfaces built in.


    Hot new applications using SOA are being created using Business Process  modeling tools to create the process framework, so the composite software that  is generated from the process definition is directly linked to the  documentation. These types of applications are already instrumented for  management reporting and optimization.  Imagine that along with the application,  you also could get the tools needed to monitor where and how many processes are  running, who is executing them, how long they take on average, and where the  process bottlenecks are. You could also determine what the IT dependencies are,  and what business processes are impacted when these IT dependencies fail.


    Well documented and optimized processes can make the difference between a  good company and a great company, or even between profits and losses.  When  documenting existing or new processes, make sure to use software that supports  Model Driven Architecture and Enterprise Architecture frameworks. This will  allow you to build high-level abstract models that are realized in different  re-usable contexts.  Also, make sure that the process models can be integrated  with CMDB, so the process dependencies can be used to create Business Service  Impact Models (Service Models for short). Service Models can then be used to  automate incident and problem management processes, and improve your service  desk responsiveness.