BPM Excuse Busters – Episode 2: “We tried Business Process Re-engineering already and failed.”

Anyone who was around the business world in the 1990s couldn’t escape the two big topics of the decade – the Y2K bug and Business Process Reengineering (BPR). The fear of the unknown drove huge investments to address Y2K and the result was…well, nothing really came of it. On the other side of the coin, the promise of efficiency and cost reduction drove many companies to undertake huge BPR efforts. Michael Hammer and James Champy’s 1993 book “Reengineering the Corporation: A Manifesto for Business Revolution” was the BPR Bible. It was a NYT Best Seller for 41 weeks. Numerous firms embraced BPR and responded to Hammer’s motto: “Don’t Automate, Obliterate!”

Unfortunately, many BPR projects suffered failures, costing companies millions without showing any measurable ROI. As a result, many business and IT people remain skeptical a decade later of the promises of Business Process Management. To many, it appears that BPM is just another version of the failed ideas of the past. They fear spending tons of money with no return. They fear losing their jobs as a result. While understandable, these fears are unfounded for a number of reasons. Consider the following:

  • BPR failures were not due to inherent problems with BPR. BPR projects failed for any number of reasons. Many of these are the same reasons any large IT/Business program fails:
    • Misalignment of business and IT
    • Poor Change Management
    • Lack of Executive sponsorship, business ownership or accountability
    • Inability to overcome internal resistance
    • Over-sold expectations and under-sold investment requirements
    • Poor definition and management of scope
    • Lack of appropriate technical skills
    • Budgetary cut backs
    • Analysis paralysis

The list is endless. But the fact remains that many BPR projects avoided these obstacles and were completed successfully, providing significant positive impact on the organizations they changed. As with any IT project, BPM projects are susceptible to these same risk factors. But when properly executed, they can overcome these risks and show value; there is nothing inherently broken about BPM.

  • BPM is not BPR. Sure, they sound similar, but the main philosophy with BPR is to radically change the way a company does business. While one can take this approach with BPM, it is not the only way. In fact, in my last blog post, I explored how BPM can show benefit without any process change at all. So don’t let BPR horror stories or even an organizational aversion to change taint the possibilities of BPM benefitting your organization.
  • BPM embraces a more deliberate, iterative approach. Remember the BPR mantra: “Don’t Automate, Obliterate!” BPR eschewed small process change in favor of major change. The philosophy was that BPR was revolutionary, not evolutionary. While this approach can yield much greater impact, it also comes with greater risk. BPM embraces an iterative, evolutionary approach that requires less investment before seeing positive ROI.
  • Today’s technology landscape is different. In the mid-1990s, the technology focus was on client/server technologies. The web was just beginning to take root and grow. Windows95 was the first usable GUI on a mainstream operating system (bringing it almost on par with Macintosh System 7 from 1991). Graphical modeling environments were rare. Most major processing still required Mainframe computing power.

Contrast this with the technological capabilities of today. Internet technology is ubiquitous. Web Services standards, Enterprise Application Integration and Services Oriented Architectures enable the exchange of data and choreography of processes like never before. Numerous platforms exist to enable Business Intelligence, Data Analysis, Business Activity Monitoring, etc. Visual process modeling tools are commonplace. Graphical dashboards allow complicated data to be communicated and understood quickly and easily. The bottom line is that today’s technology enables so much more than that of 10 years ago. BPM efforts can capitalize upon these technology advancements.

  • BPM places more importance on the “B”. While the “B” in BPR stands for Business, many BPR projects were IT-driven projects. As a result, many projects were not aligned well enough with the business to succeed. When done right, BPM projects are business-focused and business-driven.
  • BPM Suites. When BPR at its peak, there were few tools available to assist with the process. In fact, I was personally involved deeply with the development of an early BPR tool (called Apache – later renamed Process Vision) at Electronic Data Systems. Ironically, although I witnessed significant successes brought about by use of Apache, I also recognize that the effort was conducted out of EDS’ R&D organization. Thus, it had a bit of that “IT-driven” nature mentioned in the previous bullet. We were one of a very small set of sophisticated BPR tools available at the time; business units seeking to take on a BPR project did not have very many places to turn nor much of a “services economy” to support those efforts.

Today, there are many viable Business Process Management Suites (BPMS) that can be leveraged. These products robust provide out-of-the-box functionality to jump start your BPM efforts. But they offer much more than that. Most BPMS’s provide the capability for: business process modeling/analysis, process simulation/optimization, monitoring/reporting/notification, business rule integration, lifecycle management and much more. In addition to the solid offerings from pure-play BPM vendors such as Global 360 (an Avalon Partner), Lombardi and Pegasystems, enterprise application vendors like IBM and Oracle have BPM solutions as part of their product suites.

Conclusion: Busted!

While there is a similarity between the excitement around BPR in the ‘90s and that of BPM today, there are also significant and structural differences. Thus, there is no need to fear BPM because of failed past attempts to address BPR. To do so would ignore all of the potential benefits that are absolutely critical to remaining competitive in today’s rapidly changing business world.

What are some of the excuses that you hear against pursuing BPM – justified or not? Let me know what barriers you encounter and I’ll try to address them in future posts.

Mike Green About Mike Green

Mike has been involved with Business Process analysis since he helped develop one of the first visual business process modeling and re-engineering tools – Process Vision - in the early 1990s. More recently, he was a Principal Consultant with Electronic Data Systems, where he worked with clients to define IT transformation strategies to support their changing business process needs. From his experience talking to business and IT people striving for agility, Mike understands that companies are looking for help getting past the promises and hype to really understand how subjects like BPM can derive actual business impact. Thus, this blog focuses on the practical application of BPM technologies and techniques. When not leading Avalon’s BPM Practice, Mike coaches youth soccer and is an avid runner and bicyclist.

Leave a Comment