Kodėl komandos komunikacija yra svarbesnė nei jūsų „Martech“ krūva

Marketingo komandos komunikacija ir analizė

Netipiškas Simo Ahavos požiūris į duomenų kokybę ir komunikacijos struktūras atgaivino visą salę Eikite į „Analytics“! konferencija. OWOX, „MarTech“ lyderis NVS regione, pasveikino tūkstančius ekspertų į šį susirinkimą pasidalinti savo žiniomis ir idėjomis.

„OWOX BI“ komanda norėčiau, kad pagalvotumėte apie Simo Ahavos pasiūlytą koncepciją, kuri neabejotinai gali paskatinti jūsų verslą augti. 

Duomenų kokybė ir organizacijos kokybė

Duomenų kokybė priklauso nuo asmens, kuris juos analizuoja. Paprastai mes kaltintume visus įrankių, darbo eigos ir duomenų rinkinių duomenų trūkumus. Bet ar tai pagrįsta?

Atvirai kalbant, duomenų kokybė yra tiesiogiai susijusi su tuo, kaip mes bendraujame savo organizacijose. Organizacijos kokybė lemia viską, pradedant požiūriu į duomenų gavybą, įvertinimą ir matavimą, tęsiant apdorojimą ir baigiant bendra produkto kokybe bei sprendimų priėmimu. 

Įmonės ir jų komunikacijos struktūros

Įsivaizduokime, kad įmonė specializuojasi viename įrankyje. Šios įmonės žmonės puikiai randa tam tikras problemas ir jas sprendžia B2B segmentui. Viskas puiku, ir, be abejo, žinote porą tokių kompanijų.

Šalutinis šių bendrovių veiklos poveikis yra paslėptas ilgalaikiame duomenų kokybės reikalavimų kelimo procese. Tuo pat metu turėtume prisiminti, kad įrankiai, sukurti analizuoti duomenis, veikia tik su duomenimis ir yra izoliuoti nuo verslo problemų, net jei jie sukurti jiems spręsti. 

Štai kodėl atsirado kitos rūšies įmonė. Šios įmonės specializuojasi derinant darbo eigą. Jie gali rasti daugybę problemų verslo procesuose, įdėti jas į lentą ir pasakyti vadovams:

Čia, čia ir ten! Taikykite šią naują verslo strategiją ir viskas bus gerai!

Bet tai skamba per daug gerai, kad būtų tiesa. Abejotinas patarimų, kurie nėra pagrįsti įrankių supratimu, efektyvumas. Tos konsultacinės firmos dažniausiai nesupranta, kodėl atsirado tokių problemų, kodėl kiekviena nauja diena įneša vis naujų sudėtingumų ir klaidų ir kurios priemonės sukurtos neteisingai.

Taigi šių bendrovių naudingumas atskirai yra ribotas. 

Yra įmonių, turinčių ir verslo patirties, ir žinių apie įrankius. Šiose įmonėse visi apsėsti samdyti puikių savybių žmones, ekspertus, kurie yra tikri savo įgūdžiais ir žiniomis. Saunus. Tačiau paprastai šios įmonės nesiekia išspręsti komunikacijos problemų komandoje, kuri, jų manymu, dažnai yra nesvarbi. Taigi, atsiradus naujoms problemoms, prasideda raganų medžioklė - kieno kaltė? Gal BI specialistai supainiojo procesus? Ne, programuotojai neskaitė techninio aprašymo. Bet apskritai tikroji problema yra ta, kad komanda negali aiškiai apgalvoti problemos, kad ją išspręstų kartu. 

Tai mums rodo, kad net ir įmonėje, kurioje yra daug šaunių specialistų, viskas prireiks daugiau pastangų, nei reikia, jei organizacija to nedaro subrendęs pakanka. Idėja, kad turite būti suaugęs žmogus ir būti atsakingas, ypač krizės metu, yra paskutinis dalykas, apie kurį žmonės galvoja daugumoje įmonių.

Net mano dvejų metų vaikas, einantis į darželį, atrodo labiau subrendęs nei kai kurios organizacijos, su kuriomis dirbau.

Negalite sukurti efektyvios įmonės tik samdydami daug specialistų, nes juos visus užvaldo kokia nors grupė ar skyrius. Taigi vadovybė ir toliau samdo specialistus, tačiau niekas nesikeičia, nes darbo eigos struktūra ir logika visiškai nesikeičia.

Jei nieko nedarysite kurdami bendravimo kanalus šiose grupėse ir skyriuose ir už jų ribų, visos jūsų pastangos bus beprasmės. Štai kodėl komunikacijos strategija ir branda yra „Ahava“ dėmesys.

„Conway“ įstatymas buvo taikomas „Analytics“ įmonėms

Prasmingi duomenys - Conway dėsnis

Prieš penkiasdešimt metų puikus programuotojas, vardu Melvinas Conway, pateikė pasiūlymą, kuris vėliau tapo populiarus kaip Conway įstatymas: 

Organizacijos, kurios kuria sistemas. . . yra priversti kurti dizainus, kurie yra šių organizacijų komunikacijos struktūrų kopijos.

Melvin Conway, Conway įstatymas

Šios mintys kilo tuo metu, kai vienas kompiuteris puikiai tinka vienam kambariui! Įsivaizduokite: čia viena komanda dirba prie vieno kompiuterio, o kita - prie kito kompiuterio. Realiame gyvenime Conway įstatymas reiškia, kad visi komunikacijos trūkumai, atsirandantys tarp tų komandų, atsispindės jų kuriamų programų struktūroje ir funkcionalume. 

Autoriaus pastaba:

Ši teorija šimtus kartų buvo išbandyta vystymosi pasaulyje ir buvo daug diskutuojama. Patikimiausią Conway dėsnio apibrėžimą sukūrė Pieteris Hintjensas, vienas įtakingiausių 2000-ųjų pradžios programuotojų, sakydamas, kad „jei esate šmaikščioje organizacijoje, sukursite šmaikščią programinę įrangą“. (Amdahl to Zipf: Dešimt žmonių fizikos dėsnių)

Nesunku suprasti, kaip šis įstatymas veikia rinkodaros ir analizės pasaulyje. Šiame pasaulyje įmonės dirba su milžinišku kiekiu duomenų, surinktų iš skirtingų šaltinių. Visi galime sutikti, kad patys duomenys yra teisingi. Bet atidžiai apžiūrėję duomenų rinkinius, pamatysite visus tuos duomenis surinkusių organizacijų trūkumus:

  • Trūksta vertybių, kur inžinieriai nekalbėjo 
  • Neteisingi formatai, kai niekas nekreipė dėmesio ir niekas neaptarė dešimtainių skaičių
  • Bendravimas vėluoja, kai niekas nežino perdavimo formato (paketo ar srauto) ir kas turi gauti duomenis

Štai kodėl duomenų mainų sistemos visiškai atskleidžia mūsų trūkumus.

Duomenų kokybė yra įrankių specialistų, darbo eigos ekspertų, vadybininkų pasiekimas ir visų šių žmonių bendravimas.

Geriausios ir blogiausios daugiadisciplininių komandų komunikacijos struktūros

Tipišką „MarTech“ ar rinkodaros analizės įmonės projektų komandą sudaro verslo intelekto (BI) specialistai, duomenų mokslininkai, dizaineriai, rinkodaros specialistai, analitikai ir programuotojai (bet kokiu deriniu).

Bet kas nutiks komandoje, kuri nesupranta bendravimo svarbos? Pažiūrėkime. Programuotojai ilgai rašys kodą, stengdamiesi, o kita komandos dalis tiesiog lauks, kol jie perims estafetę. Pagaliau bus išleista beta versija ir visi murmės, kodėl tai užtruko taip ilgai. Kai pasirodys pirmasis trūkumas, visi pradės ieškoti kažko kito, kas būtų kaltas, bet ne būdų, kaip išvengti situacijos, kuri juos ten pateko. 

Jei pažvelgsime giliau, pamatysime, kad abipusiai tikslai nebuvo suprasti teisingai (arba apskritai). Ir tokioje situacijoje gausime sugadintą ar sugedusį produktą. 

Skatinkite daugiadalykes komandas

Blogiausios šios situacijos savybės:

  • Nepakankamas įsitraukimas
  • Nepakankamas dalyvavimas
  • Bendradarbiavimo stoka
  • Trūksta pasitikėjimo

Kaip mes galime tai išspręsti? Pažodžiui verčiant žmones kalbėti. 

Skatinkite daugiadisciplinines komandas

Surinkime visus kartu, nustatykime diskusijų temas ir planuokime savaitinius susitikimus: rinkodara su BI, programuotojai su dizaineriais ir duomenų specialistais. Tada tikėsimės, kad žmonės kalbės apie projektą. Bet to vis tiek nepakanka, nes komandos nariai vis dar nekalba apie visą projektą ir nekalba su visa komanda. Lengva pasnigti, nes vyksta dešimtys susitikimų, nėra išeities ir laiko atlikti darbus. Tos žinutės po susitikimų pražudys likusį laiką ir supras, ką daryti toliau. 

Todėl susitikimas yra tik pirmas žingsnis. Mes vis dar turime tam tikrų problemų:

  • Blogas bendravimas
  • Abipusių tikslų stoka
  • Nepakankamas įsitraukimas

Kartais žmonės bando perduoti svarbią informaciją apie projektą savo kolegoms. Tačiau užuot gavus pranešimą, gandų mašina viską padaro už juos. Kai žmonės nežino, kaip tinkamai ir tinkamoje aplinkoje pasidalinti savo mintimis ir idėjomis, informacija bus prarasta pakeliui pas gavėją. 

Tai yra įmonės, kovojančios su komunikacijos problemomis, simptomai. Ir tai pradeda juos gydyti susitikimais. Bet mes visada turime kitą sprendimą.

Nurodykite visiems bendrauti apie projektą. 

Daugiadisciplininis bendravimas komandose

Geriausios šio požiūrio savybės:

  • Skaidrumas
  • Dalyvavimas
  • Žinių ir įgūdžių mainai
  • Švietimas be perstojo

Tai itin sudėtinga struktūra, kurią sunku sukurti. Galbūt žinote keletą šio požiūrio rėmų: „Agile“, „Lean“, „Scrum“. Nesvarbu, kaip jį pavadinsi; visi jie sukurti remiantis principu „sudaryti viską kartu“. Visi šie kalendoriai, užduočių eilės, demonstraciniai pristatymai ir pasirengimo susitikimai yra skirti tam, kad žmonės kalbėtų apie projektą dažnai ir visi kartu.

Štai kodėl man labai patinka „Agile“, nes tai apima bendravimo svarbą, kaip būtiną projekto išlikimo sąlygą.

Ir jei manote, kad esate analitikas, kuriam nepatinka „Agile“, pažvelkite į jį kitu būdu: tai padeda parodyti savo darbo rezultatus - visus apdorotus duomenis, tas puikias informacijos suvestines, duomenų rinkinius - kad žmonės taptų įvertink jūsų pastangas. Tačiau norint tai padaryti, turite susitikti su kolegomis ir kalbėtis su jais prie apskritojo stalo.

Kas toliau? Visi pradėjo kalbėti apie projektą. Dabar mes turime įrodyti kokybę projekto. Tam įmonės paprastai samdo aukščiausios profesinės kvalifikacijos konsultantą. 

Pagrindinis gero konsultanto kriterijus (galiu pasakyti, nes esu konsultantas) nuolat mažina jo dalyvavimą projekte.

Konsultantas gali ne tik pateikti įmonei nedidelių profesinių paslapčių, nes tai nepadarys įmonės brandžios ir savarankiškos. Jei jūsų įmonė jau negali gyventi be jūsų konsultanto, turėtumėte atsižvelgti į gautos paslaugos kokybę. 

Beje, konsultantas neturėtų daryti ataskaitų ar tapti jums papildoma rankų pora. Tam turite savo vidinių kolegų.

Samdykite rinkodaros specialistus, o ne delegacijas

Pagrindinis konsultanto samdymo tikslas yra švietimas, struktūrų ir procesų nustatymas ir bendravimo palengvinimas. Konsultanto vaidmuo yra ne kas mėnesį teikiamos ataskaitos, o pats įsitvirtinimas projekte ir visiškas dalyvavimas komandos kasdienybėje.

Geras strateginės rinkodaros konsultantas užpildo projekto dalyvių žinių ir supratimo spragas. Bet jis niekada negali padaryti darbo už ką nors. Vieną dieną visiems reikės dirbti puikiai, be konsultanto. 

Efektyvaus bendravimo rezultatai - raganų medžioklės ir pirštų rodymo nebuvimas. Prieš pradedant užduotį, žmonės dalijasi abejonėmis ir klausimais su kitais komandos nariais. Taigi, dauguma problemų išsprendžiamos prieš pradedant darbą. 

Pažiūrėkime, kaip visa tai įtakoja sudėtingiausią rinkodaros analizės darbo dalį: duomenų srautų apibrėžimą ir duomenų sujungimą.

Kaip duomenų perdavimo ir apdorojimo metu atsispindi komunikacijos struktūra?

Tarkime, kad turime tris šaltinius, pateikiančius šiuos duomenis: srauto duomenis, el. Prekybos produktų duomenis / pirkimo duomenis iš lojalumo programos ir mobiliosios analizės duomenis. Duomenų apdorojimo etapus atliksime po vieną, nuo visų duomenų perdavimo į „Google Cloud“ iki visko siuntimo vizualizuoti "Google" duomenų studija su pagalba „Google BigQuery“

Remiantis mūsų pavyzdžiu, kokius klausimus žmonės turėtų užduoti, kad užtikrintų aiškų bendravimą kiekvienu duomenų apdorojimo etapu?

  • Duomenų rinkimo etapas. Pamiršę išmatuoti ką nors svarbaus, negalime grįžti į praeitį ir to iš naujo įvertinti. Dalykai, į kuriuos reikia atsižvelgti iš anksto:
    • Jei nežinome, kaip įvardyti svarbiausius parametrus ir kintamuosius, kaip mes galime susitvarkyti su visais netvarkais?
    • Kaip bus pažymėti įvykiai?
    • Koks bus unikalus pasirinktų duomenų srautų identifikatorius?
    • Kaip mes pasirūpinsime saugumu ir privatumu? 
    • Kaip rinksime duomenis ten, kur yra duomenų rinkimo apribojimai?
  • Duomenų srautai sujungiami į srautą. Apsvarstykite šiuos dalykus:
    • Pagrindiniai ETL principai: ar tai yra duomenų perdavimo paketo ar srauto tipas? 
    • Kaip pažymėsime srauto ir paketinių duomenų perdavimo jungtį? 
    • Kaip mes juos pritaikysime toje pačioje duomenų schemoje be nuostolių ir klaidų?
    • Laiko ir chronologijos klausimai: Kaip patikrinsime laiko žymes? 
    • Kaip mes galime žinoti, ar duomenų atnaujinimas ir praturtinimas veikia tinkamai laikui bėgant?
    • Kaip patvirtinsime įvykius? Kas nutinka su negaliojančiais įvykiais?

  • Duomenų kaupimo etapas. Į ką reikėtų atsižvelgti:
    • Specializuoti ETL procesų nustatymai: ką turime daryti su neteisingais duomenimis?
      Pataisyti ar ištrinti? 
    • Ar galime iš to gauti pelno? 
    • Kaip tai paveiks viso duomenų rinkinio kokybę?

Pirmasis visų šių etapų principas yra tas, kad klaidos kaupiasi viena ant kitos ir paveldi viena iš kitos. Pirmajame etape surinkti duomenys su trūkumu privers šiek tiek sudeginti galvą per visus tolesnius etapus. Antrasis principas yra tas, kad turėtumėte pasirinkti taškus duomenų kokybei užtikrinti. Nes kaupimo etape visi duomenys bus sumaišyti ir jūs negalėsite paveikti mišrių duomenų kokybės. Tai tikrai svarbu mašininio mokymosi projektuose, kur duomenų kokybė paveiks mašininio mokymosi rezultatų kokybę. Gerų rezultatų negalima pasiekti naudojant žemos kokybės duomenis.

  • Vizualizacija
    Tai generalinio direktoriaus etapas. Galbūt girdėjote apie situaciją, kai generalinis direktorius pažvelgė į prietaisų skydelio skaičius ir sako: „Gerai, šiais metais mes turime daug pelno, net daugiau nei anksčiau, bet kodėl visi finansiniai parametrai yra raudonojoje zonoje ? “ Ir šiuo metu jau per vėlu ieškoti klaidų, nes jas jau seniai reikėjo pagauti.

Viskas remiasi bendravimu. Ir pokalbio temomis. Štai pavyzdys, ką reikėtų aptarti ruošiant „Yandex“ srautą:

Rinkodaros BI: „Snowplow“, „Google Analytics“, „Yandex“

Atsakymus į daugumą šių klausimų rasite tik kartu su visa komanda. Nes kai kas nors priima sprendimą pagal spėjimą ar asmeninę nuomonę, neišbandydamas idėjos su kitais, gali atsirasti klaidų.

Sudėtingumo yra visur, net paprasčiausiose vietose.

Štai dar vienas pavyzdys: stebėdamas produktų kortelių parodymų balus, analitikas pastebi klaidą. Rezultatų duomenyse visi reklaminių antraščių ir produktų kortelių parodymai buvo išsiųsti iškart po puslapio įkėlimo. Tačiau negalime būti tikri, ar vartotojas tikrai viską apžiūrėjo puslapyje. Analitikas ateina į komandą, kad apie tai išsamiai informuotų.

BI sako, kad negalime taip palikti situacijos.

Kaip mes galime apskaičiuoti MUT, jei net negalime būti tikri, ar produktas buvo parodytas? Koks tada yra kvalifikuotas nuotraukų PR?

Rinkodaros specialistai atsako:

Žiūrėk, visi, mes galime sukurti ataskaitą, rodančią geriausią PR, ir patikrinti ją pagal panašią kūrybinę reklamjuostę ar nuotrauką kitose vietose.

Tada kūrėjai pasakys:

Taip, šią problemą galime išspręsti naudodamiesi savo nauja slinkties sekimo ir objekto matomumo tikrinimo integracija.

Galiausiai UI / UX dizaineriai sako:

Taip! Galime pasirinkti, ar mums pagaliau reikalingas tingus ar amžinas slinkimas ar paginavimas!

Štai žingsniai, kuriuos atliko ši maža komanda:

  1. Apibrėžė problemą
  2. Pateikė problemos verslo pasekmes
  3. Matuojamas pokyčių poveikis
  4. Pateikė techninius sprendimus
  5. Atrado nereikšmingą pelną

Norėdami išspręsti šią problemą, jie turėtų patikrinti visų sistemų surinktus duomenis. Dalinis vienos schemos dalies sprendimas verslo problemos neišspręs.

sulyginti koreguoti dizainą

Štai kodėl mes turime dirbti kartu. Duomenys turi būti renkami atsakingai kiekvieną dieną, o tai padaryti yra sunkus darbas. Ir duomenų kokybė turi būti pasiekta iki samdyti reikiamus žmones, pirkti tinkamas priemones ir investuoti pinigus, laiką ir pastangas kuriant efektyvias komunikacijos struktūras, kurios yra gyvybiškai svarbios organizacijos sėkmei.

Ką manote?

Ši svetainė naudoja "Akismet", kad sumažintų šlamštą. Sužinokite, kaip apdorojamas jūsų komentaras.