Uno de los errores más frecuentes que veo en equipos que quieren automatizar es que arrancan por la herramienta. Buscan un software, lo implementan, y a los tres meses descubren que automatizaron un proceso que estaba roto desde antes.
Automatizar un proceso mal diseñado no lo mejora. Lo acelera.
Por eso, antes de tocar cualquier herramienta, el primer paso es mapear. Y mapear bien.
Qué significa mapear un proceso
Mapear un proceso es documentar cómo se hace algo, paso a paso, tal como se hace hoy. No como debería hacerse. No como dice el manual. Como realmente pasa.
Un mapa de proceso responde tres preguntas:
- ¿Qué entra? (el input: una solicitud, un archivo, un dato, una tarea)
- ¿Qué transformación ocurre? (las acciones, decisiones y responsables en el medio)
- ¿Qué sale? (el output: el resultado esperado)
Parece simple. Pero en la práctica, cuando juntás a las personas que ejecutan el proceso y les pedís que lo describan, aparecen inconsistencias, pasos informales, decisiones no documentadas y tareas que “siempre hizo alguien” sin que nadie sepa exactamente por qué.
Eso es lo que querés encontrar antes de automatizar.
Los cuatro pasos para mapear un proceso
1. Definir el alcance
Antes de dibujar cualquier diagrama, respondé estas preguntas:
- ¿Dónde empieza el proceso? ¿Con qué evento o acción?
- ¿Dónde termina? ¿Cuál es el output final esperado?
- ¿Qué queda afuera? (tan importante como lo que queda adentro)
Un error clásico es querer mapear “todo el proceso de onboarding” cuando en realidad hay cinco subprocesos distintos. Acotar el alcance desde el inicio ahorra horas de trabajo y conversaciones circulares.
2. Relevar cómo se hace hoy (el AS-IS)
Acá viene la parte incómoda: hay que observar y preguntar, no asumir.
Las fuentes de información son:
- Las personas que ejecutan el proceso. No los gerentes que creen saber cómo se hace. Las personas que lo hacen todos los días.
- Los sistemas que se usan. Emails, planillas, CRMs, herramientas de gestión. Ahí están las huellas reales del proceso.
- Los errores y excepciones. Preguntá: “¿Qué pasa cuando algo sale mal?” Las respuestas revelan los puntos de fragilidad.
El resultado es un diagrama o listado de pasos con: acción, responsable, herramienta utilizada y tiempo aproximado.
3. Identificar cuellos de botella y pasos sin valor
Una vez que tenés el proceso documentado, lo analizás con esta pregunta en mente: ¿Este paso agrega valor al output final, o existe por inercia?
Algunas señales de que un paso es candidato a eliminarse o rediseñarse:
- Requiere esperar la aprobación de alguien que casi siempre aprueba sin revisar
- Genera un documento que nadie usa
- Se repite porque el paso anterior no es confiable
- Lo hace una persona de alto costo para una tarea de bajo valor
Los cuellos de botella son los puntos donde el proceso se frena sistemáticamente. Pueden ser una persona, una herramienta lenta, una dependencia externa o una decisión que no tiene criterios claros.
4. Diseñar el proceso mejorado (el TO-BE)
Recién acá, con el AS-IS claro y los problemas identificados, diseñás cómo debería funcionar el proceso. El TO-BE no es una utopía: es la versión mejorada y realista, que elimina los pasos innecesarios y simplifica los que quedan.
Y es sobre ese proceso mejorado que evaluás qué se puede automatizar.
Qué herramientas usar para el mapeo
No necesitás nada sofisticado para empezar. Las opciones más usadas:
- Papel y marcadores en un taller con el equipo. Sigue siendo el método más rápido para relevar el AS-IS en tiempo real.
- Miro o Mural para trabajar en formato digital y remoto, con sticky notes y diagramas colaborativos.
- Lucidchart o draw.io si querés un diagrama más formal con notación estándar (BPMN o swimlanes).
- Notion o Confluence para documentar el proceso en formato texto, con tabla de responsables y herramientas.
La herramienta importa menos que el hábito de documentar. Un mapa en Google Slides que todo el equipo entiende es mejor que un diagrama BPMN perfecto que nadie consulta.
El error más común: mapear lo que debería ser, no lo que es
Cuando le pedís a alguien que describa su proceso, tiende a describir la versión ideal. El proceso sin excepciones, sin errores, sin los atajos que aprendió con el tiempo.
Por eso el relevamiento no puede hacerse solo en una reunión de presentación. Necesitás observación directa, ejemplos reales y la pregunta que más incomoda: ¿Esto siempre funciona así, o a veces hacen algo diferente?
Las respuestas a esa pregunta son el núcleo del diagnóstico.
Cuándo estás listo para automatizar
El proceso está listo para automatizar cuando:
- Está documentado y el equipo lo valida como correcto
- Los pasos innecesarios ya fueron eliminados
- Los responsables y criterios de decisión están claros
- El output esperado está definido y es medible
- El proceso se ejecuta de forma consistente por diferentes personas
Si alguna de esas condiciones no se cumple, la automatización va a heredar el problema. Y un problema automatizado escala más rápido y es más difícil de detectar.
El mapeo de procesos no es burocracia. Es la diferencia entre implementar una solución y resolver un problema. Antes de preguntarte “¿con qué herramienta automatizo esto?”, preguntate “¿entiendo exactamente qué estoy automatizando?”.
Si trabajás con equipos que necesitan ordenar sus procesos antes de dar el salto a la automatización, escribime y lo analizamos juntos.
Si el proceso ya está mapeado y querés ver la automatización en concreto, el caso más rápido de implementar son los reportes: automatizar reportes de proyectos con IA. Para ver qué otras tareas conviene delegar — y cuáles no —, 5 tareas de PM que podés delegar a IA. Y si el desorden es más de fondo que de herramienta, empezá por cómo implementar gestión de proyectos desde cero.