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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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