מילון מונחים

דוגמה לטקסט עם

דוגמת בועה

 

 

“עַל כֵּן קָרָא שְׁמָהּ בָּבֶל כִּי שָׁם בָּלַל ה’ שְׂפַת כָּל הָאָרֶץ”

– ספר בראשית, פרק י”א, פס’ ט’

אוגדן השירותים – Service Portfolio

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

אירוע – Event

שינוי בפריט תצורה בעל משמעות לניהול שירותי המחשוב. אירועים מסוג אזהרה (Warning) וחריגה (Exception) מנוטרים על ידי תשתית שו”ב (שליטה ובקרה) ומבוקרים על ידי מערכת ניהול אירועים. סוג שלישי של אירועים הם ליידוע בלבד (Information) והם לרוב נשמרים בטבלת לוגים לטובת תחקור אוחר. ניהול אירועים הוא חלק מתפעול השירות.

אמנת השירות – (Service Level Agreement (SLA

הסכם בין הארגון ספק שירות המחשוב (IT Service Provider) לבין לקוחותיו, בו מתחייב ספק השירות על יעדים כמותיים אודות ההיבטים השונים שניסח הלקוח במסגרת דרישות רמת השירות, לאחר שספק השירות בחן את עלויות אספקת השירות והסכים לגביהן עם הלקוח. אמנת השירות יוצרת תיאום ציפיות בין הלקוח לספק השירות אודות אופן אספקת ותפעול השירות. אמנת השירות מבוססת על קטלוג השירותים ויש לוודא את עדכניותה בכל שינוי שמבוצע בשירות או בפריטי תצורה המשפיעים עליו, וכן באופן תקופתי בפרקי זמן קבועים. אמנת השירות נתמכת על ידי הסכמי תמיכה וחוזים תומכים (Underpinning Contracts). ניהול רמת השירות הוא חלק מעיצוב השירות.

אנליסט – Analyst

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

בסיס הנתונים לניהול תצורה – (Configuration Management Database (CMDB

אוסף של טבלאות המכילות את המידע אודות פריטי התצורה (CIs) והקשרים ביניהם וכן ממשק משתמש לניהול. מודול זה הוא המרכזי מבין שלושת מרכיבי מערכת ניהול התצורה (CMS) והוא מהווה חלק בלתי נפרד ממנה.

בעיה – Problem

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

בקשת שינוי -(Request for Change (RFC

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

בקשת שירות – (Service Request (SR

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

גורם הצלחה קריטי – (Critical Success Factor (CSF

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

גורם מטפל – Responsible Person

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

גילוי – Discovery

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

דחיפות – Urgency

נתון המשקף את דחיפות הטיפול בתקלה הנובעת מההקשר העסקי שלה (לדוגמה: שגרה, פעילות מבצעית, חירום, תרגיל), ומשפיעה על קביעת עדיפות הטיפול בתקלה.

דרישות רמת השירות – (Service Level Requirements (SLR

דרישות הלקוח מרמת השירות. הדרישות מתייחסות לזמינות, קיבולת ורציפות השירות, לאבטחת המידע בשירות וערוצי התקשרות וזמני הטיפול בתקלות ובקשות שירות. דרישות רמת השירות מהוות בסיס לתמחור על ידי ספק השירות ולמשא ומתן שבסופו נחתמת אמנת השירות.

הודעה – Announcement

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

הסכמי תמיכה – (Operational Level Agreements (OLAs

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

הסלמה מקצועית – Functional Escalation

העברת קריאה מצוות ברמת תמיכה נמוכה יותר (למשל: Level 1) לצוות ברמת תמיכה גבוהה יותר (למשל: Level 2). מוקד השירות ומנהל התקלות אחראים להמשיך לעקוב אחר הטיפול בקריאה גם לאחר הסלמתה לצוותים ברמת תמיכה גבוהה יותר ולוודא כי היא נפתרת ביעד הזמן שהוגדר באמנת השירות.

הסלמה ניהולית – Hierarchical Escalation

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

ועדת השינויים – (Change Advisory Board (CAB

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

זמינות – Availability

מדד לחוויית המשתמש. הזמינות מחושבת כסך המרווחים שבין התקלות המערכתיות חלקי סך זמן הזמינות הנדרשת. הזמינות הנדרשת לכל שירות היא שונה, שכן ישנם שירותים שאמורים להיות זמינים 24/7, בעוד אחרים צריכים להיות זמינים בשעות העבודה בלבד, או בימים ושעות משתנים, במועדים המתוכננים מראש.

יחידה עסקית – Business Unit

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

יעד הזמן – (Service Level Target (SLT

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

ישות – Contact

יחידת בסיס לפעילות האנושית במערכת ניהול השירות (SMS). במערכת קיימים שני סוגים של ישויות: משתמש וצוות.

לוח מחוונים – Dashboard

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

לוח תוצאות – Scoreboard

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

לקוח – Customer

נציג של אחת היחידות העסקיות, כלפיו מחויב גוף מערכות המידע באמצעות אמנת השירות. לקוח יכול להיות משתמש יחיד או צוות ארגוני. קריאה שנפתחה על ידי משתמש יחיד מוגדרת כקריאה אישית בעוד שקריאה שנפתחה ע”י צוות ארגוני מוגדרת כקריאה צוותית.

מאגר התקלות הידועות – (Known Error Database (KEDB

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

מאמר ידע – (Knowledge Base Article (KBA

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

מדדי מפתח – (Key Performance Indicators (KPIs

מדדים עיקריים, שנועדו למדוד את השגתם של גורמי ההצלחה הקריטיים (CSFs) בכל תהליך. דוגמאות למדדים נפוצים: משך תקינות ממוצע (MTBF), משך תקלה ממוצע (MTRS), וזמינות. השימוש במדדים נעשה כחלק משיפור השירות המתמיד (CSI).

מוקד שירות הלקוחות – Service Desk

גוף מרכזי בשיטת ITIL, האחראי על מתן שירות ללקוחות, בעיקר באמצעות מענה לבקשות (RF) וניהול תקלות (IM). גוף זה מנהל את הפתרונות מקצה לקצה ואחראי כלפי הלקוח (Accountable) על הטיפול בכל קריאה שנפתחה לטיפולו. תפקוד ארגוני זה מוגדר כקו ראשון (Level 1), משום שהוא הראשון לטפל בתקלות שדווחו על ידי הלקוחות.

מנהל תקלות – Incident Manager

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

מסלולי טיפול – Handling Routes

בקריאות ניידות נקבע לכל קריאה מסלול טיפול: חופשי או מנוהל. תקלות מערכתיות בסביבת הייצור או בסביבת התרגיל מטופלות במסלול טיפול מנוהל, בעוד יתר הקריאות מטופלות במסלול טיפול חופשי. קריאות מנוהלות ייפתחו ישירות לטיפול מוקד השירות או מנהל התקלות (לצורך מיקוד ותעדוף) בעוד קריאות לא מנוהלות ייפתחו ישירות לצוות הטכני הרלוונטי (לפי נושא הפנייה ומיקומו של הלקוח). קריאות מנוהלות מועברות בין צוותים רק דרך מוקד השירות או מנהל התקלות, גם במקרה של העברה בין שני צוותים שתחת אותו המוקד. קריאות לא מנוהלות ניתן להעביר בין צוותים טכניים בחופשיות, לדוגמה: הסלמת תקלה ממוקד שירות הלקוחות (Level 1) לצוות הטכני המומחה (Level 2) ביחידה ארגונית אחרת.

מערכת ניהול האירועים – (Event Management System (EMS

מערכת לניהול אירועים המזוהים על ידי כלי ניטור אחד או יותר ומרוכזים למערכת ניהול מרכזית המשמשת “מנהל של המנהלים” (Manager of Managers). המערכת מאפשרת לניהול תפעול המחשוב לזהות אירועים מסוג אזהרה (Warning) וחריגה (Exception) ולהגיב במהירות.

מערכת ניהול הידע – (Service Knowledge Management System (SKMS

מערכת בה מנוהלים מאמרי הידע התומכים בשירות ומבוססת על מספר מאגרים.

מערכת ניהול השירות – (Service Management System (SMS

מערכת בה מנוהלים מענה לבקשות (RF), ניהול תקלות (IM), ניהול בעיות (PM) וניהול שינויים (CM). מערכת זו עשויה לכלול בתוכה או להתממשק למערכת ניהול תצורה (CMS) ולמערכת ניהול הידע (SKMS), לטובת ניהול נכסים תצורה (SACM) וניהול ידע (KM), בהתאמה. מערכת ניהול האירועים (EMS) גם היא עשויה להתממשק למערכת ניהול השירות, לטובת דיווח אוטומטי (חוק קבוע) או חצי-אוטומטי (בהתאם לשיקול דעת) של אירוע אשר זוהה כתקלה.

מערכת ניהול התצורה – (Configuration Management System (CMS

מערכת אשר מכילה את כל הקשרים בין פריטי התצורה בארגון. מערכת ניהול תצורה עשויה להתבסס על שלושה מרכיבים: גילוי אוטומטי (Discovery), בסיס הנתונים לניהול תצורה (CMDB), מיפוי וניהול שירותים עסקיים (BSM). לב המערכת הוא בסיס הנתונים לניהול תצורה שבו מתועד המידע אודות נכסי השירות ופריטי התצורה, כאשר הגילוי והמיפוי יכולים להתבצע באופן ידני/אוטומטי. המערכת מאפשרת הערכת השפעה (Impact Analysis) של פריטי תצורה על השירותים העסקיים במסגרת תכנון שינויים ועל וכן אבחון של סיבת שורש (Root Cause Analysis) מרמת השירות העסקי ועד לפריטי התצורה במסגרת חקירת תקלות ובעיות.

מרכז תפעול רשתי – (Network Operation Center (NOC

ראה ניהול תפעול המחשוב.

משימה – Workflow Task / Work Order

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

משך תקינות ממוצע – (Mean Time between Failures (MTBF

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

משך תקלה ממוצע – (Mean Time to Restore Service (MTRS

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

משך תקלה ממוצע – (Mean Time to Repair (MTTR

ראה משך תקלה ממוצע (MTRS).

משתמש – User

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

נוהל תמיכה (Standard Operating Procedure (SOP

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

ניהול היישומים – Application Management

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

ניהול התשתיות – Technical Management

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

ניהול שירותים עסקיים – (Business Service Management (BSM

מודול המזהה את קשרי התצורה בין פריטי התצורה לבין השירותים העסקיים. הוא לרוב נרכש בנפרד, ומאפשר לבצע הערכת השפעה (Impact Analysis) של פריטי תצורה על השירותים העסקיים מלמטה למעלה (Bottom-Up) וכן אבחון סיבת שורש (Root Cause Analysis) מרמת השירות העסקי ועד לפריטי התצורה התומכים בו מלמעלה למטה (Top-Down).

ניהול תפעול המחשוב – IT Operations Management

גוף מרכזי בשיטת ITIL, האחראי על ניהול ותחזוקת הליבה של המערכות והתשתיות התומכות בשירותים העסקיים. מדובר בחדר בקרה מרכזי שתפקידיו העיקריים הם ניהול אירועים וניהול תקלות. גוף זה נקרא לעתים מרכז תפעול רשתי (Network Operation Center; NOC) והוא מוגדר כקו ראשון (Level 1), משום שהוא הראשון לטפל בתקלות שזוהו על ידי מערכת ניטור.

נכסי שירות – Service Assets

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

נספח – Attachment

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

סיבת שורש – Root Cause

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

סיווגים ומשפחות – Classes & Class Families

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

עדיפות – Priority

נתון לקביעת סדר הטיפול בתקלות, הנקבע לפי הדחיפות ולפי רמת ההשפעה של התקלה.

פורטל קטלוג השירותים – Service Catalog Portal

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

פריטי תצורה – Configuration Items

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

צוות – Group

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

צוות טכני – Technical Group

צוות הנמנה על ספק שירות המחשוב (IT Service Provider) בעל יכולת לטפל בבקשות שירות, בקשות שינוי, תקלות ו/או בעיות. הצוותים הטכניים נחלקים לשלוש רמות תמיכה.

צוות לקוחות – Customer Group

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

צוות מוקד טכני – Control Group

ראה מנהל תקלות.

צוות מטפל – Responsible Group

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

צוות מנהל – Accountable Group

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

קטלוג השירותים – Service Catalog

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

קריאה – Ticket

הגדרה כללית המתייחסת לכל בקשת שינוי, בקשת שירות, תקלה או בעיה המתועדות במערכת ניהול השירות (SMS).

קריאות ניידות ונייחות – Movable & Non-Movable Tickets

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

רמת השפעה – Impact

נתון המשקף את היקף ההשפעה העסקית של תקלה או שינוי. רמת ההשפעה משקללת את כמות המשתמשים המושפעת ואת חשיבותם.

רמת סיכון – Risk

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

רמת תמיכה – Level / Tier

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

שאלה נפוצה – (Frequently Asked Question (FAQ

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

שינוי חירום – Emergency Change

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

שינוי סטנדרטי – Standard Change

שינוי תדיר בעל רמת השפעה נמוכה (ועל כן בעל רמת סיכון נמוכה). שינויים סטנדרטיים מנוהלים לרוב כבקשות שירות.

שינוי רגיל – Normal Change

שינוי המבוצע בליבת המערכת, שהינו לרוב ייחודי, מורכב ונדיר, בעל רמת השפעה גבוהה. לשינויים רגילים לרוב רמת סיכון גבוהה וביצועם דורש אישור של ועדת השינויים (CAB).

שירות – Service

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

שירות טכני – Technical Service

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

שירות עסקי – Business Service

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

תהליך עסקי – Business Process

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

תפקוד עסקי חיוני – (Vital Business Function (VBF

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

תקלה – Incident

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

תקלה ידועה – Known Error

סוג מאמר ידע הקשור לשירות ומופיע במסך פרטי השירות בממשק האנליסט. התקלות הידועות מופיעות גם בלשונית ניהול ידע במסך פרטי הקריאה של תקלות ובעיות. תכליתן של תקלות ידועות היא להנחות את הגורמים המטפלים לגבי אופן הטיפול בתקלות ובעיות שקיים עבורן פתרון ידוע או מעקף (Workaround).

תקלה מבצעית – Operational Incident

תקלה שהסביבה של המיקום של פריט התצורה שלה הוגדרה כמבצעית (לדוגמה: תקלה ברכיב Outlook.Exchange תהיה מבצעית בעוד תקלה ברכיב Outlook.Client לא תהיה מבצעית).

תקלה מערכתית – High-Impact Incident

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

תקלת שבר – Major Incident

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