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