Business Reengineering
Business reengineering got off to a bad start. After Dr. Michael Hammer published his article “Obliterate, don’t Automate” and followed it up with the bestseller “Re-engineering the Corporation” the reengineering revolution took off.
CEOs around the world were excited by the idea of quantum improvements in performance. The dream of “starting again with a clean sheet” was appealing.
However, the theory did not translate into practice. Teams went away, often for months, to ‘re-engineer’ their businesses and came back to a wall of resistance. The teams believed they had ‘the answer,’ the rest of the organization was still trying to find the question.
Early business reengineering failed for a number of reasons;
- It wasn’t process based – the original focus of re-engineering was business rules. It was believed that operational complexity was driven by inappropriate business rules. This was wrong and even Dr Hammer admitted this in his later (2001) book, “Agenda”.
- It was too ambitious – businesses are just too complex to reinvent from a ‘clean sheet of paper’ as the starting point. Even the smallest business has core, secondary, supporting and other types of processes across their operations. In large corporations, this complexity is magnified. The aim was impossible to achieve.
- No one knew what they were doing. Reengineering was a concept rather than a repeatable process. Looking back at the ‘training’ given for business re-engineering it was conceptual at best.
Process Reengineering
The death of the initial business reengineering revolution was hastened by the early 1990’s focus on ‘downsizing.’ Reengineering was seen as taking too long to be of value in this exercise; and most organizations were getting rid of the very people who could do the re-engineering.
So business re-engineering was reborn as ‘process reengineering’. Most people didn’t notice the change from a business to a process focus, but it is process reengineering that has survived (albeit in a number of guises, as we’ll discuss later).
Initially ‘process improvement’ was the focus. This was initially driven by cost-reduction and/or quality improvement agendas. Hence the rise of such approaches as Activity based analysis (ABA) and Six Sigma.
Organizational processes were reviewed for inefficiencies, problems and errors. Although paraded under the nomenclature of ‘re-engineering’ these early approaches were essentially only process improvement techniques. The actual need for the process being reviewed was rarely questioned and radical redesign was very much the exception.
One reason for this ‘dumb-downed’ approach to re-engineering was that many processes were so inefficient that significant improvements could be achieved with these limited approaches.
A second reason was fear of organizational change. Radical process redesign could lead to radical organization change and that was a complication ‘process consultants’ wanted to avoid.
A third reason was the creation of ‘process specialists.’ All they seemed to know was to map processes - endlessly. Hence many a CEO has exclaimed, “If I see another process map I’ll scream” as weeks, months and years were spent ‘mapping processes’ to no avail. (As we’ll see the very concept of a ‘process specialist’ corrupts the re-engineering process.)
Through the 1990’s ‘process re-engineering’ meandered to the point that any approach that talked of a process or produced a process map was called “re-engineering.” Hence the term got a very bad name.
Then, to make matters worse the IT software industry got involved.
Process management
Always looking for something to automate, “process management” tools came into being to help the re-engineering efforts. They did not realize that they were actually reversing the very premise of business re-engineering by “automating not obliterating”! If you’re using “BPM software” you’re not re-engineering. With true business re-engineering, process management software is of little value because the processes being reviewed change so much that time spent capturing current processes in the software is really wasted as their replacements are (or should be) so very different and cannot be adapted from the originals.
The second way the IT industry adopted processes was by embedding process workflow in their software under the over-used stamp of “best practice.” “Buy our software and you’ll automatically get worlds best practice workflow processes – so why design you own (obviously inferior processes)?”
This hijacking of processes and in effect, negation of process re-engineering almost spelled the end of re-engineering. Senior Management, already frustrated at the lack of process improvement their own process staff had actually made, were ripe to be sold the “worlds best practice” as the solution. Many a CEO or General Manager has said they don’t believe their staff can or would come up with any significant process improvements. The premise is that “If they could, surely they would now!” This is a false premise, as we’ll show later.
Anything to do with processes
By the early 2000s many so-called process-re-engineering practitioners had no idea of the origins of re-engineering (and probably had never read any of Dr Hammer’s works). Doing anything with processes became synonymous with ‘re-engineering.’ And the results continued to be poor.
Understanding orthodox approaches’ deficiencies
Organizations need to improve. The pressure to simultaneously reduce costs, increase profitability and improve customer service is unrelenting.
Previous attempts to slash costs by downsizing, for example, have caused subsequent problems as less people try to cope with increasing work demands. The promise of expensive systems to reduce costs and improve service has also been largely found to be unfulfilled. Conventional process improvement, the use of consultants or the adoption of, say, Six-Sigma have all been found to be expensive and to not deliver the results or level of improvements expected, indeed needed. Yet, conventional wisdom offers only these approaches (and internal continuous improvement) as the most common options.
Most approaches to improving processes start with the current process and seek to remove ‘noise’, waste, the causes of errors, delays and other problems. Depending on the approach used, the process is mapped (endlessly or superficially) and the existing metrics are gathered so that every step’s cost is known (within the limitations of cost accounting). Sources of problems are discovered and ideas for improvement are sought and their impacts computed. The outcome is an improved process with less wasted steps, errors and problems.
This is good but not good enough. Each of the most common approaches has serious deficiencies.
Blue sky — Asking what they want.
Of course there are the (somewhat justified) complaints that “the business does not know what it wants”. This is true on the conscious level. They’ll ask for what they think they want in good faith, but don’t have the wherewithal to define their true business requirements. As one chairperson once put it, “Being asked what you want out of a system is a bit like being asked what you want out of life! What are the options, the boundaries, the opportunities?”
You can’t usefully ask for requirements, people’s brains don’t work that way. They’ll talk about current problems, deep-seated frustrations and other conscious issues. What they won’t talk about is the strategic intent of the processes or the detailed inter-linkages needed.
Similarly, attempts to define the ‘as is’ (current state) in a workshop with or without some prior analysis is equally useless. The people who operate the current operational processes know them in their non-conscious; yet most workshops are designed to operate at the conscious level; an immediate and important mis-match. As a result, the ‘as is’ definition is deficient (many of the details, alternatives and variations are missed) and the consequent ‘to be’ definition is therefore also inadequate.
Vanilla sky — ‘Out of the box’ software adoption
Another favorite approach seems to be to take the software’s solution ‘vanilla’ or ‘out of the box’. You then change the business to fit the software avoiding ‘software customization’ (which is “known to be bad”).
The first thing to remember is that ‘vanilla’ is a flavor, not neutral. Software is comprised of automated processes. So, when you’re installing software you’re installing (someone else’s) processes. Processes are how your organization works, competes, does business and makes money. Processes impact your operating costs, your flexibility to respond to market changes, your service offerings. Yet most software processes are adopted blind, with little to no understanding or evaluation.
There is a belief, promoted by the software vendors and systems implementers, that their software’s processes are better than yours so, by adopting their processes, you’ll instantly be more efficient and effective. This isn’t necessarily so, but lets go with it for the moment.
Quality and Time view — (Lean) Six-Sigma
Six-Sigma, beloved by so many organizations, can only do ‘slices’ of a major end-to-end process at a time and can take up to a year to do, say, an end to end mortgage or order-to-supply process.
The strength of Six Sigma is that it is data driven. The weakness of Six Sigma is that it is data driven! If you don’t have the data you cannot use Six Sigma. However, at times the data is irrelevant as the process should not exist at all. Six Sigma is a quality improvement/time reduction process. It is designed to reduce errors, wasted time and other problems. Define the problem, quantify it, find the root cause, remediate it and measure the results. Great for solving problems, poor for improving organizational performance.[1]
The (lack of) results
From these orthodox approaches, you can have reduced errors, improved processes, consequential change ideas and new metrics to show the likely value. What you usually don’t have is:
- a full and deep understanding of the strategic intent of each process and, therefore, its ongoing relevance and value
- a detailed value-analysis of each process step, why it exists and how it contributes to the strategic intent of the process
- a clear specification of where information systems can be used to further simplify the processes
- or, a defined list of measurable business end states (outcomes) that the process changes will deliver.
You also usually don’t have a high level of understanding amongst the existing staff as to why the process has to change, the value of the changes proposed and what’s in it for them (WIIFM). This is a recipe for generating the famed ‘resistance to change’.
TOP recognized that a better way was needed that overcame these deficiencies and delivered results fast.
Business Simplification
So we developed a new approach to business reengineering that overcame the problems with the earlier approaches and achieved the intent of the original business reengineering idea – implementable, quantum business improvement. To differentiate it from the ‘noise’ and bad vibes surrounding ‘re-engineering,’ we called it, “Business Simplification” (Simplification).
Simplification delivers a new standard in improving operational performance and defining your business requirements that simultaneously...
- significantly simplifies your operational processes (routinely by more then 40%),[2]
- moves your organization towards new levels of performance in terms of lower cost/improved service
- while simultaneously defining your business (systems) needs
- your desired business outcomes (end states)
- and business change requirements — how to get there from here.
Simplification offers an approach to business requirements definition that is faster, more cost-effective and simpler than the alternatives.
Key design aspects of Business Simplification include:
- It is based on over 20 years research and a body of knowledge in relation to business processes, how they operate and can be simplified and improved.
You need to thoroughly understand processes if you’re going to improve them. - It leverages the latest neuroscience research into how people think, innovate, adapt and work. Simplification therefore works at both people’s conscious and non-conscious levels to generate extraordinary results. Results even those involved never thought were possible!
- We have found that it is far easier to teach Simplification to internal staff who operate the processes than to get professional analysts (‘process consultants’) to understand in depth the existing processes. Simplification, therefore, is designed to be executed by your own internal staff (with no prior experience required).
- This full staff involvement ensures the resultant outcomes are understood, committed to and desired by the staff as the new way of working. Hence Simplification also generates a momentum for and a commitment to the resultant change. We don’t encounter ‘resistance to change’.
While based on the original intent of reengineering (obliterate, don’t automate), Simplification arms your own staff to define and then deliver transformational change – including tightly configured software support solutions that deliver exceptional business results.
