Enterprise System Spectator blog: ERP and enterprise system vendor evaluation, selection, and implementation.

The Enterprise System Spectator

Monday, May 12, 2008

Custom systems: alternative to ERP

Vinnie Mirchandani brings up an interesting point: outside of the manufacturing industry, the major ERP vendors have a much more difficult time breaking into core operational functions.

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

by Frank Scavo, 5/12/2008 11:58:00 AM | permalink | e-mail this!

 Reader 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
 

Links to this post:


 

Powered by Blogger

(c) 2002-2016, Frank Scavo.

Independent analysis of issues and trends in enterprise applications software and the strengths, weaknesses, advantages, and disadvantages of the vendors that provide them.

About the Enterprise System Spectator.

Frank Scavo Send tips, rumors, gossip, and feedback to Frank Scavo, at .

I'm interested in hearing about best practices, lessons learned, horror stories, and case studies of success or failure.

Selecting a new enterprise system can be a difficult decision. My consulting firm, Strativa, offers assistance that is independent and unbiased. For information on how we can help your organization make and carry out these decisions, write to me.

My IT research firm, Computer Economics provides metrics for IT management, such as IT spending and staffing benchmarks, ROI/TCO studies, outsourcing statistics, and more.


Go to latest postings


Search the Spectator!
Join over 1,700 subscribers on the Spectator email list!
Max. 1-2 times/month.
Easy one-click to unsubscribe anytime.

Follow me on Twitter
My RSS feed RSS News Feed

Computer Economics
ERP Support Staffing Ratios
Outsourcing Statistics
IT Spending and Staffing Benchmarks
IT Staffing Ratios
IT Management Best Practices
Worldwide Technology Trends
IT Salary Report

Get these headlines on your site, free!


Awards

2014 Best Independent ERP Blog - Winner

2013 Best ERP Writer - Winner

Alltop. We're kind of a big deal.
 
Constant Contact 2010 All Star Technobabble Top 100 Analyst Blogs


Key References
Strativa: Business strategy consulting, strategic planning
Strativa: IT strategy consulting
Strativa: Business process improvement, process mapping, consultants
Strativa: IT due diligence
Strativa: ERP software selection consulting and vendor evaluation
Strativa: CRM software selection consulting and vendor evaluation
Strativa: Project management consulting, change management
StreetWolf: Digital creative studio specializing in web, mobile and social applications
Enterprise IT News: diginomica


Spectator Archives
May 2002
June 2002
July 2002
August 2002
September 2002
October 2002
November 2002
December 2002
January 2003
February 2003
March 2003
April 2003
May 2003
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
September 2008
October 2008
November 2008
December 2008
January 2009
February 2009
March 2009
April 2009
May 2009
June 2009
July 2009
August 2009
September 2009
October 2009
November 2009
December 2009
January 2010
February 2010
March 2010
April 2010
June 2010
July 2010
August 2010
September 2010
October 2010
November 2010
December 2010
January 2011
February 2011
March 2011
April 2011
May 2011
July 2011
August 2011
September 2011
October 2011
November 2011
December 2011
January 2012
February 2012
March 2012
April 2012
May 2012
June 2012
July 2012
September 2012
October 2012
December 2012
January 2013
February 2013
March 2013
May 2013
June 2013
July 2013
September 2013
October 2013
December 2013
January 2014
February 2014
March 2014
April 2014
May 2014
June 2014
July 2014
August 2014
September 2014
October 2014
November 2014
December 2014
February 2015
March 2015
April 2015
May 2015
June 2015
July 2015
September 2015
October 2015
November 2015
February 2016
May 2016
June 2016
July 2016
August 2016
September 2016
Latest postings