viernes, 5 de agosto de 2016

Proyectos MDM: errores y razonamientos (y II)

13:45 by Zalakain · 0 comentarios

Continúo tras un paréntesis con el siguiente post sobre Master Data Management (MDM) y en concreto sobre los errores más
Como ya comenté en mi primer artículo sobre este tema, me he basado en un artículo de "Hub Designs" al respecto. Sobre este, hago mi visión particular del tema, donde divido los errores en errores comunes a todo Proyecto TIC y errores específicos de proyectos MDM/PIM. Toca en esta segunda parte hablar de

Errores específicos de Proyectos MDM/PIM

Si consideramos debidamente cualquier proyecto MDM habremos realizado un análisis que como mínimo nos indicará:
  • objetivo: qué es lo que queremos lograr con el proyecto; descrito en "lenguaje comprensible por todos" y con el nivel de detalle que sea preciso 
  • cómo medir el resultado: qué indicadores mirar, cómo obtenerlos y qué valores son los deseados así como los aceptables (que no tienen por qué ser necesariamente los mismos)
Esto de nuevo es común a cualquier proyecto TIC. El "añadido" que nos podemos encontrar en muchos proyectos MDM/PIM es que el propio proyecto en sí sea interdependiente de otros proyectos "paralelos" y a los cuales se dé más o menos importancia: creación de una plataforma de eCommerce, creación de una nueva Web, creación de un nuevo catálogo digital...  Si este es el caso habrá que prestar una atención adicional a los puntos de "integración/interconexión" entre proyectos y esto en ocasiones es muy complejo (por motivos como políticas de empresa/departamentos; recelos entre integradores; complejidad excesiva de alguno de los proyectos...). En estos casos podemos (¿debemos?) aplicar una metodología LEAN y lograr que la integración funcione (por cierto, qué difícil resulta encontrar en Internet referencias de LEAN que no tengan que ver con las Startup...  vale, de acuerdo que a las Startup también les aplica, y mucho, esta metodología pero ¡también a muchos otros procesos y proyectos! Simplificar, Aligerar, MVP... eso debería ser parte de las tareas de cualquier proyecto que quiera tener éxito). Si no es así, entraremos en la "typical spanish" fase de echar la culpa al otro...

Bueno, centrémonos de nuevo en lo que nos ha traído hasta aquí, los Errores específicos de Proyectos MDM/PIM que nos quedaban por comentar del post anterior. "Al lío"...

No crear un Grupo de Data Governance

Esto es un error en el que es muy fácil caer, después de todo ¿a quién le apetece que le digan que tiene más trabajo que hacer? Y no obstante es muy importante evitar este error. Porque en caso contrario más pronto que tarde nos encontraremos en una situación donde determinar cuál es el origen de los datos válido o con precedencia sobre los demás quedará en las manos de un Desarrollador que estará presionado y limitado en el tiempo para decidir y que puede o no tomar la decisión adecuada (pero que en ningún caso debe ser responsabilizado por ello). Y darse cuenta de que hay un error grave en la calidad de los datos una vez hayamos terminado el Proyecto y puesto el mismo en producción es un gran fallo, uno además con un coste elevado para solucionar (pensar sólo en el tiempo que va a llevar conseguir determinar dónde está el error...). Esto es algo que se puede solucionar si establecemos desde el principio un grupo de Data Governance, con unos participantes con conocimientos no sólo de la plataforma y del negocio, si no también de a dónde queremos que se dirija este negocio (visión de futuro) ya que podrán aportar valor que si no será necesario incorporar más adelante (y no queremos andar haciendo un proyecto MDM tras otro, ¿verdad?).
Pienso hablar más adelante sobre qué es un Grupo de Data Governance por lo que no me extenderé más por ahora en este punto. Sólo comentar dos características que debe tener:
  • Ser capaz de tomar decisiones: las reuniones de este Grupo deben ser las necesarias, de la duración precisa (y no más), y concluyentes: si se requiere una decisión, se toma y se acepta. No se trata de hacer reuniones por hacer, eternas o que no valgan para nada. Todos tenemos cosas mejores que hacer que participar en grupos inútiles.
  • Ser accesible/convocable por los PMs de todos los proyectos relacionados con los datos del MDM: si hay una "ceremonia" que dificulta a los PMs el pedir algo a este Grupo, al final no se convocará y las decisiones que se tomen en los Proyectos podrán no ser las más acertadas. Por tanto estamos poniendo en peligro el/los proyectos y colaborando a dinamitar el valor de este Grupo. 

Implantar un MDM en modo "big bang"

Este fallo por suerte parece que cada vez se da con menos frecuencia, pero aún así hay proyectos donde a pesar de carecer de todo conocimiento previo sobre qué es un MDM, para qué sirve, cómo usarlo mejor, etc. se decide que la implementación sea un "big bang", un cambio radical y completo de toda la gestión previa de los datos en una empresa.
Esto desde luego que generará ruido, y también con mucha probabilidad hará "explotar" todo... en el mal sentido.
Demasiadas veces nos encontramos con numerosas dificultades en los proyectos que desaconsejan esta aproximación. La principal de ellas es la diferencia lingüística (que no de idioma, que esa puede ser otra...) entre Negocio y Desarrollo/Sistemas. Lo que un departamento entiende por "dato maestro" puede no tener nada que ver con lo que entiende otro. Y esto muchas veces se deja en manos de Consultores que tienen una enorme carga de trabajo y un tiempo muy limitado para desarrollarlo, por lo que para cuando se detecta que esto es un problema y se pretende corregir ya es demasiado tarde: un modelo de datos malo y no adecuado a la tarea que se precisa; un diseño de la solución que no se beneficia de las ventajas que la plataforma MDM aporta; una complejidad excesiva en todos los casos para acomodar situaciones "y si", etc. En definitiva, una solución pobre y mal implementada, que como poco causará animadversión a los usuarios.
La solución a este problema en realidad son dos posibilidades:
  • pasar muchísimo tiempo en la fase de Análisis del Proyecto si contamos con un equipo de Consultoría experimentado y capaz (en caso contrario, es mejor no intentar este camino), con la esperanza de que se llegue al nivel de entendimiento perfecto entre las partes y se diseñe y realice una buena solución MDM ("safe & sound").
  • o ser realista y aproximarnos al desarrollo de la solución de una manera cíclica, que permita aprender según se va avanzando y lograr el mejor valor posible de la solución en cada momento del ciclo de vida del proyecto. ¿A alguien le suena esto a Metodologías Ágiles? Exactamente, esa es la idea. Una aproximación tipo SCRUM o incluso Kanban al proyecto puede lograr que el resultado final sea mucho más satisfactorio que hacer un "big bang". 

Considerar sólo una dimensión


Por último, aquí entramos en la parte más "analítica" del proyecto MDM, en la que nos debemos plantear qué datos tenemos, cuáles queremos gestionar, cómo son (qué información contienen), cómo interactúan entre ellos, y cómo queremos acceder a los mismos. Por supuesto que todo esto desde dos puntos de vista: cómo lo hacemos actualmente y cómo querríamos hacerlo.
Y aquí es donde entran las distintas "dimensiones" de las que hablamos. Es decir, si nos planteamos un proyecto MDM sólo desde un único punto de vista (por ejemplo, manufacturing) tendremos el problema de que aunque la solución satisfaga éste no podremos fácilmente satisfacer otros que añadamos posteriormente (p.e. marketing; o web; o mobile...) si no los hemos pensado antes e incorporado sus requerimientos al diseño de la solución MDM. Esto en sí es un proceso complejo y creo que justifica por sí sólo la existencia de una fase de "Análisis MDM" en el proyecto, que se ocupe de trabajar con todas las dimensiones que haga falta, con la suficiente importancia y alcance como para garantizar unas mínimas capacidades "multidimensionales" a la solución desarrollada.
En caso de no hacerlo, tendremos el problema de que lo que se haya implementado, por bien que se haya hecho (y seguramente caro), no va a ser la solución que sirva para otras necesidades de la empresa. Y esto hay que evitarlo a toda costa, se trata de implementar proyectos MDM sólidos, duraderos y estables (al fín y al cabo, en muchos casos van a ocupar el lugar de los antiguos OS/360, que aunque "feos" pueden perfectamente definirse con esas palabras).

Y hasta aquí mis comentarios sobre estos errores en proyectos MDM. Espero haber aportado algo al respecto, y desde luego estaré encantado de cualquier opinión sobre el tema.

viernes, 24 de junio de 2016

Proyectos MDM: errores y razonamientos (I)

14:13 by Zalakain · 0 comentarios

Comienzo con este post a escribir sobre el tipo de sistemas con los que trabajo actualmente, los sistemas MDM (Master Data Management).

Recientemente leí un artículo que trataba sobre las "8 peores prácticas en Master Data Management y cómo evitarlas" escrito por "Hub Designs". Me parece un tema interesante y quería aportar mi propia visión sobre el tema, ya que por desgracia después de tantos años los Proyectos Informáticos siguen tropezando en las mismas piedras...

La visión que daba el artículo, si lo traducimos al castellano y lo simplificamos es esta:


En general estoy de acuerdo con los errores que se detallan, pero he realizado una pequeña modificación: los círculos en naranja representan errores comunes a todo proyecto TIC mientras que los azules tratan de errores específicos de proyectos MDM/PIM.

Veamos más en detalle cada uno...

Errores comunes en proyectos TIC (IT)

La gestión de los proyectos TIC, y casi de cualquier proyecto, es una tarea muy compleja como bien saben mis amigos del Asociación Navarra de Gestión por Proyectos. La toma de requerimientos, la gestión de los recursos, los plazos... son tareas que pueden resultar enormemente complejas y requerir mucho esfuerzo, y que si no se llevan a cabo correctamente darán al traste con el proyecto.
Lo que sí conocemos y de lo que voy a hablar aquí, son una serie de errores que si no los corregimos pronto harán que nuestro proyecto fracase sin importar el esfuerzo que dediquemos al resto de tareas. (Aclaro que entiendo por "fracaso" el hecho de que un proyecto no se reconozca como éxito o beneficioso, a pesar de que se haya entregado por completo, en tiempo y en costes; vamos, que si no nos reconocen el resultado ¿para qué hemos trabajado?)

Olvidarse del caso de negocio

O, dicho de otra manera ¿para qué estábamos haciendo esto? Aunque parezca mentira, a veces los proyectos desarrollan soluciones que no son lo que se necesitaba o no solucionan completamente el problema que se pretendía solucionar. Sobre esto, las Metodologías Ágiles como SCRUM ayudan enormemente a no cometer este error ya que siempre se mantiene el foco en lo que el cliente quiere solucionar en todo momento. De este modo el resultado es lo que el cliente espera (y por tanto supondremos que es lo que le soluciona sus problemas :) ). Otra técnica, más simple y que no implica necesariamente cambiar el proceso de desarrollo que tengamos implantado, es la metodología Lean y sobre todo el concepto de Producto Mínimo Viable un concepto que debería ser obligatorio en todo desarrollo software y que comprendí mucho mejor de la mano de expertos como Mario López de Ávila o Rodrigo Corral: (simplificando el concepto muchísimo) desarrolla la solución necesaria mínima, e itera sobre esta.
En cualquier caso, hay que tener siempre presente lo que buscamos solucionar y asegurarnos de hacerlo, sin florituras. El resto, para más adelante.

Sin Sponsor ejecutivo

Esto es un problema que demasiadas veces se obvia en los proyectos, y luego causa enormes dificultades: ¿quién es la persona (o personas) dentro del cliente que apoya este proyecto y tiene capacidad para hacerlo? Si no la hay sinceramente sería mejor no realizar el proyecto. Porque cuando haga falta buscar aprobaciones, información, respuestas, apoyos, formalizaciones, firmas... si no existe esta figura vamos a tener que perder mucho tiempo (y dependiendo del cliente puede ser mucho-mucho...) y esfuerzo para conseguir algo que debería ser muy simple.
Esto, que puede parecer trivial, nos va a causar dos problemas mayores:
  • Si somos estrictos en nuestros requerimientos, va a causar retrasos y más retrasos en el proyecto (que potencialmente podrán encima ser achacados a la tarea del PM...)
  • Y como PMs tenemos muchas otras tareas en las que dedicar nuestro esfuerzo y nuestro tiempo. Soportar estos temas es más que probable que nos cause una percepción negativa del proyecto.
Por tanto, aunque parece algo trivial este error nos puede causar unos problemas muy graves. Así que lo trivial debería ser determinar esa figura.

Tecnología errónea

Esto sí que está claro, sin duda :) El elegir una tecnología errónea para una solución nos va a dar muchísimos dolores de cabeza. En ocasiones no es fácil o posible conocer de antemano qué es lo que nos interesa más, por lo que se hace preciso realizar un buen análisis de las soluciones existentes para conocer cómo solucionarían el problema concreto.
Además, también es muy conveniente tener en mente una visión amplia de hacia dónde queremos que evolucione en el futuro nuestra solución o plataforma, de tal manera que no nos quedemos "atados" a sistemas legacy o con muy poco recorrido a futuro.
Aquí me permito hacer una pequeña "cuña publicitaria": STEP de Stibo es la mejor solución de MDM del mercado, para ambos puntos ;) 

No planificar el cambio organizativo y cultural

Esta es una parte que los programadores "de siempre" hace años pensábamos: "ya se adaptará el usuario y si no que aprenda". Y aprendimos a las duras que eso no es así, y que encontrarnos con un grupo de usuarios finales que hecha pestes del proyecto no es bueno, y trae problemas...
Así que hay que preocuparse de esto debidamente, planificarlo, desarrollarlo, etc. como un subproyecto del proyecto, con su propio PM si es preciso, recursos, tiempos, etc... 
El asegurarnos de que el usuario final entiende y conoce cómo utilizar nuestro desarrollo es una parte esencial si luego queremos lograr ese reconocimiento del resultado. En esto un proyecto es como cualquier otro negocio: si entregas algo mal y sin instrucciones claras lo más posible es que no te valoren "5 estrellas"...

Sin métricas para evaluar el resultado

Este es el último de los problemas "genéricos" de cualquier proyecto, el que podemos traducir como "ni sabemos dónde estamos ni dónde queremos llegar". Y es que en muchas ocasiones (demasiadas) los proyectos nacen de una "idea feliz" o impresión sobre que algo es necesario, pero no se sabe muy bien ni por qué ni para qué. Sólo unas métricas adecuadas (y nunca "impresiones") pueden aclarar esto debidamente. Y siempre es posible determinarlas. Todo software proporciona valores o datos que son medibles. Toda actividad de una persona puede representarse de acuerdo a algún parámetro que se puede medir. Por tanto, por complicado que parezca esto, es posible. Y muchas veces nos encontramos con que los proyectos no se miden de ninguna manera más que por el tiempo y el coste de los mismos. ¿Y qué hay del resultado?
Por eso las métricas son necesarias, para conocer y documentar lo qué se ha hecho y por qué se ha hecho. Y en consecuencia que se reconozca el éxito del proyecto.


Hasta aquí esta entrada, en la próxima me centraré en los errores más "puros MDM". Espero haber aportado un poco sobre este tema, y por supuesto que cualquier comentario, crítica u opinión es más que bienvenida. Entre todos mejoramos :)