Transcript.

Erik: Welcome to the Industrial IoT Spotlight, your number one spot for insight from industrial IoT thought leaders who are transforming businesses today with your host, Erik Walenza.

Welcome back to the Industrial IoT Spotlight podcast. I'm your host, Erik Walenza, CEO of IoT ONE and your host today, this podcast is brought to you by PTC and Live Works, the world's most respected digital transformation conference. In this series, we will feature partners of PTC who are driving digital innovation and value creation today. Stephan and Steve, thank you so much for taking the time to talk with me today about Brock Solutions and your work with PTC and ThingWorx.

Stephan: It's our pleasure. Thanks for inviting us.

Erik: So I think a great point to start would be just to give our listeners a foundation in what Brock Solutions does and then also in how you fit into the organization just so they know who we're talking to and the experience that you're bringing to the table. And maybe we can start with Brock Solutions and then if you can help us understand how you fit in and what your role is in helping get solutions built for your customers.

Stephan: Brock Solutions, we're a systems integrator, and we're focused on the real time digital space. So that's a bit of a mouthful, but what that really means is our expertise is in delivering solutions, basically below manufacturers, planning systems or financial systems. So if you can envision a manufacturing operation where there are systems pertaining to automation, maybe their IoT could be a manufacturing execution system, or MES as it's referred to in the industry. that's really what our company specializes in.

So we're laser focused on that real time space. And we're about 500 people, which makes us pretty large. In fact, we think we're the largest independent integrator focused on the real time space, which is pretty exciting place to be for us. We focus on large enterprise customers. So typically, our customers have multiple sites, and they're located all around the world, which allows us to kind of flex that size and scale muscle that we're privileged to have in the industry.

Just in terms of my role, specifically, I've been at Brock for about 20 years. An interesting thing about Brock is we don't have titles, so that does make it a little bit difficult to describe. If I were to describe my role, and what I what I do day in and do, it's to lead our manufacturing business unit. And the clients that we serve are basically anyone that makes something so they could be in food and beverage, automotive, steel, etc. And maybe Steve, I’ll pass it over to you to close the loop on it.

Steve: Sure. I'm Steve Sangster. And Solution Architect is usually the way that I'll describe my role. I work with our clients to understand their process challenges, understand their business needs, and architect solutions, mostly from a system architecture and functional design point of view to formulate the projects that we deliver.

Erik: And yeah, I think you're probably right there about being certainly one of the larger system integrators in the market. We do talk to quite a few system integrators, but most really don't crack 100 employees aside and then you have the Tatas and so forth, which are kind of in a different range, but also doing, I think, different types of projects. One of the interesting things that just as a side note about Brock, maybe you just have a couple comments on this is that it's employee-owned. I mean, you can probably see this reflected in the fact that you don't have titles. Anything interesting to point out there, I don't come across many companies particularly in this space that are really employee owned?

Stephan: I'm a lifer here at Brock solution. So I don't know any other way. But what I can tell you is that it tries a certain type of behavior where everybody and I can almost say, without exception, is really focused on delivering solutions that are going to work and that are going to add value to our customers. So, it's in your best interest. We are all owners of this company to be able to deliver solutions that we can be proud of. And that's really something that our culture has, ever since I've been here and before the culture really embraces that and lives that. So when you walk around Brock, there's no hierarchy, there's no ladder to worry about. You worry about delivering the solutions effectively so that you can see your customers using them. And what you worked on actually matters. So I think it drives that type of behavior and it certainly is unique.

Erik: Yeah, indeed. Well, I suppose when you own the company, as employees, and when you don't have titles, a lot of these issues related to hierarchy and positioning and in politics, and so forth just disappear. There's another thing that I wanted to delve into a bit more in this focus that you have on real time. And so this term is used a lot. And my belief is that actually a lot of people have maybe a vague understanding of what does it mean, really, to develop real time solutions? What exactly does real time mean? Because I think real time can mean a different timespan for different environments. So how fast actually is real time? And then why are you focused on this? And why is this critical for the customers that you're working with?

Steven: When we refer to the real time aspect of it, really we’re talking about the controls level of any system or any operation. And when we're looking at integration of applications in that real time space, it's really bringing together the PLC world, the automation world, with the software world. It may not sound all that difficult. But it's an area that a lot of companies can struggle to get right, can struggle to build solutions that are robust and perform well.

And in our experience in that space, we've developed a lot of best practices and patterns that we can reuse that allow us to deliver well performing solutions really effectively there.

Stephan: And something I would just add to that real time to us means that these solutions are mission critical. So as Steve mentioned, whether they're in the automation layer, or in maybe the MES layer, the IoT layer, the solutions that we deliver have to work. And that might sound counterintuitive or kind of silly that yes, I assume the solutions have to work, that any systems integrators delivery. But the reason I say it that way is just to give you a sense of the importance of these solutions to the operations of our customers.

So if I use some examples, if it's a stamping, press, if it's an airline that's trying to sort bags, if it's a conveyor that's jammed, our systems are controlling those applications. So if the systems go down, those operations don't run: you're not making your car or you're not sorting your bag. If you're a steel plant, you're not making a pipe that you expect to deliver. So real time to us is a good way to encompass all of the complexity, and the seriousness of the solutions that we're deploying.

Erik: And maybe we can go into some of those key problems that you're working with companies to solve. Maybe if we want to go through three or four, what would be typical challenges that companies are coming to you with?

Stephan: Well, I think it's all under the umbrella lately of going digital. So the idea of a digital environment, that's really what manufacturers are coming to us and saying, we have this vision, we want to integrate all of our systems from research and development to ideation, to what's actually happening in our manufacturing plant, to our aftermarket services and back again. So they really are embracing the term ‘digital’ as the catch all to provide all that integration, and it's to solve problems that you would imagine a manufacturer has.

They typically want to optimize their supply chain. They want to have better transparency with their customers. They have to figure out how to do things better on the plant floor and more efficiently. And that doesn't happen easily. Because there are some practical realities of what they have. Most of our customers, because they enterprise nature, they've got a bunch of acquisitions. And when they acquire companies that brings a whole mishmash of tools and technologies that they have to deal with, they might not have the infrastructure that digital needs.

So do they have the networks? Do they have the actual machine control systems to serve up the data that they need to become more efficient? And there's a lot of confusion on the whole space. So they'll will say to us, how do we go digital? Who do we pick? And the reality is there's a whole bunch of different technology that can be considered. There's a notion of how do I leverage tools that I already have? So this is not an easy problem to solve. It can be considered a daunting task. But it's a task that all of our manufacturing customers are laser focused on getting to the end of.

Erik: There's one topic that has come up for me personally quite a bit. I'm the co-chair of the smart factory task group with the industrial Internet consortium. And so we get into this topic a bit. And one of the big pain points here is security of the data, when you're working in an edge environment where traditionally that data is pretty much resided locally. And I imagine you're now getting into situations with clients where they want to have access to this data, potentially globally, or at least remotely for specific individuals are integrated into different systems.

Maybe you can share a little bit about your perspective on where we are today in terms of being able to take data out of a silo, for example, a factory, and how you approach this type of challenge. And where you see this going? Do you see this being a problem that is going to be fundamentally addressed so that really, we have more an actual Internet of Things, where data is more feasibly actually connected to the internet, and therefore access globally, or whether the challenges here are sufficient enough that we're really going to continue to see somewhat more isolated systems that are still firewalled off into their own domain?

Steven: Security is definitely a hot topic these days. I think, in past years, the priority was mostly about just getting data. And now, in the last couple of years, people have really started to think about the security aspect of it. And it's becoming more of an upfront thought, rather than an afterthought. In terms of data, a lot of companies have resisted cloud based solutions, because of the security question. They want to keep their data at least within their networks. Even if that's their global networks, they’re nervous about the idea of sending their data to a cloud provider. Some of the approaches to that have started to loosen up recently. But I think that's more just people becoming comfortable with the idea of cloud environments, and that they can be secure. But certainly companies are concerned about making sure that their data is protected.

Erik: Yeah, I suppose there's technology development on the one hand, and then there's just education and learning what can and what cannot be secured. And that's kind of a separation that's ongoing.

Steven: People seem to be more comfortable with the technology platforms that provide on-premise solutions, rather than being cloud only. It's definitely an advantage when you see that there's flexibility in the offering where you could either go cloud or go on-premise, because then at least it leaves things open for people to decide where they're more comfortable. The cloud only solutions, they'll get used in pilots from time to time. But when it comes time for a broad rollout, and that's when people kind of raise the security flags, and sometimes back away from that.

Erik: But if you can walk us through your thought process for how you approach a problem, and maybe starting quite early in the process in terms of evaluating the situation that your customer has, defining approach, going through the technology selection process. And if you even want to take us a step past implementation, and also talk about how you maintain the system, because obviously, we're now in an environment where things are not hard coded to an extent, but there's going to be ongoing optimization, there's going to be ongoing additions of new applications to a system. And so how you look at this maintenance and improvement in the long term, I think it'd be interesting just to understand your thought process through the entire lifecycle of a solution.

Stephan: Sure. And that's something that we enjoy talking about, because we're living it every day, and the methodology is something that we're proud of. Before maybe I asked Steve to walk through the hallmarks of that methodology, something that I just wanted to frame here to give it some context is the way Brock is actually organized. And it's really team based.

If you were to walk into a conference room, for instance, right now and you were to kind of see all these different people sitting around solving problems, trying to define solutions, developing code, etc, I think you would see a pretty interesting mix and it explains why we do things the way we do. If you want into that conference room now with an invisibility cloak or something on, what you would see was this diversity of skill set.

So you would see a couple folks that were working on an automation aspect of the project, whether it was developing PLC or DCS code or maybe they're working on an HMI system, a SCADA system. And then across the table from them, you'd see others that are more software focused, that are looking at how to integrate and develop an MES or an IoT solution to work with that controls layer. You'd probably see an IT expert in there helping them figure out the network infrastructure required to make this all work. And then you'd have a project manager that was trying to keep all these moving pieces marching toward the expected scope and time and schedule.

So we've had to develop a methodology that lends itself to the diversity of the skill sets all coming together to deliver a solution that works. So I just wanted to paint that picture so that you understood or you can get a vision of what our teams look like and then the methodology that's quite honed at this stage in our company's evolution that Steve will walk you through.

Erik: That's great background. One of the things that we come up with a lot is the challenge of working between the information technology space and the operational technology space. And a lot of companies are just not well suited. They just don't have the skill sets, right. So a lot of companies are coming from an IT background, they excel in that domain. But understanding the challenges of a messy environment with brownfield capital equipment, and maybe an operating environment where operations have to continue as you're doing the deployment, but because you simply can't stop a factory production line for two weeks to grow something out.

And then conversely, we see a lot of companies who are coming from the more operational technology domain, where they maybe understand their problems quite well, but lack the idea expertise. So I think this multidisciplinary approach, probably something we will begin to see more in the future. I know a lot of companies are now struggling with how to build out these capabilities. But it sounds like you're a couple steps ahead in pulling the right people together here.

Steven: The things usually begin with us having broad conversation about our customers digital journey and their objectives. As Steph mentioned earlier, not all of them know where to start and what it is, what path they need to take to get where they're going. Some of them just know that they need to go digital, they need to figure out how to get there. And that's where we start to get involved.

So the initial conversations are often more of a consulting exercise, trying to paint out a roadmap towards the new digital environment that they're aspiring for. At that stage, we often first need to get to know their operation. So we'll do studies or take a close look at their processes, specifically in the manufacturing space, but also understanding their system landscape and how they do business so that we can map out how everything's going to fit together into the new picture.

And then along with that, then we can start to identify a bit of a project roadmap around implementation of systems to get from quick value early, but to deliver systems over the course of sometimes a few years to be able to work towards those digital objectives. Within that then, on any individual project, then we're basically looking at a specific scope of work that we're going to deliver. So we'll define that, and then that's when the project team really gets involved as part of the delivery of the implementation of that specific scope.

Erik: So I suppose in some circumstances, the scope is very clear, and the customer knows exactly what they're trying to implement. In other cases, I would imagine that the scope might not be entirely well defined and it might then evolve. How do you kind of approach these cases where maybe the customer is not crystal clear on what that scope is, and you then have to kind of also plan for evolution through the project?

Stephan: I think one of the unique things that Brock does, just based on my experience when I'm talking to customers about how to scope things, we deliver solutions in the majority of our projects on a fixed price, fixed scope basis. And that scope is very rarely defined in a way up front that we can deliver a proposal to deliver a fixed price project. So it's important that we work with the customer to capture that scope, and we've got a bunch of tools. And we're happy to share with the audience if anyone's interested in learning a little bit more.

But primarily, the way we're able to help a customer understand the scope that's going to get delivered is through a workflow process. So we use graphical workflows. If you can imagine, picture in your mind's eye a large sheet of paper with some swimlanes at the bottom, it's your production process; you move up, it's your controls and automation up to MES, up to ERP, we use this graphical workflow approach to capture what's going to live in what layer. So what goes where? What would you want to do in your MES future state? What do you want to do in your controls layer? How are the systems all going to interact?

So that's how we capture scope. Just as a little aside, here, we used to write these gigantic, functional spec documents 300 pages of a narrative describing how future state systems were going to work. And we quickly discovered that our customers, first, they didn't necessarily understand what we were putting on paper, it lent itself to some misinterpretation. And second, a lot of them won’t read it, it was just too onerous, it was too large, too difficult to consume.

So that's why we move to this more graphical workflow approached capture scope. And then based on that scope, we work with the customer to decide how the project is going to be implemented. And as Steve described, that's when the rubber hits the road, the team gets together. And we march toward pretty specific deadlines and deliverables that are the project manager’s responsibility to be on top of.

So I think Steve's described it well. Most customers don't quite know how to get from A to B, especially under this broad context of digital, which is where we feel we can help based on our experience and our workflow approach. Once we get that nailed, we're able to deliver against that fixed scope so that there are no surprises. And a big way that we're able to deliver against that scope so that there are no surprises is that we are real, big, big believers in simulation. And I'll let Steve go over what that means in terms of practical terms.

But the fact that we test and simulate all of these systems on the bench before they ever go into a production environment, I think, it’s been the key to our success. We're able to deliver something that we know is going to work. In what's often a very stressful commissioning environment, you only have so many hours to implement the solutions that you built. So it's important that once we get on site, there are no surprises.

Steve: Yeah, just to expand a little bit on the simulation, it's the nature of the types of systems we're integrating pieces. Now usually, there's existing equipment on the floor, often it's legacy equipment. And when we're doing our work offline in our office, we're not necessarily going to bring a press into the office just so we can test things out. So we have a number of tools that we use, just as part of our regular implementation routines where we can simulate the IO for the particular equipment that we're going to be connecting to, and then use that to drive all of our testing activities so we can basically exercise all of the normal, all of the exception conditions with the system. We can actually run a full demonstration of the system in our office before we take it and install it in the plant.

Erik: There was a point that you mentioned earlier around technology selection and the challenge of selecting the right technology in these areas where there's maybe on the one hand, many options in the market, and on the other hand, not necessarily clear specifications. So I suppose if you're dealing with a sensor, you have a pretty clear set of specs. But if you're dealing with a cloud platform, for example, it might be a bit more vague what qualifies one platform over another? Is this a good point to get a bit more into the technology selection process?

Stephan: So the way I would answer that is this is where the workflows are really so critical. So once we help the customer really understand what their systems are to do in the future to meet their digital goals, then it becomes okay, I think well now we have a great understanding what all of these different systems are going to do in my environment. I could see it graphically. I can understand all the different touch points. Now use that as a way to facilitate who you're going to work with in terms of what technology should go where.

So we don't recommend technology platforms or things like that. Our role is to help our customers really understand what future state solutions are to deliver and then help facilitate a process where the manufacturer themselves will get a good understanding of what technology they want to select, and who they want to work with based on those workflows.

So for instance, we recommend something we call a ‘Day in the Life’. If a customer is trying to determine they've got a shortlist, let's say a couple MES providers or IoT providers, we recommend that they use the workflows, they give those workflows to the potential software provider and ask that provider to come back demonstrating a ‘Day in the Life of their software to the needs that are identified in the workflow. It's so much better than giving a software provider a huge Excel spreadsheet and say, can your product do XYZ?

Software providers are better off to demonstrate how their solution is going to work in the customer’s environment. It's something that they'd like to do to be able to demonstrate how the system's actually going to work and get to know the customer better than just responding to a big spreadsheet. And for the customer side, they get to actually see how the solution is going to work and not watch death by PowerPoint of a software overview. Our role is to help facilitate that process to make sure that the manufacturer or the transportation customer is getting a better more practical realistic overview of how a solutions going to work in their environment. And that's a better way to make a decision.

I think we all have that in our own lives. We want to understand if we're going to buy a service, who are we going to work with? How's it going to work in our environment? And do we have the potential for a long term relationship? Because frankly, that's when you get to know your solution provider.

Erik: And then we had discussed a bit about the continuous improvement maintenance or just the cadence of a rollout, as an organization gets more experience with the system that has been deployed to date, and then is able to make decisions on what next stage capabilities might look at. When you are scoping out a project and helping to plan a roadmap, because I imagine this is often the case that it doesn't make sense to take a grand plan approach, and try to think through, what's the ideal system? It's more what system is going to create value today at a reasonable cost and reasonable risk level? And then how can we learn from that and build on that?

Maybe you could take a step back and share with us how you advise companies to balance. I think at least we do encounter a fair bit of big thinking in terms of ambition level, and that carries with it a fair amount of risk. And then the alternative would be that a company says well, let's do a bunch of small pilots. But that also carries a good amount of risk that those pilots mature into nothing. So how do you balance and find a good medium ground where they can really deploy a meaningful solution that can be built on in the future? And maybe just to share your perspective on how to find this right scope for the deployment today with a view towards expanding in the future?

Stephan: Well, you've hit on the challenge that we deal with every week. And I don't think there's a silver bullet. I wouldn't want to stand here and say this is really. We figured out how to deploy digital solutions in a way that they're adopted on day one and used forever. But we have learned some lessons along the way that we'd be happy to share. And the number one lesson we learned, and over and over and over again, independent of the industry is that if you are going to go digital, you need to have your executives engaged. So it's so critical that the message of the importance of digital, tying that importance of digital back to how it's going to make your company money, how it's going to make your employees jobs better, potentially easier, that message really needs to come from the top.

And in fact, a colleague of mine often jokes about how if he were to write a book about what it takes to go digital, the first chapter would say, “Get Executive Engagement”, and then the next chapter would say, the end. This is really it kind of begins and ends with getting executive engagement, so then people will adopt and use the tools. And folks are marching to the same drumbeat.

You said something interesting there about pilots, and how do you make sure a pilot doesn't go into the digital pilot graveyard, which we've seen as well? And I think starting with executive engagement is just table stakes. That has to be there. But then the interesting part, and it's something that we get excited about, because we have a role in this, is how do you deliver something that's quick to value? That's the expression we use internally. It's got to be quick to value, but still have that nod to the broader digital strategy.

And I could say, in the last maybe five years or so, the whole idea of these big bang five years digital transformation journey, we're going to march through all of our 50 plans and replace everything and tie it all together in one fell swoop, those days are gone. Manufacturers need to go fast. That's the one thing we consistently hear over and over, go fast and deliver value, which isn't easy in light of all the things that we discussed earlier. There’re infrastructure gaps. There’re challenges with plant floor equipment. So we see our role as helping scope those initial engagements that are quick to value aligned with the leadership direction, the strategic direction, and are going to work when they're switched on. Maybe I'll pass it over to Steve, if he wants to describe some projects we're working on right now where that's actually a part of the process.

Steve: Yeah, we have a few examples. Just in the last year or so where to be able to get towards that larger digital journey, the first step is we need to get the data. And getting the data, first of all, can be a bit of a hard thing to quantify value for because you don't necessarily know what you're going to be able to do with it until you get it. So there's an aspect there where we work on helping to figure out well, what value will you get from this data? What could the future unlock once you have it?

But those initial those initial projects around getting connected to the equipment, getting the data out of it, sometimes even having to either upgrade or augment the equipment with additional hardware to be able to communicate with it, that's really just the first step is get that data. Some initial quick value can be obtained from it just by making sure that the initial scope includes making it visible. So, operator, dashboards, supervisory dashboards, kind of getting into feeding towards a data warehouse where you know you're going to unlock some potential, those are examples of things that can help unlock that data. Just one simple step beyond just collecting it.

Erik: We discussed offline this Brembo example. Would we be able to dive into this a little bit as a concrete illustration of how you approach this?

Steve: Sure. Yes, that's an example of sort of that dashboard and data collection concept. Brembo, for anybody who doesn't know, they make brakes. They're best known for high performance brakes in applications like racing and motorcycles. But they really make brakes for everything, from your Ford Focus to your Ferrari, and transport trucks as well.

They have highly automated processes where in their rotor plant where they're machining rotors to very tight specifications. And within those production cells, where they're running the machining process, there's a number of components that are involved there that are all generating data. So the project that we did initially with them using ThingWorx was built around both the collection of data as well as dashboards, like I just described. And the interesting thing there is that the mashups that we built on ThingWorx are actually consolidating data from four different data sources all on one screen.

So we're pulling together live production data, combining that with data that's coming from ERP about the current work order, the current part that's being run, the number of parts that have been made, things like that. And also pulling in quality data from some automated measurement tools that are displaying is everything coming out within spec, as well as data from maintenance systems, which is a number of sensors that are on the line that are monitoring things like vibrations and temperatures as a way of trying to indicate whether you've got a problem or things are running well.

So you can imagine this dashboard now where you've got data from all four of those different sources all being put together on one screen, rather than having to look at four independent screens and try and tie it all together for yourself. It allows us to do things like highlight for the user when two things from two different applications might be conflicting with each other or when there's an indicator on one application that might lead to something that they need to do elsewhere in the process to adjust things to avoid a problem. That's kind of the initial thing that helps with the operator there.

And then on top of all of that, the data from those four applications, then it's all logged into, essentially, four different databases, but it's there and available then for other reporting and analysis applications that you're going to do with you bring in your data science team to, you bring in business analysts and process engineers, and then now have that all available to start moving things to the next step.

Stephan: And I think Brembo, that project is a good example of quick to value. It's not building a rocket ship that's going to take months. These definitions and implementation type activities, we're talking weeks in terms of having something demonstrably, usable, available to provide insights quickly and to be rolled out in scale. And I think that at the end of the day, the reason these projects are considered successful, and we've had very nice feedback from Brembo, and others that are doing similar things is that they see the value and they don't have to wait. So digital doesn't mean waiting forever, I guess would be a point I would want to make. And it means getting things in front of you quickly to have insights to make decisions to keep building on and to roll out and scale. So the PTC ThingWorx platform just lends itself to that, and just the way it's built and designed, and has been an effective tool in this example.

Erik: I'm interested in your perspective on where we are in terms of the types of functionality. So I think what you were describing scribing with Brembo, is we would bringing the right information to the right people and combining information from different sources so that you can create kind of unique perspectives. And then the person is still the primary decision maker. Obviously, there's been a lot of venture capital going into machine learning and so forth and a lot of companies putting effort here. To what extent are you seeing this rollout effectively in the field today? Are you seeing situations where data is being analyzed, and more or less real time and being used to drive automated decisions? Or do you see this more as what we might expect to see rollout in the coming years?

Steve: I think we're just seeing the beginning. From what we've seen, the majority of companies are just they're not quite there yet. There's definitely a lot of excitement about it, and people want to get there. But there are so many companies out there that still don't even have the data. There's so many paper based processes out there still. And the reality is, as much as we'd like to think that every company on the planet is highly automated, most are not. But I think the potential is definitely there. And the ones that are starting to get data, the ones that have process engineers and data scientists engaged in their projects are the ones that are definitely further ahead. And it's only a matter of time until this just becomes the norm.

Stephan: I think that was really well said. It really depends on the maturity of the manufacturing operation in terms of actually having the data. I think we've seen executive teams and operational teams value machine learning in particular as the next big stage of where they're trying to go. But I think to Steve's point, a lot of that, and for lack of a better word, the plumbing still needs to be addressed before they can get there.

Now that said, we have seen some customers who have taken it to the next level and started to use machine learning, predictive analytics, prescriptive analytics to get them to the next level. And you can just see how much further ahead those folks are in terms of their market share as well. So there's a direct correlation. And there's definitely an evolution that our customers are on. And hopefully, we're contributing to that evolution in a way that's helpful for them to get there.

Erik: I think you got a super interesting job, you get to kind of play at the cutting edge and really get involved in hands on making things happen. I'm here sitting a bit more on the business side, which is also quite interesting. As closing thoughts, maybe I can ask you both just to summarize from your experience in past projects. If somebody here is listening, and they are either just planning out deployment and are a little bit uncertain, or maybe they're in the middle of a deployment, that's not going as well as they had planned, if you can just quickly summarize your advice to people on how to make sure that they're minimizing risk and they're, as you said, accelerating the time to value?

Stephan: I would come back to the point that we make about getting executive engagement and alignment. And we see this pattern a lot. If there's a project that was kicked off in digital, and then it stopped and then the company had to regroup and they're about to restart, it can typically trace it back to did we really understand the benefit that this was going to bring our business? Did we have our executives online to saying use these tools because they're going to help us get to where we want to be? And are they consistently looking at value?

So it's got to be done for a reason. As simplistic as that might sound, that call to action should really be about the value that these solutions are going to deliver to the business. And I think that's the number one lesson, for sure, our company is learned in terms of when solutions are successful, and how to ensure their success, and make sure they're not done in isolation. And so that would be another best practice. Or maybe I would even term it as a lesson learned from the school of hard knocks. Does everyone understand the value? Are they aligned on what they're going to get in there? Are they marching towards that goal?

Steve: And when you get into the details of the implementation, then you can take that engagement a little bit further to and you use want to think about user engagement, you don't want to design something that the end users are not going to want to use or not going to appreciate using. So as Steph said, they need to understand the value and the goal so they're all marching in the same direction. But they also involving them in the process of designing, it will also help ensure that they'll accept it when it comes and that they'll use it and not just revert back to the old ways.

Stephan: It's funny how, although we're a technical delivery company, these are really the things that keep us up at night. These are the things that have to be in place to have successful projects. And I Brock Solutions, we're only as good as our last project. So it's important that the way we design our team, so our methodology, how we talk to clients include the business perspective from the front end, the rock solid technical delivery, and then making sure that the solutions are used and continuously improved, which has actually been a big part of our business over the last couple of years.

We call it sustainment. But what that means to us is know a consistent way of improving the solutions responding to any issues that might happen with the solutions in their production environment. But always kind of looking forward to how can we deliver more value? How can we improve the solutions in the way that we can capture the benefits that they're bringing? So really an interesting evolution for us marrying the business side to the technical side, which I think it's a pretty unique thing and exciting to your point.

Erik: Well, guys, thank you so much for taking the time and really walking through this in depth. I think for me super interesting. And I have no doubt that it'll be really valuable for a good number of our listeners.

Stephan: Oh, it's our pleasure.

Erik: This episode of the industrial IoT spotlight podcast is part of a collaboration with PTC, the global software company that helps companies design, manufacture, operate, and service things for a smart connected world. To learn more about PTC visit www.ptc.com and to collaborate on future podcasts with IoTONE, please feel free to reach out to us at team@IoTone.com.

Thanks for tuning in to another edition of the industrial IoT spotlight. Don't forget to follow us on Twitter at IoTONEHQ and to check out our database of case studies on IoTone.com. If you have unique insight or a project deployment story to share, we'd love to feature you on a future edition. Write us at erik.walenza@IoTone.com.