The headline question is from an ebizQ forum. http://bit.ly/nD7kSS I found it a little flippant but let’s pick up on the premise in the article it referenced: “The key to business improvement is getting a process live in the shortest time, so that it is real, and can be seen and understood, and more importantly, improved.”
I think there is a balancing act here. So many times I find that digitising a process exposes the real opportunity for improvement. In fact it’s like two main waves and then improvement ripples. One wave is almost a wire frame process providing visibility, enabling insight into what is happening. The second wave is a refinement process that settles the process in a more permanent way; baselines it. The ripples are the refinement a good BPMS should support to keep it relevant. The balancing act is weighing up what knowledge is required either side of a deployment to get the right outcome. I am progressive on this front but not to the detriment of quality. I see many hold back big improvements to go into a holding pattern of analysis paralysis.
This question is also very dependent on the nature of the process tackled and what the objectives are. Is it about providing visibility, traceability, capturing metrics, operational data that underpins moving an improvement forward? Or is it about a process that manages critical business risk that has zero margin of tolerance? So let’s not take a blanket approach.
I also think it comes down to the technology you are familiar with. Some BPMSs move like snails, the ability to really expose and refine without creating significant business disruption is complex to say the least. Interestingly, there is a definite move from ‘doing by design’ to ‘design by doing’ in the BPMS world. I think some platforms talk straight to this while others have too much legacy weight behind them to be genuine contenders.
One area which I think should take centre stage in getting a BPMS process in place is qualifying its goal and objectives, determining what KPIs it impacts, defining its own performance measures and outputs it is required to support, ie, if you deploy a process without these goals, objectives, etc, then it cannot “be seen and understood, and more importantly, improved”.
On a separate but related note, several have referenced quick wins as the entry point for BPMS. If it’s simple, a quick win, but has a massive organisational impact, question why has it not been done to date? It may be due to new insight, new direction, refocus of strategic goals, business incompetence!
Generally small things usually make small impacts. If you address enough ‘simple’ that the impact is not deep but wide, and touches many, then it may still have an impact. I would always suggest to take on all comers, large or small, if the business benefit is large enough. Just because it’s big doesn’t mean you avoid it. These larger processes are often the differences that can propel a business into another orbit. You just mix quick wins with the first steps to addressing these larger process projects to get the best sense of movement.