נתונים מלוכלכים – תוצר בעייתי: מה קורה לדאטה הארגוני שלכם?

או: איך שריטה במשקפי שמש היא הזדמנות למידה

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

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

מה הסיבה לביצוע ההחזר?

• מוצר פגום

• מוצר לא מתאים ללקוח / התחרט

רוצים לנחש מה נציגת השירות סימנה? היא סימנה "מוצר לא מתאים ללקוח / התחרט".

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

איך נתונים שגויים מסכלים את מאמצי הארגון

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

ברם, ניתוח ישיר של "שיעור המוצרים שהוחזרו בשל פגם", המבוסס על הנתונים שמזין הסניף בקופות הרשומות יעיד על מספר מאוד נמוך של מוצרים פגומים, בשל ההזנה השגויה של אנשי הסניף. ערוץ נתונים נוסף הוא הערוץ הלוגיסטי (של החזרות לספק, בהנחה שגם שם יש תיעוד מקביל), אבל מה שיקרה הוא שהאנליסט המנתח את הנתונים יקבל שני מספרים שונים בתכלית. המספר שמבוסס על הזנה שגויה בקופות הרושמות עשוי להוביל לקבלת החלטות מוטעית, או בשפה פשוטה: Garbage in garbage out (נתוני זבל נכנסים – ממצאי זבל יוצאים).

הזנת נתונים שגויה – לא רק ב-retail

התופעה הזו, של נתונים שמתועדים במערכות ארגוניות באופן שגוי, אינה ייחודית לרשתות פארמה או קמעונאות: לפני מספר שנים בעת שעבדתי עם לקוח מתחום השירות על אופטימיזציה של המערך שלו, רצינו לנתח את משכי השירות, ואת "הזמנים המתים" (כמה זמן לוקח לתת שירות ללקוח, ומהם ה-idle times של נותני השירות). תוך כדי ניתוח הנתונים גילינו שישנם משכי שירות קצרים בצורה קיצונית, ומשיחות עם אנשי השטח התגלה שלפעמים נותני השירות מתעדים את מתן השירות באופן שגוי (ביצוע check-in ו-check-out של מקבל השירות באופן מיידי, מסיבות של נוחות ועל מנת "לחסוך זמן" בסיום השירות). זה כמובן דרש מאיתנו התחכמויות ופשרות בניתוח הנתונים, משום שנתוני המקור היו לא אמינים ונדרשנו להחליט מהם הקריטריונים להכללת נתונים ואיך מתגברים על הדיווחים השגויים.

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

איך מתמודדים עם הבעיה?

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

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

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

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

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

איך מתמודדים עם הבעיה?

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