Selecting, Implementing, and Using QMS Software Solutions · 2016-05-26 · software solutions have...

Selecting, Implementing,

and Using QMS Software

Solutions

THE QMS GUIDEBOOK

Table of Contents

Introduction: Why do We Need QMS?

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

Getting Started on Your Journey

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

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

Tips for Implementation Success

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

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

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

Best Practices for QMS Solutions

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

Risk Assessment: Creating a Risk Matrix . . . . . . . . . . . . . . . 18

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

Final Thoughts: Fun Takes on QMS Software

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

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

www .etq .com • 800 .354 .4476 • info@etq .com

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

3 |3 | Getting on the Quality Management Software SoapboxIntroduction: Why do We Need QMS?

www.etq.com • 800.354.4476 • [email protected]


Is The Quality Management Software Market Evolving to be Easier, or More Complex?As the world market evolves, product lifecycles are speeding up to accommodate market demand and keep up with competing products . As a result, Quality benchmarks need to evolve as well . Risk is fast becoming the benchmark for assessing Quality throughout an organization . This is because organizations need a systematic and objective way of looking at incoming information and making decisions on how best to manage Quality . Risk Management provides this benchmark—it allows for a quantitative method to review the data and come up with decision criteria to help make better decisions leading to better Quality . In this day and age, companies cannot afford to lag on their Quality—product lifecycles are moving too fast and companies cannot keep up . Risk has evolved over the years to be more quantitative in nature and is incorporated into traditional Quality models in order to keep up with the pace of the new markets . This evolution is seen in adopting risk matrices incorporated into multiple facets of the Quality dynamic; Complaints, Audits, Nonconformances, Corrective Actions, and similar functions all use Risk in some form or another . This is growing in interest to the point in which risk activities often govern the processes and are fully integrated in the traditional workflows .

Whereas this was once a discipline reserved for only the leading edge companies, is now becoming mainstream . Most software solutions have some element of risk built in, and as more risk solutions are offered, more companies adopt the risk methodologies . This mainstream adoption is going on now and soon it will be hard to find a company that doesn’t have some sort of risk built into their system . The bottom line is that Risk Management is getting easier to access for all organizations;

but it is still a complex dynamic . Each company will need to determine which risk model best fits their business needs . The trick is to find a solution that is flexible enough to provide the level of detail needed for risk activities, but make it easy for each company to adapt and grow their Risk Management program .

What You Didn’t Know, or Were Afraid to AskThe main obstacle to truly being risk-based is the shift in changing your understanding of Quality and risk . It’s sometimes difficult to understand what is “critical” in a business, and therefore overuse Corrective Actions . Many feel it’s better to just initiate the Corrective Action and deal with the process than truly assess whether you even need it . Not every adverse events needs to be a Corrective Action; this dilutes the purpose of the process . Corrective Actions are designed to correct critical and/or systemic issues . Risk Assessment and Risk Management are designed to help discern which is critical and which is not critical . Non-critical events can be immediately corrected; however, many businesses do not see the value of correcting non-critical events in the source data in which they are found .

Especially in regulated industries where the scrutiny is so high, we often want to err on the side of caution and do a full-blown investigation on a minor event, such as a label smudge . While this is an important correction, it’s not critical and wastes resources and time for a business . First and foremost, organizations need to realize where their critical events lie, focus on those first, then worry about the non-critical areas as they come . Risk Management provides this ability to filter out the critical events and make the right decisions on how to handle them .

Why Companies are Still Reluctant to Purchase a QMSSoftware is a key component in today’s industries . Again, industries are moving faster and much like the automated assembly line, so too must the business processes that govern manufacturing be automated . So why are people so hesitant to implement software? Here are a few potential reasons:

1. The Fallacy of the Custom Solution: Most people remember the days of the custom-developed solution, where in order to get the software to work the way you want it to, you need a team of developers over the period of a year or more to code the system into your company’s “mold .” While the stigma remains, the software has evolved beyond this . Especially in business process automation (such as Quality), the custom solution is gone, giving way to the “configured” solution . Adaptations and changes to the system are all encased in settings and drag and drop interfaces, making the configuration of the system as easy as changing your Facebook settings . Now the business user, not a developer,

Getting on the Quality Management Software Soapbox




is adapting the system to meet the business need; this is extremely powerful and time-saving on resources, but is also putting the software design in the hands of the people who actually use the tools . Very powerful, and organizations are slowly warming up to this concept .

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 organization’s needs, and so companies can now get into a decent enterprise software product for a fraction of the cost 10, even 5 years ago .

3. The Fallacy of the In-House Maintenance: Another issue that comes up with many smaller businesses is a small IT footprint . 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 administrative 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 businesses to enjoy the benefits of enterprise Quality Management solutions, without having to dedicate specific resources or significant cash flow to a single tool . Pay as you go—it’s the way of the future .

Everyone resists change . Most often, the larger companies will be the ones to take the first step, and sometimes the innovators in the industry, regardless of size . Mainstream adoption often comes when it becomes easier to make the change from one system (or no system) to an automated software tool . With flexible, configurable solutions that can be deployed in-house or over the Web, change becomes easier, and more and more small to mid-sized organizations can enjoy the benefits of the solutions in the market today .

What are the Obvious and Not-so-Obvious Benefits to a QMS Solution?As with anything, you often find that your goals change over time . This is also the case with an enterprise Quality Management System (QMS) . Many will enter into an investment in a QMS with very specific goals—“implement Document Control and Corrective Action,” and then as they see more value, they see more potential in the software . You get the “core” needs covered, and then as that is running smoothly you begin to look for ways to make the software work for you elsewhere . That’s what it’s for—it makes your job easier . The obvious benefits are:

1. Time-savings: Let’s face it—manually processes are time-consuming . Chasing paper is not what you’re 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, integrating with other business systems, and fostering better visibility and collaboration throughout the business .

2. Return on Investment: There’s not doubt that oftware is an investment . From the small desktop solutions to the enterprise systems, there is an investment to be made . The return on that investment is where the difference is made . If you can reduce your Corrective Action cycle time by 50%, and you’re able to focus on the issues that matter most to organization, then you’ve already seen the return . The key here is to ensure that you’ve maximized the software to realize that return .

Then there are the not-so-obvious benefits .

1. Rapid Application Development: As a Quality professional, you’re not in the business of building applications . But to the earlier point, software these days is less developing and more configuring . Many organizations are leveraging the workflow-based platforms to extend the software to more areas of the business . Take the Environmental Health and Safety (EHS) system for example—many Quality systems have similar functions to that of an EHS system . If you can leverage your existing solution in Quality, and create a similar set of modules for the EHS team, you’ve not only doubled the power of the software to another operational area, but you’ve also created another “hero moment” for you and your team . Many organizations have become a center of excellence due in part to their use and innovation into other areas like EHS, HR, PLM, and Supplier Management .

2. Enterprise Risk Management: QMS solutions that incorporate risk are unique in that the risk concept transcends Quality . Risk is a company-wide issue . You’ve heard the mantra, “Quality is everyone’s responsibility .” That’s a nice statement, but often Quality is really only the “responsibility” of the Quality department . Very few outside of Quality actually “speak” Quality, so there is a disconnect . However, everyone in the company speaks risk . By using risk as a benchmark, you are translating your Quality activities into risks and opportunities that the entire company can understand . Enterprise Risk is a function that can come from Quality and be extended to the entire organization . Along with that, a risk-based QMS can be extended to encompass the entire enterprise, thereby becoming an Enterprise Risk Management (ERM) solution .

What’s Your Price? Moreover, what’s Your Price Not to go with QMS?How much to pay for an Enterprise Quality Management solution? Again, when we look at this, we have to discuss in terms of not price point, but also investment and return . How much




is an automated system worth to your organization? Typically enterprise systems will not be cheap, but the key is to do your due diligence and examine your current “as-is” and the potential “to-be” by implementing a system . Configurable systems and systems hosted in the Cloud will be offered at a reasonable price, and as these systems become more flexible and easily deployed, you will see the price points go down . Consider the following examples of Return on Investment (ROI):

1. 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 view of their QEHS . They decided to make the investment in an automated solution, and thanks to the benefits listed above, they’ve 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 .

2. 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 implemented an automated system, they have since reduced this time to less than a day for the same process . Less than a day! They estimate the time saved to be near 650 hours of labor . This is a perfect example of time-savings as an ROI metric .

Scalability: Can’t We All Get Along?One key area that needs to also be mentioned is scalability . We no longer live in a single siloed world . Companies have multiple facilities, each with their own unique processes relative to the corporate standard . Everyone operates in their own way that works for them, and implementing a software system should not force them to change . QMS needs to be adaptable to the business processes for each line of the business, but also conform to a corporate standard . So the question becomes, “how can we all be unique in our processes, but conform to the common corporate platform?” QMSs are evolving to address this issue . It used to be that for each site, a separate instance of the software needed to be installed and maintained . If you have 30 sites, then you would need 30 systems, each with their own administration and workflows . No longer is this the case . Flexibility is now extending beyond just the processes and workflows, but also into the locations in which processes are located . With flexibility by location, you can log into the system from your site and see all the relevant workflows, coupled with some of the corporate standard workflows . They become one holistic workflow that can vary site to site, but maintain the relevant data that corporate needs to track . So in effect, you have a global, holistic solution that can satisfy both corporate needs and the needs of the individual sites .

6 |6 | 8 Simple Rules for Selecting a Quality Management Software SystemGetting Started on Your Journey



In a market where high-demand causes organizations to seek software systems that will fit into their complex business infrastructure, the pressure to find the right system often causes angst to many . Coupled with the host of options out there, the pressure builds . Often, organizations will “settle” on a system that has most of the functionality they need, but doesn’t provide everything they want . That being said, here are “8 Simple Rules” on what to look for in a QMS .

1. Flexibility to Adapt to Business Processes: Probably the most important consideration is the ability of the system to adapt to your existing business processes, and be flexible enough to change and improve as your processes change and improve . This may seem like a simple statement, but many times software vendors build their systems around a generic, best-practice approach that cannot be changed without substantial time and cost . These vendors want you to adapt your processes to their software, not the other way around . If your company has spent years developing and fine-tuning business processes, and upon purchasing a software system, you find yourself reengineering your proven processes to fit within the software system’s limitations, you have compromised your efficiency.

Do not compromise—find a solution that is truly flexible and configurable, and can configure all aspects of the software, including workflows, forms, fields, reports, business rules, even the look and feel . Configuration should also be easy for non-technical administrators . Graphical tools such as drag-and-drop will enable administrators to own the configurations of the system with limited to no programming knowledge required . In many cases, the cost of changing your operations as a result of an inflexible software package outweighs the cost of the package itself. Careful and thoughtful attention to the software’s flexibility is key to a successful implementation .

2. Web-based versus Web-enabled: The Internet has made the world much smaller . Organizations are building intranets and extranets into their global network, and the need to have systems in place that not only utilize the Internet but also thrive on it is key to success . Following this lead, enterprise software vendors are building tools that move away from the old client-server models to a thin-client interface, allowing for more flexibility in a global environment . There are software vendors that are Web-based and some that are “Web-enabled .” Knowing the difference between the two can provide a key differentiator in your selection of the system .

3. Look and Feel—Making the System Your Own: One of the more overlooked issues when selecting the software is the ability to “brand” the system with your

organization’s look and feel . While many ask whether the system can be configured to meet their changing needs, the ability to change the colors, logos, fonts, and general layout of the navigators, forms and reports is usually an afterthought . Many systems will offer some level of configurability, but this will usually not extend to the layouts themselves . End users must contend with the vendor’s look-and-feel, which will be foreign to them . The ability to control all aspects of the software’s user interface helps user-acceptance of the software, and user buy-in is one of the major contributors to a software implementation’s success . In the age of Web-based applications, vendors can demonstrate flexibility by complying with Web user interface standards . Furthermore, they should be able to provide this control without the need to customize the software . When selecting a system, have a well-defined set of user interface requirements that will make the system work for you, and ensure that the system is able to meet those requirements without having to do extensive development .

4. Making Sense of the Data—Reporting and Searching: When you automate using QMS, there is an enormous amount of data created . Without some means of easily accessing the data, the QMS makes it extremely difficult to derive trends and insights on the Quality system . Users are left to their own devices to manually filter out the data, or even export the results into an external system for reporting . This is a time-consuming effort, and can lead to time management issues in finding the data, filtering the data and reporting on the data . Software systems will often offer some means of search capabilities, but this comes in many ways and may require administrative intervention . Having search capabilities is often not enough—the system should be able to search not only at the highest level, but also search on multiple criteria and search within records, or even within attachments embedded in records . At the same time, reporting on the data comes in many flavors . Many software vendors consider reporting an afterthought in the development of their products—usually partnering with third party tools to help make sense of the data, but with only limited integration between the two systems . Others will embed reporting tools directly into their product—providing a more integrated method of pulling data across records within the system . When selecting a software solution, determine the types of searches and types of reports you need to generate, and require that the vendor is able to create such searches and generate the reports you need .

5. Taking Quality to the Enterprise—Scalability Matters: Ultimately, your QMS may not serve a single site, especially if your organization has multiple facilities . As

8 Simple Rules for Selecting a QualityManagement Software System

7 |7 | 8 Simple Rules for Selecting a Quality Management Software SystemGetting Started on Your Journey



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 to expand your QMS beyond your four walls to include other facilities, or even suppliers and customers, can make a difference in the system’s long-term value . Watch out for false scalability promises—some 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 .

Look for customer references that have scaled the system to a level that is equal to your business, specifically in the ability to delegate administration to different levels in the organization, across the entire enterprise . Truly scalable systems include location-based administration that extends beyond simply managing different user groups, to enabling location-specific configurations and dynamic filtering of location-specific data.

6. 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 importance to be able to integrate your systems .

When looking to select a system, keep in mind the integration options available within the solution . Avoid solutions that claim integration, but will only do basic integration “lookups .” While this is powerful and eliminates some degree of double-entry of data, true integration will not only pull data in from production systems, but will also push data back to those systems, such as nonconformance issues, overall cost of Quality activities and more .

7. Know Your Audience—End User Acceptance: Typically, the team selecting a software system is made up of multiple areas—IT, 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 doesn’t look familiar; it doesn’t 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 . Many software vendors do not come from your industry . In fact,

many come from a technology background, and never take into account the user experience . The result is a software system that is technologically advanced, but completely “un-user friendly .”

When selecting a software system, take into account the end user’s experience . Make sure the software can easily be configured to help the end user—whether it is familiar forms and layouts, even colors that match the corporate look . If you are replacing an existing system, see if you can match the new system’s look and feel, even the form layouts to the old system . This can make the transition much easier, and make the end users more productive right from the start .

8. Time to Value—Implementation and Deployment: You’ve covered your needs in terms of the solution and it has all the bells and whistles your company needs—now what? The solution needs to be implemented . This is where, many times, software selections fail . In fact, in a recent study of over 9,000 software implementations, 71% of them either failed or were late or over budget . Many of these projects cited the implementation project as a major reason for failure . It is critically important that the software vendor be able to demonstrate their capability to not only deliver the solution to you on time and on budget, but do so in a fashion that lets you use the system as you intend to use it—with all your configurations and best practices built in .

Look for a solution that has a proven implementation method that involves the requirements gathering, the side-by-side collaboration with their folks and your team, and sticks to an agreed upon project scope . Furthermore, get your requirements finalized up front—adding new features and functions mid-stream often delays projects as more time is added to the project to meet these new “last minute” entries . Finally, make sure all the stakeholders in your organization have had their opportunity to contribute to the requirements phase . This will ensure that all parties are satisfied before the implementation begins .

These 8 rules of engagement when selecting a software solution (which can really be applied to any enterprise solution, not just Quality or EHS), can have a tremendous impact on how you approach your software purchases in the future .

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



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

In this day and age, very rarely do people buy anything without doing their research . This rings true when it comes to the buying process for enterprise software systems . In many ways, the buyer has so many tools available to research vendors and understand the pros and cons, we see a much more informed and educated enterprise buyer . Web-based research will give you some of the key areas to 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, and a few discovery demonstrations . However, we still see cases where a company has selected a vendor, and that vendor continues to fail on their delivery of the solution . You would think that these failures would be picked up on during their extensive, informed research, but there is more to a company than the above bullet points . Below are some additional considerations to be aware of when selecting an enterprise vendor—those that go beyond pricing, features, and tools .

1. Implementation Track Record: One of the primary reasons software implementations fail is a lack of communication and project 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 methods are “proven” is to look for proof from existing customers .

2. Customer Satisfaction: Today’s enterprise software buyer will no doubt ask for references . Most vendors will gladly turn you towards their go-to reference or load you up with case studies . And most buyers will discuss the cursory questions—“What do you like about the software,” and “does the software meet your needs,” etc . When doing your reference call, it’s also a good practice to delve into some more intangible questions . Remember, enterprise software is not only an investment in a solution; it can be an investment in the people within the company . Questions like “What do you think of your account manager or service manager,” or “Do they respond to your needs at this company,” or even“ What is their user conference like” will give you a deeper insight into how this company operates . These types of questions (which may seem silly at first) add dimension to the vendor, and also give you an indication of the health and longevity of the company . You want to invest with a company that will be around for as long as you continue to work with them .

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



3. Financial Well-Being: As stated above, you are investing in an enterprise solution and the company behind it—it’s critically important that you feel comfortable about the company’s financial well-being as well as their product offering . In this day and age, software companies are being bought and sold, and a company’s control is sometimes in the hands of a venture capitalist rather than a software architect . In some cases, the software vendor is a minority shareholder in their own company . Venture capital investment, loans and lines of credit to keep operations going—truth is, a software vendor may have more debt than equity . Don’t hesitate to get financial information from the vendor .

Now many may not be apt to opening their books for you, and that’s fine—there are a few ways to get an accurate financial picture:

a. Search the Web for Investment News: 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 carefully on whether the investment firm is providing capital, or actually purchasing the vendor .

b. Ask for a Debt to Equity Ratio: 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 ratios—chances are they may be burning more cash than they are bringing in .

c. Annual Growth Rate: 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 .

d. Annual Net Income Growth Rate: Another good metric to asses the health of a vendor is to examine the net income growth, which is essentially the vendor’s profitability . 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 understand 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 innovations, providing you with services for years to come .

4. 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 . It’s 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 .

In our world where we have all the information at our fingertips, it’s sometimes easy to say we know everything . But there are still those data points that are not publicly known, and getting the right answers can make a big difference in your decision . So it’s important to do your research and come to the table prepared, but don’t be afraid to ask for more information on your enterprise software solution .

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



Build vs. Buy: Best-Practice QMS Solution over Custom DevelopmentIn today’s dynamic and demand-driven market, the need to implement enterprise technology to keep pace with rapidly evolving operational, production and compliance environments is key to success . In recent years, enterprise technology has become more prevalent in its penetration of all operational areas within a business . It has become so prevalent that it is rare to find a department within an organization that does not have a dedicated enterprise software solution to provide some level of support .

In the case of Quality, this statement rings true . In recent years, enterprise software solutions have become commonplace in many organizations, whether integrated QMS, or Quality Management modules within larger production systems, even down to simple point solutions for Document Control or Corrective Action . Recent reports on top software components for organizations show that Quality Management is at the top of the list . In many organizations, Quality Management solutions are a strategic priority . As demand for these solutions grow, so does the vendor landscape—more software vendors are providing solutions for Quality and Compliance Management than ever before .

When determining the strategy for automating a mission critical business process like those in QMSs, a “Build versus Buy” choice remains a key decision . Overwhelmingly, organizations have proven the decision to “Buy” provides much greater value and success than the decision to “Build .” Here is a “Top Five” list of things to watch out for in a build versus buy scenario .

1. Predictable and Transparent Costs: Developing an enterprise application is no small task, especially when it comes to estimating the cost of development . When you buy a best-practice enterprise solution, you evaluate in advance the features, functions, 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 .

In fact, according to Gartner Research Group, packaged applications with best practices already built in have found favor within many enterprises and are now considered viable choices for many corporate tasks . In fact, corporate edicts have often been established that preclude even a discussion of the build versus buy process . Therefore, buying a software package with best practices already built in, under all circumstances is the dominant trend .

When evaluating whether to buy or build, it’s critical to thoroughly understand total costs during the software lifecycle—typically 7 or 8 years .

This step is important, because 70% of software costs occur after implementation . A rigorous lifecycle analysis that realistically estimates ongoing maintenance incurred by a custom development project often tips the balance in favor of buying .

2. Flexibility and the Ability to Adapt to Change: Businesses experience constant and rapid changes . Companies change their processes, expand or shrink, and competition drives innovation to the market . Application developers often hear “although we needed that a year ago, it’s not what we need to run our business today .” Add in rapidly changing technology and the adaptability of a homegrown system becomes an issue, and often a system built in-house becomes obsolete before it’s complete . A best practice configured application is a production ready application that can be customized for a unique environment within a relatively short timeframe .

Furthermore, having the flexibility to adapt to changes is key to success in response to changing market conditions . With configurable solutions, processes can be changed as needed with little to no additional costs . With custom developed solutions, there is little room for change—if change is required, it can result in hundreds of development hours and the project overruns can be steep .

3. Best Practices Experience and Core Business Focus: When determining an enterprise solution, it is important to consider the focus of the organization . How well do the vendors know the business challenges your organization faces? How well versed in best practices is the vendor, and what is their experience in the industry? A vendor who is rooted in these best practices has a broad knowledge base of experience to draw from, whereas a custom development from a vendor outside of the industry will be starting from scratch on how to match your business processes to the application . This can push the scope of the project out, simply because the learning curve on processes and terminology need to be collaborated on . Selecting a vendor with a broad background on a specific industry like Quality Management helps to provide a foundation for building a process that meets your requirements, with a long-standing knowledge base of experience to draw from .

4. Consider the Project Scope—Proven Implementation versus New Application Development: According to a report by the Standish Group on more than thousands of software projects, 40% failed completely, and an additional 33% were “challenged,” meaning that they completed late, went over budget, or were completed with fewer features and functions than originally specified . Even more staggering, a recent study by Gartner




Research revealed that nearly four in ten major software purchases ended up as “shelfware”—software that was purchased, but never implemented .

The root of all these challenges lies in the ability of the project to be defined properly . With custom developed solutions, the project scope encounters obstacles not foreseen at the outset of the project, and it is extremely difficult to estimate the time and expense associated with a major development project . This is primarily due to development of new features not inherent within an existing application or customer developed application, which creates a tendency to change and modify the scope “on the fly .” The result, according to the Standish Group, estimates that 52 .7% of all custom application projects cost 189% of the original estimate provided .

Software vendors with best practices built-in draw on a history of implementation of similar processes, and have implemented hundreds of projects of similar focus and scope . These implementations follow a proven process, and follow a pattern of project management that delivers the product on-time and within scope .

5. Return on Investment—Look for the Hidden Cost of Development: 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 on the next page .

When comparing these two scenarios, we can assign a risk ranking to build versus buy, as illustrated in the risk matrix below:

Because a best-practice configured solution requires little to no development costs and uses a proven method of implementation to ensure projects are kept on scope, the actual risk associated with implementing is considered lower than that of a custom-built application . This is primarily due to the unknown factors that can occur in custom development, as well as long-term costs to update and maintain the custom-built system .

Avoid the Dangers of Buy…then BuildWhen making the decision of build versus buy, it’s important to determine the level of development required, in either case . While many off the shelf software systems will claim to have the best practices built out of the box, what is often not determined is any level of custom development that may be needed after the software is purchased . Often times, purchased solutions will incorporate a framework of best practices within their solution, but in order to tailor the system to meet your needs, the system must be custom developed . As a result, the customer is left with a purchased solution that will need a custom development project added into the purchase, creating the same challenges with a purely built solution . Look for systems that have the flexibility to adapt to specific processes without any need for custom development . These solutions often enable the administrator (or “Power User”) to configure all aspects of the system to meet unique business needs . Configurable systems such as these completely eliminate any custom development needs, and provide a truly flexible and adaptable system that embodies the purpose of a purchased, best-practice solution .

The decision to implement enterprise software is not a simple task . Software solutions typically represent an investment of 5-7 years, often up to a decade for many organizations . When weighing the options of determining software selection, the “Build versus Buy” decision is one that will always come up, and requires careful consideration on the path to take for your investment .

While both options have merit, many organizations opt to leverage the existing best practices implemented within the industry, the proven track record of success and innovation, and the most flexible technology that will help them seek returns on their technology solution . For many, the growing trend lies in purchasing a solution that provides the most functionality and features, and presents the lowest total risk to the organization .




13 |13 | Avoid Scope Creep in Enterprise Software ImplementationTips for Implementation Success



Avoid Scope Creep in Enterprise Software ImplementationWhile many companies focus heavily on the software’s ability to meet the business need, very few focus on the vendor’s ability to implement the software . The responsibility of a software implementation project is shared between the vendor and the customer . While the vendor needs to deliver on all those promises they made in the RFP, the customer needs to make sure that their processes are well-defined, and that all the requirements of the solution are outlined in detail . Without the roadmap for the solution, the vendor can only take a “best attempt” at meeting the business need . Kind of like shooting a moving target in the dark, blindfolded and with one hand tied behind the back .

With all the investment put into selecting a software vendor for your business, it is hard to believe that there is any possibility of failure . However, recent studies have shown that within a sample set of more than 9,000 software rollouts, 71% either failed or were late and over budget . Even more staggering, a recent study by Gartner Research revealed that nearly four in ten major software purchases ended up as “shelfware”—software that was purchased, but never implemented . The root cause of such pitfalls is usually attributed to challenges associated with project management, and the inability to properly define the requirements to make the implementation successful . As a result, the end users never really accept the solution, and the cost to implement correctly becomes extended .

Successful projects are the result of the Quality of the solution and the acceptance of the solution by the end users . As seen in the diagram below, without proper planning and project definition at the start of the project, implementation projects can often suffer in the long-term . Projects without a defined scope will often require fluctuations in resource levels, and push the project out far beyond its expected completion .

Here are just some quick points to consider when looking at an implementation project:

1. Get the Requirements Up Front: While this may seem like a no-brainer, many companies won’t truly know what their requirements are when they start a project . You may have one or two project managers who swear up and down they know the processes, and do not need this exercise—until you actually get all the stakeholders in a room . At that point, the picture gets painted a different shade of what you thought . Many times, the stakeholders will “trickle in” during the project after implementation has begun, and this is the source of the evil “Scope Creep” paradox . The more features we want, the more time it will take, and the more time it will take, the less likely the vendor is to deliver it on time .

By gathering all the stakeholders and clearly defining the project and its requirements at the start, the actual implementation process will move much smoother . No one is “trickling in” and all elements of the project are planned and ready to go . This early investment of time in the beginning of a project may seem like it would take longer on the outset, but in reality, this up-front investment of time actually speeds up the project in the long run . Resources are efficiently managed, project timelines are met, and this project is delivered on time and on budget .

2. Get a Design Specification: Whether you are implementing a configurable, out-of-the-box solution or a heavily custom developed application, getting a design specification is an important step in the process . A design specification is essentially a simple mock-up, “wire frame” or depiction of what the final product is going to look like once implemented . These are typically 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, and so forth . Same goes for the software solution—making 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 specifications in place and approved, then the real implementation can begin . Whether configuration or coding, most implementations will vary, but ultimately the goals are similar . This is to deliver the finished product according to the information provided in the first two points . Ensuring the finished product matches your requirements exactly is important, which is covered in the next point .

14 |14 | Avoid Scope Creep in Enterprise Software ImplementationTips for Implementation Success



3. UAT—User Acceptance Testing: It’s important to always include the end users in the process—they 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 car—making sure that the seats are comfortable, the engine is tuned, and the wheels won’t fall off . Just the same in the software world—move around through the workflows and forms, push the performance, and make sure the proverbial “wheels stay on .” This is usually done by the company’s 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 “word on the street” for those daily users .

The theory behind using this project management/requirements first approach to implementation is that during UAT, only minor problems are tweaked . The last thing either party wants is a major technical flaw this late in the game .

Investment in software shouldn’t fall victim to a poor implementation . Not only does it leave a bitter taste in the mouths of the project team, but the software investment becomes diluted and could end up as “shelfware .” Ensuring the project requirements are gathered at the start, the design is approved before implementing and testing on the backend will help to make sure the project is completed within scope and within budget .

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



ROI: Assessing Value in a Quality and EHS Management SystemEveryone seeks out value . Whether you’re a coupon clipper, a sale shopper, or a garage sale stalker, people look to get some sort of value out of their buying experience . And if the product is purchased at retail, you look for ways to get the most out of the product you purchased .

The software sale is no different, and potential customers are looking for ways to demonstrate a viable Return on Investment (ROI) . Let’s dispel any misconceptions first—software is not just a tool, it’s an investment . Quality and Environmental Health and Safety (EHS) management solutions require upfront costs, and upfront effort to get it up and running, and the returns only come after you’ve put financial investment into the product and financial investment into the implementation . The key is how quickly you expect to see a return .

In this market, ROI needs to happen quickly . We have entered a time when IT departments are cutting budgets and looking for ways to consolidate and integrate business systems . As such, IT is looking for ways to cut systems that are draining resources, protect budgets for larger-scale implementations, and seek out solutions that are low-cost alternatives . The Chief Information Officer (CIO) is looking for ways to demonstrate immediate ROI on projects, to the tune of seeing returns within a Quarter . This need has had an effect on the “Software Middle-Class”—those systems that are high-cost with long timelines to ROI . You have three real scenarios in this IT solution model:

1. 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 example—the 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 .

2. 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 .

3. 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 .

So, what does this mean for Quality and EHS solutions? Well, it means that companies are looking for more value from their systems; QMS and EHS solutions are expected to do more and provide more immediate value . The CIO will look at their

infrastructure and say, “can my too-big-to-fail systems handle the processes we need, and if not, what systems can we put in place that will integrate with these systems and provide me with quick ROI?” QMS and EHS are prime examples of systems to accomplish this goal . Here’s what these systems offer:

1. Workflow and Business Process Automation: Look for a system that has the flexible workflow to not only accomplish the task of Quality and Health and Safety, but to also provide value in all business process initiatives . Can the system be configured to do more for the organization? Leading systems integrate PLM, SCM features into Quality, and add Sustainability to EHS that the software middle-class once handled; this provides additional value to the system and makes it a lower-cost alternative to these middle-class systems .

2. Integration Capabilities: Again, the CIO will ask whether the “big project” systems like SAP can handle the process, and if it can’t, then can it be integrated with these QMS and EHS systems . Look for solid and certified integration points that will enhance your “too-big-to-fail” systems . Leading QMS and EHS systems offer various levels of integration—enough to fill the gaps that are necessary to round out the infrastructure .

3. Provide Immediate Value: When looking at these systems, take time to realize the ROI is critical . The nature of QMS and EHS systems is in their configurability—they are inherently built to be configured quickly and adapt to changing processes with little to no programming or custom development . This enables them to provide value within a short span of time, usually within a Quarter .

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



4. Demonstrate Definable ROI: This one is tricky—how 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 EHS systems:

a. Time Savings: 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 organization 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 immediately quantifiable, the time savings is staggering .

b. Systems Consolidation: 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 efficient method of tracking Quality and Safety .

c. Administrative Overhead: 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 automatically 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 .

So, ROI is all in how you perceive value in the system . Look for a solution that not only is able to provide value in a short period of time, but demonstrates the value in a way that you can relate to your organization . The above are just specific examples . You would need 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 ROI comes in all shapes and sizes, and not

only do leading QMS and EHS system provide the low-entry, high value mix, but are prime examples of gaining ROI in a short period of time .

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



The Importance of Risk in the Complex Quality LifecycleManufacturing industries have matured over the years, customer demand increases, and the complexity of the products also increases . So we now have a complex product lifecycle that needs to move faster to keep up with demand—manufacturers must keep pace with the demand, while ensuring Quality of the product at every step . The faster we move, the harder it becomes to correct adverse events, and prevent Quality issues in the same way we’re used to . We need a measure to help us search out the most critical issues and address the Quality issues that matter most . Risk Management is of growing importance in Quality for this very reason .

Let’s look at some of the areas risk plays in the Quality lifecycle:

1. Risk in Design: Incorporating risk in design is a critical, but sometimes overlooked component in the Quality life-cycle . Traditionally 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 .

2. Risk in Process: Corrective Actions are an issue in many organizations . You would think that a system designed to efficiently correct a problem wouldn’t be a problem itself—but 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 incor-porating 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 immediately—Quality systems do not specifically state that every event become a Corrective Action . Using risk will help to streamline the system in this fashion .

3. Enterprise Risk Management: Risk mitigation is every-where . 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 orga-nization and take action based on those elements in broad strategic level .

In reality, ERM follows a path no different than the more granular departmental levels:

a. Risk Identification: Simply put, look for the potential risks . Whether at a low-level or high-level, you need to figure out where your risks arise . This can be from adverse events, hazard analysis, departmental surveys, and similar areas .

b. Risk Assessment: Once you’ve identified the risk, you need to determine how severe it is . Is this risk high, low, or negligible? Assessment seeks to cate-gorize (and potentially prioritize) our risk .

c. Risk Review: New risks within an organization need to be reviewed . Risks cannot automatically be assigned an action—often you need a team to review the risk ranking, determine the next steps, and so forth .

d. Risk Mitigation: We now ask the question, “how do we fix this?” Risk Mitigation relies on taking steps to correct the events, and ultimately reduce their risk to acceptable levels . Corrective Actions help to create a plan for investigating and correcting systemic issues, and reduce the risk of recurrence .

e. Risk Reporting: The last step is sometimes over-looked, but critically important . Reporting not only creates visibility into top risks, but it also lets you trend out potential areas of improvement . Reporting lets you see how one area’s risks overlaps with another area’s risks .

As industries move faster and product lifecycles shorten, you need to benchmark Quality not only as a corrective measure, but in a proactive, preventive way . Incorporating risk into the product lifecycle will help to identify, mitigate, and prevent potential risks along the way .

You need to identify potential risks, assess the dangers, take steps to correct your “path” to mitigate the risk, and continue on . The faster you go, the more risk mitigation plays into the equation .

18 |18 | Risk Assessment: Creating a Risk MatrixBest Practices for QMS Solutions



Risk Assessment: Creating a Risk MatrixIn this day and age, risk is the biggest buzzword in the compliance industry . We’ve talked about it, you can’t go anywhere without hearing about it, and everyone’s got a risk-based solution . I think the primary reason why we focus on Risk Assessment and Risk Management, is because in business, we need to quantify our actions . We can no longer rely purely on “gut instinct” to execute on events, whether Quality, Financial, Social, or similar areas . The world moves too fast, and one misstep can make or break your business . Risk provides the objective metric to help the decision-making process . But, you need to know how to use risk .

How do you define risk? It’s not as easy as you may think . Companies spend plenty of time and money coming up with a scheme on how to calculate risk for their organization . Risk is defined as the “systematic application of policies, procedures, and practices to the tasks of analyzing, evaluating, and controlling risk .” All this really means is that we put tools in place to help us look for risks, assess those risks, and then take action on the risk . The trick here is finding the risk, isn’t it? How do we find the risk?

The components of risk usually manifest themselves in two forms: hazards or harms . Hazards represent the potential source of a harmful event (the cause) . Harms are the resulting damages to products, persons, or the environment (the effect) . Risk is essentially cause and effect on a defined scale . It’s the scale in which most struggle .

Usually, when trying to quantify hazards and harms, most organizations look at two metrics: Severity and Frequency (or likelihood) . Taking these metrics into account, we can develop a scale in which to measure hazards and their harms . This can be numeric (scale of 1-5), verbal (excellent to poor) or both . If you were to graph these scales, you would come up with a numerical matrix, one that highlights the risk “zones” by their multiplied number on the axis, much like this one below:

You can see that we have a Low-Risk or Generally Acceptable Risk zone, and a High-Risk or Generally Unacceptable Risk zone, but

what about the middle? There’s a gray area of subjectivity here . How do companies determine this gray area?

This is not always an easy answer . Some companies have to weigh the costs versus benefits on these risks, without creating a disproportionate cost to risk (Example: spending $1M to prevent a blister is disproportionate; spending $1M to prevent a fatality is proportionate) . Companies will carefully vet these zone, and typically adopt a concept called ALARP (As Low as Reasonably Practicable) . Simply put, this means that the risk is as low as we can possibly get it, or it’s “Tolerable” or “Undesirable”—but it isn’t critical or catastrophic . So 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 “vet the matrix”—put it through real-world historical examples and see if the risk matrix comes up with the correct risk based on historical events . You may need to “tweak” the matrix based on the vetting process . Hard mathematics will not properly assess the risk without a little real-world honing . Once you’ve fine-tuned the matrix, you can start utilizing it in your Compliance system .

19 |19 | Risk Assessment: Creating a Risk MatrixBest Practices for QMS Solutions



Risk Assessments and risk matrices are wonderful tools to help guide decision-making in an organization, but they are not meant to be stand-alone tools . They help to provide a guide for Risk Assessment, using quantitative and repeatable metrics to ensure a consistent method of determining risk . Most best-in-class organizations will assemble a “risk team” to go over adverse events and determine the risk . It’s 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 quantitative risk-based processes, but the people are the drivers of the system .

The next question becomes, “How do I incorporate Risk into my Quality Management System?” More specifically, how can Risk ease the bottlenecks in an organization’s Corrective Action process?

Too often, when adverse events enter an organization’s Quality system, people are quick to open up a Corrective and Preventive Action (CAPA) . No matter what the adverse event, its severity or impact, a CAPA is opened up . Having a CAPA system in place is an extremely valuable (and essential) part of a good QMS . However, if everything becomes a CAPA, then you create a bottleneck . Employees are so focused on working on their CAPAs, they forget to do anything else .

What you end up with is this—hundreds of CAPAs, without really knowing which CAPAs are critical to the business and which have less impact . It becomes the needle in the haystack conundrum—finding the critical adverse events can prove difficult if you don’t have a way of finding them . I once asked a Quality Manager how he handles CAPAs—what his metric was . “We handle the most overdue first,” was his reply, and he went on to say that if it isn’t critical and is at the “bottom of the pile,” then they don’t get to it in time . That said, there is a better way .

1. Not every event needs to be a CAPA: Yes, it’s true—if you can immediately correct an event, then correct it . Not every event needs to be opened up as a Corrective Action, only those that are systemic issues and pose a critical impact on the business .

2. Use Risk to filter events: So if not every event needs to be a CAPA, then how do we figure out the bad the from not-so-bad? You need a way to filter these events, and you need to do it in a repeatable, systematic method . Risk Assessment is a great way to do this . Risk matrices will help your team make the determination as to the criticality of an event . The higher the risk, the more likely we would like to take Corrective Action .

3. Do a CAPA on your CAPA System: Sometimes even a good CAPA process needs a little updating . Make sure to continually audit the CAPA process, and if the process is not efficient enough, then it may be time to do a CAPA to correct any potential bottlenecks or problems within . Like any good process, a little maintenance and “trimming” is always healthy .

4. Use Risk to Ensure Effectiveness: For an action to be truly corrective to the process, it must be effective, otherwise you’re back to square one . Much like risk can be used to filter adverse events, risk can also be used to ensure effectiveness of a CAPA . Risk helps to ensure that not only is the CAPA effective, but it’s within the risk limits of your organization’s compliance standards .

CAPA is an effective and essential tool but, like many processes, can be blocked up if you are too reactive to events . In order to streamline your CAPA process, it is important to look at adverse events and filter them to properly determine how critical they are .

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



Three Keys to Global Harmonization in Quality: Learning to Share

Each site within the organization, operating under their own QMS, are happy to have their specific processes just the way they like them . Then someone comes along and says, “we’re going to standardize on a single platform .” There are inherent challenges to harmonizing a solution, especially Quality Management . However, with the right tools, harmonization can actually enable a single standardized environment, while at the same time sustaining each site’s unique business processes . Below are a few key considerations when harmonizing your QMS:

1. 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 today’s advances in technology, it’s now possible to be “common” on a corporate level, while maintaining the unique processes associated with each site . The key lies in the technology .

2. 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 backbone—each 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 .

3. Get a Strong Project Team to Work Out the Details: Technology is only as effective as the team that is implementing it . Harmonization, by definition, is a group operating in the same direction—the team must be able to work together to get the business requirements to building a standardized solution . This involves looking at the stakeholders of the system (at the corporate level and the site level), the inputs required across the enterprise, the processes that govern the system, the desired outputs that the team expects to see, and how the results will be measured and managed . This methodology will spit out a set of requirements which, if done properly, will create a framework for a harmonized system . But each team member must contribute and commit to the cause . When starting the journey towards harmonization, there will be bumps along the way . Not all processes will fit together, and there will need to be compromises . It is important that the project team stay focused on the ultimate goal—the stronger the team, the better the end result will be .

A strong team builds innovation and the technology drives it . The combination of these two elements will then answer the question, “how can we all be common, but keep our processes and data unique?”

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



Is Quality Dying a Slow Death, or Evolving Beyond Definition?Is Quality as we know it a dying concept, or is it evolving?There are those who crave the old days of Deming and Juran, and those who see their multiple Quality certifications as a badge of honor, and those who will define them as a Quality practitioner . These are the folks who hold on dearly to the concept that Quality is reserved for the few practitioners who are meant to “police” the Quality operations—a single point of contact for all of Quality .

These are those who fear Quality is dying .

There are those in this market who recognize we are in a world of change, 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 concept of Quality, but expand it to the enterprise .

In this evolutionary model, what is the view of Quality? Well, Quality means different things to many people . In fact, Quality can be considered such a broad scope, that it may defy definition . However, the challenge is that Quality is defined differently throughout the enterprise, and the key to recognizing what Quality is depends on who is defining it . Here are some of the segmentation of who Quality touches in the enterprise:

1. “In the Box” Quality: QC, QA and the like are what you would call “in the box” Quality . Simply put, it’s the folks who have Quality in their title, and live and breathe the practices that have been perfected over 60 years .

2. The Quality “Involved”: There are many areas within the organization that don’t 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:

a. EHS: Processes and practices in EHS have incredible similarities to Quality . Simply looking at the ISO standards for Environmental and Health and Safety will demonstrate how similar ISO 9000 aligns .

b. Corporate Social Responsibility: Whether Human Resources, or social responsibility, the concepts of improvement, controls, and processes are touching Quality .

c. Product Design and Development: Tell an Engineer he’s a part of Quality, and he may look at

you funny, but Quality by Design is a key component of improving overall product Quality, and they are Quality users as well .

d. Governance, Risk, Compliance: Methods in this sector are continually borrowing from Quality, and while the terms may change, the goals are similar .

e. Other Processes: IT, Supply Chain and more areas are all Quality involved .

3. The Consumers of Quality: Quality is not just in practice . There are many in the organization that consume the results of Quality and use Quality data to make decisions . C-Levels within an organization are a perfect example . While not considered a part of the Quality machine, improving overall Quality as it affects the bottom line is of critical importance . Without consuming the critical Quality related data from the above areas, decisions are made much more difficult .

So, what is the future of Quality? Well, it needs to expand the vision to encompass these groups and escape the narrow definitions of the past . We need to be able to incorporate the Quality practices and translate them into the vernacular of these involved areas, and demonstrate that Quality goes beyond a single department . Quality is everyone’s problem, and by creating a holistic vision of Quality, all areas begin to converge and recognize their role in Quality .

This recognition is the first step to the evolution of Quality, taking the concept to new heights and shaping the future of how organizations view Quality .

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



What Star Wars Can Learn from Quality Management Software

“What if The Empire had implemented a QMS on the Death Star?” Here’s what would have helped The Empire in their endeavor to rule the galaxy if they only had put Quality Management as a strategic initiative .

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 of activities . The Death Star project management team consisted of three key people—Grand Moff Tarkin, Darth Vader, and Emperor Palpatine . These are not the more flexible managers, and are not above taking employee errors or missed deadlines with the aid of a lightsaber, force lightning or a death ray .

Perhaps if The Empire implemented a Quality-based Project Management System, they would be able to clearly define the roles involved in the project, assign tasks to those roles, and manage the project from an aggregate level . Workflows keep the project deliverables on track, and perhaps this level of visibility would enable them to maintain control, without having to resort to the Dark Side as their only means of clairvoyance .

1. Document Management: Let’s be honest—even The Empire could’ve 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 the network and download the Death Star plans like it was a space walk in the park? My guess is that The Empire, in all its glory, was using a file system to store documents . If The Empire would have used a Document Control system like those in a QMS, access to these

specifically sensitive documents would have been limited to those who had the proper access rights . Furthermore, document control can limit the details of certain fields within the data, so that no sensitive data is accessed .

2. Employee Training System: Without proper employee training, then many organizations run the risk of Quality incidents, Safety incidents, and other risks to the business . It appears to me that The Empire was not tracking training in a centralized system . If they were, then they would have been able to see that nearly 80% of the Stormtroopers in The Empire couldn’t hit a target with a blaster if their lives depended on it (and it often did) . Or maybe they would have uncovered the fact that their patrol procedures clearly missed security breaches—Like 80 year old Jedis skulking around the tractor beam . Proper training systems enable managers to see visibility into not only who is trained, but also how well they are trained and whether actions need to be taken to update training records for poor performance .

3. Supplier Management and Supplier Rating: Let’s face it—The Empire had to have contracted out to build this Death Star . All the components that go into building a finished product rely on suppliers and contractors to help complete the process . When watching the movie, we know that the Rebels found a weakness in the design of the Death Star (thanks to the weak Document Management System) . If The Empire would have had a real-time inspection and rating system, they would have been able to inspect that access port, and send out a Corrective Action to the knuckleheads who thought putting a direct access to the Death Star core was a good idea .

4. Nonconformance, Audits and Corrective and Preventive Action: Let’s stay on this, then . Obviously, we know that the Death Star had a defect . It was only in the final hour did The Empire realize the danger, and by that point it was too late . If they had a Quality system in place, they would have found this flaw, whether through regular space Audits (or at the very least an Audit through tremors in the Force), or a Nonconformance when the defect was installed, and issued a Corrective Action to fix the problem . Clearly, Quality took a backseat to their overconfidence, and ultimately resulting in, well…you know the rest .

5. Management Review and Reporting: As I said before, the primary project managers used fear as their primary motivator, 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 report—if they had a robust reporting system that collected

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



Quality data from all areas of the Death Star, and rolled this data up to help determine 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 wouldn’t 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 .

6. 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 Leia’s home world? Did Darth Vader assess the risk of letting the Rebels escape with the Death Star plans? Did they assess the risk when they underestimated the rebel’s chances of destroying the Death Star? In any system, it’s important to incorporate risk into the processes, whether Quality or similar system . If The Empire would have perhaps weighed the severity and likelihood of the risks associated with their actions, perhaps we would have seen a different outcome of the story . Risk Assessment, especially in a QMS, allows managers to filter out critical events, and make better decisions on how to handle them, and then ultimately mitigate the risk of recurrence .

Of course, we know that if The Empire followed these rules of Quality Management, we wouldn’t have had the story that makes Star Wars so great . But it is sometimes fun to imagine, “What if?” and see how life would have been if instead of Darth Vader, we had Darth Deming .

24 |24 |

www.etq.com

[email protected]

800.354.4476

516.293.0949

Date post:	10-Jul-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Selecting, Implementing, and Using QMS Software Solutions · 2016-05-26 · software solutions have...

Documents