Random Thoughts on Life

I'm famous!

Ha, someone finally linked to me! Edward Champion has a large list of links on the AMS bankruptcy and potential sale of PGW to Perseus. He seems to be keeping it current.

posted by MrPopman @ 10:13 PM 0 comments

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 0 comments

I told you so part 2 - How not to do a software implementation!

All of the information I am about to impart I have received 2nd hand. The names have been removed to protect the individuals involved. When last we left our company the decision had been made to implement purchased applications to replace the custom ones the company had been using. Sometime after I left the company in '98 both the VP of IS and the Manager of Application support also left and/or were let go (I have heard both) over differences with senior management involving the software implementation. These were both very long term (> 10 year) employees who's input to the process was basically ignored. After their departure a third party consulting company was brought in to implement the applications. They basically did it the way they were instructed to do. Between the exit of the 2 senior managers, the consulting company, the hiring of a VP of IS and his promotion to CIO, and the promotion of the most junior analyst (< 2 yr seniority) to Manager of Application support by the new CIO, this killed the morale of the remaining IT people. They all understood that it was do it the way you were told or hit the road. This mindset is a really bad one to exist going into the very critical software selection for the distribution centers. This software drives the way the DC's work, and the DC's is where the company makes its money. Some extra overhead in the accounting systems is not a big deal. A little bit of extra overhead dealing with the product can eliminate the company's profits. The role of the in-house IT department in a software selection process is to understand both how the company works now and see how a potential software product will support those process' and how they will have to change to fit the product. In the specific case of AMS, the major evaluation of a software product needed to be how efficiently it implemented the specialized shipping procedures for dealing with case packs of items. From my point of view, the selection of the PkMS product is a black box, I do not know how AMS ended up with this product and have not been told anything I believe. What I do know, is that in its standard implementation PkMS was not capable of implementing AMS' core business, shipping cases of books to customers. Let me state that again, in its standard implementation PkMS was not capable of implementing the central money making process of AMS, the primary reason for its purchase! Just so you understand, PkMS in its standard form, was not capable of processing the 20% of AMS' orders that represent 80% of its volume and profits. Any selection process that produces this kind of result is invalid. So to work for AMS, PkMS had to be extensively modified to meet AMS' needs, an expensive, time consuming, and bug creating process.

I do not know the details of the project, but in total AMS spent $26 Million to purchase PkMS, customize it extensively to support processing by the case, implement customized order processing in Oracle, implement customized interfaces from PkMS to Oracle financial applications, implement customized interfaces from PkMS to and from AMS' legacy applications, test, and implement the setup. The implementation for this was scheduled for summer of '02 during FY '03. The cutover process was setup based on the way the customers ordered with small quantity singles customers first, larger quantity singles customers next, and finally the case pack ordering club customers. Due to the way the cutover process was designed, it had to occur at the fiscal month end. (If someone wants to email some details, I would personally be interested in why this was an issue.) The schedule was initially for the first customer to be cutover in June with the last in August. However, the schedule badly slipped, and during '02 only the customers ordering singles were converted to PkMS, with the club customers remaining being shipped from the legacy systems. Between the missed conversions causing AMS to continue using its legacy system for case customers, issues with the custom interfaces, a large contingent of outside consultants 'tuning' the new systems, and a generally poor holiday season for retail, AMS had a disastrous fall in '02. One item of importance was the close to $2 million in special ship charges in the fall quarter. (An AMS special shipment is when books are shipped late from the DC by fast freight or air to arrive on time at the retailer.) One of these charges can be the difference for AMS between making a profit for the month or not. The reason for these charges is that the system interfaces were not processing the data quickly enough to meet AMS' schedule. This was not found during the testing, because the interfaces were not volume tested they were only tested for functionality (did they do it right.) At no point in the testing was the expected volume of transactions pushed through the interfaces to see if they would complete their processing in time. It turns out a number of systems were simply not capable of processing the volume of transactions necessary. Starting in early '03, all of the new systems were expanded dramatically, most doubling in size. This was a large unexpected capital expense, requiring AMS to tap its credit line further to the point it had to be increased. But in the meantime AMS was forced to special ship during its busiest quarter to ensure the Retailers received books on time.

All of this comes back to the morale and mind set of the original IS staff. When the outside CIO was brought in, he made it clear through his actions that you did things his way or you were out. No one who understood how AMS processed orders and understood software selection would have reasonably selected PkMS. Those were the longtime IS employees who were cut out of the selection process. When the Oracle/PkMS project implementation moved into high gear not one of them was directly involved with the implementation. None of those people would have had anything to do with selecting PkMS in the first place nor would they have assume the processing would work in a timely manner. However, they had neither the mind set nor approval to disagree with the projects path. Like I said, how not to do a software implementation

Do you see the foundation for Part 3 "it doesn't add up"??

posted by MrPopman @ 9:36 PM 0 comments

Coming soon!

Coming soon - I told you so Part 2 and Part 3. Oh, I was sooooo right!

Part 2: How not to do a software implementation - aka - how to blow $26 Million.
Part 3: What do you mean, it doesn't add up - quite possibly the REAL reason why AMS has not re-filed its FY 03 nor filed its FY 04 financials.

Anyone else who wants to email me information, please feel free to do so (see the link in my profile). I've been sent some of the pertinent facts, but not all of them. Of special interest is a first hand account of how they got hooked up with Manhattan Associates and when the accounting department realized the issues they are still struggling with.

posted by MrPopman @ 7:57 PM 0 comments

Advanced Marketing Services Links

Here are assorted links to the AMS information:

An author's perspective.
A former PGW employee's perspective.
Some really dark humor from a very disgruntaled person.
Another view from an author.

I will add more links as I find them.

posted by MrPopman @ 8:12 PM 0 comments

I TOLD YOU SO!

Ah, at last I can say it, I TOLD YOU SO! Many years ago I worked at Advanced Marketing Services (ticker MKTS.PK ). On Friday December 29th, they filed for bankruptcy. The reasons for this are many, all ultimately caused by inept senior management. Sometime this year you will find your local Costco or Sam's club with a limited book selection. AMS is the primary supplier for them. For most people, that will be the extent of the effect on their daily lives. If you read specialty books from Publisher Group West (PGW) you may be in for a very rough ride as PGW is wholly owned by AMS and will undoubtedly be negatively affected by this. As for me, I am long gone from them. My stock options are worthless and have been for some time. The reasons for these grants are a whole other story. As to why I knew this was going to happen, and have been expecting it for years, it starts with decisions made in 1998.

Back in '98 AMS was solely a book distributor purchasing pallets from publishers, tagging books individually for retailers, and shipping case lots to them. All of their software (distribution management, ordering, EDI, AP, AR, GL) was custom built for them. The decision was made to start implementing purchased applications capable of supporting a wider range of customers and general business diversification, starting with the financial systems: GL, AP, and AR, using Oracle financial software. Implementing purchased software as a replacement for custom, in theory, was a good idea. In practice it was a disaster from the start. The core problem was the lack of a project lead with both the responsibility and authority needed to complete a successful implementation. The IT department was being held responsible for the implementation, but was not given the authority necessary. Typical example, any one for any reason at any time could walk out of any meeting or simply not attend as they saw fit. When we tried to explain to management (from line managers up to and including the CEO) that the decisions made in these meetings would have a daily impact on the operations and profitability of the company for many years to come, we were (to be blunt) ignored. The reason this was allowed to happen (and this is hearsay) is that the CEO stated that daily operations were more important than the software implementation project. Anyone with any project experience will tell you that yes daily operations can be more critical than an implementation project but they are not more important. The other huge issue with the implementation was that the design of the accounting system done in Oracle closely followed the custom system that had been implemented. Basically, people took a look at how they were performing tasks with the current system and modified the Oracle systems to match them. When implementing purchased software, you always need to look at each process, and determine what needs to be accomplished and then modify the business procedures to suit the software. This fundamental software implementation error and the resulting management philosophy of telling IS to "do it the way we tell you to" was the start of the very long fall from grace of AMS. It was at this point that I left the company, feeling that their next project, to implement a purchased system for the management of the distribution process, was going to ultimately lead to the company's failure. This is what I stated to the CIO when I left. It took 7 years, but it did finally happen.

posted by MrPopman @ 6:45 PM 0 comments