UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO FACULTAD DE ESTUDIOS SUPERIORES CUAUTITLAN BUSINESS INTELLIGENCE TRABAJO PROFESIONAL

Transcripción

1 UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO FACULTAD DE ESTUDIOS SUPERIORES CUAUTITLAN BUSINESS INTELLIGENCE TRABAJO PROFESIONAL QUE PARA OBTENER EL TÍTULO DE: LICENCIADO EN INFORMÁTICA PRESENTA: ADRIÁN PÁVEL LUGO FERRER ASESOR: M. C.C. María Araceli Nivón Zaghi CUAUTITLÁN IZCALLI, ESTADO DE MÉXICO, 2014

2 Agradecimientos Le doy gracias a mis padres Ernesto y Blanca por apoyarme en todo momento, Por lo valores que me han inculcado, y por haberme dado la oportunidad de Tener una excelente educación en el transcurso de mi vida. Sobre todo por ser un excelente ejemplo de vida a seguir. A mi hermana Jaqueline por ser parte muy importante de mi vida y darme Alegría y entusiasmo con sus ocurrencias. A Jazz, por ser una parte importante de mi vida, por haberme apoyado En todo momento en las buenas y en las malas, Sobre todo por su paciencia y amor. Le agradezco la confianza, apoyo y dedicación de tiempo a mi asesora Araceli Nivón, Por haber compartido sus conocimientos conmigo y ser una guía vital en este desarrollo.

3 Índice 1. Objetivo 6 2. Introducción 7 3. Marco Teórico Inteligencia de negocios (Business Intelligence) Modelos de datos Granularidad Herramientas de BI Fuentes de información Proceso ETL Metodologías SCRUM MicroStrategy Descripción y relevancia del trabajo profesional Historia profesional Descripción de Technolab Corp Visión Servicios Información comercial Propuesta y descripción de funciones Análisis y Discusión Metodología PIB Bancomer Metodología PIB Descripción general Modelo de datos Objetos de MicroStrategy Objetos de esquema Objetos de Aplicación Beneficio a la sociedad Recomendaciones Recomendaciones a la Licenciatura en Informática Recomendaciones a Technolab Corp Conclusión 91 Bibliografía 93 Glosario 94

4 1. Objetivo Explicar cómo generar un tablero de control en una herramienta de Business Intelligence que muestre los niveles de servicio de cada una de las sucursales activas en la red de BBVA Bancomer. Será un tablero ejecutivo y contendrá de manera muy puntual los indicadores de indisponibilidad de los servicios prestados semanalmente por cada sucursal. El tablero estará desarrollado en la herramienta corporativa MicroStrategy.

5 2. Introducción El objetivo de la licenciatura dentro de la Universidad es preparar gente que sepa crear, administrar y mantener servicios y sistemas de información con el fin de facilitar la toma de decisiones y todas las operaciones dentro de una empresa, cuando el egresado sale al campo laboral. Durante la carrera curse materias tanto administrativas como informáticas, tales como programación, bases de datos, diseño de algoritmos, análisis y diseño de sistemas. De manera que cuando se está dentro de la escuela no se tiene la noción acerca de su aplicación pero la realidad es diferente, porque si bien no se aplica al 100% lo que uno aprende en la escuela, si se aplican las bases, los cimientos debido a una buena preparación, ya que para saber ofrecer una solución técnica se debe primero conocer el negocio y entenderlo. En el presente informe se describe cómo fue mi incursión en el campo laboral, qué conocimientos aprendí en la escuela y apliqué; además se realiza una descripción del trabajo profesional realizado en la empresa Technolab Corp., dentro del cliente BBVA Bancomer, tomando como base la herramienta corporativa del banco que es MicroStrategy. Technolab es una empresa con más de 15 años de experiencia y es especializada en Inteligencia de Negocios (Business Intelligence (BI)) y Enterprise Performance Management (EPM). Technolab es una empresa internacional y opera en 9 países: México, EE.UU, Argentina, Brasil, Canadá, Chile, Perú, Uruguay y España. Tiene más de cien clientes en la mayoría de los sectores: Servicios Financieros, Manufactura, Minería, Industrial, Sector Comercial y Público. Está dedicada a seguir soluciones de negocio que mejoran el desempeño, rentabilidad, el pronóstico y los procesos de consolidación financiera; es proveedor de servicios cuya misión es ayudar a sus clientes de forma más eficaz utilizando la tecnología para resolver problemas del mundo real. Algunos de sus clientes son: Televisa, BBVA Bancomer, Banamex, Banorte, Banco de Chile, Grupo Bimbo, Comex, Sony, Movistar, entre otros. En el presente trabajo de tesis se introduce con un Marco teórico en donde se tratan los temas de Inteligencia de negocios, modelado de base de datos, procesos ETL, metodologías y MicroStrategy; en seguida se presenta la descripción del trabajo profesional desempeñado. El objetivo del proyecto fue tener los indicadores de Indisponibilidad de las Sucursales BBVA Bancomer en México, para identificar las principales causas de Indisponibilidad y en un futuro corregir esos lapsos de Indisponibilidad.

6 3. Marco Teórico 3.1 Inteligencia de Negocios (Business Intelligence) En un artículo de 1958, el investigador de IBM Hans Peter Luhn utiliza el término Inteligencia de Negocio. Se define la inteligencia como: La capacidad de comprender las interrelaciones de los hechos presentados en tal forma como para orientar la acción hacia una meta deseada. El objetivo básico de la Business Intelligence es apoyar de forma sostenible y continuada a las organizaciones para mejorar su competitividad, facilitando la información necesaria para la toma de decisiones. El primero que acuñó el término fue Howard Dresner que, cuando era consultor de Gartner, popularizó Business Intelligence o BI como un término paraguas para describir un conjunto de conceptos y métodos que mejoraran la toma de decisiones, utilizando información sobre qué había sucedido (hechos). Mediante el uso de tecnologías y las metodologías de Business Intelligence pretendemos convertir datos en información y a partir de la información ser capaces de descubrir conocimiento. La definición de BI nos dice: BI es un proceso interactivo para explorar y analizar información estructurada sobre un área (normalmente almacenada en un datawarehouse), para descubrir tendencias o patrones, a partir de los cuales derivan ideas y extraer conclusiones. El proceso de Business Intelligence incluye la comunicación de los descubrimientos y efectuar los cambios. Las áreas incluyen clientes, proveedores, productos, servicios y competidores. Si se analiza esta definición podemos obtener lo siguiente: Proceso interactivo: Al hablar de BI estamos suponiendo que se trata de un análisis de información continuando en el tiempo, no sólo en un momento puntual. El análisis a través del tiempo nos puede aportar mucho valor. Explorar: En los proyectos de BI hay un momento inicial en el que por primera vez accedemos a información que nos facilita su interpretación; en la primera fase, lo que se hace es explorar para comprender qué sucede en nuestro negocio. Analizar: Pretendemos descubrir relaciones entre variables, tendencias, es decir, cuál puede ser la evolución de la variable, o patrones. Si un cliente tiene una serie de características, cuál es la probabilidad que otro con similares características actué igual que el anterior. Información estructurada y datawarehouse: La información que utilizamos en BI está almacenada en tablas relacionadas entre ellas. Las tablas tienen registros y cada uno de los registros tiene distintos valores para cada uno de los atributos. Estas tablas están almacenadas en lo que conocemos

7 como datawarehouse o almacén de datos. Área de análisis: Todo proyecto de BI debe tener un objeto de análisis concreto. Nos podemos centrar en los clientes, los productos, los resultados de una localización, etc. Que pretendemos analizar con detalle y con un objetivo concreto. Comunicar los resultados y efectuar los cambios: Un objetivo fundamental de BI es que, una vez descubierto algo, sea comunicado a aquellas personas que tengan que realizar los cambios pertinentes en la organización para mejorar nuestra competitividad. Una definición 1 más amplia es la que proponen en The datawarehouse Institute: Business Intelligence (BI) es un término paraguas que abarca los procesos, las herramientas y las tecnologías para convertir datos en información, información en conocimiento y planes para conducir de forma eficaz las actividades de los negocios. BI abarca las tecnologías de datawarehousing los procesos en el 'back end' 2, consultas, informes, análisis y las herramientas para mostrar información (estas son las herramientas de BI) y los procesos en el 'front end'. Uno de los objetivos básicos de los sistemas de información es que nos ayuden a la toma de decisiones. Cuando un responsable tiene que tomar una decisión pide o busca información, que le servirá para reducir la incertidumbre. Sin embargo, aunque todos la utilicen, no todos los responsables recogen la misma información: depende de muchos factores, como puede ser su experiencia, formación, disponibilidad, etc. A partir de los datos que nos proporciona el sistema de BI podemos descubrir conocimiento. Por ejemplo, en un cocesionario de coches descubrimos la relación entre el número de visitas al concesionario y el número de vehículos vendidos en el mes siguiente. Parece claro que el número de visitas al concesionario parece un indicador clave, pero todos los concesionarios lo recogen? Los beneficios que se pueden obtener a través del uso de BI pueden ser distintos tipos: Beneficios tangibles, por ejemplo: reducción de costes, generación de ingresos, reducción de tiempos para las distintas actividades del negocio. Beneficios intangibles, el hecho de que tengamos disponible la información para la toma de decisiones hará que más usuarios utilicen dicha información para tomar decisiones y mejorar la nuestra posición competitiva. Beneficios estratégicos, todos aquellos que nos facilitan la formulación de la estrategia, es decir, a qué clientes, mercados o con qué productos 1 Enterprise Business Intelligence: Strategies and Technologies for Deploying BI on an Enterprise Scale, Wayne W. Eckerson y Cindi Howson, TDWI Report Series, Agosto Los términos back end y front end comunmente usados en Sistemas de Información significan, respectivamente, la parte más cercana al área tecnológica y más cercana a los usuarios.

8 dirigirnos. A continuación se muestran algunos ejemplos de cómo BI nos puede generar beneficios: Beneficios tangibles, generación de ingresos: Mejorar la adquisición de clientes y su conversión mediante el uso de la segmentación. Reducir la tasa de abandono de clientes, incrementar su fidelidad, teniendo en cuenta cuál es su valor. Incrementar los ingresos por crecimiento de las ventas. Aumentar los resultados, consiguiendo que nuestros clientes actuales compren más productos o servicios. Evitar las pérdidas producidas por las ventas de nuestros competidores. Aumentar la rentabilidad por el acceso a información detallada de productos, clientes, etc. Conocer mejor cuáles son las características demográficas de nuestra zona de influencia. Hacer crecer la participación del mercado. Reducir el tiempo de lanzamiento de nuevos productos o servicios. Mejorar aquellas actividades relacionadas con la captura de datos. Analizar la cesta de la compra y la afinidad de venta entre los productos. Medir la efectividad de las campañas rápidamente y ser capaces de hacer ajustes durante el ciclo de vida de las mismas. Optimizar las acciones de marketing. Identificar clientes rentables en segmentos no rentables. Analizar a la competencia cuando establecemos precios. Beneficios tangibles, reducción de costes: o Negociar mejores precios con los proveedores, identificar a los proveedores más importantes, gestionar descuentos por cantidades de compra; permitir el análisis del cumplimiento de los proveedores y asignar las compras de acuerdo con ellos; medir el nivel de calidad, servicio y precio. o Reducir o reasignar el personal necesario para llevar a cabo los procesos. o Incrementar la productividad con información más inmediata y mejor. o Aumentar el control de costes. o Disminuir gastos. o Eliminar ineficiencias y reducir los costes operativos al generar una sola

9 versión de la verdad. o Reducir los créditos incobrables. o Eliminarlas sobreproducciones de productos. o Acortar los tiempos de respuesta a las peticiones de informes. o Analizar los problemas, reparaciones y defectos y proveer la información para hacer un seguimiento y corregir los problemas recurrentes. o Proveer el suministro dentro del plazo. o Reducir las devoluciones de productos. o Analizar la productividad de los empleados Beneficios intangibles: o Optimizar la atención a los clientes. o Aumentar la satisfacción de los clientes. Cuando se habla de Business Intelligence es necesario definir un área de negocio, siempre se debe pretender medir un resultado, ingresos, costes, ventas, etc. Para empezar debemos definir cuál es nuestro modelo de negocio y cuáles son las métricas que vamos a utilizar. Se plantea un enunciado con el contexto de negocio y se establecen las preguntas de negocio que se quieren responder, a continuación se muestra un ejemplo: Dicha empresa tiene distintas líneas fijas entre ciudades, tiene camiones propios. Aunque para parte de las rutas subcontrata camiones a otras empresas. Para simplificar el ejemplo, vamos a suponer que el reparto se subcontrata, en su totalidad, a terceros. Las preguntas de negocio que se responderán son: 1. Es rentable tener camiones propios? 2. Todas las rutas son rentables? 3. Qué rutas nos interesa potenciar? Si se analiza cada una de las preguntas anteriores podremos identificar si tenemos los elementos necesarios para poder responderlas, comencemos por los camiones: Cuál es la información que disponemos de ellos?, es posible tener información sobre costes de mantenimiento, reparaciones, consumos, seguros, amortización del camión. También podemos tener información de los costos de los choferes. Después nos interesa saber cuáles son las rutas rentables y cuáles no; para eso es necesario tener la información de los ingresos que han generado en cada una de las rutas, a estos ingresos debemos restar los costes de los viajes que se han realizado, con medios propios o subcontratados. Ahora ya estamos en disposición de saber qué rutas son rentables y cuáles no. Entonces, De qué factores depende el resultado?, depende de:

10 Los precios que se cobran por el servicio de transporte. El nivel de ocupación del camión en cada viaje. Esta información es la que nos permitirá responder a la tercera de las preguntas: Qué rutas nos interesa potencia? La respuesta es: aquellas en las que el porcentaje de ocupación del camión es bajo. Construir un modelo nos permite analizar qué está sucediendo y para poder construirlo debemos documentar, probar, y desarrollar la teoría de cómo funciona el negocio. Es importante construir un modelo de negocio porque ese será la base para el modelo de datos. Una vez definido el modelo de negocio debemos determinar qué información tenemos para analizarlo. 3.2 Modelos de datos Un modelo de datos estructurado es una representación discreta de una serie de entidades de la vida real relacionadas entre sí. La técnica de modelado tradicional para los sistemas gira en torno al modelo de entidad-relación. Desafortunadamente, para las aplicaciones analíticas que son relevantes para el BI el modelo entidad relación pierde muchas ventajas. Otra definición más contempla al modelo de datos como un lenguaje orientado a describir una Base de Datos. Un modelo de datos nos permite describir: La estructura de datos de la base: El tipo de los datos que hay en la base y la forma en que se relacionan. Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para reflejar correctamente la realidad deseada. Operaciones de manipulación de los datos: típicamente, operaciones de agregado, borrado, modificación y recuperación de los datos de la base. La representación de un modelo multidimensional es un modelo tipo estrella. Una tabla de hechos que contiene los registros que hacer referencia a objetos visibles, dentro del contexto del negocio. En las bases de datos usadas para data warehousing, un esquema en estrella es un modelo de datos que tiene una tabla de hechos (aquello que queremos medir o analizar), y alrededor las tablas de dimensiones (cómo lo queremos medir). En los desarrollos de Business Intelligence este tipo de modelo es el más óptimo y el más utilizado. Las tablas de dimensiones tendrán siempre una clave primaria simple, mientras que en la tabla de hechos, la clave principal estará compuesta por las claves principales de las tablas de dimensiones. Este esquema es ideal por su simplicidad y velocidad para ser usado en análisis multidimensionales. Permite acceder tanto a datos agregados como de detalle. El diseño de esquemas en estrella permite implementar la funcionalidad de una base de datos multidimensional utilizando una clásica base de datos relacional. Otra gran ventaja de utilizar este tipo de esquema es su simplicidad en las consultas. Las consultas

11 no son complicadas, ya que las condiciones y las uniones (join) necesarias sólo involucran a la tabla de hechos y a las dimensiones, no haciendo falta que se encadenen uniones y condiciones a dos o más niveles. Además ofrece un mejor rendimiento y velocidad pues permite indexar las dimensiones de forma individualizada sin que repercuta en el rendimiento de la base de datos en su conjunto. Hay una dimensión que en todo proyecto de BI debe de aparecer para poder movernos a través del tiempo, y es precisamente la Dimensión Tiempo, el atributo de Fecha se compone por Día, Mes, Trimestre, Año. Esto nos permitirá analizar si las ventas son similares todos los días de la semana o no, si se vende más en un mes determinado Granularidad La granularidad es la diferencia del nivel de detalle en el análisis. Debemos decidir y determinar cuál es el nivel de granularidad necesario para poder construir un modelo que nos permita responder a aquellas preguntas que nos hemos formulado, ya que si determinamos un nivel podremos responder unas preguntas pero no otras. En el caso de que nos interese tener distintos niveles de agregación podemos recurrir a las jerarquías, que nos permitirán agregar la información a distintos niveles, tales como División, Zona y Sucursal ó Familia, Subfamilia y Producto. Es mejor construir un modelo al máximo nivel de detalle o el nivel más bajo. 3.3 Herramientas de BI En el siguiente diagrama se ven los componentes de Business Intelligence.

12 Figura 1. Estructura de Business Intelligence

13 Los componentes son: Figura 2. Componentes de Business Intelligence Data sources/ Fuentes de Información: Son la fuente de información de las cuales alimentaremos de información el datawarehouse. Proceso ETL: Es la extracción, transformación y carga de los datos en el datawarehouse. Antes de almacenar los datos en un datawarehouse, éstos deben ser transformados, filtrados y redefinidos. La información que se tiene en un sistema transaccional no está preparada para la toma de decisiones. Datawarehouse: Se almacena el Metadata o Diccionario de datos también, se busca almacenar los datos de una forma que maximice su flexibilidad, facilidad de acceso y administración. Data Mart: Es un subconjunto de datos de un área específica ejemplo Ventas, Recursos Humanos, etc. Análisis/Explotación: Nos permiten el análisis y la navegación. Para describir los distintos componentes vamos a comenzar primero por las fuentes de información, después el resto de los componentes y se finalizará con las herramientas de análisis. En un proyecto real se debe definir primero cuáles son los objetivos y el alcance de la solución. 3.4 Fuentes de Información

14 Un datawarehouse es la principal fuente de información que alimenta el procesamiento analítico dentro de una organización; un datawarehouse es un repositorio centralizado de información, se organiza en torno a las áreas importantes dentro de la organización, es una fuente de datos consultable para una empresa. Sistemas de información departamentales: previsiones, presupuestos, hojas de cálculo, etc. Existen muchos factores que contribuyen a la complejidad de cargar la información en un datawarehouse. Uno de los principales es el número de fuentes de información distintas de las que cargamos la información. La información que se carga normalmente en un datawarehouse es estructurada, es decir, aquella que se puede almacenar en tablas, en la mayoría de los casos es numérica. Cada vez más la tecnología nos permite trabajar con información no estructurada. Un punto clave es identificar las fuentes más apropiadas de las cuales recuperaremos la información, debemos analizar los formatos, la disponibilidad y la calidad de la información. Tenemos que analizar si la información de la que disponemos es la que necesitamos para alimentar el modelo de negocios que hemos definido previamente. En este punto, muchas vece descubrimos que no disponemos de la información necesaria para completar el modelo de negocio. Una vez decididas las fuentes de información debemos verificar la calidad de los datos. Si en el datawarehouse hay errores, éstos se propagarán a lo largo de toda la organización y son muy difíciles de localizar. Además puede ocasionar que se tomen decisiones incorrectas que afecten a los resultados de la organización. Los errores en los datos pueden provenir de los sistemas transaccionales de los que recuperamos los datos, del proceso ETL, o del propio datawarehouse. En algunas organizaciones existen comprobaciones tanto de forma manual como de forma automática, teniendo en cuenta distintos niveles de detalle y variando en los periodos de tiempo para verificar que los datos cargados coincidan con los de las fuentes de datos origen. El proceso debe ser continuo para seguir la mejora en la calidad de los datos. Este proceso nos puede ayudar a mejorar nuestros sistemas transaccionales, corregir errores en el datawarehouse, mejorar el proceso ETL o incluso mejorar los modelos de negocio por parte de los usuarios de Business Intelligence. 3.5 Proceso ETL Una premisa básica en la construcción de un datawarehouse son los repositorios de datos desde diferentes fuentes. Este proceso trata de recuperar los datos fuente de información y alimentar el datawarehouse. Es una serie de aplicaciones que extraen los conjuntos de datos de las diversas fuentes, los lleva a un área de almacenamieto de datos llamada staging, se aplican una serie de pasos para preparar los datos para migrarlos al Warehouse. Las ventajas que se obtienen mediante un proceso ETL son las siguientes: Extraer los datos desde la ubicación origen. Mapear los datos de su forma original en un modelo de datos adecuado para su manipulación. Validar la limpieza del dato.

15 Aplicar cualquier transformación que los datos requieran antes de cargarlos en el repositorio. El proceso ETL se divide en 5 subprocesos: 1. Extracción. Este proceso recupera los datos físicamente de las distintas fuentes de información. En este momento disponemos de los datos en bruto. 2. Limpieza. Este proceso recupera los datos en bruto y comprueba su calidad, elimina los duplicados y, cuando es posible, corrige los valores erróneos y completa los valores vacíos, es decir se transforman los datos (cuando sea posible) para reducir los errores de carga. En este momento disponemos de datos limpios y de alta calidad. 3. Transformación. Este proceso recupera los datos limpios y de alta calidad y los estructura y sumariza en los distintos modelos de análisis. El resultado de este proceso es la obtención de datos limpios, consistentes, sumarizados y útiles. 4. Integración. Este proceso valida que los datos que cargamos en el datawarehouse son consistentes con las definiciones y formatos del datawarehouse; los integra en los distintos modelos de las distintas áreas de negocio que hemos definido en el mismo. Estos procesos pueden ser complejos. 5. Actualización. Este proceso es el que nos permite añadir los nuevos datos al datawarehouse. Se detalla cada uno de los subprocesos: Extracción. Este subproceso responde principalmente dos preguntas: Qué datos se deben extraer? Cómo se deben extraer esos datos? La extracción de los datos se puede realizar de forma manual o utilizando herramientas de ETL. La alternativa más rentable es la que provee las herramientas especializadas de ETL como Informática, ya que son diseñadas para llevar a cabo esta función y nos permiten visualizar el proceso y detectar los errores durante el proceso o durante la carga. El objetivo principal de la extracción es extraer tan sólo aquellos datos de los sistemas transaccionales que son necesarios y prepararlos para el resto de los subprocesos de ETL. Para ello se deben determinar las mejores fuentes de información las de mejor calidad; con tal finalidad, deberemos analizar las fuentes disponibles y escoger aquellas que sean mejores. Limpieza. Los sistemas transaccionales contienen datos que no han sido depurados y que deben ser limpiados. Las herramientas de ETL tienen funcionalidades de limpieza de datos. Si no llevamos a cabo este subproceso de forma correcta los resultados mostrados estarán mal, por ejemplo, mostraremos datos duplicados.

16 La limpieza de datos se divide en distintas etapas: Depurar los valores: Este proceso localiza e identifica los elementos individuales de información en las fuentes de datos y los aísla en ficheros destino. Por ejemplo: separar el nombre completo en nombre, primer apellido, segundo apellido. Corregir: Este proceso corrige los valores individuales de los atributos usando algoritmos de corrección y fuentes de datos externas. Por ejemplo: comprueba una dirección y el código postal correspondiente. Estandarizar: Este proceso aplica rutinas de conversión para transformar valores en formatos definidos aplicando procedimientos de estandarización y definidos por las reglas de negocio. Relacionar: Este proceso busca y relaciona los valores de los registros, corrigiéndolos y estandarizándolos, basándose en reglas de negocio para eliminar duplicados. Consolidar: Este proceso analiza e identifica relaciones entre registros relacionados y los junta en una sola representación. Transformación. La transformación de los datos se hace partiendo de los datos una vez limpios. Transformamos los datos de acuerdo con las reglas de negocio. La transformación incluye: Conversión de tipo de dato. Es analizar las cadenas que representan valores enteros y numéricos y su transformación adecuada en el destino, y la conversión de las representaciones físicas de valor de una plataforma a otra. Limpieza del dato. Es aplicar las reglas que vayamos descubriendo a través del proceso; se utiliza para corregir los datos que sabemos son incorrectos. Integración. Esto incluye la explotación de tablas y llaves foráneas que tengan relación con otras tablas, estas son independientes de las reglas del negocio. Validar integridad referencial. Las relaciones de llaves foráneas son expuestas a través de perfiles en los documentos de interacción, estos componentes validan que no se viole la integridad referencial y destaca los campos que no son llave y cualquier campo foráneo detectado. Derivaciones. Cualquier transformación basada en las reglas de negocio, cálculos nuevos, manipulaciones de cadenas, todo lo que se necesite aplicar a los datos para moverlos de la fuente al destino serán en este paso. Desnormalización y renormalización. Frecuentemente los datos vienen normalizados desde el sistema fuente, es necesario romperlo en una forma no normalizada para las dimensiones de nuestro repositorio. Agregaciones. Cualquier agregación de información que se utiliza para resumir o cualquier dimensión de cubo se puede hacer en el área staging.

17 Auditoria de Información. Es una cuestión para validar la integridad referencial, siempre se usa para los cálculos de alguna información de auditoria, como cuantas filas, cuantas columnas, cuantas tablas, incluso también el tiempo y fecha de la extracción, y tiempo y fecha de la transformación. Conversión de nulos. Los nulos aparecen en diferentes formas, desde los nulos del sistema que representan valores nulos, es por eso que se les aplica una conversión a valores diferentes de nulos. Carga. Se basa en el movimiento de los datos transformados en la data Warehouse. Las premisas importantes en este proceso son: en donde y en cuantas máquinas vivirá el repositorio; y la frecuencia y el volumen de actualización de los datos. Este proceso determina la periodicidad con el que haremos nuevas cargas de datos al datawarehouse. Debido a la criticidad del proceso de extracción, transformación y carga, las herramientas ETL son claves en los proyectos de Business Intelligence. Datawarehouse. Cuando queremos analizar un problema empresarial, normalmente la información que necesitamos proviene de distintos sistemas, pero nosotros la requerimos en un mismo entorno para facilitar su análisis. Normalmente, en los sistemas transaccionales no tenemos la información preparada para ser analizada; sólo tenemos información de las transacciones actuales, pero no la de los periodos anteriores a la de las previsiones. La aparición de los datawarehouse o Almacenes de datos son la respuesta a las necesidades de los usuarios que necesitan información consistente, integrada, histórica y preparada para ser analizada para poder tomar decisiones. Al recuperar la información de los distintos sistemas, tanto transaccionales como departamentales o externos, y almacenándolos en un entorno integrado de información diseñado por los usuarios, el datawarehouse nos permitirá analizar la información contextualmente y relacionada dentro de la organización. Un datawarehouse debe contener las siguientes características: Orientado a un área: Significa que cada parte del datawarehouse está construida para resolver un problema de negocio, que ha sido definido por los tomadores de decisiones. Por ejemplo: Entender los hábitos de compra de nuestros clientes, analizar la calidad de nuestros productos, etc. Para poder analizar un problema de negocio necesitamos información que proviene de distintos sistemas y la organizamos entorno a áreas: ventas, clientes, elementos de transporte, etc. Integrado: La información debe ser transformada en medias comunes, códigos comunes y formatos comunes para que pueda ser útil. La integración permite a las organizaciones implementar la estandarización de sus definiciones, por ejemplo: la moneda en la que están expresados los importes. Indexado en el tiempo: Significa que se mantiene la información histórica y

18 se almacena referida a determinadas unidades de tiempo, tales como semanas, meses, trimestre o año. Ello nos permitirá analizar, por ejemplo, la evolución de las ventas en los periodos que queramos. No volátil: Significa que los usuarios no la mantienen, como lo harían en los entornos transaccionales. La información se almacena para la toma de decisiones. El alcance del datawarehouse puede ser departamental o a nivel corporativo. El datawarehouse no sólo es información sino también las herramientas de consulta, análisis y presentación de la información. Si el datawarehouse está construido adecuadamente proporciona un entorno de información que nos permitirá nuevo conocimiento y generar valor. El trabajo de construir un datawarehouse corporativo puede generar inflexibilidades, o ser costoso y requerir plazos de tiempo que las organizaciones no están dispuestos a aceptar. En parte, estas razones originaron la aparición de los Data Mart. Un componente crítico de un datawarehouse es el Metadata. El Metadata es el repositorio central de información de la información. Nos da el significado de cada uno de los componentes y sus atributos que residen en el datawarehouse, Puede incluir definiciones de negocio, descripciones detalladas de los tipos de datos, formatos y otras características. Data Mart. Los Data Mart están dirigidos a una comunidad de usuarios dentro de la organización, que puede estar formada por los miembros de un departamento, o por los usuarios de un determinado nivel organizativo, o por un grupo de trabajo multidisciplinario con objetivos comunes. Los Data Mart almacenan información de un número limitado de áreas; por ejemplo, puede ser de marketing y ventas. Normalmente los Data Mart son más pequeños que los datawarehouse. Tienen menos cantidad de información, menos modelos de negocio y son utilizados por un número inferior de usuarios. Los Data Mart pueden ser independientes o dependientes. Los primero son alimentados directamente de los orígenes de información, mientras que los segundos se alimentan desde el datawarehouse corporativo.

19 Figura 3. Tipos de Datamart Análisis/Explotación. Existen distintas tecnologías que nos permiten analizar la información que reside en un datawarehouse. Los usuarios necesitan analizar información a distintos niveles de agregación y sobre múltiples dimensiones. Los usuarios pueden hacer este análisis al máximo nivel de agregación o al máximo de detalle. OLAP provee de estas funcionalidades y algunas más, con la flexibilidad necesaria para descubrir las relaciones y las tendencias que otras herramientas menos flexibles no pueden aportar. A este tipo de análisis se les llama multidimensionales, porque nos facilitan el análisis de un hecho desde distintas perspectivas o dimensiones. Esta es la forma natural que se aplica para analizar la información por parte de los tomadores de decisiones, ya que los modelos de negocio normalmente son multidimensionales. La visualización de la información es independiente respecto de cómo se haya almacenado. OLAP debe cumplir las siguientes reglas: Rápido: Debe ser rápido, es necesario lanzar consultas y ver los resultados inmediatamente. Análisis: Debe soportar la lógica de negocio y análisis estadísticos que sean necesarios para los usuarios. Compartido: Tiene que manejar múltiples actualizaciones de forma segura y rápida. Multidimensional: Tiene que proveer de una visión conceptual de la información a través de distintas dimensiones.

20 Información: debe poder manejar toda la información relevante y la información derivada. Representación gráfica del OLAP. Figura 4. Cubo OLAP En el cubo tenemos las unidades vendidas de cada uno de los libros, para los distintos clientes y en los distintos años. Este es el concepto de multimensionalidad. Disponemos de las unidades vendidas de cada uno de los libros para cada uno de los clientes y en cada uno de los años: el contenido de un cubo individual son las ventas de un libro a un cliente en un año. Los contenidos de cada uno de los cubos individuales del cubo recogen lo que llamamos hechos. Las herramientas OLAP nos permiten rotar los cubos, es decir, cambiar el orden de las distintas dimensiones: En lugar de analizar por clientes, también podemos analizarlo por libros, ya que los usuarios que lo quieren consultar son distintos y tienen distintas necesidades. Las principales herramientas de Business Intelligence son: Generadores de informes: Utilizadas por desarrolladores profesionales para crear informes estándar para grupos, departamentos o la organización. Herramientas de usuario final de consultas e informes: Empleadas por usuarios finales para crear informes para ellos mismo o para otros; no requieren programación. Herramientas OLAP; Permiten a los usuarios finales tratar la información de forma multidimensional para explotarla desde distintas perspectivas y periodos de tiempo. Herramientas de Dashboard y Scorecard: Permite a los usuarios finales ver información crítica para el rendimiento con un simple vistazo utilizando íconos gráficos y con la posibilidad de ver más detalle para analizar información detallada e informes, si lo desean. Herramientas de planificación. Modelización y consolidación: Permite a los

21 analistas y a los usuarios finales crear planes de negocio y simulaciones con la información de Business Intelligence. Pueden ser para elaborar la planificación, los presupuestos, las previsiones. Estas herramientas proveen a los dashboards y los scorecards con los objetivos y los umbrales de las métricas. Herramientas datamining: Permiten a estadísticos o analistas de negocio crear modelos estadísticos de las actividades de los negocios. Datamining es el proceso para descubrir e interpretar patrones desconocidos en la información mediante los cuales resolver problemas de negocio. Los usos más habituales del datamining son: segmentación, venta cruzada, sendas de consumo, clasificación, previsiones, optimización, etc. 3.6 Metodologías Es un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas de información. Una metodología de desarrollo de software se refiere a un framework que es usado para estructurar, planear y controlar el proceso de desarrollo en sistemas de información. El framework para metodología de desarrollo se software consiste en: Una filosofía de desarrollo de programas de computación con el enfoque del proceso de desarrollo de software. Herramientas, modelos y métodos para asistir al proceso de desarrollo de software SCRUM Scrum es un proceso ágil y liviano que sirve para administrar el desarrollo de software. El desarrollo se realiza en forma iterativa e incremental (una iteración es un ciclo corto de construcción repetitivo). Cada ciclo o iteración termina con una pieza de software ejecutable que incorpora nueva funcionalidad. Las iteraciones en general tienen una duración entre 2 y 4 semanas. Scrum se utiliza como marco para otras prácticas de ingeniería de software, como ser la integración continua o la programación de a pares. Scrum se focaliza en priorizar el trabajo en función del valor que tenga para el negocio, maximizando la utilidad de lo que se construye y el retorno de la inversión. Está diseñado especialmente para adaptarse a los cambios en los requerimientos, sobre todo en mercados de alta competitividad. Los requerimientos y las prioridades se revisan y ajustan durante el proyecto en intervalos muy cortos y regulares. De esta manera es posible adaptar en tiempo real el producto que se está construyendo a las necesidades del cliente. Se busca entregar software que realmente resuelva las necesidades, aumentando la satisfacción del cliente. En Scrum, el equipo se focaliza en una única cosa: construir software de calidad. Por otro lado, la gestión de un proyecto Scrum se focaliza en definir cuáles son las características que debe tener el producto a construir (qué construir, qué no y en

22 qué orden) y en remover cualquier obstáculo que pudiera entorpecer la tarea del equipo de desarrollo. Se busca que los equipos sean lo más efectivos y productivos posibles. Scrum tiene un conjunto de reglas muy pequeño y simple basado en los principios de inspección continua, adaptación, auto-gestión e innovación. El cliente se entusiasma y compromete con el proyecto dado que ve crecer el producto iteración a iteración y encuentra las herramientas para alinear el desarrollo con los objetivos de negocio de su empresa. Por otro lado, los desarrolladores encuentran un ámbito propicio para desarrollar sus capacidades profesionales y esto resulta en un incremento en la motivación de los integrantes del equipo. Figura 5. Ciclo de Proceso SCRUM Cómo funciona? Se debe de tener un marco de trabajo el cual se compone de lo siguiente: Roles: Product Owner, Scrum Master y Scrum Team Reuniones: Sprint Planning, Sprint Review, Sprint retrospective y Daily Scrum Meeting Artefactos: Product Backlog, Sprint Backlog, Burnup Chart y Burndown Chart Roles:

23 Product Owner = Gestor del Producto: o Responsable por la definición del alcance del proyecto (negocio). o Responsable por la priorización del trabajo a ser realizado (negocio). o Responsable por la orientación del equipo durante el proyecto. o Responsable por validar los productos desarrollados. Scrum Master = Coordinador del Equipo: o Responsable por mantener el equipo con foco en el proyecto (negocio). o Responsable por mantener los valores y las prácticas ágiles de Scrum durante el proyecto (proceso). o Responsable por mantener el ritmo sustentable (control). o Responsable por eliminar los conflictos e impedimentos del proyecto con el exterior (riesgos). o Responsable por las revisiones diarias (resultados). Scrum Team = Equipo Scrum: o Sin clasificación jerárquica de roles (horizontal). o Todos actuando en múltiples funciones (competencia). o Todos comprometidos con el plan del sprint (foco). o Escalonables mediante Scrum de Scrums (>100).

24 Reunión de Planificación de Sprint Parámetros: Objetivo: 1 por Sprint Duración 8 hrs aproximadamente. Se realiza en dos partes Figura 6. Etapa de planificación. Tomando como base las prioridades y necesidades de negocio del cliente, se determinan cuáles y cómo van a ser las funcionalidades que se van a incorporar al producto con el próximo sprint. Reunión Parte 1: Puede tener una duración de una a cuatro horas, se decide qué elementos del product backlog se van a desarrollar. Reunión Parte 2: Se desglosan los ítems seleccionados en tareas necesarias, se estima el esfuerzo que necesita cada una y se asigna a las personas del equipo. Reunión Diaria

25 Parámetros: Diaria 15 minutos De pie No es para resolver problemas Tres preguntas: Qué hice desde el último encuentro? Qué voy a hacer de ahora hasta el próximo encuentro? Cuáles son los problemas que tengo que afectan a mi actividad? Puercos y gallinas están invitados: Solo los puercos pueden hablar Involucrar al resto ayuda a evitar otras reuniones innecesarias El diálogo cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo. Reunión de Revisión de Sprint Parámetros: Objetivo: 1 por Sprint Duración 4 hrs. aproximadamente Preparación < 2 hrs.: Generalmente se presenta como una Demo del funcionamiento del producto. El equipo presenta lo que hizo durante el Sprint al Product Owner Se valida producto según criterios de aceptación identificados al inicio del Sprint Participantes: Cliente Product Owner Equipo Otros interesados Reunión de Retrospectiva de Sprint Parámetros:

26 Objetivo: 1 por Sprint Duración 4 hrs aproximadamente Después de la Reunión de Revisión El equipo analiza resultados y determina lecciones aprendidas Tres Preguntas Qué tenemos que empezar a hacer? Qué debemos dejar de hacer? Qué debemos continuar haciendo? Participantes: Solo el Equipo A veces el Product Owner es inlcuido Scrum para software emplea dos formatos para el registro y comunicación de los requisitos: Product Backlog: Se sitúa en el área de requisitos o necesidades de negocio desde el punto de vista del cliente. Sprint Backlog: Se sitúa en el área de especificaciones de los requisitos de software necesarios para dar respuesta a las funcionalidades esperadas por el cliente. Artefactos: Product Backlog: Es el inventario de funcionalidades, mejoras, tecnología y corrección de errores que deben incorporarse al producto a través de las sucesivas iteraciones de desarrollo. Representa todo aquello que esperan los clientes, usuarios, y en general los interesados en el producto. No es un documento de requerimientos (ERS), sino una herramienta de referencia para el equipo. A diferencia de una ERS, este nunca se da por completo y está en continua evolución. En Bancomer, algunos de estos ítems se van a encontrar estimados. Son los requerimientos a los que se les hizo una Gestión de Iniciativa. Estimados o no, cada ítem será re-estimado en la 2da parte de la Reunión de Planificación del Sprint, siguiendo el método ágil. Independientemente del formato, cada ítem del Product Backlog debería incluir al menos la siguiente información:

27 Identificador único de la funcionalidad o trabajo Descripción de la funcionalidad Campo de Priorización Estimación Observaciones Criterio de validación Persona asignada N de Sprint en el que se realiza Módulo del sistema al que pertenece Sprint Backlog: Es la lista que descompone las funcionalidades del product backlog en las tareas necesarias para construir un incremento. Realizado de forma conjunta por el equipo, identificando las tareas para conseguir el objetivo del sprint. Sólo el equipo lo puede modificar durante el sprint. El tamaño de cada tarea está en un rango de 4 a 16 horas de trabajo. Debe estar visible para todo el equipo. 3.7 MICROSTRATEGY MicroStrategy es un vendedor de software OLAP, de inteligencia de negocio y de informes de empresa. El software de MicroStrategy permite crear informes y análisis de los datos almacenados en una base de datos relacional y de otras fuentes. La suite de software más reciente se llama MicroStrategy 9. MicroStrategy proporciona una serie de componentes para la visualización y análisis de información; conforme al cuadrante mágico de Gartner, actualmente es una de las herramientas líderes en el mercado para el desarrollo de Business Intelligence.

28 Figura 7. Herramientas de BI MicroStrategy es una tecnología que aglutina una serie de conceptos, técnicas y herramientas que permiten la integración y análisis de los datos, facilitando la obtención de información y conocimiento estratégico, y brindando un valioso apoyo a la gestión de negocios. Interface Web Características Intuitivas Ambiente Seguro Reportes Ad Hoc Motor Analítico Motor SQL Dinámico Motor de Seguridad Alto rendimiento Múltiples orígenes de datos Scripts de Administración Figura 8. Estructura MicroStrategy

29 En MicroStrategy hay dos tipos de proyectos, a dos niveles y tres niveles; a los niveles consta de dos conexiones directas base de datos por ODBC. Una primera conexión al Warehouse la cual puede ser con múltiples bases de datos (Teradata, Oracle, DB2, Excel) y una segunda a la metadata del proyecto. A continuación se muestra la arquitectura a dos niveles. Figura 9. Arquitectura dos niveles MicroStrategy En la arquitectura de tres niveles presenta y forma en una de las herramientas líderes Business Intelligence, gestión de rendimiento y soluciones de reporting y cuadros de mando. Figura 10. Arquitectura tres niveles MicroStrategy MicroStrategy es la herramienta corporativa de BI para BBVA Bancomer y todos

30 los desarrollos se deben de ajustar a esta herramienta. 4 Descripción y relevancia del Trabajo Profesional 4.1 Historia Profesional Concluí mis estudios en la Facultad de Estudios Superiores Cuautitlán en diciembre de 2011, comencé a buscar trabajo en enero de 2012 y en el mes de febrero asistí a varias entrevistas en diferentes empresas. Una de ellas fue en las instalaciones de Technolab Corp me sentía nervioso ya que era el primer empleo que se relacionaba directamente con lo que estudie, el perfil de la vacante incluía conocimiento de Business Intelligence, base de datos, metodologías y ganas de trabajar. Antes del día de la entrevista me dedique a investigar y estudiar que era Business Intelligence o Inteligencia de Negocios, para que el día de la entrevista tuviera las bases y responder lo que me preguntaran; y así fue, el día de la entrevista afortunadamente me fue bien y después de un proceso de selección fui contratado. En un principio estuve en capacitación para conocer las herramientas con las que debía de familiarizarme y conocer, después de un mes de capacitación fui asignado a la cuenta de Bancomer y desde entonces he estado poniendo en práctica lo aprendido pero capacitándome día a día. 4.2 Descripción de Technolab Corp Technolab es una empresa con más de 15 años de experiencia y es especializada en Business Intelligence (BI) y Enterprise Performance Management (EPM). Technolab es una empresa internacional y opera en 9 países: México, EE.UU, Argentina, Brasil, Canadá, Chile, Perú, Uruguay y España. Tiene más de cien clientes en la mayoría de los sectores: Servicios Financieros, Manufactura, Minería, Industrial, Sector Comercial y Público. Es dedicada a dar soluciones de negocio que mejoran el desempeño, rentabilidad, el pronóstico y los procesos de consolidación financiera; es proveedor de servicios cuya misión es ayudar a sus clientes de forma más eficaz utilizando la tecnología para resolver problemas del mundo real. Algunos de sus clientes son: Televisa, BBVA Bancomer, Banamex, Banorte, Banco de Chile, Grupo Bimbo, Comex, Sony, Movistar, entre otros. Se fundó en el año de Ofreciendo servicios de consultoría, soporte, capacitación e instalación tanto en sitio como a distancia. Parte del éxito se debe a la utilización de una metodología probada que incorpora las mejores prácticas en gestión de proyectos y el contenido de soluciones.

31 4.2.1 Visión El firme compromiso con la satisfacción del cliente se impregna en todo lo que se hace a partir de la comprensión del negocio para ofrecer las mejores soluciones en su clase, a tiempo y dentro del presupuesto. En todos los proyectos se hace un punto para involucrar a la gente de los clientes, tanto en el punto de las decisiones con respecto a la herramienta de selección, desarrollo, implementación, capacitación y soporte. Esto asegura que las recomendaciones Technolab e implementaciones proporcionan un valor duradero y sostenible Servicios Los servicios están diseñados para aprovechar las capacidades de inteligencia de negocio a través de la mejora de procesos de negocio y el análisis y diseño de sistemas. Los servicios de implementación pueden ofrecer cualquier cosa, desde la primera puesta en marcha de la aplicación y la gestión de sus soluciones de planificación presentación de informes y análisis. Las soluciones están enfocadas a la plataforma de EPM que comprende un conjunto de metodologías, métricas, procesos y sistemas utilizados para gerenciar y monitorear el desempeño de negocios. El principal socio de negocio es ORACLE-Hyperion y los productos que ofrece son: Hyperion Financial Management Hyperion Planning Hyperion Capital Expense Planning Hyperion Workforce Planning Hyperion Strategic Finance Hyperion Performance Scorecard Hyperion Financial Data Quality Management Hyperion Profitability and Cost Management Oracle Business Intelligence EE Información Comercial Technolab cuenta con un talentoso equipo de líderes de proyecto y consultores de implementación que son reconocidos por su capacidad de ofrecer una solución completa que satisfaga las necesidades de los clientes y obtener el máximo valor de su inversión Propuesta y Descripción de Funciones Mi historia en Technolab comienza en el año 2012 cuando después de un proceso de reclutamiento fui seleccionado, me incorpore en el mes de marzo, al inicio estuve en capacitación de la herramienta MicroStrategy, y posteriormente tome varios cursos sobre metodologías. Los proyectos de Technolab se desarrollan

32 desde las oficinas del cliente o bien desde las oficinas de Technolab trabajando remotamente. 5 Análisis y Discusión Antes de comenzar con el desarrollo de cualquier proyecto, es necesario conocer la metodología que la empresa u organización ha implementado, para este proyecto se utilizó la metodología del banco y se presenta a continuación: 5.1 Metodología PIB Bancomer Modelo de Atención PIB 1. Partición de alcance en fases para aislar requerimientos maduros y agilizar el inicio del desarrollo. 2. Partición de alcance en iteraciones cortas de duración fija (6 semanas). 3. Cada iteración entrega a su término un producto funcional (un incremento). 4. Interacción constante entre el cliente y el equipo que desarrolla las soluciones 5. Estrategias de soluciones focalizadas en las prioridades del negocio (acordadas con usuarios). 6. Trabajo colaborativo, sinergia en la conformación de equipos (mesas de diseño). 7. Construcción de prototipos funcionales y evolutivos para la validación temprana de necesidades. 8. La iteración en curso no acepta cambios mayores de alcance para no demorar entregas programadas (flexibilidad ante cambios mínimos). 9. Flexibilidad para responder a los cambios que puedan surgir a lo largo del proyecto. 10. Monitoreo constante de las iniciativas (KPI s, alertamientos, acciones preventivas y correctivas) además de la realización de auditorías en Soluciones BI. 11. Producción solo de los documentos que sean necesarios para tomar una decisión importante. 12. Mejora continua de procesos de soporte para: o Desarrollo de Soluciones BI o Service Desk o Infraestructura

33 Figura 11. Modelo de atención BBVA Bancomer Factores críticos de éxito PIB El logro de los beneficios que persigue la Metodología PIB en cuanto a tiempos, calidad y oportunidad de negocio, depende estrictamente del compromiso de todos sus participantes y del cumplimiento de los siguientes factores: Compartir la visión y el cumplimiento de los tiempos límites establecidos para cada actividad (todos los participantes). Disponibilidad e involucramiento del usuario en cada actividad prevista en la metodología. Comprensión detallada de la necesidad del negocio por parte del equipo que atiende la solución. Conocimiento tecnológico, capacidad de construcción ágil y orientación a servicios. Infraestructura y recursos disponibles Metodología PIB

34 Figura 12. Metodología BBVA Gestión de Iniciativa En la Gestión de Iniciativa se desarrollan los siguientes componentes, los componentes dentro de la metodología Bancomer son documentos. Componentes Generados: A825 Firmado C100 o P950 Firmado C100 (Preliminar) Minutas Plan de trabajo (preliminar) Metadatos El proceso se lleva a cabo de la manera que a continuación de muestra: Recoger Iniciativa 1. Revisión detallada del documento

35 a. A825 y b. C100 o P950 Análisis de la Necesidad Business Intelligence 2. Solicitud de reunión al cliente para iniciar la atención de la iniciativa 3. Reuniones de trabajo con el cliente para reestablecer el vínculo correcto entre la necesidad del cliente y las alternativas de solución, durante estas sesiones se elabora: a. C100 Preliminar b. C100 Ajustes. Derivados de la retroalimentación del cliente. c. Minutas de acuerdos. 4. C100 Preliminar es el producto resultante de las sesiones de trabajo con el cliente, dicho documento se entrega al Especialista de Solución. Revisar Necesidad Business Intelligence 1. Se pone en contacto con Especialista de Solución para dar respuesta a las dudad que se deriven del proceso de revisión del C Aclaradas las dudas se solicita Mesa de Diseño al Especialista de Solución. Mesa de Diseño Se reúne el Especialista Business Intelligence con el Especialista de Solución y dan respuesta a: o Decisión de la mejor alternativa de solución. o Se establecen las iteraciones del proyecto. o Se determinan las fechas estimadas del proyecto. o Fecha de entrega del C102 o Se toma la decisión de realizar un prototipo para la solución. o Fecha de presentación de Prototipo. Validar Soluciones BI por Par 1. Se realiza la revisión del C100 por parte de otro Especialista Business Intelligence Construcción del Prototipo 1. Se valida en conjunto con el Especialista de Solución el prototipo. 2. Se solicita al cliente la reunión para la presentación del prototipo. 3. Durante la presentación del prototipo el cliente puede solicitar ligeros ajustes a la aplicación, los cuales se reflejaran en el C100 final. Validar y Aprobar Solución BI con el Cliente 1. Se solicita al cliente la reunión para la revisión del C100 final 2. Se procede a la firma (Cliente, BP, DM y MIS) del documentos y se obtiene el C100 Final 3. El C100 final se entrega firmado y digitalizado al Especialista de Solución. Análisis Componentes Generados:

36 Backlog C102 Q201 El proceso se lleva a cabo de la manera que a continuación de muestra: Revisar Backlog de la Iteración 1. Confirmar y ajustar los requerimientos que serán cubiertos por la iteración con el cliente y el Especialista de Solución. Validar Propuesta de Solución BI por Par 1. Revisión del C102 por parte del Especialista Business Intelligence. Validar Propuesta de Solución con el Cliente. 1. Coordinar con el cliente, el Especialista de Solución y el Business Partner la reunión de aceptación (firma) de la propuesta de solución (C102). Identificar/Seleccionar Pruebas de Aceptación de Usuario 1. A partir de los casos de prueba (C204) generados por el Especialista de Solución seleccionar el conjunto de casos de prueba que se utilizarán durante las pruebas de usuario. Diseño Componentes generados Minuta de acuerdos. El proceso se lleva a cabo de la manera que a continuación de muestra: Valida y aprueba los avances en el diseño Seguimiento a la iniciativa En caso de ser requerido coordina con el cliente la reunión de revisión de avances de diseño y genera la correspondencia minuta. Construcción Componentes generados Minuta de acuerdos. Manual de usuario. El proceso se lleva a cabo de la manera que a continuación de muestra: Valida y aprueba los avances de construcción

37 En caso de ser requerido coordina con el cliente la reunión de revisión de avances de construcción y genera la correspondiente minuta. Seguimiento a la iniciativa. Manual de usuario. Coordinador con el Business Partner la elaboración del documento. Pruebas técnicas Componentes generados C204 Resultados SRM Soluciones (Ajustes) El proceso se lleva a cabo de la manera que a continuación de muestra: Realizar/Aprobar pruebas Técnicas Coordinar la ejecución de pruebas con el Business Partner, utilizando el C204 que fue preparado para realizar las pruebas de usuario. Seguimiento a la iniciativa. Garantizar la ejecución del QA. Pruebas de usuario Componentes generados C204 Ajustes a la solución BI blacklog Lecciones aprendidas Manual de usuario El proceso se lleva a cabo de la manera que a continuación de muestra: Realizar pruebas de aceptación cliente. Coordina con el cliente y el Business Partner la ejecución de las pruebas de aceptación de usuario. Se utiliza el C204 y se registran los resultados. Seguimiento a la iniciativa. Realiza retrospectiva y actualizar BI Blacklog

38 Registrar las lecciones aprendidas del proyecto/iteración y generar/actualizar el Blacklog con los requerimientos para las próximas iteraciones. Implantación Componentes generados Instalación y configuración de herramientas. A990 BI Blacklog final Encuesta de satisfacción El proceso se lleva a cabo de la manera que a continuación de muestra: Instalación y configuración de herramientas Notificación al equipo de Service Desk Ejecución de la encuesta de satisfacción Publicación en BI Store Rol y responsabilidades Analista funcional, arquitecto y desarrollador de soluciones BI. Análisis Traduce las necesidades de negocio de los usuarios a propuesta de desarrollo de aplicaciones de BI. Elabora los requerimientos necesarios para el desarrollo de aplicaciones. Da seguimiento al desarrollo, implantación y productivización de aplicaciones. Certifica la funcionalidad de las aplicaciones con el usuario final. Propone y promueve mejoras en prácticas, políticas, sistemas, estándares y procedimientos como resultado de procesos de mejora y difusión de conocimiento. Arquitectura Planea y evalúa la solución integral arquitéctonica de las soluciones consideración con base a la arquitectura y gobernabilidad establecida por la organización. Establece los programas de Capacity Planning. Revisor por Pares de requerimientos y diseño de soluciones BI. Desarrollo

39 Establece conjuntamente con Especialista C 3 el alcance y programa de trabajo para el desarrollo de la aplicación de BI. Diseña, desarrolla y realiza las pruebas de liberación de la aplicación. Actividades diarias Registrar el portal de Plataforma Informacional Bancomer: o Documentación del proyecto. o Registro de Desviaciones o Registro de avance del proyecto Enviar el Estatus semanal de avance a los clientes Revisar la metodología de trabajo y estar enterado de los cambios de versión. Mantener una línea de comunicación directa con todas las áreas involucradas. Alentar las situaciones de conflicto del proyecto de manera oportuna. 5.2 Descripción General En BBVA surgió la necesidad de saber y llevar un control de los tiempos en que las sucursales tenían indisponibilidad, por ejemplo cuando la sucursal se quedaba sin luz, sin papel para imprimir, sin equipo de cómputo, sin plantilla completa para atender; incluso se tomaron en cuenta los cajeros automáticos y practicajas a nivel nacional. Cuando me incorporé al proyecto el requerimiento ya se había levantado, como se ve a continuación. De acuerdo al análisis hecho se determinó lo siguiente: Se requiere generar un tablero de control en una herramienta de BI que muestre los niveles de servicio de las sucursales, en este contexto se requiere plasmar de manera ejecutiva y muy puntual los indicadores de indisponibilidad de los servicios (más adelante detallados). Generar un modelo de datos en un repositorio ismatizado que permita contar con la información en cuestión de manera oportuna, contar con respaldos y con acumulación de historia para futuros análisis que permitirán una toma de decisiones oportuna. Además era necesario distribuir en un formato PDF el tablero de indisponibilidad solicitado en este requerimiento a través de un proceso automático que permitiría a los directivos de cada sucursal tener disponible semanalmente dicho reporte en la aplicación de Escenarios Comerciales (Nuevo Front, etc.) dependiendo de la versión que maneja cada sucursal. En resumen lo que se tenía que hacer y desarrollar era lo que se detalla a continuación:

40 Creación de modelo de datos en repositorio ismatizado. Generación de un proceso ETL para alimentar modelo de datos semanalmente. Generación de Tablero de control en herramienta MicroStrategy. Distribución de informes (pdf) a cada una de las sucursales. La siguiente imagen muestra la propuesta de tablero que despliega los indicadores de indisponibilidad de servicios solicitados. Figura 13.Tablero Original Niveles de Servicio Beneficios esperados: Contar con un repositorio de información centralizado e ismatizado. Eliminar tareas manuales del área de Procesos y Calidad. Automatizar el proceso de generación y distribución del tablero de niveles de servicio a las sucursales activas de BBVA. Las alternativas analizadas y propuestas fueran las siguientes: 1.- Generar modelo de datos. Continuar realizando los reportes de manera centralizada en Excel. Crear la estructura de datos requerida en Oracle. 2.-Generación de tablero de control ejecutivo

41 Generar los reportes ejecutivos con la herramienta Qlik View para que se conecten a un cubo de información. Generar los reportes ejecutivos que pueden conectarse a múltiples fuentes de información y puedan explotar directamente la información. 3.-Distribución del tablero de Niveles de Servicio. Obtener los reportes de manera centralizada sin hacerla llega a los Directores de Sucursales. Con la herramienta MicroStrategy generar un tablero de manera semanal que pueda ser explotado a través de la herramienta Web que actualmente es la herramienta corporativa y a través de la cual se explota toda la información de inteligencia de negocios. Después de los análisis que se realizaron la solucionas más viable y propuesta fue: Generar un modelo de datos. o Contar con un repositorio que permita contar con la información de manera oportuna, que sea cargada a través de un proceso ETL. o Contar con respaldos de información de manera semanal y de manera ismatizada que contempla niveles de servicio adecuados para preservar la información. o Acumulación de historia para futuros análisis del negocio. Generación de tablero de Niveles de Servicio. o Crear un tablero que muestre los indicadores de indisponibilidad para el corporativo y para cada sucursal en una fase posterior. Ejecución del tablero de control ejecutivo. o El acceso a la herramienta será a través de la versión web que no requiere de ningún tipo de configuración o instalación adicional. Mi incorporación al proyecto se da arrancado ya el análisis de la necesidad, el perfil con el cual me incorporé al equipo fue de especialista BI por los conocimientos de MicroStrategy y de base de datos con los que contaba en ese momento. Parte de las primeras funciones que debía desempeñar era revisar que el análisis del modelo de datos propuesto era el adecuado, gracias a la versatilidad que tengo entre MicroStrategy y base de datos pude ofrecer mejoras al modelo para hacerlo más óptimo. En paralelo debía desarrollar la documentación requerida en base a la Metodología que se ocupó; mientras más clara fuera la documentación mejor sería la construcción. Durante la etapa de análisis comencé a diseñar una maqueta de un tablero ejecutivo, para ello se programaron varias sesiones con el usuario final con el objetivo de entender mejor como quería ver la información, cómo iba navegar, que gráfico le daba más valor a la información.

42 Mientras el diseño del tablero se iba madurando era necesario determinar cómo se extraería la información, se concluyó que el usuario dejaría la información en un archivo de texto plano separado por pipes alojado en un repositorio donde un proceso pl/sql buscaría el archivo y lo cargaría a las tablas del modelo. Con las tablas de nuestro modelo cargadas y el diseño del tablero definido comenzó la construcción de la arquitectura en MicroStrategy, a continuación se detalla paso a paso la evolución del proyecto. 5.3 Modelo de Datos La primer actividad que lleve a cabo fue revisar un prototipo de modelo de datos que cumpliera con las formas de explotación deseadas, sin que afectara el performance y donde la velocidad de respuesta de fuera en segundos, era necesario hacer que las consultas utilizaran los menos joins posibles; por eso se propuse que la mejor solución era hacer un modelo tipo estrella. Un modelo de datos tipo estrella se construye con una tabla central que contendrá todos los índices y campos numéricos con los que se harán los cálculos; y alrededor de está estarán los catálogos o dimensiones, además de una tabla de tiempo para poder movernos a través de los meses o incluso los años.

43 Figura 14. Estructura Física del Modelo Las tablas físicas quedaron conformadas de la siguiente manera, layout de las nuevas tablas: El primero catálogo es de los dispositivos a evaluar, en este caso sólo son tres los dispositivos y cada uno con su respectivo id: Catálogo: Dispositivos Campos: CD_TIPODISP NB_DESCRIPCION 1 Sucursales 2 Cajeros Automáticos 3 Practicajas Otro de los catálogos que se identificaron fue el de los Contribuyentes de indisponibilidad, se clasificaron en cuatro ramas:

44 Catalogo: Contribuyente Campos: CD_CONTRIBUYENTE NB_DESCRIPCION 1 Global 2 Gestión Oficina 3 Técnicos y EE 4 Centrales Algo muy importante en un tablero ejecutivo es representar de forma muy visual el estado de un dispositivo, y para eso se utilizan semáforos que representan con colores si algún dispositivo tiene alerta (rojo), llamada de atención (amarillo), bien (verde), excelente (azul): Catalogo: Semáforo Campos: CD_SEMAFORO NB_DESCRIPCION 1 Azul 2 Verde 3 Amarillo 4 Rojo Un catálogo más proviene de un concepto de negocio muy propio del banco, ellos clasifican las sucursales en cinco aspectos Ventana Crítica (VC), Ventana Crítica Prioritaria (VCP), Ventana No Crítica (VNC), Red Ulises que es un nuevo concepto en el banco y Gestión Comercial, por lo que el catálogo quedó así: Catalogo: Ventanas Campos: CD_VENTANA NB_DESCRIPCION

45 1 Gestión Comercial BC (N. Front ) 2 Red Ulises 3 VC 4 VCP 5 VNC Algo que no debe de faltar es la tabla del tiempo, porque gracias a ella vamos a poder navegar a través del tiempo y esto nos va permitir un análisis para saber que tanto ha progresado el banco o que tanto ha ido en retroceso: Catalogo: Tiempo Campos: AÑO MES DIA INICIAL DE LA SEMANA DIA FINAL DE LA SEMANA La primera tabla de hechos quedó compuesta de la siguiente manera: Hechos: Sucursales Campos: SUCURSAL FECHA DE INICIO

46 FECHA DE CORTE CÓDIGO DE DISPOSITIVO CÓDIGO DE VENTANA META INDICADOR SEMÁFORO MES SEMANA La segunda tabla se forma por los siguientes campos: Hechos: Dispositivos Campos: SUCURSAL FECHA DE INICIO FECHA DE CORTE CÓDIGO DE DISPOSITIVO CÓDIGO CONTRIBUYENTE META INDICADOR SEMÁFORO TIPO DE DISPOSITIVO ESTATUS SUCURSAL MES SEMANA

47 A continuación se muestran las tablas lógicas del modelo ya con los nombres de los campos y su longitud de cada uno: TABLA GORAPR.TLP148_NS_CAT_CONT Nombre de campo CD_CONTRIBUYENTE NB_DESCRIPCION Tipo de Dato VARCHAR2(100) TABLA GORAPR.TLP147_NS_CAT_DISP Nombre de campo Tipo de Dato CD_TIPODISP NB_DESCRIPCION VARCHAR2(100) TABLA GORAPR.TLP153_NS_CAT_CRS Nombre de campo CD_N07_OFICINA_ID CD_N01_BANCO_ID NB_N01_BANCO CD_N02_DG_ID NB_N02_DG CD_N03_DIVISION_ID NB_N03_DIVISION CD_N04_NA_ID NB_N04 NA CD_N05_DUG_ID NB_N05_DUG Tipo de Dato VARCHAR2(4), VARCHAR2(4), VARCHAR2(60), VARCHAR2(4), VARCHAR2(60), VARCHAR2(4), VARCHAR2(60), VARCHAR2(4), VARCHAR2(60), VARCHAR2(4), VARCHAR2(60),

48 CD_N06_NA_ID NB_N06_NA NB_N07_OFICINA CD_NIVEL_ESTRUCT CD_OFICINA_LAT CD_OFICINA_LON CD_MES_INICIAL CD_MES_FINAL ST_REGISTRO ST_USO ST_EJECUCION ST_BLOQUE ST_SUBSCRIP ST_DATASET VARCHAR2(4), VARCHAR2(60), VARCHAR2(60), NUMBER TABLA GORAPR.TLP149_NS_CAT_SEMA Nombre de campo Tipo de Dato CD_SEMAFORO NB_DESCRIPCION VARCHAR2(100) TABLA GORAPR.TLP150_NS_CAT_VEN Nombre de campo Tipo de Dato CD_VENTANA NB_DESCRIPCION VARCHAR2(100) TABLA GORAPR.TLP155_NS_CAT_TIEM

49 Nombre de campo Tipo de Dato CD_DIA CD_ANIO NU_ANIO_DU CD_ANIO_ANTERIOR CD_SEMESTRE NB_SEMESTRE VARCHAR2(20), NU_SEMESTRE_DU VARCHAR2(20), CD_SEMESTRE_PREV CD_SEMESTRE_APREV CD_TRIMESTRE NB_TRIMESTRE VARCHAR2(20), NU_TRIMESTRE_DU CD_TRIMESTRE_PREV CD_TRIMESTRE_APREV CD_MES NB_MES_LARGA VARCHAR2(20), NB_MES_CORTA VARCHAR2(20), NU_MES_DU NU_MES_DEL_ANIO CD_MES_PREV CD_MES_ANIO_PREV CD_SEMANA NB_SEMANA VARCHAR2(30), FH_SEMANA_DIA_INI DATE, FH_SEMANA_DIA_FIN DATE, NU_SEMANA_DU

50 CD_SEMANA_PREV CD_SEMANA_APREV FH_DIA FH_DIA_PREV FH_DIA_HABIL_PREV NU_DIA_ANIO NU_DIA_MES NU_DIA_SEMANA NB_DIA_SEMANA ST_DIA_HABIL DATE, DATE, DATE, VARCHAR2(20) NUMBER TABLA GORAPR.TLP151_NS_HEC_DIS Nombre de campo CD_SUCURSAL FH_INICIO FH_CORTE CD_DISPOSITIVO CD_CONTRIBUYENTE NU_META NU_INDICADOR CD_SEMAFORO CD_TIPODISP ST_SUCURSAL CD_MES CD_SEMANA VARCHAR2(4), DATE, DATE, NUMBER Tipo de Dato TABLA GORAPR.TLP152_NS_HEC_SUCU Nombre de campo Tipo de Dato

51 CD_SUCURSAL FH_INICIO FH_CORTE CD_DISPOSITIVO CD_VENTANA NU_META NU_INDICADOR CD_SEMAFORO CD_MES CD_SEMANA VARCHAR2(4), DATE, DATE, NUMBER Una vez que se tenía la primera versión del modelo comencé las pruebas para corroborar que efectivamente cumpliría lo que se necesitaba, para empezar hice una división de información en dos grandes rubros, Sucursales y Dispositivos. Sucursales: En las Sucursales el objetivo era saber la indisponibilidad de la Sucursal a nivel global, incluyendo todos los dispositivos con los que contara, practicaja y/o cajero; debía de mostrar los índices de incumplimiento a nivel Ventana, el semáforo que correspondería de acuerdo a su porcentaje de indisponibilidad contra la meta propuesta. Dispositivos: En un segundo nivel tenemos los dispositivos con los que contará las sucursales, debemos de saber que sucursal corresponde a cada dispositivo, el id o número de identificación que hace único a un dispositivo, el contribuyente que provoca la indisponibilidad, los índices de incumplimiento, la meta propuesta, el semáforo que corresponde a ese nivel de indisponibilidad y el tipo de dispositivo. Por este motivo decidí separar y hacer estos dos conceptos de negocio de una manera independiente, como consecuencia se crearon dos tablas de hechos; otra cosa importante es la forma en la que se deseaba navegar, se tuvo que definir una Jerarquía conocida en el Banco como Árbol de Centros, que contiene la agrupación de las Sucursales, es decir, una Sucursal pertenece a una Zona y a su vez esa Zona pertenece a una División. A continuación se muestra la forma en que se agrupó: Sucursal->Zona->División. En las pruebas lo primordial era validar que la información coincidiera con el archivo de aprovisionamiento, por ello hice primero las pruebas de Oracle contra Origen; mediante una consulta (query) debemos reflejar lo que el archivo de aprovisionamiento contiene para confirmar que durante la carga no se haya presentado ningún error.

52 vs Oracle Figura 15. Comparación entre archivo de texto y una base de datos Si el resultado de esta primera comparación era incorrecto, había que reprocesar y volver a cargar el archivo de aprovisionamiento, sino se podía continuar con el desarrollo. 5.4 Objetos de MicroStrategy Una vez que se validé todos los catálogos y se comprobé que la información contenida en la BD era la misma al archivo de aprovisionamiento la siguiente actividad fue construir la arquitectura en MicroStrategy. MicroStrategy divide sus objetos en dos tipos, Aplicación y Esquema: Figura 16. Objetos MicroStrategy Objetos de Esquema Un atributo son los conceptos de negocio, como productos, empleados, clientes, tiendas, que representan los muchos e importantes atributos de un negocio. Son

53 conceptos de negocio que responden a preguntas sobre cómo, cuándo, dónde, etc. Se representa por el siguiente icono: Figura 17. Representación de Atributo en MicroStrategy Un hecho son mediciones empresariales que toman forma de datos almacenados en el origen le datos; los hechos suelen ser numéricos y son apropiados para la agregación. Se utilizan para crear indicadores y otros objetos en MicroStrategy. Entonces un hecho es un objeto por medio del cual se define la forma en que se desea medir un valor siendo asociado con un atributo. Se representa por el siguiente icono: Figura 18. Representación de Hecho en MicroStrategy Una Jerarquía consta de un grupo de atributos de negocio relacionados que están conceptualmente asociados entre sí. Para navegar exitosamente a través de los datos de un informe debe comprender cómo se pueden relacionar los atributos del negocio en un proyecto de informes entre ellos dentro de conceptos del negocio de alto nivel llamados jerarquías. Se representa por el siguiente icono: Figura 19. Representación de Jerar quía en MicroStrategy

54 Ejemplo: Figura 20. Ejemplo de Jerarquía en MicroStrategy Una transformación aplica valores de demora, como por ejemplo hace cuatro meses, a un indicador de un informe. Se utiliza en los indicadores para comparar los valores de momentos distintos. Se representa por el siguiente icono: Figura 21. Representación de Transformación en MicroStrategy Partición es una tabla de una base de datos dividida en tablas de componentes más pequeñas. Puede realizarse en el nivel de base de datos o de aplicación. Se representa por el siguiente icono: Figura 22. Representación de una Partición en MicroStrategy Objetos de Aplicación Un Template especifica la forma en que serán mostrados los datos recuperados del Data Warehouse. Se representa por el siguiente icono:

55 Figura 23. Representación de un Template en MicroStrategy Un filtro de visualización restringe dinámicamente los datos que recoge el informe sin que sea necesario volver a ejecutar el informe en el warehouse; con esta función, los tiempos de respuesta mejoran y disminuye la carga de trabajo de a base de datos. Son útiles para clarificar grandes cantidades de datos y mostrar sólo subcojuntos de datos. Se representa por el siguiente icono: Figura 24. Representación de Filtro en MicroStrategy Un indicador es un cálculo que refleja las cifras que el usuario desea ver. Los cálculos de indicadores pueden proporcionar información a niveles tanto sencillos como complejos, y así, muestran tendencias de ventas, patrones de crecimiento, contribuciones de porcentajes del total y análisis de beneficios. Es decir, son cálculos realizados con los datos almacenados en la base de datos y cuyos resultados se muestran en un informe. Se representa por el siguiente icono: Figura 25. Representación de Indicador en MicroStrategy Un Grupo personalizado es una forma especial de mostrar los datos del informe, agrupándolos mediante nombres que tengan sentido para los analistas de la información, es decir, es un conjunto de filtros que obtienen del origen de datos un conjunto definido específicamente de elementos de atributo que se mostrarán en el informe. Se representa por el siguiente icono: Figura 26. Representación de un Grupo Personalizado en MicroStrategy Una Consolidación es un grupo seleccionado de elementos de atributo que se utiliza como un atributo en un informe. Es un conjunto de elementos de atributo agrupados de una manera en la que no estaban agrupados originalmente dentro del proyecto. Se representa por el siguiente icono: Figura 27. Representación de una Consolidación en MicroStrategy Una Selección dinámica es una pregunta que se hace al usuario que ejecuta el

56 informe; según las respuestas que proporcione el usuario, el informe se actualiza y muestra otros datos del origen de datos. Son útiles para clarificar grandes cantidades de datos y mostrar solo subconjuntos de datos, de modo que los informes muestren a los usuarios los que realmente necesitan ver. Se representa por el siguiente icono: Figura 28. Representación de una Selección dinámica en MicroStrategy Ya que se explicó cada uno de los objetos de MicroStrategy a continuación iré explicando cómo se hizo el proyecto de Indicadores de Niveles de Servicio paso a paso. El paso uno consiste en llenar las tablas de nuestro modelo tipo estrella, la carga de estas tablas se llevó a cabo por medio de un archivo de texto plano separado por pipe. Estos archivos los dejó el usuario en una ruta y de ahí se tomaron para la ejecución. A continuación se muestra un ejemplo del archivo de texto plano. Figura 29. Script con la definición de los catálogos. El script de la figura anterior será ejecutado en una herramienta de base de datos, para este ejercicio se ocupó Oracle SQL Developer; ejecuté una consulta para confirmar que efectivamente los datos hayan sido cargados correctamente, a continuación se muestra un ejemplo de esto.

57 Figura 30. Ejecución de consulta para confirmar Después de tener llenos los catálogos y las tablas de hechos, lo siguiente fue crear el proyecto en MicroStrategy, entramos a nuestra aplicación de MicroStrategy

58 Figura 31. Icono de MicroStrategy Le daremos clic y la pantalla principal de MicroStrategy es la siguiente que vemos en la siguiente figura: Figura 32. Pantalla principal de MicroStrategy

59 Dentro de MicroStrategy lo primero que debemos de hacer es la conexión con el origen del Proyecto, es decir, conectar a la base de datos mediante un ODBC, a continuación daremos clic en Herramientas- Administrador de Origen de Proyecto. Figura 33. Paso número 1 Después de dar clic en Administrador de Origen de Proyecto nos aparecerá la siguiente pantalla: Figura 34. Administrador de Origen de Proyecto Ahora seleccionaremos la opción de Agregar porque es un nuevo desarrollo y la pantalla que a continuación nos mostrará es la siguiente:

60 Figura 35. Conexión al Servidor Después de haber agregado y configurado el nuevo Origen de Proyecto le daremos clic en Aceptar, esta pantalla se cerrará y en el menú principal de MicroStrategy ya podremos ver el nuevo Origen como se muestra a continuación: Figura 36. Origen de Proyecto creado Ahora sí crearemos nuestro proyecto dentro del Origen que acabamos de crear, para ello daremos clic derecho en nuestro nuevo origen y seleccionaremos Crear Proyecto Nuevo

61 Figura 37. Creación de Proyecto Nuevo En la parte de la creación del proyecto MicroStrategy cuenta con un Asistente que nos lleva paso a paso de una manera sencilla y ordenada, la pantalla es como la que se muestra a continuación: Figura 38. Asistente para Creación de Proyectos Le daremos clic en Crear Proyecto y MicroStrategy generará todos los archivos necesarios del sistema para poder empezar a trabajar, al seleccionar Crear Proyecto MicroStrategy nos pedirá un nombre para nuestro Proyecto como podemos ver a continuación:

62 Figura 39. Nuevo Proyecto Todos los demás campos los dejaremos por defecto y daremos clic en Aceptar y comenzará a crear los archivos necesarios: Figura 40. Creación del Proyecto

63 El tiempo de espera para generar los archivos necesarios no es mayor a cinco minutos, una vez que termine de crear estos archivos nos mostrará la siguiente pantalla: Figura 41. Tablas de Warehouse Cuando ha terminado una actividad pondrá una palomita verde indicando que se realizó correctamente, y ahora daremos clic en Seleccionar Tablas en el Catálogo de Warehouse:

64 Figura 42. Instancia de Base de Datos En esta parte seleccionaremos la Instancia de la Base de Datos a la que nos vamos a conectar, en caso de que no hallamos configurado ninguna la podemos crear en este paso, seleccionamos la instancia y le damos clic en Aceptar en este caso nuestra instancia es de tipo MySQL y se llama enobi. Figura 43. Selección de la Instancia de Base de Datos En este caso nos vuelve a preguntar si es correcta la Instancia de Base de Datos que hemos elegido previamente, en caso de que sea correcto daremos clic en Aceptar y ahora nos mostrará las tablas que contiene esa Base de Datos y agregaremos sólo las tablas que ocuparemos, si son todas o sólo algunas como se muestra a continuación:

65 Figura 44. Selección de tablas a utilizar en el Proyecto En este caso hemos seleccionado todas las tablas que contiene nuestra Base de Datos, después de que las elegimos daremos clic en Guardar y Cerrar, con este paso veremos completado el paso de Seleccionar las tablas del Warehouse:

66 Figura 45. Tablas del Warehouse Completadas Este Asistente no lo vamos a utilizar en la Creación de Hechos y Atributos para ver de forma detallada cómo se crean estos objetos, así que ahora daremos clic en Aceptar y ya podemos ver creado nuestro proyecto como se ve a continuación: Figura 46. Estructura del Proyecto En la imagen anterior se puede ver el Proyecto creado con la estructura que genera MicroStrategy automáticamente, a continuación vamos a crear los objetos de esquema como son Hechos y Atributos; vamos a expandir la carpeta de Objetos de Esquema y nos posicionaremos en la carpeta de Hechos como se muestra a continuación:

67 Figura 47. Carpeta de Hechos Damos clic derecho en la carpeta y seleccionaremos Crear nuevo hecho y nos aparecerá la siguiente pantalla: Figura 48. Creación de Hecho En este asistente debemos de seleccionar una tabla de Origen de la cual tomaremos el campo que queremos que sea nuestro Hecho, un Hecho siempre debe ser numérico y debe estar en nuestra tabla de Hechos, no lo podemos tomar de un catálogo, seleccionamos un campo de los que contenga nuestra tabla y le

68 damos doble clic, al darle doble clic se pasará automáticamente de lado derecho: Figura 49. Selección de campo para Hecho En la parte de Método de Asignación vamos a selección Manual y damos clic en Aceptar y ahora nos mostrará la siguiente pantalla: Figura 50. Métodos de Asignación En esta parte seleccionaremos las tablas de Origen, si un campo tiene como origen dos tablas, esto quiere decir que en la tabla de hechos existe el campo pero sólo contiene el ID, si seleccionamos la otra tabla que deberá ser un Catálogo se crea de forma automática una unión o join entre esas dos tablas; ya que hemos seleccionado nuestras tablas de Origen daremos clic en Guardar y Cerrar y la pantalla que nos mostrará es la siguiente:

69 Figura 51. Guardando un Hecho Por defecto nos posiciona en la Carpeta de Hechos, aquí sólo debemos poner un nombre representativo y damos clic en Guardar. MicroStrategy crea el Hecho y ya lo podemos visualizar en nuestra carpeta de Hechos como se ve a continuación: Figura 52. Carpeta de Hechos

70 De este mismo modo crearemos cuantos hechos necesitemos, recordemos que las métricas se construyen en base a los Hechos por lo que debemos de crear los Hechos necesarios; ahora vamos a crear otro tipo de objeto de esquema, los atributos, y para ellos nos vamos a posicionar en la carpeta de Atributos como se muestra a continuación: Figura 53. Carpeta de Atributos Al igual que en los Hechos, una vez que estamos en la carpeta de Atributos daremos clic derecho y seleccionaremos Nuevo Atributo y nos mostrará el asistente para la creación de los atributos: Figura 54. Creación de un Atributo

71 El método es muy similar en este paso al de los Hechos, debemos ahora de seleccionar los campos de nuestras tablas que son Catálogos empezando por los campos de ID, basta con dar doble clic en el campo que seleccionamos y se pasará de lado derecho como se muestra a continuación: Figura 55. Elección de campo ID Seleccionamos el Método de Asignación de forma manual y damos clic en Aceptar y ahora nos muestra la siguiente ventana:

72 Figura 56. Representación del Atributo En la figura anterior podemos observar el campo que elegimos previamente y las tablas que tiene como Origen, una tabla Catálogo y la tabla de Hechos, siempre debemos de seleccionar como Lookup nuestra tabla Catálogo, la tabla que se muestra en negritas es la que se define como Lookup, ya que hemos validado eso damos clic en Aceptar y nos mostrará la siguiente pantalla: Figura 57. Representación de ID en un Atributo

73 Ya tenemos la descripción del ID de nuestro campo, pero hace falta agregar la descripción larga, para hacer esta nueva descripción vamos a dar clic en Nuevo y nos va mostrar lo siguiente: Figura 58. Elección de campo de Descripción Nos muestra el mismo asistente que antes, pero ahora en lugar de ID por defecto nos muestra DESC, refiriéndose a una descripción, ahora seleccionaremos el mismo campo que antes pero con la descripción, damos doble clic en el campo y lo veremos en la parte derecha como se muestra en la figura anterior, damos clic en Aceptar y nos mostrará la siguiente pantalla:

74 Figura 59. Representación de Descripción En esta parte debemos de seleccionar solamente la tabla Catálogo porque ahí está alojada la descripción, vemos que por defecto nos ha llenado algunos de los campos con DESC, y eso es correcto por eso no lo modificaremos y ahora daremos clic en Aceptar y nos muestra la siguiente pantalla: Figura 60. Definición del atributo

75 En la figura anterior vemos la definición de nuestro Atributo, vemos que contiene un id (ID) y una descripción (DESC), ahora procedemos a dar clic en Guardar y Cerrar como se muestra a continuación: Figura 61. Guardando un Atributo Debemos de asignarle un nombre representativo del negocio a nuestro atributo, y después de eso darle clic en Guardar por defecto MicroStrategy lo guardare en la carpeta de Atributos, después de que lo guardamos ya es posible visualizar el atributo en la carpeta. Hemos construido ya los objetos de esquema básicos para la construcción de nuestros Reportes y posteriormente de nuestro Tablero, pero aún falta crear los Objetos Públicos, así que vamos a construir una métrica, ahora nos posicionamos en la carpeta de Objetos Públicos y después en la carpeta de Indicadores como se ve a continuación:

76 Figura 62. Carpeta de Objetos Públicos En la carpeta de Indicadores daremos clic derecho y seleccionaremos Nuevo Indicador y nos mostrará la siguiente pantalla: Figura 63. Creación de Indicador El asistente de la creación de Indicadores es como el que se muestra en la figura anterior y daremos clic en Aceptar y nos mandará a la siguiente pantalla:

77 Figura 64. Elección de Hecho Cómo lo dijimos anteriormente, para que podamos construir un indicador debemos tomar como base un hecho, en el paso que vemos en la figura anterior es donde se debe seleccionar el hecho que será fuente de este indicador, en la parte derecha definimos la fórmula que nosotros queramos, en este caso dejamos la formula por defecto y daremos clic en Guardar y Cerrar y nos mostrará la pantalla siguiente:

78 Figura 65. Guardando un Indicador Ahora construiremos una Jerarquía, las jerarquías son importantes también para permitir y facilitar la navegación en un reporte o en un tablero, para ello nos iremos a la carpeta de Jerarquías y daremos clic derecho y seleccionamos Nueva Jerarquía y nos mostrará la siguiente imagen: Figura 66. Creación de Jerarquía En la figura anterior lo que debemos de hacer es seleccionar los atributos que en conjunto formarán parte de nuestra jerarquía, una vez que los hemos seleccionado

79 se verán de la siguiente manera: Figura 67. Elección de Atributos Ya que hemos elegido los atributos para nuestra Jerarquía las pasaremos de lado derecho y daremos clic en Aceptar y nos mostrará la siguiente pantalla: Figura 68. Definición de Jerarquía En esta parte es donde vamos a definir como irá nuestra Jerarquía, nosotros la podemos acomodar de acuerdo a la necesidad del negocio, será también la forma en la que el usuario podrá navegar, ya que tenemos definida nuestra Jerarquía

80 daremos clic en Guardar y Cerrar y nos mostrará la siguiente pantalla: Figura 69. Guardando una Jerarquía Le debemos de poner un nombre representativo a nuestra Jerarquía para identificarla fácilmente. Después de haber construido estos objetos, ahora si comenzaremos a crear lo Reportes, los Reportes son la base de nuestros Tableros Ejecutivos, son la fuente de información, para crear un Reporte nos vamos a la carpeta de Informes y daremos clic derecho en Nuevo Informe y nos mostrará la siguiente pantalla: Figura 70. Creación de nuevo Informe En el Asistente que nos aparece seleccionaremos Informe en blanco y damos clic en Aceptar y nos llevará a la siguiente pantalla:

81 Figura 71. Pantalla principal del nuevo Informe En estos Informes es donde vamos a utilizar los objetos creados anteriormente, podemos agregar atributos, indicadores, jerarquías y otros objetos, en la figura anterior podemos ver de lado izquierdo los accesos directos a los objetos, basta con abrir esas carpetas y arrastrar al lado derecho el atributo que queramos, así como los indicadores que queramos, cuando los arrastramos hacia al lado derecho se visualizarán como se muestran a continuación: Figura 72. Informe con un atributo y un indicador Una vez que agregamos todos los objetos necesarios en nuestro Informe, vamos a ejecutar este, cuando lo ejecutamos veremos los datos que contengan los atributos que agregamos así como los valores que tengan los indicadores, tal y como se muestra en la siguiente imagen:

82 Figura 73. Ejecución de Informe Hemos puesto sólo datos de muestra debido a la confidencialidad de los datos del Banco, pero como podemos ver en la figura anterior los atributos en este caso llamado Dispositivos contienen una descripción y los indicadores en este caso llamado Indisponibilidad contienen valores numéricos, para guardar nuestro Informes basta con darle clic en Guardar y Cerrar y nos mandará a la siguiente pantalla:

83 Figura 74. Guardando un Informe Le pondremos un nombre representativo del negocio y damos clic en Guardar, crearemos el número de Reportes necesarios para poder crear nuestro tablero, para eso nos vamos a ir a la carpeta de Documentos y damos clic derecho, vamos a seleccionar Nuevo Documento y nos mostrará la siguiente pantalla: Figura 75. Elección de tipo de Tablero En esta pantalla vamos a elegir el primer Tablero, el 01 Tablero en Blanco y damos clic en Aceptar y nos va mostrar la siguiente pantalla:

84 Figura 76. Pantalla principal de un Tablero En esta parte es donde vamos agregar los Informes que creamos previamente, cuando lo creamos nos pide que elijamos un Informe con el que vamos a estar trabajando, durante la construcción del tablero podemos agregar más Informes si así lo requerimos, la construcción de los Tablero es mucho trabajo de diseño, en la siguiente pantalla se puede ver de mejor manera: Figura 77. Diseño de un Tablero En la figura anterior podemos observar el Informe que nosotros elegimos previamente y cómo se debe de ir creando la estructura para poder diseñar el tablero, se han agregado los Paneles en los cuáles insertaremos los gráficos correspondientes, se debe de cuidar mucho la parte de estándares de publicación

85 cómo se ve en la siguiente imagen: Figura 78. Estándares de Publicación Como se puede ver en la imagen anterior, sólo se pueden utilizar ciertos colores y tipo de letra en las publicaciones, así que hemos adoptado esos estándares, en cada uno de los paneles que agregamos tenemos que agregar nuestros gráficos, como lo podemos ver en la siguiente imagen: Figura 79. Vista modo diseño del Tablero En la imagen anterior se muestra el diseño completado pero visto desde el modo de vista diseño, cuando lo vemos en web la vista mejora considerablemente como se puede apreciar en la siguiente imagen:

86 Figura 80. Vista de Tablero modo Web En la imagen anterior se puede apreciar el tablero en vista de Web, así fue como se entregó finalmente, y como plus se realizó el mismo tablero pero a nivel de tablas y el resultado fue el siguiente: Figura 81. Tablero con la modalidad de Tablas En la imagen anterior se puede apreciar el tablero en vista de Web pero en modo de tablas, los colores en cada valor son semáforos que el usuario ha establecido. De este modo finalizo el desarrollo de nuestro proyecto en MicroStrategy.