Hvorfor teamkommunikasjon er viktigere enn din Martech Stack

Markedsføringsteams kommunikasjon og analyse

Simo Ahavas atypiske synspunkt på datakvalitet og kommunikasjonsstrukturer friske opp hele salongen på Gå Analytics! konferanse. OWOX, MarTech-lederen i CIS-regionen, ønsket tusenvis av eksperter velkommen til denne samlingen for å dele sin kunnskap og ideer.

OWOX BI-team ønsker at du tenker over konseptet som er foreslått av Simo Ahava, som definitivt har potensial til å få virksomheten din til å vokse. 

Kvaliteten på data og kvaliteten på organisasjonen

Kvaliteten på dataene avhenger av personen som analyserer dem. Vanligvis vil vi skylde på alle feil i dataene på verktøy, arbeidsflyter og datasett. Men er det rimelig?

Oppriktig sagt er kvaliteten på dataene direkte knyttet til hvordan vi kommuniserer i organisasjonene våre. Organisasjonens kvalitet bestemmer alt, med utgangspunkt i tilnærming til datautvinning, estimering og måling, fortsetter med prosessering og slutter med den generelle kvaliteten på produktet og beslutningstaking. 

Bedrifter og deres kommunikasjonsstrukturer

La oss forestille oss at et selskap spesialiserer seg på ett verktøy. Menneskene i dette selskapet er gode på å finne visse problemer og løse dem for B2B-segmentet. Alt er bra, og uten tvil kjenner du et par selskaper som dette.

Bivirkningene av disse selskapenes aktiviteter er skjult i den langsiktige prosessen med å heve kravene til datakvalitet. Samtidig bør vi huske at verktøy som er opprettet for å analysere data, bare fungerer med data og er isolert fra forretningsproblemene - selv om de er laget for å løse dem. 

Det er derfor en annen type firma har dukket opp. Disse selskapene er spesialiserte i feilsøking av arbeidsflyt. De kan finne en hel rekke problemer i forretningsprosesser, sette dem på en tavle og fortelle lederne:

Her, her og der! Hvis du bruker denne nye forretningsstrategien, vil du ha det bra!

Men det høres for bra ut til å være sant. Effektiviteten av råd som ikke er basert på forståelse av verktøyene er tvilsom. Og de konsulentfirmaene har en tendens til ikke å forstå hvorfor slike problemer dukket opp, hvorfor hver nye dag gir nye kompleksiteter og feil, og hvilke verktøy som ble satt opp feil.

Så nytten av disse selskapene alene er begrenset. 

Det er selskaper med både forretningskompetanse og kunnskap om verktøy. I disse selskapene er alle besatt av å ansette folk med gode kvaliteter, eksperter som er sikre på sine ferdigheter og kunnskaper. Kul. Men vanligvis er disse selskapene ikke rettet mot å løse kommunikasjonsproblemer i teamet, noe de ofte ser på som uviktige. Så når nye problemer dukker opp, starter heksejakten - hvis feil er det? Kanskje forvirret BI-spesialistene prosessene? Nei, programmererne leste ikke den tekniske beskrivelsen. Men alt i alt er det virkelige problemet at teamet ikke kan tenke klart over problemet for å løse det sammen. 

Dette viser oss at selv i et selskap fylt med kule spesialister vil alt kreve mer innsats enn nødvendig hvis organisasjonen ikke er det moden nok. Tanken om at du må være voksen og være ansvarlig, spesielt i en krise, er det siste folk tenker på i de fleste selskaper.

Selv barnet mitt på to år som går i barnehagen virker mer modent enn noen av organisasjonene jeg har jobbet med.

Du kan ikke opprette et effektivt selskap bare ved å ansette et stort antall spesialister, da de alle blir absorbert av en gruppe eller avdeling. Så ledelsen fortsetter å ansette spesialister, men ingenting endres fordi strukturen og logikken i arbeidsflyten ikke endres i det hele tatt.

Hvis du ikke gjør noe for å skape kommunikasjonskanaler i og utenfor disse gruppene og avdelingene, vil all din innsats være meningsløs. Derfor er kommunikasjonsstrategi og modenhet Ahavas fokus.

Conways lov anvendt på Analytics-selskaper

Meningsfylte data - Conways lov

For femti år siden kom en flott programmerer ved navn Melvin Conway med et forslag som senere ble populært kjent som Conways lov: 

Organisasjoner som designer systemer. . . er tvunget til å produsere design som er kopier av kommunikasjonsstrukturene til disse organisasjonene.

Melvin Conway, Conways lov

Disse tankene dukket opp på en tid da en datamaskin passet perfekt til ett rom! Tenk deg: Her har vi ett team som jobber på en datamaskin, og der har vi et annet team som jobber på en annen datamaskin. Og i det virkelige livet betyr Conways lov at alle kommunikasjonsfeil som vises blant disse teamene, vil bli speilet i strukturen og funksjonaliteten til programmene de utvikler. 

Forfatterens merknad:

Denne teorien har blitt testet hundrevis av ganger i utviklingsverdenen og har blitt diskutert mye. Den mest sikre definisjonen av Conways lov ble skapt av Pieter Hintjens, en av de mest innflytelsesrike programmererne på begynnelsen av 2000-tallet, som sa at "hvis du er i en dritt organisasjon, vil du lage skitne programvare." (Amdahl til Zipf: Ten Laws of the Physics of People)

Det er lett å se hvordan denne loven fungerer i markedsførings- og analyseverdenen. I denne verden jobber selskaper med enorme mengder data samlet fra forskjellige kilder. Vi kan alle være enige om at dataene i seg selv er rettferdige. Men hvis du inspiserer datasett nøye, vil du se alle ufullkommenhetene til organisasjonene som samlet inn dataene:

  • Manglende verdier der ingeniører ikke har snakket gjennom et problem 
  • Feil formater der ingen tok hensyn og ingen diskuterte antall desimaler
  • Kommunikasjonsforsinkelser der ingen vet formatet for overføring (batch eller stream) og hvem som må motta dataene

Derfor avslører datautvekslingssystemene våre mangler fullstendig.

Datakvalitet er oppnåelsen av verktøyspesialister, arbeidsflyteksperter, ledere og kommunikasjonen mellom alle disse menneskene.

De beste og verste kommunikasjonsstrukturene for tverrfaglige team

Et typisk prosjektteam i et MarTech- eller markedsføringsanalyseselskap består av Business Intelligence (BI) -spesialister, dataforskere, designere, markedsførere, analytikere og programmerere (i en hvilken som helst kombinasjon).

Men hva vil skje i et team som ikke forstår viktigheten av kommunikasjon? La oss se. Programmørene vil skrive kode i lang tid og prøve hardt, mens en annen del av teamet bare vil vente på at de skal overføre stafettpinnen. Endelig vil betaversjonen bli utgitt, og alle vil murre om hvorfor det tok så lang tid. Og når den første feilen dukker opp, vil alle begynne å lete etter noen andre å klandre, men ikke etter måter å unngå situasjonen som fikk dem dit. 

Hvis vi ser dypere, vil vi se at gjensidige mål ikke ble forstått riktig (eller i det hele tatt). Og i en slik situasjon får vi et skadet eller feil produkt. 

Oppmuntre tverrfaglige team

De verste funksjonene i denne situasjonen:

  • Utilstrekkelig involvering
  • Mangelfull deltakelse
  • Manglende samarbeid
  • Mangel på tillit

Hvordan kan vi fikse det? Bokstavelig talt ved å få folk til å snakke. 

Oppmuntre tverrfaglige team

La oss samle alle sammen, sette diskusjonstemaer og planlegge ukentlige møter: markedsføring med BI, programmerere med designere og dataspesialister. Så håper vi at folk snakker om prosjektet. Men det er fortsatt ikke nok fordi teammedlemmer fortsatt ikke snakker om hele prosjektet og ikke snakker med hele teamet. Det er lett å bli snødd med titalls møter og ingen vei ut og ingen tid til å gjøre jobben. Og disse meldingene etter møtene vil drepe resten av tiden og forståelsen av hva du skal gjøre videre. 

Derfor er møte bare det første trinnet. Vi har fortsatt noen problemer:

  • Dårlig kommunikasjon
  • Mangel på gjensidige mål
  • Utilstrekkelig involvering

Noen ganger prøver folk å formidle viktig informasjon om prosjektet til sine kolleger. Men i stedet for at meldingen kommer igjennom, gjør ryktemaskinen alt for dem. Når folk ikke vet hvordan de skal dele tankene og ideene sine riktig og i riktig miljø, vil informasjon gå tapt på vei til mottakeren. 

Dette er symptomer på et selskap som sliter med kommunikasjonsproblemer. Og det begynner å kurere dem med møter. Men vi har alltid en annen løsning.

Led alle til å kommunisere over prosjektet. 

Tverrfaglig kommunikasjon i team

De beste funksjonene i denne tilnærmingen:

  • Åpenhet
  • Involvering
  • Kunnskap og kompetanseutveksling
  • Uavbrutt utdanning

Dette er en ekstremt kompleks struktur som er vanskelig å lage. Du kjenner kanskje til noen rammer som tar denne tilnærmingen: Agile, Lean, Scrum. Det spiller ingen rolle hva du heter det; alle er bygget på "å lage alt sammen samtidig" -prinsippet. Alle kalenderne, oppgavekøene, demopresentasjonene og stand-up-møtene tar sikte på å få folk til å snakke om prosjektet ofte og alt sammen.

Derfor liker jeg Agile mye, fordi det inkluderer viktigheten av kommunikasjon som en forutsetning for prosjektoverlevelse.

Og hvis du tror du er en analytiker som ikke liker Agile, kan du se på det på en annen måte: Det hjelper deg å vise resultatene av arbeidet ditt - alle de behandlede dataene dine, de flotte dashbordene, datasettene dine - for å få folk setter pris på innsatsen din. Men for å gjøre det må du møte kollegene dine og snakke med dem ved rundebordet.

Hva blir det neste? Alle har begynt å snakke om prosjektet. Nå har vi gjort det for å bevise kvaliteten av prosjektet. For å gjøre dette ansetter selskaper vanligvis en konsulent med høyest faglige kvalifikasjoner. 

Hovedkriteriet for en god konsulent (jeg kan fortelle deg fordi jeg er konsulent) reduserer stadig hans engasjement i prosjektet.

En konsulent kan ikke bare mate et selskap med små faglige hemmeligheter fordi det ikke vil gjøre selskapet modent og selvforsynt. Hvis firmaet ikke allerede kan leve uten konsulenten din, bør du vurdere kvaliteten på tjenesten du har mottatt. 

Forresten, en konsulent skal ikke lage rapporter eller bli et ekstra par hender for deg. Du har dine innvendige kolleger for det.

Ansett markedsførere for utdanning, ikke delegasjon

Hovedmålet med å ansette en konsulent er utdannelse, fikse strukturer og prosesser og legge til rette for kommunikasjon. En konsulents rolle er ikke månedlig rapportering, men heller implantering av seg selv i prosjektet og å være helt involvert i teamets daglige rutine.

En god strategisk markedsføringskonsulent fyller hull i kunnskapen og forståelsen til prosjektdeltakerne. Men han eller hun kan aldri gjøre jobben for noen. Og en dag vil alle trenge å jobbe helt fint uten konsulenten. 

Resultatene av effektiv kommunikasjon er fravær av heksejakt og fingerpeking. Før en oppgave startes, deler folk sin tvil og spørsmål med andre teammedlemmer. Dermed løses de fleste problemene før arbeidet begynner. 

La oss se hvordan alt dette påvirker den mest kompliserte delen av jobben med markedsanalyse: å definere datastrømmer og slå sammen data.

Hvordan speiles kommunikasjonsstrukturen i dataoverføring og -behandling?

La oss anta at vi har tre kilder som gir oss følgende data: trafikkdata, e-handelsproduktdata / kjøpsdata fra lojalitetsprogrammet og mobilanalysedata. Vi vil gå gjennom databehandlingsstadiene en etter en, fra å streame alle dataene til Google Cloud til å sende alt for visualisering i Google Data Studio med hjelp av Google BigQuery

Basert på vårt eksempel, hvilke spørsmål bør folk stille for å sikre klar kommunikasjon i hvert trinn av databehandling?

  • Datainnsamlingsstadium. Hvis vi glemmer å måle noe viktig, kan vi ikke gå tilbake i tid og måle det på nytt. Ting du bør vurdere på forhånd:
    • Hvis vi ikke vet hva vi skal kalle de viktigste parametrene og variablene, hvordan kan vi takle alt rotet?
    • Hvordan blir hendelser flagget?
    • Hva blir den unike identifikatoren for valgte datastrømmer?
    • Hvordan vil vi ivareta sikkerhet og personvern? 
    • Hvordan vil vi samle inn data der det er begrensninger på datainnsamlingen?
  • Sammenslåing av data strømmer inn i strømmen. Vurder følgende:
    • De viktigste ETL-prinsippene: Er det en batch- eller strømtype dataoverføring? 
    • Hvordan vil vi markere sammenhengen mellom overføring av strøm og batchdata? 
    • Hvordan vil vi justere dem i samme dataskjema uten tap og feil?
    • Tids- og kronologispørsmål: Hvordan vil vi sjekke tidsstempel? 
    • Hvordan kan vi vite om dataoppussing og berikelse fungerer riktig innen tidsstempler?
    • Hvordan skal vi validere treff? Hva skjer med ugyldige treff?

  • Dataggregasjonsfase. Ting du bør vurdere:
    • Spesialiserte innstillinger for ETL-prosesser: Hva har vi med ugyldige data å gjøre?
      Patch eller slette? 
    • Kan vi få fortjeneste fra det? 
    • Hvordan vil det påvirke kvaliteten på hele datasettet?

Det første prinsippet for alle disse trinnene er at feilene stabler oppå hverandre og arver fra hverandre. Data som er samlet inn med en feil på første trinn, vil få hodet til å svi litt i alle påfølgende stadier. Og det andre prinsippet er at du bør velge poeng for datakvalitetssikring. Fordi på aggregeringsstadiet blir alle dataene blandet sammen, og du vil ikke kunne påvirke kvaliteten på de blandede dataene. Dette er veldig viktig for maskinlæringsprosjekter, hvor kvaliteten på data vil påvirke kvaliteten på maskinlæringsresultatene. Gode ​​resultater er ikke oppnåelige med data av lav kvalitet.

  • Visualisering
    Dette er konsernsjefstadiet. Du har kanskje hørt om situasjonen når konsernsjefen ser på tallene på dashbordet og sier: "Ok, vi har mye overskudd i år, enda mer enn tidligere, men hvorfor er alle økonomiske parametere i den røde sonen ? ” Og for øyeblikket er det for sent å lete etter feilene, slik de burde vært tatt for lenge siden.

Alt er basert på kommunikasjon. Og om samtaleemnene. Her er et eksempel på hva som bør diskuteres mens du forbereder Yandex-streaming:

Markedsførings BI: Snowplow, Google Analytics, Yandex

Du finner svarene på de fleste av disse spørsmålene bare sammen med hele teamet ditt. For når noen tar en beslutning basert på gjetting eller personlig mening uten å teste ideen med andre, kan det oppstå feil.

Kompleksiteter er overalt, selv på de enkleste stedene.

Her er et eksempel til: Når en analytiker registrerer visningspoengene for produktkort, merker det en feil. I treffdataene ble alle inntrykk fra alle bannere og produktkort sendt rett etter sideinnlasting. Men vi kan ikke være sikre på om brukeren virkelig så på alt på siden. Analytikeren kommer til teamet for å informere dem om dette i detalj.

BI sier at vi ikke kan forlate situasjonen slik.

Hvordan kan vi beregne CPM hvis vi ikke en gang kan være sikre på om produktet ble vist? Hva er den kvalifiserte CTR for bildene da?

Markedsførerne svarer:

Se, alle sammen, vi kan lage en rapport som viser den beste CTR og verifisere den mot et lignende kreativt banner eller bilde andre steder.

Og så vil utviklerne si:

Ja, vi kan løse dette problemet ved hjelp av den nye integrasjonen vår for sporing av rulle og synlighet av emner.

Til slutt sier UI / UX-designerne:

Ja! Vi kan velge om vi til slutt trenger den late eller evige rulle eller paginering!

Her er trinnene dette lille teamet gikk gjennom:

  1. Definerte problemet
  2. Presentert de forretningsmessige konsekvensene av problemet
  3. Målte effekten av endringer
  4. Presenterte tekniske beslutninger
  5. Oppdaget det ikke-trivielle overskuddet

For å løse dette problemet, bør de sjekke datainnsamlingen fra alle systemer. En delvis løsning i en del av dataskjemaet løser ikke forretningsproblemet.

juster juster design

Derfor må vi jobbe sammen. Dataene må samles inn ansvarlig hver dag, og det er vanskelig å gjøre det. Og kvaliteten på dataene må oppnås ved ansette riktige mennesker, kjøpe riktige verktøy og investere penger, tid og krefter i å konstruere effektive kommunikasjonsstrukturer, som er avgjørende for en organisasjons suksess.

Hva tror du?

Dette nettstedet bruker Akismet for å redusere spam. Lær hvordan kommentaren din behandles.