לאחרונה שואלים אותי הרבה אנשים מה ההבדל בין דאטה אנליסט מול מפתח BI.
או אפילו לאנליסט BI.
אז הנה מאמר שאמור לשפוך קצת אור על הנושא…
דאטה אנליסט מול מפתח BI – הכל התחיל עם בסיסי נתונים רלציוניים…
במהלך שנות ה-70 של המאה הקודמת הומצאה התפיסה של בסיסי נתונים רלציוניים.
לפי התפיסה הזו – היה אפשר לשמור נתונים של פעילות עסקית במספר טבלאות – עם קשרים ביניהן (מכאן המילה רלציוני – Relational).
מספר שנים לאחר מכן (אי שם בשנות ה-80), מישהו הבין, שאחרי שמתחילים לשמור נתונים בטבלאות – נוצר מאגר שאפשר להוציא ממנו דוחות ולהציג למנהלים ולמשתמשים בארגון בצורה יחסית פשוטה.
שימוש בנתונים הללו יוכל ליצור תובנות חדשות וידע, שיוכלו לשפר את תהליכי קבלת ההחלטות העסקיות בארגונים.
הם קראו לתפיסה – BI – Business Intelligence.
אבל למרות התפיסה היפה, המציאות התבררה כמורכבת יותר…
"יש בעיה בנתונים!"
מאחר ומערכות תפעוליות המבוססות על בסיסי נתונים רלציוניים היו עדיין דבר יחסית חדש, הם אפשרו למשתמשים הרבה מאוד גמישות, כנראה הרבה מדי…
הגמישות הזו גרמה להרבה נתונים שגויים או חסרים.
וכשרצו להשתמש בנתונים האלה בשביל לקבל החלטות – נתקלו בחוסר אמינות שלהם.
וזה הקשה מאוד על תפיסת ה-BI.
על הרקע הזה צמחה התפיסה של ERP – Enterprise Resource Management.
התפיסה תפסה תאוצה בשנות ה-90, ואפשרה בעצם לקחת תהליכים סטנדרטיים מבוססי סקטור עסקי, ולהטמיע אותם בהרבה ארגונים.
התוצאה הייתה הסדרה גם של התהליכים העסקיים וגם של הנתונים שנשמרו במערכות המידע.
רק לאחר שהנתונים האלה טויבו – אפשר היה להתחיל ליצור שכבה של דיווח, מה שאפשר לתפיסת ה-BI לתפוס תאוצה (בעשור הראשון של שנות האלפיים).
דאטה אנליסט מול מפתח BI – הפיצול
המשימה המשמעותית ביותר שנגזרה מתפיסת ה-BI היתה להנגיש את המידע למשתמשים בארגון בכלל, ולמקבלי ההחלטות – בפרט.
וכאן התחום התפצל לשתי גישות:
- גישת התשתית
- גישת הפתרונות הנקודתיים והמחקריים
גישת התשתית מתארת צורך ביצירת תשתית טכנולוגית בשביל להנגיש מידע מסוים להרבה מאוד משתמשים בארגון.
כמובן שהמידע הזה צריך להיות יחסית מאופיין וסטנדרטי.
גישת הפתרונות הנקודתיים באה מכיוון אחר, ומכוונת לרוב לשני שימושים עיקריים:
- מצד אחד – מתן מענה לצורך נקודתי שיש למשתמשים או למנהלים, שאינו קיים בדוחות הסטנדרטיים.
- ומצד שני – מתן מענה לצרכי מידע מעט יותר מעמיקים – כמו מחקרים סטטיסטיים ואנליטיים.
אני מניח שבשלב הזה הבנתם כבר את הפואנטה של המאמר – וההבדל בין דאטה אנליסט מול מפתח BI :
גישת התשתית הפכה למה שהיום נקרא BI.
וגישת הפתרונות הנקודתיים הפכה לאנליזת נתונים.
מלחמת העולמות
שתי הגישות האלה – של דאטה אנליסט מול מפתח BI (או אנליזת דאטה מול BI) – שונות מהותית אחת מהשנייה.
BI – מגיעה מעולם התוכנה. בעולם הזה הדברים חייבים להיות סגורים – מאופיינים וממומשים ב-100%.
אם זה לא המצב – המשתמשים פשוט יאבדו אמון במערכת ולא ישתמשו בה.
זו הסיבה העיקרית לכך, שהטמעת מערכות BI – כמו מערכות מידע בכלל – לוקחת כל כך הרבה זמן.
היא דורשת הרבה מאוד בקרות ובדיקות שהתוצאה אכן אמינה ועובדת כראוי – גם מבחינת אמינות נתונים, גם מבחינת ביצועים, הרשאות וכיו"ב.
אנשי BI עובדים עם SQL, ועם כלי ETL – Extract-Transform-Load – כלים שמטרתם היא פיתוח בסיסי נתונים ומימוש תהליכי נתונים. הם כמובן מתמקדים ברמת התשתית הטכנית, ופחות נכנסים לתוכן של הנתונים.
גישת ה-Data Analysis – מגיעה מהצורך היותר עסקי.
בעולם של משתמשים – הגישה שונה לחלוטין, ונגזרת מהתהליך העסקי הכי מייצג:
הלקוח שואל שאלה עכשיו בטלפון – והוא דורש תשובה "אתמול".
אם לא יקבל תשובה – הוא ינטוש, או אם מדובר בשיחת מכירה – הוא לא יקנה.
זה אומר שלמשך הזמן שלוקח להחזיר תשובה ישנה בחלק גדול מהמקרים חשיבות מהותית.
ולכן, לעיתים קרובות אפשר להתפשר על רמת הדיוק של התשובה – גם תשובות "בכיוון"/"בערך" הן אפשריות – ואפילו עדיפות.
ייתכן גם שלא תידרש כלל אוטומציה של המידע שנדרש – אלא רק שליפה חד פעמית.
המשמעות היא, שעבור צרכים כאלה לא בהכרח יכול להינתן פתרון ע"י גישת ה-BI, בעיקר כאשר מדובר על צורך חדש או נקודתי.
מקרה אחר הוא מחקרים מעמיקים על תופעה מסוימת – סטטיסטיים או אחרים.
מחקרים כאלה כבר מצריכים בהרבה מקרים נתונים שלא נכללים בתשתית ה-BI, ונדרש לאפיין אותם.
במחקרים כאלה לא ניתן לדעת מראש מה תהיה התוצאה – ולכן גם לא ניתן לאפיין אותם מראש עבור הפקת דוחות.
זה מחייב עבודה אנליטית מסיבית ומותאמת – Custom – וזה כמובן לא מתאים לגישת ה-BI.
גם אנליסטים עובדים עם כלים לאחזור נתונים כמו SQL, אבל בשונה מאנשי ה-BI – הם נכנסים בעיקר לתוכן של הנתונים ומבצעים שליפות. הם לא מפתחים תשתית.
לסיכום:
אנליזה של דאטה היא כמו יחידת קומנדו:
מבצעת 'מבצעים מיוחדים' ומאתגרים שאמורים לתת 'ניצחונות קטנים'.
BI היא כמו גדוד חי"ר: מתאים למשימות גדולות, שאמורות ליצור מציאות מסוימת ולשמור עליה.
שניהם כמובן נדרשים וקריטיים להצלחה של הארגון.
רגע – אבל מה עם אנליסט BI?
אז כאן כבר מתחיל להיות מעניין, כי אנליסט BI אמור להיות קצת משני הצדדים. וזה לא פשוט…
מצד אחד – ליצור תשתית טכנולוגית, ומצד שני לתת פתרונות מהירים.
והאמת? ברוב המקרים זה לא ממש אפשרי, כי יש אוריינטציה אחת מובילה – או BI או פתרונות נקודתיים.
אז כשאתם נתקלים בתפקיד כזה – חשוב להבין היכן הוא יושב:
ביחידת ה-BI (שם לרוב הוא יממש דוחות יחסית פשוטים בכלי BI);
או ביחידה האנליטית (ושם לרוב הוא לא יפתח תשתית טכנולוגית).
חשוב להכיר את זה ולבחור בצד שיותר מושך אתכם.
שביל הזהב
העולם היום הוא הרבה יותר טכנולוגי, והרבה יותר מהיר ממה שהיה פעם.
זה גורם לארגונים לדרוש וליצור הרבה יותר תובנות בהרבה פחות זמן.
לכן – קפיצת המדרגה הבאה כנראה תכלול שיתוף פעולה הדוק יותר בין הגישות של BI ו-Data Analysis.
לשלב את הטוב משני העולמות:
מצד אחד – יכולות האפיון, המחקר והתוצר המהיר של האנליסטים.
ומצד שני – היסודיות ויכולת המימוש של אנשי ה-BI.
וכמו שכבר הבנתם – זה לא יקרה אם רק נקרא לזה 'אנליסט BI'…
דאטה אנליסט מול מפתח BI – אז איך כן משלבים כוחות?
זוהי שאלת מיליון הדולר…
זה האתגר שכאשר ייפתר – יאפשר להרבה מאוד ארגונים ליצור הרבה יותר תובנות ממה שיש להם כיום.
נכון להיום עדיין לא הצליחו לפתור את האתגר הזה בצורה מובנית.
אבל כנראה שהדרך לשם מתחילה קודם כל בלהבין מה כל אחד מהצדדים עושה – וזה בדיוק מה שהתחלתם לעשות במאמר הזה…
נהנית מהמאמר ויש לך עניין בלהפוך לדאטה אנליסט? מעולה!
הצעד הבא הוא לעשות את "עבודת ההכנה" עליה דיברנו – ולהירשם למשדר מיוחד בנושא:
'10 הטעויות שמחריבות לך את הסיכוי להפוך לדאטה אנליסט'.
זה משדר חובה לכל מי שמתחיל לשקול קריירה בתחום – הוא יכול לחסוך לך חודשים של תסכול והתברברות בגלל בחירות לא נכונות – רק בגלל "שלא היה לך את מי לשאול".
וכמובן בגלל שמי שרוצה להיות Data-Analyst – צריך לסגל הרגלים נכונים;
וההרגל הראשון הוא קודם כל לאסוף דאטה – ורק אז לקבל החלטות…
בהצלחה!