תוכנה לניהול IT

שלוש בעיות, שלושה קצבים

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

המדידה שקודמת לקנייה

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

התוצאה תהיה אחת משתיים, ולכל אחת מסקנה אחרת:

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

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

מצאי: למה להתחיל ממנו ואיך לבדוק אותו

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

ובדיקת תקינות של מצאי נעשית בשני כיוונים, ובדרך כלל עושים רק אחד:

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

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

למה מערכת קריאות נזנחת, ומה מונע את זה

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

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

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

רישיונות ומנויים: החלק שמתגלה מאוחר

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

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

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

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

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

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

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