סיכום ועיבוד- מוריה לוי
הספר, Business Intelligence for Dummies, הינו ספר בסדרת ספרי הלימוד לכאלו שאינם מומחים, אך בהחלט מומלץ גם למומחים. הספק סוקר את כל עיקרי הבינה העסקית (BI) מן המסד ועד הטפחות, כולל, לסקרנים, סקירת התפתחות היסטורית, כולל גם ניתוחי מותגים, וכל היבט אחר שניתן להעלות על הדעת.
סיכום זה כולל התייחסות להיבטים המעשיים של בינה עסקית, ופחות להיבטים אחרים. הספר אינו מפרט את עולם מחסני הנתונים (Data Warehouses) למרות הממשק הצמוד בין מחסני נתונים ובינה עסקית. כל זאת, מקוצר היריעה (מדובר בספר של מעל 350 עמודים). מה שמעניין- שהרבה מההיבטים הניהוליים והפרויקטאליים היו יכולים להיכתב מילה במילה בספר ניהול ידע. להלן עיקרי הספר:
|
|
|
מפת הספר
הספר כתוב באופן מקיף, מדויק ופשוט, והינו בהחלט קל לקריאה. מומלץ לכל מי שמבקש להכיר את עולם הבינה עסקית יותר מקרוב. מומלץ גם למי שעוסק בתחום כמקור לידע מארגן או לטובת הכנת הדרכות. שווה קריאה גם למי שעוסק בניהול פרוייקטים ופרויקטי ניהול ידע בכלל.
קריאה מהנה!
|
מבוא: מהי בינה עסקית
בינה עסקית מוגדרת כתובנות עסקיות מדויקות, בעלות ערך, בזמן ומכוונות לפעולה, ובתהליכים וטכנולוגיות המאפשרות השגתן.
יש לשים לב לארבעת המרכיבים בהגדרה:
מדובר במהלך מחזורי של שיפור מתמיד של פעילויות BI, שימוש בנתונים ומידע, מדידה והפקת לקחים.
פירוט התהליכים והטכנולוגיות- בפרקים הבאים.
סוגיות מרכזיות בהקמת פעילויות BI:
1. BI ארגוני ריכוזי או מחלקתי מבוזר
ההמלצה היא להתחיל בפעילות ראשונה מחלקתית, ממוקדת, ורק לאחר התנסות לעבור למענה ארגוני.
2. BI תומך החלטות אסטרטגיות או תמוך החלטות טקטיות
אין המלצה חד משמעית, והתשובה תלויה ארגון. אם הארגון מבוסס על תנועה (traffic)
עדיף להתחיל ברמה הטקטית תפעולית, כי שם יתכן ערך מוסף עסקי משמעותי.
סוגיות נוספות (קריטיות פחות):
3. ידידותיות למשתמש או כלים חזקים (למרות מה שהספקים טוענים- יש מתח בין השניים)
ההחלטה צריכה לנבוע מהצורך העסקי העיקרי של המשתמשים.
4. דו"חות או חיזויים אנליטיים
אין המלצה.
תובנות כלליות:
1. BI הינו בה במידה אמנות כמו מדע.
2. לא נכון לחשוב יותר מידי טכנולוגי; לא לחשוב רק אנשים.
3. הספקים ימכרו לכם במילים יותר מאשר יספקו בפועל. אל תופתעו.
חזרה
|
סוגי פתרונות BI
דו"חות
שאלה שתמיד נשאלת לגבי דו"חות היא מה ההבדל בין כלי דו"חות (Reporting)
לכלי תשאול (Querying).
השורה התחתונה היא שכיום אין הבדל; הספקים אחדו את שני סוגי הפתרונות דנן.
במקור, אגב, כלי תשאול שימשו לבירור נתון אד-הוק, בעוד דו"חות התאימו לצרכים קבועים ולכן נתנו דגש גם על הנראות של התוצרים.
פונקציונאליות הכלים כוללת:
הגדרת שאילתות SQL ודרך מסכים מנחים (כל משתמש כפי רצונו)
יכולות מתקדמות שיש בחלק מהכלים:
-
התאמת הדו"ח לגודל הדף באופן אוטומטי (adaptive authoring)
-
הצגת דו"ח עם נתונים עדכניים (שרועננו), כל פעם שפותחים את הדו"ח מחדש
-
תרגום אוטומטי של שאילתא לדו"ח מותאם שהוגדר מראש (interactive reporting)
-
יכולת התראה
המאפיינים החשובים ביותר של כלי דו"חות הינם:
-
קלים לשימוש
-
מבוססי WEB
-
מהירים (יש לזכור שמחסני נתונים גדולים עד מאד)
-
התוצרים ניתנים להעברה הלאה (למשל ל- Excel)
-
מאפשרים Drill Down דרך הדו"חות וכך חושפים את המידע בהדרגתיות
-
גמישים: ניתן להריצם באופן קבוע, ניתן לקבל התראות על פי תנאים.
משמש מגוון קהלי יעד:
משתמשי Power: מפתחים ומנהלנים (המכינים דו"חות לאחרים); מומחים.
חזרה
|
OLAP
OLAP, או בשמו המלא Online Analytic Processing הינו יישום Online המאפשר הצגת הנתונים המעובדים באופן אינטראקטיבי.
בדרך כלל הכוונה לדו"חות המוצגים Online, המאפשרים צלילה פנימה, ו/או הסתכלות חלופית על ממדים שונים של אותם נתונים. למשל- הצגת נתוני מכירות על פי מוצר; מעבר להצגה לפי זמן; מעבר להצגה לפי מדינה; צלילה לתוך אזורים, מעבר קל בין אזורים וכו'. מובן שניתן להציג בו זמנית על פי שני ממדים (והמהדרים אפילו מציגים שלושה) אך מעבר לכך מתחייבת החלפה ומיקוד כל פעם בחיתוך חלקי אחר.
תצוגות המידע בממדים רבים ומשתנים נקראת גם "קובייה" המסמלת את ההסתכלות התלת-ממדית.
ברמת הארכיטקטורה, ניתן לתמוך בצורך שכזה עם מספר חלופות:
1. MOLAP: מסד נתונים ייחודי רב ממדי (M- Multi).
2. ROLAP: מסד נתוני טבלאי, המממש באופן מושטח את הממדים השונים (R- Relational).
3. HOLAP: מסד נתונים משולב (H- Hybrid).
מושגים חשובים ב- OLAP:
· Dimension- מימד: נקודת מבט דרכו בוחנים את הנתונים. דוגמאות: מקומות, זמן.
הערה- ממד יכול להיות בכמה רמות, לדוגמא: זמן: שנה-חודש-יום
· Measure- מדד: נתון כמותי שמוצג בטבלה. דוגמאות: הכנסה, רווח.
ב- ROLAP מוחזק בטבלאות הנקראות Fact tables.
· Consolidation- שילוב ואיחוד (נקרא גם Drill up): עלייה ברמת המימד ובחינת נתונים סיכומיים.
דוגמא: מעבר מהסתכלות על חודשים להסתכלות רבעונית על אותם הנתונים.
· Drilling into- צלילה והעמקה. ירידה ברמת המימד ובחינת נתונים מפורטים יותר.
דוגמא: מעבר מהסתכלות על מכירות בערים להסתכלות על מכירות בכל חנות.
· Pivoting- הסתכלות רב כיוונית. בחינת אותם נתונים מכיוונים שונים
(כמו ב- Excel).
למתעניינים: לפני עשור נקרא תחום זה EIS- Executive Information Systems- מערכות מידע למנהלים.
חזרה
|
Dashboards
Dashboard, או בשמו העברי, לוח מחוונים, הינו שם שמקורו בתא הטייס הכולל אין ספור מחוונים לידיעה ולפעולה. פתרונות ה- Dashboard שהתפתחו מעולם ה- EIS הינם מסכים אינטראקטיביים המתארים באמצעות מחוונים מסוגים שונים, כפי שיפורט בהמשך, את תמונת הארגון, ומאפשרים למנהל לדעת את השורה התחתונה, תוך הצבעה והתרעה לחריגים (המחייבים ידיעה או טיפול).
כדי לתת תמונה ארגונית, מושתתים ה- Dashboards על KPI's
(Key Performance Indicators),שהינם מדדי מפתח לביצועי הארגון. לעולם לא ניתן למדוד כל דבר, אך המדידה בהחלט מייצגת, אם מתוכננת נכון. הדבר דומה לתעודת בית ספר, שאינה מייצגת את כל היבטי התלמידות, אך בהחלט תמונה לא רעה על הילד.
ה- KPI's ראוי שיהיו ממוקדות דיין כדי שאפשר יהיה לנתח מה מקור בעיה ארגונית/עסקית אם קיימת ולטפל
בה, אך כלליים מספיק כדי לתת תמונה ארגונית כוללת ועם זאת לא ללכת לאיבוד בפרטים.
דוגמאות ל- KPI's:
- זמן המתנה ממוצע של לקוח במוקד שירות.
- מספר הפעמים בשנה שהמלאי נגמר ויש להזמין חדש.
- אחוז היחידות הפגומות המיוצרות בחודש.
- ממוצע זמן מחזור מכירה.
- מכירות ביחס למ"ר רצפה בחנויות.
לוחות מחוונים יכולים להיות מספריים, אך בדרך כלל מבוססי צבעי רמזור ו/או חיצים (#$):
אדם מצביע על בעיה; צהוב/כתום על איזור בין לבין; וירוק על מצב תקין.
הצבעים יכולים להיות חלק מרמזור מלא, חלק ממחוון כמו מד דלק, או עיגול בצבע הרלוונטי.
מאפיינים חשובים של לוחות מחוונים:
1. התצוגות מאפשרות ניווט בין אזורי לוחות שונים.
2. הלוחות מושכים, ומאפשרים גרפיקה מגוונת.
3. הלוחות אינטראקטיביים.
4. ניתן להתאים את הממשק לארגון ולקבוצת המשתמשים המהווה את קהל היעד.
5. מאפשרים שילוב של תכנים חיצוניים יחד עם הנתונים הארגוניים (לדוגמא- נתוני מניות).
6. בעלי ממשק WEB-י.
ניתן להקים Dashboards טקטיים, תפעוליים או אסטרטגיים, בהתאם לצורך הארגוני ולשלב פעילות ה- BI
הכוללת.
בן דוד קרוב של לוחות מחוונים הינם ה- Scorecards (כרטיסי ניקוד). מטרתם של אלו להראות באמצעות מדדים גרפיים קצב התקדמות לעומת מטרה ארגונית/עסקית מתוכננת.
גם ה- Scorecards נסמכים על KPI's.
חזרה
|
שיטות מתקדמות
כיום ישנם כלים נוספים המאפשרים העברת מסרים מבוססי נתונים למשתמש בשיטות מתקדמות, תוך אפשרות ניווט ויתר המאפיינים המתוארים בפרק ה- Dashboards לעיל
(ממשק WEB-י וכו').
כלים מקובלים יותר כוללים הצגות מרחביות שונות (spatial visualization) לרבות:
1. מפות גיאוגרפיות.
2. תצוגת רבדים.
3. מבנים גיאומטריים תלת ממדיים.
ועוד.
משפחה אחרת לחלוטין של כלים מתקדמים הינה כלי Data Mining (כריית הנתונים).
כלים אלו מבוססים על מספר אלגוריתמים מתקדמים המנסים לזהות תבניות (patterns) מתמטיים מסוגים שונים ולנבא על סמך העבר את ההתנהגות העתידית, או להציף מצרפי התנהגות שאינם נהירים לעין המתבונן, ללא תוכנה תומכת.
דוגמאות (מפורסמות בישראל- מ.ל.) כוללות:
- גברים צעירים הקונים בסופרמרקט חיתולים בסופי שבוע, קונים בסבירות רבה גם בירה.
- בתקופת הרמדאן יש צריכה מוגברת של חלווה ביישובים ערביים מוסלמיים.
המגמה החדשה ביותר המתפתחת בעולם ה- BI עוסקת בכריית תכנים ממידע לא מובנה (מסמכים). גם כאן מדובר לא על חיפוש יזום של המשתמש, אלא בזיהוי תבניות והצפת מידע שיכול להיות בעל ערך לארגון.
כל זה נכון לזמן כתיבת הדברים, אך סביר להניח שתהיינה שיטות מתקדמות נוספות...צריך רק לחכות.
[יש לציין שמשעת כתיבת הספר ב- 2008 הולך ופורח תת העולם האנליטי שקיבל כיסוי, אך פחות נרחב בספר - מ.ל.].
חזרה
|
תהליך המימוש
אסטרטגיה
נתחיל מהסוף- אין מתכון מוכן, ואין מתודולוגיה יחידה לפיה נכון לפעול. כל יועץ ושיטותיו הוא, כל ארגון, ומה שמתאים עבורה. כאשר ארגון נכנס לפעילות BI, מוצע לתכנן אסטרטגיית פעולה למימוש הארגוני.
תוכנית אסטרטגית תתייחס ל:
1. הערכה עסקית נוכחית: פונקציות עסקיות; תהליכים תפעוליים; נושאים כואבים / הזדמנויות.
2. הערכה טכנולוגית נוכחית: תשתית; כלים; ממשקי משתמש; מדיניות ניהול הרשאות וניהול המידע.
3. תכנון התשתית הטכנולוגית החדשה:
החלטה מה מהקיים ישומר ויהפוך לחלק מהאסטרטגיה העתידית. החלטה ממה להיפטר/להתעלם.
החלטה מה להרחיב; והחלטה מה ראוי לרכוש.
4. תיאור חזון ה- BI (BI אוטופי) בארגון: תשתית טכנולוגית; ניהול נתונים; ותשתית עסקית. הכותב ממליץ לא לקפוץ על שלב זה, למרות שברור שלא ימומש, ככלי להגדרת הצלחות ושאיפות.
5. הערכת מכשולים אפשריים: אנושיים; מתודולוגיים; תהליכיים; טכנולוגיים; ופוליטיים ארגוניים.
6. בחינת חלופות והחלטה לגבי ישימות החלופות במצב הארגוני הקיים.
7. זיהוי סיכונים ודרכי התמודדות: סיכוני נתונים;סיכוני יישומים; סיכונים ארגוניים; וסיכונים תקציביים.
8. זיהוי הערך העסקי שניתן להפיק מפעילות ה- BI.
9. בחירת חלופה המתאימה למבנה הארגוני ותרבותו, ולוקחת בחשבון את הסיכונים והערך המוסף האפשרי.
10. גיוס התמיכה (Buy-in) בארגון.
בסיום האסטרטגיה תיבנה תוכנית ה- Roadmap לתחילת הפעילות:
1. הגדרת הבעיה העסקית ותיחום עסקי תוכני של הפתרון.
2. הגדרת המידע הנדרש לפתרון; הגדרת מיקומו ומצבו.
3. ניתוח תקציבי ראשוני, ו- ROI מוערך.
4. הגדרת על של דרישות החומרה לפרויקט.
5. הגדרת התוכנה התומכת הקיימת וזו שיש לרכוש לטובת הפרויקט.
6. הגדרת צוות הפרויקט ותחומי אחריות.
7. פירוט סיכונים, אילוצים ובעיות נוספות אפשריות.
כותב הספר צולל לכל סעיף ומפרט (לדוגמא- פירוט עלויות אפשריות, לטובת הערכת התקציב, או אפשרויות תיחום עסקי וקריטריונים להעדפה).
חזרה
|
תכנית הפרויקט
כמו כל פרויקט, גם פרויקט BI צריך להיות מנוהל.
על תכנית הפרוייקט לכלול:
1. משאבים
2. שותפים ובעלי תפקידים.
3. משימות: ברמת על, ברמת אבני דרך מפורטות, וכולל לו"ז.
4. קשרים ותלויות המשימות; אילוצים.
5. סיכונים ודרכי התמודדות (כולל תכנית המשכיות ונקודות בקרה).
המלצה חמה, אך לא טריוויאלית היא:
- לשמור את תוכנית הפרויקט עדכנית. התוכנית יכולה להשתנות בגלל שינויי תקציב, שינוי יעדים, אילוצים טכנולוגיים ו/או בגלל שינויים בהרכב הצוות. היערכו!
- לעקוב באופן יומי אחר מצב המשימות ורמת ההתקדמות (הן של התשומות, הן של התפוקות).
חזרה
|
איסוף דרישות
הציפייה שלנו היא שהמשתמשים יספרו לנו מהם צרכיהם העסקיים ובקלות נוכל לגזור פתרונות BI. המצב אינו כך בדרך כלל, וזו טעות משמעותית הגורמת להרבה קטסטרופות בתוצאות.
ראשית יש להבין שלא מדובר בטכנולוגיה, אלא בעסקים.
איסוף הדרישות ראוי שייעשה ברוח מתאימה ויכלול:
- תיחום מדויק
- הגדרת תפוקות
- פירוט דרישות עסקיות; תעדוף
- תהליכי עבודה ואופן השימוש במערכת ה- BI הצפוי בתהליכים אלו
- אופן ניהול דרישות משתנות ושינויי תכולה
- אבי טיפוס וצילומי מסך
- תרחישים לדוגמא.
על המנתחים העסקיים לדבר עם המשתמשים (על רמותיהם השונות) ועם בעלי החסות. מומלץ באופן נחרץ שלא לערב אנשים טכנולוגיים בשלב זה!
בשלב איסוף הדרישות יש לברר מול בעלי התפקידים אילו נתונים היו רוצים שיעמדו לרשותם כדי לבצע את עבודתם טוב יותר, ואיך כלי ה- BI יכולים לספק נתונים אילו באופן המיטבי.
באיסוף הדרישות, בבואנו להגדיר איך כלי ה- BI נותנים פתרון מיטבי, מתייחסים ל: דו"חות, גרפים, לוחות מחוונים ושימוש בשיטות מתקדמות.
יש לתת את הדעת בשלב זה, כמו גם בהמשך, לחשיבות ממשק המשתמש, נוחותו ופשטותו.
בסוף איסוף הדרישות יש שני תת שלבים סופיים:
8. תיקוף הדרישות (אל מול המשתמשים)
9. תעדוף הדרישות. מה יבוצע עתה, ומה יידחה להמשך.
חזרה
|
תכנון ופיתוח
המלצות מקדימות לתכנון:
1. זכרו שהצלחה אינה מובטחת והיא תלויה רבות דווקא בהטמעה.
2. היו ריאליסטיים בתכנון- תחמו.
3. התקדמו על פי דרישת המשתמשים; אל תרוצו מהר מידי, גם אם טכנולוגית אפשר.
4. פעלו על פי צרכי הטווח המיידי, אך תחשבו קדימה על צרכי הטווח הרחוק.
5. המשתמשים, יכולותיהם, רצונם ודרך חשיבתם הם שצריכים להנחות את מה שיתוכנן.
המלצות לשלבי התכנון השונים:
1. תכנון סביבת הנתונים:
א. נתחו-
• מה מקורות המידע ומה מצבם האיכותני; עד כמה הם נגישים לצורך BI.
• סוגי השאלות שהמשתמשים ירצו לענות עליהם; תבניות ייחודיות לדו"חות שיידרשו להם.
• דרישות ביצועים: עד כמה מהר יצפו המשתמשים לתשובות.
א. צוותו את האנשים המוכשרים ביותר שיש בצוות לתכנון תהליך יציב של ETL
(העברת הנתונים).
ב. אם נדרשת גמישות גבוהה בשאלות שתישאלנה, תכננו מסד יותר מנורמל עם מינימום
חזרתיות.
2. תכנון סביבת המשתמש:
א. דו"חות: ליבת כל פעילות BI
• תכננו מערך תוכנה מאפשר:
כלי להגדרת והפקת דו"חות; שירותי ניהול להרצת דו"חות, אחסונם והרשאות; פורטל דרכו
ייכנסו ויצפו בדו"חות.
אם יש משתמשים שצריכים דו"חות לא סטנדרטיים, יש לתכנן תת סביבה ייעודית עבורם.
• תכננו תבנית קבועה (Header, Footer) לדו"חות.
כללו גם הסתייגויות משפטיות, לוגו ארגוני ותאריך עדכניות.
ב. OLAP:
• זהו את המשתנים שיש לעקוב אחריהם ולמדדם; קבצו אותם לפי תחומים.
• הגדירו את הקשרים בין הישויות השונות. היעזרו במומחה כדי להגדיר את הממדים!
• הגדירו את הנוסחאות והגזירות לצורך הצגת קוביות ה OLAP.
ג. יישומים אנליטיים:
זכרו שלמרות מורכבות הפתרון, התוצר טוב רק במידה והנתונים איכותיים, המודל נכון
והדו"חות מתאימים לצרכים הארגוניים.
הערה- אין הנחיות תכנון מיוחדות ל- Data Mining ול- Dashboards.
ולפני סיום: אל תשכחו לתקף מול משתמשים; אל תשכחו לקיים בדיקות; ואל תשכחו שפיילוט הינו קריטי.
חזרה
|
תחזוקה ושיפורים
המלצות מקדימות לשלב התחזוקה והשיפורים:
1. למרות שכבר מקובל להבין שלא מספיק לשים תוכנה, לדאוג לתכנים ולהכין דו"חות ולקוות שיהיה שימוש. BI הינו תהליך ולא פרוייקט.
2. לאחר העלייה לאוויר תכננו שלב התנסות. התנסות אינה בדיקות, ובאופן טבעי תעלינה דרישות נוספות, ואפילו לא מעטות, שלא באו לידי ביטוי קודם. אל תילחצו; זה טבעי. תמיד היערכו לחלק ב לפרוייקט שכולל שיפורים.
3. מומלץ לבצע הפקות לקחים, הן בהיבט הפרוייקטלי הכולל, הן בהיבט הטכנולוגי והן בהיבט של ההשפעות וההשלכות העסקיות. אם הוגדרו מדדים/יעדים בהיבט העסקי- יש לבחון אל מולם. שימו לב, לא רק האם ניתן להפיק את הדו"חות הרצויים, אלא האם אכן יותר קל, זול ומהר להפיקם במערכת החדשה.
הדבר החשוב ביותר בשלב התחזוקה הוא להבטיח יציבות של המערכת במספר היבטים:
1. יציבות התוכנה; עדכניות גרסאות!!
2. יציבות נתונים; תחזוקת מסדי הנתונים וכיוונם מעת לעת.
3. יציבות זמני התגובה; מעקב וניטור קבועים להבטחת יציבות זו.
מעבר לכך,לטובת תחזוקה יש להבטיח כי:
1. הפתרון המוצע רלוונטי, לאור שינויים עסקיים שתמיד ישנם.
2. ישנה תמיכה לבעיות תפעול ותקלות.
3. ישנו מנגנון לקבלת משובים וניהולם.
4. ישנה הדרכה קבועה למשתמשים.
5. צוות ה- BI שותף לתהליכי קביעת סטנדרטים ומדיניות governance ארגוני.
6. יש קשר קבוע עם בעלי חסות בהנהלה.
שיפורים:
לאורך זמן ההילה של מערכות BI קטן. כדי לייצר התלהבות חוזרת ונשנית מומלץ:
1. להשלים ולתת פתרון לצרכים שלא נענו בשלבים קודמים.
2. לתת מענה מורכב יותר בתחומים עסקיים בהם ניתן פתרון ראשוני
(למשל- ניתוח אנליטי).
3. לשפר הנגשה.
4. להתקין גרסאות תוכנה חדשות וכלים מתקדמים.
5. להוסיף משתמשים.
אחת ל- 18-24 חודשים מומלץ לעשות סקר כולל לגבי השימוש, רמתו, ביצועים, ערך מוסף וצרכים.
חזרה
|
תשתיות
תשתית טכנולוגית: מוצרי תוכנה
כדי להקים סביבת BI נדרש להקדים ולהעמיד מחסן נתונים מרכזי (Data Warehouse), מחסנים קטנים מבוזרים (Data Marts), שילובים של הנ"ל [או הצגת נתונים ללא מקור נתונים מאחד- מ.ל.].
כחלק ממחסן הנתונים מקובל להקים Repository (MDM) המתאר לכל הנתונים שניתן להגדיר מעליהם דו"חות או תצוגות שונות את שמם, תיאורם, אפיונם, גורמים אחראים וחוקים עסקיים קשורים. כמו כן, נהוג לתאר לכל פריט מידע מתי נגזר, איך ומהיכן.
הכותב מתאר, נכון לשנת 2008, שנת כתיבת הספר, את כל ספקי התוכנה המרכזיים בתחומים הקשורים הבאים ומפרט יכולות של כל אחד ואחד מהם. תחומי הכלים:
1. מסדי נתונים
2. כלי שילוב נתונים (כלי ETL, כלי מחסני נתונים)
3. כלי תשאול, דו"חות וגרפים, לרבות OLAP
4. כלי כריית נתונים; כלי ניתוח אנליטי
5. כלי dashboards וכלי visualization נוספים
6. ממשקים (פורטלים וכלי גישה ל- mobile).
מעבר לכך יש לזכור כי ישנן טכנולוגיות משלימות לסביבת ה- BI:
-
ERP (מערכות ניהול המשאבים): אחד משלושת המקורות התפעוליים המרכזיים של הנתונים עליהם נשענים ובהם תומכים.
-
CRM (מערכות ניהול הלקוחות): אחד משלושת המקורות התפעוליים המרכזיים של הנתונים עליהם נשענים ובהם תומכים.
-
Finance: אחד משלושת המקורות התפעוליים המרכזיים של הנתונים עליהם נשענים ובהם תומכים.
-
[ניהול ידע (KM): טכנולוגיה משלימה המסייעת לתמיכה בקבלת החלטות. מ.ל.].
חזרה
|
תשתית אנושית: בעלי תפקידים
כל פרוייקט BI, בכל גודל ובכל תיחום מושפע מההיבט האנושי. ההתייחסות הנכונה להיבט זה חשובה לפחות כמו ההיבט הטכנולוגי, ויש לתת עליה את הדעת בהתאם.
בעלי התפקידים המרכזיים כוללים:
1. צוות ה- BI:
• מנהל פרויקט
• מנתח עסקי- Business Analyst- BA- אדם שלאו דווקא מתמחה ב- BI, אלא יודע לראיין
בעלי תפקידים עסקיים, להבין את צרכיהם, בכל תחום תוכן שהוא, ולהציע פתרונות BI
מתאימים.
קבוצה מוכשרת של BA's יכולה להוות את קפיצת המדרגה למימוש מוצלח.
• מעצב נתונים- Data Architect /Designer- DA- מומחה להבניית מסדי הנתונים ומבני
הנתונים השונים. אחראים להסבת הנתונים מהעולם התפעולי למחסן הנתונים.
לעיתים משמשים גם כאחראים לטיוב הנתונים, אלא אם יש בעלי תפקידים ייעודיים נפרדים
לארגון לכך.
בנוסף ישנם בעלי תפקידים תומכים-
• ארכיטקט תשתיות BI- אחראי למוצרי התוכנה
• מפתח יישומים
• DBA- מנהלן נתונים
• בודק תוכנה- איש QA
2. בעלי תפקידים בארגון:
• משתמשים
• מומחי תוכן
• מנהלים
• בעל חסות- מנהל בכיר המוביל ומלווה את הפעילות.
היבטים שיש לתת עליהם את הדעת בהיבט האנושי:
• הדרכת צוות ה- BI, פיתוח מומחיותו וטיפוחו.
מבנה ארגוני תומך (מבוזר במחלקות; מרכזי ב- IT; או, BICC- כולל בעלי תפקידים עסקיים).
• ניהול השינוי אל מול המשתמשים ומומחי התוכן
(כל טכניקות ניהול השינוי רלוונטיות לסעיף זה).
חזרה
|
עשרת הגדולים- 10 טיפים במגוון נושאים הקשורים במימוש בינה עסקית בארגון
10 מפתחות להצלחת בינה עסקית
10 המפתחות להצלחת פעילות בינה עסקית (BI) הינם:
1. בחירת KPI's שאכן יכולים לסייע בקבלת החלטות טובות יותר ושיפור ביצועים.
2. התאמת המתודולוגיות/מתכונים לצרכים הספציפיים של הארגון. לעולם לא להישאר עם פתרון
בי"ס.
3. הבנה שלמרות כל מה שהספקים ויועצים מספרים מדובר במסע מורכב, לא קל ולא פשוט.
4. חשיבה ופעילות מחוץ לקופסא.
5. צוות טוב- גם בהיבט המקצועי, אך לא פחות בהיבט האנושי.
6. המשך לימוד מתמיד במתודולוגיות, בכלים ובשיטות למימוש בינה עסקית.
7. תמיד יהיו כשלים וטעויות. החוכמה לזכור אותם ולהימנע מנפילה חוזרת בהם.
8. לקיחת התרבות הארגונית בחשבון, כבר משלבים ראשונים של הפעילות ואיסוף הדרישות.
9. פרוייקט מתגלגל. עדיף פעילויות קטנות יותר, שאפשר להוכיח כדאיותם, והתקדמות מדורגת.
10. אימוץ מנהל בכיר שיהיה בעל חסות מרכזית לפעילות.
חזרה
|
10 סיכונים ב- BI ודרכים להתמודדות
10 הסיכונים המרכזיים בפעילות בינה עסקית:
1. התנגדויות
דרך התמודדות אפשרית: בניית קשרים יציבים ומשמעותיים עם אנשי מערכות מידע, עם אנשי
המידע ועם שותפים נוספים. הקמת ועדת היגוי משותפת או מרכז מצוינות כמסגרת להחלת
רעיונות ושיתוף.
2. יעדים משתנים
דרך התמודדות אפשרית: קישור היעדים למערכות יעדים ארגוניות אחרות; חיפוש מתמיד של
השינויים, כדי לתת את הדעת האם נדרש שינוי BI מתאים
3. יתר ציפיות מכלי תוכנה ויישומים
דרך התמודדות אפשרית: הקטנת הסיכון בבחירת מוצרי התוכנה.בקשת הדגמות; עבודה עם
ספקים המצהירים גם על קשיי המוצרים שלהם; דיון עם ספקים על קשיים אצל לקוחות קיימים.
4. משתמשים לא עושים שימוש במערכת
דרך התמודדות אפשרית: שילוב אמיתי של המשתמשים בתהליך, גם אם צוות ה BI סובר
שהוא יודע מה צריך; מעקב סטטיסטי אחר שימוש לאיתור בעיות שימוש בשלבים ראשוניים
5. איכות נתונים בעייתית
דרך התמודדות אפשרית: הבנה שטיוב אינה משימה חד פעמית; מעקב מתמיד, ובמידת
האפשר איתור בעיות (ותיקונן) כבר בהעברת הנתונים למחסן הנתונים-ETL
6. תקציב חסר
דרך התמודדות אפשרית: לקיחת כל העלויות בחשבון מראש, עד כמה שניתן; לא לבצע
פרוייקט בכל מחיר.
7. תיחום גדל (תמיד יש עוד מחלקה/נתון/מידע שגם כדאי וחשוב להוסיף)
דרך התמודדות אפשרית: מלכתחילה- תיחום רחב והיערכות לשינוי; עבודה עם מנתחים
עסקיים מצוינים כדי לתכנן נכון. כאשר יש שינוי- ניהול השינוי על פי הספר (ולא בפאניקה).
8. היצמדות להחלטות ראשוניות (נובע מניתוח שהינו הרבה פעמים bottom-up)
דרך התמודדות אפשרית: היערכות לגמישות; הכללת כלים המאפשרים למשתמשים להוסיף
בעצמם מענה לצרכים נוספים בהמשך.
9. נפילה של הסביבה
דרך התמודדות אפשרית: אפשרות כניסה ישירה לכלים, לא דרך הסביבה הכוללת.
משום מה, למרות שמדובר בעשרות..יש רק תשעה סיכונים המוזכרים בספר.
חזרה
|
10 טיפים לאיסוף דרישות
10 טיפים לאיסוף דרישות טובות:
1. אנשים: ודאו שהאנשים שיכולים לתרום הכי הרבה הם נציגי המחלקות עמם אתם
נפגשים.
2. תיאום מוקדם עם מנהלים: תיאום מוקדם לתיאום ציפיות ולהאחדת נקודת ההסתכלות.
3. קשרו את נושאי הדרישות לנושאים המרכזיים בהם פועל הארגון והמעסיקים אותו.
4. ודאו שכל הדרישות מקושרות לנושאים המרכזיים לעיל.
5. הבינו היכן הקיים מספק, והיכן נדרש שינוי תהליכי. אל תמהרו להיכנס ליותר מידי
שינויים.
6. נסו להבין איך הארגון יכול להסתדר בלי הנתונים, אם תעדיפו לוותר על דרישה מסוימת.
יעזור לתעדוף.
7. כחלק מאיסוף דרישות בכל נושא בקשו להבין: מידע נדרש, מה מתוכנן לעשות עמו,
כיצד יעובד; יועבר, אילו תובנות יכולות להתפתח ממנו. האם ישנם צעדים מקדימים
מחייבים; מה בגדר "חובה".
8. ירידה לפרטים: לכל נתון נדרש בררו היכן נשמר כיום; כיצד ניתן לשלפו; מה מצבו;
השלכות במידה והמידע מטויב/מעובד. זכרו שלמחלקות שונות יש ראיה שונה, לפעמים
לאותם נתונים.
9. למרות שחשוב להיות ממוקדים, תכננו חזון. הוא בעל ערך!
10. ודאו לכלול תעדוף במסמך הדרישות. ודאו שייצג במשותף את היבטי הלקוח (מה חשוב)
והיבטי הפרוייקט (מה ניתן).
חזרה
|
10 טיפים להטמעה טובה
בכל פרויקט ברור שהטמעה הינה גורם קריטי להצלחה. במערכות שאינן תפעוליות (דוגמת ניהול ידע ובינה עסקית) האתגר לא פשוט, כי אנשים הסתדרו פעמים רבות גם ללא המידע והידע ומדובר בשינוי תרבותי.
להלן טיפים להצלחה בתהליך ההטמעה:
1. החלו את תהליך ההטמעה, בשלב מוקדם ככל הניתן.
2. היעזרו בספקי התוכנה. תידרשו להם, והחוזים כוללים הפעלתם- כך שלא אמור להיות
קושי בהפעלתם.
המוצרים המשולבים לא תמיד עובדים ביחד כפי שציפינו.
3. היעזרו בנציגי המשתמשים לא רק להבנת הדרישות, אם כי גם להתייעצויות ופתרון
קונפליקטים הקשורים בתוכן.
4. שיווק: אל תצפו שהלקוחות ידעו ויזכרו כנה הפעילות חשובה. ודאו שאתם דואגים שהנושא
יישאר בשיח הארגוני.
5. אל תוותרו על בדיקות התוכנה והמערכת כולה.
6. ארגנו חמ"ל (חדר מלחמה/ חדר מצב) בו תרכזו את הפעילות הראשונית עם העלייה
לאוויר.יש לכך משמעות תפעולית וגם משמעות סמלית.
7. נהלו את הפרוייקט; ודאו ניהול ובקרה כוללים.
8. התמודדו מיידית עם גרירת רגליים וסחבת. אל תתנו לזה להתפתח.
9. קיימו POC (Proof Of Concept- הוכחת יכולת) לפני כניסה לארגון כולו. הרבה קשיים
מתגלים בשלב זה.
10. אלוהים נמצא בפרטים הקטנים. ודאו טיפול בהם, למרות שהפיילוט חייב להיות קצר
ומהיר.
11. זכרו שהנראות והדו"חות קצה יכולים להשתנות וישתנו, אך ודאו שהנתונים ומבנה
הנתונים יציב וקשיח. אל תאפשרו שינויים מזדמנים ברמה זו.
ולכל אלו שעדיין ערניים- אכן פה יש 11 טיפים ולא 10. כנראה פיצוי על הפרק בו היה חסר טיפ...
חזרה
|
10 טיפים לסביבת BI בריאה
סביבת BI צריכה להיבנות באופן יציב ולהיות מוכנות לעמוד גם בשינויים שיהיו. להלן 10 טיפים לתכנון מקדים נכון של הפעילות:
1. ודאו איכות הנתונים: האם ברי שימוש? האם שלמים? האם לא סותרים זה את זה?
2. תחמו מראש את הפונקציונאליות, את מספר הספקים והתוכנות המעורבות
ואת כמות מקורות המידע. יאפשר לחרוג פחות בתקציב הפרוייקט (ואולי יהיה המפתח לשרידותו).
3. תכננו באופן זהיר אך קשיח את לוחות הזמנים לכל שלב; עמדו בהם, וזכרו לכלול בהם
גם זמני הדרכה והטמעה.
4. עשו שימוש חוזר בטכניקות שעבדו. אל תמציאו כל פעם את הגלגל מחדש.
5. גבשו תהליך קבוע ומתודולוגי ללמידה משגיאות (הפקת לקחים).
6. תעדו!!!
7. בשלב ראשון תמיד מוותרים על חלק. זכרו להשלים את החסר בגרסא הבאה.
8. ודאו שמבוצעים שדרוגי תוכנה באופן קבוע ועיתי.
9. נטרו פעילות ובחנו מה דורש שינוי.
10. תקשרו שינויים; אל תצפו שאנשים יתחילו לעבוד ללא דחיפה.
11. השקיעו הרבה בהדרכה; ספקים יגידו שאין צורך והתוכנות ברורות. התעלמו מהם- והשקיעו.
12. נהלו את התחזוקה כתהליך קבוע- שדרוגים, הדרכות, הכשרת אנשי צוות וכו'.
שוב גם כאן המספר 10 הוא יותר סמלי ממעשי. גם לא ברור למה דווקא הטיפים כונסו תחת רשימה אחת, לעומת הפרקים האחרים. בכל מקרה, בלי קשר למיקומם, הם נכונים ומסייעים, וראוי להתייחס אליהם.
חזרה
|
10 סימנים שסביבת ה BI בסכנה
למרות כל התכנונים, ולמרות כל הפעילות, ישנם דברים שיכולים להשתבש. להלן 10 דברים שיש לשים אליהם לב:
1. לא משנה כמה סביבת ה- BI מוצלחת, אנשים ממשיכים להשתמש בדו"חות מבוססי
Excel . מומלץ לנתח כל מקרה לגופו ולנסות לשנות.
2. לא משנה כמה הכל ברור, אנשים לא יבינו וישאלו שאלות. יש להיערך עם משאבים
מתאימים.
3. לעיתים אנשים לא מבקשים עזרה בכלל. יש להתייחס לכך כסכנה- ולחפש אם יש כלל
שימוש.
4. לעולם הסביבה פחות נגישה אינטואיטיבית ממה שציפינו. מומלץ לנתח ולשפר- בעיקר
בעיות שימושיות. התייחסו לשיחות הלא-פורמאליות כמקור נאמן למידע.
5. הבינו שתמיד העבר נראה נוסטלגי ומוצלח יותר. אם השיח לא עובר לאחר זמן, סימן
שמדובר בבעיה אמיתית.
6. תמיד סמוך להשקה יש יותר משתמשים. למרות זאת, אם סביבת ה- BI טובה, כמות
המשתמשים צריכה לעלות כל הזמן בהדרגה. אם הדבר אינו כך- נתחו וחפשו בעיה.
7. כלי BI אמורים להשתלב ככלי עבודה בתכנונים אסטרטגיים באופן קבוע. עקבו ובררו,
ואם אין הדבר כך, מדובר בסימן מדאיג המחייב טיפול.
8. מנהלים בכירים נותני חסות נוטים לאבד מהתלהבותם. אל תיקחו אותה כמובנת מאליה,
והשקיעו בהם לאורך זמן.
9. מנהלים בכירים נותני חסות יכולים לעזוב את הארגון. בנו רשת ביטחון.
10. לעיתים מצליחים לקבל תקציב לפרוייקט ראשוני, אך נתקלים בקשיים לקבלת תקציב
ההמשך. אם אכן כך, זימן שהפעילות בסכנה, ובררו למה הקיים לא מספיק מלהיב
וקריטי לעבודה כדי שיבינו שאכן נדרש להמשיך ולהשקיע עוד.
|
סיכום: בינה עסקית הינה הרבה יותר מפרויקט אך כדאי להתחיל בפרויקט; יש כלים רבים; יש טיפים רבים עוד יותר, המסייעים ליישם. מה שנשאר- זה להתחיל לממש. בהצלחה!
חזרה
|