Unit Tests For Business Processes!

In software refactoring best practice you usually start out refactoring test cases, so you can make sure that after your refactoring, you didn’t break the software system. How could this possibly be transferred to business process refactoring?

The basic difference between software products and business processes is: software products are being run by machines, while business processes are being run by human beings. No matter how formally correct an engineered business process solution may be, it tells us little about how the people will be able to accept or even work with them.

Therefore the sequence with business processes must be exactly vice versa as with software engineering:

1. Get people do and act according to your change draft, to learn about the look and feel of the changes as well as their ability to cope

2. Review the results and check against other existing business procedures. Goto step one, as long as adjustment may become necessary.

3. Sketch down the process formally for further communication. Document the process as slim as can be. Declare the change as implemented, as and only as people are already acting accordingly.

There is little use in formalizing your process reengineering down more than is necessary for an initial communication of the idea. There is even less use in losing pace by arguing on assisting the reengineered process with information techology prior to the retrospectives.