למה הדאשבורד שבניתם מת אחרי חודש (ואיך מונעים את זה)
יש רגע מאוד ספציפי שאני מזהה בשיחות אפיון, ובדרך כלל הוא מגיע עם משפט שנאמר בחצי מבוכה: "בנינו דאשבורד לפני כמה חודשים, ו... האמת שכבר לא ממש מסתכלים עליו." לפעמים זה דאשבורד שהם בנו לבד ב-Google Sheets עם המון עמל, לפעמים זה משהו שספק חיצוני הרכיב להם ב-Power BI או ב-Looker. משותף לכולם הדבר הזה: בהשקה כולם היו בהתלהבות, המסך היה יפה, המספרים היו שם – ואחרי חודש הוא הפך לעוד טאב פתוח שאף אחד כבר לא לוחץ עליו.
מה שמעניין הוא שכמעט אף פעם הדאשבורד לא "מת" בגלל הדאשבורד עצמו. הגרפים בסדר גמור, הצבעים יפים, הכלי עובד. הוא מת בגלל השכבה שמתחתיו – מאיפה הנתונים מגיעים, מי אחראי עליהם, ומה בעצם מישהו אמור לעשות איתם. אחרי מספיק פעמים שראיתי את הדפוס הזה חוזר, זיקקתי אותו לארבע סיבות שחוזרות כמעט תמיד. אם בניתם דאשבורד שכבר לא נפתח, סביר מאוד שלפחות שתיים מהן מדברות אליכם ישירות.
קודם כל: הבעיה כמעט אף פעם לא בוויזואליזציה
זו הנקודה שהכי חשוב לי להתחיל ממנה, כי היא משנה את כל האבחון. כשדאשבורד ננטש, האינסטינקט הראשון הוא להאשים את התצוגה: "הגרף לא ברור", "חסר לי פילטר", "בוא נעבור מ-Sheets למשהו יותר רציני". אז מחליפים כלי, משקיעים עוד כסף, ושלושה חודשים אחר כך הדאשבורד החדש והמבריק מת בדיוק כמו הישן.
מהניסיון שלי, ברוב המוחלט של המקרים השורש נמצא שכבה אחת למטה – במקום שממנו הנתונים מגיעים ובאופן שבו הם (לא) מתחזקים. דאשבורד הוא בסך הכול חלון ראווה. אם מה שמאחורי הזכוכית מבולגן, לא מעודכן או לא מוסכם, שום עיצוב של החלון לא יציל את זה. ארבע הסיבות שלמטה כולן, בסוף, מצביעות לאותו כיוון.
סיבה 1: הנתונים לא מתעדכנים, אז הדאשבורד "משקר" בשקט
זו הסיבה הכי נפוצה, וגם הכי מסוכנת, כי היא לא מכריזה על עצמה. דאשבורד שקורס בגלוי – מציג שגיאה, לא נטען – לפחות מאותת שיש בעיה. אבל דאשבורד שממשיך להראות מספרים יפים שהם פשוט לא נכונים כבר יותר? הוא הרבה יותר מזיק, כי הוא נראה בדיוק כמו דאשבורד תקין.
זה קורה כשהחיבור בין מקורות הנתונים לתצוגה הוא ידני או חצי-ידני. מישהו מייצא קובץ מה-CRM פעם בשבוע ומדביק אותו בגיליון, או שיש איזו אוטומציה ששברה לפני חודש ואף אחד לא שם לב. בהתחלה המספרים טריים, אז יש אמון. ואז מגיע היום שבו בעל העסק פותח את הדאשבורד, רואה "12 עסקאות פתוחות", והוא יודע בעצמו שיש לפחות 20. ברגע הזה נגמר הסיפור. אמון בדאשבורד הוא בינארי: מהרגע שתפסתם אותו טועה פעם אחת, אתם חוזרים לפתוח את המערכות המקוריות "רק כדי לוודא" – ואם ממילא פותחים אותן, בשביל מה הדאשבורד?
הפתרון הוא לא "לרענן ידנית יותר בתדירות". הפתרון הוא שהדאשבורד יישאב ישירות ממקורות האמת, בלי תחנת ביניים אנושית שאפשר לשכוח לעדכן. אם עדיין לא הגעתם לשם, עדיף דאשבורד עם שלושה מספרים שמתעדכנים אוטומטית מאשר עשרים מספרים שתלויים בזה שמישהו יזכור לייצא קובץ ביום ראשון בבוקר.
סיבה 2: אין בעלים למדדים, אז אף אחד לא מרגיש אחראי כשמשהו נשבר
זו סיבה שראיתי מפילה גם דאשבורדים שנבנו מצוין טכנית. בהשקה כולם מסתכלים, כי זה חדש ומרגש. ואז ההתלהבות דועכת, החיים ממשיכים, ואין אף אדם אחד שהתפקיד המפורש שלו הוא להסתכל על הדאשבורד הזה ולהחזיק אותו. כשמדד מתחיל להיראות מוזר, כולם מניחים שמישהו אחר יבדוק. כשמקור נתונים משתנה, אף אחד לא מרגיש שזה באחריותו לתקן את החיבור.
זה בדיוק אותו דפוס של "בעל בית אחרי ההשקה" שכתבתי עליו בהקשר של פרויקטי AI ב-למה רוב פרויקטי ה-AI נכשלים – רק שבדאשבורדים זה מחריף, כי דאשבורד הוא כלי פסיבי. הוא לא שולח מייל ולא מתריע כשמשהו מתקלקל. הוא פשוט יושב שם ומציג נתון ישן בשקט מוחלט. בלי אדם שאחראי עליו, אין לו שום מנגנון שמחזיר אותו לחיים.
הפתרון פשוט להגדרה וקשה ליישום: לכל דאשבורד צריך להיות בעלים אחד, ולכל מדד מרכזי בתוכו כדאי שיהיה בעלים – מישהו שהמספר הזה "שלו", שהוא מסתכל עליו באופן קבוע ושיֵדע להגיד אם הוא נראה הגיוני. דאשבורד בלי בעלים הוא לא כלי ניהול, הוא קישוט.
סיבה 3: יותר מדי מטריקות שלא מחוברות לאף החלטה
יש פיתוי גדול, במיוחד כשבונים דאשבורד בפעם הראשונה, למלא אותו בכל מה שאפשר למדוד. אחרי הכול, אם המידע קיים – למה לא להראות אותו? אז מוסיפים עוד גרף ועוד מונה ועוד פילוח, וכל אחד מהם "נחמד לראות". התוצאה היא מסך צפוף שבמבט ראשון נראה מרשים, ובמבט חמישי כבר גורם לך לא לרצות להסתכל בכלל.
הבעיה העמוקה כאן היא לא עומס ויזואלי. היא שכמעט אף אחת מהמטריקות לא מחוברת להחלטה אמיתית. דאשבורד עסקי טוב אמור לענות על שאלה מהצורה "מה אני עושה אחרת מחר בבוקר בגלל המספר הזה?". אם התשובה למדד מסוים היא "כלום, סתם מעניין לדעת" – הוא לא שייך לדאשבורד, הוא שייך לדוח רבעוני. הרחבתי על ההיגיון הזה במאמר על מתי העסק שלכם באמת צריך דאשבורד: המבחן הוא לא "האם אפשר למדוד את זה" אלא "האם המספר הזה מזיז החלטה חוזרת".
דאשבורד עם שלושה מספרים שכל אחד מהם מוביל לפעולה שווה יותר מדאשבורד עם עשרים מספרים שכולם רק "לידיעה". וכשיש בו עשרים מספרים, גם השלושה החשובים באמת נבלעים ברעש – אז בפועל מפסיקים לראות גם אותם.
סיבה 4: מקור הנתונים לא אמין או לא מסונכרן מלכתחילה
וכאן אנחנו מגיעים לשורש שמתחת לכל השורשים. אפשר לבנות דאשבורד מושלם, עם חיבורים אוטומטיים, בעלים ברור וארבעה מדדים ממוקדים – ובכל זאת הוא ייכשל, אם הנתונים שהוא נשען עליהם מגיעים ממערכות שלא מסכימות ביניהן. אם אותו לקוח קיים בשלוש גרסאות שונות ב-CRM, בוואטסאפ ובמערכת החשבוניות, הדאשבורד לא באמת יודע כמה לקוחות יש לכם – הוא מנחש, על סמך המקור שבמקרה חיברתם אליו.
זה בדיוק המצב שבו הבעיה כבר לא "חסר לנו דאשבורד" אלא "אין לנו מקור אמת אחד". תיארתי את הסימנים לכך בהרחבה במאמר על מקור אמת אחד ואינטגרציית CRM, והם רלוונטיים כאן ישירות: כשאין רשומה אחת מוסמכת שאומרת מה נכון, כל דאשבורד שיושב מעל זה פשוט בוחר לו גרסה אחת מבין כמה סותרות ומציג אותה בביטחון. הוא לא פותר את חוסר הסנכרון, הוא רק מסתיר אותו מאחורי גרף.
זה גם אותו עיקרון שכתבתי עליו בעולם האוטומציה ב-למה אוטומציה נכשלת: מערכת שמונחת מעל נתונים מבולגנים לא מסדרת אותם, היא רק מזרימה את הבלגן מהר יותר ובצורה משכנעת יותר. בדאשבורד זה מקבל ניואנס מסוכן במיוחד – כי בניגוד לאקסל ידני שאתם יודעים שהוא "בערך", הדאשבורד הצבעוני משדר סמכות. אתם נוטים להאמין למספר על המסך יותר משהייתם מאמינים לאותו מספר בגיליון. וכשהמספר שגוי, הביטחון השגוי הזה הוא בדיוק מה שהופך אותו למסוכן.
אז איך בונים דאשבורד ששורד יותר מחודש
אחרי כל מה שתיארתי, המסקנה המעשית די ברורה – והיא כמעט כולה מתרחשת מתחת לדאשבורד, לא בו:
- קודם מקור אמת, אחר כך תצוגה. לפני שאתם בכלל בוחרים כלי, ודאו שיש הסכמה במערכות על מה נכון. אם אין – זו המשימה הראשונה, והדאשבורד מחכה.
- חברו אוטומטית, לא ידנית. כל תחנת ביניים אנושית בשאיבת הנתונים היא מקום שבו הדאשבורד ימות בשקט. עדיף פחות מדדים אוטומטיים מאשר יותר מדדים שתלויים בזיכרון של מישהו.
- תנו בעלים לכל מדד. מישהו אחד שהמספר "שלו" ושיֵדע להגיד אם הוא נראה הגיוני. בלי זה, אף אחד לא יתפוס את הרגע שבו הדאשבורד התחיל לשקר.
- ארבעה מספרים, לא עשרים. לכל מדד שאתם שוקלים להוסיף, שאלו: "מה אני עושה אחרת בגללו?". אם אין תשובה – הוא דוח, לא דאשבורד.
סיכום
הדאשבורדים שראיתי מתים לא מתו כי מישהו בחר את הכלי הלא נכון או ציִיר גרף מכוער. הם מתו כי הנתונים הפסיקו להתעדכן ואף אחד לא שם לב, כי אף אחד לא היה אחראי עליהם, כי הם היו עמוסים במדדים שלא הובילו לשום פעולה, או – הכי נפוץ – כי הם נבנו מעל מקורות נתונים שמעולם לא הסכימו ביניהם מלכתחילה. בכל ארבעת המקרים, הבעיה הייתה בשכבה שמתחת לגרף, לא בגרף.
זו בדיוק הסיבה שאני מעדיפה, כמעט תמיד, לדבר על מקור האמת והחיבורים לפני שמתחילים לבנות תצוגה. דאשבורד הוא הגג. הוא יפהפה ושימושי – אבל רק כשמישהו קודם דאג ליסודות.
בניתם דאשבורד שכבר לא נפתח, ולא בטוחים אם הבעיה בכלי או במה שמתחתיו? בואו נסתכל יחד על השכבה שמתחת – מאיפה הנתונים מגיעים ומה באמת שבור – לפני שבונים עוד תצוגה שתמות בעוד חודש.
רוצים ליישם את זה אצלכם?
אני עוזרת לעסקים לבנות ארכיטקטורת אוטומציה חכמה. בואו נבדוק איך הכלים האלו יכולים לעבוד בשבילכם.
בואו נדבר על זה