universidad de concepción - edutic 2011
DESCRIPTION
Inteligencia de Negocios en el ambiente Universitario - Metodología y Casos PrácticosTRANSCRIPT
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
