STC Quality SIG Article:
Using FMEA and Process Maps in Financial Services

By Lois Marsh, Senior Member, Toronto chapter
Reprinted from Direction, newsletter of the Policies and Procedures SIG STC
Third Quarter 2005

Founded in 1817, my employer is one of the oldest and largest financial services providers in North America. Like most government-regulated companies, we produce and maintain a large volume of policies and procedures—and we have used the same methodology for reviewing them for many years: we ask the content owners to update the content, then edit and re-publish if necessary.

In this post-Enron era, though, there’s a change in the wind that has impacted our policies and procedures review process. Our internal auditors recently suggested we add some new tools: process mapping and Failure Mode and Effects Analysis.

Introducing the FMEA methodology

Initially developed by aerospace engineers (QPI SIG note: in the Apollo space program), Failure Mode and Effects Analysis (FMEA) is a methodology for analyzing potential process failures so that preventive controls can be built in. You can learn a great deal about FMEA on the internet. This article focuses on some challenges we faced in implementing the methodology in a service environment.

QPI SIG note: In FMEA, the analyst creates a matrix listing all characteristics of the product and all possible ways it might fail. The potential effects of failure are identified, as well as possible causes and the controls that are in place to prevent failure. Risk assessment can be included, for existing controls and improvement actions.

For our first project, we hired an outside consultant to orient us to FMEA. As manager of the Market Risk Documentation Team, I was asked to roll out the methodology to the other groups in our business unit and keep the momentum going.

We were also asked to create process maps to be used together with the FMEA methodology. Flowcharting of processes was not new to me, but doing so within the FMEA framework was. For instance, it took us a few tries to agree on our definition of a control point (preventive step). For us, a control point is defined as “a point in a process denoting accountability and overall responsibility for accuracy and completeness.” It is typically a management review of the results from a critical step in a procedure.

It was a real stretch for our business unit to see how a tool used widely in the auto industry applied to the business of analyzing market risk. Let’s face it—manufacturing widgets seems a far cry from analyzing Delta/Gamma/Vega curves for yesterday’s financial trades.

Once people became comfortable with admitting to potential failures, they were more enthusiastic about the FMEA process and identifying preventive steps. The task that initially caused some groaning became an accepted part of procedure reviews. We also faced the challenge of deciding what level of detail to include in our process maps, and how to effectively link outputs from one process to subsequent processes as inputs. Editing for consistency in labeling and hyper linking related maps proved useful.

Benefits of process mapping

Mapping the processes was invaluable and very much worth the effort. It’s easier to gain consensus on how a procedure can be improved using a flowchart than a narrative document because the flowchart is less open to interpretation. Process maps now form an important part of all our policies and procedures projects. We involve as many team members as possible in the mapping meetings, and it is well worth the investment—the sessions often reveal misunderstandings or control gaps that can introduce unwanted risk.

High-level process maps now help define the scope for our detailed documentation. They also make the job of identifying changes in procedures easier during periodic reviews. They act as visual cues, and reviewing them is more likely to bring to light changes than just asking a subject matter expert to read a whole chapter of their policy and procedure manual.

Role Change

One surprise outcome of the FMEA methodology was that my own role as a documentation specialist has significantly broadened. Not only am I expected to develop and publish policies and procedures, but also to facilitate minor process reengineering as a result of our FMEA work. This has been reasonably easy for me because I spent several years as a business analyst. It’s more challenging for documentation staff who may see themselves primarily as compilers and editors. For me, it’s an exciting challenge to apply new methodologies to policies and procedures. Who knows? I may end up on a Six Sigma team yet!

About the author

Lois Marsh is Manager of Documentation for Market Risk with BMO Financial Services in Toronto, Canada and editor of the newsletter of the Policies and Procedures SIG of STC.