מענה לבקשות (Request Fulfillment), ניהול תקלות (Incident Management)

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

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

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

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

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

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

הפתרון הטוב ביותר לבעיה זו הוא מינוי גוף אחראי לניהול התקלות (Incidet Manager), תפקיד שיכול להיות מאויש 24/7 במסגרת מרכז תפעול רשתי (NOC) של הארגון. מנהל התקלות מחזיק את תמונת התקלות של הארגון, אחראי לעדכן בכירים (Hierarchical Escalation) במידת הצורך, ומוסמך להנפיק הודעות למשתמשים על תקלות או שינויים מתוכננים. בחלק מן המקרים יש לו גם תפקיד טכני, במסגרתו הוא מבצע אבחון ראשוני של תקלות מורכבות, כדי לקבוע מי הצוות הרלוונטי וכן הוא מבצע מעקב ובקרה על התקלות שבטיפול הצוותים כדי לוודא שהתקלות החשובות מטופלות לפי סדר קדימות נכון. בשל הסמכות שניתנת לו להורות לכל צוות באילו תקלות לטפל, הוא מסוגל וצריך למנוע מצב של פינג-פונג. תקלות מנוהלות חייבות לקבל את אישורו בכל העברה בין צוותים, כך שצוות אחד לא יכול להתנער מאחריות. מנהל התקלות יוודא שבוצעו כל הבדיקות המקדימות בטרם תאושר ההעברה והוא ישמש בורר בכל מצב של חילוקי דעות. הוא יכול אף להורות לכל אחד מן הצוותים לשלוח נציג בדחיפות ל”חדר הפתרונות”, בו כולם יושבים ביחד עד לליבון שורש התקלה והחלטה על אופן הפתרון וחלוקת המשימות.

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

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

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

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

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

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

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

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