DB Modulo 4.pdf

Bloque 1Bloque 2Referencias Ciclo de vida del Business Intelligence “El ciclo de vida de un proyecto de Business Intelligence abarca desde la planificación del proyecto hasta el despliegue, crecimiento y mantenimiento de la solución” (Kimball, 2013, p. 404). 1. Etapas del ciclo de vida Diagrama del...

Bloque 1Bloque 2Referencias Ciclo de vida del Business Intelligence “El ciclo de vida de un proyecto de Business Intelligence abarca desde la planificación del proyecto hasta el despliegue, crecimiento y mantenimiento de la solución” (Kimball, 2013, p. 404). 1. Etapas del ciclo de vida Diagrama del ciclo de vida de BI De acuerdo con Ralph Kimball (2013), el ciclo de vida de un proyecto de Business Intelligence atraviesa un conjunto de etapas: planificación y gestión del proyecto; definición de los requerimientos del negocio; diseño de la arquitectura técnica; selección e instalación de productos; modelado multidimensional; diseño físico; diseño y desarrollo de procesos ETL; especificación / diseño de la aplicación de BI; desarrollo de la aplicación de BI; despliegue; crecimiento; mantenimiento. A continuación, se presenta un diagrama del ciclo de vida en donde se aprecia cómo se interrelacionan las distintas etapas / tareas: Figura 1: Diagrama del ciclo de vida de un Proyecto de BI Fuente: Elaboración propia en base a Kimball, 2013, p. 404. 2. Pasos de cada etapa A continuación, describiremos las características principales de cada etapa de acuerdo con lo enunciado por Ralph Kimball (2013). Etapa de planificación y gestión del proyecto Todo proyecto de Business Intelligence inicia con una serie de actividades ligadas a la planificación del proyecto, incluyendo lo siguiente. ☰ Evaluación de si la organización Evaluación de si la organización está preparada para iniciar un proyecto de BI, en base a tres factores críticos: contar con el apoyo de los directivos; contar con una motivación comercial que justifique el proyecto de BI; que exista factibilidad tanto técnica como a nivel de recursos, pero especialmente la factibilidad para acceder a los datos transaccionales / operacionales. ☰ Definición del alcance del proyecto Definición del alcance del proyecto (por ejemplo, iniciar con un solo proceso de negocio) y la justificación del mismo, lo cual está relacionado con realizar una estimación de los beneficios y costos asociados al proyecto. ☰ Conformación de un equipo Conformación de un equipo de personas que sea multidisciplinario, preferentemente. El equipo estará constituido por varios perfiles; entre ellos podemos encontrar: ​ sponsor del negocio (cliente): correspondiente al directivo que promueve el proyecto; líder del negocio (quién conoce más sobre el negocio y quién será el referente con el que se comunicará el líder del proyecto); usuarios finales; analistas del negocio / analistas funcionales; administrador de datos (data steward); arquitecto / diseñador de BI; desarrollador de aplicaciones de BI; project manager; arquitecto técnico; arquitecto de datos; modelador de datos; administrador de bases de datos (DBA); coordinador de metadatos; arquitecto / diseñador ETL; desarrolladores de procesos ETL. ☰ Desarrollo y mantenimiento del plan del proyecto de BI El cual identifica todas las tareas necesarias del ciclo de vida. Aquí es clave la estimación del esfuerzo requerido en cada tarea así como los criterios de aceptación e hitos del proyecto. Etapa de definición de los requerimientos del negocio Incluye lo siguiente. Preplanificación de los requerimientos, que consiste básicamente en seleccionar el lugar adecuado para llevar adelante las sesiones/entrevistas de captura de requerimientos. Además, se debe identificar y preparar al equipo que realizará el relevamiento y captura de requerimientos, al igual que seleccionar apropiadamente los responsables del negocio/usuarios que serán entrevistados, si esto fuera posible. Captura de los requerimientos del negocio. Conducción de entrevistas centradas en los datos, es decir, teniendo sesiones con los expertos en los sistemas transaccionales/operacionales. Documentación de los requerimientos. Priorización de los requerimientos. Etapa de diseño de la arquitectura técnica Incluye lo siguiente. Establecer un miniequipo dedicado y enfocado en el diseño de la arquitectura. Generalmente está compuesto por el arquitecto técnico junto con el arquitecto ETL y el arquitecto BI. Captura de los requerimientos relacionados con la arquitectura técnica. Documentación de los requerimientos de arquitectura. Creación del modelo de arquitectura técnica del proyecto. Determinación de las fases de implementación de la arquitectura. Diseño y especificación de los subsistemas. Creación del plan de arquitectura técnica. Revisión y finalización de la arquitectura técnica. Etapa de selección e instalación de productos Incluye las siguientes tareas. Comprensión del proceso corporativo interno de compras. Desarrollo de una matriz de evaluación de productos. Conducción de investigaciones de mercado. Evaluación de productos a partir de una lista reducida preseleccionada de opciones. Diseño de un prototipo, si fuera necesario. Selección de los productos. Instalación de versiones trial de los productos. Negociación comercial con los proveedores de los productos. Etapa de modelado multidimensional Esta etapa corresponde al modelado de las estructuras multidimensionales del Data Warehouse y/o Data Mart. Etapa de diseño físico Los modelos multidimensionales desarrollados y documentados necesitan traducirse en una base de datos física. Con el modelado multidimensional, los diseños lógico y físico suelen ser bastante similares. Los detalles de implementación de la base de datos física pueden variar ampliamente por plataforma y proyecto. Esta etapa incluye lo siguiente. Desarrollo de estándares de bases de datos, como por ejemplo, nombres de tablas y columnas. Desarrollo del modelo físico de base de datos. Desarrollo del plan de indexación inicial. Diseño de sumarizaciones, incluyendo el diseño de los cubos OLAP, si es que se incluyen en el proyecto de BI. Finalización del almacenamiento físico (bloques, archivos, discos, particiones y tablespaces, entre otros aspectos). Etapa de diseño y desarrollo de procesos ETL En esta etapa se lleva adelante el diseño arquitectónico general de cada uno de los procesos ETL y posteriormente el desarrollo propiamente dicho de los mismos. Etapa de especificación / diseño de la aplicación de BI Una vez definidos los requerimientos del negocio, se necesita establecer un conjunto inicial de aproximadamente 10 a 15 reportes y aplicaciones analíticas de BI. Antes de proceder a desarrollar las aplicaciones de BI, es necesario también establecer ciertos estándares, tales como el look & feel que tendrán los distintos dashboards, por ejemplo. Etapa de desarrollo de la aplicación de BI La actividad de desarrollo puede iniciarse cuando el diseño de la base de datos esté finalizado, las herramientas BI instaladas y un subconjunto de datos históricos se carguen en la base de datos. Etapa de despliegue El despliegue depende de la convergencia exitosa entre la tecnología, los datos y las aplicaciones de BI. Es claro que las tareas relacionadas con los procesos ETL suelen ser las más impredecibles, puesto que podemos encontrarnos con cualquier tipo de complejidad en los datos, muchas de las cuales pueden no haber sido contempladas. También en el despliegue es necesario realizar un testing end-to-end final, incluyendo el aseguramiento de la calidad de los datos, el procesamiento correcto de las distintas operaciones y procedimientos, issues de performance y, por supuesto, un testing de usabilidad. También un punto crítico en esta etapa consiste en la capacitación de los usuarios finales de las nuevas herramientas de BI. Etapas de crecimiento y mantenimiento Luego de la implementación en producción será necesario un trabajo de mejora continua, incluyendo: soporte técnico; soporte funcional; capacitación; nuevas funcionalidades. A diferencia de los sistemas tradicionales, el cambio en los proyectos de BI debe visualizarse como una medida del éxito de su despliegue y uso. Referencias Kimball, R. (2013). The Data Warehouse Toolkit (3º Edición). Estados Unidos: Wiley Publishing. IntroducciónBloque 1Bloque 2Bloque 3Bloque 4Bloque 5Referencias Core Team Introducción De acuerdo con Ralph Kimball, Margy Ross, Warren Thornthwaite, Joy Mundy y Bob Becker (2008), el Core Team soporta el grueso de la responsabilidad en el diseño y desarrollo del sistema de BI. 1. Analista de negocio / analista funcional El analista de negocio o analista funcional es el responsable de liderar las actividades de definición de requerimientos del negocio, como así también de representar estos requerimientos en la especificación de arquitectura técnica, modelo multidimensional y aplicaciones de BI. El rol del analista de negocio generalmente se cubre con una persona de sistemas que esté extremadamente centrada en el usuario y conozca del negocio. Alternativamente, podría cubrirse también con una persona de la organización que conozca bastante del negocio y que no sea del departamento de sistemas, pero debe contar con sólidos fundamentos técnicos. En proyectos más pequeños, el propio Project Manager o el líder del proyecto del negocio puede cubrir esta misma posición. El analista del negocio debe contar con fuertes habilidades comunicacionales. Por otro lado, ser respetado por los clientes/usuarios resulta un plus adicional, teniendo en cuenta que dicho analista estará representando al resto del equipo del proyecto en cuanto a la definición de requerimientos. 2. Administrador de datos / analista de aseguramiento de la calidad (QA) El administrador de datos, o Data Steward en inglés, es el responsable de gestionar el acuerdo organizacional en cuanto a las definiciones, las reglas de negocio y los valores de dominio permitidos para el Data Warehouse, además de la posterior publicación de estas definiciones y reglas. Históricamente se refirió a este rol como el DBA (DataBase Administrator en inglés), una función dentro de sistemas. Sin embargo, es conveniente que este rol sea cubierto por un experto en la materia/área de interés de la aplicación de BI por parte del propio negocio/cliente. Además, este es un rol políticamente cambiante. Deben ser líderes altamente respetados, comprometidos con el trabajo a través de inevitables cruces interfuncionales y apoyados por alta gerencia, especialmente cuando se requiere del compromiso organizacional. Algunas veces, trabaja en conjunto con los analistas de aseguramiento de la calidad (QA), quienes garantizan que los datos cargados en el Data Warehouse sean precisos y completos, identifican potenciales errores en los datos y buscan su resolución. En ciertas ocasiones, el analista QA también es responsable de verificar la integridad funcional de las aplicaciones de BI. Además, tiene una carga de trabajo significativa durante la carga de datos inicial para asegurar que los procesos ETL trabajen correctamente. Dada la necesidad de una verificación continua de los datos, el rol no finaliza aunque el Data Warehouse entre en producción. 3. Arquitecto de datos/modelador de datos/administrador de bases de datos (DBA) El arquitecto de datos es responsable de desarrollar la estrategia arquitectónica de datos general del sistema de BI asegurando la reusabilidad, la integración y la optimización. El modelador de datos es responsable de realizar el análisis detallado de los datos y de desarrollar el modelo de datos multidimensional. Su rol tiene gran influencia en el éxito del proyecto, los modelos bien diseñados son más fáciles de implementar, al mismo tiempo que satisfacen los requerimientos de los usuarios. Para este rol se requiere de gran conocimiento de las estructuras de datos de los sistemas corporativos como así también de las reglas del negocio. Si bien es valiosa su experiencia previa en modelado de estructuras de datos, es clave que no esté demasiado "atado" al pensamiento ligado al modelo relacional y al diseño normalizado tradicional, para poder seguir las técnicas de diseño multidimensional. En caso de usar OLAP, esta persona frecuentemente diseña tanto el modelo multidimensional sobre el RDBMS como sobre el MDBMS, en conjunto con el desarrollador de la aplicación de BI. El modelador de datos participa en la actividad de definición de requerimientos en un rol secundario. El administrador de bases de datos (DBA, Data Base Administrator en inglés) se encarga de traducir el modelo multidimensional en una estructura física de tablas. En algunos casos también está involucrado en el proceso de modelado multidimensional; por lo tanto, las personas que cubran este rol deben estar, como mínimo, familiarizadas con estas técnicas de diseño. El DBA es responsable del diseño físico general, incluyendo aspectos tales como particionamiento, plan de índices y otros. Además, el DBA también es responsable del soporte operativo diario de la base de datos asegurando la integridad de datos, disponibilidad y performance. Coordinador de metadatos Es necesario que alguien tome la responsabilidad de coordinar los metadatos, puesto que pueden estar ubicados en cualquier parte del sistema de BI. En este rol de coordinador de metadatos no se es responsable de cargar los metadatos, sino de asegurar que todos los componentes contribuyen a su carga, desde los sistemas transaccionales fuente, pasando por el ETL y hasta las herramientas de visualización de BI. Esta persona tiene la última palabra sobre qué metadatos se conservan, dónde se ubican y cómo se publican a los usuarios. 4. Arquitecto ETL/desarrollador ETL El arquitecto/diseñador ETL es responsable del diseño end-to-end del proceso ETL. El desarrollo de procesos ETL requiere de fuertes habilidades en diseño modular de sistemas. Este rol muchas veces no se cubre y el desarrollador debe codificar sin plan alguno. El arquitecto/diseñador ETL debería estar involucrado en la captura de requerimientos y tener una relación laboral permanente con el equipo de la aplicación de BI. Los desarrolladores ETL construyen, prueban y automatizan los procesos ETL bajo la dirección del arquitecto ETL. Quien asuma este rol debe tener un conocimiento íntimo de los sistemas transaccionales/operacionales para ayudar en el mapeo, así como un conocimiento básico de los modelos multidimensionales destino. 5. Arquitecto BI/desarrollador de aplicación BI El arquitecto BI tiene la responsabilidad general del sistema BI, asegurando que todo el entorno de BI esté optimizado para tratar los requerimientos del negocio. El arquitecto BI establece el framework y refuerza los estándares que son usados por los desarrolladores BI. El desarrollador de aplicaciones de BI crea y mantiene las aplicaciones de BI, generalmente usando software de Query & Reporting; además es responsable de configurar la capa semántica de la herramienta de BI. Este rol requiere de conocimientos en bases de datos y también habilidades en programación, junto con una profunda comprensión del negocio y sus requerimientos. Referencias Kimball R.; Thornthwaite, W. y Mundy Joy, B. B. (2008). The Data Warehouse Lifecycle Toolkit (2º Edición). Estados Unidos: Wiley Publishing. Bloque 1Referencias Extended Team 1. Extended Team De acuerdo con Ralph Kimball, Margy Ross, Warren Thornthwaite, Joy Mundy y Bob Becker (2008), el Extended Team está conformado por roles adicionales que contribuyen al proyecto de BI, pero sobre aspectos muy especializados o temas puntuales. Desde luego, los roles que aquí mencionamos también pueden ser llevados a cabo por las personas que conforman el Core Team. ☰ Arquitecto técnico/arquitecto de seguridad El arquitecto técnico/arquitecto de seguridad es responsable del diseño de la infraestructura técnica y la estrategia de seguridad para soportar el Data Warehouse. Para desempeñar este rol no se necesita ser un experto en todas las tecnologías de infraestructura y seguridad, sino que más bien debe proveer cohesión general para asegurar que los componentes se ajusten entre sí. ☰ Especialistas en soporte técnico Dependiendo de la organización, puede haber especialistas enfocados en sistemas cliente/servidor, redes, comunicaciones, etcétera. Estos especialistas en soporte técnico están involucrados en las etapas iniciales del proyecto para realizar un análisis de recursos y capacidad de equipos. Además, durante la selección de los productos aseguran la compatibilidad con el entorno tecnológico existente. Una vez seleccionada la tecnología, proceden a la instalación y configuración de los nuevos componentes; también proveen de soporte continuo en producción. ☰ Programador de Data Staging El programador de Data Staging es un programador cuyo rol puede ser cubierto incluso por el desarrollador ETL, pero, en este caso, si se usa alguna estructura de preparación de datos (Data Staging, en inglés), se requerirá entonces de un rol especializado para esta etapa intermedia entre el ETL y que los datos lleguen al repositorio definitivo del Data Warehouse. ☰ Consultores externos Desde luego, en más de un proyecto se requerirá de uno o más consultores externos especializados en alguno de los roles mencionados anteriormente. Referencias Kimball R., Ross, M., Thornthwaite, W., Mundy J. y Becker B. (2008). The Data Warehouse Lifecycle Toolkit (2º Edición). Estados Unidos: Wiley Publishing. Bloque 1Bloque 2Bloque 3ReferenciasRevisión Taller 1. Taller “Escoger aquella herramienta de Business Intelligence que mejor satisfaga las necesidades de los usuarios en cuanto a las funcionalidades, con la mejor arquitectura y al mejor coste, no es una tarea fácil” (Cano, 2007, p. 163). Elección herramienta Múltiples alternativas Uno de los primeros puntos a definir a la hora de encarar un proyecto de Business Intelligence consiste en identificar qué herramientas vamos a utilizar. Se debe tener en cuenta que existen múltiples opciones, puesto que hay muchas empresas que proveen este tipo de software (como puede verse en el capítulo VI de Josep Lluís Cano, 2007). Para poder seleccionar correctamente las herramientas de BI que vamos a utilizar, es importante tener en cuenta las características de nuestros usuarios. Josep Lluís Cano (2007), en base a un trabajo de Jonathan Wu (2000), establece que el proceso de selección de las herramientas puede ser formal o informal. Proceso de selección informal Según Josep Lluís Cano (2007, p. 164), “Comúnmente, las organizaciones no establecen un proceso formal de selección de software y, desafortunadamente, en la mayoría de los casos este procedimiento no produce los resultados esperados”. Es posible, por lo tanto, que una organización haya adquirido inapropiadamente un software porque no ha destinado los suficientes recursos en tiempo y dinero para seleccionar la solución. La elección de una solución de Business Intelligence no se puede tomar de cualquier manera: Algunas organizaciones se ven obligadas a cambiar de proveedor al cabo de uno o dos años. Los costes para la organización no son tan sólo los de adquisición de las licencias, sino también los del proyecto de implementación, que incluyen tanto los de formación de los usuarios como los de conseguir el conocimiento necesario por parte de la organización para que la solución sea utilizada. Debemos tener en cuenta el coste, los requerimientos funcionales y la arquitectura tecnológica. (Cano, 2007, p. 165) Proceso de selección formal Según Josep Lluís Cano (2007, p. 165), “Con un proceso formal de selección de software la probabilidad de seleccionar la mejor herramienta para la organización se incrementa sustancialmente”. El autor describe un conjunto de etapas y tareas a seguir para la selección formal de software de BI, en base a dos metodologías distintas: la de Jonathan Wu y la de Wayne Eckerson y Cindi Howson. Metodología de Jonathan Wu 1. Inicio del proyecto: 1.1. Alcance y objetivos. 1.2. Equipo. 1.3. Comunicación del inicio. 2. Análisis de los procesos de negocio: 2.1. Comprender los procesos actuales y su información asociada. 2.2. Identificar las mejores prácticas que apoyan a los objetivos de negocio. 2.3. Análisis de las diferencias. 2.4. Desarrollar cómo deberían ser los procesos en el futuro. 3. Definir los requerimientos: 3.1. De negocio: 3.1.1. Presupuesto y plazos. 3.1.2. Requerimientos de información directiva. 3.2. Funcionales: 3.2.1. Estado de las necesidades de negocio. 3.3. Técnicos: 3.3.1. Estándares de sistemas. 3.3.2. Diagramas de flujo. 3.3.3. Interfaces de sistemas. 4. Punto de decisión: Construir (¿realmente queremos construir la solución en lugar de utilizar uno de los productos disponibles en el mercado?) versus comprar. 5. Gestión de los proveedores: 5.1. Demostraciones. 5.2. Análisis de sus ofertas. 5.3. Ranking de las soluciones de los proveedores. 5.4. Negociación. (Cano, 2007, pp. 165-166) Metodología de Wayne Eckerson y Cindi Howson 1. Deberíamos constituir el Comité de Selección de la herramienta de Business Intelligence. Debería estar formado por todos los stakeholders de los distintos departamentos, incluido el de Sistemas de Información. En el Comité debería participar algún directivo que actúe como sponsor del proyecto. Si tenemos usuarios con experiencia deben participar en él. Para que sean efectivos, los comités deben estar compuestos por pocos miembros. 2. Definir los usuarios y los escenarios de uso: muchas organizaciones no se preocupan demasiado por los usuarios. Su foco es crear un Data Mart o un informe, y no definir cuál es la información que se necesita y para qué rol y nivel de la organización. Se hace necesario definir quién interactuará con un informe y cómo, ya que los diferentes tipos de usuarios requieren distintas herramientas e interfaces. Comprender los segmentos de usuarios es crítico para gestionar el alcance en la selección y resolver los conflictos de los requerimientos. Siguiendo este proceso, puedes descubrir que distintos grupos de usuarios que tienen los mismos requerimientos quieren soluciones distintas. 3. Refinar los requerimientos de información: Cada herramienta de Business Intelligence soporta modelos y esquemas ligeramente diferentes, lo cual es crítico para incorporar los requerimientos en el proceso de selección. Por ejemplo, los usuarios quizás necesiten analizar las ventas con los inventarios para calcular “inventarios por días de venta” de varios grupos de productos y periodos de tiempo. Este simple requerimiento se convierte en una serie de características técnicas: 1) multi SQL para consultar dos tablas del Data Warehouse; 2) capacidad para agregarlos inventarios por grupos de producto, pero no a través de periodos de tiempo; 3) suma automática de filas individuales de información, para poder ver los totales del año o por grupos de productos. Las distintas herramientas de BI solventan estos requerimientos de formas absolutamente distintas. El Comité de Selección debe comprender las diferencias y saber qué aproximación será mejor para la organización. 4. Definir los criterios de selección y su peso. Hay varias metodologías para capturar los requerimientos de los usuarios: Entrevistas individuales, análisis de la diferencia o sesiones de tormenta de ideas. La clave, sin embargo, es trasladar los requerimientos a las capacidades de la herramienta de Business Intelligence. Por ejemplo, es difícil que los usuarios digan: “Queremos una herramienta de BI con una capa de metadata”. Lo que probablemente dirán, es que quieren crear sus propios informes sin necesidad de conocer su lenguaje. Los criterios más utilizados son viabilidad del vendedor, estrategia del vendedor, funcionalidades (en consultas, en informes, en entrega de información, integración con hojas de cálculo, cuadros de mando, administración, arquitectura, coste, formación y soporte). Deberemos priorizar cada criterio con un peso. Si se quieren consultar ejemplos de listas de criterios, se pueden consultar en www.BIScorecard.com. ​5. Solicitudes de información (RFI). Generan mucho trabajo para el vendedor y poco valor para el comprador; muchos vendedores dicen “sí” a todos los requerimientos. Para ser justos, algunos vendedores son más honestos que otros y los requerimientos están sujetos a interpretación. Por ejemplo, si necesitas una arquitectura tecnológica basada en Unix, los vendedores que no soportan Unix pueden ser eliminados. Para aumentar el valor del RFI, se deben incluir aquellos requerimientos que sean decisivos en la selección o en la estandarización: Preguntar cómo las herramientas específicas solucionan los requerimientos de los usuarios. Las preguntas abiertas, al final, pueden mostrar luz sobre la aproximación del vendedor y el interés que tiene por el proyecto. Los vendedores que atienden cuidadosamente las respuestas, en lugar de los que utilizan material preparado y empaquetado por marketing, son más válidos. 6. Demostraciones: El Comité debe ver las distintas demostraciones de los proveedores y debe prepararse un orden del día para cada vendedor. En el orden del día debe disponerse de tiempo para hablar de las consideraciones estratégicas, así como de las capacidades del producto. Se debe invitar a usuarios que no participan en el Comité a las demostraciones para poder obtener su opinión y asegurar que han participado en el proceso de decisión, preguntándoles cuál es su valoración de la habilidad de los vendedores en cubrir sus requerimientos específicos. Las demostraciones se pueden basar en los datos del vendedor o en los propios de la organización: El uso de los de la organización puede ayudar a comprender mejor las diferencias entre herramientas, aunque requiere una inversión en tiempo mayor para el vendedor y la propia organización. Esta alternativa vale la pena si tenemos pocas alternativas, ya que si el número de productos es muy elevado no es demasiado práctica. 7. Determinar cuál es la herramienta que se ajusta más: Usando los requerimientos definidos en el punto 4, puntuar los criterios y las demostraciones; incorporar consideraciones estratégicas, información cualitativa e información de clientes de la herramienta para saber cuál de ellas y qué proveedor se ajusta mejora corto y largo plazo a nuestra organización. Si la elección está clara, no se deben abandonar las segundas alternativas completamente: Debemos todavía probar el concepto, negociar el contrato o poner a prueba si nuestra primera elección tiene problemas insuperables. 8. Probar el concepto: Sólo deberíamos tener uno o dos proveedores posibles al llegar a esta fase. Es la oportunidad de probar la herramienta en nuestro entorno. Únicamente es una prueba, aunque en este punto es importante conseguir que el Comité esté centrado en los requerimientos críticos más que en jugar interminablemente con la herramienta o intentando crear informes. La prueba del concepto sirve para elegir entre las alternativas, su propósito es confirmar que el producto funciona como se espera. Para ello deberemos escoger un grupo de informes, limitando el alcance, para probar el concepto. Los informes de ejemplo pueden basarse en los requerimientos definidos en el punto 3 y que sean moderadamente complejos (se trata de que no sean simples listados, pero tampoco tan complejos que un programador experimentado tenga que destinar un mes completo para crearlos). La prueba del concepto nos dará la idea de cómo debemos adaptar el resto de nuestra arquitectura de BI, pero no es la clave definitiva para resolver los problemas de implementación. (Cano, 2007, pp. 166-170) 2. Criterios de selección de la herramienta / producto de BI Josep Lluís Cano (2007) describe un conjunto de criterios a tener en cuenta a la hora de seleccionar la herramienta de BI, en base a un trabajo de Wayne Eckerson y Cindi Howson (2003). Evaluar datos financieros sobre del proveedor: Total de ingresos de productos de Business Intelligence/total de sus ventas. Ratio entre ingresos por servicios y licencias. Evolución de la venta de licencias. Resultado económico. Evolución de las acciones. Recursos destinados a Investigación y desarrollo. Estrategia de ventas. Fusiones, adquisiciones, etc. La estrategia del proveedor: Si tiene otros productos (por ejemplo, de ETL, base de datos propia, etcétera). Cuando venden, ¿qué venden? Cuáles son sus principales competidores. Cuál es su origen y hacia dónde van. Cuáles son sus diferencias respecto a los otros proveedores. Posibles evoluciones de la herramienta. La arquitectura tecnológica del proveedor. Arquitectura orientada a servicios (SOA). Estructura común a través de todos los productos. Procesamiento en el servidor (o en cliente). Desarrollo por capas. Conectividad con terceros. Solidez del sistema. Escalabilidad y rendimiento. Alta disponibilidad. Que soporte estándar. Las funcionalidades de consultas: Proteger a los usuarios de las complejidades del motor de base de datos. Consultas ad hoc. Consultas totalizadas y detalladas. Seleccionar listas. Acceder a distintas fuentes de datos. Impacto de las consultas en la base de datos. Complejidad del lenguaje de las consultas. Acceso desde cliente servidor o vía web. Las funcionalidades de informes: Estructura de los documentos y flexibilidad. Complejidad del documento (distintas fuentes de datos, tablas combinadas, gráficos). Formatos de tablas. Tipos de gráficos. Cálculos basados en el informe. Diseño del informe, formato rápido. Control de impresión. Formato contextual. Capacidades de navegación. Formato WYSIWYG. Entrega de información: Planificada (tiempo, eventos, versiones, etc.). Formatos (Excel, PDF, HTML, etc.). Dispositivos (correo electrónico, PDA, impresora). Integración en portales. Las funcionalidades OLAP: Tipo de arquitectura: MOLAP, ROLAP, OLAP, DOLAP. Uso de particiones. Proceso de construcción de los cubos. Cálculos. Jerarquías alternativas. Análisis de atributos. Soporta otras fuentes OLAP. Valores en un momento del tiempo o agregados en un periodo. Navegar a detalle. Deshacer en análisis qué pasaría si (What if). Posibilidad de crear funciones. Número de usuarios, dimensiones, etc. Pivotar cubos, arrastrar y soltar. Tiempo de respuesta. Cálculos a nivel de usuario. Utilizar jerarquías definidas y caminos de navegación. Ranking. Alertas y semáforos. Juntar tablas y gráficos y navegar de forma sincronizada. Formatos de impresión. Las funcionalidades de administración: Autentificación de usuarios (LDAP, roles, basados en web). Construcción y mantenimiento del Metadata. Administración del servidor. Información y monitorización del uso. Entornos de desarrollo. Control de cambios. Los precios: Licencias (nominales, concurrentes, por servidor, por CPU). Mantenimiento (importe, actualizaciones y soporte). Soporte (niveles, importe, base de datos de incidencias). Importe para el proyecto concreto. Coste total de propiedad 115 (TCO, “Total Cost of Ownership”). (Cano, 2007, pp. 171-174) Criterios de selección del implementador de BI Josep Lluís Cano (2007) propone también una serie de criterios que deben tenerse en cuenta a la hora de seleccionar la empresa proveedora que realizará la implementación de la solución de BI. Puntualmente, menciona los siguientes aspectos: Historia. Estabilidad y viabilidad financiera. Recursos humanos y de gestión. Cobertura geográfica. Servicios ofertados. Experiencia con el producto y en el sector. Experiencia con clientes afines. Metodología y herramientas de desarrollo. Productos y metodologías implementadas. Grado de confianza. A estos criterios deberían añadirse algunos de los que propone Forrester Research: Especialización vertical. Facilitar la colaboración con otros proveedores. Flexibilidad para cambiar las necesidades del cliente. Soporte para la aparición de nuevas tecnologías o la innovación en los negocios. Casar los servicios ofrecidos con las necesidades de los clientes. (Cano, 2007, pp. 174-175) Productos de BI En la Nota Técnica 3 del Capítulo VI (2007, pp. 175-185), Josep Lluís Cano hace una recopilación de distintos proveedores de productos de BI. Es evidente que, para el caso de las PyMEs, muchas veces los costos pueden resultar definitivamente prohibitivos; en tal caso no queda otra alternativa por la cual optar que por una herramienta Free Open Source, o bien por alguna opción comercial de relativo bajo costo, como, por ejemplo, para la visualización de los datos puede ser la planilla de cálculo Microsoft Excel. En este sentido, Josep Lluís Cano (2007) muestra un ejemplo de acceso a bases de datos OLAP con Excel (también en el mencionado capítulo VI, pp. 186-192). Por otro lado, en el capítulo VIII hace un repaso de la evolución de las herramientas de BI y del mercado global de soluciones de BI. En el informe de Gartner es interesante observar cuáles son las empresas que tienen mayor participación de mercado, lo cual denota el grado de implementación de sus productos por parte de las organizaciones cliente en todo el mundo: “SAP: 22,1 % Oracle: 14,9% IBM: 12,4 % SAS: 12,2% Microsoft: 9,1%” (“Gartner says worldwide Business Intelligence…”, s.f., https://bit.ly/39LWRy4) Relevamiento del negocio Una vez decidida la plataforma tecnológica de soluciones de BI, el relevamiento del negocio es fundamental para poder comprender los requerimientos. Entre los aspectos que debemos tener en cuenta podemos mencionar los siguientes: datos generales sobre la empresa y el área de Sistemas (todo esto en caso de que estemos ofertando o proporcionando una solución de BI a un cliente externo); relevamiento de requerimientos de información con los usuarios claves; relevamiento de los sistemas de información transaccionales/operacionales de la empresa ‒que se utilizarán como fuente de datos para la construcción del Data Warehouse‒; otros aspectos. Josep Lluís Cano (2007) hace, en el capítulo VII, un recorrido de distintos casos de estudio con diferentes experiencias de implementación de soluciones de BI. Análisis OLTP Para cada uno de los sistemas de información transaccionales/operacionales de la empresa, será necesario hacer un análisis detallado exhaustivo respecto a sus características, funcionalidades, plataformas tecnológicas y sobre todo sus estructuras de datos. Contar con un diagrama de entidad-relación (DER) de cada uno de ellos será fundamental. Josep Lluís Cano (2007) enuncia, en el capítulo VII, distintos casos de empresas con sus respectivos sistemas de origen. Construcción procesos ETL A partir de los datos transaccionales/operacionales se deberá proceder a construir los procesos ETL que terminarán transportando los datos hacia el Data Warehouse. Josep Lluís Cano (2007) denota, en el capítulo VII, su recorrida de distintos casos de estudio, con diferentes experiencias de implementación de soluciones de BI y las características de varios procesos ETL empleados. 3. Armado de Datamart Los procesos ETL deberán finalmente llevar datos al Data Warehouse y luego deberá armarse el Data Mart correspondiente. Josep Lluís Cano (2007), en el capítulo VII, expone el modelo multidimensional generado en varios casos de estudio. Así, por ejemplo, podríamos tener un modelo multidimensional como el que sigue, correspondiente a una concesionaria que vende automóviles en todo el país. En el caso, tenemos 2 hechos: cantidad de unidades vendidas; precio unitario. Y además las dimensiones: tiempo (año, mes y día); producto (marca y modelo de auto); sucursal; cliente. Figura 1: Modelo multidimensional de ejemplo de concesionaria Fuente: Elaboración propia. Presentación La capa de presentación es clave, puesto que, por más que hayamos realizado un excelente trabajo de integración y transformación de datos, esto no aportará valor agregado al usuario final si no cuenta con una herramienta de visualización/explotación que le sea útil y fácil de usar. También Josep Lluís Cano (2007), en el capítulo VII, muestra diferentes tipos de aplicaciones que se usaron en varias empresas. Siguiendo el ejemplo de la concesionaria de vehículos, podríamos poner en la pantalla cada una de las dimensiones para que el usuario p|ueda seleccionar los valores que desee para hacer drill-down y ver más detalles. Así, por ejemplo, como puede verse en la Figura 2, ubicamos los valores de la dimensión tiempo en la parte superior de la pantalla y el resto de las dimensiones en el margen izquierdo de la misma. Sin embargo, aún no hemos incluido ningún gráfico en la pantalla (como puede verse en la Figura 2), para poder visualizar los indicadores seleccionados. Figura 2: Pantalla con dimensiones sin indicadores Fuente: Elaboración propia. A continuación, se muestra un gráfico en el que se visualiza el indicador de cantidad de unidades vendidas, que lo definimos como un SUM del campo FACT_VENTAS.CANTIDAD. Este gráfico de ejemplo se elaboró incluyendo la dimensión producto, de modo tal que podremos ver los autos vendidos por cada una de las marcas (productos). Utilizamos un gráfico de torta ordenando los valores desde el producto más vendido hasta el menos vendido. Los valores se muestran arriba de cada producto. Figura 3: Autos vendidos por marca Fuente: Elaboración propia. Sobre el mismo gráfico vamos a hacer una operación de drill-down. Para ello, simplemente seleccionaremos un valor de la dimensión sucursal. En este caso, queremos ver ‒para el indicador de cantidad de unidades vendidas‒ cuántos se vendieron en la sucursal "ROSARIO". Figura 4: Autos vendidos por marca por sucursal Fuente: Elaboración propia Ahora aplicamos un drill-across seleccionando un valor de la dimensión cliente. Queremos ver los autos vendidos por marca en la sucursal "ROSARIO" para el cliente "ABC S.A.". Figura 5: Autos vendidos por marca por sucursal por cliente Fuente: Elaboración propia A continuación, queremos ver la evolución de las ventas usando el mismo indicador, pero por tiempo. Para ello, agregamos otro gráfico, en este caso de barras, para ver los autos vendidos por año, mes y día (es decir, agregamos la dimensión tiempo). En este caso ‒y a diferencia de las dimensiones anteriores‒, la dimensión tiempo cuenta con una jerarquía (año, mes, día). Figura 6: Autos vendidos por año Fuente: Elaboración propia Ahora seleccionamos un año (2012), con lo cual vemos las ventas para dicho año. El gráfico nos muestra la evolución mes por mes (hicimos un drill- down en la jerarquía de la dimensión Tiempo). Figura 7: Autos vendidos por mes del año Fuente: Elaboración propia Luego, aplicamos un nuevo drill-down y seleccionamos el mes de junio. Vemos la evolución de las ventas por día. Figura 8: Autos vendidos por día del mes del año Fuente: Elaboración propia Supongamos que queremos ver las ventas de Renault Clio en el año 2013, para el mes 9. Figura 9: Autos vendidos por producto (marca), año y mes Fuente: Elaboración propia En definitiva, como conclusión final, se establece que la capa de presentación de una solución de Business Intelligence es lo que realmente termina visualizando el usuario y es con lo que termina interactuando. Por lo tanto, sus capacidades gráficas, posibilidades de navegación y niveles de usabilidad, entre otros, son factores claves para el éxito de cualquier proyecto de BI. Referencias Cano, J. L. (2007). Business Intelligence: Competir con Información. España: Banesto Fundación Cultural y ESADE. Gartner Says Worldwide Business Intelligence, CPM and Analytic Applications/Performance Management Software Market Grew Seven Percent in 2012. (s.f.) En Qoints. Recuperado de: https://qoints.com/market-insight/gartner-saysworldwide-business-intelligence-cpm-and-analytic-applicationsperformancemanagement-software-market-grew-seven-percent-in-2012/ Revisión del módulo Hasta acá aprendimos ☰ Ciclo de vida del business intelligence De acuerdo con Ralph Kimball (2013), el ciclo de vida de un proyecto de Business Intelligence atraviesa un conjunto de etapas: planificación y gestión del proyecto; definición de los requerimientos del negocio; diseño de la arquitectura técnica; selección e instalación de productos; modelado multidimensional; diseño físico; diseño y desarrollo de procesos ETL; especificación / diseño de la aplicación de BI; desarrollo de la aplicación de BI; despliegue; crecimiento; mantenimiento. ☰ Core Team De acuerdo con Ralph Kimball, Margy Ross, Warren Thornthwaite, Joy Mundy y Bob Becker (2008), el Core Team soporta el grueso de la responsabilidad en el diseño y desarrollo del sistema de BI. ☰ Extended Team De acuerdo con Ralph Kimball, Margy Ross, Warren Thornthwaite, Joy Mundy y Bob Becker (2008), el Extended Team está conformado por roles adicionales que contribuyen al proyecto de BI, pero sobre aspectos muy especializados o temas puntuales. Desde luego, los roles que aquí mencionamos también pueden ser llevados a cabo por las personas que conforman el Core Team. ☰ Taller “Escoger aquella herramienta de Business Intelligence que mejor satisfaga las necesidades de los usuarios en cuanto a las funcionalidades, con la mejor arquitectura y al mejor coste, no es una tarea fácil” (Cano, 2007, p. 163).