Proyectos de BI: ¿Cuál es el elemento fundamental?

Muchas veces hemos hablado de los diferentes elementos a considerar para abordar adecuadamente un proyecto de Business Intelligence (metodología, fases, actores, etc…), pero hoy vamos a centrarnos en el que, en nuestra opinión, es el elemento fundamental a la hora de abordar un proyecto de este tipo y cuya no consideración es el mayor error que se suele cometer:

la MEJORA en la GESTIÓN

¿Qué es lo que queremos mejorar?, ¿Dónde tenemos problemas en nuestra información que nos hacen perder oportunidades?, ¿Qué indicadores o KPI’s queremos cambiar?…; podemos formularlo de mil formas diferentes, pero, al final, todas redundan en lo mismo: ¿qué es lo que queremos gestionar mejor en nuestra Organización para generar más valor?

Se que casi todos me diréis que sí, que ese es el desencadenante del proyecto de BI, el motivo por el que se lanzan estos proyectos….., cierto, aunque por desgracia el Análisis de la Necesidad no siempre se realiza de manera adecuada, como podéis ver en el post “Elementos de un Proyecto de BI: la Necesidad“.

Sin embargo, el que tengáis identificada la necesidad NO ES SUFICIENTE; es el requisito necesario, ¡por supuesto!, pero eso no os garantiza que el proyecto sirva para algo.

¿Cual es el requisito fundamental vinculado a la Necesidad?: que sea el HILO CONDUCTOR de todo el Proyecto. No solo que lo hayamos definido inicialmente de manera correcta sino que, DURANTE TODO EL PROYECTO, todas las decisiones y todas las actuaciones estén orientadas a la consecución del objetivo definido.

No es un ejercicio teórico: toda la metodología que utilicemos debe estar centrada en la consecución del objetivo final, debe bascular sobre cómo mejorar la gestión.

Puede que alguno esté pensando que esto es un lugar común, que obviamente si hacemos un proyecto informático es para obtener una mejora en algún aspecto…., pero es que un Proyecto de BI NO es, fundamentalmente, un proyecto informático. ¿Utiliza la informática?, por supuesto! ¿Debemos plantear un proyecto de informática para desarrollarlo?, sería absurdo no utilizar la tecnología hoy en día…., pero ¡no es un Proyecto Informático!

Cuando lanzamos un proyecto de BI, debe ser buscando una mejora en nuestra gestión, debemos buscar generar más valor con nuestras decisiones de gestión. Un ejemplo: si tenemos un problema con el control de nuestros gastos de viajes, lo normal es que desarrollemos una aplicación de gestión que nos permita capturar los gastos de nuestros empleados, de manera cómoda y fiable, con procedimientos de validación, etc…., y para ello desarrollaremos una aplicación informática; sin embargo, si queremos mejorar la gestión de nuestros gastos de viaje, no solo tendremos que tener la información, sino que deberemos articular mecanismos de análisis que nos digan donde hay problemas y deberemos hacer cambios en nuestra forma de gestionar los viajes. Para ello podremos haber lanzado un proyecto de BI…., pero lo fundamental de dicho proyecto es realizar una mejora en el modo de gestionar nuestros gastos de viaje; por el mero hecho de moner en marcha el sistema, no mejorará nuestra gestión de los gastos de viaje…, al contrario de lo que ocurría si nuestro problema era solo de que necesitábamos controlar dichos gastos, en cuyo caso, la puesta en marcha del sistema informático automáticamente implica la consecución del objetivo de control.

Proyecto de BI = Mejora en la Gestión

La Mejora en la Gestión: Hilo Conductor en los Proyectos de BI

Y todo esto no es sólo teoría: la Necesidad de Mejorar nuestra Gestión debe ser el Hilo Conductor de todo nuestro Proyecto; cuando definamos las herramientas, cuando diseñemos el equipo, cuando elijamos la metodología, cuando diseñemos el sistema, cuando demos la formación……, absolutamente en todas las fases de nuestro proyecto debemos guiarnos por el objetivo de gestión que teníamos al principio y que definimos inicialmente.

Si pensáis que ésto es obvio, reflexionad sobre los proyectos de BI que habéis hecho recientemente: ¿teníais clara la Necesidad?, ¿definisteis objetivos claros del proyecto en base a dicha necesidad?, ¿seleccionasteis las herramientas en base a dicha necesidad?, ¿organizasteis los equipos de trabajos para optimizar la mejora en la gestión a obtener?….; pues si no lo hicisteis, os saltasteis una de las claves para obtener un buen resultado de vuestro proyecto y, probablemente, tras un proceso largo y costoso, ¡no hayáis conseguido mejorar realmente la gestión de vuestra Organización!

Quiero aprovechar para anunciaros que hemos estado trabajando para sistematizar todos los aspectos metodológicos que aparecen en este blog y que, en los próximos días, lanzaremos un curso gratuito sobre Cómo Hacer un Proyecto de BI que Funcione, al que os podréis apuntar todos los que estéis interesados, sin ninguna obligación ni coste. Si queréis evitar que se os pase, os sugiero que os apuntéis de momento a la Newsletter (podéis hacerlo pinchando en la cajita de la parte superior derecha) y una vez al mes recibiréis un resumen con las ultimas publicaciones

 

 

 

 

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

La Paradoja del Rey Desnudo y la Toma de Decisiones

Siguiendo una de las líneas de este blog, hoy vamos a utilizar un cuento para reflexionar sobre la forma en la que abordamos la Toma de Decisiones en nuestras organizaciones. Para ello, traemos a colación uno de los cuentos populares más famosos,“El Rey Desnudo” o “El traje nuevo del Rey”, que normalmente se atribuye a Hans Christian Andersen (1837), pero que con anterioridad lo encontramos recogido en El Libro de los enxiemplos del Conde Lucanor et de Patronio (1335) por Don Juan Manuel.

Dado que es bastante conocido, vamos a resumirlo de forma libre:

En un país muy lejano vivía un rey, siempre preocupado de poseer los objetos más valiosos y excepcionales. Ocurrió que tuvo conocimiento de que los mejores sastres del mundo andaban por su reino por lo que los mandó llamar. Cuando estuvieron ante él les pidió que le hicieran el mejor traje del mundo o los mandaría matar; los sastres, tras hablar entre ellos le dijeron que le harían el traje más maravilloso del mundo y con el que el Rey se vería gallardo como nunca antes, pero que, además, sería un traje que solo los listos podrían ver, y le pidieron una fortuna en joyas y dinero. El rey pensó que con un traje así podría presumir en la corte y ante sus súbditos como ningún otro monarca de los reinos vecinos, así que accedió.

Tal y como solicitaron los sastres, habilitaron unas lujosas dependencias para que trabajaran, ordenando que les facilitaran todo aquello que pidieran; durante días y días los sastres vivieron a cuerpo de rey, disfrutando de todos los placeres que el dinero y el poder podían conseguir en aquel reino.

Al cabo de una semana el Rey empezó a mosquearse y decidió enviar a uno de sus lacayos a que viese como iban los sastres. Estos, cuando le vieron venir, hicieron grandes alharacas y aspavientos y le hicieron acercarse al telar, que se encontraba absolutamente vacío; “¿Qué os parece el traje? ¿Es absolutamente maravilloso, verdad?, dijeron mientras manipulaban el aire como si manejaran sedas e hilos de oro. El cortesano, que no veía nada, pero que conocía que era un traje que solo los tontos no podían ver, les siguió el juego y, cuando volvió con el monarca se deshizo en alabanzas, repitiendo todas las descripciones que los sastres habían hecho.

El rey se quedó más tranquilo durante un tiempo, hasta que, una semana después, envió a otro cortesano para ver si faltaba mucho y para que le contase cómo era el traje que estaban confeccionando. Al igual que habían hecho con el anterior, los sastres se dedicaron a manipular el aire, gesticulando como si en sus manos tuviesen un delicado traje y fueron describiendo todos los detalles del mismo…., mientras el vasallo miraba el vacío que ante él se describía como una de las maravillas del mundo. Pero con el antecedente del anterior emisario y conociendo que sólo los inteligentes podían ver el traje, decidió disimular y fingió que el también lo veía, celebrando con alborozo la maravilla que habían confeccionado los sastres y reproduciendo con todo detalle las características del traje ante el Rey

Así fue como, al poco tiempo, los sastres se personaron ante el rey y tras hacerle desnudarse simularon vestirle, mientras iban describiendo las maravillas de las telas, los colores, los bordados y todos los elementos que iban inventando y lo bien que sentaba el traje al rey y lo apuesto que con él se veía. El rey, demudado ante la imposibilidad de ver nada de las maravillas que le describían, les hizo repetir una y otra vez todos los detalles para ser capaz de disimular ante la Corte y que nadie se diera cuenta de que su rey era tan tonto que ni siquiera podía ver su maravilloso traje.

El traje nuevo del Rey

El Rey desnudo

Vestido con su imaginario traje, el rey paseó desnudo por Palacio; todos los súbditos con los que se cruzaba -tras un momento de estupor inicial al ver desnudo al rey- se fueron sumando a las alabanzas sobre el traje y lo apuesto que se veía al rey, así vestido, pues nadie estaba dispuesto a que los demás pensaran que era estúpido.

Al día siguiente, el rey decidió mostrar su nuevo traje al pueblo. Las noticias sobre el nuevo traje y su extraordinaria característica ya eran la comidilla en todo el reino, así que cuando el rey salió a pasear por las calles, los primeros en verle estallaron en comentarios aduladores para que nadie pensara que ellos eran tan tontos que no podían ver el maravilloso traje, y a ellos se fueron sumando todos los que se iban asomando a ver pasar al rey.

De repente, un niño pequeño vio al rey y a gritos exclamó: “¡el Rey está desnudo!”, grito al que otros niños se fueron sumando mientras los adultos se miraban y, poco a poco, todos fueron entendiendo que sus ojos no les engañaban y que el rey se estaba paseando como vino al mundo.

El Rey se percató entonces del engaño del que había sido objeto y, abochornado, se refugió en Palacio, de donde los sastres ya habían huido con su botín y, durante mucho, mucho tiempo, se mantuvo recluido en Palacio.

Aunque de este cuento podríamos sacar muchas enseñanzas, quiero centrarme en uno de sus aspectos y sus implicaciones a la hora de tomar decisiones: la búsqueda de las soluciones mágicas y la falta de cuestionamiento de los resultados obtenidos

¿Cuantas veces se os ha “vendido” el Business Intelligence como la panacea universal? “Implanta una herramienta de BI y todo irá mejor: venderás más, gastarás menos…”; así que tomamos la decisión y nos embarcamos en un proceso largo, complejo y caro, para implantar una solución de BI y, al cabo del tiempo, ponemos en marcha nuestro BI, contentos porque ya se han “puesto los medios para solucionar todos nuestros problemas”.

¡Y nos quedamos tan contentos! ya nos hemos puesto nuestro “traje mágico”, así que ya somos más “apuestos” (vendemos más, mejora nuestra imagen de marca, gastamos menos….). Accedemos a nuestros dashboards, entramos en nuestros informes….., ¿y nada más? ¿Ya hemos hecho todo lo que teníamos que hacer?

Por desgracia, muchas veces nos han vendido la tecnología de BI como la panacea universal: basta con tener una herramienta de BI y diseñar una buena solución de informes, etc, para tener la solución a todos los problemas de nuestra Organización.

Y, además, cuando, por fin, ponemos en marcha la solución diseñada, nadie la cuestiona; aunque no veamos mejores resultados, no podemos poner en cuestión el “traje nuevo del emperador” y si alguno no es capaz de ver lo maravilloso que es, será porque es “idiota”, como en el cuento.

Lo fundamental tras una decisión: medir

Mide los resultados de tus decisiones

Pero la realidad es que la tecnología de BI, en cualquiera de sus versiones, incluido el Big Data hoy tan de moda, es solo una herramienta para mejorar el proceso de toma de decisiones. ¡Pero la tecnología sola no sirve!: es una herramienta fantástica, pero si no cambiamos nuestra forma de tomar decisiones, si no medimos los resultados obtenidos, si no entramos en un proceso constante de revisión de nuestro proceso de toma de decisiones (principio Think-Act-Analyse), disponer de una herramienta de BI no nos servirá de nada…, aunque nadie se atreva a decírnoslo, como ocurría en el cuento.

Si os apetece leer más, podéis hacerlo en el post “los cinco errores más comunes en un proyecto de BI

Como conclusión: antes de poner en marcha un proyecto de BI, tened claros los objetivos, preparad vuestra organización para las nuevas capacidades, diseñad los nuevos procesos de toma de decisiones que utilizaréis con la nueva tecnología y, sobre todo, medid los resultados en vuestra gestión, analizad si es lo que esperabais y, si no lo es, volved a plantearos los objetivos y a rediseñar la solución aplicada.

Esto último, medir y evaluar el resultado obtenido, es la única forma de evitar andar desnudos mientras todo el mundo nos dice lo bonito que es nuestro traje.


Si te ha gustado esta entrada, suscríbete a nuestra Newsletter para recibir las últimas entradas del Blog.


 

 

 

Publicado en BI, Business Intelligence, Decisiones, Decisones de Negocio, Errores en la Toma de Decisiones, Gestión, Implantación BI, Implantación de un Sistema de BI, Inteligencia de Negocios, Metodología BI, Teccnologia, Tecnología para la Toma de Decisiones, Toma de Decisiones | Etiquetado , , , , , , , , , | Deja un comentario

El Proceso de Toma de Decisiones

Habitualmente, cuando hablamos de Procesos de Gestión en las empresas, nos referimos a aquellos procesos que sustentan la actividad productiva; así, hablamos de los procesos comerciales, de facturación, logísticos, productivos, etc.…y dentro de ellos englobamos el conjunto de tareas a realizar para vender, facturar, comprar o producir.

Sin embargo, en cualquier entidad se hace algo más que ejecutar procesos, realizar tareas, etc.…: se toman decisiones. Decisiones que dan sentido a esa ejecución de tareas; que permiten diferenciar a nuestra Organización de lo que hace la competencia; que aportan valor a la Compañía y, en definitiva, que hacen que la gestión de las personas sea relevante y diferencial, para cualquier compañía.

La Toma de Decisiones forma parte de los Procesos de una Organización

La Toma de Decisiones forma parte de los Procesos de una Organización

La respuesta de la tecnología al primer tipo de procesos ha venido por la vía de los sistemas transaccionales, fundamentalmente los ERP’s, es decir sistemas que facilitan la ejecución de los procesos administrativos, que ayudan a gestionar los recursos de la entidad y que garantizan una forma predefinida de ejecución del conjunto de tareas necesarias.

Sin embargo, los Procesos de Toma de Decisiones se encuentran aún en una fase inicial en cuanto a su nivel tecnológico: la Toma de Decisiones sigue estando dentro del “terreno reservado a los gestores” y a sus “capacidades innatas e intransferibles”.

Y esto es así, a pesar de la irrupción del “BIG DATA” en nuestro día a día. Si, la verdad es que nos encontramos en una situación bastante especial:

  • Por un lado, la aparición del Big Data parece que se hubiese comido a los procesos de toma de decisiones: es el mero análisis matemático-estadístico el que nos debe de dar las pautas para saber como se comportan nuestros clientes y usuarios y, en base a ello, la toma de decisiones es inmediata y, además, está obligada a seguir a lo que concluyan nuestros sistemas de análisis.
  • Pero por otro lado, los Procesos de Toma de Decisiones en nuestras organizaciones siguen siendo, en muchísimos casos, absolutamente manuales, vinculados más que nada a las capacidades intrínsecas de los propios directivos

La irrupción del Big Data ha tenido dos efectos: uno positivo, al generar un enorme ruido en las empresas que ha hecho que “todo el mundo” entre dentro del mantra del BigData -nadie puede oponerse al BigData-; otro negativo, el generar la impresión de que “todo es Biga Data”…, ¡lo que es radicalmente falso!

¿Qué diferencia el Big Data de lo que siempre hemos llamado Business Intelligence? Si tuviese que resumir la respuesta en una palabra, yo diría que “NADA”. Habrá quien se rasgue las vestiduras por atreverme a decir lo anterior, así que voy a intentar explicar mi respuesta.

Lo nuevo que aporta el Big Data es la capacidad de utilizar unas fuentes de datos inmensas (mucho más grandes de las que tradicionalmente soportaban los sistemas de BI) y, además, que en estas fuentes los datos pueden no estar estructurados, para lo que utilizan algoritmos de interpretación semántica, etc. La verdad es que, desde el punto de vista tecnológico es un gran cambio: me permite visualizar tendencias con datos que antes estaban ocultos (o no existían), conocer el impacto de determinadas acciones, saber como evolucionan mi imagen de marca y la de la competencia…., y los mil usos para los que se está utilizando el BI.

Pero esto afecta a LA TECNOLOGÍA y, en concreto a la tecnología con la que manejamos los datos, pero el Business Intelligence es algo más.

En una de las primeras entradas de este Blog, hablábamos de la diferencia entre las meras herramientas de visualización y lo que realmente debería estar detrás del concepto de Business Intelligence. Al releerlo me he dado cuenta de que, a pesar de la pujanza del Big Data, en muchos casos estamos en una situación similar a la que teníamos hace unos años: la tecnología he evolucionado, nos permite saber cosas analizando información que antes no estaba accesible (o incluso que no existía, como es el caso de las redes sociales, al menos con la pujanza actual), pero lo que nos deberían aportar los sistemas de Business Intelligence sigue siendo mucho más que simplemente el análisis estadístico de unos u otros datos. Es por ello , así que he decidido reeditar la página antigua, actualizando el contenido al momento actual.

¿Qué debe aportar una tecnología para realmente permitir la mejora en los procesos de toma de decisiones? En principio la respuesta es simple: debe ayudar a hacer lo que hace un gestor en su día a día: abstraer conceptos, profundizar en los detalles, comunicar a la organización, asignar responsabilidades, analizar información, planificar actuaciones, adoptar medidas correctivas y controlar su efectividad, ayudar en el proceso cognitivo, etc….

Requerimientos de la Tecnología de Toma de Decisiones

Cinco son los elementos fundamentales que debe tener una tecnología para realmente ayudar a los gestores en la Gestión de los Procesos de Toma de Decisiones:

  1. Debe permitir dar una respuesta adecuada a la necesidad concreta del gestor; no podemos utilizar una única “herramienta” para solucionar todas las necesidades de información de la compañía. ¿Os imagináis una organización en la que la única herramienta de ayuda a la toma de decisiones fuese un Big Data? ¿Y toda la información operativa y de gestión de la Compañía? ¿O es que ya solo vamos a utilizar tecnologías de Big Data? No nos estamos refiriendo a las “marcas” tecnológicas (yo puedo tener una marca u otra en mis sistemas), sino que hablamos de las diferentes funcionalidades del BI. Es decir, en una misma organización deberían convivir herramientas de reporting, de visullización, de análisis…., y de BigData!
  2. Dicha respuesta debe ser adecuada a las características del gestor y, por supuesto, de la Organización: la tecnología debe aportar funcionalidades de apoyo, pero no debe imponer una forma de gestionar la información. Seguimos teniendo un tejido directivo con una escasa base tecnológica y no podemos esperar cambios radicales: la tecnología debe apoyar su evolución, pero si ponemos la barrera excesivamente alta, como única alternativa, ¡muchos no podrán saltarla!
  3. Debe permitir ejecutar las diferentes funciones del proceso de toma de decisiones en aquella parte de la Organización que se desee. El Big Data nos ha devuelto al área técnica: solo grandes matemáticos, estadísticos, etc…, son capaces de interactuar con los modelos del Big Data…., pero nos olvidamos de que no son ellos quienes toman las decisiones en las organizaciones…., ¿o en vuestra organización todas las decisiones las dejáis en manos de los técnicos?
  4. La tecnología debe cubrir todo el ciclo de la toma de decisiones. Ello significa que debe incorporar utilidades, funcionalidades, herramientas, etc… para que el gestor pueda hacer esas funciones, en mejores condiciones que si no tuviese dicha tecnología. Hacemos referencia en este punto a las clásicas: Planificar, Visualizar, Analizar y Actuar y, luego, volver a analizar y volver a comenzar el ciclo, a partir de los resultados de las decisiones tomadas.
    1. En primer lugar, debe ayudarnos a planificar, a determinar a dónde queremos llegar, qué pasos prevemos, que actividades necesitaremos realizar, etc.
    2. Por supuesto, debe permitirnos visualizar en qué situación nos encontramos y, no nos olvidemos, hacerlo de la forma más adecuada a cada uno y de acuerdo con nuestras necesidades.
    3. Debe ayudarnos a analizar la información, ubicando esta capacidad en el elemento de la organización que deseemos y sin que sea necesaria una cualificación tecnológica especial.
    4. Finalmente debe ayudarnos a adoptar las decisiones, a ponerlas en marcha, a controlarlas y en su caso a rediseñarlas o a adoptar otras nuevas si no tienen los efectos deseados

      EL Proceso de Toma de Decisiones

      La Tecnología de Toma de Decisiones debe soportar todas las fases cognitivas del Proceso de Toma de Decisiones

  5. Estas funcionalidades deben ser complementadas, hoy en día, con otras básicas para cualquier gestor.
    1. La tecnología de Toma de Decisiones debe permitirnos definir qué queremos medir
    2. Debe constituirse, en sí misma, como una herramienta de comunicación y formación
    3. El tercer elemento inherente a los procesos de toma de decisiones es la gestión de responsabilidades, desde su asignación hasta el seguimiento y control de las mismas; la tecnología debe incorporar esta función, ayudando a integrarla en el propio proceso decisorio
    4. Finalmente, la tecnología de toma de decisiones debe facilitar el acceso consciente a la experiencia de los procesos decisorios previos y a los resultados de los mismos; si el proceso decisorio se basa en la información, la experiencia, el análisis previo realizado y las consecuencias de las decisiones anteriores deben formar parte de nuestros imputs básicos

En definitiva, la gestión de una entidad exige gestionar los procesos desarrollados en la misma, los cuales son de dos tipos: procesos de negocio y procesos de toma de decisiones.

La tecnología que soporte los segundos debe dar cobertura a todas las funciones básicas asociadas al proceso cognitivo decisorio, es decir debe constituirse en un autentico SISTEMA DE GESTIÓN.

En tanto en cuanto sigamos concibiendo las tecnologías de este universo como meras herramientas puntuales, el proceso de toma de decisiones seguirá limitado a las capacidades del gestor, sin permitirle aprovechar las capacidades tecnológicas existentes.


Si te ha gustado esta entrada, suscríbete a nuestra Newsletter para recibir las últimas entradas del Blog.


 

Publicado en BI, Business Intelligence, Decisiones, Decisones de Negocio, Inteligencia de Negocios, Metodología BI, Metodología Business Intelligence, Tecnología para la Toma de Decisiones, Toma de Decisiones | Etiquetado , , , , , , , | Deja un comentario

Metodologías de Desarrollo: El principio “Think-Act-Analyze” frente a los Principios Básicos de las Metodologías Ágiles

Desde que en 2013 comenzamos con este Blog, se han producido cambios -unos mayores y otros menores- en la forma de abordar los proyectos de BI y, en general, en la forma de abordar el desarrollo de aplicaciones. Quizás, el principal de ellos haya sido la consolidación de metodologías ágiles tipo SCRUM, Extreme Programming, etc..

En varias ocasiones se me ha instado a hacer una evolución hacia este tipo de motodologías, lo que nos ha obligado a revisar en profundidad la metodología utilizada en diferentes proyectos, y ver hasta que punto las metodologías ágiles son preferibles a las nuestras y donde están los puntos de diferencia que puedan ser incorporados.

PRINCIPIOS BÁSICOS DE LAS METODOLOGÍAS DE DESARROLLO ÁGILES

Probablemente los gurús de las metodologías ágiles y los equipos que las aplican digan que es una simplificación, pero creo que podríamos decir que existen tres principios fundamentales en éstas metodologías:

Metodologáis Ágiles: principios fundamentales

Principios Básicos de las Metodologías Ágiles

  • Principio del Valor para el Cliente.- Lo que hagamos debe proporcionar valor inmediato y directo a nuestro cliente.
  • Principio de Entregas Cortas.- tanto en plazo como en contenido, que aporten valor añadido frente a las necesidades concretas del cliente.
  • Principio de Equipo Integral Colaborativo.- el equipo de desarrollo es multidisciplinar y se interrelaciona y retroalimenta para aprovechar las capacidades de todos sus miembros, integrando en el mismo al propio cliente

Vamos a analizar estos principios desde el punto de vista de la Metodología BI que en diferentes entradas hemos detallado y desde la Metodología T2T (TopTo Top) que en las ultimas entradas hemos ido esbozando

El Principio del Valor para el Cliente

Que lo que se haga debe tener valor para el cliente, es una perogrullada; el matiz es que ese valor debe ser inmediato y directo, según las metodologías ágiles…, y que si no tiene ese valor inmediato y directo, no se debe de abordar.

Aun admitiendo las bondades en general de este principio, se me hace difícil conciliarlo con aspectos que consideramos fundamentales, tanto los referidos a las Fases de Análisis (como son el Análisis de Necesidades, el Análisis de la Organización o el Análisis de los Usuarios) como a las de Planificación (del Proyecto, de la Implantación…); obviamente todas estas fases tienen valor para el cliente, pero creo que no es este tipo de valor al que hacen referencia las metodologías ágiles, que propugnan un valor más concreto y tangible a nivel de programa disponible

Si consideramos que las metodologías ágiles solo abordan los principios de las fases de desarrollo estricto sin considerar el marco general, podríamos empezar a acercar posiciones.

Sin embargo, existe otra diferencia importante en nuestros planteamientos: tanto en el caso de la Metodología pura de BI como en el caso de la Metodología T2T de Desarrollo General de Aplicaciones, el “Valor para el Cliente” no es una declaración generalista que hace referencia a lo que le pueda aportar valor, sino a aquello que le ayude a mejorar en la gestión de su Organización, y esto es diferencial: las metodologías ágiles no entran a valorar el objetivo para el que trabajan; nosotros, en cambio, consideramos que, sólo con la mirada puesta en la mejora en la gestión, tiene sentido abordar cualquier tipo de desarrollo: si consideramos como objetivo del cliente las mejoras en la gestión, si que compartiríamos este principio general; de hecho, ese es el centro de toda nuestra metodología: la mejora en la gestión.

Sin embargo, nuestra Metodología va más allá y no solo mantiene ese valor para el cliente como centro, sino que lo estructura a través del Método “Think-Act-Analyze”, que envuelve toda la metodología. ¿En qué consiste este método?

1.- Piensa en lo que necesitas para mejorar la gestión, qué indicadores desearías mejorar y cómo podrías conseguirlo

2.- Desarrolla el sistema objetivo

3.- Analiza si es resultado te ayuda a mejorar la gestión; mide cómo han mejorado tus KPI’s, como ha mejorado tu toma de decisiones y si has alcanzado todos tus resultados de gestión esperados (¡ojo!, no si has alcanzado tus resultados de desarrollo previstos, sino si has conseguido las mejoras en tu gestión esperadas)

4.- Y vuelve a pensar en cómo mejorar los resultados de gestión obtenidos, o en cómo mejorar en otras áreas de gestión

El Proceso Iterativo

Think-Act-Think

Esta forma de actuar supone el cuestionamiento permanente de todo el proyecto, de todos sus resultados y, desde nuestro punto de vista, es mucho más dinámico y productivo que las metodologías ágiles, por cuanto centra el desarrollo en la mejora continua de la gestión.

El Principio de Entregas Cortas

Aunque no está expresamente formulado como tal, la verdad es que, con algunos matices, es uno de los elementos de actuación generales en nuestras metodologías. ¿Cual es el matiz fundamental?: que lo importante no es la duración sino que el resultado sea medible, que tenga sentido y que proporcione valor (es decir, que ayude a mejorar la gestión). Cuando vemos las metodologías ágiles, todas ponen el foco en el horizonte temporal: 3 semanas o 4 semanas por ciclo de desarrollo.

Está bien…., pero para nosotros, lo importante no es el plazo, sino el resultado: cada ciclo de desarrollo debe aportar un resultado tangible, concreto y que aporte valor. Además, sobre todo si hablamos de desarrollo de aplicaciones en general, es fundamental garantizar la coherencia del proyecto en su conjunto, tanto vertical como transversalmente. Es decir, seguimos manteniendo que la construcción modular en preferible a la de proyectos “macro” y que no hay que esperar a que todo esté totalmente terminado, sino que se pueden ir añadiendo funcionalidades de manera progresiva, de forma tal que el cliente vaya viendo como las nuevas entregas mejoran sus capacidades de gestión.

Que esos resultados deben ajustarse a entregas lo más cortas posibles y con resultado medible, estoy totalmente de acuerdo…, pero eso es un “además”, no el principio de la formulación.

Por tanto, de acuerdo con el principio general, pero no como principio absoluto focalizado en el eje temporal.

El Principio de Equipo Integral Colaborativo

Para analizar este principio correctamente, conviene separarlo en sus dos componentes: la parte del equipo interno del proyecto y la parte de la integración del cliente en el propio proyecto.

Respecto a la primera parte, es obvio que tener integradas todas las capacidades necesarias en cada uno de los equipos es bueno y evita sustos de final de proceso y creo que es una dé las ideas que han venido para quedarse en el mundo del desarrollo: su aplicación garantiza una mejor interacción entre todas las capacidades y, sobre todo, reduce riesgos.

La constatación de que la colaboración no puede ser solo una libertad que se otorga a los miembros del equipo, sino que debe estar institucionalizada es algo que, progresivamente, vamos incorporando a nuestros proyectos.

En segundo lugar, tenemos el aspecto de incorporación del cliente al equipo de trabajo. No solo estamos de acuerdo con este principio, sino que lo consideramos clave: es el cliente quien define qué necesita y para qué lo necesita; él es quien constata si los desarrollos tienen el resultado que preveía y quien prioriza las actuaciones. Pero además, de acuerdo con nuestra metodología, el cliente debe adecuar su gestión a los nuevos desarrollos, modificando su forma de obtener información, el uso que hace de la misma y cómo gestiona a partir de lo que le ofrece el nuevo sistema.

En el post “Elementos de un Proyecto BI: las Piezas” se desarrollan los principales roles que deben existir y dos de ellos son claramente del cliente: el líder del Proyecto y los Responsables Funcionales de Área. Ambos Roles son piezas claves, no solo para garantizar que el desarrollo encaja con lo pretendido sino, y de manera que va mucho más allá que en las metodologías ágiles, porque son los encargados de trasladar a la organización el cambio en la gestión que suponen los nuevos desarrollos.

En resumen, consideramos que las metodologías ágiles suponen un avance en muchos sentidos, aunque en otros siguen con una visión finalista del propio desarrollo y se olvidan de para qué estamos desarrollando, que, al final, siempre es para mejorar la gestión de los recursos de nuestra organización, tal y como nosotros entendemos el desarrollo de aplicaciones.

 

Publicado en BI, Business Intelligence, Decisiones, Decisones de Negocio, Gestión, Inteligencia de Negocios, Metodología BI, Metodología Business Intelligence, Metodologia Desarrollo de Aplicaciones, Toma de Decisiones | Etiquetado , , , , , , , , , | Deja un comentario

La Paradoja del Leñador y la Toma de Decisiones

Los que seguís este blog ya sabéis que me gusta trasladar cuentos populares y reflexiones filosóficas a la toma de decisiones, al BI o al desarrollo de software, los tres temas de los que habitualmente hablamos aquí.

Hoy quiero utilizar la Paradoja del Leñador como base para un par de reflexiones relacionadas con la Toma de Decisiones. Supongo que la conocéis, pero por si acaso la repito, en versión libre:

Llegó el día en que Pequeño Osezno debía decidir a qué profesión se iba a dedicar en adelante. Por ello se presentó ante su maestro:

– Maestro, estoy lleno de dudas y no se a qué debería dedicarme en el futuro

– Piensa, Pequeño Osezno, ¿qué te gustaría hacer?, ¿qué se te da bien?, ¿haciendo qué te sentirás realizado?, le contestó el Maestro

– Yo Maestro, soy fuerte y se me dan bien los trabajos físicos, contestó Pequeño Osezno

– Piensa entonces, tal vez, en una profesión manual, donde tu fuerza sea importante

– Ya sé -dijo Pequeño Osezno-, seré leñador, seré el leñador más fuerte y talaré más árboles que nadie!

Contento de la decisión tomada, se fue al bosque y se incorporó a los leñadores que a diario se encargaban de la tala y la preparación de la madera, quienes le dieron un hacha grande y bien afilada

El primer día, tras aprender las técnicas básicas, comenzó a talar y, pronto, quedó claro que su fuerza le permitía blandir el hacha durante más tiempo y  con mejores resultados que ninguno de los demás leñadores, por lo que al final del día fue profusamente halagado por el capataz y por sus compañeros, retirándose a dormir como el hombre más feliz del mundo, pues había encontrado una profesión que le gustaba y para la que valía.

La Paradoja del Leñador y la Toma de Decisiones

La Paradoja del Leñador

El segundo día, notó que su rendimiento había bajado y pensó que quizás estuviese un poco cansado del día anterior, pero como no quería que sus compañeros pensaran que lo del primer día había sido casual, redobló sus esfuerzos y alargó las horas de trabajo para conseguir talar la misma cantidad

El tercer día se levantó cansado del sobreesfuerzo del día anterior, pero se dijo a si mismo: “esto es solo los primeros días hasta que me acostumbre, pero no puedo dejar que los demás piensen que solo aguanto el ritmo un par de días”, así que se fue al bosque y atacó un grueso árbol. Si el segundo día se le hizo cuesta arriba, el tercero creyó morir: sus golpes cada vez penetraban menos en la madera y a pesar de que incrementó sus horas de trabajo, no consiguió ni siquiera acercarse a los niveles del primer día. Abatido se retiró a dormir, pensando que probablemente el cuarto día su cuerpo ya se habría acostumbrado y empezaría a coger ritmo.

Sin embargo el cuarto día comenzó aun peor: sus golpes no penetraban en la madera por mucho que se esforzara, así que, tras horas de intentarlo, abandonó las herramientas y, abochornado, salió corriendo del bosque y se refugió en la vieja escuela cayendo de rodillas ante el maestro

– ¿Qué ocurre, Pequeño Osezno?

– Soy un fracasado Maestro: no sirvo para nada; he intentado ser leñador, pero no sirvo para eso; el primer día me fue bien y talé más que ningún otro leñador, pero a partir de ahí cada día me costaba más y por mucho esfuerzo y tiempo que ponía, ¡cada vez talaba menos!

– Y dime Pequeño Osezno, ¿afilaste el hacha cada día?

– No Maestro, -respondió Pequeño Osezno-, no tenía tiempo para eso, ¡¡¡todo mi tiempo lo he dedicado a talar!!!

¿Cuantas veces nos empeñamos en hacer las cosas como alguna vez nos funcionó, sin darnos cuenta de que las circunstancias cambian? ¿Cuantas veces atacamos los troncos con el hacha que al principio nos funcionó sin reconocer que ya se ha mellado?

Cuando tomamos decisiones lo hacemos normalmente utilizando herramientas y sistemas que en otras ocasiones nos han funcionado, pero ese mecanismo, fruto de la evolución, que nos permite saber qué hacer en circunstancias que ya se han producido antes, sin tener que perder el tiempo en pensar, ¡cada vez es menos fiable en nuestra variable sociedad!

¿Qué suele ocurrir en cualquier organización?: al inicio buscamos soluciones de gestión estándar, sencillas, que nos permitan comenzar a funcionar sin grandes problemas y, poco a poco, lo que eran soluciones facilitadoras, se van convirtiendo en una losa que condicionan nuestra evolución. O bien, si hemos implantado un sistema, con su correspondiente análisis previo y bien hechas las cosas, nos encontramos con que al cabo del tiempo -si no es desde el inicio, habida cuenta de los dilatados tiempos que una implantación requiere-, ese sistema ya se ha quedado obsoleto…, pero ¡seguimos usándolo, sin cuestionarlo, sin darnos cuenta de que el mundo ha cambiado, que el mercado evoluciona a toda velocidad, que nuestra competencia cambia, que la tecnología cambia y que lo que antes nos funcionó de maravilla, ahora no es más que un freno que nos impide evolucionar!

Pero que conste que el problema no es de la tecnología, !es nuestro¡: no nos damos cuenta de que las decisiones que ayer tomamos de una forma concreta y funcionaron, hoy ya no pueden tomarse de la misma manera; el entorno cambia rápidamente y nuestra escala de valores decisionales debe modificarse si queremos sobrevivir.

Cuando llegas a un cliente que tiene implantada una solución de Business intelligence, lo más complicado es conseguir que se cuestione si esa herramienta sigue respondiendo a sus necesidades actuales y si la manera en que empezamos a utilizarla sigue siendo la mas operativa: la tendencia es a seguir usando lo que tenemos y, además, de la misma manera, aunque no nos sirva ya. Lanzamos procesos pesadísimos de desarrollo de aplicaciones y soluciones de gestión, cuando la realidad fluye a una velocidad muy superior a nuestra capacidad de reacción pero, en lugar de tratar de vivir en un mundo cambiante, nos apalancamos en nuestra situación y seguimos haciendo las mismas cosas una y otra vez, aunque los resultados cada vez sean peores.

En la Metodología que a lo largo de este blog intentamos trasladaros siempre hay dos elementos fundamentales:

En definitiva, el proceso de reflexión debe ser el desencadenante de nuestras acciones, pero una vez actuado debemos volver a reflexionar para establecer si el resultado ha sido el esperado y para volver a cuestionar la situación de partida…, para volver actuar; y, así, de manera permanente.

El Proceso Iterativo

Think-Act-Think

El cambio no es un evento pasajero que puede existir y que permite pasar de la situación A a la situación B, sino que es el único estado real; el cambio de estado es la única situación existente y debemos acostumbrarnos a vivir en el cambio si queremos sobrevivir. Vivimos en un flujo y la realidad es el flujo, no los estados intermedios.

En resumen, piensa, actúa y vuelve a pensar para volver a actuar: Think-Act-Think …, y ¡no actuéis como osos!

Publicado en Uncategorized | Deja un comentario

La Paradoja de los 6 hombres ciegos y un elefante: una reflexión en los proyectos BI

Hace tiempo publiqué en un blog con el que colaboro -Optimiza- la paradoja de los seis hombres ciegos y el elefante; en esa ocasión lo utilizaba para reflexionar sobre la necesidad de tener información antes de tomar decisiones, pero releyendolo creo que es muy pertinente si hablamos de metodologías y de la forma de abordar los proyectos de BI. Supongo que la conoceréis, pero por si acaso os la recuerdo:

“Un profesor, en clase de filosofía, se dirigió a sus alumnos: el rey de un lejano país había ido perdiendo vista, hasta que se quedó completamente ciego. No fiándose de que le engañaran los que veían, nombró asesores suyos a 6 ciegos de nacimiento.

Un día recibió en audiencia al enviado de un lejano y exótico país, el cual le dijo que le traía como obsequio seis magníficos elefantes, lo más preciado en su reino, como muestra de los deseos de amistad entre los dos reinos.

El rey, que nunca había visto un elefante ni oído hablar de ellos, pidió a uno de sus asesores que se lo describiera; acercándose al costado del primero, pasó las manos arriba y abajo y a los lados le dijo: “es una pared, majestad, rugosa y áspera en todo lo que abarcan mis brazos”

El monarca pidió al resto de sus asesores que describieran el resto de regalos; tocando una de las patas el segundo asesor la abarcó con sus brazos lo describió: “majestad, lo que os ha traído el emisario es un árbol de tronco fuerte”.

Repitió la petición al tercero de los asesores, el cual tocando uno de los colmillos se dirigió al monarca: “es una afilada lanza de punta cónica, majestad”

El cuarto se acercó al elefante por detrás,  y agarrando la cola del animal dijo: “señor, se trata de fuertes cuerdas, terminadas en flecos”

El quinto se acercó a su elefante y cogió la oreja, dirigiéndose al rey en estos términos: “parece un abanico, pero muy pesado y poco manejable, mi señor”

Finalmente, el último se acercó por delante y acertó a coger la trompa del elefante, el cual, se sacudió la presión de las manos, golpeando suavemente la cara del ciego. Este pegó un brinco hacia atrás y se dirigió al monarca: “majestad, es una serpiente y ha intentado atacarme cuando me he acercado.”

Enfadado, el rey hizo llamar al emisario del lejano reino y le dijo: “no entiendo a vuestro rey: como muestra de amistad me ofrece lanzas, muros y cuerdas para escalarlos, abanicos que no funcionan y árboles de los que tenemos millones en mi reino; y por último, camuflado en el último regalo, me envía una serpiente; ¡es la mayor ofensa que nunca nadie ha hecho a mi persona!”

Los proyectos de BI hechos a ciegas

La Paradoja del Elefante y los 6 hombres ciegos

Y diciendo esto, le ordenó que saliera de su reino y nunca más volviera a aparecer y, antes de que abandonara su presencia le entregó un cofre con piedras preciosas para que entregase a su señor.

El profesor se dirigió a sus alumnos: pensad la de veces que tomamos decisiones sin tener toda la información o basándonos en prejuicios e ideas preconcebidas; investigad las cosas, adquirir los conocimientos por vosotros mismos, no os baséis en lo que os cuenten ni en lo que digan los demás; así evitareis tomar decisiones que no sean vuestras.

¿Y por qué le envió un cofre con gemas, en lugar de cortarle la cabeza?, preguntó uno de los alumnos

Si no tenéis más remedio que tomar decisiones con lo que os cuenten, al menos no os cerréis las puertas con vuestras equivocaciones y dejad abiertas otras posibilidades para poder rectificar o corregir los errores.”

Una de fenómenos más habituales -y frustrantes- que me ha ocurrido cuando he llegado a una Organización para plantear soluciones de BI era lo que denominábamos “Situación de Tierra Quemada”: había habido un intento previo de montar un sistema de BI, pero ese sistema había resultado un fracaso. Las causas de ese fracaso podían ser múltiples: algunas técnicas (falta de respuesta, de rendimiento); otras conceptuales (no aportaban lo esperado); y otras de falta de uso en relación al coste (sistemas caros e infrautilizados).

Analizando la situación (en los casos en los que no se había enconado tanto el tema que te echaban sin darte oportunidad de intentar reconducir el tema), casi siempre se llegaba a la conclusión de que les habían vendido un sistema de BI sin preocuparse de su necesidad real: el vendedor se había preocupado de “soltarles” su producto y sus servicios, sin tener en cuenta qué necesitaban y la propia organización se había basado en lo que le decían como el rey de la paradoja: habían comprado un elefante sin saber si les servía para algo, sin saber como usarlo en su caso concreto, ni si era la mejor solución existente en el mercado.

Hemos insistido muchas veces en este blog: implantar un sistema de BI no es comprar la primera aplicación informática que nos pongan delante. Hay que cubrir una serie de pasos previos de manera obligatoria:

  • Hay que analizar la Necesidad: para qué lo queremos
  • Hay que analizar nuestras características como Organización: nuestra Cultura, como gestionamos
  • Hay que analizar cual es la mejor alternativa hoy y cual lo será en el futuro
  • Hay que hacer un plan de implantación de la nueva forma de gestionar, no solo de la implementación de la aplicación informática

Y estos pasos debe cubrirlos la propia organización destinataria…,  o un tercero independiente (si no hay más remedio)…, pero dejar que sea un tercero quien aconseje y venda la solución…, lo más fácil es que terminéis comprando un elefante para tenerlo en el jardín de vuestra Organización

Y si, por el motivo que sea no podéis hacer el proceso de una manera lógica y vais a fiaros como el rey de la paradoja de lo que os “vendan” los terceros, al menos, no os cerréis las puertas: realizar un proceso que os permita rectificar y no condenar a la Organización a una travesía en la que los sistemas de ayuda a la gestión hayan quedado proscritos

Publicado en Decisiones, Decisones de Negocio, Errores en la Toma de Decisiones, 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, Toma de Decisiones, Uncategorized | Etiquetado , , , , , , | Deja un comentario

Tres Elementos Básicos de la Metodología de Desarrollo de Aplicaciones T2T: Hilos, Roles y Conectores

La Metodología TopToTop (T2T) es un marco de referencia para realizar desarrollo de aplicaciones encajados con el modelo de gestión de la Organización. Como tal, las fases no se encuentran absolutamente cerradas y su utilización permite aplicar diferentes metodologías a partes concretas del Proyecto, siempre y cuando el esquema general y algunos puntos específicos se mantengan.

Dentro de estos puntos específicos destacan los denominados Elementos Básicos T2T:

  • Los Hilos Conductores
  • Los Roles
  • Los Conectores
Metodología TopToTop.- Elementos Básicos

Elementos Fundamentales de la Metodología T2T de Desarrollo de Aplicaciones

Hilos Conductores.-

Denominamos Hilos Conductores a aquellos conceptos que unifican la gestión de la Organización, creando el eje de referencia de toda la información, tanto operativa como de gestión.

Uno de los problemas que suelen tener todos los sistemas informáticos (y en muchos casos, la propia gestión de las Organizaciones), es la carencia de líneas claras que permitan analizar e interpretar toda la información que se produce en la Organización. La definición de cuales son dichos ejes, de como concebimos el negocio, de como lo articulamos, lo controlamos y, en definitiva, lo gestionamos, es fundamental para crear una malla coherente que facilite articular todos los sistemas que vamos a desarrollar.

Un ejemplo bastante usual de hilo conductor son las Líneas Estratégicas definidas en la Organización, o bien las Líneas de Negocio, los Sectores…., etc. Se trata de definir qué da sentido a nuestro enfoque del negocio, cómo lo entendemos, qué pensamos que es lo importante, como asignamos recursos y como valoramos la rentabilidad de nuestras acciones.

La concreción de estos elementos como Hilo Conductor supone que TODO elemento de nuestros sistemas debe estar relacionado con nuestros hilos conductores o debe contener información que permita relacionarlo con los hilos.

Un ejemplo: supongamos que hemos definido como Hilo Conductor las Líneas Estratégicas de la Organización. Esto supone que TODOS los elementos de nuestro sistema deben hacer referencia a una Línea Estratégica o hacer referencia a un elemento que a su vez haga referencia a una Línea Estratégica (LE). Ello nos debe permitir, por ejemplo, saber la rentabilidad por LE, saber la inversión, el gasto, los proyectos, las ventas, los productos, centrar nuestras inversiones, establecer nuestros nichos de mercado, definir políticas comerciales, etc….

Una de las referencias fundamentales de nuestro Sistema de Gestión, de nuestros Cuadros de Mando, de nuestro planteamiento Estratégico, etc…. deben ser los hilos conductores definidos; y nuestro transaccional debe estar organizado para permitir obtener de manera sencilla dicha información, gestionando el día a día también sobre dichos parámetros.

Los hilos conductores no son, obviamente, los únicos elementos de gestión, pero siempre deberán estar en nuestro modelo.

Roles.-

En el post Elementos de un Proyecto de BI: las Piezas hacíamos referencia a algunos de los roles que podemos encontrar en un proyecto de BI; aunque no todos los elementos que veíamos allí se van a repetir exactamente cuando hablamos de la Metodología T2T, os invito a que le echéis un vistazo.

Cuatro son los roles fundamentales que debemos contemplar en un proyecto bajo metodología T2T:

  • El Líder
  • El Director del Proyecto
  • El Responsable Conceptual de Área
  • El Responsable Técnico de Área

A) El Lider.- Es, sin duda, la figura fundamental. Su papel es cohesionar todas las partes del proyecto, sobre todo aquellas que no son estrictamente técnicas y operativas (cuya responsabilidad recaerá en el Director del Proyecto).

Ocho son sus funciones fundamentales:

  • Definir los objetivos de gestión del proyecto
  • Definir el Modelo de Gestión
  • Definir el Modelo Operativo
  • Asignar los Roles al Equipo de Trabajo
  • Establecer los canales de comunicación y los Conectores
  • Validar los entregables y los plazos
  • Validar el desarrollo realizado
  • Asegurar la Implantación del Sistema de Gestión, aprobando los valores medidos

Su misión es, en definitiva, asegurarse de que el desarrollo realizado es el que necesita la Organización para gestionar y que, una vez finalizado, realmente se gestiona con su soporte y se obtienen los datos de gestión esperados.

B) El Director de Proyecto.- Figura tradicional de todo proyecto, es el encargado de conseguir que los resultados del proyecto sean los previstos. No es por tanto el responsable de QUÉ es lo que hay que hacer (para eso tenemos al Líder), sino de CÓMO hay que hacerlo y de que se cumplan los plazos, costes, etc…., establecidos.

Conviene resaltar que el Director del Proyecto no es un mero ejecutor de lo que otros han decidido sino que debe ser parte de la solución elegida; debe haber formado parte de la solución desde los comienzos, puesto que una de sus responsabilidades fundamentales es garantizar que la solución sirve para los objetivos de gestión definidos.

C) El Responsable Conceptual de Área.- El o los responsables de área son los encargados de garantizar, a lo largo de todo el proyecto y en el ámbito de su área, que el resultado obtenido es el que se esperaba, que no han cambiado los requerimientos de gestión en el ínterin y que, si han cambiado, ambas partes -gestión y proyecto- han evolucionado de manera congruente.

Uno de los problemas tradicionales de muchos proyectos es el mantenimiento de la coherencia entre las necesidades y la evolución lógica de los proyectos (por problemas tecnológicos, operativos, de recursos…..). Ello hace que la ejecución del proyecto vaya por su lado mientras que la evolución de las necesidades (que también se produce). vaya por el suyo.

El Responsable Conceptual tiene 6 labores fundamentales a lo largo del Proyecto:

  • En la Fase de Diseño
    • Definir las necesidades de gestión y operacionales del área
    • Validar que los resultados previstos con la solución definida cubren las necesidades del área y, en su caso, planear los cambios en el área que serían necesarios para la nueva solución
  • En la Fase de Desarrollo
    • Implementar los cambios acordados en el área, para adaptarse a la nueva solución
    • Verificar que los resultados obtenidos en el proyecto cuadran con lo esperado
  • En la Fase de Implementación
    • Tutelar la implantación efectiva de la solución en su área, garantizando tanto los nuevos procesos transaccionales como de gestión.
    • Medir los resultados de gestión con el nuevo sistema; compararlos con los esperados; analizar las desviaciones y proponer acciones de cambio u mejora, tanto en los procesos como en la solución.

D) El Responsable Técnico de Área.- Para cada una de las áreas deberá existir un responsable técnico del proyecto con el objetivo de garantizar que la solución en ejecución cubre las necesidades de gestión del Área. Su enfoque será desde el punto de vista de la solución elegida, pero su labor es garantizar que los planteamientos técnicos cubren, de la mejor manera posible, los requerimientos funcionales. Dicho de otra forma, su papel dentro del proyecto es buscar la mejor opción técnica para las necesidades funcionales, tanto operativas como de gestión

Esta figura nace para evitar uno de los problemas habituales de todo proyecto: las decisiones del día a día se toman con criterios técnicos, de recursos, etc…., obviando los requerimientos funcionales (que si se tuvieron en cuenta en el diseño de la solución); ello genera que la solución que se va construyendo diverja cada vez mas de la solución conceptual diseñada. Esto, que en las primeras etapas es fácilmente reconducible, termina siendo una barrera infranqueable y el sistema termina siendo como se ha devenido en el curso del proyecto y no como se diseñó originalmente.

Corregir esta deriva y reconducir la solución tecnológica a la conceptual es la labor del Responsable Técnico de Área.

Conectores

Existen dos tipos de conectores:

  • Conectores Conceptuales.- Son aquellos elementos que conectan áreas entre si o que conectan la parte transaccional con la de gestión.

Identificar estos elementos es fundamental, puesto que son los que dan coherencia a toda la solución. Una vez identificados es necesario establecer los mecanismos que garanticen que no sufren cambios o que, si los sufren, dichos cambios se acompañan de las medidas para que, tanto a nivel de solución como de necesidades, se modifiquen las condicionen de manera que el resultado no sea peor del esperado.

Mientras que los Hilos constituían el nexo longitudinal del proyecto, podemos definir los conectores como el nexo transversal. Como ejemplo de conectores típicos podemos hablar del “proyecto”, el “área”, el “sector”, el “artículo”…., es decir aquellos elementos que existiendo en diferentes áreas de la Organización y tanto en el plano operacional como de gestión, permiten los flujos de información entre dichas áreas y planos.

  • Conectores Formales o Canales.- Son los mecanismos establecidos para garantizar que los conectores conceptuales funcionan a lo largo de todo el proyecto

Pueden ser de diferentes tipos, articulados en base a reuniones, comités, grupos de trabajo, sesiones de revisión…..

Casi todas las metodologías establecen este tipo de mecanismos. La Metodología T2T permite utilizar cualesquiera, siempre y cuando se anteponga como objetivo garantizar la conservación de los conectores conceptuales

Hilo Conductor y Conectores Conceptuales constituyen la columna vertebral y las vertebras sobre los que diseñaremos todo nuestro sistema, y garantizar su integridad a lo largo del proyecto es una de las misiones fundamentales de los Roles de la Metodología.

Para más detalles sobre la metodología T2T, podéis entrar en el post Fases de la Metodología T2T de Desarrollo de Aplicaciones

Espero vuestros comentarios sobre la Metodología T2T. En sucesivas entradas iremos profundizando en distintos aspectos de la Metodología. Si nos haceis llegar vuestras preocupaciones o dudas, eso nos ayudará a priorizar unos u otros temas

Publicado en Decisones de Negocio, Metodologia Desarrollo de Aplicaciones, Teccnologia, Uncategorized | Etiquetado , , , , | Deja un comentario