Por qué el Excel nunca fue el problema real en la gestión de catálogos — aunque sí era el síntoma más visible

El Excel es la herramienta más culpada en los proyectos de transformación de datos de producto. Esa culpa está mal asignada. El Excel no es el origen del problema de gestión de catálogos: es la evidencia más visible de un problema más profundo que ningún cambio de herramienta resuelve por sí solo. Y en una arquitectura madura, tampoco desaparece: madura junto con ella.

¿Por qué el Excel no es el problema real en la gestión de datos de producto?

El Excel no es el problema real porque es una herramienta, y las herramientas no generan problemas organizacionales por sí solas. El Excel aparece en los catálogos de producto porque cubre un vacío que ningún otro sistema de la empresa estaba resolviendo.

Cuando una empresa gestiona su catálogo en Excel, está tomando una decisión práctica y racional: usar el instrumento más flexible disponible para un problema que nadie diseñó cómo resolver formalmente. El Excel no invade los procesos de gestión de producto. Es convocado por ellos.

El problema real es la ausencia de un modelo de datos de producto definido, de procesos de gobernanza establecidos y de un sistema diseñado específicamente para gestionar información comercial a escala. El Excel llena ese vacío con notable eficiencia hasta que la escala del catálogo supera su capacidad estructural. En ese punto, el Excel no se convierte en el problema: se convierte en el espejo donde el problema real se hace visible por primera vez.

¿Cuándo el Excel es una solución válida en la gestión de datos de producto?

El Excel es una solución válida —y en varios escenarios, la solución correcta— en cuatro contextos concretos dentro de cualquier operación de catálogo, incluyendo las que ya tienen un PIM implementado:

Catálogos de menos de 500 SKUs con estructura de atributos estable. A esta escala, el esfuerzo de mantener un sistema dedicado supera el beneficio. El Excel permite gestionar la información con control directo y sin dependencia de infraestructura tecnológica compleja.

Etapas iniciales de diseño del modelo de datos. Antes de implementar cualquier sistema PIM, el Excel es el entorno natural para prototipar la taxonomía de categorías, definir los atributos por familia de producto y validar la estructura con los equipos involucrados. Es el mejor lugar para cometer errores baratos antes de que esos errores se vuelvan costosos en producción.

Plantillas de carga estructurada hacia el PIM. Este es uno de los usos más vigentes y frecuentes del Excel en empresas que ya tienen un PIM operativo. Las plantillas de importación masiva —hojas con columnas predefinidas, valores controlados y reglas de validación— son el mecanismo estándar para ingresar datos al PIM en volumen: altas de productos nuevos, actualizaciones masivas de atributos, migraciones parciales de categorías. El Excel no desaparece con el PIM: se convierte en la interfaz de entrada de datos más usada por equipos internos y proveedores externos.

Intercambio de datos con proveedores y terceros. En ecosistemas donde los proveedores no pueden conectarse a una API ni a un portal de onboarding dedicado, el Excel es el estándar de facto para la recepción de información de producto. Su universalidad es, en ese contexto, una ventaja real que ningún sistema más sofisticado puede replicar a ese costo de adopción.

En estos cuatro contextos, reemplazar el Excel por un sistema más complejo no resuelve ningún problema real. Agrega fricción donde no se necesita.

¿Cuándo el Excel se convierte en deuda técnica?

El Excel se convierte en deuda técnica cuando la organización sigue usándolo más allá del umbral en que su estructura puede sostener la operación. Ese umbral tiene señales específicas:

El archivo tiene más de una versión circulando simultáneamente. Cuando existen múltiples copias del mismo catálogo —en correos, carpetas compartidas, computadoras locales— con modificaciones no sincronizadas, el Excel dejó de ser una herramienta de gestión y se convirtió en un generador de inconsistencias.

Nadie sabe con certeza cuál es la versión oficial. La pregunta “¿cuál es el Excel correcto?” en una reunión de equipo es la señal más clara de que el sistema de gestión de datos ya colapsó, independientemente de qué herramienta se esté usando.

El proceso de actualización depende de una persona específica. Cuando solo una persona sabe cómo funciona la estructura del archivo, cómo están organizadas las pestañas y qué fórmulas no deben tocarse, la organización tiene un riesgo operativo concentrado en un punto de falla único.

La publicación multicanal requiere copiar y pegar manualmente. Cuando actualizar la información de un producto en tres canales implica abrir tres archivos distintos y modificarlos de forma independiente, el costo operativo de mantener la consistencia ya supera lo que cualquier sistema dedicado costaría.

Las búsquedas y los filtros ya no funcionan con la velocidad necesaria. Un catálogo de 10.000 SKUs con 40 columnas de atributos en Excel no es un problema de diseño del archivo. Es un problema de herramienta equivocada para la escala del problema.

La deuda técnica generada por el Excel en estas condiciones no es el archivo en sí mismo. Es el tiempo acumulado de trabajo manual, los errores no detectados, los procesos no documentados y las decisiones implícitas en su estructura que nadie puede explicar porque quien las tomó ya no está en la empresa.

¿Qué revela el Excel sobre el problema de fondo?

El Excel como herramienta de gestión de catálogos es un diagnóstico en sí mismo. Su presencia como sistema principal en la operación de una empresa con catálogos medianos o grandes no indica que el equipo tomó una mala decisión. Indica que la organización nunca tomó una decisión formal sobre cómo gestionar sus datos de producto.

Cuando auditamos el estado de los datos de producto en una empresa y encontramos el catálogo gestionado exclusivamente en Excel, lo que en realidad estamos viendo es:

Ausencia de modelo de datos documentado. La estructura de columnas del Excel es, de facto, el modelo de datos de la empresa. Nadie lo diseñó formalmente. Se fue construyendo por acumulación de necesidades inmediatas. Cada columna nueva que alguien agregó en algún momento es una decisión de arquitectura no documentada que se hereda sin cuestionamiento.

Ausencia de gobernanza. Si cualquier persona con acceso al archivo puede modificar cualquier celda sin trazabilidad ni validación, la empresa no tiene gobernanza de datos de producto. Tiene un documento compartido que se deteriora a medida que más personas lo usan.

Ausencia de estándares de calidad. Un Excel no puede impedir que alguien escriba “Rojo” en una celda donde todos los demás valores dicen “rojo” o “ROJO”. No puede forzar que un campo numérico contenga solo números. No puede alertar cuando una ficha está incompleta según el estándar mínimo de publicación. La calidad de los datos depende exclusivamente de la disciplina individual de quien los carga.

Ausencia de integración sistematizada. Los datos del Excel llegan a los canales de venta a través de procesos manuales o semi-manuales: exports, importaciones, copias, adaptaciones. Cada paso manual es un punto de falla potencial y un costo operativo que se repite indefinidamente.

Estas cuatro ausencias —modelo, gobernanza, estándares, integración— son el problema real. El Excel es solo el lugar donde ese problema se hace visible.

¿Por qué reemplazar el Excel sin resolver el problema de fondo no funciona?

El error más costoso que cometen las empresas al decidir implementar un PIM es asumir que la herramienta resolverá los problemas que el Excel evidenció. No los resuelve. Los importa.

Un PIM implementado sin modelo de datos diseñado previamente reproduce la estructura caótica del Excel en un sistema más caro y más complejo. Un PIM implementado sin gobernanza definida es un Excel con mejor interfaz. Un PIM implementado sin estándares de calidad establecidos publica fichas incompletas con más eficiencia, pero las publica igual.

En CRITERIA hemos auditado implementaciones de PIM que llevaban entre uno y tres años en producción y seguían generando los mismos problemas que motivaron la inversión original: inconsistencias entre canales, fichas incompletas, datos duplicados, procesos manuales que sobrevivieron al cambio de sistema. En todos esos casos, el diagnóstico fue el mismo: se reemplazó la herramienta sin resolver la arquitectura.

La herramienta correcta sobre un proceso incorrecto produce resultados incorrectos con mayor velocidad y menor costo de excusa. El Excel al menos tenía la virtud de hacer evidente el problema. Un PIM mal implementado lo oculta detrás de dashboards y conectores.

¿Cuál es el rol correcto del Excel en una arquitectura de datos de producto madura?

Una arquitectura de datos de producto bien diseñada no elimina el Excel. Lo reubica en las funciones para las que fue diseñado, y lo libera de las funciones que lo estaban deformando.

Como plantilla de carga e importación masiva al PIM. Este es, probablemente, el uso más intensivo del Excel en equipos que ya operan con un PIM. Cada familia de productos tiene su plantilla: columnas predefinidas, listas de valores controlados, campos obligatorios marcados, reglas de formato documentadas. El equipo interno las usa para altas masivas. Los proveedores las usan para entregar datos en el formato que el PIM puede procesar directamente. El Excel no compite con el PIM en este rol: es su canal de entrada más accesible y universal.

Como herramienta de diseño y prototipado del modelo de datos. El Excel es el mejor entorno para diseñar el modelo de atributos antes de implementarlo en el PIM, para testear la taxonomía de categorías con los equipos de negocio y para documentar las reglas de transformación entre sistemas. Las decisiones que se toman en esta etapa determinan la calidad de la arquitectura del PIM; hacerlas en Excel primero reduce el costo de los errores de diseño.

Como herramienta de análisis y revisión de calidad. Los exports del PIM hacia Excel para revisar completitud de fichas, auditar consistencia de atributos o tomar decisiones puntuales sobre el catálogo son un uso completamente legítimo y frecuente. El Excel sigue siendo insuperable para manipular datos tabulares en contextos de análisis no repetitivos o revisiones editoriales antes de una publicación masiva.

Como formato de intercambio con el ecosistema externo. Proveedores, agencias de contenido, fotógrafos, traductores, importadores: todos los actores externos que participan del ciclo de vida del dato de producto operan con Excel o Google Sheets como denominador común. Una arquitectura madura diseña plantillas estandarizadas para cada tipo de intercambio externo y las convierte en el punto de entrada oficial al PIM.

Lo que el Excel no debe hacer en una arquitectura madura es ser el sistema de registro maestro, el sistema de publicación, el sistema de aprobación o el sistema de integración entre canales. Esas funciones pertenecen a sistemas diseñados para ellas. Pero el Excel como interfaz operativa del PIM —como plantilla, como herramienta de revisión, como formato de intercambio— no solo es aceptable: es inevitable y deseable.

Diagnóstico: 5 preguntas para saber si su empresa tiene un problema de Excel o un problema de arquitectura

Pregunta 1. Si mañana eliminara todos los archivos Excel de gestión de catálogo de su empresa y pidiera al equipo que continuara operando, ¿podrían hacerlo con los sistemas existentes? Si la respuesta es no, el Excel no es el problema: es la infraestructura real de gestión de datos de producto de la empresa.

Pregunta 2. ¿El modelo de atributos de sus productos existe documentado en algún lugar fuera del Excel? Si la respuesta es no, el Excel no solo almacena datos: almacena el conocimiento organizacional sobre la estructura de su catálogo.

Pregunta 3. ¿Puede saber cuántas versiones distintas de su catálogo existen en este momento en los sistemas y dispositivos de su empresa? Si no puede saberlo, la fragmentación ya es sistémica.

Pregunta 4. ¿Tiene su empresa un proceso formal y documentado para incorporar un producto nuevo al catálogo desde su alta en el ERP hasta su publicación en todos los canales? Si ese proceso existe solo en la cabeza de una o dos personas, es un proceso en riesgo, no un proceso gestionado.

Pregunta 5. ¿Cuánto tiempo dedicó su equipo la semana pasada a tareas que podrían describirse como “pasar datos de un lugar a otro”? Si la respuesta supera el 20% de la capacidad del equipo, el costo operativo del problema ya es medible y justifica la inversión en resolverlo.

Conclusión: el Excel es el síntoma más honesto que una empresa puede tener — y un aliado cuando está en su lugar

El Excel tiene una virtud que los sistemas más sofisticados no tienen: es transparente sobre su propio caos. Cuando el catálogo vive exclusivamente en Excel y hay problemas, los problemas son visibles. Las celdas vacías son visibles. Las inconsistencias son visibles. La falta de estructura es visible.

Esa visibilidad es, paradójicamente, lo más valioso que el Excel aporta en el momento del diagnóstico. Cuando una empresa llega a CRITERIA con su catálogo en Excel y una lista de problemas, ya hizo el trabajo más difícil: reconocer que el modelo actual no escala.

Pero reconocer ese límite no significa despedirse del Excel. Significa redefinir su rol. En empresas con PIM implementado, el Excel sigue siendo una presencia cotidiana y funcional: como plantilla de carga masiva, como formato de intercambio con proveedores, como herramienta de revisión editorial, como entorno de prototipado del modelo de datos. No desaparece — madura junto con la arquitectura.

La pregunta correcta no es “¿cómo reemplazamos el Excel?”. La pregunta correcta es “¿qué funciones le estamos pidiendo al Excel que ningún Excel puede sostener a esta escala, y qué sistema está diseñado para asumir esas funciones?”.

Responder esa pregunta antes de evaluar cualquier plataforma es la diferencia entre una implementación que resuelve el problema real y una implementación que lo hereda con mejor tecnología — y con el Excel todavía ahí, haciendo el trabajo que el nuevo sistema no supo asumir.

Este artículo es parte del newsletter semanal Datos de que Venden. Suscribite para recibir cada entrega directamente en LinkedIn.