Automation of processes can provide great benefits including improved quality, improved throughput, more consistency, more available production data, notifications of significant events and reduced costs. However, automation can also be expensive, overwhelm your workforce, cause future integration problems and magnify issues that you are currently experiencing. After all, if a machine can do work 100 times faster than a human, it can also produce problems 100 times faster than a human. Whether it is a benefit or a scourge depends largely on the implementation process.

There are thousands of possible technology solutions for just about any production problem. The trick to getting results that will work for your company is to use good engineering practices starting from the beginning. Good engineering practices are documented in various publications including ISPE Baseline Guides, but there are common threads among all such guides. What will the system be used for and what problem is it intended to solve?

The key is implementing a system that is fit for your intended use. As obvious as it sounds, this is often the most overlooked challenge of the process. In the grand scheme of things, it is a MUCH better proposition to spend more time planning and have a smooth operation than implement a system quickly and fight it because it isn’t a good fit for the intended use. The industry is littered with systems that were prematurely implemented and complicate rather than simplify operations. Planning is cheap, but fixing is expensive.

The most important step to getting an automated system that will work for you is also the first:

Defining “what” you need the system to do: User Requirements

With decades of experience in the automation industry, I have seen systems in many industries and applications and it is universally true that the definition of requirements is key to the success of the automation adventure. To clarify, the user requirements are intended to define “what” the system is required to do, rather than “how” it will do it. This means that persons that may not be familiar with the automation technologies can still be (and usually are) among the most important contributors to the user requirements document. Often, the people most familiar with the task that you wish to automate can contribute the most to the User Requirements document.

Some of the components of a User Requirements document typically include:

• Purpose: What will the system be used for and what problem is it intended to solve?
• Users: Who will be the users of the system and what is their relevant experience?
• Integration: Is the system required to integrate into any existing or anticipated systems?
• Regulatory Requirements: Is the system required to meet any regulatory requirements?
• Functions: What is the system required to do? This may include operating ranges, operator interface information, records generation and storage, security, etc.
• Performance: How many units per hour are required to process?  What percent non-conforming product is acceptable?
• Environment: What environment is the system required to operate in? Indoor, outdoor, flammable, etc.
• Documentation: What documentation is required with the system to support ongoing maintenance, calibration, etc.?
• Warranties/Support: Will you perform work in-house, or will the manufacturer support the system?

The level of detail in the User Requirements should be scaled to the intended use. More critical operations may require more detailed and formal User Requirements. At a minimum, the User Requirements could be a punch list of items, but a detailed User Requirements may fill binders. The important thing is that you have one, and that the stakeholders in the operation have been involved in its production and approval.Once completed, the User Requirements can be a very good document to have for prospective providers of solutions to focus their attention on what is important to you, the customer.

Equally important to the process is the idea of not over-constraining the potential solutions by including “how” the system will meet the requirements within the User Requirements. If it is required to use specific technologies for integration with other existing systems, it is appropriate to include that information in the User Requirements. However, if use of a particular technology (e.g. “wireless”) is not required, the inclusion may unnecessarily eliminate viable design options for systems that may address the requirements.

Once completed, the User Requirements can be a very good document to have for prospective providers of solutions to focus their attention on what is important to you, the customer. This helps to ensure that they focus their efforts in the areas that match your needs and they don’t waste resources (which translate to your costs) in areas that don’t have tangible benefits to you, the customer. It also gives you a great tool to “value engineer”, meaning that you can consider cutting design options that do not support the User Requirements, which can reduce project costs and timelines, keeping things lean and on track.

Further steps in the project are built around the User Requirements including system specifications provided by vendors, testing documentation and the overall turnover package. An appropriately scaled User Requirements document is a low cost, easy way to ensure that your automated system will serve you well for years to come. Alternatively, the lack of a User Requirements document is an all-too-common indicator that there may be challenges ahead including scope creep, missed deadlines and unacceptable long term performance.

Feel free to reach Vince at vjs@sebaldconsulting.com with any questions you might have.