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

ITIL  מכסה את נושא הסיווג בצורה יפה. קיימות רשימות תיוג (checklists) ודוגמאות רבות בנוסף לסיוע הניתן מכל אחת ממערכות CRM העונות לדרישות ITIL.

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

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

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

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

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

אנא תנו תשומת לב מירבית לפשטות בתהליכי התחקור.

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

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

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

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

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

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

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

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

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

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

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

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

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

מעבר לסיווג על פיCI  או שירות, ניתן לכלול לפחות את שלושת השדות (שלשות) הבאים: סוג, קטגוריה, ותת קטגוריה. שדה סוג מסייע להתמקד בשירות הנדרש, ולעיתים מסייע גם בתעדוף הקריאה. ITIL  מכיל 3 סוגים בסיסים: כשל/פגם (fault), בקשת שירות (service request), בקשה לעזרה (assistance inquiry).

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

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

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

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

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

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

סיווג פשוט מסייע למערכת להיות יעילה וברת תועלות מרובות:

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

(מאמר זה מבוסס על מאמר של הנק מרקיז שהתפרסם ב-ITSMWatch.com)

Copyright © Calltec LTD All Rights Reserved. • טל: 5703167-02 • פקס: 5330175-02