כולנו נוהגים לומר שידע הוא כוח. זה נכון בכל תחום – אבל על אחת כמה וכמה בעולם מערכות המידע. זה לא סוד ששליטה במידע – לדעת את תמונת המאקרו ויחד עם זאת לקבל את האפשרות לצלול ולרדת לרמת הפרט הקטן ביותר – היא הכוח של מנהלי ארגונים, מנכ"לים של חברות, CIO, מנהלי שיווק, מוצר, אופרציה – ובעצם בכל תחום. "דאטה נכון ומדויק הוא הכלי החשוב ביותר בידיו של מקבל ההחלטות", אומר אודי שויקי, ארכיטקט מערכות אנטרפרייז בסיילספורס.
כולם רוצים דאטה
ככל שהעולם משתכלל (ויחד עם זאת, מסתבך) אנחנו מייצרים הרבה יותר דאטה מבעבר – וגם צורכים הרבה יותר דאטה. לפי הדוח הזה, נגיע לצריכת נתונים של כ-180 זטא-בייט עד שנת 2025. רק לשם ההשוואה, ב-2020 הנתון עמד על 64 זטאבייט "בלבד". כלומר, גידול של פי שלושה בחמש שנים בלבד.
"כארגון, הנתונים האלה חשובים לנו יותר מהכל", אומר אודי. "כולם רוצים לאסוף נתונים – וכמה שיותר. להכיר את הלקוחות שלנו יותר ולהגיע לרמת פרסונליזציה גבוהה – לדעת את ההעדפות של כל לקוח ואיך אני יכול לחזק את הקשר בינו לבין הארגון שלי".
אך לצד הגידול העצום בדאטה, מתעוררות לא מעט שאלות: כיצד נוכל לשמור על כמויות הדאטה האלו? איך מגינים על הדאטה בעת משבר? כיצד שומרים על אמינות הנתונים ומוודאים זמינות גבוהה שלהם?
"כולנו שואפים לכך. אנחנו גם יודעים עד כמה זה לא פשוט. ואם נודה על האמת, רובנו לא שם".
אז מה חשוב שיתקיים כדי שנהיה מוכנים למשבר, כדי שלא נופתע וכדי שנוכל להגיב מהר? "לפני הכל, חשוב להבהיר שלא מדובר רק במשבר או בשעת חירום. אם אני רוצה להיות מוכן ולהגיב מהר לשינוים בשוק למשל, או לתחרות, אני צריך לאמץ את אותה האסטרטגיה – אני צריך נתונים, אני צריך שליטה, אני צריך ויזיביליות. בעיניי, יש שלושה עקרונות חשובים: זמינות, אמינות ואיכות הדאטה. כמובן, יש עוד הרבה עקרונות, קטגוריות או דגשים, אבל מבחינתי אלו הם העקרונות שבהם יש לטפל לפני הכל, ובהתאם לסדרי העדיפויות של כל ארגון וארגון".
עקרון הזמינות: דמוקרטיזציה של הדאטה
על פניו, "זמינות" נשמע כדבר ההגיוני והמובן מאליו: הדאטה שלי צריך להיות זמין עבורי ועבור הארגון שלי, אבל מאחורי רעיון הזמינות יש כמה רבדים מעניינים. אודי מציג ארבע שאלות שיש לשאול בהקשר זה:
- בתוך כמה זמן אקבל את התמונה המבוקשת? את החתך שאני צריך? כמה מהר אצליח לייצר סגמנט למטרה שאני צריך?
- האם הדאטה זמין לי מיד במקרה חירום? האם הוא יושב במקום נגיש? האם – כדי להגיע לדאטה – אני צריך לכתוב שאילתות מורכבות רק כדי לקבל ריספונס לא קריא או פלט לא ברור ב-CSV בגודל אסטרונומי? או שאולי ניתן יהיה לגשת ל-UI קל ונוח ולקבל גישה ויזואלית ופשוטה כך שאוכל לבצע כל חתך שארצה באמצעות קליקים בודדים עם העכבר?
- בתוך כמה זמן אתן שירות לכל המבקשים? בתור מחלקת מערכות מידע או מחלקת דאטה בארגון, ישנן מחלקות אחרות שתלויות בי. האם אדע לתת להן שירות מהיר בעת הצורך? כולנו יודעים מה קורה במצב חירום – שכולל לא רק מצב ביטחוני אלא גם תקיפת סייבר, התקפת כופר על הארגון או התמודדות עם תחרות שהגיעה ברגע מפתיע. ומה שקורה הוא כאוס, והכאוס מגיע עם עומס פתאומי ולא צפוי. במצב כזה, איך ניתן יהיה להעניק שירות לכל המחלקות שידרשו ממני דאטה? כמה זמן הם יצטרכו להמתין?
- שירות עצמי – האם לאפשר אותו? האם יש לי את הכלים לייצר מצב כזה בארגון? כמובן, שירות עצמי כולל לא רק את הזמינות של הדאטה, אבל העיקרון הראשי שלו הוא הזמינות. הרי איך שירות עצמי יוכל להועיל אם כל בקשה נענית אחרי יומיים? מי בכלל ירצה להשתמש בשירות כזה?
"יש עוד שאלות רבות שאפשר לשאול במטרה להבין את תמונת זמינות הדאטה שלנו בארגון, וחשוב גם לציין שלא כל שאלה תהיה רלוונטית לכל ארגון. אבל אלו הם היסודות", אומר אודי.
אז פרקטית, מה עושים? "אחד הפתרונות שאני מאוד מאמין בו הוא מהלך של דמוקרטיזציה של הדאטה. כאשר משלבים טכנולוגיה נכונה שמנגישה את הדאטה לכל דורש בהתאם להרשאות המתאימות, תפיסת 'דאטה לכולם' היא פתרון נהדר. ביישום נכון של תפיסת הדמוקרטיזציה של הדאטה אנחנו משיגים גם שירות עצמי, גם זמינות מיידית, גם מסירים את צוואר הבקבוק ממחלקת הדאטה או ה-IT וגם דואגים שכל מחלקה תקבל את הדאטה שלה כדי שהיא תוכל להתנהל עצמאית בכל מצב. ככל שאנחנו מסירים חומות ומפרקים מחלקות נפרדות (Silos) או איים של דאטה בארגון – ומעבירים את הדאטה הארגוני לפלטפורמה אחת, מתקדמת, זמינה, עם מודל הרשאות חכם – כך יהיה לנו קל יותר ליישם מדיניות של 'דאטה לכולם'".
עקרון האמינות: לסמוך על הדאטה
השפה האנגלית מציעה מילה מצוינת לתיאור העקרון הבא: Veracity. המילה מתארת לא רק "אמינות" אלא גם "אמת", "אותנטיות" ו"דבר-מה שאפשר לסמוך עליו". בכך היא מרמזת על רמת דיוק מרבית, ובמקרה שלנו: רמת האמינות הגבוהה של הדאטה.
ואם כבר הזכרנו את המילה "אמת", עולה מיד האסוציאציה של Single Source of Truth. כלומר, המקור לאמת הארגונית. "וזוהי לחלוטין אחת השאיפות שלנו כשאנחנו מדברים על אמינות", מסביר אודי.
אז אילו שאלות כדאי לשאול כדי לוודא שאכן נקבל את האמינות הגבוהה ביותר שנוכל להשיג? "גם במקרה זה הייתי שואל ארבע שאלות עיקריות", ממשיך אודי ומפרט: "נתחיל בשאלה הפשוטה: האם שתי שאלות זהות, ממקומות שונים ובזמנים שונים, ייתנו את אותה התשובה? אני נתקל בזה כל הזמן, ורבים מאיתנו מכירים את זה היטב. אם סמנכ"ל שיווק וסמנכ"ל כספים שואלים אותי כמה ממוצר X מכרנו בחודש שעבר, ולאחד אני עונה 300 ולשני 301, אז יש לי בעיה של אמינות המידע. מרגע זה אני מתחיל לחפור במחילת הארנב כדי לגלות מהיכן הגיע האחד הזה, או אולי, בעצם, לאן הוא נעלם? כי, מה האמת? 300 או 301?"
השאלה השנייה שיש לשאול היא: האם כל השכבות תואמות? הרי אם דשבורד כולל במבט מנכ"ל הוא מבט העל והסכימה הכוללת, השכבות שנמצאות תחתיו הן אלו שבונות את הדשבורד הזה, שכבה אחר שכבה. "חשוב לבנות אגרגציות טוריות, או אגרגציות מסתמכות – 'אגרציות של אגרגציות' – מאשר אגרגציות מקביליות", מוסיף אודי, ומסביר: "לדוגמה, מוקד השירות שלי מטפל בקריאות אחת-אחת ומאגד אותן לפי קטגוריות. כדי לתת למנהל השירות תמונה כוללת של כל הקריאות המטופלות – האם אני סוכם מחדש את כל הקריאות לפי קריטריונים ופילטורים או שאני סוכם את הסכימות שכבר ביצעתי עבור הקטגוריות? ככל שאתחיל להתפצל ולייצר אגרגציות מקביליות, אמצא בעיות אמינות במורד הנהר".
אז אפשר לטעון שאם טעית בסכימה באחת השכבות, "תסחוב" איתך את הטעות מעלה אל מבט העל (או מטה, במורד הנהר), לא? "זה נכון, ומסיבה זו אני מקים בקרות. וכך, במקרה שאכן נפלה טעות ועוד לא עליתי עליה, לפחות יש לארגון שלי תמונה אחידה ולא מספר תמונות שונות שיוצרות חוסר באמינות. וזה מחזיר אותי לנושא של Single Source of Truth".
השאלה השלישית היא: איפה יושב המאסטר? כלומר, מי הקובע? מי המחליט? רבים יחשבו כעת על ה-MDM Master Data Management – נושא שלם שעומד בפני עצמו. בעבר היינו פונים לאסטרטגיית ה-MDM שלנו כדי שתייצר לנו אמינות. אבל הימים השתנו, ואיתם גם הטכנולוגיה והתפיסה. כעת, השאלה "מי המאסטר?" של כל נתון היא עדיין נכונה, אבל עם ראייה מעט שונה.
"אני מציע להתייחס לכך באופן הבא: מי היוצר של הנתון ומי הצרכן שלו? רבים יסכימו שיכול להיות ששניהם ה"בעלים" של הדאטה. הרי שניהם צריכים לקבוע. לפעמים יצרן הדאטה יהיה בעל משקל גדול יותר ולפעמים צרכן הדאטה – אבל הם שניהם חשובים להחלטה הזו. ומעבר לכך, לפעמים גם יש יותר מצרכן אחד".
וכעת עולה השאלה הרביעית – שהיא אולי לא באמת שאלה, אלא יותר התבוננות: האם הארגון סומך על הנתונים שמסופקים לו? האם נוצרים תהליכים מקביליים, מעין דוחות צללים, כמו שרבים מאיתנו מכירים כ-Shadow IT?
"אם נרד לרמת התכלס, הרי השטח קובע – ואין כמו בדיקה תקופתית במחלקות השונות, אצל צרכני הדאטה, כדי לראות אם הם נותנים אמון בנתונים שאני מספק להם. אם אני מגלה שהם עובדים עם אקסלים למשל ואוספים נתונים באופן עצמאי, כנראה שאני לא מספק להם את השירות שהם מצפים לו. כלומר, הם לא סומכים עליי ועל הדאטה", אומר אודי, וממשיך אל העקרון השלישי, שלטענתו חושף פערים גדולים כמעט בכל ארגון שבו הוא מבקר.
עקרון האיכות: זה חשוב, אבל…
סביר להניח שרוב המשתמשים יתרכזו בעיקר בעיקרון האיכות. "לאורך השנים גיליתי שזה הופך להיות סוג של משימת החיים של צוותי הדאטה ב-IT, וזה לצערי קצת מעוור אותם אל מול התמונה הכוללת ושאר העקרונות. אז כן, ברור שאיכות היא עניין חשוב. בדומה לאמינות, גם האיכות תשפיע מאוד על השימוש של הארגון בדאטה שלו ועל היכולת לקבל החלטות. למעשה, איכות היא קריטית, אבל מה זה אומר 'איכות הדאטה'? זה הזמן לבדוק את ההבדל המעט מבלבל בין אמינות ואיכות".
אודי מסביר כי "לעומת אמינות – האם אני יכול לסמוך על הנתונים שאני מקבל – כשאני חושב על איכות אני שואל האם המידע ברור, רלוונטי, נהיר, מנורמל ומגיע בפורמט הנכון. חשוב להפריד בין אמינות לאיכות כי עם בעיות איכות, על אף הדעה הרווחת, אני והארגון שלי יכולים לעבוד. אמנם זה לא יהיה קל ונוח, אבל כל עוד המידע אמין – אני יכול לנהל ביזנס".
תוכל לתת דוגמה שתסביר את ההבדל? "נניח שטבלת טרנזקציות שלי מכילה תאריך ביצוע הטרנזקציה והיא כתובה בפורמט GMT עם תאריך מלא לועזי, פלוס שעה בפורמט 12 שעות, פלוס דקות ושניות ועשיריות השנייה, ולבסוף משורשרת גם חתימת איזור הזמן. כל זה לפעמים נרשם בשדה טקסט ולא בשדה תאריך ייעודי. האם זה נתון שאני יכול לעבוד איתו? האם אני יכול להציג שדה כזה להנהלת החברה? האם אני יכול לחשב על סמך זה מרווחי זמן? כנראה שכן, אבל המאמץ יהיה יקר מאוד, ואפילו בעלות-תועלת שלילית, אבל השעה תהיה נכונה ומדויקת!".
וחוץ מהסיבוך והזמן, יש עוד בעיות בזה? "אם אני צריך לחשב SLA על סמך שדה שכזה? מה יקרה אז? כעת יש לכך משמעות כבדה: חוזית ומשפטית. וזו רק דוגמה קטנה ופשוטה".
תוכל לתת דוגמה נוספת? ניקח למשל מערכת עם מידע דמוגרפי, שבה צריך לבחור קופת חולים לכל לקוח שלנו. ברוב המקרים – ואני רואה את זה לעתים קרובות – אצל רוב הארגונים נמצא רשימת קודים לקופות החולים ובצד, או שבאותה רשימה, יהיה גם המיפוי של אותם קודים לשמות הקופות. האם זה יעיל? האם זה סקיילבילי? מה שקורה הוא שעובדי החברות פשוט נאלצים להתרגל ולזכור את הקודים של קופות החולים. למזלנו, אין הרבה קופות בארץ, אבל ברור שזה לא התפקיד שלהם. זה תפקידן של מערכות המידע".
ואיך כל זה קשור לאיכות? "אם נמשיך עם הדוגמה הזו – נדמיין שמגיעה דרישה לנהל מאפיינים על קופות החולים האלה. איך אני עושה את זה עכשיו? איך אפלטר או אחתוך דוחות בהתאם למאפיינים האלו אם לא אתכנן נכון וחכם את מבנה הנתונים, וגם אשקיע בתיקון שלו כשעולה הצורך? במקרה זה, הייתי ממיר את רשימת הבחירה לטבלה חדשה, לבסיס נתונים אחר, לאובייקט אחר – לא משנה איך נקרא לכך – ומייצר הפניה וקישור מטבלת הלקוח. כל עוד לא אשקיע בתכנון נכון ובתחזוק נכון, אצור בעיות איכות נתונים".
אודי חוזר שוב לדוגמה של מעלה הנהר ומורד הנהר, ומסביר כי היא מתאימה היטב לסיטואציה שתוארה. "מה שאני עושה לא נכון במעלה הנהר, פוגש אותי שוב במורד הנהר. לפעמים עם השפעה כואבת יותר ועם קושי גדול יותר לתיקון. זה אולי לא נראה כך, אבל הרבה יותר קל לתקן בעיות איכות במעלה הנהר מאשר במורד הנהר".
להאזנה לאודי בפודקאסט פורצים דרך
