Este texto está dirigido a los consejos de administración y a las personas que avalan con su firma la compra de un sistema: el secretario municipal y el tesorero del ayuntamiento, el presidente de una empresa municipal, el director financiero, el propietario de una empresa. También al responsable de TI que prepara el procedimiento o la solicitud de ofertas y quiere saber en qué debe fijarse el consejo antes de aprobar los documentos.
Por qué surge este problema
La mayoría de los problemas con los proveedores tienen su origen en el propio organismo contratante, y mucho antes de la firma. No por mala fe: preparar una contratación es un trabajo para el que rara vez hay tiempo y competencias dentro de la organización, y los proveedores se prestan encantados a facilitarlo. Traen descripciones ya redactadas, demostraciones y presupuestos. Como resultado, el organismo contratante compra lo que el proveedor sabe vender, no lo que necesita. Otro problema es que, con mucha frecuencia, las decisiones de compra quedan en manos de las áreas funcionales, mientras que TI se limita a hacer de guardián de la seguridad. La falta de estándares y de una estrategia de TI a largo plazo hace que la organización realice compras que no siempre encajan en el marco cuya función es mitigar el riesgo.
Veo los mismos errores en las administraciones públicas y en las empresas. Lo que cambia es el procedimiento de compra, no el mecanismo.
Doce errores
- Requisitos redactados a partir de la oferta o la presentación de un único proveedor. Limita la competencia y consolida la dependencia antes incluso de elegir al contratista. Lo desarrollo con más detalle en el artículo sobre el vendor lock-in en el pliego de condiciones de la licitación (SWZ).
- Falta de un propietario de negocio. El proyecto tiene formalmente un jefe de proyecto, pero nadie con mandato del consejo de administración decide cómo deben funcionar los procesos.
- Falta de criterios de recepción y de escenarios de prueba antes de firmar. La recepción se convierte en una disputa de interpretación, en lugar de una comprobación de si el producto del proyecto cumple los criterios de éxito de la implantación.
- Desconocimiento de lo que ya existe. Compráis un sistema nuevo sin saber qué contratos, licencias y funciones actuales se solapan con él.
- Integraciones omitidas. Con qué sistemas debe intercambiar datos el nuevo sistema, en qué direcciones, qué sistemas tienen el rol principal, qué datos, mediante qué formatos, y si el proveedor lo sabe y garantiza que aportará los mecanismos necesarios y asumirá la responsabilidad de su continuidad.
- Migración de datos descrita en una sola frase. Sin determinar qué datos, de qué período, quién los depura y quién comprueba el resultado.
- Requisitos en forma de lista de funciones en lugar de una descripción de los procesos. Cualquier proveedor responderá "sí" a la pregunta sobre una función. Ante la pregunta de cómo gestionará vuestro caso concreto, las respuestas difieren.
- Comparar el precio inicial en lugar del coste total. La licencia es solo el principio. El mantenimiento, los cambios y las integraciones se pagan durante años. Explico este mecanismo en el artículo sobre el coste total de propiedad (TCO) y la rana hervida.
- Falta de reglas para modificar el alcance. No queda claro quién propone un cambio, quién lo valora y quién lo aprueba.
- Contrato sin condiciones de salida. Faltan cláusulas sobre la exportación de datos, la documentación y el traspaso del mantenimiento a otra entidad. Faltan herramientas de mitigación del riesgo.
- Contrato de mantenimiento adoptado a partir de la plantilla del proveedor. Los niveles de servicio, los tiempos de respuesta y el coste de los cambios los fija entonces una sola parte.
- Decisión aplazada hasta el último momento antes del plazo. Cuando el plazo legal o el fin del soporte del sistema antiguo están cerca, ya no queda margen para comparar ofertas ni negociar.
Los errores del uno al tres son los de origen. Si los elimináis, la mayoría de los demás se hacen visibles en la fase de preparación, no en la de ejecución.
Para el pleno, el consejo de vigilancia o la central corporativa, lo más importante es si la decisión de elegir al proveedor cuenta con una justificación documentada. Los doce puntos anteriores son, a la vez, una lista de preguntas que conviene plantear antes de que el consejo de administración apruebe los documentos de la contratación.
Ejemplo práctico
Uno de nuestros clientes recibió del proveedor de su sistema ERP la garantía de que no habría ningún problema para intercambiar datos de contrapartes con el sistema de gestión de la correspondencia (EZD, gestión electrónica de documentos y expedientes, integrado con e-Doręczenia, el servicio polaco de entrega electrónica) que se estaba implantando. Un sistema de gestión de la correspondencia suele almacenar los datos de todas las contrapartes, no solo de aquellas con las que se producen operaciones económicas, es decir, que se convierten en clientes o en proveedores. Sencillamente, el ciclo de vida de los datos de una nueva contraparte suele empezar mucho antes de que se produzcan las operaciones económicas.
Durante la implantación resultó que el coste de adaptar la interfaz API para el intercambio bidireccional de datos de contrapartes, por parte del proveedor del ERP, ascendía al 80 % del valor total del proyecto de implantación del circuito de documentos de gasto, integrado con el KSeF (Sistema Nacional de e-Factura polaco), con OCR, con el VIES y con el GUS (Oficina Central de Estadística de Polonia), y finalmente con la exportación de datos al sistema financiero-contable. Esa única integración, no discutida en detalle con el proveedor desde el principio, prácticamente duplicó el coste del proyecto.
Cuándo hace falta un asesor independiente
Si contáis con un equipo experimentado que ya ha preparado varias contrataciones similares, esta lista os servirá como lista de comprobación. Una mirada independiente tiene sentido cuando la contratación es grande en relación con el tamaño de la organización, cuando los requisitos se elaboraron en contacto con un único proveedor, cuando la decisión tendrá que defenderse ante una auditoría, el pleno o la central, o cuando nadie en el lado del organismo contratante conoce estos sistemas por dentro.
Puedo revisar los documentos antes de publicar el procedimiento o de enviar la solicitud de ofertas, preparar los requisitos y los escenarios de prueba o evaluar las ofertas ya presentadas. En las administraciones públicas, el punto de partida es algo distinto; lo describo en la página para las entidades de la administración local (JST).