לפני שבונים דשבורד: איזו החלטה הוא אמור לשנות?

מני ברגר

Data Scientist

4 דק׳ קריאה

בכתבה זו

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

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

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

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

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

למה זה קורה שוב ושוב? כי התאהבנו בפתרון לפני שהבנו את הבעיה.

 

המלכודת: כשכולם שיכורים מדאטה

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

היה פיתוי עצום פשוט להתיישב ולבנות את "לוח המחוונים האולטימטיבי".

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

היה נתק מוחלט בין הפיקסלים על המסך לבין שולחן קבלת ההחלטות.

 

ארבע השאלות שעושות סדר בבלאגן

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

  1. מי אתה ומה התפקיד שלך? האם אתה סמנכ"ל שיווק שצריך לראות מגמות מאקרו ולחלק תקציב רבעוני, או מנהל צוות תמיכה שצריך לדעת איפה יש צוואר בקבוק ממש עכשיו ב-10:00 בבוקר?
  2. איזו החלטה עסקית אתה צריך לקבל בעזרת המידע? (למשל: האם לעצור קמפיין מסוים? האם לשנות תמחור של חבילה? האם להקצות עובדים נוספים לפרויקט?)
  3. מה תראה על המסך שיגרום לך לפעול אחרת מחר בבוקר? אם מספר מסוים יעלה ב-8% או יצנח בחצי — איזו פעולה פיזית תבצע בעולם האמיתי בעקבות זה?
  4. מה מבחינתך נחשב לתובנה שמקדמת את העסק, ולא סתם "עובדה מעניינת"?

השיחה הזו שינתה את כל התמונה. פתאום כולם הבינו שחצי מרשימת הדרישות הייתה מורכבת מ"מדדי גאווה" (Vanity Metrics) — מספרים שנראים נהדר בגרף, אבל לא גורמים לאף אדם בארגון לקום מהכיסא ולעשות משהו אחרת.

פחות זה הרבה יותר

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

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

 

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

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

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

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

דברו איתנו

*לפרטים לעניין איסוף והשימוש במידע שלך על ידי SQLINK ראה הצהרת פרטיות