التنفيذ وطابور العمل

تتعامل Operational Health Matrix مع معالجة المشكلات التشغيلية بوصفها عمليةً مُدارةً، لا مجموعةً من المهامّ المستقلّة.

بعد إنشاء Operational Issue، يبني النظام سياق العمل تلقائياً، ويحدّد منطقة المسؤولية التشغيلية، ويطبّق سياسة الـ SLA المقابلة، ثم يضع الكائن في طابور التنفيذ.

وبهذا تتحقّق دورة متّصلة لإدارة الأعمال، من لحظة اكتشاف المشكلة وحتى التأكّد من استعادة الحالة الطبيعية للمعدّات.

نموذج التنفيذ

يمرّ كلّ Operational Issue بدورة تنفيذ واحدة.

flowchart TD
  A["الاكتشاف"] --> B["Operational Issue"]
  B --> C["الملكية التشغيلية"]
  C --> D["التخطيط"]
  D --> E["التنفيذ"]
  E --> F["التحقّق"]
  F --> G["الإغلاق"]
  G --> H["التحسين المستمرّ"]

ويُسجّل النظام في كلّ مرحلة:

• المسؤول؛
• المواعيد النهائية؛
• الحالة؛
• سجلّ التغييرات؛
• Evidence؛
• المهامّ المرتبطة؛
• مقالات Knowledge Base المطبَّقة؛
• نتائج التحقّق.

الملكية التشغيلية (Operational Ownership)

تُحدَّد المسؤولية بالمنطقة التشغيلية، لا بالمستخدم.

مثال:

وبعد تحديد المنطقة، يُسنِد النظام العمل إلى مهندس بعينه بناءً على:

• الكفاءة؛
• حِمل العمل؛
• الإقليم؛
• جدول العمل؛
• الـ backlog الحالي؛
• مستوى التصريح.

وعند الحاجة، يستطيع المدير تغيير الإسناد يدوياً.

طابور العمل

طابور العمل عرضٌ ديناميكي لـ Operational Issues النشطة.

وخلافاً لقائمة المهامّ التقليدية، يُبنى الطابور على مجموعة من العوامل:

• الأولوية (Priority)؛
• الخطورة (Severity)؛
• الثقة التشغيلية (Operational Confidence)؛
• الوقت المتبقّي من الـ SLA؛
• الأثر على الأعمال (Business Impact)؛
• عدد الأصول المتأثّرة؛
• عدد مرّات إعادة الفتح (Reopen Count)؛
• الثقة في الـ Root Cause.

وافتراضياً ترتفع الكائنات الأشدّ حرجاً إلى الأعلى تلقائياً، بصرف النظر عن وقت الإنشاء.

فئات الطوابير

يدعم OHM عدّة طوابير متخصّصة.

الواردة (Incoming)

مشكلات جديدة تنتظر الفرز (triage).

المُسنَدة (Assigned)

مشكلات أُسنِدت إلى مهندس.

قيد التنفيذ (In Progress)

أعمال جارية حالياً.

بانتظار التحقّق (Awaiting Verification)

أعمال اكتملت وتنتظر التأكيد.

المتأخّرة (Overdue)

جرت مخالفة متطلّبات الـ SLA.

المُصعَّدة (Escalated)

مشكلات جرى تصعيدها تلقائياً.

المُعاد فتحها (Reopened)

مشكلات عاودت الظهور بعد الإغلاق.

الحوادث الجماعية (Massive Incidents)

حوادث تشغيلية على مستوى النظام.

ترتيب أولويات الطابور

يستخدم النظام أولوية إجمالية للترتيب.

مثال:

حيث

• P — الأولوية (Priority)؛
• S — الخطورة (Severity)؛
• B — الأثر على الأعمال (Business Impact)؛
• C — الثقة التشغيلية (Operational Confidence)؛
• T — الوقت المتبقّي من الـ SLA.

ويُستخدَم المؤشّر الناتج لترتيب الطابور حصراً، ولا يغيّر قيمة Priority الرسمية للكائن.

العمليات الجماعية

يدعم OHM تنفيذ عمليات جماعية على مجموعة من Operational Issues.

مثال:

• تغيير المالك؛
• تغيير المنطقة؛
• تغيير الـ SLA؛
• إسناد Root Cause مشترك؛
• الدمج في Massive Incident؛
• تطبيق Knowledge Article؛
• تغيير الأولوية؛
• التصدير.

وتُسجَّل جميع الإجراءات الجماعية في الـ Audit Trail.

مراعاة السعة (Capacity)

يُراعى عند إسناد الأعمال حِمل العمل الفعلي على الأقسام.

ويوصَف كلّ مهندس بما يلي:

• Active Issues؛
• Verification Queue؛
• Planned Work؛
• Availability؛
• Current Capacity.

وإذا تجاوز الحِمل الحدّ المقرَّر، يوصي النظام بإعادة توزيع الأعمال.

توزيع حِمل العمل

يستخدم النظام الموازنة لمنع فرط التحميل.

ويُراعى في التوزيع:

• عدد Issues المفتوحة؛
• إجمالي درجة الحرجية؛
• متوسّط زمن الحلّ؛
• الكفاءات؛
• التبعية الجغرافية؛
• سجلّ تنفيذ أعمال مماثلة.

التنفيذ عبر الهاتف المحمول

توفّر النسخة الميدانية من OHM للمهندس:

• بطاقة الأصل؛
• المسار؛
• السجلّ التاريخي؛
• أحدث Evidence؛
• الصور المرتبطة؛
• التعليمات؛
• Knowledge Articles؛
• إمكانية إرفاق موادّ جديدة؛
• التوقيع الإلكتروني؛
• تأكيد إنجاز العمل.

وبعد المزامنة تصبح المعلومات متاحةً فوراً للمُرسِل (dispatcher).