تحتاج دراسة نظام داخلي عندما يصبح تنفيذ إجراء متكرر معتمدًا على صلاحيات واعتمادات وحالات لا تستطيع ضبطها عمليًا بالأداة الحالية. كثرة الصفوف أو الرغبة في لوحة جميلة لا تكفي. إذا كانت البيانات صحيحة والعمل يسير بوضوح، فقد يكفي تحسين الجدول. وإذا كان برنامج جاهز يحقق المطلوب، فتجربته تسبق تكليف بناء مخصص.
لمنشأة سعودية نامية، البداية الأنسب غالبًا هي إجراء واضح: طلب خدمة بين الفروع، أو اعتماد مستند، أو متابعة تنفيذ مهمة. حدّد بدايته ونهايته ومسؤوله، ثم قرر إن كنت تحتاج نظام إدارة عمليات داخلية ولوحة متابعة. لا تحول الطلب من أول جلسة إلى مشروع لإعادة بناء كل أنظمة الشركة.
1. هل المشكلة في التقرير أم في تنفيذ العمل؟
اسأل فريقك: «لو ظهر التقرير المطلوب الآن، هل سيُحل التعطل؟». إذا كانت الإجابة نعم، فقد تحتاج تنظيف البيانات أو توحيد تعريف المؤشر أو لوحة قراءة فقط. أما إذا كان الموظف لا يعرف مَن يعتمد الطلب، أو يستطيع شخص تعديل حالة لا يحق له تعديلها، فالمشكلة في الإجراء نفسه.
فرّق بين ثلاثة مخرجات:
| المطلوب | ما يقدمه | ما لا ينبغي افتراضه |
|---|---|---|
| جدول منظم | بيانات وحسابات ومتابعة بسيطة | أنه يفرض كل قواعد العمل والصلاحيات المطلوبة |
| لوحة مؤشرات | عرض حالة البيانات ومساعدة الإدارة على المراجعة | أنها تعالج طلبًا أو تسجل اعتمادًا تشغيليًا |
| نظام عمليات | إدخال مضبوط، وحالات، وصلاحيات وإجراءات متفق عليها | أنه بديل شامل للمحاسبة والموارد البشرية وERP |
قد يجمع الحل بين نظام موجود ولوحة وتقارير مصدّرة إلى الإكسل. الاحتفاظ بالجداول للتحليل ليس فشلًا في التحول؛ المشكلة هي تعدد المصادر المتنافسة للحقيقة التشغيلية.
2. متى يكون تحسين الجداول كافيًا؟
ابقَ مع الجداول إذا كان الإجراء بسيطًا، والمشاركون يعرفون مسؤولياتهم، ومخاطر الخطأ محدودة، ويمكن ضبط الإدخال والمراجعة دون حلول ملتوية. جرّب نسخة مرجعية واحدة، ومعرّفات ثابتة للسجلات، وقواعد تحقق للحقول، وتعريفات موحدة للحالات، ومسؤولًا واضحًا عن جودة البيانات.
لكن لا تخلط حماية الخلايا بسرية السجلات. توضح Google أن حماية ورقة أو نطاق في Sheets ليست إجراءً أمنيًا، وأن إخفاء ورقة لا يمنع المحررين من إظهارها. إذا كان موظف فرع يجب ألا يرى بيانات فرع آخر، فتحقق من ضوابط الوصول الفعلية بدل الاكتفاء بإخفاء تبويب. المصدر: حماية أوراق Google Sheets وإخفاؤها.
سجّل حالات الفشل الواقعية قبل اختيار البديل: طلب ضاع، أو اعتماد غير موثق، أو تكرار سجل، أو تعارض تعديل. لا تضع عتبة عامة مثل «بعد عشرة موظفين تحتاج نظامًا»؛ طبيعة الإجراء والبيانات أهم من عدد المستخدمين وحده.
3. قارن أربعة خيارات على المهمة نفسها
اطلب تنفيذ سيناريو واحد من البداية للنهاية في كل خيار، باستخدام بيانات تجريبية لا معلومات حساسة.
| الخيار | متى يستحق التجربة؟ | ما تختبره قبل اختياره؟ |
|---|---|---|
| تحسين الجدول الحالي | عملية بسيطة وقواعد قليلة | وضوح المصدر، والتحقق من الإدخال، وحدود المشاركة |
| برنامج جاهز | عملية شائعة مثل الطلبات أو إدارة المهام | الحالات والاستثناءات والتصدير والصلاحيات ضمن الباقة المقترحة |
| منصة قابلة للتهيئة أو تطوير منخفض الكود | احتياج محدد يمكن تمثيله داخل حدود المنصة | التكلفة المتكررة، والتكاملات، وحدود البيانات والانتقال منها |
| نظام مخصص محدود | فجوة مهمة أثبتت التجربة أن البدائل لا تغطيها | ملكية التشغيل، والصيانة، والاختبارات، ونقل البيانات |
لا تقارن صور الشاشات. قارن قدرة كل خيار على إكمال المهمة العادية وحالة الرفض والتعديل بعد الاعتماد. واحتسب التكلفة الكلية: اشتراك أو تطوير، وتنظيف بيانات، وربط، وتدريب، ودعم، وتغييرات مستقبلية، والخروج من الأداة عند الحاجة.
4. وثّق الإجراء قبل تصميم لوحة المتابعة
تحتاج ورقة تحدد الحدث الذي يبدأ العملية، والبيانات اللازمة، والحالات المسموحة، وصاحب كل قرار، والمدة المتوقعة بحسب سياسة منشأتك، والاستثناءات. حدّد أيضًا النظام المرجعي لكل حقل: لا تجعل النظام الجديد مصدرًا موازيًا لبيانات يملكها نظام آخر دون سبب.
في اكتشاف المنتج وتوثيق المتطلبات، ينبغي أن ينتج عن النقاش نطاق يمكن اختباره: من يفعل ماذا، وعلى أي سجل، ومتى ينتقل إلى الحالة التالية، وما الذي يحدث إن رُفض الطلب أو تعطّل الربط.
ثم اختبر نموذجًا أوليًا مع الأشخاص الذين سينفذون المهام، لا المدير وحده. قد تظهر حاجة الموظف إلى قائمة أعمال يومية واضحة أكثر من حاجته إلى رسم بياني. هنا يفيد تصميم تجربة المستخدم في ترتيب خطوات العمل وحالات الخطأ قبل تثبيتها في الكود.
5. مثال افتراضي: طلبات صيانة بين فروع منشأة سعودية
هذا مثال تعليمي ببيانات اختبار، وليس مشروعًا أو نتيجة فعلية لـLAB. لدى منشأة فروع في الرياض والدمام. تُرسل طلبات الصيانة في الرسائل ويُحدّث موظف واحد جدول المتابعة. تقرر المنشأة اختبار بوابة لطلب الصيانة فقط، مع بقاء الحسابات والمشتريات في الأنظمة القائمة.
نطاق النسخة الأولى: إنشاء الطلب، وإرفاق وصف مناسب، ومراجعة المشرف، وإسناد التنفيذ، وتسجيل الإغلاق. لا يشمل إدارة الرواتب أو إصدار الفواتير أو استبدال المخزون.
مصفوفة صلاحيات مقترحة للمثال
| الدور | ما يُسمح به | ما يجب منعه |
|---|---|---|
| موظف الفرع | إنشاء طلب ومتابعة الطلبات المسموح له بها | اعتماد طلبه أو الاطلاع على فرع غير مصرح به |
| مشرف الفرع | قبول أو رفض طلبات فرعه مع سبب | تغيير سجل اعتماد قديم دون أثر محفوظ |
| مسؤول العمليات | الإسناد والمتابعة والإغلاق وفق القاعدة المتفق عليها | إغلاق الطلب قبل اكتمال بيانات الإغلاق المطلوبة |
| المراجع | الاطلاع والتصدير ضمن نطاقه | تعديل الطلبات أو اتخاذ قرار اعتماد |
وجود زر مخفي ليس اختبارًا كافيًا للصلاحية. توصي OWASP بالحد الأدنى من الصلاحيات، والمنع الافتراضي، والتحقق من الإذن في كل طلب. لذلك ينبغي أن يشمل الاختبار محاولة الوصول غير المسموح بها، ضمن بيئة ونطاق مصرّح بهما، لا مجرد مشاهدة القوائم. المصدر: إرشادات التفويض من OWASP.
كيف نتأكد أن اللوحة تعرض الرقم الصحيح؟
افترض ثمانية طلبات اختبار: ثلاثة مسودات، واثنان قيد المراجعة، واثنان معتمدان ينتظران التنفيذ، وواحد مغلق. إذا عرّفت المنشأة «الطلبات النشطة» بأنها قيد المراجعة أو المعتمدة غير المغلقة، فالنتيجة أربعة، لا سبعة ولا ثمانية.
يجب أن تقود بطاقة «أربعة طلبات نشطة» إلى السجلات الأربعة نفسها، مع احترام صلاحية الفرع والفترة الزمنية. ثم غيّر حالة طلب واحد وتأكد من اتساق القائمة والبطاقة. هذه مطابقة مصدر مع شاشة، وليست تجميل تقرير.
6. اختبارات القبول التي تمنع المفاجآت
اكتب الاختبارات قبل اعتماد التنفيذ:
- يمر طلب كامل من الإنشاء إلى الإغلاق مع حفظ المسؤول عن كل إجراء.
- لا يعتمد صاحب الطلب طلبه إذا كانت سياسة العمل تمنع ذلك.
- لا يرى المستخدم سجلًا خارج نطاقه، حتى عبر رابط مباشر.
- يظهر سبب الرفض، ويعرف الموظف كيف يصحح الطلب ويعيد تقديمه.
- لا يُحفظ تعديل قديم فوق تعديل أحدث بصمت عند عمل شخصين على السجل.
- تتطابق أرقام اللوحة مع السجلات والمرشحات وتعريف الحالة.
- يظهر فشل التكامل أو التنبيه للمسؤول، ولا ينتج التكرار سجلات مزدوجة.
- تُختبر العربية على الجوال، والحقول والتواريخ ورسائل الخطأ المطلوبة.
- يمكن تصدير البيانات المتفق عليها وقراءة سجل الإجراءات واستعادة نسخة وفق الخطة.
إذا احتجت جلب بيانات من برنامج آخر، فعرّف اتجاه التحديث، والتكرار، والصلاحيات، والمسؤول عن التعارض. خدمة تطوير وربط واجهات برمجة التطبيقات مناسبة لهذا الجزء عندما تكون الواجهات والاعتمادات متاحة؛ وجود واجهة لا يعني تلقائيًا إمكانية ربط أي نظام بلا قيود.
7. انقل البيانات تدريجيًا وسلّم مسؤولية التشغيل
ابدأ ببيانات منظفة، مع تعريف للسجلات المكررة والحقول الناقصة. طابق أعداد السجلات وعينة من تفاصيلها، وحدد ما سيُنقل وما سيبقى في أرشيف للقراءة. لا تحوّل كل ملف قديم إلى وظيفة جديدة.
أثناء التجربة، عيّن مصدرًا رسميًا للقرار وكيفية تسوية الفروق؛ التشغيل المتوازي دون هذه القاعدة يخلق نسختين مختلفتين بدل التحقق من الانتقال. اعتمد التوسع بعد نجاح المهام والصلاحيات والمطابقة وتدرّب الفريق، لا بمجرد اكتمال الشاشات.
اطلب سجلًا للعيوب ونتائج اختبار وضمان جودة البرمجيات، ودليل إدارة المستخدمين والنسخ والتصدير، ومسؤولًا للتشغيل بعد التسليم. النظام المحدود يحتاج مالكًا أيضًا؛ لا تجعل كل تحديث بسيط معتمدًا على ذاكرة منفّذ واحد.
أسئلة شائعة
هل لوحة المتابعة تعني أننا نملك نظام عمليات؟
لا. قد تعرض اللوحة بيانات من ملفات دون التحكم في إنشائها أو اعتمادها. اسأل أين تُنفّذ المهمة وأين تُفرض القاعدة، ثم حدّد دور اللوحة.
هل النظام المخصص أفضل دائمًا من البرنامج الجاهز؟
لا. قد يغطي البرنامج الجاهز الإجراء بتكلفة تشغيل وجهد أقل. يصبح البناء خيارًا مبررًا عندما تثبت فجوة مهمة بعد تجربة البدائل، مع قدرة واضحة على تشغيل الحل وصيانته.
هل يجب إلغاء الإكسل تمامًا؟
لا. يمكن إبقاؤه للتحليل والتخطيط والتصدير. المهم ألا تتحول نسخة التحليل إلى مصدر تعديل منافس للسجل التشغيلي المعتمد.
هل يمكن ربط النظام بالمحاسبة لاحقًا؟
قد يمكن ذلك بحسب النظام القائم وواجهاته وصلاحياته. افصل هذا الربط عن النسخة الأولى، وحدّد البيانات والمسؤولية ومعايير المطابقة. بوابة إجراء واحد لا تعني بناء ERP أو اعتمادًا محاسبيًا.
الخطوة التالية
اختر إجراءً واحدًا يتعطل اليوم، واجمع نموذج طلب وحالة رفض ومثال تعارض بيانات. اطلب مقارنة عملية بين تحسين الأداة الحالية، وتهيئة برنامج جاهز، وبناء نطاق محدود، باستخدام سيناريو القبول نفسه في الخيارات الثلاثة.
المصادر
رُوجعت في 26 أكتوبر 2026.
