La hoja de cálculo no es necesariamente el problema
Las hojas de cálculo son rápidas, flexibles, conocidas y económicas. Para un proceso cambiante del que se ocupan una o dos personas, pueden ser justo lo que hace falta. Sustituir una hoja de cálculo funcional por software a medida añade costes, formación y mantenimiento, sin que necesariamente mejore el negocio.
El problema empieza cuando la hoja de cálculo asume funciones para las que no se diseñó: gestionar permisos, actualizaciones simultáneas, el estado de los procesos, integraciones, un historial de auditoría o un servicio fiable para clientes y personal.
Siete señales de que hay que tomar una decisión sobre el flujo de trabajo
- Varias personas mantienen copias distintas o no saben cuál es la versión más reciente.
- El proceso depende de fórmulas, macros o conocimientos que solo tiene una persona.
- El personal copia la misma información entre la hoja de cálculo y otros sistemas.
- Personas con distintos roles deberían ver o editar información diferente.
- Cuesta saber quién modificó un valor, aprobó una etapa o debe encargarse de la siguiente acción.
- El archivo se vuelve lento, frágil o difícil de probar a medida que se acumulan las reglas.
- Un error puede retrasar una entrega, dar una cifra financiera incorrecta o afectar un compromiso con un cliente.
La matriz de decisión con cuatro opciones
| Opción | Conviene cuando | Principal contrapartida |
|---|---|---|
| Mantener y mejorar | El volumen es bajo, hay pocos usuarios y el proceso cambia | Control e integración limitados |
| Comprar software | El proceso es habitual y los flujos estándar son adecuados | Coste de suscripción y adaptación al producto |
| Conectar herramientas | Los sistemas existentes funcionan, pero los datos y las acciones no circulan entre ellos | Responsabilidad de las integraciones y límites de los sistemas |
| Desarrollar una herramienta específica | El flujo de trabajo es particular, importante, estable y no está bien cubierto | Coste inicial y responsabilidad continua sobre el producto |
Define los requisitos a partir del trabajo, no de la hoja de cálculo
- 01
Resultado
¿Qué debe haberse conseguido al terminar el proceso?
- 02
Usuarios y roles
¿Quién crea, revisa, aprueba, administra o solo consulta?
- 03
Flujo habitual
¿Qué sucede en la mayoría de los casos, desde el inicio hasta el resultado?
- 04
Excepciones
¿Qué variaciones requieren soporte y cuáles deberían seguir siendo manuales?
- 05
Sistemas
¿Cuál es la fuente de verdad y qué datos o acciones deben transferirse?
- 06
Evidencia
¿Qué historial, estado, aprobación o exportación debe conservar el negocio?
- 07
Medición
¿Qué resultado en tiempo, coste, errores o servicio permitirá comprobar la mejora?
Ejemplo anonimizado: las aprobaciones van más allá de la hoja de cálculo
Un equipo usaba una hoja de cálculo para hacer seguimiento de solicitudes financieras y sus aprobaciones. Los cálculos eran manejables, pero el flujo de trabajo que los rodeaba no: el acceso variaba según el rol, los justificantes estaban en otro lugar, las actualizaciones de estado eran manuales y nadie tenía un registro de auditoría fiable.
Comprar una plataforma generalista habría obligado a la empresa a cambiar más cosas que el proceso en cuestión. Conectar los sistemas resolvía solo una parte del problema. Se justificaba desarrollar una herramienta interna específica porque el flujo de trabajo era estable y tenía consecuencias importantes. Su alcance se mantuvo acotado: solicitudes, aprobaciones según el rol, historial de auditoría e integraciones necesarias.
Qué incluir al evaluar el coste de desarrollo
- La fase de análisis y definición del proceso, no solo el desarrollo de la interfaz.
- Autenticación, permisos, revisión de seguridad, copias de respaldo y capacidad de auditoría.
- Migración de datos e integración con los sistemas existentes.
- Pruebas, puesta en marcha, formación y un procedimiento manual alternativo.
- Alojamiento, supervisión, soporte, actualizaciones de dependencias y cambios futuros.
- El coste de oportunidad del tiempo que necesita dedicar el personal interno a tomar decisiones.
Cuándo no desarrollar una herramienta interna
No desarrolles una herramienta si un producto con soporte cumple los requisitos importantes, el proceso no tiene una persona responsable, las reglas cambian cada mes o la organización no puede mantener el resultado. Evita una sustitución completa si una integración o una interfaz operativa sencilla resuelve la mayor parte del problema.