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)
Atul Rai
· 2 years ago
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.
sig
· 2 years ago
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 :)
Mario Ruiz
· 2 years ago
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.
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
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?
dan pontefract
· 2 years ago
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.
Shiv Singh
· 2 years ago
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/informa...
Justin Davis
· 2 years ago
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.
Paul Wallis
· 2 years ago
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.
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.
Mathias Van Moortel
· 2 years ago
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 ...
Stefan
· 1 year ago
What is the best way to organize training of the staff during implementation, on your opinion?
Dave Navarro
· 1 year ago
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.
All Comments
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)
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.
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 :)
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
http://dealarchitect.typepad.com/deal_architect...
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.
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/informa...
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.
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.
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.