كيف تبني نظام تشغيل مؤسسي أكثر كفاءة؟

قبل فتح أي برنامج أو التفكير في الشاشات، يحتاج من يبني نظام تشغيل مؤسسي إلى إجابات عن ثلاثة أسئلة: ما البيانات التي يستحق الأمر تسجيلها؟ من يملك كل خطوة في العملية؟ وكيف تتحرك الحالة من بدايتها حتى إغلاقها؟ الترتيب هنا مهم: هذه القرارات يجب أن تُتخذ قبل التهيئة التقنية، لأن أي إعداد لاحق سيبني فوق افتراضات خاطئة إذا لم تُحسم هذه الأسئلة أولًا.
اختيار البيانات التي تستحق التسجيل
الميل الشائع عند البناء هو إضافة كل حقل يمكن تخيله “احتياطًا”. النتيجة شاشة إدخال طويلة يتجنبها المستخدمون أو يملؤونها بشكل عشوائي لإنهائها بسرعة. المعيار الأفضل هو أن يُسأل عن كل حقل: هل سيُستخدم هذا الحقل لاحقًا في قرار أو تقرير أو تنبيه؟ إذا كانت الإجابة لا، فالحقل عبء وليس قيمة. الحقول التي تستحق الوجود عادة قليلة: من نفّذ الإجراء، متى، أين (الموقع أو المركز)، ما تصنيفه، وما حالته الحالية. أي حقل إضافي يجب أن يبرر نفسه بوضوح.
من المفيد أيضًا التفريق بين البيانات التشغيلية اللازمة لإنجاز المهمة، والبيانات التحليلية التي تُجمع فقط لأغراض التقارير. الأولى يجب أن تكون بسيطة وسريعة الإدخال لأن المستخدم الميداني يملؤها أثناء العمل، بينما يمكن للثانية أن تكون أكثر تفصيلًا لأنها تُراجع لاحقًا من قِبل الإدارة.
تحديد مالك كل خطوة
كل مرحلة في العملية يجب أن يكون لها مالك واحد واضح، لا فريق أو “إدارة” بشكل عام. حين تُسند الخطوة إلى جهة غير محددة الاسم، تتحول المتابعة إلى تخمين: من المفترض أن يتصرف الآن؟ الملكية الواضحة لا تعني عزل الآخرين عن رؤية الحالة، بل تعني أن شخصًا واحدًا مسؤول عن التحرك بها للأمام في كل لحظة.
من المفيد رسم هذه الملكية على شكل جدول بسيط قبل أي تهيئة تقنية: كل حالة في العملية، ومن ينقلها للحالة التالية، وما المدة المتوقعة قبل اعتبارها متأخرة. هذا التمرين يكشف غالبًا خطوات بلا مالك واضح كانت تُدار سابقًا بالتنسيق غير الرسمي، وهي أول ما يجب إصلاحه قبل نقل العملية إلى نظام.
تصميم مسار الحالات
الخطأ الأكثر شيوعًا في تصميم الحالات هو جعل عددها يعكس الهيكل الإداري بدل أن يعكس الحالة الفعلية للعمل. حين تختلف تسميات الحالة بين إدارة وأخرى لنفس المعنى الفعلي — “قيد المراجعة” في قسم و“بانتظار الموافقة” في آخر لنفس الخطوة تقريبًا — تصبح التقارير المجمّعة غير موثوقة لأن الأنظمة تقارن أشياء غير متطابقة تسميًا.
القاعدة العملية: كل حالة يجب أن تملك معنى تشغيليًا واحدًا وإجراءً متوقعًا واضحًا مرتبطًا بها. إن لم يكن هناك إجراء محدد يترتب على وجود الحالة، فهي على الأرجح حالة زائدة يمكن دمجها مع غيرها. كما يجب أن يكون لكل عملية حالة واحدة نشطة في أي لحظة، لا حالات متوازية متضاربة تجعل من الصعب معرفة أين تقف العملية فعليًا.
مسار الاستثناء لا يقل أهمية عن المسار المثالي
من السهل تصميم مسار الحالة للسيناريو المثالي: تُفتح الحالة، تُنجز، تُغلق. الأصعب هو تحديد ما يحدث حين لا يسير الأمر كذلك. ماذا يحدث إن غاب المسؤول عن الخطوة؟ من يستلم الحالة إن تجاوزت المهلة المحددة؟ هل يمكن إعادة فتح حالة مغلقة، ومن يملك صلاحية ذلك؟ من يبني النظام دون الإجابة عن هذه الأسئلة مسبقًا سيجد المستخدمين يبتكرون حلولًا يدوية موازية بمجرد ظهور أول استثناء حقيقي، وهذا يعيد المشكلة الأصلية التي كان الهدف حلها.
مثال عملي: تهيئة مسار مخالفة
لنفترض تصميم مسار للتعامل مع مخالفة تشغيلية. الحالات المنطقية قد تكون: مسجّلة، قيد المراجعة، مؤكدة، قيد المعالجة، مغلقة. لكل حالة مالك محدد: المراقب الميداني يسجلها، مشرف المنطقة يراجعها، مالك العقد يؤكدها ويحدد إجراء المعالجة، والفريق التنفيذي يغلقها بعد التأكد من التنفيذ. مسار الاستثناء يحدد ماذا يحدث إن لم تُراجَع المخالفة خلال مدة معينة — تصعيد تلقائي لمشرف أعلى، لا بقاؤها معلّقة بلا صاحب.
هذا النوع من التصميم — القرارات حول البيانات والملكية والحالات — هو ما يجب حسمه قبل فتح أي إعداد داخل النظام، سواء كانت الوحدة المستخدمة لاحقًا خاصة بالمخالفات العامة أو بوحدة تشغيل العقود أو غيرها؛ الإعداد التقني يعكس قرارًا سبق اتخاذه، لا العكس.
التدرج بدل التطبيق الشامل
بعد حسم هذه القرارات، التطبيق الأفضل يبدأ بعملية واحدة محدودة النطاق، لا بمحاولة تهيئة كل شيء دفعة واحدة. تجربة عملية واحدة تكشف أخطاء في تصميم الحالات أو الملكية يصعب رؤيتها نظريًا، ويمكن تصحيحها قبل أن تتكرر عبر عمليات أخرى.
أسئلة شائعة
كم عدد الحالات المثالي لأي عملية؟
لا يوجد رقم ثابت، لكن القاعدة العملية أن كل حالة يجب أن تحمل معنى وفعلًا متوقعًا. إن وجدت حالتين لا فرق عمليًا بينهما، فهما على الأرجح حالة واحدة بمسميين.
من يجب أن يشارك في تصميم مسار الحالات قبل التهيئة؟
من ينفذ العملية فعليًا ميدانيًا، لا الإدارة فقط. كثير من مسارات الحالات المصممة من مكتب الإدارة تتجاهل تفاصيل تظهر فقط لمن يؤدي العمل يوميًا.
ماذا لو تغيرت العملية بعد التهيئة؟
هذا متوقع وطبيعي. المسار الجيد قابل للتعديل، لكن يجب توثيق سبب كل تعديل ومراجعة أثره على التقارير التاريخية حتى لا تفقد المقارنات الزمنية معناها.
