למה הטמעות CRM ו-ERP נכשלות?

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

כמה הדרכה צוות באמת צריך?

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

כדאי להריץ את התהליך הישן במקביל למערכת החדשה לזמן מה?

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

מי צריך להיות הבעלים הפנימי של המערכת?

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

איך נדע אם ההטמעה הצליחה?

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

הטמעת CRM ו-ERP: למה מערכות נכשלות באימוץ ולא בהתקנה

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

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

המערכת לא הייתה הבעיה. כמעט כל הטמעה כושלת שראיתי נכשלה באימוץ, ולכשלי אימוץ יש סיבות עקביות שאפשר לטפל בהן.

למה אנשים חוזרים לאקסל

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

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

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

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

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

איך נראית הטמעה טובה

להגדיר לפי התהליך שיש לכם באמת

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

לתקן את הנתונים לפני העלייה לאוויר

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

להדריך לפי תפקיד, על החמישייה היומית

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

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

לכתוב את המדריך של שני העמודים, לא את המדריך המלא

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

למנות בעלים פנימי

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

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

לכבות את הדרך הישנה

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

לוח זמנים ריאלי

שלב	משך טיפוסי
מיפוי תהליכים והגדרה	2-4 שבועות
ניקוי והעברת נתונים	2-6 שבועות, בחפיפה
פיילוט עם צוות אחד	שבועיים
הדרכה לפי תפקיד ועלייה לאוויר	1-2 שבועות
ייצוב עם תמיכה אינטנסיבית	4-6 שבועות

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

איך לדעת אם זה הצליח

אל תמדדו כניסות. מדדו אם העבודה באמת עברה:

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

האחרון הוא המבחן הכן. אם מערכת הצללים עדיין חיה, ההטמעה לא הסתיימה.

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