Sustituir Excel por software: qué se queda, qué se va y qué conviene aclarar antes

La pista suele estar en el nombre del archivo: “Planificacion_final_nuevo_Version3”. Al lado está “Planificacion_final_nuevo_Version3_Copia”, y todos en la oficina saben que solo una de las dos es correcta. Quien las abre pregunta primero en el pasillo si alguien está trabajando en ella en ese momento. En este escenario suponemos una empresa pequeña cuyos pedidos, citas y cálculos confluyen en un único libro.

El libro no está mal construido. Ha crecido con los años y cada ampliación fue razonable: una columna para el estado, una hoja para el material, una macro que convierte filas en una oferta. Juntas forman un sistema que funciona mientras lo maneje una persona concreta. Si esa persona falta, solo entonces se advierte cuánto conocimiento hay en los colores de celda, los ajustes de filtro y las columnas ocultas.

Por eso la pregunta rara vez es “¿Es malo Excel?”. Es: ¿cuándo cuesta la hoja de trabajo más de lo que aporta y qué perdemos si la sustituimos? Quien quiera sustituir Excel por software debería plantearse primero esta segunda pregunta, porque la respuesta decide si el proyecto sale bien o si solo surge una herramienta nueva con los mismos errores de siempre.

A ello se suma un momento que muchas empresas conocen: un empleado nuevo debe introducir datos y pregunta qué columna significa “fecha de entrega” y cuál “fecha deseada”. La respuesta es: “Eso se ve por el color”. Frases así son inofensivas mientras esté la persona que puede explicarlas. Son una señal de alarma cuando el conocimiento reside en un único lugar.

Excel rara vez falla por potencia de cálculo, sino por simultaneidad y carácter vinculante. Dos personas introducen cambios la misma mañana, una versión sobrescribe a la otra y solo se nota cuando falta una entrega. Incluso con edición compartida en la nube el problema de fondo persiste: cada celda puede contener cualquier cosa y nadie comprueba si una fecha es realmente una fecha.

A ello se suma la invisibilidad de las reglas. Una fórmula remite a una hoja oculta, una macro convierte valores al guardar, un formato condicional colorea de rojo las filas con más de diez días. Nadie ha formulado jamás estas reglas como requisito, y sin embargo la gente confía en ellas. En un relevo, son los puntos que se pierden sin aviso.

Por último, falta trazabilidad. ¿Quién cambió el precio de la fila 214 y cuándo? Excel puede registrar cambios, pero en el día a día el registro es incompleto o está desactivado. Para empresas que gestionan ofertas, protocolos de inspección o datos de clientes, esto es más que una cuestión de comodidad, pues afecta a la responsabilidad, las reclamaciones y la protección de datos.

Un relevo empieza clasificando. Excel es excelente para análisis puntuales, escenarios, modelos de cálculo rápidos y evaluaciones en las que alguien explora datos. Es débil con datos que muchas personas mantienen a la vez, que deben hacer cumplir reglas y que necesitan un historial. Quien mezcla ambas cosas en un archivo suele haber encontrado la causa del problema.

Una distinción útil separa registrar, procesar y analizar. Registrar y procesar pertenecen a una aplicación con formularios, campos obligatorios, permisos y registro de cambios. El análisis puede quedarse en Excel, alimentado desde una exportación limpia. Así el personal conserva la herramienta conocida donde necesita libertad, y los datos ganan disciplina donde la libertad produce errores.

No toda hoja de cálculo merece un software. Una lista con pocas entradas que una persona mantiene una vez al mes está bien en Excel. Un relevo compensa donde muchas personas cambian los mismos datos, donde los errores cuestan dinero o confianza y donde los procesos se repiten con regularidad. Indicaríamos con honestidad qué archivos de la empresa pueden quedarse a propósito.

Una piedra de toque es la pregunta de quién tendría que hacerse cargo del archivo mañana. Si una compañera nueva puede manejarlo con seguridad al cabo de una semana, la estructura es sólida. Si necesita meses y transmisión oral, el archivo ya es un riesgo operativo, sin importar lo bien que calcule.

El camino tentador es el gran golpe: se reconstruye el libro, se cambia en una fecha fija y se apaga Excel. Según la experiencia, esto fracasa por dos cosas. Primero, el alcance funcional del libro antiguo es mayor de lo que parece. Segundo, una fecha fija mete presión justo en el momento en que aparecen los primeros errores. Solo elegiríamos este camino para archivos muy pequeños y manejables.

Resulta mejor un relevo por rebanadas. Primero se cambia el área que más problemas causa y tiene las reglas más claras, por ejemplo el registro de pedidos. Los análisis se quedan al principio en Excel y leen de la nueva fuente. Cada rebanada ofrece por sí sola un estado funcional, y el equipo aprende con un ejemplo manejable en lugar de tener que asimilarlo todo a la vez.

Como alternativa cabe el software estándar, por ejemplo una gestión de pedidos ya hecha o una plataforma low-code. Suele ser la elección correcta si los procesos de la empresa son habituales de todos modos. El software a medida compensa cuando las reglas propias constituyen la ventaja competitiva o ningún producto las refleja. Compararíamos ambas opciones y dejaríamos la decisión a la empresa, no al proveedor.

Una tercera posibilidad es conservar Excel y construirlo con más disciplina: hojas de entrada y de cálculo separadas, validación de datos, fórmulas protegidas, un almacenamiento central con responsabilidad clara. Es barato y rápido, pero llega a su límite en cuanto muchas personas trabajan a la vez o se exigen permisos y registro de cambios. Como paso intermedio puede tener sentido, porque de todos modos hace visibles las reglas que necesitará un relevo posterior.

El paso de trabajo más importante es discreto: leemos el libro como un perito. Se revisa cada hoja para saber qué guarda, qué calcula y en qué se apoya. Lo oculto, lo protegido y lo vinculado se hace visible, y las macros se describen línea por línea. El resultado no es un programa, sino una lista de reglas en lenguaje normal que la empresa puede revisar.

Salen a la luz tres tipos de reglas. Hay reglas explícitas, por ejemplo “descuento a partir de diez unidades”. Hay reglas implícitas que valen solo por costumbre, por ejemplo “los pedidos con fondo rojo se tramitan primero”. Y hay compensaciones de errores, en las que el libro calcula algo mal y el personal corrige la desviación mentalmente. Este tercer tipo no debe adoptarse sin revisar.

Como comprobación se hace una entrevista con quienes trabajan a diario con el archivo, y no solo con la dirección. Preguntas como “¿Qué hace usted cuando la cifra no cuadra?” sacan a la luz lo que ningún documento revela. De ambas fuentes surge una lista que se decide en conjunto: esta regla se queda, esta se simplifica, esta se elimina porque solo era un apaño.

Así surge de paso un beneficio que todavía no tiene que ver con el software. La empresa descubre cómo trabaja en realidad y puede decidir si es lo que quiere. Algunos relevos se vuelven más pequeños, porque una regla superflua desaparece antes de convertirse en código.

En la mudanza se ve cuán indulgente es Excel. La misma columna contiene “12.03.2024”, “marzo 24” y “12/3”. Los nombres aparecen con y sin título, los importes con coma, punto o símbolo de moneda en un campo de texto. Una base de datos exige unicidad, y por eso la depuración decide la calidad del nuevo sistema más que cualquier interfaz. Cuente con una parte considerable del tiempo del proyecto para ello.

Técnicamente, la migración se hace con scripts, no a mano. Los datos se leen, se comprueban, se normalizan y se escriben en la estructura de destino. Las filas que infringen una regla acaban en una lista de errores que el personal especializado de la empresa va resolviendo. Tras cada ejecución comparamos recuentos, sumas y muestras con el origen. Los duplicados y los huérfanos se deciden de forma consciente, no se borran en silencio, y el original permanece intacto como archivo.

La aplicación consta de pocos componentes. Una base de datos guarda pedidos, clientes y posiciones en tablas separadas, una capa de aplicación impone en un solo punto los campos obligatorios, las transiciones de estado permitidas y los cálculos, y una interfaz web refleja la forma de trabajar de la empresa. Los permisos se piensan por roles: la planificación cambia las citas, la contabilidad ve las cifras pero no la comunicación con los clientes. Quien no necesita datos, no los ve; los detalles los aclara la empresa con su asesoría de protección de datos.

Un registro de cambios guarda el usuario, el momento y el valor anterior y el nuevo, también al borrar. La pregunta “¿quién ha cambiado esto?” se convierte en una consulta al historial. La exportación sigue siendo una función fija: cada lista puede obtenerse como archivo CSV o Excel, y los datos están en un formato abierto. Así la empresa sigue siendo independiente del proveedor y los análisis pueden continuar en Excel.

La transición es el momento en que los proyectos se tuercen. Haríamos funcionar lo antiguo y lo nuevo en paralelo durante un tiempo limitado: las mismas operaciones se registran en ambos sistemas y una conciliación periódica muestra las diferencias. Cuesta tiempo y es impopular, pero saca a la luz reglas que se pasaron por alto en el inventario. Cada diferencia es un hallazgo sobre el sistema nuevo o sobre el libro antiguo.

La duración del funcionamiento en paralelo depende del ritmo de la empresa. Quien factura cada mes debería vivir al menos un ciclo de facturación completo en ambos sistemas. Además hace falta una opción de retorno clara: mientras la conciliación muestre dudas, Excel sigue siendo la fuente principal; después cambia el liderazgo y el libro antiguo pasa a solo lectura, no se borra.

Al personal no se le convence con diapositivas de formación. Ayuda implicar pronto a las personas que trabajan a diario con el libro y tomarse en serio sus atajos. Un atajo que alguien ha inventado suele señalar una necesidad real. Introducciones breves sobre casos reales, una persona de contacto en la empresa y un punto de consulta durante las primeras semanas funcionan mejor que los manuales exhaustivos.

También conviene hablar con honestidad de la resistencia. Quien ha sido eficiente durante años con un archivo pierde al principio ritmo en el sistema nuevo. Este efecto es normal y pasajero, pero debe planificarse, por ejemplo aliviando la carga en los picos de trabajo. Quien lo calla genera desconfianza, que luego perjudica al proyecto más que el periodo de aprendizaje.

Un caso especial son las macros que llaman a programas externos o generan documentos. Aquí no basta con leer el código: hay que conocer el resultado. ¿Cómo es la oferta que recibe el cliente y qué no puede cambiar nunca en ella? Estas salidas se reconstruyen como plantillas y se comparan frase por frase con documentos antiguos antes de que pase por ellas la primera operación real.

Un software no promete milagros, pero elimina ciertas clases de errores. Desaparecen los conflictos de versiones porque solo existe un estado de los datos. Las entradas no válidas se detectan en el formulario en lugar de descubrirse en el informe. Los cambios son trazables y los permisos limitan el daño que puede causar un descuido. Son mejoras estructurales que no dependen del estado de ánimo de una persona.

El beneficio se hace medible con indicadores que la propia empresa fija antes de empezar el proyecto. Entre ellos están el número de correcciones tras la captura, el tiempo de cierre mensual y de informes, el número de consultas por versiones poco claras y el tiempo hasta que los nuevos empleados trabajan de forma autónoma. Es importante contar con una base de comparación de las semanas previas al cambio; si no, cualquier afirmación posterior queda en una impresión.

Lo que no se puede prometer: ahorros de tiempo concretos en horas o porcentajes antes de conocer los procesos. Tampoco sería honesto afirmar que todos los implicados van a adorar el sistema nuevo. El objetivo realista es que el trabajo sea más fiable, que la empresa dependa menos de personas concretas y que los datos sigan disponibles. Si compensa económicamente se ve a lo largo de varios meses, no en la primera semana.

A esto se oponen unos costes recurrentes que conviene mencionar abiertamente. Una aplicación necesita alojamiento, actualizaciones, copias de seguridad y, de vez en cuando, ajustes cuando cambian los procesos. Excel parecía gratuito porque los costes posteriores estaban ocultos en horas de trabajo y errores. La comparación solo es justa cuando se presentan ambos lados con honestidad.

La calidad de los propios datos también se convierte en una vara de medir. Tras el cambio se puede contar cuántos registros contienen completos los datos obligatorios y cuántas entradas hubo que corregir después. Estas cifras son incómodas porque muestran debilidades que Excel ocultaba en silencio. Pero son justo lo que una empresa necesita para mejorar sus procesos de forma dirigida en lugar de limitarse a soportar los errores.

De este método pueden extraerse algunos principios. Primero: la lista de reglas es más importante que el código. Quien la mantiene bien puede ampliar el sistema más adelante sin tener que desenterrar de nuevo el conocimiento. Segundo: la depuración de los datos es un subproyecto propio, con responsable propio en la empresa, no un subproducto de la programación.

Tercero: las porciones pequeñas ganan a los grandes golpes. Un área que funciona bien en pocas semanas genera confianza y aporta conclusiones para la siguiente. Cuarto: no declarar a Excel enemigo. Quien deja el archivo como herramienta de análisis quita resistencia al proyecto y conserva una capacidad probada. Quinto: la exportación forma parte del sistema desde el principio, porque asegura la independencia.

Igual de instructivos son los casos en que se desaconseja una sustitución. Si los procesos todavía no están claros, el software solo los fijará. Si el archivo lo lleva una persona para una persona, a menudo basta una hoja de cálculo mejor construida, con validación de entradas y una breve documentación. También eso es un resultado legítimo de una consultoría.

Otro principio se refiere a la responsabilidad tras la puesta en marcha. Una aplicación no es un objeto que se recibe y se olvida. Hace falta alguien en la empresa que recoja peticiones, gestione los permisos y priorice los comentarios; si no, en lo nuevo vuelve a crecer enseguida una maraña de soluciones particulares, solo que de otra forma. Este papel no tiene que ser grande, pero debería estar designado y contar con algo de tiempo.

Sustituir Excel por software rara vez es una tarea técnica; es, ante todo, una tarea organizativa. Usted debe saber qué hace realmente su libro antes de poder juzgar qué debe aportar un sucesor. La sustitución sale bien cuando se documentan las reglas, se depuran los datos, se planifican las transiciones y se implica a las personas. Fracasa cuando se construye una interfaz y se espera que el resto se resuelva solo.

Un primer paso cuesta poco. Abra su libro más importante y anote quién lo edita, qué hojas están ocultas y qué macros se ejecutan. Pregunte a dos compañeros qué hacen cuando una cifra no cuadra. Con esa lista se puede decidir con sobriedad si merece la pena sustituirlo, si basta un archivo de Excel mejor o si primero deberían aclararse los procesos.

Con gusto revisamos con usted un libro así y le damos una valoración clara de qué debería sustituirse, qué puede quedarse y con qué esfuerzo debe contar. No hacemos ninguna promesa de ahorro hasta que se conozcan los procesos.

Planifique con realismo: una sustitución dura más de lo que sugiere la primera impresión del libro, porque las reglas ocultas solo aparecen al leerlo. Por eso, una primera fase bien delimitada y con un marco fijo es mejor punto de partida que una oferta global para todo.