Toma de requisitos para la creación de sistemas de BI

Toma de requisitos para la creación de sistemas de BI

Un pilar fundamental en cualquier tipo de proyectos, y en especial en la creación de sistemas de BI, es la toma de requisitos. Durante él hay que obtener las necesidades de los usuarios del sistema a construir. Para llevar a cabo este proceso debemos de seguir una metodología que nos guíe y ayude durante todo el proceso, que básicamente consiste en entrevistar a los actores del sistema, entender sus necesidades y plasmarlas en la documentación, para a partir de ahí diseñar y desarrollar un sistema de BI que responda a las necesidades de dicha empresa.

En nuestro caso lo haremos en base a pequeños y continuos ciclos de desarrollo con entregas al usuario para su validación y uso.

A continuación tenéis una imagen muy descriptiva de la problemática ocasionada por una mala toma de requisitos y que en todo momento debemos evitar:

Toma de requisitos para la creación de sistemas de BI

En general, en toda toma de requisitos debemos tener claro que nuestro objetivo es plasmar tanto los requisitos funcionales como los no funcionales, de cara a un correcto desarrollo del sistema y éxito final del mismo. Deberemos diferenciar, por tanto, entre los funcionales (aquellos que describen aquello que el sistema ha de ser capaz de hacer) y los no funcionales (aplican a las limitaciones que puedan aplicar al sistema, como por ejemplo tecnología a utilizar, tiempos de respuesta, seguridad, escalabilidad, etc.).

En este apartado nos centraremos en describir en primer lugar los pasos a tener en cuenta para obtener toda la información relevante a nuestro sistema, y posteriormente, cómo plasmarlo en un documento de toma de requisitos adecuadamente.

Obtención de requisitos

Como punto de partida, nos encontraremos en nuestro sistema de BI con el primer paso a dar en cualquier proyecto que aspire a tener éxito. Será la piedra angular del proyecto, y se puede resumir en conocer nuestro negocio. Un buen lugar para comenzar, por tanto, será analizando el negocio de cara a la toma de requisitos, mediante el acercamiento a los usuarios de negocio implicados en el proceso final. Sólo así lograremos tener claras cuáles son las necesidades pasadas, presentes y futuras (en la medida de lo posible) de cara a que el nuevo sistema las resuelva del mejor modo posible.

Una estrategia a seguir, de cara a plasmar esta etapa inicial de la toma de requisitos, sería por tanto recopilar esa experiencia de usuario de negocio y tratar de reflejarla, por ejemplo, mediante mapas conceptuales.

Toma de requisitos para la creación de sistemas de BI

Por ejemplo, en la figura 0-2, podemos observar cómo se ha detectado que a partir de un conjunto de datos base, se quiere extraer una serie de informes (bien nuevos, bien replicar y optimizar informes ya existentes) con unas condiciones de acceso concretas (por ejemplo, podríamos tener una biblioteca de informes en un SharePoint corporativo) y con información actualizada en un plazo determinado (esto determinará la ventana de tiempo que tenemos para manejar los datos). Estaríamos reflejando aquí tanto requisitos funcionales como no funcionales.

No es el objetivo del presente texto profundizar en las técnicas de toma de requisitos.

Como comentábamos, es importante hablar con los usuarios, en plural, ya que habrá que identificar si no a todos ellos, al menos todos los perfiles de usuario que va a tener el sistema. Habrá representantes de diversas áreas de negocio (por ejemplo Control de Gestión, Recursos Humanos, etc.) y dentro de cada una distintos roles que adoptan, que requieren de un uso determinado del sistema (habrá quien necesite un informe cada 24 horas como comentábamos en el ejemplo, otros cada 2 horas de otro aspecto en concreto…). Es por ello importante identificar y representar los perfiles de usuario. Es decir, qué tipo de usuario vamos a tener presente en el sistema (quién genera la información, quién la va a consumir, nivel de conocimientos que tienen de las herramientas, etc.).

Otro de los aspectos en que nos pueden ayudar estas reuniones con los distintos actores implicados, es a conocer la nomenclatura que se utiliza para cada perfil de usuario. De este modo, se podrá plasmar el requisito, y la futura implementación, con términos amigables, con los que están familiarizados, que sean sencillos de utilizar y permitan explotar con facilidad el dato. Por ejemplo, deberemos ser capaces de determinar si lo que para un usuario es un «empleado» y lo que para otro es un «recurso», son equivalentes. O por ejemplo, cuál es la fórmula acertada para calcular el beneficio neto. Estas y otras muchas dudas pueden surgir, especialmente cuando se trata de un entorno con muchos usuarios implicados, pertenecientes o no a una misma área.

Procesos de negocio, Data Mart, Data Warehouse

A partir de los modelos de negocio, seremos capaces de identificar las necesidades concretas iniciales del sistema, como puedan ser informes estáticos a determinadas horas, informes dinámicos en el momento de consulta, aplicaciones analíticas, consultas ad-hoc…, pero siempre centrados en el objetivo de lograr un repositorio de datos que pueda ser explotado de todas esas formas y métodos. Hablamos de lograr construir un Data Mart, que podemos entenderlo en su forma más sencilla como un repositorio de información de uno de los procesos de negocio de la organización. Una organización constará de varios procesos de negocio y, por ende, de varios Data Marts, que conformarán un Data Warehouse, de tal modo que se cubran la mayoría de los procesos para lograr responder adecuadamente a las consultas de información que realizarán los usuarios.

Podemos entender un proceso de negocio como un conjunto de tareas que son aplicadas en un marco común para obtener un resultado útil para el negocio. Las tareas pueden abarcar desde ventas o compras a solicitudes o envíos, movimientos de stocks, procesos financieros, etc. en general son tareas que suceden en el tiempo, por lo que podríamos equipararlas con eventos de negocio.

Para evaluar dichos procesos de negocio, tendremos dos posibilidades. Realizar un análisis cuantitativo de los mismos (por ejemplo evaluar costes, beneficios, presupuestos, etc.) o cualitativo (estados, descripciones, fechas, clientes…). Es importante determinar qué aspectos querremos evaluar en nuestro proceso ya que definirá en gran medida el resultado del proyecto. Para ello, lo más recomendable es dividir el proceso en tareas, y para cada una de ellas, identificar por una parte los eventos cuantificables y aquellos que son cualificables. Los primeros normalmente los encontraremos al formular una pregunta del tipo «¿Qué queremos medir?», mientras que los segundos los encontraremos al preguntar «¿Por qué aspecto de negocio quiero analizar lo medido?».

Es recomendable a la hora de diseñar un sistema de estas características, ser proactivo con respecto a las necesidades que puedan darse en el futuro. Por ejemplo, si disponemos de una serie de facturas, y el único interés de negocio actual fuese conocer los gastos distribuidos por fecha, un aspecto cuantitativo sería el volumen de gastos, y un aspecto por el que cualificar sería la fecha. Sin embargo, podríamos ir más allá y proponer (o simplemente prever) un posible análisis por proveedor, tipo de gasto (interno/externo), etc., ya que en un sistema de BI usualmente mediante estas acciones descubriremos un potencial extra para nuestro sistema.

Veamos un ejemplo:

Toma de requisitos para la creación de sistemas de BI

En el ejemplo de la figura 0-3, vemos cómo hemos descompuesto el proceso de Ventas en tres tareas distintas: pedir, enviar, facturar. Para cada una de ellas, hemos
identificado varios elementos que pueden sernos de utilidad cuantificar, y otros por los que cualificar. Así, por ejemplo, podríamos ya saber que vamos a querer información de las cantidades facturadas por fecha.

Nos encontraremos, sin embargo, con el problema que introducíamos antes, y es el de la terminología. Un departamento quizá considere que un importe facturado responde únicamente a lo ya facturado, mientras que otro departamento quizá considere el conjunto de lo facturado más lo pendiente de facturar. Es por ello que se ha de recoger unos datos maestros y sus definiciones, y llegar a un consenso con los jefes de departamento para unificar criterios o, en caso de desacuerdo, seguir las reglas del departamento de mayor peso en nuestro negocio.

Es muy importante que las reglas y definiciones acordadas queden plasmadas en los requisitos, ya que será en base a ello en torno a lo que se construirá el sistema.

Elección del proceso de implementación

Habiendo registrado las necesidades de los usuarios en forma de requisitos, se ha de definir igualmente al modo en que se realizará la implementación del sistema. Tenemos varias opciones:

  • Opción 1: Implementar todos los procesos de negocio a la vez. En base a todos los requisitos de todos los procesos de negocio, estructuraremos el desarrollo para crear un modelo bien diseñado que refleje todos los aspectos a analizar. Se trata de un desarrollo de tipo Top Down.
  • Opción 2: Crear un Data Mart completo e independiente por cada departamento. Se tomaría en cuenta los requisitos de cada área por separado, implementando así un sistema que satisface unas necesidades puntuales de una forma más rápida. Es el desarrollo de tipo Bottom Up.
  • Opción 3: Realizar un desarrollo incremental teniendo en cuenta los elementos comunes. Nos encontramos ante un escenario de tipo Híbrido, donde no se satisfarán todas las necesidades de todas las áreas al tiempo, sino que se partirá de todos los elementos comunes para construir una base a la que ir añadiendo especificaciones.

Toma de requisitos para la creación de sistemas de BI

Como podemos ver en la figura 0-4, dependiendo de las necesidades de negocio (tiempo en obtener dato, interés particular por una determinada área o proceso de negocio, etc.) podremos trazar las líneas del proceso de implementación de nuestro sistema de BI. Podemos ver un ejemplo en la figura 0-5, donde vemos una distribución de los distintos Data Marts a implementar (en las filas), y los distintos aspectos de negocio por los que queremos analizar (en las columnas). Marcados con X aparecen las ocurrencias en que un determinado proceso de negocio se analiza por un aspecto de negocio. También podemos ver un reparto de las tareas por fases, de cara a un desarrollo incremental, donde el orden puede determinarlo como comentábamos desde la generalidad de sus aspectos de negocio (Ventas por ejemplo analiza por Fecha, Campañas, Consultoras y Producto) hasta la urgencia de la obtención de la información. Esta forma de representar la información la llamaremos Bus Dimensional.

Toma de requisitos para la creación de sistemas de BI

Con este paso ya tendremos identificada toda la funcionalidad requerida, así como la metodología de trabajo que se desea seguir para acabar finalmente con nuestro sistema BI implementado con éxito.

Requerimientos no Operativos

No podemos olvidar los requisitos no operativos, aunque algunos de ellos están más ligados a otros departamentos (TI, diseño, legal, etc.) que pueden también ser determinantes en la consecución de nuestro sistema. Los introdujimos al mencionar, por ejemplo, el tener un tipo u otro de interfaz de acceso. Algunos de los más importantes que debemos tener presentes son:

  • Conformidad Legal (Compliance). El sistema deberá cumplir con las regulaciones propias del estado y organización en que se desarrolle.
  • Calidad de Datos. Además de asegurar que los datos no sufren distorsiones y son confiables, también querremos proporcionar unas características de disponibilidad, integridad y eficiencia que proporcionen una experiencia satisfactoria al usuario.
  • Se debe contemplar quién estará autorizado a consultar la información y a través de qué medios.
  • Integración de Datos y Archivo. Se definirán los diversos orígenes y cómo acceder a los mismos, así como el sistema en que se implementará el BI.

o Requisitos tecnológicos. Se deberá definir qué entorno servirá para alojar el sistema, y qué tecnología y versión serán las escogidas para llevarlo a cabo.

  • Linaje de Datos. Siempre es recomendable contar con un sistema de auditoría (por ejemplo metadatos -datos sobre los propios datos-) que proporcione una vía de hacer seguimiento de la vida del dato.
  • UI (Interfaz de Usuario) de cliente final. Definiremos cómo se va a consumir la información, si se querrán informes, acceso mediante algún programa generalista tipo Excel, u otras vías de presentación.
Alcance

Hasta este punto hemos visto qué elementos debemos considerar para poder construir nuestro sistema BI. No obstante, hay que tener muy presente que también deberemos haber reflejado en nuestra toma de requisitos otros aspectos que se han decidido dejar de lado en esta implementación, o que simplemente una indefinición pueda provocar un problema futuro. Un caso común sería remarcar que los datos sólo estarán disponibles a partir de una fecha determinada, pero no con anterioridad. Es por ello muy importante dejar claro qué queda dentro y qué queda fuera del alcance en el documento inicial, que debe ser aprobado por las partes implicadas (generalmente los usuarios de negocio de más alto nivel, así como el equipo encargado del nuevo sistema). Este aspecto que puede parecer trivial inicialmente, puede llegar a ser muy importante si una vez avanzado el proyecto surgen problemas en cuanto a lo que en ese momento se espera de él con respecto a lo que se acordó inicialmente. Es, por tanto, tan importante consensuar qué queda dentro del alcance como lo que queda fuera de él.

Documentación de requisitos

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 (se puede ver un ejemplo en el documento «Sector Seguros – Vision y Alcance.pdf»).

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:

Toma de requisitos para la creación de sistemas de BI

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:

Toma de requisitos para la creación de sistemas de BI

También es recomendable incluir el Bus Dimensional (ver Figura 0-5 Bus Dimensional).

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 estudiará a fondo en un tema 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. En el documento «Sector Seguros – Vision y Alcance.pdf» puede un ejemplo.

Publicaciones Similares