En la ultima entrada de Toma de requisitos para la creación de sistemas de BI sentamos las bases para la obtención de requisitos de un sistema BI, haciendo hincapié en la importancia de identificar los distintos usuarios finales de nuestro sistema, tanto para entender que necesitan ver en los informes como para saber la frecuencia con la que desean actualizar la información. A continuación nos centraremos en entender, y saber identificar que es un proceso de negocio para poder diseñar de forma adecuada nuestro Data Warehouse.
Procesos de negocio Business Intelligence, 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:
En el ejemplo de la figura, 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 negocio (Business Intelligence) a implementar
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.
Como podemos ver en la figura, 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 tabla mas abajo, 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.
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.
- Seguridad. 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.
- 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.
Hasta aquí la segunda entrada de Toma de requisitos para la creación de sistemas de BI, hemos definido los procesos de negocio y como enfocar el diseño de los distintos Datamarts. Hemos visto que existen diferentes opciones a la hora de enfocar la manera en la que concentraremos la información, bien en distintos almacenes para distintos procesos de negocio o bien en un almacén central de información.
