More, again, on why BPM initiatives fail.
Many BPM initiatives fail because they take on too big a scope, this extends the initial implementation timeframe, results are slow to materialize, people lose enthusiasm, progress slows, the timeframe then increases way beyond the original timeframe, funding runs out, and management eventually puts the initiative out of its misery.
The future is not going to be like the present so any “big project” that cannot get off the ground in weeks is doomed because the playing field WILL be different.
So, go for incremental deployment (this department, this process), but make sure of four things (and perhaps others) . . .
1) Adopt a total enterprise approach – “we are going to encourage best practices, people can follow these as-is if that is appropriate but they can optionally deviate from best practices to the point where a best practice comprising a linked sequence of steps actually gets implemented in isolated situations as a seemingly unrelated series of ad hoc steps”.
The approach must allow incremental roll-out of processes over an extended timeframe.
And, it must be able on a ongoing basis to “rein in” serious deviations from best practices.
2) There is a central common resource allocation, leveling and balancing run time environment for the performance of work so that scarce pooled resources can be properly allocated across the organization to process instances and to ad hoc interventions.
3) The User Interface must be such so that the care and feeding of the BPM mapping environment and the run-time environment do not detract from staff productivity.
A not-so-bad solution is ONE screen where each worker sees their fixed time commitments on one side and their floating time to-do tasks on the other side. This covers 100% of all work done by all workers each day.
4) From the time the first process is mapped and implemented, it should be able, via the run-time environment to carry out bi-directional dynamic linking to/from other current and legacy systems.
This requires the use of an arms-length data exchanger as opposed to trying to hay-wire disparate systems together.