Spring 1995 - The ERP Crisis

In late summer 1994 I signed on as a programmer/analyst at a computer configurator/reseller called Ameridata based in Golden Valley. Think about what CDW does now, they did then: They worked with Compaq and HP and Apple, and sold computers, printers, networking gear, and everything else via mail order and inbound sales. In the pre-internet world, it wasn't a bad business: They had one big warehouse, a lot of customers, and were also growing into the services area as well. Their system was (as most things were in those days) a heavily customized COBOL system they had bought maybe 10 years earlier and had tweaked the source code beyond all recognition. I was there because, well, I did COBOL. We called the system ADI.

Thing moved quickly for me there... in the late summer, I was doing programming work anyone needed doing, and was creating some consternation in the ranks of the veteran programmers. I was fast. Too fast for the established norms they were used to. There were wide swaths of code that the whole team referred to as "OSK" - Only Skip Knows - the guru who had been tweaking the code the longest. And to do any work in that code, you needed some of Skip's time, and he doled the time out very very meagerly. For such a busy man, he kept very lax hours, and to everyone's surprise, he up and quit 2 months into my tenure.

Fortunately I was able to figure out the OSK bits without too much trouble.

Around December, there was a rumble through the organization... there would be a new system. Something to replace ADI because ADI was old, and they needed to move into the future. Something called "BaaN Triton", which I would come to learn was an "ERP" system, similar to SAP (but less expensive). Half of the team was split off to work on the BaaN project, at a new location, while the rest of us were to keep ADI alive.

Around the same time, Ameridata decided to expand and purchased a similar outfit in Gaithersburg MD. This was a first step toward global domination, I suppose. They put ME on the team to figure out how to put Ameridata East onto ADI, and quickly, and they gave it to me to figure out. After a few weeks of looking at the tables, a thought occurred to me: Did these groups have separate sales forces? Yes. Separate warehouses? Yes. Separate purchasing departments? Yes. When would they be integrated? Sometime AFTER BaaN.

Then heck, let's just clone the system, add a switcher front-end for the 4 people in the organization who need to access both, and be done with it. The project went from a 1 year project to a 3 months slam dunk. I went on my first real "business trip" out to Gaithersburg for the (completely uneventful) cutover. ADI2 went live, and I felt pretty good. Which meant it was time for me to join the BaaN team.

Now, this company may have had high hopes for this BaaN system, but let's take a look: They had a Cobol system that worked. They had business processes that worked. They had in NO way outgrown their systems: Every screen was responsive, every team member got reports they needed. Even with their acquisition, given the huge geographic difference AND the completely separate sales/customer base there was nothing pushing them.

Nothing but a consultant from CSC who had done an assessment and determined that in order to play in the "big leagues", they needed an ERP. Mike was a suit guy, and not only did he do the assessment, he picked the software, and he committed to staying on for 2 years to see the project through.

I never knew the full numbers, but if memory serves, the software and implementation was due to cost over $4m in software and hardware alone, let alone services. At the time, Ameridata had total annual revenues of $10-15m, and I can't imagine margins were that great, even in the wild 90's. And the project was structured just like you'd expect an ERP project to be structured: 6 "business analysts" were brought in who were expected to be entirely non-technical - just work on the workflows. Then there was Mike. And a new DBA. And a new Report Writer.

Plus the 6 people who had run the whole operation for the previous 10 years on the system they already owned. And these people were cross-trained to be the programmers in BaaN. I was sent to Grand Rapids MI with two compatriots, John and Jim, and none of us could figure out why we were only learning certain "modules" - we were capable of maintaining ALL parts of our previous system, so why wouldn't we learn ALL of Triton? Oh, it doesn't work like that... it's so complex you need to specialize.

This did lead to my first amusing travel story: At the Hertz office, they were all out of mid-size cars, but they did have a Town Car they'd let us have at a discount. I said yes and spent the afternoon tooling around in a Lincoln, until Jim and John teamed up on me and DEMANDED that I return it and get a compact because EVEN THOUGH it's at a discount, they would be terrified if the VP asked them to justify the expense. For we spent the next 2 days in a Ford Fiesta.

Triton was written in some Moon Man 4GL that had huge processing overhead, and had a charming habit of crapping out with the message "SERVER GESTAPT". The Server in question was a refrigerator-sized computer that cost $250,000. a 4-processor Pentium 90 with 6 GIGABYTES of storage (in the form of 2 dozen 270 meg hard drives). The thing was huge and loud and had a cold room all to itself. It had a dedicated terminal and had something on it called NCSA MOSAIC.

More about my first exposures to the World Wide Web on MOSAIC in a future post.

Naturally, that was just the TEST machine. The PROD machine came later, at another $250,000. And even with all of this, the system was horribly poky. Oracle blamed BaaN, BaaN blamed Oracle, everyone blamed ATT (apparently our superserver was not the most desirable one, even with that cost). The network took some blame. You'd log in, count to 10, enter an order number, count to 10 for the HEADER, then wait 15 more seconds for the Detail Lines to draw. And we programmers were locked out of the low-level routines - this was a 4GL - they just give you an "interpretive layer" which is a layer of code above the code (which is already above some code)....

It's worth mentioning AGAIN that our little ADI system ran just fine on the 486 tower, connected to 500 meg of storage which held everything.

I was just a programmer, here, keeping ADI going, and building things in Triton as requested, but I was kept entirely out of the "fishbowl" - the conference room where the business analysts kept the 4 "subject matter experts" in the company hostage while they documented workflows and use cases. For months I watched flow charts go up on the wall-length whiteboards. It was while walking past that I first heard the term "Out of the Box", which didn't make any sense to me.

I left there in Fall 1995 (that is another story) and sadly wasn't there to see their golive in Spring 1996. But I heard that they went live replacing ADI1 only, and that "overnight processing" (invoicing, inventory updates, etc) took 26 hours to complete, during which time everyone was locked out.

I was just amazed: I was able to bring a new business unit online with their proven older technology in under 3 months. In 18 months they spent more than $4m to barely replicate what they had working when I walked in the door, with a system that barely was able to function. The plan was to bring ADI2 on board within 6 months. I never heard any plans to bring on their IT consulting wing or their implementation services... As far as I could tell, BaaN was just there to replace ADI.

But the next steps didn't happen, because by Summer 1996, the company had been sold. To GE, who DID have a national presence, and who were in the process of installing SAP. By Fall 1996, the Triton team was already hard at work.... planning for the replacement of BaaN with SAP.

It was told to me that the whole reason they went up on BaaN was to increase their sale value, that the sale had been in the planning stages for years, and if they were able to point to this ERP in their core, they'd have a higher market value, since obviously they'd be bringing not just 2 warehouses to the deal, but "engineered best practices" and "state of the art software". That strikes me as a pretty cynical way to look at it, but I can't argue with it either, since GE bought them for almost a half BILLION. And installing ERP for its own sake sure as hell didn't make any sense to me.

Now, all of this is to my best recollection, of course, and seen from the programmer's chair. There may have been a whole different story two levels above me. And maybe somebody wants to tell that story. But this is MY blog. And the whole thing struck me as such a "poster child of ERP Excess" I just had to share.