KMKey HelpDesk
En este punto se supone que se ha explicado la parte común del interface así como los procedimientos de funcionamiento operativo que son transversales a toda la aplicación.
Introducción:
La estructura propia de KMKey lo hace idóneo para su configuración como software para la gestión de incidencias, servicios de mantenimiento, sistemas de ayuda al usuario, servicios de atención al cliente, servicios de gestión de averías, o Tickets I*net, etc.
Conceptos principales:
- Entorno colaborativo.
- Los participantes en KMKey HelpDesk (permisos y accesos) pueden estar definidos desde el operador que recibe la incidencia, hasta el gerente, pasando por los técnicos o miembros de los departamentos involucrados en la solución de la incidencia.
- Los flujos de información y sus participantes pueden quedar definidas y automatizadas en el patrón.
- Notificaciones automáticas (por e-mails e interna) a los participantes de cualquier acción.
- Interface gráfico para la "visualización" de la evolución de cada incidencia/averia/ticket/queja, etc..
- Registro de todas las actividades del sistema, listas para ser explotadas como listados de registros de incidencias, de actividad de los técnicos, de estado de las incidencias por categoria, etc.
Las acciones propias a todos estos servicios se pueden sistematizar y automatizar como distintos patrones de KMKey HelpDesk.
La automatización puede extenderse a la división en distintas tareas de la acción, sus fechas y plazos de desarrollo, sus responsables, los documentos generables de registro asociados, etc.
Más que en Project y en Quality, los efectos que "causan" en KMKey HelpDesk:
- la posibilidad de la sistematización de toda la secuencia de acciones en patrones de trabajo...
- el hecho que estos patrones de trabajo puedan incluir un flujo de la información bien definido...
- entre un número de participantes con
- pocos roles intercambiables y perfiles de intervención, también, muy bién definidos
facilitan extraordinariamente las tareas de recogida de requerimientos y las labores de formación, en todo lo que respecta a las partes básicas de funcionamiento de la aplicación.
Prácticas de funcionamiento
Conceptos Previos:
Introducción a la "filosofía" de proyectos/expedientes en 5 pasos, que coinciden con los TABS: DEFINICIÓN, EQUIPO, PLANIFICACIÓN, GESTIÓN Y CONTROL.
- Explicar (recordar) la vinculación entre patrones a la vista y filtros automáticos.
- Recordar que no todos los usuarios del sistema tendrán las mismas posibilidades de "iniciar" Nuevos expedientes/acciones, o de intervenir en ellos.
- Recordar que los campos de cualquier "Nuevo" son definibles según las necesidades del cliente.
- En función del usuario que estemos utilizando aprovechar para entrar como "manager" y mostrar en el TAB: ADMIN la lista de patrones, su estructura XML y los campos de un patrón en concreto.
- Recordar que en los patrones de las distintas acciones podemos dejar programado, TAMBIÉN, el flujo de trabajo del mismo:
- quién lo inicia,
- a quién lo envia,
- a quién se notifica,
- qué decisiones se toman,
- cómo y cuando se supervisan,
- quiénes son sus responsables, etc.
Así en KMKey Help Desk tenemos a disposición un sólo patrón para la demostración.
Práctica 1
- Iniciamos un patrón de Ticket I*net.
- Utilizamos el usuario (eva).
- Recogemos los datos.
- Decidimos un Revisor de la Incidencia (raúl).
TAB DEFINICIÓN
- Mostramos que se ha inciado un expediente en el NAVTREE y lo abrimos mostrando la tarea asociada.
- Salimos del usuario eva.
Práctica 2
- Entramos como raúl.
- Mediante el sistema de Mensajes, mostramos como que da notificado de su afectación a ese expediente.
- Mostramos que existen una serie de nuevos datos listos para ser recogidos a través de DEFINICIÓN > Modificar.
- Raúl rellena la parte que le corresponde y la envia al receptor rafa.
- Salimos del usuario raúl.
Práctica 3
- Entramos con el usuario rafa.
- Volvemos a mostrar como nuevos campos se añaden al TAB DEFINICIÓN.
- Entramos en el expediente mediante el sistema de notificaciones que también habrá funcionado en este caso.
- Rafa rellena la parte de información restante.
Prácica 4
TAB EQUIPO
- Podemos asignar un usuario al expediente y darle permisos mediante un rol.
- Explicar que el usuario podrá definir los roles que necesite.
- Mostrar un grupo que sea de Técnicos.
- Asignar un grupo de técnicos al expediente.
Práctica 5
TAB PLANIFICAR
- Podemos mostrar la posibilidad de que en otros patrones (mostrar ejemplos de Project o Quality) se puede modificar la planificación de la tareas y/o sus responsables.
- No hace falta insistir demasiado en ese aspecto, aunque si en el siguiente.
- Mostrar como podemos realizar (para patrones en los cuales el flujo no este tan definido internamente como en el de Ticket I*net) asignaciones en fecha, (día y hora) para un técnico concreto del equipo añadido anteriormente.
TAB GESTIÓN
- Introducción a la filosofía de los 4 ejes de desarrollo, aunque, en la mayoría de casos no se utilizen los 4 ejes.
- Insistir en el eje conocimiento/información.
Práctica 6
Añadir Documento
- Mostrar la posibilidad del gestor documental y/o gestor de versiones. Sin insistir.
- Añadir un documento generado a través de plantilla. Resumen de Incidencia.
Práctica 7
- Añadir Nota a uno o varios participantes.
Práctica 8
- Enviar un e-mail desde el expediente.
- Enviar un e-mail al expediente o tarea.
Práctica 9
- Añadir una imputación de horas.
- Hacerla coincidir con la asignación realizada anteriormente.
- Mostrar el resultado en Historia.
Práctica 10
- Añadir un gasto personal o una venta sucedidos durante la solución de la incidencia.
TAB CONTROL
- Mostrar los recursos gráficos obtenidos con la pantala específica de HelpDesk.
- Mostrar la pantalla de fechas.
- Mostrar las posibiliadades de obtener Listados de Tickets, Tareas no finalizadas, Gastos, etc.
Etiquetas: Formaciones KMKey