Part 3 Analitica empresarial & workflow: Componentes necesarios

Este es el tercero de la serie de blogs sobre analítica y workflow. En nuestro último blog hemos definido la diferencia entre un workflow real y lo que normalmente se entrega con las soluciones analíticas. En este blog analizaremos los componentes de workflow de sistema de analítica.

Si no puede esperar o le interesa en formato de documento, puede descargar todos los blogs como un documento en este enlace  'Workflow y Analitica" 

1. Definición de la Tarea.

Uno de los pilares básicos de cualquier workflow o flujo de trabajo son las tareas que describen una acción a realizar. Esto podría ser la carga de los datos reales del mes pasado en el motor de análisis, o la generación de un informe para un usuario en particular. 

Las tareas se ensamblan en los procesos, que describen una secuencia completa de actividades, por ejemplo, carga de datos, comparar con el año pasado, calcular las diferencias, presentar los resultados, solicitar al usuario más información y así sucesivamente, donde cada uno puede activarse según un conjunto de reglas. Veremos esto enseguida, pero por ahora nos centraremos en el contenido de una tarea. 

Para cada tarea, se debe especificar la siguiente información: 

• Departamento y persona involucrada. Esto identifica a los responsables de llevar a cabo la tarea. Esto podrían ser varias personas en varios departamentos. Por ejemplo, puede haber un manager de producto para cada categoría de producto, por lo tanto para revisar el rendimiento anterior requeriría que cada Gerente de producto revise sus propias áreas. Esto podría realizarse en paralelo, pero cada una tendría que completarse antes del comienzo de la siguiente tarea. 
• Modelo Analítico y vista de datos. Esto describe para cada tarea, el modelo analítico al que necesita acceder y la 'porción' de los datos para ser presentados. Dado que los modelos suelen contener datos de varios departamentos que abarcan varios procesos de gestión, es importante que sólo las personas adecuadas pueden acceder a la información correcta en el momento adecuado. Las soluciones de planificación modernas son capaces de hacer esto, de manera simple, pero el workflow aún tiene que enfocar la atención del usuario a los datos que él o ella necesitan revisar para que el usuario pueda crear la salida apropiada para la siguiente tarea. 

En algunos casos, los usuarios pueden necesitar acceso a múltiples modelos analíticos. Por ejemplo, al analizar el rendimiento anterior, pueden necesitar acceso a modelos de clientes y/o modelos de producción específicos para que puedan realizar análisis detallados y comparados con los resultados en un modelo de previsión detallado antes de que lleguen a alguna conclusión. 

• Procesamiento necesario. Una vez que se ha concedido acceso a los datos, el sistema tendrá que saber lo que hay que hacer con ello. Por ejemplo, esto puede significar la carga de un archivo de datos de una transacción de soporte o sistema externo; realizar transformaciones para generar indicadores clave de rendimiento, y dirigir a los usuarios en cuanto a lo que pueden hacer con los resultados. Esto puede incluir dar acceso a los usuarios para que puedan crear sus propios modelos y realizar sus propios análisis. 
• Acción o salida requerida. Las tareas requieren una salida. Esto podría ser el envío de los datos para su aprobación, como en el caso de entrada en un presupuesto; hacer un comentario, tal como después de la revisión de los resultados reales; de la aprobación de un envío, como en el caso de la creación de una previsión. En la mayoría de los casos, la salida será obligatoria, por lo que el formato esperado debe ser claramente definido. Para el envió de datos, esto debe incluir el modelo analítico y el segmento de datos que necesita ser completado. 
• Notificación de finalización. Este último dato indica que cuando la tarea se ha completado y por ello ya no está disponible. Esto puede incluir lo siguiente: 

• Cuando se ha realizado una acción concreta, como la aprobación de un presupuesto.
• Una fecha o la hora. Por ejemplo, las previsiones se pueden introducir hasta el último día del mes, después de lo cual se bloqueará la entrada de datos.
• Un conjunto de condiciones. Por ejemplo, se pueden modificar las solicitudes presupuestarias hasta que todas las propuestas han sido recibidas. 
• Cualquier combinación de los anteriores.

2. Definición del proceso

Cuando las tareas se colocan dentro de un proceso, se requiere la siguiente información por la que han de operar: 

• Desencadenante. Aquí se definen las reglas por las cuales se inicia una tarea. Esto podría ser una fecha del calendario; un evento como la realización de una tarea anterior; una excepción como una variación especificada; o una combinación de todos ellos. Dentro de un proceso puede haber múltiples tareas siendo ejecutadas en el mismo tiempo, pero otras que únicamente pueden funcionar cuando todas las demás han terminado. 
• Parámetros. Éstos proporcionan una forma de transferir información a una tarea que puede ser utilizada en el trabajo que se realiza. Ejemplos de ello son parámetros que pasan el mes y el año curso en una tarea para que los datos se analicen para el período actual. Esto significa que las tareas que utilizan esta información no es necesario modificar cada mes. 
• Establecer fechas y tiempos. Todas las tareas deben tener definido una fecha/tiempo de comienzo y fin para cuando se requiera una intervención manual. Por ejemplo, un usuario es requerido para ver el resultado y hacer una recomendación. Esto define cuándo pueden acceder a los datos y la fecha en la que deben responder. 
• Procedimientos de escalamiento. Para cada tarea, particularmente aquellos que involucran la intervención manual, tiene que haber un mecanismo por el cual la tarea se escala a otra persona o tarea en caso de no llevarse a cabo satisfactoriamente dentro del plazo establecido. Esto evita que todo el proceso se interrumpa e impide que los cuellos de botella se acumulen.

3. Control de Procesos / Tareas

Una vez que un proceso se ha activado, las siguientes actividades deben ser soportadas por las capacidades del workflow: 

• Automatizar las listas “To Do”. El flujo de trabajo debe informar a los usuarios — vía email u otros dispositivos de comunicación — cuando se requiere una acción. Debe generar automáticamente listas “To Do” personalizadas que se actualizan cuando las tareas se completan. 
• Automatizar los avisos y el escalamiento. A medida que llegan las fechas de vencimiento de las tareas, los usuarios deben ser advertidos acerca de lo que se necesita y cuándo. Si estos se ignoran o son completados insatisfactoriamente, la tarea tiene que ser automáticamente escalada e informadas las personas adecuadas. 
• Monitor del workflow. Finalmente, los administradores deben ser capaces de ver el estado de todas las tareas y procesos. Debería ser fácil ver si un departamento o una unidad negocio se retrasará, y donde se han escalado las tareas. Desde este punto de vista, el administrador debe ser capaz de modificar el proceso y reorientar las actividades como mejor lo considere.

En el siguiente y último blog, analizaremos los aspectos de diseño de un sistema de workflow inducido (workflow driven system) y los puntos a comprobar en un software. Si no puedes esperar, entonces  puedes descargar nuestro documento en español que cubre toda la serie en este enlace "Workflow y Analítica empresarial" o en la imagen de abajo.