מיזוג מערכות CRM אחרי רכישה: מה עובר ומה נשאר?

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

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

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

למה מיזוג מערכות CRM הוא לא רק העברת נתונים?

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

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

איך בוחרים לאיזו מערכת CRM ממזגים?

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

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

מה עובר במיזוג מערכות CRM ומה נשאר מאחור?

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

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

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

מתי עדיף לא למזג את מערכות ה-CRM?

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

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

איך עוברים את תקופת מיזוג ה-CRM בלי לאבד לקוחות?

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

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