ארבע הדרכים לנהל נתוני אב

🌐 זמין גם ב-28 שפות

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

התמונה נוצרה בבינה מלאכותית

תורגם בבינה מלאכותית. הקהילה עוד לא בדקה את התרגום. לקריאה באנגלית

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

השאלה שהיחידה הזו עונה עליה: איך ארגונים מנהלים נתוני אב, ואיזה סגנון מתאים?

יחידה 1 אמרה שסמכות נקבעת מאפיין אחרי מאפיין. עכשיו: מה עושים כשהמאפיינים האלה חיים בכמה מערכות בבת אחת? מידע על לקוחות ב-Salesforce, ב-ERP, בחיוב, בתמיכה, אולי ב-Data 360, אולי במחסן נתונים, ולכל אחת גרסה משלה. זו הבעיה שניהול נתוני אב (MDM) מנסה לפתור, ו-MDM איננו ארכיטקטורה אחת. תשמעו על ארבעה דפוסים: רישום (registry), איחוד (consolidation), דו-קיום (coexistence) ומרכזי (centralized). הם לא הגדרות של מוצר. הם ארבע תשובות לשאלה אחת: כמה סמכות יש לשכבת ניהול נתוני האב?

התחילו מהבעיה, לא מהמוצר

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

רישום: תגידו לי מי זה מי

הדפוס הכי קל. רישום (registry) לא מחליף את המקורות. ה-ERP שומר את הלקוח שלו, Salesforce את החשבון שלו, החיוב את הלקוח שלו, והרישום מבין שהרשומות האלה מייצגות את אותה ישות: חשבון Salesforce 001…, לקוח ERP SAP-43821 ולקוח חיוב BILL-9127 שייכים ללקוח אחד. המקורות נשארים במקומם ולא נדרסים. עכשיו ל”תראו לי כל מה שאנחנו יודעים על הלקוח הזה” יש תשובה.

אבל שימו לב על מה רישום לא עונה. Salesforce אומר רחוב הראשי 123, ה-ERP אומר 125, החיוב “הראשי 123, סוויטה 200.” הרישום יודע שהם שייכים יחד. הוא לא מחליט איזה מהם צריך להשתנות. קישור איננו ניהול נתוני אב.

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

Click to enlarge

רישום עונה: אילו רשומות שייכות לאותה ישות?

איחוד: להביא את הנתונים יחד

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

קל לבלבל בין רישום לאיחוד. ההבדל הוא מה מרוכז: רישום מרכז זהות (“אלה שייכים יחד”); איחוד מרכז יותר מהנתונים (“בואו נביא את המאפיינים יחד כדי שנוכל להשתמש בהם”). אף אחד מהם לא אומר “המערכת המרכזית הזו היא עכשיו מקור האב וכל אפליקציה חייבת לקבל את הערכים שלה.”

Click to enlarge

איחוד מביא את הנתונים יחד בלי לקחת את הבעלות מהמקורות.

דו-קיום: להחליט, ולשלוח חזרה

בדו-קיום (coexistence), שכבת ניהול נתוני האב מקבלת סמכות אמיתית. הנתונים עדיין חיים בכמה מערכות תפעוליות, אבל תהליך ה-MDM מחליט על הערך המנוהל ומפרסם אותו חזרה. ל-Salesforce, ל-ERP ולחיוב יש כל אחד שם משפטי אחר; תהליך ה-MDM קובע את השם המנוהל ומפיץ אותו לשלושתם. המערכות מתקיימות זו לצד זו, אבל הן מתכנסות לערך המנוהל.

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

Click to enlarge

דו-קיום לא רק מקשר את הרשומות. הוא מחליט על ערכים מנוהלים ושולח אותם חזרה.

מרכזי: מקור האב יוצר את האמת

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

Click to enlarge

MDM מרכזי מעביר את היצירה ואת הסמכות למקור האב.

הארבעה זה לצד זה

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

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

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

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

איפה Data 360 נכנס?

Data 360 בונה פרופילים מאוחדים על פני מקורות רבים, מה שנשמע מאוד כמו MDM, והוא אכן פותר חלק מהבעיה. זיהוי הישויות שלו מתאים פרופילי מקור לזהות מאוחדת ושומר את הקישורים חזרה לרשומות המקור (Data 360 Architecture (opens in a new tab)). זה הופך אותו לקרוב ביותר לרישום. הוא יכול גם להציג ערכים מיושבים (reconciled) על הפרופיל המאוחד. אבל זה לא הופך אותו למערכת רשומת זהב מרכזית שכותבת מחדש את המקורות. תמונה מאוחדת איננה אוטומטית רשומה ארגונית מנוהלת. יחידה 4 עוסקת כולה בהבדל הזה.

מודל משותף איננו אמת משותפת

תשמעו גם על מודל נתונים קנוני (canonical data model). החשבון של Salesforce, השותף העסקי (business partner) של ה-ERP והלקוח של החיוב ממופים כולם למושג ארגוני מוסכם אחד, לקוח, עם מזהים ומאפיינים מוסכמים, כך שכל אינטגרציה לא צריכה להבין את הצורה של כל מערכת אחרת. מודל הנתונים של Data 360 הוא דוגמה להאחדה (harmonization) של מקורות למושגים משותפים. אבל מודל קנוני עונה על איך מייצגים את זה באופן עקבי? MDM עונה על איך מזהים את זה, מחילים עליו ממשל ומנהלים אותו כנתוני אב על פני מערכות? מפו את שלוש המערכות בצורה מושלמת לצורת לקוח אחת, ו-Salesforce עדיין אומר רחוב הראשי 123 בזמן שה-ERP אומר 125. פתרתם את המבנה, לא את הסמכות. האחדה וניהול נתוני אב אינם תחליף זה לזה.

עסק אחד, כמה דפוסים

אז “Steve Trucking צריכה MDM” היא לא דרישה. בשביל מה? שותפים קמעונאיים, מרכזי הפצה, צוותים, משאיות, נמענים הם תחומים שונים עם סמכויות שונות: שותפים קמעונאיים מנוהלים ב-Salesforce וב-ERP של הכספים, זהות המשאית מגיעה מ-FleetLink, וכל נמען מסופק על ידי שותף לכל משלוח. תחומים שונים יכולים לקבל דפוסים שונים, ובתוך תחום, למאפיינים יכולות להיות סמכויות שונות. אז אל תשרטטו קופסה עם התווית MDM באמצע הדיאגרמה ותגידו שזה פתור. שאלו מה הקופסה עושה.

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

MDM היא החלטה עסקית

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

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

מה הארכיטקט מחליט כאן

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

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

להרחבה

• Salesforce Architects, Data 360 Architecture (opens in a new tab) (באנגלית, נבדק ב-2026-10-14).