Ann All spoke with Vinay Mummigatti, head of the BPM group at Virtusa Corporation, a global IT services company providing IT consulting, technology and outsourcing services. The company recently announced a BPM Test Drive service, which is specifically focused on educating both business and IT stakeholders on BPM and developing a common set of goals and metrics.

All: I believe you think the steps companies take in the very early stages of a BPM project tend to make or break the initiative. Why is that?
Mummigatti: First, some background: I’ve been involved with BPM since 1998-99. I initially worked with workflow solutions and then gradually saw the evolution of different technologies. We started seeing a rapid expansion of the BPM space the last three or four years. I worked with some large companies like General Electric, JPMorgan Chase and Caterpillar. When we started building our BPM practice, we were a traditional technology shop. But then we started analyzing some BPM projects that either had not met business expectations or were considered to be failures. I began relating them to projects I had been part of over the last decade and started trying to see some of the common failure factors of these projects

If you look at the BPM lifecycle, it starts out with some kind of business problem analysis, then some kind of a definition or preparation of a business case, and then the technology elements, and then finally we go into the actual implementation. The root causes of failure can get introduced at any of these levels. Most of the integrators in the market today are focused very heavily on the implementation part. Many times, by the time we get to the implementation, we’ve already taken a few steps which have compounded the root cause of the failure and it may be too late to correct them.

All: This problem you describe doesn’t seem exclusive to BPM, but is it perhaps more visible with BPM?
Mummigatti: I’ve worked with content management, CRM and other areas in my consulting career. BPM stands out in a big way. BPM initiatives directly touch so many different areas of the business. And also, the people who are defining and designing the requirements, using the applications and dictating how the applications should respond to their needs are all business stakeholders. That level is very different than the one commanded by an integration solution or a content management solution. The business dominance is much higher with BPM.

All: You mentioned that many companies focus heavily on implementation. So is letting IT take too much of a lead a common problem? Or considering technologies before examining the underlying need for them?
Mummigatti: That’s a good question. It’s also about what is the level of common expectations and the understanding each one needs to have before they embark on a BPM initiative. BPM is a very broad concept. It’s not just about considering a solution. Technology becomes a medium for transforming business processes. Many times IT becomes very focused on automating processes, and that is where a lot of the failure points arise. The business starts seeing a lot of gaps.

So we try to take a step back and create a common set of expectations and understanding between the key business stakeholders and IT stakeholders. What is BPM, in terms of concept and methodology, the value of BPM tools, who are the key players in a BPM initiative, what makes BPM different from other platforms. The fundamental paradigm of BPM has to be ingrained with the business and IT audiences.

All: So you might want to start with something as basic as a definition of BPM?
Mummigatti: Technology vendors haven’t been helping the situation. When they get involved, the whole discussion turns toward the technology and what it can do. The project scope is adjusted to fit the technology. In the process, we come down from a larger business solution to a technology solution very quickly. I think the business and IT teams need to have an upper hand in terms of what they are looking at in terms of a true BPM solution. They need to see technology as a means to achieving that larger goal.

Source:http://www.itbusinessedge.com/cm/community/features/interviews/blog/put-process-before-technology-in-bpm-initiatives/?cs=40201