Rogue IT

Today I shall scratch the surface of the so-called “Rogue IT”, how it is affected or enabled by the very nature of cloud and Software as a Service and whether organizations should fight against it or just “ride the wave”.

A simple definition of “Rogue IT” is the situation where organization departments build and/or use their own applications without prior knowledge of the CIO. Because such applications do not have a “legitimate” confirmation by the IT department, it is often called “hidden technology”. Also, the costs relevant to that software or service are called “hidden IT costs”. Obviously, they are not really hidden; they just don’t appear in the I.T. annual budget sheet.

Rogue IT is not a new concept. Even before the days of the cloud, departments sometimes created pieces of “application software” to execute several tasks. This could start from an intelligent spreadsheet, which incorporated formulae to extract department-specific statistics but it sometimes grew extensively to local databases with quite sensitive data. For example stand-alone CRM applications built in MS Access which, among other things, contained some form of “Customer file”. Of course, that meant that somebody from Sales or Marketing or whatever department had some technical knowledge to build such applications (but this was often the case!).

Now, the cloud era makes things easier for rogue IT. Departments no longer have to have any technical expertise to build the application that they need. If the IT department can’t serve them fast and completely, they may choose to adopt some cloud offering to do what they have in mind. A scheduling system to track your department’s activity, a CRM for the Marketing, a ticketing system for Service operations etc. The department head can allocate a percentage of their annual budget to “invest” to such software solutions. They just make their own market research and decide to subscribe to this or that SaaS service. The fact that nowadays there are a lot of reputable SaaS solutions for any need drives the potential growth of the Rogue IT. Also, by definition, it solves some “traditional” problems that the Rogue IT users were facing: Who can develop a really workable and reliable application if they are not real “IT guys”? Who and how will maintain this application? What happens when the person who built that application leaves the organization? How can this work in a multi-user environment (departments don’t have access to setting up servers etc.)? These days, one can subscribe to a SaaS service, have their users collaborate in a cloud platform and immediately solve all of the above problems.

After understanding how cloud enables Rogue IT, we must ask ourselves whether organizations should fight against this trend or not. It seems that both aspects have their pros and cons. Let’s have a look at the two sides of the same coin:

Issue	Rogue IT is good because…	Rogue IT is bad because…
Costs	Costs of rogue IT do not burden the annual budget of the IT department and so the organization may find itself in a position that it invests in some new technologies which otherwise it wouldn’t.	Rogue IT costs may well go out of hand, if every department invests unattended. This may significantly increase total IT spending without getting the benefits that it would, if all these investments were centrally controlled.
Agility	If a specific department no longer needs or is disappointed by the performance, it may very easy choose to switch to another service. It can do so fast and easy without depending on the IT department’s availability to lead such a transition project.	When switching between cloud services, somebody must have the control of what is to happen with the data that were stored in the abandoned service and a lot more technicalities pertinent with the organization data on the cloud.
Time-to-port a new application	If each department drives its own Rogue IT project, then things will move much faster that having the IT department of the organization trying to serve everybody and manage multiple projects at the same time.	If nobody (the IT dept.) doesn’t have the central management of such projects, then perhaps departments build their own logic, diversified from corporate policy and maybe duplicate data and processes while they are implementing (e.g. the CRM customer file can/should be only one for all purposes, like Marketing, Sales and Accounting. Imagine the issues that arise if every single department had their own customer file and updated it the way that they would see fit!)
User support	Rogue IT users may be happy with the support that they get from the SaaS vendor.	IT dept. hot support is missing.

The above examples show that while Rogue IT is a reality (and will probably continue to rise), there aren’t specific rules or arguments that drive the decision to adopt or to abolish the use of it.

SaaS ecosystems as business enablers

In the past, I have talked about collaboration opportunities in SaaS environments where similar business run their operations and one can get some input or intelligence from the other, here http://tchristidis.blogspot.com/2011/01/collaboration-in-saas-environments.html . Also, I have talked about how a SaaS application forms a kind of community which can assist users to exchange ideas and increase the usability of the software, thus maximizing the investment they have done in their SaaS solution, here http://tchristidis.blogspot.com/2011/10/saas-applications-and-their-community.html.

Today, I am elaborating on some details and investigate if and how a SaaS environment can be used not only as a means to execute daily tasks but also as a business enabler for the on-board users.

The basic idea is that a SaaS database contains valuable data of the on-board users, such as services they provide, product catalogues, availability of their products etc. Businesses with some kind of co-relation (e.g. a Service shop that services automobiles and a Parts supplier of that service shop) may stop for minute and think how this potentially common database can assist them to do business together and increase productivity, while providing better service to the customer. A service shop would typically stop at a customer’s inquiry by saying “sorry, that accessory is not available”. But, what if they could instantly add “…but I can get it for you in 2 days…”.

Recently, I was discussing with a retail professional who said to me that he was thinking about approaching other retailers in his area and propose some kind of discount scheme if customers from one shop visited the other (obviously, their products were not antagonistic, but complementary to each other). If a customer visited shop A to buy, say,  some meat, then he would instantly gain some discount on shop B which sells fish and vice versa. A great idea, if you ask me, that talks about collaboration in the real world. Now, imagine this in the virtual world of SaaS. Customer goes to shop A and buys meat and the SaaS platform automatically registers a “earned discount” for shop B. When customer visits shop B, he doesn’t need to say anything. The cashier sees that there is a “earned discount” and immediately assigns it to the receipt. Need some kind of verification? Easy. The two businesses of the example reside in the same database. Therefore data exchange is possible; so is a more sophisticated workflow (if need be) between clerks of businesses A and B (in order to verify, authorize etc.).

One could expand the above case to a more sophisticated loyalty scheme that stretches beyond the physical boundaries of business A. What if there was an easy way so that loyal customers to business A could enjoy benefits in business B, too? (further business analysis is not my intention today, but I think you get the point!).

Another example is that of a retail shop that finances its sales through personal loans. The retailer already has the basic data that the bank needs for its loan application process: The customer data, the goods sold and their value. What if that data could be transmitted to the bank and get an instant response with zero effort from the retailer. Of course, such “interfaces” or EDI can be built between any two systems, but that would mean customization effort and a combined project between the two businesses and their two software vendors. New web services would need to be built, security issues could arise etc. But if these businesses were running on the same SaaS platform, then the technical difficulties would be much lower, since there would be one I.T. vendor that would only need one internal process to decide how that business enablement can be implemented in that one, shared database (of course, in that simplified example I choose to overlook how a bank would choose to implement its loan approval process in a public cloud, but that’s another story).

Perhaps this kind of functionality requires some customization but it is my belief that horizontal SaaS solutions that support some kind of workflow and also architecturally allow some data sharing can be the vehicle to such business-to-business collaboration. And my point today is that SaaS ecosystems can also work as business enablers for the parties that have subscribed in that service.

Mobile is the future (or is it?)

One of the many advantages that web applications (SaaS is my favorite kind!) bring is this of mobility. Before web business applications you had to login to some server using several cumbersome technologies like Remote Desktop etc. to gain access to those apps. Then the web came and new robust (and secure I might add) applications came into light. Tapping in your enterprise network and executing several activities was made much easier. Also, you could now utilize a powerful laptop or even work with a device (PC or laptop) that wasn’t yours.

Now, this is the 2010’s, where smart phones (and other devices) gain ground but also users are becoming more and more demanding when it comes to their desk-independence and mobility. They need mobile applications that (like the web before) offer more and more functionality, without serious (or any) compromises in security. Also, a large number of people are becoming more dependent on their favorite devices, so BYOD (Bring Your Own Device) is becoming a big issue for CIO’s around the world. They simply *have* to accept BYOD and solve the inevitable device diversity issues that arise (Take, for example, a medical center were patients come in to stay for a “long” (in internet scale) time. They are BYOD-ing and the hospital CIO must simply accept this fact and do what is necessary for the security and functionality of the hospital network!)

It’s not my intention to quote many statistics that can be found everywhere on the web. Just a few facts:

• Mobile users are quickly increasing in number; faster than PC users on the 80’s and probably 90’s
• Soon, there will be more mobile devices (smart phones and tablets) than PC’s and laptops.
• Mobile users in China doubled over the last year against Japanese users.
• Building mobile apps is easy either by the use of development kits or by HTML and HTML5 based code.
• There is a large number of mobile apps offered for free that can be upgraded later for a small amount of money. This is not the case with web apps and SaaS.

 Around 2025 we shall see a new kind of device. We don’t yet know how this will look like but it’s surely going to be “mobile” in kind (this is based on the assumption that new devices emerge every 15 years).

The above are showing us that mobile computing (and business applications, which is the focus of this article) is the future. There will be a large number of new players. Many of them will come from emerging markets of Asia. But, in general, Mobile will serve as the nursery of many startups. In my opinion, we are facing a new bubble: the Mobile Bubble. There will be too many players asking for too much money (in investments) to build new ideas (most of which will be repetitions of previous attempts). Some of them will be interesting, some not. Some of them will float on the “enterprise ocean” but most of them will not.

Just like the dot-com bubble in the 90’s, I expect to see a similar “curve” in the evolution of mobile applications. I quote something I read on a relevant blog post: “For every really good dot-com idea there were a thousand really terrible ones” and I add: some really good ideas never made it to the business profit plateau due to problems other than their technical completeness.

It seems like the “curse” of mobile development is exactly its advantages:

• Requires forward thinking that usually young entrepreneurs have (along with not-so-developed entrepreneurship skills)
• It is a universal trend, so everybody that is seeking to do something new, inevitably turns their sights to that arena. The current situation is that most of the mobile-focused businesses are start-ups. This means not very-well-thought business plans, poor funding, low visibility etc. (Large players are still in the development or marketing phase of their venture. Some of them are even sitting back and observing “where the ship will turn to”)
• Modern tools make it easy to develop an average or poor user interfaces in a matter of days. So I would expect that a number of ideas will be condemned to obscurity just because of their poorly developed functionality or interface.

I still believe that mobile computing has a long way to cover. I also believe that the future of computing is mobile, since devices are becoming smaller, smarter, more power independent and – let’s face it – more of a personal gadget that everybody wants to have with them at all times. Also, it is the best form of computing device that can mix business and personal activities. But, we could also expect a “mobile bubble of the 2010’s” and we will probably (hopefully!) be here to discuss it, somewhere in the 2020’s!

How to increase conversions in a SaaS application (part 2)

In the previous post, I started the discussion of how SaaS vendors can increase their conversion ratios, defined as:
[Customers that adopted the product] / [Total Prospects]
In this post I shall continue with some more techniques that I have spotted in several products of the global market:

Demo account with preloaded data: No matter how good your web site presentation is and how explanatory the product videos are, there is nothing better than giving prospects the opportunity to use the software before they actually buy it. That way, they can see hands-on not what the vendor selected to show them (which are obviously the best parts of their product) but what they are supposed to be doing in their day to day operations. They will have the opportunity to make transactions like they would in real life and actually decide for themselves if this product is better than what they already have or the rest of the competition. Of course, it is crucial that your demo account has access to a meaningful, yet quite generic business model that most of the prospects can understand (even if it is not directly connected with their specific business line). Also, that demo account/system should be frequently updated with new releases and features that you add to your main offering. If that demo environment stays “still”, it is as good as dead. You have to make sure that your product evolution is directly demonstrated in your demo environment. Sure, that is an overhead for your sales team (updating and keeping it up to date) but that’s just the price that you have to pay.

Explanatory, contextual help: It is probably not enough to have a demo account in place. If your app has to do with fairly complex business transactions, it may not be so evident how it processes or integrates or implements them (e.g. how do you record a sales lead in a billing system and then convert it to an order and finally how do you create the actual invoice and dispatch the goods, etc.). Having on-line contextual help text, inside your app will help increase the visitor’s first understanding of the product and avoid being “overwhelmed” (which can lead to quitting the app). You can do this inside the application, or you can deploy third-party software to do that for you: Integrating a widget on your web system, can give you the possibility to add contextual help text and other material in each page, separately.

Active presence in social media: A SaaS app is by definition a web app. With the booming of social media, more and more applications come “closer” to a social-like style of user interface (Salesforce CRM is good example of this). On the other hand, social media gain more users every day and there doesn’t seem to be an end in this trend. Therefore, the vendor of the SaaS app, should also have a strong social media presence. There are several examples of how social media are used not only to “transmit” sales messages but also keep the users informed of new developments, give a heads-up for scheduled down-times, provide on-line support and building a sense of “community” around the users of the application. I regularly follow @Xero, because I think they are doing a good job at this level and I, too, get some lessons from them; but there are other examples, too.

Proof of frequent software updates: An application is only as good as the evolution that it enjoys from its maker. There is no doubt that software bugs exist and (annoying as it may be) we all have to live with them. The question is how quickly a bug is resolved. Apart from bugs, there is also the question of functionality enhancements and new features. In all cases, the prospect must be convinced that software updates happen often enough and for that you’d better be in a position to provide proof. Here are some thoughts: a) You can maintain a “new releases” and/or “issues resolved” blog. b) When you deploy a major release, you probably issue some “release notes”. Keep them public in a blog or a special page of the product web site. c) Use social media to transmit such information, too.

Self sign-up feature: After all that “trouble” (!) that the prospect went in, they may be quite ready to buy your solution. You need to be ready to get the customer “right then and there”, while they are hot. If your sales process involves a pre-sales contact through a sales representative, discussion about the SLA that you can offer etc., then you may not be able to exploit the “inertia” that the prospect has gotten while browsing and testing your solution, on-line. For that reason, you need to have in place a “self sign-up” feature where the prospect will be able to activate an account, instantly. Whether you will ask for a credit card deposit, immediately or after a period of time is another story.

This and the previous post were aiming to show ways that potentially increase the possibilities of a prospect adopting your solution. After that, there is the question of how do you keep these customers; how do you minimize customer churn rates. That is an issue that I will deal with in a next post.

How to increase conversions in a SaaS application (part 1)

There is quite a big discussion around how SaaS vendors can increase conversions into their offerings. It goes without saying that any SaaS product must have a strong presence on the internet (temporarily, setting aside other ways of promotion) and so a number of visitors is expected to land on the product page. They will read about the product, go through the brochure etc. But how will they be “intrigued” to take one step forward and actually use the product/service?

In this post, I deal with the increase of the conversion rate and not the increase in actual number of hits or visits in the web site. The latter falls in the jurisdiction of marketing experts and SEO’s. The conversion rate, however, is another story: it is about increasing the fraction:

[Customers that adopted the product] / [Total Prospects]

(Preferably, by increasing the numerator of the fraction instead of decreasing the denominator!)

So, what are the specific measures or techniques that a SaaS vendor can take in order to increase that number? Let’s have a look at the most important of them:

·         Explanatory product-specific site with lots of resources: Your company web site is not enough for what you are trying to accomplish: get new customers, through the internet without previous engagement by pre-sales consultants (that’s what SaaS is all about, if you are seeking to make money, right?). A new site (or micro-site, if you wish) would do the job better than the usual “our company-our products-our vision-contact us” corporate web site. Plus it gives the notion of an increased investment from your side, to build it.

Make sure that the site includes small videos, demonstrating some specific aspects of the functionality of the system. They must be focused on one specific business process, e.g. how you setup a new customer order, how do you issue a sales invoice. Focus on the strong points of your software, within that specific process, e.g. stress the fact that the invoice is issued automatically from an order with a click of a button, or other similar stuff.

·         Testimonials page: Another very important piece of that product micro-site is the testimonials page, in which prospects will see how exactly others like them have been benefited by the adoption of your application.

If it is possible, organize these testimonials by industry, so that prospects can easily find testimonials closer to their business case and model.

Consider including video-testimonials which are easier to follow, but take good care that their quality and speaker’s articulation is good enough.

·         Offer a free trial period: A free period is a period in which potential customers are able to work with the product (full-scale or partially, it doesn’t really matter, in my opinion) and see if it actually fits their needs. Also, it will give them a first-hand user experience, let them evaluate the user interface and – most important – identify areas of low coverage of their specific needs (in other words, areas that will require some customization, enhancements, new reports etc.). That last point is very important because it will add a “number” in the TCO that they are planning/willing to take. A product that will give them this opportunity (to test for themselves) will increase the probability of adopting, since the customization effort will be – to some extent – known beforehand.

Free periods are also technically feasible to offer: The software is on the cloud and so it costs little or nothing for the vendor to provide this option. This was not the case back in the “old days” when one had to see a system demo by a trained pre-sales consultant, buy the software, install it in the premises and then start customizing it. Therefore, since the technical capability is there, it is the market that drives us, vendors, to “not say no” in this option.

·         Offer a subscription-free period: After customers are engaged with the product, it is a good practice to offer a subscription-free period (at least, one month), so that any last doubts are resolved. A trial period gives the opportunity to use the product in real life and identify gaps, on the job. The subscription-free period gives the additional advantage that even if unexpected problems occur (during the first days of “Production” operation) the customer hasn’t paid any money, yet, even though he has probably signed a contract.

·         Actively engage with the customer: During that free trial or subscription-free periods, vendors have to make sure that they engage with the customer; they offer support, try to identify problems and mis-uses and give a “heads-up” to the customer and in general try to be “one step forward”. This is very important because, even if your self-explanatory site says it all, your price list is attractive and your user interface is exceptional, you can’t avoid some user’s mis-using the system or not being able to quickly absorb/digest all of its potential. So, even after a very quick and easy self sign-up process (we’ll talk about that in the next post), you just can’t leave the customer alone.

An additional reason for it is that this engagement will be a first glimpse on your company’s user support process (which will undoubtedly be appreciated!)

Stay tuned for more conversion-increasing techniques in the next post. Till then, take a second look at your product site…