טבלת הרכישות נראתה מצוין.

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

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

צינור הנתונים היה תקין. התשובה הייתה שגויה.

זה דיוק.

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

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

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

מדויק בהשוואה למה?

אי אפשר להעריך דיוק באופן מופשט.

בהשוואה למה?

  • לנתוני התשלומים שסולקו אצל ספק הסליקה?
  • לספרי החשבונות?
  • לקבלות של לקוחות?
  • לרשומות המשלוחים של המחסן?
  • למה שממשק המוצר הציג למשתמש?

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

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

האמת של מערכת המקור היא לא תמיד האמת העסקית

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

לפעמים זה הגיוני. לעיתים קרובות זה גם שגוי.

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

לכן דיוק דורש יותר מאמון במקור הנתונים ובמסלול שעברו. הוא דורש להבין מה בדיוק כל מערכת אמורה לתעד.

התאמה בין מקורות, דגימה ובדיקות מול המציאות

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

מוכיחים אותו באמצעות השוואה.

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

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

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

למה ביטחון בדשבורד הוא לא ראיה

דשבורד יציב יכול לטעות במשך חודשים.

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

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

התפקיד הלא נוח של מומחי התחום

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

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

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

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

איך אנליסטים בדרך כלל מפספסים בעיות דיוק

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

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

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

רשימת בדיקה מעשית להתאמה בין מקורות

בכל מדד עסקי חשוב, ודאו שיש התאמה בין המערכות לבין מה שהעסק חווה בפועל.

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

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

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