Cómo abordar un proyecto de Business Intelligence (parte 1)

En una serie de dos artículos voy a explicar cuál es la mejor manera, en mi opinión, de realizar un proyecto de Business Intelligence desde cero, enumerando las principales etapas de este camino y explicando, en cada una de ellas, de qué tratan y qué resuelven.

Esta primera parte se centra en todo lo que debería suceder antes de ponernos a desarrollar, mientras que el segundo artículo estará dedicado en exclusiva a la parte de desarrollo.

Como todo en la vida, no hay que hacer las cosas porque sí. Antes de mover un dedo, nos hemos de hacer la siguiente pregunta:

¿Necesita mi empresa un sistema de análisis de datos (mejor que el que ya tiene)?

Aunque cada maestrillo tiene su librillo, aquí van una serie de preguntas de manera que, si la respuesta de alguna(s) de ellas es sí, muy probablemente sí necesitemos crear un sistema de BI e nuestra empresa o mejorar el existente:

• ¿Consigo encontrar las respuestas a mis preguntas sobre el estado de la empresa?
• ¿Lo hago de una manera rápida?
• ¿Me resulta sencillo analizar los datos desde distintos puntos de vista?
• ¿Tengo datos suficientemente actualizados del estado de mi empresa?
• ¿El proceso de preparación de los datos es manual?

Aquí vamos a analizar qué departamentos de mi empresa necesitan un buen sistema de analítica de datos. En Mistral pensamos que la mejor manera de abordar un proyecto es trazando un plan global y ambicioso, que incluya todas las necesidades actuales y futuras, pero implementándolo paso a paso.

Al final de este punto deberíamos tener un documento que nos indique, no con gran nivel de detalle, qué áreas de mi empresa van a disponer de cuadros de mando y, aunque sea a grandes rasgos, qué tipo de información vamos a mostrar para cada departamento.

Cuando hay que implantar el sistema de BI en múltiples áreas, como Dirección, Finanzas, Comercial, Compras, Producción, Logística, Calidad, etc., a menudo hay intereses internos encontrados y todo el mundo quiere ser el primero. O, simplemente, no sabemos cómo priorizar el orden de desarrollo.

Hay que seguir una pauta para el desarrollo y, aunque luego se pueda ser flexible para adaptarse a los imprevistos que seguro tendremos, hay que empezar el viaje con un plan.

No hay un criterio válido único para determinar en qué orden ejecutamos el proyecto, pero sí hay distintos criterios que pueden ayudarnos a tomar esa decisión. Por ejemplo, podríamos ordenar la implantación de los cuadros de mando en los distintos departamentos atendiendo a:

• Cuáles tienen más problemas actualmente para analizar datos.
• Cuáles necesitamos, dada su criticidad en la empresa, que tengan antes un buen sistema de análisis.
• Cuáles tienen sus orígenes de datos en mejor disposición de ser analizados, en términos de disponibilidad, calidad o accesibilidad.
• Para qué departamentos tengo hecho un análisis de requerimientos más completo.

O, en caso de empate, una combinación de estos criterios. Al final de esta fase debo tener un plan de ejecución, donde tenga una visión (aunque sea aproximada) sobre qué voy a hacer, en qué orden y unas primeras fechas estimadas de entregas.

Dentro de cada departamento, hay que hacer un análisis interno sobre cuáles son las necesidades de análisis de datos. Tendemos a pensar en términos de “respuestas”, pero la mejor manera de establecer qué necesitamos analizar en un departamento es hacernos “preguntas”.

Es decir, debemos hacer una lista de preguntas cuyas respuestas queremos conocer. ¿Cuáles son las preguntas cuyas respuestas necesito conocer para hacer correctamente mi trabajo?

Una vez tenemos la lista de preguntas, construir un sistema de BI es “tan solo” crear el sistema capaz de dar respuesta a esas preguntas.

Una vez hemos completado las etapas anteriores, estamos en disposición de empezar el desarrollo de código propiamente dicho. Tenemos claro qué queremos a nivel global, en qué orden lo vamos a implementar y los requerimientos para empezar el desarrollo.

Como indiqué al comienzo del artículo, esto lo veremos con más detalle en un próximo artículo que en breve estará disponible.

Hay una serie de tareas que pueden (y deben) realizarse en paralelo a los pasos anteriormente descritos. Algunas pueden no tener relación directa con la semántica del proyecto, pero sin duda son imprescindibles para su éxito. Algunas de ellas son:

• Acceso a las fuentes de datos: Hay que asegurarse que va a ser posible acceder a los datos. Puede parecer obvio, pero quien ha trabajo en proyectos de BI sabe que esto no siempre es así.
• Infraestructura: ¿Disponemos de los recursos necesarios? Si el proyecto implica un DWH, ¿tenemos la máquina para ello? ¿Licencia de base de datos, herramienta ETL, visualización? ¿Tenemos presupuesto para ello?
• Responsables internos: La empresa debe elegir a ciertas personas que se encargarán de trasladar los requerimientos al equipo de desarrollo y luego validar el mismo. Estas personas ya tienen su propio trabajo y esto les va a suponer un esfuerzo extra. Hay que ser conscientes de ello.
• ¿Quién se encarga del mantenimiento evolutivo del sistema? Un sistema de Business Intelligence es un ente vivo, que va a necesitar una atención constante, tanto desde el punto de vista de sistemas, como para el desarrollo de nuevas funcionalidades. Hay que tener esto presente.
• Gestión de expectativas: Es necesario hacer una gestión interna de las expectativas, acerca de plazos, qué podemos esperar y qué no del BI, la importancia de la calidad de los datos en los sistemas operacionales (para que el BI proporcione información correcta), etc.
• Venta interna: A algunas personas les va a suponer un trabajo extra. A muchas les va a suponer un cambio en su manera de trabajar. Si sustituimos una herramienta de visualización de cuadros de mando antigua por una nueva, seguro que habrá reticencias. Es necesario que, desde dentro, se realice un trabajo para concienciar de que el pequeño esfuerzo inicial para adaptarse al cambio va a traer ventajas muy grandes.

Aquí finaliza este artículo. Muchas gracias por dedicar tu tiempo a leerlo, espero que te haya resultado de interés. Próximamente escribiré la segunda parte, cómo afrontar la fase de desarrollo de un proyecto de BI. ¡Hasta pronto!