تطوير نظام زوار خاص أم اعتماد منتج قابل للتهيئة؟ مصفوفة قرار للمصانع

أربعة طرق لا طريقان

يُطرح السؤال عادة كأنه ثنائي: «نشتري أم نبني؟». في الواقع أمام المنشأة أربعة طرق، ولكل منها من يملكه ومن يتحمل مخاطرته:

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

ما يُستهان به عند التطوير الخاص

نموذج طلب زيارة وجدول موافقات يمكن بناؤهما في أسابيع. الصعوبة ليست هناك، بل في الأجزاء التي لا تظهر في العرض الأول ولا في الكراسة المختصرة:

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

كل بند من هذه يمكن بناؤه. السؤال هو هل أدرجته الكراسة، وهل قدّره الفريق، ومن سيصونه بعد مغادرة من بناه.

اختبار التغطية: صنّف قائمتك قبل القرار

خذ قائمة متطلباتك — إن كانت مكتوبة كحالات كما في نموذج وثيقة المتطلبات فأفضل — واطلب من مورّد منتج أو اثنين تصنيف كل بند بالمستويات الأربعة الموضحة في صفحة مستويات التخصيص: إعداد، أو محتوى وقالب، أو تخصيص برمجي، أو خارج نطاق المنتج. ثم انظر إلى النتيجة لا بالعدد فقط، بل بالموقع:

• إن كانت بنود التخصيص البرمجي على أطراف الإجراء — تقرير بنموذج داخلي، قاعدة خاصة لفئة واحدة — فالمنتج يغطي الجوهر، والتخصيص بنود محددة.
• إن كانت في قلب الإجراء — طريقة اعتماد لا تشبه أي مسار، أو كيان لا يوجد في منطق الزيارة أصلًا — فهذا مؤشر حقيقي على أن التطوير الخاص يستحق الدراسة.
• إن كثرت بنود «خارج النطاق»، فراجع هل تطلبون نظام زوار أصلًا، أم نظام مستودعات أو تصاريح عمل أو تتبع مواقع باسم آخر.

هذا الاختبار يستغرق أيامًا، ويحوّل نقاشًا عامًا عن «مرونة المنتجات» إلى قائمة بنود يمكن مناقشة كل منها.

مصفوفة القرار

تكلفة الملكية بعد السنة الأولى

مقارنة «تكلفة البناء» بـ«سعر المنتج» تخطئ غالبًا لصالح البناء، لأن تكاليف ما بعد التسليم لا تظهر في عرض المطوّر. أضف إلى جانب التطوير الخاص هذه البنود على الأفق نفسه الذي تقارن عليه العروض:

• تشغيل الخوادم ومراقبتها ونسخها الاحتياطية واختبار استرجاعها.
• تحديثات الأمان للنظام ومكتباته، خصوصًا الجزء المكشوف للزوار.
• معالجة الأعطال خارج أوقات العمل إن كانت لديكم مناوبات.
• التوثيق ونقل المعرفة عند تغيّر المطوّر أو الفريق.
• كل تغيير في الإجراء — لأنه تطوير، لا إعداد يجريه مسؤول النظام.

وبالمقابل، أضف إلى جانب المنتج بنوده المتكررة والمستثناة كما في جدول تطبيع العروض على خمس سنوات. المقارنة العادلة تضع الطريقين على الأفق نفسه وبالتفصيل نفسه.

الطريق الوسط: منتج وواجهات

كثير من المنشآت التي تميل إلى البناء لا تريد في الحقيقة نظام زوار مختلفًا، بل تريد أن تبقى بياناتها ومنطقها متصلين بأنظمتها: أن يُنشأ طلب الزيارة من نظام الصيانة، أو أن تظهر حالة الزيارة في لوحة داخلية. هذا لا يحتاج بناء النظام كله؛ يحتاج واجهات ربط محددة النطاق. صفحة التكامل تشرح الواجهات البرمجية المتاحة ضمن نطاق يُحدد: ما العمليات، ومن يستدعيها، وما البيانات، مع صلاحية ومفتاح وسجل لكل تكامل.

مثال: فريق تقنية يريد البناء

أسئلة متكررة