Adopción ERP en modalidad SaaS «on the cloud»

Dirección (D): Tras descartar otras alternativas sobre el software de gestión empresarial a adoptar y decantarnos por una solución ERP, analizamos la conveniencia de adoptar un sistema privativo u otro Open Source. Debido a la irrupción en el mercado de distintas alternativas SaaS «on the cloud», nos planteamos la conveniencia de la adopción de un ERP en esta modalidad frente a la de un ERP on-premise. Por mis referencias parece ser que es una modalidad que lleva implícita un menor coste económico y temporal de implantación, por lo que podría ser una clara opción para el grupo XYZ.

Sergio Martínez (SM): El Software como Servicio (Software as a Service, SaaS), representa el modelo por el cual, tanto el propio software como los datos se alojan en instalaciones distintas a la del propio consumidor, mediante un proveedor que gestiona una aplicación (o suite de aplicaciones), ofreciéndola como servicio a demanda a muchos clientes/inquilinos a través de una única instancia (multi-tenancy), y repercutiendo cargos a esos clientes en función de su nivel de uso.

Esta definición de SaaS lleva implícita una serie de ventajas e inconvenientes, algunos de los cuales (no todas) representan un beneficio o un hándicap importante para XYZ. Veamos cuales son y como puede incidir este modelo sobre XYZ.

Ventajas y beneficios ERP SaaS

• Facilidad y rapidez de implantación. El despliegue suele ser muy rápido en comparación con soluciones on-premise. La formación, al ser entornos normalmente más intuitivos (aunque no tiene porqué), también.

Uno de los temores de la dirección de XYZ en la gestión del cambio era la demora en la implantación. El despliegue ERP SaaS reduce considerablemente estos tiempos.

• Convierte parte de los costes fijos en variables. El pago por uso suele reducir estos costes, sin embargo, hay que tener especial cuidado en el tipo de métrica usada para ese pago por uso: transacciones, usuarios activos, funcionalidades contratadas, capacidad de procesamiento asegurada, etc. La elección de una métrica u otra puede hacer demasiado imprevisible estos costes variables. Se reducen (o comparten entre los distintos inquilinos) costes de las licencias, soporte, mantenimiento, etc.

Otro de los temores de la dirección de XYZ era el sobredimensionamiento del proyecto y por tanto de sus costes. La alternativa SaaS permitiría iniciarse en un entorno controlado y de coste reducido. Por tanto, previsiblemente, menor TCO y un ROI más inmediato.

• Reduce los recursos necesarios del departamento TI. O por lo menos, permite asignar a éstos, tareas de mayor valor. El departamento de sistemas de XYZ es un departamento con muchos recursos humanos, para una plantilla relativamente pequeña, debido a la necesidad de mantener el software y las infraestructuras. La externalización de estos servicios podría permitir prescindir o reubicar alguno de estos recursos.

• Accesibilidad a través de navegadores. Hace innecesaria la instalación de software en los dispositivos de los usuarios, y permite la accesibilidad desde cualquier punto donde se tenga un acceso a internet.

Este punto es especialmente importante, dada la necesidad de XYZ de acceso por parte de los comerciales desde cualquier ubicación geográfica, así como de gerencia, desde cualquier punto y a cualquier hora.

• Simplifica actualizaciones y upgrades. El número de actualizaciones por parte del proveedor se reduce y además, es controlada, por lo que es más fácil tener a todos los clientes alineados frente a la opción on-premise que requiere de multitud de intervenciones, con la consiguiente dispersión de versiones en curso. En definitiva, el cliente recibe las actualizaciones con mayor frecuencia y sin necesidad de intervención por parte de los usuarios.

• Escalabilidad en infraestructura y usuarios a bajo coste. Contratar más usuarios, mayor capacidad de procesamiento, etc, no requiere de grandes inversiones económicos ni de tiempo.

El rápido crecimiento de XYZ augura un crecimiento paralelo en el número de usuarios, por lo supone una buena alternativa.

• Dado que el pago es por suscripción y periódico, el proveedor fidelizará al cliente con una buena atención y servicio.

 Inconvenientes y restricciones ERP SaaS

• Menor capacidad de customización. Puesto que solo existe un modelo de datos y es compartido por todos los clientes, la customización (desarrollos a medida) se hace más difícil. Es muy importante conocer de antemano las funcionalidades del ERP y que estén alineadas con las necesidades de la empresa, así como establecer acuerdos con el proveedor sobre el número y periodicidad de versiones, la incrementalidad en la funcionalidad de esas versiones, etc. El ritmo de evolución del software es importante en este sentido.

XYZ ya ha sufrido una obsolescencia en su software, no puede permitirse repetir el error. Habrá que prestar especial atención a si XYZ requiere de esa capa de personalización o puede quedar alineado con el producto estándar.

• Disponibilidad acceso a Internet. Si éste se interrumpe, los accesos también, por lo que es necesario asegurar esa disponibilidad. Los proveedores de Internet no suelen garantizar una fiabilidad 100%, y además, en algunos países donde XYZ posee subsidiarias comerciales, tanto la velocidad como la fiabilidad de las conexiones son reducidas.

• Sensación de inseguridad. Brechas de seguridad podrían permitir el acceso a la información de otros clientes, o incluso por parte del proveedor. Además, información de carácter marcadamente sensible o confidencial puede quedar expuesta.

XYZ dispone de información de gran valor, pero no crítica, por lo que este punto no es de vital importancia.

• Recuperación ante desastres y acuerdos de nivel de servicio (SLA). Se deberán fijar los acuerdos con el proveedor que garanticen la disponibilidad, el rendimiento, horarios de atención, tiempos de recuperación de backups, etc.

XYZ dispone de franjas horarias laborales en distintos husos, por lo que los acuerdos del servicio deben ser bastante explícitos en este sentido. Además, contingencias tarde o temprano las hay, por lo que es importante establecer por contrato el nivel y los límites del servicio.

• Propiedad de la información, migración de la aplicación y/o datos a otra infraestructura. No todos los proveedores facilitan la disponibilidad de los datos de su cliente cuando éste los requiere (por ejemplo, para una migración), por lo que es conveniente establecer medidas contractuales que eviten estas situaciones.

• Suelen presentar inconvenientes de compatibilidad con ofimática y aplicaciones locales. Es algo habitual, aunque más que por el hecho de ser en tecnologías web que por el propio hecho de ser en modalidad SaaS.

• Cumplimiento de requerimientos legales, tales como la LOPD en España. Si los servidores donde se ubica el ERP SaaS se encuentra fuera de España, es muy posible que no cumpla con los requisitos legales que exige la ley de protección de datos.

• Algunos fabricantes disponen de una solución Enterprise on-premise, y una solución SaaS con menores prestaciones. La adopción de esta última podría implicar carencias funcionales. Es importante, por tanto, ante la decisión de implantar un ERP, conocer ampliamente la funcionalidad ofrecida por cada uno de ellos o por cada una de sus distintas versiones. Una vez reducido el abanico de posibilidades, la decisión puede centrarse en la conveniencia de una modalidad SaaS, pero no antes.

• Se dificulta la integración con otras herramientas. Si el ERP no cumple con los módulos funcionales de un ERP II, se requerirá integración con herramientas de BI, CRM, etc.

XYZ ya tuvo problemas de reporting y analítica en el pasado, así que habrá que analizar con el proveedor estas posibilidades.

Tras esta batería de pros y contras sobre la adopción de un ERP SaaS, deberíamos ser capaces de asignarles una ponderación con la finalidad de dotar a XYZ de una herramienta de decisión objetiva.

Uno de los inconvenientes más importantes es que, si bien, la mayoría de ERP poseen un amplio espectro de personalización, en el caso de un ERP en modalidad SaaS, debido a su carácter multi-tenancy, la capacidad de customización se anula. A pesar que se debería reducir ésta al máximo, una empresa como XYZ, está acostumbrada a disponer de un departamento de desarrollo según sus necesidades. En este tipo de entornos, la zona de confort del usuario es aquella por la cual el sistema se adapta a su forma de operar, incluso en ocasiones en los mínimos detalles, en detrimento de otros usuarios, departamentos o del interés general de la empresa. Cambiar los procedimientos de trabajo y hacer reingeniería de procesos se ve como una amenaza al status de estos usuarios y por tanto provoca resistencia al cambio.

Autor: Sergio Martínez

Recibe nuevos artículos periódicamente, mediante la suscripción por e-mail, vía RSS o Google Currents.