Successful Implementations

I would like to call your attention to a recent article on ERP implementation problems. The full text is available at:

www.cio.com/archive/060100_erp_content.html

This is a very harsh article, entitled "ERP Training Stinks", and details such horror stories as SAP and PeopleSoft go-live failures (Hershey Foods, Whirlpool, Allied Waste, W. W. Grainger, and more).

The article does make useful suggestions as to how to avoid these problems, but unfortunately scatters them throughout the article, instead of making a list of ideas.

From my own experience, I would recommend that companies facing initial implementation, major upgrade, or new staff retraining, note the following. Some of these concepts are more pertinent to an initial implementation or purchase, and some more to upgrades, but the themes are the same.

The CIO article suggests "what we normally call training is increasingly shown to be relatively worthless. What’s called for, it seems, is an ability to figure out the underlying flow of information through the business itself. The traditional view of training may blind the unwary to its significance and to the tightly woven links that exist between training, change management and staff adequacy""

Also … "I separate training into two parts – education and training," says John Conklin, vice president and CIO of World Kitchen (formerly Corning Consumer Product Co., manufacturer of Pyrex and Corningware), of Elmira, N.Y. "Education is all the why, how and where issues," Conklin says. "Training is the how part of the equation." And of the two, he says, "education is the bigger piece of the puzzle. If people don’t go through this education, you won’t have their hearts and you won’t have their minds."

Per my own 20 years’ experience in database design, administration, programming, and consulting:

a). Evaluate your existing system, before taking on a major upgrade of software. Does the system continue to reflect the way your company does business? Is it readily modifiable, or extendible, in order to take advantage of new technologies, such as XML? Take a look ahead, at paragraph (g), if you are undertaking an evaluation of the existing system, and have not made any decisions as yet. Business models are moving so fast today, that no single package can do everything that your individual business requires, in order to remain competitive. Flexibility, and expandability, will be the keys to success.

b). If you are considering a new system, obtain professional objective assistance, re the following:

Can the existing system be readily modified, and extended,

to encompass new business concepts? Would this be cheaper,

easier, and faster, than moving to something totally new?

Connectivity to new technologies and suppliers/customers/B2B

Assessment of business needs, present and future

Conversion of existing data to a new environment

Formal RFP specifications encompassing future business plans

c). There can be enormous costs in data conversion, re-training, and re-implementation. Time costs money, as well. A full conversion can tie up users in significant re-training, while you are trying to do daily business. Purchase of an entirely new system may require additional third-party add-ons, for your company’s specific business needs. No system today does everything, and each is strong in certain areas, but not in others.

d). Utilize the services of professional consultants with "package experience", who will be candid as to what can be done with the existing system. Those with the added capability of writing good custom code, and provide proven third-party attachments, should be considered. If the consultant only believes in running "vanilla", you will never operate any better than the system currently allows. This is the flaw with Application Service Providers – you have to operate the way they allow you to, so you can be no better than their other customers. Certain applications, such as HR and Payroll, can be readily outsourced.

e). Speak with other customers who utilize the existing baseline system, and have tailored it for their own needs. That is what user groups are for.

f). If looking at a different package, speak with customers already implemented and running, for an assessment of their success. Their particular business should relate to yours, in general type (Manufacturing vs. Distribution, Make-to-Order vs. Make-to-Stock).

g). Design a "conference room pilot", so that everyone can learn the functions of the entire system, and not just their part. Operating on a multi-module database is a cooperative effort (i.e., Planning, Materials, Purchasing, Design Engineering, Schedule). Take a look at what makes up the classic Supply Chain (Plan, Source, Make, and Deliver), and see your company as fully inter-linked, for the benefit of your customers. Speak with key customers and suppliers, about their problems with your system. Stay in touch with the latest technologies from the Supply Chain Council (SCC), and updates to the Supply Chain Operations Reference (SCOR) model. See the article in the June 5^th issue of Intelligent Enterprise magazine (www.intelligententerprise.com) on how the "supply chain" concept is moving towards "value chain", and then on to "dynamic trading networks". In summary, make sure that your environment is flexible enough to keep up with newer business concepts and technologies. This may well require the addition of third-party offerings, which is a common practice in larger companies, who acknowledge that one "package" cannot do everything.

h). Utilize a consultant, with package experience, to answer specific questions, which arise from your evaluation, or Pilot. If you use the Software Company, you may get the "stock" replies, including "the system does not do that". Consultants with package experience may have already encountered, and solved the problem, or can advise on an alternative. Part of the consultant’s job is to think "outside of the box", and find solutions.

i). Take advantage of training classes, to learn the concepts. If those concepts are well understood, the mechanics of entry and reporting will be easier to deal with.

j). Do not "cut over" until the new system does what you need, in order to provide the appropriate level of customer service and fulfillment. This may mean "running parallel" for a time.

k). If it doesn’t "look like Windows" now, so what? The quality of the information, and availability of it, is what is important, not the display technology. Ease of use is an issue of education and training, not interface. Experienced data-entry people (and, for that matter, Windows pros) avoid the use of a mouse, as it takes your hand off of the keyboard. I spend long periods, writing complex code, without ever using a mouse. There are several products in the multi-value (Pick, Unidata, UniVerse, GA) arena which can provide a "windows" front-end, and web capability, to your existing software, and these will be steadily improving. There are millions of individual user "seats" on multi-value systems, and there is a market for these products.

l). Devote enough time to piloting and training. Knowledge is not gained through osmosis. Train key people first, to help train others. Maintain procedures manuals. Training must continue past the "go-live" point. Maintain a Pilot/Play account to work in, and test in.

m). Join a nearby APICS chapter (www.APICS.org).

n). Maintain an in-house library, starting with the latest APICS dictionary. For valuable links for magazines and books, look on my web site www.bartonworks.com, at "Useful Links". Some of the magazines offer free subscriptions.

o). Inform the user base that it is OK to say, "I don’t understand", and ask for help. Give no credit to somebody’s workaround of the established methodology – if they have a suggestion for improvement, let them make it formally.

p). If the users are not your partners, they have the choice of apathy, or animosity. Neither delivers quality product on time.