# ¿Tu sistema interno depende de una sola persona? > Si el sistema interno depende de una persona, el riesgo no es que se vaya: es lo que solo está en su cabeza. Cuatro capas que sacar de ahí antes de su salida. - Autor: Marlon Trettin - Publicado: 2026-10-19 · Actualizado: 2026-10-19 - Idioma: es - Canonical: https://yowpi.com/es/blog/tu-sistema-interno-depende-de-una-sola-persona --- Si tu sistema interno depende de una sola persona, el riesgo no es que se vaya. Es lo que solo existe en su cabeza: las contraseñas, el código que nadie más ha abierto, la forma de publicar una corrección y el motivo de cada regla. Decidir que todo eso viva en la empresa es arquitectura, y esa decisión va antes de la carta de renuncia. ## TL;DR - En un estudio con 133 proyectos populares de código abierto, [el 65% dependía de dos personas o menos](https://arxiv.org/abs/1604.06766) para no detenerse. Concentrar el conocimiento en pocas personas es habitual en software, incluso cuando el código es público. - En un análisis de más de 36.000 proyectos, [el 89% perdió su equipo central al menos una vez](https://arxiv.org/abs/2412.00313), y entre los proyectos abandonados solo el 27% logró atraer a un nuevo desarrollador central. - La dependencia tiene cuatro capas: acceso, código, entorno y decisiones. Cada una puede sacarse de la persona y ponerse a nombre de la empresa. - Contratar a un empleado, a un freelancer o a un studio no lo resuelve por sí solo. Lo que lo resuelve es definir, por escrito, qué tiene que quedarse en la empresa cuando cualquiera de ellos se vaya. ## ¿Por qué la salida de una persona detiene un sistema entero? Porque en la mayoría de las pymes el sistema interno nació de la mano de alguien que lo hacía todo. Escribió el código, contrató el servidor, registró el dominio, montó las integraciones y decidió las reglas de negocio en conversaciones de pasillo con el dueño. Funcionó. Por eso nadie lo tocó. El problema aparece el día en que esa persona renuncia, enferma o simplemente deja de responder rápido. En ese momento la empresa descubre que el sistema es suyo en el contrato y de otra persona en la práctica. El tamaño de la empresa hace este escenario más probable, no menos. Según Eurostat, [en 2023 las funciones de TIC las realizaban proveedores externos en el 70,19% de las pequeñas empresas de la UE](https://ec.europa.eu/eurostat/statistics-explained/index.php?title=ICT_specialists_-_statistics_on_hard-to-fill_vacancies_in_enterprises), y solo el 14,04% de las pequeñas empresas empleaba a un especialista en TIC en 2024. En la mayoría de las empresas pequeñas, nadie en plantilla es especialista en TIC, y el trabajo técnico queda en manos de un proveedor externo que puede irse con poco aviso. ## ¿Qué muestran los datos sobre la concentración de conocimiento? Que es el estado normal de un proyecto de software, incluso donde todo está a la vista. La ingeniería de software lo mide con el truck factor: el número mínimo de personas que tienen que irse para que el proyecto se detenga. Investigadores de la Universidad Federal de Minas Gerais lo calcularon para [133 proyectos populares alojados en GitHub](https://arxiv.org/abs/1604.06766). En el 65% de ellos era de una o dos personas. Un estudio publicado en diciembre de 2024 amplió la muestra a [más de 36.000 proyectos de código abierto](https://arxiv.org/abs/2412.00313). Los autores encontraron que el 89% perdió su equipo central al menos una vez, que el 70% de esas pérdidas ocurrió en los tres primeros años del proyecto y que la mayoría de los proyectos depende de un único desarrollador central. De los proyectos abandonados, solo el 27% logró atraer a alguien para ocupar ese lugar. Estas cifras vienen del código abierto, y eso importa. Son proyectos donde el código está publicado, el historial es visible y cualquiera puede estudiar lo que se hizo. No existe una medición pública equivalente para los sistemas internos de las pymes. Lo que sí se puede afirmar es el sentido de la diferencia: en un sistema interno el código suele estar cerrado, a veces el historial ni existe y el único lector posible es quien lo escribió. ## ¿La dependencia es de la persona o de lo que carga? De lo que carga. Y lo que carga se divide en cuatro capas, cada una con una pregunta objetiva. ### Acceso ¿A nombre de quién están el dominio, la cuenta del servidor, el repositorio de código, la base de datos y las claves de las integraciones? Si la respuesta es el nombre de alguien o su tarjeta de crédito personal, la empresa no controla su propio sistema. Es la capa más barata de corregir y la más cara de descubrir tarde. ### Código ¿El código está en un repositorio de la empresa, con historial de cambios, o en una computadora personal y una carpeta compartida? El código sin historial muestra lo que el sistema hace hoy y esconde todo lo que se intentó y se deshizo. ### Entorno ¿Otra persona puede poner una corrección en producción sin llamar a quien la escribió? Si la publicación depende de un paso que solo una persona sabe hacer, el sistema puede estar perfectamente documentado y aun así quedarse parado. ### Decisiones ¿Por qué el descuento se calcula así? ¿Por qué ese campo es obligatorio? El estudio ["Bus Factor In Practice"](https://arxiv.org/abs/2202.01523), presentado en ICSE 2022 con respuestas de 269 ingenieros, mostró que el conocimiento de un proyecto circula también por las revisiones de código y las reuniones, no solo por el código. En una pyme, ese canal suele ser la conversación de pasillo, y no queda registrada en ninguna parte. La [guía para documentar y versionar automatizaciones](/es/blog/como-documentar-y-versionar-automatizaciones) propone un formato ligero para ese registro. Las cuatro capas tienen un orden. El acceso va primero porque sin él las otras tres no sirven de nada. Las decisiones van al final porque son las que más tiempo llevan, y son justo la capa que permite a un sucesor entender el sistema en lugar de solo poder abrirlo. ## Un ejemplo, y es una hipótesis Imagina una distribuidora que factura unos pocos millones al año. Hace tres años, un desarrollador independiente construyó su sistema de pedidos. Responde bien, conoce la operación y el sistema funciona sin incidentes relevantes. Un día avisa de que ha aceptado una oferta y se va en cuatro semanas. En la primera reunión de traspaso, la empresa descubre que el dominio está a su nombre, que el servidor se paga con su tarjeta personal, que el código está en un repositorio de su cuenta y que la regla de comisiones de los vendedores se acordó por mensaje con un director que ya no está. Nada de esto es mala fe. Es el resultado natural de tres años en los que nadie preguntó a nombre de quién estaban las cosas. Las cuatro semanas se van en traspasar cuentas, y no queda tiempo para traspasar el entendimiento. La situación es inventada. Lo que pasa después, no. [Colo Saúde](/es/cases/colo-saude) llegó a Yowpi con una plataforma construida por un proveedor anterior, sin responsable técnico y sin nadie del equipo que la conociera por dentro. El primer proyecto fue un rescate: auditoría de seguridad y ajuste de rendimiento, antes de cualquier evolución. En otro proyecto, un sistema de control de transporte público, el software lo había escrito el propio fundador del cliente, y el trabajo fue corregir errores e integrar un nuevo frontend al sistema existente, sin reescribirlo desde cero. ## ¿Contratar o externalizar cambia este riesgo? Cambia la forma, no la existencia. Un empleado puede irse con unas semanas de preaviso. Un freelancer, con menos. Un studio puede terminar el contrato o rotar al equipo. En todos los casos, la pregunta que protege a la empresa es la misma: ¿qué se queda con ella al día siguiente? La diferencia está en lo que puedes exigir. A un empleado, la empresa se lo exige por política interna. A un proveedor, por contrato: cuentas a nombre del cliente desde el primer día, código en el repositorio del cliente, proceso de publicación por escrito y decisiones de negocio registradas junto al código. Cualquiera de las tres opciones necesita esa cláusula para no convertirse en dependencia. ## Cuatro preguntas para hacer esta semana No hace falta una auditoría para empezar. Hace falta una conversación de una hora con quien mantiene el sistema hoy, con estas cuatro preguntas: 1. ¿Qué cuentas usa el sistema, y a nombre de quién está cada una? 2. ¿Dónde está el código, y alguien además de quien mantiene el sistema tiene acceso a él? 3. Si quien mantiene el sistema estuviera fuera dos semanas, ¿quién podría publicar una corrección, y cómo? 4. ¿Cuáles son las tres reglas del sistema que más dudas generan, y dónde está escrito su motivo? Las respuestas muestran en cuál de las cuatro capas está expuesta tu empresa. Si la primera pregunta ya revela una cuenta a nombre personal de alguien, tienes motivo suficiente para la segunda conversación. ## Preguntas frecuentes **No tengo a nadie técnico para revisar las respuestas. ¿Por dónde empiezo?** Empieza por la capa de acceso, que no exige conocimientos técnicos. Pide la lista de cuentas y comprueba si el titular es la empresa. Eso lo verificas tú mismo mirando facturas y registros. Las otras capas necesitan a alguien que lea código, y ahí vale la pena una evaluación externa. **¿Externalizar a un studio no cambia una dependencia por otra?** Sí, si el contrato no dice qué se queda contigo. La dependencia de un proveedor es manejable cuando las cuentas están a nombre de tu empresa, el código está en tu repositorio y las decisiones están registradas. En ese escenario, cambiar de proveedor da trabajo, pero es posible. Sin eso, es empezar de nuevo. **El sistema funciona y la persona no piensa irse. ¿Vale la pena tocarlo ahora?** Sí, justamente porque ahora la conversación es tranquila. Con la persona disponible, traspasar cuentas y registrar decisiones es un trabajo corto y en colaboración. Cuando se va, el mismo trabajo se convierte en ingeniería inversa, más lenta, que no siempre recupera el motivo de las reglas. ## El siguiente paso Si las respuestas mostraron capas que siguen en manos de una persona, el [Diagnóstico de Arquitectura Operacional](/es/contacto) es una conversación de 30 minutos para mapear esas capas y el orden en que traspasarlas.