Recently, I attended briefings that Unit4/Agresso held in Boston. These briefings predominately concerned their CODA business unit.
In the last year or so, Unit4/Agresso has commissioned research projects with CFO magazine and IDC. The most recent research certainly generated a lot of discussion at the event and it continues to drive conversations within the blogger community. Specifically, I’ve participated in blogger conversations re: this research at the recent SAP Influencers Summit. Enterprise Irregular bloggers have been conversing about it, passionately I might add, this week, too.
So, what’s in the research and why is it sparking so much discussion?
The report is titled: “Modifying and Maintaining ERP Systems: The High Cost of Business Disruption” (IDC, author: Michael Faucette, December 2009). You can download this report here . Additionally, you can download the prior CFO report, “The High Cost of Change for ERP”, by CFO Research Services, from CODA .
The purpose of the IDC research was to see how a software customer is impacted when they must make changes to ERP software to accommodate software or business driven changes. The research looked at the experiences of over 200 software customers and the disruptive impact that ERP software changes had on their firms.
Building off of the prior CFO research effort, IDC focused on the top five drivers of systems change:
- regulatory requirements
- organizational reorganization/restructuring
- mergers and acquisitions
- financial management-driven changes
- new or changed business practices
From these, IDC reviewed nine categories of disruption cost metrics. These included:
- decreased operational efficiency
- decreased decision-making efficiency
- delayed cost reduction plans
- drop in customer satisfaction
- delayed product launch or increased product time to market
- lost market share
- payment of fines for noncompliance
- missed opportunity for or delayed an acquisition
- decreased stock price
Now, this part is really important to understand. The study respondents were asked to report if they experienced any of the disruption cost categories for each of the five top drivers of systems’ change. IF THEY DID, they then had to choose from a list of estimate ranges that defined the extent of the disruption they encountered. IF THEY DID NOT, no estimate was given and those null responses were not added to the basis.
So, when you read the report and you see that under the Reorganization/Restructuring change driver there is a score of 22.6 for Decreased Stock Price, this means that of those firms that undertook an ERP systems change due to a restructuring or reorganization AND experienced a drop in their stock price, THEN the stock price fell an average of 22.6%.
The data in this report will make you think as it puts some numbers behind the cost of change for ERP beyond the usual technical costs. The cost categories aren’t fees paid to hardware vendors or to systems integrators, these costs point to factors like lost market share and fines for non-compliance.
ERP software vendors that are still selling products that:
- are hard to update
- take too long (and require too much effort) to upgrade
- require the use of systems integrators or vendor consultants to implement
- can’t quickly absorb customary business changes
- etc.
are really out of sync with the modern business.
Today’s businesses need to change on a dime. They need to enter and exit global markets in days not fiscal years. They need to modify their product mix constantly to include widely varying collections of services and products. They have to respond to competitor and commodity price changes in seconds, sometimes milliseconds. It’s a high velocity business world full of low velocity software.
Bob Warfield, one of the Enterprise Irregulars, asked the question du jour: What is it about ERP solutions that make so many of them so impossible to change or change quickly and cheaply? Bob tossed out a lot of examples and here are mine:
1) Customer is part of the problem - Customers can be their own worst enemy if they make too many modifications to the package. However, in defense of these customers, if the packages could deliver the functionality needed in that industry many customizations might not be needed.
2) Archaic data models – When some of the ERP solutions on the market today were first conceived, there weren’t relational data bases, disk drives held mere megabytes of storage, etc. Those were constrained times and vendors developed clever ways to deal with constrained CPU speeds, limited batch windows, expensive DASD, etc. As time went on, the cheap thing for vendors to do was to port the old data model to a new technology. While it works, it’s not optimal. Worse, systems designed for constraints are really rigid as pieces of data are scattered across multiple systems, databases, etc.
3) Conflicting Reporting Structures – Some ERP solutions, incorrectly, assume that all companies and all reporting structures are perfect command-and-control hierarchies. They’re not. Yes, I need my subsidiaries/legal entities to roll-up in this fashion but people on project teams, ad-hoc groups, cross-functional teams, etc. do not. If the data is stored hierarchically, then doing anything different is tough.
4) When the accounting calendar isn’t the business calendar – Some firms use accounting periods that aren’t calendar months. They may close their books daily, weekly, hourly, on a 4-4-5 basis, etc. But, sales compensation plans may be on a different basis. What happens when the company wants to introduce a new, special sales commission/incentive that starts somewhere in the middle of the month and only runs for three days? Time should not be defined only by the accountants. Corporate timetables vary a lot and flexibility for same should be in ERP solutions.
5) Code block insanity – Just because your accounting modules can support a 30 segment code block doesn’t mean most companies should use this. Moreover, what views a company will want in its code block will change over time. Unfortunately, most financial software products (and all the feeder systems that supply accounting transactions to them) make changes to the code block akin to a complete re-install of the software. Nothing brings rigidity to ERP like the code block.
6) Vendor’s assume accounting is a constant – Double-entry accounting came into being in 1495. Many ERP vendors would be very happy if it didn’t change again for another 500 years. That’s not realistic, though.
7) Too much redundant data – When the same data (or variants thereof) are stored in the general ledger, subledgers, extended general ledgers, data warehouses, reporting databases, etc., change can’t come easily. Too many places must be fixed, adjusted or repaired when the data changes.
8) Too many acquired products – When a vendor buys many of their suite components, they might slap a new user interface on these products to give the appearance of an integrated solution. But, under the hood, you’ll find spaghetti wiring that’s interfacing one application/tool to another. It’s not elegant and it’s really hard to make fast changes with so many non-standard components built by different teams with different tools and designs.
9) Vendor’s assume implementations, upgrades, etc. are not their concern – If you never think about these costs and how your products add to them, you don’t design in efficiencies for your customers. ‘Nuff said.
FTC Blogger disclosure: Unit4/Agresso provided or will reimburse my hotel accommodations and some travel costs. Unit4/Agresso did not pay for my time or for anything I may write or may have written concerning this event.
