How production standards safe you money and saves your quality| Ep. 10

Lars Linnet (00:00):
We need to talk the same language, and we need to understand how does the recipe even look? What’s a master recipe? What’s a control recipe? What should be in the recipe header when you push it down to go to a production? If you don’t have that common language, then that would be like pushing Legos and Duplos together. They may look somewhat the same, but they just don’t fit. You ask why are we running 80% like we are supposed to? Maybe when you ask three people, you get seven different answers.

Mikkel Svold (00:33):
The flip side of following these standards, doesn’t that risk being a rock in the shoe on innovation? Welcome to the Food Tech Podcast. I’m Mikkel Svold, and today we explore the technology and the standards that shape the future of dairy production. Today we are talking about something that sits often quietly behind every successful dairy plan. We’re talking standards. It may sound a little bit boring, but I assure that it won’t be because standards, they form… From food safety to automation, and they form the foundation of what keeps everything running smoothly and of course compliant. We’ll explore how production leaders, they can move from just complying with the standards to actually actively using them to drive efficiency, reliability, quality, and of course, digital transformation. Today, my guest is Lars Linnet, who is the product director at Au2mate and who spent years developing or helping dairies strengthen that foundation between IT and OT, and of course, making the standards work in practice and not just on paper. Lars, welcome to you.

Lars Linnet (01:55):
Thank you.

Mikkel Svold (01:56):
I think a good place to start will probably be what kinds of standards are we actually talking when we talk dairy industry?

Lars Linnet (02:05):
Well, I think from my point of view, from coming from the automation side of it, we have three standards that are very important. That really is the foundation and really sets the tone of how we approach a project. Also, I would say also how a lot of the different other actors in the business also see both from the user side, but also from the system providers and system suppliers. That would be like the batch ISA-88, which really outlines a common language for how to break down a process, the procedure, the equipment, and really gives us a common language to speak from. Then there’s what’s called S-95, which goes in more on a… It actually is related to ISA-88 in that way that it is for the next layer.

(03:10):
It defines how should databases look, how should the data flow, how should we interact with what I call usually the shop floor, and how should we provide data in a structured, orderly manner to like, for example, an ERP system? Then we also have what’s called PackML, which is actually a derivative of the ISA-88, but say the ISA-88 is targeted at process equipment. Typically, we have something in vats and tanks, and you’re mixing and adding. Then the PackML is for the end of line, so the high-speed packaging machines, the fillers, the wrappers, the palletizers, which there’s I can say different challenges, and therefore, different needs. The PackML standard then tries to address those very specifically.

Mikkel Svold (04:10):
Yeah. Those would be the three foundational standards. What other kinds of standards do we have?

Lars Linnet (04:15):
Well, of course, there’s a ton of food safety standards, which of course the system suppliers knows much better than I do, and also, of course, the dairy producers themselves. Then of course there’s also machine safety. The machine directive would also be a very important standard, of course. Of course there’s a ton of standards around the system out there.

Mikkel Svold (04:44):
If you put yourself in the shoes of a production manager in a dairy facility, which of those standards would you give the most attention?

Lars Linnet (04:56):
I would definitely start with the ISA-88, simply because you need to understand that the ISA-88 is actually one that all the major players in the business knows, understands, and they orient their approach to a project like that. For example, if I go to a competitor, if they are fairly say competent, we in a way talk the same language. If we go to a dairy and we say, “We have a tank over here, and the customer wants to do something,” and they maybe have one part of a delivery and I have the other part, then we know what we call the equipment. We are actually able to talk with the same language. We know what’s a unit, for example, what’s an equipment module. When we know how to talk about it, we also… It just strengths of the corporation and also helps define the interfaces between the deliveries. In every project, that is always where you have most of the risk is when you have the interfaces between other systems or suppliers or other actors on the side.

Mikkel Svold (06:10):
Can you give an example of that? How would that problem look in real life?

Lars Linnet (06:16):
Oh, let’s imagine we are out at a site, and a customer has decided to expand their capacity. Let’s say they’re expanding some cheese lines, cheese production lines, for example. Then there’s a lot of companies out there that specializes in delivering that hardware. Then the customer has bought a complete system with control and automation on the shop floor level. Then, for example, Au2amte will come in and do the MES system. The MES system is where you have things like recipes and traceability and most really core functions of food and beverage production. We need to talk the same language, and we need to understand how does the recipe even look? What does the recipe contain?

(07:03):
The ISA-88 goes in and actually defines that and gives you a common language for that. What’s a master recipe? What’s a controlled recipe? What should be in the recipe header when you push it down from the MES layer down to the… To go to a production facility? All that is outlined in that one. Therefore, it is actually very key. If you don’t have that common language and you maybe can’t even… You don’t agree upon where does the unit start and where does it end, then of course you can see that would be like pushing Legos and Duplos together. They may look somewhat the same, but they just don’t fit.

Mikkel Svold (07:46):
Basically that would mean that when you then implement that new machine or that new line, the output once you’ve run the production would look something completely different from what you’d expect.

Lars Linnet (07:59):
You can say the integration at least would be much more customized, and it would be therefore more expensive. It would be also be harder to maintain for the customer after people have left. Also, it will also be harder to let’s say make adjustments on that interface. Let’s imagine that same producer has the cheese running. They’re producing, and then two years time they need to push out a new product. Then you have to go in and then you actually have to go in and modify that recipe. If it’s done correctly, then that should be a fairly easy task. But if there’s a lot of custom work and a lot of hard coded at the system end to make this work, then maybe you need to bring in both us and the system supplier. You can even hear the overhead on that one.

Mikkel Svold (08:52):
It sounds like something that’s very logical. It sounds very straightforward. Of course you should do this. You visit a lot of different food and beverage facilities. Is this in general something that is completely under control? Or is it a little bit up in the air whether they follow these standards or they have some kind of handheld custom-made solution?

Lars Linnet (09:16):
I definitely think that the big ones are fairly really good at this, and they understand it also.

Mikkel Svold (09:23):
Big ones meaning the big producers. The big-

Lars Linnet (09:25):
Yeah. The big producers, but maybe let’s say you’re a mom-and-pop shop that started producing something out of your garage and just… Well, incrementally, you just expeed your capacity, you hired more people. Then maybe you wouldn’t have… You don’t see the problems of not having a structure planned until you… Say, you can’t manage everything in your head, if you know what I mean.

Mikkel Svold (09:54):
Mm-hmm.

Lars Linnet (09:57):
There’s definitely someone who… Yeah. you can say, is behind the curve on this one.

Mikkel Svold (10:06):
What’s the tipping point then? Because complying to all of these standards and implementing that is also very… It’s a resource heavy thing to do, I imagine, or no?

Lars Linnet (10:18):
I would say sometimes what I hear from when I talk with customers or even engineers when needs to… Are told they need to work on this standard, but maybe they come from a different sector-

Mikkel Svold (10:32):
Yeah.

Lars Linnet (10:32):
… so they’re not used to using this standard. They already have a system in place, so of course for them to then be compliant with this standard is a extra cost.

Mikkel Svold (10:43):
Yeah.

Lars Linnet (10:45):
Then for a producer, you’re always caught in this dilemma that if he has the best machine on the market, but not compliant with standard, how can you make this work if you really want to have the best machine on the market? Then there’ll also be some, well, then selling it on, but they are compliant with standard to a certain point. This can also seem like a bit of… If you have a small production, not that many machines, and it’s relatively handheld, a lot of operator control, then this can seem like a bit of a academia exercise.

Mikkel Svold (11:24):
Yeah. Yeah. I could imagine. You bake your bread from mostly gut feeling and of course a recipe that you mainly have in your head, and then suddenly this highly-schooled engineer comes over and says, “We need standards. We need all of these documents.”

Lars Linnet (11:42):
Yeah, exactly. Yeah, yeah, yeah. Exactly. Because you can say just one good example of what the ISA-88 actually defines as… It goes in and says like, “Okay. When we look at a company…” Let’s say we have a production site. It defines a site. Then it defines what are you doing within the site. Let’s see, with the cheese producer, you have a milk reception, a cheese production plant, and then you have some packaging. That will be three areas within the site. Then for each area, you have a process cell. For example, so basically you drill down and get granularity of your plant all the way down to the specific unit, actually all the way down to a specific valve. Then you have that model and you have that physical layer, I’m talking about, it just enables a whole lot of things like how do you structure your documentation? How do you produce on this plant? How do you visualize it actually, even on a scale?

Mikkel Svold (12:50):
Yeah. What if you then have maybe not a small production, but a very flexible production? You need to be able to do lots of different things within the same production line, what then? Yeah. What happens?

Lars Linnet (13:03):
Then you could say that the standard actually also defines the routes between the production. Say like how many flows do you have between? How can you cross? How should you structure and set that up? Whereas this term, for example, that in the standard was called allocation and arbitration. Already here, it sounds a bit academic, right? If you just-

Mikkel Svold (13:30):
Yeah.

Lars Linnet (13:30):
But basically what it tries to tell you is let’s say you have a tank farm that holds different types of raw material. Allocation is when you say like, “Okay. Which of these tanks do I want to use in my process right now?” I may not be wanting to use all of them. I just want to use the three of them. Then arbitration goes and tells like, “Okay. In what sequence, if any, should I then draw upon those tanks? Should it be all this product I’m pulling first? Should it be operator controlled?” You can say the standard doesn’t give you a clear answer on this, but at least it makes you think about it and set some common rules that you then can use across your whole plant. It won’t be so when one operator goes from one area of a plant to another, then the equipment suddenly starts behaving differently. There is a common thread between, at least from an operator view, how the equipment functions.

Mikkel Svold (14:31):
Yeah. I think as I hear it now, the standards, they really help you maintain the quality throughout production no matter who’s at work that day. It also helps the systems and the different parts of the food plant work together basically. It helps it integrate. I can see the benefits. In hindsight, I can see the compliance benefits. You are able to say, “Okay. We always have this quality that we promise, blah, blah, blah, because we have all these standards and these processes in place.” That is actually all good. That is… I would probably suggest that for most production managers out there, that should actually be sufficient for implementing standards simply to keep an even quality. But what if you want to then use these standards for more than just documentation and compliance? How can you actually turn these… The standards and the requirements they come with, how can you use that proactively and make your plant more efficient or better? How would you do that? Can you do that?

Lars Linnet (15:49):
That’s a good question. I think you cannot stress enough actually how important it is just to have a common structure because that’s what we see… A lot of the projects we’ve done with, like for example, using AI on data, for example. The problem is that if you just… If you don’t have a strict rule of naming your data, so identifying where those data points are coming from, then it’s really a lot of work sorting that out and mapping it out. The ISA-88, for example, gives you a naming convention, and it gives you a hierarchy, and it gives you a structure. If you are good enough as a system supplier or the end user to say like, “You have to use this hierarchy. You need to use our naming conventions. I know that your own engineering partner may have your own internal sets. I understand that, but we need to find a way to make this work and be a bit pragmatic about it.”

Mikkel Svold (16:56):
I’m sure you’ve tried this in real life, coming out to a facility where you’re like, “What are these units?” What do you do then? Can you try and describe what then happens? What’s the problem?

Lars Linnet (17:10):
I think that if you go out and you don’t… If you get a Excel spreadsheet and you maybe not… Then you maybe have this planned overview. If you can’t see from the Excel spreadsheet where the data is coming from, you only have really two options. Either you can call someone and hope that they can explain it. Often they can’t, or it’s very difficult to get a complete picture. Or you simply have to go onsite and do what we call a line walk and just see, okay, so this is equipment and go and look up on SCADA. Okay. I can see this is visualized to be the tank temperature on this tank, and then you have to do more or less a detective work to pull that data and pair it with a physical model.

Mikkel Svold (17:59):
That is something that you’ve actually done?

Lars Linnet (18:01):
Yes. Yes. We have actually done that.

Mikkel Svold (18:04):
How long time does that take?

Lars Linnet (18:05):
It can take for a long time. Yeah. It can really take a long time. It can also be one of the major barriers for really doing data-driven optimization at a plant because just the step of doing that work of mapping out your data can just be so time-consuming, and therefore, so expensive that the whole business model can actually fall apart. Yeah.

Mikkel Svold (18:33):
But that was actually my question. What’s at stake? Because sending you around a food factory to look at every machine and then rewiring your whole system, it’s not a small thing. That’s a huge thing, and it comes with potential errors. It comes with a lot of uncertainty. It comes with getting people used to doing things in another way, probably a big thing as well. What’s the business case here? What’s at stake? What if you don’t do it?

Lars Linnet (19:08):
Well, if you don’t get the data and you can’t… When you say you lose out on a lot of the low-hanging fruits actually from doing optimization because you are basically running blind compared to optimization. Yeah. I would say that’s what at stake. You really lose out at getting all those small gains out of your plant that you can do. You’re maybe more stuck at investing in more heavy, bigger investments maybe for equipment or something like that.

Mikkel Svold (19:47):
There’s a lot of money at stake as well?

Lars Linnet (19:49):
Yeah. Definitely. Definitely.

Mikkel Svold (19:50):
Yeah. We had an interview on this podcast where we talked about decimal optimization. If you can basically improve by 0.05%, then that will be worthwhile doing, of course, because just the volumes of… In this case, it was raw milk. The volumes of raw milk is just so immense that even just a slight, slight optimization will just explode into €70,000.

Lars Linnet (20:20):
Yeah, yeah. Exactly. Exactly.

Mikkel Svold (20:23):
Right?

Lars Linnet (20:23):
Yeah.

Mikkel Svold (20:24):
I think there’s really a lot at stake. I want to come back to this, how do you work with the standards and not just follow them? How do you look at the data that you get and then from there, build design improvements? Where would you start?

Lars Linnet (20:49):
Well, I would actually say… I would actually take a step backwards and say the way we work with standards is actually right from the beginning of the project. Even when you start designing your solutions, you already need to think in how the standards do. This physical model, like what is the unit? What does it consist of? What is the interfaces? You already need to use the terminology and the structure in the design phase to really gain off. If you try to do it at the back of a project, then you’re suddenly… Then it just becomes this academic say exercise. The way we do it is that we use the model here as a framework for how we structure the plant and how we do our documentation and how we test. One of the words we use a lot is like this object-based programming. Here, the structure also help us achieve that. That, again, benefits the customer because it makes like we can reuse more of our code, and this also drives the engineering cost lower. Actually, it also benefits I can say the end user.

Mikkel Svold (22:06):
But I can’t but think the flip side of following these standards and having them, as you say, as part of the very foundational work in when you build something new, when you design something new, so you have the thought, that’s just how we do it. Is that also… Or doesn’t that risk being a rock in the shoe on innovation or thinking a little bigger than the standards? Isn’t it constraining that innovation?

Lars Linnet (22:40):
Yeah. That’s a good question. You can say… I want to flip it around and say, if you didn’t have a standard and didn’t have a structure, then every time someone sat down and started a project, the output would be different. Then you would end up with having this massive technical debt that you then had to sort out at some point. Like I said, like with the small producer growing up to a certain size, and all of a sudden he can’t gain the benefits of big ones because he doesn’t necessarily have the data at hand. No. No. Because I also think the standards are also very much guidelines. They give a language and a structure and say almost a best practice of what it should contain, but it doesn’t go in and say specific, “You need to do A, B, C, and this is the only way you can do it.” No, I don’t think it in that way hinders innovation.

Mikkel Svold (23:37):
You see it more so actually an enabler of growth, so that it will make you able to push your production from low scale to high scale because you then have the right data format, you would have all the right stuff set in place, and then when you implement that new production line it will work.

Lars Linnet (23:59):
Yes, exactly. Also, you can say in the food and bev business, you change products all the time, and there’s a lot of innovation going down on the product level, and where having a nice structured plant is just really important on so many levels for everyone actually around the table. Not just the final supplier, but also us as a automation supplier. The maintenance guys, for example, also, they also all of a sudden have a nice structured documentation. I know I see a lot of benefits of it.

Mikkel Svold (24:39):
Now you mentioned a lot of different people involved, but who owns these processes? Who owns the standards? Who should own them?

Lars Linnet (24:48):
Yeah. That’s a good question. I see…

Mikkel Svold (24:52):
Is it the production manager, or no?

Lars Linnet (24:56):
I think that you can say we do it way more, so like do it every time, use this framework, because that’s just way we do business, also of our project management is built around this. I know a lot of the big system suppliers also use it as a integrated part of their projects. You can say sometimes I meet, for example, a user requirement where we don’t mention really standards. I will always try to nudge them to say like, “Are you familiar with standard?” Because sometimes they maybe come from another business where we don’t have it or they haven’t met it. Because it is really important to have this in already at a user-requirement level because this only works if you are structured and if you do it at every project. If you only do it at two thirds of a project, well, you really don’t get the benefits of it. No. I would say it’s everyone around the table really needs to take care that you bring this.

Mikkel Svold (26:09):
Now our time’s nearly up, but I want to ask you, again, put yourself in the shoes of a production manager. What three actions or two actions, three actions would you take tomorrow to get closer to those… You mentioned those three foundational standards, the ISA-88 and the S-

Lars Linnet (26:34):
95.

Mikkel Svold (26:35):
… 95, which is like… I wrote down this basically data infrastructure kind of-

Lars Linnet (26:40):
Yeah.

Mikkel Svold (26:40):
… thing, right? Then the PackML, which is packaging thing. What would your immediate actions be?

Lars Linnet (26:49):
I would definitely not go about it like try say… Do necessarily a full analysis of the site and like a full gap analysis. I think that I would-

Mikkel Svold (27:01):
You wouldn’t do that?

Lars Linnet (27:02):
No. I wouldn’t do that simply because that’s too big a task.

Mikkel Svold (27:07):
Gotcha.

Lars Linnet (27:07):
If I know I have it in place, I’d of course just be… I would nurture that. But let’s say I have a new project coming in, then I would try to go like a map. What do we have in place? What would it require for us to be compliant or use the best parts of this S-88? Be pragmatic about it and see what gives sense for us, what makes sense for us, and where can we see the benefit, and what do we push down the line? Then for that project, then try to implement it, make it here, and then over time build it. Because there’s no benefit… If you have a working plant, there is no benefit of just redoing everything just for tidying up.

Mikkel Svold (27:51):
Just bulldozing over everything. Yeah.

Lars Linnet (27:52):
Yeah, yeah. Exactly. That doesn’t really add much benefit compared to the cost of it.

Mikkel Svold (27:56):
Is that the most common pitfall?

Lars Linnet (27:58):
Yes. I would definitely say. If you try to do everything at once, you will necessarily fail. You need to take it in small increments.

Mikkel Svold (28:07):
Are people generally good at that?

Lars Linnet (28:10):
I would say, yeah. How do you measure that success? Is that that you at the end of the day stand with a site that is 100% compliant? I don’t think that should be the dream, but I think you should be pragmatic and use the standards to mitigate those pains you have and try to see if this can be the framework you’re looking for instead of you having to reinvent something yourself.

Mikkel Svold (28:40):
If you were to do your sales work and then sell this idea into let’s take three different levels. We would have the top of the organization, C level, and maybe even board. The same goes, what if you were just to sell this idea into production managers? Maybe even what about the engineers actually working the machines making sure that the product comes out and, done, it’s good? What are those three different key ideas that they should know?

Lars Linnet (29:13):
I would ask a operator, “Would it be really nice when you go in at work, right? Then when you operate the machines, that all of them more or less all act the same when you push your start button and you push your stop button. When there’s an error, that those errors are presented in the same way. Wouldn’t that be nice for you and say have you a more pleasant workday? You don’t have to stress around, and you know that machine A acts like this when it has an error. Then you need to bang it and reset.

Mikkel Svold (29:44):
But isn’t that also what gives you the feeling of you know your trade? You can knock that tank three times, and then you know the temperature of what’s inside it?

Lars Linnet (29:53):
Yeah. Some of the experienced operators are really, really good.

Mikkel Svold (29:55):
Yeah.

Lars Linnet (29:55):
I won’t take anything away from them, but you can say a lot of the operators are where today maybe only stay at one site for two or three days. Or maybe some of the errors that actually occur, they occur so rarely that you may only see them once or twice a year. That would be my pitch for the operator. I think for the more higher level, for you can say the production management, “Wouldn’t it be nice if we had a framework that could tell you in a uniform way what are the stoppages causes at your packaging machines? Because you know they are maybe only running 60%, right?” You ask them, “Why are we running 80% like where you’re supposed to maybe?” Then when you ask three people, you get seven different answers of why.

Mikkel Svold (30:57):
Gotcha. Yeah.

Lars Linnet (30:58):
Wouldn’t it be nice to have across all suppliers, all different kinds of machines in the process, just to have this nice dashboard, for example, for runtime, for stoppages, why, what products do you run and everything? The standards can give you a framework for that and a common language. Then for the higher level, for the… See like for the financial and, we’ll say, the site manager, or say, “Wouldn’t it be nice that every time you have to do a major project on this site, that you can do a user requirement that everyone understands actually? Now you laugh, but actually has the same language and you are sure that you get what you want and it fits your site here. It also gives you a model for being able to compare things.”

Mikkel Svold (32:00):
Yeah. I was thinking that exactly. I was like, “It must also provide some kind of better way of comparing prices, better way of estimating project costs.” Because you know that, okay, once these are implemented, we know that we have this and that product. Instead of being like, “Yeah. We may have to also have half a year of amending the recipe,” for instance.

Lars Linnet (32:28):
But I also think that what’s really important is also, I heard from my former site director is that, well, if we follow this framework, there will be a higher probability that you can get more suppliers to do the same kind of work. You have access to more qualified people. What I see sometimes is that you have a supplier that come into a site, made a very specific custom job. A excellent job. There’s no question about it, but it’s so specific to the way how the supplier views the equipment and the way how to produce that going to another supplier can actually be a risk. Not just more expensive, but actually be a real risk because we’re doing heart surgery here, changing the production equipment at site.

Mikkel Svold (33:27):
Yeah.

Lars Linnet (33:27):
It’s really important. If a site can’t produce, then of course ultimately most people will be out of work. It’s a lot about trust.

Mikkel Svold (33:36):
Yeah. Basically just summing up a little bit. These standards, they are not just a compliance and documentation thing. It’s also something that ensures your operations can run much more smoothly. It ensures the quality as well not depending on who’s at work that specific day. Then also I hear you say that it’s also about securing the business, securing the future of the business, securing that you are supplier agnostic. That you can choose between different suppliers to whatever it may be. I think those should definitely be top of mind for the listeners out there. That’s all also what we have time for today. Lars Linnet, thank you so much for joining this talk.

(34:29):
I hope that I kept my promise that it wasn’t this boring talk about standards and different documentations for you out there, the listener, as well. If it was really boring, let me know because I would like to know. If you got something out of it, make sure to send it to a colleague or a friend that may also benefit from this episode. If you like it, do please also subscribe to the podcast and like this episode. It really helps us spread the word and keeps us running, sharing this knowledge. That’d be a big help. Of course, lastly, if you have any questions, do reach out to us at podcast@au2mate.com. That was automate with the two. It’s A-U-2, the number two. It was podcast@au2mate.com. I think that’s it for now. Lars Linnet, thank you so much for joining.

Lars Linnet (35:21):
Yeah. You’re welcome.

Mikkel Svold (35:23):
Thank you so much for listening.