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

כללי – מבוא

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

מטרה זו מושגת באמצעות:

 

 •         תהליך של ניהול משא ומתן במגמה להפיק מסמך רמת שירות מוסכם בין נותן השירות (הספק) למקבל השירות (הלקוח) - הסכם רמת השירות.

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

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

 

לתהליך זה ישנן השלכות רגולטיביות עקב דרישת SOX לניהול תפעול המערכות (סעיףIT General Control), רגולציה של אבטחת מידע ו- ITG.

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

 

מטרה

מטרת התהליך היא לממש את המפורט להלן:

 

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

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

 •         הגדרת אופן תהליך מיסוד והסכמה על רמת השירות,

 •         הגדרת תהליך בקרת רמת השירות,

 •         הגדרת הדיווח השוטף לבקרת רמת השירות: דוחות, מחזוריות ותפוצה,

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

תועלות התהליך

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

 •         תיאום ציפיות בין ספק ללקוח,

 •         תעדוף נכון בהתאם לצורך עסקי,

 •         זיהוי נקודות תורפה כך שניתן יהיה לשפר אותן,

 •         ניהול אפקטיבי של ספקים,

 •         הגדלת היכולת לעמוד בדרישות הארגון לאורך זמן,

 •         בסיס איתן לשיפור מתמיד של איכות השירות,

 •         העלאת שביעות הרצון של הלקוחות/משתמשים,

 •         סיוע בעמידה ברגולציות ותקנים.

 

התועלת הישירה של מיסוד התהליך לגוף ה- IT תתבטא במיוחד ב:

 

 •         יכולת הניהול, ההתמקדות והתעדוף של השירותים,

 •         הגברת תיאום ציפיות מול המשתמשים בכל הרבדים,

 •         הגדלת שביעות רצון של הלקוחות משירותי גוף ה- IT,

 •         עמידה ברגולציות וסטנדרטים.

הגבלות, חריגים וסייגים

 •         ה - SLA מותנה בהעמדת משאבים בקיבולת הנדרשת על פי התכנון ובתמיכה של קווי התמיכה בחוזי OLA (Operational Level Agreement) וחוזי צד שלישי תומכים,

 •         תהליך זה מותאם לעבודה תחת מסגרת ITIL v3. אי לכך תועלת מירבית תתקבל רק לאחר מימוש כלל תהליכי ה- Service Management ומיסוד של מערכת המדידה,

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

 

מחזור חיים של תהליך SLM

שלבי התהליך

מחזור החיים לתהליך רמת השירות כולל את השלבים הבאים:

 

1.       ייזום – דרישת לקוח, צורך עסקי, שינוי,

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

3.       גישור מקצועי ועסקי, חתימה על הסכם ה SLA,

4.       הקמת מערכת המדידה,

5.       הגעה ל- Base Line וכוונון נדרש,

6.       On Going - מדידה, בקרה, סקירה, שיפור מתמיד,

7.       יציאה משירות – הסרת השירות מקטלוג השירותים של מערכות מידע.

 

פירוט התהליך

ייזום – דרישת לקוח, צורך עסקי, שינוי

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

 

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

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

 •         צורך עסקי - שינוי הנובע מתוך דרישה מאושרת במערכת ניהול הדרישות. במסגרת תהליך ניהול הדרישות יש להגיע גם להסכמה ולהקצאת משאבים הכרוכים בשינוי רמת השירות. מאשר הדרישה אחראי לנושא זה. התיאום יבוצע מול מנהל רמת השירות והלקוח המייצג את הדרישה העסקית. עבור שינוי מהותי ואשר נוגע לשירות IT קריטי, באחריות מנהל התפעול להחליט באם יבוצע BIA ( Business Impact Analysis) לשינוי הנדרש.

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

 •         שינוי טכנולוגי - שינוי ברמת שירות הנובע מסיבה טכנולוגית. מנהל רמת השירות יסביר וינמק את סיבת המקור והסיכונים הכרוכים בביצוע/אי ביצוע של השינוי.

 

אפיון – הגדרת השירות ותכולתו

בשלב זה יבוצע אפיון מפורט של רמת השירות על כל מרכיביו:

 

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

 •         מילוי טופס בקשה ל- SLA,

 •         אפיון מלא של המדדים ואופן המדידה,

 •         תוצרי בקרת רמת השירות.

 

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

 

גישור מקצועי ועסקי, חתימה על הסכם ה SLA

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

 

 •         הוספת הסכמי OLA ו- UPC הנדרשים ואשר אושרו תקציבית לביצוע בשלבים קודמים,

 •         השגת פשרות עקב אילוצים בין הדרישה/ צורך ליכולת ה- IT לבצע,

 •         התגברות על מחלוקות,

 •         חתימת ההסכם של כל הגורמים המעורבים,

 •         חשיפה ופרסום של ההסכם לפי כללי השקיפות שהוחלט עליהם (למשל חשיפת השירות בקטלוג).

 •          

הקמת מערכת המדידה

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

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

 

הגעה ל- Baseline וכוונון המערכת

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

On Going - מדידה, בקרה, סקירה, שיפור מתמיד

השלב השוטף יכיל את הפעילויות :

 

 •         מדידה – מדידה שוטפת של המדדים בהתאם לאופיים ויכולת קבלת תוצרים.

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

 •         בקרה – בקרה תבוצע במספר רמות: Dashboard, דוחות קבועים ומחזוריים, התראות של מערכת השו"ב הן לאי קיום המדידה והן על הפרת ה- SLA. במחזור ארוך יותר ובהתאם לשיקול של מנהל ה- SLA ומנהל השיפור תבוצע בקרה על התהליך עצמו.

 •         סקירה – תבוצע סקירה חצי שנתית ברמת הנהלת גוף ה- IT. תוכן הסקר:

             •          הצגה וניתוח של נתוני העמידה/אי העמידה ביעדי המדדים של ה- SLA.

             •         הצגת ממצאים מתחקירים שבוצעו בחצי השנה עקב אירועים של אי עמידה ב- SLA.

             •         העלאת דרישות וצרכים רוחביים לשיפור רמת השירות.

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

 •         שיפור מתמיד – במסגרת השיפור המתמיד יבוצע Assessment שנתי לתהליך ה- SLM. ממנו יופקו לקחים שיהוו בסיס לשיפור המתמיד.

 

יציאה משירות

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

גורמים מעורבים בתהליך

הגורמים המעורבים בתהליך הם:

 

 •         מנמ"ר והנהלת החברה,

 •         לקוחות,

 •         מנהל התפעול (מנהל השירות),

 •         מנהל רמת השירות,

 •         מנהל השיפור המתמיד / מנהל איכות,

 •         מרכז השירות,

 •         צוותי תמיכה טכנית בתחום תפעול ותשתיות,

 •         צוותי פיתוח ויישומים באגף מערכות מידע,

 •         עובדי הארגון (משתמשים),

 •         שותפים עסקיים,

 •         ספקים – צג ג'.

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

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

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

 

הגדרת תפקיד מנהל שירות

 •         איכלוס ועדכון של קטלוג שירותים,

 •         עיצוב, בנייה ותחזוקה של  הסכמי רמת שירות – SLA, הסכמי רמת שירות פנימיים – OLA, הסכמי שירות חיצוניים – UPC,

 •         ביצוע של מו"מ עם לקוחות על הסכמי רמת שירות והגעה להסכמה,

 •         ניתוח וסקירה של הסכמי רמת שירות מול עמידה בפועל,

 •         הפקה של דוחות רמת שירות,

 •         מתאם של שינויים אשר נועדו על מנת לעמוד ברמת השירות,

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

 •         שיפור מתמיד של תהליך ניהול רמת השירות.

דרישות וכישורים מבעל התפקיד

 •         יחסי אנוש מעולים,

 •         הבנה של מערכת המידע וההשפעה של שינויים ברמת השירות על מערכת ה- IT,

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

 •         יכולות גבוהות של תקשורת וניהול משא ומתן,

 •         סבלנות, סובלנות וגמישות,

 •         ניסיון וידע בתהליכי ניהול ספקים,

 •         יכולת ניתוח אנאליטית,

 •         יכולת הקשבה,

 •         יכולת אדמיניסטרטיבית,

 •         ניסיון קודם במשא ומתן עסקי.

 

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

מנהל רמת השירות ידווח לגורמים הבאים:

 

 •         מנהל גוף ה- IT לצרכי הסלמה,

 •         מנהלים עסקיים על רמת העמידה ברמת השירות ( SLA),

 •         ראשי צוותים על עמידה ברמת שירות פנימית ( OLA).

טבלת RACI לניהול התהליך

המונח RACI הוא קיצור של Responsible, Accountable, Consulted, Informed, שהן ארבע דרגות המעורבות של בעלי תפקידים בכל משימה.

 

 •         Responsible (R) - אחראי לביצוע בפועל

 •         Accountable (A) - מאשר, אחריות ניהולית

 •         Consulted (C) - מייעץ, מתייעצים בו לפי הנדרש

 •         Informed (I) - מידע, לידיעה בלבד

 

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

 

תפקידים   משימות	מנהל רמת שירות	לקוח	מנהל תפעול	אחראי מקצועי	צד ג'	מנהל שינויים	מנהל מרכז שירות	הנהלה	מנהל השיפור
ייזום	A	R	R	C
קביעת התכולה	A	R	C	C
גישור וחתימה	R	C	C	C
אתחול מערכת המדידה	A	I	R	R
הגדרת Base Line
מדידה
בקרה
סקירה
שיפור
יציאה משירות

 

מדידה, בקרה והסלמה

בסיס המדידה

כללי

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

במהלך הרבעון הראשון להפעלת המערכות יוגדר- Baseline, רמת השירות בפועל,  וממנה  יש להתחיל בביצוע שיפור מתמיד (לדוגמא: עלייה של 2% בשנה), עד הגעה ליעדים הרצויים.

 

מונחי יסוד

(SD – Service Desk)

א.       היקף תקלה (ב- SD מופיע כ"היקף השפעה")

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

ב.       קריטיות מערכת (ב- SD מופיע כ"דחיפות")

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

             •         קריטיות 1 -  עבור מערכת שאינה יכולה לסבול יותר מחצי יום השבתה

             •         קריטיות 2 – עבור מערכת שיכולה לסבול לכל היותר יום השבתה

             •        קריטיות 3 – עבור מערכת שיכולה לסבול יותר מיום השבתה

ג.        דרגת חומרה של תקלה (ב- SD מופיע כ"עדיפות")

דרגת חומרה תציין את עוצמת התקלה בהתאם לקריטיות המערכת (1-3) ולהיקף התקלה.

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

 

	קריטיות המערכת
היקף התקלה	1	2	3
א'	A	B	C
ב'	B	C	C
ג'	C	C	D
ד'	C	D	D

 

מדדי שירות

בתחום מדידת השירות מומלצים המדדים הבאים:

 

 •         מדד עמידה בפרויקטים – לו"ז

 •         מדד עמידה בפרויקטים - משאבים

 •         מדד עמידה בפרויקטים - איכות/תוצרים

 •         הרמת שפופרת ומענה לפונה

 •         שיעור שיחות ננטשות

 •         משך פתרון תקלה (Open ועד Resolve)

 •         MTBF (Mean Time Between Failures) – זמן ממוצע בין תקלות

 •         MTTR (Mean Time To Repair) – זמן ממוצע לתיקון

 •         FTFR (First Time Fix Rates) - שיעור פתרון במענה ראשוני

 •         משך טיפול בבקשת שירות

 •         זמינות מערכות/שירותים - Uptime

 •         ביצועי טרנזקציות

 •         שביעות רצון לקוחות/משתמשים

 •         אירועי אבטחת מידע

 •         אצווה וגיבויים

 •         המשכיות עסקית

 •         שיפור מתמיד

 •         תקלות חוזרות

 •         שיעור הצלחה של הפצות

 

בהגדרות הראשוניות של המדדים תהיה התייחסות לנושאים הבאים:

 

 •         אוכלוסייה

 •         תקופת מדידה

 •         תקופת ניתוח

 •         נוסחת החישוב

 •         Base Line

 •         יעד

 

בעוד שבמהלך השוטף של הפרויקט (On Going) תהיה התייחסות בעיקר לנושאים הבאים:

 

 •         רמת שירות בפועל

 •         מוצר תומך

 •         דוחות

 •         הסלמה

 •         פעילות

 

בקרה

הבקרה על תהליך ה- SLM מתבצעת באמצעות הגורמים הבאים:

 

 •         דו"חות – הפקה של דוחות עמידה ב- SLA לפי חתכים של: מדדים, לקוחות, אתרים, תקופות זמן (שעות , ימים, ימים מיוחדים), חריגות.

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

 •         תחקירי אירועים  של אי עמידה משמעותית ברמת השירות.

 

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

 

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

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

 

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

 

 •         תהליך CSI -  מימוש Continual Service Improvement לפי ITIL V3 מבוסס על עדכון יעדי המדדים ומעקב אחר ביצוע פעולות מתקנות של תחקירים.

 •         סקר שביעות רצון משתמשים/לקוחות תקופתי.

 •         סקר הנהלה תקופתי.

 •         Assessment (הערכה) לתהליכי מרכז השירות על פי ITIL.

 

הסלמה (אסקלציה)

תנאים לביצוע ההסלמה

הסלמה מתקיימת במצבים אלה:

 

 •         לפי הנחיות רגולציה,

 •         במידה ואי העמידה ב-SLA  היא עבור שירות קריטי מערכתי,

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

 •         בהתאם להנחיה מראש של גורם מוסמך/מנהל.

 

מצבי הסלמה

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

הסלמה מסוג זה תבוצע טלפונית (ובנוסף תגובה בדוא"ל) ותכלול:

             •         פרטי אי העמידה, גידור הזמן, אוכלוסייה,

             •         השלכות ומשמעות של אי העמידה בהיבט הלקוח ובהיבט גוף מערכות מידע,

             •         הצעה ראשונית לתיקון השבר.

ב.       הסלמה לגורם עסקי

הסלמה מסוג זה תבוצע טלפונית (ובנוסף תגובה בדוא"ל). תהליך ההסלמה לדרג הניהולי יכלול את המידע הבא:

             •         השלכות אי העמידה מבחינה עסקית,

             •         צעדים שבוצעו עד כה לאיתור הסיבת לאי העמידה,

             •         הגורם המטפל באישוש רמת השירות.

 

המפתח להצלחה

KSF – Key Success Factor

 

 •         ה- SLA מול הלקוח חייב להיות בראייה של "שירות",

 •         גוף ה- IT צריך לראות את עצמו כגוף שמספק שירות בעל ערך מוסף ללקוח, הטכנולוגיה הנה אמצעי,

 •         יכולות גישור לרמת שירות מוסכמת,

 •         מירכוז : הן ברמת תהליכים והן ברמת מערכות,

 •         הקמה של קטלוג שירותים,

 •         מיסוד תהליך של בקרת רמת שירות, כולל מינוי מנהל אחראי,

 •         התבססות על מערך מדדים רב מימדי ובר מדידה,

 •         ביסוס של תהליך שיפור,

 •         בקרה ואכיפה עם תמיכת הנהלה,

 •         אימוץ מסגרת ITIL,

 •         כלים התומכים בתהליך.