Una empresa cambia de equipo de mantenimiento de su ERP. Siguen entrando pedidos, el almacén continúa preparando entregas y administración necesita registros fiables. El traspaso debe comprobar que el nuevo equipo puede atender esas operaciones, entender las excepciones y recuperar el trabajo cuando falla una integración. Recibir un repositorio y una cuenta de administrador es solo el comienzo.
Una checklist de revisión técnica de ERP relaciona la evidencia del software con las operaciones de las que depende la empresa. Úsala antes de asumir un sistema, encargar una ampliación importante o preparar una sustitución. Esta guía se centra en la operación del ERP. La guía general de revisión técnica de software cubre el análisis de la aplicación que la sostiene.
Define la decisión y las operaciones críticas
Escribe qué decisión debe apoyar la revisión. Asumir el mantenimiento, conectar un portal y sustituir la interfaz contable necesitan evidencias diferentes. Identifica al responsable de negocio que puede explicar el resultado esperado y aceptar las conclusiones. Acuerda un entorno de pruebas adecuado y datos representativos y autorizados antes de organizar demostraciones.
Selecciona recorridos completos: del pedido al cobro, de la compra a la recepción o del ajuste de existencias al informe. Incluye una operación habitual y una excepción importante en cada uno. Pregunta qué actividad se detiene si el sistema no está disponible y qué alternativa manual puede realizar realmente el equipo. Así podrás ordenar la revisión por necesidades concretas.
La guía de implementación basada en procesos de Microsoft sirve como referencia para relacionar roles, actividades, datos y sistemas. Aplica ese enfoque al ERP que vas a asumir, tanto si es un producto estándar con extensiones como si es una aplicación a medida.
Sigue un pedido por todos los sistemas
Imagina un distribuidor británico con un portal de clientes, un módulo de pedidos propio, una aplicación de almacén y un programa contable independiente. Es un ejemplo hipotético de revisión, no un caso de éxito. La confirmación del portal por sí sola no demuestra que toda la venta esté registrada correctamente.
Sigue un pedido de prueba autorizado por estos pasos:
- Recibir la solicitud. Identifica cliente, centro de entrega, productos y referencia del envío original. Comprueba quién puede actuar en nombre de esa cuenta.
- Aceptar las condiciones. Confirma tarifa, moneda, unidades y aprobación. Compara el pedido almacenado con lo aceptado por el comprador e identifica la configuración que produjo el resultado.
- Reservar y entregar. Sigue la asignación de existencias, las entregas parciales y las sustituciones. Localiza al responsable de una petición que llega al almacén pero no puede completarse.
- Registrar el resultado contable. Sigue el documento y su referencia hasta contabilidad. Pide al responsable que explique una cancelación, devolución o abono mediante un caso de prueba acordado.
- Conciliar el resultado. Compara los registros entre sistemas con una fecha de corte común. Una respuesta correcta de una API demuestra una interacción, pero no que todos los registros posteriores coincidan.
Repite después el recorrido con un mensaje duplicado y una integración que agota el tiempo de espera. Averigua cómo distingue el equipo una solicitud sin procesar de otra que terminó pero perdió la confirmación. Registra la evidencia y las dudas pendientes, sin convertir una demostración correcta en prueba de todas las variantes.
Utiliza una checklist con evidencias y responsables
Anota para cada punto la ubicación de la evidencia, quién revisa, el resultado, sus límites y la siguiente acción. Utiliza estados claros: verificado, fallido o no examinado. Un documento ausente o un entorno inaccesible siguen siendo asuntos abiertos.
- Reglas y configuración. Localiza precios, descuentos, reglas de existencias, aprobaciones y numeración de documentos. Solicita ejemplos aceptados por el responsable y sigue la configuración o el código correspondiente. Comprueba cómo se reconoce una regla modificada después de una operación histórica.
- Personalizaciones y dependencias. Distingue comportamiento estándar, configuración admitida y extensiones propias. Enumera tareas programadas, servicios externos y componentes mantenidos por proveedores. Determina qué código, instrucciones de compilación, cuentas y acuerdos de soporte estarán disponibles para el equipo entrante.
- Responsabilidad e identificadores de datos. Define qué sistema manda sobre clientes, productos, pedidos y documentos contables. Revisa correspondencias entre identificadores, duplicados, unidades y monedas. Averigua si una corrección se propaga o deja una diferencia pendiente de resolución manual.
- Integraciones y trabajo pendiente. Identifica desencadenante, contenido, confirmación y responsable de recuperación de cada interfaz. Examina reintentos y algún fallo reciente. Demuestra cómo reanudar el trabajo sin crear otro pedido, envío o documento contable.
- Permisos y aprobaciones. Prueba roles representativos y cuentas de clientes distintos. Comprueba que quien prepara una operación no puede saltarse silenciosamente su aprobación. Examina qué ocurre cuando cambian responsabilidades o caduca una credencial de servicio.
- Conciliación de datos. Acuerda las reglas de comparación con quienes utilizan los registros. Comprueba cantidades de registros, importes, estados y relaciones importantes. Explica diferencias por tiempos, cancelaciones o conversiones de unidades, sin declarar éxito únicamente porque coinciden dos totales.
- Publicación y recuperación. Demuestra una compilación repetible, un despliegue aislado y la restauración de una copia representativa. Registra dependencias, tiempo de recuperación y comprobaciones antes de reanudar el trabajo. Revisa también los servicios externos, además de la base de datos.
- Responsabilidad operativa. Identifica quién recibe alertas, atiende incidencias fuera de horario cuando corresponde y autoriza intervenciones manuales. Pide al nuevo equipo que investigue un fallo controlado con las instrucciones disponibles. El traspaso está incompleto si solo el desarrollador anterior sabe dónde buscar.
La guía de gestión de datos de Microsoft ayuda a planificar responsabilidades sobre la información. La revisión debe indicar además qué registros se comprobaron, qué comparaciones se hicieron y qué quedó fuera de la muestra.
Convierte las discrepancias en decisiones
Supón que el portal de prueba muestra un pedido aceptado, el almacén registra un envío y contabilidad contiene dos registros para la misma solicitud. No corrijas un dato de producción durante la revisión solo para hacer coincidir los totales. Conserva la evidencia, reproduce el problema en el entorno acordado y determina la causa con los responsables.
Un hallazgo útil describe el recorrido afectado, lo observado, la consecuencia, la evidencia y la acción propuesta. Por ejemplo, un reintento podría crear otro documento porque el receptor no reconoce la referencia original. La acción debe contemplar impedir el duplicado, identificar registros afectados y acordar una conciliación controlada con administración.
Agrupa los hallazgos según la decisión que condicionan. Quizá haya que resolver una recuperación sin probar antes del traspaso. Un informe lento pero comprendido puede entrar en el mantenimiento. Un rediseño propuesto necesita una estimación separada con condiciones y dependencias. Evita ocultar compromisos distintos dentro de una puntuación general del software.
Ensaya el traspaso y la recuperación
Pide al equipo entrante que realice un cambio pequeño y autorizado en pruebas, lo publique y demuestre cómo recuperarse. Elige un ejemplo que atraviese una parte relevante del proceso, como una validación que afecte a un informe posterior. Registra versión, configuración y condiciones de datos necesarias para volver a trabajar.
Restaurar una base no deshace automáticamente un correo, un envío o una operación aceptada por otro sistema. Planifica cómo identificar y conciliar el trabajo ocurrido después del punto de recuperación. La guía de despliegues seguros de Microsoft puede orientar los controles de publicación; los recorridos reales del ERP determinan la recuperación necesaria.
Acuerda una primera fase acotada
La revisión debe dejar un registro de evidencias, responsables de asuntos pendientes y un primer alcance priorizado. Explica qué puede mantener el equipo desde el comienzo, qué necesita acceso o correcciones y qué no se examinó. Vincula las estimaciones a esas condiciones en lugar de transformar cada incógnita en una promesa.
Worktechlabs puede evaluar un ERP existente, revisar sus integraciones y planificar la modernización alrededor de los procesos que deben seguir funcionando. Cuéntanos qué ERP vas a asumir y qué operaciones no pueden detenerse. Podemos concretar una revisión y la evidencia necesaria antes de proponer la siguiente etapa.
Fuentes oficiales y lecturas recomendadas
