Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.
IT Versus OT: Do CIOs Have To Do Both?
Should the chief information officer be on the hook when something goes wrong with the engineering group’s standalone CAD system?
5 Min Read
ElenaBs via Alamy Stock
As more systems move to the enterprise edge and citizen IT grows, independent user departments are developing mini-IT budgets of their own and purchasing their own systems.
In many cases, IT isn’t aware of these purchases, and there are users who feel that IT has no need to know, saying these systems and technologies are operational in nature, designed for the functions of a specific user area, and already supported by outside vendors that can give users the support they would otherwise need from IT.
These user systems are known as OT, or operational technology, because they are intended to meet a specific operational need in the business. They may even do it in “standalone,” non-integrated fashion. They are not intended to be broad-based information repositories for systems that everyone needs, and that require IT involvement.
Examples of OT systems in business are medical diagnostics systems that physicians use, MRI machines that radiologists use, robotic surgery arms used by surgeons, industrial automation in manufacturing, automated forklifts that warehouses use, and turnkey engineering 3D product design systems for engineers.
The divide between OT and IT systems can be difficult for CIOs to navigate because of fights over who is the decision maker and owner of which technologies.
From experience, I can remember the painstaking effort involved in integrating a standalone engineering CAD OT system with other downstream systems in manufacturing. The company found itself having to maintain multiple parts and product configuration databases, with manufacturing and engineering often working from different product revision levels. In some cases, this resulted in obsolete or incorrect product components that either failed manufacturing’s quality assurance (QA) checkouts or caused issues for customers.
Everyone knew about these product “disconnects,” and they understood that some kind of integration between engineering and manufacturing systems was needed. There was also consensus that any systems integration required IT’s involvement. Despite this, there was pushback from engineering. “We run and maintain our own system,” they said, “Why would we need IT when we have skilled software engineers of our own who can surpass the skill levels that you have in IT?”
Engineering, indeed, had specialized software engineering skills that IT didn’t have. Yet, as the product “disconnects” made their way to the bottom lines of our corporate profit and loss statements, the issue of engineering and manufacturing systems not working well together gained the attention of the board and the CEO. These executives wanted system integration that would fix the problem, and they expected IT to provide it, which we ultimately did.
OT/IT dialogues and debates like this continue today, and CIOs need to be aware of them.
Many already are aware, and from their experiences, here are some the OT/IT lessons that are beginning to emerge:
Stay in touch with your users! Don’t bury your head in the sand when a user talks about a new standalone analytics system, an automated assembly line or a new CT Scan machine. No matter how autonomous vendors and users claim the new technology to be, OT will ultimately turn into IT. Why? Because sooner or later, IT will be called to integrate these systems, and that’s when both OT and IT become the IT team’s issues.
Early on, it’s sound practice to know which new OT systems that users are contemplating. This is so IT can check the application programming interfaces APIs) and other types of connectivity options that come with the OT technology. The same goes for security and governance. Will the new OT technology (and its vendor) meet enterprise requirements? Most users will welcome an advance IT review of such issues, because the users themselves won’t know much about them. More importantly, upper management and the board will want such a review, because OT technology is expensive and they don’t want to find that they have invested in tech that can’t “talk” to other tech, or that has lax or non-existent security.
Don’t lose your cool when a user tells you they purchased some new OT and they now want to integrate it with other corporate systems, and you had no “heads up” on this. A few CIOs have told me that the initial response they are tempted to say is, “Well, you never told me about this new OT so I can’t guarantee that it will work well with other systems. It’s your problem!” From the gut, this is a natural reaction, but it’s not advisable when your job is to make technology work for the overall benefit of the company. Still, it’s fair to advise users and upper management of any system integration challenges you foresee.
Where We Go From Here With OT/IT
As more automation and edge technology is deployed at remote locations, the lines between OT and IT will continue to blur. Companies are already seeing this, and many have seized upon new ways for IT and end users to do more upfront collaborating and planning.
On the operations side, users can see the possibilities for bringing data from more systems into their operations so they can do their jobs better, and they can appreciate what IT can deliver. On the IT side, IT can gain a better understanding of how the end business and its OT works, which puts IT in a better position to deliver “spot on” technology that solves tough business issues.
The OT/IT divide has the potential to be a “coming together” for everyone, and it’s likely that CIOs will have a central role in shaping it.
About the Author
You May Also Like
More Insights
