Capítulo 3 · Marco SaaS Maestro de ProjectVIEW ERP
El Acuerdo de Nivel de Servicio de ProjectVIEW ERP establece un compromiso de disponibilidad mensual del 99.9% del entorno de producción, un Recovery Point Objective de 15 minutos y un Recovery Time Objective de 4 horas. Los incidentes se clasifican de P1 a P4 con objetivos definidos de respuesta y resolución (MTTR), de modo que un incidente P1 recibe una respuesta inmediata y un objetivo de MTTR de 4 horas, 24×7×365, y el rendimiento del SLA se informa mensualmente y se revisa trimestralmente.
- 99.9%disponibilidad mensual (producción)
- 15 minRecovery Point Objective
- 4 hRecovery Time Objective
- 4 hobjetivo MTTR de P1, 24×7×365
3.1 Resumen del SLA
Esta sección define los Niveles de Servicio que el Proveedor se compromete a alcanzar en la entrega y el soporte de la Plataforma. El Proveedor empleará esfuerzos comercialmente razonables para cumplir o superar los Niveles de Servicio establecidos en esta sección al prestar los Servicios.
Los Niveles de Servicio abarcan la disponibilidad de la plataforma, la respuesta a incidentes, los objetivos de resolución, los objetivos de copia de seguridad y recuperación, y los correspondientes Créditos de Servicio en caso de incumplimiento.
El SLA se aplica únicamente al entorno de producción de la Plataforma. Los entornos no productivos (desarrollo, sandbox/pruebas) quedan excluidos de la medición del SLA, salvo que se especifique lo contrario en el Contrato Comercial.
3.1 Disponibilidad de la Plataforma
3.1.1 Objetivo de Nivel de Servicio (SLO)
El Proveedor se compromete a un Objetivo de Nivel de Servicio de 99.9% de tiempo de actividad mensual para el entorno de producción de la Plataforma, medido como porcentaje del total de minutos del mes natural aplicable.
| Métrica | Objetivo | Periodo de medición |
|---|---|---|
| Objetivo de Nivel de Servicio (SLO) | 99.9% | Mes natural |
| Tiempo máximo de inactividad permitido | 43.2 minutos / mes | Calculado: (1 – 0.999) × 43,200 min |
3.1.2 Cálculo de la disponibilidad
La disponibilidad mensual se calcula mediante la siguiente fórmula:
% de disponibilidad = ((Minutos totales – Minutos de inactividad) / Minutos totales) × 100
Donde:
- Minutos totales = el número total de minutos del mes natural aplicable
- Minutos de inactividad = el total de minutos durante los cuales el entorno de producción no está disponible, excluyendo el Mantenimiento Programado y los Eventos Excluidos
3.1.3 Mantenimiento programado
El Proveedor realizará el mantenimiento programado durante las ventanas de mantenimiento acordadas previamente. El Mantenimiento Programado queda excluido de los cálculos de Disponibilidad siempre que:
- (a) El Proveedor entregue al Cliente un preaviso por escrito de 5 días hábiles como mínimo sobre el mantenimiento programado;
- (b) El mantenimiento se programe durante horas de baja actividad (entre las 22:00 y las 06:00 hora local en la sede principal del Cliente), salvo que se acuerde lo contrario;
- (c) El Mantenimiento Programado Total no excede 4 horas por mes calendario;
- (d) El Proveedor emplee esfuerzos comercialmente razonables para minimizar la duración y el impacto de cada ventana de mantenimiento. Mantenimiento de emergencia: En caso de una vulnerabilidad crítica de seguridad o de una falla inminente del sistema, el Proveedor podrá realizar mantenimiento de emergencia con menos de 5 días hábiles de preaviso. El Proveedor notificará al Cliente tan pronto como sea razonablemente posible y proporcionará un informe posterior al mantenimiento dentro de los 2 días hábiles.
3.2 Ciclo de vida del entorno
Durante la implementación, el Proveedor habilita dos (2) entornos distintos para el Cliente:
| Fase | Entorno | Finalidad |
|---|---|---|
| Implementación | Desarrollo / Sandbox | Configuración, personalización, migración de datos, pruebas de integración y Pruebas de Aceptación de Usuario Universal (UAT). El Cliente y el Proveedor validan conjuntamente todos los requisitos funcionales antes del Go-Live. |
| Implementación | Producción | El entorno operativo en vivo para todos los Usuarios Autorizados. Sujeto a las métricas completas del SLA definidas en esta Sección 3. |
3.2.1 Transición del entorno tras el Go-Live
Tras el Go-Live, la estructura del entorno pasa a ser la siguiente:
| Entorno | Rol posterior al Go-Live | Finalidad |
|---|---|---|
| Desarrollo / Sandbox | Entorno de Staging | Pasa a ser el entorno de preproducción permanente utilizado para: depuración y reproducción de fallos, solicitudes de cambio y desarrollo de mejoras, actualizaciones de software y pruebas de parches, y Pruebas de Aceptación de Usuario Universal (UAT) antes de la implantación en producción. |
| Producción | Entorno de Producción | Continúa como entorno operativo en vivo. No se despliegan cambios en producción sin validación previa y aprobación de UAT en el Entorno de Preproducción. |
Pruebas de Aceptación de Usuario Universal (UAT): Todos los cambios de software, parches, actualizaciones y nuevas versiones de funcionalidades deben pasar por UAT en el Entorno de Preproducción antes de su despliegue en Producción. Se concederá al Cliente un mínimo de 5 días hábiles para completar la UAT, y el despliegue en Producción requiere aprobación escrita del Cliente. El Proveedor no desplegará ningún cambio en el Entorno de Producción sin la aprobación confirmada de UAT, salvo en el caso de Mantenimiento de Emergencia según se define en la Sección 3.1.3.
El Proveedor mantendrá la paridad entre los entornos de Preproducción y Producción para garantizar que los resultados de UAT sean representativos del comportamiento en producción. Ambos entornos ejecutarán en todo momento versiones de software, configuraciones y políticas de seguridad idénticas, diferenciándose únicamente en el contenido de los datos.
3.3 Objetivos de recuperación
El Proveedor se compromete con los siguientes objetivos de recuperación para el entorno de producción, alineados con la arquitectura de Continuidad del Negocio y Recuperación ante Desastres (BC/DR) de la Plataforma:
| Métrica | Objetivo | Definición |
|---|---|---|
| Recovery Point Objective (RPO) | 15 minutos | La cantidad máxima aceptable de pérdida de datos medida en el tiempo. Las copias de seguridad del registro de transacciones se ejecutan cada 15 minutos, garantizando que no se pierdan más de 15 minutos de datos en un escenario de desastre. |
| Recovery Time Objective (RTO) | 4 horas | La duración máxima aceptable de interrupción del servicio. El Proveedor restablecerá la funcionalidad completa de la plataforma en un plazo de 4 horas desde la declaración de un evento de desastre. |
Estos objetivos de recuperación cuentan con el respaldo de la siguiente arquitectura de copia de seguridad:
| Tipo de copia de seguridad | Frecuencia | Retención | Cifrado |
|---|---|---|---|
| Copias de seguridad del registro de transacciones | Cada 15 minutos | 7 días | AES-256 en reposo |
| Copias de seguridad completas de la base de datos | Cada 12 horas | 30 días | AES-256 en reposo |
| Copias incrementales de archivos | Diaria | 30 días | AES-256 en reposo |
| Copias de seguridad completas semanales | Semanal (domingo) | 90 días | AES-256 en reposo |
| Copias de seguridad de archivo mensuales | Mensual (día 1) | 12 meses | AES-256 en reposo |
Todas las copias de seguridad se almacenan en almacenamiento Azure georredundante dentro de la región Azure designada por el Cliente, con replicación entre regiones opcional según se especifique en el Contrato Comercial. La integridad de las copias de seguridad se verifica mediante pruebas automatizadas de restauración realizadas trimestralmente.
Resumen de Azure Backup: https://azure.microsoft.com/en-us/products/backup
3.4 Clasificación de prioridad de incidentes
Todos los Incidentes reportados al Service Desk del Proveedor (PSD) se clasificarán de acuerdo con los siguientes niveles de prioridad:
| Prioridad | Gravedad | Definición | Ejemplo |
|---|---|---|---|
| P1 | Crítico | Indisponibilidad total del sistema o fallo crítico de una función empresarial que afecte a todos o a la práctica totalidad de los Usuarios Autorizados. Riesgo para la integridad de los datos. | Servidor de producción caído, corrupción crítica de la base de datos, plataforma totalmente inaccesible, evento de pérdida de datos. |
| P2 | Urgente | Deterioro significativo de una función empresarial crítica. Sistema operativo pero con funcionalidad gravemente limitada. Funcionalidad principal no disponible. | Módulo clave no operativo (por ejemplo, Control de Costes), deterioro grave del rendimiento, fallo crítico de integración. |
| P3 | Mayor | Función no crítica afectada o rendimiento degradado que no impide las operaciones centrales del negocio. Existe una solución alternativa razonable. | Fallo en la generación de informes, problema en un módulo no crítico, defecto cosmético que afecta la usabilidad, fallo menor de integración. |
| P4 | Menor | Problema cosmético, solicitud de información o sugerencia de mejora sin impacto operativo inmediato. | Problema de alineación de la interfaz de usuario, corrección de documentación, solicitud de funcionalidad, consulta general. |
La clasificación de prioridad será acordada mutuamente entre el Cliente y el Proveedor en el momento de registrar el ticket. Si las Partes no llegan a un acuerdo, prevalecerá la clasificación del Cliente en espera de revisión por parte del Service Delivery Manager en la siguiente reunión programada de Revisión del Servicio.
Los Incidentes P1 y P2 deben reportarse por teléfono al Service Desk del Proveedor para garantizar atención inmediata. Los Incidentes P3 y P4 pueden reportarse por correo electrónico, el portal PSD o por teléfono.
3.5 Matriz de respuesta y resolución del SLA
El Proveedor responderá y resolverá los Incidentes dentro de los objetivos establecidos en la siguiente Matriz del SLA:
| Prioridad | Tiempo de respuesta | Objetivo MTTR | Objetivo de solución provisional | Ventana de operación | Objetivo GOS |
|---|---|---|---|---|---|
| P1 – Crítico | Inmediato | 4 horas | Esfuerzo continuo hasta su resolución | 24 × 7 × 365 | 98% |
| P2 – Urgente | Inmediato | 8 horas | 15 días hábiles | 24 × 7 × 365 | 95% |
| P3 – Mayor | En un plazo de 2 horas | 12 horas | 20 días hábiles | 24 × 7 × 365 | 93% |
| P4 – Menor | En un plazo de 4 horas | Siguiente versión | Siguiente lanzamiento programado | Horario laboral | 90% |
Donde:
- Tiempo de respuesta = tiempo transcurrido desde el acuse de recibo del Incidente por parte del PSD hasta la primera acción de diagnóstico por parte de un ingeniero asignado
- MTTR (Mean Time to Repair) = tiempo transcurrido objetivo desde el acuse de recibo del Incidente hasta la resolución completa o una solución provisional eficaz
- Objetivo de solución provisional = tiempo máximo transcurrido para proporcionar una resolución temporal que restablezca la funcionalidad empresarial central mientras se espera la corrección definitiva
- GOS (Grade of Service) = porcentaje de Incidentes dentro de cada nivel de prioridad que se resuelven dentro del objetivo MTTR durante el periodo de medición
3.6 Exclusiones del SLA
Los siguientes eventos quedan excluidos de la medición del SLA y no se contabilizarán como Tiempo de Inactividad ni afectarán a los cálculos de GOS:
- (a) Mantenimiento programado : mantenimiento notificado previamente realizado dentro de las ventanas de mantenimiento acordadas según lo definido en la Sección 3.1.3
- (b) Eventos de seguridad : cualquier tiempo de inactividad derivado de brechas de seguridad, ataques DDoS o parches de seguridad de emergencia aplicados para proteger la Plataforma y los Datos del Cliente
- (c) Fuerza mayor : eventos fuera del control razonable del Proveedor según se define en la Sección 9
- (d) Retrasos causados por el Cliente : retrasos derivados del incumplimiento por parte del Cliente de sus obligaciones en virtud de la Sección 2.8, incluida la falta de suministro oportuno de información, retrasos en aprobaciones o modificaciones no autorizadas
- (e) Fallos de terceros : interrupciones en la conectividad a Internet, DNS u otros servicios no bajo el control directo del Proveedor, incluidas las interrupciones de la plataforma Microsoft Azure que afectan a la infraestructura subyacente
- (f) Retrasos del ciclo de aprobación : retrasos causados por flujos de trabajo de aprobación o procesos de firma del Cliente que impiden al Proveedor continuar con las actividades de resolución En caso de una interrupción de la plataforma Azure, el Proveedor entregará al Cliente el informe correspondiente de Microsoft Root Cause Analysis (RCA) dentro de los 5 días hábiles siguientes a su publicación por Microsoft.
Azure Service Health: https://azure.microsoft.com/en-us/features/service-health/ Azure Status: https://status.azure.com/
3.7 Penalizaciones por incumplimiento del SLA
Cuando el Proveedor no alcance los objetivos de SLO o de Grade of Service (GOS) establecidos en esta Sección 3, el Cliente tendrá derecho a penalizaciones económicas abonadas por el Proveedor. La escala de penalización, la base de cálculo y los topes se establecen en el Contrato Comercial de cada Cliente. En resumen:
- (a) Escalonadas según la desviación: las penalizaciones aumentan en función de la magnitud del incumplimiento respecto del objetivo. Una desviación pequeña dentro de la tolerancia acordada no conlleva penalización.
- (b) Dos medidas: tanto el desempeño de Disponibilidad (SLO) como el de Nivel de Servicio (GOS) cuentan para la penalización, teniendo la Disponibilidad el mayor peso.
- (c) Pago directo: las penalizaciones se pagan como un desembolso financiero directo, no como una nota de crédito, una vez validada la reclamación del Cliente. Se aplica un tope trimestral.
- (d) Proceso de reclamación: el Cliente presenta una reclamación por escrito con los Incidentes relevantes y las pruebas de respaldo dentro de 30 días desde el final del mes en que se produjo el incumplimiento. El Proveedor valida o impugna la reclamación en un plazo de 10 días hábiles. Las disputas se elevan al Steering Committee.
- (e) Único recurso económico: las penalizaciones constituyen el único y exclusivo recurso económico del Cliente por no alcanzar los Niveles de Servicio. Esto no limita el derecho del Cliente a resolver el Framework por incumplimiento material conforme a la Sección 7.
- (f) Exclusiones: no se abonará ninguna penalización cuando el incumplimiento del SLA derive de un Evento Excluido según se define en la Sección 3.6.
3.8 Licencias adicionales y nuevos usuarios
Cuando el Cliente opte por añadir nuevos Usuarios Autorizados (licencias adicionales) durante el Plazo de Suscripción, se aplicarán las siguientes disposiciones:
- (a) Misma cobertura de SLA: Todos los Niveles de Servicio, objetivos de rendimiento, objetivos de recuperación y disposiciones de penalización establecidos en esta Sección 3 se aplicarán por igual a todos los Usuarios Autorizados y licencias adicionales desde la fecha de activación. No existe un SLA reducido ni por fases para los nuevos usuarios.
- (b) Ajuste de ARR: El ARR utilizado para los cálculos de penalización conforme a la Sección 3.8 se recalculará para incluir las tarifas de las licencias adicionales desde la fecha de activación, de forma prorrateada para el resto del periodo de medición aplicable.
- (c) Coherencia del entorno: Los nuevos usuarios tendrán acceso a los mismos entornos de Producción y Preproducción. El Proveedor garantizará que la Plataforma escale para dar cabida a los usuarios adicionales sin degradación del rendimiento ni de la Disponibilidad.
- (d) SLA de incorporación: El Proveedor activará las nuevas cuentas de usuario dentro de 2 días hábiles desde la recepción de una solicitud completa de alta de licencias por parte del Cliente, incluida la asignación de roles, el aprovisionamiento de accesos y el material de formación inicial.
- (e) Garantía de capacidad: El Proveedor garantiza que el entorno privado soberano dedicado dispone de capacidad suficiente, o será escalado de forma proactiva, para dar soporte a los usuarios adicionales sin afectar al SLO del 99.9% ni a ningún objetivo de GOS. El procedimiento para añadir nuevas licencias, incluidos los requisitos de precios y de modificación del Contrato Comercial, se establece en la Sección 6 (Honorarios, facturación y condiciones de pago).
3.9 Informes de SLA y revisiones del servicio
3.9.1 Informe mensual de SLA
A solicitud del Cliente, el Proveedor podrá entregar al Cliente un informe mensual del rendimiento del SLA dentro de los 10 días hábiles siguientes al final de cada mes natural. El informe incluirá:
- (e) Porcentaje mensual de Disponibilidad y comparación con el objetivo SLO
- (f) Número total de Incidentes por nivel de prioridad, con tiempos de respuesta y de resolución
- (g) Cumplimiento de GOS por nivel de prioridad
- (h) Tasas de éxito de las copias de seguridad y cualquier evento de copia de seguridad fallida
- (i) Cualquier incumplimiento del SLA con análisis de causa raíz y acciones correctivas
- (j) Cálculos de penalizaciones (si corresponde) con el criterio de ARR mostrado
- (k) Análisis de tendencias comparando el desempeño con los 3 meses anteriores
3.9.2 Revisión trimestral del servicio
Las Partes podrán celebrar una reunión de Revisión Trimestral del Servicio para revisar el rendimiento del SLA, debatir iniciativas de mejora del servicio y abordar cualquier asunto pendiente. El Proveedor preparará y presentará un informe trimestral del servicio en el formato acordado por el Cliente al menos 5 días hábiles antes de cada reunión de revisión. El informe trimestral incluirá:
- (l) Desempeño consolidado del SLA durante el trimestre
- (m) Resúmenes de incidentes graves con análisis de causa raíz
- (n) Actualizaciones y avances del plan de mejora del servicio
- (o) Análisis de tendencias de capacidad y rendimiento
- (p) Resumen de gestión de cambios (parches, actualizaciones, versiones desplegadas)
- (q) Evaluación prospectiva de riesgos y plan de mitigación
3.9.3 Mejora continua del servicio
El Proveedor mantendrá un registro de Mejora Continua del Servicio (CSI) que documente las oportunidades de mejora identificadas, las acciones acordadas, los responsables y las fechas objetivo de finalización. El registro CSI se revisará en cada Revisión Trimestral del Servicio.
3.10 Gobernanza del SLA
La siguiente estructura de gobernanza se aplica a la gestión del SLA:
| Rol | Responsabilidad | Frecuencia |
|---|---|---|
| Service Delivery Manager (Proveedor) | Punto principal de responsabilidad sobre el rendimiento del SLA. Responsable del informe mensual de SLA, la gestión de escalaciones y el registro CSI. | En curso |
| Account Manager (Proveedor) | Gestión de la relación comercial. Punto de escalado para disputas de SLA y reclamaciones de Créditos de Servicio. | Cuando sea necesario |
| Enlace de TI del Cliente | Contacto principal del Cliente para la gestión diaria del servicio, la notificación de Incidentes y la coordinación de UAT. | En curso |
| Steering Committee | Foro conjunto de alta dirección para la revisión estratégica de la relación de servicio, la revisión de Incidentes Mayores y las decisiones a nivel de contrato. | Semestral |
Los objetivos de SLA establecidos en esta Sección se revisarán anualmente en la reunión del Steering Committee y podrán modificarse por acuerdo escrito mutuo de las Partes.
Resumen del SLA de Azure: https://azure.microsoft.com/en-us/support/legal/sla/summary/ Gestión de niveles de servicio ITIL: https://www.axelos.com/best-practice-solutions/itil
3.11 Registro de procesos
La siguiente tabla resume los procesos de gestión del SLA establecidos en este capítulo, incluidos los roles responsables, los resultados esperados y las referencias cruzadas a procesos relacionados en otros capítulos.
Leyenda de roles: P = Proveedor | C = Cliente | PSD = Service Desk del Proveedor | SDM = Service Delivery Manager | SC = Steering
Committee
3.11.1 Registro de procesos
| Ref | Proceso | Disparador | Responsable | Aprobador | Resultado Esperado | Cruz. Ref. |
|---|---|---|---|---|---|---|
| P-3.01 | Monitoreo de la disponibilidad | Continuo (automatizado) | Proveedor (NOC) | SDM | SLO del 99.9% mantenido; alertas ante incumplimiento del umbral | § 3.2 |
| P-3.02 | Clasificación de incidentes | Incidente reportado al PSD | PSD | Cliente / SDM | Prioridad acordada mutuamente (P1–P4) | § 3.5, § 4.3 |
| P-3.03 | Medición del rendimiento del SLA | Cierre de fin de mes | SDM | — | Informe mensual de SLA dentro de 10 días hábiles | § 3.9.1 |
| P-3.04 | Detección de incumplimiento del SLA | El informe mensual de SLA revela incumplimiento | SDM | Responsable de cuentas del Proveedor | Se inicia el cálculo de la penalización | § 3.8 |
| P-3.05 | Reclamación y pago de penalización | El Cliente presenta la reclamación dentro de 30 días | Finanzas del Proveedor | Responsable de cuentas del Proveedor | Pago financiero dentro de los 30 días posteriores a la validación | § 3.8 |
| P-3.06 | Revisión trimestral del servicio | Cierre de trimestre | SDM + Enlace de TI del Cliente | Comité Directivo | Revisión del servicio completada; registro CSI actualizado | § 3.9.2, § 4.10 |
| P-3.07 | Activación de nuevo usuario | Solicitud de alta de licencia del Cliente | Proveedor (PSD) | Enlace de TI del cliente | Usuario activo dentro de 2 días hábiles; ARR ajustado de forma prorrateada | § 3.9, § 6 |
| P-3.08 | Mantenimiento programado | Ventana de mantenimiento planificada | Proveedor (Infra) | SDM | Mantenimiento completado; ≤ 4 h/mes; Cliente notificado con 5 días hábiles de antelación | § 3.1.3 |
3.11.2 Matriz RACI
| Proceso (Ref) | Proveedor | PSD | Cliente | SDM | SC |
|---|---|---|---|---|---|
| P-3.01 Monitoreo de la disponibilidad | R | I | I | A | — |
| P-3.02 Clasificación de incidentes | — | R | C | A | — |
| P-3.03 Medición del SLA | — | — | I | R/A | I |
| P-3.04 Detección de incumplimientos | — | — | I | R | I |
| P-3.05 Reclamación de penalización | R | — | R | A | I |
| P-3.06 Revisión trimestral | C | — | R | R | A |
| P-3.07 Activación de usuarios | R | R | A | I | — |
| P-3.08 Mantenimiento programado | R | I | I | A | — |
R = Responsable (ejecuta) | A = Accountable/Responsable último (aprobación final) | C = Consultado | I = Informado | — = No participa
3.11.3 Flujo del proceso — Ciclo de vida del SLA
| Etapa | Actividad | Rol | Resultado |
|---|---|---|---|
| ① Monitorear | Monitoreo continuo de disponibilidad y rendimiento (Azure Monitor, Defender) | Proveedor (NOC) | Alertas en tiempo real; datos de disponibilidad |
| ② Detectar | Incidente detectado o reportado a través del canal omnicanal del PSD | PSD / Cliente | Ticket creado → § 4.3 |
| ③ Clasificar | Se asigna prioridad (P1–P4), comienza el reloj del SLA | PSD + Cliente | Prioridad acordada; temporizador de respuesta |
| ④ Resolver | Resolución según el objetivo MTTR; escalado si es necesario | Ingeniería del Proveedor | Incidente resuelto → § 4.4 |
| ⑤ Informe | Informe mensual de SLA generado; GOS y Disponibilidad calculados | SDM | Informe de SLA → § 3.9.1 |
| ⑥ Revisión | Revisión Trimestral del Servicio; registro CSI actualizado | SDM + Cliente + SC | Acciones CSI → § 4.10 |
| ⑦ Penalizar | Si hay incumplimiento: reclamación de penalización, validación, pago financiero | Cliente → Finanzas del Proveedor | Pago dentro de 30 días |
