I realize this is a Nigerian bank we’re talking about but one part of the piece really caught my eye. It reminded me that when it comes to business process work, without vigilance the old mistakes can and will be repeated:
The first stage Flexcube Upgrade project commenced with the Business Process Redesign (BPR) . The BPR project would lead to the establishment of efficient processes in accordance with best practices that would be well aligned with the new version of the Flexcube, while the upgrade project would lead to the upgrade of the Flexcube software from 4.3 to 6.6 (Retail) and from 3.2 to 7.2 (Corporate) to drive the businesses of the Bank.
That seemingly innocent description illustrates one of the biggest pitfalls of engaging in business process work, letting a particular software package be the driver of BPR in the first place. Why is that a pitfall? Because demanding BPR as a precondition for software integration is just a rhetorical technique for mandating that an organization change the way it works for the sole purpose of achieving compatibility with the software it has recently purchased.
Put another way, letting software drive business process work is a euphemism for cramming cookie-cutter “solutions” into a unique organization. The “minor customizations” often deemed necessary to ensure a “successful integration” are the flip side of this coin, modifying the otherwise-cookie-cutter software in often not-so-minor ways so that it can attempt (or appear) to function in places where the organization can’t or won’t change to fit the software.
This obvious example of tail-wagging-dog is one of the main reasons BPR got such a bad reputation in the 90s (so bad, in fact, that many practitioners these days have taken to calling it Business Process Management or “BPM”, just to distance their efforts).
This quote from a 2003 Giga paper entitled Supporting SAP Offshore, under a section entitled Recommendations, shows the deceptive logic that sneaks BPR into places it doesn’t belong:
Business process improvement should be an integral part of any SAP implementation. Companies that don’t take this opportunity to optimize their processes before mapping the software cannot take advantage of the process cost reduction that a package like SAP can enable.
In other words, you can only use this software effectively if you operate like it assumes you do. That might be an absolute key to successfully implementing SAP, but it’s got nothing to do with good reasons to perform business process work.
History has taught us that BPM, or BPR, whatever we want to call it, should quite simply be motivated by a demonstrable need to improve the way an organization operates. Notice how the June 27 article at ZDNet UK, How to roll out SAP, talks a lot about how the award-winning companies were so successful at implementing SAP. Well that’s fine, but what did or will the implementation improve? No mention of that…
July 6, 2008 at 10:51 am
I took on a training consultancy as a sub. The client was a Northern Canadian Oil Company with the most dysfunctional work and IT processes, and a BIG SAP system…in short, a mess.
I asked the prime contractor, a good colleague, “how do they make money with all of these broken, half functional systems and processes?”
He answered, “They are an oil company, they make money no matter what – they made money when they were mainframe based, client server, thinclient, WAP, tin can and string. People jsut send them profits.”