7 aspects to keep in mind to avoid failure in SaaS implementations

Software as a Service is gaining traction over on premise solutions year after year. Surely enough, cloud applications deliver good value to lots of customers, but that does not mean that the implementation of such a solution is risk less.

In this article, my intention is to highlight the key factors in avoiding SaaS implementations failure.

1.- Understand the value of cloud applications

The only benefit of cloud application is not the OpEx vs CapEx rationale. Compared to on premise solutions, SaaS has the ability to evolve faster. It is much easier for the vendor to have all the customers on the same codeline than supporting them in different versions, as it is usually the case in on premise products. In a way, implementing a cloud application is a bet on its evolution and its capability to cover new business requirements. Having this point in mind is key to drive change through the organization.

2.- Accept the application as it is

Most SaaS vendors will say that their applications are highly configurable or extendable. The reality is that, very often, when the organization has a clearly defined business flow before the cloud application comes to the scene, the cloud application does not cover 100% of the existing processes. Successful SaaS implementations often requires the customer to adapt to the product features, betting on its future development to cover the organization's ideal needs.

3.- Ability to drive change

Once the key users have decided together with the implementation team how the product is going to be configured, it is important to communicate the model to the rest of the company. In this communication, describing the benefits of SaaS is key to achieve the right positioning. Let the users know that the application will evolve much faster than other product, and communicate the enhancements that are useful for the organization as soon as they are enabled.

Naturally, sponsorship on the project is key to drive change through the organization. Lack of project sponsorship may translate in a myriad of requirements coming from all places in the organization.

4.- Methodology

The implementation methodology for on premise applications is not the best choice for SaaS implementations. Actually, normally is bad choice. SaaS implementation should be iterative by nature. The possibility of having a proof of concept quickly up to speed allows the system to evolve until it reaches its final shape. Adopting the usual top down methodology will only cause more costs and frustation to your organization.

5.- Deep knowledge of the application

Well, you may think that this applies also on premise implementation. True, but if a member of the implementation team generates wrong expectations to the users because of not knowing the application in full detail, there might be no way to satisfy that expectation. In on premise products, there was always a back-door available allowing customizations to be built to cover user needs. Having a good and deep product knowledge helps to set expectations realistically since the beginning.

6.- IT collaboration

The internal IT role is often neglected in SaaS implementations. Even though the role of IT has changed, it is important to involve them since the beginning of the project. Sooner or later, your project will meet a point where you need to collaborate with the IT department, either to build an integration with an existing system, to enable Single SignOn or to set up a support help desk. Make sure you have them on board from the start to guarantee a smooth project execution.

7.- Integrations

Make sure you have the right integration strategy for your organizations. Integrations may be built using on premise equipment, Platform as as Service or even cloud application specifically designed for that purpose. Whenever you come through an integration requirement, fully assess the situation in order to pick the right solution. Organizations are often tempted to build the integrations using on premise facilities, but this is far from being the best option in all cases. You do not want to end with a cloud application that is difficult to maintain due to the number of ad hoc integrations you have built.

Conclusions

Although SaaS applications usually cover the same features we have seen around in on premise products for years, their implementation projects have very specific challenges, risks and opportunities. If your implementation team is fully aware of them, you have set the cornerstone for project success.

Muchas gracias por tus comentarios Rubén.

回复
Rubén Oca?a Sánchez

Operations Security Engineer at EUMETSAT

9 年

?Totalmente de acuerdo! Creo que hoy en día las claves para que un proyecto del tipo (y casi para cualquier proyecto de implantación de un SI) que comentas nacen en las fases previas a la implementación. Una toma de requisitos correcta con el cliente no es tan evidente como parece y a veces se le resta importancia. Esta fase puede adelantarnos a posibles problemas de integración, adaptabilidad y desarrollo que a priori no vemos. Yo creo que es vital hacer partícipe del proyecto a todas las áreas IT, así como transmitir los beneficios que tiene la nueva herramienta que va a utilizar evitará los rechazos tan conocidos al cambio. Muchas gracias, es un gran artículo que todo consultor debería leerse y, como diría un abogado: "Nada más que a?adir Se?oría". Un saludo

要查看或添加评论,请登录

Javier Delgado的更多文章

社区洞察

其他会员也浏览了