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.