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

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

א. מהם המוצרים של החברה? האם אנחנו מייצרים, משווקים ומוכרים אותם בקצב הנכון לנו?

ב. מהם ההבדלים המרכזיים בין החברה לבין המתחרים? מהו ה-Secret sauce של החברה והאם ניתן למדוד משהו שקשור אליו?

ג. מהם הפרמטרים העיקריים והמדידים בשרשרת הייצור של החברה?

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

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

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

שכבה חשובה נוספת היא שכבת הצגת הנתונים (Data servicing)

 אנליסטים מיומנים יעבדו ישירות מול בסיסי הנתונים בהם נמצא המידע לאחר שעבר עיבוד (Data warehouse) ויכתבו שאילתות ע״מ לענות על שאלות שקיבלו ממנהלים, Product managers ועוד. לעומתם, משתמשים רבים אינם יודעים כיצד לכתוב שאילתות (לרוב בשפת SQL) והם זקוקים לכלי ויזואלי פשוט, מהיר ונוח ע״מ לנבור בנתונים ולהוציא את התובנות להם הם זקוקים. בחירת כלי הנגשת הנתונים (Data visualization tool) היא בחירה קריטית לחברה, משום שאיכות והתאמת הכלי יקבעו לעיתים האם ובאיזו מהירות הדרגים השונים ייחשפו לתובנות בנוגע לחברה. סיבה חשובה נוספת היא ה-Vendor lock - ככל שעוד ועוד דו״חות נכתבים ע״ג כלי מסוים, כך יהיה יותר קשה לעבור לכלי אחר בעתיד. ברוב המוחלט של המקרים המעבר מכלי לכלי הוא ידני ואין כלים אוטומטיים ע״מ לבצע זאת.

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

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

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

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

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

אחת ההחלטות הראשונות והקריטיות של מחלקת ה-Data בתוך הארגון היא ארכיטקטורת תהליכי המידע

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

אופציה מודרנית יותר היא בניית Contract בין מערכות המקור לבין מערכות ה-Data ושליחת אירועים (events) בדומה לעבודה עם APIs. האופציה הזו מפחיתה משמעותית את הצמידות בין המערכות אך מכבידה בהתחלה על המפתחים משני הצדדים, שכן יש לפתח את הארכיטקטורה הזו.

ישנן ארכיטקטורות המשלבות את השניים והרבה נוספות שלא ניכנס אליהן במסגרת זו.

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