BPM implementation best practices – part I

Unlike traditional software development, BPM program group just cannot ask business users to provide requirements, take sign off, and then come back for acceptance of the BPM implementation. This is commonly done mistake in BPMS implementation. It is necessary that Project Manager (PM) and Analysts (BA/PA) are trained properly on usage of BPMS tools and BPM methodology to ensure this mistake doesn’t happen. Generally PM are trained on standard software development methodologies and come with project plans that invariably have Requirements, Design, Development, Testing, Go-live phases. These phases are fine, however, what happens in each of these phases is more important. BPMS Implementation Requirements phase is not restricted interviewing stake holders and creating System Requirements Specification document for the purpose of sign-off.

Also, it may be difficult to get buy-in from customer IT to establish such collaborative practice with process owners/users. However, that is because customer stakeholders might not be aware of how BPM solutions are implemented. Hence, it is recommended to have a workshop with key customer stakeholders to make them aware of BPMS suite components and how each of them can be used during entire lifecycle of process solution.

All popular BPMS provide easy to use process modeling tool, which is a very important tool for requirement gathering and generally enables collaboration amongst implementation team and process stakeholders by allowing them to work together to develop process model, process interfaces wireframes as well as process documentation. Tight collaboration with process owners and joint modeling exercise can yield significant results. As explicit definition of any business process starts to emerge, there are plenty of opportunities for process owners to brainstorm on potential process improvement areas.

Across various implementations we have seen time/cost savings of anywhere from 10-20% as a result of this approach.

Below are some of key advantages of this:

• When Process modeling becomes joint exercise, end result is the way process owners and participants see it rather than based on imaginations of process analyst who models process based on document in front of him/her. When Process is modeled the way business sees it in practice, it becomes that much more easier for them to use process solution as well as monitor the process for its effectiveness.

• Joint modeling exercise, invariably triggers discussions around why certain steps in process are performed the way they are…this in turn give plenty of opportunity to potentially improve the process, even before it gets automated.

• Take the requirements document and come back with implementation approach leaves a lot of things to assumption and runs a high risk of late change requests (potential conflict point) and rework. This of course has very significant effect on timelines and cost of the project.

• BPMS modeling environment generally also provide user interface design tool. If wireframes are developed using BPMS native tool, implementers just needs to put the meat behind them to make them work. In traditional way, other wireframe tools are used and they are generally not usable for direct implementation. Using BPMS native tool for wireframe can save a lot of time during implementation.

Happy collaboration!