Appropriate controls shall be exercised over computer or related systems to assure that changes in master production and control records or other records are instituted only by authorized personnel. Input to and output from the computer or related system of formulas or other records or data shall be checked for accuracy. The degree and frequency of input/output verification shall be based on the complexity and reliability of the computer or related system. A backup file of data entered into the computer or related system shall be maintained except where certain data, such as calculations performed in connection with laboratory analysis, are eliminated by computerization or other automated processes. In such instances a written record of the program shall be maintained along with appropriate validation data. Hard copy or alternative systems, such as duplicates, tapes, or microfilm, designed to assure that backup data are exact and complete and that it is secure from alteration, inadvertent erasures, or loss shall be maintained.
Kris Kelly over at Advantu got me thinking about GAMP5 today. As a result I went to the FDA’s Inspection Observations page and was quickly reminded me that in 2017 one of the top ten highest citations was against 211.68(b), with the largest frequency being “Appropriate controls are not exercised over computers or related systems to assure that changes in master production and control records or other records are instituted only by authorized personnel. ”
Similar requirements are found throughout the regulations of all major markets (for example EU 5.25) and data integrity is a big piece of this pie.
When building your change management system remember that your change is both a change to a validated change and a change to a process, and needs to go through the same appropriate rigor on both ends. Companies continue to get in a lot of trouble on this. Especially when you add in the impact of master data.
Make sure your IT organization is fully aligned. There’s a tendency at many companies (including mine) to build walls between an ITIL orientated change process and process changes. This needs to be driven by a risk based approach, and find the opportunities to tear down walls. I’m spending a lot of my time finding ways to do this, and to be honest, worry that there aren’t enough folks on the IT side of the fence willing to help tear down the fence.
So yes, GAMP5 is a great tool. Maybe one of the best frameworks we have available.
It’s often said that people don’t resist “change” so much as they resist “being changed.” So, the job of change management is clear: In a nutshell, you must explain why the affected people should want to change, and thereby cultivate readiness instead of resistance. What are some recommended strategies or tactics to help achieve successful change management?
My first piece, of advice, abandon the idea that change management only involves people. Just as all systems are made of people, organization, process and technology; all changes impact all four and need to be viewed holistically.
Second, get rid of the artificial barriers between change management and change control. Change management is the how of change – assess, handle and release. Change control is the what, the execution steps. Remember that all changes are really just projects, and vice versa. The level of change determines the level of activity.
Level of Change
Change Management
Change Control
Transactional
Minor
Few
Closely clustered
Operational
Major
Several
Across several areas
Transformational
Fundamental
Many
Iterative
Often in waves
Simplify your variety of change controls and strive for scalability within one change management (and control) system. Utilize the levers, which include: regulatory (compliance), product release and risk.
Knowledge Management
Change Management and Knowledge Management are closely entwined. An effective change management system includes active knowledge management, in which information from multiple sources is integrated to identify stimuli for changes needed to improve product and/or process robustness.
Specific – The proposal needs to be accurate and leave no doubt as to what the change will achieve.
Measurable – How will the system owner (sponsor) know when the project is complete.
Achievable – Make the change as small as possible after all it is easier to eat an elephant one bite at a time. It is far easier to manage a few smaller change than one big one. This is why operational and transformational changes are many changes and often iterative.
Realistic – Make the change easy to deliver, if it is over complicated then it is likely to hit problems and run over budget, be delivered late or of poor quality.
Timely – Does the change have to be complete by a certain date? If so put it in the scope that the project has to be complete by that date. Are there dependencies and independencies?
Evaluate
The change Project team leverages SMEs to harness the collective intelligence (synergy) for the benefit of the site.
Relevancy – The information gathered is of value
Reliability – The process by which the information is collected should be consistent
Accuracy – The data should be expressed in a manner that most accurately reflects its information content
Efficiency – The design and implementation of the tasks should minimize the burden
What people, departments and processes need to change in order to realize our vision?
How will we support people?
What actions will we do to support people through the change?
What is our plan?
Detailed action plan
Build in effectiveness reviews to your plan.
Implement
Execute the change plan, provide evidence of completion. Escalate significant risks or delays.
Close
Ensure change plan was executed and benefits realized.
Hold a lessons learned.
Conclusion
Change management is a system. It should have its own cycles of improvement and grow as you execute changes. Change is a fundamental pillar of a quality system and spending the time to build a robust system will reap dividends and prove itself a good idea again and again.
This past week the FDA issued a draft guidance “Post Approval Changes to Drug Substances” from the Center for Drug Evaluation and Research on post-approval changes for drug substances to provide clarity to holders of drug master files and holders of new and generic drug applications on which reporting category manufacturing changes fall into as well as the information required to support these changes.
Like any guidance this is supposed to “describe the Agency’s current thinking on a topic” and in this case this is a pretty important guidance as it is the first on the subject of change management published after the draft of Q12. It also clearly builds on the concepts of Q11 and is the first time the agency has published a guidance on drug substance post approval changes.
The guidance covers changes to facility; scale and equipment changes; specification changes to starting materials; synthetic manufacturing process changes; and, changes to the container closure systems for the drug substance.
It uses the traditional breakdown of major changes (prior approval supplement category), Moderate changes (changes-being-effected-30 (CBE-30) category) and Minor changes (annual report).
The guidance provides some solid requirements for risk assessments, and requires the risk assessment be included with the filing of change. This will require some companies to improve their risk management process, and may cause some to question decision making about their internal formulas for level of effort and the formality of risk management.
An effective change management system includes active knowledge management, leveraging existing process and product knowledge; capturing new knowledge gained during implementation of the change; and, transferring that knowledge in appropriate ways to all stakeholders.
Any quality system (any system) has as part of it’s major function transforming data into information; the acquisition and creation of knowledge; and the dissemination and using information and knowledge. A main pipe of process improvement is how to implicit knowledge and make it explicit. This is one of the reasons we spend so much time developing standardized work.
And yet I, like many quality professionals, have found myself sitting at a table or standing in front of a visual management board, and have some type of leader ask why we spend so much time training when we should be able to hire anyone with an appropriate level of experience and have them just do the job.
Systems are made up of four things – process, organization, people and technology. When folks think of change management, or root cause analysis, or similar quality processes and tools they tend to think the system is only about the activity we are engaging in. But change management (or root cause analysis or data integrity) is not that simple.
This is really two-fold. A person assessing a change is not just needing to be knowledgeable about how the change control process works, they need to be able to analyze the change to each and every process within the systems they represent, to understand how moving the levers and adjusting the buffers within this change influences each and everything they do, even it that’s to be able to make a concrete and definitive no impact statement.
So when we process improve our change management system (or similar quality processes) we are both improving how we manage change and how folks apply that thinking to all their other activities.
In less mature systems we end up having a lot of tacit knowledge in one person. You have that great SME who understands master data in the ERP and how changes impact it. In way to transfer that tacit knowledge to another person is a lot of socialization. It is experiential, active and a “living thing,” involving capturing knowledge by spending a lot of time with that person and having shared experience, which results in acquired skills and common mental models.
For example, my master-data guru needs to be involved in each and every change that might possibly involve the ERP or master-data. I might have reached the point where the procedure has large sections that give detailed instructions on when to involve the master-data guru in a change. The master-data guru spends a lot of time justifying no-impact. Otherwise, I might be having change after change forget to update master data. Which leads to deviations.
At this stage of maturity I’ve recognized I need a master data guru. I’ve identified the individual(s). Depending on maturity I either involve the master-data guru on every change or I’ve advanced enough that I have a decision tool that drives changes to the master-data guru.
So now either the master-data guru is becoming a pain point or we’ve had one too many changes that led to deviations because we failed to change master data in the ERP correctly. So we enter a process improvement cycle.
What we need to do here is make the master-data guru’s tacit knowledge explicit; we need to externalize this knowledge. We start building the tools that better define what never has impact, what always has impact, and what might have impact or be really unique. When a change has no impact, the change owner is able to note that and move on (no master-data guru involvement necessary). When it has definite impact the change owner is able to identify the actions required, knowing exactly what procedures to follow and how to execute those within a change. We still have a set of changes that will trigger the master-data guru’s involvement, but those are smaller in number and more complex in scope.
The steps we took to get here also allow us to more easily develop and train master-data gurus. Maybe we have a skills matrix and it is on development plans. Our training program now has the tools to allow internalization, the process of understanding and absorbing explicit knowledge into tacit knowledge held by the individual.
At this point I have the tools for my average change owner to know when to change master data and how-to-do it (this might not involve them actually doing master data management it is really knowing when to execute, and the outputs from and inputs back into the change management system) AND I have better mechanisms for producing master data experts. That’s the beauty here, the knowledge level required to execute change management properly is usually an expert level competency. By making that knowledge explicit I am serving multiple processes and interrelated systems.
To breakdown the process:
Capture all the knowledge. Interview the SME(s), evaluate the use of the system, gather together all the procedures and training and user manuals and power point slides
Assess what is valuable, what needs to be transferred
Share this knowledge, and make sure others can understand it
Contextualize into standard tools (job aids, user guides, checklists, templates, etc.)
Apply the knowledge. Train others and also update your system processes (and maybe technology) to make sure the knowledge is used.
Update – make sure the knowledge is sustained and regularly updated.
Change management has lots of inputs and outputs. As does data integrity and other quality systems. Understanding these interrelationships, and ensuring knowledge is appropriate, captured, and utilized, is a big way we improve and thrive.
Change Effective, implementation, routine use…these are all terms that swirl in change control, and can mean several different things depending on your organization. So what is truly important to track?
Taking a look at the above process map I want to focus on three major points, what I like to call the three implementations:
When the change is in use
When the change is regulatory approved
When product is sent to a market
The sequence of these dates will depend on the regulatory impact.
Tell and Do
Do and Tell
Do and Report
Change in use
After regulatory approval. When change is introduced to the ‘floor’
When change is introduced to the ‘floor’
When change is introduced to the ‘floor’
Regulatory approval
Upon approvals
After use, before send to market
Upon reporting frequency (annual, within 6 months, within 1 year)
Sent to market
After regulatory approval and change in use
After regulatory approval and change in use
After change in use
I’m using ‘floor’ very loosely here. “Change in use” is that point where everything you do is made, tested and/or released under the change. Perhaps it’s a batch record change. Everything that came before is clearly not under the change. Everything that came after clearly is.
You can have the same change fit into all three areas, and your change control system needs to be robust enough to manage this. This is where tracking regulatory approval per country/market is critical, and tracking when the product was first sent.
A complicated change can easily look like this (oversimplification).
Is this 1, 2 or 3 processes? More? Depends on so many factors, the critical part is building the connections and make sure your change control system both receives inputs and provides outputs. Depending on your company, the data map can get rather complicated.
Investigations of a Dog 