Paying Bills for American Motors

My first Big Six consulting engagement, right out of MBA school, was solving a catastrophic failure in the Accounts Payable system of American Motors Corp.  You may recall AMC, they produced the Gremlin and the original Jeep.  This was right around the time of their acquisition by Chrysler, a sensitive time for the company.  The building still wore the red, white, and blue AMC logo, but the Chrysler employee newspaper was on the stand in the cafeteria.

It was on me to figure out what in hell had caused this popular and bulletproof software to fail. 

They were also just about to launch two new assembly plants in Canada, at Brampton and Bramalea, Ontario.  The launch, and maybe even the acquisition, was jeopardized because AMC had suddenly lost the ability to pay its suppliers’ invoices.  They had devolved to a purely manual process, paying months late, and their suppliers were threatening to cut them off.  Without a functioning A/P system, there would not be many parts shipping to the new plants in Canada.

The classical A/P function revolves around the “three-way match.”  Starting with the invoice, you must locate the purchase order for the goods and the slip from the receiving department showing that the correct goods had arrived.  As you can imagine, a giant manufacturing company cannot possibly perform this task on paper.  American Motors had been running the McCormack & Dodge suite of accounting software, and that was the proximate cause of the failure.  My assignment was to diagnose and fix the failure.

The Director of the A/P department had collected all of the invoices, receivers, and purchase orders into file boxes on tables in a huge room.  This had been a big conference room, maybe, or a gymnasium, and he had hired a platoon of “account temps” to run around the room looking for three-way matches.  Once someone found a match, they would run down the hall to the cashier and authorize payment of the invoice.  It was like a demented Chuck Barris TV game show.

The mad rush to pay months-old invoices was destroying any organization that might once have existed.

For me, as a programmer, this provided a stunning visualization of what this work must have looked like in the dark days before computers.  Of course, in those days, they would have been prepared for it.  Here, the mad rush to pay months-old invoices was destroying any organization that might once have existed in the file boxes.  The A/P director’s job was on the line and, over the weeks of my engagement, he aged ten years.  This poor devil was my client.  I could see the dark circles and the grey hair progressing as I greeted him each morning.

I should note that a new consultant doesn’t get a big job like this on his own but, as “senior schmuck onsite,” I was running the engagement.  Occasionally, higher-ranking consultants would show up to offer an opinion, not do any actual work, and bill four hours to the job.  Also, as the only one with any computer skills, it was on me to figure out what in hell had caused this popular and bulletproof software to fail.

Our method had two prongs of attack.  First, we brought in several junior, not yet CPA, staffers from our audit practice, and put them to work matching invoices.  This was basically the same process as in the gym downstairs, only our people were going to be smarter and look for patterns that might provide some clues.  Plus, we could bill for them at 100% realization.

Meanwhile, I would learn everything I could about the failing A/P system and its friends, the Purchasing system and the General Ledger system.  I read all three APRMs (Application Programmer’s Reference Manual, pronounced “A-Parm”) from cover to cover.  I read all the Job Control Language, the job streams, and much of the COBOL source code.

The only people dumber than the A/P department are these consultants!

I also got invited to defend our work at an executive meeting on the top floor of the AMC building, where I met the Vice President of Purchasing.  This was a big bull of a man, obviously some kind of ex-jock with a lot of red meat in his diet.  He pounded my guy mercilessly, and the preliminary stats from our auditors were no defense.  “The only people dumber than the A/P department,” he roared, “are the consultants hired by the A/P department!”

Eventually, I traced the failure to one specific job running one specific program, P1X030, the “matching module” itself.  All data flowing into, out of, or around this module were good, except that something like 90% of invoices went unmatched.  I called my manager up from Detroit and we went over the results.

I enjoyed working with Ken.  Back in those days, computer skills were considered déclassé.  I was the only consultant who could write a lick of code, and Ken was our only “technical” manager.  Eventually, the firm would get rid of Ken, and then me, in favor of a more golf-oriented practice.

“What about the exception report?” Ken asked, “is it dummied out?”  I checked the JCL.  Systems programmers would often streamline an implementation by suppressing some of its printouts but, no, P1X030 was faithfully printing a list of its reasons for rejecting 90% of the invoices.  “Let’s go for a walk,” Ken said.

We walked about half a mile, the length of the big, mainframe computer facility.  There, lying on the output table, was P1X030’s exception report.  Ken rapped on the window of the control room and spoke with the operator.  The report spooled off his printer every night, and then lay unclaimed on the table.  The operator had been collecting the old reports, and he was relieved to the be rid of them.  This was line-printer paper, boxes of it.  I waited while Ken went to find a hand truck.

The problem, printed mechanically line after line, was that the Purchasing department had been neglecting the important task of generating proper purchase orders.  They had been ordering the suppliers, probably in the same tones I had heard in the boardroom, simply to ship now and worry about the numbers later.

Purchasing had evidently instructed the suppliers to invent random P.O. numbers.  Our auditors had found a few clinkers, like 12345678 and 00000000, but mostly we had no clue.  If anyone had thought to ask a supplier, they would have been afraid to admit it and, anyway, it would have been the Purchasing department doing the asking.

I wrote up our findings and Ken presented them to AMC management.  He wheeled his hand truck into the boardroom and, for dramatic effect, read off the first few variants of “missing or invalid purchase order number.”  We included a report from P1X030, tabulating the various ways in which its safety features had been defeated.

There was no system failure for me to fix, so that concluded our engagement.  As to the failure we did find, management seemed eager to fix that one on their own.

Farewell to PEN

Clients are often surprised when I say, “my work here is finished.”  The consultant’s handbook says you should hang around until they’re sick and tired of you.  I feel it is better, when retained for a specific task – like a startup – to do the job in good style and then move on.

So it is with Provider Exchange Network.  The business model is established, the software is up and patented, and the staff are fluent in their new roles.  It has been my pleasure to work with the talented people at PEN, and I wish them all the best.