كيف تتفادى تضخم النطاق في تنفيذ SAP

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

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

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

هذه ليست حالات شاذة. إنها الطريقة الأكثر شيوعاً التي تفشل بها برامج SAP.

يبدأ ببراءة. يطلب قائد في العمل «تغييراً صغيراً واحداً فقط». ثم آخر. وعبارة «ما دمنا هناك، فلنضف فقط...» أخرجت من مسارها تنفيذات SAP أكثر مما فعل أي تحدٍّ تقني.

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

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

بدأ عميل في التصنيع بعشرة تقارير مخصصة وانتهى بـ 47، وأضاف كل منها وقتاً للتصميم والبناء والاختبار. وتجاوز مسار التقارير وحده ميزانيته بنسبة 200%.

200%

تجاوز ميزانية مسار التقارير بعد أن رفع انجراف النطاق التقارير المخصصة من 10 إلى 47

المصدر: برنامج عميل في التصنيع

علامات التحذير

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

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

كل شيء مترابط

تربط SAP كل شيء معاً. المالية تؤثر في سلسلة الإمداد. والموارد البشرية تمس الرواتب. والمبيعات ترتبط بالمخزون. تغيير واحد قد يعطّل عشرة أشياء.

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

ضغط الفرصة مرة كل عقد

تنفذ معظم الشركات SAP مرة كل 10 إلى 15 سنة. وتعرف كل إدارة أنها لن تحصل على فرصة أخرى لعقد كامل. لا أحد يريد أن يسمع «المرحلة الثانية»، التي تعني في معظم المؤسسات أنها لن تأتي. فيُدفع كل شيء إلى المشروع الحالي، وتتحول قائمة النطاق إلى قائمة أمنيات.

ما الذي يغيّره Clean Core

يضع Clean Core كابحاً تقنياً على التخصيص. في S/4HANA Cloud Public Edition، لا يمكن تعديل النواة: تمر الامتدادات عبر واجهات برمجة مُعلَنة، سواء ضمن المنصة نفسها (on-stack) أو بجانبها (side-by-side) على SAP BTP. وفي Private Edition والبيئة المحلية، يظل التعديل ممكناً، لكن إرشادات SAP تعدّه الملاذ الأخير لأن كل تعديل يضيف عملاً عند الترقية.

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

1. حدد النطاق باستثناءات صريحة. وثّق ما هو خارج النطاق بالعناية نفسها التي توثق بها ما هو داخله، واحصل على توقيع على الاثنين. الغموض هو حيث تبدأ الخلافات.
2. طبّق ضبطاً رسمياً للتغيير مع عواقب. كل تغيير يحتاج إلى تقييم للأثر على الكلفة والوقت والجودة، ظاهر لمن يوافق عليه.
3. أبلغ بحدود النطاق في كل اجتماع للجنة التوجيهية. اعرض حالة النطاق بعرض بسيط بالأحمر والأصفر والأخضر. كثير من الانجراف سوء فهم.
4. اكتب خطة لإدارة النطاق. حدد كيف تُقيَّم التغييرات وتُعتمد وتُصعَّد وتُتتبَّع، كي يتعامل معها كل مسار عمل بالطريقة نفسها. ويقدم قالب نطاق مشروع SAP بنية للبدء.
5. رتّب الأولويات بطريقة MoSCoW. ضروري (Must have)، ومهم (Should have)، ومرغوب (Could have)، ولن يُنفَّذ هذه المرة (Won't have). اضغط بقوة لإبقاء قائمة Must have قصيرة.
6. أخضِع كل قرار لضبط الإصدارات. كل تغيير معتمد يحدّث خط الأساس. وكل تغيير مرفوض يُسجَّل مع سببه.
7. اشترط المفاضلات. إذا دخل متطلب جديد، يخرج شيء آخر. وتصبح الأمور الضرورية اختيارية بسرعة حين تكلف شيئاً.

ثلاث تقنيات استخدمتها تجعل هذه الاستراتيجيات تثبت.

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

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

أظهر كلفة التغيير. قد يكلف تغيير أثناء التصميم 5,000 دولار. والتغيير نفسه أثناء الاختبار قد يكلف 50,000 دولار. ضع رسماً بسيطاً بذلك أمام الناس وستتباطأ الطلبات العابرة.

هذه نطاقات تقريبية لكلفة التغيير في برامج S/4HANA في السوق الأمريكية. وهي تتفاوت بحسب التعقيد والشريك. استخدمها مرساة، لا عروض أسعار.

المرحلة	كلفة التغيير الصغير المعتادة	كلفة التغيير المتوسط المعتادة
Explore (التصميم)	2 إلى 10 آلاف دولار	10 إلى 30 ألف دولار
Realize المبكرة	5 إلى 20 ألف دولار	20 إلى 80 ألف دولار
Realize المتوسطة (البناء)	15 إلى 50 ألف دولار	50 إلى 200 ألف دولار
Realize المتأخرة (الاختبار)	30 إلى 100 ألف دولار	100 إلى 400 ألف دولار
Deploy والانتقال	80 إلى 300 ألف دولار	300 ألف إلى 1 مليون دولار فأكثر
الدعم المكثف (بعد التشغيل الفعلي)	150 إلى 500 ألف دولار	500 ألف إلى 2 مليون دولار فأكثر

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

البنود التعاقدية المهمة

العقود الغامضة تخلق مشكلات مكلفة. رأيت عميلاً يوقع عقداً ينص فقط على «تنفيذ S/4HANA». وادعى الشريك لاحقاً أن عمليات بعينها إضافات تستلزم رسوماً إضافية، وانتهى الأمر بالعميل إلى الدفع مرتين. هذه البنود تمنع ذلك:

البند	الغرض
نطاق مع استثناءات صريحة	يحد مما يغطيه السعر الثابت ويزيل الغموض حول الإضافات
أسعار متفق عليها مسبقاً للتغييرات الشائعة	يثبّت الأسعار للتقارير والواجهات وتغييرات التهيئة قبل أن يأتي الضغط
استمرارية الاستشاريين	يمنع الاستشاريين الجدد من إعادة فتح قرارات محسومة وتوسيع النطاق
سلطة الموافقة على الجانبين	يمنع الاستشاريين المبتدئين من الوعد بميزات لم يفوّض بها أحد
فوترة قائمة على المراحل	يربط الدفع بمخرجات معتمدة، لا بالوقت المنقضي
معايير قبول لكل مخرج	يعرّف «المنجز» قبل أن يجادل أحد فيه
بند امتدادات Clean Core	يشترط أن تستخدم الامتدادات واجهات برمجة مُعلَنة أو SAP BTP؛ ويوفر إعادة العمل عند أول ترقية كبرى

وتغطي ملاحظاتي عن التفاوض على عقود ERP كيف تحصل على الاتفاق على هذه البنود.

مجلس ضبط التغيير

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

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

لا يتحرك النطاق إلا عبر المجلس

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

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

بعض التغييرات ضروري. أصابت لوائح جديدة من إدارة الغذاء والدواء الأمريكية (FDA) عميلاً لي في قطاع الأدوية في منتصف التنفيذ. كان لا بد من إدخالها. هذا ليس تضخماً في النطاق. هذا هو الواقع.

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

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

والذكاء الاصطناعي يساعد الآن في الأعمال الورقية. فمساعدون مثل Microsoft Copilot يلخصون سلاسل طلبات التغيير الطويلة في موجز جاهز للقرار للمجلس، ويربط SAP Cloud ALM المتطلبات والتغييرات والاختبارات معاً بحيث يسهل تتبع أثر التغيير. يستطيع الذكاء الاصطناعي أن يبيّن أن تغييراً يمس 14 مجالاً. لكنه لا يستطيع أن يقول لمدير العمليات إن طلبها يعني أن طلب المدير المالي لن يتحقق. تلك المحادثة تبقى مسؤوليتك.

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

واستخدم عميل آخر نظام رموز: تلقت كل إدارة ثلاثة رموز تغيير للمشروع كله. تريد تغييراً؟ أنفق رمزاً. فكّر الناس مليّاً فيما يهم، وأُعيد النظر في «الضروريات» حين صارت تكلف عملة محدودة.

لا أحد من النهجين معقد. كلاهما يحتاج إلى انضباط ودعم من القيادة. واختبار أي عملية للنطاق هو اليوم الذي يدخل فيه مدير العمليات غرفة المشروع بـ«تغيير صغير واحد فقط». ابنِها لذلك اليوم.

ما هو تضخم النطاق في مشروع SAP؟

هو النمو التدريجي غير المنضبط للمتطلبات دون تغييرات مقابلة في الجدول الزمني أو الميزانية أو الموارد. وفي SAP يبدأ عادةً بإضافات صغيرة: تقارير إضافية وحقول إضافية و«تغيير سريع واحد فقط في سير العمل». كل منها يبدو غير ضار. ومجتمعة تضيف أشهراً.

تتبع تغييرات النطاق المشروعة عملية وتأتي مع تعديلات على الجدول الزمني والميزانية. أما تضخم النطاق فيصل بشكل غير رسمي ويتجاوز ضبط التغيير.

ما أكثر أسباب تضخم النطاق شيوعاً في مشاريع SAP؟

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

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

كيف يغيّر Clean Core مخاطر تضخم النطاق؟

يضيف كابحاً تقنياً. في S/4HANA Cloud Public Edition لا يمكن تعديل النواة، فتصبح كل فجوة امتداداً له كلفة تصميم وبناء واختبار خاصة به. وفي Private Edition والبيئة المحلية يكون التعديل ممكناً لكنه يضيف عملاً عند الترقية، لذا تثني إرشادات SAP عنه.

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

ما الفرق بين تضخم النطاق والإفراط في الإتقان (gold-plating)؟

يأتي تضخم النطاق من العمل: طلبات تتجاوز ما اتُّفق عليه. ويأتي الإفراط في الإتقان من فريق التسليم: تعقيد لم يطلبه أحد.

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

كيف تبني عملية ضبط للتغيير تنجح فعلاً؟

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

وهذه القاعدة الأخيرة وحدها تُصفّي الطلبات التي ليست حرجة فعلاً.

هل يمكن تفادي تضخم النطاق تماماً؟

لا. في أي برنامج يزيد عن بضعة أشهر، تتغير ظروف العمل وتتبدل اللوائح ويكشف التصميم عن فجوات.

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

ما أفضل طريقة للتعامل مع تجميد النطاق في برنامج SAP طويل؟

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

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