ERP Trivia - Every Why Should Have Its Wherefore Part 2: ERP Key Success Factors

Part 2: ERP Key Success Factors
P.J. Jakovljevic - August 29, 2001

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 the mass audience owing to exorbitant subscription fees, has recently been confirmed in a more tangible manner. Namely, many major companies are having difficulty achieving effective enterprise resource planning (ERP) even after a full year of implementation, according to the report titled ERP Trends (Research Report 1292-01-RR) and released at the end of June by The Conference Board, the premier business membership and research network worldwide, which links executives from different companies, industries, and countries.

About this note:
This is a three-part note. Part One summarized a report titled ERP Trends by The Conference Board. This part comments on the major key success factors for ERP projects and on the causes of ERP implementation failures. Part Three contains User Recommendations based on this information

Key Success Factors 

As long suspected and hinted in the past, the report confirms that the compelling business case and the management's commitment are the major key success factors (KSF). These are, furthermore, mutually causal. For the project to get the commitment of the likes of a CEO and thereby have the best chance of success, he/she must visualize the ERP implementation as improving the attainment of certain business objectives.

That, unfortunately, has not often been the case in the past - deceived by the technology siren song (for more information, see The "Old ERP" Dilemma: Replace or Add-on), many companies have failed to construct a tangible business rationale, let alone calculate the return on investment (ROI) for an implementation. Top management's frivolous approach quickly gets revealed and the attitude cascades down the hierarchy. The promise of helping everyone within the organization improve his or her objectives then degenerates into a software implementation trudge dominated by the IT department. Anyone who felt left out will, intentionally or not, demoralize the success of the project by simply going through the motions.

Retaining Ownership

Further, it is crucial that the use of consultants does not mean that the company loses "ownership" of the project. Very often the company, not realizing the importance of a full time project leader and the project team, does not release them from their obligations in their regular positions. When their administrative duties get too demanding, the implementation commitment is the first thing to go. Often, as a result, outside consultants have to slog through the most mundane tasks like data capturing/cleansing, which were contractually assigned to the customer's team and blatantly shirked by these. The consultants' thinking has been that the overtime work was a lesser evil than the ensuing finger pointing in case of a missed 'go live' deadline and the budget overrun. One should only imagine the fate of the live system in the hands of highly indifferent end users after the consultant's departure.

Project Plan is Crucial

The lack of a well devised, realistic and thorough project plan with the rationale why the software is being implemented, what parts of business will be affected and how, and how long it will take, was also cited by the report as the main reason of dissatisfaction. The lack of a sound plan also leads to another common implementation problem - the dreaded scope creep. Instead of limiting the applications functionality and project scope, the companies let eventually awakened and project engrossed users suggest modifications on the fly that rapidly eat up project budget and time. Often, these modifications are required only to replicate the existing (probably ineffective) legacy processes since that is 'how the business has been run for ages'. For more modifications' caveats, see Should You Modify an Application Product?

Avoid the "Big Bang" Approach 

The so called "Big Bang" approach, that is, rather than moving to the new system one component at a time, doing it in one fell stroke, has also been attributed to a number of failed implementations. Until recently the approach has virtually been mandated by the prevalence of monolithic ERP products. Now the trend is to deliver the products as components and web-enabled (see Where Is ERP Headed (Or Better, Where Should It Be Headed)? Part 2: Product Architecture and Web-Basing).

Many companies nowadays start out thinking in terms of a Big Bang, but later decide to follow a "phased" approach, in which new parts of the system are introduced incrementally. This more cautious strategy allows system bugs to be found and corrected before moving on to the next phase, while reducing the shock to the users that inevitably accompanies new corporate-wide system implementations. Big Bangs are misleading in their promise of "once and it's done" benefits as investments made to remedy problems can quickly outweigh anticipated savings.

Companies are adopting an incremental approach and starting with the mature modules that need the least customization. This in turn should build the momentum, prove the concept and benefits, and consequently garner support and enthusiasm from other departments and top management.

Fast-path as an Alternative 

Another approach would be to opt for vendors' rapid (fast-path) implementation tools and programs bearing in mind the potential ramifications of using them (see Fast-path Implementations - Are They Good or Bad?).

Use Competency Centers for Maintenance

Reportedly increasing deployment of "competency centers" to manage the maintenance and support of ERP environments indicates another important people issue - ongoing appropriate training and the promotion of IT departments into enterprise knowledge systems rather than mere data processing centers. Time and again people who have implemented systems, even with the successful outcome, claim they did not have a sufficient level of understanding of either the software or the underlying business processes and procedures needed to work in an integrated environment.

What has typically been referred to as training has proven to be useless - too often companies fall in the trap of training employees how to navigate screens or 'which field or button does what' instead of boosting their ability to realize the underlying flow of information through business processes. ERP systems, in fact, are devised to operate by codifying a set of business processes and employees have to learn the whys, wheres and whos of the business process (workflows) rather than hows of the software screens. Without learning the whys and wherefores of the process, users retain their pre-ERP mindset, which is quite detrimental in an interwoven ERP environment (when, e.g., a sales order clerk does not understand the implications of his/her transactions on the other users of the system).

To make things worse, training typically happens at the end of implementation, often immediately before going live, when it is too late and everybody feels stressed.

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 the 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).
  
  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 that all but overwhelms the customer. 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 the 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. Some vendors have even 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. In essence replacing the system with a better suited product (see, SAP sets up Apparel and Footwear team).
  
  Also not uncommon is the case when the software has strong functionality but imposes 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.
  

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.

This concludes Part Two of a three-part report. Part One summarized a report titled ERP Trends by The Conference Board. Part Three contains User Recommendations based on this information.