The post How to Achieve More Value from Your Automation Projects first appeared on the ISA Interchange blog site.
The industrial automation industry is largely a project-centric business. Over the past three decades automation suppliers, system integrators, engineering procurement contractors, and industrial automation users have become extremely proficient at executing automation projects.
Unfortunately, in numerous interviews in which I have participated with industrial company executives, many indicated that although they believe automation should add business value to their operations, they are not convinced that it really does. Many of these executives have commented that they see huge return-on-investment (ROI) projections for automation projects before selecting and executing the projects, but seldom see any actual ROI data upon completion. As a result, they have become skeptical about the value of automation projects, and in some cases are actually redirecting available capital to other areas.
This skepticism has been a reality for many years. Perhaps the best proof of this is the continual price pressure in the automation marketplace, which has made automation technologies commodity products. This degree of commoditization would not have been as significant if executives truly believed automation projects delivered high levels of business value.
Most automation professionals I have talked to are convinced that automation technologies, effectively applied, can add significant business value. But that does not seem to be the prevailing perspective of executives. It is critically important to the success of industrial automation projects that the business value of automation solutions is made clear and discernable and that automation investments are made in the areas of greatest potential value improvements. Driving this transition requires identifying and overcoming the barriers to measurable business value improvement.
There are three critical barriers to realizing the potential business value generation from automation projects:
All three of these barriers are based on traditional business processes associated with selecting and executing automation projects. Fairly minor modifications to these traditional business processes will cause greater discernable value from automation. This should help change the prevailing executive perspectives that automation projects do not produce value.
There are two basic classes of automation projects: greenfield and brownfield. Greenfield projects are projects in new plants involving new automation systems. The installation and startup of the automation systems are often on the critical path of greenfield projects. Therefore the primary objective for greenfield projects is getting the automation systems installed and running correctly in the necessary time frame to get the plant running on schedule. As a result, the business value perspective proposition for automation systems in greenfield operations is essentially viewed as an enabler to getting the plant producing and delivering profits. During the 1970s when a large percentage of the automation projects were greenfield, there was very little question about the value of automation.
Brownfield projects, on the other hand, are projects in existing operations. They typically involve the installation of new automation technologies to upgrade or replace existing automation systems. Over the past decade, the vast quantity of automation projects have been brownfield projects. As a result, the impressions of executives regarding automation projects have been highly affected by brownfield projects.
Unfortunately, the commonly accepted capital budget processes associated with the application, selection, and execution of brownfield projects have severely limited the actual value of automation projects. One reason for this is a phenomenon called “replacement automation.” Many brownfield automation project opportunities are first identified by plant engineering and operations teams motivated by an installed automation solution that is aging, with an increasing frequency of failures and difficult-to-procure spare parts. Team members decide to request capital to replace the aging system. To develop the request, they need some idea of the cost of replacing the system, so they develop an initial specification for the new system. They technically define the exact system that is already installed and to be replaced. This specification is sent to a few suppliers to establish an estimated replacement cost, and this is the cost that is typically used to request capital funding. This means that the initial project specification is for the exact functionality of the system being replaced, and the amount requested is what it costs to execute a project for that exact functional replacement.
To secure capital funding, the plant engineering and operational team estimates the value the new automation system will provide, typically in the form of an estimated ROI. Because the new system is a functional replacement of the existing system, the only real data the team has is spare parts and maintenance cost savings data, which is seldom enough to justify the required level of ROI to get a capital project approved. Therefore the team estimates the ROI based on what it determines to be the threshold level for project approvals for the company. The good news is that the actual ROI is seldom calculated after project execution, so whatever ROI they estimate is pretty safe for the team.
If the capital project is approved, the specification and the project budget given to the project team is for an exact replacement of the installed system. Even though the new system may have many additional features and functions that could add value the old system did not have, those features and functions are typically not included in the project scope. This is because the plant engineering and operations team was likely not aware of the available capabilities when it initiated the project. As a result, the cost to implement those features and functions was not included in the project costs. Therefore the project is typically for an exact functional replacement of an existing system. Unfortunately, replacing old technology with new technology performing the exact same functions seldom has significant incremental value.
The “replacement automation” approach produces a number of projects that may be well implemented, but provide little incremental business value. This means that for many automation projects the executive perspective that automation projects do not add much value is correct. It is important to point out that this does not mean that the new automation systems cannot provide significant value improvement—they often can. But realizing the incremental business value improvement depends on using some of the new capabilities not available or not utilized in the installed systems, and the project budget does not support that work.
It is interesting that project teams are often in the position of selecting, or at least influencing, the selection of the automation system. This may result in automation selection criteria heavily weighted on “ease of use.” That is, the project teams put heavy emphasis on selecting technologies that make on-time, on-budget project delivery more likely. Ease of use can be attained in a number of ways, including reducing the functionality of the system. Reduced functionality may imply less capability to drive performance improvements. This is not to say that automation systems should not be easy to use—they certainly should be as easy to implement and use as possible. But reducing value-adding functionality to attain ease of use may not be the best trade-off for long-term performance.
In discussions with project team members on the topic of unused functionality that may drive significant business value improvements, many expressed frustration that they could not take advantage of the functionality during the project. But they also indicated that they were optimistic that this incremental, unutilized functionality might be used later, after the project was complete and the system started up. In my experience, very little, if any, of this incremental functionality is ever implemented. Plant engineering teams lack expertise, and plant engineers have high activity levels, leaving no time to work on these potentially beneficial opportunities. The result is that the utilized functionality of automation systems changes very little over the system’s life cycle, and the potential incremental business value improvements are not realized.
One potential solution to the replacement automation challenge is adding a key project team performance measure on the incremental business value provided by the automation solution. This sounds like a simple fix to this issue, but it really is not simple at all. It requires rethinking the entire project cycle. Project team members might need an opportunity to influence the specification to drive value-adding functionality before project costs and schedules are nailed down. Time needs to be allocated to project cycles so project teams can add value in this way. Project managers need new mechanisms to manage scope creep effectively while allowing appropriate, value-adding functional enhancements. Changes to current processes are required, but the increased returns from the automation investment should be great enough to make the changes very worthwhile.
Although the replacement automation approach results in project specifications that add little or no value, there is often a high level of talent on project teams. It might be expected that the project teams could use this talent to add incremental value. Unfortunately this is seldom, if ever, the case. The problem is not the talent level on project teams, but how the performance of project teams is measured.
In most industrial organizations, the primary performance measures of project teams are on-time and on-budget delivery of the projects. Notice that the actual incremental business value delivered by the project is typically not a key measure of project team performance. In fact, in many of the projects I have been involved with over the past three decades, it is not a project team performance measure at all. Project budgets and project schedules are set up to align with the project delivery according to the scope defined in the project specification. Therefore the time and cost allocated to the project team are set up to deliver the project as specified and nothing more. Because project team managers are extremely cognizant of their performance measures, they tend to carefully manage the projects to ensure there is no scope creep that might negatively affect schedule or cost. This means that the functionality in the project specifications, which is often defined on a replacement automation basis, is exactly what is delivered by project teams. Unfortunately this leads to automation projects that provide little or no incremental business value.
Click here to continue reading Peter Martin’s article at InTech magazine.
About the Author
Source: ISA News
