When ERP Projects Get Derailed By “Silly” Reasons

by

According to the popular narrative, a software product should be highly customizable so that it can meet the customer’s specific requirements.

Often times, when customers say customization, they have in mind labels, forms and reports. Certainly all leading COTS (Commercial Off The Shelf) software products do support customization of this nature.

But when customization enters the realm of business constructs, processes and workflows, things can get tricky.

As Handelsblatt says, “Altering existing COTS software like ERP / SAP is like changing a prefab house. You can put the kitchen cupboards in a different place but you can’t move the walls”.

When customers ask for “shift the kitchen cabinet” kind of changes, most software vendors and implementation partners will gladly make them.

But when customers ask for “move the wall” kind of changes, most vendors will stonewall them.

(See “#2. RIGID V. FLEXIBLE” in Product Versus Services Selling – Part 1 for more insights into the behavior of software product vendors.)

Many of these changes might appear minor to customers’ business users. Therefore they might get frustrated by vendors’ stonewalling. Then the company’s honchos start asking their CIOs, if we’re paying tens of millions of dollars, how come we can’t get what our COOs and CMOs and CROs want?

CIOs in turn push back on the vendor.

Sometimes vendors are able to persuade customers to avoid such changes.

But sometimes they succumb to the customer’s demands. Those movies don’t have a happy ending.

Given below are a few case studies of what happened when leading software products needed to be changed in allegedly minor ways.

SAP-LIDL

In line with the best practice in the retail industry, SAP values inventory by Selling Price in its IS Retail solution. However, German retailer Lidl deviates from this practice and values inventory by Purchase Price.

SAP agreed to change the basis of valuation in its software to meet the €100 billion retailer’s differentiator.

The change created so many complications in functionality and performance that it eventually killed the project and caused a €500M loss. You can find more details at Lidl software disaster another example of Germany’s digital failure.

ERPCO-PETROCHEMICALS GIANT

ERPCo’s product conformed with the global trade best practice whereby goods can be shipped only after the LC is opened.

However, one of its customers, a petrochemicals giant, was used to receiving goods before opening the LC.

When their user champions noticed that the LC and Goods Receiving functionality of ERPCo went in the opposite direction to their customary workflow, the customer pushed back, saying we need goods fast and we can browbeat our bank manager to open the LC later, so what’s your problem, change the software so that it lets us do things our way.

ERPCo agreed.

Project bombed.

ORACLE FINANCIALS-GERMANY

All over the world, the supplier raises an invoice, submits it to the customer, customer issues a cheque after the agreed credit period, supplier deposits the cheque in its bank account, simultaneously credits the payment to Customer’s account, updates Accounts Receivable, receives the bank statement, verifies that it reflects the credit and files it.

In Germany, cheques are virtually non-existent. Payments are made via electronic fund transfers from customer’s bank account to the Supplier’s bank account. When they become due, the customer wire transfers the payable amount to the supplier’s bank account, bank issues a statement to the supplier, reflecting the credit, which triggers the Accounts Receivable update.

As you can see, in the rest of the world, the credit entry in the bank statement happens at the end of the Order-to-Cash process and is just FYI whereas it’s a trigger for a lot of activities in Germany.

Ergo a change was required in Oracle Financials to cater to the German market.

A preliminary overview of the change indicated that it was a “move the wall” and not “shift the kitchen cabinet” type of change. Detailed impact analysis confirmed that view: This change would rattle the basic structure of Oracle Financials and destabilize its data model.

Accordingy, Oracle refused to make the change.

In return, Germany rejected Oracle Financials.

Oracle Financials, which was the #1 financial accounting COTS in the world, did not feature even among the Top 10 finac software products in Germany in the early 2000s when digital payments in B2B was a thing only in Germany.

The very few companies in Germany who used Oracle Financials were German subsidiaries of foreign companies who had standardized on Oracle Financials globally. The German subsidiaries had to use Oracle Financials for the sake of uniform accounting and reporting worldwide, and needed to make offline changes to accommodate the different way in which Accounts Receivable was handled in Germany.

Changing the basis of valuation. Changing the sequence of activities. Changing the trigger event.

Minor changes, no? What can go wrong, huh?

Sadly, lots can go wrong in ERP. And do, as we saw in the above examples of three different ERP products.

It might seem silly to blame these changes for derailing major ERP projects. But that’s what happened.

In the case of SAP and ERPCo, agreeing to make the changes caused implementation disasters. In the case of Oracle, declining to make the change caused marketing disappointment wherein the world’s #1 financial accounting software was shut out of the world’s third largest market for its product category.

For some more ERP snafus, see 16 famous ERP disasters, dustups and disappointments.

Custom software developers – and even some entry level product implementation partners – might find this incredulous, but when it comes to software products, what appears to be a harmless Tiny Noticeable Thing could explode like TNT!