Episodio n.º 67: DCFTS 9, Cómo construir un sistema unificado de participación
Publicado: 2021-02-01Comparte este artículo
Nuestro episodio final del Sistema de Transformación Digital Customer-First. Hoy hablamos sobre cómo usar una arquitectura de referencia para adaptar la nueva tecnología a su pila martech existente.
Haga clic aquí para ver el Modelo de Arquitectura de Referencia del Sistema de Transformación Digital Customer-First (pdf, 317KB)
Todos los episodios de podcasts
TRANSCRIPCIÓN DEL PODCAST
Estamos de vuelta. Es la Experiencia CXM. Soy Grad Conn, CXO, director de experiencia en Sprinklr. Y este es nuestro episodio final, no la última vez que hablamos de ello, sino nuestro episodio final sobre el DCFTS, el sistema de Transformación Digital Cliente Primero. Y hoy, lo que vamos a hacer es hablar un poco sobre cómo usar una arquitectura de referencia para adaptar la nueva tecnología a su pila martech existente. Va a ser un debate bastante interesante. Pero antes de entrar en materia, voy a dedicar un segundo a lo que ya es DCFTS. Has estado escuchando, probablemente lo sepas. Haré esto razonablemente económicamente. Pero voy a repasar estos cinco pasos en su viaje para convertirse primero en un cliente digital.
Esto es algo que hacemos con los clientes todo el tiempo. Podemos hacerlo como una serie de talleres, de medio día, de un día, de dos días, tantos días como quieras. Los líderes sénior dentro de Sprinklr, también nuestros socios de SI, pueden ejecutarlos, y son una forma fantástica de alinear a sus partes interesadas, aclarar sus pensamientos... asegurándose de que todos estén en sintonía. Y también puede descargarlos y obtener copias de estos de nuestro blog, y de mi blog, etc.
Entonces, permítanme hablar un poco sobre los cinco pasos. Así que el primer paso es ver qué es posible. Ese es un modelo de valor, oye, ¿qué podemos sacar realmente de esto? ¿Qué tipo de valor quiero entregar a la organización? El segundo paso es identificar lo que necesita. Eso lleva a un modelo de capacidades. Cuáles son las capacidades que necesitamos construir como organización. Esa fue una discusión de dos episodios, o tal vez incluso de tres episodios, mientras la analizaba en detalle. Es un modelo muy rico. El tercer paso es definir dónde se encuentra y qué sigue. Eso lleva al modelo de madurez. El modelo de madurez es uno de mis pasos favoritos porque hace que todos estén de acuerdo, aquí es donde estamos hoy como organización y, lo que es más importante, donde queremos estar. Y luego tienes que validar la inversión. ¿Cuál es el ROI que esperamos de esto? ¿Cómo queremos hacer que esto se devuelva? ¿Cuál es nuestro plazo de amortización? ¿Y qué vamos a mirar allí? ¿Y cómo pensamos en el ROI? Muy importante, porque muchas de las transformaciones digitales centradas en el cliente tienden a adoptar un aspecto casi religioso de "¿qué es lo correcto?". Y es lo correcto, no me malinterpreten. Pero el resultado es que las personas terminan impulsando algo que las personas no tienen claro cuál es el valor, no saben por qué lo estamos haciendo. Y puede confundirse y tal vez frustrarse.
Y luego el paso cinco en realidad tiene tres partes. Es decidir qué hacer. Entonces, una vez que esté en esta etapa, puede crear casos de uso funcionales, y son muy particulares para la organización. Puede construir un modelo de operaciones. Y lo analizamos en detalle en el último programa. Y creo que puede ver el modelo de operaciones, una excelente manera de lograr que todos se alineen en todas las cosas que debe hacer. Y luego, hoy, vamos a terminar con el modelo de arquitectura de referencia.
Esta es una diapositiva bastante visual. Entonces, describiré eso y hablaré un poco sobre eso. Pero también, hablaré un poco sobre las pilas de martech y algunos de mis pensamientos al respecto, algunas experiencias que he tenido con las pilas de martech y un poco de perspectiva sobre lo que veo en las personas que están haciendo el mejor trabajo. esta haciendo Eso es DCFTS. Así que, aquí vamos.
Hablemos del modelo de arquitectura de referencia. Tengo un sesgo aquí. Entonces, solo expondré ese sesgo, porque creo... Probablemente tengo múltiples sesgos, pero este es un sesgo particular en torno a la arquitectura, que es que trabajamos con organizaciones muy grandes de Sprinklr. Entonces, cuando entramos en una organización, por lo general ya tienen muchos sistemas. Múltiples sistemas SAS. El departamento de marketing promedio en general tiene más de 70 sistemas martech diferentes. Solo HR tiene casi tantos. Pero muchos tienen muchos más que eso. De hecho, estaba en una gran empresa mundial de fabricación y tecnología, y usé ese número 70 como promedio. Y el director de operaciones estaba comprometido conmigo, se echó a reír. Dije, ¿qué es tan gracioso? Y llega a los 70, dice, aspiramos a bajar a los 70. Estamos en los 100. Y eso es bastante típico. Entonces, sí digo que tengo un sesgo en una perspectiva matizada de que estamos trabajando con grandes organizaciones que tienen muchos sistemas.
Una de las razones de esto es que se ha empoderado mucho a diferentes grupos, como los equipos de marketing, que comprarán estos sistemas por su cuenta sin involucrar a TI. Creo que eso es un error. De hecho, me encantaba trabajar con... tenía un gran socio de TI y me encantaba trabajar con TI. Y fue una parte muy importante de cómo tuvimos éxito en Microsoft al hacer esto. Pero eso no sucede en todas partes.
Lo segundo es que en realidad observé que muchos proveedores se aprovechan de la complejidad de las grandes organizaciones. Tengo un punto de vista sobre esto también. Creo que esto es lo incorrecto. Pero clásicamente entrará en una organización grande y les preguntará cuántos, digamos, sistemas CRM tienen. Y todos serán de un proveedor. Pero tendrán como 16, 17, 20, 25 versiones diferentes que no se pueden combinar, ya sea en diferentes países, diferentes departamentos o diferentes negocios. Entonces, el desafío es que termina con datos sobre el cliente en un montón de sistemas diferentes, y eso nunca se puede agregar.
Entonces, tenemos una filosofía en Sprinklr, que mantenemos muy firmemente, que es que solo hacemos implementaciones de una sola instancia. Y este ha sido un principio de Sprinklr desde el primer día. Y ha demostrado ser un modelo operativo fantástico. Trabajamos con algunas empresas en 140 países diferentes. E incluso si un país nos pidiera tener su propia versión de Sprinklr, no lo haríamos. Siempre nos aseguramos de que todos estén en la instancia de Sprinklr de esa empresa. Para que pueda ocurrir una colaboración global, puede ocurrir una colaboración de unidad de negocio a unidad de negocio, y las personas pueden trabajar entre sí sin importar dónde se encuentren. Y eso ha demostrado ser profético, la gente no estaba tan preocupada por eso, digamos hace una década cuando se creó ese principio. Pero hoy en día, se ha convertido en un problema real en el que las personas intentan descubrir cómo obtener una vista del cliente de 360 grados y no pueden hacerlo.
También tengo un punto de vista sobre las pilas martech en general. Voy a exponer este sesgo también. Si vas a Chiefmartech.com, que es... Me encanta lo que Scott ha estado haciendo allí. Creo que es un gran sitio. Si no lee chiefmartech.com al menos una vez a la semana, debería hacerlo. Es realmente genial. Lo hace gratis, y hay mucha perspectiva interesante ahí. Pero dirige algo llamado los Premios Stackie. Y los Premios Stackie son: muéstranos tu stack de martech. Y juzgaremos quién es el mejor stack. Y creo que hay algo de orgullo en las personas que tienen stacks complejos. El problema es que para que todas estas diferentes aplicaciones SaaS funcionen juntas, todas deben conectarse a través de una API. Y el desafío es que cualquier buena aplicación SaaS está en constante evolución. Haremos de 700 a 800 funciones por trimestre, eso es en Sprinklr. Y todo el mundo está haciendo eso. Y entonces, tienes todas estas diferentes aplicaciones SaaS que evolucionan muy rápidamente. Y esas API tienden a ser bastante frágiles. Por lo tanto, los sistemas tienen dificultades para trabajar y conectarse entre sí.
Tenía un equipo cuando estaba en Microsoft, cuyo objetivo era simplemente encontrar los cables rotos que caían al suelo entre la API, las conexiones API rotas entre nuestras diferentes aplicaciones SaaS, para tener perspectiva. Pero esa es la realidad. Y está cambiando. Lo que sí vemos, cada vez más, es que las personas usarán Sprinklr para eliminar muchas soluciones de puntos individuales. Sprinklr, puede reemplazar hasta 17 soluciones puntuales diferentes con su funcionalidad, o incluso más si tiene duplicados. Eso es muy bonito. No voy a lanzar eso hoy, ahí es donde vamos. Pero cuando estaba construyendo mi pila martech en Microsoft, mi perspectiva era que no quería tener un montón de soluciones puntuales. Lo que realmente quiero es un montón de suites. Y ni siquiera un montón… unas pocas suites, ¿verdad?
Y esa perspectiva provino de la atención médica. El cuidado de la salud está clásicamente un poco por delante de la curva en TI. Algo en lo que tal vez no todos piensen, especialmente cuando estás sentado en el consultorio del médico llenando formularios una y otra vez en papel. Pero en realidad, la TI es muy sofisticada... La TI en el cuidado de la salud es muy sofisticada, porque siempre están a la vanguardia tratando de averiguar cómo asegurarse de que los resultados de los pacientes estén optimizados. Y así, hace unos 10 años, los hospitales llegaron a un punto en el que tenían tantas soluciones puntuales que les resultaba difícil operar el hospital. Incluso el simple aprovisionamiento de un nuevo usuario era extremadamente complicado. El Centro Médico de Palo Alto, por ejemplo, en Palo Alto, California, tenía 400 camas en su hospital, una especie de hospital de tamaño medio. Y tenían 400 soluciones SaaS diferentes en ejecución. Algunos también eran escritorios, creo. Y ese pobre CIO está al límite todo el tiempo. El simple hecho de proporcionar una nueva enfermera fue extremadamente complicado.
Y así surgió un sistema en los años 80. Pero les tomó mucho tiempo construirlo, llamado Epic. Y Epic Health Care, con sede en Madison, Wisconsin, es una de las mejores empresas del mundo, un CEO fantástico, una cultura única. Y su perspectiva siempre fue que sería mejor tener toda la información del paciente en un solo lugar y tener un montón de diferentes sistemas conectados a él. Suena familiar, ¿verdad? En muchos sentidos, Sprinklr es simplemente la misma estrategia que Epic, pero en marketing en lugar de atención médica. Y a Epic le tomó mucho tiempo desarrollar todas las diferentes funciones que eran necesarias para operar completamente un hospital. Pero alrededor de 2006 a 2010, llegaron a un punto en el que podía administrar su hospital en Epic. Hoy, Epic es el 60% del negocio hospitalario. Son el jugador dominante. Han aplastado a todos. Cerner está en un gran problema. Y lo que se ha demostrado es que el modelo de poder ver la vista completa de un paciente, y que el paciente también vea su vista completa, porque hay un portal de Epic, es increíblemente valioso porque puede administrar los resultados más fácilmente.
Creo que la misma revolución está llegando al marketing. En Sprinklr, lo que vemos todos los días es que más y más empresas nos utilizan para poder obtener una vista de 360 grados de su cliente en un perfil CXM, utilizando nuestra base de datos CXM. Y verán las ventajas de brindar mejores experiencias a los clientes a través de la lealtad y los ingresos. Y ahí es donde nos dirigimos.
Entonces, en el modelo DCFTS, lo que hacemos aquí, y esto es increíblemente útil, porque lo que hacemos es tomar... es un gran diagrama con muchas líneas. Entonces, ni aquí ni allá. La clave es pensar en todos los diferentes sistemas que necesita conectar. Y aquí es donde creo que a veces la complejidad de la pila de martech existente a veces se puede pasar por alto, o pasar por alto, o simplemente no pensemos en eso porque da un poco de miedo. Pero esto básicamente dice: Oye, tienes sistemas de correo electrónico, tienes bases de datos, tienes sistemas CRM, tienes todo tipo de gestión de la atención y tienes herramientas de gestión de terceros. Y tiene todas las diferentes herramientas de planificación, herramientas de gestión de marketing, herramientas de producción de contenido y muchas cosas más. Entonces, lo que hace esta arquitectura de referencia es mostrar todas esas cosas en un solo lugar. Y luego puedes empezar a pensar en cuál es tu arquitectura y cómo encajan todas tus cosas.
Es, creo, una de las cosas más importantes que puedes hacer en este proceso porque, clásicamente, las personas se olvidan de un sistema, o no piensan en un sistema, o no crean claridad sobre cuál es el sistema dominante. O cuál va a ser mi sistema de registro. O a dónde voy y obtengo ese perfil de 360 grados. Y ya sabes, la gente ha estado creando lagos de datos durante varios años. Una perspectiva rápida sobre eso, un poco de sesgo allí, he visto proyectos de lagos de datos fallar una y otra vez. La gente gasta mucho dinero en ellos. Pero debido a que no son realmente procesables, son solo almacenamiento, no tienden a ir a ninguna parte y las personas generalmente reconstruirán el lago de datos. Es posible que esté en una versión dos o tres de su proyecto de lago de datos. Si ese es el caso, entonces probablemente debería detenerlo y tratar de obtener algo que sea más procesable con lo que realmente pueda hacer algo.
Entonces, todas las funciones de front office deben pensarse en esta arquitectura de referencia. Es decir, marketing, atención al cliente, publicidad, comercio, investigación y análisis, desarrollo de productos, relaciones públicas, ventas, recursos humanos, legal y finanzas. Todos estos son realmente importantes para observar y pensar en cómo todos ellos se conectan a todos los diferentes sistemas que están en contacto con el cliente. Y luego hemos agrupado los sistemas en conversaciones, comunidad, colaboración, campañas y contenido. Entonces, hay diferentes sistemas haciendo todas esas cosas diferentes en este momento.
Y luego siéntate y diviértete. De hecho, tenemos pequeñas piezas, como pequeñas piezas de madera que puedes poner en este diagrama. Nuestro CEO hace esto todo el tiempo. Y es superpoderoso. Porque puede ver todos los diferentes sistemas que tiene y crear este inventario de: Dios mío, todo eso se está ejecutando en este momento. Y necesito pensar en cómo voy a hacer, administrar, desmantelar, volver a poner en servicio o lo que sea, todos esos sistemas diferentes. Y es un gran ejercicio para asegurarse de no olvidar nada y no dejar a nadie fuera.
Eso es DCFTS. Si desea que hagamos esto con usted, comuníquese con nosotros. Soy [email protected] y estaría encantado de hacer algo. También puedes contactarme en Twitter, enviarme un mensaje privado a @GradConn. Contáctame en messenger, soy Grad Conn en Facebook. Si quieres enviar una solicitud de amistad, la aceptaré. Y, por supuesto, LinkedIn. También soy Grad Conn en LinkedIn. De hecho, soy Grad Conn en todas partes. Excepto GradConn.com. Estaba muy complacido porque soy el único Grad Conn en el mundo y no registré GradConn.com. Entonces, si vas allí, verás que es una empresa china de conectores. Ese no es mi ajetreo secundario. Esa es en realidad una compañía diferente que sigue tratando de robarme los identificadores. Pero, ya sabes, no los van a conseguir. Y sigo esperando que quiebren, pero parece que les está yendo muy bien. Por lo tanto, es un poco de un punto muerto en este momento. Veremos que pasa. Pero en cualquier lugar que no sea GradConn.com puede comunicarse conmigo. Ponte en contacto conmigo y prepara algo. Y tendremos una conversación, podemos analizarlo en detalle, y podemos organizar un taller, y para la Experiencia CXM, soy Grad Conn, y los veré la próxima vez.