En las entregas anteriores de esta serie hemos hablado de como definir los requisitos de nuestro sistema BI y de como acometer su diseño centrándonos en los distintos procesos de negocio. En esta entrada hablaremos de algo no menos importante, y que en muchos casos no se acomete con la seriedad que merece.
Documentando requisitos de una solución de Business Intelligence
En el punto Obtención de requisitos hemos visto qué vamos a querer plasmar, veamos ahora cómo hacerlo. Existen muchas formas de reflejar los requisitos, que se complementan y apoyan entre sí, pero en este caso nos vamos a centrar en la generación de un documento de visión y alcance.
Para estructurarlo, podríamos basarnos en el siguiente esquema:
Portada. Emplazaremos el título del proyecto, dejando claro que se trata de un documento de visión y alcance, así como la versión y autor del mismo.
Control de versiones. Insertaremos una tabla que registrará qué cambios ha sufrido el documento, quién y cuándo se han llevado a cabo.
Índice de contenidos. Una guía rápida de navegación del documento.
Introducción. Breve descripción del propósito del documento y del proyecto. Podremos incluir información acerca de la situación actual (punto de partida), Visión (meta a lograr) y un Análisis de beneficios (qué esperamos mejorar).
Solución conceptual. Crearemos un espacio en el que describir aquellos requisitos que hemos recopilado, desglosándolos según las categorías que consideremos oportunas. Por ejemplo podríamos incluir una sección que reflejase los objetivos generales, a nivel de los distintos usuarios que van a consumir la información, según lo que esperan cada uno de ellos. Podríamos contar con la visión esperada de un usuario de negocio avanzado y la de un usuario final con menos necesidades de información. También reflejaremos los objetivos desglosados por fases, si así se ha decidido llevar a cabo la solución, de cara a poder asociar qué elementos se verán afectados en qué momentos del tiempo.
Mostraremos en esta sección la arquitectura (a alto nivel) propuesta de la solución. Esta arquitectura podrá reflejar:
- Una descripción de cada uno de los orígenes de datos (bases de datos, archivos de texto, etc.).
- Una descripción de los procesos de ETL (Extracción, Transformación y carga -Load en inglés-) esperados. Cómo y dónde acceder a cada uno de los orígenes de datos, así como posibles reglas de negocio a aplicar en cada uno de ellos. Por ejemplo, ficheros Excel almacenados en una biblioteca SharePoint, unos ficheros en formato CSV en un recurso de red compartido, una base de datos relacional SQL Server, otra Oracle, etc..
Incluiremos una breve descripción del tratamiento de datos que haremos y las bases de datos que utilizaremos. Un ejemplo de dicha descripción (muy simplificado) sería: “Se utilizará la herramienta ETL SSIS (SQL Server Integration Services) para leer los distintos orígenes (Pólizas, Agencias, CRM, RRHH), tratarlos y almacenarlos en una base de datos relacional de Staging (un área intermedia), donde nuevamente con SSIS entrelazaremos la información para consolidarla en la base de datos relacional del DWH (Data Warehouse). Finalmente, una base de datos multidimensional leerá de nuestro DWH y será objeto de consultas para los usuarios a través de la herramienta Microsoft Excel y de informes de Reporting Services. La representación gráfica de dicha arquitectura la podemos ver en la siguiente figura:
Nota: Si nuestro perfil es de usuario de negocio, nos apoyaremos en el departamento de TI para que sean ellos los encargados de definir dicha arquitectura y entregarnos la documentación correspondiente.
Describiremos aquí los Requisitos obtenidos a lo largo de las reuniones con cada parte implicada con más detalle. Incluiremos los requisitos funcionales y los no funcionales. Una posible forma de organizarlo es describiendo el listado de requisitos en esta sección, y apoyarnos de secciones del tipo “Anexo” para adjuntar los posibles diagramas que hayamos realizado de los mismos (casos de uso, secuencia…). Debe quedar especificado con el mayor detalle posible todo lo relacionado con el proyecto, para facilitar un arranque exitoso del mismo.
Es recomendable incluir, bien en el documento bien en modo de “Anexo”, aquellos elementos que puedan ayudar en la implementación o que apoyen a los requisitos para la consecución del objetivo. Por ejemplo, si el sistema pretende reemplazar un conjunto de informes, podríamos adjuntarlos a nuestra toma de requisitos, junto con un ejemplo de la interfaz y visualización que se desea para la nueva solución. Así, se podría contar con una serie de gráficas de ejemplo que sirviesen de referencia a los informes-objetivo a generar, como podemos ver en la siguiente figura:
También es recomendable incluir el Bus Dimensional (ver entrega anterior).
Describiríamos así los distintos procesos de negocio identificados, los elementos que queremos analizar en cada uno de ellos, y los elementos por los que queremos realizar dicho análisis. Asimismo, incluiríamos las definiciones acordadas para cada dato, de modo que se genere una información consistente para toda la organización. Este aspecto lo vimos anteriormente relacionado con la importancia de la nomenclatura.
Alcance. Describiremos qué puntos cubrirá el desarrollo, sin extendernos demasiado, pero tratando de ser concisos y de evitar ambigüedades. Pudiera ser que hayamos detectado requisitos deseables, pero no necesarios, que se haya decidido no incluir en la implementación.
Fuera de alcance. Incluiremos en esta sección aquellos puntos que pudieran generar duda y que quedan fuera de la solución prevista. Pudiera ser, por ejemplo, una restricción en cuanto a ciertos orígenes de datos no automatizables, o ciertos requisitos que se haya decidido no llevar a cabo pese a haberse detectado en la toma de requisitos, por ejemplo, por falta de tiempo o de presupuesto.
Diseño preliminar del modelo dimensional. El documento de visión y alcance lo podremos completar, conforme tengamos más estables todos los requisitos y hayamos comenzado con el modelo dimensional, con una versión preliminar del modelo diseñado. Incluiríamos un detalle de las estructuras a utilizar y los cálculos empleados, así como una representación gráfica del modelo que hayamos decidido utilizar. Podemos incluir varias subsecciones para representar, por ejemplo, los elementos implicados en cada fase de ejecución, si es que se ha acordado seguir una implementación iterativa.
Nota: Aunque el modelado dimensional se verá a fondo en un post posterior, hemos preferido introducirlo aquí para que tenga una imagen global de los elementos que intervienen en la toma de requisitos. Por ahora, simplemente quédese con la idea de qué es y de que es conveniente incluirlo en la toma de requisitos.
Hasta aquí la serie Toma de requisitos para un Sistema BI. Hemos visto como definir los requisitos, pasando por la arquitectura típica de una solución BI, hasta como debería de documentarse esta. En las siguientes entradas abordaremos las herramientas y sistemas para el desarrollo de un sistema BI.
