Far too often, the final bill for software implementations can seem like a bit of voodoo to the uninitiated. It just seems counterintuitive that software can cost more than the hardware—and that the implementation of enterprise management systems can easily cost several times more than the software itself.
“Yet, this has been the case for 15-20 years,” observes Marc Leroux, chief technology evangelist for collaborative production management at automation vendor ABB Inc. (www.abb.com) “Today, everything is becoming ‘smart,’ and software is becoming the differentiator among vendors.” He is not alone in making this observation.
“To a large degree, hardware has become a commodity,” says Jack Gregg, director of Experion product marketing for Honeywell Process Solutions (www.honeywellprocess.com). “Standardization has driven us to solve problems with software as opposed to hardware.” Today, therefore, the real intellectual property or brain trust in the automation world tends to be in the software.
"The cost of this brain trust includes more than just the control software and the other packages that sit on top of it to monitor, manage and optimize the system. It also includes the cost of configuring the software upon installation to fit it to the particular manufacturing process. “Users must consider this cost, whether they hire someone else to do it or they do it themselves,” says Gregg.
Not only does this software need to be installed and configured to the particular manufacturing process and its controls, but it also sometimes needs to be customized. “Depending on the system’s complexity, the cost of customizing software can easily exceed the initial cost of the software,” notes Leroux.
Even after the initial implementation, the spending does not stop. Software requires a continuing investment to maintain it through periodic upgrades from the developer and any changes to the manufacturing process itself over time. “With any change, there is a risk that something could break or disrupt the integration,” explains Gregg. “So, every time you update a control system, application or configuration, you have to consider how it could propagate through the system.” Users, therefore, must include regression tests and other forms of maintenance in their budgets to ensure that the system remains integrated and up to date.
Because of these continuing costs, Gregg joins his counterparts at other automation vendors in urging users to look beyond the initial configuration and testing of the software. “There is a total lifecycle cost,” he says.
Quantify engineering effort
Calculating lifecycle cost begins with determining the cost of implementation, which varies with the amount of engineering services that you need to get it up and running. If, on one hand, the software simply needs loading, some configuring, and perhaps installing some hardware, these services could cost between 20 and 100 percent of the software itself, according to Mark Carrigan, vice president of business lines at alarm management software vendor PAS Inc. (www.pas.com) On the other hand, such services can cost as much as five times more than the software on larger, more complex projects that require modifying the software, reengineering work processes, or both.
For examples of both ends of this cost spectrum, consider the alarm management systems offered by PAS. At the low end, some manufacturing plants want the software simply as an engine for tracking key performance indicators (KPIs). “If that’s all they want, the cost to install the software, get it up and running, and train people how to use it is usually around 50 percent of the software price,” says Carrigan.
At the high end of the cost spectrum, other users ask PAS to undertake an alarm-management improvement project that involves an alarm-rationalization study. “Services for these projects are typically four or five times more than the software itself,” says Carrigan.
For a recent job, PAS’s engineering staff conducted an initial study into the management of alarms and controls at an oil refinery. “By examining the plant’s operational history and incident reports over the last two years, we identified approximately $8 million a year of lost production from deficiencies in work processes,” says Carrigan. These losses accumulated from such things as damage to equipment and inefficiencies in shutdowns and other procedures.
Based on this study, PAS drafted a $1 million proposal for correcting the deficiencies. The proposal included both an implementation schedule and the price of the software and consulting services from PAS. Because the price tag did not include the projected investment of time from the plant’s employees, the proposal also included a separate table detailing the hours that would be needed from operations, engineering and other personnel. “They could then apply their internal rates on top of that to get a total cost,” explains Carrigan.
He notes that users often neglect to budget adequately for the time that their own people will spend on the project. He urges users to calculate these costs at the beginning so they can understand the true cost and allocate the necessary resources.
Look at lifecycle cost
Because the purchase price of the initial software is but one factor, and sometimes a relatively small one, vendors constantly urge users to consider its overall cost over its entire lifecycle. “We tend to fixate on the initial price,” notes Simon Hogg, senior product manager for platform software at National Instruments Corp. (www.ni.com) “However, this cost tends to be over-considered, possibly because it’s the easiest to measure and compare.
“Any informed decision needs an evaluation of the costs to acquire, learn, use and maintain one software tool over another rather than just comparing purchase prices.” To calculate a true cost, he suggests using an equation that expresses total cost as the sum of the initial purchase price, implementation cost, training cost, maintenance expense, opportunity cost, and risk. This equation applies to any software project, whether it involves installing a commercial application or developing your own with development tools.
Because developing software in-house is not always the cheaper way to go, Hogg urges users to weigh the opportunity costs before making this decision. “It’s easy to focus on the sticker price of acquiring software without taking into consideration how much is spent in salary and lost productivity creating an in-house solution,” he says. “Ultimately, when the cost of developing a solution in-house outweighs the cost of acquiring a solution, it makes sense to acquire it.”
Developing software in-house also carries its own risks. For example, a task projected to take a week may wind up taking a few months. “Sometimes, the task may be more complex than anticipated, or other times, a star performer may get sick or leave the
company,” says Hogg.
I/O points drive cost
Because the number of discrete and analog I/O points is the dominant cost variable in most software projects, it winds up being a good metric for forecasting cost. In fact, many system integrators quote jobs by multiplying this number by their hourly rate and the estimated number of hours that they expect to spend on the average I/O point.
Experienced integrators typically have a sound historical basis for their time estimates. “Our company uses an ERP [enterprise resource planning] system to log all of our labor and material costs,” explains Ben Durbin, president of Cybertrol Engineering LLC, a Minneapolis-based integrator of Rockwell Automation software (www.rockwellautomation.com). “Because the system has an open database, we were able to develop many levels of reports for analyzing our performance on different kinds of jobs.”
Besides using their historical cost data, he and his colleagues also refine their estimates by dividing a project into five stages of a software development lifecycle (SDLC) model. The first stage defines the project, an activity that generates a document called a user requirements specification, which quantifies such things as production volumes and quality parameters. Because the user usually provides these specifications, integrators typically bill very little time for this stage.
Integrators typically do most of the work at the next stage of developing a functional requirement specification, a document that details the functions of each unit and control module. “A user requirements specification may say to run at 500,000 pounds an hour,” says Durbin. “We break that down in the detailed functional specification, putting all of the I/O points for every control sequence into a table and defining each state and alarm.” The work involves interviewing all parties to the project—from process design through maintenance.
The third stage in the lifecycle model is writing the code. “We require that a functional requirement specification be written before any programming starts on a project,” says Durbin. Because this document removes any guesswork and assumptions on how the user might want to run the equipment, it makes the programming task much more straightforward and efficient.
The fourth stage in the model is factory acceptance testing or simulation. Here, Cybertrol’s engineers simulate the system in an office environment to test each function. “Acceptance testing involves the relevant parties at the end user and the various engineering firms that were involved in the process or equipment design,” says Durbin.
Although the actual engineering times in these stages vary considerably by job type and size, Durbin estimates the average time at 3.5 hours for jobs with 150-200 I/O points. For jobs of this size, generating the functional requirement specifications generally takes about one hour per point. It takes about two hours per point for writing code for the controllers and HMIs and doing the internal testing. Factory acceptance testing might take a half hour per I/O point. Assuming a rate of $125 per hour, the cost for the engineering services before commissioning, therefore, is around $440 per point.
Durbin has no rule of thumb for the final stage, the commissioning of a project. “It boils down to the customer’s ability to plan, manage and staff the construction phase,” he explains. All too often, construction falls behind schedule, and the window for commissioning becomes narrower to compensate for the delay. Near the end of a project, therefore, users often ask their contractors to be onsite 24/7 to be ready to check out equipment. For this reason, Durbin rates commissioning as the most underestimated cost component for software projects.
Remember training and risk
Vendors report that other costs commonly underestimated by users are training, maintenance costs and risk. “Training, particularly on new technology, may require significant time after implementation for people to reach a state where they are fully productive,” says ABB’s Leroux. He compares the process to learning to use a new application on a smartphone.
“Apps are supposed to be easy enough to use without documentation, but it takes a while to get used to a new one,” Leroux says. For a similar reason, he recommends investing time in developing a training plan for any new software. Besides the initial training session, the plan should also include on-the-job resources and refreshers once people get their feet wet, so to speak, with the software.
Maintenance is another category of cost often neglected in the initial lifecycle calculations. These costs go beyond the recurring license and contract fees. “While software won’t actually rust or wear out, it still requires maintenance to continue working as desired,” notes National Instruments’ Hogg. For example, someone needs to keep the software up to date.
Another example is the need to keep a distributed control system (DCS) synchronized with a historian. “Last year, I asked a few users how much effort it took to make sure that their DCSs and third-party historians were in sync,” reports Leroux at ABB. “The answers ranged from a quarter person to a full person. One customer just laughed, saying, ‘They haven’t been in sync since the day they were started.’”
Besides underestimating maintenance, users also frequently neglect risk management, probably because they lack concrete cost data. Leroux, however, urges users to plan for unexpected contingencies that may affect the business. “This can involve significant disruptions to workflows or production systems,” he says.
