I read hundreds of LinkedIN posts each week on various ways of introducing Business Process Management (BPM). Many of the approaches seem extraordinarily complex.
The approach we use with our clients works well for us and for them:
(1) processes are owned by the line people who do the work.
(2) they maintain their own processes, with assistance from IT, not the other way around.
(3) consultants/supervisors can suggest all manner of improvements, but these are implemented by or in close cooperation with the silos (you only need one process mapper per silo).
(4) during the “introduction to processes” phase, consultants or internal Business Analyst groups, playing the role of facilitators, sell the system to end users on the basis of:
* what is in it for the people who will be at the User Interface (i.e. the BPMs will guide the processing, mostly in the area of handoffs across silos, but, if the process is complex, then the BPMs will guide handoffs across users within silos).
* users no longer need to worry what to do, when, who does it, or how in respect of structured work and users can basically do what they like in respect of unstructured or ad hoc work, thanks to ACM/BPM.
* process documentation, improvement and implementation is a necessary thing to build, improve competitive advantage for the organization.
(5) the initial “sales pitch” to management is they have spent a lot of time and money building competitive advantage in the form of infrastructure, staff and customers. All customer experiences derive from processes (i.e. transformation of inputs to outputs) and there is nothing better than ‘best practices’ so it makes sense develop, improve and encourage the use of “best practices”).
The quantifiable benefits are increased staff efficiency, increased throughput, decreased errors, improved compliance with internal/external rules and regulations, all of which lead to better customer experiences.
(6) Change Management is important but the need for CM is directly proportional to the complexity of the BPMs – the closer you end up with familiar forms and familiar flows (once these have been improved and adapted for automation) the less the need for change.
(7) Implementations that are complex to the end user, that increase, rather than decrease, end user effort/time are likely to fail.
(8) Process initiatives that involve multiple steps, connected in complex ways, where there are handoffs within and across silos, where there is a need to provide proof of completion of steps, where a full audit trail is required and where there is a need for data interoperability have a higher probability of failure and typically fail earlier than the ones described in (7) in the absence of in-line, real-time automated resource allocation, leveling and balancing software systems.