תמונת מצב 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.

מהם הפתרונות שה-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). ניתן להגיע לאותן תוצאות (מיפוי נכון של תהליך) גם ללא כלים ארוזים אלה.

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

Thoughts about disruptive technologies

During 2007-8, SaaS and Web 2.0 disrupted the applications market:

SaaS presented an alternative model for application consumption, and Web 2.0 presented a set of new practices and tools for internal and external collaboration.

During 2008, Social Software and Open Source Applications also started to undermine existing models. Both these areas rely on economies of scale and provide more value the more people use them. Social software is gaining much attention in the global market, while most Israeli organizations aren’t even aware of the possibilities of using these models within the organization walls. We recommend CIOs to start thinking about how social software can help promote their organization on the one hand, and on the other - improve internal collaboration within the organization.

Open source (OS) software is also not yet a hot topic in Israel. While a Cutter IT Study (2008) suggests that 65% of global organizations are already using some kind of open source software, most Israeli organizations we have talked to aren’t considering using OS tools and much prefer the traditional “proprietary” software model mainly due to local support issues. Lately some organizations have began to express interest in open source applications for very specific and limited needs: Electronic Forms, Blogs, Wikis, Search. As one of the IT managers I spoke to told me recently: "open source apps are ok for the internal, IT stuff, but I would never provide open source apps to business users, it's too risky".

SaaS has finally started to enter the Israeli market during 2007 slowly, but surely, mainly due to Salesforce.com’s entrance to the Israeli market. However, there isn’t much activity in the SaaS market besides this vendor. Most user and vendor organizations are still waiting to see what happens in this market before jumping in.

What about cloud computing?

There's no doubt that the current economic situation will do a lot of good for the "cloud concept". Cloud computing, which is essentialy "anything as a service" (XaaS), will fit very nicely into the new paradigm: Service instead of Products.

We don't hear expressed intentions of organizations to start using the cloud for their software/platform needs, but I think that once the services are available, they will attract organizations. The reason will not only be managing costs more easily (cloud services will be considered an expense), but also simply taking all the "headache" out of things that are not in the core business of the organizations, or, in other words - commodity.

Sound familiar? Exactly the same arguments for outsourcing, except today outsourcing is not an "issue" anymore. The same thing will happen with cloud computing. A few years from now, mail and calendering services will mostly be provided through the cloud, as well as other "commoditised" services that the organization doesn't want or need to fuss around.

ERP Lifecycles

The ERP lifecycle within Israeli enterprises is typically divided into 2 main phases:

ERP 1 – the first phase is getting the basic modules (Financials, logistics, and sometimes also HR) up and running, and also reaching stability of the system within the organization. This phase it rather complex, and takes several years to accomplish. The benefits derived from this phase are not entirely clear, but are usually referred to as operational benefits since an ERP 1 is essentially an operations support system. It is seen by most Israeli companies as a “must have” infrastructure that can help the organization in its future plans.

The 2nd phase, however, is meant to better align the ERP package with the business needs. ERP 2 includes implementation of more advanced and specialized modules (for example, project management, asset management, incentives management etc.), recently organizations have started implementing core vertical modules as the 2nd phase of their ERP lifecycle – loans management, core banking etc. Another characteristic of ERP 2 projects is the incorporation of infrastructure-type components that are becoming a part of the ERP’s technological architecture (for example, ERP-specific portals for dedicated ERP processes, DW/BI specific to the ERP data, internal BPM/Integration engine etc.). So ERP 2 is about making ERP work better and easier, and close to the business needs. Another focus point is upgrades to advanced versions. Most Israeli SAP customers have already upgraded or are in the process to upgrade to SAP’s ECC 6.0 version. On average, full upgrade takes 4-9 months and can cost up to $1M in a complex large implementation. Main reason for this upgrade is “staying in-line with vendor” in order to minimize future risk and avoid high maintenance costs (versus pure functional reasons). Oracle ERP shops have been less enthusiastic about upgrading to Oracle 12, most are planning to do so in the coming years but are not in a hurry to do so in the very near future.

But moving from ERP1 to ERP2 is sometimes tricky due to the "shock" that is caused to the organizations after ERP1; Some IT departments are complaining it's hard to get the support of the LOB managers although it's clear that ERP2 presents sibstantial potential benefits. The organization just "wants to relax" and have to stability, so getting on to the 2nd wave will not be so easy.

It's time to manage the customer experience

Meet the next three-letter-acronym in CRM: CEM - Customer Experience Management.

It was bound to come. After so many years of focusing on internal CRM processes (how the organization is working with the customer) now it's time to improve the customer's experience in his/her interactions with the organization.

There are many interpretations to this relatively new buzzword (2003), one of them, by Bernd Schmitt, defines CEM as "the process of strategically managing a customer's entire experience with a product or company."

Everyone wants engagement with the customer. But how do you create a positive customer experience, when each customer has his/her own preferences, and they have different preferences when it comes to different types of transactions.

Right now most organizations don't have these answers. We have only began to scratch the surface on this important area. But I think that we will see pretty soon that companies who can consistently provide a positive customer experience throughout all their touch points with their customers will have a distinct competitive advantage.

After a couple of difficult years, the CRM Israeli market is picking up (10% annual growth). While early CRM projects in Israel (2001-2004) focused on the operational part, in recent years we have seen the focus of CRM projects move to analytical initiatives. I estimate that the next phase will be all about managing customer experience, and the next big challenge is focusing on the touch points with the customer ("Collaborative CRM" or as I like to call it "multi-channel" CRM)– organizations will focus on the channels in which the organization talks to the customer.

These points of interaction include Call Centers, Web, Email, SMS/MMS, and direct mail. In the past CRM projects were all about the internal processes of an organization while dealing with the customer across the service, sales and rarely also marketing touch points. Future projects will force organizations to adopt the customer’s point of view – how does the customer talk to the organization? Or in other words – managing the customer experience. We are already getting a lot of questions from large Israeli organizations with more mature CRM practices about the management of a multi-channel approach towards customers.
Next big spenders in the Israeli CRM market that will enter new CRM projects during 2008-10 are: Insurance & Capital investment companies, and SMBs.

מגמות בתחום ניהול מסמכים ו-ECM

המגמות העיקריות בתחום ניהול המסמכים/ ECM:

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

מגמות ספציפיות בישראל:

בישראל רוב הארגונים בשנים האחרונות ניהלו רק את המסמכים שיש צורך דחוף לנהלם – בעיקר מסמכים "תפעוליים", וגם יוזמות אלו נוהלו בצורה מבוזרת. ברוב הארגונים בישראל קיימים "איים" של נתונים המקושרים למערכות התפעוליות. בשולחן עגול אותו קיימנו לאחרונה בנושא עלו כמה בעיות עם תצורה זו, כאשר העיקרית הנה ביסוס של ארכיטקטורת מסמכים מבוזרת שאינה מאפשרת שיתוף מסמכים בין עולמות תפעוליים שונים (הזמנות מעודכנות במערכת X, חשבוניות במערכת Y). בנוסף, רוב הארגונים בישראל אינם מנהלים בצורה שיטתית את המסמכים ה"רכים" בארגון, וכתוצאה מכך ידע רב אינו מנוצל ותהליכים רבים מומצאים מחדש. אנו רואים כרגע כל מיני יוזמות נקודתיות לשיתוף וניהול ידע שכוללות גם ניהול מסמכים (לדוגמה, ניהול מסמכי אפיון, ניהול דרישות וניהול פרויקטי פיתוח ב-IT). גישות יישום - פיתרון אחד גדול אל מול פתרונות ממוקדיםאנו נתקלים לרוב בהתלבטות בין שתי גישות שונות לניהול מסמכים: גישה ראשונה - פיתרון גדול ומקיף, תשתית ניהול מסמכים אליה ייגשו כל המערכות, גישה שנייה – פתרונות שונים לצרכים שונים (כל מחלקה עם פיתרון מתאים לה).רוב הארגונים הגדולים בישראל (חלקם מתוך בחירה וחלקם פשוט מצאו עצמם במצב זה) נמצאים במצב של ריבוי מערכות ניהול מסמכים לצרכים שונים. ארגונים השואפים לתשתית אחת רוחבית לכלל צרכי ניהול התכנים בארגונם ייטו יותר לכיוון ספקי High End. ארגונים שבוחרים יותר בגישה הנקודתית של מערכת לצורך ספציפי יבחרו מערכת המתאימה יותר לצורך, זה תוך התחשבות בתשתית הקיימת בארגון. יחד עם זאת, יש לקיים הבחנה בין צרכי ניהול מסמכים תפעוליים לרכים. לדוגמה, MOSS לרוב נבחר לצרכי ניהול מסמכים רכים ושיתופיים (עבודה צוותית, פרויקט). לעומת זאת, בתחום המסמכים התפעוליים, בארגונים כבר בהם פועלת מערכת FileNet לצורך ממוקד, הארגון ייטה להשתמש בתשתית זו גם לצורך נקודתי תפעולי אחר. אנו גם רואים לעתים שימוש ב-2 מערכות שונות לצרכים שונים. לדוגמה, ישנם ארגונים שבחרו בכיוון MOSS/SPS לצורך מסמכים רכים, ולצורך מסמכים תפעוליים, במיוחד במקרים בהם נדרשו יכולות פונקציונליות חסרות או יכולת ייחודית (כגון ארכיב) בחרו בפתרונות High End לצרכים ממוקדים אלה.
לסיכום, להערכתנו, רוב הארגונים ימשיכו להפריד בין צרכי ניהול המסמכים הרכים לתפעוליים (מה שגם אומר שבמקרים רבים יהיו מערכות שונות). בתחום ניהול המסמכים התפעוליים אנו רואים רצון לנסות לנהל את כלל המסמכים התפעוליים במקום אחד כדי לטפל יותר טוב בנושא ההרשאות וגישת המערכות למסמכים (בניגוד לגישת ה"איים" הקיימת כיום).

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

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

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

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

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

BPM – מבט קצת אופטימי לעתיד

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

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

את תחום ה-BPM אני נוטה לחלק, בדומה לרבים אחרים, ל-3 חלקים:

• תחום מידול ותכנון תהליכים – BPA - Business Process Analysis


• תחום אקטיב ציית תהליכים


• בקרה וניטור תהליכים – BAM - Business Activity Monitoring

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

בין המניעים שידחפו את תחום ה-BPM לישראל בשנים הקרובות:

• כניסה ל-SOA מחייבת מקום בו מוגדרים תהליכים המורכבים משירותים שונים, כלומר סביבת יצירת Composite Applications. סביבה זו הנה סביבת ה-BPM. ככל שארגונים יבנו תשתיות שירותים, וכלל שארגונים אלה יתחילו להרכיב משירותים אלה אפליקציות חדשות, כך יעלה הצורך בסביבת הפיתוח העתידית שתכלול בין השאר גם יכולות BPM.


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

המלצות ליישומי BPM בארגונים (מניסיון ארגונים בינלאומיים וממעט הניסיון שכן נצבר בישראל):

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


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


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

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.

Software Maintenance in "Post traumatic IT" times

I've been talking to organizations that heavily rely on packaged enterprise applications (SAP/Oracle/Siebel etc.) and are paying considerable annual maintenance fees (typically between 18% - 22% of the software license price). This means that within 5-6 years time the organization has paid the equivalent of a full software license.

On top of this expense, internal dedicated staff that support the ERP/CRM packages is a considerable expense and, meanwhile, it doesn't look like it's getting any smaller.

Enterprise applications have become what is sometimes called "Applistructures" – a combination of software and infrastructure components bundled together. This advent has an implication on the ERP support staff: it is becoming more diverse, more skills are required, and the packages are more difficult to maintain (one CIO told me that in the "good old days" when a specific model had performance issues they knew exactly what to do, nowadays you can never know if the problem is in the application level, portal server, web server etc. so the maintenance is getting more and more complicated as the packages vendors provide more "SOA" elements).

ERP staffing ratios in Israel
A survey we performed among large Israeli enterprises revealed that it takes 1 ERP professional to support 30-50 users (this is in organizations that are relying quite heavily on ERP for a large percent of their business operations); and it takes 1 ERP professional to support 80-100 ERP users in which ERP is "just another application", or, in other words, not a critical one. This means that ERP departments in organizations are quite large, and are usually above 10 people.

How much does it cost to run ERP after going live?
A general "rule of thumb" stated that the cost of maintaining ERP after going live is 1% of the organizations' revenues! This is a very disturbing figure, especially since most ERP packages are not helping companies grow or transform, they are usually helping companies to "keep the lights on" and continue operating pretty much the same way they did.

So - What can companies do to lower these maintenance costs in post traumatic IT times, such as the one we are most likely facing in 2009 and possibly beyond that?

New application packages maintenance models?

An interesting phenomenon (in the worldwide IT market) lately is the use of 3rd party vendors that are offering software maintenance services (for specific software packages such as Peoplesoft, Siebel etc.), for about 50% of the maintenance costs that are paid to the software provider. In exchange, these companies are offering Help Desk services, updates and fixes (at the application level, not technical level), and also tax and regulations updates. For example, Rimini St., (which also lately announced it will soon support SAP at a time when SAP shops are faced with maintenance fees increase from SAP). Another example which was actually founded by the same founder formerly is (was) TomorrowNow, it was acquired by SAP which was sued by Oracle and recently had to close these operations.

While this is a very interesting model that provides some alternative to CIOs, it is definitely not for everyone. It seems to me that a CIO would have to be quite brave to take on this adventure. Sure, it provides great savings each year and frees up much of the budget to be used for better purposes, but it also means that he doesn't have anyone to talk to if there are serious technical issues that can only be solved in the product technology level. The other big implication is that once a major release is out, and an organization has not paid maintenance fees to the vendor, he would have to buy the package all over again.

We have not seen any vendor try to offer this model in Israel, and I'm not sure that we will. It is not a very widespread trend abroad as well, but is definitely expanding. However, this model shows that there is an interest to decrease "keep the lights on" budgets to make more room for "grow" and even "transform" budgets. I think we are expected to see more models around the area of software maintenance that provide lower TCO in the next years.

האם ארגונים כבר מוכנים לאמץ כלי Workflow?

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

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

במטרה לבחון מהי רמת המוכנות של ארגונים לאימוץ שיטות וכלי Workflow, וכן גיבוש טיפים ולקחים מארגונים שכבר עוסקים בנושא, החלטתי לקיים שולחן עגול בנושא.

בין השאלות אותן נעלה בדיון:
· מה מצב שוק ה Workflow בישראל? האם ארגונים עושים שימוש בכלים אלה, ולאילו צרכים? האם לצרכים אדמיניסטרטיביים אשר אינם מטופלים על ידי מערכות אחרות, או האם גם לתהליכי ליבה?
· מה המאמץ הנדרש בכניסה לתחום זה? איך להיערך? מהי עקומת הלמידה?
· עד כמה אפשרי לתת למחלקות עסקיות/אנשי או"ש לתכנן תהליכים בעצמן באמצעות כלים אלה?
· עד כמה ארגונים מאמצים כלים למידול וניתוח תהליכים עסקיים ( Business process analysis, business process modeling tools )?
· כיצד מקשרים את סביבת המידול לסביבת האקטיבציה?
· איך מתמודדים עם מפת הספקים המבלבלת והעובדה שספקי Workflow מגיעים מכיוונים מאוד שונים (ספקי אפליקציות, ספקי WF ייעודיים, ספקי אינטגרציה ותשתיות, ספקי פלטפורמות, ספקי ניהול תוכן וכד')?

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

etty@stki.info ושמרית Shimrit@stki.info או טלפונית בטל': 09-7907000 (אתי או שמרית).
(המפגש מוגבל לארגוני משתתפים בלבד ולא לספקים או יועצים).

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

המפגש ייערך בתאריך 15.12 (יום שני) בין השעות 09:30 – 13:00 ויתקיים במשרדנו שבבני ציון.

איך אתם מקדמים חדשנות בארגון?

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

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

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

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

כיום רוב הארגונים אינם נהנים משירותי IT תומכים לחדשנות, השאלה היא מהם אותם כלים? האם ישנם כלי "מדף" לחדשנות (מושג קצת אירוני בפני עצמו)?

אתר שתפס את עיני הוא האתר הבא, שממפה כלים טכנולוגיים לחדשנות - http://www.innovationtools.com/

כלים אלה כוללים יכולות למיפוי רעיונות ודירוגם, ניהול תהליך של סיעור מוחות, הפעלת תהליכי Workflow לצורך העברת רעיונות לביצוע או בחינה וכד'.

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

כלי חדשנות הם תחום לחלוטין לא מנוצל שטומן בחובו פוטנציאל רב לחילול שינוי משמעותי בארגון. האם יש מקום לכלים אלה, שנחשבים Nice to have ובוודאי לא נכנסים תחת קטגוריית Keep the lights on בסעיפים התקציביים, גם בתקופות כלכליות קשות כזו שמצפה לנו ב-2009? פרויקטי ה Nice to have יהיו הראשונים שיקוצצו, אך מצד שני - פרויקטים אלה אינם יקרים כלל. ניתן ליצור בקלות ובמהירות סביבות להעלאת רעיונות על ידי העובדים ודירוגם על ידי שימוש בכלי בלוגיים חצי חינמיים (במקרה זה האתגר היותר גדול הוא ליישם תהליכים ארגוניים שידעו לנצל רעיונות אלה כמו לדוגמה בעל תפקיד שאמור לעבור על רעיונות אלה).

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

שולחן העבודה של נציג השירות - סיכום שולחן עגול

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

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

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

מפגש זה עסק בניהול, עיצוב, תכנון, ותפעול שולחן העבודה של נציג השירות. התחומים שהוזכרו בדיון:
EPSS - Electronic Performance Support Systems
Unified Desktop
כלי- Interaction Management לצורך שיפור וייעול התהליכים המתבצעים מול הלקוחות במוקדי שירות הטלפוניים.

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

• מהן הבעיות הקיימות כיום במוקד השירות?
• EPSS - מה התועלות וממה להיזהר? למי זה מתאים?
• Unified desktop - האם יש מספיק ניסיון, ובמיוחד בארץ, בתחום זה?
• מה הגבול בין מערכות תפעוליות ל-CRM?

שנה טובה!

שתהיה שנה נהדרת, מוצלחת, מלאה בעשייה מעניינת, בריאות, אושר ואהבה!

מהו ה-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, זהו עיתוי מצוין להרחבת מעגל המשתמשים והעלאת הערך של שירותיהם.

מה מצב השימוש בWeb 2.0 בתוך הארגון?

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

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

דוגמאות של יוזמות Web 2.0 בתוך הארגון עליהן סיפרו המשתתפים:

• יישום בלוגים ברשת האינטרה-נט הפנימית
• תכנון ליישום רשתות חברתיות בתוך הארגון (מעין פייסבוק מנוון פנימי) במטרה ליצור רשת ארגונית. התועלת העיקרית הצפויה ממיזם זה הנה לקהל על התקשורת הארגונית, במיוחד בפרויקטים ומשימות חוצות ארגון.
• רצון לבניית רשת חברתית ארגונית במודל LinkedIn, לצורך כך צוין שימוש בכלי open source. צוין גם כי case study של חברה שיישמה רשת חברתית מה שתרם לרמת עזיבה מופחתת של העובדים.
• אתרים פנימיים שיתופיים באופיים, פורומים וקהילות. אחד הארגונים כבר עובד שנים עם אתרים שיתופיים מסוג זה ומציין רמת שימוש גבוהה בהרבה ממחלקות הארגון. הידע השיתופי שנמצא בפורטלים/אתרים שיתופיים אלה מהווה מקור מידע נוסף למידע ה"מוסדר" הארגוני (נהלים, חוזרים).
• שימוש בטכנולוגיות מעולם ה Web 2.0 – צוין שימוש בAJAX גם לצורך אתרים פנימיים
• ארגון גלובלי ציין ערך מוסף בכלי Web 2.0 בארגונו לעומת ארגון שפחות מבוזר. בארגון זה גם לטכנולוגיית AJAX יש ערך מוסף גדול בשל בעיית ביצועים שנוצרת כשעובדים המפוזרים במקומות שונים בעולם מנסים לגשת לפורטל הפנימי.

סוגיות בעייתיות (ופתרונות שהוצעו) בהקשר של Web 2.0 פנים ארגוני:

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

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

חיפוש שולחני - Desktop Search

בזמן שכלי חיפוש שולחני (Desktop Search) נעשים יותר ויותר נפוצים, ברוב המקרים למחלקת ה IT אין מדיניות מוצהרת באשר לשימוש בכלים אלה - באילו כלים להשתמש? האם ניתן/לא ניתן להוריד כלים "חינמיים"? היכן ניתן לחפש?

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

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

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

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

סיכום שולחן עגול בנושא אסטרטגיות אתרי אינטרנט

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

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

• Web 2.0 באתר האינטרנט החיצוני
• Web 2.0 בתוך גבולות הארגון
• סוגיות ארגוניות – מי אחראי ליוזמות אינטרנט בארגון?
• Self Service באתרים חיצוניים - עד כמה מודל שירות עצמי "תפס"? מהן התועלות הצפויות? כיצד לעודד לקוחות לעבוד במודל שירות עצמי?
• האתר ככלי להכרת הלקוח ופרסונליזציה - עם דגש ספציפי לגבי נושא כלי ניתוח אתרים (Web analysis)
• הקשר בין CRM לאתר האינטרנט עולמות וירטואליים

Open Source בעולם האפליקציות

תחום ה Open Source והשפעתו ספציפית על עולם האפליקציות הולך וגדל בצורה מתונה בעולם.

אולם בישראל לא ראינו עדיין אימוץ משמעותי של open source על ידי ארגונים ואפילו ישנם ארגונים שבהם קיימת מדיניות נגד שימוש במוצרים אלה. ארגונים שכן אימצו מדברים לרוב על Linux ברמה התשתיתית. אבל מה קורה עם אפליקציות open source? יש סיכוי שארגונים יכניסו אותם לצרכים אפליקטיביים שונים בארגון? ואם כן, לאיזה צרכים?
מאמר שהתפרסם לאחרונה ב CIO Insight מדבר על המצב בשוק העולמי, שם העניינים מתחילים לזוז קצת יותר מהר אבל הרבה מהחסמים שקיימים כאן משפיעים גם על חברות בינלאומיות.

החששות:
אבטחת מידע ונושא התמיכה נותרים כחששות העיקריים מהכניסה ל open source. בישראל חשיבות התמיכה גבוהה עוד יותר, שכן יש חשש תמידי ממוצרים שאולי מאוד מובילים בחו"ל אבל אם אין תמיכה מקומית לעתים מנמ"רים יוותרו על השימוש במוצר, למרות מובילותו הפונקציונאלית.
ישנו חשש נוסף שהתחלנו לשמוע לגביו, והוא הנושא המשפטי. מה המשמעויות המשפטיות של שימוש בתוכנת open source? אם הארגון מפתח פיתוחים נוספים האם הוא נדרש לחלוק אותם עם הקהילה? ואם ארגון מוכר מוצר שמתבסס על open source, מהם בדיוק חובותיו?

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