Mapeo de procesos: no diseñes cómo debería funcionar antes de descubrir cómo funciona realmente
Pregúntale a un gerente cómo funciona un determinado proceso.
Pregúntale a un gerente cómo funciona un determinado proceso.
Él te explica.
La actividad entra por aquí.
Pasa por esta persona.
Después va para aquel sector.
Hay una aprobación.
El sistema lo registra.
El equipo concluye.
Parece organizado.
Ahora sigue un caso real.
La solicitud llega por WhatsApp.
Alguien la copia en una planilla.
La planilla no está actualizada.
La persona envía un mensaje para confirmar una información.
Espera.
Cuando la recibe, la carga en el sistema.
Descubre que faltó una aprobación.
Vuelve.
El gerente aprueba desde su celular.
Nadie registra la aprobación.
La actividad queda parada porque otra persona no sabía que tenía que continuar.
Después alguien se da cuenta.
Corre.
Entrega.
Al final, todos dicen:
“Nuestro proceso es simple”.
Por eso es que el mapeo de procesos no debería empezar en una sala de reuniones dibujando cómo la empresa cree que trabaja.
Debería empezar por descubrir cómo el trabajo realmente sucede.
No mapees primero cómo debería funcionar. Mapea cómo funciona realmente.
El proceso real y el proceso imaginado pueden ser dos empresas diferentes
Toda organización tiene una versión oficial del trabajo.
Y una versión operativa.
En la versión oficial:
el pedido ingresa al sistema.
En la operativa:
el pedido llega por WhatsApp, teléfono, e-mail y mensaje directo al dueño.
En la versión oficial:
el gerente aprueba.
En la operativa:
nadie sabe exactamente cuándo es necesaria la aprobación, entonces pregunta “solo para asegurarme”.
En la versión oficial:
el CRM registra al cliente.
En la operativa:
parte de la información está en el CRM, parte en la agenda y parte en la cabeza del vendedor.
En la versión oficial:
el procedimiento existe.
En la operativa:
nadie abrió el documento en los últimos seis meses.
Mapear procesos significa reducir la distancia entre lo que la empresa cree que sucede y lo que realmente sucede.
El flujograma es una consecuencia, no un descubrimiento
Los flujogramas son útiles.
El BPMN puede ser útil.
El SIPOC puede ser útil.
Los diagramas ayudan a visualizar el trabajo.
Pero ningún dibujo sustituye el descubrimiento.
Si preguntamos solo:
“¿Cómo debería ser?”
podemos crear un excelente mapa de una empresa que no existe.
El trabajo inicial necesita encontrar hechos.
¿Quién recibe?
¿De dónde llega?
¿Qué verifica?
¿Dónde registra?
¿Qué información falta?
¿A quién le pregunta?
¿Cuánto espera?
¿Qué excepción aparece?
¿Qué vuelve?
¿Qué se hace dos veces?
¿Qué planilla paralela existe?
¿Qué etapa solo funciona porque alguien con experiencia se acuerda?
Después de eso, representarlo visualmente pasa a tener mucho más valor.
El proceso está en los detalles que nadie pone en la presentación
Algunos de los puntos más importantes rara vez aparecen en el procedimiento oficial.
“Si es un cliente antiguo, llámale a María”.
“Cuando pasa de este valor, pregúntale al dueño”.
“El sistema no hace eso, así que lo controlamos aquí”.
“Este informe yo lo descargo y lo arreglo en Excel”.
“Cuando no responde, le envío un mensaje por WhatsApp”.
“Esto en teoría es de finanzas, pero normalmente lo hacemos nosotros”.
Estas frases parecen pequeñas.
Pero revelan:
dependencia;
responsabilidad ambigua;
integración inexistente;
regla informal;
retrabajo;
riesgo;
conocimiento tácito;
oportunidad de mejora.
La improvisación también forma parte del proceso real.
Ignorarla en el mapa no la elimina de la operación.
El objetivo no es documentarlo todo
Una empresa tiene cientos o miles de actividades.
Intentar mapearlo todo con el mismo nivel de profundidad puede transformar la mejora en burocracia.
Tenemos que elegir.
Un proceso merece prioridad cuando combina factores como:
impacto financiero;
frecuencia;
retrabajo;
riesgo;
dependencia de personas;
quejas de clientes;
tiempo de espera;
error recurrente;
dificultad de capacitación;
potencial de automatización;
cuello de botella para el crecimiento.
La pregunta no es:
“¿Qué procesos existen?”
Es también:
“¿Qué procesos le están costando capacidad a la empresa?”
Siete movimientos para mapear antes de mejorar
Un enfoque práctico puede ser el siguiente:
VER → ESCUCHAR → SEGUIR → MEDIR → REDISEÑAR → VALIDAR → IMPLEMENTAR
1. Ver
Observa la operación.
No empieces solo por el organigrama o el procedimiento.
Mira las pantallas.
Planillas.
Mensajes.
Documentos.
Colas.
Intercambios entre áreas.
La realidad deja rastros.
2. Escuchar
Conversa con quien ejecuta.
No solo con quien gerencia.
Pregunta:
¿qué sucede normalmente?
¿qué sale mal?
¿dónde esperas?
¿qué necesitas preguntar?
¿qué información suele faltar?
¿qué etapa harías de forma diferente?
¿quién decide realmente?
3. Seguir
Elige casos reales y acompáñalos de principio a fin.
Un pedido.
Una venta.
Una compra.
Una queja.
Una contratación.
Un presupuesto.
Esto revela pasajes que las entrevistas aisladas pueden ocultar.
4. Medir
No todo cuello de botella necesita un dashboard sofisticado.
Pero necesitamos evidencia.
¿Cuánto tiempo?
¿Cuántas veces?
¿Cuántas personas?
¿Cuántos retornos?
¿Qué volumen?
¿Qué error?
¿Qué costo aproximado?
¿Qué impacto en el cliente?
La medición ayuda a separar una molestia de una prioridad.
5. Rediseñar
Ahora podemos discutir el TO BE.
¿Qué eliminar?
¿Qué simplificar?
¿Qué cambiar de responsable?
¿Qué estandarizar?
¿Qué integrar?
¿Qué automatizar?
¿Qué decisión se puede delegar hacia abajo?
¿Qué información necesita existir antes?
Aquí nace el proceso futuro.
6. Validar
Antes de declarar el nuevo proceso como oficial, incluye a quien lo ejecuta en la conversación.
¿Funciona?
¿Hay alguna excepción olvidada?
¿La responsabilidad está clara?
¿La herramienta lo soporta?
¿La regla crea otro problema?
La validación reduce el riesgo de diseñar un proceso bonito e impracticable.
7. Implementar
Un proceso rediseñado todavía no es un proceso implementado.
Necesita llegar a:
las personas;
la rutina;
el sistema;
los indicadores;
la capacitación;
la responsabilidad;
el seguimiento.
El mapa muestra el camino. La implementación cambia la operación.
AS IS y TO BE: dos mapas con funciones diferentes
En proyectos de procesos, dos conceptos aparecen con frecuencia.
AS IS: cómo funciona el proceso hoy.
TO BE: cómo debería funcionar después de la mejora.
La lógica es simple.
El error es saltar directamente al TO BE.
Cuando hacemos eso, perdemos información sobre por qué el proceso actual se convirtió en lo que es.
Alguna etapa aparentemente inútil puede existir para controlar un riesgo real.
Una aprobación puede haber surgido después de un fraude.
Una planilla paralela puede compensar una limitación del sistema.
Un atajo puede existir porque el flujo oficial es demasiado lento.
Antes de eliminar, tenemos que entender.
Una mejora sin contexto puede eliminar un desperdicio - o eliminar una protección.
El retrabajo es una de las señales más valiosas
Cada vez que algo vuelve, surge una pregunta.
¿Por qué volvió?
¿Faltó información?
¿El criterio era ambiguo?
¿La responsabilidad no estaba clara?
¿El cliente no entendió?
¿El sistema permitió el error?
¿La etapa anterior no tenía cómo verificarlo?
¿Se digitó el mismo dato dos veces?
El retrabajo es visible porque consume tiempo.
Pero también tiene un efecto oculto.
Interrumpe la concentración.
Aumenta la cola.
Genera irritación.
Retrasa al cliente.
Ocupa a los líderes.
Crea urgencia.
El mapeo ayuda a ver dónde el trabajo deja de avanzar y empieza a dar vueltas.
La espera también es parte del proceso
Las empresas suelen fijarse en el tiempo de ejecución.
¿Cuánto se tarda en hacer?
Pero ignoran el tiempo de inactividad.
Una actividad puede tardar quince minutos en ejecutarse y tres días en cruzar la empresa.
Espera por aprobación.
Espera por información.
Espera por respuesta.
Espera por acceso.
Espera porque nadie se dio cuenta de que era su turno.
En muchos procesos administrativos y comerciales, reducir la espera puede ser más relevante que acelerar la ejecución.
Por eso necesitamos mapear no solo tareas.
Necesitamos mapear transiciones y filas.
Una responsabilidad confusa produce un proceso lento
“¿Quién es el responsable?”
A veces responden tres personas.
A veces nadie.
A veces alguien ejecuta, otro aprueba, un tercero debería hacer el seguimiento y el dueño interviene cuando se traba.
Los malos procesos frecuentemente tienen responsabilidades implícitas.
El equipo aprende con la convivencia diaria.
Cuando entra alguien nuevo, pregunta todo.
Cuando alguien se va, se descubre que ciertas decisiones nunca fueron asignadas formalmente.
Un buen diseño necesita dejar en claro:
quién inicia;
quién ejecuta;
quién decide;
quién aprueba;
quién necesita ser informado;
quién responde por el resultado.
La claridad en la responsabilidad reduce la necesidad de una coordinación improvisada.
El proceso atraviesa los departamentos
El cliente no compra “lo comercial”.
Compra una experiencia completa.
La venta pasa a operaciones.
Operaciones depende de compras.
Compras depende de finanzas.
Finanzas necesita la información correcta.
Atención al cliente recibe la consecuencia de errores anteriores.
Cuando cada área optimiza solo su propia etapa, el flujo total puede seguir siendo malo.
El mapeo de procesos es especialmente útil en las transiciones entre áreas.
Es ahí donde aparecen frases como:
“Pensé que ellos lo harían”.
“Eso no es con nosotros”.
“No recibimos esa información”.
“Nadie avisó”.
El organigrama separa los departamentos.
El proceso muestra cómo el valor atraviesa la empresa.
No confundas estandarización con mapeo
Mapear responde:
¿cómo sucede?
Estandarizar responde:
¿qué forma queremos convertir en referencia?
Primero podemos descubrir que existen cinco formas diferentes de ejecutar la misma actividad.
Después decidimos si tiene sentido establecer una forma común.
Esto conecta el mapeo con el desarrollo de un método.
Pero son movimientos diferentes.
Documentar demasiado pronto puede simplemente oficializar un mal proceso.
No automatices solo porque encontraste una tarea manual
Una tarea manual no es automáticamente un desperdicio.
Puede requerir juicio.
Puede ocurrir pocas veces.
Puede ser barata.
Puede cambiar frecuentemente.
Puede depender de un contexto aún no estructurado.
La automatización debe competir con otras mejoras.
Tal vez sea mejor eliminar la tarea.
Simplificar.
Cambiar la regla.
Integrar dos sistemas.
Dar autonomía.
Estandarizar la entrada.
Después, si todavía hay suficiente repetición, volumen y estabilidad, automatizar puede tener mucho sentido.
Este análisis evita transformar la tecnología en una decoración operativa.
Dónde entra la inteligencia artificial
La IA amplía las posibilidades.
Puede ayudar a:
transcribir entrevistas;
organizar evidencias;
clasificar ocurrencias;
analizar documentos;
identificar patrones;
resumir procesos;
consultar conocimiento;
interpretar entradas no estructuradas;
apoyar decisiones con criterios;
ejecutar determinadas etapas.
Pero la IA no debería eliminar la necesidad de comprender la operación.
De hecho, cuanto más poderosa es la automatización, más importante es saber qué es lo que está multiplicando.
El mapeo no debería terminar en un PDF
Uno de los peores destinos para un proyecto de procesos es una carpeta.
Mapas.
Flujos.
Procedimientos.
Presentación.
Todo correcto.
Nada cambió.
El trabajo necesita llegar al día a día.
Tal vez esto exija:
alterar el sistema;
cambiar la responsabilidad;
crear un formulario;
eliminar una aprobación;
integrar herramientas;
capacitar al equipo;
crear un indicador;
revisar una reunión;
automatizar una etapa;
documentar un estándar;
acompañar la adopción.
La entrega no debería ser solo “el proceso fue mapeado”.
Deveria ser:
ahora podemos ver, decidir y mejorar el trabajo con más claridad.
¿Cuándo contratar una consultoría de procesos?
Puede tener sentido cuando:
la operación creció más rápido que la organización;
nadie puede explicar el flujo completo;
los errores y retrabajos se repiten;
las áreas se culpan unas a otras;
muchas decisiones escalan hasta el dueño;
la empresa pretende cambiar de ERP o CRM;
existe un proyecto de automatización o IA;
el onboarding tarda porque todo depende de la explicación oral;
los procesos críticos dependen de pocas personas;
la empresa quiere crecer sin multiplicar la improvisación.
Esto no significa que todo caso exija una consultoría larga.
A veces un diagnóstico corto es suficiente para localizar la prioridad.
Otras veces existe un proceso crítico que merece un trabajo profundo.
El alcance debería seguir al problema.
Cómo evaluar una consultoría de procesos
Antes de contratar, pregunta:
¿Observan la operación real o trabajan solo con entrevistas?
¿Cómo eligen qué procesos priorizar?
¿Cómo registran el AS IS?
¿Cómo identifican los cuellos de botella?
¿Cómo tratan las excepciones?
¿Cómo miden el impacto?
¿Quién participa en el diseño del TO BE?
¿El proyecto incluye la implementación?
¿Cómo entran los sistemas y la automatización?
¿Cómo valida el equipo el nuevo proceso?
¿Qué quedará dentro de la empresa después?
¿Cómo sabremos si hubo una mejora?
El método utilizado importa menos que la capacidad de transformar la realidad en decisión y la decisión en ejecución.
Primero la realidad. Después el diseño. Después el sistema.
Las empresas en crecimiento frecuentemente intentan organizar el futuro sin comprender el presente.
Compran un sistema.
Crean un procedimiento.
Automatizan.
Contratan.
Redistribuyen funciones.
Pero continúan trabajando sobre una imagen incompleta de la operación.
El mapeo de procesos sirve para producir visibilidad.
No porque todo trabajo deba convertirse en un diagrama.
Sino porque aquello que no podemos ver es difícil de mejorar conscientemente.
La secuencia es simple:
entiende cómo funciona hoy;
descubre dónde pierde capacidad;
diseña una forma mejor;
valida con quien ejecuta;
implementa;
mide;
mejora nuevamente.
El proceso ideal no nace de la imaginación.
Nace del confronto entre la realidad, el objetivo y la capacidad.
¿Quieres ver dónde se está trabando tu operación?
Si tu empresa creció, acumuló rutinas, planillas, sistemas, aprobaciones y diferentes maneras de ejecutar el trabajo, podemos empezar mapeando lo que realmente sucede.
No para producir un flujograma bonito.
Sino para identificar:
cuellos de botella;
retrabajo;
espera;
dependencias;
responsabilidades confusas;
riesgos;
conocimiento atrapado;
oportunidades de simplificación;
sistemas y automatizaciones que realmente tienen sentido.
Después del diagnóstico, la intervención puede implicar el rediseño de procesos, estandarización, capacitación, sistemas, automatización o inteligencia artificial.
Primero vemos la operación real. Después decidimos qué merece cambiar.
Jeferson de Lima
Fundador de IGNIS Desarrollo Empresarial
Desarrollo empresarial, liderazgo, equipos, ventas, procesos, sistemas e inteligencia artificial aplicada a los negocios.