¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
techbiz
Javier Ortiz Hace 1 día Cargando comentarios…
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.
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.
Me lo agradecerás más adelante 😉.
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.
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.
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.
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.
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).
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.
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.
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”.
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”.
Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.
Cuéntanos qué te parece.