Takım İletişimi Neden Martech Yığınınızdan Daha Önemli?

Pazarlama Ekibi İletişimi ve Analizi

Simo Ahava'nın veri kalitesi ve iletişim yapıları konusundaki alışılmadık bakış açısı, tüm salonu tazeledi. Analytics'e gidin! konferans. OWOXBDT bölgesindeki MarTech lideri, bilgi ve fikirlerini paylaşmak için bu toplantıda binlerce uzmanı ağırladı.

OWOX BI Ekibi kesinlikle işinizi büyütme potansiyeline sahip olan Simo Ahava'nın önerdiği konsept üzerinde düşünmenizi isterim. 

Organizasyonun Veri Kalitesi ve Kalitesi

Verilerin kalitesi, onu analiz eden kişiye bağlıdır. Tipik olarak, araçlar, iş akışları ve veri kümelerindeki verilerdeki tüm kusurları suçlarız. Ama bu mantıklı mı?

Açıkçası, verilerin kalitesi doğrudan kuruluşlarımız içinde nasıl iletişim kurduğumuzla bağlantılıdır. Organizasyonun kalitesi, veri madenciliği, tahmin ve ölçüm yaklaşımından başlayarak, işlemeye devam ederek ve ürünün genel kalitesi ve karar verme ile biten her şeyi belirler. 

Şirketler ve İletişim Yapıları

Bir şirketin tek bir araçta uzmanlaştığını hayal edelim. Bu şirketteki insanlar, B2B segmenti için belirli sorunları bulma ve çözme konusunda harikalar. Her şey harika ve şüphesiz bunun gibi birkaç şirket tanıyorsunuz.

Bu şirketlerin faaliyetlerinin yan etkileri, uzun vadeli veri kalitesi gereksinimlerini artırma sürecinde gizlidir. Aynı zamanda, verileri analiz etmek için oluşturulan araçların yalnızca verilerle çalıştığını ve bunları çözmek için oluşturulmuş olsalar bile iş sorunlarından izole edildiğini unutmamalıyız. 

Bu yüzden başka tür bir firma ortaya çıktı. Bu şirketler, iş akışı hata ayıklamasında uzmanlaşmıştır. İş süreçlerinde bir sürü sorun bulabilir, bunları beyaz tahtaya koyabilir ve yöneticilere şunları söyleyebilirler:

Burada, burada ve orada! Bu yeni iş stratejisini uygulayın ve iyi olacaksınız!

Ama kulağa gerçek olamayacak kadar iyi geliyor. Araçların anlaşılmasına dayanmayan tavsiyelerin etkinliği şüphelidir. Ve bu danışmanlık firmaları bu tür sorunların neden ortaya çıktığını, her yeni günün neden yeni karmaşıklıklar ve hatalar getirdiğini ve hangi araçların yanlış kurulduğunu anlamama eğilimindedir.

Dolayısıyla bu şirketlerin kendi başlarına yararlılıkları sınırlıdır. 

Hem iş uzmanlığı hem de araç bilgisi olan şirketler var. Bu şirketlerde herkes, beceri ve bilgilerinden emin, büyük niteliklere sahip kişileri işe almak konusunda takıntılıdır. Güzel. Ancak tipik olarak, bu şirketler genellikle önemsiz gördükleri ekip içindeki iletişim sorunlarını çözmeyi amaçlamazlar. Yeni sorunlar ortaya çıktıkça, cadı avı başlar - bu kimin hatası? Belki BI uzmanları süreçleri karıştırdı? Hayır, programcılar teknik açıklamayı okumadılar. Ama sonuçta, gerçek sorun, ekibin sorunu birlikte çözmek için sorunu net bir şekilde düşünememesidir. 

Bu bize, havalı uzmanlarla dolu bir şirkette bile, organizasyon değilse her şeyin gereğinden fazla çaba gerektireceğini gösteriyor. olgun yeter. Yetişkin olmanız ve sorumlu olmanız gerektiği fikri, özellikle bir kriz anında, çoğu şirkette insanların düşündüğü son şeydir.

Anaokuluna giden iki yaşındaki çocuğum bile birlikte çalıştığım bazı kuruluşlardan daha olgun görünüyor.

Yalnızca çok sayıda uzmanı işe alarak verimli bir şirket oluşturamazsınız, çünkü hepsi bir grup veya departman tarafından emilir. Dolayısıyla yönetim uzmanları işe almaya devam ediyor, ancak iş akışının yapısı ve mantığı hiç değişmediği için hiçbir şey değişmiyor.

Bu grupların ve departmanların içinde ve dışında iletişim kanalları oluşturmak için hiçbir şey yapmazsanız tüm çabalarınız anlamsız olacaktır. Bu nedenle iletişim stratejisi ve olgunluk Ahava'nın odak noktasıdır.

Analitik Şirketlere Uygulanan Conway Yasası

Anlamlı Veriler - Conway Yasası

Elli yıl önce, Melvin Conway adlı büyük bir programcı, daha sonra popüler olarak Conway yasası olarak bilinen bir öneride bulundu: 

Sistemleri tasarlayan kuruluşlar. . . bu kuruluşların iletişim yapılarının kopyaları olan tasarımlar üretmekle sınırlıdır.

Melvin Conway, Conway Yasası

Bu düşünceler, bir bilgisayarın bir odaya mükemmel bir şekilde sığdığı bir zamanda ortaya çıktı! Düşünün: Burada bir bilgisayarda çalışan bir ekibimiz var ve orada başka bir bilgisayarda çalışan başka bir ekibimiz var. Ve gerçek hayatta Conway yasası, bu ekipler arasında ortaya çıkan tüm iletişim kusurlarının geliştirdikleri programların yapısı ve işlevselliğine yansıyacağı anlamına gelir. 

Yazarın notu:

Bu teori, geliştirme dünyasında yüzlerce kez test edildi ve çok tartışıldı. Conway yasasının en kesin tanımı, 2000'li yılların başlarının en etkili programcılarından biri olan Pieter Hintjens tarafından oluşturuldu ve "boktan bir organizasyonun içindeyseniz, boktan bir yazılım yaparsınız." (Amdahl'dan Zipf'e: İnsanların Fiziğinin On Yasası)

Pazarlama ve analiz dünyasında bu yasanın nasıl işlediğini görmek kolaydır. Bu dünyada şirketler, farklı kaynaklardan toplanan dev miktarda verilerle çalışıyor. Hepimiz verilerin kendisinin adil olduğu konusunda hemfikir olabiliriz. Ancak veri kümelerini yakından incelerseniz, bu verileri toplayan kuruluşların tüm kusurlarını göreceksiniz:

  • Mühendislerin bir sorun üzerinde konuşmadığı eksik değerler 
  • Kimsenin dikkat etmediği ve kimsenin ondalık basamak sayısını tartışmadığı yanlış formatlar
  • Aktarım biçimini (toplu iş veya akış) kimsenin bilmediği ve verileri kimin alması gereken iletişim gecikmeleri

Bu nedenle veri alışverişi sistemleri kusurlarımızı tamamen açığa çıkarır.

Veri kalitesi, araç uzmanlarının, iş akışı uzmanlarının, yöneticilerin başarısı ve tüm bu insanlar arasındaki iletişimdir.

Multidisipliner Takımlar İçin En İyi ve En Kötü İletişim Yapıları

Bir MarTech veya pazarlama analizi şirketindeki tipik bir proje ekibi, iş zekası (BI) uzmanları, veri bilimcileri, tasarımcılar, pazarlamacılar, analistler ve programcılardan (herhangi bir kombinasyon halinde) oluşur.

Peki iletişimin önemini anlamayan bir takımda ne olacak? Bakalım. Programcılar uzun süre kod yazacak, çok çabalayacaklar, ekibin başka bir kısmı ise onların batonu geçmesini bekleyecek. Sonunda beta sürümü yayınlanacak ve herkes neden bu kadar uzun sürdüğü konusunda mırıldanıyor olacak. Ve ilk kusur ortaya çıktığında, herkes suçlayacak birini aramaya başlayacak, ancak onları oraya getiren durumdan kaçınmanın yollarını aramayacaktır. 

Daha derinlemesine bakarsak, karşılıklı hedeflerin doğru (ya da hiç) anlaşılmadığını görürüz. Ve böyle bir durumda hasarlı veya kusurlu bir ürün elde ederiz. 

Çok Disiplinli Takımları Teşvik Edin

Bu durumun en kötü özellikleri:

  • Yetersiz katılım
  • Yetersiz katılım
  • İşbirliği eksikliği
  • Güven eksikliği

Nasıl düzeltebiliriz? Kelimenin tam anlamıyla insanları konuşturarak. 

Multidisipliner Takımları Teşvik Edin

Herkesi bir araya toplayalım, tartışma konuları belirleyelim ve haftalık toplantılar planlayalım: BI ile pazarlama, tasarımcılarla programcılar ve veri uzmanları. O zaman insanların proje hakkında konuşmasını umarız. Ancak bu yine de yeterli değil çünkü ekip üyeleri hala tüm proje hakkında konuşmuyor ve tüm ekiple konuşmuyor. Onlarca toplantıyla kar yağmak kolaydır, çıkış yok ve işi yapmak için zaman yok. Ve toplantılardan sonraki mesajlar geri kalan zamanı ve bir sonraki adımda ne yapılacağını anlamayı öldürecek. 

Bu yüzden buluşma sadece ilk adımdır. Hala bazı sorunlarımız var:

  • Zayıf iletişim
  • Karşılıklı hedef eksikliği
  • Yetersiz katılım

Bazen insanlar proje hakkında önemli bilgileri meslektaşlarına aktarmaya çalışırlar. Ancak dedikodu makinesi gelen mesaj yerine onlar için her şeyi yapıyor. İnsanlar düşüncelerini ve fikirlerini doğru bir şekilde ve uygun ortamda nasıl paylaşacaklarını bilmediklerinde, alıcıya giden yolda bilgi kaybolacaktır. 

Bunlar, iletişim sorunları ile mücadele eden bir şirketin belirtileridir. Ve toplantılarla onları iyileştirmeye başlar. Ama her zaman başka bir çözümümüz var.

Herkesi proje üzerinden iletişim kurmaya yönlendirin. 

Takımlar halinde çok disiplinli iletişim

Bu yaklaşımın en iyi özellikleri:

  • Şeffaflık
  • ilgi
  • Bilgi ve beceri alışverişi
  • Kesintisiz eğitim

Bu, yaratılması zor olan son derece karmaşık bir yapıdır. Bu yaklaşımı benimseyen birkaç çerçeve biliyor olabilirsiniz: Çevik, Yalın, Scrum. Adının ne olduğu önemli değil; hepsi “her şeyi aynı anda bir arada yapma” ilkesi üzerine inşa edilmiştir. Tüm bu takvimler, görev kuyrukları, demo sunumları ve stand-up toplantıları, insanların proje hakkında sık sık ve hep birlikte konuşmasını amaçlamaktadır.

Bu yüzden Agile'ı çok seviyorum çünkü projenin hayatta kalması için bir ön koşul olarak iletişimin önemini içeriyor.

Agile'dan hoşlanmayan bir analist olduğunuzu düşünüyorsanız, buna başka bir yoldan bakın: Çalışmalarınızın sonuçlarını - tüm işlenmiş verilerinizi, o harika kontrol panellerinizi, veri kümelerinizi - insanları göstermenize yardımcı olur. çabalarınızı takdir edin. Ancak bunu yapmak için meslektaşlarınızla buluşmalı ve onlarla yuvarlak masada konuşmalısınız.

Sıradaki ne? Herkes proje hakkında konuşmaya başladı. Şimdi sahibiz kaliteyi kanıtlamak için projenin. Bunu yapmak için, şirketler genellikle en yüksek mesleki niteliklere sahip bir danışman tutar. 

İyi bir danışmanın ana kriteri (size söyleyebilirim çünkü ben bir danışmanım) projeye katılımını sürekli olarak azaltmaktır.

Bir danışman, bir şirketi sadece küçük profesyonel sırlarla besleyemez çünkü bu, şirketi olgunlaştırmaz ve kendi kendini idame ettiremez. Şirketiniz danışmanınız olmadan yaşayamıyorsa, aldığınız hizmetin kalitesini göz önünde bulundurmalısınız. 

Bu arada, bir danışman rapor vermemeli veya sizin için ek bir el çifti olmamalıdır. Bunun için içeriden meslektaşlarınız var.

Yetki Verme Değil, Eğitim İçin Pazarlamacıları İşe Alın

Bir danışman tutmanın temel amacı eğitim, yapıları ve süreçleri düzeltmek ve iletişimi kolaylaştırmaktır. Bir danışmanın rolü aylık raporlama değil, kendisini projeye yerleştirmek ve ekibin günlük rutinine tamamen dahil olmaktır.

İyi stratejik pazarlama danışmanı Proje katılımcılarının bilgi ve anlayışındaki boşlukları doldurur. Ama işi asla birileri için yapmayabilir. Ve bir gün, herkesin danışman olmadan gayet iyi çalışması gerekecek. 

Etkili iletişimin sonuçları, cadı avının ve parmakla işaretin olmamasıdır. Bir göreve başlamadan önce, insanlar şüphelerini ve sorularını diğer ekip üyeleriyle paylaşır. Böylece çoğu sorun iş başlamadan önce çözülür. 

Tüm bunların pazarlama analizi işinin en karmaşık bölümünü nasıl etkilediğini görelim: veri akışlarını tanımlama ve verileri birleştirme.

Veri Aktarımı ve İşlemesinde İletişim Yapısı Nasıl Yansıtılır?

Bize aşağıdaki verileri veren üç kaynağımız olduğunu varsayalım: trafik verileri, e-ticaret ürün verileri / sadakat programından satın alma verileri ve mobil analitik verileri. Tüm bu verilerin Google Cloud'a akışından görselleştirme için her şeyi göndermeye kadar veri işleme aşamalarını tek tek geçeceğiz. Google Veri Stüdyosu yardımıyla Google BigQuery

Örneğimize göre, veri işlemenin her aşamasında net bir iletişim sağlamak için insanlar hangi soruları sormalı?

  • Veri toplama aşaması. Önemli bir şeyi ölçmeyi unutursak, zamanda geriye gidip onu yeniden ölçemeyiz. Önceden dikkat edilmesi gerekenler:
    • En önemli parametreleri ve değişkenleri neyi adlandıracağımızı bilmiyorsak, tüm karmaşayla nasıl başa çıkabiliriz?
    • Olaylar nasıl işaretlenecek?
    • Seçilen veri akışları için benzersiz tanımlayıcı ne olacak?
    • Güvenlik ve mahremiyetle nasıl ilgileneceğiz? 
    • Veri toplamada sınırlamalar olan verileri nasıl toplayacağız?
  • Veri akışının birleştirilmesi akışa. Aşağıdakileri göz önünde bulundur:
    • Ana ETL ilkeleri: Toplu iş mi yoksa akış tipi veri aktarımı mı? 
    • Akış ve toplu veri aktarımlarının birleşimini nasıl işaretleyeceğiz? 
    • Bunları aynı veri şemasında kayıp ve hata olmadan nasıl ayarlayacağız?
    • Zaman ve kronoloji soruları: Zaman damgalarını nasıl kontrol edeceğiz? 
    • Veri yenileme ve zenginleştirmenin zaman damgaları dahilinde doğru çalışıp çalışmadığını nasıl bilebiliriz?
    • İsabetleri nasıl doğrulayacağız? Geçersiz isabetler ne olur?

  • Veri toplama aşaması. Düşünülmesi gereken şeyler:
    • ETL süreçleri için özel ayarlar: Geçersiz verilerle ne yapmamız gerekiyor?
      Yama mı silmek mi? 
    • Bundan kar elde edebilir miyiz? 
    • Tüm veri setinin kalitesini nasıl etkileyecek?

Tüm bu aşamaların ilk prensibi, hataların üst üste yığılması ve birbirlerinden miras alınmasıdır. İlk aşamada bir kusurla toplanan veriler, sonraki tüm aşamalarda başınızın hafifçe yanmasına neden olacaktır. Ve ikinci ilke, veri kalitesi güvencesi için noktalar seçmeniz gerektiğidir. Çünkü toplama aşamasında, tüm veriler birbirine karıştırılacak ve karışık verilerin kalitesini etkileyemeyeceksiniz. Bu, veri kalitesinin makine öğrenimi sonuçlarının kalitesini etkileyeceği makine öğrenimi projeleri için gerçekten önemlidir. Düşük kaliteli verilerle iyi sonuçlar elde edilemez.

  • Görüntüleme
    Bu CEO aşaması. CEO gösterge panosundaki rakamlara bakıp şöyle dediğinde durumu duymuş olabilirsiniz: "Tamam, bu yıl daha önce olduğundan daha fazla kar elde ettik, ama neden tüm finansal parametreler kırmızı bölgede. ? " Ve şu anda, çok uzun zaman önce yakalanmış olmaları gerektiği için hataları aramak için çok geç.

Her şey iletişime dayanmaktadır. Ve konuşma konularında. Yandex akışını hazırlarken nelerin tartışılması gerektiğine dair bir örnek:

Pazarlama BI: Snowplow, Google Analytics, Yandex

Bu soruların çoğunun yanıtlarını yalnızca tüm ekibinizle birlikte bulacaksınız. Çünkü biri, fikri başkalarıyla test etmeden tahmin veya kişisel görüşe dayalı bir karar verdiğinde, hatalar ortaya çıkabilir.

Karmaşıklıklar her yerde, en basit yerlerde bile.

İşte bir örnek daha: Ürün kartlarının gösterim puanlarını izlerken, bir analist bir hata fark eder. İsabet verilerinde, tüm afiş ve ürün kartlarındaki tüm gösterimler, sayfa yüklendikten hemen sonra gönderildi. Ancak kullanıcının sayfadaki her şeye gerçekten bakıp bakmadığından emin olamayız. Analist, bu konuda ayrıntılı bilgi vermek için ekibe gelir.

BI durumu böyle bırakamayacağımızı söylüyor.

Ürünün gösterilip gösterilmediğinden bile emin olamazsak BGBM'yi nasıl hesaplayabiliriz? O halde resimler için uygun TO nedir?

Pazarlamacılar cevap veriyor:

Bakın millet, en iyi TO'yu gösteren bir rapor oluşturabilir ve başka yerlerdeki benzer bir reklam afişi veya fotoğrafla karşılaştırabiliriz.

Ve sonra geliştiriciler şöyle diyecek:

Evet, bu sorunu, kaydırma takibi ve konu görünürlük kontrolü için yeni entegrasyonumuzun yardımıyla çözebiliriz.

Son olarak, UI / UX tasarımcıları şunları söylüyor:

Evet! Sonunda tembel mi yoksa sonsuz kaydırmaya veya sayfalandırmaya mı ihtiyacımız olduğunu seçebiliriz!

İşte bu küçük ekibin geçtiği adımlar:

  1. Problemi tanımladı
  2. Sorunun ticari sonuçlarını sundu
  3. Değişikliklerin etkisini ölçtü
  4. Sunulan teknik kararlar
  5. Önemsiz karı keşfetti

Bu sorunu çözmek için, tüm sistemlerden veri toplamayı kontrol etmeleri gerekir. Veri şemasının bir bölümündeki kısmi bir çözüm, iş sorununu çözmez.

hizala tasarım ayarla

Bu yüzden birlikte çalışmalıyız. Veriler her gün sorumlu bir şekilde toplanmalıdır ve bunu yapmak zor bir iştir. Ve veri kalitesi şu şekilde elde edilmelidir: Doğru insanları işe almak, doğru araçları satın almak ve bir kuruluşun başarısı için hayati önem taşıyan etkili iletişim yapıları oluşturmak için para, zaman ve çaba harcamak.

Ne düşünüyorsunuz?

Bu site spam'i azaltmak için Akismet'i kullanıyor. Yorum verilerinizin nasıl işlendiğini öğrenin.