Varför teamkommunikation är viktigare än din Martech Stack

Marknadsföringsteams kommunikation och analys

Simo Ahavas atypiska syn på datakvalitet och kommunikationsstrukturer fräschade upp hela loungen på Gå Analytics! konferens. OWOX, MarTech-ledaren i OSS-regionen, välkomnade tusentals experter till denna sammankomst för att dela med sig av sina kunskaper och idéer.

OWOX BI-team vill att du ska tänka över konceptet som föreslås av Simo Ahava, som definitivt har potential att få ditt företag att växa. 

Kvaliteten på data och organisationens kvalitet

Kvaliteten på data beror på personen som analyserar den. Vanligtvis skulle vi skylla på alla brister i data om verktyg, arbetsflöden och datamängder. Men är det rimligt?

Uppriktigt sagt är datakvaliteten direkt kopplad till hur vi kommunicerar inom våra organisationer. Organisationens kvalitet avgör allt, med början med tillvägagångssättet för datamining, uppskattning och mätning, fortsätter med bearbetning och slutar med produktens övergripande kvalitet och beslutsfattande. 

Företag och deras kommunikationsstrukturer

Låt oss föreställa oss att ett företag är specialiserat på ett verktyg. Människorna i det här företaget är bra på att hitta vissa problem och lösa dem för B2B-segmentet. Allt är bra, och du känner utan tvekan till ett par företag som detta.

Biverkningarna av dessa företags aktiviteter är dolda i den långsiktiga processen att höja kraven på datakvalitet. Samtidigt bör vi komma ihåg att verktyg som skapats för att analysera data fungerar endast med data och är isolerade från affärsproblemen - även om de är skapade för att lösa dem. 

Det är därför en annan typ av företag har dykt upp. Dessa företag är specialiserade på felsökning av arbetsflöden. De kan hitta en hel massa problem i affärsprocesser, sätta dem på en whiteboard och berätta för cheferna:

Här, här och där! Tillämpa denna nya affärsstrategi så kommer du ha det bra!

Men det låter för bra för att vara sant. Effektiviteten i råd som inte bygger på en förståelse för verktygen är tveksamt. Och dessa konsultföretag tenderar inte att förstå varför sådana problem uppstod, varför varje ny dag medför nya komplexiteter och fel och vilka verktyg som har ställts in felaktigt.

Så användbarheten för dessa företag på egen hand är begränsad. 

Det finns företag med både affärskunskap och kunskap om verktyg. I dessa företag är alla besatta av att anställa människor med höga kvaliteter, experter som är säkra på sina färdigheter och kunskaper. Häftigt. Men vanligtvis är dessa företag inte inriktade på att lösa kommunikationsproblem i teamet, vilket de ofta ser som obetydliga. Så när nya problem dyker upp börjar häxjakten - vems fel är det? Kanske BI-specialisterna förvirrade processerna? Nej, programmerarna läste inte den tekniska beskrivningen. Men allt som allt är det verkliga problemet att teamet inte kan tänka klart över problemet för att lösa det tillsammans. 

Detta visar oss att även i ett företag fyllda med coola specialister kommer allt att krävas mer än nödvändigt om organisationen inte är det mogen tillräckligt. Tanken att du måste vara vuxen och vara ansvarig, särskilt i en kris, är det sista som människor tänker på i de flesta företag.

Till och med mitt tvååriga barn som går på dagis verkar mer moget än några av de organisationer jag har arbetat med.

Du kan inte skapa ett effektivt företag bara genom att anställa ett stort antal specialister, eftersom de alla absorberas av någon grupp eller avdelning. Så ledningen fortsätter att anställa specialister, men ingenting förändras eftersom arbetsflödets struktur och logik inte förändras alls.

Om du inte gör något för att skapa kanaler för kommunikation inom och utanför dessa grupper och avdelningar kommer alla dina ansträngningar att vara meningslösa. Därför är kommunikationsstrategi och mognad Ahavas fokus.

Conways lag tillämpas på Analytics-företag

Meningsfulla uppgifter - Conways lag

För femtio år sedan kom en stor programmerare vid namn Melvin Conway med ett förslag som senare blev populärt känt som Conways lag: 

Organisationer som utformar system. . . är tvungna att producera mönster som är kopior av dessa organisationers kommunikationsstrukturer.

Melvin Conway, Conways lag

Dessa tankar uppstod vid en tidpunkt då en dator passade perfekt i ett rum! Tänk dig: Här har vi ett team som arbetar på en dator och där har vi ett annat team som arbetar på en annan dator. Och i verkligheten innebär Conways lag att alla kommunikationsfel som uppträder bland dessa lag kommer att speglas i strukturen och funktionaliteten i de program de utvecklar. 

Författarens anmärkning:

Denna teori har testats hundratals gånger i utvecklingsvärlden och har diskuterats mycket. Den mest säkra definitionen av Conways lag skapades av Pieter Hintjens, en av de mest inflytelserika programmerarna i början av 2000-talet, som sa att "om du är i en skitorganisation kommer du att göra skitprogramvara." (Amdahl to Zipf: Ten Laws of the Physics of People)

Det är lätt att se hur denna lag fungerar i marknadsförings- och analysvärlden. I den här världen arbetar företag med enorma mängder data som samlats in från olika källor. Vi kan alla vara överens om att uppgifterna i sig är rättvisa. Men om du inspekterar datauppsättningen noggrant ser du alla brister i de organisationer som samlade in dessa uppgifter:

  • Värden saknas där ingenjörer inte har pratat om ett problem 
  • Fel format där ingen uppmärksammade och ingen diskuterade antalet decimaler
  • Kommunikationsfördröjningar där ingen vet överföringsformatet (batch eller stream) och vem som måste ta emot informationen

Därför avslöjar system för datautbyte våra brister fullständigt.

Datakvalitet är uppnåendet av verktygsspecialister, experter på arbetsflöden, chefer och kommunikationen mellan alla dessa människor.

De bästa och sämsta kommunikationsstrukturerna för tvärvetenskapliga team

Ett typiskt projektteam i ett MarTech- eller marknadsföringsanalysföretag består av Business Intelligence (BI) -specialister, datavetare, designers, marknadsförare, analytiker och programmerare (i vilken kombination som helst).

Men vad kommer att hända i ett team som inte förstår vikten av kommunikation? Låt oss se. Programmerarna kommer att skriva kod under lång tid och försöka hårt, medan en annan del av teamet bara väntar på att de ska överföra stafettpinnen. Äntligen kommer betaversionen att släppas, och alla kommer att murra om varför det tog så lång tid. Och när den första felet uppträder kommer alla att börja leta efter någon annan att skylla men inte på sätt att undvika situationen som fick dem där. 

Om vi ​​tittar djupare ser vi att ömsesidiga mål inte förstods korrekt (eller alls). Och i en sådan situation får vi en skadad eller bristfällig produkt. 

Uppmuntra tvärvetenskapliga team

De värsta funktionerna i denna situation:

  • Otillräckligt engagemang
  • Otillräckligt deltagande
  • Brist på samarbete
  • Brist på förtroende

Hur kan vi fixa det? Bokstavligen genom att få folk att prata. 

Uppmuntra tvärvetenskapliga team

Låt oss samla alla, sätta diskussionsämnen och planera veckomöten: marknadsföring med BI, programmerare med designers och dataspecialister. Då hoppas vi att människor pratar om projektet. Men det räcker fortfarande inte eftersom lagmedlemmar fortfarande inte pratar om hela projektet och inte pratar med hela laget. Det är lätt att bli snöad med tiotals möten och ingen väg ut och ingen tid att göra jobbet. Och dessa meddelanden efter möten kommer att döda resten av tiden och förståelse för vad man ska göra nästa. 

Därför är mötet bara det första steget. Vi har fortfarande några problem:

  • Dålig kommunikation
  • Brist på ömsesidiga mål
  • Otillräckligt engagemang

Ibland försöker människor förmedla viktig information om projektet till sina kollegor. Men istället för att meddelandet kommer igenom gör ryktemaskinen allt för dem. När människor inte vet hur man delar sina tankar och idéer ordentligt och i rätt miljö kommer information att gå förlorad på vägen till mottagaren. 

Detta är symtom på ett företag som kämpar med kommunikationsproblem. Och det börjar bota dem med möten. Men vi har alltid en annan lösning.

Leda alla att kommunicera över projektet. 

Tvärvetenskaplig kommunikation i team

De bästa funktionerna i detta tillvägagångssätt:

  • Öppenhet
  • Medverkan
  • Kunskaps- och kompetensutbyte
  • Non-stop utbildning

Detta är en extremt komplex struktur som är svår att skapa. Du kanske känner till några ramar som tar detta tillvägagångssätt: Agile, Lean, Scrum. Det spelar ingen roll vad du heter; alla bygger på principen "att göra allt tillsammans samtidigt". Alla dessa kalendrar, uppgiftsköer, demo-presentationer och stand-up-möten syftar till att få folk att prata om projektet ofta och alla tillsammans.

Det är därför jag gillar Agile mycket, för det inkluderar vikten av kommunikation som en förutsättning för projektöverlevnad.

Och om du tror att du är en analytiker som inte gillar Agile, titta på det på ett annat sätt: Det hjälper dig att visa resultaten av ditt arbete - alla dina bearbetade data, de här fantastiska instrumentpanelerna, dina datamängder - för att göra människor uppskattar dina ansträngningar. Men för att göra det måste du träffa dina kollegor och prata med dem vid rundabordet.

Vad kommer härnäst? Alla har börjat prata om projektet. Nu har vi gjort det för att bevisa kvaliteten av projektet. För att göra detta anställer företag vanligtvis en konsult med högsta yrkeskvalifikationer. 

Huvudkriteriet för en bra konsult (jag kan berätta för att jag är konsult) minskar hela tiden sitt engagemang i projektet.

En konsult kan inte bara mata ett företag små bitar av professionella hemligheter eftersom det inte kommer att göra företaget moget och självbärande. Om ditt företag inte redan kan leva utan din konsult bör du överväga kvaliteten på den tjänst du har fått. 

Förresten, en konsult ska inte göra rapporter eller bli ett extra par händer åt dig. Du har dina inre kollegor för det.

Hyra marknadsförare för utbildning, inte delegation

Huvudsyftet med att anställa en konsult är utbildning, fixering av strukturer och processer och underlättande av kommunikation. En konsult roll är inte månadsrapportering utan snarare att implantera sig själv i projektet och vara helt involverad i teamets dagliga rutin.

En bra strategisk marknadsföringskonsult fyller luckor i projektdeltagarnas kunskap och förståelse. Men han eller hon kanske aldrig gör jobbet för någon. Och en dag kommer alla att behöva arbeta bra utan konsulten. 

Resultaten av effektiv kommunikation är frånvaro av häxjakt och fingerpekande. Innan en uppgift påbörjas delar människor sina tvivel och frågor med andra teammedlemmar. Således löses de flesta problemen innan arbetet börjar. 

Låt oss se hur allt detta påverkar den mest komplicerade delen av jobbet för marknadsanalys: att definiera dataflöden och slå samman data.

Hur speglas kommunikationsstrukturen i dataöverföring och -behandling?

Låt oss anta att vi har tre källor som ger oss följande data: trafikdata, e-handelsproduktdata / inköpsdata från lojalitetsprogrammet och mobilanalysdata. Vi går igenom databehandlingsstegen en efter en, från att strömma all den informationen till Google Cloud till att skicka allt för visualisering i Google Data Studio med hjälp av Google BigQuery

Baserat på vårt exempel, vilka frågor ska människor ställa för att säkerställa tydlig kommunikation under varje steg i databehandlingen?

  • Datainsamlingssteg. Om vi ​​glömmer att mäta något viktigt kan vi inte gå tillbaka i tiden och mäta om det. Saker att tänka på i förväg:
    • Om vi ​​inte vet vad vi ska namnge de viktigaste parametrarna och variablerna, hur kan vi hantera all röran?
    • Hur kommer händelser att flaggas?
    • Vad blir den unika identifieraren för valda dataflöden?
    • Hur ska vi ta hand om säkerhet och integritet? 
    • Hur samlar vi in ​​data där det finns begränsningar för datainsamlingen?
  • Sammanfoga data strömmar in i strömmen. Tänk på följande:
    • De viktigaste ETL-principerna: Är det en batch- eller strömtyp för dataöverföring? 
    • Hur ska vi markera sammankopplingen av ström- och batchdataöverföringar? 
    • Hur kommer vi att justera dem i samma dataskema utan förluster och misstag?
    • Frågor om tid och kronologi: Hur ska vi kontrollera tidsstämplarna? 
    • Hur kan vi veta om datarenovering och anrikning fungerar korrekt inom tidsstämplar?
    • Hur validerar vi träffar? Vad händer med ogiltiga träffar?

  • Datainsamlingssteg. Saker att tänka på:
    • Specialiserade inställningar för ETL-processer: Vad har vi att göra med ogiltiga data?
      Patch eller ta bort? 
    • Kan vi få vinst av det? 
    • Hur kommer det att påverka kvaliteten på hela datamängden?

Den första principen för alla dessa steg är att misstagen staplas ovanpå varandra och ärver från varandra. Data som samlas in med en brist i det första steget kommer att göra att ditt huvud brinner något under alla efterföljande steg. Och den andra principen är att du ska välja poäng för datakvalitetssäkring. Eftersom i aggregeringsfasen blandas alla data tillsammans och du kommer inte att kunna påverka kvaliteten på den blandade datan. Detta är verkligen viktigt för maskininlärningsprojekt, där datakvaliteten kommer att påverka kvaliteten på maskininlärningsresultaten. Bra resultat kan inte uppnås med lågkvalitetsdata.

  • Visualisering
    Detta är VD-scenen. Du kanske har hört talas om situationen när VD tittar på siffrorna på instrumentpanelen och säger: ”Okej, vi har fått mycket vinst i år, ännu mer än tidigare, men varför är alla ekonomiska parametrar i den röda zonen ? ” Och just nu är det för sent att leta efter misstagen, eftersom de borde ha fångats för länge sedan.

Allt är baserat på kommunikation. Och om ämnena för konversationen. Här är ett exempel på vad som bör diskuteras när du förbereder Yandex-streaming:

Marknadsförings BI: Snowplow, Google Analytics, Yandex

Svaren på de flesta av dessa frågor hittar du bara tillsammans med hela teamet. För när någon fattar ett beslut baserat på gissning eller personlig åsikt utan att testa idén med andra, kan misstag uppstå.

Komplexiteter finns överallt, även på de enklaste platserna.

Här är ytterligare ett exempel: När du spårar visningspoängen för produktkort märker en analytiker ett fel. I träffdata skickades alla intryck från alla banners och produktkort direkt efter sidladdning. Men vi kan inte vara säkra på om användaren verkligen tittade på allt på sidan. Analytikern kommer till teamet för att informera dem om detta i detalj.

BI säger att vi inte kan lämna situationen så.

Hur kan vi beräkna CPM om vi inte ens kan vara säkra på om produkten visades? Vad är den kvalificerade CTR för bilderna då?

Marknadsförarna svarar:

Titta, alla, vi kan skapa en rapport som visar bästa CTR och verifiera den mot en liknande kreativ banner eller foto på andra ställen.

Och då kommer utvecklarna att säga:

Ja, vi kan lösa detta problem med hjälp av vår nya integration för rullningsspårning och synlighetskontroll av ämnen.

Slutligen säger UI / UX-designers:

Ja! Vi kan välja om vi äntligen behöver den lata eller eviga rullningen eller paginering!

Här är stegen som detta lilla team gick igenom:

  1. Definierade problemet
  2. Presenterade affärens konsekvenser av problemet
  3. Mätte effekterna av förändringar
  4. Presenterade tekniska beslut
  5. Upptäckte den icke-triviala vinsten

För att lösa detta problem bör de kontrollera datainsamlingen från alla system. En partiell lösning i en del av dataschemat löser inte affärsproblemet.

justera justera design

Det är därför vi måste arbeta tillsammans. Uppgifterna måste samlas in ansvarsfullt varje dag, och det är hårt arbete att göra det. Och den datakvaliteten måste uppnås genom anställa rätt personer, köpa rätt verktyg och investera pengar, tid och ansträngningar i att konstruera effektiva kommunikationsstrukturer, som är viktiga för en organisations framgång.

Vad tror du?

Den här sidan använder Akismet för att minska spam. Läs om hur din kommentardata behandlas.