So many decision points lurk in an automation project. The first set of decisions creates ramifications down the complete line of the project. If you are using a system integrator, you still need to decide if you also are using them for IT, or using your own IT department. You and your manufacturing team will still be the driver by putting your business goals first, to be matched by the automation system, which will be served by the IT infrastructure.
Business drives all the other aspects of the project. The reason behind the purchase could be as simple as shaving time and adding a higher hourly rate. It could be that the machine in question is the only one on the market that can do a particular task or tasks. Whatever the case, the bottom line is the key metric here.
The production team must be involved. Their input will provide reality checks along the way. No two ways about it: adding automation will change the workflow, and their unique perspective will be vital in shaping the new way things get done. (Even HR could get involved in transitioning people to a new environment.)
Facilities management also needs a voice. Some popular although sometimes overlooked topics from this team include floor reinforcement, doorway widths, lighting, rack room, and the addition of moving machines (e.g. AGVs or AMRs).
Almost every group in your business must be involved at some point in an automation project.
And now, the data
Your IT team for the automation project, whether they work for you or for an integrator, is well versed in the ones and zeros of getting data from place to place and protecting the areas where data collects. With automated systems comes reporting and data retention—information zipping between machine and controller, controller and server, server and back office.
The promise of good IT planning and implementation is of course to deliver on the old adage, “You can’t manage what you can’t measure,” or more positively, “You can manage what you can measure.” The reason you need this multi-team approach is that the business team is being asked to measure loads more these days. It only takes a few moments of reflection for us to conclude that the data collection and management must itself be automated. This is a good starting point for automation integration.
For the most part, this is done in shop management software, or a machine’s controller software. The automated data collection, more often than not, is already automated for you. The system you purchase uses sensors, counters, cycles, or something to report on jobs. Interruptions to the work are logged and available.
However, while it’s true that data collection is pre-automated in many cases, the sharing of data is definitely not automated. And thus we run across a second foundational precept in successful automation projects: it’s all about the interface.
This is where the Chinese curse, “May you live in interesting times” comes to test you and your system. Sometimes the unfamiliar landscape of industrial computing means outside help is enlisted. Maybe your people have experience in these arcane network and computing underlayments.
Either way, you will be faced with interfaces from current times (which might feel like they’re from the future!) as well as from the past. You will be in a situation familiar to people who create phone systems, physical layer network devices, and software—you must create a solution that is backward compatible. This is a third precept. Of course, all bets are off if you are making a “forklift upgrade” and don’t concern yourself with what has already been collected and what system is set up to continue to collect data in the current status quo.
I dislike the term “scalability” because it is limiting. I would prefer to use “future flexibility.” The world could change in terms of a OS or a networking option we haven’t even dreamed of but a future Zuckerberg or Musk is working on right now. If that happens, we need not scalability but flexibility. And if something is flexible, it is the result of people who build a solution that accommodates an unknown future. As you may have guessed, this is our fourth precept.
A fifth precept is but one word: Test. By creating a pilot program structure, you can safely road test the new environment before going live. It is valuable to take some volunteers to work on the results of IT’s creative process for real road-testing.
The precepts and more
Thus far, we have five precepts:
- Data collection and management must be automated
- It’s all about the interface
- Create a backward-compatible solution
- Create a future-flexible solution
- Test
Assuming we’ve met these criteria, there are other key areas where your IT department is vital:
- Cybersecurity is a must. Perhaps you already work partially or wholly in the cloud, with all your servers hosted elsewhere as well. The brave new world demands brave new solutions to ensure your company’s assets.
- Training, if a new system rolls into changes for users, is essential.
- Troubleshooting and support must be woven into the IT infrastructure.
- Custom work to fill in the gaps—sometimes solutions are not available because of the low market share of a legacy product or some other reason. It’s great when you have an IT team that can sling code to accommodate such circumstances.
- Risk mitigation is not just about cybersecurity but it certainly includes it. We won’t get into other areas here, but it is a key conversation to have with the head of IT.
- A feedback loop should be created to make a place where users can report anomalies, ask questions, or suggest improvements. It would also be helpful to have a monthly IT meeting with a representative for each department to discuss the systems with IT—some people like to enter something on a screen, others like to talk about it. If you rely on one methodology you’ll likely miss something important.
By involving IT early enough and thoroughly enough, you will ease the transition to an automated environment for your entire organization.