התשובה הקצרה

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

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

מה נכנס ל-Master ומה לא

סוג נתוןדוגמההאם Master
Master Dataלקוח, מוצר, ספק, אתרכן
Reference Dataמדינות, מטבעות, קודי ענףניהול נפרד ופשוט יותר
Transactionalהזמנה, חשבונית, Caseלא
Analyticalפילוח, ניקוד, תחזיתלא - נגזר

ההבחנה חשובה כי כל סוג דורש משטר אחר. Reference Data נשלט בטבלה קטנה עם בעלים אחד; Transactional נשאר במערכת שיוצרת אותו; Analytical אסור שיהפוך למקור אמת, כי הוא תוצר של חישוב שמשתנה.

שלושת סגנונות המימוש

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

Consolidation - מייצרים Golden Record לצורכי דיווח וניתוח, בלי להזרים אותו חזרה. מתאים כשהכאב העיקרי הוא דיווח כפול.

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

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

Survivorship: הכללים שקובעים מה שורד

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

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

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

Stewardship: התפקיד שמכריע אם זה יעבוד

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

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

תרחיש: יצרן עם שלוש מערכות ולקוח אחד

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

במקום פרויקט MDM מלא, הארגון התחיל ב-Registry: נבנתה טבלת מזהים ב-Data 360 שקשרה את שלוש הרשומות באמצעות ח.פ ומפתח משני, ורק אחר כך נבנה Golden Record לקריאה. Salesforce לא שינה מבנה; הוא קיבל שדה מזהה גלובלי ותצוגת "כל הפעילות בקבוצה".

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

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

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

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

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

בניית משטר MDM מדורג מתבצעת במסגרת שירות אינטגרציות ודאטה.

Checklist לפני התנעת MDM

  • ☐ נבחרו עד שלוש ישויות לגל הראשון
  • ☐ לכל ישות קיימת הגדרה עסקית כתובה
  • ☐ נבחר סגנון מימוש: Registry, Consolidation או Centralized
  • ☐ מפתחות זיהוי חזקים אותרו לכל מקור
  • ☐ כללי Survivorship נכתבו ברמת שדה
  • ☐ מזהי מקור נשמרים ומאפשרים חישוב מחדש
  • ☐ מונה Steward עם זמן מוקצה ו-SLA
  • ☐ הוגדר תהליך אישור ליצירת ישות חדשה
  • ☐ נקבע מדד ערך אחד לגל הראשון
  • ☐ קיימת החלטה מתי בכלל נשקול כלי ייעודי

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