The 'Joy' Of Enterprise Systems Implementations Part 2: Implementation Key Success Factors

The 'Joy' Of Enterprise Systems Implementations

Part 2: Implementation Key Success Factors
P.J. Jakovljevic - July 9, 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. This part comments on the major key success factors (KSF's) for enterprise applications projects and on the causes of enterprise systems implementation failures. Part Three will continue the analysis. Part Four will make 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 enterprise system 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 return calculate the investment (ROI) for an implementation. The situation is not much easier in case of system upgrades despite the attractiveness of expanding new functionality frontiers, as the battle to get all the applications inside and outside the enterprise work together rather than to merely automate parts of the business within the four walls.

The main enterprises' interest today is in systems that make interactions between trading partners more efficient and that contribute to bottom-line betterment. To that end, new functional areas beyond core ERP (but increasingly provided by many ERP vendors as well) such as e-procurement, portals, business intelligence (BI)/analytics, web self-service, etc. offer a promise of increasing supply chain efficiency and customer service.

In any case, 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. Consequently, the buy-in of the users that have the stake in operational success of the system is crucial as well. It is important to assign responsibilities and rewards to staff members who both have a good grasp of the technology and the intimate understanding of the company's business requirements and processes.

Otherwise, as a result, outside consultants will 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 consultant's departure. Therefore, enterprises that hire consultants/system integrators for an implementation/upgrade projects must ensure open channels and candid communication. Any problems with the business objectives, deadlines, project scope should be brought to light promptly as to avoid endless disputes after the event.

Project Plan/Managing Expectations is Crucial

The lack of 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'. Still, a limited number of customizations may be necessary as to accommodate critical differentiating business practices, and no vendor can provide out-of-the-box solution to all businesses. For more modifications' rationale and caveats, see Should You Modify an Application Product?

A compromise might work the best implement the new system with minimum necessary modifications and see how vehemently users demand/complain down the track. Often, implementing/upgrading an enterprise system offers a good opportunity for enterprises to review their key business processes and resources. An enterprise system is only a means to an end - management of complex business processes (including streamlining redundant processes) to improve profitability, productivity and efficiency.

Thus, because developing a plan to determine how the implementation/upgrade will affect the company is likely the most important part of the project, it should be assigned ample time and attention. Staff scheduling and careful stocktaking of necessary customizations are essential to the project success. Process standardization across like units at dispersed locations and the unification of data coding system (e.g., part numbers, chart of accounts numbers) should typically increase the system effectiveness, and should be paid due attention at this stage as well. In any case, the imposed changes to well-accustomed business practices will require change management to handle employees' resentment of new business practices and likely reorganization.

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 web-based components recently increasingly referred to as Web Services (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. Often projects involve a pilot implementation that allows the company to make sure the future system will match well the set of business processes. This in turn should build momentum, prove the concept and benefits, and consequently garner support and enthusiasm from other departments and top management. The case is somewhat different in case of product upgrades, where the Big Bang approach may be beneficial (i.e., less expensive and shorter) due to the consistent effort required in planning, system installation, and data migration phases regardless of the project scope.

Fast-path as an Alternative

Another approach would be to opt for vendors' rapid (fast-path) implementation tools and programs, with all-too-familiar accelerated' or fast-forward' monikers, bearing in mind the potential benefits but also 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 a 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 screen 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 silos, 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).

One should only imagine the magnitude of intricacy in case of implementing business processes that span across different enterprises and that are dependent on users over which the client enterprise has a little (or not at all) authority. Collaborative business is awfully complex and what business scenarios are well supported will depend on the commitment and involvement of all trading partners in case. Progressing software transactional to business-process management (BPM) within heterogeneous intra-enterprise environments is quite intricate and a time-consuming exercise for any vendor, system integrator, and, needles to say, any client organization.

Apparently, in addition to carefully studying their own capabilities, companies should also carefully scrutinize those of their business partners. An example would be a company that did implement Web self-service without assessing the preferred channel of communications of their customers, some of which still did not have Web access.

To make things worse, training and system testing typically happens at the end of implementation, often immediately before going live, when it is too late and everybody feels stressed. Needles to say that, due to the mission-critical nature of the enterprise systems, they should be thoroughly tested and put through their paces before being fully deployed; of course, not on dummy, sandbox data, but rather on actual data from specific real-world business scenarios. A manufacturing company should, e.g., invoke past orders from customers and route them again through the entire workflow from designing the product, passing it onto production, delivering it, and billing for it.

Furthermore, as enterprise systems typically outlive the IT employees and project members that conceptualize, implement, and modify systems on the go, documenting the system is also crucial so that future users grasp quickly the business process rationale behind the system. Documentation is also needed for future product updates, extensions and collaborative systems integrations that the future will inevitably bring. Finally, the documentation may demarcate the area of responsibility and the scope of engagement for all involved parties (the customer, consultants, and the vendor).

This concludes Part Two of a four-part report. Part One summarized a report titled ERP Trends by The Conference Board. Part Three will continue the discussion of the causes of ERP implementation failures. Part Four will make User Recommendations.