Is it time to consider a new IT specialty like automation engineering?
Jobs site Indeed defines an automation engineer as someone who will “search for ways to simplify activities for employees, consumers and companies by automating specific systems and manufacturing processes, like store checkouts or assembly lines”. These individuals work alongside IT and department managers to develop automation plans and then implement automation into business processes.
They use programming languages like Java, C# and Python, and they know how to work with machine actuators and sensors. Most importantly, they possess expertise in the application areas they are asked to automate. In other words, a retail automation expert might have skills in how to automate grocery checkout lines in stores, but they might not know much about how to automate a manufacturing company’s assembly line.
In the area of robotics, many of the skills needed for automation engineers carry over for robotics engineers. A primary difference is that a robotics engineer is working on a robot. The goal is to program the robot with the necessary instructions for it to fit into an existing business process.
Examples of how working robots are used include programming a robot so it can enter a nuclear facility to perform maintenance, or activating a warehouse robot that can store, pick, and deliver parts from bins throughout the warehouse while successfully navigating around obstacles on the floor.
Robotics engineers use languages like C and C# and they commonly work on Linux platforms and must be familiar with the technologies of the particular robotics vendors they are using.
Automation and robotics engineers are in high demand in business, although it costs considerably more to recruit an automation engineer (mid-100,000s salary range) than it is to hire a robotics engineer (the mid-point salary is around $80,000/year).
Where Do These Engineers Report?
Robotics and automation engineers must have the ability to cross-communicate with different departments when they implement solutions. They also need a thorough understanding of the different enterprise systems where the automation or robotics technologies will be deployed. It’s not much of a stretch to see that many of the system knowledge and cross-communicational requirements are exactly what one would find resident with an IT business analyst. The difference is that an automation or robotics engineer would have greater skills in programming, and in working with various mechanical and electronic interfaces.
As a CIO, I once had a project that required automation between our engineering CAD design database and the parts inventory, bill of material and work order systems on the manufacturing floor. There were too may disconnects between engineering and manufacturing. We wanted to eliminate this by integrating and automating information flows between the CAD system and the manufacturing systems.
Engineering was running a standalone CAD system on an entirely different platform from what manufacturing was using to run its bills of material, inventory, and work orders.
The initial decision was for IT to take the lead in this integration-automation project because IT touched all systems (except for engineering’s standalone CAD system). However, we found out quickly that engineering didn’t want to relinquish any control of its CAD systems for the automation project.
We solved this by teaming an engineer from engineering with a programmer-analyst from IT and a manufacturing engineer from, and we got the project done. It wasn’t the easiest project that we ever did.
Can IT Avoid Getting Involved?
That project with engineering, manufacturing and IT came early in my CIO career, and I learned quickly that automation projects have many different pieces, engage many different departments, and can quickly become as politically charged as they are technically challenging.
I’ve talked to several other CIOs about how to get past politics. Some are more than happy to just have the departments that want to automate retain their own consultants or hire in the people — and do the work themselves — but I’ve seldom seen this work. Why? Because invariably, the consultant or the engineer that a department brings in has a question about how to integrate with other enterprise systems that IT manages.
One way or another, IT will be involved.
Is There a Best Approach?
From personal experience and from conversations I’ve had with other managers, an optimal approach to automation and robotics when IT works with engineering-oriented departments such as manufacturing, is to place the automation or robotics engineer in the engineering or manufacturing areas. Then the engineers can be savvy on the departments’ business processes as well as on the automation and robotics technologies that are needed. In this scenario, IT would be assisting primarily in system integration.
However, if the company is in finance, healthcare, retail, or other non-engineering-oriented businesses, it’s likely that IT might be the best destination for a robotics or automation engineer, because the user departments won’t have the necessary skillset.
In all cases, automation and robotics projects require strong collaboration and cooperation between departments and IT. In this way, everyone can be assured that they are moving into each project with a complete and comprehensive knowledge base of the business, the systems, and what they want to automate.