Soporte y Operaciones del Servicio

4.1 Resumen

Esta sección define el marco de soporte operativo mediante el cual el Proveedor presta los servicios de soporte diario para la Plataforma. Establece la estructura, los procesos y las responsabilidades para la gestión de incidentes, la gestión del ciclo de vida de tickets, el mantenimiento preventivo, el escalamiento técnico y el control de cambios operativos.

Todos los procesos de soporte se alinean con las directrices de mejores prácticas de ITIL 4 y aprovechan el modelo de soporte omnicanal del Proveedor para garantizar una prestación del servicio rápida, trazable y rica en contexto en todos los canales de comunicación.

Los servicios de soporte aplican al Entorno de Producción y, cuando se acuerde expresamente en el Contrato Comercial, al Entorno de Staging. El Proveedor mantendrá procedimientos de soporte documentados y los pondrá a disposición del Cliente previa solicitud razonable. Todas las actividades de soporte se registran y siguen a través del sistema de tickets integrado de la Plataforma, lo que proporciona visibilidad de extremo a extremo tanto al Proveedor como al Cliente.

4.2 Mesa de Servicio del Proveedor (PSD)

La Mesa de Servicio del Proveedor (PSD) es el punto único de contacto para registrar, gestionar y resolver todos los tickets relacionados con soporte técnico, incluidos Incidentes, Solicitudes de Servicio, Problemas y Solicitudes de Cambio planteadas por el Cliente. La PSD opera un modelo de soporte omnicanal que unifica la gestión formal de tickets, la mensajería en tiempo real y los canales de comunicación tradicionales en un único flujo de soporte trazable. La PSD coordina con el enlace de TI designado del Cliente todos los servicios de soporte y mantenimiento.

4.2.1 Sistema de tickets integrado

La Plataforma incorpora un sistema de tickets nativo integrado dentro de la propia aplicación ProjectVIEW ERP. Esta capacidad de ITSM integrada permite a los Usuarios Autorizados generar, hacer seguimiento y gestionar tickets de soporte directamente desde la Plataforma sin salir del entorno ERP. El sistema de tickets integrado ofrece:

• (a) Registro de tickets en la aplicación: Los usuarios generan tickets directamente dentro de la interfaz de ProjectVIEW ERP, con captura automática de información contextual que incluye el módulo activo, la pantalla, el rol del usuario y cualquier registro de datos asociado;
• (b) Seguimiento del estado en tiempo real: Un panel unificado dentro del ERP muestra todos los tickets abiertos, en curso y resueltos con visibilidad completa del ciclo de vida, temporizadores de cuenta regresiva del SLA e indicadores de prioridad;
• (c) Comunicación bidireccional: Las conversaciones encadenadas entre el Cliente y el ingeniero de soporte asignado se producen dentro del propio ticket, manteniendo un registro cronológico completo de auditoría;
• (d) Captura de adjuntos y evidencias: Los usuarios adjuntan directamente a los tickets capturas de pantalla, registros de errores, documentos y grabaciones de pantalla, eliminando la pérdida de contexto durante la escalada;
• (e) Métricas e informes de SLA: Seguimiento de SLA integrado con alertas automáticas cuando los objetivos de respuesta o resolución se acercan al umbral, junto con informes en tiempo real sobre volumen de tickets, categorías y desempeño de resolución;
• (f) Integración de base de conocimientos: El sistema de tickets se conecta con la base de conocimientos integrada del Proveedor (wiki), mostrando artículos relevantes y soluciones conocidas durante la creación del ticket para facilitar la resolución por autoservicio;
• (g) Notificaciones automáticas: Se activan notificaciones por correo electrónico y dentro de la aplicación en cada transición de estado del ticket (registrado, reconocido, asignado, actualizado, resuelto, cerrado), manteniendo informadas a todas las partes interesadas.

El sistema de tickets integrado actúa como sistema de registro para todas las interacciones de soporte. Independientemente del canal por el que se notifique inicialmente un problema (teléfono, correo electrónico, WhatsApp o en la aplicación), todos los tickets deberán formalizarse dentro del sistema de tickets integrado para garantizar la medición del SLA, la auditabilidad y el cumplimiento.

4.2.2 Canales de soporte omnicanal

El Proveedor pondrá a disposición del Cliente acceso a la PSD a través de los siguientes canales:

4.2.3 Canal de soporte WhatsApp Business

El Proveedor establece un grupo dedicado de WhatsApp Business para cada Cliente, conectando a los usuarios clave designados del Cliente con los consultores asignados del Proveedor. Este canal opera como una capa de comunicación informal expedita para complementar el sistema formal de tickets. El canal de WhatsApp se rige por las siguientes reglas:

• (a) Alcance: Consultas rápidas, orientación de uso, aclaración de funcionalidades, discusión informal de posibles solicitudes de cambio e informe preliminar de incidencias no críticas. El canal de WhatsApp no sustituye al registro formal de tickets;
• (b) Regla de formalización: Cualquier incidencia comunicada por WhatsApp que requiera seguimiento formal, medición de SLA, cambio de código, modificación de configuración o escalada debe registrarse como ticket en el sistema de tickets integrado por el consultor del Proveedor dentro de las 4 horas siguientes a su identificación. Se notificará al Cliente la referencia del ticket;
• (c) Exclusión de SLA: Los temporizadores de respuesta y resolución del SLA comienzan cuando el ticket se formaliza en el sistema de gestión de tickets integrado, no cuando se produce la comunicación inicial por WhatsApp;
• (d) Protección de Datos: Los participantes no compartirán Datos Personales, credenciales, contenido de bases de datos ni Información Confidencial por WhatsApp. El Proveedor informará a todos los participantes sobre las obligaciones de tratamiento de datos conforme a las Leyes de Protección de Datos aplicables (ref. Sección 17);
• (e) Conservación: Los mensajes de WhatsApp se conservan de conformidad con la política de retención de datos del Proveedor. A efectos de auditabilidad, cualquier discusión técnica sustantiva o decisión adoptada por WhatsApp se resumirá en el registro del ticket correspondiente;
• (f) Pertenencia al grupo: La pertenencia al grupo se gestiona conjuntamente. El Proveedor actualizará la membresía del grupo dentro de los 2 Días Hábiles siguientes a cualquier cambio de personal. El Cliente notificará al Proveedor cualquier cambio en sus usuarios clave designados.

4.2.4 Horario de operación y disponibilidad de la PSD

La PSD opera 24 horas al día, 7 días a la semana, 365 días al año para el registro de tickets en todos los canales. Las actividades de resolución siguen las ventanas operativas definidas en la Matriz de Respuesta y Resolución del SLA (Sección 3.6).

Los días festivos públicos del gobierno de EAU/Grecia/Filipinas se excluyen del cálculo de Días Hábiles, pero los incidentes P1 se atienden independientemente del calendario de festivos públicos.

4.2.5 Responsabilidades de la PSD

La PSD deberá:

• (a) Registrar todos los incidentes y solicitudes de servicio reportados por el Cliente en el sistema de gestión de tickets integrado, asignando un número de referencia único del ticket con captura automática de metadatos contextuales;
• (b) Acordar con el Cliente el nivel de prioridad que se asignará a cada ticket de conformidad con la Clasificación de Prioridad de Incidentes definida en la Sección 3.5;
• (c) Proporcionar al Cliente acuse de recibo del ticket electrónico tras su recepción;
• (d) Gestionar todas las escalaciones necesarias para restablecer los Servicios dentro de los objetivos aplicables del Nivel de Servicio;
• (e) Proporcionar al Cliente actualizaciones periódicas sobre el progreso a través del sistema de tickets, teléfono, correo electrónico o WhatsApp, en intervalos mutuamente acordados;
• (f) Informar al Cliente una vez resuelto el ticket, incluyendo una breve descripción de la causa raíz, la acción correctiva adoptada y si el ticket debe cerrarse o requiere acciones adicionales;
• (g) Cuando sea posible, intentar primero resolver los tickets remotamente. Cuando la resolución remota no sea factible, el Proveedor enviará un ingeniero cualificado a las instalaciones del Cliente según sea necesario;
• (h) Formalizar en el sistema de tickets integrado cualquier incidencia comunicada inicialmente por WhatsApp o teléfono en un plazo de 4 horas;
• (i) Mantener un registro de auditoría completo de todas las interacciones del ticket, cambios de estado y actividades de resolución dentro del sistema de tickets integrado.

4.3 Gestión del ciclo de vida de los tickets

Todas las interacciones de soporte siguen un ciclo de vida de ticket estructurado, gestionado a través del sistema de tickets integrado de la Plataforma para asegurar la trazabilidad, la rendición de cuentas y el cumplimiento de los objetivos del SLA.

El ciclo de vida se aplica a todos los tipos de ticket: Incidentes, Solicitudes de Servicio, Problemas y Solicitudes de Cambio, independientemente del canal por el que se haya reportado inicialmente la incidencia.

4.3.1 Registro de tickets

Cuando el Cliente registre un ticket, deberá proporcionar a la PSD la siguiente información mínima:

• (a) Nombre del Cliente y referencia del contrato ( autocompletado cuando los tickets se registran a través del sistema de tickets integrado);
• (b) Nombre y datos de contacto de la persona que reporta la incidencia;
• (c) Una descripción clara de la incidencia, incluyendo los pasos para reproducirla (para incidencias) o la naturaleza de la solicitud (para solicitudes de servicio);
• (d) El o los módulos afectados y el número de Usuarios Autorizados impactados;
• (e) Cualquier diagnóstico, captura de pantalla o mensaje de error obtenido por el Cliente;
• (f) El nivel de prioridad propuesto por el Cliente para el ticket.

4.3.2 Flujo de procesamiento de tickets

El siguiente procedimiento define el método por el cual se procesa un ticket desde su registro inicial hasta su cierre:

Reapertura de tickets: Si el Cliente informa que la misma incidencia vuelve a producirse dentro de 5 Días Hábiles desde el cierre del ticket, el ticket original se reabrirá con la misma clasificación de prioridad dentro del sistema de tickets integrado. Los tickets reabiertos se contabilizan como un solo incidente a efectos de medición del SLA.

4.3.3 Clasificación de tickets

Los tickets se clasifican en las siguientes categorías:

4.4 Escalamiento técnico

El Proveedor mantiene una matriz de escalamiento técnico estructurada para asegurar que los tickets se escalen al nivel adecuado de experiencia y autoridad de gestión cuando no se logra la resolución dentro de los objetivos de Nivel de Servicio aplicables o cuando la gravedad de la incidencia requiere intervención de niveles superiores.

4.4.1 Niveles de escalamiento

4.4.2 Escalamiento iniciado por el Cliente

El Cliente puede escalar un ticket en cualquier momento contactando con la PSD y solicitando el escalamiento. El Proveedor actualizará la Matriz de contactos para escalamiento al menos una vez al año o ante cualquier cambio de personal, y entregará la matriz vigente al Cliente dentro de los 5 Días Hábiles siguientes a cualquier actualización. La Matriz de contactos para escalamiento incluirá nombre, cargo, números de contacto directos y dirección de correo electrónico para cada nivel de escalamiento.

Para incidentes P1 (Críticos), el Proveedor escalará automáticamente al Nivel 2 en un plazo de 30 minutos si la respuesta inicial no ha identificado una vía de resolución, y al Nivel 3 en un plazo de 2 horas si el incidente sigue sin resolverse. El enlace de TI designado por el Cliente y el Service Delivery Manager serán notificados en tiempo real de todas las escalaciones P1.

4.5 Mantenimiento preventivo

El Proveedor realizará mantenimiento preventivo mensual de todos los componentes de la Plataforma dentro del entorno soberano privado dedicado del Cliente. El mantenimiento preventivo se lleva a cabo de manera proactiva para identificar y subsanar posibles incidencias antes de que afecten la disponibilidad o el rendimiento del servicio.

4.5.1 Alcance del mantenimiento preventivo

El mantenimiento preventivo mensual incluirá, entre otros:

• (a) Comprobaciones del estado de la infraestructura: Supervisión del rendimiento de las máquinas virtuales, utilización del disco, asignación de memoria, análisis de carga de CPU y evaluación de la latencia de red;
• (b) Mantenimiento de bases de datos: Reconstrucción de índices, actualización de estadísticas, gestión del registro de transacciones, comprobaciones de integridad (DBCC CHECKDB) y optimización del almacenamiento;
• (c) Aplicación de parches de seguridad: Revisión y aplicación de parches de seguridad del sistema operativo, middleware y base de datos de conformidad con la política de gestión de parches del Proveedor (véase la Sección 3.1.3 para las ventanas de mantenimiento);
• (d) Verificación de copias de seguridad: Validación de la finalización de los trabajos de copia de seguridad, pruebas de integridad de las copias de seguridad y ejecución de simulacros de restauración (trimestral);
• (e) Estado de la aplicación: Comprobaciones funcionales a nivel de módulo, validación de extremos de API, supervisión de integraciones y revisión de registros de errores en todos los módulos activos de ProjectVIEW ERP;
• (f) Gestión de certificados SSL/TLS: Supervisión del vencimiento de certificados, renovación y rotación;
• (g) Revisión de capacidad: Evaluación de la utilización actual de recursos frente a la capacidad provisionada, con recomendaciones proactivas de escalado cuando la utilización supere el umbral del 75%.

4.5.2 Informe de mantenimiento preventivo

Tras completar cada ciclo de mantenimiento preventivo, el ingeniero de mantenimiento del Proveedor presentará al Cliente un Informe de Mantenimiento Preventivo dentro de 3 Días Hábiles. El informe incluirá:

• Fecha y duración de la actividad de mantenimiento;
  • Componentes inspeccionados y acciones realizadas;
  • Riesgos o anomalías identificados con la remediación recomendada;
  • Métricas de utilización de recursos actuales frente a los recursos provisionados;
  • Próximo calendario de parches y actualizaciones;
  • Confirmación de los resultados de verificación de copias de seguridad.

4.6 Gestión de cambios

Todas las modificaciones de la configuración, funcionalidad o infraestructura de la Plataforma se rigen por un proceso formal de Gestión de Cambios diseñado para minimizar el riesgo para el Entorno de Producción. Los cambios se clasifican y gestionan de acuerdo con las mejores prácticas de Gestión de Cambios de ITIL.

4.6.1 Clasificación de cambios

4.6.2 Flujo de trabajo de gestión de cambios

Todos los cambios normales y de emergencia siguen este flujo:

• (a) Solicitud: El Cliente o el Proveedor presenta una Solicitud de Cambio a través del PSD con la descripción, la justificación comercial, los módulos afectados y la fecha de implementación solicitada;
• (b) Evaluación: El Proveedor realiza una evaluación de impacto que abarca: riesgo técnico, usuarios afectados, plan de reversión, esfuerzo estimado y dependencias;
• (c) Aprobación: El Change Advisory Board (o el Service Delivery Manager para los cambios de emergencia) revisa y aprueba o rechaza el cambio;
• (d) Implementación: El cambio se desarrolla y despliega en el Entorno de Staging;
• (e) UAT: El Cliente realiza Universal User Acceptance Testing en el Entorno de Staging. Se concede un mínimo de 5 Días Hábiles para la UAT. Se requiere aprobación por escrito (ref. Sección 3.2.1);
• (f) Despliegue: Tras la aprobación de la UAT por parte del Cliente, el cambio se despliega en Producción durante una ventana de mantenimiento acordada;
• (g) Revisión Posterior a la Implementación: El Proveedor supervisa el cambio durante 5 Días Hábiles después del despliegue y proporciona al Cliente un informe de cierre.

Reversión: Todo cambio Normal y de Emergencia deberá incluir un plan de reversión documentado. Si el cambio provoca una degradación del servicio no planificada, el Proveedor ejecutará la reversión en un plazo de 2 horas desde la identificación del problema y notificará inmediatamente al Cliente.

4.6.3 Auditabilidad de los Cambios

Todos los cambios en la configuración, la base de código y la infraestructura de la Plataforma se registran en el Change Management System del Proveedor. Cada registro de cambio incluye: solicitante, descripción, evaluación de riesgos, cadena de aprobación, fecha de implementación, ingeniero que lo implementó, resultados de pruebas y estado posterior a la implementación. Los registros de cambios están disponibles para el Cliente previa solicitud y se incluyen en la Quarterly Service Review (ref. Sección 3.9.2).

4.7 Gestión de lanzamientos de software

El Proveedor gestiona todas las entregas de software mediante un proceso controlado de gestión de versiones que distingue entre dos tipos de entrega fundamentalmente diferentes: Releases/Updates (incrementales, específicas del cliente, frecuentes) y Upgrades (versión principal, para todo el producto, anual). Esta distinción garantiza que la entrega ágil diaria para el Cliente no entre en conflicto con la hoja de ruta de producto más amplia del Proveedor.

4.7.1 Releases y Updates (Incrementales – p. ej., v11.xx)

Los releases y updates son entregas incrementales dentro de la versión principal vigente de la Plataforma (p. ej., v11.01, v11.02, v11.15). Abordan solicitudes de cambio, correcciones de errores, ajustes de configuración y mejoras funcionales menores específicas de la implementación del Cliente. Los releases se entregan mediante una metodología de ejecución Agile adaptada al ritmo operativo del Cliente.

Metodología Agile por Sprints: El Proveedor opera en sprints de ciclo corto con una media de 3 Días Hábiles por sprint. Cada sprint entrega un conjunto definido de solicitudes de cambio, correcciones de errores o cambios de configuración acordados con el Cliente en la planificación del sprint. El ciclo del sprint es el siguiente:

Control de Versiones del Release: Cada release incremental recibe un número de versión semántico dentro de la versión principal vigente (p. ej., v11.01, v11.02… v11.xx). El número de versión aumenta secuencialmente con cada entrega de sprint. El Proveedor mantiene un registro de releases accesible para el Cliente a través de la Plataforma.

4.7.2 Upgrades (Versión Principal – p. ej., v11 → v12)

Los upgrades representan una nueva versión principal de la Plataforma (p. ej., v11 → v12, v12 → v13). Los upgrades son releases para todo el producto que abarcan mejoras funcionales significativas, nuevos módulos, rediseños de UI/UX, nuevas APIs/SDKs, mejoras arquitectónicas y grandes actualizaciones de versiones COTS (p. ej., .NET framework, motor SQL Server). Los upgrades se publican aproximadamente una vez al año y representan un nuevo número de versión de software.

Los upgrades principales suelen incluir:

• Nuevas Mejoras Funcionales: Incorporación de funcionalidades, nuevas capacidades de módulos y mejoras de flujos de trabajo impulsadas por la hoja de ruta de producto del Proveedor y por los comentarios del Customer Advisory Board;
• Mejoras de UI/UX: Rediseños de interfaz, mejoras de usabilidad, mejoras de accesibilidad y actualizaciones de diseño responsive;
• Extensiones de API y SDK: Nuevos puntos de integración, capacidades mejoradas de Web API y kits de desarrollo de software actualizados;
• Upgrades de la Plataforma COTS: Migración a nuevas versiones de las tecnologías subyacentes (.NET, SQL Server, IIS) como parte del compromiso del Proveedor con la vigencia tecnológica;
• Mejoras de Seguridad: Implementación de nuevos estándares de seguridad, mejoras de cifrado y cumplimiento de requisitos normativos emergentes.

4.7.3 Proceso integrado de gestión de lanzamientos y despliegue

Todos los releases (incrementales) y upgrades (versión principal) se gestionan a través del Platform Release Centre, que actúa como plataforma central de gestión y distribución de releases. La Plataforma ofrece las siguientes capacidades:

• (h) Catálogo de Releases: Un catálogo completo de todos los releases disponibles para cada Cliente, organizado por aplicación y versión. Cada entrada de release incluye la fecha de publicación, el número de versión y notas de release detalladas que describen nuevas funcionalidades, correcciones y problemas conocidos;
• (i) Acceso Basado en Credenciales: El acceso a la Plataforma está protegido mediante credenciales únicas asignadas a los administradores designados del Cliente. Los permisos de acceso determinan la visibilidad de los releases aplicables a los módulos licenciados del Cliente;
• (j) Notas de la versión y registros de cambios: Cada lanzamiento va acompañado de comentarios semánticos y contextuales que describen las funciones, funcionalidades y correcciones de errores más recientes, revisados y aprobados por el Revisor del Proveedor antes de su publicación;
• (k) Disponibilidad bajo demanda: Los lanzamientos están disponibles para descarga bajo demanda, sujetos a la aceptación del administrador del Cliente. El Proveedor notifica al Cliente cuando hay disponible un nuevo lanzamiento;
• (l) Trazabilidad de auditoría: La Plataforma mantiene un registro completo de qué lanzamientos se han puesto a disposición, descargado e implantado para cada entorno del Cliente. Modelo de despliegue SaaS: En el modelo de entrega SaaS, el Proveedor gestiona todos los despliegues en el entorno soberano dedicado del Cliente. El Cliente no instala los lanzamientos por su cuenta. El proceso de despliegue es el siguiente:

4.7.4 Fin de Vida y Transición de Versión

La política de Fin de Vida (EOL) del Proveedor, el ciclo de vida de transición de versión, los servicios de migración, el programa de reentrenamiento, los procedimientos de devolución de datos y los procesos de cese de suscripción se definen de forma integral en Chapter 10 — End-of-Life, Version Transition & Subscription Cessation. Chapter 10 rige todos los aspectos de la gestión del ciclo de vida de versiones desde General Availability (GA) hasta EOL Announcement, End of Engineering (EOE), End of Life y el soporte extendido opcional.

A efectos de este Chapter, se aplica el siguiente resumen: el Proveedor deberá dar al Cliente un mínimo de doce (12) meses de aviso por escrito antes de que una versión principal llegue a End of Life. La asistencia para la actualización, incluida la planificación de la migración, la migración de datos, la adopción de integraciones, el reentrenamiento y el soporte de UAT, está incluida en el Subscription Term sin coste adicional. Los términos, plazos y procedimientos completos se establecen en las Secciones 10.1 a 10.14.

4.7.5 Control de Versiones y Escrow del Código Fuente

El Proveedor mantiene todo el código fuente en un sistema de control de versiones basado en Git que incorpora:

• Rama Principal: La aplicación estándar de DANAOS ("Vanilla Version") que representa la versión actualmente disponible de forma general;
• Ramas de Cliente: Configuraciones y personalizaciones específicas del Cliente mantenidas como ramas dedicadas. Los releases de sprint se desarrollan en la rama de cliente;
• Clones de Trabajo: Copias de trabajo del desarrollador que se fusionan en condiciones estables para incorporar nuevas funcionalidades en las ramas Master y Client. Todos los cambios de código están sujetos a revisión entre pares mediante Pull Requests, pruebas automatizadas y cumplimiento de las Programming Guidelines del Proveedor que abarcan la calidad del código, la lógica de negocio y las mejores prácticas de seguridad. Tras ejecutar Commit y Push, y después de cualquier revisión de Pull Request, las versiones de la aplicación son plenamente justificadas por el programador responsable (o el Agile Team) con comentarios semánticos y contextuales. Los revisores aceptan o rechazan los cambios según las Programming Guidelines del Proveedor. La lógica de negocio también es verificada por DANAOS Support Engineers, que son expertos en la materia dentro de su ámbito.

El Proveedor aplica Integración Continua / Entrega Continua (CI/CD) para el despliegue de software cuando procede. La canalización CI/CD automatiza las etapas de compilación, prueba y despliegue desde el repositorio Git hasta el Entorno de Staging, garantizando la coherencia y reduciendo errores de despliegue manuales.

El Proveedor deberá mantener un acuerdo de Source Code Escrow con un agente de escrow independiente de terceros. Los términos completos que rigen el contenido del depósito en escrow, la frecuencia de actualización, la verificación anual, las condiciones de liberación y los derechos del Cliente tras la liberación se definen en Sección 9.14 (Source Code Escrow). Los costes del acuerdo de escrow, incluidos los honorarios del Escrow Agent, serán asumidos por el Cliente (véase § 9.14.4).

4.8 Servicios IMAC/RD

El Proveedor presta servicios de Install, Move, Add, Change, Remove, and Dispose (IMAC/RD) para la Plataforma como parte del soporte operativo continuo. Las actividades IMAC/RD se gestionan como cambios Standard o Normal (ref. Sección 4.6.1) y están sujetas al siguiente alcance:

Las actividades IMAC/RD que queden fuera del alcance del Subscription Term se cotizarán por separado sobre una base de por manday, acordada por escrito entre las partes antes del inicio de los trabajos.

4.9 Orientación sobre arquitectura empresarial

El Proveedor asesorará al Cliente en cuestiones de arquitectura empresarial relacionadas con la Plataforma, incluida la integración de sistemas, el diseño del flujo de datos y la alineación tecnológica. Esto incluye:

• (a) Arquitectura de integración: Orientación para conectar ProjectVIEW ERP con los sistemas empresariales existentes del Cliente (por ejemplo, SAP, Oracle, plataformas bancarias, sistemas de RR. HH.) a través de la API web nativa de la Plataforma (ref. Sección 2.5);
• (b) Arquitectura de datos: Asesoramiento sobre el flujo de datos, la planificación de la migración de datos, la gestión de datos maestros y la arquitectura de informes dentro del entorno soberano dedicado del Cliente;
• (c) Arquitectura de seguridad: Orientación sobre seguridad de red, políticas de control de acceso, estándares de cifrado y alineación con el marco de seguridad detallado en la Parte B de este Marco;
• (d) Planificación de la escalabilidad: Recomendaciones proactivas para el escalado del entorno en función de las proyecciones de crecimiento de usuarios, las tendencias de volumen de datos y los planes de activación de módulos. La orientación sobre arquitectura empresarial se proporciona como un servicio de asesoramiento y no se extiende al diseño, desarrollo o soporte de sistemas de terceros. La implementación de las recomendaciones de arquitectura está sujeta a un alcance y una cotización independientes, tal como acuerden las partes.

4.10 Mejora continua del servicio (CSI)

El Proveedor opera un programa de Mejora Continua del Servicio (CSI) alineado con las prácticas ITIL 4 y las metodologías contemporáneas de AIOps para impulsar mejoras continuas en la calidad del servicio, la eficiencia operativa y la satisfacción del Cliente. El programa CSI incluye:

• Análisis de Tendencias Asistido por IA: Análisis mensual de volúmenes de incidencias, categorías, problemas recurrentes y tiempos de resolución mediante reconocimiento de patrones y detección de anomalías para identificar de forma proactiva mejoras sistémicas;
• Eliminación de la Causa Raíz: Actividades de Problem Management orientadas a eliminar incidencias recurrentes mediante soluciones permanentes, basadas en análisis de correlación entre tickets;
• Optimización de Procesos: Revisión periódica de los procesos de soporte, los flujos de tickets, los procedimientos de escalado y la eficacia del soporte omnicanal para reducir los tiempos de resolución y mejorar la experiencia del Cliente;
• Gestión de Feedback y Experiencia del Cliente: Incorporación de los resultados de las encuestas de satisfacción del Cliente, el feedback de la Quarterly Service Review y las métricas de eficacia del canal de WhatsApp al registro de CSI;
• Actualización Tecnológica: Identificación proactiva de actualizaciones COTS, mejoras de seguridad y optimizaciones de la plataforma que beneficien al Cliente;
• Gestión del Conocimiento: Enriquecimiento continuo de la base de conocimientos integrada con soluciones de tickets resueltos, lo que permite mayores tasas de resolución en autoservicio y reduce el volumen de incidencias repetidas. El registro de CSI es mantenido por el Service Delivery Manager y revisado en cada Quarterly Service Review (ref. Sección 3.9.2). Todas las iniciativas de CSI se realizan un seguimiento desde su identificación hasta su implementación con resultados medibles. Cuando el Proveedor adopta herramientas asistidas por IA en las operaciones de soporte, su uso deberá cumplir con los marcos de gobernanza aplicables, incluido el EU AI Act y el NIST AI Risk Management Framework (AI RMF 1.0).

URL de referencia:

ITIL 4 Foundation – PeopleCert / Axelos ProjectVIEW ERP Ticketing System – DANAOS Projects WhatsApp Business Platform – Meta Azure Service Health – Microsoft NIST SP 800-88 Media Sanitization Guidelines NIST AI Risk Management Framework (AI RMF 1.0) EU AI Act – European Commission

4.11 Registro de procesos

La siguiente tabla resume los procesos de soporte del servicio y operativos establecidos en este Chapter, incluidos los roles responsables, los resultados esperados y las referencias cruzadas con procesos relacionados en otros Chapters.

Leyenda de roles: P = Proveedor | C = Cliente | PSD = Mesa de servicio del Proveedor | SDM = Gerente de entrega del servicio | CAB = Cambio

Advisory Board | SC = Steering Committee

4.11.1 Registro de Procesos

4.11.2 Matriz RACI

R = Responsable (ejecuta) | A = Accountable/Responsable último (aprobación final) | C = Consultado | I = Informado | — = No participa

4.11.3 Flujo del proceso — Ciclo de vida de soporte y operaciones