Control de versiones y cambios en sistemas internos: evita sorpresas y pérdidas

Por qué pierdes el control: la realidad en empresas medianas

Si tu empresa ya tuvo un sistema que un día dejó de funcionar bien (o peor: nadie supo qué le movieron), sabes de qué hablamos. Cambios mal documentados, archivos sobreescritos y actualizaciones sin aviso son receta para el caos. No es sólo cosa de desarrollo de software: aplica igual en bases de datos, configuraciones de red, incluso en sistemas de control de acceso o CCTV.

En empresas medianas, pasa mucho porque ningún proveedor te dice cómo llevar el control correcto. O te lo venden como "extra". El resultado: nadie sabe a qué versión regresar si algo falla, ni quién movió qué. Y cuando urge, nadie responde rápido.

Qué sí debes exigir: control de versiones real

Control de versiones no es sólo "respaldar" o tener copias. Es poder saber exactamente:

• Qué cambió, cuándo y por quién.
• Qué versión estaba antes de cada cambio.
• Poder regresar (rollback) si algo sale mal.

Para desarrollo de software a la medida, lo mínimo hoy es exigir uso de sistemas como Git (GitHub, GitLab, Bitbucket). Si tu proveedor sólo maneja archivos sueltos en Dropbox o manda cambios por correo, cuidado: ahí empiezan los problemas.

En infraestructura, aplica igual: toda configuración de red, scripts de control, hasta archivos de cámaras deben llevar bitácora de cambios. Hay sistemas gratuitos (como RANCID o Oxidized para redes) que pueden automatizarlo. En software de control de acceso, revisa que tu proveedor documente usuarios, configuraciones y cambios de firmware.

Cómo documentar cambios sin volverte loco

No necesitas manuales de 200 páginas. Lo que sí sirve:

• Bitácora de cambios (changelog) con fecha, responsable y motivo.
• Respaldo de cada versión estable, al menos antes de cambios mayores.
• Acceso a los registros para tu área de TI o responsable interno.

En sistemas SaaS, pide registro de cambios automático (logs). Las plataformas serias lo incluyen: por ejemplo, en nuvoria puedes ver quién cambió un expediente o editó horarios. En sistemas a la medida, que tu proveedor te entregue una bitácora simple después de cada cambio relevante. El costo de pedirlo ronda entre 10% y 20% extra del proyecto, estimado, pero te ahorra mucho más cuando hay un problema.

¿Vale la pena para todo? Lo que sí y lo que puedes saltarte

No todo requiere el mismo nivel de control. Unas reglas prácticas:

• Sistemas críticos (nómina, ventas, control de accesos, bases de datos): SIEMPRE con control de versiones y bitácora.
• Configuraciones de red y servidores: igual, mínimo respaldo y registro de cambios.
• Cambios menores (logos, textos, archivos temporales): basta con un respaldo básico.

Si un proveedor te cobra como proyecto nuevo sólo por documentar cambios menores, sospecha. Pero si lo ves como gasto innecesario, recuerda: un error en la nómina, o una configuración mal aplicada en la red puede costar más que el control de versiones de todo el año.

Qué pasa si no lo haces (y cómo corregir el rumbo)

Sin control de versiones, cada cambio es una ruleta. Pierdes tiempo investigando qué falló, y nadie quiere asumir la responsabilidad. Si ya estás en ese punto:

• Haz un corte: pide a tu proveedor (o a quien maneje tus sistemas) que documente el estado actual.
• Implementa bitácoras y respaldos a partir de hoy; no intentes reconstruir todo el pasado, pero sí lo más reciente.
• Define un responsable interno para validar cambios y registrar versiones.

Esto no se arregla con cursos ni con plataformas mágicas. Es disciplina y pedir lo justo a tu proveedor. La diferencia entre perder un día (o un mes) y resolver en minutos.