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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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