Imagina una propuesta de implantación ERP con un partner de nombre reconocido, consultores certificados y un precio inicial atractivo, pero sin un responsable funcional ni un responsable técnico confirmados. La decisión de compras todavía no consiste en determinar si el precio es aceptable. Consiste en comprobar si el proveedor ha demostrado quién ejecutará el trabajo y en qué condiciones.
Utiliza las credenciales para elaborar la lista de candidatos y, antes de firmar, verifica las personas propuestas, su disponibilidad y las responsabilidades de ejecución. Francesco Perrotta advierte que la reputación de un gran partner no se traduce automáticamente en un proyecto bien ejecutado. Describe casos de partners con dificultades para asignar personal porque tienen demasiados proyectos.
Esta es una evaluación del proveedor posterior a la decisión de seguir adelante. Si la decisión de inversión sigue pendiente, utiliza primero el marco para decidir si conviene mejorar o sustituir tu ERP. Aquí, la tarea es más concreta: determinar si una propuesta específica representa un compromiso de ejecución creíble.
Evalúa a las personas que harán el trabajo
Perrotta aconseja investigar la experiencia real del consultor, no solo su currículum. Destaca la competencia demostrada en una primera conversación y la capacidad de hablar sobre los proyectos que esa persona ha completado. Convierte esa observación en una sesión de trabajo con los responsables propuestos para la ejecución, en lugar de otra presentación comercial.
Pide al responsable funcional que explique un proceso de negocio crítico teniendo en cuenta tu contexto operativo. Pide al responsable técnico que identifique sus dependencias de datos, integración y entornos. El jefe de proyecto debería explicar cómo se controlarán las decisiones, los requisitos pendientes y los riesgos de ejecución. Evalúa el razonamiento, incluidas las preguntas que plantean antes de recomendar una solución, y no solo la soltura con la terminología del producto.
Utiliza un escenario hipotético: una aplicación externa envía correctamente una transacción al ERP, pero falla su registro en el proceso de negocio. Pide al equipo que explique cómo investigaría el problema, quién se encargaría de la conciliación, cómo se comunicaría la excepción al responsable de negocio y quién autorizaría la recuperación. Al evaluar la propuesta, la distinción importante es la que existe entre demostrar la transferencia de un mensaje y asumir la responsabilidad por el resultado completo del proceso de negocio.
Una respuesta convincente identifica los límites de responsabilidad y los supuestos pendientes de resolver. Una respuesta débil promete que «el equipo de integración se encarga», sin identificar a ese equipo ni describir su autoridad. Si los responsables propuestos no pueden asistir a la evaluación, pregunta cuándo podrás evaluarlos y deja explícita la decisión pendiente sobre la asignación del equipo antes de aprobar al proveedor.
Distingue entre credenciales, referencias y adecuación al contexto
En un webinario sobre selección de ERP para la industria manufacturera, un ponente que declara expresamente aportar la perspectiva de un fabricante recomienda comprobar la autorización del partner, sus certificaciones y su experiencia en implantaciones en sectores similares. Considéralo un consejo para el sector manufacturero condicionado por la perspectiva del fabricante, no una regla universal según la cual solo una determinada categoría de partner puede ejecutar el proyecto.
En tu proceso de compra, verifica qué acredita realmente el estatus que se presenta para el producto y el alcance seleccionados. Por separado, pide al equipo que demuestre sus conocimientos de configuración, integración y procesos de negocio. El webinario distingue entre el dominio del producto y el conocimiento funcional, que incluye comprender cómo se conectan los departamentos y de dónde proceden los datos maestros. Una acreditación y una revisión práctica de un proceso responden a preguntas distintas; ninguna debería sustituir a la otra.
Las referencias también deben servir para evaluar al equipo propuesto, no solo la trayectoria de la empresa. El método de evaluación de partners de Dreher Consulting propone expresamente hablar con clientes que hayan trabajado con los mismos consultores que ejecutarán el proyecto. Pregunta qué personas del equipo propuesto participaron en el proyecto de referencia, de qué se responsabilizaron y si siguieron implicadas cuando surgieron problemas difíciles.
Después, examina la relevancia: ¿qué flujos de trabajo, integraciones y responsabilidades del cliente se parecían a los tuyos? Pregunta qué asuntos hubo que escalar, cómo se gestionaron las sustituciones y qué aclararía el cliente en su próximo contrato. Si la confidencialidad impide una conversación detallada con un cliente de referencia, acuerda otra forma de verificar la experiencia. No des por hecho que un caso de éxito de la empresa demuestra la experiencia de un consultor concreto.
Aplica el mismo rigor a los servicios profesionales del fabricante del ERP y a los partners de implantación independientes. El webinario presenta ambas opciones y señala el conocimiento de la integración con sistemas externos como un aspecto que debe valorarse. Cuando el acceso al fabricante sea decisivo, solicita pruebas de la vía de escalado del equipo propuesto. Cuando las aplicaciones relacionadas concentren el riesgo, pide pruebas de experiencia en interfaces y de quién asume la responsabilidad en los traspasos entre equipos. Ningún modelo organizativo merece una preferencia automática.
Convierte el equipo propuesto en un compromiso de disponibilidad
La advertencia de Perrotta sobre los equipos sobrecargados señala una distinción que conviene comprobar: la competencia y la disponibilidad son cuestiones diferentes. Su descripción se refiere a partners con demasiados proyectos y a clientes que no consiguen contactar con la persona que necesitan. Por tanto, entrevistar a un consultor competente no debería dar por concluida la revisión de la asignación del equipo.
Solicita un plan de asignación de recursos que identifique a los responsables funcionales, al responsable técnico, al jefe de proyecto y a los demás especialistas críticos. Para cada persona, pregunta por su participación prevista en cada fase, la fecha de incorporación, la dedicación, los compromisos con otros proyectos y la cobertura de respaldo. Distingue las asignaciones confirmadas de los puestos que siguen sujetos a contratación o a la finalización de otro proyecto. «Acceso a nuestro equipo de expertos» no equivale a una persona asignada con una función definida.
A continuación, contrasta el plan de recursos con el contrato. Un documento de eFutures CFO sobre selección de partners de implantación describe una cláusula que exige notificación y aprobación del cliente antes de sustituir a personal clave. Revisa ese mecanismo con compras y asesoría jurídica, en lugar de dar por hecho que figura en la propuesta.
Pregunta cómo se evaluará la competencia del sustituto, quién realizará el traspaso de conocimiento y cómo se acordará cualquier repercusión sobre el calendario o las condiciones comerciales. Las promesas absolutas de que nadie abandonará el proyecto son menos útiles que un proceso de sustitución viable. Si un responsable esencial no está disponible, exige un sustituto evaluado o un plan de ejecución revisado antes de considerar que la propuesta está lista para su aprobación.
Comprueba las responsabilidades cuando el plan deja de ser cómodo
El webinario sobre industria manufacturera concreta la gestión de riesgos preguntando qué ocurre cuando faltan datos del cliente o estos no están depurados, un departamento no está disponible o alguien de cualquiera de las partes enferma. Utiliza esas incidencias para poner a prueba la metodología propuesta. Un diagrama de fases del proyecto no explica cómo responderá el equipo ante una dependencia bloqueada.
Solicita una matriz de responsabilidades que abarque la extracción y depuración de datos, las decisiones sobre procesos, la participación de los usuarios de negocio, las pruebas, la formación y la aceptación. Para cada dependencia, registra el responsable del proveedor, el responsable del cliente, la información o aportación necesaria y la vía de decisión. Si un responsable financiero no puede asistir a un taller de diseño, establece quién puede decidir si se reprograma, se delega o se continúa con un supuesto registrado expresamente.
Pide también una vía de escalado que separe las decisiones de ejecución de las discrepancias comerciales. Identifica quién puede resolver un problema entre líneas de trabajo, quién puede autorizar trabajo adicional y quién recibe un riesgo que el jefe de proyecto no puede resolver. Solicita un ejemplo del registro de decisiones que utilizaría el equipo, eliminando la información confidencial cuando sea necesario.
Compara la ejecución a precio fijo y el refuerzo del equipo con consultores externos como modelos de responsabilidad, no como opciones ganadoras en costes. En una propuesta a precio fijo, comprueba qué entregables y supuestos sustentan el precio, cómo funciona la aceptación y cómo afectan los cambios o los retrasos del cliente a las obligaciones. En un modelo de refuerzo del equipo, establece quién dirige a los consultores, coordina las dependencias, acepta su trabajo y se responsabiliza del plan integrado. No prefieras ninguno hasta que el reparto de responsabilidades propuesto encaje con tu capacidad interna.
Si tu organización quiere que el proveedor responda por entregables definidos, comprueba si las condiciones del precio fijo realmente lo establecen. Si quieres especialistas que trabajen bajo la dirección de tu programa, verifica que esa dirección dispone del tiempo y la autoridad necesarios para supervisarlos. Un alcance sin resolver no desaparece por contratar a precio fijo, y contratar capacidad especializada no determina por sí solo quién asume la responsabilidad de la ejecución.
Utiliza una lista de evidencias antes de aprobar al proveedor
Centra la comparación final en las evidencias que puedan cambiar la decisión de adjudicación. Utiliza la siguiente lista como una ayuda editorial para decidir, no como un modelo de puntuación validado. Asigna un responsable y acuerda una resolución para cada punto pendiente antes de aprobar el contrato.
- Responsables identificados: ¿han demostrado los responsables funcionales, técnicos y de proyecto propuestos la competencia necesaria?
- Referencias relevantes: ¿pueden los clientes confirmar qué entregaron realmente esas personas en un contexto comparable?
- Disponibilidad: ¿son explícitas las asignaciones, la participación por fase y las dependencias pendientes para completar el equipo?
- Sustitución: ¿existe un proceso acordado de aprobación, reemplazo y traspaso para el personal clave?
- Obligaciones del cliente: ¿se han asignado internamente las responsabilidades sobre datos, disponibilidad de usuarios de negocio y toma de decisiones?
- Aceptación y cambios: ¿está claro qué constituye la finalización del trabajo y cómo se gestionarán los trabajos adicionales o en disputa?
- Escalado: ¿saben ambas partes quién puede resolver los bloqueos de ejecución y sus consecuencias comerciales?
Mantén separadas la aprobación del proveedor y la autorización para entrar en producción. Al contratar, establece quién preparará las evidencias de preparación y quién participará en la decisión de puesta en producción. Utiliza la revisión de preparación para la puesta en producción del ERP cuando evalúes si las personas y la capacidad de soporte están listas para operar.
Antes de firmar, contrasta la propuesta, el plan de asignación del equipo y el documento de alcance del trabajo en una revisión conjunta con los responsables propuestos para la ejecución. Resuelve cualquier discrepancia entre las personas presentadas, la disponibilidad ofrecida y las responsabilidades aceptadas.
Si estás evaluando partners de implantación o necesitas consultores funcionales y desarrolladores, habla con los especialistas ERP de Digiventi sobre los perfiles, las dependencias y las responsabilidades de ejecución que requiere tu proyecto.
