17/06/2011 | Expert opinion - Nicolas Odet, Director of Services, Marketing and Communication, Hardis Group
For software publishers, moving from a model of license sales, support and maintenance to a system involving subscription to a service is not without consequence: technical changes need to be made to their solutions, the marketing and sales effort is different and there may be an impact on internal organization. To avoid mistakes and to bring a project on which the future of an entire company may depend to a successful conclusion, a complete check up is compulsory.
1. Market research: the essential step
As with any new offer, market research is the first step of the process for transforming a software solution from licensing mode to SaaS mode. Not so much in functional terms: the need exists since the tool is already used by companies or professionals (craftsmen, professionals, tradesmen, etc.). But rather in terms of the model used to make the solution available: does it correspond to a real request or need? Will it help to preserve the existing client base and / or reach different customers? What is the type of customer being targeted? Do similar solutions already exist? At what price? With what levels of functionality and service? Etc, etc.
This step will help to determine precisely which version of the product, standard or specific, complete or light, will be switched to SaaS.
2. Is my software already Web oriented?
The release schedule for a future SaaS version will depend on the answer to this question. Software already available with a Web interface has an advantage since it is already designed for browser access. For the others (conventional client/server solutions for example), the R &D effort will need to be greater since they will have to be adapted to the Web, at least as far as the interface is concerned. The good news is that complete redevelopment of the software or software package is not necessarily required. One of the workarounds to switch the client / server or legacy applications over to the cloud without starting from scratch, is to publish in "thin computing" mode... but some "SaaS compatibility"aspects still have to be checked.
3. Is my software SaaS compatible?
Technically, for software to be easily transposed into SaaS mode, it must be "shareable" and "virtualizable". To quickly clarify these two concepts, here is a list of some things to check:
- What version and what features need to be switched over?
- What are the characteristics of the components of the application (database, operating system, directory, etc.)?
- Are these components shareable? Example for the database: can my software handle different customers on the same instance in a leak tight manner? If the answer is no, it will potentially be necessary to provide one environment per customer.
- Are these components virtualizable? The answer to this question will determine whether it can be easily hosted on virtualized infrastructures.
Another point to check: the consumption of system and network resources. If this is too high before switching to SaaS, application bottlenecks will have to be sought out and corrected.
4. What should be outsourced?
For a publisher, switching ones solutions to SaaS can also be an opportunity to consider outsourcing ones own infrastructure, in order to gain flexibility and responsiveness. And also to migrate the test development and acceptance environments, in addition to the production environment made available to its customers. This decision obviously has consequences for the redeployment of the publisher's human resources.
5. Cumulative service levels
The characteristic of SaaS is that the publisher's offer, unless he chooses to host and manage his own infrastructure (but is that his job?) depends on another provider: the cloud infrastructure facilities management provider.
So it is essential to accurately determine the levels of service to be offered to customers, the basis of calculation (application uptime, performance, etc.) and, as a result, the levels of service required of the infrastructure provider. In all cases, we must never forget to stack service commitments so as to allow time for each (publisher and infrastructure provider) to carry out the maintenance and solution recovery operations.
6. Customer support: an organization to be set up
Another aspect to consider when moving to SaaS is the opening times for technical support. Even more than for "conventional" solutions, and especially due to the accessibility of SaaS tools from any computer connected to the Web, the question of 24/7 support should be considered.
It impacts both the organizational level of the staff and the cost of the solution. For a 24/7 service, the publisher can for example set up an internal on-call service for functional issues and negotiate with the infrastructure provider for him to take on support related to technical problems.
7. Funding: a new kind of cash flow
In general, it is considered that a software company is financed up to 75 % with license sales, the remaining quarter corresponding to support and maintenance. Three quarters of its turnover are therefore provided by "cash" sales, payable in the short term. These amounts help it to fund R & D for future versions.
In contrast, SaaS spreads the expense over time as a subscription. While this lack of initial investment is one of the arguments put forward by the publishers of SaaS solutions, it has its downside in terms of billing and may, at least temporarily, destabilize their cash flow. Funding solutions must then be set up to support R&D work.
8. Legal: new contracts to be drawn up
Another parameter to consider: the legal aspects, because a license sale or maintenance agreement has not much to do with a contract to supply software services. It is essential to define the standard contract clauses to submit to customers, particularly in terms of the rights and obligations of each party. Models exist, including one proposed by Syntec Informatique.
9. Marketing: important groundwork
Transposing a conventional solution to SaaS also requires a substantial change in the marketing mix. According to the famous 4P rule (Product, Price, Place, Promotion), the Product having being developed, it remains to (re)define the other three Ps.
Starting with the Price: at what price should the subscription to the solution be offered? It will basically vary depending on the modules used and the level of service offered.
The Place, i.e. the distribution method(s) can be a tricky point: for example, a publisher who previously relied on an indirect sales network will have to find new ways of paying his current retailers, so that they do not find themselves in a difficult situation.
Finally, the "sales-kit" (product fact-sheet, web site, video, Powerpoint presentation, "how to sell" and ready-to-use customer arguments) will also need to be reviewed in order to integrate the new positioning, present the new offer and the benefits for future clients, etc. Not to mention Web marketing operations (creating new pages on the company's website and / or a mini event website, keyword optimization for better SEO, promotion through social networks, etc.), and communication and operational marketing actions aimed at identified targets (e-mailing, presentation events,etc.).
10. Essential training for sales teams
Finally, the publisher's sales force is also impacted by the changeover to SaaS: licenses accompanied by support and maintenance services are not sold like a subscription to an online service. And you're not paid in the same way!
Coaching for sales and pre-sales staff is essential for them to fully adopt the new offer (strategic objectives, understanding the model, new commission rates, etc.) and its marketing pitch (presentation of the offer, customer benefits, etc.).
To conclude, moving from the conventional mode to SaaS is a decision that is not to be taken lightly. Nevertheless, history does not seem to run counter to fashion trends. And while the shift to cloud computing has not yet been completely made, it is better not to delay much longer...