تطوير نظام ERP القائم
حيث تكون الوظائف الأساسية كافية، تُستكمل العمليات الناقصة بالتطوير أو التكامل أو تطبيقات محيطة.
تحليل العمليات والاختيار والتطبيق والتطوير وترحيل البيانات والتكامل ضمن منظومات ERP متعدّدة. وتطوير النظام الذي تشغّلونه حاليًا أحد الخيارات.
احجزوا تحليل احتياجات ERP ↗تُحدَّد المنظومة التي يجري فيها العمل حسب بنيتكم القائمة وما يحتاجه المشروع.
حيث تكون الوظائف الأساسية كافية، تُستكمل العمليات الناقصة بالتطوير أو التكامل أو تطبيقات محيطة.
حيث لا يستطيع النظام الحالي تلبية الحاجة وظيفيًا أو تقنيًا أو تشغيليًا، تُوزن البدائل أمام صورة مقيسة.
يُحافَظ على نواة ERP؛ وتُحلّ العمليات المتباعدة حولها بتطبيقات B2B أو WMS أو نقاط بيع أو تطبيقات محمولة أو مخصّصة.
لا يتوقّف نجاح مشروع ERP على البرنامج المختار وحده. فالنمذجة الصحيحة لعمليات العمل، وموثوقية البيانات، وبناء معمارية التكامل بشكل سليم، وتهيئة المستخدمين للنظام، واستدامة ما يُطوَّر عليه، كلّها عوامل لا تقلّ حسمًا عن اختيار المنتج.
لذلك ليس سؤالنا الأول عند بدء أيّ مشروع «أيّ نظام ERP ينبغي أن تشتروا؟». بل نبحث أولًا عن إجابات هذه الأسئلة:
وينتهي هذا التحليل عادةً إلى واحد من ثلاثة مسارات.
إذا كانت الوظائف الأساسية للنظام كافية، فقد يكون استكمال العمليات الناقصة بالتطوير أو التكامل أو التطبيقات المحيطة هو الاستثمار الأصحّ. وفي هذه الحالة تبقى بنية السجلّات الأساسية محفوظة ويظلّ الخطر محصورًا في نطاق ضيّق.
إذا كان النظام الحالي لا يلبّي حاجة المنشأة وظيفيًا أو تقنيًا أو تشغيليًا، تُدرَس بدائل ERP الجديدة. وينبغي أن يستند هذا القرار إلى جدول مقيس، لا إلى شكوى واحدة.
يُحافَظ على نواة ERP بينما تُوضَع العمليات الخاصّة بالمنشأة حول النظام عبر تطبيقات B2B أو WMS أو نقاط البيع أو تطبيقات الهواتف أو تطبيقات مخصّصة. تبقى النواة قياسية، وتُحلّ العملية المختلفة في موضعها.
النتيجة الصحيحة عندنا ليست دائمًا «غيّروا نظام ERP». فإذا أظهر التحليل أنّ النظام الحالي قابل للتطوير، قلنا ذلك صراحةً.
تغيير ERP قرار عالي الأثر: تتغيّر البيانات والعمليات وعادات المستخدمين وعمليات التكامل كلّها في وقت واحد. ولا بدّ قبل الانتقال إلى نظام جديد من قياس ما إذا كان نظام ERP الحالي قد بلغ حدّه فعلًا.
قد يكون تطوير النظام الحالي منطقيًا:
وقد يصبح التحوّل إلى ERP جديد خيارًا أقوى:
ونشرح تفصيل إطار القرار في دليل اختيار ERP.
نحلّل العمليات القائمة على مستوى كلّ قسم؛ ونفصل بين المجالات التي تُلبّى بوظيفة قياسية، وتلك التي تحتاج إلى إعداد، وتلك التي تحتاج إلى تطوير، وتلك التي تُحلّ بالتكامل.
والمخرَج ليس عرضًا تقديميًا فحسب: بل عمل يصلح أساسًا لنطاق المشروع ومعايير القبول، ويمكن أن يُدرج ملحقًا بالعقد.
لا نقارن بدائل ERP من خلال شاشات العروض التوضيحية وحدها. بل نصنّف عمليات العمل الحرجة والمتطلّبات التقنية بحسب درجة الأهمية؛ ثمّ نقيّم كيف تلبّي الأنظمة المرشّحة هذه المتطلّبات بوظيفة قياسية أو إعداد أو تطوير أو تكامل.
والعناوين التي تُدرس معًا في التقييم:
| مجال التقييم | ما الذي يُنظر فيه |
|---|---|
| التوافق الوظيفي | نسبة تلبية العمليات الحرجة ضمن النطاق القياسي |
| عمق التصنيع | مدى ملاءمة بنية المنتج والعمليات والتخطيط ونموذج التكلفة للمنشأة |
| المالية | المحاسبة، ومحاسبة التكاليف، وإقفال الفترة، والامتثال التنظيمي |
| قدرة التكامل | واجهات API والخدمات والملفّات وطرق الوصول إلى البيانات؛ ووضع الترخيص لهذا الوصول |
| نموذج البيانات | بنية البيانات الرئيسية، وتعدّد الوحدات، والتتبّع، والعمق التاريخي |
| التقارير | التقارير القياسية، وإمكان إنشاء تقارير خاصّة، والانفتاح على مستودع البيانات |
| قابلية التوسّع | نمو المستخدمين وحجم العمليات والشركات والمواقع |
| الأمان والصلاحيات | نموذج الأدوار، والصلاحية على مستوى السجلّ، وأثر التدقيق |
| نموذج الاستخدام | سحابي أو داخلي أو مختلط؛ ومدى تحمّل الانقطاع |
| الترخيص والتكلفة الإجمالية | نموذج الترخيص، والزيادة السنوية، وإجمالي التكلفة على خمس سنوات |
| الحاجة إلى التطوير | عدد البنود الخارجة عن النطاق القياسي وأسلوب معالجتها |
| استدامة ترقية الإصدار | كيفية الحفاظ على التخصيصات عند ترقية الإصدار |
| الشريك والمنظومة | توافر الاستشاريين، والتوثيق، ومجتمع المستخدمين |
| خطر المشروع | غموض النطاق، وجودة البيانات، وقدرة الفريق |
والغاية ليست إيجاد «نظام ERP الحاصل على أعلى درجة»، بل تحديد البنية القادرة على تلبية العمليات الحرجة للمنشأة بشكل مستدام وبتكلفة وخطر مقبولين.
لا نعدّ علامة ERP واحدة صحيحة لكلّ منشأة. فنحن ننفّذ أعمال تكييف العمليات والتكامل والتقارير وسير العمل وتحويل البيانات والتطوير في منظومات ERP مختلفة بحسب حاجة المشروع، منها CANIAS وAinos ERP وSAP وKovan ERP وOracle.
ومهما كانت المنظومة نطبّق الانضباط نفسه: كلّ تخصيص يخرج عن النطاق القياسي يُوثَّق، ويُسجَّل أثره على ترقية الإصدار. فدَين التخصيص من أكثر الأسباب شيوعًا في تعطيل الترقية بعد سنوات.
ونقارن في مقال البدائل في منظومة ERP أيّ المنتجات أجدر بالدفاع عنه في أيّ ظرف.
الغاية في مشاريع ERP التصنيعية ليست فتح أمر إنتاج فحسب؛ بل يجب أن يكون الإنتاج المخطَّط وبيانات الاستهلاك والعمليات الفعلية قابلَين للمتابعة على النموذج نفسه.
ونمذج داخل نظام ERP بحسب الحاجة مكوّنات شجرة المنتج أو الوصفة، والمسار والعملية، وبنية مركز العمل أو المورد، واستهلاك المواد، وأزمنة العمالة والآلات، والهدر وإعادة التشغيل، والعمليات المسندة إلى الغير، وتتبّع اللوط أو الرقم التسلسلي، والطاقة الإنتاجية، وMRP، والجودة، وتكلفة الإنتاج، وذلك بحسب نمط التصنيع في المنشأة. ولا تحتاج كلّ منشأة إلى هذه المكوّنات كلّها؛ فالمسار البديل أو العملية المسندة إلى الغير لا تُبنى إلّا إذا كانت مستخدمة فعلًا.
ولا نفرض أسلوبًا واحدًا في نموذج التكلفة. فالتكلفة المعيارية، والتكلفة الفعلية، وتكاليف النشاط والآلة والعمالة، وأسلوب توزيع المصاريف العامّة، كلّها تُصمَّم معًا بحسب النموذج المحاسبي والإنتاجي للمنشأة. والتفصيل في دليل ERP لشركات التصنيع.
لا يتحدّد نطاق ترحيل البيانات بسؤال «كم سنة من البيانات ستُنقل؟». بل نتناول البيانات المنقولة في ثلاث فئات:
وإعادة بناء البيانات التاريخية في النظام الجديد ممكنة في بعض الحالات؛ غير أنّ جودة البيانات المصدرية ونقصها قد يحدّان من صحّة النتيجة. لذلك يُتّخذ في بداية المشروع قرار هل تُنقل أم تُؤرشَف أم تُحوَّل أم يُحتفظ بها للتقارير فقط لكلّ مجموعة بيانات، ويُعرَّف أسلوب التحقّق كتابةً.
لا يعمل نظام ERP وحده في معظم المنشآت. فقد يلزم تدفّق بيانات بين البنك، والفاتورة وإشعار التسليم الإلكترونيَّين، وبوابة الموزعين B2B، ونقاط البيع بالتجزئة، وWMS، وقنوات التجارة الإلكترونية والأسواق، ونظام إدارة علاقات العملاء، والمبيعات الميدانية، وتسجيل الحضور والانصراف، وMES، وآلات الإنتاج، والموازين، وخدمات الأطراف الثالثة.
ولا نركّز في تصميم التكامل على إنشاء الاتصال وحده؛ بل على ملكية السجلّ، وإدارة الأخطاء، ومنع الطلبات المعادة من إنتاج سجلّات مكرّرة، والمطابقة، والصلاحيات، والسجلّات، وإعادة المحاولة، وقابلية المتابعة التشغيلية. ونشرح الأسلوب في صفحة تكامل واجهات API وفي دليل التكامل البنكي.
في البنى متعدّدة الشركات، لا يعني استخدام جميع الشركات نظام ERP نفسه أنّ التوحيد المالي قد تحقّق. ويُدرَس ضمن نطاق المشروع وبحسب الحاجة: دليل حسابات مشترك أو منفصل، وإدارة موحّدة للبيانات الرئيسية، والبيع والشراء بين الشركات، والأرصدة، والعمليات داخل المجموعة، وعملة التقارير، ومتطلّبات الاستبعاد، وتقارير الإدارة، والتوحيد المالي.
وقد لا تكفي في بعض البنى وظائف ERP نفسها للتوحيد المالي أو لتقارير الإدارة؛ وفي هذه الحالة نوضّح في بداية المشروع صراحةً أنّ طبقة تقارير إضافية قد تكون لازمة.
عدم الحصول على العائد المنتظر من نظام ERP لا يعني دائمًا أنّ المنتج قاصر. فالمشكلة تعود أحيانًا إلى تصميم عمليات خاطئ أو ناقص، أو بيانات رئيسية غير كافية، أو عمل يدوي لا لزوم له، أو بنية التقارير، أو نواقص التكامل، أو مشكلة أداء، أو صلاحيات خاطئة، أو ضعف تأقلم المستخدمين.
لذلك نقيّم النظام الحالي تقنيًا ووظيفيًا قبل اتخاذ قرار بنظام ERP جديد. وإذا كان الاستثمار القائم قابلًا للتطوير، أوصينا بذلك صراحةً.
لا نضع الذكاء الاصطناعي بديلًا عن قواعد العمل القابلة للتحقّق في سجلّات المالية والمخزون والتكلفة الخاضعة للتدقيق داخل ERP. أمّا في سيناريوهات الاستخدام المناسبة فنستخدمه بصورة منضبطة: تصنيف المستندات، وتحليل وصف الإشعار البنكي، والتنبّؤ بالطلب، وكشف الحالات الشاذّة، والتقارير باللغة الطبيعية، والمساعدة الإدارية، ودعم القرار.
وفي السيناريوهات التي تتحوّل فيها نتيجة منتَجة بالذكاء الاصطناعي إلى قيد مالي أو تشغيلي، تُصمَّم آلية تحقّق وصلاحيات إضافية: يُحدَّد من البداية تحت أيّ عتبة تُعالَج تلقائيًا، ومن يعتمدها، وكيف يمكن التراجع عن النتيجة.
قيمة الترخيص بند واحد فقط من التكلفة الإجمالية. وقد تنشأ بحسب بنية المشروع البنود الآتية: الترخيص أو الاشتراك، والبنية التحتية أو السحابة، والتحليل، والاستشارات، والإعداد، والتطوير، والتكامل، وتنظيف البيانات، وترحيل البيانات، والاختبار، والتدريب، ووقت فريق المشروع الداخلي، والإطلاق، والدعم المكثّف، والصيانة والدعم، وترقية الإصدار، وتراخيص الأطراف الثالثة. وإذا لزم التشغيل المتوازي، فإنّه يُدرَج بندًا مستقلًّا في الموازنة.
ولا يتساوى وزن البنود في كلّ المشاريع: ففي بعضها يكون الترخيص بندًا مهمًّا، بينما في المشاريع التي تتطلّب تخصيصًا كثيفًا أو تحويل بيانات أو تكاملًا واسعًا قد يبلغ وزن التنفيذ والعمالة الداخلية ضمن التكلفة الإجمالية مستوى مماثلًا أو أعلى.
ونشرح الحساب بندًا بندًا في مقال كيف تُحسب تكلفة ERP؛ ويمكنكم استخدام أداة التقييم الأوّلي لاستثمار ERP والتكلفة الإجمالية لاستخراج درجة التعقيد وقائمة البنود بحسب نطاقكم.
نبدأ التقييم من واقع عمليات المنشأة وبياناتها، لا من مقارنة المنتجات.
لا نترك خارطة الطريق الناتجة عن تحليل العمليات تقريرًا فحسب. فنحن قادرون على تنفيذ الأعمال التقنية اللازمة تحت مظلّة المشروع نفسها، بما فيها إعداد ERP والتطوير والتكامل وترحيل البيانات والتطبيقات المحيطة. وبذلك لا يتحوّل التحليل والتنفيذ إلى مشروعين منفصلين يتبادلان اللوم.
عند الحاجة إلى تطبيق B2B أو نقاط بيع أو ربط بنكي أو تطبيق للهواتف أو WMS أو تطبيق خاصّ بالمنشأة، نستطيع بناء المعمارية المحيطة بنظام ERP أيضًا. وهذه الأعمال ليست عندنا خارج مشروع ERP.
لا نتعامل مع ERP باعتباره تطبيق مالية ومحاسبة فحسب؛ بل يقع نموذج التصنيع وجمع البيانات ومعمارية التكامل في قلب المشروع.
إذا لم يكن نظام ERP جديد لازمًا، فإنّ تطوير النظام الحالي أحد خيارات المشروع، ونقول ذلك ولو كلّفنا خسارة المشروع.
التوثيق، وتدريب المستخدمين الرئيسيين، ووثيقة التكامل، وسجلّات التغيير، وملكية البيانات، وبنية الأدوار والصلاحيات، كلّها تجعل المشروع قابلًا للتسلّم. ونوصي بأن تُعرَّف بوضوح في مرحلة العقد شروطُ ملكية البيانات ونطاق التطوير وحقوق الوصول والتوثيق وقابلية التسلّم.
الأغذية والمشروبات، والبلاستيك، والمعادن والآلات، والتغليف، والطباعة، والنسيج، والأثاث، والتجزئة متعدّدة الفروع، والرعاية الصحية، والمصارف والتمويل. ولكلّ قطاع قدرة حرجة مختلفة ينتظرها من ERP؛ وقد كتبناها بندًا بندًا في صفحات القطاعات.
وتجدون تقييم شركة الاستشارات كاملًا في مقال كيف تُختار شركة استشارات ERP.
لسنا مرتبطين بمنتج ERP واحد. فنحن ننفّذ مشاريع استشارات وتطوير وتكامل وتحوّل في منظومات ERP مختلفة، منها CANIAS وAinos ERP وSAP وKovan ERP وOracle. ويُحدَّد نطاق المشروع والأسلوب المستخدم بحسب النظام الحالي للمنشأة واحتياجاتها.
نعم. فاستشارات ERP لا تعني تركيب نظام جديد فحسب. إذ ننفّذ كذلك أعمال تحليل العمليات والتكامل والتطوير والتقارير ونموذج البيانات وتحسين الأداء على نظام ERP القائم.
لا نتّخذ القرار بناءً على مشكلة واحدة. بل نقيّم معًا التوافق الوظيفي، والاستدامة التقنية، وقدرة التكامل، واحتياجات المستخدمين، وعبء التطوير، والتكلفة الإجمالية للملكية، وأهداف النمو.
تتغيّر مدّة المشروع بحسب عدد الشركات، وعدد المستخدمين، ونطاق الوحدات، وتعقيد التصنيع، وعمليات التكامل، وترحيل البيانات، والحاجة إلى تطوير خاصّ. لذلك ينبغي أن يُوضع تقدير سليم للمدّة بعد تحليل العمليات والنطاق. وحين تطلبون التزامًا بالمدّة، تأكّدوا من تثبيت النطاق كذلك.
ليس دائمًا. فالبيانات الرئيسية والعمليات المفتوحة والبيانات التاريخية ينبغي تقييمها على حدة. وقد يكون الأصحّ في بعض البيانات التاريخية الاحتفاظ بها في بيئة أرشيف أو تقارير بدل نقلها إلى نظام ERP الجديد.
لا. يُحدَّد أسلوب الانتقال بحسب خطر المشروع. ويمكن استخدام الأنسب من بين التشغيل المتوازي أو التجربة الاسترشادية أو الانتقال على مراحل أو التحويل المُحكَم.
لا. فقد يكون التطوير الخاصّ لازمًا في العمليات التي تحقّق قيمة فعلية للمنشأة. والمهمّ هو توثيق التطويرات، ومعرفة أثرها على ترقية الإصدار، وتنفيذها بشكل مستدام بالأساليب التي تدعمها المنصّة.
لا يوجد معيار واحد. فالتوافق الوظيفي، والمعمارية التقنية، والتكامل، والتكلفة الإجمالية، ومنظومة التنفيذ، والاستدامة، ينبغي تقييمها معًا.
بنسخة احتياطية كاملة قبل الانتقال، وبالتحقّق من ترحيل البيانات بمجاميع التحقّق، وبعدم الانتقال قبل استيفاء معايير القبول، وبخطّة تراجع مكتوبة. وقد تكون التجربة الاسترشادية أو الانتقال على مراحل جزءًا من هذا الضبط بحسب خطر المشروع.
نقدّم تدريبًا قائمًا على الأدوار: كلّ دور يتعلّم شاشاته وحدها. كما نؤهّل بنموذج المستخدم الرئيسي أشخاصًا من داخل المؤسسة يحملون النظام لاحقًا. وهذا مهمّ حتى لا تبقى المؤسسة معتمدة على الاستشاري في كلّ تغيير صغير بعد ذلك.
لننظر معًا في نظامكم الحالي ونقاط الاختناق وأهدافكم. في المكالمة الأولى، وقبل الحديث عن المنتجات، نحدّد أي مشكلة تحتاج إلى حل.
احجزوا تحليل احتياجات ERP → أداة التقييم الأولي لاستثمار ERP والتكلفة الإجمالية ↗ دليل اختيار ERP ↗
مكالمة استكشاف تقني
اتركوا بياناتكم واختاروا يومًا يناسبكم؛ سنعود إليكم للتأكيد. في المكالمة نستمع إلى نظامكم الحالي ونقطة الاختناق وهدفكم. لا رسوم على المكالمة الأولى.
تم استلام طلبكم.