One year ago my company embarked on an enterprisewide implementation, selecting an ERP system and a suite of software to address our primary business functions. This decision was not made lightly. Lestornia Lighting is a $120 million manufacturer of commercial and industrial lighting fixtures and components (e.g., sockets, lampholders, wiring harnesses, reflectors). We've grown incrementally over the past two decades, and our business practices and processes — and the information technology (IT) that supports them — has grown piece by piece as well. I finally concluded that the Frankenstein IT infrastructure we had cobbled together needed to be destroyed. Now I greatly regret my decision.
Literally from the outset of our enterprise implementation, the scope of functionality, customizations, and departments and personnel engaged in the effort have spread like wildfire. Lestornia expected to be operating with our new systems six months ago; now we cannot get a projected date for when we will hit the switch. The escalation of costs specific to software licensing and the implementation have blown beyond anything I'd ever imagined. And with the infectious spread of applications and department-specific functionality and customization, our training and maintenance costs are doubling by the day.
I swear that every person in the company is working on this system and software implementation in some way or another, and no one is focused on making lighting products or focused on our customers. I am afraid that this project will, quite simply, kill Lestornia before we ever see a dime of return from our investment. How can we subdue the new monster we've created?
* The Challenge incorporates hypothetical persons, companies, and products and does not portray the actions of any actual persons, companies, or products.
By Kevin Hume
The Lestornia Lighting scenario is more common than you might expect in this age of technology salvations like "zero mod" installations, model-driven configuration tools, and service-oriented architecture.
Despite technological innovations, organizations still have a propensity to underestimate the impact of good design fundamentals. Key design fundamentals critical to ERP deployment include a solid grasp of operational best practices, business process design, and an experienced design team capable of applying the best practices within the context of the business processes.
I've seen many situations similar to Lestornia in which millions of dollars have been spent, yet the software is nowhere close to production — and meanwhile the costs continue to mount as "the monster" just keeps getting bigger. A common culprit in these ERP deployment nightmares can be traced back to an inexperienced design team attempting to replicate legacy processes within a new software environment. But before we go down that path, lets take a look at the entire process.
How did Lestornia get here?
Let's first take a look at the initial software selection process. Many legacy ERP organizations tend to rely heavily upon the existing users and support community to participate in the selection process. While a solid understanding of past and current business processes and technology is certainly necessary, it's only of limited value within a new software application and associated business process design.
The most important aspect of the ERP selection process is to identify the critical business processes, measure them against industry and your own best-practice experience, and then determine the ability of the competing ERP products to meet those requirements with minimal to no modifications.
Typically, competing ERP products can be "scripted" one against the other to get a good feel for which applications can best support your critical business process goals with minimal to no customization efforts. Once you have identified the ERP product that can adapt to your critical business process with minimal to no modifications, in post-selection design sessions a larger team can focus on the remaining, less-critical business process re-engineering.
So what went wrong with Lestornia?
Lestornia selected its ERP application, began the design-configuration process, and now you find your company one year down the road and six months behind schedule. Now what?
The deployment effort is at the tipping point. It is time to carefully examine the financial and business risks and decide whether to trudge along with the original plan or consider throwing out the incumbent and starting over. Or, like many organizations I've seen in similar situations, do you simply fold up the project, accept defeat, and go back to the legacy system, effectively kicking the can down the road for another management team to tackle at a later date?
In the case of Lestornia, let's assume the business risk of going back to the old legacy system (obsolete technology and skillsets) is not a feasible option. Let's also assume the selection team did an appropriate job of highlighting the critical business functions and selecting the best ERP solution that can adapt to the Lestornia requirements.
Typically, when you see a lot of customizations, expanded scope of the application, blown budgets and timelines, etc., it's because either:
- The company selected an ERP product with relatively little deployment experience within its industry (knife to the gun fight syndrome), or
- The company has a lack of leadership and limited best-practice experience within the design teams, resulting in legacy processes being replicated/invented in the new ERP application (the shoehorn syndrome).
Design team leadership and business process design validation is an area in which a third-party integrator, familiar with best practices and past experience within a particular industry, can provide immense value during the detail design phase of an ERP integration effort. The integrator can provide insight far beyond the team, who may have only limited exposure to business process alternatives beyond their own company.
Additionally, the integrator has the ability to build consensus among the business processes and information technology contingents by helping to strike a balance between technology or business expedient solutions. This results in process configurations in the best interest of the overall system design.
The integrator, armed with the critical business processes, can force hard questions to be answered up front during the initial design sessions, rather than after a costly cycle of software configuration, and can circumvent the proverbial can-kicking process evident in past ERP deployment failures.
How does Lestornia's story end?
You recognized the shortcomings of Lestornia Lighting's implementation partner. You've also recognized your company's own shortcomings during the implementation process. Specifically, you've recognized that your own team did not push hard enough for alternative business process designs that could be supported with minimal customization. Most importantly, you've recognized how critical an integrator is to migrating business processes that balance the needs of the business within the context of the ERP software.
This is how Lestornia's story can end. You stop the deployment effort, reconvene the original selection team, and identify the critical business processes that require the most customization effort during the initial deployment.
Armed with this critical business process analysis, Lestornia identifies and evaluates several other ERP system integrators purporting to have successfully deployed solutions within the lighting industry. Then you offer a compelling opportunity for these integrators to succeed where a competitor had failed. As a result, Lestornia should be able to drive contract terms and limit their payments until a configured and user-accepted system is delivered and ready for release into production.
Your story ends with a successful ERP deployment six months later — one in which the re-engineered, best-practice driven business processes resulted in operational savings that exceeded the original savings projections.
Kevin Hume, a principal at Tompkins Associates (www.tompkinsinc.com), analyzes processes, systems, and equipment for supply chain optimization, and is a pioneer in the field of Internet retail fulfillment. He also writes for the Supply Chain Information Technology Perspectives Blog. Tompkins Associates designs and integrates value-based, end-to-end supply chain solutions and focuses on growth and business strategy, global supply chain services, distribution operations, information technology, material handling integration, and benchmarking and best practices.
By Monique Rupert
Lestornia Lighting is experiencing what many companies experience when implementing a large enterprisewide software solution. ERP software vendors generally design their suites and associated modules to meet the needs of a wide variety of businesses. Accordingly, each suite and module provides specific functionality. Companies choose their suites and modules to meet their functional needs — as they understand them — during the selection process. This approach provides great flexibility, but also contains many pitfalls for the unaware (i.e., Lestornia Lighting).
Modules and suites are flexible in that that they can be added together and interchanged to create an overall solution, but they are inflexible in that they are limited to their respective functionality and are not always easily customizable. Hence, companies that initially believe they are purchasing an "out of the box" solution, instead find, during the implementation, that they either have to purchase additional modules or engage in lengthy and disruptive customizations. And once the company does go live, there is typically poor user adoption due to the overall complexity of the system and high ongoing costs to maintain their highly customized solution.
Lestornia should now take a hiatus in its project, and go back to the drawing board to rethink what it is you are trying to accomplish. I would propose the following seven steps:
Step 1: If you are implementing a full ERP suite (human capital management, financial management, supply chain management, customer relationship management, etc.), you should make a priority list of top business problems that are prohibiting you from being successful at Lestornia's core business, which is to make lighting products and focus on your customers.
Step 2: Take those top business problems, prioritize them, and architect a multiphased plan to address those problems. For each phase, set specific, realistic goals and key success criteria so that a project can be completed within four months and results can be measured. A smaller, focused effort has a much better chance of success. This approach will also consume fewer company resources at any given time.
Step 3: Assign an executive sponsor who is empowered to resolve any issues and roadblocks that might prevent on-time completion of the project. This person also has the authority to assign resources.
Step 4: Assign subject matter experts to the project who understand the business, are forward-thinking, can make effective decisions, have the respect of others in the organization, and can dedicate enough time to complete their tasks.
Step 5: Stay flexible! These types of projects naturally require some deep thought. Inevitably, some of the original assumptions on scope may be incorrect, and the natural tendency is to allow scope creep. Some scope creep is natural, however, if there is more than a 15% to 20% increase in scope, someone needs to question what is happening. As you proceed, create a list of scope items for future phases, enhancements, wish lists, etc.
Step 6: Create an accurate test plan that covers all possible use cases of the system. Too many times the creation of a test plan is left to consulting partners, and, of course, the consulting partners do not fully understand every possible scenario your company may face. Be sure to dedicate the right people who understand the business to build all possible use cases, and then take the time to execute the test plan thoroughly.
Step 7: Make sure the end users are involved in every step of the project. Many times the end users are brought in only to perform user-acceptance testing and attend end-user training (not at the beginning of the project). This can lead to poor understanding of what is to be accomplished, lack of understanding of functionality, and, ultimately, poor user adoption. If Lestornia wants to ensure good user adoption of the system, it will put in place a change management process that educates and incorporates the end users throughout the process.
If Lestornia is able to refocus on smaller, more realistic objectives, it should be able to get something live and see some business benefit. But as mentioned, Lestornia and other companies should really first determine whether they need to go down the path of the ERP software solution to meet all their needs. Sometimes a mix of ERP and best of breed can work effectively, particularly in the supply chain/manufacturing world due to the complexity and cost of ERP solutions in that area.
Monique Rupert is vice president, professional services at Kinaxis (www.kinaxis.com). With more than 15 years of professional services experience, Monique leads the company's deployment, training, and consulting-services teams for North America and Europe with a mission to ensure customers maximize the value of their investment in the Kinaxis™ RapidResponse™ solution. A primary focus for Monique is supporting the company's expanding customer base through the development of scalable services backed by a strong partner ecosystem. To this end, Monique works closely with the Alliances group in successfully engaging strategic partners to help deliver consulting and integration services as the company continues to aggressively grow its business. Monique previously held executive positions with PeopleSoft, Lawson, Andersen Consulting, and Price Waterhouse. She can be reached at mrupert@kinaxis.com