Is Your System Maintainable?

Don’t waste your money on a system integrator (SI) who leaves an undecipherable system when they finish. Learn steps your SI should take for a smooth transfer of information, so your team can utilize the new process right away—without information gaps.

Image001

How much do you depend on integrators to keep your system running as it should? Can you easily troubleshoot problems on your own? Is everyone in your plant up to speed with what the integrator provided and how it works? If you find yourself lost without your integrator, you may not have a maintainable system.

What does it mean to have a maintainable system?

  1. A well-documented system with code that makes sense. We, at Glenmount Global, provide a well-documented system with code that makes sense. For example, the client could have a shear subroutine within the program and there would be a label for that shear. In addition, all its code would reside within. So, if a change needs to be made, they can go right to that spot in the code without having to go in line by line to find where to make modifications. We can build a program that has cryptic names for all the components in the software and know how it works, but if we handed that to someone else in the plant who has never seen the software, they would have a hard time figuring it out. Integrators must segregate those functions within the code to provide ease of access for those who did not write it. Imagine having to browse through thousands of lines of code and find what you are looking for while the plant is in the middle of a breakdown!
  2. Good documentation, drawings, and functional descriptions. Most of the time, we are replacing obsolete systems with documentation that is not well-written or well commented. For someone who does not do what we do every day, it is a tremendous effort to figure out how those old systems work when there is a problem. There are times when we walk into a facility and they do not have a functional description or drawings for their process—so, we have no starting point. We must write our own documentation, stepping through how the line operates and collaborating with the personnel. At times it is even necessary to chase wires hand by hand to figure out how the existing control system works. This can add hundreds of hours on to a project schedule, depending on the system.
  3. Clean graphical user interfaces. If you do not put your interface together in a clear manner, it is tough for folks to understand. You must design an interface with the end user in mind. We must account for the operator on the floor, the engineer, and management when we put these interface packages together, because it is important that all the stakeholders can see and interact with the system. This principle should be applied for something as small as a narrowly focused piece of equipment to something as large as a complete process line with hundreds of motors. Our systems can get very complex and making sure the interfaces are intuitive at all levels is critical.
  4. Stakeholders were involved during development. Bring in operators, the engineering team, and managers, letting them get their hands on the solution before it is installed on site. The feedback provided and buy-in from plant floor operators during acceptance testing is invaluable insight prior to installation of a system. Overall, during the project, it is important that the engineering and maintenance teams are both involved. We like to encourage the technical representatives of the customer to be a part of our team. Their input can have a big influence on what we do and will also allow them to understand it before it hits the shop floor. Being engaged well ahead of the FAT is a key component of a process for a maintainable system.
Companies in this article
More in Plant Maintenance