Tradicionalmente, este enfoque se ha aplicado más a proyectos en los que el componente de 'desarrollo' tiene un peso muy importante y se hace muy difícil aplicarlo al BI/DW, donde los requisitos, el manejo de datos de negocio y la participación de perfiles de interlocutores muy diversos lo hace muy difícil.
A. El enfoque tradicional de planificación en BI/DW
- La planificación de proyectos en cascada (con diagramas de Gantt ) que todos conocéis (lleva usándose más de 70 años) se ha demostrado imperfecto a la hora de conseguir que un proyecto BI sea exitoso. Que quiere decir 'un proyecto BI exitoso'? quiere decir 'que se use' por la mayor parte de la organización y es porque les ofrece 'lo que necesitan'
- Los diferentes planteamientos teóricos de construcción ( Kimball , Inmon , Data Vault ) se han demostrado muy útiles para reflejar el diagrama de modelos y almacenes de datos, pero la ejecución en el día a día, nos ha demostrado que se requieren enfoques ágiles para llevarlos a la práctica
- Los problemas surgen pues 'Cómo se había hecho una planificación', 'con muchos meses por delante' , cuando surge un problema de arquitectura, de volumen, cambio de requerimientos, mejoras de software... el encaje y respuesta rápida se hace imposible
- Al ser proyectos con un alcance ya cerrado y difícil de cambiar, 'proyectos caja negra' , los usuarios e interesados en el proyecto no lo sienten como suyo, generando reticencias sobre su uso, al no sentirse partícipes, pues sus propuestas y sugerencias, 'suelen llegar tarde'
B. Los 20 puntos clave para un proyecto Agile BI/DW
1. Haz prototipos (antes, durante y después). No dejes de hacerlos, son la mejor herramienta para garantizar que se va en el buen camino
2. Ten un entorno preparado para los prototipos rápidos (entorno en la nube, componentes predefinidos, procesos automatizados...)
3. Usa metodologías ágiles . Hay muchas ... (scrum...), lo más importante es el cambio de mentalidad y empezar a usarlas
4. La regla de oro: mejor rehacer un 30% ahora que un 100% dentro de 6 meses. No tengas miedo a que te hagan cambios en los prototipos . Siempre será mejor que ir a ciegas
5. Todo el equipo se siente implicado desde el momento inicial. Y sienten que sus opiniones cuentan
6. La tradicional batalla entre usuarios-IT-Consultores, por sus diferentes prioridades, se minimiza al colaborar desde momentos muy tempranos y con la tranquilidad de que 'hay tiempo para corregir errores'
7. En este tipo de proyectos, encontrar un 'product owner' es complicado, pero lo tenéis que hacer. Debe ser de negocio
8. Solventa cuanto antes los puntos de fricción 'top-down', 'down-top' , desde la importancia de la calidad del datos, los procesos ETL y los metadatos a los análisis de negocio en tiempo real, KPIs, etc... (en el punto intermedio, todos los participantes deberán alinearse)
9. Haz los planes de pruebas no al final, sino al día siguiente de empezar
10. Necesitas un Project Manager (el que está al tanto de todo, conoce a todos, convoca y resume las reuniones, etc...) Necesitas una cabeza visible y clara que todos 'identifiquen con el proyecto'
11. Mide y cuenta los avances , genera satisfacción con lo conseguido
12.
Reuniones breves
al principio de cada día y más amplias cada semana
13. Nunca pongas la presentación de un hito, avance, etc.. un lunes por la mañana (es de malos gestores, contar con el fin de semana de colchón) y genera ansiedades
14. Usa el BI (cubos, dashboards..) de forma ágil para validar rápidamente la calidad de los datos, tiempos de ejecución, etc... BI por partida doble
15. Deja que los usuarios se acerquen al BI . Desde las fases iniciales pierde el miedo a que accedan, toquen, rompan, se frustren, se sorprendan, se quejen de lo que van viendo...
16. No dejes el diseño y usabilidad para el final . Aunque pienses que es secundario y posterior, deber ir paralelo al desarrollo. Si no lo haces, la implicación de usuarios decaerá enormemente
17. Con AgileBI vas a tener que seguir documentando (de otra forma, con herramientas online (trello, podio, etc...), pero lo harás
18. Con AgileBI se necesita más disciplina, no menos . Esto es muy importante. Se asocia a cierto caos y es todo lo contrario. Se trata de trabajar como los mecánicos que cambian las ruedas en Formula 1
19. Tienes que tener a la gente motivada en el proyecto (esto se consigue con todo lo anterior), pero si haces todo lo anterior y no están motivados, 'el problema eres tú'
20. Un proyecto BI/DW nunca, nunca, nunca se acaba . Si lo das por acabado, también será un fracaso
Adenda: Si usas BI Open Source (por su flexibilidad, ahorro de costes e integración), tienes 'muchos' más puntos para conseguir tu objetivo
Te puede interesar:
- Big Data para Dummies
- Comparativa de herramientas Business Intelligence
- Descarga gratuita del Libro de un buen amigo y gran especialista, Roberto Canales: ' Transformacion Digital y Metodologías Agiles '
- Así se convierten los datos en conocimiento
- Como aprender Big Data en dos horas
