Resumen
Son muchos los proyectos Business Intelligence o Data Warehouse que concluyen con fracaso. Entendido éste como un ‘no cumplimiento de las expectativas’: coste, plazos de entrega, utilidad, calidad de los datos, usabilidad por los usuarios, implicación de la compañía, contribución a los resultados, etc…
Aquí se intentan explicar algunas claves, basadas en experiencias reales, que nos permitan abordar con éxito una implantación de este tipo.
1. ¿Qué es el Business Intelligence?
Para poder conseguir este objetivo, primero es preciso conocer que es el Business Intelligence o Inteligencia de Negocio:
Desafortunadamente, este término no tiene nada que ver con el índice de inteligencia medio de las personas que trabajan en un determinado negocio. De hecho, la inteligencia de negocio (BI) tiene que ver con los datos y aplicaciones de un negocio para entenderse mejor. Semejante a la inteligencia militar, que procura entender al enemigo, la inteligencia de negocio versa sobre todo alrededor de sí mismo. Específicamente, los sistemas de la inteligencia de negocio se basan en crear modelos informáticos de negocio de modo que pueda funcionar más eficientemente.
El almacenamiento de los datos está en la base de los procesos de la inteligencia de negocio. En el mundo de ETL, la inteligencia de negocio se refiere generalmente al espacio entero de los sistemas de la base de datos, del software, del análisis, y de la evaluación del usuario que pretende entender y evaluar un negocio.
Hay generalmente unos o más usos analíticos del software (por ejemplo, Business Objects, Cognos, o Microstrategy).
Los sistemas del BI se diferencian de sistemas operacionales en que están optimizados para preguntar y divulgar sobre datos. Esto significa típicamente que, en un Datawarehouse, los datos están desnormalizados para apoyar preguntas de alto rendimiento, mientras que los sistemas operacionales generalmente se normalizan completamente para apoyar integridad de referencia y para insertar datos continuamente. Los procesos de ETL que cargan sistemas del BI tienen que traducir del sistema operacional normalizado a desnormalizado. Y, típicamente, tienen fallos severos de funcionamiento debido a que no deben degradar el funcionamiento de los sistemas operacionales, y no deben prohibir el acceso al almacén.
Por eso surge el Business Intelligence, basado en nuevas estructuras de análisis, básicamente multidimensional, en contraste con el relacional.
2. ¿Como elegir una aplicación Business Intelligence?
Lo primero que puedo decir es que tenemos que identificar cuáles son las necesidades y el tipo de herramienta que se busca: análisis, reporting, base de datos, OLAP, etc…
De momento, os voy a dejar con unas pinceladas, según mi criterio, de los principales factores (sin orden de importancia) a tener en cuenta cuando elegimos una herramienta Business Intelligence:
1) La Plataforma: No es lo mismo estar atados a Microsoft, o poder trabajar en Unix, o tener una estrategia Open Source Linux. Lo mismo aplica al hardware. Algunos fabricantes son restrictivos.
2) El Curriculum del vendedor: Es muy útil conocer el tipo de implementaciones que se han hecho, si se han realizado en tiempo, si se utilizan, la satisfacción de usuarios, etc…
3) El tamaño del cubo: Es imprescindible hacer un análisis previo de la amplitud de la información a almacenar. Algunas aplicaciones pueden ‘explotar’ llegado cierto nivel.
4) La velocidad de consulta: Los usuarios siempre quieren velocidad en sus consultas. Y si 20 segundos de espera es mucho, quizás haya que buscar otra herramienta.
5) Servicios de soporte y ayuda a nivel mundial: Tenemos que tener la seguridad de que si algo falla en la aplicación (y fallará, esto es seguro) podamos resolverla en el menor tiempo posible.
6) Evaluaciones de analistas: Gartner, IDC saben de qué hablan… y suelen ser objetivos. No está de más fijarse en sus ‘cuadrantes’.
7) El ecosistema del vendedor (consultores, partners, acuerdos, comunidad de desarrolladores…).
8 ) Base instalada de usuarios. Si hay de mi sector mucho mejor. Si puedo hablar con ellos y ver la herramienta en vivo, todavía mejor.
9) Graphical User Interface (GUI). Hay que recordar que hablamos de una herramienta para usuarios finales y si a éstos no les gusta, no la utilizarán y será dinero tirado.
10) El precio: No tiene por qué ser lo más importante…pero…es importante!!!
11) Integración con otras herramientas: Ninguna herramienta funciona como una isla aislada del resto. Lo mismo que una empresa, si creas islas, crearás incomunicación.
3. ¿Por qué fallan muchos proyectos Business Intelligence?
A veces nos sorprende que con el desarrollo al que han llegado muchas herramientas, el uso de metodologías contrastadas y el mayor nivel de conocimiento de técnicos y usuarios, se produzcan tantos desastres en la implementación de soluciones Business Intelligence, en términos de exceso de coste sobre el previsto, no utilización por parte de los usuarios, no cumplir con las expectativas, información errónea, etc…
En base a mi experiencia os voy a comentar cuales son algunos de los principales fallos:
1) Muchos Data Warehouses crecen en tamaño de forma desproporcionada porque los técnicos no consiguen decir ‘no’ a las ‘excesivas’ demandas de los usuarios.
2) Se prefiere realizar el proyecto con gente de la propia empresa, cuando éstos no tienen ni tiempo, ni conocimientos para poder abarcarlo.
3) Se fijan unas fechas de entrada en producción del sistema poco realistas, que
provoca nuevas fechas y más retrasos.
4) El presupuesto destinado para el proyecto es escaso en comparación con el grado de complejidad que se quiere desarrollar.
5) La selección del software y hardware a veces se realiza siguiendo criterios de acuerdos generales o compromisos, antes que puramente técnicos.
6) Antes del proyecto, no se realizan benchmarks o ‘pruebas de concepto’ para determinar la viabilidad.
7) Los datos de origen no están limpios. Duplicidades, errores, carácteres erróneos… implican un proceso ETL más costoso, mayor tamáño de la Base de datos y peor rendimiento.
8 ) El sponsor del proyecto no ejerce como tal durante el mismo. No ‘baja a la tierra’.
9) Mala elección de los consultores y excesiva rotación entre ellos.
10) Escasa involucración de los usuarios finales que les lleva a sentir cierta frustración con los resultados obtenidos.
11) Caer en el error de ‘en informática todo se puede hacer’ y empezar con customizaciones, escribir código fuera de las funcionalidades standard.
12) No alinear el proyecto dentro de una estrategia de negocio.
Existen muchos más factores que pueden hacer fallar un proyecto Business Intelligence, pero éstos pueden hacer literalmente ‘tumbarlo’, no conseguir más proyectos para los consultores, mala imagen del producto y riesgos internos para el director de informática y otros sponsors.
4. Los sistemas OLAP. Consejos para su correcto uso.
Vamos a suponer que hemos realizado un análisis detallado de las necesidades de la empresa, se ha hablado con todos los interlocutores y usuarios, hemos identificado las necesidades de reporing y acceso, y finalmente, tenemos claro el modelo (que variables, formulas, dimensiones…) vamos a incluir.
Es en este momento cuando nos planteamos la pregunta clave: ¿Qué método de almacenamiento vamos a utilizar? Podemos tener todos los datos en nuestro sistema transaccional, que permite montarlo más rápido, pero puede ser menos eficiente. O podemos precalcular la información para que ésta se obtenga de forma rápida y exacta. Es una decisión muy importante, porque puede implicar mayor coste de mantenimiento y de licencias.
Es aquí donde conviene aclarar estos acrónimos:
OLAP es online analytical processing. Se trata de una forma de almacenar la información en una Base de Datos que permita realizar de forma más efectiva las queries. Es una definición abreviada, claro está, la realidad es más compleja.
MOLAP: Multidimensional OLAP. Tanto los datos fuente como los datos agregados o precalculados residen en el mismo formato multidimensional. Optimiza las queries, pero requiere más espacio de disco y diferente software. El primer punto está dejando ser un problema: el espacio de disco cada vez es más barato.
ROLAP: Relational OLAP. Tanto los datos precalculados y agregados como los datos fuente residen en la misma base de datos relacional. Si el DataWarehouse es muy grande o se necesita rapidez por parte de los usuarios puede ser un problema.
HOLAP: Hybrid OLAP: Es una combinación de los dos anteriores. Los datos agregados y precalculados se almacenan en estructuras multidimensionales y los de menor nivel de detalle en el relacional. Requiere un buen trabajo de análisis para identificar cada tipo de dato.
Desde un punto de vista práctico me gustaría añadir algunas otras características de un sistema OLAP:
- Debe ser rápido. No debe transcurrir mucho tiempo entre la necesidad de información y el resultado.
- Debe tener un lenguaje funcional y de negocio.
- Debe ser de manejo sencillo, con wizards y templates.
- Debe poder integrar API.
- Debe tener potentes posibilidades gráficas.
- Debe utilizar mapas de forma habitual.
- Posibilidad de almacenar y compartir los informes y cálculos creados por los usuarios.
- La administración la deben llevar los usuarios, no IT.
- El tiempo de implementación (proyecto) debe ser muy corto.
- Deber generar respuestas medibles para la toma de decisiones.
- Tenemos que ser capaces de obtener ROI con las aplicaciones OLAP.
Como resumen final se puede decir los tres principales aspectos a cuidar son la elección de las personas que usaran las herramientas, de quienes llevan el mando en el proyecto y de los consultores externos. Además de todo esto, el sistema debe estar dentro de una estrategia de negocio clara a medio y largo plazo, para evitar soluciones parche y gastos innecesarios.
