Senior Program Manager Kelly Chalmers presented a webinar entitled “The Customer and System Integrator Relationship: A Critical Element for a Successful Automation Project” for Machine Design’s Day of Learning 2021.
A veteran employee of more than two decades, Kelly Chalmers began her career 
at AMT as a process engineer and has worked in progressive roles as a processing and simulation leader and engineering group manager before being promoted to senior program manager. In her current role, Kelly has worked closely with Applied Manufacturing Technologies’ system integration clients on dozens of projects. In a webinar hosted by Journalist Rehana Begg of Machine Design for the annual Day of Learning, Kelly shares key client-integrator relationship management strategies for a successful system integration project.
“I've had several different roles at AMT, and it's really been able to give me a wonderful perspective on how we interact with our customers every day,” said Chalmers. “I've worked both on the services-level, interacting with the customer while they're in the midst of their engineering journey for automation projects. I've been a senior engineer, working as a project manager and directly working with the leadership on projects. I've also contracted into the customer’s organization, helping them on their end and working from their perspective.”
Assessing Readiness for Automation
Kelly Chalmers’ presentation focused on the important relationship that gets built between customers and system integrators, enabling project success. “The very first step before everything gets going is the customer assessing its own readiness for automation, which is a very critical part of the process. This is what allows for a project to start with all of the right tools in place to go forward on the same page with system integrators and their vendors. We must take an honest look at the level of automation maturity of the client. We're in an age of technology growth and there's a lot of new development taking place. Many companies are taking on new technology, new processes and also new ways of doing business. An organization needs to have the ability to look at themselves and understand where they are on a level of maturity for being able to understand automation, to maintain it, and to support it long-term. This will drive the needs that they have in automating, which will be taken care of during the course of a project, whether it's getting additional training or understanding how to fill those gaps.
“Next, we talk about the client’s corporate goals. Often, there are goals in place and those need to be broken down to the actual attainable target goals for a specific project. Those goals may be long-term or short-term, but we need to understand how they're directly related to the project that's about to be undertaken.
“Finally, we focus on stakeholder engagement and ensuring that the appropriate voices are being heard. This can be speaking to those levels of leadership in the organization, or also down to the day-to-day operators and those people that are going to be directly influencing how automation is being used on a day-to-day basis for manufacturing or other production.
“We take an honest look at these items to evaluate automation readiness, which creates the starting point for an automation project. It's the end user's responsibility to be able to bring this candid information to the table, which creates the baseline for all of the organizations and other entities that are going to be engaged on the project and are going to rely upon this being a stake in the ground. They won't be able to sit there and question it, it's going to have to be a known starting point. What we’re really trying to get to is answering the question, Is the organization prepared to take that next step and move forward? If the customer can't answer those questions or they're not ready to agree upon where they're at, then the idea is that they're not ready and they need to go back and reassess or take steps to understand how to approach them differently.”
Defining the Role of the System Integrator
The system integrator’s role is critical in assessing automation readiness and setting the project up for success. “When you think about an end user, you're often faced with an organization that does have engineering and automation engaged already,” said Chalmers. “Many times, they feel that they have expertise in being able to do automation installations and commissioning those types of equipment on their own. But when we really break it down, what we see typically is that the end-user more often has expertise in the manufacturing or process that they're responsible for, not in the automation itself. If the company makes a certain product, their expertise lies in the way that it's made. They may have experience with automation, but it's typically not expertise. The automation knowledge is a by-product, really, of what they're actually trying to accomplish.
“On the other side, you have vendors of different types of equipment, processes, technology, and information systems that have their own agendas. They are not in the business of trying to create that tie in to a specific end user. They do have their own agenda because they're a company as well, which is to sell their own products. Many times, you'll have partnerships between end users and vendors and they're trying to create that tie. Those are very specific relationships and they are very narrowly drafted as far as how much they can accomplish just within that one relationship.
“And so, the role of a system integrator becomes creating that connection point and really ensuring that all of the hardware and software that is created by different manufacturers is all working together and meeting the end user's requirements. If you remember from the self-assessment, What are the needs or gaps that have to get filled on the end-user side, by the different pieces of the puzzle that you're bringing in?
“Additionally, the system integrator must make sure not only that the new equipment and new technology in the system is all functioning together, but that it's also integrating into whatever existing equipment is in the facility. That includes everything from machines to work processes that are in place. A very critical example of this is when you have labor unions involved at the facility. There are a lot of rules and regulations that are already agreed to; anything that you're putting new into a facility does need to be considered from that perspective. Also, our IT infrastructures – that is a very overarching umbrella to the technology that is being utilized inside of a facility. Those needs should be taken into account as well when you're trying to integrate any new pieces to that puzzle.
“The analogy I like to use for the system integrator is this idea 
of a wheel and a hub. The end user is getting the work done; that's the outside of your wheel that is rolling down the ground, getting you somewhere. You have your pieces that are all contributing to the structure of the end user being able to do its work. You have machines, IT, technology, people - even all of the people and the key stakeholders are a part of that wheel as well. They are there to help get that work done. And the system integrator is really the hub in the middle. You're the one that's tying all those pieces in to make sure that they're properly supporting that wheel structure so that the wheel integrity is there.”
Selecting a System Integrator
When it comes to selecting an integrator, Kelly Chalmers believes it's really about finding a good match and asking How do the customer needs align to a particular system integrator? “You're looking for that match of strategy and philosophy,” said Chalmers. “A lot of these ideas are very big things and it's not really boiled down to a person, for example. You will see a lot of companies that have found a very good working relationship with a certain project manager, like myself at an integrator or a certain engineering team or something like that. One of the reasons that those relationships get so strong is because they've learned to understand the customer's needs and where they are along the line of all of these parameters. Again, this comes back to that original first assessment to figure out, What do you need? and Where do you sit?
“Finding the match – it's not really about who is a good system integrator; it's really about what organization would work best with your particular group. An example of that may be something like, I'm an international company, and I need to have a system integrator that can work within those types of boundaries versus something that's more domestic. That's a very specific need. Some companies have experience with that, and others may not. There are some system integrators that are very niche and have specialized experience with a certain industry or a certain application. If there's a need in that direction, then that becomes a very good match. 
“If you are in something that's a little bit newer, maybe a new process or a new machine that is being used in a different way, or maybe it's a very broad undertaking where there is no specific type of equipment or process in place, it's really, I need ‘A’ to turn into ‘B,’ tell me how to get that done. In this case, a system integrator with engineering capabilities becomes a priority because you actually need your system integrator to help you figure out not only how to get it done, but what are those pieces because they haven't really been figured out yet. All these types of parameters become important to go through and assess where do we sit with these ideas and how does a potential system integrator also align to them to find that good match.”
For more information about selecting a system integrator, download this eBook by Chief Operating Officer Craig Salvalaggio.
Successfully Kicking Off the Project
The successful kickoff of a project between a system integrator and an end user or customer is a very critical step. “The ability to move successfully past this point and into more of a work process is really a defining moment,” said Chalmers. “It's something that you don't get a lot of chance to redo once it's done. Being prepared and coming to the table to create the right version of the kickoff is really important. In itself, it's very simple which is why sometimes it's very unassuming and people can take the process for granted. It just seems like it's such a simple element to the project, but if we don't take it with the amount of importance that it has, some things can go by the wayside.
“The first step is the definition of the project team. I say the word definition pretty specifically because it's not about assigning a project team and it's not really about creating a project team because in general, that always happens. The real part is the definition of the project team. What's important about that word is that we're actually defining how we want the team to operate by what type of stakeholders we're bringing to the table, by what type of leadership we're bringing to the table, because perhaps this end user really needs the system integrator to function with more leadership and actually be more of a driver with the project as a whole.
“Other companies or organizations may do it differently and may want to be the driver. Some clients really just need that foreman on the construction site that gets the jobs done and keeps everything moving, but they really want to be the leaders of the day-to-day work that's happening. And so, again, that definition of the team is really a critical step. It's going to set the tone for how everything moves forward. If we fail at that first step, what you could end up seeing is a lot of disorganization and communication breakdown. One of my favorite questions that I ask every single time, and again, it's very simple: What is our protocol coming out of this meeting for how we're going to communicate? Are we planning on having a single point of contact? Are we planning on having a group email with 10 people in it? There are many reasons for going different routes with that; that's not really important. There's no one best way - what's best is what fits how the project team functions.
“The second item I have on this list is the shared understanding of the current situation. I will see a lot of projects start out with a definition of what they want to have happen. They'll have the end goal very clearly stated, which you'll see also on this list, but they will not be sharing with the full team a more robust description of where we're at today. What everyone is trying to do is get to the delta. We're all trying to change from where we are today to what the end goal is, and it's really hard to make sure you aren't missing something. If you have not clearly communicated where you sit today with all of the items that need to be addressed – and that's everything from not only your current way of working on the floor today, the current equipment you have in place and those types of things, but also the current understanding of where you are today from a metric to say, We are working today and producing this much product, because even things that you're not trying to improve, you have to maintain.
“You need to make sure that everyone has that clear vision and you'll see even the end goals on the list as well. Like I mentioned, if we haven't clearly stated what the end goal is – and it can't just be 'install machine X,' it really does need to come with an idea of what was trying to be accomplished. A machine, a piece of equipment, a new software package: those are a means to an end. And if we don't understand clearly what the end goal or goals were, then whenever we hit a roadblock, we won't be able to make the right decisions. Not only are we not able to see around obstacles but we're not able to communicate it clearly back to the whole team. I won't understand that I have missed the mark somewhere if I didn't understand that that was some kind of a parameter that needed to be addressed.
“The last item on this list is very clearly something that should be done during the course of the project. As we're moving forward, very often responsibilities will be fanned out to different types of stakeholders, whether it's engineers or researchers. We not only need to measure progress and the schedule, but we need to agree on the tools that we're going to use to do that. We have a lot of delegation in our world today, and very often, we'll find that if I haven't given you the tool that I want you to use for that measuring of progress, then that gap will be filled by someone else. Of course, because they're going to want their team to be able to understand where they're at, and soon I'll have five different versions of how people are measuring their progress.
“When that happens, not only is it a difficult thing to bring together, then it's also not something that can be shared amongst our project team to make sure that everyone is on the same page. I may have two or three different engineering teams working on different areas of a project and they need to be able to depend upon each other because there will be a point where they are going to need to intersect. If they can't understand where everyone's at, then it creates gaps and delays. These are clear and simple items for a kickoff, and yet very difficult for us always to get it right when we're not all on the same page, especially the understanding that these are the critical things that need to be accomplished.”
Customer and Integrator Project Roles
Now that the project has successfully kicked off, the customer and integrator must establish roles for a successful project execution. “We've kicked it off; we went through and accomplished everything. We're all starting out on the same page - and every project is different,” said Chalmers. “What's actually happening during the project? There can be 20 million different versions of how you run a successful automation project, but there are things that are clearly common. Again, keep it simple. The number one rule is that you keep each other accountable. There are usually responsibilities on both sides and at different phases of the project; you may have one side or the other be a little bit more heavily burdened as far as things that need to be accomplished during a certain time, but you are accountable to keep the team abreast of your area and accountable to make sure that the other side is also keeping on pace.
“For example, I may have a project that was kicked off. Everyone's on the same page. Everyone walks away with action items. But if I can't keep nailed down one portion of that, say, if an end user has a goal or several goals that they're accomplishing with a project but that bar moves - and sometimes that's going to happen. It's not necessarily bad to have things change. There are very important levels to an organization that all need to be heard and sometimes starting those conversations can start that ball rolling for other areas of an organization, and now we need to make sure we tie in. But if the bar keeps moving too much, then we will never be able to progress. It's the job of a system integrator to come in and if we can't create a new level baseline, then we need to actually hit pause and say, Let's just stop for a second. We actually need to go back to a prior step, which is the self-assessment. Are you ready?
“Keeping each other accountable for these different types of phases that we're in is by far the number one role of the integrator and the customer. For the customer, it’s the same way; they need to be able to keep the integrator accountable. Are you making the decisions in line with our needs? Are you understanding our needs? Are we progressing to the point of our schedule?
“Bringing in outside resources is a very big part for both the integrator and the customer. It’s easy to think of this in the role of the integrator: you're very often going to bring in vendors or different suppliers that are providing you with the automation and technology that you want to bring to the project. Similarly, customers are responsible to bring in outside resources for their level of ownership.
“A very clear example that we see often is when we are dealing with safety. In the role of an integrator, I have a lot of responsibilities with safety, but the customer also does because they're the ones that are going to own the safety of a system when I am done. It's obviously a very important topic, and so the idea of the customer bringing in whatever outside resources that they need to either properly assess the safety needs of a system, or if they have other organizations they are a part of that also need to bring that in - they need to bring those resources to the table as well to be engaged in the project early on.
“The end-user preparation is another item that both the customer and integrator need to get engaged on. When we're going through a project and we are engaging in new technology, in particular, we do need to make sure that there is buy-in and also proper preparation for that to be integrated into a facility. Some of that is things like training. Training isn't something that you get to go out and purchase and then you have overnight. This is something that needs to be part of the discussion during the project as a whole. You don't want to get to the installation then say, Oh, I wish all these people that are working with this piece of equipment knew how to work it. Training actually has to be part of that work during the project. The same thing is true with buy-in. I think a large part of our work these days is actually doing some education and show-and-tell, if you will, for people that maybe aren't part of that kickoff meeting in the beginning, but they are stakeholders. Whether they are team leaders out on a floor, or support personnel that are going to be maintaining a piece of equipment during its lifecycle, bringing them in and having them be able to interact or have some feedback into how our automation is being designed and engineered is a very critical step.
“You're talking about people that have sometimes been working with this type of equipment or automation for years and years, and they'll know more than I ever will because they are the ones really using it, so getting them brought in and prepared for what's going on during the course of the project in different stages is very critical.
“The last element, which is something I feel pretty strongly about, is roadblock transparency. Of course, you have the roles of integrator and customer, and then also our vendors. You know, we all have a little bit of our own agendas. You have a responsibility to your own organization, for example, and that can fly in the face a little bit sometimes of being really transparent about problems and concerns. Even sometimes conflicts which is a little different than problems, but I think the ability to take roadblocks in particular and make sure that those are transparent during the project between the integrator and customer is a very critical element. A roadblock, for example, is something that not only is a concern that someone had and we're working through it, but it has become a roadblock. We can't move past it until we have dealt with it. It's actually going to impede progress. And so, whenever you encounter a roadblock versus just the inner workings of a project where there are concerns…a roadblock in particular must be transparent to the key stakeholders so that we all are working together. Many times, what we're doing is adjusting the schedule and sometimes we're adjusting goals. Working through those in a transparent fashion and making sure everyone has all the information that's needed to make those decisions is very critical.”
What Happens After Install?
The successful kickoff and properly defined roles have led to a successful project, so what comes next? “At the end of the day, what happens after install?” said Kelly. “I've seen a lot of projects that have amazing technology and very exciting processes. I've seen them run off successfully and then I've seen them sometimes sit there in a corner gathering dust. This happens to many, many companies and there probably isn't a company something like this hasn't happened to. Usually, it happens because one of four critical elements has failed. The first one that happens when you're done with install is that you have a handoff to the customer, and that can take a lot of different kinds of processes into place. Sometimes it's very formal. Sometimes it's very informal. Sometimes it's a very shared experience where you're collaborating at the end but agreeing to what that should look like and making sure it really fits with the automation maturity of the end user, which is very important.
“If the handoff isn't properly handled, then what will happen is the system integrator and support people from vendors and equipment will all leave and you'll be left with a team that hasn't properly taken ownership. They own it, but they don't have the ownership of what's happening to it. As soon as you hit one snag, they won't really be ready to deal with whatever needs to be done, or on the other hand, maybe it isn't properly ready for them to receive. For example, if we are not giving mechanical equipment a proper runoff with the appropriate amount of volume, the appropriate amount of change to it, as far as maybe there's a certain number of different styles of product that are being produced on it, and we're not fully exercising it, then it isn't really ready to be handed off to an end user. Planning for what that handoff looks like and making sure that it is proper for the organization that it's being handed off to is an important part of making sure that the longevity of that automation system is going to be realized.
“Training; both operational and technical. We talked about training earlier as far as making sure that you addressed it. You need to be given the time and also put into practice what is being taught to new personnel because just training alone without any kind of actual work on a machine is not as well ingrained into you. Both operational and technical training is important because you not only have users who will operate the equipment but you also have technical people who will maintain it or program it so you almost have two different perspectives that need to be dealt with. Those points of view can have very differing types of understanding that they need from training. For example, in one of our last projects, we made a custom HMI that was developed for the system that was already running. As part of this, we actually separated our end user's personnel into two groups because operationally there was a lot that needed to be dealt with on the HMI. It was a very robust system with a lot of options and so properly being able to set up that production run for what they needed to do was one whole area that had to be walked through in a lot of detail. On the other hand, from a technical standpoint, because it was a custom interface, we needed to make sure that their programming personnel were able to understand how that works and so that was a completely separate understanding that had to be worked through.
“The end-user support strategy is actually a question that we keep asking earlier and earlier in a project. Very large companies used to make sure that they had every kind of support that they needed in-house as part of their company and then it was a pretty easy question to answer. Now that new technology like robotics and many other areas are being put into smaller companies, it's much more approachable automation. But those companies are not large enough to have all the support that they need in house, as part of their company. They may actually engage third party companies to be their support, or they may want system integrators or other vendors to be engaged as their route that they're going to take when they do need support. We need to understand what their strategy is so we can bring in the right people at the right time, but also to make sure that after install, those agreements are in place so that there's not a gap in having support people ready to call that are familiar with your automation. There's nothing more desperate than someone whose automation has stopped working when production needs to run and they're trying to find a phone number. That should never happen.
“The last element is the 'well-baby' checkup; it's kind of a term that is industry-wide, people are familiar with what you're talking about. The idea is that if everything is good and these first three items here have been taken care of properly, that's really not the end of the project; the end is to come back for a checkup. From a sales standpoint, of course, that makes sense. You want to engage back with your customer and be looking for the what next step. This is also important from the position of a system integrator and who takes care of the equipment very often, because again, there are a lot of very smart people working on these machines and they will be making minor fixes.
“If I don't go back and look at the equipment and understand... Maybe they've been able to take care of several minor issues on their own, but that's not really the goal of trying to get it done, and sometimes those are really band-aids. And so, we go through a 'well-baby' checkup to see how it is really being used now that we've put it in. You know, we had an idea of how it was going to be used, but how is it really being used? Are there things that either need to be tweaked, fixed, or improved now that we see it in action so that we can get the full value again back to those original end goals of the user, so we come back and ask, Has it done what was intended? Has it brought the value that you were looking for?
“So, what's next? What you're trying to get to is: I've reassessed it, and now I have some notes. Let's get the team together again and see where we're at and what is on list that we should address. That's how you get a successful install because that's tying it back in. If you don't keep going through these last steps, you're just kind of launching it over the wall and saying, Hey, it's your turn, you deal with it, but what we really need to do is continue on. The project's not really done until you've gotten to that 'what's next' standpoint.”
Changes Brought About by the Pandemic
Host Rehana Begg asked Kelly, “What should be done with the strategy that was started pre-pandemic? What are the first signs that the digital transformation, the integration needs to be adjusted?”
“I think the honest answer is that we're all still figuring that out,” said Kelly Chalmers. “There are a lot of things that have changed, of course, but also are still changing. I think a lot of our upfront discussion actually does center around the idea of not only trying to look at those things and say, Okay, do we need to adapt here? Do we need to adapt there? This doesn't really work anymore like that. Actually, the bigger question is When or how are we going to assess when we find that next thing? One of the big things that's happening right now is the inability to procure and get materials. It's not just one type of thing that it's affecting so it doesn't really matter if you're trying to find a certain bolt, a certain cable, a certain computer, a certain robot...
“It could be almost anything right now. One of our first, most important questions as we're engaging in these projects, some of which really did start pre-pandemic, is How are we going to maneuver around these things? Because sometimes, we're looking at installations that have constraints on substitutional parts or we have a schedule that just cannot move because there are other things tied to it that are not negotiable. And so, we really need to have an honest look at what constraints are going to be immovable and how are we going to address it when we find them, because we will. That's where we're at right now. And so, just having that part of the discussion and making sure we have those people engaged is really the critical element. AMT does this, but I don't know that all system integrators do.
“We involve our procurement department pretty early on in our process, and it is a very large part of our kickoffs now because it is such a critical element to bring them in as a stakeholder very early in the game and understand how we're going to interact with them, what options we have, or even in some cases, where the end users themselves are perhaps responsible for procuring certain equipment. And if they have difficulties, how will we be able to help them? And that's absolutely been on the table.”
The relationship that gets built between customers and system integrators is critical when embarking on a system integration project. Following these key concepts and procedures ultimately enables project success.
Kelly Chalmers also authored a Control Engineering cover story, “Three Ways to Ensure Collaborative Robot Success” and was featured in Robotics Tomorrow’s “The Benefits of Collaborative Robotics.” Click to download an eBook about selecting a system integrator.