This page is published under the
terms of the licence summarized in footnote 1.
This paper follows the paper in which the application portfolio management options were introduced.
The first thoughts of an application portfolio manager are often to cut back application maintenance budgets and replace old systems with new packaged solutions.
And these are sometimes wise decisions.
However, this paper offers a rationale for why these decisions can so easily turn out to be unwise.
And why investing in a serious maintenance team can prove more cost-effective in the long term.
The paper concludes there may even be 'break-even' package cost, above which one should tend to favour strong maintenance - with view to deferring the need for a replacement as long as possible.
“I fully agree with the sentiment of the paper and I really like the model that the paper has in the conclusion section.” Nisheed Rama
Experiences of implementing big ERP systems
The need to cost packages properly
The need for a maintenance strategy
The manager may look to replace a system with a pre-packaged solution for various reasons.
Not necessarily because the package is a better system, which gives its users new functions or better usability.
Often (perhaps more often) because:
The last is common; the owner is simply unwilling or unable to pay for enhancement of the old system, and hopes that a replacement package will be simpler and cheaper.
“There is another key factor for making a replacement decision.
The application may support a business process that is important to the business, yet doesn't provide the company with competitive advantage in the market (perhaps it is support function rather than a core function).”
However, replacement can prove a false economy.
When planning to invest in a replacement system, you must consider not only the short-term migration costs (effort to remove the old system - effort to migrate data from old systems to replacement systems - loss of functions, etc.), but also the long term costs.
“The average company spends $15 million on Enterprise Resource Planning software, the monolithic systems of record from vendors like SAP and Oracle, and many large companies have spent tens and even hundreds of times that.... Certainly, companies that have tried to customize these systems to reflect their own customized processes have spent a lot of time and money to do so.
And ERP systems do introduce a certain amount of rigidity.
On the flip side, having a system of record is a benefit in and of itself that shouldn’t be discounted.”
Ben Worthen - the Wall Street Journal Business Technology Blog – as quoted in ref. 1.
If Cynthia Rettig (ref. 1) and architects on Avancier’s training courses are to be believed, many businesses have set out to consolidate and standardise their applications by buying a big COTS package, only to be disappointed.
They say their enterprise has spent millions of dollars/pounds/euros on an ERP or CRM package only to find it does little of what they want and/or the modules they want to use have to be configured using specialist consultants.
According to a paper by AT&T, the most common pitfalls in a SAP implementation are
Implementing Applications
· Failure to document and blueprint business processes
· Undersizing the system infrastructure
· Failure to make testing a priority
Ongoing Application Management
· Understaffing or overstaffing the application management team
· Not maintaining current software releases
· Failure to take advantage of the full business value of SAP
Upgrading Applications
· Failing to make a solid business case for upgrading
· Poor planning and project management
· Poor testing or lack of testing
http://www.business.att.com/enterprise/exchange_resource/Topic/networking-applications/Whitepaper/how_to_avoid_the_most_common_pitfalls_of_an_sap_solution_usi/
Note “understaffing or overstaffing the application management team” - a theme in this paper.
A reader (a Business Intelligence Manager at a Blue Chip Multinational) writes of his experience:
“Once your CEO takes a decision to buy big ERP package (if for no other reason that he has heard of it) then the 2-3 years of hard work and angst are inevitable.
But in the end it can be worthwhile.
We are almost 3 years down the road with our ERP package (you can guess which one).
Some conclusions
- we pay depreciation each year – this kills the IT budget but it will be fully depreciated soon which will make it more "free"
- after many defects it is settling down - though IT tend to be overzealous in saying "its not a defect its an enhancement"
- we are just now reaching something approaching stability.
With stability comes the opportunity for enhancement to bring more value to the business.
For instance the business intelligence reports are now getting a better press in the business,
because they are genuinely pointing out ways the business are losing money, or not making as much as they should - which was invisible before.
A key constraint is staffing and resources for testing.
The dilemma is that business people - at design and implementation time - have neither the time nor interest to help ensure proper design.
Only after it is commissioned they can see how it works.
This is too late - it takes a lot to re-work and re-customise.
What you need on the project is "hybrid" people who understand both the business and IT.”
OK, but this paper you suggest your CEO might have done better to reuse or build rather than buy!
If architects on training courses are to be believed, many businesses have set out to consolidate and standardise their applications by buying a big COTS package, only to be disappointed.
They say their enterprise has spent millions of dollars/pounds/euros on an ERP or CRM package only to find it does little of what they want and/or the modules they want to use have to be configured using specialist consultants.
Can you
afford to run the package?
The vendor may simplify your design process by defining a standard operating environment.
There is a natural tendency for this to be over-engineered.
And it may not fit with the infrastructure you need to run other systems.
Can you afford to configure the package? Can you use the package “out of the box”?
If not, then you have configuration, migration and testing projects do, perhaps using specialist resources.
The more bespoke your requirements, the more the package looks like an expensive development environment.
Can
you afford to upgrade the package?
Can you take on the next version “out of the box”?
“Just ask the folks that used to work at Baan about this problem. SAP made a killing switching out Baan customers due to extraordinary upgrade costs.” (quoted in ref. 3)
How
useable are the modules you want to use?
A brand name may give a large package the appearance of unity.
Often, the package behind the brand has grown by acquisition of distinct applications.
Some of these are good, some are well integrated, and some are largely unusable by anybody but their original customer.
If it turns out you want to use the latter, you need those specialist resources to configure it.
So make you sure you ask for references to customers who use the modules you want to use.
How
will you integrate the package with your other systems?
Buy a package, and you often bring into your business a new database that stores business data you already store in other databases.
You have created new data integrity issues and a systems integration challenge.
The enterprise architect is still needed to address the age-old challenges.
· How to improve data integrity between disparate systems?
· How to automate workflows that join disparate systems together?
Buying packages creates work for the enterprise architect.
Assuming the replacement system will itself need to be configured, maintained or enhanced - who will do this?
You need domain experts who deeply understand your systems, your business processes, your business rules, your business data.
Do you want these domain experts to be in the employ of IBM, or HP, or Oracle, or SAP, or CSC?
Suppose a large business has a large system and a strong maintenance team.
So far their unspoken strategy has been to extend the life of the system for as long as is reasonably possible.
Nevertheless, managers see the system as coming towards the end of its life in the next couple of years.
And managers are looking for possible cost cutting opportunities.
So they say - let’s make some of the maintenance team redundant – since we are going to replace the system soon anyway and we won’t need them that much in the next couple of years.
This decision is short-sighted.
The consequences are bigger than at first they appear.
The decision fails to account for the need to define a new maintenance strategy for the replacement system.
Before the new system in running, managers must choose between diverging maintenance strategies:
So managers might find that the short-term cost-saving decision taken now compromises not only the current system (which might be an acceptable price to pay over a couple of years) but also their ability to maintain and extend the life of the next system in a cost-efficient manner - whatever they do in a couple of years time.
There is also the issue of how competent the new system implementation will be if the strong maintenance team is no longer there to advise on its implementation.
“When you replace an in-house solution with a packaged one, the rule is to use “out-of-the-box” product features for all business processes, and accept that you are outsourcing the development of new features to the product vendor.” Nisheed Rama
Indeed, you have to accept you are handing over knowledge of your business processes and business rules to an outside party.
“Key to ensuring that your purchase delivers benefits is to use “out-of-the-box” product features, even if this means re-engineering your business to around the application.
Most large package vendors support big players in their industry domain, so their product evolves alongside business procedures of that industry.
So rely on the vendor product roadmap and simple product upgrade processes to provide new features to the business unit.
Free your development resource to focus on the applications that provide competitive advantage.” Nisheed Rama
Given that well-nigh every software system has a limited lifetime, when you take a long term view of the main costs, you are left with two principal options.
Option 1. Plan to rewrite or replace the system (say after 5 years) with minimal maintenance until then.
Amortise the replacement cost over 5 years at 20% per year. Add a minimal maintenance cost of 2.5%.
Option 2. Prolong the life of the system (say double to 10 years) by investing in a consistent and serious maintenance team.
Amortise the replacement cost over 10 years at 10% per year. And, say, add a serious maintenance cost of 10%, four times the cost of maintenance in option 1.
Suppose a replacement package costs £10 million up front, and minimal maintenance of that package requires a team of 2
Suppose serious maintenance of the legacy system requires a team of 8.
Then the essential numbers might look like this.
|
|
Plan to rewrite or replace the system
after 5 years with minimal maintenance until then |
|
Double the life of the system by
investing in a consistent and serious maintenance team. |
||
|
Costs |
Amortised Replacement |
Minimal Maintenance |
Costs |
Amortised Replacement |
Serious Maintenance |
|
Year 1 |
2,000,000 |
250,000 |
Year 1 |
1,000,000 |
1,000,000 |
|
Year 2 |
2,000,000 |
250,000 |
Year 2 |
1,000,000 |
1,000,000 |
|
Year 3 |
2,000,000 |
250,000 |
Year 3 |
1,000,000 |
1,000,000 |
|
Year 4 |
2,000,000 |
250,000 |
Year 4 |
1,000,000 |
1,000,000 |
|
Year 5 |
2,000,000 |
250,000 |
Year 5 |
1,000,000 |
1,000,000 |
|
Year 6 |
2,000,000 |
250,000 |
Year 6 |
1,000,000 |
1,000,000 |
|
Year 7 |
2,000,000 |
250,000 |
Year 7 |
1,000,000 |
1,000,000 |
|
Year 8 |
2,000,000 |
250,000 |
Year 8 |
1,000,000 |
1,000,000 |
|
Year 9 |
2,000,000 |
250,000 |
Year 9 |
1,000,000 |
1,000,000 |
|
Year 10 |
2,000,000 |
250,000 |
Year 10 |
1,000,000 |
1,000,000 |
|
Totals |
20,000,000 |
2,500,000 |
Totals |
10,000,000 |
10,000,000 |
|
Total |
22,500,000 |
Total |
20,000,000 |
||
I’ve manipulated the business cases to be comparable.
But remember, the serious maintenance team can make your system do exactly what you want.
So there are other factors besides the numbers in this table.
And in any case, the numbers input to your business case will be different.
Option 1 is probably even more expensive in ways not shown in the table.
Each system replacement takes a huge a change management effort.
And the interest on capital invested may have to be taken into account.
The average ERP spend is reported to be £15 million.
Several architects have told me their enterprise has spent around £50 million - only to make only limited use of the package.
(A new large bespoke application development can cost you as much from a large IT services provider.)
If you don’t allow any maintenance at all on the package, you may well have to replace the system sooner.
If you do allow minimal maintenance?
Even as little as one dedicated resource (multiply by three or more if third world resources are used, with all the communication difficulties that introduces) exposes you to the risk that a package evolves away from the thing you bought into a bespoke system that prevents you from accepting the next version the vendor offers to sell you.
This can defeat the purpose of buying the package in the first place, and shift you into option 2.
Reader: The manager sees a risk in option 2.
He pays for the maintenance and then still has to replace for some reason (mistake with maintenance, competitors overtaking them, major IT development etc) so option 1 may look less risky from that point of view
The same risk and reasons apply to any package (ask the users of Baan who switched to SAP).
They are countered only by proper ‘architecture’.
And conversely, the later you buy a package, the more advanced the version of the package you get – and probably at a lower price. So putting it off as long as possible might prove a good strategy.
Once you take option 2 you lose some benefit if you don’t stick with it.
There is a risk that a decision to cut the maintenance cost in a given year (e.g. in a recession) may lose you the expertise to allow you to effectively manage that generation of the software at all.
This brings forward the costs of the rewrite or replacement - and the rebuilding of a maintenance capacity.
Reader: And the argument for persistent maintenance is weaker for smaller organisations with inexpensive packages as there may be more of a 'fixed cost' element to maintaining a strong maintenance team.
If the maintenance cost can’t be reduced by the same ratio as the package cost (and its depreciation) then the calculation will be less convincing for smaller packages.
True. There may be 'break-even' package cost:
But I don’t know how to calculate it.
References
Ref. 1: “The Trouble
with
Ref. 2: “Agree EA funding model or ROI metrics in Avancier Methods at http://avancier.co.uk
Ref. 3: “Architectural Myths” at http://avancier.co.uk
Ref. 4: “Can we measure architecture” at http://avancier.co.uk
Ref 5: “Application Portfolio Management” at http://avancier.co.uk
Footnote 1: Creative Commons
Attribution-No Derivative Works Licence 2.0 26/05/2014 15:11
Attribution: You may copy,
distribute and display this copyrighted work only if you clearly credit
“Avancier Limited: http://avancier.co.uk”
before the start and include this footnote at the end.
No Derivative Works: You may
copy, distribute, display only complete and verbatim copies of this page, not
derivative works based upon it. For more information about the licence, see http://creativecommons.org