UNIVERSIDAD CENTRAL DEL ECUADOR
FACULTAD DE INGENIERÍA, CIENCIAS FÍSICAS Y MATEMÁTICA
INSTITUTO DE INVESTIGACIÒN Y POSGRADO (IIP)
METODOLOGÍA DE INTELIGENCIA DE NEGOCIOS APLICANDO PRINCIPIOS ÁGILES PARA EL SERVICIO DE
RENTAS INTERNAS DEL ECUADOR
LUIS FERNANDO LLANGANATE MORENO
TUTOR: SILVIA ELIZABETH GARCÍA GONZÁLEZ
Trabajo presentado como requisito parcial para la obtención del grado de:
MAGÍSTER EN GESTIÓN INFORMÁTICA EMPRESARIAL
Quito – Ecuador
2015
DEDICATORIA
A Dios.
Por haberme permitido llegar hasta este punto, para seguir logrando todos mis objetivos en la vida, además por su infinita bondad amorosa que en cada respiro me permite seguir adelante y me acompaña en cada paso, recordando que no hay paso dado sin su bendición.
A mi Madre.
Por enseñarme como aprender de mis errores cada día y pese a todo por estar conmigo siempre diciéndome que sea fuerte, compartiendo conmigo su fortaleza.
A mi familia.
Por sus mágicas enseñanzas de vida, por su perseverancia y constancia que los caracterizan y que me han infundado siempre, por el valor mostrado para salir adelante en momentos difíciles y por su amor, por creer en mí antes que en nadie, ellos son mi inspiración.
Luis Fernando
AGRADECIMIENTOS
Al finalizar un trabajo tan arduo y lleno de dificultades, como es el desarrollo de una tesis de maestría, es inevitable que me asalte un muy humano egocentrismo que me lleva a concentrar la mayor parte del mérito en el aporte que se ha hecho. Sin embargo, el análisis objetivo me muestra inmediatamente que la magnitud de ese aporte, hubiese sido imposible sin la participación de personas e instituciones que me han facilitado las cosas para que este trabajo llegue a un feliz término. Por ello, es para mí un verdadero placer utilizar este espacio para ser justo y consecuente con ellas, expresándoles mis agradecimientos.
Debo agradecer de manera especial y sincera a la profesora Ing. Silvia García MSc por aceptarme para realizar esta tesis bajo su dirección. Su apoyo y confianza en mi trabajo y su capacidad para guiar mis ideas ha sido un aporte invaluable, no solamente en el desarrollo de esta tesis, sino también en mi formación como investigador. Las ideas propias, siempre enmarcadas en su orientación y rigurosidad, han sido la clave del buen trabajo que hemos realizado juntos, el cual no se puede concebir sin su siempre oportuna participación. Un enorme agradecimiento al Servicio de Rentas Internas del Ecuador por haberme facilitado siempre los medios suficientes para llevar a cabo todas las actividades propuestas durante el desarrollo de esta tesis.
Luis Fernando
AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL
Yo, LUIS FERNANDO LLANGANATE MORENO en calidad de autor del trabajo de tesis realizada sobre una: “METODOLOGÍA DE INTELIGENCIA DE NEGOCIOS APLICANDO PRINCIPIOS ÁGILES PARA EL SERVICIO DE RENTAS INTERNAS DEL ECUADOR”, por la presente autorizo a la UNIVERSIDAD CENTRAL DEL ECUADOR, hacer uso de todos los contenidos que me pertenecen o de parte de los que contiene esta obra, con fines estrictamente académicos o de investigación.
Los derechos que como autor me corresponden, con excepción de la presente autorización, seguirán vigentes a mi favor, de conformidad con lo establecido en los artículos 5, 6, 8, 19 y demás pertinentes de la Ley de Propiedad Intelectual y su Reglamento.
Quito, 01 de octubre del 2015.
--- LUIS FERNANDO LLANGANATE MORENO CI. 1709334930
CERTIFICACIÓN DEL TUTOR
En calidad de Tutor del proyecto de Investigación “METODOLOGÍA DE INTELIGENCIA DE NEGOCIOS APLICANDO PRINCIPIOS ÁGILES PARA EL SERVICIO DE RENTAS INTERNAS DEL ECUADOR”, presentado y desarrollado por Ingeniero LUIS FERNANDO LLANGANATE MORENO, previo a la obtención del Título de MAGÍSTER EN GESTION INFORMÁTICA EMPRESARIAL, considero que el proyecto reúne los requisitos necesarios.
En la ciudad de Quito, al 1 día del mes de octubre del año 2015.
Ing. Silvia Elizabeth García González MSc TUTORA
CONTENIDO
DEDICATORIA……….……….…ii
AGRADECIMIENTOS………..……….…………..……iii
AUTORIZACIÓN DE LA AUTORIA INTELECTUAL………...………..……….iv
CERTIFICACIÓN DEL TUTOR………..v
CAPÍTULO I ... 1
1.1 ANTECE DENTES...1
1.2 La necesidad de hacer las soluciones de la Inteligencia de Negocios más Ágiles 2 1.3 PLANTEAMIENTO DE HIP ÓTESIS...5
1.4 OB JE TIV OS ...5
1.4.1 GENE RAL ...5
1.4.2 ESPECÍFICOS ...5
1.5 JUSTIFICA CIÓN...5
CAPÍTULO II ... 7
2.1 LA INTE LIGENCIA DE NE GOCIOS (BI)...7
2.1.1 BI: El paradigma de la Información ...7
2.1.2 Estilos de toma de decisiones... 10
2.2 ME TODOLOGÍAS ÁGILES ... 12
2.2.1 Agilidad ... 12
2.3 EL MA NIFIES TO ÁGIL ... 13
2.4 PEOPLEWARE,(DEMARCO &LIS TE R,2002)... 15
2.4.1 La gente... 15
2.5 DATA WAREHOUSE ÁGIL ... 19
2.5.1 El Departamento de Tecnología de la Información y el Negocio: Alineación o amistad 23 2.5.2 Información Institucional ... 24
2.5.3 El usuario institucional ... 26
2.5.4 El usuario en un equipo de trabajo ... 26
2.5.5 Reuniones de trabajo. ... 28
2.5.6 Interrupciones. ... 29
CAPÍTULO III ... 33
3.1 PROYECTOS DE INTELIGENCI A DE NEGOCIOS Y METODOLOGÍAS ÁGILES... 33
3.2 CICLO DE VIDA DE UN PROYECTO INTELIGENCIA DE NEGOCIOS... 35
3.3 REVISIÓN DE LAS PROP UESTAS METODOLÓGI CAS DE INTELI GENCIA DE NEGOCIOS ... 36
3.4 PRINCIPIOS ÁGILES ... 38
3.5 REVISIÓN DE LOS FACTORES CRÍTICOS DE ÉXITO DE LA INTELIGENCIA DE NEGOCIOS (CSF) 39 3.6 RELACIÓN ENTRE EL ENFOQUE ÁGIL Y LOS FACTORES CRÍTICOS DE ÉXITO EN LOS PROYECTOS DE INTELIGENCI A DE NEGOCIOS... 40
3.7 ANÁLISIS DE LAS RELACIONES PARA EL CASO DEL SERVICIO DE RENTAS INTERNAS DEL ECUADOR ... 43
CAPÍTULO IV... 50
4.1 METODOLOGÍA DE INTELIGENCIA DE NEGOCIOS APLICANDO PRINCIPIOS ÁGILES PARA EL SERVICIO DE RENTAS INTE RNAS DEL ECUA DOR ... 50
4.1.1 PROCESO ... 50
4.1.1.1 Entendimiento ... 55
4.1.1.2 Construcción ... 57
4.1.1.3 Aplicación ... 58
4.1.2 ROLES DE LA NUEVA METODOLOGÍA ... 59
4.1.3 APLICACIÓN PARA UNA PROBLEMÁTICA DE UN PROCESO TRIBUTARIO PARA EL SERVICIO DE RE NTAS INTERNAS DEL ECUA DOR. ... 61
4.1.3.1 Primera Iteración: ... 62
4.1.3.2 Segunda Iteración: ... 67
4.1.3.3 Tercera Iteración: ... 68
CAPÍTULO V... 71
5.1 CONS IDE RACIONES DE RÉPLICA DE LA NUEVA ME TODOLOGÍA ... 71
5.1.1 ARQUITECTURA DE LA METODOLOGÍA DE INTELIGENCIA DE NEGOCIOS APLICANDO PRINCIP IOS AGILES. ... 71
5.1.2 GESTIÓN DE LA METODOLOGÍA DE INTELIGENCIA DE NEGOCIOS APLICANDO PRINCIPIOS AGILES. 80 5.1.2.1 FÁBRICA DE INFORMA CIÓN ... 81
5.1.2.2 CUA TRO DOMINIOS DE LA INTELIGE NCIA EN REFERE NCIA A LA NUEVA ME TODOLOGÍA. 82 5.1.2.3 GES TIÓN DE LA INFORMA CIÓN INS TITUCIONAL... 83
5.1.2.3.1 LEVANTAMIE NTO DE LA NECES IDAD DE INFORMACIÓN ... 87
5.1.2.3.2 CAPTURA DE DA TOS ... 88
5.1.2.3.3 PROCESAMIE NTO DE DA TOS ... 88
5.1.2.3.4 ALMACE NAMIE NTO DE INFORMACIÓN... 89
5.1.2.3.5 USO DE INFORMACIÓN... 90
5.1.2.3.6 ACTUALIZACIÓN DE ACTIV OS DE INFORMACIÓN... 91
CAPÍTULO VI... 92
6.1 CONCLUSIONES ... 92
6.2 RE COME NDA CIONES ... 92
ANEXO 1 ... 94
ANEXO 2 ... 99
ANEXO 3 ...113
GLOSARIO ...115
BIBLIOGRAFÌA ...126
BIOGRAFÌA ...128
LISTADO DE FIGURAS
Figura 1 Pirámide de la Información. ... 8
Figura 2 Clasificación de los proyectos según su complejidad e incertidumbre. ... 9
Figura 3 Perfiles vs Estilos de Toma de Decisiones ... 11
Figura 4 Puntos de intervención Usuarios – Data Warehouse ... 20
Figura 5 El diamante de Leavitt ... 31
Figura 6 Modelo tradicional en cascada para soluciones BI... 50
Figura 7 Proceso de la nueva metodología de Inteligencia de negocios aplicando principios ágiles ... 51
Figura 8 Tres Iteraciones iniciales recomendadas en la nueva metodología... 52
Figura 9 Arquitectura de capas del DWH ... 73
Figura 10 Diferencia de Almacenamiento filas vs columnas ... 75
Figura 11 Acceso a los atributos por columnas ... 76
Figura 12 Arquitectura Ágil para la Metodología de Inteligencia de Negocios basada en Principios Ágiles ... 77
Figura 13 Ciclo del Proceso de Información ... 81
Figura 14 Cuatro Dominios de la Inteligencias conforme la Metodología ... 83
Figura 15 Gestión de la Información Institucional ... 84
Figura 16 Modelo de Información ... 85
LISTADO DE TABLAS
Tabla 1 Siete puntos de aprovechamiento de Metodologías Ágiles ... 12
Tabla 2 Detalle de los 4 valores de las metodologías ágiles para BI ... 13
Tabla 3 Doce principios de las metodologías ágiles. ... 15
Tabla 4 Barreras de desconfianza en proyectos de desarrollo de software... 16
Tabla 5 Siete características de una metodología de BI... 36
Tabla 6 Catorce enfoques para proyectos BI ... 37
Tabla 7 Doce principios ágiles ... 38
Tabla 8 Factores Críticos de Éxito de BI ... 40
Tabla 9 Los factores primarios ... 41
Tabla 10 Los factores secundarios ... 41
Tabla 11 Factores con pesos en función del total y acumulados ... 42
Tabla 12 Relación CSF y principios ágiles para el Servicio de Rentas Internas del Ecuador ... 43
Tabla 13 Matriz numérica de la relación CSF y principios ágiles para el SRI ... 44
Tabla 14 Ponderación de la matriz numérica de la relación CSF y principios ágiles para el Servicio de Rentas Internas del Ecuador ... 45
Tabla 15 Cinco factores con mayor ponderación de la relación CSF y principios ágiles para el Servicio de Rentas Internas del Ecuador ... 45
Tabla 16 Pesos a considerar en los tiempos para cada iteración de la Metodología. ... 53
Tabla 17 Distribución de tiempos considerando 3 iteraciones de 40 horas laborables ... 54
Tabla 18 Actividades de la nueva metodología en función de sus pesos ... 54
Tabla 19 Cronograma inicial para sistematización de Reportes Ejecutivos para el SRI... 62
Tabla 20 Ejemplo de utilización de herramientas en sus fases ... 64
Tabla 21 Entregables de la nueva metodología ... 64
Tabla 22 Comparación entre la construcción de Reportes Ejecutivos bajo una metodología tradicional y ágil ... 70
Tabla 23. CSF y CFF ... 94
Tabla 24. Factores de éxito del líder de proyecto de BI... 94
Tabla 25. Intervenciones... 95
Tabla 26. Criterios de usuario ... 95
Tabla 27. Errores en el proyecto BI ... 95
Tabla 28. Tips de proyectos BI ... 96
Tabla 29. Criterios de proyectos BI ... 96
Tabla 30. Criterios organizacionales de BI ... 97
Tabla 31. Criterios de Data Warehouse ... 97
Tabla 32. Criterios metodológicos ... 97
Tabla 33. Criterios de planificación... 98
RESUMEN
METODOLOGÍA DE INTELIGENCIA DE NEGOCIOS APLICANDO PRINCIPIOS ÁGILES PARA EL SERVICIO DE RENTAS INTERNAS DEL
ECUADOR
Los proyectos de construcción de soluciones de Inteligencia de Negocios han cambiado su alcance, hasta hace poco tiempo era aceptable que su duración promedio sea de varios meses e inclusive años, pero hoy en día para la mayoría de las organizaciones, y sobre todo en una economía globalizada y competitiva, es básico, poder disponer de la flexibilidad suficiente para adaptar sus procesos de toma de decisiones en función de los constantes cambios que suceden.
Día a día, los requerimientos de Inteligencia de Negocios, se han vuelto más complicados y por ende hacer que su desarrollo se mantenga estable hasta que finalice con éxito una implantación es aún más difícil. Por otro lado para una problemática similar, los principios de las metodologías ágiles cada vez están demostrando ser más efectivas y eficientes para los ambientes de desarrollo de software.
El presente trabajo de investigación explora los principios de las metodologías ágiles que han sido aplicadas en el desarrollo de software y basados en una particular adaptación generar una nueva metodología replanteando conceptualmente todos los componentes de la Inteligencia de Negocios desde la perspectiva “ágil”, en busca de su gobernanza, un concepto moderno e innovador de última data, finalmente la nueva metodología es aplicada para un problema en particular en la administración tributaria del Servicio de Rentas del Ecuador.
DESCRIPTORES: INTELIGENCIA DE NEGOCIOS / METODOLOGÍAS ÁGILES / DATA WAREHOUSE / GESTIÓN DE LA INFORMACIÓN / GOBIERNO DE DATOS / CICLO DE VIDA DE LA INFORMACIÓN.
ABSTRACT
BUSINESS INTELLIGENCE METHODOLOGY BASED ON AGILE PRINCIPLES FOR THE INTERNAL REVENUE SERVICE OF ECUADOR Business Intelligence development projects have an increased importance. Until recently, an average project duration of many months or even years was acceptable but today, given a competitive global economy, most organizations need the flexibility to quickly adapt their decision making processes in order to respond to the constant changes they encounter.
Day after day, Business Intelligence requirements become more complex and as a result, stable development and successful implementations are more difficult. On the other hand, the principles of the Agile methodology have proven effective and efficient in software development.
This research work explores the Agile methodology applied to software development and leverages it to formulate a new, adapted Business Intelligence methodology based on its innovative principles and governance. Subsequently, this new methodology is applied to a Tax Administration problem in the Revenue Service of Ecuador.
KEYWORDS: BUSINESS INTELLIGENCE / AGILE METHODOLOGY / DATA WAREHOUSE / INFORMATION MANAGEMENT/ GOVERNMENT DATA / LIFE CYCLE OF INFORMATION
Quito, 1 de octubre del 2015
CERTIFICACIÓN
Certifico que el resumen del trabajo de tesis titulado “Metodología de Inteligencia de Negocios aplicando Principios Ágiles para el Servicio de Rentas Internas del Ecuador” se ha realizado en pleno conocimiento del idioma inglés. Se anexa el título universitario que respalda la suficiencia en dicho idioma.
Ing. Carlos Rudyard Vásconez Soria
CI. 171025976
CAPÍTULO I
1.1 Antecedentes
La Inteligencia de Negocios (Business Intelligence o BI) ayuda a las organizaciones en el análisis de sus: operaciones de negocio, posición competitiva y productividad para que sus administradores puedan tomar las mejores decisiones y cada vez de forma más rápida. La funcionalidad más común de las soluciones de Inteligencia de Negocios incluye la presentación de reportes, análisis, dashboards, scorecards, minería de datos, gestión del rendimiento corporativo (CPM) y análisis predictivo entre otros elementos.
La Inteligencia de Negocios es el cumulo de habilidades, el conocimiento, tecnologías, aplicaciones, calidad, riesgos, problemas de seguridad y prácticas utilizadas para ayudar a la organización a adquirir una mejor comprensión del comportamiento de su entorno y su contexto de ser el caso. Cuando están bien construidas, las soluciones de Inteligencia de Negocios ayudarán a una organización en el establecimiento de la adecuada estrategia que le lleve un paso por delante de la competencia o para sobrevivir a través de una crisis organizacional.
Los directivos de toda organización necesitan información detallada sobre el rendimiento en sus planes estratégicos y el día a día de las operaciones, de manera que puedan tomar decisiones oportunas y bien fundamentadas, pero carecen por lo general del acceso a la información que necesitan y que les puede ayudar a mejorar su conocimiento. La Inteligencia de Negocios no es un tema simple, debido a que se encarga de la recopilación, integración, análisis, interpretación y presentación de la información institucional, es capaz de entregar un gran valor organizacional, pero los enfoques tradicionales de metodologías de desarrollo de Tecnologías de Informacióm no son aplicables a la Inteligencia de Negocios cuyo objetivo es proporcionar información oportuna y significativa que ayude a la gestión eficiente.
De todo el tiempo y el dinero gastado en las soluciones de la Inteligencia de Negocios de hoy en día, son relativamente pocas las organizaciones que cuentan
con un importante valor organizacional de sus inversiones en esta área. Para ofrecer el valor correcto y retornar sus inversiones, debe superarse un obstáculo importante: las metodologías tradicionales de desarrollo para la Inteligencia de Negocios son muy rígidas, lentas y costosas.
La presente investigación técnica ofrece una visión de la necesidad de una metodología para la agilidad de la Inteligencia de Negocios y de esta manera las organizaciones pueden finalmente cosechar los frutos del trabajo en esta área.
1.2 La necesidad de hacer las soluciones de la Inteligencia de Negocios más Ágiles
Hoy en día las organizaciones líderes en el mercado existen en función de sus datos, para competir mejor en el mercado global, transformándose de ser organizaciones basadas en su intuición a ser organizaciones basadas en hechos para la toma de decisiones, tema del que dependerá incluso su propia supervivencia, para realizar con éxito esta transición la panacea es el acceso oportuno y rápido a la información que permita las mejores decisiones de gestión lo que se ha convertido en una necesidad tan imperiosa tal como en la época medieval lo era la búsqueda del santo grial.
Aunque la mayoría de las organizaciones de Tecnologías de Información han empezado a aplicar metodologías ágiles en sus proyectos de desarrollo, aun así los proyectos de la Inteligencia de Negocios están siendo ampliamente implementados usando la tradicional metodología en cascada del desarrollo de software.
La razón primordial por la que en los proyectos de Inteligencia de Negocios no se han utilizado aún una metodología ágil, se encuentra probablemente en las diferencias fundamentales que se dan desde el inicio del proyecto en los requerimientos y documentación.
Los requerimientos para los proyectos de aplicaciones transaccionales son bien definidos y estáticos por naturaleza, los de Inteligencia de Negocios son impulsados por metas y objetivos estratégicos de negocio y son fluidos, dinámicos y en continua evolución. Además los requerimientos de Inteligencia de Negocios se
centran en el seguimiento de los procesos comparándolos con metas y objetivos, la planificación evoluciona y cambia en respuesta al cambio operacional de las expectativas, entonces naturalmente la solución de Inteligencia de Negocios también cambiará.
Hoy en día, la mayoría de soluciones de la Inteligencia de Negocios consideran metodologías que tienen estrechos vínculos con la metodología de desarrollo de software en cascada. En esta metodología el desarrollo es visto como un proceso secuencial, que fluye hacia abajo (en forma constante como una cascada) a través de las fases de análisis, diseño, construcción, pruebas, implantación y mantenimiento.
La planificación es metódica, los requerimientos se esperan por adelantado, son fuertemente estructurados bien documentados (toda una ingeniería de requerimientos) y sus procesos altamente burocráticos. La idea detrás del modelo de cascada puede expresarse en la siguiente frase: "Medir una sola vez, pero bien", pero quienes se oponen al modelo de cascada argumentan que esta idea tiende a desmoronarse cuando el problema que se está midiendo está en constante cambio debido a la exigencia de modificaciones sobre el problema en sí.
“Sólo el 16% de todos los proyectos de desarrollo de software se entregan a tiempo y dentro del presupuesto, y el sobrecosto promedio es de 189%”, Jiménez (2007).
Los enfoques tradicionales de entregables de las aplicaciones operacionales no construyen fuertes conexiones entre los usuarios y la información, debido al tiempo que transcurre entre la fase de levantamiento de requerimientos y entrega de la misma, al igual que en las metodologías tradicionales de desarrollo de aplicaciones en cascada, los enfoques tradicionales de Inteligencia de Negocios sufren de estos problemas.
Los usuarios finales se sienten desconectados del equipo a cargo y con frecuencia decepcionados por los entregables y su incapacidad para hacer frente a sus necesidades.
Normalmente las soluciones de Inteligencia de Negocios se centran en una pequeña población de usuarios, pero con requerimientos de información muy complejos y difíciles de manejar, con frecuencia obligando a las organizaciones a depender de informáticos descentralizados que generan informes personalizados utilizando herramientas tales como hojas de cálculo o gestores de bases de datos fáciles de administrar, para superar la gran cantidad de requerimientos de información. La recopilación de la información de esta manera es un proceso puntual e ineficiente.
Los usuarios a menudo terminan en la lista de espera semanas o meses para recibir los informes especializados creados a partir de acceder a múltiples bases de datos y aplicaciones, lo cual a la postre resulta poco óptimo y caro. La pérdida de tiempo se incrementa porque los directores no pueden acceder fácil y oportunamente a la información generada y en esta difícil economía más que nunca, el tiempo es dinero. Así como las organizaciones están migrando de desarrollo de software de las metodologías tradicionales a más ágiles, de ese camino se pueden obtener beneficios similares en los temas de Inteligencia de Negocios.
El Desarrollo Ágil de software opta por hacer las cosas en pequeños incrementos, con una planificación mínima, en lugar de una planificación a largo plazo, son iteraciones en plazos cortos que por lo general duran de una a cuatro semanas.
La conformación del equipo en un proyecto ágil suele ser multifuncional y de auto- organización, no se considera jerarquías corporativas ya existentes o funciones corporativas de los miembros del equipo. Normalmente, los miembros del equipo asumen la responsabilidad de las tareas dadas en una iteración y deciden por sí mismos la forma en que se ejecutará la siguiente iteración.
Los métodos ágiles enfatizan la comunicación a través de documentos escritos no tan formales y a su vez reflejan en ellos la principal medida de progreso.
Enfatizando la comunicación face to face (personalizada y frente al usuario), por lo general las metodologías ágiles suelen producir menos documentación escrita que otras metodologías.
1.3 Planteamiento de Hipótesis
El uso de las metodologías ágiles del desarrollo convencional de software, presentan diferentes alternativas de toma de decisiones gerenciales, de acuerdo a los criterios relevantes.
1.4 Objetivos 1.4.1 General
Aplicar los principios de las metodologías ágiles en la construcción de informes ejecutivos tributarios en el Servicio de Rentas Internas en Quito, Ecuador.
1.4.2 Específicos
Describir las fases para la aplicación de los principios de las metodologías ágiles en la Inteligencia de Negocios.
Usar herramientas de inteligencia de negocios existentes en el mercado (SAP Business Objects).
Aplicar las metodologías ágiles para los informes ejecutivos tributarios en el Servicio de Rentas del Ecuador.
Especificar consideraciones para la réplica de la aplicación de las Metodologías ágiles de Inteligencia de Negocios para otras organizaciones.
1.5 Justificación
El auge de las denominadas soluciones de la Inteligencia de Negocios ha ahondado la realidad de que la mayoría de estos proyectos han fracasado en conseguir sus objetivos. De hecho, tampoco es de extrañar el alto índice de fracaso, al tratarse de sistemas intensamente orientados a la Información y de una disciplina todavía no madura con diversidad de enfoques metodológicos y todo un ecosistema de terminología técnica.
¿Cuál sería la metodología más apropiada para reducir el fracaso de las implementaciones de los proyectos de Inteligencia de Negocios? Obviamente, aquella que potenciara los factores de éxito de la información, siendo muchos los que se han identificado, sin embargo el principal de ellos, hace referencia a los
datos que producen los sistemas operacionales de los usuarios transaccionales y el resto hacen referencia a la organización del proyecto, al usuario de negocio y a temas metodológicos.
Así pues, por la naturaleza de los temas referentes al concepto de información es que se deberá utilizar una metodología de inteligencia de negocios focalizada en los datos del usuario. ¿Podrían servir los principios de las metodologías ágiles en procura de mejorar el proceso de construcción de soluciones de inteligencia de negocios?
El presente trabajo de investigación da respuesta a esta interrogante pero adicionalmente busca una aplicación práctica de la nueva metodología ágil de la Inteligencia de Negocios aplicando los principios ágiles de desarrollo de software para una solución en el ámbito tributario del Servicio de Rentas Internas, en Quito - Ecuador.
CAPÍTULO II
2.1 La Inteligencia de Negocios (BI)
2.1.1 BI: El paradigma de la Información
Ken Coller en su libro “Agile Analytics a Value-Driven Approach to Business Intelligence and Data Warehousing”, (Coller, 2011) hace una analogía entre el enfrentar proyectos de Inteligencia de Negocios y el escalar un monte muy elevado como es el caso del Everest en el cual muchos escaladores mueren en el intento, menciona que de cada 4 escaladores por lo menos uno no lo logra.
Una organización sin la utilización de la información se parece mucho a esta situación, en donde de no preparar sus recursos necesarios para la toma de decisiones, pese a la correcta ejecución de los procesos organizacionales está muy lejos de cumplir con sus objetivos estratégicos pues sin información en sus manos, no sabe lo que hace y es muy probable que tampoco sepa a donde va, por tanto finalmente sucumbe.
Ciertamente la Inteligencia de Negocios es un término de amplia definición que alberga diferentes acrónimos, herramientas y disciplinas: OLAP, Data Warehouse, Data mart, Minería de Datos, Executive Information Systems, Decisión Support Systems, Redes Neuronales, Sistemas Expertos, Cuadros de Mando, Balanced Scorecards por mencionar algunos.
Sin embargo de ello sus beneficios se pueden expresar de tres maneras:
La primera de ellas es proveer de información para el control de los procesos de negocio, independientemente de donde se encuentre almacenada esta información.
Como se muestra en la Figura 1, referente a la Pirámide de Información propuesta por (Páez Urdaneta, 2009) en donde se toma en cuenta la calidad y cantidad de Información, a menor cantidad de información mayor calidad de la misma es requerida, por tanto una vez resuelto este tema la problemática radica en la disposición de la información para los diferentes niveles organizacionales. El nivel
de agregación y unificación de fuentes heterogéneas de datos será mayor para los procesos de carácter analítico y es precisamente este motivo el que da un nuevo matiz a la definición de Inteligencia de Negocios: el soporte a la toma de decisiones su característica más notable
Figura 1 Pirámide de la Información.
Fuente: Páez Urdaneta (2009)
La Inteligencia de Negocios, no solo se limita a presentar la información sino que otorga al usuario la capacidad de analizar y navegar sobre ella a voluntad según la requiera. En la toma de decisiones este análisis es fundamental, no se toman decisiones con una sola información, las informaciones se mezclan, se relacionan entre sí, se cruzan.
De lo dicho se tiene la siguiente reflexión: ¿Quién toma las decisiones con la información que le hemos entregado necesita saber de tecnologías de información para interpretarla? La respuesta es NO, debe saber del negocio. Y aquí nace la tercera característica de la Inteligencia de Negocios; la capa semántica.
El negocio habla su propio lenguaje, da igual donde está la información almacenada y como se haya transformado, esta información da al usuario final un lenguaje de negocio que el comprende y con el que se siente cómodo y que no necesita un
traductor adicional. En este aspecto la Inteligencia de Negocios es clara: la información reduce la incertidumbre (sobre algún aspecto de los procesos del negocio) y por tanto permite tomar mejores decisiones.
Complementando lo anterior, revisemos los aspectos económicos con las prácticas de la Inteligencia de Negocios, en el sentido de la necesidad de agilidad de la misma, una propuesta es la clasificación de la cartera de proyectos relacionados con la incertidumbre y complejidad que éstos presentan, (Little, 2005). Bajo esta clasificación la cartera de proyectos se divide en cuatro tipos diferenciados, llamados como “perros”, “potros”, “vacas” y “toros”. La Figura 2 se muestra el cuadrante utilizado para segmentar la cartera de proyectos aplicables a la Inteligencia de Negocios, Little, (2005) el autor lo denomino Mapas de Houston.
Figura 2 Clasificación de los proyectos según su complejidad e incertidumbre.
Fuente: Little (2005)
Existen diferentes niveles de incertidumbre, caracterizadas por una serie de variables como son: incertidumbre del negocio, incertidumbre técnica, duración del proyecto, dependencias con otros proyectos y en cuanto a la complejidad del proyecto otras variables adicionales tales como: interés por parte del negocio, tamaño del equipo de trabajo, misión crítica, ubicación del equipo, capacidad y carga de trabajo, brechas de conocimiento, clima laboral, dependencias.
Los estudios realizados por (Little, Cockburm, Boehm & Turner, 2005) concluyen que para cada conjunto de proyectos se propone aplicar una metodología de desarrollo diferente, que varía desde metodologías más ágiles, hasta los tradicionales procesos planificados dependiendo de las diferentes variables. Bajo este concepto únicamente se evalúa el riesgo global de cada proyecto y se aplica un tipo de ciclo de desarrollo más o menos orientado a controlar ese riesgo.
2.1.2 Estilos de toma de decisiones.
En todo momento la mayor parte de directivos participan en algún aspecto en la toma de decisiones ya sea intercambiando información, revisando datos, sugiriendo ideas, evaluando alternativas o ideando directrices, se pensaría que este proceso sería un problema para el planteamiento formal de la agilidad. Sin embargo, el modo en el que un directivo de éxito enfoca el proceso de toma de decisiones varía conforme a la organización en la cual se aplique y sería importante en principio identificar sus estilos.
1. Existen dos principales características sobre el perfil del tomador de decisiones:
a. Uso de la información.
¿Cuanta información se necesita consultar antes de tomar una decisión?
¿Toda la existente? ¿Solo una poca hasta hacernos una idea? ¿Exhaustiva y contrastada o por el contrario la suficiente para generar una hipótesis?
En el caso de los tomadores de decisiones que necesitan abundante información, consultarla toda y estar seguros que esa es la mejor solución, ese es el perfil "Maximizador".
Para el caso de los que necesitan la información justa para poder ponerse manos a lo obra, es el perfil de los "Satisfechos", es decir, deciden cuando tienen la información suficiente para satisfacerse.
b. El objetivo como parte importante cuando se toma esa decisión.
¿Solo tienen un objetivo en mente cuando toman una decisión? ¿Un camino único, recto y lineal, con un objetivo claro? ¿La decisión puede satisfacer la
consecución de varios objetivos? ¿Varios caminos no del todo definidos pero que pueden satisfacer las necesidades?
Para quienes eligen el camino recto y un único objetivo, son la clase conocida como "Única opción", si en cambio consideran varios cursos de acción posible entonces la etiqueta es de "Opciones múltiples"
2. Se pueden identificar 4 perfiles de "estilo de toma de decisiones" basados en los dos aspectos anteriores de acuerdo a la figura 3.
Figura 3 Perfiles vs Estilos de Toma de Decisiones
Fuente: Autor
Para las soluciones de la Inteligencia de Negocios se tiene un producto cartesiano en el que se agrupan todas las posibilidades según una estructura dimensional con todos los cálculos. Este enfoque de adquisición se parece mucho al perfil de toma de decisiones Jerárquico, que se vincula con los mandos con carácter más operacionales que bajo mecanismos tradicionales, se vuelven muy difíciles de entregar la información necesaria.
Muchas veces en los cargos cercanos a Director General, se tienen quejas de la poca flexibilidad de los sistemas de Inteligencia de Negocios, en concreto de los cuadros de mando, pues bien según el perfil en este nivel es flexible.
Las soluciones de la Inteligencia de Negocios sirven en los entornos operacionales y tácticos, pero en los niveles de decisión estratégicos los caminos son múltiples y no se necesita tener "toda" la información, sino a propósito información muy resumida cuyo origen debe tener una alta calidad de datos.
2.2 Metodologías Ágiles 2.2.1 Agilidad
David Peterson, en su artículo “What's wrong with the Agile Manifesto?”, Little (2005), promueve que aquellos que han descubierto mejores formas de desarrollar software tienen una cierta obligación para con los demás que aún no lo han hecho y deben ayudarlos. Esto no significa que a todo "no-creyente" de las Metodologías Ágiles que se crucen en el camino deben ser “evangelizados”.
Los siguientes 7 puntos deben considerarse básicos para que una organización pueda abordar un proyecto utilizando metodologías ágiles y se refieren a diversos cambios.
Tabla 1 Siete puntos de aprovechamiento de Metodologías Ágiles
Fuente; Recopilación Autor
Para el caso en las que las organizaciones tienen un elevado nivel de rotación de personal es altamente recomendable la aplicación del punto siete en cuanto a intercambiar permanentemente los roles de experticia.
1. El estilo de gestión de "orden y control" hacia
"liderago y colaboración"
Se reemplaza el esquema tradicional de ordenes a los subalternos por un coaching del lider mediante la continua motivación.
2. La cultura organizacional "de centrada procesos" a
"orientada a procesos"
La ágilidad es generada por las personas en torno al proceso y no al contrario
3. La gestión del conocimiento de "explicito" a "tácito" La documentación excesiva al final corta la creatividad de las personas.
4. La comunicación de "formal" a "informal" Los vinculos comunicantes no deben ser rigidos sino flexibles.
5. El rol de usuario final de "importante" a
"fundamental"
Los usuarios forman parte del equipo de desarrollo en lugar de solo un observador.
6. La estructura de la organización de "jerarquica" a
"orgánica" Pasar de una excesiva burocracia a una flexible , reflexiva y cooperativa 7. De "roles estrictos" a" "roles intercambaibles" Capacidad Técnica de Multifuncionalidad de los funcionarios
2.3 El Manifiesto Ágil
En el Manifiesto Ágil se definen los cuatro valores por las que se deberían guiar las metodologías ágiles:
• Los individuos e interacciones sobre procesos y herramientas.
• El software en lugar de una amplia documentación.
• Centrado en el usuario antes que la negociación de un contrato.
• Responder al cambio en lugar de seguir un plan.
El Manifiesto Ágil fue firmado por (Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland & Dave Thomas, 2005) cientificos considerados como pioneros y padres del concepto. A continuación se analiza a mayor detalle los mencionados valores:
Tabla 2 Detalle de los 4 valores de las metodologías ágiles para BI
Fuente: Cockbourn (2001)
Algunos enfoques populares de los que proceden el manifiesto y principios ágiles son: Programación Extrema (XP), SCRUM, DSDM, etc. y que son en la práctica hoy en día casos de éxito. La transición del desarrollo de software tradicional a una metodología ágil no está exenta de retos y muy pocas organizaciones pueden demostrar el éxito de la adopción de este enfoque que es bastante nuevo.
(Kendall & Kendall, 2005) postula que el enfoque de desarrollo de software tradicional llamado el desarrollo de software de ciclo de vida en cascada hizo hincapié en la comprensión, la diagramación y el diseño de los sistemas de información. Los enfoques ágiles se centran más en las personas con la afirmación
1. Los individuos e interacciones sobre los procesos y herramientas.
La experiencia de la gente hace que los procesos y herramientas sena mejor apovechados.
2. Centrado en el software en lugar de una amplia documentación.
La idea es que la documentación sea mas visual que textual la misma no puede ser mas importante que el desarrollo del software.
3. Centrado en el usuario antes que la rigidez de los reqerimientos funcionales.
La persepción del sentido de propiedad del usuario mejora la comunicación entre las partes interesadas.
4. Respuesta al cambio versus la rigidez del plan Bienvenida a los cambios los cuales no constituyan excepciones sino por el contrario.
de que la gente está en la raíz de todos los errores y defectos. La creatividad humana puede asumir el control cuando los procesos estructurados y formales no tienen en cuenta los problemas del sistema.
Kendall & Kendall (2005) indica que las metodologías ágiles sólo tienen éxito cuando todas las partes interesadas colaboran y sólo funcionan bien cuando la cultura organizacional apoya la colaboración y si las estructuras organizacionales son menos jerárquicas, pues enfatizan pequeñas entregas incrementales sin perder la funcionalidad de un sistema. El enfoque de aproximación ágil pretende que las personas mejoren la calidad de los sistemas a través de una mayor comunicación y colaboración.
En contraste con las metodologías tradicionales, el enfoque ágil traza las diferencias fundamentales que deben tomarse en cuenta en la adopción de las mismas. El desarrollo tradicional se ha estructurado en fases: requerimientos, diseño, desarrollo, pruebas y producción, que siguen completando cada fase antes de pasar a la siguiente. El planteamiento ágil propone ciclos iterativos que producen pequeños avances en características o componentes del sistema. El desarrollo tradicional incluye líneas de tiempo que se pueden extender hasta años antes de producir software productivo; El esquema ágil se centra en la producción de software que trabaja en lanzamientos en cajas de tiempo más pequeñas (semanas).
El desarrollo tradicional incluye grandes equipos de especialistas versus individuos ágiles que hacen hincapié en equipos de programadores versátiles. La colaboración en el desarrollo tradicional sucede de forma intermitente durante las fases donde la agilidad se centra en la colaboración constante entre las partes interesadas.
Como consecuencia de estos cuatro valores, el Manifiesto Ágil también enuncia los doce principios que caracterizan un proceso ágil que se muestran en la Tabla 3.
Hasta este punto se puede intuir que las formas de hacer las cosas están cambiando, adaptándose más a las personas y a las organizaciones en las que han de funcionar las aplicaciones.
¿Esto es la antesala de una revolución? Posiblemente. ¿Pero se puede aplicar esta metodología a los sistemas orientados a la información o solo es aplicable a los sistemas operacionales?
Tabla 3 Doce principios de las metodologías ágiles.
Fuente: (Jeft Sutherland, 1993) 2.4 Peopleware, (Demarco & Lister, 2002)
2.4.1 La gente
Cuál es el inicio para empezar a adoptar el término “ágil”?. Es algo tan sencillo, como la pregunta: para que moverse hacia las metodologías ágiles en una organización, El valor fundamental a considerar es? : La confianza.
Al abandonar paulatinamente el control basado en procesos, se empieza a confiar en que las personas desarrollarán su trabajo de la manera adecuada porque saben y quieren hacerlo. Esto tiene numerosas implicaciones, por ejemplo y de repente el departamento de gestión de la calidad no tiene que vigilar el obligado cumplimiento de normas, procesos y burocracia.
Los empleados y jefes deben confiar en sus compañeros. Confianza en los conocimientos de los empleados, en su sabiduría y buen hacer. Confianza en la
I La prioridad es satisfacer al usuario mediante tempranas y continuas entregas de software que aporten valor.
II Dar la bienvenida a los cambios incluso al fnal del desarrollo, estos le darán una ventaja competetiva al usuario.
III Los intervalos de entrega de software deben ser lo mas coryos posibles considerando dias y semanas en lugar de años y meses.
IV El equipo de trabajo esta conformados por la gente del negocio y desarrolladores durante todo el proyecto.
V El proyecto funciona sobre personas moivadas que tiene todo el apoyo y confianza que necesitan.
VI El dialogo face to face es el método más eficiente y efectivo para comunicar información dentro de un equipode desarrollo.
VII El software que funciona es la mejor medida de progreso.
VIII Los procesos ágiles promueven un desarrollo sostenido, el equipo de trabajo deben mantener un ritmo de desarrollo constante.
IX La atención continua a la calidad técnica y el buen diseño mejoran la ágilidad.
X La simplicidad es esencial, se ha de saber minimizar el trabajo que NO se debe realizar.
XI Las mejores soluciones de software surgen de los equipos auto- organizados.
XII El equipo de trabajo debe autoevaluarese constantemente y ajustar su compartamiento.
palabra de las personas. No se necesita poner exhaustivamente todo por escrito.
Confiar en ellos, si dicen algo lo harán. Pasar a un modelo colaborativo exige confiar. Cuando en una organización se han creado los procesos para controlar el trabajo, es difícil volver atrás. Pero no debe ser imposible. Por algo (Joel Spolsky, 2007), dice que hay que contratar a los mejores, pero únicamente a las personas en las que se esté convencido de que son las mejores:
“El principio es sencillo, se debe buscar gente que, uno sea inteligente y dos quieran hacer su trabajo eso es todo lo que se tiene que buscar”, Spolsky (2007)
Entonces se puede confiar en ellos. Sin duda no es un paso fácil en muchas organizaciones y menos en instituciones públicas, como en el caso del Servicio de Rentas Internas del Ecuador.
Existe personal con nombramiento definitivo que se les controla exageradamente. Pero entonces ¿por qué se les contrato? ¿se confiaba en ellos? O quizás se ha perdido la confianza a lo largo del proyecto. Entonces el problema no es controlarlas, si no volver a confiar en ellos, analizar qué se hizo mal.
A veces hay jefes de equipo que controlan al milímetro lo que hacen sus subordinados, cargándose un excesivo trabajo que no les corresponde, y siendo un cuello de botella en el proyecto.
Incluso cuando los funcionarios no se fían del trabajo de los demás, o lo desprecian si lo han hecho en otro equipo, se ponen zancadillas al buen desarrollo de los proyectos.
¿Se puede corregir esto con normas y procesos? Pues quizás a veces sí. Pero, si se quiere mover hacia las metodologías ágiles, porque se cree que pueden ser beneficiosas en un buen número de proyectos, centrándose más en las personas que en los procesos, el objetivo debe ser recuperar la confianza y evitar las carreras de desconfianza mostrado en la tabla 4.
Tabla 4 Barreras de desconfianza en proyectos de desarrollo de software
Fuente: Autor.
Podría decirse que la obra más conocida e influyente en materia del recurso humano de los departamentos de tecnología es el clásico libro de DeMarco y Lister (2002), Peopleware: Productive Projects and Teams. Está centrado principalmente en la gestión de proyectos pero también señala algunos tópicos como los conflictos entre la perspectiva del trabajo individual y la ideología corporativa, equipo compenetrado, relaciones de grupo, entropía organizacional, el discurrir del tiempo, vigilancia a los empleados ("teamicide") y la teoría del entorno de trabajo (para la optimización).
A continuación algunos puntos relevantes sobre el tema:
Los desarrolladores construyen componentes modulares, como por ejemplo rutinas de código; los módulos son construidos normalmente como "cajas negras" es decir al final del día lo que importa es que hagan lo que tiene que hacer, sin importar los detalles de cómo fueron hechos.
Los principales problemas del trabajo no son tanto tecnológicos sino más bien sociológicos por naturaleza. Muchos jefes y gerentes coincidirán con la idea de que tienen más preocupaciones en las personas que preocupaciones técnicas.
Ellos administran la tecnología como su principal preocupación. Parte de este fenómeno se le atribuye al ascenso o promoción de administradores
1.
Un jefe de proyectos debe ser paranoico respecto a los procesos (las cosas pueden fallar) pero confiadas con respecto a las personas(mi equipo saldra adelante), por degracia aveces ocurre lo contrario se desconfia de las personas pero se mantienen planificaciones irreales.
2.
Quienes saben como hacer las cosas son los miembros del equipo, el jefe de proyecto no debe repasar ni revisar lo que se hace a detalle, sin embargo hay jefes de proyectos que piensan que deberian clonarse a si mismo y reemplazar a su equipo de trabajo.
3. Pese a que en un proyecto el jefe puede estar en un determinado momento desanimado bajo ningun concepto esta animaversión debe ser trasladado a su equipo de trabajo.
4. El jefe de proyecto debe defender a su equipo de trabajo y filtrar los aspectos negativos y no hacer de mera correa de transmisión de la presión ocurrida desde arriba.
promedio (jefes promedio), ya que fueron educados en "como se hace el trabajo" y no en "como debe ser administrado el trabajo".
La razón principal de preocupase en los aspectos técnicos en vez de los humanos, no es porque éstos sean cruciales, simplemente es por son más fáciles de ejecutar. Instalar un nuevo disco duro en una máquina es algo trivial comparado con tratar de entender por qué un funcionario está enojado o por qué alguien no está contento con la organización. Las interacciones humanas son complicadas y nunca fáciles y limpias en sus efectos, pero estas importan más que cualquier otro aspecto del trabajo.
Para los trabajadores pensantes (es decir que analizan y no solo ejecutan), tener un error ocasional es una parte natural y saludable de su trabajo. Sin embargo, muchas veces se tiende a asociar un error, al equivalente de un pecado según la Biblia. Esta es una actitud que para poder cambiarla, es necesario padecer de algunos sufrimientos. Promulgar un ambiente en donde no se permiten los errores simplemente ocasiona que las personas actúen defensivamente. Ellos ya no probarían cosas que puedan terminar mal, simplemente dejarían de pensar y solo pasarían a ejecutar.
El principal enfoque en la administración de un proyecto debe ser hacia la dinámica del esfuerzo del desarrollo del mismo. El problema es que a menudo se evalúa el valor que aporta una persona a un nuevo proyecto en términos de características de estado estacional: ¿Cuánto código puede escribir? o ¿Cuánta documentación puede producir? Ponemos muy poca atención en que tan bien cada uno de ellos se desenvuelve aportando en los esfuerzos por obtener los resultados como conjunto. Alguien que pueda ayudar a unir un equipo en un proyecto vale dos personas que simplemente se dedican a hacer su trabajo.
La productividad busca esencialmente lograr más resultados en una hora de trabajo, sin embargo, a menudo se ha convertido en extraer lo más que se pueda de una hora de trabajo pagada, el error en el que incurren los gerentes para lograr niveles de productividad, es utilizar el mecanismo de
horas extras de trabajo no pagadas, dividen cualquier trabajo hecho, en una semana de cuarenta horas, no por las ochenta o noventa horas que el trabajador realmente la realizo.
Ellos buscan impresionar sobre la importancia de lo que la fecha de entrega significa (aun cuando esta ha sido definida arbitrariamente; el mundo no se va detener solo porque un proyecto es completado un mes después), persuaden a sus trabajadores en aceptar calendarios de trabajo sin sentido y esperanza, los humillan hasta sacrificar cualquier cosa para lograr la fecha de entrega y hacen todo lo posible por hacerlos trabajar más duro y por más tiempo.
Aunque sus colaboradores estén expuestos al mensaje "Trabaje más duro y por más tiempo" mientras están en la oficina, ellos están recibiendo un mensaje completamente diferente en casa. El mensaje en casa es, "La vida se te está pasando. Tu ropa sucia se está acumulando en el closet, tus niños no han recibido tus abrazos y tu esposa ya está comenzando a buscar otros rumbos. Solo existe una chispa de tiempo llamada vida, solo una oportunidad. Y tú utilizas tu vida en esa cosa llamada Inteligencia de Negocios...."
2.5 Data Warehouse Ágil
Un data warehouse exitoso, lo es por el mayor número de interacciones de la tecnología con el contexto social y corporativo lo que determina el éxito (que se use) o el fracaso (que no se use) de un data warehouse.
¿Esto recuerda al primer párrafo del Manifiesto Ágil? "En este trabajo valoramos al individuo y sus interacciones más que al proceso y las herramientas."
Siendo el corazón de las construcciones de la Inteligencia de Negocios, el data warehouse, a continuación se analizan 7 puntos que relacionan la intervención del usuario con el data warehouse, mostrados en la Figura 4.
Figura 4 Puntos de intervención Usuarios – Data Warehouse
Fuente: Autor
Los puntos de intervención 1 y 2 (Apoyo de los Usuarios) son de sentido común. Si no se tiene alguien que auspicie el proyecto desde la alta dirección o no se tiene a los usuarios a favor, difícilmente se tendrá éxito con una implementación de data warehouse o de cualquier iniciativa tecnológica. Son puntos de intervención que caen por su propio peso, pero a veces se olvidan. Un usuario boicoteador puede hacer muchísimo daño, mientras que un usuario involucrado en el proyecto desde el inicio difícilmente echará a perder su propio esfuerzo.
Sin embargo para el punto de intervención 3 (Qué tan amplia es la Información?) se da una nueva visión sobre si es bueno o no el uso de los data marts multidimensionales o si podemos aplicar un modelo de data warehouse más al estilo antiguo sin estructurar excesivamente el mismo.
La pregunta que se tiene que hacer es ¿se tiene un amplio abanico de información a la que acceder?, si la respuesta es sí y se ataca con un modelo multidimensional
1 y 2. Apoyo de los usuarios
3. Que tan amplia es la información
4. Herramientas de explotación reestrictivas o no
reestrictivas 5. Los usuarios
saben como utilizar la información
extraída 6. Relación usuarios
- TI es fluida
7. Power Users.
iremos directamente al fracaso. Si por el contrario no se tiene esta necesidad, entonces el modelo multidimensional es muy válido.
Referenciando nuevamente al décimo principio de las metodologías ágiles.
"X. La simplicidad es esencial. Se ha de saber minimizar el trabajo que NO se debe realizar."
El cuarto punto de intervención (Elegir Herramientas Restrictivas o No Restrictivas) se refiere a disyuntiva de los usuarios deben elegir herramientas restrictivas (es decir herramientas que limitan las opciones del usuario final) sin duda ayudará a reducir la complejidad y la ambigüedad semántica, pero limitan sus posibilidades.
Usar herramientas no restrictivas (es decir herramientas que dan una amplia gama de opciones al usuario) les permitirá acceder a información menos estructurada, pero son más complejas de usar.
Obviamente en la práctica aquellos usuarios que tenían un repositorio simple como data warehouse (sin data marts) y que habían tenido éxito optaren por herramientas no restrictivas, pues preferían invertir en aprender la complejidad de este tipo de herramientas antes que utilizar una más simplificada.
Las herramientas que simplifiquen la interacción también harán más sencillos los tipos de análisis que podamos hacer, perdiendo parte de esa capacidad en el camino. Si se limita a decir "no, mejor todas las posibilidades" entonces introducimos complejidad innecesaria, dificultamos el aprendizaje del data warehouse, e incentivamos a los usuarios a que busquen la información por otro lado.
No es lo mismo acceder a la información mediante informes realizados en herramientas específicas de Inteligencia de Negocios, diseñadas para el análisis y el reporting (Business Objects, Cognos, MicroStrategy, MIS, etc...), que hacerlo directamente con sentencias SQL. Seguro que con sentencias SQL podemos acceder a cualquier posibilidad que exista en el data warehouse, pero la complejidad de su uso quizá no merezca la pena.
Por lo tanto este equilibrio entre lo que se pierde en la capacidad de análisis y lo que se gana en sencillez es vital para el éxito del data warehouse.
Tomando en cuenta que los usuarios finales son generalmente bastante ambiguos siempre encontrarán la manera más sencilla y más cómoda para acceder a la información.
Desde el punto de vista de las metodologías ágiles, la utilización de una herramienta restrictiva es la más adecuada, ya que la famosa regla del 80-20 se cumple inexorablemente. Quizás se pueda dejar un 20% de análisis no típicos que al ser semi estructurado se pierde, pero el 80% restante se lo tendrá con solo el 20% de esfuerzo. ¿Merece la pena aplicar otro 80% de esfuerzo por esos análisis? Pues generalmente NO. Se piensa que uno de los principios básicos de las metodologías ágiles es potenciar la puesta en marcha rápida de todo aquello que sea útil desde la perspectiva de negocio, eliminando lo superfluo.
Si ya se tiene la información "semi estructurada" en un data mart, esa pérdida ya se la ha cometido con lo que el uso de la herramienta restrictiva apenas si portará simplificación del uso y reducción de la ambigüedad semántica (esto último se consigue al crear el data mart y luego ponerle una capa de abstracción o semántica o de metadatos con la herramienta de explotación del usuario que se escoja).
Por el contrario, si no se tiene la información "semi estructurada", es decir, si se tiene un repositorio simple, al introducir una herramienta restrictiva se está poniendo mucho en juego, se está perdiendo esa amplitud de análisis que precisamente habían llevado a elegir un repositorio simple.
Se podría pues deducir, que si se tiene un repositorio con información semi estructurada y se elige una herramienta no restrictiva, seguramente llegará el momento en que se debe completar esos "huecos" con información no estructurada, para permitir recuperar esa pérdida de capacidad de análisis.
El punto de Intervención 5 (Los usuarios saben cómo utilizar la información extraída) es asegurarse de que los usuarios finales saben cómo aplicar la información extraída del data warehouse a sus tareas diarias, y si no saben cómo les puede ayudar el data warehouse obviamente no lo utilizarán y el caerá en desuso y posteriormente en el olvido.
En esta línea no solo es necesario que los usuarios finales entiendan como aplicar la información a sus tareas diarias, sino que comprendan la globalidad del proceso
del negocio (del cual estas tareas forman parte), el objetivo del mismo y las perturbaciones a las que pueden ser sometidas, tanto internas como externas a la organización.
El punto de intervención 6 (la relación usuario – Tecnologías de Información es fluida) es asegurarse que la relación entre el departamento de sistemas de información y los usuarios finales es amigable. Si se encuentra con hermetismo por alguno de los dos lados, seguramente la implantación será un fracaso, es mejor retrasarla hasta propiciar un entorno colaborativo.
Este punto es plenamente coincidente con las metodologías ágiles en los que los usuarios finales forman parte del equipo del proyecto, participando en las reuniones periódicas, aportando ideas, añadiendo o eliminando funcionalidades, pero como uno más, no como el usuario al que se le pregunta cuando se tienen dudas y que lo que él diga luego servirá de excusa o de salvoconducto.
El punto de Intervención 7 (Power User) es asegurarse que entre los usuarios finales va a haber uno que conozca muy bien tanto las capacidades del data warehouse como el uso de las herramientas de explotación, lo que los autores llaman el "Power User". Si se quiere tener éxito en el uso continuo y a largo plazo del data warehouse es necesaria una persona de negocio que explore todas las posibilidades y que ayude e incentive al resto de compañeros. No hay nada como un usuario que consigue maravillas con el data warehouse para que los demás imiten su camino.
Si este perfil no existe hay que crearlo, en una metodología ágil ese usuario ya se crea durante el proyecto, ya que forma parte del equipo.
2.5.1 El Departamento de Tecnología de la Información y el Negocio:
Alineación o amistad
Del artículo titulado "4 Steps to Create an Effective IT and Business Partnership", (Villar & Kushner, 2009), se propone una innovadora idea que parte del hecho de olvidarse del término alineación de Tecnología de la Información con el negocio, nada de alinearse, lo mejor es ser amigos de los usuarios de negocio, comprenderles y formar un equipo. Muchas veces se ha hablado de la Inteligencia de Negocios como un vehículo catalizador que reducirá el gap Tecnología/Negocio
pero el planteamiento de Villar y Kushner (2009), es totalmente diferente al propuesto tradicionalmente.
Parten de la siguiente premisa: La identificación y definición de los datos críticos de negocio requiere de una fuerte alianza entre el negocio y los departamentos de Sistemas. Hay por tanto que establecer una relación de éxito entre ambas partes.
Son 4 los pasos que hay que seguir para conseguirlo:
1. Conocerse mutuamente.
2. Desarrollar una relación.
3. Definir roles y responsabilidades.
4. Establecer comunicación, real, abierta y sincera.
Principalmente en los pasos anteriores, como hilo conductor se menciona la gestión y la calidad del dato, pero es perfectamente extrapolable a la gestión de indicadores analíticos. A la hora de establecer comunicación de forma abierta con los usuarios de negocio, considerar los siguientes puntos:
Soñando el mismo sueño; todos deben tener los mismos objetivos, remar en la misma dirección.
Eliminando las capas de interferencia; muchas veces se ponen "personas intermedias" que trasladan las necesidades de negocio al personal de Sistemas.
Esto hay que eliminarlo, se necesita un contacto directo para que ambos mundos se pongan a trabajar como socios e incentivar el contacto entre ellos, hacer sesiones de "un día en la vida del comercial" o "un día en la vida del analista de Inteligencia de Negocios" para que se vea lo difícil que es vender y que ellos vean lo difícil que es transformar datos en información y en indicadores.
Este enfoque que se le da a la alineación está muy en línea con las metodologías ágiles y la vuelta a la confianza en las personas para llevar al éxito a las organizaciones.
2.5.2 Información Institucional
Resulta necesario exponer una perspectiva más amplia del usuario de información, empezando por definir más claramente qué se entiende por información, en tanto
