Tag: knowledge management

Knowledge management as continuous improvement

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.

Knowledge management Circular_Process_6_Stages (for expansion)

To breakdown the process:

  1. 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
  2. Assess what is valuable, what needs to be transferred
  3. Share this knowledge, and make sure others can understand it
  4. Contextualize into standard tools (job aids, user guides, checklists, templates, etc.)
  5. Apply the knowledge. Train others and also update your system processes (and maybe technology) to make sure the knowledge is used.
  6. 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.

Deep expertise, quality culture and the long road

Dr. Zeynep Tufekci, a professor who writes about the social impact of technology, wrote and excellent Op-Ed in the New York Times this past weekend titled “What Elon Musk Should Learn From the Thailand Cave Rescue.” In this she takes to task silicon valley, stresses the importance of hard-earned expertise and the “safety culture” model. A topic near-and-dear to my heart as a quality professional, as she stresses the importance of deep expertise, lengthy training and the ability to learn from experience (and to incorporate the lessons of those experiences into future practices) as a valuable form of ingenuity.

Safety culture = quality culture. It has been said many times that the only real difference is that of the question asked (patient safety vs employee safety), but lets all agree that the tools used are pretty equivalent.

What this article really reminds me of is an article from A Lean Journey back in February titled “Lean Culture: Do You Want Firemen or Farmers in Your Organization.”

I see this a lot in Lean, especially early in the transformation process. An idea that any expert is equivalent, that quick, fast wins are the best. Which is sometimes relevant, often not good for the long run. Its interesting that we are, what, 30-40 years into Lean as a management methodology in this country (my entire adult life I have been involved in Lean projects of one sort or another) and it still feels new in most places.

I think that the trends Dr Tufekci and Mr McMahon are discussing are very similar. Stem from similar causes, and probably lead to why a lot of long-term transformations don’t get the benefits we intend.

International Council of Harmonization Q7-Q14

The Pharmaceutical GMP Professional certification from the ASQ body of knowledge has, as its first area, Regulatory Agency governance, as it should, as a solid understanding of not only what the regulations and guidances say is important, it is pretty important to understand the why, and how they work together.

The subsection Regulations and Guidances states: “Interpret frequently used regulations and guidelines/guidances, including those published or administered by the Pharmaceutical Inspection Convention and Pharmaceutical Inspection Cooperation Scheme (PIC/S), Health Canada, the World Health Organization (WHO), the International Conference on Harmonization (ICH), the European Medicines Agency (EMA), the Food & Drug Administration (FDA), the USDA 9CFR, the International Pharmaceutical Excipients Council (IPEC), and Controlled Substance Act (CSA) 21 CFR 1300. (Understand)”

The ICH is on my mind this week as I’ve had a few different conversations with folks as part of development conversations and other places about understanding regulations, and this post is my jotting down a few thoughts for future development and thought.

I am focusing on Q7 to Q14 (Q7-Q11 are published, Q12 in draft, Q13 and Q14 just recently announced). There are other Qs and there are certainly other aspects of the ICH, those just are not what I am interested in here.

Q7-Q14, in many ways, involves the development of a philosophy between the ICH member nations and the various observers. Like any harmonization and guidance process, it has a few difficulties, but the developing philosophy has been developed to establish a more proactive and risk-based approach to the industry. As such, being well versed in the principles is good for a pharmaceutical quality practitioner.

Quality trio ICH

Q7

ICHQ7 “Good Manufacturing Practice Guide for Active Pharmaceutical” was a fairly late product of the ICH. Founded in 1990 it was not until 1998 that it was determined that a GMP document was needed. It took another 2 years to complete and then another year or two for adoption by the member nations of the time. Which for the ICH is rocket speed.

Q7 is basically a solid list of what makes a functioning pharmaceutical quality system. Its the great big giant check-box of stuff to make sure you have. Personnel Qualification! Check! Production Controls? Check! Cleaning Validation? Check (well….)

Q7 covers API and has a great table on page 3 that covers applicability for types of API and the increasing GMPs. That said, Q7 is pretty much a great stopping place for anyone evaluating their quality system in a GMP environment. Most of the principles are universal, for example stating about master production records “These records should be numbered with a unique batch or identification number, dated and signed when issued. In continuous production, the product code together with the date and time can serve as the unique identifier until the final number is allocated.”

The Q&A released for Q7 in 2015 is telling. It is either all narrow specifies (including a definition of terms) or it is “Can I use risk management with X”, such as “To what extent can quality risk management be used in establishing appropriate containment measures to prevent cross-contamination?” To which the answer is basically “That is why we wrote Q9”

A good document to have around when setting standards.

Q8

ICHQ8 “Pharmaceutical Development” is the place where quality by design really starts coming into its own a solid concept. Finalized in 2005, it started being adopted in 2009/2010 (with Canada adopting it in 2016).

Q8 is all about setting forth a systematic, knowledge-driven, proactive, science and risk-based approach to pharmaceutical development. And at its heart, this is the philosophy that these ICH guidances rest on.

Q9

ICHQ9 “Quality Risk Management” was finalized in 2005 and quickly adopted in 2006 (except in Canada). This guidance pretty much recognizes that nothing the ICH was going to do would work without a risk-based approach, and it is arguable that the pharma industry might not have been all on the ball yet about risk. Risk management is without a doubt the glue that holds together the whole endeavor.

Q10

Q10

ICHQ10 “Pharmaceutical Quality System” was finalized in 2008 and adopted from 2008-2010 (except Canada). Q10 lays out a quality system approach that, based on a science and risk-based approach, establishes 4 pillars: Process Performance and Product Quality Monitoring; CAPA; Change Control; and, Management Review. Your welcome pharmaceutical industry, the ICH has now told you how to do your job and after Q10 we are getting serious about figuring out how to get ready for new technologies and be nimble and stuff.

The Pharmaceutical lifecycle is set out in 4 phases: Pharmaceutical Development, Technology Transfer, Commercial Manufacturing and  Product Discontinuation; with the requirements of each pillar being explained at a high level for each phase.

Knowledge management gets poked at as a key enabler.

Q9 and Q10 together basically set out to demonstrate just how to do the things that are a requirement in order to have quality by design (Q8) but also show how to move from Q7 to a proactive, risk-based approach to running your pharmaceutical lifecycle. We are moving from a set of discrete compliance requirements (which Q7 is sort of a bow-tie around) to a comprehensive quality systems approach over the lifetime of the product to establish and maintain a state of control and facilitate continual improvement. Breaking down silos this approach united product development with manufacturing, with distribution. I feel almost like I am having a mystic experience when I contemplate what this path we are on can do. Because frankly, we are still on the path.

Q11

ICHQ11 “Development and Manufacture of Drug Substances” was finalized in 2012 and adopted in the next 4 years. This is a bow guidance as it shows how to implement Q8, with the support of Q9 and Q10. This is based on six principles that stem from the three previous guidances: Drug-substance quality linked to drug product; Process-development tools; Approaches to development; Drug-substance CQAs; Linking material attributes and process parameters to drug substance CQAs; and, Design space.

Q11 is our blueprint, drug substance manufacturers. Others can learn a lot of how to implement Q8-10 through reading, understanding and internalizing this document.

Q12

In November of 2017 the long-anticipated draft of ICHQ12 “Technical and Quality Considerations for Pharmaceutical Product Lifecycle management” was published. Q12 provides a framework to manage CMC changes across the lifecycle of the product. In short, it utilizes Q8, Q9, and Q10 and says if you do those things then here are how post-marketing changes will work and the expected regulatory benefits. Which means getting changes to market faster. Knowledge management is expanded upon as a concept.

Q12 enshrines established conditions, which is a term that wraps a few QbD concepts and provides a regulatory framework. Still, in draft, there is a fair share of controversy (for example, the EMA can’t adopt it as is it appears) and I am certainly curious to see what the final result is.

At this point we have: Q7 – summary of GMPs; Q8 – QbD; Q9- risk management; Q10 – quality systems; Q11 – a roadmap for drug substances; and in draft, Q12 – lifecycle management.

The ICH primary exists as a way for regulatory bodies to align and work out the thorny issues facing the industry. The process is not perfect, but it’s much better to be involved then to ignore.

Q13 and Q14

This last June the ICH met and, amongst other things, announced the roadmap for what is next:

  • Analytical Procedure Development and Revision of Q2(R1) AnalyticalValidation (Q2(R2)/Q14)
  • Continuous manufacturing (Q13)

Q2 is desperately in need of revision. It was finalized back in 1996 and does not take advantage of all the thought process expressed in Q8-Q11. Apply QbD, risk management, and quality systems will hopefully improve this guidance greatly.

Q13 appears to be another in the line of how to apply the Q8-Q10 concepts, this time to everyone’s favorite topics – continuous manufacturing. Both the FDA and EMA have been taking stabs at this concept, and I look forward to seeing the alignment and development through this process.

I look forward to seeing formal concept papers on both.

Learning Culture

Over at the Harvard Business Review there is a great article on 4 Ways to Create a Learning Culture on Your Team. A learning culture is a quality culture, and enabling a learning culture should be a key element of a robust knowledge management system.

Frankly, this is an attribute that I think needs to be better reflected in the QBok, as it is a core trait of a successful quality leader. And supporting learning is a core element of any professional society.