A fresh model for software maintenance

A fresh model for software maintenance

Summary: It is clear that the homogeneous application of round sum percentages applied to software maintenance pricing is a dead business model. Nowhere is that more clearly illustrated in the recent kerfuffle over SAP's forced price rise for its maintenance services.


It is clear that the homogeneous application of round sum percentages applied to software maintenance pricing is a dead business model. Nowhere is that more clearly illustrated in the recent kerfuffle over SAP's forced price rise for its maintenance services. SAP has put up a spirited defense but on the basis of the customer conversations I've had, it is falling on deaf ears.

Thinking about this more broadly, I have posed the question whether Oracle can realistically continue to trumpet high 30's percentage points earnings when it is obvious from its financials that these are largely derived from maintenance revenues. These are but two of the more prominent examples. The same goes for almost every other traditional software vendor right down to the Sage's of this world. It is unsustainable and there will come the day, whether locked into the vendor or not, that customers will come together and say 'no more.' I absolutely believe that to be a reality.

My friend and co-buy side advocate Vinnie Mirchandani talks a lot about 'empty calories' an expression that describes that part of the maintenance bill that deliver little or nothing of value. He correctly argues that in a recessionary economy it is neither fair nor does it do anything to help customers get access to the innovations that software vendors espouse. We know the innovations exist - we've seen them - but how can companies invest when they are fighting against ever increasing maintenance costs? The two cannot go hand in hand. It makes no economic sense. What is the solution?

I'll throw this out. I believe that the thinking that informs CK Prahald and MS Krishnan's recent book: The New Age of Innovation provides clues that are well suited to this problem. In Prahald's world of co-creation, everyone involved in the delivery and use of goods and services has a responsibility that can be leveraged for the development of new business models that not only add value but do so profitably. In an interview at Sandhill, Prahald rehearses a speech he gave at InterOp where he outlines the principles underpinning his ideas. His key takeaway is that providers need to differentiate among customers to the point where the customer receives an individual experience.

In software terms, we already know that happens through software implementation, configurations and customizations that are a core part of delivering to customer needs. There is no reason why the same principles cannot be applied to the maintenance element of the business relationship. If you stand back and put aside the notions of the last 30+ years, it is blindingly obvious.

It is obvious for example that in the early stages, customers will consume a considerable amount of resource as they learn and become familiar with the product. They should therefore pay an economic price that reflects the services they consume. However, the software vendors need do three things in order to soften the impact and reduce the long term burden:

  • Recognize that customers are telling them they want to be dealt with as individuals not as cattle all subject to the same broad brush strokes.
  • Take control of the indirect channels of distribution and implementation. Time and again I hear about vendor rescue teams being parachuted in to resolve issues that have been created by inexperienced or incompetent implementation partners. In the 21st century and after 30+ years of enterprise software, that isn't acceptable.
  • Insist that customers develop centers of excellence that are certified according to vendor standards that allow customers to become self sufficient on routine matters over time.

Tie that to milestones and a promised general reduction in direct maintenance cost and you achieve several things.

  • The burden upon the vendor to service unprofitable or recalcitrant customers (unless willing to pay the economic penalty that implies) is removed while improving the overall level of service that can be offered at appropriate rates.
  • The vendor improves channel quality and in the process puts an end to the egregious practice of consulting hours being strung out, often at no value to customers.
  • It opens the door to the very innovations the vendors are developing because they should, in this model, provide the oxygen that allows customers to draw benefit.

It is a win-win-win situation that should not play havoc with overall margins though it may shift the internal balance as reported in financial statements. Customers see demonstrable value, vendors have happier customers and can upsell much more readily with perhaps less of the horse trading that is endemic in the industry.

Following Prahalad's model requires that vendors have a much clearer understanding of their customers, their levels of competency, the value they can deliver and TCO/ROI calculators upon which customers can reasonably rely. It will mean the creation of modified networks within the vendor ecosystems and far closer attention to business metrics and analytics upon which the vendors can make a case that customers both understand and accept.

I will not pretend this is easy. Wall Street makes little effort to understand the tensions that vendors face and may punish vendors who choose to take this type of action. At least in the short term. But what's the choice? The vendors may believe they're in a strong position but if the broad levels of discontent I am seeing are indicative of general customer sentiment, that is an illusion. Too many voices are being raised.

Neither will I pretend this is a panacea but Prahalad has demonstrated these models work in service based industries. I often hear that large vendor ecosystems are complex and it is difficult...yada yada yada. Maybe so but the fact remains that software economics are at heart, simple. As a bean counter, I can say that it is generally much easier to dissect a software company's 10-K/Q than it is a global manufacturing business. If the fundamental economics are simple as I believe them to be, then it cannot be beyond the wit of strategists to figure this out.

Topics: IT Employment, CXO, Software

Dennis Howlett

About Dennis Howlett

Dennis Howlett is a 40 year veteran in enterprise IT, working with companies large and small across many industries. He endeavors to inform buyers in a no-nonsense manner and spares no vendor that comes under his microscope.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Value-oriented maintenance pricing

    Hi Dennis

    Great article and I will be showing it to various clients of ours who we are trying to persuade to set up 'centres of excellence' - in fact 'centres of competence' would be a good start in one or two cases.

    A related approach we're taking where the clients will accept it is to get rid of percentage-based pricing altogether. Instead we are agreeing value measures - such as productivity or revenue gains - and charging both for change orders and maintenance on the basis of those measurements.

    Some more detail about this on [b][u]http://www.knowingandmaking.com/2008/08/software-maintenance-models.html[/u][/b]

    Thanks for the writing and keep up the good work.
  • RE: A fresh model for software maintenance

    I believe Dennis begins an excellent thread of conversation regarding the entire issue software ?maintenance?. It is long past time for a clear and frank dialogue about this ?black hole? in the software acquisition process. My clients have varied from na?ve indifference to the maintenance component to bitter distrust and distaste in their response to the whole practice (wizardry?) of ?Maintenance? (always to be said with booming voice, flashing lightning and a ?sign here; press hard; fifth copy is yours? car-salesman-tactic slimy smirk).

    There are several menu items included in the typical ?family-meal? approach (maintenance is maintenance, end of discussion) for software maintenance:
    ? Warranty (bug fix)
    ? A ?Help Desk? where the customers (varying from anyone in the customer?s organization to only a small/tiny/singular designated pool) are allowed to communicate with and/or seek assistance from the ?Help Desk? (?Help Desk? is enclosed in quotes because some/many are notoriously unhelpful)
    ? Post-implementation training, often fallout from poor and/or train-the-trainer implementation approaches, customer lack of buy-in or understanding during the pre-implementation planning, or ?training time? that was poorly strategized, lacking effective curriculum, transformed to implementation efforts, or absent due to ?cost savings? on the part of the customer, the vendor or both
    ? Minor (and sometimes a bit major) updates to meet changing external realities faced by the customers as a group, such as legal opportunities/mandates (e.g. tax breaks or labor standards)
    The addition of new functions and capabilities (that may or may not be desired by a specific customer) which often contribute to application bloat and have varying value to the marketplace, segments of the market and/or individual customers
    ? Sometimes, involvement with user groups and/or user conferences

    What is not usually included in software maintenance costs also should be noted:
    ? Major new version that utilizes a new database or is written in a new language or incorporates new architecture, approaches or workflows, etc.
    ? New versions for a different operating system/environment (AS/400 to Unix, centralized to client server, client server to thin client, etc.)
    ? Specialized capability for an individual customer
    ? Sometimes, involvement with user groups and/or user conferences

    One ought to note that the maintenance equation is really only about ?ERP?, high-end, or industry-specific software. General purpose software tends to have its own alternate reality of maintenance: buy an upgrade version every 18 to 24 months (to wit: Office). For those in the ?Open? world who have stood to shout, they too have an alternate reality: no maintenance, at least until the consortium or committee or whomever (including they themselves) decide it is time to do something, maintenance-wise.

    The question remains, then, which of the ?menu items? above should be paid for by a particular customer (if at all), and what pricing level is appropriate.

    The matrix of all these possibilities most likely forms another reality, a hugely alternate reality.

    We are having this dialogue with more and more clients and more and more of their current and future software vendors.

    Jerry Byrd