Director of Sales Engineering
Ignition Team Lead
Barry-Wehmiller Design Group
In order to succeed at Digital Transformation, organizations must plan and carry it out at the levels of process, technology, and culture. Because it is an all-encompassing and ongoing endeavor, the pain points associated with Digital Transformation can be more complex than those you’d encounter when doing something like a SCADA system upgrade or a first-time OEE project.
Because Digital Transformation looks different for each organization, this webinar brings together professionals who have worked on a variety of Digital Transformation projects. As they discuss common pain points and potential solutions, you’ll gain insights to make your Digital Transformation journey smoother for everyone involved.
- Setting clear and attainable goals
- Getting buy-in from stakeholders
- Taming the ‘information’ beast
- Reducing costs, speeding up ROI, and more
Kent Melville: Hello, welcome to today's webinar, “Overcoming Digital Transformation Pain Points: Changing Processes for the Better with Ignition.” I'm Kent Melville, the Director of Sales Engineering at Inductive Automation. I've been with Inductive for about six years, and I spend my time working with customers, talking about their requirements, their issues, and helping them understand how Ignition can meet their needs. It's pretty rewarding seeing all the cool things that people do with Ignition. So I really like my job. My co-presenter today is Brad Fischer. He's also a Sales Engineer here at Inductive Automation, who I get to work with on a regular basis. Brad, can you tell us a little bit about yourself and what you do here?
Brad Fischer: Yeah, thanks, Kent. So as a Sales Engineer, I get to help Ignition customers and users talk about architectures, solve complex problems, and just overall discuss the platform and find a solution that works for them. If they can dream it, I can help them build it. I've been using Ignition for almost 10 years now. I was previously a System Integrator, along the East Coast, and it's been a lot of fun to kind of move over to the Inductive Automation side of the business and get to help so many other customers bring their projects to reality.
Kent: Perfect, thanks, Brad. We also have a few guest presenters today. First is Reese Tyson, the Ignition Team Lead at Flexware Innovation. And then next, we have Steve Chapman, a Partner at Barry-Wehmiller Design Group. Reese, let's start with you. Can you tell us a little bit more about what you do at Flexware?
Reese Tyson: Yeah, thanks, Kent. Yeah, first off, I'd like to say thanks for having me on. It's definitely a pleasure. But yeah, my name is Reese Tyson. I am an Ignition Team Lead at Flexware Innovation. We have several different business units here at Flexware, ranging from automation up to enterprise solutions and working on projects across the board. Our Ignition group, which I'm a part of, we're made up of 21 individuals, and we just do Ignition projects. So my role as an Ignition Team Lead is just to make sure we're delivering world-class Ignition solutions to our clients. So whether that's SCADA systems in a water/wastewater environment, which we'll actually be talking a little bit about today, or OEE in manufacturing environments, or interfacing with ERP systems, etcetera, we've created a lot of different innovative and custom projects in many different environments. So that's me. Back to you.
Kent: Yeah, thanks, Reese. Glad you're here. And now, Steve, would you tell us a little bit about what you do at Barry-Wehmiller?
Steve Chapman: Yes, I will. Thank you. So first of all, good afternoon, good morning, wherever you may be calling in from. My name is Steve Chapman and I'm a Partner with Barry-Wehmiller Design Group. And they are a St. Louis-based engineering and system integration firm. And thank you for giving me the opportunity to present to you today. I appreciate that. And just a little bit more about myself, I've been with Design Group now for about 13 years. I'm based in our King of Prussia, Pennsylvania office. I've been working in industrial automation for the last three decades, spanning several industries, and more recently, over the last decade, the life sciences industry. And today, I'm currently leading Design Group's Information Solutions Initiative for cell and gene manufacturing. And we're going to be looking at a project today. We used Ignition in cell therapy.
Kent: Perfect. I'm excited to see that project. It should be great. And so it's clear. We have a knowledgeable group with us today. And so here's the agenda for the webinar. First off, for those of you who might be new to Ignition, I'll just quickly tell you about our software platform. Then we'll discuss what it means when we call something Digital Transformation, what a Digital Transformation project looks like, and some real-world examples of that. And then we'll look at how those projects and digital technologies intersect with process improvement. And after that, we'll break down some specific Digital Transformation pain points and their corresponding solutions. And finally, as always, we'll wrap up with some audience Q&A. And if you have any questions during the presentation, you can type them into the questions area of the GoToWebinar control panel. And we'll answer as many as we can at the end of the webinar. And if we can't get to your question in time, we encourage you to reach out to one of our talented account executives, and they'll be sure to help you get an answer.
Kent: And to answer one question that we always get right now, a recording of this webinar will indeed be made available within the next couple of days to watch on demand on our website. A little background about the software platform Ignition. Ignition is a universal industrial application platform for HMI, SCADA, MES, and IIoT. Ignition is used by 44% of the Fortune 500 companies, 57% of the Fortune 100. And why are all those companies using it? They use it because Ignition has an unlimited licensing model, because of its cross-platform compatibility, that it is built on IT-standard technologies and has a scalable server-client architecture. It's web-based, web-managed, with web-deployed designers and clients. People love the modular configurability. You're just gonna pay for what you need and the included rapid development and deployment tools. So we think it's great. You should definitely use it. But today, we're gonna be talking not so much about the software itself, but more about the projects that people do with it.
Kent: And so if we're gonna discuss Digital Transformation pain points, we need to define what a Digital Transformation project is. And that definition can be pretty broad because every organization's Digital Transformation will be unique. However, one common thread of all successful Digital Transformation projects is process improvement through the use of digital technologies. So you can install more electronic devices and collect more data. But unless you're using that data and technology to better your operations, you haven't really transformed, have you? So Digital Transformation is about using these new and emerging technologies to not only change how you perform processes, but also changing your mindset and changing your approach. And so let's look at some projects that exemplify what it means to digitally transform an organization. And we'll start by handing things over to Reese to talk about Flexware's project for American Water. So Reese, over to you.
Reese: Sure. Yeah, so we'll chat through this project here. And I figured it'd probably be a good place to start to understand a little bit about American Water. So the slide talks through that here. So American Water is, really it's the largest publicly traded water and wastewater service provider in the US. They distribute water to about 14 million people across 24 states in the US. And they are comprised of over 600, 700 service water or groundwater, wastewater treatment plants. So you see the graphic there on the, oops, the graphic there kind of just gives you a good idea of the area that American Water serves across the states there. Alright, go ahead, Kent. So we teamed up with ACC and used, which is another integrator that we're working with on this project, used some of their vast knowledge in the water and wastewater industry to kind of collaborate and bring that extra value to American Water. But this project aimed to solve really three main pain points. And really, these pain points are pretty common in projects that we see.
Reese: So they may resonate with some of you out in the audience. But the first one here is inconsistent SCADA platforms. So there was no real standard that was created across the SCADA systems. And it might be common to see a red means alarm on one screen and that same red color means a relay contact is energized and in the correct state on another screen. The second pain point here, there was really no central place to view the data across the company. There are several systems that you kind of had to remote into the system or log into a portal or whatever that might be to view the data from different places. And the third one there is kind of data silos. Data was stuck in the SCADA realm. And we wanted to pull that data from the OT side of things and kind of combine that with the IT side of things, just so we could give the data a little bit more context. So in order to solve those pain points, we created the following project within Ignition. So the first one here was the inconsistency of the SCADA platforms at the site.
Reese: So we created a SCADA platform within Perspective that included UDTs, symbols, when you click on the symbol, faceplates, navigation for the project, the standardization there, trending, etcetera. Some of those typical things that you'd expect out of a SCADA platform, but we wanted to make it really flexible enough to connect to many different types of systems and devices and PLCs. So this platform does follow industry standards such as the ISA 101 and we really tried to focus on highlighting abnormalities to the operators. We also used Ignition's MQTT modules to pump that data up to what we call the Enterprise Portal to view sites in a consumable manner. Next slide there. So the second pain point was, as I mentioned just before that, or this, was the Enterprise Portal. We created that for kind of a central place to view the data rather than having to log into those multiple systems I was mentioning to view the data from the different platforms.
Reese: So that really provided one place to view that information. But now that we had that information kind of side by side and this site A and site B, we could kind of start doing that, some comparative analysis and understand why those sites are performing better than each other. That kind of unlocks the ability to increase efficiencies across the company based on that real-time data that we're bringing into that central data location. And then, next slide here. Finally, we wanted to, like I mentioned earlier, wanted to expose the operational data to other business units within the company. So if anyone out there is familiar with Ignition, hopefully there are a few of you, you know it has plenty of capabilities to talk to other systems and exchange that data. So that's exactly what we did here. We are now exposing this data to lab software suite, which they're using Waterly for QA testing, bringing in data from their MapCall system to pull in information for geographical coordinates, to display different information on, for example, the Map Component within Ignition, and also pumping data over to their data lake with a Kafka.
Reese: So just able to do a lot more analysis over there and provide that information. So as more and more data becomes available and we continue to create this ability to aggregate the data, the power of this tool only really grow with time. So here are a few metrics just to get a better understanding of the scope of this project. We're continuing to add sites to the portal, as well as convert site-level projects over to Ignition. So this project will continue to grow along with the adoption of the technology. But just a couple of things to highlight here is, the amount of visuals that they're serving up and screens that they have open. We have five front-end servers behind a load balancer, and it's a pretty large system there. So that's a really quick intro to our project at American Water. Obviously, if you want more content, you can check out our Firebrand video. It's available on Inductive's website. But yeah, that's our project. Back to you, Kent.
Kent: Yeah, thank you, Reese. That was great. And I love that you're showing that Digital Transformation isn't just about new features, new bells and whistles, right? But instead, Digital Transformation is about scalability, about standardization across an enterprise, improving consistency, adopting open standards, creating enterprise solutions with centralized data. It really is cool to see these projects that we're getting away from just connecting to a machine and they have a local HMI. But now this is something where I can improve processes throughout the entire organization. So very cool to see. Thank you, Reese. Yeah, so next up we have Steve. Steve, can you tell us a little bit about the project that Barry-Wehmiller Design Group did for Autolus Therapeutics?
Steve: Yeah, absolutely. So first of all, just a little bit of background on Autolus. So they are a T-cell therapy company that focuses on developing cancer treatments. And with one of their therapies that they had been developing through clinical trials was moving forward to commercialization, they realized the need to have their manufacturing capabilities ready. And part of that was to be able to network the equipment and implement a process control system or what we call the PCS. At this point, Design Group has been working with Autolus since early clinical phase. So we were already pretty well on our way with kind of understanding what some of their needs were and what that meant to be commercially ready. I'll just share that in October of last year, Autolus celebrated their groundbreaking ceremony for a new manufacturing facility in the UK where we are currently working on deploying the next Ignition project. So we've been working with them now for quite some time.
Steve: And our mission was to use Ignition for data acquisition, visualization, alarming, reporting, and regulatory compliance, which is a really important point when we're talking about the life science industry. So one of the challenges inherent in cell gene therapy manufacturing is that the equipment is laboratory scale. So there are some pictures here of what some of the equipment would look like. And as you can see, it doesn't look like traditional industrial manufacturing equipment, say for a large-scale batch process, large-scale packaging process. This is clearly very different. This equipment's laboratory scale, it's not traditionally networked and thus presents unique challenges with networking capability. And so you definitely need a system integrator to somehow network and aggregate the data into a consistent and concise data source. And as you take a closer look at some of these instruments and equipment, you realize that we're dealing with different types of data and data classes.
Steve: And so when you think about typical instruments for monitoring, say temperature, CO2, relative humidity, and then we've got result-oriented data that comes from some of these analytical instruments that basically run an analytical cycle and they produce a result file. And then you've got equipment where you've got direct integration with the OEM, with the original equipment manufacturer that has the capability to actually be networked and send data across. So you can see there's a need here for different communication protocols. And that was one of the clutch areas that Ignition was able to help us with, with both MQTT, OPC UA and the Web Services Module also proved to be very valuable for this project. It also allowed us to do integration with the client Active Directory that was necessary in order to create the audit trail feature. You know, who's logging in, who's acknowledging alarms, who's changing set points, very important to maintain regulatory compliance when you're storing these electronic records.
Steve: So understanding what data to collect and how to present it and make it available to the different end users was a really important step in this process, in the design process. For example, production personnel, they need to know what's going on in the room, information at a glance. So a dashboard where you could look up and using the high-performance graphics here, you could easily see if you had a piece of equipment that was in alarm. So the dashboards and the floor plan layouts were very important for production personnel to be able to see at a glance what was going on. And then for our other stakeholders that are, say process development, manufacturing science and technology, they're looking for more like result-oriented data, like the analytical instrument results that we were able to capture and, using Ignition, aggregate that data and make it available. And then above all, in clean room environments, being portable is really important, having to be able to take your tablet with you for viewing trends, acknowledging alarms, and to generate that audit trail was a really important aspect of the project as well.
Steve: So overall, the project scope, so this is a kind of an interesting takeaway here. The project that Reese just presented, you think about the vast geographical expanse and the importance of how Ignition was able to facilitate that data aggregation. Well, in this case, it was a lot smaller scale but had other kinds of complexities and challenges. And this project is completely scalable as well. So this particular project could be expanded from one clean room where we've got a set of equipment to the next clean room and to the next clean room. So the scalability was a very important aspect, but the journey to digitalization can start in a very small isolated environment or in a very large and geographical expansive type of environment. So I thought that was just kind of an interesting contrast to these two projects. Overall, we had about 12 different screens. We were using two clients to serve up a dozen or so Perspective sessions to our Microsoft tablets.
Steve: We were using a redundant cloud-based architecture and we have both SQL and OSI PI as our historians in this project for audit trail and event-driven data that we were putting in SQL versus our continuous process data that we were using OSI PI. And really, at the end of the day, the project resulted in compliance of being able to quickly... And this is really one of the most important aspects I would say of how Ignition was able to help us achieve compliance by being able to quickly generate and provide the data to those that need them, ensuring that the data is protected and that it's retained, and ensuring that only those authorized users that have access to the data sources and the PCS data, we were able to automate the data transfers, which was a huge improvement over a paper-based process. And then lastly, those audit trails to record the user interactions of who did what, when, where, and what changes were made was really some of the highlights of the project.
Kent: Awesome. Steve, thank you so much for sharing all of that. I like that you compared the two projects together, the different scales, but the same problems. You have data that's isolated on different machines, maybe not different sites, but different machines and being able to network that all together and improve processes is fun to watch. And I love that you highlighted something that's another misnomer, I guess, of Digital Transformation, which is that people think that Digital Transformation means that you're moving decision-making away from people to computers. That it's all machine learning or analytics that drives decisions, but rather, Digital Transformation is often just getting the data and aggregating the data in a meaningful way and presenting it to the right people so that the right people can make decisions. And I think that this project highlights that really well of getting the right data to the right people and allowing them to do their jobs better and to help improve the whole business as a whole.
Steve: Yeah, yeah, I totally agree. That was a major part of the success of this project.
Kent: Well, perfect. Yeah, thank you so much, both of you, for sharing those examples of successful Digital Transformation projects. And as we discussed at the beginning of the webinar, all of these in one way or another focused on process improvement. However, when there's a shared method of improvement, there are common pain points as well, regardless of industry or organizational size. And a Digital Transformation pain point is anything that makes the job of digitally transforming a company through integration of IIoT-enabled technologies more difficult to build, implement, or update. And pain points can range from small issues to large project-derailing problems. And so luckily Digital Transformation pain points can be solved with the right mix of technology, mindset, planning, and organizational support. And so today we're gonna talk about some of those pain points. The first of which is a lack of buy-in. And this is a great place to start because if key stakeholders won't buy into your Digital Transformation initiative, you're either in for an uphill battle or for a project that is dead on arrival.
Kent: And one thing to keep in mind is that buy-in comes from key stakeholders as well as operators on the floor and really anyone who may be using the application. And that might sound daunting, but there are some solutions. So how do we get people to buy in? The first thing to do is to understand the needs of those key stakeholders. You should also look for solutions that OT and IT can get behind. Because Ignition is a great example because it breaks down those OT-IT barriers so that data isn't siloed off. But another solution is to focus on big-picture goals. You're looking for benefits that stretch across the organization and make life better, not just for one or two people, but make life better for everyone. So that being said, you gotta look for quick wins that help build support and momentum. And so, Reese and Steve, do you guys have any additional comments about buy-in? Were your projects an easy sell or did they need to focus on one area or certain people to get buy-in? Reese, maybe we'll start with you.
Reese: Sure, yeah. I think I'm gonna take a little step back here and talk about a process that we like to follow here at Flexware called “The 5 B Process,” but it definitely hits on this as well. And the first step is a baseline, create a baseline of where are we at. And in terms of American Water, we had those three pain points I mentioned earlier, no central place to view data, inconsistent SCADA platforms, and data silos across the company. And so once we've created a baseline of understanding where we're at, like be realistic. Out of those items, what can we solve, what can we accomplish right out of the gate? Once we understand what we're gonna solve, build that team. This ties into this point right here. If we don't have the right stakeholders involved, I don't care how good your technology is. If people don't use it, it's not going to work. So the old saying, “Garbage in, garbage out.” Right?
Reese: So the fourth one here, build a strategy. What tools are we going to use and how are we going to execute on the realistic action items that we created back in step two? What are the best action items to tackle first to create some quick wins is exactly what you just said, Kent. And when we have the right stakeholders, building that strategy and involving those folks, that process becomes much more streamlined and folks know what's going on so that they can feel like they're a part or actually be a part of the solution. And then number five, they're bringing value. At this point, you can start bringing value to stakeholders because they have been involved in that process. So I've been a part of many different projects and the key to avoiding a lack of buy-in is to get the stakeholders involved in the direction and involved in the direction of the project. So again, if we create this fantastic solution but nobody's using it, what's the point? So stakeholders and end users must be involved in that process.
Kent: Yeah, awesome. Thank you, Reese. And hopefully people are taking notes and learning about, yeah, the processes that have made Flexware so successful. But yeah, it's great to hear about the approach you guys take. And I think you're right that you gotta get those stakeholders involved early and then I love that you finished with bringing value because I think sometimes people think of Digital Transformation as technology for technology's sake, but it's not. It's all about bringing value at the end of the day. And if it's not bringing value, people aren't seeing the value, you're really failing in your Digital Transformation initiative. So thank you for sharing that. Steve, over to you. What are your experiences with lack of buy-in?
Steve: Yeah, so Reese touched on a lot of good points there. And I would just state that it's important that you help the organization realize what, or to understand what are their needs across multiple organizations in the business because it may not just be one organization. For example, in the case of this project, the production team had very different needs than the process development teams. And they really looked at things completely differently. So having stakeholder workshops to work through those needs and the benefits of having the data formatted and presented in two different ways really made it much easier to get a broad stakeholder buy-in across multiple organizational units and not just say, manufacturing.
Steve: And then I think you mentioned that making the data available with regards to, we've got our OT plan for data, but then we needed to share data to the IT side of the network, and that extensibility being able to publish that information was a really huge benefit. And the other benefit that we look out at in the future was integration to MES, which the business really realized was something that they needed. They need to progress towards that goal. So understanding, helping them understand that and how this solution was going to help them get there was really key in getting broad acceptance.
Kent: Yeah, thank you, Steve. I think sometimes as an engineer, I've fallen into the trap of saying, this particular stakeholder is easy to work with and so I'm gonna mostly interact with them throughout a project and they end up loving the results, but other stakeholders end up not so much. But they didn't provide the feedback. And I think, I love that you talked about making sure you're capturing all the stakeholders and making sure you're looking at different companies or parts of companies and making sure that they're all represented because, yeah, it's easy to miss that. It's easy to build for one person and then it ends up not being valuable for the whole company and not providing the value it needs. So yeah, great example.
Steve: Thank you.
Kent: And so, Brad, I'll turn it over to you to talk about our next pain point.
Brad: Yeah, thank you, Kent. So another major Digital Transformation pain point is disruption. Obviously, you'll need to devote resources to your Digital Transformation initiative, and this can obviously disrupt the workflow and the daily routines of team members. These changes will challenge the comfort zones of those team members. And so some people may feel threatened or have some uncertainty. And one of the things that you commonly hear is, "Oh man, another software package that I need to learn." And what that usually indicates is a failure of some level during a previous Digital Transformation initiative. Because what they're really saying is, "Another software package I'll have to learn to work around and not with." And so what can we do to mitigate the negative effects of these disruptions? First off, as you guys just touched on, strong communication is key. Explain to team members why these changes are necessary beforehand so that they can see the bigger picture.
Brad: Make it clear that the greater risk is to not change because Digital Transformation is needed to ensure that the company stays viable in the future. Communication is a two-way street, so you've gotta give team members a forum to ask questions and share concerns, especially when those concerns are about the disruptions that they're gonna face. Scheduling feedback sessions with floor operators as well as management is a great way to minimize those disruptions because those people, not only are they aware of the disruptions that they might face, they may have a very good solution that would be easy to implement. And so your resources might need to be allocated a little differently during a Digital Transformation initiative, so it's always a good idea to strategically prioritize. But really, the right technology solution minimizes those disruptions. And since Ignition can be deployed so quickly, it reduces the disruptive impact. Steve, as an integrator, do you have any thoughts on how to reduce disruption during a Digital Transformation?
Steve: Yeah, so projects have so many different makeups. You look at projects that could be automating a high-volume, low-margin type manufacturing process. It could be the quite opposite where you've got a very valuable, small-batch situation, which is the situation that we were in with the project that we're speaking about today. And so that sets the stage for the end user in terms of what their frame of mind is. I understand exactly the example you gave where sometimes operations are resistant to automation and change, they might feel threatened by that. And so that presents a whole unique set of challenges that you've got to overcome by demonstrating the value and the ease of use. In the example with Autolus, one, we had a very informed client with a very specific need, and they were very eager to streamline their processes. They understood that that was going to be a requirement if they were gonna move from clinical into a commercial manufacturing setting.
Steve: So the landscape there was a little bit different. And quite thankfully, that was a great opportunity and a great environment and collaborative environment to work in because I have worked on the other side of that where disruption and reluctance runs amok. And so the easy answer on the side where you've got clients that are informed and they want to work towards streamlining the process, that was quite the workshops with stakeholders to gather requirements, requirements definition really eliminated those types of disruptions. But on the other side of that, in the other scenario, you really are going to have to give those team members a forum to voice those questions. I've been in situations where it was an engineering project right up until the point it was to be taken over by production, and that never goes well. So early and often getting those team members engaged to pull them in and make them feel like they're part of the process and the project is a key to success.
Brad: Absolutely. Well, thank you for weighing in there, Steve. And for our next pain point, I'm gonna hand it back over to Kent.
Kent: Yeah, thank you. Digital Transformation can be a broad concept, but a successful project is predicated on tangible results. And so it's not enough to simply say, I want to digitally transform my organization, you need to decide how processes will be improved. And so this pain point is unclear or unrealistic goals. And unrealistic goals are not exclusive to Digital Transformation, but having goals that are specific makes achieving them possible. And really, the solution for this pain point is pretty straightforward. You have to narrow your vision to what you wanna change in your process instead of chasing tech trends or buzzwords, instead you gotta go after real problems. And you're looking for results over concepts. Analyze your process and identify areas in need of improvement, and how do you clarify the steps towards process improvement?
Kent: You do so by defining your goal, the method, and the measure for improvement. As you go through this process, you have to ask yourself, what does success look like for your project? Because it's gonna look different depending on your industry, the type of product, and a multitude of other factors. But certainly, I like that Reese already brought up some of these points at the beginning, talking about in your “Bs” there. At the beginning, defining the process, making sure you have that shared vision, that same goal that you're working towards and all that kind of stuff. And then making sure it's bringing value. So yeah, Reese, could you share any comments you have about goal setting and how that can solve this pain point of unclear, unrealistic goals?
Reese: Yeah, definitely going back to what I mentioned earlier at American Water, one of the goals that we specified early on in the project, during that build-a-strategy phase, was wanting to get buy-in early. So we focused on one site, getting the data out of that site, and we were able to show stakeholders what the vision of this project was in a very tangible form. And that's when things started to click, and we can kind of unleash the potential of what Ignition has to offer. This is when we start to get to the fun part. Now that all the upfront work of creating the baseline, being realistic, and building the team with the right stakeholders, once all that's done and we're all on the same page, we can start looking at that data and start really iterating on that phase-one success. And we start the process all over again with creating the baseline and where are we at now?
Reese: What do we want to do differently next time or in this next iteration? And creating that strategy of the things we wanna tackle next. And once again, obviously get those right stakeholders involved. This is a process, this process is a journey and not a destination. And if you can help everyone involved understand that, A, this is new, and you know what? We're gonna celebrate the wins, we're gonna get better from the losses because both of those things will happen in the journey. You have the highs, you have the lows. But if we all understand where, "Hey, we're marching towards this end, the common goal," setting those mental parameters is extremely beneficial when we're trying to attempt and create really any kind of change, not just Digital Transformation.
Kent: Yeah, thank you so much, Reese. I love that iterative approach and about helping set those expectations at the beginning that there's gonna be successes and failures. Because I think some people, especially when they have large-scale projects, which a lot of Digital Transformation projects are large-scale projects, right? There's so much pressure associated with, is this gonna be successful or is it gonna fail? And by breaking it down into smaller goals and having that iterative approach, I think it takes the pressure off and I think then people can see value along the way. Yeah, I think that that's super valuable to ensure that the people find success in the project, even if there are individual things that are hiccups along the way. So yeah, thank you so much for that. And Brad, I'll give it back to you for the next pain point.
Brad: Yeah, thank you, Kent. So projects can be slowed down or derailed when there isn't a healthy flow of communication across devices or even systems. Interoperability is the key for this pain point. And so when managers or operators don't have access to real-time data, it makes it a lot harder for them to do their job. It's one thing to have information coming in from a PLC, but it's another to be able to have a system that's integrated with your ERP, MES, or CMMS system. And on the other side of the coin, we're seeing ongoing supply-chain issues that are highlighting the need for different systems to work with one another. Organizations are turning to the technology that's more flexible.
Brad: And without open communication across systems, it's really hard to pivot when specific hardware is suddenly unavailable for months at a time. And for a successful Digital Transformation, you need to break down those barriers. Ignition has open standards and ties into other systems, which helps avoid communication issues across systems, right? So giving operators and managers real-time access to data wherever they are allows them to do their jobs properly. Open-standard software creates a strong foundation for Digital Transformation, prevents those communication barriers. The right architecture can help a dispersed network function in a much more unified way. So Steve, any advice you want to share about overcoming communication barriers?
Steve: Yeah, sure. Thank you. And thank you for picking me for this particular pain point, because I think this is an easy one. In the project that I presented, we had three different types of data flows. We had continuous data, typical instruments for monitoring environment, temperature, discrete alarms, and whatnot. So using Siemens PLC, we were able to speak OPC UA natively. Result-oriented data that was often hosted in software as a service, where we needed to use a web API to communicate to get the data across. And then we had OEM equipment integration that was real-time data that was coming across via MQTT. And so right there, we had three different challenges that were easily overcome using the communication interface capabilities of Ignition. So you can see that there's going to generally be a need in many projects for different communication protocols. So that solves the issues on the plant floor and being able to aggregate the data. But then making the information available to higher systems, whether it's an MES application or directly the ERP, again, is very achievable. So that was really my experience with it, was having the tools in the toolbox to get the job done.
Brad: Yeah, great, great. So yeah, thanks for that, Steve. I think Ignition's a very good solution to be able to connect to all those different things and pull all that data together. So alright, so Kent, why don't you go ahead and talk about our next pain point?
Kent: Sure thing. And now we come to the oldest and most persistent pain point, which is cost. And the pain point, cost, predates Industry 1.0. Now we're Industry 4.0, but cost has been around since before industry was a thing. So whether it's a single process upgrade or enterprise-wide overhaul, every project has a budget. But it's always smaller than you want it to be. And if you're paying by device, that's really where you start to run into cost issues. But with Ignition's unlimited licensing, you pay by the server, meaning that you can add as many clients, screens, tags, devices, or connections as needed for no extra cost. If you don't have an Ignition license, certainly you can download Ignition for free. And it runs in a two-hour trial. You can refresh that trial as long as you need to.
Kent: In fact, some of our biggest clients have told us that they actually built full-proof of concepts using just that Ignition trial. And then once you have that license, you do purchase Ignition, everything that you built during the trial – tags, templates, UDTs, windows, scripts – all of that stays. No need to start over. You don't even have to import it or export it from your trial system into a new production system. It's just all one and the same right there. Another cost-saving feature is that Ignition is modular, so you only pay for what you need. But overall, we try to remove barriers here at Inductive Automation. And cost has become such a barrier for Digital Transformation. And so we're trying to do our part to make it simple, straightforward, and easy. But Reese, do you have any additional comments about overcoming cost pain points when planning or implementing a project?
Reese: Sure. Yeah, I mean, as you said, cost is pretty straightforward, I feel like, if we spend more than we make, that's typically not going to end really well, I guess, contrary to the Fed's recent track record here. But as you mentioned, with all the different unlimiteds that Ignition has to offer, "unlimiteds" I'm doing quotation marks in the air here. That's kind of what I like to call them. It's Ignition, that's just such a no-brainer. We're starting to see a lot more projects go to the enterprise route and bringing data from multi-sites and aggregating that into one location. So the unlimited tag, just that alone, the part of the licensing, it really allows the ability to scale out large solutions without concern for going back to the well to fund those licenses and so forth.
Reese: And really, that's exactly the case with American Water. With so many different site deployments, the low-cost barrier that Ignition has to offer, it really starts to become a huge advantage. And I would also mention in addition, another cost that might not be as tangible but should absolutely be considered is time to market, or cost and time that it takes to complete this project or get to that proof-of-concept stage. So with the trial mode, as you mentioned, with free downloads, with Inductive University, user manual, designers, super easy to develop in, all these things that Ignition has to offer, it really knocks down that development time so you can bring value very, very quickly and get that buy-in from the stakeholders.
Steve: Great point.
Kent: Yeah, absolutely. And that actually leads us really well into our next topic. And so Brad, take it away.
Brad: Yeah, thanks, Kent. So as we just discussed, time is arguably the most valuable resource we have, right? And tasks that are a huge drain on time and effort pose a danger to a project's timeline. Inefficient ways of completing tasks is one of the main culprits for this pain point. And additionally, some tasks might just be too much to put on one person's plate. And so software that only allows one person to be in the designer at a time really slows things down. Ignition's free trial helps you quickly find a way to complete these kinds of tasks. Ignition lets you have unlimited people working concurrently on a project, on a gateway, even on the same screen. And your team can really put their heads together and knock out time-consuming tasks quickly. Rapid project development methodologies, templates, UDTs, all of those really speed up those kinds of tasks. And templates really help to streamline a task and it maximizes your efficiency. So any insight on this pain point, Steve?
Steve: Yeah, thanks. One word: COVID. So in 2020, we were in the midst of developing this project that I just presented to you. And so that was during a time in the US when everybody was working remotely. So because that we were able to have multiple people logged in at the same time, developing in the application, really helped us to keep the project on track. So it was an unfortunate situation that the country was in at the time. But thinking about it now, I don't know how we would have been successful delivering the project when we did.
Brad: Right, and I can only think that 20 or 30 years ago had that happened, we just wouldn't have had the ability to create those kinds of solutions that quickly, right? It would have been, you would have had to work on a project and emailed it back to a coworker for them to review and do more. And they would have had to email it back to you and it would have been a very cumbersome process.
Steve: Yeah, totally. And in the Ignition community, there are examples and source code out there that can be leveraged. Now the open-source nature and the community that's willing to share project examples or best practices, I think is also another huge time-saver.
Brad: Absolutely, well, thank you, Steve. Kent, I'll pass this back over to you for our next pain point.
Kent: Yeah, and this is really where cost and time come together, which is the pain point of slow ROI. What is ROI? ROI is your return on investment. So you're spending some money, you're investing upfront, and you're expecting that you're getting the value out of that investment. And so organizations naturally want this to happen quickly and they may get frustrated if ROI is not apparent within the timeframe they want. And this relates to the cost pain point and the greater the cost, the longer it takes to recoup that cost or to get ROI. If a project scope gets bigger, slow ROI can make it hard to get the additional funding that's needed or the support that's necessary to continue. And if slow ROI is a major issue, Ignition's a game changer 'cause it saves both time and money. Kind of the benefits we see there, the things we've talked about, you don't have the typical licensing issues. So you can implement changes quickly. We help with optimizing deployment, maintenance, and uptime, which lowers your overall total cost of ownership.
Kent: And digitization reduces operational and maintenance costs. Ignition also gives you better visualization of that data to let you see and respond to issues faster, get the data in the right hands, in the right way, you can leverage the MQTT Module for bandwidth savings to help reduce data rates, real-time visibility of all assets with the cloud has direct savings in travel costs. If not having people on site to view something, they can view it remotely. And then like we've talked about before, overall faster deployment is gonna equal quicker ROI. But another solution comes back to those quick wins we were talking about earlier. Creating this proof of concept, that idea of kind of building something quickly, getting quick value at the beginning, those quick wins, that increases the customer's patience for long-term returns. And then finally, as we set realistic expectations for stakeholders from the beginning, then they're gonna stick around with us, that we got that buy-in at the beginning. So, Reese, any comments from you about dealing with slow ROI based on your experiences?
Reese: Yeah, I think this one kind of goes back to the one I just talked about with the cost. But it kind of ties into also building our strategy, right? Not only does that include figuring out the technology and what's gonna be cost-effective, but also how are we going to execute the steps to get to that end result, right? So that's when we would decide if we need to provide a quick example and get feedback for further direction, or do we have enough information, right, to go off of and have a bit of a development runway to create the general project, and then you can kind of tweak things as needed as you go along. But this is completely dependent on the stakeholders, the company culture, the process that the operators are going through, and really, it's going to be unique for each scenario, each customer, each project, etcetera. Really what drives this is what makes the most sense in each situation. So in the case of American Water, we wanted to get some quick wins at the Enterprise Portal, as I mentioned earlier.
Reese: So we had the ability to show the power of the system right out of the gate. So one of the things, steps that we did was we selected a site that ACC, our partners on this project, a site that they're very familiar with. And while they were working on getting the tags and the mapping, etcetera, we were working on the portal side of things, creating our first revision of the Enterprise Portal and the visuals and how we're going to represent those tags. So we were able to kind of meet in the middle and provide an idea of what the system could look like. And once we hit that first milestone, folks were able to visualize those new features and also like, “Oh, we should include this or that or the other thing.” If you can access the data from site A, could you also grab that data too and put that side by side? So it really all boils back to sitting down with the stakeholders, building the strategy according to what makes sense in that situation, and bringing that value quickly and efficiently to the folks that need it.
Kent: Perfect, thank you. And Brad, back to you for the next one.
Brad: This next pain point is at the crux of any Digital Transformation initiative: difficulty finding, understanding, or leveraging information. There's no point in using IIoT-enabled technologies to collect all this data if you don't have an effective way to use it, or if by the time you can use it, that information is already out of date or it doesn't accurately represent your plant floor, your field site. And when I say use data, I'm talking about data access. Is data democratized throughout the organization or can only a select few see it? Now context: information is important, but information without context is just numbers. And actionable insights, can you look at the data you're collecting and leverage it to improve your operations?
Brad: Ignition offers a robust solution to this pain point because it breaks down data silos and gathers information from the plant floor to the edge to the cloud, and lets you see it on desktop, mobile, most any device. There have also been a few recent Ignition features that can provide more data or let you use it in a more active way. The first that I wanna highlight is the Tag Report Tool, which lets you quickly build queries that can search for specific tags based on properties like tag path, quality, types, traits, ancestors, etcetera. And once you've defined the parameters for a specific tag search, you can save that query for later use and generate like a CSV export of the search results. You can also perform the tag search via a scripting function for those of you who love scripting.
Brad: The other big one is the Machine Learning Manager. And it isn't actually in a specific version of Ignition. Instead, it's on the Ignition Exchange. For those of you who are unfamiliar, the Exchange is an online repository of free Ignition resources developed both by the IA team as well as Ignition community members. And honestly, the amount of cool stuff on the Exchange is staggering. There's over 250 resources. You should definitely check it out if you haven't. But coming back to that Machine Learning Manager, it allows users to create, train, and process machine learning models. And this can be used for a variety of practical applications, right? Including anomaly detection, preventative maintenance, reject or bad product prediction, process tuning, even digital twin simulation and prediction. So Steve, do you have anything to add about leveraging the information?
Steve: Yeah, I'll key off of something that Reese said earlier, except I'm going to call it “The 4 Rights.” And that is about getting the right data to the right people in the right place at the right time. And that was exactly the challenge that we had with our project. Challenge met, but understanding what those “4 Rights” were was really a key part of the project. Perspective presents a key feature for the project and the fact that we were able to go mobile. Tablets are commonly used in this industry. So having the real-time monitoring application on your person was a huge benefit. And then having to kind of overcome this OT-IT barrier, the convergence of OT-IT was another key element because meanwhile, the folks in process development and MSAT, they needed result data for analytical and process improvement purposes. And they're across the campus. So they're not within the OT network space where they could access that data. So again, that was another huge challenge overcome by being able to make that data extensible to other parts of the organization. So, that I think to me are probably the most important aspects of the project when it comes to difficulty getting information to the right folks in the right time.
Brad: Well, thanks, Steve. Kent, how about you discuss our last pain point?
Kent: Yeah, we're about out of time here, but the fact of life is things go wrong. We all need help sometimes. And so needing support itself isn't really a pain point. Instead, it's about the support that you get. And unfortunately, a lot of tech support out there in the world is not great. Support is something that we really pride ourselves on here at Inductive Automation. That's not just our support division, which is excellent, but also a bunch of online support, whether that's through our ecosystem of partners, or whether that's through our distributors, whether it's through Inductive University and our online user manual, all that kind of stuff. We're trying to get you the support that you need so that you can make sure your projects are successful. And Reese, in 15 seconds, any... You agree? You like the support from Inductive Automation?
Reese: Yeah, I'll keep it really quick here. Absolutely. As an end user, I use Ignition on the daily. If you've used Inductive support, you know that it's incredibly knowledgeable. Everybody over there is incredibly knowledgeable, follow through with outstanding items. And often, actually, I just had this happen a couple of weeks ago. I'll take items that we work through back to the dev team and implement some of those items back into the platform to continue making the Ignition platform just that much better. So, you guys really provide a service that’s second to none. And if support is a pain point of yours, it should definitely not be on this list.
Kent: Well, thank you so much, Reese. We've gone over a lot of pain points today. This kind of just shows you a list there. And so we really hope that this has been useful as we've talked about these different pain points, that they don't need to continue to be pain points, right? That there are solutions. And as you do these things, as you do business the right way, really, we can make it so that each of these Digital Transformation projects are successful. We really see Ignition as being one of those main solutions for Digital Transformation. So, if you're already using it, great. If you're not using it yet, check it out. You can go and download it for free on our website. And we hope you do. For those of you outside of North America, we wanna let you know that certainly you can reach out to our distributors so you can get some help for people nearby. Their information's all on this slide, but also on our website. And if you have questions of who to reach out to, you can always reach out to Yegor. His email is there below. If you'd like to talk to one of our account executives here at our headquarters in California, you can call 1-800-266-7798.
Kent: We're happy to answer your questions as well. Speaking of questions, we haven't had a ton of questions come into the chat. So, if you have any quick questions, you can go and type them in really quick. But one question that did come up is people were talking about how we talked about you can do concurrent development. So, multiple developers can be in the project developing things at the same time. They asked, “How does that really work?” In Ignition when you go and you open up a screen, it then shows as open. And if somebody else goes to open that screen as well, then it'll prompt them and say like, “Somebody has this open, are you sure you wanna open it?” And if you say yes, then you can open it. But then when one person saves, it'll prompt the other person saying, “Somebody else has saved their work. Do you want to load their changes?” Things like that. And there's ways you can export your screens and merge your changes, all that kind of stuff. If you do a save and you see other people have changed different resources that you weren't on, you can make sure that you're choosing which changes to keep, merge changes as appropriate, all that kind of stuff.
Kent: So, there's some conflict resolution built into the Ignition designer. Also, shout out to Steve, people are loving your “4 Rights” that you brought up there at the end. So yeah, thank you everybody for your feedback. We're out of time, so we're not gonna be able to get to other questions unfortunately, but please reach out to your account executives like we said at the beginning, we'll make sure we get questions answered. We hope that for Digital Transformation, you guys are finding success, that you are helping your customers through these projects, that you're helping yourself through these projects, you're working with stakeholders, having those open lines of communication. And if there's anything that we can do as Inductive Automation to help you through those processes, please let us know. But with that, we're out of time for today. So, I just wanna say thank you everybody. We're just really grateful to have had Reese and Steve here. So thank you both for being here. And Brad, thanks for co-presenting with me. And bye for now. Hope everybody has a great day and a happy Halloween.
Steve: Alright, thank you.
Reese: Thanks everybody.