העוצמה שבחולשה 6


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

בעזרת פנקס ועפרון אפשר לנהל מספר קטן של עובדים. כאשר כמות העובדים בארגון שלנו גדלה, הפנקס והעפרון כבר לא יספיקו, נצטרך לעבור לכלים ממוחשבים. כך עשו לפני כ-40 שנה כשהחליטו להקים את מאגר המידע המרכזי.
הבעיה היתה שכל המידע שנאסף עד כניסת המערכת הממחושבת, היה מידע של "פנקס ועפרון", הנייר כידוע, מוכן לקלוט הכל. לדוגמא – אין שום בעיה לכתוב על הנייר שתאריך הלידה היה ערב סוכות ותאריך העסקת העובד היא ב-30 בפברואר. אפשר גם לרשום בטופס שסימול קורס ריתוך חשמלי הוא 1234, וקוד זה בכלל לא קיים ברשימת הקורסים של המכללה, או לרשום את שם עיר הלידה בשגיאות כתיב – במיוחד כשמדובר על מקום בחו"ל, ויש דוגמאות רבות נוספות.

אמרתי בעיה?

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

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

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

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

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

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

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

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

כמובן שאם אין בכלל צורך במידע הלא תקין – אין סיבה לשמור אותו, לא בצורה כזו, ולא בצורה אחרת…


תגובתך בבקשה...

6 מחשבות על “העוצמה שבחולשה

  • שרון לביא

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

    • יעקב גלזר

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

  • מיכאל

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

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

    • יעקב גלזר

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

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

      אני מציע לא להקדים את המאוחר – פוסט על טיוב מידע יגיע בקרוב!!!

  • ליעד

    היי,
    קודם כל, אני מאד נהנה לקרוא את הבלוג, געגועי להבנת הנקר"א (שאף אחד לא באמת הבין חוץ ממי שכתב אותו),
    לעניין הבלוג – במערכות ERP עלות הפיתוח של שמירת המידע הלא מטויב (פיתוח מלא של הלקוח!), בדיקתו, ותחזוקתו לאורך שנים, עולה בכסף, לדעתי, פי כמה מטיובו, אם כי היא הרבה יותר קשה לנו (כי כולנו יודעים לפתח עוד שדה, אבל מי יודע לטייב נתוני כ"א???)