Episodul #67: DCFTS 9, Cum să construiți un sistem unificat de implicare

Ultimul nostru episod Digital Customer-First Transformation System. Astăzi vorbim despre cum să utilizați o arhitectură de referință pentru a încadra noile tehnologii în stiva dvs. de martech existentă.

Faceți clic aici pentru a vizualiza modelul de arhitectură de referință a sistemului de transformare digitală pentru clientul întâi (pdf, 317KB)

Toate episoadele de podcast

Mergi acum

TRANSCRIPT PODCAST

Ne-am întors. Este experiența CXM. Sunt Grad Conn, CXO, ofițer șef de experiență la Sprinklr. Și acesta este ultimul nostru episod – nu ultima dată când am vorbit despre el – ci ultimul nostru episod despre DCFTS, sistemul de transformare digitală a clientului în primul rând. Și astăzi, ceea ce vom face este să vorbim puțin despre cum folosiți o arhitectură de referință pentru a încadra noile tehnologii în stiva dvs. de martech existentă. Va fi o discuție destul de interesantă. Dar înainte de a intra în asta, voi petrece doar o secundă ceea ce este deja DCFTS. Ai ascultat, probabil știi. Voi face asta relativ economic. Dar voi parcurge acești cinci pași în călătoria ta pentru a deveni mai întâi client digital.

Acesta este ceva ce facem cu clienții tot timpul. O putem face ca o serie de ateliere, jumatate de zi, o zi, doua zile, cate zile doriti. Liderii seniori din Sprinklr, precum și partenerii noștri SI, cu toții le pot executa și sunt o modalitate fantastică de a vă alinia părțile interesate, de a vă îndrepta gândirea,... asigurându-vă că toată lumea este pe aceeași pagină. De asemenea, le puteți descărca și obține copii ale acestora de pe blogul nostru și de pe blogul meu etc.

Deci, permiteți-mi să vorbesc puțin despre cei cinci pași. Deci, primul pas este să vedem ce este posibil. Acesta este un model de valoare, hei, ce putem obține cu adevărat din asta? Ce fel de valoare vreau să ofer organizației? Pasul doi este să identifici ceea ce ai nevoie. Deci asta duce la un model de capabilități. Care sunt capacitățile pe care trebuie să le construim ca organizație. A fost o discuție în două episoade, sau poate chiar în trei episoade, când am trecut prin asta în detaliu. Este un model foarte bogat. Pasul trei este să definiți unde vă aflați și ce urmează. Deci asta duce la modelul de maturitate. Modelul de maturitate este unul dintre pașii mei preferați pentru că îi face pe toți să fie de acord, aici suntem astăzi ca organizație și, mai important, unde vrem să fim. Și apoi trebuie să validați investiția. Care este rentabilitatea investiției pe care o așteptăm de la asta? Cum vrem să facem rambursarea acestui lucru? Care este intervalul nostru de amortizare. Și ce ne vom uita acolo? Și cum ne gândim despre rentabilitatea investiției? Foarte important, deoarece o mulțime de transformări digitale orientate spre client în primul rând tind să capete un aspect aproape religios al „ce este ceea ce trebuie făcut”? Și este lucrul corect de făcut, nu mă înțelege greșit. Dar rezultatul este că oamenii ajung să conducă ceva pe care oamenii nu sunt clari care este valoarea, nu știu de ce o facem. Și poate deveni cam confuz și poate frustrat.

Și apoi pasul cinci are de fapt trei părți. Este să decizi ce să faci. Deci, odată ce sunteți în această etapă, puteți construi cazuri de utilizare funcționale și sunt foarte specifice organizației. Puteți construi un model de operațiuni. Și am trecut prin asta în detaliu în ultimul spectacol. Și cred că puteți vedea modelul de operațiuni, o modalitate excelentă de a-i alinia pe toți la toate lucrurile pe care trebuie să le faceți. Și apoi astăzi, vom încheia cu modelul de arhitectură de referință.

Acesta este un slide destul de vizual. Deci, voi descrie asta și voi vorbi puțin despre asta. Dar, de asemenea, voi vorbi puțin despre martech stacks și despre câteva dintre gândurile mele despre asta, despre câteva experiențe pe care le-am avut cu martech stacks și puțină perspectivă asupra a ceea ce văd oameni care fac cea mai bună treabă. se face. Deci asta este DCFTS. Deci iată-ne.

Să vorbim despre modelul arhitecturii de referință. Am o părtinire aici. Deci, voi expune doar această părtinire, pentru că cred că... probabil că am mai multe părtiniri, dar aceasta este o părtinire specială în jurul arhitecturii, adică lucrăm cu organizații foarte mari ale Sprinklr. Deci, atunci când intrăm într-o organizație, de obicei au deja o mulțime de sisteme. Mai multe sisteme SAS. În general, departamentul mediu de marketing are peste 70 de sisteme martech diferite. Doar HR are aproape la fel de multe. Dar mulți au mult mai mult decât atât. Am fost de fapt la o mare companie globală de producători și tehnologie și am folosit acel număr de 70 ca medie. Și COO era în logodnă cu mine, a început să râdă. Am spus, ce e atât de amuzant. Și împlinește 70, spune el, aspirăm să coborâm la 70. Suntem în 100. Și asta e destul de tipic. Deci, spun că am o părtinire într-o perspectivă nuanțată că lucrăm cu organizații mari care au o mulțime de sisteme.

Unul dintre motivele pentru acest lucru este că multă împuternicire s-a dus la diferite grupuri, cum ar fi echipele de marketing, care vor cumpăra aceste sisteme pe cont propriu, fără a implica IT. Cred că este o greșeală. De fapt, mi-a plăcut să lucrez cu... am avut un partener IT grozav și mi-a plăcut să lucrez cu IT. Și a fost o parte foarte importantă a modului în care am avut succes la Microsoft să facem asta. Dar asta nu se întâmplă peste tot.

Al doilea lucru este că am observat de fapt că mulți furnizori profită de complexitatea organizațiilor mari. Am si eu un punct de vedere despre asta. Cred că acesta este lucrul greșit de făcut. Dar, în mod clasic, vei intra într-o organizație mare și îi vei întreba câte, să zicem sisteme CRM au. Și toate vor fi de la un singur furnizor. Dar vor avea 16, 17, 20, 25 de versiuni diferite care nu pot fi combinate, fie în țări diferite, departamente diferite sau afaceri diferite. Și astfel, provocarea este că ajungeți cu date despre client într-o grămadă de sisteme diferite și care nu pot fi niciodată agregate.

Deci, avem o filozofie la Sprinklr, pe care o ținem foarte tare, și anume că facem doar implementări cu o singură instanță. Și acesta a fost un principiu Sprinklr din prima zi. Și sa dovedit a fi un model de operare fantastic. Lucrăm cu unele companii din 140 de țări diferite. Și chiar dacă o țară ne-ar cere să avem propria lor versiune de Sprinklr, nu am face asta. Ne asigurăm întotdeauna că toată lumea se află pe instanța Sprinklr a companiei respective. Pentru ca colaborarea globală să poată avea loc, poate avea loc colaborarea între unități de afaceri și indivizii pot lucra unul cu celălalt, indiferent unde se află. Și asta s-a dovedit a fi prevăzător, oamenii nu erau la fel de îngrijorați de asta, să spunem acum un deceniu, când a fost creat acel principiu. Dar astăzi, a devenit o problemă reală în care oamenii încearcă să-și dea seama cum să obțină o viziune la 360 de grade a clienților și nu o pot face.

Am și un punct de vedere asupra stivelor martech în general. Voi expune și această părtinire. Dacă mergi pe Chiefmartech.com, adică... Îmi place ce face Scott acolo. Cred că este un site grozav. Dacă nu citiți chiefmartech.com cel puțin o dată pe săptămână, ar trebui. Este chiar grozav. O face gratuit și o mulțime de perspectivă interesantă acolo. Dar el conduce ceva numit Stackie Awards. Și premiile Stackie sunt: ​​arată-ne stiva ta de martech. Și vom judeca cine este cel mai bun stack. Și există o mândrie, cred că oamenii au stive complexe. Problema este că, pentru a face ca toate aceste aplicații SaaS diferite să funcționeze împreună, toate trebuie să se conecteze printr-un API. Iar provocarea este că orice aplicație SaaS bună evoluează constant. Vom face 700 până la 800 de funcții pe sfert, asta la Sprinklr. Și toată lumea face asta. Și astfel, aveți toate aceste aplicații SaaS diferite care evoluează foarte rapid. Și acele API-uri tind să fie destul de fragile. Deci, sistemele funcționează și se conectează cu greu unele la altele.

Am avut o echipă când eram la Microsoft, al cărei scop era doar să găsească clienții rupți care au căzut la podea între API, conexiunile API întrerupte între diferitele noastre aplicații SaaS, pentru perspectivă. Dar asta e realitatea. Și se schimbă. Ceea ce vedem, din ce în ce mai mult, este că oamenii vor folosi Sprinklr pentru a elimina o mulțime de soluții de puncte individuale. Sprinklr, poate înlocui până la 17 soluții punctuale diferite cu funcționalitatea sa, sau chiar mai multe dacă aveți duplicate. E destul de misto. Nu voi lansa asta azi, acolo mergem. Dar când îmi construiam stack-ul martech la Microsoft, perspectiva mea era că nu vreau să am o grămadă de soluții punctuale. Ce îmi doresc cu adevărat este că vreau o grămadă de apartamente. Și nici măcar o grămadă... câteva apartamente, nu?

Și această perspectivă a venit din asistența medicală. Asistența medicală este în mod clasic puțin înaintea curbei în IT. La care poate nu toată lumea se gândește, mai ales când stai în cabinetele medicului completând formulare iar și iar pe hârtie. Dar, de fapt, IT-ul este foarte sofisticat... IT-ul în domeniul sănătății este foarte sofisticat, pentru că ei sunt mereu pe punctul de a încerca să-și dea seama cum să se asigure că rezultatele pacienților sunt optimizate. Și astfel, spitalele au ajuns la un punct în urmă cu aproximativ 10 ani, în care aveau atât de multe soluții punctuale încât le-a fost greu să opereze spitalul. Chiar și doar furnizarea unui utilizator nou a fost extrem de complicată. Centrul Medical Palo Alto, de exemplu, din Palo Alto, California, avea 400 de paturi în spitalul lor, un fel de spital de dimensiuni medii. Și aveau în funcțiune 400 de soluții SaaS diferite. Unele au fost și desktop-uri, cred. Și astfel că săracul CIO este tot timpul pe margine. Doar asigurarea unei noi asistente era extrem de complicat.

Și așa a apărut un sistem în anii 80. Dar le-a luat mult timp să-l construiască, numit Epic. Și Epic Health Care, cu sediul în Madison, Wisconsin, este una dintre marile companii din lume, CEO fantastic, cultură foarte unică. Și perspectiva lor a fost întotdeauna că ar fi mai bine să aibă toate informațiile despre pacient într-un singur loc și să existe o grămadă de sisteme diferite conectate la ele. Sună cunoscut, nu? În multe privințe, Sprinklr este pur și simplu aceeași strategie ca Epic, dar în marketing, spre deosebire de asistența medicală. Și lui Epic i-a luat mult timp să construiască toate funcțiile diferite care erau necesare pentru a funcționa pe deplin un spital. Dar prin 2006 până în 2010, au ajuns la un punct în care îți poți conduce spitalul pe Epic. Astăzi, Epic reprezintă 60% din afacerea spitalelor. Ei sunt jucătorul dominant. I-au strivit pe toți. Cerner are probleme mari. Și ceea ce s-a dovedit este că modelul de a putea vedea imaginea completă a unui pacient și pentru ca pacientul să-și vadă și el complet, pentru că există un portal Epic, este atât de incredibil de valoros pentru că poți gestiona mai ușor rezultatele.

Cred că aceeași revoluție vine și în marketing. La Sprinklr, ceea ce vedem în fiecare zi este din ce în ce mai multe companii care ne folosesc pentru a putea obține o vedere la 360 de grade a clientului lor într-un profil CXM, folosind baza noastră de date CXM. Și vor vedea avantajele de a oferi clienților experiențe mai bune prin loialitate și venituri. Și acolo ne îndreptăm.

Deci, în modelul DCFTS, ceea ce facem aici, și acest lucru este incredibil de util, pentru că ceea ce facem este să luăm... este o diagramă mare cu multe linii în ea. Deci, nici aici, nici acolo. Principalul lucru este să vă gândiți la toate sistemele diferite de care aveți nevoie pentru a vă conecta. Și aici cred că uneori, complexitatea stivei de martech existente poate fi omisă, sau ignorată, sau, pur și simplu, să nu ne gândim la asta pentru că este oarecum înfricoșător. Dar asta spune practic: Hei, ai sisteme de e-mail, ai baze de date, ai sisteme CRM, ai tot felul de management al îngrijirii și ai instrumente de management ale terților. Și aveți toate instrumentele de planificare diferite și instrumente de management de marketing și instrumente de producție de conținut și o mulțime de lucruri. Și astfel, ceea ce face această arhitectură de referință este că arată toate acele lucruri într-un singur loc. Și apoi poți începe să te gândești care este arhitectura ta și cum se potrivesc toate lucrurile tale?

Este, cred, unul dintre cele mai importante lucruri pe care le poți face în acest proces pentru că, în mod clasic, oamenii vor uita de un sistem, sau nu se vor gândi la un sistem, sau nu creează claritate în jurul a ceea ce este sistem dominant. Sau care va fi sistemul meu de înregistrare. Sau unde să mă duc și să obțin acel profil de 360 ​​de grade. Și știți, oamenii au creat lacuri de date de câțiva ani. O perspectivă rapidă asupra asta, o mică părtinire acolo, am văzut proiecte lacurile de date eșuate din nou și din nou. Oamenii cheltuiesc mulți bani pe ei. Dar pentru că nu sunt cu adevărat utilizabile, sunt doar stocare, nu au tendința de a merge cu adevărat nicăieri, iar oamenii vor reconstrui de obicei lacul de date. Este posibil să fiți într-o versiune a două sau trei a proiectului dvs. de lac de date. Dacă acesta este cazul, atunci probabil că ar trebui să oprești și să încerci să obții ceva mai ușor de acționat cu care să poți face ceva.

Deci, atunci toate funcțiile de front office trebuie gândite în această arhitectură de referință. Deci, marketing, asistență pentru clienți, publicitate, comerț, cercetare și analiză, dezvoltare de produse, relații publice, vânzări, resurse umane, juridic și finanțe. Toate acestea sunt foarte importante să le privim și să ne gândim la modul în care toate acestea se conectează la toate sistemele diferite care ating clientul. Și apoi am grupat sistemele în conversații, comunitate, colaborare, campanii și conținut. Deci, există sisteme diferite care fac toate acele lucruri diferite chiar acum.

Și apoi stai jos și distrează-te puțin. De fapt, avem bucăți mici, cum ar fi bucăți mici de lemn pe care le puteți pune pe această diagramă. CEO-ul nostru face asta tot timpul. Și este super puternic. Pentru că puteți vedea toate sistemele diferite pe care le aveți și puteți crea acest inventar cu: o, Doamne, toate aceste lucruri rulează chiar acum. Și trebuie să mă gândesc la modul în care voi face, sau gestiona, sau scoatem din funcțiune, sau repunerea în funcțiune, sau orice altceva, toate acele sisteme diferite. Și este un exercițiu grozav pentru a te asigura că nu uiți nimic și nu lași pe nimeni afară.

Deci asta este DCFTS. Dacă doriți să facem acest lucru cu dvs., vă rugăm să ne contactați. Sunt [email protected] și aș fi încântat să fac ceva. Poți să mă lovești și pe Twitter, dă-mi DM @GradConn. Dați-mă pe messenger, sunt Grad Conn pe Facebook. Dacă vrei să trimiți o cerere de prietenie, o voi accepta. Și, desigur, LinkedIn. Sunt Grad Conn și pe LinkedIn. De fapt, sunt Grad Conn peste tot. Cu excepția GradConn.com. Am fost foarte mulțumit pentru că sunt singurul Grad Conn din lume și nu m-am înregistrat pe GradConn.com. Deci, dacă mergi acolo, vei vedea că este o companie chineză de conectori. Asta nu este agitația mea secundară. Aceasta este de fapt o altă companie care tot încearcă să-mi fure mânerele. Dar, știi, nu le vor primi. Și tot sper că vor înceta, dar par să se descurce grozav. Deci, este un pic de impas acum. Vom vedea ce se întâmplă. Dar oriunde, în afară de GradConn.com, mă poți contacta. Ia-mă și pune la cale ceva. Și vom avea o conversație, o putem parcurge în detaliu și putem organiza un atelier, iar pentru experiența CXM, sunt Grad Conn și ne vedem data viitoare.