انتهاء صيانة SAP ECC في 31 ديسمبر 2027: قفزة في السعر، لا إيقاف للنظام

في 31 ديسمبر 2027، تنهي SAP الصيانة الأساسية لـ SAP ECC 6.0 وللتطبيقات الأساسية الأخرى في SAP Business Suite 7. لا شيء يتوقف في 1 يناير 2028. نظامك يواصل العمل، ومستخدموك يواصلون ترحيل الفواتير، وستظل SAP تبيعك الدعم. ما يتغير هو كم تدفع مقابله وما الذي تحصل عليه.

هذا الفرق مهم، لأن كثيراً من النصائح المتداولة يعامل 2027 كحافة هاوية. وبالنسبة لمعظم الشركات التي لا تزال على ECC، ليس الأمر كذلك، وهي تعرف ذلك: أكبر مجموعة من مستخدمي ECC المتبقين تخطط لعام 2030. والخطر الحقيقي مختلف. فالعمل الذي يحدد الموعد فعلاً (شيفرة ABAP المخصصة، والواجهات، والبيانات) يُقدَّر نطاقه متأخراً، فيتضح أن 2030 ضيق بقدر ما كان 2027.

هذا المقال لمديري تقنية المعلومات ومسؤولي SAP في الشركات متوسطة الحجم، ومعظمها في الأسواق الناطقة بالألمانية، ممن لا يزالون يشغّلون ECC وعليهم أن يقرروا شكل السنوات الثلاث المقبلة.

ما الذي التزمت به SAP فعلاً

الشروط منشورة في صفحة استراتيجية الصيانة لدى SAP، وأُعلنت أول مرة في فبراير 2020:

• حتى 31 ديسمبر 2027: صيانة أساسية للتطبيقات الأساسية في Business Suite 7، ومنها SAP ERP 6.0، على أحدث ثلاث حزم تحسين (enhancement packages). وإن كان نظامك على حزمة تحسين أقدم، فراجع SAP Note 2881788 (المرتبطة من تلك الصفحة) قبل أن تبني خطة على موعد 2027.
• من 1 يناير 2028 إلى 31 ديسمبر 2030: صيانة ممتدة اختيارية، مقابل "علاوة قدرها نقطتان مئويتان على أساس الصيانة". وببساطة، يرتفع معدل الصيانة الذي تدفعه اليوم بنقطتين.
• إن لم تختر الصيانة الممتدة: تنتقل تلقائياً إلى الصيانة الخاصة بالعميل (customer-specific maintenance). وما تغطيه موصوف في SAP Note 52505، المرتبطة من الصفحة نفسها. اقرأها قبل أن تفترض أنها كافية.
• بالنسبة لـ S/4HANA: التزمت SAP بالصيانة حتى نهاية 2040.

وهناك مسار إضافي لمجموعة أصغر. ففي أغسطس 2025 أعلنت SAP عن خيار الانتقال SAP ERP, private edition: اشتراك محدد المدة ينقل ECC من 2031 إلى 2033 داخل السحابة الخاصة لدى SAP. والشروط صارمة. "يجب ترحيل الأنظمة إلى SAP ERP, private edition على SAP HANA قبل 31 ديسمبر 2030." وHANA هي قاعدة البيانات الوحيدة المدعومة، ولا يُتاح الخيار إلا مع خطة max success للفترة من 2031 إلى 2033، وتحدد SAP حداً أدنى قدره 2 تيرابايت للأنظمة المشتركة بموجبه. وتقول SAP إنه مخصص "لأكبر عملاء SAP ERP وأكثرهم تعقيداً". أما "الشروط المكافئة تجارياً" التي عرضتها SAP فكانت للعملاء الذين التزموا بـ private edition بحلول نهاية 2025.

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

ماذا يفعل بقية السوق

أجرت DSAG، رابطة مستخدمي SAP الناطقين بالألمانية، تقرير الاستثمار 2026 بمشاركة 198 مستجيباً بين 8 ديسمبر 2025 و21 يناير 2026. ومن هؤلاء، لا يزال 54% يشغّلون ECC أو Business Suite الأقدم، انخفاضاً من 68% في 2024.

وبشأن التوقيت، يخطط نحو نصف المستجيبين للانتقال إلى S/4HANA بحلول نهاية 2030، وتشير DSAG إلى أن هذا يعني دفع ثمن الصيانة الممتدة. ويريد 37% آخرون الانتقال بحلول نهاية 2027، ولا يستهدف سوى 4% عام 2033 وخيار الانتقال إلى private edition.

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

والمشترون من القطاع العام يتحركون أيضاً. فإحصاؤنا لإشعارات المناقصات العامة في الاتحاد الأوروبي يجد نحو 200 إجراء لترحيل S/4HANA في كل نصف سنة خلال 2025 و2026، وأكثر من 300 في 2026 حتى بداية أكتوبر، معظمها في ألمانيا. العمل يجري. لكنه موزع على مدرج أطول مما توحي به عناوين 2027.

أين يقع العمل فعلاً

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

ويصبح مشكلتك بقدر ما بنيته بنفسك.

شيفرة ABAP المخصصة: حيث تنزلق المشاريع

S/4HANA ليس ECC على قاعدة بيانات جديدة. فأجزاء من نموذج البيانات تغيّرت. العملاء والمورّدون يصبحون شركاء أعمال (business partners). وقيود المالية والمخزون دُمجت في جداول أقل عدداً وأعرض. وبعض المعاملات والوظائف أُزيلت أو استُبدلت.

والشيفرة المخصصة التي تقرأ الجداول مباشرة، أو تعتمد على نقطة خروج (exit) انتقلت، أو تفترض ضمناً ترتيب فرز معيناً (HANA لا تَعِد بترتيب ما لم يطلبه الاستعلام) يمكن أن تجتاز فحص الصياغة وتفعل مع ذلك الشيء الخطأ. وهذا النوع الأخير هو الذي يؤلم، لأنه يظهر في اختبار التكامل أو بعد بدء التشغيل، لا في فحص الشيفرة.

العملية التي تنجح:

1. قِس الاستخدام أولاً. فعّل تسجيل الاستخدام في بيئة الإنتاج (مراقب استدعاءات ABAP، المعاملة SCMON) واتركه يعمل طوال إقفال نهاية سنة كامل. ففي الأنظمة طويلة العمر، كثيراً ما يكون جزء كبير من الكائنات المخصصة لا يعمل أبداً. والشيفرة التي لا ينفذها أحد تُحذف، لا تُرحَّل.
2. شغّل أدوات التحليل على ما تبقى. فحوص SAP تجد المشكلات المحتملة. لكنها لا تستطيع أن تخبرك أيها مهم للأعمال.
3. صنّف كل كائن. أوقفه، أو استبدله بوظيفة قياسية، أو أصلحه في مكانه، أو أعد بناءه خارج النواة. قرار واحد لكل كائن، مع مالك أعمال محدد بالاسم.
4. اختبر حسب العملية، لا حسب الكائن. تغيير الشيفرة هو الجزء الرخيص. أما إثبات أن دورة الطلب حتى التحصيل وإقفال نهاية الشهر لا تزالان تنتجان الأرقام نفسها فهو الجزء المكلف.

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

الواجهات، وPI/PO على الساعة نفسها

نادراً ما يقف ECC وحده. رسائل IDoc إلى المستودع، واستدعاءات RFC وBAPI من أرض المصنع، وملفات مسطحة إلى المصرف وإلى المستشار الضريبي، وبوابة عملاء تقرأ عرضاً في قاعدة البيانات أنشأه أحدهم عام 2011. كل واحدة منها يجب العثور عليها، واختبارها، وإعادة بنائها في بعض الحالات.

وإن كانت تلك الواجهات تمر عبر SAP Process Integration أو Process Orchestration، فهناك موعد ثانٍ على التواريخ نفسها. يقول مركز البنية لدى SAP إن PI/PO يقترب من "نهاية الصيانة القياسية في 2027"، وإن العملاء يستطيعون تمديد الصيانة حتى 2030، وإن دعم SAP ينتهي بعد ذلك. وتوجّه SAP عملاء PI/PO إلى SAP Integration Suite، الذي يأتي مع تقييم للترحيل وأدوات ترحيل قائمة على المعالجات الإرشادية.

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

ترحيل البيانات

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

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

وعلى أي من المسارين، أرشف ما لم تعد تحتاج إليه أولاً. بيانات أقل تعني عمليات تحويل أقصر ونافذة توقف أقصر.

امتدادات النواة النظيفة

الإغراء في مشروع يقوده موعد نهائي هو نقل كل تعديل والوعد بالترتيب لاحقاً. ولاحقاً لا يأتي.

اسم SAP للبديل هو النواة النظيفة (clean core): اترك النظام القياسي دون تعديل، وابنِ الامتدادات مقابل واجهات تنشرها SAP وتحافظ على ثباتها، إما داخل S/4HANA وإما إلى جانبه على SAP Business Technology Platform. لا يمكن أن يكون كل شيء نظيفاً من اليوم الأول. لكن القاعدة التي تستطيع الالتزام بها فعلاً أبسط: لا شيء جديد يُبنى بالطريقة القديمة. وكل تعديل تتجنبه الآن هو تعديل لن تعيد اختباره في كل ترقية مستقبلية.

إطار للقرار

هناك ثلاثة مسارات واقعية، ورابع يحظى باهتمام أقل.

بدء التشغيل على S/4HANA بحلول 31 ديسمبر 2027. يناسب الشركات التي بدأت بالفعل، وتشغّل نظاماً قياسياً في معظمه، وحجزت شريكاً. ومن اليوم يعني ذلك خمسة عشر شهراً، وقلة من فرق المالية ستقبل انتقالاً في منتصف إقفال نهاية السنة. وإن لم يكن تحليل الشيفرة المخصصة لديك قد أُنجز، فهذا على الأرجح ليس مسارك.

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

اختيار خيار الانتقال إلى private edition حتى 2033. يعني ذلك عقد RISE with SAP، وHANA، ونقل نظامك إلى SAP ERP, private edition قبل 31 ديسمبر 2030، وخطة max success، والحد الأدنى البالغ 2 تيرابايت. وبالنسبة لشركة متوسطة الحجم، نادراً ما يكون أرخص طريقة لشراء الوقت.

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

الأشهر الستة المقبلة، أياً كان اختيارك

من الآن حتى نهاية مارس 2027، كل ما يلي يؤتي ثماره على كل المسارات:

1. تأكد من نقطة انطلاقك. حزمة التحسين، وقاعدة البيانات، وعقد الصيانة. اطلب من فريق حسابك لدى SAP كتابةً شروط الصيانة الممتدة التي تنطبق عليك.
2. فعّل تسجيل الاستخدام الآن، حتى يلتقط إقفال نهاية 2026.
3. أجرِ تحليلاً للشيفرة المخصصة واخرج منه برقم، لا بانطباع: كم كائناً، وكم منها قيد الاستخدام، وكم منها يمس الأجزاء المتغيرة من نموذج البيانات.
4. ابنِ حصر الواجهات، بما في ذلك كل ما يمر عبر PI/PO، مع مالك وقرار لكل واجهة.
5. ابدأ تنقيح البيانات الرئيسية، العملاء والمورّدين أولاً.
6. توقف عن إضافة التعديلات. التطوير الجديد يتبع مبدأ النواة النظيفة من اليوم.
7. ضع زيادة الصيانة لعام 2028 في ميزانية 2027 كتكلفة معروفة لا كمفاجأة.
8. احجز القدرات: الشريك، وفريق SAP الداخلي لديك، والمطورين الذين يرعون الأنظمة المحيطة بـ SAP. فنقص المهارات أحد الأسباب التي يذكرها أعضاء DSAG لانزلاق الجداول الزمنية.

بالعد التنازلي من بدء تشغيل في 2030: دورات الاختبار وتمارين الانتقال في 2030، والبناء والمعالجة في 2029، والتصميم وتنقيح البيانات في 2028، والتحليل الآن. والهامش في ذلك أقل مما يبدو.

أين تحصل على المساعدة

لسنا شركة استشارات وظيفية في SAP ولا ندير تحويلات S/4HANA؛ بل نعمل إلى جانب الشريك الذي يديرها، على حصر الواجهات وإعادة بنائها، وشيفرة ترحيل البيانات ومطابقتها، والتطبيقات المبنية حول ECC التي يجب أن تنجو من الانتقال. هذا العمل موصوف في صفحة تحديث أنظمة ERP، وتغطي صيانة الأنظمة القديمة الأنظمة التي تبقى في مكانها حتى تنتقل. وإن أردت إحصاء المنظومة المحيطة بنظام ERP لديك قبل توقيع برنامج، راسلنا على office@c9group.dev.