Selección de aplicaciones SaaS. Gestión Servicio

 

Si vamos a utilizar una aplicación en modo SaaS – Software as a Service – tendremos que gestionar ese as a Service y la manera habitual de gestionar cualquier servicio externalizado es mediante acuerdos sobre la calidad del servicio que espera recibir el cliente del proveedor o, en la jerga del sector,  SLAs (Service Level Agreement) ligados a la QoS (Quality of Service).

Esta entrada no pretende cubrir en detalle qué es un SLA ni como se negocia/acuerda, hay mucha literatura, y buena, disponible, sino en los puntos particulares que pueda tener la gestión y medición del servicio en el caso de aplicaciones SaaS de gestión.

Dicho esto, cuando estemos negociando con nuestro proveedor de aplicaciones SaaS de gestión cómo se va a gestionar, medir y gobernar el servicio que nos quiere vender, tendremos que atender, al menos, a los siguientes puntos:

Niveles de servicio por capas.

Teniendo en cuenta la arquitectura típica de este tipo de aplicaciones es conveniente conocer los niveles de servicio para las distintas capas tecnológicas que la conforman:

• Aplicación
• Integración/Middleware
• Infraestructuras

En principio los niveles de servicio que más hemos de controlar directamente son los de Aplicación. El resto pueden ser relevantes si hay terceros proveedores, por ejemplo en la capa de infraestructuras. Y si ese es el caso leer bien los SLAs ofrecidos por ese tercero no vaya a ser que te pueda pasar esto.

 

Niveles de servicio por tipo

Los niveles de servicio se pueden definir de varios tipos. En este contexto no debería faltar:

• Rendimiento de la aplicación. Estos niveles de servicio no es aconsejable que sean genéricos y se han de intentar definir para las transacciones que consideremos más importantes – por ejemplo tiempo que se tarda en finalizar la entrada de un pedido de cliente. Es recomendable que cada empresa revise su caso particular y no acepte por defecto las estándares (si las hubiere, que es poco probable). Otro tema es como se mide.
• Tiempos de respuesta al soporte. Tiempos relacionados con consultas, incidencias, etc. de los usuarios finales o de los técnicos. Aparte de estos tiempos hay que definir tipos de incidencia/consulta, prioridades, etc.
• Disponibilidad de la aplicación. Normalmente se expresa en porcentajes de tiempo y excluye los tiempos dedicados a mantenimiento de la plataforma. No olvidar el periodo de medición de esa disponibilidad (no es lo mismo el 99,9% de disponibilidad mensual que anual).
• No disponibilidad del servicio por mantenimiento. Ya sé que he dicho antes que en una aplicación true SaaS el cliente ni se tiene que enterar de un cambio de versión pero entiendo que la plataforma requerirá paradas por mantenimiento. Hay que prestar atención a tiempos de preaviso y horarios (no es lo mismo no tener disponible la plataforma el día que lanzas la facturación mensual que no tenerla un domingo)
• Tiempos de puesta en marcha de nuevas funcionalidades. Si la aplicación, como debería una True SaaS, permite activar/desactivar funcionalidades, será conveniente especificar el tiempo de activación/desactivación operativa.

 

Ligados a los procesos de negocio

Ya se ha apuntado antes pero lo recalco. Estamos en un contexto de aplicaciones de gestión empresarial. Cualquier parámetro de gestión del servicio/sistema ha de tener como referente los procesos de negocio cuando se traten temas de disponibilidad, horarios, rendimientos, velocidad, tiempos de ejecución,… aunque hemos de ser conscientes del reto que puede suponer para el proveedor trabajar en ese modo.

 

Hay más elementos a tener en cuenta a la hora de negociar los SLAs pero no veo que tengan particularidades relevantes con respecto a un SaaS de aplicaciones de gestión. No obstante no nos olvidemos de temas como:

• Ajuste/renegociación de SLA. Hay que prever la posibilidad de ajustar periódicamente los parámetros que miden la calidad del servicio
• Monitorización. ¿Cómo va el cliente a ver en tiempo real los parámetros de medición de la calidad del servicio y  problemas que puedan haber?
• Reporting. Forma, periodicidad, formato de la información, etc. que el proveedor va a poner a disposición del cliente para el seguimiento de la calidad del servicio.
• Penalizaciones/incentivos si las expectativas no se cumplen o se cumplen mejor de lo previsto
• Mecanismos para la mejora continua
• etc.

 

No se me escapa que esta entrada ha quedado bastante genérica pero es que es un tema muy extenso. He intentado al menos citar los puntos más importantes en relación. Si crees que necesitas más ayuda no dudes en contactarme.

 

El resto de la serie y otras entradas relacionadas: Selección de aplicaciones de negocio SaaS. Puntos clave

 

Foto de Chandra Marsono