Random Thoughts on Life

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