تم النشر في 6 يونيو • نُشر في الأصل على موقع mustafaerbay.com.tr
في مسيرتي المهنية، ربما كان هذا أحد أكثر المجالات تحديًا، حيث قلت "هل يحدث هذا حقًا؟" وكان أكثرها برمجيات المؤسسات، وخاصة أنظمة تخطيط موارد المؤسسات (ERP). أثناء بناء نظام تخطيط موارد المؤسسات (ERP) من الصفر لشركة تصنيع أو التعمق في نظام موجود، أدركت أن كتابة برنامج تخطيط موارد المؤسسات (ERP) أمر صعب للغاية بالفعل. ومع ذلك، فإن هذه الصعوبة ليست مجرد مسألة فنية، كما هو شائع.
في رأيي، الجانب المعقد حقًا في كتابة برامج تخطيط موارد المؤسسات (ERP) لا يكمن في الكود نفسه، ولكن في محاولة رقمنة العمليات البشرية المعقدة والمتغيرة باستمرار للمؤسسات. لم تكن أخطائي الأكثر تكلفة في سطر من التعليمات البرمجية، ولكن في تلك اللحظات عندما أدركت أن سير العمل قال العميل "نعم، إنه يعمل تمامًا مثل هذا" لم يعمل في الواقع بهذه الطريقة على الإطلاق.
يتمثل جوهر نظام تخطيط موارد المؤسسات (ERP) في ربط جميع عمليات الشركة - بدءًا من الشراء وحتى الإنتاج، ومن الشحن إلى إعداد الفواتير. وهذا يتطلب أكثر بكثير من مجرد الانضمام إلى جداول قاعدة البيانات. من خلال خبرتي، تحتوي كل عملية من هذه العمليات على مجموعة من الاستثناءات وآليات الموافقة والمواقف غير المتوقعة.
منذ سنوات مضت، في نظام تخطيط موارد المؤسسات (ERP) للتصنيع، لاحظنا أن تقارير الشحن كانت غير مكتملة باستمرار. وبعد عملية تصحيح الأخطاء التي استمرت ثلاثة أيام، أدركنا أن المشكلة لم تكن في البرنامج نفسه، ولكن في نموذج الخروج اليدوي غير الرسمي الذي يستخدمه موظفو المستودعات في المواقف "العاجلة". لم يتمكن البرنامج من رؤية المنتجات التي مرت عبر هذا النموذج، وبالتالي العناصر المفقودة في التقارير. كان هذا مثالًا رائعًا لكيفية تأثير "الاختراق" التنظيمي على البرنامج.
تعتقد كل شركة أن طريقتها في أداء الأعمال فريدة من نوعها. يعد هذا أحد المواقف الأكثر شيوعًا التي أواجهها في مشروع تخطيط موارد المؤسسات (ERP). القواعد البسيطة التي تم وضعها في البداية تصبح محملة بالعشرات من الاستثناءات والسيناريوهات الخاصة مع مرور الوقت. كل استثناء يعني كتلة if-else جديدة في قاعدة التعليمات البرمجية، أو حقل قاعدة بيانات جديد، أو وحدة نمطية مختلفة تمامًا.