تبدو أنظمة التذاكر مثالية على الورق تحصل على الأرقام وقوائم الانتظار ولوحات البيانات لكن في الواقع هذا النموذج يقيس المعاناة فقط بعد تعطل النظام بالفعل الجزء المكلف من المشكلة يبدأ عادة في وقت أبكر بكثير يبدأ عندما يهدر الموظف عشر دقائق ثم عشرون ثم يستسلم في النهاية يحاولون مجددا يسألون زميلا في العمل يفوتنا الاجتماع أو يشاركون ملفا خاطئا لأن المسار الصحيح توقف عن العمل وهذا هو الجزء الذي لا تزال معظم فرق الدعم لا تراه أفضل نموذج للدعم الداخلي اليوم لا يتعلق بفرز أسرع للتذاكر بل يتعلق بإزالة الحاجة إلى الفرز تماما تخيل وكيلا مستقلا داخل مايكروسوفت 365 يراقب السياقة ويكتشف المعويقات مبكرا ويتصرف قبل أن يفكر أي شخص في فتح بوابة دعم في هذه الحلقة أريد أن أوضح لك لماذا ينهار نموذج مكتب المساعدة وما الذي يحل محله فعليا وكيف يمكنك إدارته دون التسبب في فوضى إذا كان هذا التحول يهم عملك اشترك في M365F لأن المشكلة الحقيقية على مستوى أعمق ليست قائمة الانتظار بل النموذج الكامن خلفها موت التذكيراتي تدفق الدعم القديم لا يزال موجودا في كل مكان شيء ما يتعطل مستخدم يلاحظ ذلك المستخدم يحاول شرحه ثم يقوم قسم تكنولوجيا المعلومات بترجمة ذلك الشرح إلى فئة وأولوية وربما مجموعة إسناد تدخل المشكلة في قائمة انتظار يقوم شخص ما بفرزها يطلب شخص آخر المزيد من التفاصيل يتم إشراك فريق آخر الوقت يمضي بينما يظل العمل الفعلي عالقا تبدو هذه العملية طبيعية لأنها مألوفة لكن المألوفة والفعالة ليس الشيء نفسه التذكرة ليست دعما التذكرة هي دليل على أن الدعم وصل متأخرا بحلول الوقت الذي توجد فيه تذكرة يكون الموظف قد واجه بالفعل عقبات وفقد سياق عمله لقد حولوا انتباههم بالفعل بعيدا عن العمل الذي كانوا يحاولون القيام به قائمة الانتظار ليست هي الخدمة قائمة الانتظار هي سجل للفشل في بيئات مايكروسوفت 365 الكبيرة يصبح الفرز يدويه وعنق الزجاجة الحقيقي هذا لا يحدث لأن فرق الدعم كسولة يحدث لأن البشر يطلب منهم القيام بشيء لم يعد يناسب حجم البيئة لديك المزيد من المستخدمين والمزيد من الأجهزة والمزيد من التطبيقات والمزيد من السياسات لديك المزيد من الحالات الاستثنائية التي تعبر بين الفرق وشيربوينت واكستشينج وانتون وانترا في نفس الوقت تماما الحجم لا ينمو فحسب التركيبات هي التي تنمو هنا ينهار النموذج القديم معظم الفرق تستجيب بإضافة المزيد من الهياكل يبنون بوابة أخرى أو روبوت آخر أو قاعدة توجيه أخرى لكن في الواقع هذا يضيف فقط طبقة أخرى بين الموظف والحل لا يزال النظام ينتظر من المستخدم ملاحظة المشكلة ووصفها وطلب المساعدة بالطريقة الصحيحة لا يبدأ العمل في بوابة دعم بل يبدأ في تينز وفي أوتلوك وفي مستند يحتاجه شخص ما الآن أو اجتماع سيبدأ بعد ثلاثون ثانية هنا يبدأ طلب الدعم فعليا ونموذج التذاكر منفصل تماما عن تلك اللحظة التكلفة الخفية أكبر بكثير مما يظهره تقرير قائمة الانتظار لديك الموظفون يغيرون سياق مهامهم باستمرار تتراكم الحوادث المتطابقة تحت مسميات مختلفة تتقادم مقالات المعرفة وتفقد قيمتها يقضي المحللون يومهم بالكامل في التصنيف والتوجيه والتوضيح بدلا من إصلاح الأشياء فعليا يمتد وقت الحل لأن كل عملية تسليم تضيف تأخيرا وكل تأخير يجرد المشكلة من سياقها الأصلي تشير الأبحاث حول ذكاء الاصطناعي الوكيل وعمليات تكنولوجيا المعلومات إلى نفس المشكلة الهيكلية لا تزال نسبة 80% على الأقل من الجهد حبيسة العمل التفاعلي بأسلوب ATAL هذا الرقم مهم لأنه يخبرك بالضبط أين تذهب الجهود البشرية إنها لا تذهب نحو المرونة أو الوقاية بل تذهب نحو رد الفعل بمجرد أن تدرك ذلك تبدأ التذكرة في الظهور كعرض جانبي وليست نموذج تشغيل إنه عرض لنظام لا يستجيب إلا بعد أن يصبح الضرر مرئيا لذا السؤال التالي ليس كيف نعالج التذاكرة بشكل أسرع بل ما الذي يجب أن يفعله النظام قبل الحاجة إلى تذكرة نموذج الموظف غير المرئي إذن ما الذي يحل محل التذكرة فعليا إنه ليس مجرد روبوت محادثة آخر يجلس فوق نفس الفوضى وبالتأكيد ليس واجهة أجمل لنفس قائمة الانتظار القديمة التحول أعمق من ذلك بكثير لأن الموظف غير المرئي هو عامل تشغيلي يعيش داخل بيئة مايكروسوفت 365 الخاصة بك هذا الوكيل لديه هويته الخاصة ونطاق عمل محدد وذاكرة لما فعله بالأمس وقواعد صارمة بشأن ما يمكنه وما لا يمكنه لمسه هذا التمييز مهم ينتظر روبوت المحادثة منك كتابة طلب لكن الموظف غير المرئي يراقب تغير الظروف إنه يبدأ من السياق بدلا من البدء بمحادثة لأنه يستطيع رؤية حالات تسجيل الدخول وصحة الأجهزة وحالة التراخيص وكيفية مشاركة الملفات فلا دعي الانتظار ظهور المشاكل بدلا من السؤال عن كيفية المساعدة بعد حدوث العطل فإنه يطرح باستمرار سؤالا مختلفا في الخلفية ما الذي يبتعد عن الحالة التي يحتاجها هذا الموظف للقيام بعمله الآن هنا تتغير الأمور النموذج مدمج مباشرة داخل العمل نفسه عندما ينضم شخص إلى اجتماع ويفشل توجيه الصوت أو لا يستطيع ضيف فتح ملف أرسل إليه للتو فإن العالم القديم ينشئ تقريرا وعملية تسليم في النموذج الجديد يكتشف الوكيل نمط فورا ويتحقق مما إذا كانت الحالة تطابق مشكلة معروفة ثم يتخذ الإجراء الآمن التالية لإصلاحها ربما يقوم بإعادة ضبط مسار أو تفعيل فحص سياسة أو ربما يعيد توجيه طلب ويطلب التحقق متعدد العوامل MFA قبل توثيق الإصلاح الأمر بسيط لم تعد الاستجابة الأولى تتطلب من البشر قراءة وصف غامض وتخمين ما حدث يبدو هذا غير مرئيا عندما يعمل بشكل جيد فلا توجد غرفة امتظار ولا نموذج يرجى اختيار فئة لملئه يظهر الدعم كاستعادة لسير العمل يعود الموظف إلى عمله ببساطة وفي كثير من الحالات لا يرى حتى الآليات التي تعمل في الخلفية يمكنك بالفعل رؤية كيف يغير هذا منطق التوظيف لديك النموذج القديم يوظف أشخاصا لاستعاب حجم الطلبات وتصنيفها وإصلاح السياقات المقطوعة بين الفرق المختلفة يحتاج النموذج الجديد إلى عدد أقل من الأشخاص للفرز والمزيد من الأشخاص لتصميم الضوابط وتحديد الحالات المطلوبة والإشراف على سلوك هؤلاء الوكلاء بمرور الوقت يظل البشر جزءا من النظام لكن شكل عملهم اليومي يتغير بالكامل تستمر الأبحاث حول الذكاء الاصطناعي الوكيل في الدعم في الإشارة إلى هذا الاتجاه يمكن للدعم الروتيني الانتقال نحو المعالجة القائمة على الاستثناءات مما يخلق مكاسب هائلة في الكفاءة عندما تكون البيئة والسياسات محددة جيدا هذا الجزء الأخير حيوي لأن هذا ليس سحرا إذا كانت بياناتك ضعيفة أو عمليتك فوضوية فلن يصبح الوكيل ذكيا لمجرد أنك قررت تسميته مستقلا اتضح لي الأمر تماما عندما توقفت عن التفكير في الوكيل كميزة برمجية وبدأت في اعتباره موظفا غير بشري يحمل بطاقة تعريف يحتاج العامل الحقيقي إلى هوية ووصف وظيفي وصلاحيات ومدير يرفع تقاريره إليه يحتاج الوكيل إلى نفس هذه الأشياء تماما لأن القيمة تأتي من العمل الموثوق داخل النظام وليس من اللغة الذكية في نافذة الدردشة الموظف غير المرئي ليس مجرد خدعة في واجهة المستخدم إنه طبقة دعم جديدة تراقب الاحتكاك عبر بيئة مايكروسوفت 365 وتعمل ضمن السياسة وتوجه انتباه البشر نحو الاستثناءات التي تحتاج فعليا إلى حكم بشريا بمجرد أن يصبح هذا النموذج واضحا يصبح السؤال التالي عمليا جدا كيف تعمل الاستباقية فعليا بنية الاستباقية إذن كيف تعمل الاستباقية فعليا داخل مايكروسوفت 365 ينتقل التحول من الطلب والاستجابة إلى التفكير في الأحداث والتنسيق يبدو هذا تقنيا لكن النموذج بسيط بمجرد تفكيكه أولا يتغير شيء ما في البيئة ثم يفسر النظام ما إذا كان هذا التغير يعني مخاطرة أو انحرافا وأخيرا يتخذ الإجراء المعتمد باستخدام الأدوات الموجودة بالفعل في حزمتك ابدأ بطبقة الأحداث تنتج مايكروسوفت 365 بالفعل إشارات في كل مكان مما يعني أن انترا يرى سلوك تسجيل الدخول بينما يتتبع انتون حالة الجهاز والامتثال يراقب ديفيندر أي نشاط مشبوه ويوضح لك تيمز بالضبط متى يفشل الاجتماع أو تنخفض جودة المكالمة تكشف شيربوينت واكستشينج عن أنماط الوصول ونشاط المحتوى بينما تخبرك إشارات صحة الخدمة عندما تكون المنصة نفسها هي المشكلة عندما تضيف إجراءات المستخدم فوق ذلك تحصل على تدفق مستمر من السياق تجمع معظم المؤسسات تلك الإشارات لكن قلة قليلة منها تستخدمها فعلياً كنظام دعم الأحداث الأولية وحدها لا تساعد لأنها تحتاج إلى طبقة تفكير لفهم هذا الضجيج هنا يتوقف الموظف الخفي عن كونه مجرد عرضاً للأتمتة ويبدأ في العمل كمشغل حقيقي ينظر الوكيل إلى الإشارة ويقارن الحالة الحالية بالحالة المطلوبة ويقرر نوع الإجراء الآمن الذي يمكن اتخاذه مشكلة صوت الاجتماع ليست مثل تسجيل دخول محفوف بالمخاطر ورابط المشاركة المعطل يختلف عن عدم تطابق الترخيص يجب على الوكيل تصنيف المشكلة أولاً لأن اتخاذ إجراء دون تصنيف يؤدي إلى ارتكاب أخطاء بشكل أسرع ثم يأتي دور التنسيق بمجرد أن يفهم الوكيل المشكلة يمكنه استخدام الآلية المناسبة للاستجابة قد يكون ذلك Power Automate لسير العمل أو Co-Pilot Studio للمنطق أو Microsoft Graph لإجراءات النظام والسياق الأدوات مهمة لكن النقطة الأهم هي كيفية اتصالها ببعضها البعض أنت لا تبني مطالبة ذكية واحدة بل سلسلة يمكنها الاكتشاف والقرار والتنفيذ والتحقق هذا الجزء الأخير يتم تجاهله طوال الوقت النظام الذي يصح ذاته لا يتوقف بمجرد اتخاذ الإجراء إنه يعمل في حلقة حيث يكتشف المشكلة ويختبر الحالة ويطبق الإصلاح ويتحقق من النتيجة قبل تسجيل ما حدث توضح الأبحاث حول المنطق التصحيحي الذاتي أن هذه الأنظمة تعمل من خلال أنماط التغذية الراجعة والتصحيحي بدلاً من إجابة واحدة معزولة من نموذجاً لغوياً إذا فشل الإجراء الأول يحتاج النظام إلى طريقة لتقييم السبب حتى يتمكن من مراجعة الخطوة التالية مع البقاء ضمن الحدود المحددة يمكنك تصور هذا بوضوح في بعض حالات Microsoft 365 عندما يتم حضر مستخدم لأن ترخيصه ونطاق سياسته لا يتطبقان يكتشف الوكيل عدم التطابق ويتحقق من ملف تعريف الدور المقصود يطبق التصحيح المسموح به ويؤكد حصول المستخدم على الوصول ويسجل التغيير دون الحاجة لسؤال أي شخص إذا ظهر تسجيل دخول محفوف بالمخاطر في إنترا يرى الوكيل حدث الخطر ويتحقق من قواعد الوصول المشروط الخاصة بك على الفور يطلب التحقق بشكل أقوى أو يحضر الوصول بناء على سياستك ثم يسجل النتيجة ليراجعها شخص ما لاحقا عندما يستمر فشل رابط مشاركة قديم في SharePoint يقوم الوكيل بمقارنة مسار الأذنات الحالي بقواعد المشاركة المتوقعة يستبدل الوكيل الرابط التالف بالرابط المعتمد ويرسل الرابط المصح في سياقه مما يغلق دائرة المشكلة قبل أن يضطر أي محلل تقني لقراءة تذكرة بعنوان مشكلة وصول عاجلة دعم الاجتماعات مثال رائع آخر إذا تعطل جهاز في الغرفة أو انقطع مسار الاندمام قبل ثوان من بدء المكالمة يمكن للوكيل اكتشاف الحالة والتحقق من العطل يحاول الوكيل إجراء خطوة استرداد منخفضة المخاطر ويخطر المنظم عبر تيمز بتحديث للحالة في مكان العمل نفسه تعد طبقة التواصل هذه جزءا كبيرا من التصميم يجب أن يتواجد الدعم حيثما يحدث الانقطاع إذا كان عملك يتم في تيمز وأوتلوك ومساحة عمل 365 فيجب أن يستجيب الدعم لك هناك أيضا لا ينبغي عليك نقل المستخدم إلى مكان آخر بينما يمكنك معالجة الحدث في سياقه هذا لا يعني الأتمتة الكاملة لكل مهمة لأن ذلك سيكون تهورا يمكن تنفيذ الإجراءات منخفضة المخاطر تلقائيا لكن تغييرات ذات التأثير العالية لا تزال تتطلب موافقة بشرية يجب أن يكون مسار الموافقة هذا جزءا من البنية الأساسية منذ البداية بدلا من إضافته لاحقا يجب أن يعرف الوكيل متى يتصرف ومتى يطلب الإذن ومتى يتوقف تماما وبمجرد دمج ذلك في سير العمل يتوقف الحديث عن كونه مجرد ميزات أتمتة يصبح الأمر متعلقا بالتحكم والحوكمة والثقة وهوية الوكيل عندما يبدأ الدعم في التصرف من تلقاء نفسه يظهر سؤال صعب على الفور من الذي يقوم بالعمل فعليا إذا كانت الإجابة غامضة فإن النموذج بأكمله ينهار لا يمكن للوكيل أن يوجد في بيئتك كمساعد غامض يتمتع بوصول واسع وبدون مالك واضح إنه يحتاج إلى هوية حقيقية في إنترا يحتاج إلى مالك مسمنة ونطاق محدد ودورة حياة تبدأ وتنتهي لسبب معين إذا كان بإمكان هذا الوكيل قراءة البيانات أو تشغيل مهام سير العمل أو مراسلة مستخدمك فيجب عليك إدارته كمشارك نشط في المستأجر لا يمكنك التعامل معه كميزة قام شخص بتشغيلها ثم نسي أمرها لهذا السبب تعد هوية الوكيل أمراً بالغ الأهمية للنظام يجب أن تعرف بالضبط ما هو الوكيل والأنظمة التي يمكنه الوصول إليها ومن يتلقى تنبيهها عندما تبدأ الأمور في الانحراف يجب أن يكون مبدأ الامتياز الأقل هو الأساس هنا لا يمكنك الاكتفاء بالراحة العامة أو إقناع نفسك بأنك ستشدد الأذونات لاحقاً لأن نطاق تأثير وكيل الدعم يعتمد كلياً على أذوناته فإن تصميم تلك الأذونات جزء جوهري من تصميم الدعم يعمل أيجنت 365 كطبقة تحكم ضرورية في هذا الأعداد لأنه يتيح رؤية واضحة وشاملة لجميع الوكلاء أيجنت في النظام فهو يوفر السجلة وسر عمل الموافقات ونماذج السياسات التي تضمن سير العمل بأمان وعلى الرغم من أن هذه العناصر قد تبدو كمهام إدارية روتينية إلا أنها تحل مشكلة هيكلية ضخمة لا تعاني معظم المؤسسات بسبب افتقارها لميزات الذكاء الاصطناعي بل لأنها لا تستطيع رؤية أو التحكم فيما يعمل بالفعل في بيئتها الأبحاث حول هذه النقطة مباشرة وصريحة قلة قليلة فقط من المؤسسات الكبيرة يمكنها حصر كل وكيل يعمل حاليا في نظامها بشكل كامل قبل أن يبدأ القادة في الحديث عن توسيع نطاق الدعم الذاتي عليهم الإجابة على سؤال أبسط بكثير هل نعرف أصلا ما هي الوكلاء الموجودة وما الذي تفعله الآن يجب أن تتناسب الرقابة أيضا مع مستوى المخاطر التي تنطوي عليها العمليات وكيل الانتاجية الشخصي الذي يعمل في نطاق ضيق شيء ولكن الوكيل التعاوني الذي يتعامل مع محتوى مشترك شيء آخر تماما ثم هناك وكلاء المؤسسات الذين يتخذون إجراءات عبر سير عمل حساس وهو ما يقع في فئة مختلفة من المخاطر لهذا السبب يعتبر نموذج مناطق المخاطر الشخصي والتعاوني والمؤسسي مهما للغاية يجب أن يرتفع مستوى نموذج التحكم الخاص بك بالتوازي مع التأثير المحتملي إذا عملت كل وكيل بنفس الطريقة فسيتم دفن العمل منخفض المخاطر في موافقة بطيئة بينما تمر الأعمال عالية المخاطر بتدقيق ضعيف على أقل تقدير يجب أن تكون حزمة التحكم الخاصة بك في ميكروسوفت 365 مألوفة لفريقك أن تستخدم الهوية في إنترا وحدود البيانات من خلال بورفيو والمراقبة من خلال ديفيندر أن تطبق شروط الوصول من خلال الوصول المشروط وتضمن دمج قابلية التدقيق منذ البداية يجب أن تكون قادرا على إعادة بناء ما حدث بالضبط دون الحاجة إلى التخمين بعد وقوع حادث يجب تصميم الرقابة البشرية ضمن منطق العمل بدلا من الارتجال أثناء الأزمات يجب أن تتوقف الإجراءات ذات التأثير العالي دائما بانتظار توقيع بشري يجب تسجيل أسباب اتخاذ القرارات بصيغة يمكن للأشخاص فحصها وفهمها فعليا يجب أن تتوفر لديك مسارات للتراجع قبل أن يبدأ أول إجراء ذاتي بالعمل إذا قام وكيل بتحديث صلاحيات الوصول أو تغيير سياسة التوجيه فيجب أن يكون لدى شخص ما طريقة لتتبع ذلك القرار والتراجع عنه بشكل نظيف هناك عامل آخر يغفل عنه القادة غالبا لأن العروض التوضيحية المبكرة تبدو جيدة جدا تكلفة إعادة العمل إذا تسبب الوكيل في خلق حلقات تنظيف لفريقك فإن الوفرات المتوقعة ستتلاشى فورا هذه هي ضريبة إعادة العمل وهي الوقت الذي يقضيه الفريق في تصحيح المخرجات السيئة أو عكس الإجراءات الخاطئة أو تتبع الآثار الجانبية غير المقصودة

بل تأتي من الأدلة الملموسة أثناء التشغيل يحتاج الناس إلى رؤية ما رأاه الوكيل وما قرره وما تغير بالفعل في النظام هذه هي الطريقة التي تبني بها ثقة في الدعم الذاتي يجب أن يكمن الدليل في سلوك الأدات لا في العلامة التجارية للمشروع بمجرد أن تصبح أسس الحوكمة راسخة يمكن للحوار أخيرا تجاوز مصطلحات الأمن إلى لغة تنفيذية ما الذي يغيره هذا بالفعل بالنسبة للنتائج المالية النهائية العائد الجديد على الاستثمار للدعم غير المرئي

مثل التذاكر المغلقة والمكالمات المعالجة وأداء اتفاقية مستوى الخدمة تظل تلك الأرقام مهمة لكنها تصف فقط رد الفعل تجاه مشكلة ما فهي لا تخبرك بحجم الانقطاعات التي لم تصل إلى قائمة الانتظار أو مقدار وقت الموظف الذي ظل سليما لأن المشكلة تم وعدها مبكرا تلك هي المشكلة المحاسبية الجوهرية الدعم غير المرئي يخلق القيمة من خلال الغياب تدرك القيمة عندما لا توجد تذكرة ولا تصعيد ولا محلل يقضي عشرون دقيقة في إعادة بناء مشكلة من ملاحظات غير مكتملة إذا قصت فقط الجهد المرئي لفريق الدعم فستغفل النتيجة التي أردتها حقا لقد أردت عملا مستقرنا مع انقطاعات أقل حجم التذاكر هو مؤشر ضعيف عندما يتم النظر إليه منفردا قد يعني انخفاض التذاكر تراجع الطلب لكنه قد يعني أيضا أن البيئة أصبحت أكثر صحة وطبقة الدعم أكثر ذكاء تلك قصتان مختلفتان تماما يحتاج التنفيذيون إلى مجموعة مؤشرات أداء رئيسية قادرة على التمييز بينهما يجب أن تبدأ بالنظر إلى معدل الحل الذاتي لا يتعلق الأمر بعدد المحادثات التي أجراها البوتو بل بعدد أحداث الدعم التي تم حلها بالكامل دون تدخل بشريا تحتاج أيضا إلى تتبع الانخفاض في متوسط وقت الحل في البيئات المعتمدة على ذكاء الاصطناعي تشهد المسارات التي تتطلب تشخيصا مكثفا تحسينات تتراوح بين 40 و60% بعد ذلك يمكنك النظر إلى تكلفة الحل والإنتاجية التي استعادتها للمستخدم من السهل تجاهل هذا المقياس الأخير لأنه لا يندرج بدقة في تقارير مكاتب الخدمة القياسية ومع ذلك غالبا ما تكمن القيمة الحقيقية هناك الشخص الذي يتعطل لمدة 15 دقيقة قبل أن يفتح تذكرة قد تسبب بالفعل في تكلفة على الشركة عندما تضرب ذلك في انقطاعات الاجتماعات وصعوبات الوصول عبر مؤسسة كبيرة تكون الخسارة الخفية أكبر بكثير مما تشير إليه قوائم الانتظار ولهذا السبب يعد نموذج تكلفة التقاعس مهما جدا لدراسة الجدوى التجارية أن تحسب الساعات التي تقضيها في الجفد اليدوي قبل أن يبدأ الدعم الرسمي حتى ثم أضف تكلفة الأخطاء وتكرار العمل فجأة تتوقف حجة الاستباق عن كونها مجرد نظرية أنت لا تمول مجرد طبقة دعم مستقبلية أنت تزيل ضريبة كانت كامنة في عملك اليومي لسنوات اقتصادية الحالة المحددة تجعل هذا الأمر أكثر وضوحا تشير أبحاث دعم تكنولوجيا المعلومات المعتمد على الوكلاء إلى أن تكلفة المعالجة البشرية تبلغ حوالي 8.75 دولار لكل مشكلة في المقابل يمكن أن تنخفض تكلفة المعالجة المحددة بالوكيل إلى أقل من 50 سنة لكل مشكلة بمجرد تطوير النظام هذا لا يعني أن كل إجراء دعم سيكون بهذا الرخص وعلى القادة توخي الحذر عند استخدام المتوسطات العامة ستؤثر جودة البيانات الوصفية والحوكمة دائما على التكلفة النهائية لكن اتجاه المسار لا لبس فيه هذه هي اللحظة التي تخرج فيها تكنولوجيا المعلومات من قصة مركز التكلفة القديمة ليس لأن الدعم يختفي بل لأن الدعم يتحول إلى طبقة موثوقية تحمي إنتاجية الموظفين في الخلفية تشعر الشركة بهذا كعمل أكثر سلاسة بدلا من حدث دعم دراماتيكي تحصل على مقطعات أقل واستعادة أسرع وجهد أقل مهدر في التوجيه والتوضيح مع ذلك يمكن للقياس السيئ أن يزيف التقدم بسهولة إذا كانت بياناتك الوصفية ضعيفة فقد يكتفي الوكيل بتلخيص الفشل بشكل أسرع بدلا من منعه فعليا إذا ظل العمل المعاد خارج لوحة البيانات فسيبدو عائد الاستثمار أنظف بكثير مما هو عليه في الواقع إذا تسرب الوقت المسترد إلى أنشطة منخفضة القيمة فسيبالغ القادة في تقدير المكاسب يجب أن تظل الحالة المالية مبنية على أدلة طوية مثل الحوادث التي تم منعها وتقليل التدخلات اليدوية عليك قياس الوقت الذي عاد فعليا إلى العمل المفيد بمجرد قياس ذلك بشكل صحيح تتوقف وظيفة الدعم عن كونها نفقات عامة يجب تقليصها تبدأ في الظهور كقدرة تشغيلية تستعيدها الشركة أخيرا ماذا يفعل هذا بفريق الدعم فكر فيما يفعله هذا حقا للفريق على أرض الواقع لأن هذا التحول لا يتعلق بتقليص عدد الموظفين بل بتغيير ما يفعله أفرادك فعليا في يومهم في الإعداد القديم تستهلك معظم قدرة الدعم لديك في إعادة تعيين كلمات المرور وتوجيه التذاكر وحلقة التوضيح التي لا تنتهي لديك أشخاص يطاردون التحديثات وينقلون البيانات بين أنظمة لم تصمم أبدا للتحدث مع بعضها البعض لا شيء من ذلك العمل يجعل البيئة أكثر استقرارا إنه فقط يمنع طفح قائمة الانتظار عندما يتولى الوكلاء هذا العمل الروتيني المتوقع يرتق الجهد البشري أخيرا إلى مستوى أعلى يبدأ مهندس الدعم في قضاء وقتهم في تحديد شكل الحالة السليمة وضبط المنطق وراء الموافقات إنهم يركزون على تحسين مصادر المعرفة واختبار سلوك السياسات والتأكد من بقاء الوكيل ضمن الحدود التي ودعت له هذه وظيفة مختلفة تماما عن التحديق في سطور الموضوع طوال اليوم ومحاولة تخمين ما يريده المستخدم حقا هذا هو بالضبط المكان الذي تتعثر فيه معظم عمليات النشر تحاول المؤسسات الحفاظ على عملياتها القديمة المعطلة وتكتفي بإضافة وكيل ذكي فوقها متوقعة النتائج أفضل لكن العملية تظل تفاعلية وعمليات التسليم لا تزال فوضوية والمعرفة الأساسية لا تزال ضعيفة يصبح الوكيل مجرد طبقة طلاء أخرى على جدار متداع قد يجيب على سؤال بشكل أسرع لكنه لا يستطيع إصلاح نموذج دعم بني أساسا على التأخير الطريقة الأفضل هي إعادة تصميم العمل أولا عليك أن تقرر أي المهام تظل بشرية لأنها تتطلب حكما أو تواصلا حساسا

ببساطة إلى أشخاص يصممون الضوابط ويتعاملون مع الاستثناءات هذا يعني أن الطريقة التي ندرب بها الناس يجب أن تتغير أيضا تحتاج الفرق إلى تعلم كيفية الإشراف على نظام بدلا من مجرد تنفيذ مهمة يدوية يحتبنا إلى فهم منطق التراجع ومراجعة التدقيق وكيفية اختبار الوكيل قبل تشغيله يجب أن يكونوا قادرين أيضا على اكتشاف فشل النموذج لأن سير العمل السيء المؤتمد يظل سير عمل سيئا إنه فقط يفسد الأمور بسرعة أكبر إذا كنت توظف لهذا المستقبل فمن المحتمل أنك لا تحتاج إلى موظف عام آخر لفرز التذاكر أنت بحاجة إلى شخص يمكنه تنسيق التدفقات عبر حزمة مايكروسوفت 365 وتحديد الضوابط التي تبقي الوكلاء تحت سيطرة أنت تريد أشخاص يمكنهم تحسين البيئة بحيث ينخفض طلب الدعم فعليا بدلا من تراكمه إذن كيف تبدأ هذا فعليا دون أن يتحول إلى مشروع تحول ضخم يستغرق سنوات أفضل خطوة هي اختيار تدفق واحد يسبب احتكاكا مستمرا داخل بيئة مايكروسوفت 365 الخاصة بك غالبا ما يكون إصلاح الوصول مرشحا رائعا ولكن يمكنك أيضا النظر في دعم الاجتماعات أو تسليمات امتثال الأجهزة لا يهم أينا منها تختار طالما أن النمط يتكرر كثيرا وتعرف بالضبط كيف يجب أن تبدو النتيجة الناجحة بمجرد تحديد الهدف يجب عليك تحديد الأساسيات بانضباط حقيقي يجب أن تعرف كيف تبدو الحالة السليمة وما هي الأحداث المحددة التي تخبرك أن الأمور تحيد عن مسارها حدد الإجراءات الآمنة للأتمتة وأين بالضبط يجب أن يبدأ التصعيد البشري قبل إطلاق أي شيء تأكد من وضع خط أساس لأعداد التذاكر والتدخلات اليدوية ومدة انتظار المستخدمين حاليا للحصول على حل يجب عليك أيضا وضع حوكمتك موضع التنفيذ منذ اليوم الأول أمنح الوكيل هوية محددة وعين له مالكنا بشريا وحدد قواعد موافقة واضحة يجب تسجيل كل إجراء يتخذه الوكيل يجب أن يكون لديك أيضا خطة لإيقاف الوكيل أو إعادة تعيينه حتى لا يتحول إلى أتمتة مهجورة عندما تبدأ تلك العملية الأولى في العمل يبدأ نموذج التشغيل بالكامل في التحول يتوقف الدعم عن التصرف كمكتب استقبال يكتفي برد الفعل تجاه المشكلات بدلا من ذلك يبدأ في العمل كمحرك موثوقية مدمج مباشرة في النظام يتحول الدعم من رد فعل مرئي إلى وقاية مضمنة لم تكن التذكرة هي الخدمة أبدا بل كانت دليلا على أن الخدمة وصلت متأخرة جدا اختر مسار دعم وحدا هذا الربع وأعد تصميمه ليكون استباقيا بدلا من أن يكون استجابيا إذا أردت المزيد حول M365 كوبايلوت وأشر والأمانة ونماذج تشغيل الذكاء الاصطناعي اشترك في M365 FM وترك تقييما تواصل معي ميركو بيتر على لينكتن لاقتراح الموضوع التالي الذي تود مني شرحه