The Promise

Let’s take a customer order as an example. At its simplest level, fulfillment of the order involves taking the information from the customer, locating/making the product, shipping it, billing for it, receiving payment for it and accounting for it on company books and commission checks. In the pre-integration days, an order started as a conversation that got written up on a piece of paper. That sales order floated from in-basket to in-basket and was keyed and likely re-keyed into each computer system along the way. The end result of this process was often misplaced or lost orders, delays in order processing and errors in quantity or price. And good luck to the poor customer with questions about order status without multiple call transfers retracing the paper’s journey.

When an order is taken in an ERP system, the salesperson or customer service representative has all the information necessary to complete the order – customer credit rating and account/payment history, inventory levels at the warehouse, and shipping schedules. When one department finishes with its part of the order, the order information is automatically routed to the next in line. Information on order status can be accessed at any point by logging into and querying the ERP system.

The Reality

All this automation should help customers get their orders faster and accurately. But all this automation affects the people inside the company in new and different ways. Before, each group just did its part. If something went wrong with the order outside one department’s walls, it was somebody else’s problem. With ERP, customer service representatives are more than order entry clerks. The information on their PC screen – credit rating from the finance department, inventory levels from the warehouse, last payment information from accounts receivable – makes them businesspeople, responsible for making decisions regarding the customer and the order they did not have to make before. People in other departments face new responsibilities too. Inventories can no longer be kept in logbooks or clipboards on a nail. Information on inventory levels must be entered online and kept updated so the customer service reps can quote accurate information on items in stock.

Accountability, responsibility and communication have never been tested quite like this before. In addition to the technical installation, implementing an ERP system forces alterations in key business processes to match the system and requires new training and changes to the job responsibilities of all those involved to perform new tasks, or the same tasks in different ways, to different levels of performance.

The Big But

The biggest caveat with an ERP system is that it is a generic representation of the ways a typical company does business, based on alleged extensive best practices research. While most ERP packages are mind-numbingly comprehensive, they are for the most part designed for use by manufacturing companies that make product units that can be counted. ERP vendors have labored to modify packages for process manufacturers (e.g., oil, chemical and utility companies that measure products by flow rather than units). Given the depth and complexity of the system, modifications at the code level for these and other industries have taken Herculean efforts.

The idea is for companies to adapt their internal business processes to those best practice processes that come embedded within the purchased ERP package. As noted in the order fulfillment example, an installation means changing long-established business processes to accommodate ERP software which, in turn, means changing many people’s roles and responsibilities, including people at very senior levels. Not a relishing prospect for the under-committed.

So the bottom line in plain English is simple but revolutionary to many. You don’t buy an ERP package and “customize” it to fit your business processes. You in fact customize or modify your business processes to fit the package. Rather like bringing the mountain to Mohammed. Amazingly, we still see corporate ERP buyers shocked by that realization, especially after an ERP purchase.

Reasons to Implement ERP

So, the decision to implement an ERP involves a project of breathtaking scope, gut-wrenching adjustments to people and processes, and price tags large enough to make even the most seasoned CEOs lose many night’s sleep. What possible benefits could be worth this much pain? In a Dec. 22, 1999 article, “The ABCs of ERP,” CIO magazine lists the three major reasons companies implement ERP:

1. To integrate financial data. With different systems using different sets of numbers for financial reports, CEOs and division heads get different versions of the truth. An ERP system produces a single version of the truth so everyone is operating from the same page in measuring performance.
2. To standardize manufacturing processes. Companies with international business units may be making many of the same products but using different methods and computer systems. By standardizing manufacturing processes and using a single, integrated computer system, companies can increase productivity and quality. Newly merged and acquired companies are common targets for ERP implementation (or re-installation if the parent has already implemented a package).
3. To standardize HR information. In companies with multiple business units, tracking employee time and benefits is extremely labor intensive. ERP provides a simple method for tracking and communicating these and other company programs and news.

In the CIO article, authors cite a 1999 Meta Group study that looked at the benefits and total cost of ownership (TCO) of an ERP system. TCO included the cost of hardware, software, professional services and internal staff. TCO numbers include the software installation cost and the following two years of service cost, which is when the real costs of maintaining, upgrading and optimizing the system are felt.

1. Among the 63 companies surveyed, the average TCO was $15 million, with a range of $400,000 to $300 million. With such a wide range, it’s hard to draw absolute conclusions; however, the one stat worth noting is the TCO for a single “head-down” user over that period – $53,320.
2. The study found that it took eight months after the new system was in place – 31 months total from project initiation – to start seeing the benefits. The median annual savings from the new ERP system was $1.6 million/year.

The Corporate Root Canal: Why ERP Implementations Are a Red Zone Condition

A few oversights in the budgeting and planning stage can send ERP implementation costs spiraling out of control faster than almost any other IT project. The mere mention of enduring another ERP project within their group sends managers in many organizations running for cover. Covering some infamous budget-busting, career-endangering implementations, the Wall Street Journal, Business Week, Fortune and other publications have characterized ERP implementations as the “equivalent of a corporate root canal.”

Not without some justification. According to a study on ERP implementations by Robert Austin and Richard Nolan of the Harvard Business School, a remarkable 65 percent of executives believe ERP systems have at least a moderate chance of hurting their businesses because of the potential for implementation problems. In a 1998 report called “Chaos,” the Standish Group published some eye-opening results of 8,000 software projects (not all ERPs) that showed significant time and cost overruns and content deficiencies. Based on their sample:

1. The average project exceeds its planned budget by 90% and its schedule by 120%
2. 31.1% of the projects are cancelled before they ever get completed
3. 33% of all projects are over budget and late
4. 52.7% of projects will cost 189% of their original estimates
5. Only 16.2% of projects will be completed on time, on budget
6. The average time overrun is 222% of the original estimates

Implementing an ERP system is an exercise in strategic thinking, precision planning and negotiations within and between multiple departments and functions. It is important for executives and managers to be aware of success factors involved before implementation begins. As reported in Information Systems Management by scholars researching critical implementation issues, “Once an ERP system is implemented, going back is extremely difficult; it is too expensive to undo the changes ERP brings into a company.” ERP projects involve changing the way a company works, and the company (read “leaders” here) has to be responsible for doing just that. It’s easy to blame the complexities of the technology for expensive snafus, but (and here’s another big but) the technology itself is not the biggest problem to resolve. Poor planning and/or poor project management top the list for reasons for implementation snafus. And the top ten list of bubble and budget busters includes difficulties with testing and integration, data conversion, training, project scope creep, consultant creep, and staff disillusionment and loss. Derek Slater’s complete discussion of “The Hidden Costs of Enterprise Software” can be accessed online at cio.com.

As this book goes to press, there is a new wave called extended ERP that connects a company and its suppliers and customers with a single system. If implementing an ERP is a Red Zone, implementing an extended ERP is a dark Red Zone and requires even greater care and attention. Summing it all up, the most common reason for the performance drop is that everything works differently, and it takes some time for people to adjust to the new way to do their job on a new system, be it an ERP or and extended ERP. The expectation is that things were supposed to be instantly better with the flip of a switch. As mistakes and frustration levels rise, management panics and the business hiccups before settling into the new  routine.

No primer on implementing enterprise systems would be finished without some real, live examples of companies who succeeded and failed in this Red Zone. These brief examples were selected to show how messy some of the real world implementations are. The examples hopefully make the point that it takes a good deal of leadership to keep this maneuver under control and to synchronize the technical implementation with the needed modifications of work processes and performance systems.

Singing the Blues: W.L. Gore

There are too many examples of failed ERP attempts in which the companies lost not only the capital invested in the system and millions paid to consultants, but also a major portion of their business. In November 1999, W. L. Gore & Associates, Inc., a privately-held manufacturer of electronic components, surgical appliances, adhesives and sealants, and outdoor accessories (e.g., Gore-Tex brand fabrics) filed suit against PeopleSoft and Deloitte & Touche, alleging that they improperly installed PeopleSoft’s HR management system and damaged Gore’s business.

The lawsuit alleges that Deloitte & Touche consultants were not the PeopleSoft experts they had represented themselves to be. Jay Eisenhofer, an attorney representing Gore, says that the Deloitte team was always on the phone to the PeopleSoft customer service hotline asking for guidance.

Oddly enough, Donald Duck figures into the dispute. To test the system, the Deloitte team created fictional employee files using Disney characters such as Donald Duck. Eisenhofer told the Wall Street Journal that the team couldn’t get the fictional names out of the system and disrupted business by printing out paychecks, benefits and tax statements for Donald and his cartoon mates when the system went live in July 1997.

“Within a very short time of going live, Gore’s human resources, benefits and payroll administration functions were in chaos,” said Eisenhofer in a Nov. 1999 InfoWorld article, “Consultant, ERP Firm Face Lawsuit Over HR App.” “Gore associates were not getting paid, and Gore could not track vacation time or benefits,” he added. Gore is said to have brought in another team of consultants from PeopleSoft to delete the cartoon names and reinstall the software.

According to the suit, Gore paid Deloitte approximately $2.8 million for the software implementation, not including the cost of the software itself, although the estimate provided by Deloitte was for less than half that amount. Gore alleged fraud, negligence and the assignment of incompetent consultants to the project, claiming unspecified damages plus a refund of the $2.8 implementation fees and a further $650,000 in charges. In cases like this, courts have frequently awarded triple damages.

At the time of the filing, neither Deloitte nor PeopleSoft commented on the lawsuit. However, a Deloitte spokesperson later commented in a July 17, 2000 Business Week article, “First, Sue All the Consultants,” that the assignment was completed “to the client’s satisfaction” and suspected the problems occurred when Gore tried to make later changes on its own.

Culture plays an important part in the story as well. Gore has been recognized as one of Fortune magazine’s 100 Best Companies to Work for in America. There is no traditional management structure. The family-run company is known for its consensus-driven, “bone-less” structure. Associates, not employees, communicate directly with each other and are accountable to fellow members of multi-disciplined teams. Sponsors, not bosses, guide associates toward projects that match their skills and interests, helping them chart a career path that maximizes their contributions to the enterprise. Leaders emerge naturally, defined by what is called “followership.” Apparently, some Gore employees have acknowledged that the company’s unusual culture and structure could be a factor in its implementation difficulties.

The Red Zone Moral to the Story:

The moral is simple. Don’t try a Red Zone maneuver with a “consensus-driven, bone-less structure.” Red Zone calls for clear direction, lock-step coordination, and a fast close. This example calls for business unusual rather than business as usual.

And Some Who Are Singing Praises: Chevron
As we’ve seen, out-of-control costs of a massive ERP implementation can be career ending for executives and damaging to the reputations of major consulting firms. Implementing SAP R/3, Chevron’s IT managers executed a project that was fraught with dangers, yet they avoided many of the big traps.

Three years into their implementation, work on the project was still on schedule but the number of expected users had quadrupled to 10,000, and cost estimates were up by a third to about $130 million. Chevron CEO Ken Derr calmly gave the team the green light to continue what would be one of the world’s largest R/3 implementations. According to “Slick Moves,” a Feb. 3, 1997 article in PC Week, Norman Osborn, manager of Chevron’s Advanced Financial Information System project, reported that Derr said “we seemed to be on the right track and that we seemed to have good reasons for our costs as well as our benefits increasing.” Not the reaction you would have expected? Naturally, there’s more to the story.

Initial support for the R/3 project came from Chevron’s CFO who wanted to revamp the company’s collection of some 200 25-year-old financial systems and processes. After an evaluation of ERP packages, R/3 was selected for a pilot implementation at Chevron’s Warren Petroleum subsidiary, an integrated oil patch company like its parent. By all accounts, the implementation and results within the subsidiary were very successful. As published in the PC Week article, one implementation team member said with pride, “We got this to be a top management driven project with heavy emphasis on change management right from the beginning. This wasn’t just about implementing SAP but about getting an old, inflexible organization ready for the inevitable change. And it worked pretty damn slick!!”

While senior management had given the green light, Jim Zell, CIO at Chevron, reported in an Aug. 17, 1998 Industry Week article, “Proof Positive,” that “as we developed a rollout strategy, we couldn’t get the individual businesses to hold themselves accountable for the benefits.” So rather than rushing headlong into implementations in all 15 operating companies, the IT project leads asked each company to develop its own business case, looking at implementation costs and bottom line benefits. Taking this approach, the team had key business data to show the CEO to defend the decision to go forward with the project. Plus, top managers of the operating companies spent the time and effort necessary to understand the system, its benefits and its limitations, as the team earned their buy-in for the implementation.

After nine months of work to assemble the business cases, the company projected a total implementation cost of $75-$100 million. Current cost for financial processes was $124 million per year. The initial set of business cases indicated costs could be reduced by at least $25 million per year – a payoff in three to four years – with the system rolled out to 2500 users.

So how did the danger-fraught times come into play? As it turned out, most of the business cases underestimated current expenses, costs of implementation, and payback. After widespread implementation started in 1994, the scope started changing rapidly. Many operating companies wanted to broaden implementations to cover more functions and users. As SAP started introducing new releases of R/3 with new modules for purchasing and project management, the operating companies wanted the new additions too.

The team controlled their appetites for more technology by continuing to demand ROI and business case justification for each new expansion of the project. To avoid unpleasant surprises, they continued to communicate their approach and their results to senior leaders. The biggest increase in cost and complexity came in building links to legacy systems and to stress testing to be sure that R/3 could handle the now massive workload. Plain and simple, the need for additional computing hardware and disk storage drives up cost in any project with little recourse.

But the team did manage some innovations in other areas to help keep costs under control. The user pool had expanded to 10,000. The cost of training these additional users could have blown the budget and ROI potential to bits. For the initial rollouts, Chevron had used standard classroom training covering R/3, new business processes associated with the system and PC use. The training price tag per user was $4,000. Since a training cost of $40 million would have busted the budget, the team decided to develop their own computer-based training (CBT). Their CBT, using animation, Windows help features, and on-line quick reference replaced classrooms and reduced system instruction by half. Users were required to take the 40-hour CBT training on the new financial system and pass a test before they were certified.

The team became so good at implementation that they were rolling out R/3 in up to five operating companies simultaneously. In fact, said Osborn, that was the only way the project stayed on schedule in spite of the sizeable increase in the scope of the project. Post-deployment, Chevron refers back to the original business cases as they study the returns in the operating companies. The team plans to use the same formula as the units press for more R/3 modules, like Sales and Distribution, along the way: They stuck with careful documentation of the business case and ROI and very careful management of executive expectations.

The Red Zone Morale to the Story:

Get the best players in the game, keep top management in the lead, conduct thorough due diligence  on the enterprise system before you start, keep learning.

Red Zone Principles

Red Zone principles for the implemantation of enterprise systems are critical for success. This chapter will build on the principles of Chapter Four and will include several important variations and distinctions.

Red Zone Principle One: Declare the Company in a Red Zone
While it’s easy for just about anybody in an organization to figure out that a merger is a Red Zone maneuver, few realize that implementing an enterprise system is one. After all, companies have been implementing computer systems for years. What’s so different about this one? The unexpected answer is just about everything.

Enterprise systems bring two key things to the implementing organization: connectivity between parts of the organization that had not been connected before and standard work processes that are baked into the system. First, most companies have implemented software that affects one functional area at a time, like a new financial package that impacts the departments of finance or accounting. An implemented enterprise system may impact dozens of departments simultaneously, requiring the folks in those departments to agree to work together as never before.

Second, many departments in typical companies have been working with computer systems that they believe are the best in class or that are their own proprietary systems that they believe give competitive advantage. Moving to an enterprise system represents a change in organizational strategy, saying that the department will now use a standard solution exactly like many of its competitors will use. Department members must move from a mindset of “our system is special and we need to keep improving it” to a mindset of “our system is not special, it’s standard off-the-shelf stuff that will be improved by the software vendor by periodic new release.” Vastly increased connectivity and movement to a standard solution represent big change for the organization, in both information technology and user departments.

To add to the complications, the value from an enterprise system frequently is not gained by its initial implementation buy by subsequent use of the system and the identification and implementation of process improvements made possible by the systems connectivity. That is, once the system has been implemented and users begin working together in a more connected way across departments, performance improvement opportunities frequently appear. However, further changes in the way the users work together are usually necessary to achieve the improvement opportunity, becoming what some have called a second wave of implementation. The second wave is problematic to many organizations since organization members were bunged up and burned out over initial implementation. It seems awfully difficult for users to even think about a second wave of what they see as pain while they are still licking their wounds from the first wave.

The biggest problem right off the bat is selling top management that implementing an enterprise system is a real Red Zone maneuver. Obviously they would not be considering implementation if a business case had not already been made for the potential big gain. But frequently, the case for a potential big loss has not been made. Somehow the subject does not come up in the conversations with the enterprise software vendor: surprise! Top management’s first step when contemplating an enterprise system should be intense due diligence research on several firms who have completed similar implementations.  If due diligence is done thoroughly, the firm considering the implementation should find a number of firms who can tell them how difficult, upsetting, and tumultuous such an implementation can be.

If top management does its due diligence well, they will understand how tough other firms have found ERP implementations to be, and they will think Red Zone. The information technology professionals will also be thinking Red Zone because of their technical knowledge of enterprise systems. They will understand that they are about to undertake a big, difficult project. The final challenge in preparing the organization will be to convince users of the enterprise system that they will have more hard work and changing to do than just about anybody.

We believe that it is critical for top management to declare a Red Zone when they decide to go forward with the enterprise system implementation. The declaration should include both the potential big wins or gain and the nature of the big losses that are possible from a failed implementation. Top management must also make the case for extremely hard work for several months during at least two waves of implementation. Frankly, I can’t think of a better way to make the point than the Wall Street Journal phrase “corporate root canal” to describe an implementation.

Red Zone Principle Two: Put the Best Players in the Game
Implementation of an enterprise system is a top-down management exercise that follows from a decision that is made at the top. Firms that spend $15 million to $250 million on software alone - in addition to system integration, documentation, training and change management - will want the organization to use that system to make money for the company. In company environments that are accustomed to taking or leaving a new computer application, depending on the preferences of the user, introduction of an enterprise system is a shocking change. Only the most senior executives on both the line and staff sides of the organization have the authority and power to make the enterprise system decision and then enforce it.  While many CEOs have tried to duck responsibility during system implementation, organizations with successful systems have stand-up CEOs who actively led the implementation.

Contrary to popular belief, the second most important executive to the implementation is the COO who represents the user community who will work with the implemented system to make money for the company. The COO is directly responsible for the users who must be fully prepared to use the new enterprise system once implemented. Full preparation includes a lot more than training on the new bells and whistles of the technology. Preparation includes the alteration of all work processes that touch the enterprise system to ensure alignment and the alteration of the performance systems of roles and responsibilities of workers who will use the new system. In those cases where only selected modules of an enterprise system are implemented, like financial or human resources modules, the top organizational executive responsible for the target functional area (i.e., the CFO or the CHRO) most take on those duties just discussed for the COO.

The third key executive role is played by the CIO, the usual owner of the information technology resource for the firm, who must ensure a successful technical implementation of the enterprise system. The CIO is many times called on to be the day-to-day leader of the executive team during the implementation. The savvy CIO leads by pointing out the time and place the CEO needs to throw her support for the system and working with the COO to ensure that user preparation is proceeding as needed to be ready for the technical “go live.”.
Every top executive in the organization that is implementing an enterprise system will have a Red Zone role. That is, they should each have an important and visible piece of the Red Zone action in addition to their day job, their usual duties in the day-to-day running of the company.

• Red Zone Duties of the Chief Executive Officer (CEO)
  1. Chief advocate for the move to the new enterprise system who ensures that the company fully understands the reason for the move to the new system, the organizational implications of that move, and the requirement to get on with it.
  2. Chief customer advocate who ensures that customer goals wind up at the top of the list for the implementation maneuver. 
  3. Chief advocate to the board and to investors.  The CEO’s goal should be to keep the Board of Directors informed, involved, and supportive of the enterprise system implementation, especially when the inevitable obstacles to implementation show up.
  4. Chief Communications Officer to the firm to explain the new organizational strategy represented by the implementation of the new system.  For many companies, moving to an enterprise system is a major shift in how the company will do its business.
  5. Owner of the program management office that will work day to day to support both the COO in user preparation and the CIO in technical implementation. The CEO, working through the program manager, must ensure that the implementation moves forward around, under, and through the day-to-day changes that will occur in the company’s business during the implementation.
  6. Major provider of resources and internal obstacle remover. In addition, the CEO must keep the ultimate budget and time clock on the implementation.
     
     
• Red Zone Duties of the Chief Operating Officer (COO)
  1. Chief User Preparation Officer, responsible that the user organizations are ready to use the new system just as technical implementation is complete.
  2. Works with the CEO and his program manager to understand what changes in work processes and plant/equipment and tools will be necessary to move to the new system. Leader in completing needed process changes and plant alterations.
  3. Chief Performance Officer. The COO and her direct reports will be the folks on the spot for organizational performance during the implementation and after the new system goes live.
  4. Day-to-day owner of the customer scorecard since the COO owns those parts of the organization that must be altered to produce the desired customer scorecard.
  5. Chief Performance Improvement Officer whose job it is to ensure that long-term performance improvement comes from the new connectivity capability of the enterprise system. 
  6. Leader in day-to-day teamwork of the executive team as it focuses on internal issues associated with the implementation.
     
     
• Red Zone Duties of the Chief Information Officer (CIO) 
  1.  Chief Technology Officer, ensuring that the technical implementation of the enterprise system is properly completed. Ensures that technical risks associated with the stysem implementation are properly managed and mitigated.
  2. Chief information technology strategist who ensures that the company’s technology strategy accommodates the new enterprise system.
  3. Works directly with program management and the COO to ensure that information technology resources are available for cooperating in user preparation, i.e., the provision of user training on the technical operation of the enterprise system.
  4. Works directly with the COO after systems implementation to ensure that performance gains from organization-wide use of the new system are realized, consolidated, and technically supported.
  5. Works directly with the CEO and CFO to ensure that the company metrics and scorecards for measuring results of the system implementation are in place. 

• Red Zone Duties of the Chief Sales Officer
  1. Key focus is on customer relationships during the enterprise system implementation. Responsible for key customer interaction and market impact.
  2. Responsible for ownership of the customer scorecard that should show how system implementation will add to the company’s value proposition with customers.
  3. Responsible for keeping the CEO and the executive team in sync with the marketplace during and after the implementation.
  4. Chief communicator to customers to explain how the system implementation will produce value for them. 
  5. Responsible for keeping the organization informed about the potential impacts that the system implementation is likely to have on customers.
     
     
• Red Zone Duties of the Chief Financial Officer (CFO)
  1. Leader in getting metrics in place to measure the results of the system implementation. Making adjustments to the company’s balanced scorecard as necessary.
  2. Assisting the CEO with the resourcing of funds needed to get the system implemented.
  3. Devil’s advocate for investment in the system.
  4. Works with the CEO and Human Resources Officer to ensure that monetary incentives are in place to adequately motive key organization members to successfully implement the system in the short run and raise performance levels in the long run.

• Red Zone Duties of the Chief Human Resources Officer (CHRO)
  1. Helping to find and identify the manpower needed for running the business while some of the company’s best players work system implementation and user preparation.
  2. Acts as the company’s Chief People advocate. Monitors stress and strain on the organization and recommends support to people as needed for Red Zone success.
  3. Leader in aligning employee performance management systems to use the enterprise system as well as changes in incentive compensation criteria.
  4. Works with the CEO and CFO to ensure that monetary incentives are in place to adequately motivate key organization members to successfully implement the system in the short run and raise organizational performance levels in the long run.
  5. Providing trained HR generalists to assist line management in preparing full use of the new enterprise system.

Not only is implementing an enterprise system the place for strong individual leaders with authority, it is the place for top-notch executive teamwork. While the tendency in many organizations has been to look at system implementation as solely the CIO’s game, the executive team must be absolutely together on this one.  Team building sessions with top management may be required to prepare for and execute the systems implementation, beginning with the sharing of due diligence information about the results of similar implementations in other companies and extending into the clear assignment of Red Zone roles for this maneuver.

This Red Zone maneuver is typically vendor intense. The implementing company will probably have extensive contacts with the system vendor, the systems integrator, and various training, documentation, and change management firms. The selection of the vendors and their ongoing management is therefore a critical part of the system implementation. My experience is that the best vendor management situations occur when that responsibility is given to the program manager who works directly for the CEO, thereby ensuring the single point of management responsibility needed to direct vendors and resolve the inevitable conflicts between them.

Red Zone Principle Three: Focus on the Customer
Nowhere is the customer more likely to be forgotten than in the implementation of an enterprise system. While the ability to better deal with customer transactions is usually one of the strongest reasons to move to an enterprise system, the implementation battle in the trenches is sometimes so difficult and intense that it is easy to forget the customer.

We believe that it is critical for the implementing company to complete a customer scorecard (like the one shown in Chapter Four) as a part of the design sequence of the implementation. The customer scorecard should show those attributes of the implementing company’s products and services that will be impacted positively by the use of the new enterprise system. Attributes like time to place an order, availability of information about placed orders, number of contacts needed to get order and status information are likely to be impacted immediately if the implementation is successful.

A customer panel can be used during implementation to ensure that the customer gets in his two cent’s worth about the value of the new system. Additionally, the customer panel becomes a ceremonial feature of the implementation that keeps customer value as the focus for the implementation. After all, if the new system doesn’t help the company serve the customer better, is it really worth all the implementation trouble?

Red Zone Principle Four: Set Clear Red Zone Goals
Three categories of goals are needed for effective guidance for an enterprise system implementation: technical implementation goals, user preparation goals, and business results goals. Goals for the technical implementation for the system are well understood by both information technology departments and the systems integrators who are frequently hired to assist in that implementation. Those goals usually revolve around implement timetables and budgets for the various modules of the enterprise systems to be implemented. Budgetary goals are critical for enterprise systems because the price frequently runs into the tens or even hundreds of millions of dollars. These technical goals are key to the effectiveness of detailed program and project management that will be discussed in principle seven.

It is also critically important to set goals for the preparation of those workers who will be the users of the new enterprise system. Frequently overlooked in enterprise system implementation, the user community must be prepared to use the new system when it is technically ready. The easiest and most effective goals here are related to time schedules for each user community or department. Obviously it will be critical for senior management to coordinate technical and user preparation goals to synchronize the implementation: technical systems are released for use just as users are certified ready to use them. In addition, senior management should set budgetary goals for user preparation. Guidelines range from as little as ten percent of the technical cost of the enterprise system to thirty percent, numbers that can easily run into millions of dollars.

Management must go beyond the typical enterprise implementation goals of “on time and on budget” to goals that describe what the enterprise system is to do for the company. I have seen two different kinds of results goals set for enterprise systems implementation. The first kind of goal focuses on the amount of dollars to be saved by use of the new system. I have found that kind of goal to be problematic, hard to measure, and easy to fudge. I prefer to add a second kind of result goal that focuses on some tangible measures of company performance that can have overall dollar impacts. For instance, in Chapter Four principle three, I gave a customer scorecard example that contained three attributes that could be made into implementation goals: time to place an order, availability of information about placed orders, number of contacts needed to get order and status information. An enterprise implementation that meets goals in these three categories will surely provide long-term value to the company.

The three kinds of goals - technical, user preparation, and results – must be coordinated to ensure there is good guidance for the management of the implementation. Obviously we do not want to meet one set of goals at the expense of the others, and we clearly do not want to forget that the real goal of the implementation of the enterprise system is to have a positive bottom line impact on the company.

Red Zone Principle Five: Blueprint for Success
The goal of the blueprint step in Red Zone system implementation is to build a compelling picture of the organization as it uses the new enterprise system to do the work of the company both differently and, hopefully, better that work is done now. The better and more complete the picture of how the organization is to work after the Red Zone maneuver, the better the firm’s chances of a successful implementation with full goal achievement.

The blueprint for an enterprise system implementation should clearly and precisely show the organization acting in several ways that are especially important for this Red Zone maneuver:

1. Using an industry standard enterprise system instead of the custom or proprietary system the organization may have been using before. The organization must understand that movement to an enterprise system is not a move to software that will be customized to meet the company’s every need. The point must be clearly made that the enterprise system may or may not be better for each particular situation than the company’s current system. The move to the enterprise system is all about getting connectivity between different parts of the organization and moving to a standard solution that will not call for in-house customization or applications development. 
2. Using the enterprise system to serve customers as shown on the customer scorecard and to meet the results goals.
3. Using the new system as an integral part of routine performance of work.
4. Use of the system by employees to transact employee business, if the enterprise solution has a human resources module.
5. Employees working together across the organization (connectivity)…both handling transactions and problem solving together for overall performance improvement.
6. Handling changes to the enterprise system, as in new releases, rather than having in-house customization and updating of the system.

Completion of the blueprint is the final step in Red Zone design that links customer scorecard, Red Zone goals, with the description of how the organization will need to look and operate after the implementation of an enterprise system.

Don’t Move! Don’t go to Red Zone execution principles until there is a clear picture of the improved business designs that will be created:

1. clear understanding of how the Red Zone system implementation will positively impact the customers.
2. clear goals for the maneuver in implementation targets and end results.
3. completed blueprint for the organization after the maneuver, as it uses the implemented system to do better business.

Red Zone Principles for Execution of an Enterprise System

The Red Zone execution principles for enterprise system implementation are especially critical since the Red Zone goals and blueprint are likely to represent a comprehensive and challenging change to the organization. It will take a lot of leadership horsepower in this execution phase.

Red Zone Principle Six: Focus on Mechanics
The goal of this step is to identify those mechanical parts of the organization that must be altered in order for the blueprint to come to life. Once again, those mechanicals are (1) work processes, (2) the plant, equipment, and tools needed to support those work processes, and (3) the performance systems that help focus employee behavior on those processes and tools. For an enterprise system implementation, identifying and altering the mechanicals can be a major and difficult operation. The difficulty of the needed alterations will to a large degree be dependent on how similar the organization’s current work processes are to those work processes incorporated into the ERP system. In all cases that I have seen, however, a significant number of mechanical changes in work processes are necessary for any enterprise system implementation.

1. Work Processes – the detailed steps the organization takes to do what it is designed to do. For an enterprise system implementation, the primary process task is to alter existing work processes in the company to match or align with those processes baked into the enterprise system. For example, an implementing company might have a purchasing process that requires staff workers to take specific data collection steps before initiating an automated purchase order within their existing purchasing system. Implementing a new enterprise system might require different data collection steps before purchase order initiation. Those different steps and the way the purchase order is generated in the new system constitute a change in work process that needs to be thought through, tested, written into procedures and placed into the training program that will be used with the procurement staffers.
   
   
2. Plant/Equipment/Tools – those concrete items that are used by the firm’s employees to support its work processes. In this case, the primary item is the enterprise system itself. For an enterprise system implementation, it is common these day to see other technical information systems being implemented in parallel, thereby complicating the overall implementation environment. For example, customer relationship management systems are frequently implemented along side the enterprise system.
   
   
3. Performance Systems – the organization’s collection of roles, goals, training programs, and incentive structures will need to change to reflect altered work processes that are aligned with the enterprise system.  Full implementation will require all workers who touch the new system to change some aspects of their roles and be trained in those new roles aspects using the altered procedures and the new enterprise system.
   

Red Zone Principle Seven: Use Program and Project Management to Build to Print
The job of the program manager, the right hand person to the CEO, should be focused on getting two things done at once. Program management works to ensure that the enterprise system, and any other technical systems accompanying it, is successfully implemented from a technical point of view on target, on time and on budget. Program management also must work to ensure that the users of the new system or systems are thoroughly prepared and are ready to put the new system into play just as it is ready. Accomplishing both tasks in parallel not only involves a great deal of planning and day-to-day supervision but working across many organization lines with technical and user communities who have different missions and priorities.

The projects that make up the enterprise implementation program are best organized around technical systems and user organizations to be impacted by the new system(s). Some cross functional membership will be useful in the project organizations. For example, the technical project team focused on configuring and implementing the enterprise system should have some user personnel on or assisting the technical work to ensure the presence of the user perspective. The user preparation projects are designed (1) to get user work processes altered and aligned with the technical system and (2) to alter user roles and responsibilities and to provide work process training as it would need to be done with the enterprise system. User preparation cannot go forward successfully without intense communication and coordination with the personnel who are at work on the technical projects.

Once the enterprise system has gone live, program management must shift its emphasis to exploiting the new system for company advantage. The projects that make up the enterprise exploitation program are best organized around organization-wide work processes that serve internal and external customers. Cross functional membership is a requirement on project teams designed to find better ways for the organization to work together by using the new system.

Program management should stay active until top management is satisfied the results goals of the implementation have been achieved. At this point, program management can be discontinued until the next hurdle for the enterprise system. And that next hurdle will be implementing the subsequent releases of the enterprise software that company management decides will be of value. In other words, the software vendor who designed and built the enterprise system will always be actively improving the system to provide greater functionality and actively trying to sell those new releases to its current customers. In practical terms, some program management functions barely complete one cycle of system implementation and exploitation before top management decides to implement the next purchased release. Implementing a new release may or may not be another Red Zone, depending on the amount of process change built in the system. Buyer beware.
 
Red Zone Principle Eight: Focus on Speed
Since the goal of enterprise system implementation is to allow the company to operate in a more connected way, the sooner the system is implemented and exploited the better. Time frames for implementation of enterprise system frequently run 12 to 24 months for the system selection and technical implementation. That means that at the end of that time period, the company has a system that works technically. If the user community has been successful readied in parallel, the company will have a new system up and running with what amounts to rookie users. Depending on the enterprise system, some benefits to the implementing company should be available immediately. However, to gain the long-term value desired by the organization will take another six months to two years of hard work as users cooperate to find ways to exploit the system for customer and company value.

The CEO has a big job as she holds the time clock on this Red Zone maneuver. Many organizations are so fatigued by the implementation itself that they tend to back away from the work to exploit the systems once the go live point has been reached. The CEO’s job is to keep the organization at work to figure out ways to exploit the system to get what many call the second wave benefits.

Red Zone Principle Nine: Meet Special Needs of Workers
The special needs of workers who are a part of a Red Zone strategy change are rooted in the fact that they are frequently sprinting a marathon. Implementing an ERP strategy takes intensive effort for a long time, and workers wear out. Important consideration for workers during this Red Zone include:

1. Making sure that workers on Red Zone project teams have someone covering for them in their regular jobs,
2. Ensuring that project personnel have job protection (i.e., ensuring that employees still have choices that are acceptable to them about the kind of work they do for the company. In many cases, personnel on implementation project team become so familiar with the new enterprise system that they are kept on system duty, not given the chance to return to their regular jobs),
3. Taking special care of workers might need to be balanced with taking special care of the organization in the case of this Red Zone. Turnover can be a problem with this Red Zone maneuver as workers leave to exploit their new enterprise skill sets and market value. 

Red Zone Principle Ten: Reward for Red Zone Performance
Incentives for this Red Zone maneuver must drive off the accomplishment of the goals set for the maneuver. Care must be taken to not only incentivize the accomplishment of short term technical and user preparation goals but to put important incentives behind the accomplishment of long-term results goals.

Top management must use good judgment in sizing the incentives that will be available and in detailing the criteria that will be judged for reward. The offered incentives must be large enough to get the attention of Red Zone players but not so large that those players will kill anything or anybody to get to the dollars. The criteria for award of incentives must be several in number and to some degree conflicting. For example, criteria for payment of an implementation reward to the technical project manager should include not only implementation schedule and budget but adequacy of cooperation with the user preparation project manager. Failure to add user preparation criteria could result in effort solely directed to the technical go live at the expense of the rest of the enterprise program.

Click here to return to Holland & Davis Specialized Services

To engage in an initial conversation about your ERP Implementation needs, please call Gary Skarke at 713.800.3663. I am confident we will learn something from you and hopefully you will learn from us too!