In addition, several other factors affect implementation cost but generally do not affect software license cost. These include the following:
- An organization that can implement the new system cleanly, without a lot of data conversion from the old system and without building interfaces to legacy or third-party systems, will get by with a much smaller implementation budget than will an organization that requires excessive data conversion or integration.
- An organization with well-defined business processes, and that conform to the business processes defined in the software, will generally pay less for implementation than will an organization that needs a lot of business process change.
- An organization that has a well-formed internal project team with skilled resources will generally pay less for implementation than will an organization that depends mostly on outside contractors to undertake implementation activities. The organization with a well-formed team also is at less risk of project failure.
- Choice of the implementation consulting partner. An organization that engages the help of a qualified system integrator—or the vendor’s own consulting arm, if so qualified—will generally spend less on implementation than will an organization that chooses an integrator with lesser skills or a poor track record in delivering services within budget.
Other factors come into play, such as the degree of standardization of business processes among multiple facilities, and the organization’s track record in managing cross-functional business-change projects.
Complexity of the Software
Lastly, one other factor acts as a wild-card, in my opinion, in the ultimate cost of an ERP-software implementation project: the complexity of the software itself. This may or may not affect software license cost, but it often affects implementation cost.
This may be easiest to define with an example. SAP and Oracle are two well-known, so-called Tier I ERP systems. It generally is understood that these systems can support the largest, most complex and most geographically dispersed organizations. Also, they can support the widest number of industry sectors. They do this by incorporating a great deal of functionality for various industries, business processes and local regulatory requirements. These systems are highly configurable, with a big footprint.
This complexity comes with a price. It means that to make use of the system in a specific organization, many decisions must be made during implementation. These decisions cost time and money as experts configure the software and test it specifically for the organization’s needs. This drives up the cost of the implementation.
SAP and Oracle are well-aware of this issue and have worked hard over the past decade to preconfigure their systems for specific industries and uses. If a customer fits well into the vendor’s preconfigured templates, much of the complexity of the software can be hidden from view. Customers that fall neatly into these templates can sometimes achieve very rapid and cost-effective implementations.
But don’t the higher-end software packages still cost more than software targeted for small and mid-size businesses? This is not als the case. I have seen situations where SAP and Oracle were actually the low-cost bidders. In cases where a software vendor wants the deal, it is not safe to assume that the higher-end package will cost more. For this reason, I don’t believe software complexity in itself is a consistent factor in either software license cost or implementation cost.So, why do software vendors, customers or integrators continue to use the implementation-to-license cost ratio? Because, as flawed as the ratio is, it does set expectations as to implementation cost. To me, the ratio best works in hindsight—if a system implementation, on average, costs 1.5 times the cost of the software, a customer must not assume that it can do it for half the license cost. To really judge the prospective cost of an implementation project, nothing beats performing a detailed estimate based on a realistic work-breakdown structure, with realistic estimates that account for the factors outlined here. MF