תמונת מצב Workflow/ Human oriented BPM - סיכום שולחן עגול

בשולחן עגול שנערך בנושא Human Oriented BPM / Workflow עלו הנושאים הבאים:

מהו המניע העיקרי בכניסה ל-BPM?

1. קיצור תהליכים בארגון
   ארגונים הנמצאים בתחרות אינטנסיבית בשוק שלהם, מתמודדים עם סביבה עסקית המאופיינת בקצב שינויים גבוה, אמרו כי הארגון דורש גמישות עסקית גבוהה. בארגונים אלה, מחלקת ה-IT לא רוצה להיות צוואר הבקבוק בתהליך. אחד הארגונים תיאר מצב מתמיד של מיזוגים, רכישות ופיצולים עמם הארגון מתמודד. תהליכים ספציפיים שצוינו: קיצור זמן ההספקה (בעיקר נושא הרכש שמעכב את התהליך), קיצור זמן אישור דרישות רכש.
2. שיפור תהליכים קיימים
   שיפור תהליכים קיימים תמיד היה מניע "קלאסי" לכניסה ל-BPM. אחד הארגונים אשר מתקדם בתחום ה-BPM סיפר על יוזמה לשיפור האיכות (עמידה בתקינה של איכות) אשר מומשה באמצעות BPM. ארגונים אחרים סיפרו שאחת התועלות הצפויות מתחום זה היא היכולת לנטר באופן שוטף תהליכים כדי לבחון כיצד אפשר לשפרם, לזהות צווארי בקבוק ולשפר את התהליך (לעומת תהליך פיתוח רגיל אשר אינו מאפשר זאת).
3. יכולת לתת מענה לתהליכים עסקיים רוחביים (כאלה שאינם מוגבלים למחלקה אחת אלא חוצי מחלקות).
4. רגולציות SOX
   למרות שזה לא עלה כמניע עיקרי, נושא הרגולציות הוזכר כעוד תועלת לה ניתן לצפות לאחר כניסה לתחום. בתחום ה-SOX צוין כי האינטרס של הארגון הוא לדעת שהארגון לא עובר "סף" כלשהוא שאסור לו לעבור. ארגון משקיע הרבה כסף כל שנה מחדש לנושא ה SOX (בחינה של איזה תהליכים עסקיים משפיעים על דיווח כספי), אח"כ בונים תכנית עבודה – על כל תהליך מהם הסיכונים, וגם הזנת התוצאות. נושא הSOX צריך להיות עוד פרמטר בכלי ה-BPM.
5. צוין כי המניע לא צריך להיות חיסכון בעלויות. המוטיבציה צריכה להיות מכיוון מדידת שיפור בביצועים (זיהוי צווארי בקבוק, היכן צריך לתגבר עובד, האם אנו מתאימים לתהליכי התקינה). הרווח לא מגיע בשנה הראשונה אלא לאורך זמן. ארגון שרואה לנגד עיניו מטרה של חיסכון בעלויות יתקשה לתת לזה כיסוי, בטח שלא בשנים הראשונות.
6. תועלת נוספת שצוינה (לא ממש מניע, אלא תועלת נלווית) היא אלמנט ה"יוקרה" - משתמשי המערכת מרגישים שהם נמצאים ב"חזית הטכנולוגיה". פועל יוצא נוסף הוא כוח פוליטי בתוך הארגון. השקיפות שהכלי מייצג ש"איפה התהליכים תקועים" טומן בחובו חסרונות (התנגדויות בארגון) אך גם יתרונות (אם עד עכשיו האשימו מחלקה X בעיכוב תהליך מסוים, לאחר השימוש במערכת גילו כי התהליכים בכלל תקועים במחלקה Y).

תהליכים אדמיניסטרטיביים "קלים" לעומת תהליכים "כבדים"
במפגש נעשתה הבחנה בין שני סוגי תהליכים:

• תהליכים אדמיניסטרטיביים
  תהליכים אלה, אשר בדר"כ ממכנים איזשהוא נוהל, ואינם מערבים אינטגרציה לאפליקציות רבות, נחשבים יותר קלים ליישום מצד אחד, אך אין להם תהודה עסקית מצד שני: לדוגמה, תהליכי סבבי חתימות, תהליך אישורי נסיעות לחו"ל צוין כתהליך קל "קלאסי"; קליטת עובד, ולרוב תהליכים סביב נושאי כוח אדם. כמו כן, אחד הארגונים כלל תחת קטגוריה זו תהליכים CRMים שאי אפשר לתת בזמן קצר במערכות CRM.
  באחד הארגונים צוין כי בגלל הקושי לייצר תהליכי WF במערכת ה ERP, אנשים תמיד ימצאו את פתרונות אחרים (מיילים/ידני, באים ל-IT שיפתחו בפורטל מיני-WF), בארגון זה דווקא להכנסה של אלמנטים פשוטים היה impact גדול על המשתמש (לפני כן תהליך מתן הרשאות היה נתקע במייל שבועות וביום שתהליך זה מוכן ב-WF זה עשה שינוי גדול בחברה).
• תהליכים "כבדים"/ליבתיים
  רוב הארגונים שנכנסו לתחום ה-BPM לא מיכנו עדיין תהליכים ליבתיים. ארגון שכן עשה כך סיפר כי הייתה לכך השפעה גדולה בארגון, מה שעזר להמשיך ולהשקיע.
  האם כדאי למכן תהליכים פשוטים אדמיניסטרטיביים או דווקא מורכבים וליבתיים? לא הייתה המלצה ברורה לכך. רוב המשתתפים הסכימו שכדאי להתחיל עם הפשוטים אך השאיפה צריכה להיות טיפול בתהליכים המורכבים, שכן הם גם היותר חשובים ולשיפור משמעותי בהם תהיה השפעה ממשית על הארגון. אחד הארגונים שמיכן הן תהליכים פשוטים והן מורכבים המליץ להתחיל עם תהליכים פשוטים כדי להוריד את הסיכון אבל לשאוף להגיע לתהליכים המורכבים, והמליץ שבמקרה שאכן ממכנים תהליכי כ"א אדמיניסטרטיביים פשוטים - מומלץ ללכת על תהליכים כאלה שבהם התועלת היא מדידה כדי להראות ערך ברור שהתקבל מהמערכת, אבל בסופו של דבר תהליכים "פשוטים" הם לא אלה שיביאו את ה-ROI האמיתי של המערכת. אלה הם תהליכים שכדאי להתחיל איתם כדי לצבור ידע, אך בסופו של דבר המטרה היא להגיע לתהליכים הליבתיים שמשפיעים רבות על הארגון (התהליכים שכדאי לשפר כל הזמן).
  הבעיה עם גישה זו היא שעם המעבר לתהליכים יותר מורכבים פתאום אפשר לגלות שהארגון לקח החלטות מוטעות ושהוא אינו יכול לעבור לשלב הבא משום שהמוצר אינו מתאים, או שאין תמיכה תשתיתית מספיקה ועוד הפתעות לא נעימות.
  אחד הארגונים סיפר כי בצעדי הכניסה של הארגון לתחום, כל הספקים המליצו להם שכדאי לעשות פיילוט לתהליך פשוט שניתן להרים בתוך 3 שבועות. אך ארגון זה החליט שלא להתחיל בדברים הקטנים, למרות שניתן היה בקלות להעביר תהליכים מצומצמים/נהלים פשוטים, מתוך חשש שכשהיו מגיעים לשלב מימוש תהליכים יותר כבדים הם היו מגלים שהכלי בעצם אינו מתאים.

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

מהן הבעיות הצפויות בכניסה ל-BPM? כיצד להיערך אליהן מראש?

• ביצועים
  צריך להיערך לנושא ביצועים, כדי שלא תהיה בעיה לעשות scaling בהמשך. ארגונים סיפרו ששיפור ביצועים ברמה תשתיתית ברגע שהתחום "מתרומם בתוך הארגון", דרש המון משאבים ברמה התשתיתית. יציבות מערכת היא issue. תהליכים שהסתיימו עושים לו archiving. יש לבצע הערכה נכונה של כמות התהליכים שתהיה בשטח. נאלצו לנסות לבנות בדיקה של SLA ברמת ה-activity הבודד בתוך תהליך. הומלץ לחזק נושא run time governance – להיות מסוגלים למדוד כמה ומי פונה לאיזה שירות.
• תחזוקה
  תחזוקה של תהליכי BPM שונה מתחזוקת מערכות רגילה. זו פלטפורמה עם הרבה ישויות שרצות באוויר, versioning. תהליך כבר רץ, מציאת ופתירת הבעיות הנה בעייתית. דרכי ההתמודדות הן גילוי של מה שקרה - איזה service נפל (לצורך זה נדרשים כלי מוניטורינג טובים), והדבר השני –אינטגרציה מערכתית טכנולוגית שמושתתת על patterns.
  כדי לבצע תחזוקה בסביבת BPM צריך לבנות שכבה וירטואלית שתאפשר למדוד SLA. לא מספיק לבנות תווך טכנולוגי של איך השירות עובר ממקום למקום. לצורך זה, ESB יכול לעזור לפתור בעיות כשל. יש לבצע impact analysis - מה קורה אם אני משנה משהו? על מה זה משפיע?

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

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

זמני פיתוח תהליכים
תהליך פשוט (כמו אישור נסיעה לחו"ל) – מאמץ פיתוח התהליך ייקח בין שבועיים לחודש (קלנדרית בין חודש לחודשיים). פרויקט יותר גדול בין חודש לשלושה. לאחד הארגונים יש גם פרויקטים שלקחו חצי שנה.
במיוחד בתחילת הדרך, ארגונים שומעים רבות כי "אם היו עושים את זה בסביבות המוכרות היה לוקח פחות זמן", אבל צריך להבין שעל ידי שימוש בתשתית ה BPM, גם אם זה לוקח יותר זמן, מקבלים יותר, כי קיימת יכולת מדידה של התהליך ושיפורו באופן מתמיד. אבל זה לא פשוט להעביר את המסר בארגון, דורש פעילויות "PR" בתוך הארגון.
מהם הגורמים המסבכים ומאריכים פרויקטי פיתוח תהליכים באמצעות BPM? אינטגרציה, כשהנוהל לא סגור/ או כששינוי הנוהל הוא קשה (אוטומציה של נוהל בדר"כ משנה אותו בצורה מסוימת), ריבוי key users, המשתמש עצמו יכול להיות צוואר בקבוק (אם הוא לא גמיש מספיק).
צויין כי קיימת עקומת שיפור. אחד הארגונים המתקדמים יותר בתחום ה-BPM ציין כי כיום,במצב בו התשתיות כבר קיימות, פיתוח תהליך חדש פשוט נעשה על ידי סטודנט שה skiilset שלו מינימלי. אין שום צורך להכיר JAVA / דוט נט.

מה עם Reuse?
במהלך הדיון עלו נושאים ששייכים לתחום ה-SOA, כמו השאיפה לעשות Re-use של קומפוננטות (כלומר, תהליך שפותח למטרה א' יוכל לשמש גם למטרה ב'). אולם כדי להגיע למצב של Re-use צריך להסתכל על הדברים בצורה מרכזית.
ארגון יחסית מתקדם בתחום (עם עשרות תהליכים באוויר) סיפק כי השלב הבא הוא asset management , עם SLA, וrepository מרכזי. כשלב מקדים, נעשה ניסיון של מיפוי יכולות בסיסיות של השלמת חוסרים. כיום לאותו ארגון יש ארסנל של יכולות קיימות, כך שמפתח התהליכים משתמש ביכולות הקיימות ולא מפתח דברים חדשים.

מפת שוק הספקים – מה השתנה?
ארגונים סיפרו על הרגשת אי נוחות מסוימת, שבה הם אינם מרגישים שיש ספק מוביל ברור. רובם בחנו מספר כלים. ארגון שבחן כלים לפני כ-3 שנים סיפר כי בזמן זה רוב הספקים היו ספקי Workflow, וכיום ניתן למצוא ספקים הרבה יותר אינטגרטיביים הכוללים יכולות רבות תחת אותה חבילה. כמה ארגונים סיפרו על קושי במציאת כל הרכיבים הנדרשים תחת קורת גג אחת, מה שמחייב אוסף של כמה פתרונות (פיתרון BPM, פיתרון אינטגרציה, פורטל, ניהול מסמכים, ניהול טפסים, BAM, סביבת מידול). יחד עם זאת, צוין כי כיום הכלים כבר מגיעים הרב יותר אינטגרטיביים.
מה שמאפיין פרויקטי Human WF – תהליך עסקי שיש בו תחנה של משתמש. העובדה שצריך להציג ממשק למשתמש מחייב שבכלי הנבחר יהיה מסך שיבצע עדכון של נתונים, צריך לאפשר תור עבודה, אקסלציות ודלגציות. יש הרבה pre-requisites טכנולוגיים שצריך לעמוד בהם: לדוגמה, SSO Silent sign on (שלא דורש מהמשתמש להקיש יוזר וסיסמה).

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

בקרה על תהליכים – BAM? BI?
בקרה על תהליכים – activity monitoring עלה כנושא חשוב ביותר שמספק את מירב הערך מהמאמץ. אולם ארגונים שכבר נכנסו לתחום ונכחו בדיון סיפרו כי כרגע הם עושים הכיוון כרגע רישום נתוני BPM איתם אפשר למדוד SLA של תהליך ומיישמים את ה BAM עם תשתית ה BI הקיימת של הארגון (היתרונות - חוסך skills נדרשים נוספים, ומנצל יכולות טבעיות של כלי ה BI הקיימים - תשתיות BI מספקת כלי אולטימטיבי לתת דשבורד שהוא MUST ב BAM).
עשו שימוש בתשתית ה-BI הקיימת בארגונם וחיברו אותה לנתונים המגיעים מה-BPM. ארגון אחד סיפר על בניית עולמות והגדרת אינדיקטורים / מדדים שעל בסיסם יוכלו לבדוק תהליך. הדברים שרוצים לבדוק הנם זמני סבב, צווארי בקבוק, מי מעכב מה, כמה תהליכים הלכו לערוץ מסוים, כמות התהליכים, זיהוי תהליכים שבהם ניתן לשפר (זיהוי קניין עם הזמנות חורגות, צווארי בקבוק טכנולוגיים, איפה המערכת לוקחת הרבה זמן). לתחום זה קראו המשתמשים BPI – business process intelligence (KPIS), "התוצר האמיתי של ה-BPM".

לקחים וטיפים לארגונים הנכנסים לתחום:

• פרויקט BPM מצריך עוד יכולות תשתיתיות שחשוב שיימצאו בארגון. ואם יכולות אלה חסרות, אין ברירה וצריך לקיים פרויקטים של הכנה תשתיתית לקראתו. אחד הארגונים סיפר על תקופת הכנת תשתיות מתאימות שארכה בין חצי שנה לשנה. יכולות אלה כוללות: תשתית ניהול מסמכים (באיזשהוא שלב חוסר קיום תשתית זו יהווה בעיה); סביבה מונחית שירותים ותשתית אינטגרציה. ברוב הארגונים לא קיימת סביבה כזו אך הרבה ארגונים גדולים נמצאים בשלבים התחלתיים.
• מפתח להצלחה - בניית תכנית ארוכת טווח שתכלול שלבים בביצוע, מה צריכים לעשות ולאן רוצים להגיע.
• מחזור איטרטיבי בפיתוח הוא הדבר הנכון (עוזר לא לגלות את הדברים בסוף המשחק).
• גיבוי הנהלה עוזר מאוד, במיוחד באותן נקודות (שצפוי שיופיעו) של הבעת התנגדויות
• הרבה ערך לרכיב ה-BAM. לשקול לשלב אותו כבר מהשלבים הראשונים, לבחון רכיב זה בכלים הנבחנים.
• אם לא קיים, להגדיר תפקיד "ארכיטקט" כבר בשלבים הראשונים, בשלבי ההגדרה של התועלות הצפויות מהפרויקט (לא משמש רק לצרכי BPM כמובן).
• חשוב לזהות את המקומות שמהווים את מנועי השינוי המשמעותיים, ובהם להשקיע.
• להגדיר מדדי KPI לכל פרויקט, מה ROI הצפוי לכל פרויקט (חיסכון בכ"א? קיצור זמן התהליך?)
• אחד הארגונים המליץ לשים את האחריות על אינטגרציה ו BPM ביחד, תחת אותו צוות. באותו ארגון זה היווה יתרון.

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

לצפייה בקובץ של סיכום השולחן העגול המלא לחץ כאן.

כמה זמן העובדים שלכם (ואתם) מבזבזים על חיפוש מידע? יותר מדי!

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

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

אחרי כל החישובים של כמה עובדי ידע יש בארגון וכמה זמן הולך לאיבוד, התוצאה העגומה היא ששווי של 10% ממשכורת של עובד הולך לאיבוד, וזה המס שאנו משלמים על חוסר יכולתנו להתמודד עם עודף (ולא חוסר) המידע.

מחקרים נוספים מראים תמונה בעייתית גם כן, על פי סקר שנערך על ידי חברת Delphi בקרב 300 ארגונים, כ30% מבזבזים מעל 8 שעות בשבוע על חיפושים של מידע אלקטרוני – יום עבודה בשבוע!

סקר של BusinessWeek גורס שאיסוף מידע (וזו כבר הגדרה יותר רחבה) גוזלת מאיתנו 12 בשבוע:

According to a Business Week Online survey, employees spend upward of 12 hours each week on information-gathering tasks.

ועל פי Accenture, רוב המידע שאנו מוצאים בחיפושים האלה בעל ערך נמוך.

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

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.

איזה אפליקציות יותר מתאימות ל- Cloud?

"תשאלו 12 מומחים שונים מה זה Cloud computing ותקבלו 12 תשובות שונות". ממליצה מאוד לצפות בקטע הוידיאו הקצר (והמצוין) הזה, שהציב את השאלה "מה זה לדעתך Cloud computing?" בפני 12 מומחי Web 2.0 כולל Tim O'Reily. התוצאות משעשעות, וגם הטוקבקים, כמו למשל הטוקבק הבא:

"Cloud = internet. OK. I get it."

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

אחת התגובות לוידיאו זה הגדירה זו בצורה תמציתית:

"Cloud Computing to me is running my business with my laptop, on the beach in Mexico, beer in hand and not stressing about keeping the lights on!"

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

התחומים שיותר "תפסו" עד כה ב-SaaS וסביר שיהיו נפוצים יותר ויותר במודל Cloud הנם:
1. HR (משאבי אנוש) – ישנם כל מיני תהליכים בתוך עולם התוכן של ניהול משאבי אנוש שכיום הולכים ותופסים תאוצה במודל ה Cloud – לדוגמה, ניהול תמריצי עובדים (כאן כבר כיום מובילי התחום הנם ספקי on demand), תחום גיוס עובדים ובמיוחד גיוס עובדים באינטרנט e-recruitement.
2. תחומים בהם ישנם גוף חיצוני שיושב בתפר בין כמה ארגונים שמספק שירותי "מסלקה". לדוגמה, תחום ניהול נסיעות עובדים – Travel management שמחובר לסוכנויות שונות ולמערכות הזמנות של חברות תעופה. זהו תחום בו לדעתי ה-Cloud לא רק מספק מודל אלטרנטיבי אפשרי, אלא ערך מוסף ממשי מכך שהאפליקציה יושבת ומנוהלת מחוץ לארגון.

3. CRM (תהליכים ספציפיים בתוך CRM כגון מעקב אחר לידים/ניהול פניות במוקד, ובדר"כ לא CRM כלל ארגוני). כאן הסיבה שהמודל "תפס" היא קצת מלאכותית, זה לא שהשוק חייב שדווקא תהליכי CRM ינוהלו בחוץ, אלא שחברת Salesforce דחפה את המודל בצורה כ"כ חזקה לשוק, כך שהיא למעשה העירה אותו ודחפה אותו קדימה עוד לפני תחומים אחרים. כיום כבר אי אפשר לעצור את התהליך, וחברות רבות מתחום ה CRM הרגיל (on premise) מתחילות לאמץ גם כן את מודל ה-SaaS (סיבל עם Siebel on demand, גרסת ה on demand של מיקרוסופט וכד').

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

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

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

ומה לא מתאים ל Cloud?

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

State of the Knowledge Management market in Israel

In the past several years, KM (Knowledge Management) projects have been given a “bad name” and were associated with failure, lack of integration, and no ROI. Recently, Israeli KM project managers and CKOs (Chief Knowledge Officers) have been trying to come up with new ways for making KM work – new implementation methodologies, new approached, and most are now trying to target specific processes in which KM services can be embedded successfully. In our opinion, KM is becoming more process-dependent and in order to be successfully integrated, KM services should be combined in every-day tasks. We see less and less mega KM projects “just for the sake of KM”. There has to be a specific need, process, and business owner.

I have been talking to many enterprises lately regarding their KM initiatives; There's no doubt that this trend of combining KM within day-to-day processes is a desired goal for most organizations. Timing and context are very important – providing the right piece of information to the right person at the right time, and within the right context is key.
Another hot topic lately for Israeli CKOs is the web 2.0 dilemma. CKOs are wondering, if and how they can implement web 2.0 concepts and tools within the organization boundaries to improve knowledge creation and sharing (Enterprise 2.0).

Much of this interest can be associated with the failure of traditional very centrally managed models. Since the old model is associated with many of the KM failures, organizations are trying to use new models that are almost the opposite of the traditional ones.

Here are some of the main differences:
Traditional KM: Expensive, IT-dependent, complex
Web 2.0 KM: Cheap, simple to set up, run and use

Traditional KM: Top-Bottom, Centrally Managed, controlled
Web 2.0 KM: Bottom-up, decentralized, not “controlled”

Traditional KM: “The larger the org - the harder it gets”
Web 2.0 KM: The larger – the more “searchable”

We estimate that about a third of Israeli enterprises are piloting web 2.0 for internal KM or planning to do so soon. However, there are also many difficulties that can arise in this approach: First, it is not easy turning employees into bloggers, taggers, wikiers. Another factor here is that those who have the most valuable knowledge have the least spare time. We have also seen that organizations are having a very hard time determining the right degree of control over the content creation. Since there is so little experience in Israel with this area, best practices are hard to find, and understanding in which cases these concepts work better than the traditional model and vice versa is very difficult and almost looked upon as a “trial and error”.

Additional popular areas are ECM (Enterprise Content Management), enterprise search, and the use of enterprise portals for KM needs.
Enterprise Search is also a hot topic for large enterprises in Israel in the past year. Several of them are now piloting a few solutions. Up until recently, this was not a very active market in Israel, since prices were higher than what companies were willing to pay for enterprise search. The combination between price decreases, market consolidation and maturity, and the entrance of new, cheaper options to Israel (Google enterprise, Microsoft’s MOSS) led to a lot of interest in this area.