מקור אמת אחד לכל מאפיין

🌐 זמין גם ב-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)

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

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

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

השאלה שהיחידה הזו עונה עליה: מה באמת אומר “מקור אמת אחד”?

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

האמת שייכת למאפיין

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

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

רשומה אחת; האמת מפוזרת. זה נורמלי. “מערכת הרשומה = Salesforce” לא מתאר את זה. מודל סמכות כן.

איפה נוצר, איפה נערך, איפה משמש, וכמה מהר?

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

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

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

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

מערכת רשומה, מערכת מעורבות, מערכת ייחוס

אוצר המילים של פרק 4 עוזר כאן. מערכת רשומה (system of record) מחזיקה את הגרסה הסמכותית. מערכת מעורבות היא המקום שבו אנשים עובדים איתה. מערכת ייחוס מספקת נתונים שמערכת אחרת משתמשת בהם אבל לא מחזיקה בבעלותה. Salesforce יכול להיות מערכת המעורבות של הקשר עם הלקוח בזמן שה-ERP נשאר מערכת הרשומה של המאפיינים המשפטיים והפיננסיים שלו. זו לא חולשה בארכיטקטורה; זו היא הארכיטקטורה. הטעות היא להעמיד פנים שמערכת אחת חייבת להיות הבעלים של הכול כדי שהדיאגרמה תיראה פשוטה יותר.

רשומת הזהב ההיברידית

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

הפכו את הסמכות לגלויה

אז אני הופך סמכות חיצונית לבולטת בסכמה. אם SAP שולטת בשדה, הוא מקבל קידומת: sap_Customer_Number, sap_Credit_Status, sap_Legal_Name. זה אותו רעיון כמו קידומת ה-erp_ של פרק 4. השתמשו בשם המערכת כשהסמכות הזו ספציפית ויציבה, ובקידומת כללית כשהמשמעות חשובה יותר מהספק של היום. העיקר הוא שבעוד שישה חודשים, מי שקורא את המודל יוכל לראות: זה לא עוד שדה של Salesforce; מערכת אחרת היא הבעלים של הערך הזה. אל תכריחו אנשים לגלות מחדש את הסמכות על ידי הנדסה לאחור של אינטגרציות.

בנו מפת סמכות

לנתוני אב חשובים, אני רוצה מפת סמכות (authority map): לכל מאפיין מפתח, מי יוצר אותו, מי הבעלים של ההחלטה העסקית, איזו מערכת סמכותית, ומי או מה רשאי לשנות אותו. ארבע שאלות שונות:

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

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

Click to enlarge

לקוח אחד. מאפיינים רבים. סמכות אחת לכל אחד.

הסמכות משתנה לאורך מחזור החיים

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

עותק איננו סמכות

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

אמון צריך יותר מערך

“כתובת חיוב: רחוב הראשי 123.” לסמוך עליה? אני רוצה אותות אמון: מאיפה היא הגיעה, מתי אושרה לאחרונה, איזו מערכת סיפקה אותה, ומי או מה שינה אותה לאחרונה: אדם, אינטגרציה, סוכן? עכשיו ה-ERP אומר רחוב הראשי 123, Salesforce אומר 125, וקובץ של שותף אומר “הראשי 123, סוויטה 200.” מה נכון? אל תענו “השתמשו בעדכני ביותר.” אולי. אבל “העדכני ביותר” הוא בעצמו כלל שמניח שמי ששינה אחרון ראוי לנצח. זה יכול להיות נכון, או נורא. יחידה 3 מתמודדת עם זה. אמון מגיע מסמכות וממקור (provenance), לא ממציאת שדה שמישהו מילא.

Steve Trucking: של מי האמת?

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

Click to enlarge

משלוח אחד, שתי סמכויות.

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

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

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

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

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

להרחבה

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