מדוע תקשורת צוותית חשובה יותר מסטאק מארטך שלך

תקשורת וניתוח צוות שיווק

נקודת המבט הלא טיפוסית של סימו אהבה על איכות הנתונים ומבני התקשורת ריעננה את כל הטרקלין במלון עבור אל אנליטיקס! וְעִידָה. OWOX, מנהיג MarTech באזור חבר העמים, בירך אל אלפי מומחים לכינוס זה כדי לחלוק את הידע והרעיונות שלהם.

צוות OWOX BI הייתי רוצה שתחשבו על הרעיון שהציע סימו אהבה, שבהחלט יש פוטנציאל לגרום לעסק שלכם לצמוח. 

איכות הנתונים ואיכות הארגון

איכות הנתונים תלויה באדם שמנתח אותם. בדרך כלל, אנו מאשימים את כל הפגמים בנתונים בכלים, תהליכי עבודה ומערכי נתונים. אך האם זה סביר?

בכנות, איכות הנתונים קשורה ישירות לאופן שבו אנו מתקשרים בארגונים שלנו. איכות הארגון קובעת הכל, החל מהגישה לכריית נתונים, אומדן ומדידה, המשך עיבוד וכלה באיכות הכוללת של המוצר וקבלת ההחלטות. 

חברות ומבני התקשורת שלהן

בואו נדמיין שחברה מתמחה בכלי אחד. האנשים בחברה זו מצליחים למצוא בעיות מסוימות ולפתור אותן למגזר B2B. הכל נהדר, ואין ספק שאתה מכיר חברות זוגיות כאלה.

תופעות הלוואי של פעילות חברות אלה מסתתרות בתהליך ארוך הטווח של העלאת הדרישות לאיכות הנתונים. יחד עם זאת, עלינו לזכור כי כלים שנוצרו לניתוח נתונים עובדים עם נתונים בלבד ומבודדים מהבעיות העסקיות - גם אם הם נוצרו כדי לפתור אותם. 

לכן הופיע סוג אחר של משרד. חברות אלו מתמחות באגים בתהליך העבודה. הם יכולים למצוא חבורה שלמה של בעיות בתהליכים עסקיים, להעלות אותם על לוח לבן ולומר למנהלים:

הנה, פה ושם! החל את האסטרטגיה העסקית החדשה הזו ותהיה בסדר!

אבל זה נשמע טוב מכדי להיות אמיתי. יעילות הייעוץ שאינה מבוססת על הבנת הכלים מוטלת בספק. חברות הייעוץ הללו נוטות לא להבין מדוע הופיעו בעיות כאלה, מדוע כל יום חדש מביא מורכבויות ושגיאות חדשות ואילו כלים הוקמו באופן שגוי.

אז התועלת של חברות אלה בפני עצמן מוגבלת. 

ישנן חברות בעלות מומחיות עסקית וידע בכלים. בחברות אלה כולם אובססיביים לשכור אנשים בעלי איכויות נהדרות, מומחים בטוחים בכישוריהם ובידע שלהם. מגניב. אך בדרך כלל, חברות אלה אינן מכוונות לפתרון בעיות תקשורת בצוות, שלעיתים קרובות הן רואות כלא חשובות. אז כשמופיעות בעיות חדשות, ציד המכשפות מתחיל - של מי אשמתו? אולי מומחי ה- BI התבלבלו בין התהליכים? לא, המתכנתים לא קראו את התיאור הטכני. אבל בסך הכל, הבעיה האמיתית היא שהצוות לא יכול לחשוב על הבעיה בצורה ברורה כדי לפתור אותה יחד. 

זה מראה לנו שאפילו בחברה ממולאת במומחים מגניבים, הכל יידרש יותר מהנדרש אם הארגון לא יהיה בוגר מספיק. הרעיון שאתה צריך להיות מבוגר ולהיות אחראי, במיוחד במשבר, הוא הדבר האחרון שאנשים חושבים עליו ברוב החברות.

אפילו הילד שלי בן השנתיים שהולך לגן נראה בוגר יותר מכמה מהארגונים שעבדתי איתם.

אינך יכול ליצור חברה יעילה רק על ידי שכירת מספר רב של מומחים, מכיוון שכולם נקלטים על ידי קבוצה או מחלקה כלשהי. אז ההנהלה ממשיכה להעסיק מומחים, אך שום דבר לא משתנה מכיוון שמבנה הלוגיקה של זרימת העבודה כלל אינם משתנים.

אם לא תעשה דבר ליצירת ערוצי תקשורת בתוך ומחוץ לקבוצות ומחלקות אלה, כל המאמצים שלך יהיו חסרי משמעות. זו הסיבה שאסטרטגיית תקשורת ובגרות היא המוקד של אהבה.

החוק של קונווי חל על חברות אנליטיקה

נתונים משמעותיים - חוק קונוויי

לפני חמישים שנה, מתכנת גדול בשם מלווין קונווי העלה הצעה שלימים נודע בכינויו חוק קונווי: 

ארגונים אשר מתכננים מערכות. . . מאולצים לייצר עיצובים שהם העתקים של מבני התקשורת של ארגונים אלה.

מלווין קונווי, חוק קונוויי

מחשבות אלו הופיעו בתקופה שמחשב אחד התאים לחדר אחד בצורה מושלמת! רק דמיין: כאן יש לנו צוות אחד שעובד על מחשב אחד, ושם יש לנו צוות אחר שעובד על מחשב אחר. ובחיים האמיתיים, החוק של קונווי אומר שכל פגמי התקשורת המופיעים בקרב אותם צוותים יבואו לידי ביטוי במבנה ובפונקציונליות של התוכניות שהם מפתחים. 

הערה:

תיאוריה זו נבדקה מאות פעמים בעולם הפיתוח ונדונה רבות. ההגדרה הוודאית ביותר לחוק קונווי נוצרה על ידי פיטר הינטג'נס, אחד המתכנתים המשפיעים ביותר בתחילת שנות האלפיים, שאמר כי "אם אתה בארגון מחורבן, אתה תיצור תוכנה מחורבנת." (Amdahl to Zipf: עשרה חוקי פיסיקה של אנשים)

קל לראות כיצד חוק זה עובד בעולם השיווק והניתוח. בעולם זה חברות עובדות עם כמויות ענק של נתונים שנאספו ממקורות שונים. כולנו יכולים להסכים שהנתונים עצמם הוגנים. אבל אם תבדוק ערכות נתונים מקרוב, תראה את כל הפגמים של הארגונים שאספו את הנתונים האלה:

  • חסרים ערכים שבהם המהנדסים לא דיברו על נושא 
  • פורמטים שגויים שבהם איש לא שם לב ואף אחד לא דן במספר המקומות העשרוניים
  • עיכובים בתקשורת כאשר איש אינו יודע את פורמט ההעברה (אצווה או זרם) ומי חייב לקבל את הנתונים

לכן מערכות חילופי נתונים חושפות את פגמינו לחלוטין.

איכות הנתונים היא הישג של מומחי כלים, מומחים לזרימת עבודה, מנהלים ותקשורת בין כל האנשים האלה.

מבני התקשורת הטובים והגרועים ביותר עבור צוותים רב תחומיים

צוות פרוייקטים טיפוסי בחברת MarTech או ניתוח שיווק מורכב ממומחי בינה עסקית (BI), מדעני נתונים, מעצבים, משווקים, אנליסטים ומתכנתים (בכל צירוף שהוא).

אבל מה יקרה בצוות שלא מבין את חשיבות התקשורת? בוא נראה. המתכנתים יכתבו קוד זמן רב, תוך ניסיון קשה, בעוד חלק אחר בצוות רק יחכה להם שיעבירו את השרביט. סוף סוף גרסת הבטא תשוחרר, וכולם יתלבטו מדוע זה לקח כל כך הרבה זמן. וכשמופיע הפגם הראשון, כולם יתחילו לחפש מישהו אחר שאשם אך לא דרכים להימנע מהמצב שהביא אותם לשם. 

אם נתבונן עמוק יותר, נראה כי מטרות הדדיות לא הובנו נכון (או בכלל). ובמצב כזה נקבל מוצר פגום או פגום. 

עודד צוותים רב תחומיים

המאפיינים הגרועים ביותר של מצב זה:

  • מעורבות לא מספקת
  • השתתפות לא מספקת
  • חוסר שיתוף פעולה
  • חוסר אמון

איך נוכל לתקן את זה? פשוטו כמשמעו על ידי לגרום לאנשים לדבר. 

עודד צוותים רב תחומיים

בואו לאסוף את כולם יחד, לקבוע נושאי דיון ולקבוע פגישות שבועיות: שיווק עם BI, מתכנתים עם מעצבים ומומחי נתונים. אז נקווה שאנשים ידברו על הפרויקט. אבל זה עדיין לא מספיק מכיוון שחברי הצוות עדיין לא מדברים על כל הפרויקט ולא מדברים עם כל הצוות. קל להגיע לשלג עם עשרות פגישות וללא מוצא וללא זמן לעשות את העבודה. והודעות אלה לאחר פגישות יהרגו את שאר הזמן ואת ההבנה מה לעשות הלאה. 

לכן הפגישה היא רק הצעד הראשון. עדיין יש לנו כמה בעיות:

  • תקשורת גרועה
  • היעדר מטרות הדדיות
  • מעורבות לא מספקת

לפעמים אנשים מנסים להעביר מידע חשוב על הפרויקט לעמיתיהם. אבל במקום שהמסר יעבור, מכונת השמועות עושה הכל בשבילם. כשאנשים לא יודעים לשתף את מחשבותיהם ורעיונותיהם כראוי ובסביבה הנכונה, המידע יאבד בדרך למקבל. 

אלה סימפטומים של חברה הנאבקת בבעיות תקשורת. וזה מתחיל לרפא אותם בפגישות. אבל תמיד יש לנו פיתרון אחר.

הובילו את כולם לתקשר על הפרויקט. 

תקשורת רב תחומית בצוותים

התכונות הטובות ביותר בגישה זו:

  • שקיפות
  • מעורבות
  • החלפת ידע ומיומנויות
  • חינוך ללא הפסקה

זהו מבנה מורכב ביותר שקשה ליצור. יתכן שאתה מכיר כמה מסגרות הנוקטות גישה זו: Agile, Lean, Scrum. לא משנה איך קוראים לזה; כולם בנויים על עיקרון "הכנת הכל יחד". כל אותם לוחות שנה, תורי משימות, מצגות הדגמה ופגישות סטנד-אפ נועדו לגרום לאנשים לדבר על הפרויקט לעתים קרובות וכולם יחד.

זו הסיבה שאני מאוד אוהב את Agile, כי זה כולל את חשיבות התקשורת כתנאי הכרחי להישרדות בפרויקט.

ואם אתה חושב שאתה אנליסט שלא אוהב את Agile, תסתכל על זה אחרת: זה עוזר לך להציג את תוצאות העבודה שלך - כל הנתונים המעובדים שלך, לוחות המחוונים הנהדרים האלה, מערכי הנתונים שלך - כדי לגרום לאנשים מעריך את המאמצים שלך. אבל לשם כך, עליך לפגוש את עמיתייך ולדבר איתם בשולחן העגול.

מה הלאה? כולם התחילו לדבר על הפרויקט. עכשיו יש לנו כדי להוכיח את האיכות של הפרויקט. לשם כך חברות בדרך כלל מעסיקות יועץ בעל הכישורים המקצועיים הגבוהים ביותר. 

הקריטריון העיקרי של יועץ טוב (אני יכול לומר לך כי אני יועץ) הוא הפחתה מתמדת במעורבותו בפרויקט.

יועץ לא יכול פשוט להאכיל חברה בסודות מקצועיים קטנים מכיוון שהדבר לא יהפוך את החברה לבוגרת ותומכת בעצמה. אם החברה שלך לא יכולה לחיות כבר בלי היועץ שלך, עליך לשקול את טיב השירות שקיבלת. 

אגב, יועץ לא צריך להכין דוחות או להפוך לזוג ידיים נוסף עבורך. יש לך את הקולגות הפנימיים שלך בשביל זה.

לשכור משווקים להשכלה, לא למשלחת

המטרה העיקרית של העסקת יועץ היא חינוך, תיקון מבנים ותהליכים והקלה על תקשורת. תפקידו של היועץ אינו דיווח חודשי אלא השתלת עצמו בפרויקט והשתתפות מוחלטת בשגרת היומיום של הצוות.

טוב יועץ שיווקי אסטרטגי ממלא פערים בידע ובהבנה של משתתפי הפרויקט. אבל הוא או היא לעולם לא יעשו את העבודה בשביל מישהו. ויום אחד, כולם יצטרכו לעבוד בסדר גמור בלי היועץ. 

התוצאות של תקשורת יעילה הן היעדר ציד מכשפות והצבעה באצבעות. לפני תחילת משימה, אנשים משתפים את ספקותיהם ושאלותיהם עם חברי צוות אחרים. לפיכך, רוב הבעיות נפתרות לפני תחילת העבודה. 

בואו נראה כיצד כל זה משפיע על החלק המסובך ביותר בעבודת ניתוח השיווק: הגדרת זרימת נתונים ומיזוג נתונים.

כיצד משתקף מבנה התקשורת בהעברת ועיבוד נתונים?

נניח שיש לנו שלושה מקורות המספקים לנו את הנתונים הבאים: נתוני תנועה, נתוני מוצר מסחר אלקטרוני / נתוני רכישה מתוכנית הנאמנות ונתוני ניתוח סלולרי. נעבור את שלבי עיבוד הנתונים בזה אחר זה, החל מהזרמת כל הנתונים האלה ל- Google Cloud ועד לשלוח הכל להדמיה Google Data Studio בעזרת BigQuery של גוגל

על סמך הדוגמה שלנו, אילו שאלות אנשים צריכים לשאול כדי להבטיח תקשורת ברורה בכל שלב של עיבוד הנתונים?

  • שלב איסוף הנתונים. אם אנו שוכחים למדוד משהו חשוב, איננו יכולים לחזור אחורה ולמדוד אותו מחדש. דברים שכדאי לקחת בחשבון מראש:
    • אם איננו יודעים כיצד למנות את הפרמטרים והמשתנים החשובים ביותר, כיצד נוכל להתמודד עם כל הבלגן?
    • כיצד יסומנו אירועים?
    • מה יהיה המזהה הייחודי לזרימות הנתונים שנבחרו?
    • איך נדאג לביטחון ולפרטיות? 
    • כיצד נאסוף נתונים במקום בו יש מגבלות על איסוף הנתונים?
  • מיזוג נתונים זורם לזרם. שקול את הדברים הבאים:
    • עקרונות ה- ETL העיקריים: האם זה סוג אצווה או זרם של העברת נתונים? 
    • כיצד נסמן את הצירוף של העברת נתוני זרם ואצווה? 
    • כיצד נתאים אותם באותה סכמת נתונים ללא הפסדים וטעויות?
    • שאלות בזמן וכרונולוגיה: כיצד נבדוק את חותמות הזמן? 
    • כיצד נוכל לדעת אם שיפוץ והעשרת נתונים פועלים כראוי בתוך חותמות הזמן?
    • איך נאמת להיטים? מה קורה עם להיטים לא תקפים?

  • שלב צבירת נתונים. דברים שיש לקחת בחשבון:
    • הגדרות מיוחדות לתהליכי ETL: מה יש לנו לעשות עם נתונים לא חוקיים?
      לתקן או למחוק? 
    • האם נוכל להשיג רווח מכך? 
    • כיצד זה ישפיע על איכות מערך הנתונים כולו?

העיקרון הראשון לכל השלבים הללו הוא שהטעויות נערמות זו על זו וירושתן זו מזו. נתונים שנאספו עם פגם בשלב הראשון יגרמו לראש לשרוף מעט במהלך כל השלבים הבאים. והעיקרון השני הוא שעליך לבחור נקודות להבטחת איכות הנתונים. מכיוון שבשלב הצבירה כל הנתונים יתערבבו יחד, ולא תוכלו להשפיע על איכות הנתונים המעורבים. זה חשוב באמת עבור פרויקטים של למידת מכונה, כאשר איכות הנתונים תשפיע על איכות תוצאות הלמידה המכונה. לא ניתן להשיג תוצאות טובות עם נתונים באיכות נמוכה.

  • ראיה
    זה שלב המנכ"ל. אולי שמעת על המצב כאשר המנכ"ל מסתכל על המספרים בלוח המחוונים ואומר: "בסדר, יש לנו הרבה רווח השנה, אפילו יותר מבעבר, אבל למה כל הפרמטרים הכספיים נמצאים באזור האדום ? ” וברגע זה, מאוחר מדי לחפש את הטעויות, כפי שהן היו צריכות להיתפס מזמן.

הכל מבוסס על תקשורת. ועל נושאי השיחה. הנה דוגמה למה שצריך לדון בזמן הכנת הזרמת Yandex:

BI שיווק: Snowplow, Google Analytics, Yandex

תוכלו למצוא את התשובות לרוב השאלות הללו רק יחד עם כל הצוות שלכם. מכיוון שכאשר מישהו מקבל החלטה על פי ניחוש או דעה אישית מבלי לבדוק את הרעיון עם אחרים, עלולות להופיע טעויות.

המורכבות נמצאת בכל מקום, אפילו במקומות הפשוטים ביותר.

הנה דוגמה נוספת: בעת מעקב אחר ציוני ההופעות של כרטיסי המוצר, אנליסט מבחין בשגיאה. בנתוני ההיט, כל ההופעות מכל הבאנרים וכרטיסי המוצרים נשלחו מיד לאחר טעינת הדף. אך איננו יכולים להיות בטוחים אם המשתמש באמת הסתכל על הכל בדף. האנליטיקאי מגיע לצוות כדי להודיע ​​להם על כך בפירוט.

ה- BI אומר שאנחנו לא יכולים להשאיר את המצב ככה.

כיצד נוכל לחשב את העלות לאלף הופעות אם איננו יכולים אפילו להיות בטוחים אם המוצר הוצג? מהו שיעור הקליקים המוסמך לתמונות?

המשווקים עונים:

תראה, כולם, אנחנו יכולים ליצור דוח המציג את שיעור הקליקים הטוב ביותר ולוודא אותו מול באנר או תמונה יצירתית דומה במקומות אחרים.

ואז המפתחים יגידו:

כן, אנו יכולים לפתור בעיה זו בעזרת השילוב החדש שלנו למעקב אחר גלילה ובדיקת נראות הנושא.

לבסוף, מעצבי UI / UX אומרים:

כֵּן! אנחנו יכולים לבחור אם סוף סוף אנחנו צריכים את המגילה העצלה או הנצחית או עימוד!

להלן השלבים שעבר הצוות הקטן:

  1. הגדיר את הבעיה
  2. הציג את ההשלכות העסקיות של הבעיה
  3. מדד את השפעת השינויים
  4. הוצגו החלטות טכניות
  5. גילה את הרווח הלא טריוויאלי

כדי לפתור בעיה זו, עליהם לבדוק את איסוף הנתונים מכל המערכות. פתרון חלקי בחלק אחד מסכמת הנתונים לא יפתור את הבעיה העסקית.

יישר עיצוב עיצוב

לכן עלינו לעבוד יחד. יש לאסוף את הנתונים באופן אחראי בכל יום, וזו עבודה קשה לעשות זאת. וה איכות הנתונים חייבת להיות מושגת על ידי העסקת האנשים הנכונים, קניית הכלים הנכונים והשקעת כסף, זמן ומאמץ בבניית מבני תקשורת יעילים, החיוניים להצלחת הארגון.

מה אתה חושב?

אתר זה משתמש Akismet כדי להפחית דואר זבל. למד כיצד הנתונים שלך מעובדים.