A New ERP

I was once told that most IT people only have to go through a major ERP implementation once during their career.  But, I was also told that it was Santa Claus bringing those presents. 

This is my second time through an ERP process and this blog is going to be my Christmas/Valentines/Easter present to you.  Implementing Enterprise Resource Planning systems (that?s the last time I?m typing it all out), as President Bush would say, ?It?s hard -- it?s a lot of work!?  By becoming my vicarious companions on this adventure I hope to share with you what I learn and keep you from being sucked into the black hole of project failure.  And, I hope to pick up a few pointers from you along the way.

So, what is this agency I work for and why are we doing this to ourselves?

For purposes of discretion, we?ll call it the Deer Creek Water Agency (DCWA). 

The DCWA was formed in 1950 to supply supplemental water to the region.  It is a California special district, a member agency of a larger metropolitan water district which imports water to our area from hundreds of miles away.  In its early days it consisted of its elected Board of Directors and half a dozen employees. In 1958 it signed a contract with cities in its service area to take on sanitation responsibilities (sanitation ? you know, the people who make your brown water blue.)  It has since grown to be a regional wastewater treatment agency with domestic and industrial disposal systems and energy recovery/production facilities. It has a 242 square mile service area and provides services to six cities and two retail water agencies. In addition, the Agency has become a recycled water purveyor, biosolids/fertilizer treatment provider and continues as a leader in water supply salt management.

When I arrived here in 1991, DCWA was about to implement it?s first ERP.  More on that in my next posting.

So what went wrong here?  Did the ERP we were using for 15 years suddenly have a stroke?  Did the developers make some strategic turn into a dead end?  Did we outgrow it?

None of the above.  There is in fact nothing wrong with IFAS and other organizations will be adopting it at the same time we whish is auf Wiedersehen.  What happened was a series of cultural accidents.  Like most cultural changes, they are more obvious in the rear view mirror than when we drove through them.  That doesn?t mean, however, that they couldn?t have been avoided.

Cultural Accident Number 1:  Whose IS Department is this anyway?
When I came to DCWA the IS Department reported to the Director of Administration who was responsible for providing Agency-wide services.  This is the organizational sweet-spot for IS.  When the Director was promoted to General Manager, instead of replacing himself, he doled out the departments that formerly reported to him to other divisions in the Agency and IS went to the Director of Finance.

It?s not unusual for IS to report to a CFO, but the results are predictable.  I objected at the time, saying we?d become the Accounting Department?s IS staff.  My objection carried no weight and years went by and I thought perhaps I was wrong.  I wasn?t.  We responded to the needs of Accounting first.  Other departments came to view us as a roadblock, developed their own systems, and generally tried to avoid us.

Cultural Accident Number 2:  We became fat, dumb and deaf.
Accounting was happy, the backups were done, and we were busy implementing applications to fill holes in IFAS and specialized non-financial applications such as Laboratory Information Management Systems.  We didn?t talk to the other departments about how they used or how much they were satisfied with the ERP.  It was here, it wasn?t going away, and it worked.  End of story (we thought).

 Cultural Accident Number 3:  We don?t need no stinking training.
In the early ?90?s the Agency was dominated by one of the members of the Board of Directors who thought all training was a ?boondoggle?.  That belief was a cornerstone of his political life.  The IS Department went for years without formal training.  The users tended to get intermittent training in office applications.  IFAS had and has an active, involved user group but our participation was irregular and minimal.  After the initial implementation, user training was of the folk knowledge variety, handed down through generations.  People tried, but without an ongoing training program for old and new users alike, a complex system like an ERP will eventually become a puzzle with the answers hidden in a locked book.

 

 

Sometimes users just won?t tell you what?s wrong.  As I sat in meetings listing to the shortcomings of the current system, I kept saying to myself (and only to myself since defending the current system would not be useful in this meeting) ?I know how to fix that? and ?I wrote a report that shows that? and ?That could be fixed? and so on. 

The saddest moment was when someone said, ?And you know, you just can?t get labels out of this system?.  It reminded me that about six years ago we decided that labels were so easy to do, given the advances in desktop software, that we just weren?t going to write label programs on the mini-computer anymore.  Well, over the years it seems that the people who know how to do labels got transferred or promoted or left the Agency for other jobs.  Sometimes we don?t give users enough credit.  Sometimes we give them too much.  By the way, you can get labels out of the system, but I?ll have someone on my staff write a Crystal Report to help them out.

One of my programmers mentioned that job shadowing is a good way to find out what really isn?t working for a particular user.  If you ask them they say, ?Yeah, everything is OK.?  But if you work with them for a few days, you see all the inefficiencies that are involved in their job.  You can see the things they need to learn, the computer solutions they should be taking advantage of, and what needs to be written or configured so they can use it.  As we implement the new ERP, we should job shadow the doers.

We had our first Evaluation Team meeting yesterday.  This team will put together the RFP and then morph into the Implementation Team.  Everyone had been playing nice while the requirements were being gathered, but now the gloves are off.

We were trying to decide an order for implementing subsystems.  The rub is with maintenance.  The Maintenance Department had their project for a new CMMS put on hold to see if it could be rolled into an ERP.  The two team members from Maintenance kept referring to ?your system? (the financials) and ?our system? (the CMMS).  It remains to be seen whether we will have an all encompassing ERP or an ERP with a closely integrated CMMS.  If we let the CMMS come up first, they?ll bolt.  We?ll never see the Maintenance Department at a team meeting again and we won?t have an integrated system.

Tomorrow we begin out third series of meetings with our project consultants whom will call the Accounting for Government Professionals Association (AGPA). AGPA is providing expertise on how to create our RFP and how to negotiate with vendors to whom our Agency might look like a tiny morsel to be swallowed in one gulp.

The first series of meetings was fact finding.  They then roughed out a set of requirements.  The second series of meeting was to review the draft requirements.  This week we will be hammering out the final RFP ? a document which may influence the future of the Agency for decades. (Pretty dramatic for accounting, huh?)

I?m reviewing the ERP Specs in preparation for this week?s meetings.  I?ve noticed that there are two really overworked terms:  ?real-time? and ?automatic?.

One text book definition of real-time when it comes to computing is:

"The term is used to describe a number of different computer features. For example, real-time operating systems are systems that respond to input immediately. They are used for such tasks as navigation, in which the computer must react to a steady flow of new information without interruption. Most general-purpose operating systems are not real-time because they can take a few seconds, or even minutes, to react. Real time can also refer to events simulated by a computer at the same speed that they would occur in real life. In graphics animation, for example, a real-time program would display objects moving across the screen at the same speed that they would actually move."

What we are really concerned with is not ?real-time?, but integration ? that the information entered into one module is available in other modules where it is relevant.  This is pretty much a given in an ERP.  It?s why the ERP exists to begin with.  As a requirement, this should probably be handled at a high level, for example:

?The Agency requires a fully integrated enterprise resource planning system, with an online interface to other Agency software.?

Automatic ? to me this is a scary term.  We don?t want a system that, for instance, ?automatically prints purchase orders? or ?automatically sends notifications?.  There should be some human intervention.  A system might automatically generate purchase orders, but a human should approve them.  My experience has been that when a system does a lot of things ?automatically? you eventually hear conversations like this:

?What?s that stuff?

?I don?t know.  The system prints it out every night.  We just throw it away every morning.?

Now, if I could only find a program to automatically review the rest of these specifications in real-time!

We just finished three solid days of requirements reviews with the Accounting for Government Professionals Association (AGPA).  The hardest thing that most employees had to deal with was separating ?the way we do things now? from what we need to do.

?The way we do things now? involves work-arounds, shadow systems and spreadsheets. 

          HR PERSON: ?I just can?t imagine a system that would be able to do what I do on a spreadsheet?

          ME: ?Imaging a system is not your job.  Just tell us what you do with the spreadsheet.?

One ironic moment:  The ERP implementation team (heavily Accounting) and the AGPA have been preaching that all shadow systems and spreadsheet/MS Access/whatever work-arounds had to be managed into the new ERP.  Then someone brought up an MS Access program I had written about six years ago. Accounting is still using it to calculate property taxes.  They didn?t want to give it up.  Sometimes it?s hard to eat your own dog food.  But they were brave and they swallowed.

[ Warning ? Leo is being curmudgeonly again. ]

I decided to take another shot at principles for the ERP project. (Not, ?Guiding Principles?; they guide you because they are principles.  That?s what principles are for.)

Principles need to start with a verb and be generally applicable to the entire subject matter for the entire length of the project, not specific and accomplishable.  The specific, accomplish and check-off stuff are Goals or Objectives.  Principles just go on and on, like my e-mails.

Here they are.  (I?ve also put a copy in G:\ERP\Project Charter.)  Once my wisdom is generally acknowledged we can put these up on the wall of our meeting room.  (Seriously, I am interested in feedback.)

6.0 PRINCIPLES

While implementing  the ERP project, Deer Creek Water Agency will adhere to the following principles:

Principle 1 ? Focus on the Agency

Focus on the needs of the entire Agency, while remembering that the needs of each department must be considered and that no department should be unfairly burdened by the new system.

Principle 2 ? Take Responsibility

All departments will do their own data entry.  No one will develop their own paper forms or spreadsheets and send them to another department to be entered.

Principle 3 ? Put it Online, not On-Paper

Make all information needed by all levels of the Agency available on-line.  Reports that contain information not available online and the use of paper forms are signs of failure.

Principle 4 ? Enter Only Once

Once data is entered into the system, it should never need to be re-keyed. 

Principle 5 ? Stop the Paper Here

Paper documents from outside the Agency should be discouraged in favor of electronic transmissions. When paper documents must be accepted they will be scanned, or OCR?ed then discarded.  If you are ordering new file cabinets, you don?t get it.

Principle 6 ? Work Electronically

Business processes will be conducted by automated workflow.  Map out processes that will be improved and manage the change.  If at the end of the implementation you are stuffing routine documents into interoffice envelopes, you missed the boat.

Principle 7 ?Train Now and in the Future

Training for both the Project Evaluation Team and users of the system during the implementation and on an on-going basis is critical for success.  Failure to train is failure to implement.

Principle 8 ? Communicate with Users

Communication must be regular, varied in format and two-way.  Otherwise, friction and resistance to change will result because most people in the Agency will be too busy doing their current jobs to understand what is happening. 

Principle 9. Remain Positive and Have a Good Time - View this as the opportunity to create a lasting, positive imprint of the way the Agency conducts business.

Daisymae L. Maldanado
Administrative Coordinator
Engineering, Energy and Construction Management Dept.
Deer Creek Water Agency

Dumb numbers are good. You can?t run out of them and computers can assign them. 

A ?dumb number? is a number which does not contain any meaningful internal elements. It?s just a number.  A smart number, like the Vehicle Identification Number on your car, tells you all kinds of things such as the manufacturer and who tightened the bolts on the brake pad.

When in comes to identifying equipment in our new ERP, our Maintenance Department keeps insisting on using a smart number that will tell you the location, the process involved and several other pieces of information, because ?people need to know this when they are in the field?.  They seem to be oblivious to the arguments that:

• Anyone looking at a piece of equipment in the field will immediately be able to grok all this info by turning their head from side to side and processing visual data, and
• Anyone using the ERP system will be able to look at related fields and not need to know the secret codes embedded in the number.

During an hour and a half discussion of this yesterday ? which started going around in circles after the first twenty minutes ? someone finally asked, ?Where do they (maintenance) get these numbers they want to use?  They don?t relate to anything else we?re doing now.?  Unfortunately, I?m the only one old enough to know the answers.  The numbers come not from our current system, but from a custom program written on an IBM S/36 which the Agency stopped using in 1993.

Has anyone run into this smart number fetish before?  How do we convince these gentlemen, who are not dumb, that all they need is a dumb number?

We have a name ? The Agency Wide Systems Migration (AWSM) Project.  It?s pronounced ?awesome?.  Two of our Steering Committee members liked the name right away.  Another inquired, ?Should the title make some reference to information systems, computers, electronic data??

My answer ? not delivered yet, but scrawled next to his note ? is ?No?.  No, because this project is about much more than computers ? it?s about how we do our jobs.  Besides, Agency Wide Computer Systems Migration would make a lousy acronym.

Tom Mochal makes some excellent points about naming and marketing projects.  Check out his article.

Has anyone had a great name for a project?  Been stuck with a lame name?  Has it made a difference?