Visión de un HelpDesk con NINTEX sobre SharePoint

Un help-desk o un sistema de ticketing tiene por objeto fundamentalmente recibir peticiones por diversas vías (un email, un formulario en la intranet, en la web, una llamada por teléfono, etc.) y gestionar su resolución.

Habitualmente una petición (o intervención, o caso,  o incidencia, o solicitud de servicio o …) tiene una serie de campos que el usuario debe informar para cualificar la solicitud que está haciendo de manera suficiente como para que el sistema sepa cómo conducirla (al menos en su fase inicial) hacia su resolución:

Luego los agentes que van a intervenir enriquecerán con más información esa petición por diversas razones:

·         Para retroalimentar el sistema y que esta sepa cómo debe seguir avanzado

·         Para dejar registro de las actividades y esfuerzo aplicado

·         Para consolidar el conocimiento de resolución para su aprovechamiento en el futuro

·         Para que el usuario/cliente iniciador tenga feedback del estado de su solicitud

Habitualmente los usuario/clientes iniciadores de una solicitud suelen tener un panel (una página web) donde ven sus propias peticiones, el estado en que se encuentran e información suficiente para conocer su proceso de resolución:

Los atributos necesarios para gestionar estas peticiones varían mucho en función del contexto a resolver, pero suelen incluir:

·        
           Solicitante

·         Descripción

·         Creada cuándo

·         Canal de llegada

·         Sistema afectado

·         Tipo de Petición

·         Categoría

·         Cliente/Contrato asociado

·         …

·         Agente responsable

·         Fecha compromtida

·         Prioridad

·         Estado

·         Modificada cuándo

·         …

·         Historial

·         Tareas

·         Documentos asociados

·         Evidencias

·         …

·         ….y mucho más

Para dar soporte a estos atributos SharePoint nos ofrece listas y la relación entre listas (a modo de tablas). Por supuesto también nos ofrece soporte a la gestión documental y elementos diversos colaborativos. Las vistas de estas listas, los modelos de seguridad, las páginas de acceso, etc. también son facilidades “naturales de SharePoint”

SIN EMBARGO…

Lo que los analistas y diseñadores de estas soluciones hemos acabando requiriendo del sistema con el que construir la aplicación es que necesitamos un motor de workflows que nos permita modelar y articular los procesos de resolución de las peticiones de usuario de forma flexible, a la vez que potente.

NINTEX Workflow 2010 es el compañero perfecto para este fin, porque nos permite diseñar y desplegar workflows a partir de plantillas o desde cero y facilitar su mantenimiento posterior de una manera gráfica:

Con un metalenguaje gráfico que, apenas sin programación, permite modificar las reglas de negocio y de decisión implicadas en los diferentes subelementos de un proceso:

Con ello nos evitamos tener que estar dependiendo de reprogramar esa DLL con Visual Studio a cada cambio en los requisitos de negocio.

Los elementos con los que calcular reglas  o tomar decisiones dentro del diseño proceso son muy ricos y si no tenemos suficiente siempre podemos fabricar nuestras propias cajas.

Con workflows como los de la figuras siguientes podemos asignar un experto a un determinado tipo de Petición en función de su temática, la carga de Peticiones por experto, los lazos de respuesta y disponibilidad del experto, etc.:

Otros workflows naturales de un sistema de HelpDesk pueden ser los implicados en aumentar el nivel de prioridad de una Petición (en función de los días que han pasado, o el nivel VIP del peticionario) o el de feedback al peticionario, o la solicitud de aprobación para pedir a un proveedor externo que intervenga, o el de conversión de emails de queja a Peticiones del HelpDesk, etc., etc.