Choosing the Wrong ERP Because ERP

Choosing the Wrong ERP

Because ERP systems are prefabricated systems, users need to determine whether a particular ERP fits their organization’s culture and its business processes. A common reason for system failure is when the ERP does not support one or more important business processes. In one example, a textile manufacturer in India implemented an ERP only to discover afterward that it did not accommodate a basic need.
The textile company had a policy of maintaining two prices for each item of inventory that it sold. One price was used for the domestic market, and a second price, which was four times higher, was for export sales. The ERP that the user implemented was not designed to allow two different prices for the same inventory item. The changes needed to make the ERP work were both extensive and expensive. Serious system disruptions resulted from this oversight. Furthermore, modifying an ERP program and database can introduce potential processing errors and can make updating the system to later versions difficult.


Goodness of Fit
Management needs to make sure that the ERP they choose is right for the company. No single ERP system is capable of solving all the problems of all organizations. For example, SAP’s R/3 was designed primarily for manufacturing firms with highly predictable processes that are relatively similar to those of other manufacturers. It may not be the best solution for a service-oriented organization that has a great need for customer- related activities conducted over the Internet.
Finding a good functionality fit requires a software selection process that resembles a funnel, which starts broad and systematically becomes more focused. It begins with a large number of software vendors that are potential candidates. Evaluation questions are asked of vendors in iterative rounds. Starting with a large population of vendors and a small number of high-level qualifier questions, the number of vendors is reduced to a manageable few. With proper questioning, more than half the vendors are removed from contention with as few as ten to twenty questions. In each succeeding round, the questions asked become more detailed and the population of vendors decreases.
When a business’s processes are truly unique, the ERP system must be modified to
accommodate industry-specific (bolt-on) software or to work with custom-built legacy systems. Some organizations, such as telecommunications service providers, have unique billing operations that off-the-shelf ERP systems cannot satisfy. Before embarking on the ERP journey, the organization’s management needs to assess whether it can and should reengineer its business practices around a standardized model.


System Scalability Issues
If an organization’s management expects business volumes to increase substantially during the life of the ERP system, then there is a scalability issue that needs to be ad- dressed. Scalability is the system’s ability to grow smoothly and economically as user requirements increase. The term system in this context refers to the technology plat- form, application software, network configuration, or database. Smooth and economical growth is the ability to increase system capacity at an acceptable incremental cost per unit of capacity without encountering limits that would demand a system upgrade or replacement. User requirements pertain to volume-related activities such as transaction processing volume, data entry volume, data output volume, data storage volume, or increases in the user population.
To illustrate scalability, four dimensions of scalability are important: size, speed, workload, and transaction cost. In assessing scalability needs for an organization, each of these dimensions in terms of the ideal of linear scaling must be considered.5

Size. With no other changes to the system, if database size increases by a factor of x, then query response time will increase by no more than a factor of x in a scalable system. For example, if business growth causes the database to increase from 100 to 500 gigabytes, then transactions and queries that previously took 1 second will now take no more than 5 seconds.


5 R. Winter, “Scalable Systems: Lexicology of Scale,” Intelligent Enterprise Magazine (March 2000), 68–74.

564 Chapter 11: Enterprise Resource Planning Systems


Speed. An increase in hardware capacity by a factor of x will decrease query response time by no less than a factor of x in a scalable system. For example, increasing the number of input terminals (nodes) from one to twenty will increase transaction processing time proportionately. Transactions that previously took
20 seconds will now take n