¿Necesitas una aplicación a medida o puedes seguir trabajando con Excel?
Una hoja de cálculo puede resolver mucho. El problema aparece cuando deja de ser fácil, segura o fiable para el equipo.
Por Fran Navarro. Publicado: . Actualizado: .
Cuándo seguir con Excel
Si pocas personas editan datos, el proceso es sencillo y no hay problemas de versiones, quizá baste con una plantilla mejor diseñada y validaciones.
Cuándo evaluar una aplicación
Cuando necesitas permisos por rol, trazabilidad, formularios guiados, múltiples usuarios o reglas complejas, una aplicación puede ofrecer un flujo más controlado.
Antes de desarrollar
Documenta los casos de uso, los usuarios y las excepciones. Una aplicación a medida necesita mantenimiento; no conviene crearla si un proceso más simple resuelve el problema.
Ejemplo de cambio de escala
Un responsable puede registrar presupuestos en una hoja y trabajar cómodamente. Cuando cinco personas deben editarla, aprobar distintos estados y consultar historial, comienzan los conflictos. Una aplicación con permisos, validaciones y registros de cambios puede ayudar, pero debe justificarse por problemas observables y no por la mera idea de modernizar.
Qué preguntar a quien la desarrolle
¿Se podrá exportar la información? ¿Cómo se harán copias de seguridad? ¿Quién gestiona permisos? ¿Qué cuesta mantenerla? ¿Puede crecer por módulos? Pide una primera versión concreta y pruebas con usuarios reales. Conserva la posibilidad de cambiar de proveedor y de acceder a los datos en formatos razonables.
La hoja no deja de servir por tener varias personas
Antes de desarrollar, revisa si el problema está en columnas ambiguas, datos duplicados o varias copias del archivo. Una tabla común, validaciones y responsables pueden mejorar mucho el trabajo. Excel permite coautoría en entornos compatibles, por lo que «somos varios» no basta para justificar una aplicación.
Ejemplo ficticio: dos personas registran consultas y filtran pendientes. Si las reglas son sencillas y el acceso está controlado, una hoja organizada puede resolverlo. El escenario cambia cuando cada registro necesita aprobación, restricciones por rol e historial obligatorio. Entonces conviene describir requisitos observables: quién puede modificar un importe, cómo se conserva el dato anterior y qué ocurre si dos usuarios actúan a la vez.
Compara tres opciones, incluyendo herramientas existentes
La primera opción es mejorar la hoja y el procedimiento. La segunda es adaptar una herramienta existente que cubra la necesidad con un coste asumible. La tercera es desarrollar a medida cuando las reglas propias o integraciones lo justifican. No hace falta elegir la más sofisticada para trabajar mejor.
Una aplicación exige diseño del proceso, validaciones, pruebas, permisos y continuidad. Si los datos siguen llegando incompletos o nadie acepta un criterio común, el desarrollo puede trasladar el desorden a otra pantalla. Pide una demostración del caso principal y de sus excepciones. No te conformes con ver un formulario bonito: prueba qué pasa al cancelar, corregir o repetir una acción. Si hay datos reales de negocio, comprueba el aislamiento y el acceso antes de incorporarlos.
Cómo definir una primera versión sostenible
Enumera usuarios, entradas, estados y salidas. Separa lo imprescindible de lo deseable: quizá la primera versión solo necesita recibir solicitudes, asignarlas y exportar un registro. Deja informes avanzados para después si no son necesarios para operar. Define una prueba de aceptación que cualquiera pueda repetir y reconocer como correcta.
Pregunta por propiedad del código cuando corresponda, exportación de datos, copias y restauración, coste de alojamiento y mantenimiento. Aclara quién gestiona incidencias y cómo se incorpora un nuevo usuario. Compara el coste completo con el problema actual, incluidos errores y tiempo de revisión. El árbol interactivo orienta la conversación y también puede recomendar seguir con Excel o revisar una solución existente. Antes de pedir presupuesto, describe un proceso concreto que hoy falle y aporta un ejemplo ficticio con sus resultados esperados.
Documenta el problema antes de escoger tecnología
Describe una tarea que falle hoy, cuántas veces ocurre y cómo se corrige. Añade quién interviene, qué información necesita y qué permisos deberían existir. Revisa si una plantilla o una herramienta ya disponible resuelve el caso. Si no, prepara una primera versión a medida con una prueba clara. El árbol de decisiones ayuda a ordenar esas preguntas; no convierte una respuesta en un contrato de desarrollo. Una solución pequeña, exportable y mantenible puede ser más adecuada que una aplicación con muchas funciones que nadie utiliza.
Preguntas frecuentes
¿Varios usuarios obligan a desarrollar una aplicación?
No. Revisa antes coautoría, estructura, permisos y herramientas existentes. Los requisitos concretos deben justificar el cambio.
¿Puedo pedir una primera versión pequeña?
Sí. Define un proceso central, sus excepciones y criterios de aceptación antes de añadir módulos.
Fuentes y documentación
Documentación consultada el 26 de octubre de 2026.
Activa JavaScript para utilizar la herramienta interactiva de este artículo.
Ver aplicaciones a medida para pymes