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