Miks on meeskonnasuhtlus olulisem kui teie Martechi korstnat?

Turundusmeeskonna kommunikatsioon ja analüüs

Simo Ahava ebatüüpiline seisukoht andmete kvaliteedi ja kommunikatsioonistruktuuride kohta värskendas kogu salongi Minge Analyticsi! konverents. OWOX, MarTechi SRÜ piirkonna juht, tervitas sellel koosolekul tuhandeid eksperte, et jagada oma teadmisi ja ideid.

OWOX BI meeskond sooviksin, et mõtleksite läbi Simo Ahava pakutud kontseptsiooni, millel on kindlasti potentsiaali teie äri kasvatada. 

Andmete kvaliteet ja organisatsiooni kvaliteet

Andmete kvaliteet sõltub inimesest, kes neid analüüsib. Tavaliselt süüdistaksime kõiki tööriistade, töövoogude ja andmekogumite andmete puudusi. Kuid kas see on mõistlik?

Ausalt öeldes on andmete kvaliteet otseselt seotud sellega, kuidas me oma organisatsioonides suhtleme. Organisatsiooni kvaliteet määrab kõik, alustades lähenemisviisist andmete hankimisele, hindamisele ja mõõtmisele, jätkates töötlemisega ning lõpetades toote üldise kvaliteedi ja otsuste tegemisega. 

Ettevõtted ja nende kommunikatsioonistruktuurid

Kujutame ette, et ettevõte on spetsialiseerunud ühele tööriistale. Selle ettevõtte inimesed oskavad suurepäraselt leida teatud probleeme ja lahendada neid B2B segmendi jaoks. Kõik on suurepärane ja kahtlemata teate mõnda sellist paari ettevõtet.

Nende ettevõtete tegevuse kõrvalmõjud on peidetud andmete kvaliteedi nõuete tõstmise pikaajalises protsessis. Samal ajal peaksime meeles pidama, et andmete analüüsimiseks loodud tööriistad töötavad ainult andmetega ja on äriprobleemidest eraldatud - isegi kui need on loodud nende lahendamiseks. 

Sellepärast on tekkinud teist tüüpi ettevõte. Need ettevõtted on spetsialiseerunud töövoo silumisele. Nad leiavad äriprotsessidest terve hulga probleeme, panevad need tahvlile ja ütlevad juhtidele:

Siin, siin ja seal! Rakendage see uus äristrateegia ja saate kõik hästi!

Kuid see kõlab liiga hästi, et olla tõsi. Nõuannete tõhusus, mis ei põhine tööriistade mõistmisel, on kaheldav. Ja need konsultatsioonifirmad ei saa aru, miks sellised probleemid ilmnesid, miks iga uus päev toob kaasa uusi keerukusi ja vigu ning millised tööriistad olid valesti üles seatud.

Nii et nende ettevõtete kasulikkus üksi on piiratud. 

On ettevõtteid, kellel on nii äriteadmisi kui ka teadmisi tööriistadest. Nendes ettevõtetes on kõik kinnisideeks palgata suurepäraste omadustega inimesi, eksperte, kes on oma oskustes ja teadmistes kindlad. Lahe. Kuid tavaliselt ei ole need ettevõtted suunatud kommunikatsiooniprobleemide lahendamisele meeskonnas, mida nad peavad sageli ebaoluliseks. Nii et uute probleemide ilmnemisel algab nõiajaht - kelle süü see on? Võib-olla ajasid BI-spetsialistid protsessid sassi? Ei, programmeerijad ei lugenud tehnilist kirjeldust. Kuid kokkuvõttes on tegelik probleem see, et meeskond ei suuda probleemi selgelt läbi mõelda, et see koos lahendada. 

See näitab meile, et isegi lahedate spetsialistidega täidetud ettevõttes võtab kõik, kui organisatsioon seda ei vaja, rohkem kui vaja küps piisav. Idee, et peate olema täiskasvanud inimene ja vastutama, eriti kriisi ajal, on viimane asi, millele inimesed enamikus ettevõtetes mõtlevad.

Isegi mu kaheaastane lasteaias käiv laps tundub küpsem kui mõned organisatsioonid, kellega ma olen koostööd teinud.

Efektiivset ettevõtet ei saa luua ainult paljusid spetsialiste palgates, kuna neid kõiki võtab mõni rühm või osakond. Nii et juhtkond palkab jätkuvalt spetsialiste, kuid midagi ei muutu, kuna töövoo struktuur ja loogika ei muutu üldse.

Kui te ei tee midagi suhtluskanalite loomiseks nendes rühmades ja osakondades ja väljaspool, on kõik teie jõupingutused mõttetud. Seetõttu on Ahava keskmes kommunikatsioonistrateegia ja küpsus.

Analüütikaettevõtetele kehtis Conway seadus

Sisukad andmed - Conway seadus

Viiskümmend aastat tagasi tegi suurepärane programmeerija Melvin Conway ettepaneku, mida hiljem hakati rahva seas nimetama Conway seaduseks: 

Organisatsioonid, kes kavandavad süsteeme. . . on kohustatud tootma kujundusi, mis on nende organisatsioonide kommunikatsioonistruktuuride koopiad.

Melvin Conway, Conway seadus

Need mõtted ilmusid ajal, mil üks arvuti mahtus ühte ruumi ideaalselt! Kujutage vaid ette: siin töötab üks meeskond ühes arvutis ja teine ​​meeskond töötab teises arvutis. Ja tegelikus elus tähendab Conway seadus, et kõik nende meeskondade seas ilmnevad suhtlusvead peegelduvad nende arendatavate programmide ülesehituses ja funktsionaalsuses. 

Autori märkus:

Seda teooriat on arengumaailmas testitud sadu kordi ja seda on palju arutatud. Conway seaduse kõige kindla määratluse lõi 2000. aastate alguse üks mõjukamaid programmeerijaid Pieter Hintjens, kes ütles, et „kui olete jama organisatsioonis, siis teete ka sitta tarkvara”. (Amdahlist Zipfini: Inimeste füüsika kümme seadust)

On lihtne mõista, kuidas see seadus turundus- ja analüüsimaailmas töötab. Selles maailmas töötavad ettevõtted tohutute andmetega, mis on kogutud erinevatest allikatest. Me kõik võime nõustuda, et andmed ise on õiglased. Kuid kui uurite andmekogumeid tähelepanelikult, näete kõiki andmeid kogunud organisatsioonide puudusi:

  • Puuduvad väärtused, kus insenerid pole teemat läbi rääkinud 
  • Valed vormingud, kus keegi ei pööranud tähelepanu ja keegi ei arutanud kümnendkohtade arvu
  • Suhtlemine viibib, kui keegi ei tea edastamise vormingut (partii või voog) ja kes peab andmed vastu võtma

Sellepärast avaldavad andmevahetussüsteemid meie puudused täielikult.

Andmete kvaliteet on tööriistaspetsialistide, töövooekspertide, juhtide ja kõigi nende inimeste vahelise suhtluse saavutus.

Parimad ja halvimad kommunikatsioonistruktuurid multidistsiplinaarsetele meeskondadele

Tüüpiline projektimeeskond MarTechi või turundusanalüütika ettevõttes koosneb äriteabe (BI) spetsialistidest, andmeteadlastest, disaineritest, turundajatest, analüütikutest ja programmeerijatest (mis tahes kombinatsioonis).

Mis saab aga meeskonnast, kes ei mõista suhtluse tähtsust? Vaatame. Programmeerijad kirjutavad pikka aega koodi ja näevad vaeva, samal ajal kui teine ​​osa meeskonnast lihtsalt ootab, kuni nad teatepulga edasi annavad. Lõpuks ilmub beetaversioon ja kõik nurisevad, miks see nii kaua aega võttis. Ja kui ilmneb esimene viga, hakkavad kõik otsima kedagi teist, keda süüdistada, kuid mitte võimalusi, kuidas neid olukorda vältida. 

Kui vaatame sügavamale, näeme, et vastastikuseid eesmärke ei mõistetud õigesti (või üldse). Ja sellises olukorras saame kahjustatud või vigase toote. 

Julgustage multidistsiplinaarseid meeskondi

Selle olukorra halvimad omadused:

  • Ebapiisav kaasatus
  • Ebapiisav osalemine
  • Koostöö puudumine
  • Usalduse puudumine

Kuidas saame selle parandada? Sõna otseses mõttes inimesi rääkima pannes. 

Julgustage multidistsiplinaarseid meeskondi

Kogume kõik koos, määrame aruteluteemad ja lepime kokku iganädalased kohtumised: turundus BI-ga, programmeerijad disainerite ja andmespetsialistidega. Siis loodame, et inimesed räägivad projektist. Kuid sellest pole veel piisavalt, sest meeskonnaliikmed ei räägi endiselt kogu projektist ega räägi kogu meeskonnaga. Kümnete koosolekute ajal on lihtne lund sadada, väljapääs puudub ja töö tegemiseks pole aega. Ja need sõnumid pärast koosolekuid tapavad ülejäänud aja ja mõistavad, mida edasi teha. 

Sellepärast on kohtumine alles esimene samm. Meil on endiselt probleeme:

  • Kehv suhtlus
  • Vastastikuste eesmärkide puudumine
  • Ebapiisav kaasatus

Mõnikord püüavad inimesed projekti kohta olulist teavet oma kolleegidele edastada. Kuid selle asemel, et sõnum kätte saada, teeb kuulujutt nende heaks kõik. Kui inimesed ei tea, kuidas oma mõtteid ja ideid õigesti ja õiges keskkonnas jagada, kaotatakse teave vastuvõtja juurde minnes. 

Need on sümptomid ettevõttest, kes võitleb kommunikatsiooniprobleemidega. Ja see hakkab neid kohtumistega ravima. Kuid meil on alati teine ​​lahendus.

Juhatage kõik projekti üle suhtlema. 

Multidistsiplinaarne suhtlus meeskondades

Selle lähenemise parimad omadused:

  • läbipaistvus
  • Kaasamine
  • Teadmiste ja oskuste vahetamine
  • Peatuseta haridus

See on äärmiselt keeruline struktuur, mida on raske luua. Võite teada mõnda raamistikku, mis seda lähenemist kasutavad: Agile, Lean, Scrum. Pole tähtis, kuidas te seda nimetate; kõik need on üles ehitatud põhimõttele "kõik korraga valmis teha". Kõik need kalendrid, ülesannete järjekorrad, demoettekanded ja stand-up kohtumised on suunatud sellele, et inimesed räägiksid projektist sageli ja kõik koos.

Sellepärast meeldib mulle Agile palju, sest see sisaldab kommunikatsiooni tähtsust kui projekti ellujäämise eeldust.

Ja kui arvate, et olete analüütik, kellele Agile ei meeldi, vaadake seda teistmoodi: see aitab teil näidata oma töö tulemusi - kõiki töödeldud andmeid, neid suurepäraseid juhtpaneele, andmekogumeid - et inimesi muuta hindan teie pingutusi. Kuid selleks peate kohtuma kolleegidega ja rääkima nendega ümarlaual.

Mis järgmiseks? Kõik on hakanud projektist rääkima. Nüüd oleme seda teinud kvaliteedi tõestamiseks projekti. Selleks võtavad ettevõtted tavaliselt tööle kõrgeima kvalifikatsiooniga konsultandi. 

Hea konsultandi peamine kriteerium (võin teile öelda, kuna olen konsultant) vähendab pidevalt tema osalust projektis.

Konsultant ei saa ettevõttele lihtsalt pisikesi ametisaladusi anda, sest see ei muuda ettevõtet küpseks ja isemajandavaks. Kui teie ettevõte ei saa juba ilma konsultandita elada, peaksite arvestama saadud teenuse kvaliteediga. 

Muide, konsultant ei tohiks teha aruandeid ega saada teie jaoks täiendavaks käepaariks. Selleks on teil oma sisekaaslasi.

Palgake turundajaid hariduse, mitte delegatsiooni jaoks

Konsultandi palkamise peamine eesmärk on haridus, struktuuride ja protsesside kinnitamine ning suhtlemise hõlbustamine. Konsultandi roll ei ole igakuine aruandlus, vaid pigem projekti juurutamine ja meeskonna igapäevases tegevuses osalemine.

Hea strateegiline turunduskonsultant täidab lüngad projektis osalejate teadmistes ja mõistmises. Kuid ta ei pruugi kunagi seda tööd kellegi heaks teha. Ja ühel päeval peavad kõik ilma konsultandita hästi töötama. 

Tõhusa suhtluse tulemuseks on nõiajahi ja näpuga näitamise puudumine. Enne ülesande alustamist jagavad inimesed oma kahtlusi ja küsimusi teiste meeskonnaliikmetega. Seega lahendatakse enamik probleeme enne töö algust. 

Vaatame, kuidas see kõik mõjutab turundusanalüüsi kõige keerukamat osa: andmevoogude määratlemist ja andmete ühendamist.

Kuidas peegeldub andmeedastuse ja -töötluse kommunikatsioonistruktuur?

Oletame, et meil on kolm allikat, mis annavad meile järgmised andmed: liiklusandmed, e-kaubanduse toodete andmed / lojaalsusprogrammi ostuandmed ja mobiilianalüütika andmed. Teeme ükshaaval läbi andmetöötluse etapid, alates kõigi nende andmete voogesitamisest Google Cloudi ja lõpetades kõikide kuvamiseks kuvamiseks Google Data Studio abiga Google'i BigQuery

Milliseid küsimusi peaksid inimesed meie näite põhjal küsima, et tagada selge suhtlus andmetöötluse igas etapis?

  • Andmete kogumise etapp. Kui unustame midagi olulist mõõta, ei saa me ajas tagasi minna ja seda uuesti mõõta. Asjad, mida eelnevalt kaaluda:
    • Kui me ei tea, kuidas nimetada kõige olulisemaid parameetreid ja muutujaid, kuidas saame kogu segadusega hakkama?
    • Kuidas sündmused märgistatakse?
    • Milline saab olema valitud andmevoogude kordumatu tunnus?
    • Kuidas me hoolitseme turvalisuse ja privaatsuse eest? 
    • Kuidas me andmeid kogume, kus andmete kogumisel on piiranguid?
  • Andmete voogude ühendamine. Mõelge järgmisele:
    • Peamised ETL-i põhimõtted: kas see on partii- või voogedastuse tüüp? 
    • Kuidas tähistame voo ja pakettandmete edastamise koosmõju? 
    • Kuidas kohandame neid samas andmekavas ilma kaotuste ja vigadeta?
    • Aja- ja kronoloogiaküsimused: kuidas kontrollime ajatemplid? 
    • Kuidas me saame teada, kas andmete renoveerimine ja rikastamine töötab õigesti ajatemplites?
    • Kuidas kinnitame tabamusi? Mis juhtub kehtetute hittidega?

  • Andmete liitmise etapp. Arvestatavad asjad:
    • Spetsiaalsed seaded ETL-protsessidele: mida on meil teha kehtetute andmetega?
      Plaaster või kustutamine? 
    • Kas saame sellest kasumit? 
    • Kuidas mõjutab see kogu andmekogumi kvaliteeti?

Kõigi nende etappide esimene põhimõte on see, et vead laduvad üksteise otsa ja pärivad üksteiselt. Esimesel etapil puudusega kogutud andmed panevad teie pea kõigi järgnevate etappide ajal kergelt põlema. Ja teine ​​põhimõte on see, et andmete kvaliteedi tagamiseks peaksite valima punktid. Kuna liitmise etapis segatakse kõik andmed kokku ja te ei saa segatud andmete kvaliteeti mõjutada. See on tõesti oluline masinõppeprojektide puhul, kus andmete kvaliteet mõjutab masinõppe tulemuste kvaliteeti. Ebakvaliteetsete andmetega pole häid tulemusi võimalik saavutada.

  • Visualiseerimine
    See on tegevjuhi etapp. Võib-olla olete kuulnud olukorrast, kui tegevjuht vaatab armatuurlaual olevaid numbreid ja ütleb: "Olgu, meil on sel aastal palju kasumit, isegi rohkem kui varem, kuid miks on kõik finantsparameetrid punases tsoonis ? " Ja sel hetkel on liiga hilja vigu otsida, kuna need oleks pidanud ammu tabama.

Kõik põhineb suhtlemisel. Ja jututeemadel. Siin on näide sellest, mida tuleks Yandexi voogesituse ettevalmistamisel arutada:

Turunduse BI: Lumesahk, Google Analytics, Yandex

Enamikule neist küsimustest leiate vastused ainult koos kogu meeskonnaga. Sest kui keegi teeb otsuse äraarvamise või isikliku arvamuse põhjal ilma ideed teistega katsetamata, võivad ilmneda vead.

Keerukust on kõikjal, isegi kõige lihtsamates kohtades.

Siin on veel üks näide: Tootekaartide näitamisskooride jälgimisel märkab analüütik viga. Tulemusandmetes saadeti kõik bännerite ja tootekaartide kõik näitamised kohe pärast lehe laadimist. Kuid me ei saa olla kindlad, kas kasutaja vaatas lehel tõesti kõike. Analüütik tuleb meeskonda, et neid sellest üksikasjalikult teavitada.

BI ütleb, et me ei saa olukorda niimoodi jätta.

Kuidas saame arvutada CPM-i, kui me ei saa isegi kindel olla, kas toodet näidati? Mis on siis piltide kvalifitseeritud CTR?

Turundajad vastavad:

Kõik, saame koostada aruande, mis näitab parimat CTR-i, ja kinnitada seda sarnase loomingulise bänneri või foto järgi mujal.

Ja siis ütlevad arendajad:

Jah, saame selle probleemi lahendada kerimise jälgimise ja objekti nähtavuse kontrollimise uue integreerimise abil.

Lõpuks ütlevad UI / UX disainerid:

Jah! Saame valida, kas vajame lõpuks laiskat või igavest kerimist või lehekülgede otsimist!

Siin on sammud, mida see väike meeskond läbis:

  1. Määras probleemi
  2. Tutvustas probleemi ärilisi tagajärgi
  3. Mõõtis muudatuste mõju
  4. Esitati tehnilisi otsuseid
  5. Avastas mitte triviaalse kasumi

Selle probleemi lahendamiseks peaksid nad kontrollima kõigi süsteemide andmete kogumist. Andmekava ühes osas osaline lahendus ei lahenda äriprobleemi.

joondage kujunduse kohandamine

Sellepärast peame tegema koostööd. Andmeid tuleb iga päev vastutustundlikult koguda ja selle nimel on raske töö. Ja andmete kvaliteet tuleb saavutada aastaks õigete inimeste palkamine, õigete tööriistade ostmine ning raha, aja ja vaeva investeerimine tõhusate kommunikatsioonistruktuuride ülesehitamiseks, mis on organisatsiooni edukuse jaoks ülioluline.

Mis sa arvad?

Sellel saidil kasutatakse rämpsposti vähendamiseks Akismetit. Vaadake, kuidas teie andmeid töödeldakse.