Usually, what is unique about your business is how you track, manage and communicate your needs � internal needs for financial information, production schedules and sales data; external needs for sales quotes, purchase orders and shipping instructions. In my experience, most companies develop unique methods of tracking, managing and communicating, not from some consciously thought-out master plan for world leadership, but from some evolutionary process often initiated by persons long-gone and even forgotten.

One of the unique facets of an event as broad-scoped and encompassing as an ERP system implementation is that it provides the opportunity required to overcome the inertial resistance of years of evolution � a chance to make a quantum leap forward, establishing your company as the industry leader, and devastating your competition.

Spending on ERP systems is expected to rise from $5.5 billion in 1996 to $15 billion in 2000 � a hefty 173 percent in four years. In fact, three of the four largest software companies in the world are ERP systems vendors.


What is Required to Succeed?

A question that is not asked seriously enough at the outset.

To succeed, senior management must know and communicate the importance of the effort. It must be sold and re-sold. Knowing why the effort is being undertaken is the most important key to a successful implementation. It is vital to identify, and use, prioritized core business objectives (CBOs) to demonstrate "why" (Example 1). The CBOs must also be translated into a cost-benefit analysis to support the decision (Example 2).

EXAMPLE 2: SAMPLE "COST-BENEFIT ANALYSIS" FORM.
1. Reduced Costs	Total prior year's COGS x 5% (Savings)
2. Better time-to-market	Total prior year's Sales x 1.5% (Improved Margin) Prior year's average inventory value x 2% (Savings)
3. Improved Quality	Total prior year's Returns x 10% (Savings)
4. Increased Customer Service Levels	Total prior year's Sales x 5% X 10% (Improved Sales X Margin)
5. Overcoming a Lack of Information	Total prior year's Sales x 5% X 10% (Improved Sales X Margin)
6. Eliminated Cost of Maintaining Older Systems	Cost from MIS budget (Savings)
7. Year 2000 Issues	Planned cost of reprogramming (Savings)
8. Improving Business	SWAG value of increased opportunities (Sales X Margin) (Software) Flexibility
Total Value of Benefits	$$$
Total Cost of System	$$$ (Taken from Project Budget; see section, "On Schedule, On Budget)
Return On Investment (ROI)	% (ROI equals the Total Value of Benefits divided by Total Cost of System.)
Note: If ROI is less than 30 to 50 percent, implementing is not advisable at this time.

Step one, have management create a prioritized set of CBOs.

Step two, have management restate the priorities in terms of core functionality desired.

At this stage, an experienced, APICS-certified consultant can be of tremendous value. We also find a "reports analysis" effective in identifying required functionality. A reports analysis takes existing reports and requires management to identify the five most critical variables on the three most important reports for running the business. (Have them visualize "flying a plane," the business, in an "instruments only" mode due to "reduced visibility," where they only have three instruments with five variables.) What would those have to be? Would it be cash balance, EBITDA, billing milestones, aged receivables? What is the most critical information, and how are they accustomed to seeing it presented? The process is then repeated to establish additional sub-layers of importance.


A Model for Implementing

Careful planning. Accountability.

Implementing an ERP system is, by its very nature, an iterative process. Knowing how to implement successfully requires knowing what to do and when to do it. To succeed you must decide what the appropriate "functional layers" are for your business (Figure 1). Then carefully plan to install, initialize and test one functional layer at a time. First the core functionality, using representative data, is installed, initialized and tested. Then additional layers of functionality are processed using representative data. Finally, the entire system is tested using larger samples of real, historical data with known results. Only an implementation model based on the discipline to make consistent, iterative progress will carry you to success.

The model: We focused on a 10-day, iterative cycle, broken into three- and seven-day parts. Three workdays are spent with the appropriate consultant to analyze, plan and learn what is needed during the next seven workdays to execute the defined objectives. Day 8 is designated for the project review cycle, and consists of progress review by the appropriate level of management. This is where accountability is enforced.

Defined objectives specify what to do and when to do it. The defined objectives are derived from the CBOs, desired functionality and reports analysis. They are developed as building blocks, one layer at a time, until top management's strategic needs are under-pinned by middle management's tactical needs, which are then under-pinned by line management's operational needs. The final result is a complete description of what the system must do � an "information plan." It shows what information users require before the implementation can be a success. It is also a hierarchical plan with dependencies, so it can be scheduled. Establishing the defined objectives is best done bottom up to ensure being grounded in reality.

Scheduling the defined objectives provides the when. Taking the beginning and ending dates for the schedule provided by top management, plus the information plan, with the help of the appropriate vendors and consultants, a baseline schedule can be created and then evaluated for a "reality quotient." Since some activities can only be done sequentially, while others can be done in parallel, the schedule can be evaluated not only for whether it is achievable in an absolute, objective sense, but also within the budgetary constraints set by management. It can also be evaluated for optimization opportunities. In other words, could total cost be reduced 30 percent by extending the schedule six weeks? Is it possible to reduce costs by shortening the schedule three weeks and "cutting over" at a year-end? If, in weeks 22, 23 and 24, the schedule needs 46 people full time, is that realistic or do we need to adjust the schedule? Would the probability of success be increased by one team working longer instead of multiple teams working in parallel? These and many other questions must be addressed with unswerving honesty to establish a baseline schedule solidly grounded in reality.


Being "On Schedule, On Budget"

Starting with reality, commitment and accountability.

The key to being on schedule and on budget is to start with a baseline schedule and budget grounded in reality (Example 3). The next step is to consult with vendors to see how resources for consulting, education and technical support align with the baseline schedule and budget. The process iterates until both the baseline schedule and budget are finalized. Get written commitments from the vendor, and any other outside consultants, to adhere to the defined objectives in the baseline schedule. Remember, there is no substitute for having commitments in the contract.

EXAMPLE 3: BUDGET GUIDELINES
Initial Costs:
Hardware Costs	Average 10 - 20% of Total Project
Software Costs	Average 40 - 45% of Total Project
User Training	Average 24 - 30% of Software Costs
Integration and Testing	N/A
Data Conversion	N/A
Data Analysis	N/A
Consultants	Average 40 - 60% of Software Costs
Process Rework	N/A
Duplication of Existing Reports	N/A
Data Warehouse Integration	N/A
Ongoing Costs: Maintenance Fees	Average 12 - 15% of Software Costs
Note: You can test your budget for reality using these guidelines, but you need to remember every company enters into ERP from a unique position. Therefore, there are some variables where guidelines would be meaningless or misleading so we have shown them as "n/a." We have included them in the list simply so you won't forget to include them in your budget. The five most often underestimated costs are User Training, Integration and Testing, Data Conversion, Data Analysis and Consultants (see box below).

This is not the time for "selling" a "politically acceptable" baseline schedule or budget. If the appropriate commitment of resources from management or the vendors are not made, achieving accountability through a project review cycle becomes impossible, and being over-budget and behind schedule is virtually guaranteed. Once the baseline schedule is finalized, enforcing a project review cycle becomes paramount.

Having invested the time and effort to create the baseline schedule, a realistic budget enables the final key to success � creating ownership and accountability. From here on, enforcing responsibility through rewards or discipline is done at project review meetings. Maintaining the project review cycle becomes paramount. The implementation team must know that time is critical � if the integration takes too long the business benefits from ERP are lost. The team has a realistic baseline schedule and budget to use as a "road map," but successfully completing the project is its responsibility.


Relying on the Vendor for Success

What you need to know about contracts and consultants.

The old adage, "If you want to know the truth about what you're buying, read what is written," has never been truer. A typical software license contract states that the company "does not warrant that the system software will meet the licensee's requirements or that operation of the system software will be error free," that the company "does not warrant that the operation of the system software will be uninterrupted or error free" and that "licensee agrees that it accepts full responsibility for the installation and use of the system software to achieve the intended results." You simply cannot rely on the vendor for success. The rule is caveat emptor. They have told you in writing what to expect.

And as if that weren't bad enough, you will need to rely on help from consultants � either independent or the vendor's employees. They are often marginally qualified, but employed anyhow, because demand so dramatically exceeds supply, and vendors and clients are grabbing anyone they can. And it is getting worse as more systems are purchased and implemented. Since the ideal consultant is "multilingual," speaking fluent Accounting-ese, Manufacturing-ese and Information Technology-ese, flowing back and forth from core business issues to technology issues and "translating" between the different user groups within the company, the supply of qualified consultants cannot expand fast enough to keep up with demand. As a Labor Department report on high technology jobs said, "This labor shortage isn't simply an inconvenience for business anymore; it's starting to affect competitiveness."

So we have to ask, Why take the risk of implementing an ERP system? Because there are core business objectives that indicate you could be enjoying a return on investment between 30 and 50 percent from the system implementation effort. However, make no mistake; to enjoy those rewards you must avoid the pitfalls of relying on the vendor or consultants for success. You must use an approach designed to create success, and have the discipline to stay on course.


Defining, Documenting and Re-Engineering the Business

Exercising uncompromising honesty.

Apple's free-wheeling corporate culture rebelled at ERP's push toward standardization. At Owens-Corning, ERP has become the engine of a broad overhaul. Yet many companies buy these systems and end up worse off than when they started. What makes the difference?

The toughest decision of the implementation is whether to "shape the software" or "shape the business." It is critical to selecting the right software. It makes all the difference. It is vitally important, and often misunderstood. It can be a source of incredible pain, or incredible gain, and the correct decision can't be made accidentally because of "the human factor." Because ERP systems are so complicated, it is usually cheaper to change people's workflow than to change the way the system works. What that means is, if the implementation is going to be required to shape (i.e., customize) the software in any significant way, the database technology and its tools become more mission critical than the "out-of-the-can" functionality. However, the reverse is true also. And don't be too quick to say, "Our business is so unique, so one of a kind, that we would lose all of our business, all of our competitive edge, if we changed it to fit the software." Granted, your business is unique, but a quick response belies a basic misunderstanding about being uniquely similar.

As we said before, one of the unique facets of an event as broad-scoped and encompassing as an ERP system implementation is that it provides the opportunity to overcome the inertial resistance of years of evolution � a very real chance to make a quantum leap forward.

To facilitate your system implementation, defining and documenting your current processes is required. Luckily, it can be done painlessly using a rather simple methodology. Step One is selecting a War Room. A windowless conference room with lots of whiteboard space is ideal, but any room can be converted for the purpose by hanging three long strips of 24- to 30-inch wide butcher paper, horizontally, on two opposing walls. The top strip will become a flowchart of financial processes, the middle strip operational processes, and the bottom strip anything that doesn't fit the first two. One wall is the "current process" and the other the "improved (i.e., re-engineered) process." The flowchart is created by writing each step in the process, at an adequately low level of detail, on Post-It notes and attaching them to the butcher paper. It is important to flowchart how it is really done � not how the manual of SOPs says it should be done. So if employees currently circumvent the SOP by stashing some extras in their toolbox or under the workbench or by buying Charlie donuts so their project can be next on his mill, flowchart it with the extras and Charlie in there. On the second wall, if you choose to evaluate the opportunities available for improvement, use the same procedure to develop an optimized approach.

Now making the decision whether to shape the software or shape the business can be done effectively. Evaluate system choices against your process flowchart � regular or optimized. Make your decision wisely.


Selecting the Right System

Using a "global" perspective.

The key for selecting the right system is using the "global" perspective of optimizing the resources of the company. What is most significant are the interrelationships of all the needs and resources. Bringing those relationships into balance allows the company to achieve world-class results in growth, profitability, and product and service development. It is also how the implementation achieves the world-class quality desired.

As Stu Clifton, CEO of DataWorks, a worldwide provider of ERP systems, said, "Manufacturers need to focus on � empowering users to make decisions that bring greater value to the organization through better information." However, better information is not the same thing as more data. In many cases, applications need more emphasis on fulfilling functional needs.

If the decision is made to shape the business, ensuring that the system has the required functionality is absolutely critical because the implementation will entail "selling" organizational and operational change to a greater degree. If the decision is made to shape the software, ensuring that the system has powerful database technology and tools is essential because the implementation will entail much more challenging technical development. No system should be seriously considered if it is significantly deficient in either, but the relative strengths need to fit the shaping decision.


Assembling the Right Team

Having the "right stuff."

Can you imagine NASA preparing and launching a shuttle mission using brand new personnel or part-timers? Implementing an ERP system is nearly as daunting a task, and yet, many companies turn the task over to new hires or existing personnel on a part-time basis, and then wonder why the effort fails! This is clearly not a part-time effort. It is a full-time mission-critical effort. The implementation will fair better with four full-time people than with 23 adding it to their existing responsibilities (i.e., part-time). You may need one team for a small implementation, or multiple teams in parallel for a large implementation, but the full-time rule still applies. Senior management must realize and support the major time commitment the user community makes during the system selection process and implementation period. They must communicate that understanding and support through regular "attaboys" and rewards, especially as the pain index is rising.

But who should be on the team? Since ERP will cross many of the traditional (and artificial) boundaries that users have established, the team must be willing to look beyond what is in place and challenge organizational norms. In order to be effective in implementing the system, the team must include well-established employees who have a strong grasp of the business, who are opinion makers, who understand the unique opportunity a system implementation provides and who are passionate about making things happen. They need to be willing, and able, to delegate all of their current duties, in order to make a commitment to the implementation as their new full-time responsibility. And they need to commit to being the "owners" of the system when the implementation is complete.

It should be a cross-functional group with a designated project leader. Experience has shown that they should be physically relocated together into a work group, possibly in, or adjacent to, the War Room, so that everyone else in the company is put on notice, non-verbally, that the team has accepted a new, mission-critical role.


Successfully Launching the System

There is no substitute for proper testing.

What should management expect? Management expectations should start with themselves. Management should expect leadership, vision, resources, unflinching honesty and expectations limited to well-grounded reality � from themselves � first.

Then, they should expect the team to take ownership. The team must prove it first, launch it second! To prove that the system has been thoroughly tested and is operationally reliable, they must fulfill the requirements of the information plan completely. To launch it they must have a realistic plan for system roll-out that includes generous training opportunities for the user community.

During the implementation period, management should expect the team to provide accurate feedback on progress during the review cycle, using demonstrable examples such as reports actually run in the system with representative data, and to have concrete action plans for managing obstacles as they are encountered. Final approval should only occur when the team can present actual reports and documents as outlined in the information plan, using a large sample of historical data with known results, that are validated by a full reconciliation.

For the roll-out, management should expect to see a realistic plan that includes company-wide PR-type communication, a comprehensive training schedule and training materials (i.e., procedure guidelines, checklists, etc.) in usable form.


Ten Mistakes to Avoid

The probability of failure is very real.

Don't underestimate the pain that precedes success. The Wall Street Journal says installing an integrated ERP system "is the corporate equivalent of a root canal." According to other industry pundits, one-third to one-half of ERP system implementations are "failures," with nearly half of the failures leading to the demise of the company as an independent, ongoing concern.

Ten mistakes to avoid:

1. Hiring inexperienced consultants. You need someone with the intelligence, experience and courage to challenge you.
   
   
2. Abdicating too much. A good consultant is no substitute for a knowledgeable, committed team of owners!
   
   
3. Being afraid to rock the boat. Quantum improvements always shift the balance of power causing waves of turmoil.
   
   
4. Being overanalytical or overintuitive. A system must be rational, but quantum leaps cannot be proven in advance.
   
   
5. Believing one size fits all. Your enterprise is uniquely similar. An important blend of unique traits drives your current success. Do not forsake them.
   
   
6. Emotionally "buying" a particular system too soon. Don't let slick sales presentations convince you to skip through a thorough evaluation and selection process.
   
   
7. Underplanning. Thorough planning is a critical success variable.
   
   
8. Undisciplined testing. There is no substitute because it will not operate like it did on the drawing board.
   
   
9. Expecting short-term results. Don't kid yourself. An ERP system initialized today will not assure improvements by tomorrow night.
   
   
10. Underfeeding the system. An ERP system requires a long-term commitment of ongoing resources.

An ERP system is a major investment. It is an expensive tool with high initial costs and low usage costs. The more completely it's used, the greater the return on investment. Unfortunately most companies underutilize their ERP systems. They are data rich and information poor. An ERP system requires a long-term commitment of ongoing resources, not just the start-up costs budgeted and planned here, and the results will take time. But real-world experience has shown that the investment will pay off. Mass production has given way to mass customization. Local markets are being served by the global village. Your new system � while not a quick fix � is the answer to long-term opportunity in an increasingly competitive world.

ABOUT THE AUTHOR

John Stenbeck is the project manager for the implementation of the new ManFact system that will replace the Jamis system at Southwest Marine in San Diego. Some of the key variables driving the change include problems with Jamis and Year 2000 dates which will begin affecting projects as early as January 1999, and a desire by SWM to provide employees with a user-friendly current-generation technology which will increase job satisfaction and effectiveness. Stenbeck graduated with a bachelor's degree in business (emphasis in Accounting) from San Diego State University in 1985. He is a member of APICS (The Educational Society for Resource Management) and the Southern California Regional officer for DUAL (DataWorks User Alliance). He has worked in accounting, information systems and production management for several companies including PriceCostco Industries and Composite Optics, Inc. He can be contacted at: [email protected]