ERP Trivia - Every Why Should Have Its Wherefore Part 2: ERP Key Success Factors
Written By: Predrag Jakovljevic
Published On: August 29 2001
ERP Trivia - Every Why Should Have Its Wherefore
2: ERP Key Success Factors
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.
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
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.
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
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.
Plan is Crucial
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?
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).
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.
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.
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?).
Competency Centers for Maintenance
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.
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).
make things worse, training typically happens at the end of implementation,
often immediately before going live, when it is too late and everybody
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 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,
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:
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
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 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
Product: Too Bad The Architecture Doesn't Fit).
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.
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.
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.