Los sistemas propios: ¿riesgo o ventaja?

Sobre las empresas que decidieron construir su propio software y terminaron construyendo su propia desorganización.

Hay una conversación que se repite tanto que ya podría repetirla de memoria. Un director me enseña el sistema que su equipo interno desarrolló. Hecho a la medida. Sin licencias mensuales, sin costos de implementación. Con exactamente las pantallas que la operación pidió. “Nos costó una fracción de lo que cotizaba el proveedor”, me dice. Entonces pregunto: ¿quién lo hizo? Y la respuesta, casi siempre, es un nombre, a veces dos.

He visto empresas de muchos millones de pesos de facturación cuya operación completa, desde cobranza, inventarios a producción, corre sobre código escrito por una persona que sigue trabajando ahí, que no documentó nada, que es la única con las contraseñas del servidor y que en la última revisión de sueldo pidió un aumento que a todos les pareció excesivo y que todos aprobaron, que se ha adueñado de los procesos y que se siente indispensable. Eso no es una ventaja competitiva. Es una hipoteca que la empresa pagará tarde o temprano.

Los argumentos a favor de desarrollar plataformas propias son reales, porque el desarrollo interno no es una mala idea en sí misma y quien lo defiende tiene razones sólidas. El costo directo suele ser menor, sobre todo comparado con licencias por usuario que se multiplican cada vez que la empresa crece. La personalización puede ser total, nadie va a entender su proceso de producción mejor que quien lo vive todos los días. El control de la información es propio y no depende de la política de datos de un tercero. Y hay una satisfacción organizacional difícil de medir en el hecho de que la solución salió de casa.

Cuando una empresa tiene procesos genuinamente únicos, una lógica de negocio que ningún producto del mercado contempla y cuenta con un equipo de tecnología maduro, con gobierno, documentación y prácticas serias, el desarrollo propio puede ser la decisión correcta. Existen esos casos. Los he visto y son exitosos. Lo que también he visto, pero con mucha más frecuencia, es lo otro.

Lo que nadie cotizó

El problema del software propio rara vez aparece en el año uno, aparece en el año cuatro o cinco, cuando el desarrollador original ya se fue, la persona que lo reemplazó no entiende la arquitectura y cada cambio pequeño tarda tres semanas porque nadie sabe qué más se va a romper.

Aparece cuando la empresa crece de doscientos a ochocientos usuarios y el sistema, que fue diseñado para una operación pequeña, empieza a tronar los lunes a las nueve de la mañana. Aparece cuando alguien pregunta quién tiene acceso a qué, y descubrimos que todos los usuarios comparten tres perfiles, que las contraseñas nunca expiran, que no hay bitácora de quién modificó qué registro y que el respaldo se hace manualmente en un disco externo que vive en el cajón de un escritorio.

Y aparece, sobre todo, cuando llega el auditor, el cliente corporativo o la certificación que exige controles de acceso, trazabilidad y continuidad operativa, y la empresa descubre que su sistema estrella no puede demostrar nada de eso.

El desarrollo de software depende, en buena medida, de las decisiones y del razonamiento de quienes lo construyen. Cada desarrollador puede interpretar un problema de manera distinta y llegar a una solución diferente; por ello, la lógica detrás de una aplicación no siempre resulta evidente para alguien que no participó en su construcción. Podemos compararlo con un edificio, si conocemos únicamente la estructura terminada, pero no contamos con los planos, las especificaciones ni la documentación de cómo fue construido, entenderlo, modificarlo o repararlo se vuelve considerablemente más difícil.

En el software ocurre algo similar. Cuando las decisiones de arquitectura, las reglas de negocio, las integraciones y el conocimiento técnico permanecen únicamente en la mente de una persona o de un pequeño grupo, la organización genera una dependencia crítica. El riesgo aumenta cuando esas personas dejan la empresa, cambian de función o concentran un nivel de conocimiento y control que nadie más posee. Incluso pueden surgir riesgos relacionados con la propiedad intelectual, la reutilización no autorizada de componentes o la réplica de soluciones desarrolladas para la organización. Estos no son costos que aparezcan en la comparación inicial. Pero son costos.

El peor dato, sin embargo, viene de la encuesta Voice of the CISO de Proofpoint, en 2025, 80% de los responsables de seguridad de la información en México percibía riesgo de sufrir un ciberataque material en los siguientes doce meses, 57% admitía que su organización no estaba preparada para responder, y 84% dijo que consideraría pagar un rescate para recuperar sus sistemas, la tasa más alta del mundo. A eso agréguele que el reporte anual de IBM sobre el costo de las brechas de datos ubicó el promedio global de 2025 en 4.44 millones de dólares por incidente.

Ahora preguntate con honestidad, el sistema que su equipo desarrolló internamente, ¿fue diseñado pensando en ese escenario? ¿Tiene control de accesos por rol, cifrado, monitoreo, respaldos probados, segregación de ambientes, actualizaciones de dependencias? ¿O tiene, como la mayoría, un login, una base de datos y mucha, muchísima buena fe?

La dependencia que se disfraza de lealtad

Hay una variante del problema que casi nunca se nombra en voz alta, y es importante decirlo, cuando una sola persona o un equipo muy pequeño controla el código, los servidores, los accesos y el conocimiento del sistema que sostiene la operación, esa persona o ese equipo tiene sobre la empresa un poder que ningún organigrama refleja.

No estoy insinuando mala fe. La mayoría de los equipos internos que conozco son gente honesta y comprometida, que trabaja de más y que quiere a la empresa. El problema no es la intención, es la estructura. Una organización jamás debería estar en una posición donde la renuncia de una persona o su enojo, o su enfermedad, o su accidente represente un riesgo existencial. Y muchas empresas mexicanas están exactamente ahí sin saberlo.

He visto negociaciones donde el desarrollador tenía todo el poder porque todos en la mesa sabían que sin él la operación se detenía. He visto salidas amargas que dejaron sistemas sin documentación y sin quien los entendiera. Y he visto compañías pagar tres veces el valor de un sistema comercial solo para poder salir del suyo.

Cómo hacer las paces con el software propio

No estoy proponiendo que todo mundo tire su desarrollo interno a la basura. Estoy proponiendo que lo trate como el activo crítico que es y no como el proyecto simpático de tecnología.

Eso significa cosas concretas y verificables. Que el código esté en un repositorio de la empresa, no en la computadora de nadie. Que exista documentación funcional y técnica que permita a un tercero entender el sistema en semanas, no en años. Que los accesos estén por rol, con bitácora y con revocación al momento de una salida. Que los respaldos se restauren en un simulacro, porque un respaldo que nunca se ha probado no es un respaldo, es una esperanza. Que alguien externo audite la seguridad al menos una vez al año. Y que quede claro, por escrito, quién es dueño de la propiedad intelectual.

En este contexto, vale la pena considerar que contratar plataformas de software bajo un esquema de licenciamiento puede reducir de manera importante los riesgos asociados con la dependencia de personas específicas. En lugar de que el conocimiento, el mantenimiento y la evolución de la solución recaigan exclusivamente en un desarrollador o en un equipo interno, la empresa adquiere el respaldo de un proveedor responsable de mantener la plataforma, corregir errores, actualizarla y asegurar su continuidad tecnológica. Además, una licencia normalmente establece con mayor claridad las condiciones de uso, soporte, propiedad intelectual, seguridad, niveles de servicio y responsabilidades de cada parte. Esto permite que la organización se concentre en aprovechar la tecnología para su operación, en lugar de asumir por completo el costo y el riesgo de construir, documentar, mantener y evolucionar una plataforma propia a lo largo del tiempo.

La conversación entre construir y comprar dejó de ser una discusión de costos hace rato. Hoy es una discusión de riesgo, de continuidad y de a quién le estás confiando la operación completa de la empresa. Un sistema propio bien gobernado puede ser una ventaja formidable. Un sistema propio sin gobierno es una bomba con temporizador y casi siempre, el dueño o el directivo es el único que no sabe la hora.