לא להכניס נתונים גרועים

🌐 זמין גם ב-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. כל יחידה עומדת בפני עצמה. הקודם: ממשל הנתונים מתוכנן לתוך ה-org · הבא: הכירו את הנתונים שלכם

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

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

“טוב מספיק” היא הגדרה עסקית

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

מונעים את הטעויות היקרות

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

פתוח או נעול?

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

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

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

הדרך האמצעית: סוג רשומה זמני

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

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

סוג רשומה לכל זרימה

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

Click to enlarge

סוג רשומה לכל זרימה: חשבונות Sales יוצאים, חשבונות ERP נכנסים.

זה לא מעלים את המקרה הקשה. איש מכירות ממיר ליד של Steve’s Plumbing, אבל Steve’s Plumbing כבר קיים כחשבון ERP, ואיכשהו בדיקת הכפילויות לא תפסה את זה. עכשיו אתם ממזגים, מעבירים את רשומות הבן להורה אחר ומחליטים איזו רשומה שורדת (פרק 6, יחידה 3).

ואל תיתקעו על סוג הרשומה עצמו. בדרך כלל אני נמנע מסוגי רשומה אלא אם יש בשבילם סיבה חזקה. השתמשתי בהם כאן כי לפני Dynamic Forms, סוג הרשומה בחר את פריסת הדף (page layout), ופריסה אחת הציגה את שדות ה-ERP לקריאה בלבד. עם Dynamic Forms, כללי נראות יכולים להציג ולהסתיר שדות לפי ערך של שדה, שדה יכול להיות לקריאה בלבד בדף מסוים, ו-Salesforce עצמה אומרת ש-Dynamic Forms מצמצמים את מספר פריסות הדף וסוגי הרשומה שאתם צריכים (Break Up Your Record Details with Dynamic Forms (opens in a new tab); Required and Read-Only Fields in Dynamic Forms (opens in a new tab)). אבל קריאה בלבד בדף היא קריאה בלבד בדף הזה: ה-API, טעינת נתונים או אינטגרציה עדיין יכולים לכתוב לשדה. האכיפה האמיתית היא אבטחה ברמת השדה או כלל אימות; אימות בממשק המשתמש הוא לא אימות נתונים (פרק 3, יחידה 9). סוגי רשומה עדיין מצדיקים את מקומם כששני סוגי החשבונות צריכים ערכי רשימת בחירה או תהליכים עסקיים שונים. מה שכן חשוב הוא ששדה כלשהו יאמר בבירור מאיפה הרשומה הגיעה: מפתח ה-ERP עצמו, דגל של נתוני אב, או רשימת בחירה של מקור. ואז הניעו את אפשרות העריכה מהשדה הזה.

Click to enlarge

מזמני למנוהל: המכירות מתחילות למכור מיד; רק התהליך הסמכותי הופך את הרשומה למנוהלת.

מגינים על הרשומה המנוהלת

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

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

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

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

כפילויות מצטברות. תפסו אחת לפני שהיא נוצרת וזו בעיה קטנה. מצאו אותה שנתיים אחר כך, עם הזדמנויות, פניות, אנשי קשר, חשבוניות, אינטגרציות ואנליטיקה שתלויים בשתיהן, וזו בעיה גדולה. יחידה 7 בפרק 3 כיסתה את המנגנונים (כללי התאמה, כללי כפילויות, External IDs ייחודיים), אז לא אלמד אותם שוב. שאלת הממשל היא איפה אנחנו חייבים למנוע כפילות, ואיפה נסבול אותה ונפתור אותה אחר כך? ליד שיווקי מזדמן יכול לחיות עם עמימות. לקוח שמנוהל ב-ERP ויש לו תנועות כספיות לא יכול.

לתקנן את מה שמכונות קוראות

טקסט חופשי נהדר לאנשים ונורא כשמערכת צריכה לפרש אותו. שימו Arizona, AZ, Ariz., Phoenix area ו-Southwest בשדה שמניע ניתוב, ויש לכם בעיית איכות. אם ערך מניע אוטומציה, אינטגרציה, דיווח, אבטחה, הקצאה או פעולה של סוכן, חשבו היטב כמה תקני הוא חייב להיות. לא כל שדה טקסט הופך לרשימת בחירה, אבל הבחינו בין מידע שאנשים קוראים לבין מידע שמכונות מחליטות על פיו. השני ראוי לבקרה חזקה יותר.

אל תתנו לשדות חובה לייצר נתונים מזויפים

אנחנו מחליטים ששדה חשוב והופכים אותו לחובה. המשתמש לא יודע את התשובה, המערכת לא נותנת לו להמשיך, אז הוא מקליד N/A, Unknown, 999999 או test@test.com. השדה מלא; הנתונים זבל. לפני שהופכים משהו לחובה, שאלו אם המשתמש באמת יודע את זה בנקודה הזו. אם לא, דרשו את זה מאוחר יותר בתהליך, תנו למערכת אחרת לספק את זה, השתמשו במצב הזמני, או הציעו Unknown מפורש כש”לא ידוע” היא תשובה לגיטימית. כלל אימות יכול לאכוף מדיניות. הוא לא יכול לגרום למישהו לדעת את מה שהוא לא יודע.

כל גבול של נתונים צריך החלטת איכות

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

Click to enlarge

כל גבול של נתונים צריך החלטת איכות.

נתונים היסטוריים הם סיפור אחר

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

מודדים את מה שמישהו יפעל לפיו

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

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

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

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

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

להרחבה

• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (באנגלית, נבדק ב-2026-10-14).
• Salesforce Help, Break Up Your Record Details with Dynamic Forms (opens in a new tab) ו-Required and Read-Only Fields in Dynamic Forms (opens in a new tab) (באנגלית, נבדק ב-2026-10-14).