speaker-0: And welcome everybody. Welcome to today's webinar. I'm Zach Scrivan with A Belara. Thank you guys for joining from ERP to factory floor. How CIOs and Enterprises are simplifying their architecture with Fuse and Litmus. We have today here none other than Fuse and Litmus, but we also have Glenn Gardner who's gonna be starting off the session today. And he is bringing the experience of the chief executive of the C level, and then we also have Dylan Dufrain, ⁓ Don't wanna skip him. He's the architect for he's our lead architect here at Ablara. So thank you guys for joining today's webinar. Sit back and relax. We got an action-packed webinar for you. These guys are really bringing the heat for you. So and then Craig Scott, CEO of Fuse and Hossein, sales engineer with Litmus. So I'm gonna pass it over to Glenn. Thank you, Glenn.
speaker-1: All right, appreciate it, Zach. So I thought I'd kick us off with me sharing three of the biggest pain points that I experienced. For many years I had the honor of being the president of a laser manufacturing company, and there were a big three pain points that seemed imminently solvable, but it turns out were not with the IT stack that we had were a huge challenge. So my top three were number one, what I call the supply chain to factory floor disconnect. This was not at all intuitive to me when I first learned about it, but in most manufacturers, you use something called an MRP process, manufacturing resource planning process. What you do there is in order to figure out how you're going to get all of your spare parts and raw materials to build your finished goods, you put together what's called a master schedule. ⁓ It's simply a combination of the backlog of customer POs plus a forward-looking forecast, and then you take that master schedule, like a giant metaphorical spreadsheet. ⁓ And you share it with your supply chain so that you get all the parts that you need in time. So, as far as that goes, all is well. What's interesting though is the factory floor, with very rare exceptions, doesn't build directly to a customer PO. Instead, they build large batches of individual SKUs, which in turn then fill multiple line items from multiple customer POs. And that's where the disconnect lies. It turns out that there's a dramatic difference in the language that supply chain uses, which is all built up from the customer order, is kind of Fundamental unit. And the language that the factory floor uses, which uses a factory floor work order, which is a totally different thing. So for example, when on the factory floor a large batch of 50 lasers in my case gets deferred because of the absence of a part, there's nothing directly linking that to which customer POs are directly associated with it. And so there's a lot of manual labor in order to keep those two things synced up. I've actually found that that's the norm and not the exception. I'll go out on a limb and say 98% of manufacturers that I've experienced face that same difficulty. So that was one of my number one pain points. It just takes a lot of manual labor to sync up the supply chain view with the factory floor view because they speak fundamentally different languages. The second one is timely awareness of cost variances. The reality is most people that are sitting in the president's chair at a manufacturing company use something called a standard costing model where You have a standard cost for each product that you build, each SKU that you build that takes into account raw materials, labor, energy, etc. And on your books, you're recording that standard cost every single time you make a unit. However, the standard cost is by definition an estimate, and it means that there are variances every single day, every week, every single batch that you make. There's lots of variances to the standard cost. And the biggest challenges that a lot of manufacturers face is you don't tally up all of those variances until the End of the reporting period, say the end of the quarter. You can really get bitten by surprise if you have a lot of variances that are going the wrong way, and then you've committed to a certain gross margin, and you won't hit that gross margin because your standard margin was tracking perfect, but unbeknownst to you, you had lots of negative variances, lots of unfavorable variances that were stacking up, and all of a sudden your gross margin is going to be way off to what you committed to either your boss or to Wall Street or whatever the case might be. And worse than simply not meeting your gross. Margin commitment is that you could have prevented the problems earlier on. But even more important than just hitting a number, which everybody has to do, that's just a part of life. Even more importantly, you want to know as early as practical that you're having these negative variances start to stack up so that you can take corrective action. And if you don't know until after the end of the reporting period, obviously that's far too late to take action on it. And so that's pain point number two.
speaker-0: Alright, real real quick, Glenn, let me ⁓ let me jump in here. So if you guys are just joining the live webinar, Glenn's diving into the pain points that enterprise like real pain points that sea levels and enterprises are facing. But I I just real quick wanted to share, like if you guys are joining, you joined from the email, we sent out the messaging why enterprises are wanting to simplify their architecture.
speaker-1: ⁓ yeah, please.
speaker-0: We've had such a explosion of number of softwares and solutions and acquisitions and our clients that we're talking to are trying to reduce the number of logos and vendors that they're relying on. And someone in the community asked, could you just do all of this with fuse and litmus? And so that's what we're gonna actually dive into. So Glenn just shared two very detailed pain points. Pain point number one, the disconnect between supply chain and the factory floor. And then pain point two, when you're missing your mark, you don't you're not even aware of it. Enterprises are not even aware until quarter end. And more importantly than that, you've lost the ability to fix it at that moment. And so we're solving those problems with fuse and limits, but we're gonna dive into pain point three. But I just wanted to share the context of of where you are. Thank you guys for joining, ⁓ if you're joining late. So all right, Glenn, back to you.
speaker-1: Zach, well done, my friend. You said that way more concisely than me. I liked your version of it. And ⁓ pain point number three is the disconnect between the KPIs that you see in the C suite or in the executive suite and how they're actually built up from the ground up on the factory floor. the gist of this is when you're in the C suite, you see all sorts of KPIs like on time delivery, quality metrics, importantly, revenue, margin, expansion of margin, or lack thereof. ⁓ all of those metrics show up in big. A really nice, well-hone dashboard. And it looks at first glance like, ⁓ clearly, there's some type of infrastructure that can tell me exactly how all of those metrics came to be. And if I choose, I could double-click on any one of those and understand with great precision what led to you know missing gross margin by three basis points. The reality is that's not the case. It's almost always the case that behind the scenes there are lots of finance and operations professionals that are munging together all sorts of different disconnected data. Data sources that ultimately lead to what looks like a very clean KPI dashboard. Now, the problem isn't so much that the dashboard isn't accurate. Normally, because each of those people is really diligent, you get accurate KPIs. The problem is you have no way of double-clicking and figuring out the drivers of it. Because you're munging together so many different systems from disparate places on the factory floor, when you see a particular KPI that's off, you instinctively want to say, okay, Pareto that out. Give me the top three reasons that we missed our four. on delivery, on margin, on whatever it might be. ⁓ That is extraordinarily difficult to do because the same people that just put together that big dashboard then have to go and reconcile all sorts of different information to hand you what is seems like a simple question. Hey, what are the top three reasons we missed that metric?
speaker-0: This actually this actually happened at Cappy Hour, right? We knew we had downtime on the filler line, but we didn't really know why, so we had to install a downtime tracking system to be able to understand what those root causes were.
speaker-1: It did indeed, yeah. And yeah, if people don't know the reference, Cappy Hour is a fictional entity that was kind of the focus of our big presentation. So if anyone gets a chance to watch that video, that's what Zach's referencing. So Zach, I'm gonna try to be as concise as you are and state my big three again before we kind of dive into how we might solve these things. But ⁓ number one is the disconnect between supply chain and the factory floor. The gist of that one is when an order on the factory floor is deferred for any reason, be it lack of parts or otherwise, it often takes tremendous effort to map that back to the customer-facing POs that the supply chain sees. And it would be great if that didn't take as much manual effort as it does. Number two is timely awareness of cost variances. In many cases, you don't actually know your variance to standard, your variance to standard cost until after the period close, which means number one, unexpected. Surprises can happen, and number two, even worse, you're missing an opportunity to start addressing negative variances or unfavorable variances earlier. And number three is anytime you see a managerial KPI dashboard, you should assume that many people behind the scenes are munging together many different data sources to actually present what looks like a nice clean KPI dashboard. And the moment you say, ⁓ we missed this particular box, I see it's red. Give me the top three reasons, you have just incurred tens, if not hundreds, of hours of labor of lot of people behind the scenes because the data is not connected together. Those are my top three pain points. And you know what I would love? I would love if there was like a software founder that could solve all of those with a platform.
speaker-0: Mm. Now you're talking, Glenn. Thank you for sharing the problems. If you guys I'd be curious if you're joining, which one of those problems resonates the most with you? Me personally, I've I can intuitively understand the real-time costing problem, number two, but as a controls engineer, I don't think I've really had considered problem number one. Right? I'm thinking about automating the a controls engineer, you're thinking about automating the line, you're thinking about taking data off of a PLC and bringing it into maybe an OPC server at the most. When you're looking at an enterprise scale, that's where simplification is the only way to scale. And that's why I'm really excited about Fuse and Litmus. I mean, if you also want to talk about AI, two of the platforms that are leading in AI, Fuse and Litmus. That's my own personal opinion. Craig, I'd be curious to hear what you think about these pain points.
speaker-2: Yeah, so ⁓ before I jump into the pain points, I do have to say, Glenn, I'm I'm a little concerned that all of the orders I've been sending to Cappy Hour will not be getting filled. I don't know if that's an accurate statement. I thought it was a real organization.
speaker-1: Yeah. ⁓ i keep keep sending it. That address is totally real. Keep the keep the checks coming.
speaker-2: Okay. Okay. I was wondering whether there's just a delay in the shipments or what was going on here, but ⁓ now it's this is all making more sense. It's coming. So okay. ⁓ yeah, so point one, you know, that you made Glenn, I I think you're exactly right. I don't see it so much as a technology gap as it is an architecture problem. You know, how we get data from all of these disconnected systems up to ⁓ the folks that need to be able to consume this data is sort of the the point of this whole conversation. And I think for decades, you know We've tried to connect systems that were never designed really to work together, right? We've had multiple different vendors kind of working in their own little paradigms from the big box PLC guys all the way up to the big box ERP guys and all of the little point solutions in between those two ends of the spectrum. You know, the ERP, MES, supply chain planning, not to mention Excel, probably one of the most widely used MES systems that we have, right?
speaker-1: Num number one in my Excel as the dominant market leader in
speaker-2: Number one. And and they're all they're all optimized for their specific domain, right? Not for the flow of information across ⁓ those different solutions or across the enterprise. so what are companies supposed to do? They try to solve this right now with ⁓ myriad of integrations, middleware, data lakes. But none of that actually solves the problem. It's just moving the data around after the fact. Cause the other point you brought up was, you know, the real issue is that there's just no shared operational model trying to, you know, tying supply chain decisions to the execution reality. Right. All of these things live in very disparate areas. Yep.
speaker-0: What is a shared operational model even like mean?
speaker-2: So a shared operational model is is a foundational piece of what we do at Fuse. And it's putting in a relational model that represents the the physical aspect that's happening in the factory floor, and then marries that with the information models that we have stored in ERPs and PLMs and you know from an engineering and costing standpoint. And bringing these two things together and it gives a a company some Structure and some governance, but still the flexibility at the plant level. ⁓ I think Dylan and Walker talked a little bit about this on stage, right? This red and blue data concept. So that there's some consistency and you know harmonization across those different plants. So I don't know that that helps clear that up or makes it more muddy. But it's a difficult concept, right? Because I think ⁓ you know, in large part the Problems that we're solving, ⁓ you know, a combination of fuse and litmus are problems that have people have tried to solve for decades, but they have done it with duct tape and and band-aids and bubblegum, and you know, a lot of those projects have not succeeded ⁓ succeeded. And ⁓ the reason why they haven't succeeded, in my view, is that the folks that are funding those projects and those initiatives aren't seeing the value from them. And it's still because there's that struggle between getting the data from where it's originating to the people that need to consume it without the latency.
speaker-0: When when I when I was on the when I met Walker Reynolds and we were on that really large enterprise oil and gas data project, this is one of my first introductions to the power of of unifying namespaces. We consulted with them for about three weeks straight and they had like over fifty different software packages across all of the different domains and departments and business units. This is why the message that we're focusing on is simplifying the enterprise stack.
speaker-2: ⁓ we see it all the time too, Zach. I mean, and every customer that calls us up, you know, they come to us oftentimes with a a really elaborate diagram of their existing application, you know, footprint, and there's, you know, 20, 30, 40 different applications on there. ⁓ you know, and then they'll share with us maybe, you know, the list of things that they're looking at plugging into that existing infrastructure, which includes another dozen or so things, you know, not to mention the thousands of software. Vendors that are out there trying to solve these these little micro pain points. I kind of look at it like death by a thousand cuts, right? You start implementing all of these various point solutions and you know duct tape between them and fragile integrations and software licenses and multiple multiple different partners you're working with. The the risk to the organization is literally just through the roof. And so by making this a much more simple stack and a simple architecture, you greatly reduce the risk, you greatly ⁓ increase the potential for success, and you get the data where it needs to go when it needs to go there.
speaker-0: Like let us know in if you're joining in the comments. Like how many pieces of software are in your s architecture? Is it less than ten? Is it more than ten? You know, there's no single OEM that could solve all of your problems, right? But you could solve most of them with just two.
speaker-2: Yeah, I think that's the story that we're trying to tell here a little bit. And I think ⁓ Glenn, I'll I'll kind of come back to to some of your points, right? You know, the cost visibility problem. I worked as a system integrator implementing ERP systems in global organizations and realizing this same thing for almost a decade that new ERP system never solves your problems, never gives you the visibility that you want. And I've never seen it produce an ROI outside of The fact that it it made somebody have some you know job satisfaction five years after you know they went through the implementation process. ⁓ but the that visibility problem isn't about reporting, it's not about the lack of information, it's the latency in getting that information where it needs to be. And by the time those variances are showing up in your ERP or your finance system, the damage has long been done. There is no way to fix what happened yesterday. There's you can only look going forward from an operational standpoint. How do we improve this? But now you've already lost a month or a quarter or half a year by the time all of those numbers I aggregated. And I think your point is very valid on the tens or hundreds of hours that are spent, not just at corporate, but at the plant level. I I've helped so many plant managers try to implement these systems, and they just have teams of people that are just collecting data from. Spreadsheets and operators and just to bubble that up to corporate. ⁓ or what happens at the end of the year when the when the new ⁓ you know the the budgeting comes out, right? The forecast for next year. Every plant receives this massive spreadsheet for what the the company thinks, you know, next year's budget needs to look like. And we spend weeks combing through this and trying to implement this.
speaker-1: Yeah, it's it's crazy. And what what the real kicker is your best people, right? It it's not you don't give that to your B team because if there's any mistakes in that roll up, there could be real huge consequences. So you take all of your A players, you bury them in endless spreadsheets and disparate data. They spend tens and usually hundreds of hours reconciling it, and there's no value added to the end customer. And your A players are off the field, mired in all of that. That that's kind of what That's what drives me to fix this problem fundamentally. It frees up the A players to do mu higher value add stuff.
speaker-2: A a hundred percent. You know, let them focus on solving other solutions or ⁓ you know, the continuous improvement that's really gonna drive ⁓ those costs down and those margins up. ⁓ when they're focused on just collecting data and putting it in a chart and graph for someone else to look at, there's no problems are being solved.
speaker-1: Right. Exactly. Exactly.
speaker-2: You I I think it's that real time operational context, right? And that's that's one of the big reasons why, you know, we we've got litmus here with us, you know, as well to to help us bridge this gap from, you know, what changed on the line, what what constraint emerged in this process and and what decision was made locally that impacted this cost ultimately, right? And being able to do that in real time and and do that in a small number of systems, a small number of applications. So it's highly efficient and highly available. Available to everyone in the organization. We don't have to worry about who has a user license to this tool that we're using over here, or who has access to that tool over there. Everybody should have access to everything. And that's the reason why we do unlimited user-based licensing. You know, we don't want to penalize any of our customers for adding people to the system to have visibility to the data that they own. There's a lot of questions pouring in here. So I I wanted to ⁓ you had brought up a third point too, Glenn. I think bridging the the C suite KPIs to the plant floor is ⁓ in my experience, that's where most transformations have failed. And everybody talks about the revenue and the margin, on-time delivery and quality. Those are hugely important in in an industrial operation. But those are not things you can manage directly. ⁓ those are emergent outcomes of thousands of micro decisions that get made on the factory floor. So I think that's critical for a lot of executives to understand. And that's one of the reasons why I say and I advocate that, you know, putting a new ERP system in. doesn't solve any of these problems. If ERP is anything, it's anything but micro. It's very macro. And so you're missing all of that detail, ⁓ all of that minutiae that happens. And getting that into that operational model, Zach, that you were you were asking about, that's what's key. Because in the operational model is where all of these events live. And these events live right alongside, the the macro and the micro data essentially come together and they live in one in one space. So you have both perspectives.
speaker-0: I I love that. I mean I I like your analogy of when you called it like the DNA of the business. And I'd love to get Dylan's input here as like in as the architect before we bring on litmus. You know, I like what I was saying is anyone who if you're familiar with four point ⁓ solutions and the IIT university, they have this MES boot camp. Actually I think you could watch like the first session for free if you're a member on their YouTube channel. Anyways, in the very first session, the very first thing you do when you're building an MES From scratch is you're building out we use I think MySQL to build out a relational database so we could store events that were coming off of the machines to store sta state changes. We use the state changes to do downtime tracking, we use that and connection with standard rates to be able to track performance and quality to ultimately get OEE. But imagine that's when it really clicked for me with Fuse. Because if I wanted to build an MES infuse, all of that database configuration is really abstracted for me as the application developer, as the owner of the solution. I just get to see the model in the data model designer and it abstracts all of the technical underworkings for me. And I was like, wow, that's now I get to focus on solving problems.
speaker-2: I am curious, Dylan, what are your thoughts? I mean, you're the architect. I'm just the software vendor. I think this sounds wonderful. but in practice, you know, w you working with so many different organizations, what where are you seeing?
speaker-3: Yeah, I think the ⁓ reality comes down to getting the data on the plant floor. I mean, Glenn talked a lot about the different pain points we feel. It was the disconnection between the supply chain, there was the ⁓ timely awareness and cost variance, how that affects the financials and the core, the results and all that. As well as just linking the needs of these C suite level KPIs, the metrics that feed those, and how do we link those metrics back down to actual data points on the plant floor? Fuse gives us a really good suite to do a lot of that orchestration, a lot of that law logic, and integrate heavily with a lot of the enterprise systems. But with that, we need to get the initial KPIs from somewhere. And that comes down into the OT domain, more so than the IT. And Fuse is a The IT software that understands OT. It's an enterprise grade platform that you can build on top of, you can solve all your own problems with the data flows, the screens and all that. It is that cloud native. You can build your MES in it, you can build your WMS, you can build your supply chain software, and you can solve all those problems that Glenn talked about in Fuse when you have that data coming in from the edge. When you're talking a single site, it's pretty simple. Everything kind of comes together. But once you start scaling, once you go from one line to two lines to three sites to four sites to a hundred sites. Now we need to f figure out a solid, not just a solid IT strategy, but a solid data foundation, a solid OT layer of how do we get this very messy, very disconnected and very disparate data from all these different controllers, from these different devices, these different machines that oftentimes don't speak the same language. And that's where something like litmus really comes in handy. You got the device drivers, you got the modeling, and it allows us to pull down to the plant floor for a second and we'll get back up to the metrics and the KPIs. But as I said, that data has to come from somewhere. So that data starts typically in a PLC, in a controller, in a robot, somewhere on the plant floor in some machine or some device. There's a handful of different protocols they talk and different ways they can get there, different networks, different serial protocols, things like that, but they don't usually do too well at talking to each other. And even if they do, everybody who programs that controller, even from the same OEM, does so in a slightly different way next month than they did last month. I mean, unless you're in some very disciplined industries like automotive or things like that, where you get some the luxury of consistency and you can kind of force the vendors to do things a certain way. Most industry can't. And so you're gonna get from the same machine builder the same machine with very different code bases and different logic. From an IT perspective, you should just have a data model. And that model and that data point maps up to that metric, maps up to Fuse, and everything goes. But in the real world on the plant floor, we need to get it into that consistent data model as close to the edge as possible. And for me, that's where Litmus comes in with 250 plus device drivers. You've got the digital twin capability, which for the sake of conversation with the audience and stuff here, their version of digital twin is a lot more like data modeling. ⁓ so if you're familiar with ignition and UDTs and stuff, it's a very similar approach where you've got your logic, you've got your expressions and your scripts that can then derive values from other values in a hierarchical model. And between the device connectivity and that data modeling, we can then plug that in through various means. ⁓ we can do REST APIs, we could do the OPC connector, we could do MQTT or various different ways of getting that data into Fuse after it's been modeled and consistent at the edge. And then from there, we can tie those data models at the edge into various hierarchies and layers of metrics that eventually become KPIs and eventually solve Glenn's problem in the C suite. But I'm sure Hussein, you got some ideas on how it might not be that easy, but how litmus can help.
speaker-2: Well, you actually did such a good job of explaining that, right? So that's as I was thinking about ⁓ how we can actually ⁓ talk about all this, right? So ⁓ you're absolutely correct. We to kind of tee up all the conversations, like ⁓ what Glenn had said, right, we have the multiple connectors ⁓ that will allow us to simplify that architecture to pull from what Greg had said Craig had said, right? And ⁓ We can kind of model that very simply at the edge ⁓ and prepare that data, send it up in real time, right? Which again, ⁓ Glam to your second point, that that is very important, right? Because ⁓ otherwise you really would not be able to do that. You would you'd be waiting until the end of the month or the end of the quarter, right? At base best case scenario. ⁓ and one of the other tools that we have that is kind of embedded in our product is you can actually add metadata. ⁓ to make sure your your operation at a high level when you're rolling up all that data ⁓ and getting it to your systems, ⁓ how does that actually all look at the same time? Right? You can actually sift through that ⁓ when you have all that data. So basically in a to kind of T like basically ⁓ wrap it all up, right? You can simplify the architecture because everything is under one platform. ⁓ and we have supporting ⁓ software to be able to kind of make sure that that is scaling in that one platform, the Litmus Edge, ⁓ like the Edge Manager, right? And then we also will be able to be the unified namespace. Zach, what you said is giving that flexibility ⁓ at the edge to kind of create the way that you want that unified namespace that you need ⁓ essentially all at once as well ⁓ using a platform.
speaker-0: I wanna translate that into like maybe like ⁓ from my perspective. ⁓ you know, this is one of the big challenges on that enterprise project and enterprise scale. You might be able to have certain platforms that ha have a limited selection of data collection, but let's just talk about the elephant in the room. A lot of the companies out there are using Kepware for data collection because honestly they had built some really great drivers. One of the limitations that I didn't even realize was a problem until more recently. over the past handful of years was running that footprint on a Windows installation like it was very limiting. So being able to have containers to deploy containered solutions from an enterprise IT perspective is almost a minimum technical requirement. And so a lot of companies are they're using Kepport now and they're literally switching over to litmus to standardize on at the enterprise. Now I want the best for Kepware. I w I hope that they're able to adapt and we'll see what's coming from them. They've been sold twice in the last year, which has been a little bit rough, but it took me a while to really see the value of litmus. And so we hope that through our presentation today we can help communicate that. Because again, sometimes you're not you're not considering it because you're like, I'm already doing this these jobs with this tool here. What's the benefit?
speaker-2: Yeah.
speaker-0: And and ⁓ so yeah, like really that being able to model within Litmus, I think that's one of the key differentiators, right? Not only from deployment in containers, but also being able to model, like Dylan said, right at the edge. And then just it could no matter what you really throw at it or come across, you could probably connect to it with litmus and then they're the best at creating drivers. Dylan, how what do you feel like litmus is missing and then what do you feel like the industry needs to standardize on at the edge?
speaker-3: Yeah, I think the biggest one is just data modeling as close to the edge as possible. So Litmus has a lot of good capability of modeling that data directly above the PLC layer, but that shouldn't discount, especially in greenfield sites or for any of the machine builders or OEMs listening, that modeling should be happening at least at a basic level with consistent practices and good hygiene in the PLCs themselves. So the more consistent your controls layer programs are. The more consistent and the faster you can deploy those data models on top, the faster you can build your SCADA, your HMI screens, the faster you can troubleshoot. And the lower down the stack, even down into the PLC programs themselves, the more, and we might not call it data modeling at that point, but the more consistency, the more good hygiene, and the more best practices you can follow in the name of consistency into that controller layer as possible, the more benefits you're gonna see across the board. And currently litmus is one of the few tools that allows us to do that modeling, maybe not in the controller, because most people who are programming the PLCs and most OEMs aren't doing that yet. But at least that allows us to do it one layer above them, even to the point with simple enough user interfaces that you could say, hey machine builder, you know the system inside and out. Can you make the data model for us? Or can you at least document it? And you get their insights on how to build it faster. Because despite them not doing the modeling in any real way, They have the mechanical design. They wrote the program. They know where things are. So the more you can involve your OEM and the person who wrote that code in the first place, even in the discussions of data models, the better you're gonna have. And once you get those data models built, we'll just say in litmus for now and kind of ignore southbound for the sake of this conversation. Once we get those data models built in litmus, we've added the ⁓ metadata, we've added things like units of measure, we've added maybe some aggregate. ⁓ metrics and values that we can derive from other ones. ⁓ we probably are historizing that somewhere at the edge, but then those data models that we have in litmus can then be mapped one to one or at least in a way that grows even further and more standardized in Fuse. And in the data models and in the schema that we build in Fuse, if that's consistent with the data models in litmus, we can carry that up and we can add context the further up we go in the stack, the more context we add. And then from there, depending on the needs, the industry, and how far we're going at the edge, which is going to depend on every different customer with the needs they have, we'll determine how big or small or how detailed those models happen to be in litmus, what gets added in Fuse, and then what then from Fuse, where does that data go back to? And what context is that pulling from other systems like your ERP or your warehouse management or your quality systems? And You get this orchestration going up and down with these shared common data models that are living in different platforms but share the same foundation. And I think that's where the real power lies is consistency throughout the stack, as far up and as far down as you can go.
speaker-0: I love that. I mean we had a question come in, ⁓ I'm gonna drop it to you guys but Literally we would spend most of our time, even the same assets weren't the same, right? And so you know, that's the power of litmus, being able to to to model that, you know, just literally using like JSON objects and and configuration as you know, code. Like these these these platforms are just so much more AI ready. It's insane. Honestly one of the things I think like when I think of litmus, very strong at the edge data collection. It's one of its missing elements is visualization, right? Building applications and that's I think one of us's strong points. And then as well as that enterprise modeling your enterprise data and then litmus modeling your edge data. Those just pair so well together. the question that came in ⁓ was from Patrick said ERP plant floor integration is critical but don't overlook security implications. Industrial IoT data flows create new attack vectors. that requires zero trust architectures and encrypted data exchange protocols.
speaker-3: I'll let Craig go deeper on that, but I'll add real quick that's where Fuse fits in because Fuse is not an in industrial IoT data flow. Fuse is an IT platform with all of that baked in that's connecting to your ERP, where we can then build logic and such into those flows to effuscate and regulate who can access what, where it can go, and who can see various parts of it. But Craig, you're probably better suited to talk about your own security.
speaker-2: Yeah, yeah, sure. I mean, this question comes up all the time. You know, and we we started the platform with built-in role-based access control policies. Data's encrypted in motion and at rest. It's highly secure. What's really nice about that is being an event-driven architecture, the backbone of the platform is UNS. So now you've got a UNS with tight role-based access controls applied over top of it, which is kind of not what you see in a traditional ⁓ OT deployed UNS. And then In addition, we've got the MCP capabilities, which is inherently insecure, right? So we've applied all of these concepts in our IT focused platform to get our hands on OT data from litmus, right? So that we can make it secure. And governed and of course scalable across the enterprise. And it's important for us because most of our customers are on our public-hosted cloud, publicly traded companies that are trusting us to move their data about, you know, hundreds of different plants and keep it secure for them. So and I'm sure once we get down into the DMZ. That's where things like our fuse gateway comes into play. So that gateway will connect through the firewall using WebSockets. So it's only outbound communication. We're not plugging any holes. That's the tool that we connect directly to Litmus at the edge with. And Zach, to your point, visualizations at the edge are critical. We want to see that data. And what that gateway allows us to do is subscribe to things that we're able to collect in Litmus and immediately visualize those through dashboards and screens that we can. develop in Fuse. ⁓ and that's all deployed at the edge through our gateway. So it's it's a hybrid concept. So those are running locally. If you lose internet connectivity, they still continue to run. And then we have a a native ⁓ built in ⁓ store and forward capability there as well. So if any of that stuff actually needs to make it up to the cloud, ⁓ it will once that connection comes back online. So yeah.
speaker-3: And for the sake of fairness too, on Litmus's side, if you have Litmus and Litmus alone, they do have visualization and data flows with Grafana and Node Red. And in isolation below the DMZ, those work really well for what they're made for on the industrial side. But when we're talking about feature overlap and where they complement each other, is if we use the data flows and the visualization options inside of Litmus, that allows for much more IT secure and regulated with role based access controls and various security pieces that Craig just talked about that can be on top of and really extend those capabilities. So one or the other or both you can do a lot and there's some feature overlap there. But I think the combination of the two is where things really get beautiful.
speaker-2: Yep. Yep. Yeah, it's kind of back to the you know, the genesis of the conversation is how do we, you know, get the most value out of the slimmest set of solutions that we can possibly deploy both at the edge and you know at the enterprise.
speaker-0: 'Cause if you have too many solutions, you don't even see you can't even see everything that you have. You don't have a complete documented list. That's why companies are hiring us to consult with them just to help figure out where where to even start. Which by the way, if you want to know where to start, Dylan's doing a workshop on that. And also Dylan wrote a wrote the book on the Phantom palette. So definitely pick up a copy and support that. But yeah, like I I'm really excited about getting like a real deeper integration with Litmus Infuse. If you're in an IT team and you're using Google Cloud, or you're using AWS cloud and you're using their edge connectors, you're already using Litmus Edge, right? That's kind of what I want to see for people that are using the Fuse Cloud. And really it's it's just so funny because I kind of went through this, it's like a whole like life cycle. It's like you have like this epiphany phase. If you end up building, if you end up just kind of building your own solution and you you start scaling it and you start building on like a cloud platform. You probably would end up building something that would look a lot like litmus infuse. So why not just go with litmus infused? You know, that's what I'm asking.
speaker-3: Yep. And we've talked a lot here about greenfield or ideal scenarios with using Litmus and Fuse. But to add, just so we don't lose the plot on the other side too, the more common brownfield implementation, where we've got existing PLCs, we've got existing HMIs, we might even have existing SCADA systems or IoT infrastructure in place. That's part of where both platforms allow for really good connectivity into existing systems through various protocols like OPCUA MQTT and other brokers and REST APIs and just all sorts of different things. So you can make use of your existing base, your existing SCADA system, and then maybe you can start putting new connections in through Litmus and Fuse and slowly over time migrating. But just because you already have a SCADA system in place or you already have something connecting to your devices doesn't mean that you can't gain value from and even eventually migrate to if you choose fully into the litmus and fuse stack. But Litmus and Fuse exist very well alongside existing OPC servers, existing SCADA platforms, existing historians, and things like that. And there's very there's too many ways to go into it a podcast. So going and saying this is exactly how you would do it would take another four hours. But they I mean Litmus has their two hundred and fifty protocols. Craig, you Fuse supports just about everything I know under the sun too. And between the two of them, you're not gonna find too many things that you can't talk to.
speaker-0: I'm glad you you know, you took the words right out of my mouth, Dylan. I'm glad you mentioned the credit where it's due. They do have visualization and honestly if you looked at the Cappy Hour approved session, what Tupinix built inside of Litmus, it's actually pretty incredible and it helped save the company like over a quarter million dollars and we got paid back within ninety days on that ROI. So like, you know, Dylan, as the architect, how would you connect Fuse to litmus and how would you wanna see that ⁓ connection evolve.
speaker-3: I think the most realistic in the early term, and this is a conversation that Fuse and Litmus would have to have, but my preference would be that there be a way to deploy and manage litmus models and things like that, almost the enterprise management tool they've got there from Fuse, where IT is already working in one more unified platform. But the other angle would be too having the Fuse edge gateway. be one of the applications on the litmus store as well. So we could run on the same infrastructure that litmus is running on. So you're gonna have some customers and some clients and some teams that want separate images and separate VMs for everything for various segmentation and backup reasons. And you're gonna have others who want the smallest footprint possible, sometimes even running on bare metal. And that's where we can use the litmus operating system running on its own VM, running containers within it, one of which being the Fuse Edge Gateway. And then Fuse can talk very directly through that connection on that local network on that same machine to the OPC server in Litmus is probably going to be the most efficient, most deterministic way to get that data. And then from there we can pipe that up to the cloud using Fuse's edge gateway, their AMQP, their store and forward and all that kind of stuff.
speaker-2: That one tripped me up too.
speaker-3: Ha ha.
speaker-0: All right. Craig I'll pass it to you. Anything you'd want to see or any anything you wanna add?
speaker-2: Yeah, I I ⁓ yeah, I echo ⁓ Dylan on that. You know, these are some conversations that you know, so we got really amped up on litmus. ⁓ just kind of going into prove it this year. You know, we it wasn't something that was really on our radar too much, but we noticed that it kept coming up more and more often in conversations we were having with our current customers and ⁓ potential customers that, you know, they were they were looking at litmus. So we did a little bit more digging into what that would look like ⁓ had a great conversation with Watsal over there and you know, several since then with Sam Elsner and you know, we did a ⁓ podcast with him and I think ⁓ all of these things are in the works currently ⁓ as we kind of work through finalizing and formalizing our ⁓ technology alliance with Litmus and you know, getting these things in place. So hopefully that will just grease the skids for a lot of organizations that that wanna do this. it's all, you know, fully functional the way it is, but I think we can kind of lower some of the friction points by doing some of the things Dylan mentioned.
speaker-0: Hasn't.
speaker-2: Thanks, Zach. And I think what I wanna leave the audience with is to think about a as you said, Zach, you can build all these things up and just have to probably containerize a bunch of things and ⁓ we deal with a lot of smart people that that are very capable. ⁓ I I think it's important to to understand why you don't wanna do it, right? ⁓ and maybe you could do that one or two plans, but those point to point solutions, ⁓ They will cause you problems, right? As soon as one of those points break, all of a sudden you have a problem. And and then secondly is is the scale piece, right? We've been talking about scale as an underlying message this whole time. ⁓ if you have anywhere more than like two or three plants, you're you're definitely gonna fail. I I I can guarantee you that 'cause I've seen that over and over, right? ⁓ you will have a you will have to have a really large team to to do this. So I think you will the same way you wouldn't create your own operating system, right? That why would you you go and buy out of Windows or Linux, right? Why would you why would you create your own data infrastructure ⁓ essentially, right? Or really in your management ⁓ tool essentially. So that's kind of what I like to leave the audience with to kind of think about that and let that sink in.
speaker-3: And I think from there we'd want to get some of Glenn's feedback here on that enterprise at that executive level there and how this all ties back into the business side of things. But to tee that up a little bit, I just wanna add that one of the things we've heard about scale and things, we've got two different platforms that do two different parts of the puzzle. And together they don't only complement each other, but they de-risk each other. And from there, let's get back into the executive scope. And what do you think about all this, Glenn? How does this tie back to those original KPIs?
speaker-1: Yeah. Yeah, so we we like these webinars to be educational. Our our goal first and foremost in any webinar like this is to be educational. And the trickiest thing that people come to us with is hey, there's fifty vendors in the industry four point zero space. They all seem reputable. In fact, many of them, most of them are reputable. How the heck do I make sense of fifty options? It's very intentional that we chose to have Fuse and Litmus on the podcast here because they're really important pivot points, arguably the two most important pivot points in the whole ecosystem. Zach alluded to this earlier. Earlier, if you were to go back 20 years, rewind in your mind 20 years ago, it's 2005, 2006, all you have is an ERP and PLCs and a fine historian, and like nothing in between. Like that's all you've got. And then step through your daily interactions and the pain points that you would incur and think about what you would build if you were in that situation. So like start from the top down. You're ⁓ you are ERP minded, you kind of are starting from the corporate KPIs and going down. If you had a wish list of problems and you solved them top down, you would build Fuse. If you had a wish list of problems and you solve them kind of edge in or bottom up if you will from the factory floor, you'd build litmus. And so I like to encourage everybody, Fuse and litmus won't solve 100% of your problems. Nobody would ever claim that, but they're really important anchor points to understand. And if you dive deep on those two platforms, you can absolutely fuse the gap with other software packages that we love, like we love ignition, we love flow software, those are awesome packages. But if you start with Fuse And litness, you'll really understand the nature of the problem you're trying to solve. And then you can stitch together a great full stack solution.
speaker-0: Thank you, Glenn. Thank you guys again for joining. Let me break it down for you guys here if you're s if you're watching. Alright, so this is the webinar recording page. If you're on this page, if you're watching the webinar recordings, some of you may have had ac issues accessing the YouTube live stream. We do apologize. We're gonna email you all the link to the recording. On this page, if you scroll down, there's a form to get in contact with us, Avellara. Companies are coming to Avalara To help them architect their solutions, to help understand their problems, and to help architect agnostic solutions. You know, Dylan is very busy, but we are accepting a few y if you're a lighthouse partner, we essentially we come in and we do a digital transformation workshop. We help architect the solution and we help get you hitting the ground running. Fill out your information. What is your biggest operational challenge right now? And why do you want to be a lighthouse partner? Definitely fill out that form. That's the best way to get into the front of the line. Especially if you're looking at views or litmus.
speaker-3: Yep, and off that real quick, on the any platform piece there too, with a sorry, not sorry to both litmus and fuse here. Despite being on a podcast here and saying how much we love you guys, we don't start with a hey, you need fuse or you need litmus. So every time I go into an engagement, we have friends, we have partners, ⁓ we have relationships with different software companies. But every time we go into an engagement, we're gonna start from a fresh sheet of paper, figure out what you already have, what you need, and If that happens to be fuse or litmus, which are patterns that come up quite often, then that's what we'll recommend. And but at the end of the day, our interests are aligned with you, the end user, and your architecture and putting what works for you in place. ⁓ and that not only helps you, it helps our other software partners and make sure that the right fit is in the right place and everybody gets what they need and everybody works well together.
speaker-1: While stuff. Sorry, Craig, in the scene. And you
speaker-0: So we'll we'll go ahead and wrap it up here. If there are any final c questions, please feel free to leave them in the chat. ⁓ or if you want to reach out to us and work with Abelara, we'd be happy to to work with you, fill out that Lighthouse Partner application form. Hossein, any final closing thoughts?
speaker-2: No, this was an awesome conversation. Thank you guys for for having them as part of it.
speaker-0: I think you really ha you had that mic drop moment when you said let that sink in. Remember this, even if you have ignition or another tool, this isn't a rip and replace trap. We connect what you got and imagine that. Thank you guys for joining. We'll see you guys in the next webinar. Thank you, everyone. Bye.
speaker-1: For watching. If you like this content, don't forget to like this video and subscribe to the channel for more content like this. Ascend, see more, improve more.
speaker-1: All right, appreciate it, Zach. So I thought I'd kick us off with me sharing three of the biggest pain points that I experienced. For many years I had the honor of being the president of a laser manufacturing company, and there were a big three pain points that seemed imminently solvable, but it turns out were not with the IT stack that we had were a huge challenge. So my top three were number one, what I call the supply chain to factory floor disconnect. This was not at all intuitive to me when I first learned about it, but in most manufacturers, you use something called an MRP process, manufacturing resource planning process. What you do there is in order to figure out how you're going to get all of your spare parts and raw materials to build your finished goods, you put together what's called a master schedule. ⁓ It's simply a combination of the backlog of customer POs plus a forward-looking forecast, and then you take that master schedule, like a giant metaphorical spreadsheet. ⁓ And you share it with your supply chain so that you get all the parts that you need in time. So, as far as that goes, all is well. What's interesting though is the factory floor, with very rare exceptions, doesn't build directly to a customer PO. Instead, they build large batches of individual SKUs, which in turn then fill multiple line items from multiple customer POs. And that's where the disconnect lies. It turns out that there's a dramatic difference in the language that supply chain uses, which is all built up from the customer order, is kind of Fundamental unit. And the language that the factory floor uses, which uses a factory floor work order, which is a totally different thing. So for example, when on the factory floor a large batch of 50 lasers in my case gets deferred because of the absence of a part, there's nothing directly linking that to which customer POs are directly associated with it. And so there's a lot of manual labor in order to keep those two things synced up. I've actually found that that's the norm and not the exception. I'll go out on a limb and say 98% of manufacturers that I've experienced face that same difficulty. So that was one of my number one pain points. It just takes a lot of manual labor to sync up the supply chain view with the factory floor view because they speak fundamentally different languages. The second one is timely awareness of cost variances. The reality is most people that are sitting in the president's chair at a manufacturing company use something called a standard costing model where You have a standard cost for each product that you build, each SKU that you build that takes into account raw materials, labor, energy, etc. And on your books, you're recording that standard cost every single time you make a unit. However, the standard cost is by definition an estimate, and it means that there are variances every single day, every week, every single batch that you make. There's lots of variances to the standard cost. And the biggest challenges that a lot of manufacturers face is you don't tally up all of those variances until the End of the reporting period, say the end of the quarter. You can really get bitten by surprise if you have a lot of variances that are going the wrong way, and then you've committed to a certain gross margin, and you won't hit that gross margin because your standard margin was tracking perfect, but unbeknownst to you, you had lots of negative variances, lots of unfavorable variances that were stacking up, and all of a sudden your gross margin is going to be way off to what you committed to either your boss or to Wall Street or whatever the case might be. And worse than simply not meeting your gross. Margin commitment is that you could have prevented the problems earlier on. But even more important than just hitting a number, which everybody has to do, that's just a part of life. Even more importantly, you want to know as early as practical that you're having these negative variances start to stack up so that you can take corrective action. And if you don't know until after the end of the reporting period, obviously that's far too late to take action on it. And so that's pain point number two.
speaker-0: Alright, real real quick, Glenn, let me ⁓ let me jump in here. So if you guys are just joining the live webinar, Glenn's diving into the pain points that enterprise like real pain points that sea levels and enterprises are facing. But I I just real quick wanted to share, like if you guys are joining, you joined from the email, we sent out the messaging why enterprises are wanting to simplify their architecture.
speaker-1: ⁓ yeah, please.
speaker-0: We've had such a explosion of number of softwares and solutions and acquisitions and our clients that we're talking to are trying to reduce the number of logos and vendors that they're relying on. And someone in the community asked, could you just do all of this with fuse and litmus? And so that's what we're gonna actually dive into. So Glenn just shared two very detailed pain points. Pain point number one, the disconnect between supply chain and the factory floor. And then pain point two, when you're missing your mark, you don't you're not even aware of it. Enterprises are not even aware until quarter end. And more importantly than that, you've lost the ability to fix it at that moment. And so we're solving those problems with fuse and limits, but we're gonna dive into pain point three. But I just wanted to share the context of of where you are. Thank you guys for joining, ⁓ if you're joining late. So all right, Glenn, back to you.
speaker-1: Zach, well done, my friend. You said that way more concisely than me. I liked your version of it. And ⁓ pain point number three is the disconnect between the KPIs that you see in the C suite or in the executive suite and how they're actually built up from the ground up on the factory floor. the gist of this is when you're in the C suite, you see all sorts of KPIs like on time delivery, quality metrics, importantly, revenue, margin, expansion of margin, or lack thereof. ⁓ all of those metrics show up in big. A really nice, well-hone dashboard. And it looks at first glance like, ⁓ clearly, there's some type of infrastructure that can tell me exactly how all of those metrics came to be. And if I choose, I could double-click on any one of those and understand with great precision what led to you know missing gross margin by three basis points. The reality is that's not the case. It's almost always the case that behind the scenes there are lots of finance and operations professionals that are munging together all sorts of different disconnected data. Data sources that ultimately lead to what looks like a very clean KPI dashboard. Now, the problem isn't so much that the dashboard isn't accurate. Normally, because each of those people is really diligent, you get accurate KPIs. The problem is you have no way of double-clicking and figuring out the drivers of it. Because you're munging together so many different systems from disparate places on the factory floor, when you see a particular KPI that's off, you instinctively want to say, okay, Pareto that out. Give me the top three reasons that we missed our four. on delivery, on margin, on whatever it might be. ⁓ That is extraordinarily difficult to do because the same people that just put together that big dashboard then have to go and reconcile all sorts of different information to hand you what is seems like a simple question. Hey, what are the top three reasons we missed that metric?
speaker-0: This actually this actually happened at Cappy Hour, right? We knew we had downtime on the filler line, but we didn't really know why, so we had to install a downtime tracking system to be able to understand what those root causes were.
speaker-1: It did indeed, yeah. And yeah, if people don't know the reference, Cappy Hour is a fictional entity that was kind of the focus of our big presentation. So if anyone gets a chance to watch that video, that's what Zach's referencing. So Zach, I'm gonna try to be as concise as you are and state my big three again before we kind of dive into how we might solve these things. But ⁓ number one is the disconnect between supply chain and the factory floor. The gist of that one is when an order on the factory floor is deferred for any reason, be it lack of parts or otherwise, it often takes tremendous effort to map that back to the customer-facing POs that the supply chain sees. And it would be great if that didn't take as much manual effort as it does. Number two is timely awareness of cost variances. In many cases, you don't actually know your variance to standard, your variance to standard cost until after the period close, which means number one, unexpected. Surprises can happen, and number two, even worse, you're missing an opportunity to start addressing negative variances or unfavorable variances earlier. And number three is anytime you see a managerial KPI dashboard, you should assume that many people behind the scenes are munging together many different data sources to actually present what looks like a nice clean KPI dashboard. And the moment you say, ⁓ we missed this particular box, I see it's red. Give me the top three reasons, you have just incurred tens, if not hundreds, of hours of labor of lot of people behind the scenes because the data is not connected together. Those are my top three pain points. And you know what I would love? I would love if there was like a software founder that could solve all of those with a platform.
speaker-0: Mm. Now you're talking, Glenn. Thank you for sharing the problems. If you guys I'd be curious if you're joining, which one of those problems resonates the most with you? Me personally, I've I can intuitively understand the real-time costing problem, number two, but as a controls engineer, I don't think I've really had considered problem number one. Right? I'm thinking about automating the a controls engineer, you're thinking about automating the line, you're thinking about taking data off of a PLC and bringing it into maybe an OPC server at the most. When you're looking at an enterprise scale, that's where simplification is the only way to scale. And that's why I'm really excited about Fuse and Litmus. I mean, if you also want to talk about AI, two of the platforms that are leading in AI, Fuse and Litmus. That's my own personal opinion. Craig, I'd be curious to hear what you think about these pain points.
speaker-2: Yeah, so ⁓ before I jump into the pain points, I do have to say, Glenn, I'm I'm a little concerned that all of the orders I've been sending to Cappy Hour will not be getting filled. I don't know if that's an accurate statement. I thought it was a real organization.
speaker-1: Yeah. ⁓ i keep keep sending it. That address is totally real. Keep the keep the checks coming.
speaker-2: Okay. Okay. I was wondering whether there's just a delay in the shipments or what was going on here, but ⁓ now it's this is all making more sense. It's coming. So okay. ⁓ yeah, so point one, you know, that you made Glenn, I I think you're exactly right. I don't see it so much as a technology gap as it is an architecture problem. You know, how we get data from all of these disconnected systems up to ⁓ the folks that need to be able to consume this data is sort of the the point of this whole conversation. And I think for decades, you know We've tried to connect systems that were never designed really to work together, right? We've had multiple different vendors kind of working in their own little paradigms from the big box PLC guys all the way up to the big box ERP guys and all of the little point solutions in between those two ends of the spectrum. You know, the ERP, MES, supply chain planning, not to mention Excel, probably one of the most widely used MES systems that we have, right?
speaker-1: Num number one in my Excel as the dominant market leader in
speaker-2: Number one. And and they're all they're all optimized for their specific domain, right? Not for the flow of information across ⁓ those different solutions or across the enterprise. so what are companies supposed to do? They try to solve this right now with ⁓ myriad of integrations, middleware, data lakes. But none of that actually solves the problem. It's just moving the data around after the fact. Cause the other point you brought up was, you know, the real issue is that there's just no shared operational model trying to, you know, tying supply chain decisions to the execution reality. Right. All of these things live in very disparate areas. Yep.
speaker-0: What is a shared operational model even like mean?
speaker-2: So a shared operational model is is a foundational piece of what we do at Fuse. And it's putting in a relational model that represents the the physical aspect that's happening in the factory floor, and then marries that with the information models that we have stored in ERPs and PLMs and you know from an engineering and costing standpoint. And bringing these two things together and it gives a a company some Structure and some governance, but still the flexibility at the plant level. ⁓ I think Dylan and Walker talked a little bit about this on stage, right? This red and blue data concept. So that there's some consistency and you know harmonization across those different plants. So I don't know that that helps clear that up or makes it more muddy. But it's a difficult concept, right? Because I think ⁓ you know, in large part the Problems that we're solving, ⁓ you know, a combination of fuse and litmus are problems that have people have tried to solve for decades, but they have done it with duct tape and and band-aids and bubblegum, and you know, a lot of those projects have not succeeded ⁓ succeeded. And ⁓ the reason why they haven't succeeded, in my view, is that the folks that are funding those projects and those initiatives aren't seeing the value from them. And it's still because there's that struggle between getting the data from where it's originating to the people that need to consume it without the latency.
speaker-0: When when I when I was on the when I met Walker Reynolds and we were on that really large enterprise oil and gas data project, this is one of my first introductions to the power of of unifying namespaces. We consulted with them for about three weeks straight and they had like over fifty different software packages across all of the different domains and departments and business units. This is why the message that we're focusing on is simplifying the enterprise stack.
speaker-2: ⁓ we see it all the time too, Zach. I mean, and every customer that calls us up, you know, they come to us oftentimes with a a really elaborate diagram of their existing application, you know, footprint, and there's, you know, 20, 30, 40 different applications on there. ⁓ you know, and then they'll share with us maybe, you know, the list of things that they're looking at plugging into that existing infrastructure, which includes another dozen or so things, you know, not to mention the thousands of software. Vendors that are out there trying to solve these these little micro pain points. I kind of look at it like death by a thousand cuts, right? You start implementing all of these various point solutions and you know duct tape between them and fragile integrations and software licenses and multiple multiple different partners you're working with. The the risk to the organization is literally just through the roof. And so by making this a much more simple stack and a simple architecture, you greatly reduce the risk, you greatly ⁓ increase the potential for success, and you get the data where it needs to go when it needs to go there.
speaker-0: Like let us know in if you're joining in the comments. Like how many pieces of software are in your s architecture? Is it less than ten? Is it more than ten? You know, there's no single OEM that could solve all of your problems, right? But you could solve most of them with just two.
speaker-2: Yeah, I think that's the story that we're trying to tell here a little bit. And I think ⁓ Glenn, I'll I'll kind of come back to to some of your points, right? You know, the cost visibility problem. I worked as a system integrator implementing ERP systems in global organizations and realizing this same thing for almost a decade that new ERP system never solves your problems, never gives you the visibility that you want. And I've never seen it produce an ROI outside of The fact that it it made somebody have some you know job satisfaction five years after you know they went through the implementation process. ⁓ but the that visibility problem isn't about reporting, it's not about the lack of information, it's the latency in getting that information where it needs to be. And by the time those variances are showing up in your ERP or your finance system, the damage has long been done. There is no way to fix what happened yesterday. There's you can only look going forward from an operational standpoint. How do we improve this? But now you've already lost a month or a quarter or half a year by the time all of those numbers I aggregated. And I think your point is very valid on the tens or hundreds of hours that are spent, not just at corporate, but at the plant level. I I've helped so many plant managers try to implement these systems, and they just have teams of people that are just collecting data from. Spreadsheets and operators and just to bubble that up to corporate. ⁓ or what happens at the end of the year when the when the new ⁓ you know the the budgeting comes out, right? The forecast for next year. Every plant receives this massive spreadsheet for what the the company thinks, you know, next year's budget needs to look like. And we spend weeks combing through this and trying to implement this.
speaker-1: Yeah, it's it's crazy. And what what the real kicker is your best people, right? It it's not you don't give that to your B team because if there's any mistakes in that roll up, there could be real huge consequences. So you take all of your A players, you bury them in endless spreadsheets and disparate data. They spend tens and usually hundreds of hours reconciling it, and there's no value added to the end customer. And your A players are off the field, mired in all of that. That that's kind of what That's what drives me to fix this problem fundamentally. It frees up the A players to do mu higher value add stuff.
speaker-2: A a hundred percent. You know, let them focus on solving other solutions or ⁓ you know, the continuous improvement that's really gonna drive ⁓ those costs down and those margins up. ⁓ when they're focused on just collecting data and putting it in a chart and graph for someone else to look at, there's no problems are being solved.
speaker-1: Right. Exactly. Exactly.
speaker-2: You I I think it's that real time operational context, right? And that's that's one of the big reasons why, you know, we we've got litmus here with us, you know, as well to to help us bridge this gap from, you know, what changed on the line, what what constraint emerged in this process and and what decision was made locally that impacted this cost ultimately, right? And being able to do that in real time and and do that in a small number of systems, a small number of applications. So it's highly efficient and highly available. Available to everyone in the organization. We don't have to worry about who has a user license to this tool that we're using over here, or who has access to that tool over there. Everybody should have access to everything. And that's the reason why we do unlimited user-based licensing. You know, we don't want to penalize any of our customers for adding people to the system to have visibility to the data that they own. There's a lot of questions pouring in here. So I I wanted to ⁓ you had brought up a third point too, Glenn. I think bridging the the C suite KPIs to the plant floor is ⁓ in my experience, that's where most transformations have failed. And everybody talks about the revenue and the margin, on-time delivery and quality. Those are hugely important in in an industrial operation. But those are not things you can manage directly. ⁓ those are emergent outcomes of thousands of micro decisions that get made on the factory floor. So I think that's critical for a lot of executives to understand. And that's one of the reasons why I say and I advocate that, you know, putting a new ERP system in. doesn't solve any of these problems. If ERP is anything, it's anything but micro. It's very macro. And so you're missing all of that detail, ⁓ all of that minutiae that happens. And getting that into that operational model, Zach, that you were you were asking about, that's what's key. Because in the operational model is where all of these events live. And these events live right alongside, the the macro and the micro data essentially come together and they live in one in one space. So you have both perspectives.
speaker-0: I I love that. I mean I I like your analogy of when you called it like the DNA of the business. And I'd love to get Dylan's input here as like in as the architect before we bring on litmus. You know, I like what I was saying is anyone who if you're familiar with four point ⁓ solutions and the IIT university, they have this MES boot camp. Actually I think you could watch like the first session for free if you're a member on their YouTube channel. Anyways, in the very first session, the very first thing you do when you're building an MES From scratch is you're building out we use I think MySQL to build out a relational database so we could store events that were coming off of the machines to store sta state changes. We use the state changes to do downtime tracking, we use that and connection with standard rates to be able to track performance and quality to ultimately get OEE. But imagine that's when it really clicked for me with Fuse. Because if I wanted to build an MES infuse, all of that database configuration is really abstracted for me as the application developer, as the owner of the solution. I just get to see the model in the data model designer and it abstracts all of the technical underworkings for me. And I was like, wow, that's now I get to focus on solving problems.
speaker-2: I am curious, Dylan, what are your thoughts? I mean, you're the architect. I'm just the software vendor. I think this sounds wonderful. but in practice, you know, w you working with so many different organizations, what where are you seeing?
speaker-3: Yeah, I think the ⁓ reality comes down to getting the data on the plant floor. I mean, Glenn talked a lot about the different pain points we feel. It was the disconnection between the supply chain, there was the ⁓ timely awareness and cost variance, how that affects the financials and the core, the results and all that. As well as just linking the needs of these C suite level KPIs, the metrics that feed those, and how do we link those metrics back down to actual data points on the plant floor? Fuse gives us a really good suite to do a lot of that orchestration, a lot of that law logic, and integrate heavily with a lot of the enterprise systems. But with that, we need to get the initial KPIs from somewhere. And that comes down into the OT domain, more so than the IT. And Fuse is a The IT software that understands OT. It's an enterprise grade platform that you can build on top of, you can solve all your own problems with the data flows, the screens and all that. It is that cloud native. You can build your MES in it, you can build your WMS, you can build your supply chain software, and you can solve all those problems that Glenn talked about in Fuse when you have that data coming in from the edge. When you're talking a single site, it's pretty simple. Everything kind of comes together. But once you start scaling, once you go from one line to two lines to three sites to four sites to a hundred sites. Now we need to f figure out a solid, not just a solid IT strategy, but a solid data foundation, a solid OT layer of how do we get this very messy, very disconnected and very disparate data from all these different controllers, from these different devices, these different machines that oftentimes don't speak the same language. And that's where something like litmus really comes in handy. You got the device drivers, you got the modeling, and it allows us to pull down to the plant floor for a second and we'll get back up to the metrics and the KPIs. But as I said, that data has to come from somewhere. So that data starts typically in a PLC, in a controller, in a robot, somewhere on the plant floor in some machine or some device. There's a handful of different protocols they talk and different ways they can get there, different networks, different serial protocols, things like that, but they don't usually do too well at talking to each other. And even if they do, everybody who programs that controller, even from the same OEM, does so in a slightly different way next month than they did last month. I mean, unless you're in some very disciplined industries like automotive or things like that, where you get some the luxury of consistency and you can kind of force the vendors to do things a certain way. Most industry can't. And so you're gonna get from the same machine builder the same machine with very different code bases and different logic. From an IT perspective, you should just have a data model. And that model and that data point maps up to that metric, maps up to Fuse, and everything goes. But in the real world on the plant floor, we need to get it into that consistent data model as close to the edge as possible. And for me, that's where Litmus comes in with 250 plus device drivers. You've got the digital twin capability, which for the sake of conversation with the audience and stuff here, their version of digital twin is a lot more like data modeling. ⁓ so if you're familiar with ignition and UDTs and stuff, it's a very similar approach where you've got your logic, you've got your expressions and your scripts that can then derive values from other values in a hierarchical model. And between the device connectivity and that data modeling, we can then plug that in through various means. ⁓ we can do REST APIs, we could do the OPC connector, we could do MQTT or various different ways of getting that data into Fuse after it's been modeled and consistent at the edge. And then from there, we can tie those data models at the edge into various hierarchies and layers of metrics that eventually become KPIs and eventually solve Glenn's problem in the C suite. But I'm sure Hussein, you got some ideas on how it might not be that easy, but how litmus can help.
speaker-2: Well, you actually did such a good job of explaining that, right? So that's as I was thinking about ⁓ how we can actually ⁓ talk about all this, right? So ⁓ you're absolutely correct. We to kind of tee up all the conversations, like ⁓ what Glenn had said, right, we have the multiple connectors ⁓ that will allow us to simplify that architecture to pull from what Greg had said Craig had said, right? And ⁓ We can kind of model that very simply at the edge ⁓ and prepare that data, send it up in real time, right? Which again, ⁓ Glam to your second point, that that is very important, right? Because ⁓ otherwise you really would not be able to do that. You would you'd be waiting until the end of the month or the end of the quarter, right? At base best case scenario. ⁓ and one of the other tools that we have that is kind of embedded in our product is you can actually add metadata. ⁓ to make sure your your operation at a high level when you're rolling up all that data ⁓ and getting it to your systems, ⁓ how does that actually all look at the same time? Right? You can actually sift through that ⁓ when you have all that data. So basically in a to kind of T like basically ⁓ wrap it all up, right? You can simplify the architecture because everything is under one platform. ⁓ and we have supporting ⁓ software to be able to kind of make sure that that is scaling in that one platform, the Litmus Edge, ⁓ like the Edge Manager, right? And then we also will be able to be the unified namespace. Zach, what you said is giving that flexibility ⁓ at the edge to kind of create the way that you want that unified namespace that you need ⁓ essentially all at once as well ⁓ using a platform.
speaker-0: I wanna translate that into like maybe like ⁓ from my perspective. ⁓ you know, this is one of the big challenges on that enterprise project and enterprise scale. You might be able to have certain platforms that ha have a limited selection of data collection, but let's just talk about the elephant in the room. A lot of the companies out there are using Kepware for data collection because honestly they had built some really great drivers. One of the limitations that I didn't even realize was a problem until more recently. over the past handful of years was running that footprint on a Windows installation like it was very limiting. So being able to have containers to deploy containered solutions from an enterprise IT perspective is almost a minimum technical requirement. And so a lot of companies are they're using Kepport now and they're literally switching over to litmus to standardize on at the enterprise. Now I want the best for Kepware. I w I hope that they're able to adapt and we'll see what's coming from them. They've been sold twice in the last year, which has been a little bit rough, but it took me a while to really see the value of litmus. And so we hope that through our presentation today we can help communicate that. Because again, sometimes you're not you're not considering it because you're like, I'm already doing this these jobs with this tool here. What's the benefit?
speaker-2: Yeah.
speaker-0: And and ⁓ so yeah, like really that being able to model within Litmus, I think that's one of the key differentiators, right? Not only from deployment in containers, but also being able to model, like Dylan said, right at the edge. And then just it could no matter what you really throw at it or come across, you could probably connect to it with litmus and then they're the best at creating drivers. Dylan, how what do you feel like litmus is missing and then what do you feel like the industry needs to standardize on at the edge?
speaker-3: Yeah, I think the biggest one is just data modeling as close to the edge as possible. So Litmus has a lot of good capability of modeling that data directly above the PLC layer, but that shouldn't discount, especially in greenfield sites or for any of the machine builders or OEMs listening, that modeling should be happening at least at a basic level with consistent practices and good hygiene in the PLCs themselves. So the more consistent your controls layer programs are. The more consistent and the faster you can deploy those data models on top, the faster you can build your SCADA, your HMI screens, the faster you can troubleshoot. And the lower down the stack, even down into the PLC programs themselves, the more, and we might not call it data modeling at that point, but the more consistency, the more good hygiene, and the more best practices you can follow in the name of consistency into that controller layer as possible, the more benefits you're gonna see across the board. And currently litmus is one of the few tools that allows us to do that modeling, maybe not in the controller, because most people who are programming the PLCs and most OEMs aren't doing that yet. But at least that allows us to do it one layer above them, even to the point with simple enough user interfaces that you could say, hey machine builder, you know the system inside and out. Can you make the data model for us? Or can you at least document it? And you get their insights on how to build it faster. Because despite them not doing the modeling in any real way, They have the mechanical design. They wrote the program. They know where things are. So the more you can involve your OEM and the person who wrote that code in the first place, even in the discussions of data models, the better you're gonna have. And once you get those data models built, we'll just say in litmus for now and kind of ignore southbound for the sake of this conversation. Once we get those data models built in litmus, we've added the ⁓ metadata, we've added things like units of measure, we've added maybe some aggregate. ⁓ metrics and values that we can derive from other ones. ⁓ we probably are historizing that somewhere at the edge, but then those data models that we have in litmus can then be mapped one to one or at least in a way that grows even further and more standardized in Fuse. And in the data models and in the schema that we build in Fuse, if that's consistent with the data models in litmus, we can carry that up and we can add context the further up we go in the stack, the more context we add. And then from there, depending on the needs, the industry, and how far we're going at the edge, which is going to depend on every different customer with the needs they have, we'll determine how big or small or how detailed those models happen to be in litmus, what gets added in Fuse, and then what then from Fuse, where does that data go back to? And what context is that pulling from other systems like your ERP or your warehouse management or your quality systems? And You get this orchestration going up and down with these shared common data models that are living in different platforms but share the same foundation. And I think that's where the real power lies is consistency throughout the stack, as far up and as far down as you can go.
speaker-0: I love that. I mean we had a question come in, ⁓ I'm gonna drop it to you guys but Literally we would spend most of our time, even the same assets weren't the same, right? And so you know, that's the power of litmus, being able to to to model that, you know, just literally using like JSON objects and and configuration as you know, code. Like these these these platforms are just so much more AI ready. It's insane. Honestly one of the things I think like when I think of litmus, very strong at the edge data collection. It's one of its missing elements is visualization, right? Building applications and that's I think one of us's strong points. And then as well as that enterprise modeling your enterprise data and then litmus modeling your edge data. Those just pair so well together. the question that came in ⁓ was from Patrick said ERP plant floor integration is critical but don't overlook security implications. Industrial IoT data flows create new attack vectors. that requires zero trust architectures and encrypted data exchange protocols.
speaker-3: I'll let Craig go deeper on that, but I'll add real quick that's where Fuse fits in because Fuse is not an in industrial IoT data flow. Fuse is an IT platform with all of that baked in that's connecting to your ERP, where we can then build logic and such into those flows to effuscate and regulate who can access what, where it can go, and who can see various parts of it. But Craig, you're probably better suited to talk about your own security.
speaker-2: Yeah, yeah, sure. I mean, this question comes up all the time. You know, and we we started the platform with built-in role-based access control policies. Data's encrypted in motion and at rest. It's highly secure. What's really nice about that is being an event-driven architecture, the backbone of the platform is UNS. So now you've got a UNS with tight role-based access controls applied over top of it, which is kind of not what you see in a traditional ⁓ OT deployed UNS. And then In addition, we've got the MCP capabilities, which is inherently insecure, right? So we've applied all of these concepts in our IT focused platform to get our hands on OT data from litmus, right? So that we can make it secure. And governed and of course scalable across the enterprise. And it's important for us because most of our customers are on our public-hosted cloud, publicly traded companies that are trusting us to move their data about, you know, hundreds of different plants and keep it secure for them. So and I'm sure once we get down into the DMZ. That's where things like our fuse gateway comes into play. So that gateway will connect through the firewall using WebSockets. So it's only outbound communication. We're not plugging any holes. That's the tool that we connect directly to Litmus at the edge with. And Zach, to your point, visualizations at the edge are critical. We want to see that data. And what that gateway allows us to do is subscribe to things that we're able to collect in Litmus and immediately visualize those through dashboards and screens that we can. develop in Fuse. ⁓ and that's all deployed at the edge through our gateway. So it's it's a hybrid concept. So those are running locally. If you lose internet connectivity, they still continue to run. And then we have a a native ⁓ built in ⁓ store and forward capability there as well. So if any of that stuff actually needs to make it up to the cloud, ⁓ it will once that connection comes back online. So yeah.
speaker-3: And for the sake of fairness too, on Litmus's side, if you have Litmus and Litmus alone, they do have visualization and data flows with Grafana and Node Red. And in isolation below the DMZ, those work really well for what they're made for on the industrial side. But when we're talking about feature overlap and where they complement each other, is if we use the data flows and the visualization options inside of Litmus, that allows for much more IT secure and regulated with role based access controls and various security pieces that Craig just talked about that can be on top of and really extend those capabilities. So one or the other or both you can do a lot and there's some feature overlap there. But I think the combination of the two is where things really get beautiful.
speaker-2: Yep. Yep. Yeah, it's kind of back to the you know, the genesis of the conversation is how do we, you know, get the most value out of the slimmest set of solutions that we can possibly deploy both at the edge and you know at the enterprise.
speaker-0: 'Cause if you have too many solutions, you don't even see you can't even see everything that you have. You don't have a complete documented list. That's why companies are hiring us to consult with them just to help figure out where where to even start. Which by the way, if you want to know where to start, Dylan's doing a workshop on that. And also Dylan wrote a wrote the book on the Phantom palette. So definitely pick up a copy and support that. But yeah, like I I'm really excited about getting like a real deeper integration with Litmus Infuse. If you're in an IT team and you're using Google Cloud, or you're using AWS cloud and you're using their edge connectors, you're already using Litmus Edge, right? That's kind of what I want to see for people that are using the Fuse Cloud. And really it's it's just so funny because I kind of went through this, it's like a whole like life cycle. It's like you have like this epiphany phase. If you end up building, if you end up just kind of building your own solution and you you start scaling it and you start building on like a cloud platform. You probably would end up building something that would look a lot like litmus infuse. So why not just go with litmus infused? You know, that's what I'm asking.
speaker-3: Yep. And we've talked a lot here about greenfield or ideal scenarios with using Litmus and Fuse. But to add, just so we don't lose the plot on the other side too, the more common brownfield implementation, where we've got existing PLCs, we've got existing HMIs, we might even have existing SCADA systems or IoT infrastructure in place. That's part of where both platforms allow for really good connectivity into existing systems through various protocols like OPCUA MQTT and other brokers and REST APIs and just all sorts of different things. So you can make use of your existing base, your existing SCADA system, and then maybe you can start putting new connections in through Litmus and Fuse and slowly over time migrating. But just because you already have a SCADA system in place or you already have something connecting to your devices doesn't mean that you can't gain value from and even eventually migrate to if you choose fully into the litmus and fuse stack. But Litmus and Fuse exist very well alongside existing OPC servers, existing SCADA platforms, existing historians, and things like that. And there's very there's too many ways to go into it a podcast. So going and saying this is exactly how you would do it would take another four hours. But they I mean Litmus has their two hundred and fifty protocols. Craig, you Fuse supports just about everything I know under the sun too. And between the two of them, you're not gonna find too many things that you can't talk to.
speaker-0: I'm glad you you know, you took the words right out of my mouth, Dylan. I'm glad you mentioned the credit where it's due. They do have visualization and honestly if you looked at the Cappy Hour approved session, what Tupinix built inside of Litmus, it's actually pretty incredible and it helped save the company like over a quarter million dollars and we got paid back within ninety days on that ROI. So like, you know, Dylan, as the architect, how would you connect Fuse to litmus and how would you wanna see that ⁓ connection evolve.
speaker-3: I think the most realistic in the early term, and this is a conversation that Fuse and Litmus would have to have, but my preference would be that there be a way to deploy and manage litmus models and things like that, almost the enterprise management tool they've got there from Fuse, where IT is already working in one more unified platform. But the other angle would be too having the Fuse edge gateway. be one of the applications on the litmus store as well. So we could run on the same infrastructure that litmus is running on. So you're gonna have some customers and some clients and some teams that want separate images and separate VMs for everything for various segmentation and backup reasons. And you're gonna have others who want the smallest footprint possible, sometimes even running on bare metal. And that's where we can use the litmus operating system running on its own VM, running containers within it, one of which being the Fuse Edge Gateway. And then Fuse can talk very directly through that connection on that local network on that same machine to the OPC server in Litmus is probably going to be the most efficient, most deterministic way to get that data. And then from there we can pipe that up to the cloud using Fuse's edge gateway, their AMQP, their store and forward and all that kind of stuff.
speaker-2: That one tripped me up too.
speaker-3: Ha ha.
speaker-0: All right. Craig I'll pass it to you. Anything you'd want to see or any anything you wanna add?
speaker-2: Yeah, I I ⁓ yeah, I echo ⁓ Dylan on that. You know, these are some conversations that you know, so we got really amped up on litmus. ⁓ just kind of going into prove it this year. You know, we it wasn't something that was really on our radar too much, but we noticed that it kept coming up more and more often in conversations we were having with our current customers and ⁓ potential customers that, you know, they were they were looking at litmus. So we did a little bit more digging into what that would look like ⁓ had a great conversation with Watsal over there and you know, several since then with Sam Elsner and you know, we did a ⁓ podcast with him and I think ⁓ all of these things are in the works currently ⁓ as we kind of work through finalizing and formalizing our ⁓ technology alliance with Litmus and you know, getting these things in place. So hopefully that will just grease the skids for a lot of organizations that that wanna do this. it's all, you know, fully functional the way it is, but I think we can kind of lower some of the friction points by doing some of the things Dylan mentioned.
speaker-0: Hasn't.
speaker-2: Thanks, Zach. And I think what I wanna leave the audience with is to think about a as you said, Zach, you can build all these things up and just have to probably containerize a bunch of things and ⁓ we deal with a lot of smart people that that are very capable. ⁓ I I think it's important to to understand why you don't wanna do it, right? ⁓ and maybe you could do that one or two plans, but those point to point solutions, ⁓ They will cause you problems, right? As soon as one of those points break, all of a sudden you have a problem. And and then secondly is is the scale piece, right? We've been talking about scale as an underlying message this whole time. ⁓ if you have anywhere more than like two or three plants, you're you're definitely gonna fail. I I I can guarantee you that 'cause I've seen that over and over, right? ⁓ you will have a you will have to have a really large team to to do this. So I think you will the same way you wouldn't create your own operating system, right? That why would you you go and buy out of Windows or Linux, right? Why would you why would you create your own data infrastructure ⁓ essentially, right? Or really in your management ⁓ tool essentially. So that's kind of what I like to leave the audience with to kind of think about that and let that sink in.
speaker-3: And I think from there we'd want to get some of Glenn's feedback here on that enterprise at that executive level there and how this all ties back into the business side of things. But to tee that up a little bit, I just wanna add that one of the things we've heard about scale and things, we've got two different platforms that do two different parts of the puzzle. And together they don't only complement each other, but they de-risk each other. And from there, let's get back into the executive scope. And what do you think about all this, Glenn? How does this tie back to those original KPIs?
speaker-1: Yeah. Yeah, so we we like these webinars to be educational. Our our goal first and foremost in any webinar like this is to be educational. And the trickiest thing that people come to us with is hey, there's fifty vendors in the industry four point zero space. They all seem reputable. In fact, many of them, most of them are reputable. How the heck do I make sense of fifty options? It's very intentional that we chose to have Fuse and Litmus on the podcast here because they're really important pivot points, arguably the two most important pivot points in the whole ecosystem. Zach alluded to this earlier. Earlier, if you were to go back 20 years, rewind in your mind 20 years ago, it's 2005, 2006, all you have is an ERP and PLCs and a fine historian, and like nothing in between. Like that's all you've got. And then step through your daily interactions and the pain points that you would incur and think about what you would build if you were in that situation. So like start from the top down. You're ⁓ you are ERP minded, you kind of are starting from the corporate KPIs and going down. If you had a wish list of problems and you solved them top down, you would build Fuse. If you had a wish list of problems and you solve them kind of edge in or bottom up if you will from the factory floor, you'd build litmus. And so I like to encourage everybody, Fuse and litmus won't solve 100% of your problems. Nobody would ever claim that, but they're really important anchor points to understand. And if you dive deep on those two platforms, you can absolutely fuse the gap with other software packages that we love, like we love ignition, we love flow software, those are awesome packages. But if you start with Fuse And litness, you'll really understand the nature of the problem you're trying to solve. And then you can stitch together a great full stack solution.
speaker-0: Thank you, Glenn. Thank you guys again for joining. Let me break it down for you guys here if you're s if you're watching. Alright, so this is the webinar recording page. If you're on this page, if you're watching the webinar recordings, some of you may have had ac issues accessing the YouTube live stream. We do apologize. We're gonna email you all the link to the recording. On this page, if you scroll down, there's a form to get in contact with us, Avellara. Companies are coming to Avalara To help them architect their solutions, to help understand their problems, and to help architect agnostic solutions. You know, Dylan is very busy, but we are accepting a few y if you're a lighthouse partner, we essentially we come in and we do a digital transformation workshop. We help architect the solution and we help get you hitting the ground running. Fill out your information. What is your biggest operational challenge right now? And why do you want to be a lighthouse partner? Definitely fill out that form. That's the best way to get into the front of the line. Especially if you're looking at views or litmus.
speaker-3: Yep, and off that real quick, on the any platform piece there too, with a sorry, not sorry to both litmus and fuse here. Despite being on a podcast here and saying how much we love you guys, we don't start with a hey, you need fuse or you need litmus. So every time I go into an engagement, we have friends, we have partners, ⁓ we have relationships with different software companies. But every time we go into an engagement, we're gonna start from a fresh sheet of paper, figure out what you already have, what you need, and If that happens to be fuse or litmus, which are patterns that come up quite often, then that's what we'll recommend. And but at the end of the day, our interests are aligned with you, the end user, and your architecture and putting what works for you in place. ⁓ and that not only helps you, it helps our other software partners and make sure that the right fit is in the right place and everybody gets what they need and everybody works well together.
speaker-1: While stuff. Sorry, Craig, in the scene. And you
speaker-0: So we'll we'll go ahead and wrap it up here. If there are any final c questions, please feel free to leave them in the chat. ⁓ or if you want to reach out to us and work with Abelara, we'd be happy to to work with you, fill out that Lighthouse Partner application form. Hossein, any final closing thoughts?
speaker-2: No, this was an awesome conversation. Thank you guys for for having them as part of it.
speaker-0: I think you really ha you had that mic drop moment when you said let that sink in. Remember this, even if you have ignition or another tool, this isn't a rip and replace trap. We connect what you got and imagine that. Thank you guys for joining. We'll see you guys in the next webinar. Thank you, everyone. Bye.
speaker-1: For watching. If you like this content, don't forget to like this video and subscribe to the channel for more content like this. Ascend, see more, improve more.
