Many companies urgently need to replace their systems in order to adequately service their customers, improve the efficiencies of their operations, and become year 2000 compliant. Neither upgrading existing systems nor developing new systems in house is feasible, given the time frame. CIOs and MIS managers must turn to outside software vendors to replace their systems portfolios. Enterprise Resource Planning (ERP) systems, which support all of a company's business processes and link to customers and suppliers, are being sold in record numbers. Led by growth engines SAP AG, Baan, Oracle, and PeopleSoft, the ERP market is expected to expand from $13.8 billion in 1996 to $17.7 billion by the end of 1997*.

With more than 125 enterprise applications vendors worldwide vying to meet customers' demands*, how can a company select among so many choices?

System Selection Isn't What it Used to Be

Selecting and implementing an ERP package today is completely different from what occurred in the past. It is also different from developing a system from scratch. The traditional approach to software selection usually involves the creation and issuance of a formal request for proposal (RFP). The basis of an RFP is one of the following:

A long list of function and feature requirements that is a composite of every requirement provided by sources such as Advanced Manufacturing Research and Gartner Group, trade shows, software vendors, and other RFPs. Vendors are rated on the number of functions and features their packages can provide. The objective of the selection committee is to find a vendor who can cover the highest number of requirements. Resulting problem: There is usually little or no prioritization of requirements. Priorities, if any, are highly subjective. Critical and unique requirements are buried in the list, and their importance is often lost.

A corporate-created standard model of the business that is imposed on the business groups. The model is usually the result of many months of discussion and design by a committee. The model is a vision of what Corporate would like to see in the business groups and is not grounded in the reality of these businesses. Resulting problem: The model is a composite of the requirements of all the business groups and does not fit any one group well. Also there is minimal sponsorship and commitment from the management of the business groups.

A detailed specification of the systems that will be required to support recently redesigned business processes. The MIS group develops the specifications as part of process reengineering. Resulting problem: The reengineering is done without consideration of standard package functionality. The specifications are usually unique to the company's operations and practices, and therefore, difficult to translate to an ERP package.

The responses from the RFP are evaluated based on a limited interchange with the vendors' sales teams. If a demonstration of a vendor's package is provided, it is often the vendor's standard, pre-packaged demonstration and does not have relevant terms, data, and processes (e.g., a toy company example for a chemical company). Finally, the selection team scores the vendor responses and makes its selection. As the result of the above problems, the traditional RFP selection process is a long, drawn out, internal decision-making process.

Selection teams often get "stuck" and cannot reach a decision, or reach a decision but cannot sell it to management and get appropriate funding. To speed the process along, an executive of a company will sometimes make an arbitrary decision to go with the ERP system vendor that is the defacto industry standard or the choice of a trusted business associate. This decision is then dictated to the rest of the organization.

Neither the RFP nor the executive decision is the best approach for a company. The arbitrary decision is almost always vigorously resisted by the organization. The committee selection process takes too long and cuts into the time for implementation. In both approaches, important requirements are overlooked or under-valued in the selection process. Business process and practice improvements that are part of packages are not considered. There is usually a misfit between the company's requirements and the package's features, so time and money must be invested to align the two. Finally, neither approach gives the company and the vendor an opportunity to establish a relationship with each other, or to determine what it will be like to live and work together during system configuration and implementation.

ERP Packages in the 1990's Are Better

ERP system packages today have been engineered to provide the functions and features that are standard in most industries. The systems are designed around business processes such as order fulfillment, rather than functions such as sales, planning, purchasing, production, shipping, and accounts receivable. Most of the functionality that a company requires can easily and quickly be configured into the systems without modification to the software. Interfaces to supplemental, special function systems are either provided by the vendors or enabled in their system design.

Most ERP systems include the leading practices advocated by professional societies, industry groups, and consultants. Thus, they provide companies with the opportunity to learn better practices than they currently employ. Most companies would probably not come up with better practice models on their own, except in a few unique industry processes.

Many vendors have process models of their systems' functions that will guide a company through redesign of its business processes. Some ERP vendors have developed configurators to make the initial system configuration (and subsequent changes) fast and easy for a company. Companies should take advantage of these features and prepare only minimally in advance of selecting a package. Companies should not "reinvent the wheel" and develop detailed specifications of their system requirements. It is very time consuming and costly, and will be unlikely to fit any package when done.

Rapid Software Selection Process

In most cases, a company should "time box" its selection process to no more than eight to ten weeks. In the first six weeks, the objective should be to quickly narrow the list of software vendors to the few that appear to best fit the company's requirements. In the remaining four weeks, the vendor finalists should be evaluated and a preliminary selection made of the best ERP vendor and package.

Every ERP selection process should begin with the establishment and/or documentation of its case for action and business objectives. Why must the company change? What are the opportunities? What are the threats? What are the measures of success? What are the priorities? What role will the systems play?

After some preliminary review, the company should develop and issue a request for information (RFI) to those vendors that meet the first level of selection criteria, such as industry fit, technology platform, and company size. Typically, this includes five or six vendors. The RFI should be brief and describe the company and its unique requirements. It should request that each vendor sends documentation on its package's features, technology, and support capabilities, and - most importantly - the package's ability to support the critical requirements. Based on this information and on-going conversations with vendor representatives, the company can select three vendors which best suit its basic needs (e.g., can meet unique process requirements, are able to provide on-site support, are willing to work through the RSS process, etc.).

In parallel with the RFI, the company should develop requirements checklists for each of its business processes. Usually one to two-day working sessions with people who understand today's processes and one or two outside experts to provide best practice examples are sufficient for each major process. The workshops should model future processes, only to the level required to sufficiently understand the requirements and their relative priorities and benefits, and define the implications for change. Checklists also should be developed for technology requirements and project support requirements (e.g., how the project should run, who will lead it, who will participate, how consultants will work together). Every requirement on a checklist should be prioritized with only a limited number deemed an "essential" criteria for the ERP package selection.

Once the checklists are complete, the few vendor finalists should be invited in for structured interviews and demonstrations to key stakeholders and selected participants from each of the working sessions. Then the vendors and their ERP packages should be rigorously evaluated and ranked. Customer references and the financial well-being of the vendors should be checked and a visit made to at least one of the vendors' customer installations. The implementation team and project manager from the vendor should meet the company's proposed project team so they can discuss their working relationship.

The initial RFI, working sessions, and vendor meetings result in the preliminary selection of a vendor. However, the final step in the decision-making process is optimally a three-week "honeymoon" in which each vendor finalist allows the company "hands on" time with its system to better understand how it works. The vendor can use this time to learn about the company's operations and its unique processes. The project team and vendor work together to determine the fit of the package, the necessary modifications, and the principles of how the vendor and company will work together.

Beyond making the best decision quickly and building a motivated team, the RSS process addresses three additional critical project components:

Business case development. A business case needs to be developed to support the ERP system recommendation. The case will include the costs and benefits of the proposed solution as well as the impact on the organization in terms of process, practice, organization, and job changes; training and skills development; changes to performance management systems; and adjustment of the culture, norms, and policies of the organization.

Change management. Enrollment and communications cannot wait until the ERP system vendor has been selected. In order to ensure a smooth and timely transition into system implementation, the selection team should work to build understanding and support for the ERP system throughout the selection process. All key stakeholders and decision-makers should understand the case for action, the business objectives, and the purpose and capabilities of the ERP system. They should understand how their jobs will change for the better.

Implementation planning. A road map for the implementation of the ERP system should be developed. The phases and pace of the project should balance the organization's capability to change, its need for benefits return, and its ability to fund the system. Project plans should be developed with milestones and deliverables. Roles and responsibilities should be specified and agreed upon by accountable people. In most projects, implementation planning will include the identification and contracting of additional resources to supplement the capabilities of the existing organization.

ERP System Selection Case Studies

Industry Standard Solution

After some deliberation, a company's executive staff chose a leading ERP supplier for their company's ERP solution. They had been vigorously "wooed" by the vendor's management team and believed that the vendor's package was becoming a standard in their industry. They thought the ERP package was the logical choice for their company. After two years of investing time, effort, and millions of dollars in configuring and implementing the system, the company abandoned the project and the ERP solution. Why?

The company's strength and competitive advantage is its renowned direct selling approach. The company had revolutionized its industry when it chose to sell its products directly to the market, rather than through an external sales force or distributors. The direct selling process is the unique, core process of the company's business. What the executive staff had not known was that the ERP system could not sufficiently support this core process and could not technically handle the volume of its transactions. What should the company have done?

Using the RSS process, the company would have identified, early on in the process, direct selling as its core business process and an essential requirement of its ERP solution. The company would have required that each vendor under consideration demonstrate its package's capability to support high volume, direct selling.

Corporate Dictated Solution

A company's corporate management had formed a relationship with a leading ERP vendor and expected that all its business divisions would standardize on that vendor. However, the management of the first division to select an ERP solution refused to follow the dictate of Corporate. The division had been set up as a new business model and had a sense of independence. The division set up its own team to evaluate ERP vendors, and to make a recommendation for the division.

The team developed a lengthy list of its requirements, including technical requirements which specified a distributed architecture. The corporate-approved package did not have a distributed architecture and was thereby eliminated from consideration. After six months of evaluation and little progress toward a decision, the team decided to try the RSS process.

Over several weeks of facilitated working sessions, the team and others they involved from the division, identified what system features were really important to the division. The criteria they defined clearly indicated that business requirements were much more important than the technical requirements - in particular, the distributed architecture. The team used its criteria to evaluate the corporate-approved vendor plus two other vendors. The corporate-approved vendor was found to be the best overall solution. The team made its recommendation and successfully implemented the package.

RSS Assisted Solution

The company's systems were old, heavily patched, and required costly maintenance. Rather than enable the company's business processes, the systems hindered and were sometimes a barrier to doing business competitively. Increasingly, long-suffering customers notified the company that they were switching to competitors. The last straw for the company was a systems audit by an outside firm, indicating that it would cost at least $10 million to make the systems year 2000 compliant. The cost estimate did not include the cost of making any improvements in functionality.

The MIS management requested permission from the company's senior management to select an ERP system package to replace most of the existing systems. The company's senior managers were not system advocates and had no sense of urgency to improve the functionality of the systems. The managers just wanted the group to fix the year 2000 problem so that there would be no disruption in operations. They grudgingly gave their approval for the formation of a project team to evaluate and select an ERP package.

The MIS group formed a cross-functional project team - one of the first cross-functional teams in the company. The team had little confidence in its ability to succeed at this venture. No one in the team knew anything of packaged ERP systems. In addition, the company had a track record of failed or aborted systems projects. After 18 months of team formation and review of alternative ERP selection approaches and consultants, the team had made little progress in selecting an ERP package.

The hiring of a new COO and CIO rocketed the team into action. In six weeks of using the RSS approach, process teams formed and identified its important ERP requirements in short, intense working sessions. The teams issued and evaluated an RFI and narrowed their vendor prospects from nine to three. Over the next few weeks, the vendors demonstrated their packages and participated in a day-long, energetic Q&A session with the process teams. The vendors commented favorably on the preparation, knowledge, and confidence of the process teams. The process teams made their decision and were committed to the successful implementation of the ERP system.

Rules for Successfully Using the RSS Process

As the result of our experience with the RSS process, we have learned what makes it successful. These "rules" may seem like common sense, but companies that deviate from them do not get significant results from the RSS process. The following are the rules for a successful RSS process:

Do the selection process - from start to finish - in a matter of weeks so that the information is fresh and understood, and people are energized and committed to the results. The longer the selection process, the more the information ages and loses its priority.

Involve the right people in working sessions. Participants must be knowledgeable and experienced with the current processes and functions, and credible to the rest of the organization. The best candidates for the team will be those targeted to lead the ERP system implementation. They should be a small and empowered group.

Make the working sessions short, intense and focused on getting out the key requirements for each process area. The sessions should be fun. The working sessions should neither attempt to uncover all requirements nor document each requirement in depth.

Focus on the essential priorities in the vendor evaluations. Use three priorities: essential, important, and nice-to-have. Assign every requirement a priority.

Structure the business processes early in the RSS process to get a useful business model. When companies try to build their processes themselves from groups of their functions, they end up with too many processes that are not relatable to the ERP process set. Companies have found that it is beneficial to use an external coach to assist them in this process.

Capture benefits and change implications of process requirements during the working sessions. These benefits and implications can be used in the business case to support the ERP package recommendation.

Engage a coach to direct the selection process and to run the working sessions with rigor, discipline, and a fast pace. The coach should have experience with the RSS process and should be able to contribute examples of better practices in each process area.

Talk to the right person at the right level in the vendor's organization. Seek out the regional manager or the manager of your industry focus area, not just the local sales manager. Tell the vendor that you are using the RSS process and not a traditional selection process. Make sure that the vendor is willing to participate and meet your schedule and milestones.

Ask the vendor to mobilize a group of its package experts to lead the demonstration of its package's capabilities. Explain how the demonstrations and question/answer process will be done. Emphasize the importance that a relevant demonstration will have in your decision making process.

Manage the project as a business change project with no breaks between selection process and implementation. Milestones, meetings, and resources that will be required in the selection process should be planned in advance. Change management should begin from the start of the selection process, and should be an explicit and important agenda throughout the process. The whole project should be managed as a business change project rather than a systems project.

Results of the RSS Process

RSS is an efficient and structured ERP software selection process that is based on a company's unique business model and key requirements. The selection decision is made in a reasonable period of time by an informed and empowered cross-functional team, rather than a dictate by a senior executive. The selection team understands and is committed to its ERP package decision. The team learns how to work together effectively - a benefit that will be advantageous throughout the project.

A context and foundation for partnering with software vendors are established during the RSS process. This is untypical in most vendor/customer relationships. The process is interactive and emphasizes sharing of information with the vendor. The process asks vendors to respond to specific needs and participate in a company-defined RSS process. This thereby establishes the role of the company to drive the selection process.

All factors critical to eventual project success, including better practices, change implications, benefit statements, and roles and responsibilities, are considered from the start of the RSS selection process. Additionally, the results of RSS are integrated and linked to the business case, providing a foundation for all subsequent development and implementation activities.

Advantages of the RSS Process to the Vendors

The RSS process is very considerate of the vendors' time and costs. Vendors do not have to do long, formal, and costly responses to RFPs, a typical investment vendors must make before they are qualified in the selection process. In the RSS process, vendors are qualified or eliminated quickly based on the critical criteria. Vendors, themselves, can tell whether or not their packages fit.

There should be no surprises in the RSS process. People who participate become knowledgeable about their company's requirements for an ERP package. The vendors can discuss with the participants in an open forum throughout the selection process. They learn how the company wants to work with a vendor during the project, and they get enough exposure to know whether they want to work with and contract with the company. The RSS process establishes a sound basis for a partnership between a company and its chosen vendor. The likelihood of implementation success is significantly higher with companies that have begun their association with their vendors in the RSS process.

Summary

Selecting an ERP package should not be a long, exhaustive process. With year 2000 just around the corner, time is better spent on configuring and implementing a system rather than on selecting a system. Companies should use ERP packages' documentation and process models to determine what they are capable of providing and which are the best fit.

Companies do not need to reengineer their business processes and develop detailed specifications before making their software decision. The selection criteria can be easily and quickly defined. The best business process solution should be modeled around a systems package, and any process redesign should be done in concert with the package, not in isolation of it. Once a company has decided to use a package, the company should proceed rapidly through evaluation to package selection. We recommend that companies use the fast, focused approach to ERP system selection that we call Rapid Software Selection. With this approach, companies in weeks - not months or years - identify their critical business and technology requirements, and use this criteria to confidently make their system selections.

(* references upon request)

###

To Top of Page