לקוחות מתלוננים ומחפשים את המנכ"ל או את המנהלים הבכירים ודורשים תיקון מיידי לתקלה שקרתה? המנהלים מתרוצצים כדי להרגיע ולפתור בעיות? פותרים תקלה אחת ומיד נכנסות שלוש חדשות? יש עוד ועוד בעיות?…הקמתם מרכז שירות ותמיכה והתומכים משמשים שק חבטות ללקוחות? מנסים לפתור בעיות ולא תמיד מצליחים? התלונות הולכות ונערמות ויחד עם זה התומכים נשחקים וחלקם עוזבים?לא נעים, בהחלט…אבל יש גם יותר גרוע.
מה יותר גרוע מלקוח שמתלונן? לקוח לא מרוצה שלא מתלונן ולאחר שהסאה גדשה, פשוט מוצא אלטרנטיבה ועוזב.
מה עושים? מקימים מרכז שירות לקוחות ונותנים מענה לפניות או לפחות ממנים גורם אחד מרכזי שירכז את הפניות מהלקוחות והמענה להם; נותנים לתומכים כלים טכניים ורכים כדי לענות כהלכה ללקוחות, ועוד כהנה וכהנה.
המיקוד במרכז לשירות לקוחות הוא פתרון מהיר ואפקטיבי של תקלות הנוצרות משימוש במוצר או מהשירות. מאמר זה מרחיב את התהליך ומוסיף תשתית שמטרתה למנוע את הישנות התקלות.
תקלה בתהליך מתן השירות מוגדרת ככזאת שאם לא תטופל תגרום לכך שהספק שנותן את השירות לא יעמוד בהתחייבויות שלו. חלק מההתחייבות כתובות בהסכם השירות, וחלקן האחר ברור מאליו – למשל שהמוצר יעבוד לפי התצורה שהלקוח קבע, מתוך תפריט האפשרויות שסופקו לו.
התהליך כולל את הפעילויות הבאות:
להלן שני סוגים מרכזיים:
דוגמאות: באג בתוכנה שגורם להפסקת מתן שירות, או מזוודה שהולכת לאיבוד בשדה התעופה;
בהגדרה, לכל תקלה בשירות יש סיבת שורש הגורמת לה, גם אם ספק השירות אינו מודע לה או זיהה אותה.
יש סיבות שורש שאינן גורמות מיידית לתקלה. למשל: תקלה הנגרמת מאופן שימוש נדיר במוצר או בשירות יכולה להתגלות לאחר זמן רב של שימוש סטנדרטי במוצר/שירות.
לפעמים, הסרת גורם השורש אינה משתלמת כלכלית. במקרים אלה, נמצא מעקפים או אפילו נפתור בעיות בצורה מקומית כל פעם שהן קורות.
|
התהליך לטיפול בתקלות ומניעת הישנותן כולל שלושה תהליכים מרכזיים, המתחלקים לתהליכי משנה:
תהליך הכנת התשתית כולל שני תהליכי משנה:
המתודולוגיה מתארת את פונקציות הארגון המעורבות בפיתרון ומניעה של תקלות, השיטות והכלים בהם משתמשים, וכן את האחראים לטיפול במשימות לאורך מחזור חיי תקלה. בדרך כלל השיטה מתועדת בכתב, וכוללת גם הגדרה של מסגרת זמן מוגדר מראש לפיתרון התקלות.
השיטה מגדירה גם את התהליך שבו הלקוחות יכולים לדווח על תקלה ואת התהליך שבו משתפים את המדווחים על מצב התקלה ואופן הטיפול בה. כמו כן, השיטה מתארת תהליך לזיהוי הלקוחות שעלולים להיות מושפעים מהתקלה שהתגלתה, גם אם הם טרם גילו אותה, ואת אופן הטיפול בהם.
במקרים רבים, הארגון מקים מרכז שירות או מרכז תמיכה בלקוחות. פונקציה זו באה במגע עם הלקוחות, מקבלת את התלונות והתקלות, מספקת מעקפים, ומטפלת בתקלות. המאמר שלהלן מתמקד בטכניקה לאיתור בעיות השורש של התקלות ונקיטת פעולות כדי למנוע את הישנותן. יצויין שניהול שיטתי של מרכז שירות מטפל בנושאים נוספים, כגון: מניעת שחיקה של התומכים, אך נושאים אלה אינם בתכולת מאמר זה.
התקלות מסווגות במספר פרמטרים אורתוגונליים המסייעים בחיפוש הגורמים לתקלות, בהגדרת אופן הטיפול, ובמידת האסקלציה שנדרש לעשות:
מערכת לניהול תקלות כוללת כלים, שיטות ומדיה לאחסון ותיעוד התקלות ותהליך הטיפול בהם. המערכת יכולה להיות אוטומטית או ידנית. המערכת מאפשרת לאגור ולנתח נתונים היסטוריים, כגון תקלות שקרו, מעקפים שנעשו וכדומה. נתונים אלה מסייעים בניתוח ופיתרון התקלות החדשות.
תהליך ניהול התקלות עד לסגירתן, כולל חמישה תהליכי משנה:
התהליך כולל איסוף פרטים על הסביבה בה קרתה התקלה ואופן השימוש שגרם לתקלה.
זיהוי התקלה כולל ניתוח והבנת המקור של התקלה, למשל:
התיעוד כולל אפיון התקלה בהתאם לסוגי המאפיינים שנקבעו מראש: קטגוריות, עדיפות, חומרה וכדומה.
ניתוח התקלה יאפיין את אופן התגובה: החל מלא לעשות דבר ולהמשיך לנטר את האירוע, וכלה בהדרכת המשתמשים לגבי השימוש הנכון במוצר/שירות, הפעלת מעקף שכבר הוכן מראש, או כל פיתרון מוכר אחר להתמודדות עם התקלה.
פיתרון התקלה יתבסס על הניתוח שנעשה לתקלה. יתכן שהפיתרון שנבחר יפתור את התקלה באופן חלקי, או שלא יפתור אותה כלל. במקרים אלה, נדרש לחזור לשלב הניתוח, ולהעמיק כדי למצוא פיתרון שונה נוסף.
פיתרון באמצעות מעקף, או מיחזור של פיתרון שבוצע בעבר, יכול לשכך את הכאב של התקלה ולהשקיט את ההמולה, כדי שאפשר יהיה להקדיש את הזמן לפיתרון גורם השורש. במערכות גדולות עם תקלות מרובות (מה לעשות, קורה…) מומלץ לשקול להקים מאגר של מעקפים ופתרונות שבוצעו בעבר.
במידה וסופק פיתרון, מטרת הניטור הינה לתעד את הפעולות שנעשו ולוודא שאכן רמת השירות חזרה לעמוד בציפיות המשתמשים. כשמתקבל אישור על שביעות רצון מהלקוח, סוגרים את התקלה במערכת. במידה והתקלה לא נפתרה לשביעות רצון המשתמשים, יופעל מנגנון אסקלציה.
תקשורת עם בעלי העניין חשובה תמיד; חשיבות התקשורת עם מדווח התקלה ואלה המושפעים ממנה כל עוד לא נפתרה התקלה חשובה שבעתיים. כאשר משתפים את הלקוחות והמשתמשים במידע הקשור בתקלה הם יותר סלחניים ומסייעים. כמו כן, תיאום בין הצוות שהגדיר את פתרון התקלה לצוות שאחראי ליישם את הפתרון בשטח הינו חשוב ביותר כדי למזער את ההפרעה למתן השירות. אישור לסגירת התקלה מתקבל ממדווח התקלה לאחר אימות שהפיתרון אכן פתר את הבעיה. התקשורת עם בעלי העניין מתועדת לאורך כל מחזור חיי התקלה, כדי לא לאבד מידע, ולא לחזור על איסוף מידע שכבר נעשה. לאחר מכן, תיעשה תוכנית פעולה מקיפה ומעמיקה כדי להתמודד עם סיבות השורש.
מטרת תהליך זה היא לצמצם את הנזק מתקלות פוטנציאליות עתידיות. תהליך זה בוחר מספר תקלות ומנתח כיצד למנוע את הישנותן בעתיד. לאחר שמסוכמת דרך הפעולה ננקטות פעולות תיקון שורש על ידי "יוצרי התקלה". פעולות אלה, תורמות להפחתת כמות התקלות ובכך תורמות להעלאת שביעות הרצון של הלקוחות, והפחתת העומס על מרכז השירות/תמיכה בלקוחות. סיבת השורש במקרים רבים שונה מהסיבה שגרמה לתקלה. למשל: סיבת השורש לתקלה בשירות שנגרמת משבר באחד מרכיבי המוצר יכולה להיות תהליך ניהול דרישות לא אופטימאלי שלא ניתח נכון את העומסים הצפויים על אותו רכיב. תיקון התקלה המיידי יחליף את החלק השבור ואולי אף יוסיף מעקף שינתב את העומס לרכיב מקביל. תיקון השורש יכול לקחת זמן רב יותר.
תהליך העבודה על סיבות השורש מורכב משלושה תהליכי משנה:
תהליכי ניתוח סיבות השורש של התקלות נעשה עם הגורמים הרלוונטיים ש"יצרו" את התקלה. נעשית הערכת המשמעות של תיקון גורמי השורש. לעיתים, ניתוח עלות-תועלת של תיקון סיבת השורש, יכול ללמד, שמטעמים עסקיים, כדאי להסתפק במעקף. לכן, מומלץ לנהל מסד נתונים עם תיאורי התקלות, סיבותיהן ומעקפיהן, בהתאמה. בסופו של תהליך הניתוח יוחלט על אופן הפעולה.
מעקפים, הם הפיתרון האופטימאלי, כל עוד לא הוסרו גורמי השורש לתקלות. לכן נדרש ליצור מסד נתונים של תקלות ופתרונות הביניים שלהם. גם פיתרונות הביניים צריכים להיות מאומתים בשטח, ולקבל אישור שאכן הם פותרים את התקלה.
לאחר שהניתוח מצא את סיבות השורש, במידה והוחלט על ביצוע פעולות להפחתת תקלות עתידיות – הן מתוכננות ומבוצעות. התכנון מפרט תוכנית מה לעשות – מי? מה? מתי? לאחר מכן, מבצעים את התוכנית ועוקבים שאכן כמות התקלות יורדת.
תהליך תיקון תקלות מהשורש נועד להגדיל את שביעות רצון הלקוחות מאיכות השירות, ולהגדיל את יעילות התפעול של מרכז השירות ללקוח, כיוון שבטווח הארוך התהליך אמור להקטין את כמות התקלות. במידה ותהליך הפקת הלקחים נעשה בצורה מעמיקה, על ידי שיפור תהליכי הפיתוח והבקרה, יש סיכוי טוב שימנעו גם בעיות שטרם קרו.
התהליך שתואר לעיל נראה ברור מאליו. למרות זאת, תצפיותיי בארגונים השונים מראות שבודדים הארגונים שמשקיעים מאמץ בסילוק גורמי השורש. רובם מסתפקים בתיקון הבעיות לאחר שהן קרו.
מקור: CMMI For Services, Version 1.3, CMMI-SVC, V1.3, November 2010 – Incident Resolution and Prevention