גיבוי ושחזור ב-CRM: מה עושים כשנמחק מידע חשוב?

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

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

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

למה גיבוי ב-CRM שונה מגיבוי של קבצים?

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

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

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

מה באמת כולל הגיבוי של ספק ה-CRM?

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

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

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

מה בודקים בתרגיל שחזור לפני שצריך אותו?

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

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

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

מי אחראי על הגיבוי והשחזור בארגון?

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

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

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

מתי גיבוי ושחזור הם לא הבעיה האמיתית?

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

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

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