Single Point of Failure

I keep revisiting old articles, not necessarily because I've run out of things to say, but because I often feel I did not state my case well enough. This mainly happened because I did not have enough practical experience outside of consulting to be able to be relevant. Here's for a second go at my article on process redundancies and why they can make sense.

Defining a single point of failure

A single point of failure is a point in a system (such as a (manual) process) which, if it fails, will bring the whole system down. Not all redundancies were created because people felt they could afford to add an additional, non value added layer. Rather, redundancy in systems were created to avoid single point of failure.

Of course, during crisis times, process efficiency reviews such as Process Impact Analyses (PIA's) are likely to identify redundant activities. The subsequent reengineering will lead to significant optimizations in process efficiency. However, while aiming to reduce the unnecessary redudancy in systems there are a lot of reengineering projects which overshoot.

The butcher's apprentice

Large scale reengineering projects sometimes cut indiscriminately through processes and systems. In my experience, especially projects which originate out of a dire need to reduce expenditure will have overall expenditure reduction targets that are most easily applied across the board. That this approach often makes no sense at all is never considered. These projects result in the creation of single points of failure in processes where prior to the reengineering effort a necessary redundancy existed. Indiscriminate cutting into a process is a bit like being a butcher's apprentice ... mistakes by cutting the wrong piece of the meat can be quite costly.

And let's face the hard truth we failed to face so often in the past: our people (who are responsible for doing the process work) are expensive to make mistakes with. Especially, but not only if these people are good in what they do.

It gets worse. Given these reengineering exercises are most often executed by external parties, those mistakes are mostly made by young, ambitious but necessarily inexperienced consultants with little to no real life process background.

Is there a way to avoid this? Can you detect and fix a single point of failure?

Detecting single points of failure

To detect a single point of failure, it's important to take the time and talk to the people that execute the process every single day. They're pretty much the only ones that are aware how the process actually functions. And talking, preceeded by gaining the trust of those people and earning that trust is essential. Not only because you may be surprised about the amount of process knowledge that was not captured in the process documentation. No, quite often these people are the only ones that are aware of the existence of the single point of failure and all possible implications that brings with it. Even better, they can quite likely help you avoid it. There are other ways, which I list below, but none as powerful as talking to people.

Alternative or additional actions

The following alternative but most often additional actions can help you in your search for single points of failure. Note that these require a significant investment in time and means to properly execute. In my opinion, only coupled with in depth discussion with process owners and operators will they yield the most relevant results. You can:

1. Map the process: understanding the process and the interactions in the process is a powerful way to understand what is actually going on. Again, do not base yourself on procedural descriptions. Rather, interview people, monitor process execution and look at what's really there. You may be able to identify your single points of failure in the process itself;
2. Identify choke points during a walk-through or based on process indicators: quite often, a choke point where backlog piles up is a good indicator of a single point of failure. Process indicators which are often indicative of a problem in a process will be a relevant factor as well.

After identification, you need to solve the issue

As I stated above, a significant number of reengineering projects stripped operations to the bare bones, only to find out that because of the existence of single points of failure the process completeness, timeliness and accuracy were largely jeopardized.

That's why I dare you to create or maintain the necessary redundancy in the process. This is often a cost benefit decision. In case the single point of failure risks risks collapsing or significantly disturbing the process, creating a redundancy in your process is not overspending. Rather, it makes good business sense if the cost of failure is significantly higher than the cost of the redundancy, over time.

The advantages of risk and evidence based reengineering

I've expanded on a post I wrote for my old reengineering blog in 2010. Enjoy!

I’ve seen a lot of failed reengineering attempts. There are a lot of reasons why reengineering exercises fail and it’s not the purpose of this blog post to evaluate all possible reasons. What I do want to discuss, briefly, is why evidence based reengineering is a relevant, different and I believe more successful approach.

Reengineering 101

Traditionally, the top line activities in reengineering are executed according to the following pattern:

1. the assessment of the current, or as-is situation
2. the establishment of a wanted, future, or to-be situation
3. the analysis of the differences between what is now and where we want to be, or the gap analysis
4. the development and execution of an action plan to change the current into the wanted, future situation.

For anyone who has ever looked in awe at a consultant, well, this is pretty much what reengineering experts do. They’ll tell you it’s much more complex than this, but in essence, this is what it really boils down to.

Reengineering failures

Among the reasons why a project potentially goes awry is the very blatant one of starting from the wrong assessment of the as is.

How is that possible? Lack of validation is likely to be one, but a more likely one is a situation where the findings were validated by the management, but ultimately proved to be wrong anyway, because management did not have all information or was not aware of certain issues. After all, management is not deity (although behaviorally, this tends to be assumed in some cases) and therefore management can fail.

This is exactly where evidence enter the picture.

What is reengineering evidence and how do you use it?

Evidence is most certainly not interviews, especially not internal interviews. Most as is assessments are based on interviews with management and close collaborators of management. Consultants often assume that this information is complete, accurate, relevant and timely, but often this is anything but. Especially interviews with internal collaborators tend to confirm whatever it is that the collaborator thinks his management thinks or wants to hear.

Now, any auditor can tell you that internal evidence is the weakest of all evidence material, and reengineering interviews confirm this. Therefore, if interviews are the only information source, execute interviews with multiple independent sources with a clear view on the actual situation of the enterprise. Think clients, suppliers … even competition.

Oh, by the way, interviewing competitors to learn better practices under the guise of "research" is a common practice among some of the better known consulting organisations.

Relevant evidence

Better yet, start gathering hard data. Payroll data, other direct and indirect cost data, information from internal systems but also information gathered from banks, other lenders or financiers when it concerns financial information.

Go outside to clients and suppliers. A supplier will tell you if there are payment delays. A client will inform you of quality issues with products or services, of delay in delivery, of issues with execution … former clients are often a source of highly relevant information.

I remember a reengineering project I was involved in a couple of years ago where, in response to a simple request for information on payment terms and reasons for late payment by the specific client, we received an envelope full of evidence on very operational and quality issues. Following up with this third party, we finally understood what management was reluctant to share with us: significant quality control issues after a production line moved to a new location with lower labor cost and more manual interaction in the production process. None of the managers, afraid for the resulting backlash, was willing to share this.

Risk models as a basis for evidence gathering

A good means to structure the work is around risk models. I am a very big fan of risk based reengineering, and using risk models as a basis for reengineering is a good way to approach this exercise. Risk models allow for structuring of potential exposures in an organization, and will result in targeted exercises where the cost of reengineering is balanced as compared to the added benefit it entails.

The external cost of internal optimization

Traditional cost reductions don’t take customers in account

Most organisations do not realize they are imposing significant burdens on their users. Any interaction involves a transaction cost. Organizations competed on cost reduction platforms, trying to drive down the transaction cost as low as possible … for their own operations. Quite often, an important part of the transaction cost is pushed onto the user, especially in situations of market dominance. What organizations often fail to see is that users will integrate the cost of the interaction in their choice. Organizations should therefore strive not to lower only their transaction costs, but to reduce the overall transaction burden, including the burden to their users.

The boundaries of cost reduction

Since the late ’80s we’ve gone from reengineering over right sizing to reengineering revisited. The aim, often rightly so, was to cut the fat out of organizations. This ‘fat’ does not add to the value delivery nor to the internal optimization of activities, and has to be removed. As with any exercise, in some cases we cut too deep. On occasion, this turned into an opportunity for certain companies which provided outsourcing services, hence the sudden bloom of the outsourcing business. After all, whether you cut costs or not, the job had to be done.

The focus on ‘core’ activities

Questions on which activities were ‘core’ to the business were asked more and more often, and non-core activities were pushed away, in order for organizations to focus on their core business. Again, not necessarily bad. However … When reengineering and restructuring, organizations often pushed out part of the requirements they had and put these responsibilities with users. It started out as a fadish project. I remember walking around in Southern California in the late 80’s, being charmed by the ‘build your own teddybear’ shops that sprouted like mushrooms. Teddybear fans built their own, and part of the production process was pushed out to the fans. This can go wrong, and we often find it has. We’ve seen situations where users were asked to provide information which the organization had in its systems, again and again.

User revolts

What a lot of companies do not understand is that users will walk away from a difficult interactions. On the contrary, the easier the transaction, the more often users will stick with the organization.

Examples

Let’s look at a couple of internet enabled examples: * Look at purchasing habits of people owning Amazon Kindles. Their purchasing effort is minimal. The ‘one-click’ system allows for a purchase of a book with only one click. Amazon even offers advice based on their extensive purchasing profiles. People who purchased this book, also purchased … * look at the recent introduction of the Genius function to the Apple App Store. Previously reserved only for music selection advice, Apple has extended its functionality to advice clients on relevant apps for their iPhone, iPod Touches or iPads.

Make it easier for users to engage with you than with any other organization

Organizations should strive to make the use decision and especially the administration related to the use decision and actual act of using their tools, services, products … as easy as possible. The information to do this is available, often in the organization’s systems. In addition, the technology exists to enable even fysical purchases to be a lot less painfull. What organisations need, and currently lack, is a good, quantified understanding of the cost of the transaction to their users.

Reengineering and customer satisfaction

The focus of reengineering and process optimization

Many organizations have invested significant time and means in internal process optimization. Often for all the right reasons, such as performance improvements which were essential and reduced organisational bloat. Occasionally for the wrong reasons, such as the reaction the stock market will have on the intent to reengineer: management by announcement. These optimizations are almost always internal: for most comanies, direct cost control over a process ended at their door. But does it? Should there not be an external focus?

The relevance of the external focus

Internal processes impact the customer base, either directly or indirectly. So if an organization starts restructuring these processes, it will impact its customer experience. You really can’t have one without the other. So during a reengineering project, the focus needs to be external as well. This is often neglected. If an organization fails to address the impacts of its process adaptations on its customer base, it is likely to alienate customers. This way, internal cost reduction leads to an external revenue reduction. Usually not the purpose.

first step towards understanding – walk a mile in your customer’s shoes

There are a couple of concrete actions an organization can commit itself to in order to gain a better understanding of the external impact its reengineered procedures can have.

A first thing to do, to paraphrase Steven Covey, is to first seek to understand. You can only truly appreciate the issues your customers have if you understand them. Not only on the intellectual level, but on the emotional level as well. And the best way to do that is to become your own customer.

Approach your organization as if it were a third party, and engage in a transaction. What happens? What do you need to do? Do you understand why the process requires you to perform certain actions? Is it apparent to your customers? Is it really necessary?

Based on this initial insight, this understanding, you will be in a much better position to understand the genuine concerns your customers may have.