1. Lo que podemos aprender del video

El video anterior ilustra numerosos aspectos típicos de una «ilusión de cambio»:

🐢 1. «¡Jefe, hemos malinterpretado la decisión de cambio!»

«Dijeron que debíamos construir una nueva fábrica. Pero nadie nos explicó exactamente qué debía producir la fábrica. Así que simplemente construimos todo lo que se nos ocurrió».

→ Mensaje clave: Cambio ≠ Alcance. Sin directrices concretas, se genera caos.

🎢 2. «¡La montaña rusa era parte del “aumento de la productividad”!»

«Pensamos que si las sardinas se deslizaban más rápido, produciríamos más. Así que construimos una montaña rusa para que las latas pudieran pasar volando más rápido por la nave».

→ Mensaje clave: Cuando se toman decisiones sobre cambios sin requisitos claros, surgen soluciones absurdas.

🏊 3. «¡La piscina era un objetivo de seguridad!»

«El comité directivo dijo que necesitábamos más seguridad. Así que construimos una piscina para que nadie se golpeara con fuerza contra el suelo al caerse de la montaña rusa.»

→ Mensaje clave: Los cambios vagos conducen a resultados que no tienen nada que ver con el objetivo.

🛶 4. «¡Los botes de latas fueron un proyecto de armonización de procesos!»

«Dijeron que debíamos armonizar los procesos. No sabíamos cuáles. Así que convertimos las latas en botes para que todos los empleados tomaran el mismo camino hacia su receso».

→ Mensaje clave: Sin resultados claros, la «armonización» conduce a interpretaciones absurdas.

🐟 5. «¡Las sardinas voladoras eran un objetivo de innovación!»

«Dijeron que debíamos ser innovadores. Así que construimos alas para las sardinas. Ahora vuelan por todos lados y gritan: “¡Caipirinha!”»

→ Mensaje clave: La innovación sin un alcance definido conduce al caos en lugar de al progreso.

🧨 6. «Fuimos desarrollando la decisión de cambio paso a paso… hasta que explotó».

«Dijeron: nueva fábrica. De ahí se derivó: nueva nave → nueva máquina → nuevos procesos → nuevos conceptos de seguridad → nuevas actividades de ocio → nueva satisfacción de los empleados → nueva montaña rusa → nueva piscina → nueva escuela para sardinas voladoras».

→ Mensaje clave: Esa es la «ilusión del cambio»: se desarrolla el cambio, no su alcance.

📦 7. «No teníamos resultados concretos, así que simplemente nos los inventamos».

«Nadie nos dijo qué era lo que realmente debíamos entregar. Así que simplemente entregamos todo lo que se nos ocurrió. Incluso los barcos de sardinas. Y la escuela de vuelo de sardinas. Y los planes de mantenimiento para la montaña rusa».

→ Mensaje clave: Sin resultados definidos, el alcance se sale de control.

Definición:

La «ilusión del cambio» es la suposición errónea de que la decisión de realizar un cambio define automáticamente el alcance del trabajo.

Se produce cuando las organizaciones tratan un cambio de alto nivel («Necesitamos una nueva fábrica», «Necesitamos más seguridad», «Necesitamos armonización») como si ya incluyera los resultados concretos necesarios para su implementación.

Esta ilusión lleva a que los equipos elaboren el cambio por sí mismos —al agregar ideas, interpretaciones y suposiciones— en lugar de definir los resultados reales. Como consecuencia, el esfuerzo se estima en el nivel equivocado, el alcance se sale de control y los proyectos se hunden en el caos.

3. La definición del alcance del proyecto (elaboración del alcance) en lugar de la definición de los servicios (elaboración de los servicios)

El problema con estos talleres es que no se centran en los resultados, sino más bien en el alcance.

3.1. Por qué los talleres «Fit-to-Standard» definen los cambios

A primera vista, los talleres «Fit-to-Standard» parecen ser talleres clásicos de requisitos; sin embargo, desde un punto de vista metodológico, siguen un enfoque completamente diferente. No definen el estado de negocio deseado, sino que analizan en qué medida el estado actual puede adaptarse al estándar de SAP. El enfoque no se centra en la pregunta «¿Qué queremos lograr?», sino en la pregunta: «¿Cómo debemos modificar nuestra situación actual para que se ajuste al estándar?». Esto no describe la situación objetivo, sino el cambio en la situación actual; es decir, un cambio. La discusión gira en torno a variantes de procesos, comportamiento del sistema, opciones de configuración y desviaciones del estándar. Tan pronto como se identifica una brecha, surge automáticamente un cambio: una decisión sobre cómo se debe adaptar la situación actual. Por lo tanto, «Fit-to-Standard» no es una definición de requisitos, sino más bien la elaboración sistemática de los cambios que se derivan de la decisión «Vamos a implementar SAP».

3.2. Por qué los talleres técnicos de RICEFW elaboran cambios

Los talleres técnicos que se ocupan de los objetos RICEFW tampoco abordan requisitos, sino el diseño concreto de los cambios identificados previamente en el proceso «Fit-to-Standard». Un requisito describiría el beneficio comercial que debe ofrecer un informe, una interfaz o un formulario. Sin embargo, en los talleres de RICEFW el enfoque no se centra en el beneficio ni en el estado objetivo, sino en la implementación técnica: campos de datos, tablas, módulos de función, lógica de asignación, puntos de activación y código definido por el usuario. Se trata, por lo tanto, de la elaboración pura y simple de los cambios. Los talleres aclaran cómo se deben implementar técnicamente las decisiones de modificación tomadas previamente. No definen los requisitos de negocios, sino más bien los cambios técnicos en el sistema. Por lo tanto, los talleres de RICEFW son un ejemplo paradigmático de cómo los proyectos de SAP pasan directamente a la fase de implementación sin llegar a formular nunca el estado de negocios deseado.

3.3. Por qué y cómo los talleres elaboran los cambios

Los talleres de migración también suelen parecer sesiones orientadas al negocio, pero incluso ellos se centran en la elaboración de cambios. La migración en sí misma es un cambio: la decisión de modificar el estado actual de los datos para transferirlos al nuevo sistema. Los talleres no definen los requisitos de negocio para los datos, sino más bien cómo deben transformarse los datos existentes para que funcionen en SAP. El enfoque se centra en la asignación, la limpieza, el ajuste estructural y la transferencia técnica. Esto no es una definición de requisitos, sino más bien la elaboración de un cambio que ya se ha establecido en la guía del proyecto: «Migramos nuestros datos a SAP». Los talleres aclaran la implementación de este cambio, no el estado comercial deseado en cuanto a la calidad de los datos o los procesos de datos. Por lo tanto, los talleres de migración también forman parte de la elaboración de cambios, y no de la recopilación de requisitos.

3.4. Por qué los talleres organizacionales concretan los cambios

A primera vista, los talleres organizacionales —que se centran en las estructuras corporativas, las autorizaciones y los conceptos de seguridad— parecen ser de naturaleza estratégica y técnica. Sin embargo, tampoco definen requisitos, sino más bien los cambios estructurales necesarios para poder utilizar SAP en primer lugar. La definición de sociedades, plantas, organizaciones de ventas o perfiles de roles no es una descripción de un estado deseado, sino más bien una decisión sobre cómo se debe representar en el sistema el estado actual de la empresa. Estas decisiones transforman la organización —y, por lo tanto, constituyen cambios—. Los talleres no aclaran qué es lo que la empresa desea lograr desde el punto de vista comercial, sino más bien cómo debe transformarse estructuralmente para poder utilizar SAP. Tampoco en este caso se define el alcance del producto; en cambio, el enfoque se centra en la formulación de la decisión de cambio: «Vamos a implementar SAP». Los resultados derivados de estos cambios estructurales solo se hacen visibles más adelante, en forma de modelos organizacionales, matrices de roles, conceptos de seguridad y configuraciones del sistema.

4. ¿Un proyecto preliminar como solución?

4.1. Por qué es absolutamente necesario realizar una segunda estimación de los recursos necesarios

Solo después de los talleres se obtiene, por primera vez, una visión realista de los cambios reales. Solo en ese momento el proyecto sabe qué adaptaciones de procesos, ampliaciones, interfaces, migraciones de datos y cambios organizativos son realmente necesarios. Sin embargo, la estimación inicial del esfuerzo casi siempre se basa en la decisión de cambio establecida en la carta de compromiso —es decir, en una idea general como «Vamos a implementar SAP» o «Vamos a armonizar los procesos». Esta estimación es inevitablemente imprecisa, ya que no se basa en servicios concretos. Por lo tanto, una segunda estimación de la carga de trabajo no solo sería sensata, sino metodológicamente indispensable: solo después de la fase de talleres se cuenta realmente con la información necesaria para determinar correctamente la carga de trabajo. Sin esta segunda estimación, el proyecto se planifica sobre la base de una ilusión —y se topa con un muro, ya que nunca se evaluaron las prestaciones reales.

4.2. Por qué un anteproyecto sería la única solución sensata

Un anteproyecto lograría precisamente lo que la metodología de SAP omite: crearía el marco. Definiría el estado de negocio deseado, identificaría los resultados, evaluaría los cambios y prepararía la Estructura de Entrega de Resultados (Outcome Delivery Structure). Un anteproyecto sería la etapa en la que se disiparía la «ilusión del cambio» y los resultados se harían visibles. Solo entonces se podría planificar un proyecto de manera adecuada. Sin embargo, en la práctica, este paso casi siempre se omite. En lugar de llevar a cabo un anteproyecto, los participantes se lanzan directamente a los talleres —y, con ello, directamente a la fase de elaboración del cambio—. El proyecto comienza con la solución, incluso antes de que se haya definido el problema. Un anteproyecto sería la respuesta metodológicamente correcta a la «ilusión del cambio», pero rara vez se lleva a cabo, ya que requiere tiempo, dinero y claridad: tres elementos que, en las primeras fases del proyecto, a menudo se perciben como factores «retardadores».

4.3. Por qué se rechaza sistemáticamente esta solución

El rechazo a una segunda estimación de recursos o a un anteproyecto no es una coincidencia, sino un patrón estructural. Las organizaciones buscan decisiones rápidas, presupuestos claros y cronogramas fijos —mucho antes de que quede claro qué es lo que realmente se debe implementar. Una segunda estimación revelaría que la planificación original era poco realista. Un anteproyecto demostraría que la decisión de cambio no se ajusta a los requisitos. Ambas cosas destruirían la ilusión de que el proyecto está «bajo control». Por eso se rechaza la solución metodológicamente correcta: generaría transparencia donde hasta ahora solo reinaba la esperanza. La ilusión del cambio resulta agradable porque transmite la falsa impresión de seguridad en la planificación. La realidad de las tareas que hay que realizar resulta incómoda porque pone de manifiesto el esfuerzo, el riesgo y la complejidad. Precisamente por eso se impide sistemáticamente la solución bien fundamentada.

4.4. Por qué los proyectos sin esta solución fracasan inevitablemente

Si falta la segunda estimación de esfuerzo y no se lleva a cabo un anteproyecto, los planes del proyecto se basan en la «ilusión del cambio». Los cambios se presentan como alcance, aunque el alcance solo existe a nivel de los resultados parciales. El esfuerzo se estima a nivel de los cambios, aunque el esfuerzo se deriva exclusivamente de los resultados. Se subestiman los riesgos, ya que se desconocen los resultados. Se pasan por alto las dependencias, ya que no se ha definido la estructura de entrega de resultados (Outcome Delivery Structure). Y la transición se lleva a cabo de manera caótica, ya que POD → OD solo funciona cuando existen resultados. El proyecto no fracasa porque los participantes hagan un mal trabajo, sino porque la metodología nunca estableció el marco. Sin la segunda estimación y sin un anteproyecto, el proyecto permanece en la oscuridad —y, inevitablemente, se desvía de su rumbo, ya que nunca supo dónde se encontraba realmente el marco.

4.5. Por qué la solución solo funciona cuando los resultados del trabajo se derivan primero de los cambios elaborados

Para que una segunda estimación y una estimación del tiempo requerido puedan funcionar, es necesario insertar un paso entre la elaboración de los cambios y la fase de planificación —un paso que casi siempre falta en los proyectos de SAP—: la derivación de los resultados del trabajo. Solo cuando quede claro qué resultados del trabajo se derivan de los cambios identificados, se podrá evaluar un proyecto de manera realista. Los talleres solo proporcionan las decisiones de cambio —es decir, la descripción de cómo se debe modificar el estado actual—. El esfuerzo, el riesgo y la complejidad no se derivan de la decisión de cambio en sí misma, sino más bien de los entregables que surgen de dicha decisión. Una brecha en el «Fit-to-Standard» no es un elemento del alcance del proyecto, sino una indicación de que se debe generar un resultado. Una ampliación no es un factor de esfuerzo, sino más bien un conjunto de resultados como especificaciones, artefactos de desarrollo, casos de prueba, documentación y autorizaciones operativas. Una migración de datos no es una tarea, sino una variedad de resultados como tablas de asignación, reglas de limpieza, escritos de transformación, pruebas de simulación e informes de aceptación.

Mientras estos resultados no sean visibles, el proyecto avanza a ciegas. La elaboración del cambio solo proporciona la idea del cambio, pero no el trabajo en sí. Solo la derivación de los resultados del trabajo muestra lo que realmente se debe desarrollar, probar, documentar y entregar. Sin este paso, cualquier estimación de esfuerzo es inevitablemente errónea, ya que se basa en una decisión de gobernanza y no en los resultados del trabajo que conforman el alcance del producto. Por lo tanto, la segunda estimación solo puede realizarse una vez que los resultados estén claramente definidos —y no antes—. No se trata de una «corrección» de la primera estimación, sino más bien de la primera estimación realista en absoluto, ya que se basa en la Estructura de Entrega de Resultados y no en la «ilusión del cambio».

Precisamente por esta razón, un anteproyecto sería tan valioso: permitiría deducir los resultados a partir de los cambios antes de que comience el proyecto propiamente dicho. Sin embargo, dado que este paso requiere tiempo, dinero y transparencia, en la práctica suele rechazarse. La empresa exige presupuestos, cronogramas y compromisos desde el principio, aunque aún no se conozcan los resultados. De este modo, se mantiene la «ilusión del cambio»: se planifica un proyecto cuyo alcance nunca se ha definido. Por lo tanto, la solución es obvia: En primer lugar, deduzca los resultados a partir de los cambios elaborados; luego, calcule el esfuerzo y el tiempo necesarios; y solo entonces decida si el proyecto es realmente viable en esta forma.

5. Por qué SAP Activate no toma en cuenta el paso más importante en la planificación del proyecto

5.1. SAP Activate es una metodología de implementación, no una metodología para definir el alcance del proyecto

SAP Activate nunca se diseñó para definir el alcance del negocio. Activate es una metodología de aceleración que parte de la base de que el alcance ya está claro, aunque en realidad esto nunca sea así. La metodología presupone que la empresa sabe lo que desea lograr y que los resultados ya pueden deducirse implícitamente del estándar de SAP. Sin embargo, esto no es cierto. Activate parte de la solución (el estándar de SAP), no del problema (el requisito). Por ello, falta el paso de deducir los resultados: la metodología parte de que el alcance está «anclado en el estándar» y no es necesario hacerlo visible primero. Se trata de un error metodológico que, en la práctica, genera falsas expectativas respecto al alcance.

5.2. SAP Activate se basa en la suposición de que el estándar define el alcance

El núcleo de Activate es el «Fit-to-Standard». Esto supone implícitamente que el estándar de SAP determina el alcance. Si el estándar determina el alcance, en teoría no hay necesidad de derivar resultados de trabajo, ya que el alcance ya estaría definido. Sin embargo, en la realidad, el estándar es solo un punto de partida. Cada desviación genera cambios, y cada cambio da lugar a entregables. Activate omite este paso, ya que la metodología parte de la base de que las desviaciones son mínimas y de que los entregables «surgen por sí solos». Esto es una ilusión. En los proyectos reales surgen cientos de entregables que nunca se nombran, nunca se estiman y nunca se planean. Activate ignora este paso, ya que la metodología sitúa el alcance en la norma —no en el proyecto—.

5.3. SAP Activate evita deliberadamente todo lo que haga visible el esfuerzo

Otra razón es de carácter político: la derivación de resultados revelaría de inmediato la verdadera magnitud del proyecto. Mostraría:

  • cuántas ampliaciones deben desarrollarse
  • cuántos casos de prueba se deben crear
  • cuántos objetos de datos deben migrarse
  • cuántos roles deben definirse
  • cuántos documentos deben crearse

En otras palabras: esto revelaría el esfuerzo real que implica.

Activate omite este paso, ya que destruiría la ilusión de que las implementaciones de SAP son rápidas, ágiles y constituyen «mejores prácticas». La metodología está diseñada para que los proyectos sean «vendibles», no «planificables». La derivación de servicios revelaría la complejidad y, por lo tanto, socavaría la lógica de ventas de la metodología Activate. Por esta razón, este paso se omite sistemáticamente.

5.4. SAP Activate se enfoca en la elaboración de cambios en lugar de en la definición de servicios

El punto más importante es de naturaleza metodológica: «Activate» se centra por completo en la elaboración de cambios.

«Fit-to-Standard» es la elaboración de cambios. Los talleres de RICEFW son la elaboración de cambios. La migración de datos es la elaboración de cambios. La estructura organizativa consiste en la elaboración de cambios.

«Activate» define cómo se modifica el estado actual, pero nunca cómo será el resultado resultante.

La metodología no cuenta con una estructura para la entrega de resultados. No contiene una lista de resultados. No tiene un alcance de producto. Se ocupa exclusivamente de los cambios.

Por eso falta el paso de la derivación de resultados: «Activate» es una metodología que se ocupa exclusivamente de los cambios —y considera que los resultados están «implícitamente presentes», aunque en la realidad deban hacerse visibles en primer lugar.

En resumen:

SAP Activate omite la derivación de resultados, ya que la metodología parte de la base de que el alcance ya está definido en el sistema estándar, que los cambios determinan el volumen de trabajo y que los resultados se derivan de ello de manera natural. Sin embargo, en la realidad esto es incorrecto, y es precisamente por eso que los proyectos de SAP se descarrilan.

Actualización

Este artículo ofrece una introducción simplificada a los conceptos analizados. En la revista Change Illusion Journal se puede consultar una versión ampliada que incluye definiciones formales, la Estructura de Entrega de Resultados (ODS), los Entregables de Transición (TD), el Flujo de Entregables de Transición y el modelo de la «Ilusión del Cambio».

List of terms