Es decir, comprender la situación actual es fundamental para definir la situación futura. Hace poco participaba en un proyecto con alta carga de transformación en la manera de trabajar y, como suele pasar, la primera reunión estuvo llena de energía: visión, objetivos ambiciosos, grandes palabras y un diagrama bonito del «estado futuro» en la pizarra. Había esbozados el cómo asrían en el futuro algunos procesos (gracias a una herramienta que se iba a implementar) sin tener en cuenta cómo funcionaban realmente los procesos hoy. Y no es la primera vez que lo veo: la tentación de saltar directamente al to-be es enorme, porque diseñar el futuro es mucho más ilusionante que documentar el presente. Incluso en la reunión se comentó que no se necesitaba conocer como se trabajaba hoy, porque total, no íbamos a seguir trabajando así.
El problema es que un to-be sin un as-is sólido, es casi un acto de fe.
Por qué nos saltamos el as-is
Entender cómo funcionan realmente los procesos (no cómo dice el manual que funcionan, sino cómo los ejecutan de verdad las personas cada día) es un trabajo poco vistoso. Requiere entrevistar, observar, contrastar versiones distintas de la misma historia y, muchas veces, incomodar a alguien al señalar una ineficiencia que llevaba años ahí. Frente a eso, dibujar el futuro deseado es fácil, gratificante y no genera fricción con nadie. El papel lo aguanta casi todo. Por eso muchas organizaciones, presionadas por plazos y por la necesidad de mostrar avance, se lanzan a especificar el to-be sin haber cerrado el as-is.
El resultado es previsible: se diseña una solución elegante para un problema que no es exactamente el que existe. Se automatizan excepciones que en realidad eran la regla. Se elimina un paso «innecesario» que, sin que nadie lo documentara, era el que absorbía todos los casos extraordinarios. El nuevo proceso funciona perfecto en la demo y se rompe en la primera semana de producción real con el consiguiente malestar y tensión de las personas que lo ejecutan.
El factor humano, la parte que casi nunca aparece en el diagrama
Aquí es donde más veces he visto fallar las transformaciones: el as-is no es solo el flujo de actividades, es también quién lo ejecuta, por qué lo hace así y qué le costaría dejar de hacerlo.
Cada proceso real está lleno de ajustes informales que las personas han ido incorporando para que las cosas funcionen: la hoja de Excel paralela que nadie reconoce oficialmente, la llamada de teléfono que evita un cuello de botella en el sistema, el criterio no escrito que aplica la persona con más experiencia del equipo. Ese conocimiento tácito rara vez está en ningún manual de procedimientos, y sin embargo sostiene buena parte de la operación. Si no lo capturamos al levantar el as-is, lo perdemos al diseñar el to-be, y con él perdemos resiliencia.
Además, las personas que ejecutan el proceso hoy son, casi siempre, las mismas que tendrán que adoptar el proceso de mañana. Si no han participado en describir cómo trabajan realmente, es difícil que sientan como propio el estado futuro que otros han diseñado sobre ellas. La resistencia al cambio que tantas veces se atribuye a «cultura» o a «falta de compromiso» tiene, en muchos casos, un origen mucho más simple: nadie les preguntó cómo era su día a día antes de decidir cambiarlo.
Qué pasa cuando falta uno de los dos extremos
- Sin as-is claro: se diseñan soluciones para un problema mal entendido, se subestima el esfuerzo de migración, aparecen «sorpresas» a mitad de proyecto que en realidad eran previsibles, y se generan procesos en la sombra porque el sistema nuevo no contempla casos que en la práctica eran habituales.
- Sin to-be claro: el levantamiento del estado actual se convierte en un ejercicio interminable de documentación sin propósito, se pierde el foco en qué mejorar y para qué, y la organización acaba invirtiendo esfuerzo en describir con detalle procesos que ni siquiera merece la pena conservar.
Ambos extremos son igual de peligrosos. El as-is sin rumbo es arqueología; el to-be sin cimientos es ciencia ficción.
¿Es realmente necesario?
¿Podemos conducir a un destino, sin saber de qué punto partimos? El tener los procesos as-is, nos proporciona una ventaja indiscutible tanto para gestionar el plan de implementación y su ejecución, como para la gestión del cambio. Algunas ventajas son:
- Diagnóstico realista: Sin entender el estado actual, no puedes identificar con precisión los dolores, cuellos de botella, ineficiencias, duplicidades, riesgos o desperdicios. Diseñar un To Be sin este conocimiento suele generar soluciones que parecen bonitas en papel, pero que fracasan en la implementación.
- Base de medición: El As Is te da el baseline (punto de partida) para definir KPIs claros y medir el impacto real de la transformación. ¿Cómo sabrás si mejoraste si no sabes de dónde partías?
- Aprovechar lo que ya funciona: Muchas veces hay procesos, controles o prácticas que sí son efectivos. Un buen To Be evoluciona lo bueno y elimina o rediseña lo malo. Ignorar el As Is genera riesgo de “tirar al bebé con el agua sucia”.
- Gestión del cambio y buy-in: Las personas que operan los procesos actuales conocen mejor que nadie las realidades del día a día. Involucrarlas en el análisis del As Is genera confianza y reduce resistencia al cambio.
- Identificación de restricciones: Tecnológicas, regulatorias, culturales, de recursos o contractuales que limitan las opciones del To Be.
Si es cierto que en algunos casos, se puede decir que es menos necesario (nunca indispensable). Algunas de estas excepciones podrían ser:
- Transformaciones radicales o greenfield: Cuando se crea un nuevo negocio, línea de producto o modelo operativo completamente nuevo. Por ejemplo una startup digital nativa o una escisión de negocio.
- Reinvención disruptiva: En casos donde el as-is está tan obsoleto o roto que seguir analizándolo genera “parálisis por análisis”.
- Mandato de alto nivel muy agresivo: Cuando la dirección decide un cambio drástico como la adopción obligatoria de una nueva plataforma ERP y prioriza velocidad sobre optimización fina.
Pero incluso en estos casos, tener un nivel de análisis as-is (aunque sea ligero) nos dará ventaja.
Siendo pragmáticos, el nivel de profundidad del as-is debe ser proporcional al alcance del proyecto:
– Proyectos pequeños o muy focalizados → Análisis ligero (entrevistas clave + mapeo de alto nivel).
– Transformaciones grandes o complejas → Análisis profundo (mapeo detallado, medición de tiempos/costos, análisis de variabilidad, voice of customer, etc.).
Como regla de oro, podemos decir que cuanto más ambicioso sea el to-be (digitalización, automatización, cambio de modelo operativo), más crítico es el entendimiento profundo del as-is.
Cómo lo he visto funcionar bien
Las transformaciones que mejor he visto avanzar comparten un patrón: dedican tiempo real (no un par de talleres exprés) a entender el estado actual, e involucran en ese ejercicio a quienes ejecutan el proceso, no solo a quienes lo supervisan. El objetivo no es producir un documento perfecto de doscientas páginas, sino generar un entendimiento compartido, suficientemente honesto, de qué funciona, qué no, y por qué las cosas son como son hoy.
Solo con esa base tiene sentido preguntarse hacia dónde queremos ir y cómo hacerlo. Y cuando llega el momento de diseñar el to-be, conviene seguir contando con esas mismas personas: no como validadores de un diseño ya cerrado, sino como parte del equipo que ayuda a construirlo. El cambio se adopta mucho mejor cuando quien lo va a vivir ha tenido voz en cómo se ha planteado.
Tener el mapa antes de trazar la ruta
Al final, pensar en el to-be sin conocer el as-is es como planificar una ruta de montaña sin saber desde qué punto se sale. Puedes tener clarísimo el destino, pero si no sabes dónde estás, cualquier camino que traces será, en el mejor de los casos, una suposición con suerte. Conocer el terreno, con sus atajos informales, sus zonas pantanosas y la gente que ya sabe por dónde no hay que pasar, es lo que convierte un buen propósito en un plan que realmente se puede ejecutar.
Conocer el as-is no es un paso burocrático, es la base de una transformación exitosa. Saltárselo es una de las causas más comunes de fracaso en proyectos de rediseño de procesos y transformaciones de negocio.