> ## 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. # إدارة خدمات تقنية المعلومات ITSM: ما الذي تحتاجه فعلاً؟ - URL: https://arabroot.io/articles/ادارة-خدمات-تقنية-المعلومات-itsm/ - Published: 2026-10-13T07:15:00.000Z - Updated: 2026-10-13T08:00:22.000Z - Description: كيف تنظم عمل الدعم الفني بالتذاكر والمؤقتات والتصعيد، وما الذي تأخذه من ITIL دون بيروقراطية. - Author: فريق عرب رووت - Tags: الأدلة التقنية, الاستضافة الذاتية والتطبيقات, الاستضافة الذاتية في أغلب الشركات الصغيرة يبدأ الدعم الفني برسالة في مجموعة واتساب أو مكالمة مباشرة لموظف تقنية المعلومات الذي يعرفه الجميع، وهذا يعمل جيداً حتى يكبر عدد الموظفين، فتضيع الطلبات بين الرسائل، ولا يعرف أحد كم طلباً ينتظر ولا من يعمل على ماذا، ويتكرر العطل نفسه كل أسبوع لأن أحداً لم يبحث عن سببه، ثم يأتي المدير ويسأل «لماذا تأخر إصلاح نظام الرواتب؟» فلا يوجد سجل يجيب عن السؤال. وهذا بالضبط ما تحاول إدارة خدمات تقنية المعلومات ITSM (IT Service Management) أن تحله: أن يصبح عمل قسم تقنية المعلومات خدمة لها مدخل واحد وسجل واضح ووعود زمنية معروفة، بدل أن يكون مجموعة من الخدمات الشخصية. وسوف نناقش في هذا المقال ما يلي: - الفرق بين الحادثة Incident والمشكلة Problem والتغيير Change وطلب الخدمة Service Request، ولماذا يضر خلطها. - كتالوج الخدمات Service Catalog وبوابة الخدمة الذاتية Self-Service Portal، واتفاقيات SLA وOLA والتصعيد Escalation. - قاعدة المعرفة Knowledge Base، والفرق بين قاعدة بيانات الإعدادات CMDB وإدارة الأصول Asset Management. - إطار ITIL 4 ومن يملكه اليوم، وما المفيد فيه، وكيف تأخذ منه دون أن تغرق في البيروقراطية. - المقاييس مثل MTTR ونسبة الحل من أول تواصل First Contact Resolution وحجم المتراكم Backlog ورضا المستخدم CSAT، وأيها يخدع. - تحويل البريد إلى تذاكر Email-to-Ticket وباقي القنوات، والفرق بين ITSM وESM. - تجربة حقيقية على Zammad: تذكرة من البريد، ثم SLA بدقيقتين، ثم تجاوز الموعد وتصعيد تلقائي إلى الدعم الثاني، ثم ما يحدث عندما نخطئ في إعداد التصعيد. - كيف يبدأ فريق تقنية معلومات صغير خطوة بعد خطوة. أما اختيار النظام نفسه، أي Zammad أو GLPI أو FreeScout أو osTicket أو iTop أو Znuny وغيرها، فقد خصصنا له مقالاً مستقلاً بتراخيصها ودعمها للعربية وتجربة على ثلاثة منها، وفي هذا المقال نركز على المفاهيم التي تحتاجها قبل أن تختار أي نظام: [![](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/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/access-gateways-cover-cover.webp)دليلأدوات الوصول الآمن إلى السيرفرات: خريطة مفتوحة المصدرخريطة لأدوات الوصول الآمن مفتوحة المصدر إلى السيرفرات، ماذا تحل كل عائلة منها وما ترخيصها، وكيف تختار ما يناسب فريقك.](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/) ## الحادثة والمشكلة والتغيير وطلب الخدمة أول قرار في أي نظام تذاكر هو نوع السجل، لأن كل نوع يجيب عن سؤال مختلف ويقاس بطريقة مختلفة، وخلطها هو السبب الأول في أن تقارير الدعم الفني لا يفهمها أحد. والصورة التالية تبين الأنواع الأربعة وكيف يقود أحدها إلى الآخر: ![مخطط يتوسطه مكتب الخدمة Service Desk ومن حوله أربعة صناديق: الحادثة Incident بمعنى شيء تعطل الآن مثل خطأ الدخول إلى نظام الرواتب، وطلب الخدمة Service Request بمعنى طلب لا عطل فيه مثل جهاز جديد أو صلاحية VPN، والمشكلة Problem بمعنى سبب تكرار الحوادث، والتغيير Change بمعنى تعديل مخطط له موافقة وخطة رجوع، مع أسهم من الحادثة المتكررة إلى المشكلة، ومن المشكلة إلى التغيير، وسهم متقطع من التغيير الفاشل إلى حادثة جديدة](https://arabroot.io/content/images/2026/10/itsm-intro-01-itsm-records.webp) الحادثة تعيد الخدمة، والمشكلة تبحث عن السبب، والتغيير يصلحه بأمان، وطلب الخدمة ليس عطلاً أصلاً - **الحادثة Incident:** شيء كان يعمل وتوقف أو ساء أداؤه، مثل موظف لا يستطيع الدخول إلى نظام الرواتب أو طابعة الطابق الثاني لا تطبع. وهدف الحادثة Incident هو إعادة الخدمة بأسرع وقت ولو بحل مؤقت Workaround، وليس فهم السبب، ولذلك يقاس الفريق فيها بالوقت. - **المشكلة Problem:** السبب المجهول وراء حادثة أو عدة حوادث، فإذا تكرر خطأ الدخول خمس مرات في شهر فهناك مشكلة Problem واحدة خلف خمس حوادث Incident. وهدفها مختلف تماماً: التحقيق في السبب الأساسي Root Cause وإزالته، وقد تبقى المشكلة Problem مفتوحة أسابيع بينما تغلق كل حادثة في دقائق، وهذا طبيعي. - **التغيير Change:** أي تعديل مخطط له على شيء يعمل، مثل ترقية قاعدة بيانات نظام الرواتب أو تغيير قاعدة في الجدار الناري Firewall، وله طلب وتقييم للأثر وموافقة وموعد وخطة رجوع Rollback Plan. وغالباً يأتي التغيير Change من مشكلة Problem وجدنا سببها، ولاحظ السهم المتقطع في الصورة: التغيير الفاشل هو أحد أكثر مصادر الحوادث، ولهذا وجد التغيير كسجل مستقل. - **طلب الخدمة Service Request:** طلب لا يوجد فيه عطل، مثل حاسوب لموظف جديد أو صلاحية على مجلد أو إعادة تعيين كلمة المرور، وهو أكثر ما يصل إلى الدعم الفني عدداً في أغلب الشركات، ويحل بخطوات معروفة مسبقاً يمكن توثيقها وأتمتة جزء منها. وقد يتساءل البعض: ما الضرر إذا سجلنا كل شيء كتذكرة واحدة بنوع واحد؟ والإجابة أن متوسط وقت الحل سوف يصبح رقماً بلا معنى، لأنه يخلط طلب حاسوب يستغرق ثلاثة أيام بانتظار الشراء مع عطل حرج يجب أن يحل في ساعة، وكذلك سوف تختفي المشكلات Problem تماماً لأن كل تكرار يغلق كحادثة جديدة ولا يربطه أحد بما قبله. ولا تقم بتحويل كل شكوى إلى مشكلة Problem أيضاً، والسبب أن المشكلة سجل تحقيق له صاحب ووقت، فافتحها عندما تتكرر الحادثة أو عندما يكون أثرها كبيراً. ## كتالوج الخدمات وبوابة الخدمة الذاتية كتالوج الخدمات Service Catalog هو قائمة بما يقدمه قسم تقنية المعلومات فعلاً للموظفين، مثل «حساب بريد لموظف جديد» و«صلاحية VPN» و«تثبيت برنامج من القائمة المعتمدة»، ولكل بند منها نموذج يحدد الحقول المطلوبة، ومن يوافق عليه، وكم يستغرق عادة. وفائدته العملية أن الطلب يصل كاملاً من البداية، فبدل أن يكتب الموظف «أريد VPN» ثم يسأله الفني عن مديره وعن سبب الحاجة وعن مدة الصلاحية، يملأ النموذج هذه الحقول ويذهب الطلب إلى مديره للموافقة قبل أن يصل إلى الفني. وبوابة الخدمة الذاتية Self-Service Portal هي الصفحة التي يدخل منها الموظف ليفتح الطلبات من الكتالوج ويتابع حالة تذاكره ويبحث في قاعدة المعرفة قبل أن يكتب، ولاحظ أن قيمتها الكبرى في البحث قبل الكتابة: إذا وجد الموظف مقالاً يشرح طريقة ربط الطابعة فلن تصل التذكرة أصلاً. وابدأ بكتالوج صغير من خمسة إلى عشرة بنود هي الأكثر تكراراً عندك، والسبب أن كتالوجاً من مئة بند لا يحدثه أحد يتحول إلى قائمة طويلة يتجاهلها الموظفون ويعودون إلى واتساب. ## اتفاقيات SLA وOLA والتصعيد اتفاقية مستوى الخدمة SLA (Service Level Agreement) هي وعد زمني مكتوب بين قسم تقنية المعلومات ومن يخدمهم، مثل «نرد على الحادثة الحرجة خلال 15 دقيقة ونحلها خلال 4 ساعات في أوقات الدوام»، أما اتفاقية المستوى التشغيلي OLA (Operational Level Agreement) فهي وعد داخلي بين فرق القسم نفسه، مثل أن فريق الشبكات يرد على ما يحوله إليه الدعم الأول خلال ساعة، وبدون OLA لا يستطيع الدعم الأول أن يفي بال SLA لأن جزءاً من الوقت عند فريق آخر لا يلتزم بشيء. وفي أغلب الأنظمة يتكون ال SLA من ثلاثة مؤقتات، كما في [توثيق Zammad لاتفاقيات مستوى الخدمة](https://admin-docs.zammad.org/en/latest/manage/slas.html?ref=arabroot.io)، وهي: - **وقت الاستجابة الأولى First Response Time:** من إنشاء التذكرة حتى أول رد حقيقي من الفني إلى صاحبها، والرد الآلي «وصلتنا رسالتك» لا يحسب. - **وقت التحديث Update Time:** أقصى مدة بين ردين متتاليين، حتى لا تبقى التذكرة صامتة أياماً بعد الرد الأول. - **وقت الحل Solution Time:** من الإنشاء حتى إغلاق التذكرة. وتحسب هذه الأوقات على تقويم ساعات العمل Business Hours، فإذا كان الدوام ثماني ساعات في اليوم فإن SLA مدته 16 ساعة يعني يومي عمل، وهذا مذكور في التوثيق نفسه، وهو أكثر ما يربك من يقرأ تقارير SLA لأول مرة. ويختار النظام ال SLA المناسب لكل تذكرة حسب الأولوية Priority، والأولوية في أغلب الفرق تحسب من عاملين: الأثر Impact أي كم شخصاً أو خدمة تأثرت، والإلحاح Urgency أي هل يمكن الانتظار، فتعطل نظام الرواتب يوم صرف الرواتب أثره كبير وإلحاحه عال، فيصبح أولوية أولى P1 دون نقاش. والتصعيد Escalation نوعان: تصعيد وظيفي Functional Escalation ينقل التذكرة إلى فريق أعلى خبرة مثل الدعم الثاني L2 أو فريق الشبكات، وتصعيد إداري Hierarchical Escalation يبلغ قائد الفريق أو المدير بأن وعداً على وشك أن يكسر أو كسر فعلاً. والقاعدة المهمة هنا أن التصعيد يجب أن يكون آلياً ومرتبطاً بالمؤقت، لأن التصعيد الذي ينتظر أن يتذكره الفني لن يحدث في أكثر الأيام ازدحاماً، وهي بالضبط الأيام التي تحتاجه فيها، وسوف نرى ذلك عملياً في التجربة. ## قاعدة المعرفة قاعدة المعرفة Knowledge Base مجموعة مقالات قصيرة تجيب عن الأسئلة المتكررة، ولها جمهوران: الموظفون الذين يجدون الحل بأنفسهم في بوابة الخدمة الذاتية، والفنيون الذين يجدون حل الحادثة Incident التي رآها زميلهم قبل شهر. ولاحظ أن قاعدة المعرفة هي المكان الطبيعي لنتيجة المشكلة Problem، فعندما يعرف الفريق سبب تكرار خطأ الدخول ويجد حلاً مؤقتاً Workaround إلى أن يصل التغيير Change، يكتبه كمقال يسمى في ITIL الخطأ المعروف Known Error، فيستخدمه كل من يستلم حادثة مشابهة بدل أن يبدأ من الصفر. وأغلب أنظمة التذاكر فيها قاعدة معرفة مدمجة، ولكن بعض الفرق تفضل أداة توثيق مستقلة لأنها أفضل في الكتابة والتنظيم، وقد شرحنا اثنتين منها في [تثبيت Outline لقاعدة معرفة الفريق](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-outline-%D9%84%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-%D9%85%D8%B9%D8%B1%D9%81%D8%A9-%D8%A7%D9%84%D9%81%D8%B1%D9%8A%D9%82/) و[تثبيت BookStack لتوثيق الفريق](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-bookstack-%D9%84%D8%AA%D9%88%D8%AB%D9%8A%D9%82-%D8%A7%D9%84%D9%81%D8%B1%D9%8A%D9%82/). والقاعدة العملية أن يكون للمقال صاحب وتاريخ مراجعة، والسبب أن المقال الخطأ في قاعدة المعرفة أسوأ من عدم وجود مقال، لأن الموظف ينفذه بثقة. ## قاعدة بيانات الإعدادات CMDB وإدارة الأصول هذان المفهومان يخلط بينهما كثيرون لأن كليهما قائمة بالأجهزة والبرامج، ولكن كل واحد منهما يجيب عن سؤال مختلف، والصورة التالية تبين السيرفر نفسه من الجهتين: ![مخطط من جزأين يتوسطهما سجل السيرفر SRV-01: في جهة إدارة الأصول Asset Management يظهر السيرفر وترخيص مع حقول المالك والتكلفة 38,000 ريال وانتهاء الضمان ورقم العقد ودورة الحياة من الطلب إلى الاستخدام فالإصلاح فالإخراج من الخدمة، وفي جهة CMDB تظهر سلسلة علاقات من خدمة الرواتب Payroll إلى التطبيق payroll-web إلى السيرفر SRV-01 الذي يعتمد على قاعدة بيانات PostgreSQL والمحول SW-2، مع ملاحظة أن تعطل SW-2 يؤثر على خدمة الرواتب](https://arabroot.io/content/images/2026/10/itsm-intro-02-cmdb-assets.webp) إدارة الأصول تخدم المالية والمشتريات، وال CMDB تخدم الحوادث والتغييرات - **إدارة الأصول Asset Management:** تنظر إلى الجهاز كشيء له ثمن ومالك وضمان وعقد ودورة حياة من الشراء إلى الإخراج من الخدمة، وأسئلتها مالية وإدارية: كم حاسوباً لدينا؟ أين هو؟ مع من؟ متى ينتهي ضمانه؟ كم ترخيصاً اشترينا وكم نستخدم؟ وهذا ما تفعله أداة Snipe-IT ووحدة الأصول Assets في نظام GLPI مثلاً. - **قاعدة بيانات الإعدادات CMDB:** وهي اختصار Configuration Management Database، وتنظر إلى الشيء نفسه كعنصر إعدادات Configuration Item واختصاراً CI، والمهم فيها هو العلاقات: هذا السيرفر يشغل هذا التطبيق، وهذا التطبيق يقدم خدمة الرواتب، ويعتمد على قاعدة البيانات تلك وعلى المحول ذاك. وسؤالها تشغيلي: إذا تعطل هذا العنصر فما الذي سيتأثر؟ وإذا أردنا تغييره فمن يجب أن نبلغ؟ وقد يتساءل البعض: هل تحتاج شركة صغيرة إلى CMDB؟ والإجابة في الغالب لا تحتاج إلى قاعدة بيانات الإعدادات CMDB كاملة في البداية، والسبب أن CMDB لا يحدثها أحد هي أخطر من عدمها، لأن الفريق يتخذ قرار تغيير بناء على علاقات لم تعد صحيحة. ابدأ بسجل أصول دقيق، ثم أضف العلاقات للخدمات الحرجة فقط، مثل الرواتب والبريد والموقع، وحاول أن تملأها آلياً من أدوات الاكتشاف مثل وكيل GLPI أو osquery الذي شرحناه في [إدارة أجهزة الموظفين 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%D9%84%D9%87%D9%88%D9%85-%D9%84%D8%A7%D8%A8-%D8%A8%D9%85%D9%88%D8%A7%D8%B5%D9%81%D8%A7%D8%AA-%D8%A7%D9%84%D8%A5%D9%86%D8%AA%D8%A7%D8%AC-%D8%A7%D9%84%D8%AA%D8%B5%D9%85%D9%8A%D9%85-%D9%88%D8%A7%D9%84%D8%B9%D8%AA%D8%A7%D8%AF/) حيث ذكرنا NetBox كمصدر للحقيقة Source of Truth للشبكة. ## إطار ITIL: ماذا تأخذ منه وماذا تترك إطار ITIL (Information Technology Infrastructure Library) مجموعة من الممارسات الموثقة لإدارة خدمات تقنية المعلومات، بدأت من [توصيات وكالة CCTA الحكومية البريطانية في الثمانينيات](https://en.wikipedia.org/wiki/ITIL?ref=arabroot.io)، وصدر ITIL 4 في فبراير 2019\. أما من يملكه اليوم، فقد كانت تديره شركة Axelos، وهي مشروع مشترك أسسه مكتب مجلس الوزراء البريطاني مع شركة Capita في 2013، ثم [أكملت شركة PeopleCert الاستحواذ على Axelos في 2021](https://www.peoplecert.org/news-and-announcements/2021/peoplecert-completes-axelos-acquisition?ref=arabroot.io) بعد إعلانه في 21 يونيو 2021، فأصبحت PeopleCert هي مالكة ITIL والجهة التي تصدر شهاداته. ويجدر أن تعرف أن PeopleCert أصدرت في 2026 النسخة التالية باسم ITIL (Version 5)، وتقول في [صفحة الأسئلة الشائعة عن ITIL](https://www.peoplecert.org/help-and-support/faq-itil?ref=arabroot.io) إنها تطور وليست قطيعة، وإنها تحتفظ ب 34 ممارسة إدارية مقسمة إلى ممارسات إدارة المنتجات والخدمات وممارسات الإدارة العامة، وإن الخطة الحالية هي إيقاف كل وحدات ITIL 4 في 31 ديسمبر 2027\. وهذا مهم إذا كنت تخطط لشهادة، أما إذا كنت تريد تنظيم قسمك فالأفكار نفسها لم تتغير، كما تقول PeopleCert في [شرحها للنسخة الجديدة](https://www.peoplecert.org/news-and-announcements/itil-version-5-explained?ref=arabroot.io). والمفيد عملياً لفريق صغير من بين الممارسات الكثيرة ست فقط: - مكتب الخدمة Service Desk كمدخل واحد لكل الطلبات. - إدارة الحوادث Incident Management وإدارة طلبات الخدمة Service Request Management، كل واحدة بمسارها. - إدارة المشكلات Problem Management للحوادث المتكررة فقط. - تمكين التغيير Change Enablement، وهو الاسم الذي يستخدمه ITIL 4 لما كان يسمى إدارة التغيير Change Management. - إدارة المعرفة Knowledge Management لتوثيق الحلول. - إدارة مستوى الخدمة Service Level Management، أي ال SLA ومراجعته. وأهم ما في ITIL 4 في رأينا ليس الممارسات وإنما المبادئ التوجيهية السبعة Guiding Principles، لأنها تطبق على أي فريق مهما كان حجمه، وثلاثة منها هي علاج البيروقراطية التي يشتكي منها الناس عند ذكر ITIL: ![سبع بطاقات للمبادئ التوجيهية في ITIL 4: ركز على القيمة Focus on Value، ابدأ من حيث أنت Start Where You Are، تقدم على مراحل مع التغذية الراجعة Progress Iteratively with Feedback، تعاون واجعل العمل مرئياً Collaborate and Promote Visibility، فكر واعمل بنظرة شاملة Think and Work Holistically، اجعلها بسيطة وعملية Keep It Simple and Practical، حسن ثم أتمت Optimize and Automate، والبطاقات 2 و3 و6 بالبرتقالي لأنها تعالج البيروقراطية مباشرة](https://arabroot.io/content/images/2026/10/itsm-intro-07-guiding-principles.webp) المبادئ السبعة، والبرتقالي منها هو ما يمنع البيروقراطية والبيروقراطية تأتي عادة من ثلاثة أخطاء: - لجنة موافقة على التغيير CAB (Change Advisory Board) تجتمع أسبوعياً لتوافق على كل تغيير مهما كان صغيراً. - نماذج تذاكر فيها عشرون حقلاً إجبارياً لا يقرؤها أحد. - فصل كل ممارسة في فريق مستقل، في قسم كله خمسة أشخاص. والحل لأولها أن تقسم التغييرات إلى ثلاثة أنواع، وتجعل أغلب العمل اليومي من النوع الأول: | نوع التغيير | متى يستخدم | الموافقة | | ------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------- | | التغيير القياسي Standard Change | عمل معروف ومكرر قليل الخطر، مثل إضافة مستخدم أو تثبيت برنامج معتمد | موافقة مسبقة مرة واحدة، ثم ينفذ دون اجتماع | | التغيير العادي Normal Change | تغيير جديد أو له أثر كبير، مثل ترقية قاعدة بيانات الرواتب | تقييم الخطر وخطة الرجوع، ثم موافقة من له الصلاحية | | التغيير الطارئ Emergency Change | إصلاح عاجل لحادثة أو ثغرة لا يحتمل الانتظار | موافقة سريعة من شخص محدد، ثم مراجعة بعد التنفيذ | وقد يتساءل البعض: هل نحتاج شهادة ITIL قبل أن نبدأ؟ لا، والتفصيل أن الشهادة تفيد من يعمل في شركات كبيرة أو يتعامل مع عملاء يشترطونها، أما الفريق الصغير فيكفيه أن يفهم أنواع السجلات والمؤقتات والمبادئ أعلاه، ثم يحسن عمله بالتدريج. ## المقاييس: أيها يفيد وأيها يخدع كل نظام تذاكر يعطيك لوحة مليئة بالأرقام، والخطر أن الفريق يبدأ بتحسين الرقم بدل تحسين الخدمة. وهذه أشهر المقاييس وكيف تخدع: - **متوسط وقت الإصلاح MTTR:** وهو اختصار Mean Time To Repair أو Resolve، وقد شرحنا معادلته وعلاقته بالتوفر في [مفاهيم التوفر العالي](https://arabroot.io/articles/%D9%85%D9%81%D8%A7%D9%87%D9%8A%D9%85-%D8%A7%D9%84%D8%AA%D9%88%D9%81%D8%B1-%D8%A7%D9%84%D8%B9%D8%A7%D9%84%D9%8A-high-availability-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/)، وفي الدعم الفني يخدع لأن المتوسط يخفي الحالات الطويلة، فعشر تذاكر تحل في خمس دقائق وتذكرة واحدة تبقى ثلاثة أيام تعطي متوسطاً يبدو مقبولاً بينما الموظف صاحب التذكرة الطويلة غاضب. استخدم الوسيط Median والنسبة المئوية 90 بدل المتوسط، وافصل الحوادث عن طلبات الخدمة. ولاحظ أن اسم MTTR يستخدم أيضاً في مقاييس DORA بمعنى آخر هو التعافي من النشر الفاشل، كما ذكرنا في [الفرق بين DevOps وSRE وPlatform Engineering](https://arabroot.io/articles/%D8%A7%D9%84%D9%81%D8%B1%D9%82-%D8%A8%D9%8A%D9%86-devops-%D9%88-sre-%D9%88-platform-engineering/)، فتأكد من التعريف قبل أن تقارن رقمك برقم غيرك. - **نسبة الحل من أول تواصل FCR:** وهو اختصار First Contact Resolution، أي كم تذكرة حلت دون تحويل أو رد ثان، وهو مقياس جيد لمعرفة الدعم الأول، ولكنه يخدع عندما يكافأ الفريق عليه، فيغلق الفني التذكرة بحل ناقص ويطلب من الموظف أن يفتح تذكرة جديدة إذا عاد العطل، فترتفع النسبة ويتكرر العطل. راقبه دائماً مع نسبة إعادة فتح التذاكر Reopen Rate. - **حجم المتراكم Backlog:** عدد التذاكر المفتوحة، والرقم وحده لا يقول شيئاً، والمفيد هو اتجاهه وعمر أقدم التذاكر فيه، فمتراكم ثابت عند 40 تذكرة عمرها يومان أفضل من متراكم عند 20 فيها خمس تذاكر عمرها شهران. - **رضا المستخدم CSAT:** وهو اختصار Customer Satisfaction، أي استبيان قصير بعد الإغلاق، ويخدع لأن من يجيب هم غالباً الراضون جداً أو الغاضبون جداً، ونسبة المجيبين قد تكون صغيرة، فاقرأ التعليقات المكتوبة قبل النسبة، وانشر عدد المجيبين بجانبها دائماً. - **نسبة الالتزام بال SLA:** تخدع إذا كانت الأولويات توضع بعد فوات الوقت، أو إذا كان الفريق يغير حالة التذكرة إلى «بانتظار المستخدم» ليوقف المؤقت، فراجع عينة من التذاكر يدوياً كل شهر. ## البريد والقنوات الأخرى أبسط قناة وأهمها هي البريد، أي تحويل البريد إلى تذاكر Email-to-Ticket: يكون للدعم الفني عنوان مثل helpdesk@ ويقرأه النظام دورياً عبر IMAP أو عبر واجهة Microsoft 365 أو Gmail، فيحول كل رسالة جديدة إلى تذكرة وكل رد على الرسالة إلى تعليق في التذكرة نفسها، ويعرف ذلك من رقم التذكرة مثل \[Ticket#37003\] في آخر عنوان الرسالة. وقد شرحنا كيف تنتقل الرسالة بين السيرفرات في [كيف يعمل البريد الإلكتروني SMTP وIMAP](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D9%8A%D8%B9%D9%85%D9%84-%D8%A7%D9%84%D8%A8%D8%B1%D9%8A%D8%AF-%D8%A7%D9%84%D8%A7%D9%84%D9%83%D8%AA%D8%B1%D9%88%D9%86%D9%8A-smtp-%D9%88-imap/)، ولاستضافة بريد المؤسسة نفسه ارجع إلى [دليل استضافة البريد للمؤسسات](https://arabroot.io/articles/%D8%AF%D9%84%D9%8A%D9%84-%D8%A7%D8%B3%D8%AA%D8%B6%D8%A7%D9%81%D8%A9-%D8%A7%D9%84%D8%A8%D8%B1%D9%8A%D8%AF-%D8%A7%D9%84%D8%A5%D9%84%D9%83%D8%AA%D8%B1%D9%88%D9%86%D9%8A-%D9%84%D9%84%D9%85%D8%A4%D8%B3%D8%B3%D8%A7%D8%AA/). وبعد البريد تأتي بوابة الخدمة الذاتية، ثم الهاتف حيث يسجل الفني التذكرة أثناء المكالمة، ثم المحادثة Chat أو تطبيقات المراسلة. ولاحظ أن أنظمة خدمة العملاء مثل [Chatwoot](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-chatwoot-%D9%84%D8%AE%D8%AF%D9%85%D8%A9-%D8%A7%D9%84%D8%B9%D9%85%D9%84%D8%A7%D8%A1/) مصممة للعملاء الخارجيين وقنوات المحادثة، وليس فيها مفاهيم مثل المشكلة Problem والتغيير Change والأصول، فلا تستخدمها كنظام ITSM لقسم تقنية المعلومات. والقاعدة المهمة في القنوات أن كل قناة تنتهي في السجل نفسه، فإذا قبل الفني طلباً في الممر أو في واتساب فعليه أن يسجله تذكرة، والسبب أن الطلب غير المسجل لا يدخل في أي مقياس ولا يتعلم منه أحد. ## إدارة خدمات المؤسسة ESM خارج تقنية المعلومات إدارة خدمات المؤسسة ESM (Enterprise Service Management) هي تطبيق الفكرة نفسها على أقسام أخرى غير تقنية المعلومات، فالموارد البشرية تستقبل طلبات شهادات الراتب والإجازات، والمرافق تستقبل بلاغات التكييف والصيانة، والمالية تستقبل طلبات العهد والسلف، وكل هذه طلبات خدمة Service Request لها كتالوج ونماذج وموافقات ومؤقتات. والفرق بين ITSM وESM ليس في الأداة غالباً، فأغلب الأنظمة التي سنقارنها تسمح بمجموعات وقوائم انتظار لأقسام أخرى، وإنما في من يملك الكتالوج ومن يرد. ولا تقم بتوسيع النظام إلى أقسام أخرى قبل أن يعمل جيداً عند قسم تقنية المعلومات، والسبب أن كل قسم جديد يضيف كتالوجاً وصلاحيات وأسئلة، وإذا كان الأساس مضطرباً فسوف يحكم الجميع على الفكرة كلها بالفشل. ## تجربة عملية: تذكرة من البريد وSLA يتجاوز موعده الآن سوف نرى المؤقتات والتصعيد على نظام حقيقي، وقد اخترنا Zammad 7.2.2 لأن ال SLA والتصعيد فيه مدمجان دون إضافات. وبيئة التجربة هي نفسها التي شرحنا تثبيتها في مقال المقارنة، أي Zammad على المنفذ 18080 مع Mailpit الذي يستقبل كل البريد وGreenMail الذي يحفظ صندوق الدعم الفني، فلا تخرج أي رسالة من الجهاز. والسيناريو كما يلي: موظف يرسل بريداً بأنه لا يستطيع الدخول إلى نظام الرواتب، فتصبح الرسالة تذكرة عند الدعم الأول L1، ثم يصنفها الفني كحادثة حرجة P1 لها SLA استجابة أولى مدته دقيقتان، ولا يرد أحد، فيجب أن ينقلها النظام وحده إلى الدعم الثاني L2 ويبلغ قائد الفريق. ### الخطوة الأولى: SLA وقاعدة التصعيد ال SLA التالي ينطبق على كل تذكرة أولويتها «3 high»، مع وقت استجابة أولى دقيقتين ووقت حل 30 دقيقة، والتقويم رقم 1 جعلناه يعمل 24 ساعة طوال الأسبوع بتوقيت الرياض حتى لا تتوقف المؤقتات خارج الدوام أثناء التجربة: ```json {"name":"عطل حرج P1","calendar_id":1,"first_response_time":2,"solution_time":30,"condition":{"ticket.priority_id":{"operator":"is","value":["3"]}}} ``` ```bash curl -s -X POST -H "Authorization: Token token=$ZAMMAD_TOKEN" \ -H 'Content-Type: application/json; charset=utf-8' \ --data-binary @sla.json http://127.0.0.1:18080/api/v1/slas ``` والصورة التالية تبين ال SLA في شاشة الإدارة بالواجهة العربية: ![شاشة اتفاقيات مستوى الخدمة في Zammad بالعربية فيها اتفاقية باسم عطل حرج P1 شرطها أن تكون الصلاحيات 3 عالية، وأوقات التصعيد 00:02 ساعات لوقت الاستجابة الأولى و00:30 ساعات لوقت الحل، والتقويم Asia/Riyadh 24/7، وفي القائمة الجانبية عناصر مترجمة وأخرى بالإنجليزية مثل Text Modules وMacros وWebhook](https://arabroot.io/content/images/2026/10/itsm-intro-03-zammad-sla.webp) ال SLA في Zammad، ولاحظ أن الترجمة العربية كتبت «صلاحيات» مكان الأولوية Priority أما التصعيد فهو قاعدة Trigger في Zammad، وهذه القاعدة كما استخدمناها في النهاية (وسوف نرى بعد قليل لماذا نقول «في النهاية»): ```json {"name":"تصعيد عند تجاوز SLA","active":true,"activator":"time","execution_condition_mode":"selective", "condition":{"ticket.escalation_at":{"operator":"has reached"},"ticket.priority_id":{"operator":"is","value":["3"]}}, "perform":{"ticket.group_id":{"value":"2"},"ticket.owner_id":{"pre_condition":"specific","value":"5"}, "notification.email":{"recipient":["userid_5"],"subject":"تصعيد: تجاوزت التذكرة #{ticket.number} وقت SLA","body":"التذكرة #{ticket.number} «#{ticket.title}» تجاوزت وقت الاستجابة الأولى المتفق عليه، وانتقلت إلى #{ticket.group.name}.","internal":false}}} ``` في الإعداد أعلاه لاحظ التالي: - القيمة `"activator":"time"` تجعل القاعدة تعمل على حدث زمني وليس على تعديل يقوم به شخص، والشرط `ticket.escalation_at` مع `has reached` يعني أن موعد التصعيد قد حل. - المجموعة رقم 2 هي «الدعم الثاني L2»، والمستخدم رقم 5 هو قائد الفريق، فالقاعدة تنقل التذكرة وتجعل القائد مالكها وترسل له بريداً. - القاعدة نفسها لا تعرف شيئاً عن الدقيقتين، فالمدة في ال SLA، والقاعدة تقول فقط ماذا نفعل عندما يحل الموعد، وهذا الفصل يسمح لك بتغيير المدد دون لمس منطق التصعيد. ### الخطوة الثانية: الرسالة والتصنيف والانتظار أرسلنا الرسالة من حساب الموظف عبر Mailpit إلى صندوق الدعم الفني، وبعد 11 ثانية ظهرت التذكرة 37003 عند الدعم الأول. ولقراءة حالة التذكرة وتغييرها كتبنا سكربتاً صغيراً بلغة Node.js اسمه `sla-lab.mjs` يستخدم REST API الخاص بZammad، وهو موجود في مجلد التجربة. والأمر التالي يعرض حالة التذكرة قبل التصنيف: ```bash node sla-lab.mjs show 3 ``` والمخرج سوف يكون كما يلي: ```text #37003 | new | 2 normal | الدعم الأول L1 | owner: - created 01:14:14 | first response due - | answered - | solution due - | closed - escalation_at - | first_response_diff_in_min null | close_diff_in_min null ``` لاحظ أنه لا يوجد أي موعد، لأن ال SLA لا ينطبق إلا على الأولوية العالية. الآن يصنفها الفني كحادثة P1 بعد عشر ثوان: ```bash node sla-lab.mjs p1 3 ``` ```text #37003 | new | 3 high | الدعم الأول L1 | owner: - created 01:14:14 | first response due 01:16:14 | answered - | solution due 01:44:14 | closed - escalation_at 01:16:14 | first_response_diff_in_min null | close_diff_in_min null ``` وهنا أول درس مهم: موعد الاستجابة الأولى هو 01:16:14، أي دقيقتان من إنشاء التذكرة في 01:14:14 وليس من وقت التصنيف، وهذا يتفق مع التوثيق الذي يقول إن الوقت يحسب من إنشاء التذكرة. فإذا تأخر الدعم الأول في التصنيف نصف ساعة فقد يولد ال SLA مكسوراً، ولهذا يجب أن يكون التصنيف نفسه أول عمل في التذكرة، أو أن يصنف البريد آلياً بقواعد على المرسل أو الموضوع. بعد ذلك لم يرد أحد، وانتظرنا. والصورة التالية تبين عمر التذكرة كاملاً بالأوقات الحقيقية من التجربة: ![خط زمني لتذكرة واحدة بست نقاط: 1 في 01:14:14 تحولت الرسالة إلى تذكرة، 2 في 01:14:24 صنفت P1، 3 في 01:16:14 فات موعد الاستجابة الأولى ومدته دقيقتان، 4 في 01:18:29 شغلت مهمة التصعيد فنقلت التذكرة إلى L2 وجعلت قائد الفريق مالكها وأرسلت بريداً عبر Mailpit، 5 في 01:20:43 أول رد متأخراً 4 دقائق، 6 في 01:21:05 أغلقت قبل موعد الحل ب 24 دقيقة، مع شريط وقت الحل 30 دقيقة، وفجوة دقيقتين و15 ثانية بين الموعد والتصعيد لأن المهمة تعمل كل خمس دقائق](https://arabroot.io/content/images/2026/10/itsm-intro-04-ticket-lifecycle.webp) الموعد فات في 01:16:14، والتصعيد حدث في 01:18:29 عند تشغيل مهمة التصعيد التالية والأمر التالي يعرض سجل التذكرة، أي ما تغير ومن غيره ومتى: ```bash node sla-lab.mjs history 3 ``` ```text 01:14:14 employee@it.lab created Ticket → 01:14:14 employee@it.lab created Ticket::Article → 01:14:14 employee@it.lab updated last_contact_at → 2026-10-12 22:14:14 UTC 01:14:14 employee@it.lab updated last_contact_customer_at → 2026-10-12 22:14:14 UTC 01:14:15 - created Ticket::Article → 01:14:17 - email Ticket::Article Thanks for your inquiry (لا أستطيع الدخول إلى نظام الرواتب) → employee@it.lab 01:14:18 employee@it.lab notification Ticket → admin@it.lab(create:online,email) 01:14:19 employee@it.lab notification Ticket → agent@it.lab(create:online,email) 01:14:19 employee@it.lab notification Ticket → lead@it.lab(create:online,email) 01:14:24 admin@it.lab updated priority 2 normal → 3 high 01:14:24 admin@it.lab updated first_response_escalation_at → 2026-10-12 22:16:14 UTC 01:14:24 admin@it.lab updated close_escalation_at → 2026-10-12 22:44:14 UTC 01:14:24 admin@it.lab updated escalation_at → 2026-10-12 22:16:14 UTC 01:14:28 admin@it.lab notification Ticket → agent@it.lab(update:online,email) 01:14:28 admin@it.lab notification Ticket → lead@it.lab(update:online,email) 01:18:29 - updated group الدعم الأول L1 → الدعم الثاني L2 01:18:29 - updated owner - → قائد الفريق 01:18:29 - created Ticket::Article → 01:18:33 - email Ticket::Article تصعيد: تجاوزت التذكرة 37003 وقت SLA → lead@it.lab ``` في المخرج أعلاه لاحظ التالي: - الرد الآلي «Thanks for your inquiry» خرج بعد ثلاث ثوان من إنشاء التذكرة، ولم يوقف مؤقت الاستجابة الأولى، وهذا صحيح لأن الرد الآلي ليس استجابة. - الأوقات بصيغة UTC في السجل، فالموعد 22:16:14 UTC هو 01:16:14 بتوقيت الرياض. - التصعيد حدث في 01:18:29، أي بعد الموعد بدقيقتين و15 ثانية، والسبب أن Zammad لا يراقب كل تذكرة لحظياً، وإنما يشغل مهمة باسم `Ticket.process_escalation` كل 300 ثانية كما يظهر في جدول المهام المجدولة لديه، فقد يصل التصعيد متأخراً حتى خمس دقائق، وهذا لا يهم في SLA مدته ساعات، ولكنه يهم إذا وضعت SLA بدقائق قليلة. - التصعيد لم يأت من فني، فالمستخدم فارغ «-» لأن النظام هو الذي نفذ القاعدة. والصورة التالية تبين التذكرة بعد التصعيد، وقد انتقلت إلى الدعم الثاني وأصبح قائد الفريق مالكها، وفي أعلاها «التصعيد قبل 2 الدقائق»: ![شاشة التذكرة 37003 في Zammad بالواجهة العربية بعنوان لا أستطيع الدخول إلى نظام الرواتب، وفي اللوحة الجانبية المجموعة الدعم الثاني L2 والمالك قائد الفريق والحالة جديد والأولوية 3 عالية، وتحت العنوان عبارة التصعيد قبل 2 الدقائق باللون الأحمر، وفي المحادثة رسالة الموظف ثم الرد الآلي ثم بريد التصعيد إلى lead@it.lab](https://arabroot.io/content/images/2026/10/itsm-intro-05-zammad-escalated.webp) التذكرة بعد التصعيد الآلي إلى الدعم الثاني L2 ووصل بريد التصعيد إلى قائد الفريق، وهذه صورته في واجهة Mailpit كما يلي: ![شاشة Mailpit فيها رسالة من دعم تقنية المعلومات zammad@it.lab إلى lead@it.lab عنوانها تصعيد: تجاوزت التذكرة 37003 وقت SLA، ونصها أن التذكرة تجاوزت وقت الاستجابة الأولى المتفق عليه وانتقلت إلى الدعم الثاني L2، وفي القائمة الجانبية رسائل New ticket وUpdated ticket السابقة](https://arabroot.io/content/images/2026/10/itsm-intro-06-mailpit-escalation.webp) بريد التصعيد كما وصل إلى Mailpit، ولاحظ أن إشعارات Zammad الافتراضية بقيت بالإنجليزية مثل New ticket بعد ذلك رد قائد الفريق على الموظف ثم أغلق التذكرة: ```bash node sla-lab.mjs reply 3 node sla-lab.mjs close 3 ``` ```text #37003 | closed | 3 high | الدعم الثاني L2 | owner: lead@it.lab created 01:14:14 | first response due - | answered 01:20:43 | solution due - | closed 01:21:05 escalation_at - | first_response_diff_in_min -4 | close_diff_in_min 24 ``` والقيمة `first_response_diff_in_min -4` تعني أن الرد الأول جاء بعد موعده بأربع دقائق، أي أن ال SLA كسر وسوف يظهر في التقارير كذلك حتى لو أغلقت التذكرة بسرعة بعده، أما `close_diff_in_min 24` فتعني أن الحل جاء قبل موعده بأربع وعشرين دقيقة. وهذا هو الفرق بين المؤقتين: يمكن أن تفي بوعد الحل وتكسر وعد الاستجابة في التذكرة نفسها، والموظف يشعر بالثاني أكثر من الأول. ### اكسرها: قاعدة لا تعمل أبداً، ومالك لا يمكن تعيينه في المحاولة الأولى على تذكرة سابقة رقمها 37002 كتبنا قاعدة التصعيد بالطريقة التي تبدو منطقية، أي قاعدة تعمل عند الإجراء Action وشرطها أن قيمة الإجراء هي escalation كما يلي: ```json "activator":"action", "condition":{"ticket.action":{"operator":"is","value":"escalation"}, …} ``` وبعد تسع دقائق من الموعد كان المخرج كما يلي: ```text 01:03:41 #37002 | new | 3 high | الدعم الأول L1 | owner: - created 00:52:36 | first response due 00:54:36 | answered - | solution due 01:22:36 | closed - escalation_at 00:54:36 | first_response_diff_in_min null | close_diff_in_min null ``` مهمة التصعيد عملت أكثر من مرة في سجل الجدولة، ولكن التذكرة بقيت في الدعم الأول دون أي خطأ ظاهر، والسبب أن Zammad يرسل حدث التصعيد إلى القواعد الزمنية فقط، أي القواعد التي قيمتها `"activator":"time"`، ويتحقق منها بالشرط `has reached` على `ticket.escalation_at`، أما قواعد الإجراء فلا تراه أبداً. وهذا أخطر نوع من الأخطاء، لأن الإعداد مقبول ويحفظ دون اعتراض، والفريق يظن أن التصعيد يعمل حتى يأتي يوم الأزمة. والدرس أن تختبر كل قاعدة تصعيد بتذكرة حقيقية ومدة قصيرة قبل الاعتماد عليها، كما فعلنا هنا. وبعد إصلاح القاعدة ظهر الخطأ الثاني، فقد نقلت التذكرة 37002 إلى L2 ولكن الأمر `show` أعاد هذا الخطأ: ```text Error: GET /tickets/2?expand=true → 403 {"error":"Not authorized","error_human":"Not authorized"} ``` والسجل بعد إصلاح الصلاحيات أظهر أن المجموعة تغيرت ولكن المالك لم يتغير: ```text 01:08:27 - updated group الدعم الأول L1 → الدعم الثاني L2 01:08:28 - created Ticket::Article → 01:08:32 - email Ticket::Article تصعيد: تجاوزت التذكرة 37002 وقت SLA → lead@it.lab ``` والسبب أننا أنشأنا مجموعة الدعم الثاني L2 بعد أن أعطينا الفنيين صلاحياتهم، فلم يكن لأحد منهم، ولا لقائد الفريق، أي صلاحية عليها، فاختفت التذكرة من شاشة المدير الذي يستخدم السكربت، وبقي حقل المالك فارغاً، والأرجح أن Zammad لم يقبل تعيين مالك لا يملك صلاحية على المجموعة، فوصل البريد إلى قائد الفريق وهو لا يستطيع فتح التذكرة. وعندما أعطينا الفنيين صلاحية على L2 وكررنا التجربة على التذكرة 37003 تعين المالك كما رأينا في السجل أعلاه. والقاعدة هنا أن فريق التصعيد يحتاج صلاحية على مجموعة التصعيد قبل أن تحتاجها، وأن تختبر التصعيد بحساب الشخص الذي سيستلمه وليس بحساب المدير. ## كيف يبدأ فريق صغير؟ لنفرض أن لديك قسماً من ثلاثة أشخاص يخدم مئة وخمسين موظفاً، والطلبات اليوم في واتساب والبريد الشخصي، فهذه خطة عملية من أربع مراحل: 1. **الأسبوعان الأولان:** نظام تذاكر واحد وعنوان بريد واحد مثل helpdesk@، وتعلن للموظفين أن أي طلب خارجه لا يعتبر طلباً، ثم نوعان فقط من السجلات: الحادثة Incident وطلب الخدمة Service Request، وأولويتان أو ثلاث. 2. **الشهر الأول:** SLA واحد بسيط بأوقات الدوام، مثل استجابة خلال ساعتين للأولوية العالية ويوم عمل لغيرها، مع تصعيد آلي إلى قائد الفريق، ثم ربط الدخول بنظام الهوية كما في [إدارة الأدوار عبر تطبيقاتك من 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/) حتى لا يكون للنظام حسابات منفصلة. 3. **الشهر الثاني والثالث:** كتالوج من خمسة إلى عشرة بنود هي الأكثر تكراراً، وعشرة مقالات في قاعدة المعرفة لأكثر الأسئلة، وسجل أصول للحواسيب والتراخيص. 4. **بعد ذلك:** فتح المشكلات Problem للحوادث المتكررة، وتسجيل التغييرات Change على الأنظمة الحرجة، ثم العلاقات في قاعدة بيانات الإعدادات CMDB للخدمات المهمة فقط، ومراجعة شهرية للمقاييس مع عينة من التذاكر. وإذا كان الفريق يحتاج إلى مساعدة الموظف على جهازه عن بعد أثناء التذكرة، فقد قارنا أدوات الدعم عن بعد في [أدوات الوصول الآمن إلى السيرفرات](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). ## أخطاء شائعة - تسجيل كل شيء كحادثة Incident، فيصبح متوسط وقت الحل رقماً يخلط طلبات الشراء بالأعطال الحرجة. - قاعدة تصعيد لم تختبر بتذكرة حقيقية، وقد رأينا في التجربة قاعدة تحفظ دون خطأ ولا تعمل أبداً. - مجموعة تصعيد لا يملك أعضاؤها صلاحية عليها، فيصل البريد ولا تفتح التذكرة. - تصنيف الأولوية متأخراً، والمؤقت يعمل منذ إنشاء التذكرة. - تقويم ساعات العمل لا يطابق الدوام الفعلي أو العطل الرسمية، فتظهر تذاكر مكسورة في يوم إجازة أو تتوقف المؤقتات في يوم عمل. - مكافأة الفريق على FCR أو على نسبة الالتزام بال SLA وحدهما، فيتعلم الفريق إغلاق التذاكر بدل حلها. - بناء قاعدة بيانات الإعدادات CMDB كاملة يدوياً في البداية، ثم تركها حتى تصبح خاطئة. - لجنة CAB لكل تغيير صغير، فيبدأ الفريق بعمل التغييرات دون تسجيلها. ## الخلاصة - الحادثة Incident تعيد الخدمة، والمشكلة Problem تبحث عن السبب، والتغيير Change يعدل بأمان، وطلب الخدمة Service Request ليس عطلاً، ولكل منها مسار ومقياس. - ال SLA وعد للمستخدم، وال OLA وعد بين فرقك، والتصعيد يجب أن يكون آلياً ومرتبطاً بالمؤقت. - إدارة الأصول Asset Management تسأل كم وأين ومع من، وقاعدة بيانات الإعدادات CMDB تسأل ماذا يتأثر، وابدأ بالأصول. - إطار ITIL ملك PeopleCert منذ استحواذها على Axelos في 2021، وصدر ITIL (Version 5) في 2026، والمفيد لفريق صغير ست ممارسات والمبادئ التوجيهية، خصوصاً «ابدأ من حيث أنت» و«اجعلها بسيطة». - المتوسط يخفي الحالات الطويلة، وFCR وCSAT ونسبة الالتزام بال SLA تخدع إذا كوفئ الفريق عليها وحدها. - في التجربة بدأ مؤقت الاستجابة من إنشاء التذكرة وليس من تصنيفها، وحدث التصعيد بعد الموعد بدقيقتين و15 ثانية لأن مهمة التصعيد في Zammad تعمل كل خمس دقائق، وقاعدة التصعيد المبنية على الإجراء لم تعمل أبداً دون أي خطأ. وفي المقال التالي سوف نقارن أنظمة التذاكر المفتوحة المصدر بتراخيصها وأجزائها المدفوعة ودعمها للعربية، مع تجربة البريد وال SLA على ثلاثة منها: [![](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/outline-cover-cover.webp)دليلOutline: قاعدة معرفة فريقك على سيرفرككيف تشغل Outline على سيرفرك ليكتب فيه فريقك إجراءاته وقراراته، ويدخل إليه الموظفون بحساباتهم في authentik.](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-outline-%D9%84%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-%D9%85%D8%B9%D8%B1%D9%81%D8%A9-%D8%A7%D9%84%D9%81%D8%B1%D9%8A%D9%82/)[![](https://arabroot.io/content/images/2026/10/bookstack-cover-cover.webp)دليلBookStack: توثيق فريقك في كتب وفصول على سيرفرككيف تشغل BookStack على سيرفرك وتنظم توثيق فريقك في أرفف وكتب وفصول، مع صلاحيات ودخول موحد وبحث بالعربية.](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-bookstack-%D9%84%D8%AA%D9%88%D8%AB%D9%8A%D9%82-%D8%A7%D9%84%D9%81%D8%B1%D9%8A%D9%82/)[![](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/) ## سجل التحديثات - أكتوبر 2026: كتابة المقال مع تجربة حقيقية على Zammad 7.2.2 (ghcr.io/zammad/zammad:7.2.2-0003) مع PostgreSQL 17.11 وRedis 8.10.2 وMemcached 1.6.45 وMailpit 1.31.5 وGreenMail 2.1.14 على Docker Engine 29.8.0، ومعلومات ITIL من صفحات PeopleCert كما هي في 13 أكتوبر 2026. - أكتوبر 2026: تقسيم فقرة ITIL إلى قوائم وجدول، وإضافة صورة المبادئ التوجيهية السبعة.