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