Tengo un sistema que funciona pero no hace lo que necesito

Si tu sistema funciona y solo se queda corto en un punto, casi nunca hay que cambiarlo entero. Hay cuatro salidas: ampliarlo por dentro, envolverlo con una pieza nueva que se apoya en él, conectarlo con otro sistema que ya hace esa parte, o sustituirlo. La última es la más cara y la que más riesgo tiene, porque tiras también lo que sí funcionaba. Abajo tienes cuándo elegir cada una.

Este artículo es para decidir, no para vender. Si ya sabes lo que necesitas y buscas quién lo haga, ve directo a desarrollo de software a medida o integración de sistemas — o cuéntanos el caso y te decimos qué haríamos.

El problema siempre tiene la misma forma

Cambia el sector y cambia el programa, pero la frase se repite: tengo esto montado, va bien, y no hace X.

• Una web que informa perfectamente pero no reserva: el cliente rellena un formulario y alguien contesta a mano con disponibilidad y precio.
• Un ERP donde nadie mete los partes de trabajo, porque hay que volver a la oficina a teclearlos.
• Un TPV que hace lo suyo pero va lento a determinadas horas, justo las de más venta.
• Una aplicación web que se usa a diario y que la gente pide en el móvil.
• Dos programas que guardan lo mismo por duplicado, y alguien pasa datos de uno a otro.

Ninguno de estos es un sistema roto. Son sistemas que sostienen el negocio y que se han quedado cortos en un punto concreto. Eso importa, porque cambia la respuesta: no estás eligiendo software, estás decidiendo dónde tocar lo que ya tienes.

Y hay una diferencia entre los dos grupos que conviene ver antes de seguir. Los cuatro primeros son un sistema con un hueco. El último es dos sistemas que no se hablan. El segundo caso casi nunca se arregla ampliando: se arregla conectando.

Por qué esto no se decide con una demo

La tentación es pedir demos de productos que hagan lo que falta. El problema es que en una demo todo funciona, porque la demo la monta quien vende.

Lo que decide si un producto encaja no se ve en la demo: es si puede leer y escribir en lo que ya tienes. Un motor de reservas precioso que no sabe consultar tu disponibilidad real es un motor de reservas que vas a rellenar a mano.

Por eso el orden correcto es: primero decidir la forma de la solución (las cuatro de abajo), y después elegir herramienta. Al revés se compra una licencia y luego se descubre el trabajo.

Las cuatro salidas

1. Ampliar por dentro

Se toca el sistema que ya tienes y se le añade la función. Es la opción más limpia si tienes el código y alguien puede mantenerlo.

Cuándo sí: el sistema es tuyo o tienes acceso al código, y lo que falta encaja con cómo está hecho. Si el programa ya gestiona clientes y quieres añadirle un histórico de incidencias por cliente, estás construyendo sobre algo que ya existe.

Cuándo no: es un producto de un tercero que no te deja tocarlo. O cada cambio rompe otra cosa — y eso segundo es una señal de que el problema no es la función que falta, sino cómo está construido lo de debajo. Si cada arreglo trae dos incidencias, la conversación es otra.

Lo que suele salir mal: que no exista nadie que conozca el código. Un sistema hecho hace ocho años por alguien que ya no está, sin documentación y sin tests, se puede ampliar, pero el primer mes se va en entender qué hace. Eso no es un problema insalvable; es una partida del presupuesto que hay que poner por delante, no descubrirla a mitad.

2. Envolver

Se deja el sistema como está y se construye una pieza nueva encima, que se apoya en él.

El caso típico es la app móvil a partir de una web que ya funciona: se empaqueta lo que hay y se le añade lo que solo puede hacer un móvil —cámara, ubicación, avisos, trabajar sin cobertura y sincronizar al recuperarla. La web sigue siendo una sola, así que no acabas con dos productos que mantener en paralelo, que es el coste oculto de hacer una app aparte.

Cuándo sí: lo que falta es una forma nueva de usar lo mismo, no una lógica nueva. El dato y las reglas ya están; lo que cambia es dónde y cómo se accede.

Cuándo no: la pieza nueva necesita datos que el sistema no expone de ninguna manera. Si para pintar una pantalla hay que reconstruir la mitad de la lógica de negocio, ya no estás envolviendo: estás escribiendo un sistema paralelo que se desincronizará.

Lo que suele salir mal: confundir envolver con maquillar. Si la web original es lenta, la app que la envuelve va a ser lenta. Envolver reparte el trabajo de otra forma; no arregla lo que hay debajo.

Es la salida más rentable de las cuatro cuando encaja, y la que menos se plantea — porque no la propone nadie que venda producto.

3. Conectar

Lo que falta ya existe en otro sitio, y el trabajo es que las dos cosas se hablen: el ERP con la tienda, el motor de reservas con la web, la base de datos local con el cloud, el TPV con contabilidad.

Cuándo sí: hay un producto que ya hace bien esa parte y tiene forma real de integrarse. Y —esto se olvida— cuando el dato tiene un dueño claro. Una integración sana tiene siempre un sistema que manda sobre cada dato y otro que lo copia. Cuando los dos escriben lo mismo, no has integrado: has creado dos verdades.

Cuándo no: la integración solo existe sobre el papel. Antes de firmar nada conviene pedir la documentación de la API y comprobar que hace de verdad lo que dice el folleto — y en particular si permite escribir, no solo leer. Muchas integraciones anunciadas son de solo lectura, que sirve para informes y no para operar.

Lo que suele salir mal: la sincronización. Dos sistemas conectados funcionan de maravilla hasta el primer corte de red. Lo que separa una integración que aguanta de una que da guerra cada semana es qué pasa cuando un mensaje se pierde: si se reintenta, si se detecta el duplicado, si alguien se entera de que ha fallado. Eso es trabajo real y hay que presupuestarlo.

4. Sustituir

Cambiar el sistema entero.

Cuándo sí, y son pocos casos:

• El fabricante ha dejado de darle soporte y ya no hay actualizaciones de seguridad.
• No hay forma de sacar los datos, ni por API ni por base de datos ni por exportación.
• Lo que falta no es una función, es la mitad del trabajo. Si en la lista de lo que le pides al sistema hay más cosas que no hace que cosas que sí, no estás ampliando: estás pidiendo otro sistema.
• El coste de mantenerlo vivo ya supera al de reemplazarlo, y eso se puede calcular.

Cuándo no: cuando el sistema aguanta la operación diaria y solo falla en un punto. Cambiarlo significa volver a construir todo lo que ya funcionaba —incluidas las mil reglas pequeñas que nadie ha escrito en ningún sitio y que solo se descubren cuando faltan— y volver a formar a la gente que ya sabía usarlo.

Lo que suele salir mal: subestimar lo que el sistema viejo hacía sin que nadie lo supiera. Las excepciones, los casos raros, el apaño de hace seis años que resolvió un problema concreto. Un reemplazo se juzga por si cubre esos casos, no por si cubre el folleto.

Si aun así hay que sustituir, casi nunca conviene hacerlo de golpe. Se puede ir sacando funciones del sistema viejo una a una, dejándolo en marcha mientras tanto, hasta que se queda vacío. Es más lento de contar y mucho menos arriesgado de vivir.

Las cuatro, de un vistazo

	Qué se toca	Cuándo encaja	Riesgo principal	Lo que la encarece
Ampliar	El sistema por dentro	Tienes el código y lo que falta encaja con cómo está hecho	Que cada cambio rompa otra cosa	Que no quede nadie que conozca el código
Envolver	Nada; se añade encima	Lo que falta es una forma nueva de usar lo mismo	Construir un sistema paralelo sin querer	Que el sistema no exponga los datos
Conectar	Nada; se añade en medio	Lo que falta ya existe en otro producto	Que las dos partes escriban el mismo dato	Que la API sea de solo lectura
Sustituir	Todo	Sin soporte, sin acceso a datos, o falta más de lo que hay	Perder reglas que nadie había escrito	Los casos raros que el sistema viejo sí cubría

Cómo se decide, en la práctica

La pregunta que más ordena no es «¿qué tecnología?» sino ¿puedo llegar a los datos?

Con una base de datos accesible o una API documentada, una pieza acotada suele estar en semanas. Cuando no hay forma de entrar, lo que se alarga no es programar: es averiguar cómo está guardada la información. Ese trabajo existe, cuesta y hay que presupuestarlo aparte en vez de descubrirlo a mitad del proyecto.

Después, tres preguntas más que ordenan casi cualquier caso:

¿Cuánta gente depende de esto cada día? Cuanto más crítico, más peso tiene no tocarlo. Un sistema que usan treinta personas ocho horas al día no se toca igual que uno que usan dos personas los viernes.

¿Lo que falta lo pide el negocio o lo pide una persona? No es lo mismo un hueco que frena ventas o que obliga a que alguien teclee cuatro horas al día, que una comodidad que pidió alguien en una reunión. La primera se paga sola; la segunda hay que justificarla.

¿Cuánto cuesta hoy el apaño? Casi siempre hay uno: un Excel, una persona que copia datos, un correo que alguien contesta a mano. Ese apaño tiene un coste en horas que se puede calcular, y es la referencia honesta contra la que comparar el presupuesto. Si el apaño cuesta dos horas al mes, probablemente no hay proyecto. Si cuesta dos horas al día, el proyecto se paga en meses.

Cómo pedir presupuesto para esto

Lo que más encarece un proyecto de este tipo es la incertidumbre sobre lo que ya existe. Se reduce mucho si en la primera conversación llevas:

• Qué sistema es y de cuándo. Nombre del producto o del framework, y año aproximado.
• Si hay acceso a los datos. Si tienes usuario de base de datos, API, o solo la pantalla.
• Quién lo mantiene hoy. Un proveedor, alguien interno, o nadie.
• El apaño actual. Cómo se resuelve hoy lo que falta, y cuántas horas se van en ello.
• Qué pasa si no se hace nada. A veces la respuesta honesta es «nada grave», y eso también es una decisión.

Con eso se puede decir qué salida de las cuatro encaja sin haber tocado el sistema. Sin eso, cualquier número que te den es una estimación de otra cosa.

Lo que no hay que hacer

Empezar por elegir tecnología. La decisión de arriba no depende del lenguaje ni del framework. Elegir stack antes de saber si vas a ampliar, envolver, conectar o sustituir es contestar una pregunta que aún no se ha hecho.

Pedir un presupuesto cerrado sin que nadie haya mirado los datos. Sale un número que no significa nada, y se ajusta después por la vía de recortar alcance — normalmente lo que menos se ve, que es la parte de que las cosas aguanten cuando fallan.

Dar por hecho que hay que cambiarlo todo. Es la conclusión más cara y suele venir de quien vende el reemplazo. Merece la pena en algunos casos, y son identificables; fuera de esos, es tirar lo que funciona.

Dejar el proyecto sin dueño por tu parte. En todos estos casos hay decisiones que solo puede tomar quien conoce el negocio: qué pasa con los casos raros, qué dato manda cuando dos sistemas discrepan, qué se hace con el histórico. Sin alguien que conteste eso, el proyecto se para o se decide mal.

Cuatro casos reales, y qué salida encajó

Todos son consultas que hemos recibido. Van sin nombre a propósito: lo que importa es la forma del problema, no de quién era.

Una web que informaba pero no reservaba. Empresa de actividades turísticas con la web montada en un gestor de contenidos antiguo. El cliente rellenaba un formulario y alguien contestaba a mano con disponibilidad y precio. La web funcionaba bien como escaparate. Salida: conectar. Lo que faltaba —disponibilidad, cálculo de precio, cobro— ya existe resuelto en motores de reserva. El trabajo real no era programar un motor, era decidir quién manda sobre el calendario y que la web consultara ese calendario en vez de un correo.

Un ERP donde nadie metía los partes. Empresa de servicios con un ERP del sector que sí tenía módulo de partes de trabajo. En diez meses se habían registrado veintiocho. La gente estaba en casa del cliente, con las manos ocupadas, y el parte se metía —o no— al volver a la oficina. Salida: envolver. El ERP no estaba mal; el punto de captura estaba en el sitio equivocado. Una pieza para el móvil que escribe en el mismo ERP, que funciona sin cobertura y sincroniza después. Ampliar el ERP no habría cambiado nada, porque el problema no era el software: era dónde ocurría el trabajo.

Una aplicación web que la gente pedía en el móvil. Aplicación usada a diario, funcionando, con la particularidad de que además necesitaba que la base de datos local se sincronizara con la nube. Salida: envolver y conectar a la vez. La aplicación se empaquetó para el móvil en lugar de rehacerse, y la sincronización se trató como lo que era: un proyecto propio, con sus reglas de qué pasa cuando falla, y no como una casilla del anterior.

Dos canales de atención que no se hablaban. Varias líneas de mensajería, incluidos grupos, y ninguna forma de saber qué se le había contestado a quién. Salida: conectar, con una pieza propia encima. No había producto que hiciera exactamente eso, así que la parte de unificar se compró y la de trazar los casos se construyó. Es la combinación más frecuente en la práctica: casi ningún caso real es una sola de las cuatro salidas en estado puro.

Señales de que el problema no es la función que falta

A veces la conversación empieza por «necesito que haga X» y a los diez minutos se ve que X es el síntoma. Estas son las señales que lo delatan:

Cada cambio rompe algo distinto. Si arreglar una cosa saca dos incidencias en otro sitio, el problema es cómo está construido lo de debajo. Añadir una función más va a costar el triple de lo que parece, y la siguiente el triple de esa.

Nadie sabe explicar por qué hace algo. Reglas de negocio que están en el código y en la cabeza de nadie. No impide trabajar, pero significa que cualquier cambio se hace a ciegas.

El sistema va lento a las horas que importan. Lentitud a horas punta rara vez se arregla con más máquina. Suele ser una consulta concreta, o transacciones que se quedan abiertas, y hasta que no se mide no se sabe. Es barato de diagnosticar y caro de suponer.

Hay dos sitios donde está el mismo dato. Si alguien copia información de un sistema a otro, ya tienes una integración: la hace una persona. Lo que se plantea no es crear una integración, es automatizar la que ya existe.

La gente ha montado su propio circuito por fuera. Excels compartidos, grupos de mensajería, carpetas con nombres de fecha. Eso no es indisciplina: es el sistema diciendo que no cubre algo. Y es la mejor fuente que hay para saber qué falta de verdad.

Qué pasa con los datos cuando se toca un sistema vivo

Es la parte que menos se pregunta y la que más disgustos da.

Copias antes de tocar nada. Parece obvio y no siempre está. Antes de la primera modificación tiene que existir una copia restaurable y alguien tiene que haber probado a restaurarla. Una copia que nunca se ha restaurado no es una copia, es una intención.

Un entorno donde probar. Trabajar directamente sobre el sistema que usa la gente es la forma más rápida de convertir un proyecto pequeño en una urgencia. Montar una copia del entorno para probar cuesta tiempo al principio y lo devuelve entero a la primera semana.

Datos personales. Si el sistema guarda datos de clientes o de empleados y se va a copiar a un entorno de pruebas, esos datos hay que anonimizarlos. No es solo cumplimiento: es que un entorno de pruebas siempre acaba siendo menos vigilado que el de producción.

Quién tiene acceso a qué, después. Un proyecto de este tipo suele implicar dar acceso a alguien de fuera. Conviene decidir desde el principio qué accesos son, por cuánto tiempo, y qué pasa con ellos al terminar.

Dónde acaban los datos. Si parte de la solución se va a la nube, hay que saber a qué proveedor, en qué país y con qué contrato. Es una pregunta de cinco minutos al principio y de varias semanas cuando se hace tarde.

Preguntas frecuentes

¿Puedo hacer una app móvil a partir de la web que ya tengo? Sí, y suele salir bastante más barato que hacer una app desde cero. Se empaqueta lo que ya funciona y se le añade lo que solo puede hacer un móvil. La ventaja de fondo es que sigues manteniendo una sola cosa, no dos.

¿Cuánto tarda añadir una función a un sistema en marcha? Depende sobre todo de si se puede llegar a los datos. Con base de datos accesible o API documentada, una pieza acotada suele estar en semanas. Sin acceso, lo que se alarga no es programar: es entender cómo está guardada la información.

¿Y si el sistema lo hizo otra empresa? Se puede trabajar igual, y es más frecuente de lo que parece. Lo que hace falta es acceso: al código, a los datos o a las dos cosas. Si no hay acceso a nada, las salidas se reducen a envolver o conectar por fuera.

¿Me conviene esperar a rehacerlo todo el año que viene? Casi nunca. Si el hueco cuesta horas todos los días, ese coste corre mientras esperas. Y una pieza bien acotada suele poder reaprovecharse cuando llegue el reemplazo, si se hace pensando en eso.

¿Cómo sé si me están vendiendo un reemplazo que no necesito? Pregunta qué pasa con lo que ya funciona. Si la respuesta no incluye cómo se migran los casos raros, el histórico y las reglas que no están escritas, la propuesta está calculada sobre la parte fácil.

Si quieres que lo miremos

Llevamos desde 2012 metiendo mano en sistemas que ya estaban en marcha: ampliándolos, envolviéndolos o conectándolos con otros. Cuéntanos qué tienes y qué le falta, y te decimos cuál de las cuatro salidas encaja — aunque sea una que no necesite que hagamos nada.

Escríbenos y lo vemos.