Premortem de un CDP: 10 aprendizajes antes de implementar un Customer Data Platform.

Una definición formal presenta a un Customer Data Platform (CDP) como una herramienta que centraliza y unifica los datos de clientes de múltiples fuentes para ofrecer una visión completa y coherente del cliente.

En la mayor parte de las conversaciones, la definición que se ofrece es “una coctelera en la que metes todos los datos del cliente y sirves a cada equipo aquello que quieren consumir” y esta falta de precisión no es por desconocimiento de los diferentes interlocutores, es por la importancia que tiene poder crear un entendimiento o visión compartida porque, en la implementación, no son tantos los problemas de datos, sino todo lo demás.

Trabajar con metáforas en implementaciones técnicas ayuda a que todos los equipos puedan comunicar los objetivos, frenos, implicaciones y dependencias y especialmente en proyectos con un alcance tan transversal.

A medida que avanza el proyecto y ya se forman los equipos de trabajo, el valor de las metáforas se relega en pos de las especificaciones de los entregables, si bien, vuelve a ser importante su uso en las sesiones de check in o demos cross departamentales.

Primer aprendizaje del premortem: no hacer esfuerzos en comunicar de una forma inclusiva puede dejar fuera a agentes fundamentales.

Un gran reto al crear un equipo de trabajo para un assessment de un CDP se hereda de la propia configuración del equipo de trabajo. Equipos de tecnología, negocio, legal o cliente tendrán diferentes aproximaciones a las oportunidades y retos de implementar un CDP, así como tiempo, conocimiento y necesidades a corto plazo y en este caso no se diferencia de la implementación de un proyecto de alta complejidad, requiere un sponsor, un outcome, un owner, las voces de los diferentes departamentos y un timebox en el que se defina la primera parte del proyecto.

El outcome de esa fase es explicar a los diferentes interlocutores el potencial impacto, las dependencias que puedes tener, las oportunidades y transmitir la “paz mental” de que no se van a tomar decisiones. Dentro de esta fase, una matriz RACI es una buena herramienta para asegurar a todos los miembros del equipo que todas las decisiones que se tomen en el futuro van a estar refrendadas por ellos, aunque hayan estado desconectados durante un tiempo.

Un timebox para este proceso es importante para no perderse en el proceso ni entrar en tomas de requisitos muy específicas.

De esta fase han de salir ya los interlocutores que formarán parte del proyecto.

Segundo aprendizaje: recoge todos los pains internos de los interlocutores al principio del proyecto y cierra procesos para informar y consultar.

Me lo agradecerás más adelante 😉.

Tercer aprendizaje: el owner del proyecto tiene que tener muy claro su rol como responsable de gestionar esos pains.

Con el equipo formado y los objetivos del proyecto identificados, se abren diferentes caminos en función de los equipos que han liderado la iniciativa. Frecuentemente, equipos técnicos tienden a abordar el proceso desde el inventariado de las fuentes de datos, mientras que equipos que se identifican con negocio y data mantienen el foco en el outcome que se tangibiliza en los casos de uso y una matriz de priorización.

Cada camino presenta limitaciones diferentes. El proceso que parte desde el inventario de fuentes de datos en muchos casos simplifica una prueba de concepto, mientras que el proceso diseñado desde los casos de negocio crea mayor tracción, adherencia entre los interlocutores, lleva a casos de uso con mayor creación de valor y requiere en contraposición una capacidad de abstracción mayor y una confianza en el compromiso y capacidades técnicas de la empresa.

En aquellos casos en los que se ha hecho el kick off ampliado con los diferentes responsables de área, el trabajo en paralelo es muy eficiente, si bien, es muy recomendable gestionar el inventario de fuentes de datos con una plantilla que facilite posterior integración.

Cuarto aprendizaje: la comunicación de planificación, entregables y decisiones se debe comunicar desde el primer momento.

El outcome del proyecto nunca es implementar una tecnología o lanzar una campaña. La métrica de éxito suele tener una vertiente económica, decantada en métricas de cliente (nps, churn, upsell), métricas de adquisición (CTR, CPA, CAC) o métricas de eficiencia (Time to purchase u otros SLA) y esta reflexión es fundamental antes de empezar a tantear tecnologías, ya que en muchos casos hay formas más sencillas de llegar a esos objetivos y, desde luego, más económicas.

Quinto aprendizaje: enamorarse del problema y no de la solución es un error, puede que un CDP no sea lo que necesitas.

Una vez que persigues el outcome (y esto vale también para las diferentes alternativas a los CDP), es fundamental entender cómo son los flujos de información que tu empresa va a activar y los diferentes puntos de integración.

1. Para brick and mortar, soluciones como Wapping pueden ayudar a proyectar la atribución multi distribuidor en un proceso de venta (pudiendo establecer sistemas de fidelización, multi distribuidor).
2. Para banco o plataformas en las que el control de flujos de información es fundamental, Tealium aporta diferentes soluciones de control a través de sus diferentes sistemas de gestión de tags.
3. Para entidades con equipos más pequeños que quieren poder ejecutar modelos de propensión directamente en la plataforma, Treasure Data es una buena solución.
4. En aquellos casos en los que la empresa ha desarrollado un datamart centralizado y gobernado, un Census o Hightouch facilitan la integración, acelerando el time to value.

Cada plataforma tiene una ^^propuesta de valor y escala** en función de diferentes parámetros (POS, Eventos, Integraciones, módulos)... y a todo eso hay que sumar los modelos de comisionamiento de los diferentes implementadores. Una proyección de los gastos fijos y variables en este punto puede simplificar la decisión.

Sexto aprendizaje: entender las reglas de implementación, gasto y mantenimiento a futuro es fundamental.

Es frecuente en este momento que las diversas soluciones tecnológicas hagan una intro con los socios implementadores de cada país y, en muchas ocasiones, has introducido a otro agente comercial dentro de tu proceso de decisión en lugar de un partner que te ayude a elegir. Y, aunque se pueda hacer referencia a diferentes tecnologías con las que se trabaja, el modelo de comisionamiento hará que no salgan del que ha generado el lead inicial.

(Única cuña publicitaria: en Paradigma no cobramos fee / comisión de implementación en nuestros acuerdos con CDP / Reverse ETL, ya que queremos poder tener la seguridad de que la decisión estará enfocada en cliente y no alterada por escalados).

Séptimo aprendizaje: el momento para hablar con un perfil de consultoría va a tener mucho impacto en la relevancia de la solución. Se muerde poco la mano que te da de comer.

El levantamiento o refinamiento de casos de uso sucede durante la fase final de la preventa. En ese momento se empieza a tangibilizar el tiempo, impacto, costes de desarrollo, coste oportunidad, disponibilidad de los equipos, retorno de los casos, proyecciones a futuro, colisión con proyectos estratégicos y es un punto muy habitual para que los proyectos mueran si no hay un alineamiento anterior. Todo nuevo sponsor que entre en este punto del proceso tendrá más posibilidades de convertirse en un antagonista.

De igual manera, todos los stakeholders iniciales verán más cerca el proyecto y la necesidad de compromiso por su parte. Asegúrate de que cualquier nuevo impedimento es compartido.

Octavo aprendizaje: la tracción entre los stakeholders principales es el mayor asset a mantener y el más difícil de recuperar.

Así como un porcentaje muy elevado de proyectos terminan en fracaso, nuevos retos en la ingesta, integraciones, persistencia de eventos, nuevos cambios regulatorios, gente que cambia del proyecto… pueden hacer peligrar el éxito o mermar el alcance. Puntos de situación durante la implementación ayudarán a encauzar esos retos y mantener el control del proyecto.

Las historias buenas suceden a quienes saben contarlas (Paul Auster, escritor) y en el caso de implementaciones de procesos y analitica tienen más peso. Una demo con hipótesis, acciones y resultados es siempre necesaria ya que, aunque los resultados no sean los esperados en una primera instancia, frecuentemente demuestran que el control del proceso ha mejorado.

Noveno aprendizaje: hacer una demo de cliente con KPI siempre es positiva, independientemente del resultado.

Tras la primera entrega de casos de uso, equipos de cliente, marketing, operaciones tienden a levantar nuevas necesidades con el impacto en la priorización, asignación de presupuesto y timings. Si se han ajustado las reglas de partida, es más fácil “proyectivizar el bau”.

Décimo aprendizaje: el día después es cuando empieza el verdadero proyecto.

El desarrollo para implementar una solución centralizada de cliente no es tanto un proyecto técnico como un proyecto de gestión del cambio y como tal, los retos no vienen tanto del lado técnico como del lado humano.

Nunca es un proyecto de “unos meses”. Incluso en el mundo de los reverse ETL, el proyecto siempre acarrea un BAU.

El modo y momento de elegir un partner para la implementación determinará mucho las decisiones tecnológicas para un outcome que nunca es “implementar una tecnología”.