I recently wrote some lines for a friend of mine on the similarities of an editor’s job and a certification body manager job, and on the risks they both incur.

Being myself an automotive auditor, I’m very familiar with AIAG’s FMEA approach (Failure Mode & Effect Analysis) but all the duels between customer and supplier, and auditor and auditee to rate severity, occurrence and detection left – and leave – me quite suspicious on the effectiveness of the FMEA approach.

THE GLOW OF FAULT TREE ANALYSIS (FTA)
On the other hand, the FTA approach still has such a space-age glow that it could hardly be thought to be applicable to a scarcely technical business such as provision of services.

But reviewing ISO 9001 (2015) and writing to the friend of mine convinced me that I could start walking on this path.

I had, and still have, five basic beliefs:

1. FTA is a top-down process, against FMEA, which is bottom-up;
2. I’ve come to this with a more than thirty-years work experience in services, covering a variety of businesses;
3. Literature and bibliography do not seem to be abundant on this matter, though there is plenty of articles, or short writings, that, when read between the lines, all hint at this issue, though not systematically;
4. Make FTA user-friendly as much as possible to non-technically skilled service providers, based on perceived experience, and therefore “home-made”;
5. ISO 9001 (2015) highlights its applicability to services, to, and to manage the risks connected with their provision.

MY LOGIC FLOW
As with any unknown tool, its initial use may arouse feelings of worry, if not of fear, that will gradually fade as one gets used to master it: FTA is no exception.  Here’s my logic:

“FTA is a top-down, deductive failure analysis in which undesired state or system is analyzed using boolean logic to combine lower-level events.” And, “Boolean logic is a form of algebra in which all values are reduced to either TRUE or FALSE.”

 Both above quotes are taken from Wikipedia – the fount of all knowledge.  Now, some of us are familiar with the 0-1 – or true-false binary computer language, though sophisticated thinkers maintain that nothing can be 100% true or false, and that, being the computer 0-1 binary system based on electricity transmission, there’ll always be some measure of leaking.  But these are finesses.

The graphical structure of a FTA tree surely looks impressive but, if we look at it closer, it reminds of a puzzle game, or of kids’ two-dimensions Lego-like toys.

FTA uses a number of symbols, to build structures: event symbols (basic, external, undeveloped, conditioning); gate symbols (or, and, exclusive or, priority and, inhibit); transfer symbols (in, out).

To make it more understandable to novices, FMEA’s are started based on the question “what can go wrong?” and Ishikawa’s fish-bones chart “the probable causes of undesired effects”.  FTA graphs represent, in their simplest form, events and their features, interfaces / interactions among events and data / information flows among events via their interactions (or “transfers”).

It would take too long, and too much of your well-meant patience, to compare FTA to FMEA and Ishikawa fish-bone philosophies and methodologies.  But, to try to do justice to a prevention methodology unjustly feared of, let me remind you what Wikipedia writes about it:

“… the most common and popular way (to model a FTA) can be summarized in a few steps. A single fault tree is used to analyze one and only one undesired event or top event, which may be subsequently fed into another fault tree as a basic event.”

CERTIFICATION BODY STORY
One example is worth a thousand words, they say, so, please, stay with me.  Here’s my story:

The certification board of a multinational registrar had to hastily decide whether to issue a certificate to a very important customer, that was putting a lot of pressure on the board.

The audit package (report, check-lists & notes, audit plan, non-conformities and corrective actions records, and so on) had already been thotoughly reviewed by the certification manager, and he was not satisfied.  He told the certification board so, and he was asked if, on his own judgement, the customer site could be granted registration.  This was obviously beyond the authorities & responsibilities of the certification manager, who, being a member of the certification board, could only vote yes or no.

This story resulted in a big mess: the board would not decide.   The customer was very unsatisfied and angrily called the accreditation body in, the certification manager left, the registrar top management started an inquiry.

DIFFERENT SCENARIOS
Were the inquiry conducted according to FMEA best practices, the following would have occurred.  It would have determined and implemented containment action, not to let the situation get worse; corrective action to find out why the certification manager was not happy with the audit package, in the first place; and may be even go as far as to define preventive action to make reasonably sure such a failure would not recur.

Were the inquiry conducted according to Ishikawa’s fish-bone analysis, it would have come out with a root cause, that most probably would have been defined as human or communication error, therefore leaving the unseeable two-thirds of the iceberg to be explored.

Were the inquiry conducted based on even the simplest FTA, it would have identified and classified events, gates and transfer points.  But: while the FMEA records would have been to be revised, meaning additional work, and the fish-bone leaving a taste of wish-bone in one’s mouth, the FTA results would be – if one only wanted to – a ready-to-learn lesson.

The three-concepts FTA approach, that is event (preferably one at the time), gates, transfers, is typical of the boolean yes / no, true / false, OK / NOK logic and – though not being 100% applicable to very fine, micro-matters, it can be depended upon for medium- to macro-matters, such as daily recurring events.

The events-making processes are flow- or stream-like: the event classification as “basic, external, undeveloped, conditioning”, the gate classification as “or, and, exclusive or, priority and, inhibit” and the transfer classification “in, out” – beyond and apart the meaning each of us would give to each or any attribute above – all point to a direction making FTA to be seen as a more continuous failure-preventing system, as compared to FMEA or Ishikawa’s fish-bone.

FTA BENEFITS
This FTA’s plusses are also confirmed by its five step structure:

1. Define the undesired event to study.
2. Obtain an understanding of the system (or event environment).
3. Construct the fault tree, based on “and” and “or” gates.
4. Evaluate the fault tree (aiming to risk management and identification of hazards).
5. Control the hazards identified.

It is not required that the tree be nice looking, provided it works; and, as far as my own experience is concerned, also in its simplest form, the FTA-branching approach can be a very powerful tool in hazards identification, risk management and failure prevention in non-technical businesses such as much of services provision is.

The below quote from Application of fault tree analysis to the service process: service tree analysis approach, by Y. Geum, H. Seol, S. Lee, Y. Park – Seoul National University, Seoul, Republic of Korea – Emerald Group Publishing Limited, Journal Of Service Management, Vol. 20 No. 4, 2009:

“… distinctive features of services, vis-a-vis the manufacturing. First and foremost, as a co-producer or a partial employee, the customer may take an active part to the service operation.  As services cannot be separated from customers, customer participation perspectives should be captured in the service process.  Second, service firms have faced with limited analytical and quantitative tools to systematically describe the service processes.  Thus, quantitative analysis should be made to provide operational and strategic implications. The tree structure has been recognized as an effective representation method to visualize the complex process. Most important, the Boolean logic of the tree can mirror customers’ perspective; elements with an AND gate can be interpreted as “always selected by customers” whereas elements with an OR gate as “optionally selected by customer”.  In addition, as the Boolean logic tree is also capable of identifying critical events, analytical power of the Boolean logic tree can be applied in the service process to quantitatively measure the characteristics and impacts of the service elements.”

” … since the basic concept of this paper that the tree is constructed according to the customer perspective on the process is not applied to every service operation, (are) proposed three types of operation, characterized by the inputs that are processed: customer processing operations (CPO), information processing operations (IPO), and material processing operations (MPO).”

The case example quoted in paragraph 445 – hospital service – identifies the hospital service as top event, which is subsequently broken down into branch events, namely: visit, registration, medical examination, payment.  Payment – as an example – is further broken down into “payment through machine” and “payment through person events”.

I look forward to your comments and exchange of experience; thank you.