Por qué fracasan los proyectos de datos y cómo evitarlo

Los proyectos de datos pueden comenzar con grandes expectativas y terminar con cuadros de mando poco utilizados, retrasos, sobrecostes o resultados que no responden a las necesidades reales. ¿La razón? Se ha puesto en marcha una solución tecnológica sin resolver antes las condiciones que permiten utilizarla con confianza.  

Pero la causa del fracaso de proyectos de datos rara vez está en una única decisión. Normalmente existe una combinación de factores relacionados con el enfoque, los datos, la organización, los usuarios y la gestión del cambio:  

• Hay iniciativas que se bloquean durante la integración de los sistemas. 
• Otras entran en producción y apenas se utilizan.  
• También pueden existir proyectos con muchos usuarios que no consiguen reducir errores, agilizar decisiones ni mejorar los procesos previstos. 

Para evaluar qué está fallando, conviene separar las causas, pues la tecnología, la calidad de la información, las responsabilidades y los hábitos de trabajo requieren medidas distintas.  

A continuación, planteamos nueve situaciones que ayudan a identificar dónde intervenir y cómo orientar una implantación de Business Intelligence o inteligencia de negocio. 

1. Elegir la herramienta antes de definir la decisión

Elegir una plataforma antes de definir qué decisiones se quieren mejorar es uno de los errores más habituales a la hora de implantar una herramienta de análisis de datos para empresas. Por eso, la primera conversación debería concretar qué se quiere cambiar: pasar del «necesitamos analizar las ventas» al «necesitamos identificar qué clientes pierden margen para revisar sus condiciones antes de renovar el contrato».  

Esto delimita un uso, un responsable y un momento de actuación. En definitiva, la solución pasa por invertir el orden: 

1. Definir objetivos. 

2. Identificar decisiones. 

3. Seleccionar indicadores. 

4. Localizar datos. 

5. Diseñar la solución. 

6. Elegir la tecnología más adecuada. 

La elección tecnológica llega con esos requisitos sobre la mesa.  

Por supuesto, también exige pruebas: tiempos de respuesta con datos representativos, compatibilidad con los sistemas de origen, permisos y coste de mantenimiento. Los fallos técnicos existen y deben evaluarse con el mismo rigor que los organizativos. 

2. Intentar abarcar toda la empresa en la primera entrega

Los programas excesivamente ambiciosos pueden tardar demasiado en mostrar resultados, así que es preferible construir una hoja de ruta global y ejecutarla mediante casos de uso concretos, siguendo unas fases que vayan aportando resultados visibles y reutilizables. 

Unificar ventas, compras, finanzas, producción y logística puede ser un objetivo razonable a medio plazo pero convertirlo en condición para la primera entrega multiplica las dependencias, ya que cada área añade reglas, excepciones y necesidades de validación. 

La alternativa consiste en definir una estrategia de datos común y ejecutar casos de uso acotados: quién necesita la información, para qué tarea y con qué resultado esperado. La priorización debe considerar utilidad, disponibilidad de datos, esfuerzo y dependencias. 

Además, ese primer alcance ha de conservar elementos reutilizables: identificadores de producto, calendario y reglas de cálculo. Si cada fase crea sus propias definiciones, la empresa acumulará soluciones aisladas y encarecerá la integración posterior. 

Trabajar por etapas tampoco justifica ignorar la arquitectura, es decir, cómo se organizan los componentes técnicos y sus conexiones. De ahí que la primera entrega necesite un diseño compatible con el crecimiento previsto, sin cargar desde el inicio con todas las funciones futuras. 

Después, cada ampliación tiene que depender de evidencias sobre calidad, uso y capacidad de mantenimiento. 

3. Dar por válida la calidad de los datos de origen

Las herramientas de análisis no eliminan automáticamente: 

• Registros duplicados. 
• Códigos inconsistentes. 
• Campos incompletos. 
• Errores de clasificación.
• Definiciones diferentes. 
• Procesos de origen mal ejecutados. 

La calidad del dato debe medirse, corregirse y gobernarse. La solución puede exigir cambios en la captura del mismo, validaciones o responsables de mantenimiento.  

Con esto, el cuadro de mando ha de informar de la última actualización y de las limitaciones que puedan afectar a su lectura. 

Si quieres profundizar en cómo identificar, evaluar y mejorar la calidad de los datos en tu organización, puedes ver nuestro webinar Calidad del dato, donde abordamos las claves para convertir la información en un activo fiable y útil para la toma de decisiones. 

4. Diseñar sin observar cómo trabajan los usuarios

El fracaso de proyectos de datos puede pasar también porque el cuadro de mando que se ha implantado es técnicamente correcto pero resultar inútil para la persona que debe utilizarlo. 

Un responsable comercial puede necesitar detectar oportunidades sin actividad, mientras un director financiero quiere buscar desviaciones respecto al presupuesto. Mostrarles la misma pantalla a los dos, con las mismas opciones y el mismo nivel de detalle, les obliga a realizar trabajo adicional. 

Así que la participación de los usuarios de la herramienta debe comenzar antes de aprobar su diseño. Conviene observar qué información utilizan, qué comprobaciones repiten y qué decisión toman después. Lo mejor es pedirles que expliquen una tarea concreta para conocer sus requisitos de análisis. A partir de ahí, las pruebas deben reproducir esas labores.  

Los usuarios de negocio tienen que participar en: 

• Definición de preguntas. 
• Selección de indicadores. 
• Validación de cálculos. 
• Diseño de navegación. 
• Pruebas. 
• Formación. 
• Evolución. 

También deben hacerlo perfiles con diferentes niveles de experiencia, pues validar solo con la persona más experta puede ocultar dificultades de interpretación para el resto. La accesibilidad requiere de revisar contraste, tamaño del texto y alternativas a los códigos de color. 

Al terminar cada prueba, además, hay que registrar el problema y la corrección acordada.  

La participación aumenta la utilidad y la adopción. 

5. Acumular indicadores sin establecer prioridades 

Un cuadro de mando efectivo prioriza, jerarquiza y facilita detectar lo importante, y su diseño pierde claridad cuando mezcla objetivos, periodos y niveles de detalle sin explicar la relación entre ellos. 

La solución empieza por ordenar las preguntas. Una pantalla sobre ventas puede mostrar la evolución respecto al objetivo, localizar las desviaciones y permitir después examinar clientes o productos. Y cada nivel responde a una necesidad distinta, evitando presentar todos los detalles a la vez. 

Además, los indicadores seleccionados para el dashboard  también necesitan contexto, pues una subida de facturación puede coincidir con un descenso del margen y un aumento de existencias puede responder a una compra planificada. La comparación debe utilizar periodos equivalentes y recoger circunstancias que alteren la lectura. 

Después, el equipo tiene que revisar qué decisión respalda cada elemento, porque si nadie puede explicar para qué sirve un gráfico, conviene retirarlo o trasladarlo a una vista secundaria.  

Las alertas merecen el mismo criterio. Cada aviso ha de tener destinatario, condición de activación y actuación prevista. Sin esas reglas, la organización recibe notificaciones que compiten entre sí y termina ignorándolas, así que el umbral debe ajustarse a la actividad y revisarse cuando produzca avisos poco útiles. 

6. Dejar las definiciones y las responsabilidades sin resolver 

Otro error común que puede llevar al fracaso de proyectos de datos es olvidarse de que los indicadores necesitan propietarios. Alguien debe responsabilizarse de: 

• Su definición. 
• La fuente. 
• La calidad. 
• La interpretación. 
• Las acciones asociadas. 
• Su actualización. 

Sin gobierno del dato, las métricas pueden proliferar y perder coherencia. Su aplicación ha de ser proporcionada al tamaño de la empresa y puede comenzar con un registro compartido de indicadores y responsables, sin crear una estructura difícil de sostener. 

Cada medida debería documentar nombre, fórmula, fuente, frecuencia de actualización, exclusiones y propietario. Esa persona es quien valida el significado empresarial, mientras el equipo técnico implementa la regla, mantiene las conexiones y atiende incidencias dentro de sus responsabilidades. 

El control incluye los accesos: quién puede consultar costes, márgenes o información de clientes y qué sucede al exportar datos. Y los permisos deben probarse con perfiles reales antes de publicar. 

También conviene conservar la trazabilidad: la posibilidad de seguir el origen de una cifra y las transformaciones que ha recibido. 

7. Limitar la formación al día del lanzamiento 

Como comentábamos más arriba, si no se implica a los usuarios en el proyecto de datos, será difícil que este se aplique con éxito. Para ello, también es necesaria la formación y no vale con una sesión inicial, que puede enseñar dónde están los filtros y cómo navegar pero que las personas sepan interpretar los resultados y utilizarlos en sus tareas diarias.  

Eso sí, debe ajustarse a cada función, porque una persona que consulta resultados necesita entender indicadores y límites, mientras quien construye análisis necesita conocimientos sobre relaciones entre datos, cálculos y validación.  

Una medida aplicable puede ser reservar sesiones de seguimiento durante los primeros ciclos de uso, para revisar dudas surgidas en reuniones, errores de interpretación y tareas que siguen exigiendo operaciones manuales. Las respuestas pueden incorporarse a una guía breve que permanezca accesible. 

8. Medir accesos sin comprobar resultados 

Más que por el número de usuarios activos, un proyecto de datos ha de estar relacionado con resultados, como pueden ser: 

• Reducción del tiempo de reporting. 
• Disminución de errores. 
• Mayor rapidez de cierre. 
• Mejora del margen. 
• Reducción de inventario. 
• Detección temprana de impagos. 
• Incremento de la conversión comercial. 
• Mayor uso de la plataforma. 

Conviene medir tres aspectos: funcionamiento, uso y resultados. El primero incluye actualizaciones completadas y disponibilidad; el segundo permite comprobar qué perfiles utilizan los análisis y para qué tareas; y el tercero conecta el proyecto con cambios observables en el trabajo. 

9. Cerrar la implantación sin prever su mantenimiento 

Los datos, procesos y objetivos de una empresa cambian, por lo que el entorno analítico debe revisarse y evolucionar con ellos. Así que la puesta en producción de un proyecto de datos tiene que incluir un plan de operación.  

Es el que define quién supervisa las cargas de datos, cómo se notifican los fallos, qué copias se conservan y cómo se recupera el servicio. También necesita presupuesto y capacidad para corregir incidencias, pues las modificaciones de cálculos requieren pruebas antes de publicarse.  

Por ejemplo, si cambia el criterio de ventas netas, el equipo ha de comprobar qué informes dependen de esa medida y si las comparaciones históricas siguen siendo válidas. Los usuarios necesitan conocer la fecha y el efecto del cambio. 

En definitiva, se recomienda programar revisiones del contenido, ya que un análisis puede quedar obsoleto porque desaparece el proceso al que servía. Mantenerlo sin revisar consume recursos y puede inducir a error. Retirarlo también forma parte del mantenimiento. 

Cómo aumentar la probabilidad de éxito 

Para evitar el fracaso de un proyecto de datos, su planteamiento tiene que combinar: 

• Patrocinio de dirección. 
• Objetivos concretos. 
• Casos de uso priorizados. 
• Participación de negocio. 
• Arquitectura escalable. 
• Gobierno del dato. 
• Formación. 
• Gestión del cambio. 
• Medición de resultados. 
• Evolución continua. 

El partner como elemento clave en la implantación  

Un proyecto de datos exige conectar tres lenguajes: el del negocio, el de la información y el de la tecnología. Y el partner debe comprender las preguntas empresariales para transformarlas en modelos, indicadores y experiencias de análisis. 

El proveedor tiene que entender el proceso que se quiere analizar y explicar cómo lo traduce en datos, reglas y pruebas. A partir de ahí, ha de aportar una propuesta revisable que identifique fuentes, dependencias, responsabilidades, exclusiones y entregables. Por supuesto, también debe dejar claro qué trabajo corresponde al equipo interno. 

Así que antes de contratar un proyecto de datos, se recomienda solicitar una explicación del mantenimiento: documentación disponible, procedimiento de cambios y condiciones de soporte.  

En Mercanza acompañamos a las organizaciones desde la definición inicial hasta la implantación, formación, soporte y evolución. 

Sabemos que el verdadero valor de los datos no está en acumular información ni en disponer de más informes, sino en conseguir que cada dato aporte conocimiento y ayude a tomar mejores decisiones. Por eso, abordamos cada proyecto desde una visión global, en la que el conocimiento del negocio, la calidad de la información y la tecnología trabajan de forma conjunta. Esta perspectiva nos permite ir más allá de la implantación de herramientas: construimos soluciones de análisis que responden a necesidades reales, generan confianza y evolucionan al ritmo de cada organización. 

Así que si tu organización tiene informes que se consultan poco, cifras que no se concilian o tareas manuales que siguen creciendo, el primer paso es delimitar dónde aparece el problema. Contacta con Mercanza para revisar las necesidades de tu proyecto de datos y valorar los siguientes pasos.