התשובה הקצרה

Login מוכיח שמישהו נכנס למערכת. הוא לא מוכיח שהעבודה נעשתה בתוכה, שהנתון שנכנס אמין, או שהמנהל יכול לקבל החלטה על בסיסו. ארגון שמדווח 92% Logins ובמקביל מנהל תחזית באקסל — לא אימץ Salesforce, הוא רק פתח אותה.

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

שלוש רמות של אימוץ

רמהמה נמדדדוגמהמה זה אומר
נוכחותLogin, זמן שהייה92% נכנסו השבועכמעט כלום
שימוש פעילפעולות ליבה לפי תפקיד78% מהעסקאות עודכנו תוך 7 ימיםהתהליך רץ
ערךתוצאה עסקית + איכותסטיית תחזית ירדה מ-31% ל-12%האימוץ שילם

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

איך מגדירים פעולת ליבה

פעולת ליבה היא הפעולה שבלעדיה התהליך שבור. לא הפעולה הנפוצה ביותר — הפעולה הקריטית ביותר. עבור נציג מכירות זה בדרך כלל עדכון שלב ותאריך סגירה; עבור מנהל מכירות זה סקירת Pipeline שבועית בתוך Salesforce; עבור נציג שירות זה סגירת Case עם קוד סיבה נכון.

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

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

שכבת איכות הנתונים

פעולה שבוצעה גרוע היא לפעמים גרועה מפעולה שלא בוצעה, כי היא מייצרת אמון שווא. לכן כל מדד כמותי צריך צמד איכותי:

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

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

פילוח: הממוצע משקר

ממוצע ארגוני של 70% אימוץ יכול להסתיר צוות אחד ב-95% וצוות אחר ב-20%. כל מדידה חייבת להיות מפולחת לפי שלושה חתכים לפחות:

  1. תפקיד — נציג, מנהל, Back Office. לכל אחד ציפייה שונה.
  2. צוות או מנהל ישיר — ההבדל הגדול ביותר באימוץ הוא כמעט תמיד המנהל הישיר, לא ההדרכה.
  3. ותק במערכת — משתמשים שהצטרפו אחרי ה-Go Live לא עברו את אותה הדרכה, והנתון שלהם מעיד על תהליך הקליטה.

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

Baseline: הטעות שאי אפשר לתקן בדיעבד

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

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

מממצא לפעולה

הטבלה הבאה ממפה ממצאים נפוצים לפעולה הנכונה. ההיגיון: כמעט אף ממצא אימוץ אינו נפתר בהדרכה נוספת.

ממצאסיבת שורש סבירהפעולה מומלצת
Logins גבוהים, פעולות ליבה נמוכותהמערכת אינה במסלול העבודה היומישילוב בתהליך: התראות, Path, רשימות עבודה
פעולות מבוצעות אך באיחור של שבועותאין מחזור ניהולי שנשען על הנתוןסקירת Pipeline שבועית מתוך Dashboard
איכות נמוכה בשדה מסויםהשדה לא רלוונטי או לא ברורלצמצם, לשנות ל-Picklist או להסיר
צוות בודד נחשלמנהל ישיר שאינו משתמשעבודה עם המנהל, לא עם הצוות
כלל השדות ממולאים אך ההנהלה לא סומכתחוסר התאמה בין המדד לשאלה העסקיתהגדרה מחדש של מדד התוצאה

איך זה נראה בדוח חודשי

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

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

סיכום

מדדי אימוץ אינם דוח ציונים למשתמשים — הם מערכת גילוי תקלות בתהליך. אם המדידה לא מובילה לשינוי בתהליך, בממשק או בשכבת הניהול, היא רק מייצרת עבודה. התחילו מארבעה מדדים, פלחו לפי צוות, קבעו Baseline, וקשרו כל ממצא לפעולה עם אחראי.