Mejora de datos maestros paso a paso (estrategia gatear, andar y correr)

Por Israel Rosales el 30 de junio de 2014

En el artículo anterior sobre datos maestros nos preguntamos sobre cuál es el estado actual de los datos maestros en nuestra organización y describimos a alto nivel las tres etapas que, de forma natural, deberíamos seguir con las herramientas Winshuttle. En este post describiremos un ejemplo real de aplicación, para ello utilizaremos un caso del sector textil. La situación de esta empresa era la siguiente:

Nivel datos maestrosMike es el mánager del equipo de datos maestros de la empresa, un equipo de reciente creación hace solo año y medio. Este equipo fue creado para aglutinar todas las tareas de la gestión de datos maestros de materiales ya que éstas fueron identificadas como un área de gran importancia para la empresa. Su equipo está formado por 4 analistas de datos que se encargan de las diferentes tareas. Con esta organización podemos encuadrar a esta empresa entre las fases “En desarrollo” y “Reactivo” dentro de los niveles de desarrollo de la gestión y gobierno de datos maestros que vimos en el post anterior.

Estacionalmente y para cada temporada han de crearse en el sistema múltiples elementos dependientes del maestro de materiales:

  • Productos terminados con todas sus vistas (básicas, ventas, fabricación, contabilidad, etc)
  • Materias primas con sus vistas
  • Listas de materiales que relacionan los productos terminados, sus materias primas y el proceso productivo
  • Condiciones de precio de los productos terminados (precio base, impuestos, descuentos, condiciones de rappel, etc)

Actualmente esta estacionalidad se reduce a “solo” cuatro temporadas que se corresponden con las estaciones, pero marketing y ventas quiere añadir subtemporadas llevando este número a ocho temporadas al año (dos por cada estación) para reaccionar de forma más ágil a la demanda de los cliente, esta estrategia ya es llevada a cabo por la competencia. Cada temporada se generan unas 1500 nuevas referencias de producto terminado, esto supone:

  • 1500 nuevos productos terminados
  • 3000 nuevas materias primas, se ha conseguido minimizar esto a una media de 2 nuevas materias primas por material gracias a procesos de estandarización entre productos terminados y colecciones
  • 2750 nuevas listas de materiales, la media es 1,5 por producto terminado ya que existen listas alternativas de producción en los diferentes centros de producción
  • 30.000 nuevos registros de condición para los diferentes tipos de condición de precio y combinaciones de las secuencias de acceso
  • Omitiremos otros elementos como ordenes de producción, etc que consideraremos transaccionales

El equipo de Mike ha de perseguir a los diferentes departamentos para que completen plantillas Excel, cada departamento se encarga de unos campos determinados. Una vez toda esta información es reunida los analistas de datos utilizan programas de carga (creados hace varios años para la migración a SAP) para realizar la carga de los diferentes objetos. Como estos programas no siempre están lo suficientemente actualizados, tienen que complementar esta acción con modificaciones manuales en el sistema.

Tanto el proceso de captura de la información como los cambios manuales se han identificado como generadores de errores en el sistema.
Además tanto producción como marketing y ventas solicitan frecuentemente al equipo de datos modificaciones masivas de cualquiera de los objetos por diferentes razones: cambios en los precios para amoldarse al mercado, cambio en los descuentos de determinados clientes, cambios en las listas de materiales o nuevas materias primas alternativas por variaciones en los procesos productivos o precios de los proveedores, etc. Estas solicitudes  de cambio adhoc son un permanente dolor de cabeza para Mike y su equipo ya que cada petición es ligeramente diferente a la anterior y los pocos programas ABAP creados para esto han sido caros y rápidamente han quedado obsoletos al no cubrir todas las necesidades.

A todo esto hay que añadir el goteo constante de peticiones de correcciones al detectar errores en los datos día a día. Actualmente el equipo está totalmente desbordado y se dedica a apagar fuegos y sobrevivir cada día. Cada nueva temporada se traduce en interminables sesiones de noches sin fin, personal subcontratado y una factura de programas ABAP que no para de crecer y que parece ser un agujero sin fondo. A esto hay que añadir las quejas del negocio ya que los retrasos y errores en los datos maestros se traducen en un impacto financiero y en errores que afectan al nivel de servicio y a la satisfacción de los clientes.

El jefe de Mike le convoca a una reunión y en ella le comunica algunos cambios:

  • Se ha confirmado que se pasará de cuatro a ocho colecciones por año
  • Estas subtemporadas no serán tan grandes como las principales pero se estima que inicialmente sean la mitad del tamaño de las actuales.
  • El equipo de datos maestros comenzará a gestionar otros dominios de datos maestros, primero clientes en tres meses y proveedores en seis meses.
  • Solo se podrá incrementar el equipo en una persona para esto.
  • Se acabó el utilizar personal subcontratado por sistema para cada nueva temporada, hay que reducir costes.
  • El presupuesto para nuevos desarrollos ABAP se restringe y solo habrá presupuesto para desarrollos o software si las herramientas suponen un aumento claro de la productividad y no como hasta ahora.

Abatido y derrumbado Mike vuelve a su despacho sin tener muy claro su futuro, pobre Mike…

Durante los siguientes días Mike dedica horas tras su jornada laboral a buscar posibles soluciones, los fuegos diarios a los que se enfrenta su equipo no le permiten hacerlo en horas normales de oficina. Finalmente a través de su grupo local de usuarios de SAP alguien le sugiere un nombre: Winshuttle.

Mike investiga en la página web de Winshuttle y analiza la solución con el equipo comercial de Winshuttle, tras varias reuniones y demos (online y en las oficinas de su equipo) Mike decide utilizar su presupuesto para programas en ABAP en adquirir licencias desktop para los miembros de su equipo de datos maestros, con la ayuda del equipo de ventas de Winshuttle Mike consigue crear un caso de negocio que convence a su jefe a autorizar el gasto. A partir de aquí los acontecimientos se suceden:

Primera fase (gatear – Desktop):
Con las herramientas de escritorio de Winshuttle, Mike y su equipo pueden generar de forma rápida y sin programación plantillas para acciones en masa en SAP, de esta forma responden rápidamente a los cambios en el negocio y cubren las cargas masivas de la siguiente temporada de forma mucho más rápida.

Las peticiones adhoc que antes requerían mucho tiempo por parte de su equipo son cubiertas rápidamente. El equipo de Mike al apagar los fuegos rápidamente empieza a pensar en evitar que estos aparezcan. Combinando las herramientas de consulta y actualización masiva entre SAP y Excel el equipo realiza tareas de limpieza y corrección en el sistema, previniendo la aparición de errores.
Todos los departamentos están sorprendidos por el cambio, la última temporada ha sido creada en el sistema sin retrasos, la calidad de los datos es mejor y cuando se solicitan cambios masivos el departamento de datos maestros reacciona con mayor rapidez. El jefe de Mike empieza a estar contento.

Los miembros del equipo de Mike ya no dedican todo su tiempo a apagar fuegos y pueden pensar en cómo mejorar su forma de trabajar y procesos, uno de ellos sugiere a Mike una osada idea:“¿Por qué no damos al negocio algunas licencias Winshuttle y que ellos realicen algunas tareas?”
Todo esto ha sucedido en menos de tres meses…

Segunda fase (andar – Workgroup):
Ante el inminente aumento del número de usuarios de las herramientas Winshuttle, Mike decide dar el salto de una implementación puramente Desktop a un tipo de implementación Workgroup. En esta se añade una herramienta de gestión documental y gobierno de Winshuttle.

Usuarios clave del negocio son identificados como autores (creadores de plantillas Winshuttle) pero de segundo nivel y los miembros del equipo de Mike serán autores de primer nivel, es decir, revisores de estas plantillas para su validación así como revisores de cada carga o modificación que se realice en el sistema productivo.

El equipo absorbe las tareas de mantenimiento del maestro de clientes como estaba previsto y esto no impacta en la siguiente subtemporada y temporada de artículos. El maestro de clientes es incluido en la misma dinámica y Mike decide no incrementar el equipo con el nuevo miembro autorizado por su jefe. Con el maestro de proveedores como futura responsabilidad en un mes, decide utilizar el presupuesto del nuevo miembro en mejorar los procesos y adquirir la plataforma Enterprise de Winshuttle.
Todo esto en menos de dos meses…

Tercera fase (correr – Enterprise): 
Ante los resultados Mike da el salto a la plataforma Enterprise de Winshuttle, con ella pone en funcionamiento diferentes workflows para controlar los procesos:

  • Varios workflows basados en Excel para controlar la recopilación de la información de cada uno de los objetos de datos de las nuevas temporadas.
  • Un workflow basado en formularios para cambios/creaciones de clientes.
  • Un workflow basado en formularios para cambios/creaciones de proveedores.
  • Un workflow basado en formularios para cambios/creaciones de materiales.

Con las herramientas sin programación de Winshuttle, un miembro del equipo y Mike (liberados de sus anteriores tareas diarias) pueden poner en marcha estos workflows en cuatro meses con algunas jornadas de servicios de un partner Winshuttle, en comparación con las facturas de los viejos desarrollos ABAP, el jefe de Mike considera esta factura “una propinilla”.

 

Madurez datos maestros

Tras finalizar estos cuatro meses Mike se para a reflexionar y analiza la evolución en tan solo nueve meses:

Antes:

  • Su equipo solo apagaba fuegos del día a día.
  • Cada nueva temporada era una pesadilla y el negocio se veía impactado por retrasos y la mala calidad de los datos.
  • No tenían control de los procesos ni tiempo de pensar como mejorar sus procesos.
  • Solo el pensar en absorber la gestión de los maestros de clientes y materiales le quitaba el sueño

Ahora:

  • Los fuegos son prevenidos e incluso si alguno aparece se apagan rápidamente.
  • Las temporadas y nuevas subtemporadas están siendo gestionadas de forma ágil y son capaces de adaptarse a los cambios en el negocio.
  • No hay retrasos al negocio y la calidad de los datos es inmejorable.
  • Con las herramientas dashboard de Winshuttle, (totalmente out-of-the-box) Mike puede analizar sus procesos workflow y detectar cuellos de botella. Al mismo tiempo al tener una herramienta de medición tan potente puede aplicar cambio y mejoras y evaluar el impacto de las mismas. Ha conseguido implementar mejora continua.
  • Sin aumentar el personal del equipo, han absorbido la gestión de los maestros de clientes y proveedores.
  • Han conseguido involucrar realmente a todos los departamentos en los procesos de gestión de datos maestros.

Mike se reclina en su silla y apoya los pies sobre el escritorio, si no fuera porque dejo de fumar hace cinco meses (y que no esta permitido fumar en la oficina), se encendería un puro y lo disfrutaría a la salud de Winshuttle.

¿Desea hacer alguna pregunta o comentario acerca de este artículo?

Continúe la conversación en Twitter usando @IsraelRosJ


Acerca del autor

Israel es licenciado en Ingeniería informática por la ETSII de Sevilla y Executive Master en SCM (Supply Chain Management) por el ICIL Madrid, escuela de negocios en la que imparte clases sobre Lean Manufacturing. Tras 10 años en el mundo SAP SCM se unió a Winshuttle en 2012 y actualmente es Enterprise Solutions manager, especialista en Lean, SCM y Datos Maestros. Cuando no está solucionando problemas de ERP, comparte su vida con esposa, hija y dos perros.


Artículos relacionados


¿Te ha gustado este artículo?

Por favor compártelo en tus redes sociales