instructivo de sisnet - logon del usuario.pdf · orden de trabajo – el requerimiento está...

Índice Introducción ............................................................................................................................................. 2 Ingreso a la aplicación .............................................................................................................................. 2 Menú de usuario ....................................................................................................................................... 3

Registrar un requerimiento Nuevo ........................................................................................................... 4 Elementos ............................................................................................................................................. 5 Recomendaciones ................................................................................................................................. 6

Nivel de servicio (SLA) ........................................................................................................................... 6 SLA 1 o “A - Atención en 24 Hs” – Criticidad de alta prioridad ........................................................ 7 SLA 2 o “B – Atención en 48 Hs” – Criticidad media ........................................................................ 7 SLA 3 o “C – Según agenda” – Criticidad media baja ........................................................................ 7 SLA 4, Orden de trabajo, Informe técnico – Criticidad baja ............................................................... 7

Listado de requerimientos propios ........................................................................................................... 8 Abrir un ID específico .............................................................................................................................. 9 Ver requerimientos de mis compañías ..................................................................................................... 9

Reportes / Exportar a Excel .................................................................................................................... 11 Editar Usuario ........................................................................................................................................ 13 Estados ................................................................................................................................................... 14

Introducción ....................................................................................................................................... 14

Autoría de estados .............................................................................................................................. 14 Roles ................................................................................................................................................... 15 Diagrama de transición de estados ..................................................................................................... 15

Matriz de transición de estados .......................................................................................................... 17 Detalle de estados ............................................................................................................................... 18

Anexo I – Métricas ................................................................................................................................. 22 Introducción ....................................................................................................................................... 22 Indicadores definidos ......................................................................................................................... 22

Definición de indicadores ................................................................................................................... 23

Anexo II – Recomendaciones para gestionar SisNet ............................................................................. 27 Introducción ....................................................................................................................................... 27

Tareas pendientes ............................................................................................................................... 28 Roles – Cliente ................................................................................................................................... 28

Seguimiento ........................................................................................................................................ 28 Planificación ....................................................................................................................................... 29 Ejecución del plan .............................................................................................................................. 29

Introducción El sistema de requerimiento es una herramienta que permite mejorar el contacto con los clientes y la vez, mejorar el servicio brindado contribuyendo a mejorar la calidad. El principal elemento que se administra mediante este aplicativo es el requerimiento. Los requerimientos evolucionan a través de un ciclo de vida basado en estados, cuya historia se registra completamente. Cada vez que acontece una novedad en un requerimiento, se envía mail a los involucrados en el mismo (Cliente y Sistran), informando la evolución del mismo. La aplicación consta con reportes y exportación a Excel, para brindar elementos de utilidad para facilitar el seguimiento de las tareas soportadas por los requerimientos.

Ingreso a la aplicación Cada vez que una persona ingresa al sistema de requerimientos necesitará entrar con su Nombre de Usuario y Contraseña. Este nombre de usuario y contraseña es asignado por la persona de Sistran Consultores S.A. asignada a la mesa de ayuda.

Si no recuerda la contraseña puede ingresar a Enviarme mi contraseña e ingresando el Nombre de Usuario el sistema le envía un mail a la dirección registrada en el perfil del usuario cuando se habilitó para uso de la aplicación.

Menú de usuario Inmediatamente al ingresar el usuario y contraseña, se presenta el menú con las acciones posibles, habilitadas:

Registrar un requerimiento nuevo: Presenta el formulario de requerimientos. Ver lista de requerimientos Propios: Se visualiza todos los requerimientos ingresados por el usuario que no están cerrados (pendientes de resolución). Ver requerimientos de mi/mis compañía/s: se visualiza todos los requerimientos de la compañías asignadas al usuario. Reportes / Exportar a Excel: Presenta un formulario que nos permite realizar una selección sobre los requerimientos y luego de visualizar la el resultado de la selección y realizar la exportación a Excel.

Editar Usuario: Presenta un formulario con los datos del Usuario que ingreso permitiendo modificar sus datos.

Registrar un requerimiento Nuevo El requerimiento es el principal elemento de información del SisNet. Mediante esta pantalla se ingresa un nuevo requerimiento en SisNet.

Elementos Información del Contacto Nombre de usuario: Nombre del usuario que está operando SisNet (No modificable). Correo: Selecciona automáticamente la dirección de correo de la persona que está operando SisNet (No modificable). Usuario Solicitante: En casos que una persona registra requerimientos en nombre de otra, se indicará el nombre del usuario al que realmente corresponde el requerimiento. Teléfono:Teléfono de referencia para ubicar al solicitante del requerimiento. Req. Interno Cia.: el número de requerimiento que utiliza la compañía que está cargando el ticket.

Clasificación de los requerimientos Compañía: Cliente o compañía a la que corresponde el requerimiento. En caso de requerimientos internos (en caso de Sistran o que la Compañía contrate el servicio de SisNet como Issue-tracker interno), se registrará el centro de costo o unidad de negocio. Departamento: Se tomará el módulo del aplicativo, área de conocimiento o proyecto. Nota: tanto la Compañía como el Departamento, deben considerarse como agrupadores de requerimientos, por lo que la forma de definirlos e implementarlos, quedará a criterio de un consenso entre ambas partes (Sistran / Cliente). Nivel de servicio: Está relacionado principalmente al grado de criticidad o forma de gestionar el requerimiento. Este dato merecerá un tratamiento específico. Ejemplos:

Orden de trabajo – El requerimiento está asociado a un costo soportado en una Orden de trabajo a facturar en forma independiente del licenciamiento o contrato de mantenimiento. Informe Técnico con costo – La tarea será resuelta por un Analista especializado, y el resultado o entregable, será una tarea de un alto grado de complejidad.

C – Según Agenda – El requerimiento se atenderá según la planificación y disponibilidad de tareas. Asignar a: En esta casilla, se seleccionará de todas las personas asociadas a la compañía para su atención, aquella que tenga la responsabilidad de continuar con el ciclo del requerimiento. Tipo de problema: Este clasificador se utiliza para poder efectuar un análisis cualitativo de los requerimientos. Los clasificadores pueden ser:

Asistencia – Se aplica a toda tarea que el cliente solicita y no puede ser realizada por el alcance funcional del aplicativo. Normalmente se trata de vuelcos de información, análisis de información, preparación de algún reporte especial, etc.

Parte de falla o error del sistema – Se aplica a una tarea que representa un error detectado en el sistema.

Ampliación de funcionalidad – Cuando se crea un nuevo módulo, listado o programa, que permite al sistema realizar alguna funcionalidad que antes no estaba efectuando y generalmente implica que el sistema adquiere mayor alcance funcional, sin importar cuál sea la magnitud.

Modificación – Se aplica cuando se modifica algún componente o programa, para que realice la misma función de otra manera. No implica un crecimiento funcional, sino una adaptación.

Tecnología: Este clasificador se utiliza para identificar la tecnología que corresponde al ticket (1G, 2G, 3G, etc).

Información del requerimiento: Título: Registrar brevemente un texto que sea lo más explícito posible y permita en una rápida lectura, individualizar el requerimiento entre otros. Descripción: Probablemente es uno de los elementos más importantes de un requerimiento, ya que es la

descripción mediante la cual, las personas involucradas se comprometen a resolver, en tiempo y forma el requerimiento con el nivel de calidad deseado. Es sumamente importante tener en cuenta que la calidad y tiempos de resolución, estarán relacionados directamente con la calidad en la definición del mismo (Ver recomendaciones). Solución: Este elemento, es tal vez tan importante como el de Descripción. Es fundamental, que la persona que resuelva el requerimiento, registre con muy pocas líneas, la estrategia que utilizó para resolver el requerimiento. Esto permite que el conocimiento quede registrado en la base de datos y posibilite que otra persona esté en condiciones de retomar la tarea o investigar en base a estas soluciones registradas cómo proceder ante situaciones similares.

Graba el requerimiento y envía un mail al usuario y al representante asignado.

Blanquea todos los campos del formulario para ingresar un nuevo requerimiento desde el principio. Importante: Los datos registrados en el requerimiento no pueden ser modificados, sino que se pueden adicionar notas, para aumentar los niveles de aclaración, pero todos los cambios quedan registrados a modo de log de eventos.

Recomendaciones Las siguientes son recomendaciones para tener en cuenta al momento de definir un requerimiento, se pueden tomar como un check-list para validar si un requerimiento está bien formado.

Características Situación Si/No

¿Se indica claramente la forma de llegar a la pantalla/formulario (Menú, acciones previas, criterio de selección, etc.)?

Error

¿Se indica la situación de error indicando mensaje, copia de pantalla de error para que sea posible inferir el error sin ambigüedad?

Error

¿Se requiere un resultado específico en función de valores de precondiciones de datos. ¿Se adjunta casos de prueba?

Error/Nuevo

El comportamiento esperado tiene cierta complejidad y obedece a un conjunto incremental de condiciones. ¿Se indica claramente todas las alternativas posibles y las acciones a tomar en cada una?

Error/Nuevo

¿Se aclara concretamente cuál es el criterio de aceptación del requerimiento? Error/Nuevo

¿En casos de aplicativos en distintos ambientes (UAT, Producción, sucursales, etc.) ¿Se indica en qué ambiente ocurrió el incidente?

Error

¿El nivel de servicio es el correcto en función del contenido de la definición (verificar alcance, contrato de prestación, tipo de tarea a desarrollar, etc.)?

Error/Nuevo

Nivel de servicio (SLA) Los niveles de servicio determinan la criticidad y necesidad de atención de un requerimiento. A grandes rasgos, si bien cada nivel tiene una definición preestablecida, es necesario establecer convenciones particulares para ajustar el criterio de cada nivel de servicio a la realidad de cada compañía, pero deberá documentarse claramente la interpretación de cada uno de ellos, y comunicarla en todos los involucrados con el uso de SisNet.

SLA 1 o “A - Atención en 24 Hs” – Criticidad de alta prioridad Se trata de una terminación anormal de programa, proceso o función que devenga en una corrupción de datos y/o un alto en la producción derivando en un impacto crítico al negocio que envuelve a múltiples usuarios. Sistran analizará el problema, identificará e implementará la solución (puede ser una solución definitiva, o una corrección o reemplazo rápido de programa para dar una solución temporal, o una modificación de datos), para poder recuperar la capacidad operativa lo antes posible. Es posible que como producto de la solución a aplicar, se pueda reducir el nivel de criticidad y pasar a SLA 2 o “B – Atención en 48 Hs”. Si la solución definitiva no es identificable o no puede ser aplicada, Sistran propondrá al Cliente alternativas y opciones viables con pros y contras.

SLA 2 o “B – Atención en 48 Hs” – Criticidad media Está definido como un incidente aislado que deriva en un impacto crítico al negocio para el cual no existe un workaround (forma alternativa de cumplir con la misma función por otros medios). Si la solución definitiva no es identificable o no puede ser aplicada, Sistran propondrá al Cliente alternativas y

opciones viables con pros y contras.

SLA 3 o “C – Según agenda” – Criticidad media baja Está definido como un incidente que atenta contra la funcionalidad del sistema, pero no interrumpe el flujo de operaciones normal debido a la existencia de un workaround. Sistran analizará el problema y estimará el esfuerzo necesario para proveer un arreglo permanente; presentará al cliente una propuesta de solución para su revisión y decisión, cuyo plan de trabajo y entrega será consensuado por ambas partes.

SLA 4, Orden de trabajo, Informe técnico – Criticidad baja Estos niveles de servicio, merecen un tratamiento especial, en todos estos casos, los plazos de entrega son acordados por ambas partes.

Orden de trabajo Tarea solicitada, que no representa un error o malfuncionamiento del sistema. Comprende una mejora, modificación o programación que cubre funcionalidad fuera del alcance de la aplicación, asistencia a tareas que solicita el cliente, en función del conocimiento y/o experiencia de los especialistas de Sistran. Estas tareas se requieren de aprobación previa para iniciar su ejecución, y se facturan como un servicio adicional no recurrente.

Informe técnico Como entregable de una evaluación, investigación o análisis, se entrega un documento denominado “Informe técnico”.

Informe técnico con costo Responde al mismo concepto de informe técnico, pero tiene un costo asociado.

Listado de requerimientos propios Para acceder a una vista rápida de los requerimientos ingresados por una persona no cerrados, se puede generar este listado. El resultado es el siguiente reporte:

Si se desea editar o ver el detalle del requerimiento, se deberá clickear con el mouse en el título del requerimiento deseado. Notar que a la derecha de cada requerimiento hay un cuadro de check o indicador de selección, que sirve para seleccionar o eliminar la selección de un requerimiento. Id: Tique asignado por el sistema de requerimientos unívoco. Titulo: Determina la descripción reducida del requerimiento, debe ser especificada con claridad ya que por la misma se identifica el requerimiento. Asignado a: Represente técnico asignado al requerimiento. Fecha de registro: Fecha de ingreso del requerimiento por parte del usuario. Estado: Estado asignado por el representante. Compañía: Compañía que fue asignada cuando se registró el requerimiento.

Selecciona todos los requerimientos (establece la marca de selección en todos los requerimientos).

Libera todos los requerimientos (elimina la marca de selección de todos los requerimientos).

Convierte el requerimiento a un formato amigable con la impresora y muestra una vista preliminar, ofreciendo las opciones de selección de impresora para imprimir.

Abrir un ID específico Cuando se desea consultar un requerimiento específico, se ingresa el número del mismo, y se activará la consulta puntual del mismo.

Ver requerimientos de mis compañías Cada usuario tiene distintas compañías asociadas. A través de este reporte, se relaciona todos los requerimientos que corresponden a las compañías relacionadas a un usuario.

Si se desea editar o ver el detalle del requerimiento, se deberá clickear con el mouse en el título del requerimiento deseado. Notar que a la derecha de cada requerimiento hay un cuadro de check o indicador de selección, que sirve para seleccionar o eliminar la selección de un requerimiento. Id: Tique asignado por el sistema de requerimientos unívoco. Título: Determina la descripción reducida del requerimiento, debe ser especificada con claridad ya que por la misma se identifica el requerimiento. Asignado a: Represente técnico asignado al requerimiento. Fecha de registro: Fecha de ingreso del requerimiento por parte del usuario.

Estado: Estado asignado por el representante. Compañía: Compañía que fue asignada cuando se registró el requerimiento.

Selecciona todos los requerimientos (establece la marca de selección en todos los requerimientos).

Libera todos los requerimientos (elimina la marca de selección de todos los requerimientos).

Convierte el requerimiento a un formato amigable con la impresora y muestra una vista preliminar, ofreciendo las opciones de selección de impresora para imprimir.

Reportes / Exportar a Excel Esta opción permite seleccionar un subconjunto de requerimientos mediante un criterio flexible de filtro. En esta pantalla se pueden obtener reportes filtrando por cualquiera de los campos indicados ya sea por especificaciones del requerimiento, por palabra clave o bien por fechas. Así mismo estos resultados pueden ordenarse por id, nombre de usuario, nombre del representante o estado. Una vez listado los resultados la herramienta presenta la opción de Imprimir y Exportar. Para generar reporte agrupando varios requerimientos en función de sus características, se ofrece la siguiente posibilidad de establecer filtros para generar un reporte de requerimientos.

Reportado por: incluye los requerimientos que contengan en el nombre del usuario que lo reportó, la frase o palabra que se ingrese en este cuadro de texto.

ID del requerimiento: Número o identificador del requerimiento a consultar.

Asignado a: Si se desea incluir los requerimientos asignados a una persona en particular, seleccionar el usuario deseado.

Compañía: Seleccionar la compañía cuyos requerimientos se desea incluir.

Departamento: Departamento cuyos requerimientos se desea incluir.

Estado: Seleccionar el estado de los requerimientos a incluir. Si se desea incluir los requerimientos pendientes, se puede seleccionar el estado especial “All No cerrados”, que involucra todos los estados en los que se indica que quedan tareas pendientes para su concreción.

Nivel de servicio: Seleccionar el nivel de servicio a incluir.

Control de facturación: TODO

Contiene o Palabras clave: Se puede ingresar un texto o frase, que servirá para incluir todos los

requerimientos que lo incluyan en las partes del requerimiento que se indiquen: Título Descripción Solución Notas

Ordenado por: Permite establecer el criterio de ordenamiento de los requerimientos resultantes de la selección. Las distintas posibilidades de ordenamiento están dadas por:

o ID del requerimiento o Nombre de usuario o Nombre del representante o Estado

Fechas: o Desde o Hasta

Las fechas que se ingresan se usan para seleccionar los requerimientos dependiendo la fecha de TODO (alta de requerimientos, último estado).

Al pulsar el botón “Ejecutar Selección”, se exhibe el resultado de seleccionar los requerimientos considerando que, de todas las opciones de selección ingresadas deben cumplirse todas a la vez. Como resultado, la pantalla que se exhibe es la siguiente:

Exporta la selección actual a una planilla Excel.

Abre la selección actual a un browser Excel en Internet Explorer. Nueva Selección Vuelve al formulario anterior, blanqueando el criterio de selección utilizado previamente.

Editar Usuario Nombre: Nombre del usuario. Apellido: Apellido del usuario. Dirección de correo: Dirección de mail al que se enviarán las notificaciones al usuario. Idioma: Idioma al que se presenta la aplicación al usuario. Contraseña anterior: Contraseña actual del usuario. Contraseña: Nueva contraseña del usuario. Confirma Contraseña: Confirmación de la nueva contraseña del usuario.

Estados (Segmento extraído de la Metodología de ATC/OT)

Introducción Un requerimiento evoluciona a través de los cambios de estado. Los estados pueden cambiar de acuerdo a un orden y posibilidades permitidas. Es importante destacar, que está abierta la posibilidad de definir un circuito particular por cliente, aunque esta definición deberá estar contemplada por el cálculo de indicadores de performance o KPI’s.

Autoría de estados En el siguiente cuadro se exhibe los posibles estados y qué roles tienen la capacidad de ingresarlos:

Estado Rol que lo ingresa 1 – Nuevo Cliente

Sistran

2 - Pedido - Sin Definición Sistran – Mesa de Entrada

3 - Pedido – Definido Sistran – Mesa de Entrada

4 - Prueba CIA Sistran – Test

5 – Desarrollo Sistran – Desarrollador

10 - Prueba Sistran (Área de Test) Sistran – Desarrollador

11 - Prueba Sistran Aprobada Sistran – Test

12 - Prueba Sistran Rechazada Sistran – Test

20 - A Cotizar Sistran – Mesa de Entrada

21 – Cotizado Sistran – Mesa de Entrada

22 - Cotización Aprobada Cliente

23 - Cotización Rechazada Cliente

31 - Prueba OK Cliente

32 - Prueba Rechazada Cliente

100 – Finalizado Cliente,

Sistran

101 - No corresponde / Cancelado Sistran – Mesa de Entrada

Roles Cliente: La definición y asignación de subroles queda librado al criterio y decisión del cliente. La contraparte asignará sub-roles dependiendo de la división de requerimientos que desee. Podría asignarse un usuario líder de Emisión para atender todos los requerimientos de emisión, otro para siniestros, etc. Sistran – Mesa de Entrada: Puede ser una o varias personas, que diriman la gestión de requerimientos velando por la correcta definición, equilibrio entre alcance y cumplimiento, y en muchos casos dirimir disparidades de criterios. Sistran – Test: Personas cuya misión principal es la de velar por la calidad y cumplimiento del alcance definido en los requerimientos. Podrán contar y reclamar al cliente (si consideran necesario), casos de prueba o circuitos de comportamiento esperado, según lo requiera la naturaleza del requerimiento a probar. Sistran – Desarrollador: Persona o equipo de personas que se hacen cargo de la tarea técnica que permite desarrollar, probar (pruebas técnicas, de unidad, de carga, etc.), y garantizar que el requerimiento cumpla con las definiciones requeridas. Sistran: No se especifica, ya que puede ser cualquiera de los roles de Sistran descriptos anteriormente.

Diagrama de transición de estados

SISTRAN CLIENTE

Analiza

Requerimiento

2 - Sin Definición

-NO

3 - Pedido Definido

-SI

Requerimiento

Completo?

20 - A Cotizar

21 - Cotizado

Analiza Cotización

Analiza falta de

definición / actualiza

1 - Nuevo

101 - Cancelado

Cotización

Aceptada?

-NO

23 - Cotización Rechazada

22 - Cotización Aprobada

-SI

5 - Desarrollo

Se realiza el desarrollo /

implementación

10 - Prueba Sistran

Calidad testea

requerimiento

Test OK?

-NO

-SI

11 - Prueba Sistran OK

12 - Prueba Sistran Rechazada

4 - Prueba Cia Test OK?

32 - Prueba Rechazada

-No

31 - Prueba OK

-Si

-No

-Si

100 - Finalizado

Rechazado por

alcance?

Matriz de transición de estados

Detalle de estados

Cód Estado Significado Responsable Acción

1 Nuevo Se genera un nuevo incidente en SisNet para realizar el pedido/ solicitud de atención a una necesidad del cliente. El responsable de generar un nuevo requerimiento debe ser el cliente y debe asignarlo al responsable de su proyecto en Sistran. El requerimiento acaba de ser creado y está a la espera de ser atendido. Es probable que el mismo personal de Sistran genere requerimientos, por necesidades de mantenimiento o tareas internas de Sistran.

Sistran – Mesa de Entrada

Analizar el requerimiento (Debe estar bien formado, acorde a un check-list, si aplica debe estar complementado de pantallas, casos de prueba, etc.). Además debe validarse el nivel de servicio (OT/ATC).

2 Pedido Sin Definición

Es necesario que el usuario responsable complete o ajuste las definiciones que permitan iniciar su resolución por parte de un técnico de Sistran.

Cliente Analiza y ajusta los defectos o déficits del requerimiento definidos por Sistran en el detalle de los motivos que llevaron a cambiar el estado a "Pedido Sin Definición".

3 Pedido Definido

Está en condiciones de poder iniciarse su resolución, este estado es consecuencia de haber resuelto una solicitud de mayores especificaciones, mediante el estado “Pedido Sin Definición”.

Sistran – Mesa de entrada

Según el nivel de servicio, se pasa a estado Cotizar (OT) o Desarrollo (ATC). En ambos casos, se designa un responsable.

20 A Cotizar Sistran está cotizando el costo del requerimiento. Se debería admitir este estado para el Nivel de Servicio OT o Informe Técnico con costo.

Sistran Se deberá, en base a todos los elementos del requerimiento, estimar el esfuerzo y costear el mismo. Deberá tenerse en mente el nivel de productividad del/los posibles perfiles a ser asignados.

21 Cotizado Finalizó la cotización por parte de Sistran. Cliente El Cliente debe analizar la cotización y aceptar o rechazar la misma.

22 Cotización Aprobada

El Cliente aprobó la Cotización. Sistran – Mesa de Entrada

Sistran cambia el estado a "Desarrollo" y asigna al responsable.

23 Cotización Rechazada

El Cliente rechazó la Cotización. Cliente El Cliente debe pasar el estado a "Finalizado.

5 Desarrollo El desarrollador, analizó el requerimiento, estimó los tiempos y está en condiciones de cumplir con su compromiso para resolver el requerimiento. Inmediatamente al comenzar con la atención del mismo, debe actualizarse el estado. Se puede tomar ajustes originados por la revisión de Test (Prueba Sistran Rechazada), o de rechazos de prueba de cliente. Una vez ajustados todos los errores o defectos del requerimiento, se deberá proceder a preparar los entregables para implementar en entorno de test (UAT) del cliente.

Sistran - Desarrollador

Analizar las definiciones y material adjunto al requerimiento. Ajustar la estimación, y en caso de desvíos, tomar acciones para mitigar los mismos, esto se puede presentar al transferir requerimientos entre desarrolladores. Es probable que la misma persona que estimó no se la que lo resuelva, o puede que se reasigne a otro perfil de desarrollador. Durante el desarrollo, se efectuará las pruebas unitarias e integrales, que garanticen una fase breve de prueba por parte de Test sin rechazos. Documentar debidamente la estrategia empleada en la resolución del issue a modo de Knowledge Base o como información de transferencia de módulo, en caso que aplique, desarrollar la matriz de impacto.Dependiendo de la naturaleza del requerimiento, podría pasar al área de Test de Sistran o directamente a Prueba en Compañía. Se debería notificar al Área de Test o a la Compañía para que planifiquen la estrategia de ejecución de la prueba en paralelo al desarrollo. Finalizado el desarrollo, deberá prepararse el Deliverable para su implementación en el entorno de prueba, y su posterior implementación en entorno de producción por parte del Cliente. El deliverable debe contar un instructivo apropiado, y el detalle de los alcances cubiertos.

10 Prueba Sistran

Cuando un requerimiento es asignado a Desarrollo, el área de test es notificada para comenzar con la planificación de la prueba.

Sistran – Test Ejecutar el plan de prueba para certificar que el requerimiento cumpla con el alcance definido. El rechazo de la prueba implica el pasaje al estado "Prueba Sistran Rechazada". La aceptación de la prueba, pasa al estado "Prueba Sistran OK". En ambos casos se deberá indicar una descripción (o referencia) del plan de prueba efectuada y en el caso de los rechazos, los motivos de los mismos.

12 Prueba Sistran Rechazada

Cuando el equipo de Calidad realiza las pruebas funcionales y los resultados obtenidos no son los esperados pasa el requerimiento a este estado con el objetivo de asignarlo nuevamente a desarrollo y que éste corrija los errores detectados.


Realizar los ajustes necesarios para satisfacer los criterios de aceptación.

11 Prueba Sistran Aprobada

Al realizar las pruebas en Sistran obteniendo resultados satisfactorios respecto del alcance indicado en el requerimiento, el equipo de Calidad pasa el requerimiento a este estado con el objetivo de asignarlo nuevamente a desarrollo para preparar la implementación en el cliente para realizar las pruebas UAT de asignarlo nuevamente a desarrollo y que éste corrija los errores detectados.


Preparar el "Delivery" para que el cliente pueda implementar en entorno de UAT, y así entrar en el estado de "Prueba en Compañía"

4 Prueba en la Compañía

Habiendo finalizado el desarrollo y/o contando con la aprobación del equipo de Test de Sistran, se procede a pasar a este estado.

Cliente Implementar el deliverable, preparado por el team de desarrollo de Sistran, vivenciando la puesta en producción en un ambiente de prueba. Esta tarea es de suma importancia, porque deberá repetir el proceso en ambiente de producción. Una vez finalizada la implementación en ambiente de prueba, deberá ejecutar los casos de prueba que le permitan certificar que el requerimiento está acorde con el alcance solicitado y convenido al aprobar el requerimiento como "Pedido Definido". Como resultado de estas pruebas, se pude presentar una aceptación o rechazo.

31 Prueba OK La solución al requerimiento provista por "Sistran - Desarrollo" fue implementada en entorno de UAT.

Cliente Implementar el deliverable en ambiente de producción, consultando con el responsable de desarrollo acerca de posibles conflictos de incompatibilidad de versiones. (Esta actividad podría presentar riesgos cuando los tiempos de prueba sean demasiado elevados, en esos casos, debería solicitarse que los cambios se pasen al próximo entregable, responsabilizándose por las demoras y tiempos emergentes de haber retrasado la prueba).

32 Prueba rechazada

En caso que el usuario Cliente haya efectuado las pruebas (cuyos elementos fueran entregados oportunamente al desarrollador), y el resultado no sea el esperado en función de lo redactado en el requerimiento, el Cliente pasará a este estado. Deberá especificarse, en caso que corresponda las condiciones en las que se efectuó la prueba (ambiente, ingreso de datos, etc.), si no coinciden con los elementos que conformaron el caso de prueba.Si el motivo del rechazo se originó porque se requiere una funcionalidad distinta a la mencionada en el requerimiento, se deberá pasar después de este estado al estado Nuevo, indicando los motivos que originaron esta decisión.


Realizar los ajustes necesarios para satisfacer los criterios de aceptación.

100 Finalizado Una vez que se aceptó la calidad y resultado esperado de la resolución de este requerimiento, el Cliente pasa el requerimiento a este estado.

N/A

101 Cancelado Sistran/Cliente determinan que el requerimiento no amerita ser resuelto.

Cliente Debe darse por finalizado o revisarlo, ajustarlo y volverlo al estado "Nuevo".

Anexo I – Métricas

Introducción El objetivo de las métricas es el de medir la calidad del servicio para poder mejorar los procesos y la atención al cliente. La mejora no es un proceso aislado o responsabilidad individual sino que es un proceso compartido por todos los involucrados. Por este motivo, es imprescindible definir métricas que permitan diagnosticar en forma objetiva, los componentes del proceso a optimizar y lograr un beneficio conjunto.

Indicadores definidos

Ind Área Métrica Periodicidad

1 SLA – Tiques Sistran (Por nivel de servicio)

(Cantidad de Tiques resueltos / Cantidad de Tiques pendiente Sistran) x 100

Mensual

2 Desvío en tiempos Sistran (Duración real Sistran – Duración estimada Sistran) * 100 /Duración Estimada Sistran

Mensual

3 Tiempo de respuesta (Tiempo de atención de nuevo requerimiento /Tiempo acordado según nivel de servicio) x 100

Mensual

4 BMI (Back Log Management Index)

(Cantidad de Tiques resueltos / (Cantidad de Tiques pendiente Sistran al inicio del período a medir x (Tiempo de antigüedad en meses +1)) + Cantidad de Tiques Nuevos desde el inicio del período a medir hasta el fin del período a medir) x 100

Mensual

5 Arreglos incorrectos (Cantidad de Tiques rechazados Sistran / Cantidad de Tiques resueltos)

Mensual

6 Tiempo de Pruebas (Tiempo de prueba Cliente /Tiempo esperado según nivel de servicio) x 100

Mensual

7 Cambios en la definición original (Cantidad de Cambios Solicitados / Cantidad de tiques resueltos) x 100

Mensual

8 Tiempo de Ajuste de Definición Tiempo insumido en ajuste de definición Cliente Mensual

9 Tests rechazados Cantidad de rechazos Test / Cantidad de Tiques resueltos

Mensual

Definición de indicadores

KPI 1 - SLA – Tickets por nivel de servicio

Cantidad de Tickets atendidos dentro del período de medición

Cantidad de Tickets a atender generados dentro del período de medición

Cantidad de tickets atendidos dentro del período de medición:

Requerimientos registrados desde el inicio de vigencia del contrato de SLA hasta el último día del período de medición.

Un ticket se considera atendido cuando dentro del período de toma de medición cambie de estado Nuevo a cualquier otro estado, dentro del tiempo de atención convenido en el SLA.

Para las fechas de inicio y fin de período, tomar la hora a las 9:30hs y 18:30hs respectivamente.

Considerar requerimientos con nivel de servicio de SLA1, 2 y 3. Cantidad de tickets a atender generados dentro del período de medición:

Requerimientos registrados dentro del período de la toma de medición con estado Nuevo.

Un requerimiento está pendiente de atención, cuando haya sido creado en el período de toma de medición y no haya sido atendido, es decir que no tuvo un cambio de estado dentro del período de medición.

Considerar requerimientos con nivel de servicio de SLA1, 2 y 3.


No se tiene en cuenta los requerimientos cuyo estado final al fin del período de toma de medición estén cancelados.

El indicador se deberá calcular para cada nivel de servicio por separado.

KPI 2 - Desvío en tiempos Sistran (Duración Real – Duración estimada según SLA) * 100

Duración estimada según SLA

Fuente de datos:

Requerimientos registrados dentro del período de la toma de medición.


Considerar requerimientos con nivel de servicio de SLA1 y 2 (Se excluye el SLA 3 por no especificarse una cantidad fija de horas de resolución, sino que es un tiempo a convenir).

No se tiene en cuenta los requerimientos cuyo estado final al fin de la toma de medición estén cancelados.

Duración real – Cantidad total de horas de las tareas que demandó la atención del requerimiento. El tiempo de atención se considera desde inicio (Estado Nuevo), despreciando los tiempos insumidos por el Cliente para establecer la definición del mismo. El tiempo se obtiene sumando el total de horas de tareas registradas asociadas a cada requerimiento resuelto dentro del período de toma de medición, considerando los períodos laborables. El requerimiento se considera resuelto cuando no quedan tareas pendientes por parte de Sistran, esto se logra cuando se encuentra en los estados:

Prueba OK

Finalizado

No Corresponde/Cancelado

Para calcular el total de tiempo de atención, se calculan los tramos de tiempo entre eventos de inicio y eventos de cierre. Si ni hubiera un evento de cierre se toma el último día del período de toma de medición. Los eventos de inicio de tramo de atención son:

Nuevo

Pedido definido

Desarrollo

Prueba rechazada

A cotizar

Cotización Aprobada

Los eventos de cierre son:

Pedido Sin Definición

Pedido Definido

Prueba en Compañía

No Corresponde/Cancelado

Cotizado

Duración estimada según SLA – Cantidad de horas pactadas en el contrato de SLA que indican el tiempo máximo de resolución del requerimiento para ese nivel de servicio. Forma de exposición: Deberá exhibirse el detalle del tiempo incurrido en cada día transcurrido entre los eventos iniciadores y de finalización. La sumatoria de horas de atención deberá contar con un claro detalle del consumo día por día. Consideraciones particulares:

Para cada tramo, se deberá calcular las horas trabajadas en días hábiles (excluir feriados), dentro del horario normal de trabajo (de 9:30hs a 18:30hs).

Si al finalizar el período de toma de medición no pasó a un estado de desarrollo o resolución, la Duración Real se considera desde que el pedido está definido (Fecha y hora de registración del estado “Pedido Definido”) hasta el último día del período de toma de medición.

KPI 3 - Tiempo de respuesta

Tiempo de atención de nuevo requerimiento x 100

Tiempo acordado según nivel de servicio

Fuente de datos:

Requerimientos nuevos generados dentro del período de la toma de medición.



Considerar los atendidos y no atendidos (En el detalle se distingue si están atendidos o no). Tiempo de atención de nuevo requerimiento – Tiempo transcurrido desde el estado Nuevo, hasta el siguiente estado. Tiempo acordado según nivel de servicio – Tiempo acordado en el contrato de SLA.

KPI 4 – Backlog Management Index Este indicador mide el “aging” o antigüedad residual de requerimientos pendientes, en forma relativa a la capacidad de atención de requerimientos. Este concepto se adopta de esta manera como alternative a la fijación de un valor arbitrario.

Fuente de datos de “Cantidad de Tickets resueltos en el período de toma de medición”:

Requerimientos generados desde el inicio de vigencia del contrato de SLA hasta el último día del período de medición.

Dentro del período de medición deben tener como último estado: Prueba OK, Finalizado o No Corresponde/Cancelado).


Considerar requerimientos con nivel de servicio de SLA1, 2 y 3. Fuente de datos de “Cantidad de requerimientos pendientes al inicio del período a medir”:

Requerimientos generados entre el inicio de vigencia del contrato de SLA y el día anterior a la fecha de inicio del período de la toma de medición.

Para las fechas de inicio y fin de período, tomar la hora las 9:30hs y 18:30hs respectivamente.


El último estado al día anterior al inicio del período de medición, debe ser pendiente (quedan tareas por completar en el requerimiento por parte de Sistran), dicho estado debe ser alguno de los siguientes:

o Nuevo o Pedido Definido o Desarrollo o Prueba Sistran o Test o Prueba Sistran Aprobada

o Prueba Sistran Rechazada o A cotizar o Cotización aprobada o Prueba rechazada

Antigüedad en meses del requerimiento – Tiempo transcurrido en meses desde la creación de ese requerimiento hasta la fecha de inicio de toma de medición. La antigüedad se trunca, no se aplica redondeo. Se deberá acumular la cantidad de meses y sumarle uno (por definición), a todos los requerimientos pendientes. Fuente de datos de “Cantidad de Tickets nuevos ingresados en el período de toma de medición”:

Requerimientos nuevos (creados dentro del período de toma de medición).



No incluir los requerimientos cancelados. Ticket Nuevo – Ticket ingresado dentro del período de toma de medición no cancelado.

KPI 5 - Arreglos incorrectos

Cantidad de Tickets rechazados

Sistran

Cantidad de Tickets atendidos

Fuente de datos de “Cantidad de Tickets rechazados Sistran”:


Debe tener al menos un estado ¨Prueba Rechazada¨ dentro del período de toma de medición.


Considerar requerimientos con nivel de servicio de SLA1, 2 y 3. Ticket rechazado Sistran – Cantidad de cambios de estado a Prueba rechazada, registrados dentro del período de la toma de medición (No importa la cantidad de Tickets). Si un mismo requerimiento tuviera más de un rechazo en el período de medición, se cuenta cada rechazo. Fuente de datos de “Cantidad de Tickets atendidos” :

Requerimientos generados desde el inicio de vigencia del contrato de SLA hasta el último día del período de medición, que hayan tenido un cambio de estado a “Prueba Rechazada” dentro del período de toma de medición.

Un ticket se considera atendido cuando dentro del período de toma de medición cambie de estado Nuevo a cualquier otro estado, dentro del tiempo de atención convenido en el SLA.



KPI 6 - Tiempo de prueba

Tiempo de prueba Cliente x 100

Tiempo esperado según nivel de servicio

Fuente de datos:

Requerimientos que hayan pasado al estado a “Prueba en Compañía” dentro del período de toma de medición.


Considerar requerimientos con nivel de servicio de SLA1, 2 y 3. Tiempo de prueba Cliente – Se toma el tiempo transcurrido desde que el requerimiento pasó al estado “Prueba en Compañía”, hasta un cambio de estado. Se considera los tramos de tiempo incluidos en días y horarios laborales. Es posible que en caso de una prueba rechazada, el requerimiento ingrese al estado de prueba más de una vez, en esos casos, el contador se reiniciará y se volverá a tomar el tiempo. Tiempo esperado según nivel de servicio – El tiempo estipulado para la prueba es de 15 días.

KPI 7 - Cambios en la definición original

Cantidad de Cambios Solicitados x 100

Cantidad de Tickets resueltos

Fuente de datos de cambios solicitados:

Requerimientos que hayan pasado al estado a “Pedido sin Definición”, o de ¨Prueba Compañía¨ a ¨Nuevo¨ dentro del período de toma de medición.


Considerar requerimientos con nivel de servicio de SLA1, 2 y 3. Cantidad de cambios solicitados – Cantidad de cambios de estado a Pedido sin definición, registrados en el período de la toma de medición (No importa la cantidad de Tickets). También cuando es un cambio de alcance. En este caso pasa del estado actual al estado Nuevo. Cantidad de Tickets resueltos:


Dentro del período de medición deben tener como último estado: Prueba OK, Finalizado o No Corresponde/Cancelado).



Anexo II – Recomendaciones para gestionar SisNet

Introducción Como toda herramienta, la potencia de la misma radica en un buen uso. Este anexo describe pautas simples para aprovechar la herramienta.

Tareas pendientes A toda persona involucrada en el uso de SisNet, le interesa conocer:

¿Qué falta para concretar los requerimientos que necesito? Esta visión está compartida por los Clientes, que registran requerimientos para su resolución, y por los especialistas de Sistran, que necesitan concretarlos. Al existir objetivos y necesidades en común, se crea la necesidad de trabajar en equipo.

Roles – Cliente La administración de SisNet en una compañía se puede administrar por alcances:

Nivel 1: Jefe/Gerente de Sistemas o contraparte de Sistran Es la persona que trata los requerimientos directamente con el representante de Sistran. Funciones y/o responsabilidades:

Coordinar con los responsables de cada área de la empresa atendida por Sistran, para negociar prioridades y tiempo de atención de Sistran hacia sus áreas. Lograr a través de los responsables de cada una de las áreas, que las tareas pendientes por parte de los usuarios bajo su ámbito de gestión sean cumplimentadas.

Nivel 2 : Responsable de área por parte del Cliente Es la persona responsable de todos los requerimientos el área. Centraliza los pedidos por mail de los usuarios de su área y los registra en el SisNet, asegurándose que no se repita la registración de los pedidos, y tenga el conocimiento de la estabilidad del módulo que gestiona, y a la vez, se compenetra con la funcionalidad del mismo. Funciones y/o responsabilidades:

Coordinar y negociar prioridades y tiempos de atención con el responsable de la compañía ante Sistran. Estar informado de la aprobación/rechazo de los requerimientos resueltos por Sistran que afecten a su área. Cuando los requerimientos requieran acciones por usuarios de su área, deberá asignar tiempo y atención para cumplir las acciones que permitan a los especialistas de Sistran resolverlos (Prueba en la compañía, pedido sin definición, aprobación de OT’s, etc.).

Seguimiento El seguimiento se pude efectuar de la siguiente manera: Ir al punto de menú “Reportes / exportar a Excel”:

Seleccionar en las opciones, el departamento o área de su interés, y el estado “All no Cerrado”. Con estas opciones, podrá tener en Excel todas las tareas pendientes de finalización, ya sea por acciones pendientes de Sistran o por usuarios de su área.

Seleccionar en las opciones, el departamento o área de su interés, y el estado “Prueba en la Compañía”, y podrá ver todos los requerimientos, que el usuario debe probar para que Sistran una vez aprobados, pueda poner en producción y darlos por resueltos, o al rechazar la prueba, el personal de Sistran pueda realizar los ajustes necesarios para volverlo a poner en prueba lo antes posible.

Seleccionar en las opciones, el departamento o área de su interés, y el estado “Pedido sin definición”, y podrá ver todos los requerimientos, que el usuario debe completar en su definición, por ser insuficiente las pautas para resolverlo. En estos casos, tener en cuenta y repasar los aspectos mencionados en

Recomendaciones.

Seleccionar en las opciones, el departamento o área de su interés, y el estado “Desarrollo”, y podrá ver todos los requerimientos que en ese momento estén siendo resueltos por Sistran.

Planificación Una buena práctica consiste en realizar una planificación de objetivos en un horizonte de tiempo determinado. Esta planificación depende de la capacidad asignada a la atención del Cliente por pare de Sistran y, eventualmente a la capacidad de realizar requerimientos por encima de la capacidad disponible para la atención del Cliente (órdenes de trabajo/proyectos). Una manera efectiva de realizar una planificación consiste en exportar a un Excel todos los requerimientos pendientes dependiendo del alcance de la planificación (todas las áreas o un área en particular). A la planilla resultante, se sugiere agregar una columna para asignar prioridad (de 0 a 10), y una columna de observaciones. A continuación, se consultará con los responsables de área el nivel de prioridades con el que se desea atender los pendientes. Cuando la planificación involucra varias áreas, se deberá lograr consenso entre todos. Finalmente, quedará una planilla Excel con las prioridades y comentarios de cada requerimiento. Estas prioridades deberán ser suministradas a Sistran para consensuar una estimación de tiempos de respuesta y compromiso de fechas tentativo. El responsable de la atención de la cuenta, informará a su contraparte los compromisos de fecha, y a partir de ese momento comienza la gestión del plan. Es sumamente importante determinar el horizonte de tiempo del plan, a medida que se comienza con esta práctico, o en función de la dinámica de la compañía, el horizonte puede comenzar siendo semanal, para luego, extenderse en el tiempo, a planes quincenales, mensuales, etc.

Ejecución del plan La determinación de un plan, constituye un ideal de expectativa de realización. Muchas veces, en el transcurso de la ejecución de un plan, surgen imponderable y urgencias, que deben atenderse a expensas del plan. Para esto, se recomienda:

Cuando surge un imprevisto que afecte al cumplimiento del plan, se deberá informar inmediatamente a la contraparte de Sistran, para que pueda consensuar con los responsables de las áreas el corrimiento de fechas.

Gestionar nuevamente las prioridades.

Ante un cambio de alcance, determinar la factibilidad de realizarlo o postergar el requerimiento.

Estar estrechamente en contacto, el responsable de atención de la compañía con su contraparte, ya que el cumplimiento del plan es responsabilidad de ambos.

Realizar reuniones de control de avance para evaluar acciones a tomar y medir e informar el grado de avance a todo los involucrados.

Actualizar frecuentemente la planilla Excel, importando nuevamente los requerimientos, conservando las columnas “ad-hoc” de Prioridad y observaciones mediante el número de requerimiento.

instructivo de sisnet - logon del usuario.pdf · orden de trabajo – el requerimiento está...

Documents