10 أخطاء في تحديث ERP ينبغي تجنبها

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

هذا المقال لمديري تقنية المعلومات (CIO) والمديرين الماليين (CFO) ومديري البرامج الذين يخططون لتحديث S/4HANA أو أي تحديث آخر لنظام ERP أو ينقذونه. ويأتي كل خطأ أدناه مع شكله في الواقع العملي وطريقة إصلاحه، تليها قائمة مراجعة للإنذار المبكر في صفحة واحدة، وما تعنيه تغييرات SAP في 2026.

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

1. اعتبار التشغيل الفعلي خط النهاية

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

رأيت مشاريع تُحلّ فيها اللجنة التوجيهية فور التشغيل الفعلي. وبعد ستة أشهر يكون التبنّي راكداً ولا يملك أحد قائمة الأعمال المتراكمة.

الإصلاح: مَوِّل فترة حوكمة من 6 إلى 12 شهراً بعد التشغيل الفعلي. ومدِّد تفويض اللجنة التوجيهية. وراقب تبنّي العمليات، لا مدة التشغيل المتواصل فقط. وضع بوابات جودة بعد التشغيل الفعلي بأصحاب مسمّين.

2. نقل العمليات القديمة دون إعادة التفكير فيها

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

ونسخة S/4HANA من هذا: مهام دُفعات مخصصة نُقلت كما هي من ECC، مبنية على بنى جداول لم تعد موجودة. الانتقال سليم تقنياً. أما منطق الأعمال فمعطل.

الإصلاح: أعد تصميم العمليات قبل البناء. اجعل فرق العمليات والمالية والتسليم تستعرض كل مسار عمل معاً، وتساءل عن كل خطوة.

المجال القديم	ما الذي يسوء غالباً	ماذا تفعل بدلاً من ذلك
الشيفرة المخصصة من ECC	نقل شيفرة مخصصة غير مستخدمة إلى S/4HANA	شغّل تحليل الاستخدام وفحوصات الشيفرة المخصصة من SAP؛ وأحِل غير المستخدم إلى التقاعد
مسارات العمل القديمة	إعادة بناء مسارات الموافقات في حين صارت الأتمتة ممكنة	راجعها مع مالكي الأعمال؛ واستخدم تطبيقات Fiori القياسية أو SAP Build Process Automation
البيانات الرئيسية غير القياسية	الإعدادات القديمة المرنة تفشل في تحقق S/4HANA	نظّف ووائم قبل الانتقال، مع SAP MDG حيثما يناسب
التقارير على الجداول القديمة	الوصول المباشر إلى الجداول لا يطابق نموذج بيانات S/4HANA	أعد بناءها على CDS views
الحلول اليدوية الخفية	تعود العمليات الجانبية بعد التشغيل الفعلي	استخدم تنقيب العمليات (process mining) قبل الانتقال وارقمن الفجوات

3. البدء المتأخر في ترحيل البيانات

نقل بيانات سيئة إلى ERP جديد أشبه بالانتقال إلى منزل جديد دون التخلص من أي شيء. فالفوضى تنتقل معك، ويصعب تنظيفها حين تصبح داخل نظام منظم.

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

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

4. اعتبار إدارة التغيير مهمة جانبية

الصيغة المعتادة: إدارة التغيير «مُعالَجة أصلاً»، أي بضع شرائح وعرض توضيحي وجلسة تدريب واحدة قبل التشغيل الفعلي.

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

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

الإصلاح: امنح إدارة التغيير ميزانيتها وجدولها الزمني ومالكها الكبير منذ البداية. ارسم الأدوار مبكراً، وابحث عن الداعمين المحليين (champions)، وتابع مؤشرات التبنّي إلى جانب المراحل التقنية. ويبيّن دليلي لخطة إدارة التغيير البنية المطلوبة.

5. التخطيط بناءً على خرائط طريق الموردين

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

يبني الموردون خرائط الطريق لمجموعات واسعة من العملاء. ونادراً ما تكون شركتك محور ذلك التصميم.

الإصلاح: تعامل مع خريطة الطريق على أنها مدخل واحد. صمّم حول ما هو متاح للعموم اليوم، واختبر الميزات الجديدة في بيئة تجريبية (sandbox) قبل بناء الخطط عليها، وعُدّ منافع خريطة الطريق ميزة إضافية لا بنداً في الميزانية.

6. غياب خطة لإيقاف الأنظمة القديمة

رأيت مرة شركة تدفع مبلغاً من ست خانات سنوياً لإبقاء نظام قديم يعمل لستة مستخدمين يحتاجون إلى استخراج تقارير مرتين في السنة. ولم يضع أحد خطة لإيقافه.

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

7. التقليل من تعقيد التكامل

حين يفشل التكامل، تلاحظ الأعمال ذلك قبل تقنية المعلومات، لأن مسارات العمل تتوقف في منتصف العملية في بيئة الإنتاج، لا في نظام اختبار.

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

الإصلاح: ابدأ تصميم التكامل في مرحلة المخطط التفصيلي (blueprint). عرّف كل سيناريو، والبرمجية الوسيطة، والتعيين (mapping)، وأحجام الرسائل، ووضّح مع الأعمال هل كل واجهة آنية (real-time) أم دُفعية (batch). وعيّن مالكاً لكل واجهة باتفاقية مستوى خدمة (SLA) قبل التشغيل الفعلي. وفي برامج SAP الجديدة تكون البرمجية الوسيطة هي SAP Integration Suite؛ أما SAP PI/PO فتخرج من الصيانة الأساسية في نهاية 2027.

8. افتراض أن ERP يستطيع التعامل مع كل شيء

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

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

الإصلاح: قرر عن عمد ما لا ينبغي بناؤه في ERP. استخدم امتدادات جنباً إلى جنب (side-by-side) على SAP BTP للاستثناءات، واستخدم ServiceNow أو ما يشبهه للتنسيق خارج النواة المعاملاتية. ويتناول مقالي عن تحديث ERP مع SAP وServiceNow هذا الفصل.

9. التقليل من كلفة التراخيص على المدى الطويل

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

تُحاسب تراخيص ERP على المستخدمين والوحدات والمعاملات واستخدام واجهات API، وتتصاعد الكلفة مع نمو الأعمال سواء خططت لذلك أم لا. وفي SAP يعني نموذج Digital Access أن المستندات التي تنشئها أنظمة الأطراف الثالثة قد تحمل كلفة ترخيص لم تكن في النموذج التجاري الأصلي. وفي RISE وSAP GROW تنمو أعداد مكافئ المستخدم الكامل (FUE) مع التبنّي.

الإصلاح: ابنِ نموذجاً للتراخيص يمتد من ثلاث إلى خمس سنوات قبل التوقيع. اربط الأدوار بأنواع التراخيص، وأنمذج نمو FUE على منحنى تبنٍّ واقعي، وافهم الوصول غير المباشر (indirect access) قبل ربط الأنظمة الخارجية، ودقّق المستخدمين غير النشطين بعد التشغيل الفعلي.

10. اعتبار ERP مشروع تقنية معلومات

النمط الأكثر شيوعاً والأشد ضرراً. يبدأ التخطيط في تقنية المعلومات، وتقوده تقنية المعلومات، ويحل مشكلات تقنية المعلومات.

رأيت فرقاً تحقق كل مرحلة على الورق بينما ما زالت الأعمال تسأل لماذا لا يبدو أي شيء أفضل. وهذا يعني عادة أن ERP بُني لعمليات الأمس، دون قادة العمليات أو المالية أو الجانب التجاري في التصميم.

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

استخدمها في كل اجتماع للجنة التوجيهية. وإذا ظهرت علامة إنذار، يقدّم المالك المسمّى تقريراً عنها إلى أن تزول.

1. الميثاقالملكية والكلفةلا قائد للعمليات أو المالية، ولا نموذج تراخيص لخمس سنوات، ولا موعد لإيقاف الأنظمة القديمة
2. المخطط التفصيليتصميم العمليات والتكاملنسخ عملية اليوم، وواجهات لم تُصمَّم بعد
3. أول تحميل تجريبيالبياناتلا تقرير لجودة البيانات بعد
4. التشغيل الفعليما يحدث بعدهلا حوكمة ممولة للأشهر الـ12 التالية

الخطأ	علامة الإنذار المبكر	المالك
1. التشغيل الفعلي خط نهاية	لا خطة حوكمة ممولة للأشهر الـ12 بعد التشغيل الفعلي	الراعي
2. نسخ العمليات القديمة	تبدأ ورش التصميم من شاشات «كيف نفعلها اليوم»	مالكو العمليات
3. التأخر في أعمال البيانات	لا تقرير لجودة البيانات قبل أول تحميل تجريبي	قائد ترحيل البيانات
4. التغيير مهمة جانبية	خطة التغيير مجرد جدول تدريب	قائد التغيير
5. الاعتماد على خريطة الطريق	قرار تصميم ينتظر ميزة لم تُطرح بعد	معماري الحلول
6. غياب إيقاف الأنظمة	لا موعد لإحالة أي نظام قديم إلى التقاعد في الميثاق	PMO
7. التقليل من التكامل	واجهات لم تُصمَّم بنهاية المخطط التفصيلي	قائد التكامل
8. ERP لكل شيء	كائنات مخصصة لمسارات عمل غير معاملاتية	معماري المؤسسة
9. التراخيص	لا نموذج تراخيص لخمس سنوات في دراسة الجدوى	المدير المالي
10. برنامج لتقنية المعلومات وحدها	لا قائد للعمليات أو المالية في اللجنة التوجيهية	الراعي

النشر. في برامج SAP الجديدة يكون الخيار الافتراضي RISE with SAP على SAP Cloud ERP Private، أو SAP GROW على الإصدار العام (SAP Cloud ERP) للشركات المتوسطة. وعمليات النشر المحلية الجديدة نادرة. ويواجه عملاء ECC انتهاء الصيانة الأساسية في 31 ديسمبر 2027، مما يقصّر الوقت المتاح لإصلاح الأخطاء 2 و3 و7.

Clean Core. تصنّف SAP الامتدادات الآن على أربعة مستويات في Clean Core، من A (واجهات API المُصدَرة فقط، جنباً إلى جنب على BTP أو داخل النظام مع ABAP Cloud) إلى D (غير نظيف). ولا يسمح الإصدار العام إلا بالمستوى A، وهذا يفرض النقاش الكامن وراء الخطأ 2. أما الإصدار الخاص فما زال يسمح بالامتدادات التقليدية، لذا يجب أن يأتي الانضباط من الحوكمة. فالشيفرة المخصصة التقليدية هي ما يجعل كل ترقية مشروعاً. ويذهب مقالي عن استراتيجية Clean Core أبعد من ذلك.

الذكاء الاصطناعي في أدوات التسليم. يوجد Joule الآن في SAP Cloud ALM وفي SAP Activate Roadmap Viewer، ويستخدم SAP Build Code مساعد Joule في تطوير الامتدادات. اسأل الشركاء كيف تنعكس أدوات الذكاء الاصطناعي في جدول أسعارهم. فإن لم تنعكس، فإما أن السعر مرتفع أو أن الوفر يذهب إلى هامش ربحهم.

أدوات إدارة دورة الحياة. SAP Cloud ALM هي أداة إدارة دورة الحياة لبرامج السحابة. وتخرج Solution Manager 7.2 من الصيانة الأساسية في نهاية 2027، لذا تحتاج البيئات التي تشغّل الأداتين معاً إلى خطة للانتقال.

الأخطاء العشرة لم تتغير. لكن كلفة ارتكابها تغيّرت. ففي برنامج RISE تُحسم قرارات Clean Core ونموذج النشر ونموذج FUE كلها في الأسابيع الأولى من إطلاق البرنامج. ونافذة التأثير فيها قصيرة.

لماذا تخفق جهود تحديث ERP بعد التشغيل الفعلي؟

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

ما خطر نسخ العمليات القديمة إلى ERP جديد؟

يرث النظام الجديد أوجه القصور القديمة بكلفة أعلى. وفي عمليات الانتقال إلى S/4HANA تحديداً، كثيراً ما لا تعمل الشيفرة المخصصة ومهام الدُّفعات المبنية على جداول ECC، فيمكن أن يكون الانتقال سليماً تقنياً بينما منطق الأعمال معطل.

كيف تضر جودة البيانات الضعيفة بتحديث ERP؟

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

لماذا يُقلَّل من شأن إدارة التغيير في مشاريع ERP كثيراً؟

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

لماذا تستمر الأنظمة القديمة في العمل سنوات بعد التشغيل الفعلي لنظام ERP؟

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

كيف يغيّر RISE with SAP وClean Core هذه الأخطاء؟

في الإصدار العام تجعل قواعد Clean Core التخصيص العميق مستحيلاً، وهذا يفرض نقاش العمليات الكامن وراء الخطأ 2. وفي الإصدار الخاص ما زالت الامتدادات التقليدية مسموحة، لذا يعتمد Clean Core على الحوكمة. ويتحول التكامل إلى SAP Integration Suite مع انتهاء صيانة PI/PO. ويصبح الترخيص مسألة نمو FUE. ويصبح إيقاف الأنظمة القديمة أكثر إلحاحاً لأن تشغيلها بالتوازي يضيف كلفة فوق اشتراك متعدد السنوات.