Software Return on Investment
A little while ago, I posted an entry on the Longer Term View of Software where I discussed how software investments should be considered. While it touches on ROI, I thought I'd write something about the ROI on software. It's a question that's been coming up more and more.
Enterprises know that software is important - that software helps with productivity, gives a competitive edge and opens up new opportunities. Even though there is an innate appreciation of software, enterprises outside of the technology industry are looking to cut IT costs. IT, even in this day and age, is very much considered a cost center by many organizations. So how can IT put a value on their software investments? Here are a few ways software provides value at a high level:
1. Acceleration: What used to take 2 days, takes 2 hours rapidly accelerating the organizations ability to serve its customers, reducing latency and impoving capacity. This could be as simple as accelerating a PO approval to accelerating product development through intricate design software. The more you can do, the more money you make in a shorter amount of time... another simple example is a user being able to find information quickly (search).
2. Automation. This is a direct enabler of acceleration. The reason why I call this out specifically is because some organizations make the mistake of trying to measure automation, when they should be measuring acceleration. An example of automation is an EAI system that integrates data from various systems and creates a report. That can ultimately allow you to make more informed decisions.
3. New revenue streams. The simple example is a traditional B2C site where an organization is selling products or services. This is a direct result of reach and automation.
4. Communication & Collaboration. Being able to communicate with people (synchronously and asynchronously) easily is important to get work done. A simple example is email - it's a critical part of any organization's IT investments.
5. Cost reduction. What used to take 10 servers and 5 people to do, it now takes 1 server (hardware consolidation) and 1 person. A good example of this is replacing file shares with self-service collaboration software.
6. Compliance. This is a gimme... there's nothing better than policy and the threat of litigation to make it worthwhile.
While all of the above make sense and are common sensical, how do you measure them? #3 and #5 are relatively straightfoward to measure, what about the rest? How do you justify spending a certain dollar value on software? How do you increase your budget? Here's a thought and something that is getting more and more industry recognization: Software as a Service.
When people usually talk about software as a service, they are generally referring to software architecture. I'm talking about something different in this context. I'm essentially saying that software can be measured as a service. We pay for services everyday - cell phone calls, electricity, water, et cetera. We pay for how much we use. If someone said, put the dollar value on a cell phone... I would quote the ammortized price of my phone plus my monthly bill. Sure - it's worth a lot more than that, but now it's quantifiable.
So why shouldn't software be treated the same way? Why can't IT departments adopt a chargeback model? They possibly can.
The challenge with chargeback is 1) how much do you charge and 2) what do you charge for? To be clear, the chargeback model could be "funny money". It just provides a better understanding of the software that's being used and what the value is.
On #2, as far as SharePoint technology is concerned, we have a feature called a Feature that IT/development can develop and deploy. These features can be activated and deactivated and can be composed of data definition and application code. It provides a really good way to bundle and deploy code... and needless to say, maps very well to the chargeback model. Business units can active and/or deactive the features they want... and ultimately "pay" for usage. Mario Morejon, in his recent CRN article, actually discusses how easy it is to build on SharePoint Server.
On #1, that's something that depends on the feature. Needless to say, you also need to think about the how (per transaction, per instantiation) you want to charge. For example, if you're a SharePoint customer who can charge a business unit when a site is created... and depending on the features that are activated, you can charge a premium.
So why is the chargeback model an interesting theoretical model to explore:
1. You can get "more budget" by showing the value and usage of the software. Business units have dollars to spend as part of their marketing and development budgets... if they are using software to acceleration and automate a lot of that work, shouldn't there be a kick-back?
A corollary to this is unifying budgets across IT departments. Large organizations have more than 1 IT department... so consolidating budgets and environments can possibly lead to higher ROI.
2. Usage tracking and adoption. Whether you charge funny money, real dollars or nothing at all, by implementing a chargeback model you can see precisely how the software is being used... ultimately, your software is only worth something if people adopt and use it.
In any case, this is something interesting to explore... I don't know of many organizations taking a look at this, but at the very least, it's important to explore a flexible usage tracking system... giving every employee a fantastic cell phone and service plan.... and being told you're a cost center, isn't exactly fair. Especially when those cell phones are helping sales people close million dollar deals. :-)
Comments
- Anonymous
November 11, 2006
Arpan Shah (Group Product Manager) wrote a great blog entry on ROI – I thought I'd add some comments. - Anonymous
November 11, 2006
By combining a few blog entries I just read – Arpan's ROI post which talks about ROI/Chargeback and Chris - Anonymous
November 28, 2006
Written like a true geek who does not understand basic business fundamentals. None of what you cite has anything to do with ROI. How can you cite email as anything but a drain on money and human resources? Moving from the cost center to the revenue center I'd buy , but only if the technology directly impacts the revenue stream- for instance the software that runs the robotics or the electronic banking transfers.