OSS (Operation Support System)

Transcription

1 מפרט מספר: בקשה להגשת הצעות למערכת OSS (Operation Support System) מערכת אינטגרטיבית לניהול תשתיות התקשורת בחח"י בהתאם לארכיטקטורת etom 1

2 תוכן עניינים יעדים (I) 3... כללי (I)...3 לקוח/מומחהיישום (I)...3 יעדיםומטרות (G)...3 בעיות במצב הקיים (I)...4 השתלבות ביעדי הארגון - הקשר ארגוני \ עסקי (I)...4 תכנית עבודה שנתית (I)...4 ישימותועלות/תועלת (I)...4 אופק הזמן...5 יישום (S)...6 ארכיטקטורה כללית (I)...6 אופיומצב כללי של היישום (I)...7 תיחום חיצוני (I)...8 תיחום פנימי (I)...8 ממשק משתמש (S)...9 כלים (S) 9... מילון פריטי המידע (I)...21 דו"חותושאילתות (S) אבטחת מידע (S)...23 נפחים עומסים וביצועים (S)...26 ממשקים חיצוניים (S)...27 הציוד בתשתיות התקשורת (I)...31 טכנולוגיהותשתית (S) ארכיטקטורהותפיסה כללית (S)...32 חומרה מרכזית (S)...32 אחסוןנתונים מרכזי (S)...32 אמינותושרידות המערך (S)...32 וירטואליזציה (G)...33 מערכת ההפעלה (S)...33 בסיסינתונים (S)...33 כלים לפיתוח ותחזוקה (S)...33 תוכנות מדף (S)...34 כלי תפעול וייצור (S)...34 רשתות תקשורת ממודרות (S)...35 מחשב לקוח (S)...35 תקשורת (S)...35 מימוש (S) כללי הבהקים (I) גורמים מעורבים (S)...36 מימוש כולל ותכנית עבודה (S)...44 תפעול שוטף (S)...49 אינדקסותיעוד (I)...49 שירותותחזוקה (S)...50 השתלבות בארגון תיעוד הדרכה והטמעת המערכת (S)...54 חוסןואמינות בדיקות ואבטחת איכות (I)...56 זמינותושרידות (S) תצורות (S)...59 הערכת הפתרון (I)

3 לתשומת לבכם: (להנחיות המלאות לגבי אופן ההגשה- ראו סעיף בפרק המנהלי) את ההצעה יש להגיש בנוסף גם במדיה מגנטית.(CD) במידה ותהיה סתירה בין העותק המודפס ובין המדיה המגנטית, יגבר העותק המודפס. יש לצרף להצעה הטכנית (למענה לפרקים 2-4 במכרז) טבלה מסכמת למענה בקובץ אקסל במבנה שלהלן. המענה בטבלה המסכמת יהיה בנוסף למענה לכל אחד מסעיפי המכרז. מספר סעיף סוג מענה (אין מענה/מענה חלקי/ מענה מלא) תיאור המענה לסעיף יעדים (I) כללי (I) חברת חשמל מבקשת בזאת לקבל הצעות פתרון למערכת (Operation Support System) OSS - מערך אינטגרטיבי לתפעול שליטה ובקרה של תשתיות התקשורת של חח"י, בהתאם לארכיטקטורת.(TM Forum Business- Process Framework) etom הספק הזוכה יספק פתרון וכלים, יאפיין ויעצב את הפתרונות המבוקשים, יקים את המערכות, ידריך ויתעד את ההטמעה וייתן שירותי תמיכה ותחזוקה לקוח/מומחה יישום (I) הלקוח העיקרי הינו יחידת קשר ואלקטרוניקה ארצית. מפיקי התועלת המרכזיים והעיקריים מתהליך השיפור יהיו אגפי החברה, שאמורים לקבל שירותים, מנוהלים באופן מיטבי, כבסיס למילוי משימותיהם העסקיות והתפעוליות יעדים ומטרות (G) יעדים ג. ניהול מיטבי של תשתיות התקשורת שבאחריות יחידת קשר ואלקטרוניקה לשיפור היכולות של האגף בפרט ושל החברה בכלל. התייעלות בביצוע שליטה, בקרה, תפעול ותחזוקת תשתיות התקשורת והשירותים. שיפור השירותים הניתנים ע"י יחידת קשר ואלקטרוניקה באמצעות העלאת זמינותם ואמינות אספקתם לאורך זמן. 3

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

5 מטרות / תוצרים הניתנים להשגה הורדת משך זמן אי-אספקת שירות. הורדת משך זמן.Root Cause Analysis הורדת משך זמן יצירת.Trouble Ticket שיפור ביעילות תפעול לתהליכים של.Provisioning שיפור היעילות בתהליכי ניהול קונפיגורציה אופק הזמן לוחות זמנים הנדרשים לביצוע החלק המרכזי (פירוט בסעיף 4.2 מימוש כולל ותוכנית עבודה) - רבעון רביעי 2012 במסגרת המכרז קבלת מענים - רבעון ראשון 2013 התחלת יישום פתרון - מרבעון ראשון 2013 במשך כחצי שנה יישום צעד 1 - מרבעון שלישי 2013 במשך כחצי שנה יישום צעד 2 - מרבעון ראשון 2014 במשך כשנה יישום צעד הלו"ז המפורט לעיל הינו מתוכנן ומשוער בלבד, ועשוי להתעדכן בהתאם לשיקול דעתה הבלעדי של חברת החשמל ובהתחשב בשינויים הנובעים מפרסום מכרז פומבי בנוש מחזור חיים המערכת נדרשת לשרת את חברת החשמל לפחות 7 שנים מיום העברתה לייצור (בהתייחס ליישום צעד 3)

6 יישום (S) ארכיטקטורה כללית (I) נדרש פתרון המבוסס על כלים קיימים, בשלים ומוכחים לניהול, התומכים בתהליכי etom.(tm-forum Business Process Framework) כלים ליישום בחלק המרכזי: - Mediation & Discovery כלי גילוי, איסוף וקבלת נתונים ממערכות וציוד - Core Inventory בסיס נתונים מרכזי - In Plant Management ניהול גרפי של חדרי הקשר, ארונות התקשורת והציוד. Fault Management - ניהול אירועים ותקלות Provisioning ניהול תהליכי תכנון, שריון משאבים ושלבי היישום כלי ליישום בחלק האופציונאלי (החלטה לגביו תתקבל לאחר סיום החלק המרכזי): Performance Management ניהול ביצועים ובקרת איכות הרשת להלן מפורטים מספר הדגשים לפתרון הנדרש: ג. ד. ה. ו. המערך ישמש לניהול ארצי-אחיד של תשתיות התקשורת, בארכיטקטורה של שני מרכזים בגיבויי הדדי (לשרידות מלאה). המערכת תשמש כ- (MoM) Manager Of Managers ותספק פתרון ניהול אינטגרטיבי לכל מערכות הניהול והשו"ב של תשתיות התקשורת בהווה ובעתיד. באחריות הספק לגלות, לייבא, להקים, להטמיע ולהזין בכלי המערכת את כל הנתונים הדרושים (כגון: אתרים, קווים, רשתות, ציוד, טופולוגיה, עורקים, שירותים ולקוחות) כולל אחריות על איכותם. המערכת תהיה בעלת Core Inventory אחד לתמיכה בכל הכלים והתהליכים הנדרשים בפתרון. תינתן עדיפות לפתרון כולל ואחיד לכל מרכיבי המערכת ללא כלים נפרדים מיצרנים שונים. המערכת תהיה בעלת מבנה מודולארי שיאפשר הוספה של רכיבים להרחבת יכולות המערכת ללא השפעה על המערך. 6

7 (S) ז. ח. ט. י. י י המערכת המוצעת תידרש להתממשק למערכות על/חיצוניות (פרוט בסעיף 2.22). על המערכת להיות מבוססת על מוצר מדף ולא פיתוח. בהתאם לכך על המציע להצהיר כי המערכת כבר מפותחת במלואה ומוטמעת בחברות נוספות וכי לצורך מענה לדרישות מכרז זה נדרשות רק התאמות מינימאליות. המערכת תתמוך ב- Multi-Technology,Multi-Vendor ו-.Multi-Layer המערכת תתמוך במגוון הציוד והשירותים המנוהלים בחח"י, כולל תמיכה בטכנולוגיות מתקדמות ועתידיות. המערכת תתמוך בהרחבת תשתיות התקשורת, כמות הציוד המנוהל והשירותים עד פי 2 מהמצב הקיים בחח"י. המציע יידרש לביצוע הוכחת יכולת היישום (פירוט הדרישות בסעיף 4.11) אופי ומצב כללי של היישום (I) מצב קיים יחידת קשר ואלקטרוניקה ארצית מפעילה מגוון רחב של טכנולוגיות, מערכות, ציוד ושירותים בתחומים: סיבים אופטיים, תמסורת, תקשורת, בקרים ברשת החשמל, טלפוניה, אלחוט וכו'. תחום תשתיות התקשורת: תשתיות התקשורת מורכבות ממספר שכבות (פיזיות ולוגיות) וממגוון רחב של יצרנים, טכנולוגיות ופרוטוקולים. רשת התמסורת מספקת שירותים לכלל החברה ומהווה פלטפורמה לשירותים ניהוליים ותפעוליים. טכנולוגיות מרכזיות: סיבים אופטיים,,DWDM,FTTH.ETH,MPLS, PDH,SDH פועלים שני מרכזי תפעול שליטה ובקרה לרשת התמסורת (צפון, דרום). בקרים ברשת החשמל- רשת תפעולית לשליטה ובקרה מרחוק על מנתקים ברשת החשמל באמצעות בקרים מתוכנתים המותקנים על רשת חשמל. התקשורת בין יחידת הקצה (FTU) למרכז הבקרה מתבצע ע"י תקשורת סלולארית, קווית או קשר רדיו המופעל באמצעות רשת תחנות הבסיס. מכלול הבקרה כולל 2 יחידות עיקריות: מכשיר קשר או מודם ובקר מתוכנת. קיימים 5 סוגי מכשירי קשר עיקריים: RADIO DATA,SPECTRA,2000-MCS,,MAXTRAC.CDM-750 קיימים 5 סוגי בקרים עיקריים: ACE, MOSCAD ו- INTRAC (מתוצרת מוטורולה), MODICON (מתוצרת 200-S,(ABB (מתוצרת סימנס). סך הכל מותקנות כ יחידות קצה לבקרה על מנתקים. 7

8 פועלים שישה מרכזי תחזוקה - MC (Maintenance Center) לבקרה ותפעול של הבקרים ברשת החשמל, אחד בכל מחוז (במחוזות: דן, דרום, י"ם, ב"ש, צפון, חיפה). תשתיות התקשורת נמצאות תחת פיקוח הרשות לאבטחת מידע (רא"ם) תיחום חיצוני (I) משתמשי המערכת הלקוח העיקרי של המערכת הוא יחידת קשר ואלקטרוניקה ארצית. משתמשי המערכת העיקריים הם הנהלת היחידה, מחלקות התחזוקה והתכנון מערכות משיקות ראה סעיף תיחום פנימי (I) תיחום הפרויקט - חלק מרכזי אספקת מערכת OSS כפתרון ארצי לניהול תשתיות תקשורת. ביצוע אפיון ועיצוב להטמעת ה- OSS ומכלול הכלים הנ"ל. ביצוע אפיון ועיצוב לתשתית הנדרשת ליישום הפרויקט. אפיון וביצוע הסבות והזנות נתונים ממערכות קיימות. הטמעה של הכלים הנדרשים במערך ה-.OSS ביצוע אינטגרציה בין המערכת למערכת ה- BSM (Business Service Management) ולמערכות מידע ושו"ב משיקות. ביצוע בדיקות מסירה. ביצוע הדרכות והטמעות. תיעוד ונהלים. תמיכה ותחזוקה שוטפים למערך שיוקם. תיחום הפרויקט - חלק אופציונאלי לאחר סיום החלק המרכזי חח"י תחליט האם ואילו כלים ייושמו וישולבו בהמשך. יישום כל אחד מהכלים יכלול: ביצוע אפיון, הכנת תוכנית עבודה ליישום, הטמעת מערכת, בדיקות קבלה, הדרכה ותיעוד. 8

9 2.4. ממשק משתמש (S) כללי הנדסת אנוש - ממשק מערכת הניהול במענה לסעיף 2.4 על המציע לציין לגבי כל תת סעיף האם הדרישה כלולה בפתרון המוצע על ידו, תוך מתן פירוט והסבר לגבי אותו רכיב בפתרון נדרשת מערכת בעלת ממשק ניהול אחיד לכל חלקי הפתרון. במידה ונעשה חיבור בין מספר כלים/תהליכים, יש לוודא התאמתם לממשק ניהול אחיד, שימוש אחיד במינוחים ואפשרות מעבר לכל כלי מתוך הכלים. כמו כן, נדרשת אחידות במנגנונים רוחביים, כגון Sanity,WORKFLOW Check וכלי קסטומיזציה. על ממשק המשתמש לתמוך בשפה העברית, כולל תמיכה בטקסט עברי וטקסט משולב עברי אנגלי (הקלדה, הצגה, חיפוש וכו'). על ממשק המשתמש להיות ידידותי ונוח. על הפתרון להכיל מנגנון סיוע מקוון (Help) לתמיכה בכל הפעילויות המתבצעות ע"י משתמשי המערכת. נדרש ממשק,WEB לפחות לכלים שמשמשים כממשק משתמש. על ממשק המשתמש להיות מותאם לבעלי התפקידים השונים. הממשק נדרש להיות מותאם בהתאם לפרופיל התפקיד. למשל, בעל התפקיד יראה רק את המסכים הרלוונטיים לתחומי האחריות שלו. על השינויים בפרופילים להתבצע ע"י מנהלני המערכת של חח"י ללא צורך בתוכניתן או בסיוע הספק. המערכת תתמוך ב- Log-in\Sign on יחיד. גישה מרחוק למערכת תתאפשר באמצעות פרוטוקולים מאובטחים, כגון:.HTTPS,SSH כלים (S) במענה לסעיף 2.5 על המציע למלא את הטבלאות הבאות: טבלה א - הכלים הנדרשים למימוש התהליכים. טבלה ב - ריכוז המוצרים הנדרשים והמחייבים למימוש הפתרון. טבלה ג - ריכוז מוצרים נוספים שיכולים לסייע למימוש הפתרון אך אינם הכרחיים למימוש הפתרון טבלה ד - מענה לסעיפים רמת התאימות להדגשים בכל כלי 9

10 טבלה א - הרכיבים הנדרשים למימוש התהליכים שם הכלי שם המוצר/ים והגרסא שם המודול/ים במוצר תמיכה בטקסט בעברית ובשילוב אנגלית Mediation & Discovery Core Inventory In-Plant Management Fault Management Provisioning תהליכים אופציונאליים Performance Management טבלה ב - ריכוז המוצרים הנדרשים והמחייבים למימוש הפתרון הכולל שם המוצר וגרסא תאור המוצר ייעוד המוצר בפתרון תאימות ל- etom אופן הרישוי כמות רישיונות (עפ"י ההיקפים כמפורט בסעיף ( הערה לטבלאות ב' ו-ג': בעמודת אופן הרישוי יש להתייחס לאפשרויות כדוגמת רישיון צף,שמי, לפי שרתים, מעבדים וכו'. הרישוי יכלול אפשרות שימוש בסביבות נוספות בנוסף לסביבת הייצור. טבלה ג - ריכוז מוצרים נוספים שיכולים לסייע, אך אינם הכרחיים למימוש הפתרון שם המוצר וגרסא תאור המוצר ייעוד המוצר בפתרון אופן הרישוי כמות רישיונות (עפ"י ההיקפים כמפורט בסעיף (

11 טבלה ד - מענה לסעיפים רמת התאימות להדגשים בכל כלי מספר סעיף תאור הפתרון בקצרה מענה מלא האם נדרשת התאמה היקף מוערך לשעות עבודה (עפ"י עסוקים) להתאמות אין מענה הערות Mediation & Discovery הכלי יאפשר ייבוא וגילוי אוטומטי של נתוני הציוד, הטופולוגיה, העורקים והשירותים, ברשתות ממגוון יצרנים וטכנולוגיות. יאפשר התממשקות לציוד ומערכות הניהול של היצרנים השונים. יאפשר התממשקות לציוד ומערכות הניהול בטכנולוגיות השונות. יאפשר התממשקות מאובטחת למערכות ורשתות ממודרות CORBA יתמוך במגוון ממשקים סטנדרטיים כגון:,SNMP ו-.OSS/J יהיה מבוסס חוקים לביצוע פירוק, הרכבה, עריכה ואימות של המידע שנאסף, עם מנגנון. Reconciliation יאפשר למנהלני המערכת של חח"י לערוך, להוסיף ולמחוק חוקים ללא התערבות היצרן/ספק המערכת. יהיה בעל ממשק ליצירה ושליחה של פקודות לציוד ולמערכות השו"ב (באופן ידני ו/או מתוזמן אוטומטית). יהיה בעל GUI ליצירה, עדכון והטמעה של ממשקים. הפתרון המוצע יאפשר למשתמש מורשה להפסיק/לאתחל את מנגנון איסוף הנתונים מציוד/מערכת באופן פרטני. הפתרון המוצע יאפשר העברת נתונים לכלים השונים, בזמן אמת, על תקלות בתשתיות התקשורת Core Inventory בסיס נתונים מרכזי לניהול התצורה של כל מערך תשתיות התקשורת, הכולל: ציוד, רשתות, עורקים (פיזיים ולוגיים) שירותים ולקוחות

12 ניהול פרטי הרכיבים כגון: קטלוג (דגם,משפחה וכו'), זיהוי חד חד-ערכי, מיקום פיזי (אתר, קומה, חדר, ארון וכו'), שיוך לגורם מטפל, סטאטוס, נתוני הרכש (למשל: מחיר, תאריך אחריות ועוד) וקישור לחוזי תחזוקה. ניהול פרטני של הנתונים הטכנולוגיים של הציוד והכרטיסים כגון: דגם, גרסת חומרה ותוכנה, מספר סידורי, מיקום, כתובת,IP יצרן, ממשקים פיזיים, ממשקים לוגים,,Cross Connections עורקי טופולוגיה (פיזיים ולוגיים), שירותים (בכל הרמות, הטכנולוגיות והפרוטוקולים). תמיכה בהיררכיית מיקום הציוד (Location) עד לרמת המיקום בארון התקשורת בחדר. תמיכה בתצורת ציוד ברמת- Shelf/Card/slot/Port/Interface כולל הרחבה גמישה למאפיינים נוספים. תמיכה בממשקים פיזיים ולוגיים לציוד, כולל.Cross-Connects ניהול ניצולת של עורקי תמסורת וממשקים, מסוגים שונים, בציוד. תמיכה במגוון סוגי מגשרים ומחברים פיזיים בין הציודים. תמיכה ב- Sanity Check ברמת הציוד והמגשרים. תמיכה בטכנולוגיות Ethernet,MPLS,TDM,SDH,DWDM,FTTH וכו' כולל ההיררכיה, הקשרים וניהול השירותים אשר "רוכבים" על התשתיות הנ"ל מקצה לקצה. תמיכה בטכנולוגית MDLC לניהול תצורת רשת בקרים. תמיכה בקישור רדיו מבוסס תחנות בסיס.Store And Forward תמיכה בהגדרת נ.צ. (בפורמט "ישראל החדשה") לציוד המותקן בשטח. באחריות הספק להקים ממשק למערכת ה- GIS הקיימת בחח"י (מתוצרת (ESRI לצורך הצגת ציוד המוגדר עם נ"צ על גבי מפה גיאוגרפית. ניהול כלל השירותים מקצה לקצה והלקוחות Management).(Service ניהול הקשרים, הפיזיים והלוגיים, בין הרכיבים (כולל תמיכה בריבוי היררכיות) והקשרים לשירותים העסקיים והתשתיתיים. מידול, הצגה ומעקב אחר שירותים, מקצה לקצה, כולל כל הרכיבים בדרך (ברמת Indoor וברמת.(Outdoor תמיכה בניהול שירותי תמסורת בתצורות.Protection

13 הצגת טופולוגית הרשתות בצורה לוגית, פיזית וסכמתית. על המציע לפרט: ג. סוגי ה- Configuration Items (תבניות CI הכוללות מאפיינים ייחודיים) הקיימים OOB ב-.Core Inventory השיטה והתדירות לקבלת והתקנת סוגי CI חדשים שפותחו לאחר רכישת והטמעת הפתרון. מידת המורכבות והשקעה/ תלות במציע/ כלי קסטומיזציה להגדרת CI ייחודיים בחח"י. גילוי אוטומטי וייבוא רחב ככל האפשר, עבור ה-,Core Inventory של רכיבים וקשרים ביניהם. על המציע לפרט: ג. ד. ה. ו. ז. סוגי הרכיבים והקשרים שכלי הגילוי מסוגל לגלות.OOB השיטה והתדירות לעדכון כלי הגילוי בתבניות חדשות לאחר רכישת והטמעת הפתרון. מידת המורכבות וההשקעה/ תלות במציע/ כלי קסטומיזציה להגדרת תבניות זיהוי ייחודיות בחח"י. הצעה לתהליכי ייבוא וגילוי, עפ"י מתודולוגיית המציע /היצרן. תיאור המנגנון הקיים לטיפול ברכיבים חריגים בזמן הגילוי, (חריגים הינם רכיבים הקיימים בשטח ולא קיימים במצאי ולהפך). הערכת המציע לתדירות ומשך ביצוע תהליכי ייבוא וגילוי בחח"י, באופן קבוע, בהתאם למפרט הרכיבים הקיים. אפשרות ליצירת פרופילים מוגדרים וייעודיים לגילוי ואיסוף נתונים. בנוסף למפורט בסעיפים לעיל, על המציע להתייחס לטבלה בסעיף 2.23 ולפרט לגבי כל סוג ציוד: האם קיימות תבניות OOB או שנדרשת הקמה של תבניות ייעודיות. באחריות הספק להגדיר את כל התבניות הנדרשות בהתאם לטבלה הנ"ל ולהקים את התצורה המלאה של תשתיות התקשורת בהתאם למצב הקיים. נדרשת תמיכה בספריות לכל סוגי הציוד המפורט בסעיף 2.23 כולל גרסאות עתידיות (הספק יקיים שיתוף פעולה עם יצרני הציוד ויתעדכן בגרסאות חדשות). כלי ידידותי לעדכון ידני של רכיבי CI ב- Core Inventory שלא ניתנים לגילוי ולעדכון קשרים ועצי שירות. תצוגה גרפית ברורה של ה- - Core Inventory הרשתות, הציוד, הקשרים והשירותים. יכולת ניווט למעלה ולמטה מכל נקודה בהיררכיה

14 ניהול תצורה של ציוד קצה גנרי (ברמה בסיסית). ניהול רישיונות וגרסאות תוכנה (ברמה בסיסית). ניהול כתובות IP כולל VPN ID, VLAN ID וכו'. יכולת סימון גרפי ל- CI שיש עליו תקלה פתוחה (ידנית עם אופציה לאוטומטית). נדרש מנגנון Impact Analysis למעקב אחר הקשרים בין האתרים, הציוד, המעגלים, השירותים והלקוחות (כולל ה- SLA מולם) המושפעים מהתקלות. תמיכה של ה- Core Inventory וכלי היבוא והגילוי בריבוי רשתות פיזיות ווירטואליות, כולל תמיכה באבטחת מידע מרשתות ממודרות (פרוט בסעיף.(3.17 באחריות הספק להקים ממשק, דו-כיווני, בין ה- Core Inventory במערכת ה- OSS ל- CMDB המרכזי במערכת ה- BSM, שיאפשר: ג. ד. ניהול התצורה, השירותים, הציוד והנכסים במערכת ה- BSM יצוא נתוני טופולוגיה, עורקים, שירותים, ציוד ונכסים ל- BSM עדכון נתוני ה- Asset של ציוד תשתיות התקשורת (שמנוהל ב- OSS ) בין ה- BSM וה-.Core Inventory הליך מובנה לעדכון שינויים שבוצעו דרך כלי ה- Change.OSS ב- Provisioning וכלי ה- BSM המרכזי ב- Management In-Plant Management הכלי יספק יכולת מלאה להצגת השכבה הפיזית של הרשת, האקטיבית והפסיבית, בצורה גראפית. תמיכה בהצגה גרפית-היררכית של השכבה הפיזית של הרשת: ג. ד. ה. תצוגת אתר: תצוגה גרפית של האתר ממבט על ובו החדרים והקישורים הפיזיים ביניהם. תצוגת חדר: תצוגה גרפית של החדר במבט על ארונות התקשורת במבט מהחזית. ותצוגה גרפית של תצוגת ארון תקשורת: תצוגה גראפית של הארון, כולל תצוגה של הציוד האקטיבי והפסיבי לפי מיקומו וגודלו בארון. הכלי יתמוך בהצגה גרפית של הקשרים הפיזיים בין הרכיבים השונים. בבחירת ציוד ניתן יהיה לראות את מרכיביו הפיזיים, כולל הקישורים לציוד אחר והשירותים הקשורים אליו. 14

15 ו. בבחירת מחבר או מגשר עוברים בו. יש לראות להיכן הוא מקושר ואילו שירותים הכלי יאפשר Zoom-In / Zoom-Out מתצוגה מפורטת מאוד של המרכיבים עד לתצוגה מלאה של הרשת ולהיפך. תתאפשר הכנסה ועדכון נתונים למערכת באמצעות "ספריה" ובה שרטוטים גרפים של כל הציוד האקטיבי והפסיבי, כולל מודלים ומחברים (פירוט בסעיף 2.23) לצורך הקמה ועדכון של אתרים, ארונות וציוד. המשתמש יוכל לעדכן ולהוסיף רכיבים בספריה, באמצעות.GUI הכלי יאפשר להציג באופן גרפי, לשרטט, לתאר, לשנות ולאחסן במסד הנתונים את כל המידע על ציוד תשתיות התקשורת, כולל: ציוד, מחברים וחיבורים, ארונות תקשורת, חדרי תקשורת ואתרים. הכלי יאפשר לקשר או להפריד בין מרכיבי הרשת, כולל תמיכה ב- Sanity.Check הכלי יאפשר הצגת סטאטוס של רכיבים באופן גראפי (בהתאם להתראות המתקבלות מה-.(Core Inventory והסטאטוס מה- Fault Management ניתן יהיה לשרטט את התיעוד של הרשת ישירות על המפה כדי לאכלס את מסד הנתונים המרכזי כלי זה יהיה בעל ממשק דו-כיווני ל- וקבלת נתונים, בסינכרון אוטומטי.,Core Inventory לביצוע עדכונים Fault Management ניהול והצגה, בתצורה מרכזית, של התקלות והאירועים הקשורים לתשתיות התקשורת, בזמן אמת מבנה הודעות התקלה יכלול לפחות את השדות המוגדרים בתקן 733.X.ITU-T הפתרון לניהול התקלות יהיה תואם למודל.TMN התקלות יוצגו כמלל קריא, בצורה ברורה ובעלת משמעות (לא בתצורה של קוד). ניתן יהיה לתרגם/להמיר את המידע בשדות השונים המרכיבים את התקלה. התקלות יוצגו במבנה אחד-אחיד

16 כל תקלה תכלול, לפחות, את המידע הנ"ל: מס' זיהוי ייחודי, תאריך ושעה, שם ציוד, מאתר-לאתר, תיאור התקלה, חומרת התקלה, מרחב גיאוגרפי, גורם אפשרי. כל תקלה תציג את השירותים והלקוחות המושפעים, כולל אפשרות לתצוגה גרפית של השירות (מקצה לקצה) עם חיווי על האובייקט התקול. הכלי יאפשר ניטור של שירותים, מקצה לקצה, עפ"י הגדרה מראש, ותאפשר ניהול תקלות ואירועים לפי שייכותם לשירותים. כלי ה- Management Fault יאפשר יצוא של תקלות לצורך הצגה גרפית בכלים תומכים ובאובייקטים הרלוונטיים. הכלי יאפשר חיווי גרפי וקולי (Audio) על תקלות נכנסות, כמו כן נדרש ממשק לחיווי חיצוני על התראות. ג. ד. ה. הפתרון יכלול לפחות שני סוגים של מאגרי תקלות: Current Alarms מאגר של התקלות שקיימות באותו רגע נתון ברשת. מנהלי המערכת יוכלו להגדיר קריטריונים להופעה של תקלות במאגר נתונים זה. - History Alarms מאגר של תקלות שעברו למצב תקין.(Clear) מנהלי המערכת יוכלו להגדיר קריטריונים להופעה של תקלות במאגר נתונים זה. מנגנון ניהול התקלות יכלול, לפחות, את המאפיינים הבאים: מנגנון המציג מופע אחד של תקלה האוגד בתוכו מספר התראות החוזרות בפרק זמן קצוב Alarms).(Repeated יכולת לביצוע Clear או Acknowledge לתקלה. מנגנון Drill-Down להצגת מגוון הנתונים הקשורים לתקלה פרטנית (נתונים גולמיים, נתוני Core Inventory ועוד). יכולת לקבץ תקלות לפי מבנה של.Parent/Child Log פעילויות שביצעו המשתמשים, המשויכות לטיפול בתקלה. יכולת לקליטת כל ה- Current Alarms ממערכות השו"ב/הציוד בהליך (Re-Synchronization) ReSync שיבוצע בחיבור הראשוני בין המערכת לרשת ובכל חיבור חוזר לאחר הפסקת הקישורים. הכלי ינטר את הקישורים השונים למערכות השו"ב ולציוד ברשת, וידווח בהודעת תקלה על כשל בקישור (ובהודעה על סיום התקלה עם החזרת הקישור לשמישות). ממשק המשתמש יאפשר ביצוע פילטר/עריכה של תקלות, באופן גמיש, בהתאם לכל אחד מהשדות המרכיבים את התקלה

17 כל משתמש יוכל להגדיר תצורת צפייה אישית בתקלות. התצורה תוגדר תחת פרופיל המשתמש בלבד ולא על מאגר התקלות המרכזי. נדרשת אפשרות להגדרת תצוגה של תקלות (עפ"י: מבנה ארגוני, טכנולוגיות, רשתות, ציוד ושירותים) בהתאם לפרופיל ולתחומי הפעילות של המשתמשים. נדרש לאפשר להגדיר אובייקטים (רשת, ציוד, עורק, שירות) ו/או קבוצה של אובייקטים, ככאלה שתקלות שיתקבלו מהם יסוננו ולא יוצגו למשתמשים (למשל אובייקטים שיוגדרו בסטאטוס: בהקמה, בבדיקה וכו') הכלי יתייחס לתקלה בשירות מגובה (Protection) ברשת ה- SDH כתקלה המשפיעה על שרידות השירות אך לא פוגעת בתעבורה. נדרשת יכולת לספק למשתמש רשימת פעילויות אפשריות המוצעות לטיפול בתקלה. מנגנון ה- :Correlation ג. ד. ה. ו. ז. ח. ט. י. המנגנון יבצע Filtering והפחתה של תקלות מיותרות. תקלה המאגדת מספר תקלות (לאחר תהליך קורלציה) תסומן ותזוהה ככזו, כולל אפשרות Drill-Down לצפייה בתקלות המקוריות מהן היא נבעה. מנהלי המערכת יוכלו לקבוע/לערוך/לשנות את הפרמטרים המגדירים את אופן פעולת המנגנון. המנגנון ינתח ויאתר את סיבת השורש בתקלות - Cause Root.Analysis המנגנון ינתח את סיבת השורש בתקלות על בסיס הטופולוגיה והקונפיגורציה (הפיזית והלוגית) של הרשת. המנגנון יהיה מסוגל לנתח את סיבת השורש גם בתקלות אינטגרטיביות מרשתות וטכנולוגיות שונות ) Multi-Domain.(Alarms המנגנון יספק את רשימת השירותים שהושפעו/נפגעו (ה- Service (Impact מתקלת שורש. המנגנון יבצע Impact Analysis למעקב אחר הקשרים בין האתרים, הציוד, המעגלים, השירותים והלקוחות (כולל ה- SLA מולם) המושפעים מהתקלות. המנגנון יאפשר, למנהלי המערכת, יצירה/עריכה של חוקים (קורלציה, אגרגציה, פילטרים וכו') באמצעות.GUI המנגנון יכלול פונקצית Debugging ופונקצית סימולציה של התראות. 17

18 ה( חברת החשמל לישראל בע"מ הממשק בין כלי ה- Management Fault ל- Core Inventory יהיה דו- כיווני ויאפשר את הפעילויות הבאות: ג. ד. ה. קבלת נתוני קונפיגורציה של ציוד קבלת סטאטוס של הציוד (מופעל, מותקן, בבדיקה וכו') קבלת פירוט על העורקים בין הציוד לציודים אחרים. קבלת המידע וכל הנתונים הדרושים להעשרת התקלה, לביצוע קורלציה ולניתוח ה-.Service Impact יכולת העברת ה- Alarms Current של ציוד להצגה בניהול הקונפיגורציה. הכלי יאפשר העברה של תקלות סגורות לארכיון, לאחר תקופת זמן שתוגדר ע"י מנהלני המערכת. הכלי יאפשר הפקת ניתוחים סטטיסטיים מפורטים ודוחות לגבי תחום ניהול התקלות. באחריות הספק להקים ממשק, דו-כיווני, בין כלי ה- Fault Management במערכת ה- OSS לכלי לניהול תקריות אחיד וכלי ניהול בעיות במערכת ה- BSM, שיאפשר: ג. ד. ה. ביצוע אינטגרציה וקורלציה ב-,BSM עם האירועים ממערכות השו"ב של ה- IT, לצורך ניתוח ה- Root Cause Analysis וה- Impact Service השפעה על השירותים). פתיחה/סגירה של Trouble Ticket ב- BSM לאחר אינטגרציה וקורלציה של האירועים. פתיחת Trouble Ticket ו/או Problem ב- BSM עם כל נתוני ההעשרה (enrichment) הדרושים, כולל העורקים, השירותים והלקוחות שנפגעו. קישור בין תקלה ל- Trouble Ticket המתאים ולהיפך. סגירת תקלה ב- Fault Management מה-.BSM באחריות הספק להקים ממשק למערכת ה- GIS הקיימת לצורך חיווי והצגת תקלות (בציוד המוגדר עם נ"צ) על גבי מפה גיאוגרפית. באחריות הספק להקים ממשק למערכת שליחת הודעות חיצונית, לצורך שליחת הודעות SMS על אירועים (כולל ציוד, עורקים, שירותים ולקוחות שנפגעו) לצוותים המקצועיים, ללקוחות ולהנהלה. המערכת תתמוך בהתממשקות Interface) (North Bound למערכת OSS חיצונית לחח"י, לתמיכה בתהליכי ניהול תקלות בציוד, עורקים ושירותים (ממשק עתידי)

19 Provisioning הכלי יתמוך בתהליכי יישום ותפעול, תכנון בסיסי ושריון משאבים בתשתיות התקשורת (תהליכים מרכזיים: Network Provisioning,.(Service Provisioning הכלי יתמוך בהקמת בקשת שינוי עפ"י מקורות השינוי (בעיה, יזום, פרויקט, שינוי טכנולוגי, תקלה, שו"ש, שו"ב וכו') כולל תיאור השינוי ומאפיינים ייחודיים לכל סוג שינוי. תמיכה בתהליכי שינוי בתשתיות התקשורת Provisioning) (Network הכולל הוספה/גריעה/שינוי לציוד ברשת (אקטיבי/פאסיבי) דוגמאות מעשיות: 1. התקנת FDF בארון תקשורת וחיבורו לכבל אופטי 2. שילוב מרבב אופטי בשכבת.SDH תמיכה בתהליכי שינוי אספקת שירותים Provisioning) (Service הכולל הוספה/גריעה/שינוי לשירות המנצל את קיבול הרשת. לדוגמא: הקמת שירות תמסורת בפרוטוקול וברוחב פס מבוקש (100M.(E1,Ethernet הכלי יתמוך בניהול לוח זמנים לשינויים ועבודות. תמיכה ב- Workflow (מסלולי אישורים) עם אפשרות לשינויים ללא אישור (סטנדרטיים-מאושרים מראש) כולל תרשים גרפי של מסלול האישורים. השוואה אוטומטית בין שינויים שנתגלו ע"י כלי הגילוי לבין השינויים המאושרים, והפקת חריגים. ניהול עבודות הנובעות מתוך בקשת שינוי מאושרת, כולל יצירת פקודות עבודה לצוותים ומעקב ביצוע של שלבי היישום (תמיכה ב-.(Workflow תמיכה בתחזוקה מונעת ותחזוקה תקופתית. לדוגמא, הקמה אוטומטית של פקודת עבודה עם אפשרות לתזמון, באופן אוטומטי אחת לתקופה, עבור תחזוקה תקופתית. כלי ה- Provisioning יפעל באינטגרציה מלאה ועם ממשק דו-כיווני ל- Core Core כולל אפשרות שסגירת פקודת עבודה תעדכן את ה-,.Inventory Inventory בסיום הביצוע (עבור רכיבים שאינם ניתנים לגילוי אוטומטי)

20 באחריות הספק להקים ממשק דו-כיווני ואינטגרציה לכלי ה- Change Management המרכזי במערכת ה- BSM, לתמיכה בתהליכי ניהול שינויים אינטגרטיביים Performance Management (אופציונאלי) המערכת תספק כלי Performance Management כדי לאסוף נתונים, לנתח ולדווח על התנהגות ואפקטיביות הרשת והציוד בתשתיות התקשורת. מנגנון האיסוף יתמוך בפורמטים שונים של נתונים גולמיים אשר אותם יוכל לבנות מחדש בפורמט גנרי. הכלי ינטר ברציפות את התעבורה ברשת ויתריע על כל חריגה. ניתן יהיה להפסיק/לאתחל את פעולת הניטור של הכלי החל מרמת הציוד ועד לרמת מערכות השו" הכלי יתמוך בשימוש בנתונים סטטיסטיים מהציוד כמקור מידע. הכלי יאסוף נתוני Performance ממגוון רחב של מקורות, כגון: מערכות מידע ושו"ב וישירות מהציוד. הכלי ידווח על תקלה במידה ותהליך איסוף נתוני ביצועים יכשל. כל מונה יאגור נתונים וישמור אותם, בהתאם להגדרות משתמשי המערכת. כלי ה- Management Performance יהיה בעל GUI שיאפשר להגדיר ולנהל KPIS ו- KQIS המבוססים על הנתונים שנאספו. הכלי יתמוך בניתוח מגוון נתוני ה- Performance שנאספו. ה- Performance Management יספק כלי ניטור תעבורה שידגום את דפוסי התעבורה לגילוי ודיווח על תופעות חריגות (בהתאם לספי ביצועים שהוגדרו ב- KPIS ו-.(KQIS תמיכה במנגנון וממשקים לייבוא/ייצוא של נתונים, אירועים ודיווחים. תמיכה בהעברת התראות לכלי ה- Management Fault לצורך פתיחת תקלה. SDK גמיש לאינטגרציה פשוטה של נתוני Performance ממערכות חדשות ולביצוע שינויים ותוספות, כולל GUI לניהול ותמיכה. ניתוח ארוך טווח: יכולת ליצירת KPI/KQI ממספר מקורות מידע שונים. 20

21 ג. ד. יכולת ביצוע מניפולציות ויצירת דוחות בהתאם למאפיינים הבאים: - יצירת דוחות מתבניות קיימות. - ביצוע דוחות, באופן אוטומאטי, על בסיס תזמון שנקבע מראש. - שמירה ויצוא של דוחות בפורמטים סטנדרטיים. - יכולות נרחבות לעריכה וסינון. - ביצוע שאילתה, באופן יזום, דרך GUI ידידותי למשתמש. דוחות Performance (מכל הסוגים) יוכלו להיות מוצגים בתצורה טבלאית, בתצורה גרפית ובתצורה משולבת (טבלאית וגרפית) בהתאם לבחירת המשתמש. תצורת הגרף תהיה בהתאם להגדרת המשתמש. ניתן יהיה להציג את הנתונים במגוון תצורות (עמודות, עוגה וכו') ניתוח בזמן אמת Time) :(Real ג. ד. יכולת ניתוח של נתוני ביצועים ותעבורה, הקרובות ביותר שניתן, לזמן אמת. השוואת הנתונים שנאספו מול נתוני סף מוגדרים מראש (הניתנים לעריכה ושינוי). ניתן יהיה להגדיר נתוני סף עבור משימות ייעודיות, לפרקי זמן קצרים. כל חריגה מערכי הסף שהוגדרו תייצר ותייצא תקלה לכלי ה- Fault.Management (N) מילון פריטי המידע (I) מונח תיאור מערכת אינטגרטיבית לניהול שירותי אגף מערכות מידע ותקשוב בחח"י, בהתאם לתהליכי ITIL V3 מושג שבא לבדוק את טביעות הרגל של תוכנה במערכות המידע בזמן השימוש בהן מדדי ביצוע מרכזיים על פיהם אומד הארגון את רמת ביצועיו. מדדי איכות מרכזיים על פיהם אומד הארגון את איכות הנתונים (אמינות וזמינות השירותים) שהוא מספק. פריט תצורה שהוא חלק ממכלול (לדוגמה: ארון, ציוד תקשורת, מחבר אופטי בציוד וכו') BSM (Buisiness Service Management) FOOT PRINT KPI (Key Performance Indicators) KQI (key quality indicator) רכיב (Configuration CI Item) 21

22 מונח תיאור מודל המגדיר תצורת עבודה להשגת קישוריות מלאה ותקשורת בין מערכות ניהול ורשתות טלקום תקן של (International Telecommunication Union) ITU בנושא פונקציונאליות דיווח על תקלות Reporting) (Alarm ארכיטקטורה של TM Forum בתחום Buiseness Process Framework מודל TMN (Telecommunications Management Network) תקן X.733 ITU-T ארכיטקטורת etom 2.15.דו"חות ושאילתות (S) בסעיף זה נדרש המציע לענות בכל תת-סעיף האם המערכת כוללת את הרשום בתת הסעיף. המערכת תכלול מחולל דו"חות בעזרתו ניתן יהיה להפיק דו"חות שונים מכל הכלים בפתרון (נדרשת אינטגרציה מלאה עם כל הכלים) תמיכה בהפקת דוחות מכל הנתונים במערכת בפורמט CSV,HTML,PDF או דוחות גרפיים על פי בחירת המשתמש הפקת הדוחות תתאפשר בתצורה של: טבלה, גרף או משולבת (טבלה+גרף) קיום דוחות מובנים OOB באנגלית ובעברית הפקת הדוחות תתאפשר על פי כל אחד מהפרמטרים / השדות בכלי ה- Fault Management (כגון:זמן, חומרה, תיאור וכו') הפקת הדוחות תתאפשר על בסיס ממשק בציוד, ציוד, רשת, מרחב (צפון/דרום) או כל תשתית התקשורת. הפקת דוחות ייעודיים תתאפשר בצורה פשוטה וידידותית דרך.GUI אפשרות להקמת והצגת הדוחות דרך ממשק ה- WEB. הכלי יאפשר הצגת מספר אנליזות זה לצד זה. הכלי יאפשר הפקה של דוח מנתונים של עד שנה אחורה. הכלי יאפשר הפקת דוח על פי תזמון מראש ) דוח שיתבצע בתאריך מסוים עתידי). הכלי יאפשר למשתמש קביעת מיקום כל שדה, זיהויו ורוחבו. הכלי יאפשר הוספת שדות מחושבים לערכים מספריים. הכלי יאפשר ביצוע חיתוכי נתונים ומיונים בדו"ח

23 הפקת דוח תתאפשר ע"י בחירה משולבת של כל נתון המופיע ב- Inventory.Core הכלי יאפשר למשתמש לסמן ולהדגיש ערכים יוצאי דופן בדוחות. אפשרות הפקת דוחות ושאילתות מקוטלגים ומוכנים במבנה קבוע עם פרמטרים, לצרכי העבודה השוטפת בתפעול המערכת. DASHBOARDS לרמות ניהוליות שונות: הנהלה, מנהלנים, אחראי תחומים, אחראי שירותים. נדרשת גישה לבסיסי נתונים לצורך הפקת שאילתות/דוחות ייעודיים/ סטטיסטיקות בכל הכלים. ניתן יהיה לשמור/לאכסן/להדפיס/לייצא (בפורמטים סטנדרטיים) דוחות שבוצעו. דוחות מוכנים מראש יפתחו ע"י לחיצה על תפריט/"כפתור" יעודי, מובנה, במערכת. על המציע לפרט יכולות מימוש הדוחות: מחולל דוחות,,DASHBOARD דוחות מובנים. הדוחות הנדרשים יוגדרו במהלך האפיון. המציע יידרש להגדיר לפחות 10 דוחות ראשוניים באמצעות מחולל דוחות ותדפיסים מתוך המערכת לעבודה שוטפת,מעבר לדוחות המגיעים עם המערכת (N) אבטחת מידע (S) בסעיף זה מפורטות דרישות אבטחת המידע. על המציע להתחייב לקיים בקפידה את כל דרישות, הוראות ונהלי חח"י בהקשר של אבטחת מידע. במענה לסעיף זה על המציע לפרט את יכולות המערכת המוצעת והפונקציות הכלולות בה לפי הנדרש בסעיף זה בתחום אבטחת מידע, ובנוסף, יש לענות לפי ההנחיות הספציפיות ככל שהן קיימות בתתי הסעיפים שלהלן אבטחת כלי גילוי כלי הגילוי השונים מספקים מידע רב על מערך תשתיות התקשורת של הארגון וחושפים אותו לסיכוני אבטחת מידע. על המציע לפרט: ג. דרישת ההרשאות של כל מוצר להתקנתו ולפעילותו השוטפת. אמצעי אבטחת המידע הקיימים בהם למניעת פריצות לארגון. הפרוטוקולים השונים אשר בהם נעשה שימוש בין רכיבי הפתרון. 23

24 ד. ה. תמיכה בקישור לרשתות תקשורת שונות בעלות רמות אבטחה מגוונות. פתרון להעברת נתונים מאובטחת בין הפתרון המוצע (מערכת ה- OSS ) למערכת ה- BSM העתידית זיהוי המערכת נדרשת להכיל מנגנון של זיהוי משתמש. רצוי הזדהות אוטומטית עפ"י.Active Directory בנוסף, המערכת נדרשת להכיל כלים למניעת כניסה בלתי חוקית (כגון חידוש הזיהוי אחרי זמן מסוים של אי-פעילות, החלפה תדירה של סיסמאות במקרה ואין מנגנון הזדהות אוטומטי וכו'). מאגר המשתמשים - תינתן עדיפות לשימוש ב Directory Active (ניתן לשמור במערכת עצמה פרטים נוספים על המשתמש, פרופיל המשתמש והרשאותיו). פרוטוקול ההזדהות - - סיסמה לא תעבור בתקשורת בצורה גלויה. - לא ניתן יהיה לגשת למערכת ללא סיום שלב ההזדהות באופן תקין ה - Session ייסגר (או לחילופין המסך ינעל) לאחר Idle Time שיוגדר ע"י מנהלני המערכת Concurrent User תהיה יכולת להגביל את מספר הכניסות שיבוצעו בו זמנית באמצעות אותו קוד משתמש הרשאות - מידור הגישה למידע נדרש פרופיל למנהל/מנהלן המערכת אשר אחראי על תחזוקת המערכת, הגדרות, תפעול וכדומה. אפשרות לניהול ההרשאות עפ"י פרופילים של משתמשים. קביעת קבוצות (Groups) משתמשים בעלי הרשאות דומות. יכולת שיוך משתמש לקבוצה אחת או יותר. נדרש כלי שיאפשר טיפול במידור הגישה למידע: - לפי נושאי עבודה (כלים/מסכים) - לפי סוג הנתונים שהמשתמש רשאי לגשת אליו. - יש להבחין בין סוגי הפעולות השונות: קריאה, עדכון וכו'. - לפי האחריות המרחבית על התשתיות (צפון, דרום, י"ם וב"ש). - לפי פונקציונאליות: מידור פעילויות ייעודיות במערכת (למשל ברמת הכפתורים במסכים)

25 לכל Group ניתן להגדיר את ההרשאות הבאות: הגדרת המערכות המאופשרות עבור כל קבוצה. הגדרת האובייקטים המאופשרים בכל מערכת. הגדרת יכולות העדכון עבור כל אחד מהאובייקטים לכל קבוצה. הגדרת התפריטים המאופשרים. ניהול הרשאות ברמת ה- Inventory Core לצפייה ועדכון Audit בקרה - נדרש כי יבוצע חיווי על הפעולות המבוצעות במערכת, לצורך ביקורות בדיעבד של נתונים ומהלך היווצרותם. על המציע לפרט מהן יכולות החיווי במערכת. המערך יכלול מנגנון בדיקה עצמי אוטומטי שינטר את רמת התפקוד של הרכיבים השונים: תוכנה (כלי תוכנה, ממשקים ותהליכים) וחומרה (זיכרון, מעבד, דיסק קשיח וכו'). כל אירוע חריג ידווח לכלי ה- Fault.Management הקשחת המערכת הספק יקשיח את המערכת (השרתים, מערכות ההפעלה, וכלי התוכנה השונים) בהתאם להמלצות היצרן ודרישות חח"י. המערכת תאפשר התקנת אנטי-וירוס של McAfee (כולל (epo Agent על כל השרתים ותחנות העבודה הכלולים בפתרון מנגנון ויומן אבטחת מידע מנגנון אבטחת המידע של המערכת נדרש להיות נגיש אך ורק למשתמשים שישמשו כמנהלי האבטחה. כל פעולות המערכת מנהלני המערכת (כגון יצירת פרופילים ומתן הרשאות), יירשמו ביומן האבטחה של המערכת. קבצי יומני האבטחה לא יהיו ניתנים לשינוי ע"י גורם כלשהו. המערכת נדרשת להכיל מנגנון רישום מלא של כל הגישות והשינויים שבוצעו במערכת. כגון: כניסה / יציאה מהמערכת,(login/logoff) בקרה על כישלונות בגישה אל המערכת וסיבתה (שגיאה בסיסמא, משתמש חסום וכדומה)

26 המערכת תוודא כי לא בוצעו שינויים בהגדרות האבטחה ובקבצי ההגדרות שלה פעולות תמיכה המערכת נדרשת לכלול מנגנון שיתמוך בביצוע גיבויים ושחזורים בהתאם למדיניות אמ"ת. (N) נפחים עומסים וביצועים (S) המערכת המוצעת נדרשת להיות מסוגלת להתמודד עם ההיקפים, הנפחים, העומסים וזמני התגובה המפורטים בסעיף זה (במענה לסעיף זה על המציע לפרט את יכולות המערכת המוצעת לתמוך בנפחים, עומסים וביצועים נדרשים). היקפים ועומסים - אלפי פריטי קונפיגורציה פסיביים ואקטיביים בתשתיות התקשורת. - הציוד פרוס גיאוגרפית וארגונית במאות אתרי החברה. - מספר אירועים ביום: כ- 100,000 - מספר תקלות (שורש) ביום: כ מספר משימות הקמה, תפעול ותחזוקה (ברמת הרשת ו/או השירותים) ביום: כ נדרשת תמיכה בהגדרה ראשונית של מינימום 50 משתמשים מהסוגים הבאים: מנהלני המערכת (משתמשי על): 4 משתמשים עם סמכויות: 16 משתמשי קצה: 30 - יכולת לתמוך בהגדרה עתידית של מינימום 100 משתמשים מהסוגים הבאים: מנהלני המערכת (משתמשי על): 5 משתמשים עם סמכויות: 40 משתמשי קצה: 55 - נדרשת יכולת לתמוך בכל המשתמשים שמתחברים בו להגדרות). זמני תגובה זמנית למערכת (בהתאם המערכת נדרשת להיות מקוונת LINE) (ON באופייה ולכן זמן התגובה הוא כזה שהמשתמש הסביר יהיה שבע רצון ממנו. נדרשת תגובה מיידית (חלקי שניות) לפעולות של הקלדה וזמן תגובה של שנייה עד שתיים בעבודה שוטפת מול מסך (מרגע בקשת המסך ועד הופעתו, שמירה וכו'). לגבי שאילתות ודוחות נדרש זמן תגובה של עד 30 שניות (במקרה של שאילתות ודוחות כבדים). 26

27 עומסים וביצועים המציע יציין השפעת כלי הגילוי והממשקים, בזמן הפעלתם, על תשתיות התקשורת PRINT).(FOOT המציע יציין רכיבים נוספים בעלי השפעה על רמת העומסים והביצועים 2.22.ממשקים חיצוניים (S) כללי באחריות הספק להקים את הממשקים הדרושים מהמערכת המוצעת למערכות בפלטפורמות שונות. להלן רשימת הבהקים כלליים בנושא, בנוסף לפירוט רשימת הממשקים בסעיף : על המציע לפרט את היכולות ותצורת ההתממשקות של המערכת המוצעת למערכות חיצוניות. המערכת תתמוך בממשקים דו-כיווניים מול מערכות השו"ב הקיימות (פרוט בסעיף ). נדרשת תמיכה, לפחות, בהעברת סוגי התוכן הבאים: אירועים ותקלות נתוני תעבורה וביצועים לוגים ג. נתוני קונפיגורציה של הציוד, כולל רכיבים פיזיים ולוגיים ד. ה. נתוני טופולוגיה של רכיבי תשתיות התקשורת והקישורים ו. נתוני העורקים, השירותים והלקוחות. נדרשת התממשקות ואינטגרציה בין מערכת ה- OSS למערכת ה- BSM לתמיכה בתהליכים הנ"ל: ג. ד. ניהול התצורה, השירותים, הציוד והנכסים ב- BSM (פרוט בסעיף ( ניהול שינויים מרכזי ב- BSM (פרוט בסעיף ) ניהול תקריות מרכזי (דרך מנגנון קורלציה) ב- BSM כולל אינטגרציה ל- Service Impact Analysis (פרוט בסעיף.( המציע יפרט יכולות התממשקות ואינטגרציה לכלים המובילים בשוק תשתית האינטגרציה בחח"י להעברת מידע וקישור בין מערכות: 27

28 ג. ד. ה. ו. תשתית האינטגרציה בחח"י מבוססת על מוצרי IBM ממשפחת Websphere הרכיבים הם MQ ו- WBI (ברוקר) הטופולוגיה של תשתית האינטגרציה היא, Spoke & Hub כאשר Hub מרכזי הוא ברוקר בפיתוח המנשקים נדרש תיאום עם חח"י (מדור האינטגרציה) לצורך שימוש בסטנדרטיים הקיימים והנחיית אבטחת מידע יש לפרט מה ההשלכות של שימוש ב- MQ כרכיב קישור בין מערכת ה- OSS ל-.BSM תבחן האפשרות להתממשקות גם ב- Web Services (המציע נדרש לפרט את היכולות) נדרש קשר חד כיווני מרשתות ממודרות שתומך בהעברת נתונים בתווך מבוסס מוצרים כדוגמת.Waterfall על המציע לפרט תפיסת פתרון להתממשקות למערכות ברשתות תקשורת ממודרות (פרוט בסעיף 3.17). על המציע לפרט לגבי מערכת ניהול הממשקים: הגדרת ממשקים, מעקב אחרי הפעלתם וכו' רשימת הממשקים להלן רשימת המערכות שבאחריות הספק להקים עבורן ממשקים. לכל מערכת בטבלה מצוין פירוט הממשק הנתמך והיישום הנדרש. על המציע לפרט לכל ממשק: האם קיים ממשק מובנה/ נדרש פיתוח/ שימוש ב- API יכולת לביצוע הממשק ואופן ההתממשקות טכנולוגיה וצורת יישום ניסיון מימוש ממשקים אצל לקוחות אחרים כמות שעות העבודה הנדרשות עפ"י הערכת המציע (מפורטת לפי סוגי העיסוקים הנדרשים) 28

29 מס טבלת המערכות והממשקים הקיימים: שם המערכת יצרן תיאור כמות מערכות פועלות סוגי ממשקים / פרוטוקולים נתמכים היישום הנדרש ECI LightSoft 1 מערכת ניהול לשליטה 1) Corba 2 ממשק להעברת נתוני קונפיגורציה SNMP (ציוד, טופולוגיה, שירותים וכו') ובקרה על כל ציוד ECI (לתקלות) 2) ממשק להעברת אירועים ותקלות ברשת התמסורת Castle SNMPc 2 מערכת ניהול לשליטה 1) ODBC 3 ממשק להעברת נתוני ציוד מנוהל Rock ובקרה על ציוד בפרוטוקול ברשת ( 2 ממשק להעברת אירועים ותקלות SNMP JDSU ONMS 3 מערכת לניהול וניטור רשת 1) SNMP 2 ממשק להעברת נתוני תצורה (לתקלות) (אתרים, ציוד, קווים וכו') הסיבים האופטיים (בסיס ( 2 ממשק להעברת אירועים ותקלות נתונים- (Oracle Cisco Cisco 4 מערכת ניהול לציוד 1) - 2 Cisco ממשק להעברת נתוני קונפיגורציה (ציוד, טופולוגיה, שירותים וכו') Works 2) ממשק להעברת אירועים ותקלות 1) - 1 ממשק להעברת נתוני קונפיגורציה Juniper JunoSpace 5 מערכת ניהול לציוד Juniper (ציוד, טופולוגיה, שירותים וכו') ( 2 ממשק להעברת אירועים ותקלות הסבת נתונים - - ניהול מצאי ציוד באתרי Microsoft כלי Office 6 הקשר (בתוכנות: Visio, (Excel, PowerPoint הסבת נתונים - - קבצי CAD של תכנון אב - קבצי 7 ותכנון מפורט לאתרי קשר, חדרים וארונות תקשורת Medusa AutoCAD הסבת נתונים - 1 תוכנת Magic לניהול ותיעוד ציוד במערך הקשר חח"י ניהול הקשר 8 (בסיס נתונים- (Oracle McAfee epo 9 מערכת ניהול, הפצה וניטור 1) SNMP 2 ממשק להעברת נתוני ציוד מחשוב (לתקלות) מנוהל ברשת לאנטי-וירוס ורכיבי ( 2 ממשק להעברת אירועים ותקלות אבטחה ממשק ואינטגרציה ל- CMDB, - BSM 10 מערכת על לניהול כלל 1 Change Management ו- השירותים, הציוד והאירועים באמ"ת Trouble Ticket פרוט בסעיף Emations OSS חיצונית WIZCON 12 מערכת OSS אופציונאלית עתידית מערכת SCADA לשליטה ובקרה על בקרים מתוכנתים ברשת החשמל מערכתSCADA לשליטה ובקרה על בקרים מתוכנתים ברשת החשמל OPC 9 North Bound Interface לתמיכה בתהליכי ניהול תקלות בציוד, עורקים ושירותים ממשק להתראות ממערכת Alarm Module -WIZCON,OPC MQ,IEC104 6 AFCON AFCON PCIM - FMW PCIM - CMW מערכתSCADA לשליטה ובקרה על ציוד בפרוטוקול SNMP מערכת לניהול קונפיגורציה של ציוד תקשורת ברשת החשמל OPC SNMP IEC104,SQL 6 6 AFCON Config. Editor 15 ממשק להתראות Current Alarm של מערכת PCIM ממשק להתראות Current Alarm של מערכת PCIM 1) ממשק לטבלאות SQL המכילות נתוני קונפיגורציה של RTU וציוד(הכנסת הנתונים מתבצעת בחלקה לתוך ה- Editor (Configuration 2) כחלק מתהליך ניהול העבודה ישנם פרמטרים המוכנסים ל- Configuration,Editor נדרש עדכון של כלי ה- וה- Inventory Provisioning 29

30 מס שם המערכת יצרן תיאור כמות מערכות פועלות סוגי ממשקים / פרוטוקולים נתמכים היישום הנדרש מערכת מידע גיאוגרפית בהתאם 1) ArcGIS יקבל נתוני קונפיגורציה מה- Core Inventory 2) ArcGIS יציג תקלות שיועברו מה- Management Fault SQL 4 ESRI ArcGIS 16 OPC, SQL מערכת לשליחת התראות 15 מערכת SEIM/SOC ממשק להעברת תקלות ואירועים מה- Fault Management למערכת ה- UCME שתשלח הודעות SMS ממשק דו כיווני (להעברת אירועים ונתונים מציוד ומערכות שו"ב) למערכת SIEM/SOC מבוססת ArcSight 1 ControlS ee HP UCME ArcSight

31 2.23.הציוד בתשתיות התקשורת (I) טבלת הציוד שינוהל במערך ה- OSS (סוגים וכמויות): מס' שם הציוד יצרן תיאור כמות - - ECI RAD Cisco Juniper MRV ATI Fortinet - Gamatronic ABB /אפקון ציוד פסיבי ארונות תקשורת XDM-1000 XDM-100 BG-40 BG-30 BG-20 Megaplex, DXC 1700, 2800, 3400, 2950, 2960, 1300 MX-80 EX-3200 EX-2200 Opti-Switch 200, 400, 800 AR745 FortiGate 60, 80, 310 ציוד קצה גנרי PSM-1006, PSM Compact Micro 512,Power Box תיבות סעף אופטיות,(FDF) לוחות גישורים, מגשרים, תיבות חיבורים אופטיות (מופות), כבלים אופטיים. ארונות תקשורת לציוד אקטיבי / פסיבי ציוד תמסורת בטכנולוגית DWDM, SDH, MPLS מנוהל דרך מע' ניהול LightSoft ציוד ריבוב בטכנולוגית PDH מנוהל דרך מע' ניהול SNMPc מתגים ונתבים מנוהלים דרך מע' ניהול SNMPc, CiscoWorks מתגים ונתבים בטכנולוגית MPLS מנוהלים דרך מע' ניהול SNMPc, JunoSpace מתגים מנוהלים דרך מע' ניהול SNMPc נתבים מנוהלים דרך מע' ניהול SNMPc SNMPc מנוהלים דרך מע' FireWall שרתים, מתגים, ממירים וכו' מערכות כח DC מנוהלות דרך מע' ניהול SNMPc בקרים מתוכנתים, מנוהל ע" PCIM,WIZCON אלפים בקרים מתוכנתים, מנוהל ע" PCIM,WIZCON בקרים מתוכנתים בקרים מתוכנתים מודם רדיו מנוהל ע" PCIM,WIZCON מודם רדיו מנוהל ע" PCIM,WIZCON בקר מתוכנת, מנוהל ע" PCIM,WIZCON בקר מתוכנת, מנוהל ע" PCIM,WIZCON MOTOROLA Siemens Modicon MOTOROLA DATA RADIO MOTOROLA Unitronic Moscad INTRAC ACE GateWay S7 984 MCS2000 MacTrac CDM750 T96 SR ALR Fault Detector

32 טכנולוגיה ותשתית (S) ארכיטקטורה ותפיסה כללית (S) להלן מספר הדגשים לפתרון המוצע מבחינה טכנולוגית: ג. ד. ה. ו. ז. ח. ט. י. המציע יפרט באמצעות סכמה את ארכיטקטורת המערכת כולל רכיבי תוכנה וחומרה נדרשים תוך התחשבות בהיבטי High Availability,שרידות ומצבי אסון על בסיס שני אתרי NOC בחח"י. המערכת נדרשת לזמינות גבוהה 24 שעות במשך 7 ימים בשבוע. שדרוגי תוכנה Minor) (Major & לא ישפיעו על זמינות המערכת. עדיפות למערכת שתפעל בטכנולוגיית אינטרנט. עדיפות למערכת שתתמוך גם בטכנולוגית VMware (כאפשרות למימוש עתידי) נדרש ממשק משתמש גרפי וידידותי (GUI) המתאים לדפדפן explorer 8 ומעלה. נדרשים ממשקים למערכות בהתאם לסעיף נדרש מחולל דוחות, גרפים ושאילתות בהתאם לסעיף נדרשת עמידה בדרישות אבטחת מידע כפי שמופיע בסעיף 2.19 נדרשת תמיכה בעבודה בריבוי רשתות ממודרות כפי שמופיע בסעיף חומרה מרכזית (S) על המציע לפרט את השרתים שחח"י נדרשת לרכוש ואת הדרישות הבסיסיות מהחומרה באתרי חח"י, לכל אחד מהרכיבים בתשתית שבהצעתו. המענה לסעיף זה יכלול את מילוי הטבלה הבאה ופירוט של מידת התמיכה בוירטואליזציה CPU הרכיב כמות שרתים מערכת הפעלה כמות מעבדים זיכרון כרטיסי רשת דיסק 3.2. אחסון נתונים מרכזי (S) על המציע לפרט לגבי הפתרון המוצע לאחסון נתונים מרכזי אמינות ושרידות המערך (S) המערך יפעל בתצורת ניהול ארצית-בגיבוי הדדי, כאשר בכל NOC תותקן מערכת עם כל הרכיבים הדרושים לניהול ארצי-מלא, באופן עצמאי. המערכות יפעלו בארכיטקטורת.High Availability המציע יפרט לגבי אופן פעולת המנגנון המוצע

33 המערכות יהיו מסונכרנות אחת עם השנייה. המציע יפרט לגבי תהליך הסנכרון, הגיבוי והשחזור (אוטומטי וידני). כל אחת מהמערכות (שיותקנו ב- NOC צפון ודרום) תחובר לכל מערכות השו"ב, לרשתות ולציוד. המערכת תהיה זמינה 365 7X24, ימים בשנה, ברמה של 99.99%. במקרה של רכיב חומרה או תוכנה תקול, תבצע המערכת מעבר אוטומטי, שקוף למשתמשים, לרכיב תקין במערך. על המציע לפרט לגבי פתרון גיבוי לכלל רכיבי המערכת ובפרט ל- Inventory Core (מערך הגיבויים בחברה מבוסס על תוכנת גיבוי TSM של חברת.(IBM על המציע לפרט את תהליכי שחזור הנתונים במערכות המרכזיות בעת משבר (הן מהמערכת ב- NOC המקביל, ב- Availability,High והן מהגיבוי) (N) וירטואליזציה (G) על המציע להתייחס לתמיכה בטכנולוגית הוירטואליזציה במסגרת הצעתו. נדרשת תאימות לארכיטקטורה וירטואלית של חברת VMware (התשתית שנבחרה ליישום בחח"י) מערכת ההפעלה (S) על המציע לפרט את מערכות ההפעלה שבסביבתם יכולה המערכת לעבוד, ומהי מערכת ההפעלה שתיושם ע"י המציע בפתרון (נדרשת מערכת הפעלה סטנדרטית: (Linux,Windows 3.9. בסיסי נתונים (S) על המציע לפרט את בסיסי הנתונים שבסביבתם יכולה המערכת לעבוד, ומהו בסיס הנתונים המומלץ ע"י המציע ליישום (עדיפות לבסיס נתונים סטנדרטי:.(Oracle, SQL-Sever (N) כלים לפיתוח ותחזוקה (S) על המערכת להכיל כלים להמשך פיתוח והתאמה ע"י חח"י, ללא ירידה ברמת האחריות של המציע להמשך תמיכה. על המציע לפרט את כלי ההתאמה בפתרון והכלים לניהול המערכת. (N)

34 3.15. תוכנות מדף (S) תיאור תוכנת מדף (I): ג. (S) מוגדרת כתוכנה המיוצרת ונמכרת באופן שוטף ב- 4 השנים האחרונות, בעלת Roadmap לפיתוחים עתידיים בשלוש השנים הקרובות לפחות. התוכנה המוצעת במסגרת הפתרון תהיה בגרסה תקנית (לא גרסת "ביתא"). על תוכנת המדף להיות מלווה בתיעוד מקיף הכולל תאור פונקציונאלי של המערכת, מדריך למשתמש, מדריך פתרון בעיות והוראות לאחזקה שוטפת. (M) כל התוכנות המוצעות כפתרון במסגרת הצעה למכרז זה יהיו תוכנות מדף, כמפורט בסעיף לעיל. על המציע לפרט את רשימת מוצרי המדף הנכללים במענה לכל אחד מהכלים הנדרשים ואת כל ההתאמות הנדרשות. הפירוט יכלול: אילו תכונות אינן קיימות במערכת, מהן ההתאמות הנדרשות, זמן פיתוח והתחייבות לפיתוח. בטבלה להלן: תוכנה מוצעת (שם וגרסא) משמש את כלי: (להתאים לכלים המופיעים בפרק 2) תכונות קיימות (בהתאם לפרק 2) תכונות חסרות (בהתאם לפרק 2) הערכת זמן פיתוח להתאמה הנדרשת (S) על המציע להתחייב לתחזוקת כל גרסא רשמית שתותקן בחברת חשמל למשך 7 שנים מיום העברה לייצור כלי תפעול וייצור (S) הפתרון צריך להכיל כלים לתפעול וייצור. המציע ייפרט את הכלים המוצעים ויתייחס ל: כלים למפעיל ואחראי ייצור פתיחה / סגירה (העלאה / הורדה) של המערכת מעקב שוטף אחרי פעילות המערכת, כולל הודעות על אירועים חריגים גיבויים ושחזורים הרצת מהלכים תקופתיים: דיווחים סטטיסטיים וניקוי כלי שליטה ובקרה למנהל המערכת ניטור משתמשים פעילים ברגע נתון ניטור אבטחת המערכת 34

35 מ. חברת החשמל לישראל בע"מ משלוח הודעות מתפרצות מעקב ביצועים: כלי מדידה וניטור רשתות תקשורת ממודרות (S) חח"י מבצעת פעילות שוטפת להעמקת ההגנה על תשתיות קריטיות, הגנה על מידע ויישומים מתוקף רגולציה, בקרה על גישה למידע רגיש ועוד. במסגרת הפרויקט יידרש הספק להקים את מערכת ה- OSS ואת הקישורים בין המערכת לרשתות תקשורת ממודרות, בהתאם להגדרות אבטחת מידע (פרוט דרישות אבטחת מידע למערכת בסעיף 2.19). על המציע לפרט כיצד מערכת ה- OSS, בפתרון המוצע, מתממשקת לרשתות השונות (ולמערכות השו"ב המנהלות אותן) בצורה מאובטחת. נדרשת תמיכה לפחות בשתי תצורות גישה: קשר מאובטח לרשתות שונות בפרוטוקולים מאובטחים, כגון SSH ו- Https ותמיכה בתווך מבוסס Firewall קשר חד-כיווני מרשתות ממודרות (כדי למנוע מצב בו מערכת ה- OSS תחבר בין כל הרשתות) ותמיכה בתווך המבוסס על יכולות מוצרים כגון.WaterFall.1.2 המציע יציין פרויקטים (ואנשי קשר באותם פרויקטים) בהם ניתנו פתרונות בהתאם למענה לסעיף זה. חח"י,כבעלת תשתית אסטרטגית במדינת ישראל, מונחית על ידי הרשות הממלכתית לאבטחת מידע ובמסגרת זו יתכן ויועברו לספק הזוכה דרישות נוספות להגנה על תשתיות ויישומים. חשב לקוח (S) על המציע לפרט את עמדות הקצה עליהן יכולה המערכת לעבוד, כולל פירוט המאפיינים הנדרשים (מעבד, זיכרון, נפח אחסון וכו') תקשורת (S) על המציע לפרט את דרישות התקשורת להקמת מערך OSS ארצי בהתאם לפתרון המוצע (בתוך ה- NOC, בין ה- NOC הצפוני לדרומי, ובין מערך ה- OSS לבין מערכות השו"ב והרשתות השונות). 35

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

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