)){kind=icon}
)){kind=icon}
)){kind=icon}
)){kind=icon}
)){kind=icon}
)){kind=icon}
)){kind=icon}
)){kind=icon}
La selección de un ERP empresarial exige dos decisiones: elegir una plataforma que se ajuste al negocio y elegir un socio capaz de implementarla, darle soporte y mejorarla. Para las organizaciones basadas en proyectos, esto implica evaluar la experiencia sectorial, el control de proyectos conectado y la responsabilidad sobre la implementación. Además, implica evaluar la adopción por parte de los usuarios, la integración y la continuidad del servicio a largo plazo. Una lista de funcionalidades es útil. Sin embargo, no puede demostrar cómo se comportarán el sistema —y las personas que lo respaldan— cuando un proyecto cambie, una integración falle o los equipos de obra necesiten soporte.
Una demostración de ERP puede mostrar que un sistema crea órdenes de compra, registra costos y genera paneles de control.
No necesariamente muestra si la solución propuesta conectará una solicitud de obra con el alcance y el presupuesto correctos. Tampoco muestra si la vinculará con la actividad programada, la autoridad de aprobación y la consecuencia financiera.
Tampoco establece quién asumirá la responsabilidad cuando esa conexión no funcione.
Por eso considero que la evaluación de un ERP empresarial debe responder a dos preguntas:
¿Entiende esta plataforma cómo opera nuestro negocio?
¿Puede este proveedor ayudarnos a implementarla, operarla y mejorarla de forma continua?
Esta perspectiva de ciclo de vida se refleja en la guía de implementación de Dynamics 365 de Microsoft. Esta guía abarca desde la estrategia y la implementación hasta la preparación y la operación continua. El recorrido de una aplicación empresarial no termina con la puesta en marcha.
Para los contratistas y otras empresas basadas en proyectos, la evaluación debe ir, por tanto, más allá de una comparación de módulos. Necesita una prueba mucho más exigente: el ajuste operativo, demostrado mediante procesos de negocio reales y respaldado por una responsabilidad clara.
1. La experiencia sectorial debe demostrarse a través de la lógica de negocio
Un proveedor de ERP debe entender algo más que la terminología que se utiliza en una empresa constructora.
Debe entender las relaciones entre los compromisos comerciales de la empresa, sus procesos de producción, sus recursos y sus resultados financieros.
Consideremos tres estructuras de proyecto distintas.
- El presupuesto por partidas (Bill of Quantities, BoQ) identifica las partidas de obra medidas y sus cantidades. El análisis de recursos sobre esas partidas puede respaldar la estimación interna de costos del contratista. Un precio de venta frente al cliente y un costo interno de ejecución no son automáticamente lo mismo.
- La estructura de desglose del trabajo (Work Breakdown Structure, WBS) organiza el alcance del proyecto en componentes manejables. El cronograma asociado introduce actividades, dependencias, duraciones y fechas. La WBS en sí no debe confundirse con el cronograma completo.
- Los códigos de costo (Cost Codes) proporcionan la clasificación interna del gasto. A través de ella, los gastos y los costos de recursos pueden acumularse, analizarse y conciliarse.
El Practice Standard for Work Breakdown Structures del Project Management Institute describe la WBS como una estructura para organizar el alcance total del proyecto. Esa distinción es importante al evaluar si un proveedor entiende realmente el control de proyectos o simplemente utiliza siglas conocidas.
DANAOS Insights analiza la relación entre estas dimensiones en Establecimiento de líneas base de desempeño del proyecto. Allí conecta BoQ, WBS, clasificación de costos, planificación de recursos y autorización de trabajos.
¿Cómo comprobar si el proveedor entiende el control de proyectos?
La prueba práctica es sencilla:
¿Puede el proveedor explicar cómo un cambio de cantidad afecta a la demanda de recursos, las compras, la ejecución, el costo y la proyección, y no solo cómo registrar el cambio?
Esto no justifica afirmar que las plataformas empresariales generalistas carecen de funcionalidad para proyectos. Oracle, por ejemplo, documenta transacciones de Primavera Unifier que contienen códigos CBS y WBS a la vez. Esa funcionalidad es real. Lo que no establece por sí sola es si una implementación concreta ofrece el flujo operativo completo, impulsado por el BoQ, que necesita un contratista.
Evalúe la configuración y el proceso propuestos, no un estereotipo sobre el proveedor.
2. Sustituya las demostraciones aisladas por una prueba de proyecto de principio a fin
Mi recomendación es entregar a los proveedores preseleccionados un escenario de proyecto representativo y pedirles que demuestren la secuencia completa.
Por ejemplo, consideremos un paquete ilustrativo de trabajos de cimentación. Se trata de un escenario de evaluación, no de un caso de estudio de un cliente.
Comience con el alcance medido y la estimación basada en recursos. Establezca el presupuesto aprobado, asocie el trabajo al cronograma del proyecto y defina los códigos de costo correspondientes.
A continuación, pida al proveedor que demuestre cómo esa misma información respalda:
Una solicitud de obra, una aprobación, una orden de compra, una entrega, el consumo de materiales, los registros de mano de obra y maquinaria, el avance medido, una certificación de subcontratista y la posición de costos resultante.
¿Qué ocurre cuando el proyecto cambia?
Después, introduzca un cambio.
Aumente una cantidad. Retrase una entrega. Rechace parte del trabajo tras una inspección. Registre tiempo adicional de equipo inactivo. Presente una variación que aún no haya sido aprobada.
Ahora examine si el sistema conserva las distinciones que importan:
El material recibido no es necesariamente material consumido.
El material consumido no es necesariamente avance físico aceptado.
Un costo incurrido no es necesariamente una variación aprobada por el cliente.
Una proyección revisada no debe sobrescribir silenciosamente la línea base aprobada original.
En cada etapa, pregunte: ¿Quién registra el evento, quién lo autoriza, qué cambia aguas abajo y qué evidencia queda?
La guía de estrategia de pruebas de ERP de Microsoft pone el acento en los requisitos de negocio y los resultados de prueba documentados. Además, subraya la preparación para producción y la aprobación por parte de los usuarios de negocio. Son bases más sólidas para la aceptación que una demostración pulida por sí sola.
El objetivo no es complicar la demostración.
Es descubrir si la solución propuesta sigue siendo coherente cuando el proyecto se complica.
3. La capacidad de implementación forma parte de lo que usted compra
Una plataforma capaz no se configura sola en torno a la organización.
La implementación debe establecer cómo funcionarán en conjunto empresas, proyectos, usuarios, recursos, proveedores, presupuestos, permisos y flujos de trabajo.
La guía de estrategia de implementación de Microsoft aborda explícitamente los objetivos de negocio, las medidas de éxito y las responsabilidades del cliente y del socio. También cubre la metodología, la retroalimentación y la adopción. Trata la implementación como una iniciativa coordinada de negocio y tecnología.
Para los compradores empresariales, yo lo traduciría en tres requisitos.
- Primero, conozca al equipo de implementación, no solo al equipo comercial. Pregunte quién dirigirá el diseño de procesos, la migración de datos, la integración, la formación y el soporte posterior a la puesta en marcha. Examine su experiencia pertinente y su disponibilidad real.
- Segundo, clasifique cada requisito importante. ¿Está disponible en el producto estándar, se puede lograr mediante configuración, depende de una integración, requiere desarrollo a medida o todavía está en la hoja de ruta?
- Tercero, defina la aceptación antes de que comience el desarrollo. Acuerde el comportamiento esperado, los datos de prueba, los usuarios responsables y la evidencia necesaria para la aprobación.
«Podemos dar soporte a eso» no es lo suficientemente preciso.
El comprador necesita saber cómo, quién lo hará, a qué costo, con qué dependencias y según qué criterios de aceptación.
DANAOS describe su combinación de conocimiento sectorial, implementación y soporte continuo a través de Integrated Digital Delivery. Los compradores deben traducir cualquier propuesta de este tipo —incluida la nuestra— en un plan de implementación específico y acordado.
Un socio de confianza debe aclarar esas distinciones, no ocultarlas.
4. La integración debe preservar el significado, no solo mover datos
Una interfaz puede transferir correctamente una transacción y, aun así, dejar el proceso de negocio mal controlado.
Por ejemplo, una orden de compra puede llegar al ERP corporativo. Sin embargo, el sistema receptor puede no conservar la asignación al proyecto, el estado de aprobación o la relación con el presupuesto subyacente.
Por eso, la evaluación de la integración debe examinar algo más que la conectividad.
Pregunte qué sistema es propietario de cada registro maestro. Establezca la dirección y la frecuencia del intercambio. Defina cómo se corrigen las transacciones rechazadas, cómo se evitan los duplicados y cómo se realizan las conciliaciones.
Y, sobre todo, identifique quién es responsable cuando un proceso cruza la frontera entre dos sistemas.
La lista de verificación de estrategia y gobierno de la integración de Microsoft recomienda probar las integraciones en condiciones realistas y examinar sus efectos aguas arriba y aguas abajo.
DANAOS Insights aborda la relación entre proyecto y finanzas en Los códigos de costo en ProjectVIEW ERP: integración con Oracle Fusion y SAP. El enfoque publicado utiliza la correspondencia de códigos de costo para conectar las operaciones del proyecto con la información corporativa.
Esto plantea una decisión de arquitectura importante.
Un contratista puede adoptar un ERP de construcción integrado en todas sus operaciones. En cambio, también puede mantener una plataforma corporativa y conectarle un sistema operativo específico para construcción. La descripción general de la integración con ERP de terceros de DANAOS describe tanto el papel complementario como el de sustitución de ProjectVIEW ERP. Aun así, el alcance adecuado debe diseñarse y validarse para cada organización.
Un socio creíble debe recomendar la arquitectura que se ajuste al negocio, no automáticamente el programa de sustitución más amplio.
5. La adopción por parte de los usuarios es un resultado de procesos, no un recuento de inicios de sesión
Iniciar sesión en un ERP no demuestra que alguien lo esté utilizando de forma eficaz.
Para un ingeniero de obra, la adopción puede significar registrar el avance en el paquete de trabajo correcto. Además, implica presentar las necesidades de materiales mediante el proceso aprobado y adjuntar la evidencia necesaria para su revisión.
Para compras, puede significar tramitar las solicitudes sin volver a crear la información en otra hoja de cálculo.
Para finanzas, puede significar rastrear un costo hasta la transacción operativa que lo generó.
Por ello, yo mediría la adopción a través de la calidad y la finalización de los procesos de negocio, no simplemente por el número de cuentas activas.
Entre los indicadores útiles se encuentran la proporción de transacciones requeridas que se completan en el sistema y el desfase entre un evento en obra y su registro. También cuentan la frecuencia de envíos rechazados y la cantidad de conciliación manual que todavía se necesita.
La lista de verificación de gestión del cambio de Microsoft incluye las conocidas pruebas de «un día en la vida» y la retroalimentación sobre la formación. Asimismo, incluye la transferencia de conocimiento y la medición de la adopción y el uso.
El artículo de DANAOS La organización que aprende: cómo ProjectVIEW ERP acelera la transformación digital desarrolla la conexión entre los procesos estandarizados, la retención del conocimiento y el aprendizaje operativo continuo.
Su enfoque publicado de incorporación y formación de ProjectVIEW ERP incluye sesiones estructuradas, usuarios referentes (champions) del cliente, materiales grabados y soporte de seguimiento. Son elementos concretos que los compradores pueden examinar al evaluar el plan de adopción.
El objetivo no debe ser que los empleados dependan del proveedor para cada acción rutinaria.
El objetivo debe ser que la organización sea cada vez más capaz de operar bien el sistema.
6. Un socio sólido no puede sustituir a un liderazgo comprometido
El proveedor tiene responsabilidades. El cliente también.
El proveedor debe entregar la funcionalidad acordada, explicar las limitaciones, dar soporte a los usuarios y gestionar sus obligaciones de entrega.
El cliente debe designar responsables de procesos, aportar y validar los datos y asignar tiempo de los usuarios. Además, debe resolver los desacuerdos internos y establecer la autoridad de aprobación.
Ningún proveedor de software puede decidir qué departamento del contratista debe ser responsable de un proceso de negocio en disputa. Tampoco puede decidir qué directivo tiene autoridad para aprobar un compromiso excepcional.
DANAOS Insights plantea este punto en Romper los silos: por qué el compromiso de la dirección es crucial para el éxito del ERP en la construcción. En ese artículo subraya el patrocinio, la asignación de recursos y la implicación continua de la dirección.
Microsoft recomienda asimismo una gestión del cambio proporcional al riesgo y la complejidad de la organización. Es decir, no la trata como una actividad genérica que se añade al final de la implementación.
En mi opinión, un socio de ERP de confianza debe estar dispuesto a cuestionar al cliente de forma constructiva.
Eso puede implicar señalar clasificaciones de costos incoherentes, responsabilidades poco claras o una personalización propuesta que simplemente reproduce un proceso ineficiente.
Estar de acuerdo con cada solicitud no es lo mismo que actuar en interés del cliente.
7. Defina los resultados de negocio antes de contar los módulos implantados
Un hito de implantación indica a la dirección qué se ha instalado.
No demuestra, por sí solo, qué ha mejorado.
Yo establecería un pequeño conjunto de indicadores operativos antes del despliegue, con un responsable designado y un método de cálculo acordado.
Visibilidad comercial y de costos: ¿Puede el equipo identificar el presupuesto vigente, los costos reales, los compromisos pendientes y la proyección restante sin contabilizar dos veces? ¿Con qué rapidez puede evaluar el efecto de un cambio?
Ejecución y productividad: ¿Pueden relacionarse las horas de mano de obra, el uso de equipos y el consumo de materiales registrados con la producción física correspondiente? ¿Se hacen las comparaciones con un alcance, unas unidades y unas reglas de medición coherentes?
Fiabilidad de los procesos: ¿Cuánto tiempo se necesita para aprobar una solicitud, resolver una excepción de datos o conciliar los registros del proyecto con los corporativos? ¿Qué soluciones alternativas siguen existiendo?
Se trata de indicadores de evaluación propuestos, no de afirmaciones sobre un porcentaje de mejora garantizado.
El Digital, Data and Technology Playbook del Gobierno del Reino Unido ofrece un principio de contratación útil. Propone centrarse en las necesidades de los usuarios, los resultados y el valor a lo largo de todo el ciclo de vida. Así, la compra inicial de la solución deja de tratarse como la decisión completa. Su orientación está escrita para la contratación pública; el principio general de evaluación también es útil para los compradores empresariales.
El caso de negocio de un ERP debe hacer que la mejora esperada sea verificable.
8. El soporte a largo plazo debe ser específico en lo operativo
«Soporte incluido» deja demasiadas preguntas sin respuesta.
¿Qué usuarios reciben soporte? ¿En qué horario y en qué idiomas? ¿Quién se ocupa de una integración fallida? ¿Cómo se escalan las incidencias urgentes? ¿Quién prueba una actualización antes de que llegue a producción?
La guía de estrategia de soporte de Microsoft distingue entre el alcance, el equipo y las operaciones de soporte. También aborda el horario de servicio, la geografía, el idioma, las prioridades y el escalamiento.
En el caso de un contratista, yo pondría a prueba ese modelo de servicio con una situación práctica:
Una obra no puede enviar una solicitud urgente, la aprobación está bloqueada y el equipo responsable se encuentra en otra zona horaria. ¿Qué sucede a continuación?
La respuesta debe identificar el canal de notificación, el responsable de la incidencia y la ruta de escalamiento. Además, debe indicar la solución alternativa de negocio y el proceso de comunicación.
Un acuerdo de nivel de servicio también debe distinguir entre respuesta, restablecimiento y resolución definitiva. Acusar recibo de un ticket no es lo mismo que restablecer el proceso afectado.
El modelo de soporte de ProjectVIEW ERP publicado por DANAOS describe la gestión de tickets, la gestión de incidencias y el escalamiento conforme a los requisitos de nivel de servicio. Los compromisos precisos deben verificarse con respecto al alcance de servicio acordado con el cliente.
La calidad de la relación se hace visible cuando algo sale mal, no solo cuando todo funciona con normalidad.
9. La confianza incluye transparencia sobre la continuidad, el costo y la salida
Una relación a largo plazo no debe depender de que marcharse resulte inviable.
Mi recomendación es evaluar los mecanismos de continuidad y salida antes de firmar, junto con la implementación y el soporte.
Pregunte cómo puede la organización recuperar sus datos, documentos, historial de transacciones y la información de configuración pertinente. Establezca los formatos, las responsabilidades y los costos asociados.
Revise la capacidad de entrega del proveedor, la dirección de su producto y su dependencia de personas clave. Examine la evidencia de seguridad y recuperación adecuada para la implantación propuesta.
Después, evalúe el panorama comercial completo: implementación, suscripciones, integración, personalización, formación, actualizaciones, esfuerzo del personal interno y eventual transición.
Las secciones sobre diligencia debida del proveedor y planificación de la salida del Digital, Data and Technology Playbook del Reino Unido abordan explícitamente la solvencia financiera del proveedor y la continuidad. Además, tratan la planificación temprana de la transferencia de conocimiento y datos.
Un socio creíble debería sentirse cómodo al tratar estas cuestiones.
La confianza es mayor cuando las responsabilidades están claras y el cliente conserva el control de su información de negocio.
10. La IA hace que una selección de ERP rigurosa sea más importante, no menos
Una demostración de inteligencia artificial (AI) no debe eliminar la necesidad de evaluar la lógica de negocio, los permisos y la responsabilidad.
Para cada capacidad de AI propuesta, pregunte a qué datos puede acceder y cómo se verifican sus resultados. Luego, pregunte qué acciones puede ejecutar y dónde sigue siendo necesaria la aprobación humana.
Distinga también con claridad entre la funcionalidad disponible hoy, un piloto controlado y una hoja de ruta futura.
El NIST AI Risk Management Framework ofrece una base reconocida para incorporar la fiabilidad y la gestión de riesgos. Esta base abarca el diseño, el desarrollo, el uso y la evaluación de los sistemas de AI.
El ecosistema ProjectVIEW AI de DANAOS presenta los recursos actuales de asistencia informativa y de conocimiento. Además, muestra su orientación más amplia hacia agentes de AI y operaciones inteligentes. Por eso, los compradores deben verificar la disponibilidad y los requisitos de implantación de cada caso de uso propuesto. No conviene tratar la visión general como una lista de funcionalidades ya completada.
La posición de DANAOS Projects es que la AI debe operar en torno a datos de proyecto y procesos de negocio controlados.
La pregunta pertinente no es simplemente: «¿Incluye este ERP AI?».
Es: «¿Podemos entender, gobernar y verificar lo que hace su AI?»
Cómo encaja ProjectVIEW ERP en esta evaluación
La arquitectura publicada de ProjectVIEW ERP se basa en conectar BoQ, WBS y Cost Codes a lo largo de los procesos comerciales, operativos y financieros.
DANAOS Insights explica este enfoque en Cómo logra ProjectVIEW ERP un verdadero control de costos: análisis en profundidad de la arquitectura de módulos integrados. El artículo describe cómo la estimación, las compras, las transacciones de obra, la subcontratación y la información financiera contribuyen a una estructura común de control del proyecto.
Para las organizaciones que evalúan opciones
, la propuesta pertinente es, por tanto, la combinación de funcionalidad específica para proyectos y los servicios necesarios para ponerla en funcionamiento.
No obstante, a ProjectVIEW debe aplicarse la misma disciplina de evaluación que a cualquier otra plataforma preseleccionada.
Pídanos que demostremos sus procesos. Examine las integraciones propuestas. Conozca al equipo de implementación. Acuerde los criterios de aceptación. Revise el plan de adopción y las responsabilidades de soporte.
Una propuesta de colaboración solo tiene sentido cuando puede ponerse a prueba.
Reflexión final
Los compradores de ERP empresarial seleccionan algo más que software.
Seleccionan una lógica de negocio, una capacidad de implementación, unas responsabilidades operativas y una relación que debe continuar después de la puesta en marcha.
La plataforma adecuada no puede compensar una implementación ineficaz.
El socio adecuado no puede compensar una inadecuación fundamental del producto.
Y ninguno de los dos puede compensar a una organización que no está dispuesta a asumir sus procesos y decisiones.
Por ello, la mejor selección de ERP responde a una pregunta exigente:
¿Qué plataforma y qué socio pueden demostrar cómo funcionará mejor nuestro negocio y seguir siendo responsables de su parte para lograrlo?
Es una pregunta más útil que preguntar qué sistema tiene la lista de funcionalidades más larga.
