My previous blog post on the benefits of commercial enterprise systems, which was a response to an article by Cynthia Rettig, generated some interesting comments, both on my blog and elsewhere. The ones that caught my eye argued that companies were digging themselves into a deep, dark, hole of complexity by deploying these technologies:
"Rettig is looking forward and McAfee is taking the historical perspective. In summary, information technology has been good for business to date, but we’re at an impasse where, as the saying goes, past performance is not necessarily indicative of future success." – comment on my blog from Philip Sheldrake
"Also, I think Rettig’s larger point… is that ERP systems… may hinder companies from capitalizing on potentially more flexible and simpler systems going forward." – comment on my blog from Nick Carr
"McAfee’s critique, however, doesn’t address Rettig’s larger point, which concerns the effect of ERP’s complexity on companies’ choices going forward." – from Rough Type, Carr’s blog
When it comes to enterprise IT architectures, everyone agrees that complexity kills. It adds to expense, decreases reliability, and makes system accidents more likely. Everyone also agrees that modern commercial enterprise systems (like those sold by SAP and Oracle) are unbelievably complex pieces of software. So it’s a short and easy logical leap to conclude that companies that buy enterprise IT are killing themselves, or at least mortgaging their futures in a demonstrably counterproductive way.
The flaw in this logic is that it ignores the differences between system (or design) complexity and module complexity. A company’s IT infrastructure is a system made up of many interdependent modules, or discrete applications. These modules interact with each other in many, many ways, but they also do some purely internal work. An SAP ERP application (module A), for example, might receive an order from a Web front end (module B). This order triggers a number of purely internal events within ERP – decrementing inventory balances, preparing billing paperwork, printing out a pick list in the warehouse, etc. The order also yields a commission payment for a sales rep. Data about this payment is sent to a CRM application (module C), which salespeople check obsessively from their Blackberries.
The key distinction here is that it’s SAP’s responsibility to configure, test, and maintain all the logic and data flows that are purely internal to ERP, while it’s the CIO’s responsibility to do the same for all the activities that flow between systems. And of all the complaints I’ve heard about commercial enterprise applications over the years, I’ve rarely heard that their internal logic was messed up – that they kept losing orders, double-paying sales reps, and so on. And when I have heard such complaints during an implementation project, it’s almost always turned out that an interface with another system was to blame. Enterprise systems can be terribly difficult to configure, but if and when they are properly configured their internal logic generally works. CIOs who want to minimize complexity can "set ‘em and forget ‘em." A complexity theorist would lump all that internal logic together as a ‘hidden module‘ and ignore it, concentrating instead on all the interfaces between modules.
The counterintuitive result is that adding a wildly elaborate and complicated module can significantly decrease system complexity, if it replaces a number of older modules whose interactions required babysitting. If the PC I wrote this on had a motherboard I’d built myself from scratch, I’d have to spend a lot of time troubleshooting it, and making sure that every new peripheral I added didn’t destabilize the whole machine. I’d be smart to just replace the whole thing with a ready-made and pre-tested motherboard. If I tried to build a motorcycle engine from scratch and put it in my bike I’m sure I’d spend no time riding and all my time fixing. Even though my Ducati’s desmodromic engine is complicated even in comparison to its peers, it gives me no headaches and I never think about it (except to feel cool ’cause my bike has a desmodromic engine). Some very talented people in Bologna dealt with its complexity, so I don’t have to.
Companies that go through the hard work of deploying enterprise IT and shutting off some of their pre-existing legacy systems are reducing their complexity, not increasing it. They might be mortgaging their future in other ways with this IT architecture choice (although I doubt it, which is a topic for another blog post) but they’re not setting themselves up to be overwhelmed by complexity somewhere down the road. Instead, they’re reducing the number of modules in their system.
{ 18 comments… read them below or add one }
Are you therefore arguing for monolithic, all-singing, all-dancing enterprise systems? Outsourcing ALL the complexity to the vendor? How far does that argument hold up – do you ride the Ducati, or does it ride you?
Or do we have to embrace some level of complexity to ensure SOME competitive differentiation, but be selective about it? After all – “if someone else can buy it too, it’s not strategic” (apologies – can’t remember who said that)
I think you have a point there. Lets not blame the ERP packages themselves. To an extent, I think the vendors should carry that … They have been selling the idea that with an ERP, the managers only need to come to the Office, switch on some mythical machine (where the answer is 42?????), and go play golf for the rest of the day!
Somewhere, what was lost in all the debate was that ERP is a tool. Nothing more, nothing less. And, like any other tool, its as good or as lousy as the person using it.
Both SAP and Oracle have had successful implementations, and implementations which have been disasters. So, is it the package? Maybe its the consultants. They have had all kinds of implementations with the same set of consultants, whether an Accenture, or IBM, or Wipro, or Infosys, or TCS, or Satyam. If we take this logic forward, the one thing we can isolate is the commitment of the managers in the organization. Commitment to change, largely … I dont think any of them are inherently allergic to ERPs.
Very clear and compelling! And I would agree fully given that IT systems will forever consist of “modules”…
Today modules, cutting up the complete value adding flow into applications where logic is applied to data while supporting tasks or amassing data, is the solution. Of course.
But, that way of organising the flow has not changed since before IT entered the scene, the way was built using pen and paper and IT merely copied that “model” – and complexity ensued obviously.
A more holistic view, shedding what is taken for granted in the way the total flow is organised might one day replace the “modules”…
But funny enough there my argument bites itself in the tail as the worst culprit, the biggest complexity factor overall, I would argue, is not the core ERP etc systems, it’s the widespread use of disparate applications that must be shed – thus the argument is for investing in core systems as long as they’re architected to include more than the easily repeatable and linear processes over time. But that’s really not happening yet
Hi Andrew,
I like to make a case on complexity. We like simple things. We can almost tempted to say that the only things that works fine are the simple one.
A Ducati is not simple. Its engine has so many details that it was amazing to see how many people supported Casey Stoner yesterday at the GP prize of Czech Republic.
I am a mathematician, when it comes to algebra, the simple is beautiful, but not always the beautiful is possible. When it comes to Algebra ring, field and functional analysis simplicity is not possible. When is comes to calculus, the partial differential equations solutions are not simple either.
What it kills any system is make a layer of complexity when not needed. However Cynthia, was trying to oversimplify the help an ERP has caused to companies buy taking in account only the difficulties and not the benefits.
Cynthia is looking a football game watching only one field goal.
Mario Ruiz
@ http://www.oursheet.com
Professor – good analogy with the Ducati – except the ERP Ducati would be the equivalent of 2 cylinders humming along, but the other 6 needing to be housed in other older engines …the coverage of ERP is much lower than advertised, and the cost per square inch of coverage way high…see my post
http://dealarchitect.typepad.com/deal_architect/2007/08/making-your-com.html
The Ducati analogy points to the eventual replacement of most in-house systems with utility services, no? Why spend a lot of time and money fiddling around with your own data center and all those hardware and software modules when you can get some very talented people in Bologna (or Mountain View, or wherever) to do it for you?
In an ever changing technological world, the flexibility of the ERP is unfortunately meek and bleak. Its altruistic intent was to centralize (and expedite) various business processes within a corporation, yet its legacy will be that of an albatross.
ERPÂ’s were purported to rationalize efficiencies and speed up the transaction, whatever that transaction may have been. The problem? They couldnÂ’t and cannot keep up to the demands of the ever changing technological world.
Web services, and for that matter SOA, is the proverbial wave of the future, yet the investment spent on the deployment of the ERP in today’s corporation ensures companies will continue to lean on Oracle and SAP ‘future enhancements’. This can only result in additional monolithic modules developed by these two giants whom try to keep up with the Joneses, whilst working on SOA integration with relevant 3rd party players.
There are web services and SOA naysayers out there for certain, but its early days, and frankly I would rather have a barebones ERP in place, and build off of that with a proper web services/SOA plan in place to allow for integration with vendors that specialize in modules that are relevant for the business Â… and that work.
In my experiences, IT managers have rarely chosen complexity over simplicity. No one wants an unnecessarily complex system. IT environments get unwieldy because of the existing infrastructure. The infrastructure is recalcitrant so while each additional piece of module functionality maybe simpler, because it is tying in with a legacy, dated infrastructure it becomes complex. Also, keep in mind that when that legacy infrastructure was first installed it was probably considered simple and replaced something more complex.
So yes, shutting of preexisting legacy systems wherever possible makes sense. The ERP vendors aren’t trying to make their software more complex and nor are the consultants who implement them. But what is required is a new way to approach the problem of legacy infrastructure. That’s where I believe some of thinking on improvisations from Dr. Claudio Ciborra may help – http://www.theworkplaceblog.com/2007/03/information_systems_theory_on.html
Complexity does kill in the world of IT. When I came on board with my current company the network was so complicated and detailed that nothing worked well if it worked at all. I recently got promoted to Director of IT Engineering and have suggested we begin data center automation.
We have begun the process to some degree implementing things like run book automation into our network which has helped us solve problems much quicker than before saving us time and money. Some are against IT Automation but I can attest that it is the way of the future and we should all be thankful for it.
My experience is that ERP can work and provide real business benefits, given the right set of circumstances.
Perhaps your call for more research and empirical evidence would allow those circumstances to become more defined so as to avoid an expensive waste of time, money and corporate effort.
A few years ago I worked on a project which was establishing a new business venture in the Far East. ERP was the first computer system to be specified on the project, and from that all processes and systems were put in place. Understanding the ERP “internal logic” was not important – only understanding the functions it would perform, and how the data was supplied to and from that logic. The data flow between the systems was well engineered and understood from the outset.
In a similar vein, another project centred on a new joint venture company between two large European chemical companies. By utilising one of the partnersÂ’ ERP systems the roll out and integration of the new business was extremely quick. Understanding and controlling the data flow here was also the key to successfully linking both corporate ERP systems.
A contrasting experience which I watched from a safe distance was a huge implementation where the business edicts surrounding the project were simplistic and showed a glaring disconnect between business and IT: “Implement ERP”, “reduce the number of legacy systems”, “rationalise applications”, and “consolidate hardware”. ERP was eventually installed after enforcing change around the globe, but the initial vision was far from realised. Millions of pounds were over-spent in the drive to implement ERP, but ultimately that wasn’t ERPs fault. Trying to force too much change onto a complex organisation because of what Denis Howlett calls “political necessity or ‘me too’ ERP envy” is doomed to failure.
I believe you are right to say “that adding a wildly elaborate and complicated module can significantly decrease system complexity, if it replaces a number of older modules whose interactions required babysitting.”
Dataflows are important, and it is the understanding, documenting, and engineering of them which is key to managing complexity. We should look towards other industries for a lead here. After all, how could we build other complex things like skyscrapers or bridges without blueprints or engineering diagrams.
I would invite you to read “IT exists for one reason” for more about this concept.
Well if you consider that excellent database automation begins with the execution of RBA then youÂ’d have a valid point. To say that we should just start throwing automation tools at our network though and expect to increase the performance of business software applications then youÂ’re nuts my friend! These types of things or anything in IT for that matter requires careful planning and execution. Fast and cheap only leads to disaster for you and for your employer and/or clients.
The database tools you choose to use are of utmost importance. Make smart decisions, not “affordable” ones as you put it. That translates into cheap and you get what you pay for…especially when dealing with technology. If you are truly interested in going with data center automation then slow down and take your time. If your boss doesn’t like that explain to him that hasty actions will cost both he and the company more in the long run.
I fully agree on point 10 “Understanding and controlling the data flow here was also the key to succes”. Unfortunately something where a lot of consultants have problems with, it’s not always the technical side that’s the hardest …
What is the best way to organize training of the staff during implementation, on your opinion?
I think one of the big reasons people don’t automate is they feel like they don’t have the time to make it happen.
Being the boss in this field is always hard.. There are always a competition..
Viagra
Great post, what you said is really helpful to me. I can't agree with you anymore. I have been talking with my friend about this, he thought it is really interesting as well. Keep up with your good work, I would come back to you.
Great post, what you said is really helpful to me. I can’t agree with you anymore. I have been talking with my friend about this, he thought it is really interesting as well. Keep up with your good work, I would come back to you.
my computer keeps freezing