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

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

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

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

מהי תקלה?

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

מהו תהליך לטיפול בתקלות ומניעת הישנותן?  

התהליך כולל את הפעילויות הבאות:

1. מתן פיתרון מיידי ללקוח

·                 זיהוי וניתוח התקלות;

·                 ביצוע פעילות ממוקדת לפיתרון התקלה; הפחתת ההשפעה של התקלה למינימום

·                 מציאת פיתרון מהיר או מעקף כדי להחזיר במהירות את יכולת השימוש במוצר או בשירות;

·                 מעקב ובקרה על מצב התקלה וביצוע אסקלציה בהתאם לצורך;

·                 הודעה לבעלי עניין על סטאטוס התקלה;

·                 בדיקה ואישור עם בעלי העניין שאכן הבעיה תוקנה.

2. תיקון יסודי של התקלה

·                 מעקב אחר האירועים או סיבות השורש שגורמים לבעיה;

·                 זיהוי וניתוח גורמי השורש;

·                 הסרת גורמי השורש.

מהי תקלה במתן שירות?

להלן שני סוגים מרכזיים:

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

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

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

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

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

ניהול שיטתי של פיתרון תקלות ומניעתן

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

1. הכנה תשתית לפיתרון ומניעה של תקלות

תהליך הכנת התשתית כולל שני תהליכי משנה:

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

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

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

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

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

·                 הגדרה של סוגי תקלות

·                 רמת עדיפות לגבי פיתרון התקלות

·                 חלוקת התקלות לקטגוריות ורמות חומרה.

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

ב. מיסוד מערכת לניהול התקלות

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

2. זיהוי, טיפול ובקרה בתקלות

תהליך ניהול התקלות עד לסגירתן, כולל חמישה תהליכי משנה:

א.  זיהוי ותיעוד התקלות

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

זיהוי התקלה כולל ניתוח והבנת המקור של התקלה, למשל:

·                 האם דווחה על ידי הלקוח? משתמש קצה? מערכת אוטומטית?

·                 האם מדובר בתקלה שנובעת מאי הבנה או שימוש לא נכון?

·                 מה היה התרחיש המדויק שגרם לתקלה?

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

ב. ניתוח התקלות

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

ג. פיתרון התקלה

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

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

ד. ניטור התקלה עד לסגירתה

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

ה. דיווח על מצב התקלה לבעלי העניין

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

3. ניתוח סיבות השורש שגרמו לתקלה ופתירתן

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

תהליך העבודה על סיבות השורש מורכב משלושה תהליכי משנה:

א. ניתוח מספר תקלות נבחרות

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

ב. מיסוד פתרונות שיתנו מענה לתקלות עתידיות

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

ג. מיסוד פתרונות להפחתת תקלות עתידיות

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

כמה מילים לסיכום

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

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

מקור:   CMMI For Services, Version 1.3, CMMI-SVC, V1.3, November 2010 – Incident Resolution and Prevention