¿Mejorar Excel o Coda, comprar software o desarrollar un sistema propio?

Cuando una empresa empieza a sentir que Excel, Coda, Airtable, Notion u otra herramienta ya no alcanza, es fácil llegar a una conclusión apresurada: “necesitamos desarrollar un sistema propio”.

No siempre es así.

En algunos casos conviene ordenar y mejorar lo que ya existe. En otros, un software disponible en el mercado puede resolver el problema con menor costo y en menos tiempo. También hay situaciones donde sí tiene sentido desarrollar una aplicación a medida porque los procesos son particulares, requieren integraciones específicas o necesitan crecer con reglas que una herramienta estándar no puede representar bien.

La decisión correcta no debería empezar por la tecnología, sino por una pregunta más importante:

¿Qué problema operativo estamos intentando resolver y cuánto nos cuesta seguir trabajando como ahora?

En EstudioPHP abordamos este tipo de decisiones desde el análisis del proceso actual antes de recomendar una plataforma, una integración o un desarrollo nuevo.

Si la duda todavía es identificar cuándo Excel empieza a quedarse corto, esa evaluación previa tiene señales propias. Aquí el foco es distinto: comparar tres caminos posibles una vez que la empresa ya sabe que necesita mejorar su forma de trabajar.

Antes de reemplazar una herramienta, hay que entender qué está funcionando

Que un sistema esté desordenado no significa necesariamente que deba eliminarse.

En un diagnóstico realizado sobre la operación de una empresa de servicios encontramos una solución construida progresivamente sobre una plataforma low-code. Con el tiempo había crecido hasta superar las 90 páginas, con 14 tablas base, 18 vistas y procesos operativos importantes que ya funcionaban dentro de la herramienta. Al mismo tiempo, varias tareas financieras continuaban gestionándose en hojas de cálculo.

La conclusión no fue “hay que reemplazar todo”. Primero era necesario identificar:

• qué procesos ya estaban funcionando correctamente;
• qué información estaba duplicada o parcialmente migrada;
• qué tareas seguían dependiendo de Excel;
• qué relaciones entre datos necesitaban aclararse;
• qué procesos representaban un riesgo operativo;
• qué partes podían mejorarse sin obligar a la empresa a migrar todo de inmediato.

Este paso es importante porque reemplazar un sistema que todavía aporta valor puede aumentar innecesariamente el costo, el tiempo y el riesgo del proyecto.

Opción 1: mejorar Excel, Coda u otra herramienta existente

Esta alternativa suele tener sentido cuando la empresa ya tiene un flujo de trabajo conocido y la herramienta todavía puede soportarlo con algunos ajustes.

Por ejemplo, puede ser razonable mantener el sistema actual cuando:

• el número de usuarios todavía es manejable;
• los procesos principales funcionan;
• el problema está concentrado en unas pocas áreas;
• existe información histórica difícil de migrar;
• los usuarios ya conocen la herramienta;
• una reorganización puede resolver la mayor parte de los problemas.

En el caso analizado, parte de la operación ya estaba centralizada en la plataforma low-code, mientras que caja, egresos, devoluciones y otros procesos seguían dependiendo de Excel. La primera recomendación no fue abandonar la herramienta, sino separar lo que funcionaba de lo que necesitaba rediseñarse.

Ventajas de mejorar lo existente

• Menor inversión inicial.
• Menor impacto sobre los usuarios.
• Menos migración de información.
• Implementación por etapas.
• Posibilidad de conservar el histórico.
• Tiempo de puesta en marcha más corto.

Limitaciones

El problema aparece cuando la herramienta empieza a forzar a la empresa a trabajar alrededor de ella. Si cada nueva necesidad requiere fórmulas difíciles de mantener, procesos manuales, tablas duplicadas o soluciones temporales, el costo oculto empieza a crecer.

En ese punto puede convenir convertir gradualmente un proceso de Excel en una aplicación web, pero no basta con preguntar cuánto cuesta cambiar la herramienta: también hay que calcular cuánto cuesta seguir dependiendo de ella.

Opción 2: implementar un software existente o SaaS

Antes de desarrollar una solución propia, conviene revisar si ya existe un producto que resuelva el problema de forma razonable. Un SaaS puede ser la mejor opción cuando el proceso de la empresa es relativamente estándar.

• CRM.
• Facturación.
• Inventario.
• Ventas.
• Gestión de proyectos.
• Recursos humanos.
• Soporte al cliente.
• Reservas.
• Contabilidad.

Si un producto existente cubre la mayor parte de lo necesario y la empresa puede adaptar razonablemente su proceso, desarrollar desde cero puede ser una inversión innecesaria.

Ventajas de un SaaS

• Implementación rápida.
• Menor inversión inicial.
• Actualizaciones administradas por el proveedor.
• Infraestructura ya resuelta.
• Funciones que han sido probadas por otros usuarios.

Qué debe evaluarse antes de contratarlo

No basta con comparar listas de funciones. Hay que revisar:

• si el flujo real de trabajo encaja;
• cuánto habrá que adaptar el proceso;
• costos por usuario y costos futuros;
• límites de almacenamiento;
• integraciones disponibles;
• exportación de datos;
• dependencia del proveedor;
• soporte;
• qué ocurre si la empresa decide migrar.

Un software económico puede terminar siendo caro si obliga al equipo a mantener procesos paralelos en Excel o WhatsApp porque determinadas operaciones no pueden resolverse dentro de la plataforma.

Opción 3: desarrollar software a medida

El desarrollo propio empieza a justificarse cuando la operación tiene reglas que realmente la diferencian o cuando las herramientas existentes generan demasiadas restricciones.

Puede tener sentido cuando:

• los procesos centrales son particulares;
• existen varias plataformas que deben integrarse sin perder trazabilidad;
• hay reglas de negocio complejas;
• se necesita controlar la evolución del sistema;
• los usuarios realizan demasiado trabajo manual que podría automatizarse con reglas claras;
• el volumen de información está creciendo;
• adaptar un producto existente resulta más costoso que construir una solución adecuada.

Cuando varias aplicaciones necesitan comunicarse, conectarlas mediante APIs puede ser parte de la solución sin obligar a sustituir cada sistema existente.

En el caso analizado, una posible evolución consistía en construir una aplicación web centrada en el expediente principal de la operación y relacionarlo con pasajeros, servicios, proveedores, cobranzas, pagos y saldos. Incluso en ese escenario no se planteó una migración histórica completa desde el primer día.

La alternativa era comenzar con las operaciones nuevas y conservar temporalmente el sistema anterior como consulta histórica. Esto reduce el riesgo y permite modernizar por etapas.

Digitalizar no significa haber integrado

Una empresa puede haber dejado el papel y aun así seguir teniendo un problema de sistemas. Durante el diagnóstico encontramos información repartida entre una plataforma low-code y hojas de cálculo, además de estructuras que habían evolucionado con el tiempo y requerían reconciliación antes de eliminarse.

Por ejemplo, había dos conjuntos de datos de pasajeros con aproximadamente 386 y 368 registros. A primera vista podría parecer que bastaba con borrar uno, pero no estaba completamente confirmado que todos los registros, relaciones y adjuntos hubieran sido trasladados correctamente.

Eliminar la tabla sin analizarla podía significar perder información.

Antes de “limpiar” un sistema, hay que entender la historia de los datos.

Automatizar un proceso ambiguo puede empeorar el problema

Uno de los procesos financieros analizados tenía relaciones entre caja, bancos y tarjetas. Sobre aproximadamente 580 notas de cobranza existían combinaciones donde un mismo proceso podía estar relacionado simultáneamente con más de una de esas fuentes.

Eso no demostraba que hubiera duplicación. Lo comprobado era que primero debía definirse qué representaba cada registro y que existía riesgo de doble contabilización si las reglas se interpretaban de forma incorrecta.

Por ejemplo:

1. El cliente realiza un pago.
2. El pago se registra como cobranza.
3. El dinero posteriormente aparece en una cuenta bancaria.

Si el sistema interpreta ambos registros como ingresos nuevos, una operación real de 1,000 podría terminar apareciendo como 2,000. La tecnología puede automatizar el cálculo perfectamente y aun así entregar un resultado incorrecto.

Automatizar un proceso que todavía no está bien definido puede acelerar los errores en lugar de eliminarlos.

Cómo decidir entre mejorar, comprar o desarrollar

Una comparación inicial puede verse así:

No existe una opción que gane siempre. La decisión depende de cuánto valor aporta cada alternativa frente a su costo y riesgo.

Un proceso práctico para tomar la decisión

1. Auditar el proceso actual

Documentar cómo trabaja realmente la empresa, no cómo se supone que debería trabajar. Hay que identificar herramientas, archivos, tablas, responsables, pasos manuales, duplicación de información, reportes, integraciones y excepciones.

2. Identificar qué ya funciona

No todo debe reconstruirse. Una migración segura empieza preservando aquello que ya aporta valor.

3. Separar los problemas de proceso de los problemas de software

A veces una herramienta parece ser el problema cuando en realidad no existe una regla clara dentro de la empresa. Cambiar de plataforma no corrige automáticamente una operación ambigua.

4. Revisar productos existentes

Antes de desarrollar, conviene comparar alternativas reales, no por cantidad de funciones, sino por capacidad para representar el proceso.

5. Calcular el costo de adaptación

Hay dos costos diferentes: adaptar el software a la empresa y adaptar la empresa al software. Ambos deben considerarse.

6. Desarrollar a medida cuando exista una razón empresarial

El desarrollo propio debe resolver una ventaja o una limitación concreta. No debería ser una decisión basada únicamente en que “un sistema propio suena mejor”.

Señales de que todavía puedes mejorar lo que ya tienes

• Los procesos principales funcionan.
• Los problemas están localizados.
• El equipo puede seguir trabajando mientras se mejora.
• La información histórica está bien organizada.
• Las limitaciones todavía pueden resolverse sin crear una arquitectura demasiado compleja.

Señales de que deberías evaluar un SaaS

• El proceso es estándar.
• Existen productos maduros para la necesidad.
• Necesitas implementar rápido.
• El presupuesto inicial es limitado.
• La empresa puede adaptarse al flujo de la plataforma sin perder eficiencia.

Señales de que un sistema a medida empieza a tener sentido

• Excel, WhatsApp o varias herramientas se han convertido en partes inseparables del proceso.
• Existe información duplicada.
• Los reportes requieren consolidación manual.
• Los sistemas no se comunican.
• Las reglas del negocio son particulares.
• El equipo realiza tareas repetitivas que podrían automatizarse.
• El crecimiento está aumentando el riesgo operativo.

Una sola señal no justifica necesariamente desarrollar software. Varias de ellas juntas sí justifican, como mínimo, realizar un diagnóstico.

Modernizar no significa empezar de cero

Uno de los errores más comunes es plantear una modernización como una sustitución total. En muchos proyectos es más seguro avanzar de manera gradual:

1. entender el sistema existente;
2. identificar los procesos críticos;
3. corregir primero los mayores riesgos;
4. integrar lo que todavía sirve;
5. desarrollar los nuevos componentes;
6. migrar información solamente cuando exista una razón clara.

Este enfoque reduce interrupciones y permite que la inversión acompañe al crecimiento real de la empresa.

La pregunta correcta no es “¿qué software compro?”

La pregunta debería ser:

¿Qué necesita cambiar en nuestra operación y cuál es la forma más razonable de conseguirlo?

A veces la respuesta será mejorar Excel o Coda. A veces será implementar un SaaS. Y otras veces será desarrollar una aplicación propia.

Una buena decisión tecnológica no se mide por cuánto software nuevo se implementó, sino por cuánto mejoró la operación de la empresa.