רשמים ממפגש שולחן עגול - SAP

מפגש זה היווה גיבוש של קבוצת עניין אשר בעתיד תיפגש בנושאים שונים שמנהלי אפליקציות בסביבת SAP נתקלים בהם. הנושאים העיקריים שעלו במפגש ראשון זה:

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

גודל מחלקת ה-ERP SAP
לרוב הארגונים מחלקות ERP די גדולות לצורך תמיכה שוטפת ב-SAP. מבין משתתפי הדיון, מס' אנשי מחלקת SAP נע בין 10 ל-100, ובממוצע 30 איש. החלוקה לתפקידים השונים:

מיישמים: 60%

מפתחים: 17%

BASIS: כ10%

אחר: 13%

רוב המאמץ מוקדם לחידושים ופיתוחים (כשני שליש) והשאר לתחזוקה. לדוגמה, באחד הארגונים מחזיקים מיישם לכל מודול רק לעניין תחזוקה, ופי שניים לחידושים ופיתוחים.
בארגון אחר 70% שו"שים ו-%30 תחזוקה (שזה הרבה פעמים גם הדרכה). לגבי התחזוקה, בארגון אחד צוין כי מאמץ התחזוקה הרבה יותר קטן - על 3 מודולים מחזיקים מיישם שלהם + חלקיקי משרות מבחוץ.

יחס ERP Staffing למספר המשתמשים
מספר המשתמשים ב-SAP בארגון בממוצע עמד על 1800 משתמשים (נע בין 200 ל 6000). יחס אנשי ה-SAP בארגון (כולל מיישמים, מפתחים תמיכה basis וכד') למס' המשתמשים בממוצע עמד על 1:66 (איש SAP אחד על כל 66 משתמשים ב-SAP), אך הייתה שונות גדולה מאוד מארגון לארגון במדד זה (לדוגמה, ארגון עם יחס של 1:10 לעומת ארגון עם יחס של 1:110).

המודולים שארגונים מתכננים ליישם ב-SAP
צוינו מספר יוזמות שונות שהם מתכננים להיכנס אליהם:
· שדרוגים: ECC, CRM
· איחוד דוחות
· העמקת כניסה לפורטל כולל ESS
· PLM
· SRM ניהול ספקים
· PM מודול אחזקה
· APO – על מנת לעבור לניהול מלאי גלובלי
· העמקת יישומי SOA ויישומי אינטרנט
· שיפור ממשק המשתמש (כיום מסורבל ולא נוח)
· מתכוונים להעמיק שימוש בפורטלים כדי לחזק את ההטמעה

SAP Portal
75% ממשתתפי הדיון כבר עושים שימוש כיום ב- SAP EP, רובם עושים בו שימוש כפורטל תהליכי (שכבת פורטל מעל תהליכים המנוהלים בסביבת ה-SAP), אחד מהמשתתפים עושה בו שימוש כפורטל ארגוני "רוחבי" (מעין אינטרה-נט) בלבד, רק מספר בודד של ארגונים משתמשים בו הן כפורטל ארגוני רוחבי, והן כפורטל תהליכי מעל SAP.

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

• ניהול HD יותר חכם – אחד הארגונים ציין כי את כל ניהול הקריאות עושים כעת דרך ה solution manager, מה שצפוי להוריד את כמות הטלפונים כי התהליך הוא אינטראקטיבי. חלק מהמשתתפים בדיון העלו הסתייגויות לגבי מוכנות המשתמשים לפתוח משם קריאות? עקרונית זה לא צריך לשנות למשתמש. היתרון הוא שהמשתמש מקבל את כל הנתונים של התקלה, השאלה היא אם הוא יאמין בזה ויתמיד בשיטה.
  מערך התמיכה – Help Desk
  קיימות בין 2-3 רמות: 1st, 2nd ולעתים גם 3rd level support:
  · 1st level support (לדוגמה, סיסמה, הרשאות) ניתן על ידי ה-HD, לרוב ה-HD הכללי של ה-IT.
  · 2nd level support - אנשי מפתח במחלקות עסקיות. עשוי להיות יותר מאדם אחד בכל תחום עסקי.
  · 3rd level support – מיישמים. נותנים מענה לתקלות יותר גדולות.
  אחד המשתתפים ציין כי בארגונו בנו מחלקת תמיכה ייעודית ל-SAP שבה יושבים משתמשי מפתח שהועברו למעשה לשבת תחת חסות ה-IT. לא אצל כל המשתתפים הופיעו 3 רמות אלה, בחלקם קיימת ה 1st level support ואחריה ישנם מומחי יישום – שעדיף שיבואו מהמחלקות עצמן. בכל אופן, ברור כי לצורך התמיכה המעמיקה יותר יש צורך להבין תהליכים עסקיים.

שימוש בכ"א חיצוני
בדיון עלתה הסוגיה של שימוש בחברת יישום גדולה לעומת שימוש פרטני ביועצים עצמאיים.
כשעובדים עם חברה גדולה עם חלקי משרות יש יתרון (אם חולה יגיע מישהו אחר) החיסרון – האפשרות שחברה גדולה תשלח כ"א לא מיומן שהחברה מרוויחה עליו עשרות אחוזים.
הצעות שעלו במידה ומשתמשים בחברה גדולה: אם מחליפים מיישם זה צריך להיות בהסכמה, וכן לבדוק אפשרות של קבלת מיישם "JUNIOR" במחיר מופחת/חינם לתקופה מוגבלת של למידה, ולאחר תום תקופת הלמידה לעבור לתשלום רגיל.
לגבי השימוש במיישמים עצמאיים – צויין כי שימוש בכ"א זה בפירוש כרוך בעלויות לא זולות אבל יש אפשרות לקבל כ"א טוב ביותר עם 10-15 שנות ניסיון. הבעייתיות כאן היא השאלה עד כמה ניתן וצריך לסמוך עליהם בזמנים בעייתיים. בחברות הגדולות מרגישים קצת יותר בטוחים במובן זה.
צויין כי ישנם אנשים טובים גם בחברות גדולות ובסה"כ אם משלמים את התעריפים המבוקשים - יקבלו כ"א איכותי בחברות הגדולות גם כן.
האנשים הטובים באמת שווים את התוספת במחיר במיוחד לתחומים בהם חסר ידע. אחד המשתתפים סבר כי לתחומים הפשוטים כמו פיננסי FI MM חבל לקחת חברות גדולות, משום שזה commodity. באזורים של פחות ידע אין ברירה וצריך וכדאי לקחת כ"א יותר טוב גם אם זה אומר שימוש ביועצים פרטיים.
ההבדל בין מיישם טוב למצויין יכול להיות 30% ו 300% בתפוקה בתנאי שיודעים להפעיל אותו נכון. מיישם של 280 ₪ - אפשר להביא אותו פעם בשבוע ולתת לו רשימת X בעיות והוא עשוי לפתור תוך רבע שעה בעיה שאחרים אמרו שתיקח שבועיים. יש תשומת ניהול במקרה ולוקחים יועצים פרטיים, אבל התארגנות נכונה יוצרת ניהול טבעי. אחד הארגונים המשתתפים בדיון סיפר כי בארגונו כך עובדים, והם מזמינים פרילנסרים כאלה שבאים והולכים.
נקודה חשובה שצוינה - שווה לשלם את ה 300 ₪ לאותם אנשים שלעתים מכונים "כוכבים" אבל בתנאי שהיועץ השאיר לא רק את הפיתרון אלא גם את הידע על הפיתרון. כלומר, המצב הרצוי הוא לא רק שיבוא ויפתור את הבעיה, אלא שיהיו איתו אנשים מהארגון שילמדו מה הוא עושה.

BW - BI
אחד הנושאים שעלו בדיון הנו נושא ה-BW. הבעיות שצוינו - זמני גזירות ארוכים מדי ל-BW מאוד גדול (יחד עם זאת, צוין כי לא ייכנסו ל BIA – BI Accelerator בגלל שיקולי עלויות), שני ארגונים העריכו גם כי רמת השירות/יישום של BCS ו-BW בארץ עדיין די נמוכה.
תוארו מקרים של עבודת עלי BI צד שלישי מעל סביבת ה-SAP BW: באחד הארגונים הוטמע כלי BI של qlikview מעל סביבת ה-BW (צוין כי בארגון זה זהו לא כלי אונליין ולא תחליף לדוחות ב SAP), ובשני הוטמעה סביבת Cognos מעל BW (כולל נושא של מדדים KPIs). בשני הארגונים ישנה שביעות רצון די גבוהה.
מוצרים משלימים:
אחד הנושאים שעלו בדיון הנו נושא המוצרים המשלימים לסביבת SAP שיכולים לעזור בעבודה יותר יעילה, לקצר זמני תחזוקה והדרכה. הכלים שצויינו:
· Epiuse (נציגה בישראל: נס) מסייע בתהליכי גזירה סלקטיבית, שולפים אוכלוסיה ספציפית מה-SAP.
· קוגנוס – צויין שימוש בקוגנוס מעל תשתית ה-BW בשילוב עם תשתית נתונים אחרת לצורך BI, וכן KPIs, BSC - מפה אסטרטגית עם מדדים מקושרים. צוין כי החיבור ל-SAP היה קל.
· Itemfield כמיפוי לטובת ה-XI.
· IXOS (Open Text) - לארכוב מסמכים.
· Zoptions (בייצוג נס) לקליטה של פקודות יומן (יכול להוציא מהאקסל לפקודות יומן).
· זירוקס - OCR עם תמיכה בעברית.
· Printboss – לעיצוב פלטים וגם צוין שימוש בכלי לצורך תרגום שפות (מחזיקים ב SAP רק באנגלית).
· בבילון – ככלי שחוסך זמן ומעלה רמת אפקטיביות ארגונית

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

מודול אחזקה - PM
בדיון דובר ספציפית על מודול אחזקה (הן לצורך אחזקה מתוכננת והן לאחזקת שבר) ומידת בשלותו, ותהליך ההטמעה שלו. רוב הארגונים תיארו כי לפני השימוש במודול זה נעשה שימוש בעוצמה 10 (מוצר בתחום האחזקה).
מספר ארגונים סיפרו כי מודול ה- PM נותן להם מענה טוב לצרכים (הן תחזוקת שבר והן מתוכננת) וכי הדבר החשוב ביותר היא מיהו המיישם ומשתמש המפתח – צריך שיהיה אחד שמבין את הראש של SAP ויודע מה התהליכים העסקיים. צוין שימוש בPM גם לספירת ציוד (שכבר הופחת אבל קיים). בחלק מהארגונים לא כל נושא התחזוקה עבר ל-PM (לדוגמה, תחזוקת IT) אך ברובו כן.
היתרון שצוין לשימוש במודול PM הנו האינטגרציה עם המודולים הפיננסים, כמו כן צוין כי ניהול סריאלי – נוח ב PM, וסוכם כי זהו מודול פשוט יחסית ולא מורכב. שימושים שצוינו במודול זה (לדוגמה):
· ניהול צי רכב של רכבים כבדים – אחזקת שבר ומונעת: הפעילו מוקד מנהלות, כל הקריאות מנוהלות, כולל שליחת SMSים. הפעילו PM על ניהול עבודה דיווח פרויקטים ותחזוקה.
· ניהול מלאי של רכיבים וברגים.
· חיבור למערכת ייצורית (פתיחת פקודת אחזקה כאשר יש בעיה במכונה)
· הכנסת PM לניהול מתקני הרמה (בשל רגולציה). היישום התנהל ללא קשיים ובכ"א מינימלי (מיישם אחד עם יועץ junior) הלכו על הסטנדרט (לא עשו פיתוחים).

לצפייה/הורדת סיכום הדיון המלא לחצו כאן.

רשמים ממפגש שולחן עגול - Oracle Applications

בדר"כ מפגשי שולחנות עגולים שאנחנו עושים סובבים סביב תחום טכנולוגי - ניהול מסמכים, BI, ERP, CRM, ולא סביב סביבה טכנולוגית ספציפית (אורקל/סאפ/מיקרוסופט...). החלטנו לחרוג ממנהגנו ולערוך 2 מפגשים מקבילים:

• מפגש למנהלי אפליקציות בסביבת Oracle Applications
• ובמקביל - מפגש למנהלי SAP

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

הנה מידע (חלקי) לגבי כמה מהנושאים שעלו:

מבנה מחלקת ה-ERP - Oracle
בארגון ה IT לרוב קיימות מספר מחלקות פיתוח ומחלקת הERP מהווה רק אחת מהן, לצד מחלקות CRM, ליבה/בילינג/בנקאית, BI (וזה במקרה בו ה ERP מהווה "עוד מערכת" ולא המערכת העיקרית). לעתים קיימות מחלקות "רוחביות" נוספות (לדוגמה, מנהלי פרויקטים רוחביים).
בתוך מחלקת הERP, ישנה חלוקת תפקידים ל:
1. מיישמים (לרוב מתפקדים גם כתומכים),
2. תכניתנים (ERP ו CRM – צוותים שונים),
3. אנשי "תשתיות ייעודיות"/DBAs.
חלוקה נוספת הנה מקצועית - אנשי לוגיסטי, פיננסי, HR.

יחסי כוח אדם
אחוז אנשי מחלקת הERP מכלל אנשי ה-IT נע בין 3% (בארגון בעל יחידת IT מאוד גדולה ובו ה-ERP אינו מנהל את ליבת הארגון) ל-20% (בארגון בעל יחידת IT קטנה יחסית וERP שמנהל את ליבת הארגון).
מתוך צוות הERP: 65% אנשי יישום ותמיכה, 35% אנשי פיתוח ו-DBA
יחס של בין 1:20 ל1:50 (על כל אדם אחד במחלקת ה ERP יש 50 משתמשים בERP)

שימוש בכ"א חיצוני
רוב משתתפי הארגון משתמשים בכ"א חיצוני במידה מינורית. בין היתרונות שצוינו – כוח האדם החיצוני מקדם מבחינה מקצועית את צוותי הפיתוח.

ניהול תצורה וגרסאות
צוין כי נושא ניהול השינויים קיים באופן מאוד חלקי באורקל, הנושא שחסר באופן מיוחד הנו נושא העברת גרסאות. בארגונים שונים פותחו יכולות סביב זה או שמשתמשים במוצרי צד שלישי (כמו לדוגמה מוצר של חברת Unitask). בגרסאות הבאות לאורקל יהיה כלי לניהול enterprise manager. יהיה סוג של addon שם לאורקל APPS.
מספר הקסטומיזציות שארגונים היותר גדולים במפגש ביצעו נע בין 900 ל 1900. אופן
ניהול שינויים אצל אחד מהמשתתפים – כל פיתוח מנוהל כקסטומיזציה, כל קסטומיזציה באיפיון "מתגלגל" (מתקדם בגרסאות). יש להם מערכת ניהול תצורה Starteam שבה הם מנהלים את הקסטומיזציות.
כל כמה זמן מעבירים שינויים לפרודקשן? בארגון בו ל IT יש יותר כוח אל מול הארגון שינויי ה ERP מועלים במסגרת "גרסת IT" כל 3 חודשים (כלומר, כל המערכות עולות באותו יום, ה ERP לא עולה בנפרד). ארגונים אחרים ציינו שדבר זה לא יתקבל בארגונם וכי לוחצים עליהם לשחרר גרסאות יותר מוקדם.
רוב המשתתפים עובדים ב 4 גרסאות שנתיות. אצל אחד מהם משתדלים בכל חודש להעלות מיני גרסה ופעם ברבעון להעלות גרסה גדולה. משתמשים ב HARVEST לאריזה (העברה של תכנה). אם יש setups שניתן להעביר דרך תשתית אורקל.

לחצו כאן לצפייה והורדת סיכום הדיון המלא.

בהמשך אעלה גם את סיכום השולחן העגול בנושא SAP.

כנס שנתי STKI - 24 מרץ 2009

לאתר הכנס והרשמה - לחצו כאן.

תובנות ממפגש סיעור מוחות בנושא Cloud Computing, SaaS

ערכנו מפגש סיעור מוחות ראשון מתוך סדרת מפגשים צפויים. המפגש הראשון היה סביב נושא מתבקש במיוחד - Cloud Computing ו - SaaS - Software as a Service

מהם מפגשי סיעור מוחות?

• מפגשים של כ15-20 CTOs/ארכיטקטים, יועצים, אנליסטים של STKI, ואנשי חשיבה בתחומים טכנולוגיים שונים.
• במפגשים אלה משתתפים הן ספקים והן ארגוני משתמשים בתחום ה-IT.
• מפגשים אלה סובבים סביב נושאים חדשים, אשר עדיין אינם נחשבים ל-Mainstream.
• במפגשים נבחנות טכנולוגיות אלה, מידת ישימותן בארגונים בכלל ובארגונים ישראליים בפרט.

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

ההערכה של STKI לגבי תחום ה Cloud היא שהמצב הכלכלי דוחף ארגונים כיום לשקול מודלים חדשים של מחשוב אשר מבטיחים עלויות השקעה נמוכות ובתוך כך גם מחשוב ענן המתייחס לטכנולוגיות המאפשרות לצרוך יכולות מחשוב בתצורת שירותים. להערכתנו, ארגונים יבחנו את מודל הענן גם בהיבט של הורדת עלות פר יחידה (עלות פר שרת, פר טרהבייט אחסון, פר תקלה במוקד התמיכה, פר מתכנת או פר שורת קוד), ובממדים אלה ספקים יצטרכו להציג מודל כלכלי משתלם.
עלינו עדיין לחקור את המודל הכלכלי של מחשוב הענן, שצריך לכלול עלויות הסבה, מעבר ועלויות אבטחת מידע, בנוסף לחסינות הספקים שמציעים מודל זה. CAPEX אינו משפיע רק על ארגוני משתמשים אלא גם על ספקי ה-IT. מודל מחשוב הענן בתחום התוכנה, שכולל את תחום אספקת תוכנה כשירות (Software as a Service) – מודל זה ינוסה על ידי ארגונים ויאומץ בסדר גודל מוגבל. יתרונות מודל מחשוב הענן של עלויות השקעה מראש נמוכות ומעבר לעלויות תפעוליות שוטפות יותר נמוכות, בנוסף לחיזוקים המתקבלים מספקים גדולים שמצטרפים לשוק ובונים יכולות בתחום ה- Cloud (שכוללות גם חיזוק והדרכת הערוצים שלהם), יעודדו יותר ארגונים אשר נמצאים בשוליים של אימוץ התחום להיכנס אליו יותר. ארגונים שנמנעו לחלוטין מהמודל (מסיבות אבטחת מידע, קישוריות וכד'), ייאלצו לבחון מחדש את המודל וישימותו לארגון שלהם. ארגונים בתעשיות שונות יבחנו מודלים שונים של שירותי Cloud, המסופקים ומנוהלים על ידי ספקים בינלאומיים, ישראליים, ספקי תקשורת, אינטגרטורים בישראל או ספקי hosting.

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

משמעות ה Cloud לארגוני enterprises בישראל:
ארגוני IT שאנו משוחחים עמם אינם מתרגשים מעניין ה hype הקיים כיום סביב הCLOUD. מנמ"רים מעוניינים לדעת באופן פרקטי כיצד מהם היתרונות שכדאי (אם כדאי) לנצל ממודל זה? אנו מתייחסים לשירותי ה Cloud כ"Virtual Data Center", המתקיים לצד ה On site / Off site Data Center. בעולם זה, אנו מחלקים את היתרונות הפרקטיים שניתן לקבל מעולם ה Cloud לשניים:
בתחום האפליקציות: ארגונים ישראלים יידרשו יותר ויותר לקיים סביבת "שירותים", כאשר תפקיד מחלקת ה IT יכלול גם נושא של "הרכבת" שירותי IT מתוך שימוש ברכיבי תשתיות ואפליקציות קיימים. בתחום האפליקציות, ארגונים יצטרכו ליצור מה שאנו קוראים "Mashups" (מושג "שאול" מעולם ה Web 2.0) – חיבור של שירותים שונים לכדי שירות חדש. המשמעות של ה CLOUD במובן זה היא שלמנמ"ר יהיו הרבה יותר אופציות ליצירת Mashups מאשר בעבר.
בתחום התשתיות: ארגונים יידרשו להרכיב סביבות המורכבות משירותים תשתיתיים, מה שאנו מכנים "Ensembles": שילוב של שכבות תשתיתיות שחלקן נמצאות אצל הארגון ב- data center , חלקן נמצאות אצל ספקי השירותים וחלקן נמצאות במקביל גם ב- data center וגם אצל ספקי השירות. בניית ensembles אינה טריוויאלית בגלל הצמידות של שכבות התשתית השונות והצורך לפעול במקביל גם ב- data center וגם אצל ספקי השירות.
דוגמה בולטת לכך היא ניהול זהויות שחייב להתבצע במקביל בשכבות השונות.

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

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

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

לסיכום הדיון המלא - לחצו כאן.

Join our group

Inviting you to join our group (in linkedin) for discussions, questions & answers, and overall "brainstorming" about IT market trends:

STKI (META Group Israel) employees, alumni and friends

Is the Enterprise ERP market entering a "freeze" period?

I recently talked to organizations on their next ERP initiatives, and have also checked with IT vendors about their plans for ERP in 2009. Here's what I'm hearing from both sides:

From the user perspective:

• Maintaining the ERP and keeping it going costs a lot. The typical israeli ERP department (this mainly refers to SAP and Oracle shops) includes 10-20 people, and getting these numbers down is very hard. If anything, I think this number increases as these packages spread into more functional areas (more modules) and technological areas (Portal, BI, EAI etc) since the complexity is growing.
• Most organizations prefer to stretch the need to upgrade, I think we will see less upgrades in the coming year (unless the vendor announces end of standard support for older versions). This is inline with the common trend these days for enterprise apps - if there' no clear ROI, we won't do it.
• More opennes to ideas, 3rd party tools and delivery models that can help them keep maintenance/training/development/support costs down.

From the vendor perspective:

• Not many "new" large scale projects planned for 2009
• Vendors are counting on the fact that some users will have to upgrade to newer versions... I think some will rethink this decision.
• New modules that haven't yet made the big break: compliance/GRC, financial planning, vertical modules (core banking, core insurance) etc.
• Vendors are trying to find ways to help organizations be more effecient in their ongoing ERP operations.

So what is happening?

This will probably be a slow ERP period. Some organizations' I've talked to were planning to start they're ERP projects this year but some say they might need to push it back because of limited resources and a difficulty in proving a valid ROI.

The main challenge for user organizations in 2009 will be balancing the need to keep and maintain existing applications ("keep the lights on") but also providing services that help the organizations change (in order to survive) and grow. As a result, they will look for practical ways to help reduce ERP maintenance and support costs and this will include using 3rd party tools and using various sourcing models.

איך אפשר לנצל כלי Web 2.0 לניהול ידע פנים ארגוני?

תפיסות Web 2.0 יכולות להציע "best practices" עבור ארגונים בכל הנוגע לשיטות שיתוף מידע, בניית מאגרי מידע בגישת ה Collective intelligence, ודרכים נוספות לנהל ידע (תחום אשר נחל כשלונות רבים ועדיין עומד בפני אתגרים לא פשוטים).

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

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

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

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

What does Cloud mean in the Enterprise Applications world?

המאמר הבא פורסם בחברת המחקר Cutter Consortium.

Improving the Forecast: Cloud Models in the Applications World
by Einat Shimoni

The cloud hype continues to spread into just about any IT category, whether it's computing infrastructures (IAAS), platforms (PAAS), storage (scaling on-demand), applications (software as a service [SaaS]/cloud software), and even newer categories, such as integration on the cloud (IAAS). The list goes on.

Cloud models are now presenting CIOs with new ways of dealing with the shrinking IT budgets by allowing them basically to move nondiscretionary activities to discretionary.

But how does that all ultimately affect the end user? What will be the changes (if any) in the way of consuming applications? What does this all mean to the business?

If we take a look at just the application category and try to peel away the hype factor, how does the cloud model help business applications?

To answer that question, let's first examine previous application delivery models and how it all evolved into current cloud models:

Application Service Provider (ASP)
ASP was about using an external package, including the hardware, database, and application, all bundled together as a package with maintenance services. But it was a "messy" deal; the hosting came from vendor A, the software from vendor B. Sometimes the client had to talk to both vendors; sometimes vendor A would buy the software from vendor B. Either way, pricing was not flexible.
The advantages with ASP were that you could outsource what you didn't need inside, and there was no need to manage hardware and maintain the application.
The drawbacks mainly related to timing (ASP came a bit too soon to the market). The core idea is good but inadequate security technologies and communication barriers (bandwidth) made it a risky choice for many organizations. Another drawback associated with ASP was that it was a single application that could be used by many -- no customization, no changes. It was a "vanilla," take-it-or-leave-it package.
Will ASP still have a place a few years from now? Yes, it will fill a need for a "service" (a single instance) that many people need to use. For example, a suppliers' portal that provides an exchange place for buyers and sellers. In this case, there will be no reason to customize the application for everyone; it's a generic application that everyone can use, no one needs to keep it inside its organization, and, in fact, it is even better off managed by an external party that can be the "translator" between all parties.

SaaS
SaaS had much better timing. Suddenly, everyone is now talking about it, and it actually makes a lot of sense. Many of the technological barriers are gone. As organizations embrace new architectures such as SOA, SaaS is becoming a more viable option. While SaaS is a multitenant configuration, it does allow organizations to make some changes and customization. They don't have their own specific application, but they can have a variation of their application, sharing the infrastructure, platform, and application layer with other tenants.
The main limitation to SaaS, however, is the lack of control. When you use SaaS, you don't control the application (the core processes that are managed within it), and you don't control the data. This limits the uses of SaaS to applications with the following characteristics:
Applications that have a "network effect" (much like Web 2.0 initiatives, these applications present more value when more people are using them). For example, travel management and social software.
Niche and loosely coupled processes. The "classic" process would be one that doesn't require (any or many) integration with other processes. HR-related processes are a good example (i.e., travel management systems, eployee performance management, incentives management, e-recruitment).
Noncore processes. When it comes to core processes that are at the heart of the organization, even if COTS software is used, the application must be customizable; there is no room for compromise. SaaS is not the answer in this case. The high sensitivity level in this type of application makes it all the more difficult to hand over the control of data to an external vendor.
New processes. Organizations will most likely look at SaaS for new things that are not currently managed with an existing application.
As a result, in a few years most organizations will have a mix of applications: legacy core applications will run internally (perhaps organizations will use cloud services to make these applications more efficient), and the other type of applications will indeed be SaaS -- these will be the newer applications, and usually the more innovative systems.
Organizations will need to address the integration issues of cloud-based applications with internal ones (not surprisingly, there are already quite a number of vendors developing these types of integration solutions to the cloud).

Cloud Software
Cloud software will be another development in this lifecycle. Cloud software brings the control back to the user organization; it can develop its own application from scratch (using platform as a service tools [PaaS]).
In previous models -- ASP and SaaS -- organizations have no or limited control of their data. In SaaS, they don't really control the data or the application; they are consuming services and don't really deal with the content of the services or how they are delivered.
Cloud software will not eliminate the need for SaaS, however. Both models will have a place: SaaS will become a model more suitable for commodity-type or lightweight processes, and cloud will enable organizations to run heavier, core processes.

IaaS (Integration as a Service)
IaaS is another piece of the architecture that will become more and more necessary as organizations adopt these solutions. They will need to integrate them with internal, legacy, on-premise applications.

There is a very high chance that this is not the final phase of the evolution.

את המאמר ניתן לקרוא באתר של Cutter - כאן.

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

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

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

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

מצגת - מגמות בתחום ה CRM

במצגת בנושא מגמות CRM אותה הצגתי לאחרונה עלו הנושאים הבאים:

• כיצד נראים פרויקטים CRM כיום (לעומת פרויקטים בשנים שעברו)? על מה ארגונים שמים את הדגש?
• CRM תפעולי/ אנליטי / שיתופי - מה השלב הבא?
• מה זה CRM רב ערוצי? וכיצד מנהלים את חוויית הלקוח - CEM - Customer Experience Management?
• מודלים של עלויות פרויקטי CRM

במצגת תוכלו לצפות כאן.