La Metodología TopToTop: App’s Smart Development

¿No habéis tenido la sensación cuando diseñabais un sistema de BI de que el transaccional estaba mal o incompleto? Una de las sensaciones más frustrantes al hacer proyectos de BI deriva de los problemas existentes con la información transaccional, básicamente por:

  • Está mal, es incoherente, no cuadra, no tiene sentido….
  • Está incompleta, no tiene las características que necesitaríamos para analizarla….
  • No contempla todos los casos que se nos dan actualmente….
  • Está estructurada de manera anárquica para poderla analizar, o hacerlo es terriblemente complicado y costoso

¿Y cuando habéis puesto en marcha un sistema transaccional, no os ha ocurrido que al finalizar os pedían que diese información de una manera no prevista, para unos casos no contemplados, en unas circunstancias operativas diferentes y para unos interlocutores distintos y con unas necesidades diferentes a las contempladas?

¡A mi me lleva pasando toda la vida! La parte más frustrante del desarrollo es que nunca conseguía cerrar el circulo y tener un sistema que cumpliese las expectativas finales de gestión. He probado diferentes metodologías, y formas de hacer proyectos transaccionales y de BI, pero siempre llegaba al mismo punto: había elementos que deberían estar y que no estaban y que no eran responsabilidad del sistema en el que estaba trabajando sino de otro de los sistemas implicados; es decir, mi sistema estaba bien, pero había piezas que debían estar pero no estaban…, o no estaban como deberían.

Hasta hace unos tres años, casi había asumido esta situación como ineludible y uno de los costes de desarrollar en cualquier ámbito. Pero entonces sucedió un hecho que quiero contaros aquí, y cómo ha afectado a todos los desarrollos posteriores que he realizado:

¡Apareció en el mercado eBavel de BITAM!

¿Qué es eBavel?: Una plataforma de desarrollo de aplicaciones web, que permite desarrollar sin código aplicaciones en entorno web para la captura de información, la implementación de WorkFlows (flujos de trabajo) y la generación automática de los modelos multidimensionales necesarios para Business Intelligence. Si, lo habéis leído bien: haces una aplicación de captura de información y la misma plataforma te genera la metadata y los modelos multidimensionales…, sólo necesitas dibujar los informes y los Dashboard y empezar a trabajar con la información que se vaya generando, sin cargas ni validaciones ni problemas de ningún tipo.

¿Y por qué he tardado 3 años en contároslo? Pues muy sencillo: llevamos esos tres años haciendo multitud de proyectos con las dos plataformas (eBavel para el desarrollo de aplicaciones y KPIonline para la parte BI), y desarrollando una metodología que nos permita aprovechar la potencialidad conjunta de estas dos plataformas de BITAM:

  • eBavel.- para el desarrollo de aplicaciones web
  • KPIOnline.- para el sistema BI asociado

En este post quiero contaros las líneas generales de esta metodología, que hemos denominado TopToTop o de “desarrollo inteligente” o ASD Methodology.

ASD Methodology

ASD Methodology

Aunque esta Metodología se ha desarrollado a partir de una plataforma tecnológica como es la de BITAM, la metodología es independiente de la tecnología, siempre y cuando la tecnología aplicada cumpla con lo que contamos a continuación. Por ello, si encontraseis en el mercado otra tecnología equivalente (que hoy por hoy, yo no conozco), os animo a que probéis la metodología TopToTop

La Metodología TopToTop: App’s Smart Development Methodology

Vamos a intentar sintetizar en este post los elementos básicos de la metodología que iremos desarrollando en otros posteriores:

¿Qué es la Metodología TopToTop?

La ASD Methodology o Metodología TopToTop es un planteamiento que rompe la barrera existente entre las aplicaciones transaccionales y las de gestión, unificándolas en un único elemento que gestiona cada una de ellas en si misma y en relación con la otra.

Hasta ahora, el desarrollo de una aplicación siempre se hacía poniéndole un apellido de entrada: o era una aplicación transaccional (ERP, CRM…..) o era un sistema BI (BSC/BI/Reporting….) y, en el mejor de los casos, se buscaba como se podía conseguir que determinados aspectos de la otra “pata” estuviesen cubiertos. Por ejemplo. se hacía un ERP y se le incrustaba una herramienta de informes, para que la parte de gestión estuviese cubierta. El resultado de ello es que el ERP podía ser fantástico, pero siempre, la parte de gestión y el soporte para la toma de decisiones era un parche insuficiente e irrelevante.

Cambio en las Metodologías de Desarrollo de Aplicaciones

Desarrollo Tradicional vs. Desarrollo ASD

Ante ello, la ASD lo que plantea es que debe definirse cómo se debe gestionar la Organización, qué procesos es necesario contemplar y para qué y a partir de ahí comenzar con el desarrollo.

Probablemente me diréis que eso está muy bien, pero que luego a la hora de la verdad, la barrera entre las aplicaciones de gestión y las aplicaciones transaccionales es, técnicamente infranqueable. Cierto…., hasta ahora: la doble plataforma de BITAM (que supongo que marcará el camino de evolución de este tipo de tecnologías) permite integrar dos plataformas de desarrollo con dos ejes fundamentales:

  • Cada plataforma es independiente y se ha diseñado con las funcionalidades que ese tipo de producto precisa (me remito a las encuestas de satisfacción de usuarios BI de Gartner para que se vea que no hablamos de productos de segunda sino de uno de los mejores productos de BI del mercado mundial: Las 13 Soluciones BI más importantes del mercado, frente a frente) y os animo a que probéis la plataforma de desarrollo de aplicaciones eBavel, que aunque mucho más joven en el mercado, está teniendo un nivel de aceptación muy elevado

Este aspecto es básico: no se trata de tener un mal producto para decir que desarrollamos una de las partes del sistema, cuando realmente nuestro foco está en la otra parte -que es lo que tradicionalmente se ha venido haciendo cuando se colocaba un producto complementario para decir que si se cubría la otra parte, como en el caso de los ERPs con un generador de informes acoplado)

  • Cada plataforma se ha diseñado pensando desde el principio en que debe integrarse de manera natural con la otra; es decir, no hemos hecho una herramienta de desarrollo y al final nos hemos puesto a pensar en como conseguimos integrar otro producto (porque así es imposible que lo que salga funcione), sino que se han concebido las herramientas informáticas desde una base filosófica y conceptual única:
    • La herramienta de desarrollo de aplicaciones genera unas estructuras de datos pensadas para poder ser tratadas con herramientas de BI
    • La herramienta de BI está diseñada para tratar los datos existentes, de manera natural.

Es decir, aunque la metodología no tiene nada que ver con la herramienta utilizada para el desarrollo, si requiere que la plataforma utilizada sea capaz de hacer determinadas cosas: no vale cualquier herramienta para desarrollar con la Metodología ASD.

Resumiendo, la ASD Methodology se basa en 2 pilares:

  1. Integra la parte de gestión y la toma de decisiones con la parte operativa, tratándola como un único cuerpo conceptual
  2. Utiliza tecnologías de nueva generación concebidas para integrar ambos aspectos.

Principios Básicos de la Metodología TopToTop:

  1. Principio de Integridad.- Todo sistema debe integrar tanto la parte operativa como la de gestión; los sistemas sirven para gestionar nuestra organización: no tiene sentido, por tanto, que un sistema informático sólo satisfaga una parte de las necesidades. Los sistemas informáticos deben automatizar nuestras operaciones pero sobre todo, deben permitirnos mejorar nuestra forma de tomar decisiones, que es lo que nos diferencia de la competencia y lo que aporta valor.

    Principios ASD

    Principios de la Metodología TopToTop

  2. Principio TopToTop.- El diseño de un sistema empieza por la Necesidad a Gestionar; se sigue diseñando el Sistema Transaccional y se termina otra vez con la Necesidad a Gestionar.
  3. Principio de Transversalidad.- Todo el desarrollo debe tener una línea conductora que enhebre la totalidad del sistema, y dicha línea conductora es conceptual y debe reflejar el concepto de negocio de la Organización. Es lo que nos va a definir la Organización y lo que la diferenciará de la competencia.
  4. Principio de Priorización.- Debemos categorizar nuestras necesidades y actuar en base a dicha ordenación a lo largo de todo el desarrollo. Si hemos establecido que una necesidad es superior a otra, no podemos poner en cuestión la primera porque tengamos problemas con la segunda: es necesario buscar alternativas que no alteren el orden de nuestras necesidades
  5. Principio de Capas.- Construiremos nuestro sistema de dentro a fuera: partiremos de los elementos esenciales y, una vez definidos éstos y teniéndolos permanentemente presentes, desarrollaremos el resto. Para los que me seguís habitualmente no creo que os sorprenda si os digo que la capa más interior es la capa de gestión y la externa la transaccional, pero dentro de esto hay muchos matices que desarrollaremos en otros post.
  6. Principio de Continuidad.- El desarrollo de una Aplicación de Gestión es parte de la Gestión de la Organización y no finaliza cuando termina el desarrollo técnico de la App: es en ese momento cuando hay que empezar a gestionar con ella, modificando nuestra forma de gestionar y de manera iterativa, modificando nuestro sistema para incrementar el valor de nuestras decisiones.

En próximos post entraremos en las fases de la Metodología, las barreras existentes y la forma de abordar proyectos de esta manera. Os invito a suscribiros al Blog para que os llegue la notificación automática cuando se encuentren disponibles.

Publicado en BI, Metodología BI, Metodología Business Intelligence, Metodologia Desarrollo de Aplicaciones, Teccnologia, Tecnología para la Toma de Decisiones, Uncategorized | Etiquetado , , , | Deja un comentario

Los 5 errores más comunes en un proyecto de BI; no te olvides del quinto

Por qué fracasan los proyectos de BI?

¿Piensas que un proyecto de BI es esencialmente igual que cualquier otro proyecto de tecnología? Si es así, probablemente hayas fracasado a la hora de conseguir implantar un proyecto de BI en tu Organización pues, aunque tiene algunos elementos comunes a todo proyecto, ¡tiene aspectos muy diferenciales y críticos!

Como siempre que hablamos en este blog de BI, nos estamos refiriendo a auténticos sistemas de toma de decisiones, no a meras herramientas de reporting, sean éstas gráficas o no. Implantar un sistema de reporting tendrá muchos elementos en común con cualquier otro proyecto tecnológico, pero no es esto de lo estamos hablando.

¿Qué ocurre cuando necesitamos modificar nuestro sistema de toma de decisiones, apoyándonos en la tecnología, para generar más valor en nuestra Organización? Si no somos conscientes de las diferencias y las barreras existentes, incurriremos en una serie de errores que, con total seguridad, darán al traste nuestro objetivo

Primer Error en un Proyecto de BI: Ignorar cual es TU Necesidad

¿Alguna vez te has sentado a analizar la forma en la que se toman las decisiones en tu Organización? ¿Has analizado quien toma las decisiones y cómo lo hace? Si la respuesta es afirmativa, ¡enhorabuena, eres la excepción!

Cuando estamos en cualquier tipo de organización y alguien nos llega con un proyecto de BI, nos suele traer argumentos del tipo “mira qué fácil es organizar la información”, “mira qué bien salen las gráficas y qué claras están”, “fíjate qué sencillo es extraer datos de tus sistemas”, etc. Te intentan encandilar con el resultado visible y la sencillez técnica, pero nadie entra a cuestionar cómo se toman las decisiones en tu Organización y si una herramienta tecnológica te ayudará a mejorar la forma de tomar las decisiones.

Errores en un Proyecto de BI: error nº 1

Error nº1: Empezar un Proyecto de BI sin analizar la Necesidad

Un ejemplo: organización muy jerarquizada en la que la decisión final siempre recae en la cúpula; ¿de qué me sirve el mejor BI si éste no va a ser usado por los gestores que tienen la ultima palabra? Podremos empeñarnos en ponerlo en marcha, pero a la hora de la verdad, nuestra toma de decisiones no habrá cambiado nada ni generará más valor.

Por consiguiente, antes de embarcarte en un proyecto de BI, analiza si tu problema se soluciona con una herramienta tecnológica y, si no es así, empieza por donde debes, es decir, por tu proceso lógico de toma de decisiones y, más adelante, podrás plantearte la parte tecnológica.

Segundo Error en un Proyecto de BI: creer que es un Proyecto de Tecnología

Si eres un gestor de negocio, probablemente pienses que como esto del BI es un tema en el que hay involucrada tecnología pues que debe ser el Departamento de Sistemas/TI el que se encargue de él.

Pero, por desgracia, normalmente el área de TI se dedica a hacer lo que otros le dicen que debe hacerse, pero no a decidir cómo deben funcionar las cosas dentro de la Organización: ¡eso lo hacen los gestores de negocio! Sin embargo, cuando arrancamos con un proyecto de BI directamente asumimos que debe ser tecnología quien lo lidere.

¿Por qué es distinto de, por ejemplo, un proyecto de implantación de un ERP? Cuando lanzamos un proyecto normal de implantación de cualquier sistema, estamos automatizando algo que ya se estaba haciendo, pero de otra forma; introducimos cambios en la forma de operar para adaptarnos a la nueva herramienta pero, básicamente, seguimos haciendo lo mismo. ¡No pretendemos cambiar la forma de trabajar! En estas circunstancias, el área de sistemas puede ser un razonable gestor e impulsor de la implantación, puesto que está sustituyendo una herramienta por otra o está mecanizando algo que antes no lo estaba.

Sin embargo, un Proyecto de BI es, esencialmente, un proyecto que cambia la manera de tomar decisiones de nuestra Organización y esto no es un mero tema técnico sino estratégico y de concepción de nuestro negocio. No podemos esperar que el Área Tecnológica lidere el proyecto ni que adopte las mejores decisiones, simplemente porque es un tema tecnológico.

¡Y aún mayor error si piensas que el Área de Tecnología lo va a apoyar! Eso, sin contar con que nuestro Área de Sistemas no le haga “la cama” a nuestro proyecto, dado que va a limitar “su poder” dentro de la Organización. Para no repetir aspectos ya vistos, en la entrada “Elementos de un Proyecto BI: las Piezas” podéis ver la importancia del Área de Tecnología en el éxito de un proyecto de BI y por qué debemos tener claro su papel en un proyecto que afecte a la Toma de Decisiones.

Tercer Error en un Proyecto de BI: no definir los objetivos reales

¿Para qué estamos implantando un sistema de BI? Hemos dicho que para mejorar nuestro proceso de toma de decisiones, para generar más valor…., ¡pues definamos unos objetivos del proyecto que tengan que ver con estos aspectos!

¿Cómo se miden los proyectos de tecnología normalmente? Se controlan plazos y costes y, en el mejor de los casos, se analiza el cumplimiento de los requerimientos funcionales de los usuarios; es decir, se miden si los elementos operativos se han cubierto de acuerdo con la planificación, pero, ¿de qué me sirve esto para ver si ha mejorado mi toma de decisiones?

Segundo error en Proyectos BI

Segundo error: Considerar el Proyecto BI sólo como un Proyecto Tecnológico

Insistimos, un proyecto de BI no es un proyecto de tecnología y, por consiguiente, no se puede concebir, analizar ni valorar de acuerdo con los parámetros de los proyectos de tecnología.

El resultado normal de considerar un proyecto de BI únicamente como un proyecto tecnológico es, indefectiblemente, terminar teniendo un sistema informático que no sirve para mejorar el valor aportado por nuestra empresa u organización; es decir un sistema que no sirve para lo que lo habíamos definido.

Cuarto Error en un Proyecto de BI: creer que el Proyecto termina cuando lo implantamos

Como todos los proyectos de TI, una vez implantados hay que perseguir que se use correctamente, verificar que no haya casos de uso que se escapen del proceso, montar una mecánica de realimentación que permita determinar los siguientes pasos, etc….; pero en el caso de los proyectos de BI lo fundamental no es esto sino

conseguir que se produzca un cambio en la forma de tomar las decisiones y que dicho cambio GENERE VALOR nuevo

Me da lo mismo que hayamos generado un BI eficiente,  ágil, fácil de usar, agradable al usuario…., y todo lo que queramos: si el sistema no supone que mejora nuestra forma de tomar decisiones y esto se traduce en que hacemos mejor las cosas y lo podemos medir, no nos sirve de nada; tendremos un sistema tecnológicamente magnifico, que nos permitirá apuntarnos medallas con aquellos a los que se los enseñemos y que

nos habrá costado muchísimo, pero no valdrá nada

Por tanto, una vez que hayamos implantado técnicamente el Sistema de BI, hay que poner en marcha toda la fase de implantación del Sistema de Toma de Decisiones; la primera fase afecta a nuestra plataforma de BI (Bitam, QlickView, Oracle…., o la que queramos); la segunda atañe a cómo hacemos el proceso de toma de decisiones y por tanto a todos los aspectos del mismo, que en otros post hemos visto (por ejemplo en la Metodología para el Diseño e Implantación de un Sistema de BI)

Quinto Error en un Proyecto de BI: no medir

Este es el error en el que todos caemos: en el mejor de los casos definimos bien la necesidad, planteamos el proyecto no solo en su faceta técnica sino como un cambio en el proceso de toma de decisiones, montamos una sistemática de supervisión y seguimiento una vez implantado el sistema para asegurarnos que se usa (controlamos los accesos e incluso los tiempos de conexión)…., ¡y lo dejamos ahí!: ya hemos cumplido y el sistema está implantado

Pero nos hemos vuelto a olvidar de PARA QUÉ LO HEMOS IMPLANTADO. ¿No hemos dicho que era para mejorar mi proceso de toma de decisiones y para que nuestras decisiones generasen más valor a la Organización? Pues

tendremos que medir cómo las nuevas decisiones aportan valor a la organización

Dependiendo del alcance del sistema deberemos definir unas métricas lógicas que nos permitan evaluar cuanto ha mejorado nuestro Proceso de Toma de Decisiones. Dependiendo del caso tendremos que determinar como han variado:

  • Los tiempos
  • El número de eventos
  • La frecuencia de los mismos
  • Su tipología
  • ….

Vamos a poner un ejemplo: tenemos un problema en comercial porque nuestros clientes, con los que interactúan nuestros comerciales en su casa, consumen pocos de nuestros artículos y no siempre los más rentables. Ante eso montamos un sistema que permita conocer qué consumen los clientes, cruzando por diferentes dimensiones, tanto de nuestros artículos como de nuestros clientes, de forma tal que cuando un comercial está ante el cliente, pueda saber qué ha consumido ese cliente, qué han consumido clientes parecidos, cuando lo han hecho, qué ventajas les suponen esos nuevos artículos…..Pues bien, cuando nos lancemos a implantar un sistema de BI deberemos tener permanentemente presente que ése era el motivo de implantar el sistema y, por tanto, una vez implantado deberemos comprobar que nuestros indicadores han mejorado. Deberemos medir y ver como evolucionan y si su comportamiento no es el esperado, deberemos volver a analizar el proceso de toma de decisiones en cada uno de sus puntos para ver donde hemos fallado.

La medición en ProyectosBI

Quinto error en un Proyecto BI: No Medir

Y esto deberíamos tenerlo definido desde el minuto 1 del Proyecto. ¡Esto es lo que debería justificarnos la inversión en un sistema de BI !

Por tanto, definamos la necesidad y establezcamos cómo vamos a medirla; establezcamos los KPI’s y sus valores objetivos y chequeemos permanentemente que el sistema implantado sirve para lo que queríamos…, y si nuestros indicadores no están mejorando, replanteémonos todo el sistema -aunque si has seguido los diferentes consejos que aparecen en este blog, te puedo asegurar que eso no te ocurrirá-

Resumiendo: analiza tu necesidad; define tus objetivos y cómo vas a medirlos; controla tu proyecto no solo -ni fundamentalmente-, como un proyecto de tecnología; no delegues en el Área Tecnológica para hacerlo; y, una vez implantado, persigue que se use para tomar decisiones y mide…., mide……, y vuelve a medir…., y si no da los valores esperados, revisa todo el proceso.

Publicado en BI, Business Intelligence, Errores en la Toma de Decisiones, Implantación BI, Implantación de un Sistema de BI, Metodología BI, Metodología Business Intelligence, Toma de Decisiones | Etiquetado , , | Deja un comentario

Elementos de un Proyecto de BI (IV): el Tablero

Analizar y entender cómo es el Tablero en el que vamos a desarrollar nuestra partida es un aspecto fundamental para enfocar adecuadamente nuestro proyecto de BI; nos referimos a la tecnología que va a soportar nuestro proyecto y aquella con la cual debe relacionarse, es decir, la parte externa y la interna.

EL TABLERO EXTERNO EN UN PROYECTO DE BI

¿A qué llamamos Tablero Externo?: el Tablero Externo es el soporte tecnológico en el que vamos a basar nuestro BI, es decir, qué características tiene nuestro software, qué requerimientos tiene, qué bases de datos soporta como fuentes y sobre cuales podemos instalarlo -y si son propietarias o no-, que tipo de accesos soporta, cómo se gestiona, como se configura, cómo son los upgrades…, en definitiva, todo aquello que hace que nuestro software de BI sea compatible, fácil de usar, de mantener y de compaginar con nuestras fuentes de información actuales.

Esto, que hace 3 o 4 años era fundamental, hoy ha perdido relevancia: la tecnología cloud aplicada al BI ha eliminado todos los condicionantes existentes: ya no dependo de mis estructuras físicas, de mis equipos ni de mis bases de datos, no necesito tener expertos en comunicaciones ni en una base de datos concreta, o los requerimientos que tengo son mínimos; no tengo que preocuparme de las copias de seguridad ni de la conectividad de mi personal, no tengo que estar optimizando mi base de datos….; de todo eso y más se ocupa/preocupa el Sistema de BI en Cloud. Sólo necesito un Sistema de BI con capacidades de conectividad suficientes para interactuar con mis sistemas operacionales, extrayendo información y, en su caso, volcando información una vez procesada.

Tecnología Interna vs. Externa en un Proyecto de BI

EL TABLERO INTERNO EN UN PROYECTO DE BI:

El Tablero Interno es la capa lógica que interrelaciona el BI con el resto de sistemas  de nuestra Organización; nótese el adjetivo “lógica”: no hablamos de conectividad física entre sistemas (que pertenecería al tablero externo) sino de la conectividad lógica, es decir, de donde tomamos los datos y, en su caso, aunque es más excepcional, a donde volcamos los datos procesados por nuestro sistema de BI. Este aspecto es hoy el más relevante y a él vamos a dedicar el resto del artículo.

Uno de los problemas cuando diseñamos un sistema de BI es que partimos de la información existente en la Organización: analizamos nuestras necesidades a partir de la información que tenemos, definimos nuestras necesidades a partir de los datos existentes y establecemos nuestra forma de gestionar a partir de cómo lo hacemos actualmente…., y eso suele dar lugar a sistemas poco adaptados a nuestra necesidad actual; ¿quien no se ha encontrado a la hora de diseñar un sistema con que el diseño inicialmente deseado no es abordable porque no existe la información que necesitaríamos o cómo la necesitaríamos?; ello nos obliga, en el mejor de los casos, a crear complejos mecanismos de transformación de la información (que en muchas ocasiones mueren por su propia inercia), pero casi siempre, el resultado es que abandonemos los objetivos iniciales, restringiéndolos a lo posible.

Y esto, ¿por qué ocurre así? La respuesta es sencilla: cuando diseñamos e implementamos nuestros sistemas transaccionales no tenemos en cuenta las necesidades de gestión; sólo nos preocupamos de los procesos operativos, de cómo capturar la información y, en su caso de los work flows necesarios: definimos como realizar el proceso de compras (quien, cuando y cómo debe hacerlo, quien debe validarlo, aprobarlo….), pero no analizamos qué es lo importante a la hora de comprar, qué valor añadido me debe aportar la compra, cómo mejora mi ventaja competitiva, qué debo analizar en cada compra y en el proceso en general….Y como no lo analizamos ni consideramos, montamos los procesos sin considerar otros parámetros distintos de los puramente operativos. Por consiguiente, cuando vamos a montar un sistema de toma de decisiones, no disponemos de la información que necesitaríamos ni como la necesitaríamos!

En el siguiente post desarrollaremos la Metodología TopToTop  de desarrollo inteligente de aplicaciones de gestión, pero ahora vamos a plantearnos qué hacer si ya tenemos nuestras aplicaciones operacionales y éstas no cubren nuestras necesidades de gestión.

Si ya estamos ante una situación como la descrita, deberemos plantearnos frontalmente si nuestra mejor opción es renunciar a lo que necesitamos (creando un símil de sistema de toma de decisiones que aporte un valor limitado a nuestra Organización),  o si debemos plantearnos la modificación de nuestras aplicaciones transaccionales para adaptarlas a nuestras necesidades de gestión (con las dificultades que ello conlleva).

En el caso de decidir modificar nuestras aplicaciones transaccionales, yo os recomiendo que utilicéis las técnicas darwinianas de selección natural a la evolución de vuestras aplicaciones. ¿En qué consisten dichas técnicas? Muy sencillo: en analizar qué cambios producen el mayor beneficio y van a permitir la supervivencia de nuestros sistemas…., con el menor coste posible. Es sencillo, ¿verdad?

Por si os ha surgido alguna duda de en qué consiste esta técnica, vamos a desarrollar un poquito en que consisten estas técnicas, aplicadas a la evolución de nuestros sistemas:

  • Objetivo fundamental: conseguir la supervivencia de nuestra aplicación.  Partimos de que el origen de los cambios necesarios es la falta de adaptación a las necesidades derivadas de la toma de decisiones. Olvidémonos, por tanto, de la aplicación transaccional y pensemos qué elementos son fundamentales para nuestra toma de decisiones; analicemos qué información es imprescindible y no tenemos; por cual otra podríamos sustituirla y con qué condicionantes; qué estamos dispuestos a sacrificar y a qué no podemos renunciar.

Definir lo importante, desde el punto de vista de gestión, implica desprendernos de las ataduras propias de nuestra aplicación actual (plataforma, funcionalidades, entorno tecnológico…) y pensar de manera finalista: cómo debería funcionar mi aplicación y para qué. Esto, que puede resultar obvio, es lo que nunca se hace: el proceso normal es que ante una necesidad no cubierta se someta al área de tecnología para que ésta determine qué se puede hacer y qué no….., y el resultado es, normalmente, que ¡no se puede hacer!

En cambio, nuestro planteamiento es distinto: establezcamos qué necesitamos, prioricemos lo imprescindible y lo conveniente, y cuando lo tengamos claro, pasemos al siguiente punto. Esto es lo único que nos va a permitir garantizar la supervivencia de nuestra aplicación transaccional: si nos sirve para gestionar los procesos, pero no para gestionar la Organización, no nos permitirá generar valor y, por consiguiente, terminará generando un divorcio entre el plano de gestión y el operativo y, aunque a corto plazo, gane el corto plazo, a la larga, ninguna Organización puede pervivir si no se diferencia por la forma de gestionar.

  • Una vez que tengamos priorizadas las necesidades, es el momento de analizar el coste que supondría implementar en nuestra aplicación transaccional los cambios definidos. Y no hablamos sólo de costes económicos; debemos considerar, al menos los siguientes costes:
    • Costes funcionales.- incorporar lo nuevo supone renunciar a algo? qué coste tienen dichas renuncias? pueden ser sustituidas por otras cosas? En ese caso, cual es el coste de los cambios adicionales de sustitución?
    • Costes organizativos.- qué suponen los cambios en los procesos para nuestra organización; a qué unidades les afecta; cómo vamos a abordar esos cambios; qué aspectos pone en riesgo y qué pérdidas pueden suponer
    • Costes de transición.- qué implica cambiar  nuestra aplicación transaccional? afecta a nuestros procesos actuales? necesitaremos habilitar procesos especiales en la fase de cambio?
    • Costes tecnológicos.- debemos incorporar nuevas tecnologías? tenemos los recursos para hacerlo? sabemos como operar con las nuevas cosas? acepta nuestra organización ese tipo de cambios?
    • Costes de Riesgo.- qué riesgos corremos acometiendo ese cambio? qué se puede torcer? qué pasa si no conseguimos llegar al objetivo marcado?
    • Y, por supuesto, los costes económicos del cambio.- cuanto nos cuesta? qué plazos son factibles y razonables?

Una vez que tengamos definidos nuestros costes -al menos de estos 6 tipos-, deberemos dimensionar nuestros costes globales de forma tal que podamos asignar un valor de coste a cada una de las necesidades (dependiendo de la Organización, deberemos asignar un mayor peso a unos u otros costes); ello nos permitirá obtener un valor de coste global de cada necesidad.

  • Finalmente, deberemos calcular los tiempos necesarios para cada uno de los cambios analizados.

El resultado de todo lo anterior podríamos visualizarlo en la Matriz de Supervivencia de nuestra aplicación:

Matriz de Supervivencia.- Cambios en las Aplicaciones Transaccionales

Tal y como se muestra en la imagen, plazo y coste forman los ejes básicos, figurando las funcionalidades nuevas analizadas en las burbujas, por el valor aportado a la organización (tamaño de la burbuja) y por su color (escala de valor de rojo a amarillo, siendo rojo “imprescindible” y amarillo “poco necesaria”).

Un arco de eje a eje permite marcar, de manera sencilla e intuitiva, las necesidades más prioritarias, realizables en condiciones aceptables. La elección y priorización dentro de dicho rango vendrá dada por el color (que nos marcará si se trata de una necesidad imprescindible para gestionar o simplemente conveniente) y por su tamaño (que nos dimensionará el valor que tiene para la organización).

En el ejemplo de la gráfica, se puede observar cómo algunas funcionalidades aparecen en rojo (o cerca del rojo), lo que significa que son imprescindibles para gestionar, pero, sin embargo, el coste o el plazo excede de los límites establecidos. Esta situación obligará a replantear el modelo de gestión o a ir a una nueva aplicación transaccional.

Resumiendo: cuando abordemos un proyecto de BI deberemos analizar cual es nuestro entorno tecnológico: el Tablero Externo, es decir la tecnología inherente a nuestro sistema de BI y el Tablero Interno, esto es, el encaje funcional de nuestras necesidades para la toma de decisiones con nuestros sistemas transaccionales. Y si no encajan, deberemos replantearnos modificaciones de los transaccionales o su sustitución completa.

Publicado en Barreras a la utilización de la tecnologia de BI, BI, Business Intelligence, Gestión, Implantación BI, Implantación de un Sistema de BI, Metodología BI, Metodología Business Intelligence, Tecnología para la Toma de Decisiones, Uncategorized | Etiquetado , , , , , , , | Deja un comentario

Elementos de un Proyecto de BI (III): las Piezas

Tras un largo paréntesis, retomamos la serie sobre los elementos fundamentales a tener en cuenta para garantizar el éxito de un proyecto de BI, hablando de otro aspecto básico: los recursos involucrados en la implantación de un proyecto de Business Intelligence, es decir, las piezas y el tablero con los que vamos a “jugar” nuestra partida.

Todo el análisis que hagamos sobre los recursos involucrados debe pasar necesariamente por una reflexión inicial: ¿cuál es la importancia de disponer de un sistema de BI para nuestra Organización? Estaremos de acuerdo en que los recursos asignados serán acordes con la importancia que demos al proyecto: si para nuestra Organización el Proyecto de Implantación de un Sistema de BI es residual…, asignaremos recursos y prioridades de manera tal que solo cuando no tengamos otro destino de nuestros recursos, los dediquemos al proyecto de BI; por el contrario, si la organización ha asumido la importancia del proyecto, la gestión de los recursos será favorable al proyecto de implantación.

Esto quiere decir, al igual que cuando hablábamos de otros temas, que los recursos implicados dependerán de nuestro enfoque de Proyecto…., y eso no es bueno ni malo…, siempre que seamos conscientes de la situación.

Dicho esto, y sobre la base de que los recursos deberán adaptarse al tipo de proyecto de BI y a la importancia del mismo para nuestra Organización, vamos a analizar el tipo de recursos y sus características cuando el BI del que hablamos se sitúa en el rango más alto: un sistema de BI orientado a la toma de decisiones y al control de las mismas.

La realización de un Proyecto de BI es como una partida de ajedrez: existen numerosas piezas, cada una de las cuales pueden interactuar de maneras diferentes y contribuir o frenar la consecución de nuestros objetivos. Al menos existen seis roles diferentes cuando abordamos un proyecto de BI, y todos ellos son fundamentales y de su nivel de implicación en cada fase del proyecto, dependerá el éxito del mismo

  • El Rey

    Las Piezas y el Tablero en un Proyecto de BI

  • La Reina
  • Las Torres
  • Los Alfiles
  • Los Caballos
  • Los Peones

Y ya que hemos dicho que pueden jugar a favor o en contra del proyecto, hablaremos de que hay piezas blancas y negras

Antes de comenzar a describir nuestras piezas, resaltar que existe una gran diferencia con el juego de ajedrez: en éste, el objetivo es acabar con el rey contrario; en nuestros proyectos el objetivo final será convertir a las piezas negras (opositores) en piezas blancas que jueguen a favor del proyecto.

El REY:

El Rey es la pieza sin la cual se termina la partida; sin él, nada de lo que hagamos tiene sentido, pues es el destinatario final de todo el juego. Es una pieza con poca movilidad, pero su ubicación en el tablero es fundamental.

Está claro que estamos hablando de la Dirección de nuestra Organización, no?

El Proyecto de BI puede ser un proyecto que implique a toda la Organización o que sea especifico de un área concreta. En cualquiera de los casos (y siempre que consideremos que se trata de un proyecto de BI completo), la Dirección de la Compañía debe estar implicada, porque si del proyecto va a depender el cómo se toman las decisiones e incluso, qué decisiones se toman…., ¿cómo no va a conocerlo y respaldarlo la Dirección al más alto nivel? Sólo si descendemos en la cadena de valor del BI y nos quedamos en meros sistemas de obtención de información, podríamos pensar que, al ser simplemente una herramienta, su existencia no sea una parte intrínseca del trabajo de la Dirección.

Normalmente, hablaremos de la Dirección General o podemos estar hablando de la Dirección del Área a la que afecte el Proyecto, aunque en general será difícil quedarnos a nivel de área si se trata de un proyecto de BI de alto nivel

El Rey tiene dos funciones fundamentales en un proyecto de BI:

  • Implicar al resto de la organización, poniendo los recursos que sean necesarios, priorizándolos cuando se requiera e implicándose en la resolución de los problemas que, sin duda, se plantearán.
  • Ser el primer usuario del Sistema, no desde el punto de vista temporal, sino conceptual. Imaginad dos escenarios: una dirección que usa el BI para gestionar, analizar las decisiones tomadas, ver el impacto que tienen, etc… y otra, que considera el BI como una herramienta de sus subordinados sin repercusión en su propio trabajo y responsabilidades.

El Rey puede ser blanco o negro y su color hará exitoso o no el proyecto:

  • Un Rey Blanco es aquel que entiende que disponer de un sistema de BI es una pieza fundamental para la Organización y que conseguir que funcione es crítico para incrementar la generación de valor de la Compañía. Por ello, un Rey Blanco coloca el sistema de BI como una de las piezas fundamentales de su gestión y lo dota de los mejores recursos para conseguir su buen fin; pero no solo eso, en el momento en el que empieza a estar disponible, exige su utilización por toda la organización y él mismo lo utiliza para gestionar.

Hace unos años tuve ocasión de ver en acción a un Rey Blanco magnífico; a los Comités de Dirección de la Compañía, acostumbraban a acudir los diferentes directores con sus “cuadernos” en los que tenían sus números, sus análisis, etc.; por supuesto, esos números nunca cuadraban los de unos con los de otros…, y la mitad del tiempo se perdía en discusiones sobre dichos valores. Una vez disponible el BI desarrollado para la Compañía, la convocatoria del Comité de Dirección incluyó una nota en la que se decía que se utilizaría el BI para las exposiciones a que hubiera lugar. En el siguiente Comité de Dirección, el Director General cercenó todos los intentos de utilizar sistemas diferentes al BI como fuente de información, obligando a todos los directores a utilizar las cifras que estaban en el sistema y a realizar sus análisis basándose en las capacidades del sistema (que, todo sea dicho, eran muchas y más que suficientes). Ese Comité resultó bastante desastroso pues, por supuesto, todos los directores habían preparado la reunión con sus propios sistemas y métodos, pero a partir de ahí, quedo claro que la información válida era la del sistema de BI y que éste era la base para la toma de decisiones.

  • Un Rey Negro, por contra es aquel que tolera la implantación de un sistema de BI, pero sin que dicho sistema sea fundamental para él(con lo que no lo dotará en muchos casos con los recursos necesarios, no le dará la prioridad adecuada y, sobre todo, no lo usará como la herramienta clave para su propia gestión y la de todos los que de él dependan)

La importancia del Rey en un Proyecto de BI

Así como un rey blanco en la parte superior de la organización fuerza a que todo el resto de la cúpula directiva sea blanca, si el top de la organización la ocupa un rey negro, podemos encontrar reyes negros en diferentes puntos de la misma: directivos que, no siendo obligados por sus superiores, continúen usando sistemas anteriores, eviten la participación de los suyos en el Proyecto, etc…; dependerá de sus características e intereses particulares el apoyar o no el proyecto.

Es, por tanto, fundamental, disponer de un Rey Blanco a la hora de abordar un proyecto de BI. Y ésta es una las principales causas de fracaso de los proyectos de BI: la Dirección los considera proyectos “técnicos”, que afectan a procesos operativos, pero que no afectan a la Gestión de la Compañía ni, mucho menos, a su gestión como máximo responsable.

Por tanto, el primer trabajo que debe realizar quien lidere el proyecto es conseguir la total implicación de la Dirección en el Proyecto, no solo para que no ponga barreras, sino para que sea el primer usuario del sistema.

LA REINA

Pieza fundamental en el ataque y la defensa, se mueve en todas direcciones pudiendo alcanzar cualquier posición rectilínea en el tablero. Sin ella, la partida pierde dinamismo y está abocada, casi sin solución, a su finalización.

El papel de Reina  o Dama es ocupado en un proyecto de BI por la persona o estructura que lidere el proyecto, y cuyo objetivo fundamental será conseguir que el nuevo sistema constituya la base de la toma de decisiones de la Organización.

Nótese que hemos hablado de la persona o estructura que lidere…., es decir, no estamos hablando del director del proyecto de BI, cuyo objetivo será conseguir que todas las fases del proyecto se cumplan, hasta conseguir que el sistema esté operativo y en uso(*); estamos hablando de quien debe concebir el nuevo sistema de toma de decisiones, convencer a toda la organización de su necesidad, alienar la Organización con los objetivos, convencer a todos los actores de su utilización y garantizar que la nueva filosofía supone un cambio y una mejora para la Organización que aumente su generación de valor.

(*) El Director del Proyecto deberá existir y podrá incluso coincidir con nuestra Reina…, pero no necesariamente y, siendo fundamental como en todo proyecto, no es un elemento especial de un proyecto de BI, así que no será objeto de análisis en este artículo.

La Reina debe dar coherencia a todo el proyecto de BI, debiendo ejecutar obligatoriamente una serie de tareas:

  1. Conceptualizar el BI adecuado para la Organización.- es decir, analizar y establecer qué BI es el que se adecúa a nuestra organización, de acuerdo con la cultura de empresa y el resto de aspectos que hemos tratado en otros puntos de este blog.
  2. Implicar a la Dirección en la necesidad de cambiar la forma de tomar las decisiones, implicándose en el cambio cultural, operativo y de gestión.
  3. Asegurar que toda la Organización está alineada con los objetivos y estrategia definida
    1. Analizar las barreras previsibles y establecer un Plan de Desactivación de Barreras
    2. Velar por la no existencia de Reyes Negros a niveles intermedios (directores de área, etc…), que puedan ralentizar la implantación del sistema
  4. Asegurar la vinculación de la ejecución del Proyecto (responsabilidad del Director del Proyecto) con los objetivos y estrategia establecidos

 

Funciones de la Reina en una Proyecto de BI

 

La Reina es, casi por definición, una pieza blanca, aunque podríamos hablar de Reina Negra cuando esta figura no existe como tal y sus funciones se mezclan y diluyen entre las del Director del Proyecto, anteponiendo los aspectos ejecutivos del proyecto a la razón de fondo del mismo.

LA TORRE

Con movimientos horizontales o verticales, la torre asienta la estrategia de defensa, permitiendo cambios instantáneos en el ataque. Se trata de una de las piezas cuyos movimientos cambian el planteamiento de la partida, pudiendo generar variaciones estratégicas.

El rol de Torre es desempeñado por la Tecnología, entendida como los recursos humanos tecnológicos involucrados en el Proyecto.

Un proyecto de BI es un proyecto eminentemente tecnológico; supone la incorporación de la tecnología no ya a la operación, sino a la gestión de la Organización, implicando una nueva manera de tomar decisiones.

La tecnología tiene dos derivadas en cualquier proyecto de BI:

  • Una hacia delante, a través del propio Sistema de BI que se implante y que debe facilitar la mejora en el proceso de toma de decisiones (no entraremos en sus características, pues en otros artículos lo hemos desarrollado)
  • Otra lateral, enlazando con todos los sistemas existentes en la Organización, de los cuales debe extraer (y en su caso, volcar) información y en los cuales ha venido soportándose la toma de decisiones

La cooperación del área de Tecnología, su entendimiento del proyecto de BI y su alineamiento con el mismo, asumiendo un cambio de rol, es fundamental para garantizar el éxito de proyecto.

Para el área de tecnología, un proyecto de BI puede suponer perder su principal poder dentro de la Organización: los usuarios ya no necesitan al Departamento de Sistemas para tener acceso a la información, siendo autosuficientes; el director de Informática ya no es quien establece las prioridades de información entre unos y otros usuarios, sino que todos los usuarios acceden de forma instantánea a todo lo que necesitan…, en definitiva, deja de ser la piedra angular que tiene la información y por tanto el poder.

Cambio de rol de la Tecnología en un Proyecto de BI

En esta situación, la sensación de pérdida de poder hace que, en ocasiones, el Departamento de Informática sea el principal enemigo de los sistemas de BI. Como me decía el Director de Informática de una empresa multinacional muy grande, “para que quiero yo una herramienta de estas para hacer gráficos, cuando tengo mas de 100 programadores  (y me señaló una pradera llena de gente), dedicados a hacer los informes que necesita la Organización”, es decir, para que iba él a apoyar la implantación de un sistema que provocaría que “sus” 100 programadores ya no fuesen necesarios y que ya no fuese él quien definiese qué necesitaba la organización y el orden en que esas necesidades eran satisfechas por el departamento de informática. Esa pérdida de poder era impensable que la realizase de manera voluntaria y, de hecho, años después, la situación en ésta empresa sigue siendo casi la misma.

  • La Torre Negra puede oponerse frontalmente al proyecto – como me ocurrió en una entidad financiera, donde, con el CEO a favor, el D. de Estrategia a favor, etc…, el proyecto no se realizó porque el D. de Informática había dicho que “él no se responsabilizaba de ese proyecto”…, así que la Dirección tuvo que optar entre el proyecto o el D. de Informática…, y ¡se quedó sin sistema de información estratégica-; aunque en muchos casos la oposición puede ser más sutil y, sin remar en contra, hacer que el proyecto sea un fracaso. Dos son las formas de dinamitar un proyecto de BI desde Tecnología:
    • No ayudando a la elección de un Software adecuado a la Organización, que choque con la cultura, el nivel de tecnificación, etc…, o que directamente sea tan escaso que realmente no suponga una mejora para los usuarios (esto es lo habitual cuando se eligen los grandes softwares que hacen muy bien informes, pero que no facilitan el cambio en el modelo de gestión de la Organización)
    • Dificultando el proceso de integración con los sistemas de base existentes, generando un volcado limitado de información (que limita las posibilidades del BI) o no integrando el BI con el resto de sistemas, con lo que se queda como una pieza aislada de lo demás.
  • Por contra, una Torre Blanca apoyará la transformación de la Organización, detectará barreras culturales relacionadas con la tecnología, controlará los responsables a favor y en contra del proyecto y trabajará con la Reina para conseguir hacer más fácil el proceso de implantación a toda la Organización; además facilitará la transición al nuevo sistema. Ello implica un cambio de rol de Tecnología: ya no es el “dueño” de la información, sino que es un aliado de todos los gestores para que puedan gestionar de la mejor manera; es quien debe hacer que la tecnología facilitadora de la gestión fluya por la Organización

Como hemos dicho, el papel del Área de Tecnología es fundamental, pero es una de las áreas que más se ven afectadas por la implantación de un sistema de BI, dado que cambia su función (en una parte) dentro de la Organización y, por tanto, no siempre juega a favor del proyecto.

EL ALFIL

Con movimientos diagonales, el Alfil cohesiona las diferentes líneas de ataque, mientras refuerza la defensa desde posiciones distantes.

Un rol muy relevante en cualquier proyecto de BI es el asignado a los responsables funcionales de las áreas; ellos son quienes deben establecer las necesidades de los usuarios, la manera de utilizar los nuevos sistemas y los resultados a obtener como consecuencia de los cambios en el proceso de toma de decisiones.

Su papel es básico, pues de la correcta definición de las necesidades y su impacto en la Organización va a depender el sentido del nuevo sistema de gestión.

  • Un Alfil Blanco lidera funcionalmente su área, establece necesidades, analiza los recursos del área, su cultura, define KPIs y sus metas, detecta los puntos de relación y dependencia con otras áreas (de ahí su transversalidad) y pelea para conseguir su máxima implicación en el Proyecto.
  • El Alfil Negro, normalmente suele ser la carencia de un Alfil Blanco; es casi inevitable que algunas áreas no se vean involucradas en el proceso y en éstas, suele no existir nadie que asuma el rol de Alfil: nadie pilota las necesidades del área ni se preocupa de que el nuevo sistema de gestión se adapte a su funcionamiento y características.

Aquellas áreas sin Alfil Blanco terminan siendo reactivas al proyecto, se incorporan de manera lenta al mismo, sus necesidades no están bien cubiertas ni los resultados son coherentes con su organización y recursos.

El Alfil Blanco debe contar con el apoyo del responsable del área, aunque éste pueda no estar implicado en el proyecto. En caso contrario, una de sus principales misiones será implicarle en el proyecto.

Áreas sin Alfil Blanco se convierten en una de las prioridades de la Reina y donde debe focalizar su juego de Caballos.

EL CABALLO

Los movimientos no rectilíneos del caballo le permiten interactuar con posiciones no accesibles por ninguna otra pieza.

Uno de los principales problemas que puede tener un proyecto de BI es estar configurado con piezas independientes. Es necesario contar con figuras que cohesionen el proyecto sobre dos ejes:

  • Horizontal .- Asegurando que los objetivos, la forma de soportarlos y el nivel de validez de la solución es válida para todos las áreas funcionales; coordinando la interacción de las diferentes áreas; facilitando soluciones comunes y valor general y en definitiva, consiguiendo que el sistema de BI sirva para toda la organización y no solo para una parte de ella.
  • Vertical.- Asegurando la coherencia y validez del modelo para todos los planos de la Organización: Operativo, de Gestión y Estratégico. El proceso de toma de decisiones nunca puede entenderse como una coto cerrado de determinadas niveles de la Organización y debemos garantizar su permeabilidad por toda la estructura y todos los niveles

Parte de las funciones antes comentadas serán ejercidas por la Reina, pero es imposible que se multiplique suficientemente y, probablemente, algunas de estas funciones deben ser ejecutadas por tropas más ejecutivas, dejando a la reina la coordinación de los caballos.

Caballos podemos tenerlos explícitos -forman parte del equipo de proyecto- o implícitos, aportando con su experiencia y conocimiento de la Organización la necesaria coherencia en el proyecto.

  • El Caballo Blanco, por tanto, cohesiona diferentes partes del proyecto, tanto horizontales como verticales; asegura que el sistema sirve para todas las áreas involucradas y aporta coherencia entre los niveles operativo, de gestión y estratégico
  • El Caballo Negro, al igual que ocurría con el alfil, suele implicar la inexistencia de una figura que asegure la coherencia del proyecto. Esto repercute siempre en crear agravios entre áreas, que determinadas áreas se descuelguen del proyecto, que se cubran unos aspectos y otros no o, en el peor de los casos, que el sistema de BI solo sirva a uno de los niveles de la gestión: operativa, de gestión y estratégica.

Al igual que decíamos con la Reina, el rol de los Caballos no debe ser confundido con los miembros del equipo de trabajo, que podrán ejecutar sus trabajos de una manera correcta en sus respectivos ámbitos, sin que eso garantice la coherencia necesaria del proyecto.

De hecho, esta falta de integridad, de coherencia y de cohesión en los proyectos de BI es uno de los principales problemas de estos proyectos: terminan siendo unas piezas tecnológicas fantásticas, que no satisfacen las necesidades de toda la Organización, bien porque cubren unas áreas si y otras no, bien porque se olvidan del nivel estratégico o se aíslan del nivel transaccional.

LOS PEONES

¿De qué me sirve tener el mejor sistema del mundo si mis usuarios no lo utilizan? Esta pregunta, que es de Perogrullo, suele olvidarse cuando hablamos de los sistemas de BI. Esto, además, es peculiar de estos sistemas y no se da, por ejemplo, cuando hablamos de la implantación de sistemas transaccionales, donde, por definición todo el mundo debe usarlos y no se admite otra situación. Por contra, seguimos considerando que la toma de decisiones es parte de las capacidades intrínsecas del ser humano y, sobre todo de los directivos y que “para eso les pagamos”; asumir que dotar a una Organización de un Sistema de Toma de Decisiones implica exigir a esa Organización que lo utilice, sigue siendo difícil: no valoramos la toma de decisiones por el proceso cómo se ha realizado sino por el resultado: si la decisión es buena, vale como se haya llegado a ella; si es mala, da igual cual haya sido la causa. Esta irracionalidad en la exigencia de responsabilidades  sólo se da en este ámbito; imaginaos un contable que se empeñase en realizar la contabilidad manualmente o un director de producción que no utilizase herramientas de planificación…, sería impensable, ¿verdad?. Sin embargo, admitimos sin problemas que nuestros directivos y gestores tomen decisiones sin usar las herramientas de las que les hemos dotado.

La ultima fase de un proyecto de BI es su puesta en marcha como sistema de toma de decisiones, no simplemente la puesta en marcha de la aplicación informática, y para ello tenemos que conseguir un tablero lleno de Peones Blancos

  • Un Peón Blanco es, obviamente, un usuario que utiliza el sistema para su propia toma de decisiones y exige a los que dependen de él a aplicar la misma coherencia, sistemática y procedimiento de toma de decisiones; es decir, es aquel que basa sus decisiones en una metodología e información acorde con el sistema corporativo de BI.
  • Por contra, un Peón Negro pasará del Sistema de BI y seguirá funcionando como venía haciéndolo con anterioridad a la implantación del BI.

Durante todo el proceso de gestación y desarrollo del Proyecto de BI, todas las piezas blancas deberán colaborar para minimizar el número de Peones Negros y, una vez implantado, todos los esfuerzos irán en la línea de debilitar su existencia e imposibilitar su multiplicación, eliminando todas las prácticas que faciliten su proliferación.

Como todo sistema, nunca conseguiremos un sistema de BI perfecto a la primera, con lo que las críticas serán habituales y justificadas; ante ello, es necesario concebir el nuevo sistema como un elemento en permanente evolución, que incorpore las carencias y mejore los defectos. Pensar que una vez terminada la implantación del Proyecto de BI, el trabajo se ha terminado es la mejor manera de garantizar el fracaso del sistema.

Ir corrigiendo de manera dinámica los defectos y carencias será la mejor forma de convertir a los peones negros en blancos, pero su existencia persistirá y será una de las labores del Rey Blanco evitar que perjudiquen al nuevo sistema de Toma de Decisiones de que se ha dotado la Organización.

En resumen: antes de abordar un proyecto de BI, garanticemos que contamos con un Rey y una Dama Blancos, empecemos por poner a nuestro favor a Tecnología y conseguir que sea una Torre Blanca y a lo largo de todo el Proyecto, controlemos los alfiles, caballos y peones negros del tablero, minimizando su impacto e influencia

Publicado en BI, Business Intelligence, Implantación BI, Implantación de un Sistema de BI, Inteligencia de Negocios, Metodología Business Intelligence, Toma de Decisiones, Uncategorized | Etiquetado , , , , , , , , | Deja un comentario

Las 13 Soluciones de BI más importantes frente a frente: las nuevas soluciones arrasan frente a las tradicionales

Tercera entrega de nuestra serie de artículos basados en los datos de la Encuesta de Satisfacción de Usuarios BI recién publicada por Gartner (octubre 2014)…, y la conclusión es radical: las soluciones tradicionales son barridas por soluciones algo menos conocidas, como es el caso de BITAM, Panorama y Tableau.

La encuesta recoge datos de 27 soluciones; en este artículo hemos seleccionado las que consideramos pueden ser relevantes en nuestros mercados y que cualquier directivo que esté analizando posibles alternativas podría barajar: BITAM, IBM-Cognos 10, Information Bulders, Microsoft-SQL 2012, MicroStrategy, Oracle, Panorama, Pentaho, QlikTec, SAP-Business Object 4.1, Tableau y Tibco.

20 son los criterios que aparecen con datos directos medibles, aunque en el informe aparece algún otro criterio respecto del cual solo se ofrece el posicionamiento de cada solución respecto a la media, situándolas por encima o por de bajo de ésta. En las gráficas siguientes se ofrecen los valores obtenidos por cada solución para cada criterio valorado. Aunque desde mi punto de vista no todos tienen la misma importancia ni mucho menos, creo que es preferible el dato puro y que cada uno se haga sus composiciones a andar presentando conclusiones de laboratorio.

La primera conclusión nos la ofrece la siguiente tabla, elaborada a partir de las valoraciones de los 20 criterios en cada solución: BITAM, Panorama y Tableau son valoradas muy por encima del resto de las soluciones en el conjunto de los criterios analizados, con un empate técnico entre Panorama y Bitam en la primera posición.

Las 13 Soluciones principales del Mercado BI frente a frente

Ranking de las 13 Soluciones BI principales

Esta tabla también nos ofrece una perspectiva muy clara de las soluciones menos valoradas: IBM-Cognos, Oracle, SAP-Business Object y SAS cierran el ranking, destacando la posición de cola de Oracle.

Al objeto de ordenar un poco los criterios los hemos agrupado en 4 bloques:

  • Criterios que afectan a las características del producto (calidad, rendimiento, etc…)
  • Criterios que afectan a su facilidad de utilización por los departamentos técnicos (soporte, facilidad de upgrade, etc…)
  • Criterios que valoran la Integración de la Solución y su facilidad de Integración con otros elementos
  • Criterios que valoran la empresa fabricante (experiencia de ventas, futuro de la solución, etc…) y la Solución como globalidad.

La siguiente tabla muestra la posición de cada solución respecto a estos 4 criterios de agrupación, calculados como media aritmética de los criterios incluidos: en las cuatro agrupaciones de criterios Bitam, Panorama y Tableau siguen figurando en cabeza.

Producto, Facilidad Técnica, Integración e Integrabilidad y Empresa Fabricante

Resumen de las Valoraciones de los Usuarios

Vamos a realizar un breve repaso de los diferentes criterios recogidos en la Encuesta.

1.- Valoración de las Soluciones BI: los Productos

Cuatro son los criterios que hemos incluido en este punto, entendiendo que son los criterios que directamente afectan a los usuarios directos y que mejor reflejan la impresión que sobre cada solución tienen quienes las utilizan:

  • Calidad del Producto
  • Facilidad de Uso
  • Velocidad de Respuesta / Rendimiento
  • Valoración Media de las Diferentes Funcionalidades (17) analizadas en la Encuesta
Como valoran los usarios los principales productos de BI

Valoración del Producto: Calidad, Usabilidad, Rendimiento y Funcionalidades

 2.- Valoración de las Soluciones BI: Aspectos Técnicos

En este apartado hemos incluido todos aquellos aspectos de la Encuesta que más afectan al desempeño directo de las áreas técnicas:

  • Sencillez de Upgrade
  • Integración (entendida como media de todos los aspectos de integración e integrabilidad, aunque no queda muy claro qué y como lo computa Gartner)
  • Calidad del Soporte (que entendemos que afecta más al área técnica que al usuario final)
  • Amplitud de Uso de las diferentes funcionalidades, es decir, qué porcentaje de usuarios dentro de la organización utilizan varias funcionalidades de BI. En mi opinión éste es uno de los aspectos que mejor indican qué soluciones cubren las necesidades globales de un usuario BI y cuales son buenas sólo en un aspecto limitado.
Las Principales Soluciones BI frente a los aspectos técnicos

Valoración Técnica de las Soluciones: Facilidad de Upgrade, Integración, Soporte y Amplitud de Uso

3.- Valoración Soluciones BI: Integración de la Plataforma y Capacidad de Integración con otras soluciones tecnológicas

Este año el informe de Gartner desglosa bastante los aspectos relativos a la integración de la solución y su capacidad de relacionarse con otros productos y soluciones tecnológicas: los movimientos de compra del mercado han generado que algunas de las soluciones hayan pasado a ser un “batiburrillo” de productos agrupados bajo una única marca, pero sin que realmente haya una plataforma común; por otro lado, cualquier solución -del tipo que sea-, constituye cada vez más una pieza del puzle tecnológico de las empresas, por lo que una solución difícilmente integrable termina siendo un problema más que una ventaja competitiva para la empresa.

Siete son los criterios incluidos en éste apartado: cuatro tienen que ve con que sea realmente una solución y no un conjunto de productos y tres con su capacidad de integrarse y relacionase con otros elementos tecnológicos:

  • Facilidad de Integración:
    • Integrabilidad en Portales
    • Utilización y Generación de DataMashups
    • Integración con Productos Complementarios de BI
  • Integración de la Solución:
    • Integración de los componentes en una Plataforma Común
    • Plataforma de Administración y Seguridad Comunes
    • Capa Semántica Común
    • Herramientas de Front-End comunes
Valoración de las pricipales soluciones BI: Integración e Integrabilidad

Valoración de las Soluciones: Integración e Integrabilidad

4.- Valoración de las Soluciones BI: las Empresas Fabricantes

Varios de los aspectos analizados en la encuesta valoran más que las soluciones en sí, aspectos que tienen que ver con la forma de posicionarse en el mercado de las empresas fabricantes o con la percepción general que los usuarios tienen (y que no dependen solo del producto o del servicio). En este apartado hemos incluido cinco criterios de evaluación:

  • Experiencia de Ventas
  • Experiencia de Cliente
  • Futuro de la Solución
  • Beneficios para el Negocio
  • Satisfacción General con la Solución

Entendemos que los dos últimos son un compendio de lo realmente importante: hasta que punto la solución analizada ayuda a la competitividad de la empresa y cual es la satisfacción general con la solución.

Valoración de las Soluciones BI: los fabricantes

Valoración de las Soluciones BI: el Fabricante y la Solución Global

En resumen, BITAM y  Panorama lideran claramente el ranking de valoración de los usuarios, prácticamente con un empate técnico entre ellos; de hecho en más de la mitad de los criterios analizados ambas empresas copan la primera y segunda posición; el tercer lugar es ocupado por Tableau Software y a una distancia considerable Information Builders.

 

 

Publicado en BI, BI Customers Survey, BI Gartner, Business Intelligence, Cual es el mejor BI, Decisones de Negocio, Encuesta, Encuesta de Satisfacción de Clientes Gartner, Estado de Opinión, Gartner, Gartner BI 2014, Inteligencia de Negocios, Opinión de los usuarios sobre las herramientas de BI, Teccnologia, Tecnología para la Toma de Decisiones, Toma de Decisiones, Valoración de las soluciones de Business Intelligence | Etiquetado , , , , , | 1 Comentario

Encuesta de Satisfacción de Clientes BI Gartner 2014.- Análisis Global

Gartner acaba de presentar su Encuesta de Satisfacción de Usuarios BI (octubre 2014). Como siempre, el informe de Gartner presenta la información combinando factores para hacer sus análisis, pero en ocasiones, en mi opinión, más que facilitar, ese tipo de tratamiento enmascara la realidad de lo que opinan los usuarios.

Es por ello que, como otros años, en estos artículos intentamos recoger los datos puros que ofrece el informe, aislando cada uno de los elementos analizados y recogidos en el informe con valoración (existen determinados aspectos en los que simplemente se dice si la solución está por encima o por debajo de la media, pero esto permite poco análisis).

Los datos recogidos permiten hacer tres tipos de los análisis significativos:

  • Qué Soluciones lideran cada uno de los aspectos analizados
  • Qué Soluciones son las peor valoradas
  • Cual es el posicionamiento relativo entre las diferentes soluciones

La forma de realizar las encuestas hace que cada usuario valore su solución (la que él maneja y tiene en su organización). Eso hace que las comparativas siempre puedan adolecer de algunos vicios, pero cuando extrapolamos los datos y nos quedamos con cuales son las mejor y peor valoradas, esto nos da una visión directa de lo que opinan los usuarios de estas soluciones.

De estos diferentes análisis podemos extraer algunas conclusiones generales:

Los usuarios siguen valorando mejor lo que Gartner denomina “soluciones pequeñas” que las grandes soluciones tradicionales

Birst, Bitam, Panorama, Prognoz y Tableau lideran el ranking de soluciones mejor valoradas, apareciendo valoradas entre las 10 primeras en casi todos los criterios analizados.

Pero no solo es que estén entre las mejores en los 20 aspectos analizados, sino que copan las primeras posiciones en todos ellos; si a las anteriores añadimos Alterix y Logi, las tres primeras posiciones de prácticamente todos son ocupadas por estas 7 empresas.

La gráfica siguiente recoge el número de criterios en los que cada solución analizada aparece en las primeras posiciones (1ª, 2ª, 3ª, 4ª, 5ª y de la 6ª a la 10ª)

Las Soluciones BI mejor valoradas

Las Soluciones Mejor Valoradas por los Usuarios

Visto de otra forma, y si asignamos valoraciones a las posiciones positivas obtenidas (10 para la primera posición hasta 1 para la décima posición), podemos ver una tabla que refleja de manera resumida, cuales son las mejores soluciones para los usuarios:

Las Solucioens BI mejor valoradas por los Usuarios

Ranking Global de las Soluciones Mejor Valoradas

Los usuarios cada vez aprecian menos las grandes soluciones tradicionales

Si en el análisis y el cuadro anterior recogíamos las preferencias en positivo, quizás aun más esclarecedor resulta cuando comparamos los resultados peores obtenidos por los 27 fabricantes analizados.

Como vemos en la siguiente gráfica, las grandes soluciones tradicionales (SAS, SAP, Oracle, IBM), junto con algún “pequeño” como Actuate, Arcplan, GoodData o Pyramid aparecen en más de la mitad de los criterios como las soluciones peor valoradas. MicroStrategy tampoco se salva, apareciendo justo detrás de las anteriores. Resulta sorprendente que Oracle aparezca en todos los criterios en las peores posiciones, seguido de cerca por Cognos-IBM

Las Sluciones menos apreciadas por los usarios

Ranking de Soluciones valoradas en las Últimas Posiciones

Si al igual que hacíamos antes asignando un valor positivo a las mejores posiciones, lo hacemos para los peor valorados, pero al revés (-10 para la última, hasta -1 para la decima por detrás), podemos construir una tabla resumen como la siguiente, que matiza los resultados anteriores:

Las Peores Soluciones de BI

Las Soluciones BI Peor Valoradas según los usuarios

Si realizásemos un análisis combinando ambos factores -las soluciones mejor valoradas y las peor valoradas por los usuarios-, obtendríamos una gráfica como la siguiente, donde las barras recogen la posición media ponderada. Este análisis desprecia las posiciones intermedias, exagerando el afecto de estar entre las mejores o entre las peores, pero creo que facilita una visión más acertada del mercado según los clientes y usuarios de Business Intelligence.

Este análisis prima estar entre los mejores valorados y no estar entre los peores, quedando tres empresas claramente destacadas: Birst, Bitam y Jaspersoft

Valoración de las soluciones BI (Gartner 2014)

Valoración media de las Soluciones BI

Las grandes empresas siguen prefiriendo las soluciones tradicionales, pero cada vez se abren paso las opciones en las que prima la calidad, el servicio y las prestaciones

El análisis que ofrece Gartner incorpora el tamaño de la empresa usuaria, como uno de los elementos de análisis. Dos conclusiones podemos obtener de dicha información:

  • Las grandes empresas siguen manteniendo a los grandes fabricantes (Oracle, SAP-Business Object, IBM-Cognos, MicroStrategy o SAS) de manera tal que estos fabricantes lideran claramente el análisis basado en el tamaño de las empresas clientes.
  • Sin embargo, cada vez es más clara la escalada de empresas que no pertenecen al grupo de las tradicionales; así, fabricantes como Actuate, Arcplan, Alteryx, Bitam, Pentaho, QlikTech, Tableau y Tibco  se posicionan igualmente en segmentos medios de más de 10.000 empleados.

En el próximo artículo analizaremos los datos obtenidos por las 13 principales Soluciones del Mercado en todos los criterios, dejando de lado los resultados de fabricantes menores con poca relevancia y presencia en el mercado mundial, aunque incorporaremos algunos de los “emergentes”

 

 

 

Publicado en BI, BI Customers Survey, BI Gartner, Business Intelligence, Cual es el mejor BI, Encuesta, Encuesta de Satisfacción de Clientes Gartner, Estado de Opinión, Gartner, Gartner BI 2014, Inteligencia de Negocios, Opinión de los usuarios sobre las herramientas de BI, Teccnologia, Tecnología para la Toma de Decisiones, Uncategorized, Valoración de las soluciones de Business Intelligence | Etiquetado , , , , , , | 1 Comentario

BITAM frente a las principales Soluciones BI, según la Encuesta de Satisfacción de Usuarios de Gartner (octubre 2014)

Un año más, Gartner ha publicado la encuesta de satisfacción de usuarios BI, analizando las principales soluciones con presencia en el mercado.

En las graficas presentadas destaca como novedad el detalle de los aspectos de integración de la plataforma y de capacidad de integración con otros elementos del entorno BI. Sin embargo, dado que se trata de un elemento novedoso, las siguientes gráficas solo contemplan una única línea para todos los aspectos relacionados con la integración, al objeto de no disparar el numero de elementos analizados.

Este año se ha incluido en nuestro análisis dos nuevas soluciones de BI: Pentaho y Panorama; la primera porque es un “jugador” habitual en nuestros mercados y la segunda porque cada vez aparece más. Junto con Tableau y Tibco son soluciones con una menor presencia, aunque en determinados mercados y para algunos aspectos del BI puede ser significativa.

De la comparativa de BITAM frente a las grandes soluciones, sigue destacando la gran diferencia existente, cuando de la valoración de los usuarios hablamos. La valoración de los usuarios de los grandes fabricantes sigue cayendo, aunque en algunos casos, la aparición de nuevas versiones consigue mantener esas soluciones en márgenes razonables (al objeto de mantener la comparativa lo más real posible, solo se han cogido las opiniones de la ultima versión cuando el fabricante mantiene varias en el mercado)

Sin más preámbulos, a continuación tenéis las comparativas directas de Bitam con los principales fabricantes.

Los Usuarios valoran a Bitam y a Cognos

Bitam vs Cognos (Encuesta Satisfacción de Usuarios Gartner 2014)

Los Usuarios Valoran a Bitam e Information Builders

Bitam vs Information Builders (Encuesta Satisfacción de Usuarios Gartner 2014)

Los usuarios valroan a Bitam y a Microsoft

Bitam vs Microsoft (Encuesta Satisfacción de Usuarios Gartner 2014)

Los usuarios valoran a Bitam y a MicroStrategy

Bitam vs MicroStrategy (Encuesta Satisfacción de Usuarios Gartner 2014)

Los usuarios valoran a Bitam frente a Oracle

Bitam vs Oracle (Encuesta Satisfacción de Usuarios Gartner 2014)

Los usuarios valoran a Bitam y Panorama

Bitam vs Panorama (Encuesta Satisfacción de Usuarios Gartner 2014)

Los usuarios valoran a Bitam y a Pentaho

Bitam vs Pentaho(Encuesta Satisfacción de Usuarios Gartner 2014)

Comparativa de Bitam y QlickTech

BITAM vs.Qlick.- Encuesta Satisfacción BI Gartner 2014

Los usuarios valoran a Bitam y SAP

Bitam vs SAP(Encuesta Satisfacción de Usuarios Gartner 2014)

Los usuarios valoran Bitam y SAS

Bitam vs SAS (Encuesta Satisfacción de Usuarios Gartner 2014)

Los usuarios valoran a BITAM y a Tableau

Bitam vs Tableau (Encuesta Satisfacción de Usuarios Gartner 2014)

Los usuarios valoran Bitam y Tibco

Bitam vs Tibco (Encuesta Satisfacción de Usuarios Gartner 2014)

Publicado en BI, BI Customers Survey, BI Gartner, Business Intelligence, Cual es el mejor BI, Decisiones, Decisones de Negocio, Encuesta, Encuesta de Satisfacción de Clientes Gartner, Estado de Opinión, Gartner, Gartner BI 2014, Inteligencia de Negocios, Opinión de los usuarios sobre las herramientas de BI, Teccnologia, Tecnología para la Toma de Decisiones, Toma de Decisiones, Valoración de las soluciones de Business Intelligence | Etiquetado , , , , , , , | Deja un comentario