Yesterday’s article on Coors in Intelligent Enterprise piqued my interest by combining beer and BPM, although I confess that I am highly unlikely to drink an American beer regardless of how efficiently it is delivered.
What I found particularly interesting is the description of how they first approached their BPM efforts, starting in 2000. They have a Director of Business Process Management, who by their own description was “spearheading an IT-led supply chain improvement project, but the team wasn’t collaborating with business users”. Did someone make a mistake about this guy’s title by using the word “business” in it, when he was actually an IT person working on an IT project with little or no business interaction? At the same time, they hired a business architect to do process modelling, but with no coordination with the related IT project.
The story has a happy ending: boy meets girl and they share business process models to great success. However, this same story is playing out in organizations everywhere, and many are far from a happy ending. Due to the inclusion of all manner of application integration and middleware products under the global BPM naming umbrella, many “BPM” projects start as IT-only EAI, with little or no communication with the business side of the organization, and allow IT to seize control of all subsequent BPM projects. BPM products are selected based on IT’s criteria, then “business process management” projects are built purely by IT, with sufficient arrogance to believe that they understand enough about the business that they don’t need interaction with the business units.
These organizations inevitably end up wondering why the success rate of their BPM projects is so low. It’s simple: they need to put the “business” back in BPM.