> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # فريق الدعم الفني: المستويات والأدوار وكيف يعمل - URL: https://arabroot.io/articles/فريق-الدعم-الفني-المستويات-والادوار/ - Published: 2026-10-13T10:45:00.000Z - Updated: 2026-10-13T21:21:14.000Z - Description: كيف تنظم فريق الدعم الفني بمستوياته وأدواره ومناوبته، وكم موظفاً تحتاج فعلاً لترد على المكالمات في وقتها. - Author: فريق عرب رووت - Tags: الأدلة التقنية, الاستضافة الذاتية والتطبيقات, الاستضافة الذاتية في مقال [إدارة خدمات تقنية المعلومات ITSM](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%AE%D8%AF%D9%85%D8%A7%D8%AA-%D8%AA%D9%82%D9%86%D9%8A%D8%A9-%D8%A7%D9%84%D9%85%D8%B9%D9%84%D9%88%D9%85%D8%A7%D8%AA-itsm/) نظمنا الطلبات نفسها، أي التذاكر والمؤقتات والتصعيد، ثم اخترنا النظام في [مقارنة أنظمة التذاكر](https://arabroot.io/articles/%D9%85%D9%82%D8%A7%D8%B1%D9%86%D8%A9-%D8%A7%D9%86%D8%B8%D9%85%D8%A9-%D8%A7%D9%84%D8%AA%D8%B0%D8%A7%D9%83%D8%B1-helpdesk-%D9%88-itsm/)، ولكن السؤال الذي يصل بعد ذلك إلى كل مدير تقنية معلومات هو سؤال عن الناس وليس عن الأداة: من يرد على الهاتف في الثامنة صباحاً؟ ومن يذهب إلى مكتب الموظف ليستبدل الشاشة؟ ومتى تنتقل التذكرة من الفني إلى مهندس الشبكات؟ ومن يرد إذا تعطل البريد في الحادية عشرة ليلاً؟ وكم شخصاً نحتاج أصلاً حتى لا ينتظر الموظف عشر دقائق على الخط؟ وهذه الأسئلة لا يجيب عنها نظام التذاكر، وإنما يجيب عنها شكل الفريق. وسوف نناقش في هذا المقال ما يلي: - ماذا يفعل الدعم الفني، والفرق بين مكتب الخدمة Service Desk والدعم الميداني والمتخصصين. - مستويات الدعم من L0 إلى L4، ونموذج Intelligent Swarming الذي يلغي المستويات. - الأدوار في الفريق، وما يقاس به كل دور، والمهارات والشهادات. - نماذج التغطية خارج الدوام، والفرق بين مناوبة الدعم ومناوبة المهندسين. - مصفوفة التصعيد، والعقد بين الدعم وفريق التطوير. - الفريق الداخلي والدعم الخارجي، وشكل الفريق في شركة صغيرة وفي جامعة. - تجربة عملية: حساب عدد الموظفين بمعادلة Erlang C في Container، مع جدول حساسية وجدول مناوبة. [![](https://arabroot.io/content/images/2026/10/itsm-intro-cover-cover.webp)دليلإدارة خدمات تقنية المعلومات ITSM: ما الذي تحتاجه فعلاً؟كيف تنظم عمل الدعم الفني بالتذاكر والمؤقتات والتصعيد، وما الذي تأخذه من ITIL دون بيروقراطية.](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%AE%D8%AF%D9%85%D8%A7%D8%AA-%D8%AA%D9%82%D9%86%D9%8A%D8%A9-%D8%A7%D9%84%D9%85%D8%B9%D9%84%D9%88%D9%85%D8%A7%D8%AA-itsm/)[![](https://arabroot.io/content/images/2026/10/itsm-tools-cover-cover.webp)دليلأي نظام تذاكر Helpdesk يناسب قسم تقنية المعلومات؟مقارنة أنظمة التذاكر المفتوحة بتراخيصها وأجزائها المدفوعة ودعمها للعربية، مع تجربة البريد وال SLA على ثلاثة منها.](https://arabroot.io/articles/%D9%85%D9%82%D8%A7%D8%B1%D9%86%D8%A9-%D8%A7%D9%86%D8%B8%D9%85%D8%A9-%D8%A7%D9%84%D8%AA%D8%B0%D8%A7%D9%83%D8%B1-helpdesk-%D9%88-itsm/)[![](https://arabroot.io/content/images/2026/10/production-accountability-cover-cover-1.webp)دليلمن يتحمل المسؤولية Accountability عندما يتعطل الإنتاج؟كيف تحدد ملكية الخدمات وتدير الحادثة بأدوار واضحة، ثم تكتب تقرير ما بعد الحادثة دون لوم وبإجراءات تغلق فعلاً.](https://arabroot.io/articles/%D9%85%D9%86-%D9%8A%D8%AA%D8%AD%D9%85%D9%84-%D8%A7%D9%84%D9%85%D8%B3%D8%A4%D9%88%D9%84%D9%8A%D8%A9-%D8%B9%D9%86%D8%AF%D9%85%D8%A7-%D9%8A%D8%AA%D8%B9%D8%B7%D9%84-%D8%A7%D9%84%D8%A7%D9%86%D8%AA%D8%A7%D8%AC/) ## ماذا يفعل الدعم الفني؟ كلمة «الدعم الفني» تجمع في أغلب الشركات ثلاث وظائف مختلفة، ولكل واحدة منها طريقة عمل وطريقة قياس، وخلطها هو السبب في أن الفني نفسه يرد على الهاتف ويركب الطابعات ويحاول إصلاح قاعدة البيانات في اليوم نفسه، فلا يتقن أياً منها. والوظائف الثلاث هي: - **مكتب الخدمة Service Desk:** المدخل الواحد لكل الطلبات، بالهاتف والبريد والبوابة، وعمله أن يستقبل الطلب ويسجله ويصنفه ويحل المعروف منه فوراً، ويوجه الباقي إلى من يحله ويتابعه حتى يغلق. ويقاس بالوقت حتى أول رد وبنسبة ما يحله من أول تواصل. - **الدعم الميداني Desktop Support:** العمل على الجهاز نفسه أو في مكان الموظف، مثل تجهيز حاسوب جديد واستبدال قطعة وتوصيل شاشة في قاعة اجتماعات، وتسجيل الأجهزة في نظام الإدارة كما في [إدارة أجهزة الموظفين MDM](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D8%AC%D9%87%D8%B2%D8%A9-%D8%A7%D9%84%D9%85%D9%88%D8%B8%D9%81%D9%8A%D9%86-%D9%88%D8%AA%D8%A3%D9%85%D9%8A%D9%86%D9%87%D8%A7-mdm/)، وكثير منه اليوم يتم عن بعد بأدوات قارناها في [أدوات الدعم الفني عن بعد](https://arabroot.io/articles/%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D8%A7%D9%84%D9%88%D8%B5%D9%88%D9%84-%D8%A7%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D9%89-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA/#remote-support). - **المتخصصون Specialists:** فرق الشبكات والسيرفرات وقواعد البيانات والهوية وفريق التطوير، وهؤلاء لا يستقبلون الطلبات من الموظفين مباشرة، وإنما تصلهم من مكتب الخدمة Service Desk بعد أن تتضح المشكلة. ## المستويات من L0 إلى L4 أشهر طريقة لتنظيم الفريق هي المستويات Tiers، أي أن تبدأ التذكرة عند أقرب مستوى إلى المستخدم وأقلها تكلفة، ثم تصعد إلى مستوى أعلى خبرة إذا لم يستطع حلها، والصورة التالية تبين المستويات الخمسة: ![خمسة أعمدة متدرجة الارتفاع من اليمين إلى اليسار: L0 الخدمة الذاتية Self-Service ببوابة وقاعدة معرفة وإعادة تعيين كلمة المرور دون فني، ثم L1 مكتب الخدمة Service Desk يستقبل ويسجل ويصنف ويحل المعروف ويملك التذكرة حتى تغلق، ثم L2 الدعم الميداني والتطبيقات، ثم L3 المهندسون والمتخصصون للشبكات والسيرفرات وقواعد البيانات وفريق التطوير، ثم L4 المورد أو الشركة المصنعة بعقد دعم أو ضمان، وسهم أحمر في الأسفل للتصعيد الوظيفي من اليمين إلى اليسار، وسهم أخضر متقطع في الأعلى يعيد الحل إلى قاعدة المعرفة باتجاه L0](https://arabroot.io/content/images/2026/10/it-support-team-01-tiers.webp) كل مستوى أعلى أغلى وأبطأ، ولذلك يعود الحل مكتوباً إلى مستوى أقرب للمستخدم - **L0 الخدمة الذاتية Self-Service:** ما يحله الموظف بنفسه دون فني، مثل إعادة تعيين كلمة المرور من صفحة مزود الهوية، ومقال في قاعدة المعرفة يشرح ربط الطابعة، ونموذج في الكتالوج يطلب برنامجاً معتمداً. - **L1 مكتب الخدمة Service Desk:** أول إنسان يرى الطلب، ويحل ما له حل معروف وموثق، مثل حساب مقفل أو مشكلة في إعداد البريد على الهاتف، ويجمع المعلومات الكاملة قبل أن يحول الباقي. - **L2 الدعم الميداني والتطبيقات:** فنيون أعمق في الأجهزة والأنظمة الداخلية، مثل نظام الموارد البشرية أو نظام إدارة التعلم في الجامعة، ويحتاجون صلاحيات أكثر ووقتاً أطول للتذكرة الواحدة. - **L3 المهندسون والمتخصصون:** من يستطيع تغيير النظام نفسه، أي مهندس الشبكات الذي يعدل قاعدة الجدار الناري Firewall، ومدير قاعدة البيانات، والمطور الذي يصلح الخطأ في الكود. - **L4 المورد Vendor:** الشركة المصنعة أو مزود الخدمة بعقد دعم، مثل مورد نظام الرواتب أو الشركة المصنعة للسيرفر في مطالبة ضمان، وتبقى تذكرتك مفتوحة وفيها رقم تذكرة المورد. وقد يتساءل البعض: إذا انتقلت التذكرة إلى L3 فهل تصبح ملكاً له؟ والإجابة في أغلب الفرق لا، والسبب أن الموظف لا يعرف L3 ولا يجب أن يلاحقه، فيبقى مكتب الخدمة Service Desk صاحب التذكرة أمام المستخدم، يتابعها ويرد عليه، بينما يعمل L3 على الإصلاح. أما نوعا التصعيد، الوظيفي إلى خبرة أعلى والإداري إلى المدير، وربطهما بمؤقت ال SLA فقد شرحناهما في [اتفاقيات SLA وOLA والتصعيد](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%AE%D8%AF%D9%85%D8%A7%D8%AA-%D8%AA%D9%82%D9%86%D9%8A%D8%A9-%D8%A7%D9%84%D9%85%D8%B9%D9%84%D9%88%D9%85%D8%A7%D8%AA-itsm/#sla). والفكرة الأهم في هذا النموذج هي السهم الأخضر في الصورة، أي ال Shift-Left، ومعناها أن كل حل يصل إليه مستوى أعلى يكتب في قاعدة المعرفة بحيث يستطيع مستوى أقرب إلى المستخدم أن ينفذه في المرة القادمة. وبدون ذلك يصبح L3 هو الذي يحل نفس المشكلة كل أسبوع، وهذا أغلى استخدام ممكن لوقت المهندسين. ## نموذج Intelligent Swarming بدل المستويات النموذج المتدرج له مشكلة معروفة، وهي أن كل تحويل يضيف قائمة انتظار جديدة، وأن الموظف يشرح مشكلته مرة لكل مستوى، وأن L1 لا يتعلم لأن الحل يحدث بعيداً عنه. ولهذا طور اتحاد Consortium for Service Innovation، وهو تحالف غير ربحي من شركات الدعم والخدمات وهو نفسه صاحب منهجية KCS لإدارة المعرفة، نموذجاً سماه [Intelligent Swarming](https://library.serviceinnovation.org/Intelligent%5FSwarming?ref=arabroot.io)، ويصفه بأنه يقوم على إزالة مستويات الدعم، وعلى أن يستدعى عند الحاجة خبرة مجموعة من الفنيين حول المشكلة. والصورة التالية تبين الفرق: ![مقارنة من جزأين: في جهة Tiered Support تمر التذكرة من L1 إلى L2 إلى L3 ثم بسهم متقطع إلى L4 وفوق كل تحويل ساعة انتظار، مع ثلاث ملاحظات بأنه يناسب الطلبات الكثيرة المعروفة، ويتعلم فيه الدعم الأول ببطء، ويشرح فيه المستخدم مشكلته أكثر من مرة، وفي جهة Intelligent Swarming تصل التذكرة إلى فني واحد هو المالك owner في وسط دائرة ومن حوله أربعة زملاء متصلون به، مع ملاحظات بأنه يناسب المشكلات الجديدة والمعقدة، ويحتاج ثقة عالية ونظاماً يبين من يعرف ماذا، وقد يبقى فيه فرز أول Triage في المنظمات الكبيرة](https://arabroot.io/content/images/2026/10/it-support-team-02-swarming.webp) في النموذج المتدرج تنتقل التذكرة إلى الخبرة، وفي ال Swarming تنتقل الخبرة إلى التذكرة ويقوم النموذج على أربعة مبادئ كما وردت في [صفحة المبادئ والمفاهيم الأساسية](https://library.serviceinnovation.org/Intelligent%5FSwarming/Practices%5FGuide/40%5FPrinciples%5FCore%5FConcepts?ref=arabroot.io) من دليل الممارسات: - الوفرة Abundance: كلما شاركنا أكثر تعلمنا أكثر. - صناعة القيمة Create Value: نعمل على المهام ونرى الصورة الكاملة. - العمل حسب الطلب Demand Driven: في وقت الحاجة، وليس تحسباً لما قد يحدث. - الثقة Trust: إشراك الناس وتمكينهم وتحفيزهم. والمفاهيم التي تغير شكل الفريق فعلاً من الصفحة نفسها ثلاثة: - فريق واحد بمهارات مختلفة، ولا توجد مستويات منفصلة للدعم. - يصل العمل من أول لمسة إلى الشخص الأقدر على حله. - من يأخذ الطلب يملكه حتى يحل، والاستثناءات تعامل كاستثناءات وليست القاعدة. وهل يناسب كل فريق؟ لا، والدليل نفسه صريح في ذلك، فهو يقول في [صفحة هل يناسبك](https://library.serviceinnovation.org/Intelligent%5FSwarming/Practices%5FGuide/35%5FIs%5FIt%5FRight%5Ffor%5FYou?ref=arabroot.io) إن النموذج يصنع أكبر قيمة عندما يكون تعقيد العمل أو خطورته متوسطاً إلى عال، ويذكر علامات منها: - متوسط وقت حل العمل الجديد أكثر من 15 دقيقة. - نسبة المشكلات الجديدة من الوارد أكثر من 30%. - نسبة التذاكر التي تحتاج تصعيداً إلى مستوى أعلى في ازدياد. - الثقة داخل الفريق عالية والتعاون فيه طبيعي. أما إذا كانت أغلب الطلبات معروفة وقليلة التعقيد، مثل كلمات المرور والحسابات المقفلة، فالدليل يرى أن مكانها الخدمة الذاتية وقاعدة المعرفة، ويذكر أن الإبقاء على فرز أول Triage في نموذج مختلط قد يكون منطقياً لبعض المنظمات، وأن القرار يحتاج تقديراً. والخلاصة العملية لقسم تقنية معلومات داخلي أن أغلب طلباته من النوع المعروف، فالنموذج المتدرج مع Shift-Left جيد يناسبه، ولكن يمكنك أن تأخذ من ال Swarming فكرتين دون أن تغير الهيكل: أن يبقى صاحب التذكرة معها ويطلب المساعدة في قناة مشتركة بدل أن يحولها ويتركها، وأن يجتمع المختصون حول الحادثة الكبيرة بدل أن تمر بينهم بالتسلسل. ## الأدوار في الفريق وكيف يقاس كل دور الدور غير الوظيفة، ففي فريق من ثلاثة أشخاص قد يحمل الشخص الواحد أربعة أدوار، ولكن من المفيد أن يعرف أي دور يحمل الآن، والسبب أن كل دور يسأل سؤالاً مختلفاً ويقاس بمقياس مختلف. والجدول التالي يجمع الأدوار المعتادة، والمقاييس فيه شرحنا معانيها وكيف يخدع كل منها في [مقاييس الدعم الفني](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%AE%D8%AF%D9%85%D8%A7%D8%AA-%D8%AA%D9%82%D9%86%D9%8A%D8%A9-%D8%A7%D9%84%D9%85%D8%B9%D9%84%D9%88%D9%85%D8%A7%D8%AA-itsm/#metrics): | الدور | مسؤوليته | ما يقاس به | | --------------------------------------------- | ------------------------------------------------------------------------------- | ---------------------------------------------------------- | | موظف مكتب الخدمة Service Desk Agent | استقبال الطلب وتسجيله وتصنيفه وحل المعروف منه ومتابعة الباقي | وقت أول رد، والحل من أول تواصل FCR، ونسبة إعادة الفتح | | فني الدعم الميداني Desktop Support Technician | تجهيز الأجهزة وإصلاحها في المكان أو عن بعد، والطلبات التي تحتاج يداً على الجهاز | وقت الحل للحوادث، والوقت حتى تسليم الجهاز للموظف الجديد | | قائد الفريق Team Lead | توزيع العمل يومياً، ومراجعة التذاكر المتأخرة، والتصعيد الإداري، وتدريب الفريق | الالتزام بال SLA، وعمر أقدم التذاكر في المتراكم Backlog | | مدير تقديم الخدمة Service Delivery Manager | العلاقة مع الأقسام، وال SLA وال OLA، والتقارير الشهرية، وعقود الموردين | رضا المستخدمين CSAT مع عدد المجيبين، والالتزام بالاتفاقيات | | مدير الحوادث Incident Manager | قيادة الحادثة الكبيرة والتواصل فيها، وغالباً يكون دوراً يحمله قائد الفريق | وقت إعادة الخدمة في الحوادث الكبيرة | | مدير المشكلات Problem Manager | البحث في سبب الحوادث المتكررة ومتابعة إصلاحه | عدد الحوادث المتكررة، والمشكلات المفتوحة وعمرها | | مدير التغيير Change Manager | مراجعة التغييرات العادية والطارئة وجدولتها | نسبة التغييرات التي سببت حوادث | | مدير المعرفة Knowledge Manager | جودة قاعدة المعرفة ومراجعة المقالات وأصحابها | التذاكر التي حلت بمقال، والمقالات التي فات موعد مراجعتها | | مدير الأصول Asset Manager | سجل الأجهزة والتراخيص ودورة حياتها من الشراء إلى الإتلاف | دقة السجل في الجرد، والأجهزة التي بلا صاحب | ولاحظ أن أدوار الحادثة الكبيرة نفسها، أي قائد الحادثة والموثق ومسؤول التواصل، شرحناها في [أدوار الحادثة Incident Roles](https://arabroot.io/articles/%D9%85%D9%86-%D9%8A%D8%AA%D8%AD%D9%85%D9%84-%D8%A7%D9%84%D9%85%D8%B3%D8%A4%D9%88%D9%84%D9%8A%D8%A9-%D8%B9%D9%86%D8%AF%D9%85%D8%A7-%D9%8A%D8%AA%D8%B9%D8%B7%D9%84-%D8%A7%D9%84%D8%A7%D9%86%D8%AA%D8%A7%D8%AC/#incident-roles)، ومكان مكتب الخدمة Service Desk فيها غالباً هو التواصل مع المستخدمين. أما دور مدير الأصول فهو موضوع مقالنا التالي عن دورة حياة الأجهزة. وقد يتساءل البعض: لماذا لا يوجد في المقال رقم مثل «المتوسط في الصناعة لوقت الرد هو كذا»؟ والإجابة أن أغلب هذه الأرقام المنتشرة مصدرها استبيانات تجارية لا تنشر طريقتها ولا عينتها، وتخلط شركات بأحجام وقنوات مختلفة، فلا تصلح للمقارنة، والمفيد هو اتجاه أرقامك أنت شهراً بعد شهر بعد أن تثبت تعريفاتها. ## المهارات والمسار المهني أكثر ما يحتاجه موظف مكتب الخدمة Service Desk ليس المعرفة التقنية العميقة، وإنما مجموعة مهارات تجعل الطلب يصل كاملاً ويحل بسرعة، وهي: - طرح الأسئلة الصحيحة: متى بدأ العطل؟ هل يحدث لزميلك؟ ماذا تغير؟ وكتابة الإجابات في التذكرة بحيث لا يسأل L2 السؤال نفسه مرة أخرى. - الكتابة الواضحة: تحديث التذكرة، ورد للمستخدم بلغة يفهمها، ومقال قاعدة معرفة يستطيع زميله تنفيذه. - أساسيات التقنية: الشبكة والبريد والهوية وأنظمة التشغيل، بما يكفي ليعرف أين يبحث. - الهدوء مع المستخدم الغاضب، والسبب أن أغلب المكالمات تصل بعد أن تعطل عمل صاحبها. والمسار المعتاد يبدأ من مكتب الخدمة Service Desk، ثم يتفرع إما إلى العمق التقني، أي L2 ثم الشبكات أو السيرفرات أو الأمن أو مهندس المنصات، وإما إلى الإدارة، أي قائد الفريق ثم مدير تقديم الخدمة. أما الشهادات فهي مفيدة في البداية لأنها تعطي إطاراً مرتباً، وأشهرها ثلاث جهات: - **شهادة CompTIA A+:** تقول CompTIA في [صفحة الشهادة](https://www.comptia.org/en-us/certifications/a/?ref=arabroot.io) إنها تتطلب اختبارين، Core 1 للعتاد والشبكات وCore 2 لأنظمة التشغيل والأمن، والوظيفة التي تذكرها لها هي أخصائي دعم الهلب ديسك Help Desk Support Specialist. - **شهادات HDI:** وتذكر HDI في [صفحة الشهادات](https://www.thinkhdi.com/certification?ref=arabroot.io) أن شهاداتها المرتبطة بالأدوار تمتد من ممثل خدمة العملاء Customer Service Representative إلى مدير مركز الدعم Support Center Director، وأنها تقدم إلى جانبها شهادات في مبادئ KCS وفي ITIL 4 Foundation. - **شهادات ITIL:** وتصدرها PeopleCert، وقد ذكرنا تغيير ملكيتها وصدور ITIL (Version 5) في 2026 في [فقرة ITIL](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%AE%D8%AF%D9%85%D8%A7%D8%AA-%D8%AA%D9%82%D9%86%D9%8A%D8%A9-%D8%A7%D9%84%D9%85%D8%B9%D9%84%D9%88%D9%85%D8%A7%D8%AA-itsm/#itil)، وهي مفيدة لمن يتجه إلى الإدارة أو يعمل في شركات تشترطها. ## نماذج التغطية خارج الدوام أول قرار في التغطية هو ساعاتها، والسبب أن الأسبوع 168 ساعة والموظف يعمل حوالي 40 منها، فتغطية مقعد واحد طوال الأسبوع تحتاج أكثر من أربعة موظفين قبل حساب الإجازات، فلا تعد بها قبل أن تعرف ما الذي يحتاجه المستخدمون فعلاً بعد الدوام. وأشهر النماذج كما في الجدول التالي: | النموذج | كيف يعمل | متى يناسب | نقطة الضعف | | -------------------------- | ---------------------------------------------------------------------------------------------- | ----------------------------------------------- | --------------------------------------------------------- | | ساعات الدوام فقط | مكتب الخدمة Service Desk يعمل في الدوام، والبريد والبوابة يستقبلان الطلبات ليلاً لتعالج صباحاً | شركة تعمل في الدوام فقط وأنظمتها غير حرجة ليلاً | عطل الساعة العاشرة ليلاً ينتظر حتى الصباح | | الدوام ومناوبة بعده | فريق كامل في الدوام، ثم هاتف واحد يحول إلى المناوب من الفريق بجدول أسبوعي | أغلب الشركات المتوسطة والجامعات | يحتاج تعويضاً واضحاً وتعريفاً دقيقاً لما يعتبر عاجلاً | | اتباع الشمس Follow-the-Sun | فرق في مناطق زمنية مختلفة تسلم الطابور لبعضها في نهاية كل يوم | شركات لها مكاتب في قارات مختلفة | التسليم بين الفرق، ولغة المستخدم، وتوحيد الأدوات والمعرفة | | مزود خارجي MSP | شركة خدمات مدارة Managed Service Provider ترد بعد الدوام أو طوال الوقت حسب العقد | فريق داخلي صغير لا يستطيع مناوبة عادلة | لا يعرف أنظمتك الداخلية، ويحتاج صلاحيات على بيئتك | ## مناوبة الدعم ومناوبة المهندسين هذا أكثر موضع يحدث فيه الخلط، فالكثير من الفرق تجعل شخصاً واحداً «مناوباً» يستقبل اتصالات الموظفين وتنبيهات المراقبة في الوقت نفسه، ثم يتساءل الجميع لماذا يترك الناس المناوبة. والحقيقة أن هناك مناوبتين مختلفتين في المصدر والعمل والمقياس، والصورة التالية تبين الفرق ونقطة التسليم بينهما: ![في الأعلى شريط ليوم عمل بتوقيت الرياض: من 08:00 إلى 16:00 مكتب الخدمة بكامل فريقه، وقبله وبعده دعم ما بعد الدوام بالهاتف، وتحته شريط مناوبة الهندسة على مدار الساعة للخدمات الحرجة فقط، وفي الأسفل جزءان: After-hours Support مصدره إنسان يتصل مثل لا أستطيع الدخول أو الطابعة متوقفة، يحل ما يستطيع ويؤجل غير العاجل ويقاس بال SLA ودليله قاعدة المعرفة ومصفوفة التصعيد، وEngineering On-call مصدره تنبيه من المراقبة مثل نسبة الأخطاء في بوابة الطلاب 30% أو قاعدة البيانات لا ترد، يصلح الخدمة أو يتراجع ويقاس بوقت التعافي ودليله ال Runbook، وبينهما سهم أحمر رقم 1 من الدعم إلى المناوب وسهم أخضر رقم 2 من المناوب إلى الدعم](https://arabroot.io/content/images/2026/10/it-support-team-03-after-hours.webp) الدعم يستقبل الناس، والمناوب يستقبل التنبيهات، والتسليم بينهما مكتوب مسبقاً والجدول التالي مثال لمن يستدعى في كل حالة، والقيم فيه مثال لجامعة متوسطة الحجم وليست معياراً: | الحدث بعد الدوام | من يستلمه أولاً | من يستدعى بعده | | --------------------------------------------- | -------------------- | ----------------------------------------------------- | | موظف واحد لا يستطيع الدخول إلى حسابه | مناوب الدعم | لا أحد، فإذا لم يحل ينتظر الصباح ما لم يكن عمله حرجاً | | عشرة اتصالات خلال ربع ساعة بأن البريد لا يعمل | مناوب الدعم | مناوب الفريق المالك لخدمة البريد، بإعلان حادثة | | تنبيه من المراقبة بأن بوابة الطلاب ترد بأخطاء | مناوب الهندسة مباشرة | مناوب الدعم ليعرف ماذا يقول لمن يتصل | | تنبيه بأن قرص النسخ الاحتياطي امتلأ بنسبة 85% | لا أحد ليلاً | تذكرة في طابور الفريق المالك صباحاً | وفي الإعداد أعلاه لاحظ التالي: - مناوب الدعم لا يصلح خدمة متوقفة، وإنما يتأكد أن العطل في الخدمة وليس عند المستخدم، ثم يستدعي المناوب المالك ويسجل الحادثة. - تنبيهات المراقبة لا تمر على الدعم أولاً، والسبب أن كل تحويل إضافي في الليل يضيف دقائق لا فائدة منها. - بعد الاستدعاء يبقى مكتب الخدمة Service Desk مسؤولاً عن الرد على المستخدمين، ويأخذ التحديثات من المناوب أو من صفحة الحالة، حتى لا ينشغل المهندس بالرد على الهاتف. أما قواعد مناوبة المهندسين نفسها، أي عدد المناوبين وال Runbook وتسليم النوبة والتعويض، فقد شرحناها في [المناوبة On-call دون أن تحرق الفريق](https://arabroot.io/articles/%D9%85%D9%86-%D9%8A%D8%AA%D8%AD%D9%85%D9%84-%D8%A7%D9%84%D9%85%D8%B3%D8%A4%D9%88%D9%84%D9%8A%D8%A9-%D8%B9%D9%86%D8%AF%D9%85%D8%A7-%D9%8A%D8%AA%D8%B9%D8%B7%D9%84-%D8%A7%D9%84%D8%A7%D9%86%D8%AA%D8%A7%D8%AC/#on-call)، وكلها تصلح لمناوبة الدعم أيضاً مع فرق واحد: مصدر الطلب في مناوبة الدعم إنسان، ولذلك يحتاج مناوب الدعم مقالات قاعدة معرفة قصيرة لما يحدث بعد الدوام، مثل حساب مقفل وحاسوب لا يقلع قبل محاضرة، ويحتاج صلاحية محددة لإعادة تعيين كلمة المرور وفك القفل دون صلاحيات المدير الكاملة، كما في [إدارة الأدوار عبر تطبيقاتك من authentik](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D8%A7%D8%AF%D9%88%D8%A7%D8%B1-%D8%B9%D8%A8%D8%B1-%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA%D9%83-%D9%85%D9%86-authentik/). ## مصفوفة التصعيد مصفوفة التصعيد Escalation Matrix جدول مكتوب يقول لكل أولوية: من يستلم، وإلى من تصعد، ومتى، ومن يبلغ. وقيمتها أنها تمنع النقاش في وقت الأزمة، فلا يحتاج الفني في الحادية عشرة ليلاً أن يقرر هل يتصل بمدير الشبكات أم لا. والجدول التالي مثال يمكنك أن تبدأ منه، والمدد فيه أمثلة نختارها نحن وليست معياراً: | الأولوية | مثال | التصعيد الوظيفي | التصعيد الإداري | | --------- | ---------------------------------------------- | -------------------------------------------------- | ------------------------------------------------------------------------ | | P1 حرجة | البريد أو بوابة الطلاب متوقفة لأغلب المستخدمين | استدعاء مناوب الفريق المالك فور التأكد، دون انتظار | قائد الفريق فوراً، ومدير تقنية المعلومات إذا لم تعد الخدمة خلال 30 دقيقة | | P2 عالية | نظام مهم معطل لقسم كامل | إلى L2 أو الفريق المالك إذا لم يحل خلال 30 دقيقة | قائد الفريق عند مرور نصف وقت الحل | | P3 متوسطة | موظف واحد لا يستطيع العمل | إلى L2 إذا لم يحل خلال 4 ساعات عمل | قائد الفريق عند كسر ال SLA | | P4 منخفضة | طلب خدمة أو عطل له حل مؤقت | حسب مسار الطلب في الكتالوج | في التقرير الأسبوعي فقط | وضع في المصفوفة أسماء الأدوار وليس أسماء الأشخاص، واربط كل دور بجدول المناوبة، والسبب أن الأسماء تتغير مع الإجازات والاستقالات، والمصفوفة التي فيها اسم موظف غادر قبل ستة أشهر أسوأ من عدم وجودها. واجعل التصعيد آلياً في نظام التذاكر كما فعلنا في [تجربة Zammad](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%AE%D8%AF%D9%85%D8%A7%D8%AA-%D8%AA%D9%82%D9%86%D9%8A%D8%A9-%D8%A7%D9%84%D9%85%D8%B9%D9%84%D9%88%D9%85%D8%A7%D8%AA-itsm/#lab). ## العمل مع فريق التطوير أكثر علاقة تتعب الدعم الفني هي العلاقة مع فريق التطوير، فالدعم يرى أن التذكرة ضاعت عند المطورين، والمطورون يرون أن ما يصلهم «لا يعمل» دون أي تفاصيل. والحل أن يكون بينهما عقد مكتوب، وهو في الحقيقة اتفاقية مستوى تشغيلي OLA يتفق عليها الطرفان، وفيها ثلاثة أجزاء: - **ما يجب أن يصل في كل تذكرة:** خطوات إعادة إنتاج الخطأ، والمستخدمون المتأثرون وعددهم، ووقت البداية، ورسالة الخطأ أو لقطة الشاشة، والمتصفح أو إصدار التطبيق، والحل المؤقت إن وجد، وأرقام التذاكر المشابهة. - **ما يلتزم به فريق التطوير:** وقت للرد الأول على الخطأ حسب خطورته، ورابط ثابت بين تذكرة الدعم وبطاقة الخطأ في نظام التطوير، وإبلاغ الدعم عند الإصلاح أو عند تأجيله. - **ما يحدث بعد الإصلاح:** يحدث الدعم قاعدة المعرفة، ويغلق التذاكر المرتبطة كلها، ويبلغ المستخدمين، وإذا تكررت الحوادث تفتح مشكلة Problem كما شرحنا في [الحادثة والمشكلة والتغيير](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%AE%D8%AF%D9%85%D8%A7%D8%AA-%D8%AA%D9%82%D9%86%D9%8A%D8%A9-%D8%A7%D9%84%D9%85%D8%B9%D9%84%D9%88%D9%85%D8%A7%D8%AA-itsm/#records). ولا تقم بنسخ تذكرة الدعم كاملة إلى نظام التطوير ثم متابعة الاثنين يدوياً، والسبب أن النسختين تختلفان خلال يومين، وإنما اجعل بطاقة التطوير تشير إلى تذكرة الدعم، واجعل حقلاً واحداً في تذكرة الدعم يحمل رابط البطاقة، فيعرف كل طرف أين يجد الحقيقة. ## فريق داخلي أم دعم خارجي؟ القرار هنا ليس مالياً فقط، فلكل خيار نقاط قوة ونقاط ضعف: - **نقاط القوة في الفريق الداخلي:** يعرف الأنظمة والناس والسياسات، ويتعلم من كل تذكرة، ويستطيع أن يذهب إلى المكتب. - **نقاط الضعف في الفريق الداخلي:** التغطية بعد الدوام والإجازات صعبة في الفريق الصغير، والخبرات النادرة مكلفة. - **نقاط القوة في المزود الخارجي:** تغطية أوسع في الساعات، وعدد أكبر من الفنيين في الذروة، وخبرات لا تحتاجها كل يوم. - **نقاط الضعف في المزود الخارجي:** لا يعرف بيئتك، ويحتاج صلاحيات عليها، وتنتقل المعرفة إليه بدل أن تبقى عندك. والحل الذي يتكرر في أغلب الشركات مزيج من الاثنين: فريق داخلي يملك النظام وقاعدة المعرفة والهوية والصلاحيات المميزة، ومزود خارجي للمكالمات بعد الدوام أو للدعم الميداني في الفروع. وإذا اخترت مزوداً خارجياً فتأكد من أربعة أمور قبل التوقيع: - أن ال SLA في العقد مكتوب بالأوقات والأولويات نفسها التي في نظامك. - أن فنيي المزود يدخلون بحسابات شخصية من مزود الهوية بدور محدد، وليس بحساب مشترك. - أن تبقى التذاكر والمعرفة في نظامك أنت، وتعود إليك إذا انتهى العقد. - أن أداة الدعم عن بعد التي يستخدمها مسجلة ومراقبة، وليست أداة اختارها الفني بنفسه. ## شكل الفريق في شركة صغيرة وفي جامعة الهيكل يتبع الحجم، والخطأ الشائع أن تنسخ الشركة الصغيرة هيكل شركة كبيرة قرأت عنه، والجدول التالي يقارن بين حجمين: | الجانب | شركة صغيرة بفريق من 2 إلى 5 | جامعة أو منظمة كبيرة | | ----------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------- | | المستويات | مستوى واحد عملياً، والجميع يستقبل الطلبات ويحلها ويطلب المساعدة من بعضهم | مكتب خدمة مستقل، ودعم ميداني لكل مبنى أو كلية، وفرق متخصصة | | الأدوار | كل شخص يحمل عدة أدوار، ويكتب في نظام التذاكر من يحمل كل دور | قائد فريق لكل مجموعة، ومدير تقديم خدمة، ومدير أصول متفرغ | | بعد الدوام | مناوبة أسبوعية لهاتف واحد للأنظمة الحرجة فقط، أو مزود خارجي | مناوبة دعم بجدول، ومناوبة هندسة لكل فريق مالك للخدمات الحرجة | | الذروة | بداية الأسبوع وموظفون جدد | بداية الفصل الدراسي ومواعيد التسجيل والاختبارات، حيث يتضاعف الطلب أياماً معدودة | | أهم استثمار | قاعدة معرفة لأكثر عشرة طلبات، والخدمة الذاتية لكلمات المرور | حساب عدد الموظفين للذروة، ومصفوفة تصعيد، وعقود OLA مع الفرق المتخصصة | ## تجربة عملية: كم موظفاً تحتاج على الهاتف؟ أصعب سؤال يسأله المدير هو «كم موظفاً نحتاج؟»، والإجابة البسيطة أن نقسم عدد المكالمات على ما يستطيع الموظف أن يرد عليه، فإذا كانت 40 مكالمة في الساعة ومدة المكالمة ست دقائق فهذا يعني أربع ساعات عمل في كل ساعة، أي أربعة موظفين. وهذا الحساب خطأ، والسبب أن المكالمات لا تصل بانتظام، فقد تصل خمس في دقيقة واحدة ثم لا يصل شيء خمس دقائق، وأربعة موظفين مشغولون طوال الوقت يعني طابور انتظار يكبر بلا نهاية. والطريقة المعروفة للحساب في مراكز الاتصال هي معادلة Erlang C، وسوف نكتب سكربتاً بلغة Python يحسبها ونشغله في Container حتى لا نثبت شيئاً على الجهاز. ### المدخلات والمعادلة تحتاج المعادلة أربعة مدخلات: - **عدد المكالمات في الساعة:** في ساعة الذروة وليس متوسط اليوم، ومصدره تقارير نظام الهاتف أو نظام التذاكر. - **متوسط مدة المعالجة AHT:** وهو اختصار Average Handle Time، أي مدة المكالمة مع ما بعدها من كتابة في التذكرة. - **هدف مستوى الخدمة Service Level:** مثل أن يرد على 80% من المكالمات خلال 30 ثانية، وهذا هدف نختاره نحن في التجربة وليس رقماً عاماً. - **نسبة الانكماش Shrinkage:** الوقت الذي يكون فيه الموظف في الدوام ولكنه ليس على الهاتف، أي الاستراحة والتدريب والاجتماعات والإجازات، ووضعناها 30% كافتراض قابل للتعديل. ومن أول مدخلين نحسب حجم الحركة Traffic بوحدة Erlang، أي عدد المكالمات في الساعة مضروباً في مدة المعالجة بالساعات. ثم تعطي [معادلة Erlang C](https://en.wikipedia.org/wiki/Erlang%5F%28unit%29?ref=arabroot.io) احتمال أن ينتظر المتصل لأن كل الموظفين مشغولون، ومنه نحسب نسبة من يرد عليهم خلال الوقت المستهدف، ومتوسط وقت الرد ASA (Average Speed of Answer)، وهو الاحتمال نفسه مضروباً في مدة المعالجة ومقسوماً على عدد الموظفين ناقص حجم الحركة، كما في متوسط الانتظار في [نموذج الطابور M/M/c](https://en.wikipedia.org/wiki/M/M/c%5Fqueue?ref=arabroot.io). ولاحظ افتراضات المعادلة كما في الصفحة نفسها: المكالمات تصل عشوائياً، ومدة المكالمة موزعة أسياً، والطابور لا حد له، والمتصل لا يغلق الخط أثناء الانتظار، والأخير غير صحيح في الواقع، ولذلك تعامل النتيجة كتقدير للتخطيط. ### تشغيل الحساب السكربت `erlang.py` موجود في مجلد التجربة، ولا يحتاج أي حزمة خارجية، والجزء الأساسي منه كما يلي: ```python def erlang_b(n, a): # Iterative Erlang B, stable for large n (no factorials) b = 1.0 for k in range(1, n + 1): b = a * b / (k + a * b) return b def erlang_c(n, a): # Probability that a call waits (n agents, a Erlangs of traffic) if n <= a: return 1.0 b = erlang_b(n, a) return n * b / (n - a * (1 - b)) def service_level(n, a, aht, t): # Share of calls answered within t seconds if n <= a: return 0.0 return 1 - erlang_c(n, a) * math.exp(-(n - a) * t / aht) ``` ولاحظ أننا نحسب Erlang C من Erlang B بطريقة تكرارية بدل المضروب Factorial الموجود في الصيغة المكتوبة، والسبب أن المضروب يكبر بسرعة ويسبب أخطاء في الحساب عندما يكون عدد الموظفين كبيراً. والأمر التالي يشغل السكربت في Container من Image بايثون الرسمية دون أي تثبيت: ```bash docker run --rm --name lab-itam-erlang -v "$PWD:/lab:ro" -w /lab \ python:3.13.16-slim python erlang.py ``` والمخرج سوف يكون كما يلي، وهذا الجزء الأول منه لساعة الذروة بأربعين مكالمة ومدة معالجة ست دقائق: ```text == 1. Peak hour on the phone line: 40 calls/h, AHT 6 min, target 80% within 30 s traffic A = 40 calls/h x 360s / 3600 = 4.00 Erlangs agents occupancy P(wait) SL<=30s ASA s 4 100% 100.0% 0.0% inf 5 80% 55.4% 49.0% 199.5 6 67% 28.5% 75.9% 51.3 7 57% 13.5% 89.5% 16.2 8 50% 5.9% 95.8% 5.3 9 44% 2.4% 98.4% 1.7 required on the phones: 7; with 30% shrinkage (breaks, training, leave): 10.00 -> 10 scheduled ``` في المخرج أعلاه لاحظ التالي: - الصف الأول هو الحساب البسيط: أربعة موظفين بنسبة إشغال Occupancy تبلغ 100%، أي أن كل متصل ينتظر، ومتوسط الانتظار لا نهائي لأن الطابور لا يفرغ أبداً. - خمسة موظفين يردون على 49% فقط خلال 30 ثانية، ومتوسط الانتظار 199.5 ثانية، أي أكثر من ثلاث دقائق، مع أن الموظف الخامس يبدو «زائداً» في الحساب البسيط. - الهدف يتحقق عند سبعة موظفين بنسبة 89.5%، وليس عند ستة التي تعطي 75.9%، ولاحظ أن الإشغال عند سبعة هو 57% فقط، وهذا ليس كسلاً وإنما ثمن الرد السريع على حركة عشوائية. - سبعة على الهاتف يعني عشرة في الجدول بعد افتراض انكماش 30%، لأن 7 مقسومة على 0.7 تساوي 10. ### جدول الحساسية: ما الذي يغير الرقم أكثر؟ القسم الثاني من المخرج يكرر الحساب لأعداد مكالمات ومدد معالجة مختلفة بالهدف نفسه: ```text == 2. Sensitivity: agents needed for 80% within 30 s calls/h AHT 4m AHT 6m AHT 8m 20 3 4 5 30 4 5 7 40 5 7 8 50 6 8 10 60 7 9 12 ``` والقسم الثالث يغير الهدف نفسه: ```text == 3. Sensitivity to the target itself (40 calls/h, AHT 6 min) 80% within 60s -> 7 agents (occupancy 57%, reaches 91.8%) 80% within 30s -> 7 agents (occupancy 57%, reaches 89.5%) 90% within 30s -> 8 agents (occupancy 50%, reaches 95.8%) 90% within 20s -> 8 agents (occupancy 50%, reaches 95.3%) 95% within 20s -> 8 agents (occupancy 50%, reaches 95.3%) ``` وفي هذين الجدولين ثلاثة دروس: - تقليل مدة المعالجة يوفر موظفين مثل تقليل عدد المكالمات تقريباً، فعند 40 مكالمة يكفي خمسة موظفين بمدة أربع دقائق بدل سبعة بست دقائق، وهنا تظهر قيمة قاعدة المعرفة والأدوات الجيدة، لأنها تقصر المكالمة. - العلاقة غير خطية، فالانتقال من 50 إلى 60 مكالمة بمدة ثماني دقائق يحتاج موظفين إضافيين، ولكن من 20 إلى 30 بمدة أربع دقائق يحتاج موظفاً واحداً. - الموظف الواحد يغير مستوى الخدمة بقفزات كبيرة، فبين سبعة وثمانية موظفين يرتفع الرد خلال 30 ثانية من 89.5% إلى 95.8%، ولذلك فإن هدفي 80% و90% لا يختلفان كثيراً في التكلفة هنا، بينما تختلف تجربة المتصل كثيراً. ### طابور واحد أم طابوران؟ لنفرض أن للجامعة حرمين، ولكل حرم 20 مكالمة في الساعة، فهل نضع فريقاً لكل حرم أم طابوراً واحداً يخدم الاثنين؟ والقسم الرابع من المخرج يجيب: ```text == 4. One shared queue or two separate queues (two campuses, 20 calls/h each) two separate queues: 4 + 4 = 8 agents one shared queue: 7 agents ``` الطابور المشترك يحقق الهدف نفسه بموظف أقل، والسبب أن ذروات الحرمين لا تحدث في اللحظة نفسها، فالموظف الفارغ في طابور يستطيع أن يرد على متصل ينتظر في الطابور الآخر. وهذا الفرق يكبر مع عدد الطوابير، ولهذا لا تقسم مكتب الخدمة Service Desk إلى خطوط لكل قسم أو نظام إلا إذا احتاج كل خط مهارة لا يملكها الآخرون، وابق الدعم الميداني وحده موزعاً على المباني. ### التذاكر ليست مكالمات معادلة Erlang C تفترض أن المتصل ينتظر على الخط، أما البريد والبوابة فالطلب ينتظر في الطابور ساعات دون أن يغلق أحد الخط، ولهذا نحسبها بطريقة حجم العمل Workload، والقسم الخامس من المخرج كما يلي: ```text == 5. Email and portal tickets are not a phone queue: workload method 120 tickets/day x 15 min = 30.0 h of work one agent: 7.5 h x 70% productive = 5.25 h/day agents for tickets: 5.71 -> 6 ``` ولاحظ أن الأرقام هنا مدخلات نختارها للمثال، أي 120 تذكرة في اليوم بمتوسط 15 دقيقة، ودوام 7.5 ساعات منها 70% عمل فعلي على التذاكر. واستبدلها بأرقامك من نظام التذاكر، ومدة المعالجة تجدها في حقل الوقت المسجل Time Accounting إذا كان الفريق يسجله، وإلا فخذ عينة من التذاكر وقس وقتها يدوياً. ### اكسرها: عندما تأتي الذروة ولم تحسب لها لنفرض أن الجامعة في أول أسبوع من الفصل وصلت إلى 60 مكالمة في الساعة بالمدة نفسها، وبقي على الهاتف سبعة موظفين كما في الأسبوع العادي. والقسم السابع من المخرج يحسب هذه الحالة: ```text == 7. Break it: start-of-term peak (60 calls/h) with the normal 7 agents traffic A = 60 calls/h x 360s / 3600 = 6.00 Erlangs agents occupancy P(wait) SL<=30s ASA s 6 100% 100.0% 0.0% inf 7 86% 61.4% 43.5% 221.0 8 75% 35.7% 69.8% 64.3 needed for 80% within 30 s: 9 ``` زيادة المكالمات بنسبة 50% لم تخفض الرد خلال 30 ثانية بنسبة 50%، وإنما أنزلته من 89.5% إلى 43.5%، ورفعت متوسط الانتظار من 16.2 ثانية إلى 221 ثانية، أي أكثر من ثلاث دقائق ونصف. وفي الواقع يحدث شيء أسوأ لا تحسبه المعادلة: يغلق المتصلون الخط ثم يعيدون الاتصال، فيرتفع عدد المكالمات فوق حقيقته، ويرسل الموظف نفسه بريداً ثم يفتح تذكرة من البوابة، فتصبح المشكلة الواحدة ثلاث تذاكر. والحل ليس معادلة أدق، وإنما أن تعرف موسم الذروة مسبقاً، فتنقل إليه موظفين من الدعم الميداني، وتنشر قبله مقالات الخدمة الذاتية لأكثر خمس مشكلات في بداية الفصل. ### جدول المناوبة القسم الأخير من المخرج جدول مناوبة لخمسة أشخاص بعد الدوام، لكل أسبوع مناوب أساسي Primary ومناوب احتياطي Backup: ```text == 6. After-hours rota: 5 people, primary and backup, one week each week starting primary backup 2026-11-01 Huda Faisal 2026-11-08 Omar Reem 2026-11-15 Faisal Majed 2026-11-22 Reem Huda 2026-11-29 Majed Omar weeks per person (primary, backup): Huda 1+1, Omar 1+1, Faisal 1+1, Reem 1+1, Majed 1+1 ``` في الجدول أعلاه لاحظ التالي: - الاحتياطي هو الشخص الذي يبعد مكانين في القائمة، فلا يأتي أحد احتياطياً في الأسبوع الذي يلي مناوبته الأساسية مباشرة، ولا قبلها مباشرة، فيبقى له أسبوعان على الأقل دون أي مناوبة. - كل شخص يناوب أسبوعاً أساسياً وأسبوعاً احتياطياً في كل خمسة أسابيع، وهذا عادل ولكنه ثقيل لفريق صغير، فإذا كانت الاتصالات بعد الدوام قليلة فاجعل المناوبة على الأنظمة الحرجة فقط. - الأسماء في الجدول تتغير، أما المصفوفة فتشير إلى «مناوب الدعم» كدور، وجدول المناوبة هو الذي يحول الدور إلى اسم ورقم هاتف في ذلك الأسبوع. ## أخطاء شائعة - حساب عدد الموظفين بقسمة العمل على الساعات للهاتف، فيكون الإشغال 100% والطابور لا ينتهي. - حساب الموظفين لمتوسط اليوم وليس لساعة الذروة وموسم الذروة. - تقسيم مكتب الخدمة Service Desk إلى خطوط صغيرة لكل نظام، فيحتاج كل خط موظفين أكثر من حصته. - مناوب واحد يستقبل اتصالات الموظفين وتنبيهات المراقبة معاً، فيتعب من الاثنين. - تحويل التذكرة إلى L3 وتركها، فلا يتابعها أحد مع المستخدم ولا يعود الحل إلى قاعدة المعرفة. - مصفوفة تصعيد بأسماء الأشخاص بدل الأدوار. - مزود خارجي يدخل بحساب مشترك، وتبقى تذاكره ومعرفته في نظامه هو. - مقارنة أرقام الفريق بأرقام «متوسط الصناعة» من استبيانات لا تذكر طريقتها. ## الخلاصة - الدعم الفني ثلاث وظائف: مكتب الخدمة Service Desk كمدخل واحد، والدعم الميداني، والمتخصصون، ولكل منها مقياس. - المستويات من L0 إلى L4 تصعد بالتذكرة، وال Shift-Left يعيد الحل مكتوباً إلى مستوى أقرب، ومكتب الخدمة Service Desk يبقى صاحب التذكرة. - نموذج Intelligent Swarming يلغي المستويات ويجعل من يأخذ الطلب يملكه حتى يحل، ويناسب العمل الجديد والمعقد أكثر من الطلبات المعروفة. - مناوبة الدعم تستقبل الناس، ومناوبة الهندسة تستقبل التنبيهات، والتسليم بينهما مكتوب في مصفوفة تصعيد بالأدوار. - في التجربة احتاجت 40 مكالمة في الساعة بمدة ست دقائق سبعة موظفين على الهاتف وليس أربعة، وعشرة في الجدول بعد الانكماش، وكان الطابور المشترك لحرمين أوفر بموظف من طابورين منفصلين. وفي المقال التالي سوف ننتقل من الناس إلى الأجهزة التي يدعمونها، أي دورة حياة جهاز المؤسسة من الشراء إلى الإتلاف، مع تجربة على Snipe-IT: [![](https://arabroot.io/content/images/2026/10/itam-lifecycle-cover-cover.webp)دليلدورة حياة أجهزة المؤسسة IT Asset Managementكيف تتابع كل جهاز في مؤسستك من الطلب والشراء إلى التسليم والجرد والإرجاع، ثم المسح والإتلاف بسجل كامل.](https://arabroot.io/articles/%D8%AF%D9%88%D8%B1%D8%A9-%D8%AD%D9%8A%D8%A7%D8%A9-%D8%A7%D8%AC%D9%87%D8%B2%D8%A9-%D8%A7%D9%84%D9%85%D8%A4%D8%B3%D8%B3%D8%A9-%D9%85%D9%86-%D8%A7%D9%84%D8%B4%D8%B1%D8%A7%D8%A1-%D8%A7%D9%84%D9%89-%D8%A7%D9%84%D8%A7%D8%AA%D9%84%D8%A7%D9%81/)[![](https://arabroot.io/content/images/2026/10/device-management-cover-cover.webp)دليلMDM: إدارة أجهزة الموظفين وتأمينها بأدوات مفتوحةكيف تدير الشركة حواسيب موظفيها وهواتفهم وتفرض عليها التشفير والتحديث، وما الذي تستطيع أن تراه فعلاً على كل جهاز.](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D8%AC%D9%87%D8%B2%D8%A9-%D8%A7%D9%84%D9%85%D9%88%D8%B8%D9%81%D9%8A%D9%86-%D9%88%D8%AA%D8%A3%D9%85%D9%8A%D9%86%D9%87%D8%A7-mdm/)[![](https://arabroot.io/content/images/2026/10/jml-cover-cover.webp)دليلدورة حياة حساب الموظف JML من أول يوم إلى آخر يومكيف تجعل الموارد البشرية مصدر كل حساب، فيجد الموظف ما يحتاجه في يومه الأول وتغلق كل أبوابه في يوم مغادرته.](https://arabroot.io/articles/%D8%AF%D9%88%D8%B1%D8%A9-%D8%AD%D9%8A%D8%A7%D8%A9-%D8%AD%D8%B3%D8%A7%D8%A8-%D8%A7%D9%84%D9%85%D9%88%D8%B8%D9%81-jml/) ## سجل التحديثات - أكتوبر 2026: كتابة المقال مع حاسبة Erlang C حقيقية بلغة Python 3.13.16 في Container من python:3.13.16-slim على Docker Engine 29.8.0، ومعلومات Intelligent Swarming من صفحات Consortium for Service Innovation، والشهادات من صفحات CompTIA وHDI كما هي في 13 أكتوبر 2026.