بوابة العملاء: وحدة الـERP أم بناء مستقل؟ قرار من ستة أبعاد

عندما تقرر شركة فتح بوابة لعملائها، يظهر خياران سريعان: وحدة بوابة العملاء داخل نظام ERP الحالي، أو بوابة مبنية بشكل مستقل تتصل بالـERP عبر واجهات برمجية. الأول يبدو أرخص لأنه «موجود بالفعل». الثاني يبدو أنظف لأنه «مصمّم للمستخدم». وكلا الانطباعين قد يكون صحيحاً أو خاطئاً حسب عدد المستخدمين ونوع البيانات وطريقة تسعير مزوّد الـERP.

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

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

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

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

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

قارن الخيارين على البعد نفسه، لا على السعر النهائي. كل بند أدناه يمكن أن يقلب القرار إذا كان متطرفاً.

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

اسأل أيضاً أين تُخزَّن البيانات. بعض الجهات تطلب استضافة داخل المملكة، وبعضها يقبل استضافة إقليمية بعقد واضح. القرار يؤثر على الـERP نفسه، لا على البوابة وحدها. راجع قائمة الامتثال لبوابة العملاء قبل أن تبدأ التصميم.

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

اختر هذا المسار فقط إذا كان لديك فريق يتحمّل تشغيل نظامين، وموعد انتقال واضح، وميزانية للفترة المزدوجة. بدون هذه الثلاثة، يتحول المسار التدريجي إلى نظامين دائمين، ويدفع العميل ثمن الاثنين بلا مكسب واضح.

هل البوابة المخصصة أغلى دائماً؟ في البناء غالباً نعم. في التشغيل قد تكون أرخص إذا كان عدد المستخدمين كبيراً.

هل يمكن بناء بوابة فوق ERP دون تغييره؟ نعم، عبر واجهات برمجية أو طبقة قراءة. تحتاج اتفاقاً واضحاً على من يملك التكامل.

كم يستغرق بناء بوابة؟ يعتمد على عدد المهام والتكاملات. المشروع المركّز يبدأ من نطاق منشور، ثم يُسعَّر بعد الاكتشاف.

هل نحتاج فريق دعم جديد؟ نعم، أو عقد دعم واضح. البوابة قناة يراها العميل كل يوم، لا نظام داخلي.

ماذا لو كان الـERP سيُستبدل؟ لا تبنِ تكاملاً عميقاً قبل قرار الاستبدال. ابنِ طبقة واجهة يمكن نقلها.

• اللائحة التنفيذية لنظام حماية البيانات الشخصية — التزامات المعالجة والإفصاح والإبلاغ.
• OASIS — معايير مفتوحة تُستخدم في تكامل أنظمة المؤسسات.
• نطاقات رصد السعرية — الأرقام المنشورة قبل المكالمة.
• أنظمة المؤسسات — كيف نبني التكامل والبوابات.
• تكلفة تطوير بوابة عملاء — تفصيل النطاق.