Metodología para el Diseño e Implantación de un Sistema de BI

¿Cuantos proyectos de BI terminan siendo un éxito para la Organización que los pone en marcha? Sin duda, muchos de los abordados han terminado en un completo fracaso, y ello con independencia muchas veces del tipo de Organización de que se trate, de la Solución seleccionada, etc.

Podríamos pensar que la tecnología no se adapta a los requerimientos de nuestras empresas, pero el nivel tecnológico actual supera normalmente los requerimientos de los gestores; también podríamos pensar que nuestros gestores no están preparados para estas tecnologías, pero no parece que si otras tecnologías son adoptadas sin problemas, la de BI tenga que ser especialmente compleja.

¿No será entonces que los proyectos de BI se plantean metodológicamente de manera incorrecta? Mientras que por todos lados podemos encontrar metodologías para desarrollar aplicaciones, para implantar ERP’s, para abordar cualquier tipo de actuación en el ámbito tecnológico, éstas son escasas o inexistentes en el ámbito de la implantación de sistemas para la toma de decisiones.

Acabamos de introducir un pequeño matiz en la discusión: ya no hablamos de sistemas de BI sino de sistemas para la Toma de Decisiones. Creo conveniente, antes de hablar de metodologías, hacer una reflexión sobre qué entendemos por Tecnología de BI. El mundo BI incluye diferentes tecnologías que dan cobertura a diferentes problemáticas, y que, de manera resumida responden a 5 grandes Ejes Funcionales:

1. Captación de Información: incluye todos los procesos orientados a integrar información dispersa y que puede tener problemas de integridad, calidad de datos, etc., o a capturar información no existente previamente.Dentro de esta parte se incluirían todas las tecnologías relativas a ETL (Extracción, Transformación y Carga), a las tecnologías tendentes a asegurar la integridad y calidad de la información y a los diferentes sistemas de captura de información utilizable por sistemas BI
2. Manejo de la Información: incluye todas las tecnologías relacionadas con Bases de Datos, Modelos Multidimensionales, sistemas de agregación de información, etc.
3. Visualización y Distribución: un caso claro de metonimia que ha dado lugar a que mucha gente identifique la visualización con la tecnología de BI; y nada más lejos de la realidad. Por supuesto que toda la información deberemos visualizarla para poder hacer algo con ella, pero, con ser importante este no es el elemento único de esta tecnología.Dando cobertura a esta funcionalidad están las soluciones de reporting, visualización, broadcasting, etc….
4. Análisis de la Información: es probablemente el grupo funcional que dio origen a la denominación de Business Intelligence…, pero por desgracia es un aspecto en muchos casos irrelevante de los proyectos de BI, siendo sustituida la capacidad de análisis en manos de los gestores, por multitud de “fotos fijas” que presentan información. A pesar de ello, es parte inherente a todo proyecto de BI.
5. Gestión de las decisiones adoptadas: si estamos hablando del proceso de toma de decisiones, una vez adoptada una decisión queda ponerla en marcha y gestionar su ejecución. Esta es por tanto la funcionalidad que cierra el ciclo y que nos permite tener una tecnología capaz de gestionar todo el proceso. Este grupo funcional ha sido el último en incorporarse a la tecnología de BI, pero es el que realmente nos permite hablar de una tecnología capaz de ayudarnos a gestionar el Proceso de Toma de Decisiones en su totalidad. La parte final de todo proceso de análisis es la acción, pero si dejamos la gestión de las acciones fuera de la tecnología BI, difícilmente vamos a poder cerrar el círculo y realimentar nuestro sistema

La siguiente imagen recoge los diferentes elementos que hoy conforman el mundo de la tecnolpgía de Business Intelligence y la Gestión del Porceso de Toma de Decisiones:

Los cinco Ejes son necesarios si queremos manejar la información de cara a gestionar nuestra toma de decisiones…., y acabamos de introducir otro matiz: ya no hablamos de tecnología de toma de decisiones sino de tecnología para Gestionar la Toma de Decisiones.

La Toma de Decisiones, entendida como la acción de tomar una decisión (decido ir al cine o irme a tomar una cerveza), es un acto cognitivo puntual que realiza un ser humano y que, salvo que hablemos de toma automatizada de decisiones (en función de reglas de negocio, etc….), no puede ser sustituido por ningún sistema. Sin embargo, la Toma de Decisiones como hecho empresarial, no es un hecho puntual, sino que es un proceso y como tal proceso sí puede ser gestionado con una determinada tecnología.

Por tanto, podemos definir BI como la Tecnología para la Gestión del Proceso de Toma de Decisiones.

La discusión anterior es importante pues, a nuestro entender, el primer gran problema a que se enfrenta cualquier proyecto de BI es determinar para qué se quiere poner en marcha. Difícilmente vamos a poder determinar el alcance de un proyecto, si no sabemos la problemática que queremos solventar.

Cuando abordamos un proyecto de BI es necesario determinar su alcance…, y esto no es tan claro ni tan sencillo como parece y constituye la primera etapa metodológica: La Determinación de Requerimientos. A continuación se desarrollan las características y problemáticas de este primer escalón.

Fase 1 .- Determinación de Requerimientos

Una consideración: si queremos hacerlo bien, esta etapa, que normalmente se soslaya, es básica y fundamental, y, por desgracia, normalmente se obvia totalmente;

Tiene tres etapas diferenciadas pero interrelacionadas:

1.1.    Determinación de Necesidades.

El objetivo de esta etapa es obvio: definir qué necesidades tenemos cuando nos planteamos la realización de un proyecto de BI. Sin embargo, como se detalla a continuación, este es un proceso mucho menos simplista de lo que pudiera parecer. Podemos estructurar esta etapa en tres actividades:

a)      Determinación de la Necesidad Emergente.- La primera pregunta que debemos plantearnos es qué necesidad tenemos dentro de la empresa y, sobre todo, para qué queremos un sistema de BI (si es que ya hemos llegado a determinar que eso es lo que precisamos).

Empezaremos siempre por examinar lo que denominaremos “Necesidad Emergente”, es decir, qué problema de gestión nos ha llevado al BI, y que, normalmente, está claramente identificado con uno de los Ejes Funcionales vistos:

• Tenemos un problema con la información que manejamos, ya sea por problemas de integridad de la información, por problemas de integración de fuentes diversas, por problemas con el tratamiento de los datos, etc….
• Tenemos un problema de accesibilidad a la información en que la información no está fácilmente accesible, o los formatos no son los adecuados, o no llega a quien tenía que llegar.
• Tenemos un problema para gestionar con dicha información, bien porque no podemos analizarla de una manera que sea operativa, bien la gestión de las decisiones adoptadas no funciona como debiera.

b)      Una vez analizada la necesidad emergente es fundamental revisar si el resto de necesidades existen también. Uno de los problemas más habituales de los proyectos de BI es enfocarlos atendiendo sólo a la primera necesidad detectada, sin revisar si existen otros problemas o necesidades que sea necesario atender.

Imaginemos que nuestra necesidad emergente viene derivada de los problemas de acceso y visualización de la información; antes de ponernos manos a la obra, deberemos analizar qué otros problemas existen en la empresa y cuál será la situación una vez implantada nuestra solución de visualización. En caso contrario, podemos encontrarnos con un magnífico Cuadro de Mando o sistema de Reporting con problemas de calidad de datos o, en el otro extremo, proporcionando información que no hay forma de trasladar a acciones operativas.

c)       Como tercer elemento, es necesario establecer el alcance de estas necesidades: ¿se trata de un único Departamento o Área afectado?; ¿podrían estar afectados por esta necesidad otras áreas?; ¿el alcance es general de toda la Compañía, aunque haya surgido de un área concreta?

La repercusión de esta pregunta es importante porque ignorarla puede significar que aunque el proyecto sea un éxito para el área en cuestión, su validez y pervivencia en el futuro sea nula porque no tenga capacidad de expandirse transversalmente o a la totalidad de la Organización

Todo proyecto de BI debe tener esas dos capacidades: la transversalidad (es decir, poder servir para cualquier otro área de la empresa) y la escalabilidad (es decir, poder ser válida para cubrir las necesidades globales)

La no consideración de este aspecto ha generado, en muchas ocasiones, proyectos que nacen y mueren en un departamento sin poderse aprovechar por la organización; hay multitud de empresas donde proliferan las herramientas de BI: cada departamento tiene la suya, pero ninguna tiene validez global, fundamentalmente, por que no se ha planteado que la tenga. Esto provoca una sensación de reinos de taifas y dinamita uno de los grandes beneficios que debería obtenerse del BI: la utilización de un lenguaje común.

Determinación de los Requerimientos del Sistema BI

1.2.    Determinación de las características de la Organización y su impacto sobre las Necesidades

Si en la implantación de cualquier ERP es necesario analizar las características de la Organización antes de abordar el proyecto, en un proyecto de BI es una actividad fundamental: la forma de realizar la toma de decisiones, depende de muchos elementos internos de la empresa. En este sentido, deberemos analizar, al menos, los siguientes elementos:

a)      Proceso de Toma de Decisiones. ¿Cómo se toman decisiones en la Organización? ¿Quién puede tomarlas? ¿existe autonomía o todas las decisiones deben pasar necesariamente por determinadas personas?

Los requerimientos funcionales del sistema BI deberán estar en consonancia con la estructura decisoria de la Organización; ¿para qué queremos un sistema con grandes capacidades de análisis en manos del usuario si todas las decisiones pasan por un “gran boss”  que es quien decide todos los temas y que, además, no va a tener tiempo de hacer el los análisis, sino que se los van a hacer otros?

Deberemos adecuar nuestro sistema a la realidad de la empresa, sea ésta la actual o la que prevemos en un plazo razonable.

b)      Gestión de Responsabilidades. ¿Tenemos un modelo jerárquico o descentralizado de responsabilidades? A la hora de ver cómo vamos a gestionar las decisiones es fundamental analizar cómo funcionan las responsabilidades en la Organización

La existencia de modelos de gestión como por ejemplo “dirección por objetivos” condiciona de manera positiva la implantación de un sistema de BI, facilitando la ampliación de necesidades a cubrir

c)       Política de Comunicación. Cómo fluya la información en nuestra Organización va a condicionar la posibilidad de explotar un sistema de BI: ¿existe un camino único y fiable? ¿cada área utiliza su propia información? ¿Cómo se determinan los flujos de información? Saltarse este análisis puede hacer que el sistema implantado quede sin fuerza “legal” dentro de la Organización por no responder a la política de comunicación existente. ¡Y ojo!, política de comunicación existe siempre, aunque sea no formal

d)      Sistemas de Control de Actuaciones.- ¿Cómo se gestionan los proyectos a desarrollar? ¿Quién asigna las responsabilidades? ¿Cómo se persigue su cumplimiento?

e)      Planificación.- La existencia o inexistencia de una cultura de programación y planificación de las actuaciones a realizar; la aceptación de dichas programaciones como un elemento básico o su tratamiento como un hecho aislado a soslayar dentro de la Organización influirá en el Modelo de Gestión a construir y deberá valorarse en el inicio del proyecto.

f)       Cultura de Empresa. Al final, lo que estamos analizando en este apartado son todos los aspectos que tienen que ver con la cultura de empresa que tiene nuestra organización; dependiendo de cómo sea ésta, tendremos que tener en mente unos u otros aspectos, pero siempre deberemos contemplarlo en el análisis inicial.

Si estamos diseñando un sistema para interactuar en la toma de decisiones de nuestra Organización, debemos conocer en profundidad cómo se están tomando las decisiones hoy en día, en teoría y en la práctica. Lo contrario puede hacernos diseñar un sistema inútil sin legitimidad en la Empresa.

1.3.    Definición de las características de los usuarios.

Tres aspectos debemos pararnos a considerar en esta fase del proyecto:

a)      Cómo son los usuarios finales.- ¿están acostumbrados a tomar decisiones? ¿Analizan la información suministrada o se limitan a ejecutar a partir del análisis realizado por otros? ¿Que usan hoy día para acceder a la información? ¿Cómo analizan los datos?

Debemos tener una fotografía clara del tipo de usuario final, sus características, hábitos  y limitaciones, pues debemos determinar si el proyecto quiere mantener la situación de partida o utilizarse como ariete para modificar determinados aspectos

b)      Si el proyecto afecta sólo a una parte de la Organización, deberemos considerar cómo es lo que está fuera del proyecto y cómo va a condicionar su implantación y su desarrollo posterior. Es importante, en este sentido, analizar las limitaciones que fuera del área pueden existir, sobre todo, si algún superior funcional o jerárquico puede condicionar el uso esperado. Es relativamente común que una vez en funcionamiento el sistema, un usuario externo al sistema, pero con poder de decisión dentro de la Compañía, pone trabas a la información o a su estructura o a su presentación, invalidándola y obligando a buscar formas externas para solucionarlo; estas situaciones terminan dinamitando el sistema, cortando su escalabilidad y, muchas veces, su propia viabilidad.

c)       Cuál es el perfil del área de sistemas y sus relaciones con los usuarios finales. ¿Cómo funciona el área de Tecnología actualmente y cuál se prevé que sea su papel tras la implantación del nuevo Sistema.

Un sistema de BI en condiciones debe trasladar de Informática al usuario final las labores de preparación de formatos y el análisis de los mismos. Pero estas son funciones que tradicionalmente han estado en la parte técnica. Si no queremos tener problemas futuros, debe existir un acuerdo entre las partes para ver cómo va a funcionar el modelo futuro.

Una vez que ya sabemos qué queremos hacer y qué condicionantes vamos a tener debemos detenernos unos instantes para establecer la Planificación del Proyecto, que constituirá la segunda Fase.

Fase 2 .- Estrategia de Proyecto

Vamos a establecer cómo va a ser el Sistema con el que gestionamos quizás la parte más importante de la Compañía. Una vez que ya sabemos lo que necesitamos y cómo es nuestra Organización, debemos pararnos a reflexionar sobre cómo vamos a realizar el proyecto.

Varios son los aspectos que deberemos establecer antes de lanzarnos a realizarlo:

• Explicitemos nuestra necesidad, a corto y a medio plazo
• Definamos su nivel de criticidad, lo que nos jugamos con este proyecto
• Establezcamos nuestros ventajas y nuestros puntos débiles para ponerlo en marcha
• Reflexionemos sobre las barreras que nos vamos a encontrar y cómo hacerlas frente
• Definamos las responsabilidades y los intervinientes
• Analicemos cómo deberíamos abordar cada fase para que tenga éxito (pero hagámoslo ahora, no cuando se produzcan los problemas)
• Establezcamos los niveles de éxito y fracaso aceptables para cada aspecto incluido, y las alternativas si no se consiguen
• Establezcamos la política de comunicación que vamos a seguir
• Finalmente, deberemos definir la estrategia de implantación

La definición previa de todos estos elementos nos permitirá adelantarnos a los problemas, explicitarlos a la Organización y transmitir la implicación de la Dirección en el Proyecto.

Por supuesto, en tanto en cuanto el proyecto toque más ejes funcionales y entre más en la gestión del proceso de toma de decisiones, la definición de la estrategia de proyecto será más crítica; obviamente, si mi única necesidad es acceder a determinada información con un sistema de informes, esta fase podremos aligerarla de manera considerable; por el contrario, si estamos estableciendo una nueva forma de gestionar la Organización, deberemos definir la estrategia de proyecto con cuidado, pues el resultado dependerá en buena parte de lo que hagamos en este momento.

Fase 3 .- Planificación del Proyecto

Cómo cualquier Proyecto de TI (y de cualquier otra cosa), antes de abordar el proyecto, es necesario pensar qué vamos a hacer, quien debe estar implicado y cuando tenemos previsto ejecutar las actuaciones definidas.

No es objeto de este artículo hablar sobre cómo se planifica un proyecto de IT (que probablemente todos hayáis hecho alguna vez), aunque si debemos resaltar algunos puntos básicos y que no deben olvidarse:

En primer lugar, no nos olvidemos de que una Planificación es un elemento de gestión y. como tal, debe servirnos para mejorar nuestro proyecto; establezcamos un cronograma creíble y realizable y determinemos cómo lo vamos a controlar, cómo vamos a detectar desviaciones y cómo vamos a actuar si se producen. No basta con tener un cronograma, hay que estar preparados para gestionar los tiempos. Preveamos que las cosas no van a funcionar como pensamos y ello nos permitirá establecer la estrategia de respuesta.

En segundo lugar, definamos responsables y responsabilidades, que no es lo mismo: yo puedo ser responsable de ejecutar una tarea concreta, pero es posible que, si no se puede hacer, no sea mi responsabilidad. Esto que parece un oxímoron se produce con gran frecuencia en nuestras organizaciones, al asignar a alguien una responsabilidad teórica pero no darle los medios materiales o el poder suficiente para llevarlos a cabo. Los proyectos de BI tocan muchas partes de la Organización y las dificultades muchas veces no están en un área concreta sino en los puntos de cruce. Establecer responsables adscritos a un área es la mejor forma de garantizar la existencia de problemas a la hora de abordar un proyecto de este tipo. Por tanto, definamos responsables y démosles poder para llevar a cabo sus funciones.

Esta metodología establece unas fases y actividades, que van desde el análisis inicial hasta que el sistema está funcionando al 100%; sea con esta u otra metodología, realizar una planificación es básico, aún más cuando todo lo que tiene que ver con la toma de decisiones suele ser un tema poco claro y definido. La existencia de una planificación nos ayudará a no saltarnos cosas de manera arbitraria y, al menos, a realizar una reflexión antes de obviar aspectos que inicialmente habíamos previsto.

Fase 4 .- Selección de la Tecnología

En un mundo tan variopinto como el de la tecnología de BI, con unas diferencias funcionales, de proceso y de operación tan grandes como las existentes entre las diferentes soluciones existentes, la selección de la tecnología debe realizarse en una fase temprana del proyecto, dado que condicionará de manera significativa lo que se pueda hacer y cómo se pueda hacer.

Ya sabemos lo que se va a requerir por parte del usuario, las funcionalidades presentes y futuras, los condicionantes derivados de la Organización y las relaciones de Sistemas con los usuarios. Es el momento de decidir qué tecnología se adecua a nuestras necesidades y cual satisface mejor nuestras características.

Dos serán los elementos a analizar: qué tecnología cubre funcionalmente nuestras necesidades y qué tecnología podemos soportar desde nuestra organización. El cruce de ambas debería darnos la mejor alternativa para soportar el proyecto, pero vamos a analizarlas inicialmente por separado:

3.1.    ¿Qué tecnología cubre funcionalmente nuestras necesidades?

Abordar este aspecto puede ser una tarea sencilla o compleja, aunque en general requiere un tiempo y dedicación elevados si queremos realizarla correctamente.

A nivel de los grandes Ejes Funcionales, el cuadre con las tecnologías existentes puede ser sencillo (saber si una tecnología permite desarrollar Cuadros de Mando debe ser inmediato), pero deberíamos  profundizar, estableciendo para cada Eje qué funcionalidad necesitamos actualmente.

No sólo deberemos establecer si necesitamos cubrir una funcionalidad, sino que deberemos establecer cómo desearíamos cubrirla. Vamos a verlo con un ejemplo:

Ejemplo detalle de formulación de requerimientos funcionales

• Eje Funcional: Visualización
  • Funcionalidad:               Reporting
  • Detalle funcional: informes de detalle, que incluyan gráficas, vinculación con otros informes y análisis directo (etc.–> debería incluir todos los detalles de lo que nos gustaría que hiciera)
    • Datos origen: Cubos multidimensionales y Tablas relacionales
      • Realización: Por el usuario final
      • Utilización: por el usuario final

Cada una de las funcionalidades de detalle deberemos graduarlas, fijando el grado de criticidad de las mismas, estableciendo qué es prioritario y qué es un objetivo deseable y, a ser posible, puntuando dicha criticidad (que es una forma magnífica de obligarnos a precisar).

Una vez que tengamos el nivel de cobertura funcional actual para cada Eje deberíamos establecer un mapa equivalente a medio plazo; es decir, por ejemplo, hoy no voy a tener usuarios que realicen directamente sus análisis, pero puede que en un par de años esa demanda si tenga sentido.

Una vez que tengamos nuestro mapa de requerimientos funcionales actuales y a medio plazo, ya estaremos en condiciones de compararlo con las tecnologías existentes y ver si lo cubren y cómo lo cubren.

3.2.    ¿Qué tecnología podemos soportar en nuestra Organización?

Ya tenemos la tecnología que mejor cubre nuestros requerimientos, pero ¿somos capaces de soportarla? La mejor forma de no tirar por un camino intransitable es situar esta pregunta al inicio, y utilizarla de filtro.

La primera pregunta debería ser si podemos soportar alguna tecnología, o si debemos ir a un esquema que nos permita no tener que soportar nada en nuestra Organización; actualmente la tecnología Cloud nos puede permitir, incluso, no soportar nada dentro de nuestra organización, externalizando completamente la funcionalidad.

Si decidimos ir a una solución in house, soportada internamente, deberíamos respondernos a una serie de cuestiones:

• Qué plataforma tecnológica tenemos (S.O., BD, estructura física, etc…)
• Qué tecnologías conocemos en la Organización
• Cuál es nuestra política de desarrollo (interno, subcontratación….)
• Como son los flujos TI v. Usuarios finales
• Cuál es nuestra política de formación en tecnología
• Cuál es nuestra política de formación a los usuarios

Por supuesto, deberemos establecer no sólo la situación actual, sino las previsiones futuras.

En función de ello, estableceremos nuestros requerimientos tecnológicos para la nueva solución.

Fase 5 .- Diseño del Sistema de Información

Ésta es la primera Fase en la que el usuario va a empezar a ver algo de lo que el sistema le va a aportar y, por tanto, es importante para asegurar que lo que al final tengamos sea lo que estábamos esperando.

El diseño responderá a las características del sistema a implantar, pero sí hay determinados aspectos comunes a todos y que podemos articular en una serie de subfases:

5.1.    Determinación del Modelo de Información

En primer lugar deberemos definir exactamente qué necesitamos tener en nuestro sistema de información, en cuatro aspectos:

• Variables a controlar, definidas exhaustivamente (por ejemplo, ventas = ventas brutas – comisiones – rappels a estándar por tipo de cliente)
• Dimensiones por las cuales vamos a querer gestionar dicha información, es decir, qué es significativo para nuestro negocio de cada variable (siguiendo con el ejemplo, puede ser conocer las ventas por cliente, por área geográfica, por tipo de producto, por producto, etc….)
• Dónde está esa información y si está tal cual la necesitamos o precisa transformaciones
• ¿Qué funcionalidad necesita cada tipo de usuario para manejar esa información?. No olvidemos que si queremos montar un sistema que funcione, no deberíamos forzar a que todos los usuarios utilicen la misma herramienta de visualización. Un ejemplo: puede haber usuarios que accedan a cuadros de mando con indicadores, otros que vean informes de detalle, otros que puedan analizar la información, etc… Esto influirá notablemente en el diseño que deberemos hacer del Sistema de Información.

5.2.    Diseño de la plataforma de visualización por tipo de usuario

Vamos a determinar qué es lo que debe utilizar cada usuario o tipo de usuario para visualizar su información.

En este punto debemos plantearnos cuál es la manera más eficiente para que los usuarios accedan a ver la información.

Veamos un ejemplo: información de ventas en una organización comercializadora; con independencia de temas de control de acceso, probablemente pudiéramos montar un esquema como el siguiente:

1.- Nivel A (directores no comercial).- Cuadro de Mando con indicadores comerciales y otros indicadores de gestión

2.- Nivel B (directores área comercial).- Cuadro de Mando y Sistema de Análisis de Información

3.- Nivel C (comerciales).- Sistema de Reporting, con detalle de información y acceso a sistema de análisis

4.- Nivel D (comisionistas).- Informes en PDF enviados de manera automática todos los días con detalle de las operaciones realizadas y las comisiones devengadas

En el caso de utilizar diferentes funcionalidades, esto nos permitirá, además, dimensionar la plataforma de aplicaciones a los requerimientos de la organización, probablemente adecuando el coste a las necesidades reales. En el ejemplo anterior, está claro que el licenciamiento de un sistema de CM con análisis integrado es mucho más costoso que un sistema de generación y envío automático de PDF’s por email; por tanto, si las necesidades de una parte importante de mi fuerza comercial quedan cubiertas con una solución más económica, mejor que mejor.

5.3.    Diseño de la interfaz de usuario

Diseñar qué es –al nivel de detalle que se defina- lo que va a ver el usuario nos permitirá asegurarnos de que hemos entendido su necesidad y adecuar la tecnología a sus características.

En caso de utilizar diferentes plataformas de visualización también deberemos prever qué se utilizará en cada caso.

Un elemento básico en este punto es diseñar la navegabilidad que va a tener el usuario dentro del sistema: diseño de menús de acceso, estructura de navegación, etc.

La validación del resultado de esta fase con los requerimientos establecidos y su aprobación por parte de los usuarios es fundamental. Todo proyecto informático requiere hitos de aprobación, pero debemos tener en cuenta que un proyecto de BI está diseñando cómo se va a gestionar la Compañía; por ello, este punto de validación cobra una especial relevancia.

Una vez pasado este punto, estaremos en condiciones de elaborar nuestro sistema de información, lo que constituye el objeto de la quinta fase.

Metodología de Business Intelligence

Fase 6 .- Elaboración del Sistema de Información

No vamos a entrar en esta fase en cómo se realiza un sistema de información. Existen múltiples metodologías que nos permitirán organizar adecuadamente todo el proceso productivo, teniendo en cuenta, además, que la tecnología elegida tendrá una repercusión importante.

Como veremos más adelante uno de los principales obstáculos que normalmente encontraremos para establecer un nuevo sistema como éste, será la reticencia del usuario. Normalmente cómo vive el usuario final un proyecto de éstos: se entera de que se va a realizar, con suerte le preguntan su opinión y, de repente, se encuentra con un nuevo sistema que como mínimo le supone una ruptura con lo anterior…, ¡y todavía nos extrañamos de que su posicionamiento –al menos inicial-, sea de rechazo!

Al igual que en la fase anterior, éste es el momento de hacerle participar. Con el formato que queramos, de la manera que más encaje con la cultura de la empresa…., pero dejémosle que participe. Probablemente será la mejor inversión de todo el proyecto.

…

Ya tenemos nuestro sistema, pero esto no ha acabado ni mucho menos: nos queda ponerlo en marcha y eso es uno de los puntos en los que tradicionalmente yerran todas las implantaciones de los sistemas de BI.

Fase 7 .- Planificación de la Implantación

Empezaremos por planificar cómo vamos a realizar la implantación. Puede que éste punto ya lo hayamos incluido en la fase de Definición de la Estrategia de Proyecto (así lo habíamos dicho en su momento); a pesar de ello, y aunque ya hayamos definido cómo vamos a hacer al implantación, aquel planteamiento respondía a lo que suponíamos iba a ocurrir…., pero en este momento ya tenemos el sistema, ya hemos ido interactuando con los usuarios, ya hemos visto qué aspectos gustan y antes cuales son más reacios…., pues éste es el momento de revisar y ajustar nuestra estrategia para garantizar que el proyecto tenga éxito.

Revisemos cómo están todos los temas que en su momento planteamos: si hemos cubierto todas las necesidades que teníamos previstas, el nivel de implicación de los usuarios, si hemos cumplido nuestra estrategia de comunicación, etc….; y aquellos aspectos que no hayamos realizado como teníamos previsto, evaluemos su impacto y cómo debemos hacer la implantación para suplir carencias y aunar voluntades

Fase 8 .- Implantación Piloto

Todos los proyectos de implantación de ERP’s etc., siempre incluyen una fase en la que el sistema se prueba en paralelo, se verifica que hace lo que tiene que hacer, se detectan las pegas para los usuarios, ¿por qué no hacer lo mismo en los sistemas de BI?

El concepto de paralelo probablemente no tenga sentido en este tipo de sistemas, puesto que al no incidir en los procesos podemos mantener el antiguo sistema de información y el nuevo sin problemas. Sin embargo, lo que si deberemos hacer es, antes de implantarlo en todo el área o toda la organización, probar que lo que hemos hecho sirve para gestionar.

Volvamos a los conceptos iniciales: si estamos desarrollando un sistema para la toma de decisiones que nos permita mejorar la gestión de nuestra compañía, no nos basta con decir que ya tenemos hecho un Cuadro de Mando o unos Informes y soltarlos en la empresa. ¡No!, debemos asegurarnos de que el nuevo sistema permite a los usuarios gestionar mejor, y para eso deberemos probarlo.

Para ello podemos utilizar muchos esquemas, como por ejemplo, coger un pequeño grupo de directivos (que cubran todos los perfiles) y establecer un proceso de implantación reducido, tal cual se describe en las fases siguientes, hasta llegar a la aprobación final del sistema, pero para un universo de usuarios limitado.

Corregidos los defectos encontrados y modificada nuestra estrategia de implantación, ya estaremos en condiciones de realizar la implantación

Fase 9 .- Formación

Estamos ante uno de los puntos en los que suelen fallar los sistemas de BI: la formación que reciben los usuarios y los técnicos sobre el nuevo sistema. No basta con plantear una formación sobre el uso de las herramientas implantadas, es necesario adiestrar en la manera de utilizarlas, y esto afecta a los usuarios y a los departamentos técnicos.

Qué debe incluir la formación:

• Formación a áreas técnicas:
  • Formación en el uso de las tecnologías. Es obvio: nuestro departamento de IT debe conocer en profundidad la nueva tecnología y deben estar formados, por supuesto en función de que su evolución y desarrollo se vaya a hacer directamente o se vaya a subcontratar.
  • Formación en la utilidad de esas tecnologías. No basta con saber cómo funcionan, IT debe conocer en detalle para qué puede servir, qué cosas tiene sentido hacer y cómo hacerlas…., porque va a ser quien pueda hacer de interlocutor con los usuarios.
  • Formación a usuarios finales:
    • Formación operativa en el uso de su modelo de negocio. Debemos enseñar a los usuarios a utilizar la nueva tecnología: cómo se navega, cómo se accede a las herramientas de análisis y se utilizan, etc…, pero a un nivel de detalle que les capacite para empezar a utilizar la tecnología desde los primeros momentos, con un rendimiento alto. Si no conseguimos este nivel de formación, será muy difícil que los usuarios abandonen los esquemas anteriores e incorporen la nueva tecnología.
    • Formación a los usuarios sobre cómo gestionar con ésta nueva tecnología. No basta con que sepan utilizarla (faltaría más); debemos enseñarles a cómo gestionar, cómo tomar decisiones, cómo poner en marcha acciones correctivas, como gestionarlas…., y esto va mucho más allá de lo que simplemente es saber utilizar una herramienta

Fase 10 .- Puesta en Marcha del Sistema

Ya hemos hecho un piloto, hemos formado a los usuarios, ¿nos falta algo para echar a rodar nuestro nuevo sistema? ¡Sí, nos falta acompañarles mientras empiezan a utilizar el sistema!

No basta con darles formación y que sepan cómo utilizarlo, deberemos establecer una sistemática para que incorporen esa tecnología en su día a día. Deberíamos poder sentarnos periódicamente con cada usuario y ver qué están haciendo, cómo lo están haciendo y proponerles operativas diferentes aprovechando las capacidades del nuevo sistema.

Vamos a poner un ejemplo que quizás sea más didáctico: imaginemos que hemos implantado un sistema que incorpora un cuadro de mando, con una herramienta de análisis y otra de informes incorporada (algo sencillo y mínimo). Deberíamos programar reuniones, por ejemplo semanales con cada usuario. En ellas revisaríamos qué información necesita, le “forzaríamos” a resolver su necesidad con la herramienta de análisis, profundizando en las posibilidades que tiene, hasta llegar a las conclusiones necesarias, le podríamos sugerir que compartiese con otros mediante un informe directamente degenerado por el usuario la información, que solicitase a sus subordinados que utilizasen el sistema para reportarle y que el reportase utilizando las capacidades del nuevo sistema.

Pero para esto tenemos que estar con el usuario: la formación no basta para aprender a gestionar utilizando una tecnología de BI, es necesario adiestrar en su uso.

Estas diez fases son consecuencia directa de cuatro consideraciones fundamentales a la hora de abordar un proyecto de BI:

Aspectos Fundamentales para la Implantación de un Sistema de BI

• Debemos tener clara la necesidad actual y su evolución futura, si no queremos hacer algo inservible a corto plazo
• Es un tema que afecta a la Gestión y, por tanto, a los usuarios, que son quienes gestionan las organizaciones; por consiguiente debemos contar con ellos. Es para el usuario y debe hacerse con el usuario
• La elección de la tecnología depende de las necesidades y del Modelo de Gestión de la Organización
• Hay que planificar todo el proyecto y gestionarlo