Miksi joukkoviestintä on tärkeämpää kuin Martech-pinosi

Markkinointitiimin viestintä ja analyysi

Simo Ahavan epätyypillinen näkökulma datan laatuun ja viestintärakenteisiin piristi koko salin Siirry Analyticsiin! konferenssi. OWOX, MarTechin johtaja IVY-alueella, toivotti tuhansia asiantuntijoita tervetulleiksi keräämään tietoa ja ideoita.

OWOX BI -tiimi haluaisin sinun miettivän Simo Ahavan ehdottaman konseptin, jolla on ehdottomasti potentiaalia saada yrityksesi kasvamaan. 

Tietojen laatu ja organisaation laatu

Tietojen laatu riippuu henkilöstä, joka analysoi niitä. Yleensä syytämme kaikkia työkalujen, työnkulkujen ja tietojoukkojen tietojen puutteita. Mutta onko se järkevää?

Suoraan sanottuna tietojen laatu riippuu suoraan siitä, miten kommunikoimme organisaatioissamme. Organisaation laatu määrää kaiken, alkaen lähestymistavasta tiedonlouhintaan, arviointiin ja mittaamiseen, jatkamalla käsittelyä ja päättyen tuotteen yleiseen laatuun ja päätöksentekoon. 

Yritykset ja niiden viestintärakenteet

Kuvitellaan, että yritys on erikoistunut yhteen työkaluun. Tämän yrityksen ihmiset löytävät hienosti tiettyjä ongelmia ja ratkaisevat ne B2B-segmentille. Kaikki on hienoa, ja epäilemättä tunnet pari tällaista yritystä.

Näiden yritysten toiminnan sivuvaikutukset ovat piilossa pitkäaikaisessa prosessissa, jolla nostetaan tietojen laatuvaatimuksia. Samalla on syytä muistaa, että tietojen analysointiin luotut työkalut toimivat vain datan kanssa ja ovat eristettyjä liiketoiminnan ongelmista - vaikka ne olisi luotu niiden ratkaisemiseksi. 

Siksi on syntynyt toisenlainen yritys. Nämä yritykset ovat erikoistuneet työnkulun virheenkorjaukseen. He voivat löytää koko joukon ongelmia liiketoimintaprosesseissa, laittaa ne taululle ja kertoa johtajille:

Täällä, täällä ja siellä! Käytä tätä uutta liiketoimintastrategiaa ja olet kunnossa!

Mutta se kuulostaa liian hyvältä ollakseen totta. Neuvojen tehokkuus, joka ei perustu työkalujen ymmärtämiseen, on kyseenalaista. Ja ne konsulttiyritykset eivät yleensä ymmärrä, miksi tällaiset ongelmat ilmaantuivat, miksi jokainen uusi päivä tuo uusia monimutkaisuuksia ja virheitä ja mitkä työkalut on asetettu väärin.

Joten näiden yritysten hyöty yksin on rajallinen. 

On yrityksiä, joilla on sekä liiketoimintaosaamista että osaamista työkaluista. Näissä yrityksissä kaikki ovat pakkomielle palkkaamaan ihmisiä, joilla on erinomaiset ominaisuudet, asiantuntijoita, jotka ovat varmoja taidoistaan ​​ja tietämyksestään. Viileä. Mutta tyypillisesti näiden yritysten tarkoituksena ei ole ratkaista viestintäongelmia tiimin sisällä, mikä heidän mielestään on usein merkityksetöntä. Joten uusien ongelmien ilmaantuessa noita metsästys alkaa - kenen vika se on? Ehkä BI-asiantuntijat sekoittivat prosessit? Ei, ohjelmoijat eivät lukeneet teknistä kuvausta. Mutta kaiken kaikkiaan todellinen ongelma on, että joukkue ei voi ajatella ongelmaa selkeästi ratkaistakseen sen yhdessä. 

Tämä osoittaa meille, että jopa yrityksessä, joka on täynnä hienoja asiantuntijoita, kaikki vie enemmän kuin tarvitaan, ellei organisaatio ole kypsä tarpeeksi. Ajatus siitä, että sinun on oltava aikuinen ja vastuussa etenkin kriisitilanteessa, on viimeinen asia, mistä ihmiset ajattelevat useimmissa yrityksissä.

Jopa kaksivuotias lapsi, joka käy päiväkodissa, näyttää kypsemmältä kuin jotkut järjestöt, joiden kanssa olen työskennellyt.

Tehokasta yritystä ei voi luoda vain palkkaamalla suuren määrän asiantuntijoita, koska jokin ryhmä tai osasto imee heidät kaikki. Joten johto jatkaa asiantuntijoiden palkkaamista, mutta mikään ei muutu, koska työnkulun rakenne ja logiikka eivät muutu lainkaan.

Jos et tee mitään luoda viestintäkanavia näiden ryhmien ja osastojen sisällä ja ulkopuolella, kaikki ponnistelusi ovat merkityksettömiä. Siksi Ahavan painopiste on viestintästrategia ja kypsyys.

Conwayn lakia sovellettiin Analytics-yrityksiin

Merkitykselliset tiedot - Conwayn laki

Viisikymmentä vuotta sitten suuri ohjelmoija nimeltä Melvin Conway teki ehdotuksen, josta myöhemmin tuli yleisesti tunnettu nimellä Conwayn laki: 

Järjestöt, jotka suunnittelevat järjestelmiä. . . on pakko tuottaa malleja, jotka ovat kopioita näiden organisaatioiden viestintärakenteista.

Melvin Conway, Conwayn laki

Nämä ajatukset ilmestyivät aikaan, jolloin yksi tietokone sopi täydellisesti yhteen huoneeseen! Kuvittele vain: Täällä meillä on yksi joukkue työskentelee yhdellä tietokoneella, ja siellä meillä on toinen tiimi, joka työskentelee toisella tietokoneella. Todellisessa elämässä Conwayn laki tarkoittaa, että kaikki näiden joukkueiden joukossa esiintyvät viestintävirheet heijastuvat heidän kehittämiensä ohjelmien rakenteessa ja toiminnallisuudessa. 

Tekijän huomautus:

Tätä teoriaa on testattu satoja kertoja kehitysmaailmassa ja siitä on keskusteltu paljon. Varmimman määritelmän Conwayn laista loi Pieter Hintjens, yksi 2000-luvun alun vaikutusvaltaisimmista ohjelmoijista, ja sanoi, että "jos olet paska organisaatiossa, teet paskaa ohjelmistoa". (Amdahlista Zipfiin: Ihmisten fysiikan kymmenen lakia)

On helppo nähdä, miten tämä laki toimii markkinointi- ja analyysimaailmassa. Tässä maailmassa yritykset työskentelevät valtavan määrän tietoja eri lähteistä. Voimme kaikki olla yhtä mieltä siitä, että itse data on oikeudenmukaista. Mutta jos tarkistat tietojoukot tarkasti, näet kaikki tiedot keränneiden organisaatioiden puutteet:

  • Puuttuvat arvot, joissa insinöörit eivät ole puhuneet asiasta 
  • Väärät muodot, joissa kukaan ei kiinnittänyt huomiota eikä kukaan keskustellut desimaalien lukumäärästä
  • Viestinnän viiveet, kun kukaan ei tiedä siirtomuotoa (erä tai suoratoisto) ja kenen on vastaanotettava tiedot

Siksi tiedonvaihtojärjestelmät paljastavat puutteemme kokonaan.

Datan laatu on työkaluasiantuntijoiden, työnkulun asiantuntijoiden, johtajien ja kaikkien näiden ihmisten välisen viestinnän saavutus.

Paras ja huono viestintärakenne monitieteisille ryhmille

Tyypillinen MarTech- tai markkinointi-analytiikkayrityksen projektitiimi koostuu liiketoimintatiedon (BI) asiantuntijoista, datatutkijoista, suunnittelijoista, markkinoijista, analyytikoista ja ohjelmoijista (missä tahansa yhdistelmässä).

Mutta mitä tapahtuu tiimissä, joka ei ymmärrä viestinnän merkitystä? Katsotaan. Ohjelmoijat kirjoittavat koodia pitkään ja yrittävät kovasti, kun taas toinen osa tiimistä vain odottaa heidän välittävän kepin. Viimeinkin beetaversio julkaistaan, ja kaikki nurisevat miksi se kesti niin kauan. Ja kun ensimmäinen virhe ilmenee, kaikki alkavat etsiä jotakuta muuta syyllistä, mutta eivät tapoja välttää tilannetta, joka sai heidät sinne. 

Jos katsomme syvemmälle, huomaamme, että keskinäisiä tavoitteita ei ymmärretty oikein (tai ollenkaan). Ja tällaisessa tilanteessa saamme vahingoittuneen tai puutteellisen tuotteen. 

Kannusta monitieteisiä joukkueita

Tämän tilanteen pahimmat piirteet:

  • Riittämätön osallistuminen
  • Riittämätön osallistuminen
  • Yhteistyön puute
  • Epäluottamus

Kuinka voimme korjata sen? Kirjaimellisesti saamalla ihmiset puhumaan. 

Kannusta monialaisia ​​tiimejä

Kerätään kaikki yhdessä, asetetaan keskustelunaiheet ja ajoitetaan viikoittaiset kokoukset: markkinointi BI: n kanssa, ohjelmoijat suunnittelijoiden ja data-asiantuntijoiden kanssa. Sitten toivomme, että ihmiset puhuvat projektista. Mutta se ei silti riitä, koska tiimin jäsenet eivät vieläkään puhu koko projektista eivätkä puhu koko tiimin kanssa. Kymmenien kokousten ansiosta on helppo lumisateessa olla ilman uloskäyntiä eikä aikaa tehdä työtä. Ja nuo kokousten jälkeiset viestit tappavat lopun ajan ja ymmärryksen siitä, mitä tehdä seuraavaksi. 

Siksi tapaaminen on vasta ensimmäinen askel. Meillä on edelleen joitain ongelmia:

  • Huono viestintä
  • Keskinäisten tavoitteiden puuttuminen
  • Riittämätön osallistuminen

Joskus ihmiset yrittävät välittää tärkeitä tietoja projektista kollegoilleen. Mutta sen sijaan, että viesti olisi tullut läpi, huhukone tekee kaiken heidän puolestaan. Kun ihmiset eivät osaa jakaa ajatuksiaan ja ideoitaan oikein ja oikeassa ympäristössä, tieto menetetään matkalla vastaanottajalle. 

Nämä ovat oireita yrityksestä, joka kamppailee viestintäongelmien kanssa. Ja se alkaa parantaa heitä kokouksilla. Mutta meillä on aina toinen ratkaisu.

Ohjaa kaikki kommunikoimaan projektin yli. 

Monitieteinen viestintä ryhmissä

Tämän lähestymistavan parhaat ominaisuudet:

  • Läpinäkyvyys
  • Osallistuminen
  • Tietojen ja taitojen vaihto
  • Non-stop-koulutus

Tämä on erittäin monimutkainen rakenne, jota on vaikea luoda. Saatat tuntea muutaman kehyksen, jotka käyttävät tätä lähestymistapaa: Ketterä, Lean, Scrum. Ei ole väliä mitä nimität; ne kaikki on rakennettu "kaiken tekeminen samaan aikaan" -periaatteelle. Kaikkien näiden kalentereiden, tehtäväjonojen, esittelyesitysten ja stand-up-kokousten tarkoituksena on saada ihmiset puhumaan projektista usein ja yhdessä.

Siksi pidän ketterästä paljon, koska siihen sisältyy viestinnän merkitys projektin selviytymisen edellytyksenä.

Ja jos luulet olevasi analyytikko, joka ei pidä ketterästä, katsokaa sitä toisella tavalla: Se auttaa sinua näyttämään työsi tulokset - kaikki käsittelemäsi tiedot, nuo upeat kojelaudat, tietojoukot - saadaksesi ihmiset arvostaa ponnistelujasi. Mutta sen tekemiseksi sinun on tavattava kollegasi ja keskusteltava heidän kanssaan pyöreän pöydän ääressä.

Mitä seuraavaksi? Kaikki ovat alkaneet puhua projektista. Nyt meillä on todistaa laadun projektin. Tätä varten yritykset palkkaavat yleensä konsultin, jolla on korkein ammatillinen pätevyys. 

Hyvän konsultin tärkein kriteeri (voin kertoa teille, koska olen konsultti) vähentää jatkuvasti hänen osallistumistaan ​​projektiin.

Konsultti ei voi vain syöttää yritystä pieniin paljoihin ammattisalaisuuksia, koska se ei tee yrityksestä kypsää ja itsensä ylläpitävää. Jos yrityksesi ei voi jo elää ilman konsulttiasi, sinun on harkittava saamasi palvelun laatua. 

Muuten, konsultin ei pitäisi tehdä raportteja tai tulla ylimääräisiksi käsipareiksi sinulle. Sinulla on sisäisiä kollegoitasi.

Palkkaa markkinoijia koulutukseen, ei edustustoon

Konsultin palkkaamisen päätavoitteena on koulutus, rakenteiden ja prosessien vahvistaminen sekä viestinnän helpottaminen. Konsultin rooli ei ole kuukausiraportointi vaan pikemminkin istuttaminen projektiin ja täysin osallistuminen tiimin päivittäiseen rutiiniin.

Hyvä strategisen markkinoinnin konsultti täyttää aukot projektin osallistujien tietämyksessä ja ymmärryksessä. Mutta hän ei ehkä koskaan tee työtä jonkun puolesta. Ja jonain päivänä jokaisen on työskenneltävä hienosti ilman konsulttia. 

Tehokkaan viestinnän tuloksia ovat noidan metsästyksen ja sormen osoittamisen puuttuminen. Ennen tehtävän aloittamista ihmiset jakavat epäilynsä ja kysymyksensä muiden tiimin jäsenten kanssa. Siten suurin osa ongelmista ratkaistaan ​​ennen työn aloittamista. 

Katsotaanpa, miten kaikki tämä vaikuttaa markkinoinnin analyysityön monimutkaisimpaan osaan: tietovirtojen määrittelemiseen ja tietojen yhdistämiseen.

Kuinka tiedonsiirtorakenne heijastuu tiedonsiirrossa ja käsittelyssä?

Oletetaan, että meillä on kolme lähdettä, jotka antavat meille seuraavat tiedot: liikennetiedot, verkkokaupan tuotetiedot / kanta-asiakasohjelman ostotiedot ja mobiilianalyysitiedot. Käymme läpi tietojenkäsittelyvaiheet yksitellen kaikkien tietojen suoratoistosta Google Cloudiin kaikkien lähettämiseen visualisointia varten Google Data Studio avulla Googlen BigQuery

Mitä kysymyksiä esimerkin perusteella pitäisi kysyä, jotta varmistetaan selkeä viestintä tietojenkäsittelyn jokaisessa vaiheessa?

  • Tiedonkeruun vaihe. Jos unohdamme mitata jotain tärkeää, emme voi palata ajassa taaksepäin ja mitata sitä uudelleen. Huomioitavia asioita etukäteen:
    • Jos emme tiedä mitä nimetä tärkeimmät parametrit ja muuttujat, miten voimme käsitellä kaikkea sotkua?
    • Kuinka tapahtumat merkitään?
    • Mikä on valittujen tietovirtojen yksilöllinen tunniste?
    • Kuinka hoidamme turvallisuuden ja yksityisyyden? 
    • Kuinka keräämme tietoja siellä, missä tiedonkeruussa on rajoituksia?
  • Tietojen virta sulautuu streamiin. Harkitse seuraavaa:
    • Tärkeimmät ETL-periaatteet: Onko kyseessä erä- tai suoratyyppinen tiedonsiirto? 
    • Kuinka merkitsemme virta- ja erätiedonsiirron yhteydet? 
    • Kuinka mukautamme ne samassa datakaavassa ilman menetyksiä ja virheitä?
    • Aika- ja aikakysymykset: Kuinka tarkistamme aikaleimat? 
    • Mistä voimme tietää, toimiiko tietojen kunnostus ja rikastaminen oikein aikaleimoissa?
    • Kuinka osumat vahvistetaan? Mitä tapahtuu virheellisille osumille?

  • Tietojen yhdistämisvaihe. Huomioitavia asioita:
    • Erikoistuneet asetukset ETL-prosesseille: Mitä meidän on tehtävä virheellisten tietojen kanssa?
      Korjataanko vai poistetaanko? 
    • Voimmeko saada siitä voittoa? 
    • Kuinka se vaikuttaa koko tietojoukon laatuun?

Kaikkien näiden vaiheiden ensimmäinen periaate on, että virheet pinotaan päällekkäin ja perivät toisiltaan. Ensimmäisessä vaiheessa virheellisellä tavalla kerätyt tiedot saavat pään hiukan palamaan kaikissa seuraavissa vaiheissa. Toinen periaate on, että sinun tulisi valita pisteitä tietojen laadun varmistamiseksi. Koska yhdistämisvaiheessa kaikki tiedot sekoitetaan keskenään, etkä voi vaikuttaa sekoitettujen tietojen laatuun. Tämä on todella tärkeää koneoppimisprojekteille, joissa tiedon laatu vaikuttaa koneoppimisen tulosten laatuun. Hyviä tuloksia ei voida saavuttaa huonolaatuisella tiedolla.

  • Visualisointi
    Tämä on toimitusjohtaja. Olet ehkä kuullut tilanteesta, kun toimitusjohtaja tarkastelee kojelaudan numeroita ja sanoo: "Okei, meillä on tänä vuonna paljon voittoa, jopa enemmän kuin aiemmin, mutta miksi kaikki taloudelliset parametrit ovat punaisella vyöhykkeellä ? ” Ja tällä hetkellä on liian myöhäistä etsiä virheitä, koska ne olisi pitänyt saada kiinni jo kauan sitten.

Kaikki perustuu viestintään. Ja keskustelunaiheista. Tässä on esimerkki siitä, mistä tulisi keskustella Yandex-suoratoistoa valmisteltaessa:

Markkinoinnin BI: Snowplow, Google Analytics, Yandex

Löydät vastaukset useimpiin näistä kysymyksistä vain yhdessä koko tiimin kanssa. Koska joku tekee päätöksen arvaamisen tai henkilökohtaisen mielipiteen perusteella testaamatta ajatusta muiden kanssa, voi ilmetä virheitä.

Monimutkaisuus on kaikkialla, jopa yksinkertaisimmissa paikoissa.

Tässä on vielä yksi esimerkki: Kun seuraat tuotekorttien näyttökertoja, analyytikko huomaa virheen. Osumatiedoissa kaikki bannereiden ja tuotekorttien näyttökerrat lähetettiin heti sivun lataamisen jälkeen. Mutta emme voi olla varmoja, katsoiko käyttäjä todella kaikkea sivulla. Analyytikko tulee tiimiin ilmoittamaan heille tästä yksityiskohtaisesti.

BI: n mukaan emme voi jättää tilannetta sellaiseksi.

Kuinka voimme laskea tuhannen näyttökerran hinnan, jos emme voi edes olla varmoja, näytetäänkö tuotetta? Mikä on kuvien pätevä napsautussuhde?

Markkinoijat vastaavat:

Kaikki, voimme luoda raportin, joka näyttää parhaan napsautussuhteen, ja tarkistaa sen vastaavalla mainospalkilla tai valokuvalla muissa paikoissa.

Ja sitten kehittäjät sanovat:

Kyllä, voimme ratkaista tämän ongelman uuden integraation avulla vierityksen seurantaan ja kohteen näkyvyyden tarkistamiseen.

Lopuksi UI / UX-suunnittelijat sanovat:

Joo! Voimme valita, tarvitsemmeko vihdoin laiskaa tai ikuista vieritystä tai sivunvaihtoa!

Tässä ovat vaiheet, jotka tämä pieni joukkue kävi läpi:

  1. Määritti ongelman
  2. Esitti ongelman liiketoiminnalliset seuraukset
  3. Mitattiin muutosten vaikutuksia
  4. Esitetyt tekniset päätökset
  5. Löysi ei-triviaalin voiton

Tämän ongelman ratkaisemiseksi heidän tulisi tarkistaa tiedonkeruu kaikista järjestelmistä. Osaratkaisu tietomallin yhdessä osassa ei ratkaise liiketoimintaongelmaa.

kohdista muotoilu

Siksi meidän on tehtävä yhteistyötä. Tiedot on kerättävä vastuullisesti joka päivä, ja se on kovaa työtä. Ja tietojen laatu on saavutettava vuoteen XNUMX mennessä oikeiden ihmisten palkkaaminen, oikeiden työkalujen ostaminen ja rahaa, aikaa ja vaivaa sijoittamalla tehokkaiden viestintärakenteiden rakentamiseen, mikä on elintärkeää organisaation menestykselle.

Mitä mieltä olet?

Tämä sivusto käyttää Akismetiä roskapostin vähentämiseksi. Lue, miten kommenttitietosi käsitellään.