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.