
المحتويات
- لماذا تتجاوز ميزانيات SAP حدودها: الأسباب الحقيقية
- 1. توضع الميزانية منخفضة، ثم تكشف مرحلة Explore النطاق الحقيقي
- 2. المورّد يتحكم في النطاق
- 3. تغييرات في النطاق دون ضبط للتكلفة
- 4. جداول زمنية يفرضها ضغط الإدارة العليا
- 5. موظفون داخليون بدوام جزئي
- 6. بيانات تُكتشف متأخرة
- علامات الإنذار المبكر لتجاوز ميزانية SAP
- أدوات الضبط التي توقف التجاوز
- كيف يغيّر RISE وGROW المخاطر
- ما يمكنكم رسملته وما لا يمكنكم
- التجاوز يبدأ عند الموافقة
- الأسئلة الشائعة
تتجاوز مشاريع SAP الميزانية في الغالب لأن الشركات تحاول إبقاء التكلفة منخفضة في البداية، ثم تتلقى الضربة في مرحلة Explore، عندما تكشف ورش Fit-to-Standard النطاق الحقيقي. في البرامج التي راجعتها، التجاوزات بنسبة 40 إلى 60 في المئة شائعة.
الإجابة المختصرة: تتجاوز ميزانية SAP حدودها عندما توضع قبل أن يعرف أحد النطاق، وعندما يتحكم المورّد لا العميل في ذلك النطاق. راقبوا عدد WRICEF خلال مرحلة Explore، وامتلكوا النطاق بأنفسكم، واحتفظوا باحتياطي طوارئ بنسبة 10 إلى 20 في المئة في جانبكم.
تبدو متوسطات الاستطلاعات أهدأ. وجد تقرير ERP لعام 2026 الصادر عن Panorama Consulting أن أكثر من ربع المؤسسات تجاوزت ميزانيات ERP لديها، وكانت الاحتياجات التقنية الإضافية السبب الرئيسي. متوسطات الاستطلاعات والبرامج التي تصل في النهاية إلى مستشار هما مجموعتان مختلفتان، فخططوا للثانية.
تجاوز في الميزانية أراه كثيرًا في برامج SAP التي أراجعها
المصدر: Noel D'Costa، ملاحظة منشورة
يتناول هذا المقال التجاوز، لا الرقم الابتدائي. لنطاقات التكلفة حسب حجم الشركة، وأين تذهب الأموال، والأسعار اليومية، ومعادلة للميزانية، اقرأوا دليلي حول كم تبلغ تكلفة تنفيذ SAP.
عبر 21 برنامج SAP قدتها أو أنقذتها، تتكرر الأسباب نفسها. ومعظمها ظاهر قبل توقيع العقد.
1. توضع الميزانية منخفضة، ثم تكشف مرحلة Explore النطاق الحقيقي
هذا هو السبب الأكثر شيوعًا الذي أراه. تحاول الشركات إبقاء التكلفة منخفضة في البداية، غالبًا لأن دراسة الجدوى تحتاج إلى رقم يوافق عليه مجلس الإدارة. ثم تأتي مرحلة Explore.
في SAP Activate، مرحلة Explore هي حيث تختبر ورش Fit-to-Standard العمليات القياسية في SAP مقابل الطريقة التي تعمل بها الشركة فعلًا (SAP Learning). كل فجوة تُكتشف هناك تصبح بندًا في قائمة الأعمال: تقريرًا أو واجهة أو تحويلًا أو تحسينًا أو نموذجًا أو مسار عمل. ولم يكن أيٌّ منها في السعر الأصلي.
لم تكن الميزانية خاطئة لأن أحدًا أخطأ في الحساب. كانت خاطئة لأنها وُضعت قبل أن يوجد النطاق. إن استطعتم، أجروا تقييمًا قصيرًا وفق Fit-to-Standard قبل أن توافقوا على الرقم النهائي.
2. المورّد يتحكم في النطاق
أكبر خطأ في التكلفة أراه قبل التوقيع هو السماح للمورّد بالتحكم في النطاق. عندما تكتب شركة تكامل الأنظمة النطاق، فإنه يصف ما تخطط الشركة لتسليمه، لا ما تحتاجه الأعمال.
تظهر الفجوات لاحقًا في صورة طلبات تغيير، وكل طلب تغيير يسعّره المورّد نفسه. اكتبوا النطاق بأنفسكم، أو اجعلوا جهة مستقلة عن التنفيذ تكتبه معكم.
3. تغييرات في النطاق دون ضبط للتكلفة
وضعت سلسلة بيع بالتجزئة ميزانية قدرها $5M وانتهت عند $12.3M. أدى ضعف جمع المتطلبات إلى تغييرات مستمرة في النطاق. وفي منتصف الطريق، اكتشفت أن عمليات المخزون لديها لا تتطابق مع الوظائف القياسية في SAP، فتبع ذلك تخصيص واسع.
وكانت قد قلّلت أيضًا من تقدير ترحيل البيانات من أنظمتها القديمة. ولو وُوئمت العمليات مع المعيار في مرحلة التصميم لكان ذلك أرخص بكثير.
4. جداول زمنية يفرضها ضغط الإدارة العليا
تجاوز برنامج تصنيع عالمي ميزانيته بنسبة 143% ($14M مقابل $5.8M مخطط لها) وانطلق متأخرًا 11 شهرًا. الأسباب: ضغط غير واقعي من الإدارة العليا على الجدول الزمني، وفريق داخلي ينقصه العدد، ووحدات كثيرة في وقت واحد، وشريك هو الأقل تكلفة دون خبرة في القطاع.
الأرخص ليس الأفضل تلقائيًا. عميل اختار خيار التنفيذ الأقل تكلفة انتهى به الأمر إلى إنفاق 30% أكثر على إصلاح مشكلات كان فريق أكثر خبرة سيتجنبها.
5. موظفون داخليون بدوام جزئي
البرامج التي تعيّن ممثلين بدوام جزئي بدلًا من مالكي عمليات متفرغين تخسر أيامًا عند كل قرار. وكان الفريق الداخلي الذي ينقصه العدد في برنامج التصنيع العالمي ذاك أحد أسباب تأخره 11 شهرًا.
سيكون أفضل موظفيكم ملتزمين بالبرنامج بنصف وقتهم أو أكثر لأشهر. ولا يظهر وقتهم ولا التباطؤ المحيط بالتشغيل الفعلي في عرض أي مورّد.
6. بيانات تُكتشف متأخرة
مشكلات البيانات التي تُكتشف في مرحلة ما قبل الإنتاج هي الأغلى. يجب أن يجري تحليل البيانات بالتوازي مع المتطلبات، لا بعد الإعداد. ثلاثة أشهر من التنظيف تحت ضغط النظام الحي هي باستمرار أكبر بنود تكلفة التأخير في البرامج المتجاوزة للميزانية.
أتناول هذا الموضوع أيضًا في مقطع فيديو على قناتي في YouTube (باللغة الإنجليزية).
أوضح علامة إنذار مبكر هي مرحلة Explore نفسها. راقبوا عدد WRICEF: التقارير والواجهات والتحويلات والتحسينات والنماذج ومسارات العمل. إذا ظلت هذه القائمة تنمو ورشةً بعد ورشة، فالميزانية متأخرة بالفعل عن النطاق.
تشير كل علامة أدناه إلى أحد الأسباب السابقة. ويمكن التحقق من معظمها في مراجعة أسبوعية للبرنامج.
| علامة الإنذار | ما تعنيه عادةً | ما يجب فعله |
|---|---|---|
| نمو عدد WRICEF خلال مرحلة Explore | النطاق الحقيقي أكبر من النطاق المسعّر | أعيدوا تحديد خط أساس الميزانية في نهاية Explore، قبل بدء Realize |
| إغلاق الفجوات بعبارة «لنبنِه» افتراضيًا | لا أحد يتحدى العمليات القياسية | اطلبوا من مالك العملية تبرير كل فجوة مقابل المعيار |
| وثائق النطاق من صياغة شركة تكامل الأنظمة | المورّد يتحكم فيما يُسعَّر | امتلكوا النطاق وراجعوه مع جهة مستقلة |
| طلبات تغيير تُراجع شهريًا أو لا تُسعَّر | التغييرات الصغيرة تتراكم دون أن تُرى | سعّروا كل طلب تغيير وراجعوها أسبوعيًا |
| تحليل البيانات لم يبدأ بنهاية Explore | ستظهر مشكلات البيانات في الاختبار أو الانتقال | ابدأوا التحليل الآن، بالتوازي مع المتطلبات |
| المستخدمون الرئيسيون لا يزالون بدوام جزئي | القرارات تتباطأ وإعادة العمل تزداد | وفّروا بدلاء لأعمالهم اليومية أو حرّكوا الجدول الزمني |
كل واحدة منها تعالج أحد الأسباب السابقة. والقصص من برامج عملت فيها أو راجعتها.
- امتلكوا النطاق. اكتبوه في جانب العميل، وجمّدوه في نهاية Explore، وتعاملوا مع كل تغيير لاحق كقرار مسعّر، لا كملاحظة في ورشة عمل.
- اعتمدوا العمليات القياسية. كل تخصيص يكلّف مرتين: عند بنائه، ثم في كل ترقية. وفّر عميل في قطاع التصنيع أكثر من $800K بمواءمة عملياته مع معايير SAP بدلًا من التخصيص. كان ذلك مؤلمًا لبعض الإدارات، لكن الفارق المالي كان هائلًا.
- قسّموا النشر إلى مراحل. وفّر عميل في قطاع التجزئة $1.2M بتقسيم النشر إلى ثلاث مراحل على مدى 18 شهرًا بدلًا من تنفيذ كل شيء دفعة واحدة. انخفض الاستثمار الأولي بنسبة 40%، وجعلت دروس المرحلة 1 المراحل اللاحقة أسرع.
- ادفعوا مقابل الخبرة، لا مقابل سعر يومي منخفض. انتقلت شركة كيميائية من عملائي من شريك SAP عام إلى متخصص في القطاع وأنفقت 20% أقل إجمالًا رغم ارتفاع الأسعار بالساعة. عمل المتخصصون بسرعة أكبر وارتكبوا أخطاء أقل.
- احتفظوا باحتياطي الطوارئ في جانبكم. أبقوا 10 إلى 20 في المئة فوق الميزانية، لا يُفرج عنها إلا مقابل مخاطر محددة بالاسم. احتياطي الطوارئ داخل سعر الشريك يُنفق على أولويات الشريك.
- راجعوا طلبات التغيير أسبوعيًا. سعّروا كل طلب من حيث أثره على الميزانية والجدول الزمني قبل الموافقة عليه، لا في نهاية الشهر.
- أتمتوا اختبارات الانحدار. أدوات مثل Tricentis Tosca أو أدوات أتمتة الاختبار الخاصة بـ SAP تسترد كلفتها في أي برنامج يجري أكثر من دورتي اختبار، وكل ترقية بعد التشغيل الفعلي هي دورة أخرى.
للجانب التجاري، تغطي قائمة التحقق للتفاوض على تراخيص SAP ومراجعة تكاليف العقد للمديرين الماليين ما يجب الضغط عليه قبل التوقيع.
أرخص تنفيذ لـ SAP هو الذي لا تضطرون إلى إجرائه إلا مرة واحدة. الوفورات الزائفة التي تؤدي إلى إعادة العمل تكلّف دائمًا أكثر في النهاية.
ينقل نموذج الاشتراك الإنفاق من النفقات الرأسمالية إلى النفقات التشغيلية. لا يزيل خطر التجاوز، لكنه ينقل موضع هذا الخطر.
يعمل GROW with SAP على S/4HANA Cloud Public Edition، الذي لا يسمح بالامتدادات إلا عبر الواجهات المُصدَرة. وهذا يحدّ من مدى نمو قائمة WRICEF، وتستغرق برامج GROW غالبًا نحو 6 إلى 9 أشهر. والمقابل هو حرية أقل في مواءمة SAP مع العمليات غير المعتادة.
يعمل RISE with SAP على S/4HANA Cloud Private Edition، حيث لا يزال بإمكانكم تعديل النواة. هناك تكون النواة النظيفة (Clean Core) قرار حوكمة لا قيدًا تقنيًا، فيكون خطر مرحلة Explore مماثلًا لـ on-premise. تستغرق برامج RISE عادةً من 9 إلى 18 شهرًا، ويجب أن تكون مدة الاشتراك متعددة السنوات ظاهرة في دراسة الجدوى.
الذكاء الاصطناعي بند جديد في الميزانية، لا وفورات تُحتسب مسبقًا. تأتي بعض قدرات Joule مع اشتراكات SAP السحابية، في حين تُسعَّر قدرات الذكاء الاصطناعي المتقدمة بشكل منفصل. اطلبوا افتراض الإنتاجية الذي تستند إليه أي قائمة أسعار لشريك تدّعي وفورات من الذكاء الاصطناعي.
هذا مهم لكيفية تأثير برنامج كبير في قائمة الدخل. وفق IFRS وUS GAAP، يمكن رسملة تكاليف بناء أصل تسيطرون عليه؛ أما تكاليف التشغيل والتدريب والتحضير فلا. والسحابة تغيّر الإجابة بالنسبة إلى جزء كبير من الميزانية.
| عنصر التكلفة | ترخيص on-premise | اشتراك سحابي (RISE / GROW) |
|---|---|---|
| رسوم الترخيص أو الاشتراك | تُرسمل كأصل غير ملموس | تُصرف على مدى العقد (عقد خدمة) |
| خدمات الإعداد والبناء | تُرسمل إذا كانت منسوبة مباشرة | IFRS: تُصرف غالبًا، ما لم تُنشئ أصلًا منفصلًا تسيطرون عليه. US GAAP: تُرسمل تكاليف التنفيذ وتُطفأ على مدى فترة الاستضافة |
| العمالة الداخلية في البناء | تُرسمل إذا كانت منسوبة مباشرة | التقسيم نفسه كما أعلاه |
| التدريب وإدارة التغيير | مصروف | مصروف |
| تنظيف البيانات | مصروف | مصروف |
| أدوات تحويل البيانات التي تحتفظون بها | تُرسمل إذا كانت قابلة لإعادة الاستخدام | تُقيَّم كل حالة على حدة |
| Hypercare والدعم | مصروف | مصروف |
يستند موقف IFRS إلى قرار جدول الأعمال لعام 2021 بشأن تكاليف الإعداد والتخصيص في ترتيبات الحوسبة السحابية الصادر عن لجنة تفسيرات IFRS. ويستند موقف US GAAP إلى ASU 2018-15. ووفق IFRS خصوصًا، فإن دراسة جدوى لـ RISE تفترض رسملة on-premise قد تبالغ في ربح السنة الأولى بشكل جوهري.
التوثيق هو ما يحدد مقدار ما تحتفظون به. وفّر عميل في قطاع التصنيع $2.3M من مصروفات السنة الجارية بالرسملة الصحيحة، لأنه تتبّع أنشطة المستشارين بدقة كافية للدفاع عن هذا النهج. وواجه عميل آخر إعادة إصدار مؤلمة لقوائمه لأنه لم يستطع إثبات قرارات الرسملة.
يدقق المراجعون بعناية في المشاريع الكبيرة المُرسملة. اتفقوا معهم على السياسة قبل بدء البرنامج، لا في نهاية السنة.
معظم البرامج المتجاوزة للميزانية لم تعانِ من فشل في التخطيط. بل عانت من فشل في الصراحة في مرحلة التخطيط. المدير المالي الذي يوافق على خطة واقعية باحتياطي طوارئ مناسب ينفق أقل من الذي يوافق على خطة متفائلة بلا احتياطي.
هذا الدليل جزء من دليلي الشامل لتطبيق SAP، الذي يربط كل المواضيع من دراسة الجدوى إلى التشغيل الفعلي.
لماذا تتجاوز تطبيقات SAP الميزانية؟
في الغالب لأن الميزانية تُبقى منخفضة في البداية، ثم تكشف مرحلة Explore النطاق الحقيقي. تحوّل ورش Fit-to-Standard الفجوات إلى تقارير وواجهات وتحويلات وتحسينات ونماذج ومسارات عمل لم تُسعَّر قط. والنطاق الذي يتحكم فيه المورّد، والفرق الداخلية بدوام جزئي، والعمل المتأخر على البيانات تزيد الأمر سوءًا.
بكم تتجاوز مشاريع SAP الميزانية عادةً؟
في البرامج التي راجعتها، التجاوزات بنسبة 40 إلى 60 في المئة شائعة. ووجد استطلاع Panorama Consulting لعام 2026 أن أكثر من ربع المؤسسات تجاوزت ميزانيات ERP لديها. والبرامج التي تصل إلى مستشار تميل إلى أن تكون الطرف المتعثر من تلك المجموعة.
ما علامات الإنذار المبكر لتجاوز ميزانية SAP؟
أوضح علامة هي عدد WRICEF الذي يظل ينمو خلال مرحلة Explore. ومن العلامات الأخرى وثائق النطاق التي يصوغها المورّد، وطلبات التغيير التي لا تُسعَّر أسبوعيًا، وتحليل البيانات الذي لم يبدأ بعد، والمستخدمون الرئيسيون الذين لا يزالون يعملون بدوام جزئي. أعيدوا تحديد خط أساس الميزانية في نهاية Explore إذا كانت القائمة قد نمت.
كيف توقفون تضخّم النطاق في مشروع SAP؟
امتلكوا النطاق في جانب العميل بدلًا من ترك شركة تكامل الأنظمة تكتبه. جمّدوه في نهاية Explore، وتحدّوا كل فجوة مقابل معيار SAP، وسعّروا كل طلب تغيير قبل الموافقة عليه. راجعوا طلبات التغيير أسبوعيًا، لا في نهاية الشهر.
هل يقلل RISE with SAP خطر تجاوز الميزانية؟
ليس وحده. يعمل RISE على Private Edition، حيث لا يزال بالإمكان تعديل النواة، فيكون خطر مرحلة Explore مماثلًا لـ on-premise. أما GROW with SAP على Public Edition فيحصر الامتدادات في الواجهات المُصدَرة، ما يضيّق مدى نمو النطاق.
هل يمكن رسملة تكاليف تنفيذ RISE with SAP؟
جزئيًا، ويعتمد ذلك على إطاركم المحاسبي. يُصرف الاشتراك نفسه عادةً كمصروف. ووفق IFRS، تُصرف خدمات الإعداد والتخصيص في ترتيب SaaS غالبًا كمصروف أيضًا، ما لم تُنشئ أصلًا منفصلًا تسيطرون عليه؛ أما وفق US GAAP (ASU 2018-15) فتُرسمل تكاليف التنفيذ وتُطفأ على مدى فترة الاستضافة.
الخطوة التالية
هل تدير برنامج ERP الآن؟
إذا مسّ هذا المقال برنامجاً أنت في خضمه الآن، فإن حديثاً مدته 30 دقيقة يوصلك عادةً أبعد من أسبوع آخر من التحليل الداخلي.




