الافتتاح: يتم اعتماد طلبات السفر عبر رسائل المجموعة، ويُعتمد على السؤال للعثور على مسؤول الموافقة
في شركة تصنيع يبلغ عدد موظفيها نحو 200 موظف، كانت أول طلب سفر بعد العام الجديد كما يلي: يُشير الموظف إلى المشرف في المجموعة، ويرد المشرف بـ"موافق"، ثم يحفظ الموظف لقطة الشاشة؛ وعندما يحين وقت إعداد تقارير السفر لدى قسم المالية نهاية الشهر، يتم مراجعة اللقطات واحدة تلو الأخرى مقابل الميزانية؛ وفي نهاية العام، يقوم قسم الموارد البشرية بإحصاء "عدد أيام سفر الموظفين"، ليكتشف أن اللقطات غير كاملة وأن البيانات بين الأقسام غير متطابقة.
هذه ليست حالة فردية. ففي العديد من الشركات داخل البلاد، تسير عملية الموافقة على النحو التالي:
- العثور على المسؤول بالسؤال : خلال الأسبوع الأول من التعيين، يكون السؤال الأكثر شيوعًا هو: "من الذي يوافق على إجازتي؟ ومن الذي يراجع حساباتي؟"
- استخدام رسائل المجموعة كإثبات : في مجموعات ويشات أو دينغدونغ، يُعتبر الإشارة إلى "تمت الموافقة من قبل المدير" بمثابة إقرار بالموافقة، مما يجعل المراجعة اللاحقة مستحيلة.
- عدم توافق البيانات بين الأقسام : يرى قسم المبيعات أن زيارة العميل قد تمت الموافقة عليها، بينما يرى قسم التسويق أنها لم تُعتمد، وتقوم المالية بدفع المبلغ بناءً على لقطة شاشة من قسم المبيعات.
- الاعتماد على الصلاحيات الشفهية : عند مغادرة مدير ما للشركة، لا تُستعاد صلاحياته، ولا يعرف الموظف الجديد من يحمل عقد الموافقة السابق للمدير.
إن جذور هذه المشاكل لا تكمن في مدى تعقيد عملية الموافقة، بل في أنّ سير العمل الخاص بالموافقة لم يُدمج في النظام . فرسائل المجموعة والكلام الشفهي ولقطات الشاشة كلها وسائل مؤقتة، وما ينقص هو وجود وسيلة منظمة، مسجلة، وقابلة للتتبع. نظام OA (نظام التشغيل الآلي للمكاتب) هو الذي يُنظّم هذه العملية: إذ يُوثّق كل شيء — من "من، أي موضوع، متى، من تم استدعاءه، ووفق أي قواعد تمت الموافقة، وكيف تُرسب البيانات بعد الموافقة" — ضمن سير عمل واحد.
إن تقسيم عملية الموافقة إلى أجزاء يتكوّن في الواقع من ثلاثة مستويات:
- مستوى الموضوعات : يُقدّم الموظف طلبات محددة مثل "السفر، الإجازة، المطالبة بالمصاريف، العقود، ختم المستندات، الشراء"، وكل منها يحتوي على مبالغ مالية، أيام، مرفقات، وأشياء مرتبطة بالأعمال (مثل ربط طلب السفر بأمر البيع، وربط المطالبة بالمصاريف بالفاتورة).
- مستوى الإجراءات : تنتقل الطلبات من نقطة إلى أخرى، ويُحسب مسؤول الموافقة لكل نقطة بشكل ديناميكي (بحسب القسم، المستوى، المبلغ، الفئة)، وليس بشكل ثابت.
- مستوى البيانات : بعد الموافقة أو الرفض، يجب إعادة كتابة البيانات إلى أنظمة الأعمال (الموارد البشرية، المالية، المبيعات، قاعدة العقود)، ولا يجوز تركها محصورة في سير العمل فقط.
العلاقة بين المستويات الثلاثة هي: الموضوعات هي المدخل، الإجراءات هي العمود الفقري، والبيانات هي المخرج . فإذا تم تصميم نظام OA دون إدراج بيانات المخرج، سيصبح سير العمل الخاص بالموافقة جزيرة معزولة؛ وإذا تم التركيز على الموضوعات فقط دون وضع إجراءات، فسيتحوّل إلى مجرد "نظام ملء الاستمارات".
02 كيف نصمم: ثلاثية العناصر الأساسية: العقد الديناميكي، مصفوفة الصلاحيات، وتسجيل الأثر
تصميم العقد: مسؤول الموافقة ليس ثابتًا
كثير من أنظمة OA تُحدد مسؤول الموافقة منذ البداية: "طلب السفر → مدير القسم → الموارد البشرية → المدير العام". ونتيجة لذلك، عند تغيير مدير القسم، أو دمج الموارد البشرية في قسم الإدارة، أو غياب المدير العام، يختل النظام تمامًا.
الطريقة الصحيحة: يُحسب مسؤول الموافقة ديناميكيًا وفق القواعد . وعادةً ما تشمل أبعاد القواعد أربعة:
- البعد التنظيمي : يُربط قسم المتقدم بالمسؤول الحالي لهذا القسم (بالاستعلام عن طريق شجرة التنظيم في الوقت الحقيقي).
- البعد المستوى : تُربط المبالغ، الأيام، وقيمة العقد بفئات مختلفة، وكل منها يرتبط بمستوى موافقة مختلف.
- البعد الوظيفي : إذا تجاوزت قيمة العقد 500 ألف، يجب أن يتدخل قسم الشؤون القانونية؛ وإذا سافر الموظف إلى الخارج، يجب أن يُوقّع على المستندات لضمان السلامة والامتثال.
- البعد الوكيل : عندما يغيب مسؤول الموافقة أو يسافر، يُحال الأمر تلقائيًا إلى الوكيل، ويُحدَّد الوكيل إما وفق العلاقات التنظيمية أو بواسطة قسم الموارد البشرية.
تُجمَع هذه الأبعاد الأربعة في "تعبير قواعد"، ويحسب محرك الإجراءات العقد ديناميكيًا وفق القواعد، دون تحديد اسم مسؤول الموافقة بشكل ثابت . وبذلك، لا يحتاج تغيير المناصب أو التعديلات التنظيمية إلى تعديل قالب الإجراءات.
تصميم الصلاحيات: ثلاث مستويات — القائمة، البيانات، الحقول
الصلاحيات ليست مجرد "هل يمكن الدخول إلى النظام؟"، بل هي ثلاثية المستويات:
- مستوى القائمة : هل يمكن رؤية هذا القسم (الموظف العادي لا يستطيع رؤية "إدارة الهيكل التنظيمي")؟
- مستوى البيانات : هل يمكن رؤية هذه البيانات (قسم المبيعات الأول يستطيع رؤية مطالبات موظفيه فقط، ولا يمكنه رؤية قسم المبيعات الثاني)؟
- مستوى الحقول : هل يمكن رؤية بعض حقول هذه البيانات (المسؤول العادي لا يستطيع رؤية حقل راتب المتقدم، لكن قسم الموارد البشرية يستطيع)؟
بعد تقسيم الصلاحيات إلى مستويات ثلاثية، يصبح نظام OA قادرًا على دعم الهياكل التنظيمية المعقدة: المجموعة-الفرع-القسم-الفريق، حيث تُدار البيانات عبر المستويات المختلفة وفق قاعدتين متوازيتين: "أستطيع رؤية نفسي ضمن هذا الخط + أنا مسؤول عن هذا الخط".
تصميم تسجيل الأثر: العناصر السبعة لسجل الموافقة
يجب تسجيل سبعة عناصر في كل عملية موافقة:
- الشخص الذي قام بالعمل : من الذي ضغط الزر.
- وقت التنفيذ : بدقة حتى الثانية.
- فعل التنفيذ : الموافقة، الرفض، الإحالة، الإضافة، الإلغاء.
- رأي التنفيذ : يجب ملء رأي الرفض، أما الموافقة فيمكن تركها فارغة.
- موقع العقد : في أي مرحلة من سير العمل يوجد الآن.
- لقطة للبيانات المرتبطة : أثناء الموافقة، تُحفظ قيم حقول موضوع العمل (المبلغ، المرفقات) كما هي، ولا يُسمح بتعديل موضوع العمل لاحقًا دون تغيير سجل الموافقة.
- آثار الجهاز وعنوان IP : من أي جهاز ومن أي عنوان IP جاءت (لأغراض التدقيق والامتثال).
إذا فقد أحد هذه العناصر السبعة، ستظهر مشكلات أثناء التدقيق. ومن الأخطاء الشائعة أن يُترك "رأي التنفيذ فارغًا"، مما يؤدي إلى رفض بلا سبب، وإعادة تقديم الطلبات من قبل الموظفين، وتطويل سير العمل.
03 كيف نطوّر: ثلاثية المحركات — محرك الإجراءات، محرك النماذج، وحافلة الرسائل
جوهر تطوير نظام OA يكمن في ثلاثة محركات، وليس في عدد الصفحات:
محرك الإجراءات
لا يتطلب محرك الإجراءات كتابة الكود، بل يمكن تشغيله عبر الإعدادات فقط. ومن الخصائص التي يجب دعمها:
- التسلسل، التوازي، التوقيع المشترك، التوقيع المنفصل : أربع أنواع أساسية من سير العمل، فطلب التثبيت يكون بالتسلسل (الموارد البشرية → المشرف → الرئيس التنفيذي)، بينما الشراء بالتوقيع المشترك يكون بالتوازي (المالية والمشرف على الشراء يراجعان معًا).
- التفرع وفق الشروط : تُقسّم الطلبات حسب المبلغ، الفئة، ومستوى المتقدم؛ فالطلبات تحت 5000 يوان تُعالج بإجراءات مبسطة، ومن 5000 إلى 50000 تُراجع من قبل القسم والمالية معًا، وأكثر من 50000 تُعرض على الرئيس التنفيذي.
- الرجوع والرفض: يتعين دعم ثلاثة أنواع من الرفض، وهي الرفض إلى مقدم الطلب، والرفض إلى أي عقدة، والرفض إلى العقدة السابقة.
- التوقيع الإضافي والتحويل للتوقيع: يمكن للمستلم للموافقة تحويل المهمة إلى زميل (تحويل التوقيع)، كما يمكنه إشراك زميل آخر في المراجعة (التوقيع الإضافي).
- السحب والإلغاء: يستطيع مقدم الطلب سحب الأمور التي لم تُعتمد بعد؛ ويمكن للمدير إلغاء الأمور الشاذة.
بعد إنشاء محرك العمليات،تم إضافة فئة جديدة من الموافقات لا تتطلب كتابة الكود، إذ يكفي رسم مخطط وتهيئة نموذج لتشغيلها مباشرةً. وهذا هو العامل الأساسي الذي يميّز نظام OA عن "التطوير الخارجي للموافقات".
محرك النماذج
يجب أن يكون تصميم النماذج "بدون كود": حيث تُحدد أنواع الحقول (نص، رقم، تاريخ، مرفق، علاقة مع كائن أعمال)، وقواعد التحقق، وحالة الإلزامية أو الاختيارية، وشروط الإظهار أو الإخفاء، كل ذلك عبر تكوين مرئي بالسحب والإفلات. وبهذه الطريقة، عندما يرغب قسم الموارد البشرية في تعديل حقل المصاريف، أو قسم المبيعات في إضافة حقل العقد، فلا يحتاج إلى جدولة مسؤولي تقنية المعلومات.
يتعين على محرك النماذج دعم ما يلي:
- صلاحيات على مستوى الحقل: في النموذج نفسه، لا يرى كل مراجع نفس الحقول (فالمراجع العادي لا يرى رقم هاتف مقدم الطلب).
- ربط الحقول : عند اختيار "نوع العقد = عقد خدمات"، تُعرض تلقائيًا الحقول الخاصة بعقد الخدمات.
- كتابة البيانات إلى النظام الأساسي : بعد اعتماد الطلب، تُكتب البيانات تلقائيًا إلى أنظمة الأعمال (حالة العقد، حضور الموظفين في قسم الموارد البشرية، السجلات المالية).
حافلة الرسائل
عند اعتماد الطلب أو رفضه، يتلقى المتقدم والأنظمة ذات الصلة (الموارد البشرية، المالية، المبيعات) إشعارًا فوريًا. يتم إرسال الإشعارات بشكل موحد عبر حافلة الرسائل:
- الإشعارات داخل النظام : رسائل داخل التطبيق مع مهام معلقة.
- إشعارات IM : عبر ويب هوك لتطبيقات WeChat للأعمال، DingTalk، Feishu، حيث تُرسل إلى المجموعات أو الأفراد المعنيين.
- البريد الإلكتروني والرسائل النصية : إشعارات احتياطية عند نقاط مهمة (مثل اعتماد العقود، السفر للخارج).
- رسائل أنظمة الأعمال : بعد اعتماد الطلب، يُضاف إشعار إلى قائمة المهام في نظام الأعمال (مثل إشعار الموارد البشرية بمهام التوظيف، وإشعار المالية بطلبات السداد).
حافلة الرسائل ليست مجرد "زينة"، بل هي "حلقة التغذية المرتدة" لسير المراجعة—فبدون الإشعارات، لا يعرف المتقدم من هو الشخص التالي الذي يجب التواصل معه، مما يؤدي إلى تعثر العملية برمتها.
الخلاصة: ترتيب التنفيذ، المخاطر، والمؤشرات
إطلاق نظام OA يتم على ثلاث مراحل:
- المرحلة الأولى (شهر واحد) : إدخال ثلاثة إجراءات شائعة الاستخدام وهي طلب الإجازة، السفر للعمل، وطلب السداد، لتغطية جميع الموظفين. نبدأ بنقل إجراءات المراجعة من مجموعات WeChat إلى النظام ، وحتى إذا كان ذلك فقط لهذه الإجراءات الثلاثة، فإن بيانات الأقسام المختلفة ستتوافق فورًا.
- المرحلة الثانية (شهرين إلى ثلاثة أشهر) : إدخال أربعة إجراءات متوسطة الشيوع وهي العقود، ختم الوثائق، الشراء، والدفع، مع ربطها بنظام المالية. وفي هذه المرحلة يجب ضمان كتابة البيانات إلى النظام الأساسي (مثل إدراج العقود المعتمدة تلقائيًا في مكتبة العقود).
- المرحلة الثالثة (حسب الحاجة) : إدخال إجراءات كاملة لشؤون الموظفين مثل الأداء، الترقية، التثبيت، التوظيف، والاستقالة. وهذه المرحلة تقودها إدارة الموارد البشرية، ويجب ربط البيانات الأساسية للموارد البشرية.
المخاطر الشائعة:
- القواعد المفرطة في المرونة : عندما تكون إعدادات سير المراجعة مفرطة في الحرية، يصبح من الصعب معرفة من هو الشخص التالي المسؤول عن المراجعة. المبدأ: يجب ألا يتجاوز عدد قوالب العمليات 30 قالبًا ، إذ إن زيادة العدد تؤدي إلى فقدان السيطرة.
- عدم تعيين وكيل مسؤول : عندما يكون المراجع في سفر ولا يُعين وكيل، يتعطل سير المراجعة لمدة ثلاثة أيام دون أي مراجعة. يقوم النظام تلقائيًا بإصدار تنبيه عند تجاوز مدة تعليق العملية 24 ساعة.
- عدم كتابة البيانات إلى النظام الأساسي : رغم اعتماد الطلب، إلا أن بيانات الحضور في نظام الموارد البشرية لم تُحدّث، ولم تُنشأ أي سجلات في النظام المالي. ويجب أن تُجرى عملية الكتابة إلى النظام الأساسي وفق "التحقق المزدوج"، وبعد إكمال الكتابة في نظام OA، يُستدعى تلقائيًا واجهة النظام الأساسي للتأكد من استلام البيانات.
مؤشرات قياس النجاح:
- متوسط وقت إنجاز المراجعة : قبل التشغيل، كانت المراجعة تستغرق ثلاثة أيام عبر المجموعات، أما بعد التشغيل، فأصبحت تُنجز خلال يوم واحد داخل النظام.
- توافق البيانات بين الأقسام : انخفاض نسبة الخطأ في مقارنة بيانات الموارد البشرية، المالية، والمبيعات بنسبة تزيد عن 80%.
- معدل إمكانية التتبع أثناء التدقيق : عند أخذ عينة عشوائية من 20 عملية مراجعة سابقة، بلغت نسبة اكتمال العناصر السبع 100%.
نقل إجراءات المراجعة من مجموعات WeChat إلى النظام ليس بهدف "إدخالها إلى النظام"، بل هو تحويل عملية "البحث عن الشخص المسؤول" من الاعتماد على الأشخاص إلى الاعتماد على القواعد . فبمجرد صياغة القواعد، لن يختل سير المراجعة حتى مع ترك موظف أو تغيير الهيكل التنظيمي.