Ejecución de un proyecto de inteligencia de negocio

Asegurar que se realizan las actividades y tareas para cumplir los requisitos del proyecto.

Asegurar que se crean o producen los entregables (productos o servicios) objeto del proyecto.

Asignar, organizar, entrenar y gestionar a los miembros del equipo del proyecto.

Implementar los métodos y estándares de trabajo planificados.

Establecer y gestionar los canales de comunicación del proyecto, tanto internos (dentro del equipo) como externos (con el cliente y partes interesadas).

Generar datos del proyecto (acerca de costes, calendario, progreso técnico y de calidad) para reportar sobre su estatus y realizar previsiones.

Documentar las peticiones de cambios y adaptar los cambios aprobados al plan de proyecto o proponer y actualizar los planes.

Documentar y resolver las incidencias.

Implantar los cambios aprobados, por medio de acciones correctivas, preventivas o de reparación de defectos.

Gestionar los riesgos e implementar las actividades de respuesta.

Gestionar la relación con los contratistas.

Recoger y documentar las lecciones aprendidas para el futuro.

La evaluación de la infraestructura técnica o tecnológica (hardware, software, comunicaciones, bases de datos, etc.) que incluye las siguientes actividades:

• Evaluación de la infraestructura existente: hardware, middleware, gestores de bases de datos, herramientas disponibles y redes de comunicaciones. Esta actividad incluye el análisis de rendimientos y la compatibilidad con nuevos productos y aplicaciones.

• Evaluación y selección de nuevos productos (si corresponde). Normalmente, algunas o todas las capas y componentes de un sistema de inteligencia de negocio complejo necesitan una inversión adicional de los componentes anteriores y, sobre todo, de las aplicaciones que compondrán el nuevo sistema. Esta es una decisión compleja, que requiere de la involucración del departamento de IT, pero también de un grupo de usuarios y directivos.

Arquitectura técnica de un sistema de inteligencia de negocio

Fuente: modificado de Loss y Atre (2003)

La evaluación de la infraestructura no técnica o funcional (procesos de gestión, calidad de los datos, uso actual de sistemas de gestión de la información, políticas internas, estándares de aceptación, etc.). Podríamos decir, parafraseando a Thomas Davenport, que la inteligencia de negocio es “otra forma de vida”. La manera como se han diseñado y construido las aplicaciones, basadas en silos departamentales (incluso en el mundo de los ERP y las bases de datos comunes), no sirven ni están preparadas, por regla general, para una visión integrada, transversal y multidimensional del negocio. La evaluación de la infraestructura no técnica es, por una parte, una revisión del mundo de partida y, por la otra, un análisis del gap o diferencia con el modelo futuro que necesitamos construir. Este análisis incluye revisar los siguientes aspectos:

Procesos de servicio y acuerdos de niveles de servicio de las aplicaciones.

Funciones de soporte y asistencia al usuario.

Procesos de comunicación y resolución de conflictos.

Refinar el análisis de requerimientos realizado en las fases anteriores, en particular los que afectan a los datos, la funcionalidad (informes y queries) y la infraestructura (técnica y no-técnica, en el sentido presentado anteriormente).

Determinar el estado de las fuentes de datos: archivos y bases de datos existentes en el nivel operacional.

Revisar las estimaciones de coste en función de lo anterior y del coste de los productos seleccionados. Es importante tener en cuenta los costes de gestión del cambio y de aprendizaje de la nueva organización de usuarios que manejará el BI y del propio departamento de informática.

Revisar el análisis de riesgos realizado en la fase anterior (business case).

Identificar los factores críticos de éxito; es decir, las condiciones que deben darse y sostenerse a lo largo del trabajo para que se puedan cumplir los objetivos.

Definir las necesidades de reporting; es decir, cómo el cliente y los usuarios principales necesitan recibir la información. Este análisis será crucial para determinar el nivel de agregación de datos, el tipo de interrogaciones y la estructura de los universos de datos, pero al mismo tiempo no requiere de una definición detallada, sino más bien estratégica y orientada a las necesidades de información y al uso que hacen de ella los ejecutivos.

Identificar las fuentes de datos. A partir de la recogida y análisis de la información anterior, se deberá establecer con mucho detalle dónde están los datos en origen, examinar su nivel de calidad, cómo se alimentan y hacer una primera evaluación de la necesidad de conversión y transformación.

Establecer un modelo de datos (casi) definitivo. Normalmente, como ocurre con otros requisitos, en esta etapa se debe refinar los modelos de datos de alto nivel que se han construido en etapas anteriores y bajarlos a un nivel de detalle suficiente para establecer las entidades, relaciones y atributos necesarios para la preparación del prototipo y para el posterior diseño del sistema.

Definir los acuerdos de niveles de servicio (preliminares). Normalmente, el personal técnico puede pensar que no hace falta hacerlo tan pronto, pero frecuentemente es una red de seguridad para la definición de la infraestructura técnica y no técnica del proyecto y un criterio de aceptación para los propios usuarios. Son criterios o ANS de disponibilidad, tiempos de respuesta, seguridad, calidad de los datos, soporte al usuario... También aseguran, y no es de menor importancia, la involucración en el proyecto de los responsables de la infraestructura técnica de IT desde el principio.

Establecer las necesidades de ampliación o cambios en la infraestructura técnica; es decir, qué componentes (hardware, software, comunicaciones, gestores de bases de datos, aplicaciones...) se deben extender o modificar para alcanzar los objetivos del proyecto. Sería de algún modo el análisis de lo que tiene que ser (to be) frente al análisis de lo que hay (as is) y la determinación de la diferencia (gap). En algunas metodologías, de hecho, se determina primero la situación to be y se compara con la as is, especialmente si se trata de la implantación de soluciones estándar que determinan u obligan a cierta clase de requisitos técnicos.

Establecer los requisitos de ampliación o cambios en la infraestructura “no técnica”; es decir, las políticas, procesos y metodologías de gestión del proyecto en la actualidad y, eventualmente, del sistema en el futuro. Lo más específico es establecer las normas de funcionamiento del equipo de trabajo y sus diferentes roles y responsabilidades, lo cual, como hemos dicho, no es nada obvio en los proyectos de inteligencia de negocio.

Revisión del alcance y la planificación del trabajo. Aquí es donde vienen muchas veces las sorpresas. Cuando se baja a este nivel de detalle es cuando se puede saber con precisión si es asumible el alcance inicial y si la planificación es realista, y proponer los cambios de alcance, tiempo y esfuerzo oportunos. Debe hacerse aquí, luego puede ser demasiado tarde.

Naturaleza del problema u oportunidad del proyecto (qué se debe solucionar) y nivel del daño, riesgo o beneficio para la empresa.

Por qué este problema necesita resolverse con una solución de inteligencia de negocio y no con otras soluciones tradicionales (por ejemplo, informes extraídos de la aplicación transaccional) y cómo un sistema BI solucionará el problema.

Requerimientos de información, análisis y presentación de cada área afectada.

Requerimientos priorizados y detallados de los datos que se requieren para proporcionar esa información, dónde se encuentran y con qué nivel de calidad.

Requerimientos de depuración (“limpieza”) y conversión de datos.

Requerimientos históricos (desde cuándo).

Aspectos de acceso y seguridad.

Niveles de servicio requeridos.

Construcción de un modelo lógico normalizado de datos, basado normalmente en un diagrama de entidad-relación. Debe establecer identificadores únicos de todos los datos y su definición y atributos. Se puede decir que este es un producto “técnico”.

Identificación de los metadatos. Descripción de los datos específicos de negocio (los que usarán los ejecutivos y usuarios): nombres, definiciones, relaciones, tipos, dominios (áreas o aplicaciones) de la empresa y (muy importante) quién es el propietario de los datos, de su calidad y mantenimiento. Se puede decir que este, a pesar de su nombre, es un producto “de negocio”.

Reglas de depuración de la información, que permitirán realizar la conversión de datos de forma segura e integral. Este documento se usará más tarde para el diseño de las ETL.

Establecer los requerimientos del repositorio; es decir, el nivel de detalle, el tipo de documentación, la manera de guardarla y el encargado de su mantenimiento. También se deben establecer los requisitos de acceso y seguimiento.

Establecer los procesos y herramientas de integración del repositorio con otras aplicaciones o fuentes de documentación, frecuentemente muy variadas y heterogéneas. De hecho, es bastante habitual que el repositorio se construya manualmente y sea una colección de documentos heterogéneos.

Crear el modelo lógico y sus relaciones con el modelo físico de datos.

Crear los meta-metadatos. Algunos autores y practicantes defienden que los metadatos tienen dos niveles de detalle: uno más general, con una visión útil principalmente para el negocio, y una visión más detallada, útil principalmente para el departamento de IT. Esta última está formada por los meta-metadatos.

Identificar el nivel de detalle de la información que se necesita; es decir, el BI no puede ser una copia de las bases de datos operacionales. Alternativamente, y es una importante decisión de diseño, se pueden tener dos bases de datos: una con información agregada y otra con información desagregada.

Identificar el tipo de acceso que requerirá la mayoría de los usuarios. Lo normal es que la gente prefiera un análisis multidimensional basado en cubos y con un nivel de agregación alto, pero recientemente, y para determinados analistas de grandes masas de datos, es preferible un acceso más abierto basado en modelos de entidad-relación y con un mayor nivel de granularidad.

Cabe recordar que el BI no puede sustituir ni inventar ni manipular (modificar) datos que no proceden de los sistemas operativos. Muchos proyectos fracasan por esta causa: intentar inventar o resolver en el BI lo que no está resuelto en el nivel de las operaciones.

Revisar los requisitos de acceso y análisis de los datos, a partir de la información del análisis y, en particular, después de probar los prototipos.

Determinar los requisitos de agregación y sumarización de datos, de acuerdo con el líder de negocio y evitando el fenómeno de “explosión” de datos (incluir datos “por si acaso”).

Diseñar las bases de datos objetivo, de acuerdo con los criterios y decisiones anteriores, que debería tomar el líder de negocio, no el técnico y mucho menos el jefe de proyecto.

Establecer las estructuras físicas de la base de datos (clusterizar, particionar, indexar, etc.), de acuerdo con las decisiones adoptadas anteriormente. Insistimos: son decisiones de uso y conveniencia del usuario, no decisiones de eficiencia y elegancia técnica de la base de datos.

Crear un documento de mapeo de la relación entre las fuentes de origen de los datos y los datos objetivo, y describir los procesos de transformación.

Probar la funcionalidad de la herramienta, para asegurar que puede hacer lo que realmente se pretende que haga, y la necesidad de complementar la funcionalidad con código adicional.

Diseñar el flujo de ETL, de la forma más sencilla, trazable y rápida posible. Lo ideal es dividir el flujo en partes más pequeñas que no actúen en serie, sino en paralelo.

Diseñar los programas de ETL, particularmente la carga inicial de datos. Lo histórico y lo nuevo ya vendrán después.

Establecer la infraestructura técnica donde residirán estos procesos y herramientas, deseablemente un servidor separado y único.

Decidir la estrategia (comprar/hacer) a partir de los resultados de la fase de análisis y, si es el caso, seleccionar la herramienta.

Refinar el diseño de la base de datos del repositorio; decidir sobre los formatos de los documentos y establecer los procesos de documentación, mantenimiento, control de versiones, back-up y recuperación. Normalmente, esta es una actividad alternativa o complementaria a la anterior, ya que es muy diferente trabajar sobre la funcionalidad que ofrece un producto o realizar un desarrollo propio.

Instalar el producto (o productos, si se ha decidido probar varios).

Diseñar el proceso de migración de metadatos. Frecuentemente, esta migración consistirá en trasladar los diccionarios de datos existentes en otras bases de datos operacionales al repositorio del BI.

Diseñar las aplicaciones de interfaces, informes, soporte, etc., que normalmente también variarán mucho en función de la estrategia de “comprar” o “hacer” y de los productos elegidos.

Modelo físico de metadatos. La elección del modelo de presentación y documentación.

Lenguaje de definición de datos (DDL). La colección de instrucciones de interrogación y búsqueda (SQL) que permite al repositorio recuperar los datos de las bases de origen.

Lenguaje de control de datos (DCL). Lo mismo relacionado con el control de acceso y seguridad.

Especificaciones para la programación o configuración del repositorio de metadatos.

Por más que se hayan desarrollado las herramientas y soluciones de mercado, ya sean soluciones integradas o soluciones específicas para esta capa, difícilmente cubren todos los requerimientos de tratamiento de datos de usuarios muy exigentes pero que no siempre tienen el conocimiento y la dedicación. También es frecuente que cosas que fueron aceptadas en el análisis, o incluso en el prototipaje, puedan cambiar en la fase de construcción. Esto conduce a mayores tiempos y esfuerzo en realizar desarrollos a medida que tienen que completar la funcionalidad del producto estándar.

Por más que se haya hecho un esfuerzo en el análisis para establecer los procesos de transformación y conversión de datos y por crear un vocabulario común, es frecuente que en esta etapa aparezcan dudas o discrepancias y hay que estar preparado para un mayor esfuerzo de diálogo con los usuarios finales, para pedir un mayor liderazgo y patrocinio directivo pero también, inevitable, para un esfuerzo técnico de reconciliación con los datos de origen en su totalidad y en el detalle. Las decisiones sobre el nivel de detalle, ya lo dijimos, son cruciales. En la planificación y la gestión de esta etapa no hay que subestimar el esfuerzo de transformación de datos.

Igual ocurrirá, como consecuencia de lo anterior, con la limpieza o depuración de los datos de origen. Si vamos hacia atrás, descubriremos ahora procesos de entrada de datos y de tratamiento de los mismos en el nivel operacional que no encajan con el diseño de los procesos de carga y transformación que necesitamos o hemos previsto para el BI.

Informes estáticos y dinámicos.

Queries (preguntas al sistema).

Análisis multidimensional mediante cubos OLAP.

Minería de datos.

El entorno de acceso y presentación.

Establecer las fases para la puesta en marcha, con un primer modelo de metadatos, que luego se puede extender e irse poblando paulatinamente.

Automatizar lo más posible la creación del repositorio.

Construir las interfaces, que contengan sistemas de avisos, de manera que la carga sea lo más mecánica posible.

Hacer pruebas, como de todo lo demás, aunque normalmente no tienen por qué ser tan exhaustivas como las de la ETL ni tan continuas como las de las aplicaciones de usuario.

Asignar un responsable (o un equipo de responsables) del subproyecto y de su mantenimiento futuro perteneciente a la compañía cliente. Este equipo debe tener personal técnico y personal de las áreas de negocio.

Preparar y proporcionar un plan de formación. La formación debería ser más práctica que teórica y bastante personalizada: como en otros temas del BI, cada tipo de participante necesita un tipo diferente de formación.

No subestimar el tiempo y esfuerzo requerido y no recortarlo. Una regla sacada de la experiencia es que por cada día de código hacen falta tres días de pruebas.

Planificar las pruebas y los juegos de pruebas, en particular las pruebas de aceptación de usuario en un entorno operativo. Normalmente será un proceso iterativo, o sea, habrá que probar varias veces, y eso también debe planificarse.

La gestión de configuraciones y versiones también es iterativa y debe planificarse adecuadamente: no es opcional y no caben ahorros.

Si se está trabajando con herramientas o aplicaciones de mercado, es bueno probarlas antes y probar sus componentes.

Si se está trabajando con una parte de código grande y complicado, es bueno establecer sistemas de revisión interna y peer reviews.

Preparar un entorno de pruebas, que puede ser el entorno de prototipos (si se tiene, por ejemplo para las aplicaciones de usuarios) o el entorno de control de calidad (si se tiene) o un entorno de preproducción. Las pruebas no se deben hacer en desarrollo y mucho menos en producción.

Planificar y dirigir cuidadosamente las pruebas de usuario son el mejor escenario para conseguir la aceptación del proyecto, el uso del sistema y la transferencia de conocimiento. Es también un espacio para la formación inicial.

Usar herramientas automáticas de realización de pruebas aumenta la precisión y reduce los costes.

En proyectos de BI, aún más que en otros, las interfaces, la conversión de datos y la carga de información histórica son especialmente críticos y complicados. No es mala idea tener un plan de migración separado y un juego de pruebas diferenciado.

En grandes proyectos de BI, incluso más que en otros, una buena aproximación para la puesta en marcha es librarlos por fases y/o establecer una puesta en marcha inicial que se pueda experimentar en un entorno de menos riesgo o más tolerancia y luego hacer las extensiones (roll-outs) poco a poco.

Empezar pronto. Insistimos, probar lleva tiempo y esfuerzo. El sistema de prototipos desarrollados y usando datos reales, realizado con frecuencia, ahorra tiempo y dinero. Si hacemos las pruebas unitarias y algunas pruebas de integración, solo nos quedarán para el final las pruebas de rendimiento y las del entorno completo (que no es poco).

Pruebas unitarias de cada programa o módulo: funcionalidad, compilación y detección de errores.

Pruebas de integración: o sea, de los flujos e interacciones entre módulos o partes.

Test de regresión: son los que se hacen después del test original y de haber detectado fallos. La reprogramación puede provocar nuevos fallos difíciles y caros de detectar, por lo tanto, es bueno guardar el primer test y probar solo lo nuevo y, luego, volverlo a probar todo junto.

Test de rendimiento. Por el volumen y complejidad de los datos, por las dificultades de diseño del ETL y porque no son cosas que se deban ir probando sobre la marcha en forma de prototipos, los rendimientos de un sistema BI son una caja de sorpresas. Es aconsejable, de nuevo, hacer varios test de simulación por fases, siempre en un entorno de pruebas, o de control de calidad, o de preproducción.

Test de calidad. El proyecto debería haber definido los criterios y procedimientos de calidad en las primeras fases de lo que llamábamos “infraestructura no técnica” del proyecto y aplicarlos ahora. En los últimos años se han ido estableciendo estándares de calidad de mercado por el IEEE, por las normas ISO u otros.

Test de aceptación de usuario (UAT). Si se dispone de diferentes entornos, se puede mantener un entorno de pruebas de usuario por separado, mientras se realiza el resto de las pruebas. Como siempre, mientras más haya trabajado el usuario con los desarrolladores o implantadores en las diferentes fases del proceso, menos dramáticas serán las UAT. Igual pasa en el ciclo completo de pruebas; si el usuario ha participado o conocido las pruebas unitarias y las pruebas de integración, se habrá ido familiarizando con el sistema y las pruebas serán más cortas y rápidas.

Test de funcionamiento en operación. Esto se hace poco. En realidad, el sistema solo funciona y funciona bien si el usuario lo usa y obtiene los resultados que quiere con la calidad que los quiere. Los contratos, planes de trabajo y planes de pruebas deberían tener una sección separada de test operativos a realizar algunas semanas o meses después de la puesta en producción del sistema.

El uso del sistema por los usuarios de diferente perfil para los cuales se diseñó.

La explotación y mantenimiento técnico ordinario por parte de los servicios de informática de la empresa.

Realizar el plan de implantación: quién, cómo, dónde, cuándo y por qué se hacen las cosas de una manera y no de otra.

Establecer el plan de transporte y traslado a producción, de acuerdo con las políticas de infraestructura no técnica de la organización o las que se hayan definido para el proyecto.

Establecer el plan de acceso y seguridad. Normalmente es una parte de lo anterior, pero en proyectos de BI grandes y, sobre todo, la primera vez, es importante que estos aspectos tengan un tratamiento suficiente y separado.

Instalar (instalación técnica) las aplicaciones del sistema en el entorno de producción.

Establecer los calendarios de operación; es decir, cuándo se cargarán y refrescarán los datos y se realizarán, si es el caso, las explotaciones que representan mayor carga de trabajo y/o que tienen que estar sujetas a unos calendarios fijos (por ejemplo, la información de cierre del mes para el comité de dirección).

Establecer el plan de soporte a usuarios y los niveles de servicio del plan en el momento del arranque.

Establecer el plan de formación y transferencia de conocimiento al personal técnico y no técnico.

Establecer las operaciones de cierre y aceptación final del trabajo.

Establecer el plan de soporte ordinario a usuarios y la estructura organizativa y procesos de gestión del sistema.

Es preferible una aplicación parcial de alta calidad en funcionalidad y datos que un sistema completo con muchos defectos y datos erróneos.

Cada versión debería tener un número reducido de entregables de pequeñas dimensiones.

Deberían entregarse nuevas versiones con nuevos datos y funcionalidades para nuevos usuarios cada 3 a 6 meses.

La primera release durará más y debe incluir la infraestructura técnica y no técnica, la máquina de ETL y el primer repositorio de datos. Debe incluir también algunos informes de datos básicos.

Ser realistas y no generar expectativas que no se puedan cumplir. Este plan debe ser comprendido y compartido por los responsables de negocio.

Negociar los ritmos de implantación y entrega bajo la autoridad del comité de dirección de la compañía, la dirección general o un líder de negocio con autoridad y delegación suficiente. Todo es negociable si se hace explícito: alcance, esfuerzo, calendario...

Cada release debe incluir su repositorio de metadatos, si se pretende que el sistema sea sostenible.

En esta clase de procesos, el desarrollo de nuevas aplicaciones puede ser muy flexible, basado en prototipos y en una relación directa y estrecha entre el usuario y el desarrollador o implantador (con una filosofía similar a la del desarrollo “ágil”).

La ampliación de alcance o la aparición de nuevos requerimientos y cambios debe ser gestionada y evaluada por el patrocinio de negocio, el comité de dirección del proyecto o un órgano de arbitraje y control de cambios. Si los errores o cambios son pequeños, pueden entrar en la release actual. Si son grandes, es mejor dejarlos para la próxima release o introducirlos en el programa global para ser revaluados.

Preparar la revisión.

Preparar la documentación a revisar.

Organizar la reunión o reuniones de revisión.

Celebrar la reunión o reuniones de revisión.

Redactar un documento de conclusiones, lecciones aprendidas y una lista de acciones a implantar.

Realizar un seguimiento.