BI, PASOS PARA SU

IMPLANTACIÓN

ADRIÁN RAMÍREZ.
 Agenda

Implantación
Por dónde empezar
Los 5 ejes
Pasos
Fase 1 .- Determinación de Requerimientos
Fase 2 .- Estrategia de Proyecto
Fase 3 .- Planificación del Proyecto
Fase 4 .- Selección de la Tecnología
Fase 5 .- Diseño del Sistema de Información
Fase 6 .- Elaboración del Sistema de Información
Fase 7 .- Planificación de la Implantación
Fase 8 .- Implantación Piloto
Fase 9 .- Formación
Fase 10 .- Puesta en Marcha del Sistema
 Implantación

La implantación de sistemas de BI es un proceso

complejo que, generalmente, surge de un
departamento concreto y que requiere implicación
del conjunto de la organización, y una visión global
por parte de todo el equipo del proyecto.
 Gestión del proyecto IT

La gestión del proyecto informático que dé lugar a la

implantación del sistema de BI requiere un equipo
de profesionales mixto (de negocio y tecnología) que
sepa traducir los requerimientos de la estrategia en
indicadores de negocio y sistemas completos de toma
de decisiones aprovechando la infraestructura
tecnológica disponible en cada empresa.
Construcción del almacen de datos (Data
Warehouse y Datamarts)

La construcción del almacén de datos ha de partir de

una visión única de negocio, integrando en una única
base de datos información de los diferentes sistemas
de gestión de la compañía (ERP, CRM, etc).
Esta base de datos ha de estar perfectamente
depurada y definida para evitar: datos redundantes,
confusión en el significado de los indicadores e
información errónea.
 Por dónde empezar

El mundo BI, incluye diferentes tecnologías que dan

cobertura a diferentes problemáticas, pero de alguna
manera responden a 5 ejes fundamentales:
1. Captación de Información
2. Manejo de Información
3. Visualización y distribución
4. Análisis de la información
5. Gestión de las decisiones adoptadas
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 ignora, 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.
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 elaboelaborar
nuestro sistema de información, lo que constituye el objeto de la quinta
fase.
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:
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
Fin