Process Development and Manufacturing Need To Be One Team

PhM – One thing we hear about is how compartmentalized and siloed the typical drug company is. How can you implement QbD when the individual teams aren’t really communicating with each other and sharing data?

JN – A lot of different disciplines and compartments take part in drug development… Process development and manufacturing need to be on one team.

One of the problems that made this difficult to achieve is that there has been an absence of technologies that allow people to function as a team across disciplines. They have different IT abilities, for example, ability to write sequel queries… or to do data analysis.

The central language of collaboration is that data. From FDA’s perspective, a drug company makes three products: the drug, the process and the data that go with it. 

Today, there is enabling technology that allows people to get data from multiple sources anywhere in the world at their desktop without writing sequel queries or command line, regardless of IT background.

PhM – But how much of this is an IT vs. an organizational issue? We still hear of “throwing process over the wall.” Is management support and education required?

JN - We recently did a survey on the AMR web site; there were about 35 companies who answered. We asked, “At what stage is QbD at your company?” Most people said their companies were at the “ideation and visioning” stage. Which disciplines and functional areas within your company are involved? The answer to that was satisfying: Quality, process development and manufacturing.  That’s what you expect, since those three need to collaborate to make this happen.

But we had disappointing results in response to the question, “What is the greatest barrier to moving QbD forward?” The most frequent answer was “too many other higher priority things to do.”

PhM – If QbD can reduce cost of quality by billions of dollars… is management too focused on short- term financial goals? What needs to change?

JN – There’s a cultural aspect. It hasn’t been in the culture of the pharmaceutical industry to do what FDA and consumers want them to do. There’s a change process that’s going on for that. But there is a business case for QbD, so when I see that it isn’t at the top of priorities, I can only suppose that there’s been a failure to articulate the business case, or that the business case has not been fully examined. If it is examined, it should be top priority. 

PhM – A lot of people think of QbD as a drug development or R&D function. Is there a perception that manufacturing doesn’t need to get involved?

JN – You’ll often hear people say QbD when they are really talking about design of experiments (DOE), but DOE is really only one component of QbD. A lot of what it takes to do QbD well comes from tapping into the experience that you already have, on processes that you’ve already run. There’s a loop going on. There’s information and enabling data that moves from process development to manufacturing, but experiences learned in manufacturing must feed back into process development so that process development specialists are aware of constraints and performance criteria that must be met in order for that next process to succeed during startup and commercialization and scaleup later on.

That’s another reason why there’s a need for one team. There needs to be a back and forth flow of data, of information, of science. Design for manufacturing info flows back, design space info flows forward, and all of it together is QbD.

PhM – How can drug companies avoid “reiniventing the wheel” and ensure that they’re getting all the info they need, but that it’s not horrible to manage?

JN – At the lowest level of pyramid is data; it’s either on or it’s off. In and of itself, it’s not that useful. It’s useful if you can take action on it. Data with a context is information. That is useful. You need to understand the context of data, for example, the temperature is 59 and increasing, but the spec is 62; now we can decide to reduce the input of heat to avoid exceeding specs.

The next level up is knowledge. Knowledge is the experience of having used information and taken action and embodied it. You often hear it referred to as instinct, or “I feel like this.” It’s embodied information. An individual professional is an embodiment of information and a knowledge vessel, but when people move from job to job, they usually take that information with them. What hasn’t happened yet is knowledge management.

The goal that most companies have is to institutionalize knowledge in the company as well as in individuals, so when people leave, the company doesn’t have to reinvent the wheel. Libraries are just a crude beginning.

When we log, track and keep audit trails, we don’t include the wisdom components. SNAFUs develop because it’s so cheap to collect and store data. We need access to it in order to be able to turn it to information by adding context. Then, we can build knowledge and wisdom and instinct, and that’s where we avoid problems.
At many companies, the first step beyond the data world hasn’t yet been taken.