ليه الموضوع ده مهم لصاحب الشركة؟
الشهادات والمصطلحات مفيدة فقط حين تتحول لسلوك قابل للقياس. الشركة الصغيرة تقدر تبدأ بممارسة واحدة واضحة، وتطورها مع نمو المخاطر والعمل.
أي قرار في التشغيل أو التكنولوجيا لازم يجاوب عن ثلاثة أسئلة: ما المشكلة التي نحلها؟ من المسؤول عن النتيجة؟ وكيف سنعرف أن الوضع اتحسن؟ لو إجابة واحدة مش واضحة، يبقى من الأفضل نوقف الشراء أو التنفيذ لحين تحديدها. وده مش تعطيل؛ ده تقليل لتكلفة إعادة الشغل.
المشكلة الحقيقية مش دايمًا اللي باين
طلبات التقنية كثيرًا ما تصل في الرسائل الشخصية وتضيع الأولوية والملكية. حل المشكلة يبدأ بتعريف الخدمة وطرق الطلب ثم اختيار Helpdesk مناسب.
من العلامات المبكرة إن الفريق يعتمد على شخص واحد للرد على الأسئلة المتكررة، أو أن الملفات والقرارات موزعة على محادثات متعددة، أو أن الإدارة لا تقدر تفرّق بين التأخير الاستثنائي والتأخير المتكرر. اكتب مثالًا حقيقيًا من أسبوع العمل الحالي، ثم تتبع السبب خطوة بخطوة قبل أن تختار الحل.
القرار الذي ينبغي حسمه
فرّق بين Incident يعطل خدمة قائمة وService Request يطلب شيئًا معتادًا. اعرف الخدمات الأساسية ومن يملكها وكيف يتم التصعيد.
خلي كل ممارسة لها مالك، سجل بسيط، موعد مراجعة، ومعيار لمعرفة نجاحها. المستند الذي لا يقرأه أحد مش نظام جودة.
لتحويل الكلام إلى قرار تنفيذي، وثّق الافتراضات والبدائل: ماذا سيحدث لو لم نفعل شيئًا لمدة ثلاثة أشهر؟ وما أبسط تعديل يمكن اختباره دون التزام مالي كبير؟ ومن سيعطي الموافقة النهائية؟ احتفظ بالقرار في مكان يعرفه الفريق.
مصدر الصورة: Pexels.

مرتبط بهذه الفكرة: النسخ الاحتياطي مش كفاية: هل جرّبت ترجع بيانات شركتك؟
أربع ممارسات ITIL 4 تبدأ بها
لا تحتاج منصة ITSM كبيرة من اليوم الأول. يكفي سجل تذاكر بسيط يحدد رقم الطلب، الأولوية، المالك، وقت الاستجابة والحل، وسبب التكرار.
- Service Desk: قناة واضحة لاستقبال الطلبات ومتابعتها.
- Incident Management: إعادة الخدمة بسرعة عند حدوث عطل.
- Service Request Management: تنفيذ طلب عادي مثل إنشاء حساب أو صلاحية.
- Change Enablement: تقييم أثر التغيير قبل تنفيذه على الأنظمة الحيوية.
- 01ليه الموضوع ده مهم لصاحب الشركة؟
- 02القرار الذي ينبغي حسمه
- 03خطة تنفيذ واقعية
خطة تنفيذ واقعية
لا تنقل كل الشركة مرة واحدة إلى طريقة جديدة. نفّذ على نطاق صغير فيه عدد محدود من الأشخاص والحالات، ثم اجمع الملاحظات. لو اكتشفت استثناءات كثيرة، غالبًا الخطة لم تصف العمل الحقيقي بما يكفي.
- الخطوة 1: اكتب Service Catalog من 5 إلى 10 خدمات يفهمها الموظفون.
- الخطوة 2: حدد قناتين كحد أقصى لاستقبال الطلبات، واجعل حالة كل طلب ظاهرة.
- الخطوة 3: عرّف أولويات بسيطة بناء على الأثر والاستعجال مع أهداف استجابة واقعية.
- الخطوة 4: راجع أسباب التذاكر المتكررة وحول الحلول المعتمدة إلى Knowledge Base.
مثال من واقع الأعمال — للتوضيح فقط
مكتب متوسط يرسل فيه الموظفون أعطال البريد على WhatsApp لثلاثة أفراد. توحيد نقطة الاستقبال مع قاعدة أولويات قد يقلل تكرار السؤال ويجعل المسؤول واضحًا؛ السيناريو افتراضي.
الفكرة هنا ليست نسخ المثال بحذافيره. خذ نفس السؤال إلى شركتك: أين تتعطل العملية؟ من يتأثر؟ ما البيانات التي تثبت التأخير؟ وما القرار الذي يستطيع المسؤول اتخاذه قبل الرجوع إلى الإدارة؟
راجع قبل اتخاذ القرار
- Service Desk: قناة واضحة لاستقبال الطلبات ومتابعتها.
- Incident Management: إعادة الخدمة بسرعة عند حدوث عطل.
- Service Request Management: تنفيذ طلب عادي مثل إنشاء حساب أو صلاحية.
- Change Enablement: تقييم أثر التغيير قبل تنفيذه على الأنظمة الحيوية.
أخطاء نراها كثيرًا
راجع العملية بعد أول شهر: هل فعلاً انخفضت الأخطاء؟ هل الموظفون يعرفون أين يبلّغون عن مشكلة؟ وهل الإدارة تتخذ إجراءً؟
مؤشرات بسيطة تراقبها
زمن الاستجابة، تكرار الأعطال، عمر الطلبات المفتوحة، ورضا المستخدم بعد الحل.
حدد خط أساس قبل التغيير، حتى لو أسبوعين فقط، ثم راجع نفس المؤشرات بعد التطبيق. لا تضع هدفًا رقميًا اعتباطيًا؛ ابدأ بتحسن واضح ومستقر، وراجع الشكاوى والاستثناءات بجوار الأرقام.
قائمة فحص لصاحب الشركة
ابدأ بأربع ممارسات، مش مشروع توثيق ضخم
قس تكرار الأعطال وزمن الاستعادة والطلبات المتأخرة، ولا تخلط بين طلب خدمة روتيني وحادث يوقف العمل. هذه الممارسات جزء من نطاق ITIL 4؛ تطبيقها لا يتطلب فريقًا كبيرًا أو شهادة قبل البدء. PeopleCert: ممارسات ITIL 4.
الخطوة التالية
اختار عملية واحدة أو قرارًا واحدًا يستهلك وقتك كل أسبوع. اكتب كيف يحدث اليوم، وماذا تتمنى أن يحدث بدلًا منه، ومَن سيملك الخطوة التالية. هذه نقطة بداية أقوى من قائمة برامج طويلة. وإذا احتجت رؤية محايدة لتصميم التشغيل والبنية الرقمية، يمكن مناقشتها في جلسة مراجعة هيكل الأعمال لدى ORVEAX.
- شراء أداة قبل الاتفاق على طريقة العمل والأدوار.
- اعتبار وجود ملف سياسة أو قائمة مهام دليلًا على أن النظام يعمل.
- تجاهل تدريب الموظفين ونقل المسؤولية عند خروج أحدهم.
- قياس عدد المهام المكتملة فقط، وتجاهل الجودة وإعادة العمل وزمن الانتظار.
- هل المشكلة محددة بجملة واحدة مفهومة؟
- هل صاحب القرار والمسؤول عن التنفيذ معروفان؟
- هل يوجد مستند أو إجراء قصير يرجع له الفريق؟
- هل سنختبر التغيير على نطاق محدود؟
- هل حددنا موعدًا لمراجعة النتيجة وما سنفعله عند الإخفاق؟
- طلبات الخدمة: قناة واحدة لطلبات الحسابات والصلاحيات والدعم المعتاد، مع مسؤول وزمن استجابة متوقع.
- الحوادث: سجل العطل وتأثيره ومن يقود استعادة الخدمة أولًا.
- مكتب الخدمة: نقطة تواصل واضحة تمنع ضياع الطلب بين الفرق.
- التحسين المستمر: اجتماع قصير كل أسبوعين لاختيار سبب متكرر وإزالته.
