Av Techopedia Staff, 25. mai 2016
Takeaway: Vert Eric Kavanagh diskuterer master data management med Dez Blanchfield, Robin Bloor, John Evans og Diana Collins.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Eric Kavanagh: OK, mine damer og herrer, sommeren nærmer seg, det blir varmt her inne. Hvorfor det? Fordi det er tid for Hot Technologies. Ja, jeg heter Eric Kavanagh. Jeg vil være din moderator for showet som er designet for - vi skal snakke om det som er varmt, hva som skjer, hva er de kule tingene der ute på markedet. Dette er vårt samarbeid med Techopedia. Vi elsker disse karene. Vi har jobbet med dem i flere år nå. De har en fantastisk side. Hvis du vil vite noe i tech-verdenen, hva dens definisjon kan være, gå til techopedia.com. Og i dag snakker vi om MDM, master data management. Den nøyaktige tittelen er "Det største bildet: Å kjenne kunden din over flere plattformer." Og dette spillet forandrer seg, folkens, jeg kan fortelle deg akkurat nå.
Så det er et sted om ditt virkelig, slo meg opp på Twitter @eric_kavanagh. Jeg prøver å svare på alle som svarer til meg. Så året er varmt. Det er sikkert varmt for MDM. Og jeg forteller deg hva, det er varmt, ikke bare varmt for de store bedriftene, men også for de små til mellomstore bedrifter som, gjett hva, har mange forskjellige systemer. CRM-systemer, markedsføringssystemer via e-post, ERP-systemer, webanalysesystemer, eBusiness-suiter, osv. Det er mange forskjellige tilgangspunkter for informasjon om kunder, og jo bedre en jobb som bedrifter kan gjøre med å veve alt sammen, jo bedre vil være i stand til å betjene kunden, ikke krysse av for kunden og holde kundene rundt. Hold dem til å kjøpe flere ting.
Jeg har sporet MDM personlig siden om lag 2003, som er omtrent da begrepet ble skapt. Helt ærlig var det en bank, Chase Bank faktisk, jeg tror det var Bank En vei tilbake da, og en av mine gode venner nå, en fyr som heter Joe Northern jobbet med et selskap som het Razza Solutions, og de hadde det som ble DRM-verktøyet av Oracle. Så de faktisk rullet opp kontoer og gjorde hierarki-styring for banken tilbake den gang, og det er noe av de tidlige dagene med masterdatastyring.
Så i disse dager snakker vi om både analytiske og operasjonelle MDM-er. Vi kommer til å snakke mye om de tingene i dag og virkelig hjelpe deg med å forstå hvordan du kan utnytte denne teknologien for å få et komplett syn på kunden din, forstå hvem de er og for å sikre at du kan ta vare på deres behov i hva er et ærlig talt veldig konkurransedyktig miljø over hele verden. Vi ser det over alt.
Altså, rockestjernes rollebesetning av karakterer her: Dez Blanchfield, Robin Bloor, John Evans, Diana Collins. Ringer inn fra fire forskjellige steder over hele planeten. Vi starter med Dez Blanchfield, og med det overlater jeg nøklene til deg, Dez, og jeg begynner å twitre. Ta den bort.
Dez Blanchfield: Takk Eric. Jeg måtte bare minne meg selv på å gå av. Jeg beklager det. Takk for muligheten til å presentere dette. Så jeg kommer til å komme til dette fra et virkelighetseksempel på en organisatorisk utfordring for å håndtere det jeg har omtalt som en av de største forstyrrelsene for organisasjoner de kommer til å se for noen tid. Vi har sett en rekke utfordringer. GFC-rammeselskapene måtte takle det. Vi får jevnlige lovendringer rundt personvern vi må forholde oss til.
En av de tingene som jeg tror at organisasjoner blir fanget opp med at de ikke så komme, var virkningen av hele dette kjendisopplevelsesproblemet. Og egentlig mennesker som løper rundt med mobiltelefoner som ønsker øyeblikkelig tilfredsstillelse på noen måter. Men øyeblikkelig tilfredsstillelse på en god måte, ikke en petulant barnslig måte. Bare en erkjennelse av at de er kunden, de betaler pengene og at de burde få verdien for det. Og slik har det vært denne mynten av kundesentrisitet eller blitt en kundesentrisk organisasjon. Så jeg skal raskt gå igjennom hva det betyr og føre til en litt mer teknisk del av diskusjonene våre snart.
Jeg vil bare si det der ute og si at det for det første at det å være en kundesentrisk organisasjon kommer til en enkel ting: Du trenger en fullstendig oversikt over kunden og kundedataene dine. Du kan ha forskjellige systemer. Du kan ha mange forskjellige produkter. Du har kanskje femti forskjellige avdelinger i organisasjonen din, men uansett hvor du er i organisasjonen, uansett hva jobbfunksjonen din er, bør du være i stand til å få en fullstendig oversikt over alle kundene dine, eller kundene som er i sammenheng med hva din jobbfunksjon er. Og alle deler av datasettet du har, eller alle deler av datasettene du har som forteller deg hva staten for nasjonen er for den kunden.
Jeg satte denne linjen at et komplett bilde av kunder på tvers av alle systemene dine ikke bare er et pent! Nå for tiden er det en nødvendighet. Og første gang du blir fanget i et scenario der du har å gjøre med noe å gjøre med en kunde, spesielt hvis det er live, på telefonen, eller i en webchat eller person som er enda mer skremmende, og du kan ikke fortell dem alt du bør vite om dem, det blir veldig opplagt og det er en veldig uheldig situasjon å være i.
Jeg kommer til å starte med en veldig rask anekdote rundt scenerier i den virkelige verden. Dette er et bilde av en tavle, og denne er mindre enn fem dager gammel. Dette er et faktisk scenario i en tavle i et rom nylig, for et par dager siden, og snakker om selve temaet om hvordan vi går fra å være en veldig stor organisasjon med noe som nitti forskjellige deler av virksomheten vår. Det er en asiatisk bank, de har nitti forskjellige forretningsenheter. De gjør alt fra samfunnslån og jevnaldrende og mikrolån helt til finansiering av å sette satellitter i verdensrommet. Så de er et monster. De har flere titalls millioner klienter. Jeg tror de har knappe femti millioner kunder. Og de blir møtt med denne typiske utfordringen med hvordan vi ikke bare nærmer deg masterdatahåndtering, men spesielt kundedata og en enkeltenhetsklient.
Og da vi kartla det som hoppet av oss fra denne tavlen, var at de ikke bare hadde et problem, de hadde et mareritt fordi ingen av systemene deres snakket med hverandre. Jeg kunne gå inn på hvilken som helst del av banken eller noen del av virksomheten og be om et lån, det kan være et billån, et huslån, et lite virksomhetslån, og de kunne ikke si noe til seg selv, eller de kunne ikke t oppdager noe om noe annet forhold jeg hadde med banken. Og det var absolutt å skremme dagslysene ut av dem fordi de skjønte at bankene langs veien allerede kan gjøre dette, og de er potensielt 12, 15 år bak den åtte ballen. Og det kommer ned til disse nøkkelverdiforslagene som klienter bare ser etter, som bare er et konsekvent syn på meg som kunde, og du må finne ut hvordan du kommer til å levere det. Spesielt nå som jeg har å gjøre med deg på nettet, er det mer sannsynlig å være tilfelle via app i disse dager.
Når det gjelder hvordan den kundesentriske kulturen ser ut, handler det om å integrere alt vi har fra kjernesystemer som fanger opp ting som den første navn, etternavn og andre detaljer når du fyller ut et skjema eller fyller det ut på nettet eller kommer til oss på en teller et eller annet sted ved et utsalg, og vi blir kjent med deg innledningsvis gjennom hele reisen til oss som leverer produktene selv eller tjenesten til du. Og kartlegge det ut fra topp til bunn. Kontinuerlig foredling av dataene og datamodellene vi bruker for å forstå det. Å samkjøre hvordan disse teknologiene og prosessene i virksomheten, flyter, strammer kontinuerlig opp synet vårt på deg. Det pågående engasjementet vi har med deg. Hvordan vi kontinuerlig fokuserer rundt deg klienten og hvordan vi kommuniserer med deg. Hvis jeg selger deg tre tjenester, vil jeg ikke sende deg tre forskjellige papirstykker hver måned eller tre utsagn eller regninger, og så videre.
Den kundesentriske historien får en virkelig trekkraft nå, og organisasjoner ser verdien av den. Det er fremdeles en virkelig utfordring i og med at det er: “Ok, jeg har ti forskjellige systemer, og de snakker ikke med hverandre. Jeg har ikke et verktøy eller et system eller en plattform for å dra det hele sammen. ”Og alltid havner folk i et rom med whiteboard-økter som den jeg nettopp viste deg. Men det hele kommer til en kjerneting i det venstre hjørnet der en transformasjon. Og transformasjon fra organisasjonskultur, mennesker, og stab og operasjonsmodell, helt ned til teknologibunken som støtter dem. Så det er en ganske vanlig sjekkliste som organisasjoner går gjennom for å komme til dette punktet hvor de til og med forstår utfordringen med hva det vil si å være kundesentrisk og behovet for å bygge et system og få tilgang til verktøy som kan hjelpe dem å gjøre dette.
Det er ting som å kartlegge kundereisen gjennom hele livssyklusen og opplevelsen de har med deg som organisasjon. Foredle driftsmodellene dine og hvordan du organiserer dere for å være fokusert på kunden og verdiforslaget du har gitt kunden. Og selvfølgelig justere dine teknologier og dine teknologibunker og prosesser rundt dem for å sikre at du faktisk kontinuerlig driver videre engasjement, og bedre og strammere engasjement med kundene dine. Og selve engasjementsprosessen fra lederne og nedover.
Hvis du ikke har endret synet ditt på verden fra toppen av næringskjeden, fra styrerommet og nedover, er det liten sjanse for at deponivået ditt eller det daglige økonomipersonellet kommer til å endre oppførsel. Du må lede fra toppen. Du må kontinuerlig oppdatere og omdefinere og omutvikle hvordan du adresserer målretting mot det faktiske fokuset på klienten. Så hvordan skaper du ikke bare et kulturskifte i enden, men atferdsendring i bunnen av organisasjonen, og verktøyene du gjør tilgjengelig for å gjøre det?
Det er en ting å si at du er en kundesentrisk organisasjon og at du vil at folk skal oppføre seg på en måte, men du har ikke gitt dem midler og verktøy og evne til å gjøre det, du kommer ikke til å få en atferd skift fordi folk bare fortsetter å falle tilbake i vanene de har kjent før de trodde de var kundesentriske organisasjoner. Og deretter den generelle integrasjonen av de forskjellige delene av organisasjonen og kulturen som bodde i det og åpenbart underbygget av verktøyene og plattformen.
Så hvordan tar du disse forskjellige forretningsenhetene eller virksomhetene eller delene av organisasjonen din og får dem til å oppføre seg annerledes fra et kulturelt synspunkt og nedover? Vel, du gir dem de riktige verktøyene og måtene og måtene å få et komplett og enkelt syn på klienten og klientopplevelsen på. Og hvordan kan du sette noen KPIer og måle det mot det og spore det og sette noen beregninger mot disse og måle disse KPIene og gi verdi til det? Forretningsverdi for dere selv og åpenbart verdi i en eller annen form i verdikjeden for kunden og få dem til å komme tilbake. Og integrer deretter all kommunikasjonen du har med kundene dine fra tilbakemeldinger og sanntid eller behandles iterativt, slik at din oppførsel og ditt kulturelle skifte forhåpentligvis blir fanget i en slags tilbakemeldingssyklus og tilbakemeldingssløyfe, og du kan finne ut om du re faktisk treffer merket eller ikke.
Vi kommer til scenariet hvor du vet at organisasjoner til slutt vil finne seg i å drukne i forskjellige data, og vi har sett noen slags ting her, noen interne, noen eksterne. Historisk sett har vi hatt plattformer for kundeforhold og annonseringsplattformer og markedsføringsplattformer. Vi har hatt alle slags forskjellige systemer som kjører uavhengig av hverandre og forhåpentligvis snakker de med hverandre i en eller annen form. Vi har hatt de siste par ukene en eksplosjon av interaksjoner med deg nå, så vi snakker med deg via sosiale medier, vi snakker med deg via nettstedet vårt, vi får e-post fra deg.
IVR-systemene våre som snakker med deg via telefonen, må nå kartlegge disse dataene og fortelle oss hvordan du har taklet telefonsystemet vårt og samhandle med databasene våre, og hvis du hadde vært i en telefonsamtale med oss, er alt det du trenger bli fanget i sanntid, og vi må være i stand til å sørge for at vi kan få et felles syn på det, som forhåpentligvis er den vanlige databehandlingsplattformen i midten av det diagrammet der.
Det er uttrykket som nylig er blitt myntet, og som er en "kjendiskundeopplevelse." Hva betyr det egentlig? Det er ikke slik at vi tror at sluttbrukere eller forbrukere er dårlig oppførte kjendiser og at de føler seg annerledes på noen måte. Hva det betyr er at vi har våknet opp til det faktum at vi skal behandle alle kundene våre som en kjendis. De burde få VIP-behandlingen helt fra det øyeblikket vi møter dem gjennom hele livssyklusen av at vi har gleden av å ha dem som kunder.
Så spørsmålet som jeg blir stilt regelmessig - å bringe dette tilbake til en litt mer anekdotisk ekte historie om en klient - er hvordan kan vi gjøre at organisasjonen vår kan levere den økende etterspørselen etter en kjendis kundeopplevelse? Fordi det vi ser nå er en av de største forstyrrelsene for organisasjoner, er kravet for å levere det løftet til klienter. For å gi dem kjendis kundeopplevelsen. Organisasjoner, fra min erfaring, og absolutt over hele verden som jeg ser, blir forstyrret uten å innse det med skiftet fra andre påvirkninger som de kanskje allerede har visst om eller sett komme til de faktiske kundene. Kundene deres forstyrrer dem og forstyrrer dem på en veldig alvorlig måte. Og hvis du ikke kan gi denne kjendisopplevelsen og gi verktøyene og måtene og virkemidlene for organisasjonen din til å få den ene visningen av klienten, vil du savne en kilometer, i det minste en kilometer evne og kapasitet til å levere det løftet.
Det er noen viktige punkter jeg skal kaste ut her, og deretter overlate til Robin for å få inn litt mer tekniske detaljer, som jeg anbefaler at alle organisasjoner tenker veldig hardt og raskt om hvis de til og med er fjernt nær dette leverer på løftet til sine ansatte og deres organisasjon om å bli en kundesentrisk enhet. Og det er fokus på de grunnleggende komponentene og skaper et enkelt kundesyn. Det høres veldig enkelt ut, men hva betyr det? Vel, det betyr å sørge for at du har riktig data fra riktige datakilder hele tiden og til rett tid. Forsikre deg om at dataene er tilgjengelige på rett sted hele tiden. Ikke bare noe av tiden.
Og den må være tett integrert. Og det må bygges innfødt i plattformen din. Det kan ikke bare være noe du tror du gjør. En enkelt markedsføringskampanje. Hver gang du ser på en kunde trenger du å kunne få tak i dette hele tiden. Det må være tilgjengelig for alle de rette menneskene hele tiden. Så jeg vil ikke løpe rundt i gangene og lete etter stammekunnskap. Jeg trenger å kunne få dette på et øyeblikk, bare ved å komme til ett verktøy. Og du må gi den på riktig plattform med riktig verktøy. Så det må bygges inn i de eksisterende systemene du allerede bruker.
CRM-en din må være i stand til å se alt fra når jeg besøker deg fra mobilappen min, fra nettstedet, fra å snakke med IVR, interaktiv stemmeopptak, til å gå gjennom telefonens helpdesk som en selvbetjening. Eller hvis jeg skyver star-ni og kommer til mennesket, så stiller jeg det litt mer utfordrende spørsmålet som IVR ikke er programmert til å takle. Hvis jeg twitret noe lykkelig, hvis jeg har skrevet en artikkel på LinkedIn. Disse må til slutt mate tilbake i CRM slik at hvis jeg klarer noe med kunden å gjøre, kan jeg se det. Vi må gjøre det til standard og ikke unntaket.
Det er fremdeles veldig unntaket at folk ønsker å drive en kampanje, de ønsker å drive en salgs- og markedsføringsinnsats, eller de ønsker å løse noe problem eller håndtere et prisfastsettelsesproblem. Vi kjører en engangskampanje og prøver å få et enkelt syn på et bestemt segment av vår klient og begynner å kjøre rapporter og skrive ut ting og overlate dem i bundet trykt kopieringsformat. Det er et unntak. Det må være standard. Systemene dine må hele tiden gi dette ene synet på klienten. Og på noen måte vi kommer til det - enten det er en salg og markedsføring, eller bare en operasjonell, produksjon, eller logistikk, eller hva det måtte være, synspunkt - realiteten er at du må gjøre alt det før du kan se en solid avkastning på investeringen din i denne overgangen til å bli en kundesentrisk organisasjon. Du kommer til å få noen kjappe gevinster. Det kommer garantert til å bli raske gevinster. Så det er noen gode nyheter på den fronten. Men virkeligheten er at inntil du fullfører en overgang til å bli en fullstendig visning av kundens kundesentriske organisasjon, kan ikke ROI hoppe av skjermen. Og det er en morsom reise. Det er en verdig reise. Og det hele understøttes av å ha de riktige verktøyene, de rette plattformene og gjøre det tilgjengelig for organisasjonen din på et så tidlig tidspunkt som mulig, i en fornuftig, teknisk og kommersiell levedyktig form. Med det i tankene skal jeg overlate til Robin. Robin?
Robin Bloor: Takk, Dez. Jeg måtte gjøre det samme som deg, jeg måtte slå meg av. Ok, jeg hadde tenkt å nærme meg dette mer fra et konseptuelt synspunkt enn hva slags praktisk scenario som Dez gikk gjennom. Vi snakker virkelig om et veldig spesifikt sett med aktiviteter i en organisasjon når vi kommer inn på området MDM og selvfølgelig er kunden det store. Kundens enhetsidentitet er mye vanskeligere å få til av en hel rekke grunner enn noe annet. Det er sannsynligvis den viktigste enheten. Det er noen virksomheter der de bare har en kunde, og de kan ha all informasjonen de kan få om den kunden. Veldig sjelden. For det meste har organisasjoner flere kunder og kundene har flere fasetter. Og dataene er stort sett spredt over alt. Jeg har jobbet med denne ideen ganske nylig, ideen om en datapyramide. At det er en tydelig forskjell mellom data og informasjon og kunnskap, og faktisk forståelse. Men data, informasjon og kunnskap kan leve i datamaskiner. Data på det laveste nivået er bare signaler og målinger. Og informasjon du kan få tak i som er hva -
Eric Kavanagh: Lyden din begynner å forsvinne, Robin. Bare så du vet det.
Robin Bloor: Ok, jeg flytter mikrofonen. Hva med det?
Eric Kavanagh: Der går du. Det høres mye bedre ut. Der går du.
Robin Bloor: Ja, så data består hovedsakelig av signaler, målinger, opptak og sånt. Det har ingen spesifikk kontekst. Det blir informasjon ved å gi den den konteksten. Koble data sammen. Strukturere dataene. Lage visualiseringer, ordlister, skjemaer. Alt du vil lage rundt det. Det blir overført til kunnskap når du på en eller annen måte faktisk kan begynne å forutsi atferden til en gitt enhet og også implementere retningslinjer og regler for å håndtere den. Forståelsen lever helt i mennesker. Og det er en del av problemet. Når du faktisk ser på fragmenteringen som eksisterer med tanke på kundesituasjonen, oppdager du ofte at salg, vel, har et syn på kunden, markedsføring har et annet. Salgsstøtte eller faktisk bare kundebehandling har et annet syn. Det kan være mange berøringspunkter som en kunde har med en organisasjon. Og ingenting av det er integrert i riktig strukturert informasjon, eller mye av det er ikke integrert.
Og så har vi problemet som har begynt å bli mye mer utbredt de siste årene. Du kan samle eksterne data om mennesker, og det er veldig nyttig, men du må faktisk integrere det for at du skal ha noen reell verdi. Så i foredling av data oppstår de store vanskene ved fragmentering. Disse dataene kommer fra forskjellige steder, og de er ikke godt strukturert. Og det faktum at det pleier å være en kontinuerlig tilførsel av nye data, og dette er nesten alltid tilfelle når det gjelder kunde. Og enhver enhet er et bevegelig mål. Vi brydde oss ikke, kanskje for tre-fire år siden, om sosiale medier-profilen til kundene, men vi bryr oss om det nå. Vi bryr oss om det fordi det kan være skadelig for en organisasjon eller øke for en organisasjon, avhengig av hva som skjer der ute.
Hvis du faktisk har ideen, hvis du satte deg ned og gjorde en øvelse og prøvde å finne ut hva som var de tingene du interesserte deg for kunde for fem år siden? Og du gjør det igjen, og du oppdager at ting er lagt til. Og ting kan ha blitt tatt bort. Jeg mener ingen bryr seg lenger for eksempel hva faksnummeret folk faktisk har. Noen mennesker pleide å ha faksnumre på visittkortene sine. Men ingen bryr seg lenger fordi faks døde. Så det er et bevegelig mål. Når du ser på datamodellering og MDM, er den første tingen - vel, faktisk må jeg si om dette, at dette er en del av datastyring, hvis du ikke gjør dette så er det et problem i måten du styrer data på . For hvis du ikke faktisk gjør datamodellering og MDM, så har du på en eller annen måte faktisk ikke et veldig godt ovenfra og ned-syn på en gitt enhet.
Men jeg har listet opp her styring av data. Jeg har listet opp avstamning, databruk, kvalitet, sikkerhet, servicestyring, gjenoppretting. Du kan legge til livssyklus og så videre. Det er utrolig mye med styring av data og datamodellering, og MDM er en grunnleggende og kanskje sentral del av det. Endring kommer ovenfra og ned i den forstand at du innser at endring skjer fordi folk innser at det skjer. Og derfor kan man tenke på hele denne stabelen fra filer og databaser gjennom dataelementer til betadata og forretningsdefinisjoner.
Du tenker kanskje med tanke på å faktisk måtte på en eller annen måte å administrere hele stabelen og holde hele stabelen oppdatert, fordi å vite noe på forretningsdefinisjonsnivå betyr ikke faktisk at du fanger dataene på fil- og databasenivå. Det er et veldig bredt bilde, og inntil du faktisk tenker på det, skjønner du ikke hvor bredt det er. Modelleringen og MDM, hvis du faktisk ser, handler ikke hele big data-trenden bare om det - det er mye mer data. Det handler om at det er mye mer data fra mange flere kilder, og gir deg mye mer perspektiver på en gitt enhet som du faktisk samler informasjon om. Og jo mer kompleks det er, jo mer du trenger en modell, desto mindre lett er det å forstå. Bare ved å se på la oss si et databaseskjema hva som skjer når data faktisk kommer fra 10, 20, 30 kilder.
I teorien kan du si at MDM gir deg et syn på datauniverset, men i praksis er det faktisk en del av det. Og vi diskuterte faktisk bare hvis du ser på den betydningen av data, da informasjonen om betydningen av data faktisk er en del av datauniverset du ser på. Modellering er ovenfra og nede og opp. Det er at du kan se på ting fra et forretningsperspektiv, men du kan også se på ting fra perspektivet til det vi har. Og du bygger i begge retninger. Og dette er ikke, og kan aldri bli, et prosjekt. Å starte det er et prosjekt. Det er en pågående aktivitet. Du kan sparke det av som et prosjekt fordi du ikke har noe sammenhengende på plass, men når du først har sparket det av, skal det være en pågående aktivitet. Og alt som gjøres innen datasfære, bør MDM-teamet, hvis du vil, vite om det.
Kunden utfordrer, bare se på å fokusere på kundenheten. Det er mye mer tilgjengelig nå om kunden fra langt flere kilder enn for noen annen enhet. Og det ser ut til å øke hele tiden. Det er ofte unøyaktig. Hvis du samler inn data fra meg, for eksempel. Hvis du samler inn data om meg, vil du innse at jeg har forskjellige identiteter, og det er bare om jeg bruker mellom initialer eller ikke når jeg går til forskjellige nettsteder. Og det gjør jeg ofte bare for å oppdage hvor jeg skal få spam fra en gitt identitet. Men mange gjør det. Og så gjør folk utilsiktet feil. Og informasjonen er utdatert.
Jeg gikk til en av disse dataressursene som hevder å kunne gi deg mye informasjon om et gitt individ, og gjorde det åpenbare og stilte spørsmål om meg selv. Og halvparten av informasjonen de ga meg var faktisk utdatert. Og noe av det var galt uansett. Og du ser på det, og du tror at hvis du på en eller annen måte skal samle inn data fra andre kilder, så er det et stort element i å rense dataene og kunne identifisere om det er dataene du har. Som enkeltpersoner har vi ingen unik identifikator. Navn og mobiltelefonnummer vil sannsynligvis komme deg i nærheten av folk flest, men ikke alle har et mobiltelefonnummer. Og det er annerledes i forskjellige kulturer også. Og så er det naturen til data når det gjelder analyser.
Jeg har ikke tenkt å gå nærmere inn på dette, men data kan velges. Hvis du har fått noen Twitter-data, er det bare en liten befolkning av individer som aktivt legger data på Twitter. Og de er utvalgte. De er ikke tilfeldig utvalgte kunder. Det er de som har bestemt seg for at de vil være vokale på Twitter. Det er notorisk vanskelig å få et 360-graders syn på en kunde. Og det er delvis bare på grunn av alles tekniske historie. Det er ikke uvanlig å oppdage at det er tre eller flere kundedatabaser, akkurat som databaser, ikke husk på mange andre kilder til informasjon du faktisk samler om kunden. Og kundeanalyse, er det verdt å si at det er en enorm mulighet nå. Vi pleide å gjøre segmentering i churn, men nå er det virkelig, fordi det er utrolig mange eksterne data tilgjengelig for kundene, kan du gjøre en masse analyse av forholdsgraf, som egentlig er relativt nytt. Du kan bruke prediktiv analyse, du aldri visste før. Du kan samle moteinformasjon og meningsinformasjon du aldri kunne samle før.
Det er en veldig god grunn til å gå gjennom hva du gjør med hensyn til kunden, og til å tenke på hvordan du best kan utnytte dataene du har. Et praktisk syn. Modellering av kundenheten er en nødvendig aktivitet av hensyn til nøyaktig og nyttig BI og foredling av kunnskap. Med andre ord, hvis du har en rimelig stor befolkning av kunder, er det egentlig ikke en valgfri ting. Du må slags gjøre det. Og jeg tror det er alt jeg har å si. La oss gi ballen videre.
Eric Kavanagh: OK, så John, jeg tror du kommer videre? Da vil Diana gjøre en demo. Så med det, John Evans, ta det bort. Og folkens, ikke vær sjener, send inn spørsmålene dine når som helst. Vi overvåker det for spørsmål og svar. Ta den bort, John Evans.
John Evans: OK. Takk, Eric. Og takk Dez og Robin for introduksjonen og kommentarene. Det var mye overlapping mellom det du snakket om der og det vi skal snakke om og vise i dag, noe som er flott. Og at vi absolutt vil være enige om at denne forestillingen om kundesentrisitet er noe som folk søker å oppnå, og jeg tror i grunnen at vi vil si at det å ha gode data, så gode data som du kan få om kundene dine, er eneste måten å ha en bønn om å oppnå det. Så det vi ønsker å gjøre i dag er å snakke om kundeorientert masterdataadministrasjon og dele med alle litt om hvordan vi nærmer oss det, løser det problemet og snakker om et nytt tilbud som vi nettopp har introdusert for å gjøre det enkelt for selskaper i alle størrelser å levere bedre kundedata i hele deres fragmenterte datalandskap. Så det landskapet kan se noe slikt ut.
Vi har forskjellige systemer rundt omkretsen her, mange fragmenterte applikasjoner, noen av dem kjører i skyen, noen av dem kjører i lokaler. Og innenfor hver av disse, per definisjon, kommer du til å ha forskjellige måter å identifisere kunder og kundeinformasjon på. Ulike modeller av kundedata med forskjellige attributter, forskjellige prioriteringer og så videre. Og selv om du var en organisasjon der du anser deg for å være, du vet, en SAP-butikk eller en Oracle-butikk, eller du bare driver virksomheten din på SAP for eksempel, eller bare på Oracle, eller du bruker SalesForce, Du kan ha flere forekomster av disse systemene, selv i ditt eget selskap. Kanskje de er distribuert av et annet sted eller av en region som er satt opp av forskjellige grunner, forskjellige soner i verden, eller du kan ha dem satt opp annerledes etter bransje. Og selv om du har en enkelt ERP, hvis du har gjort tilpasningen på tvers av disse, vil det være konflikter i dataene.
Nå blir fragmenteringen vi ser ytterligere forsterket av økningen i adopsjonen av skybaserte systemer og best-of-breed-applikasjoner. Så mens et veldig stort, sammensatt, sammensveiset miljø som dette pleide å være noe som alle trodde, “Vel, som egentlig bare forekommer i de virkelig store selskapene, ” på grunn av denne advent av skyløsninger og den beste rasen tilnærming, blir nå mer utbredt selv i mindre organisasjoner. Så det kjører virkelig en rekkevidde fra små foretak helt til store foretak. Alle lider av det samme problemet med kundedataene sine. Og du kan se på noen av de problemene jeg har listet opp her i midten.
Jeg deler dem opp i tre typer. Det er datarelaterte problemer der du har duplikater, du har ugyldige data, du mangler felt, du har inkonsekvent informasjon, inkonsekvente hierarkier, og disse tingene har en tendens til å bli verre etter hvert som tiden går. Så har du menneskerelaterte utfordringer der folk ikke får tilgang til dataene, de kan ikke svare på spørsmålene de har, hvor de søker, men de klarer ikke å oppnå det 360-graders synet som Robin snakket om.
Og på det tredje området er prosessrelaterte utfordringer der du har data flere steder og også folk ikke vet hva som har endret seg og når fordi ting skjer med dataene hele tiden. Så det er ingen kontroll eller styring av hvordan du holder dataene rene. Så når du prøver å levere en mer sammenhengende / samsvarende kundeopplevelse og gå i dialog med kunder, er det virkelig vanskelig å oppnå det når dine egne data om disse personene ikke er konsistente og ikke er nøyaktige.
Akkurat som til side jeg så, tror jeg det var forrige uke eller uken før, en artikkel i “Information Management” som snakket om hvorfor personlig markedsføring fremdeles ikke er nøyaktig, og de oppførte ni grunner. De to første grunnene i listen deres er datakvaliteten dårlig, og dataene er ikke integrert.
Så hva kan du gjøre med dette? Det er vel et par måter du kan prøve å tilnærme deg dette problemet og tenke på i forhold til hva det vil koste organisasjonen din. Du kan enten sortere angrep på disse dataene når den blir født, hvis du vil, eller du kan angripe den når den er infiltrert i systemet ditt. Så her er et bilde fra en organisasjon som vi har jobbet med, som faktisk fremhevet tretti forskjellige steder der data ble lagret der inne, i sitt landskap.
Så når de dataene er blitt gitt ut i naturen, i disse titalls systemene er det vanskelig å finne, det er vanskelig å vedlikeholde, det er dyrt å fikse, hvis du tenker på å gå inn og prøve å fikse det tretti forskjellige ganger på tretti forskjellige steder . Så ett av begrepene vi vil snakke om er å prøve å være proaktive og prøve å fikse ting tidlig i livssyklusen som mulig fordi når du gjør det vil det være lettere å finne, lettere å kontrollere og rimeligere å fikse og vedlikeholde og på den måten får du bedre data når du jobber nedstrøms i applikasjonene dine.
Så dette er et konsept vi har snakket om, kalt proaktiv MDM, og taglinjen vi liker å bruke er konseptet å rense elvene, ikke innsjøene. Så det er tre trinn til det. Først er å bli ren, der du vil matche og slå sammen og rense og overleve poster så nær kilden som mulig for å prøve å få en gylden post, slik at du unngår å forurense nedstrømsapplikasjonene dine. Dette kan gjøres ved å implementere kontroller over kilder eller til og med gi et sted å sentralt tilby dataene slik at de er konsistente og nøyaktige før du slipper dem ut i naturen.
Berikelse handler om å tilføre verdi til dataene mens du går, inkludert referansedata og annen informasjon som ikke er i kildens operasjonssystem, så dette kan være hierarkier, det kan være segmenteringer for eksempel som ikke er i seg selv lagret i disse systemene.
Så handler den tredje delen om å holde seg ren, og her vil du forsikre deg om at du har prosesser på plass, og at folk er identifisert for å utføre forvaltningen og for å gjøre styresett, ha verktøy tilgjengelig for å aktivere disse prosessene og deretter samsvare proaktivt og at du renser dataene dine med jevne mellomrom slik at de ikke gjør det, så du unngår forfallet som naturlig kommer til å skje, for eksempel når folk skifter jobb eller de skifter bolig eller så videre.
Så hvordan får du tak i dette? Vel, det er en rekke alternativer du kan bruke for å angripe dette problemet. Du kan bruke et datakvalitetsverktøy, du kan bruke et dataintegrasjonsverktøy for å trekke ut informasjonen, du kan bruke et arbeidsflytverktøy for å dele ut til forskjellige mennesker. Du kan bruke et styringsverktøy for å holde rede på hvem som gjør hva. Du kan faktisk koble sammen alle de forskjellige arvemidlene og kaste mange mennesker på det.
Men det er alt veldig dyrt, det er veldig ressurskrevende, det kommer til å være tregt å distribuere og det kommer til å være vanskelig å administrere, og du vil kanskje til og med begynne med kundedataene dine, men du vil også til slutt administrere produktene dine, listen over produkter som disse kundene har, og listen over leverandører for disse produktene, og et kontoplan som du bruker på tvers av virksomheten din for å holde rede på hva som skjer, administrere de ansatte som betjener disse kundene og så videre . Så nå snakker du om flere domener, leverandører, produkter, kontoplan, ansatte og så videre for å prøve å levere en 360-graders oversikt over hele virksomheten.
Så ideelt sett er det vi tror du ønsker å oppnå, en løsning for å integrere, matche og rense dine kundemasterdata, en løsning slik at du kan administrere forvaltning og styring og ett verktøy som du kan bruke til å administrere hvert datadomen når du begynner med kunde og gå videre. Så det er målet bak et nytt tilbud som vi nettopp har kunngjort med navnet Magnitude ONE. Magnitude ONE er et MDM-tilbud designet for bedrifter for å integrere, harmonisere og administrere stamdataene på tvers av de populære SaaS- eller ikke-lokaliserte applikasjonene som er i bruk som vi snakket om tidligere, og Magnitude ONE inkluderer derfor en rekke komponenter.
Det første det inkluderer er vår Kalido MDM-løsning, som har blitt distribuert i noen av verdens selskaper, og Eric, du snakket om eksponeringen din for masterdata og styring tilbake i 2003, jeg tror dette produktet opprinnelig kom ut rundt 2004. Så Vi har vært en tidlig pioner på dette rommet, med dette verktøyet. Vi startet med å bruke den til å betjene den analytiske bruken av informasjonen for å sikre at god data kom inn i lageret og over tid har kundene våre brukt den mer og mer på operasjonsbruk og å håndtere flere domener inkludert kunde og produkt og økonomiske og leverandør og ansatt og så videre. Så Kalido MDM er en kjernedel av denne løsningen.
Vi leverer også tilkobling og integrasjon til et bredt utvalg av kildesystemer ved et partnerskap med SCRIBE programvare, og bruker deres SCRIBE online integrasjonsplattform som en tjeneste. Det er et skybasert integrasjonstilbud med tilkoblinger til over førti systemer både på stedet og SaaS-systemer som organisasjoner bruker. Så med de to sammen, med vår Kalido MDM-løsning inkluderer den også muligheten til å ha et arbeidsflytdrevet miljø for masterdatastyring og administrere det gjennom hele livssyklusen. Vi har en matchende motor som er der som er spesielt designet for å håndtere kundedata, og vi tilbyr i tillegg til programvaren, litt virtuell klasseromsopplæring på Kalido MDM-produktet og modelleringskomponentene.
Så Robin, du snakket om modellen, det er en veldig kritisk del, og det er faktisk der vi begynner i løsningen vår, og vi vil vise deg det om et øyeblikk, hvordan du tar det hvite tavlen som Dez viste og oversatte det til noe som kan konfigurer faktisk MDM-systemet ditt. Det siste punktet ditt om Magnitude ONE er at det er tilgjengelig i lokaler eller som en skytjeneste, du kan få en abonnementslisens eller en evigvarende lisens. Ideen er at det kommer til å være enkelt for deg å kjøpe, vedlikeholde, implementere og vedlikeholde.
Så hvordan dette ser ut da er Magnitude ONE i sentrum her, med de robuste evnene til å gjøre alt i de hvite og blå boksene. Så koble til og få tilgang til kundedata gjennom SCRIBE-kontakten som jeg snakket om. Gjør deretter alle mestringsøvelsene du trenger å gjøre rundt å matche data, slå sammen, overleve og berike dataene for å få det rent. Autoriser og publiser deretter nøyaktige og konsistente data ut til dine konsumerende systemer sammen med et tilgangslag for folk å søke etter data, bla gjennom data og til og med forfattere nye poster slik at dine operative og analytiske systemer kan holde seg rene etter hvert som tiden går.
Vi tilbyr et nettbasert brukergrensesnitt for både tillitsvalgte og administratorer, som du ser på et øyeblikk, så vel som forretningsbrukere. Ikke bare kan de bare bla gjennom og få tilgang til publiserte stamdata, de kan til og med spille en rolle i forvaltningsprosessen. Så forestill deg at salgsrepresentanten din snakker med kundene, de lærer noe nytt om kunden, de kan reise en endringsforespørsel og si hei denne kunden, de har endret tittel, de har endret e-postadresse, de har byttet selskap, kanskje denne legen har byttet tilknytning til dette sykehuset, vi vil sørge for at vi holder oversikt over den slags ting, eller at denne forsikringsmegleren nå bærer disse produktene, vi vil sørge for at vi markedsfører disse nye forsikringsproduktene til dem, for eksempel. Så den slags ting kan løftes opp og repareres på samme måte som de kundevendte ansatte har å gjøre med disse personene.
Et par andre attributter om løsningen vår. Nummer én er denne forretningsmodellen, husk det hvite tavlebildet som Dez viste som hadde sirklene og pilene. Det er i utgangspunktet forretningskravene for hvordan dataene må være, og hvordan de brukes i den virkelige verden. Vi starter med noe som kalles en forretningsinformasjonsmodell, og vi kan i utgangspunktet fange opp disse kravene og de tilhørende forretningsreglene og faktisk distribuere det for å lage reglene og MDM-depotet. Så det fungerer effektivt som en måte å bygge bro på kommunikasjonsgapet som vi så ofte ser mellom forretningsfolk som beskriver et krav og at IT må gå tilbake og oversette det til tabeller og kartlegginger og så videre.
Så vi har den forretningsmodellstyrte tilnærmingen for å sikre at det er riktig fra du starter. Vi inkluderer også automatisert behandling for det og den innebygde arbeidsflyten og endringshåndteringen, slik at du kan, hvis du har en endring i modellen der du legger til den, kan du raskt distribuere det og gjøre det med et lite team på grunn av automatiseringen, krever det ikke så mye koding som kanskje du kanskje hadde forventet å gjøre.
Jeg nevnte den modelldrevne naturen som også driver skjermene som faktisk vises. Så når du har en beskrivelse av en kunde og har attributtene deres der, det du vil se på skjermen er attributtene som er definert i modellen, så alt er opprettet for deg, du trenger ikke å opprette noe spesifikt grensesnitt skjermbilder for å kartlegge for dataene, alt er drevet av modellen.
En annen kul funksjon som vi har introdusert er konseptet med Excel-integrasjon for datatilitsvalgte. Dette betyr at datatilitsvalgte kan bruke Excel som et sted å redigere postene som ikke automatisk kunne matches og godkjennes og distribueres. Nå kan du kanskje tenke, vel, dette er bare, du bare dumper data til Excel, ikke sant? Vel, det er mye mer enn det fordi det kule med denne muligheten er at den overvinner problemet med å bare forny dataoppdateringer ved å laste inn data fra Excel.
Når vi laster ned dataene fra Kalido MDM til Excel-grensesnittet, kommer vi faktisk med valideringsreglene. Så den vil fortelle deg hvilke av disse cellene som må fylles ut for å gjøre den til en gyldig post, den vil gi deg en rullegardinliste over tilgjengelige verdier, eller de godkjente verdiene for eksempel slik at du i utgangspunktet unngår opprette feil når du oppdaterer hoveddataregistrene.
Deretter på innebygd arbeidsflytmotor, sørg for at dataene er alle behandlet og autorisert for publisering, og at det også holder oversikt over hvem som gjorde hva og når, og lar deg i utgangspunktet gjennomgå og revidere alle de tidligere stamdataverdiene, slik at du kan se hvordan dataene endres over tid.
Fordelen med dette, når det gjelder kundedata, er at du kan komme til et sted hvor du kan ha mer personlig og relevant dialog og interaksjon med kundene. MDM blir mer forretningskritisk, spesielt når du tenker på en-til-en-markedsføring som foregår der, og dette er et godt eksempel på syklusen som oppstår.
Så du begynner med data om kundene dine, dette er de tingene du har mestret, hvem er de, hvilke produkter eier de, hva kan jeg matche når det gjelder kundeinformasjon på tvers av flere systemer? Så beriker du det med mer informasjon om dem og hvordan du har hatt interaksjon i fortiden. Hva har de svart på? Eller hvordan ønsker de å bli kontaktet? Kanskje de vil bli kontaktet via faks, så det er derfor det fremdeles står på visittkortet. Men den informasjonen som deretter gir deg innsikten du trenger for å kunne samhandle.
Så hvilke andre preferanser? Noe av det kan komme fra sosiale kilder for eksempel. Så kan du bestemme ut fra hva som er det nest beste samspillet for disse kundene, hvilke tilbud skal jeg gi? Det kommer til å generere en slags interaksjon, de kommer til å laste ned noe, de kommer til å kjøpe noe.
Det kommer selvfølgelig til å lage flere data du vil mate inn i denne dydige syklusen med markedsføringsinteraksjoner. Som et resultat vil du kunne finne og stenge nye kunder raskere, øke salg, levere bedre kundeservice, eliminere feil, eliminere dupliserte forsendelser, for eksempel sende markedsføringsmateriell, og til slutt får vi redusert salg og markedsføringskostnader.
Så et eksempel på en kunde av oss som gjorde dette, Storbritannias postkontor brukte Kalido MDM for å levere bedre kundedata slik at de kunne levere riktige produkter og videreføre sine kundedialoger i riktig kanal som til slutt førte til høyere salgsvolum og økte marginer for dem.
Så det er bare de innledende kommentarene mine. Jeg vil nå overføre den til Diana, for å ta deg gjennom og vise deg nøyaktig hvordan vi gjør noe av dette.
Diana Collins: Takk John, så forhåpentligvis vil vi kunne gi noe av dette til live for dere alle. Så det du bør se på skjermen din akkurat nå, er et eksempel på en Kalido forretningsinformasjonsmodell. Så en del av løsningen, det vi skal vise deg i dag, er en integrasjon av data fra salesforce.com. Her har vi fått frem vår salesforce.com-modell nederst til venstre. Det er åpenbart en nettbasert applikasjon. Programvaren er en slags applikasjonsform. Vi kommer til å integrere det med data fra vår lokale implementering av Oracle, en forretningssuite.
Så målet vårt er å ta kontaktene og kontoinformasjonen vår fra salesforce.com, integrere den med våre kundefordringer og kontaktinformasjon i en enkelt harmonisert konto og kontaktstruktur som vi deretter vil laste inn i Microsoft Dynamics CRM. Så vårt scenario her er at vi migrerer fra å ha brukt salesforce.com tidligere til å bruke Dynamics CRM. Vi vil sørge for at vi har en fullt integrert, harmonisert liste over kunder, 360-graders visning basert på vårt nye Dynamics CRM-miljø.
Så for å bygge dette har vi flyttet dataene fra salesforce.com og EBS til Kalido MDM, vi har faktisk kjørt harmoniseringsprosessen. Så av hensyn til tid har vi liksom gjort matlagingen, og vi kommer til å glede oss over måltidet. Så la oss gå over til MDM-miljøet vårt og bare vise deg noen av tingene vi kan gjøre i de ekstra funksjonene som en MDM-løsning gir en enkel tilkoblingsintegrasjon av disse plattformene.
Men en av tingene som selvfølgelig ville skje, det er at du mister historien. Du vil ende opp med dataene dine i Microsoft Dynamics, men ville du vite hvor noe kom fra? Det er det MDM, en av tingene MDM-løsningen kan gi oss, det gir oss en historie.
Så hvis vi tar en titt på listen over harmoniserte kontoer, og vi velger en av dem. La oss si at vi valgte Albert's Stores her. Dette gir oss litt informasjon om hvor denne Albert's Stores-platen kom fra. Vi kan se at det er en integrasjon av to poster, en kom fra en salesforces.com-konto kalt Albert og Gerard og en kom fra EBS-faktureringskonto kalt Albert's Stores, og de ble integrert sammen og harmonisert i denne alenekontokontoen kalt Albert's Stores.
Vi ser også dens opprinnelige ID, vi kan se i dag at den allerede er migrert til Microsoft Dynamics fordi her har vi CMR-ID fra Microsoft Dynamics. Jeg kan se tidspunktet da dataene sist ble oppdatert. I tillegg til dette gir vi et annet syn som ikke bare lar deg se på dataene, men også med vår grafvisning kan du se på assosiasjonene som dataene deltar i.
Så her har vi den samme posten, våre Albert's Stores med tilknytning til kundekontoen, salesforce.com-kontoen og kontaktene. Hvis vi velger en av disse kontaktene, kan vi se at kontakten faktisk var en salesforce.com-kontakt. På samme måte som Adam Albert-kontoen vår var en EBS-kontakt, så for denne bevegelsen tror jeg på skjermen det skjer automatisk, et par av dem jeg gjør bare holder ting lett å lese. Men mens vi fortsetter, kan vi ta en titt på kontaktinformasjonen og se at den kom fra salesforce.com-kontoen. Det vil faktisk bygge opp en visning som viser oss alle forholdene som dataene våre deltar i.
I tillegg ser vi måtene vi klassifiserer saleforce.com-dataene våre og at det er andre kontoer der ute som er for mange til å føre opp. De tingene som er for mange til å liste, kan vi fremdeles få til dem. Vi kan bare bla nedover siden her og komme til listen over alle ekstrakontoer som var for mange til å vise i grafisk visning. Selvfølgelig kan vi også starte i grafisk visning for noen av disse. Så det er en måte å takle ting på. Vi kan se dataene, vi kan manipulere dataene, vi vil også kunne sanere og fikse data. Så et par måter å se på det.
Så en av tingene vi kunne gjøre er at vi kan gå over, ta en titt på hierarkiet, jeg har lagret kontohierarkiet som en av favorittene mine, så jeg kan lagre forskjellige kategorier av informasjon som kontoer samt hierarkiske stier som Jeg kunne bruke i hierarkivleseren. Så her kan jeg se gjennom hierarkiet mitt, jeg kan se alle de forskjellige kontaktene jeg har med hver konto.
Men en av de andre tingene som dette miljøet gir, er muligheten til å finne alle foreldreløse barn. Dette er kontakter som kom inn gjennom vårt harmoniserte system som ikke hadde foreldre i sine kilder, så dette er foreldreløse som har blitt etterlatt. Så vi har brakt disse over, vi har identifisert dem, vi vet at dette er foreldreløse, og hvordan fikser vi det? Vel, vi klikker bare på denne bryteren for å redigere modus, som åpner en annen visning av hierarkiet, og vi kan nå begynne å klassifisere disse menneskene. Så kanskje Bill Murray jobbet for AC Network slik at vi kan ta ham over og legge ham til listen og vi ser ham fremhevet ved å påpeke for oss at dette er en endring. Jeg kan flytte Sandy og tildele henne kanskje til AG Edwards og Company.
Når disse endringene blir gjort, blir de spilt ned her. Jeg kan angre dem hvis jeg er klar over at jeg har gjort en feil. Jeg kan gjeng multiplum av dem sammen og flytte dem gjennom systemet som en enhet ved å gi dem et navn, og så ble de behandlet som en enkel enhet av arbeidet gjennom systemet mitt. Så dette er en måte, og selvfølgelig, hvis jeg er proaktiv, kan det være lurt å gå inn her og se på dette og se om det var foreldreløse barn og løse problemet. Hva om jeg ikke gjorde det? Hva om jeg ikke var proaktiv? Vel, igjen inkluderer systemet vårt en arbeidsflyt, som jeg nevnte tidligere, en arbeidsflytløsning som gjør at vi kan håndtere dette mer direkte.
For å gjøre det skal jeg logge av som systemadministrator, jeg skal nå logge meg på som en datatyrmann, ok? Så dette vil være personen som er ansvarlig for å håndtere ugyldige data. Du får se så snart jeg logger på, blir jeg ført til innboksen min, hvor gjett hva? Det er våre 11 foreldreløse poster fordi forholdet, tilknytningen mellom kontaktene og deres kontoer er obligatorisk. Alle de harmoniserte kontoene som ikke hadde passende tilknytning til en konto, er ugyldige. De beveger seg gjennom arbeidsflyten, og som vi kan se i diagrammet over arbeidsflyten, her er det hvor vi nå omarbeider poster. De vil deretter strømme til en godkjenningsprosess, godkjent av salgssjefen, godkjent av regnskap, og til slutt autorisert for publisering på neste batchoppdatering av dynamikken vår.
Selvfølgelig kan dette også settes opp til å kjøre i sanntid, så snart det er publisert, så snart det er godkjent for publisering, ville det straks strømme ut Dynamics, så det er opp til deg hvordan du vil konfigurere det siste trinnet i grensesnitt. Så forhåpentligvis har dette gitt oss - gitt dere alle en kort ide, en oversikt over bare noen av måtene MDM-verktøyet vårt kan bidra til å berike og forbedre miljøet vårt. Det er mange, mange andre måter vi kan forbedre din bruk av kundens informasjon, og virkelig komme til det punktet der du har et virkelig harmonisert 360-graders syn på en kunde med all informasjonen på ett sted tilgjengelig for brukere. Ikke bare gjennom denne leverandøren UI, men som jeg nevnte tilbyr vi også et forbrukergrensesnitt, en slags nettportal der hvis en bruker vet at det har skjedd en endring i kontoen, kan han oppgi en endringsforespørsel og adressere det, og pakke den endringen ber direkte til den tillitsvalgte om å gjøre endringer i denne posten som de ser må gjøres. Så på dette tidspunktet tror jeg at jeg vil vende det tilbake til Eric, og vi går inn på Q og A.
Eric Kavanagh: Visst. Så vi har fått et par spørsmål fra publikum her. Jeg kaster en ut, men kanskje først Dez eller Robin, har du noen spørsmål? La meg starte med deg Dez.
Dez Blanchfield: En av tingene jeg kommer over hver gang jeg går gjennom denne reisen med en organisasjon er hele utfordringen med versjonskontroll. Kunne du bare berøre tilnærmingen til versjonskontroll rundt data eller bestemt - du vet, forestill deg et scenario der tre forskjellige deler av organisasjonene har å gjøre med meg som kunde, og så gjør de forskjellige oppdateringer og endringer gjennom en ny verktøy. Hvordan tar vi opp problemet med nettopp versjon som kontrollerer dataene som kommer gjennom virksomheten, og hvem som kuraterer, kontrollerer og godkjenner det?
Diana Collins: Det er et utmerket spørsmål. Så en av tingene som er innebygd og bakt inn i løsningen vår er revisjonsspor og historie. Så jeg får se om jeg kan finne en plate med historie. La meg se om Albert's Stores-posten som vi brukte har historie, så snart jeg klikker på History Mode hva dette gjør for meg - har jeg - denne har ingen endringer i historien. Jeg vil ha det som det vil vise oss eventuelle midlertidige endringer som ble gjort her, og datoen og klokkeslettet der de ble gjort. I tillegg kan jeg gå til Full historie detaljer, og hvis jeg har slått på etterfølgende revisjon, ville jeg ikke bare se disse endringene, og når de ble gjort, men revisjonssporet vil da fortelle meg hvem som har gjort disse endringene, hvilken bruker som har gjort disse endringene også .
Vår tilnærming til versjonering er mer tidsbasert snarere enn ved å sette vilkårlige etiketter. Du kan velge et tidspunkt og se dataene dine som det var på det tidspunktet og migrere dataene som det var på det tidspunktet. Og vi sporer selvfølgelig historien, ikke bare datainnholdet, men også datamodellen. Så da datamodellen din kan utvikle seg, legger vi til nye klassifiseringer, vi sporer det også, og du kan alltid rulle tilbake og se ting som de var på et gitt tidspunkt.
Dez Blanchfield: Datamodeller gir utfordring der, jeg mener du har en betydelig stamtavle med å håndtere noen betydelige artikler. Kan du gi oss et par eksempler på noen av datamodellene som allerede er på plass og noen du har jobbet med å drive dette, vet du, de viktigste sektorene som produksjon og detaljhandel, og logistikk og finansielle tjenester. Du har bank- og tapsstyring og så videre, så er tilnærmingen gjort med en tidligere modell som raskt kan spinne opp et prosjekt som folk kan begynne å vite hvor hullene er, eller må de bygge og trene den modellen selv?
Diana Collins: Vi har tatt begge tilnærmingene gjennom årene. Vi har prøvd å komme opp med modeller og funnet ut at jo mer komplett en modell egentlig betyr, jo flere endringer må du gjøre, for å ha flere tilpasninger du kan gjøre for kunden. Så vi har virkelig tatt tilnærmingen til fragmenter av modeller, visse grunnleggende felleselementer som vi synes som virkelig gjennomsyrer i hele bransjer.
Vi har for eksempel innen finansielle tjenester vi har modeller for i et kapitalmarked for verdipapirer og derivater osv. Vi har modeller for forsikring, for eiendoms- og ansvarsforsikring, for gjenforsikring, og som begge styrer risiko på forskjellige måter. Vi har produksjonsmodeller for produktregninger på materialer, landingsregninger. Vi har andre deler av modellen for en forsyningskjede eller annen tracker, mellomlager, distribusjonsmodeller, aldring av varelager, sånt. For mange av våre kunder, vet du, har vi kunder i nesten hver vertikal du kan tenke på, men for mange av dem har vi vært i stand til å utvikle visse kjernekomponenter som vi samler for våre kunder til en ferdig modell.
John Evans: Ja. La meg bare legge til det, Diana. Du vet, modellen som vi viste for et øyeblikk siden med den slags oransje bakgrunn er virkelig en konseptuell modell, så den har, du vet, vokaler, og det er ingen understrekinger, jeg mener det er at et menneske kan forstå. Det er ikke et IT-konsept i seg selv, det er noe en virksomhetsperson kan forstå. Vi har disse konseptuelle modellene, vi kan importere en eksisterende modell som du måtte ha, og vi faktorerer den for å få det slik, men med - som Diana snakket om, når vi har et modellfragment eller en eksempelmodell som vi har brukt at før vi viser til kunden, vanligvis innenfor, du vet, en liten stund av å se på den og sette den opp på en skjerm og slags peke og bevegelse, kan de vanligvis refaktorere den modellen for å få den til å være ganske representert av hva de prøver å oppnå.
Så det akselererer tiden for å fange opp disse kravene slik at du kan fortsette med det, men det andre jeg ikke viste her er, du vet, det er dette diagrammet, men det er også en fane som heter operasjoner der du i utgangspunktet trykker på en -knappen, og den genererer alle objektene du trenger i MDM-repository sammen med regelen du har vært - du har satt opp til, du vet, hva som er valgfritt, hva er obligatorisk, hva er kardinaliteten, alle de tingene du ønsker å gjøre, men det er en knapp der det står Distribusjon, da ville det bare generere modellen du har laget i frontenden. Så vi har fragmenter, vi har erfaring i en rekke bransjer, og konsulentene våre kan gjøre det mulig for kundene å komme raskt i gang.
Diana Collins: Vel, den andre tingen jeg skulle finne ut -
Dez Blanchfield: Så jeg den andre raske før jeg overleverer den til Robin - ja, sorry, gå.
Diana Collins: Jeg vil bare konstatere at vi vanligvis kjører disse modelleringsøktene som en slags jam session fordi vi ikke er så interessert i detaljene til alle attributtene, vi kan fylle ut det senere når vi kommer til det. Det vi virkelig er interessert i, er å få virksomhetssynet til hvordan dataene henger sammen og hvordan de forstår at de er nyttige, og det er hvordan vi ønsker å bygge løsningen.
Dez Blanchfield: Nei, det gir god mening. En siste kjappe en så overleverer jeg den til Robin. Så det jeg umiddelbart forestiller meg at skulle skje i lederens samtale med organisasjoner som jeg arbeider med, er at - de har syn, de har allerede, du vet, styring, rammer og verktøy på plass - hvordan er opplevelsen når du går inn en organisasjon der vi bare kan si at ledergruppen bestemte seg for at de skal gå denne ruten, bli kundesentrisk og rydde opp i kundedataene, eller få en enkelt forfall, og likevel kan IT og andre deler av virksomheten allerede ha følt at de kjøre flere arbeidsprogrammer for å komme til et bra sted på det?
Diana Collins: Det er et interessant spørsmål. Ja, jeg tilbyr at MDM-implementeringer generelt vil mislykkes med mindre det er den slags støtte på høyt nivå. Jeg tror at disse prosjektene må drives fra et ganske høyt nivå i en organisasjon fordi det er en kulturendring som må aksepteres. Jeg tror Robin snakket med dette tidligere at, du vet, det ikke er noe du bare gjør som prosjekt, og det avhenger av å være slik det ofte blir kontaktet i IT-organisasjonen. Det er et pågående program, det er noe som krever engasjement og vilje til å endre hvis du vil implementere, og når du har det, tror jeg at vi fant ut at implementeringer går veldig bra.
Der vi har å slite med en viss implementering har vært der det ikke har vært lederstøtte på høyt nivå eller der IT-organisasjonen har vært motstandsdyktig mot endring, men vi har lyktes ganske bra i begge tilfeller med å vinne dem. Jeg tror at når vi en gang viste dem hvor enkelt det er å komme opp og operere, og hvordan det virkelig tar ansvaret for datainnholdet fra skuldrene, og virkelig burde ikke IT være ansvarlig for det. Virksomheten vet hva som utgjør gode data, det skal IT ikke trenge å vite. IT bør være ansvarlig for tingene de gjør godt - å organisere data, holde dem trygge, holde dem sikre og hvordan - og vanligvis kommer de rundt og ser det på den måten.
Eric Kavanagh: Og vi har noen spørsmål fra publikum, la meg kaste disse ut her. Vi går litt etter hvert, men jeg tror jeg får alle spørsmålene vi kan eller i det minste prøve. Jeg vil kaste denne over til deg, kanskje John eller Diana, uansett. En deltaker spør: "Har du funksjonalitet for å utvikle deg for å bli foreldre fra dårlige poster til gyldne poster? Transaksjonene som for eksempel salgsordrer rett i operasjonssystemene? ”Ikke sikker på at jeg vet nøyaktig hva han mener her, men forhåpentligvis kan du svare på det.
Diana Collins: Vel, vi kan absolutt gjenopprette poster. Det er en veldig standard del av denne kontorløsningen, men innenfor operasjonssystemene er de ikke direkte. Vi kan gjøre det på MDM-miljøet og deretter skyve de dataene tilbake fra MDM-miljøet når de først er publisert fra MDM-miljøet, skyve dem tilbake til operativsystemet, men de vil ikke bli direkte fanget i - vi ville ikke korrigere det direkte i operativsystemet fra MDM-miljøet.
Eric Kavanagh: Got you. OK, og her er et annet spørsmål, "Kan verktøyet brukes til å se avstamning?"
Diana Collins: Å absolutt, ja. Igjen er ikke dette en god modell for den slags illustrasjoner, men absolutt. Der du har historikk til dataene dine, der data har kommet fra flere steder, kan vi merke dem med kilden og føre den informasjonen videre til de publiserte dataene.
John Evans: Takk for det. Det er et element av det her i modellen, der inne Diana, jeg mener at du har SFDC-kontakter og EBS-kontakter, og som faktisk kom gjennom i et graffelt også. Det henger slags rundt dataene.
Diana Collins: Ja. Jeg mener tydeligvis i et ekte avstamningsmiljø, ville du ha en mer robust løsning og implementering, og bare en grunnleggende ble gjort her.
Eric Kavanagh: Ok, bra. Bare et par spørsmål til, så pakker vi opp. En av de fremmøtte sier: “Hvordan støtter du definisjonen av husholdning? Har du en måte å berike kundens masterdata med sosiale nettverk? ”
Diana Collins: Det er på veikartet vårt, berikelse med sosiale nettverk fra data fra sosiale nettverk er på veikartet vårt. Det er ikke på produktet for øyeblikket, men når det gjelder husholdning, er det en del av våre matchende og sammenslående evner. I samsvar med prosessen er det mange knotter og spaker som du kan kontrollere for vekter av bestemte deler av dataene, men det det til slutt lar oss gjøre er å samle alle de individuelle kontaktpostene som kan være en del av samme husstand . Da forstår det forskjellen mellom selskaper og mennesker. I selskaper ser du generelt på begynnelsen, hva slags betydning ordene har i et navn; i et selskap, start fra fronten og jobb mot slutten. Men når du driver med husholdning, vil du virkelig begynne på slutten og jobbe mot fronten med folkenavn. Den forstår det og klarer å gjøre en ganske god jobb med å samle kontakter som tilhører en enkelt husstand.
Eric Kavanagh: Og et siste spørsmål, hva med restaurantkunder? Vi har et godt kunnskapsrike publikummedlem her og spør om du har noen restaurantkunder?
Diana Collins: Egentlig nei. Det vil være nytt vertikalt for oss. Vi vil virkelig være interessert i å forfølge det. Vi har kunder som leverer restauranter, men vi har ingen restauranter som er kunder.
Eric Kavanagh: Ok, ingen bekymringer i det hele tatt. Vel folkens, vi har brent gjennom en time og fem minutter her, så en veldig stor takk til presentatørene våre i dag. Vi vil arkivere denne webcasten slik at alle disse arkivene er tilgjengelige for senere visning. Stor takk til presentatørene våre i dag. Stor takk til selvfølgelig Dez og Robin for deres innsikt, og til Magnitude Software. Dette er gode greier. MDM er her for å bli, folkens, det er det ingen tvil om. Det er veldig viktig å få det sentrale synet som kommer til å bli viktigere etter hvert som tiden går. Jeg må tenke når kundene våre bestemmer at de ikke vil bli mishandlet, de ønsker å få en best mulig behandling og det er slik det kommer til å bli.
Så med det folk, skal vi ta farvel. Takk igjen. Vi snakker med deg i morgen på en annen webcast i morgen, ja. Hot Technology er det hotteste showet i disse dager, vi skal snakke med deg i morgen klokka fire øst. Inntil da, ta vare, folkens. Buh-bye.
