Random Thoughts on Life

I told you so part 3 - What do you mean it doesn't add up?!?!

What I am about to relate, I do with some sense of bewilderment. I had a conversation with a former employee of AMS several months ago and we discussed AMS's continued inability to release audited financial reports. (This was when Robert Robotti was in a proxy fight in part over the unreleased financial reports.) This person's perspective (I'll call him Tom) was that, they might never release fully audited financial reports for FY '03 onward! Over 2 years ago, when AMS was struggling with their new systems and before the accounting scandle broke, Tom was approached (as a former employee) to review the new systems and possibly recomend ways to improve them. Tom spent a week reviewing the list of open issues and talking with individuals. At the end of the week, Tom informed the person who approached him that Tom would be "unable to devote the time necessary to fully investigate their issues and determine appropriate solutions." In fact, they were the only potential consulting contract Tom had at the time, and Tom walked away without submitting a single bill for his time nor anything in writing. In Tom's opinion at that point, AMS had dug their own grave (with their new systems), placed one foot firmly in it, had the other on a banana peel and he wanted nothing to do with them. It is my opinion, that the accounting misdeeds turned out to be the shove that ended them up in bankruptcy, not the central reason for it.

Now so you understand his background, Tom is a degreed IT professional, who has extensively supported finance departments. When Tom was brought in AMS was having several problems, including processing delays causing special ships, a higher level of manpower required to complete the same amount of shipping compared to the legacy systems, and interface issues between PkMS, Oracle order processing, and the Oracle accounting systems. Tom was asked to look into the interface issues. What Tom found astonished him and caused him to back out of the deal. In simple terms, the PkMS system (specifically the custom modifications) was generating unbalanced accounting transactions that were being loaded into Oracle and adversely affecting the profit and loss statements for AMS. Because of assorted issues, there was no programatic way to correct the errors, they were all going to have to be found and fixed by hand. The really bad news, was that there were thousands being generated on a monthly basis and when Borders was an active customer there were tens of thousands being generated monthly.

The detail of these transactions is as follows. AMS' inventory exists in several states and one title will be stored in multiple locations. A single title can have a status of active, inactive or stored (don't ask) and depending on the state can be in one or more of the bulk pack, piece pick, case pick, low steel, high steel, receiving dock, temporary, rework, returns, or storage locations. It is the responsibility of PkMS to manage the movement of inventory through these locations and the order processing. Obviously anytime a pallet or case is moved or a case or piece picked for shipment, PkMS needs to be updated so it knows where the inventory is, what pallet locations are occupied or available, what quantities are available in the case and piece pick locations, and which orders have been filled and which have yet to be. It is a very large and complex process to manage with AMS moving 40-50 Million books a year through its operations. As some of these movements occur, PkMS needs to generate accounting transactions to update the financial reports. As PkMS is updated with inventory movements within a DC, it generates accounting transactions for the Oracle financial systems. (I do not understand for the most part why these transactions are generated, Tom is the expert.) An example would be 4 cases are pulled from case pick to be broken down into singles for the piece pick area. The cases would be scanned when picked, then again when placed in the piece pick area. At the end of the shift, or on the next shift, one of the cases is still unopened and the decision is made to place it back in case pick. Again, the case is scanned when pulled from piece pick and when placed back in case pick. At each scan a transaction would be generated for the financial systems. Where the wheels came off the rail is that at each scan, the person doing the scanning would be queried by the system as to why they were scanning the case, and their answer would determine which financial account would be credited or debited with the inventory value. In our example the one case that was returned back to case pick should credit the value in the account that was debited when the 4 were pulled for a net change of (the value of) 3 cases. However, in our example, the person putting the case back would have no way to know what reason the person who pulled it told PkMS (in this case there is a correct choice, but for other cases multiple answers were valid) for the pull so would simply use their best judgment on which code to use. In theory only two accounts should have been touched in our example, but in fact sometimes four accounts would be affected. Now, to be honest, as Tom described this I entered a state I can only describe as "on Tilt", having been given information that I could not come up with any reasonable explanation for. The jobs at the DC are, for the most part, one step up from fast food positions and attract a wide variety of people with different work ethics, some of whom when asked by a system why the just picked or placed a case of books will select the first choice every time. My opinion is that asking these people (regardless of the work ethic) why they just performed something they were asked to do is a totally inappropriate behavior for a software package, and one that is guaranteed to generate errors. Unfortunately for AMS, these errors were directly loaded into the GL, AP, and AR accounting areas. At the time Tom looked into it, he estimated there were between 100,000 and 500,000 unbalanced transactions that needed to be fixed, all by hand. As a side note, I do know PkMS was originally designed for a high value low volume warehouse operation, not the low value high volume distribution center operation of AMS. Maybe asking these questions in the environment PkMS was designed for made sense, however it does not for AMS. As I said in Part 2, PkMS was not a reasonable software package for AMS to select.

It is my personal speculation that these transactions are why AMS is still unable to restate their FY '03 (the first FY with PkMS in production) financial reports nor state their FY '04 and beyond. Now you might ask, they put some numbers out for FY '03, how did they do that. My answer is that, I don't know. What I do know is that Arthur Andersen LLP was the independent auditor for AMS and AMS stuck with them until long past the indictment in '01. Deloitte & Touche took over late in the FY '02 audit, and when they audited the FY '03 reports it was their first full pass through them. The FY closes for AMS on March 31st, with the results announced toward the end of May. It was the end of July when the first search warrants were executed. You can speculate all you want as to what happened between March '03 and July '03, I have no idea. As for not releasing the revised reports, my guess is that with the intense scrutiny involved, no one will certify the audit until the unbalanced transactions are rectified. Like I said, quite possibly the real reason why AMS has not restated its FY '03 nor filed its FY '04 financial reports.

Update 1/27/06 16:37 PT: Ok, after hearing from other sources, it turns out Tom's departure from AMS was not amicable. At the time I put this post together I was under the impression that Tom had originally left AMS due to the general unpleasantness going on. It turns out there was a bit of shoving done by the then CIO (BB). Do I think he totally snowed me on this, no I don't. I believe the unbalanced transactions are a problem (I have other sources on that.) Did he possibly exaggerate the scope, possibly. Understand, I worked with this person before I left and trusted him implicitly. When we met last year, he stated to me that I got out at the right time before the implementation got really ugly and he regretted the time wasted battling management before he left. Turns out BB encouraged him to move on using motivating techniques such as removing all direct reports from Tom and having him report to one of his prior subordinates. From personal experience, that leaves a mark. So take the scope of the problem with a grain of salt. Until someone else can supply some information on the scope of the issue, I am going to stand with what I said, in general. The interface problems between PkMS and the Oracle financial systems have left AMS with issues that prevent it from filing fully audited financial results for FY '03 and beyond.

posted by MrPopman @ 9:43 PM