الجدول الزمني لتنفيذ SAP: مدد المراحل و5 أخطاء

يستغرق تنفيذ SAP من 6 إلى 9 أشهر مع GROW with SAP ومن 9 إلى 18 شهراً مع RISE with SAP، من واقع تجربتي. أما الانتقال من SAP ECC فيستغرق من 12 إلى 18 شهراً للتحويل بأسلوب brownfield أو للانتقال الانتقائي للبيانات، ومن 18 إلى 24 شهراً لتنفيذ greenfield.

الإجابة المختصرة: ثبّت الموعد في نهاية Explore، لا عند الانطلاق، وأضف هامشاً من 15 إلى 20 بالمئة فوق تقدير المورّد. ابدأ العمل على البيانات في Discover، لأن ترحيل البيانات يستهلك من 30 إلى 40 بالمئة من جهد التنفيذ. وكل شهر تأخير إضافي يكلّف مبلغاً من ست خانات على الأقل في أتعاب الاستشارات وحدها.

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

في برنامج تصنيع في أوروبا عام 2024، التقيت مدير مشروع كان مشروع SAP لديه متأخراً ستة أشهر عن الجدول. وبعد إعادة الضبط بصرامة وفق مراحل SAP Activate، أنهوا العمل المتبقي في أربعة أشهر.

قال بكلماته: «وجود مراحل واضحة بمخرجات محددة صنع الفرق كله. كنا نعرف دائماً بالضبط ما الذي علينا فعله بعد ذلك.»

نموذج النشر يغيّر الجدول الزمني لتنفيذ SAP أكثر من أي خيار آخر. هذه هي النطاقات التي أخطط على أساسها:

نقطة البداية والهدف	الجدول الزمني المعتاد	ما الذي يحدد الإيقاع
GROW with SAP (SAP Cloud ERP، الإصدار العام)	من 6 إلى 9 أشهر	العمليات القياسية فقط؛ والامتدادات على واجهات API مُصدَرة
RISE with SAP (SAP Cloud ERP Private)	من 9 إلى 18 شهراً	النطاق، وعدد الامتدادات، وحجم البيانات
تحويل ECC بأسلوب brownfield	من 12 إلى 18 شهراً	الشيفرة المخصصة، وبنود التبسيط، والاختبار
تنفيذ greenfield انطلاقاً من ECC	من 18 إلى 24 شهراً	إعادة تصميم العمليات، وعبء التغيير على المستخدمين
الانتقال الانتقائي للبيانات	من 12 إلى 18 شهراً	تحديد نطاق البيانات والأدوات المتخصصة

للمقارنة، يقدّر خبير منتجات في SAP راجع مئات مشاريع الإصدار العام أن التشغيل الفعلي المعتاد يتم خلال خمسة إلى سبعة أشهر. ويستهدف عرض GROW Fast من SAP، الذي أُطلق في مطلع 2026، مدة من شهرين إلى أربعة أشهر بنطاق ثابت. أنا أخطط لبرامج GROW على 6 إلى 9 أشهر، لأن البيانات والقرارات والتدريب تأخذ الوقت الذي لا تأخذه البرمجيات.

مع RISE، تتولى SAP تشغيل البنية التحتية، ما يزيل جزءاً من عمل Prepare. لكنه لا يزيل جهد البيانات أو الاختبار أو التغيير. ويشرح دليل الترحيل من ECC إلى S/4HANA كيف تختار بين brownfield وgreenfield والمسار الانتقائي.

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

أين تنهار الميزانيات والمواعيد

أكبر خطأ أراه هو عدم التخطيط السليم في البداية. تتجاوز المواعيد والميزانيات حدودها في Explore، عندما تكبر قائمة مسارات العمل والتقارير والواجهات والتحويلات والتحسينات والنماذج (WRICEF)، ويصبح المورّد، لا العميل، هو من يتحكم في النطاق.

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

خمسة أخطاء تفسّر معظم التجاوزات. كل منها متوقع، ولكل منها إجراء مضاد.

الخطأ 1: تحديد المواعيد النهائية قبل فهم النطاق

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

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

الخطأ 2: التعامل مع ترحيل البيانات كمسار عمل يبدأ متأخراً

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

الحل: ابدأ تحليل البيانات في Discover، لا في Realize. ونفّذ ترحيلاً تجريبياً كاملاً في Realize قبل بدء اختبار التكامل. ويغطي مقالي حول أسباب فشل ترحيل بيانات SAP دورة الترحيل التجريبي بالتفصيل.

الخطأ 3: تجاوز بوابات الجودة تحت ضغط الجدول الزمني

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

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

الخطأ 4: تدريب المستخدمين قبل التشغيل الفعلي بشهرين

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

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

الخطأ 5: جدولة التشغيل الفعلي خلال دورات الذروة في الأعمال

أطلقت Hershey نظامها المكوّن من SAP R/3 وSiebel وManugistics في يوليو 1999، متأخرة ثلاثة أشهر عن الخطة، ومباشرة في موسم طلبات الهالوين. وأبلغ رئيسها التنفيذي المحللين أن المشكلات ستمنع Hershey من تسليم طلبات هالوين بقيمة 100 مليون دولار.

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

لـ SAP Activate ست مراحل، وهي الهيكل لأي خطة S/4HANA، سحابية كانت أو محلية. المدد أدناه نقاط انطلاق للتخطيط لبرنامج واحد، وليست وعوداً.

1. 1Discoverمن 2 إلى 4 أسابيع. الخروج: نطاق موقّع ومعايير نجاح
2. 2Prepareمن 3 إلى 6 أسابيع. الخروج: ميثاق معتمد والتزامات موارد مكتوبة
3. 3Exploreمن 4 إلى 8 أسابيع. الخروج: قرارات الفجوات لها مالكون والجدول الزمني مثبّت
4. 4Realizeمن 8 إلى 16 أسبوعاً. الخروج: اجتياز الترحيل التجريبي وإغلاق اختبارات التكامل
5. 5Deployمن 2 إلى 4 أسابيع. الخروج: اعتماد UAT وبروفة الإقفال وقرار المضي أو التوقف
6. 6Runمن 4 إلى 8 أسابيع من الرعاية المكثفة. الخروج: العيوب دون الحد المتفق عليه وتوقيع تسليم الدعم

هذا هو جدول المراحل الذي أبدأ منه كل خطة:

المرحلة	المدة المعتادة	ما الذي يحدث	بوابة الخروج قبل الانتقال
Discover	من 2 إلى 4 أسابيع	دراسة الجدوى، والنطاق، وخيار النشر (سحابة عامة أو سحابة خاصة أو نشر محلي)	نطاق موقّع ومعايير نجاح قابلة للقياس
Prepare	من 3 إلى 6 أسابيع	تهيئة الفريق، والحوكمة، وبيئة الأنظمة، والخطة الأساسية، وسجل المخاطر	ميثاق معتمد، وصانعو قرار مسمّون لكل وحدة، والتزامات موارد مكتوبة
Explore	من 4 إلى 8 أسابيع	ورش Fit-to-Standard، وسجل الفجوات، وجرد WRICEF	قرارات الفجوات مسجلة مع مالكيها؛ والجدول الزمني مثبّت
Realize	من 8 إلى 16 أسبوعاً	التهيئة، والتطوير، واختبار الوحدات والتكامل، والترحيلات التجريبية	اجتياز الترحيل التجريبي؛ وإغلاق اختبارات التكامل
Deploy	من 2 إلى 4 أسابيع	اختبار قبول المستخدم، وبروفة الانتقال، وتدريب المستخدمين النهائيين، والتحميل النهائي	اعتماد UAT، واجتياز بروفة الإقفال، وقرار المضي أو التوقف
Run	من 4 إلى 8 أسابيع رعاية مكثفة	الدعم الميداني، والفرز اليومي للمشكلات، والتسليم إلى الدعم	العيوب المفتوحة دون الحد المتفق عليه؛ وتوقيع انتقال الدعم

أين يذهب الوقت فعلاً

يُستعجَل Discover. تحدد الفرق موعداً نهائياً قبل أن تفهم النطاق، وتتجاوز معايير النجاح القابلة للقياس، مثل «تقليص الإقفال الشهري بثلاثة أيام».

في Prepare تبدأ التأخيرات التقنية في النشر المحلي، لأن العميل والشريك يبنيان البنية التحتية. احصل على التزامات الموارد مكتوبة. فالإتاحة الشفهية تتبخر.

في Explore يصبح التوثيق مهماً. فبعد ستة أشهر لن يتذكر أحد لماذا تُعالَج المرتجعات بطريقة معينة ما لم يُكتب القرار ومالكه.

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

تحتاج Deploy إلى خطة انتقال بخطوات وأوقات ومالكين محددين. و«ترحيل البيانات» ليست خطوة.

في برنامج للرعاية الصحية في الولايات المتحدة عام 2023، كان العميل متأخراً ثلاثة أشهر عن الجدول ويواجه تجاوزاً في الميزانية بقيمة 2 مليون دولار. أعدنا الضبط باستخدام ورش Fit-to-Standard من SAP Activate. ووجد الفريق 28 عملية يمكنهم تشغيلها دون أي تخصيص.

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

في برنامج تجزئة في أوروبا عام 2024، اكتشف العميل أن 70 بالمئة من احتياجاته تغطيها عمليات SAP القياسية. وكان يخطط لتخصيصات واسعة حتى رأى النظام وهو يعمل.

وclean core يزيد هذا وضوحاً. ففي الإصدار العام، العمليات القياسية هي الخيار الوحيد، والامتدادات تقع على SAP BTP أو على واجهات API مُصدَرة. وفي الإصدار الخاص والنشر المحلي لا يزال بإمكانك التعديل، لكن عندما تحتاج كل فجوة إلى قرار امتداد له تكلفة، يصبح النقاش حول التخصيص أكثر صدقاً.

كل قطاع يضيف ثقله الخاص. تغطي هذه النطاقات برنامج S/4HANA مؤسسياً كاملاً متعدد المواقع، ولهذا هي أطول من نشر RISE واحد مدته من 9 إلى 18 شهراً:

القطاع	نطاق التخطيط	ما الذي يطيله
التصنيع	من 14 إلى 20 شهراً	جودة قوائم المواد ومسارات التصنيع، وضبط MRP، ومتطلبات QM
التجزئة والسلع الاستهلاكية	من 12 إلى 18 شهراً	تكامل نقاط البيع، وحجم البيانات الرئيسية، ونوافذ موسم الذروة
الصناعات الدوائية	من 16 إلى 22 شهراً	التحقق وفق GxP، وتتبع الدفعات، والترقيم التسلسلي
المرافق	من 15 إلى 20 شهراً	إدارة الأجهزة، وهياكل تعرفة الفوترة، وتكامل GIS وSCADA
القطاع العام	من 18 إلى 24 شهراً	محاسبة الصناديق، وأنظمة المشتريات، وأعباء الموافقات، وإقامة البيانات
السيارات	من 16 إلى 22 شهراً	سلسلة توريد في الوقت المحدد، وضبط التغييرات الهندسية
الطيران والدفاع	من 20 إلى 26 شهراً	التقارير الحكومية، ومحاسبة البرامج، وسلاسل التوريد الآمنة
النفط والغاز	من 18 إلى 24 شهراً	محاسبة المشاريع المشتركة، والعمليات كثيفة الأصول
الخدمات المالية	من 14 إلى 20 شهراً	تصميم الأدوار وفق الفصل بين المهام، والتحقق التنظيمي

ما الذي تغيّره أدوات الذكاء الاصطناعي، وما الذي لا تغيّره

وصل SAP Joule for Consultants إلى الإتاحة العامة في 2025. وهو يجيب عن أسئلة التهيئة من قاعدة المعرفة الخاصة بـ SAP، بما فيها SAP Notes، ويشرح شيفرة ABAP. أما SAP Build Code، المتاح للجميع منذ مارس 2024، فيولّد شيفرة امتدادات Java وJavaScript على SAP BTP باستخدام Joule.

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

هذه هي المخاطر التي أضعها على جدول أعمال البرنامج الأسبوعي. كل منها يحرّك المواعيد إذا تُرك للجنة التوجيهية الشهرية.

1. تغييرات النطاق المتأخرة. ثبّت النطاق في نهاية Explore. وبعد ذلك، يعتمد مجلس ضبط التغيير كل تغيير مع أثره على الجدول الزمني والميزانية.
2. جودة البيانات. تتجاوز معظم الشركات تقييم البيانات أثناء التخطيط. والبيانات الرديئة هي السبب الأكثر تكراراً لفشل الترحيلات التجريبية.
3. اختناقات الموارد. احصل على التزامات مكتوبة من رؤساء الأقسام بأشخاص بأسمائهم وتواريخ محددة. ودرّب بديلاً لكل دور حرج.
4. تأخر القرارات. صعّد الخلافات حول النطاق خلال 48 ساعة. ولا تدع القرارات تنتظر المراجعات الشهرية.
5. إدارة التغيير المتأخرة. ابدأ الحديث مع المستخدمين النهائيين في Prepare، لا قبل التشغيل الفعلي بأسبوعين.

على صعيد الأدوات، SAP Cloud ALM هي منصة SAP لإدارة التنفيذ. وتنتهي الصيانة الأساسية لـ SAP Solution Manager 7.2 في نهاية 2027، مع صيانة ممتدة لوظائف محددة حتى 2030. وقد أُوقف SAP Best Practices Explorer في 2023، ويوجد محتوى العمليات الخاص به الآن في SAP Signavio Process Navigator.

هذا الدليل جزء من دليلي الشامل لتطبيق SAP، الذي يربط كل المواضيع من دراسة الجدوى إلى التشغيل الفعلي.

كم يستغرق تنفيذ SAP S/4HANA؟

من واقع تجربتي، من 6 إلى 9 أشهر مع GROW with SAP (الإصدار العام) ومن 9 إلى 18 شهراً مع RISE with SAP (الإصدار الخاص). ومن ECC، يستغرق التحويل بأسلوب brownfield أو الانتقال الانتقائي للبيانات من 12 إلى 18 شهراً، وتنفيذ greenfield من 18 إلى 24 شهراً.

كم تستغرق كل مرحلة من مراحل SAP Activate؟

كنقطة انطلاق للتخطيط: Discover من 2 إلى 4 أسابيع، وPrepare من 3 إلى 6 أسابيع، وExplore من 4 إلى 8 أسابيع، وRealize من 8 إلى 16 أسبوعاً، وDeploy من 2 إلى 4 أسابيع، وRun من 4 إلى 8 أسابيع من الرعاية المكثفة. وتطول Realize أكثر من غيرها في البرامج الأكبر.

كيف يؤثر RISE with SAP على الجدول الزمني؟

ينقل RISE مسؤولية البنية التحتية إلى SAP، ما يزيل جزءاً من عمل مرحلة Prepare. لكنه لا يختصر ترحيل البيانات أو الاختبار أو التدريب أو اتخاذ القرارات، وهي حيث يذهب معظم الوقت. ويمكن لانضباط clean core أن يختصر Realize إذا أوقف التطوير المخصص قبل أن يبدأ.

كم يجب أن يكون الهامش في الجدول الزمني لتنفيذ SAP؟

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

كيف أختصر الجدول الزمني لتنفيذ SAP؟

طبّق Fit-to-Standard بصرامة، لأن كل تخصيص تتجنبه يوفّر أسابيع. وابدأ تنظيف البيانات في Discover، وخصص موارد من الأعمال بدوام كامل بدلاً من استعارتها بدوام جزئي. وجهّز خطة الانتقال أثناء Realize لا بعدها.

هل أختار طرح big bang أم طرحاً مرحلياً لـ SAP؟

يُطلق big bang كل شيء دفعة واحدة. وهو أسرع إجمالاً وأكثر خطورة، ويناسب النطاقات الأصغر أو المؤسسات ذات إدارة التغيير القوية. أما الطرح المرحلي فيتم حسب الوحدة أو الموقع أو وحدة الأعمال، وهو أقل خطورة وأطول، ويناسب المجموعات الكبيرة متعددة الكيانات.

ما الأسباب الأكثر شيوعاً لتأخر مشاريع SAP؟

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

كم تستمر الرعاية المكثفة بعد التشغيل الفعلي لـ SAP؟

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