Summary
- Capa, Deviations, Quality Events
- CAPA and Deviations
- New QMS? Pay attention to these keys success factors!
- Validation of the Imaging Technology for a novel microbiological colony counter
- Barrier Technologies & Revision of Annex 1: requirements & operational responses for manufacturers
- GMP Annex 1 and Lyophilization
New QMS? Pay attention to these key success factors!
That’s it, Valerie, group quality director has gotten the budget, she will finally be able to implement a QMS in the company! No more “Change Controls” that are implemented before having finished all blocking actions. No more deviations opened with 2 words and an end to actions hanging around in the system since 2016!
In her new QMS, Valerie has thought of everything! With her group quality team she has constructed all the processes from A to Z – deviations, CAPA, CC, customer complaints, document proofreading flows and so on. Finally her dream is set to become a reality; the sites will be obliged to work correctly! The integrators have facilitated her task. With their experience of deployment on numerous sites, they have had her make several changes that will make the system more effective, while considerably reducing the time frames for adjustment.
Conscientiously, she sent the processes of the future system to all the quality system managers of the other sites by email. She has not had as much feedback as she would have hoped for and some others have been rather pessimistic, but that must be down to fear of change!
The integrators assured her – reporting would be automatic! No more time lost in compiling data across the group! Management will no longer be necessary either because everyone will have a list of tasks on their home page that is transmitted automatically by the system! The dream! Everything will change, everyone will be able to focus on their activity!!
The implementation team has chosen to launch the most used systems at the same time: deviations, CAPA and document management. Data recovery is difficult but happily the trainees are there to check that the data matches!
6 months later
When the “go live” was given, users saw their dashboard gradually filling up with hundreds of tasks to be completed. It was impossible to prioritize anything. Not knowing which sectors were handling which tasks, all QA could intervene on all systems by substitution. Very quickly all process management got behind schedule. Numerous control and dual control steps having been added, tasks were lost at the far end of interminable lists.
You have perhaps experienced all or part of this short description. The problem is deliberately exaggerated for the purposes of the article, but it is not so very far from the truth. The rest of this article presents the autopsy of Valerie’s project and offers more effective alternatives.
1. You are your own worst enemy
OK, so you have the experience. You have known many systems, you know the strengths and weaknesses of these systems and you have constructed the perfect system in your head. But unfortunately for you, you will not be the only person using this system. You must also consider that on your own, you cannot have all the constraints that affect your systems in your head. Do not be a victim of ivory tower syndrome.
The implementation of a QMS should not revolutionize your processes completely. Make them clearer and more reliable certainly, but changing everything seems very utopian. The human dimension must be taken into account. Remember that users will have to deal with a new system and new processes.
Your desire to implement your system, rather than the best system for users, runs a high risk of greatly slowing deployment, even of killing off the project. A successful project is also measured, above all, on its acceptance by users. They must be supportive.
When you launch a QMS project, you must have factual convictions with regard to the objectives of the system, but there are users that will help you construct the processes, define the data and the indicators to be used.
Make sure you have quantified objectives, it is for the people working with you to explain to you how they hope to achieve these.
Run modeling workshops with more enterprising practitioners who use the systems every day.
Embed the framework and the boundaries of your project in your company and its culture, they will be your common thread in conducting your project. Look for a balance between the ideal and the rational system. For example, what level of responsibility is expected from those involved (flexible system or blocked/limiting)? or what is the degree of customization of your QMS. Bear in mind the purpose and the challenges.
2. The integrators are not your friends but nor are they your enemies…
Before even thinking of doing anything, you need to understand how your site(s) operates. You must model your processes with mapping to show who does what and when? You must be precise and stick as close as possible to reality. Define the inputs, outputs, contributors and deliverables of each step.
Once this is done, you must standardize practice across all sites, taking care to comply with regulatory requirements.
Keep it simple and empower the players, instead of constructing an ultra-locked system in which bypasses will soon appear.
Bear in mind that you are constructing your QMS, which will integrate perfectly into your company and not “a QMS” (we want to develop added value). You must incorporate the conditions of your company and your objectives. What do you expect from your QMS?
Without this precious map, you will not be able to put together your URS to select the best QMS supplier, worse, you will be convinced by the publisher that certain solutions are the most appropriate for your needs (which you do not really know).
As Bill Gates said “I always choose a lazy person to do a hard job. Because I know they will find an easy way to do it.” In other words, if you don’t know what you want, you will find yourself with the solution that is the easiest to develop for the integrator. The system must adapt to the processes and not vice versa.
Watch out for the apparent flexibility of the solutions proposed. If the solution is flexible, you will be encouraged to create exceptions. Your aim is to have a clear, uniform process across all of the site or the group. Making exceptions will make the system pointlessly complex and extremely difficult to maintain. For this reason the process modeling and standardization phase must not be overlooked. Think of your QMS as a cane, it must be sufficiently robust to help us move forwards but it must not walk in our place.
Working as a team and relying on the expertise and experience of your integrator, specify exactly what you want.
Come with the “what” (what you want), present it and discuss it with your integrator to define the how. Then, deal with the direction of your QMS together.
3. The QMS is not a steering tool
If you are sold a QMS as a miraculous tool that will let you meet your deadlines routinely, the truth on the ground will call you sharply to order.
The QMS is a program, it knows no mercy, forgets nothing and pardons nothing. The tasks will pile up on the Dashboard and everything which does not block the flow will slowly become invisible, hidden behind day-to-day emergencies. The first to suffer will be the CAPAs, the SOP approvals and “change controls” (who does not have a backlog in at least 2 of these 3 processes?)
Think of a QMS as cupboards in your kitchen. At the start you know exactly what is inside and as time advances, the more the things that are never used get pushed to the back. When you move home, you always find a can of sauerkraut that has been out-of-date for 3 years, strangely-shaped Tupperware boxes of impractical sizes, or bizarre knives for slicing tomatoes.
In your reflections on the construction of your QMS, it is imperative to include the “data” dimension and its operation. Which data will be useful? What management rules? Which source of integration into my company and its ecosystem? To do what? How to reach the data and extract it rapidly? How should it be classified? Your QMS will very quickly host thousands of data items that you must use to optimize your activity. These questions are central and must influence the construction of your QMS.
To overcome this, you must do 4 things:
- Define the sectors in order to share out ongoing work for the different processes evenly. The process will have a much greater chance of being completed if the person responsible is clearly identified and notified. (Player targeted: process completed).
Plan in advance for extractions that allow all necessary information to be obtained, characterize ongoing work for the different processes and divide it between the different sectors. The expectations for use of data and processes must be included in the design.
Put in place steering (visual, preferably) for each of the processes and sectors based on QMS extractions. This is a support tool for facilitators in the field.
Appoint process owners: persons responsible for maintaining the process in the system (call to order users who do not complete the fields correctly, check that the control points function well and propose adjustments). I would strongly advise placing this responsibility in the job description. This is not a small responsibility, but effective system managers will prove of great benefit for your organization and your cycle time.
Note that the more complex the system process, the greater the task and the risk of deviation: (Change control > deviation > CAPA >document system)
It is here that your convictions mentioned in the first chapter will be useful. They will allow you to define the quantified objectives that you will give to your collaborators through the steering tools.
Process configuration is a crucial moment. It takes place after the choice of the software that will be used and before roll-out. It is during this step that the project team will constrain the software to follow the process (and not the reverse) taking account of the constraints accepted during the choice of the latter relative to other solutions. The system is a support for structuring the work, but the quality of analyses and of the content depends on the users.
The starting point is the purpose. A QMS is a data management tool whose aim is to construct an application to provide the right data, at the right time and to the right people.
The most important thing for successful configuration of different processes is the project team. They must be representative of users and have the legitimacy to lead the change. They must be composed of sector experts and not solely of managers. The team must genuinely master the challenges of the process in question, inputs, outputs, constraints and objectives.
Care must also be taken that the different roles of the project players and users are clearly defined and are not reversed during the course of the project. The risk being of adding modifications to provide comfort or those linked to individual fears which may ruin part of the work and endanger deployment.
The system designed must be maintainable and sustainable. The project must also incorporate correct system management during its life cycle.
The project must make sense to the teams. They will be working with this tool for at least ten years or so, and it is this configuration step that will decide whether using it will be misery or pleasure. And therefore, finally deciding on the acceptance or rejection of the solution.
Ultimately and simply, the definition of a process reminds us of the most important thing: correlated actions transforming input elements into output elements. The project team and the integrator must be focused on value creation within the processes implemented, all in the service of the company.
5. Successful roll-out
Roll-out is the culmination of the project. Users cease to use their old systems and will use the new one in their daily life. QA finally has a unique system, so ceasing to reconcile inconsistent data derived from multiple files. Finally, there is a single work database!
The keyword to successful roll-out is communication. Communicate the direction of your project to the users!
A project is an element of the company’s response to an identified problem. What was the fundamental problem? How should it be addressed? What are the functions of the software that allow this objective to be achieved?
Provide perspective. We are in the first stage of a long voyage that we will be taking together. Participate by passing on ideas for improvement, new needs, or quite simply during the setting up of new processes.
For peace of mind and a “quick-win” effect, favor a gradual start-up. Begin by implementing a process to get people united behind the project (a simple process, which was very poorly managed in the old system).
The success of the first process implemented will kindle the enthusiasm of users who will want more. This gentle start-up will avoid the “big bang” effect that generates stress and a loss of bearings that may impact business continuity.
Have you ever been subjected to an update that you have not requested, of software that you mastered perfectly? (Microsoft Word update jumping 3 or 4 versions, Windows 7 to Windows Vista, for instance). In such cases, we pass through several successive stages: shock, denial, anger, fear, sadness, acceptance…
The worst thing being finding yourself no longer knowing how to carry out everyday tasks which were so simple previously.
The most important thing is to provide support with a network of specialists (key-users). During initial training, carry out practical training with convincing examples and supplement these with individual support on the ground. The initial training is important in order to provide reassurance, but has very limited efficacy. The most effective approach is to learn by trying it out. The availability and responsiveness of these key users is essential in order to transition from the project to the production launch (hypercare phase) and a very effective addition to SOP or tutorial material.
At all costs avoid phrases like “anyway now this is how it is”. Anticipate any points of friction (you know them, they are the concessions that were made when choosing the software and standardizing practices to avoid exceptions). Supply a communication kit to explain why these choices were made. What were the constraints and how did you have to respond?
Focus on the positive points, the range of opportunities and the road traveled!
Conclusion
The implementation of a (new) QMS is a great moment for a pharmaceutical company. It must be synonymous with improved quality and performance. But these objectives will only be achieved if the project is prepared meticulously by competent people, and there is a perfectly mastered overall vision.
Process mapping, followed by standardization of practices, are probably the most important steps upstream of the project. They will allow you not only to select the best publisher but also to extract the critical points and performance levers of each process, while clarifying the players, deliverables and time frames.
Carrying out a project that fits the possibilities of the company rather than our own ambitions is sometime difficult, but this is why it is essential to have a good project team that is representative, competent, and has enough time allocated to it.
Keep in mind that a QMS problem can paralyze product release or lead to a formal notice and significatively impact quality performance. It is therefore crucial not to neglect the resources allocated to this project.
The QMS is the central application in the Quality system, a guarantee of trust and an essential support for successful inspections and effective quality. The introduction of a QMS is a marvelous opportunity, put all the assets on your side and enjoy the project!