The 'Joy' Of Enterprise Systems Implementations Part 3: Causes of Failures
Written By: Predrag Jakovljevic
Published On: July 2002
'Joy' Of Enterprise Systems Implementations
- July 11, 2002
Part 3: Causes of Failures
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
is a four-part note. Part
One summarized a report titled ERP Trends by The Conference Board.
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.
Causes of Ill-fated Implementations
Some other causes
of ill-fated implementations and/or poor live system performances worth
pointing out would be:
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,
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:
order still appears in the system as unfulfilled,
actual and the inventory in the system are out of sync, and
invoice cannot be sent without the order being completed through
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".
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
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
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.
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.
concludes Part Three of a four-part report. Part
One summarized a report titled ERP Trends by The Conference Board.
Two commented on the major Key Success Factors. Part Four makes User