6. ANÁLISIS DE REQUERIMIENTOS

Cuando la empresa cliente decidió formalizar su proyecto de Business Intelligence con Litebi, se inició el procedimiento rudimentario de toma de requerimientos de las áreas o departamentos implicados en el proyecto. Esta fase es la más importante dentro de la implantación de una solución de BI, ya que, si se falla en este proceso, las posteriores fases no tendrán sentido y obtendremos una solución errónea que supondrá un fracaso para la empresa que lo implanta así como para el cliente. Esta fase es la que establece el rumbo que tomará dicha solución en la empresa.

Unity

Se trata de una tarea meticulosa donde hay que actuar como consultor de estrategia de negocio además de como desarrollador, ya que hay que atender al detalle, a través de sucesivas reuniones con el cliente y/o los departamentos involucrados, sobre las necesidades del cliente, así como analizar los sistemas y métodos de obtención de información que se están utilizando previamente a la implantación de la solución. A partir de esta serie de análisis se diseñará y se implantará una solución acorde a las necesidades del cliente, que muestre toda la información necesaria de manera rápida y sencilla, y en definitiva, que la solución suponga un beneficio en tiempo y dinero para la empresa solicitante.Devonn

Para la toma de requerimientos se determinan diferentes formas de hacerlo. Aunque el objetivo parece similar, el resultado de cada escenario puede ser totalmente diferente. Por ello, nos basaremos en establecer los escenarios comunes a cualquier solución de BI para dicha toma de requerimientos, y tras esto, centrarnos en los puntos específicos del caso concreto que se plantea.

Yaestudio

Cuando se formalizó el proyecto con CECAV, a través de la firma de un contrato, se incluyó una cláusula de confidencialidad, la cual se cita a continuación. Por esta razón, no se presentará ningún dato numérico real que comprometa a la empresa cliente o a Litebi a lo largo del presente documento. La presentación a lo largo del proyecto del resto de datos asociados tanto a las empresas como a la información parcial presentada en la plataforma (se puede considerar la plataforma como tal) queda autorizada tanto por la empresa donde se desarrolló el proyecto como por la empresa cliente (Ver Anexo 2).

“LITEBI” se compromete a mantener la información introducida en la Plataforma Litebi reservadamente, otorgándole a la misma el carácter de estrictamente confidencial, y mantenerla protegida del acceso de terceros no autorizados.

“LITEBI” se compromete a no permitir la copia o reproducción total o parcial de la información que se encuentre en la Plataforma Litebi.

“LITEBI” se compromete a guardar estricta confidencialidad, discreción y cuidado respecto a la información que se encuentran en la Plataforma Litebi.

“LITEBI” se compromete a entregar una copia de seguridad de los datos que se encuentran en la Plataforma Litebi mediante pedido expreso de la empresa contratante.

“LITEBI” se compromete a la destrucción total de los datos introducidos en la plataforma Litebi transcurridos 3 meses de la baja del contrato de servicio “EL CLIENTE” cede en este acto información y secretos comerciales a “LITEBI”, con el fin de que ésta pueda desarrollar el proyecto encomendado.

Asimismo, “EL CLIENTE” autoriza a “LITEBI” para que pueda ceder a su vez la información y secretos facilitados a empresas con quienes tenga acuerdos comerciales, exclusivamente para la ejecución y desarrollo del proyecto contratado.

A la hora de iniciar la fase de la toma de requerimientos es necesario plantearse como punto de partida los objetivos a conseguir con cualquier solución de BI y tener en cuenta los diferentes fallos que se han presentado a lo largo del tiempo a la hora de llevar a cabo un proyecto de BI para no caer en ellos.

En cualquier solución de BI existen una serie de requerimientos genéricos, donde deberíamos plantearnos esta serie de puntos:

• Proveer de un sistema intuitivo y orientado hacia un usuario final con pocos conocimientos técnicos donde éste sea capaz de generar sus propios reportes y análisis: Litebi es una plataforma que cumple estos requisitos, ya que se ha desarrollado siempre pensando en el uso por un usuario (Interfaz Windows) que sea capaz de generar sus análisis de forma sencilla con unos simples clicks de ratón.
• Tener una sola versión de la información: A través de los procesos ETL, la información queda formateada a gusto del usuario final y se presenta siempre actualizada de la misma manera en cualquier ocasión.
• Proveer información de toda la compañía en un solo sistema: En el punto siguiente se presenta el objetivo de integrar tres fuentes diferentes de información dentro de la misma plataforma.
• Que los usuarios puedan acceder a la información desde cualquier lugar y en cualquier momento: Gracias al modelo SaaS de la plataforma esto es posible accediendo a través de Internet.

Cumpliendo dichos objetivos base de cualquier solución podemos plantearnos otra serie de requerimientos a cumplir.

Los requerimientos funcionales son aquellos que marcan la base para tomar decisiones en las posteriores etapas de algunos proyectos de BI. Es muy común que muchas empresas decidan su proyecto de BI en base a las herramientas disponibles. Algunos requerimientos funcionales que deben cumplir las plataformas de BI son los siguientes:

– El sistema deberá proveer la facilidad de drill down, slice and dice, fórmulas avanzadas…etc.: Litebi presenta estas funcionalidades a través de su interfaz y el lenguaje MDX (Ver Anexo 1).

– El sistema deberá tener los mecanismos para controlar la seguridad de los datos por departamento, área o gerencia así como una distribución organizacional jerárquica de la información: Litebi es una plataforma securizada y por medio de los roles se tiene la posibilidad de distribuir la información contenida en la plataforma de forma jerárquica según el cargo y departamento del usuario.

– El sistema proveerá un mecanismo de notificaciones y alertas, con criterios y reglas configurables: Este sistema está por desarrollar (Ver Anexo 1).

– El sistema permitirá la integración de diferentes fuentes de datos: Como se explicará más adelante este es uno de los mayores problemas que arrastra la empresa cliente y con la solución fue posible integrar tres fuentes diferentes de datos en un solo lugar.

Analizando de forma objetiva estos requerimientos podemos observar que la mayoría de plataformas de Business Intelligence en el mercado actual cumplen esta serie de objetivos, aunque esto no es suficiente para que la solución desarrollada cumpla con el objetivo principal que es la de aportar valor al negocio.

Otra vía de toma de requerimientos es la de solicitar al cliente un listado de los datos que requieren sus reportes, o reportes que están sacando actualmente con sus herramientas para conseguir incluir todo lo necesario en la solución para que los usuarios finales puedan realizar los reportes sin problemas.

Los usuarios finales son los que conocen de primera mano su departamento y su área de trabajo, así como los reportes que se andan realizando, por lo tanto, es muy común y entendible que dichos usuarios marquen la pauta de los datos que se requieren y en el formato que los quieren.

Estos datos concretos y ejemplos de informes sobre la empresa cliente se presentan en el apartado 6.3.

Aunque este escenario es importante para que los usuarios dispongan de toda la información necesaria, por sí sola no es una estrategia de toma de requerimientos completa, debido a que el resultado final no sería el aportar un valor de negocio sino una manera de automatizar las tareas de reporting.

Una manera de poder dar valor al negocio es hacer requerimientos que dependan del mismo. Para ello es necesario definir requerimientos donde se establezcan los objetivos de la solución que sean medibles, controlables y confiables.

La toma de requerimientos sobre este escenario puede resultar más compleja que en los casos anteriores, ya que cada decisión debe aportar valor al negocio de manera directa o indirecta según una serie de objetivos:

• Definir la estrategia de negocio en procesos que sean medibles y controlables.
• Identificar la información necesaria para cada proceso de negocio, detallando su forma de análisis, seguimiento, técnicas de análisis, así como requerimientos tecnológicos para su cumplimiento.
• Priorizar los objetivos de la solución en función de su impacto en las metas del negocio.
• Diseñar una administración flexible que permita la adaptación de las estrategias del negocio a corto y medio plazo basado en el aprendizaje continuo de la operación y seguimiento del negocio.

Esta serie de objetivos se cumplieron finalmente estudiando la actividad de la empresa y teniendo como objetivo cubrir una serie de necesidades demandadas, dejando las cuestiones tecnológicas a un lado, ya que gracias al modelo SaaS no fue necesario considerarlas.

Además de tener en cuenta los diferentes requerimientos que se deben tomar a la hora de comenzar la implantación de una solución de inteligencia de negocios, debemos tener presente una serie de fallos en los que se suele caer a la hora de llevar a cabo un proyecto de BI. Aquí presentamos algunos de estos fallos según la experiencia en otros proyectos:

• Los data warehouses crecen en gran tamaño porque los técnicos acceden a cualquier exigencia que los usuarios demandan.
• Se confía demasiado en la gente de la empresa cliente para realizar el proyecto, cuando estos no tienen ni tiempo ni los conocimientos necesarios para apoyarnos en la toma de requisitos.
• Se suelen producir retrasos en la entrada a producción del sistema debido a una mala planificación.
• Presupuesto erróneo, el precio presupuestado es escaso en comparación con la complejidad de lo que se quiere desarrollar.
• Mala elección de software y hardware sin tener en cuenta los criterios técnicos.
• No se realizan pruebas de concepto para determinar si el proyecto es viable.
• Los datos de origen no están limpios. Esto implica procesos ETL más costoso, mayor tamaño de la base de datos y peor rendimiento.
• Mala elección de los consultores y excesiva rotación entre ellos.
• Escasa involucración de los usuarios finales, la cual les lleva a sentir cierta frustración cuando se les presentan unos resultados que no son los esperados.
• Creer que en informática todo es posible y plantearse cosas prácticamente inalcanzables.
• No alinear el proyecto dentro de una estrategia de negocio.

Existen más factores que pueden hacer fallar la implantación de un proyecto de BI, pero si caemos en estos, la oportunidad que nos brindó el cliente se volverá contra nosotros, y solo conseguiremos una mala imagen de los consultores, del producto y, en definitiva, de la empresa.

Una vez analizados los requerimientos básicos de cualquier solución de BI, la siguiente fase es analizar los requerimientos propios del caso que nos ocupa.

En el CECAV se utilizaban 3 aplicaciones diferentes según los tipos de análisis a realizar. Algunas de ellas, como hemos comentado, poseen herramientas integradas de reporting básico y exportación de información. Esto fue de gran ayuda a la hora de comparar resultados obtenidos con la solución y los resultados extraídos de cada una de las aplicaciones.

La intención era la de integrar la información de las 3 aplicaciones en una misma solución y proporcionar la posibilidad al usuario de realizar algo más allá de los reportes básicos, como el análisis de los datos desde un punto de vista geográfico, el cual se estaba realizando de forma manual.

Para entender a qué nos enfrentábamos, se tuvo que estudiar con detalle cada uno de estos orígenes de datos, ya que iban a ser la fuente de información desde donde partiríamos para alimentar nuestros data marts.

Como se comentó en el apartado 1.4.2 gran parte de la solución se desarrolló a través de una conexión a Escritorio Remoto directamente con los servidores centrales de CECAV (concretamente a través de un sistema operativo Microsoft® Windows® Server 2003 for Small Business Server) , ya que de esta manera el acceso a los datos de origen fue mucho más seguro y cómodo para ambas partes, no teniéndose que realizar backups de bases de datos ni utilizar bases de datos de prueba, sino que se accedían directamente a los orígenes de datos con los que la empresa trabajaba a diario. Esta forma de acceder conllevaba una ralentización en el tiempo de desarrollo del proyecto a causa de la dependencia de los accesos al servidor y el ancho de banda disponible.

Se trata de una aplicación de gestión destinada para centros de investigación, desarrollo e innovación, y laboratorios de control de calidad y pruebas. Esta aplicación posee módulos para conectar equipos de laboratorio, integrarse con ERP’s y para ofrecer servicios en línea.

Este sistema está basado en el concepto LIMS, una solución de tecnología de la información que permite a los usuarios modificar el formato de los datos sin tener conocimientos de programación y adaptarse de forma rápida y flexible a las nuevas necesidades laborales. Se trata de una solución modular estandarizada que permite a los clientes incorporar módulos y procedimientos nuevos para adaptar el sistema sus propias necesidades. Este concepto permite ofrecer una solución accesible, fácil de instalar con un mínimo esfuerzo necesario para validación.

Para CECAV, esta aplicación es utilizada para realizar un cierto tipo de análisis, por ejemplo para analizar muestras que puedan estar infectadas con salmonella. Para este origen de datos se conoció que la empresa realizaba estos análisis de salmonella para todas las muestras que entraban al laboratorio, y por otra parte, se realizaba otros tipos de análisis sobre unas determinadas muestras (no todas) las cuales se encontraban repartidas en forma de placa o matriz de 8×8 (64 casillas, no todas utilizadas, cada una con una muestra a analizar pero toda la placa se contaba como un mismo registro con el mismo código). Este sistema se apoya en una base de datos Oracle.

Es una aplicación orientada a los análisis de muestras de avicultura y ganadería. Se trata de una aplicación altamente editable por medio de plantillas y con gran capacidad de realizar exportaciones (Excel), informes y gráficas de los resultados analizados y con múltiples formatos de presentación.

Por medio de esta aplicación, CECAV analiza una serie de muestras en busca de enfermedades como IBD o IBV.

Gracias a la capacidad de exportación a Excel de las plantillas utilizadas para los análisis, se llegó al acuerdo con CECAV de que en vez de leer directamente los resultados de la base de datos de la aplicación (un fichero Access que no era accesible), se generaran mensualmente ficheros de Excel con los resultados del mes de todos los análisis realizados, tarea bastante sencilla para el personal del laboratorio y que ahorraba bastantes complicaciones a la hora de acceder a este origen de datos.

Este acuerdo se empezó a llevar a cabo a partir de finales de Enero de 2010, donde se ubicó un fichero con nombre “20100101.xls”, que contenía los datos correspondientes a ese mes, en el directorio acordado que sería el directorio base para este origen de datos. Antes de esto, se ubicaron en el mismo directorio otros ficheros con los datos correspondientes a los años 2007, 2008 y 2009, como podemos ver en la Figura 19.

Esta aplicación es un programa informático destinado a la captura de las densidades ópticas (DO) desde un lector ELISA (lectores para identificar enfermedades) e interpretación gráfica de los resultados de las muestras. Se puede utilizar como una herramienta para interpretar fácil y rápidamente los resultados o como una herramienta más completa en estudios epidemiológicos.

CECAV utiliza este software para otro tipo diferente de análisis, como para detectar enfermedades como TRT. Aunque esta aplicación también tiene capacidad de reporting, resulta mucho más costosa que en otros casos. Los resultados se almacenan en una base de datos en formato Access la cual resultó de fácil acceso a la hora de construir el proceso ETL asociado a este origen de datos. Aquí podemos observar la estructura de tablas que posee la base de datos asociada a la aplicación. Esto resulto de gran ayuda a la hora de identificar los datos necesarios e imprescindibles para el cliente presentes en esta fuente de datos.

Como se ha introducido anteriormente, CECAV posee aplicaciones capaces de generar reportes asociados a los diferentes análisis realizados sobre las muestras avícolas que el centro recibe a diario.

Estos reportes se generan en las diferentes aplicaciones dependiendo sobretodo del grado de complejidad del reporte y las capacidades técnicas de los usuarios que los componen. El grado de dificultad de la realización de los reportes y las exportaciones de información depende a su vez de las características de cada software. Aquí se muestran algunos ejemplos de reportes gráficos extraídos de las diversas aplicaciones anteriormente expuestas.

Lo más necesario para CECAV era la realización de Mapas Sanitarios de diferentes enfermedades en la Comunidad Valenciana a nivel de comarca y a nivel de municipio. Estos mapas se componían de manera manual anteriormente a la implementación de la solución de BI. Queda claro que gracias a la solución compuesta, la empresa pudo distribuir el tiempo empleado en la realización de los Mapas Sanitarios en otras actividades, ahorrando de esta manera tiempo y dinero para el centro.

Otra de las ventajas que Litebi proporcionaba además de la rapidez y la sencillez a la hora de generar estos informes, era la posibilidad de que estos informes fuesen dinámicos, es decir, fácilmente editables y consultables por el usuario para componer nuevos informes a partir de otros.

A la hora de diseñar la capa de metadatos que compondrá la solución, había que hacer hincapié e identificar aquellos conceptos y elementos utilizados en los informes que previamente se extraían de las diferentes aplicaciones, además de las indicaciones dadas por el centro a lo largo de sucesivas reuniones. Estos factores había que adaptarlos a la estructura de cubo que utiliza Litebi para que el usuario final fuera capaz de, por lo menos, generar los mismos informes que se estaban generando anteriormente. Aquí presentamos los diferentes conceptos de información necesarios para el cliente, su distribución y presentación en estructura de cubo se verá en el apartado de diseño de la solución de manera detallada:

• Tiempo:    Poder observar los datos desde el punto de vista Año->Trimestre->Mes->Día. También había que contemplar la posibilidad de observar los datos desde la perspectiva de un curso por demanda de CECAV (de septiembre a septiembre). Se identificaron diferentes conceptos que hacían referencia al tiempo: fecha de entrada de la muestra, fecha de toma, fecha oficial, fecha de inicio de análisis, fecha de fin de análisis…etc.
• Geografía: Tratar los datos desde un punto de vista geográfico de la siguiente manera:         Comunidad->Provincia->Comarca->Municipio->Explotación. Las explotaciones vienen identificadas por un código de explotación alfanumérico asignado por el REGA (registro general de explotaciones ganaderas). Estos códigos se componen de las letras ES más doce dígitos, donde ES identifica el país, en nuestro caso España; los dos primeros dígitos identifican la provincia, tres dígitos que identifican al municipio y 7 dígitos que identifican la explotación dentro del municipio. Los códigos para las provincias y los municipios son impuestos por el INE (Instituto Nacional de Estadística).
• Enfermedad o Determinación: Es el factor de análisis de CECAV. Siempre se tienen en cuenta diferentes tipos de resultados según la enfermedad que se esté analizando. En unos casos son resultados numéricos y en otros resultados de positivo o negativo. Nos interesa tener en cuenta cualquier información referente a las enfermedades.
• Muestra: Cada muestra se identifica con un código de muestra. Podemos decir que las muestras se clasifican en registros, donde un registro con un mismo código posee una serie de muestras con diferente código (Ejemplo: Si nos llega una placa, la placa completa se trata como un registro, pero cada una de sus celdas es una muestra que se analiza de manera independiente). Las muestras son el objeto de análisis y se pueden ver desde diferentes perspectivas como el producto que hace referencia la muestra (heces, alimento, animal, etc.) o el departamento donde se analiza (necropsias, química, serología, etc.). Está sujeta a diversas características que la identifican.
• Origen: Nos indica el origen del análisis para una muestra determinada (Mapa Sanitario, Control, Plan Anual Zoosanitario, etc.).
• Tipo de Ave: Característica indispensable que necesitaba el centro para clasificar sus análisis. Existen diferentes muestras asignadas cada una a un tipo de ave en particular (ponedoras, broilers…etc.).
• Cliente: Otro dato a tener en cuenta era saber de qué cliente provenían cada una de las muestras a analizar. Se estableció en identificar al cliente mediante el NIF asociado.
• Dueño Explotación: Al centro le interesaba saber no solo de que explotación provenían las muestras, sino que persona llevaba la explotación. En muchos casos el cliente era diferente al dueño de la explotación.
• Indicadores o métricas: Tras analizar los diferentes factores a tener en cuenta según los puntos de vista de los diferentes informes, el análisis se centró en las cantidades numéricas que se estaban analizando. Se observó que dependiendo la  enfermedad, los resultados asociados eran diferentes (en unas enfermedades se medía el número de anticuerpos y en otros la densidad óptica) y por tanto no existía un patrón común de medida para todos los casos. Esta cuestión dificultaba el diseño y se planteó seguir adelante e identificar estos factores en concreto una vez el diseño fuese claro. Los únicos indicadores claros y comunes a todas las enfermedades eran: Número de muestras analizadas o número de registros analizados (o ambos) y número de explotaciones analizadas.