Proyectos TI archivos — Escritorio de Alejandro Barros /category/proyectos-ti/ En este espacio planteo ideas respecto de Innovación Pública y Modernización del Estado Mon, 08 Jun 2026 14:06:03 +0000 es hourly 1 https://wordpress.org/?v=7.1 /wp-content/uploads/2025/03/cropped-Alejandro-barros-sin-fondo-1-32x32.png Proyectos TI archivos — Escritorio de Alejandro Barros /category/proyectos-ti/ 32 32 La Dirección de Informática, donde la IA va a morir (también en el Estado) /la-direccion-de-informatica-donde-la-ia-va-a-morir/ /la-direccion-de-informatica-donde-la-ia-va-a-morir/#comments Mon, 08 Jun 2026 14:06:02 +0000 /?p=14067 Ethan Mollick ya lo diagnosticó para el mundo empresarial. En el sector público se comente el mismo error pero aumentado. Hace poco Ethan Mollick, académico de Wharton y autor de Co-Intelligence, publicó en The Economist una columna muy llamativa: «The IT department: where AI goes to die». La tesis es simple pero incómoda. Las organizaciones […]

La entrada La Dirección de Informática, donde la IA va a morir (también en el Estado) se publicó primero en Escritorio de Alejandro Barros.

]]>

Ethan Mollick ya lo diagnosticó para el mundo empresarial. En el sector público se comente el mismo error pero aumentado.

Hace poco Ethan Mollick, académico de Wharton y autor de Co-Intelligence, publicó en The Economist una columna muy llamativa: «The IT department: where AI goes to die». La tesis es simple pero incómoda. Las organizaciones están cometiendo un error estratégico al tratar la inteligencia artificial como si fuera otro software empresarial más: le asignan KPIs, la meten en los procesos existentes y se la entregan a la dirección (gerencia) de informática para que la administre.

Leí eso y pensé inmediatamente: en el sector público esto no solo aplica, sino que además se potencia.


El instinto de domesticar lo raro

Mollick habla del impulso de de-weird AI: des-rarificar la IA. Los ejecutivos están entrenados para normalizar las tecnologías nuevas y meterlas en categorías conocidas. Entonces la IA se convierte en un procesador de lógica difusa integrado a un flujo de trabajo, o en una herramienta que ahorra tiempo en una tarea. Una tecnología normal recibe un plan de implementación normal.

En el Estado, ese instinto es estructuralmente más fuerte. Las instituciones públicas tienen una tendencia orgánica a la normalización: marcos regulatorios, procesos de contratación, cultura del «esto siempre se ha hecho así», gestión de riesgos como dogma. Cuando llega algo verdaderamente disruptivo, el sistema lo procesa igual que siempre: lo convierte en un proyecto TI, le asigna un PMO, lo somete a control de cambios y listo.


El problema de fondo

No es que la IA sea difícil de implementar en el Estado. Es que el Estado tiende a aplanar lo que hace transformadora a esta tecnología, convirtiéndola en la última ola de automatización de oficinas. Y eso tiene consecuencias que van mucho más allá de la ineficiencia.


La trampa de la automatización en el sector público

Mollick identifica una segunda falla, más profunda: des-rarificar la IA lleva a las organizaciones a inclinarse hacia la automatización en lugar de la transformación. Cuando los líderes ven estudios que muestran ganancias de productividad del 30%, el instinto es cortar el 30% de la fuerza laboral.

En el sector público esto se traduce en algo diferente pero igualmente preocupante. La tentación no es tanto el despido masivo, sino la lógica del reemplazo de ventanilla: meter IA para que haga lo que hacía el funcionario, igual que antes, pero más barato. Automatizar el formulario, automatizar la respuesta, automatizar el trámite. El resultado: se digitalizan procesos que en muchos casos deberían haber sido rediseñados antes.


Lo que es realmente difícil es hacerse la pregunta correcta: ¿qué significa reconstruir un servicio público a partir del hecho de que un solo funcionario ahora puede hacer cien veces más?

Adaptado de Mollick, The Economist, abril 2026


¿Qué servicios nuevos se vuelven posibles? ¿Qué problemas que antes eran intratables pueden ahora resolverse?


El problema de pasarle la IA a la Dirección de TI

Aquí viene la parte que más me llamó la atención. Mollick es explícito: no es una crítica a los profesionales TI, que hacen trabajo esencial. Pero en la mayoría de las organizaciones su mandato es minimizar el riesgo.

En el Sector Público esto tiene nombre y apellido. La Dirección de TI de cualquier servicio público existe fundamentalmente para mantener los sistemas operando, gestionar la seguridad, controlar el acceso a la información y cumplir con los estándares normativos. Todo eso es necesario y valioso. Pero la IA exige algo diametralmente opuesto: experimentar, tolerar el fracaso, aceptar que nadie sabe todavía cuál es la forma correcta de usar estas herramientas.

Pasarle el control exclusivo de la IA a un departamento cuya misión central es eliminar el riesgo es un error según Mollick, premisa que comparto. En el sector público ese error se amplifica porque además la Dirección de TI suele no tener autoridad para modificar los procesos de negocio, que están en manos de otras áreas.


El error de categoría en el Estado

No es que informática sea mala. Es que pedirle a la dirección TI que lidere la transformación con IA es como pedirle al departamento de control de calidad que invente los nuevos productos. Tienen capacidades distintas para objetivos distintos.


El modelo Liderazgo–Multitud–Laboratorio

Mollick propone un modelo de tres partes. Vale la pena mirarlo desde la perspectiva del sector público.

  • Liderazgo – el problema de la delegación hacia abajo. El CEO y los altos directivos no pueden delegar la estrategia de IA a la gerencia media o a informática. Tienen que articular una visión sobre cómo la IA cambia lo que la organización es, no solo cómo opera. En el Estado esto es un desafío enorme. Los jefes de servicio tienen mandatos acotados, presión por resultados de corto plazo y una rotación que en muchos casos hace difícil sostener una visión estratégica de mediano plazo. El ciclo político es de cuatro años, y la IA requiere apuestas que maduran en tiempos distintos. Además, la cultura institucional premia al directivo que no se mete en problemas, no al que experimenta y falla productivamente.


  • La Multitud – los funcionarios saben más de lo que creemos. Cuando los empleados tienen acceso a herramientas de IA y permiso para experimentar, descubren casos de uso que ni las propias empresas de IA anticiparon. La IA es más efectiva en manos de expertos, y la multitud es donde nacen las mejores ideas. En el sector público esto tiene una dimensión adicional. Los funcionarios de primera línea conocen los problemas reales de los usuarios. Conocen los cuellos de botella, las excepciones, los casos que no caben en los formularios. Si se les da acceso y permiso, tienen la materia prima más valiosa: el conocimiento del dominio. El problema es que la cultura institucional pública rara vez les da ese permiso. El uso de IA no autorizado se castiga o se ignora. Los funcionarios que encuentran formas de ser más productivos lo hacen a escondidas, sin reconocimiento y sin que el aprendizaje se sistematice.


  • El Laboratorio – la estructura que falta. Mollick habla de un equipo de personas técnicas y no técnicas que trabaje con IA generativa a tiempo completo, empuje límites y retroalimente a la organización. Dice que le sorprende cuántas empresas grandes todavía no tienen esto. En el sector público, la situación es aún más precaria. Iniciativas como el Laboratorio de Gobierno fueron apuestas interesantes, pero la institucionalidad para sostener ese trabajo de forma permanente —con mandato claro, financiamiento estable y poder de incidencia— sigue siendo frágil.



El uso oculto de IA en el Estado: el problema que nadie mide


Mollick cierra con una observación que en el sector público tiene consecuencias especialmente serias. Cuando las organizaciones no crean los incentivos correctos, los empleados responden racionalmente: ocultan su uso de IA. Algunos temen el castigo. Otros no confían en que las ganancias de productividad se compartan con ellos. Algunos trabajan 90% menos y no ven razón para comentarlo.

En el Estado esto se complejiza. Un funcionario que usa IA para hacer su trabajo más rápido enfrenta preguntas sin respuesta: ¿Está autorizado esto? ¿Qué pasa con la confidencialidad de los datos? ¿Puedo usar IA con información de ciudadanos? La ausencia de marcos claros genera la respuesta más racional posible: silencio.


Lo que no se ve no se puede gestionar

Hoy existe en el sector público de nuestros países un uso masivo, silencioso e informal de herramientas de IA. Ese uso está ocurriendo igual, con o sin política. La pregunta es si va a ocurrir de forma caótica y oculta, o de forma estratégica y con aprendizaje institucional.


¿Qué hacer entonces?


No tengo una receta mágica, pero sí algunas convicciones que el análisis de Mollick refuerza:

  1. El liderazgo político y directivo tiene que hacerse cargo. No es un tema de informática. Es un tema de modernización del Estado, de calidad de servicio, de productividad pública. Requiere que los jefes de servicio lo pongan en su agenda personal, lo usen, lo entiendan y lo articulen.

  2. Hay que crear espacios para que los funcionarios experimenten con permiso explícito. Eso implica marcos regulatorios claros, guías de uso, y una cultura donde el experimento fallido no se castiga sino que se aprende.

  3. La IA no puede ser solo un proyecto de la Dirección de Informática. Requiere equipos multidisciplinarios con poder de incidencia sobre los procesos de negocio, no solo sobre la infraestructura tecnológica.

  4. Hay que tener la honestidad de reconocer que nadie tiene el mapa todavía. Como dice Mollick: no navegas territorio extraño pretendiendo que tus mapas viejos funcionan. El Estado chileno necesita construir capacidad de exploración, no solo de control.




Este post está basado en las ideas del artículo de Ethan Mollick «The IT department: where AI goes to die». Las reflexiones sobre el sector público son propias.

📄 Fuente original: Ethan Mollick — The Economist, 1 de abril de 2026. Mollick es profesor asociado en Wharton y autor de Co-Intelligence: Living and Working with AI.

La entrada La Dirección de Informática, donde la IA va a morir (también en el Estado) se publicó primero en Escritorio de Alejandro Barros.

]]>
/la-direccion-de-informatica-donde-la-ia-va-a-morir/feed/ 8
La trampa de la unicidad: tu proyecto NO es tan especial /la-trampa-de-la-unicidad-tu-proyecto-no-es-tan-especial/ /la-trampa-de-la-unicidad-tu-proyecto-no-es-tan-especial/#respond Thu, 19 Jun 2025 21:25:38 +0000 /?p=13416 Un estudio de 1.300 proyectos TI prueba que cada punto de “unicidad percibida” infla los costos en 5 puntos porcentuales. Antes de que la ilusión de ser irrepetible se coma tu presupuesto intenta mira tu proyecto evitando (o al menos reduciendo) el sesgo de unicidad. Hace unos meses Bent Flyvberg de la Universidad de Oxford, […]

La entrada La trampa de la unicidad: tu proyecto NO es tan especial se publicó primero en Escritorio de Alejandro Barros.

]]>
una persona frente al computador, pensando que el proyecto es único, pero generando sobrecostos

Un estudio de 1.300 proyectos TI prueba que cada punto de “unicidad percibida” infla los costos en 5 puntos porcentuales. Antes de que la ilusión de ser irrepetible se coma tu presupuesto intenta mira tu proyecto evitando (o al menos reduciendo) el sesgo de unicidad.

Hace unos meses Bent Flyvberg de la Universidad de Oxford, con quien he intercambiado interesantes correos electrónicos, junto a algunos colegas publicó el artículo The Uniqueness Trap en la prestigiosa publicación Harvard Business Review. Quiero recordar que Flyvberg es un experto en materia de análisis de desempeño de proyecto, tanto en el sector público como privado; cuenta con una amplia base de análisis.  Lo he referenciado en un par de oportunidades en este sitio, con su publicación: Why your IT Project may be riskier than you think (referenciando los proyectos Cisne Negro) en 2011, y más recientemente con su artículo en el que analiza el comportamiento de los sobrecostos y la distribución (del tipo cola larga) que estos siguen, The Empirical Reality of IT Project Cost Overruns: Discovering A Power-Law Distribution.

En su último articulo (marzo-2025), The Uniqueness Trap (la trampa de la unicidad), analiza el fenómeno del sesgo de unicidad en el diseño de los proyectos TI, para lo cual analizó una cantidad relevante de proyectos.

Cuando los equipos de proyecto proclaman que su iniciativa no se parece a ninguna otra, en realidad están cavando su propia tumba presupuestaria. Esa autopercepción no es inocua: por cada punto adicional que alguien se declara “único”, el presupuesto se mueve (aumenta) cinco puntos porcentuales; y los proyectos que obtuvieron la nota máxima acabaron con un sobrecosto promedio del 45 %. Lo más irónico, es que ninguno de los 59 declarados como proyectos únicos resultó, en los hechos, verdaderamente único: siempre existían precedentes internos o sectoriales que podrían haber servido de guía  .

Estos datos deberían encender todas las alarmas en la administración pública. Si alguna plataforma de ventanilla única, licitación electrónica o registro ciudadano se autodefine como irrepetible, conviene asumir de entrada que el costo real podría inflarse entre un 25% y un 45%.



¿De qué tamaño es el problema?

Algunas de las principales conclusiones del estudio de Flyvberg y sus colegas son:

  • 1.300 proyectos TI analizados en 34 organizaciones.  
  • 28% de los responsables calificó su iniciativa con ≥ 7/10 en “unicidad percibida”, la escala de unicidad va de 1 a 10.  
  • Por cada punto adicional de mi proyecto «es único”, el sobrecosto sube +5 puntos porcentuales.  
  • Los proyectos con 10/10 en unicidad cerraron, en promedio, con +45% de desviación presupuestaria.  
  • 0 de los 59 proyectos catalogados como totlamente únicos (10 puntos de unicidad), resultó realmente ser único: siempre había precedentes internos o sectoriales.  



Medidas de mitigación

Pero Flyvberg y sus colegas no solo plantean un diagnóstico, propone algunas medidas de mitigación, entre las que desatacan:

  • Pronóstico por clase de referencia (Reference Class Forecasting): Antes de fijar presupuesto y plazo, se identifica una “clase” de proyectos comparables (por ejemplo, otras ventanillas únicas estatales) y se extraen sus cifras reales de costo y duración. Esa base empírica se usa como punto de partida, corrigiendo la tendencia natural a subestimar riesgos internos. La literatura muestra que esta simple disciplina puede mejorar la precisión de las estimaciones en torno al 25 %.  
  • Pronóstico basado en similitudes (Similarity-Based Forecasting): El proyecto se descompone en módulos (autenticación, gestión de flujos, analítica) y, para cada uno, se buscan “gemelos” ya implantados en otras instituciones. Con ese espejo modular se afinan costos, secuencia de hitos y complejidades técnicas, reduciendo la varianza de plazos hasta en un 30 %.  
  • Premortem: Antes de comenzar, el equipo se sitúa mentalmente en un escenario donde el proyecto fracasó y responde: “¿qué salió mal?”. Este ejercicio de retrospectiva anticipada obliga a explicitar supuestos ocultos y suele destapar una quincena de riesgos adicionales que no emergen en las revisiones tradicionales.  
  • Auditoría de ruido (Noise Audit): Se solicitan estimaciones independientes (costos, plazo) a distintos evaluadores y se mide la dispersión. Cuando las cifras varían demasiado, no se promedian: se debate la causa de la divergencia hasta converger en una hipótesis única y consistente, lo que reduce el “ruido” de juicio en torno al 20%

A las medidas propuestas por Flyvberg y sus colegas, agregaría de mi cosecha: hacer estimaciones (costos y esfuerzo) por diferentes métodos, si en ambos casos se llega a resultados similares, significa que ese es el número.




Mi gran conclusión es:




La entrada La trampa de la unicidad: tu proyecto NO es tan especial se publicó primero en Escritorio de Alejandro Barros.

]]>
/la-trampa-de-la-unicidad-tu-proyecto-no-es-tan-especial/feed/ 0
Los modelos de lenguaje no piensan — solo imitan muy bien /los-modelos-de-lenguaje-no-piensan-solo-imitan-muy-bien/ /los-modelos-de-lenguaje-no-piensan-solo-imitan-muy-bien/#respond Fri, 06 Jun 2025 16:45:42 +0000 /?p=13376 Con el avance de modelos como ChatGPT, Claude, DeepSeek o Gemini, una pregunta se ha vuelto recurrente (y no sólo en círculos técnicos), de hecho me la hacen con bastante frecuencia: ¿estos sistemas (grandes modelos de lenguaje o LLM) realmente piensan? Recordemos que «pensar» en los seres humanos debiera tener al menos los siguientes atributos […]

La entrada Los modelos de lenguaje no piensan — solo imitan muy bien se publicó primero en Escritorio de Alejandro Barros.

]]>

Aunque parezcan inteligentes, los LLM no razonan, no entienden y no planifican. Solo predicen palabras. Y en tareas complejas, esa ilusión de pensamiento colapsa por completo.

Con el avance de modelos como ChatGPT, Claude, DeepSeek o Gemini, una pregunta se ha vuelto recurrente (y no sólo en círculos técnicos), de hecho me la hacen con bastante frecuencia:



¿estos sistemas (grandes modelos de lenguaje o LLM) realmente piensan?


Recordemos que «pensar» en los seres humanos debiera tener al menos los siguientes atributos (probablemente faltan varios atributos más): i) representaciones mentales internas, ii) propósito, intención y consciencia, iii) planificación deliberada, abstracción y autocorrección y iv) razonamiento causal y flexible frente a nuevas situaciones al menos.

En el caso de los LLM, parecen resolver problemas, generar explicaciones paso a paso e incluso «reflexionar» antes de responder.

La respuesta, sin embargo, es menos espectacular de lo que parece: no, no piensan o, al menos, no en el sentido en que lo hace un ser humano.


La ilusión del pensamiento

Un reciente estudio publicado, La Ilusión de Pensar (The Illusion of Thinking), el que se adjunta al final del post, escrito por investigadores de la empresa Apple, y que viene a profundizar un análisis realizado en 2024, sobre las limitaciones del razonamiento matemático de los modelos de lenguaje (GSM-Symbolic: Understanding the Limitations of Mathematical Reasoning in Large Language Models).

La Ilusión de Pensar, analiza modelos diseñados específicamente para tareas de razonamiento –los llamados Large Reasoning Models o LRMs, los cuales corresponden a modelos de lenguaje tradicionales (LLM) más sofisticados. El objetivo del análisis fue validar si estos modelos son capaces de realizar razonamientos complejos más allá de simplemente acertar con la respuesta final.

Las principales ideas desarrolladas en el análisis son:

  • Evaluación tradicional es insuficiente: Los benchmarks matemáticos actuales (como MATH500) están contaminados por datos del entrenamiento y no permiten observar el proceso de razonamiento, sólo la respuesta final.
  • Uso de puzzles controlados como nuevo enfoque: El estudio propone un conjunto de puzzles con dificultad ajustable (Torres de Hanoi, Salto de Fichas, Cruce del Río y Mundo de Bloques). Esto permite observar cómo evolucionan las respuestas y el razonamiento a medida que aumenta la complejidad del problema.
  • Tres regímenes de comportamiento según la complejidad
    • Baja complejidad: los modelos sin razonamiento (LLMs estándar) son más precisos y eficientes.
    • Complejidad media: los LRMs muestran ventaja al usar pensamiento encadenado (Chain of Thought).
    • Alta complejidad: ambos modelos colapsan; la precisión cae a cero.
  • Limitaciones en escalabilidad del razonamiento: Los LRMs inicialmente aumentan su esfuerzo (tokens usados) al crecer la complejidad, pero luego este esfuerzo disminuye inesperadamente, aún con presupuesto de tokens disponible. Lo que sugiere una limitación estructural en su capacidad de escalar el razonamiento.
  • Problemas en la coherencia del razonamiento: Aun cuando encuentran soluciones correctas, los modelos tienden a seguir pensando (overthinking), desperdiciando tokens. En problemas complejos, fallan en autocorregirse y no llegan a la solución.
  • Fracaso en la ejecución de algoritmos dados: Incluso cuando se les proporciona un algoritmo explícito (por ejemplo, para Torres de Hanoi), los LRMs fallan en ejecutarlo correctamente a partir de cierta complejidad. Lo que revela debilidades en su capacidad para seguir instrucciones lógicas paso a paso.
  • Comportamientos erráticos y dependientes del contexto: La calidad del razonamiento depende del tipo de problema. Por ejemplo, el modelo funciona bien en Hanoi hasta 100 movimientos, pero falla en Cruce del Río tras solo 4 pasos.  Esto sugiere que su éxito podría depender del entrenamiento previo y la familiaridad con problemas similares.

El resultado final es bastante revelador: 

  • En tareas simples o de complejidad media, los LRMs pueden ser más efectivos que los modelos estándar. 
  • Pero cuando la complejidad aumenta, todos colapsan: fallan de manera consistente, incluso si se les entrega el algoritmo correcto o se amplía su presupuesto de tokens. 
  • Peor aún, en algunos casos empiezan a «pensar menos» a medida que la tarea se vuelve más difícil.

Lo que estos modelos hacen, en el fondo, es generar texto que se parece al razonamiento. No comprenden, no planifican, no abstraen: solo predicen la siguiente palabra basada en correlaciones aprendidas a partir de enormes cantidades de texto.

El reconocido experto mundial en materias de Inteligencia Artificial, Gary Marcus, plantea a propósito de la misma investigación, la siguiente pregunta: ¿Un golpe de gracia para los LLM? el mismo Marcus se da tiempo para rebatir cada uno de los argumentos en contra del referido paper. Aquí otra referencia en el prestigioso periódico inglés The Guardian.


¿Por qué nos parecen tan inteligentes?

Porque imitan muy bien cómo escribimos cuando pensamos. Pueden usar frases como: “déjame revisar eso” o “si A implica B, entonces…”, pero eso no implica que estén realmente razonando. No hay comprensión ni intención detrás del texto. Solo estadística y patrones.

Este fenómeno –la ilusión de pensamiento– es poderoso, y a veces útil. Pero también puede llevarnos a sobreestimar la inteligencia de estos sistemas, y confiar en ellos para tareas que aún están muy lejos de poder manejar.


¿Y entonces?

Que un sistema sea capaz de «razonar» no significa que esté pensando. Significa que ha aprendido a simular razonamiento con un grado de eficiencia que puede ser útil… pero también profundamente limitado (son buenos imitadores).







La entrada Los modelos de lenguaje no piensan — solo imitan muy bien se publicó primero en Escritorio de Alejandro Barros.

]]>
/los-modelos-de-lenguaje-no-piensan-solo-imitan-muy-bien/feed/ 0
Sobrecostos en proyectos TI públicos: evidencias que no podemos seguir ignorando /sobrecostos-en-proyectos-ti-publicos-evidencias-que-no-podemos-seguir-ignorando/ /sobrecostos-en-proyectos-ti-publicos-evidencias-que-no-podemos-seguir-ignorando/#comments Fri, 16 May 2025 13:30:00 +0000 /?p=13257 Desde hace bastantes años que el investigador Bent Flyvberg de la Universidad de Oxford, está analizando el comportamiento de los proyectos TI, en particular respecto de sus costos y tiempos de ejecución, ya en 2011 publicó un artículo Why your IT Project may be riskier than you think en la Harvard Business Review mostrando el […]

La entrada Sobrecostos en proyectos TI públicos: evidencias que no podemos seguir ignorando se publicó primero en Escritorio de Alejandro Barros.

]]>
imagen de una persona preocupada por el incremento de los costos (IA Generativa)

Según estudio, los sobrecostos en proyectos TI del sector Público llegan hasta el 110%, por sobre los proyectos en el mundo privado.

Desde hace bastantes años que el investigador Bent Flyvberg de la Universidad de Oxford, está analizando el comportamiento de los proyectos TI, en particular respecto de sus costos y tiempos de ejecución, ya en 2011 publicó un artículo Why your IT Project may be riskier than you think en la Harvard Business Review mostrando el pobre despeño de los proyectos TI, en su artículo habla de los denominados Proyectos Cisne Negro.

En los últimos años, Flyvberg actualizó su análisis y publicó el paper The Empirical Reality of IT Project Cost Overruns: Discovering A Power-Law Distribution (disponible al final del post),  con una muestra aún mayor que su análisis del 2011, la muestra es de 5.392 proyectos por un valor total de 56.500 millones de dólares, de los cuales el 61% (2.759) de los proyectos corresponden al sector público y 39% (1.748) al sector privado.  Adicionalmente, para construir la muestra, existió preocupación de que los proyectos fueran de diversa índole, de forma que el análisis fuera lo más representativo posible, siendo a la fecha el estudio más grande en el área.

Una de las cosas interesantes que mostró su estudio es que los sobrecostos de los proyectos no siguen una distribución normal como se pensaba en algún momento, sino una distribución de ley de potencias (power-law distribution). Esto implica que, aunque muchos proyectos tienen sobrecostos pequeños, existe una “cola larga” de proyectos con sobrecostos extremadamente altos que ocurren con más frecuencia de lo que se espera bajo un modelo estadístico tradicional.

Según Flyvberg, lo que explicaría que los sobrecostos sigan estas distribuciones es la interdependencia entre componentes tecnológicos: una falla en un componente puede desencadenar errores en cascada.


curva de distribución de los sobrecostos en los proyectos TI
Fuente: The Empirical Reality of IT Project Cost Overruns: Discovering A Power-Law Distribution


Sector Público versus Sector Privado

Al revisar lo que ocurre en los proyectos del sector público versus el sector privado, se aprecia un peor desempeño de los del sector público.



comparación públicos versus privados
Fuente: The Empirical Reality of IT Project Cost Overruns: Discovering A Power-Law Distribution


El sector público tiene en promedio mayores sobrecostos que el privado.  Aunque el sector privado tiene casos más extremos (mayor sobrecosto registrado), el comportamiento agregado del sector público es más riesgoso en términos de desviación presupuestaria. Esto sugiere que el sector público subestima más consistentemente los costos reales, lo que puede deberse a: i) procesos de planificación menos rigurosos, ii) incentivos débiles para el control de gastos, iii) mayor complejidad burocrática o política.


Factores que explican el mal desempeño en el sector público

  • Falta de incentivos directos para controlar costos y plazos.
  • Alta complejidad institucional y multiplicidad de actores involucrados.
  • Presiones políticas que llevan a estimaciones optimistas o irreales.
  • Cambios frecuentes de autoridades o prioridades tras elecciones.
  • Capacidades técnicas dispares o insuficientes en gestión de proyectos TI.
  • Dependencia excesiva de consultores externos y procesos de licitación lentos.


Recomendaciones para mejorar la ejecución de proyectos TI públicos

  • Adoptar enfoques de gestión de riesgos que reconozcan la existencia de eventos extremos (cola gruesa).
  • Establecer mecanismos de rendición de cuentas claros y responsables técnicos permanentes.
  • Mejorar las capacidades internas en gestión de proyectos tecnológicos.
  • Incorporar márgenes de contingencia realistas en estimaciones presupuestarias y de cronograma.
  • Evaluar críticamente la viabilidad de proyectos antes de su aprobación, incluyendo análisis probabilístico.
  • Evitar cambios arbitrarios en el alcance durante la ejecución del proyecto.
  • Fortalecer la continuidad institucional y la gobernanza de programas estratégicos más allá del ciclo político.

Y por supuesto adoptar el enfoque de proyectos delfines en lugar de proyectos ballenas, enfoque recomendado por diversos estudios de la Universidad de Oxford y que promuevo hace años.


delfines en lugar de ballenas


Conclusión

El estudio de Flyvbjerg et al. deja en evidencia que los proyectos de TI, especialmente en el sector público, no fracasan por azar, sino por fallas sistémicas que pueden y deben corregirse.

Asumir que los riesgos son mayores de lo estimado, y que pueden escalar rápidamente si no se controlan, es el primer paso hacia una transformación realista y eficiente de la inversión pública en tecnología.

Una pregunta que queda dando vueltas es con las nuevas tecnologías y en particular el rol que tendrá la IA en los procesos de gestión, desarrollo de software y otros:




Información Complementaria

The Empirical Reality of IT Project Cost Overruns: Discovering A Power-Law Distribution

La entrada Sobrecostos en proyectos TI públicos: evidencias que no podemos seguir ignorando se publicó primero en Escritorio de Alejandro Barros.

]]>
/sobrecostos-en-proyectos-ti-publicos-evidencias-que-no-podemos-seguir-ignorando/feed/ 6
Servicios Transversales, ¡animal de gran tamaño! /servicios-transversales-animal-de-gran-tamano/ /servicios-transversales-animal-de-gran-tamano/#comments Tue, 15 Oct 2024 17:42:34 +0000 /?p=12636 Este post fue desarrollado en conjunto con mi amigo y colega del Centro de Sistemas Públicos Pablo Galaz Painecura 260 millones de transacciones al mes, no es poco, de hecho es mucho más que redes transaccionales tradicionales. El proceso de implementación de la Ley de Transformación Digital del Estado (Ley N°21.180) viene aparejado de la […]

La entrada Servicios Transversales, ¡animal de gran tamaño! se publicó primero en Escritorio de Alejandro Barros.

]]>
Datacenter procesando transacciones



Este post fue desarrollado en conjunto con mi amigo y colega del Centro de Sistemas Públicos Pablo Galaz Painecura



260 millones de transacciones al mes, no es poco, de hecho es mucho más que redes transaccionales tradicionales.

El proceso de implementación de la Ley de Transformación Digital del Estado (Ley N°21.180) viene aparejado de la puesta en marcha de un conjunto de servicios compartidos (también llamados share services) cuyo diseño y operación dependen de la actual Secretaría de Gobierno Digital del Ministerio de Hacienda. En base a las cifras históricas de uso de estos servicios estimamos que en un escenario de plena operación de la Ley – es decir, todos los organismos públicos hacen uso de estos servicios compartidos – se requiere de una institucional y gobernanza que dé respuesta al tamaño del desafío.

Los servicios compartidos deben ser entendidos como “servicios de misión crítica”, en cuanto deben cumplir con una serie de atributos, siendo cada uno un desafío en sí mismo.

  • Alta disponibilidad: Deben funcionar de manera continua, con tiempos de inactividad mínimos.
  • Confiabilidad: Deben operar sin errores durante largos periodos. La confiabilidad se mide en términos de tiempo medio entre fallos (MTBF) y tiempo medio para la reparación (MTTR), con el objetivo de minimizar el tiempo fuera de servicio.
  • Redundancia: Para garantizar la disponibilidad y confiabilidad, los sistemas de misión crítica suelen tener componentes redundantes.
  • Tolerancia a fallos: Incorporan mecanismos que permiten al sistema seguir funcionando incluso cuando ocurren fallos.
  • Seguridad: Dado que la interrupción o fallo de estos sistemas puede tener consecuencias graves, cuentan con medidas de seguridad robustas para proteger contra ciberataques, acceso no autorizado y otros riesgos.
  • Mantenimiento proactivo: Para evitar fallos, se llevan a cabo tareas de mantenimiento preventivo y monitoreo constante del rendimiento del sistema para detectar posibles problemas antes de que se conviertan en fallos.
  • Rendimiento predecible: Deben cumplir con requisitos de rendimiento específicos, como tiempos de respuesta o capacidad de procesamiento, incluso bajo cargas de trabajo elevadas.
  • Recuperación ante desastres: Incorporan planes y mecanismos de recuperación ante desastres para restaurar la funcionalidad en caso de que ocurra un evento catastrófico, como un corte de energía o un desastre natural.


Sistemas de Soporte a la TD y su evolución en el tiempo

A continuación, se revisan los servicios compartidos que debiesen operar transversalmente en todas las entidades públicas en los próximos años, incluyendo cifras sobre el volumen transaccional que se encuentra disponible en el Portal de Datos abiertos del Estado.


  • Clave Única: Servicio centralizado de autenticación digital, a disposición de las instituciones públicas para facilitar el acceso de la ciudadanía a sus servicios y plataformas digitales de manera segura. La pandemia de COVID-19 gatilla un crecimiento significativo de su uso, alcanzando 54 millones de autenticaciones en agosto 2020. El máximo histórico se registra en abril 2021, con 88 millones de autenticaciones en ese mes. Cifras disponibles para el año 2024 muestran del orden de 40 millones de autenticaciones mensuales. Este servicio ya lo había analizado en el pasado mostrando su volumen transaccional, planteando algunas dudas frente al entendimiento de su criticidad


serie de tiempo enero 2018-agosto 2024 de la cantidad de transacciones de clave unica



  • FirmaGob: Firma Electrónica Avanzada para funcionarios del Estado con el objeto de que las instituciones públicas puedan autogestionar la emisión y gestión de certificados para sus autoridades o funcionarios autorizados por los Ministros de fe de cada organismo, para la firma digital de documentos. Exceptuando las cifras informadas para enero 2022, se observa una clara tendencia en su uso. El uso promedio el 2024 representa 2,2 millones de firmas mensuales, equivalente al valor máximo alcanzado durante el año 2023 (diciembre). Es razonable esperar que dicho promedio aumente, considerando la tendencia al alza en los últimos meses, llegando a 2,8 millones de firmas en agosto 2024.


serie de tiempo enero 2022-junio 2024 de la cantidad de transacciones de firmas digitales



  • PISEE: Plataforma descentralizada del Estado que permite el intercambio de datos, documentos y expedientes entre las instituciones públicas. Este nuevo modelo busca disminuir los tiempos de conexión entre organismos, cuidando la ciberseguridad y apoyando la digitalización y agilidad del Estado. Incluyendo tanto transacciones exitosas como fallidas, se constata un alza sostenida en los últimos tres años. El máximo histórico se observa en julio 2023, con más de 45 millones de transacciones vía PISEE solo ese mes. Y en lo que va de 2024, se constata un aumento de 27% en la cantidad de transacciones promedio mensuales vía PISSE, con dos máximos en los meses de enero (34 millones) y mayo (38 millones).


serie de tiempo enero 2018-junio 2024 de la cantidad de transacciones de interoperabilidad (PISEE)



  • DocDigital: Plataforma para la tramitación, envío y recepción digital de comunicaciones oficiales entre organismos del Estado, tales como oficios, resoluciones y convenios, entre otros. Las cifras muestra que su uso fue relativamente estable durante los años 2022 y 2023, con cifras mensuales que varían entre 100 mil y 130 mil firmas mensuales. Dicho comportamiento cambia durante el 2024, registrándose – en promedio – más de 150 mil firmas mensuales (aumento de 40% respecto 2023), con un máximo de 211 mil firmas en julio 2024.


serie de tiempo enero 2020-junio 2024 de la cantidad de transacciones de documentos digitales



Pero además veremos a futuro un nuevo servicio, notificaciones.

  • Notificaciones:  Plataforma de notificaciones a los ciudadanos, la cual se encuentra en etapa de diseño y desarrollo.


Potencial transaccional y dimensión de criticidad

Al analizar los flujos y volúmenes que hoy tienen cada uno de estos servicios podémoste estimar el tamaño del procesamiento, pero partámos por algunos supuestos

  • La cantidad de instituciones (universo de la ley) es de aproximadamente 1000 (esta cifra está tomada desde los servicios inscritos en el sistema de compras públicas, que considera un universo similar a la ley 21.180)
  • Suponemos un valor promedio de transacciones por institución en base al último año de operación (para poder tener una métrica más precisa, se requiere caracterizar por tipología de institución)
  • En el caso del servicio de notificaciones, la estimación se basa en el historial de envío de cartas certificadas identificado en el estudio de métricas realizado por la Secretaría de Gobierno Digital), lo cual en dicho estudio tiene una gran varianza entre promedio y máximo (un par de órdenes de magnitud), se utilizó el valor promedio.
  • En el caso de FirmaDoc suponemos que al menos hay una persona por instituciones habilitada con firma digital
  • Que todas las instituciones que faltan del universo van a utilizar estos servicios
  • Se consideraron transacciones de negocios y no las unitarias (cada proceso gatilla varias transacciones granulares) por lo que el número podría aumentar de forma importante
  • Otra forma en que el volumen trnasaccional podría crecer en forma significativa, es si alguno de estos servicios se abren para que puedan ser usados en el sector privado, como se ha mencionado en el caso de Clave Única.


Como número de referencia, estimamos que el potencial de uso de los servicios descritos podría alcanzar del orden de 260 millones de transacciones mensuales.


La estimación no es exacta, en cuando considera el promedio mensual de transacciones de los últimos 12 meses con información disponible para cada servicio transversal, la cual es extrapolada linealmente considerando que el universo de la Ley de Transformación digital es de – al menos – 1.000 servicios (número aproximado de entidades inscritos en el Sistemas de Compras Públicas).

Ciertamente, esta estimación puede ser mucho mejor. Sin embargo, los datos disponibles no permiten conocer – por ejemplo – cómo ha evolucionado el número de instituciones que usan cada servicio en el tiempo, ni tampoco una categoría que permita asociado una clasificación de intensidad de uso.





Bajo el supuesto de que el uso de los servicios se concentra durante 16 horas al día, la caída – por ejemplo – del servicio Clave Única podría implicar del orden de 190 mil autentificaciones que no podrían realizarse por hora. Y en el caso de PISEE, estamos hablando de más de 335 mil transacciones por hora. En el peor de los mundos, una caída transversal de todos los servicios podría implicar cerca de 500 mil transacciones fallidas en una hora.

Solo a modo de reflexión las principales redes transaccionales de nuestro país procesan (fuentes de información al final del artículo)


cantidad de transacciones de otras redes (banca online, comercio, cajeros automáticos)


Varias interrogantes

Como se puede apreciar los servicios transversales de misión crítica pueden llegar a cerca del triple de transacciones que realiza toda la industria financiera en Chile por su canal online, y cerca de 10 veces la red de cajeros automáticos del Chile.  En el caso del comercio electrónico y llevando las cifras del CyberDay a valores mensuales (proyección lineal), estamos hablando que son 5 veces más.


Con esto en mente surgen varias interrogantes:

  • ¿Estamos preparados para gestionar una red de este tamaño y no me refiero sólo al soporte tecnológico?
  • ¿Cuál debiera ser el rol de los privados en el producción de este tipo servicios (lógica de co-producción en una modalidad de PPP)?
  • ¿Basta con poner más recursos, o más bien tenemos que repensar el modelo de prestación de servicios digital transversales?
  • ¿El arreglo institucional actual es el adecuado para la operación de estos servicios de misión crítica?



Información Complementaria

La entrada Servicios Transversales, ¡animal de gran tamaño! se publicó primero en Escritorio de Alejandro Barros.

]]>
/servicios-transversales-animal-de-gran-tamano/feed/ 2