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.