El paso que todos quieren saltarse

Cuando empiezas un proyecto de mejora, hay un momento incómodo.

Tienes el problema encima de la mesa, tienes ideas de cómo resolverlo, y alguien te dice: primero hay que documentar cómo funciona todo ahora.

Y la reacción natural es resistirse. Ya sé cómo funciona. Ya entiendo el problema. Vamos a la solución.

Ese impulso es el error más común — y el más costoso — en cualquier proyecto de transformación operativa. Lo vi en el máster, lo viví en empresas reales, y lo entiendo: documentar el estado actual se siente como tiempo perdido cuando ya tienes la respuesta en la cabeza.

# Lo que dice el proceso — y lo que dice la persona que lo vive

Mi profesor de mejora de procesos en la Universidad Politécnica de Valencia nos repetía algo en cada clase: la entrevista del AS-IS es para entender qué se hace y por qué se hace. No para buscar soluciones.

Pero añadía algo importante: en esas entrevistas, las personas que están en el proceso van a darte ideas. Van a decirte 'esto podría hacerse así' o 'siempre pensé que sería mejor si...' Esas ideas hay que anotarlas. No para implementarlas inmediatamente — sino porque vienen de quien conoce el problema de verdad. Son oro. Solo que todavía no sabes si encajan en la solución correcta.

Eso cambia completamente la forma de hacer una entrevista de análisis. No vas a confirmar lo que ya crees. Vas a escuchar lo que todavía no sabes.

# Lo que encontré cuando escuché primero

Cuando hice el análisis AS-IS para una empresa confidencial de reciclaje de plástico en Venezuela, la primera reunión fue con la gerencia general. No llegué con hipótesis. Llegué con preguntas: ¿qué está pasando?, ¿qué les duele?, ¿qué no les gusta?

La palabra que más se repitió en esa primera conversación fue trazabilidad. No la tenían. Y al principio parecía un problema técnico — un problema de registros, de datos, de sistema.

Pero al hacer el análisis completo del proceso, apareció algo que no esperaba: la empresa creía que tenía seis procesos distintos, uno por cada tipo de materia prima que procesaban. Eso los hacía sentir que el control era enormemente complejo — había que gestionar seis flujos diferentes, con sus propias reglas, sus propios responsables, sus propias métricas.

Lo que el AS-IS reveló es que en realidad tenían un solo proceso. La diferencia era el punto de entrada: dependiendo del tipo de materia prima, ingresaba en una etapa distinta del flujo. Un plástico sucio entraba en el primer paso — preselección, lavado, y seguía adelante. Un material post-industrial limpio saltaba directamente al quinto paso, que era la trituración para hacer pellets. Mismo proceso, entradas distintas.

Ese hallazgo cambió todo el diseño de la solución. Si hubiéramos llegado con la respuesta ya armada, habríamos diseñado seis flujos separados. Habríamos resuelto el problema equivocado.

# La solución que yo no habría elegido

Hay algo que quiero decir con honestidad sobre ese proyecto, aunque sea incómodo: la solución que se implementó — un ERP conocido a nivel internacional — no era la que yo habría elegido si la decisión hubiera sido solo mía.

No porque sea una mala herramienta. Es excelente. Pero en ese momento yo estaba construyendo mi propio sistema de gestión para una empresa 3PL, y veía claramente que una herramienta a medida, diseñada exactamente para el flujo de esa empresa de reciclaje, hubiera sido más eficiente para su operación actual.

La gerencia, sin embargo, tenía una razón estratégica para elegir el ERP conocido: en el futuro, si querían vender la empresa o buscar inversión, tener un sistema reconocido internacionalmente les daba credibilidad. Era una decisión de negocio, no solo operativa.

Y ahí está otra lección del AS-IS: cuando entiendes el proceso completo, también entiendes el contexto en el que vive. Las decisiones no son solo técnicas. Son financieras, humanas, estratégicas. Y si no hiciste el análisis, no tienes ese contexto. Solo tienes tu solución favorita.

# Diseñar para quien lo va a usar — no para quien lo entiende

Cuando construí el sistema logístico para la empresa 3PL donde trabajo, no hice un AS-IS formal con entrevistas estructuradas. Lo viví. Era mi operación. Conocía cada punto de dolor porque lo sentía todos los días.

Pero sí hice algo que tiene el mismo espíritu: antes de diseñar cualquier módulo, me pregunté cómo se hacía ese proceso, por qué se hacía así, y qué era lo que realmente importaba capturar. La diferencia es que las respuestas las tenía yo mismo.

Y lo que guió cada decisión de diseño fue una pregunta que aprendí de un amigo ingeniero electrónico, hace años, mientras hacíamos un montaje juntos. Él terminaba los conexionados rápido y yo le pregunté cómo sabía tan fácilmente qué iba donde. Me dijo: 'Estos conectores son para bobo. No hay dos maneras de conectarlos.'

Me quedé pensando en eso. Un diseño donde el error es imposible no necesita instrucciones. Se entiende solo.

Cuando el sistema logístico estuvo funcionando, llamé a mi madre para probarlo. Ella es educadora — no tiene nada que ver con ingeniería ni logística. Le expliqué en diez minutos cómo funcionaba y luego le pedí que hiciera una tarea: crear una pre-alerta con datos inventados. La hizo. Le pedí que recibiera el ticket. Lo hizo. En diez minutos, sin contexto técnico, completó una operación completa.

Eso era lo que buscaba. No un sistema que los ingenieros entendieran — un sistema que cualquier persona pudiera usar después de una explicación corta. Porque si necesitas que yo esté presente para que funcione, no es un buen sistema. Es una dependencia.

# A quién le hablo con este artículo