I think a good place to start the discussion around Timeless Software and non-disruptive technology is with the business value. Some people might think that the business value is obvious, and others might think this is just a technology issue, where there isn't a business value discussion. It is probably good to start by laying out the business reasons why people might care about non-disruptive technology.
This is a bit of a lenghty post, so I apologize, but it is important to set out a common framework for disruptions before you go on to discuss how it applies. The reason is that a lot of these terms, like upgrade, are thrown around pretty casually. So, you need to know what's behind them to have a meaningful discussion about them.
The way to work this out is to think about the various diruptions and then work back the business value of avoiding these types of disruptions. In my prior life, Pat Phelan, an excellent analyst, shared with me some of her thoughts around how to think about these various disruptions.
From an IT-driven cost perspective, the basic way to benchmark the cost of disruptions due to upgrade or replacement of an application is as a percentage of original implementation costs for the application in question. In cases where the application is purely augmenting the existing application stack, then the costs are typically benchmarked based on integration costs.
Leaned Out IT Costs Lead to Business Value, Not Just IT Cost Savings
The first place people look for the business value in avoiding disruptions is by enabling leaner uptake of new business oriented functionality. So, to understand the business value, you start by identifying the avoided or delayed IT costs and disruption, which allows faster and leaner uptake of business funcitonality.
Upgrade -- The word upgrade gets thrown around a lot. It can mean a lot of different things. But, generally, an upgrade consists of leaving the core transactional and master data in place. The code usually remains similar as well as business processes.
There will be changes, but, as a user, you hope that the core engineering of the system has been left in tact, which will minimize change. Conventional upgrades can typically be benchmarked at anywhere from 10-40% of original implementation costs. Yes, that's a wide range, but given how much can go into an upgrade, sometimes you hit that upper number.
Reimplementation -- A reimplementation of a system is considerably more costly than an upgarde approach. In a reimplementation, you generally start with a fresh implementation, and create master data, processes, and analytics. Then, you generally load your existing transactional data into the new implementation.
Sometimes, data migration tools will be provided for this, but just providing data migration tools will not significantly mitigate the costs of a reimplementation, as this generally only represents 10-20% of a reimplementation project.
This type of a reimplementation can cost anywhere from 75-150% of the original implementation. A lot of people are surprised to find that a reimplementation might cost more than the original implementation -- and this can happen where the new system is more complicated than the original system in place.
Timeless Software Generates Business Value By Avoiding Upgrades and Reimplementation
So, what is the business value of avoiding this? You get to uptake business funcitonality faster -- and the benefit is quantifiable. For example, if you want to implement new incentive compensation capabilities to help you deal with new sales models in China, but you need to incur an upgrade prior to deploying these capabilities, there are two ways you can either think of the business value of avoiding this disruption. Either the upgrade acts as a tax on new business innovations, or, more likely, all of your business functional releases get lumped into an annual release cycle. This makes the business value of avoiding disruptions, on average, half of a year's business case. In other words, that is a significant drag on business value obtained from the applications portfolio -- not just from an IT cost perspective.
You can start to quanitfy this value by looking at two things within your enterprise: What is the average delay from request to implementation of business funcitonality, and what is the annual value of this? You can then look at the new cycle time you'll get by being able to implement new functionality without upgardes, and the difference in cycle time to new functional attainment is the business value of Timeless Software.
By leaning out the consumption model around adopting new functionality, you don't have to take an upgrade or reimplementation in order to get new functionality. The business value of this is that you can move when the business needs to move. The speed with which you can uptake new functionality to respond to business challenges amplifies the value that is generated by new software. I mean, what is the point of new functionality if you can't use it?
I'd like to dive a bit deeper into what makes Timeless Software actually happen in future posts, but I wanted to start here so that we could reference back to the business value underneath this.
What do you think about this?
