Every once in a while I write a post that’s crazier than most. These normally happen late at night when my internal defenses have given way to a glass of wine. This post is along those lines. The basic question that I’ll try to answer is “Will the Cloud and SaaS save the current roster of Enterprise Software from the Dinosaur like extinction of its forebears?”
I’ll start by asking what can you expect if you travel around the world looking for a tasty chicken dinner?
In Vietnam you can buy a live chicken, rest is up to you.
In China you can buy a chicken that’s been killed, you pluck and eviscerate and cook.
In Paris your chicken has been plucked, you eviscerate and cook.
In Des Moines the chicken has been plucked and eviscerated, you cook.
In New York the chicken arrives on your table plated, garnished and sauced
Now it may not seem like the world of software and the world of chickens have a lot in common, dear reader, but don’t give up yet. There is a point that I want to make here. A recent conversation with the Enterprise Irregulars around the difficulty of moving ERP systems forward with the business brought some interesting ideas to the fore. It all got started with an article by the now famous, in these parts, Thomas Wailgum in CIO about a study partly commissioned by CIO and Enterprise analyst IDC concerning this very question. Wailgum’s title says it all “ERP’s Paralysis Problem and the Repercussions for Businesses Everywhere.” The repercussions, as you might have guessed, are not good.
First,the premise, more exactly, is that ERP systems can prevent companies from seizing business opportunities because the systems are lumbering giants not given to flexibility, agility, growth and change. This leads us to conclude that the deeper the functionality of the ERP system the greater the difficulty of meeting business opportunity challenges. ERP in other words suffers from the New York Chicken problem: Once it’s served there is no turning back. You can’t change the recipe or cooking method at that point.
It’s an interesting thought. I am not sure that it is 100% on the mark, but having worked with Oracle ERP software for nine years I can attest from personal experience that there is more than a grain of truth here. Brain Sommer has a good post about some of the real sticking points in ERP systems that make changes and additions so difficult. This one stuck out:
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.
I’ll take the thought one step further – why do we have a code block, this huge accounting nightmare that attempts to pump all possible corporate knowledge about what the company sold and purchased into the general ledger from the subledgers where the transactions take place? When they began to create software for financial transactions they had only a general ledger, so to see as much data as they possibly could they tagged all the transactions in ht GL. Business software became accounting centric, and remains so even after real time relational systems came on board with multiple subledgers that can report out vast quantities of detailed information. Why do you have to update the GL with sales data when it exists in such fabulous detail in your CRM/Order Management system?
So what does a large enterprise do? They run Oracle, SAP, or something similar. Does the enterprise just forgoe new opportunities? I can’t imagine that , especially since the people who run large enterprises normally come out of sales and sales is where most of the new opportunities get their start. These folks are not going to be patient for long. Eventually the line of business, lob, will go ahead and start to do whatever they have to to tackle new business, even, in many cases, if that means writing custom software.
Now, developing custom software may not seem like such an odd pursuit to you and you would be correct – if it was the 1980s or earlier. But when so many large enterprises went to systems like SAP and Oracle they lost their development teams. That was the cost justification of the new ERPs. In the bad old days all large companies employed large teams of developers who built their custom business apps from the ground up on what came to be know derisively as legacy platforms, from IBM, Burroughs, etc. Coding custom software is like the chicken in Vietnam or China. Well, at least now you have more refined tools and platforms, so we will say it is more like China.
Well, apparently the wheel has turned again. Large Enterprises are again back to the custom software job enthusiastically and doing it with the aid of all the modern IT tools, platforms and business models – outsourcing, offshoring, onshoring, LAMP stack, Cloud, Free Open Source Software, you name it. They are coding software at a pretty good clip evidently, again in an effort to meet business opportunities.
Being on the cloud and developed in the SaaS, software as a service, model may help some of the newer entrants to the Enterprise software market avoid the New York chicken problem because the cloud can give a company greater access to partner software add-ons. But that is not a given. They must still walk a tightrope between offering a robust application that includes most basic needs while giving the Enterprise with more complex requirements a path to customize those requirements using the applications itself. Every NetSuite implementation, to be perfectly honest about it, requires a fair amount of explanation of what is not possible. You can run a lot of business processes in the system with no further customization and coding should be rare, but to have a system that truly represents your business today and your meets future opportunities, you will need to customize a quite a bit and code a little. It’s not an easy tightrope to walk obviously, and the balance struck is a subjective proposition.
However, I would also submit that every buyer contemplating the decision to move to one of these new enterprise systems should have a hard discussion about how much they want to customize and code, and how to do it in a way that prevents them from falling into the New York chicken problem themselves. For my part, I suggest that clients hold off on any customization except the most absolutely vital, and wait to add code completely, until you are live for six months. You will be surprised by how much your requirements will change once you know and understand the system.
The myth, not sure if it is still current, that SaaS prevented customization, has largely been itself eviscerated by Netsuite’s Business Operating System and Salesforce.com’s Force.com development platforms. These systems are not only open and customizable, they also encourage customers to make the applications meet business opportunity challenges.
Only time will tell if SaaS Enterprise vendors avoid the same fate as their older brothers like SAP and Oracle, but it is a good time to ask the question. Who would have thought 10 years ago that ERP would end up costing you money?
(Cross-posted @ Sightings in SaaS)
Check out Workday financials. There is no code block. It’s handled with tags, good old 2.0 tags. By the way, in HRM, the ERPs are equally confining because once you’ve set up your job code structure, not unlike your code block, there’s so much tied to it that changing it can be life-threatening. And we haven’t even talked about earnings types. Or was that infotypes?
I could not agree more Naomi. Job, Position and Grade blocks are all part of the organization as it was modeled in the 1970s-1980s. It’s now virtually impossible for these to have any meaning in today’s fluid, changing organizations. And yes, Workday and NetSuite have both avoided the accounting code block, but I know that NetSuite takes a hit for it from some in the market who think that a code block is a necessity – many of whom are, not surprisingly, CPAs. I think, judging by some of the defense of their system that I have heard, Workday also hears the same disbelief. Eventually we will convince these folks that it is a better world without such phony contraints.