الشيفرة المخصّصة لم تتوقّف عن كونها ضرورية. بل توقّفت عن كونها مجانية.

تحمل معظم بيئات ECC سنوات من التعديلات، وكلٌّ منها كان له ما يبرّره يومًا. ولم تظهر الكلفة إلا لاحقًا، عند الترقية — حين كان لا بدّ من إعادة اختبار كل تغيير أو تسويته أو إعادة كتابته، فانتقلت الترقيات بهدوء من الروتين إلى الندرة.

Clean core هو الانضباط الذي يمنع تلك الدورة من أن تبدأ من جديد على S/4HANA. وهو ليس قاعدة ضد التخصيص. بل هو قاعدة تحدّد أين يُسمح للتخصيص بأن يعيش.

الخلاصة التنفيذية

تبقى النواة معيارية كي تظل قادرة على التقدّم. وكل ما هو مخصّص يعيش إلى جانبها، ويُرقّى وفق جدوله الخاص.

ما الذي يعنيه clean core فعلًا

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

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

تميّز إرشادات SAP بشأن clean-core بين القابلية للتوسعة داخل التطبيق — نقاط توسعة مُعتمدة داخل S/4HANA — والتوسعات المبنية جنبًا إلى جنب على SAP Business Technology Platform، والمتصلة عبر واجهات API المُعتمدة.

ثلاثة أسئلة قبل أي توسعة

01

هل يغطّيه المعيار بعد ضبط الإعدادات؟

نسبة مفاجئة من “المتطلبات” ليست سوى عادات مستوردة من النظام القديم. وورشة المواءمة مع المعيار (fit-to-standard) موجودة تحديدًا للفصل بين ما تحتاجه الأعمال وما صادف أن فعله التنفيذ السابق.

02

إن لم يكن — فهل يمكن أن يعيش داخل نقاط التوسعة المُعتمدة؟

الحقول المضافة وتكييفات الواجهة ومنطق الأعمال المحصور تندرج غالبًا ضمن القابلية للتوسعة داخل التطبيق، المصمَّمة للصمود أمام الترقيات. وهذا أرخص بيت يمكن أن تسكنه توسعة.

03

إن لم يكن — فمكانه إلى جانب النواة لا داخلها

التطبيقات الكاملة والمنطق الثقيل والتنسيق عبر الأنظمة مكانها المنصّة المجاورة، تتحاور مع النواة عبر واجهات API المُعتمدة. والجواب الوحيد غير المقبول هو الجواب القديم: تعديل النواة لمجرد أنها قريبة.

متطلب→فحص المواءمة مع المعيار→نقطة توسعة داخل التطبيق→التوسعة الجانبية على BTP

كم تكلّف التوسعة جنبًا إلى جنب فعليًا

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

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

ما مكان كل شيء

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

وجهة نظر VISCAP

رأينا

تعامَل مع كل طلب توسعة بوصفه مطالبةً على كل ترقية مقبلة. ومعظم المطالبات لا تصمد أمام هذا التأطير.

المؤسسات التي تتعثّر مع clean core نادرًا ما تكون الأكثر متطلبات. بل هي التي لا تملك مسار قرار — حيث يُناقَش كل طلب على حدة، ويفوز أعلى الأصوات. والأسئلة الثلاثة أعلاه ميكانيكية عن قصد: فهي تحوّل حوكمة التوسعات من جدل إلى قاعدة توجيه.

الترقيات هي المقصد

النواة النظيفة ليست ترفًا جماليًا. بل هي ما يجعل خارطة طريق المنصّة — بما فيها كل ما ستطرحه SAP لاحقًا — شيئًا تتلقّاه مؤسستك بدل أن تشتريه من جديد. وهذا الانضباط يسدّد كلفته أول مرة تكون فيها الترقية مملّة.