چرا ارتباط تیم مهمتر از Martech Stack شما است

ارتباطات و تجزیه و تحلیل تیم بازاریابی

دیدگاه غیرمعمول سیمو آهاوا در مورد کیفیت داده ها و ساختارهای ارتباطی فضای اتاق را در سالن تازه کرد به تجزیه و تحلیل بروید! کنفرانس. OWOX، رهبر MarTech در منطقه CIS ، از هزاران متخصص در این گردهمایی استقبال کرد تا دانش و ایده های خود را به اشتراک بگذارند.

تیم OWOX BI دوست دارم شما به مفهوم پیشنهادی سیمو آهاوا فکر کنید ، که قطعاً پتانسیل رشد کسب و کار شما را دارد. 

کیفیت داده ها و کیفیت سازمان

کیفیت داده ها به شخصی که آن را تجزیه و تحلیل می کند بستگی دارد. به طور معمول ، ما تمام نقایص موجود در داده ها را در ابزارها ، گردش کار و مجموعه داده ها مقصر می دانیم. اما آیا این منطقی است؟

صادقانه بگویم ، کیفیت داده ها مستقیماً به چگونگی برقراری ارتباط ما در سازمان ها وابسته است. کیفیت سازمان همه چیز را تعیین می کند ، شروع با رویکرد داده کاوی ، برآورد و اندازه گیری ، ادامه با پردازش و پایان دادن به کیفیت کلی محصول و تصمیم گیری. 

شرکت ها و ساختارهای ارتباطی آنها

بیایید تصور کنیم یک شرکت در یک ابزار تخصص دارد. افراد در این شرکت در یافتن مشکلات خاص و حل آنها برای بخش B2B بسیار عالی هستند. همه چیز عالی است ، و بدون شک شما یک شرکت زوج مانند این را می شناسید.

عوارض جانبی فعالیت این شرکت ها در روند طولانی مدت افزایش الزامات کیفیت داده ها پنهان است. در عین حال ، باید به یاد داشته باشیم که ابزارهای ایجاد شده برای تجزیه و تحلیل داده ها فقط با داده ها کار می کنند و از مشکلات تجاری جدا هستند - حتی اگر برای حل آنها ایجاد شده باشند. 

به همین دلیل یک نوع شرکت دیگر ظاهر شده است. این شرکت ها در اشکال زدایی گردش کار تخصص دارند. آنها می توانند یکسری مشکلات را در فرآیندهای تجاری پیدا کنند ، آنها را روی تخته سفید بگذارند و به مدیران بگویند:

اینجا ، اینجا ، و آنجا! این استراتژی جدید تجاری را اعمال کنید و خوب خواهید شد!

اما خیلی درست به نظر می رسد کارایی مشاوره ای که مبتنی بر درک ابزار نباشد ، جای تردید دارد. و آن شرکت های مشاوره نمی فهمند که چرا چنین مشکلاتی ظاهر شده است ، چرا هر روز جدید پیچیدگی ها و خطاهای جدیدی را به همراه می آورد و چه ابزارهایی به طور نادرست تنظیم شده اند.

بنابراین سودمندی این شرکتها به تنهایی محدود است. 

شرکت هایی وجود دارند که هم دارای تخصص تجاری و هم دارای دانش ابزار هستند. در این شرکت ها ، همه با استخدام افرادی با کیفیت عالی ، متخصصانی که در مهارت و دانش خود مطمئن هستند ، وسواس دارند. سرد. اما به طور معمول ، این شرکت ها برای حل مشکلات ارتباطی در داخل تیم نیستند ، که اغلب آنها را بی اهمیت می دانند. بنابراین با بروز مشکلات جدید ، شکار جادوگر آغاز می شود - تقصیر کیست؟ ممکن است متخصصان BI فرآیندها را اشتباه بگیرند؟ نه ، برنامه نویسان توضیحات فنی را نخوانده اند. در مجموع ، مشکل اصلی این است که تیم نمی تواند به طور واضح روی مسئله بیندیشد تا با هم آن را حل کنیم. 

این به ما نشان می دهد که حتی در یک شرکت پر از متخصصان جالب ، اگر این سازمان نباشد ، همه چیز بیش از حد لازم تلاش خواهد کرد بالغ کافی. این ایده که شما باید بالغ باشید و به ویژه در شرایط بحرانی مسئولیت پذیر باشید ، آخرین چیزی است که مردم در بیشتر شرکت ها به آن فکر می کنند.

به نظر می رسد حتی کودک دو ساله من که به مهد کودک می رود از برخی از سازمان هایی که با آنها کار کرده ام بالغ تر است.

فقط با استخدام تعداد زیادی از متخصصان نمی توانید یک شرکت کارآمد ایجاد کنید ، زیرا همه آنها جذب گروه یا گروهی می شوند. بنابراین مدیریت به استخدام متخصصان ادامه می دهد ، اما هیچ تغییری نمی کند زیرا ساختار و منطق گردش کار به هیچ وجه تغییر نمی کند.

اگر برای ایجاد کانال های ارتباطی در داخل و خارج از این گروه ها و ادارات کاری انجام ندهید ، تمام تلاش های شما بی معنی خواهد بود. به همین دلیل استراتژی ارتباطی و بلوغ مورد توجه آهوا است.

قانون کانوی برای شرکت های تجزیه و تحلیل اعمال شد

داده های معنی دار - قانون کانوی

پنجاه سال پیش ، یک برنامه نویس بزرگ به نام ملوین کانوی پیشنهادی را مطرح کرد که بعداً به عنوان قانون کانوی معروف شد: 

سازمانهایی که سیستمها را طراحی می کنند. . . برای تولید طرحهایی که کپی از ساختارهای ارتباطی این سازمانها باشد محدودیت دارند.

ملوین کانوی ، قانون کانوی

این افکار در زمانی ظاهر شدند که یک رایانه کاملاً در یک اتاق مناسب بود! فقط تصور کنید: در اینجا ما یک تیم داریم که روی یک رایانه کار می کنند و در آنجا تیم دیگری داریم که روی رایانه دیگری کار می کنند. و در زندگی واقعی ، قانون کانوی به این معنی است که تمام نقایص ارتباطی که در میان این تیم ها ظاهر می شود ، در ساختار و عملکرد برنامه های توسعه یافته آنها منعکس می شود. 

یادداشت نویسنده:

این نظریه صدها بار در جهان توسعه مورد آزمایش قرار گرفته و بسیار مورد بحث قرار گرفته است. مشخص ترین تعریف از قانون Conway توسط Pieter Hintjens ، یکی از تأثیرگذارترین برنامه نویسان در اوایل دهه 2000 ایجاد شد ، که گفت که "اگر در یک سازمان شلخته باشید ، نرم افزارهای شلخته ایجاد خواهید کرد." (آمدال به زیپف: ده قانون فیزیک افراد)

به راحتی می توانید ببینید که این قانون در دنیای بازاریابی و تجزیه و تحلیل چگونه کار می کند. در این دنیا ، شرکت ها با مقادیر عظیمی از داده های جمع آوری شده از منابع مختلف کار می کنند. همه ما می توانیم موافق باشیم که داده ها خود منصفانه هستند. اما اگر مجموعه داده ها را از نزدیک بررسی کنید ، تمام نقص های سازمان هایی را که این داده ها را جمع آوری کرده اند مشاهده خواهید کرد:

  • مقادیر از دست رفته در جایی که مهندسان در مورد موضوعی صحبت نکرده اند 
  • قالب های غلطی که هیچ کس به آنها توجه نکرده و هیچ کس در مورد تعداد رقم اعشار بحث نکرده است
  • تأخیر در مواقعی که هیچ کس قالب انتقال (دسته ای یا جریان) را نمی داند و چه کسی باید داده ها را دریافت کند

به همین دلیل سیستم های تبادل اطلاعات ، نقص های ما را کاملاً فاش می کنند.

کیفیت داده ها دستاورد متخصصان ابزار ، کارشناسان گردش کار ، مدیران و ارتباط بین همه این افراد است.

بهترین و بدترین ساختارهای ارتباطی برای تیم های چند رشته ای

یک تیم پروژه معمولی در یک شرکت تجزیه و تحلیل مارتک یا بازاریابی متشکل از متخصصان هوش تجاری (BI) ، دانشمندان داده ، طراحان ، بازاریاب ها ، تحلیلگران و برنامه نویسان (در هر ترکیبی) است.

اما در تیمی که اهمیت ارتباطات را درک نمی کند چه اتفاقی می افتد؟ اجازه بدید ببینم. برنامه نویسان برای مدت طولانی کد می نویسند ، تلاش زیادی می کنند ، در حالی که قسمت دیگری از تیم فقط منتظر می ماند تا باتوم را منتقل کنند. سرانجام ، نسخه بتا منتشر خواهد شد و همه در مورد اینکه چرا اینقدر طول کشید زمزمه می کنند. و هنگامی که اولین نقص ظاهر می شود ، همه شروع به جستجوی شخص دیگری می کنند تا سرزنش کند اما نه به دنبال راه هایی برای جلوگیری از وضعیتی که آنها را به آنجا رسانده است. 

اگر به عمق بیشتری نگاه کنیم ، خواهیم دید که اهداف متقابل به درستی درک نشده اند (یا اصلاً). و در چنین شرایطی ، یک محصول آسیب دیده یا معیوب دریافت خواهیم کرد. 

تیم های چند رشته ای را تشویق کنید

بدترین ویژگی های این وضعیت:

  • دخالت ناکافی
  • مشارکت ناکافی
  • عدم همکاری
  • عدم اعتماد

چگونه می توانیم آن را برطرف کنیم؟ به معنای واقعی کلمه با ایجاد مکالمه در مردم. 

تیم های چند رشته ای را تشویق کنید

بیایید همه را با هم جمع کنیم ، مباحث مربوطه را تعیین کنیم و جلسات هفتگی را برنامه ریزی کنیم: بازاریابی با BI ، برنامه نویسان با طراحان و متخصصان داده. سپس امیدواریم که مردم درباره پروژه صحبت کنند. اما این هنوز کافی نیست زیرا اعضای تیم هنوز در مورد کل پروژه صحبت نمی کنند و با کل تیم صحبت نمی کنند. آسان است که با دهها جلسه و بدون هیچ راهی برای بیرون آمدن و نداشتن وقت برای انجام کار زیر برف بروید. و این پیام ها بعد از جلسات باعث از بین رفتن بقیه وقت و درک اینکه چه کارهایی باید بعد انجام دهید. 

به همین دلیل ملاقات فقط اولین قدم است. ما هنوز هم برخی از مشکلات:

  • ارتباط ضعیف
  • عدم اهداف متقابل
  • دخالت ناکافی

بعضی اوقات ، افراد سعی می کنند اطلاعات مهم مربوط به پروژه را به همکاران خود منتقل کنند. اما به جای اینکه پیام از آن عبور کند ، دستگاه شایعه سازی همه کارها را برای آنها انجام می دهد. هنگامی که مردم نمی دانند چگونه افکار و ایده های خود را به درستی و در یک محیط مناسب به اشتراک بگذارند ، اطلاعات در مسیر دریافت کننده از دست می رود. 

اینها علائم یک شرکت است که با مشکلات ارتباطی دست و پنجه نرم می کند. و شروع به درمان آنها با جلسات می کند. اما ما همیشه راه حل دیگری داریم.

همه را به برقراری ارتباط درباره پروژه راهنمایی کنید. 

ارتباطات چند رشته ای در تیم ها

بهترین ویژگی های این روش:

  • شفافیت
  • درگیری
  • تبادل دانش و مهارت
  • آموزش بی وقفه

این یک ساختار بسیار پیچیده است که ایجاد آن دشوار است. ممکن است چند چارچوب را بدانید که این روش را در پیش می گیرند: Agile ، Lean ، Scrum. مهم نیست شما چه نامی بگذارید. همه آنها بر اساس اصل "ساختن همه چیز در یک زمان همزمان" ساخته شده اند. تمام آن تقویم ها ، صف کارها ، نمایش های نمایشی و جلسات استندآپ به این دلیل است که مردم به طور مکرر و همه با هم در مورد پروژه صحبت کنند.

به همین دلیل من Agile را بسیار دوست دارم ، زیرا این امر شامل اهمیت ارتباطات به عنوان پیش شرط بقای پروژه است.

و اگر فکر می کنید یک تحلیلگر هستید که Agile را دوست ندارد ، به روش دیگری به آن نگاه کنید: این به شما کمک می کند تا نتایج کار خود را نشان دهید - تمام داده های پردازش شده شما ، آن داشبورد عالی ، مجموعه داده های شما - برای ساختن مردم از زحمات شما قدردانی کنید اما برای انجام این کار ، شما باید با همکاران خود ملاقات کنید و در میزگرد با آنها صحبت کنید.

دیگه چیه؟ همه شروع به صحبت درباره پروژه کرده اند. حالا ما داریم برای اثبات کیفیت پروژه برای این کار ، شرکت ها معمولاً مشاور با بالاترین شرایط حرفه ای استخدام می کنند. 

معیار اصلی یک مشاور خوب (می توانم به شما بگویم چون من یک مشاور هستم) کاهش مداوم مشارکت وی در پروژه است.

یک مشاور نمی تواند فقط به اسرار کوچک حرفه ای یک شرکت تغذیه کند زیرا این امر باعث بالغ شدن و دوام شرکت نمی شود. اگر شرکت شما از قبل بدون مشاور شما نمی تواند زندگی کند ، باید کیفیت خدماتی را که دریافت کرده اید در نظر بگیرید. 

ضمناً ، یک مشاور نباید گزارش دهد یا یک جفت دست اضافی برای شما باشد. شما برای این کار همکاران داخلی خود را دارید.

بازاریاب ها را برای آموزش ، نه هیئت ، استخدام کنید

هدف اصلی استخدام مشاور ، آموزش ، اصلاح ساختارها و فرایندها و تسهیل ارتباطات است. نقش یک مشاور گزارشگری ماهانه نیست بلکه خود را در پروژه قرار می دهد و کاملاً در برنامه روزمره تیم نقش دارد.

خوب مشاور بازاریابی استراتژیک خلا gap موجود در دانش و درک شرکت کنندگان در پروژه را پر می کند. اما ممکن است او هرگز کار شخصی را انجام ندهد. و یک روز ، همه بدون مشورت باید به خوبی کار کنند. 

نتایج ارتباط موثر عدم وجود شکار جادوگر و اشاره انگشت است. قبل از شروع یک کار ، افراد تردیدها و س questionsالات خود را با سایر اعضای تیم در میان می گذارند. بنابراین ، بیشتر مشکلات قبل از شروع کار حل می شوند. 

بیایید ببینیم که چگونه همه آن بر پیچیده ترین قسمت کار تجزیه و تحلیل بازاریابی تأثیر می گذارد: تعریف جریان داده ها و ادغام داده ها.

ساختار ارتباطات در انتقال و پردازش داده ها چگونه منعکس شده است؟

بیایید فرض کنیم سه منبع داریم که داده های زیر را به ما ارائه می دهند: داده های ترافیک ، داده های محصول تجارت الکترونیکی / داده های خرید از برنامه وفاداری و داده های تجزیه و تحلیل تلفن همراه. ما مراحل پردازش داده ها را یک به یک طی می کنیم ، از پخش جریانی همه این داده ها به Google Cloud گرفته تا ارسال همه چیز برای تجسم در Google Data Studio با کمک Google BigQuery

براساس مثال ما ، مردم برای اطمینان از برقراری ارتباط روشن در هر مرحله از پردازش داده ها ، باید از چه س questionsالاتی بپرسند؟

  • مرحله جمع آوری داده ها. اگر فراموش کنیم که چیز مهمی را اندازه گیری کنیم ، نمی توانیم به گذشته برگردیم و دوباره آن را اندازه گیری کنیم. مواردی که باید قبلاً در نظر بگیرید:
    • اگر ما نمی دانیم مهمترین پارامترها و متغیرها را چه نام ببریم ، چگونه می توانیم با این همه خرابکاری کنار بیاییم؟
    • چگونه رویدادها پرچم گذاری می شوند؟
    • شناسه منحصر به فرد برای جریان داده انتخاب شده چیست؟
    • چگونه از امنیت و حریم شخصی مراقبت خواهیم کرد؟ 
    • در صورت محدودیت در جمع آوری داده ها ، چگونه داده ها را جمع آوری خواهیم کرد؟
  • ادغام داده ها به جریان جریان می یابد. موارد زیر را در نظر بگیرید:
    • اصول اصلی ETL: آیا انتقال دسته ای یا جریانی داده است؟ 
    • چگونه پیوند انتقال داده های جریانی و دسته ای را مشخص خواهیم کرد؟ 
    • چگونه آنها را در همان طرح داده بدون تلفات و اشتباهات تنظیم خواهیم کرد؟
    • سوالات زمان و تقویم: چگونه مهر زمان را بررسی می کنیم؟ 
    • چگونه می توان فهمید که نوسازی و غنی سازی داده ها به طور صحیح در مهر زمان کار می کند؟
    • چگونه بازدیدها را تأیید خواهیم کرد؟ چه اتفاقی می افتد با بازدیدهای نامعتبر؟

  • مرحله تجمیع داده ها. مواردی که باید در نظر گرفت:
    • تنظیمات تخصصی برای فرآیندهای ETL: ما با داده های نامعتبر چه کاری داریم؟
      وصله یا حذف شود؟ 
    • آیا می توانیم از آن سود بگیریم؟ 
    • چه تاثیری بر کیفیت کل مجموعه داده ها خواهد گذاشت؟

اولین اصل برای همه این مراحل این است که اشتباهات روی هم قرار می گیرند و از یکدیگر ارث می برند. داده های جمع آوری شده با یک نقص در مرحله اول باعث می شود که سر شما در تمام مراحل بعدی کمی بسوزد. و اصل دوم این است که شما باید نقاطی را برای تضمین کیفیت داده انتخاب کنید. زیرا در مرحله تجمیع ، تمام داده ها با هم مخلوط می شوند و شما نمی توانید بر کیفیت داده های مخلوط تأثیر بگذارید. این برای پروژه های یادگیری ماشین ، جایی که کیفیت داده ها بر کیفیت نتایج یادگیری ماشین تأثیر می گذارد ، واقعاً مهم است. نتایج خوب با داده های بی کیفیت غیرقابل دستیابی است.

  • تجسم
    این مرحله مدیرعامل است. شما ممکن است در مورد این وضعیت چیزی شنیده باشید که مدیر عامل شرکت به اعداد داشبورد نگاه می کند و می گوید: "خوب ، ما امسال سود زیادی کسب کرده ایم ، حتی بیشتر از گذشته ، اما چرا همه پارامترهای مالی در منطقه قرمز است ؟ " و در این لحظه ، خیلی دیر است که به دنبال اشتباهات بروید ، زیرا مدتها پیش باید آنها را می گرفتید.

همه چیز مبتنی بر ارتباط است. و در موضوعات گفتگو. در اینجا مثالی از مواردی که باید هنگام تهیه جریان Yandex مورد بحث قرار گیرد وجود دارد:

بازاریابی BI: Snowplow ، Google Analytics ، Yandex

پاسخ اکثر این سالات را فقط با تمام تیم خود خواهید یافت. زیرا وقتی کسی بر اساس حدس یا نظر شخصی خود تصمیم گیری کند بدون اینکه ایده را با دیگران آزمایش کند ، ممکن است اشتباهاتی ظاهر شود.

پیچیدگی ها همه جا هستند ، حتی در ساده ترین مکان ها.

در اینجا یک مثال دیگر وجود دارد: هنگام ردیابی امتیازات کارت های محصول ، یک تحلیلگر خطایی را مشاهده می کند. در داده های بازدید ، همه برداشت ها از همه آگهی ها و کارت های محصول بلافاصله پس از بارگیری صفحه ارسال می شود. اما نمی توان مطمئن بود که آیا کاربر واقعاً به همه موارد موجود در صفحه نگاه کرده است. تحلیلگر به تیم می آید تا آنها را در این مورد با جزئیات آگاه کند.

BI می گوید ما نمی توانیم اوضاع را به این ترتیب رها کنیم.

اگر حتی نمی توانیم از نمایش محصول مطمئن شویم چگونه می توان CPM را محاسبه کرد؟ پس CTR واجد شرایط برای تصاویر چیست؟

بازاریابان پاسخ می دهند:

ببینید ، همه ، ما می توانیم گزارشی ایجاد کنیم که بهترین CTR را نشان دهد و آن را در برابر یک بنر یا عکس مشابه خلاقانه در مکان های دیگر تأیید کنیم.

و سپس توسعه دهندگان می گویند:

بله ، ما می توانیم این مشکل را با کمک یکپارچه سازی جدید خود برای ردیابی پیمایش و بررسی موضوع مشاهده کنیم.

سرانجام ، طراحان UI / UX می گویند:

آره ما می توانیم انتخاب کنیم که بالاخره به طومار تنبل یا ابدی احتیاج داریم!

مراحلی که این تیم کوچک طی کرده است:

  1. مشکل را مشخص کرد
  2. پیامدهای تجاری این مشکل را ارائه داد
  3. تأثیر تغییرات را اندازه گیری کرد
  4. تصمیمات فنی ارائه شده
  5. سود غیر پیش پا افتاده را کشف کرد

برای حل این مشکل ، آنها باید جمع آوری داده ها را از همه سیستم ها بررسی کنند. یک راه حل جزئی در یک بخش از طرح داده ، مشکلی را برای تجارت حل نمی کند.

تنظیم تنظیم طرح

به همین دلیل است که ما باید با هم کار کنیم. داده ها باید هر روز با مسئولیت پذیری جمع آوری شوند و انجام این کار کار سختی است. و کیفیت داده ها باید توسط استخدام افراد مناسب ، خرید ابزارهای مناسب و سرمایه گذاری پول ، وقت و تلاش برای ایجاد ساختارهای ارتباطی موثر ، که برای موفقیت سازمان ضروری است.

شما چه فکر میکنید؟

این سایت از Akismet برای کاهش هرزنامه استفاده می کند. بدانید که چگونه نظر شما پردازش می شود.