In this first episode of The Connected Factory podcast, Alexander Krüger sits down with Jan Wokittel from Roche to explore the challenges and opportunities of digital transformation in the pharmaceutical industry. Jan, a delivery lead for digitization at Roche's new factory, shares his journey from mechatronics to engineering and his passion for open-source solutions.
Tune in to discover how the pharma industry can navigate regulatory landscapes to embrace digitalization and stay ahead in the rapidly evolving manufacturing sector.
Chapters
00:01 - 01:45 Introduction
01:45 - 04:01 Background and passion for open-source
04:01 - 09:59 Similarities between building a smart home and a digital factory
09:59 - 18:24 Technology adaptation in Pharma
18:24 - 28:54 Challenges with manufacturing software
28:54 - 33:31 Implementing UNS in pharma.
33:31 - 35:38 Skilled labor shortages
35:38 - 38:54 Involvement with the VDI
Transcript
Alexander Krüger: Hi, this is Alex, co-founder and CEO of the United Manufacturing Hub. Today, we are here with the first episode of the United Manufacturing Hub's Factory Podcast. It's a very special one because we directly turned hard mode on and said, "What's actually UNS and pharma?" So, not only technical, but also regulatory stuff is super important for us. This is why we have Jan with us. Jan works at Roche and is responsible for the digital delivery. the digital side of one new factory that they built. In pharma, everything has to do with rebuilding factories and putting the innovation there. Let's try to be as concise about it as possible and share some insights that we found. Let's get started.
Jan Wokittel: Thank you, Alex. Thank you for the invitation.
Alexander Krüger: Thanks, Jan. So, perhaps tell us a little bit more about your professional background. You actually started with mechatronics, then moved to engineering, and actually you're founding also something on your own. So, how does that actually unfold in your career?
Jan Wokittel: Yeah, as you said, I started with my bachelor's degree with a focus on technical building equipment and process engineering. Then I worked for a couple of years, but I realized I'm also into the tech stuff. So it means I didn't actually learn to code; I did this all by myself. This is why then I made the decision, "Okay, let's do a master's degree with a focus on digital product development." While doing this, I felt the startup and entrepreneurial spirit in myself, and this is why then in 2014, I founded my own IT startup in Switzerland with a focus on digitization of processes. I had this for like five years, but unfortunately, we didn't scale. So this was the point where we decided, "Let's make everything open source; maybe it could be beneficial for someone else." But this was also the moment when my love for open source grew in myself.In 2018, I joined Roche with the role of the project lead for our smart building initiatives. So, yes, since seven, eight years, we invested a lot in Basel in our site development. My first focus was on the new office infrastructure. We built the highest high-rise building in Switzerland as well. And since two years, I switched my focus from the building infrastructure to a production environment. This is also the reason why we are here today, I would say, because we have a big new CapEx project in Basel actually going on until 2030. I'm responsible, and I give my very best to make this as digitized as possible and to bring the right foundations in it. So, yeah, this is now where everything more or less comes together.
Alexander Krüger: Actually, also a super interesting path from the building to the factory automation. If you would ask an outsider on that, it does something completely different. You produce medication on the one hand, and on the other hand, you open doors and turn on the HVAC. But actually, under the hood, it's quite similar. So you have PLCs for the install, you have protocols, you exchange data. So, yeah, makes sense.
Jan Wokittel: Exactly. So I'm absolutely not a chemist or so. Actually, when I'm honest, I don't have a clue about the chemical reactions or the biological reactions from our products, I would say. So I have to be that honest. But from a technical perspective, it's like you said, so protocols are similar. A lot of the technologies we use, especially also in the IoT space, are quite similar or more or less the same. Just the regulatory topic around it is a bit different. But I also would say it shouldn't be that blocker. And this is also from the engineering perspective what makes it so interesting. It's quite cool to dive into these new fields and find out how we actually produce something, how it's working. But then at the end, always have to translate this somehow into technical solutions. And most of the time, it's about reusing what's already around, just applied in a new field.
Alexander Krüger: Actually, now let me use a bridge that we've, out of full transparency, already prepared upfront. Jan has just built a house and therefore he's also a tinkerer and used also technology in that. So what similarities do you see there, like in between building a smart home and actually running a digital factory?
Jan Wokittel: Yeah, this is also something for the outsiders, a big hobby of myself. So I more or less try to reuse what I bring in the professional environment and install it in my home. Side note: my wife really likes it. No, but yeah, I used all the experience from the last couple of years. For example, when it was about the building automation system and all the connectivity, what we planned with the new high-rise building. I just shrank that down to a smart home for a one-family home. And I figured out that also the challenges are more or less the same. I would say like 95%. You have to deal with proprietary systems, which are cruelty, and it's about creating these open ecosystems. And I was able then, okay, you asked, okay, what are the patterns and the similarities. The big win in the private environment is when something is, for example, open source or you find a community behind it. Because most of the problems I deal with or I struggle with at the end is somehow then solved by some other nerd in a community. And I just ask it and then I get the answer.But this was also the moment when I realized that this is exactly the same in the business environment, in the factories. If you want to be as innovative as possible and you have a very hard dependency on just one individual large supplier, this hinders innovation. And when I'm also chatting in these communities and just exchanging ideas, at the end, it's more or less a problem of one vendor when it's a closed source system, when there are no interfaces and I don't have any kind of possibility to connect all the other installations I've already in. So the good thing is when you can build something from scratch in Greenfield. But let's be honest, in the professional environment in business, it's more or less Brownfield. Like 90% are already given, and you have to deal with how can I evolve that to the next stage. Yeah, and this is what I found out.
Alexander Krüger: But I really also believe that we as engineers have a little bit of a sickness of thinking we are super special. If we are looking at the requirements that a factory has, so we have machines, proprietary protocols, and we need to model everything on the side and develop our own protocols to connect data. In my opinion, we should learn actually from the outside, like Jan already said, from the community, not reinvent the wheel but make something applicable. So for example, in a smart home, you start connecting perhaps via bus protocol. This is actually more manufacturing style, but for more and more time, you also use MQTT there. Like sensors connect via MQTT, you control stuff via MQTT. And this is just already a hugely distributed, highly established protocol and a broker architecture versus reinventing because there are already new initiatives like OPC UA PubSub or similar. But just take something that's existing, perhaps take it out of the context and make it applicable for manufacturing.
Jan Wokittel: Exactly. I always find myself questioning myself, do I over-engineer right now? So you now listed some of the protocols. And then at the end, think, okay, this is something I can deal with because I would say then of the engineering background. But for the normal user, what you do in the smart home is, I would say, the highest technical stage is connect something to the Apple HomeKit or Google Home. So you don't question the fact that maybe this is something proprietary, or is it okay to send something to Apple or Google, so the big techs. And I would say that also now in the professional environment, in the factories, you start questioning these. So is it okay to send everything to vendor A, or maybe I could be more innovative when I decouple all the services, because there are also some cool other tech startups around which might have a cool solution, but they need somehow the connections to the foundations, I would say. And you remembered some of the broker essentials, like the MQTT broker, for example. But when you go into the main documentation, the tender documents which are around right now, there's more or less written just use OPC UA because it relies on the ISO 95 pyramid. So you do exactly the same again, again, again. And then when you're now in this digital area, when you want to make additional use out of all the connections and you implemented the technologies which you know since 10, 20 years, you're stuck with the same problems again.
Alexander Krüger: Yeah. But I think a project is also something special and not necessarily like a good place for trying something out. It's always like, let's think every project at the start was, let's build the next generation. Everything needs to be cutting edge and nice. But then actually the time shrinks, the budget shrinks, deadlines are coming up. Do we really need that? Should we not de-prioritize and de-risk the whole project? And from that, I think it gets harder and harder to push something in there.
Jan Wokittel: Yeah, and I'm honest with you. Last week, we had a very interesting discussion where it was about, okay, what is the purpose, the main purpose of the new facility right now? And there are colleagues who say, my major goal is to build a GMP-compliant factory. And then we have also other colleagues, and I'm more or less dealing with them, and their ambition is, I want to have the most digitized factory ever built. So, and then you find yourself directly in the middle between these two chairs. Okay, I have these hard regulatory risk assumptions, what you just listened to, and also the business cases behind it. And then on the other side, a very long time span where you want to be as innovative as possible. And if you deal with such new ideas which are around and are also presented at fairs, etc., at the end, it's always weighing a bit the risks. And also, as new as the new technology is, the hardest is to bring this in a validated environment or qualified.
Alexander Krüger: Yeah, it's long-term versus short-term success. And this is another good bridge. So what do you think actually holds back pharma in general? So unified namespace all over the place right now, there are some forerunner industries and this is mostly the non-highly regulated ones. What specifically do you think is actually holding back or protecting pharma? Not everything new needs to be implemented, but what do you think is the main hurdles to adoption in pharma?
Jan Wokittel: So I would say that, and this is what I know, that no one has actually implemented it end-to-end in the live production environment at scale. And this means that it's not just only using an MQTT broker. This is easy. But you just mentioned the concept of the unified namespace. There are a lot of dependencies to other topics. And at the end, it's not just implementing an MQTT broker. And what I've read is that there are a lot of pilots around using MQTT brokers. Some of them are already doing this. I understand. But when you ask me, what is the biggest hurdle then, it's end-to-end live and also at scale. This is something which is quite hard. And this directly brings me to another point. I would say there's still a gap in education because our classical way of also building factories is, and this is also when you're in contact with general planners doing this stuff for you, there is actually no real and hard knowledge around what does it mean, all the dependencies. And this directly brings me then also to the additional benefits you bring, you get with all of these new technologies and concepts. It's not proven. Yeah. And just last week, we thought about, okay, what are the hard quantitative benefits we might get? And it's not that easy, speaking, and also for ourselves and we know our processes, but then what is the additional quantitative value you might get? I know what, yeah, the infrastructure, and at the first view, you just add new complexity on it. So in the brownfield, I would say it's not that realistic that you replace directly everything which is around. And when you now deal with these new concepts, you bring in more complexity, which means more resources. You need more people who have the right skill to maintain this kind of stuff. This is the first thing you end up with. And this is something I would say why it's not fully present at scale.
Alexander Krüger: I also think this is often a problem obviously of infrastructure. So if you think something like Snowflake or data warehousing, it's before that you already have data organized in some Postgres or SQL schemas, and then just add another database to reduce runtime and ease of use for some specific analytical workloads doesn't definitely make sense. And I think it needs to be like a critical mass of people using it, then having also quantifiable benefits from that. Like, for example, I think you can massively kill some existing software components in your tech stack manufacturing currently running on, like the whole MES. It could be trimmed down. It can be composable. You can dissect it into specific component and job to be done and do the, I would say, needling or like the connectivity for the UNS like the historian. So it's composed of the ingress and it's storing and the visualization, but with UNS, you're starting to questioning also the value proposition of those tools. And this is, theoretical. But as soon as somebody has done it, there will be another blueprint on how to do that.
Jan Wokittel: Of course. Yeah. And this is something also typical, I would say, for the pharmaceutical industry. You always look around and ask, who already has it implemented?
Alexander Krüger: As a cost attached are different for you. Yeah. You need to not only implement it, but you need to also validate it. Perhaps it's also a good thing that you could educate some viewers out there what that means.
Jan Wokittel: Yeah, yeah, yeah. But at the end, it's always weighing the pros and cons of bringing these new technologies because when you reach out to other companies and also in special, this reflects to the automation department. The first question you might get is, but why should I do this? Because now the factory might also have a runtime of 99.9%. So what did I make wrong so that you want me to implement these completely new concepts? And I was questioned that I said, yeah, this is a good argument, right? So the factory is running, it's up. But then you come up with, okay, there are now new benefits which weren't possible in the last years also when it's about these data-driven AI use cases. But you have to explain this.
Alexander Krüger: It's changing the status quo. It's not, I think you need to, we need to shift the way of doing it the way we do with different tools. Why? So like if you want to replicate the status quo with new fancy technology, there's no value add, but asking them what things they're not able to provide or what insights or applications they're not yet using because of the tech stack is a different thing. Can you now say, what's the availability of that machine? Can you trim down, what are the five main root causes of problems at that machine? Like those simple questions, I think this gives them more thinking.
Jan Wokittel: Yeah, exactly. And I'm totally with you and I love these simple questions when you more or less ask why, why, why. So, and we made this couple of weeks ago for our digital user interviews. So we asked different personas and representative stakeholders, how we name it, what do you expect for the future? And it more or less ends up with the problem that existing machines cannot be connected. Existing software solutions cannot be connected. And these are more or less the foundations why no AI-driven use case is possible. I cannot make any evaluation automatically. So doing it manually actually doesn't reflect for me the fact that you do evaluations. So I want to do this 100% automatic. Last week, I had a very interesting interview with some colleague working in our labs. And in our new factory, we think about these lab-to-launch or lab-to-production concepts, how to bring it from small scale to bigger scale automatically without manual interventions anymore. And the problem or the main issue why we're doing this today is because of lack of open interfaces. So and I say, okay, this, it can't be that hard to push also vendors to the fact, please open it because you cannot be the solution, the one-fits-all solution. But everyone is trying that, right? This is also a fact. You find every, when you are in contact with different vendors, whether it's hardware or software, everyone wants to be like, or creating an Apple ecosystem. I say it in that way because everyone understands it.
Alexander Krüger: Yeah, just trust us. Yeah, everything for all black box, trust us.
Jan Wokittel: Yeah, exactly. So use our black box and you're fine. I say no, because I'm pretty sure that today and also in the next years, you're definitely not the most innovative one in every field. Absolutely not.
Alexander Krüger: Yeah. So if I would, or if I'm pitching the unified namespace to pharma, I learned I need to try to avoid replacing what's already been there. This is more like an enabler as a second step, but first, firstly go in there and say, okay, build an open modular and API-first ecosystem besides your infrastructure. So it's saying this is just there to provide data between services more easily. Trust us, it's open source. So not only we, but also the components. So you have full governance. This is something that they're not used to do, but then you can extend. So it's not about like really rip and replace. It's more expand through this extension, I would say. And then it will take, fully transparent, a few years to really validate, make sure, smell it. It needs to be really in the people's head that this is stable and reliable. Because if you have OT availability discussions, it's super hard. They say our systems never fail. And IT says we can guarantee 99.9%. But it's not 100%, 100%. Then you say, okay, Google spends billions to get to 99.99%. Should we really, really go beyond that envelope? And this is something that they just need to try and trust.
Jan Wokittel: Yeah, and funny that you say that. So because we also know each other since a couple of years, I would say, but when I met you, the first you said, hey, replace it, right? What you said, and I really, it's logical, but it's not realistic, right? Doing this. So because it would also mean that you have to stop the whole production. And I would love to see the business case behind that of doing that if you want to replace everything. And we name it like decoupling first. So we also created these different waves, how to implement these new concepts and infrastructure. And the first one is about just decoupling. And this is a hard thing because there we have now discussions also with very known industry worldwide industry leaders about opening their solutions we are already using on worldwide scale. And this is an essential part of the strategy of decoupling services.
Alexander Krüger: But they never know that. They don't know to build API-first. Like it's so hard for them.
Jan Wokittel: No, this is new. But I also see, okay, there's now a bit of a movement in the whole industry. And we are also open. I would say we are the customer representatives. So we don't provide software. I'm the user of it. I'm the customer side. And I'm also open doing this kind of co-development when it's about, now when we are approached by some vendors and they ask, okay, what do you want in the future? What is your strategy as a customer? Then we are very open and we just did it that we say, okay, decoupling first, because I'm also open with you that I want to be more flexible in the future. If I found something, a cool startup there or a new solution there, I want to test it by myself and I don't want to spend thousands and millions of euros and months just to test something out. This can't be the future because I always reflect myself or mirror myself what I can do in my private scale. So to close the loop to our discussion before. So with all of my apps on my phone, I can connect it to other services, etc. Just last week, I connected my car to a new power system. So this was quite easy, but as soon as you are in the business environment, it's complicated and time-consuming. And I just want to be innovative, which means I need very short development cycles and short cycles of experiencing something and testing it out.
Alexander Krüger: This is also, I think, a sickness of manufacturing software. My co-founder Jeremy lightened it out quite well in another blog article. He was saying that software is built to be bought and not to be used. And this is fundamentally different to user-centric architecture. You download an app, doesn't work, delete. This is the normal cycle of doing that. And in manufacturing, you start with, these are my requirements. Here, see the Excel, 200 pages. Please match and then the vendors start, sure we have it, sure, sure, sure. And then you definitely, yeah, sure, sure, we can build it. And then after you start using it, it's like a monolithic mayhem of features glued together. Nobody can use without a system integrator. And then you're like, okay, now this will take years. For a good example is Open PCS7, like in a distributed control system. One of our customers, they needed to set up the variables in the system to configure it. The vendor doesn't provide Ctrl-C, Ctrl-V functionality. So what does he need to do? It's one on the requirement sheet. He now consults the system integrator who now goes through every 40,000 variables and hand-written into the system. Now this is super failure-prone and just stupid. But this is the way our software is now used because it's acceptable to use a product this way.
Jan Wokittel: Yeah, and in the professional environment, it's also quite hard, right, to, and you just said, install an app or delete it in the professional environment. This more or less is somehow impossible in some stages, doing this on a short cycle. It might take months or years doing this once it's implemented.
Alexander Krüger: But I think specifically in trying it out, it should not be. And you're already doing it at Roche, but other companies should also create a safe testbed where you can evaluate software in. So like, I don't know, you have a central API where you can fetch data from a PCS, from a DCS system, from a PLC, from the building automation, and then every late software in that. Then in a few hours, no, it's a product that's actually over-selling, was actually quite useful. And this is why we also open source, to be honest, because we are so frustrated by the state of manufacturing software a few years back until now. I want to see the product. Okay, sure. Just fill that form, wait three days, talk to an under-qualified sales rep who has no actually idea what my requirements are, then let him sign you, qualify you, and let him then sign you up for a demo. It needs to be always handpicked and he helps you and it's weeks in, then you understand the product is shit. But as an open source user, I want to download, try it out myself, build it out to a certain degree, and then want to get into contact with the seller to get the enterprise features or let him help me to scale. But this is also why we're trying to shift how you buy software.
Jan Wokittel: Yeah, it's also how you buy and also how you implement this. This is also an experience I made quite hard. If you are dealing with these new technologies and concepts you mentioned, a lot of the projects are, that the setup of the project, it's quite waterfall methodology. And because you have learned it since years to write down requirements, so you create a lot of paper. It's quite similar to creating an e-book just for a project or so before you start testing it out. And then you find out, this is more or less not what I needed or so. So what we also try, so I would say that we are not the best in everything. But we give our best to have these more iterative cycles when it's about implementing these new concepts. Okay, you have to write down some of the most essential requirements there. I'm with you, just to have a clue, okay, what are the criteria for success. But at the end, you will just find out what are the additional benefits for you when you can really test it and when you can interact with it.
Alexander Krüger: Yeah. Really, really, really valid point. Now I'm thinking about we talked a little bit why UNS doesn't work in a specific in the pharma context, but you're to some degree moving ahead with it. And what do you think are the key enablers for you to just give the others out there a little bit of ammunition to pitch it to the leadership and to other business owners?
Jan Wokittel: Ammunition, yeah. Okay, so let's try my ammunition. Let's see if my ammunition is good. So the first point is when it's about what is the business case behind the UNS concepts, for example. First one is definitely the open interfaces. This is the most essential foundation. What does it mean? We have on the first level process equipment level, which means open interfaces to the field devices. Second level is building infrastructure level because in the future, I'm quite sure that you cannot talk about production and lines when you don't see the bigger scale because it's also embedded in the building. And now you talk about robots which are moving, etc. So when you want to connect everything, also the infrastructure is merging. So building infrastructure, second level, and third level is for the labs. All these three levels are more and more interconnected with each other. In the production, you need more data from the labs so that the production is running. I'm more and more in contact with building infrastructure. In the past, this was also 100% separated, right? Completely new knowledge expertise, the department, but now those stuff is also merging. And for that, you need the open interfaces. Biggest business case, because in the future, the colleagues will create new business cases and new digital solutions, and they rely on this data. And last week I had a very interesting and cool presentation from a colleague where it was about the digital twin at Roche. And we are now dealing with that since a couple of years. And also when we now wrote down which kind of use cases we might enable with the digital twin, we also were talking about process level simulation, building level visualization, and then also operations level, where it's also about the digitalization of prior paper-based processes. And for that, more and more expert systems are interconnected with each other. And this is a business case. If you ask me now for quantitative numbers, I wouldn't be allowed to share that because it depends a bit on the amount of work and FTEs and etc. you have behind it. But this is, I would say, the foundation where you get the most benefit out of it. And also one experience I would like to share is also from the project perspective. We are dealing with a long lifespan. For the next six years, I really love also from an engineer perspective to deal with these new technologies, but it's hard to figure out, okay, what should I do today so that my facility, my production facility is the front runner in six years, so that we are in six years before all the other competitors. And for that, I would reduce it to create these decoupled ecosystems.
Alexander Krüger: Also, the point is we don't know use cases that we don't know yet. And in the future, like problems on the shop floor can be now solved through processes, training, etc., there will and should be like a new solution to digital technology. So it could be a dashboard alert and AI models that are referencing something. The key to success, my deepest conviction is actually that you have the tooling on there that enables the people to build a product on their own fast. It needs to be, I don't know, perhaps the business case is too weak for like a huge project. I don't know, five to 10K per annum savings or whatever, but you need to be able to capture those long tail of use cases fast and effectively. And this is what I really believe is the long tail win for the UNS because you're decoupling applications, reducing integration costs and collaboration on data and capturing those use cases you don't know yet is a fear that we're happy to work with and let the people tackle that later on.
Jan Wokittel: Yeah, and I would like to add one point because now we were very focused on the technical part, but when it's about the democratization of digital solutions and you just said that people should be able to develop something by their own because in the future, not everyone can be a developer, wouldn't make sense. But it's also a question about the shortage of skilled workers. And when you create these democratized data ecosystems and system ecosystems, you might have the right foundation to enable the people around you to create something on their own.
Alexander Krüger: Yeah. And this is also again a bridge why we love to work with technology that is known from home automation because you now drastically improve your skilled labor situation. If you're like working with highly specialized system, perhaps 1,000 customers in the world, therefore perhaps 5,000 skilled people worldwide. Try to now find a specialist on your rural plant somewhere in deeper Switzerland. And if you have like, I don't know, Node-RED, MQTT, Postgres as an interface and software components to work with, there are firstly YouTube videos on that. You can ask ChatGPT a lot and people already are working with it. So it's also about just getting back to what the people know and don't over-specialize where it's not needed.
Jan Wokittel: But you also see the shift in education, what you are doing. So I really like the videos of Jeremy when he explains the things, right? But in the past, it was like, go to today's workshop and skill up yourself. And now you're able to consume it just by yourself. And I just used the videos from Jeremy to implement my own UNS with my heat pump at home, right? So it was just a translation from industry German automation.
Alexander Krüger: It's really on-demand knowledge. The problem in industry is we're too slow. Not only pharma, but everything is too slow. Projects are too slow. Learning is too slow. Implementation is too slow due to bad products. And we at UMH have the mission to make everything way faster. It's not only the product, but it's also the learning perspective to, I would say, front-load the common knowledge. And this is why we heavily invest in it. And also what we hope this podcast led others specifically in the pharma sector to educate them, know the right terms, the right anchors to set for the UNS journey. Perhaps something now a little bit more besides your work, you're super active also in the VDI. What do you think, why are you doing that? And what do you think you want to change by being more active on a higher scale engineering organization?
Jan Wokittel: Yes, so maybe for the outsiders, VDI means Association of German Engineers. We are the biggest association in Europe and brings together the engineers. And yeah, you're right. I'm active there since my university degree. And what I'm doing there is also I try to create excitement for being an engineer and work with tech. So I really believe that most of the problems we are dealing with today require technical solutions. Or would say that also our society hopes that new technology might solve our biggest issues, our biggest problems like climate change, etc. But I see also that we have here a shortage of skilled workers. And this is why I just want to create excitement at young people being an engineer. And now starting in 2025, January next year, I will be the chairman of the regional association of German engineers here in the Black Forest. I think I will be the youngest one in Germany, which is quite cool. And I have then a couple of thousand engineers volunteering in the VDI. And also there I try to bring in new tech topics. Offering. So when you're a member of the VDI, you also get these educational sessions. You can visit other startups, other companies just to create excitement. And you're just being curious, what does it mean being an engineer and also on your daily basis when you're in the business life?
Alexander Krüger: Yeah, really, really strong. I think also upskilling engineers over the long run through digitalization is so crucial. We cannot be only the guys for the mechanical parts. I think it's a way too old assumption of what an engineer should do. So really, really great that you're pushing it.
Jan Wokittel: Yeah, yeah. And also the understanding of what does it mean being an engineer, like you said, it's not just about dealing with mechanical problems. No, also our work is more and more digitized and cross-functioning, which is quite interesting. So I really love the job, but the way until you are there, it can be hard, of course. But at the end, you have a lot of possibilities.
Alexander Krüger: Yeah, I think solving problems is what engineers do. Hard ones specifically that are interesting. So actually, this is good. The UNS to solve is still a hard problem specifically in the pharma sector and Jan and the rest actually trying their best to make that work. So thank you Jan for being on the show. I hope also the listeners enjoyed that one and more to come. Jan, it was a pleasure to have you.
Jan Wokittel: Thank you for inviting me and also for the outsiders, if you want to know more about what I'm struggling with in my private and business life, feel free to reach out to my blog and website or also Alex. Thank you. Bye bye.
Alexander Krüger: Thank you and see you soon.
