1- Índice
Propuesta para sistema de tickets para Defensa Civil de Rosario
1- Índice
2- Requerimientos funcionales
3- Objetivos
4- Propuesta
4.1- Proceso interno
5- Implementación
5.1- Estados de los tickets
5.2- Pantallas
5.2.1- Alta de tickets
5.2.2- Vista de la historia de un ticket
5.2.3- Búsquedas de tickets
5.2.4- Estadísticas
5.3- Modificaciones al sistema
5.4- Integración con infomapas de MR
5.5- Formulario público de denuncias
5.6- Requerimientos no funcionales
6- Ventajas
7- Estimación
8- Futuras mejoras
2- Requerimientos funcionales
Defensa Civil necesita organizar su funcionamiento interno de recepción de denuncias, clasificación y derivación de incidentes.
Actualmente están llevando registro de los incidentes en planillas de Excel, lo cuál no les es lo suficientemente útil para organizarse, hacer el seguimiento de los mismo, detectar duplicados y para generar estadísticas.
Defensa Civil debe comunicarse a diferentes entes internos y externos para la realización de las tareas de resolución de los casos. Por ejemplo:
● Cuadrilla propia
● EPE
● Parques y paseos
● ASUS (área de servicios urbanos) una por distrito
● Aguas santafesinas
● Litoral gas
● Policía
● Bomberos
● GUM
● Alumbrado public
3- Objetivos
● Simplificar la recepción de pedidos
○ Poder corroborar las direcciones durante la atención de la llamada
○ Poder identificar distrito al que corresponde, seccional de la policía, etc.
● Simplificar la clasificación y priorización de denuncias
● Simplificar el seguimiento de los mismos
● Poder detectar denuncias duplicadas
● Poder brindar mejor información a las cuadrillas de trabajo
● Poder brindar información a los denunciantes
● Poder sacar estadísticas
4- Propuesta
Se propone la utilización de algún sistema de tickets online Open Source. Al ser Open Source, no tiene costo de licencias ni de utilización. Al ser online, permitiría independizarse de la ubicación física desde la cual se accedería.
Además, se propone integrar el sistema de tickets con el sistema de mapas de la municipalidad de rosario (http://www.rosario.gov.ar/infomapas/) para integrar las direcciones y potencialmente mostrarla en un mapa.
La implementación de sistema de tickets requerirá un cambio en la metodología de trabajo del equipo de defensa civil.
4.1- Proceso interno
Se propone implementar un proceso con 3 niveles de atención:
1. Nivel 1: Son los telefonistas que atienden los llamados, cargan el ticket con la información requerida y lo pasan al Nivel 2.
2. Nivel 2: Son los que toman los tickets, los priorizan y clasifican y lo derivan al área de Nivel 3 que corresponda.
3. Nivel 3: Son los que hacen la gestión de los tickets comunicándose con los entes internos y externos. Podrían estar divididos en diferentes equipos que se ocupen de diferentes cosas.
Potencialmente, en caso de que las personas ocupadas en estas tareas sean pocas, las mismas personas pueden llegar a cubrir diferentes niveles, pero es importante tener bien separados los roles.
5- Implementación
Se propone utilizar el sistema RT (Request Tracker, http://bestpractical.com/rt/) o algún otro similar, que pueda ser de fácil implementación.
El sistema RT permite la adaptación para agregar campos personalizados a los tickets de modo de poder almacenar la información relevante para Defensa Civil de cada uno de los tickets.
Además, este sistema se puede configurar para estar completamente en idioma castellano.
En el sistema tiene el concepto de Colas que sirven para listar los tickets derivados en cada sección. Las colas a crear serían, por ejemplo, las siguientes:
● Service Desk: En esta cola se guardan los tickets que la gente de Nivel 2 debe tomar para priorizar. Una vez que el ticket se priorizó y clasificó, la persona de Nivel 2 lo debe pasar a una cola de Nivel 3 para ser trabajado.
● Una cola por cada grupo diferente de nivel 3.
● Una cola por cada equipo de trabajo interno o ente externo.
Cuando un ticket que se encuentra en nivel 3, requiere participación de varios equipos de trabajo o entes externos, se podría crear sub-tickets asociados al ticket inicial, para derivar a cada entidad de trabajo. Para el cierre definitivo del ticket inicial, todos sus sub-tickets deben estar cerrados. Con la correcta configuración, el sistema RT soporta esta funcionalidad.
5.1- Estados de los tickets
Los tickets podrían estar en uno de los siguientes estados:
● Nuevo: El ticket recién fue creado y aún no ha sido priorizado.
● Pendiente: El ticket ya ha sido priorizado, pero aún no se ha realizado ni derivado.
● Cancelado: El ticket se dio de baja por ser falso o duplicado.
● Derivado: El ticket ya está siendo trabajado por el área correspondiente.
● Realizado: El área correspondiente ha completado su tarea, pero Defensa Civil aún no dio por cerrado el ticket. Al comienzo, sería Nivel 3 quien pasa los tickets del estado Derivado al estado Realizado; en el futuro, si los equipos de trabajo tienen acceso a la herramienta, serían ellos quienes puede dar por Realizado el ticket. En este caso, Nivel 3 puede volver a derivar el ticket a otro ente o, si no hay más tareas que ejecutar, puede cerrar el tiket poniéndolo en estado Terminado.
● Terminado: Todas las tareas han sido completas y se dio por cerrado el ticket. Solo la gente de Nivel 3 puede dar por Terminado un ticket, para asegurar que el trabajo a sido realizado completamente.
5.2- Pantallas 5.2.1- Alta de tickets
El alta de ticket del RT es similar a la siguiente pantalla. De todas maneras, hay que tener en cuenta que se puede personalizar para solicitar la información que sea necesaria.
5.2.2- Vista de la historia de un ticket
5.2.3- Busquedas de tickets
5.2.4- Estadísticas
5.3- Modificaciones al sistema
● Implementación look & feel apropiado
● Configuración de correo electrónico
● Creación de las coles necesarias
● Agregar los estados definidos
● Agregar los campos personalizados para cada cola
● Implementar mecanismos para aumentar la prioridades automáticamente para los tickets abiertos
● Implementación de un campo de dirección u ubicación que permita ser autocompletado en la medida que se escribe, que obtenga la información desde el sitio de infomapas de MR. De esta forma se podrá almacenar información del distrito, seccional de policía y coordenadas geográficas.
● Modificar la visualización de los tickets para que permita mostrar en algún lado, de forma sencilla, la ubicación del incidente.
● Dar de alta los usuarios iniciales.
5.4- Integración con infomapas de MR
Actualmente, la municipalidad de rosario tiene el sistema de infomapas que permite buscar por dirección y obtener la información de seccional de policía y distrito y la ubicación en el mapa.
Esta aplicación está desarrollada para usuarios finales, pero debería ofrecer esta información por medio de una Interfaz de Programación de Aplicaciones (API) para poder ser consultada por el sistema de tickets más fácilmente.
Por lo tanto, habría que solicitar el desarrollo de de esta API a la municipalidad. Este desarrollo debería ser fácilmente implementada por ellos, ya que disponen de la tecnología y la información necesaria para hacerlo.
5.5- Formulario público de denuncias
Se recomienda realizar un formulario en el que se permita al público la carga de incidentes vía internet, facilitando el trabajo de carga de la información. El formulario podría ser similar al siguiente:
Dadas las facilidades del sistema RT, este formulario solo debería enviar un correo electrónico a una dirección específica y automáticamente, el sistema de tickets crearía el ticket en el estado apropiado para ser revisado por la gente de Nivel 2.
Una vez que el sistema creó el ticket, enviaría un correo electrónico al solicitante para que este pueda notificarse de la creación del mismo y agendar el núrmero de ticket.
5.6- Requerimientos no funcionales
El sistema RT tiene los siguientes requerimientos, según lo que figura en el sitio web oficial (http://bestpractical.com/rt/requirements.html):
● Un servidor web, por ejemplo Apache.
● Un servidor de base de datos, por ejemplo MySQL.
● Sistema operativo Linux.
Potencialmente, reconociendo las necesidades de Defensa Civil, con un solo servidor físico se podría soportar toda la infraestructura.
El servidor debería estar hosteado en internet para poder se accesible desde diferentes ubicaciones.
Cada oficina debe contar con el acceso a internet correspondiente y terminales necesarias para el acceso al sistema.
6- Ventajas
La implementación de este sistema traería las siguientes ventajas:
● Reducir la carga de trabajo a las personas que atienden el teléfono permitiendo que no se interrumpa la atención mientras que las denuncias comienzan a ser atendidas sin demoras.
● Se puede corroborar las direcciones automáticamente mientras se atiende el llamado, identificando automáticamente distrito correspondiente y seccional policial.
● Poder descartar fácilmente reclamos duplicados.
● Ver visual y rápidamente en un mapa la ubicación del incidente.
● Optimizar la forma de priorizar los incidentes, para poder facilitar la atención de aquellos que son más urgentes.
● Mejorar la logística para organizar las tareas a realizar por grupos (por zona, equipo, etc).
● Posibilitar el seguimiento de los equipos de trabajos y entes externos, para evaluar sus rendimientos.
● Posibilitar la obtención de estadísticas sobre tipos de denuncias, zonas de la ciudad, tiempos de respuestas, etc.
● Poder obtener información útil y a tiempo para brindar sobre el estado de los incidentes, tiempos posibles de resolución, etc.
7- Estimación
El proyecto podría realizarse por una sola persona con conocimientos de RT en las siguientes etapas:
● Relevamiento funcional e instalación inicial: 60 horas.
● Configuraciones y modificaciones al sistema: 80 horas.
● Integración con infomapas: 40 horas.
● Capacitación de uso para usuarios finales (Nivel 1, 2 y 3): 40 horas.
Se asume que se dispone de la API de infomapas disponible antes del comienzo de la etapa correspondiente. Se podría enviar una información técnica de lo que se necesita antes del comienzo del proyecto, para que la municipalidad de Rosario lo pueda implementar en fecha.
8- Futuras mejoras
Además de lo propuesto, se pueden implementar las siguientes futuras mejoras:
● Brindar acceso a las entidades externas a los tickets de la colas que le correspondan, de modo que ellos puedan cargar el reporte o las respuestas, directamente en cada ticket.
● Implementar un cliente para Mobile que permita a las cuadrillas obtener el listado de tickets pendientes priorizados para mejorar su organización de trabajo.
● Implementar 1 interfaz web para que los denunciantes puedan ver el seguimiento de sus tickets.
● Mostrar estadísticas en un mapa general para ver tickets abiertos o cerrados.
