Clean Core ليس مشروعًا ينتهي — بل معيار تلتزم به. يقدّم نموذج القابلية للتوسعة في SAP ثلاث طبقات متدرّجة، والانضباط ببساطة هو استخدام الأقل تدخّلًا منها دائمًا ما دامت تفي بالغرض. دور VISCAP هو ترسيخ ذلك المعيار ثم إبقاؤك ضمنه — تقييم، ومعالجة، وهندسة توسعات، وحوكمة إصدارات تمنع الدَّين من التراكم من جديد.
ثمانية مجالات قدرات، مذكورة قبل أي اسم أداة. كل واحد منها شيء تستطيع مؤسسة تقنية المعلومات الإشارة إليه بعد انتهاء العمل — لا وثيقة سياسة ولا ترخيصًا ولا درجة نضج.
القابلية للتوسعة داخل التطبيق في SAP S/4HANAأدوات المستخدم الرئيسي
الطبقة الأولى التي تُجرَّب. لا شيء يخرج عن نقاط التوسعة المُصرّح بها، فتبقى النتيجة سليمة بعد كل ترقية.
ABAP Cloudالقابلية للتوسعة للمطوّرين في SAP S/4HANA
حيث تنتهي قدرات أدوات المستخدم الرئيسي. اللغة نفسها كما كانت، لكن بعقد أضيق كثيرًا.
بيئة SAP BTP ABAPSAP Build CodeSAP Business Application StudioSAP Cloud Application Programming Model
الطبقة المخصّصة لأي عمل جوهري — منطق خارج النواة تمامًا، بدورة إصدار خاصة به.
SAP Build AppsSAP Build Process AutomationSAP Build Work Zone
الحوكمة أهم من الأدوات — فالبرمجة المنخفضة بلا حوكمة تعيد بناء الدَّين نفسه في مكان جديد.
SAP Integration Suiteإدارة APISAP Event Mesh
النواة التي تمتدّ إلى جداولها تكاملات من نقطة إلى نقطة ليست نواة نظيفة.
تحليل الشيفرة المخصّصة في SAPإدارة النقل ودورة الحياة
يُظهر تحليل الاستخدام عادةً أن حصة كبيرة من الكائنات المخصّصة لم تُنفَّذ منذ سنوات — وسحبها من الخدمة هو أرخص عمل متاح في مسار Clean Core.
يفشل Clean Core حين يكون مرسومًا وينجح حين يكون انضباطًا تشغيليًا. تعمل VISCAP على المسار كاملًا — من جرد الكائنات المخصّصة الذي لم يجرِه أحد منذ سنوات وصولًا إلى حوكمة الإصدارات التي تمنع الدَّين من التراكم مجددًا؛ أمّا هنا فموضع كل مرحلة وما نتولّاه داخلها.
يمسّ Clean Core كل جزء تقريبًا من بيئة SAP لديك — الشيفرة والواجهات وتقويم الإصدارات والطريقة المسموح للناس أن يبنوا بها. وتغطي خطوط خدمات VISCAP الثمانية هذه العمل المحيط به.
جميع خدمات VISCAPإجراء تقييم Clean Core، ومراجعة التخصيصات والدَّين التقني، وتحديد توجّه القابلية للتوسعة والجاهزية للترقية.
الالتزام بمعيار Clean Core داخل عمليات التنفيذ والنشر الجديدة، حيث لا تزال قرارات المواءمة مع المعيار قليلة الكلفة.
جرد الشيفرة المخصّصة، وتحليل الاستخدام، والسحب من الخدمة، والمعالجة، وإعادة بناء المنطق المتبقّي كتوسعات جنبًا إلى جنب.
تعريف مبادئ التكامل وفق Clean Core، وترشيد الواجهات، ونقل الوصلات من نقطة إلى نقطة إلى واجهات API وأحداث محكومة.
نقل التقارير المخصّصة من كائنات النواة المعدَّلة إلى العروض المُعتمدة وطبقة تحليلات محكومة.
تشغيل جرد التوسعات وضوابط النقل ودورة الحياة، وحواجز الحماية التي تُبقي كل بناء جديد داخل المعيار.
تقييم أثر الإصدار، وتتبّع الوظائف المتقادمة، ونطاق اختبار الانحدار، وقائمة أعمال الترقية، إصدارًا بعد إصدار.
تمكين المستخدمين الرئيسيين والمطوّرين من طبقات القابلية للتوسعة، ليُختار المستوى الصحيح دون الحاجة إلى مهندس معماري في كل نقاش.
توحيد عمليات الموارد البشرية والمواهب عبر فرق المصانع والمقر — نموذج تشغيل واحد لقوى عاملة في تصنيع الزجاج.
دورة حياة الموظف الكاملة على طبقة SuccessFactors واحدة متّسقة عبر عمليات الأعمال الزراعية والمنتجات العضوية الموزّعة.
أين ينبغي أن يعيش منطق التوسعة بعد أن أصبحت النواة محظورة، وكم يُكلّف التشغيل الجانبي على SAP BTP فعليًا.
يمنحك التقرير عددًا. لكنه لا يخبرك أيّ الكائنات لا يزال مهمًا، وأيّها مهجور، وكم ستكلّف إعادة بنائها.
Clean Core هو المبدأ القاضي بأن تبقى نواة SAP الرقمية قريبة من المعيار، وأن يُبنى كل ما هو مخصّص عبر نقاط توسعة مُصرّح بها بدلًا من تعديل النواة نفسها. والعائد العملي أن الترقيات تصبح إجراءً روتينيًا، لأن بإمكان SAP تغيير النواة دون كسر منطق لم يكن يُفترض أصلًا أن يعتمد على تفاصيلها الداخلية.
لا — بل يعني التخصيص في المكان الصحيح. فلكل مؤسسة عمليات تُميّزها فعلًا، وهذه تُبنى كما هي. أما الانضباط فيتعلق بالإجابة عن سؤال أين: عبر أدوات المستخدم الرئيسي، أو عبر ABAP Cloud مقابل الكائنات المُعتمدة، أو جنبًا إلى جنب على SAP BTP، بدلًا من تعديل الشيفرة القياسية.
ثلاث طبقات، مرتّبة من الأقل تدخّلًا إلى الأكثر. القابلية للتوسعة داخل التطبيق تتيح للمستخدمين الرئيسيين تكييف المعيار من داخل التطبيق نفسه. والقابلية للتوسعة للمطوّرين تستخدم ABAP Cloud مقابل الكائنات المُعتمدة. أما التوسعة جنبًا إلى جنب فتضع المنطق على SAP BTP خارج النواة تمامًا. وClean Core في جوهره عادةُ التوقّف عند أول طبقة تفي بالغرض.
ABAP Cloud هو نموذج التطوير المقيّد للبناء داخل أنظمة SAP الحديثة. اللغة مألوفة، لكن العقد أضيق كثيرًا: يقتصر التطوير على واجهات API والكائنات المُعتمدة، فلا يمكنه الوصول إلى التفاصيل الداخلية التي تملك SAP حرية تغييرها. وهذا التقييد بالذات هو ما يجعل الشيفرة الناتجة آمنة عند الترقية، كما يعني أن مهارات ABAP القائمة تنتقل معك.
واجهة API أو الحدث المُعتمد هو ما نشرته SAP بوصفه عقدًا مستقرًا والتزمت بالحفاظ عليه عبر الإصدارات. والبناء على الكائنات المُعتمدة بدل القراءة المباشرة من الجداول هو أدقّ مؤشّر منفرد على ما إذا كانت التوسعة ستنجو من الترقية دون مساس.
SAP BTP هي موطن التوسعات جنبًا إلى جنب. فبيئة SAP BTP ABAP وSAP Build Code وSAP Build Apps تتيح لك بناء تطبيقات مخصّصة جوهرية تقرأ بيانات SAP وسياق عملياتها عبر واجهات محكومة، مع تشغيلها على دورة حياة خاصة بها — بحيث يمكن إصدار التوسعة والنواة كلٌّ بمعزل عن الآخر.
النواة التي تمتدّ إلى جداولها عشرات الواجهات من نقطة إلى نقطة ليست نظيفة، مهما بدت الشيفرة. ينقل Integration Suite تلك الواجهات إلى واجهات API وأحداث مُدارة بحوكمة مركزية، فتصبح طبقة الواجهات عقدًا منشورًا بدلًا من اعتمادية غير موثّقة.
ليس بالكامل، لكن إنجاز أعمال الجرد والسحب من الخدمة أولًا أرخص في معظم الأحوال. فتحليل الاستخدام يُظهر عادةً أن حصة كبيرة من الكائنات المخصّصة لم تعمل منذ سنوات؛ ونقلها إلى عملية التحويل يعني الدفع مقابل معالجة واختبار شيفرة لا يستخدمها أحد. وقرار السحب من الخدمة أسهل كثيرًا قبل الانتقال منه بعده.
نبدأ بجرد التطويرات المخصّصة وتحليل قائم على الاستخدام — ما هو موجود، وما يُنفَّذ فعلًا، وما يعتمد على كائنات لم تعتمدها SAP. وينتج عن ذلك صورة مُقاسة للدَّين التقني، وخط أساس للجاهزية للترقية، وقائمة فجوات؛ وعليها تُبنى بعد ذلك استراتيجية القابلية للتوسعة وخطة المعالجة.
نعم، وهذا هو النوع الأكثر شيوعًا من المشاركات. فكثير من بيئات S/4HANA انحرفت عن مسارها منذ الإطلاق الفعلي (go-live). والعمل يأخذ الشكل نفسه — جرد، ومعالجة، وإعادة بناء المنطق المتبقّي جنبًا إلى جنب، وترشيد الواجهات، وإحاطة كل بناء جديد بالحوكمة ليصمد الوضع بدل أن يتدهور من جديد.
تحدّث مع مهندسي SAP لدى VISCAP عن وضع شيفرتك المخصّصة، ودورة الترقية لديك، وحجم ما تزال تُعدّله من النواة.