يمنح نموذج اتفاقية مستوى الخدمة لمكتب الخدمة تقنيةَ المعلومات والأعمال هيكلاً لاتفاقية مكتوبة، في عشرة أقسام بالحقول المطلوب تعبئتها. وتحدد الاتفاقية المكتملة الخدمات المدعومة، ومتى يتوفر الدعم، وسرعة استجابة تقنية المعلومات وحلّها حسب الأولوية، وكيف تُرفع النتائج. وكل هدف في المثال أدناه قيمة افتراضية تستبدلها منشأتك، لا معيار في القطاع.
احسم ثلاثة أمور قبل تعبئة النموذج
هذا نموذج اتفاقية مستوى خدمة يمكن لفرق تقنية المعلومات تكييفه لمكتب خدمة داخلي، وثلاثة قرارات تشكّل كل أقسامه. وإن كانت مصطلحات مثل الحادث والطلب والتغيير غير مألوفة، فـالدليل المبسّط لإدارة خدمات تقنية المعلومات يعرّفها.
- بين من تُعقد الاتفاقية. حدد العميل (المنشأة كلها أو وحدات أعمال محددة) والمزود (إدارة تقنية المعلومات وأي موردين يعتمد عليهم عملها)، وحدد موقّعاً لكل طرف.
- الخدمات المشمولة. اسردها بأسمائها، ويُفضّل من دليل الخدمات لديك، ووضّح ما هو خارج النطاق حتى لا تتحول الفجوة إلى نزاع لاحقاً.
- ما تستطيع تقنية المعلومات تقديمه اليوم. ابنِ المسودة الأولى على بيانات طلبات فعلية لبضعة أسابيع. وإن لم تتوفر، فاعتبر كل الأهداف مؤقتة وحدد موعد مراجعة بعد أول فترة تقارير كاملة.
يجب أيضاً أن تكون الأهداف مدعومة خلف الكواليس، وهنا يهم الفرق بين اتفاقية مستوى الخدمة (SLA) واتفاقية مستوى التشغيل (OLA). فاتفاقية مستوى الخدمة التزام تقنية المعلومات تجاه الأعمال، وإن نفّذ فريق تقني آخر أو مورّد خارجي جزءاً من العمل، فيجب أن تكون التزاماته تجاه مكتب الخدمة، المحددة في اتفاقية مستوى تشغيل أو عقد مورّد، بسرعة الهدف الذي تدعمه على الأقل. فهدف الحل خلال أربع ساعات غير قابل للتصديق حين لا يلتزم المورّد الذي يصلح العطل إلا باليوم التالي. ويسجّل القسم 8 من النموذج اتفاقية مستوى التشغيل أو عقد المورّد خلف كل هدف.
تصوغ ممارسة إدارة مستوى الخدمة في ITIL 4 المهمة بأنها وضع أهداف واضحة مبنية على الأعمال لمنفعة الخدمة وضمانها وتجربتها، أي ما تفعله الخدمة، ومدى موثوقيتها، وكيف يشعر المستخدم عند استخدامها. وبعبارة بسيطة، يجب أن يأتي كل هدف في النموذج مما تحتاجه الأعمال من كل خدمة، لا مما يسهل على تقنية المعلومات قياسه.
النموذج في لمحة
انسخ هذا الجدول هيكلاً لنموذجك وأكمل العمود الأيسر لكل قسم.
| القسم | الحقول المطلوب تعبئتها |
|---|---|
| 1. ضبط الوثيقة | الإصدار، التاريخ، مالك الوثيقة، المعتمد، تاريخ المراجعة، سجل التغييرات |
| 2. الأطراف والغرض | المزود وأي موردين داعمين؛ العميل أو وحدات الأعمال؛ موقّع لكل طرف؛ الغرض في جملتين |
| 3. الخدمات المشمولة | اسم الخدمة ووصفها؛ مالك الخدمة؛ المستخدمون والمواقع المدعومة؛ رابط دليل الخدمات؛ البنود المستثناة صراحة |
| 4. ساعات الخدمة وقنواتها | ساعات الدعم لكل خدمة؛ تقويم العمل المعتمد، بما في ذلك العطل الرسمية وأي ساعات مخفّضة في رمضان تنطبق على منشأتك؛ القنوات (البوابة، البريد، الهاتف، المحادثة)؛ لغات الدعم؛ ترتيبات خارج أوقات العمل للأولوية القصوى |
| 5. تعريفات الأولوية | مستويات الأثر؛ مستويات الإلحاح؛ مصفوفة الأولويات؛ مثالان أو ثلاثة أمثلة حقيقية لكل أولوية من خدماتك |
| 6. أهداف الخدمة | لكل أولوية: الاستجابة الأولى وفترة التحديث وزمن الحل أو الحل المؤقت؛ ولكل نوع طلب: زمن التنفيذ؛ نسبة التحقيق المطلوبة |
| 7. قواعد القياس | متى يبدأ الاحتساب ومتى يتوقف؛ متى يُعلَّق؛ أي الساعات تُحتسب؛ كيف تُعامل الطلبات المعاد فتحها؛ مصدر البيانات |
| 8. المسؤوليات | ما يقوم به مكتب الخدمة؛ ما يجب أن يقدمه المستخدمون؛ ملاك الخدمات؛ اتفاقية مستوى التشغيل أو عقد المورّد خلف كل هدف |
| 9. التصعيد والاستثناءات | مسار التصعيد بأدوار وجهات اتصال محددة؛ نوافذ الصيانة المخططة؛ الأحداث الخارجة عن سيطرة تقنية المعلومات؛ كيفية رفع النزاعات |
| 10. التقارير والمراجعة | محتوى التقرير ودوريته وجمهوره؛ اجتماع المراجعة؛ كيفية معالجة الإخلالات؛ أي تعويضات أو معالجات متفق عليها؛ موعد المراجعة التالية |
مصفوفة الأولويات وأهداف الخدمة (القسمان 5 و6)
تُشتق الأولوية عادةً من مدخلين: الأثر، أي عدد الأشخاص المتأثرين أو أهمية الخدمة المتأثرة، والإلحاح، أي مدى سرعة حاجة الأعمال إلى عودة الخدمة. قيّم كلاً منهما على بضعة مستويات، وضعهما على شبكة، واقرأ الأولوية. فعملية إدارة الحوادث المنشورة لدى جامعة مينيسوتا مثلاً تقيّم الأثر والإلحاح على أربعة مستويات لكل منهما وتربطهما بأربع أولويات. أبقِ عدد الأولويات قليلاً، فأربع تكفي معظم مكاتب الخدمة للتمييز بين الانقطاع وسؤال الاستخدام.
مثال توضيحي فقط. القيم أدناه افتراضية توضح شكل القسم 6 في النموذج، وليست معايير مرجعية. استبدل كلاً منها بهدف يستطيع مكتب خدمتك تحقيقه وتوافق عليه الأعمال.
| الأولوية | وصف مثالي | الاستجابة الأولى (مثال) | فترة التحديث (مثال) | الحل أو الحل المؤقت (مثال) |
|---|---|---|---|---|
| P1 حرجة | خدمة حرجة غير متاحة لكثير من المستخدمين، مثل نظام الرواتب في يوم صرف الرواتب | 15 دقيقة | كل 30 دقيقة | 4 ساعات على مدار الساعة |
| P2 عالية | خدمة متدهورة لإدارة كاملة، أو مستخدم رئيسي لا يستطيع العمل ولا يوجد حل مؤقت | ساعة واحدة | كل ساعتين | يوم عمل واحد |
| P3 متوسطة | مستخدم واحد أو مجموعة صغيرة متأثرة ويوجد حل مؤقت | 4 ساعات عمل | يومياً | 3 أيام عمل |
| P4 منخفضة | عطل بسيط أو سؤال عن طريقة الاستخدام | يوم عمل واحد | عند الطلب | 5 أيام عمل |
| طلب قياسي | طلب محدد مسبقاً مثل حساب جديد | الإقرار خلال يوم عمل واحد | لا ينطبق | 5 أيام عمل |
أضف نسبة تحقيق لكل هدف، مثل “يتحقق في [90]% من الطلبات على الأقل خلال الشهر”. فالنموذج الذي يخلو منها يجعل المستخدمين يقرؤون كل هدف وعداً لكل طلب، ويبدو أي طلب متأخر إخلالاً.
تُظهر الاتفاقيات المنشورة مدى تفاوت الصيغة. فعملية إدارة الحوادث لدى جامعة مينيسوتا تحدد استجابة خلال 15 دقيقة وحلاً خلال 4 ساعات للأولوية القصوى على مدار الساعة، وتحتسب أزمنة الحل من P2 إلى P4 بساعات العمل فقط مع استبعاد وقت الانتظار. واتفاقية UCSF IT تستخدم أيضاً 15 دقيقة و4 ساعات لـ P1، لكنها تصوغ الحل بأنه 80% من الطلبات في أقل من 4 ساعات، وتجعل P3 استجابة خلال ساعتي عمل مع حل 80% في أقل من 3 أيام عمل. وكلتاهما لمنشأة واحدة بخدماتها ومستخدميها وميزانيتها، فاستخدمهما لرؤية صياغة الاتفاقية قبل تكييف النموذج، لا لاختيار أرقامك.
قواعد القياس (القسم 7)
يحتوي القسم 7 من النموذج على هذه القواعد. اكتبها، وإلا قد ينجح الطلب نفسه أو يفشل حسب من يحسبه.
- بدء الاحتساب. قرر إن كان الاحتساب يبدأ عند تسجيل الطلب أو عند أول إقرار به، وتأكد أن كل قناة تنشئ الطلب في اللحظة نفسها.
- التعليق. وضّح إن كان وقت انتظار المستخدم يوقف الاحتساب، واشترط أن يحمل الطلب حالة تُظهر ذلك.
- الساعات. حدد التقويم الذي ينطبق على كل أولوية، ليكون لطلب P3 مرفوع في وقت متأخر من يوم الخميس جواب متفق عليه.
- التحقيق. قرر إن كان الهدف سقفاً لكل طلب أم نسبة من الطلبات، كما في صياغة UCSF أعلاه.
- الطلبات المعاد فتحها. وضّح إن كان الطلب المعاد فتحه يكمل الاحتساب الأصلي أم يبدأ احتساباً جديداً.
ما يجب أن يتضمنه التقرير الشهري (القسم 10)
يغطي القسم 10 من النموذج التقارير، وفيه تثبت الاتفاقية قيمتها. ويجب أن تكون التقارير قصيرة بما يكفي لتقرأها الإدارة في دقائق، بالتنسيق نفسه كل شهر لتظهر الاتجاهات.
- الطلبات المفتوحة والمغلقة حسب الأولوية والخدمة.
- نسبة التحقيق مقابل كل هدف، مع سرد كل إخلال وسببه.
- الطلبات المتراكمة المفتوحة وعمرها.
- الحوادث المتكررة وسجلات المشكلات المفتوحة لإزالتها.
- الطلبات المعاد فتحها وردود رضا المستخدمين.
- التغييرات المنفذة في الفترة، وأي منها تسبب في حادث.
- الإجراءات المتفق عليها في المراجعة الأخيرة وما إذا نُفذت.
ضع مصدر البيانات وتاريخ استخراجها في أسفل التقرير ليمكن التحقق من الأرقام، وأرسل التقرير إلى من وقّعوا الاتفاقية. فالاتفاقية التي لا تُرفع تقاريرها إلا داخل تقنية المعلومات ليست اتفاقاً مع أحد.
أخطاء تجعل الاتفاقية غير قابلة للاستخدام
- أرقام منسوخة. إن نسخت أهداف منشأة أخرى في نموذجك، فهي تعكس خدماتها وموظفيها وعقودها لا خدماتك.
- قياس الاستجابة الأولى فقط. الإقرار السريع بطلب يبقى مفتوحاً أسبوعاً يحقق الصياغة ويخذل المستخدم.
- غياب قاعدة التعليق. ترك معاملة وقت الانتظار دون تحديد يستدعي الجدل في كل مراجعة.
- غياب موعد المراجعة. الأهداف التي وُضعت قبل توفر أي بيانات يجب مراجعتها حين تتوفر.
إن أردت كتابة الاتفاقية مع الأعمال ودعمها باتفاقيات داخلية تجعلها قابلة للتحقيق، فإن وسنا للحلول الرقمية تغطي تحديد اتفاقيات مستوى الخدمة وتقاريرها ضمن خدمة إدارة خدمات تقنية المعلومات.
احصل على مراجعة لمسودة اتفاقيتك
شاركنا تصنيفات الطلبات الحالية وساعات الدعم والتقارير التي تطلبها الإدارة، وسنخبرك بأقسام النموذج التي تحتاج إلى أكبر قدر من العمل.
اطلب مراجعة للاتفاقيةالمصادر
- ITIL 4 Practitioner: Service Level Management، PeopleCert. تاريخ الاطلاع: 2 أكتوبر 2026.
- IT Service Management, Incident Process، مكتب تقنية المعلومات بجامعة مينيسوتا (صفحة غير مؤرخة). تاريخ الاطلاع: 2 أكتوبر 2026.
- IT Enterprise Service Level Agreement (SLA)، UCSF IT (صفحة غير مؤرخة). تاريخ الاطلاع: 2 أكتوبر 2026.
