Este artículo está dirigido a los consejos de administración y a las personas que avalan con su firma la compra de un sistema: el secretario 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 la propia entidad contratante, y mucho antes de la firma. No por mala voluntad: preparar una contratación es un trabajo para el que raramente hay tiempo y competencias dentro de la organización, y los proveedores se ofrecen encantados a facilitarlo. Traen descripciones ya hechas, demostraciones y presupuestos. El resultado es que la entidad contratante compra lo que el proveedor sabe vender, no lo que realmente necesita. Otro problema es que, muy a menudo, 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 modo de contratación, 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 incluso antes de elegir al contratista. Lo expliqué con más detalle en el artículo sobre el vendor lock-in en el pliego de condiciones (SWZ).
- Falta de un propietario de negocio. El proyecto tiene formalmente un responsable, 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 la firma. 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 implementació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 maestro, 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é periodo, quién los depura y quién comprueba el resultado.
- Requisitos en forma de lista de funciones en lugar de descripción de procesos. Cualquier proveedor responderá «sí» a la pregunta sobre una función. A 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 comienzo. El mantenimiento, los cambios y las integraciones se pagan durante años. Escribo sobre este mecanismo en el artículo sobre el coste total de propiedad (TCO) y la rana hervida.
- Falta de reglas para cambiar el alcance. No está claro quién propone un cambio, quién lo valora económicamente y quién lo aprueba.
- Contrato sin condiciones de salida. Sin cláusulas sobre exportación de datos, documentación ni traspaso del mantenimiento a otro proveedor. Sin herramientas de mitigación de riesgo.
- Contrato de mantenimiento aceptado tal como lo propone el proveedor. En ese caso, los niveles de servicio, los tiempos de respuesta y el coste de los cambios los fija una sola parte.
- Decisión aplazada hasta el último momento antes del plazo. Cuando se acerca un plazo legal o el fin del soporte del sistema antiguo, ya no queda margen para comparar ofertas ni para negociar.
Los errores del uno al tres son los de origen. Si los eliminais, la mayoría de los demás se hacen visibles en la fase de preparación, no en la de ejecución.
Para el consejo, el consejo de vigilancia o la central, 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.
Un ejemplo de la práctica
Uno de nuestros clientes recibió del proveedor del sistema ERP la confirmación de que no habría ningún problema para intercambiar los datos de las contrapartes con el sistema de gestión de correspondencia que se estaba implantando (un sistema de la clase EZD —gestión electrónica de documentos y expedientes— integrado con e-Doręczenia, el sistema polaco de entrega electrónica). El sistema de gestión de correspondencia suele almacenar los datos de todas las contrapartes, no solo de aquellas con las que se producen operaciones económicas, es decir, que pasan a ser clientes o proveedores. Sencillamente, el ciclo de vida de los datos de una nueva contraparte suele comenzar mucho antes de que se produzcan esas 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 sistema ERP, suponía el 80% del valor total del proyecto de implantación del circuito de documentos de gastos integrado con el KSeF (el sistema polaco de facturación electrónica), con OCR, VIES, el GUS (la oficina central de estadística polaca) y, finalmente, con la exportación de datos al sistema financiero-contable. Esa única integración, no discutida a fondo 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 control. 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 un órgano de control, el consejo o la central, o cuando nadie por parte de la entidad contratante conoce estos sistemas desde 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 locales (JST).