Condiciones delServicio SLA.
(Service Level Agreement)
// 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®.
02.1El 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.
02.2Provisió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.
02.3La 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.
02.4El 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.
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:
04.1Los 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.
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.
04.2NIVEL DE ESCALAMIENTO
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.
04.3MEJORAS FUNCIONALES
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.
04.4CAMBIOS LEGALES
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.
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.
06.1GENERACIÓN DE TICKETS
Deben ser ingresados desde nuestro portal tickets.sistemaisis.com
06.1.1La información solicitada es necesaria para que nuestro asesor de soporte pueda detectar rápidamente su inconveniente. Si se omite parte de la misma, puede derivar en demoras adicionales.
06.1.2Cuando se adjunta una imagen con un cartel de error, el mismo debe ser enviado en su contexto, evitando el recorte parcial de la imagen que no permita identificar mayores datos del sistema.
06.1.3Las solicitudes de modificaciones de reportes/formularios deben tener especificado el reporte/formulario en cuestión y el detalle de las modificaciones expresamente detalladas, independientemente de si se envía algún ejemplo.
06.1.4Debe mantenerse actualizada la información de contacto en nuestro portal para que nuestros asesores puedan comunicarse con el cliente sin inconvenientes.
06.2CONDICIONES DE LOS TICKETS
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.
06.2.1Las consultas que la mesa de ayuda puede resolver son de carácter operativo y puntuales. En el caso que las mismas refieran a operatorias que no se hayan implementado o se desconozca su funcionalidad, serán derivadas al área correspondiente.
06.2.2El sistema enviará un mensaje por WhatsApp al teléfono del usuario registrado en nuestra web de tickets cuando la consulta sea asignada y otro cuando esté respondida.
06.2.3El acceso remoto a la terminal del cliente será solicitado por el operador de mesa de ayuda si lo considera necesario para visualizar/analizar el inconveniente. Será tarea del cliente realizar cualquier paso indicado por el operador para solucionarlo. Dicha conexión se llevará a cabo exclusivamente con previo consentimiento.
06.2.4El personal debe ser tratado con el mismo respeto con el que tratamos a los clientes. No se atenderán llamados telefónicos o tickets que contengan agravios al operador, el servicio o el sistema; directamente serán rechazados.
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.
El cliente en caso de querer suspender o cancelar el servicio debe informarlo de modo fehaciente a QSA con al menos 30 días.
QSA tomará nota del pedido y dará de baja el servicio siempre que el cliente esté al día con los pagos.
En estos casos regirá la política de backups incluida en el Anexo II al presente.
QSA informará al cliente los cortes en el servicio programados por mantenimiento y actualización.
Sin embargo, en aquellos casos de fuerza mayor o caso fortuito —ajenos a QSA— no será responsable del no servicio por ser ajeno a su control y no haber podido proveerlos. Por supuesto que hará sus máximos esfuerzos para que el servicio se reestablezca a la brevedad.
El Servicio de mesa de ayuda tiene las características y el formato descripto en el principal de este contrato.
El cliente deberá:
El cliente es consciente que ningún sistema de información es completamente seguro, que personas dentro o fuera de la organización pueden encontrar formas de tener acceso a la información considerada confidencial, vital o estratégica.
El cliente se obliga a contribuir al cuidado y conservación de las instalaciones y sistemas.
El cliente tiene en especial consideración que la utilización de los diferentes sistemas de información de QSA es de uso exclusivo para fines laborales.
El uso personal de cualquier sistema de información para acceder, descargar, transmitir, distribuir o almacenar material obsceno está absolutamente prohibido. El uso de los recursos informáticos (sistemas de información y equipos) que tengan como objetivo cualquier tipo de ganancia económica personal para cualquier cliente está prohibido sin excepción alguna.
Bajo ninguna circunstancia el uso personal de estos sistemas por parte de los clientes debe influir de manera negativa en el desempeño de las tareas y responsabilidades para la organización.
El cliente le asegura a QSA que no utilizará Internet para propósitos que puedan influir negativamente en la imagen de QSA o de sus directivos, y en caso de hacerlo será responsable de esas circunstancias.
El cliente sabe que el acceso no autorizado a los sistemas de información de QSA está terminantemente prohibido.
De este modo el cliente debe usar la identificación, identidad, firma electrónica, firma digital o contraseña propia sin poder remitirla o permitir que la use otro usuario o cliente.
Así las cosas el cliente asume el compromiso de no informar a terceros su contraseña o identificación, a excepción en casos que deban facilitarse para la reparación o mantenimiento de algún sistema o equipo. En este caso y en forma estrictamente circunstancial, solo deberá hacerlo al personal técnico o informático autorizado, debidamente identificado.
Es obligación de los clientes respetar la siguiente política de contraseñas:
El cliente se compromete a no hacer uso del sistema con alguna de las siguientes finalidades:
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.
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.
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.
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.
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:
| 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 orientada 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 por un desastre 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) |
| Concepto | Restauración Instancia | Restauración Schema (1 sola BD) |
|---|---|---|
| RTO | 2 horas Aprox. | 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.
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.
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.
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.