// Anexo servicio de Mantenimiento, Actualización y Soporte del Sistema (SLA)
Tener activo el SLA tiene como objetivo **establecer los parámetros de operación** relacionados con el Soporte Técnico, Atención de Peticiones, Quejas y Reclamos que, como empresa proveedora de servicios, estamos en capacidad de ofrecer. Así también mantener el funcionamiento de todas las opciones incluidas en la versión de su Sistema Isis®.
El soporte por **mesa de ayuda** es brindado por medio de Ticket Web, vía telefónica o control remoto, según lo indique el nivel de servicio contratado. Siempre una consulta o solicitud de servicio debe iniciarse a través de un ticket. El mismo hace referencia a cualquier consulta sobre el uso puntual de los componentes del sistema implementado, incidentes, problemas en la operación y modificaciones por requerimientos impositivos en los formularios de Remitos, Facturas (A, B, C, E y M) y Recibos de haberes. Todo lo que se encuentre excluido de lo anteriormente mencionado, será analizado y de ser posible la modificación, se enviará el presupuesto correspondiente.
El servicio **NO incluye** la atención de incidencias sobre aplicativos que no hayan sido desarrollados por QSA, así como tampoco la cobertura de problemas referentes a la red del cliente, funcionamiento de sus sistemas externos, instalaciones, ni horas de capacitación.
Provisión de todas las nuevas versiones que QSA desarrolle de su Sistema ISIS®, más las actualizaciones que se generen, sean estas legales, impositivas, contables o **mejoras que se incorporen**.
La disponibilidad de **nuevas versiones y upgrades son informadas por notificación en el sistema**. Este procedimiento es de exclusiva responsabilidad del usuario o el responsable de sistemas del cliente. Si el cliente solicita una instalación personalizada que no está incluida en el SLA, se cotizará por hora de servicio al valor vigente en nuestra lista de precios y estará sujeta a la disponibilidad del personal técnico de QSA.
El **llamado telefónico y acceso remoto** a la terminal del cliente será solicitado por el operador de mesa de ayuda si lo considera necesario para poder visualizar/analizar el inconveniente, siendo tarea del cliente realizar cualquier paso indicado por el operador para solucionarlo.
**Nota importante 1:** El presente SLA solo cubre actividades de soporte una vez que el (los) servicio(s) contratados entran en etapa de producción, lo que se aplica a partir del informe del área de Implementaciones indicando que el cliente cumplió con los requisitos de prácticas correspondiente durante la implementación.
El servicio se prestará los días hábiles de **lunes a viernes de 09:00 a 18:00 horas**.
El usuario podrá ingresar tickets de consulta fuera de este horario desde el portal tickets.sistemaisis.com, aunque los mismos serán analizados y asignados por orden de ingreso en el primer día hábil siguiente, cuando el personal de mesa de ayuda **se reintegre a sus tareas**.
El SLA establece y documenta el nivel de servicio a brindar por QSA para la atención de requerimientos del Cliente en cuanto al exclusivo funcionamiento del sistema.
Los requerimientos se tipifican como se indica a continuación:
Los requerimientos tipificados como Errores o Incidentes del Sistema se clasifican en los siguientes niveles **según su criticidad**:
Significa que la funcionalidad del Sistema o procesos críticos no están operando correctamente debido a un error o parada no programada del Sistema y no hay una solución inmediata disponible, impidiendo al cliente realizar las tareas que impliquen la necesidad de utilizar el sistema.
Tiempo de reacción: 1 hora a partir del momento en que se recibe el reclamo.
Tiempo de respuesta: Se le dará tratamiento con alta prioridad **dentro de las 24 horas hábiles** a partir del momento en que se asigna el ticket a un operador.
Significa que la funcionalidad del sistema o procesos no críticos presentan inconvenientes, pudiendo continuar en forma restringida y solo está disponible una solución temporal.
Tiempo de reacción: 2 horas a partir del momento en que se recibe el reclamo.
Tiempo de respuesta: Se le dará tratamiento **dentro de las 48 horas hábiles** a partir del momento en que se asigna el ticket a un operador.
Significa que la funcionalidad del sistema o procesos no críticos presentan inconvenientes menores, permitiendo al usuario continuar utilizando el sistema de forma habitual. Se incluyen aquí preguntas generales de uso y requerimientos de customización.
Tiempo de reacción: 4 horas a partir del momento en que se recibe el reclamo.
Tiempo de respuesta: se le dará tratamiento **dentro de los 7 días hábiles** a partir del momento en que se asigna el ticket a un operador.
Importante.
QSA puede **recategorizar la criticidad** de un ticket si el cliente no describe claramente el problema o no adjunta la documentación correspondiente. En caso de contar con disponibilidad, el ticket puede resolverse en plazos menores, sin importar la criticidad asignada.
QSA **solo brinda soporte** sobre problemas o consultas relacionadas con el software provisto. No se incluyen problemas de equipamiento, redes, sistemas operativos o internet.
Los tiempos de **reacción y respuesta** se contemplan dentro del horario de atención de la mesa de ayuda.
En caso que el error o incidente **no pueda ser resuelto** por el operador de mesa de ayuda, el requerimiento será escalado al jefe del sector; si no puede ser resuelto por éste, se escalará al gerente de servicios o producto, dentro de los plazos especificados en el nivel de criticidad.
Se solicitarán en forma fehaciente a QSA quien evaluará el pedido, pudiéndose solicitar una reunión de relevamiento para analizar los mismos. Ante solicitudes de cambios legales particulares o específicos a su actividad, la documentación y reglamentaciones de los mismos deberán **ser suministrados por el Cliente**.
Una vez analizada la solicitud, QSA elevará un informe al cliente con el resultado del análisis de factibilidad.
Todos los desarrollos adicionales para personalizar el sistema, se cotizarán por separado ya que no se encuentran cubiertos por el presente SLA, y tienen impacto en el costo del SLA, debido a que requieren de actualizaciones al igual que el sistema estándar.
Es responsabilidad de QSA, mantener actualizados los sistemas por cambios legales y/o impositivos que afecten la operatoria de los sistemas, de tal manera que el Cliente reciba en tiempo y forma las actualizaciones.
En algunos casos donde los cambios legales y/o impositivos no sean claros en la reglamentación, pueden ocasionar demoras hasta que los consultores internos y externos dictaminen el procedimiento a aplicar y así poder realizar el cambio apropiadamente en los sistemas, y que los mismos estén funcionando correctamente.
Las versiones del sistema ISIS® no actualizadas, pueden no ser compatibles con la legislación contable e impositiva vigente.
Todas las horas adicionales que requiera el Cliente en concepto de capacitación, implementación y asistencia personalizada, se cotizarán por separado ya que no se encuentran cubiertas por el presente SLA. El **valor de la hora será el vigente a la fecha de cotización**.
(CLIENTE CON SERVICIO DE MANTENIMIENTO CONTRATADO)
Las consultas a la mesa de ayuda deben ser iniciadas por medio de un ticket ingresado a nuestro portal **tickets.sistemaisis.com**, completando toda la información requerida.
El SLA no contempla la solución de problemas si el usuario no realizó las capacitaciones correspondientes. En ese caso, nuestro operador de mesa de ayuda derivará la consulta al área correspondiente, dando por cerrado el ticket.
Deben ser ingresados desde nuestro portal **tickets.sistemaisis.com**
Por cada tema o consulta debe subirse un ticket reportándolo con todas las especificaciones descritas en el punto 6.1. No se aceptarán tickets con más de una consulta.
(CLIENTE NO ABONADO A MANTENIMIENTO)
QSA solo ofrece **soporte y actualizaciones rentados**, para lo cual pone a disposición del cliente opciones de convenios de mantenimiento que cubren distintos alcances, el cliente que no tiene un convenio de SLA activo, no está habilitado para acceder a la mesa de ayuda, ni a recibir actualizaciones de ningún tipo, el sistema no procesará consultas de clientes que no tengan una opción de SLA activa.
Objetivo.
La información almacenada y procesada es uno de los **activos más importantes de la empresa**, todos los dispositivos o equipos informáticos que albergan esta información pueden verse involucrada en situaciones como robos, virus, borrados accidentales o catástrofes naturales, es por eso por lo que es importante contar con medidas que permitan garantizar o maximizar la disponibilidad de esta con el objetivo de poder acceder a este siempre que se necesite.
Alcance.
Esta política aplica activos, bienes o servicios que **la empresa defina como críticos o clave** en su continuidad operativa, esto sea información contenida en servidores, estaciones de trabajo o correos que contenga datos, configuraciones, aplicaciones, bases de datos y servicios críticos por StarkCloud.
Esto será aplicable a todos los usuarios tanto internos como externos que utilicen recursos de la empresa inclusive empresas que presten servicios a StarkCloud.
Definiciones.
Roles y responsabilidades.
Directrices Generales.
Política.
Toda la **información de los sistemas informáticos críticos** en producción de StarkCloud o QSA deben ser protegidos de posibles fallos por lo que debe ser respaldada con cierta frecuencia, que permita asegurar un adecuado proceso de recuperación, estableciendo para ellos pruebas de manera regular.
El Departamento de Tecnologías o Plataforma, debe **considerar soluciones de respaldo** para servidores, BBDD y aplicaciones (códigos fuentes, bases de datos, archivos de configuración) que se consideren críticos para la empresa así como también garantizar la disponibilidad de infraestructura adecuada de respaldo, con servidores dedicados albergados de manera local o remota a la plataforma productiva, esto con el objetivo de asegurar que estos estén disponibles incluso después de un desastre o la falla de un equipo.
Identificación de activos críticos.
Los responsables de las distintas áreas / Plataforma de StarkCloud serán los encargados de **identificar y mantener un registro actualizado** de todos los activos que son relevantes mantener y resguardar debido a que son claves para mantener operativo sus procesos y serían necesarios restaurar en caso de eventuales problemas.
Plan de respaldo.
El equipo de plataforma define los **tipos de respaldos a aplicar** según el tipo de activo a resguardar o servicios específicos contratados por el cliente, cada estándar especifica:
Tabla resumen Frecuencia y Modalidad de Respaldos.
| Servidor | Frecuencia | Tipo Respaldo | Retención |
|---|---|---|---|
| SQL | Diaria 23:00 PM | Máquina Virtual (Incremental) | 7 días |
| Aplicaciones | Diaria 23:00 PM | Máquina Virtual (Incremental) | 7 días |
Respaldo (CBR) almacenado en contenedores Cloud ubicados en Datacenter Huawei Chile AZI.
Revisión diaria gestionada por personal específico de Plataforma StarkCloud.
Existe una **modalidad adicional de respaldo** orientado a resguardar las bases de datos específicas de los clientes, esta modalidad las lleva a una ubicación remota, esto con el objetivo de que en caso de que la plataforma base (Datacenter) se vea afectada y se pierda el acceso a estas.
| Objeto | Frecuencia | Tipo Respaldo |
|---|---|---|
| Logs | Diaria | Respaldo Ubicación Remota (Azure) |
| Bases-sql | Diaria | Respaldo Ubicación Remota (Azure) |
| Datos de Clientes | Diaria | Respaldo Ubicación Remota (Azure) |
RPO / RTO
| Concepto | Restauración Instancia 2 | Restauración Schema (1 sola) |
|---|---|---|
| RTO | horas Aprox. | BD) 1 hora Aprox. |
| RPO | 24 horas Aprox. | 24 horas Aprox. |
*Los **Tiempos de restauración** de Instancia y Schema son estimados debido a que el tiempo de restauración o recuperación de una base de datos o Schema varía según el tamaño y crecimiento que esta va teniendo.
*Hay que considerar que una **restauración por logs** de transacciones solo será efectiva en el día en curso y se asocia a la instancia completa, afectando a todas las bases alojadas en el servidor.
Tiempos de respuesta.
**RTO (Recovery Time Objective):** El RTO es la **cantidad máxima de tiempo** que debe tomar restaurar la funcionalidad de la aplicación y/o servidor en caso de una pérdida repentina del servicio.
Normalmente se mide este intervalo en segundos, minutos, horas o días. Idealmente se desea un RTO en el extremo más corto del espectro: 60 minutos es un sólido punto de referencia.
La respuesta dependerá de la criticidad de cada aplicación.
Evaluación y Difusión.
La configuración y ejecución de respaldos se debe **monitorear y evaluar constantemente** a través de controles de ejecución diario-semanal.
Pruebas semestrales o anuales de recuperación deben ser solicitadas y coordinadas por el cliente y pueden requerir evaluación comercial según el tipo de recuperación a realizar.
Validación configuración / Ejecución de respaldos.
La política actual debe **ser evaluada por el personal de StarkCloud** al menos una vez al año o cuando las circunstancias lo requieran con el fin de asegurar la eficiencia y efectividad de la política.
Para descargar el documento original en formato PDF, haz clic aquí: Descargar Condiciones del Servicio SLA (PDF)