top of page
היבטי ניהול
היבטי ניהול
ניהול דרישות
ניהול דרישות
מודל נתונים לוגי
מודל נתונים לוגי
הגדרת תהליכים
הגדרת תהליכים
חוקים עסקיים
חוקים עסקיים
ממשק משתמש
ממשק משתמש
UML
UML
BABOK
BABOK
QA
QA
קורסים
קורסים
אתרים
אתרים
הומור
הומור

איכות נתונים

מבוא לאיכות נתונים

הסבר: בעיות באיכות נתונים:

  • נזק של 600 מיליארד דולר נגרם למשק האמריקאי עקב איכות נתונים ירודה

  • 20-35% מההכנסות התפעוליות הולכות לאיבוד כתוצאה מהשקעה בתהליכים מיותרים שנבעו מאיכות נתונים לקויה

  • 60-70% ממערכות ה CRM אינן עומדו בציפיות:הסיבה איחוד נתונים ממספר מערכות

  • 80% מעלויות בנית מחסן נתונים(Data Warehouse) כרוכים בממשק בין המערכות התפעוליות ומחסן הנתונים:

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

לפי GIGO, ברור שכדי לקבל תוצאות טובות, צריך לנקות/לטייב קודם את הנתונים.

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

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

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

מכיון שכל נתוני ה BI נגזרים מהנתונים התפעוליים, המשמעות היא שבכל פרויקט חדש בתחום ה IT יש להקפיד בצורה נחרצת על איכות הנתונים(Data Quality) אחרת כל פרויקטי ה BI שיבואו בהמשך יסבלו מ GIGO!!

כדי להגיע לאיכות נתונים גבוהה יש לבנות מודל נתונים איכותי שנתמך בתהליכים שלא מאפשרים כניסת "זבל" למערכת

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

מאמר: הממדים של איכות הנתונים

ניתן לבדוק איכות נתונים באמצעות 7 מדדים

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

מודל הנתונים כולל מספר רב של מאפיינים

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

דוגמאות קלסיות: תאריך לידה, תאריך הזמנה, תאריך הפקדה, תאריך תחילת קורס...

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

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

דוגמא אופיינית: תמונה ללא תאריך. לתמונה יש כמובן ערך, אבל ללא תאריך יצירת התמונה, ערך התמונה יורד-מה המשמעות של תמונת עובד שצולמה לפני 20 שנה?

דוגמאות נוספות:

  • דרגה או תפקיד של עובד , ללא תאריך שינוי הדרגה/התפקיד

  • עדכון כתובת ללא ציון תאריך עדכון אחרון

  • עדכון מחיר של מוצר ללא ציון תאריך השינוי

  • עדכון קבועי מערכת כגון מע"מ, או אחוז הנחה לאזרחים ותיקים ללא ציון תאריך העדכון

  • הצגת פרטים על ספר ללא ציון תאריך פרסום הספר

​בקיצור, אחת הבדיקות החשובות הן בתהליך הבניה והן בסקר מודל הנתונים צריכה להיות בדיקה מקיפה של הצורך בתאריכים/תקופות בכל תתי הישויות כולל טבלאות ה LUT

מאמר: מה זה טיוב נתונים

מחבר: חברת דאטה מדיה

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

מאמר: מתיעוב נתונים לטיוב נתונים

מחבר: חברת דאטה מדיה

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

מאמר: איך לטייב נתונים בחוכמה

מחבר: PcOn

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

מאמר: שימור לקוחות על ידי הקשבה לנתונים

מחבר: חברת דאטה מדיה

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

מאמר: התקן האירופאי להגנה על המידע GDPR

מאמר אנגלית: How is Bad Data Crippling Your Data Analytics

מצגת אנגלית: DQ Fundamentals

מאמר אנגלית: Defining Data Quality Dimensions

מאמר אנגלית: Seven Dimensions of Data Quality

מאמר אנגלית: Data Quality Rules

מאמר אנגלית: Create your ideal data quality strategy

מאמר אנגלית: Why DQ Is Essential for AI and Machine Learning Success

ספר אנגלית: Data Quality Rules for State-Dependent Objects

הסבר: התפקיד המיוחד של סטטוסים במודל הנתונים

לכל ישות/תת ישות/Lut מומלץ להוסיף כמעט באופן אוטומטי מאפיין סטטוס

במערכות מידע עסקיות צריך להיזהר מביטול פיסי של מופעי ישויות/תת ישויות/Lut

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

דוגמא 2: Lut של יישובים. אם יישוב מסויים לא קיים יותר( למשל יישובי גוף קטיף) האם נמחקו אותו פיסית מהטבלה. התשובה לא. עדיף סטטוס עם ערך : ישוב פעיל/יישוב לא קיים יותר

דוגמא 3: ישות לקוחות. לקוח הפסיק לעבוד עם הארגון. האם נמחק אותו פיסית? התשובה לא. עדיף להשתמש במאפיין סטטוס עם לפחות 2 ערכים. לקוח פעיל ולקוח לא פעיל

הסבר: הגדרת שמות במודל הנתונים

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

אחת הטעויות הנפוצות של BA היא להגדיר שמות ללא פירוט מרכיבי השם

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

בעיות נוספות:

  • התעלמות משם אמצעי שנפוץ מאד בקהיליות מסוימות

  • התעלמות מתואר(ד"ר, פרופסור וכו'..)

  • התעלמות מסיומת: דרגה או מעמד, לדוגמא דרגה בצבא או מעמד ציבורי כגון שר.

​כדי להגיע לאחידות מומלץ להגדיר Object Value:

נתונים

אז שם מרצה יוגדר כדלקמן:

מרצים

מסך קליטת פרטי השם עשוי להיראות כך(לקוח מ Outlook):

מסך קליטת פרטי השם

הסבר: הגדרת טלפונים

טלפון מופיע במספר רב של ישויות /תת ישויות

השגיאות הנפוצות שמבצעים BA בהגדרת טלפון הינם:

  • שוכחים שלעתים יש גם קשרים עם חו"ל, לכן צריך קידומת מדינה

  • שוכחים מספר שלוחה וגורמים למשתמש לחכות זמן רב למענה של מרכזנית

  • שוכחים שיש מספר רב של אנשים/ארגונים שיש להם מספר רב של טלפונים/פקס

​הפתרון הנכון:

1. להגדיר מספר טלפון כמושג (Object Value)

2. כדי לא להיקלע למצב שיש רק התייחסות לטלפוו אחד, להגדיר תת ישות בשם אמצעי קשר

מסך להזנת טלפון

בדיקת מספר טלפון

הגדרת טלפון כמושג

מסך להזנת טלפון

הגדרת תת ישות אמצעי קשר

אמצעי קשר

הסבר: ספרת ביקורת

הדוגמא הקלסית של הוספת סיפרת ביקורת הינה ספרת הביקורת של תעודת הזהות

מהי הסיבה להוספה של סיפרת הביקורת?:

התשובה : מניעת שגיאות מהסוג של החלפת שתי ספרות רצופות.

החלפת שתי ספרות צמודות הינה שגיאת הקלדה אופיינית כאשר מקישים מספרים

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

במקום 204560789 הוא מקליד 204560879 אזי הוא יקבל הודעה שלא קיים מספר תעודת זהות כזה או ספרת ביקורת שגויה.

להלן תהליך החישוב של ספרת הביקורת

ספרת ביקורת

הסבר: סימונים

data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==

בישויות רבות נהוג לציין כל מיני סימונים שמפרטים את מהות הישות /תת ישות

לדוגמא: בהזמנת רכב להשכרה אפשר לציין מספר תוספות רצויות

על מנת לבנות מודל לוגי גמיש, מומלץ להגדיר את הסימונים כתת ישות נפרדת שתאפשר

להוסיף בעתיד סימונים נוספים ללא עדכון התוכנה

סרטון: What are the seven dimensions of quality

סרטון: Implementing effectve Data Quality

סרטון: DQ vs MDM

bottom of page