Un responsable de operaciones solicita modificar el flujo de liberación de pedidos. La solución propuesta es una extensión a medida, pero la solicitud de aprobación no indica si el ERP actual puede satisfacer el requisito mediante configuración, si conviene cambiar el propio proceso o quién mantendrá la extensión después de su despliegue.
Apruebe el requisito de negocio antes de aprobar el método de implementación. La personalización no es, por naturaleza, ni un gasto innecesario ni una inversión estratégica. Autorícela cuando una necesidad operativa documentada justifique las obligaciones continuas de responsabilidad, interfaces, pruebas y soporte. De lo contrario, adopte el proceso estándar, configure las funcionalidades disponibles o evalúe una aplicación externa.
Esta decisión corresponde a una solicitud de cambio concreta. Si el análisis revela que la plataforma no puede satisfacer requisitos fundamentales del negocio, utilice el marco para decidir entre mejorar o sustituir el ERP antes de considerar que añadir extensiones sucesivas es la respuesta.
Determine qué resultado no permite obtener el proceso estándar
Empiece la solicitud por el resultado esperado, no por el diseño de una pantalla. «Reproducir la antigua pantalla de aprobación» prescribe una solución. «Impedir la liberación hasta que el responsable de operaciones haya aceptado el requisito de manipulación específico del cliente» define un control de negocio que distintos diseños podrían satisfacer.
En un webinario sobre soberanía digital del ERP, los ponentes de SoftEngine rechazan las críticas indiscriminadas a la personalización y sostienen que los procesos complejos pueden requerir adaptaciones específicas. También cuestionan la reproducción automática de los flujos existentes: primero hay que determinar si un proceso sigue siendo necesario y, después, si las funcionalidades estándar pueden cubrirlo.
Para quien aprueba el cambio, la consecuencia práctica es exigir una demostración de la alternativa estándar propuesta. Pida al consultor funcional y al responsable del proceso que ejecuten el caso de negocio real, incluidas las excepciones. Una respuesta convincente identifica con precisión el control o el resultado que falta. «Los usuarios prefieren la forma anterior de trabajar» no constituye una prueba equivalente, aunque sí merece consideración un problema de usabilidad demostrado que impida ejecutar el proceso de forma fiable.
Documente por qué importa el requisito: una obligación contractual, una restricción operativa, un control necesario o una capacidad de servicio comercialmente relevante. No todos los cambios justificados tienen que diferenciar al negocio. Si el proceso estándar permite obtener el resultado, apruebe el ajuste del proceso y la preparación de los usuarios en lugar de reconstruir un funcionamiento conocido. Si no lo permite, documente esa carencia con suficiente precisión para orientar la siguiente decisión de diseño.
Compare las opciones de implementación frente al mismo requisito
Utilice el mismo escenario de aceptación para todas las opciones. De lo contrario, podría evaluar una demostración de configuración frente al flujo completo y aceptar un prototipo a medida tras ver únicamente su función más atractiva. Considere las opciones siguientes como alternativas que deben analizarse, no como una clasificación universal de preferencias.
| Opción | Cuándo considerarla | Pruebas que debe solicitar |
|---|---|---|
| Adoptar el proceso estándar | El resultado puede lograrse cambiando la forma de trabajar. | Una demostración realista del flujo y la aceptación de las diferencias por parte del responsable del proceso. |
| Configurar las funcionalidades disponibles | Los ajustes, las reglas o las funciones de flujo de trabajo existentes parecen satisfacer el requisito. | El diseño de configuración, sus límites y las condiciones de soporte aplicables al producto. |
| Integrar una aplicación externa | Una aplicación independiente merece ser evaluada por la capacidad requerida. | Acceso a las interfaces, responsabilidad sobre las transacciones, gestión de excepciones y condiciones comerciales recurrentes. |
| Autorizar un desarrollo a medida | Persiste una carencia relevante y la extensión propuesta dispone de un plan de ciclo de vida aceptable. | Un diseño acotado, un mecanismo de extensión con soporte, un responsable del mantenimiento y pruebas de regresión. |
Defina expresamente la terminología en la propuesta. La explicación de Oracle ERP-ACE describe la configuración como el uso de funciones estándar para controlar el comportamiento de la aplicación y afirma que la configuración «siempre es segura ante las actualizaciones». Trátelo como una caracterización de Oracle, no como una garantía contractual para su instalación ni como prueba de que una integración recibe la misma protección. Pregunte qué producto, versión, modelo de despliegue y mecanismo utiliza realmente el cambio propuesto.
La conversación sobre transformación empresarial plantea un argumento arquitectónico más firme: evitar la acumulación de deuda técnica en áreas que no aportan diferenciación y decidir con cuidado dónde debe residir esa diferenciación. Su análisis del enfoque clean core utiliza SAP como ejemplo y favorece una estrategia orientada a aplicaciones frente a añadir código a medida. Al aprobar un cambio, utilice esa opinión para cuestionar el desarrollo innecesario, no para asumir que todos los productos ERP tienen las mismas reglas de extensión.
Una aplicación externa debe someterse al mismo examen que una extensión interna. Pregunte por qué su capacidad justifica la interfaz adicional, las responsabilidades operativas y la dependencia comercial. Del mismo modo, no rechace una extensión a medida bien acotada solo porque exista otra aplicación. Compare diseños completos frente al mismo resultado.
Complete la ficha de aprobación del cambio
La siguiente ficha es una herramienta editorial de apoyo a la decisión, no un estándar de arquitectura validado por las fuentes. Adjúntela a la solicitud de cambio y asigne una persona responsable a los asuntos pendientes. La aprobación debe describir tanto la implementación como las responsabilidades continuas que se aceptan.
| Pregunta para la aprobación | Documentación que debe adjuntarse | Motivo para detener la aprobación |
|---|---|---|
| ¿Qué resultado no puede obtenerse con el proceso estándar? | Requisito de negocio, escenario estándar que no lo satisface y consecuencias de dejar la carencia sin resolver. | La justificación solo describe una pantalla preferida o una costumbre heredada. |
| ¿Por qué se elige esta opción de implementación? | Comparación entre cambio de proceso, configuración, integración y desarrollo a medida. | Las alternativas se descartaron sin probar el requisito. |
| ¿Quién se responsabiliza de la extensión? | Responsable de negocio, responsable del mantenimiento técnico, acceso al repositorio y derechos de uso y modificación acordados. | La responsabilidad se limita a saber a quién llamar. |
| ¿Qué interfaces y datos necesita? | Inventario de interfaces, derechos de acceso, permisos, límites de las transacciones y cargos aplicables. | «Existe una API» sustituye a la comprobación de las operaciones necesarias. |
| ¿Cómo se probarán las actualizaciones? | Escenarios de regresión, entorno de pruebas, responsabilidades de publicación y procedimiento de recuperación. | Las pruebas terminan con la instalación o la entrega del mensaje. |
| ¿Qué trabajo continuo debe financiarse? | Tareas de mantenimiento, responsabilidades de soporte, esfuerzo de pruebas y conceptos comerciales recurrentes pertinentes. | La estimación solo cubre el desarrollo. |
| ¿Qué ocurre si cambian el proveedor o su hoja de ruta? | Entregables de traspaso, alternativas de soporte, disposiciones de salida y un planteamiento de retirada o sustitución. | El plan depende de una función futura sin compromiso firme o de conocimientos inaccesibles del proveedor. |
Separe la responsabilidad de negocio del mantenimiento técnico. El responsable del proceso debe aceptar lo que hace el cambio y decidir si sigue siendo necesario. El responsable técnico debe responder de su implementación, dependencias y soporte. Los revisores de compras o del área jurídica deben confirmar los derechos pertinentes, en lugar de deducirlos de la posesión de un repositorio de código.
Si se asigna la responsabilidad a un socio de implantación, compruebe quién realizará el trabajo y cómo se efectuarán los traspasos. Esa cuestión sobre la capacidad de ejecución corresponde a la evaluación del socio de implantación; la solicitud de cambio debe recoger las responsabilidades acordadas, no repetir el ejercicio de selección del proveedor.
Apruebe el mantenimiento y la aceptación, no solo el desarrollo
Solicite un plan de mantenimiento de la extensión del ERP, expresado en tareas y roles responsables, antes de aceptar una estimación de su ciclo de vida. Incluya el análisis de los cambios pertinentes del producto, el mantenimiento y la ejecución de las pruebas, la resolución de defectos, el despliegue y el soporte operativo. Añada los cargos de alojamiento, interfaces o aplicaciones cuando el diseño propuesto los requiera. Pida los supuestos en los que se basa la estimación en lugar de aplicar un porcentaje de mantenimiento sin fundamento.
Escenario hipotético de evaluación: una aplicación externa evalúa una condición de liberación de pedidos y devuelve una aprobación al ERP. La transferencia correcta de un mensaje no basta como prueba de aceptación. Pida al equipo que demuestre que el pedido correcto cambia de estado, que se rechaza una aprobación no autorizada y que operaciones puede identificar lo sucedido.
A continuación, pruebe los fallos y la recuperación: la aplicación externa aprueba, pero el ERP rechaza la actualización; una respuesta se retrasa; una aprobación se envía de nuevo; o el negocio cancela el pedido antes de que finalice el proceso. Exija que el diseño indique quién detecta cada excepción, quién concilia el estado de negocio y quién autoriza la recuperación. Son pruebas de aceptación propuestas, no afirmaciones sobre el comportamiento de un producto concreto.
Respecto a las actualizaciones, pregunte qué pruebas deben repetirse y quién decide si el cambio sigue siendo apto para su uso. «Compatible con las actualizaciones» es una respuesta débil si no se acompaña de la política aplicable del producto y de un plan de pruebas para el flujo de trabajo. Limite o posponga la aprobación si el equipo no puede determinar el mecanismo con soporte, las obligaciones ante las actualizaciones o la responsabilidad de corregir los problemas.
Evalúe la dependencia antes de autorizar el cambio
En la conversación sobre transformación centrada en SAP, un participante insta a los clientes a exigir las API que necesitan, incluido el acceso para trabajar con otros proveedores. La implicación útil para un cambio concreto es precisa: compruebe el acceso a las operaciones y los datos que requiere su diseño antes de aprobar una integración. No equipare una declaración general sobre acceso a la plataforma con el derecho de utilizar todas las interfaces necesarias.
Realice un ejercicio de interrupción sobre la extensión propuesta. Pregunte qué ocurriría si el responsable del mantenimiento dejara de estar disponible, cambiara una interfaz necesaria, las condiciones comerciales pasaran a ser inaceptables o se retirara una función de la hoja de ruta. Exija al equipo que distinga lo que la organización puede operar, modificar, sustituir o retirar de lo que sigue dependiendo de otra parte.
Para una extensión a medida, solicite un repositorio que pueda inspeccionarse, instrucciones de compilación y despliegue, documentación de dependencias, recursos de prueba y confirmación de los derechos pertinentes. Para una aplicación externa, examine la exportación de datos, las condiciones de las interfaces, la documentación de configuración y la asistencia para la salida. Son disposiciones que deben negociarse y verificarse, no derechos que deban darse por supuestos.
Antes de aprobar el próximo cambio, complete la ficha con el responsable del proceso y el responsable del mantenimiento técnico; después, resuelva las carencias de información que podrían modificar la elección de implementación. Apruebe la opción cuyo valor de negocio justifique sus obligaciones explícitas, no simplemente la que tenga la demostración más convincente.
Si necesita apoyo funcional o técnico para evaluar ese requisito, hable con los especialistas en ERP de Digiventi sobre el trabajo de configuración, integración o desarrollo que está considerando.
