מ כ ר ז מ ע ר כ ו ת ש ו " ב כללי... 3 המערכת נדרשת לספק את התוצרים הבאים:... 3 המערכת נדרשת לספק את התועלות הבאות:... 4 יכולות מרכזיות נדרשות:... 4 תי

מ כ ר ז מ ע ר כ ו ת ש ו " ב כללי... 3 המערכת נדרשת לספק את התוצרים הבאים:... 3 המערכת נדרשת לספק את התועלות הבאות:... 4 יכולות מרכזיות נדרשות:... 4 תיחום פרויקט... 4 עקרונות ניטור... 5 מצב קיים... 6 טבלת מערכות שו"ב קיימות.... 6 - ניטור תשתיות סביבת...7 Microsoft SCOM 7... vrealize ניטור תקשורת... 7 Aternity ניטור עמדות הקצה...8 9...Elasticsearch מהות הבקשה... 9 קונסול מרכזי...MoM 9 דרישות ארכיטקטורה וטכנולוגיה...9 דרישות פונקציונאליות...0 דרישות BI ודוחות...3 דרישות שימושיות ו 14...GUI דרישות רמת שירות... 15 ניטור תשתיות... 16 כללי...6 חבילות ניטור... 16 דרישות חבילות ניטור...7 מ"ה: 17...LINUX, UNIX,WINDOWS 18...Ms-Sql-Server 1 1.2 1.3 1.5 1.6.2 2 2 2.2 2.3 2.4 2.5.3 3 3 3.2 3.3 3.4 3.5 3.2 3.2.0 3.2 3.2.2 3.2.3 3.2.4

19... Active Directory תשתית 19... SAP 20... Exchange 20... IIS 20... SPS 20... CA מערכות לווין... 21 21...DCM 21... SNS++ ממשקים נוספים... 21 21... Active Directory 21...Service Desk 22... SIEM 22...TRAP Server ו SNMP מימוש... 22 כללי) I (... 22 גורמים מעורבים... 22 גורמים פנימיים )I(...22 יצרן רכיבי הפתרון...22 קשר ליצרן...22 צוות הפרויקט של הספק...23 דרישות בעלי תפקידים... 23 תפקיד מנהל פרויקט... 24 תכנית עבודה... 25 שיטת ההקמה... 25 שלבי פרויקט...26 תכן... 27 התקנת תשתית ורכיבי המערכת... 27 תכנון...27 ביצוע מבחני מסירה וקבלה כולל איטרציות תיקונים... 28 העברה לייצור...28 3.2.5 3.2.6 3.2.7 3.2.8 3.2.9 3.20 3.3 3.3 3.3.2 3.4 3.4 3.4.2 3.4.3 3.5 4. 4 4.2 4.2 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6 4.3 4.3 4.3.2 4.4 4.4 4.4.2 4.4.3 4.4.4

השלמת תיעוד, כתיבת נהלים והוראות עבודה...28 תקופת הרצה בייצור... 28 לוח זמנים למימוש... 28 פיצוי מוסכם בגין אי עמידה בלו"ז פרויקט ההקמה... 30 חלוקת אחריות... 30 שירות ותחזוקה... 31 תחזוקת יצרן...32 תחזוקת ספק...32 פיצוי מסכם בגין אי עמידה ברמת שירות...32 הדרכה... 33 הדרכה והטמעה בפונקצית...33 NOC הדרכת צוותים מקצועיים...34 אינדקס תיעוד... 34 היפרדות... 35 4.4.5 4.4.6 4.5 4.5 4.6 4.7 4.7 4.7.2 4.7.3 4.8 4.8 4.8.2 4.9 40 כללי אגף מערכות מידע ומחשוב מבקש להקים מערכת לניהול, ניטור, שליטה ובקרה, להלן נשו"ב, על מערך המיחשוב של שירותי בריאות כללית. סביבת הניטור תכלול את הרשת הכללית)מטה, מחוזות, מרפאות, בתי-חולים(,,Data Centers אתר,DR איזורי,DMZ סביבות ענן, שירותי אינטרנט של שירותי בריאות כללית. פתרון השו"ב נדרש להיות מאובטח ומאושר על ידי פונקצית הגנת המידע בכללית. המערכת נדרשת לספק את התוצרים הבאים: תמונת מצב בריאות של תשתיות המיחשוב תוך ביצוע של קסטומיזציה לרמת הלקוח תמונת מצב בריאות של היישומים התומכים בתהליכים העסקיים התראות קונקרטיות בזמן אמת על אירועים במערך המיחשוב אשר עלולים לשבש את שירותי ה- IT כלי עזר מרכזי לעבודה של פונקצית - NOC קונסול מרכזי לניהול והפעלת מערך השליטה ובקרת התשתיות, האפליקציות והשירותים העסקיים.)BSM( תפיסה אחודה המאגדת את כלל הגורמים באמצעות מסך מרכזי. כלי עזר מרכזי לצוותי ה.Proffessional Services ממשק למערכת SIEM-SOC לסיוע באיתור אירועי אבטחת מידע 1

המערכת נדרשת לספק את התועלות הבאות: שירותי IT איכותיים עם ערך מוסף משמעותי לתהליכים העסקיים - מדיניות תפעול פרו- אקטיבית המבוססת על קריטיות העסקית של המערכת. שירותי IT בעלי זמינות וביצועים נאותים. שירותי IT מועילים ויעילים. תמיד צעד אחד קדימה פרואקטיביות. מערכות ניהול השירות ותמיכת שפה אחיד עם - שביעות רצון של לקוחות ומשתמשים משתמשים. יכולות מרכזיות נדרשות: יכולת זיהוי ואיתור של Root Cause לתקלות..IT יכולת מדידה ותצוגה, לייצוג אחיד של ביצועים ולהערכת איכות שירותי אגירה מידע לצורך ניתות מגמות אינטגרציה יכולת איסוף וקבלת מידע קסטומיזציה של מסכי מערכת לטובת משתמשים שונים תמיכה ב- Workflow לטובת ניטור תהליכים עסקיים עקרונות מערכת - MoM קונסול מרכזי תהליך מרכזי לניהול והפעלת מערך השו"ב: תשתיות, אפליקציות ושירותים עסקיים. תפיסה אחודה המאגדת את כלל הגורמים באמצעות מסך מרכזי. מדיניות תפעול פרו-אקטיבית המבוססת על קריטיות עסקית. יכולות אחסון וניתוח אירועים היסטוריים לתחקור והפקת לקחים ואיתור מגמות AI Ready בסיס לאוטומציה ממשק דו כיווני למערכת לניהול ה Service Desk של מערך ה IT הארגוני. תיחום פרויקט א. רכש רישוי תוכנה,הקמה, התאמה, הטמעה, הדרכה ותחזוקה של מערכת מרכזית בתפיסת.BSM מסגרת ההקמה תכלול ניטור של 5 יישומים/תהליכים במתקונת.MoM רכש רישוי תוכנה, הקמה, התאמה, הטמעה, הדרכה ותחזוקה של מערכת לניטור תשתיות אשר תכלול את המודולים/רכיבים הבאים: LINUX ו-,UNIX מערכות הפעלה מסוג חלונות, 1.2 1.3 1 1 SQL-Server תשתיות ) Netweaver ( SAP ADS

exchange SPS IIS Microsoft - CA מימוש, התאמה והטמעה של מודול להפצה וניהול נוטיפיקציות.SNS++ אינטגרציה מלאה של מערכת ה- MoM מול מערכות מנטרות קיימות וחדשות, להלן: Spectrum ניטור תקשורת SCOM ניטור תשתיות מיקרוסופט vrealize ניטור תשתיות וירטואליזציה Zabix - UNIX ניטור תשתיות Aternity ניטור עמדות קצה APM מוצר שייבחר במכרז מקביל מערכות ניהול/ניטור של מוצרים דוגמת,Oracle מערכות איחסון קבלת התראות ממערכות ניטור מקומיות נוספות קבלת התראות ישירות מציודים ג. ד. ה. מימוש ממשקים נוספים למערכת ה-,MoM להלן: Active Directory DCM מוצר בפיתוח מקומי RBA לטובת Eyshare, Control-M Elastic Search מערכת,SIEM ממשק חד צדדי מערכת ניהול השירות SD.Broadcom/CA עקרונות ניטור נדרש לנטר את מערכות המידע המסופקות על ידי המטה, בדגש על מערכות המידע הקריטיות. 1. נדרש לנטר את כלל מערכות המידע בבתי החולים ויחידות הסמך באחת מרמות השירות 2. הבאות: פלטינום ניטור כלל המערכות באופן זהה למערכות המטה. א. ניטור מערכות קריטיות בדומה למערכות המטה. יתרת המערכות בהתאם גולד לשיקולי היתכנות טכנולוגית ותקצי סילבר ניטור מערכות קריטיות בדומה למערכות המטה. ג. ארד ניטור של מערכות המטה בלבד. ד. 1.6

3. יש לאסוף אירועים בעלי משמעות תפעולית ולייצגם מעל מערכת מרכזית המציגה את רמת בריאות השירותים שאגף המחשוב מספק. 4. יש למסד תהליכי עבודה אשר יעשו שימוש במידע המתקבל מהמערכות המנטרות לטובת מעבר לגישה פרו-אקטיבית באמצעות שילוב של פונקציית.NOC 2. מצב קיים 2 מערכת שוב טבלת מערכות שו"ב קיימות. סביבת ניטור תכנון עתידי ניטור תשתיות מיקרוסופט בלבד באמצעות חבילות וונילה או החלפה כוללת על ידי מערכת ניטור התשתיות העתידית מידע נוסף גרסה 2012R2, פיתוח מקומי Orcastrator לאינטגרציה פיתוח מקומי אינטגרציה עם DCM ו - ESM Active Directory, IIS, SQL-Server,,SharePoint, OS-Windows, CA ניטור יישומים באמצעות,SAP,AVICODE חומרה- שרתים SCOM ZABIX ניטור מערכות UNIX עבור שרתים פיזיים ומערכות LINUX תחת VMWare ירידה הדרגתית עד סגירה, הסבה ל- vrealize ו/ או מערכת ניטור תשתיות המוצעת במכרז זה וירטואליזציה בתהליך הרחבה LINUX מערכות הפעלה,VMWare vrealize #.2.3 ניטור תקשורת מטה, שדרת הרשת ובשלב כניסה לבתי חולים, מחוזות ומרפאות ניטור LAN's במחוזות, מרפאות ובתי חולים ניטור עמדות קצה עבור יישומים קריטיים דוגמת קליקס סגירה ניטור תקשורת, שרת SNMP שרת לקבלת מידע מציודים בתהליך של קונסולידציה ל- Spectrum פריסה של כ 18,000 תחנות קצה סיוע באינטגרציה במידת צורך ניטור תחנות FAT Client TBD בשימוש Run Book Automation מוגבל בסיסי נתונים Oracle איסוף לוגים, לוגיקה עסקית, BI ניטור Oracle איסוף לוגים, לוגיקה עסקית, BI ניטור לוגים Spectrum IMC Aternity Eyeshare Oracle Manager Elastic search בקרת מצלמות בקרת מצלמות חדרי מחשב ללא שינוי בשימוש של ה NOC והביטחון.4.5.6.7.8.9 0

ניטור סביבת חדר המחשב בקרת אקלים ללא שינוי בשימוש של ה NOC והלוגיסטיקה 1 Microsoft ניטור תשתיות סביבת - SCOM Management ממומש בכללית ברמה של סוכן מערכת הפעלה עבור ניטור בסיסי ובתוספת SCOM,IIS,SQL-Server,eXchange,Active Directory יעודיים לניטור תשתית אפליקטיבית: PACKs.CA,SharePoint מעבר לשימוש בחבילה ברמת הוונילה בוצעו פיתוחים הן ברמה של Management PACS והן ברמה של תוספת ניטורים ל- PACKs הקיימים, תוך ביצוע אינטגרציה מעמיקה לסביבה הטכנולוגית של הכללית מול מערכת ניהול )DCM( Data Center מקומית ומערכת נוטיפיקציות.)ESM( כמו כן שולבו במערכת ניטורים אפליקטיביים על בסיס.AVICODE המערכת ממומשת בגרסת 2012R2 SCOM וחסרת תיעוד ברובה. המערכת מנטרת כ- 5,000 שרתים. הפצת הניטורים באמצעות CSSM )כל חבילות הניטור מופצים באופן אחיד לכל השרתים, הפעלה של המוניטורים לפי תצורת השרת(. אינטגרציה מבוצעת ברובה באמצעות,Orecastrator תהליכי אצווה מתוזמנים ברובם באמצעות.CTRL-M אין לוח ארועים מרכזי לכלל פעילויות התפעול. קבלת חיווי ממערכות חומרה HP ו- Dell מתבצעת על ידי תוכנות הניהול של השרתים אשר כותבות קובץ XML בשרתי הניהול של.SCOM שליחת אתראות למנהלי מערכות מיושמות על ידי שימוש באינטגרציה מול ( DCM מאגר מערכות, תומכים, תורנים( תוך שימוש ב- Orcastrator ושליחת נוטיפיקציות ב-.UNICEL אירועים נשמרים ברמה תפעולית למשך שבעה ימים, ובשרת ה DWH למשך שנה. לצורך דוחות ומסכי תצוגה ב NOC נעשה שימוש ב.SQUREDUP החלטה לגבי עתיד מערכת SCOM בכללית תתקבל לאחר התקשרות עם ספק זוכה במכרז זה. vrealize ניטור מערכת VMWare ושרתי LINUX מתארחים מתכונן לביצוע באמצעות.vRealize כיסוי ניטור מערכות LINUX הנו חלקי ומתנהל תהליך להרחבת הניטור ופריסה לכל השרתים המתארחים. יש תשתית VSAN נפרדת עבור מערכות הניטור, אין כרגע הפרדה ברמת,Firewall כך שבעת תקלה רוחבית במערכת VMWare או במערכי האיחסון ניתן יהיה לקבל מידע ממערכות השו"ב לגבי התקלה. מידע נשמר במערכת למשך של 6 חודשים. ניטור תקשורת ניטור מערך התקשורת מפוצל ל- 2 מערכות שונות: 2 2.2 2.3

Data Centers שדרת הרשת ו,WAN עבור רשת ה Spectrum IMC עבור רשתות LANs בבתי החולים, המחוזות והמרפאות מבוצע תהליך קונסולידציה למעבר ל Spectum עבור כלל רשת הכללית. Spectrum מערכת Spectrum מבית Broadcom/CA מנטרת את ה WAN עד לממשק קישוריות של הנתב ל LAN באתר המרוחק, ואת שדרת הרשת וה Center Data באתר המרכזי. בנוסף לשימוש במודולי Fault ו Performance נעשה שימוש במודלים נוספים עבור ניטור בקרת QoS ובקרת תצורה. היקף הניטור הנוכחי עומד על כ- 4,800. Network Device הרישוי הקיים הנו Network 6,000.Devices עבור ה- NOC בוצעה התאמה של מסך תצוגת סטאטוס, אשר אליו מתחלחלים אירועים באופן שוטף, ניתן באמצעות מסך זה לקבל תמונה כללית של סטאטוס קווי התקשורת. המסך אינו מאפשר קבלת חיווי לתקלה בדידה ברמת תצוגת ברירת המחדל. הוגדרו חוקים של אגריגציה אשר משפיעים על צבע ותצוגת המסך. 2.3 IMC 2.3.2 כאמור המערכת נמצאת בשלבי הסבה ל-.Spectrum נעשה שירות במודול הניטור, על בסיס שרתי ניהול המותקנים ב DC אשר נותן שירות לכלל בתי החולים והמחוזות והסניפים ברמת ה.LAN המערכת ממוקדת בניטור ציודים מבית.HP המערכת מותאמת כך שכל יחידה ארגונית בכללית מקבלת תצוגה אשר כוללת את התשתית ורשת התקשורת אשר משרתת אותה )למשל קמפוס בילנסון(. עקב ההיקפים וגודל המערכת לא מבוצע שימוש שוטף במודול ה-.Discovery לא נעשה שימוש בניטור של NetFlow ו/או פרוטוקולים דומים, דבר אשר מונע ניתוח ותמיכה ב QoS באופן שוטף, ומצריך מידי פעם שימוש בסניפר ברמה לוקאלית וכפעולה מגיבה ולא כפעולה פרו-אקטיבית. המערכת משמשת כשרת Traps עבור ציודי אבטחת מידע הפרוסים בתחומה, השימוש ברמה בסיסית. Aternity ניטור עמדות הקצה המערכת מנטרת עמדות עבודה של משתמשים ב- 2 יישומים מרכזיים: קליקס )חוות סיטריקס מוגדרים כ- 18,000 משתמשים( וקמיליון. לכל יישום נבנה פרופיל ניטור אשר מופץ לעמדות העבודה. משתמשי המערכת מנהלי היישומים וצוותי אינטגרציה. למערכת פותח DashBoard אשר מציג את סטאטוס עמדות העבודה ברמת OnLine עם יכולת Drill Down לאירוע אשר השפיעה על שינוי סטאטוס/צבע/רכיב תצוגה. 2

אירועים קריטיים מועברים למנהל מערכות באמצעות אינטגרציה בין Aternity ל- Eyeshare אשר מעביר את המסרים למערכות ה.Massaging Elasticsearch הכללית בחרה במוצר לצורך איסוף וניתוח לוגים ממערכות המידע. אין כרגע איסוף פעיל של לוגים ממערכות הניטור ל-.Elasticsearch בוצע POC בו הודגמו יכולות של שילוב מידע ממערכות שונות לדוח,,DashBoard מסך אחיד על מנת להגיע לתובנות הכרוכות בקשרים בין נתונים ממערכות שונות ולהגיע למסקנות לגבי השפעות ותלויות אשר אינן מובנות האופן ישיר. מהות הבקשה קונסול מרכזי MoM במסגרת הבקשה הכללי יש להציע פתרון לפונקצית קונסול מרכזי -.MoM : א. ג. שם מוצר, שם יצרן, מק"טים נכללים, גרסאות תוכנה, רישוי, כמויות תקציר של הפונקציונאליות ותכונות של המערכת המוצעת, לצרף קישור ל- White paper של המוצר באתר האינטרנט של היצרן. 2.3 3 דרישות ארכיטקטורה וטכנולוגיה דרישה פירוט 3 # עמידה בפרץ אירועים לרמות של לפחות 3000 אירועים לשנייה. ביצוע בדיקת עומסים בעת מבחני הקבלה, הקצאת משאבים עבור שרתי המערכת. TEC01 ארכיטקטורה ללא SPOF תמיכה מלאה בעבודה תחת VMWare כולל בסיסי נתונים סגמנט NOC לפי דרישה והקצאה של כללית שרידות יכולת התאוששות מכשלים אוטומטית. המערכת תהיה בעלת יכולת יתירות במובן של ביצוע התאוששות מהירה ממצבי נפילה. יש לפרט האם המדובר ביכולת ידנית / חצי אוטומטית / אוטומטית מלאה, והאם היא מושתתת על פתרון תשתיתי של מערכת ההפעלה / מערך האחסון / בסיס הנתונים )אחד או שילוב ביניהם( או שהמדובר בפתרון אפליקטיבי ייעודי. יש לפרט על מנגנון התאוששות של האינטגרציה מול המערכות המנטרות. TEC02 TEC03

אבטחת מידע: עבודה מאובטחת מעבר לחומת אש PKI תמיכה ב ADS קישור ל Automation Ready,AI שרתי ביניים שימוש ב- CA של הכללית TEC04 יכולת לשילוב עתידי של מערכות AI ו- Automation על בסיס הארכיטקטורה ואינטגרציה מובנית וסטאנדרטית ללא צורך בהחלפת מערכות והתערבות פנימית בהם לצורך מימוש האינטגרציה. TEC05 יש לתאר את ארכיטקטורת המערכת ולהתייחס לחלוקה בין שירות ה-,Web האפליקציה, בסיס הנתונים והממשקים. על המערכת להיות בעלת ממשק Webי לפחות. יש לציין האם קיימת התקנת.Desktop יש לציין תמיכה בדפדפנים, סוגי שרתי ה-,Web מ"ה, הקשחות, והאם נעשה שימוש ברכיב Java ומאילו הפצות וגרסאות. TEC06 יש למלא את גיליון תשתיות בקובץ אקסל כספי. יש לתאר את המבנה תשתית עליה יותקנו רכיבי התוכנה של המערכת בהתייחס ל: כמות שרתים דרושה להקמת המערך. יכולת עבודה בסביבה וירטואלית כולל שימוש ביכולות היתירות וההמשכיות העסקית של סביבה זו )בדגש על )VMware האם יש דרישה לשימוש בשרתים פיזיים? ולאיזה צורך? יש לפרט באופן נרח דרישות חומרה מעבד, משאבי זכרון, גודל בסיס נתונים, סוג ודרישות מ"ה. פורטים בשימוש דרישות מיוחדות בנושא גיבויים ועבודה בסביבה של אחסון מרכזי. TEC07 המערכת תהיה בעלת יכולת לעבוד באופן מלא מול מערכת מרכזית לניהול זהויות ולאפשר ניהול כניסה והרשאות מבוסס רישום נתוני משתמש ברשת מרכזית ובכלל זה ביצוע SSO ללא צורך בהזדהות נוספת. נדרשת תמיכה בפרוטוקול SSL עבור תעבורה מוצפנת וגישה ב.HTTPS המערכת המוצעת תתמוך בהנפקת תעודות אשר יחתמו על ידי שרת ה- Certificate Authority המרכזי של הלקוח. TEC08 דרישות פונקציונאליות דרישה פירוט/הסבר 3.2

מודול להגדרת חוקי קורלציה ואגריגציה עבור כלל האתראות הנכללות בקונסול מרכזי, ללא הבדל מערכת מנטרת FUN01 ניתן לשייך אזעקות לקבוצת אירוע ממשק ל,ADS עבודה לפי ROLES FUN02 ניתן לסווג Event כ-.Root Cuase ניתן לשייך אירועים ממערכות שונות כ Impacted וככרטיסי בן, בעת סגירת כרטיס האב (RC) יסגרו כרטיסי הבן באופן אוטומטי. FUN03 אינטגרציה תמיכה בכל שיטות האינטגרציה המקובלות. יכולת קבלה ואיסוף של מרחב אתראות רחב - תמיכה במגוון שיטות איסוף, פרוטוקולים, סוכן/ללא סוכן. Syslog,API,SNMP V2&V3,TRAPS FUN04 המערכת תהיה בעלת API מובנה דרכו ניתן יהיה להפעיל אותה ולשדר אירועים מאפליקציות ייעודיות שלא תתמוכנה באחד מהממשקים או סוכני הניטור הייעודיים FUN05 אינטגרציה ל-,SCOM האחריות בצד SCOM של הלקוח קבלת התראות SCOM בקונסול המרכזי מתורגמות ל"סרגל" השורות של הקונסול המרכזי, ללא אבדן מידע, תרגום רמת,Severity העשרת מידע בכרטיסים קיימים, סגירה בעקבות קבלת אירוע, נגישות לבסיס הנתונים לצורכי דוחות של ביצועים וזמינות, שרידות ויתירות של מנגנון של האינטגרציה. FUN06 אינטגרציה ל-,Spectrum האחריות בצד Spectrum של לקוח קבלת התראות Spectrum בקונסול המרכזי מתורגמות ל"סרגל" השורות של הקונסול המרכזי, ללא אבדן מידע, תרגום רמת,Severity העשרת מידע בכרטיסים קיימים -,Enrichment יכולת למימוש Root,Cuase Topology סגירה בעקבות קבלת אירוע, נגישות לבסיס הנתונים לצורכי דוחות של ביצועים וזמינות, שרידות ויתירות של מנגנון של האינטגרציה. FUN07

אינגרציה ל-,Elasticsearch האחריות בצד Elastic של הלקוח העברת לוגים ואירועים באופן שוטף של המערכת לאלסטיק, בניית "עולם" תואם באלסטיק למערכות השו"ב, בניית לוגיקה מול "עולם השו"ב", שילוב מידע ממערכות השו"ב עם מידע ממערכות ניהול ואפליקציות, הפקת "חוכמה" ותובנות במערכת ברמה של מגמות, ניהול קיבולת ורמה תפעולית שוטפת. FUN08 Dynamic Treshholds יכולת למידה של המערכת, זיהוי של מצב שגרה ובהתאם קביעת ספים להתראות באופן דינאמי FUN09 אינטגרציה ל- vrealize ו/או,Zabix האחריות בצד vrealize של הלקוח קבלת התראות של vrealize ו/או Zabix בקונסול המרכזי מתורגמות ל"סרגל" השורות של הקונסול המרכזי, ללא אבדן מידע, תרגום רמת,Severity העשרת מידע, קישור לכרטיסים קיימים, סגירה בעקבות קבלת אירוע, נגישות לבסיס הנתונים לצורכי דוחות של ביצועים וזמינות, שרידות ויתירות של מנגנון של האינטגרציה. FUN10 יכולת בניית מסכים מותאמים על פי תפקיד. קונסול המרכזי יציג את כלל האירועים המתנקזים אליו לפי דרגת הדחיפות שלהם כאשר אירועים מערכתיים ו/או בעלי דרגת דחיפות עליונה יוצגו במיקום ייעודי ובולט בקונסול האירועים. הגדרה של, Role מתן הרשאות ברמה של,Role שיוך משתמשי AD ל.Roles משתמש יכול להיות משוייך למספר.Role - BSM יכולת הגדרה של אוסף ניטורים/ CI's לאובייקט המייצג שירות, פעפוע התראות ושיוכן לאובייקט, תצוגה.Top-Down של השירות העסקי, יכולת לניתוח השפעות, יכולת לביצוע מידול ברמה של UI FUN11 FUN12 אינטגרציה ל-,Aternity האחריות בצד Aternity של הלקוח קבלת התראות של Aternity בקונסול המרכזי מתורגמות ל"סרגל" השורות של הקונסול המרכזי, ללא אבדן מידע, תרגום רמת,Severity העשרת מידע לכרטיסים קיימים, סגירה בעקבות קבלת אירוע, נגישות לבסיס הנתונים לצורכי דוחות של ביצועים וזמינות, שרידות ויתירות של מנגנון של האינטגרציה. FUN13

אינטגרציה ל-,APM אחריות בצד APM היא של זוכה מכרז ה- APM קבלת התראות ממערכת APM בקונסול המרכזי מתורגמות ל"סרגל" השורות של הקונסול המרכזי, ללא אבדן מידע, תרגום רמת,Severity העשרת מידע כולל לכרטיסים קיימים, סגירה בעקבות קבלת אירוע, נגישות לבסיס הנתונים לצורכי דוחות של ביצועים וזמינות, שרידות ויתירות של מנגנון של האינטגרציה. FUN14 פעולות והפעלת אזעקות משלוח בקונסול אירועים לגבי מתקנות בהתאם אופנים במספר יתבצעו למהות האירוע: משלוח Email לגורמים המעורבים כאשר הדיווח יתבצע לפי רשימות תפוצה הניתנות לניהול בכדי לאפשר גמישות. משלוח SMS/WhatsApp לגורמים המעורבים. Service Desk פתיחת קריאות ב- באופן חצי אוטומטי )סגירה תתבצע באופן ידני או חצי אוטומטי(. פעילות פרואקטיבית - הפעלת סקריפטים / פעולות אצווה בהתאם לשיקולים של האחראי המקצועי לביצוע פעולות מתקנות /מונעות. שימוש ביכולות של Smart routing של SNS++ לצורך משלוח נוטיפיקציות. שימוש ב WebService של CA SD לפתיחת כרטיס/קריאה במכרז השירות FUN15 נדרש מנגנון Maintenance Windows על מנת שלא לקבל אירועים עבור רכיב הנמצא במצב של תחזוקה ניתן לסמן רכיבים ברמת רכיב בודד וברמה של קבוצה. קיים לוח שנה משותף לצפייה בחלונות התחזוקה שהוגדרו FUN16 3.3 דרישות BI ודוחות דרישה פירוט/הסבר משקל /סיווג # תצוגה של DashBoards תפעוליים התאמה של יכולות וונילה אינטגרציה עם מערכות תצוגה יכולת שליפה מבסיס הנתונים של SCOM BIH01

על המערכת להיות בעלת מנגנון לאיסוף כלל נתוני ההתראות ההסטוריות לבסיס נתונים עבור תחקור והפקת דוחות עבור כל נתון שנאסף הן בהיבט התפעולי השוטף והן בהיבט של ביצועים וסטטיסטיקות. שמירת מידע לפרקי זמן ממושכים מכלל המערכות המנטרות. א. ג. יש לתאר את מנגנון איסוף ותחקור ההסטוריה ולהתייחס ליכולת עדכון מועדי שמירת / מחיקת הנתונים על ציר הזמן בהיבטי קיבולת בסיס הנתונים והביצועים. כמו כן יש לתאר את יכולות העברת נתוני ההתראות ההסטוריות לבסיס נתונים ו/או מערכת BI חיצונית כגון: שימוש בכלי,ETL גישה ישירה ל,DB ממשק מובנה ברמת המוצר עבור דוחות מגמה אופן ההשתלבות מול Elasticsearch BIH02 יש לפרט לגבי אופן שמירת אירועי BSM שנוצרו במחסן נתונים היסטורי והיכולת לתחקר אותם. יש לציין האם קיים רכיב תחקור שהנו חלק מובנה במוצר או שנעשה שימוש בכלי תחקור שהנו חלק מכלל פתרון מערך השו"ב של. יש לפרט לגבי הדוחות המובנים המגיעים עם המוצר. יש לפרט לגבי גישה לבסיס הנתונים והעברתם לבסיס נתונים חיצוני אחר של מערכות מסוג BI / Big Data יש לפרט לגבי שילוב עם Elasticsearch Top10 ל DashBoards BIH03 דוחות ותצוגת שעונים מוכנים מראש BIH04 DashBoards לביצועים וזמינות מבוסס KPI's שילוב של יעדי SLA והגדרה של,TreshHolds והצמדה של תגובה ואסקלציה נדרשת. BIH05 בסיס נתונים פתוח לחיבור ל- ODBC/JDBC יכולת עצמית לפיתוח דוחות. נדרש להבין את הסכמה ואת ה-.Meta Data BIH06 דרישות שימושיות ו GUI דרישה פירוט 3 # UI שילוב של תצוגת שורות ותצוגה גרפית של שירותים, פעפוע והצגת אירועים על גבי תצוגה גרפית של GUI01

השירות. יכולת הצגה וסינון בזמן אמת של כלל הנתונים הנוצרים / מתקבלים בהתייחס למקורות המדווחים, השירותים שמודלו, השייכות לצוותי התשתית / האפליקציה האחראיים על המערכת וכדומה. יש לפרט לגבי אופן תצוגת הנתונים במערכת ולהתייחס לתמיכה ב: תצוגה אלפא נומרית. א. תצוגה גרפית ברמת עץ שירות המערכת. תצוגה גרפית למול ערכים סטטיסטיים ושעוני.KPI ג. תצוגה גרפית מבוססת מפה סכמתית ו/או מפת מבוססת ממשק ליישום.GIS ד. Dashboard / Portal רמת שירות משול על האירועים בקונסול לכלול לפחות את המידע הבא: שם מערכת, זמן אירוע, שם רכיב, סוג רכיב, שם מערכת, תוכן האירוע, דרגת חומרה, גורם מטפל. יש לתאר שדות סרגל האירוע בקונסול, ואת יכולות ההתאמה/ פילטור של תצוגת האירוע GUI02 החצנה של DashBorads למובייל תמיכה ברמת אפליקציה ב- IOS ו- אנדרואיד. עמידה בהנחיות והוראות הגנת המידע. GUI03 החצנה של Web Services בפרוטוקול Rest על מנת לאפשר תצוגות באנגולר. תמיכה ב-.Web2 הפרדת שכבות נאותה של מערכת הניטור GUI04 דרישות רמת שירות דרישה פירוט 3 # היצרן של המוצר מתחייב לאספקה של גרסאות ועדכוני אבטחת מידע למוצר המוצע על ידי למשך 5 שנים לפחות. להתייחס לכל מוצר בנפרד SLA01 בשלות: מוצר קיים בשוק 3 שנים + גרסה נוכחית לפחות דור שלישי v3 SLA02

תפוצה: המוצרים המוצעים מותקנים לפחות ב- 3 לקוחות בישראל. רשימת לקוחות בישראל של כל אחד מהמוצרים SLA02 תאימות לטכנולוגיות שירות עתידיות, תמיכה בשיטות של מתן שירותי IT כולל השתלבות בסביבת ענן: פיצול של השירותים בין ענן פרטי לציבורי ואינטגרציה ע"י ענן היברדי. יכולת בקרת SLA לשירותים הן במתכונת מיקור חוץ והן באמצעות שירות פנימי. שקיפות הניטור בענן ללקוח. SLA03 ניטור תשתיות כללי במסגרת הבקשה הכללי יש להציע פתרונות לניטור מערך התשתיות בכללית. : עבור כל מודול ניטור יש לפרט: א. ג. שם מוצר, שם יצרן, מק"טים נכללים, גרסאות תוכנה, רישוי, כמויות תקציר של הפונקציונאליות ותכונות של המערכת המוצעת, לצרף קישור ל- White paper של המודול באתר האינטרנט של היצרן. בהתאם לתכולת ההצעה הזוכה, תחליט הכללית על מידת אימוץ פתרונות הניטור המוצעים. הפתרונות המוצעים בהצעה הזוכה יושוו ברמה של עלות/תועלת, שיקולי תקציב ותכנית עבודה מול הפתרונות הקיימים. הרצון והמגמה היא לייצר אחידות ולעשות שימוש מיטבי בהצעת הספק הזוכה. הצעה עבור סעיף זה צריכה לכלול אינטגרציה מלאה מול מוצר הקונסול המרכזי. חבילות ניטור תוגדר חבילת ניטור עבור כל מערכת הפעלה ותשתית מנוטרת, החבילה תופץ לכל השרתים הרלונטיים. שינוי יבוצע ברמת החבילה בשרת הניהול ויופץ לכל המנויים. ברירת מחדל לספים ברמת החבילה עבור ערכים שיוצבו במערכות הקיימות. על פי החלטת מנהל מערכת אפשר שספים יוגדרו אחרת אם תוך שימוש בספים דינמיים או בהנחייה. ערכים מוספים: איתור אנומליה בדגש על מצבי קיצון, זיהוי מגמות שליליות, סיוע באיתור ופתיחת צווארי בקבוק, וידוי משאבים נדרשים לתהליכים קריטיים. התראות של הסוכן המנטר יועברו למערכת ה,MoM שם יעברו תהליך ניתוח ראשוני הכולל אגריגציה, קרולציה לאירועים אחרים, תיעדוף וניתוב ראשוני לגורם אחראי. לאחר ביצוע ניתוח ראשוני תופנה ההתראה למערכת הנוטיפיקציות לצורך ביצוע Smart routing לבעלי ענין. 3.2 3.2.3 3.2

3.2.2 דרישות חבילות ניטור דרישה יש לתאר את ארכיטקטורת המערכת ולהתייחס לחלוקה בין שירות ה,Web האפליקציה, בסיס הנתונים והממשקים. על המערכת להיות בעלת ממשק Webי לפחות. יש לציין האם קיימת התקנת.Desktop יש לציין תמיכה בדפדפנים, סוגי שרתי ה,Web מ"ה, הקשחות, והאם נעשה שימוש ברכיב Java ומאילו הפצות וגרסאות # ISM01 יש להוסיף במידת הצורך שרתים בנספח השרתים 3 יש לתאר את התשתית עליה יותקנו רכיבי התוכנה של המערכת בהתייחס ל: כמות שרתים דרושה להקמת המערך )בהתייחס לכמות הרכיבים המנוטרים הדרושה(. יכולת עבודה בסביבה וירטואלית כולל שימוש ביכולות היתירות וההמשכיות העסקית של סביבה זו )בדגש על.)VMware האם יש דרישה לשימוש בשרתים פיזיים? ואם כן לאיזה צורך? דרישות חומרה מעבד, משאבי זיכרון, גודל בסיס נתונים, סוג ודרישות מ"ה. פירוט של פורטים בשימוש דרישות מיוחדות בנושא גיבויים ועבודה בסביבה של אחסון מרכזי. ISM02 המערכת תהיה בעלת יכולת יתירות במובן של ביצוע התאוששות מהירה ממצבי נפילה. יש לפרט האם המדובר ביכולת ידנית / חצי אוטומטית / אוטומטית מלאה, והאם היא מושתתת על פתרון תשתיתי של מערכת ההפעלה / מערך האחסון / בסיס הנתונים )אחד או שילוב ביניהם( או שהמדובר בפתרון אפליקטיבי ייעודי. יש להתייחס להתאוששות האינטגרציה מול הקונסול המרכזי. ISM03 המערכת תהיה בעלת יכולת לבזר את רכיבי איסוף האירועים גם עבור הפעלת מנגנון מאובטח באופן המאפשר איסוף, קבלת ושידור נתוני ניטור מוצפנים מאחורי חומת אש לשרת ניהול הניטור המרכזי תוך עמידה בתקני אבטחת המידע הארגוניים. יש לתאר את המנגנון המאובטח ולציין את שיטת ההצפנה והפרוטוקולים בשימוש. ISM04 מ"ה : UNIX,WINDOWS LINUX, סוגי וגרסאות מערכות הפעלה: 3.2.3 2003, 2008R2, 2012R2, 2016 בגירסאות: Windows

בכללית מגוון של מערכות הפעלה מסוגים שונים וממספר גרסאות לכל מערכת. נדרש להציע פתרון ניטור מבוסס סוכן אשר יכלול אופציה לניטור בשיטת.Agent Less ניטור מערכת ההפעלה יכלול לפחות את המרכיבים הבאים: - ניצולת CPU דיסקים - מקום פנוי ספריות - כמות קבצים זיכרון - מקום פנוי -OS Services זמינות - Web services זמינות - Processes סטאטוס וניצולת משאבים - Log files ניתוח מופע של מידע בקבצים אילו ניטור Event Log.2.3.4.5.6.7.8.9 Ms-Sql-Server סוגי וגרסאות בסיסי נתונים: SQL Version Edition Environment Cpu Count Core Count MachineCount SQL Server 2000 Enterprise Edition Prod 14 23 9 SQL Server 2005 Standard Edition Prod 1 2 1 SQL Server 2005 Enterprise Edition Prod 53 176 30 SQL Server 2008 Standard Edition Prod 6 12 2 SQL Server 2008 Enterprise Edition Prod 51 205 25 SQL Server 2008R2 Standard Edition Prod 79 214 50 SQL Server 2008R2 Enterprise Edition Prod 177 709 87 SQL Server 2012 Standard Edition Prod 30 82 14 SQL Server 2012 Enterprise Edition Prod 68 323 33 SQL Server 2014 Standard Edition Prod 33 96 20 SQL Server 2014 Enterprise Edition Prod 71 435 30 SQL Server 2016 Standard Edition Prod 21 42 9 SQL Server 2016 Enterprise Edition Prod 129 598 44 SQL Server 2017 Standard Edition Prod 2 8 2 SQL Server 2017 Enterprise Edition Prod 5 36 3 740 2961 359 3.2 ניטור בסיסי הנתונים יכלול לפחות את המרכיבים הבאים: Processes סטאטוס ונצילות משאבים - Services זמינות Ports סטאטוס.2.3

מקום - שיעור שטח חופשי תורים - עומס Threads סטאטוס ונצילות משאבים.4.5.6 Active Directory גרסאות: 2000/2003/2008 ניטור Active Directiry יכלול לפחות את המרכיבים הבאים: 1. Process סטאטוס ונצילות משאבים.2 Services - זמינות.3 Ports סטאטוס. 4. שימושיות תשתית SAP כאמור ניתן להציע מוצר ייעודי אשר אינו חלק מחבילת הניטור המוצעת. להלן דרישות ניטור בסיסיות ממערך :SAP 3.2 3.2.6 # SAP01 דרישה מוצר הניטור יהיה "רגיש" לארכיטקטורות SAP שונות. ניטור כלל תשתיות ה- SAP בכללית : LINUX ושרתי Oracle מול בסיס נתונים SAP מערכת מערכת SAP מול בסיס נתןנים Sql-Server ושרתי חלונות..LINUX ושרתי SAP HANA מערכת למוצר נדרש אישור/סרטיפיקציה עדכני של SAP עבור הגרסאות הקיימות בכללית תקורת הניטור בשיא לא תעבור 5%, ובממוצע של עד 2.5%, ניתן יהיה לשלוט על התקורה הניטור של מערכות בענן ישתלב בארכיטקטורת הענן ההיברדי של הכללית SAP02 SAP03 SAP04

Exchange גרסאות: 2003/2013/2016.2 ניטור Exchange יכלול לפחות את המרכיבים הבאים: Process סטאטוס ונצילות משאבים - Services זמינות Ports סטאטוס..3.4 IIS גרסאות: נצילות של תיבות-דואר 7/8/10 ניטור IIS יכלול לפחות את המרכיבים הבאים:.2 Process סטאטוס ונצילות משאבים - Services זמינות Ports סטאטוס..3.4.5.6 SPS תורים ניטור HTTP Request ביצועים ברמה של דפים ו- Web parts מול דפדפנים ניטור SPS יכלול לפחות את המרכיבים הבאים:.2 Process סטאטוס ונצילות משאבים - Services זמינות.3.4 CA ניטור CA.2 תורים ביצועים ברמה של דפים ו- Web parts מול דפדפנים יכלול לפחות את המרכיבים הבאים: Process סטאטוס ונצילות משאבים - Services זמינות.3 תורים 3.2.3 3.2.3 3.2.9 3.23

מערכות לווין DCM בכללית פותחה מערכת לניהול מרכיבי ה- Data Center הכוללת את המידע על שרתי הארגון, בעלי תפקידים, מערכות ויישומים. נדרש מהספק לעשות שימוש במערכת זו, במסגרת פרויקט הקמת המערכת והתאמתה. הכללית תאפשר לספק גישה למערכת באמצעות אוסף של web-services אשר יפותחו ויותאמו לדרישות. מידע ממערכת ה- DCM יאפשר: לשייך שרת/מערכת הפעלה לשירות אפליקטיבי לשייך ניטור תהליך לתהליך עסקי לסייע בהבנת Impact של תקלה SNS++ לשייך ולנתב התראות ברמת הקונסול המרכזי להפיץ התראות במערכת הנוטיפיקציות. בכללית מותקנת מערכת SNS++ אשר נמצאת בשירות מערך ה- Networking של הארגון. על מנת לשמור על יציבות תפעולית ולאפשר בנייה מחדש של מנגנון ה- Smart routing יוקם שרת ייעודי נוסף של SNS++ אשר יעבוד מול הקונסול המרכזי ויפיץ את ההתראות בהתאם למדיניות החדשה. הספק יידרש לבצע התאמות נדרשות בקונסול על מנת לממש מדיניות זו באמצעות.SNS++ ממשקים נוספים Active Directory ברירת המחדל לביצוע Login למערכות השו"ב תהיה באמצעות AD הארגוני של הכללית. במידה ו AD לא זמין ניתן יהיה להפעיל את מערכות הניטור ברמה של ה-,NOC גורמים מקצועיים, וממשקי התפעול. הפעלה של ממשקי BSM במצב של אי זמינות של AD אינה נדרשת. Service Desk.2.3.4 במסגרת פרויקט ההקמה יקשר הספק את הקונסול המרכזי למערכת ה- SD בכללית באופן הבא: במסך קונסול השירות המרכזי, יתווסף שירות אשר יפתח במערכת ה SD תקלה על בסיס שורת התראה מסומנת. הפעלת השירות תהיה נתונה להחלטה אנושית ולא תופעל אוטומטית. מסך הקונסול יפעיל Web Service של מערכת ה SD אשר נועד לפתיחת תקלה. שדות וטבלאות תרגום יסוכמו בין הצדדים בהמשך. 5. תקלות אשר יפתחו על ידי קונסול השו"ב ב SD יפתחו תחת קטגוריה נפרדת ושלשות ייחודיות. 3.3 3.3 3.3.2 3 3 3.2

SIEM במסגרת פרויקט ההקמה יקבל הספק רשימת דרישות לניטור עבור מערכת ה- SIEM של כללית. אירועים השייכים לדרישות ניטור אלו יועברו במקביל לפונקצית ה SIEM של הכללית, הממשק יהיה חד-כיווני וללא היזון חוזר. TRAP Server ו SNMP א. ג. ד. שרת ה MoM נדרש בנוסף לספק שירותי SNMP Server ושרת TRAP עבור ציודים אשר ידווחו באופן ישיר התראות ועובר מערכות ניטור מקומיות ייעודיות. להלן רשימת מקורות הניטור אשר יש לחבר באופן זה ל :MoM בסיס נתונים Oracle ניטור באמצעות גריד. מערכי האיחסון בכללית ניטור על ידי תוכנת יצרן. חומרת שרתים תוצרת: Dell,HP ו- IBM )מדווחים במצה הנוכחי ל )SCOM CTRIX ניטור באמצעות תוכנת יצרן מימוש כללי) I ( הספק יידרש להתחייב לבצע את הפרויקט על כל מרכיביו ואת השירותים במלואם, לרבות תכנון, תיעוד, הרצה, התקנה ובדיקות של המערכת, וכן הדרכת מנהלי המערכת מטעם המזמין, ולספק מערכת שלמה ועובדת על פי מפרט זה ובהתאם ללוח הזמנים המוגדר, באחריות כוללת לכל מרכיבי הפרויקט, תוך שיתוף עובדי המזמין או מי מטעמו בפרויקט בכל מקום שיידרש. מבלי לגרוע מאחריותו הכוללת של הספק, יהיה הספק אחראי גם על ניהול, פיקוח, בקרה, בדיקת הביצוע ומתן התרעה מראש לגבי כל חריגה צפויה הנובעת מפעילות של המזמין, על-מנת להבטיח עמידה בלוחות הזמנים ובתקציב הפרויקט וכדי לקדם ביצוע אחיד ואיכותי של הפרויקט. גורמים מעורבים גורמים פנימיים )I( הלקוח הראשי מנהלת תחום פרויקטים רוחביים במשאבי תשתיות ותפעול. מנהל הפרויקט מטעם שירותי בריאות כללית, ישמש כגורם קשר יחיד לספק.)SPOC( יצרן רכיבי הפתרון קשר ליצרן.2 על לצרף את המידע הבא לגבי : סקירת כלל פעילותו העסקית של ב- 3 השנים האחרונות במוצרים המוצעים על ידו. אופי הקשר העסקי שבין היצרן למציע. 3.3 3 1 1.2 1.2 1.2.2 1.2.3

רשימת מומחים הנמנים על עובדי אשר מחזיקים במומחיות מאושרת של היצרן עבור המוצר המוצע. כמות תומכים בכל אחד מהמוצרים המוצעים מידע על לפחות 3 פרויקטי Reference במימוש המוצר המוצע שבצע בארץ ב- 3 השנים האחרונות. לגבי כל פרויקט יש לצרף שם לקוח, מספר טלפון ו-.e-Mail.3.4.5 צוות הפרויקט של הספק א. ג. ד. במסגרת הגשת ההצעה יש למלא את שיעור המשרה המתוכנן לבעל התפקיד בלבד, להלן עמודת % משרה. מידית לאחר קבלת הודעת זכייה, הספק הזוכה ישבץ את בעלי התפקידים לקטגוריה המתאימה בהתאמה לדרישות, יפרט את ניסיונם ויפרט פרויקטים דומים. הזוכה יצרף את קורות חיים של כל אחד מאנשי הצוות הנ"ל ויגישם לאישור הכללית. הכללית תאשר כל בעלת תפקיד. הספק הזוכה מתחייב מראש להגיש מועמד חלופי למוצע וזאת עד אישור בעל התפקיד על ידי הכללית. לאחר אישור המועמדות של בעלי התפקידים המוצעים של הספק הזוכה, לא תהיה אפשרות לספק הזוכה לשנותם ללא תאום ואישור מראש ובכתב של המזמין. 1.2 % משרה תפקיד שם שם ממליץ טלפון ממליץ # מנהל פרויקט ארכיטקט מיישם מערכת MoM מיישם מערכת MoM מיישם ניטור תשתיות מיישם ניטור תשתיות מיישם מודול נוטיפיקציות מומחה אינטגרציה אחראי בדיקות כתב טכני.2.3.4.5.6.7.8.9 0 דרישות בעלי תפקידים מנהל פרויקט א. בעל ניסיון של לפחות 10 שנים במערכות מידע 1.2 1.2

ג. ד. ה. בעל ניסיון של לפחות 5 שנים בניהול פרויקטים בעל ניסיון של לפחות 3 שנים בניהול פרויקטי שו"ב השכלה אקדמאית בתחום רלוונטי ( מערכות מידע, ניהול, פיננסי( הסמכה במתודולוגיה לניהול פרויקטים ארכיטקט א. ג. ד. ה. בעל ניסיון של לפחות 8 שנים במערכות מידע בעל ניסיון של לפחות 5 שנים כארכיטקט בעל ניסיון של לפחות 3 שנים כארכיטקט של מערכות שו"ב השכלה אקדמאית בתחום רלוונטי ( מערכות מידע, ניהול, פיננסי( הסמכה מטעם היצרן של מערכת ה- MoM המוצעת מיישם מערכת /MoM ניטור תשתיות א. ג. ד. בעל ניסיון של לפחות 4 שנים במערכות מידע בעל ניסיון של לפחות 3 שנים כמיישם בעל ניסיון של לפחות 2 שנים ביישום במערכת ה /MoM תשתיות המוצעת הכרה מעמיקה של כלי אינטגרציה, שפות לכתיבת סקריפטים. אחראי בדיקות א. בעל ניסיון של לפחות 4 שנים בבדיקות תוכנה בעל ניסיון קודם בבדיקת מערכות שו"ב תפקיד מנהל פרויקט א. ג. ד. ה. הספק ימנה מנהל פרויקט מיד עם קבלת הזמנה. מנהל זה יהיה איש הקשר וישמש כאחראי המקצועי מצד הזוכה בכל עניין הנוגע לאספקה, לאחריות, לשירות ולתחזוקה של רכיבים ושירותים המסופקים על ידי הזוכה. מנהל הפרויקט יקיים פגישות סטאטוס שבועיות לכל אורך מימוש הפרויקט. פגישות הסטאטוס יתקיימו במשרדי הלקוח. ישתתפו בפגישות אלו מנהלי הפרויקט מטעם הספק ומטעם הלקוח. כמו כן יוזמנו לפגישה גם גורמים מעורבים נוספים על פי הצורך. נוסף על כך, ישמש מנהל הפרויקט כנציג הספק הזוכה בכל הקשור לנושאי ניהול הפרויקט ובכלל זה השתתפות פעילה בוועדות היגוי, הכנת דו"חות מעקב ובקרה, טיפול בבעיות וסיכונים. זמינות מנהל הפרויקט תהיה בכל ימי ושעות העבודה של המזמין. 1.2.2 1.2.3 1.2 1.2.6

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

הפעלה תקינה של התוצר המרכזי בסביבת הייצור למשך שבועיים ברציפות ללא תקלות משמעותיות. שלבי פרויקט על הספק להכין תכנית עבודה מפורטת לפרויקט ההקמה כולל שלבים עיקריים ואבני דרך. איחורים בתכנית העבודה שלא באחריות הספק יגררו דחיית לוחות זמנים בהתאם מבלי שיהיה בכך הפרה כלשהי של התחייבויות הספק. עבור כל פעילות יש לפרט את המידע הבא: מי מאנשי הצוות יבצע כל פעילות ניסיון קודם בפעילות זו להציג תאריכי תחילה וסיום של פעילויות תלויות בין הפעילויות מידע ומשאבים הנדרשים מהמזמין עבור ביצוע הפעילות אבני הדרך המפורטות הינן מנדטוריות. הספק יוכל להוסיף בהצעתו אבני דרך נוספות. הספק יכול להציע גם מקבול שלבים, במידת האפשר או אף מקבול ברמת המשימות הבודדות של כל של כל זאת כדי לייעל את תהליך המימוש. מעבר מאבן דרך אחת לבאה כרוך באישור המזמין. להלן חלוקה לשלבים/אבני דרך: א. ג..2.3 שלב א' מערכת וונילה וממשקים בסיסיים, תכנון הפרויקט תצורה וכתב כמויות - הזמנת רכש על בסיס הצעת המחיר של הספק. ארכיטקטורת על + התקנת תשתית ורכיבי המערכת על פי סעיף 4.4 בהמשך. תכנון אפיון על על פי סעיף 4.4.2 בהמשך, בדיקות, מימוש ממשקי Active Directory.4.5.2 הכנת תכנית עבודה, הכנת תסריטי קישוריות ברמת וונילה למערכות המנטרות:,vRealize,SCOM ספקטרום, אורקל גריד,,Aternity מערכת ניטור למערכי האיחסון,.Zabix ביצוע מבחני מסירה יבוצעו בשיתוף של צוות הספק וצוות הכללית, לפי סעיף 4.4.3 בהמשך איסוף אירועים, בניית ממשק ל- DCM אינטגרציה והעברת אתראות ממערכות מנטרות תרגום סרגל ההתראה של מערכת מנטרת לסרגל מערכת ה-,MoM המרת Severity לרמה המתאימה ב-.MoM ממשק.DCM.3.4 התקנת מערכת ניטור תשתיות. קבלת ניטורים מציודים וממערכות לוקליות. ניתוח אירועים התאמות ובניית קסטומיזציה של קונסול מרכזי 1.3.2

הפצת סוכני ניטור תשתיות 2. בניית חוקים: קורלציה, אגריגציה, ניתובים 3. בניית BSM עבור 2 יישומים/תהליכים עסקיים 4. מימוש מודול נוטיפיקציות 5. כניסה הדרגתית לתפעול מבחני מסירה וקבלה ברמה של מודולים ואינטגרציות 1. הדרכה והטמעה בפונקצית ה- NOC ושל צוותים מקצועיים 2. מסירת תיעוד לפי רשימה בסעיף 4.9 3. העברה לייצור ראה סעיף 4.4.4 בהמשך 4. השלמת משימות וטיוב מערכת הוספה של 3 יישומים/תהליכים עסקיים ל.BSM 1. השלמת תוצרים, 2. טיוב: ניטורים, ספים, אינטגרציות, תהליכים, תיעוד, הדרכות 3. ד. ה. תכן התקנת תשתית ורכיבי המערכת שלב זה כולל התקנת השרתים ובסיסי הנתונים בחוות השרתים של הלקוח, הקמת ממשקים לתשתיות, הגדרת שטחי אחסון, הגדרת משתמשים, פתיחת Portים ב- FW עד למצב של מוכנות להתקנת רכיבי התוכנה, הגדרת גיבויים. התקנת רכיבי התוכנה של המערכת. הגדרת שרתי ניטור עבור שדרוג של כל חבילה וחבילה לשלב ההסבה/שדרוג) סביבת טסטים(. תכנון א. התכנון יבוצע בשלב ראשון ברמת על, ולאחר מכן באופן מפורט לכל סב התכנון יכלול, לפחות את הנושאים הבאים: תיאור ארכיטקטוני מפורט של המערכת. 1. תשתיות טכנולוגיות. 2. דרישות רשת, חומרה, תקשורת ואבטחת מידע. 3. פריסת המערכת בכללית. 4. פתרון לזמינות גבוהה, שרידות והמשכיות.IT 5. תיאור מסכי העבודה המרכזיים. 6. אופן ומהות ההתממשקות והסנכרון עם מערכות - ממשקים למערכות חיצוניות 7. יישומים ותשתיות ארגוניות, מערכות שו"ב וניהול אחרות. 1 1 1.2

ניהול משתמשים יחידים וקבוצות, ניהול פרופילים והרשאות, ניהול ובקרת גישה. יש לפרט מהם הלוגים והנתונים שניתן להפיק מידע רלוונטי לנושא זה. בדיקות תכנית בדיקות מפורטת כולל תיאור תרחישים ומדדים להצלחה. הבדיקות יכללו במידת הצורך בדיקת עומסים וביצועים..8.9 ביצוע מבחני מסירה וקבלה כולל איטרציות תיקונים מבחני המסירה והקבלה יבוצעו במשותף עם צוות הספק וצוות כללית במשותף. מבחני המסירה יתועדו בתיק בדיקות אשר יימסר ללקוח, הבדיקות יבוצעו על סמך תסריטים.)STP( מבחני הקבלה יתבצעו במקביל ככל שניתן, באחריות הכללית ובליווי מלא של הספק. נדרש לספק כ לסעיף זה נספח תכנון בדיקות קבלה מקוצר STD( עד שני עמודים(. במסגרת התכנון המפורט יכין הספק מסמך ביצוע בדיקות.)STP( מסמך הבדיקות יאושר ע"י הלקוח לפני הביצוע. הלקוח רשאי להוסיף בדיקות משלו מעבר לבדיקות המוצעות ע"י הספק. העברה לייצור לספק אחריות על העברת הפתרון הנדרש לעבודה בסביבת הייצור וסביבות נוספות בכללית על פי הנדרש. במסגרת שלב זה הספק יכין תכנית פעולה לכניסה לייצור במתווה של שלבי הפרויקט המתוארים. השלמת תיעוד, כתיבת נהלים והוראות עבודה התיעוד יכלול בין השאר תיעוד Reference Guide הכולל מפרט טכני, חומרי הדרכה ונהלים אותם הספק מציע לאמץ במסגרת הטמעת המוצר. ראה פירוט בסעיף 4.9. תקופת הרצה בייצור הספק ילווה ויסייע בהטמעת המערכת במשך עד 3 חודשים מיום העברה לייצור של כל חבילה. הליווי יכלול לכל הפחות חצי משרת מיישם באתר הלקוח, אשר יטייב מוניטורים, ניטורים ויסייע בהטעמת המערכת ב.NOC לוח זמנים למימוש א. ג. ד. ה. תכנית העבודה שתוגדר ע"י כ למפרט תתבסס על מסגרת הזמנים הבאה : הזמן הנקוב לסיום בשבועות הנו זמן מקסימום, רשאי להציע הקדמה של לוחות הזמנים, כל שינוי בלו"ז דורש אישור של המזמין. הצעה אשר ישכנע את המזמין שניתן באמצעותה להקדים את לוחות הזמנים המוצעים תקבל תעדוף של 1% מניקוד האיכות עבור כל שבוע של הקדמה. נדרש לתכנן את משאבי כוח האדם וסוגי המומחיות הנדרשים על מנת לעמוד בלו"ז. הלוז הנדרש הנו קלנדרי מיום תחילת הפרויקט, התאמות אחרונות יבוצעו עם הספק הזוכה. שיעור אבן דרך התשלום מתייחס למועד סיום השלב ואישור אבן הדרך על ידי נציגי הכללית ARO יום הודעה על זכייה לספק שלב סיום שלב אבני דרך 1.3 1 1 1.6 1 #

בשבועות לתשלום 23% שלב א' מערכת וונילה וממשקים בסיסיים, תכנון הפרויקט 23% ARO + 1 ARO + 2 ARO + 4 ARO + 4 ARO + 5 ARO + 6 ARO + 7 ARO + 8 תכנון תצורה וכתב כמויות, תכנון ארכיטקטורת על, הזמנת רישוי ותוכנה תוכנית עבודה תכנון ותסריטי בדיקות התקנת תשתית המערכת התקנת תוכנת MoM ברמת וונילה ממשק Active Directory קישוריות ברמת וונילה למערכות המנטרות מבחני מסירה וקבלה לשלב.2.3.4.5.6.7.8 23% שלב ב' - איסוף אירועים, בניית ממשק ל- DCM 23% 23% 20% 23% ARO + 12 ARO + 12 ARO + 12 ARO + 12 ARO + 14 ARO + 15 ARO + 16 ARO + 17 TBD ARO + 19 ARO + 20 ARO + 22 ARO + 23 ARO + 25 ARO + 24 ARO + 25 אינטגרציה והעברת אתראות ממערכות מנטרות מימוש ממשק DCM התקנת מערכת ניטור תשתיות קבלת ניטורים מציודים, הפעלת שרת SNMP ושרת TRAP מבחני מסירה וקבלה לשלב שלב ג' - ניתוח אירועים התאמות ובניית קסטומיזציה של קונסול מרכזי בנית מנגנון להפצת סוכני ניטור תשתיות, והפעלה על קבוצת ניסוי אינטגרציה של ניטור תשתיות ל- MoM אינטגרציה ל APM יסונכרן בהמשך בניית חוקים: קורלציה, אגריגציה, ניתובים מימוש מודול נוטיפיקציות מימוש של 2 תהליכי BSM מבחני מסירה וקבלה לשלב השלמות ומבחני אינטגרציה הדרכת NOC וצוותים מקצועיים מסירת תיעוד שלב ד' - כניסה הדרגתית לתפעול.9 0 1 2 3 4 5 6 7 8 9.20.21.22.23.24.25.26

23% 23% 23% ARO + 27 ARO + 30 ARO + 30 ARO + 40 העברה לייצור שלב ה' - השלמת משימות וטיוב מערכת מימוש של 3 תהליכי BSM נוספים השלמת תוצרים משלבים קודמים תקופת הרצה וטיוב מערכת.27.28.29.30.31 א. ג. ד. ה. ו. ז. ח. פיצוי מוסכם בגין אי עמידה בלו"ז פרויקט ההקמה הספק יידרש לשפות את המזמין במידה ופרויקט ההקמה לא יעמוד בלו"ז המוסכם וזאת באחריות ישירה של הספק לאי העמידה. בחינת עמידת הספק בלו"ז תתייחס לכל אבן דרך בנפרד. פיצוי לאי עמידה יופעל על חריגה של יותר משבועיים לאבן דרך, התשלום יבוצע בגין כל יחידות חריגה. יחידת חריגה לאי עמידה בלו"ז שבוע. ימים בודדים לא ייחשבו לצורך פיצוי מוסכם. תשלום בגין אי עמידה ביחידת חריגה. 7,500 לא יופעל פיצוי כפול. במידה והופעל פיצוי מוסכם באבן דרך והספק הצליח לקזז את הפיגור בלו"ז, יופעל קיזוז על הפיצוי המוסכם בהתאם. הסבר ודוגמאות:.2.3 שלב ב' יסתיים ב 30 + 16 :,ARO חל פיגור של 2 שבועות לאבן הדרך ולכן על פי סעיף ג' אין אירוע של פיצוי מוסכם. שלב ג' יסתיים ב : 26 +,ARO חל פיגור של 3 שבועות לאבן הדרך, לכן מתקיים אירוע של פיצוי מוסכם, על סך של. 30,000 שלב ד' יסתיים ב: + 29,ARO מאחר ואין פיצוי כפול. הזמן המיועד לסיום אבן הדרך צריך להיות,ARO+30 הספק קיזז שבוע מהפיגור בלו"ז, ולכן זכאי להחזר של 10,000 מהפיצוי המוסכם שהוטל עליו באבן דרך הקודמת. חלוקת אחריות סעיף זה מגדיר את חלוקת תחומי האחריות בין הכללית לבין הספק. יודגש בזאת כי הספק מתחייב לקחת אחריות כוללת על ביצוע הפרויקט ואספקת התוצרים כנדרש במפרט זה בתצורת.Turn Key Project מנהל הפרויקט מטעם הספק יידרש להתריע בפני מנהלת הפרויקט על עיכובים באספקת התוצרים הנובעים מאי עמידה בלוחות הזמנים לביצוע משימות של הספק ושל הכללית גם יחד. להלן הגדרות בסיסיות לחלוקת אחריות בין הספק ללקוח: כללית: 1 1.6

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

תחזוקת יצרן הספק מתחייב לרכוש בעבור הכללית תחזוקה עבור המוצרים אצל יצרן המערכת. נדרשת תמיכה למוצרי המערכת ולתוצרי הפתרון שיושם במסגרת הפרויקט, בימים א' עד ה' בין השעות 07:00 ל- 21:00. יש בנוסף לתמחר עלות להגדלת חלון התמיכה ל- 7*24. הסכם תחזוקת יצרן יכלול לפחות: א. ג. זכאות לקבלת גרסאות חדשות של מוצרים שנרכשו Patches( )Minor & Major, Security על לתאר מהי הפרוצדורה לעדכון. פתיחת פניות קבלת מקצועי. גישה חופשית וללא תשלום ל- Knowledge Base של היצרן דרך ה- Internet לטובת חיפוש פתרונות לבעיות. תחזוקת ספק על להתחייב לספק שירותים מקצועיים הבאים: שימור המערכת על ידי ביצוע התאמות נדרשות בעקבות שינוי תשתית וסביבה ייעוץ מומחה במתן פתרונות לבעיות ארכיטקטורה. תמיכה במתן פתרונות טכנולוגיים בבעיות שוטפות. תמיכה בעת ביצוע שדרוג גרסאות תוכנה. סיוע בשינויים ושיפורים שוטפים באמצעות השירותים המקצועיים של הספק. שירותים אלו יינתנו לצוות השו"ב של הכללית באתר הלקוח ע"י מומחים בעלי הסמכה מטעם היצרן. רמת הזמינות הנדרשת מהמערכת היא 99.9%. רמת הזמינות תימדד בתדירות רבעונית. השבתות מתוכננות לא יכללו במניין זמני ההשבתה. יתחייב על זמנים ודרכי התגובה לטיפול בתקלות במערכת במסגרת זמני התמיכה שלהלן: תחילת טיפול בתקלה תוך שעתיים לכל היותר מדיווח למרכז השירות. אבחון תקלה תוך 4 שעות לכל היותר מפנייה ראשונית של הכללית. טיפול בתקלה משביתה יבוצע ברצף, כולל מחוץ לשעות העבודה המקובלות, עד החזרה לשירות. הגעת גורם טכני מטעם הספק למתקן הכללית על פי דרישת ר"צ שו"ב בכללית. זמן ההגעה לא יעלה על 4 שעות ממועד קבלת הדרישה. פיצוי מסכם בגין אי עמידה ברמת שירות הספק יידרש לשפות את המזמין בגין אי עמידה ברמת השירות המוסכמת. 1.3 1.3.2 1.3.3

1.3.3 פיצוי מוסכם בגין אי עמודה במדד אבחון תקלה רמת שירות נדרשת 90% לתקופת מדידה של שנה. א. יחידת חריגה שעתיים. משכים קצרים יותר יושמטו. פיצוי מוסכם בגין יחידת חריגה. 1,000 ג. אבחון תקלה יימדד מזמן פתיחת כרטיס ( )Open ועד קבלת האבחון בכללית )ברמה של -e ד. Mail בפורמט מוסכם או בשיחה עם הגורם האחראי בכללית(. הסבר ודוגמאות: ה. בשנה נפתחו 10 כרטיסי תקלה, 9 מהם זמן אבחון התקלה היה פחות מ- 4 שעות, במקרה 1. זה אין אירוע של פיצוי מוסכם. בשנה נפתחו 10 כרטיסי תקלה, 3 מהם משך זמן לאיבחון תקלה היה 8:15 6:30, 4:40, 2. ולכן מתקיים אירוע של פיצוי 70% בהתאמה. במקרה זה רמת השירות בפועל הנה מוסכם. עבור תקלה שמשכה 4:40 אין צבירה של קנס, עבור אירוע שמשכו 6:30 יש חריגה ביחידת חריגה בודדת ובגינו חל פיצוי של, 1,000 עבור האירוע שמשכו 8:15, יש חריגה של 2 יחידות חריגה ובגינו חל פיצוי של. 2,000 סה"כ פיצוי מוסכם של. 3,000 א. ג. ד. ה. פיצוי מוסכם בגין אי עמודה במדד הגעה לאתר הכללית רמת שירות נדרשת 90% לתקופת מדידה של שנה. יחידת חריגה שעתיים. משכים קצרים יותר יושמטו. פיצוי מוסכם בגין יחידת חריגה. 2,000 הגעה לאתר כללית תימדד מזמן דרישת ר"צ שו"ב בכללית ועד ההגעה בפועל לאתר הכללית. הסבר ודוגמאות:.2 הדרכה בשנה נדרשו 5 דרישות להגעה לאתר, 4 מהם זמן ההגעה היה פחות מ- 4 שעות, במקרה זה אין אירוע של פיצוי מוסכם. בשנה נדרשו 5 דרישות להגעה לאתר, 3 מהם משך ההגעה היה 8:15 6:30, 4:40, בהתאמה. במקרה זה רמת השירות בפועל הנה 40% ולכן מתקיים אירוע של פיצוי מוסכם. עבור הגעה שמשכה 4:40 אין צבירה של קנס, עבור הגעה שנשמכה 6:30 יש חריגה ביחידת חריגה בודדת ובגינו חל פיצוי של, 3,000 עבור האירוע שמשכו 8:15, יש חריגה של 2 יחידות חריגה ובגינו חל פיצוי של. 6,000 סה"כ פיצוי מוסכם של. 9,000 הדרכה והטמעה בפונקצית NOC הספק יטמיע את מערכת ה- MoM להלן תכולת המשימות הנדרשות: בפונקצית ה- NOC של הכללית, בניית מסך עבודה מרכזי מותאם לבעלי התפקידים הבאים: בקר, אנאליסט, ראש משמרת, מנהל.NOC 1.3.3.2 1.3 1.3

שילוב תהליכי העבודה הקיימים בפונקציונאליות הקיימת במערכת: התאמות נדרשות לתהליכי פתיחת צירים, החלפת משמרת, טיוב ספים. טיוב המערכת ברמה של מניעת,False Alarms התאמת ספים, הפצת ניטורים לכלל הרכיבים. הדרכה פרונטאלית של קורס אשר יכלול את המרכיבים הבאים: תפעול מערכת ה MoM ברמת קונסול מרכזי טיפול באירוע לאורך מחזור החיים הפעלת כלי תיחקור וביצוע Drill Down הפקת דוחות טיפול בהתראות False-Positive הקורס יבוצע במתקן כללית ויכלול התנסות מעשית. היקף הקורס 15-20 שעות, 3-4 מפגשים..2.3.4 הדרכת צוותים מקצועיים הדרכת הצוותים תבוצע ב- 2 אופנים: 1.3.2 On The Job Training במהלך פרויקט ההקמה ובמשך תקופת ההרצה. קורס של מערכת ה MoM אופציה לקורס עבור מערכת ניטור התשתיות קורס מערכת ה- :MoM להלן נושאים אשר יש לכלול במסגרת הקורס: התקנה וארכיטקטורה רישוי ניהול משתמשים והרשאות קסטומיזציה אינטגרציה למערכות מנטרות הוספת ניטורים, חוקים, קורלציות ניהול מידע וידע הקורס יבוצע במתקן כללית ויכלול התנסות מעשית. היקף הקורס 15-20 שעות, 3-4 מפגשים. 1.3.2 אינדקס תיעוד הספק שייבחר יידרש להכין : א. תיעוד Reference Guide הכולל מפרט טכני ואופן שילוב המערכת בכללית. 1.9

חומרי הדרכה מתאימים לצוות ה-,NOC צוותים תשתיות מקצועיים, מנהלי באגף התשתיות. הספק יפרט את הנהלים אותם הוא מציע לאמץ במסגרת הטמעת המוצר. להלן מספר נהלי חובה אותם יידרש הספק להטמיע במסגרת פרויקט ההקמה: 1. נוהל התקנת המערכת בייצור וב- DRP. 2. נוהל גיבוי ושחזור מסדי הנתונים ומערכת הקבצים של המערכת. 3. נהלי תפעול וטיפול בתקלות Level 1 ותחזוקה של המוצר בסביבת הייצור וה- DRP. 4. נוהל שינוי גרסה, כולל העברה מסביבת עבודה אחת לשנייה. 5. נוהל מעבר ל- DRP וחזרה מה- DRP. ג. היפרדות א. ג. ד. ה. ו. ז. כללית רשאית להיפרד מההתקשרות מכל סיבה שהיא באופן מלא או חלקי: משירות בלבד או משירות ניטור תשתיות או מכלל השירותים. היפרדות אינה כרוכה בתשלום נוסף כלשהו מצד המזמין. היפרדות אינה כרוכה בהחזר תשלום כלשהו מצד הספק. על היפרדות מטעמי נוחות כללית תודיע לספק לפחות שלושה חודשים מראש. MoM היפרדות הנובעת מאי עמידה של הספק בהסכם תבוצע בהתאם ללו"ז שיוכתב על ידי הכללית. הסכמי תחזוקת יצרן יוסבו למזמין או לספק חלופי אחר. הספק ישלים משימות שו"שים שהיו בביצוע, אלא אם המזמין יחליט להפסיקן ולהעביר את המשימה לספק אחר. במקרה כזה הספק נדרש לשתף פעולה ולחפוף את הספק חדש בהשלמת המשימה. 13