نموذج نطاق مشروع SAP: ما الذي تحدده وما الذي تستثنيه

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

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

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

هذه هي الأقسام التسعة، مع ما يجب أن يجيب عنه كل منها.

1. الأهداف

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

2. تعريف النطاق

الوحدات والكيانات القانونية والمصانع والبلدان واللغات والتكاملات ونموذج النشر. كن محدداً. «المالية» ليست نطاقاً. أما «المحاسبة المالية ومحاسبة التكاليف (FI/CO) التي تغطي الذمم الدائنة والمدينة ودفتر الأستاذ العام ومحاسبة مراكز التكلفة للكيان القانوني في دولة الإمارات على S/4HANA Cloud Private Edition» فهو نطاق.

3. الاستثناءات

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

1. البلدان أو الكيانات المؤجلة إلى مرحلة لاحقة.
2. التكاملات القديمة التي تبقى كما هي حالياً.
3. البيانات التاريخية قبل تاريخ إغلاق محدد.
4. التقارير المنقولة إلى قائمة تحسينات ما بعد التشغيل الفعلي.
5. المتطلبات التنظيمية المؤجلة بانتظار تأكيد قانوني.

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

4. نطاق ترحيل البيانات

نقطة عمياء متكررة. أجب عن ثلاثة أسئلة كتابةً:

1. ما الذي ينتقل؟ البنود المفتوحة فقط أم التاريخ أيضاً؟ كل العملاء والموردين أم النشطون منهم؟ المواد لكل مصنع أم لكيانات التشغيل الفعلي فقط؟
2. ما قواعد تاريخ الإغلاق؟ التاريخ المرجعي لأوامر الشراء والمبيعات والعمل المفتوحة، وما يحدث للبنود الجارية عند الانتقال.
3. ما الذي يُؤرشف بدلاً من ذلك؟ قواعد الاحتفاظ القانونية بالتاريخ، ومدة بقاء النظام القديم قابلاً للقراءة.

الافتراضات غير الموثقة هنا تصبح نزاعات أثناء البناء. ويغطي مقالي عن لماذا يفشل ترحيل بيانات SAP التخطيط بعمق.

5. النطاق غير الوظيفي

تسقط هذه أثناء التخطيط وتظهر كعوائق متأخرة في الاختبار. ضعها داخل النطاق:

1. التوفر ونافذة الصيانة. وفي RISE، أحِل إلى شروط التوفر في عقدك.
2. الأداء عند الحمل الأقصى، مثل إقفال نهاية الشهر.
3. تسجيل التدقيق: أي المعاملات، ومدة الاحتفاظ بالسجلات.
4. الأمن والتحكم في الوصول بحسب الدور.
5. زمن استجابة التقارير: فوري أو شبه فوري أو يومي.

ليست ميزات. إنها قيود يجب أن يستوفيها النظام. وإن لم تكن داخل النطاق، فلن يصمم لها أحد.

6. الأدوار والمسؤوليات

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

7. ضبط التغيير

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

8. قواعد الإضافات

كيف يُعتمد التطوير المخصص. تصنّف SAP الإضافات الآن من المستوى A، واجهات API المعتمدة فقط، إلى المستوى D، تعديلات النواة (SAP News، أغسطس 2025). وفي Public Edition ضمن GROW لا يسمح النظام إلا بالواجهات المعتمدة. وفي Private Edition ضمن RISE وفي On-premise، لا يزال بالإمكان تعديل النواة، لذا ينبغي أن ينص النطاق على المستوى المستهدف ومن يوافق على الاستثناءات. ويشرح دليلي لـ Clean Core المستويات.

9. الافتراضات والقيود

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

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

صنّف كل طلب قبل أن توافق على أي شيء:

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

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

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

1. 01رفع الطلبيُحدَّد مسبقاً ما يُعد تغييراً
2. 02التصنيفأساسي أو مهم أو غير ضروري
3. 03تقييم الأثرالوقت والميزانية، بواسطة مقيِّم مسمّى
4. 04القراريوافق مسؤول مسمّى أو يرفض أو يؤجل
5. 05تحديد رقم نسخة للنطاقرقم نسخة جديد وقائمة بما تغيّر

بعد تجميد التغييرات، تذهب الطلبات الجديدة إلى قائمة ما بعد التشغيل الفعلي

التحليلات هي حيث تحتدم محادثات النطاق. الجميع يريد تقارير ولا أحد يقول كم.

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

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

راجع النطاق عند كل بوابة مرحلة في SAP Activate وبعد كل تغيير معتمد، مع رقم نسخة وقائمة بما تغيّر. ويرتبط النطاق بـميثاق المشروع بالإحالة، كي تروي الوثيقتان القصة نفسها.

ما الذي ينبغي أن يتضمنه نموذج نطاق مشروع SAP؟

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

كيف تمنع زحف النطاق في مشاريع SAP؟

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

ما نطاق ترحيل البيانات في مشروع SAP؟

هو تحديد أي البيانات تنتقل إلى SAP وبأي قواعد: أي الكائنات (العملاء والموردون والمواد والأوامر المفتوحة والتاريخ)، وتواريخ الإغلاق، وما يُؤرشف بدلاً من أن يُرحَّل. وهو يحرك الجهد والجدول الزمني، ويحدد المدة التي يجب أن تبقى فيها الأنظمة القديمة متاحة.

ما النطاق غير الوظيفي في مشاريع SAP؟

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

كيف ينبغي التعامل مع التخصيصات في النطاق؟

صنّف كل طلب على أنه أساسي أو مهم أو غير ضروري. وسجّل لكل طلب معتمد المتطلب، ولماذا لا يلبيه SAP القياسي، والجهد، وأثر الاختبار، وتكلفة الصيانة، ونهج الإضافة. وفي Private Edition وOn-premise، حدد مستوى Clean Core المستهدف ومن يوافق على الاستثناءات.

متى ينبغي مراجعة نطاق مشروع SAP؟

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