Construya su Business Intelligence con Inteligencia

Desconozco si, antes que yo, alguien acuñó el concepto de ‘Business Stupid’ o si fue mi mente en un delirio por tratar de comprender ciertos planteamientos, la que me llevó a crear esta etiqueta hace ya varios años.

El caso es que existir, existe, doy fe. Y a lo largo de mi exposición, posiblemente veáis reflejados alguno de vuestros demonios que, lejos de ser particulares,  son más generales de lo que se pueda pensar.

Desgraciadamente, el tema es tan extenso y complejo, que, en esta intervención solamente podré trazar las líneas argumentales. Nada más lejos de mi intención hacer sangre, sino más bien, trazar, desde la experiencia, la delgada línea que separa el Éxito del Fracaso en la Concepción, Diseño y Construcción de una solución Business Intelligence. Si mi exposición sirve para evitar o minimizar problemas futuros, la doy por válida.

Para positivar este desarrollo, en adelante, no hablaré de Errores, sino de Aspectos Clave, que se conviertan en errores o no, depende de la atención que prestemos a cada uno.

Todos los que hemos trabajado, de alguna manera, en un Informacional conocemos, o deberíamos, la teoría de lo que debe ser un Sistema Informacional y, en mayor o menor medida, habremos bebido de fuentes reconocidas como Inmon o Kimball, quienes con su visión particular y su habilidad para comunicar crearon las dos corrientes principales que dividen el mundo del BI.

No se puede decir que antes de ellos, todo fuera oscuridad, pero sí que había muchas sombras.

La elección de uno u otro, cae la mayoría de las veces, de parte del Cliente, y suele estar justificada por las luchas internas  entre Áreas y el protagonismo que se suele dar al área de TI, que suele ser muy poco.

La diferencia de enfoque entre ambas, se basa en si queremos tener un Datawarehouse Corporativo que centralice la información y la distribuya a las diferentes áreas en forma de Datamarts departamentales o, por el contrario, si comenzamos a generar Datamarts departamentales para cubrir necesidades específicas, sin pretender unificar la información corporativa.

La primera opción, que corresponde a la corriente de Bill Inmon, requiere una Inversión inicial mayor, en Tiempo, Coste y Esfuerzo, para determinar qué información corporativa debe formar parte del Núcleo del Almacén central, y para definir el Diccionario Único de Datos que será la referencia que guiará el Sistema Informacional. Esta mayor inversión inicial permitirá reducir drásticamente los Costes de desarrollos posteriores.

La segunda opción, que corresponde a Ralph Kimball, se basa en la premisa de cubrir necesidades puntuales orientadas a departamentos concretos, y que permiten obtener resultados impactantes en un breve espacio de tiempo, pero generan Islas de información que dificultan la integración global posterior y la generación de un Diccionario de Datos único.

Este suele ser el primer Aspecto Clave a la hora de plantear un Sistema Informacional. Para descargo del consultor de a pie, hay que decir que la decisión la toma generalmente la compañía contratante, en adelante, el Cliente, basándose en criterios principalmente Económicos y fundamentada por Tensiones internas que acaban decantando la decisión en un sentido u otro, dependiendo del respaldo que posea el Esponsor del Proyecto, si lo hubiera (por desgracia, no siempre hay un Sponsor con peso suficiente). A lo sumo, el Consultor podrá recomendar, en función de la situación de la compañía, la solución que considera mejor, pero hasta ahí puede llegar.

El Enfoque del Sistema Informacional, si bien puede partir de Negocio, no debe construirse a espaldas de TI, algo bastante frecuente. Las tensiones internas y errores de planteamiento que se generan por este motivo, las suele pagar directamente el propio Cliente, cuando el resultado obtenido no se corresponde con las expectativas generadas (en ocasiones se genera una solución que no llega a utilizarse o que debe ser reemplazada por otra posteriormente) e  indirectamente el Consultor externo.

Por ello, se hace necesario realizar un estudio inicial donde se refleje la Situación Actual, ‘AS IS’, la Situación Objetivo, ‘TO BE’ y las diferencias a subsanar entre ambos escenarios ó ‘GAPs’. Este debe considerarse el primer Proyecto previo a realizar.

Y a este Análisis de Situaciónno siempre se le presta la debida Atención/ Esfuerzo. Para que sea efectivo debe

tener suficiente:

1. Profundidad: se debe identificar el tipo de información en cada caso.
2. Amplitud: Conocimiento de todos los Sistemas implicados y su participación
3. Respaldo: Se debe tener acceso a toda la información necesaria, sin bloqueos

El corolario de este Análisis debe estar en el Plan de Acción que se trace, donde se debe reflejar el camino a recorrer para llegar de la situación actual a la situación futura, con una planificación temporal realista que cubra el GAP existente, priorizando las tareas adecuadamente.

Es aquí donde encontramos el segundo aspecto clave a considerar: Los Objetivos y el Alcance del Proyecto deben estar perfectamente definidos de manera Cualitativa y Cuantitativa: la definición del Qué, Cómo y Cuánto deben quedar registrados previamente al inicio del Proyecto de Implantación del Sistema Informacional y debe estar pactado y consensuado entre las partes, sin ambages. Deben definirse Objetivos realistas y cuantificarse claramente los elementos que formarán parte del resultado final.

Para ello, se recomienda realizar un trabajo de Análisis previo enfocado hacia una Toma de Requerimientos en la que participen todas las Áreas involucradas de manera que queden finalmente registrados y validados todos los requerimientos que definan la solución futura. En base a ellos, se podrá planificar y dimensionar el proyecto.

El tercer aspecto clave a considerar es la Planificación del Proyecto, en la que se definirá de qué manera se generará la secuencia de tareas que se deben realizar para cumplir los objetivos definidos, y cuánto tiempo se dedicará a cada una. La Planificación del proyecto debe cumplir una serie de requisitos básicos:

1. Realista
2. Adaptada al Cliente
3. Vinculada al cumplimiento de Hitos
4. Dependencia entre Tareas
5. Consensuada con el cliente, el Equipo de Desarrollo y alineada con los Procedimientos propios del Cliente.

El siguiente aspecto a considerar es el Dimensionamiento del Equipo: factores a considerar:

1. Estructurado por perfiles y por Tecnología. Asignación de Tareas.
2. Dedicación de cada Perfil
3. Fecha de Incorporación y Desincorporación
4. Cómo y dónde se ubicará el equipo: OnSite (Oficinas del propio Cliente), Remoto o Mixto
5. Aseguramiento del Mantenimiento del Equipo hasta la finalización de las Tareas respectivas.
6. Colaboración necesaria por parte del Cliente: Perfiles necesarios, Grado de Participación…

Comentario aparte merece la consideración de un proyecto con participación de Factoría. En este caso, debe tenerse en cuenta una serie de premisas que aseguren el buen funcionamiento de la colaboración.

Otro aspecto debe ser Fijar los Procedimientos de:

1. Interlocución: Quién va a participar y a qué nivel en las diferentes tareas que lo requieran, desde la toma de requerimientos hasta el análisis o los Procesos de Validación y Cuadre
2. Control y Seguimiento: Frecuencia, Interlocutores, objetivos,….

Elementos a considerar dentro del proyecto y que pueden considerarse vitales para el éxito:

1. Altamente recomendable: incluir como colofón de la fase de Ánalisis y Diseño, una Maqueta lo más aproximada al resultado final, de manera que sea validada por el Usuario que va a participar en la validación final.
2. La arquitectura que se plantee debe tener en cuenta la distribución de las 3 etapas típicas en el proceso ETL: Staging, Datawarehouse, Datamart . Cada una de ellas requiere un tratamiento diferente y no deben obviarse sin más.
3. Debe definirse el Ciclo de Vida del Dato.
4. Debe definirse un Diccionario de Datos.
5. Deben definirse Procesos de Limpieza y Calidad de los Datos, para evitar inconsistencias.
6. Definir un Plan de Pruebas, Cuadre y Validación detallado y  adecuado.
7. Prefijar los Entregables sobre los que se realizará la aprobación final, tanto de Software como Documentales y a qué Hito de la Planificación irán ligados.

Cada uno de ellos, merece un capítulo aparte por sí solo.

En contraposición con estos aspectos, podemos resumir las Peores Prácticas, en las siguientes:

1. Enfoque del Sistema Informacional no adecuado a la realidad de la compañía.
2. No existe Sponsor del proyecto o si existe, no dispone de respaldo suficiente dentro de la compañía.
3. No se ha realizado un Análisis adecuado y exhaustivo. En ocasiones encontramos catalogado como análisis una relación interminable de pantallazos de informes sin más explicación.
4. No se ha realizado una Toma de Requerimientos adecuada, o no se ha contado con la participación de todas las Áreas involucradas o ha transcurrido tiempo suficiente para dejar obsoletos los requerimientos o no han quedado perfectamente definidos.
5. No se realiza una Maqueta durante el proyecto, como cierre del Análisis y Diseño. Genera desalineamiento entre las expectativas del Usuario y los desarrollos.
6. El Dimensionamiento del proyecto no es el adecuado: con el objeto de rebajar costes se incurre en errores como reducir tiempos, sustituir perfiles Senior por otros con menos experiencia o no se tiene en cuenta, cuando se trabaja con Factorías, que los Procedimientos de trabajo deben estar perfectamente estandarizados y debe realizarse un control riguroso de la evolución y Calidad de las Tareas.
7. Considerar al Jefe de Proyecto el chico para todo, que puede y debe cubrir cualquier carencia del equipo. El Jefe de Proyecto es el garante del cumplimiento de los compromisos adquiridos. Desviar su atención hacia otras tareas o privarle del respaldo necesario es una póliza de fracaso asegurado.
8. Culpar al Jefe de Proyecto de cualquier problema que surja durante el proyecto. Ser Responsable no es lo mismo que ser Culpable. Muchas veces, el Jefe de proyecto hereda situaciones que le son ajenas (un mal planteamiento inicial provocado por una errónea preventa, tensiones internas en el cliente, procedimientos de trabajo no consensuados, intereses creados al margen del proyecto,… ) y debe tratar de rectificar esas situaciones. Nuevamente volvemos al respaldo que debe prestarse en todo momento al JP, máxime cuando denuncia situaciones de Riesgo con antelación suficiente.
9. No prestar la debida atención a la Calidad de la ETL ni al diseño del Modelo Relacional y Dimensional, que son los factores más críticos del Sistema.
10. Rotación elevada durante el proyecto o pérdida de Personas Clave.
11. Generar bloqueos por desacuerdos en la aceptación de entregas  que contienen aspectos no definidos adecuadamente en los Requerimientos.
12. No definir un Plan de Pruebas adecuado puede hacer que no se realicen las pruebas necesarias y no pueda garantizarse, por tanto, la Calidad de las entregas.
13. No realizar una adecuada Transferencia del Conocimiento, de modo que el mantenimiento no llegue a ser operativo de manera autosuficiente.
14. No promocionar adecuadamente la solución entre las Áreas usuarias, a lo largo de la vida del proyecto: se debe buscar su participación activa, al menos, en las tareas de definición de requerimientos, Análisis, Diseño y Validación de la Maqueta, Pruebas y Validación y Formación final al usuario

En resumen, esta exposición es fruto de una reflexión particular sobre el tema. Seguramente, alguno de vosotros pueda discrepar en parte, aunque no creo que del todo, y posiblemente en la forma, pero no en el fondo.

Quizás algunos penséis que, realmente, no hay tantas compañías que no dispongan de un Sistema Informacional a estas alturas, pero os equivocáis. Seguramente las grandes compañías del Sector Bancario y Asegurador sí lo posean en su mayoría, y desde hace bastantes años. A fin de cuentas, son los sectores más maduros desde el punto de vista informacional. Pero hay muchas otras compañías de otros sectores de mediano tamaño y un volumen de facturación considerable que aún no disponen de un Sistema Informacional potente. Compañías que pueden verse tentadas por Sistemas basados en la nube o en la Lógica asociativa, sobre la premisa de un menor coste o unos tiempos mucho más reducidos. Sin pretender denostar ninguna solución, digamos solamente, que cada solución tiene su aplicación particular dentro de un marco concreto. Fuera de él, pierde todo el sentido y no son comparables. Pero este es otro tema y podremos tratarlo en una futura exposición.

Se dice con frecuencia que es de sabios aprender de los errores, pero no cabe duda de que es más inteligente aprender de los errores ajenos.

Si puedo contribuir a evitaros alguno, daré por bien empleado mi tiempo. Solo me queda agradeceros el vuestro