Custom automation vs. commercial-off-the-shelf, or both?
How to automate is as important as when. Custom is not a four-letter word. Weigh the benefits of COTS and a custom solution, rather than restricting an automation project view to a COTS or custom solution. Don’t assume that custom solutions are bad. See graphics that illustrate.
Over the past decade, the system integration business has been pushed toward a “common everything” approach. Customers are searching for a one-size-fits-all solution that is easy: easy to buy, install, and maintain. Common-off-the-shelf or commercial-off-the-shelf (COTS) products have perpetuated the idea of one solution to meet all needs. COTS offers a one-line item purchase that promises to easily meet all the features a customer wants.
Unfortunately, this promise cannot be fulfilled by a “common everything” approach or by COTS alone. Except for simple system integration projects, this method is often not feasible and can lead to poor decision making for the sake of commonality. Typically, lack of understanding surrounding a successful system integration project is what leads to these decisions.
As a result, the word “custom” has developed a bad reputation in the industry. Customers steer away from anything custom for a variety of reasons—many of which are unfounded. This article examines these reasons, attempts to show that all system integration projects require some level of customization, and that custom products and efforts are a necessary option for success.
How did we get here?
Looking at the recent history of industrial automation, the current commonality trend can be viewed as a response to past market conditions. The 1980s and 1990s were filled with proprietary software and hardware that forced customers to make decisions with no recourse. Customers had to choose a particular platform and stick with it, because there was no interoperability between competitors. If the feature you wanted was not provided on the product line you chose, you were out of luck. And it was too expensive to change to a competitor’s product because the foundational infrastructure was already in place and was not compatible with a different platform.
These conditions led to a backlash from customers that changed how the industry would go to market. Customers required interoperability among competitors’ products. Product vendors established and adopted common, open protocols to support this effort. In the late 1990s, the development of OPC (object linking and embedding for process control) created a relatively inexpensive option to allow communication between or among proprietary systems.
Customers could now choose the right product for the job and be assured that the new product could communicate with the rest of the infrastructure as well as any prior investments. Unfortunately, this openness led to unwanted and unanticipated side effects.
First, customers could choose any product that met their needs. So they did. Now one facility may have a dozen or more product platforms that required support using different tools. This placed an unusually high burden on operations and maintenance departments.
The most successful system integration projects use both COTS and custom approaches to best fit the customer’s immediate needs and future requirements.
Second, anyone could write their own software to communicate with any process control product. So they did. Customers began to develop software internally or purchase software from unqualified developers that could not be supported or maintained.
Around 2005, the pendulum began to swing back in the other direction. Customers corrected these failings by staying with one platform that could be maintained by internal staff and only purchasing COTS products that worked on that platform. Customers began to do this regardless of whether the products could meet functional needs of the related applications. It was more important to maintain the “common everything” vision for sustainability.
On the next page, learn more about "custom" misconceptions and see two graphic examples
Case Study Database
Get more exposure for your case study by uploading it to the Plant Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.
2012 Salary Survey
In a year when manufacturing continued to lead the economic rebound, it makes sense that plant manager bonuses rebounded. Plant Engineering’s annual Salary Survey shows both wages and bonuses rose in 2012 after a retreat the year before.
Average salary across all job titles for plant floor management rose 3.5% to $95,446, and bonus compensation jumped to $15,162, a 4.2% increase from the 2010 level and double the 2011 total, which showed a sharp drop in bonus.