ממשל הנתונים מתוכנן לתוך ה-org

🌐 זמין גם ב-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 עומד בעיקר לבד, ממשל נתונים פירושו לנקות נתונים במקום אחד. כשהוא צומת אחד במפת המערכות מפרק 4, זה נעשה קשה יותר, ונחוץ יותר. עכשיו הלקוח חי ב-Salesforce, ב-ERP, במחסן הנתונים, במערכות של שותפים, ב-Data 360. של מי הוא? מי יכול לשנות אותו? איזה עותק סמכותי, אילו מאפיינים מותר להעביר, כמה זמן שומרים אותם, ומי עונה כשהם שגויים? אלה לא שאלות של הגדרות. אלה שאלות של ממשל נתונים שהופכות להגדרות.

בעלי הרשומה הם לא בעלי הנתונים

נתחיל מהמילה בעלים, כי Salesforce הופך אותה למבלבלת. פתחו חשבון ותראו Owner: נניח, איש מכירות. האם איש המכירות הוא הבעלים של נתוני הלקוח? לא בהכרח. ב-Salesforce, רשומה באובייקט שיש לו בעלים שייכת למשתמש או לתור; הבעלים מקבל גישה מלאה, והבעלים מניע הקצאה ושיתוף דרך היררכיית התפקידים וכללי השיתוף (Sharing and Record Access Features (opens in a new tab)). זו בעלות על רשומה: מנגנון של הפלטפורמה.

בעלי הנתונים הם משהו אחר: האדם או הפונקציה שאחראים לנתונים כנכס עסקי. הכספים יכולים להיות הבעלים של פרטי הלקוח המשפטיים, התפעול של סטטוס המשלוח, משאבי אנוש של נתוני העובדים. Salesforce אפילו נותן לכם מקום לרשום את זה: שדה הסיווג Data Owner בכל שדה (Data Classification Metadata Fields (opens in a new tab)).

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

בעלים, נאמן, אפוטרופוס

שלושה תפקידים בממשל נתונים, שלוש עבודות שונות.

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

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

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

איך התוכנית פועלת

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

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

שה-RACI יצדיק את מקומו

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

ממשל הנתונים צריך להפוך למכני

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

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

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

Click to enlarge

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

אל תסמכו על התנהגות טובה

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

ממשל הנתונים חוצה גבולות של מערכות

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

לנהל מספיק, לא הכול

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

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

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

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

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

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

להרחבה

• Salesforce Help, Sharing and Record Access Features (opens in a new tab) (באנגלית, נבדק ב-2026-10-14).
• Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (באנגלית, נבדק ב-2026-10-14).