Hay un momento del que casi nunca se habla en las propuestas comerciales y que, sin embargo, todos los clientes viven igual. El proveedor entrega el sistema, se cierran las últimas pruebas, alguien hace una foto del equipo y la jornada termina con esa sensación agradable de proyecto acabado. A la mañana siguiente empieza lo de verdad: una recepcionista escribe el apellido compuesto de un paciente, un encargado de almacén registra una entrada a las siete desde el móvil y un comercial intenta emitir una factura mientras habla por teléfono. Ese es el instante exacto en el que el software deja de ser una demostración y pasa a ser una herramienta de negocio, y es también el instante en el que empieza la parte que casi nadie presupuesta.
Ese aterrizaje tiene una forma bastante predecible, así que conviene planificarlo con números en la mano. Lo habitual es que el primer mes tras la puesta en marcha traiga entre 25 y 40 mensajes de soporte, porque todo el mundo descubre a la vez sus dudas, sus casos raros y sus costumbres de siempre. En el segundo mes esa cifra baja a unos 16, en el tercero a unos 9 y, a partir del cuarto, se estabiliza entre 4 y 8 al mes siempre que la formación se haya hecho bien. Dicho de otro modo, un primer mes ruidoso no significa que el proyecto haya salido mal, significa que el sistema por fin está en manos de personas reales.
Aquí aparece la palabra garantía, que suele entenderse mal por ambas partes. La mayoría de los contratos de desarrollo incluyen entre 30 y 90 días de corrección gratuita de defectos, es decir, de cosas que se construyeron mal respecto a lo acordado. Lo que la garantía no cubre conviene decirlo con la misma claridad: no cubre funciones nuevas que se le ocurren a alguien al ver el sistema funcionando, no cubre los errores de tecleo del personal y no cubre los cambios que le imponen desde fuera, como cuando su pasarela de pago retira la conexión antigua y hay que rehacerla.
De ahí nace la pregunta que responde este artículo. Cuando termina la garantía, alguien tiene que hacerse responsable de ese sistema todos los meses durante años, y la cuestión ya no es si hará falta ese cuidado, sino quién lo asume y cuánto ha decidido usted gastar en él. En Linkysoft entregamos sistemas y después los mantenemos vivos, así que lo que sigue es lo que vemos una y otra vez durante ese primer año, con las horas y el dinero escritos sin adornos.
Los cuatro tipos de trabajo que nunca se detienen
El mantenimiento suena a una sola cosa, pero en la práctica son cuatro trabajos distintos que conviven cada mes: arreglar lo que se ha roto, seguir el ritmo de un mundo exterior que cambia por su cuenta y sin pedir permiso, mejorar lo que la gente pide cuando ya lleva un tiempo usando el sistema de verdad y, el menos visible de los cuatro, prevenir los problemas antes de que lleguen.
Un ejemplo pequeño de cada uno explica más que cualquier definición:
- Arreglar lo roto: el informe de cierre imprime un total equivocado porque nadie había probado un mes con devoluciones.
- Seguir el ritmo del mundo exterior: la pasarela de pago avisa de que retira su conexión antigua dentro de seis meses y hay que rehacerla antes.
- Mejorar lo que la gente pide: recepción reclama un segundo campo de teléfono, porque la mitad de los clientes dan un número de casa y otro de trabajo.
- Prevenir: alguien nota que la base de datos ha crecido en silencio hasta que las búsquedas tardan cuatro segundos, y lo corrige antes de que llegue la primera queja.
La sorpresa, para casi todo el mundo, está en el reparto. Un mes de mantenimiento normal dedica alrededor del 40 % a mantener el sistema en marcha (actualizaciones, vigilancia, copias de seguridad y parches), un 30 % a corregir fallos y responder preguntas de los usuarios, un 20 % a mejoras pequeñas y un 10 % a informes y planificación. Es decir, corregir errores es solo un tercio del trabajo, y la parte grande es ese cuidado continuo que nadie nota precisamente cuando se hace bien.
Esto importa mucho en la conversación del presupuesto, porque un cliente convencido de que mantenimiento equivale a errores concluirá, con toda lógica, que un sistema bien construido casi no necesita nada. Luego llega el primer año con su actualización de motor, su cambio de pasarela y sus dos versiones nuevas de sistema operativo móvil, y la factura le parece injusta cuando en realidad era perfectamente previsible.
El mundo cambia aunque usted no toque una sola línea
Esta es la idea central del artículo y merece decirse sin rodeos: el software se estropea aunque se quede quieto, porque todo lo que hay a su alrededor se mueve. Los navegadores se actualizan aproximadamente cada cuatro semanas y los sistemas operativos de los móviles publican una versión mayor cada año, de manera que su sistema, idéntico al día que se entregó, se va desalineando poco a poco del terreno donde funciona.
La regla que pilla desprevenido a todo el mundo es la de las tiendas de aplicaciones, que suben una vez al año los requisitos mínimos con los que se puede publicar una app. Una aplicación que lleva entre 12 y 18 meses sin tocarse suele necesitar entre 20 y 60 horas de trabajo antes de poder volver a publicarse, aunque no haya cambiado ni un botón ni un texto. Por eso, cuando planificamos el desarrollo de aplicaciones móviles, contamos desde el principio con al menos una puesta al día anual que no aporta nada visible al usuario y que aun así es obligatoria.
Algo parecido ocurre con el motor sobre el que corre su sistema, que es el programa base encargado de ejecutar el código. Ese motor tiene una vida de soporte de unos dos o tres años, y pasado ese plazo deja de recibir correcciones de seguridad. Lo sensato es presupuestar una actualización planificada cada dos o tres años, entre 15 y 60 horas según el tamaño del sistema, porque hacerla con calendario cuesta una fracción de lo que cuesta hacerla con prisa un lunes por la mañana, después de un aviso urgente.
Los servicios de terceros son el tercer frente. Pasarelas de pago, empresas de transporte y proveedores de mensajería retiran sus conexiones antiguas cada cierto tiempo y suelen avisar con entre 6 y 12 meses de antelación por correo electrónico, casi siempre a una dirección técnica que nadie abre. De ahí que una de las tareas más baratas y más rentables del mantenimiento sea, sencillamente, que haya alguien leyendo esos correos y avisando a tiempo.
Y queda el certificado de seguridad, ese candado que aparece junto a la dirección web. Los gratuitos duran 90 días y se renuevan solos, los de pago suelen durar un año, y comprobar que la renovación ha funcionado lleva minutos. Un certificado caducado deja el sitio entero fuera de servicio para todos los visitantes a la vez, sin aviso previo y con un mensaje rojo que asusta a cualquier cliente, así que es de los descuidos más baratos de evitar y más caros de sufrir.
Cuánto cuesta de verdad el mantenimiento, con las cuentas a la vista
La regla que usamos, y que puede exigir a cualquier proveedor, es que el cuidado anual de un sistema ronda entre el 15 % y el 25 % de lo que costó construirlo. Hagamos la cuenta con un caso concreto: un sistema que costó 30.000 USD desarrollar necesita normalmente entre 4.500 y 7.500 USD al año, lo que equivale a algo entre 375 y 625 USD al mes. No es una cifra que dependa del humor de quien la cobra, sino de la cantidad de piezas que hay que vigilar cada semana.
Lo que empuja un proyecto hacia la parte alta o la parte baja de esa horquilla se explica sin tecnicismos: cuántos servicios externos utiliza, porque cada conexión con un banco, una mensajería o un programa de contabilidad es una relación que puede romperse; si mueve dinero, ya que entonces cualquier fallo tiene consecuencias inmediatas; si tiene aplicación móvil, que añade el ciclo anual de las tiendas; y cuánta gente lo usa a diario, porque el volumen saca a la luz problemas que con diez usuarios no aparecen jamás.
Aparte del tiempo de las personas están los gastos de máquina, que conviene mirar por separado para que nada quede escondido en una cuota global:
- Alojamiento: entre 40 y 200 USD al mes para el sistema de una pequeña empresa.
- Dominio: entre 10 y 40 USD al año.
- Cuenta de desarrollador de Apple: 99 USD al año.
- Cuenta de desarrollador de Google: 25 USD, un pago único.
Sumando todo eso y repartiendo los importes anuales entre los doce meses, los costes de máquina rondan entre 50 y 215 USD al mes antes de pagar una sola hora de trabajo humano, y son justamente la parte que no se puede negociar a la baja.
Para terminar de aterrizar la cifra, conviene traducir los porcentajes a horas, que es lo que usted compra en realidad. Una cuota de 500 USD al mes compra, en la mayoría de los mercados, entre 4 y 10 horas de trabajo cualificado. Así que la pregunta correcta a cualquier proveedor no es cuánto cuesta el plan, sino cuántas horas incluye ese precio y qué ocurre con las horas que no se usan.
Quién lo mantiene vivo: cuatro opciones honestas
Hay cuatro maneras de hacerse cargo de este trabajo y ninguna gana siempre, así que vale la pena verlas con sus puntos flacos incluidos.
El equipo que lo construyó, con una cuota mensual. Es la opción más rápida, porque ya conocen cada decisión del sistema y no necesitan semanas para orientarse dentro del código. La debilidad honesta es que le ata a un único proveedor, de modo que la forma de comprar esta opción con tranquilidad es exigir en el contrato que pueda marcharse llevándose absolutamente todo: código, accesos, documentación y cuentas. Un buen proveedor firma esa cláusula sin pestañear, y en nuestro trabajo de desarrollo de aplicaciones web la damos por descontada desde la primera reunión.
Un profesional independiente de guardia. Suele costar unos 12.000 USD al año por disponibilidad real, sale más barato por hora y funciona bien en sistemas tranquilos que cambian poco. El riesgo es de concentración: una persona enferma, se va de vacaciones o cambia de trabajo, y con ella se marcha todo el conocimiento del sistema, así que en esta opción la documentación no es un lujo sino un seguro de vida.
Contratar a alguien en plantilla. En muchos mercados el coste real de un desarrollador de nivel medio queda entre 35.000 y 90.000 USD al año una vez contados salario, impuestos, equipo, formación y el tiempo de quien lo dirige, con una referencia intermedia cercana a los 60.000 USD. Solo tiene sentido cuando el sistema cambia cada semana y es central para la manera en que la empresa gana dinero, porque entonces la persona está ocupada de verdad.
No hacer nada y llamar a alguien cuando se rompa. Digámoslo con franqueza: es una opción legítima para una herramienta interna pequeña, sin datos delicados y con cinco usuarios que pueden sobrevivir dos días sin ella. Y digamos con la misma franqueza que es una mala elección para cualquier cosa que cobre dinero o guarde datos de clientes, porque el rescate siempre acaba costando más que el año de cuidado que se ahorró.
El paquete de traspaso que debe tener antes de pagar la última factura
Conviene imprimir esta lista y repasarla antes de firmar la última factura, porque todo lo que se pide después de pagar se consigue más despacio y con peor humor:
- El dominio y su configuración DNS, que es la libreta de direcciones que indica dónde vive su web, en una cuenta a nombre de su empresa.
- La cuenta de alojamiento o de nube, también a nombre de su empresa y no del proveedor.
- El código fuente en un repositorio que usted controle y cuya contraseña conozca, entendiendo por repositorio el almacén en línea donde vive el código junto con el registro de cada cambio que se le ha hecho desde el primer día.
- Los accesos a la base de datos guardados en un gestor de contraseñas de la empresa.
- Una nota escrita con todas las licencias que usa el sistema, cuánto cuestan y cuándo se renuevan.
Añado la que más veces vemos fallar en pequeñas empresas: todas las cuentas de terceros, es decir pago, correo, SMS y mapas, tienen que estar registradas con una dirección de correo de la empresa y nunca con la personal de un desarrollador. Esas cuentas guardan su dinero y los datos de sus clientes, así que si figuran a nombre de otra persona, usted no es del todo el dueño de su propio sistema.
Pida además dos documentos escritos en lenguaje llano: cómo se pone un cambio en producción y qué hacer cuando el sitio se cae a las nueve de la noche. Los dos deben estar redactados de forma que un profesional competente que jamás haya visto el sistema pueda seguirlos sin llamar a nadie a medianoche.
La aritmética convierte esto en algo no negociable. Preparar un paquete de entrega completo lleva entre 8 y 16 horas al final del proyecto, mientras que un equipo nuevo que llega sin él necesita entre 40 y 120 horas solo para entender el sistema antes de poder cambiar una línea con seguridad. Es la diferencia entre pagar dos días ahora o dos semanas más adelante.
Las copias de seguridad y la seguridad son suscripciones, no compras
Detrás de cualquier política de copias hay dos preguntas y ninguna es técnica: cuánto trabajo se puede permitir perder y cuánto tiempo se puede permitir estar cerrado. Si la respuesta es un día de trabajo y unas pocas horas de parada, la traducción práctica es una copia automática diaria más una copia guardada fuera del servidor principal, porque una copia que vive en la misma máquina que el sistema desaparece con ella el día del incendio.
La regla que de verdad importa es otra: una copia no es una copia hasta que alguien la ha restaurado. Por eso recomendamos una prueba de restauración real cada trimestre, con cronómetro y con alguien mirando. Restaurar una base de datos de menos de 5 GB suele llevar entre 10 y 40 minutos, y en los sistemas que recibimos de otros equipos aproximadamente una de cada cuatro tareas de copia resulta estar incompleta o fallando en silencio desde hace meses. El calendario de copias importa mucho menos que la prueba de que funcionan.
El código de terceros merece una explicación de tendero. Una aplicación web normal lleva dentro entre 300 y 1.200 piezas de código escritas por otras personas una vez se cuentan las indirectas, es decir, las piezas que a su vez utilizan otras piezas. A lo largo de un año conviene esperar entre 5 y 20 que necesiten una actualización de seguridad, de las cuales entre 1 y 3 deberían aplicarse en un plazo de 24 a 72 horas. Nada de esto se ve desde fuera, y todo forma parte de ese 40 % de mantener en marcha.
Queda la parte humana, que es por donde empieza la mayoría de los problemas reales de seguridad informática. Active la verificación en dos pasos para todos los administradores, elimine la cuenta de un empleado el mismo día que se marcha y revise dos veces al año quién tiene permisos de administrador y por qué. Tenemos más material publicado sobre seguridad, pero esas tres costumbres solas ya evitan la mayor parte de los sustos que vemos.
Tiempos de respuesta: qué pedir y qué no pagar
Los contratos de soporte hablan de niveles de gravedad, y la mejor forma de acordarlos es con ejemplos del propio negocio, no con etiquetas abstractas. Que el proceso de cobro esté caído es crítico, porque cada minuto cuesta dinero. Que el informe diario muestre una columna equivocada es grave, porque el trabajo continúa pero las decisiones se toman a ciegas. Que un botón esté descolocado en una pantalla poco usada es menor, aunque moleste a la vista.
Con esa escala ya se pueden escribir objetivos realistas en el contrato: una hora para todo lo que detiene el cobro, cuatro horas o el mismo día laborable para un problema grave, y entre dos y tres días laborables para lo estético. Un proveedor serio acepta esos plazos por escrito, porque sabe que la mayoría de los avisos no son críticos.
Y ahora lo que la mayoría de los lectores no debería comprar. La cobertura las 24 horas los 7 días de la semana cuesta normalmente entre 2,5 y 3 veces la cobertura en horario laboral, sencillamente porque exige un turno rotativo de al menos tres personas para que nadie viva pegado al teléfono. Una clínica que cierra a las seis de la tarde casi siempre acierta comprando horario laboral más un número de urgencias para el fin de semana, y dedicando la diferencia a mejoras que sí nota el personal.
Hay dos detalles que hacen que el soporte funcione de verdad, y no cuestan dinero: una persona con nombre y apellido a cada lado, y un único canal acordado. Cuando el soporte se reparte entre chats personales, tres números de móvil y algún correo suelto, el resultado siempre es el mismo, que es nadie responsable y todo el mundo convencido de que ya lo había avisado.
Los cambios pequeños que deciden si la gente sigue usándolo
Aquí se decide el rendimiento de todo el proyecto, así que merece un párrafo claro: el software que pelea contra la forma en que el personal ya trabaja se abandona en silencio, sin reuniones ni quejas formales, y un sistema que nadie usa cuesta exactamente lo mismo de alojar que uno que todos adoran. Por eso los ajustes pequeños no son caprichos, son lo que convierte una compra en una herramienta.
El primer año tiene una forma reconocible: suelen aparecer entre 30 y 60 peticiones de cambio, de las cuales normalmente solo entre 10 y 15 cambian de verdad cuánto se usa el sistema. Con un presupuesto trimestral de entre 10 y 20 horas de cambios se cubre casi todo lo que importa, siempre que ese tiempo se gaste en las peticiones correctas y no en la que gritó más fuerte.
Para saber cuáles son las correctas hace falta medir tres cosas que cualquiera entiende: cuántos empleados entran cada semana, cuántos registros se crean y cuánto tarda hoy una tarea habitual comparada con el método antiguo. Si emitir un albarán pasó de seis minutos a noventa segundos, tiene un dato con el que defender la inversión ante quien firma los cheques.
Añada un repaso de formación en la semana seis y una guía de dos páginas para el personal nuevo, porque la mayoría de los avisos del segundo mes no son fallos del sistema, son personas a las que se les enseñó una vez, en un día ajetreado, y se les olvidó. En nuestros casos prácticos encontrará ejemplos de sistemas que mejoraron bastante después del lanzamiento, casi siempre gracias a cambios pequeños y bien elegidos.
Cuándo la opción más barata es la correcta
Esta es la sección que nos gusta escribir, porque es donde se gana la confianza. Para una herramienta interna estable que usan cinco personas, sin pagos ni datos delicados, un plan ligero de mantener las luces encendidas de unos 3.600 USD al año es la compra correcta y cualquier cosa mayor es dinero desperdiciado. Vigilancia, copias, parches de seguridad y unas pocas horas al trimestre bastan.
También merece la pena sustituir una parte del sistema a medida por un producto de catálogo cuando el producto es sinceramente mejor, y suele serlo en contabilidad, en facturación electrónica o en email marketing. Cada trozo que se cae del desarrollo propio es un trozo que ya no hay que mantener, así que la pieza a medida se queda pequeña, centrada en lo que su negocio hace distinto, y por tanto barata de cuidar.
Donde sí conviene gastar más es en lo que carga con ingresos, en lo que guarda datos regulados como historiales de pacientes o datos de pago, y en lo que ve el cliente final. En esos tres casos, el coste de un mal día supera con holgura el coste de un año de mantenimiento, y ahorrar ahí es la clase de ahorro que se paga con intereses.
Queda un reflejo caro contra el que avisamos a menudo: cuando un sistema empieza a parecer anticuado, la reacción habitual es proponer rehacerlo entero. En la práctica, una mejora de entre 20 y 40 horas suele resolver la sensación de viejo mucho mejor que una reconstrucción, y solo tiene sentido rehacer cuando el coste de mantener el sistema antiguo supera al de construir uno nuevo. En Linkysoft decimos esto aunque una reconstrucción sea un proyecto más grande para nosotros, porque un cliente que gasta bien vuelve, y uno que gasta de más no.
Sus primeros doce meses y qué poner en el contrato
Si quiere un ritmo sencillo para el primer año, este funciona bien en casi todos los proyectos que acompañamos:
- Semanas 1 a 4: cobertura intensiva, con respuesta rápida y alguien pendiente a diario.
- Mes 2: repaso de formación y primera tanda de correcciones agrupadas.
- Mes 3: primera prueba real de restauración de copias y primeras mejoras pequeñas.
- Mes 6: revisión de las piezas de terceros y de la velocidad del sistema.
- Mes 9: conversación de hoja de ruta para el año siguiente.
- Mes 12: renovación del acuerdo y comprobación de versiones de motor y de sistema operativo.
Y en el contrato hay cinco condiciones que vale la pena defender, todas cortas y todas fáciles de aceptar para un proveedor honesto:
- Una persona de contacto con nombre a cada lado.
- Objetivos de respuesta por escrito, separados por gravedad.
- Un informe mensual breve con lo que se hizo y cuánto tiempo llevó.
- Claridad sobre si las horas no usadas se acumulan al mes siguiente o se pierden.
- Una cláusula de salida que incluya el traspaso completo de todo el material.
El mensaje con el que cerramos es siempre el mismo, y no cambia según el tamaño de la empresa: la pregunta nunca es si el sistema necesita cuidado, sino quién es responsable de él y cuánto ha decidido usted gastar en esa responsabilidad. Un sistema con dueño envejece bien durante años, mientras que uno sin dueño acumula deudas invisibles hasta el día en que todas vencen a la vez.
Si quiere revisar su caso concreto, cuéntenos qué tiene en marcha y en Linkysoft le diremos con franqueza qué nivel de mantenimiento necesita, incluido el escenario en el que le conviene contratar menos de lo que nos gustaría venderle. Puede escribirnos desde la página de contacto y lo hablamos con calma, con sus números encima de la mesa y sin ningún compromiso.
