Una tarea de proceso de negocio es un paso en el que el proceso se detiene y espera la acción de una persona: aprobar un documento, leerlo, completar datos. A diferencia de una tarea normal, no aparece en la sección «Tareas y proyectos»: vive en la lista «Procesos de negocio» y bloquea la ejecución del proceso hasta que recibe una respuesta. Veamos qué acciones crean estas tareas, dónde las ve el empleado y cómo lograr que no se atasquen durante semanas.

¿En qué se diferencia una tarea de proceso de negocio de una tarea normal?

Una tarea es una entidad independiente: tiene responsable, fecha límite, listas de control, se puede delegar y comentar, y permanece en el historial de la sección «Tareas y proyectos». Una tarea de proceso de negocio es una pausa dentro del proceso: el diseñador de procesos llegó al paso «preguntar a una persona» y espera. Mientras el ejecutor no responda, el proceso está parado, y con él todos los pasos siguientes: notificaciones, cambio de etapa, generación de documentos. Una tarea de proceso completada desaparece de la lista, y su rastro queda en el registro del proceso. La confusión la añade el hecho de que un proceso de negocio sabe crear también tareas normales —con la acción «Crear tarea»—, pero esa es justamente una tarea de la sección general, con su propia vida. Si un empleado «no recibió nada» aunque el proceso esté lanzado, casi siempre es que está buscando la tarea donde no es.

¿Qué acciones crean tareas de proceso de negocio?

Tres acciones estándar del diseñador de procesos. «Aprobación de documento»: el ejecutor recibe los botones «Aprobar» y «Rechazar», y el proceso se bifurca según el resultado; es la base de cualquier aprobación. «Lectura del documento»: basta con confirmar la lectura, no hay bifurcación: órdenes, reglamentos, instrucciones nuevas. «Solicitud de información adicional»: el ejecutor rellena los campos indicados y devuelve los datos al proceso; así se piden datos de registro o una aclaración a una solicitud. En las tres se configuran los ejecutores, el nombre y la descripción de la tarea. La descripción es el campo principal: escribe ahí el importe, el enlace al documento, el meollo del asunto, para que la decisión se tome desde la propia tarea, sin escarbar en la ficha. Cómo montar una ruta con estos pasos, en el análisis de la aprobación de documentos.

¿Dónde ve el empleado sus tareas de proceso?

En el menú de la izquierda, en la opción «Procesos de negocio»: ahí está la lista de tareas que te esperan a ti, con un contador de las pendientes. En paralelo llega un aviso al centro de notificaciones: la tarea se abre y se ejecuta directamente desde él. El tercer punto es la ficha del elemento: en una negociación o un proceso inteligente se ve el proceso de negocio lanzado y su paso actual. La causa más frecuente de las «aprobaciones atascadas» es que el empleado no conoce la sección «Procesos de negocio» y espera una tarea normal, donde las tareas de proceso no llegan. Se cura con una sola publicación interna con captura de pantalla y el hábito de mirar el contador del menú: más barato que cualquier reglamento.

¿Cómo evitar que las tareas de proceso se atasquen?

Dos técnicas. La primera, un plazo honesto. Calcula la fecha límite de la tarea en días laborables y no naturales, si no, una aprobación entregada un viernes por la tarde «se vencerá» durante el fin de semana. El robot «Fecha + N días laborables (RU)» suma a la fecha la cantidad necesaria de días laborables según el calendario laboral de Rusia —los fines de semana y festivos no cuentan— y devuelve la fecha en dos formatos: para el campo y para el texto de la notificación. La segunda, el escalado. Si el plazo venció y no hay respuesta, el proceso encuentra al responsable del ejecutor con el robot «Obtener el responsable de un empleado»: este, según la estructura de departamentos, devuelve el ID, el nombre y el e-mail del responsable directo, más el indicador «encontrado», y la siguiente tarea va ya hacia él.

¿Cómo comprobar los datos antes de emitir una tarea de proceso?

La peor tarea de proceso es aquella sobre la que no se puede tomar una decisión: aprobar una factura sin importe, un contrato sin los datos de registro de la contraparte. Cada caso así es una vuelta de más de «rechazado, devuelto para corregir» y menos confianza en el proceso. Antes de la acción «Aprobación de documento», coloca el robot «Comprobar que un campo está relleno»: recibe el tipo de entidad, su ID y el código del campo, y devuelve el indicador Y/N y el valor actual. Si el campo está vacío, el proceso no emite la tarea, sino que devuelve la ficha al responsable con una notificación de qué rellenar exactamente. Quienes aprueban se acostumbran rápido: si llegó una tarea, todo está listo para decidir, y responden notablemente más rápido.

Conclusión

Una tarea de proceso de negocio es un paso del proceso que espera a una persona: aprobación, lectura o aportación de datos. Las tareas de proceso se buscan en la opción «Procesos de negocio» del menú de la izquierda y en las notificaciones, no en «Tareas». Para que no se atasquen: plazo en días laborables, escalado al responsable según el organigrama y comprobación de que los campos están rellenos antes de emitir la tarea. Los ladrillos listos para todo esto están en el catálogo de Roboteka: se instalan desde Bitrix24.Market y funcionan en el mismo diseñador de procesos, junto a las acciones estándar. ¿No hay el que necesitas? Describe la tarea, hacemos el robot gratis.