התשובה הקצרה

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

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

רקע על תכנון ההסבה כולה נמצא במיגרציית נתונים ל-Salesforce.

שלושת סוגי הפערים שה-Mapping חושף

סוג פערדוגמה שכיחהמי מכריע
פער סמנטי"לקוח פעיל" = רכש השנה במערכת אחת, = לא נחסם במערכת אחרתבעל התהליך העסקי
פער מבנילקוח אחד עם חמש כתובות מול מודל Account/Contactארכיטקט הנתונים
פער איכות18% מהרשומות ללא ח.פ תקיןData Owner + רגולציה

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

שכבת המשמעות: Data Dictionary לפני גיליון Mapping

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

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

אנטומיה של שורת Mapping תקינה

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

שלושה כללי עבודה שחוסכים תקלות:

  • אין המרה שקטה. כל ערך שהמערכת "מתקנת" בעצמה חייב להירשם בלוג חריגים.
  • ברירת מחדל היא החלטה עסקית. מי שכותב Country = IL כברירת מחדל צריך להיות מי שאחראי לדוחות לפי אזור.
  • מפתחות חיצוניים לפני הכול. לכל ישות שומרים External ID ממערכת המקור. בלעדיו אין Reconciliation ואין הרצה שנייה.

Transformations: איפה טועים

ההמרות שמייצרות הכי הרבה נזק הן דווקא הפשוטות. תאריכים בלי אזור זמן מזיזים רשומות ביום; שמות שעוברים Trim ו-Upper בלי כלל אחיד מייצרים כפילויות חדשות בדיוק אחרי שניקינו כפילויות ישנות; סכומים שמומרים למטבע אחיד בשער יומי מייצרים פערי דיווח מול ה-ERP.

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

מי שעדיין לא סגר את שאלת מקור האמת ימצא רקע בSource of Truth בארגון, ואת חלון ההעברה עצמו בCutover ו-Reconciliation.

תרחיש: חברת שירותים עם שתי מערכות מקור

ארגון שירותים עם 90 אלף לקוחות ניגש להסבה משתי מערכות: מערכת גבייה ותיקה ומערכת שירות שנרכשה עם חברה-בת. גיליון ה-Mapping הראשון סומן "מוכן" תוך שבועיים - 340 שדות ממופים.

בהרצת ה-Rehearsal הראשונה 97% מהרשומות נטענו. הבעיה התגלתה ב-Reconciliation: סך היתרות ב-Salesforce היה נמוך ב-4.1% מה-ERP. הסיבה לא הייתה טעינה שנכשלה, אלא שכל הרשומות עם יתרה שלילית (זיכויים) מופו לשדה עם Validation Rule שמונע ערך שלילי - והוצבו כאפס בשקט.

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

סיכונים נפוצים ופעולות מניעה

סיכוןכיצד הוא נראה בפועלפעולת מניעה
העברת כל ההיסטוריהנפח, כפילויות ומידע חסר ערך עוברים למערכת החדשהלהגדיר Retention וספי איכות
Mapping טכני בלבדשדות מועברים בלי להבין משמעות עסקיתData Dictionary ובעלים עסקיים
המרות שקטותערכים מתוקנים אוטומטית ואיש לא יודעלוג חריגים חובה לכל כלל המרה
אין Rehearsalחלון ההשבתה מתארך ונוצרות הפתעותלפחות שתי הרצות מלאות
אין External IDאי אפשר לאמת, לתקן או להריץ שובמפתח מקור נשמר לכל ישות

כיצד מודדים הצלחה

תחוםמה מודדיםקצב בדיקה
Completenessשיעור שדות חובה מלאים ביעדלפני ואחרי כל טעינה
Reconciliationהתאמת ספירות, סכומים וקשרים למקורבכל Rehearsal וב-Cutover
חריגיםמספר שורות חריג פתוחות לפי חומרהיומי בתקופת ההסבה
שדות ללא צרכןכמה שדות שהועברו לא נקראו ב-90 יוםפעם אחת אחרי Go Live

המדד האחרון הוא הכנה למחזור הבא: הוא מלמד כמה מהעבודה הייתה מיותרת ומכוון את היקף ההסבה הבאה.

ארגונים שמעדיפים ליווי מקצועי בבניית ה-Mapping עושים זאת במסגרת שירות אינטגרציות ודאטה.

Checklist לפני הטעינה הראשונה

  • ☐ מילון מונחים קצר לכל ישות מרכזית, מאושר בעסק
  • ☐ רשימת שדות עם צרכן מוגדר; היתר לארכיון
  • ☐ External ID לכל ישות שעוברת
  • ☐ טבלת Value Mapping מלאה, כולל ערך לערכים לא מוכרים
  • ☐ כלל מפורש לכל ערך ריק ולכל ברירת מחדל
  • ☐ כל כלל המרה מפיק שורת חריג במקום תיקון שקט
  • ☐ תסריט Reconciliation: ספירה, סכום, קשר, דגימה ידנית
  • ☐ סף חריגים מוסכם שמעליו לא מבצעים Cutover
  • ☐ גרסה וחתימה על גיליון ה-Mapping
  • ☐ תוכנית Rollback והרצה חוזרת

מקורות מקצועיים