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

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

למה רוב הדשבורדים מתים אחרי חודש

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

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

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

מתחילים מהחלטות, לא מנתונים

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

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

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

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

שלושה עד חמישה מדדים, וכל אחד מוגדר עד הסוף

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

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

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

מילון קצר

• KPI (מדד ביצוע מרכזי) - מספר שנבחר כי הוא מנבא החלטה, לא כי הוא זמין. יש לו בעלים, נוסחה, קצב רענון ויעד.
• דשבורד (לוח בקרה) - מסך שמתעדכן לבד ומיועד לסריקה חוזרת, לא לקריאה מעמיקה.
• חריגה (Exception) - מצב שבו מדד יצא מהטווח שהוגדר כתקין. דשבורד טוב מציג חריגות לפני שהוא מציג גרפים.
• מקור אמת אחד (Single source of truth) - המקום היחיד שממנו כל מספר בדשבורד נלקח, כך שאין שתי גרסאות לאותו נתון.
• BI (Business Intelligence) - משפחת הכלים לחיבור נתונים, חישוב והצגה. הכלי הוא ההחלטה האחרונה בתהליך, לא הראשונה.

מגמה במקום מספר בודד, חריגה במקום גרף

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

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

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

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

מסך תפעולי מול מסך ניהולי

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

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

פריסה בעברית ובנייד, ואיזה גרף לאיזה מספר

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

• הדבר החשוב ביותר בפינה הימנית העליונה. העין בעברית מתחילה שם. רשימת החריגות או המדד הראשי יושבים שם, לא הלוגו.
• מספרים ותאריכים נשארים משמאל לימין. "12.5 אלף" ו-"01/09" צריכים להיות מסומנים כטקסט חד-כיווני, אחרת דפדפנים הופכים סימני מינוס ואחוזים למקומות לא צפויים.
• ציר הזמן בגרף רץ משמאל לימין גם בעברית. זו מוסכמה שכולם מכירים, וגרף שרץ הפוך נקרא לא נכון גם על ידי דוברי עברית.
• טבלאות מיושרות לימין, עמודות מספרים מיושרות לימין גם הן, כך שהספרות מתיישרות זו מתחת לזו ואפשר להשוות בלי לקרוא.
• נייד קודם. מסך ניהולי נפתח מהטלפון יותר מפעם. בנייד המדדים נערמים בעמודה אחת לפי חשיבות, החריגות למעלה, וגרפים רחבים הופכים למספר עם חץ. מסך שאי אפשר לסרוק בטלפון בשלושים שניות לא יעבוד.

איזה גרף לאיזה מספר

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

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

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

איכות נתונים ובעיית מקור האמת האחד

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

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

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

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

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

דוגמה: דשבורד לחברת שירות עם שלושה מדדים

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

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

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

סיכומי AI מעל הדשבורד, בזהירות

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

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

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

שורה תחתונה

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

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