في السنوات الأخيرة انتشر تخوّف داخل بعض الشركات من فكرة أن:
“الاعتماد على شركة مصرية لتنفيذ نظام ERP قد يكون مخاطرة… لأنه لو الشركة قفلت، النظام نفسه هيتوقف أو هينهار.”

 

هذا المفهوم شائع… لكنه بعيد تمامًا عن الواقع التقني والهندسي في عالم البرمجيات.
ولكي نفهم الموضوع بشكل مهني، يجب أن نبدأ من السؤال الأهم:

هل يعتمد نظام ERP على وجود الشركة المنفذة… أم على وجود هندسة واضحة تُسهّل استكمال العمل عليه مهما تغيّر الـ Vendor؟

 

الإجابة الواضحة:
أي نظام ERP محترف يعتمد على معمار هندسي ثابت—not على شركة واحدة.

أولًا: نظام الـ ERP ليس “برنامجًا”… بل مشروع هندسي كامل

النظام المحترف يتكون من مجموعة عناصر واضحة:

  • معمار برمجي (Software Architecture)

  • هيكل قاعدة بيانات موثق (Database Schema)

  • قواعد تشغيل منطقية (Business Logic)

  • مسارات عمل (Workflows)

  • واجهات ربط (APIs)

  • توثيق كامل (Documentation)

هذه العناصر تجعل النظام كيانًا هندسيًا مستقلًا وقابلًا للصيانة والتطوير بغض النظر عن الشركة التي بدأت التنفيذ.

ثانيًا: تغيير شركاء التنفيذ Vendor Switching أمر طبيعي عالميًا

على مستوى العالم، الشركات المتوسطة والكبيرة تغيّر شركاء الـ ERP باستمرار:

  • توسع

  • اندماج

  • تغيير استراتيجية

  • نمو

  • اختلاف في مستوى الدعم الفني

ومع ذلك لا تتوقف الأنظمة ولا تضيع، لأن الأساس الهندسي سليم.

ثالثًا: لماذا لا ينهار النظام لو الشركة المصرية المنفذة توقفت؟

لأسباب تقنية واضحة:

1) وجود توثيق كامل

الـ Documentation تُمكّن أي فريق من فهم النظام.

2) اعتماد النظام على Standards عالمية

 

مثل:
MVC – Layered Architecture – API-first – Design Patterns

3) قاعدة البيانات نفسها ليست سرًا

مجرد قراءة الـ Schema تفسّر معظم حركة النظام.

4) منطق العمل Business Logic ثابت

واضح ومفهوم لأي مهندس متخصص.

5) إمكانية نقل النظام لأي Vendor آخر بسهولة

طالما أن النظام مبني بطريقة هندسية صحيحة.

رابعًا: الخطر الحقيقي ليس أن “الشركة تقفل”… بل أن النظام يُبنى بدون هندسة سليمة

الخطر الحقيقي:

  • نظام بلا معمار

  • كود غير موثق

  • غياب الـ Standards

  • عدم وجود API واضحة

  • الاعتماد على مبرمج واحد فقط

هذه هي الأسباب التي تجعل أي نظام غير قابل للاستمرار.

خامسًا: الاستمرارية لا تأتي من “البراند”… بل من المنهج الهندسي

الشركات تحتاج إلى:

  1. معمار سليم

  2. وثائق كاملة

  3. دعم فني واضح

  4. نظام قابل للتسليم لفريق آخر

عند توفر هذه العناصر… الاستمرارية مضمونة مهما كان اسم الشركة.

سادسًا: كيف نتعامل مع هذا المفهوم داخل Project Metric؟

في Project Metric نعتبر أن بناء الـ ERP هو هندسة لها قواعد واضحة، لذلك نلتزم بـ:

1) معمار برمجي ثابت وواضح

Layered Architecture + Clean Code

2) توثيق كامل لكل جزء

Database Schema – APIs – Workflows – Business Logic

3) معايير عالمية في التنفيذ

MVC – API-first – Design Patterns – Security Principles

4) نظام مستقل عن وجود الشركة

يمكن لأي فريق استلامه والعمل عليه بدون البدء من الصفر.

5) حق العميل في الوثائق الكاملة

نسلّم Documentation شاملة في نهاية كل مشروع.

الخلاصة

 

السؤال:
ماذا لو الشركة المصرية المنفذة لنظام ERP أغلقت؟

 

الإجابة:
لن يحدث شيء… إذا كان النظام مبنيًا بمعايير هندسية سليمة.

 

السؤال الأصح:
هل النظام مبني هندسيًا بشكل صحيح يسمح لأي Vendor بالاستمرار؟ أم أن النظام مجرد كود بلا معايير؟

 

الاستمرارية قرار هندسي…
وليست قرار “براند”.