Discuss BPM in Plain Language, not Tech-ese

Share it on Twitter  
Share it on Facebook  
Share it on Linked in  

Last spring when I interviewed Vinaykumar Mummigatti, head of the BPM group at IT services company Virtusa Corp., he told me one of the biggest problems with business process management initiatives is organizations' tendency to focus on technologies used to deliver solutions before fully considering how BPM can help them transform their underlying business processes.


In many cases, Mummigati told me, the problem is an IT team that "becomes very focused on automating processes," without considering other process changes that may need to be made. Automating a flawed process just makes it quicker and easier to achieve subpar results, not usually the goal that folks have in mind for BPM. While this can be a problem with any enterprise software deployment, Mummigatti said it tends to be a bigger issue with BPM because "BPM initiatives directly touch so many different areas of the business."


His suggestion was to "take a step back and create a common set of expectations and understanding between the key business stakeholders and IT stakeholders." Topics of discussion should include an overview of BPM concepts and methods, determining who the key players are in a BPM initiative, and considering what makes BPM different from other platforms.


This should occur before bringing in vendors because when they get involved, "the whole discussion turns toward the technology and what it can do," Mummigati said. This isn't uncommon with any software sales pitch. It's a problem because it tends to shift the focus from business objectives to tech-centric concerns like integration.


I don't mean that issues like integration aren't important. It can be just as much of a problem if IT is left out of vendor discussions. As IT Business Edge's Loraine Lawson recently wrote, when business units purchase software-as-a-service and cloud solutions on their own, it can wreak all kinds of integration havoc.


Like Mummigatti, I think the answer lies in getting IT and business on the same page before vendors enter the picture. IT's cross-functional view of the enterprise and experience with process frameworks can make it a valuable BPM partner to the business. As with any such relationship, it'll work best if partners are committed to the same goals and understand each other's roles and responsibilities.


Business stakeholders will be more comfortable speaking with vendors if tech jargon is kept to a minimum. BPM has its share of acronyms that are probably pretty meaningless to most business users. David Almeida, director of North America Product Management for BPM provider Ultimus, provides a pretty good list on the Ultimus blog. Among them: BPA, BAM, DMS, LDAP and SOAP.


IT pros talking about SOAP are most likely discussing Web services and messaging. Business users probably only think about soap if there isn't any in the bathrooms. Chances are, business and IT folks aren't even talking about the same things when using some of the more common terms on Aldmeida's list like "usability," "legacy" and "optimization."


To make it easier for all parties to understand, he thinks vendors should answer some pretty basic, yet important, questions. Among the questions he suggests asking BPM vendors:

  • Does the BPM platform get the tasks to users on time?
  • Does it help remind users they have tasks that need attention?
  • Does it provide managers with visibility about what team members are working on?
  • Does it provide connectivity to existing data in systems throughout the company?


If vendors can't help themselves and start tossing out long strings of acronyms, IT should be ready to step in and help translate. Doing so will help ensure organizations get solutions that will solve business problems and meet users' needs.