Waarom teamcommunicatie belangrijker is dan uw Martech-stack

Marketingteam communicatie en analyse

Simo Ahava's atypische kijk op datakwaliteit en communicatiestructuren verfrist de hele lounge aan de Ga voor Analytics! conferentie. OWOX, de MarTech-leider in de GOS-regio, verwelkomde duizenden experts op deze bijeenkomst om hun kennis en ideeën te delen.

OWOX BI-team zou graag willen dat u nadenkt over het concept voorgesteld door Simo Ahava, dat zeker de potentie heeft om uw bedrijf te laten groeien. 

De kwaliteit van gegevens en kwaliteit van de organisatie

De kwaliteit van de gegevens hangt af van de persoon die ze analyseert. Meestal zouden we alle fouten in de gegevens de schuld geven van tools, workflows en datasets. Maar is dat redelijk?

Eerlijk gezegd is de kwaliteit van data direct verbonden met hoe we communiceren binnen onze organisaties. De kwaliteit van de organisatie bepaalt alles, te beginnen met de aanpak van datamining, schatting en meting, door te gaan met de verwerking en eindigend met de algehele kwaliteit van het product en de besluitvorming. 

Bedrijven en hun communicatiestructuren

Stel je voor dat een bedrijf gespecialiseerd is in één tool. De mensen in dit bedrijf zijn goed in het vinden van bepaalde problemen en het oplossen ervan voor het B2B-segment. Alles is geweldig, en u kent ongetwijfeld een paar van dit soort bedrijven.

De neveneffecten van de activiteiten van deze bedrijven gaan schuil in het langetermijnproces van het verhogen van de eisen aan datakwaliteit. Tegelijkertijd moeten we niet vergeten dat tools die zijn gemaakt om gegevens te analyseren, alleen met gegevens werken en geïsoleerd zijn van de bedrijfsproblemen, zelfs als ze zijn gemaakt om ze op te lossen. 

Daarom is er een ander soort firma ontstaan. Deze bedrijven zijn gespecialiseerd in het debuggen van workflows. Ze kunnen een heleboel problemen in bedrijfsprocessen vinden, ze op een whiteboard plaatsen en de leidinggevenden vertellen:

Hier, hier en daar! Pas deze nieuwe bedrijfsstrategie toe en het komt wel goed!

Maar het klinkt te mooi om waar te zijn. De efficiëntie van advies dat niet is gebaseerd op een goed begrip van de tools, is twijfelachtig. En die adviesbureaus hebben de neiging niet te begrijpen waarom dergelijke problemen opdoken, waarom elke nieuwe dag nieuwe complexiteiten en fouten met zich meebrengt en welke tools verkeerd zijn ingesteld.

Het nut van deze bedrijven alleen is dus beperkt. 

Er zijn bedrijven met zowel zakelijke expertise als kennis van tools. In deze bedrijven is iedereen geobsedeerd door het inhuren van mensen met grote kwaliteiten, experts die zeker zijn van hun vaardigheden en kennis. Stoer. Maar doorgaans zijn deze bedrijven niet gericht op het oplossen van communicatieproblemen binnen het team, die ze vaak als onbelangrijk beschouwen. Dus als er nieuwe problemen verschijnen, begint de heksenjacht - wiens schuld is het? Misschien hebben de BI-specialisten de processen door elkaar gehaald? Nee, de programmeurs hebben de technische beschrijving niet gelezen. Maar al met al is het echte probleem dat het team niet helder over het probleem kan nadenken om het samen op te lossen. 

Dit laat ons zien dat zelfs in een bedrijf vol met coole specialisten alles meer moeite zal kosten dan nodig is als de organisatie dat niet is volwassen genoeg. Het idee dat je de volwassene moet zijn en verantwoordelijk moet zijn, vooral in een crisis, is het laatste waar mensen in de meeste bedrijven aan denken.

Zelfs mijn tweejarige kind dat naar de kleuterschool gaat, lijkt volwassener dan sommige van de organisaties waarmee ik heb gewerkt.

Je kunt geen efficiënt bedrijf creëren door alleen een groot aantal specialisten in te huren, aangezien ze allemaal opgaan in een groep of afdeling. Het management blijft dus specialisten inhuren, maar er verandert niets omdat de structuur en logica van de workflow helemaal niet verandert.

Als u niets doet om communicatiekanalen binnen en buiten deze groepen en afdelingen te creëren, zullen al uw inspanningen zinloos zijn. Daarom staan ​​communicatiestrategie en volwassenheid bij Ahava centraal.

De wet van Conway was van toepassing op analysebedrijven

Zinvolle gegevens - de wet van Conway

Vijftig jaar geleden deed een geweldige programmeur genaamd Melvin Conway een suggestie die later in de volksmond bekend werd als de wet van Conway: 

Organisaties die systemen ontwerpen. . . worden gedwongen om ontwerpen te produceren die kopieën zijn van de communicatiestructuren van deze organisaties.

Melvin Conway, de wet van Conway

Deze gedachten verschenen in een tijd dat een computer perfect in een kamer paste! Stel je voor: hier hebben we een team dat aan de ene computer werkt, en daar hebben we een ander team dat aan een andere computer werkt. En in het echte leven betekent de wet van Conway dat alle communicatiefouten die tussen die teams optreden, zullen worden weerspiegeld in de structuur en functionaliteit van de programma's die ze ontwikkelen. 

Notitie van de auteur:

Deze theorie is honderden keren getest in de ontwikkelingswereld en er is veel over gediscussieerd. De meest zekere definitie van Conway's wet is bedacht door Pieter Hintjens, een van de meest invloedrijke programmeurs van de vroege jaren 2000, die zei dat "als je in een waardeloze organisatie zit, je waardeloze software zult maken." (Amdahl tot Zipf: tien wetten van de fysica van mensen)

Het is gemakkelijk in te zien hoe deze wet werkt in de marketing- en analysewereld. In deze wereld werken bedrijven met gigantische hoeveelheden gegevens die uit verschillende bronnen zijn verzameld. We zijn het er allemaal over eens dat de gegevens zelf eerlijk zijn. Maar als u datasets nauwkeurig inspecteert, ziet u alle onvolkomenheden van de organisaties die die gegevens hebben verzameld:

  • Ontbrekende waarden waarbij ingenieurs een probleem niet hebben besproken 
  • Verkeerde formaten waar niemand op lette en niemand het aantal decimalen besprak
  • Communicatievertragingen waarbij niemand het overdrachtformaat (batch of stream) kent en wie de gegevens moet ontvangen

Dat is de reden waarom systemen voor gegevensuitwisseling onze onvolkomenheden volledig onthullen.

Datakwaliteit is de prestatie van toolspecialisten, workflowexperts, managers en de communicatie tussen al deze mensen.

De beste en slechtste communicatiestructuren voor multidisciplinaire teams

Een typisch projectteam in een MarTech- of marketinganalysebedrijf bestaat uit business intelligence (BI) -specialisten, datawetenschappers, ontwerpers, marketeers, analisten en programmeurs (in elke combinatie).

Maar wat gebeurt er in een team dat het belang van communicatie niet begrijpt? Laten we zien. De programmeurs zullen lang code schrijven en hard hun best doen, terwijl een ander deel van het team gewoon wacht tot ze het stokje doorgeven. Eindelijk komt de bètaversie uit en iedereen zal mompelen waarom het zo lang heeft geduurd. En wanneer de eerste fout zich voordoet, zal iedereen op zoek gaan naar iemand anders om de schuld te geven, maar niet naar manieren om de situatie te vermijden die hen daar heeft gebracht. 

Als we dieper kijken, zullen we zien dat de wederzijdse doelen niet goed (of helemaal niet) werden begrepen. En in zo'n situatie krijgen we een beschadigd of defect product. 

Moedig multidisciplinaire teams aan

De ergste kenmerken van deze situatie:

  • Onvoldoende betrokkenheid
  • Onvoldoende deelname
  • Gebrek aan samenwerking
  • Gebrek aan vertrouwen

Hoe kunnen we dit oplossen? Letterlijk door mensen aan het praten te krijgen. 

Moedig multidisciplinaire teams aan

Laten we iedereen bij elkaar brengen, discussiepunten stellen en wekelijkse bijeenkomsten plannen: marketing met BI, programmeurs met designers en dataspecialisten. Dan hopen we dat mensen over het project praten. Maar dat is nog niet genoeg, want teamleden praten nog steeds niet over het hele project en praten niet met het hele team. Het is gemakkelijk om ondergesneeuwd te raken met tientallen vergaderingen en geen uitweg en geen tijd om het werk te doen. En die berichten na vergaderingen zullen de rest van de tijd en het begrip van wat te doen, doden. 

Daarom is ontmoeting slechts de eerste stap. We hebben nog steeds enkele problemen:

  • Slechte communicatie
  • Gebrek aan gemeenschappelijke doelen
  • Onvoldoende betrokkenheid

Soms proberen mensen belangrijke informatie over het project door te geven aan hun collega's. Maar in plaats van dat de boodschap doorkomt, doet de geruchtenmachine alles voor hen. Wanneer mensen niet weten hoe ze hun gedachten en ideeën op de juiste manier en in de juiste omgeving moeten delen, gaat informatie verloren op weg naar de ontvanger. 

Dit zijn symptomen van een bedrijf dat worstelt met communicatieproblemen. En het begint ze te genezen met bijeenkomsten. Maar we hebben altijd een andere oplossing.

Leid iedereen om over het project te communiceren. 

Multidisciplinaire communicatie in teams

De beste kenmerken van deze aanpak:

  • Transparantie
  • betrokkenheid
  • Uitwisseling van kennis en vaardigheden
  • Non-stop onderwijs

Dit is een buitengewoon complexe structuur die moeilijk te creëren is. Misschien ken je een paar frameworks die deze aanpak volgen: Agile, Lean, Scrum. Het maakt niet uit hoe je het noemt; ze zijn allemaal gebaseerd op het principe 'alles tegelijk samen maken'. Al die agenda's, takenwachtrijen, demopresentaties en stand-up meetings zijn bedoeld om mensen regelmatig en gezamenlijk over het project te laten praten.

Dat is waarom ik Agile erg leuk vind, omdat het het belang van communicatie omvat als voorwaarde voor het overleven van projecten.

En als je denkt dat je een analist bent die Agile niet leuk vindt, bekijk het dan op een andere manier: het helpt je om de resultaten van je werk te laten zien - al je verwerkte data, die geweldige dashboards, je datasets - om mensen waardeer je inzet. Maar om dat te doen, moet je je collega's ontmoeten en met ze praten aan de ronde tafel.

Wat is het volgende? Iedereen is begonnen over het project te praten. Nu hebben we om de kwaliteit te bewijzen van het project. Om dit te doen, huren bedrijven doorgaans een consultant in met de hoogste beroepskwalificaties. 

Het belangrijkste criterium voor een goede consultant (ik kan het je vertellen omdat ik een consultant ben) is dat hij steeds minder betrokken wordt bij het project.

Een consultant kan een bedrijf niet zomaar kleine stukjes professionele geheimen geven, want dat maakt het bedrijf niet volwassen en zelfvoorzienend. Als uw bedrijf niet al zonder uw adviseur kan leven, moet u rekening houden met de kwaliteit van de service die u heeft ontvangen. 

Een consultant mag overigens geen rapporten maken of een extra paar handen voor u worden. Daarvoor heb je je interne collega's.

Marketeers inhuren voor onderwijs, niet voor delegatie

Het belangrijkste doel van het inhuren van een consultant is onderwijs, het vastleggen van structuren en processen en het faciliteren van communicatie. De rol van een consultant bestaat niet uit maandelijkse rapportage, maar eerder zichzelf in het project te implanteren en volledig betrokken te zijn bij de dagelijkse routine van het team.

Een goede strategisch marketingadviseur vult hiaten in de kennis en het begrip van projectdeelnemers. Maar hij of zij mag het werk nooit voor iemand doen. En op een dag zal iedereen prima moeten werken zonder de consulent. 

De resultaten van effectieve communicatie zijn de afwezigheid van heksenjacht en vinger wijzen. Voordat een taak wordt gestart, delen mensen hun twijfels en vragen met andere teamleden. Zo zijn de meeste problemen opgelost voordat het werk begint. 

Laten we eens kijken hoe dat allemaal het meest gecompliceerde deel van de marketinganalyse-taak beïnvloedt: gegevensstromen definiëren en gegevens samenvoegen.

Hoe wordt de communicatiestructuur weerspiegeld in gegevensoverdracht en -verwerking?

Stel dat we drie bronnen hebben die ons de volgende gegevens geven: verkeersgegevens, productgegevens van e-commerce / aankoopgegevens van het loyaliteitsprogramma en gegevens voor mobiele analyse. We doorlopen de gegevensverwerkingsfasen een voor een, van het streamen van al die gegevens naar Google Cloud tot het verzenden van alles voor visualisatie Google Data Studio met de hulp van Google BigQuery

Welke vragen moeten mensen op basis van ons voorbeeld stellen om te zorgen voor duidelijke communicatie tijdens elke fase van de gegevensverwerking?

  • Gegevensverzamelingsfase. Als we iets belangrijks vergeten te meten, kunnen we niet terug in de tijd gaan en het opnieuw meten. Dingen om vooraf te overwegen:
    • Als we niet weten hoe we de belangrijkste parameters en variabelen moeten noemen, hoe kunnen we dan met al die rotzooi omgaan?
    • Hoe worden evenementen gemarkeerd?
    • Wat wordt de unieke identificatiecode voor de gekozen gegevensstromen?
    • Hoe zorgen we voor veiligheid en privacy? 
    • Hoe zullen we gegevens verzamelen als er beperkingen zijn op het verzamelen van gegevens?
  • Het samenvoegen van gegevens stroomt in de stream. Stel je de volgende situatie voor:
    • De belangrijkste ETL-principes: is het een batch- of stream-type gegevensoverdracht? 
    • Hoe markeren we de combinatie van stream- en batchgegevensoverdrachten? 
    • Hoe passen we ze aan in hetzelfde gegevensschema zonder verliezen en fouten?
    • Tijd- en chronologievragen: hoe controleren we de tijdstempels? 
    • Hoe kunnen we weten of gegevensrenovatie en -verrijking correct werkt binnen tijdstempels?
    • Hoe valideren we treffers? Wat gebeurt er met ongeldige treffers?

  • Gegevensverzamelingsfase. Dingen om te overwegen:
    • Gespecialiseerde instellingen voor ETL-processen: wat hebben we te maken met ongeldige gegevens?
      Patch of verwijderen? 
    • Kunnen we er winst uit halen? 
    • Hoe zal het de kwaliteit van de hele dataset beïnvloeden?

Het eerste principe voor al deze fasen is dat de fouten op elkaar stapelen en van elkaar overerven. Gegevens die in de eerste fase met een fout zijn verzameld, zullen uw hoofd tijdens alle volgende fasen lichtjes doen branden. En het tweede principe is dat je punten kiest voor datakwaliteitsborging. Omdat in de aggregatiefase alle gegevens met elkaar worden gemengd en u geen invloed kunt uitoefenen op de kwaliteit van de gemengde gegevens. Dit is erg belangrijk voor machine learning-projecten, waarbij de kwaliteit van de gegevens de kwaliteit van de machine learning-resultaten zal beïnvloeden. Goede resultaten zijn niet haalbaar met gegevens van lage kwaliteit.

  • Visualisatie
    Dit is de CEO-fase. Je hebt misschien gehoord van de situatie wanneer de CEO naar de cijfers op het dashboard kijkt en zegt: “Oké, we hebben dit jaar veel winst gemaakt, zelfs meer dan voorheen, maar waarom staan ​​alle financiële parameters in de rode zone? ? " En op dit moment is het te laat om naar de fouten te zoeken, zoals ze al lang geleden betrapt hadden moeten worden.

Alles is gebaseerd op communicatie. En over de gespreksonderwerpen. Hier is een voorbeeld van wat er moet worden besproken tijdens het voorbereiden van Yandex-streaming:

Marketing BI: sneeuwploeg, Google Analytics, Yandex

De antwoorden op de meeste van deze vragen vind je alleen samen met je hele team. Want als iemand een beslissing neemt op basis van gissen of persoonlijke mening zonder het idee met anderen te testen, kunnen er fouten optreden.

Complexiteit is overal, zelfs op de eenvoudigste plaatsen.

Hier is nog een voorbeeld: bij het bijhouden van de vertoningsscores van productkaarten merkt een analist een fout op. In de hitgegevens werden alle impressies van alle banners en productkaarten direct na het laden van de pagina verzonden. Maar we weten niet zeker of de gebruiker echt alles op de pagina heeft bekeken. De analist komt naar het team om hen hierover gedetailleerd te informeren.

De BI zegt dat we de situatie niet zo kunnen laten.

Hoe kunnen we de CPM berekenen als we niet eens zeker weten of het product werd getoond? Wat is dan de gekwalificeerde CTR voor de foto's?

De marketeers antwoorden:

Kijk, iedereen, we kunnen een rapport maken met de beste CTR en het vergelijken met een vergelijkbare creatieve banner of foto op andere plaatsen.

En dan zullen de ontwikkelaars zeggen:

Ja, we kunnen dit probleem oplossen met behulp van onze nieuwe integratie voor het volgen van scrollen en het controleren van de zichtbaarheid van onderwerpen.

Ten slotte zeggen de UI / UX-ontwerpers:

Ja! We kunnen kiezen of we eindelijk de luie of eeuwige scroll of paginering nodig hebben!

Dit zijn de stappen die dit kleine team heeft doorlopen:

  1. Definieerde het probleem
  2. Presenteerde de zakelijke gevolgen van het probleem
  3. De impact van veranderingen gemeten
  4. Gepresenteerde technische beslissingen
  5. Ontdekt de niet-triviale winst

Om dit probleem op te lossen, moeten ze de gegevensverzameling van alle systemen controleren. Een gedeeltelijke oplossing in een deel van het gegevensschema lost het bedrijfsprobleem niet op.

uitlijnen ontwerp aanpassen

Daarom moeten we samenwerken. De gegevens moeten elke dag op een verantwoorde manier worden verzameld, en het is hard werken om dat te doen. En de kwaliteit van de gegevens moet worden bereikt door de juiste mensen aannemen, de juiste tools aanschaffen en geld, tijd en moeite investeren in het opzetten van effectieve communicatiestructuren, die essentieel zijn voor het succes van een organisatie.

Wat denk je?

Deze site gebruikt Akismet om spam te verminderen. Ontdek hoe uw reactiegegevens worden verwerkt.