Antes de cambiar el software principal, averigua qué está fallando de verdad

Antes de cambiar de software, averigua qué está fallando

En muchas empresas las quejas empiezan por algo muy visible: el equipo tiene que salir del programa principal para terminar su trabajo. Hay datos en Excel. Parte de la información llega por correo. Algunas gestiones se completan en otra aplicación. Con el tiempo aparece una conclusión bastante lógica: «necesitamos cambiar de software».

Una aplicación puede estar funcionando bien y aun así formar parte de una gestión incómoda. Un ERP registra correctamente los pedidos aunque estos lleguen por correo y alguien tenga que prepararlos antes. Un CRM sirve al equipo comercial aunque para algunas gestiones haya que consultar datos del ERP. Una tienda online vende sin problemas y después deja tareas que dependen de otras herramientas.

En restauración ocurre algo parecido. El TPV puede cumplir bien su función aunque parte del trabajo de reservas o atención dependa de otras aplicaciones.

En ese escenario, cambiar la aplicación principal puede dejar intacta la causa del problema. La herramienta nueva también tendrá que recibir información de fuera. Si nadie revisa de dónde salen realmente las tareas manuales, la empresa puede terminar una migración y descubrir después que sigue haciendo casi las mismas comprobaciones.

Hay situaciones en las que cambiar está plenamente justificado. La cuestión es que la sustitución debe responder a una limitación concreta que la empresa haya identificado.

Localiza de dónde sale el trabajo manual

Si el programa ya no puede cubrir una necesidad importante, cambiarlo merece una evaluación seria. Cuando sigue cumpliendo bien su función, conviene revisar antes qué ocurre alrededor.

Al revisar el trabajo diario suelen aparecer tres situaciones distintas.

La entrada sobre limitaciones del software SaaS y procesos que no encajan explica cómo distinguir una limitación real de una diferencia que simplemente obliga a trabajar de otra manera. En este artículo partimos de un caso distinto: la empresa ya tiene un problema y necesita saber si cambiar de sistema lo resolverá.

Qué comprobar antes de sustituir el programa principal

Contar tareas manuales sirve para detectar que algo va mal, pero no explica dónde está el problema. La primera revisión debe centrarse en si el programa sigue cumpliendo bien la función para la que se utiliza.

¿El programa sigue haciendo bien su trabajo?

Una sola aplicación no tiene que gestionar toda la empresa. Sí debe resolver bien aquello para lo que se utiliza.

En un ERP, por ejemplo, habría que comprobar que los datos principales del negocio siguen siendo fiables y que las operaciones que dependen de ellos se pueden gestionar correctamente. En un CRM, la revisión debería centrarse en si el equipo comercial puede trabajar con la información que realmente necesita.

Si la información del programa es fiable y el trabajo manual aparece antes de utilizarlo o después, sustituirlo quizá no resuelva la causa. En cambio, hay un problema más serio cuando el equipo mantiene fuera información esencial porque el producto no sabe gestionarla de una forma útil.

¿Se puede confiar en los datos y en los permisos?

Un programa principal deja de servir bien si el equipo ya no confía en sus datos. Lo mismo ocurre cuando no está claro quién puede modificar determinada información.

Una configuración deficiente de permisos se puede corregir. Es distinto que el producto no permita aplicar los controles que la empresa necesita para trabajar.

¿Puede intercambiar la información necesaria con otras aplicaciones?

El programa principal casi siempre convive con otras aplicaciones. Hay que saber si puede intercambiar con ellas la información que realmente necesita la empresa.

Las opciones dependen del producto. Quizá ya exista una integración. En otros casos habrá que utilizar una API, que permite consultar o actualizar información de forma estructurada. También existen soluciones basadas en importaciones o exportaciones.

Tener una API no garantiza que cualquier integración sea sencilla. La ausencia de una API pública tampoco obliga automáticamente a migrar. Lo que hay que comprobar es si existe una forma razonable de intercambiar la información necesaria.

¿Cada cambio obliga a montar otra solución alrededor?

Hay programas que siguen funcionando, pero cualquier cambio pequeño empieza a costar demasiado. Una necesidad sencilla acaba en otra hoja o en un desarrollo específico. Con los años, mantener todo eso se complica.

Después de años de cambios es fácil acabar con configuraciones que nadie entiende del todo. Algunas soluciones que nacieron como provisionales se vuelven imprescindibles. Entonces una modificación pequeña puede requerir demasiado trabajo.

¿El producto sigue siendo una opción razonable para los próximos años?

Un programa con muchos años de uso puede seguir siendo perfectamente válido. La edad, por sí sola, no es un criterio suficiente.

Importa que el producto siga recibiendo soporte y que pueda mantenerse con seguridad. También debe seguir siendo compatible con las herramientas que la empresa utiliza.

Un producto bien mantenido puede seguir siendo válido durante muchos años. El fin de soporte o una limitación que impida un cambio necesario para el negocio sí justifican estudiar una sustitución.

Qué puede salir de esa revisión

Al terminar la revisión debería quedar claro qué está fallando y cuánto cuesta corregirlo sin migrar . También debería saberse qué parte del trabajo seguiría existiendo aunque se implantara otro programa, porque ese esfuerzo no desaparece solo por cambiar de proveedor.

Cambiar cuesta bastante más que la nueva licencia

El precio del nuevo software es fácil de ver. Los costes que rodean una migración suelen estar más repartidos y aparecen antes de que la herramienta nueva esté funcionando con normalidad. Parte del trabajo está en preparar los datos. Otra parte aparece mientras el equipo aprende a utilizar el nuevo sistema y se ajustan las conexiones que ya existían.

Para decidir con criterio hay que comparar el coste real de mantener la situación actual con el coste real de cambiar. Mantener el programa actual tiene un coste cuando obliga a repetir tareas o corregir errores. Cambiar también lo tiene: hay que implantar la nueva herramienta y trasladar la información necesaria. Después habrá que adaptar el trabajo del equipo.

Integrar no es automáticamente más barato y migrar tampoco garantiza una solución mejor. Todo depende del problema concreto que se quiera resolver. Una integración mal planteada también puede generar mantenimiento durante años, del mismo modo que una migración puede ser razonable cuando evita seguir acumulando soluciones provisionales.

Cuándo el programa sí se ha quedado corto

A veces seguir añadiendo soluciones alrededor solo aplaza una sustitución necesaria. Sucede cuando la limitación afecta a una función que la empresa necesita de forma estable.

Hay motivos para estudiar una sustitución cuando aparecen varias señales como estas:

• El sistema no puede representar datos o estados esenciales para operar correctamente.
• Las funciones críticas dependen de modificaciones difíciles de mantener que impiden actualizar o evolucionar.
• No existe una forma suficientemente fiable y segura de acceder a información necesaria para procesos importantes.
• Los permisos disponibles no permiten separar responsabilidades o accesos de una manera compatible con las necesidades reales.
• El producto deja de recibir soporte o actualizaciones relevantes para la operación.
• Cada mejora importante exige soluciones temporales que se acumulan y se vuelven imprescindibles.
• El negocio ha cambiado de forma significativa y el producto ya no puede acompañar el nuevo modelo.
• El esfuerzo de mantener excepciones, tareas manuales y conexiones frágiles empieza a superar de forma razonable el riesgo de cambiar.

Una sola señal no obliga a migrar. Si la empresa dedica cada vez más tiempo a compensar una limitación del producto, mantenerlo merece una revisión seria.

Cuando el problema está en el intercambio entre aplicaciones

Si las aplicaciones actuales funcionan bien y el trabajo manual aparece al intercambiar información, quizá no haya que sustituir ninguna. En ese caso interesa revisar exactamente qué dato se vuelve a introducir a mano y en qué momento aparece la comprobación que hace perder tiempo.

Por ejemplo, el equipo comercial puede trabajar bien en el CRM y el equipo administrativo utilizar el ERP sin problemas. Si alguien tiene que volver a introducir en el ERP información que ya existe en el CRM, cambiar uno de los dos programas no elimina necesariamente esa tarea. Primero habría que comprobar si ambos pueden intercambiar esos datos.

Conectar las aplicaciones es una opción razonable cuando:

• Las aplicaciones actuales son fiables en su función.
• El trabajo manual aparece en el traspaso de datos, documentos o estados.
• Los datos necesarios pueden consultarse y actualizarse por mecanismos mantenibles.
• Una migración obligaría a sustituir también herramientas que funcionan bien.
• La dificultad afecta a una parte del recorrido, no a todo el programa principal.
• La empresa puede definir claramente qué aplicación confirma cada dato importante.

Trabajar con varias aplicaciones exige saber cuál se toma como referencia para cada dato importante. También hay que decidir qué hacer si dos sistemas contienen valores distintos. La guía sobre integración entre CRM y ERP entra con más detalle en estas decisiones.

Antes de añadir nada, revisa lo que ya puede hacer el programa

Antes de añadir otra herramienta, merece la pena comprobar si el producto actual ya resuelve la necesidad. Esta revisión suele ser mucho más barata que iniciar una integración o una migración y, además, evita construir fuera algo que el propio software ya puede hacer.

El producto puede haber incorporado funciones después de la implantación. También puede ocurrir que una configuración muy básica haya dejado sin usar capacidades disponibles desde el principio.

Oracle recomienda aprovechar primero las funciones estándar cuando cubren el requisito y tener en cuenta el mantenimiento futuro. La recomendación es aplicable más allá de ese proveedor: si una configuración razonable resuelve el problema, añadir otra herramienta solo introduce más elementos que mantener.

Una necesidad concreta puede resolverse sin cambiar de sistema

Hay necesidades que no justifican cambiar el sistema principal y que tampoco se resuelven con una integración sencilla. En esos casos puede bastar con añadir una función concreta. La condición es que esa pieza tenga un cometido bien definido y no termine convirtiéndose en otro sistema paralelo difícil de mantener.

A veces basta con una interfaz interna para gestionar una excepción recurrente. En otra empresa puede hacer falta un portal para clientes o una herramienta documental.

El programa principal sigue ocupándose de su función habitual. La nueva solución se limita al problema que se ha identificado. Para comparar esta opción con otras alternativas puede consultarse nuestra guía sobre SaaS, integración o automatización a medida.

Un ejemplo: el ERP recibe la culpa por un trabajo que empieza fuera

Imaginemos una empresa de 50 empleados que utiliza un ERP para gestionar sus pedidos y la facturación. El equipo comercial trabaja en un CRM distinto. Algunos pedidos especiales llegan por correo con documentos adjuntos. Otros clientes envían una hoja de cálculo.

El equipo administrativo abre esos mensajes y averigua a qué cliente corresponden. Después comprueba la información necesaria para poder preparar el pedido. Cuando falta algún dato, tiene que buscarlo en el CRM. Solo entonces puede registrar el pedido en el ERP. Algunas excepciones se anotan además en una hoja compartida.

La dirección acaba concluyendo que el ERP «obliga a hacer demasiado trabajo manual» y empieza a valorar su sustitución.

Al revisar el caso aparecen varios datos que cambian el diagnóstico:

• El ERP mantiene correctamente clientes, productos, pedidos y facturas.
• Los problemas empiezan antes de que el pedido llegue al ERP, porque la información entra por canales y formatos diferentes.
• Parte de la información necesaria ya existe en CRM y ERP, pero una persona debe consultarla y relacionarla.
• Las excepciones requieren control, pero no justifican que todo el proceso viva en una aplicación nueva.

Con esos datos todavía no hay una razón suficiente para cambiar de ERP. Antes probaría a reducir el trabajo que ocurre antes de registrar el pedido. La automatización lee el correo y extrae la información útil. Después consulta las referencias necesarias en los sistemas existentes. El pedido quedaría preparado para que se valide antes de crearlo.

Después habría que medir cuánto trabajo manual queda y cuántas correcciones siguen siendo necesarias. Si la mejora se mantiene, la empresa habrá eliminado tareas sin asumir una migración completa.

Una migración también puede hacerse por etapas

Si la sustitución está justificada, queda decidir cómo hacer el cambio sin asumir más riesgo del necesario.

Microsoft y AWS documentan enfoques de sustitución progresiva en los que el sistema anterior convive temporalmente con la nueva solución. Para una empresa esto significa que no siempre es obligatorio apagar una aplicación un viernes y empezar con otra completamente nueva el lunes.

Cuando técnicamente sea posible, una empresa puede empezar trasladando una función concreta. Después comprueba su funcionamiento con usuarios reales y retira esa parte del sistema anterior. El resto puede mantenerse durante un tiempo.

Trabajar por fases reduce parte del riesgo, pero durante un tiempo hay que dejar muy claro qué sigue funcionando en cada sistema. Esa convivencia debe tener una fecha de retirada definida.

Comparar conservar y cambiar con los mismos criterios

Para comparar bien, hay que hacer las mismas preguntas a las dos opciones.

Probar con un caso real antes de decidir

No hace falta empezar pidiendo propuestas a muchos proveedores. Un caso representativo permite comprobar primero si la causa está realmente en el programa. También obliga a trabajar con datos reales del día a día en lugar de discutir sobre impresiones generales acerca de la herramienta.

1. Elige un proceso que hoy genere trabajo manual repetitivo.
2. Dibuja qué parte resuelve realmente el programa actual.
3. Identifica qué pasos ocurren fuera y por qué.
4. Separa problemas de configuración, conexión, proceso y capacidad del propio sistema.
5. Comprueba qué mecanismos de integración existen de verdad.
6. Prueba una solución pequeña si el problema está entre herramientas.
7. Mide tiempo manual, errores, excepciones y mantenimiento.
8. Compara el resultado con el coste y el riesgo estimados de cambiar.
9. Decide si conviene ampliar la mejora, reconfigurar o iniciar una evaluación seria de sustitución.

Una prueba de este tipo no permite extrapolar el resultado a toda la empresa, pero sí evita tomar una decisión grande a partir de una impresión general.

Para medir la prueba hay que observar cuánto trabajo manual queda y cuántas correcciones siguen siendo necesarias. También interesa saber si continúan apareciendo hojas paralelas o datos contradictorios. La guía sobre KPIs de automatización de procesos explica con más detalle cómo medir una automatización.

Preguntas frecuentes antes de cambiar el programa principal

La pregunta que haría antes de cambiar

Un programa antiguo puede seguir funcionando bien y un SaaS reciente quedarse corto para una necesidad concreta. La edad del producto dice poco por sí sola.

Antes de iniciar una migración plantearía una pregunta sencilla: si redujéramos el trabajo manual que ocurre fuera del programa, ¿seguiría cumpliendo bien la función para la que lo necesitamos?

Si la respuesta es sí, merece la pena intentar corregir primero ese trabajo externo. Si la respuesta es no, seguir añadiendo integraciones puede estar retrasando un cambio que ya tiene una causa concreta.

Después se puede decidir qué tecnología utilizar. La IA reduce parte del trabajo de interpretación que hoy hacen las personas, pero conservar o sustituir el programa depende de si sigue cumpliendo bien su función.