Kāpēc komandas komunikācija ir svarīgāka par jūsu moci

Mārketinga komandas komunikācija un analīze

Netipiskais Simo Ahavas viedoklis par datu kvalitāti un sakaru struktūrām atsvaidzināja visu atpūtas telpu Dodieties uz Analytics! konference. OWOX, MarTech līderis NVS reģionā, uzaicināja tūkstošiem ekspertu šajā salidojumā, lai dalītos savās zināšanās un idejās.

OWOX BI komanda vēlētos, lai jūs pārdomātu Simo Ahava piedāvāto koncepciju, kurai noteikti ir potenciāls, lai jūsu bizness augtu. 

Datu kvalitāte un organizācijas kvalitāte

Datu kvalitāte ir atkarīga no personas, kas tos analizē. Parasti mēs vainotu visus datu trūkumus par rīkiem, darbplūsmām un datu kopām. Bet vai tas ir saprātīgi?

Atklāti sakot, datu kvalitāte ir tieši saistīta ar to, kā mēs sazināmies mūsu organizācijās. Organizācijas kvalitāte nosaka visu, sākot ar pieeju datu iegūšanai, novērtēšanai un mērīšanai, turpinot ar apstrādi un beidzot ar produkta vispārējo kvalitāti un lēmumu pieņemšanu. 

Uzņēmumi un to komunikācijas struktūras

Iedomāsimies, ka uzņēmums specializējas vienā rīkā. Šī uzņēmuma cilvēki lieliski atrod noteiktas problēmas un risina tās B2B segmentam. Viss ir lieliski, un, bez šaubām, jūs zināt pāris šādus uzņēmumus.

Šo uzņēmumu darbības blakusparādības slēpjas ilgtermiņā, paaugstinot datu kvalitātes prasības. Tajā pašā laikā mums jāatceras, ka rīki, kas izveidoti datu analīzei, darbojas tikai ar datiem un ir izolēti no uzņēmējdarbības problēmām, pat ja tie ir izveidoti to risināšanai. 

Tāpēc parādījās cita veida firma. Šie uzņēmumi ir specializējušies darbplūsmas atkļūdošanā. Viņi var atrast veselu virkni problēmu biznesa procesos, ievietot tās uz tāfeles un pateikt vadītājiem:

Šeit, šeit un tur! Pielietojiet šo jauno biznesa stratēģiju, un jums viss būs kārtībā!

Bet tas izklausās pārāk labi, lai būtu patiesība. Apšaubāma ir padomu efektivitāte, kas nav balstīta uz rīku izpratni. Šīs konsultāciju firmas mēdz nesaprast, kāpēc parādījās šādas problēmas, kāpēc katra jauna diena rada jaunas sarežģītības un kļūdas un kādi rīki tika izveidoti nepareizi.

Tātad šo uzņēmumu lietderība vien ir ierobežota. 

Ir uzņēmumi, kuriem ir gan biznesa zināšanas, gan zināšanas par rīkiem. Šajos uzņēmumos visi ir apsēsti, pieņemot darbā cilvēkus ar lieliskām īpašībām, ekspertus, kuri ir pārliecināti par savām prasmēm un zināšanām. Forši. Bet parasti šie uzņēmumi nav vērsti uz komunikācijas problēmu risināšanu komandas iekšienē, ko viņi bieži uzskata par nesvarīgu. Tātad, parādoties jaunām problēmām, sākas raganu medības - kura vaina? Varbūt BI speciālisti sajauca procesus? Nē, programmētāji neizlasīja tehnisko aprakstu. Bet kopumā patiesā problēma ir tā, ka komanda nevar skaidri pārdomāt problēmu, lai to kopīgi atrisinātu. 

Tas mums parāda, ka pat uzņēmumā, kas pildīts ar foršiem speciālistiem, viss prasīs vairāk pūļu, nekā nepieciešams, ja organizācija to nedara nobriedis pietiekami. Ideja, ka jums ir jābūt pieaugušam un atbildīgam, īpaši krīzes laikā, ir pēdējā lieta, par kuru cilvēki domā lielākajā daļā uzņēmumu.

Pat mans divus gadus vecais bērns, kurš dodas uz bērnudārzu, šķiet nobriedušāks par dažām organizācijām, ar kurām esmu strādājis.

Efektīvu uzņēmumu nevar izveidot, tikai algojot lielu skaitu speciālistu, jo viņus visus absorbē kāda grupa vai nodaļa. Tātad vadība turpina pieņemt darbā speciālistus, taču nekas nemainās, jo darbplūsmas struktūra un loģika nemaz nemainās.

Ja jūs neko nedarīsit, lai izveidotu saziņas kanālus šajās grupās un departamentos un ārpus tām, visi jūsu centieni būs bezjēdzīgi. Tāpēc Ahavas uzmanības centrā ir komunikācijas stratēģija un briedums.

Konveja likums attiecās uz Analytics uzņēmumiem

Nozīmīgi dati - Konveja likums

Pirms piecdesmit gadiem lielisks programmētājs vārdā Melvins Konvejs izteica ierosinājumu, kas vēlāk kļuva populārs kā Konveja likums: 

Organizācijas, kas projektē sistēmas. . . ir jāpieprasa izstrādāt dizainparaugus, kas ir šo organizāciju komunikācijas struktūru kopijas.

Melvins Konvejs, Konveja likums

Šīs domas radās laikā, kad viens dators lieliski iederējās vienā telpā! Iedomājieties: šeit mums ir viena komanda, kas strādā pie viena datora, un tur mums ir cita komanda, kas strādā pie cita datora. Reālajā dzīvē Konveja likums nozīmē, ka visi komunikācijas trūkumi, kas parādās starp šīm komandām, tiks atspoguļoti viņu izstrādāto programmu struktūrā un funkcionalitātē. 

Autora piezīme:

Šī teorija ir simtiem reižu pārbaudīta attīstības pasaulē un ir daudz apspriesta. Visprecīzāko Konveja likuma definīciju izveidoja Pīters Hintjenss, viens no ietekmīgākajiem 2000. gadu sākuma programmētājiem, kurš teica, ka “ja jūs esat sūdīgā organizācijā, jūs izveidosiet sūdīgu programmatūru”. (Amdāls līdz Zipfam: Cilvēku fizikas desmit likumi)

Ir viegli saprast, kā šis likums darbojas mārketinga un analīzes pasaulē. Šajā pasaulē uzņēmumi strādā ar milzīgu daudzumu datu, kas savākti no dažādiem avotiem. Mēs visi varam piekrist, ka paši dati ir taisnīgi. Bet, rūpīgi pārbaudot datu kopas, redzēsiet visus trūkumus organizācijās, kuras apkopoja šos datus:

  • Trūkst vērtību, kur inženieri nav runājuši par problēmu 
  • Nepareizi formāti, kur neviens nepievērsa uzmanību un neviens neapsprieda komatu skaitu
  • Saziņa aizkavējas, ja neviens nezina pārsūtīšanas formātu (sēriju vai straumi) un kam jāsaņem dati

Tāpēc datu apmaiņas sistēmas pilnībā atklāj mūsu nepilnības.

Datu kvalitāte ir rīku speciālistu, darbplūsmas ekspertu, vadītāju sasniegums un saziņa starp visiem šiem cilvēkiem.

Labākās un sliktākās komunikācijas struktūras daudznozaru komandām

Tipiska projekta komanda MarTech vai mārketinga analīzes uzņēmumā sastāv no biznesa inteliģences (BI) speciālistiem, datu zinātniekiem, dizaineriem, tirgotājiem, analītiķiem un programmētājiem (jebkurā kombinācijā).

Bet kas notiks komandā, kas nesaprot komunikācijas nozīmi? Paskatīsimies. Programmētāji ilgi rakstīs kodu, cītīgi cenšoties, savukārt cita komandas daļa tikai gaidīs, kamēr viņi nodos stafeti. Beidzot beta versija tiks izlaista, un visi murminās, kāpēc tas prasīja tik ilgu laiku. Kad parādīsies pirmais trūkums, visi sāks meklēt kādu citu vainīgu, bet nevis veidus, kā izvairīties no situācijas, kas viņus tur nokļuvusi. 

Ja ieskatīsimies dziļāk, redzēsim, ka savstarpējie mērķi nav pareizi (vai vispār) izprasti. Un šādā situācijā mēs iegūsim bojātu vai bojātu produktu. 

Veiciniet daudzdisciplīnu komandas

Sliktākās šīs situācijas iezīmes:

  • Nepietiekama iesaistīšanās
  • Nepietiekama līdzdalība
  • Sadarbības trūkums
  • Uzticības trūkums

Kā mēs to varam novērst? Burtiski, liekot cilvēkiem runāt. 

Veiciniet daudznozaru komandas

Apkoposim visus kopā, noteiksim diskusiju tēmas un ieplānosim iknedēļas sanāksmes: mārketings ar BI, programmētāji ar dizaineriem un datu speciālistiem. Tad mēs cerēsim, ka cilvēki runās par projektu. Bet tas joprojām nav pietiekami, jo komandas dalībnieki joprojām nerunā par visu projektu un nerunā ar visu komandu. Viegli sasnigt ar desmitiem sanāksmju, bez izejas un laika paveikt darbu. Un šie ziņojumi pēc sapulcēm nogalinās atlikušo laiku un izpratni par turpmāko rīcību. 

Tāpēc tikšanās ir tikai pirmais solis. Mums joprojām ir dažas problēmas:

  • Slikta komunikācija
  • Savstarpēju mērķu trūkums
  • Nepietiekama iesaistīšanās

Dažreiz cilvēki cenšas nodot svarīgu informāciju par projektu kolēģiem. Bet tā vietā, lai ziņa tiktu cauri, baumu mašīna dara visu viņu labā. Kad cilvēki nezina, kā pareizi un atbilstošā vidē dalīties ar savām domām un idejām, informācija pazudīs ceļā pie saņēmēja. 

Šie ir simptomi uzņēmumam, kurš cīnās ar komunikācijas problēmām. Un tas sāk viņus izārstēt ar sapulcēm. Bet mums vienmēr ir cits risinājums.

Mudiniet visus sazināties ar projektu. 

Daudznozaru komunikācija komandās

Šīs pieejas labākās iezīmes:

  • Caurspīdīgums
  • Iesaistīšanās
  • Zināšanu un prasmju apmaiņa
  • Izglītība bez apstājas

Šī ir ārkārtīgi sarežģīta struktūra, kuru ir grūti izveidot. Jūs, iespējams, zināt dažus ietvarus, kas izmanto šo pieeju: Agile, Lean, Scrum. Nav svarīgi, kā jūs to nosauksit; visi no tiem ir veidoti pēc principa “visu visu veidot vienlaikus”. Visi šie kalendāri, uzdevumu rindas, demonstrācijas prezentācijas un stand-up sanāksmes ir vērstas uz to, lai cilvēki runātu par projektu bieži un visi kopā.

Tāpēc man ļoti patīk Agile, jo tajā ir iekļauta komunikācijas nozīme kā priekšnoteikums projekta izdzīvošanai.

Un, ja jūs domājat, ka esat analītiķis, kuram nepatīk Agile, paskatieties uz to citādi: tas palīdz jums parādīt sava darba rezultātus - visus jūsu apstrādātos datus, šos lieliskos informācijas paneļus, datu kopas - lai padarītu cilvēkus novērtējam jūsu centienus. Bet, lai to izdarītu, jums jātiekas ar kolēģiem un jārunā ar viņiem pie apaļā galda.

Ko tālāk? Visi ir sākuši runāt par projektu. Tagad mums ir lai pierādītu kvalitāti projekta. Lai to izdarītu, uzņēmumi parasti pieņem darbā konsultantu ar visaugstāko profesionālo kvalifikāciju. 

Galvenais laba konsultanta kritērijs (es jums varu pateikt, jo esmu konsultants) pastāvīgi samazina viņa iesaistīšanos projektā.

Konsultants nevar vienkārši pabarot uzņēmumu ar nelieliem profesionālo noslēpumu gabaliem, jo ​​tas nepadarīs uzņēmumu nobriedušu un pašpietiekamu. Ja jūsu uzņēmums jau nevar dzīvot bez jūsu konsultanta, jums jāņem vērā saņemtā pakalpojuma kvalitāte. 

Starp citu, konsultantam nevajadzētu veidot ziņojumus vai kļūt par papildu roku pāri jums. Tam jums ir jūsu iekšējie kolēģi.

Nomājiet tirgotājus izglītībai, nevis delegācijai

Galvenais konsultanta nolīgšanas mērķis ir izglītība, struktūru un procesu noteikšana un komunikācijas veicināšana. Konsultanta loma nav ikmēneša pārskatu sniegšana, bet gan sava implantēšana projektā un pilnīga iesaistīšanās komandas ikdienā.

Labs stratēģiskā mārketinga konsultants aizpilda nepilnības projekta dalībnieku zināšanās un izpratnē. Bet viņš vai viņa nekad nevar darīt kādu darbu. Kādu dienu visiem bez konsultanta būs jāstrādā lieliski. 

Efektīvas saziņas rezultāti ir raganu medību un pirkstu rādīšanas neesamība. Pirms uzdevuma sākšanas cilvēki dalās šaubās un jautājumos ar citiem komandas locekļiem. Tādējādi lielākā daļa problēmu tiek atrisinātas pirms darba sākuma. 

Apskatīsim, kā tas viss ietekmē vissarežģītāko mārketinga analīzes darba daļu: datu plūsmu noteikšanu un datu apvienošanu.

Kā datu pārraides un apstrādes laikā tiek atspoguļota komunikācijas struktūra?

Pieņemsim, ka mums ir trīs avoti, kas sniedz šādus datus: trafika dati, e-komercijas produktu dati / pirkumu dati no lojalitātes programmas un mobilās analīzes dati. Mēs veiksim datu apstrādes posmus pa vienam, sākot no visu šo datu straumēšanas pakalpojumā Google Cloud līdz visu nosūtīšanai vizualizācijai Google datu studija ar Google BigQuery

Pamatojoties uz mūsu piemēru, kādi jautājumi cilvēkiem būtu jāuzdod, lai nodrošinātu skaidru saziņu katrā datu apstrādes posmā?

  • Datu vākšanas posms. Ja aizmirstam izmērīt kaut ko svarīgu, mēs nevaram atgriezties laikā un to atkārtoti novērtēt. Lietas, kas jāapsver iepriekš:
    • Ja mēs nezinām, kā nosaukt svarīgākos parametrus un mainīgos, kā mēs varam tikt galā ar visu jucekli?
    • Kā notikumi tiks atzīmēti?
    • Kāds būs izvēlēto datu plūsmu unikālais identifikators?
    • Kā mēs rūpēsimies par drošību un privātumu? 
    • Kā mēs apkoposim datus, ja datu vākšanai ir ierobežojumi?
  • Datu plūsma tiek apvienota. Apsveriet sekojošo:
    • Galvenie ETL principi: vai tas ir datu pārsūtīšanas paketes vai straumes veids? 
    • Kā mēs atzīmēsim straumes un pakešdatu pārsūtīšanas savienojumu? 
    • Kā mēs tos pielāgosim vienā un tajā pašā datu shēmā bez zaudējumiem un kļūdām?
    • Jautājumi par laiku un hronoloģiju: kā mēs pārbaudīsim laika zīmogus? 
    • Kā mēs varam zināt, vai datu atjaunošana un bagātināšana darbojas pareizi laika zīmogos?
    • Kā mēs apstiprināsim trāpījumus? Kas notiek ar nederīgiem trāpījumiem?

  • Datu apkopošanas posms. Jāņem vērā:
    • Specializētie ETL procesu iestatījumi: kāds mums sakars ar nederīgiem datiem?
      Ielāpīt vai izdzēst? 
    • Vai mēs no tā varam gūt peļņu? 
    • Kā tas ietekmēs visas datu kopas kvalitāti?

Visu šo posmu pirmais princips ir tāds, ka kļūdas sakrājas viena virs otras un tiek mantotas viena no otras. Dati, kas savākti ar kļūdu pirmajā posmā, visos turpmākajos posmos nedaudz sadedzinās galvu. Otrs princips ir tāds, ka datu kvalitātes nodrošināšanai jums jāizvēlas punkti. Tā kā apkopošanas posmā visi dati tiks sajaukti kopā, un jūs nevarēsit ietekmēt jaukto datu kvalitāti. Tas ir patiešām svarīgi mašīnmācīšanās projektos, kur datu kvalitāte ietekmēs mašīnmācīšanās rezultātu kvalitāti. Labi rezultāti nav sasniedzami ar zemas kvalitātes datiem.

  • Vizualizācija
    Šis ir izpilddirektora posms. Jūs, iespējams, esat dzirdējuši par situāciju, kad izpilddirektors skatās uz informācijas paneļa esošajiem numuriem un saka: “Labi, mēs esam ieguvuši lielu peļņu šogad, pat vairāk nekā iepriekš, bet kāpēc visi finanšu parametri atrodas sarkanajā zonā ? ” Un šajā brīdī ir par vēlu meklēt kļūdas, jo tās jau sen vajadzēja noķert.

Visa pamatā ir komunikācija. Un par sarunu tēmām. Lūk, piemērs tam, kas jāapspriež, gatavojot Yandex straumēšanu:

Mārketinga BI: sniega tīrītājs, Google Analytics, Yandex

Atbildes uz lielāko daļu no šiem jautājumiem atradīsit tikai kopā ar visu komandu. Jo, kad kāds pieņem lēmumu, pamatojoties uz minējumiem vai personīgo viedokli, nepārbaudot ideju ar citiem, var parādīties kļūdas.

Sarežģītības ir visur, pat visvienkāršākajās vietās.

Lūk, vēl viens piemērs: izsekojot produktu karšu seansu rādītājus, analītiķis pamana kļūdu. Trāpījumu datos visi reklāmkarogu un produktu karšu seansi tika nosūtīti uzreiz pēc lapas ielādes. Bet mēs nevaram būt pārliecināti, vai lietotājs tiešām visu apskatīja lapā. Analītiķis ierodas komandā, lai viņus par to detalizēti informētu.

BI saka, ka mēs nevaram atstāt situāciju tā.

Kā mēs varam aprēķināt MPT, ja pat nevaram būt droši, vai produkts tika parādīts? Kāds tad ir kvalificētais attēlu VKS?

Mārketinga speciālisti atbild:

Lūk, visi, mēs varam izveidot pārskatu, kurā parādīts vislabākais VKS, un pārbaudīt to salīdzinājumā ar līdzīgu reklāmas reklāmkarogu vai fotoattēlu citās vietās.

Tad izstrādātāji teiks:

Jā, mēs varam atrisināt šo problēmu, izmantojot mūsu jauno ritināšanas izsekošanas un objekta redzamības pārbaudes integrāciju.

Visbeidzot, UI / UX dizaineri saka:

Jā! Mēs varam izvēlēties, vai mums beidzot ir nepieciešama slinka vai mūžīga ritināšana vai lapošana!

Šeit ir soļi, ko šī mazā komanda veica:

  1. Definēja problēmu
  2. Iepazīstināja ar problēmas uzņēmējdarbības sekām
  3. Izmērīja izmaiņu ietekmi
  4. Iepazīstināja ar tehniskiem lēmumiem
  5. Atklāja netīkamo peļņu

Lai atrisinātu šo problēmu, viņiem jāpārbauda datu vākšana no visām sistēmām. Daļējs risinājums vienā datu shēmas daļā neatrisinās biznesa problēmu.

izlīdzināt pielāgot dizainu

Tāpēc mums ir jāstrādā kopā. Dati katru dienu jāapkopo atbildīgi, un to izdarīt ir smags darbs. Un datu kvalitāte ir jāsasniedz līdz īrēt īstos cilvēkus, nopirkt pareizos rīkus un ieguldīt naudu, laiku un pūles efektīvu komunikācijas struktūru izveidē, kas ir vitāli svarīgi organizācijas panākumiem.

Ko jūs domājat?

Šī vietne izmanto Akismet, lai samazinātu surogātpastu. Uzziniet, kā tiek apstrādāts jūsu komentārs.