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