-1-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

ITIL │ ספר המתכונים

ITILאסופת מאמרים בנושא הטמעת

דורה שנייההמ

1026 מאי

'רוברט דן ינוביץ

ITILיועץ

-2-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

תוכן עניינים

3 הקדמה

4 מבוא

9 אנשים

44 תהליכים

15 אסטרטגיית השירות

18 עיצוב השירות

23 העברת השירות לייצור

25 תפעול השירות

35 שיפור השירות המתמיד

37 טכנולוגיה

46 מילון מונחים

-3-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

הקדמה

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

, שפותחה על ידי ממשלת ITILהאחרונות לעליית קרנה של שיטת כתוצאה מכך, אנו עדים בשנים .20-של המאה ה 80-בריטניה עוד בשנות ה

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

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

ITIL.

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

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

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

פרקים: חמישההמאמרים מקובצים ל

את העקרונות המרכזיים של שיטת , הכולל מבואITIL ותולדותיה ובו מפורטים השלבים

;( והתהליכים בכל שלבService Life-Cycleבמחזור חיי השירות )

ישום הנוגעים להיבטים ארגוניים של י, הכולל מאמרים אנשיםITIL;

,הכולל מאמרים הנוגעים להיבטים מתודולוגיים של יישום תהליכיםITIL;

,הכולל מאמרים הנוגעים להיבטים טכנולוגיים של יישום טכנולוגיהITIL;

הגדרה של מושגים בשיטת , הכולל מילון מונחיםITIL.

אני תקווה שהספר יהיה לכם לעזר רב.

רוברט דן ינוביץ'

ITILיועץ

-4-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

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

קיסר צרפת, נפוליאון בונפרטה -

-5-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

לדבר בשפה של הלקוח -( ITSMניהול שירותי מחשוב ) .2

Information Technology) המידע מערכות של התשתיות ספריית או ITIL שיטת

Infrastructure Library )יש כיצד הנחיות של אוסף זהו .מידע מערכות שירותי לניהול שיטה היא

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

היבט מתאר מהם אחד שכל כרכים 5 ישנם - ITIL 2011 גרסת - הנוכחית בגרסה .עסקים לעשות

ITIL שיטת (.IT Service Management) המידע רכותמע שירותי ניהול של החיים במחזור אחר

במערכות השירות ניהול תהליכי את שמגדיר לאומי-ןהבי התקן שהוא ISO 20000 בתקן תומכת

.ITIL המלצות את אימץ שארגון מוכיחה התקן בדרישות עמידה. מידע

. (Best Practiceמוצלח ) מצטבר ניסיון על מבוססתמערכות מידע ה לניהול שיטה היא ITIL שיטת המטרות בין לגשר שנועדו ורשימות משימות, עבודה נהלי, עבודה תהליכי מגדירה שיטהה

על המומלצת העבודה שיטת. המידע מערכות אגף של העבודה לשיטת הארגון של האסטרטגיות

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

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

.ITIL של פורום משתמשים מעין שהוא

ויותזכ. הבריטית (Axelosאקסלוס ) חברת של רשום מסחרי סימן הוא ITIL התיבות ראשי

(Cabinet Officeמשרד הקבינט )מ 1/1/2014-ב הועברו שיטהה והפצת בפיתוח והטיפול היוצרים

.(Axelos) אקסלוס לחברת( הבריטי המסחר משרד - OGC לשעבר) הבריטי

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

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

אספקת בשרשרת אחר תהליך מתאר אחד כל, ספרים של כאוסף 80-ה שנות בסוף לראשונה

-Plan-Do-Checkהשיפור ) מחזור בסיס על נבנתה ITIL שיטת(. ITSM) המידע מערכות שירותי

Act; PDCA) דמינג אדוארד של הניהול ועקרונות.

:ITIL ספרי של גרסאות ארבע פורסמו היום עד

גרסת ITIL V1.0 (1989) ספרים 47 הכילהש.

גרסת ITIL V2.0 (1996) ספרים 8 הכילהש.

רסתג ITIL V3.0 (2007) ספרים 5 הכילהש.

גרסת ITIL 2011 (2011) ספרים 5 הכילהש.

" הממשלתיות מערכות המידע תשתיות ניהול שיטת" בשם ,GITIMM-כ 1986-ב פורסמה השיטה

(Government Information Technology Infrastructure Management Method ,)במטרה .מחשב מתקלות הנגרמים הנזקים ואת, המחשוב ערכותמ של התפעול עלויות את להקטין

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

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

ITIL של הספרים. (IT Infrastructure Library)" למערכות מידע תשתיתה ספריית"ל השם שונה

V1.0 1986-89 השנים הלךבמ אחד-אחד יצאו אלא, אחת בבת פורסמו לא.

-6-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

. ההדרכה למשתתפי ההסמכה מבחני שכללו, ITIL של הראשונות ההדרכות החלו 1994 בשנת, הרב החומר היקף, השיטה מורכבות. הראשונות בשנים למדי זעום היה יטההש אימוץ היקף

לראשונה הוקמה 1996 בשנת. החומר" עיכול"ל פעולה שיתוף חייבו הבריטית השפה וכבדות

" שירותי מערכות המידע ניהולל פורוםה" או, itSMF שנקראה הראשונה המשתמשים עמותת

(The IT Service Management Forum) .כאשר, ובהולנד תחילה בבריטניה הוקם ורוםהפ .שיטהה בהפצת יותר פעיל היה ההולנדי הסניף

. ITIL V2.0: שיטהל שנייה גרסה itSMF פורום חברי של ובהשתתפותם בעידודם יצאה 1996 בשנת ליישם שמסייעת בצורה וערוכה, קולחת בשפה כתובה, בלבד ספרים 8: מצומצמת הייתה 2 גרסה

של המומלצת הניהול שיטת את לאמץ החלו בעולם ארגונים אלפי עשרות. גוניםבאר השיטה את

ITIL. מערכות ניהול שירות של גלובליים ספקים (Service Management Systems) ייצרל החלו

ר שלה בשם מוצשה 2003-בכבר הכריזה, לדוגמה, BMC חברת. ITIL-ל שהותאמו גרסאות

Remedy על שמבוסס מערכות מידע לניהול כלי הוא ITIL .האחרות הניהול תוכנות ספקי גם (CA,

IBM, HP )שיטהל שלהם הכלים את התאימו.

ןשה הסמכה ולקבל לבחון לחברות אפשר הוא ולראשונה, ISO 20000 תקן פורסם 2005 בשנת

הייתה ITIL V3.0 וגרסת, נוסף ריענון השיטה עברה 2007 בשנת .ITIL לתהליכי בהתאמה ותפועל .מתמיד לשיפור בשיטות מערכות המידע את שממקדים ספרים 5: מהפכני שינוי

הארגונים כל כמעט כיום (.30/6/2011-ב) ITIL 2011: האחרונה הגרסה פורסמה 2011 בשנת (.מהארגונים 90%-כ) שיטהה של אחד תהליך לפחות מאמצים המערבי בעולם

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

(Service Strategyאסטרטגיית השירות ) .1

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

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

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

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

:כי אסטרטגיית השירותיתהל

ניהול האסטרטגיה לשירותי מחשוב (Strategy Management for IT Services)

ניהול ( כלכלי לשירותי מחשובFinancial Management for IT Services)

השירותים אוגדן ניהול (Service Portfolio Management)

הדרישות ניהול (Demand Management)

הקש ניהול( רים עם העסקBusiness Relationship Management)

מאמרים בנושא אסטרטגיית השירות:

?מהו שירות

?איפה הכסף

-7-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

(Service Design) השירות עיצוב .3

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

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

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

תהליכי עיצוב השירות:

העיצוב תיאום (Design Coordination)

השירותים קטלוגניהול (Service Catalog Management)

השירות רמת ניהול (Service Level Management)

ספקים ניהול (Supplier Management)

הזמינות ניהול (Availability Management)

הקיבולת ניהול (Capacity Management)

השירות רציפות ניהול (IT Services Continuity Management)

המידע אבטחת ניהול (Information Security Management)

מאמרים בנושא עיצוב השירות:

קטלוג השירותים ואוגדן השירותים

אמנת השירות

ניהול ספקים

(Service Transition) לייצור השירות העברת .4

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

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

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

תהליכי העברת השירות לייצור:

ותמיכה בהעברה לייצור תכנון (Transition Planning and Support)

שינויים ניהול (Change Management)

נכסים ותצורה ניהול (Service Assets and Configuration Management)

פריסה וההתקנהה ניהול (Release and Deployment Management)

השירות בדיקת (Service Validation and Testing)

הערכת השינוי (Change Evaluation)

ידע ניהול (Knowledge Management)

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

נכסי שירות ופריטי תצורה

ם בתכנון שינוייםניניהול סיכו

-8-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

(Service Operation) השירות תפעול .5

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

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

.ושקופה מקצועית בצורה ינוהל מחשובה ותפעול, למידע גישה

תהליכי תפעול השירות:

מענה לבקשות (Request Fulfillment)

אירועים ניהול (Event Management)

תקלות ניהול (Incident Management)

בעיות ניהול (Problem Management)

רשאותה ניהול (Access Management)

מאמרים בנושא תפעול השירות:

ההבדלים את מצא - ובעיה תקלה, אירוע

לחיסכון בזמן םיטיפ

תעדוף תקלות

?למה זה חונה אצלי

?ציר ישיר או ציר מנוהל

תהליכי אורך, רוחב ועומק

את ארבעת התפקודים הארגוניים בגוף המחשוב:בנוסף, מגדיר כרך זה

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

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

ניהול היישומים (Application Management)

ניהול התשתיות (Technical Management)

מאמרים בנושא תפקודים ארגוניים:

התפקודים הארגוניים לפי שיטתITIL

רמות התמיכה

?ביזור או ריכוז

שגרות ניהוליות

(Continual Service Improvement) המתמיד השירות שיפור .6

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

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

.(The 7 Steps Improvementשיפור בשבעה שלבים ) תהליך אחד:שלב זה כולל , ITILשיטת

מאמרים בנושא שיפור השירות המתמיד:

מדדי המפתח

עניין של פרספקטיבה -מדידה

-9-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

באמצעות כלי נשק, אבל מי שמנצח בה הם תיכול להיות שהמלחמה מתנהל"

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

גנרל ג'ורג' פטון, צבא ארצות הברית -

-10-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

ITILודים הארגוניים לפי שיטת התפק .7

:ITILכנגד ארבעה תפקודים ארגוניים דיבר

מוקד שירות הלקוחות (Service Desk )- שיטת גוף מרכזי בITIL האחראי על שירות ,

תקלות( וניהול Request Fulfillment) בקשותללקוחות, בעיקר באמצעות מענה ל

(Incident Management גוף זה מנהל את הפתרונות מקצה לקצה ואחראי כלפי .)

פולו. תפקוד ארגוני ( שנפתחה לטיTicket) קריאה( על הטיפול בכל Accountableהלקוח )

.לקוחותווחו הי(, משום שהוא הראשון לטפל בתקלות שדLevel 1זה מוגדר כקו ראשון )

המחשובתפעול ניהול (IT Operations Management) - גוף מרכזי בשיטתITIL ,הליבה של המערכות והתשתיות התומכות בשירותים חזוקתתהאחראי על ניהול ו

Event) אירועיםהעסקיים. מדובר בחדר בקרה מרכזי שתפקידיו העיקריים הם ניהול

Management תקלות( וניהול (Incident Management גוף זה נקרא לעתים .) מרכז

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

ניהול היישומים (Application Management) - היישומים, הגוף האחראי על פיתוח

Business) שירות עסקי( התומך בTechnical Service) שירות טכניכאשר כל יישום הוא

Service יםכולל צוותים המוגדר( אחד או יותר. גוף זה ( כקו שניLevel 2 וקו שלישי )

(Level 3משום שהוא מקבל ,) לטיפולו תקלות שלא נפתרו בקו הראשון והועברו אליו

(.Functional Escalation) הסלמה מקצועיתב

ניהול התשתיות (Technical Management) - הגוף האחראי על פיתוח תשתיות

שירות עסקי( התומך בTechnical Service) שירות טכניהמחשוב, כאשר כל תשתית היא

(Business Serviceאחד או יותר. גוף זה כולל צוותים המוגדר )ים ( כקו שניLevel 2 וקו )

ראשון והועברו (, משום שהוא מקבל לטיפולו תקלות שלא נפתרו בקו הLevel 3שלישי )

(.Functional Escalation) מקצועיתהסלמה אליו ב

התרשים להלן מדגים את חלוקת העבודה בין ארבעת התפקודים:

-11-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

רמות התמיכה .8

רמות וח האדם הטכנולוגי בארגון להוא חלוקת כ ITIL שיטתאחד העקרונות הבסיסיים ביותר ב

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

פעילות המחקר והפיתוח מייצרת את מירב הערך עבור הארגון; .1

יות ההעסקה בין צוותי מחקר ופיתוח לצוותי תמיכה ושירות לקוחות.יש פער גדול בעלו .2

חלוקת הצוותים לרמות התמיכה מסייעת לקדם שתי מטרות:

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

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

נהוג לחלק את הצוותים הטכנולוגיים לשלוש רמות תמיכה:

( תפעול בסיסיLevel 1 )- ותקוחשירות ל צוותי (Service Desk ) מרכזי תפעול או

המנטרים את מערכות ותשתיות הארגון. ( Network Operation Center; NOC) רשתיים

(IT Operations Management) מחשובתפעול ניהול מקובל כי הצוותים העוסקים בשעות ביממה. לכל אחד מצוותים אלו עשרים וארבע מאוישיםיהיו תקלות מערכתיותומת הכשרה בסיסית, המאפשרת לו לתחזק כמות גדולה של מערכות או תשתית, מתוך ר

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

הראשון.

( תפעול מתקדםLevel 2 )- ם אלו בעלי רמת מומחיות גבוהה יותר, וכל אחד מהם צוותימתמחה במספר מצומצם יחסית של מערכות או תשתיות. תפקידם לפתור את כל

התקלות שלא נפתרו בצוותי התפעול הבסיסי.

( מחקר ופיתוחLevel 3 )- צוותים אלו הם בעלי המומחיות הגדולה ביותר ותפקידםו ערך לארגון בעתיד. הם לרוב אמונים על מערכת לפתח את היכולות והשירותים שיניב

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

(, Operational Level Agreements; OLAs) הסכמי תמיכהמומלץ לנסח הם מפורטת חלוקת האחריות והסמכויות בין רמות התמיכה ב

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

מהתקלות שהופנו אליה, ולהעביר 80%אמורה לפתור לפחות .20%-הלאה לא יותר מ

כך מתקבלת הפירמידה הבאה:

-12-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

ביזור או ריכוז? .9

ניהול ( ו/או גוף Service Desk) מוקד שירותמערך תמיכה המורכב מארגונים רבים מחזיקים

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

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

שיקולים בעד ריכוז

Incident) תקלות ניהולשויים שלא לנצל את כל זמנם לטכנאים המוקצים לאתר אחד בלבד, ע

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

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

וקטנים אחד על חשבון השני.

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

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

קיימת תחלופה גבוהה של טכנאים.

שיקולים בעד ביזור

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

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

.מידיר באופן שצריכות להיפת

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

שגרות ניהוליות .20

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

. מומלץ לקיים פגישות (Continual Service Improvement) מתמידהשירות הר ופישאת לקדםאלו בתדירות שבין אחת לחודש לאחת לרבעון. בארגון המוכוון שירות, מומלץ להקדיש כל מפגש

ניהם מכנה משותף. בישיבה מומלץ לסקור לשירות אחד או לקבוצה קטנה של שירותים, שיש בי

, ולבחון את המצב הנתון בהשוואה ITILשיטת שהוגדרו לכל תהליך מרכזי ב (KPIs) מדדי מפתח

.(SLA) אמנת השירותליעדים שהוגדרו ב

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

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

-13-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

בהזדמנות זו אבקש להדגיש את ההבדלים שבין שני סוגי תצוגה של מדדים:

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

Service Management) מערכת ניהול השירותהמחוונים לרוב הוא חלק בלתי נפרד מ

System.ואינו כולל יעדי ביצוע )

לו( ח תוצאותScoreboard )- קריאותהמחושבים על נתוני עבר ) מדדיםאוסף של שיפור השירות המתמידסגורות( ומציגים מגמות לאורך זמן לטובת קבלת החלטות ו

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

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

למצב הרצוי.

-14-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

מידע ומפעיל את בהצוותים והמפקדות שבאמצעותם המפקד המודרני שוא"

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

ארצות הבריתגנרל דווייט אייזנהאואר, צבא -

-15-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

(Service Strategyאסטרטגיית השירות )

מהו שירות? .22 (Strategy Management for IT Servicesניהול אסטרטגיה לשירותי מחשוב )

, אני מסביר שזו פרקטיקה לניהול השירות בעולם ITILשיטת כאשר שואלים אותי על מהות

(, למרות שלדעתי במידה רבה ניתן ליישם את עקרונות השיטה גם ITSMהמידע )מערכות

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

אסטרטגיית שונים של מחזור חיי השירות: בהיבטיםעוסקים ITIL שיטת חמשת הכרכים של

Service) העברת השירות לייצור(, Service Design) עיצוב השירות(, Service Strategy) השירות

Transition ,)תפעול השירות (Service Operationו )שיפור השירות המתמיד (Continual

Service Improvementכל ההיבטים של השיטה (. העובדה שמושג השירות שזור כחוט השני ב

( IT Service Providerובכל תהליכיה, נעוץ ברצון ליצור תיאום ציפיות בין גוף מערכות המידע ) לבין הלקוח.

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

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

במושג זה נגלה שקיימים שלושה סוגים של שירות:

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

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

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

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

אחרות.

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

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

ותשתיות שונות הפועלות מאחורי הקלעים ואינן גלויות למשתמש.

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

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

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

.תומך בתהליך עסקי אחד או יותר

-16-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

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

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

Strategyשוב )שהוא מציע. החלטה זו מתבצעת במסגרת תהליך ניהול אסטרטגי לשירותי המח

Management for IT Services םלתת בהקשר זה היא פשוט להתייעץ ע(. העצה הכי טובה שניתן הלקוחות. הגדרה של מושג השירות בארגון שלכם תלויה בעיקר באופן בו הלקוחות תופסים את מושג השירות. לדוגמה: אם הבנקאית מבחינה ומבדילה בין "שירות משכנתאות" לבין "שירות

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

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

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

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

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

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

( Service Mappingלהגדיר את כל היישום כשירות אחד. הסיבה לך נעוצה בכך שמיפוי שירותים )

של ( אליו גולש המשתמש, כך שאם הגישה URL( מבוסס על הנתיב )Top-Downמלמעלה למטה )בצעת לפי כתובת אחת, מערכת מיפוי השירותים תזהה תעמדת הקצה לליבת המערכת מתבצעת מ

היישום כשירות אחד. את

?איפה הכסף .21 (Financial Management for IT Servicesלשירותי מחשוב ) כלכליניהול

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

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

תקציב מערכות מידע(IT Budget)

(Business Servicesסקיים )שירותים ע שירות ג' שירות ב' שירות א'

יחידות עסקיות(Business Units)

יחידה עסקית א' יחידה עסקית ב' יחידה עסקית ג'

-17-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

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

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

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

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

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

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

התצורה עבורו הוא משולם, ואת משך הזמן שעליו יש לפרוס את ההוצאה. בנוסף, ניתן

(. בהתאם לחוזים CapEx( תפעול או מחקר ופיתוח )OpExבהוצאות ) וברדלהגדיר האם מ

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

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

( ניהול נכסים ותצורהService Asset & Configuration Management )- באמצעותתהליך זה, מנוהלים הקשרים בין כל פריטי התצורה אחד לשני והאופן שבו הם משפיעים על השירות. על סמך קשרי התצורה ניתן לפזר את העלויות של פריטי התצורה השונים

על השירותים העסקיים לפי מפתחות העמסה.

( ניהול קטלוג השירותיםService Catalog Management )- מצעות תהליך זה, באאניתן לפזר את העלויות של השירותים העסקיים השונים על פני התהליכים העסקיים

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

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

להציג אותה גם בצורה גרפית בחתכים שונים.

-18-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

(Service Designהשירות ) עיצוב

קטלוג השירותים ואוגדן השירותים .23 (Service Portfolio Management(, ניהול אוגדן השירותים )Service Catalog Managementניהול קטלוג השירותים )

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

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

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

( הינו חלק Service Catalog Managementניהול קטלוג השירותים )

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

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

(Service Portfolio .)השירותים אוגדןול ניה (Service Portfolio

Management) אסטרטגיית השירותהוא אחד התהליכים החשובים ב

(Service Strategy).ולרוב מבוצע על ידי גורמי הניהול הבכירים ,

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

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

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

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

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

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

פריטי התצורהממופים כל (Service Asset & Configuration Management) תצורהנכסים ו

(Configuration Items המרכיבים את ) פריט תצורהמערכות ותשתיות הארגון לשירותים )כל

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

, ניתן לחשב מדדים שונים אודות כל (Configuration Management System) ניהול התצורה

( למנהלים. מדידת טיב Score Board) תוצאותלוח ת( ולהציג אותם בשירות )למשל: זמינו

.שגרות ניהוליותומבוצע לרוב באמצעות (CSI) המתמידהשירות שיפור השירות היא חלק מ

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

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

שלהן מוטלת בספק.

-19-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

אמנת השירות .24 (Service Level Managementהשירות ) מתרניהול

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

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

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

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

הקשורות לשירות (Incidents) תקלותאו (Service Requests) שירות בקשותהמענה הניתן למסמך זה אינו רק בגדר עשוי להשתנות משירות לשירות ומלקוח ללקוח. במילים אחרות,

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

משאבי הארגון.

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

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

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

או על בסיס תקנים ונורמות המקובלים בשוק.

Service Levelאמנות שירות נעשה במסגרת תהליך ניהול רמת השירות )יצירה ועדכון של

Managementעיצוב השירות(, שהינו חלק מ (Service Design .) מומלץ כי אמנת השירות תהיה מורכבת משלושה חלקים עיקריים:

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

השירות.

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

שעות פעילות השירות.

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

בקשה/תקלה )לפי סוג המשתמש, לפי סוג התקלה(, ערוצי תקשורת לנותני השירות.

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

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

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

כדי לעמוד ביעדי אמנת השירות משתמש הארגון בשני כלים:

הסכמי תמיכה (Operational Level Agreements) - אלו הסכמים בין הצוותיםברמות התמיכה השונות, הקובעים באילו מקרים יש להעביר כל סוג קריאה בין צוותים,

-20-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

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

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

(OLAs( נעשה במסגרת תהליך ניהול רמת השירות )Service Level Management ,)

(.Service Design) עיצוב השירותשהינו חלק מ

( חוזים תומכיםUnderpinning Contracts )- במקרים רבים, מסתייע גוף מערכותהמידע בספקי משנה, ועליו להגדיר מולם חוזים תומכים, שיהיו בהלימה לאמנת

ירות יצירה ועדכון של אמנות ש השירות, כדי להתחייב על זמני יעד שניתן לעמוד בהם.

עיצוב (, שהינו חלק מSupplier Management) ניהול הספקיםנעשה במסגרת תהליך

(.Service Design) השירות

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

( Service Level Requirementsשל הלקוח ) דרישות רמת השירותומתן בו מתחשבים גם בוביכולת ספק השירות לעמוד בהתחייבויותיו, בהתבסס על הסכמי התמיכה והחוזים התומכים.

כם את הגורמים המשפיעים על עיצוב אמנת השירות:תרשים זה מס

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

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

מהשירותים 10% –פלטינה

מהשירותים 20% –זהב

מהשירותים 30% –כסף

מהשירותים 40% –ארד

( יוגדרו בכל אמנת שירות לכל אחת מהעדיפויות Service Level Target) יעדי הזמןמומלץ כי

. בנוסף, (Problems) בעיותו (Incidents) תקלותבנפרד, והדבר ישמש להגדרת זמני יעד לטיפול ב

( Task Workflow) משימותניתן להגדיר בנפרד זמני יעד למשימות המרכיבות את תזרים ה

, אשר יתווסף ליעד (Change Requests) בקשות שינויו (Service requests) בקשות שירותב הזמן הכללי בטיפול בבקשות שירות/שינוי.

-21-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

:עיותוב ת זמני היעד בתקלותהתרשים הבא מדגים את עיקרון הגדר

שינוי:ובקשות התרשים הבא מדגים את עיקרון הגדרת זמני היעד בבקשות שירות

ניהול ספקים .25 (Supplier Management) ספקיםניהול

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

(.Service Design) עיצוב השירותזה הינו חלק מ תהליך

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

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

Contract) ומנהל החוזים (Supplier Management Process Owner) ניהול הספקים

Manager).בארגונים קטנים יותר, תפקידים אלו מאוחדים לנושא תפקיד אחד .

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

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

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

במהלך כל פעילויות התהליך:במאגר הספקים והחוזים יהיה מושא להתייחסות

סיווג ספקים ותחזוקת מאגר הספקים והחוזים

הערכה והיערכות של ספקים וחוזים חדשים

-22-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

הקמת ספקים חדשים

ניהולי ביצועי ספקים וחוזים

חידוש והפסקת חוזים

כאן מובאות הפעילויות במסגרת תהליך ניהול הספקים וניהול מחזור חיי החוזה:

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

זיהוי שיטת רכש )מכרז/ספק יחיד(, -הערכה ורכש של חוזים חדשים וספקים חדשים הגדרת תבחינים להערכה, בחינת חלופות, בחירה, ניהול מו"מ, הסכמה וחתימת החוזה;

הקמת הספק והחוזה במאגר הספקים והחוזים, הפעלת - הגדרת ספקים וחוזים חדשים החוזה, הגדרה ומימוש תהליכי העבודה השוטפים;

הערכת החוזים, הערכת הספקים, עדכון מאגר הספקים והחוזים, -סיווג ספקים וחוזים תחזוקה שוטפת של מאגר הספקים והחוזים;

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

סיום/חידוש חוזה אפשרי;

סקירת התועלות והמחויבות לאורך זמן, מו"מ מחודש וחידוש, -סיום תקופת השירות ם ו/או העברה של השירות.סיו

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

(Risk) רמת ההשפעהו (Impact) שלהם מצד שני:

(Commodity Supplierספק גנרי ) .1

ספק ייחודי .2

(Strategic Supplierספק אסטרטגי ) .3

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

, אתוסוג הספק קובע את תדירות הפגישות הדרג הניהולי של איש הקשר, תדירות

דירות פגישות סקירת ספק תקופתיות, ת והיקף דו"ח ביצועי הספק.

-23-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

(Service Transition) שירות לייצורהעברת ה

נכסי שירות ופריטי תצורה .26 (Service Asset & Configuration Management) נכסים ותצורהניהול

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

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

ביניהם: יםההבדלאת רולהסבי ITILשיטת לפי לבאר את המושגים החלטתי)ולא בכדי(, יםהשני

נכסי שירות (Service Assets )- רכיבים אלו לרוב משמשים לאספקת השירותנכסים ה .נרכשו בכסף וקיים להם מיקום פיזי. מדובר לרוב בנכסים שנרכשו, כגון שרתים, מכונות

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

פריטי תצורה (Configuration Items; CIs) - פריטים שקשריהם הייחודים נחוציםלאספקת השירות )ובמילים אחרות: זמינות השירות תלויה בהם(. פריטים אלו לא

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

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

בסיס הנתונים ( שמרכזה הוא Configuration Management System; CMS) התצורה

(.Configuration Management Database; CMDB) לניהול תצורה

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

יוצאי דופן:

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

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

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

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

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

אותם שמית.

ממחיש את החפיפה החלקית בין משמאלהתרשים

Serviceפריטי תצורה ונכסי שירות. ניהול נכסים ותצורה )

Asset & Configuration Management הינו חלק )

(, בעיקר Service Transition) יצורהעברת השירות לימ שינויבשל החשיבות של עדכון המידע בעת ביצוע

(Changeו )השפעהשימוש במידע לטובת הערכת ה

(Impact Analysis.של שינויים מתוכננים )

-24-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

ניהול סיכונים בתכנון שינויים .27 (Change Managementשינויים ) ניהול

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

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

הכרוך בביצוע ( Risk) סיכוןעם זאת, לא ניתן להימנע מביצוע שינויים, ולכן חשוב לנהל את ה

Change) שינוייםעל ניהול הסיכונים בשינוי הוא תהליך ניהול ה ןתהליך האמוההשינוי.

Management אחד האמצעים למזער סיכון זה הוא לאשר שינויים משמעותיים באמצעות .)

(. כדי לקבוע את מסלול האישורים הנדרש בכל Change Advisory Board; CAB) ועדת שינויים

שלושה סוגים של שינויים: ITILשיטת ( מגדירה RFCRequest for Change ;בקשת שינוי )

שינוי רגיל (Normal Change )- שינוי שרמת הסיכון שלו גבוהה יחסית )מעבר לסף דרש כי ועדת השינויים תאשר אותו בישיבתה )השבועית לרוב(.שהוגדר(, ולכן נ

שינוי סטנדרטי (Standard Change )- שינוי שרמת הסיכון שלו נמוכה יחסית )בשלרמת השפעה נמוכה ו/או מבוצע בתדירות גבוהה( ועל כן אינו דורש אישור מיוחד.

( באמצעות תהליך Service Requestשינויים סטנדרטיים מנוהלים כבקשת שירות )

(.Request Fulfillmentהמענה לבקשות )

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

(.Emergency CAB; ECABמאושר בנוהל מזורז על ידי ועדת שינויי חירום )

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

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

שלו. בבסיס נוסחה זו קיימות שתי הנחות יסוד: (Impact) רמת ההשפעהו (Frequency) השינוי

יותר;ככל שהשינוי עשוי להשפיע על משתמשים רבים יותר, כך רמת הסיכון שלו גבוהה .1

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

סיכון הערכת

(Risk Assessment)

(Frequency) תדירות

לעתים נדירות אחת לחודש אחת לשבוע אחת ליום

1 2 3 4

רמת השפעה

(Impact)

4 3 2 1 1 אין השפעה 8 6 4 2 2 משתמש יחיד

12 9 6 3 3 תמשיםקבוצת מש 16 12 8 4 4 כל המשתמשים

דורשים אישור של ומעלה מוגדרים כשינויים רגילים ועל כן 9ניתן לקבוע כי שינויים ברמת סיכון

המאושר חירום, אלא אם השינוי נועד לפתור תקלה ואז הוא מוגדר כשינוי (CABת השינויים )דוע

.(ECABעל ידי ועדת שינויי החירום )

-25-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

(Service Operation) השירות תפעול

מצא את ההבדלים -אירוע, תקלה ובעיה .28 (Problem Management), ניהול בעיות (Incident Management), ניהול תקלות (Event Management)ניהול אירועים

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

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

(.Service Operation) תפעול השירותאירועים, תקלות ובעיות, המשולבים בתהליכי ביניהם:

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

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

Event) היא אירוע. תהליך ניהול האירועים שבראייתנו יש לה חשיבותשל תהליכים ועוד. פעולה

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

( מידעInformation )- אירועים אלו נשמרים לידיעה בלבד )לרוב בקובץ לוגים על .המחשב או השרת( לטובת תחקור אוחר

( אזהרהWarning) - אירועים המתריעים מפני חריגה צפויה מסף שהוגדר. אירועים אלו

(.Event Management System) מערכת ניהול האירועיםנוהלים על ידי מנוטרים ומ

( חריגהException) - אירועים המתריעים כי הייתה חריגה מסף שהוגדר. אירועים אלו

(.Event Management System) ול האירועיםמערכת ניהמנוטרים ומנוהלים על ידי

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

.(Change) שינוילטובת שדרוג גרסה( לא תיחשב כתקלה אלא כ)למשל: השבתת שירות שירות

Service) מערכת ניהול השירותמתועד ב (Incident Managementהליך ניהול התקלות )ת

Management System.)

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

( נרצה CPUמהזיכרון של יחידת העיבוד המרכזית ) 80%למשל: אם שרת מגיע למצב של צריכת .יוגדר המצב כתקלה 90%-ור את רף הלדעת על כך, אך רק אם הצריכה תעב

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

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

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

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

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

-26-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

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

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

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

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

הוא (Problem Management) תהליך ניהול הבעיות ל הבעיות.לרוב לא ניתן לנהל את כל התהליך שבמסגרתו מטופלות אותן בעיות שבחרנו לנהל.

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

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

(.Service Management System) רותמערכת ניהול השיתהליך ניהול הבעיות מתועד ב

I2Pשיטות לביצוע

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

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

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

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

טיפים לחיסכון בזמן .29 (Incident Management)ניהול תקלות

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

זמן התיעוד

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

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

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

יש לוודא שהרשימות )למשל: רשימת המערכות ורכיביהן( מתוכן בוחר -רשימות .1 בצורה שקל להתמצא בהן. הטכנאי הן עדכניות ומדויקות ובנויות

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

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

-27-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

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

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

תמנע בלבול ותבטיח אחידות בתיעוד בין כל הטכנאים באותה מחלקה.

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

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

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

יתן להגדיר תבניות לקריאות, שבהן כל השדות במרכבית המערכות נ -תבניות .5 לטכנאי לעשות, הוא לזהות את מהי "הטכניים" למילוי כבר הוגדרו, ואז כל שנותר

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

זמן הטיפול

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

יותר את משאב הזמן:

מומלץ כי בהישג ידו של כל -( Known Error Database; KEDB) ידועותמאגר תקלות .1ל כל התקלות הנפוצות, דרכי זיהוין, דרכי פתרונן ואף שטכנאי יהיה מאגר ובו פירוט

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

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

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

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

.בהם

מערכת זו -( Configuration Management System; CMS) תצורהמערכת ניהול .2משמשת כעין "מפה" טכנולוגית המאפשרת לכל טכנאי להתמצא בסבך המערכות והרכיבים ולזהות ולאבחן בקלות רבה יותר את הגורם לתקלה. מומלץ לשלב אותה בתוך

פריט התצורהכך שלפי (Service Management system; SMS) שירותמערכת ניהול ה

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

יכול לסייע בקביעת עדיפות (Event Management System) מערכת ניהול האירועיםללאירועים ותקלות הנובעות מהם, שכן מערכת ניהול התצורה יכולה להכיל גם קשרים

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

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

-28-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

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

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

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

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

תעדוף תקלות .10 (Incident Management)ניהול תקלות

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

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

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

רמת השפעה (Impact) - כמות המשתמשים המושפעים. כל ארגון יכול להגדיר לו סולםומעלה; 1000משתמשים, 10-100משתמשים, 1-10שונה של רמות השפעה )דוגמאות:

Configuration) מערכת לניהול תצורהאם בארגון הוטמעה צוות, מחלקה, אגף(.

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

דחיפות (Urgency) - .להלן מאפיין המשקף את חומרת הפגיעה בשירות בעיני הלקוח דוגמה:

o תפקוד עסקי חיוניאובדן מידע עסקי, פגיעה ב - דחיפות גבוהה (Vital Business

Function; VBF;)

o יטיות או עיכוב בקבלת מידע עסקי;בעיות ביצועים וא - דחיפות בינונית

o דחיפות נמוכה - ( פגיעה בתפקוד משניNice to Have.)

ות, בהתבסס על רמת ההשפעה והדחיפות:פהטבלה הבאה מדגימה את אופן חישוב העדי

תעדוף

(Prioritization) (Urgencyדחיפות )

גבוהה בינונית נמוכה

רמת השפעה

(Impact)

גבוה-3 רגיל-4 נמוך-5 נמוכה קריטי-2 גבוה-3 רגיל-4 בינונית שבר-1 קריטי-2 גבוה-3 גבוהה

קובעת במשולב עם אמנת השירות שהוגדרה לשירות המושפע תעדיפות הטיפול המתקבל

Major) תקלת שבר. תקלה בעדיפות הגבוהה ביותר מוגדרת כבקריאה את זמן היעד לטיפול

Incident).ועבור תקלות מסוג זה לרוב קיים נוהל חירום מיוחד ,

שאלה נפוצה בהקשר זה היא: כיצד לתעדף בין שתי תקלות בעדיפות זהה? התשובה כאן למעשה

(. זמן היעד Service Level Target; SLT) זמן היעד לטיפולטמונה במאפיין אחר של התקלה:

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

-29-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

להלן דוגמה:

(SLTחישוב יעד הזמן ) (SLAאמנת שירות )

פלטינה זהב כסף ארד

עדיפות(Priority)

0.5 1 2 4 שבר-4 1 2 4 8 קריטי-2 2 4 8 16 גבוה-3 4 8 16 32 רגיל-4 8 16 32 64 נמוך-5

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

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

לטיפול לפי יעד הזמן שלהן, שיהיה שונה בכל תקלה ותקלה.

?למה זה חונה אצלי .12 (Incident Management(, ניהול תקלות )Request Fulfillmentמענה לבקשות )

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

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

העברות בין שני צוותים

( מעוניין להעביר בשעות הלילה Level 1)לרוב בדרג 24/7לעתים נוצר מצב בו צוות מסוים שפעיל

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

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

ום. במילים אחרות, השאלה היא: לחובת איזה מהצוותים צריך להיספר פעיל רק בשעות הי הזמן?

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

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

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

פונג מקצועי-פינג

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

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

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

-30-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

(, תפקיד Incidet Managerהטוב ביותר לבעיה זו הוא מינוי גוף אחראי לניהול התקלות ) הפתרון

ארגון. מנהל התקלות מחזיק של ה (NOC) מרכז תפעול רשתיבמסגרת 24/7שיכול להיות מאויש

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

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

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

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

המשימות.

עיכוב שאינו באשמת הצוות

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

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

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

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

להשתמש בסטאטוס השהיה שלא לצורך.

Service) מערכות ניהול השירותשק בין ליצור ממ ניתן, כאשר לא במקרה של חברות חיצוניות

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

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

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

.השירות

המתנה לתגובת לקוח

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

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

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

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

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

-31-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

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

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

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

שיר או ציר מנוהל?ציר י .11 (Incident Managementניהול תקלות )

נהל תקלותמבארגונים בהם קיימים עשרות צוותים טכניים, לעתים מחליטים להקים גוף

(Incidet Manager)( כדי לשפר את תהליך ניהול התקלות ,Incident Management) גוף זה .התקלות, אלא רק את התקלות המערכתיות, שמתאפיינות ברמת מורכבות אינו מנהל את כל

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

דים:גוף ניהול התקלות ארבעה תפקיל ITILשיטת לפי אלו מוגדרות כתקלות מנוהלות.

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

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

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

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

עדיפויות שהוגדר.

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

גוף הניהול אחראי לעדכן מנהלים - (Hierarchical Escalation) עדכון בכירים .4 רלוונטיים, בהתאם לנוהל מוגדר.

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

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

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

עורבות של גוף הניהול.מהצוותים הטכניים, ללא

תהליכי אורך, רוחב ועומק .13 (Managing Across the Life-Cycle) ניהול רשתי של מחזור חיי השירות

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

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

-32-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

לין זו מתבטאת בכך שניתן ליצור קריאה אחת מתוך קריאה אחרת:תלות גומ

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

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

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

לטיפול בתקלה )"השבתת שבר"( מידי, הנדרש באופן שינויניתן ליצור תקלהמתוך

יש לחקור , שאותהבעיהניתן ליצור תקלהמתוך

על מנת לפתור אותהשינויניתן ליצור בעיהמתוך ,

שכן ביצוע השינוי יכול להניב תקלות חדשותתקלהניתן ליצור שינוימתוך ,

-33-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

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

סוגים:

אינו יוצר תלות תהליכים בין הקריאות המשתתפות בקשר. -קשר פשוט

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

ו ממנה, כדי לסיים את הטיפול בהפנייה ממתינה לסגירת תקלה/שינוי שנוצר - תקלה ממתינה לסגירת שינוי )"השבתת שבר"( שנוצר ממנו, בכדי לסיים אותה -

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

ן סוג מסוים של תהליכים, שאותם אני מכנה "תהליכי אורך", הדוגמה דלעיל עוסקת בקשרים בי

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

ם אנו מכנים בשם תהליכים אלו מאופיינים בניהול של פריטים שאות -תהליכי אורך

Request(. קבוצה זו כוללת תהליכים כגון מענה לבקשות )Tickets) קריאותהכולל

Fulfillment( ניהול תקלות ,)Incident Management( ניהול בעיות ,)Problem

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

שינוי(. זהו הרובד הגלוי ביותר.

תהליכים אלו חוצים את תהליכי האורך ומעשירים אותם במידע נוסף -תהליכי רוחב

( מעשיר Knowledge Managementהמשפר את תהליכי האורך. לדוגמה: ניהול ידע )נהלי העבודה או תקלות ידועות במהלך הטיפול בבקשה או בתקלה, את התומך ב

( Service Asset & Configuration Managementבהתאמה; ניהול נכסים ותצורה )

( כלשהו )הרכיב התקול, הרכיב שבו CI) פריט תצורהמוודא כי כל קריאה מתייחסת ל

Service Levelעוד ומדידה; ניהול רמת השירות )מבוצע השינוי( לטובת תי

Management זמן היעד לטיפול( מגדירה את (SLT בכל קריאה, בהתבסס על ) אמנת

(.SLA) השירות

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

( ואת ניהול אוגדן Service Catalog Managementכוללים את ניהול קטלוג השירותים )

-34-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

(. כך לדוגמה, בכל קריאה יתועדו השירות Service Portfolio Managementהשירותים )ים, הקובעים את אמנת השירות שלפיה תטופל הקריאה המושפע או השירותים המושפע

ומשמשים גם לצרכי תיעוד ומדידה.

והעומק: הרוחבהאורך, תהליכיהתרשים להלן מדגים את הקשרים בין

-35-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

(Continual Service Improvementשיפור השירות המתמיד )

מדדי המפתח .14 (Step Improvement 7) שיפור בשבעה שלבים

, מומלץ (Continual Service Improvement) המתמידהשירות פור ישהליך ככלל, במסגרת ת

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

הנפוצים ביותר: (KPIs) המפתח

MTTR/MTRS

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

ידי הגורמים התקלה על בפתרוןות הזמן הממוצעת שהושקעה מהמדד היא למדוד את כ

זמן החזרת השירות . MTRSהוחלף מדד זה במדד ITILשל 2011עם פרסום גרסת הטכניים.

( מחושב מרגע תחילת התקלה ועד לקבלת אישור Mean Time to Restore Service) הממוצע

דד זה מוכוון יותר לחוויית הלקוח.. מMTTR-תקינות מהלקוח, ועל כן נוטה להיות ארוך יותר מ

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

MTBF

או MTTR( מחושב כמדד משלים למדד Mean Time Between Failures) זמן ממוצע בין תקלות

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

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

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

זמינות

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

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

אחרים צריכים להיות זמינים בשעות העבודה בלבד, או בימים שתנים, במועדים המתוכננים מראש.ושעות מ

-36-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

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

תהליכים ומדדים

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

ו/או התשתיות המרכיבים את השירות.

(Event Management) ניהול האירועים . שיפור תהליכיITILתהליכי מדדים אלו קשורים ל

תכליתם לקצר את משך הטיפול בכל אירוע ותקלה (Incident Management) וניהול התקלות

(Problem Management) . שיפור תהליכי ניהול הבעיותMTTR/MTRS-ובכך להקטין את מדד ה

ובכך להגדיל את תכליתם לצמצם את מספר התקלות (Change Management) וניהול השינויים

תכליתם לשפר את זמינות השירות. MTBF-והגדלת ה MTTR/MTRS-. הקטנת הMTBF-מדד ה

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

ספקטיבהעניין של פר -מדידה .15 (Step Improvement 7) שיפור בשבעה שלבים

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

למדוד? האם יש להגדיר סט מדדים אותם כדאי (KPIs) מדדיםזה מעלה מספר שאלות: מהם ה אחיד לכל המנהלים בארגון? האם אפשרי שכל מנהל יראה תמונה שונה?

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

תוצאותלוח היש לקבוע מספר מדדים קבועים שיוצגו ב -למגזרים חלוקה

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

שונה מראשי מחלקות האחראים על תחזוקת תשתיות. תוצאותוח אפליקציות יצטרכו ל

יש לוודא שכל המדדים מחושבים מתוך אותו בסיס נתונים ובאמצעות -תהליך אחד נוסחה אחידה.

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

, שירות, רמת שירות ועוד.פתרוןלפי צורת דיווח, שיטת

מדידת משאבים בחתך מערכת או בחתך שכבה טכנולוגית )דוגמה(

מערכת גמל בית אוהל

שכבה טכנולוגית

גמל.תוכנה בית.תוכנה אוהל.תוכנה (Applicationתוכנה )

DBגמל. DBבית. DBל.אוה (DBבסיס נתונים )

גמל.אחסון בית.אחסון אוהל.אחסון (Storageאחסון )

גמל.תקשורת בית.תקשורת אוהל.תקשורת (Networkתקשורת )

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

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

-37-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

"אנושי שהוא לחשוב האדם לבני יגרום כשהוא אינטליגנטי להיחשב יוכל מחשב"

טיורינג אלן -

-38-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

ITILכלים טכנולוגיים ליישום .16

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

ITILההבדלים ביניהם.אותם ולהסביר את להגדירזו אבקש ת, ובמסגר

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

מזוהים על ידי מערכת ניטור אחת או יותר האירועים מרוכזים( EMS) עיםמערכת ניהול האירוב

(.Manager of Managers"מנהל המנהלים" )כ (Event Management)ניהול אירועים לטובת

( לזהות אירועים IT Operations Managementתפעול המחשוב )ניהול מערכת מאפשרת לה

( ולהגיב במהירות.Exception( וחריגה )Warningמסוג אזהרה )

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

( מסוגים Tickets) קריאותהעיקרית בה מנוהלות ההמערכת ( היאSMS) מערכת ניהול השירות

Access(, ניהול הרשאות )Request Fulfillmentובכלל זה מענה לבקשות )שונים,

Management( ניהול תקלות )Incident Management( ניהול בעיות ,)Problem

Management( וניהול שינויים )Change Management.) ( בנוסף, ניהול רמת השירותService

Level Management אמנות שירות( מבוצע באמצעות מערכת זו, ובכלל זה (Service Level

Agreementהסכמי תמיכה( ו (Operational Level Agreements.) ( מנהל המערכתAdmin הוא )

(.Service Managerמנהל השירות )

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

פריטי התצורה( וService Assets) נכסי השירותמנוהלים ( CMS) מערכת ניהול התצורהב

(Configuration Items; CIsוהקש )מבוצע ניהול הנכסים והתצורה ) בהים ביניהם. רService

Asset & Configuration Management קטלוג השירותים( וכן ניהול (Service Catalog

Management( מנהל המערכת הוא מנהל התצורה .)Configuration Manager מערכת זו .) מורכבת משלושה חלקים:

יהול תצורהבסיס הנתונים לנ (Configuration Management Database; CMDB )- אוסף של טבלאות המכילות את המידע אודות פריטי התצורה והקשרים ביניהם וכן ממשק משתמש לניהול. מודול זה הוא המרכזי מבין השלושה והוא מהווה חלק בלתי

נפרד ממערכת ניהול התצורה.

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

(Consolidationאל תוך בסיס הנתונים לנ )( יהול תצורהCMDB.)

ניהול שירותים עסקיים (Business Service Management; BSM )- ל המזהה ומוד

(. Business Services) השירותים העסקייםאת קשרי התצורה בין פריטי התצורה לבין

( של פריטי Impact Analysis) השפעהפרד, ומאפשר לבצע הערכת לרוב נרכש בנ הוא

סיבת שורש( וכן אבחון Bottom-Upתצורה על השירותים העסקיים מלמטה למעלה )

(Root Cause Analysisמרמת השירות העסקי ועד לפריט )בו התצורה התומכים י

(.Top-Downמלמעלה למטה )

-39-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

( שאותם ניתן להשוות Configuration Snapshotsמערכת ניהול התצורה שומרת מצבי תצורה )

(. לכידה יומיומית של מצבי תצורה תורמת לארגון Baseline Configurationלתצורת הבסיס ) בשני אפיקים:

עו, וכן לזהות ביצוע של יכולת לזהות כל שינוי תצורה, ולקשרו לשינויים שאושרו ובוצ .1 שינויים שלא אושרו.

( למצב Rollbackיכולת להבין "מה נשתנה" כאשר יש תקלה ולבצע חזרה לאחור ) .2 התצורה הקודם, שבו השירות היה תקין.

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

בניהול (Knowledge Base Articles; KBAs) מאמרי הידעאת אוגרת( SKMS) מערכת ניהול הידע

(Admin( מנהל הידע )Knowledge Manager לטובת )( ניהול ידעKnowledge Management.)

(Service Catalog portalפורטל קטלוג השירותים )

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

(Incidentsו )בקשות שירות (Service Requests ולעקוב אחד סטטוס הטיפול בהן, לקבל מידע )

( KBAs) מאמרי ידע( ולצפות בMajor Incidents) תקלות שבר( מתוכננים וChanges) שינוייםעל

(. לפורטל זה קיימים שמות נוספים כגון Frequently Asked Questions) שאלות נפוצותכגון

(.Self-Service( או פורטל שירות עצמי )Self-Helpפורטל עזרה עצמית )

הקשרים בין הכלים השונים

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

( בין Correlationמתאם ) ל זהל( בין האירועים ובכDependenciesהאירועים לזהות תלויות )את המידע אודות האירועים התרעה שמצביעה על סיבת השורש.ההתרעות, כך שתוצג רק ה

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

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

( של Impact Analysisקשרי התצורה במערכת ניהול התצורה מאפשרים לבצע הערכת השפעה )פריטי תצורה על השירותים העסקיים במסגרת תכנון שינויים וכן לבצע אבחון של סיבת שורש

(Root Cause Analysisמרמת השירות העס ) קי ועד לפריטי התצורה במסגרת חקירת תקלות ובעיות.

( המסייעים לגופי KBAs) מאמרי ידעמערכת ניהול הידע מזינה את מערכת ניהול השירות ב

Standard Operating) נהלי תמיכהשירות מהיר ויותר יותר על ידי חשיפה של קהתמיכה לספ

Procedures; SOPsתקלות ידועותוכן על ידי חשיפת נוי( בבקשות שירות ובקשות שי (Known

Errors.בתקלות ובעיות ) ( ניהול מאגר הידעKnowledge Base במערכת ניהול הידע, מבוצע דרך ) שתי המערכות הוא הדדי.הממשק של מערכת ניהול השירות, כך שהקשר בין

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

-40-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

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

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

התרשים להלן, מתאר את כל המוצרים שהוצגו דלעיל, ואת הקשרים ביניהם:

(, CMS) מערכת ניהול התצורהחבילה אחת עם ב( לרוב נמכרת SMS) רכת ניהול השירותמע

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

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

, ודאו ITILשיטת קרונות כדי להבטיח שמערכת ניהול השירות הכוללת שאתם רוכשים בנויה לפי ע

. כל המוצרים בעלי תקן (PinkVERIFY™ by Pink Elephant) הוורודכי למוצר תו תקן של הפיל זה בהכרח מכילים את כל התהליכים המוצגים בתרשים להלן:

-41-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

נכשל? CMDB-האם חזון ה .17

נכשל", טענה אותה אנסה CMDB-נה השחוקה כי "המן לי לשמוע את הטעדפעמים רבות הז

ל ו( הוא בסך הכCMDB) נתונים לניהול תצורהבסיס הן. ראשית, עלינו לזכור כי להפריך להל

וא למעשה טבלאות של מידע אודות ה CMDB-(. הCMS) מערכת ניהול התצורהמרכיב אחד בתוך

( והקשרים ביניהם, שאותן ניתן להזין דרך ממשק משתמש Configuration Items) פריטי תצורה

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

ל במודול ועצמו אין משמעות, שכן מדובר בסך הכ CMDB-להצלחה או לכישלון של ה .1)ואמנם מודול מרכזי( של מערכת ניהול התצורה. במילים אחרות, אם משהו נכשל או

הצליח, הרי שזה הניסיון להטמיע מערכת ניהול התצורה.

בה, ועל כן לא ניתן שמנוהלדע עיקר עוצמתה של מערכת ניהול התצורה הוא בטיב המי .2

ל אוגר את ו, שבסך הכ, שהוא מטבעו רכיב סביל )פסיבי( בתהליךCMDB-להאשים את ה .המידע

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

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

(Root Cause Analysisמרמת השירות העס ) תקלותקי ועד לפריטי התצורה במסגרת חקירת

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

א ממחיש את החזון שבבסיס מערכת ניהול התצורה:התרשים הב

-42-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

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

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

התצורה לשירותים העסקיים.

מהו אם כן, מקור הטענה?

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

נכשל". את CMDB-הוכרז הפרויקט ככישלון ומכאן נולדה האמירה כי "הבמרבית המקרים

( Neebula( וניבולה )VNTהבעיה הזו ניסו לתקוף מספר חברות הזנק ישראליות ובהן ונט )

(. המוצר Business Service Management) ניהול שירותים עסקייםשפיתחו פתרונות למיפוי ושל ניבולה זכה להצלחה כבירה, כאשר חברת ההזנק הישראלית נרכשה על ידי חברת

ServiceNow ( העולמית, ששילבה את מיפוי השירותיםService Mapping כמודול מובנה בתוך )מוצר הדגל של החברה. ברגע שהיא מקבלת את הכתובת אליה ניגש המשתמש, מערכת זו

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

בין פריטי התצורה.

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

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

דילמת הקטגוריזציה .18

Service Management) שירותמערכת ניהול האחת מנקודות התורפה של ITILשיטת ביישום

System; SMS) הוא שלב סיווג הפנייה (Categorization) .( קטגוריהCategory של )תקלה

(Incident או )בעיה (Problem( מכונה לעתים בשם סימפטום )Symptomוקטגו ) בקשת ריה של

קביעת ( Service Request Definition; SRDמכונה לעתים בשם הגדרת הבקשה ) שירות

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

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

"השתדלו לא לאפשר היררכיה בה יש יותר משלוש רמות. -"השילוש הקדוש

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

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

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

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

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

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

-43-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

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

תיעוד רטרואקטיבי .19

עוסקת (Incident Management) ליך ניהול התקלותאחת הדילמות המטרידות ביותר בתה

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

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

תיעוד רטרואקטיבי, לאילו צוותים ובאילו מקרים?

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

מערכת ניהול אירועים (EMS) אירועיםחלק מהצוותים המנהלים -ללא ממשק

(Events) תקלותומטפלים ב (Incidents) סויםמבזמן אמת מתעדים את התקלה בעיכוב ,

. ודאי (Event Management Systemמערכת ניהול האירועים )מרגע שזוהתה על ידי , אך מערכת הניטורשזמני התחילה והסיום של התקלה המהימנים ביותר מקורם ב

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

, תמיד יתועדו התקלות (Service Management System) ערכת ניהול השירותמל באיחור מסוים.

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

תשומת לב גם לתיעוד התקלה.

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

ם לעשות זאת רק בשובם למשרד.ימידע, ועל כן הם נאלצ

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

רטרואקטיבי צריך להיעשות תוך הקפדה על הכללים הבאים:

( ניהול הרשאותAccess Management) - י רק לאותם צוותים שבאמת יש לוודא כזקוקים לכך יתאפשר תיעוד רטרואקטיבי. הגבלה זו תוכל להבטיח שלא ייעשה שימוש

ביכולת זו מעבר לדרוש.

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

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

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

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

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

-44-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

אקטיבית. זהו פער שצריך ( ואותם לא ניתן לערוך רטרוסטאטוס והעברות בין צוותים בחשבון. לקחת

מומלץ כי לתקלות שתועדו רטרואקטיבית תוגדר צורת דיווח ייחודית, -צורת דיווחשמבדילה אותן מתקלות "רגילות", כך שניתן יהיה לדעת בכל רגע בקלות מהו אחוז

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

אחידות או "תפירת חליפה"? .30

Service) שירותהמערכת לניהול אחד האתגרים המרכזיים בהטמעת , ITILשיטת במסגרת יישום

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

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

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

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

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

מומלץ לבצע צירוף אינטרסים.

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

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

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

באופן זה אין צורך לבצע התאמה של המערכת לכל משתמש ומשתמש אלא לקומץ

שמייצגים את סוגי המשתמשים השונים ובכך מכסים את מרבית (VIP) האח"מים הפונקציונאליות הנדרשת.

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

וגים: שדות לניהול ושדות למדידה.העבודה והם מחולקים לשני ס

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

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

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

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

-45-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

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

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

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

המדידה מתמלאים עד לרגע הסגירה.

אוטומציה .32

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

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

גילויזיהוי ו (Discovery) - אירועיםניטור (Events) באופן תדיר או במועדים קבועים לפי תזמון מראש;

תקלהטיפול ב (Incident) - ביצוע סדרה של פעולות במטרה לתקן תקלה, לפי אלגוריתם ;מראש מוגדר

שינויביצוע (Change) - פריטי תצורהיצירת (Configuration Items,) שרת הקמת כגון התקנת אפליקציות שונות על מחשב או שרת; כגון קשרי תצורה,או עדכון וירטואלי

תיעוד ורישום (Logging) - קריאותפתיחת, עדכון ו/או סגירה של (Tickets) מערכת ב

.(Service Management System) שירותניהול ה

שימוש במנגנונים אלו מעלה שתי סוגיות מתודולוגיות עיקריות:

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

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

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

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

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

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

המדידה.

-46-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

פת כל הארץ" י שם בלל ה' ש מה בבל כ ן קרא ש "על כ

פס' ט'ספר בראשית, פרק י"א, -

-47-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

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

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

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

אירוע .33Event

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

מערכת על ידי וקריםומב( ובקרה שליטה) ב"שו תשתית על ידי מנוטרים( Exception) וחריגה

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

נת השירותאמ .34Service Level Agreement (SLA)

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

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

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

(. ניהול Underpinning Contractsוחוזים תומכים ) הסכמי תמיכהת על ידי אמנת השירות נתמכ .עיצוב השירותרמת השירות הוא חלק מ

אנליסט .35Analyst

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

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

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

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

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

בעיה .37Problem

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

תועלת.-לחקור ולפתור את הבעיות מבוצעת לפי שיקולי עלות

-48-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

בקשת שינוי .38Request for Change (RFC)

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

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

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

בקשת שירות .39Service Request (SR)

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

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

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

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

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

גורם מטפל .42Responsible Person

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

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

לטיפולו ולקבל את מלוא סמכויות הטיפול בה. קריאהשון למשוך את ההרא

גילוי .41Discovery

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

(.CMDB) ניהול תצורהבסיס הנתונים ל( אל תוך Consolidationעובר תהליך של איחוי )

דחיפות .43Urgency

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

דרישות רמת השירות .44Service Level Requirements (SLR)

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

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

-49-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

הודעה .45Announcement

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

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

הסכמי תמיכה .46Operational Level Agreements (OLAs)

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

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

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

גבוהה תמיכה( לצוות ברמת Level 1ל: נמוכה יותר )למש תמיכהרמת ב צוותמ קריאההעברת

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

.אמנת השירותשהוגדר ב

הסלמה ניהולית .48Hierarchical Escalation

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

.קריאהאך היא מתועדת בה באמצעות הוספת הערות ב (SMS) השירות

ת השינוייםדוע .49Change Advisory Board (CAB)

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

(.Downtime) לקוחותלו, וכן עוצמת ומשך ההשפעה הצפויה שלו על הש רמת הסיכוןל

זמינות .50Availability

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

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

יחידה עסקית .52Business Unit

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

-50-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

יעד הזמן .51Service Level Target (SLT)

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

ישות .53Contact

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

לוח מחוונים .54Dashboard

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

( ואינו כולל יעדי ביצוע.SMS) ניהול השירות

לוח תוצאות .55Scoreboard

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

מערכת ניהול (. לוח התוצאות לרוב אינו חלק מCSI) שיפור השירות המתמידקבלת החלטות ו

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

סמך היחס בין המצב בפועל למצב הרצוי.

לקוח .56Customer

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

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

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

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

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

מאמר ידע .58Knowledge Base Article (KBA)

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

.השירות לייצור

-51-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

חמדדי מפת .59Key Performance Indicators (KPIs)

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

. זמינות(, וMTRS) משך תקלה ממוצע(, MTBF) משך תקינות ממוצעדוגמאות למדדים נפוצים:

(.CSI) המתמידהשירות שיפור השימוש במדדים נעשה כחלק מ

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

( RF) בקשות, בעיקר באמצעות מענה ללקוחות, האחראי על מתן שירות לITILשיטת גוף מרכזי ב

לקוח(. גוף זה מנהל את הפתרונות מקצה לקצה ואחראי כלפי הIM) תקלותוניהול

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

(Level 1משום שהוא הראשון לטפל ב ,)לקוחותשדווחו על ידי ה תקלות.

מנהל תקלות .62Incident Manager

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

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

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

מסלולי טיפול .61Handling Routes

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

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

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

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

( ביחידה ארגונית אחרת.Level 2( לצוות הטכני המומחה )Level 1) הלקוחות

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

או יותר ומרוכזים למערכת ניהול דניטור אח כלימזוהים על ידי ה אירועיםלניהול מערכת

ניהול (. המערכת מאפשרת לManager of Managersמרכזית המשמשת "מנהל של המנהלים" )

יב במהירות.( ולהגException( וחריגה )Warningמסוג אזהרה ) אירועיםלזהות תפעול המחשוב

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

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

-52-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

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

שינוייםוניהול (PM) בעיות, ניהול (IM) תקלות, ניהול (RF) בקשותמענה ל מנוהליםבה מערכת

(CM)מערכת ניהול תצורה. מערכת זו עשויה לכלול בתוכה או להתממשק ל (CMS) ערכת מול

מערכת , בהתאמה. (KM) וניהול ידע (SACM) תצורהנכסים , לטובת ניהול (SKMS) ניהול הידע

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

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

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

בסיס הנתונים לניהול תצורה(, Discovery) גילוי אוטומטילהתבסס על שלושה מרכיבים:

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

על פריטי תצורה( של Impact Analysis) השפעההערכת מאפשרתמערכת ה. באופן ידני/אוטומטי

Root Cause) סיבת שורשועל וכן אבחון של שינוייםבמסגרת תכנון השירותים העסקיים

Analysisבעיותו תקלותבמסגרת חקירת פריטי התצורהועד ל שירות העסקי( מרמת ה.

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

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

משימה .68Workflow Task / Work Order

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

המשימות הקודמות להן, כפי שהוגדר בתזרים המשימות.

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

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

הבאה. תקלהלהתרחשותה של ה

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

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

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

-53-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

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

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

משתמש .71User

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

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

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

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

ניהול היישומים .74Application Management

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

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

ניהול התשתיות .75Technical Management

שירות התומך ב שירות טכניהגוף האחראי על פיתוח תשתיות המחשוב, כאשר כל תשתית היא

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

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

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

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

השירותים על פריטי תצורה( של Impact Analysis) השפעהבנפרד, ומאפשר לבצע הערכת

( מרמת Root Cause Analysis) שורשסיבת ( וכן אבחון Bottom-Upמלמטה למעלה ) העסקיים

(.Top-Downהתומכים בו מלמעלה למטה ) פריטי התצורהועד ל השירות העסקי

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

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

( והוא Network Operation Center; NOCזה נקרא לעתים מרכז תפעול רשתי ). גוף תקלות

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

-54-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

נכסי שירות .78Service Assets

שלהם ערך כלכלי )ולרוב גם ממשות פיזית( ,שירותרכיבים המשמשים לטובת אספקת ה

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

( הוא חלק SACMניהול נכסים ופריטי תצורה ) כרטיסים, קורא טביעת אצבע, מצלמת אבטחה(.

(.CMS) תצורהמערכת ניהול הומבוצע ב העברת השירות לייצורמ

נספח .79Attachment

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

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

סיבת שורש .80Root Cause

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

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

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

(.SQL-ו Oracleהסיווגים הם DB)לדוגמה: במשפחת

עדיפות .81Priority

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

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

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

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

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

פריטי תצורה .84Configuration Items

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

במסגרת ניהול (CMS) מערכת ניהול התצורה(. קשרים אלו מנוהלים בשירות)ולבסוף עם ה

-55-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

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

(.שירותים, אמרי ידעמ)לדוגמה:

צוות .85Group

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

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

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

צוות טכני .86Technical Group

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

צוות לקוחות .87Customer Group

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

שאותן פתחו בלבד. קריאותאודות ה ולהתעדכן

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

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

צוות מטפל .89Responsible Group

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

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

כצוות מטפל.

צוות מנהל .90Accountable Group

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

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

-56-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

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

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

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

קריאה .91Ticket

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

.(SMS) ניהול השירות

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

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

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

רמת השפעה .94Impact

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

רמת סיכון .95Risk

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

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

רמת תמיכה .96Level / Tier

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

(Level 1 ,)צוותים טכניים ( מומחים המסוגלים לבצע חקירת עומק וטיפול שורשיLevel 2ו )צוותי

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

שאלה נפוצה .97Frequently Asked Question (FAQ)

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

-57-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

שינוי חירום .98Emergency Change

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

שינוי סטנדרטי .99Standard Change

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

שינוי רגיל .200Normal Change

גבוהה. רמת השפעההמבוצע בליבת המערכת, שהינו לרוב ייחודי, מורכב ונדיר, בעל שינוי

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

שירות .202Service

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

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

שירות טכני .201Technical Service

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

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

שירות עסקי .203Business Service

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

מקורות )שירותי תוכן(.ו ים(ארגוניאו יםעסקי) יישומים

תהליך עסקי .204Business Process

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

תפקוד עסקי חיוני .205Vital Business Function (VBF)

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

-58-

ITIL | ספר המתכונים 6102מאי |מהדורה שנייה

תקלה .206Incident

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

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

תקלה ידועה .207Known Error

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

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

.(Workaround) פתרון ידוע או מעקף

תקלה מבצעית .208Operational Incident

שלה הוגדרה כמבצעית )לדוגמה: תקלה ברכיב פריט התצורהשהסביבה של המיקום של תקלה

Outlook.Exchange תהיה מבצעית בעוד תקלה ברכיבOutlook.Client .)לא תהיה מבצעית

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

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

תקלת שבר .220Major Incident

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

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