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.

Esta entrada fue publicada 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 y etiquetada , , , , , , , . Guarda el enlace permanente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s