היררכיות ונתונים דו-כיווניים

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

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

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

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

השאלה שהיחידה הזו עונה עליה: איך מנהלים נתונים שיותר ממערכת אחת מתחזקת?

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

נתונים דו-כיווניים לא אומרים שני מקורות אב

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

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

Click to enlarge

אינטגרציה דו-כיוונית לא יוצרת סמכות דו-כיוונית.

כשמקור האב אומר לא

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

לולאות והתנגשויות

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

ואז התנגשויות. פגשתם אחת בפרק 5: נציג מבקש Steve’s Plumbing LLC בזמן שמישהו ב-ERP מקליד Steve’s Plumbing L.L.C. (מגינים על הרשומה המנוהלת). הנה עוד אחת. Salesforce מציע רחוב הראשי 125; כמעט באותו רגע משתמש ב-ERP משנה ל-130. מי מנצח? אין תשובה טכנית אוניברסלית. אולי ה-ERP תמיד מנצח כי הוא הבעלים של השדה; אולי הבקשה של Salesforce הולכת לתור בדיקה; אולי השינוי שהתקבל אחרון מנצח; אולי ה-ERP דוחה כל עדכון שערך ההתחלה שלו השתנה. זו מקביליות, אבל מתחתיה יש החלטת סמכות, ושום דפוס אינטגרציה לא יציל אתכם אם אף אחד לא החליט מי רשאי לבצע את השינוי הסמכותי.

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

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

גם היררכיות הן נתוני אב

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

ב-Salesforce, היררכיות חשבונות נבנות עם השדה Parent Account. תצוגת ההיררכיה ב-Lightning מציגה עד 2,000 חשבונות, ורק את אלה שהמשתמש רשאי לראות; חשבונות אישיים לא נתמכים בהיררכיה; ו-Account Site מבחין בין המיקומים של חברה (Considerations for Using Account Hierarchy (opens in a new tab)). אבל השדה Parent Account לא עונה על השאלה הארכיטקטונית: מי הבעלים של ההיררכיה?

ידע למבחן. הכירו את היסודות של היררכיית חשבונות: היא נבנית עם Parent Account; התצוגה ב-Lightning מציגה עד 2,000 חשבונות, רק את אלה שהמשתמש יכול לראות; חשבונות אישיים לא נתמכים; ו-Account Site מבחין בין המיקומים של חברה.

היררכיה אחת, כמה מקורות אב

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

Click to enlarge

אפשר לקבוע את הסמכות על היררכיה ענף אחרי ענף.

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

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

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

לקוח אחד, שני ERPs

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

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

היררכיית חשבונות. Steve’s Plumbing היא האם, עם Steve’s Plumbing North America ו-Steve’s Plumbing Europe כחשבונות בת, וכל בת מייצגת את הרשומה של ERP אחד. המלכודת: הבנות כבר לא באמת Steve’s Plumbing. הן Steve’s Plumbing שעושה עסקים באזור מסוים, וכמו שראינו עכשיו, היררכיה נושאת משמעות.

חשבונות עמיתים. שני חשבונות זה לצד זה, לכל אחד שדה שאומר לאיזה ERP הוא שייך: קוד חברה, אזור. שום דבר לא מוסתר. המחיר מופיע בדיווח: כדי לראות את Steve’s Plumbing בכל העולם, צריך משהו שאומר ששני החשבונות האלה הם אותה חברה.

חשבון אחד, עם רשומת בת לכל ERP. Steve’s Plumbing אחת, ואובייקט בת עם רשומה לכל ERP שמחזיקה את מזהה הלקוח של אותו ERP. שני ERPs או עשרה. אנשי המכירות רואים לקוח אחד ומבצעים הזמנה אחת; מאחורי הקלעים, זרימות מחליטות לאיזה ERP הולכת כל שורה: עבודות חשמל ל-ERP של החשמל, אינסטלציה ל-ERP של האינסטלציה. אבל עכשיו צריך להחליט איזה ERP ראשי לערכים המשותפים, כמו שם וכתובת, ומה קורה כשהלקוח קיים ב-ERP אחד ולא בשני.

Click to enlarge

לקוח אחד, שני ERPs: שלוש דרכים לייצג אותו ב-Salesforce.

שאלו איך הם שומרים את ה-ERPs מסונכרנים

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

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

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

MDM באמצע

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

Click to enlarge

MDM באמצע: Salesforce מצביע למקום אחד.

Steve Trucking: של מי ההיררכיה?

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

הפכו את הגבולות לגלויים

בכל פעם שהסמכות מפוצלת, אני רוצה שהגבול יהיה גלוי: שמות שדות, מטא-דאטה של הרשומה, מזהי מערכת מקור, הרשאות, התנהגות האינטגרציה, תיעוד. מה שאני לא רוצה זה מפתח שקורא חמש אינטגרציות כדי לגלות ש”ערכי ה-Parent Account האלה מגיעים מ-SAP, חוץ מלקוחות פוטנציאליים, חוץ מאירופה.” זה לא מודל סמכות שאפשר לתחזק. אם ההיררכיה מנוהלת בסמכות מפוצלת, תעדו את הפיצול. אם הסמכות משתנה בהמרה, תעדו את השינוי. אם Salesforce יכול לבקש שינוי אבל לא לבצע אותו, הפכו את זה לברור בחוויית המשתמש.

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

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

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

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

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

להרחבה

• Salesforce Help, Considerations for Using Account Hierarchy (opens in a new tab) (באנגלית, נבדק ב-2026-10-14).