Cómo mapear un proceso de negocio
Cómo mapear un proceso de negocio de principio a fin: acuerda los límites, entrevista a quien hace el trabajo, dibuja el as-is con sus excepciones y valídalo. Con un ejemplo vivo de compra a pago.
Cómo funciona
Escribe el alcance como dos eventos
«Empieza cuando se crea una solicitud de compra; termina cuando se paga al proveedor.» Una frase, acordada con quien encargó el mapa, antes de cualquier entrevista. Si la gente no se pone de acuerdo sobre los límites, ese desacuerdo es el primer hallazgo y es más barato resolverlo ahora que después de tres borradores.
Identifica los carriles y a las personas que hay en ellos
Lista los roles por los que pasa el trabajo, incluidas las partes externas, y busca una persona por carril que ejecute los pasos de verdad y no que los supervise. Cuatro o cinco carriles; si necesitas ocho, el alcance es demasiado amplio y debería partirse en una entrega entre áreas.
Entrevista buscando las excepciones, no la rutina
Todo el mundo sabe describir el camino feliz y rara vez es ahí donde está el problema. Pregunta más bien: ¿qué haces cuando falta el código presupuestario, cuando quien aprueba está de vacaciones, cuando la factura llega antes que la mercancía? Esas respuestas son las ramas, y casi nunca están escritas en ningún otro sitio.
Construye el as-is como filas y deja los carriles para el final
Escribe los pasos en QueryChart como filas, conéctalos con la columna «Line to» y asigna después a cada fila un carril de responsable y una fase. Acertar la secuencia antes de preocuparte por la maquetación mantiene la discusión sobre el proceso; el diagrama se monta solo a partir de las filas.
Mide las entregas entre carriles
Para cada cruce entre carriles, anota cómo se entera el carril siguiente de que tiene trabajo y cuánto suele esperar. Escríbelo en el comentario del paso. En la mayoría de los procesos de negocio el tiempo de ciclo es tiempo de cola y no de trabajo, y las colas están exactamente en esas fronteras.
Valida, aprueba y mantén una sola versión
Recorre el mapa terminado con cada dueño de carril y cambia aquello en lo que no estén de acuerdo. Después apruébalo en QueryChart, para que exista una única versión vigente con una firma y una fecha, en lugar de un PDF que empieza a alejarse de la realidad al día siguiente del taller.
Preguntas frecuentes
¿Cuál es la diferencia entre mapeo de procesos y modelado de procesos?
El mapeo de procesos produce una imagen que la gente usa: quién hace qué, en qué orden, con qué decisiones y qué entregas entre áreas. El modelado de procesos produce una representación formal y sujeta a notación —normalmente BPMN— que una herramienta puede validar o ejecutar, y que trae reglas sobre tipos de evento, compuertas y flujos de mensajes. La mayoría de las organizaciones necesitan el mapa. Recurre al modelo cuando algo aguas abajo vaya a consumirlo, como un motor de workflow o un proyecto de automatización.
¿Debo mapear el proceso actual o el mejorado?
El actual, primero y siempre. Un mapa as-is es un registro fáctico que puedes validar con quien hace el trabajo, y eso lo convierte en un acuerdo en lugar de en una opinión. Una vez que existe, un mapa to-be es una conversación corta y barata sobre cambios concretos. Saltarse el as-is significa diseñar la mejora contra un proceso supuesto, y la suposición suele ser el camino feliz.
¿Cuánto debería llevar mapear un proceso de negocio?
Para un solo proceso operativo con cuatro o cinco carriles: un par de horas de entrevistas, una tarde para el borrador y una sesión de validación. Dos o tres días de esfuerzo repartidos en el calendario. Todo lo que lleve semanas suele ser un problema de alcance y no de complejidad: no se fijaron los límites, así que el mapa siguió creciendo hacia los lados, hacia procesos vecinos.
¿Quién debería ser el dueño de un mapa de proceso de negocio?
Una sola persona con nombre que pueda cambiarlo, normalmente el dueño del proceso y no quien facilitó el mapeo. Los dueños de carril lo revisan; el dueño del proceso lo mantiene. Sin un único dueño, los mapas se degradan de forma predecible: siguen técnicamente disponibles y en silencio dejan de coincidir con la realidad, lo cual es peor que no tener ninguno, porque la gente sigue confiando en él.