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