מה זה דשבורד באקסל ולמה הוא נשבר עם הזמן

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

מה הנתונים מראים

הבעיה הזו לא ייחודית לעסק אחד. ריימונד פנקו, פרופסור באוניברסיטת הוואי שהקדיש עשרות שנים לחקר שגיאות בגיליונות אלקטרוניים (Panko, "What We Know About Spreadsheet Errors", Journal of End User Computing, 1998, עם עדכונים שוטפים בפרויקט Spreadsheet Research של האוניברסיטה), מצא שבביקורות על גיליונות אמיתיים בשימוש בארגונים, כ-88% מהם הכילו לפחות שגיאה אחת, בדרך כלל בנוסחה שהועתקה לתא הלא נכון או שהתייחסה לטווח נתונים שהתרחב בלי שהנוסחה התרחבה איתו. המספר הזה לא אומר שאקסל פגום, הוא אומר שגיליון שמתרחב בהדרגה, תא אחרי תא, לאורך חודשים, הוא בדיוק הסביבה שמייצרת שגיאות כאלה ומסתירה אותן, כי אף שלב בתהליך לא עוצר כדי לבדוק את המבנה כולו מחדש.

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

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

למה הוא נשבר דווקא עם הזמן, ולא ביום הראשון

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

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

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

מה זה אומר בפועל, לא רק לדיוק הנתונים

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

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

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

שלוש דרכים אפשריות להתמודד עם זה

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

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

מה שווה לעשות קודם

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

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

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