Cómo gestionar una herramienta interna desarrollada por el equipo financiero
Un director financiero creó una aplicación en su tiempo libre y quiere que todo el equipo la use; los administradores se preguntan cuál es la mejor forma de proceder.
Un usuario de r/sysadmin preguntó qué hacer con una "gran aplicación" que el responsable de finanzas desarrolló durante su hora de almuerzo y que ahora quiere poner a disposición de todo su equipo. La inquietud surge porque, aunque la herramienta parece útil, no está clara su arquitectura, su licencia ni su nivel de soporte.
En estos casos, el primer paso es evaluar la solución desde la perspectiva operativa: ¿se trata de un script sencillo, una aplicación web ligera o un servicio más complejo? Si es un script o una pequeña utilidad, empaquetarlo como un contenedor Docker permite aislar dependencias y facilita su despliegue en entornos controlados. Para una aplicación web, se debe revisar si el código está versionado en un repositorio Git y si existen pruebas automatizadas; de no ser así, conviene crear al menos una rama de desarrollo y establecer un pipeline de CI/CD básico.
Otro punto crítico es la licencia. Si el autor no ha especificado una licencia, la herramienta queda bajo derechos reservados y su distribución interna puede generar problemas legales. Lo recomendable es solicitar al creador que defina una licencia open source permissiva (por ejemplo MIT o Apache 2.0) o, en su defecto, documentar explícitamente los términos de uso interno.
En cuanto a la seguridad, cualquier aplicación que exponga datos financieros debe pasar por un escaneo de vulnerabilidades y, preferiblemente, integrarse en la solución de gestión de identidades de la empresa (SSO, MFA). Si la herramienta requiere acceso a bases de datos sensibles, se deben aplicar principios de mínimo privilegio y cifrado en tránsito.
Finalmente, la decisión de adoptar la herramienta depende del coste de mantenimiento frente al valor que aporta. Si el equipo de TI no está dispuesto a asumir el soporte a largo plazo, la mejor opción puede ser archivar el código y buscar una solución comercial o open source con soporte garantizado.
En resumen, la gestión de una herramienta interna no oficial implica validar su arquitectura, definir una licencia clara, asegurar su despliegue y evaluar el esfuerzo de mantenimiento antes de ponerla en producción.
