Fifteen years ago, the hot topic on everyone's agenda was Business Process Re-engineering. A decade and a half later it's back on the agenda big time. Is this because no-one got it right the first time, asks Chris Skinner.
In 1990, Margaret Thatcher was Prime Minister of Britain, the Intel 80286 chip was about to be superseded by the 80386, 16Mb memory was considered turbo-speed, smart people had upgraded from vinyl to compact discs and, in business circles, a buzz had started. The buzz was created by a seminal paper published in the Harvard Business Review by a chap called Michael Hammer. The article had exhorted the benefits of analysing and re-thinking processes from end-to-end. The methodology was named 'Business Process Re-engineering', BPR for short, and it became the next big consulting bandwagon following on from Total Quality Management (TQM), the management fad introduced by Tom Peters.
In 2005, a decade and a half later, BPR is firmly back on the corporate agenda. This is, in part, because the job was never finished first time around but it is also because BPR, this time around, is different.
In the 1990’s, when BPR was first being discussed, the concept was to achieve radical results, to turn the business on its head and to redesign the business from the customer’s viewpoint. The aspiration was to identify all customer interaction points and design the business from scratch around those customer interactions. The achievement would be a customer-centric business and the journey to get there would involve tearing up the current business roadmap and starting again from scratch.
However, few BPR projects came anywhere close to achieving radical results because few projects re-invented the business. The majority changed business processes but did not change the business. It was the latter that many hoped would happen, but it was the former that became the reality. The reason is that no-one wanted to shake up their institution and transform it. It was just easier to implement incremental improvements to processes within functions, than to re-engineer the whole business.
By way of example, I was working with a bank in 1992 where we had the opportunity to either re-engineer the money transmissions process or the mortgage process. The former was simple because it was owned by the payments group whilst the latter was difficult because it cut across all functions, products and services within the bank. So guess which one we took? Yep, the money transmissions process. The reason we chose money transmissions was because it meant dealing with only one department within the bank and therefore avoided the political conflicts between the different business owners which would have been demanded by the mortgage process. In addition, the complexity of the mortgage process and the systems issues it would have confronted also meant it was to be avoided.
In other words, we opted for the process that allowed for improvement rather than transformation. Transformation requires revolution to achieve radical results and businesses; or more importantly people and management within those businesses seek evolutionary change rather than revolutionary. That is why we went for the process that was easier to manage and change and, as a by-note, the mortgage process in that bank is still pretty much untouched today.
However, that could be about to change because BPR today is looking at a more fundamental revolution of processes. The reason BPR is different today, and therefore can tackle more fundamental change, is because the systems issues are different today and are more easily addressed through 21st century architectures.
In 1990, systems constrained true business transformation because we were dealing with hard-wired technologies and programming environments from the 1960’s. Sure, client-server systems were around, but networked architectures, modular design, component-based methodologies and truly open systems were just a glint in the eye of a few technologists on the west coast of America.
That has been the most dramatic change in the last fifteen years. Today, Service Oriented Architecture, Web Services and related developments have made it much simpler to develop pieces of the re-engineered business and slot those in where needed on an evolutionary rather than on a revolutionary basis. That does not mean to say that transformation is easy, but it does mean that the systems issues are much more manageable today.
But it is not just for the reasons of more manageable technologies that BPR is back. BPR is back because many of us feel that the time is right to re-engineer. After all, it has been over a decade since many processes have been touched. As a result, some bad practices have developed.
For example, how many Internet banking sites reflect the bank’s internal processes and systems rather than the dynamics of the blogging and entertainment oriented Internet that we use today? How many banks offer online services designed for dial-up rather than broadband? These two points alone reflect the drive for continual re-engineering for 21st century business. After all, if we do not do it, our competition will.
In addition, many of the re-engineering programmes of a decade ago got dumped before they were completed due to other things coming along. During the mid-1990’s many banks were heavily engaged in re-engineering and just as those programmes were getting interesting – as in tackling the big issues like the internal politics and the legacy systems – a couple of more urgent priorities came along like the euro and Y2K. Then we had the Internet bubble and burst and CRM. All these ‘fads’ came and went until we finally got some breathing space.
Today, we have time to review where we have been and where we are going because there is no big blip, consulting fad or technological roller-coaster hitting our radars. Therefore, many of us are going back to basics and realising that our processes are still in a mess.
We still have silo-based systems and departments, baronial powerlords running functions and spaghetti systems that have cemented old structures in place. But the biggest difference with today’s world of re-engineering is that we can tackle processes end-to-end on an enterprise basis without breaking apart all of the old ways of doing business. That means that we can potentially transform the business without creating revolution or being revolutionary. For the beauty of this change is that it can be achieved on an enterprise basis in an evolutionary way.
Using SOA, we can evolve the enterprise. Using component-based developments, we can build the pieces and slot them into place gradually. Using business blue-printing or whatever terms you would like to use, we can build the enterprise piece-by-piece. That is the major change in today’s re-engineering programmes and yes, as a result, it will lead to business transformation.
However, there is one caveat to achieving an evolution towards enterprise renewal. It still will not happen unless the management team within the bank – the leadership team and the CEO in particular – make it happen.
Think about it. Most major enterprise change projects fail. BPR, TQM, CRM – you name it – four out of five fail. Most projects crash and burn because the change programme is delegated or designated to a department.
For example, let’s think about a 'Customer' project. The Customer Project could be under any of the change banners – BPR, TQM, CRM, or any other modish acronym. The Customer Project may have been created by the head of customer services. As a result, it becomes a customer service change programme so the customer service folks deal with it. Because service people design and implement the programme, it does not get the buy-in of the sales people. However, as it turns out, it's the sales people who have to do ten times the administration to support the service programme. If the sales people don't enter all the customer information upfront – which adds a major administrative overhead to the sales process – then the service people do not have the right information to do their job. Net result: failure.
With any such project, the minimum support required is to have all of the functional heads owning the project. By ownership, that means that there has to be real commitment, and the only way to get real commitment is to make sure it hits the wallets of those involved. Therefore, to ensure the success of the change programme, there must be a tangible impact on management bonuses, commissions and earnings. That way all of the team players have skin in the game for the project’s success or failure. However, to change an executive management team’s earnings structure can only be achieved if the CEO owns the change programme.
The CEO is the individual at the top of the tree and is the only person who can make change happen across the enterprise. A functional leader can make change happen across their function, but not across the enterprise. The buy-in and the ownership has to be across all functions for enterprise change to happen, and the only person who owns all functions is the person at the top of the tree. The CEO.
And that is where nothing has really changed at all in the last decade and a half. In 1990, four out of five change programmes failed because they did not have the ownership of the CEO to make them succeed and, in 2005, the same message holds true.
Even with the revolution of the Internet, broadband speeds that are light years ahead of those fifteen years ago, processor speeds that would be the equivalent of mainframes in 1990, the message stays the same. To achieve enterprise change, you have to have the enterprise owner firmly engaged in the change programme. And by ‘firmly engaged’ we mean committed. The CEO must be passionate and must want to be a part of making change happen by being hands-on. The CEO must live and breathe the change programme – they cannot just buy it or delegate it. The CEO becomes the ultimate leader in the enterprise change programme.
Therefore, if you are engaged in a programme that has either the word ‘enterprise’ or ‘transformation’ involved, just make sure it has the ownership of the person who sits at the top of the tree. Make sure that that person wants to hear how it is going every day. Make sure that they are willing to drop all other matters to ensure the project’s success. Otherwise, go back to doing something more evolutionary at a level that can be managed within a function.Chris Skinner is a director of TowerGroup and founder of ShapingTomorrow.com.
Web links: www.towergroup.com
Author's email: Chris Skinner