Strong Technical,
Systems Programming/Database Administration (DBA) Capabilities Are
Needed, at Least for a System as Complex and Flexible as Oracle
There are numerous
tables, parameters, and security to set up and maintain, software
versions and patches to control, for various system and database
"instances." A good DBA is also a consulting resource to IT, users,
and management.
Conventional wisdom
says that modern software packages take most of the technical risk
out of an implementation. Conventional wisdom is incorrect. Unless
we tackled technical issues head on, such as system setup,
multisite definition, library/version control, conversion, etc., it
would have meant trouble. Technical factors became a non-issue
precisely because we did apply the resources to deal with them.
We relied heavily
upon outside resources in the beginning and gradually tapered these
off as we built the skills in-house. We need to continue to broaden
the skills base to ensure that multiple in-house employees can
handle critical technical tasks, a common aspiration in mid-sized
Information Technology departments.
The company was
successful in building an effective Oracle RDBMS/UNIX/Oracle Apps,
technical capability, scaled appropriately for maintaining a
"vanilla" version of the system. It took more people than we would
have liked.
Ensure Data
Accuracy
Formal ERP systems
are very sensitive to data accuracy. We had to make big improvements
prior to implementation. Even though our outside auditor blessed our
overall numbers prior to implementation, these still did not meet
our far more rigorous internal standards. We are only now
approaching world-class standards in most areas, but actually
slipped in one area after a reorganization, spurring a rededication
to data accuracy. In the future, we will conduct rigorous quarterly
internal inventory accuracy audits and look at other areas as well.
We are simultaneously trying to reduce dependency on formal data
accuracy by moving to more visual control approaches and quick
reaction systems.
Minimize Software
Modifications
Everyone we knew in
other companies making major changes to a software package ended up
spending huge amounts of money and time and often had maintenance
and operational problems. We learned from their experiences, made
minimal changes, and had minimal problems.
Control the Scope
Although there were
people who wanted us to do a lot more, most of us agree that scope
control helped to get the job done cheaper and faster than it would
have otherwise. It would have really stretched things out and
jeopardized the results if our plate had been even more full than it
Have Contingency
Plans
After seeing and
hearing about others' past disasters, we developed a contingency
plan for what to do if the implementation failed, and what to do
when the system crashes—for an hour, a day, a week, or longer. There
is also an alternate backup site in place. We can always improve
with an ongoing readiness audit.
Have a Go/No Go
Decision Point
We did it and are
glad we did. We waved off the implementation date twice because we
wanted additional preparation. By the third time, we knew what to
look for, knew what we needed, and, to some extent, even knew what
it was we didn't know. We made a list of the outstanding issues that
had to be resolved before we would go live with the implementation
and worked them hard, as a team. A couple of months' delay is
insignificant compared to years of pain from a failed
implementation. Never implement until your people are confident and
ready.
Other
A few additional
hints—Don't put up the latest version of the vendor's software, no
matter how they praise its virtues. Major ERP packages are never
perfect—ESPECIALLY major new releases. Let others debug it for you,
even if it means waiting a little longer for some bells and
whistles. We took the conservative route and avoided much agony.
Make sure you have key management reports in place before going
live. We didn't have them all and paid the price. Make sure a
critical mass is trained in report writing. We didn't, but when
offering training the second time around, classes were "sold out"
immediately. Don't scrimp on hardware resources. You'll get punished
more for bad system performance than for spending too much on
hardware. Once we eliminated a few bottlenecks in testing,
performance became a non-issue. Establish specific systems
performance objectives, get commitments to them in writing. Reward
contributors any way you can—with praise, training, coveted team
assignments, promotions, etc. Your good people are your finest
asset.
EPILOGUE
The new system went
live on 4 January 1999 and we never looked back. There were only two
serious problems. (1) Bugs in order entry slowed us down. Better
testing and documentation of results would have mitigated this
problem. (2) In addition, an administrative problem resulted in a
number of blanket vendor purchase orders not being put on the system
for weeks, screwing up purchasing and inventory records for the
duration.
We had our first
major system crash in March 1999. Recovery procedures took nearly a
day, but restoration resulted in zero lost data, using the
task-level recovery features of the system.
We have lost some key trained talent and are trying to improve our
successor-ship and training management.
The reengineering
effort seems to be more of a gradual, continuous improvement
approach. It needs to move faster. This will take more emphasis and
rededication. There are lots more things that we can do to improve.
Other important projects seem to present even better opportunities
at this time.
More importantly, "the vision thing" is back and sales and profits
have been great. The system is working and helping to provide a firm
foundation for the new century!