מגמה חשובה בעולם ה-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.

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 יושב/ים תחת אותה מחלקה, ולרוב מחלקה זו מקיימת קשר הדוק עם המחלקות העסקיות.
כך שבסה"כ ניתן להתנחם בעובדה שלעתים דווקא העובדה שארגונים ישראליים יותר קטנים מאפשרת להם להיות יותר יעילים.

הפרדוקס בתחום ה-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.

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 של נתונים, הקושי ביצירת "תמונת לקוח"/ נתון פיננסי/ נתון ספק וכד', אחידים לכל אורך הארגון יהווה בעיה מטרידה עבור ארגונים גם בשנים הקרובות.

תובנות ממפגש שולחן עגול בנושא 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.