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

Fases de la Metodología TopToTop (T2T) de Desarrollo de Aplicaciones

La Metodología TopToTop o T2T unifica el desarrollo de aplicaciones con la gestión de la Organización; parte de la concepción de la Organización, de la definición estratégica del negocio, de cómo se quieren articular las relaciones con los terceros y la gestión interna y de cómo se entiende el proceso de toma de decisiones; a partir de ahí se definen los procesos operativos, los roles y responsabilidades, la casuística a soportar y su repercusión en el plano de gestión y estratégico y se desarrollan; finalmente se articula el plano de gestión a partir del operativo y se va redefiniendo el operativo según los requerimientos del de gestión.

T2T no es por tanto una metodología más de desarrollo (de hecho no cuestiona ni normaliza las fases propias del desarrollo), sino que entra en el concepto mismo del para qué estamos desarrollando una aplicación y tiene por objeto eliminar las barreras entre las aplicaciones de gestión y las transaccionales.

Vamos a poner un ejemplo para que se vea, de manera práctica, en que consiste esta metodología; vamos a imaginar un caso ficticio: diseñar un sistema de gestión de almacenes.

En condiciones tradicionales analizaríamos los procesos de negocio que hay que montar (entradas, salidas…); la información a controlar (roturas de stocks, plazos de entrega…) y diseñaríamos los informes operativos.

Con la Metodología T2T empezaríamos por preguntarnos para qué queremos los almacenes (para poder servir pedidos a los clientes, para producir…..); supongamos que es para servir pedidos a los clientes. Si esto es así, deberíamos pensar si el tipo de cliente al que vamos a servir influye en la gestión de nuestros almacenes, o si es el tipo de producto, etc…Imaginemos que la respuesta es que el cliente o el tipo de cliente debería influir, porque no tiene la misma importancia el pedido servido a un cliente que a otro, dado que el riesgo de un fallo a un cliente importante es crítico, mientras a otro…., pues no deja de ser un pequeño problema. A partir de aquí empezaremos a analizar cómo son las relaciones dentro de la Organización, con los terceros….., hasta que tengamos claro cómo debería funcionar nuestra gestión de almacenes para nuestra Organización; y esto, será diferente en nuestra Organización de como sería para cualquier otra, porque nosotros vamos a gestionar, a priorizar intereses, a tomar decisiones en base a aspectos internos nuestros, que son los que nos hacen distintos de nuestra competencia. Imaginaos que fruto de todo lo anterior terminamos decidiendo que lo que tendría sentido es montar nuestro sistema de almacenes organizado alrededor del concepto cliente…. (curioso, ¿no?)…., y lo ponemos en marcha, y desarrollamos el sistema transaccional y obtenemos información para gestionar el almacén como hemos definido: por los clientes. A lo mejor el supuesto que acabamos de hacer y el resultado al que hemos llegado es absurdo…., pero quizás eso sea lo que realmente necesitaría para mi concepción de mi empresa, para mi cultura corporativa y para generar algo con un valor diferencial del resto de mi competencia!

Así, mientras que cualquier metodología de desarrollo tradicional se basa en los procesos y los flujos de información, T2T se basa en para qué voy a usar la información y cómo la vamos a usar; es decir, es una metodología finalista: vamos a crear un sistema para gestionar X de acuerdo a cómo entendemos la gestión de nuestra Organización…, y esa forma de entender la gestión es propia de mi organización y de ninguna otra.

Esto es lo que pretende la metodología: crear un ecosistema de desarrollo en el que el inicio y el final de la cadena sea la gestión propia de la Organización y todo cambio sea analizado, medido y aprobado en función del impacto en la gestión.

FASES DE LA METODOLOGÍA T2T

La metodología T2T tiene tres grandes etapas:

  1. Definición del Sistema
  2. Desarrollo del Sistema
  3. Implantación de la Solución
Fases Metodología TopToTop

Fases Metodología T2T de Desarrollo de Aplicaciones

Vamos a entrar en cada una de ellas, teniendo en cuenta que la metodología específica de cada etapa no está cerrada, pudiéndose adaptar según el caso concreto. A pesar de ello existen tres tipos de elementos que si son intrínsecos a la Metodología T2T y que siempre deben mantenerse:

  • Los Hilos Conductores.- Son las líneas maestras que definen Qué es nuestra Organización y Cómo queremos gestionarla
  • Los Roles.- Aspectos y Responsabilidades que deben existir dentro del proyecto para garantizar su correcta ejecución
  • Los Conectores.- Líneas transversales que enlazan la gestión con la operativa a lo largo de todo el Proyecto

Para mayor detalle de estos tres elementos, os remito al blog Tres Elementos Básicos de la Metodología T2T: Hilos, Roles y Conectores, donde podréis encontrar una descripción mucho más exhaustiva de su significado y funcionamiento

Pero antes de entrar con el detalle vamos a hablar de la característica básica de la Metodología: la Validación Multidimensional. La Validación Multidimensional es el proceso por el cual cualquier Etapa/Bloque/Fase/Actividad o Tarea realizada es chequeada con el resto tanto vertical como horizontalmente, tanto en el plano operativo como en de gestión. Dado que estamos haciendo un desarrollo operativo enlazado con la gestión de la Organización, debemos garantizar que esta coherencia se mantiene a lo largo de todo el proceso. Para ello utilizaremos los Hilos Conductores y los Conectores.

La Validación Multidimensional en TopToTop

La Validación en T2T

Etapa 1.- Definición del Sistema

Objetivo:

Establecer qué es lo que queremos gestionar, cuales son los requisitos para la gestión, cuales los operativos, quienes intervienen y con qué roles; en base a qué se quiere gestionar y qué información se necesita; definir los “que pasa si” y sus respuestas; analizar los procesos operativos y de gestión actuales y, en su caso, rediseñarlos.

Si, habéis leído bien…., “rediseñarlos”. ¿Pero no íbamos a hablar de metodologías de desarrollo, me diréis? Si, pero automatizar procesos defectuosos es la mejor manera de garantizar que el resultado no sirva…., y a nosotros eso no me sirve para nada; así que si, una vez revisemos el sistema que queremos gestionar, vemos aspectos que no están bien…., pues habrá que remozarlos antes que nada.

Cuatro Fases deberemos considerar durante la Definición del Sistema:

 Fase 1.1.- Análisis de la Organización

Sea cual sea el Sistema que vamos a desarrollar es imprescindible que conozcamos cómo es la Organización en la que va a operar. Aspectos como la Cultura de Empresa, el Proceso de Toma de Decisiones, el sistema de Delegación, los Canales de Comunicación formal e informal, el nivel de Tecnificación, las Barreras al Cambio y el Papel del Área de Tecnología, entre otros, son claves para entender cómo debe ser cualquier sistema de gestión.

Dado que en otros post y paginas de este blog se hace referencia a la importancia de todos estos aspectos y a la forma de analizarlos y enfocarlos, no insistiremos en esta fase.

En esta fase, además, deberemos definir cuales son los “Hilos Conductores”, qué “Roles” deben existir y cómo van a funcionar los “Conectores”.

A lo largo de cada una de las fases, revisaremos los tres elementos básicos (Hilos, Roles y Conectores), asegurando la coherencia a lo largo de todo el proceso de definición: en esta fase definiremos cuales son los Hilos, qué Roles deben funcionar y quienes deben asumirlos y qué Conectores va a permitirnos garantizar la coherencia transversal; en cada una de las fases de la Etapa 1 revisaremos si lo definido es coherente con estos elementos y si los mismos nos van a permitir trazar todo el proyecto.

Fase 1.2.- Definición de la Información de Gestión

¿Cómo entendemos el negocio?¿Cómo vamos a gestionarlo?¿Qué es importante para poder tomar decisiones? En esta Fase vamos a definir que necesita nuestra Organización para Gestionar el Área cuyo desarrollo estemos haciendo; vamos a pensar qué tipo de información nos gustaría que nos proporcionase el sistema y porqué; cómo orientaríamos la gestión en base a dicha información, quien tomaría las decisiones; cómo mediríamos los resultados de dichas decisiones….

Vamos a seguir con el ejemplo de los almacenes: si hemos dicho que lo fundamental es el cliente al que servimos, deberíamos contar con informes específicos que me digan (por cliente, por tipo de cliente, categorizado de 20 formas distintas), los tiempos desde que hace el pedido hasta que se sirve; el impacto que dichos plazos tiene en la repetición de los pedidos; si existen diferencias (para ese cliente) entre retrasarnos en un tipo de productos o en otros; si puedo negociar diferentes condiciones comerciales en función del funcionamiento del almacén; cómo influye la gestión del almacén en mi volumen de ventas; cómo en mis márgenes…., etc…

Pero no sólo lo vamos a pensar…, deberemos definirlo, diseñar los flujos de información, quien va a tomar las decisiones y en base a qué, como vamos a medir el resultado de las decisiones tomadas…..Es decir, definiremos los procesos de gestión derivados del nuevo sistema.

Fase 1.3.- Definición del Sistema Transaccional

Bueno…., éste es el más obvio: deberemos diseñar nuestro sistema transaccional…, solo que en lugar de fijarnos solo en los procesos transaccionales, vamos a partir de nuestras necesidades de gestión: ¿qué necesitamos, cómo lo necesitamos y para hacer y conseguir qué?

Esta fase, quizás la más sencilla en teoría, exige revisar aspectos habitualmente admitidos sin cuestionarlos; ello implica utilizar lo que denominamos Actitud de Base Cero, llamada así en referencia a la metodología de presupuestación.

¿Qué es la Actitud de Base Cero? Es aquella actitud que nos permite cuestionar desde cero cualquier aspecto de nuestro transaccional. Es decir, nos olvidamos de todos los aspectos predefinidos, que, por ejemplo, tienen todos los sistemas, y nos planteamos qué, cómo, para qué, por qué, cuando, donde y quien debe hacer todas y cada una de los requisitos operativos, así como la mejor solución tecnológica para abordarlos.

Aunque en teoría esta actitud también sería aplicable a la fase de definición del sistema de gestión, en ese caso damos por buena la definición de las necesidades que tengamos como planteamiento de partida, aunque también utilizaremos ABC para el diseño del sistema.

Fase 1.4.- Diseño de la Implantación

Implantar un sistema diseñado con T2T afecta a la gestión de la Organización. No es por ello un tema baladí, sino que deberemos diseñar, planificar y organizar todo el proceso, desde los aspectos técnicos y los procedimientos operativos hasta los procedimientos de gestión.

Además, deberemos definir cómo vamos a medir los resultados, tanto los que tenemos antes del nuevo sistema como los que obtendremos como consecuencia de la implantación del sistema.

Etapa 2.- Desarrollo del Sistema

La Metodología T2T no entra en la metodología de desarrollo propiamente dicha, dado que existen muchas en el mercado y que la aplicación de una u otra depende, en muchos casos, de aspectos normativos internos de la Organización de que se trate (posiblemente realizaremos un post en el que resumamos los hitos fundamentales de desarrollo, pero solo a modo de guía básica).

Sin embargo, existe media docena de principios generales o puntos a tener en cuenta y que deberán ser integrados en cualquier metodología:

  • Los Requerimientos del Sistema pasan a un segundo plano, anteponiendo los Requerimientos de Gestión. Esto es, nuestro punto de partida es lo que necesita la Organización para gestionar como se ha decidido que se quiere gestionar; a partir de ahí definiremos los requerimientos del sistema de gestión y, finalmente, los requerimientos del sistema transaccional…., y a ellos condicionaremos los desarrollos
  • El Sistema de Gestión es prioritario; a él se deben supeditar los procedimientos operativos. Todo desarrollo empezará en la información de gestión y se validara con ella. Modificaciones en la información de gestión objetivo exigen la revisión de todo el proyecto.
  • La metodología elegida debe integrar los tres elementos básicos:
    • Respetar los Hilos Conductores.-
    • Gestionar las responsabilidades en base a los Roles
    •  Revisar que se mantienen operativos los Conectores, sean cuales sean los Canales establecidos en la metodología.
  • Aplicar la Validación Multidimensional a toda de decisión de cambio que se produzca, llegando hasta los requerimientos de gestión y al impacto en la implantación y analizando las interacciones en cualquier área colateral.
  • Las modificaciones, sean por la causa que sean, deben ser aprobadas por el Responsable Conceptual del Área afectada y por el Líder del Proyecto, tras el análisis de impacto en la gestión
  • Una vez aprobada una modificación es obligatorio rediseñar el proceso de gestión final y revisar los mecanismos de transición desde la situación actual al momento en que se cuente con el sistema operativo.

La Metodología T2T constituye el marco en el que se inscribe cualquier metodología tradicional, da lo mismo que utilicemos las habituales que las metodologías Agiles. Todas ellas son admisibles, dentro del marco T2T.

Etapa 3.- Implantación del Sistema

Modificar la Gestión de la Compañía, adecuando la información disponible al Modelo de Gestión es el objetivo de la metodología T2T. Por ello, la implantación del Sistema desarrollado es la fase fundamental de T2T.

Quizás debería empezar por definir lo que entendemos como “implantación” en T2T: es el proceso por el cual la gestión de la Organización mejora a partir la utilización de un nuevo sistema de información

Es decir, en T2T la implantación de un sistema no es su puesta en marcha, sino la consecución de un cambio en los indicadores de gestión.

Vamos a seguir con el ejemplo: hemos dicho que desarrollamos un nuevo sistema de almacenes para mejorar el nivel de satisfacción de nuestros clientes y, por consiguiente, su fidelidad, su volumen de compras y su rentabilidad.

La implantación del sistema contendrá la puesta en marcha del nuevo sistema de almacenes, pero eso es solo una parte: es necesario montar el nuevo sistema de gestión que permita aprovechar la mejora en los almacenes como una forma de incrementar la satisfacción de los clientes, aumentar su volumen de compras, etc…; y eso no se consigue simplemente implementando un sistema: hay que cambiar la forma de gestionar a los clientes, haciendo que es sientan más satisfechos y haciendo que dicha satisfacción repercuta en sus volúmenes de compra, etc. Y eso hay que medirlo; hay que comprobar si ese efecto se consigue y si no, analizar caso por caso porqué no y poner en marcha las medidas para reconducirlo (sean estas organizativas o tecnológicas)

La Implantación de un Sistema tiene tres actividades que se simultanean en el tiempo:

  • La implementación del Sistema.- Su instalación, configuración, formación a técnicos y usuarios, la puesta en marcha, el apoyo en los primeros tiempos….; en definitiva las tareas clásicas de una puesta en marcha de una nuevo sistema y en las cuales no vamos a insistir mucho más
  • La implementación del Nuevo Sistema de Gestión.- Si, porque si hemos desarrollado un nuevo sistema es porque queremos cambiar el sistema de gestión de nuestra Organización y ello requiere poner en marcha nuevas actividades, nuevos métodos, nuevas formas de gestionar

Imaginemos el ejemplo anterior: si ya tenemos un sistema de almacenes que nos permite gestionar los plazos de servicio en función del cliente, habrá que incorporar como una de las condiciones de nuestras contraprestaciones dicho plazo, ¿no?, y, por ejemplo, dar mejores plazos a los clientes más rentables, etc… Ello exige incorporar el plazo a nuestra forma de gestionar, de elaborar las ofertas, de establecer los precios, de hacer el seguimiento…. Y eso hay que implantarlo, no surge de forma espontánea en la Organización.

  • La Medición.- cuando diseñamos el sistema hemos dicho que empezamos por analizar qué queríamos conseguir, qué objetivos de mejora en la gestión estaban detrás del nuevo sistema a desarrollar….., pues ahora es el momento de medir si estamos generando más valor, si hemos alcanzado las metas fijadas en los diferentes KPIs, si, en definitiva, el sistema sirve para lo que lo hemos diseñado

Hasta aquí esta primera introducción a las fases de la Metodología T2T. En entradas posteriores iremos analizando aspectos concretos de la misma. Si tenéis curiosidad por algún tema, decídnoslo e intentaremos aclararlo.

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

La Metodología TopToTop (T2T): 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 , , , | 1 Comentario

Los 5 errores más comunes en un proyecto de BI; no te olvides de evitar el 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