Announcer: You are listening to augmented ops where manufacturing meets innovation. We highlight the transformative ideas and technologies shaping the front lines of operations. Helping you stay ahead of the curve in the rapidly evolving world of industrial tech. Here's your host, Natan Linder, CEO, and co-founder of Tulip, the frontline operations platform. Natan: Welcome to augmented ops. Today we have Joel Fidalgo. Who is the CEO of next pharma? Joel, welcome to the show. It's great to have you. Thanks. So for those of you who don't know next pharma, from my perspective, I think the landscape of, uh, running operations in the CDMO is really challenging and like we will talk about that in a second here and next. Pharma has been leading the charge there. They've been adopting digital technologies for quite a few years now. And building a new type of production system. So very excited to have you on the show and kind of learn from you on how you all did it. Maybe as a first thing we do here, introduce yourself and a little bit about your journey. How did you become the CIO of next pharma? Joel: So almost 15 years back when I started my career in it. I started initially in a consulting business. Mm-hmm. Um, worked there across industries, mainly focused a lot of ERP and, but also enterprise architectural topics. Moved a little bit more into project management, project and portfolio management within it. After a while I had to feel, I need to leave the space of consulting and there was an opportunity with a US company or. Primary packaging material business within the pharmaceutical industry. That's my first starting point. I started there in a global role, one of the first ones within IT who had dual reporting lines, a company that developed from a little bit more local, driven to more global organization, and, uh, had a quite good journey at this company. Learned a lot across the globe. Um, yeah, five years back, just before, uh, Corona, there was a fantastic opportunity to become the CIO of next Pharma and start there, uh, leading the digital journey. Natan: So for folks who don't know a lot about next pharma, say a little bit about where the company's focused and what are the core services and products and where are you situated in the supply chain. I think it's an important context for before we dive in. Joel: Sure. So next Pharma is a a pharmaceutical CDO company, European based. Our journey, or our focus was to grow through m and a a lot, and we built a network of different capabilities. So we call our site center of Excellences. Mm-hmm. And we are more or less focusing in all kind of pharmaceutical production. There's only a few capabilities we don't serve today. But from all solids, semis, solids, liquids, hormones, non hormones, we have a very broad rarity of pharmaceutical products we help to develop, but also commercial production. Run this through our Tencent of excellence across Europe and constantly also growing within the sites, but also looking always to other opportunities to enhance our portfolio by additional capabilities we don't serve today. Natan: What are the main driver for the business? You contract and manufacture the products and what are the constraints you're working with when you were thinking about the whole operation, I know you're A CIO, we're gonna get to that because people have been, I think, redefining over the past few years. What is the role of CIO and what is the role of COO and where the operation meets the it? But before we get into that, maybe talk a little bit about like from a high level business executive. Perspective, like what are the main constraints or driver that you guys are focused on when you're, you know, designing the operations, the architecture to drive your business? Joel: Yeah, so we are exactly in the middle of the supply chain. Mm-hmm. So we produce our customers on behalf of our customers. Our aim is always two-sided. We have to produce high quality products. That is a given in the pharmaceutical industry, of course, and that is giving you the trust of your customers and produce medicines that help patients' life. But for us, the competition, of course CDMO, there's a lot of competition out there. It is beside the quality that is for us a given, it's also speed to market. Mm-hmm. And agility and adjust to the changing market demands we see from our customers, be it small customers who don't have own production capabilities and looking for an expert to do production of the medicines or this, uh, also big pharma or other companies. Where there's products that are more commodity and they are still important for the market, but maybe not fill a factory on its own fully. Mm-hmm. So they are looking and sharing the production capabilities. So this is where, and the Natan: game of speed and agility, you know, those sometimes are really contradicting what is also required from pharma manufacturing, which is like you said, trust and safety and all that. How do you reconcile that and how do you compete? Like what does agility in this industry actually mean? Joel: I think agility is still a little bit different to compare, I think, to other industries. Yeah. But it's not jumping on the next newest thing that's out in the market. It is, however, still early exploring and, and finding ways of utilizing technologies or services or capabilities that are out there in a safe and secure way. Means you need to find ways on how you go through the cycle faster. So you can be always agile in the beginning, but at to the point where what we call go in our quality gates, I. Then we become a little bit more traditional waterfall driven with quality gate approvals to get to a point that we can use any technology that is impacting the products as a live production. But getting to this point in the, I think this is where we try to be different than others in the beginning, more agile when we get to the quality gates and the twig is also putting a lot of efforts in that agility upfront and making the products or the. Capabilities we wanna use and test them out early enough. Getting early feedback loops to then also limit the efforts after the quality gates and the feedback loop after the quality gates. Natan: Yeah, sometimes, you know, people say architecture and immediately it goes like, oh, what digital tools you're talking about. But I really wanna talk about the architecture over organization. So if you go back a few years when you joined X Pharma, you said, Hey, I was like. Getting the opportunity to digitally transform this company. I'm paraphrasing you, or you know, take this on a journey, what does it actually mean? And you're a CIO that is very, very close to the operations. So can you talk a little bit how those traditional sort of boundaries between, you know, operations and it, how do they actually blur and create this new organizational architectures and how did it happen for next pharma from your perspective? Joel: Yeah, from us. I think history plays a little bit role there. Hmm. So the company were, before I joined, very much decentralized, organized, so each plant were really much managing their own end-to-end processes, but all capabilities, even hr, finance mainly, and uh, it and all others capabilities. And there was a certain point of growing and scaling as something I think a lot of companies go through. This works well to a certain level, but if you grow and scale further, I. You see there's more opportunities in in sharing capabilities across the sites, and it was one of the first ones. Then it was not only it we, we identified earlier. I mean, our capability lies in, we make money with production, right? Yeah. So when we produce medicines, this is where we make money. We don't make money with the, uh, I would say IT services we put around this. So there was very early already the drive and the demand to say, okay. We have to tackle pillars, right? So we have our fundamental, that's the core it. Architectural scalability, that's your fundamental, build everything on. That's something we worked on and that's, I would say the typical classical IT job. But when you then look on top of this, there is the question on how you drive an internal experience. How can people work and collaborate within the organization? How you wanna drive. Also an external experience, how you wanna engage with customer suppliers. So that drives more the human factor. But then there's the other point. That's all the automation and the data architecture. So all this lies on how you can operate better. And this is where we early we said we cannot have. Parallel worlds, right? So we have engineering teams that goes to the early automation topics, but when it comes through more Inpro integration there, you need combined work and strong wall. And out of the situation, I was pushing a little bit more in that direction to make sure we have the capabilities, but working closely with local engineering teams and others together to get in the right way. Natan: So I wanna take you back to the, I don't know, first couple months that you meet this distributed organization, and I'm sure you got some pushback on like, Hey, you know, who's this new guy coming around trying to centralize and like we're changing our powers in the fact that we're being distributed? Like what, what were some of the pushback you were getting, trying to implement this new approach? Joel: Yeah, I think I face two sides of the coin. There is some sites and there's some people who really appreciate it as they want to change, but they also want it to be clear. Like a site manager who's very operational driven, who don't want to deal with some of the other things around it. So there are a lot of people also happy saying, okay, there's someone taking care of services. But I try to provide value to them, right? To show that there is a win-win situation with the centralized. But of course there's people who are feeling loss of power or thinking yeah. Should I lose agility now with the service becoming central? I think that's a fear everybody has because if I'm locally responsible and I have all my different people, I can act faster. I think that was one of the actions where I was focusing very early on that this becomes not an organization that slows down things, that it's better utilizing more capabilities cross site and allow for faster responses and taking out risk of people not available, et cetera. So that's kind of how I. Worked very early on, tried to bring down the barriers and I mean, it's a lot of talking I going to the sites. Yeah. I regularly at the sites, I like to regularly go to the shop floor. I like to regularly see the people and processes to see where our issues, and I have a lot of people in my team who do the same to really identify what's going on. Natan: Sounds like you were leading from the front and engaging the operations people. You know, I think sometimes operations leaders are quite sarcastic about it changes. They kind of say, oh, they're coming now with all their great shiny architectures, and maybe we'll get something, but they don't really listen to us and they're kind of dictating, or things like that. But it seems like you managed to get a very holistic and integrative architecture change. Can you speak a little bit about how you did that and when was the moment that you're like hearing something from the operations people and you say like, ah, we got this right. Maybe not perfect, maybe not done completely whenever it's done. Yeah, but I'm on the right track. I think CIOs listening into this podcast really would love this perspective, especially in CDMO. Joel: Yeah, so let's take the example really how we've brought Tulip to our first site, because I think that's a great example of one of those situations. So we, we had to retire a legacy ERP system that had MES capabilities. So in the initial run I was leading because we were pushing also the ERP rollout with the idea of a clean core SRP. We had to roll out a short period of time, and so we had to identify how we can solve the missing MAS capabilities that we don't wanna build in SP. So we had a great engineer on the side, but we worked very early, close with the engineering together. So we were from an IT side leading the evaluation and looked together what are the capabilities by the early involved, the local engineer, the lead engineer who really chipped into that topic. That way. We also could bring down any barriers. In the beginning, they were still skeptical until they have seen what capabilities are now available to them. And what I think for us, sort of for me is important. I want to create a certain level of governance, but I don't want to over govern. So I want to give also them the freedom and the opportunity to live and breathe with the solution. And I think that when they recognize that yes, there is some standards, there's some topics to be followed. Within this defined environment, we can be also a little bit autonomous, flexible and solve our problems at the site that were really buying into the solution and are now our biggest advocate saying, yes, it has some good starting points and we do something central. I. That helps to get the ball rolling. But of course we wanna engage all the sites to be on the operations team. Historically, we also never had automation leads on a global level. So I think that's a little bit, that's a change different, every company's different organized. But historically, due to our more decentral approach, we never had central automation engineering groups. So there was also no competition on that end, right? So, mm-hmm. They were happy that someone globally were taking the lead. That was it. In this case, because there was no competition on a global level. So my partner, the COO, has a lot of other topics to focus around. Yeah, he's a sponsor, he's part of the steering committee, but he's happy that there's someone driving this. But then of course, the local engineers are the ones involved. We know building on the more capabilities globally, step by step. But initially there was nowhere else. Natan: That's really profound. A lot of people talk about the IT OT divide. It sounds like at the sponsorship level, IT engineers and OT engineers were in the same boat, so to speak, like from day one when you're driving the change, which made a lot of difference. And you said it started from one site. I'm curious, like to get the other sites, what techniques have you used? Like did you have them come over to the site and visit? Did you send people from the sites to go over and do gemba walks in the sites that potentially would be next on your list? Like how did you handle the propagation of the knowledge and the experience and what worked and didn't work when you were moving from this first site to others? Joel: We first start building a small global team. Mm-hmm. That helps develop global capability we want to bring to all sites as a starting point that they can build off. There was, I would say, a lot of promotion done by the local engineer to the other side. So they were meeting with the global quality teams, colleagues also from the other side. So there was some promotion done. The baseline for us, the core capability we using the moment is weighing and dispensing and we went off to, to major sites and wrote this out there. Natan: Kind of like a horizontal approach. Yeah. Not like, Hey, let's do A to Z in every site. Very linearly. You kind of went parallel, which is very interesting. Right. And how did you deal with variations between the sites? 'cause when dispense is similar, but in one site, you know, have small tweaks and the other site has a different scale. And how did you handle that? Joel: We try for, especially rain dispensing is, I would say very much a standardized standard process Natan: standard. Yep. Joel: And that doesn't mean that everybody's using full capabilities always, but the process is the same. The only difference for us sometimes is the technology because we have different scale brands. Systems, yeah. Or others technology that we have to cope with. But in general, from a process is, is similar. And the idea from us, what you mentioned exactly the horizontal approach. Is a limited one. There is, in our environment a handful of core capabilities that could be run in every site is we have different, center of excellence is different production process steps. We produce different kind of dosage forms that requires different production levels. Yeah. But there are some overlaps and some core capabilities that are everywhere the same in the pharmaceutical industries. And that is our horizontal approach. Then the vertical is within a site. Then a little bit more site specific, depending on their capabilities. Natan: Yeah. What really impressed me when I saw the stuff you're doing is that you basically developed a system of apps that the end result was like a controlled EBR without necessarily calling this EBR or MES. I mean, I know these words. Mean things in the context of your quality management system, but it was like really interesting, especially with the amount of SKUs that you're supporting and the parameterization that you need to do. What did you find that was hard in going this approach and what did you find that was like actually enabling? Joel: I think for us, the enablement was I would just, our starting position. So we had traditionally none of our sites, there were an operating MES system that was going end to end. Mm-hmm. So that was actually not existing. And in the site where we start, the situation was there were not a full MES. We had to retire. There were certain capabilities. So you look on the market and you see, okay, what can we do? We have time pressure to implement Natan: you, budget constraint, you have all those Joel: things. Yeah, yeah. Budget constraints, all these things. And this is why we never called it MAS or EBR from the first place. We called it really MA apps because we were looking into building some capabilities that can solve problems. Mm-hmm. And we used it also a little bit as a pilot, right? We have to be fair. So there was the first site, you go with the pilot, you see, oh, this technology has more capabilities and we maybe even were sorting in the beginning. So our vision created later. After we were a little bit in the journey to say, this has a capability to build you a full EBR. Mm-hmm. But the EBR is very complex topic in the pharma industry. I mean, of course in a lot of companies, especially CDMOs will know this. We have hundreds of templates for a master batch record because we were driven by our customers by the different products. Yeah, so there's a lot of effort you need to look into harmonizing these kind of services. And when you look at this in the end, the paper you wanna avoid, I. But on the way there is so much more gains you can win. And that is how we approach and say, okay, let's focus on the things that provide the biggest value first. What is really causing troubles? The operators every day where there is higher risk of making mistakes because of paper, because of manual process steps. Can we bring them in a more supported automated way? Can we argument the operator activities better? This eventually drives to the full EBI at one point. We are on the step with that, especially with our health nutrition business where there is a little bit less regulation, so we can move a little bit faster. But it's not like there is this full EBI at one point because we have no lap right now in focus, but we get to this where we close, and then later there will be still some challenges to be okay, how we will get our customers final results, et cetera. But. We get away from at least running with papers through the operation processes, and more and more capabilities will be electronically recorded. That in the end, will give you a full EBR. Natan: You know what's really interesting, just listening to, I'm talking to the CIO and the CO is talking to me about productivity gains, and he's talking to me about reducing deviations and augmenting the operator. These are things that you'd expect the operations people to care about, but it sounds like you care about them. Just as much. Do you also see numbers around that? Do you and the COO kind of sit down and see like, Hey, like what is the value that is actually coming from this digital production approach using Tulip and I'm sure other tools as well? Is that something that is top of mind when you're doing your business cases to where you continue and invest? I. Joel: So this is where I want to be to see this. So in the moment we are not tracking this on that level. Mm-hmm. But ultimately, yes, I wanna see improved numbers on less deviations, less issues. Um, I think it needs a little bit time because every new technology we bring in cause a little bit also disruption in the beginning. Yeah. So you need to get, I would say, over the noise period to really compare a like for like. Because a process that has been used 20 years, you cannot compare with something that you use now since a month or two. Yeah. So you need also settle in a year or two, but absolutely. Ultimately, yes. I wanna see results because in the end, our investors wanted to understand when we invest in technology, there needs to be a certain return of invest. And yeah, quality aspects, less car paths, less deviations are number to measure. Especially in the operation side, improve processes. Yes. You can also go sometimes in optimized processes, maybe less cost. That's a very indirect feelable stuff, but that's easier to track. But you wanna also track the second step behind, right? So that you see overall, Natan: the hardest thing, I hear people time and time again as we come to this point, is it's the baseline conundrum. It's like, what am I comparing against? You know, on one hand you put all these digital products in and you start to get a ton of data. Yeah, you get the digital baseline, but what do you compare it to? So there's like some obvious stuff, like you can, people count on certain intervals, like number deviations and that kind of stuff, but like a lot of people, it's maybe not so nice to say, but they sometimes come into their process blind, for example, they don't know how long does it take? They don't know what's the cycle time of, uh, line clearance. It is an SOP somewhere. Between assumption to recommendation, but it's not real. You know, it's not like we tracked five, we tracked 10, we tracked 50, a hundred of those, and then you can start getting to a statistically significant space of this is what it takes us and that's the blindness I'm talking about. And, and I totally hear you. And I think there's a lot of work to build those ROI structures. They think about it sometimes in the budget season, you know what I mean? And that's like just not enough. Joel: Uh, so you're fair, right? To a certain point you compare to something you can't compare against? Yeah. Because you have no data from the past to that level of data. Yeah. I think it's always easier, and then nowadays when you talk software or solutions that are more scalable, so where the initial invest is overseeable, so you can prove. Earlier results, you can prove that there's value on a small scale and then you can scale up. It's different when you have to purchase or invest a million or 2 million upfront to then figure out if that business case is paying out or not. Natan: Yeah, yeah. So if you have to summarize and give a few pieces of advice to folks who are starting a journey like you've started maybe in A-C-D-M-O, maybe it's in a division of a biopharma, what are the main lessons that you learned so far? What would you have done differently? How would you recommend people kind of approach this with their teams based on your experience? Joel: So I think starting with what really went well, and I think what our base of our success, first of all, we started in a overseeable approach, right? So we looked into one side, we looked into a handful of capabilities. So we had a clear understanding of what we wanna get out of this. So there was a clear goal and very early had all teams working together. We had it. Engineering and quality sitting at one table and work together out the solutions. And then this way we also ensured our cycle and appropriate quality proof. So we didn't work against, we worked all together and the size allowed for it as we were one person per department, so to say, because it was a little bit overseeable approach. There were more people in the project, but in the end, very small team that could make this happen. I think that went well. And that was the fundamental to prove that this is what we wanna use and what we wanna scale and wanna enhance to others. I think where it's difficult or then our lessons learned is then the scaling. We build a governance model on the way. So when you start in a single situation and you have to build your governance model all the way that's on one end, I think great because it allows us to scale fast and improve. This also sometimes points you back and say, okay, might be, we should have discussed a little bit more about data architecture from day one, but it's very difficult if you don't have the full end picture. So I think for us it's like really this always going back and forth and it feels, maybe sometimes we discuss a topic more than twice, but it allowed us to be fast in the beginning and now takes us sometimes to go back and reflect again. Because I would say we are maturing along the way, and that is important to allow for that. Natan: So I hear really tight stakeholder management iterations that feed the maturity function. This is good stuff and I think people should take note. What's on your map? Where do you think is the frontier? What's top of mind for you for the year ahead as you're taking the next step? Like from technology or process? Now that you have a baseline, that you have a core architecture, like what can you do with this? Joel: So we are in the moment, really, there's two things we want to really scale horizontally. So this is where we heavily work right now, bring core capabilities to each of our sites and fostering further the community of practice of the engineers across the site. Mm-hmm. So to bring that further and then enable each of the sites to really grow a vertical, that is what we're focusing right now. Also one thing, what we identified is now looking a little bit in the bridging worlds. So the more focus right now is Argumenting, right? But we have not so much integrating of different technologies. And now if you wanna look into the integration layer, we might need to see, okay, how we best drive the integration layer. Will it be standard across sites? Will it be a standard parasite giving the different history of the sites, et cetera? This is in the moment our next big thing to look into the integration layers to integrate better data Natan: and the value you're expecting from integration is like having, I'm guessing it's like highly contextualized data across multiple sites that you can compare different processes and you can like unify some of the data mining techniques. Other than like the obvious driving the business, but what other gains and value do you see out of well integrated data layer? Joel: So fast it's driving within the site, different services of preventive maintenance, more cost efficient ways of operating. Also, they're limiting cara deviations where you bring the data to the operations leaders in the side and and allow them to be smarter with their decisions on a more data driven approach. And this along with controlled environment. If we look into MSS capabilities. Avoiding having multiple complexity in connecting to the different machines. Natan: So more standardization. Yeah. Yeah. That would give you speed. 'cause that's full circle to where we started that to stay competitive, you said needed agility and speed, and it sounds like your engineers are on board. Do you see them living well between the constraint getting from you and the CIO sort of centralized approach? Versus, oh, we want to do what we want. And you got to a point where you have a good command of that tension that you can control the pace of which they wanna change versus what you want them to adopt. Joel: I think it's, it's both. So it depends also on the maturity of each of the sites and the individuals of course. So it's not everywhere the same. Some may wanna push a little bit more ideas, but I think one reason also why it's important from a CIO perspective use this, but all the aspects of cybersecurity and it. It's one key thing, especially in the OT environment. I mean by my training, I'm also an engineer. You want to solve solutions, right? Yeah. So you wanna bring solutions to problems, but you focus more on maybe then the individual solution for being more faster or more secure, but you're not keeping maybe IT security, cybersecurity space in mind. And that's not the job of the engineers. However, it becomes more and more the job also for them. This is why it's also important, I think, from a CIO to make sure that when we go in that automation and more digital environment, especially on the shop floor, we have to keep that in mind as in the end, our products are medicines and we need to deliver to the patients in the world and we can't rely on on CQ environments. Natan: So that's a great note to remember that there's a real reason why we were building all these new types of production system, which is like deliver the product, the therapies. To customers who need them to make sure healthcare is up and running well. And first of all, it's a reason to wake up in the morning, I'm sure. And I'm sure you look back and I was just talking to a few pharma executives that, you know, have been around for a long time. It's like, look, think through all the good that all this work is done in the world to patients. And it's really easy sometimes for people to get sarcastic about it, but, uh, we're not, we believe in new production systems and the people who build them and we'll do everything we can to support so. Really appreciate you coming on the show. Thank you so much for joining us today. Announcer: Thanks, naan was a pleasure for me. Thank you for listening to the augmented Ops podcast from Tulip Interfaces. We hope you found this week's episode informative and inspiring. You can find the show on LinkedIn and YouTube or at tulip.co/podcast. If you enjoyed this episode, please leave us a rating or review on iTunes or wherever you listen to your podcasts. Until next time.