תוכנה לניהול שירות

התחייבות הזמן, ולמה היא לא שדה

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

מכאן נגזרות שאלות שמערכת משימות לא יכולה לענות עליהן:

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

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

עצירת השעון: הפרט שמפיל את כל השאר

זה נראה כמו פרט קטן והוא קובע אם המערכת תהיה כלי או טקס.

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

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

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

שני המספרים שקודמים לקנייה

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

שירות שדה: למי בונים

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

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

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

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

מודול ב-ERP או מערכת נפרדת

אם השירות אצלכם הוא תמיכה בלבד, בטלפון או בהתכתבות, מודול ב-ERP בדרך כלל מספיק, וזו התשובה הזולה.

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

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

איך אני עובד על זה

עיסוק בתחום מאז 2004, עבודה על מערכות AI מאז 2023, פרויקטים ללקוחות בארבע עשרה מדינות. אני ארכיטקט עצמאי ולא מפיץ מערכות, ולכן המסקנה «אחוז התקלות החוזרות שלכם אומר שצריך דוח אחד ולא מערכת» היא תוצאה אפשרית, ובמדידות שעשיתי היא מופיעה לעתים קרובות.

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