Five Obstacles for the Cloud Enterprise

With SaaS pundits and tech-bloggers going bananas over cloud, it can be tempting to see deviceless 100% cloud-enabled enterprise as just around the corner.

There is no question that the cloud is a great place for consumers, small startups, and even SMBs, but once you get into major enterprises, and particularly classic enterprises like FMCGs, where the majority of activities are based on end-to-end processes, and where the large numbers of users are either mobile or without regular device-access, problems start piling up.

This hasn’t stopped major ERP vendors, like SAP and Oracle from starting the cumbersome process of webifying their products, and some of them have even dabbled in providing ERP systems as a service, but before they get too excited, there are at least five major obstacles enterprises will need to overcome before they can fully escape to the clouds:

  1. Unreal identity. A lot see this as just a question of device-management, some DRM, and the right service for managing employee identities through the cloud, but you can’t replace physical and local verification of employee identities without loosing trace-ability, so until they plant a chip in our heads somebody will need to put their feet on the ground and actually talk to people to verify that they are who they log in to be.
  2. Variations in employee buying power. Although things are improving, I’ve heard of cost-to-salary ratios of up to three months in certain areas, so the fancy devices you buy in one country will be out of a reach in another, and unless you’re ok with subsidizing a steady loss of devices – which tax authorities tend to frown upon as it gives unfair advantages and/or creates artificial internal “taxation” – you will have to wait until prices drop or stick to cloud-services that also work over SMS.
  3. Limited off-line features. Even in our post-industrialized nations, a significant percentage of ground is not covered by mobile data-services, and once you go to developing nations the coverage is much worse. Most western companies don’t worry about this, but large parts of the world data-coverage is either monopolized and prohibitively expensive, limited to certain “development zones”, or simply impossible to implement because of the vast areas to cover. For enterprises with roaming employees who need to take orders, register goods, bring back empties, calculate discounts etc. you therefore need something a lot more feature-packed and off-line capable than Citrix and cached html5 to get things to work.
  4. Prohibitive legislation. The legislation in many countries severely limit the use of SaaS. In Europe alone we have personal-data laws, unions, local variations of Eurosox, and language-protection laws generating fines of up to €5000 per-document-per-day (I’m not saying in which country, but you can probably guess) that would make even the most cloud-happy CIO cringe, so until local governments get their heads out their… ears… erh… enterprises will stay behind.
  5. Outdated cost and licensing models. Finally, major vendors – and private-cloud IT departments – are having to turn their traditional cost and licensing models model on their heads to provide a per-user-per-month service-fee that supports variations in buying power, taxation, and all the other things in this list into account. This may sound doable, but never underestimate the complexities of merging the cost/benefits of a gazillion departments, contracts, and licenses into a single fee. I’ve seen more than one cloud-project short-circuit at the finish-line because somebody forgot something that completely blew the business-case or made the whole thing illegal in half the countries involved.

All in all, the 100% cloud-based enterprise is therefore still only a real option if you are small or information-based, and the time when major corporations will join in bulk, probably still some years off.

Now, I’m not saying it wont happen. Data becomes available in new areas every day, the services and devices mature, and there is no question that – with the huge push towards consumerization of traditional IT services and the incredible momentum behind privately owned devices – cloud will be an increasingly important factor even in major business.

What I am saying is that it will take time, and probably be a lot more complicated than it looks when you’re setting up your first few Dropbox accounts, logging into Zoho, and reading up on your favorite tech bloggers.

Read More

The TCO/ROI Scoping SweetSpot

If your IT costs are rising constantly on a wave of apparently critical legacy systems that you don’t know how to get rid of and nobody knows how to support, chances are you are missing the TCO/ROI sweetspot when scoping your business cases and projects.

Estimating how many users, servers, licenses, and features you need for the new shiny system you want to implement is relatively easy: just list all the things you need to get that up and running and stop there – but give me a few beers and I can rant for hours on why that is so horribly-not-at-all-and-under-any-circumstances true.

Just looking at your project may tell you something about what it will cost to get your system to work, but that is like figuring out what it costs to build a house without taking down the old one or moving the furniture. To make a proper business case, you need to look at the BIG picture and answer some of the hard questions like:

  • What can you retire when the new system is up?
  • How many years before the next major upgrade is due?
  • Is it realistic to expect everyone to be expert users from day one? Day 500?
  • Are you sure you have EVERYTHING in the project that’s needed to realize all the benefits you listed in your business case?

So to get a proper evaluation, you need to scope at least two aspects of your calculation and your project very carefully:

Systems

If you look at too few systems, it is easy to overlook dependencies and feature overlaps. You can make everything dandy within the project, but once you’re live all your benefits get hollowed out by a flotilla of annoying factors like:

  • Users having to use the old systems for single tasks so you can’t retire them
  • Data retention legislation so you can’t get rid of servers
  • Legacy license agreements that means you have to pay for the same feature twice even though you don’t use it anymore, and so on.

On the other hand, if you look at too many systems - as you’ll sometimes see when overzealous guys in my position want to get ALL it costs for all systems on day one – you’ll just drown in data, and you wont be able to deliver any meaningful answer to anything.

In my experience, your best bet here is to cluster systems into domains like HR, Finance, Productivity, and so on, with as clear a boundary as you can manage, so you have a fairly good overview without being hampered down by too much detail.

This is not easily done – and particularly not within a single project where most of the stakeholders on projects have vested interest in the outcome – so you’ll probably need some permanent non-project roles to define the domains and take the long-term TCO responsibility for this to work properly.

Timeline

The main thing to remember here, is that you can’t disconnect the project timeline from the TCO timeline: If you listed a benefit in your business case, it has to be realized before you end your TCO timeline.

Getting that timeline just right though can be a bit of a problem. Andy Kyte mentions nine years as the average time to fully replace a core IT system, and that’s probably spot on in most cases, but I usually take a less scientific approach and look at the software lifecycle of the product instead.

If you implement an IT system, chances are it will need a major overhaul in 4-5 years, and you want at least one or two of those overhauls to make sure you have a good idea about what’s going to happen. On the other hand, if you look much beyond that, the risk of the software being completely replaced by something else becomes so high that it undermines the validity of the TCO.

In my experience, the scoping sweetspot for the TCO timeline is somewhere between 5-10 years depending on the system you are looking at.

Summary

Working with TCO and ROI is not an easy task. As I’ve mentioned before it’s sometimes more art than science, and it can be tempting to give it up altogether and just look at each project individually, because after all, if we get the project approved, who cares about all the old stuff or the future. That will just take care of itself wont it?

Wrong. Of course. If you’re serious about making IT that is a competitive advantage for your business, you need to be not only good at scoping, you need to be better at it than everybody else, because in the end correctly scoping changes is what differentiates the good projects from the bad and the winning business from the ones muddling along.

Read More:

Social Media Introduction

For some reason I often find myself explaining basic Web 2.0 and Social Media Marketing concepts to people who have neither the time nor the interest to move much beyond the “hey is this a Tweet?!” stage.

So, although I’m totally aware that some of these concepts are still apexing the hype-cycle and have pundits all giddy with excitement over discussing definition minutiae I “dared an eye” – as we say in Danish – and made this presentation anyways.

To me, the main challenge is to get stakeholders to understand the basics, so if you can use it, feel free to download a copy (after reading my terms of usage), and if you have suggestions for improvements I’d love to hear them.

Read More: