Take BPM Out of Technology Trenches

Ann All

IT professionals love technology. It's likely the reason they got into IT in the first place. And there's nothing wrong with that. But sometimes they get so excited about the technology, they rush into product evaluation and implementation discussions before considering the most important question: "How can technology solve a business problem and/or achieve a business goal?"


All of the good advice to bring together business and IT people in the early stages of technology initiatives isn't worth a hill of beans if IT pros don't take the time to really listen to what business folks have to say and walk them through how technology can help them. This is true even for technology initiatives like business process management that in theory already enjoy a strong direct link with business. (That's compared to something like, say, virtualization, which can cause business people's eyes to glaze over pretty quickly.)


Last spring, when I interviewed Vinaykumar Mummigatti, head of the BPM group at IT services company Virtusa Corporation, he told me IT professionals, BPM vendors and partners like systems integrators tended to move quickly past process and steer discussions toward technology during the early stages of BPM initiatives. If and when that happens, he said, it's important to take a step back:

... 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.

Mummigatti mentioned other problems he often encounters during BPM projects. The first two relate pretty directly to putting technology before business. The third is a bit different, but also reflects a tendency to focus on technology rather than the underlying business issues:

  • Focus on automating processes rather than improving them. "Companies don't differentiate between process excellence and technology implementation. We need to establish the right way of doing a particular process before we use a technology to automate it," he said.
  • Siloed approach to BPM. This results in a lack of enterprisewide knowledge about BPM. "There is no way of institutionalizing the learning they have from their first or second project when they go to the third, fourth and fifth project. So by the time they get to that third or fourth project, the whole opinion of BPM has gone down," he explained.
  • Not enough consideration of legacy technologies. Mummigatti's take: "If you look at an enterprise technology stack, you're going to have a lot of different legacy systems and platforms that have been invested in over time. Sometimes people think if you drop a BPM solution into the mix, it'll be a magic bullet that will somehow solve all their problems. They start looking at building entire solutions with BPM technology stacks. BPM is very good for certain types of activities, like process orchestration or Web services orchestration, but BPM is not good for transactional business solutions, it's not good when it becomes very integration-centric. So you need to look at BPM in the context of the other enterprise investments you've made."


Several contributors to a recent eBizQ discussion around the question "Where would you like to see BPM improved?" offered comments that similarly hint at a need for a fundamental repositioning of BPM.


Thomas J. Olbrich, co-founder of taraneon Consulting Group, mentions a need to improve BPM management skills and added, "We're still hellbent on managing drawings -- sorry, process maps." He also notes the importance of understanding the value and meaning of processes (they "define the company," he says) and understanding the implications of processes. His take on the latter point: "Whatever happens in the tool department will never have the desired effect if we don't come to grips with the WHY and just rely on the HOW. Processes are not abstract, they are the means by which we earn or lose money.")


Focusing on the skills question, Serena Software VP Kevin Parker suggests BPM should be "an integral part" of business school curriculums. Because process touches every area of a business, he opines, "Tomorrow's graduates need to be as fluent in BPM as they are in reading a balance sheet." This may sound somewhat radical now, but I don't think will in coming years as universities and other schools begin to include topics not under the traditional purview of IT in their IT curriculums. (I'm thinking of "soft" areas as communication and change management.)


Two other points from the eBizQ discussion that I found especially interesting were made by Alberto Manuel, CEO of Process Sphere, and by Olbrich. Regarding BPM's need to become more flexible, Olbrich wrote about a prevailing attitude of "once you design a process and put it into operation, you are actually setting a mark the world around has to accept and follow."


And Manuel doesn't think enough is done to make the benefits of BPM relevant to front-line workers, a topic I wrote about in July. Manuel wrote: "People felt abandoned, confused, and were left in the middle of new acronyms and evolving methods that could fit under the BPM, to the point that the people we want to be more efficient and effective stop believing in everything that was under BPM. Ultimately they feel relieved end the project ends."


Now that's quite a collection of issues. I'm not one to think a center of excellence can solve every problem. But I think the creation of such centers are one of the best ways to initiate the kinds of high-level discussions that are the first step to tackling the kinds of issues mentioned above. They also help ensure best practices are collected and disseminated.


I like a model recommended by Forrester Research's Clay Richardson, which I mentioned in a post on five key BPM trends. Forrester research on highly successful BPM initiatives found some organizations used centralized BPM centers of excellence to focus on broad process transformation projects while allowing smaller process teams to focus on more targeted initiatives. (I expect the process teams share their best practices with the center of excellence.)

Add Comment      Leave a comment on this blog post
Sep 13, 2011 4:16 AM Neil Ward-Dutton Neil Ward-Dutton  says:


BPM CoEs aren't a "silver bullet" but they certainly can help, in two crucial ways: firstly, in scaling and sustaining BPM success past a first couple of projects; and secondly, in helping to link business strategy to operational execution.

That said, a BPM CoE can't rescue a failing initiative. If BPM already has a bad name, implementing a CoE ain't going to fix that.

We've just published an in-depth report pulling together research we've done with a number of organisations on this topic; I can provide you a copy if that would be of interest?

Sep 14, 2011 9:53 AM Ann All Ann All  says: in response to Neil Ward-Dutton

As a fan of both your work and the CoE concept, I'd love a copy of the research you mention. Can you DM me on Twitter? @all1ann

Oct 10, 2011 9:59 AM Juan Juan  says:

There is another hurdle. The IT guys consider the BPM pradigm: do more with less, as dangerous. Why? Because, it coudl be misinterpreted or worse we are showing flaws in the IT strategy. Thus, I spend most of my timing conving CIOs that embracing BPM is the source of resources not the opposite.


Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.