Upon returning last week from SAP's Sapphire conference, he writes:
I asked two SAP executives - Jim Hagemann Snabe and Bob Stutz - at Sapphire about such verticals [such as banking, utilities, insurance, and health care]. Jim acknowledged that legacy, typically custom-developed vertical applications, have been tough to displace particularly in the US. In a few deals where I have seen SAP vertical proposals, I can tell you the "displacement" is tough because SAP's [total cost of ownership] (particularly those of its SI partners) has not been compelling. You could custom develop that functionality again for cheaper. Just maintaining the legacy apps is even cheaper.True ERP is found almost uniquely in manufacturing firms
Vinnie hints at a point that is not widely recognized. In big companies, ERP--real ERP that forms the core transactional processing platform for cross-functional business processes of an organization--is still largely a manufacturing industry phenomena. Outside of the manufacturing sector what you generally have is custom-developed systems, or commercial software for specific business functions, interfaced (at best) with the "horizontal" (cross-industry) modules (e.g. accounting, HR) of the major vendors.
So, when a major vendor speaks of having a strong presence in healthcare, banking, or insurance, what they mean is that they sell a lot of their accounting, HR, business intelligence, or CRM modules into that industry. What they are not doing is replacing all the industry-specific systems for those customers.
Now, to be fair, Oracle is an exception in certain industries. In 2005, Oracle acquired I-flex, a vendor of core banking systems. Earlier that year, Oracle acquired Retek, a leading provider of retail systems. But still, it would be really, really interesting to find out how many of Oracle's customers are running all Oracle software, now three years later. I'm sure there are some, but I doubt there are many.
The reason is that the manufacturing industry has had over 30 years to figure out how cross-functional business functions should look in an integrated system. Starting with the so-called MRP revolution of the 1970s and continuing with MRP II systems of the 1980s, and ultimately ERP in the 1990s, there is now pretty much widespread agreement on the logical architecture of an integrated system for a manufacturing enterprise.
Business case often weak for replacing legacy systems
Today it is rare to find a manufacturing company writing its own material planning or shop floor control systems. Perhaps in some very specialized niches, but it's rare. Not so in banking, or insurance, or retail. Those industries are loaded with examples of companies that continue to run the core of their businesses with custom-developed software. The business case for replacing those systems--especially with those of a vendor that wants to charge 22% of the net license fee, annually, for maintenance (i.e. Oracle and now SAP). Maybe for HR, or financials, where I can justify the cost in terms of not being responsible for regulatory changes. But for my core systems? No way.
Again, for smaller companies, I think packaged software makes a better business case for non-manufacturing sectors. Many have far less investment in legacy systems and have far fewer resources to develop or maintain custom systems. But for large multi-national organizations in, say, banking, insurance, energy, transportation, or utilities, it's hard for me to imagine them standardizing all of their core operational systems on a single vendor such as SAP or Oracle.
I would love to be offered some evidence to the contrary. If you know of any, let me know.
An alternative to ERP
Where does this leave organizations that do not see the value in replacing core custom systems? The answer is to make an investment in refreshing such systems. For a fraction of the cost of ripping out and replacing legacy software, an organization can make a concerted effort to invest in modernization, training, documenting, and even redeveloping these critical operational systems.
Such an approach has its own drawbacks, of course, in terms of an organization's ability sustain a professional software development team. But in terms of overall cost and risk of disruption, refreshing a legacy system can be an attractive alternative.
Update, May 13: Sigurd Rinde writes in the comments section that ERP has not taken hold in certain non-manufacturing sectors because business in those sectors is largely non-transactional:
...the core for health, government, education and consulting is mainly Barely Repeatable Processes where each event/task can lead to many user chosen changes to the workflow path (a physician with an Xray in hand..)I disagree. Core processes in healthcare, for example, are highly transactional: appointments, patient visits, diagnoses, treatments, patient charges, prescriptions, insurance claims, reimbursements--these are all transactions. The fact that EDI is such a big part of healthcare confirms the transactional nature of the business.
Rather, I think the problem goes back to the history of application development in each industry. I may be not as familiar with the evolution of business systems in non-manufacturing sectors, but I don't believe there has been the same concerted effort in such sectors to establish a standard view of core business processes as there has been in manufacturing. APICS played a big role in this effort, and I don't know of a corollary in other industries. Again, my knowledge may be limited, so I welcome correction on this point.
More discussion between Sig and me in the comments section.
Related posts
Oracle moves into core banking applications
10 comments:
Thanks for the link. In fairness SAP does have many customers in retail, banking, utilities etc in German Speaking Europe. Breaking in to global markets with local nuances has been a challenge. And the TCO is really blown by proposals I see from its big SI partners who can talk a nice vertical game, but often do not have knowledge of the vertical SAP modules - or if they do expect a significant premium. Cost of custom development on the other hand has been dropping nicely with offshore models and automation advances. And some verticals like mortgage processing got tired of waiting and have adopted BPO for many of their unique processes.
Excellent post (and thanks Vinnie for the link!).
My immediate reaction is that the crux lies in "transactions", the basis for classic ERP - works nicely for Easily Repeatable Processes as they tend to be at the core for manufacturing (and logistics heavy retail).
But the core for health, government, education and consulting is mainly Barely Repeatable Processes where each event/task can lead to many user chosen changes to the workflow path (a physician with an Xray in hand..).
This cannot be done properly if the basis is "transactions" methinks. Banking is quasi in the middle - core is 'logistics and transactions" while much of the value creation would be BRP.
In my humble opinion I do not even think the legacy ERP systems will ever be able to do much good in the BRP area - perhaps "proven" by your observations.
Frank,
ah, semantics perhaps? What's a "transaction"? When I give you a ten dollar bill? Or when I also tell you "now it's yours"? That would not be enough under Napoleonic law in France, you would need to sign with "Lu et approuvé" before it would be a legal transaction... US GAAP defines specific transactions different from a German GAAP say.
Back to the core processes of health, let me rephrase and avoid the iffy term "transaction":
Such processes are Barely Repeatable, and with that I mean each task/event have a multitude of choices after each, looping, forking into parallels, and not necessary conditional at all, but certainly user decided at that stage in the flow. The Easily Repeatable systems (that BTW are event or transaction driven) cannot cope with that. They might have a few alternative paths built in, usually conditional as in "if more than 10k then boss must approve".
The transactional concept is too rigid - how could an event be transactional if you do not control the next step? Diagnosis would not be a simple event, it would be a process that can, and do, take many paths - xray, study that, blood test, check it out, another expert... and so forth. Where does the transaction take place there I wonder? Sure you can define "transaction" to fit it, but then it would be a term rather different from a "sale" kind of transaction. What "passes hands" during the diagnosis process? I might add.
Sig, all good points. Certainly, what goes on "inside" the diagnosis transaction may be highly dependent on the actor's judgment and knowledge. That doesn't need to get captured in a system.
What does need to get captured is the input and output from the transaction (diagnosis). E.g. Patient A came in at such and such a time and saw Doctor B, who determined that Patient A had strep throat.
But remember the original question: why has packaged ERP systems had such a difficult time replacing custom systems for core processes in non-manufacturing sectors? There are transactional systems in healthcare capturing such information today. The issue is, why has packaged ERP had such a difficult time displacing them?
I maintain that it is because of the history of business applications in each industry. Early in the history of manufacturing systems, a fairly standard way of conceptualizing business processes was agreed upon, much through the work of people like Ollie Wight and George Plossl. Commercial software vendors embodied these concepts in packaged software. Other industries do not have a similar history.
Frank,
I do agree with you - but I'm more into "expanding" the status quo a bit:
Exactly what you're saying here about the diagnosis hit me after I commented last - it can indeed be seen as a single task. Everything can in fact. Go and find the South Pole could have been a single task for Amundsen...
Thing is: Splitting that multi-sequential single task called diagnosis into the separate events and sequences it entails has a lot of value. You get accountability and ownership to each step (important for efficiency and for legal reasons), you get an opportunity to better the process (to better you have to know it) and you have a chance to create a framework that delivers the best practices you have created (and still do every day).
If I'm cheeky and risking going out on a limb I would say that the diagnosis-as-a-single-task is a result of the need to adapt reality to a model (earlier days accounting and hierarchies, today the ERP systems). Reality is a sequence of in fact single events so why not use IT to map, deliver and report on them as they are?
Lastly I think you have a good point for the "history", but allow me to add another aspect of the same issue - and that is IT have stubbornly modelled another existing model. The existing model was the way we developed methods (models as they are) to handle reality when the technology available was pen and paper or even less. Examples for me are organisational hierarchies (framework to steer resources) and accounting (control and reporting of what has happened).
Is it not time to ditch, or at least question the viability of those old-technology methods and rather apply IT for what it's worth?
Sig, finding the South Pole could have been a "single task," but if Amundsen were using an ERP system to support his endeavor, I think he would have been better served by treating it as a "project."
Perhaps there might be value in breaking up medical diagnosis into a "sequence of single events" instead of one event, as you say. The question is, though, whether users of healthcare business systems find it necessary to capture that much detail in those systems. I would argue that, right now, they don't. At least here in the U.S., it has been a tough sell to get medical doctors to adopt electronic records at all, as they often find that such systems slow their productivity. In the U.S., they are usually paid by how many patients they can see, and anything that slows them down is viewed as an impediment to their earnings. This is what I'm told by IT folks trying to implement medical record systems.
There might be great value to the hospital as a whole (and to patient, and to society in general) to have such detail captured at the point of treatment, but at the cost of the physician's earnings.
So, theoretical value is one thing. Getting users to actually change their practice at a very elemental level is another thing.
But this is true, whether the system is an integrated ERP system or a point solution.
Frank,
(appreciate your stamina in the discussion! Allow me another little one... :))
There will always be a requirement to "simplify" so as not to get bogged down - but is it the right way to simplify the process model as is always done?
Allow me to suggest that there is a much better way, and that is to step back one step and question how we represent the real-world-objects. It be a "medical condition" or a "widget" in production:
In reality we have singular objects, but in an accounting system or the based-upon-double-entry-bookkeeping transactional systems the real-world-object is not even represented, it's represented by transaction documentation/objects like invoices, bills of lading, reports, order forms, sales slips and whatnot.
That leads to, in a transactional system, that one real-world-object is represented by ten, fifteen, or more transaction-objects. As complexity is a result of number of objects and their relationships such a system would have appsoximately number-of-representations squared relationships. In short a transactional system with ten transactions per object would be approximately 100 times more complex than reality.
What I'm saying is; use IT to model the reality as it is, skip transactions as a model completely at the front-end and map transactions from the back-end - that would give a fraction of the complexity and allow ample room for a true representation of all steps in any flow which cannot be denied is a good thing regarding accountability and control. Basel II and SOX are requiring it in principle...
Cheers,
Sig
Any good system design will model real world objects. That is the basis for object-oriented design (a term that for some reason seems to have fallen out of favor in the past few years).
But I would argue that in some of your examples, what you are calling transactions are in fact real-world objects. It's just that some are tangible and some are intangible.
A shipped widget is a tangible object. An invoice reflecting the fact that the customer owes me money for the shipped widget is an intangible object. I don't mean the paper invoice, I mean the obligation of the customer to pay me.
A bottle of penicillin is a tangible object. A diagnosis that I have strep throat is an intangible object. But both are real-world objects.
A good entity-relationship diagram (ERD) is a model of the real-world, and, as you know, even in a simple example they can be quite complex.
Back on the original point: I do not see that business processes in manufacturing are any less complex than in non-manufacturing sectors. Therefore, I do not think this is a reason for the failure of fully integrated ERP to have wide adoption outside of manufacturing.
Any good system design will model real world objects. That is the basis for object-oriented design (a term that for some reason seems to have fallen out of favor in the past few years).
But I would argue that in some of your examples, what you are calling transactions are in fact real-world objects. It's just that some are tangible and some are intangible.
But remember the original question: why has packaged ERP systems had such a difficult time replacing custom systems for core processes in non-manufacturing sectors? There are transactional systems in healthcare capturing such information today. The issue is, why has packaged ERP had such a difficult time displacing them?
Post a Comment