Context is the Key to Unlocking Data

Daniel Voit and Keith Weerts of Blentech join Paul Scott to discuss the importance of context when it comes to data. They dive into how Daniel and Keith started on this path to unlocking the power of food production data, how Ignition played a crucial role in their development, and how companies can fully utilize their equipment in a short amount of time. For a video version of this podcast which includes screen demonstrations, watch here.

“It's really not uncommon to get a phone call to say, ‘The same piece of equipment, how come I'm getting a different result in Facility A versus Facility B?’ Well, the contextual data, if they're running on the same framework, can provide that.” - Daniel Voit

“Not a lot of us eat the same thing every day all of our lives. So it's about flexibility and scalability. And I believe we built an architecture that really allows folks to have the best of both of those worlds.” - Daniel Voit

“Security is paramount, it's probably the thing I think about more every day than anything else I do, and Ignition has been really key to that.” - Keith Weerts

“If you run a machine without taking advantage of the automation, you're probably never gonna get to more than 50% of the capacity of that machine.” - Keith Weerts

Bios:

Daniel Voit
Daniel Voit is the CEO for Blentech Corporation – a world-leading supplier of custom, automated and engineered food processing equipment solutions for the prepared foods, ready-meal, and restaurant commissary businesses. He has also served as President, COO, VP of Engineering, Technical Services Manager and Applications Engineer. He has a broad-basis understanding of all aspects of manufacturing and food processing. Under Daniel’s leadership, Blentech has expanded its product line to include advanced automation solutions for industrial food production applications, such as the Cooker Cloud remote reporting service and the recipe analyzer system. 

Prior to joining Blentech, Daniel held positions in R&D with Frito Lay and Quality Assurance with Norpac Foods, and worked internationally consulting in Central America. While a graduate student at UC Davis, he worked on a NASA-funded study to design and build a multi-purpose fruit and vegetable processor for a manned mission to Mars. 

Within the industry, Daniel is an advocate for Food Science as chairman of the UC Davis Bio and Agricultural Engineering Leadership Board, past chairman of the UC Davis Food Science Leadership Board and past chair of the Prepared Foods Council of FPSA. 

Daniel holds a MS degree in Food Processing from UC Davis and a BS degree in Food Science from Oregon State University.

Keith Weerts
Keith Weerts is the Chief Technical Officer for Blentech Corporation – a world-leading supplier of custom, automated and engineered food processing equipment solutions for the prepared foods, ready-meal, and restaurant commissary businesses. Early in his career, Keith worked as a process engineer and a manager working for multinational chemical companies. He regularly interacted with the research staff to design processes, products and applications for sale to the Food, Pharmaceutical, and Personal Care industries. 

Later as the Business Development Manager for Cognis, Keith worked with 47 Ph.D. researchers to turn their ideas into business opportunities. Major accomplishments included systems for remediating mines and recovery of copper from printed circuit board manufacturers. 

For the past 25 years, Keith has been focused on automating and collecting data from systems to guide business decisions. As a result,he has developed programming skills including SQL, Python, Jython, and Business Intelligence software.

Transcription:

00:38
Paul: Hello and welcome to Inductive Conversations. My name is Paul Scott, joining me today are two great guests from Blentech. I have Daniel Voit, who serves as the CEO, and Keith Weerts, who's the Chief Technical Officer. Hey guys, how are you doing?

00:50
Daniel & Keith: Doing great. Thanks for having us.

00:52
Paul: Alright, let's start the conversation with you two. Daniel, could you please give us a little bit of background on yourself, and maybe tell us a little bit about what you do?

01:02
Daniel: Great. Well, you've already given my name, it's Daniel Voit. I'm CEO here at Blentech. Blentech, we manufacture, we design, engineer, manufacture, industrial food production equipment. It's big stuff, things that make 5 - 10,000 pounds per hour, pound batches of machines making foods for restaurants, school lunches, foods you find in the stores all around the world. I myself, I'm a food scientist and a food engineer by background, I've always been interested in cooking, I've always been interested in feeding people, and this is a great way of bringing my interests in technology as well as food to add value to the world.

01:42 
Paul: That's great. Thanks for coming, I appreciate it. Keith, same thing, you want to go ahead and give us a little intro on you.

01:47
Keith: Certainly. I'm a chemical engineer by background, and I've been in the industry for a long time, I didn't get this space by being a kid. So anyhow, I've got into the development of software for integration back in the '90s, and I sort of grew up in the times when your leader [Steve Hechtman] was in the industry, developing and moving into Ignition. And actually what I did is as an integrator, I worked with Blentech a lot, and a number of other companies, and I came in contact with Ignition in 2010, and fell in love with it. And so what happened is I developed my chops on Ignition during that time period, and then Dan and I got together in about 2017, and we recognized an opportunity and that's what we're gonna talk to you a little bit about today.

02:40
Daniel: Well, in fact, Keith and I also go back to about the year 2000 is when we did our first project together, and we developed, and automated and developed a continuous stir fried egg fried rice line that we put in, in the UK. It was one of my first projects in the industry, Keith had been at it for a bit longer, but it actually kind of serves as a foundation of, we know what it's like to automate equipment with the technology that existed before what we're talking about here today in your products.

03:09
Paul: Alright, cool, so we got a background on you two. Can you talk a little bit about Blentech, maybe what the company does? What it is all about?

03:16
Daniel: Sure, absolutely. Well, we were founded by the inventor of the mechanical grape harvester, and in 1986, in fact, it's why we're in Sonoma County. Was originally, the company was gonna make winery equipment. Darrell, the founder, hired a number of folks and they said, "Hey, Darrell, not everybody drinks, but everybody eats." And he said, "That's a good point." And so we got into industrial mixing, material handling equipment, but we got our break by moving into cooking equipment. We found the opportunity to cook products like meats and things at scale, right around the time in the '90s when people were becoming quite a bit more aware about the risks of food safety, the concerns that can happen when things like E. coli get into industrial meat, as people who can get sick, cooking processes in food are generally considered a critical control point, and as a result, it's an opportunity to help make food safer.

04:13
Daniel: As a company, what we do these days is we design, manufacture, automate, integrate, and start up these industrial systems. We mostly focus on cooking and cooling, so it tends to be the types of foods that you would make on the stove top, not so much the things that you would make in the oven, or on the grill, so it's things like fillings, and soups and sauces. But there are foods like that that exist in every culture, and folks need those things all over, so we're end-to-end providing those solutions, whether if somebody wants just an individual machine or a complete line. That's what we do.

04:52
Paul: Awesome, well, thanks for the background. Appreciate it. Now, when we were talking to you guys a little bit earlier before the podcast here, I heard there's this great story about flying cross country in airplanes, and data... If you know what I'm talking about here, could you give me... Give the audience a little bit of a background on that story and what's going on there and...

05:06
Daniel: Sure, sure. And it actually goes back to that story that I mentioned, that Keith and I had done the system in Northern England in about 2000. It was a rice cooker, and back then we had email and things, actually a lot of problem solving happened with faxes back and forth as well, but it was pretty common for you to get a phone call or a fax for that matter say, "Look, there's a problem with the way the machine is running, what are we gonna do? How do we fix it?" In this case, it was, "Hey, the rice isn't cooking properly. We need it running, our customer needs these rice orders filled, we gotta get it fixed. Listen, you got four hours to fix it remotely, and... " Obviously we didn't have remote connections, right, "but you got four hours to tell us how to fix it. If not, you're getting on an airplane."

05:55
Daniel: Well, you know, we'll explore over... We didn't figure out how to fix it in four hours. We'd asked questions saying, "Hey, what's this reading? What's that reading? Tell us what you're seeing." So I get on an airplane, I fly out there, I walk in there, I see that the temperature control is not under control because there's simply a cap that's missing on the back of a machine. I put it on, tighten the clamp, sit down, 30 seconds later the rice is coming out fine. I sat on a bucket there, and watched that thing after I just flown halfway across the world to put a clamp on a cooker and thought to myself, "This is really not how this should go."

06:34
Daniel: Keith and I have talked about this a lot. I'm sure I called you up and complained about it, Keith at the moment, but I personally, I've been involved in about 700 projects or so, and we don't have problems on most of them, but every once in a while something goes wrong, and it would always be the same. I'd hop on an airplane on short notice with a stopwatch, a temperature probe, and a piece of paper. I would almost never, if ever, find a problem with the core engineering, it was usually how it was being used. And basic data could have solved that. And it's very hard not to think, "We need to find a way to identify these issues without creating this drag, this delay, this cost for everyone."

07:17
Paul: Yeah, I imagine the actual having to fly slows down things a bit, or maybe kinda ties you up a little bit. Would you say flying, or travel in general, kinda has a pretty large impact on what you guys do, or maybe even within your industry?

07:29
Daniel: Well, I mean look, it's an annoyance, but that's not really the issue. I don't mind hopping on an airplane and getting where you need to go, but the real issue is the economics of it, both for the businesses and not even so much for us, but for our customers, as well as... Look, the global impact. If you wanna look at it from that perspective as well. But if your typical machine is running 5,000-10,000 pounds an hour, and those products are selling $2-$3 a pound. Every hour that it's not performing, someone's losing $10,000-$30,000 in potential revenue per hour. You can look at best in airplane, even if it's in the United States, it's gonna get you there in a day, when you consider all the travel costs, but these types of costs are baked into the overheads of organizations, and we all take it for granted that this is just the cost of doing business, but it doesn't have to be... And that omits the environmental impact that you have from having redundant industrial systems or the cost of the fuel that brings you to and from it, it's just the cost that we all shouldn't have to bear.

08:35
Paul: So you kind of mentioned a little earlier that just being aware of how people are doing things or what they're doing, sometimes that's sort of the core problem, or maybe something that needs to be sort of identified or monitored. Can you speak a little bit more to how contextual data can make an impact?

08:49
Daniel: Yeah, I think that's it. Because when you're on the phone back in the year 2000, trying to ask why the rice isn't right, you're spot asking questions, and you're trying to figure out, "What could it be?" You're trying to diagnose a patient without seeing it. You don't have the inputs to solve it. Now look, a lot of times you could solve it, but most of the time, it took longer than it should have, and then that's where those costs came in. The context is, what happens when you do arrive, when you do fly there, the first thing you say is, "Can you walk me through what was happening?" The next thing you ask is, "What changed?" It's always the same questions. And the thing is, that context is subtracted from the data set, so even if you connect a system and have it streaming, you have to know the context of: "Who made what decision? What were you trying to do in that moment?" to determine what a resolution or a change might be to improve something in some way. That makes sense?

10:00
Paul: It does, yeah.

10:01
Daniel: Yeah.

10:01
Paul: So I'm gonna break the fourth wall a little bit. The next question we had on the outline sent to us was, what inspired you to see that context is important from data? I kind of feel like you touched upon that already. Did you have more you wanted to elaborate on there, Dan, about that topic?

10:14
Daniel: Yeah, right on. So the way this kinda came to be, and Keith, you mentioned this. Keith was standing actually here in this office, and I was saying, "You know... Hey, it's really frustrating that we still haven't found a way to have the information that solves all these problems quicker. In today's day and age, why can't we get connected to our machines remotely?" And Keith said... Well, Keith, what did you say?

10:42
Keith: I said, "Well, we can... It's really not a problem, it's just getting people to open up."

10:47
Daniel: Right, and so I'm a food scientist and food engineer, so I don't know how to do that. I do know what to do with the data once I have it, but I don't necessarily know that aspect of it. So we set up something that we called the BRS. Is that with the original term meant?

11:03
Keith: Blentech Reporting System.

11:05
Daniel: And the Remote Monitoring System, something like that. And we were so excited. We got all this data coming across, and we're like, "This is gonna solve everything." It didn't. In fact, I think it was neat, a few customers initially got... Let us get connected. We set up that quick framework, but we would get the calls with questions, and they would say, "We're having this problem, we need more throughput, or we need this... There's a problem." And now we're sifting through mountains of data, and it just didn't have the context. As an aside here, and another aspect of my life, I used to own a CrossFit gym. I ran a lot of obstacle course racing, a lot of Spartan races, and I spent a lot of time staring at my fitness tracker, and has a Garmin and... So I set it up to program my runs, and this morning I did a progression run where every mile it beeped and said, you know, "Time to step up the pace."

12:05
Daniel: So it's kind of like automating my workouts. Well, this thing connects to a platform called Strava. Strava pulls that data up and it overlays context. In that case, it overlays the GPS data, it overlays segment... Segmented data, and I would sit there and I would look at my fitness activities, and I'd look at my heart rate or my speed, and I would think to myself, "That looks a lot like a temperature profile on cooking food. How come we don't have data in a context like this?" Obviously not the same context, but relevant to what matters in industrial food production.

12:44
Paul: Awesome, alright, so you guys have two platforms, and we'll take a look at some of them later today, you have ARTIS and you have AutoChef 2.0. What inspired you to make those? And how did Ignition help with that?

12:58
Keith: Okay, so what happened is, like Dan said, we needed contextualization. And we had an AutoChef 1 from 20 years ago, it was written in PanelView and it was sluggish to be exact, and it was also... It needed a lot of work. So it was time to come up with something new. And it was, when we were looking at this, we said, in the need for contextualized data, you can't give operators the option of running recipes, you need them to run recipes, and when you pour some introducing recipes, then the data becomes contextualized by the recipe step you're in, and now you have a lot more information. So that was the basic premise for doing AutoChef 2.0. We designed it around ISA-88, which is a batching system, ideal. And that's how that system was built. And at the same time, now that we had contextualized data, ARTIS came into existence as a way of collecting that data and putting it in context in advanced tool form.

14:04
Keith: In other words, I can't... I mean, operator floor, the HMI is not the place to put the analytics that you're trying to do. The operator is just trying to make a batch, so that's what they should be doing, but someone else should be looking at the data and using all these powerful tools that exist to actually help them improve their productivity. So that was the germination point for us.

14:30
Paul: I see, awesome... I'm glad you explained AutoChef 2.0, I was gonna ask, I was curious like, "I wonder what the first iteration was." So that's great, thank you. So, okay, so you have ARTIS, you have AutoChef 2.0, how do those two interact with each other? How do they integrate with each other?

14:44
Keith: Well, okay, so taking Dan's example of the fitness tracker, this is perfect, because he described it, and as he describes it, I can tell you what you have is, the first part is a recipe. So you have to have a good system to build a recipe. Dan builds a race on his Strava, he builds what he's going to be doing, we build a recipe for how we're going to cook mac and cheese, and then we take that recipe and when we run that recipe like he runs his race, and you see the mac and cheese going through its various steps, and every time a step occurs, something is happening, we're instructing the operator to do stuff, "add this, do this... " or the machine itself is doing things.

15:26
Keith: But because we know what step we're in, we know what's supposed to be happening... What's supposed to be happening. And on top of that, if the machine is equipped with load cells, or other telemetries, we can see more of what is going on, so we have confirmation that things are happening in the correct time period, and there is no divergence from the race. So like if Dan stopped to take a break, we'd be able to see that, if an operator doesn't add the ingredient at the right time, we'll see it in the weight, and we'll know that this was not done at the right time, and we can actually catch that and report it and say, "This wasn't done at the right time, or this step took too long."

16:06
Keith: We'll get into this later when we actually do the video portion of this demonstration where you can see when the operator is taking too long to do any given step. 'Cause we're collecting statistical data on every step, every time they run this recipe. Just like Dan does the sprint up the hill, we can see on days that he has a good day and we have days that he has a bad day, and we can actually alarm the operator, or their supervisor and say, "Hey, they're having a bad day, and they're going a little slow on the steps." So that the supervisor can head out to the plant and say, "What can I do to help you to improve the throughput today?" And it may be all multitude of things. And we're not worried about that. We're worried about helping them identify the excursion in the process.

16:53
Paul: Okay, well, hey, can you walk us through a little bit how you'd... Say you have a startup, new company, a new organization, whatever, how can you get them from that sort of initial state to up 100% capacity within a relatively short amount of time? Can you kinda walk us through what that looks like?

17:08
Keith: Yeah, I mean, Dan and I have had a lot of conversations about this recently. We have... We have a few people in our organization that we're saying, "Hey, it takes too long to start up our software." In essence, it takes about a week to start up our software, to really train people on how to use it. And when you compare it to a really basic software, which is, turn on the heat, turn on the agitator, a regular operator can do that, can learn how to do that in a day, and they say, "Well, we can start using this software in a day, yet it takes us a week to start using your software." And the difference is the complexity. Yes, our software is more complex, but the major difference is, if you run a machine without taking advantage of the automation, you're probably never gonna get to more than 50% of the capacity of that machine.

17:59
Keith: What our software does is, yes, it takes us a week to get to 50%, but we keep on growing in efficiency, and it keeps on using all the data that's being collected and guiding them to say, "You can be better. You can do this faster, if you do these things." And so things we talked about is our batch comparison tool, which compares two batches side by side to show you differences, or where we do the statistical analysis of every step and we can show where there's a large divergence in proficiency. We take all that information and slowly over a three to six month period, we can build that machine up to 100% of capacity. Sometimes it happens in a month, it depends on the customer, everybody is different. But we can identify where the losses in productivity are occurring. We used to think that how fast we heated our machines was critical, yet still important, but what we find is there are a lot of other things that are actually causing batches to be made slowly, and I think Dan could probably chime in on this too.

19:04
Daniel: Yeah, I could. And I'd also like to say, on one end of the spectrum is the basic machines where you can start and stop things, and it's pretty easy to turn those things on and get them rolling in a day or two, you know, on the other end of the spectrum, was a trend that I actually think is reducing in frequency, which is the large custom-built architectures where somebody is building their own custom recipe engine, which... I've seen people do it, and I've seen them be successful over time, but I've also seen some of those systems take months if not years to get up to speed as they work through the bugs of the 0.0 rev, get up to the 0.2 or 2.0.

19:52
Daniel: So what we're recognizing and what we've done is, that there is a standardizable approach for recipe control that is modular and deployable, that gives you the advantage that you could theoretically get from a custom architecture, but you can get it in fractions of the time. So it's kind of the best of both worlds in that way, but you know... Look, absolutely. Keith mentioned that when the speed in which things heated up, when I started in the industry, 23,24 years ago, I started in the technical sales arena, and they said, "Hey, Dan, we're gonna go to trade shows, we're gonna talk to people about the value of our machines." And I said, "Great, let's do it. What are the values of the machines."

20:32
Daniel: They said, "Well, they cook 35-40% faster than a kettle." That's great. That means they can cook more food. So look, I diligently went to the shows, and look, it's true, it can absolutely heat up 30% to 40% faster than a kettle. It's fantastic. But the thing is, in a lot of foods, that doesn't matter, because the speed in which you're adding things, the sampling of the quality control... Now, look, I don't wanna walk away from the extra five or six minutes of production you can get from that, but a well-architected recipe control system can get you just as much. So at Blentech, we believe that we're in the business of providing capacity. Our goal is to provide access to the equipment that creates high quality foods at high speeds. If we can find a solution that includes software on legacy equipment and get them more production so they don't have to buy another cooker, that's a win. That's a win from our perspective.

21:40
Paul: Yeah, thanks. Alright, let's change things up a little bit. How have you too, since you have sort of platforms you're trying to provide to your customers, how do you approach security? And has Ignition sort of helped with that?

21:53
Keith: Well, security is paramount, it's probably the thing I think about more every day than anything else I do, and Ignition has been really key to that. There's various levels of Ignition, and I'm not going to delve too deep in our platform because one of the keys to good security is to not talk about what you're doing too much, but I can tell you that the identity provider platform that's now in Perspective is extremely important to us, using key fobs for us, we use either Google Titans or YubiKeys to sign in, nobody gets on our platforms without it. Our customers know, they don't need that, they have their own logins, but for those of us who are developers, who have basically the keys to the data, we need to be able to make sure it stays extremely, extremely safe, it cannot be touched by anybody. So I think we really have that nailed. By the way, I'm really excited...

22:59
Keith: It was a good plug. I think it's 8.1.16 that just came out. Was that the new one that just came out? The additional login that you have in there now that you can have a supervisor authenticate a step... I'm excited about that, that's gonna roll right into our equipment because it's just a nicer way of doing it that we didn't have before, so I'm looking forward to putting that in.

23:35
Paul: Yeah. If I can nerd out with you a little bit. I'm excited with that too, no, I saw that feature I was like, "This is great, we've been wanting something like this in Perspective for a long time." I'm glad to hear that you're excited about it as well. Yeah, I'm sure it's gonna help out quite a bit on the security front for sure.

23:37
Keith: Our team... My other team members got back to me right away, "Did you see this?" So yeah. We are pumped about that. Yeah, security, Ignition has been really helpful in that area, and I just couldn't imagine... We started out with doing Vision, and we're trying to do Vision in the cloud, and of course you can do that, but it's just not as secure. I couldn't secure it. And when Perspective came out, I had committed to... Talked to Dan and said, "I really wanna commit to this on our cloud-based platform, because we have to have this level of security that's going to come with it, and a way of tying it down, so that was really important for us to... When Perspective came out to be able to shift to that. And the other thing is, in the world of security is MQTT. MQTT wasn't really ready for prime time on Ignition five years ago, and so we didn't actually go with it for a long time, but we have been doing more and more of it, and it is in much better shape, and very easy to use now, so that is becoming the de facto method for handling a lot of our data transmission.

24:53
Paul: That's awesome. I'm glad to hear it. That's great. Alright, so what is Blentech's business approach? And what tools have you developed to achieve those goals?

25:01
Daniel: I'm trying to figure out how to attack this question here directly, 'cause there's a lot of ways we approach the market but, we work with the customers from... They had this initial inquiry where they'll call up and they'll say, "Hey look, I wanna make several thousand pounds per hour of some product," it could be a, "Hey, I've got a special mac and cheese, and it's really important recipe, we've got this loyal base, but we need to make a lot more of it, how are we gonna do it?" Or it could be somebody who wants to bring something new to the market. We work with them from the beginning to actually conceptualize the system, but then also do testing. Here in Santa Rosa, we have a test and innovation center that we have a demonstration equipment permanently installed connected with these software solutions, and we actually use the software as part of the development to define and develop those processes, run the testing, automatically create the test reports that give us all the data we need for scale-up.

26:05
Daniel: So at the core of this is people need to see it, they get peace of mind through proof of concept, but then that data we get at the testing, we need to be able to, as engineers, help them use that information or use that information on their behalf, to scale that equipment up and figure out what the throughputs are gonna be at full scale, so that their business plan comes to fruition with the appropriate cash flows, and the appropriate time frame, and so on and so forth.

26:34
Daniel: So from there on out, we get involved in actual system engineering, design of the equipment, the manufacturer of the equipment, and then physically go on-site in most cases, and start it up and train them, and then our equipment is in use for, usually, decades. And so we're providing support, and parts... On some of the equipment, some of them have almost no parts at all that need to wear, but for the life of that equipment, and keeping it rolling. So yeah... That's kind of the approach is, help them out from the beginning, all the way through that journey. And it's worked out real well.

27:15
Paul: That's great. Kind of keeping in theme with that, can you talk a little bit about the potential growth from a start-up to a mature manufacturing facility, and how different customers are served?

27:26
Daniel: Sure. Well, I think that the architecture of what we're building with the AutoChef 2 and ARTIS is probably the angle to talk about that. I'm gonna talk a little bit about how those businesses tend to grow and evolve and what they have to be able to handle the market, and then Keith you could talk about how the architecture we have services that. It's pretty common for folks to introduce some new product in the market, and of course, a lot of new products don't make it in the market. I mean, there's a lot of great product developers out there, and I've heard different statistics ranging from 50% to 90% of new product launches aren't there within a couple of years, but the resilient organizations are adaptable and flexible, and what you tend to see is a few of their SKUs do make it through.

28:13
Daniel: First they get that regional launch, then they get that national launch, and then it grows in scale with multiple outlets selling their product, and it moves from one machine to sometimes 18, or 20 machines, and during that period of time, they're also changing their formulations, they're adapting to tastes of their customer base, because, hey, we like to try new foods. And when we're walking through the stores and we see something a little bit different, we say, "Hey, I'd like to give that a try." Not a lot of us eat the same thing every day all of our lives. So it's about flexibility and scalability. And I believe we built an architecture that really allows folks to have the best of both of those worlds. Keith, can you elaborate a little bit upon that structure.

28:59
Keith: Yes. There is actually a few parts to that. First of all, that goes back to having a good recipe builder, so the recipe builder needs to be flexible to handle all the variations that a customer might wanna do. Obviously, within the constraints of the machine. The machine can only do certain things. But of course they can always add... Ask us to add on features, we can add on features, but the recipe is what keeps it all steady, but you need to be able to change recipes, you need to be able to say, "Oh, I wanna do a different recipe today to try out this." And this is where you get into development, and we do a lot of help with our customers on developing their recipes to help them produce the product that they want. The idea is, always you wanna be able to track your recipes, and so one of the features we built into ARTIS was as you're building recipes for applications, and for testing, we keep an archive of every recipe that's ever been built so that we can go back in time and find out who changed what when, because that is the bane of many a company, they don't know...

30:04
Keith: Well, first of all, if you're not, you're doing a recipe, you don't know what they're doing, and if you are doing and following a recipe, you don't know who wrote the recipe, or when it got edited. And so what we try to do is build all that into the system, is a tracking of recipes. Now, one of the things that Dan talked about is, these customers have a tendency to grow, and if they get a winning formula for a recipe, they might wanna make this product in multiple locations, and so then then the question becomes, can you share that recipe among the locations, which is another capability that we have, so that you can move recipes between locations as needed. That's sort of a more special application that isn't used by a lot of people, but it's something that I think we're gonna see a lot more of as time goes by. The larger companies recognizing the ability, the need to be able to move recipes between locations.

30:55
Keith: But just at a single location, where we have a customer who might have four machines. The fact is you build a recipe for all of them, and then you just move it between the machines as necessary, because you can move, you can say, "Today we're gonna build... We're gonna run this recipe," and then the operators on all four machines can be pulling off of that recipe and using it simultaneously, not in phase obviously, but can take advantage of it. Plus, we give them the ability to say, at the end of the day, if you're running out of an ingredient, you can scale it down, say, "I wanna... I only have this much material left, can we make 70% of a batch?" Go ahead and tell us, you can only make 70% of the batch, we will respond to that and adjust it to allow you to make just that final batch of the day, that way you don't waste ingredients at the end of the day.

31:48
Paul: Okay, so you guys have been doing this for a while now. Can you tell me a little bit about the greatest challenges that you face and how you approach them or overcome them?

31:56
Daniel: Yeah, I think... Do you mind if I field this one, Keith?

31:59
Keith: Go ahead. Well, I think we'll both be talking about this one.

32:01
Daniel: Okay. We both get to be heard on this one. I think that... Here's the truth, and I think this is true in all industries, but it's super true in the food industry. You can develop technologies faster than you can deploy them because of the entrenchment of "existing standards".

32:17
Daniel: And so we quickly realized after rolling out this, the BRS system, and then the contextualized approach, "We can do this. And we can do some pretty amazing stuff." And our development roadmap has some pretty sophisticated things in it that we've already experimented with. For example, once you have a recipe partitioned in the way we've set it up, you know which steps are operator-driven and which ones are machine-driven, you can immediately carve out the relative effect of the operators to the relative effect of the equipment. You also can compare similar categorical steps across the different formulations, you also can compare steps across multiple different sites, but it's really not uncommon to get a phone call to say, "The same piece of equipment, how come I'm getting a different result in Facility A versus Facility B?" Well, the contextual data, if they're running on the same framework, can provide that.

33:21
Daniel: I think that there's a confusion that folks have about legacy branded terminology to say, "Hey, I always use brand X components, or I always use brand Y components... " and believe that that's driving standardization in some meaningful way, which it isn't. And so our focus, really as an organization, is making the technology accessible and deployable to make sure that we get this IoT empowered cooking technology into the hands of people as a priority, rather than trying to make lots of new bells and whistles, which we've already began to make them, but getting it in use today will already be so impactful. That's the challenge, getting over that legacy hurdle. Keith, you wanna elaborate on that?

34:12
Keith: Yeah, there's... Mine are two issues: One, the ongoing issue is the adoption curve on new technology, of course, we have to go through the years that it takes to get people to adopt a technology, but you run the fear... You're gonna run into people selling fear all the time. And the fear is, "Well, we can't let you connect to our system from the outside." So the old fashioned approach is that, "We're gonna throw a wall around us and we're just not gonna let you connect." Well, if you do that, you get a walled garden approach, and you're gonna only get certain capabilities in that. And if you're a big food company, one of the big ones, they can afford to do that, because they can build all their tools in-house, and they can say, "We're not gonna let anything get outside.” Well, really, they can't, because the tools they built are pretty subpar, they just don't have the insight into the equipment to know what is important, so they build these subpar analytical systems that are just analyzing a trend and they don't really learn anything from it, and so they don't want to share.

35:35
Keith: And they believe that they have it under control, so we never get anywhere, and I've sort of said, "They'll catch up eventually." I'm targeting more the mid-size and smaller-sized companies who don't have that horsepower in-house, who can benefit from what we're doing, but they have to come to grips with, "Yes, this is a new world. We're in the world of IoT now, and you have to accept that we're in the world of IoT, and if you can't, well, we're gonna have an issue." And it takes some time. I have spent a lot of time talking to IT people, but actually, they're not too bad actually. When you get to talking to IT people, they go, "Yeah, we can do that." It's more a problem when you have this entrenched mindset, actually, at the OT level, who says, "We're not gonna let this happen." That usually is where it gets killed, and if I can convince the IT people, they convince the OT people, then we can make things happen.

36:34
Keith: That is probably the first big challenge and the second big challenge is, of course, Dan was alluding to it in a way, and that is availability of parts. Parts right now, i.e. the supply-chain disruptions, makes it difficult, in what PLC you can get and what DFD you can get, this is not an issue for Ignition, but it's certainly an issue for us from the hardware point of view, just getting the stuff we need.

37:04
Paul: Yeah. Kind of touching to the point you were bringing up there, Keith... I mean, a lot of the times when you're updating, like a customer's... Whatever, giving them a new solution or what have you, sometimes you do have to bring in new tech. Can you talk about that? Are there any hidden costs or topics, or points you wanna bring up in regards to digital transformation?

37:26 
Keith: Well, it's a point of consternation, let me put it this way. It's a point of consternation for my software developers. Because I am wanting to push our existing customers forward, and we're actually moving the platform, and of course, that's rather frustrating. They would like to leave it alone, but if I leave them alone, then I'm not really moving this whole platform forward for Blentech. Blentech needs to be... Well, to Dan's point, we need to be ahead, but we can't be too far ahead. But at the same time, for instance, a lot of our stuff was done in Vision on the HMI side of the business, and there's an opportunity now with this new login capability in 8.1.6, that allows us to do things that I think that we really should do.

38:16
Keith: So at some point we have to have a discussion, "Do we move forward? And when we move forward, do we bring the existing customers forward with us?" and that's an expense. There's certainly an expense to it, and the expense is, not so much hardware, it's mind-ware, the ability to focus on this and bring these people all forward in a very controlled manner, because you can't bring them all forward on day one. It's not like we roll on an Android update and we can throw this out to 50 customers in a day, you have to roll it forward one at a time, and that takes time, but in the end, the customers end up being benefited by this constantly improving platform. And of course, they end up liking it, but there's a cost to that. So that's part of the balance.

39:09
Daniel: I think the analogy that I have with respect to the digital transformation is, yes, there are hidden costs associated with it, but there's also an approach that you can take to digitally transform a legacy enterprise, and you really don't need to look any further than kind of what folks do when they own an older home and they wanna start using some of the smart technologies that are used in their home. You don't have to rip all the wires out of the wall to automate a couple of lights. There's a variety of ways of doing it. You can change out a couple of plugs and get a controller hub, and do these things. There's some resistance in this "all or nothing mentality." which really isn't appropriate. You can point by point attack this. And on the flip side of things, I think folks tend to approach digital transformation saying, "Hey look, I've already got the hardware. What I'll just do is I'll connect it, look at the data, and I'll slap a machine learning algorithm on it or something, and all of a sudden, insights." And I don't know how many times I've been on a call with somebody who's done that, and they put data, that flawed data into it, and produced flawed outputs because they didn't use context to extract non-meaningful data.

40:31
Daniel: If it's possible, I think the visual display of our system and our architecture would provide the perspective here in this forum to show exactly how that can be done with our framework. But also to go back to Keith's point about putting the walls up around organizations, you go that direction, and although it's possible to accomplish that on your own, you limit the ability to leverage the learnings of equipment suppliers, and you end up with those start-up timelines that can take longer, because you're having to go through the learning curve that others learned. And that's the price of isolation, I suppose. But again, it's through the demonstration of our technology that you really get it, and so if it's at all possible, it would be pretty great to share that.

41:29
Paul: Well, guys, you've been doing great answering my questions, maybe I kinda want to open the floor a little bit. Is there anything you wanted to share with our audience?

41:36
Keith: I was thinking about what Dan was talking about, the machine learning algorithm and also a few other things, and one of the things that comes out of this type of data is the ability to do digital twins. We know with all this data that we're forming, and digital twins comes, it's a hot term that's been around for a few years now, it really is a real thing, because we now have all this data on our customer's application, we can build them a digital twin that will predict in advance how long a recipe should take to run. So if they build the recipe, we should be able to come back to them. I haven't done it yet, but we can do it. This is one of those things that Dan talked about. I don't wanna get too far ahead, but if someone out there is saying, "Well, I'd really like to know how long this recipe is going to take to do." Just start using the system, and it should be able to predict for you how long this recipe will take to produce.

42:32
Daniel: Well, and it needed the contextualized steps in order to make that feasible. So it has to be built in a way where essentially the activities are unitized so that they can be summed relative to the variability or productivity that each provides on its own. The correlation of what this would look like is, when you build the recipe on our cloud platform, it would predict the time to complete it. We have all the math worked out to do this, it's all in place, and it would look a little like... I grab my phone, I set here, say I wanna drive to SFO, and then it says if I go down Golden Gate it's an hour an hour and 20, but I gotta pay a toll, maybe I go around the other way and it's two hours, but I don't have to pay the toll and I can click it and see the difference. So you could reconfigure your recipes before using them and predict the performance based on the legacy performance of your equipment, either the theoretical capability of the equipment, which would be like, without traffic or with traffic, which is the empirical performance of your team. Both of those are feasible, and then the delta between those says a lot about your capability as an organization and tells you what the growth potential of your company is.

43:54
Keith: And another thing that I think is important is, we talk about this AutoChef 2 on our Blentech equipment, but what we're realizing is that there's a huge opportunity here. This is good, really well-developed software, and it could be used well, not only on retrofitting some of our old AutoChef 1 systems, which I would love to do, but I think the beta application is, there are other people who are running recipes out there who are running with antiquated recipe systems, or don't even know that they need recipes. And we can apply this technology to that. Our competitors are out there, that we could probably automate the heck out of them and they would be... We don't wanna help them solve their kettles, but then again, we do wanna help our customers, and so we're about helping our customers improve capacity. So, we're talking to them about these things.

44:49
Paul: All right, well, I guess we'll wrap it up here. Dan and Keith, thank you very much for joining us today and sharing a bit of what you guys have been working on here. Fantastic. This seems like a great solution that... So thanks again for coming on here.

45:01
Daniel: Thank you.

45:02
Keith: Thank you for having us.