If there’s a couple of authors that helped me coast my way to getting letters after my name it would be Thomas H Davenport and Michael Hammer. To say I was a fan of the Business Process Re-engineering (BPR) revolution of the late 90s, would be an understatement. I had two dissertations written on the back of it and it informed much of what I ended up doing in business.
The concept is simple with BPR, you don’t just use technology to automate how businesses are already doing things, you obliterate and start again. What’s the point of automating a bad process in IT, right? It’s time-consuming, it’s costly and ultimately those two factors make it difficult to fix later.
Even my other management science heroes, Peter Drucker and Tom Peters also promoted the virtues of BPR. It makes a lot of sense, why would you embody a bad process in your IT systems, spending thousands getting developers and consultants to do so – when you could re-engineer as you go?
Makes a lot of sense. In fact, I still agree with it when I think of staid old ERP systems that larger companies remain fearfully wedded to. I’m talking about you, SAP and Oracle!
It’s been 30 years since the real thinking of BPR came into existence and if I have to detail the technological changes that have occurred in that time, you should probably stop reading this article (probably not for you).
Suffice it to say, when a lot of BPR was thought about, companies were still using mainframes and organisations such as DEC and Compaq were still a thing. IBM actually had big factories too!
I started my career in IT then, with the mantra of not automating, obliterating! As such, I replaced paper-based systems with IT systems. Using those IT systems to buy-in best practice business processes that were built into our software. The company I worked for was one of the UK’s fastest-growing, we ultimately didn’t have time to worry about designing our own. When we out-grew those, we bought in new ones too.
Each time was a case of process mapping, looking at the changes and seeing whether we could cope with them. I encountered several problems with the BPR strategy though.
Resistance is Futile
Well, futile resistance. We’d generally bought and paid for the system, so it was happening. Staff weren’t too happy – they didn’t always want to come along for the ride. I could write a whole article on this, but changing people’s IT systems they’d only learned a few years earlier was tough in itself.
You can train all you want, but more often than not if you’ve got a group of people who don’t buy into the change, they can just derail the whole thing. They don’t even have to be proactively unhelpful; they just have to not help. Quite often we’d end up with problems after implementation that if people had spoken up during, they’d have prevented the problem from occurring.
What do you want to be famous for?
As a business, we were undergoing rapid growth. Much of our systems were heavily aligned to the needs of our largest clients. The minute we’d change things, we’d had a wobble in terms of our delivery to them. It’s okay taking on ‘best practice processes’ from an off-the-shelf solution, but they don’t really embody anything you as an organisation know about your clients and what they want.
The headache for me was generally then to start customising the hell out of processes, as a purist, I’d rather have kept the software we’d bought in its plain vanilla factory fresh set-up. All cost, expense and time.
Locked-in syndrome
In the end, we had great IT systems, we were delivering further growth and keeping our customers happy. However, eventually, we got to a size not only of the business but also of the systems that future upgrades became prohibitive both on a cost, time and damage to the business perspective.
Although you know there are better systems out there, you are relatively stuck. It’s just not worth the hassle. You ultimately become sympathetic with the larger companies on SAP and Oracle.
However, as a business maintaining the friendly can-do customer service attitude becomes difficult as the systems just stop you from being as agile.
BPR’s end, Digital Transformations Future
I remember sitting in a meeting with a CEO probably ten years ago arguing with a CIO who was wanting to take the BPR methodology to something I was proposing. He wanted to analyse, map and re-engineer processes before implementing a system I proposed.
We ended up in an argument about Business Process Management (BPM) tools – I said, just implement what you are currently doing and worry about the rest later.
In larger businesses, the whole debacle of re-engineering actually stopped things being automated. What invariably happened was, well, nothing. BPR was a difficult process and costly in itself. Without even starting process mapping, getting stakeholders together etc, change just simply didn’t happen.
And what happens in those organisations? Well, they still use paper.
I saw the future of no-code and low-code Business Process Management (BPM) solutions coming.
If you envisage your main old IT platforms as your ‘core’ – your ERP, your HR software etc. In many organisations, there are tools like SAP, Oracle, Dynamics, PeopleSoft etc. BPM tools are outside of the core on the periphery. 
There are a few good reasons that these systems have come to exist, similar to my downsides of BPR – change of the big systems is too heavily fought against, but you still need to have a system to deal with customer requirements and it can be your only way out of being locked into your IT system.
Perhaps it was my brief stint in quality management that gave me a few ideas. Certainly, in quality management, the quality managers are good at writing the top-level manuals that get you your ISO certificate. Most, however, aren’t the experts on the processes that other managers in the business ‘own’. Personally, I knew a lot about IT but very little about concrete.
IT much like Quality Managers, should offer their expertise out to the rest of the organisation as an advisor but not necessarily dictate how things are done.
I always wanted the process owners to be able to edit and change the bit of our ERP that affected them. Unfortunately, until the last few years, there weren’t the types of IT systems to enable them to take control of their own processes in a simple, foolproof manner.
This is what a BPM system can do.
You don’t need to be a Meerkat to be Automated! BPM over BPR
Where I did see the future going is this cheap, easy, fast to implement automation, process, and workflow automation software. Perhaps many others have seen this coming too – I feel when I was first starting in IT, I was doing a lot of similar things in Microsoft Access that I now do in BPM tools. Perhaps with a bit of a Web 2.0 and mobile twist though.
What I don’t believe many people have seen is that there needs to be a change in methodology. Those of us who have Computer Science degrees and MBA’s should really forget the whole module on Business Process Re-engineering and bin that dusty-looking textbook you still refer to when you have an IT project.
With the most modern no-code BPM tools, I can create forms, workflows and processes that talk to existing ERP solutions in less than an hour. In reality, this is what true Digital Transformation is doing to the world of business and IT. In fact, I’ve recently created a video of me rolling out something meaningful in ten minutes! (link TBC)
So here at Unleashed, our methodology is to Automate! I’m not a Meerkat from the advert either.
Get things off paper, Excel and Word pro-formas and on to a proper BPM tool. As usual, Unleashed are pretty agnostic – although at the moment our favourites are KiSSFLOW and PowerApps.
By just saying screw it, let’s do it – you save a whole bunch of money on worrying about legacy systems, wasting time process mapping and worrying about who’s paying the consultants and developers.
Secondly, BPM systems are relatively cheap and easy. Rather than IT being the bottleneck, the experts or ‘citizen developers’ as we’ve started calling them (process owners to you and me). Can just go-ahead and do a lot of the work.
Once implemented on an electronic system, your horizons are widened – that, and you have a lot more data recorded that you didn’t have before. Electronic systems can measure the time taken for things to be approved or modified. It really does open meaningful insights that you never had before.
This to me, is the most important point to highlight. I’ve done the job of business process re-engineering more times than I care to remember. Those people who aren’t unhelpful, but just don’t help. They are the ones that cause the largest damage. They nod along in meetings, cheer a few positive words. Afterwards, they’re calling you names behind your back, demoralising everyone else to be equally, just not helpful.
The most successful BPM systems we’ve implemented are when the senior manager makes the decision. We’ve implemented and trained a few power users to look after it. We’ve taken forms from the paper world and replicated them online. What I like to call the path of least resistance. Looks the same, but electronic, surely you can’t be unhappy with that!?
We tend to get efficiency and accuracy savings of about 25-50% – generally, we can do some validations and lockups that prevent input errors that make that figure so high. That is quite impressive and we’ve not even re-engineered whats done.
Again, in general, customers come back to us about 12 months later filled with many ideas. They’ve seen opportunities that can be implemented quickly and easily, based on the real-world evidence of the system running. Typically, at this point, this is where we start incrementally re-engineering the process. Usually, this is evidence-based tweaks, based off information the system is recording.
Slowly, the many small changes over several years lead you to have a completely different process than where you started. There is little resistance, there are often more people willing to be helpful too and those that still grumble are hit with the figures that the system is collecting as to where the process could be better.
To summarise my final point, on these systems change is cheap. It does not really need companies like Unleashed to do it. Some customers like it, others are prepared to own their own systems. Usually, we do minor changes in minutes, and even the biggest is less than a day. Often, no coding and no developers and very little technical expertise required.
Let’s just call it Digital Process Transformation
All this is new, it’s exciting. We don’t have many names for the methodologies yet, let’s face it the academics will be years behind us.
Although I’m sticking with Digital Process Transformation as my term!
In the real world of practical doing things – businesses like yours are doing this now and we’d like to help.
