• What is ERP?
• How can ERP improve a company’s business performance?
• How long will an ERP project take?
• What will ERP fix in my business?
• Will ERP fit the ways I do business?
• What does ERP really cost?
• When will I get payback from ERP—and how much will it be?
• What are the hidden costs of ERP?
• Why do ERP projects fail so often?
• How do I configure ERP software?
• How do companies organize their ERP projects?
• How does ERP fit with e-commerce?
• How do on-demand and software-as-a-service ERP applications work?
• How do I know my ERP data is any good?
• Just how important have ERP systems become?

How do companies organize their ERP projects?

Based on our observations, there are three commonly used ways of installing ERP.

The Big Bang—In this, the most ambitious and difficult of approaches to ERP implementation, companies cast off all their legacy systems at once and install a single ERP system across the entire company. Though this method dominated early ERP implementations, few companies dare to attempt it anymore because it calls for the entire company to mobilize and change at once. Most of the ERP implementation horror stories from the late ’90s warn us about companies that used this strategy. Getting everyone to cooperate and accept a new software system at the same time is a tremendous effort, largely because the new system will not have any advocates. No one within the company has any experience using it, so no one is sure whether it will work. Also, ERP inevitably involves compromises. Many departments have computer systems that have been honed to match the ways they work. In most cases, ERP offers neither the range of functionality nor the comfort of familiarity that a custom legacy system can offer. In many cases, the speed of the new system may suffer because it is serving the entire company rather than a single department. ERP implementation requires a direct mandate from the CEO.

Franchising strategy—This approach suits large or diverse companies that do not share many common processes across business units. Independent ERP systems are installed in each unit, while linking common processes, such as financial bookkeeping, across the enterprise. This has emerged as the most common way of implementing ERP. In most cases, the business units each have their own "instances" of ERP—that is, a separate system and database. The systems link together only to share the information necessary for the corporation to get a performance big picture across all the business units (business unit revenues, for example), or for processes that don’t vary much from business unit to business unit (perhaps HR benefits). Usually, these implementations begin with a demonstration or pilot installation in a particularly open-minded and patient business unit where the core business of the corporation will not be disrupted if something goes wrong. Once the project team gets the system up and running and works out all the bugs, the team begins selling other units on ERP, using the first implementation as a kind of in-house customer reference. Plan for this strategy to take a long time.

Slam dunk—ERP dictates the process design in this method, where the focus is on just a few key processes, such as those contained in an ERP system’s financial module. The slam dunk is generally for smaller companies expecting to grow into ERP. The goal here is to get ERP up and running quickly and to ditch the fancy reengineering in favor of the ERP system’s "canned" processes. Few companies that have approached ERP this way can claim much payback from the new system. Most use it as an infrastructure to support more diligent installation efforts down the road. Yet many discover that a slammed-in ERP system is little better than a legacy system because it doesn’t force employees to change any of their old habits. In fact, doing the hard work of process reengineering after the system is in can be more challenging than if there had been no system at all because at that point few people in the company will have felt much benefit.

The On-Demand Nibble—You're most likely to see this approach in a small or midsize business that's lost its patience for Excel spreadsheets and the fax machine, and in large companies that either have massive operations and will never be able to standardize on one system or have been burned by costly and not-so-satisfying ERP rollouts in the past. In this instance, companies turn to a small but growing number of on-demand or software-as-a-service (SaaS) ERP vendors that can offer:

• faster implementation times (there's no software to install on-premise, and that literally shaves months off installation periods);
• easier and more frequent upgrades (they can happen automatically because the vendor manages the applications and can roll out patches and bug fixes more regularly); and
• cheaper up-front costs (the software price tag can be much cheaper than traditional on-premise applications because of subscription pricing that is on a "per user, per month" basis as well as big reductions in integration and consulting fees).

Why companies are just "dipping their toes" in the on-demand and SaaS waters right now is because those companies (and their vigilant IT departments) still have concerns about housing their mission-critical and highly sensitive ERP data (such as HR and financial) on a third party's servers and not their own.