One of the more lively discussions I came across recently revolved around the selection of which Business Process to manage next / first.
From my previous post it should be obvious that I like simplifying things.
I would like to bring something into the general consciousness of those that wander into the wonderful world of BPM. For the lack of a better word, I would like to coin the phrase “footprint”.
A business process footprint is the amount of persons and resources it directly or indirectly affected through its operation.
Base logic underneath discussion.
If we imagine that we can “insert” a series or parallel approval into the standard request as a packaged node element, we should be able to discover that we can now address numerous different request types using a singular process. The higher level (request) the process can be standard, but internally or lower level (approval) we can now string together very complex structures to address the specific requirements of the specific request we have to address.
In such a construct we can see that certain processes can be “componentised” and packaged for use in other processes.
If we compare two processes with one another to describe “footprint” I would like to use leave request and pay invoice as examples.
How do they measure up?
Here a simple scale is used to answer a single question – If this process did not work properly, how high would the impact be on the business (scale in example 1 low 5 critical).
As discussed in the base logic section above, can this process be packaged and re-used somewhere else? Best guess at the moment expressed as a number.
Persons Use (client)
The number of people that would end up using the process if it was working or in full production mode. In this case we presume a company containing 50 employees in total with 5 people that could possibly pay invoices.
People required to manage the “result” that emerges from the completed process.
The number of disciplines, departments, human or computer based systems that would be affected by the output or result from the process. Leave = HR, Payroll, Accounts – Invoice = Accounts.
Relative complexity of process considering the following – Number of nodes (steps), alternatives or feedback loops, number of people (or groups) interacting, number of documents (or forms) required, number of aggregations (or calculations) and data retrieval complexities.
From the above we can assume that most persons would instinctively elect to implement the Pay Invoice process first – It makes sense as it is the most critical in business criticality.
I would like to propose considering implementing the Leave request process first in organisations where BPM is starting out, has to grow in maturity or the business is experiencing some external pressure.
The reason behind this resides in the footprint argument. Even though it is a less important process than Pay Invoice (Business criticality), it exposes more people to the BPM concept, has a lower risk profile (should things go wrong) and would therefore have a MUCH lower resistance to change from the people in general because everybody knows that if it breaks, its not the end of the world.
This “softer” point to entry can and will evolve quicker and mature faster than the more complex, important and “dangerous” Pay Invoice process, getting people on the program faster, making users used to the idea and providing a much more visible and immediate benefit.
If the Leave Request process is implemented first, people accept it like a fax (reliable, repeatable and adding convenience) they may just approach you to do the Pay Invoice process on their own accord – Think of the reduction in change management required.