Pasar de Excel a un sistema no consiste en importar todas las hojas y reproducir cada fórmula. Consiste en reconstruir el proceso: qué entrada es válida, qué dato es autoritativo, qué regla produce una salida, quién decide una excepción y qué historial merece conservarse.
Si la hoja mezcla datos, reglas, parches y conocimiento de una persona, trasladarla tal cual convierte el desorden actual en requisitos del sistema nuevo. El orden correcto es: inventariar → separar → decidir qué conservar → diseñar el proceso objetivo → probar la transición → retirar la fuente anterior.
Excel no es el problema por defecto
Una hoja puede ser suficiente cuando el trabajo es acotado, la edita poca gente, el dato no necesita coordinar varios sistemas y una persona puede comprobar el resultado sin riesgo desproporcionado.
El cambio merece evaluarse cuando el proceso empieza a depender de condiciones como estas:
- existen varias copias y nadie sabe cuál es la vigente;
- la misma información se vuelve a escribir en correo, CRM, facturación u otra hoja;
- una fórmula o macro solo la entiende una persona;
- faltan permisos, historial o owner de cada cambio;
- los casos excepcionales se resuelven con columnas y colores sin definición común;
- el equipo no puede saber qué trabajo está pendiente o terminado;
- una ausencia obliga a reconstruir el criterio de quien gestiona el archivo.
Estas señales no obligan a comprar un ERP ni a desarrollar software. Indican que hace falta gobernar el proceso y comparar una solución proporcional.
Inventaría el proceso, no solo los archivos
Empieza con una unidad real de trabajo: un pedido, una oportunidad, una incidencia, una reserva o una aprobación. Recorre un caso desde que entra hasta que termina.
Para cada paso registra:
| Campo | Pregunta |
|---|---|
| Entrada | ¿Qué evento inicia el paso y de dónde llega? |
| Dato | ¿Qué información se consulta, crea o modifica? |
| Regla | ¿Qué condición decide la siguiente acción? |
| Owner | ¿Quién ejecuta o responde del resultado? |
| Excepción | ¿Qué caso no sigue el camino normal? |
| Evidencia | ¿Cómo se sabe que el paso terminó correctamente? |
| Destino | ¿Qué persona o sistema necesita la salida? |
Después enlaza cada hoja, correo, formulario o sistema con esos pasos. Puede que un archivo contenga varias funciones diferentes o que una misma función esté repartida entre varias fuentes.
Separa dato, regla, excepción y parche
Una celda no explica por sí sola qué representa. Clasifica el contenido antes de migrarlo.
Dato
Describe una entidad o un hecho: cliente, producto, fecha, estado, importe, responsable. Necesita definición, formato, fuente y condición de validez.
Regla
Decide qué hacer: quién recibe un caso, cuándo se considera completo, cómo se calcula una categoría o qué condición exige revisión. Una fórmula puede contener una regla válida, pero también una aproximación antigua que nadie revisó.
Excepción
Representa un caso que no encaja en la regla normal. No debe desaparecer dentro de una columna libre. Necesita motivo, salida, responsable y estado final.
Parche o workaround
Es una solución creada para compensar una limitación de la herramienta o del proceso. Puede haber sido útil sin merecer convertirse en función permanente del sistema nuevo.
Marca cada elemento como conservar, corregir, documentar, archivar o no migrar. No uses “está en el Excel” como único criterio de alcance.
Decide cuál es la fuente de verdad
Cuando el mismo dato vive en varias hojas o herramientas, el sistema nuevo necesita saber qué fuente gobierna cada campo y qué ocurre ante un conflicto.
Para cada dato relevante define:
- nombre y significado;
- fuente actual y owner;
- formato y valores válidos;
- identificador de la entidad;
- regla de actualización;
- duplicados conocidos;
- historial necesario;
- fuente objetivo después de la transición.
Si no existe un identificador común, la migración puede crear dos registros para la misma entidad o unir registros distintos. La limpieza no es solo borrar filas vacías: exige decisiones de negocio sobre identidad y autoridad.
La guía de Microsoft para migración en Dynamics incluye descubrimiento de fuentes, alcance, mapeo, transformación, pruebas, validación y asignación de responsabilidades (Microsoft Learn, observada el 29/08/2026). Es un ejemplo de disciplina de migración; no implica que Dynamics sea la solución adecuada.
No todo el historial debe vivir en el sistema nuevo
Conservar acceso a un dato no exige siempre cargarlo en la base operativa nueva. Pregunta:
- ¿se necesita para ejecutar el proceso actual?
- ¿debe editarse o solo consultarse?
- ¿tiene calidad suficiente para influir en decisiones?
- ¿existe una obligación o razón operativa para conservarlo?
- ¿puede archivarse de forma segura y recuperable?
- ¿qué coste y riesgo introduce transformarlo?
La documentación de Dynamics para aplicaciones de relación con clientes plantea expresamente que valor, calidad, volumen, tiempo y coste pueden justificar no migrar ciertos datos y mantener otra forma de consulta (Microsoft Learn, observada el 29/08/2026). La decisión concreta requiere contexto, privacidad y requisitos de la empresa.
Diseña el proceso objetivo antes de elegir tecnología
El target mínimo debe describir comportamiento, no producto:
- entrada válida;
- entidad e identificador;
- estados necesarios;
- reglas y permisos;
- excepciones y revisión;
- salidas e integraciones;
- evidencia y trazabilidad;
- owner y mantenimiento.
Después decide qué parte puede resolverse configurando una herramienta, qué necesita integración y qué justifica desarrollo. La guía sobre software a medida frente a SaaS y no-code conserva el marco Configurar → Integrar → Desarrollar.
No conviertas una preferencia de interfaz en requisito si no cambia el trabajo. Tampoco fuerces el proceso a una herramienta solo porque puede importar el archivo.
Prepara una migración que pueda comprobarse
Una transición verificable contiene:
- muestra representativa con casos normales y excepciones;
- mapeo de campos y transformaciones;
- reglas para duplicados, valores inválidos y ausentes;
- orden de carga cuando existen dependencias;
- criterios de aceptación del resultado;
- registro de errores y decisiones;
- responsable de validar cada tipo de dato;
- plan de corte, convivencia o vuelta atrás.
No uses solo el recuento total de filas. Dos conjuntos pueden tener el mismo tamaño y relaciones rotas, estados incorrectos o duplicados diferentes.
Prueba el proceso completo con datos controlados: entrada, decisión, salida, permisos, excepciones e integración. Después compara resultados del sistema anterior y del nuevo según criterios definidos. Si aparece una diferencia, clasifícala como corrección esperada, error de migración o cambio de regla.
Evita la doble operación indefinida
Durante una transición puede ser razonable mantener temporalmente la hoja y el sistema, pero debes definir:
- qué fuente puede editarse;
- qué datos se sincronizan o se congelan;
- cómo se comparan diferencias;
- quién resuelve conflictos;
- qué condición termina la convivencia;
- qué se archiva y qué se elimina conforme a la política aplicable.
Si ambas fuentes siguen editándose sin regla, el equipo vuelve a crear dos verdades. La coexistencia es una fase de prueba o transición, no un estado final por comodidad.
GOV.UK recomienda inventariar activos de datos, conocer dependencias y considerar ownership, procesos y cultura al gestionar tecnología heredada (GOV.UK, observada el 29/08/2026). Su contexto es la administración pública británica; aquí se usa como marco de preguntas, no como norma para empresas españolas.
La adopción forma parte del sistema
Un proceso nuevo falla operativamente si el equipo mantiene la hoja como vía real y usa el sistema solo para copiar datos al final. Antes del corte define:
- quién realiza cada paso;
- qué formación necesita por tarea;
- qué excepción todavía requiere vía manual;
- dónde se solicita ayuda;
- qué feedback puede cambiar el diseño;
- qué evidencia demuestra que la fuente anterior dejó de gobernar.
La implantación de CRM para empresas desarrolla proceso, datos, integración y adopción cuando el destino es un CRM. C05 se mantiene neutral respecto al tipo de sistema.
Ejemplo ilustrativo: solicitudes gestionadas en una hoja
Imagina una hoja donde entran solicitudes desde correo. Una persona copia datos, asigna responsable con colores y escribe comentarios libres.
| Elemento actual | Decisión antes de migrar |
|---|---|
| una fila por correo | definir si cada correo es solicitud nueva o seguimiento |
| color del fondo | convertir su significado en estado o prioridad documentada |
| nombre escrito a mano | identificar owner mediante un valor estable |
| comentario libre | separar siguiente acción, motivo y contexto necesario |
| fórmula de prioridad | revisar si la regla sigue vigente y qué excepción admite |
| hojas mensuales | decidir qué historial necesita consulta y qué puede archivarse |
El objetivo no es recrear colores en otra pantalla. Es que el nuevo sistema pueda explicar estado, owner, regla, siguiente acción y excepción.
Checklist antes de pasar de Excel a un sistema
- La unidad de trabajo está definida de principio a fin.
- Cada archivo y herramienta está asociado a un paso del proceso.
- Datos, reglas, excepciones y parches están separados.
- Cada dato relevante tiene definición, fuente y owner.
- Se ha decidido qué conservar, corregir, archivar o no migrar.
- El proceso objetivo está descrito sin depender de una herramienta.
- La elección Configurar → Integrar → Desarrollar se hace después.
- La muestra de prueba contiene casos normales y excepciones.
- La validación compara relaciones y resultados, no solo filas.
- La convivencia tiene fuente editable y condición de salida.
- El equipo sabe cuándo la hoja deja de gobernar.
El presupuesto debe llegar después de cerrar este alcance mínimo. La guía para preparar un presupuesto de software a medida explica qué partidas y preguntas comparar sin convertir una cifra genérica en tarifa.