WEBVTT

00:00:00.000 --> 00:00:01.940
מערכת כרטיסים נראית מצוין על הנייר.

00:00:02.060 --> 00:00:04.160
מקבלים מספרים, תורים ולוחות בקרה.

00:00:04.300 --> 00:00:08.120
אך במציאות, המודל הזה מודד את הכאב רק אחרי שהמערכת כבר קרסה.

00:00:08.240 --> 00:00:10.880
החלק היקר בבעיה מתחיל בדרך כלל הרבה קודם.

00:00:11.020 --> 00:00:14.380
זה מתחיל כשעובד מאבד 10 דקות, אחר כך 20, ובסוף פשוט מבטר.

00:00:14.500 --> 00:00:15.260
הם מנסים שוב.

00:00:15.420 --> 00:00:16.480
הם שואלים עמית לעבודה.

00:00:16.660 --> 00:00:20.080
הם מפספסים את הפגישה או משתפים את הקובץ הלא נכון כי הדרך הנכונה הפסיקה לעבוד.

00:00:20.080 --> 00:00:22.560
וזה החלק שרוב צוותי התמיכה עדיין לא רואים.

00:00:22.700 --> 00:00:26.040
המודל הטוב ביותר לתמיכה פנימית כיום אינו עוסק במיון מהיר יותר.

00:00:26.220 --> 00:00:28.420
הוא עוסק בביטול הצורך במיון לחלוטין.

00:00:28.600 --> 00:00:32.940
דמיינו סוכן אוטונומי בתוך מייקרוסופט 365 שצופה בהקשר,

00:00:33.220 --> 00:00:37.120
מזהה חיכוך מוקדם ופועל לפני שאדם בכלל חושב לפתוח פורטל.

00:00:37.300 --> 00:00:40.760
בפרק הזה אני רוצה להראות לכם למה מודל ההילפדסק נשבר,

00:00:41.020 --> 00:00:44.040
מה באמת מחליף אותו ואיך אפשר לנהל את זה בלי ליצור קאוס.

00:00:44.040 --> 00:00:46.000
אם השינוי הזה חשוב לעבודה שלכם,

00:00:46.180 --> 00:00:49.160
הרשמו להם 365FM כי ברמה אחת עמוק יותר,

00:00:49.360 --> 00:00:51.700
הבעיה האמיתית היא לא התור, אלא המודל שמאחוריו.

00:00:51.820 --> 00:00:52.820
מותו של הכרטיס.

00:00:53.020 --> 00:00:55.360
זרימת התמיכה הישנה עדיין נמצאת בכל מקום.

00:00:55.500 --> 00:00:56.240
מה שהוא נשבר.

00:00:56.460 --> 00:00:57.520
משתמש מבחין בזה.

00:00:57.680 --> 00:00:59.260
המשתמש מנסה להסביר את זה.

00:00:59.420 --> 00:01:01.820
ואז העית מתרגם את ההסבר הזה לקטגוריה,

00:01:02.040 --> 00:01:03.700
עדיפות ואולי קבוצת שיוך.

00:01:03.880 --> 00:01:05.140
הבעיה נכנסת לתור.

00:01:05.320 --> 00:01:06.360
מי שהוא עושה למיון.

00:01:06.360 --> 00:01:08.220
מי שהוא אחר מבקש פרטים נוספים.

00:01:08.340 --> 00:01:09.520
צוות נוסף מעורב.

00:01:09.660 --> 00:01:12.340
הזמן ממשיך לרוץ בעוד העבודה עצמה נשארת תקועה.

00:01:12.420 --> 00:01:14.580
התהליך הזה מרגיש נורמלי כי הוא מוכר,

00:01:14.720 --> 00:01:16.440
אבל מוכר ויעיל הם לא אותו דבר.

00:01:16.620 --> 00:01:17.740
כרטיס הוא לא תמיכה.

00:01:17.860 --> 00:01:20.300
כרטיס הוא עדות לכך שהתמיכה הגיעה באיחור.

00:01:20.500 --> 00:01:21.840
עד שכרטיס בכלל קיים,

00:01:22.040 --> 00:01:24.320
העובד כבר נתקע ואיבד את ההקשר שלו.

00:01:24.460 --> 00:01:27.720
הם כבר הסיתו את תשומת הלב שלהם מהעבודה שהם ניסו לעשות.

00:01:27.920 --> 00:01:28.960
התור הוא לא השירות.

00:01:28.960 --> 00:01:30.640
התור הוא רישום של כישלון.

00:01:30.780 --> 00:01:33.000
בסביבות מייקרוסופט 365 גדולות,

00:01:33.000 --> 00:01:34.940
מיון ידני הופך לצוואר הבקבוק האמיתי.

00:01:35.120 --> 00:01:36.940
זה לא קורה כי צוותי התמיכה עצלנים.

00:01:37.160 --> 00:01:41.100
זה קורה כי מבקשים מבני אדם לעשות משהו שכבר לא מתאים לקני המידה של הסביבה.

00:01:41.240 --> 00:01:44.600
יש לכם יותר משתמשים, יותר מכשירים, יותר אפליקציות, יותר מדיניות.

00:01:44.760 --> 00:01:47.040
יש לכם יותר מקרי קצה שחוצים צוותים,

00:01:47.220 --> 00:01:50.080
SharePoint, Exchange, Intune ו-Entra בו זמנית.

00:01:50.200 --> 00:01:52.540
הנפח לא רק גדל, השילובים גדלים.

00:01:52.800 --> 00:01:54.320
שם המודל הישן נשבר.

00:01:54.320 --> 00:01:56.560
רוב הצוותים מגיבים בהוספת מבנה.

00:01:56.560 --> 00:01:59.560
הם בונים עוד פורטל, עוד בוט, או עוד כלל ניתוב.

00:01:59.700 --> 00:02:03.740
אך במציאות, זה רק מוסיף עוד שכבה אחת בין העובד לבין הפתרון.

00:02:03.920 --> 00:02:06.900
המערכת עדיין ממתינה שהמשתמש יבחין בבעיה,

00:02:07.200 --> 00:02:09.380
יתאר אותה ויבקש עזרה בדרך הנכונה.

00:02:09.540 --> 00:02:11.480
העבודה לא מתחילה בפורטל תמיכה,

00:02:11.680 --> 00:02:13.340
היא מתחילה בטימס, באטלוק,

00:02:13.580 --> 00:02:15.300
במסמך שמישהו צריך ברגע זה,

00:02:15.480 --> 00:02:17.440
או בפגישה שמתחילה בעוד 30 שניות.

00:02:17.440 --> 00:02:19.480
שם למעשה מתחיל הצורך בתמיכה,

00:02:19.480 --> 00:02:22.020
ומודל הכרטיסים מנותק לחלוטין מהרגע הזה.

00:02:22.180 --> 00:02:25.140
העלות הנסתרת גדולה בהרבה ממה שדוח התורים שלך מראה.

00:02:25.260 --> 00:02:26.600
אנשים עוברים בין הקשרים.

00:02:26.840 --> 00:02:28.900
אירועים כפולים נערמים תחת תוויות שונות.

00:02:29.100 --> 00:02:30.900
מאמרי ידע הופכים ללא רלוונטיים.

00:02:31.120 --> 00:02:32.960
אנליסטים מבלים את כל יומם במיון,

00:02:33.200 --> 00:02:35.480
ניתוב וברור במקום בתיקון דברים בפועל.

00:02:35.660 --> 00:02:38.680
זמן הטיפול מתארך כי כל העברה מוסיפה עיכוב,

00:02:38.680 --> 00:02:41.000
וכל עיכוב גורע מההקשר המקורי.

00:02:41.000 --> 00:02:44.980
מחקרים על בינה מלאכותית, סוכנת ותפעול אית מצביעים על אותה בעיה מבנית.

00:02:45.140 --> 00:02:49.100
לפחות 80% מהמאמץ עדיין קלו בעבודה הראקטיבית בסגנון ITIL.

00:02:49.260 --> 00:02:52.260
המספר הזה חשוב כי הוא אומר לך בדיוק לאן הולכת העבודה.

00:02:52.420 --> 00:02:55.100
היא לא הולכת לחוסן או למניעה, היא הולכת לתגובה.

00:02:55.220 --> 00:02:56.060
ברגע שרואים זאת,

00:02:56.180 --> 00:02:59.380
הכרטיס מתחיל להיראות פחות כמו מודל תפעולי, ויותר כמו תסמין.

00:02:59.380 --> 00:03:02.660
זהו תסמין למערכת שמגיבה רק לאחר שהנזק גלוי לעין.

00:03:02.660 --> 00:03:05.360
לכן, השאלה הבאה היא לא איך לאבד כרטיסים מהר יותר,

00:03:05.580 --> 00:03:08.060
אלא מה המערכת צריכה לעשות לפני שכרטיס בכלל נדרש.

00:03:08.180 --> 00:03:09.660
מודל העובד הבלתי נראה.

00:03:09.760 --> 00:03:11.360
אז מה באמת מחליף את הכרטיס?

00:03:11.560 --> 00:03:14.220
זה לא סתם עוד שדבות שיושב על גבי אותו הבלגן,

00:03:14.440 --> 00:03:17.180
וזה בטח לא דלת כניסה יפה יותר לאותו תור ישן.

00:03:17.340 --> 00:03:20.860
השינוי עמוק הרבה יותר כי העובד הבלתי נראה הוא עובד תפעולי

00:03:20.860 --> 00:03:24.020
שחי בתוך סביבת מייקרוסופט 365 שלך.

00:03:24.180 --> 00:03:25.800
לסוכן הזה יש זהות משלו,

00:03:25.800 --> 00:03:28.540
היקף עבודה מוגדר, זיכרון של מה שעשה אתמול,

00:03:28.800 --> 00:03:31.040
וכללים נוקשים לגבי מה הוא יכול או לא יכול לגעת.

00:03:31.100 --> 00:03:32.660
להבחנה הזו יש משמעות.

00:03:32.860 --> 00:03:34.480
שדבות מחכש את הקליד הנחיע,

00:03:34.760 --> 00:03:37.200
אבל עובד בלתי נראה עוקב אחר שינויים בתנאים.

00:03:37.380 --> 00:03:39.720
הוא מתחיל מהקשר במקום להתחיל משיחה.

00:03:39.860 --> 00:03:41.780
מכיוון שהוא יכול לראות מצבי התחברות,

00:03:41.940 --> 00:03:44.960
תקינות מכשירים, סטטוס רישיונות ואיך קבצים משותפים,

00:03:45.120 --> 00:03:46.660
הוא לא צריך לחכות להופעת חיכוך.

00:03:46.660 --> 00:03:49.660
במקום לשאול איך הוא יכול לעזור אחרי שמשהו נשבר,

00:03:49.660 --> 00:03:51.780
הוא שואל ללא הרף שאלה אחרת ברקע.

00:03:51.880 --> 00:03:55.680
מה שותה מהמצב שהעובד הזה צריך כדי לבצע את עבודתו כרגע?

00:03:55.840 --> 00:03:57.480
זה המקום שבו דברים משתנים.

00:03:57.700 --> 00:04:00.060
המודל מוטמע ישירות בתוך העבודה עצמה.

00:04:00.260 --> 00:04:03.020
שמי שהוא מצטרף לפגישה וניתוב האודיו נכשל,

00:04:03.240 --> 00:04:06.080
או שאורך לא יכול לפתוח קובץ שזה עתה נשלח אליו,

00:04:06.300 --> 00:04:08.340
העולם הישן יוצר דוח והעברה.

00:04:08.460 --> 00:04:11.300
במודל החדש, הסוכן מזהה את הדפוס באופן מיידי,

00:04:11.300 --> 00:04:15.640
בודק אם התנאי תואם בעיה מוכרת ונוקט בפעולה הבטוחה הבאה כדי לתקן אותה.

00:04:15.720 --> 00:04:18.080
אולי הוא מאפס נתיב או מפעיל בדיקת מדיניות,

00:04:18.280 --> 00:04:22.100
או שאולי הוא מנתב מחדש בקשה ומפעיל אימות רב גורמי לפני תיעוד התיקון.

00:04:22.240 --> 00:04:23.180
הנקודה פשוטה.

00:04:23.320 --> 00:04:27.620
התגובה הראשונית כבר לא דורשת מאדם לקרוא תיאור מאורפל ולנחש מה קרה.

00:04:27.800 --> 00:04:29.760
זה מרגיש בלתי נראה כשהכל עובד טוב,

00:04:29.960 --> 00:04:31.500
כי אין חדר המתנה ואין תופס,

00:04:31.500 --> 00:04:33.080
ענה בחר קטגוריה למילוי.

00:04:33.080 --> 00:04:35.080
התמיכה מופיעה כזרימה משוחזרת.

00:04:35.240 --> 00:04:36.560
העובד פשוט חוזר לעבודה,

00:04:36.820 --> 00:04:39.920
ובמקרים רבים הוא אפילו לא רואה את המנגנון שפועל מאחורי הקלעים.

00:04:40.120 --> 00:04:43.560
אתם כבר יכולים לראות איך זה משנה את הלוגיקה של כוח האדם שלכם.

00:04:43.700 --> 00:04:46.080
המודל הישן סוחר אנשים כדי לספוג נפח,

00:04:46.240 --> 00:04:48.940
למיין בקשות ולנקות הקשרים שבורים בין צוותים שונים.

00:04:49.140 --> 00:04:53.380
המודל החדש זקוק לפחות אנשים שעוסקים במיון ויותר אנשים שמתכננים מגבלות,

00:04:53.380 --> 00:04:56.720
מגדירים מצבים רצויים ומפקחים על התנהגות הסוכנים לאורך זמן.

00:04:56.880 --> 00:04:58.500
בני אדם נשארים במערכת,

00:04:58.660 --> 00:05:00.640
אך כל צורת עבודתם היומיומית משתנה.

00:05:00.800 --> 00:05:03.220
מחקר על בינה מלאכותית, סוכנית בתחום התמיכה,

00:05:03.300 --> 00:05:04.580
ממשיך להצביע לכיוון הזה.

00:05:04.720 --> 00:05:07.560
תמיכה שגרתית יכולה לעבור לטיפול מבוסס חריגים,

00:05:07.820 --> 00:05:09.480
מה שיוצר רווחי יעילות עצומים,

00:05:09.580 --> 00:05:11.820
כאשר הסביבה והמדיניות מוגדרות היטב.

00:05:11.960 --> 00:05:14.360
החלק האחרון הזה חיוני כי זה לא קסם.

00:05:14.360 --> 00:05:17.460
אם הנתונים שלכם חלשים או התהליך שלכם מבולגן,

00:05:17.660 --> 00:05:20.560
הסוכן לא יהפוך לחכם רק כי החלטתם לקרוא לו אוטונומי.

00:05:20.660 --> 00:05:24.040
הכל התחבר לי כשהפסקתי לחשוב על הסוכן כתכונת תוכנה,

00:05:24.180 --> 00:05:26.720
והתחלתי לראות בו עובד לא אנושי עם טאג עובד.

00:05:26.900 --> 00:05:31.080
עובד אמיתי זקוק לזהות, תיאור תפקיד, הרשאות ומנהל לדווח לו.

00:05:31.200 --> 00:05:33.080
הסוכן זקוק בדיוק לאותם דברים,

00:05:33.380 --> 00:05:35.360
כי הערך נובע מפעולה המינה בתוך מערכת,

00:05:36.020 --> 00:05:37.500
לא מספה חכמה בחלון שט.

00:05:37.500 --> 00:05:40.360
העובד הבלתי נראה אינו טריק של ממשק משתמש.

00:05:40.540 --> 00:05:44.500
זוהי שכבת תמיכה חדשה שמשגיחה על חיכוך ברחבי סביבת מייקרוסופט 365,

00:05:45.160 --> 00:05:49.560
פועלת במסגרת המדיניות ומעבירה את תשומת הלב האנושית לחריגים שבאמת דורשים שיקול דעת.

00:05:49.620 --> 00:05:52.860
ברגע שהמודל הזה ברור, השאלה הבאה הופכת למעשית מאוד.

00:05:53.020 --> 00:05:54.300
איך מניעה באמת עובדת?

00:05:54.580 --> 00:05:55.980
הארכיטקטורה של המניעה.

00:05:56.060 --> 00:05:59.220
אז, איך מניעה באמת עובדת בתוך מייקרוסופט 365?

00:05:59.740 --> 00:06:02.980
השינוי עובר מבקשה ותגובה להסקה על אירועים ותזמור.

00:06:03.160 --> 00:06:06.120
זה נשמע טכני, אבל המודל פשוט ברגע שמפרקים אותו.

00:06:06.260 --> 00:06:07.700
ראשית, מה שהוא בסביבה משתנה,

00:06:07.900 --> 00:06:10.920
לאחר מכן המערכת מפרשת אם השינוי הזה אומר סיכון או סטייה,

00:06:11.100 --> 00:06:14.920
ולבסוף, היא נוקטת בפעולה המאושרת באמצעות הכלים שכבר נמצאים בערימה שלכם.

00:06:15.020 --> 00:06:16.400
נתחיל בשכבת האירועים.

00:06:16.400 --> 00:06:19.480
מייקרוסופט 365 כבר מייצר אותות בכל מקום,

00:06:19.480 --> 00:06:24.180
מה שאומר שאינטרה רואה התנהגות התחברות בעוד אינטון עוקב אחר מצב המכשיר והציעות לנהלים.

00:06:24.360 --> 00:06:25.940
דפנדר מחפש פעילות חשודה,

00:06:26.220 --> 00:06:29.700
וטאמס מראה לך בדיוק מתי פגישה נכשלת או שאיכות השיחה יורדת.

00:06:29.800 --> 00:06:32.800
שירפוינט ואקסצ'יינג' חושפים דפוסי גישה ופעילות תוכן,

00:06:33.000 --> 00:06:36.280
בעוד אותות בריאות השירות מדווחים לך מתי הבעיה היא בפלטפורמה עצמה.

00:06:36.280 --> 00:06:39.980
כשמוסיפים לכך פעולות משתמש, מקבלים זרם קבוע של הקשר.

00:06:39.980 --> 00:06:42.180
רוב הארגונים אוספים את האותות הללו,

00:06:42.240 --> 00:06:44.800
אך מעטים מאוד משתמשים בהם בפועל כמערכת תמיכה.

00:06:44.940 --> 00:06:46.620
אירועים גולמיים בלבד אינם עוזרים,

00:06:46.840 --> 00:06:49.200
כי נדרשת שכבת השכה כדי להבין את הרעש.

00:06:49.340 --> 00:06:53.520
כאן הופך העובד הבלתי נראה מתיאטרון של אוטומציה למפעיל אמיתי.

00:06:53.680 --> 00:06:57.180
הסוכן בוחן את האות, משווה את המצב הנוכחי למצב הרצוי,

00:06:57.180 --> 00:06:59.400
ומחליט איזה סוג פעולה בטוח לביצוע.

00:06:59.540 --> 00:07:02.360
בעיית שמה בפגישה אינה זהה להתחברות מסוכנת,

00:07:02.360 --> 00:07:05.080
וקישור שיתוף שבור שונה מאי התאמה ברישוי.

00:07:05.200 --> 00:07:07.140
הסוכן חייב לסווג את הבעיה תחילה,

00:07:07.320 --> 00:07:09.920
כי פעולה ללא סיווג רק מייצרת טעויות מהר יותר.

00:07:10.140 --> 00:07:11.780
לאחר מכן מגיעה האורקסטרה.

00:07:11.940 --> 00:07:13.340
ברגע שהסוכן מבין את הבעיה,

00:07:13.520 --> 00:07:15.600
הוא יכול להשתמש במנגנון הנכון כדי להגיב.

00:07:15.760 --> 00:07:17.660
זה עשוי להיות Power Automate לזרימות עבודה,

00:07:17.660 --> 00:07:18.940
Copilot Studio ללוגיקה,

00:07:19.060 --> 00:07:21.000
או Microsoft Graph לפעולות מערכת והקשר.

00:07:21.140 --> 00:07:24.580
הכלים חשובים, אך הנקודה המרכזית היא האופן שבו הם מתחברים זה לזה.

00:07:24.580 --> 00:07:26.360
אתה לא בונה הנחיה חכמה אחת,

00:07:26.480 --> 00:07:29.300
אלא שרשרת שיכולה לזהות, להחליט, לפעול ולאמת.

00:07:29.480 --> 00:07:31.580
החלק האחרון הזה מתפספס כל הזמן.

00:07:31.800 --> 00:07:35.080
מערכת שמתקנת את עצמה לא עוצרת ברגע שהפעולה מבוצעת.

00:07:35.200 --> 00:07:37.360
היא מריצה לולאה שבה היא מזהה את הבעיה,

00:07:37.620 --> 00:07:38.500
בודקת את התנאי,

00:07:38.740 --> 00:07:41.720
מיישמת את התיקון ומאמת את התוצאה לפני תיעוד המקרה.

00:07:41.720 --> 00:07:43.620
מחקר על לוגיקה של תיקון עצמי

00:07:43.620 --> 00:07:46.860
מבהיר שמערכות אלו עובדות דרך דפוסי משוב ותיקון,

00:07:46.860 --> 00:07:49.200
ולא על בסיס תשובה בודדת ממודל שפה.

00:07:49.360 --> 00:07:50.720
אם הפעולה הראשונה נכשלת,

00:07:50.880 --> 00:07:52.680
המערכת זקוקה לדרך להאריך מדוע

00:07:52.680 --> 00:07:55.860
כדי שתוכל לעדכן את הצעד הבא תוך שמירה על מגבלות מוגדרות.

00:07:56.040 --> 00:07:59.240
אפשר לתאר זאת בבירור בכמה מקרי שימוש של מייקרוסופט 365.

00:07:59.740 --> 00:08:03.200
כאשר משתמש נחסם בגלל אי התאמה בין הרישיון לבין היקף המדיניות,

00:08:03.200 --> 00:08:06.040
הסוכן מזהה את הבעיה ובודק את פרופיל התפקיד המיועד.

00:08:06.140 --> 00:08:07.520
הוא מיישם את התיקון המורשה,

00:08:07.520 --> 00:08:09.240
מוודא של המשתמש יש גישה,

00:08:09.440 --> 00:08:11.900
ומתעד את השינוי מבלי שאף אחד יצטרך לבקש זאת.

00:08:12.000 --> 00:08:13.940
אם מופיעה התחברות מסוכנת באנטרה,

00:08:14.180 --> 00:08:17.780
הסוכן רואה את אירוע הסיכון ובודק מיד את כללי הגישה המותנת שלך.

00:08:17.920 --> 00:08:21.240
הוא מבקש עימות חזק יותר או חוסם גישה בהתאם למדיניות שלך,

00:08:21.520 --> 00:08:23.920
ואז מתעד את התוצאה לבדיקה אנושית בהמשך.

00:08:23.920 --> 00:08:27.060
כאשר קישור שיתוף מיושן ממשיך להיקשל בשורפוינט,

00:08:27.240 --> 00:08:30.400
הסוכן משווה את נתיב ההרשאות הנוכחי לכללי השיתוף הצפויים.

00:08:30.560 --> 00:08:32.780
הוא מחליף את השורש השבור בשורש המאושר,

00:08:32.860 --> 00:08:35.180
ושולח את הקישור המתוקן בהקשר הרלוונטי,

00:08:35.440 --> 00:08:37.820
מה שסוגר את המעגל לפני שאנליסט תמיכה בכלל,

00:08:37.940 --> 00:08:40.320
צריך לקרוא כרטיס שכותרתו בעיית גישה דחופה.

00:08:40.420 --> 00:08:42.620
תמיכה בפגישות היא דוגמה מצוינת נוספת.

00:08:42.780 --> 00:08:46.500
אם התקן בחדר נכשל או שנתיב הצטרפות משתבש שניות לפני תחילת שיחה,

00:08:46.500 --> 00:08:48.840
הסוכן יכול לזהות את המצב ולאמת את התקלה.

00:08:48.980 --> 00:08:50.700
הוא מנסה צעד התאוששות בסיכון נמוך,

00:08:50.700 --> 00:08:54.420
ומודיע למארגן בטימס עם עדכון סטטוס ישירות במקום שבו העבודה מתבצעת.

00:08:54.480 --> 00:08:57.040
שכבת התקשורת הזו היא חלק משמעותי מהעיצוב.

00:08:57.240 --> 00:08:59.820
התמיכה חייבת להתקיים במקום שבו מתרחשת ההפרעה.

00:08:59.960 --> 00:09:01.480
אם העבודה שלך מתבצעת בטימס,

00:09:01.600 --> 00:09:03.980
באטלוק ובסביבת העבודה של M365,

00:09:04.260 --> 00:09:05.740
אז התמיכה צריכה לענות לך גם שם.

00:09:05.740 --> 00:09:09.820
אסור לך לגרור את המשתמש למקום אחר כשאפשר לפגוש את האירוע בהקשר שלו.

00:09:09.920 --> 00:09:12.780
כל זה לא אומר אוטומציה מלאה בכל משימה ומשימה,

00:09:12.780 --> 00:09:13.880
כי זה יהיה פזיז.

00:09:14.020 --> 00:09:16.200
פעולות בסיכון נמוך יכולות להתבצע אוטומטית,

00:09:16.400 --> 00:09:18.960
אך שינויים בעלי השפעה גבוהה עדיין דורשים אישור מאדם.

00:09:19.100 --> 00:09:22.180
נתיב אישור זה חייב להיות חלק מהארכיטקטורה מההתחלה,

00:09:22.400 --> 00:09:23.800
במקום להוסיף אותו מאוחר יותר.

00:09:24.020 --> 00:09:25.660
הסוכן צריך לדעת מתי לפעול,

00:09:25.660 --> 00:09:27.920
מתי לבקש אישור ומתי בדיוק לעצור.

00:09:28.040 --> 00:09:30.220
וברגע שאתה בונה את זה לתוך התהליך,

00:09:30.440 --> 00:09:32.500
השיחה מפסיקה לעסוק בתכונות אוטומציה.

00:09:32.660 --> 00:09:36.260
היא הופכת לשיחה על שליטה, ממשל, אמון וזהות הסוכן.

00:09:36.260 --> 00:09:40.300
כאשר התמיכה מתחילה לפעול בעצמה, עולה מיד שאלה קשה.

00:09:40.460 --> 00:09:41.960
מי באמת מבצע את העבודה?

00:09:42.160 --> 00:09:44.920
אם התשובה לכך מאורפלת, המודל כולו קורס.

00:09:45.120 --> 00:09:49.680
סוכן לא יכול להתקיים בסביבה שלך כעוזר מאורפל עם גישה רחבה וללא בעלים ברור.

00:09:49.680 --> 00:09:51.600
הוא זקוק לזהות אמיתית באנטרה.

00:09:51.740 --> 00:09:56.580
הוא צריך בעלים מוגדר, היקף מוגדר ומחזור חיים שמתחיל ומסתיים מסיבה ספציפית.

00:09:56.660 --> 00:10:01.100
אם הסוכן הזה יכול לקרוא נתונים, להפעיל תהליכי עבודה או לשלוח הודעות למשתמשים שלך,

00:10:01.100 --> 00:10:03.120
עליך לנהל אותו כמשתתף פעיל בטנן.

00:10:03.260 --> 00:10:06.640
אתה לא יכול להתייחס אליו כמו אל תכונה שמישהו הפעיל ושכח ממנה.

00:10:06.760 --> 00:10:09.260
לכן זהות הסוכן היא כל כך קריטית למערכת.

00:10:09.420 --> 00:10:12.360
עליך לדעת בדיוק מהו הסוכן, באילו מערכות הוא יכול לגעת,

00:10:12.360 --> 00:10:14.440
ומי מקבל את הקריאה כשדברים מתחילים להשתבש.

00:10:14.540 --> 00:10:17.220
העקרון של הרשאות מינימליות חייב להיות קו הבסיס כאן.

00:10:17.340 --> 00:10:21.360
אתה לא יכול להסתפק בנוחות רחבה או לומר לעצמך שתהדק את ההרשאות מאוחר יותר.

00:10:21.360 --> 00:10:25.200
מכיוון שרדיוס הנזק של סוכן תמיכה תלוי לחלוטין בהרשאות שלו,

00:10:25.440 --> 00:10:28.140
עיצוב ההרשאות הללו הוא חלק מרכזי בעיצוב התמיכה.

00:10:28.280 --> 00:10:32.160
אייג'נט 365 משמש כשכבת בקרה הכרחית במערך הזה,

00:10:32.420 --> 00:10:34.940
כי הוא מאפשר תצוגה ברורה של כלל סביבת הסוכנים.

00:10:35.120 --> 00:10:40.040
הוא מספק את הרישום, תהליכי האישור ותבניות המדיניות ששומרים על התנהלות בטוחה.

00:10:40.140 --> 00:10:43.160
אף שהרכיבים האלה עשויים להישמע כמו מטלות מנהלתיות,

00:10:43.420 --> 00:10:44.840
הם פותרים בעיה מבנית עצומה.

00:10:44.840 --> 00:10:47.840
רוב הארגונים לא מתקשים בגלל חוסר בבינה מלאכותית,

00:10:48.060 --> 00:10:51.260
אלא כי הם לא מסוגלים לראות או לשלוט במה שכבר רץ בסביבה שלהם.

00:10:51.420 --> 00:10:53.240
המחקר בנושא זה חד משמעי.

00:10:53.400 --> 00:10:58.700
רק מיעוט קטן מהארגונים הגדולים מסוגל למפות באופן מלא כל סוכן שרץ כרגע במערכת שלו.

00:10:58.800 --> 00:11:01.520
לפני שמנהיגים מתחילים לדבר על הרחבת תמיכה אוטונומית,

00:11:01.720 --> 00:11:03.580
עליהם להשיב על שאלה פשוטה הרבה יותר.

00:11:03.760 --> 00:11:07.100
האם אנחנו בכלל יודעים אילו סוכנים קיימים ומה הם עושים ברגע זה?

00:11:07.100 --> 00:11:10.100
הפיקוח חייב גם להתאים לרמת הסיכון הכרוכה בדבר.

00:11:10.260 --> 00:11:13.060
סוכן פרודוקטיביות אישי שעובד בתחום צר הוא דבר אחד,

00:11:13.300 --> 00:11:16.220
אך סוכן שיתופי שנוגע בתוכן משותף הוא עניין אחר לגמרי.

00:11:16.360 --> 00:11:19.780
לאחר מכן ישנם סוכנים ארגוניים שפועלים בתוך תהליכי עבודה רגישים,

00:11:19.980 --> 00:11:21.500
מה שנמצא בקטגוריית סיכון אחרת.

00:11:21.640 --> 00:11:25.280
זו הסיבה שמודל אזורי הסיכון אישי, שיתופי וארגוני הוא כה חשוב.

00:11:25.480 --> 00:11:28.460
מודל הבקרה שלך צריך לעלות בהתאם להשפעה האפשרית.

00:11:28.460 --> 00:11:30.320
אם תתייחס לכל סוכן באותו אופן,

00:11:30.440 --> 00:11:32.620
עבודה בסיכון נמוך תיקבר תחת אישורים איתיים,

00:11:32.820 --> 00:11:35.180
בעוד עבודה בסיכון גבוה תחמוק ללא בקרה מספקת.

00:11:35.320 --> 00:11:39.820
לפחות, מערך הבקרה שלך במיקרוסופט 365 צריך להיות מוכר לצוות שלך.

00:11:39.960 --> 00:11:41.460
אתם משתמשים בזהות באנטרה,

00:11:41.680 --> 00:11:44.340
בגבולות נתונים דרך פורוויו ובניטור דרך דפנדר.

00:11:44.500 --> 00:11:46.960
אתם מכילים תנאי גישה דרך גישה מותנת,

00:11:47.060 --> 00:11:49.660
ומבדאים שהיכולת לביקורת מוטמעת מההתחלה.

00:11:49.660 --> 00:11:54.440
עליכם להיות מסוגלים לשחזר בדיוק מה קרה מבלי לנחש לאחר התרחשות אירוע.

00:11:54.560 --> 00:11:58.740
פיקוח אנושי צריך להיות מתוכנן לתוך הלוגיקה ולא מעולתר במהלך משבר.

00:11:58.900 --> 00:12:02.200
פעולות בעלות השפעה גבוהה צריכות תמיד להיעצר עד לאישור אנושי.

00:12:02.320 --> 00:12:05.980
תהליך קבלת ההחלטות צריך להירשם בצורה שאנשים יכולים לבחון ולהבין בפועל.

00:12:06.100 --> 00:12:10.560
עליכם להבטיח קיומם של נתיבי חזרה לאחור עוד לפני שהפעולה האוטונומית הראשונה יוצאת לפועל.

00:12:10.560 --> 00:12:16.060
אם סוכן מעדכן הרשאות או משנה מדיניות ניתוב, חייבת להיות דרך לעקוב אחר ההחלטה ולבטל אותה בצורה נקייה.

00:12:16.200 --> 00:12:20.100
ישנו גורם נוסף שמנהיגים מפספסים לעיתים קרובות כי ההדגמות המוקדמות נראות טוב מדי.

00:12:20.240 --> 00:12:21.540
העלות של עבודה חוזרת

00:12:21.540 --> 00:12:25.760
אם סוכן יוצר סבבי ניקוי עבור הצוות שלך, החיסכון הצפוי נעלם מיד.

00:12:25.960 --> 00:12:27.540
זהו מס העבודה החוזרת.

00:12:27.540 --> 00:12:32.920
זהו הזמן המושקע בתיקון פלט שגוי, הפיכת פעולות לא תקינות או רדיפה אחר השפעות לא מכוונות.

00:12:32.920 --> 00:12:38.820
אם הצוות שלך חוסך עשר דקות בביצוע אבל שורף שמונה דקות בניקוי הבלגן, למעשה לא ביצעת האוטומציה לתמיכה.

00:12:38.940 --> 00:12:41.460
פשוט העברת את החיכוך לחלק אחר בתהליך.

00:12:41.640 --> 00:12:44.900
אמון לא נוצר ממצגת מדיניות, מהוקצת או מהכרזה חגיגית על השקה.

00:12:45.000 --> 00:12:46.480
הוא נובע מהוכחות בזמן אמת.

00:12:46.660 --> 00:12:50.440
אנשים צריכים לראות מה הסוכן ראה, מה הוא החליט ומה בפועל השתנה במערכת.

00:12:50.440 --> 00:12:52.340
כך בונים אמון בתמיכה אוטונומית.

00:12:52.480 --> 00:12:56.420
ההוכחה חייבת להיות בהתנהגות הכלי ולא במיתוג של הפרויקט.

00:12:56.420 --> 00:13:02.280
ברגע שיסודות המשילות איתנים, השיחה יכולה סוף סוף לעבור מזרגון אבטחה לשפת מנהלים.

00:13:02.500 --> 00:13:04.340
מה זה באמת משנה לשורה התחתונה?

00:13:04.540 --> 00:13:06.940
החזר ההשקעה החדש של תמיכה בלתי נראית.

00:13:07.120 --> 00:13:10.760
ברגע שמנהיגים מקבלים את מודל הבקרה, השאלות הפיננסיות מתחילות להשתנות.

00:13:10.760 --> 00:13:16.220
במודל הישן, ערך התמיכה נמדד בעבודה הגלויה כמו כרטיסים שנסגרו, שיחות שטופלו וביצועי SLA.

00:13:16.380 --> 00:13:19.860
המספרים האלה עדיין חשובים, אבל הם רק מתארים תגובה לבעיה.

00:13:19.860 --> 00:13:25.400
הם לא אומרים לך כמה הפרעות מעולם לא הגיעו לתור או כמה זמן עובד נחסך כי הבעיה חוסלה מוקדם.

00:13:25.580 --> 00:13:27.360
זוהי בעיית החשבונאות המרכזית.

00:13:27.500 --> 00:13:30.260
תמיכה בלתי נראית יוצרת ערך דרך היעדרות.

00:13:30.320 --> 00:13:37.060
אתה רואה את הערך כשאין כרטיס, אין הסלמה, ואף אנליסט לא מבלה 20 דקות בשחזור בעיה מפתקים חלקיים.

00:13:37.260 --> 00:13:42.380
אם אתה מודד רק את המאמץ הנראה לעין של צוות התמיכה, אתה מפספס את התוצאה שבאמת רצית.

00:13:42.560 --> 00:13:44.620
רצית עבודה יציבה עם פחות הפרעות.

00:13:44.620 --> 00:13:47.620
נפח כרטיסים הוא סימן חלש כשהוא עומד בפני עצמו.

00:13:47.760 --> 00:13:53.100
ירידה בכרטיסים עשויה להעיד על ירידה בביקוש, אך היא יכולה גם להעיד שהסביבה הפכה בריאה יותר ושכבת התמיכה חכמה יותר.

00:13:53.260 --> 00:13:54.760
אלו שני סיפורים שונים מאוד.

00:13:54.960 --> 00:13:58.780
מנהלים זקוקים למערכת מדדי ביצוע, KPI, שיכולה להבחין ביניהם.

00:13:58.900 --> 00:14:01.440
כדאי להתחיל בבחינת שיעור הפתרון האוטונומי.

00:14:01.600 --> 00:14:07.340
זה לא על כמה שיחות הבוט ניהל, אלא כמה אירועי תמיכה נפטרו מקצה לקצה מבלי שאדם נגע בהם.

00:14:07.340 --> 00:14:10.360
עליך לעקוב גם אחר הצמצום בזמן הממוצע לפתרון.

00:14:10.540 --> 00:14:15.660
בסביבות מונאות בינה מלאכותית, תהליכים עתירי אבחון רואים לעיתים קרובות שיפורים בטווח של 40-60%.

00:14:15.660 --> 00:14:19.740
לאחר מכן ניתן להסתכל על העלות לפתרון ועל פריון המשתמש שהחזרת לעצמך.

00:14:19.900 --> 00:14:24.440
קל לדלג על המדד האחרון הזה כי הוא לא משתלב בצורה מסודרת בדוח שירות סטנדרטי.

00:14:24.540 --> 00:14:26.680
עם זאת, שם לרוב תמון הערך האמיתי.

00:14:26.680 --> 00:14:31.940
אדם שחסום במשך 15 דקות עוד לפני שהוא פותח כרטיס כבר יצר עלות עבור החברה.

00:14:32.040 --> 00:14:38.340
כשמכפילים זאת בהפרעות בפגישות ובקשיי גישה בתוך ארגון גדול, ההפסד הסמוי גדול בהרבה ממה שהתור מראה.

00:14:38.460 --> 00:14:42.000
זו הסיבה שמודל, עלות חוסר הפעולה, כל כך חשוב לניתוח העסקי.

00:14:42.120 --> 00:14:45.940
אתה מחשב את השעות שהושקעו במאמץ ידני לפני שתמיכה רשמית בכלל מתחילה.

00:14:46.040 --> 00:14:48.400
ואז מוסיפים את עלות השגיאות והעבודה החוזרת.

00:14:48.400 --> 00:14:51.800
לפתע, הטיעון בעד מניעה מוקדמת מפסיק להישמע כמו תיאוריה.

00:14:51.900 --> 00:14:54.060
אתם לא סתם מממנים שכבת תמיכה עתידנית.

00:14:54.260 --> 00:14:57.500
אתם מסירים מס שרובץ על העבודה היומיומית שלכם כבר שנים.

00:14:57.640 --> 00:15:00.420
הכלכלה של מקרים ממוקדים הופכת את זה לברור עוד יותר.

00:15:00.600 --> 00:15:05.380
מחקר על תמיכת איט מבוססת סוכנים מראה שטיפול אנושי עולה כף מינוס 8.75 דולר לי ועיה.

00:15:05.520 --> 00:15:10.960
לעומת זאת, טיפול ממוקד של סוכנים יכול לרדת אל מתחת למד מינוס 50 סנט לבעיה ברגע שהמערכת מפותחת.

00:15:10.960 --> 00:15:15.840
זה לא אומר שכל פעולת תמיכה תהיה כזאת זולה, ומנהלים צריכים להיזהר עם ממוצעים כלליים.

00:15:16.000 --> 00:15:21.320
איכות התלמטריה והמשילות תמיד ישפיעו על העלות הסופית, אך כיוון המגמה הוא חד משמעי.

00:15:21.480 --> 00:15:25.040
זה הרגע שבו האיט יוצא מהסיפור הישן של מרכז עלויות.

00:15:25.240 --> 00:15:31.220
זה לא בגלל שהתמיכה נעלמת, אלא בגלל שהיא הופכת לשכבת אמינות שמגנה על תפוקת העובדים ברקע.

00:15:31.360 --> 00:15:35.400
העסק מרגיש את זה כעבודה חלקה יותר במקום כאירוע תמיכה דרמטי.

00:15:35.400 --> 00:15:40.180
מקבלים פחות הפרעות, התאוששות מהירה יותר ופחות עבודה מבוסבזת על ניתוב וברורים.

00:15:40.300 --> 00:15:43.440
ובכל זאת, מדידה גרועה יכולה בקלות לזייף התקדמות.

00:15:43.480 --> 00:15:48.060
אם הטלמטריה שלכם חלשה, הסוכן עלול פשוט לסכם תקלה מהר יותר במקום למנוע אותה באמת.

00:15:48.240 --> 00:15:52.160
אם עבודה חוזרת נשארת מחוץ ללוח המכוונים, הרו ייראה הרבה יותר נקי ממה שהוא באמת.

00:15:52.280 --> 00:15:57.040
אם זמן שהוחזר רק דולף חזרה לפעילות בעלת ערך נמוך, מנהלים יגזימו בהערכת הרווח.

00:15:57.040 --> 00:16:01.860
הטיעון הכלכלי חייב להישאר מבוסס על ראיות מוצקות כמו מניעת תקריות ופחות מגע ידני.

00:16:02.020 --> 00:16:04.860
חייבים למדוד את הזמן שבאמת הוחזר לעבודה מועילה.

00:16:05.020 --> 00:16:09.340
ברגע שמודדים זאת נכון, פונקציית התמיכה מפסיקה להיראות קהלות שצריך לקצץ.

00:16:09.500 --> 00:16:13.140
היא מתחילה להיראות כקיבולת תפעולית שהעסק סוף סוף מקבל בחזרה.

00:16:13.320 --> 00:16:14.720
מה זה עושה לצוות התמיכה?

00:16:14.900 --> 00:16:16.960
חישבו על מה שזה באמת עושה לצוות בשטח.

00:16:16.960 --> 00:16:19.460
כי השינוי הזה הוא לא באמת על צמצום כוח אדם,

00:16:19.640 --> 00:16:22.300
אלא על שינוי מה שהאנשים שלכם באמת עושים במהלך היום.

00:16:22.460 --> 00:16:26.160
במבנה הישן, רוב קיבולת התמיכה שלכם נאחלת על ידי איפוס סיסמאות,

00:16:26.380 --> 00:16:28.300
ניתוב כרטיסים ומעגלי ברורים אינסופיים.

00:16:28.500 --> 00:16:31.580
יש לכם אנשים שרודפים אחרי עדכונים ומעבירים נתונים בין מערכות

00:16:31.580 --> 00:16:33.200
שמעולם לא תוכננו לתקשר זו עם זו.

00:16:33.320 --> 00:16:35.960
שום דבר מהעבודה הזו לא הופך את הסביבה ליציבה יותר,

00:16:35.960 --> 00:16:37.700
הוא רק מונע מהתור לעלות על גדותיו.

00:16:37.700 --> 00:16:40.300
כשסוכנים משתלטים על עבודת השגרה הצפויה הזו,

00:16:40.500 --> 00:16:42.340
המאמץ האנושי סוף סוף עולה רמה.

00:16:42.520 --> 00:16:45.960
מהנדסי תמיכה מתחילים להשקיע את זמנם בהגדרת מצב תקין

00:16:45.960 --> 00:16:47.900
וכיוונון הלוגיקה שמאחורי אישורים.

00:16:48.040 --> 00:16:49.720
הם מתמקדים בשיפור מקורות ידע,

00:16:49.860 --> 00:16:51.300
בבחינת התנהגות מדיניות,

00:16:51.520 --> 00:16:54.040
ובוידו שהסוכן נשאר בתוך הגבולות שהוגדרו לו.

00:16:54.200 --> 00:16:57.220
זה תפקיד שונה לגמרי מבחיה בשורות נושא כל היום

00:16:57.220 --> 00:16:59.500
וניסיון לנחש מה המשתמש באמת רוצה.

00:16:59.500 --> 00:17:02.080
זה בדיוק המקום שבו רוב ההתמאות נתקעות.

00:17:02.200 --> 00:17:05.060
ארגונים מנסים לשמור על התהליכים הישנים והשבורים שלהם

00:17:05.060 --> 00:17:07.800
ופשוט להוסיף סוכן מעל בציפייה לתוצאות טובות יותר.

00:17:07.980 --> 00:17:09.400
אבל התהליך נשאר תגובתי,

00:17:09.600 --> 00:17:11.120
העברות הטיפול עדיין מבולגנות,

00:17:11.320 --> 00:17:12.720
והידע הבסיסי נותר חלש.

00:17:12.860 --> 00:17:15.680
הסוכן הופך סתם לעוד שכבת צבע על קיר מתפורר.

00:17:15.820 --> 00:17:17.120
הוא אולי יענה על שאלה מהר יותר,

00:17:17.120 --> 00:17:19.700
אבל הוא לא יכול לתקן מודל תמיכה שנבנה סביב עיכובים.

00:17:19.700 --> 00:17:22.440
הדרך הטובה יותר היא לתכנן מחדש את העבודה קודם.

00:17:22.560 --> 00:17:24.780
עליך להחליט אילו משימות נשארות אנושיות,

00:17:24.880 --> 00:17:26.840
כי הן דורשות שיקול דעת או תקשורת רגישה.

00:17:26.960 --> 00:17:29.520
אז אתה מחליט איזו עבודה עוברת לזרימות אוטונומיות,

00:17:29.620 --> 00:17:31.460
כי התוצאה צפויה והפעולות בטוחות.

00:17:31.560 --> 00:17:34.380
החלוקה הזו חיונית כי צוותי התמיכה לא הולכים לשום מקום.

00:17:34.520 --> 00:17:37.480
הם פשוט הופכים לאנשים שמתכננים את הבקרות ומטפלים בחריגים.

00:17:37.480 --> 00:17:40.520
זה אומר שגם הדרך שבה אנחנו מכשירים אנשים חייבת להשתנות.

00:17:40.520 --> 00:17:44.540
צוותים צריכים ללמוד איך לפקח על מערכת במקום רק לבצע משימה ידנית.

00:17:44.740 --> 00:17:49.240
הם צריכים להבין לוגיקה של שחזור, ביקורות ואיך לבדוק סוכן לפני שהוא עולה לאוויר.

00:17:49.420 --> 00:17:51.820
הם גם צריכים להיות מסוגלים לזהות מתי מודל נכשל,

00:17:51.980 --> 00:17:54.720
כי זרימת עבודה גרועה ואוטומטית היא עדיין זרימת עבודה גרועה.

00:17:54.820 --> 00:17:56.440
היא פשוט מקלקלת דברים מהר יותר.

00:17:56.440 --> 00:18:00.520
אם אתם מגייסים לעתיד הזה, אתם כנראה לא צריכים עוד קולבויניק למיון כרטיסי תמיכה.

00:18:00.520 --> 00:18:06.520
אתם צריכים מישהו שיכול לתזמר זרימות במיקרוסופט 365 ולהגדיר את הבקרות ששומרות על הסוכנים בשליטה.

00:18:06.640 --> 00:18:11.740
אתם רוצים אנשים שיכולים לשפר את הסביבה כדי שדרישת התמיכה תרד במקום רק להיערם.

00:18:11.860 --> 00:18:16.140
אז איך מתחילים את זה באמת בלי שזה יהפוך לפרויקט טרנספורמציה עצום של שנים?

00:18:16.140 --> 00:18:21.800
המהלך הטוב ביותר הוא לבחור זרימה אחת שגורמת לחיכוך מתמיד בתוך סביבת המיקרוסופט 365 שלכם.

00:18:21.800 --> 00:18:27.100
תיקון גישה הוא בדרך כלל מועמד מצוין, אבל אפשר גם לבחון תמיכה בפגישות או העברות תהימות מכשירים.

00:18:27.280 --> 00:18:33.080
לא משנה מה תבחרו, כל עוד התבנית קוראת לעתים קרובות ואתם יודעים בדיוק איך תוצאה מוצלחת צריכה להיראות.

00:18:33.300 --> 00:18:37.140
ברגע שיש לכם את היעד, עליכם להגדיר את היסודות עם משמעת אמיתית.

00:18:37.140 --> 00:18:42.120
אתם צריכים לדעת איך נראה מצב תקין ואילו אירועים ספציפיים מעידים על כך שדברים יוצאים מאיזון.

00:18:42.120 --> 00:18:46.780
החליטו אילו פעולות בטוחות לאוטומציה ומאיזו נקודה בדיוק נדרשת הסלמה אנושית.

00:18:46.900 --> 00:18:53.060
לפני שאתם משיקים משהו, הודו שיש לכם בסיס למספר הכרטיסים, הפעולות הידניות וכמה זמן המשתמשים מחכים לפתרון.

00:18:53.220 --> 00:18:55.940
עליכם גם להכיל את הממשל שלכם מהיום הראשון.

00:18:55.940 --> 00:19:00.440
תנו לסוכן זהות ספציפית, הקצו לו בעלים אנושי וקבעו חוקי אישור ברורים.

00:19:00.600 --> 00:19:03.320
כל פעולה שהסוכן מבצע צריכה להירשם ביומן.

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

00:19:09.140 --> 00:19:13.080
כשתהליך העבודה הראשון מתחיל לפעול, כל המודל התפעולי שלכם מתחיל להשתנות.

00:19:13.260 --> 00:19:16.520
התמיכה מפסיקה לתפקד כדל פק קבלה שמגיב רק לבעיות.

00:19:16.700 --> 00:19:21.160
במקום זאת, היא מתחילה לפעול כי מנוע אמינות המותמה ישירות בתוך המערכת.

00:19:21.300 --> 00:19:23.820
התמיכה עוברת מתגובה גלויה למניעה מובנית.

00:19:23.820 --> 00:19:26.060
כרטיס התמיכה מעולם לא היה השירות עצמו.

00:19:26.160 --> 00:19:28.440
הוא היה הוכחה לכך שהשירות הגיע מאוחר מדי.

00:19:28.560 --> 00:19:32.440
בחרו תהליך תמיכה אחד ברבעון זה ותכננו אותו מחדש למניעה במקום לתגובה.

00:19:32.560 --> 00:19:37.160
אם תרצו עוד על M365 Copilot, Azure, הבטחה ומודלים טיפוליים של AI,

00:19:37.440 --> 00:19:40.080
הרשמו ל-M365 FM והשאירו ביקורת.

00:19:40.180 --> 00:19:43.960
צרו איתי קשר, מרקו פיטר, בלינקטין עם הנושא הבא שתרצו שננתח.