Bridging the Gap Between IT & Maintenance/Operations

There are many silos and points of contention in this world. Some have very serious consequences. Some are just annoying. One can easily make a long list of opposite sides that we allow to impact our daily lives. Red vs. Blue. Arizona State vs. University of Arizona. My Book, your Book. Blah, blah, blah. Maybe we all need a sense of belonging to a team. Once joined it is now easy to identify anyone who is not on our team as the adversary. Settled science it would seem.

Ripping off the bandage

Let’s face it: The relationship between IT; the folks who deliver the technology we need to get our jobs done, and Maintenance/Operations; the folks out in the field getting dirty, is rarely a happy one. There is a natural tension between these two groups, mainly due to their completely different mission statements and goals. How can two groups of anything move in the same direction if their goals are different?

There are few things more frustrating when a tool you are relying on to get a job done is not working. Dead batteries, put away broken, out for repair, etc. can drive your field crews crazy. They know how to use the tools, but they are either unavailable or perhaps not meeting their current needs. Software, the main deliverable our IT teams provide, is just another tool in the toolbox for Maintenance/Operations.

Kumbaya – or not

Here is the problem to solve:

“I need this function in order to accomplish my goals and you are going to make it happen for me.”

“I spy with my little eye…”

Not the best way to start.

IT is the constant receiver of requests by non-IT/non-software tech-savvy employees who are trying to get things out of whatever software product. (Don’t get us wrong here… Maintenance/Operations has its own technical basis, just not always using the same language as IT.)

“Do this… Make it look like… Force it to do… Why can’t it…, etc.”

Multiple business units may be asking for what appears to be the same thing. What can help IT understand varied requirements? Some user communities don’t care how something functions behind the scenes, they just want the output to be X. Functional areas embark on business optimization or improvement projects, leaving IT out until the end when they stand at the door with a long list of software changes.

Keep in mind that IT typically has its own self-sourced projects. They might be staring a significant upgrade in the face that will absorb weeks of planning and several weekends. Maybe there is a nagging security problem that must be stamped out quickly. Maybe they failed an audit and need to remedy the findings in a few short weeks. IT is not just sitting around watching the green lights blink. (Although doing that in front of racks of servers can be quite therapeutic!)

The challenge is for these two groups to communicate with each other to gain full understanding of the purpose, scope, and expected timeframe of the project, no matter how big or small.

You mean I must spend time with, “them?”

Ding, ding, ding… We have a winner!

Let’s say the company’s business side has decided to implement an integrated Inventory software solution that will replace several stand-alone systems yet communicate with existing systems to pass data back and forth.

Big project for sure.

In the end, no matter what the solution looks like, IT will be the folks wringing their hands over whether the systems are up and serving the user communities. After all the consultants have exited the building leaving their trail of sticky notes and invoices, IT will be the ones remaining to feed not only the solution itself, but also the user communities as they evolve in their use of the toolset.

As the project team is formed, the second set of participants to include are representatives from IT. You would be shocked at how important it is to have IT involved early in the project! Have them involved in all demonstrations performed by vendors. Their questions can quickly eliminate some solutions because of the potential IT overhead or their cutting across the grain of established IT policies. IT folks have a knack for cutting through the Sales… er, noise.

IT must also be part of the project’s requirements gathering and/or process improvement activities. True, they might not know a single thing about the business process in question, but they have deep knowledge as to how to implement any process into the software suite. They might not know what the data being discussed means, but they have intimate knowledge of where that data is stored and its various formats.

Happy dance! Project complete-ish!

So, your big happy family spent 6-9 months implementing your EAM system. Things are running swell out in the cloud and Users are enjoying their new mobile apps on fancy tablets. Look how cute the data streaming in from the field is! Life is good.

Umm… you’ve only just begun.

Let’s assume that because of this project you initiated a “User Group,” or governing body of some kind surrounding the businesses’ use of whatever EAM tool you implemented. Of course, IT plays a big role in this team. Further, let’s assume you have created a Change Management approach as to how further changes (no matter how small) to the system are identified, rationalized, prioritized, tested, and then pushed into production.

These two elements: an active and productive governing body, and an effective change management approach bring together the technical and the business sides. It is here where everyone gains clear understanding of the goals and challenges of their workmates from across the divide.

Come together. Stay together. The future is always better.

Where to begin?

Start with the boss. You will need to start with multiple bosses. Projects of this sort will require leadership at many levels. Someone will need to be the Sponsor. Others will need to lead within their own disciplines, all the while working across the divide to accomplish the goals of the project.

Find a source of the tools you need who understands these crucial relationships between the business and the technical side. Yes, Programs (software) are important, but so too are the People expected to use them and the Processes that they reflect. Best you find a company who understands all of these vs. just one element. Bring them into your team as a long-term member.

We believe the blending of TRM and IDCON is that mix you need. Make contact to see how we can help you bring the many into one.

John Q. Todd, Sr. Business Consultant / Product Researcher at TRM. Reach out to us at AskTRM@trmnet.com if you have any questions or would like to discuss deploying MAS 8 or Maximo AAM for condition-based maintenance/monitoring.