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