יום חמישי, 28 באוגוסט 2008

מה מצב השימוש ב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, קופרניק) ניתן למצוא כאן.

יום חמישי, 21 באוגוסט 2008

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

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

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

יום שני, 18 באוגוסט 2008

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

יום חמישי, 14 באוגוסט 2008

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

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

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

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

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

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

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

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

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

יום רביעי, 13 באוגוסט 2008

ארכיטקט ERP – תפקיד חדש בארגון?

הארגונים העוסקים ב ERP לרוב מכירים את המונח (ERP COE (Center of Excellence שמהווה מרכז ההתמחות של ERP בארגון. זה הפך להיות best practice לארגונים העוסקים ב ERP (ובמיוחד אלה המשלבים את ה ERP בפעילויות הליבה שלהם) להקים COE שמעבר למתן שירותי תמיכה "סטנדרטיים" גוף זה מתווה מפת דרכים להתפתחות ה ERP בעתיד, נמצא עם יד על הדופק בנוגע להתפתחויות עסקיות חדשות, בוחן את אופן ההטמעה, וחלק מתפקידו של ה-COE הנו גם התעדכנות לגבי ה roadmap העתידי של ספק ה ERP, מה שנעשה לרוב על ידי קשר הדוק עם הספק עצמו, התעדכנות על ידי אנליסטים ויועצים, וכן שותפות בקהילות משתמשים שונות.
יחד עם זאת, בארגונים לאחרונה צומחת פונקציה חדשה שנראה שרק תלך ותהפוך ליותר ויותר חשובה הן בעולם ERP והן בעולם הIT הקלאסי – Enterprise Architect (לעתים מתייחסים לתפקיד זה בתור ה CTO החדש, בניגוד ל CTO שאנו מכירים כיום שמרוכז בעיקר סביב נושאים תשתיתיים). תפקידו של הארכיטקט הנו להוות תווך בין הצרכים העסקיים המשתנים של הארגון ובין אופן התפתחות ה-IT, כולל התוויית תכנית עתידית וגיבוש ארכיטקטורה. כמו כן, חלק מתפקיד הארכיטקט/CTO הנו לבחון טכנולוגיות חדשות, כאשר היתרון העיקרי הוא שלפונקציה זו יש מידע עדכני לגבי הצרכים העסקיים של הארגון – לאן הארגון רוצה להגיע, אילו שירותים המחלקות העסקיות צריכות, סדרי עדיפויות בין הצרכים השונים. פונקציה זו – הארכיטקט – לרוב כפופה למנמ"ר.
תיאור תפקידי ארכיטקט הERP (לקוח מתוך אתר של קהילת Netweaver) ניתן למצוא
כאן.
אין כל חשיבות אם מדובר בארגון שעושה שימוש ב SAP או באורקל. היישומים הופכים להיות יותר מורכבים, סביבות הניהול משתנות והופכות להיות יותר SOA, ותפקיד הארכיטקט לנושא ה ERP הופך להיות יותר ויותר חשוב.

ארכיטקט אינו מושג חדש במחלקת ה-IT אך אין ספק שלאחרונה הוא הופך להיות יותר ויותר חשוב. קיימנו מפגש שולחן עגול, אליו הגיעו ארכיטקטים וכן CTOs. כמה מהתובנות שעלו מאותו המפגש:
  • הגדרה של פונקצית ה-CTO/ארכיטקט – ישנם ארגונים בהם ישנה הגדרה ברורה של CTO וארכיטקט, כאשר בד"כ הפונקציה של CTO הנה ותיקה יותר ובכירה יותר. באופן כללי, ה- CTO אחראי על בחירת טכנולוגיות בארגון באופן כללי (מהו הסטנדרט שיהיה מקובל בארגון ?) והארכיטקט אחראי על בחירת טכנולוגיות ספציפיות לפרויקט (באיזה שרתים ואחסון ישתמשו לפרויקט ספציפי- ERP? האם יהיה שימוש ב- CLUSTER? וכו'). ישנם ארגונים בהם התפקידים של CTO וארכיטקט הנם תפקידים מקבילים, כאשר ה- CTO עוסק בתשתיות והארכיטקט עוסק באפליקציות\תוכנה. ישנם גם ארגונים בהם תפקודי ה- CTO או הארכיטקט מהווים חלק מתפקידו של מנהל התשתיות.
  • מעורבות הארכיטקט\CTO בפרויקטים חדשים – ישנם ארגונים בהם ישנו תהליך מובנה וברור של התנעת פרויקטים חדשים בהשתתפות נציגי גוף ה- CTO\ארכיטקט. לעיתים ההתנעה מלווה בהליך של Architecture Review ולאחר מכן בתהליכים של Design Review. מצד שני, ישנם ארגונים בהם תהליך זה לא קיים כלל או שלחילופין, השתתפות נציגי גוף ה- CTO\ארכיטקט הנה וולונטרית – כלומר, על פי הצורך. אז מתגלה לעיתים שישנה בחירה בטכנולוגיה לא מתאימה או פיתוח של פונקציונאליות שכבר קיימת בארגון. ברוב המקרים פרויקטים גדולים זוכים במלוא תשומת הלב, אולם פרויקטים קטנים או לחילופין פרויקטים דחופים לא עוברים במסלול המלא וגם אז מתגלות בעיות – כשהפרויקט נמצא כבר בייצור\תחזוקה ואז כמובן עלות התיקונים גבוהה. כלומר, ישנה חשיבות גדולה לעובדה שה- CTO\ארכיטקט יהיה דמות שרוצים להתייעץ איתה ולא מאוימים על ידה. הערה חשובה: אין ספק שתהליך מסודר ומובנה של התנעת פרויקטים מעכב את הפרויקט ויוצר תקורות. אכן, נציג אחד הארגונים היעילים בתחומו (לעומת ארגוני IT מקבילים בתעשייה) ציין שבארגונו לא קיים תהליך מובנה וכבד. חשוב לציין שבפורום זה של CTO וארכיטקטים לא נשמע קולם של מנהלי הפרויקטים שעשויים להתלונן על "בירוקרטיה" באישור הפרויקט...
  • אכיפה – רוב הארגונים ציינו שבכל מקרה לא מדובר באכיפה קפדנית של החלטות (והסטנדרטים) של ה- CTO\ארכיטקט. הסיבה לכך היא קיומה של דילמה בין האכיפה של סטנדרטים והמלצות של גוף ה- CTO\ארכיטקט לבין האינדיבידואליזם של הפרוייקטור\מפתח. ברור שלא רוצים "לדרוס לגמרי" את האינדיבידואליזם.

יום שלישי, 12 באוגוסט 2008

מה קורה כשספק פתאום מעלה את אחוזי התחזוקה?

SAP הודיעה בחודשים האחרונים שהיא תעביר באופן הדרגתי את לקוחותיה למדרגת תחזוקה יותר גבוהה, מה שאומר שהיא תעלה הדרגתית את עלויות התחזוקה שלה מ 17% (לארגונים שהשתמשו בחבילת התמיכה הבסיסית) ל-22% עד 2012.

מאז הידיעה שיצאה בחו"ל, יצאו עוד כמה ידיעות שמראות שארגוני משתמשי SAP מאוד לא מרוצים מהמהלך.

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

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

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



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

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

יום חמישי, 7 באוגוסט 2008

מה זה בכלל Cloud Computing?

כמו בכל תחום חדש והייפי, בשלבים ההתחלתיים של השוק יש בלבול מושגים, ואותו מושג משמש פעמים רבות לתיאורים שונים שמאחוריהם כוונות שונות לחלוטין.
אותו הדבר קורה עם Cloud Computing. אנשים איתם אני מדברת על התחום מגדירים Cloud Computing לעתים בתור ה"דור החדש" של התוכנה כשירות (SaaS - Software as a Service), לעתים אנשים מתייחסים לנושא זה כ"מחשוב כשירות" - כלומר, האפשרות לעשות שימוש במשאבי ותשתיות מחשוב בתצורת שירותים.
השבוע נתקלתי במונח שלדעתי מתאר את ה Cloud Computing בצורה הטובה ביותר, וממחיש את גודל האמורפיות של מושג זה: "Anything as a Service" או בדרך הקיצור: XaaS.
המאמר המספק הגדרה זו מתאר מצב בעתיד בו המיקום בו נמצאת תוכנה כלל לא ישנה, ואף מתאר מצב בו מי שכן יחזיק תוכנה אצלו "בבית" ייחשב לבזבזני מכיוון שיהיה עליו לתמוך בתשתיות המחשוב התומכות באותה תוכנה בעצמו.
לדעתי, חזון זה הנו אפשרי. מערכות המידע העתידיות מתפתחות בכיוון זה, המחסומים הטכנולוגיים מוסרים לאט לאט, מניעים נוספים כגון הגדלת הניידות, שיפורים באבטחת המידע, התפתחות ארגונים לכיוון ארכיטקטורות SOA, וכן הסרת המחסומים הפסיכולוגיים, כל אלה תורמים להיתכנות של הפיכת מודל Cloud computing למודל שישנה את מערכי ה-IT של ארגונים בתוך מספר שנים.
בחו"ל כל מספר חודשים נערך סקר שמראה עד כמה ארגונים מאמצים תוכנות/מחשוב כשירות, ואחוזים אלה גדלים בקצב מהיר. לדוגמה, קצב אימוץ תוכנות כשירות בתחום ה-CRM הרבה יותר מהיר מקצב אימוץ תוכנות CRM כשירות.
אבל לא מדובר רק על תוכנות, מדובר על סביבות מחשוב שלמות המסופקות כשירות, כולל סביבות פיתוח בתוך ה-
"Cloud". אין ספק שכאשר IBM, גוגל, אמאזון, DELL, Salesforce מחליטות להשקיע כל כך הרבה כסף, שחלקו כרגע מושקע במחקר ופיתוח, בתחום ה Cloud Computing, התחום הזה עוד צפוי להשפיע רבות על הדרך בה נשתמש ונצרוך משאבי IT בעתיד.

ניתן לצפות במצגת של ג'ימי על התחום כאן.

יום רביעי, 6 באוגוסט 2008

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

לאחרונה ערכנו מפגש שולחן עגול בנושא מוקדי שירות. השאלות שעלו בדיון:
  • תמונת מצב קיימת במוקד השירות בארגון - באילו כלים משתמשים כיום? האם בעיקר ב CTI ו IVR או האם טכנולוגיות יותר חדשות מיושמות?
  • מעבר למודל שירות עצמי – משתתפי הדיון הביעו רצון של ארגונם להיכנס יותר ויותר ליוזמות אלה. במפגש דובר על ניסיון קיים, פרויקטים עתידיים, אתגרים והתלבטויות.
  • אימוץ טכנולוגיות חדשניות במוקד השירות – Emotion Detection, Speech Recognition
  • אחריות ארגונית למוקד השירות, אחריות טכנולוגית למוקד השירות. מיהו האחראי בארגון? כיצד עובדות יחד המחלקה העסקית והמחלקה הטכנולוגית? והיכן האחריות נופלת?

תוכלו לצפות בסיכום מפגש זה כאן.