THE FOOD SAFETY GUIDEBOOK EtQ, Inc. - WordPress.com · 2015-08-03 · THE FOOD SAFETY GUIDEBOOK...

Selecting, Implementing, and Using Software Solutions for the Food & Beverage Industry

EtQ, Inc.THE FOOD SAFETY GUIDEBOOK

www.etq.com 800.354.4476 [email protected]

The Food Safety Guidebook: Selecting, Implementing, and Using Software Solutions for the Food & Beverage Industry

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

Best Practices in Food Safety

Risk Assessment: Creating a Risk Matrix . . . . . . . . . . . . . . . . . . . . . .13

Quantitative Risk Assessment in HACCP Plans: Decisions, Decisions... . . . . . . . . .15

The Food Safety Modernization Act: Perspectives & Recommendations for Planning Your Food Safety Program for the Future . . . . . . . . . . . . . . . . . . . . . . . 17

Food Safety Management: SQF 7th Edition Takes a Unified Approach . . . . . . . . .19

The Low Carbon Diet: Sustainability In Food Safety Management Systems . . . . . .20

Final Thoughts: Fun Takes on Quality Management

All I Need to Know About Food Safety Management I Learned in Kindergarten . . . .21

1 |1 |



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

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 deci-sions 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 deci-sions 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 incor-porated 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 main-stream 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 inves-tigation 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 auto-mated. So why are people so hesitant to implement software? Here are a few potential reasons:

The Fallacy of the Custom Solution: 1. 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, 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.

Getting on the Quality Management Software Soapbox

2 |



The Fallacy that Software is too Expensive:2. 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.

The Fallacy of the In-House Maintenance:3. 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 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 organiza-tions 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:

Time-savings:4. 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, inte-grating with other business systems, and fostering better visi-bility and collaboration throughout the business.

Return on Investment:5. There’s not doubt that software 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.

Rapid Application Development:6. 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.

Enterprise Risk Management:7. 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 every-one’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.


3 |



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

Case:1. 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 auto-mated 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.

Case:2. 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! 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 facil-ities, 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.


4 |4 |



In a market where high-demand causes organizations to seek software systems that will fit into their complex business infra-structure, 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.

Flexibility to Adapt to Business Processes:1. 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 limita-tions, you have compromised your efficiency.

Do not compromise—find a solution that is truly flexible and config-urable, and can configure all aspects of the software, including work-flows, 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 oper-ations 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.

Web-based versus Web-enabled:2. 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 flexi-bility 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.

Look and Feel—Making the System Your Own:3. 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 require-ments without having to do extensive development.

Making Sense of the Data4. —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.

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

8 Simple Rules for Selecting a Quality Management Software System

5 |



Taking Quality to the Enterprise—Scalability Matters:5. 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 to expand your QMS beyond your four walls to include other facil-ities, 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.

Tying Systems Together through Integration:6. 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 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.

Know Your Audience—End User Acceptance:7. 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.

Time to Value—Implementation and Deployment: 8. 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 implemen-tation 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 Simple Rules for Selecting a QMS SystemGetting Started on Your Journey

6 |6 |



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 enter-prise 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.

Implementation Track Record:1. 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.

Customer Satisfaction:2. 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 ques-tions. 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.

Financial Well-Being:3. As stated above, you are investing in an enterprise solution and the company behind it—it’s criti-cally 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 capi-talist 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.

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

7 |



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:

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 carefully on 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 ratios—chances 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 vendor’s 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:4. 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.

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

8 |8 |



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

Predictable and Transparent Costs:1. 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.

In fact, according to Gartner Research Group, packaged applica-tions 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.

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

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

Flexibility and the Ability to Adapt to Change:2. 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 rela-tively short timeframe.

Furthermore, having the flexibility to adapt to changes is key to success in response to changing market conditions. With configu-rable 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.

Best Practices Experience and Core Business Focus:3. 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.

Consider the Project Scope—Proven Implementation versus 4. 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 spec-ified. Even more staggering, a recent study by Gartner Research

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

9 |



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 asso-ciated with a major development project. This is primarily due to development of new features not inherent within an existing appli-cation 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 implemen-tations follow a proven process, and follow a pattern of project management that delivers the product on-time and within scope.

Return on Investment—Look for the Hidden Cost of Devel-5. 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 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 appli-cation. 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 prac-tices 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


Comparison: Build Versus Buy

10 |



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 consid-eration 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.


11 |11 |



While 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 implemen-tation 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.

Avoid Scope Creep in Enterprise Software Implementation

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

Get the Requirements Up Front:1. 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 implemen-tation 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.

Get a Design Specification:2. 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

Avoid Scope Creep in Enterprise Software ImplementationTips for Implementation Success

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, 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 specifi-cations 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 require-ments exactly is important, which is covered in the next point.

UAT—User Acceptance Testing:3. 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 implemen-tation. 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.

Avoid Scope Creep in Enterprise Software ImplementationTips for Implementation Success

13 |13 |



Risk Assessment: Creating a Risk Matrix

In 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 organi-zations 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 high-lights 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 dispro-portionate cost to risk (Example: spending $1M to prevent a blister is disproportionate; spending $1M to prevent a fatality is propor-tionate). 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

Risk Assessment: Creating a Risk MatrixBest Practices for QMS Solutions

14 |



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.

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 quan-titative 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.

Risk Assessment: Creating a Risk MatrixBest Practices for QMS Solutions

Not every event needs to be a CAPA:1. 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.

Use Risk to filter events:2. 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 determi-nation as to the criticality of an event. The higher the risk, the more likely we would like to take Corrective Action.

Do a CAPA on your CAPA System:3. 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 bottle-necks or problems within. Like any good process, a little mainte-nance and “trimming” is always healthy.

Use Risk to Ensure Effectiveness:4. 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.

15 |15 |



Quantitative Risk Assessment in HACCP Plans: Decisions, Decisions...

Quantitative Risk Assessment in HACCP Plans: Decisions, Decisions...Best Practices in Food Safety

Hazard Analysis and Critical Control Points (HACCP) in itself is a Risk Management tool, and is adopted by many of the Global Food Safety Initiative (GFSI) Compliance standards. It’s concerned with looking at the various potential hazards within the food safety plan and assessing what types of controls need to be put in place. Controls like these come in many flavors, most notably Prerequisite Programs or Critical Control Points (CCP). But, “how do you accurately determine whether a step in the process is a CCP or not?”

There are two schools of thought to this. One is the Decision Tree and another is Quantitative Risk Assessment.

Decision Trees seemed to be more common in HACCP Plans, maybe because most HACCP Plans haven’t been automated to the point where Risk has become necessary. But as more Food Safety Management Systems (FSMS) become automated, new technol-ogies are introduced that streamline the process. The trouble with a decision tree is that it lends itself to subjectivity. Depending on who is filling out the decision tree, the answer could change. That is not to say that there is a problem with decision trees or the person filling them out—it’s the combination of the two that can be problematic.

HACCP needs logical, systemic methods for determining the signif-icance of a hazard in a repeatable way. Risk Assessment is the best method for this. It relies on a defined verbal scale, it uses a singular, common mathematic method for determining a hazard, and sets guidelines for actions based on the result. Furthermore, it’s a repeatable method—if done properly, the risk matrix will spit out the same result every time.

Let’s take an example. Here’s a hazard for a step that involves a potential CCP—Pathogens: (See figure 1)

We know the hazard and the severity/likelihood, but we still need to come up with a determination of whether a CCP is necessary. A decision tree would look something like this: (See figure 2)

Or we can try and put the hazard into a Risk Matrix, using the verbal scale and assigning a weight to each level on the scale:

Now, we have a repeatable and systemic matrix for looking at the risk. We can set up our risk thresholds (let’s say for this example 1-10 is a CCP), and then apply the verbal scale to the matrix:

Now we have a quantitative result to draw from. We can then enter it into the hazard analysis, and record the results:

It’s not enough to just have a risk matrix in food safety or any other compliance-related process. You need a team in place to analyze the risk and leverage the data to make the decisions. There is always “tweaking” based on other factors and human experience. HACCP is about common sense. Risk will help to automate it and give a consistent, auditable, and logical result. But experience is also important in determining hazards. So there is a marrying of the two methods that will ultimately make for an efficient Food safety system.

16 |



Risk Management and Risk Assessment are prevalent in all indus-tries. Food Safety is no exception, and like all industries, Risk requires a certain degree of human element coupled with a quantitative tool to be effective.

Quantitative Risk Assessment in HACCP Plans: Decisions, Decisions...Best Practices in Food Safety

Figure 1

Figure 2

17 |17 |



The Food Safety Modernization Act: Perspectives & Recommendations for Planning Your Food Safety Program for the Future

Like anyone who is involved in the food industry, it was promising to see Congress pass the Food Safety Modernization Act (FSMA). It’s a monumental step in the right direction towards achieving a national food safety program. That being said, it’s still a long road ahead. It will take months, if not years, to draft the regulations, train and develop the people to enforce those regulations, and most impor-tantly, to pay for it all. The current price tag is looking at about $1.4 billion over the next 5 years.

Nevertheless, this is a great leap towards a better plan for how the government handles food safety. While we can expect a slow-as-government-goes implementation, it’s important to note that many best in class organizations are already (and have been) taking steps to improve their food safety programs, many of which align with the new bill. So, while many organizations will wait till the final regula-tions hit their proverbial plate, there are a few key areas that make the most sense to start working on now.

Recall Management:1. Prior to this law, food regulators could only recommend a recall to organizations. Much like their FDA brethren in Life Sciences, food organizations are now subject to a mandatory recall process. Like any process, recall management involves many roles and steps to ensure that the product is effec-tively removed, the affected parties are notified and measures are taken to inform the FDA at every step of the recall process. Trans-parency and full disclosure become a key point, and without a proper system in place, you run the risk of a messy recall.

Risk-Based Approach to Food Safety:2. The FDA is planning to take a risk-based approach to food safety, focusing their attention on those food contaminants that represent the highest risk to the public. This is not only a great practice from a regulatory

perspective, but it’s also a great approach for any organization when assessing their own products. Using risk-based tools, orga-nizations can focus their attention on the products and processes that pose the highest risk, and take action on related events. It will be interesting to see how the FDA plans to incorporate risk tools into their process in the coming months.

FDA Visibility into Company Records:3. The FDA will be seeking better ways to require access to an organization’s records prior to an inspection. This will not only give the FDA a “heads up” on any potential issues, but also allow them to gain a more comprehensive view of the organization’s operation that they

may not get on the inspection. It will be critical that organiza-tions have a centralized and controlled system for managing and maintaining records. Without a well-defined system in place, it can be a harrowing experience trying to collect all the necessary documents from all over the company.

Preventive Controls:4. Many companies already have HACCP plans in place, but the law goes a little beyond that now. It will require the HACCP, but it will also require a Preventive Control Plan. In this plan, not only will the HACCP elements be required, but so will preventive controls. These include:

Hazard prevention

Sanitation and hygiene documentation and training

Environmental monitoring

Food allergen control

Recall management plan

In addition, if a preventive control fails, the organization will need to have a corrective action plan in place. There is really no way to manage all this without an automated FSMS. It provides all the key processes to help maintain a food safety system, it provides the record keeping components for visibility into your organization, and it allows you to be able to adapt to any changes in regulation.

As the FDA begins its journey towards implementing the most important food legislation in our history, organization should focus on the key areas which will help them adapt to any new changes that will come (eventually)—process automation, visibility, prevention, and responsiveness.

The Food Safety Modernization Act: Perspectives & Recommendations for Planning Your Food Safety Program for the FutureBest Practices in Food Safety

18 |



So, while food and beverage manufacturers patiently await these FDA regulations, market demand does not wait, and the need to ensure safety and quality in food products does not wait either. Many organizations are adopting FSMSs, whether out of good business practice or in anticipation of regulation. The FSMA will have provisions in it that will require greater visibility into data and more stringent controls in place to ensure food safety.

Many organizations are following the GFSI scheme for food safety initiatives, and this seems to be where the regulations should be centered around. Automated FSMSs are designed currently with the GFSI schemes in mind; a good enterprise system will be flexible enough to adapt to new regulations and business processes such as the FSMA.

The bottom line is don’t wait on the FDA—get lined up for Food Safety Management now. Start working on the processes and implement systems to help you today, because who knows when the FDA will really be ready for tomorrow.

Truth of the matter is, there are some challenges to these regulations. The FDA is vastly underfunded for this endeavor, and the $1.4 billion that is budgeted for this new sweeping reform is being whittled away. There are serious challenges facing regulators. So what is in front of the FDA with respect to Food Safety Management?

Overcome the Challenge of Increased Inspections:1. According to the FSMA, the FDA was required to conduct at least 600 inspections in 2011, and then double that number each year for the next 5 years. This number has currently been met, and will be most likely met for 2012. But what’s the solution? Even the FDA doesn’t know—funding does not seem likely. If the FDA cannot inspect every facility, then an alternative needs to be implemented. Many organizations are adopting a risk-based approach to food safety—why can’t the FDA? Taking a risk-based approach would enable the FDA to inspect only the high-risk facilities, maximizing their effectiveness to those facilities they do inspect.

Embrace Information Technology:2. We live in a digital age, so much so that even saying “digital age” sounds cliche. So, why do most FSMSs rely on some sort of manual component? The key to success of better food safety enforcement and safer end product relies on the implementation of an Enterprise FSMS. This is not just on the vendor side—this is from farm to fork to regulatory agency. The FDA has already started to creep into the regulatory reporting with their Electronic Submissions Gateway (ESG). The Life Sciences industry has created a technology platform that automates Quality and Safety and creates a layer of visibility into regulatory agencies like the FDA. The food industry will need to follow suit—adopting more enterprise systems that integrate with all areas of the business and tie Quality and Safety to their end product and report to the agencies that regulate them.

Include the Supply Chain:3. Part of the FSMA overhaul involves the supply chain, particularly foreign suppliers. The FDA cannot necessarily extend beyond their jurisdiction, but they can enforce incoming goods from foreign suppliers. The key to control is actually two-fold; the vendor needs to ensure quality down their supply chain, and the FDA needs to control the quality and safety of the goods that come into the country. Technology is the key to this success. Supplier Management Systems centered around Food Safety and Food Quality become a crticial factor in ensuring suppliers’ goods meet U.S. standards. Creating visibility into your supplier’s Food Safety system and enabling them to respond to Quality and Safety issues within your FSMS will ultimately reduce the number of safety events, and increase the ability for foreign suppliers to bring safe quality goods to the country.

Work Towards Farm to Fork Compliance:4. The FDA is looking to expand their regulations with some provisions specifically targeted at farms. This is either a good thing or a bad thing, depending on who you’re talking to. For those smaller farms, increased regulation and requirements may overwhelm. For others, it becomes a way to increase visibility into the “food chain” for their industry. Much like foreign suppliers, agri-suppliers will strive to adhere to the vendors food safety standard in order to keep the business, and vendors can utilize technology to incor-porate farmers into their FSMSs.

The question here becomes one of coordination. When it comes to “farm to fork” food safety compliance, where does the USDA, FDA and Department of Health hand off to one another? From what I’ve seen, there is very little cross-agency coordination. Yet, farm to fork compliance would involve all three—who’s in charge here?

The FDA needs to get on the GFSI Train:5. Like it or not, the FDA is not the sheriff in food safety town. That badge goes to the GFSI. GFSI Compliance schemes like Safe Quality Food (SQF), ISO 22000, Dutch HACCP, and British Retail Consortium (BRC) are being adopted by the largest corporations in order to meet the needs of consumers. Companies are requiring compliance to SQF in order to continue to do business with them. When a company represents 50% of your business, and they want you to jump—you jump. So, what is the FDA doing with the GFSI? They are listening, and that’s about it. In order to really be an effective regulatory agency, they need to work with the GFSI to fine-tune their regulations to be in-step with what GFSI is doing—this will help to better promote adoption and compliance.

There’s no magic bullet for the FDA in their journey towards Food Safety Modernization. However, they are staring down a 5-year plan that will face budget cuts, resource constraints, and the inability to execute on their promise. It’s time to think outside the box, and start looking towards technology to help ease the transition.

The Food Safety Modernization Act: Perspectives & Recommendations for Planning Your Food Safety Program for the FutureBest Practices in Food Safety

19 |19 |



Food Safety Management: SQF 7th Edition Takes a Unified Approach

Food Safety Management: SQF 7th Edition Takes a Unified ApproachBest Practices in Food Safety

The GFSI recently revised their guidance document to better address the needs of food safety in the marketplace. As a result, this required all GFSI-recognized schemes to adhere to the new guidance. SQF took this opportunity to re-evaluate their SQF 1000 and 2000 codes and decided to combined them into a single, holistic code, now titled “SQF 7th Edition.”

This new code streamlines the process of SQF compliance, and provides a “farm to fork” compliance regulation that incorporates the supply chain, and covers a broad range of industry sectors. So what are the big changes to the code? Let’s take a look:

Reformatting to GFSI and a Single Code1. : SQF has reformatted the numbering and order of the code to meet the new GFSI format, and combined the 1000 and 2000 standards into one. As a result, there are some areas that contain new elements and other areas that have moved to coincide with GFSI changes and the combined format. The important thing for food manu-facturers is to read the code thoroughly to understand what’s moved and what’s changed. SQF has put together a great change map to help companies with this.

Opportunities for Improvement Scoring is Removed2. : As part of the change, SQF removed the scoring for the Opportunities for Improvement section. However the scoring criteria has not altered very much; the deductions for nonconformance has increased, and companies still need to score a 96% or higher to receive an “Excellent” rating.

Mandatory versus Non-Mandatory Sections3. : As these two codes join up, there are changes to sections of this new code. As a result, some Level 3 requirements are now being made mandatory for Level 2 certification, and other new mandatory

sections have been added. Most mandatory sections remain constant, e.g, Management Policy, Document Control, and Corrective Action. One of the new sections include Allergen Management, which requires a register of export countries and their associated allergen requirements. It’s a good idea to take a look at the full list of what is covered, and where your organi-zation fits in.

Risk Assessment4. : One of the additions is the inclusion of a risk analysis for any exclusions to the code. The risk analysis is used to serve as a justification that food safety has not been compro-mised and needs to be documented prior to any SQF audit. Risk Assessment and Risk Management are not new concepts to SQF, GFSI, or any Food Quality or Safety system within the industry. It’s important to build risk and hazard analysis into all processes within your system.

As we begin to see the tightening up and streamlining of SQF, BRC, ISO 22000 and other GFSI schemes, we can start to see a cohesive set of standards that hopefully will provide some further guidance to the upcoming FSMA regulations. It seems the FSMA, while still getting budgeted out, will be taking a page from SQF and the other GFSI players. This is encouraging as not only do these standards provide a comprehensive and proven system for Food Safety, but the more coordinated government regulations and industry-governed regu-lations are, the easier it will be for organizations to implement.

20 |20 |



The Low Carbon Diet: Sustainability In Food Safety Management SystemsIt’s difficult to truly cover every aspect of your life in a green fashion. The key is to focus on those areas that have the most impact.

There was a period in time when “going green” was considered a fashionable endeavor for an organization. As the world began to come to the realization that environmental adverse effects will have a true economic impact, sustainability has become a hard reality. But many organizations are looking to understand where to focus their energy with respect to sustainable business.

The Food and Beverage industry has a lot to worry about in this sustainability theater. Most people expect utilities, oil and gas, and industrial goods to be high on the list. However, according to recent Gartner research, the Food and Beverage industry is third in Carbon Intensity Emissions (Tons of CO2-e/$ million in revenue), just behind Basic Resources and Utilities. This has labeled the Food and Beverage industry as “energy intensive.”

Greenhouse Gases (GHG) account for 20% of F&B emissions

Water Abstraction accounts for about 60% of F&B emissions

Other emissions (CO2-e, VOCs, etc) account for 20% of F&B

emissions

So how do Food and Beverage companies seek to reduce their ecological impact and start on the sustainability path? There are a few considerations:

Sustainability is Not Limited to One Department1. : The majority of organizations tend to lean toward the EHS group to solve their sustainable business initiatives. While this was once the trend, as sustainability becomes more of an organizational directive, more operational areas are being tapped to help. Sustainability teams now encompass Financial, EHS, Accounting, Purchasing, Compliance, and the like. Make sure that all aspects of the business are participating in the project.

Sustainability is Not Limited to the Environment2. : While many associate sustainability with the environment, this is only one slice of the pie. Social and Corporate Sustainability round out the sustainable business.

Set Sustainability Goals3. : This isn’t as easy as it seems, since there are many areas to focus on. Just reporting on your green strategy isn’t enough—you need to identify your goals. Set Envi-ronmental Objectives and Targets and seek ways to improve. The collection of data is your measure of success, not your ultimate goal. Ask yourself:

What are we required to report on? (regulations, laws, etc.)

Where are our biggest offending areas? (water waste, carbon,

etc)

Why are we adopting a sustainability plan? (Competitive

Advantage, Business Value, Regulatory, Ethical, etc.)

How much does our Supply Chain factor into sustainability?

Incorporate the Supply Chain4. : The Food and Beverage industry has one of the largest impacts when it comes to supplier foot-print. Apart from the Oil and Gas industry, Food and Beverage has the second largest emissions within their supply chain. With multiple supplier tiers and managing the logistics of moving goods from farm to fork, maintaining a sustainable supply chain is a daunting task. But without considering your supply chain, you are only accounting for 20% of your total ecological impact.

Invest in Solutions to Help You Make Sense of it All5. : Excel spreadsheets are great, don’t get me wrong. In fact, 30% of you are using Excel to manage sustainability right now. However, when adopting a sustainability strategy that coordinates the supply chain, sets long-term goals, measures reporting against those goals, and attempts to make sense of a mountain of data, you need an enterprise system. Much like an Integrated FSMS, the data that comes in is aggregated and normalized, providing a high-level picture of your sustainable business.

These are just some quick items to get the ball rolling. The Food and Beverage sector has always been concerned with providing clean, safe, quality foods. Sustainability is another element to that mantra—providing environmental value. Consumer perception is a key piece to this puzzle, and responding to your customers with a sustainability message is becoming a common theme. Food Safety and Food Quality are growing topics in the industry and within regu-lators. Whether it’s implementing one of the GFSI schemes, getting the latest FSMA updates, or just evaluating the best practices solu-tions on the market, the concept of Food Safety Management is at the forefront of the discussion. It seems that with each new trend and development that comes into view, the complexity tends to grow along with it.

The Low Carbon Diet: Sustainability In Food Safety Management SystemsBest Practices in Food Safety

21 |21 |



All I Need to Know About Food Safety Management I Learned in KindergartenFinal Thoughts: Fun Takes on Quality Management

All I Need to Know About Food Safety Management I Learned in Kindergarten

Today’s FSMSs follow common frameworks. Whether you are following the GFSI Schemes or internal best practices, you need to have a system in place that will outline your processes and prereq-uisite programs, control the procedures, and provide methods of enforcing them. Having a good Document Control system and Training Management system in place will not only centralize your processes, but ensure that the most recent processes are being followed. Integrate this with training, and you can automatically train employees on new procedures as they are released.

Stay Clean and Tidy : This can be interpreted several ways. On the one hand, having a HACCP Plan in place will enable your orga-nization to identify any potential hazards—sanitary, biological, or chemical—and take steps to control them. Having an auto-mated HACCP program helps to identify these hazards, do a risk assessment, and take steps to control the potential hazard. The other way to stay clean and tidy is in centralizing your data. Having an enterprise FSMS enables you to centralize your data in a single, normalized database. In other words, it keeps your data neat and tidy in a single environment.

Work Together to Solve Problems : If you encounter an event that has an adverse effect on food safety, you need to be able to solve that problem quickly, efficiently, and correctly so as to avoid future events. Having an integrated Food Safety system with Corrective Action provides a systematic way of identifying adverse events, pulling information from other areas within the organization (Complaints, Audits, HACCP, etc.) and correcting those problems. By taking a systematic, risk-based approach, you can even mitigate future recurrence of adverse events.

Learn to Share : Data from one aspect of the organization is valuable to other areas of the business. Having a Food Safety System that integrates at the module or process level will allow you to inherit data, create visibility into events, and make better deci-sions based on multiple points of data. Look for systems that not only integrate best practice modules, but also integrate with other business systems. The more data is shared amongst your different processes, the more likely you are to be able to quickly and effectively manage food safety within your organization.

Communicate : Visibility into the system’s data is a key component of an effective FSMS.

Having the data in your system is not useful unless you can interpret it and analyze it to foster change to your food safety program. Having a robust reporting system helps to commu-nicate the data and uncover trends, which will allow the orga-nization to make better decisions and really leverage the tech-nology to make continual improvements to food safety across the enterprise.

Of course, there’s much more to implementing an FSMS, and many facets to consider, but when you break it down to its simplest form, you can ensure an effective FSMS with the basic rules we all learned when we were young.

[email protected]

800.354.4476516.293.0949

THE FOOD SAFETY GUIDEBOOK EtQ, Inc. - WordPress.com · 2015-08-03 · THE FOOD SAFETY GUIDEBOOK...

Documents

Transcript of THE FOOD SAFETY GUIDEBOOK EtQ, Inc. - WordPress.com · 2015-08-03 · THE FOOD SAFETY GUIDEBOOK...