איכות הנתונים כתנאי להצלחת פרויקט CRM

 

מאת: אבי עסיס

 

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

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

 

* אנו יודעים מי הלקוחות

* מה היקף הצריכה שלהם

* כמה הם שווים לארגון

* מה הצרכים שלהם

 

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

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

 

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

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

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

כניסה לפרויקט טיוב נתונים, מחייבת את הארגון לא רק להשקעת מאמץ חד פעמית, אלא ליצירת תהליך ממושך ומבוקר לכל אורך חיי המערכת. ע"פ המכון לשיווק ומכירות Sales and Marketing Institute  עולה כי ב-70.8% מהמקרים משתנה נתון או יותר על הלקוח במהלך השנה, פירושו שיישור קו חד פעמי בפרויקט טיוב נתונים יגרום לנו מהר מאוד לאבד את ההשקעה ושוב נמצא עצמנו עם בסיס נתונים שאינו מתאים בהכרח למציאות .

 

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

 

*אבי עסיס (M.Sc.) – מנכ"ל חברת Widelink  פתרונות עסקיים בע"מ. מומחה בעל ניסיון רב ביישום וניהול פרויקטי CRM בפרט ומחשוב ארגוני בכלל.

לתגובות, הערות והארות ניתן להפנות

למייל: avi@widelink-crm.com

 

 

קישורים רלבנטים באתר: