ביישום שיטת ITIL אחת מנקודות התורפה של מערכת ניהול השירות (Service Management System; SMS) הוא שלב סיווג הפנייה (Categorization). קטגוריה (Category) של תקלה (Incident) או בעיה (Problem) מכונה לעתים בשם סימפטום (Symptom) וקטגוריה של בקשת שירות מכונה לעתים בשם הגדרת הבקשה (Service Request Definition; SRD) קביעת הקטגוריה בכל קריאה (Ticket) היא מושא למתח מתמיד בין הרצון להכניס אפשרויות רבות ומפורטות ככל שניתן מחד, והרצון להקל על הלקוח ולצמצם את רשימת הקטגוריות מאידך. להלן שני כללים פשוטים שיסייעו לכם לעצב את רשימת הקטגוריות:

danbert “השילוש הקדוש” – השתדלו לא לאפשר היררכיה בה יש יותר משלוש רמות.

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

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