Yeah, I think you're touching on two really important things. And, you know, I've always been fascinated. Well, we had to be fascinated by the history of some of this, especially on the technology. And so you're touching on two things. One is the notion of that database or the digitized data and the information and all that. And the other is, as you mentioned, resisting change. And these are two very different things, but obviously they had to collide in all of this and somehow somebody had to make this work. So on the database type, there's a really fascinating history here. It has nothing to do with our industry. It has everything to do with where technology came from and where it was going and what it hoped to achieve. Nobody talks about this much anymore. It's not at all trendy because it's old. But there was a period of time in the 70s and 80s, especially, where a lot of faith was being put into this. NET technology. Microsoft for a while was big in that, but so were all the ERP systems. And the idea for. NET was that everybody would converge on a standard for data. Everybody would converge on the same kinds of rules. And when they did, they would sort of all be installing fully compatible ERP systems, sort of enterprise systems, and all of that. And they would magically all talk to one another as if there were one. And that convergence never happened.. NET did bring us one beautiful thing, which is it created rules, repeatable rules for how you could access data from other machines. And they're called APIs or application, they're interface layers. And those were done. And so it's much, much easier if a system today will typically always have APIs so that another system can read data from that and write back in. So that came from it. But the intelligence that everybody expected, like these systems would now magically act like one, didn't. And we came along during that time. And rather than say, hey, we're going to set up some big, huge data exchange in the middle where everybody can park their own parts information, we knew that would never happen. Certainly not in this industry, but as we learned later, it didn't happen in any other industry either. There's a little bit of that actually, oddly enough, in the trucking and transportation side, but that's a very narrow version of this. And we said, we have to find a way to bridge these systems. So if you're a fleet owner, let's go back into our industry. You own a whole bunch of equipment. You have a dealer, and then you've got different manufacturers for your fleet. And all the information that you tend to maintain in your own system, it's called an item master file, which is where do what these are the parts I need. This is the kind of machines I have and so forth. They they need regular updating. And we said, Well, rule number one, there should be no updating if somebody a john Deere, somebody at Caterpillar, somebody at the case, New Holland, changes, brings brings along a new part for those machines, they should automatically be written into your system. And so that was for us a big deal. We respected that you have what we call a system of record. Your suppliers have a system of record. And all we did is tie them all together that if there's a change that pertains to you, your item master file would self-update when you try to order that part, for example. If it doesn't exist in your file, it'll go and what is it? It'll add it and they'll do it all dynamically. So in a way, we were doing what. NET was promising would happen. But you actually had to build technology in between it to make it happen and use these APIs that it came with. So that was the approach to data. Everybody that looks at these systems today, at our technology and said, hey, this is pretty easy. It's because you don't see the plumbing in the background of what had to happen to get all of these different systems to talk to one another. So that's one part. The other part, which is in many ways, the more interesting human dimension in all of this is the resisting change side. So here you go, you walk in and you say, hey. we're not just going to put it on glass. We're going to make all this stuff interactive. We're going to allow it to tell one system, tell another system what to do. And then when you come with this sort of vision, you're being very naive because you think, okay, the organization is immediately going to change what they've been doing for generations, and they're just going to hop right in. And that's the wrong way to do it. So there's this whole literature. Business schools do a lot about it, and we've seen a lot of it, which is they call this the balanced scorecard approach. And what it means is essentially the world it lives in is that you come in with a new technology and you do exactly what you've been doing to date, but you do it faster, more accurately, and with a great deal more efficiency. So let's take an example. A piece of equipment, let's say you own your fleet and you're running it. A piece of equipment comes back from a job. It gets inspected. You say, aha, there's a repair that needs to happen. You create a work order. You identify the parts you need in your own inventory, which you have. And then you say, well, actually, we need 10 parts. We only have two of them. So let's go ahead and order the other eight. Well, who do we buy these parts from? So you then look at your preferred supplier list. You say, well, what region am I currently in? Okay, I'm in Wisconsin. So my preferred supplier for this is A.A doesn't have those parts. What's my backup supplier? B. So you go there, you call them. A likes it when you look online. B likes it when you call them. C wants you to send a fax, whatever it is. So you really work your way through them. And then when you finally have the right part that you need or the parts. You go back to your own system, you generate a purchase order, you send that purchase order number to them, they give you a sales order number, the stuff arrives. At the end of the day, the fact that you just ordered a $50 part, so $50 are irrelevant. You just spent several hundred dollars of labor time and equipment downtime trying to get all of this. So we came with this new technology, just like a lot of other companies. This is not a SmartEquip specific story. We came and said, hey, we can make all this stuff go really fast and you can skip a lot of steps. And instead, we saw that the only implementation that worked well was when you put the system in and everybody did exactly what I just described, but they did it electronically. So the equipment would come back, they would click on something, it would generate a work order automatically. They would say, hey, I need these parts. So they would click on the different parts diagram that would pop up, a specific serial number, and the machine or our system would tell them, yeah. Two of those you have in your own stock because we just read your other system. But the other eight you have to order. And by the way, this is your preferred supplier. They have them. And the other one, they have six of them. But the other two you've got to get from your backup supplier. They can be here tomorrow. Here's the correct pricing. We've already put it in your purchase order. We've already sent the PO to them. We've already got a sales order back. So all this stuff I just described happens electronically and interactively. And you go, wow, this is great. And these guys are happy as can be. Because they can now do in minutes what used to take several hours and was error prone. So that's a big shift. But there's still something that they're not doing. And there's still something that leaves you frustrated. And that is, guys, if we can do all of this, and you wait for them to say, you can't tell them, you wait for them. And we just had this a few years ago, my favorite example, somebody in the Netherlands where we put the system in, some guy came back and says, guys, if we do all of this. Why do we need a work order? So now you're not saying, let's go through the same lines. Now you're saying, let's do it differently altogether. And their boss immediately said, what do you mean? Why do we need a work order? Of course we need a work order. How are we going to do service work without a work order? And he said, no, but think about it. The reason we have work order in our company, this is a very specific interpretation, is because we want to know what each machine costs to maintain. And we want to see exactly what that machine consumes in parts. We want to assume what it consumes in service units and hours. That's really why we have them. That's the only reason. And we want somebody to look at a piece of paper and say, this is what you need to do. Now we have SmartEquip in here. Again, you can find, I know our example is the best, but this is true for virtually any technology implementation. At some point this happens. And they'll come in and say, hey, if we place the order, The system already knows who the part is being ordered for, meaning which machine it goes to. We can very easily just say, hey, yeah, it took two hours, boom. And we know what our internal rate is. So let's just bypass work order altogether. And so that's when it gets really exciting. You're not just doing what you've always been doing, but doing it faster. If you think of it geometrically, it's as your innovation curve, or sorry, your process curve, you make it steeper because you're getting better at it. Now you're saying, well, wait a minute, we can do things in a new way and you can just shift it up. And the last thing on all this is if there's one thing that this whole balanced scorecard literature has taught us, trying to leapfrog directly to the outcome by saying, hey, guys, we've got something completely new. Forget everything you've ever done and do this. Almost always fails. Whereas if you put it in and then have somebody in the organization and good organizations always have sort of their pilot crew and they get involved and they roll up and they know the key performance indicators, they get involved and they come back and they say, guys, guys, guys, we can actually innovate the workflow now. And we can continue to do this on a quarterly, annual, whatever basis and sit down and measure these. And that's when it gets really, really exciting. So that's a big, big shift from, so there are really two shifts we just described. One was get it off the printed page onto Glass and then recognize that that's a bit of a step backwards, at least for the user, not so much for the manufacturer in this case. Second thing is start doing everything that you've been doing before, but you're getting so much faster and better and more accurate at it with the whole process. But then within that, have a whole different type of innovation happen that was never available before. So that's a long-winded way of describing this and meandering to what. NET role was. But that outcome was always the dream from these technology innovations,. NET and other. But it requires the user to go through all of this. And it also required technology to take a slightly different path than what was originally envisioned.
