The Slippery Slope of SAP Disconnected B2B ecommerce Websites

Written November 21st, 2011 by
Categories: CEO's Blog
1 Comment »
VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

I just ran into this post over at the SAP Community Network.  It’s a cry for help from an European SAP developer who is being asked to “harmonize” the batch orders that he is receiving from a standalone ecommerce website that his US business unit has developed.

Here is an excerpt of the requirement:

“Our US sales organization works with a non SAP ecommerce tool for sales of all materials. Every night (European time) a job is scheduled to send over the information about created orders and deliveries. As such orders get created in SAP.

Most often the delivery for these orders already occurred so they just want to deliver them out of SAP once the orders are created there. They do not want SAP to calculate the earliest delivery date based on ATP logic and routing because then they have to constantly set the delivery date in future during delivery creation.

Our US colleagues only mind of the stock levels which they constantly (every 10 minutes) update to their web based tool and which they want to be accurate all the time.”

So let me get this straight.  SAP has all of the information…Material lists, inventory, etc… and supports the requisite business processes…ATP logic, Deliveries etc…that the business requires, yet they have chosen to duplicate all of that in their standalone B2B ecommerce website??

Why?

Isn’t anyone concerned with the fact that they’ve now added a resource burden to maintain all of that information in two systems and…as the inquiry suggests…have to invest in making sure that they remain synchronized?

Actually, I know why.  Politics.

See this post for the research behind my conclusion.  I’m 99.9% sure that the US Business unit saw the need to “get on the web” and the folks in HQ who own SAP couldn’t quite fit it into their work schedule.  (Probably because they were too busy developing and supporting poorly designed “patches” to systems).  So the business unit goes ahead and builds their own website and drags IT kicking and screaming to support them with the “integration” into SAP.  The irony is that both organizations are now spending extra time and money to participate in a “forced conversation” with one another.  In this case, the unintended consequence of delivering orders in the ecommerce website first is that the CSR’s using SAP now have a harder time creating those deliveries manually.  Of course this spawns a project to change the posting process to relieve that burden…which will probably spawn another project to…and another and another.

That’s a total waste of human capital that could be applied to much more important business objectives.

By the way, I wonder how this company is managing the “post order entry” customer service requirements for tracking orders, reprinting invoices and reporting on historical purchases.  Let me guess…duplicate data in both the website and SAP and batch programs to synchronize the two.

What a waste.

The whole point of implementing SAP was to consolidate data into a central repository so that the entire enterprise could be working off of one set of business data and rules.  Why is it that when it comes to ecommerce websites, that that philosophy and architecture is so easily dismissed?

I guess if people can’t talk to one another in real time it’s no big surprise that the systems they support can’t either.

Sam