Tu empresa no tiene un problema tecnológico

Hay una idea que se repite mucho en comités de dirección y conversaciones con responsables IT: “tenemos un problema tecnológico”. Después de más de 25 años trabajando en desarrollo de software y viendo la evolución de las empresas —desde sistemas en COBOL, pasando por el efecto 2000, el cambio al euro y ahora la ola de la inteligencia artificial— puedo decir con bastante seguridad que, en la mayoría de los casos, esa afirmación está mal enfocada.

El problema no suele ser la tecnología. El problema es la dependencia. Dependencia de personas concretas, de proveedores que concentran el conocimiento o de sistemas que han crecido sin un diseño claro y que funcionan, sí, pero sin que nadie tenga una visión completa de cómo ni por qué.

Este patrón no es nuevo. A finales de los 90, con el efecto 2000, muchas empresas descubrieron que tenían sistemas críticos funcionando sobre código que nadie había revisado en años. No era raro encontrar aplicaciones que llevaban décadas en producción, modificadas por distintas personas, sin documentación real y con lógica de negocio incrustada en lugares que nadie recordaba. El miedo no era tanto que los sistemas fallaran —que también—, sino que, si fallaban, nadie sabría por dónde empezar a arreglarlos.

Aquello obligó a hacer algo que se había ido posponiendo durante años: entender de verdad los sistemas, documentarlos, revisar dependencias y, en muchos casos, rehacer partes críticas. No fue una crisis tecnológica, fue una crisis de conocimiento y de control.

Pocos años después, con la llegada del euro, vivimos algo muy parecido, aunque con otro enfoque. En teoría, el cambio era “solo” una conversión de moneda. En la práctica, obligó a revisar todos los sistemas donde había lógica económica: facturación, contabilidad, precios, informes… y ahí volvieron a aparecer los mismos problemas. Cálculos duplicados, reglas de negocio dispersas, desarrollos hechos “para salir del paso” que se habían quedado como solución definitiva. Muchas empresas descubrieron que no sabían realmente dónde estaban todas las piezas que había que tocar. Otra vez, el problema no era el cambio en sí, sino la falta de control sobre lo que tenían.

Si saltamos al presente, el contexto ha cambiado, pero el patrón es exactamente el mismo. Hoy hablamos de inteligencia artificial, automatización o integración de sistemas, pero cuando analizas lo que ocurre en el día a día de muchas organizaciones, ves estructuras tecnológicas construidas de forma incremental, casi siempre con buena intención, pero sin una visión global. Un ERP por un lado, un CRM por otro, herramientas específicas para cada departamento, integraciones hechas en distintos momentos y por distintos proveedores. Todo funciona, más o menos, hasta que necesitas que todo funcione como un conjunto. Es en ese momento cuando aparece el problema real: nadie tiene el control completo del sistema, ni del flujo de datos, ni de las dependencias.

En este escenario, la dependencia suele materializarse de varias formas. La más evidente es la dependencia de personas: alguien que conoce cómo funciona un proceso crítico, cómo se despliega una aplicación o cómo se resuelve una incidencia compleja. Mientras esa persona está, el sistema funciona. Cuando no está, aparecen las dudas, los retrasos y, en muchos casos, los errores. Otra forma habitual es la dependencia de proveedores: empresas que han desarrollado partes del sistema y que son las únicas capaces de modificarlas con seguridad. Y una tercera, más sutil pero igual de peligrosa, es la dependencia de una arquitectura improvisada, donde cada pieza tiene sentido por separado, pero el conjunto carece de coherencia.

El problema de fondo es que esta dependencia no suele ser visible. No aparece en un informe financiero ni en un cuadro de mando. La empresa cree que su tecnología funciona porque el día a día sale adelante. Pero en realidad está operando sobre una base frágil, donde cualquier cambio —una baja en el equipo, una nueva necesidad de negocio, una integración adicional— introduce un nivel de riesgo desproporcionado. Y esto es especialmente crítico ahora, porque muchas empresas están intentando dar el salto hacia la automatización o la inteligencia artificial sobre esa misma base. La IA no corrige la falta de estructura; al contrario, la amplifica. Si los procesos no están claros, si los datos no son coherentes y si las integraciones son frágiles, cualquier intento de automatización se convierte en una fuente adicional de problemas.

La solución no pasa por añadir más tecnología. De hecho, en muchos casos pasa por lo contrario: parar, analizar y poner orden. Lo primero es identificar dónde están las dependencias reales, no las teóricas. Qué procesos dependen de personas concretas, qué sistemas no están documentados, qué integraciones no tienen un responsable claro. A partir de ahí, el trabajo es más estructural que tecnológico: documentar, definir responsabilidades, unificar criterios de datos, revisar la arquitectura y, cuando es necesario, simplificar. No se trata de rehacerlo todo, sino de recuperar el control. De que la empresa entienda su tecnología, no solo la utilice.

Hay un cambio de mentalidad importante en este punto. Durante muchos años, la tecnología se ha visto como un conjunto de herramientas que hay que implantar y mantener. Hoy debería entenderse como parte del propio negocio. Igual que una empresa controla sus procesos financieros o su cadena de suministro, debería tener control sobre su arquitectura tecnológica. Saber qué sistemas tiene, cómo se relacionan, quién los gestiona y qué impacto tiene cada cambio. Cuando esto no ocurre, la empresa no está utilizando la tecnología como palanca, sino como una fuente de riesgo.

Si miro atrás, a lo que vivimos con el efecto 2000 o con el cambio al euro, hay una lección que sigue siendo válida hoy: las crisis tecnológicas no suelen venir por la tecnología en sí, sino por la falta de control sobre ella. En aquel momento hubo una fecha límite que obligó a reaccionar. Hoy no la hay, y eso hace que muchas empresas sigan posponiendo decisiones que, en realidad, ya son necesarias. Pero el punto de inflexión acaba llegando siempre. No con un cambio de calendario, sino con algo más cotidiano: un sistema que deja de escalar, una integración que falla, un proyecto que no se puede evolucionar o una persona clave que ya no está.

La diferencia entre las empresas que gestionan bien esa situación y las que no suele ser muy clara. No tiene que ver con el tamaño ni con el presupuesto, sino con el nivel de control que tienen sobre su tecnología. Cuando ese control existe, los problemas se resuelven. Cuando no existe, se acumulan. Y en ese momento, lo que parecía un problema técnico se convierte en un problema de negocio.

Por eso, antes de plantearse nuevas herramientas, nuevas plataformas o nuevas iniciativas de IA, merece la pena hacerse una pregunta más básica: ¿entendemos realmente cómo funciona nuestra tecnología hoy? Porque si la respuesta no es un sí claro, probablemente el problema no sea tecnológico. Es de dependencia. Y ese, antes o después, siempre acaba saliendo a la superficie.

#TransformacionDigital #TecnologiaEmpresarial #SoftwareAMedida #ArquitecturaIT #CIO #CTO #ITStrategy #GestionDeRiesgos #ContinuidadDeNegocio #DependenciaTecnologica #DigitalizacionEmpresarial #SistemasDeInformacion #Automatizacion #IntegracionDeSistemas #TecnologiaYNegocio