إنقاذ مشاريع SAP: كيف تعيدون برنامجًا متعثرًا إلى مساره

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

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

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

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

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

بعض الأنماط التي أعدّها إشارات على الحاجة إلى إنقاذ:

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

أي واحد من هذه يمكن إصلاحه بدفعة. أما اثنان أو أكثر معًا فعادة لا.

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

هذا ما يغطيه كل فحص، وما يخبركم به الاختلاف:

الفحص	ما أنظر إليه	السؤال الذي يجيب عنه	إذا اختلف مع الفحصين الآخرين
حالة البرنامج	الخطة، وتقارير الحالة، وسجل RAID، وطلبات التغيير المفتوحة، والإنفاق مقابل الميزانية	ما الذي يعتقده البرنامج عن نفسه؟	التقارير متفائلة أو منفصلة عن التنفيذ
التصميم	تصميم عمليات الأعمال، ومخرجات Fit-to-Standard، وقائمة WRICEF، وقرارات التصميم المفتوحة	ما الذي وُعد به قطاع الأعمال؟	البناء انحرف عما اتُّفق عليه، أو أن التصميم لم يكتمل قط
ما هو منشور	أنظمة التطوير والاختبار، والتهيئة، وطلبات النقل، والشيفرة المخصصة، وعمليات تحميل البيانات حتى الآن	ما الموجود فعلًا اليوم؟	جرى الإبلاغ عن تقدم في عمل غير موجود في النظام

الفحص الثالث هو الذي تتخطاه معظم المراجعات. وهو يعني الجلوس أمام النظام وتشغيل العمليات، لا قراءة وثائق عن النظام.

تقارير الحالة ووثائق التصميم ادعاءات. أما النظام فهو الدليل.

من يجب أن يجري الفحوص

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

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

في 2018 عملت على إنقاذ برنامج في قطاع الطيران. كانت الوحدات قد نُشرت، لكن لم تُهيأ أي منها بناءً على متطلبات الأعمال.

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

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

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

وهناك سببان آخران يتكرران مرة بعد مرة:

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

أما جانب الميزانية من ذلك، بما في ذلك سبب قفز التكاليف في مرحلة Explore، فيغطيه مقالي عن لماذا تتجاوز مشاريع SAP ميزانياتها. لن أكرره هنا.

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

بمجرد أن تعرفوا الحقيقة، يكون للإنقاذ تسلسل واضح. وتخطي خطوة يعني عادة إجراء الإنقاذ مرتين.

تسلسل إنقاذ برنامج SAP

1. 01

   التشخيص

   الحالة والتصميم وما هو منشور، مقارنة ببعضها.

2. 02

   استعادة النطاق

   نطاق يملكه العميل، مجمّد، مع تسعير كل تغيير.

3. 03

   إعادة خط الأساس

   خطة جديدة واحدة مبنية على الأدلة، مع احتياطي طوارئ في جانبكم.

4. 04

   بوابات المراحل

   بوابة جودة في نهاية كل مرحلة متبقية.

5. 05

   التمرين والانتقال النهائي

   تمارين كاملة قبل تأكيد موعد التشغيل الفعلي.

1. استعيدوا ملكية النطاق

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

اكتبوا النطاق في جانب العميل، وقارنوه بما هو منشور، وجمّدوه. ومن ذلك الحين، يصبح كل تغيير قرارًا مسعّرًا له مالك.

2. أعيدوا خط الأساس مرة واحدة، بناءً على الأدلة

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

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

احتفظوا باحتياطي طوارئ من 10 إلى 20 في المائة في جانبكم، لا يُفرج عنه إلا مقابل مخاطر محددة بالاسم. ويشرح مقالي المكمّل عن تكلفة الانتقال إلى S/4HANA ما يحرك الأرقام.

3. ضعوا بوابة جودة في نهاية كل مرحلة

البرامج المتعثرة انتقلت عادة من مرحلة إلى أخرى بناءً على التواريخ لا على الأدلة. صححوا ذلك.

في SAP Activate، تجري مرحلة Explore ورش Fit-to-Standard، وتدخل متطلبات الفروقات المعتمدة في قائمة أعمال المنتج لمرحلة Realize. إذا غادر البرنامج مرحلة Explore دون تصميم مكتمل، فعودوا وأكملوه. ويدعم SAP Cloud ALM بوابات الجودة كنقاط تفتيش مع قوائم تحقق، تظهر في نظرة المشروع العامة، فلا تحتاج البوابة إلى أن تعيش في جدول بيانات.

4. تمرّنوا قبل الالتزام بموعد

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

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

5. تحققوا من الموعد النهائي الذي تعملون عليه فعلًا

بالنسبة إلى SAP ERP 6.0 على حزم التحسين 6 إلى 8، تنتهي الصيانة الرئيسية في 31 ديسمبر 2027، مع صيانة ممتدة اختيارية حتى نهاية 2030 مقابل علاوة قدرها نقطتان مئويتان (SAP News). وأي إنقاذ يدفع الانتقال من ECC إلى ما بعد 2027 يجب أن يخصص ميزانية للصيانة الممتدة بشكل صريح.

لا تدعوا موعد 2027 يفرض تشغيلًا فعليًا لا تدعمه التمارين. التشغيل الفعلي المتأخر يكلف رسوم صيانة. أما الفاشل فيكلف أكثر بكثير.

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

هذه هي الأسئلة التي أطرحها قبل القرار:

1. هل تستطيعون أن تعرضوا علينا النظام المنشور، مباشرة، مقابل التصميم الموقّع؟ لا بيئة عرض توضيحي ولا شرائح.
2. أي عناصر WRICEF بُنيت واختُبرت ونُقلت، وأيها مُبلغ عنه فقط على أنه منجز؟
3. ما تصميمكم عالي المستوى للإكمال، وأي مراجع يمكننا الاتصال بها أنقذتم فيها برنامجًا مثل برنامجنا؟ المراجع والتصميم عالي المستوى هما الأمران اللذان أطلبهما من أي شريك قبل التوقيع.
4. ما الذي تحتاجونه منا ولا تحصلون عليه؟ القرارات الغائبة والمستخدمون الرئيسيون بدوام جزئي كثيرًا ما يكونون نصف القصة.
5. لعملاء RISE with SAP: أي المشكلات تقع على SAP لا على الشريك، ومن يصعّدها؟

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

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

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

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

ما المقصود بإنقاذ مشروع SAP؟

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

كيف أعرف أن مشروع SAP لدي يحتاج إلى إنقاذ؟

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

ما الذي يجب أن يحدث في الأسبوع الأول من إنقاذ تنفيذ SAP؟

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

هل يجب أن نستبدل شريك تنفيذ SAP خلال الإنقاذ؟

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

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

لماذا تخرج عمليات الانتقال إلى SAP S/4HANA عن مسارها؟

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

هل سيدفع الإنقاذ انتقالنا من ECC إلى ما بعد موعد 2027 النهائي؟

قد يحدث ذلك. تنتهي الصيانة الرئيسية لـ SAP ERP 6.0 على حزم التحسين 6 إلى 8 في 31 ديسمبر 2027، وتمتد الصيانة الممتدة الاختيارية حتى نهاية 2030 مقابل علاوة قدرها نقطتان. خصصوا ميزانية للصيانة الممتدة بدلًا من فرض تشغيل فعلي لا تدعمه تمارينكم.