"¿Y por qué no lo montamos nosotros, en nuestros propios servidores?"
Esa pregunta la hace siempre la misma persona. No importa el tamaño de la empresa, ni el sector, ni si es la primera vez que se plantea un DAM o la tercera. Siempre hay alguien, normalmente del departamento de sistemas, que suelta esa frase con la seguridad de quien cree que cualquier problema se resuelve con hardware propio.
La primera vez que la escuchamos, pensamos que era una buena pregunta. Sonaba responsable, controlada, sensata. No es la primera vez que nos equivocamos.
"Porque no es solo comprar un servidor" contestamos, después de haber vivido ya el ciclo completo en una empresa anterior. "Es parchearlo, monitorizarlo, hacer copias de seguridad que de verdad funcionen (no solo que existan), y tener a alguien disponible el día que algo falla, que no siempre es en horario de oficina."
"Pero eso ya lo hacemos para otras cosas" respondieron, con la paciencia de quien cree que está hablando con alguien que no entiende de infraestructura.
Y ahí estaba el problema. Lo que sonaba razonable en esa reunión, seis meses después ya no sonaba tan bien. Porque el servidor que "ya teníamos" no estaba dimensionado para el volumen de archivos de marketing, que crece a un ritmo distinto al de los servidores de correo o de los ERP. Porque la VPN que funcionaba para que el equipo de desarrollo accediera desde casa no estaba diseñada para que un diseñador en una agencia externa descargara vídeos de dos gigas. Porque la copia de seguridad que "se hacía automáticamente" se había quedado sin espacio hacía tres semanas y nadie se había dado cuenta.
La reunión terminó con un "lo estudiamos" que en el lenguaje de las empresas significa "no tenemos tiempo de hacerlo ahora, pero tampoco queremos decirlo". Y el DAM se quedó en el limbo durante otro año, mientras el caos de archivos seguía creciendo y la gente seguía mandándose logos por correo.
No es que la opción de servidor propio sea mala. Es que quien la defiende suele subestimar tres cosas:
La primera: el mantenimiento no es un evento puntual, es un proceso continuo que alguien tiene que asumir, y ese alguien normalmente ya tiene otras quince cosas que hacer.
La segunda: el acceso remoto no es "una VPN y ya". Es una capa de fricción que se nota cada vez que alguien nuevo necesita acceso, y esa fricción es exactamente lo que hace que la gente termine mandando archivos por correo en vez de usar el sistema que se supone debería evitarlo.
La tercera: la seguridad no depende de dónde están físicamente los archivos, sino de quién y con qué recursos los protege. Y un proveedor de nube que vive de eso va a tener un equipo de seguridad dedicado, mientras que nosotros vamos a tener a una persona que además tiene que encargarse del firewall, del correo y de la migración de la base de datos del CRM.
Al final, la pregunta no es cuál opción es más barata en el primer año. Es cuál de las dos sigue funcionando bien sin fricción cuando triplicamos el volumen de archivos y de gente que los usa.
"Nos lo pensamos" dijo alguien de sistemas al terminar la reunión.
Y nosotros, que ya habíamos escuchado esa frase antes, sabíamos que tarde o temprano el DAM sería la única alternativa viable.