Oracle vs. SAP - Battle of the False Gods

Regular readers know that we have a pretty low opinion of MRP/ERP software and in general prefer the simple excellence of manual visual systems for shop floor control.  It's not that we're luddites living in fear of new technology, but instead it's that technology can have an annoying habit of covering up waste.   A wasteful process that is carried out with extreme methodical efficiency is still a wasteful process, and as such it adds no value to the customer.

So you can understand my amusement and perhaps outright frivolity when I read about Oracle suing SAP.  A battle of the titans!  A duel of the supreme false gods of the almighty algorithm!  What could be more fun to watch, except perhaps Florida taking on UCLA in the NCAA final four this Saturday?

The lawsuit is obviously no laughing matter, although the allegation is of an ingenious attempt by SAP to offer better and cheaper customer service on Oracle products to Oracle customers than Oracle itself does in order to eventually convert them to SAP.  Get that?  Pretty neat trick, eh?

Just before Oracle completed its acquisition of PeopleSoft, 37 PeopleSoft support techs created a new company called TomorrowNow, based in Bryan, Texas.  SAP rapidly snatched them up, closing the deal at almost the same time as Oracle closed the PeopleSoft deal. 

Oracle's lawsuit alleges that SAP TomorrowNow (SAP TN) then began to access Oracle's protected customer support databases, using usernames of PeopleSoft (now Oracle) customers that would soon expire.  Massive downloading of technical and support documentation was recorded and traced back to Bryan, Texas.  SAP then went after Oracle customers and offered them support on Oracle products for half the price of Oracle's own support.  The program was called "Safe Passage," as it was intended to offer a "safe" pathway to migrate from Oracle to SAP products.

Oracle confessed to wondering how a small company like SAP TN could develop and offer "customized ongoing tax and regulatory updates," "fixes for serious issues," "full upgrade script support" and "most remarkably, '30-minute response time, 24x7x365' on software programs for which it had no intellectual property rights" at "50 cents on the dollar, and purported to add full support for an entirely different product line with a wave of the hand.

No kidding... that does sound a little suspicious.  It's rare to get that level of support at any price... even from the actual creator of the product.  Let alone its archrival!  Stay tuned; this duel will be going on long after UCLA takes the crown.

Comments

[robert thompson]

I would agree that traditional MRP systems promote push not pull. However, the business intelligence of some ERP systems can be complementary to lean. I do agree though that simple, visual systems are the easiest to follow and avoids the search for the next greatest piece of planning software viewed as a panacea to all problems.

Rob

[Brendan O'Malley]

Ron Pereira had an excellent post in the last few days on the zealots who badmouth everything that doesn't belong to their particular chosen mission. MRP systems were developed to assist in planning for the future. The context at the time was the accepted paradigm of mass production. Lean production overthrew many of the concepts of mass production and demonstrated that it was much better to pull products through a streamlined and rapid production operation to serve actual customer demand than it was to spend lots of computer horsepower on the dynamic rescheduling of WIP. We have learned that much of what was done in the heyday of MRP was wasteful and unnecessary. But let's not throw the baby out with the bathwater. Planning is still needed. Mangers need as much notice as possible of growing or changing demend patterns that will require the addition or modification of capacity beyond the day-to-day fluctuations that a good lean process should be able to digest. You can't build a new plant without recognising theneed for it well in advance of when capacity runs out at your ewxisting one. Even more so, your suppliers need to know that they need to do something about their capacity if your demand is likely to exceed what they can manage today. A good S&OP process addresses these issues and uses tools like rough-cut capacity planning RCCP originally developed for MRPII implementation.

It always mystifies me that there is so little mention of planning on the Lean literature. Planning may have been given a bad name in the past, but eliminating the muda to focus planning on where it is needed is just as Lean as optimising flow through a work cell.

[Kevin]

I think we're actually arguing the same thing from the same side. As I mentioned in the first couple lines, I don't have a problem with new technology, even software. However I believe you must be very careful with it as it is easy for it to cover up a wasteful underlying process. First make sure the underlying process is as efficient and waste-free as possible, then use available technology to take it to the next level. I've seen far too many SAP and Oracle implementations that have automated inefficient processes, or in other cases have forced changes in efficient processes because they didn't map directly to how SAP/Oracle/etc "wanted" to do things. I am also speaking more to the shop floor itself, where even Toyota doesn't use computerized scheduling. For external gross scheduling and capacity planning, and the automated communication links to suppliers, such systems can make a lot of sense.

[Mike L]

UCLA is going to take the crown? You must be crazy. Gator bait baby!!! I love your blog by the way.