SAP R3: Is the cure worse than the disease?greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread
I work for a Tier One supplier to auto industry - we are the largest competitor in our industry. We import and export globally.
General Motors required their suppliers to be Y2K compliant by June 1, 1999. After several years of planning, we implemented all SAP R3 modules simultaneously on May 1. This was against the advice of our third party consultant; the consultant recommended we implement one module at a time stating he had been involved with over 20 other SAP system implementations and no one had switched on all modules simultaneously.
After a few days, legacy code was successfully transfered and the old non-Y2K compliant was shut down. For a few weeks, we lost a few orders, it seems that SAP R3 would not allow a new order to be scheduled for manufacture without the Product & Inventory Control Dept entering a proper promise date for the order. If an order sat in the system for a few days without receiving a promise date, the system dumped the order without scheduling it leaving Sales to find the problem before we shut down a customer.
This was fixed by resetting the P&IC module so that if any order did not receive a promise date the promise date field was filled with a copy of the sales' request date and scheduled for manufacture. This worked for several weeks as Sales had a good idea on the real lead times especially for repeat orders. However, to combat the surprise of learning that their apparent order was not ready as "promised" sales began entering more orders and our lead times have extended. Lead times have also gone up as P&IC issued directives to Manufacturing not to make any order that did not have P&IC approval. So essentially P&IC have been manually scheduling orders independent of the request date and the sometime bogus promise date.
Another complication was implemneted to minimize inventory. In the new system, a new order is compared to existing stock and if there is existing stock on hand for another order that did not ship on the other order's promise date, the system will cancel the old order and apply it to the new order. To date, this has not shown up on the Sales Order so we may have 1000 widgets in stock against 3-4 orders each for 1000 widgets and each thinking the system shows their 1000 widgets are in stock. Needless to say the level of confusion has ramped up to the point that continued availability to fill orders is in question.
The only thing that has kept our customers supplied has been 12 hour days, air freight and exclusive use of trucks with tandem drivers for overnight deliveries.
I understand other modules payroll, account receivable, accounts payable are equally screwed up.
I wonder if Y2K will be any worse than our current situation? Is suppose so, we import raw material from many third world developing countries.
-- y99? (email@example.com), August 10, 1999
Much worse -- a severe global depression.
-- Randolph (firstname.lastname@example.org), August 10, 1999.
This is a great example of what Infomagic's famous "Charlotte's Web" analogy is all about. Even though the solution to Y2K in this case was a faulty one, it has happened early enough, and with enough resources, to muddle through. Thus, the web has a few broken strands, but nevertheless still holds.
But as time marches on, more and more strands will break. The web will be overwhelmed. The web will break.
-- King of Spain (email@example.com), August 10, 1999.
It also illustrates what an excellent job of concealing complexity we've done with our old enterprise systems. Only when a major change or a whole-hog system replacement with a fixed deadline is required do we actually see just what a messy beast our underlying software has become.
I would venture to say that 20% of large/middle class companies are in "Hoff" shape
50% are in "y99? (firstname.lastname@example.org)" shape
and 30% are in "shit" shape.
-- a (email@example.com), August 10, 1999.
Y'all miss my point. This post is a good illustration.
Implementation of SAP, or any other new development, can cause large problems. No argument here.
But these problems can and do appear in virtually every aspect of the software.
Unlike Y2k problems, that are restricted to a much smaller subset of the code, in date processing.
Like I've said before, more and more I'm of the opinion that, with the massive number of new development/new systems being implemented, that right now, we are experiencing larger error rates, of greater magnitude, simultaneously, than we will experience at rollover.
-- Hoffmeister (firstname.lastname@example.org), August 10, 1999.
Hoff --- You're nuts. But not worth discussing. Not much longer now.
-- BigDog (BigDog@duffer.com), August 11, 1999.
er, not quite Hoff...go back to sleep.
-- a (email@example.com), August 11, 1999.
Sounds to me like the proper config and data was not present. The company sounds like it had a severe Y2K problem, and forced the implementation of new software before the company had prepared and fed it the right data. Add an obviously inexperienced or ineffective consulting integrator to an inexperienced client, and you get a mess.
It's easy to blame software. It's just an inanimate object. Harder to blame poor project management.
Odds are the very few really experienced consultants on board voiced their concerns, but they were ignored.
-- Spanky (firstname.lastname@example.org), August 11, 1999.
Thanks for the, ummm, enlightening comment. I'll give it all the consideration it deserves.
It is very apparent that Gartner Group is projecting date errors here.
"The biggest [misconception] is when the failures will occur," said Marcoccio, an analyst at Gartner Group Inc. in Stamford, Conn. In reality, only 8% to 10% of year 2000-related breakdowns will occur during the end of December and the beginning of January, he said.
Meanwhile, companies that have contingency plans aren't planning for them sooner, Marcoccio said.
Failures will begin in phases, he said: first in July as some companies enter their new fiscal year and face date issues that haven't been fixed or were fixed incorrectly, Marcoccio said.
By October, the number of failures should increase as systems that forecast the first quarter start to have errors and an additional one-third of companies enter their fiscal year, he said.
Also here: http://www.idg.net/crd_ pc_9-126963.html
About 25 percent of the eventual Y2K failures will happen before the Jan. 1, 2000 deadline, as computer systems increasingly need to interact with next year's dates, Morris said here. An estimated 8 percent of all failures will happen "within two weeks of Jan. 1, 2000," he added, with 55 percent happening sometime during the year 2000.
-- Hoffmeister (email@example.com), August 11, 1999.
No big deal. If one of the largest suppliers has problems and there are 80,000 or so suppliers to GM, then the auto industry is toast.
This talks about manufacturing orders but if these orders are not placed then there will be a delay in ordering materials. Love JIT.
It is the smaller companies that are further behind which does not bode well either. So much reliance on vendor promises will come home to roost.
It only takes one part and the vehicle cannot be shipped. Remember who said the word "catastrophic" regarding his industry?
-- Mike Lang (firstname.lastname@example.org), August 11, 1999.
I've said it before and I'll repeat it: I would rather go through lower intestinal surgery without anesthesia and antiseptics before I would go through another SAP implementation.
We spent three months bending our processes to conform to SAP's format plus another six recovering from the lost orders and production capacity the "bending" cost us. And we hemmoraged good people who couldn't put up with the heartburn of twelve and sixteen hour days, seven days a week, just to re-input data into the SAP system simply because SAP didn't come with a cross-compiler or data interpreter between the two systems.
SAP may be a viable Y2K fix for some companies, but the timeframe for implementing it was late last year or early this year. Anybody trying to adapt their operations to SAP's "Any color you want, as long as it's black." type of system is facing far too steep a learning curve to have success a guaranteed outcome.
WW and SAP: Been there, done that. Got the scars to prove it. SAP is Y2K compliant but
-- Wildweasel (email@example.com), August 11, 1999.