Essential Guide to QMS

8/13/2019 Essential Guide to QMS

1/24

Selecting, Implementing,and Using QMS SoftwareSolutions

EtQ, Inc.THE QMS GUIDEBOOK


2/24www.etq.com 800.354.4476 [email protected]

The QMS Guidebook: Selecting, Implementing, and Using QMS Software Solutions

Table of Contents

Introduction: Why do We need QMS?

Getting on the Quality Management Software Soapbox. . . . . . . . . . . . . . . 1

Getting Started on Your Journey

8 Simple Rules for Selecting a Quality Management Software System . . . . . . . . 4

Look Under the Surface: 4 Things to Ask a Compliance Software Vendor . . . . . . . 6

Tips for Implementation Success

Build vs. Buy: Best-Practice QMS Solution over Custom Development . . . . . . . . 8

Avoid Scope Creep in Enterprise Software Implementation . . . . . . . . . . . . .11

ROI: Assessing Value in a Quality and EHS Management System . . . . . . . . . . .13

Best Practices for QMS Solutions

The Importance of Risk in the Complex Quality Lifecycle . . . . . . . . . . . . . .15

Risk Assessment: Creating a Risk Matrix . . . . . . . . . . . . . . . . . . . . . .16

Three Keys to Global Harmonization in Quality: Learning to Share . . . . . . . . . .18

Final Thoughts: Fun Takes on QMS Software

Is Quality Dying a Slow Death, or Evolving Beyond Definition? . . . . . . . . . . . .19

What Star Wars Can Learn from Quality Management Software . . . . . . . . . . .20


3/24

1 |1 |

www.etq.com 800.354.4476 [email protected]


Getting on the Quality Management Software SoapboxIntroduction: Why do We need QMS?

s The Quality Management Software market Evolving to be

asier, or more Complex?

As the world market evolves, product lifecycles are speeding up

o accommodate market demand and keep up with competing

roducts. As a result, Quality benchmarks need to evolve as well. Risk

s fast becoming the benchmark for assessing Quality throughout an

rganization. This is because organizations need a systematic and

bjective way of looking at incoming information and making deci-

ions on how best to manage Quality. Risk Management provides

his benchmarkit allows for a quantitative method to review the

ata and come up with decision criteria to help make better deci-

ions leading to better Quality. In this day and age, companies

annot afford to lag on their Qualityproduct lifecycles are moving

oo fast and companies cannot keep up. Risk has evolved over the

ears to be more quantitative in nature and is incorporated into

raditional Quality models in order to keep up with the pace of the

ew markets. This evolution is seen in adopting risk matrices incor-

orated into multiple facets of the Quality dynamic; Complaints,

Audits, Nonconformances, Corrective Actions, and similar functions

ll use Risk in some form or another. This is growing in interest to the

oint in which risk activities often govern the processes and are fully

ntegrated in the traditional workflows.

Whereas this was once a discipline reserved for only the leading edge

ompanies, is now becoming mainstream. Most software solutions

ave some element of risk built in, and as more risk solutions are

ffered, more companies adopt the risk methodologies. This main-

tream adoption is going on now and soon it will be hard to find a

ompany that doesnt have some sort of risk built into their system.

he bottom line is that Risk Management is getting easier to access

or all organizations; but it is still a complex dynamic. Each company

will need to determine which risk model best fits their business

eeds. The trick is to find a solution that is flexible enough to provide

he level of detail needed for risk activities, but make it easy for each

ompany to adapt and grow their Risk Management program.

What You Didnt Know, or Were Afraid to AThe main obstacle to truly being risk-based is the shift in chan

your understanding of Quality and risk. Its sometimes difficu

understand what is critical in a business, and therefore ove

Corrective Actions. Many feel its better to just initiate the Corre

Action and deal with the process than truly assess whether you

need it. Not every adverse events needs to be a Corrective Action

dilutes the purpose of the process. Corrective Actions are desig

to correct critical and/or systemic issues. Risk Assessment and

Management are designed to help discern which is critical and w

is not critical. Non-critical events can be immediately corre

however, many businesses do not see the value of correcting

critical events in the source data in which they are found.

Especially in regulated industries where the scrutiny is so high

often want to err on the side of caution and do a full-blown in

tigation on a minor event, such as a label smudge. While this

important correction, its not critical and wastes resources and

for a business. First and foremost, organizations need to re

where their critical events lie, focus on those first, then worry a

the non-critical areas as they come. Risk Management provides

ability to filter out the critical events and make the right decision

how to handle them.

Why Companies are Still Reluctant to Purcha QMSSoftware is a key component in todays industries. Again, indus

are moving faster and much like the automated assembly line, so

must the business processes that govern manufacturing be a

mated. So why are people so hesitant to implement software?

are a few potential reasons:

The Fallacy of the Custom Solution:1. Most people remem

the days of the custom-developed solution, where in ord

get the software to work the way you want it to, you ne

team of developers over the period of a year or more to cod

system into your companys mold. While the stigma rem

the software has evolved beyond this. Especially in bus

process automation (such as Quality), the custom soluti

gone, giving way to the configured solution. Adaptations

changes to the system are all encased in settings and drag

drop interfaces, making the configuration of the system as

as changing your Facebook settings. Now the business user

a developer, is adapting the system to meet the business n

this is extremely powerful and time-saving on resources

is also putting the software design in the hands of the pe

who actually use the tools. Very powerful, and organization

slowly warming up to this concept.

Getting on the Quality Management Software

Soapbox


4/24

2 |



The Fallacy that Software is too Expensive:. Much like the

advent of standardize parts in the automotive industry, having

a configured system that has all the components developed out

of the box has driven the price point down considerably. One

solution can satisfy many different organizations needs, and

so companies can now get into a decent enterprise software

product for a fraction of the cost 10, even 5 years ago.

The Fallacy of the In-House Maintenance:. Another issue

that comes up with many smaller businesses is a small IT foot-

print. They cannot manage yet another system, and IT will not

administer the system for them. Thanks to the advent of cloud

computing, we are seeing this paradigm slowly fade. Software as

a Service (SaaS) is growing in exponential fashion, and it enables

a small organization to get into the game with little to no admin-

istrative IT footprint. Much like we use Facebook, Pandora, and

LinkedIn in our personal lives, so too are professional software

solutions coming into the fray. Applications that are delivered in

the cloud and are paid as a subscription are enabling smaller busi-nesses to enjoy the benefits of enterprise Quality Management

solutions, without having to dedicate specific resources or signif-

icant cash flow to a single tool. Pay as you goits the way of the

future.

veryone resists change. Most often, the larger companies will be

he ones to take the first step, and sometimes the innovators in

he industry, regardless of size. Mainstream adoption often comes

when it becomes easier to make the change from one system (or no

ystem) to an automated software tool. With flexible, configurable

olutions that can be deployed in-house or over the Web, change

ecomes easier, and more and more small to mid-sized organiza-ons can enjoy the benefits of the solutions in the market today.

What are the Obvious and Not-so-ObviousBenefits to a QMS Solution?As with anything, you often find that your goals change over time.

his is also the case with an enterprise Quality Management System

QMS). Many will enter into an investment in a QMS with very specific

oalsimplement Document Control and Corrective Action, and

hen as they see more value, they see more potential in the software.

You get the core needs covered, and then as that is running

moothly you begin to look for ways to make the software work for

ou elsewhere. Thats what its forit makes your job easier. Thebvious benefits are:

Time-savings:. Lets face itmanually processes are time-

consuming. Chasing paper is not what youre in Quality for. You

need to be able to free up as much time dedicated to ensuring

the Quality and Compliance of your operation. Software can

provide that time-savings through automating processes, inte-

grating with other business systems, and fostering better visi-

bility and collaboration throughout the business.

Return on Investment:5. Theres not doubt that oftware

investment. From the small desktop solutions to the enter

systems, there is an investment to be made. The return on

investment is where the difference is made. If you can red

your Corrective Action cycle time by 50%, and youre ab

focus on the issues that matter most to organization, then yo

already seen the return. The key here is to ensure that yomaximized the software to realize that return.

Then there are the not-so-obvious benefits.

Rapid Application Development:6. As a Quality professi

youre not in the business of building applications. But to

earlier point, software these days is less developing and m

configuring. Many organizations are leveraging the workf

based platforms to extend the software to more areas o

business. Take the Environmental Health and Safety (EHS) sy

for examplemany Quality systems have similar function

that of an EHS system. If you can leverage your existing soluin Quality, and create a similar set of modules for the EHS t

youve not only doubled the power of the software to ano

operational area, but youve also created another hero mom

for you and your team. Many organizations have become a ce

of excellence due in part to their use and innovation into o

areas like EHS, HR, PLM, and Supplier Management.

Enterprise Risk Management:7. QMS solutions that incorpo

risk are unique in that the risk concept transcends Quality. Ris

company-wide issue. Youve heard the mantra, Quality is e

ones responsibility. Thats a nice statement, but often Qu

is really only the responsibility of the Quality departmVery few outside of Quality actually speak Quality, so the

a disconnect. However, everyone in the company speaks

By using risk as a benchmark, you are translating your Qu

activities into risks and opportunities that the entire com

can understand. Enterprise Risk is a function that can come

Quality and be extended to the entire organization. Along

that, a risk-based QMS can be extended to encompass the e

enterprise, thereby becoming an Enterprise Risk Managem

(ERM) solution.

Whats Your Price? Moreover, whats Yo

Price Not to go with QMS?How much to pay for an Enterprise Quality Management solu

Again, when we look at this, we have to discuss in terms of not

point, but also investment and return. How much is an autom

system worth to your organization? Typically enterprise system

not be cheap, but the key is to do your due diligence and exa

your current as-is and the potential to-be by implementi

system. Configurable systems and systems hosted in the Cloud

be offered at a reasonable price, and as these systems become m

flexible and easily deployed, you will see the price points go d



5/24

3 |



Consider the following examples of Return on Investment (ROI):

Case:. One Life Sciences consumer goods company was using

over 500 systems to manage both Quality and EHS (QEHS)

processes. This varied in range from spreadsheets to enterprise

ERP systems, across all of their global applications. Managing

500+ different sources of data left them with a disparate viewof their QEHS. They decided to make the investment in an auto-

mated solution, and thanks to the benefits listed above, theyve

reduce the 500+ systems down to a single system. Regardless of

their actual investment cost, the benefit of having a single source

of the truth has been an overwhelming return.

Case:. A Blood Services organization had a manual Quality

process that tracked their Quality Control (QC) data. Since this

was a manual process, the time it took to manage and review the

QC data was roughly 45 days to completion. Once they imple-

mented an automated system, they have since reduced this time

to less than a day for the same process. Less than a day! Theyestimate the time saved to be near 650 hours of labor. This is a

perfect example of time-savings as an ROI metric.

Scalability: Cant We All Get Along?One key area that needs to also be mentioned is scalability. We no

onger live in a single siloed world. Companies have multiple facil-

ties, each with their own unique processes relative to the corporate

tandard. Everyone operates in their own way that works for them, and

mplementing a software system should not force them to change.

QMS needs to be adaptable to the business processes for each line

f the business, but also conform to a corporate standard. So the

uestion becomes, how can we all be unique in our processes, butonform to the common corporate platform? QMSs are evolving to

ddress this issue. It used to be that for each site, a separate instance

f the software needed to be installed and maintained. If you have

0 sites, then you would need 30 systems, each with their own

dministration and workflows. No longer is this the case. Flexibility

s now extending beyond just the processes and workflows, but also

nto the locations in which processes are located. With flexibility by

ocation, you can log into the system from your site and see all the

elevant workflows, coupled with some of the corporate standard

workflows. They become one holistic workflow that can vary site to

ite, but maintain the relevant data that corporate needs to track.

o in effect, you have a global, holistic solution that can satisfy bothorporate needs and the needs of the individual sites.



6/24


7/24

5 |



Taking Quality to the EnterpriseScalability Matters:. Ulti-

mately, your QMS may not serve a single site, especially if your

organization has multiple facilities. As more and more companies

scale their systems to span the enterprise, it will become

necessary for the QMS to follow suit. When selecting a software

system, think about the long-term goals on how you plan to

scale. It may not be an immediate need, but having the ability toexpand your QMS beyond your four walls to include other facil-

ities, or even suppliers and customers, can make a difference

in the systems long-term value. Watch out for false scalability

promisessome systems will claim scalability, but have no real

experience in the matter. A scalable system must obviously be

technically capable of handling the load of additional users, but

that is only half of the picture. The scalability of administration is

equally important and can be much more expensive to fix later if

not considered up-front.

ook for customer references that have scaled the system to a level

hat is equal to your business, specifically in the ability to delegatedministration to different levels in the organization, across the

ntire enterprise. Truly scalable systems include location-based

dministration that extends beyond simply managing different user

roups, to enabling location-specific configurations and dynamic

ltering of location-specific data.

Tying Systems Together through Integration:. Operational

areas no longer live in silos when it comes to business systems.

Whether they are Production, Financial, or Quality systems, the

ability to interact, collaborate, and coordinate across the business

is key to uncovering any gaps in processes, and creates visibility

from one operational area to the next. It is of paramount impor-tance to be able to integrate your systems.

When looking to select a system, keep in mind the integration

ptions available within the solution. Avoid solutions that claim

ntegration, but will only do basic integration lookups. While this is

owerful and eliminates some degree of double-entry of data, true

ntegration will not only pull data in from production systems, but

will also push data back to those systems, such as nonconformance

ssues, overall cost of Quality activities and more.

Know Your AudienceEnd User Acceptance:. Typically, the

team selecting a software system is made up of multiple areasIT,Quality, Operations, Purchasing, and more. More often than not,

the participants are manager-level, and are making the decision

on behalf of themselves and the end users. The end users, while

most likely the highest volume user, are more than likely not

involved in the ultimate decision. Many software systems will

have the technology and process management needed, but

once implemented, the end users are lost. It doesnt look familiar;

it doesnt look and feel right, and requires significant adjustment

to get used to. Look and feel may not seem like a deal breaker

but it can be a hindrance in the learning curve for many users,

and cause delays in getting implemented and effective. M

software vendors do not come from your industry. In fact, m

come from a technology background, and never take

account the user experience. The result is a software system

is technologically advanced, but completely un-user friend

When selecting a software system, take into account the end uexperience. Make sure the software can easily be configured to

the end userwhether it is familiar forms and layouts, even co

that match the corporate look. If you are replacing an existing sys

see if you can match the new systems look and feel, even the f

layouts to the old system. This can make the transition much ea

and make the end users more productive right from the start.

Time to ValueImplementation and Deployment:8. Yo

covered your needs in terms of the solution and it has all the

and whistles your company needsnow what? The solu

needs to be implemented. This is where, many times, softw

selections fail. In fact, in a recent study of over 9,000 softimplementations, 71% of them either failed or were lat

over budget. Many of these projects cited the implementa

project as a major reason for failure. It is critically important

the software vendor be able to demonstrate their capabili

not only deliver the solution to you on time and on budget

do so in a fashion that lets you use the system as you inten

use itwith all your configurations and best practices built

Look for a solution that has a proven implementation method

involves the requirements gathering, the side-by-side collabora

with their folks and your team, and sticks to an agreed upon pr

scope. Furthermore, get your requirements finalized up froadding new features and functions mid-stream often delays pro

as more time is added to the project to meet these new last min

entries. Finally, make sure all the stakeholders in your organiza

have had their opportunity to contribute to the requirements p

This will ensure that all parties are satisfied before the implem

tation begins.

These 8 rules of engagement when selecting a software solu

(which can really be applied to any enterprise solution, not

Quality or EHS), can have a tremendous impact on how you appr

your software purchases in the future.

8 Simple Rules for Selecting a QMS SystemGetting Started on Your Journey


8/24

6 |6 |



n this day and age, very rarely do people buy anything without

oing their research. This rings true when it comes to the buying

rocess for enterprise software systems. In many ways, the buyer

as so many tools available to research vendors and understand the

ros and cons, we see a much more informed and educated enter-

rise buyer. Web-based research will give you some of the key areas

o rate a vendor on, such as:

Market expertise

Features and utilities

Broad company overview

Pricing and support structure

Breadth of applications offered

All these things can be commonly found after some basic research,

nd a few discovery demonstrations. However, we still see cases

where a company has selected a vendor, and that vendor continues

o fail on their delivery of the solution. You would think that these

ailures would be picked up on during their extensive, informed

esearch, but there is more to a company than the above bullet

oints. Below are some additional considerations to be aware of

when selecting an enterprise vendorthose that go beyond pricing,

eatures, and tools.

Implementation Track Record:. One of the primary reasons

software implementations fail is a lack of communication andproject management within the implementation team. To put it

more simply, the project scope goes over time and over budget.

Often (and especially in the Compliance software market), the

software sale draws so much focus, that the service element

becomes an afterthought. Look for a vendor that has a proven

track record of implementing their solutions successfully, and

make sure to spend some time reviewing their strategy. Proper

implementations, whether large or small, should incorporate

some element of project management that involves both

parties. The best way to find out if the implementation met

are proven is to look for proof from existing customers.

Customer Satisfaction:2. Todays enterprise software b

will no doubt ask for references. Most vendors will gladly

you towards their go-to reference or load you up with

studies. And most buyers will discuss the cursory questio

What do you like about the software, and does the softw

meet your needs, etc. When doing your reference cal

also a good practice to delve into some more intangible q

tions. Remember, enterprise software is not only an investm

in a solution; it can be an investment in the people within

company. Questions like What do you think of your acc

manager or service manager, or Do they respond to your n

at this company, or even What is their user conference like

give you a deeper insight into how this company operates. T

types of questions (which may seem silly at first) add dimen

to the vendor, and also give you an indication of the health

longevity of the company. You want to invest with a com

that will be around for as long as you continue to work

them.

Financial Well-Being:3. As stated above, you are investin

an enterprise solution and the company behind itits

cally important that you feel comfortable about the compa

financial well-being as well as their product offering. In this

and age, software companies are being bought and sold, a

companys control is sometimes in the hands of a venture c

talist rather than a software architect. In some cases, the soft

vendor is a minority shareholder in their own company. Ven

capital investment, loans and lines of credit to keep opera

goingtruth is, a software vendor may have more debt

equity. Dont hesitate to get financial information from

vendor.

Look Under the Surface:

4 Things to Ask a Compliance Software Vendor

Look Under the Surface: 4 Things to Ask a Compliance Software VendorGetting Started on Your Journey


9/24

7 |



Now many may not be apt to opening their books for you, and thats

nethere are a few ways to get an accurate financial picture:

Search the Web for Investment News:a. Vendors may not

actively promote when they are bought or invested in, but

the investors love to talk up their portfolio. Look for press

releases from investors on your vendor, and read carefullyon whether the investment firm is providing capital, or

actually purchasing the vendor.

Ask for a Debt to Equity Ratio:b. This is a great way to see

the financial health of an organization without prying

into their books. The Debt to Equity ratio will indicate

how much they owe versus how much they own. Be wary

of vendors with high ratioschances are they may be

burning more cash than they are bringing in.

Annual Growth Rate:c. Average growth percentages over

a 3-5 year period are nice, but the vendor could have

had one great year in year 1, and the next 2-4 years they

declined. Compounded Annual Growth Rate provides a

more accurate depiction of how the company has fared

financially over the past few years.

Annual Net Income Growth Rate:d. Another good metric

to asses the health of a vendor is to examine the net

income growth, which is essentially the vendors prof-

itability. They could have a decent revenue stream, but

are they profiting enough to sustain themselves? Net

income will give you an idea if the vendor can stand on

its own two feet. These are just some basic ways to under-

stand the health of the company. A healthy company that

invests money back into their product and plans for the

long-term will ultimately result in more product innova-

tions, providing you with services for years to come.

Proof of Concepts and Workshops:. If you get to a point where

two vendors are equally adept, then it might be time to suggest

a workshop or proof of concept. These are typically 1-2 day

engagements with the vendor whereby you give them a simple

set of requirements, and ask them to implement it on a small

scale. Its like a test-drive of the system on your terms and

using your processes. What makes it powerful is that you can get

a glimpse of how your future relationship with the vendor will

be, and how they work when implementing your solution. These

workshops can be time-consuming (and occasionally a pay-for

exercise), so reserve this for special circumstances.

Look Under the Surface: 4 Things to Ask a Compliance Software VendorGetting Started on Your Journey

In our world where we have all the information at our fingertip

sometimes easy to say we know everything. But there are still t

data points that are not publicly known, and getting the right ans

can make a big difference in your decision. So its important t

your research and come to the table prepared, but dont be afra

ask for more information on your enterprise software solution.


10/24

8 |8 |



n todays dynamic and demand-driven market, the need to

mplement enterprise technology to keep pace with rapidly evolving

perational, production and compliance environments is key to

uccess. In recent years, enterprise technology has become more

revalent in its penetration of all operational areas within a business.

t has become so prevalent that it is rare to find a department within

n organization that does not have a dedicated enterprise software

olution to provide some level of support.

n the case of Quality, this statement rings true. In recent years,

nterprise software solutions have become commonplace in many

rganizations, whether integrated QMS, or Quality Management

modules within larger production systems, even down to simple

oint solutions for Document Control or Corrective Action. Recent

eports on top software components for organizations show thatQuality Management is at the top of the list. In many organizations,

Quality Management solutions are a strategic priority. As demand

or these solutions grow, so does the vendor landscapemore

oftware vendors are providing solutions for Quality and Compliance

Management than ever before.

When determining the strategy for automating a mission critical

usiness process like those in QMSs, a Build versus Buy choice

emains a key decision. Overwhelmingly, organizations have proven

he decision to Buy provides much greater value and success than

he decision to Build. Here is a Top Five list of things to watch out

or in a build versus buy scenario.

Predictable and Transparent Costs:. Developing an enterprise

application is no small task, especially when it comes to esti-

mating the cost of development. When you buy a best-practice

enterprise solution, you evaluate in advance the features, func-

tions, and capabilities in an existing enterprise environment. A

known cost is attached to a best-practice solution. If you build

a new system with alternative development resources, project

costs and time to deploy may range widely, affecting the success

of the project.

n fact, according to Gartner Research Group, packaged applica-ons with best practices already built in have found favor within

many enterprises and are now considered viable choices for many

orporate tasks. In fact, corporate edicts have often been established

hat preclude even a discussion of the build versus buy process.

herefore, buying a software package with best practices already

uilt in, under all circumstances is the dominant trend.

When evaluating whether to buy or build, its critical to thoroughly

nderstand total costs during the software lifecycletypically 7 or

years.

Build vs. Buy: Best Practice QMS Solution over

Custom Development

This step is important, because 70% of software costs occur

implementation. A rigorous lifecycle analysis that realistically

mates ongoing maintenance incurred by a custom developm

project often tips the balance in favor of buying.

Flexibility and the Ability to Adapt to Change:2. Busine

experience constant and rapid changes. Companies change

processes, expand or shrink, and competition drives innova

to the market. Application developers often hear althoug

needed that a year ago, its not what we need to run our bus

today. Add in rapidly changing technology and the adapta

of a homegrown system becomes an issue, and often a sys

built in-house becomes obsolete before its complete. A

practice configured application is a production ready applica

that can be customized for a unique environment within atively short timeframe.

Furthermore, having the flexibility to adapt to changes is ke

success in response to changing market conditions. With con

rable solutions, processes can be changed as needed with litt

no additional costs. With custom developed solutions, there is

room for changeif change is required, it can result in hundre

development hours and the project overruns can be steep.

Best Practices Experience and Core Business Focus:3. W

determining an enterprise solution, it is important to con

the focus of the organization. How well do the vendors knowbusiness challenges your organization faces? How well vers

best practices is the vendor, and what is their experience in

industry? A vendor who is rooted in these best practices h

broad knowledge base of experience to draw from, where

custom development from a vendor outside of the industry

be starting from scratch on how to match your business proce

to the application. This can push the scope of the project

simply because the learning curve on processes and termino

need to be collaborated on. Selecting a vendor with a b

background on a specific industry like Quality Managem

helps to provide a foundation for building a process that m

your requirements, with a long-standing knowledge basexperience to draw from.

Consider the Project ScopeProven Implementation ve4.

New Application Development:According to a report by

Standish Group on more than thousands of software proj

40% failed completely, and an additional 33% were challeng

meaning that they completed late, went over budget, or w

completed with fewer features and functions than originally s

ified. Even more staggering, a recent study by Gartner Rese

Build vs. Buy: Best-Practice QMS Solution over Custom DevelopmentTips for Implementation Success


11/24

9 |



revealed that nearly four in ten major software purchases ended

up as shelfwaresoftware that was purchased, but never

implemented.

he root of all these challenges lies in the ability of the project to

e defined properly. With custom developed solutions, the project

cope encounters obstacles not foreseen at the outset of the project,nd it is extremely difficult to estimate the time and expense asso-

iated with a major development project. This is primarily due to

evelopment of new features not inherent within an existing appli-

ation or customer developed application, which creates a tendency

o change and modify the scope on the fly. The result, according to

he Standish Group, estimates that 52.7% of all custom application

rojects cost 189% of the original estimate provided.

oftware vendors with best practices built-in draw on a history

f implementation of similar processes, and have implemented

undreds of projects of similar focus and scope. These implemen-

ations follow a proven process, and follow a pattern of projectmanagement that delivers the product on-time and within scope.

Return on InvestmentLook for the Hidden Cost of Devel-.

opment:While many custom-built applications outline a broad

scope for a project, without having a best practice approach it is

impossible to determine how long the project will actually take.

Vendors that offer a best practice solution are able to leverage

years of implementation and product development to accurately

scope out a project and will not incur the same project overruns

custom developed solutions encounter.

Consider the breakdown on build versus buy conducted in a Standish

Group Report, illustrated in the tables at the bottom of the page.

When comparing these two scenarios, we can assign a risk rankin

build versus buy, as illustrated in the risk matrix below:

Because a best-practice configured solution requires little t

development costs and uses a proven method of implementa

to ensure projects are kept on scope, the actual risk associated implementing is considered lower than that of a custom-built a

cation. This is primarily due to the unknown factors that can o

in custom development, as well as long-term costs to update

maintain the custom-built system.

Avoid the Dangers of Buythen BuildWhen making the decision of build versus buy, its importan

determine the level of development required, in either case. W

many off the shelf software systems will claim to have the best

tices built out of the box, what is often not determined is any

of custom development that may be needed after the softwa

purchased. Often times, purchased solutions will incorpora


Comparison: Build Versus Buy


12/24

10 |



ramework of best practices within their solution, but in order to

ailor the system to meet your needs, the system must be custom

eveloped. As a result, the customer is left with a purchased solution

hat will need a custom development project added into the

urchase, creating the same challenges with a purely built solution.

ook for systems that have the flexibility to adapt to specific processes

without any need for custom development. These solutions oftennable the administrator (or Power User) to configure all aspects

f the system to meet unique business needs. Configurable systems

uch as these completely eliminate any custom development needs,

nd provide a truly flexible and adaptable system that embodies the

urpose of a purchased, best-practice solution.

he decision to implement enterprise software is not a simple task.

oftware solutions typically represent an investment of 5-7 years,

ften up to a decade for many organizations. When weighing the

ptions of determining software selection, the Build versus Buy

ecision is one that will always come up, and requires careful consid-

ration on the path to take for your investment.

While both options have merit, many organizations opt to leverage

he existing best practices implemented within the industry, the

roven track record of success and innovation, and the most flexible

echnology that will help them seek returns on their technology

olution. For many, the growing trend lies in purchasing a solution

hat provides the most functionality and features, and presents the

owest total risk to the organization.



13/24

11 |11 |



While many companies focus heavily on the softwares ability to

meet the business need, very few focus on the vendors ability to

mplement the software. The responsibility of a software implemen-

ation project is shared between the vendor and the customer. While

he vendor needs to deliver on all those promises they made in the

FP, the customer needs to make sure that their processes are well-

efined, and that all the requirements of the solution are outlined

n detail. Without the roadmap for the solution, the vendor can only

ake a best attempt at meeting the business need. Kind of like

hooting a moving target in the dark, blindfolded and with one hand

ed behind the back.

With all the investment put into selecting a software vendor for your

usiness, it is hard to believe that there is any possibility of failure.

However, recent studies have shown that within a sample set ofmore than 9,000 software rollouts, 71% either failed or were late

nd over budget. Even more staggering, a recent study by Gartner

esearch revealed that nearly four in ten major software purchases

nded up as shelfwaresoftware that was purchased, but never

mplemented. The root cause of such pitfalls is usually attributed to

hallenges associated with project management, and the inability

o properly define the requirements to make the implementation

uccessful. As a result, the end users never really accept the solution,

nd the cost to implement correctly becomes extended.

uccessful projects are the result of the Quality of the solution and

he acceptance of the solution by the end users. As seen in theiagram below, without proper planning and project definition at

he start of the project, implementation projects can often suffer in

he long-term. Projects without a defined scope will often require

uctuations in resource levels, and push the project out far beyond

ts expected completion.

Avoid Scope Creep in Enterprise Software

Implementation

Here are just some quick points to consider when looking a

implementation project:

Get the Requirements Up Front:1. While this may seem

a no-brainer, many companies wont truly know what

requirements are when they start a project. You may have

or two project managers who swear up and down they k

the processes, and do not need this exerciseuntil you act

get all the stakeholders in a room. At that point, the picture

painted a different shade of what you thought. Many times

stakeholders will trickle in during the project after implem

tation has begun, and this is the source of the evil Scope Cr

paradox. The more features we want, the more time it will

and the more time it will take, the less likely the vendor

deliver it on time.

By gathering all the stakeholders and clearly defining the projec

its requirements at the start, the actual implementation proces

move much smoother. No one is trickling in and all elements o

project are planned and ready to go. This early investment of tim

the beginning of a project may seem like it would take longer o

outset, but in reality, this up-front investment of time actually sp

up the project in the long run. Resources are efficiently mana

project timelines are met, and this project is delivered on time

on budget.

Get a Design Specification:2. Whether you are implemen

a configurable, out-of-the-box solution or a heavily cus

developed application, getting a design specification i

important step in the process. A design specification is essen

Avoid Scope Creep in Enterprise Software ImplementationTips for Implementation Success


14/24

12 |



a simple mock-up, wire frame or depiction of what the final

product is going to look like once implemented. These are typi-

cally done in phases of the implementation, so that each piece

is given its own design specification. Think of it like building a

house. You would want to see the floor plan before they start

laying the foundation, and building up the rooms. You want to

make sure the bathroom is in the right place, the kitchen, andso forth. Same goes for the software solutionmaking sure the

forms look right, the fields and keywords match your ideas, and

are in the right place are very important.

At this point, with the requirements gathered and design specifi-

ations in place and approved, then the real implementation can

egin. Whether configuration or coding, most implementations

will vary, but ultimately the goals are similar. This is to deliver the

nished product according to the information provided in the first

wo points. Ensuring the finished product matches your require-

ments exactly is important, which is covered in the next point.

UATUser Acceptance Testing:. Its important to always

include the end users in the processthey are after all, the day

to day users of the system. Their acceptance of the system will

ultimately determine whether the new solution is truly a success

or not. The UAT phase of the process is like the test drive of

the new sports carmaking sure that the seats are comfortable,

the engine is tuned, and the wheels wont fall off. Just the same

in the software worldmove around through the workflows

and forms, push the performance, and make sure the proverbial

wheels stay on. This is usually done by the companys project

team, but many like to take a few of their end users and let them

comment on the system. This is a good practice to get the wordon the street for those daily users.

he theory behind using this project management/requirements

rst approach to implementation is that during UAT, only minor

roblems are tweaked. The last thing either party wants is a major

echnical flaw this late in the game.

nvestment in software shouldnt fall victim to a poor implemen-

ation. Not only does it leave a bitter taste in the mouths of the

roject team, but the software investment becomes diluted and

ould end up as shelfware. Ensuring the project requirements are

athered at the start, the design is approved before implementingnd testing on the backend will help to make sure the project is

ompleted within scope and within budget.

Avoid Scope Creep in Enterprise Software ImplementationTips for Implementation Success


15/24

13 |13 |



veryone seeks out value. Whether youre a coupon clipper, a sale

hopper, or a garage sale stalker, people look to get some sort of

alue out of their buying experience. And if the product is purchased

t retail, you look for ways to get the most out of the product you

urchased.

he software sale is no different, and potential customers are looking

or ways to demonstrate a viable Return on Investment (ROI). Lets

ispel any misconceptions firstsoftware is not just a tool, its an

nvestment. Quality and Environmental Health and Safety (EHS)

management solutions require upfront costs, and upfront effort to

et it up and running, and the returns only come after youve put

nancial investment into the product and financial investment into

he implementation. The key is how quickly you expect to see a

eturn.

n this market, ROI needs to happen quickly. We have entered a time

when IT departments are cutting budgets and looking for ways to

onsolidate and integrate business systems. As such, IT is looking

or ways to cut systems that are draining resources, protect budgets

or larger-scale implementations, and seek out solutions that are

ow-cost alternatives. The Chief Information Officer (CIO) is looking

or ways to demonstrate immediate ROI on projects, to the tune of

eeing returns within a Quarter. This need has had an effect on the

Software Middle-Classthose systems that are high-cost with

ong timelines to ROI. You have three real scenarios in this IT solution

model:

The Too Big To Fail:. These are the long-term, high budget

projects that are simply too big to abandon or too critical to the

business to scale back. SAP is a prime examplethe solution

touches so many parts of the business, and has so much stake in

the success of IT, that it will never be scaled or abandoned.

The Software Middle-Class:. These are specialized solutions

that serve a singular need (or the needs of a few), but come at

a high-price of entry, and no definable ROI in the near future.

These are solutions that end up on the chopping block with

people looking for lower cost alternatives.

The Low Entry, High Return:. These are specialized solutions

that have carved out their niche in a particular function, and have

certain out-of-the-box qualities that make the product have a

low entry cost, but due to the configurable nature and flexibility,

can yield a faster ROI than their middle class cousins.

o, what does this mean for Quality and EHS solutions? Well, it means

hat companies are looking for more value from their systems; QMS

nd EHS solutions are expected to do more and provide more

immediate value. The CIO will look at their infrastructure and

can my too-big-to-fail systems handle the processes we need, a

not, what systems can we put in place that will integrate with t

systems and provide me with quick ROI? QMS and EHS are p

examples of systems to accomplish this goal. Heres what t

systems offer:

Workflow and Business Process Automation:1. Look f

system that has the flexible workflow to not only accomplis

task of Quality and Health and Safety, but to also provide v

in all business process initiatives. Can the system be config

to do more for the organization? Leading systems integ

PLM, SCM features into Quality, and add Sustainability to

that the software middle-class once handled; this provides a

tional value to the system and makes it a lower-cost alterna

to these middle-class systems.

Integration Capabilities:2. Again, the CIO will ask whethe

big project systems like SAP can handle the process, and

cant, then can it be integrated with these QMS and EHS syst

Look for solid and certified integration points that will enh

your too-big-to-fail systems. Leading QMS and EHS syst

offer various levels of integrationenough to fill the gaps

are necessary to round out the infrastructure.

Provide Immediate Value:3. When looking at these systems,

time to realize the ROI is critical. The nature of QMS and

systems is in their configurabilitythey are inherently bu

be configured quickly and adapt to changing processes

little to no programming or custom development. This ena

them to provide value within a short span of time, usually w

a Quarter.

ROI: Assessing Value in a Quality and EHS

Management System

ROI: Assessing Value in a Quality and EHS Management SystemTips for Implementation Success


16/24

14 |



Demonstrate Definable ROI:. This one is trickyhow do you

define ROI? Many companies look for quantifiable ROI, but often

have no baseline to compare it to. As many organizations are

not tracking ROI metrics on a particular software solution, they

seek ways to determine how much value a system like Quality

Management or EHS Management will provide. Here are just

some sample cases where ROI is provided on QMS and EHSsystems:

Time Savings:a. One area is in saving time over manual or

cumbersome processes. The nature of workflow-based

automated Quality and EHS is that it reduces the cycle

time to complete otherwise manual process. One organi-

zation had a Quality Control process that took upwards of

45 days to complete a cycle in a manual process. This was

due to diverse locations and compiling data from various

sources. Using automated solutions, the QC process was

reduced from 45 days to a single day. While not immedi-

ately quantifiable, the time savings is staggering.

Systems Consolidation:b. Creating a centralized resource

for Quality and Safety is important to demonstrate value.

Another company had a diverse portfolio of business

systems managing their processes, which would grow

over time as new divisions adopted business processes. At

its high point, they had over 700 business systems driving

processes, with various levels of complexity. Using a single,

holistic solution, they were able to reduce the number of

systems from 700 to a single system. This alone saves time

and money in maintenance, but also provides a more effi-

cient method of tracking Quality and Safety.

Administrative Overhead:c. Manual or cumbersome

processes take up resources. Whether this is in man-

hours, administration time, or physical bodies, this is time

spent on the system, rather than the business. One such

example came when an organization purchased a system

to manage Audits. The system enabled them to automat-

ically schedule audits versus manually scheduling them.

This reduction in time and overhead resulted in a resource

savings equal to 5 full-time employees. These employees

are now freed up to do work more relevant to the business,

and not on scheduling.

o, ROI is all in how you perceive value in the system. Look for a

olution that not only is able to provide value in a short period of

me, but demonstrates the value in a way that you can relate to

our organization. The above are just specific examples. You would

eed to use these as a base, but will have to determine your own

metrics based on your unique business needs. The take-away is that

OI comes in all shapes and sizes, and not only do leading QMS and

HS system provide the low-entry, high value mix, but are prime

xamples of gaining ROI in a short period of time.

ROI: Assessing Value in a Quality and EHS Management SystemTips for Implementation Success


17/24

15 |15 |



The Importance of Risk in the Complex

Quality Lifecycle

Manufacturing industries have matured over the years, customer

emand increases, and the complexity of the products also increases.

o we now have a complex product lifecycle that needs to move

aster to keep up with demandmanufacturers must keep pace

with the demand, while ensuring Quality of the product at every

tep. The faster we move, the harder it becomes to correct adverse

vents, and prevent Quality issues in the same way were used to.

We need a measure to help us search out the most critical issues and

ddress the Quality issues that matter most. Risk Management is of

rowing importance in Quality for this very reason.

ets look at some of the areas risk plays in the Quality lifecycle:

Risk in Design:. Incorporating risk in design is a critical, but

sometimes overlooked component in the Quality lifecycle. Tradi-tionally speaking, Quality has always been reactive in nature

events happen and we need to correct them. However, if we

can work towards mitigating risk during earlier stages in the

product lifecycle, such as in design, then we can mitigate the

risk of these in-field failures. Tools like Failure Modes and Effects

Analysis (FMEA) or simple Hazard Analysis provide the ability

to break down a design into core components and assess the

risk of failure. By calculating the risk before the product is even

built, you can take steps to mitigate that risk in a more proactive

way. Even for known risks, you can better prepare your team for

potential post-market events, and handle them more efficiently.

Risk in Process:. Corrective Actions are an issue in many orga-

nizations. You would think that a system designed to efficiently

correct a problem wouldnt be a problem itselfbut it can be,

especially if every event becomes a Corrective Action. Too many

Corrective Actions can shift the focus on what is most overdue,

versus what is most critical. By incorporating risk into the process

of adverse events, you can filter the critical and non-critical

events, ensuring that the highest risk events make it to the top

of the list. Less critical events can even be handled immedi-

atelyQuality systems do not specifically state that every event

become a Corrective Action. Using risk will help to streamline the

system in this fashion.

Enterprise Risk Management:. Risk mitigation is everywhere. If

you think of an umbrella, the spines that make up the umbrella

are the various risk areas (risk in design, risk in process, safety

risks, human factors, governance, etc.). The umbrella as a whole

is Enterprise Risk Management (ERM). ERM seeks to combine risk

elements from all over the organization and take action based

on those elements in broad strategic level.

In reality, ERM follows a path no different than the more gra

departmental levels:

Risk Identification:a. Simply put, look for the pote

risks. Whether at a low-level or high-level, you neefigure out where your risks arise. This can be from adv

events, hazard analysis, departmental surveys, and si

areas.

Risk Assessment:b. Once youve identified the risk,

need to determine how severe it is. Is this risk high,

or negligible? Assessment seeks to categorize (and po

tially prioritize) our risk.

Risk Review:c. New risks within an organization nee

be reviewed. Risks cannot automatically be assigne

actionoften you need a team to review the risk ran

determine the next steps, and so forth.

Risk Mitigation:d. We now ask the question, how d

fix this? Risk Mitigation relies on taking steps to co

the events, and ultimately reduce their risk to accept

levels. Corrective Actions help to create a plan for inv

gating and correcting systemic issues, and reduce th

of recurrence.

Risk Reporting:e. The last step is sometimes overloo

but critically important. Reporting not only creates

bility into top risks, but it also lets you trend out pote

areas of improvement. Reporting lets you see how

areas risks overlaps with another areas risks.

As industries move faster and product lifecycles shorten, you

to benchmark Quality not only as a corrective measure, but

proactive, preventive way. Incorporating risk into the product

cycle will help to identify, mitigate, and prevent potential risks a

the way.

You need to identify potential risks, assess the dangers, take ste

correct your path to mitigate the risk, and continue on. The fa

you go, the more risk mitigation plays into the equation.

The Importance of Risk in the Complex Quality LifecycleBest Practices for QMS Solutions


18/24

16 |16 |



Risk Assessment: Creating a Risk Matrix

n this day and age, risk is the biggest buzzword in the compliance

ndustry. Weve talked about it, you cant go anywhere without hearing

bout it, and everyones got a risk-based solution. I think the primary

eason why we focus on Risk Assessment and Risk Management, is

ecause in business, we need to quantify our actions. We can no

onger rely purely on gut instinct to execute on events, whether

Quality, Financial, Social, or similar areas. The world moves too fast,

nd one misstep can make or break your business. Risk provides the

bjective metric to help the decision-making process. But, you need

o know how to use risk.

How do you define risk? Its not as easy as you may think. Companies

pend plenty of time and money coming up with a scheme on how to

alculate risk for their organization. Risk is defined as the systematic

pplication of policies, procedures, and practices to the tasks ofnalyzing, evaluating, and controlling risk. All this really means is

hat we put tools in place to help us look for risks, assess those risks,

nd then take action on the risk. The trick here is finding the risk, isnt

t? How do we find the risk?

he components of risk usually manifest themselves in two forms:

azards or harms. Hazards represent the potential source of a harmful

vent (the cause). Harms are the resulting damages to products,

ersons, or the environment (the effect). Risk is essentially cause and

ffect on a defined scale. Its the scale in which most struggle.

Usually, when trying to quantify hazards and harms, most organi-ations look at two metrics: Severity and Frequency (or likelihood).

aking these metrics into account, we can develop a scale in which

o measure hazards and their harms. This can be numeric (scale of

-5), verbal (excellent to poor) or both. If you were to graph these

cales, you would come up with a numerical matrix, one that high-

ghts the risk zones by their multiplied number on the axis, much

ke this one below:

You can see that we have a Low-Risk or Generally Acceptable

zone, and a High-Risk or Generally Unacceptable Risk zone, but

about the middle? Theres a gray area of subjectivity here. How

companies determine this gray area?

This is not always an easy answer. Some companies have to w

the costs versus benefits on these risks, without creating a dis

portionate cost to risk (Example: spending $1M to prevent a b

is disproportionate; spending $1M to prevent a fatality is pro

tionate). Companies will carefully vet these zone, and typically a

a concept called ALARP (As Low as Reasonably Practicable). Si

put, this means that the risk is as low as we can possibly get it, o

Tolerable or Undesirablebut it isnt critical or catastrophi

then, with the ALARP in place, you have a risk matrix:

Now you can go off and start using it, right? Well...you need to

the matrixput it through real-world historical examples and

if the risk matrix comes up with the correct risk based on histo

events. You may need to tweak the matrix based on the ve

Risk Assessment: Creating a Risk MatrixBest Practices for QMS Solutions


19/24

17 |



rocess. Hard mathematics will not properly assess the risk without

little real-world honing. Once youve fine-tuned the matrix, you can

tart utilizing it in your Compliance system.

isk Assessments and risk matrices are wonderful tools to help guide

ecision-making in an organization, but they are not meant to be

tand-alone tools. They help to provide a guide for Risk Assessment,sing quantitative and repeatable metrics to ensure a consistent

method of determining risk. Most best-in-class organizations will

ssemble a risk team to go over adverse events and determine the

sk. Its up to the team to decide how an event will be handled, and

what the true risk is. Risk matrices are the keys to unlocking quan-

tative risk-based processes, but the people are the drivers of the

ystem.

he next question becomes, How do I incorporate Risk into my

Quality Management System? More specifically, how can Risk ease

he bottlenecks in an organizations Corrective Action process?

oo often, when adverse events enter an organizations Quality

ystem, people are quick to open up a Corrective and Preventive

Action (CAPA). No matter what the adverse event, its severity or

mpact, a CAPA is opened up. Having a CAPA system in place is an

xtremely valuable (and essential) part of a good QMS. However,

f everything becomes a CAPA, then you create a bottleneck.

mployees are so focused on working on their CAPAs, they forget to

o anything else.

What you end up with is thishundreds of CAPAs, without really

nowing which CAPAs are critical to the business and which have

ess impact. It becomes the needle in the haystack conundrum

nding the critical adverse events can prove difficult if you dont

ave a way of finding them. I once asked a Quality Manager how he

andles CAPAswhat his metric was. We handle the most overdue

rst, was his reply, and he went on to say that if it isnt critical and is

t the bottom of the pile, then they dont get to it in time. That said,

here is a better way.

Risk Assessment: Creating a Risk MatrixBest Practices for QMS Solutions

Not every event needs to be a CAPA:1. Yes, its trueif you

immediately correct an event, then correct it. Not every e

needs to be opened up as a Corrective Action, only those tha

systemic issues and pose a critical impact on the business.

Use Risk to filter events:2. So if not every event needs to

CAPA, then how do we figure out the bad the from not-so-You need a way to filter these events, and you need to do i

repeatable, systematic method. Risk Assessment is a great

to do this. Risk matrices will help your team make the dete

nation as to the criticality of an event. The higher the risk

more likely we would like to take Corrective Action.

Do a CAPA on your CAPA System:3. Sometimes even a g

CAPA process needs a little updating. Make sure to contin

audit the CAPA process, and if the process is not efficient eno

then it may be time to do a CAPA to correct any potential bo

necks or problems within. Like any good process, a little ma

nance and trimming is always healthy.

Use Risk to Ensure Effectiveness:4. For an action to be

corrective to the process, it must be effective, otherwise yo

back to square one. Much like risk can be used to filter adv

events, risk can also be used to ensure effectiveness of a C

Risk helps to ensure that not only is the CAPA effective

its within the risk limits of your organizations compli

standards.

CAPA is an effective and essential tool but, like many processes

be blocked up if you are too reactive to events.


20/24

18 |18 |



Three Keys to Global Harmonization in Quality:

Learning to Share

Three Keys to Global Harmonization in Quality: Learning to ShareBest Practices for QMS Solutions

ach site within the organization, operating under their own QMS,

re happy to have their specific processes just the way they like

hem. Then someone comes along and says, were going to stan-

ardize on a single platform. There are inherent challenges to

armonizing a solution, especially Quality Management. However,

with the right tools, harmonization can actually enable a single stan-

ardized environment, while at the same time sustaining each sites

nique business processes. Below are a few key considerations when

armonizing your QMS:

Ask, How can we all be Common, but Keep our Processes.

and Data Unique?:Perhaps the biggest challenge leading into

a harmonization/standardization initiative is convincing the site-

level managers to adopt the system. Many times, each site will

want to keep their specific processes in fear that a harmonization

may compromise their unique way of doing business. When

harmonizing a system, traditional methods would warrant that

all sites need to adopt the corporate standard, and fit into the

mold that is set in front of them. With todays advances in tech-

nology, its now possible to be common on a corporate level,

while maintaining the unique processes associated with each

site. The key lies in the technology.

The Technology Platform Needs to Support Harmonization:.

Technology is constantly evolving, and each new advancement

brings business systems closer together. For harmonization

projects to be successful, the software solution needs to be

flexible enough to adapt to the concept of having multiple

processes operating on a corporate standard. Leading edge QMS

Solutions are able to have site-level processes layered on top of a

corporate backboneeach site is able to retain the specific data

points that are pertinent to them, while keeping in line with the

standardized, corporate process. This allows the enterprise to be

common and unique at the same time.

Get a Strong Project Team to Work Out the Details:3. T

nology is only as effective as the team that is implementin

Harmonization, by definition, is a group operating in the s

directionthe team must be able to work together to ge

business requirements to building a standardized solu

This involves looking at the stakeholders of the system (a

corporate level and the site level), the inputs required acros

enterprise, the processes that govern the system, the de

outputs that the team expects to see, and how the results w

measured and managed. This methodology will spit out a s

requirements which, if done properly, will create a framewo

a harmonized system. But each team member must contriand commit to the cause. When starting the journey tow

harmonization, there will be bumps along the way. No

processes will fit together, and there will need to be com

mises. It is important that the project team stay focused on

ultimate goalthe stronger the team, the better the end r

will be.

A strong team builds innovation and the technology drives it

combination of these two elements will then answer the ques

how can we all be common, but keep our processes and

unique?


21/24

19 |19 |



Is Quality Dying a Slow Death, or Evolving Beyond

Defnition?

Is Quality Dying a Slow Death, or Evolving Beyond Definition?Final Thoughts: Fun Takes on QMS Software

s Quality as we know it a dying concept, or is it evolving?

here are those who crave the old days of Deming and Juran, and

hose who see their multiple Quality certifications as a badge of

onor, and those who will define them as a Quality practitioner.

hese are the folks who hold on dearly to the concept that Qualitys reserved for the few practitioners who are meant to police the

Quality operationsa single point of contact for all of Quality.

hese are those who fear Quality is dying.

here are those in this market who recognize we are in a world of

hange, and Quality is no longer defined within the narrow box

we have always placed it in. These are the people who believe that

Quality is undergoing an evolution, one that will not eliminate the

oncept of Quality, but expand it to the enterprise.

n this evolutionary model, what is the view of Quality? Well, Quality

means different things to many people. In fact, Quality can beonsidered such a broad scope, that it may defy definition. However,

he challenge is that Quality is defined differently throughout the

nterprise, and the key to recognizing what Quality is depends on

who is defining it. Here are some of the segmentation of who Quality

ouches in the enterprise:

In the Box Quality:. QC, QA and the like are what you would

call in the box Quality. Simply put, its the folks who have

Quality in their title, and live and breathe the practices that have

been perfected over 60 years.

The Quality Involved:.

There are many areas within the organi-zation that dont consider themselves to be Quality professionals,

but whether they like it or not, they are involved in Quality in

some way or form. I am speaking of those disciplines, that while

not directly related to Quality, utilize the Quality methods and

processes that exist in their Quality department. These are:

EHS:a. Processes and practices in EHS have incredible simi-

larities to Quality. Simply looking at the ISO standards for

Environmental and Health and Safety will demonstrate

how similar ISO 9000 aligns.

Corporate Social Responsibility:b. Whether Hu

Resources, or social responsibility, the concept

improvement, controls, and processes are touc

Quality.

Product Design and Development:c. Tell an Enghes a part of Quality, and he may look at you funny

Quality by Design is a key component of improving ov

product Quality, and they are Quality users as well.

Governance, Risk, Compliance:d. Methods in this se

are continually borrowing from Quality, and while

terms may change, the goals are similar.

Other Processes:e. IT, Supply Chain and more areas a

Quality involved.

The Consumers of Quality:3. Quality is not just in practice. T

are many in the organization that consume the results of Quand use Quality data to make decisions. C-Levels within an o

nization are a perfect example. While not considered a pa

the Quality machine, improving overall Quality as it affects

bottom line is of critical importance. Without consuming

critical Quality related data from the above areas, decision

made much more difficult.

So, what is the future of Quality? Well, it needs to expand the v

to encompass these groups and escape the narrow definitio

the past. We need to be able to incorporate the Quality prac

and translate them into the vernacular of these involved areas,

demonstrate that Quality goes beyond a single department. Quis everyones problem, and by creating a holistic vision of Qualit

areas begin to converge and recognize their role in Quality.

This recognition is the first step to the evolution of Quality, ta

the concept to new heights and shaping the future of how orga

tions view Quality.


22/24

20 |20 |



What Star Wars Can Learn from Quality

Management Software

What Star Wars Can Learn from Quality Management SoftwareFinal Thoughts: Fun Takes on QMS Software

What if The Empire had implemented a QMS on the Death Star?

Heres what would have helped The Empire in their endeavor to rule

he galaxy if they only had put Quality Management as a strategic

nitiative.

Project Management: From the time that the Death Star plan

was conceived, it took The Empire almost 20 years to complete it.

A project this large requires multiple roles involved and delegation

f activities. The Death Star project management team consistedf three key peopleGrand Moff Tarkin, Darth Vader, and Emperor

alpatine. These are not the more flexible managers, and are not

bove taking employee errors or missed deadlines with the aid of a

ghtsaber, force lightning or a death ray.

erhaps if The Empire implemented a Quality-based Project

Management System, they would be able to clearly define the roles

nvolved in the project, assign tasks to those roles, and manage the

roject from an aggregate level. Workflows keep the project deliver-

bles on track, and perhaps this level of visibility would enable them

o maintain control, without having to resort to the Dark Side as their

nly means of clairvoyance.

Document Management:. Lets be honesteven The Empire

couldve used a strong Document Management System.

Given the sheer size of the Death Star with the thousands of

employees that worked there, there would have been tens

of thousands of records that would need to be controlled

work instructions, job descriptions, procedures, floor plans, and

the like. You would think that with this technological terror

The Empire constructed, there would be a secure Document

Management System in place.

Then how did a small droid like R2-D2 plug into

network and download the Death Star plans like it

a space walk in the park? My guess is that The Empi

all its glory, was using a file system to store docum

If The Empire would have used a Document Co

system like those in a QMS, access to these sp

cally sensitive documents would have been limite

those who had the proper access rights. Furtherm

document control can limit the details of certain f

within the data, so that no sensitive data is accesse

Employee Training System:2. Without pr

employee training, then many organizations run

risk of Quality incidents, Safety incidents, and o

risks to the business. It appears to me that The Emwas not tracking training in a centralized system. If

were, then they would have been able to see that n

80% of the Stormtroopers in The Empire couldnt

target with a blaster if their lives depended on it (and it often

Or maybe they would have uncovered the fact that their p

procedures clearly missed security breachesLike 80 yea

Jedis skulking around the tractor beam. Proper training sys

enable managers to see visibility into not only who is trained

also how well they are trained and whether actions need t

taken to update training records for poor performance.

Supplier Management and Supplier Rating:3. Lets face itEmpire had to have contracted out to build this Death Sta

the components that go into building a finished product re

suppliers and contractors to help complete the process. W

watching the movie, we know that the Rebels found a weak

in the design of the Death Star (thanks to the weak Docum

Management System). If The Empire would have had a real-

inspection and rating system, they would have been ab

inspect that access port, and send out a Corrective Action to

knuckleheads who thought putting a direct access to the D

Star core was a good idea.

Nonconformance, Audits and Corrective and Preven4.Action: Lets stay on this, then. Obviously, we know that

Death Star had a defect. It was only in the final hour did

Empire realize the danger, and by that point it was too la

they had a Quality system in place, they would have found

flaw, whether through regular space Audits (or at the very

an Audit through tremors in the Force), or a Nonconform

when the defect was installed, and issued a Corrective Actio

fix the problem. Clearly, Quality took a backseat to their over

fidence, and ultimately resulting in, wellyou know the res


23/24

21 |



Management Review and Reporting:. As I said before, the

primary project managers used fear as their primary moti-

vator, and seldom relied on the data to help them with Quality.

In the movie, you see the officers of the Death Star sitting in a

conference room, and not one of them produced a reportif

they had a robust reporting system that collected Quality data

from all areas of the Death Star, and rolled this data up to helpdetermine the top risks and top Quality issues, then maybe that

meeting would have gone differently. Perhaps if that poor guy

had shown Darth Vader his latest Quality Report, he wouldnt

have gotten the old force choke from the Dark Lord of The Sith.

Having a top-level reporting system that presents the Quality

system challenges in a single view might have mitigated their

risks.

Risk Assessment:. I think that perhaps The Empire took many

risks when going about this whole Death Star thing. Did Tarkin

assess the risk of testing the Death Star on Leias home world?

Did Darth Vader assess the risk of letting the Rebels escape withthe Death Star plans? Did they assess the risk when they under-

estimated the rebels chances of destroying the Death Star? In

any system, its important to incorporate risk into the processes,

whether Quality or similar system. If The Empire would have

What Star Wars Can Learn from Quality Management SoftwareFinal Thoughts: Fun Takes on QMS Software

perhaps weighed the severity and likelihood of the risks a

ciated with their actions, perhaps we would have seen a diffe

outcome of the story. Risk Assessment, especially in a QMS, al

managers to filter out critical events, and make better decis

on how to handle them, and then ultimately mitigate the ri

recurrence.

Of course, we know that if The Empire followed these rules of Qu

Management, we wouldnt have had the story that makes Star

so great. But it is sometimes fun to imagine, What if? and

how life would have been if instead of Darth Vader, we had D

Deming.


24/24

www.etq.com

[email protected]

800.354.4476

516.293.0949

Documents

Essential Guide to QMS