A muchos todavía nos sorprende ver organizaciones que se aferran a Microsoft Teams o Copilot en vez de usar soluciones infinitamente mejores.

Quizá la IA también cambie esto. O quizá no.

Hace unos días, las acciones de empresas como Oracle y Microsoft sufrieron algunas de sus peores caídas en años. Otras empresas de software, en particular aquellas con modelos Software as a Service (SaaS), también se dejaron buena parte de sus valoraciones.

Uno de los motivos que explica esta falta de confianza en estas empresas es la increíble capacidad para producir software que están demostrando herramientas como Claude Code o Cursor. La tesis de muchos analistas e inversores es la siguiente: si cualquiera puede desarrollar software con herramientas de IA, el modelo de negocio de las compañías de software tiene los días contados.

¿Cómo va a impactar esto en el sector govtech?

Seguramente de mil maneras. Puede que los modelos SaaS hayan iniciado su declive hacia una muerte – incorrectamente – anunciada mil veces. Puede que un puñado de compañías se lleve todo el mercado de aplicaciones. Puede que la gran ventaja la tenga quien posea los datos y no el acceso a los modelos. Y mil posibilidades más. 

Al menos en el corto plazo, sin embargo, creo que la manera en la que los gobiernos usan e integran innovación tecnológica, incluida la IA, va a cambiar más despacio de lo que algunos anticipan. O al menos de una manera distinta a la que se anuncia en redes y medios.

Hace poco leí la historia de Oracle (Softwar), y ayuda a entender por qué muchas organizaciones – incluidas las Administraciones Públicas – prefieren las soluciones integradas (suites) frente a soluciones innovadoras “de nicho”. Entender la dicotomía entre suites versus soluciones de nicho, su evolución en la historia reciente, y su posible desarrollo futuro ayuda a mirar el “hype” de la IA con algo más de matiz, serenidad y profundidad. 

Porque la Historia no se repite, pero sí que rima.

El dominio de suites integradas en la década de los 2000

En los años 90, Larry Ellison, fundador de Oracle, lanzó una cruzada contra lo que consideraba un enfoque muy ineficiente para desarrollar, comprar e integrar aplicaciones de software dentro de las organizaciones:

Construir un sistema integrado a partir de varios productos de software diferentes que no fueron diseñados para trabajar juntos es complicado. En Oracle, solíamos vender y entregar estos sistemas 'de nicho'; la venta era fácil, la integración ya no. IBM tiene miles de consultores dispuestos a ofrecerte servicios de consultoría para ayudarte con esa tarea de integración. Cuanto más complejo es el proyecto de integración, más probable es que se retrase y supere el presupuesto. Incluso puede fallar por completo. Y al final, es el cliente quien asume el riesgo.

‍

Esto integrar productos de software 'de nicho’ solo pasa en la industria de software. Si Detroit funcionara como Silicon Valley, nadie vendería coches, solo componentes. Los clientes tendrían que averiguar cuáles son las 'mejores’ piezas — un motor Honda, una transmisión Ford, un chasis BMW, un sistema eléctrico GM —, comprarlas e intentar ensamblarlas en un coche que funcione. Buena suerte. Sé que suena a locura, pero así es como las empresas integran programas y aplicaciones de software hoy en día.

‍

Larry Ellison había identificado un problema que se había convertido en la pesadilla de muchas organizaciones de la época. Empresas y gobiernos tenían que gestionar un rompecabezas fragmentado de aplicaciones y bases de datos que hacía imposible gestionar las organizaciones. Esta cita de una entrevista con el exsecretario de Salud y Servicios Humanos del gobierno norteamericano, Tommy Thompson, da una buena idea de la situación a la que se enfrentaban muchos gestores públicos:

Tenemos más de 3.000 servidores diferentes y 2.900 empleados de IT. Tenemos 1.200 sistemas informáticos diferentes con distintas capacidades de correo electrónico, algunos de los cuales no se comunican entre sí. Tenemos 63.000 empleados pero 83.000 computadoras. Tenemos 12 divisiones operativas, todas las cuales establecen sus propios sistemas de IT, sus propios sistemas de contabilidad, su propio presupuesto, sus propios sistemas de relaciones públicas. Siguen sus propios procesos en recursos humanos, gestión de subvenciones, adquisiciones y logística. Tenemos 2.000 sitios web con 800.000 páginas y 981 números gratuitos. En una división, descubrí que teníamos 5 sistemas financieros, 13 sistemas de gestión de subvenciones, 6 sistemas de adquisición, 6 sistemas de personal y 13 sistemas de correo electrónico separados. ¿Cómo puedo dirigir un ministerio así?

‍

Esto también me recordó el concepto de "capas (layering)" de Jennifer Pahlka en Recoding America.

La mayoría de las organizaciones, pero particularmente las más antiguas y grandes — como las administraciones públicas—, han construido sus sistemas de forma incremental, a medida que surgen las necesidades, se establecen los procesos y se aprueban las políticas, leyes y reglamentos. Los gobiernos terminan con una madeja de sistemas que no se hablan entre sí.

Muchos proyectos de transformación digital son tanto un ejercicio de arqueología como una tarea de programación.

A lo largo de los años, los líderes de IT han intentado limpiar este desorden. Han favorecido cada vez más los sistemas integrados, las bases de datos con esquemas comunes y las aplicaciones de suite única que pueden comprar y operar de una manera más centralizada y segura. En la década de 2000 las suites integradas ganaron terreno, y empresas como Oracle, SAP o Microsoft se hicieron con una gran parte del mercado de software en esa época. 

En las administraciones públicas, la preferencia por las suites integradas no es solo una cuestión de las prioridades del departamento de IT. Las normas y prácticas de contratación pública hacen que sea mucho más fácil justificar una única compra a un gran proveedor que la de varias herramientas innovadoras, aunque sean aparentemente mejores. Los organismos de supervisión y auditoría castigan los fallos visibles, pero nunca recompensan las innovaciones exitosas. Así que los que tienen que tomar las decisiones de compra priorizan — racionalmente — la estabilidad sobre la experimentación.

Los costes ocultos de la coherencia

Las suites integradas tienen beneficios claros, pero buscar un enfoque "todo en uno" también tiene costes. El primero es obvio: los gobiernos que favorecen suites integradas a menudo tienen que conformarse con productos de segunda o tercera para muchas tareas (e.g., Copilot o Teams).

El enfoque “suite” también ralentiza la adopción de la innovación – y sospecho que esto lo veremos también en el ámbito de la IA. Por definición, las empresas de soluciones “de nicho” están empujando las fronteras en sus categorías. Si el departamento de IT prioriza la seguridad, el control y la integración sobre los beneficios que ofrece el mejor producto, la innovación se queda sin puntos en la licitación.

En una entrevista con Ben Thompson, Bret Taylor (antiguo CTO de Meta, que también fue presidente de Twitter, ejecutivo en Google y co-CEO en Salesforce, y es el actual presidente de OpenAI y fundador de una empresa de agentes de IA, Sierra) explicó por qué es importante quién toma la decisión de compra.

Cuando un departamento de negocio toma la decisión de comprar un software con el objetivo inequívoco de mejorar los resultados de su departamento, los costes de integración o el hecho de que la organización tenga ya una licencia con Microsoft u Oracle no importan mucho. Sin embargo, si IT es quien toma la decisión de compra, otras consideraciones importan más. Esto lleva a una paradoja:

Cuando IT compra una tecnología que se va distribuir a todos los empleados de una organización, el valor marginal de que el empleado número 46.000 tenga un app de chat mejor es bajo. Así que IT prefiere comprar tecnología "commodity". Sin embargo, si vas por el mundo, lo interesante es que...a menudo ves empresas donde el equipo de ingeniería tiene Slack y todos los demás tienen que usar Teams. Esto demuestra que para esa organización, el valor marginal de que sus ingenieros se comuniquen eficazmente es muy alto, y piensan, 'Sí, elegiremos el mejor producto'.

‍

Aunque pueden tener sentido para herramientas de software que deben llegar a todos los empleados de la organización, si una organización siempre elige la suite integrada, renunciará a innovaciones que pueden generar beneficios significativos.

Dónde tienen sentido las suites y dónde no

Como suele ocurrir, la dicotomía entre "suite integrada versus soluciones de nicho" es demasiado simple. Promover la innovación en el sector público exige un análisis más fino, ya que la cuestión varía mucho dependiendo del tipo de la tecnología de la que estemos hablando.

En los sistemas ERP (Enterprise Resource Planning), una suite integrada puede ser la elección correcta. Estos sistemas están estrechamente conectados con otras herramientas, y cambiar la aplicación tiene mil ramificaciones. Muchos de estos sistemas se estructuran para cumplir reglas de contabilidad o normativa laboral, leyes que son relativamente estables. Los procesos (workflows) a los que dan apoyo estos sistemas también son dificiles de cambiar, entre otras cosas porque muchas veces se han estructurado alrededor del uso de estas herramientas. Y por otro lado, los beneficios de innovar con estos sistemas no están muy claros. Así que, en este tipo de aplicaciones, el dilema suite vs. nicho a menudo se resuelve a favor de la suite.

Algo similar sucede con las aplicaciones de productividad y colaboración de los empleados: correo electrónico, calendario, edición de documentos, almacenamiento de archivos, chat, reuniones... Estos sistemas están altamente interconectados y, si bien hay una innovación significativa en el sector de aplicaciones de productividad, los riesgos de fallos de seguridad o disponibilidad si un nuevo sistema no funciona son altos. Además, estas aplicaciones también crean culturas y procesos a su alrededor que son difíciles de cambiar. El beneficio de una herramienta nueva tiene que estar muy claro para que una organización decida dejar el clásico Microsoft 365 (o Google Workspace para los más innovadores). En esta categoría, el dilema tiende a resolverse en una o dos suites principales para la base, más algunas adiciones estratégicas "de nicho" — Slack, Zoom, Notion... — cuando éstas son dramáticamente mejores o sirven a equipos específicos.

En otras áreas, sin embargo, las soluciones “de nicho" tienden a ganar. Esto es especialmente cierto para herramientas "de frontera" como plataformas de automatización y herramientas de IA verticalizadas, como las que está creando CivitPhone para atención ciudadana. La IA está cambiando extremadamente rápido —aparecen nuevos productos y capacidades cada semana — y el beneficio de elegir una herramienta genuinamente mejor puede ser sustancial para un servicio o equipo determinado, sobre todo si no implica grandes cambios en procesos o sistemas internos.

De momento se encuentran en la periferia y no en el núcleo de la organización: la mayoría de los otros sistemas no dependen de ellas para funcionar. Con el tiempo, es probable que algunas de estas capacidades se incorporen a suites más grandes. O quien sabe, quizá cualquier organización sea capaz de programar intuitivamente y en lenguaje natural (vibe code) sus propias soluciones, core y específicas, aunque lo dudo. Por ahora, sin embargo, todavía estamos en una fase fragmentada y experimental, particularmente en IA y automatización, y la necesidad de integrar y alinear las herramientas con procesos operativos, reglas internas y sistemas organizativos va a seguir siendo clave.

En resumen, el dilema suite integrada vs. soluciones de nicho se resuelve a favor de las suites cuando: (1) los procesos son altamente inter-funcionales y están estrechamente conectados; (2) la categorías es relativamente estable y está fuertemente regulada; y (3) el riesgo principal es el cumplimiento normativo en lugar de la velocidad de la innovación. Por el contrario, si la categoría está cambiando rápidamente y las innovaciones pueden ser una fuente clara de diferenciación o mejora de la productividad, las soluciones de IA pueden tener una oportunidad. 

La tarea de las Administraciones: equilibrar estabilidad con innovación

Después de haber leído Softwar, entiendo mejor por qué algunas organizaciones se aferran a Microsoft Teams cuando hay herramientas mucho mejores. Y, sin embargo, el "fundamentalismo de la suite" puede hacer que una organización pierda los importantes beneficios de adoptar innovaciones de manera dinámica.

Alguien decía que sobre-estimamos los impactos de la IA a corto plazo, pero subestimamos la transformación que va a suponer a largo plazo. Estoy de acuerdo.

La Historia nos muestra que la lógica organizativa y los incentivos institucionales retrasarán la adopción de innovaciones tecnológicas en las Administraciones Públicas. A largo plazo, sin embargo, la Inteligencia Artificial va a redefinir de manera radical tanto la función, como el funcionamiento de los gobiernos.

En el “mientras tanto” la clave para las Administraciones Públicas es saber cuándo apostar por la innovación, y cuándo no comprometer la estabilidad. Aquellos gobiernos que sepan combinar estabilidad con innovación serán los que naveguen mejor las movidas aguas que nos esperan.

‍

‍

* Firma invitada: Fernando Fernandez-Monge. Senior Associate en Bloomberg-Harvard City Leadership Initiative en la Universidad de Harvard e investigador en el Institute for Innovation and Public Purpose en University College London. Una versión anterior de este artículo apareció en el Newsletter DataPolis.

‍

‍

‍

‍

‍

‍

‍

‍

‍

‍