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

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

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

אמרתי בעיה?

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

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

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

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

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

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

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

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

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