מגמה חשובה בעולם ה-BI/DW

מאמר שכתבתי בנושא Big Data ו DW Appliances התפרסם בדמרקר:

לכולם ברור כי כמות הנתונים עמם ארגונים נאלצים להתמודד גדלה בכל שנה. הנה כמה מספרים המדגימים את הקושי: כמות הנתונים גדלה בכ50% בכל שנה, כאשר בשנים הקרובות שיעור הצמיחה יהיה גדול אף יותר, בשל הרצון להכניס למחסני הנתונים גם מידע בלתי מובנה, מעולם האינטרנט ורשתות חברתיות. במקביל, בסקר של MIT, 60% ממנהלים ציינו כי כמות המידע שעומד לרשותם גדולה מדי מכדי להתבסס עליו לצורך קבלת החלטות.

לתופעת הגדילה האקספוננציאלית של נתונים בארגונים קוראים כיום בספרות "big data" וזהו גם אחד הנושאים במחקר בתחומי ה-BI, למשל. בעקבות זאת, עלה טרנד חדש בעולם ניהול ואחסון הנתונים: קופסאות ענק (Appliances) שמנהלות כמות אדירה של נתונים. קופסאות אלה יחליפו את בסיסי הנתונים הקלאסיים המרכיבים כיום את מחסני המידע. הן מורכבות בתצורת "קופסאות שחורות", שמכילות חומרה, יכולות עיבוד נתונים מתקדמות (in memory processing, parallel computing, column-based computing), רכיבי ETL ואינטגרציית נתונים, וכן יכולות אנליטיות מובנות. הביצועים של קופסאות אלו הם מצויינים (פי 10-עד פי 100 מאלה של DW "קלאסיים").

היתרונות שבאימוץ קופסאות אלה - חוויית משתמש טובה, ביצועים טובים ולכאורה (אם נשארים "בתוך גבולות הקופסה") - עלויות תחזוקה נמוכות ו-time to market מהיר. חשוב לשים לב גם לחסרונות - העיקרית שבהן הגדלת התלות בספק מחשוב. בדומה לעידן ה-MF, בו ארגונים קנו קופסה באופן די דומה, בעידן ה-APPLIANCES אנו קונים הכל מספק אחד. לכן חשוב לנסות ולהגביל תלות זו עד כמה שניתן, לדוגמה - על ידי הכללת סעיפים לגבי רכש עתידי בחוזה.

ואכן, ספקים מזדרזים להיכנס לתחום ולבסס על מיקומם כמובילים - אורקל, יבמ, סאפ, EMC, HP ועוד, לצד ספקים ותיקים בתחום - טרהדטה, TM1 של יבמ. כמו כן, בשנה האחרונה שמענו על רכישות רבות בתחום והכרזות על מוצרים חדשים.

הקופסאות החדשות יהוו גם אתגר עבור החלוקה המבנית של מחלקות ה- IT. עד כה, מחלקות אלו עבדו בראייה של צוותים ולא בצורה רוחבית: צוות תשתיות, צוות אפליקציות, צוות אינטגרציה וכו'. אך מה קורה כשצריך לנהל וליישם קופסה שמכילה את כל שלושת רכיבים אלה? תחת איזה צוות הנושא יושב? האם יהיו צוותים חוצי תחומים שיטפלו ב-DW, ERP, CRM? מה זה אומר לגבי הכישורים הנדרשים מעובדי IT?

בעולם ה-BI, למשל, שבו ישנה הפרדה ברוב הארגונים בין צוות ה-BI ובין ה-DBAs, שיושבים תחת מחלקת התשתיות ומספקים שירותים לצוות ה-BI, כבר יש סימנים של שינוי. אם ניקח, לדוגמה, ספק APPLIANCE ותיק ומוכר - NCR TERADATA, נראה שבארגונים המפעילים טכנולוגיה זו כבר קיים שילוב: בד"כ ה-DBA של DW מבוסס טרהדטה, יושב במחלקת ה-BI ולא במחלקת תשתיות. זאת, לעומת ארגון בו ה-DW מבוסס אורקל/מיקרוסופט, בו ה-DBA יושב במחלקת תשתיות, שכן מדובר ביכולת כלל ארגונית ולא ספציפית לעולם ה-DW.

Presenation from STKI Summit 2010

Thanks for everyone who came to our summit. It was a great event!

And a big thank you to STKI clients and everyone who assisted us in conducting our annual research (answering surveys, brainstorming with us...)

I've uploaded my presentation to slideshare, you can take a look at it here:

2010 Enterprise Applications, BI & KM Trends

View more presentations from Einat Shimoni.

BI לנתוני SAP - רשמים משולחן עגול

בשולחן עגול בנושא BI לנתוני SAP בו השתתפו ארגונים משתמשי SAP, עלו הנושאים הבאים:

• שימוש ב-BW של SAP כ ETL מובנה לנתוני SAP: במפגש הייתה הסכמה כללית על השימוש הרצוי ב-BW כ'שער' לנתוני SAP. כלומר, גישה לנתוני SAP לא תתבצע ישירות מול ה-SAP התפעולי, אלא בכל מקרה הנתון יילקח מה-BW (עד כמה שניתן). השימוש ב-BW כשער גישה לנתונים הוגדר כ- Best practice. גם במקרה של ניתוח הנתונים שלא באמצעות כלי האחזור של BW, עדיין משתמשים ב-BW כמעין ETL מובנה. כמה ארגונים סיפרו כי הם מוציאים מידע מה-BW החוצה (באמצעות שימוש בכלי מובנה ב-SAP בשם Open Hub) בצורת קבצים שטוחים לדטהבייס חיצוני (אורקל, טרהדטה...) על מנת לנתח נתונים שם עם כלי אחזור שונים אליהם הארגון רגיל.
• סוגיה מרכזית שעלתה: היכן לבצע ניתוחים משולבים המשלבים בין נתוני SAP ונתוני Non-SAP? בשנים האחרונות מגמת שילוב כלי BI / DW / ETL מובנים בתוך חבילות אפליקטיביות (ERP, CRM, ניהול קמפיינים, תכנון תקציב וכד') הולכת וגדלה, מה שמכתיב ארכיטקטורת DW יותר מבוזרת (על פי סקר שערכנו, לכ75% מהארגונים קיים DW מרכזי, ולצידו – מספר דטה מרטים ייעודיים ל ERP וכד'). אולם מה קורה כאשר צריך לבצע ניתוחים משולבים, תוך שימוש בנתונים המגיעים מהDW המרכזי והן מהדטה מרטים הייעודיים? במפגש עלתה שאלה זו כסוגיה מרכזית – היכן מבצעים ניתוחים משולבים? שתי הדרכים האפשריות לניתוח משולב של נתוני SAP בשילוב עם נתונים ממערכות תפעוליות אחרות: העברת נתוני NON SAP ל BW; והעברת נתוני SAP ל-DW הארגוני. במפגש עלו דוגמאות לכאן ולכאן ולא הייתה המלצה חותכת לדרך נכונה אחת, משום שהדבר תלוי בארגון, באופן יישום ה-SAP ובמידת מרכזיותו בארגון. שני פרמטרים עיקריים היוו קוים מנחים לבחירה:
  1. המידה בה הארגון מבוסס SAP (בארגונים מבוססי SAP בהם % הכיסוי של האפליקציות על ידי SAP היה גבוה, הנתונים הועברו ל-BW). אם ה-SAP מהווה רק סביבה לניהול תהליכים אדמיניסטרטיביים ומכסה רק עשרות % בודדים מתהליכי הארגון, בדר"כ בארגונים אלה קיים DW אחר, ולרוב - ביצוע ניתוחים 'משולבים' יבוצעו שם (למעט מקרי קצה בודדים בהם ה-BW מהווה המרכיב העיקרי בניתוח).
  2. שיקול נוסף מוביל – היכן המסה העיקרית של הנתונים? אם רוב הנתונים לצורך הניתוח המשולב נמצאים ב-SAP ורק מעט מגיעים מה-DW הארגוני, הם יועברו ל-BW ושם ייעשה הדיווח, ולהיפך. איפה שהמסה של הנתונים יותר גדולה – שם הם יישארו ויתוחקרו.
  אם אין צורך לניתוחים משולבים, משאירים את נתוני SAP ב-BW (משתדלים לא לשכפל).

נושאים נוספים שעלו:

• ארגונים סיפרו ניסיונות לשימוש בכלי אחזור צד-שלישי מעל סביבת ה-BW.
• במפגש עלו כמה טיפים ושיטות עבודה עליהן ארגונים המליצו. בין ההמלצות שעלו: שימוש ב SAP Portal ושימוש בסביבות עבודה מוכנות (Business packages) של SAP.
• במפגש עלו גם יחסי כ"א ומיקומם הארגוני של אנשי הBW / SAP BI.

ממצא מפתיע לטובה - מבנה מחלקות הBI בישראל הרבה יותר טוב מאשר בחו"ל

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

לעומת זאת, בחברות בינלאומיות גדולות קיימת בעייה ידועה של "איי BI" המתקיימים במקביל, צוותי BI שונים ללא תיאום משמעותי ביניהם, וחוסר סטנדרטים. התוצאה הנה חוסר שיתוף בידע לגבי פרויקטי BI דומים, המצאת הגלגל מחדש, וקיומם של כלי BI רבים תחת אותה קטגוריה (סביר מאוד למצוא 3-4 כלי Reporting שונים, 2-3 כלי OLAP, 1-2 כלי Data Mining וכד'). בשנים האחרונות אותם ארגונים בינלאומיים שחיים עם "שגרת איי ה-BI" עוסקים בפרויקטי BI Consolidation שמשמעותם לאו דווקא בניית Enterprise Data Warehouse אחד, אלא בניית ארכיטקטורה, התוויית מדיניות, קביעת סטנדרטים של כלים טכנולוגיים (צמצום מסדר גודל של כ-7 כלים שונים ל-3 כלים שונים), וכן – באזוורד חדש עליו מדובר כמעט בכל מחקר הסוקר מגמות BI: ה-BICC.

BICC – Business Intelligence Competence Center
קיימות מספר הגדרות שונות ל-BICC, אך הרעיון הוא שגוף זה אחראי על הסתכלות מרכזית על תחום ה-BI בארגון, הבנת הדרישות העסקיות, תיעדוף, והעברתם למחלקת הפיתוח של ה-BI שמתקיימת כגוף נפרד. יש הגורסים כי תפקיד ה-BICC ממשיך גם לנושא ההטמעה של יוזמות ה-BI בארגון, וכגוף המרכז את דרישות ה-BI של ההנהלה הבכירה.

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

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

הדבר הבא במדיה החברתית: Sentiment Analysis

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

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

מחלקות שיווק ו PR מנסות לפענח מה "נאמר על החברה/המוצרים" ברחבי הרשת באתרים בעלי תוכן הנבנה ע"י אנשים, ובאופן ספציפי – באתרי הרשתות החברתיות. באתרים אלה גלום מידע בעל ערך רב: ניתן להבין הרבה על האופן בו החברה/המוצרים/שירותיה נתפסים, העדפות, מגמות, ועוד מאפיינים של תרבות הצריכה הרלוונטית לחברה.
בדיוק כדי לספק את הרצון הזה צמחו כלי כריית נתוני רשתות חברתיות, הדומים במאפייניהם לכלי כריית מידע קלאסיים ובמיוחד לכלי כריית מידע בלתי מובנה / טקסטואלי (Text Mining). לתחום זה של הפקת תובנות מניתוח מידע באתרי רשתות חברתיות קוראים כיום "Sentiment Analysis": הניסיון להבין מהי הגישה של כותב תוכן כלפי אובייקט מסוים. מטרת כלים אלה לאפשר לארגונים "להאזין" לתוכן של רשתות חברתיות, לנתח את השיחה כדי לזהות איזשהו רגש המתקשר עם החברה. זהו חלק ראשון של היוזמה, החלק השני הוא להשתמש בתובנה הזו כדי להגיב בצורה כלשהיא - לפעול להגן על המותג, לנסות לתקן, למנף ביקורת חיובית של בלוגר וכד'. כיום מתחילים לצוץ כמה ספקים של כלי תוכנה שאמורים לספק מענה לצרכים אלה. כלים אלה מספקים יכולות ניתוח טקסט המאפשרות לדוגמה יצירת clusters של תוכן חיובי לעומת שלילי, חלקם מספקים "ציון כולל" לקבוצה של תכנים לגבי מוצר מסוים, ורכיב חשוב – היכולת להגדיר על ידי מחלקת השיווק של הארגון חוקים ספציפיים עבורו (מילות חיפוש חשובות שמשנות את הציון וכד').

דוגמה של כלים כאלה: Umbria (מתמקדת באתרים חברתיית – לדוגמה, בלוגים), Biz360, ודוגמה לחברה ישראלית בתחום – באזילה.

בלינק הבא (בלוג של חברת המחקר 451 Group) יש רשימה די ארוכה של כלי sentiment analysis.

מהן הבעיות כרגע בניתוח Sentiment של רשתות חברתיות?

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

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

נושא זה מזכיר כלים לניתוח סנטימנטלי בערוצים אחרים – לדוגמה, ניתוח רגשות ("emotion detection") במוקד השירות באמצעות כלים המגיעים מתחום ה-speech recognition. כלים בתחום זה מזהים טונציה, מילים ספציפיות – word spotting (תביעה משפטית/שם המתחרה) ויכולים להוביל לפעולה על סמך התובנות המתגלות.
אך צריך להיזהר לנסות לנתח תוכן באותה הצורה בה אנו מנתחים תכנים אחרים, יותר מסודרים וקונבנציונאליים, המדיה שונה לחלוטין. לראיה, כל ניסיון לנסות ולהשוות את Twitter עם מדיה אחרת יהיה מוטעה. טוויטר מספק כיום אמצעי העברת מידע מהיר מכל מדיה אחרת (דוגמה טובה לכך היא העברת המידע בצורה כל כך חיה על המתחרש ברחובות איראן). כך, לדוגמה, ניתן לנתח בצורה מהירה השפעה של קמפיין מסוים על ה"שיחה" שבשטח כמעט בזמן אמיתי.

לסיכום, לדעתי, ארגונים שיתחילו כבר עכשיו לנסות ולנצל את הכוח הגדול של התוכן החבוי ברשתות חברתיות לא רק יצליחו "להרגיש" את השטח יותר טוב כדי להגן על המותג והתדמית, אלא עם שימוש נכון, יוכלו גם לנצל שיחות אלה למטרת קידום חדשנות מונעת-לקוחות.

הפרדוקס בתחום ה-BI

"BI הנו תחום החשוב ביותר ל 2009" זהו משפט ששמענו הרבה מארגוני enterprise בישראל לאחרונה. הקיצוצים בתקציב הובילו לפחות פרויקטי IT חדשים ויותר התמקדות בדברים הקיימים. פרויקטי BI במובן הזה הם "קלאסיים" – עוזרים להוציא יותר ערך ממערכות קיימות, ועוד סיבה חשובה: לרוב הארגונים יש כבר לא מעט כלי BI, ויש מחלקת BI פנימית, כך שניתן בעלויות צנועות למדי לבצע פרויקטי "הרחבת BI ליותר משתמשים בארגון.

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

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

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

היוזמות שמתקיימות כעת אצל ארגונים במטרה להרחיב את שירותי ה-BI:

• פרויקטים קטנים שמביאים לתוצאות מהירות – זהו איפיון הפרויקטים בBI וברוב התחומים האפליקטיביים האחרים. אם לפרויקט יש רמת סיכון גבוהה/אין ידע בישראל/הטכנולוגיה אינה בשלה ארגונים נרתעים מהתחום בימים אלה הרבה יותר מאשר בזמנים אחרים, טובים יותר.
• פרויקטי BI להנהלה (בעיקר דשבורדים, ופרויקטי מדדים). תחום זה שוב עולם לכותרות, החדשות הטובות הן שכיום הדוחפים הם יותר ההנהלות (ופחות מחלקת ה-IT). יש לציין כי בפרויקטים אלה ארגונים אינם פוסלים שימוש בכלים אחרים (שונים מכלי ה-BI בהם הם משתמשים כיום)
• פרויקטי BI פיננסי – כלי BI המיועדים למחלקה הפיננסית, ובראשם – כלי תכנון פיננסי ותכנון תקציב. גם כאן מדובר בכלי Best of breed ייעודיים, ולא דווקא של ספק ה-BI המרכזי של הארגון.
• התחום הרגולטיבי (באזל II לבנקים, ובהמשך גם Solvency לביטוח) מייצרים תקציב נוסף, ייעודי, שמתרכז בתחום ה-DW על מנת לייצר פתרונות בתחום זה.

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

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

העניין בכלי BI מבוססי קוד פתוח בעולם גובר בהתמדה, ונוצר דיון סביב המידה בה Open Source BI מהווה או לא מהווה Disruptive Technology לאפליקציות ה-BI הקלאסיות.

למרות שעד כה ארגונים ישראליים נרתעו מאימוץ אפליקציות מבוססות קוד פתוח, אנו רואים שכיום ארגונים בישראל גם הם מביעים התעניינות זהירה בקוד פתוח במספר תחומים, כאשר אחד מהם הנו תחום ה-Business Intelligence, ובאופן יותר ספציפי בכלי Reporting, Dashboarding ו – OLAP Viewers.

באופן כללי, בשוק הבינלאומי רמת השימוש באפליקציות מבוססות קוד פתוח (OSS) גבוהה יותר ועומדת על עשרות אחוזים (מעל 50% מארגונים הנשאלים בסקרים אומרים כי הם משתמשים באפליקצית OS כלשהיא), אך, כשמדובר בתחום ה-BI, גם בחו"ל אחוזי השימוש אינם מאוד גבוהים, רמת השימוש עדיין מאוד מוגבלת אך על פי מחקרים - עולה בהתמדה. לדוגמה, על פי סקר של חברת Cutter שנערך ב2008, רק כ-18% מארגונים בינלאומיים עושים שימוש כלשהוא במוצרי BI מבוססי קוד פתוח (לעומת 11% בלבד ב-2006). 35% מהארגונים הנשאלים מתעניינים ביישום כלים אלה. מחקר זה מראה מגמה יציבה של התעניינות גוברת בקוד פתוח על פני 3 השנים האחרונות.

מאפייני ההתעניינות הזהירה בכלי Open Source BI:

• הקטגוריות הפופולאריות ביותר לכלי BI מבוססי קוד פתוח הנם כלי דוחות ודשבורדים. בחו"ל יש גם עניין בולט בכלי ETL מבוססי קוד פתוח.
• ברוב הכולל של ארגונים מתעניינים לא מדובר ביישום BI סטנדרטי לכלל הארגון אלא לשימוש נקודתי – לפרויקט ספציפי או למחלקה מסוימת.
• רוב הארגונים המיישמים כלי BI בקוד פתוח בחו"ל יישמו זאת בעצמם, ולא באמצעות כ"א חיצוני. זאת משום שרבים מהמאמצים הנם ארגונים טכנולוגיים ובתי תוכנה שמאמצים את הכלים לשילוב במוצרים המסחריים שלהם.
• ספקי Open Source BI בולטים שמופיעים על ה"רדאר": Pentaho, Jaspersoft, מיזם BIRT - Eclipse.
  

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

מצגת - מגמות Business Intelligence

העליתי לרשת מצגת על מגמות בתחום ה BI. וביניהן:

• BI אקטיבי (המשולב במערכות התפעוליות)
• MDM וניהול נתונים
• תמונת מצב - Scorecards ו Dashboards
• התועלות שארגונים כבר מפיקים כיום מ BI
• הבעיות כיום ב-BI (מסתבר שיש לא מעט)
• מגמות לטווח הבינוני - קצר בעולם ה BI
• מגמות לטווח הארוך יותר
• כיצד ארגונים תופסים כיום את ה-BI?

את המצגת תוכלו לראות כאן.

Business Intelligence - main technology in Israel

Business Intelligence is one of the most strategic areas for the next years. It's on every CIO's agenda, and usually, one of the "top five" proprities. This is one of the few markets in which there is not much difference between the Israeli market and other global markets.

In my interaction with CIOs, I see that even in these tough times (and possibly because of that), many of them have placed this area as a top priority for 2009-10. Even though IT budgets are most likely shrinking in 2009 (~10%), BI budgets are expected to grow or remain the same.

The following radar shows which areas are being used by most enterprises / large Israeli organizations (for example, typical BI/DW is used by most), which areas are in implementation phases, and which are “of interest” (or, in other words, are being examined):

According to a survey I conducted, BI was considered a main technology for 2008, similar to what global organizations said is a similar survey performed abroad.

In my frequent conversations with organizations re BI, I hear many great things about this area (unlike other application areas such as ERP etc.).

Here are some of the good stuff people are saying about BI:

1. BI has become the most efficient way of extracting more value from existing or new applications. Some organizations make it a habit of incorporating BI services from day 1 to each new project they are launching, simply because it provides immediate value out of the application instantly, instead of waiting for the new application to stabilize first before providing analytics around it.
2. BI Helps IT achieve better alignment with the business. Because of its nature, BI requires a lot of collaboration between IT and business units, it usually also gives business users what they want, and so helps IT be regarded as a more business aligned partner.
3. BI created an organizational language. Some organizations (especially distributed or global) claim this is the most important benefit from their DW/BI.
4. A central EDW creates a single version of the truth.
5. CPM & Scorecard help the organization connect the day to day actions to the organizational strategy.
6. Active BI (incorporation of BI services in applications processes) can help create better & smarter processes.

Here are the negative things people are saying on BI:

1. BI is under-used in most organizations. Even in the more mature ones, organizations are not yet getting what they can get out of BI. Usually the mid-level management layer and business analysts are heavy users, but top management is only now starting to use dashboards, and the rest of the organization – knowledge workers – are not yet enjoying the benefits of BI. This has triggered the need in some places for a BICC.
2. Stand-alone data marts create several data versions. This problem is actually not as common in Israel as in the U.S, as most organizations have created a centralized DW and are trying to keep it as much as possible. Still, large organizations find it difficult to keep a central DW at all costs, and have to deal with several data marts. These “centralized” data marts make it difficult to implement a cross-organizational initiative, such as a Balanced Scorecard.
3. “Data Mining is only for experts” is a phrase I often hear. It is looked upon as a very complicated practice, and is used in “niche” areas – mainly marketing and fraud detection.
4. "The data is not 100% reliable". Data Quality issues are affecting the reliability of the DW.

מהם הפתרונות שה-CFO צריך? רשמים משולחן עגול

לאחרונה קיימתי שולחן עגול בנושא פתרונות למנהל הפיננסי. למפגש הגיעו הן מנהלי מחלקות שונות ב-IT, והן CFOs (מנהלים פיננסיים) או נציגי המחלקות הפיננסיות ממגוון סקטורים: ארגונים תעשייתיים, היי-טק, שירותים פיננסיים, בריאות.

בדיון דובר על המצב הקיים לעומת המצב הרצוי מבחינת פתרונות למחלקה הפיננסית, נקודת המבט של מחלקת ה-IT, נקודת המבט של המחלקה הפיננסית, בעייתיות וחסמי, והתייחסות לנושא רגולציות:

המצב הקיים לעומת המצב הרצוי:

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

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

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

• נושא תכנון תקציב (Budget Planning) כתחום אליו ארגונים כבר נכנסו או לחילופין מעוניינים להיכנס בקרוב. הכלים העיקריים שהוזכרו בהקשר זה: הייפריון, פתרונות SAP. כל הארגונים שהשתתפו בדיון סיפרו על רצונם להיכנס למערכות תכנון ובקרה (חלקם כבר עושים זאת כיום), ורובם הביעו רצון שמערכת זו תתממשק בצורה טובה עם מערכת ה-ERP שלהם. יש לציין כי למרות דרישת התממשקות זו, כמחצית ממשתתפי הדיון מסתכלים על הכלים בתחום זה ככלי best of breed (מה שאומר שאם המערכת המוצעת מספק הERP אינה מספיק טובה, הם יסתכלו על כלים אחרים). ארגונים מאוד מוטי מערכת ERP ספציפית סיפרו כי לא היה הרבה ספק בשלב בחירת המערכת שכן היא צריכה להתממשק בצורה הדוקה ל-ERP כדי לספק סגירות ותאימות חשבואנית, ולכן, גם אם המודול הרלוונטי אינו הטוב בשוק, הם יבחרו לעשות בו שימוש.
• תחום נוסף שהוזכר כחשוב הנו תחום המדידה / Balanced Scorecard. במקרה זה, מעטים הם הארגונים שכבר מיישמים שיטות מדידה באמצעות כלי מדף, אך חלקם כבר עובדים בצורה כזו עם כלים בפיתוח עצמי, ואחרים הביעו רצון להיכנס לתחום.
• מערכות המנהלות את תהליך הזמנת נסיעות – מערכות Travel שלכאורה אינה קשורה למחלקה הפיננסית, הנה מערכת שהוזכרה כמה פעמים בדיון, כאשר התועלת מהכנסת מערכת המנהלת את תהליך הזמנת הנסיעות של העובדים הנה כספית ודי ברורה – ארגונים שכבר יישמו מערכת זו סיפרו שחסכו חיסכון משמעותי והצליחו ליישם יותר בקלות מדיניות נסיעות באמצעות המערכת. המערכת מאפשרת בקרה על תהליך הנסיעות מבחינת התקציב, כולל התממשקות למערכת ה-ERP לצורך רישום חשבונאי.

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

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

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

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

ניתן לצפות בסיכום הדיון המלא כאן.

איך זה שMDM עדיין לא תפס בישראל?

אחת הדוגמאות הבולטות ביותר לפער בין השוק הבינלאומי לשוק הישראלי הוא שוק ה-MDM. בחו"ל - אחד השווקים החמים ביותר כיום, בישראל - בקושי קורה כאן משהו. נתון שעולה מסקר שערכתי בנושא בקרב ארגונים גדולים בישראל - 36% הביעו כוונות להיכנס לפרויקטי MDM בשנים הקרובות, 35% לא מתכננים, ו29% כלל לא מכירים את הנושא שעדיין הנו חדש יחסית. הפער מול המצב בחו"ל בולט, בסקר מקביל שנערך בקרב ארגונים בינלאומיים- 60% מהם כבר החלו ביוזמות MDM כלשהן:

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

עוד חוליה שחסרה בדרך להפיכת שוק ה-MDM לשוק חי ובועט בארץ: אין בעלות עסקית על נתונים. ברוב החברות אין מישהו מוגדר בארגון שתפקידו להיות האחראי הראשי לנתוני לקוחות/מוצרים/ספקים. חלק גדול ממה שכלי MDM נותנים זה אפשרות לאכיפה של Data Governance ואיך ניתן לעשות זאת לאל ה Governor?

זהו אחד התחומים שבהם ברור שיש צורך עסקי, אולם כל עוד לא יהיה Data Governance בארגון פרויקטי MDM ילבשו נופך טכני ויהיו במקרה הטוב סוג של HUB / מעין ODS שמעביר נתונים ממקום למקום, ולא תהיה אחריות ניהולית על נתונים בארגון.

Supply Chain בישראל - סוף 2008

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

• רוב פעילויות ההתקשרויות מול ספקים הנן ידניות, דברים רבים שיכלו להיות ממוכנים ולחסוך עלויות כוח אדם נכבדות אינם ממוחשבים. מיכון פעילויות אלה יכול לא רק לחסוך בעלויות כוח אדם אלא להוביל לשיפורים נוספים כגון חיזוק הקשר מול הספקים, יותר נתונים שיאפשרו ניתוח הספקים, רמת אמינותם, רמת השירות, וכד'.
• ברוב הארגונים קיים טיפול (חלקי בלבד) בנושא ה Execution ולא בנושא ה Planning, ורוב ההתייחסות שמחלקות עסקיות מקבלות הנה במסגרת ה ERP + פתרונות משלימים קטנים אחרים. דווקא לחלק ה Planning שעוסק באופטימיזציה של תהליכים יש פוטנציאל עסקי גבוה ביותר, במיוחד כאשר ניתן לחבר אותו באופן הדוק לתהליכים השוטפים (Supply Chain Execution) כך שהתהליכים מושפעים מתובנות אנליטיות. כלומר, יישומי BI אקטיבי בתחום שרשרת אספקה מציעים ערך עסקי גבוה ביותר, כאמור, רוב הארגונים כלל אינם שם. רוב ניתוחי הBI הקיימים כיום מתרכזים סביב נתוני מכירות, פיננסים ולקוחות. יישומי BI אקטיבי שמשפיעים ישירות עם תהליכי ומערכות תפעוליות מתרכזים לרוב סביב איך להוציא יותר כסף מלקוחות. הם הרבה פחות מתרכזים בשאלה רלוונטית מאוד לעיתות משבר – איך נייעל את אופרציות הארגון: רכש יותר מושכל, רמות מלאי יותר מבוקרות, חיזוי דרישה וקישורו לפעילויות הארגון, איזה ספק לבחור לתהליך ספציפי וכד'.
• מנהלים עסקיים לעתים מדברים ישירות מול ספקים בתחום הSupply Chain, כאשר לעתים ה IT כלל אינו מעורב. העסק בדר"כ מסתבך כשמערבים את ה IT לקראת סוף התהליך, באופן טבעי נוצרות התנגדויות והתהליך מסתבך. כמובן שאחת מהתוצאות היא שהIT נתפס כמעכב תהליכים עסקיים לארגון.
• סינדרום ה-ERP. מנמ"רים רבים ציפו שמערכות ה-ERP ייתנו להם מענה לתהליכי שרשרת אספקה באופן די מקיף. פעמים רבות מסתבר שחבילות אלה לא מטפלות בתהליכים ספציפיים, או שהן מטפלות בו בצורה חלקית בלבד. פעמים רבות מתעורר הוויכוח הוותיק שבו ה IT לרוב יטען שכדאי להשתמש במה שיש בחבילת הERP ככיוון אסטרטגי מבחינתו. התוצאה היא ששוב מחלקת הIT נתפסת כגורם מעכב.
• תדמית שלילית. מחלקות IT שכיום מתייעצות עמנו בנושא SCM שונים מביעים רתיעה מתחומים שונים שקיבלו מוניטין רע, ובמיוחד תחומי B2B, Ecommerce. קיים פחד להיכנס לנושא זה בשל זיכרון של כישלונות עבר בתחומי זירות מסחר ויוזמות שונות שהתפוצצו.

להערכתי, מחלקות IT כיום רחוקות מדי מצרכי שרשרת האספקה של הארגון. אין ספק שתחום ה Supply Chain Planning הולך להתפתח בצורה משמעותית ביותר, לכלים בתחום תכנון שרשרת האספקה יש פוטנציאל עסקי משמעותי ביותר עבור חברות שחלקו קשור להתייעלות וחיסכון כספי בסדרי גודל מרשימים ביותר, לא רע לתקופות משבר. התחום יתפתח, ולהערכתי זה יקרה עם או בלי מעורבות מחלקות הIT (מה גם שתחום ה SaaS צפוי לחדור משמעותית לשוק זה כך שחלק מהיוזמות ייעשו לעתים ללא ידיעת הIT כלל). לי נראה שלמחלקות הIT כדאי להיות חלק מהעניין, מה גם שפרויקטי ERP גל ראשון יוצבו ברובם, כך שיוזמות SCM יכולות למנף חלק מהתשתית האפליקטיבית שארגונים כל כך התאמצו להשיג. מהצד השני של המתרס, ספקי הIT צריכים להיכנס יותר לתחום (דבר זה ידרוש השגת יכולות והתמחויות חדשות מבחינתם), רוב הספקים הגדולים בישראל מחוץ למשחק זה כיום, ומשאירות את השוק לחברות יחסית קטנות שפועלות כחברות ייעוץ + יישום + מוצר. הן אלה שפיתחו קשרים טובים עם מחלקות עסקיות בתחום זה וכן לעתים מול מחלקות הIT.

אילו פתרונות מחלקת ה-IT מספקת למנהל הפיננסי?

במשך שנים התסמן פער ברור בין השוק הבינלאומי לשוק הישראלי בכל הנוגע לכלי תכנון פיננסי, או כאלה הנכללים תחת מונח המטריה: CPM - Corporate Performance Strategy. מונח זה כולל בתוכו תתי-תחומים רבים כגון תכנון תקציב, תמחיר, איחוד דוחות כספיים, Balanced Scorecards ועוד ובשנים האחרונות זוכה לעדנה בשוק הבינלאומי. אולם בישראל רוב הארגונים יישמו רק רכיב קטן מתוך מכלול זה, ורבים מהם מתחילים להתעניין בתחום לאחרונה בצורה יותר עמוקה. מעטים הארגונים בישראל שחיברו בין תהליך התכנון האסטרטגי והתכנון הפיננסי, לפעולתו השוטפת של הארגון כדוגמת יוזמות Balanced Scorecard חוצות ארגון.

כאמור, לאחרונה חלה התעוררות בקרב ארגונים ישראלים בכל הקשור לכלי תכנון ובקרה למנהל הפיננסי. בעוד שבעבר רוב הכלים אשר סופקו ל-CFO היו תפעוליים באופיים (כחלק משלב א' בפרויקטי ERP), כיום מנהלים פיננסים דורשים (וגם מקבלים) יותר כלי תכנון ובקרה.

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

במפגש נבדוק אילו כלים ופתרונות המנהל הפיננסי כיום צריך, וכיצד מחלקת ה-IT יכולה לתמוך בצרכים אלה? במפגש נעלה את השאלות הבאות (עד כמה שיאפשר הזמן):
· מה כבר נעשה בארגונים מבחינת פתרונות למנהל הפיננסי?
· מה יהיו הכלים הבאים אותן מחלקות IT תידרשנה לספק למנהלים פיננסים, במיוחד בתקופות של חוסר יציבות כלכלית? מהו הדגש בתוך מכלול כלים אלה (האם אנליטי? האם תפעולי?)
· מה בין ERP לפתרונות פיננסים? האם הפתרונות הפיננסים מגיעים מסביבות הERP או שיש להסתכל על תחום זה כייחודי, המצריך פתרונות Best of breed?
· המלצות וטיפים לארגונים הנכנסים לתחום

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

המפגש ייערך בתאריך 05.11 (יום רביעי) בין השעות 09:30 – 13:00 ויתקיים במשרדנו שבבני ציון. המפגש מיועד לארגוני משתמשים בלבד (ולא לספקים או יועצים). אם ברצונכם להירשם, אנא שלחו מייל לאתי etty@stki.info או שמרית shimrit@stki.info או טלפונית 09-7907000 (אתי או שמרית).

ODS - תמונת מצב

ODS - Operational Data Store, הנו מונח די היסטורי בעולם ה-DW והאפליקציות הארגוניות, או ליתר דיוק - בעולם ניהול הנתונים.
לאחרונה בדקנו מה סטטוס ה-ODS בארץ ובעולם, במטרה לבחון האם ה-ODS, שיטה טכנולוגית שצמחה מתתוך הכרח, הופכת להיות מיותרת בארכיטקטורת ה-IT של היום, או שעדיין אין לה תחליף ראוי.

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

ODS - פיתרון טכנולוגי
בדיוק כמו שה-DW צמח כשיטה לאפשר ניתוחים אנליטיים, ה-ODS צמח כפיתרון המספק סביבה מקבילה המספקת שירותי נתונים תפעוליים לכל דורש, בין אם מדובר באפליקציות תפעוליות הצורכות נתונים אלה, או בסביבת DW.
היתרון הגדול הנו הפחתת העומס על מערכ/ות המקור. מבחינה היסטורית, מערכות רבות נבנו בצורה עצמאית, ללא קשרים בין מערכת אחת לשנייה. אולם עם הזמן הסתבר שההחלטות שמערכות, (וגם אנשים), מבוססות יותר ויותר על מערכות אחרות. לסוגיה זו מספר משמעויות, גם המשמעות הפיזית של גישה למערכת לשלוף את הנתונים, גישה היוצרת עומס נוסף על המערכת ותוספת עבודה במהלך התכנות (כי צריך לפנות למבנה נתונים אחר שלא שייך לפרויקט) אבל גם משמעות של קשיים טכנולוגיות ומאמצים תפעוליים. אם ישנה מערכת תפעולית חשובה שפועלת 24*7 שצריכה נתון ממערכת פחות חשובה שפועלת רק 5*8, הרי שלפחות מסד הנתונים של המערכת הפחות חשובה חייב לקבל "שדרוג" של שרתים ואחסון זמינים (cluster , DRP), מדיניות הורדת מערכת וניהול שינויים "משודרגת" וכד'.
זהו הצורך הבסיסי ל- ODS – מקור נתונים תפעוליים זמין ואמין שמוריד את העומס בכל הרמות מהמערכות התפעוליות. בד"כ ה- ODS תומך ב- read only בלבד.

תמונת מצב - מה המגמה בעולם?
מבחינת המגמה בעולם, ODS עדיין די נפוץ אך הופך להיות פחות "טרנדי". הטרנדים מדברים הרבה על ה"דור החדש" של ה-ODS: MDM – Master Data Management, וה-CDI – Customer Data Integration (אם מדובר על נתוני לקוחות), אשר מתחילים להיכנס על חשבון ODS המסורתי יותר.
ישנם קווים דומים בין תפקיד ה ODS לתפקיד ה-CDI/MDM וחפיפה ביניהם. הODS הנו פתרון "טכנולוגי" טהור שתפקידו לשמש תווך בין מערכת תפעולית למערכות תפעוליות אחרות שצורכות data שנמצא במערכת. ואילו ה-CDI הנו פיתרון טכנולוגי אך הוא גם מספק אפשרויות "ניהול" ו governance של נתון – איך מוגדר נתון לקוח? חוקים עסקיים סביב הנתון? מה עושים בעת קונפליקט? ב CDI יש בדר"כ את הטיפול בטיוב הנתונים ובאופן כללי צריך משתמש עסקי שייקח בעלות על הנתונים.
הסבר לגבי ההבדלים העיקריים בין CDI ל ODS ניתן למצוא כאן.

מה ההבדל בין ODS ל-DW?
ישנם ארגונים שהחליטו להפוך את ה-DW שלהם ל-DW תפעולי, המשרת את המערכות התפעוליות. אם כן, מה ההבדל בין DW שכזה לבין ODS? התשובה לא תמיד ברורה, שכן בפועל DW לעתים משמש כ-ODS. ה-ODS לעתים משמש (כיום פחות) כ staging area עבור ה-DW וגם להוות מקור ממנו גוזרים דוחות תפעוליים. יש ארגונים שה-DW שלהם הפך להיות סוג של ODS (כלומר מהווה את המקור ממנו מערכות תפעוליות מושכות נתון תפעולי) למרות שזהו לא תפקידו הקלאסי של ה-DW. בעוד ה-DW מכיל בדר"כ מידע היסטורי ומתעדכן אחת ליום/שבוע, ה-ODS מכיל מידע תפעולי לא היסטורי ושיטת העדכון צריכה לאפשר זמן אמיתי/קרוב לכך.

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

מהו ה-BICC?

BICC - BI Competence Center הנו מונח שעולה לכותרות לאחרונה, במיוחד במחקרים בינלאומיים המדברים על מגמות בינלאומיות בתחום ה-BI.
גם ארגונים ישראליים שואלים אותי לאחרונה על התחום ויש ניצנים ראשונים של פעילות בתחום זה גם בארץ.

מהו ה-BICC?
מחלקה היושבת בתפר שבין ה-IT למחלקות העסקיות, ואמורה לקשר בין הצרכים העסקיים של הארגון מה-BI ובין מחלקת הפיתוח של ה-BI.
כלומר, יש כאן הפרדה מסוימת מכיוון שהBICC הוא הגוף שנמצא בקשר מול המחלקות העסקיות, מבין את צרכי המידע, מגבש תפיסת מידע, עוסק בתיעדוף הפרויקטים והצרכים, ומעביר דרישות אלה (לעתים אף לאחר איפיון) למחלקה הביצועית - מחלקת הפיתוח של ה BI.
תפקיד נוסף של הBICC הוא לספק מענה לשכבות שאינן צורכות כיום שירותי BI באופן שוטף, לרוב מדובר ברמת ההנהלה הבכירה. רוב הארגונים הגיעו למסקנה שמנהליהם הבכירים לא יתחקרו נתונים בעצמם אלא תמיד יעדיפו לבקש נתונים "לעוסים" על ידי גורם אחר. תפקידו של הBICC הוא גם לספק את המידע הדרוש להנהלה הבכירה.
תפקיד נוסף, מעט יותר מעורפל, של מחלקת ה BICC הנו "Data Governance". כיום המשמעות האופרטיבית מתנקזת בעיקר להגדרות עסקיות/מילון נתונים למושגי BI שונים. אולם לדעתי, בעתיד, במיוחד עם כניסת תפיסות ניהול מידע חדשות כגון MDM-Master Data Management, גוף מרכזי שיודע להגדיר נתון לאורך כל הארגון וחשוב מכך - יש לו את הכוח והמנדט לעשות כך, יהיה בעל ערך גבוה לארגון.

במחקר שהתפרסם ב computerworld, פורסם כי ל 20% מהחברות הגדולות כבר יש BICC, אשר מכיל פחות מ-10 אנשים (רובן פחות מ5 איש). התועלות העיקריות המצופות: הגדלת שביעות הרצון של המשתמש העסקי, ושיפור תהליכי קבלת החלטות.

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

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

כיצד ישפיע המיתון הצפוי על עולם האפליקציות?

עוד לפני ההודעות המרות על קריסת מוסדות פיננסים בארה"ב, התחלנו לקבל רשמים ממנמ"רים ומנהלי IT שונים לגבי קיצוצים צפויים בפעילויות וכן במחלקות הIT שלהם.
יש הרגשה של מיתון באוויר, וחששות באשר למצב השקעות ה-IT ב-2009.
אם אכן מיתון זה יתממש, כיצד זה ישפיע על פרויקטי האפליקציות?

אם לשפוט על פי תקופות מיתון קודמות, פרויקטי ענק הם הראשונים להיעצר. בתקופות מיתון פרויקטי ERP, CRM ופיתוח/החלפת מערכות ליבה הנם הראשונים שנפגעים. הבעיה היא שהחלפת/שיפור מערכות ליבה הנו נושא חשוב ודי דחוף אשר חברות צריכות לטפל בו, שכן מערכות הליבה הישנות כבר אינן מספקות את המענה.

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

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

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

Scorecards ו- Dashboards. מה ההבדל?

יש כיום בלבול לגבי משמעות המונח Dashboard, ונוטים לעשות בו שימוש במגוון הזדמנויות. אנו מגדירים את ה- Dashboard כשכבה פורטלית היושבת מעל תשתית נתונים קיימת (בין אם סביבת BI ובין אם סביבה תפעולית?) ומציגה את הנתונים בצורה מותאמת למשתמש (Customized Views). בדרך כלל מדובר במעין Portal לנתוני BI, כאשר כל משתמש (בדרך כלל מנהל) יראה נתונים שונים המסודרים בצורה שונה.

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

הגדרה שמצאה חן בעיני לקוחה מ Perceptual Edge:

High-level summaries. The information displayed in a dashboard should consist primarily of high-level summaries, including exceptions, to communicate at a glance. It quickly tells you what's happening, but not why it's happening, just like the gauges, meters, and indicator lights on a car. Diagnosis requires further investigation and detail. A dashboard can serve as the starting point for this investigation, letting you drill down into further detail to perform an analysis, but this feature isn't required for something to be called a dashboard.
Concise, clear, and intuitive display mechanisms. Display mechanisms that clearly state their message without taking up much space are required so the entire collection of information will fit into the limited real estate of a single screen. If a graphical representation that looks like a fuel gauge, traffic signal, or thermometer is relevant and appropriate for a particular piece of information, that's what you should use. However, insisting on sexy widgets or displays similar to those found in a car when other mechanisms would work better is counterproductive.
Customized. The information on a dashboard must be tailored specifically to the requirements of a given person, group, or function; otherwise, it won't serve its purpose to help achieve specific objectives
Source: Perceptual Edge

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

Scorecards – הגדרה:
ה- Scorecard הנו חלק אחד מתחום יותר רחב שנקרא ניהול ביצועים עסקיים: BPM – Business Performance Management. המונח Balanced Scorecard (לוח שעונים "מאוזן") הנו למעשה מתודולוגיה שפותחה ע"י Norton & Kaplan, שמספקת מודל לקביעת מדדים (KPIs) על פיהם ארגון מודד את עצמו. המתודולוגיה עוסקת בעיקר בנושא האיזון – כיצד לקבוע מדדים "מאוזנים" שיאפשרו לנווט את הארגון על פי מטרותיו האמיתיות? לדוגמה, אם הארגון יקבע מדדים המדברים בעיקר על כמות (כמות השיחות הנענות במוקדי השירות, כמות התקלות שנפתרות, מס' ימים לתקלה), יש לקבוע מדדים מאזנים העוסקים באיכות (רמת שביעות רצון לקוחות). לעתים משתמשים במונח Scorecard כדי לתאר את לוח המחוונים עצמו (למעשה סוג של Dashboard) – שכבת התצוגה.

מצב השוק בישראל - Scorecards:
כ 80% מלקוחותינו בישראל כעת עסוקים ביישום או בתכנון פרויקטי Dashboards / Scorecard בארגוניהם (לרוב מתמקדים ב Dashboards ורק בודדים שמים דגש אמיתי על נושא התכנון). כמעט כולם אינם עושים שימוש במתודולוגיית Balanced Scorecard של נורטון וקפלן שמסייעת במדידה שיטתית בארגון בצורה "מאוזנת". ברוב הארגונים המתחילים לעסוק במדידה אין תהליך מתודולוגי של קביעת המדדים על פיהם יימדדו היחידות העסקיות בארגון. לרוב יש רעיון, כלשהוא, שלרוב מבוסס על ביצועי העבר, לגבי המדדים לניהול הביצועים. תת בעיה של חוסר גישה מתודולוגית הנה העובדה שלרוב מתבצע תהליך כזה על "מחלקה" אחת במנותק משאר הארגון. כלומר, ישנו נתק בין מטרות ויעדי כל מחלקה בנפרד למטרות ויעדי הארגון.

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

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

תובנות ממפגש שולחן עגול בנושא Business Intelligence

אנו נוהגים לקיים מפגשי שולחן עגול, אלו דיונים בהם אנו מנתחים תחום ספציפי, המשתתפים בדיון (ארגוני משתמשים) מספרים על נושא הדיון בארגונם, מעלים סוגיות בעייתיות, דרכים לפתרון הסוגיות וכד'.

לאחרונה ערכתי שולחן עגול בנושא BI. מלכתחילה היה ברור שיש הרבה עניין בנושא, ולמפגש הגיעו מעל 20 ארגונים מסקטורים שונים, כולם כבר עוסקים בתחום ה-BI, ורובם עושים זאת כבר כמה שנים.

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

קחו לדוגמה את תחום חבילות האפליקציות – מערכות ERP ו CRM כיום כוללות שירותי-BI/DW/אפליקציות אנליטיות מובנים. לא אחת אנחנו נשאלים שאלות אשר בבסיסן הן שאלות של מדיניות – מי בארגון אחראי על פרויקטים מסוג זה? מתי לאפשר את ביזוריות ה-BI הזו ומתי לא?

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

כמה מאפיינים מעניינים שעלו באשר למאפייני מחלקת ה-BI בדיון:
אצל 75% ממשתתפי הדיון קיימת יחידת BI מרכזית (אולם במספר ארגונים קטן קיים ביזור של נושא ה-BI למרות שבדרך כלל יש איזה גוף שאחראי על מדיניות ה-BI והפיתוח עצמו מבוזר)
בעלי התפקידים הכלולים במחלקת ה-BI/DW: מנתחי מערכות, מנהלי פרויקטים, אנשי DW – נתונים שעוסקים ב ETL, מודל נתונים וכד', אנשי פיתוח ובדיקות.
לרוב מחלקות ה-BI אין DBAs משלהם (זאת למעט ארגוני Teradata) אלא הם צורכים שירותי DBAות ממחלקת תשתיות.

יחסי כוח אדם
מסקר שערכתי בין המשתתפים על נושא יחסי כוח אדם עלתה שונות גדולה. מספר העובדים במחלקת ה-BI נע מ 4-6 במחלקות הקטנות יותר, ועד 60< במחלקות הגדולות יותר. המספר הממוצע של מספר עובדי ה-BI בארגונים ישראליים גדולים הוא 10-15 עובדים (נתון זה מסתמך על סקרים נוספים שביצעתי מול חברות רבות). ניסינו למצוא יחס בין מספר עובדי ה-BI למספר המשתמשים שעושים שימוש בשירותי ה-BI אולם גילינו כי מדד זה מאוד בעייתי בשל השונות בהגדרה "משתמש BI”, ובשל המגמה של מערכות תפעוליות שהופכות להיות משתמשים הצורכים שירותי BI בעצמם. הייתה שונות גבוהה מאוד בין היחסים שציינו הארגונים: החל מעובד BI אחד לכל 6 משתמשי BI, ועד לעובד BI אחד לכל 185 משתמשים. שיטת מדידה נוספת ויותר מוצלחת הנה גודל מחלקת ה-DW/BI (או מספר העובדים הכולל בתחומים אלה) ביחס לכלל מחלקת ה-IT. מהנתונים שאספתי, הנתון הממוצע של עובדי מחלקת ה-BI/DW מתוך כלל מחלקת ה-IT (תשתיות + פיתוח): 6.5%. יש לציין שהאחוזים שקיבלתי נעו בין 3% לבין12%. מספר ארגונים אחדים עמם שוחחתי ציינו כי תחת מחלקת ה-BI יושבים גם אנליסטים, רוב המשתתפים (כ-80%) ציינו כי האנליסטים יושבים במחלקות העסקיות. בדיון עלה גם נושא ה"גבולות" – נושא מעניין בפני עצמו. מה מחלקת ה-BI צריכה לעשות ומה לא? בארגון אחד שהשתתף מחלקת ה-BI כמדיניות שקבעה לעצמה עקב משאבים מוגבלים נותנת שירותים רק במקרים בהם יש להם ערך מוסף (כלומר אינה מוכנה להעביר נתונים ממקום למקום איפה שאין לה ערך מוסף). ארגונים אחרים ציינו כי נושא הגבולות נבדק כל הזמן ואחד מהארגונים חלק מניסיונו כשסיפר שכל גבול אדום שמחלקת ה-BI הציבה לעצמה בסופו של דבר נפרץ. באופן כללי הוסכם כי מחלקת ה-BI צריכה להתמקד בפעילויות בהם יש לה ערך מוסף, ולבחון האם לא כדאי לבצע בקשות מסוימות דווקא ברמת המערכת התפעולית ולא ב-DW.