universidad de concepción - edutic 2011

Inteligencia de Negocios en el ambiente Universitario

Metodología y Casos Prácticos

EDUTIC – 2011César González Castillo – Rolando Burgos Cárdenas

Universidad de Concepción

• Compartir la experiencia de la implantación de BI

en la Universidad de Concepción (UdeC).

• Revisar la metodología para el desarrollo de

proyectos BI.

• Analizar las conclusiones y lecciones aprendidas de

este proceso al interior de la DTI.

Objetivos

“Aquellas personas que no leen libros no tienen ninguna ventaja sobre aquellos que no saben leer.”

Mark Twain – around 1900

“Aquellas personas que toman decisiones y no pueden ver su data no tienen ninguna ventaja sobre aquellos que no tienen data en lo absoluto.”

Bob Lokken (WhiteCloud Analytics) – around 2000

Frases para reflexionar

1. Contexto

2. Inteligencia de negocios en UdeC

3. Aspectos técnicos BI-UdeC

4. Ejemplos

5. Conclusiones

Agenda

Agenda

•Hay rubros con miles de datos y que deben relacionarse (banca, retail, seguros, otros).

•Conocer realidad, predecir tendencias, entre otras son parte del día a día.

•Toma de decisiones con mejor información implica retornos muy altos y rápidos.

•En estos escenarios inversiones en BI se justifican y son claves para competir y/o sobrevivencia.

Generalidades

• En las Universidades SI se requiere implementar BI

• Los datos/indicadores son importantes

• En las Ues Si se realiza BI pero muy artesanal y con dificultades haciendo uso de mucho excel

• Concepto de proceso es fundamental

• Para los proveedores no somos un buen nicho

• Profesionalizar y oficializar

BI en Universidades

• Informes– Consolidar grandes volúmenes de datos– Datos con visión transversal– Solicitudes puntuales con urgencia– Acceso a tablas corporativas vía MSQ– Degradación del rendimiento de otros sistemas

• Hojas de cálculo en un PC: varios riesgos– Pérdida de archivos y adm. de versiones de archivos– Tamaño de las planillas con fórmulas locales – Conocimiento dependiente

Realidad

• Extraer datos desde los Sistemas operacionales (OLTP) y otras fuentes.

Filtrarlos, limpiarlos, estandarizarlos y redundarlos tanto como sea

necesario, en un proceso ordenado y automatizado.

• Agregarlos a un nuevo Almacén de datos (DataWarehouse).

• Acceder a estos datos a través de herramientas capaces de acercar la

información al usuario que la necesite (Business Objects).

DWHDWHSistemas OperacionalesSistemas Operacionales Tomadores de DecisionesTomadores de Decisiones

BI como solución

Agenda

• Año 2007

• Cuatro elementos conductores

– Revistas, seminarios, internet

– Plan estratégico (indicadores)

– Requerimientos de informes

– Iniciativa personal y de los integrantes de la DTI

Primeros pasos

Operacional• Se dispone de una capa de sistemas

operacionales que en gran medida

satisfacen las necesidades de

automatización.

• Los sistemas transaccionales están

orientados al nivel, al trabajo del día a

día.

• Estos sistemas se han ido

construyendo a través del tiempo,

focalizándose en nichos particulares.

Táctico• Los requerimientos están asociados a

necesidades de información del

“negocio particular”, generada

dinámicamente.

• Existen reportes operacionales que

satisfacen algunos de estos

requerimientos

• Muchas veces esta información se

necesita vincular con alguna otra

“fuera del dominio” del negocio.

• Los reportes de mayor complejidad

son solicitados a DTI.

• Requerimientos de indicadores de

precisión que permitan apoyar la toma

de decisiones.

• Valores más específicos respecto a una

temática en particular.

• Actualmente, son solicitados al nivel

táctico, que es el encargado de

generarlos, calcularlos, “maquillarlos”

y entregarlos.

Estratégico

Necesidades de Información

• Designación de 1 persona

• Experimentar, conocer: sw libre

• Proyecto piloto, logo, nombre (atalaya)

• Obtención de cotizaciones

• Compra de algunas licencias

BI en UdeC

• Unidad Informática: Dirección de Tecnologías de Información (DTI)• Misión , Visión, Valores, Plan estratégico• Entregamos:

– Desarrollo y mantención Sistemas corporativos– Servicios e infraestructura– Soluciones de Inteligencia de negocios– Plataforma de conectividad de redes y telefonía– Desarrollo de portales institucionales

Ubicación de BI en DTI

• Jefe de Unidad Desarrollo Sistemas Corporativos– Rolando Burgos

• Jefe de Proyecto Inteligencia de Negocios– Alvaro Muñoz. Master in Business Analysis (c) at GSU

• Jefe de Unidad Arquitectura Tecnológica– Italo Foppiano

• Ingenieros BI– Oscar Hermosilla– Nicolás Galán

Equipo Actual BI

• 2007 Benchmarking de Herramientas para BI

• 2007 Compra de Business Objects XI R2

• 2008 Proyectos menores en RRHH y Finanzas

• 2009 Migración a Plataforma Linux BO XI R3

• 2010 Creación de Datamarts y equipo BI

Grandes Hitos

Agenda

¿De qué se trata esto de BI?

http://www.gartner.com/it/page.jsp?id=1526414

Alineamiento Estratégico

http://blogs.gartner.com/mark_mcdonald/2010/02/11

¿Problema único?

http://www.gartner.com/technology/home.jsp

Gartner en Herramientas BI

En un esquema multidimensional se representa una actividad que es objeto de análisis (hecho) y las dimensiones que caracterizan la actividad (dimensiones).

La información relevante sobre el hecho se representa por un conjunto de indicadores (medidas o atributos de hecho).

La información descriptiva de cada dimensión se representa por un conjunto de atributos (atributos de dimensión).

Modelamiento Multidimensional

• Transaction

– Representan eventos que suceden en un determinado momento.

– Permiten analizar los datos con el máximo detalle.

– Ejemplo: Venta, Compra, Situación Académica

• Periodic Snapshot (Snapshot)

– Almacenan información de forma periódica a intervalos de tiempo regulares. Dependiendo de la

situación medida o de la necesidad de negocio este tipo de tablas de hecho son una agregación de

las anteriores o están diseñadas específicamente.

– Ejemplo: Estado de Cuenta Diario, Indicadores Mensuales

• Accumulating Snapshot

– Representan el ciclo de vida completo de una actividad o proceso que tiene un principio y final.

– Ejemplo: Ciclo de Vida de Alumno

Hechos

Sistemas Corporativos

Sistemas Corporativos

Otras BasesOtras Bases

Archivos ExternosArchivos Externos

ETL

Staging Area

Op Dw

Sistemas Corporativos

Sistemas Corporativos

DatawareHouse

DataMart

Conformed

Copia Operacional

Otras Plataformas

Otras Plataformas

Universos

Espacios

WebIntelligence

Widgets

Xcelcius

Explorer

Arquitectura BI UdeC

• Servidor Datawarehouse– DELL POWER EDGE 295, 2 CPU Xeon 2,33 GHz

Quad Core, 4GB RAM– Sistema Operativo: Red Hat Enterprise Linux 5.3– SGBD: PostgreSQL 8.3.10– 1,5 TB Base de Datos– 500 GB Documentos PDF

Configuración Actual

• Servidor Business Objects– DELL POWER EDGE 295, 1 CPU Xeon 2,33 GHz Quad Core, 8GB RAM– Sistema Operativo: Red Hat Enterprise Linux 5.3– SGBD: MySQL (Repositorios y CMC) 5.0.45– BusinessObjects Entreprise XI Release 3.1 Edge Series SP4

• Designer Version 12.4.0.966• Webi Version 12.1.0• Polestar (Explorer) version 12.1.1• Mobile XI Release 3.1 SP2• Crystal Reports 2008 Version 12.3.0.601• Live Office 12.1.0• QaaWs 12.4.2000• Widget 12.3.601 • webi richClient 12.4.0• Xcelsius 2008 12.4.0

– Data Integrator (ETL): DataIntegrator XI 11.7.2 para linux

Configuración Actual

OLTP

Capa 1Modelos Nativos

Capa 2Modelos Resumen

Capa 3 Tablas

Resumen

Granularidad

Mayor Detalle

Mayor Abstracción

SISPER

FINANZAS

DELFOS

SIMA

TIGRADO

SIGRA

SAC

SIGRA

SAM

Estructura Datamart

Productos Típicos BI

1.- Alcance, Modelos Iniciales

2.- Orígenes y Calidad de Datos

3.- Diseño detallado de Modelos

4.- Diseño de ETL Histórico y de rutina

5.- Construcción de Almacenes

6.- Carga Histórica

7.- Construcción ETL rutina

8.- Construcción Universos

9.- Construcción de Reportes

Metodología Proyectos BI

Alcance, Modelos InicialesEtapa 1

Alcance, Modelos Iniciales

•Objetivos•Requerimientos•Restricciones

•Estimación•Modelos Iniciales

• Tiene por objetivo estimar costos y plazos del proyecto, definiendo sus objetivos.

• Mecanismo de Estimación– Reunión Cliente

• Requisitos iniciales• Identificación de Procesos de Negocio

– Reunión Administradores• Identificación de Orígenes• Factibilidad de obtención de datos

– Diseño Preliminar• Hechos• Dimensiones

• Entregables– Estimación– Modelo Inicial

Alcance, Modelos Iniciales

• La carga de dimensiones representa menos complejidad

• Las tablas transaction son de menor complejidad y generalmente de capa 1

• Las tablas Periodic Snapshot son más complejas y generalmente de capa 2

• Las tablas Accumulating Snapshot son las más complejas y generalmente son de capa 2, aunque

con algunos aportes directos de los OLTP.

• Los procesos ETL van disminuyendo en complejidad según el nivel de las capas que interconectan.

• Los procesos ETL van aumentando su complejidad según el tipo de Hecho a obtener.

Objeto Dimensión Capa 1 Capa 2 Capa 3

Dimensión

Transaction

Periodic Snapshot

Accumulating Snapshot

Estimaciones

Orígenes y calidad de datosEtapa 2

Orígenes y Calidad de Datos

•Requerimientos•Restricciones•Modelos Iniciales

•Detalle Orígenes•Herramientas en Stage•Doc. Calidad de Datos

• Determinar de donde se pueden obtener los datos necesarios• Se identifica factibilidad de obtención de datos• Se determina cual es el mayor nivel de detalle que se puede

obtener• Se determina que tan confiables son los datos• Entregables:

– Documento con orígenes para diseño ETL– Estudio de Calidad de Datos

• Importante: En este punto se puede detener el proyecto

Orígenes y Calidad de Datos

• Universo de Personas– No están 2.790 (5,41%)– Incluidas 48.773 (sac, sisper, sigra)– Otras “no relevantes” 40.196 (45,18%)

• Ítems > 396.969• Préstamos > 3.449.034• Usuarios > 57.787• Reservas > 40.734• Órdenes > 12.779• Proveedores > 427• Facultades > 27• TUdeC > 27.438• Uso entrada > 201.230

Orígenes y Calidad de Datos

Diseño detallado de modelosEtapa 3

Diseño Detallado de Modelos

•Requerimientos•Restricciones•Modelos Iniciales

•Documento de Diseño de Modelos

RESERVA• Item

– Tipo Material– Demanda– Biblioteca – Colección

• Usuario– Datos básicos– Carrera / Programa– Facultad Sede– Biblioteca base

• Tiempo– Año Mes Día

• Reserva (ocurrencia)

PRESTAMOS• Item

– Tipo Material– Demanda– Biblioteca – Colección

• Usuario– Datos básicos– Carrera / Programa– Facultad Sede– Biblioteca base

• Funcionario• Tiempo• Días relacionados

ADQUISICIONES• Facultades• Tiempos

– Creación– Solicitud– Cierre

• Proveedores• Productos• Tipo Adquisición• Presupuesto• Tipo Producto

USO TUDEC• Alumnos

– Pregrado– Postgrado– Funcionarios

• Puertas• Operaciones• Tiempo• Hora entrada/salida• Duración• Capacidad

Modelos

Diseño ETL histórico y de rutinaEtapa 4

Diseño ETL Histórico y de Rutina

•Documentación OLTP•Requerimientos•Modelos Iniciales

•Diseños de ETL•Calendario de Ejecución

• Histórico: Se determina desde donde se puede “reconstruir” la historia.– Factibilidad– Calidad

• Rutina: Se determina de donde se tomarán los datos de carga permanente.– Determinar origen– Determinar restricciones y/o tomar decisiones– Determinar apoyos de stage (vistas, vistas materializadas, etc.)– Determinar calendario de carga (diaria, semanal, mensual, etc.)

Diseño de ETL

Construcción de almacenesEtapa 5

Construcción de Almacenes

•Documentación de Diseño

•Esquema físico

• Se procede a la implementación de las tablas físicas

• Se define esquema de indexación de tablas para mejorar tiempos de respuesta

Construcción de Almacenes

CARGA HISTORICAEtapa 6

Carga Histórica

•Documentación OLTP•Requerimientos•Modelos Iniciales•Diseños de ETL

•ETL’s de Carga•Datos Históricos Cargados

• Se define la mejor manera de cargar los datos históricos hasta la fecha actual.

• Se ocupa recurrentemente el área de Staging.

• Se trabaja en conjunto con los administradores.

• Por lo general se construyen ETL’s que solo se utilizan para estas cargas.

• Se define mecanismo de validación de datos.

Carga Histórica

Construcción de etl’s de rutinaEtapa 7

Construcción ETL ‘s de Rutina

•Documentación OLTP•Requerimientos•Modelos Iniciales•Diseños de ETL

•ETL’s•Controles de Carga

• Con los Diseños se procede a crear los ETL’s

• Se Procede a crear “Jobs” de carga por tabla

• Se coordina la carga en “WorkFlows”:– Carga de Tablas de Dimensiones– Carga de Tablas de Hecho

• Posteriormente, se define el calendario de ejecución de los ETL’s

• Se define mecanismo de supervisión de carga (generalmente correo de confirmación de carga)

Construcción ETL’s de Rutina

DataFlow ETL Dimensión

DataFlow ETL Capa 1

DataFlow ETL Capa 2

Construcción universosEtapa 8

Construcción Universos

•Documento de Diseño de Modelos•Requerimientos Iniciales

•Universos

• Los Universos en BO representan una capa semántica que busca entregar a los usuarios finales un acceso rápido, en lenguaje natural y libre del SQL a los datos.

• Los Universos también permiten independizar esta presentación de los orígenes de los datos.

• Dentro de esta metodología, los Universos son un activo importante y por ende son sometidos a pruebas de pre entrega (completitud, sintaxis, etc.)

Construcción de Universos

Ejemplo Universo Biblioteca

Construcción de reportesEtapa 9

Construcción Reportes

•Universos•Requerimientos Iniciales

•Reportes Creados•Validación de Datos

• Los reportes en BI representan objetos dinámicos, fáciles de obtener y mutar, por lo que no se consideran un activo importante.

• Sin embargo, son la cara visible y el requerimiento más urgente del usuario.

• Adicionalmente, se utilizan para realizar la validación final de calidad de datos.

• Al construirlos también se define el canal de distribución.

Construcción de Reportes

• Despliegue en WebIntelligence

• Distribución – Casilla WebIntelligence– Correo Electrónico

• Formatos PDF, XLS, CSV• Calendario de ejecución (monitoreable)

– FTP• Formatos PDF, XLS, CSV• Calendario de ejecución (monitoreable)• Permite desarrollar despliegues con herramientas que no

requieren licenciamiento

Distribución de Informes

Ejemplo Distribución E-Mail

Ejemplo Distribución FTP

Ejemplo Distribución FTP

Agenda

Control de Becas de Alimentación

Alumnos por año de ingreso

Seguimiento por año de Ingreso

Uso de Biblioteca

Calendario de Accesos Mensuales

Satisfacción de Usuarios

• DTI

• Admisión

• Docencia Pregrado (Carga Docente)

• Docencia Postgrado (en construcción)

• Situación financiera del Estudiante (no completo)

• Biblioteca

• Telefonía

Principales DataMart Construidos

Data Integrator en Integraciones B2B

Formatea, Firma y envía

DocumentosClientes-SII

Clientes

Proveedores

Recibe, valida y entrega

Documentosa Sistema de Proveedores

11

33

44

22

33

22

22

1.- Emisión de DTE2.- Consulta Estado DTE3.- Recepción de DTO’s4.- Informe estado aceptación DTO’s

Factura Electrónica

Sistemas CorporativosSistemas Corporativos

Recaudación Corpbanca

• Negocio a UdeC– Archivos Ingresa (CAE)– Archivos Project (Fondo de Crédito)– Admisión, archivos DEMRE

• UdeC a UdeC– Archivos de Tarificación Telefónica– Alta disponibilidad de sistema de control de casinos

• UdeC a Negocio– Archivos para Credenciales TUDEC– SIES

Otros

Agenda

• Varios tipos de conocimiento:– Herramienta– Modelamiento multidimensional– Procesos universitarios– Sistemas universitarios (modelo de datos corporativo)– Arquitectura tecnológica

• Metodología de trabajo, documentación, orden.• Inicio sin fin (internet): decisiones siempre• ROI:

– Inversión: servidores, licencias, soporte, capacitación, asesorías– Retorno: ???

• No es fácil. Más tarde que nunca.• ETL : muy poderoso y multifuncional• Plataforma base ser cuidadoso

Consideraciones

• Divergencia conceptual de BI entre Usuarios y TI. Se confunde BI con un concepto comercial que implica compra de herramientas.

• Centralismo, falta de conocimiento experto regional. La apuesta debió ser la de “enseñar”.

• BI es una alternativa a la problemática de la falta de visibilidad de los datos operacionales. Muchas veces, esta falta se interpreta como falencia de la capa operacional y se impulsa un cambio en dichos sistemas, con un mayor costo.

• Resistencia al cambio. Los usuarios quieren seguir haciendo los análisis como saben, con Excel, papel, etc.

Dificultades

• ¿Cuál es el rol TI en una arquitectura empresarial BI?– Establecer el alcance del equipo técnico TI– ¿Solo construirá hasta los Universos? ¿Construirá informes?, ¿Tendrá que interpretar

resultados? ¿Capacitará a los usuarios?

• Elegir un buen partner. – El proceso de implantación demorará tanto como su equipo demore en madurar sus

conocimientos y su “experiencia”. Determinar qué tan importante es disminuir ese tiempo define qué grado de asesoría se necesita.

• Las capacitaciones y los contratos de mantención son inversiones!!!– ¿Le pasaría su Ferrari nuevo a alguien que no sabe manejar? ¿Le pasaría una moto sierra

para cortar un bosque a alguien que nunca ha usado una? La inversión tecnológica debe considerar los costos de aprendizaje.

– Es más efectivo realizar las capacitaciones a medida que avanza el conocimiento.

Lecciones Aprendidas

• Las herramientas son solo eso, herramientas– Facilitan las labores– Sin metodología, estrategia, conocimiento, no reditúan.

• ¿Es mi mayor problema?– ¿Cómo está mi capa operacional?– ¿Tengo capacidad de procesamiento?– ¿Tengo usuarios capaces de aprovechar la plataforma?

• ¿Qué quiero conocer? Cuidar las Expectativas– Acotar los objetivos de los proyectos a necesidades reales de negocio.– Evitar los excesos de imaginación de los usuarios (Quiero ver “toda” la información)

• Entender los requerimientos – Al principio no es fácil identificar qué requerimientos pueden ser satisfechos por BI.– Es importante estar constantemente evaluando los factores que permiten identificarlos.– Convertirse en “cazadores de datos”.

Lecciones Aprendidas

• La calidad de datos está subestimada en la capa operacional.– Datos incorrectos producen decisiones incorrectas.– Supervisar la Calidad de Datos es una tarea constante.

• La reportería operacional es de rápido efecto, pero, cuidado con los alambres!!!

– Buscando rápidos efectos se buscan reportes conectados directamente a la capa operacional.

– Como los datos no están disponibles de manera explícita, se tiene a crear herramientas facilitadoras (vistas, vistas materializadas, etc.)

– Cuando ya se entregan normalmente, muchas veces se evidencian situaciones operacionales que generan dudas sobre los datos, o bien, surgen cambios que no son de tan fácil solución.

Lecciones Aprendidas

• Cuidado con los indicadores– Partir por indicadores es una opción, sin embargo, existe el riesgo de no tener

antecedentes para explicar el por qué de ellos. Adicionalmente, también se corre el riesgo de tener incoherencias entre las fuentes y dichos indicadores.

• Sponsor adecuado– La “evangelización” de BI es compleja. Obtener los apoyos necesarios de la “alta

gerencia” es de vital importancia para poder tomar decisiones, por lo que a ellos debe apuntar la primera parte. En el caso UdeC, los mejores resultados han estado en la Dirección de Bibliotecas y Dirección de Docencia.

• No desaparece Excel!!– Lo que se elimina es la necesidad de realizar planillas base y crear informes consolidados

a partir de estas.– Excel se transformará en una herramienta más de explotación de la plataforma, en el

caso de BO, a través de LiveOffice o desde reportes distribuidos en formato XLS.

Lecciones Aprendidas

• Fortalecer el equipo.

• Seguir construyendo almacenes.

• Conseguir nivel de Dimensiones y Hechos

conformados.

• Consolidar la plataforma BI como un referente en

la toma de decisiones tácticas.

Próximos Desafíos

• Fortalecer lo avanzado y existente.

• Lograr una mayor cobertura.

• Mantener a los usuarios contentos.

• Realizar mediciones de satisfacción.

• Efectuar proyectos con otras herramientas de la suite

• Lograr reconocimiento y posicionamiento explícito.

Próximos Desafíos

Muchas Gracias…..

Consultas ????

cesar.gonzalez@udec.clrolando.burgos@udec.cl