ניהול ידע במוקד השירות - האתגרים, הפתרונות והטיפים

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

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

הפתרונות הקיימים בהם ארגונים משתמשים כיום:
הדרך הבולטת ביותר שעלתה בדיון - "שלשות" – פיתרון לסיווג קריאות. רוב הארגונים שנכחו בדיון ניצלו דרך סיווג זו לצורך הצפת פריטי תוכן וקישור בין הKM ל CRM (כ"כיבוי שריפה" שאפשר לחיות איתו בינתיים). 'שלשה' – מושג בתחום השירות שמשמעותו סיווג פניות של לקוחות. בעזרת היררכיה של שלוש רמות (סוג, קטגוריה, ותת-קטגוריה) מגדירים סיווג של תקלה. ניתן להשתמש בנושא השלשות על מנת לקשר תקלה לתחום תוכן רלוונטי ברמת URL (לדוגמה, קישור בין הCRM לתחום הידע הרלוונטי המנוהל במערכת ניהול מסמכים).
בנוסף, ארגונים משתמשים במערכות מדף שונות, כדוגמת מערכות ייעודיות ל- Knowledgebases או כאלה הכלולות במודול השירות של ה-CRM, מערכות שפותחו על גבי פורטל, שימוש במוצרי Rich Client / שולחן עבודה להצפת המידע הרלוונטי, כלי למידה/ "בועיות" שקופצות במערכת.

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

• אי אפשר לנהל הכל. כדאי לנסות להבין מה המידע הכי יקר לארגון, ואותו לנסות לנהל. מה הידע שהכי משתמשים בו? אם מצליחים להוריד שם את השיחות ההשפעה תהיה גדולה יותר.
• בדר"כ אחוז גדול מהפניות הנן פניות "תהליכיות" ולא טכניות (לדוגמה, באחד הארגונים ב 95% מהמקרים התמיכה היא תוכנית תהליכית - המשתמשים לא יודעים מה התהליך), במקרה והרבה תקלות הנן תקלות חוזרות, זמני השיחה במקרה זה ארוכים וזה בסדר כי משתמש שמקבל הסבר מקיף על הבעיה לומד ואז לא יפתח תקלה פעם הבאה. רואים את זה כסוג של הדרכה שיאפשר ירידה בבעיות חוזרות. במקרה זה שיטת המדידה של הנציגים צריכה לשקף זאת.
• לדעתי האישית, באופן כללי, ארגונים כיום לא מספיק שמים דגש על נושא פתיחת בסיס הידע החוצה ללקוחות חיצוניים - על מנת לאפשר גישה למידע בשיטת Self Service. ארגונים המתכננים לרוב מחפשים פיתרון טאקטי לצרכים פנים ארגוניים ולא מתכננים מראש את הצעד הבא – חשיפת אותו בסיס ידע לערוצים נוספים (האינטרנט הנו רק אחד מהם, בקרוב מאוד גם המובייל יהווה ערוץ חשוב לפחות לחלק ממידע זה). כלומר, בעתיד ייווצרו באותו ארגון "איים" של בסיסי מידע שונים לצרכים שונים שעלולים להיות לא מסונכרנים. במפגש שקיימנו, רוב הארגונים שנכחו במפגש לא הגיעו לשלב פתיחת בסיס הידע החוצה לWEB, והאווירה שעלתה היא שארגונים מעוניינים עד כמה שניתן לאפשר שירות עצמי בעיקר בשל מניע חיסכון בעלויות מוקד השירות, אך יחד עם זאת - קיימת זהירות רבה בנושא זה: ארגונים מעוניינים להגיע לשלב זה רק לאחר הטמעה מוצלחת ומוכחת של ניהול ידע פנים ארגוני (לנציגי השירות).
• במפגש עלתה דוגמה למתודולוגיה עולמית בתחום - KCS – Knowledge centered support, מתודולוגיה שלמה לאופן שבו מנהלים ידע במוקד שירות (נושא זה עלה בהקשר של מרכז שירות פנים ארגוני בתחום ה-IT). על פי מתודולוגיה זו התוכן נוצר תוך כדי פיתרון תקלות ומתפתח כל הזמן באופן שיתופי. פתרונות לבעיות יתועדו על ידי הנציגים, יש תהליך שנועד לאשר. לפי מתודולוגיה זו, יש בסיס של הדרכה אבל בשיטת המנהלת הרגילה (בה קיים גוף מרכזי שמעדכן את התכנים) הזמן שעובר מרגע שבעיה מופיעה עד שהיא מתועדת במלואה ארוך מדי. מתחילים למדוד את הרווח מהפיתרון בשלב מאוד מאוחר כי רק אז הוא מגיע למערכת. ואילו במתודולוגיה – KCS - הנציג אמור לחפש את הפיתרון במערכת ואם הוא לא מוצא – אמור למצוא פיתרון בעצמו, ותיעוד הפיתרון מחויב - אי אפשר לסגור קריאה עד שלא מתועד. צריך כתב טכני שמאשר את הפיתרון. זוהי מעין גישת "Web 2.0" של ניהול ידע (יותר ביזורי מאשר ריכוזי) – נותנים "בסיס" ומשחררים את התמיכה לשטח.