התשובה הקצרה

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

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

שלוש שאלות שמכריעות בעלות

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

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

מטריצת בעלות לדוגמה

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

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

הפרדה בין הצגה לסמכות

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

כל שדה שמועתק הוא התחייבות תפעולית: סנכרון, כשל, פער וזמן. לפני שמעתיקים שואלים אם נדרשת עליו אוטומציה או דיווח היסטורי. אם לא - עדיף להציג ולא להעתיק. הרחבה בגישה הזו נמצאת בZero Copy ו-Federation ב-Data 360.

קונפליקטים: להחליט מראש, לא בזמן אמת

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

תרחיש: ארגון עם שתי אמיתות לכתובת אחת

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

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

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

אכיפה: ממסמך למציאות

מטריצת בעלות מתקיימת רק אם היא מיושמת בשלוש נקודות: Field-Level Security שמונעת עריכה בצד שאינו הבעלים, משתמש אינטגרציה עם הרשאות מצומצמות לשדות שבבעלותו בלבד, ודוח חודשי שמציג שדות שעודכנו בניגוד למדיניות. הדוח השלישי הוא זה שחושף אינטגרציות ותיקות שאיש לא זוכר.

תיעוד המשמעות של כל שדה מתחבר ישירות לData Mapping למיגרציה.

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

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

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

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

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

Checklist להכרעת מקור אמת

  • ☐ רשימת הישויות המרכזיות בארגון
  • ☐ לכל ישות: איפה נוצר, מי מוסמך, מי אחראי לשגיאה
  • ☐ בעלות נקבעה ברמת שדה או קבוצת שדות
  • ☐ כיוון סנכרון מפורש לכל קבוצה
  • ☐ כל שדה מועתק עומד במבחן "יש לו צרכן"
  • ☐ כלל הכרעת קונפליקט נבחר וכתוב
  • ☐ קיים תור טיפול ידני עם בעלים ו-SLA
  • ☐ Field-Level Security תואמת את המטריצה
  • ☐ משתמש אינטגרציה מוגבל לשדות שבבעלותו
  • ☐ דוח חודשי לחריגות מדיניות

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