‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax.

972-97442444‬‬

‫סיכום מפגש שולחן‪-‬עגול‬

‫פרוייקטי שו"ב וניטור רשתות תקשורת‬

‫אפריל ‪0202‬‬

‫עורך‪ :‬שחר גייגר מאור‬

‫הערה חשובה‪:‬‬
‫סיכום דיון זה אינו מהווה סקר שוק‪ ,‬המלצה או מחקר‪ ,‬אלא מספק תמונת מצב סטאטית לגבי הנעשה בארגונים‬
‫שהשתתפו בדיון‪.‬‬
 ‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫‪Contents‬‬
‫הקדמה ‪3 ...........................................................................................................................................................‬‬
‫חלק ראשון –מצב קיים בארגונים המשתתפים במפגש ‪4 ......................................................................................‬‬
‫חלק שני –סיפורי לקוח ‪5 ....................................................................................................................................‬‬
‫סיפור לקוח –הטמעת פיתרון לניטור רשתות של ‪5 ...................................................................... .SolarWinds‬‬
‫רקע על הארגון והסביבה הארגונית‪5 ......................................................................................................... :‬‬
‫רקע לפרוייקט‪5 ........................................................................................................................................ :‬‬
‫על הפרוייקט‪6 .......................................................................................................................................... :‬‬
‫על הפיתרון‪6 ............................................................................................................................................ :‬‬
‫תמיכה בתקלות? ‪6 ....................................................................................................................................‬‬
‫לקחים עבור ארגונים אחרים‪7 ................................................................................................................... :‬‬
‫סיפור לקוח –הטמעת פיתרון של חברת ‪ Centerity‬לניטור תשתיות‪7 .............................................................. .‬‬
‫רקע‪7 ....................................................................................................................................................... :‬‬
‫על הפרוייקט‪7 .......................................................................................................................................... :‬‬
‫על הפיתרון הנבחר‪8 ................................................................................................................................ :‬‬
‫הטמעה ותמיכה ‪8 ......................................................................................................................................‬‬
‫טיפול בתקלות ‪8 ........................................................................................................................................‬‬
‫ניהול שינויים והשבתות ‪8 ...........................................................................................................................‬‬
‫שאלת החברה קטנה ‪8 ...............................................................................................................................‬‬
‫לקחים לארגונים אחרים‪9 .......................................................................................................................... :‬‬
‫סיפור לקוח –הטמעת פיתרון של חברת ‪ CA‬לניטור תשתיות עם דגש על ניטור שירותים‪9 ................................ .‬‬
‫רקע ‪9 ........................................................................................................................................................‬‬
‫על הפרוייקט ‪9 ...........................................................................................................................................‬‬
‫איך משתלב השו"ב בעבודת ה ‪9 .......................................................................................................... ?IT‬‬
‫לקחים ותובנות עבור ארגונים אחרים ‪02 .....................................................................................................‬‬
‫סיפור לקוח –הטמעת פיתרון ‪ Netcool‬של חברת ‪ IBM‬לניטור תשתיות תקשורת ‪02 .......................................‬‬
‫רקע כללי‪02 ............................................................................................................................................. :‬‬
‫רקע לפרוייקט והצורך‪02 ........................................................................................................................... :‬‬
‫על המערכת‪02 ......................................................................................................................................... :‬‬
‫טיפים ולקחים לארגונים אחרים‪00 ............................................................................................................. :‬‬
‫הערה חשובה‪:‬‬
‫סיכום דיון זה אינו מהווה סקר שוק‪ ,‬המלצה או מחקר‪ ,‬אלא מספק תמונת מצב סטאטית לגבי הנעשה בארגונים‬
‫שהשתתפו בדיון‪.‬‬
 ‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫הקדמה‬
‫בדרך כלל מקובל לחשוב על יחידת מערכות המידע כגוף שנועד לסייע לגוף העסקי בעבודתו השוטפת‪" .‬לקדם ולא‬
‫לעכב"‪.‬‬

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

‫עולם השליטה והבקרה מתחלק בהיבט השימושים (בצורה גסה מאוד) למספר רבדים ומשפחות‪:‬‬

‫המשפחה הראשונה קשורה לשכבת הניטור ה"קלאסית" (‪ AGENTS‬שמדווחים למרכז) והיא מורכבת מכמה רמות‪:‬‬

‫‪ ‬רמת הניטור הראשונה‪ :‬סוכנים (‪ )agents‬שממוקמים על כל שרת או סביבה רלוונטית ומדווחים לקונסול‬
‫מרכזי‪.‬‬
‫מה המערכת יודעת "לתת"? דיווח בסיסי פיזי (סטטוס של השרתים‪ , routers ,‬אחסון וכד')‪.‬‬

‫הרמה השניה (הניטור הלוגי)‪ :‬ברמה זו ניתן לשייך כמה פריטים פיזיים אחד לשני ולקבל תמונה לוגית‬ ‫‪‬‬
‫ברורה יותר‪ .‬לדוגמא‪ :‬תמונת מצב הדואר אלקטרוני בארגון‪ ,‬תמונת שרתי ‪ ERP‬וכד'‪.‬‬

‫בכלי שו"ב ברמות הללו יש שתי בעיות מרכזיות‪ :‬קשה לשמור על מערכת מעודכנת כי צריך להתקין ‪ agents‬כל‬
‫הזמן ולקנפג אותם בצורה מתאימה‪ .‬בעיה נוספת‪ :‬אם רכיב בסיסי במערכת מסויימת נופל‪ ,‬מקבלים "אדום" בכל‬
‫המערכת‪ .‬לעיתים תכופות קשה לדעת מהו מקור התקלה האמיתי‪ .‬כדי לסייע בהתמודדות עם נושא זיהוי מקור‬
‫התקלה‪ ,‬קיימים כלים משלימים המכונים כלי ‪.root cause analysis‬‬

‫משפחה שניה כוללת כלי שו"ב "ספציפיים"‪ :‬כלים לניטור טכנולוגיה מסויימת‪ .‬לדוגמה‪ ,‬מוצרים לניטור האחסון‪,‬‬
‫ניטור ‪ ,Java‬ניטור ‪ , .Net‬ניטור התקשורת‪ ,‬אבטחת מידע וכד'‪.‬‬

‫משפחה שלישית מתייחסת לניטור שירותים ותהליכים עסקים (בניגוד להסתכלות על מערכות בדידות)‪ .‬המונח‬
‫המקובל‪ ,‬לעיתים‪ ,‬הוא ‪ . Business Transaction Management‬מערכות בעולם תוכן זה יידעו לתת התראות‬
‫במקרה של נפילת שרת בודד גם בהקשר העסקי\תהליכי שלו‪ .‬במקרים רבים כלים אלו יידעו לבצע ניתוח ‪root‬‬
‫‪.cause‬‬

‫המשפחה הרביעית והמתקדמת ביותר בתחום השליטה והבקרה‪ ,‬נכון להיום‪ ,‬היא תפיסת ‪ CMDB‬ביחד עם‬
‫מתודולוגית ‪.ITIL‬‬

‫ברמה הטכנולוגית ‪ CMDB‬הנו מסד נתונים של ”‪ "configuration items‬או ‪ CIs‬שנמצאים בארגון (כמו למשל‬
‫שרת‪ ,‬שירות ב‪ , windows -‬אחסון‪ ,‬אפליקציה ואפילו אנשים ומבנה ארגוני)‪ .‬כאשר אותם ‪ CIs‬והקשרים ביניהם‬

‫הערה חשובה‪:‬‬
‫סיכום דיון זה אינו מהווה סקר שוק‪ ,‬המלצה או מחקר‪ ,‬אלא מספק תמונת מצב סטאטית לגבי הנעשה בארגונים‬
‫שהשתתפו בדיון‪.‬‬
 ‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫אמורים להתגלות בצורה אוטומטית‪ .‬המידע ששומרים ב ‪ DB‬על כל ‪ CI‬הוא רב מימדי תוך התחברות למערכות‬
‫אחרות שקיימות בארגון‪:‬‬

‫‪ – Configuration management‬מה מותקן עליו‪ ,‬איזה רמה של טלאים ‪ ,‬איזה שינויים בצעו ב‪-‬‬ ‫‪.1‬‬
‫‪ registry‬וכד'‪.‬‬
‫‪ – Asset management‬באיזו פקודת רכש נרכש ה‪ ,CI -‬עם איזו אחריות‪ ,‬באיזה רמת ‪ SLA‬וכד'‪ .‬בתוכנה‬ ‫‪.0‬‬
‫– כמה רשיונות תוכנה נוספים יש בארגון וכמה נוצלו וכד'‪.‬‬
‫מידע שקשור ל‪ – service desk -‬אילו קריאות נפתחו על ה ‪ CI‬לאחרונה וכד'‪.‬‬ ‫‪.3‬‬
‫כל המידע שקשור לחיווים של מערכת השליטה והבקרה‪.‬‬ ‫‪.4‬‬
‫קשר לקונסול של אבטחת המידע‪ .‬ועוד‬ ‫‪.5‬‬

‫עולם תוכן שלם שהתפתח במקביל למשפחות השו"ב כאן מדבר על ניטור חוויית המשתמש ( ‪end user‬‬
‫‪ :)experience‬איך מושפע המשתמש הארגוני או משתמש חיצוני מתשתית המיחשוב‪ .‬מי לא מכיר את הטלפונים‬
‫הנרגזים של לקוחות שמתלוננים ש"המחשב לא זז והאינטרנט תקוע"‪ .‬מערכות אלה נועדו לתת מענה למגוון‬
‫היבטים של נקודה כאובה זו‪.‬‬

‫ארגון שמחפש פיתרון שו"ב לצרכיו חייב להבין את ההבדלים בין המשפחות השונות ולבחון את הפתרונות השונים‬
‫מול צרכיו הארגוניים‪ .‬הסתכלות לא נכונה על הצרכים הארגונים יכולה להביא לחוסרים גדולים ביכולות הפיתרון‬
‫הנבחר מול כלל הצרכים הארגוניים או לחלופין‪ ,‬בחירה בפיתרון יקר ו"גדול מדי" (‪.)over-kill‬‬

‫חלק ראשון –מצב קיים בארגונים המשתתפים במפגש‬

‫מבנה גוף השו"ב ותחומי האחריות שלו שונים בדר"כ מארגון לארגון והם תולדה של האבולוציה הארגונית ביחידת‬
‫מערכות המידע ביחד עם הגדרה אסטרטגית של צרכים ואילוצים‪.‬‬

‫במפגש זה השתתפו ‪ 04‬אנשי מקצוע מ ‪ 07‬ארגונים גדולים בישראל‪ .‬המשתתפים בדיון הינם מנהלי ומנהלות‬
‫שו"ב‪ ,‬אנשי רשת ותקשורת‪ ,‬מנהלי תשתיות ומנהלים בכירים אחרים‪.‬‬

‫בכל הארגונים שהשתתפו במפגש קיים אחד מהשניים‪ :‬פיתרון נקודתי לניטור צרכים ספציפיים ברשת או פתרונות‬
‫שו"ב גדולים יותר‪ ,‬המכילים יכולות נרחבות יותר‪ .‬מגוון הפתרונות בשימוש כולל את רוב הפתרונות המוכרים כיום‬
‫בתחום ובעיקר סוויטות\מודולים של יצרנים כמו ‪ BMC ,IBM ,HP ,CA‬ואחרים‪.‬‬

‫את הארגונים המשתתפים ניתן לחלק לאחת מהקבוצות הבאות‪:‬‬

‫‪ ‬בארגונים מסויימים קיימות מספר מערכות ניטור המשרתות‪ ,‬כל אחת בנפרד‪ ,‬תחום טכנולוגי מסויים‪.‬‬
‫מצב זה מקובל בארגון ואין תוכניות לשנותו בחלק מהמקרים‪ .‬בארגונים אחרים נערכת בחינה להחלפה‬
‫מקומית של מערכת קטנה אחת באחרת‪.‬‬
‫‪ ‬בקבוצת ארגונים אחרת‪ ,‬אשר מופעלים בה מספר כלים במקביל‪ ,‬קיימות תוכניות לאחד את פעילות‬
‫הכלים לפיתרון אחד או שניים אשר יתנו מענה מקיף לכל תחומי ה ‪ .IT‬מה שמכונה ‪Manager of‬‬
‫‪.managers‬‬

‫את הארגונים המשתתפים במפגשים ניתן גם לתאר על פי החלוקה בתרשים הבא‪:‬‬

‫הערה חשובה‪:‬‬
‫סיכום דיון זה אינו מהווה סקר שוק‪ ,‬המלצה או מחקר‪ ,‬אלא מספק תמונת מצב סטאטית לגבי הנעשה בארגונים‬
‫שהשתתפו בדיון‪.‬‬
 ‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫מצב קיים בארגון‬

‫‪24%‬‬ ‫מספר פתרונות‬

‫ספציפיים\מקומיים‬
‫‪41%‬‬
‫פיתרון שו"ב מרכזי ופתרונות‬
‫משלימים‬
‫פיתרון ‪end-to-end‬‬

‫‪35%‬‬

‫בקרב חלק מהארגונים הנוכחים (מרובי פתרונות וכן כאלה עם פיתרון שו"ב מרכזי) יש כוונה לקדם פרוייקטי‬
‫‪ CMDB‬כנדבך נוסף למערכות הניהול הקיימות‪.‬‬

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

‫חלק שני –סיפורי לקוח‬

‫סיפור לקוח –הטמעת פיתרון לניטור רשתות של ‪.SolarWinds‬‬

‫רקע על הארגון והסביבה הארגונית‪:‬‬

‫הארגון מונה כמה עשרות אלפי משתמשים בשני אתרים ראשיים ומספר אתרי משנה נוספים בישראל‪ .‬בארגון זה‬
‫קיימת מחוייבות חזקה מאוד לשמירה על ‪ SLA‬גם בזמינות משאבי הרשת‪ .‬אוכלוסיות המשתמשים מונות מגוון‬
‫של תפקידים וצרכים‪ ,‬כשבחלק מהמקרים מדובר על סביבות פיתוח וניהול פרוייקטים המחייבים נפח תעבורה של‬
‫‪ G0‬לשולחן העבודה‪.‬‬
‫הארגון עושה שימוש בשני מתגי ‪ backbone‬של ‪ Nortel‬ושני מתגים נוספים לגיבוי‪ .‬התקשורת בין הסניפים‬
‫עוברת על פי רוב על תווך ‪ MPLS‬של בזק בנפח ‪ G 0‬לכל הארץ‪ .‬התווך עצמו מוצפן לכל האורך על ידי פיתרון‬
‫מסחרי מוכר‪ ,‬כשהשיקול המרכזי הוא עמידה בעומסי התעבורה ובקצבים גבוהים‪ .‬הרשת הלוגית מחולקת למספר‬
‫סגמנטים על פי רמות הסיווג והרגישות‪.‬‬

‫רקע לפרוייקט‪:‬‬
‫בשנות התשעים עבדו בארגון עם פיתרון של חברת ‪ HP‬ברמה הבסיסית והיו די מרוצים‪ .‬לפני כ ‪ 02‬שנים הוחלט‬
‫לבחור בפיתרון שו"ב מקצה לקצה של חברת ‪ .CA‬היקף הפרוייקט כלל שימוש בפתרונות השו"ב של ‪ ,CA‬לרבות‬
‫שו"ב תקשורת‪ .‬מודול שו"ב התקשורת של ‪ CA‬לא התאים לצורכי גוף התקשורת והוחלט לחפש אלטרנטיבה‬
‫הערה חשובה‪:‬‬
‫סיכום דיון זה אינו מהווה סקר שוק‪ ,‬המלצה או מחקר‪ ,‬אלא מספק תמונת מצב סטאטית לגבי הנעשה בארגונים‬
‫שהשתתפו בדיון‪.‬‬
 ‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫אחרת‪ .‬השיקול הארגוני היה פיתרון פשוט וזול יחסית שיתמקד רק בהיבט הרשת‪ .‬לאחר בחינת מספר חלופות‬
‫החליטו לבדוק את מערכת ה ‪ Orion‬של חברת ‪.SolarWinds‬‬

‫על הפרוייקט‪:‬‬
‫לפני הכנסת הפיתרון הזה טופל כל נושא תחזוקת מערכות שו"ב התקשורת על ידי גוף אחר בארגון‪ .‬אחד הצעדים‬
‫שנעשו בעקבות הכנסת הפיתרון היה היה להוסיף את נושא הטיפול והאחריות על תחזוקת המערכת לגוף‬
‫התקשורת‪.‬‬
‫הבדיקה הראשונה של הכלי עצמו כללה הורדת ‪ demo‬מאתר החברה באינטרנט והרצה שלו ברשת‪ .‬אנשי‬
‫התקשורת בארגון מספרים כי הם היו מאוד מרוצים והכלי ענה על הרבה מהצרכים שלהם בצורה מאוד טובה‬
‫יחסית לפתרונות אחרים שנראו באותה תקופה‪..." .‬כאילו אספו מספר אנשי תקשורת ושאלו אותם מה החלום‬
‫הרטוב שלהם בניטור הרשת"‪ .‬גרסת ההדגמה הייתה כל כך מוצלחת עד שכל סביבת הניטור הוקמה ללא כל סיוע‬
‫חיצוני ובקלות רבה‪.‬‬

‫על הפיתרון‪:‬‬
‫רוב העבודה נעשית באמצעות מודול שנקרא ‪ .)network performance manager( NPM‬הכלי מאפשר לזהות‬
‫פרוטוקולים שונים הנעים ברשת ולמפות בצורה טובה את אופי וסוג התעבורה (לדוגמא‪ ,‬אחוזים של כל פרוטוקול‬
‫על התווך)‪ .‬אופן הדגימה מבוסס ‪ SNMP‬בלבד (דוגם שרתים ברמה הבסיסית‪ .‬יש מודול של ניטור שירותים בשם‬
‫‪ Application Monitor‬אולם הוא לא בשימוש בארגון) ‪.‬‬
‫מספר פרמטרים שחסרו להם מאוד בכלים אחרים מקבלים מענה מאוד טוב בכלי זה‪ :‬נצילות ‪ ,CPU‬זיכרון ועוד‪.‬‬
‫מפת רשת? נבנתה מפת רשת סטאטית לאחר שהמערכת ביצעה דגימות בהתאם‪ .‬לכלי קיימת יכולת דיסקברי‬
‫ובניית רשת דינמית‪ ,‬אולם בארגון הוחלט לבנות את המפה לבד‪ .‬המערכת מאפשר קבלת סטטיסטיקות שונות‪,‬‬
‫דוחות הסטוריים וכן הלאה‪.‬‬
‫כל המודולים במערכת מנוהלים דרך מסך וובי אחד‪ .‬ניתן לבנות דוחות בצורה פשוטה מאוד לתכנון רשת או דוחות‬
‫ביצועים לצרכים שונים‪ .‬המערכת יוזמת בדיקות וגם מקבלת התראות בצורת טרפים מהרכיבים השונים באופן‬
‫מיידי‪.‬‬
‫איך מתבצעת העבודה השגרתית עם הכלי ב ‪ ?)help desk( HD‬המפעילים במרכז רואים את כלל המסכים‪.‬‬
‫קיים מסך אחוד של ‪ )Unicenter( CA‬לנושאי שו"ב ואליו מגיעים כל חיוויי ה ‪ .Orion‬כיום עדיין אין ממש‬
‫אינטגרציה בין הכלים אם כי אולי בעתיד המצב ישתנה‪.‬‬
‫הלקוח הראשי של הכלי הוא גוף התקשורת בארגון וה ‪ HD‬מהווה אינדיקציה ראשונה לבעיה בעיקר בשעות‬
‫העבודה‪.‬‬

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

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

‫תמיכה בתקלות?‬
‫לחברה אין כיום ייצוג רשמי בארץ‪ .‬עד לא מזמן היא יוצגה על ידי חברת ‪ ,Datasafe‬שפשטה רגל ב ‪.0229‬‬
‫במקרה בהם קיימות שאלות‪ ,‬ניתן להכנס פורומים של מפתחים באינטרנט‪ .‬בארגון זה מציינים כי מדובר בפורומים‬
‫מעולים אשר נותנים מענה מאוד טוב לרוב הבעיות‪ .‬גם התמיכה הישירה מהחברה טובה למדי‪ :‬נציג הארגון ציין‬
‫מקרה בו היתה לו בעיית רישוי מסויימת‪ .‬הוא פנה לתמיכה באתר החברה וקיבל תשובה מהירה מאוד‪ .‬במהלך‬
‫העבודה עם הפיתרון ניתקלו בארגון בבעיה‪ :‬לפיתרון לא היתה יכולת מובנית לזהות ‪ MIBs‬של מתגי ‪.Nortel‬‬

‫הערה חשובה‪:‬‬
‫סיכום דיון זה אינו מהווה סקר שוק‪ ,‬המלצה או מחקר‪ ,‬אלא מספק תמונת מצב סטאטית לגבי הנעשה בארגונים‬
‫שהשתתפו בדיון‪.‬‬
 ‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫לאחר פניה של אנשי התקשורת בארגון לחברה בחו"ל פותחו יכולות מובנות בפיתרון לזיהוי הרכיבים הרלוונטיים‪.‬‬
‫מבחינת הארגון מדובר בצעד שמראה הרבה מאוד על הקשר של החברה עם לקוחותיה‪.‬‬

‫מחיר החבילה היווה יתרון משמעותי נוסף והוא עמד בשעתו על כמה אלפי דולרים בודדים לחבילת הבסיס‪.‬‬
‫קיימות שלוש רמות תימחור עקריות‪ :‬שתי רמות עם הגבלת משתמשים (קטנה וגדולה יותר) וחבילה עם רשיון‬
‫‪( site‬הארגון בחר באופציה השלישית)‪ .‬תקורות התפעול השוטף הן נמוכות יחסית ואין עובד במשרה מלאה‬
‫שמתפעל את המערכת‪ .‬אנשי התקשורת עושים שימוש יומיומי מאסיבי בממשקי הכלי לצורך עבודתם השוטפת‪.‬‬

‫לקחים עבור ארגונים אחרים‪:‬‬

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

‫סיפור לקוח –הטמעת פיתרון של חברת ‪ Centerity‬לניטור תשתיות‪.‬‬

‫רקע‪:‬‬
‫ארגון זה הינו גוף גדול מאוד מתחום התקשורת‪ .‬בארגון פרושה אחת מרשתות התקשורת הגדולות בארץ‪ .‬ברשת‬
‫זו קיימים אלפי פרטי ציוד בקצוות ובשני מרכזי הנתונים של הארגון‪ .‬בארגון רשת ‪ voice‬גדולה ומסועפתהכוללת‬
‫מספר מתגים כמו כן קיימים כ ‪ 0222‬שרתים פיזיים ווירטואליים מכל הסביבות והפלטפורמות‪ ,‬עשרות אפליקציות‬
‫ארגוניות מכל הסוגים‪ .‬כמו כן מחוברים לרשת עשרות רכיבים הקשורים להיבטי הביטחון הפיסי של מתקני‬
‫הארגון‪ ,‬רכיבי מערך החשמל‪ ,‬כיבוי האש‪ ,‬בקרות כניסה ועוד‪.‬‬
‫מרכז הבקרה הארגוני הוא ליבת העסק ומרכז את כל היבטי הניטור בארגון‪ ,‬הן להנדסה והן למערך ה ‪.IT‬‬

‫בארגון בוצעו מספר בדיקות ומחקרים לגבי אופי התקלות אשר מגיעות לטיפול במרכז התמיכה וגילו כי רובן‬
‫המוחלט הן תקלות "פשוטות" ומסתיימות באיתחולי שרת או פעולה פשוטה אחרת‪ .‬ברוב התקלות מטפל צוות‬
‫‪( first level support‬צוות ‪ )FLS‬ולו נהלים מאוד מדוייקים שנועדו לייעל מאוד את הטיפול בתקלות רשת ולצמצם‬
‫תקורות‪.‬‬

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

‫בארגון נבחנו מספר חלופות‪ .‬חלקן מוצרים מוכרים ומובילים בשוק וחלקם מבוססי קוד פתוח‪ .‬השיקול הכספי היווה‬
‫שיקול חשוב מאוד והצעות המחיר שהם קיבלו מחלק מספקי הפתרונות היו גבוהות מאוד‪ .‬המצב הקיים בארגון‬
‫הערה חשובה‪:‬‬
‫סיכום דיון זה אינו מהווה סקר שוק‪ ,‬המלצה או מחקר‪ ,‬אלא מספק תמונת מצב סטאטית לגבי הנעשה בארגונים‬
‫שהשתתפו בדיון‪.‬‬
 ‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫טרם תחילת הפרוייקט כלל שימוש במספר מוצרי ניטור במקביל‪ .‬מרכז הבקרה הכיל הרבה מאוד מסכים‬
‫והדיווחים הגיעו ממספר מקורות שונים‪ .‬מערכת השו"ב החדשה נועדה להחליף את רוב המערכות הקיימות‬
‫במערכת אחודה אחת‪.‬‬

‫על הפיתרון הנבחר‪:‬‬

‫מערכת ה ‪ Centerity‬חולשת על רובם המוחלט של הרכיבים הארגוניים שדורשים ניטור קבוע‪ :‬רשת פנימית‪,‬‬
‫אפליקציות‪ ,‬ממשקים‪ ,‬שירותים‪ ,‬רשת הנדסית‪ ,‬מערכת חשמל‪ ,‬קווי תמסורת‪ ,voice ,‬מצלמות ומנגנוני אבטחה‬
‫ועוד‪ .‬מערכת זו היא מערכת השו"ב היחידה בארגון לצרכים פנימיים‪.‬‬
‫המערכת מבצעת בדיקת זמינות של ציוד ברשת‪ ,‬בדיקת איכות השירות (‪ ,)QOS‬דגימת ‪– VOIP‬גם בצד הלקוח‬
‫(המערכת מקבלת ‪ CDR‬בזמן השיחה מציוד תקשורת ה ‪ ,)IP‬ניטור רשת האינטרנט –נתבים‪ ,‬קווים בינלאומיים‬
‫ועוד‪.‬‬
‫בדיקת חווית משתמש –מתבצעת באמצעות מנוע שמריץ חיבורים לאתרים שונים ובודק את איכות הגלישה‬
‫בפועל‪ .‬חברת ‪ Centerity‬משתמשת במקרה זה במנוע חיצוני של חברת ‪.Automate‬‬
‫בדיקת חווית המשתמש היא בעצם בקרה על הברזלים‪ .‬על כל שרת יש כ ‪ 05-35‬בדיקות שונות שניתן להריץ‪ .‬לא‬
‫תמיד מבצעים את כל הבדיקות‪ ,‬אלא סט מסויים על פי מתודולוגיה סדורה לעניין‪.‬‬
‫היופי במערכת הוא שינוי התפיסה יחסית למציאות שבארגון היו רגילים לה‪ :‬לא צריך להקליד ידנית‪ .‬המנוע של‬
‫המכונה עושה הרבה מאוד עבודה אוטומטית ועצמאית‪ .‬נושא תקורות הניהול של המערכת מאוד חשוב בארגון‪.‬‬
‫יישום המערכת הביא לירידה במספר המפעילים הקבועים שעובדים מול המערכת משלושה לאחד בלבד‪.‬‬

‫הטמעה ותמיכה‬
‫הטמעת הפרוייקט נעשתה על ידי חברת ‪ Centerity‬עצמה‪ .‬הארגון היווה מעין אתר ‪ beta‬עבור הפיתרון ולכן קיבל‬
‫יחס מאוד מיוחד גם בתהליך ההטמעה‪ .‬הרבה מהאינטגרציה עצמה ופיתוחים סביב המוצר נעשו על ידי הארגון‬
‫עצמו‪ .‬לחלק מדרישות הארגון‪ ,‬כמו למשל יכולות מסויימות של ניטור ‪ ,voice‬לא היו פתרונות מוכנים מראש ונדרש‬
‫פיתוח‪ .‬מכיוון שלארגון יכולות מתקדמות בפיתוח‪ ,‬נעשה הפיתוח לבד‪.‬‬
‫בכל מקרה בו נדרש חיבור (‪ )plug-in‬למערכת אחרת‪ ,‬הארגון בודק בפורומים באינטרנט אם יש קיים חיבור כזה‪.‬‬
‫אם לא‪ ,‬יש גוף פיתוח בארגון‪ .‬אם גם זה לא מתאים‪ Centerity ,‬מחייבים לפי שעות פיתוח‪.‬‬

‫טיפול בתקלות‬
‫תפיסת העולם בנושא טיפול בתקלות הוא להשאיר את אנשי המקצוע לעבודה היומיומית שלהם‪ .‬הגורמים‬
‫הרלוונטים מקבלים ‪ SMS‬על כל תקלה‪ .‬רק במקרה הצורך‪ ,‬כאשר מוחמר המצב‪ ,‬הם נכנסים ללולאת הטיפול‪ .‬כל‬
‫נושא הטיפול בתקלות נעשה דרך מערכת נפרדת (לא דרך ‪.)Centerity‬‬

‫ניהול שינויים והשבתות‬

‫הכל דרך מרכז הבקרה‪ .‬הוא הגורם המאשר‪ .‬טופס בקשה להשבתה\שינויים נשלח למרכז הבקרה‪ ,‬הם בודקים‬
‫את ההשלכות הארגוניות‪ ,‬מתאמים בין כל הגורמים הרלוונטים של ההשבתה ומנהלים אותה לכל אורך הדרך‪.‬‬

‫שאלת החברה קטנה‬

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

‫הערה חשובה‪:‬‬
‫סיכום דיון זה אינו מהווה סקר שוק‪ ,‬המלצה או מחקר‪ ,‬אלא מספק תמונת מצב סטאטית לגבי הנעשה בארגונים‬
‫שהשתתפו בדיון‪.‬‬
 ‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫לקחים לארגונים אחרים‪:‬‬

‫מאוד חשוב להביא לשיתוף פעולה ומחוייבות בין מרכז השליטה לגופים מהם נדגמים רכיבים ושירותים‪ .‬העדר‬
‫שיתוף פעולה מספק יכול להביא לקריסה מהירה באמינות המערכת‪.‬‬

‫סיפור לקוח –הטמעת פיתרון של חברת ‪ CA‬לניטור תשתיות עם דגש על ניטור שירותים‪.‬‬

‫רקע‬
‫רשת הארגון מבוססת ‪ Cisco‬על פי מתודולוגיית שלוש השכבות של ‪ .Cisco‬המתגים בארגון שייכים למספר‬
‫משפחות עיקריות‪ ,‬כמו מתגי ‪ 3722‬ואחרים‪ .‬גודל הרשת הוא מספר אלפי פורטים‪ .‬אמינות הרשת גבוהה מאוד‬
‫וקיימת שרידות מלאה בין כל המתגים‪ .‬ברשת קיימים כ‪ VLANs 42 -‬מנוהלים‪ 42 ,‬יחידות ‪access point‬‬
‫אלחוטיות‪ ,‬החיבור ל ‪ 62 -‬שלוחות וסניפי הארגון בחו"ל נעשה על גבי ‪ .IPVPN‬נפח התעבורה בארץ בין אתרי‬
‫הארגון הוא כ ‪ 02 -‬מגה‪ .‬תשתית הארגון כוללת כ ‪ 052 -‬שרתים ( ‪ .) Win , Linux , Unix , M/F‬לארגון אתר‬
‫אינטרנט עסקי קריטי לפעילות הארגון‪.‬‬

‫על הפרוייקט‬
‫בשנת ‪ 0222‬הוחלט בארגון על הליכה לפרוייקט שו"ב מרכזי‪ .‬לאחר בחינה של מספר חלופות נבחרה סוויטת‬
‫הפתרונות של ‪ . CA‬אחד השיקולים החשובים בארגון זה הוא מיזעור נושא האינטגרציה והעדפת פתרונות רחבים‬
‫עד כמה שניתן ממספר מועט של ספקים‪.‬‬

‫תמונת המצב כיום בארגון בתחום השו"ב היא כזו‪ :‬כל השרתים בארגון מנוטרים בצורה מלאה על ידי ה‬
‫‪ Unicenter R11‬של ‪ ( CA‬מערכות הפעלה‪ ,‬תהליכים ועוד)‪ .‬שרתי ה ‪ Exchange‬מנוטרים גם הם‪ .‬אתר‬
‫האינטרנט מנוטר ע"י ‪ Unicenter‬ו ‪ .Willy -‬תפיסת השו"ב בארגון היא תפיסה קלאסית‪ ,‬כלומר‪ :‬קונסול אחד‬
‫שאליו מדווחות כל המערכות הרלוונטיות‪ .‬בשנים האחרונות הוחלפה מתודולוגיית הניטור מניטור שרתים לניטור‬
‫שירותים‪ .‬על פי תפיסה זו בוצע ניתוח של השירותים הארגוניים השונים במונחי מודל ‪ 7‬השכבות (‪ )OSI‬והתאמת‬
‫עבודת כלי השו"ב למתודולוגיה זו‪ .‬כיום הניטור מתחיל בתהליך העסקי ומשם מגיע עד לשרתים הרלוונטיים‪ .‬גם‬
‫התראות המערכת מתורגמות למשמעות הארגונית ברמת ההשפעה על שירותי העסק ומכך נגזרת רמת הטיפול‪.‬‬
‫מחלקת השו"ב מונה ‪ 3‬משרות ‪ .‬אחת המערכות המרכזיות של הארגון ממוקמת בחו"ל בתצורת ‪.Hosting‬‬
‫השליטה על מערכת זו בהיבטי השו"ב נמוכה יחסית ( מגבלות גישה ) ‪ ,‬ומתבססת על ניטור השירותים למערכת‬
‫הליבה באמצעות ‪ Unicenter‬ומערכת ה – ‪ CEM‬לניטור ניהול חווית הלקוח הממוקמת בסגמנט ה ‪ DMZ‬של‬
‫הארגון‪ .‬בשלב הנוכחי המערכת מנטרת ‪ 0‬סוגי כשלים מ ‪ 7-‬אפשריים [ במהלך הזמן יופעלו הכשלים הנוספים ] ‪.‬‬
‫נדבך נוסף להשלמת ניטור הסביבה הזו הוא שימוש ב ‪ Willy‬עם סוכנים על תשתית האינטרנט וניטורה‪ .‬כל‬
‫המערכת המתוארת מוציאה לקונסול הראשי התראות במקרים של כשלים באחת משלבים השירות‪ .‬כאן רואים את‬
‫היתרון בעבודה עם כלי אינטגרטיבי על פני חיבור של מספר מערכות נפרדות‪.‬‬

‫לדברי נציג הארגון ‪ ,‬בעת תקלה קשה יותר לרדת במהירות ב ‪ Drill Down -‬לשורש התקלה בתצורת מפה‪.‬‬
‫בארגון זה פיתחו לא מעט כדי להגיע לתצורה אופטימאלית בכל הקשור לאופן צורת הצגת האירועים במערכת (על‬
‫חשבון ‪ GUI‬פחות "סקסי" אולם מרשים מאוד ויעיל )‪.‬‬

‫איך משתלב השו"ב בעבודת ה ‪?IT‬‬

‫בארגון נבנה פורום מנהלי תחומים‪ ,‬כשבכל תחום (אפליקציות‪ ,DBA ,‬תשתיות וכו') הוגדר איש קשר‬
‫רלוונטי‪ .‬צוות השו"ב נפגש עם אנשי הקשר מדי פעם ולומד מהם על הצרכים של התחום השונים ‪.‬‬

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

‫הערה חשובה‪:‬‬
‫סיכום דיון זה אינו מהווה סקר שוק‪ ,‬המלצה או מחקר‪ ,‬אלא מספק תמונת מצב סטאטית לגבי הנעשה בארגונים‬
‫שהשתתפו בדיון‪.‬‬
 ‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫לקחים ותובנות עבור ארגונים אחרים‬

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

‫גם בארגון זה חושבים כי אנשי השו"ב חייבים להיות קשורים לייזום פרוייקטים חדשים בארגון ולתהליכים העסקיים‬
‫בארגון על מנת לאמוד את השפעת הפרוייקט והתהליכים העסקיים על עבודת השו"ב‪.‬‬

‫נושא אחרון הוא גב חזק מהנהלת הארגון לפני הליכה לפרוייקט שו"ב מרכזי‪.‬‬

‫סיפור לקוח –הטמעת פיתרון ‪ Netcool‬של חברת ‪ IBM‬לניטור תשתיות תקשורת‬

‫רקע כללי‪:‬‬
‫הארגון הינו גוף גדול ומוביל בתחום אספקת שירותי תקשורת‪ .‬לארגון מליוני לקוחות ואלפי עובדים במספר‬
‫אתרים‪.‬‬
‫רשת התקשורת מסועפת מאוד ובנויה ממספר סגמנטים ותת‪-‬רשתות שונות לפי הצרכים הארגוניים‪ .‬רשתות‬
‫התקשורת מספקות שירותים עבור לקוחות הארגון ונדרשות לעמוד בדרישות מחמירות מאוד של ‪ .SLA‬גוף‬
‫השו"ב של חברה זו מנטר "את כל מה שאפשר ברשת"‪ :‬מתגים‪ ,‬רדיו‪ ,‬תמסורת‪ ,‬רשת תקשורת נתונים‪ ,‬כל‬
‫השירותים על גבי הרשת‪ .‬בארגון אין אלמנט הקשור ברשת התקשורת אשר לא מנוטר‪.‬‬

‫רקע לפרוייקט והצורך‪:‬‬

‫בארגון קיים מרכז שו"ב (‪ Network Management Center‬בלשון הארגון) שהוא הלקוח העיקרי של המערכת‪.‬‬
‫מרכז זה מהווה מרכז יחיד מסוגו בארגון והוא עובד סביב השעון‪ .‬המרכז יכול לטפל בממוצע ב ‪ 3222‬התראות‬
‫ביום עקב מגבלות של כוח אדם‪ .‬כמות הנתונים שזורמים מהמערכות מגיע ל ‪ 02‬מיליון ביום ולכן חיפשו בארגון‬
‫מערכת שתדע להתממשק בקלות למערכות הקיימות בלי צורך בחיבור מיוחד‪ .‬כמו כן חיפשו כלי שייתן יכולות‬
‫לסינון התראות‪ ,‬קורלציה ואוטומציה שיקלו על הבקרים בשו"ב‪ .‬אחד היעדים בפרוייקט היה להגיע למצב של‬
‫"התראה אחת לארוע אחד" ולהמנע מריבוי התראות עבור ארוע בודד אשר הביאו בעבר להצפת מידע מיותרת‪.‬‬
‫נושאים אחרים שהוגדרו כחשובים הם ממשקים למודולים של ניטור רשתות נתונים‪ Probes ,‬לפתרונות צד ג'‬
‫רבים ככל האפשר ועלויות תחזוקה סבירות‪.‬‬
‫בשורה התחתונה‪ :‬היו להם יותר מדי קונסולים של שו"ב ויותר מדי מסכים‪ .‬הבקר לא מסוגל לראות יותר ממסך‬
‫אחד בכל זמן נתון ולכן רצו למצוא כלי אחד שיתן כמה שיותר יכולות וימלא כמה שיותר צרכים עבור מפעילי‬
‫השו"ב‪.‬‬

‫על המערכת‪:‬‬
‫מאוד מרוצים מהמערכת שנבחרה‪ .‬מדי פעם מוספים לה מודולים ויכולות נוספות כמו למשל מודול ‪ITNM‬‬
‫שמפאשר גילוי והגדרת תקלות ברשת ה‪ IP‬בלי צורך להתחקות אחרי כל תקלה ועקב קבלת המבנה ההיררכי של‬
‫כל תקלה והגורמים\מערכות הקשורים בה‪ .‬בשעתו נבחנה מערכת זו מול מערכת אחרת של ‪ TTI‬בשם ‪Netrac‬‬
‫אשר נפסלה לבסוף בשל סיבות טכניות ומסחריות‪.‬‬
‫לקוחות המערכת הם מרכז השו"ב ויחידות ההנדסה שמפעילות את רשתות הארגון‪.‬‬
‫כמו שהוזכר כבר למעלה‪ ,‬ניטור הרשת נעשה לגבי כל שירות‪ ,‬פרוטוקול או התקן קיים‪ .‬מכיוון שישנה מגבלה‬
‫אובייקטיבית של כוח אדם‪ ,‬חלק ממושאי הניטור נאספים לצורך תיחקור בדיעבד במידת הצורך ולא מסתכלים‬
‫הערה חשובה‪:‬‬
‫סיכום דיון זה אינו מהווה סקר שוק‪ ,‬המלצה או מחקר‪ ,‬אלא מספק תמונת מצב סטאטית לגבי הנעשה בארגונים‬
‫שהשתתפו בדיון‪.‬‬
 ‫‪Moshav Bnei Zion P.O.Box 151, 60910 Israel Tel. 972-9-7907000 Fax. 972-97442444‬‬

‫עליהם בזמן אמת‪ .‬עומק הניטור נגזר ממספר הבקרים במשמרת‪ .‬מספר הבקרים נע בטווח זמן של ‪ 04‬שעות בין‬
‫‪ 0‬בלילה לעד ‪ 8‬בשעות העבודה‪.‬‬
‫לפיתרון מספר תכונות מיוחדות כמו יכולות לזיהוי קורלציות בין ארועים ובין טופולוגיית רשת‪ .‬בארגון פיתחו מנוע‬
‫אוטומציה של טיפול בתקלות‪ ,‬אתחול מערכת‪ ,‬הרמת שירות וכו'‪ .‬המגבלה בהפעלה של יישום זה היא לא‬
‫טכנולוגית אלא החלטה ארגונית לגבי מימוש היכולות‪.‬‬
‫סוגיית ה ‪ ROI‬נבחנה גם היא בפרוייקט זה‪ .‬בשונה מפרוייקטים עסקיים‪ ,‬קשה למדוד את התרומה של פרוייקט‬
‫שו"ב לעסק‪ .‬מקבלי ההחלטות בארגון לא מצפים מפרוייקט כזה להביא הכנסות חדשות אלא לצמצם הוצאות‬
‫מיותרות במקרים מסויימים‪.‬‬

‫טיפים ולקחים לארגונים אחרים‪:‬‬

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

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