los expertos en licitación encuentran el mecanismo de contratación, 53 La contratación pública para la digitalización: hay que adaptarse al cambio y para mitigar el riesgo de la componente política, no hay nada mejor que obtener resultados porque lo peor es llevar a cabo realizaciones que no satisfacen a nadie (Kost 2020). 3.4. Contratación interinstitucional – gobierno y economías de escala Ante un contexto como hemos explicado, en que la administración pública estará su- jeta a un cambio importante en los años venideros en cuanto a su proceso de digitalización es fácil pensar que los distintos organismos, instituciones y demás agencias públicas tanto del contexto europeo como nacional, regional o local, se enfrenten a problemas comunes y repetitivos para los que las soluciones deberían ser también las mismas. Esto genera, entre otros, dos problemas, el primero la proliferación de sistemas para un mismo fin con el con- siguiente uso ineficiente de los recursos, el segundo la dificultad que representa la interope- rabilidad puesto que es claro que los sistemas nunca funcionan de forma aislada. Para mitigar estos problemas y racionalizar la generación de sistemas para un mismo fin, es necesaria la cooperación interinstitucional: un modelo de gobierno a distintos niveles que incluya el diseño de una arquitectura común y la adopción de estándares. En este mo- delo todos los actores tienen que estar representados, pero solamente funcionará si se iden- tifica un líder claro para la implementación de cada iniciativa. Evitar el clásico «es que nosotros somos diferentes» será un reto. Esa cooperación interinstitucional deberá también extenderse al proceso de contratación. Cuando la necesidad es común, el proceso de licitación también. Es evidente que esta coo- peración permite hacer economías de escala en cuanto el precio de, por ejemplo, programas, plataformas y dispositivos. El mundo del hardware, y sobre todo del software, se beneficia mucho de los grandes volúmenes. Por su lado, ya hemos visto que se trata de un proceso complejo y consume muchos recursos especializados no estando exento de riesgos tanto legales como operativos. Si se coopera se optimizan los recursos y se minimizan los riesgos. Una mayor centralización del proceso de licitación permitirá armonizar las soluciones, haciendo más fácil el diálogo entre los distintos sistemas implementados. En el caso de organismos e instituciones pequeñas, la cooperación interinstitucional quizá sea la única solución para afrontar el reto de la digitalización en toda su amplitud. Insistimos que establecer esa cooperación no es fácil, los organismos tienen tendencia a considerar que los problemas son diferentes y que sus necesidades son diferentes y que, por tanto, deben actuar de forma independiente para ser más eficientes. Aunque estas con- sideraciones son cuestionables, deberán ser tenidas en cuenta. 54 Magdalena Cordero Valdavida y José Carrascosa Moreno 4. Posibles innovaciones en la contratación pública de bienes y servicios digitales 4.1. Las nuevas metodologías ágiles Si bien algunos oficios como la construcción de edificios, por ejemplo, gozan de mu- chos siglos de experiencia lo que les permite establecer especificaciones detalladas que pasarán luego a la fase de implementación, las tecnologías de la información no gozan de esa experiencia. Siguiendo al Project Management Institute (PMI) (5) un porcentaje del 14% de los proyectos informáticos fracasan completamente y un 32% pierde la financiación debido a constantes fallos. Preguntándonos las causas, el 39% de los proyectos han fallado debido a las malas especificaciones originales. Este problema ya fue identificado a finales del pasado milenio, y las soluciones comenzaron a diseñarse a principio de los años 2000: las metodologías ágiles. Durante décadas los proyectos informáticos se desarrollaban utilizando el método de cascada (waterfall), que se caracteriza por detallar las especificaciones a priori y, solamen- te cuando todo el sistema se ha descrito, comenzar la fase de desarrollo que podía durar años. Durante ese período el contacto con los futuros usuarios era limitado y el resultado final tenía el riesgo de no ser el esperado debido a fallos en la descripción de las necesida- des originales y a cambios en estas necesidades durante el período, dando lugar a proyectos fallidos o a totales fracasos. Cuando se implementaba, se generaban elevados costes de mantenimiento ya que, con constantes cambios, los sistemas se iban adaptando a las nece- sidades reales. El sistema resultante carecía de una estructura coherente y la mantenibilidad era cada vez más difícil, incrementándose aún más los costes. Como los contratos para estos desarrollos eran contratos de precio fijo, se añadía (se añade) el problema de validar si todas las especificaciones habían sido satisfechas y con el alcance y la calidad requerida para así aceptar el producto y realizar los pagos. Con el cambio de milenio se intenta poner solución al problema y surgen las metodo- logías ágiles de desarrollo de sistemas de información que buscan poner en funcionamiento en poco tiempo programas pequeños de forma que el sistema se va completando de forma iterativa. Estas metodologías se basan en la flexibilidad y el trabajo en equipo para ofrecer mejoras constantes, esto implica que pequeños equipos auto-organizados de desarrolladores y representantes del negocio se reúnan regularmente durante el ciclo de desarrollo y se acepten los cambios que puedan surgir en las diferentes etapas del ciclo de vida, en lugar de resistirse a ellos. La tabla 2 hace un análisis comparativo de los dos métodos de desarro- llo, cascada y ágil. 55 La contratación pública para la digitalización: hay que adaptarse al cambio Tabla 2 Comparación de los métodos de desarrollo Cascada (Waterfall) Agile Especificaciones fijas y rígidas, se evitan cambios lo Colaborativa y enfocada a los cambios largo del proyecto Coste del proyecto establecido desde el principio Incertidumbre sobre el coste total del proyecto Centrada en la entrega exitosa del proyecto Centrada en el producto y la satisfacción de las nece- sidades del cliente Las pruebas se realizan al final Las pruebas se van realizando durante todo el desa- rrollo Los roles están muy definidos Los roles cambian según las fases Bueno para pequeños proyectos de desarrollo Bueno para grandes proyectos de desarrollo Contratos de precio fijo «llave en mano» Contratos «tiempo y material» y con costes fijos por entregas Fuente: Elaboración propia. La metodología ágil nació cuando un grupo de desarrolladores de software redactó el Manifiesto para el Desarrollo Ágil de Software, en que describieron las cuatro caracterís- ticas fundamentales que deberían valorar los equipos de desarrollo de software ágil: — Las personas y las interacciones antes que los procesos y las herramientas. — El software en funcionamiento antes que la documentación exhaustiva. — La colaboración con el cliente antes que la negociación contractual. — La respuesta ante el cambio antes que el apego a un plan. En el punto 3 se insiste en «La colaboración con el cliente antes que la negociación contractual». Esta forma de trabajar colaborativa entre las empresas y las administraciones, necesaria para tener éxito en el desarrollo de sistemas, puede entrar en conflicto con la ri- gidez de las normas de licitación y contratación a que tiene que responder el sector público. Estas prácticas ágiles enfatizan la importancia de la adaptación, de experimentar, de obser- var y aprender. Asistimos a un cambio de paradigma en el control de proyectos ya que el viejo paradigma «en tiempo, en presupuesto y con el alcance requerido» deja de ser válido, y lo mismo ocurre con los contratos que deberán adaptarse. 4.2. Impacto en la contratación de servicios digitales Los contratos de servicios son, tradicionalmente, contratos de precio fijo (o contrato cerrado o llave en mano), es decir, contratos en los que el cliente se compromete a pagar al proveedor una cantidad fija, con independencia del tiempo y coste real que le lleve al pro- veedor. Este es el contrato utilizado en las metodologías cascada. arse de forma flexible por ambas partes. Las administraciones deberán diseñar contratos marco que permitan combinar posibilidades, parte precio fijo, parte tiempo y materiales, que den flexibilidad a los respon- sables de ejecutar el contrato. Tabla 3 Modelos innovadores de contratación para el desarrollo informático Agile Método o técnica contractual Descripción Sprints de confianza Consiste en ofrecer un número determinado de sprints (ciclos cortos de desarrollo) para generar confianza y establecer una base sólida de relación entre la organización y el proveedor antes de formalizar el contrato. Not-to-exceed with Para solventar el problema de la falta de especificaciones detalladas y al mismo tiempo fixed-fee controlar el límite presupuestario, se establece un mínimo y un máximo para proteger tanto a la organización como el proveedor. Esta solución se ajusta poco al principio de adaptabilidad de las metodologías ágiles. internas si, nuevamente, no hay confianza y se teme por una actitud oportunista del otro. Bob Martin’s idea Un modelo de contrato por tiempo y materiales combinando el precio por hora y el precio por entregas. Se fija un precio por hora muy bajo y el total por entrega. Si se entrega rápido se cobra mucho y si se tarda mucho se cobra poco porque no dará tiempo a hacer muchas entregas. Por un lado se mitiga el riesgo de desviación por sobrecostes y por otro el riesgo del