Responsiveness of cloud-based software

Clouds
For a while I have been using a web-based service called Mammoth. Mammoth allows you to save text, images and other online content, as well as notes, into a single place for later use. In my case, I use it when researching issues I need to write about, or reference, for my job as a product marketer.

Mammoth allows you to create ‘boards’ which store the content about a particular subject. Boards can be shared so that people in different locations can edit the content collaboratively. A standard board in Mammoth is ‘Talk to Us’, which is shared with the Mammoth support team, and this allows me to address any issues I have with Mammoth online. Whenever I have logged an issue, I get a response via the board usually in a few hours.

In one case, Mammoth made a change to the user interface (UI) which made it look worse for me, so I logged a note on the Talk to Us board. There was a bit more discussion and clarification about the UI issue on the board, but what interested me was that 24 hour later when I logged on to Mammoth, the UI problem had been addressed. The application was fixed and changed without me having to do a thing.

It made me re-evaluate my view of cloud-based services.

  1. A problem with an on-premise application always requires the user to do something to fix it, usually download and install a software patch. With a cloud service, the problem is fixed once in the cloud, everyone gets it at the same time, and new software has to be installed.
  2. A problem with on-premise software is reported either by a phone call or an email, which then has to be discussed and confirmed before it can be transcribed and referred to the software development team. With a cloud service, you log an issue online in one place, the issue can be quickly confirmed and then be relayed speedily to developers.

Imagine if you could do that with enterprise software – ERP, CRM, warehouse management.

  • Customers could report problems so much quicker, and probably have a better support experience
  • No need for each customer to update the software with maintenance releases to fix bugs
  • Customer could log enhancement requests in a more effective way, and perhaps even get previews of enhancements before they go live
  • The development team work on supporting one codebase, in one location, for everyone
  • No need to ship CDs of software around the world

Wouldn’t that world be better? Oh wait, it’s called Software-as-a-Service and it’s here already.

The problem is that while the promise sounds simple and wonderful, the realities of transforming to that promise require major changes in thought, approach and practice – and moreover, for traditional software vendors, major investment expense.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s