Zakaj je timsko komuniciranje pomembnejše od vašega Martechovega sklada

Komunikacija in analiza marketinške ekipe

Netipično stališče Sime Ahave o kakovosti podatkov in komunikacijskih strukturah je osvežilo celoten salon na Pojdi na Analytics! konferenca. VOKS, vodja MarTech-a v regiji neodvisnih držav, je na to srečanje pozdravil na tisoče strokovnjakov, ki so delili svoje znanje in ideje.

OWOX BI ekipa bi radi, da razmislite o konceptu, ki ga je predlagal Simo Ahava, in ki zagotovo lahko poveča vaše podjetje. 

Kakovost podatkov in kakovost organizacije

Kakovost podatkov je odvisna od osebe, ki jih analizira. Običajno bi za napake v podatkih krivili orodja, delovne tokove in nabore podatkov. Toda ali je to smiselno?

Iskreno rečeno, kakovost podatkov je neposredno povezana s tem, kako komuniciramo znotraj naših organizacij. Kakovost organizacije določa vse, začenši s pristopom k rudarjenju podatkov, ocenjevanjem in merjenjem, nadaljuje z obdelavo in konča s splošno kakovostjo izdelka in odločanjem. 

Podjetja in njihove komunikacijske strukture

Predstavljajmo si, da je podjetje specializirano za eno orodje. Ljudje v tem podjetju odlično najdejo določene težave in jih rešijo za B2B segment. Vse je super in nedvomno poznate nekaj takšnih podjetij.

Stranski učinki dejavnosti teh podjetij se skrivajo v dolgotrajnem postopku dvigovanja zahtev za kakovost podatkov. Hkrati se moramo zavedati, da orodja, ustvarjena za analizo podatkov, delujejo samo s podatki in so ločena od poslovnih težav - tudi če so ustvarjena za njihovo reševanje. 

Zato se je pojavila druga vrsta podjetja. Ta podjetja so specializirana za odpravljanje napak v delovnem toku. V poslovnih procesih lahko najdejo cel kup težav, jih postavijo na tablo in vodjem sporočijo:

Tu, tu in tam! Uporabite to novo poslovno strategijo in vse bo v redu!

Ampak sliši se predobro, da bi bilo res. Učinkovitost nasvetov, ki ne temeljijo na razumevanju orodij, je dvomljiva. In ta svetovalna podjetja ponavadi ne razumejo, zakaj so se pojavile takšne težave, zakaj vsak nov dan prinaša nove zaplete in napake ter katera orodja so bila postavljena nepravilno.

Torej je koristnost teh podjetij samostojna omejena. 

Obstajajo podjetja s poslovnim znanjem in znanjem orodij. V teh podjetjih so vsi obsedeni z najemanjem ljudi z velikimi lastnostmi, strokovnjakov, ki so prepričani v svoje sposobnosti in znanje. Kul. Običajno ta podjetja niso namenjena reševanju komunikacijskih težav znotraj ekipe, kar se jim pogosto zdi nepomembno. Ko se pojavijo nove težave, se začne lov na čarovnice - čigava je krivda? Mogoče so strokovnjaki za BI zamenjali procese? Ne, programerji niso prebrali tehničnega opisa. Toda vse skupaj je resnična težava v tem, da ekipa ne more jasno premisliti problema, da bi ga skupaj rešila. 

To nam kaže, da bo celo v podjetju, polnjenem s kul strokovnjaki, vse potrebno več truda, kot je potrebno, če organizacija ni zrel dovolj. Zamisel, da moraš biti odrasel in odgovoren, zlasti v krizi, je zadnja stvar, o kateri ljudje razmišljajo v večini podjetij.

Tudi moj dveletni otrok, ki hodi v vrtec, se zdi zrelejši od nekaterih organizacij, s katerimi sem sodeloval.

Učinkovitega podjetja ne morete ustvariti samo z najemanjem velikega števila strokovnjakov, saj jih vse prevzame neka skupina ali oddelek. Vodstvo torej še naprej zaposluje strokovnjake, vendar se nič ne spremeni, ker se struktura in logika poteka dela sploh ne spremeni.

Če ne naredite ničesar za ustvarjanje komunikacijskih kanalov znotraj in zunaj teh skupin in oddelkov, bodo vsa vaša prizadevanja nesmiselna. Zato je v središču komunikacijske strategije in zrelosti Ahava.

Conwayev zakon, ki se uporablja za analitična podjetja

Pomenljivi podatki - Conwayev zakon

Pred petdesetimi leti je odlični programer po imenu Melvin Conway podal predlog, ki je kasneje postal splošno znan kot Conwayev zakon: 

Organizacije, ki oblikujejo sisteme. . . so omejeni na izdelavo modelov, ki so kopije komunikacijskih struktur teh organizacij.

Melvin Conway, Conwayev zakon

Te misli so se pojavile v času, ko je en računalnik popolnoma ustrezal eni sobi! Samo predstavljajte si: tukaj imamo eno ekipo, ki dela na enem računalniku, in tam imamo drugo ekipo, ki dela na drugem računalniku. V resničnem življenju Conwayev zakon pomeni, da se bodo vse komunikacijske napake, ki se pojavijo med temi ekipami, odražale v strukturi in funkcionalnosti programov, ki jih razvijajo. 

Opomba avtorja:

Ta teorija je bila na stotine krat preizkušena v razvojnem svetu in o njej se je veliko razpravljalo. Najbolj zanesljivo definicijo Conwayjevega zakona je ustvaril Pieter Hintjens, eden najvplivnejših programerjev v zgodnjih 2000-ih, ki je dejal, da "če ste v usrani organizaciji, boste naredili usrano programsko opremo." (Amdahl do Zipfa: Deset zakonov fizike ljudi)

Preprosto je videti, kako ta zakon deluje v svetu trženja in analitike. V tem svetu podjetja delajo z ogromno količino podatkov, zbranih iz različnih virov. Vsi se lahko strinjamo, da so podatki pravični. Če pa natančno pregledate nabore podatkov, boste videli vse pomanjkljivosti organizacij, ki so te podatke zbrale:

  • Manjkajoče vrednosti, kjer inženirji niso govorili o težavi 
  • Napačne oblike, kjer nihče ni bil pozoren in nihče ni razpravljal o številu decimalnih mest
  • Zamude pri komunikaciji, kadar nihče ne pozna oblike prenosa (paket ali prenos) in kdo mora prejeti podatke

Zato sistemi za izmenjavo podatkov v celoti razkrivajo naše pomanjkljivosti.

Kakovost podatkov je dosežek strokovnjakov za orodja, strokovnjakov za potek dela, menedžerjev in komunikacije med vsemi temi ljudmi.

Najboljše in najslabše komunikacijske strukture za multidisciplinarne ekipe

Tipično projektno skupino v podjetju MarTech ali marketinški analitiki sestavljajo strokovnjaki za poslovno inteligenco (BI), podatkovni znanstveniki, oblikovalci, tržniki, analitiki in programerji (v kateri koli kombinaciji).

Kaj pa se bo zgodilo v ekipi, ki ne razume pomena komunikacije? Pa poglejmo. Programerji bodo dolgo pisali kodo in se trudili, drugi del ekipe pa bo le čakal, da bodo predali štafeto. Končno bo izšla beta različica in vsi bodo mrmrali, zakaj je trajalo tako dolgo. In ko se pojavi prva napaka, bodo vsi začeli iskati nekoga drugega, ki bi bil kriv, ne pa tudi načinov, kako se izogniti situaciji, ki je tam prišla. 

Če pogledamo globlje, bomo videli, da skupni cilji niso bili pravilno razumljeni (ali sploh niso bili razumljeni). In v takem primeru bomo dobili poškodovan ali napačen izdelek. 

Spodbujajte multidisciplinarne ekipe

Najslabše značilnosti te situacije:

  • Nezadostna vključenost
  • Nezadostna udeležba
  • Pomanjkanje sodelovanja
  • Pomanjkanje zaupanja

Kako lahko to popravimo? Dobesedno tako, da ljudje govorijo. 

Spodbujajte multidisciplinarne ekipe

Zberemo vse skupaj, določimo teme razprav in določimo tedenska srečanja: trženje z BI, programerji z oblikovalci in strokovnjaki za podatke. Potem bomo upali, da bodo ljudje govorili o projektu. A to še vedno ni dovolj, ker člani ekipe še vedno ne govorijo o celotnem projektu in se ne pogovarjajo s celotno ekipo. Z lahkoto lahko zasujete z desetimi sestanki, brez izhoda in časa za delo. In ta sporočila po sestankih bodo uničila preostali čas in razumevanje, kaj storiti naprej. 

Zato je srečanje šele prvi korak. Še vedno imamo nekaj težav:

  • Slaba komunikacija
  • Pomanjkanje skupnih ciljev
  • Nezadostna vključenost

Včasih ljudje poskušajo pomembne informacije o projektu posredovati svojim kolegom. Toda namesto da bi sporočilo prešlo, stroj za govorice naredi vse namesto njih. Ko ljudje ne bodo znali pravilno deliti svojih misli in idej v ustreznem okolju, se bodo informacije na poti do prejemnika izgubile. 

To so simptomi podjetja, ki se spopada s težavami v komunikaciji. In začne jih zdraviti s sestanki. Vendar imamo vedno drugo rešitev.

Vodi vse do komunikacije nad projektom. 

Multidisciplinarna komunikacija v skupinah

Najboljše lastnosti tega pristopa:

  • Preglednost
  • Vključenost
  • Izmenjava znanja in spretnosti
  • Neprekinjeno izobraževanje

To je izjemno zapletena struktura, ki jo je težko ustvariti. Morda poznate nekaj okvirov, ki uporabljajo ta pristop: okretni, vitki, skromni. Ni važno, kako ga imenujete; vsi so zgrajeni po principu "delati vse skupaj hkrati". Vsi ti koledarji, čakalne vrste, predstavitve predstavitve in stand-up sestanki so namenjeni temu, da ljudje pogosto in vsi skupaj govorijo o projektu.

Zato mi je Agile zelo všeč, saj vključuje pomen komunikacije kot predpogoj za preživetje projekta.

In če mislite, da ste analitik, ki ne mara Agile, poglejte na drug način: pomaga vam pokazati rezultate svojega dela - vse vaše obdelane podatke, te izvrstne nadzorne plošče in vaše nabore podatkov - da ljudi cenim vaš trud. Toda za to se morate srečati s kolegi in se z njimi pogovoriti za okroglo mizo.

Kaj je naslednje? Vsi so začeli govoriti o projektu. Zdaj smo že za dokazovanje kakovosti projekta. V ta namen podjetja običajno najamejo svetovalca z najvišjo strokovno usposobljenostjo. 

Glavno merilo dobrega svetovalca (lahko vam rečem, ker sem svetovalec) je nenehno zmanjševanje njegove udeležbe v projektu.

Svetovalec podjetja ne more samo nahraniti z majhnimi koščki poklicnih skrivnosti, ker to ne bo omogočilo zrelosti in samooskrbe podjetja. Če vaše podjetje že ne more živeti brez vašega svetovalca, razmislite o kakovosti storitve, ki ste jo prejeli. 

Mimogrede, svetovalec ne bi smel pripraviti poročil ali postati dodaten par rok za vas. Za to imate svoje notranje kolege.

Najemite tržnike za izobraževanje, ne za delegacije

Glavni cilj najema svetovalca je izobraževanje, popravljanje struktur in procesov ter olajšanje komunikacije. Vloga svetovalca ni mesečno poročanje, temveč bolj vsaditev v projekt in popolna vključenost v vsakodnevno rutino ekipe.

Dober svetovalec za strateško trženje zapolnjuje vrzeli v znanju in razumevanju udeležencev projekta. Toda on ali ona morda nikoli ne bo delal za nekoga. In nekega dne bodo morali vsi dobro delati brez svetovalca. 

Rezultat učinkovite komunikacije je odsotnost lova na čarovnice in kazanja s prstom. Preden se naloga začne, ljudje delijo svoje dvome in vprašanja z drugimi člani ekipe. Tako se večina težav reši že pred začetkom dela. 

Poglejmo, kako vse to vpliva na najbolj zapleten del trženjske analize: definiranje podatkovnih tokov in združevanje podatkov.

Kako se zrcali komunikacijska struktura pri prenosu in obdelavi podatkov?

Predpostavimo, da imamo tri vire, ki nam dajejo naslednje podatke: podatke o prometu, podatke o izdelkih za e-poslovanje / podatke o nakupih iz programa zvestobe in podatke o mobilni analitiki. Eno za drugo bomo šli skozi faze obdelave podatkov, od pretakanja vseh teh podatkov v Google Cloud do pošiljanja vsega za vizualizacijo v Google podatkovni studio s pomočjo Google BigQuery

Na podlagi našega primera, katera vprašanja bi si morali ljudje zastaviti, da bi zagotovili jasno komunikacijo med vsako fazo obdelave podatkov?

  • Faza zbiranja podatkov. Če pozabimo izmeriti nekaj pomembnega, se ne moremo vrniti v preteklost in ga ponovno izmeriti. Stvari, o katerih je treba razmisliti vnaprej:
    • Če ne vemo, kako naj poimenujemo najpomembnejše parametre in spremenljivke, kako se spoprijeti z vso neredom?
    • Kako bodo označeni dogodki?
    • Kakšen bo enolični identifikator za izbrani pretok podatkov?
    • Kako bomo poskrbeli za varnost in zasebnost? 
    • Kako bomo zbirali podatke, kadar obstajajo omejitve glede zbiranja podatkov?
  • Združevanje podatkov teče v tok. Upoštevajte naslednje:
    • Glavna načela ETL: Ali gre za paketni ali tokovni prenos podatkov? 
    • Kako bomo označili povezavo pretočnega in paketnega prenosa podatkov? 
    • Kako jih bomo prilagodili v isti podatkovni shemi brez izgub in napak?
    • Vprašanja o času in kronologiji: Kako bomo preverili časovne žige? 
    • Kako lahko vemo, ali obnova in obogatitev podatkov deluje pravilno v časovnih žigov?
    • Kako bomo potrdili zadetke? Kaj se zgodi z neveljavnimi zadetki?

  • Stopnja združevanja podatkov. Stvari, ki jih je treba upoštevati:
    • Specializirane nastavitve za procese ETL: kaj imamo pri neveljavnih podatkih?
      Popraviti ali izbrisati? 
    • Ali lahko s tem zaslužimo? 
    • Kako bo to vplivalo na kakovost celotnega nabora podatkov?

Prvo načelo za vse te faze je, da se napake nalagajo ena na drugo in se med seboj podedujejo. Podatki, zbrani s pomanjkljivostjo na prvi stopnji, vas bodo rahlo opekli v vseh nadaljnjih fazah. In drugo načelo je, da bi morali izbrati točke za zagotavljanje kakovosti podatkov. Ker bodo v fazi združevanja vsi podatki pomešani in ne boste mogli vplivati ​​na kakovost mešanih podatkov. To je resnično pomembno za projekte strojnega učenja, kjer bo kakovost podatkov vplivala na kakovost rezultatov strojnega učenja. Dobri rezultati so z nizkokakovostnimi podatki nedosegljivi.

  • Vizualizacija
    To je stopnja izvršnega direktorja. Morda ste že slišali za situacijo, ko generalni direktor pogleda številke na armaturni plošči in reče: »V redu, letos imamo velik dobiček, celo več kot prej, a zakaj so vsi finančni parametri v rdeči coni ? " In v tem trenutku je prepozno iskati napake, saj bi jih že davno morali ujeti.

Vse temelji na komunikaciji. In o temah pogovora. Tu je primer, o čem je treba razpravljati med pripravo pretakanja Yandex:

Marketinški BI: snežni sneg, Google Analytics, Yandex

Odgovore na večino teh vprašanj boste našli samo skupaj s celotno ekipo. Ker ko se nekdo odloči na podlagi ugibanja ali osebnega mnenja, ne da bi idejo preizkusil z drugimi, se lahko pojavijo napake.

Kompleksnosti so povsod, tudi na najpreprostejših krajih.

Tu je še en primer: pri sledenju ocenam prikazov na karticah izdelkov analitik opazi napako. V podatkih o zadetkih so bili vsi prikazi iz vseh pasic in kartic izdelkov poslani takoj po nalaganju strani. Ne moremo pa biti prepričani, ali si je uporabnik res ogledal vse na strani. Analitik pride v ekipo, da jih o tem podrobno obvesti.

BI pravi, da situacije tako ne moremo zapustiti.

Kako lahko izračunamo CPM, če niti sami ne moremo biti prepričani, ali je bil izdelek prikazan? Kakšen je potem kvalificirani CTR za slike?

Tržniki odgovarjajo:

Poglejte, vsi, lahko ustvarimo poročilo, ki prikazuje najboljši CTR, in ga preverimo na podobni oglasni pasici ali fotografiji drugje.

In potem bodo razvijalci rekli:

Da, to težavo lahko rešimo s pomočjo naše nove integracije za sledenje drsenja in preverjanje vidljivosti predmeta.

Končno oblikovalci UI / UX pravijo:

Ja! Izbiramo lahko, ali bomo končno potrebovali leni ali večni pomik ali paginacijo!

Tu je korakov, ki jih je minila ta majhna ekipa:

  1. Določil težavo
  2. Predstavil poslovne posledice problema
  3. Izmerjen vpliv sprememb
  4. Predstavljene tehnične odločitve
  5. Odkril netrivialni dobiček

Da bi rešili to težavo, bi morali preveriti zbiranje podatkov iz vseh sistemov. Delna rešitev v enem delu podatkovne sheme ne bo rešila poslovne težave.

poravnaj prilagodi zasnovo

Zato moramo sodelovati. Podatke je treba zbirati vsak dan odgovorno in to je težko opraviti. In kakovost podatkov mora biti dosežena z najemanje pravih ljudi, nakup pravih orodij in vlaganje denarja, časa in truda v oblikovanje učinkovitih komunikacijskih struktur, ki so ključne za uspeh organizacije.

Kaj menite?

Ta stran uporablja Akismet za zmanjšanje nezaželene pošte. Preberite, kako se vaš komentar obravnava.