استراتيجية SAP Clean Core: ما تعنيه، والمستويات من A إلى D، والحوكمة

يعني SAP Clean Core أن تُبقي نظام S/4HANA لديك قريبًا من معيار SAP بالقدر الذي تسمح به أعمالك. وكل ما تضيفه يُبنى عبر واجهات أصدرتها SAP رسميًا والتزمت بإبقائها مستقرة، حتى لا تكسره الترقيات.

الإجابة المختصرة: Clean Core انضباط في طريقة توسيع SAP وحوكمته. يوضع المنطق المخصص on-stack باستخدام ABAP Cloud أو side-by-side على SAP BTP، وتصنّف SAP كل امتداد من المستوى A (الأنظف) إلى المستوى D (تعديلات يجب إزالتها). والعائد ترقيات أسرع: رأيت شركات تختصر مدة الترقية بنسبة 40% بهذه الطريقة.

إذا كان نظامك مليئًا بالتعديلات على كائنات SAP القياسية، يصبح كل إصدار جديد مشروع اختبار انحدار (regression). وإذا كان منطقك المخصص يقع خلف واجهات مُصدَرة رسميًا، تصبح الترقيات صيانة روتينية.

رأيت شركات تختصر مدة الترقية بنسبة 40% بتطبيق مبادئ Clean Core. فعلت ذلك بإبقاء التخصيصات عند الحد الأدنى وإخضاع ما أبقته منها للحوكمة.

في عام 2024 استبدلت شركة أوروبية للسلع الاستهلاكية منطق التسعير القديم لديها بتطبيق Fiori معياري بُني خارج النواة على SAP BTP. وألغى ذلك اختبار الانحدار لهذا المنطق بالكامل.

لا يزال بإمكانك تخصيص نظام ERP يلتزم بـ Clean Core. لكن التخصيص يجب أن يستخدم واجهات أصدرتها SAP رسميًا والتزمت بإبقائها مستقرة. وتقدّم SAP طريقتين لذلك:

• On-stack، باستخدام ABAP Cloud. تعمل الامتدادات داخل S/4HANA، لكنها لا تستخدم إلا واجهات API المُصدَرة ونقاط التوسعة.
• Side-by-side، على SAP BTP. تعمل الامتدادات كتطبيقات منفصلة وتتواصل مع S/4HANA عبر واجهات API أو الأحداث (events).

تصف SAP نهجها بأنه BTP-first، مع الاختيار حسب كل حالة استخدام. ومن خبرتي، فإن مكان تشغيل الكود أقل أهمية من سؤال آخر: هل يحتاج المتطلب إلى كود أصلًا؟

النواة «غير النظيفة» مألوفة لكل من شغّل ECC: برامج قياسية معدّلة، وجداول Z يُكتب فيها مباشرة، وواجهات تقرأ البنية الداخلية لـ SAP، وتحسينات ضمنية لم يوثّقها أحد. لم يكن شيء من ذلك خطأ عندما بُني. لكنه لم يُبنَ لنظام يُرقّى كل عام أو عامين.

أتناول هذا الموضوع أيضًا في مقطع فيديو على قناتي في YouTube (باللغة الإنجليزية).

تنظّم SAP مفهوم Clean Core حول خمسة مبادئ توجيهية. هكذا تصف SAP كل مبدأ، وهذا ما أنظر إليه أولًا:

المبدأ	ما تقصده SAP	ما أتحقق منه أولًا
العمليات	البقاء أقرب ما يمكن إلى عملية SAP القياسية	أي صيغ للعمليات موجودة فقط لأننا «اعتدنا دائمًا على ذلك»
قابلية التوسعة	امتدادات منفصلة عن النواة عبر واجهات API مُصدَرة، مع حوكمة لاختيار الخيار المستخدم	كم يوجد من الكود المخصص، وكم يُستخدم منه، وفي أي مستوى يقع
البيانات	بيانات نظيفة وممتثلة ضمن نموذج حوكمة قائم	بيانات رئيسية مكررة وناقصة، وحقول مخصصة لا يستطيع أحد تفسيرها
التكاملات	اتصالات موحّدة وآمنة مبنية على تقنيات مدعومة	واجهات point-to-point تقرأ الجداول مباشرة
التشغيل	الحوكمة والأشخاص والعمليات والأدوات التي تحافظ على المبادئ الأربعة الأخرى	من يوافق على الامتداد، وما الذي يمنع التعديل التالي

تبدأ معظم الفرق بقابلية التوسعة وتنتهي بها، لأنها الأسهل في القياس. ومن خبرتي، تسبب العمليات والبيانات تأخيرًا أكبر. فالكود المخصص عادة هو العَرَض، والعملية التي خلفه هي السبب.

في أغسطس 2025 استبدلت SAP نموذج التوسعة السابق ذا الطبقات الثلاث بـ مفهوم مستويات Clean Core. يُقيَّم كل امتداد بحسب طريقة بنائه، ومدى انفصاله عن النواة، ومدى أمان بقائه بعد الترقية. وإذا قرأت موادّ قديمة من SAP تتحدث عن الطبقات (tiers)، فهذا هو ما حلّ محلها.

المستوى Aالمستوى Bالمستوى Cالمستوى D

ما الذي يستخدمهالمستوى Aواجهات مستقرة ومُصدَرة علنًا فقطالمستوى Bأيضًا واجهات API الكلاسيكية من SAPالمستوى Cكائنات SAP الداخليةالمستوى Dتعديلات، وكتابة في جداول SAP، وتحسينات ضمنية

خطر الترقيةالمستوى Aالأدنى، مدعوم بعقود استقرارالمستوى Bمستقر عمومًا عند الترقيةالمستوى Cيحتاج إلى فحص في كل ترقيةالمستوى Dالأعلى

ما الذي تقررهالمستوى Aالخيار الافتراضي لكل جديدالمستوى Bيُقبل مع تسجيل السببالمستوى Cيُقبل مع سبب، ويُعاد فحصه في كل ترقيةالمستوى Dيُزال أولًا، أو يُنقل إلى B أو C

المصدر: مفهوم مستويات Clean Core من SAP، SAP News، أغسطس 2025

لا يستخدم المستوى A إلا واجهات مُصدَرة علنًا تدعمها عقود استقرار، وتُبنى باستخدام SAP Build أو ABAP Cloud أو BTP. ويضيف المستوى B واجهات API الكلاسيكية من SAP. أما المستوى C فيلمس كائنات SAP الداخلية، وتخطط SAP لسجل تغييرات (changelog) لهذه الكائنات للمساعدة في تخطيط الترقيات.

المستوى D هو التعديلات، والكتابة في جداول SAP، والتحسينات الضمنية، وغيرها من الأساليب التي لا توصي بها SAP. وهذا أنفع من الجدل القديم «نظيف أو غير نظيف»، لأنه يتيح لك تحديد هدف لكل كائن. ونقل كائنات المستوى D إلى B أو C قبل الترقية هو في حد ذاته خفض حقيقي للمخاطر.

ABAP Cloud هو نموذج تطوير ABAP الجاهز للسحابة من SAP. يستخدم المطورون إصدار اللغة «ABAP for Cloud Development»، ولا يمكنهم البناء إلا على كائنات مُصدَرة وواجهات API عامة ونقاط توسعة. بدأ في SAP BTP ABAP environment، وهو متاح الآن في جميع إصدارات S/4HANA (SAP ABAP Cloud FAQ).

يمنحك S/4HANA Cloud ثلاثة مسارات للتوسعة. تغطي key user extensibility التغييرات البسيطة على الحقول والمنطق وواجهة المستخدم دون المساس بكود SAP. وتتولى developer extensibility باستخدام ABAP Cloud المنطق المرتبط ارتباطًا وثيقًا بالنواة، بينما تتولى الامتدادات side-by-side على SAP BTP كل ما يجب أن يبقى منفصلًا.

والإصدار هو ما يحدد مقدار الخيارات المتاحة لك:

	S/4HANA Cloud Public Edition	S/4HANA Cloud Private Edition وon-premise
تطوير ABAP	ABAP Cloud فقط، وهو إلزامي للعملاء الجدد منذ الإصدار 2208	يُوصى بـ ABAP Cloud منذ 2022، ولا يزال ABAP الكلاسيكي مسموحًا
تغيير كود SAP	غير ممكن	ممكن، لكنه من المستوى D
امتدادات key user وامتدادات side-by-side على BTP	متاحة	متاحة
من يفرض Clean Core	النظام	حوكمتك أنت

قاعدتي لعملاء Private Edition: تعامل معها كأنها Public Edition في كل ما هو جديد. ABAP الكلاسيكي مسموح، لكن كل كائن كلاسيكي تضيفه اليوم قرار سيتعيّن على أحدهم الدفاع عنه في الترقية التالية.

يجب أن تملك قرارات Clean Core هيئة تصميم (design authority) تضم الأعمال وتقنية المعلومات. فتقنية المعلومات وحدها ستوافق على كل ما هو ممكن تقنيًا. والأعمال وحدها ستطالب بعودة عمليتها القديمة.

وهكذا كنت سأبنيها:

1. سمِّ الأعضاء. مالكو العمليات التجارية لكل مجال رئيسي، إلى جانب مهندس الحلول وكبير المطورين. يقرر مالكو الأعمال ما إذا كان المتطلب حقيقيًا، وتقرر تقنية المعلومات طريقة بنائه.
2. اتفقوا على ترتيب الأفضلية قبل بدء البناء. العملية القياسية أولًا، ثم key user extensibility، ثم المستوى A على ABAP Cloud أو BTP. ويحتاج المستوى B أو C إلى سبب مكتوب، ويحتاج المستوى D إلى خطة خروج.
3. اجعلوا لكل طلب امتداد مالكًا وسببًا تجاريًا. لا مالك، لا بناء. ويُسجَّل القرار والمستوى المقبول في سجل واحد.
4. ضعوا بوابة تقنية قبل عمليات النقل (transports). شغّلوا فحوص Clean Core في ABAP test cockpit وفق جدول منتظم، وأوقفوا أي كود جديد من المستوى D قبل وصوله إلى بيئة الإنتاج.
5. راجعوا السجل قبل كل ترقية. أوقفوا ما لم يعد أحد يستخدمه، وانقلوا ما يمكنه الآن بلوغ مستوى أعلى.

كان السؤال على تلك الطاولة في الماضي: «لماذا لا يمكن أن يعيش هذا على BTP؟» أما اليوم فسأسأل: «لماذا لا يمكن أن يكون هذا من المستوى A؟» وإن لم يكن ممكنًا، فالسؤال التالي هو أي مستوى تقبلونه ولماذا.

أكبر خطأ أراه في Clean Core هو محاولة جعل SAP يعمل مثل Oracle. تبنَّ العمليات القياسية لـ SAP بدلًا من إعادة بناء منطق نظام آخر في كود مخصص. وإن كنت لا تزال تختار بينهما، فأنا أقارن بينهما في SAP vs Oracle.

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

يسير هذا الحوار بشكل أفضل عندما ترى الأعمال العملية الجديدة وهي تعمل، لا شريحة عرض عنها. ويسير أيضًا بشكل أفضل عندما تختبر الادعاء بأن عملية ما فريدة، لأنها في الغالب ليست كذلك (انظر الخطوتين 4 و5 أدناه).

المهارات لا تقل أهمية عن الأدوات. ففريق ABAP لم يعمل مع ABAP Cloud أو BTP سيُبطئ البرنامج أثناء تعلّمه. وقد أجرت إحدى الشركات المصنّعة التي عملت معها برنامجًا داخليًا لـ BTP مدته ثلاثة أشهر قبل بدء مشروع S/4HANA، وأثمر ذلك مفاجآت أقل خلال مرحلة البناء.

الامتثال لـ Clean Core هو مقدار ما يستوفيه نظامك من معايير SAP عبر المبادئ الخمسة. ولا يمكنك إدارته من دون أرقام، وتوفّر لك SAP ثلاثة مصادر للحصول عليها.

1. ABAP test cockpit. أداة SAP للفحص على مستوى الكود. تُظهر الكائنات المخصصة التي تستخدم كائنات غير مُصدَرة أو تعديلات أو وصولًا مباشرًا إلى الجداول.
2. SAP Readiness Check. يأتي مع اتفاقية الصيانة لديك، ويُظهر ما سيتأثر بالانتقال إلى S/4HANA قبل أن تلتزم.
3. لوحة RISE with SAP Methodology dashboard، المعروفة أيضًا باسم clean core dashboard. تعمل في SAP Cloud ALM. يتحقق عرض النظام فيها من إصدار S/4HANA لديك، ويؤكد أن أدوات جمع البيانات مفعّلة، ويراجع الامتدادات قبل الترقية، بينما يتابع عرض التشغيل مؤشرات الأداء التشغيلية.

الأرقام التي سأضعها أمام هيئة التصميم كل شهر بسيطة. كم كائنًا مخصصًا يقع في كل مستوى، وهل يتراجع المستوى D؟ كم استثناءً لا يزال مفتوحًا، وهل لكل منها مالك؟

لو طلبت مني تقييم نظامك الشهر المقبل، فهذا هو الترتيب الذي سأتبعه.

1. اعرف ما يُستخدم فعلًا. شغّل SAP Readiness Check واجمع بيانات الاستخدام للكود المخصص. في أحد البرامج، أوصلنا التحليل باستخدام smartShift من 18,000 كائن مخصص إلى 3,200، لأن معظم الباقي لم يكن يُستخدم ببساطة.
2. صنّف ما تبقّى في المستويات من A إلى D. استخدم ABAP test cockpit للكود. وإذا كنت على RISE، فإن clean core dashboard يتابع ذلك من هناك.
3. قرّر كائنًا بكائن. أوقفه، أو انقله إلى واجهة مُصدَرة، أو أعد بناءه على BTP، أو أبقه مع سبب موثّق. ابدأ بالكود الذي يعمل كل يوم، لأن تقريرًا يستخدمه فريق إقليمي واحد مرتين في السنة يمكنه الانتظار.
4. أدخل الأعمال إلى الغرفة. مسؤول مالي عملت معه لم يفهم تطبيق Fiori الجديد الخاص به إلا بعد جولة شرح مدتها 45 دقيقة. ووفّرت تلك الجلسة أسبوعين من الأخذ والرد في اختبار قبول المستخدم (UAT).
5. اعترض على عبارة «عمليتنا مختلفة». في ورشة عمل مع فريق المبيعات في شركة صناعية أوروبية عام 2023، تبيّن أن العملية «الفريدة» كانت في 80% منها أعمالًا إدارية قديمة زائدة عن الحاجة. وحسّن SAP القياسي تجربة عملائهم بمجرد التخلص من الحلول الالتفافية.
6. ابدأ العمل على البيانات مبكرًا. كان لدى عميل تجزئة في دول الخليج عملت معه عام 2024 أكثر من 15,000 حقل مخصص يجب فرزها. ومن خبرتي، يستهلك ترحيل البيانات ما بين 30 و40% من جهد التنفيذ، ويوضح دليلي لتكلفة تنفيذ SAP أين يقع ذلك في الميزانية.
7. ضع الحوكمة قبل التشغيل الفعلي (go-live). أنشئ هيئة التصميم الموصوفة أعلاه، واجعلها المسار الوحيد لأي امتداد جديد.

ثلاثة أسئلة تُطرح في كل حديث تقريبًا أخوضه حول هذا الموضوع.

هل Clean Core إلزامي في RISE with SAP؟

ليس كقاعدة عامة. ففي Public Edition يفرضه النظام، أما في Private Edition وon-premise فلا يزال بإمكانك تعديل النواة.

وهناك يكون Clean Core خيار حوكمة تتابعه SAP عبر RISE methodology dashboard. وإن أخبرك أحد مُكاملي الأنظمة (SI) بأنه التزام تعاقدي، فاطلب منه أن يريك البند.

كم من الوقت لديّ على ECC؟

بالنسبة إلى SAP ERP 6.0 على حزم التحسين (enhancement packages) من 6 إلى 8، تنتهي الصيانة الرئيسية في 31 ديسمبر 2027. وتمتد الصيانة الممتدة الاختيارية حتى 31 ديسمبر 2030 بتكلفة إضافية.

بعد ذلك، يغطي خيار الانتقال SAP ERP, private edition, transition option الفترة من 2031 إلى 2033. ولا ينطبق إلا على الأنظمة الكبيرة التي نُقلت بالفعل إلى SAP ERP, private edition على SAP HANA قبل نهاية 2030.

تعامل مع 2033 كمسار استثنائي، لا كتاريخ للتخطيط. ويغطي دليلي للانتقال من ECC إلى S/4HANA خيارات المسار.

هل يهم Clean Core للذكاء الاصطناعي؟

نعم. فالبقاء على معيار SAP يساعد الذكاء الاصطناعي وJoule على العمل بشكل أفضل، والعمليات المعدّلة بكثافة هي حيث يصعب تبنّيهما أكثر من غيرها.

تبني SAP ميزات الذكاء الاصطناعي لديها، ومنها Joule، على عملياتها القياسية ونموذج بياناتها. ويولّد Joule for developers كود ABAP Cloud اعتمادًا على واجهات API مُصدَرة. وأشرح كيف تتكامل السحابة والذكاء الاصطناعي وClean Core في تحديث أنظمة ERP.

الفرق التي تتجاوز Clean Core لا تتجنّب العمل. إنها تؤجله فقط، فيعود في صورة ترقيات معطّلة، وماراثونات من اختبارات الانحدار، وكود مخصص لا يفهمه أحد.

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

ما هو Clean Core في SAP؟

يعني Clean Core إبقاء S/4HANA قريبًا من معيار SAP وبناء الامتدادات فقط عبر واجهات أصدرتها SAP رسميًا والتزمت بإبقائها مستقرة. وتعمل الامتدادات إما on-stack باستخدام ABAP Cloud أو side-by-side على SAP BTP. والهدف ألا تكسر الترقيات منطقك المخصص.

ما هي المبادئ الخمسة لـ SAP Clean Core؟

المبادئ التوجيهية الخمسة لـ Clean Core لدى SAP هي العمليات، وقابلية التوسعة، والبيانات، والتكاملات، والتشغيل. تبقى العمليات قريبة من المعيار، وتستخدم الامتدادات واجهات API مُصدَرة، وتُحفظ البيانات نظيفة ضمن نموذج حوكمة. وتستخدم التكاملات تقنيات مدعومة، ويشمل التشغيل الحوكمة والأشخاص والأدوات التي تحافظ على المبادئ الأربعة الأخرى.

ما هي مستويات SAP Clean Core A وB وC وD؟

منذ أغسطس 2025 تصنّف SAP الامتدادات في أربعة مستويات. لا يستخدم المستوى A إلا واجهات مستقرة ومُصدَرة علنًا، ويستخدم المستوى B أيضًا واجهات SAP API الكلاسيكية، ويصل المستوى C إلى كائنات SAP الداخلية. ويشمل المستوى D التعديلات والكتابة في جداول SAP والتحسينات الضمنية، وينطوي على أعلى خطر عند الترقية.

هل Clean Core إلزامي في RISE with SAP؟

ليس كقاعدة عامة. لا يسمح S/4HANA Cloud Public Edition إلا بـ ABAP Cloud والواجهات المُصدَرة، فهو يفرض Clean Core تقنيًا. أما في Private Edition فلا يزال بإمكانك تعديل النواة، لذلك يكون Clean Core قرار حوكمة تتابعه SAP عبر RISE with SAP Methodology dashboard.

ما هو ABAP Cloud؟

ABAP Cloud هو نموذج تطوير ABAP الجاهز للسحابة من SAP. ولا يسمح إلا بالكائنات المُصدَرة وواجهات API العامة ونقاط التوسعة، مما يُبقي الكود المخصص مستقرًا عند الترقيات. وهو إلزامي في S/4HANA Cloud Public Edition للعملاء الجدد منذ الإصدار 2208، ويُوصى به في Private Edition وon-premise منذ 2022.

كيف تقيس Clean Core؟

استخدم ABAP test cockpit للفحص على مستوى الكود، وصنّف الكائنات المخصصة في المستويات من A إلى D. ويمكن لعملاء RISE متابعة التبنّي في RISE with SAP Methodology dashboard، المسماة أيضًا clean core dashboard، في SAP Cloud ALM. وأتابع أنا عدد الكائنات في كل مستوى، واتجاه المستوى D، وعدد الاستثناءات المفتوحة التي لها مالك.

من يجب أن يملك حوكمة SAP Clean Core؟

يجب أن تملك كل قرارات Clean Core هيئة تصميم (design authority) تضم الأعمال وتقنية المعلومات. يقرر مالكو العمليات التجارية ما إذا كان المتطلب حقيقيًا، وتقرر تقنية المعلومات طريقة بنائه وفي أي مستوى. ويُسجَّل كل استثناء مع مالكه ويُراجع قبل كل ترقية.

متى ينتهي دعم SAP ECC؟

بالنسبة إلى SAP ERP 6.0 على حزم التحسين من 6 إلى 8، تنتهي الصيانة الرئيسية في 31 ديسمبر 2027، مع صيانة ممتدة اختيارية حتى 31 ديسمبر 2030 بتكلفة إضافية. ويمتد SAP ERP, private edition, transition option حتى 2033 فقط للأنظمة الكبيرة المؤهلة التي نُقلت إلى SAP ERP, private edition على SAP HANA قبل نهاية 2030.