Un dashboard navegable en la semana dos: qué tiene que pasar para que sea verdad

Un dashboard navegable con datos reales en la semana dos de un proyecto de BI es una promesa que asusta un poco escrita. Y está bien que asuste, porque obliga a trabajar de una forma concreta desde el primer día. KubiqX la tiene en su web, en la descripción de Core, y no es un eslogan: es una consecuencia de cómo se ordena el trabajo.

No va de ser rápidos. Va de que corregir el rumbo en la semana dos cuesta una conversación y corregirlo en la semana ocho cuesta el proyecto. Estas son las condiciones para que se cumpla, y lo que pasa cuando no se cumplen.

Las cinco condiciones de la primera semana

• Acceso a las fuentes antes del viernes. No un "ya lo pasamos": credenciales, exportación o conector funcionando. Sin dato real no hay dashboard real, hay una maqueta, y las maquetas engañan.
• Una persona de negocio que responde en 24 horas. No un comité. Alguien que sepa qué es "venta" en esa empresa, si va con o sin IVA y desde qué fecha vale el histórico.
• Cinco indicadores acordados, no cincuenta. Los cinco que el gerente mira el lunes por la mañana. El resto vendrá, pero la primera versión se construye sobre esos.
• Excel como punto de partida, sin vergüenza. Casi siempre el histórico vive en hojas de cálculo. Se toma como fuente inicial y se construye encima. Migrar después es más fácil que empezar sin nada.
• Una primera versión fea e incompleta, a propósito. Sirve para señalar con el dedo y decir "esto no es así". Cada corrección en ese momento vale oro.

Los cuatro sitios donde se rompe

• El ERP no exporta. O exporta, pero solo puede hacerlo el proveedor, y el proveedor tarda tres semanas. Cuando pasa, hay que decirlo en la primera reunión y ajustar el plazo antes de empezar, no en la semana cuatro.
• Nadie es dueño de los números. Si "margen" tiene tres definiciones y nadie puede elegir una, el dashboard no puede elegir por ellos. Se para hasta que alguien decide.
• Querer la versión definitiva en la semana dos. No existe. La definitiva es la de la semana ocho, y es buena precisamente porque hubo una de la semana dos que estaba mal.
• Cambiar los cinco indicadores cada semana. Iterar es cambiar cómo se ve algo. Cambiar qué se mide cada semana es empezar de cero cada semana.

Por qué merece la pena insistir

Porque un proyecto de BI que se entrega entero al final del trimestre es una apuesta a ciegas: durante ocho semanas nadie ve nada y en la entrega se descubre que la mitad de las cifras no se entienden. Es mejor enseñar algo imperfecto pronto y arreglarlo delante de quien lo va a usar.

Lo que enseñan los retrasos

De los proyectos de BI que se alargan, casi ninguno se alarga por técnica. Se alargan por accesos que no llegan y por definiciones que nadie quiere cerrar. La semana dos no es una meta de velocidad: es la fecha en la que esos dos problemas salen a la luz, cuando todavía son baratos.