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