The 'Joy' Of Enterprise Systems Implementations Part 3: Causes of Failures

The 'Joy' Of Enterprise Systems Implementations

Part 3: Causes of Failures

P.J. Jakovljevic - July 11, 2002

Executive Summary

What has long been a general feeling based on rumors, news headlines and some casual survey reports hidden within analyst houses' vaults and largely inaccessible to mass audience owing to exorbitant subscription fees, has recently been confirmed in a more tangible manner. Namely, many major companies are still having difficulty achieving effective enterprise resource planning (ERP) systems even after a full year of implementation, according to the report titled ERP Trends (Research Report 1292-01-RR) and released several months ago by The Conference Board, the premier business membership and research network worldwide, which links executives from different companies, industries, and countries. The general feeling is that the situation can be mirrored across the entire enterprise applications space.

This is a four-part note. Part One summarized a report titled ERP Trends by The Conference Board. Part Two covered the major key success factors (KSF's) for enterprise applications projects. This part discusses the causes of enterprise systems implementation failures. Part Four will make User Recommendations based on this information.

Other Causes of Ill-fated Implementations

Some other causes of ill-fated implementations and/or poor live system performances worth pointing out would be:

• Lack of system discipline, which can be illustrated in many ways. One is inaccurate data in the system owing to users tardy updates or inaccurate initial data capturing. Experience has shown that at least 98% of inventory records, bills of material (BOM) and routings (operations) must be correct to make the system capable to control the business. Other information must be similarly accurate (for more information, see Business Basics: Unscrubbed Data Is Poisonous Data and A CRM System Needs A Data Strategy). Even after a system is fully deployed, data gets contaminated due to aging (e.g., employees and trading partners change their address or other fields of their profile), and an ongoing effort needs to be instituted to prevent data from metastasis-level of obsolescence. The situation's complexity multiplies when many disparate systems with their own data systems are integrated.
  
  Another example of bad discipline would be the continuation of physically conducting business while circumventing the system. Often, there is an instinctive middle management urge to, for example, hastily ship goods to customers in order to preserve future sales, without necessarily logging it through the system. The consequences are multi-detrimental:
  
  
  1. the order still appears in the system as unfulfilled,
     
     
  2. the actual and the inventory in the system are out of sync, and
     
     
  3. the invoice cannot be sent without the order being completed through the system.
  
  The irony of life lies in the fact that, since no one can then trust the data in the system and physically checking on the shop floor and/or in the warehouse the whereabouts of the order is the only reliable way to trace the order status, these culprits even get the ammunition to disparage the use of system since "it was much better when things were done the old, manual way".

• An application does not meet the business requirements. One extreme example would be too "feature rich" (i.e., complex) system imposed by the top management that all but overwhelms and alienates the users. Outside consultants who do not truly understand the business then have to figure out how the package should be mapped to the business processes. This often means automating the current, likely non-optimized business processes in a manner of "digitizing the dinosaur". Not to mention the significance of the client's non-existent ownership of the project.
  
  Another example would be an attempt to fit a square peg in a round hole, like in the case of implementing a make-to-stock (MTS) environment supporting ERP system within the make-to-order (MTO) environment, which we had the displeasure of witnessing in the past.
  
  One in the myriad of appalling consequences of the implementation was the lack of a product configurator facility with generic items (with options, variants and constraints), generic BOMs, generic routings and pricing functionality. As a result, the sales order capturing clerk has to wait sometimes for days for the response from the engineering department regarding the product code and the price/cost. Needless to say the standard master data was bloated because each product variant had to have a separate stock item code, BOM and routing as if it was a standard stock item and not a once-off made customized product (e.g., with a special color).
  
  As a result, the company had to literally close down the operations so that the entire place can participate in a dreaded stock taking exercise, with an item master printout as thick as encyclopedia and with less than 10% of listed items expected to be stocked. This is without considering the likelihood of identical products having a number of different item codes, as different people created these unbeknownst to each other.
  
  Consequently, there has been a growing cognizance of the importance of vertical industry focused products. Software that combines industry-specific functionality with the flexibility to accommodate each company's unique processes goes a long way toward improving the functional fit and the speed of implementation. A vast majority of vendors have lately recognized the need to go back to the drawing board and redesign certain vertical solutions after their customers had serious difficulties using the existing ones.
  
  Also not uncommon is the case when the software has strong functionality but imposes the limits on a customer owing to its inflexible architecture. As every business is of a dynamic nature, the best assurance that the selected system will accommodate the changing business needs in the future is to make sure that it has built-in flexibility through, for example, switches, options or components (for more information, see Great Product: Too Bad The Architecture Doesn't Fit).

• Departure of the project sponsor in the midstream. The average tenure of C-level executives appears to be about four years. With large implementations lasting close to two years on average, there is a high risk of a change of management during the implementation, seriously disrupting the implementation. An even more likely occurrence is that the management that selected the system has left the company by the time the system is implemented and questions about the rationale of choosing the unsuitable system have started flying from all directions.

• Deterioration of supposedly well-implemented system, over time. For all the above reasons, and because it is human nature to disregard and put into oblivion all but a few mundane, repetitive practices, many enterprises systems gradually lose' their natively provided functionality, as users revert to previous workaround and sub optimal practices. For more information on this phenomenon, often referred to as application erosion', see Application Erosion: Eating Away at Your Hard Earned Value and Application Erosion: More Causes and Cures.

Last but not least, the report shows that the best-of-breed concept still has a large appeal, particularly within the higher end of the market where heterogeneous, multi-vendor corporate systems are the reality. For more information on pro et contra of this implementation concept, see Single Source or Best of Breed --The Debate Continues and Standardizing on One ERP System in a Multi-division Enterprise.

This concludes Part Three of a four-part report. Part One summarized a report titled ERP Trends by The Conference Board. Part Two commented on the major Key Success Factors. Part Four makes User Recommendations.