En resumen

El control de cambios del alcance del ERP ofrece al promotor una visión global del valor, el coste, las pruebas y el impacto en el lanzamiento antes de aprobar una solicitud. Una vez que el programa ha confirmado una solicitud como cambio, el promotor tiene cuatro opciones: aceptar, aplazar, modificar o rechazar. El director del programa ERP elabora la recomendación en un único documento. El promotor establece los límites de delegación y decide el presupuesto, el plazo y la línea de base revisada por encima de dichos límites.

Cómo las solicitudes de cambio menores en los sistemas ERP provocan una ampliación del alcance

Una vez aprobado el diseño, empiezan a llegar las solicitudes. Parecen cuestiones menores: un nuevo campo en una pantalla, un cambio en el umbral de aprobación, un formato diferente para un informe. Cada una de ellas llega al comité directivo como una necesidad, descrita como algo que requiere unos pocos días de consultoría y que entraña un riesgo bajo.

Un programa puede descontrolarse sin que se haya tomado ninguna decisión importante. Los patrocinadores tienen buenas razones para dar el visto bueno, ya que los solicitantes conocen bien sus operaciones. Negarse puede parecer un obstáculo cuando advierten de que el rendimiento o el cierre de fin de mes se verán afectados. Ese instinto es acertado. La dificultad radica en lo que el patrocinador puede ver en el momento de tomar la decisión.

Efectos operativos y en las pruebas derivados de los cambios en el alcance del sistema ERP

El promotor ve una funcionalidad de software en la página. El programa conlleva una serie de consecuencias. Tomemos una solicitud hipotética. Un cambio de configuración de dos días en la lógica de asignación de existencias puede dar lugar a diez días de desarrollo de scripts personalizados. Puede invalidar treinta escenarios de pruebas de integración de extremo a extremo ya completados. También puede exigir la renegociación de interfaces de terceros y alejar a usuarios clave de la empresa de los ensayos críticos de transición.

Estas cifras describen una solicitud hipotética, no una proporción para ningún otro cambio. Cuando el alcance, el coste, las dependencias de las pruebas y el calendario de lanzamiento figuran en informes distintos, ninguna página por sí sola muestra el efecto global. La línea de referencia acaba variando sin que nadie haya decidido cambiarla.

Retos transfronterizos en la gestión de las solicitudes de cambio en los sistemas ERP

El hecho de que la sede central se encuentre en París, Zúrich, Múnich o Viena suscita preocupaciones legítimas. Se necesitan normas comunes para todo el grupo, una visión global y el cumplimiento del presupuesto acordado con el integrador de sistemas. Además, debe explicarse cualquier desviación ante el Consejo de Administración.

La planta cuenta con un conjunto diferente. Una planta de primer nivel en Polonia, Chequia, Hungría o Rumanía puede abastecer a líneas de montaje de automoción alemanas o a clientes del sector aeroespacial. Esos clientes establecen plazos de entrega secuenciados, auditorías de trazabilidad y normas de embalaje. Es posible que la plantilla global carezca de la lógica de códigos de barras o de los manifiestos de reciclaje de envases que exige un cliente. La planta necesita entonces una respuesta rápida, ya que su fecha de transición está vinculada a los plazos de entrega de los clientes y a los calendarios de producción. Un contratiempo puede suponer tener que esperar hasta la siguiente ventana de trabajo disponible, lo que puede suponer varios días laborables.

Ambas posturas son razonables. La fricción surge cuando el proceso entre ambas es lento. Los equipos de planta buscan entonces soluciones alternativas, como una solicitud informal a un consultor local. Se trata de señales, no de rebeldía.

En el caso de una solicitud transfronteriza, se necesitan tres confirmaciones procedentes de tres organismos distintos. Estos pertenecen a entidades y ordenamientos jurídicos diferentes, y ninguno de ellos puede confirmar por sí solo la totalidad de la solicitud. La sección «Autoridades» indica quién confirma qué.

El integrador responde a las solicitudes que recibe, y la decisión sobre el alcance corresponde al cliente. Para ello es necesario que haya un responsable por parte del cliente con autoridad explícita para introducir cambios. Sin él, el grupo puede acabar pagando dos veces: por personalizaciones no presupuestadas y, posteriormente, por fallos de integración tras la puesta en marcha. La cuestión de si una necesidad local justifica una excepción a la plantilla global es una decisión independiente, que debe tomarse antes que esta.

Indicadores clave de la desviación del alcance en los proyectos de ERP

Los patrocinadores y los comités de auditoría no necesitan leer los registros de configuración para darse cuenta de que el alcance se está desviando. Hay indicios prácticos que muestran que un programa ha perdido el control sobre el cambio.

• Líneas de base no sincronizadas: El integrador, la oficina del programa y la planta disponen de diferentes calendarios maestros.
• Partidas pendientes sin documentar: Los responsables de las líneas de trabajo mantienen listas informales de ajustes de diseño que no llegan al comité directivo.
• Pruebas de regresión repetidas: Las pruebas se reanudan porque se incorporan nuevas mejoras tras la congelación del software.
• Erosión por contingencias: Las órdenes de modificación de los proveedores agotan el presupuesto para imprevistos, mientras que los hitos principales siguen sin completarse.

Un solo indicio puede tener una causa común. Dos juntos justifican una revisión de cómo se introducen los cambios en el programa.

Marco de decisión del patrocinador para las solicitudes de cambio en el sistema ERP

La gestión de las solicitudes de cambio en un sistema ERP parte de una referencia establecida. Este marco da por hecho que el programa ya ha confirmado que se trata de un cambio, y no de un trabajo acordado que queda pendiente. Si el cliente y el socio de implementación siguen sin ponerse de acuerdo sobre cuál de las dos opciones es, deben aclarar primero esa distinción. A continuación, el promotor —o el director del programa, dentro de los límites que se le hayan delegado— dispone de cuatro opciones. Cada una de ellas requiere pruebas diferentes.

Opción 1: Aceptar y financiar las ampliaciones del alcance del ERP

El patrocinador aprueba la incorporación y la financia con cargo al fondo de contingencia. Si las dependencias lo exigen, el patrocinador también amplía por escrito el plazo de pruebas y la fecha de transición. Documentación necesaria: coste por escrito, horas de los usuarios clave internos, pruebas afectadas y fecha en que surtirá efecto. La contrapartida es evidente: el fondo de contingencia que se gaste ahora no podrá cubrir la próxima solicitud.

Opción 2: Aplazar las solicitudes de ERP hasta las versiones posteriores al lanzamiento

El patrocinador acepta el valor y traslada la solicitud a una versión posterior a la puesta en marcha. En el ejemplo que figura a continuación, esto se denomina «Fase 1.1» o «Día dos». La transición se lleva a cabo según la línea de base establecida. Documentación necesaria: una solución provisional específica y la confirmación de que la empresa puede funcionar sin el cambio el día del lanzamiento. La contrapartida es un periodo durante el cual el solicitante debe sortear una deficiencia.

Opción 3: Modificar el alcance del ERP para garantizar las fechas de puesta en marcha

El patrocinador acepta el cambio con una condición: que se elimine de la versión inicial un elemento equivalente ya existente y no crítico. Esto protege la capacidad de prueba y la fecha de lanzamiento. Se requiere evidencia: prueba de que el elemento eliminado es realmente no crítico y el consentimiento de su responsable para aplazarlo. La contrapartida es que una solicitud queda en espera para que otra pueda seguir adelante.

Opción 4: Rechazar las solicitudes de cambio no esenciales en el sistema ERP

El patrocinador rechaza la solicitud porque su valor no justifica el coste, la interrupción de las pruebas ni el riesgo operativo. Un rechazo es una valoración sobre el momento y las consecuencias, no sobre el mérito de la idea. Se necesita justificación: un motivo documentado, para que el solicitante pueda volver tras el lanzamiento con argumentos más sólidos. La disyuntiva es una función que conlleva una brecha y puede minar la confianza en el programa.

Autoridad de aprobación en el control de cambios del ámbito del ERP

El director del programa ERP cuenta con autoridad delegada para el control de cambios. Dicha persona evalúa la viabilidad técnica, las dependencias entre las distintas líneas de trabajo y la disponibilidad de recursos, y a continuación formula sus recomendaciones. El director también debe tener autoridad para suspender las incorporaciones informales al alcance del proyecto y presentar opciones comerciales claras al promotor.

Por encima de los límites delegados, el responsable toma las decisiones que afectan al presupuesto y al calendario. Estas abarcan el capital, el calendario y la fecha de puesta en marcha. Puede tratarse del director financiero del grupo, del director de operaciones del grupo u otro responsable ejecutivo.

Desencadenantes de escalación al patrocinador para cambios en el presupuesto y el calendario del ERP

El control de cambios presupuestarios en el ERP funciona cuando el responsable establece los límites de delegación desde el principio. El momento adecuado para establecerlos es antes de la primera solicitud, no durante una discusión sobre una solicitud posterior. El responsable establece un límite para cada solicitud y un límite acumulativo para imprevistos. Una solicitud dividida para no superar un límite cuenta como una sola solicitud. Estos criterios hacen que la solicitud se envíe directamente al responsable.

• La solicitud modifica la fecha de puesta en marcha u otro hito comprometido.
• Esta solicitud, sumada a las aprobadas hasta ahora, supera el límite de contingencia establecido por el promotor.
• La solicitud modifica un criterio de fase o un diseño aprobado.
• El integrador y el director del programa no se ponen de acuerdo sobre el impacto.

Todo lo que esté por debajo de los umbrales de activación queda a cargo del director del programa, quien lo registra e informa del saldo de contingencia en cada ciclo de dirección.

Funciones de aprobación transfronteriza para las plantas y la sede central del grupo

El director de la planta o el director general confirma que la solicitud es necesaria desde el punto de vista operativo. Unos especialistas cualificados del propio país de la planta confirman el cumplimiento de los requisitos legales. La sede central confirma las normas del grupo y autoriza la inversión.

Unos límites claros benefician a ambas partes. La planta recibe una decisión, o una solicitud de pruebas con fecha, en la primera reunión del comité directivo en la que se examina la solicitud. En el caso de las solicitudes exigidas por el cliente o requeridas por ley, el promotor puede establecer una vía fuera de ciclo y decidir su periodicidad. La sede central consulta cada decisión en un único expediente.

Campos obligatorios para un registro de decisión de cambio en un sistema ERP

El registro de decisiones de cambio ofrece al promotor una página por cada solicitud. Se trata de la herramienta de trabajo para el control de cambios en el alcance del ERP. CE Interim lo propone como una ayuda práctica, no como una norma reconocida. Consta de seis campos.

• Descripción de la solicitud de cambio: qué pide el solicitante y por qué ahora.
• Valor empresarial y justificación operativa: el proceso que protege.
• Coste del proveedor e impacto en los recursos internos: los honorarios externos, las horas de trabajo interno y el saldo de la reserva para imprevistos antes y después.
• Análisis de la dependencia y el efecto en el calendario: las pruebas y las fechas a las que afecta.
• Alcance desplazado o intercambiado: qué sale de la liberación, si es que sale algo.
• Decisión autorizada y situación de referencia actualizada: la persona encargada de la aprobación, la opción elegida y el plan revisado.

El director del programa registra el impacto antes de que el promotor tome una decisión. Posteriormente, el director actualiza el plan vinculado e informa a los centros afectados y al integrador. La aprobación del lanzamiento, el contrato y los criterios de aceptación son decisiones independientes con su propia documentación justificativa. Estas decisiones recaen en el patrocinador o, en caso de que el puesto esté vacante, en la Junta. Cualquier cambio en una fecha acordada por la Junta también debe someterse a esta.

Lista de comprobación para la verificación del patrocinador antes de aprobar cambios en el alcance del ERP

La fiabilidad de un informe depende de la fiabilidad de las cifras que contiene. Un patrocinador con experiencia desconfía de una solicitud que se presenta con una sola estimación, ya que cada parte solo fija el precio de su propia parte.

En primer lugar, hay que determinar qué es lo que no incluye cada estimación: nuevas pruebas, horas de los usuarios clave, responsables de las interfaces y tiempo para el ensayo de la transición. En segundo lugar, recopila en un único documento las cifras del integrador, de la planta y del departamento central de finanzas, para que ninguna de las partes evalúe su propio impacto. Solo entonces plantea la pregunta decisiva: ¿puede la empresa funcionar el día del lanzamiento sin este cambio?

Un paso manual en un proceso no crítico puede seguir siendo imperfecto. Lo mismo ocurre con un informe que está a la espera de su primera publicación. Sin embargo, no debería ser así en el caso de las deficiencias en la facturación, el control de existencias, los envíos a los clientes o el cumplimiento normativo. La única alternativa que queda es la contingencia. Cada aprobación supone un gasto que no permite cubrir la siguiente solicitud, por lo que el patrocinador debe conocer el saldo antes de dar su visto bueno.

Ejemplos prácticos: Evaluación de los cambios en el alcance del ERP en la práctica

Este escenario es hipotético. No se trata de un cliente de CE Interim, y las cifras son meramente ilustrativas, no valores de referencia. Un proveedor del sector de la automoción de propiedad austriaca está implantando la plantilla de ERP del grupo en una planta de Polonia. En un ciclo de gestión, llegan varias solicitudes, todas ellas calificadas como «pequeñas».

Antes de la reunión, el director del programa ERP registra cada solicitud en el registro de decisiones de cambio. El integrador presenta por escrito una evaluación del impacto en los costes, las pruebas y los plazos. La planta y el departamento central de finanzas aportan sus horas internas. El registro ofrece al promotor una forma estructurada de revisar, sopesar y decidir sobre cada cambio propuesto en el ERP. Evita que cualquier modificación del alcance se apruebe sin una visibilidad explícita de los costes, las pruebas y los hitos de entrega.

Ejemplo de aceptación: Reserva automatizada de devoluciones en la línea de producción

La planta quiere que los operarios dejen de introducir manualmente los datos de las devoluciones de chatarra, y la solicitud se ajusta a los criterios básicos.

• Solicitud: Reserva automatizada de devoluciones en la línea de producción.
• Ventaja: Elimina la necesidad de introducir manualmente los datos de devolución de material de desecho; supone un ahorro de 1,5 horas de trabajo administrativo por turno.
• Coste: 18 500 € en concepto de honorarios de un proveedor externo; 45 horas de trabajo interno dedicadas a la configuración por parte de los usuarios clave.
• Pruebas y calendario: Se necesitan 4 días para las pruebas de regresión en el flujo de trabajo de ensamblaje; sin retrasos en la ruta crítica.
• Alcance desplazado: No se requiere; contingencia absorbida.
• Decisión y estado inicial: Aprobado (Aceptar ahora): Presupuesto inicial actualizado; pruebas finalizadas en el Sprint 4.

El director de planta confirma la necesidad. El impacto es limitado: las pruebas se integran en una línea de trabajo con capacidad disponible y la ruta crítica se mantiene. No se cumple ningún criterio de escalado, por lo que el director del programa aprueba el cambio dentro del límite delegado. Se comunica la decisión al promotor. El director actualiza la línea de base e informa de la contingencia restante en el mismo ciclo de dirección.

Ejemplo de Scope Exchange: Panel de control personalizado de KPI para ejecutivos

Los directivos del grupo quieren un panel de control que sustituya a los informes estáticos en hojas de cálculo, y esa necesidad es legítima.

• Solicitud: Panel de control ejecutivo personalizado de indicadores clave de rendimiento (KPI).
• Valor: Sustituye a los informes estáticos en hojas de cálculo para el equipo directivo del grupo.
• Coste: 34 000 € en desarrollo de proveedores; 30 horas de revisión de los informes financieros centrales.
• Pruebas y calendario: Alta complejidad; distrae a los arquitectos de informes principales durante las pruebas de aceptación del usuario.
• Ámbito de aplicación modificado: aplazar los informes de resumen de centros de coste no críticos hasta el segundo día.
• Decisión y situación de partida: Alcance modificado: Aprobado para su lanzamiento inicial; los informes resumidos se aplazan hasta la Fase 1.1.

La sede central tiene una necesidad real en este sentido: una visibilidad fiable de la planta. El coste va más allá de los honorarios del proveedor, ya que las pruebas de aceptación requieren a los mismos arquitectos de informes. Aplazar los informes resumidos aprobados modifica un diseño ya aprobado, lo que da lugar a una escalación. El patrocinador registra el consentimiento por escrito del responsable del informe respecto al aplazamiento y, a continuación, realiza un intercambio en lugar de una adición. El panel de control se incorpora a la versión inicial.

Ejemplo de aplazamiento: trazabilidad de palés específica para cada cliente

Un distribuidor regional tiene unas necesidades logísticas que se salen de lo habitual, y la relación comercial es importante.

• Solicitud: Trazabilidad de palés específica para cada cliente.
• Valor: Atiende una solicitud logística no estándar para un único distribuidor regional.
• Coste: 26 000 € en concepto de comisión del proveedor; lógica personalizada y exhaustiva en el módulo de gestión de almacén.
• Pruebas y calendario: retrasa la aprobación de la integración de la gestión de almacenes en 12 días laborables.
• Ámbito no cubierto: El equipo de trabajo solicitante no ha identificado ninguno.
• Decisión y situación inicial: Aplazado a la fase 1.1: Implementado 60 días después del lanzamiento; inicialmente se utilizó un registro de empaquetado manual.

El retraso afecta a un hito comprometido, lo que activa un proceso de escalación, y la línea de trabajo solicitante no tiene margen para ceder. El director de la planta confirma que el distribuidor necesita un proceso operativo desde el primer día. Un registro manual lo proporciona. El patrocinador aplaza la solicitud, designa al responsable del almacén como encargado del registro y fija una fecha de revisión.

Ejemplo de rechazo: facturación automática mediante autofacturación de proveedores

El departamento de finanzas quiere agilizar la conciliación de facturas en toda la cadena de suministro, y las ventajas son evidentes.

• Solicitud: Facturación automática mediante autofacturación de proveedores.
• Valor: Acelera la conciliación de facturas de la contabilidad de acreedores en toda la red de proveedores europea.
• Coste: 52 000 € en desarrollo por parte del proveedor; reconfiguración significativa de la interfaz EDI.
• Pruebas y calendario: Modifica las normas básicas de contabilización; pone en peligro el plazo previsto para la transición del sistema financiero principal.
• Ámbito desplazado: Ninguna; el equipo solicitante no está dispuesto a modificar el alcance.
• Decisión y situación inicial: Rechazado: alto riesgo de cumplimiento de plazos; se mantiene la conciliación de órdenes de compra estándar para la puesta en marcha.

La decisión se basa en el riesgo de incumplimiento de plazos, no en el mérito. La solicitud modifica las normas básicas de contabilización financiera, lo que altera un diseño ya aprobado y da lugar a una escalación. El equipo solicitante no modificará el alcance. El promotor mantiene la correspondencia estándar para la puesta en marcha y deja constancia del motivo. La autofacturación también afecta a las normas de facturación, que varían según el país. Los especialistas cualificados en Polonia confirman lo que permiten las normas antes de que se vuelva a plantear la idea.

Conclusiones clave de los ejemplos de cambios en el alcance del ERP

El mismo registro generó respuestas diferentes a solicitudes que parecían similares, y ninguna de ellas supuso una paralización generalizada. Se trata de patrones en este escenario, no de reglas. La solicitud aceptada tuvo un efecto limitado y la ruta crítica se mantuvo. El intercambio funcionó porque la capacidad de prueba era la limitación y un elemento no crítico contaba con un responsable dispuesto a hacerse cargo. El aplazamiento funcionó porque el negocio podía seguir funcionando gracias a una solución alternativa concreta. El rechazo se debió a un alto riesgo en el calendario, sin margen para hacer concesiones.

La planta recibió una respuesta motivada a cada solicitud, incluidas aquellas que no fueron aceptadas. La solicitud aceptada se financió con fondos de contingencia, por lo que la siguiente solicitud cuenta con una reserva menor. El grupo mantiene una referencia que puede justificar.

Cómo abordar las deficiencias de gobernanza en el control de cambios del alcance de los sistemas ERP

Una autoridad interna competente puede encargarse del control de los cambios en el alcance del ERP, con límites delegados y una vía de recurso ante el patrocinador. El patrocinador, o el Consejo de Administración en caso de que el puesto esté vacante, puede contrastar dicha situación con las condiciones recogidas en el expediente del programa.

• Ningún directivo del lado del cliente se encarga a la vez del presupuesto, del plan de pruebas y del plan de transición, por lo que cada uno de estos aspectos se decide en foros distintos.
• El director del programa no puede suspender las ampliaciones informales del alcance, ya que nadie le ha otorgado esa autoridad por escrito.
• El puesto de patrocinador está vacante, o bien el patrocinador se encarga de dirigir la empresa, por lo que las solicitudes quedan pendientes más allá de un ciclo de coordinación.
• Las cifras de impacto facilitadas por el integrador, la planta y el departamento financiero siguen sin coincidir, y nadie tiene la autoridad necesaria para zanjar la cuestión.

Cuando se dan dos o más de estas circunstancias, el programa ya no decide sobre las solicitudes basándose en un único registro. En ese caso, el grupo corre el riesgo de pagar dos veces o de modificar la fecha de la Junta de forma automática. A juicio de CE Interim, el programa conlleva entonces un riesgo crítico para la empresa y necesita un responsable por parte del cliente con autoridad ejecutiva. Una fecha límite por sí sola no es motivo suficiente para nombrar a un ejecutivo interino.

El papel de un director interino de transformación en la gobernanza de los sistemas ERP

En Director interino de Transformación y Programas puede ostentar la autoridad para realizar cambios por parte del cliente. El cargo toma decisiones dentro de los límites de una delegación por escrito. Rinde cuentas ante quien se la haya otorgado: el promotor o el Consejo de Administración, en caso de que el puesto esté vacante. No es ni el director de proyecto del integrador ni un asesor que se limite a formular recomendaciones.

El mandato establece límites de delegación, que se fijan una vez que los datos figuran en un único registro. Designa al ejecutivo interino como único responsable del plan por parte del cliente. Establece una vía de escalación y acuerda la devolución del asunto a un responsable designado. El ejecutivo presenta al responsable de la toma de decisiones la confirmación de la necesidad por parte de la planta, la confirmación legal local y la autorización de capital de la sede central, todo ello de forma conjunta.

Los socios interinos de CE revisan la calidad del registro de cambios y prestan apoyo en caso de que sea necesario elevar el asunto a un nivel superior. Proporcionan al responsable de delegar la autoridad información sobre el progreso con la periodicidad acordada y supervisan la devolución de responsabilidades.

Definición del mandato provisional para la supervisión ejecutiva

Si el puesto de director está vacante o carece de autorización por escrito, el ejecutivo interino lo ocupará durante el mandato. Lo mismo se aplica cuando dicho puesto se encuentra dentro del departamento de integración o de TI.

Cuando hay un director competente, pero la vacante se produce a nivel del patrocinador, el mandato recae por encima del director. Si el puesto de patrocinador está vacante, el Consejo designa a la persona encargada de tomar las decisiones reservadas antes de que comience el mandato. Estas abarcan el capital que supera los límites, el calendario y la fecha de puesta en marcha. Un Interim CFO o Interim COO puede mantenerlos dentro de los límites que establezca la Junta.

El orden es importante. En primer lugar, el ejecutivo consolida en un único registro las cifras de impacto del integrador, de la planta y del departamento financiero. El ejecutivo también incluye en él la cartera de pedidos informal, con autoridad para suspender nuevas incorporaciones informales. A continuación, el patrocinador —o el Consejo de Administración, en caso de que el puesto esté vacante— establece los límites de delegación sobre esa base. Solo entonces el ejecutivo pone en marcha el ciclo de dirección, con la fecha de devolución acordada desde el principio.

El nombramiento no modifica el contrato de ejecución, no exime del cumplimiento de los criterios de aceptación ni autoriza el lanzamiento. Estas competencias siguen recayendo en el promotor o, en caso de que el puesto esté vacante, en la Junta. Cualquier modificación de una fecha acordada por la Junta también debe someterse a esta.

Publicación de directrices sobre la gestión del alcance de los sistemas de planificación de recursos empresariales (ERP)

Hay dos fuentes publicadas que respaldan el principio de controlar el alcance. Las directrices de Dynamics 365 de Microsoft describen los paneles de diseño que revisar y aprobar diseños de soluciones. Afirma que los equipos deben respetar los criterios de las fases de control, sin saltárselos "por presión o por optimismo".

El proveedor de servicios de ERP Atreus informa de un retraso en la implantación del sistema ERP de posventa que se estabilizó. Se replanificaron el alcance, el presupuesto y las fases, y se definieron las funciones y responsabilidades de las áreas de negocio, TI y socios. Ninguna de las dos fuentes describe este registro ni señala un único cambio como causa. El informe de Atreus es un informe del proveedor, no una auditoría independiente.

Preguntas frecuentes sobre el control de cambios en el alcance de los sistemas ERP

¿Deberían congelarse los cambios en el alcance del ERP cuando se acerca la puesta en marcha?

No es una regla general. Una congelación puede impedir que la empresa siga funcionando. Un cambio que cumpla un requisito legal o proteja un proceso crítico tiene argumentos de peso para ser aceptado. Los especialistas del país donde se encuentra la planta deben confirmar que el requisito es real. Las mejoras no esenciales pueden esperar a una versión posterior.

¿Quién aprueba los cambios en el marco del control de cambios del ERP?

El director del programa ERP aprueba las solicitudes dentro de los límites que se le han delegado y las registra. Una solicitud que cumpla un criterio de activación se remite al patrocinador ejecutivo, quien decide el presupuesto, el calendario y la fecha de puesta en marcha. El patrocinador también resuelve cualquier desacuerdo entre el integrador y el director del programa en relación con el impacto.

¿Sustituye un ejecutivo interino al director del programa ERP?

No de forma predeterminada. Un director competente que cuente con autoridad por escrito conserva el cargo. Cuando lo ocupa un ejecutivo interino, el mandato establece la línea jerárquica y los límites de la delegación de competencias. Asimismo, fija desde el principio una fecha de traspaso. Las decisiones relativas al contrato, la aceptación y la puesta en marcha siguen siendo competencia del promotor o, en caso de que el puesto esté vacante, del Consejo de Administración.

¿Qué ocurre con la fecha de puesta en marcha acordada cuando se aprueba un cambio en el sistema ERP?

El patrocinador vuelve a establecer por escrito las bases de referencia del programa: calendario maestro, fechas de las etapas y controles, planes de pruebas de integración y presupuesto. A continuación, el director del programa informa a todos los centros y proveedores afectados. En los casos en que la Junta Directiva haya fijado la fecha original, el patrocinador presenta primero la nueva fecha a la Junta Directiva.

Conocimientos relacionados y siguiente paso

El control de cambios en el alcance del ERP protege la línea base cuando cada solicitud conlleva su coste, prueba y fecha de efecto en una única decisión. Una solicitud aprobada sin ese efecto puede pasar a la fase de puesta en marcha antes de que la Junta haya acordado una nueva fecha. El patrocinador, o la Junta en caso de que el puesto esté vacante, comprueba en primer lugar las condiciones anteriores con respecto al registro del programa. El siguiente paso consiste en definir los límites de delegación y determinar si la discrepancia se sitúa a nivel del programa o del patrocinador.

Lecturas relacionadas:

• El cierre de una planta estadounidense desde Alemania: el responsable provisional de la planta que lo logró en seis meses
• Un proveedor abastece a varias plantas de Europa Central y Oriental. ¿Cómo se debe distribuir el material disponible, que es limitado?
• Por qué un objetivo de costes de fabricación no equivale a un rediseño del modelo operativo

CE Interim ofrece liderazgo ejecutivo transfronterizo para transformaciones empresariales cruciales. Una vez completado el pliego de condiciones, un ejecutivo previamente seleccionado, adecuado para el encargo y sujeto a un acuerdo de confidencialidad, está listo para empezar.

Si se dan dos o más de las condiciones anteriores, consulta con un Socio interino de CE sobre el mandato.