Optimizing yield in pharmaceutical fermentation presents unique challenges for data-driven modelling. Batch cycles span several days, with process parameters changing continuously in real time, while final API yield is measured only at the end of the batch. This delayed feedback prevents in-process correction and limits the effectiveness of traditional real-time control methods. Complex interactions among variables, combined with limited historical batch data, further create a high-noise, data-scarce environment that constrains conventional modelling approaches.
This paper presents a structured machine learning approach, built in JMP, to investigate the causes of fermentation yield decline and to identify strategies for yield recovery and optimization in a pharmaceutical bioprocess. To address the delayed-outcome problem, the fermentation process is divided into discrete temporal stages, enabling stage-wise analysis of process behaviour. This staged structure links parameter performance at each stage to the final yield outcome, creating surrogate indicators of batch health that can be monitored before the batch concludes.
Historical high-yield batches are benchmarked against underperforming batches using descriptive statistics, distribution analysis, and process capability studies to identify critical deviations. Key parameters, including feed rates, fatty acid concentrations, pH, dissolved oxygen, dosage variables, and raw material consistency, are analysed individually and in combination. Quartile thresholds and inhibitory limits are established to define actionable control ranges for each parameter.
Three machine learning models, linear regression, CART, and random forest, are applied within an ensemble framework in JMP, followed by experimentation using a Bayesian optimization approach. Together, these models capture linear trends, interpretable decision rules, and nonlinear interactions to identify optimal operating ranges, replacing trial-and-error experimentation with a data-driven, systematic approach to process optimization.
The stage-wise ensemble approach successfully separated the process signals driving yield decline from normal batch-to-batch noise, and identified clear, actionable operating ranges, quartile thresholds and inhibitory limits, for feed rates, fatty acid concentrations, pH, dissolved oxygen, dosage variables, and raw material consistency at each fermentation stage. Batches operated within these stage-specific ranges showed measurably higher and more consistent activity than historical underperforming batches, and the Bayesian optimization step further refined the recommended operating points beyond what the tree-based and regression models alone identified, converging on near-optimal conditions without exhaustive additional experimentation.
A central goal of this work was democratization: turning a modelling exercise that would typically require a dedicated data science team into a workflow that process engineers and operations personnel can run and interpret themselves. By packaging the staged benchmarking, ensemble modelling, and Bayesian optimization entirely within JMP's interactive platform, the analysis and its outputs, control ranges, stage-wise recommendations, and a Profiler-based digital twin, are directly accessible to the people who run the fermentation process day to day. This shifts yield optimization from a periodic, specialist-led project to a continuously available, self-service capability, and offers a template that other JMP users can apply to their own delayed-outcome, high-variability processes.

Hi, everyone. This is Anurag Seksaria. Today, I will be talking about my experiences of analyzing data for pharma industry, specifically using JMP. This particular case study is on improving yield in pharma industry, and while we are improving, also how we can provide an approach which can be used by the operations team and the process can be democratized. Whenever we are improving efficiency, obviously, it's given that we maintain the quality and other parameters in a pharma industry.
This case is regarding bulk pharma, and the complexity here is that the process parameters are maintained on real-time basis, almost for 300 hours, but the yield comes out only after completion of the fermentation process. I will talk about it more in detail. Another complexity is that there is a high variability in the raw material. Sometimes, these are agri products, which have variability and cannot be validated at the incoming stage.
For this particular project, which I am presenting today, we have used the U-OSEMN method created by Hilary Mason, surprisingly, a few decades back, on how to carry out data analysis. Under U-OSEMN, we understand the business requirements, so I'm going to talk about the complexity and current state and what was the target. Obtain and scrub data: data, as I said, had a lot of noise because you have 400 hours of data and multiple parameters, so how did we scrub and clean the data, make it usable?
Then coming to explore, I will be sharing some examples about how the JMP graphical analysis was used to understand the data better. Finally, model, three approaches were used here. One is the basic regression, then CART, and then, finally, Bayesian experimentation techniques. Interpretation and deployment, we have some results also here. Of course, it's not a single case study. It had been my experience over last 3, 4 years, working with multiple pharma companies.
Quick overview of the process without getting into too much of technicalities. It is a fermentation process, so where medium is prepared. Then our focus is maintaining the condition, things like pH, temperature, oxygen, carbon, nitrogen, feed. Hereafter, I will be calling them X1, X2, X3, and the output I will be calling as Y1, Y2, Y3.
Here are the set of parameters. Some generic ones I have put with name, and hereafter, as I said, we will be calling them X1, X2, X3, so pH, temperature, carbon sources, nitrogen sources, fatty acids, and things like that.
The point I was telling is we are interested in the end of fermentation yield. However, the process parameters change on real time. What we did is we found out intermediary parameter, fermentation activity, which is directly related with yield, comes out at the final stage.
Moving forward, one of the complexity in data science is interrelationships between parameters, and we had enough of it. We had confounding or interaction effects, so carbon and nitrogen sources interact. We decided to go with C:N ratio rather than going with carbon and nitrogen separately. We also had a sequential parameter. The feed, certainly, its impact is depending on how much of activity is already there in the residual. At 10 hours, 50 hours, 100 hours, 300 hours, the activity will be different, and it will impact. We have taken a combination of feed and residual to get to the relationship between inputs and outputs. Finally, we have converging parameters also, where both are impacting equally, and we had to maintain balance between these two.
Coming to the performance data, too much of information here, but I will try to explain. On X axis, I have the log hours, as I said, 300 hours batch. On Y axis, we have the activity. As the hours go by, the activity increases. The red one shows the bad batches or low yield batches. Yellow one shows the medium yield batches, and the green one shows the good yield batches. If we are able to optimize this Y1 activity, we are sure we will be able to get better yield.
One more challenge was there. We tried doing regression and classification trees and data partitioning using this data, but we found there was a lot of noise because, as you can see, the slope is changing at every stage in between. What we decided is to divide this data into four zones. Of course, we were open to divide in three, two, or seven zones also, but we used regression to find out the rate of change and split data into four broad categories: start, which is from here to here, around 72 hours or so, initial stage, 72 hours to 140, and intermediate, and then final stage. Data was divided into four stages, and the optimization was done separately for each of the stage.
This just shows the regression models which we built for good batch at every stage to decide what should be the level of split. This shows how the activity is increasing with stages. While there is an overlap, there is a statistically significant difference also, both in averages. The nuance was that there is a significant difference in variation as well. If we see here, the variation is much lower as compared to the final stage.
Moving on further, as I was talking about exploring data, and this is one thing which I had been liking, and in JMP, it had been evolving over a period of time: our ability to put multiple factors on one graph using the graphical interface. Here there is one variable X3 with Y and stages. We tried to visualize, is there a difference in the X3 variable optimal at various stages. We see that at the initial stage, probably this is the best level. At the final stage, while this is the best level, this also can be if we can make the variation lower. This was studied for each and every variable to get deeper understanding. This is a stage we also are able to discuss with ops teams and understand their reactions on each of the parameters. While working as a data scientist or an analyst with the operations team, this stage helps quite a lot.
Moving on, we went to tree, doing the partitioning. Again, this is a tool which gives good visualization and a very in-depth analysis together. Regression also gives good understanding, but this is better understandable or explainable to the operations team. We arrived at the optimal combination. Of course, it is a partial view just to show how it was done, and you can see the activity is increasing as we are going down and down. Almost five or six level of data partitioning was done. We use random forest, we use regression trees, and then found that regression tree is more explainable, and hence we went with regression tree rather than going with random forest.
Tree also gave us the feature importance, which features are important. There were some six or seven. I have shown four here. We also built the Profiler. Optimal was done through the tree analysis and then through Profiler, and then we fine-tune what can be the best level. Post coming to this level, as I mentioned in the beginning, the raw material variations are there, and we don't have a choice of asking for raw material with certain parameter.
Picking up from here, we tried doing some experimentation: full factorial, fractional factorial. Taguchi wasn't an option because these are large plants, or even if we take in lab scale, these are long-duration process. It would have taken more time. We used Bayesian approach and split the experiment at multiple stages with multiple approaches. This was almost a 6 months exercise working with multiple people in the team and doing experiments, validating result. Of course, a lot of change management and conviction involved in all the assignments which are done in this area.
Finally, we were able to log in, on an average, 5% yield. We would have done around, in four, five companies which I'm working for, a few hundred experiments of this type, and we will see 50–60% improvement or 50% success in the projects. Finally, as I was telling, we wanted to democratize the whole initiative, not doing one time and then trying after some time. We did Bayesian experiment. Of course, the feed for experimentation is coming from exploratory analysis, from the tree diagram, from regression. We arrived at optimal conditions, then we built predictive models, then we linked it to the daily dashboards, which provide recommendation on a live basis, sort of digital twins. Continuous monitoring and improvement can be done by operations team.
This is what I wanted to share, and looking forward to the Discovery Summit 2026.
Presenter
Skill level
- Beginner
- Intermediate
- Advanced
Skill level
- Beginner
- Intermediate
- Advanced