SAP Projects and the "Big Bang" Theory

A fellow IBMer saw some of my previous posts about navigating the SAP maze from a custom development point of view and sent me an email basically asking the question "Can SAP projects be iterative? All the ones I've ever seen always seem so 'big bang.'" The more I thought about his question, the more I realized how reasonable the question seemed to those of us who've been building custom applications. After all, how many small SAP projects have you seen? How many have put something in production in 3 months? Don't most of them have budgets in the tens of millions of dollars (or even more)?

I decided to pose his question to a "real SAP consultant" I met recently. She claimed that SAP projects can be iterative. An project can cycle thru multiple iterations of the ABAP programs used for point-to-point integration with SAP (the old style integration pre-dating XI) and companies can and do gradually add new modules to their SAP environment. (This is probably more incremental vs. iterative).

I challenged her "don't the customization done at the beginning of an SAP project drive the generation of database schemas? Aren't these database schemas hard to change?" She said she typically isn't involved in that kind of SAP setup but that it could be done. There was, however, a catch. Such a change would probably require some kind of data migration project associated with it to move data from one schema to another. My gut tells me these data migrations are almost always painful. There is a reason IBM acquired Ascential a while back. The phrase Master Data Management (MDM) is familiar to all SAP consultants. If your client is looking at SAP, you'll get familiar with it too.

I think this may shed light on why SAP projects appear to be such a "big bang". Most companies do not want to support more than one system of record simultaneously. (The "E" in ERP stands for "Enterprise" so otherwise you are taking the "E" out.) They want SAP to take over all of whatever it is doing (for example the order to cash process). Otherwise you get into a need for the new SAP and the old legacy system to exchange a lot of information to keep each other "in synch" with what they are doing. Everyone these days wants their data up-to-date in real time so that probably means real-time synchronization.

I know of a company facing exactly that kind of decision. They don't really like the idea of rolling a new system out across the whole company. They'd prefer to roll new capabilities out to a single line of business first. But... each line of business shares a lot of the same customers and dealers. They often share warehouses. Shipments to customers often contain a mix of products from different lines of business. With today's legacy systems, customer can mix products from different lines of business on the same order. Imagine the implications of changing the order to cash process to a new SAP system and rolling it out to only one line of business at a time:

• Do I track inventory in two different systems?
• How do I load a truck at the warehouse if the shipment includes products from both systems?
• How do I keep up with vacant storage bins in the shared warehouses if the inventory is split between two systems. Do I draw a line down the middle and and disallow putting line of business A's inventory on the line of business B side of the line?
  
• How will I generate the pick list for the people that load the trucks? Will they have to work from two lists? How do yo make sure it'll all fit on the same truck?
• Dealers don't have to split orders by line of business today, will they have to split their orders into two separate orders tomorrow while we're in transition?
• Will customers have to check the status of different line of business orders separately?
• Will my dealers get a single invoice with all line items like today? or will they get two separate invoices, one for each system?
• Will dealers get a single monthly statement?... or two separate monthly statements?
• When a dealer visits the B2B website today they can order products from different lines of business from one screen. In the future, will they have to go to one screen for one line of products and to a different screen for the others?
  

So, the choices are clear (or is that murky?):

• Offload the data integration onto your employees and customers; making them deal with separate orders, separate shipments, separate invoices, separate statements, etc. OR
• Spend millions on middleware solutions to broker all transactions so that they all look to the external customer like there is a single back end system OR
  
• Put the "E" back in ERP and don't even try to roll out an order-to-cash process until your whole business (Enterprise) is ready.
  

Which would you choose?

Copyright © 2006 by Philip Hartman - All Rights Reserved

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.