WEBVTT

00:00:00.000 --> 00:00:01.720
تبدو أنظمة التذاكر مثالية على الورق

00:00:01.720 --> 00:00:04.280
تحصل على الأرقام وقوائم الانتظار ولوحات البيانات

00:00:04.280 --> 00:00:07.920
لكن في الواقع هذا النموذج يقيس المعاناة فقط بعد تعطل النظام بالفعل

00:00:07.920 --> 00:00:10.700
الجزء المكلف من المشكلة يبدأ عادة في وقت أبكر بكثير

00:00:10.700 --> 00:00:14.180
يبدأ عندما يهدر الموظف عشر دقائق ثم عشرون ثم يستسلم في النهاية

00:00:14.180 --> 00:00:16.780
يحاولون مجددا يسألون زميلا في العمل

00:00:16.780 --> 00:00:19.900
يفوتنا الاجتماع أو يشاركون ملفا خاطئا لأن المسار الصحيح توقف عن العمل

00:00:19.900 --> 00:00:22.640
وهذا هو الجزء الذي لا تزال معظم فرق الدعم لا تراه

00:00:22.640 --> 00:00:25.920
أفضل نموذج للدعم الداخلي اليوم لا يتعلق بفرز أسرع للتذاكر

00:00:25.920 --> 00:00:28.600
بل يتعلق بإزالة الحاجة إلى الفرز تماما

00:00:28.600 --> 00:00:32.500
تخيل وكيلا مستقلا داخل مايكروسوفت 365 يراقب السياقة

00:00:32.500 --> 00:00:37.100
ويكتشف المعويقات مبكرا ويتصرف قبل أن يفكر أي شخص في فتح بوابة دعم

00:00:37.100 --> 00:00:40.540
في هذه الحلقة أريد أن أوضح لك لماذا ينهار نموذج مكتب المساعدة

00:00:40.540 --> 00:00:44.220
وما الذي يحل محله فعليا وكيف يمكنك إدارته دون التسبب في فوضى

00:00:44.220 --> 00:00:49.400
إذا كان هذا التحول يهم عملك اشترك في M365F لأن المشكلة الحقيقية على مستوى أعمق

00:00:49.400 --> 00:00:51.660
ليست قائمة الانتظار بل النموذج الكامن خلفها

00:00:51.660 --> 00:00:52.740
موت التذكيراتي

00:00:52.740 --> 00:00:54.960
تدفق الدعم القديم لا يزال موجودا في كل مكان

00:00:54.960 --> 00:00:56.180
شيء ما يتعطل

00:00:56.180 --> 00:00:57.580
مستخدم يلاحظ ذلك

00:00:57.580 --> 00:00:59.140
المستخدم يحاول شرحه

00:00:59.140 --> 00:01:03.500
ثم يقوم قسم تكنولوجيا المعلومات بترجمة ذلك الشرح إلى فئة وأولوية وربما مجموعة إسناد

00:01:03.500 --> 00:01:05.180
تدخل المشكلة في قائمة انتظار

00:01:05.180 --> 00:01:06.580
يقوم شخص ما بفرزها

00:01:06.580 --> 00:01:08.300
يطلب شخص آخر المزيد من التفاصيل

00:01:08.300 --> 00:01:09.800
يتم إشراك فريق آخر

00:01:09.800 --> 00:01:12.140
الوقت يمضي بينما يظل العمل الفعلي عالقا

00:01:12.140 --> 00:01:14.340
تبدو هذه العملية طبيعية لأنها مألوفة

00:01:14.340 --> 00:01:16.400
لكن المألوفة والفعالة ليس الشيء نفسه

00:01:16.400 --> 00:01:17.740
التذكرة ليست دعما

00:01:17.740 --> 00:01:20.300
التذكرة هي دليل على أن الدعم وصل متأخرا

00:01:20.300 --> 00:01:21.820
بحلول الوقت الذي توجد فيه تذكرة

00:01:21.820 --> 00:01:24.400
يكون الموظف قد واجه بالفعل عقبات وفقد سياق عمله

00:01:24.400 --> 00:01:26.160
لقد حولوا انتباههم بالفعل بعيدا عن العمل

00:01:26.160 --> 00:01:27.400
الذي كانوا يحاولون القيام به

00:01:27.400 --> 00:01:29.120
قائمة الانتظار ليست هي الخدمة

00:01:29.120 --> 00:01:30.860
قائمة الانتظار هي سجل للفشل

00:01:30.860 --> 00:01:33.000
في بيئات مايكروسوفت 365 الكبيرة

00:01:33.000 --> 00:01:34.960
يصبح الفرز يدويه وعنق الزجاجة الحقيقي

00:01:34.960 --> 00:01:36.980
هذا لا يحدث لأن فرق الدعم كسولة

00:01:36.980 --> 00:01:40.200
يحدث لأن البشر يطلب منهم القيام بشيء لم يعد يناسب حجم البيئة

00:01:40.200 --> 00:01:41.400
لديك المزيد من المستخدمين

00:01:41.400 --> 00:01:42.360
والمزيد من الأجهزة

00:01:42.360 --> 00:01:43.320
والمزيد من التطبيقات

00:01:43.320 --> 00:01:44.340
والمزيد من السياسات

00:01:44.340 --> 00:01:45.820
لديك المزيد من الحالات الاستثنائية

00:01:45.820 --> 00:01:46.780
التي تعبر بين الفرق

00:01:46.780 --> 00:01:47.540
وشيربوينت

00:01:47.540 --> 00:01:48.240
واكستشينج

00:01:48.240 --> 00:01:48.800
وانتون

00:01:48.800 --> 00:01:50.180
وانترا في نفس الوقت تماما

00:01:50.180 --> 00:01:51.360
الحجم لا ينمو فحسب

00:01:51.360 --> 00:01:53.020
التركيبات هي التي تنمو

00:01:53.020 --> 00:01:54.480
هنا ينهار النموذج القديم

00:01:54.480 --> 00:01:56.760
معظم الفرق تستجيب بإضافة المزيد من الهياكل

00:01:56.760 --> 00:01:58.020
يبنون بوابة أخرى

00:01:58.020 --> 00:01:58.680
أو روبوت آخر

00:01:58.680 --> 00:02:00.080
أو قاعدة توجيه أخرى

00:02:00.080 --> 00:02:00.900
لكن في الواقع

00:02:00.900 --> 00:02:03.720
هذا يضيف فقط طبقة أخرى بين الموظف والحل

00:02:03.720 --> 00:02:06.720
لا يزال النظام ينتظر من المستخدم ملاحظة المشكلة

00:02:06.720 --> 00:02:07.440
ووصفها

00:02:07.440 --> 00:02:09.520
وطلب المساعدة بالطريقة الصحيحة

00:02:09.520 --> 00:02:11.120
لا يبدأ العمل في بوابة دعم

00:02:11.120 --> 00:02:12.380
بل يبدأ في تينز

00:02:12.380 --> 00:02:13.380
وفي أوتلوك

00:02:13.380 --> 00:02:15.220
وفي مستند يحتاجه شخص ما الآن

00:02:15.220 --> 00:02:17.340
أو اجتماع سيبدأ بعد ثلاثون ثانية

00:02:17.340 --> 00:02:19.060
هنا يبدأ طلب الدعم فعليا

00:02:19.060 --> 00:02:21.880
ونموذج التذاكر منفصل تماما عن تلك اللحظة

00:02:21.880 --> 00:02:24.800
التكلفة الخفية أكبر بكثير مما يظهره تقرير قائمة الانتظار لديك

00:02:24.800 --> 00:02:26.660
الموظفون يغيرون سياق مهامهم باستمرار

00:02:26.660 --> 00:02:28.980
تتراكم الحوادث المتطابقة تحت مسميات مختلفة

00:02:28.980 --> 00:02:31.120
تتقادم مقالات المعرفة وتفقد قيمتها

00:02:31.120 --> 00:02:33.900
يقضي المحللون يومهم بالكامل في التصنيف والتوجيه والتوضيح

00:02:33.900 --> 00:02:35.320
بدلا من إصلاح الأشياء فعليا

00:02:35.320 --> 00:02:38.480
يمتد وقت الحل لأن كل عملية تسليم تضيف تأخيرا

00:02:38.480 --> 00:02:41.040
وكل تأخير يجرد المشكلة من سياقها الأصلي

00:02:41.040 --> 00:02:42.820
تشير الأبحاث حول ذكاء الاصطناعي الوكيل

00:02:42.820 --> 00:02:45.080
وعمليات تكنولوجيا المعلومات إلى نفس المشكلة الهيكلية

00:02:45.080 --> 00:02:48.960
لا تزال نسبة 80% على الأقل من الجهد حبيسة العمل التفاعلي بأسلوب ATAL

00:02:48.960 --> 00:02:52.080
هذا الرقم مهم لأنه يخبرك بالضبط أين تذهب الجهود البشرية

00:02:52.080 --> 00:02:54.020
إنها لا تذهب نحو المرونة أو الوقاية

00:02:54.020 --> 00:02:55.340
بل تذهب نحو رد الفعل

00:02:55.340 --> 00:02:56.560
بمجرد أن تدرك ذلك

00:02:56.560 --> 00:02:59.380
تبدأ التذكرة في الظهور كعرض جانبي وليست نموذج تشغيل

00:02:59.380 --> 00:03:02.600
إنه عرض لنظام لا يستجيب إلا بعد أن يصبح الضرر مرئيا

00:03:02.600 --> 00:03:05.160
لذا السؤال التالي ليس كيف نعالج التذاكرة بشكل أسرع

00:03:05.160 --> 00:03:07.620
بل ما الذي يجب أن يفعله النظام قبل الحاجة إلى تذكرة

00:03:07.620 --> 00:03:09.420
نموذج الموظف غير المرئي

00:03:09.420 --> 00:03:11.780
إذن ما الذي يحل محل التذكرة فعليا

00:03:11.780 --> 00:03:14.740
إنه ليس مجرد روبوت محادثة آخر يجلس فوق نفس الفوضى

00:03:14.740 --> 00:03:17.240
وبالتأكيد ليس واجهة أجمل لنفس قائمة الانتظار القديمة

00:03:17.240 --> 00:03:20.060
التحول أعمق من ذلك بكثير لأن الموظف غير المرئي

00:03:20.060 --> 00:03:24.040
هو عامل تشغيلي يعيش داخل بيئة مايكروسوفت 365 الخاصة بك

00:03:24.040 --> 00:03:26.800
هذا الوكيل لديه هويته الخاصة ونطاق عمل محدد

00:03:26.800 --> 00:03:28.340
وذاكرة لما فعله بالأمس

00:03:28.340 --> 00:03:31.060
وقواعد صارمة بشأن ما يمكنه وما لا يمكنه لمسه

00:03:31.060 --> 00:03:32.240
هذا التمييز مهم

00:03:32.240 --> 00:03:34.520
ينتظر روبوت المحادثة منك كتابة طلب

00:03:34.520 --> 00:03:37.100
لكن الموظف غير المرئي يراقب تغير الظروف

00:03:37.100 --> 00:03:39.980
إنه يبدأ من السياق بدلا من البدء بمحادثة

00:03:39.980 --> 00:03:41.800
لأنه يستطيع رؤية حالات تسجيل الدخول

00:03:41.800 --> 00:03:43.600
وصحة الأجهزة وحالة التراخيص

00:03:43.600 --> 00:03:45.000
وكيفية مشاركة الملفات

00:03:45.000 --> 00:03:46.500
فلا دعي الانتظار ظهور المشاكل

00:03:46.500 --> 00:03:49.120
بدلا من السؤال عن كيفية المساعدة بعد حدوث العطل

00:03:49.120 --> 00:03:51.700
فإنه يطرح باستمرار سؤالا مختلفا في الخلفية

00:03:51.700 --> 00:03:55.800
ما الذي يبتعد عن الحالة التي يحتاجها هذا الموظف للقيام بعمله الآن

00:03:55.800 --> 00:03:57.280
هنا تتغير الأمور

00:03:57.280 --> 00:04:00.200
النموذج مدمج مباشرة داخل العمل نفسه

00:04:00.200 --> 00:04:02.880
عندما ينضم شخص إلى اجتماع ويفشل توجيه الصوت

00:04:02.880 --> 00:04:05.600
أو لا يستطيع ضيف فتح ملف أرسل إليه للتو

00:04:05.600 --> 00:04:08.380
فإن العالم القديم ينشئ تقريرا وعملية تسليم

00:04:08.380 --> 00:04:10.760
في النموذج الجديد يكتشف الوكيل نمط فورا

00:04:10.760 --> 00:04:13.480
ويتحقق مما إذا كانت الحالة تطابق مشكلة معروفة

00:04:13.480 --> 00:04:15.540
ثم يتخذ الإجراء الآمن التالية لإصلاحها

00:04:15.540 --> 00:04:17.900
ربما يقوم بإعادة ضبط مسار أو تفعيل فحص سياسة

00:04:17.900 --> 00:04:20.560
أو ربما يعيد توجيه طلب ويطلب التحقق متعدد العوامل

00:04:20.560 --> 00:04:22.060
MFA قبل توثيق الإصلاح

00:04:22.060 --> 00:04:23.020
الأمر بسيط

00:04:23.020 --> 00:04:27.620
لم تعد الاستجابة الأولى تتطلب من البشر قراءة وصف غامض وتخمين ما حدث

00:04:27.620 --> 00:04:29.720
يبدو هذا غير مرئيا عندما يعمل بشكل جيد

00:04:29.720 --> 00:04:33.060
فلا توجد غرفة امتظار ولا نموذج يرجى اختيار فئة لملئه

00:04:33.060 --> 00:04:35.060
يظهر الدعم كاستعادة لسير العمل

00:04:35.060 --> 00:04:36.860
يعود الموظف إلى عمله ببساطة

00:04:36.860 --> 00:04:40.100
وفي كثير من الحالات لا يرى حتى الآليات التي تعمل في الخلفية

00:04:40.100 --> 00:04:43.440
يمكنك بالفعل رؤية كيف يغير هذا منطق التوظيف لديك

00:04:43.440 --> 00:04:46.780
النموذج القديم يوظف أشخاصا لاستعاب حجم الطلبات وتصنيفها

00:04:46.780 --> 00:04:49.040
وإصلاح السياقات المقطوعة بين الفرق المختلفة

00:04:49.040 --> 00:04:51.480
يحتاج النموذج الجديد إلى عدد أقل من الأشخاص للفرز

00:04:51.480 --> 00:04:53.200
والمزيد من الأشخاص لتصميم الضوابط

00:04:53.200 --> 00:04:54.520
وتحديد الحالات المطلوبة

00:04:54.520 --> 00:04:56.640
والإشراف على سلوك هؤلاء الوكلاء بمرور الوقت

00:04:56.640 --> 00:04:58.220
يظل البشر جزءا من النظام

00:04:58.220 --> 00:05:00.700
لكن شكل عملهم اليومي يتغير بالكامل

00:05:00.700 --> 00:05:04.500
تستمر الأبحاث حول الذكاء الاصطناعي الوكيل في الدعم في الإشارة إلى هذا الاتجاه

00:05:04.500 --> 00:05:07.680
يمكن للدعم الروتيني الانتقال نحو المعالجة القائمة على الاستثناءات

00:05:07.680 --> 00:05:11.780
مما يخلق مكاسب هائلة في الكفاءة عندما تكون البيئة والسياسات محددة جيدا

00:05:11.780 --> 00:05:14.440
هذا الجزء الأخير حيوي لأن هذا ليس سحرا

00:05:14.440 --> 00:05:16.920
إذا كانت بياناتك ضعيفة أو عمليتك فوضوية

00:05:16.920 --> 00:05:20.320
فلن يصبح الوكيل ذكيا لمجرد أنك قررت تسميته مستقلا

00:05:20.320 --> 00:05:23.760
اتضح لي الأمر تماما عندما توقفت عن التفكير في الوكيل كميزة برمجية

00:05:23.760 --> 00:05:26.480
وبدأت في اعتباره موظفا غير بشري يحمل بطاقة تعريف

00:05:26.480 --> 00:05:31.380
يحتاج العامل الحقيقي إلى هوية ووصف وظيفي وصلاحيات ومدير يرفع تقاريره إليه

00:05:31.380 --> 00:05:35.320
يحتاج الوكيل إلى نفس هذه الأشياء تماما لأن القيمة تأتي من العمل الموثوق داخل النظام

00:05:35.320 --> 00:05:37.440
وليس من اللغة الذكية في نافذة الدردشة

00:05:37.440 --> 00:05:40.500
الموظف غير المرئي ليس مجرد خدعة في واجهة المستخدم

00:05:40.500 --> 00:05:44.100
إنه طبقة دعم جديدة تراقب الاحتكاك عبر بيئة مايكروسوفت 365

00:05:44.100 --> 00:05:49.180
وتعمل ضمن السياسة وتوجه انتباه البشر نحو الاستثناءات التي تحتاج فعليا إلى حكم بشريا

00:05:49.180 --> 00:05:52.540
بمجرد أن يصبح هذا النموذج واضحا يصبح السؤال التالي عمليا جدا

00:05:52.540 --> 00:05:54.460
كيف تعمل الاستباقية فعليا

00:05:54.460 --> 00:05:55.900
بنية الاستباقية

00:05:55.900 --> 00:05:59.220
إذن كيف تعمل الاستباقية فعليا داخل مايكروسوفت 365

00:05:59.220 --> 00:06:03.000
ينتقل التحول من الطلب والاستجابة إلى التفكير في الأحداث والتنسيق

00:06:03.000 --> 00:06:06.440
يبدو هذا تقنيا لكن النموذج بسيط بمجرد تفكيكه

00:06:06.440 --> 00:06:08.080
أولا يتغير شيء ما في البيئة

00:06:08.080 --> 00:06:11.220
ثم يفسر النظام ما إذا كان هذا التغير يعني مخاطرة أو انحرافا

00:06:11.220 --> 00:06:14.900
وأخيرا يتخذ الإجراء المعتمد باستخدام الأدوات الموجودة بالفعل في حزمتك

00:06:14.900 --> 00:06:16.320
ابدأ بطبقة الأحداث

00:06:16.320 --> 00:06:19.760
تنتج مايكروسوفت 365 بالفعل إشارات في كل مكان

00:06:19.760 --> 00:06:24.060
مما يعني أن انترا يرى سلوك تسجيل الدخول بينما يتتبع انتون حالة الجهاز والامتثال

00:06:24.060 --> 00:06:25.920
يراقب ديفيندر أي نشاط مشبوه

00:06:25.920 --> 00:06:29.680
ويوضح لك تيمز بالضبط متى يفشل الاجتماع أو تنخفض جودة المكالمة

00:06:29.680 --> 00:06:32.660
تكشف شيربوينت واكستشينج عن أنماط الوصول ونشاط المحتوى

00:06:32.660 --> 00:06:36.120
بينما تخبرك إشارات صحة الخدمة عندما تكون المنصة نفسها هي المشكلة

00:06:36.120 --> 00:06:38.120
عندما تضيف إجراءات المستخدم فوق ذلك

00:06:38.120 --> 00:06:40.060
تحصل على تدفق مستمر من السياق

00:06:40.060 --> 00:06:41.840
تجمع معظم المؤسسات تلك الإشارات

00:06:41.840 --> 00:06:44.640
لكن قلة قليلة منها تستخدمها فعلياً كنظام دعم

00:06:44.640 --> 00:06:48.980
الأحداث الأولية وحدها لا تساعد لأنها تحتاج إلى طبقة تفكير لفهم هذا الضجيج

00:06:48.980 --> 00:06:53.680
هنا يتوقف الموظف الخفي عن كونه مجرد عرضاً للأتمتة ويبدأ في العمل كمشغل حقيقي

00:06:53.680 --> 00:06:57.040
ينظر الوكيل إلى الإشارة ويقارن الحالة الحالية بالحالة المطلوبة

00:06:57.040 --> 00:06:59.360
ويقرر نوع الإجراء الآمن الذي يمكن اتخاذه

00:06:59.360 --> 00:07:02.240
مشكلة صوت الاجتماع ليست مثل تسجيل دخول محفوف بالمخاطر

00:07:02.240 --> 00:07:05.020
ورابط المشاركة المعطل يختلف عن عدم تطابق الترخيص

00:07:05.020 --> 00:07:10.140
يجب على الوكيل تصنيف المشكلة أولاً لأن اتخاذ إجراء دون تصنيف يؤدي إلى ارتكاب أخطاء بشكل أسرع

00:07:10.140 --> 00:07:11.660
ثم يأتي دور التنسيق

00:07:11.660 --> 00:07:15.760
بمجرد أن يفهم الوكيل المشكلة يمكنه استخدام الآلية المناسبة للاستجابة

00:07:15.760 --> 00:07:17.540
قد يكون ذلك Power Automate لسير العمل

00:07:17.540 --> 00:07:19.000
أو Co-Pilot Studio للمنطق

00:07:19.000 --> 00:07:20.860
أو Microsoft Graph لإجراءات النظام والسياق

00:07:20.860 --> 00:07:24.500
الأدوات مهمة لكن النقطة الأهم هي كيفية اتصالها ببعضها البعض

00:07:24.500 --> 00:07:26.400
أنت لا تبني مطالبة ذكية واحدة

00:07:26.400 --> 00:07:29.280
بل سلسلة يمكنها الاكتشاف والقرار والتنفيذ والتحقق

00:07:29.280 --> 00:07:31.720
هذا الجزء الأخير يتم تجاهله طوال الوقت

00:07:31.720 --> 00:07:34.960
النظام الذي يصح ذاته لا يتوقف بمجرد اتخاذ الإجراء

00:07:34.960 --> 00:07:37.260
إنه يعمل في حلقة حيث يكتشف المشكلة

00:07:37.260 --> 00:07:39.340
ويختبر الحالة ويطبق الإصلاح

00:07:39.340 --> 00:07:41.660
ويتحقق من النتيجة قبل تسجيل ما حدث

00:07:41.660 --> 00:07:43.640
توضح الأبحاث حول المنطق التصحيحي الذاتي

00:07:43.640 --> 00:07:46.660
أن هذه الأنظمة تعمل من خلال أنماط التغذية الراجعة والتصحيحي

00:07:46.660 --> 00:07:49.440
بدلاً من إجابة واحدة معزولة من نموذجاً لغوياً

00:07:49.440 --> 00:07:50.400
إذا فشل الإجراء الأول

00:07:50.400 --> 00:07:52.480
يحتاج النظام إلى طريقة لتقييم السبب

00:07:52.480 --> 00:07:55.920
حتى يتمكن من مراجعة الخطوة التالية مع البقاء ضمن الحدود المحددة

00:07:55.920 --> 00:07:59.080
يمكنك تصور هذا بوضوح في بعض حالات Microsoft 365

00:07:59.080 --> 00:08:02.800
عندما يتم حضر مستخدم لأن ترخيصه ونطاق سياسته لا يتطبقان

00:08:02.800 --> 00:08:05.940
يكتشف الوكيل عدم التطابق ويتحقق من ملف تعريف الدور المقصود

00:08:05.940 --> 00:08:09.280
يطبق التصحيح المسموح به ويؤكد حصول المستخدم على الوصول

00:08:09.280 --> 00:08:11.720
ويسجل التغيير دون الحاجة لسؤال أي شخص

00:08:11.720 --> 00:08:14.100
إذا ظهر تسجيل دخول محفوف بالمخاطر في إنترا

00:08:14.100 --> 00:08:17.820
يرى الوكيل حدث الخطر ويتحقق من قواعد الوصول المشروط الخاصة بك على الفور

00:08:17.820 --> 00:08:21.220
يطلب التحقق بشكل أقوى أو يحضر الوصول بناء على سياستك

00:08:21.220 --> 00:08:23.960
ثم يسجل النتيجة ليراجعها شخص ما لاحقا

00:08:23.960 --> 00:08:26.620
عندما يستمر فشل رابط مشاركة قديم في SharePoint

00:08:26.620 --> 00:08:30.420
يقوم الوكيل بمقارنة مسار الأذنات الحالي بقواعد المشاركة المتوقعة

00:08:30.420 --> 00:08:34.380
يستبدل الوكيل الرابط التالف بالرابط المعتمد ويرسل الرابط المصح في سياقه

00:08:34.380 --> 00:08:38.860
مما يغلق دائرة المشكلة قبل أن يضطر أي محلل تقني لقراءة تذكرة بعنوان

00:08:38.860 --> 00:08:40.220
مشكلة وصول عاجلة

00:08:40.220 --> 00:08:42.540
دعم الاجتماعات مثال رائع آخر

00:08:42.540 --> 00:08:46.380
إذا تعطل جهاز في الغرفة أو انقطع مسار الاندمام قبل ثوان من بدء المكالمة

00:08:46.380 --> 00:08:48.840
يمكن للوكيل اكتشاف الحالة والتحقق من العطل

00:08:48.840 --> 00:08:51.300
يحاول الوكيل إجراء خطوة استرداد منخفضة المخاطر

00:08:51.300 --> 00:08:54.300
ويخطر المنظم عبر تيمز بتحديث للحالة في مكان العمل نفسه

00:08:54.300 --> 00:08:57.120
تعد طبقة التواصل هذه جزءا كبيرا من التصميم

00:08:57.120 --> 00:08:59.740
يجب أن يتواجد الدعم حيثما يحدث الانقطاع

00:08:59.740 --> 00:09:03.140
إذا كان عملك يتم في تيمز وأوتلوك ومساحة عمل 365

00:09:03.140 --> 00:09:05.660
فيجب أن يستجيب الدعم لك هناك أيضا

00:09:05.660 --> 00:09:09.800
لا ينبغي عليك نقل المستخدم إلى مكان آخر بينما يمكنك معالجة الحدث في سياقه

00:09:09.800 --> 00:09:13.940
هذا لا يعني الأتمتة الكاملة لكل مهمة لأن ذلك سيكون تهورا

00:09:13.940 --> 00:09:15.960
يمكن تنفيذ الإجراءات منخفضة المخاطر تلقائيا

00:09:15.960 --> 00:09:18.800
لكن تغييرات ذات التأثير العالية لا تزال تتطلب موافقة بشرية

00:09:18.800 --> 00:09:22.360
يجب أن يكون مسار الموافقة هذا جزءا من البنية الأساسية منذ البداية

00:09:22.360 --> 00:09:23.860
بدلا من إضافته لاحقا

00:09:23.860 --> 00:09:27.920
يجب أن يعرف الوكيل متى يتصرف ومتى يطلب الإذن ومتى يتوقف تماما

00:09:27.920 --> 00:09:32.140
وبمجرد دمج ذلك في سير العمل يتوقف الحديث عن كونه مجرد ميزات أتمتة

00:09:32.140 --> 00:09:36.300
يصبح الأمر متعلقا بالتحكم والحوكمة والثقة وهوية الوكيل

00:09:36.300 --> 00:09:38.620
عندما يبدأ الدعم في التصرف من تلقاء نفسه

00:09:38.620 --> 00:09:40.140
يظهر سؤال صعب على الفور

00:09:40.140 --> 00:09:42.120
من الذي يقوم بالعمل فعليا

00:09:42.120 --> 00:09:45.220
إذا كانت الإجابة غامضة فإن النموذج بأكمله ينهار

00:09:45.220 --> 00:09:49.360
لا يمكن للوكيل أن يوجد في بيئتك كمساعد غامض يتمتع بوصول واسع وبدون مالك واضح

00:09:49.360 --> 00:09:51.860
إنه يحتاج إلى هوية حقيقية في إنترا

00:09:51.860 --> 00:09:56.640
يحتاج إلى مالك مسمنة ونطاق محدد ودورة حياة تبدأ وتنتهي لسبب معين

00:09:56.640 --> 00:10:00.860
إذا كان بإمكان هذا الوكيل قراءة البيانات أو تشغيل مهام سير العمل أو مراسلة مستخدمك

00:10:00.860 --> 00:10:03.000
فيجب عليك إدارته كمشارك نشط في المستأجر

00:10:03.000 --> 00:10:06.400
لا يمكنك التعامل معه كميزة قام شخص بتشغيلها ثم نسي أمرها

00:10:06.400 --> 00:10:09.380
لهذا السبب تعد هوية الوكيل أمراً بالغ الأهمية للنظام

00:10:09.380 --> 00:10:12.640
يجب أن تعرف بالضبط ما هو الوكيل والأنظمة التي يمكنه الوصول إليها

00:10:12.640 --> 00:10:14.640
ومن يتلقى تنبيهها عندما تبدأ الأمور في الانحراف

00:10:14.640 --> 00:10:17.220
يجب أن يكون مبدأ الامتياز الأقل هو الأساس هنا

00:10:17.220 --> 00:10:21.540
لا يمكنك الاكتفاء بالراحة العامة أو إقناع نفسك بأنك ستشدد الأذونات لاحقاً

00:10:21.540 --> 00:10:24.700
لأن نطاق تأثير وكيل الدعم يعتمد كلياً على أذوناته

00:10:24.700 --> 00:10:27.940
فإن تصميم تلك الأذونات جزء جوهري من تصميم الدعم

00:10:27.940 --> 00:10:31.360
يعمل أيجنت 365 كطبقة تحكم ضرورية في هذا الأعداد

00:10:31.360 --> 00:10:34.880
لأنه يتيح رؤية واضحة وشاملة لجميع الوكلاء أيجنت في النظام

00:10:34.880 --> 00:10:39.960
فهو يوفر السجلة وسر عمل الموافقات ونماذج السياسات التي تضمن سير العمل بأمان

00:10:39.960 --> 00:10:42.860
وعلى الرغم من أن هذه العناصر قد تبدو كمهام إدارية روتينية

00:10:42.860 --> 00:10:44.800
إلا أنها تحل مشكلة هيكلية ضخمة

00:10:44.800 --> 00:10:47.880
لا تعاني معظم المؤسسات بسبب افتقارها لميزات الذكاء الاصطناعي

00:10:47.880 --> 00:10:50.980
بل لأنها لا تستطيع رؤية أو التحكم فيما يعمل بالفعل في بيئتها

00:10:50.980 --> 00:10:53.460
الأبحاث حول هذه النقطة مباشرة وصريحة

00:10:53.460 --> 00:10:58.640
قلة قليلة فقط من المؤسسات الكبيرة يمكنها حصر كل وكيل يعمل حاليا في نظامها بشكل كامل

00:10:58.640 --> 00:11:01.520
قبل أن يبدأ القادة في الحديث عن توسيع نطاق الدعم الذاتي

00:11:01.520 --> 00:11:03.560
عليهم الإجابة على سؤال أبسط بكثير

00:11:03.560 --> 00:11:06.900
هل نعرف أصلا ما هي الوكلاء الموجودة وما الذي تفعله الآن

00:11:06.900 --> 00:11:10.220
يجب أن تتناسب الرقابة أيضا مع مستوى المخاطر التي تنطوي عليها العمليات

00:11:10.220 --> 00:11:12.880
وكيل الانتاجية الشخصي الذي يعمل في نطاق ضيق شيء

00:11:12.880 --> 00:11:16.280
ولكن الوكيل التعاوني الذي يتعامل مع محتوى مشترك شيء آخر تماما

00:11:16.280 --> 00:11:19.180
ثم هناك وكلاء المؤسسات الذين يتخذون إجراءات عبر سير عمل حساس

00:11:19.180 --> 00:11:21.100
وهو ما يقع في فئة مختلفة من المخاطر

00:11:21.100 --> 00:11:25.500
لهذا السبب يعتبر نموذج مناطق المخاطر الشخصي والتعاوني والمؤسسي مهما للغاية

00:11:25.500 --> 00:11:28.740
يجب أن يرتفع مستوى نموذج التحكم الخاص بك بالتوازي مع التأثير المحتملي

00:11:28.740 --> 00:11:30.240
إذا عملت كل وكيل بنفس الطريقة

00:11:30.240 --> 00:11:32.880
فسيتم دفن العمل منخفض المخاطر في موافقة بطيئة

00:11:32.880 --> 00:11:35.060
بينما تمر الأعمال عالية المخاطر بتدقيق ضعيف

00:11:35.060 --> 00:11:35.940
على أقل تقدير

00:11:35.940 --> 00:11:39.780
يجب أن تكون حزمة التحكم الخاصة بك في ميكروسوفت 365 مألوفة لفريقك

00:11:39.780 --> 00:11:43.060
أن تستخدم الهوية في إنترا وحدود البيانات من خلال بورفيو

00:11:43.060 --> 00:11:44.440
والمراقبة من خلال ديفيندر

00:11:44.440 --> 00:11:47.060
أن تطبق شروط الوصول من خلال الوصول المشروط

00:11:47.060 --> 00:11:49.480
وتضمن دمج قابلية التدقيق منذ البداية

00:11:49.480 --> 00:11:54.400
يجب أن تكون قادرا على إعادة بناء ما حدث بالضبط دون الحاجة إلى التخمين بعد وقوع حادث

00:11:54.400 --> 00:11:58.680
يجب تصميم الرقابة البشرية ضمن منطق العمل بدلا من الارتجال أثناء الأزمات

00:11:58.680 --> 00:12:02.200
يجب أن تتوقف الإجراءات ذات التأثير العالي دائما بانتظار توقيع بشري

00:12:02.200 --> 00:12:05.980
يجب تسجيل أسباب اتخاذ القرارات بصيغة يمكن للأشخاص فحصها وفهمها فعليا

00:12:05.980 --> 00:12:10.060
يجب أن تتوفر لديك مسارات للتراجع قبل أن يبدأ أول إجراء ذاتي بالعمل

00:12:10.060 --> 00:12:12.760
إذا قام وكيل بتحديث صلاحيات الوصول أو تغيير سياسة التوجيه

00:12:12.760 --> 00:12:16.220
فيجب أن يكون لدى شخص ما طريقة لتتبع ذلك القرار والتراجع عنه بشكل نظيف

00:12:16.220 --> 00:12:20.000
هناك عامل آخر يغفل عنه القادة غالبا لأن العروض التوضيحية المبكرة تبدو جيدة جدا

00:12:20.000 --> 00:12:21.440
تكلفة إعادة العمل

00:12:21.440 --> 00:12:25.780
إذا تسبب الوكيل في خلق حلقات تنظيف لفريقك فإن الوفرات المتوقعة ستتلاشى فورا

00:12:25.780 --> 00:12:30.040
هذه هي ضريبة إعادة العمل وهي الوقت الذي يقضيه الفريق في تصحيح المخرجات السيئة

00:12:30.040 --> 00:12:33.000
أو عكس الإجراءات الخاطئة أو تتبع الآثار الجانبية غير المقصودة

00:12:42.760 --> 00:12:46.560
بل تأتي من الأدلة الملموسة أثناء التشغيل

00:12:46.560 --> 00:12:50.120
يحتاج الناس إلى رؤية ما رأاه الوكيل وما قرره وما تغير بالفعل في النظام

00:12:50.120 --> 00:12:52.680
هذه هي الطريقة التي تبني بها ثقة في الدعم الذاتي

00:12:52.680 --> 00:12:56.320
يجب أن يكمن الدليل في سلوك الأدات لا في العلامة التجارية للمشروع

00:12:56.320 --> 00:12:58.500
بمجرد أن تصبح أسس الحوكمة راسخة

00:12:58.500 --> 00:13:01.920
يمكن للحوار أخيرا تجاوز مصطلحات الأمن إلى لغة تنفيذية

00:13:01.920 --> 00:13:04.760
ما الذي يغيره هذا بالفعل بالنسبة للنتائج المالية النهائية

00:13:04.760 --> 00:13:07.100
العائد الجديد على الاستثمار للدعم غير المرئي

00:13:12.760 --> 00:13:16.240
مثل التذاكر المغلقة والمكالمات المعالجة وأداء اتفاقية مستوى الخدمة

00:13:16.240 --> 00:13:19.740
تظل تلك الأرقام مهمة لكنها تصف فقط رد الفعل تجاه مشكلة ما

00:13:19.740 --> 00:13:22.320
فهي لا تخبرك بحجم الانقطاعات التي لم تصل إلى قائمة الانتظار

00:13:22.320 --> 00:13:25.360
أو مقدار وقت الموظف الذي ظل سليما لأن المشكلة تم وعدها مبكرا

00:13:25.360 --> 00:13:27.480
تلك هي المشكلة المحاسبية الجوهرية

00:13:27.480 --> 00:13:30.120
الدعم غير المرئي يخلق القيمة من خلال الغياب

00:13:30.120 --> 00:13:32.820
تدرك القيمة عندما لا توجد تذكرة ولا تصعيد

00:13:32.820 --> 00:13:37.280
ولا محلل يقضي عشرون دقيقة في إعادة بناء مشكلة من ملاحظات غير مكتملة

00:13:37.280 --> 00:13:39.620
إذا قصت فقط الجهد المرئي لفريق الدعم

00:13:39.620 --> 00:13:42.060
فستغفل النتيجة التي أردتها حقا

00:13:42.060 --> 00:13:44.660
لقد أردت عملا مستقرنا مع انقطاعات أقل

00:13:44.660 --> 00:13:47.860
حجم التذاكر هو مؤشر ضعيف عندما يتم النظر إليه منفردا

00:13:47.860 --> 00:13:49.460
قد يعني انخفاض التذاكر تراجع الطلب

00:13:49.460 --> 00:13:52.840
لكنه قد يعني أيضا أن البيئة أصبحت أكثر صحة وطبقة الدعم أكثر ذكاء

00:13:52.840 --> 00:13:54.860
تلك قصتان مختلفتان تماما

00:13:54.860 --> 00:13:58.720
يحتاج التنفيذيون إلى مجموعة مؤشرات أداء رئيسية قادرة على التمييز بينهما

00:13:58.720 --> 00:14:01.340
يجب أن تبدأ بالنظر إلى معدل الحل الذاتي

00:14:01.340 --> 00:14:04.180
لا يتعلق الأمر بعدد المحادثات التي أجراها البوتو

00:14:04.180 --> 00:14:07.460
بل بعدد أحداث الدعم التي تم حلها بالكامل دون تدخل بشريا

00:14:07.460 --> 00:14:10.340
تحتاج أيضا إلى تتبع الانخفاض في متوسط وقت الحل

00:14:10.340 --> 00:14:11.980
في البيئات المعتمدة على ذكاء الاصطناعي

00:14:11.980 --> 00:14:15.740
تشهد المسارات التي تتطلب تشخيصا مكثفا تحسينات تتراوح بين 40 و60%

00:14:15.740 --> 00:14:19.640
بعد ذلك يمكنك النظر إلى تكلفة الحل والإنتاجية التي استعادتها للمستخدم

00:14:19.640 --> 00:14:24.120
من السهل تجاهل هذا المقياس الأخير لأنه لا يندرج بدقة في تقارير مكاتب الخدمة القياسية

00:14:24.120 --> 00:14:26.960
ومع ذلك غالبا ما تكمن القيمة الحقيقية هناك

00:14:26.960 --> 00:14:31.960
الشخص الذي يتعطل لمدة 15 دقيقة قبل أن يفتح تذكرة قد تسبب بالفعل في تكلفة على الشركة

00:14:31.960 --> 00:14:35.200
عندما تضرب ذلك في انقطاعات الاجتماعات وصعوبات الوصول عبر مؤسسة كبيرة

00:14:35.200 --> 00:14:38.320
تكون الخسارة الخفية أكبر بكثير مما تشير إليه قوائم الانتظار

00:14:38.320 --> 00:14:42.120
ولهذا السبب يعد نموذج تكلفة التقاعس مهما جدا لدراسة الجدوى التجارية

00:14:42.120 --> 00:14:45.920
أن تحسب الساعات التي تقضيها في الجفد اليدوي قبل أن يبدأ الدعم الرسمي حتى

00:14:45.920 --> 00:14:48.200
ثم أضف تكلفة الأخطاء وتكرار العمل

00:14:48.200 --> 00:14:51.500
فجأة تتوقف حجة الاستباق عن كونها مجرد نظرية

00:14:51.500 --> 00:14:54.160
أنت لا تمول مجرد طبقة دعم مستقبلية

00:14:54.160 --> 00:14:57.300
أنت تزيل ضريبة كانت كامنة في عملك اليومي لسنوات

00:14:57.300 --> 00:15:00.080
اقتصادية الحالة المحددة تجعل هذا الأمر أكثر وضوحا

00:15:00.080 --> 00:15:02.240
تشير أبحاث دعم تكنولوجيا المعلومات المعتمد على الوكلاء

00:15:02.240 --> 00:15:05.860
إلى أن تكلفة المعالجة البشرية تبلغ حوالي 8.75 دولار لكل مشكلة

00:15:05.860 --> 00:15:08.580
في المقابل يمكن أن تنخفض تكلفة المعالجة المحددة بالوكيل

00:15:08.580 --> 00:15:10.920
إلى أقل من 50 سنة لكل مشكلة بمجرد تطوير النظام

00:15:10.920 --> 00:15:13.100
هذا لا يعني أن كل إجراء دعم سيكون بهذا الرخص

00:15:13.100 --> 00:15:15.740
وعلى القادة توخي الحذر عند استخدام المتوسطات العامة

00:15:15.740 --> 00:15:17.160
ستؤثر جودة البيانات الوصفية

00:15:17.160 --> 00:15:19.640
والحوكمة دائما على التكلفة النهائية

00:15:19.640 --> 00:15:21.220
لكن اتجاه المسار لا لبس فيه

00:15:21.220 --> 00:15:23.820
هذه هي اللحظة التي تخرج فيها تكنولوجيا المعلومات من قصة

00:15:23.820 --> 00:15:25.160
مركز التكلفة القديمة

00:15:25.160 --> 00:15:26.580
ليس لأن الدعم يختفي

00:15:26.580 --> 00:15:31.240
بل لأن الدعم يتحول إلى طبقة موثوقية تحمي إنتاجية الموظفين في الخلفية

00:15:31.240 --> 00:15:35.360
تشعر الشركة بهذا كعمل أكثر سلاسة بدلا من حدث دعم دراماتيكي

00:15:35.360 --> 00:15:37.920
تحصل على مقطعات أقل واستعادة أسرع

00:15:37.920 --> 00:15:40.100
وجهد أقل مهدر في التوجيه والتوضيح

00:15:40.100 --> 00:15:43.340
مع ذلك يمكن للقياس السيئ أن يزيف التقدم بسهولة

00:15:43.340 --> 00:15:44.920
إذا كانت بياناتك الوصفية ضعيفة

00:15:44.920 --> 00:15:48.020
فقد يكتفي الوكيل بتلخيص الفشل بشكل أسرع بدلا من منعه فعليا

00:15:48.020 --> 00:15:49.720
إذا ظل العمل المعاد خارج لوحة البيانات

00:15:49.720 --> 00:15:52.240
فسيبدو عائد الاستثمار أنظف بكثير مما هو عليه في الواقع

00:15:52.240 --> 00:15:54.940
إذا تسرب الوقت المسترد إلى أنشطة منخفضة القيمة

00:15:54.940 --> 00:15:56.960
فسيبالغ القادة في تقدير المكاسب

00:15:56.960 --> 00:15:59.340
يجب أن تظل الحالة المالية مبنية على أدلة طوية

00:15:59.340 --> 00:16:01.800
مثل الحوادث التي تم منعها وتقليل التدخلات اليدوية

00:16:01.800 --> 00:16:04.740
عليك قياس الوقت الذي عاد فعليا إلى العمل المفيد

00:16:04.740 --> 00:16:06.480
بمجرد قياس ذلك بشكل صحيح

00:16:06.480 --> 00:16:09.460
تتوقف وظيفة الدعم عن كونها نفقات عامة يجب تقليصها

00:16:09.460 --> 00:16:12.940
تبدأ في الظهور كقدرة تشغيلية تستعيدها الشركة أخيرا

00:16:12.940 --> 00:16:14.860
ماذا يفعل هذا بفريق الدعم

00:16:14.860 --> 00:16:17.280
فكر فيما يفعله هذا حقا للفريق على أرض الواقع

00:16:17.280 --> 00:16:19.900
لأن هذا التحول لا يتعلق بتقليص عدد الموظفين

00:16:19.900 --> 00:16:22.340
بل بتغيير ما يفعله أفرادك فعليا في يومهم

00:16:22.340 --> 00:16:25.940
في الإعداد القديم تستهلك معظم قدرة الدعم لديك في إعادة تعيين كلمات المرور

00:16:25.940 --> 00:16:28.520
وتوجيه التذاكر وحلقة التوضيح التي لا تنتهي

00:16:28.520 --> 00:16:33.140
لديك أشخاص يطاردون التحديثات وينقلون البيانات بين أنظمة لم تصمم أبدا للتحدث مع بعضها البعض

00:16:33.140 --> 00:16:35.580
لا شيء من ذلك العمل يجعل البيئة أكثر استقرارا

00:16:35.580 --> 00:16:37.480
إنه فقط يمنع طفح قائمة الانتظار

00:16:37.480 --> 00:16:40.100
عندما يتولى الوكلاء هذا العمل الروتيني المتوقع

00:16:40.100 --> 00:16:42.480
يرتق الجهد البشري أخيرا إلى مستوى أعلى

00:16:42.480 --> 00:16:46.040
يبدأ مهندس الدعم في قضاء وقتهم في تحديد شكل الحالة السليمة

00:16:46.040 --> 00:16:47.760
وضبط المنطق وراء الموافقات

00:16:47.760 --> 00:16:51.260
إنهم يركزون على تحسين مصادر المعرفة واختبار سلوك السياسات

00:16:51.260 --> 00:16:53.920
والتأكد من بقاء الوكيل ضمن الحدود التي ودعت له

00:16:53.920 --> 00:16:57.260
هذه وظيفة مختلفة تماما عن التحديق في سطور الموضوع طوال اليوم

00:16:57.260 --> 00:16:59.300
ومحاولة تخمين ما يريده المستخدم حقا

00:16:59.300 --> 00:17:02.380
هذا هو بالضبط المكان الذي تتعثر فيه معظم عمليات النشر

00:17:02.380 --> 00:17:04.920
تحاول المؤسسات الحفاظ على عملياتها القديمة المعطلة

00:17:04.920 --> 00:17:07.740
وتكتفي بإضافة وكيل ذكي فوقها متوقعة النتائج أفضل

00:17:07.740 --> 00:17:09.160
لكن العملية تظل تفاعلية

00:17:09.160 --> 00:17:10.900
وعمليات التسليم لا تزال فوضوية

00:17:10.900 --> 00:17:12.720
والمعرفة الأساسية لا تزال ضعيفة

00:17:12.720 --> 00:17:15.660
يصبح الوكيل مجرد طبقة طلاء أخرى على جدار متداع

00:17:15.660 --> 00:17:17.200
قد يجيب على سؤال بشكل أسرع

00:17:17.200 --> 00:17:19.820
لكنه لا يستطيع إصلاح نموذج دعم بني أساسا على التأخير

00:17:19.820 --> 00:17:22.300
الطريقة الأفضل هي إعادة تصميم العمل أولا

00:17:22.300 --> 00:17:26.780
عليك أن تقرر أي المهام تظل بشرية لأنها تتطلب حكما أو تواصلا حساسا

00:17:34.920 --> 00:17:37.560
ببساطة إلى أشخاص يصممون الضوابط ويتعاملون مع الاستثناءات

00:17:37.560 --> 00:17:40.400
هذا يعني أن الطريقة التي ندرب بها الناس يجب أن تتغير أيضا

00:17:40.400 --> 00:17:44.520
تحتاج الفرق إلى تعلم كيفية الإشراف على نظام بدلا من مجرد تنفيذ مهمة يدوية

00:17:44.520 --> 00:17:47.440
يحتبنا إلى فهم منطق التراجع ومراجعة التدقيق

00:17:47.440 --> 00:17:49.480
وكيفية اختبار الوكيل قبل تشغيله

00:17:49.480 --> 00:17:51.820
يجب أن يكونوا قادرين أيضا على اكتشاف فشل النموذج

00:17:51.820 --> 00:17:54.540
لأن سير العمل السيء المؤتمد يظل سير عمل سيئا

00:17:54.540 --> 00:17:56.520
إنه فقط يفسد الأمور بسرعة أكبر

00:17:56.520 --> 00:17:57.800
إذا كنت توظف لهذا المستقبل

00:17:57.800 --> 00:18:00.500
فمن المحتمل أنك لا تحتاج إلى موظف عام آخر لفرز التذاكر

00:18:00.500 --> 00:18:04.040
أنت بحاجة إلى شخص يمكنه تنسيق التدفقات عبر حزمة مايكروسوفت 365

00:18:04.040 --> 00:18:06.440
وتحديد الضوابط التي تبقي الوكلاء تحت سيطرة

00:18:06.440 --> 00:18:08.680
أنت تريد أشخاص يمكنهم تحسين البيئة

00:18:08.680 --> 00:18:11.640
بحيث ينخفض طلب الدعم فعليا بدلا من تراكمه

00:18:11.640 --> 00:18:16.200
إذن كيف تبدأ هذا فعليا دون أن يتحول إلى مشروع تحول ضخم يستغرق سنوات

00:18:16.200 --> 00:18:21.720
أفضل خطوة هي اختيار تدفق واحد يسبب احتكاكا مستمرا داخل بيئة مايكروسوفت 365 الخاصة بك

00:18:21.720 --> 00:18:24.040
غالبا ما يكون إصلاح الوصول مرشحا رائعا

00:18:24.040 --> 00:18:27.200
ولكن يمكنك أيضا النظر في دعم الاجتماعات أو تسليمات امتثال الأجهزة

00:18:27.200 --> 00:18:30.360
لا يهم أينا منها تختار طالما أن النمط يتكرر كثيرا

00:18:30.360 --> 00:18:33.060
وتعرف بالضبط كيف يجب أن تبدو النتيجة الناجحة

00:18:33.060 --> 00:18:36.960
بمجرد تحديد الهدف يجب عليك تحديد الأساسيات بانضباط حقيقي

00:18:36.960 --> 00:18:42.280
يجب أن تعرف كيف تبدو الحالة السليمة وما هي الأحداث المحددة التي تخبرك أن الأمور تحيد عن مسارها

00:18:42.280 --> 00:18:46.520
حدد الإجراءات الآمنة للأتمتة وأين بالضبط يجب أن يبدأ التصعيد البشري

00:18:46.520 --> 00:18:50.700
قبل إطلاق أي شيء تأكد من وضع خط أساس لأعداد التذاكر والتدخلات اليدوية

00:18:50.700 --> 00:18:52.880
ومدة انتظار المستخدمين حاليا للحصول على حل

00:18:52.880 --> 00:18:55.820
يجب عليك أيضا وضع حوكمتك موضع التنفيذ منذ اليوم الأول

00:18:55.820 --> 00:18:58.920
أمنح الوكيل هوية محددة وعين له مالكنا بشريا

00:18:58.920 --> 00:19:00.700
وحدد قواعد موافقة واضحة

00:19:00.700 --> 00:19:03.220
يجب تسجيل كل إجراء يتخذه الوكيل

00:19:03.220 --> 00:19:08.900
يجب أن يكون لديك أيضا خطة لإيقاف الوكيل أو إعادة تعيينه حتى لا يتحول إلى أتمتة مهجورة

00:19:08.900 --> 00:19:10.820
عندما تبدأ تلك العملية الأولى في العمل

00:19:10.820 --> 00:19:12.860
يبدأ نموذج التشغيل بالكامل في التحول

00:19:12.860 --> 00:19:16.520
يتوقف الدعم عن التصرف كمكتب استقبال يكتفي برد الفعل تجاه المشكلات

00:19:16.520 --> 00:19:20.960
بدلا من ذلك يبدأ في العمل كمحرك موثوقية مدمج مباشرة في النظام

00:19:20.960 --> 00:19:24.040
يتحول الدعم من رد فعل مرئي إلى وقاية مضمنة

00:19:24.040 --> 00:19:25.980
لم تكن التذكرة هي الخدمة أبدا

00:19:25.980 --> 00:19:28.420
بل كانت دليلا على أن الخدمة وصلت متأخرة جدا

00:19:28.420 --> 00:19:32.440
اختر مسار دعم وحدا هذا الربع وأعد تصميمه ليكون استباقيا بدلا من أن يكون استجابيا

00:19:32.440 --> 00:19:37.080
إذا أردت المزيد حول M365 كوبايلوت وأشر والأمانة ونماذج تشغيل الذكاء الاصطناعي

00:19:37.080 --> 00:19:39.820
اشترك في M365 FM وترك تقييما

00:19:39.820 --> 00:19:44.020
تواصل معي ميركو بيتر على لينكتن لاقتراح الموضوع التالي الذي تود مني شرحه