تقييم مخاطر مشاريع SAP: النسخة العملية

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

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

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

لم تكن المخاطر مفاجآت. كانت موثقة. ولم يتصرف أحد حيالها.

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

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

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

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

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

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

Lidl: نحو 500 مليون يورو على مدى سبع سنوات

بدأت Lidl مشروعها eLWIS على SAP for Retail عام 2011، وشغّلته في بعض الدول الأصغر، ثم تخلت عنه عام 2018 بتكلفة مُعلنة بلغت نحو 500 مليون يورو. وأحد الأسباب التي وردت على نطاق واسع: كانت Lidl تقيّم المخزون بأسعار الشراء، بينما يستخدم نموذج التجزئة القياسي في SAP أسعار البيع بالتجزئة. وفضّلت Lidl التخصيص على تغيير الممارسة، وقالت الشركة إن الأهداف الأصلية لا يمكن تحقيقها بجهد معقول.

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

HP: نحو 400 مليون دولار من الإيرادات الضائعة

في عام 2004 رحّلت HP جزءاً من أعمال الخوادم لديها إلى نظام طلبات وسلسلة إمداد موحّد مبني على SAP. فسقطت الطلبات بين الواجهة الأمامية القديمة وSAP وتطلبت عملاً يدوياً، وتضاعف المتراكم من الطلبات. وقال الرئيس التنفيذي لـ HP إن المشكلات كلّفت مجموعة الخوادم والتخزين نحو 400 مليون دولار من الإيرادات و275 مليون دولار من الأرباح التشغيلية، مخلّفة 120 مليون دولار من الطلبات المتراكمة. وقال مدير تقنية المعلومات في HP لاحقاً إن الفريق خطط لثلاثة أسابيع من الاضطراب وكان ينبغي أن يكون لديه احتياطي طوارئ لمدة من أربعة إلى ستة أسابيع.

الدرس: قدّر احتياطي الطوارئ لانتقال سيئ، لا لانتقال متوسط، وابنِ مخزوناً أو احتياطيات في القنوات قبل أن تنتقل.

Nike: أكثر من 100 مليون دولار من المبيعات الضائعة

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

الدرس: لا تفترض أبداً أن تكاملاً ما يعمل حتى يُشغَّل بحجم الإنتاج وببيانات حقيقية.

التقييم المبني على افتراضات أسوأ من لا شيء، لأنه يخلق ثقة زائفة. ستة مدخلات مهمة:

1. وثائق النطاق: الميثاق والنطاق المعتمد والمتطلبات الموقّعة. وإن لم تكن موجودة، فخطر النطاق مرتفع أصلاً.
2. التزامات الموارد: التزامات مكتوبة من رؤساء الأقسام، ومصفوفة مهارات للأدوار الحرجة، وبديل مسمّى لكل منصب رئيسي.
3. الميزانية والجدول الزمني: ميزانية معتمدة مع احتياطي طوارئ، وجدول زمني مقارَن ببرامج مماثلة. ستة أشهر وتمويل أدنى لطرح كامل خطر ينبغي التنبيه إليه الآن.
4. التزامات المورد: عقود بمستويات خدمة وغرامات. وعلى RISE، مسؤوليات SAP ومسار التصعيد.
5. المنظومة التقنية: التوافق مع الأنظمة القديمة، وتعقيد ترحيل البيانات، ونموذج النشر، وخطة Clean Core لأي عمل مخصص.
6. سجلات المشاريع السابقة: سجلات المخاطر وسجلات المشكلات وتقارير ما بعد المشروع من برامج SAP أو ERP السابقة. فمعظم المخاطر ليست جديدة.

قيّم كل خطر من 1 إلى 5 للاحتمالية والأثر ثم اضرب. والمثال أدناه نقطة بداية نموذجية لبرنامج S/4HANA، وستختلف درجاتك.

الخطر	الاحتمالية (1-5)	الأثر (1-5)	الدرجة	الأولوية
فشل ترحيل البيانات	4	5	20	عالية
تأخر التكامل	4	4	16	عالية
قيود الموارد	4	4	16	عالية
تجاوز الميزانية	3	5	15	متوسطة
شيفرة مخصصة في النواة تعطّل الترقيات	3	5	15	متوسطة
زحف النطاق	4	3	12	متوسطة
فجوات تغطية الاختبار	3	4	12	متوسطة
الأداء تحت الحمل الأقصى	3	4	12	متوسطة
فجوات الامتثال	2	5	10	متوسطة
غياب مسار تصعيد إلى SAP (RISE)	2	5	10	متوسطة
ضعف تبنّي المستخدمين	3	3	9	متوسطة
التعرض لتكلفة الاشتراك أو الترخيص	2	4	8	متوسطة
مؤشرات الأداء غير المتتبَّعة	3	2	6	منخفضة

الدرجات 16 فما فوق تحتاج إلى مالك محدد وإجراء الآن. والدرجات من 8 إلى 15 تحتاج إلى مراقبة مع محفّز تصعيد محدد. وما دون 8، أبقه في السجل دون أن تنفق عليه وقت الأولوية. الدرجات نقطة بداية لا حكم: فجوة امتثال بدرجة 10 قد تصبح 25 في قطاع خاضع للتنظيم.

الدرجة وحدها لا تغيّر شيئاً. يحتاج كل خطر إلى هذه الحقول معبّأة.

الحقل	ما الذي تكتبه	مثال
الخطر	الحدث، في جملة واحدة	لم تُنظَّف بيانات الموردين الرئيسية قبل التحميل التجريبي 2
المالك	شخص واحد محدد	قائد الحسابات الدائنة
الدرجة	الاحتمالية × الأثر	4 × 5 = 20
المحفّز	النقطة القابلة للقياس التي تتصرف عندها	نسبة التكرار أعلى من 5 بالمئة في استخراج التحميل التجريبي 1
الاستجابة	التجنب أو التخفيف أو النقل أو القبول، مع الإجراء	التخفيف: محللان من الحسابات الدائنة على التنظيف لمدة ثلاثة أسابيع
المراجعة التالية	التاريخ	مراجعة المخاطر يوم الاثنين القادم
الحالة	مفتوح، قيد الإجراء، مغلق	قيد الإجراء

ضع التكلفة بمصطلحات واقعية حيثما استطعت. «خطر عالٍ» عبارة غامضة. أما «تأخر أسبوع واحد في UAT يكلف مبلغاً مكوناً من ستة أرقام تقريباً في وقت الفريق وقد يدفع التشغيل الفعلي ثلاثة أسابيع» فيلفت الانتباه.

الشيفرة المخصصة فئة مخاطر قائمة بذاتها. في S/4HANA Cloud Public Edition، لا يمكن كتابة شيفرة مخصصة في النواة. وتمر الإضافات عبر SAP BTP أو واجهات API المعتمدة أو أدوات المستخدم الرئيسي (Key User). وفي السحابة الخاصة وعلى On-premise لا يزال بإمكانك تعديل النواة، والشركاء المعتادون على فعل ذلك سيفعلونه. وهذا الدين التقني يظهر عند أول ترقية كبرى. تتبّع كم من التخصيصات المحددة لها نهج Clean Core متفق عليه، وتحقق من خبرة الشريك في إضافات BTP، وأنشئ منتدى مراجعة بنهاية Explore.

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

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

1. حدد المخاطر عبر الفئات الخمس كلها. أجرِ ورش عمل مع تقنية المعلومات والأعمال والموردين، فكل طرف يرى مخاطر مختلفة. وعلى RISE، أشرك جهات اتصال SAP في ورشة واحدة على الأقل. والمخاطر التي تفوت الفرق عادةً: توقعات مختلفة لدى تقنية المعلومات والأعمال، وتكاملات خارجية محددة بشكل ضعيف، ومالكو UAT غير المتاحين، وتغييرات النطاق غير الرسمية.
2. قيّم كل خطر بحسب الاحتمالية والأثر، بأرقام حقيقية حيثما أمكن.
3. عيّن مالكاً واحداً لكل خطر. شخصاً لا فريقاً. بلا مالك لا تتبع ولا حل.
4. حدد الاستجابة قبل أن يقع الخطر. التجنب أو التخفيف أو النقل أو القبول. «راقب واستجب» ليست خطة. إنها قرار مؤجَّل.
5. راجع أسبوعياً. افحص المخاطر المفتوحة، وأضف الجديدة، وأعد التقييم حيث تغيرت الظروف، وصعّد كل ما اقترب من محفّزه. وارفع أهم المخاطر إلى اللجنة التوجيهية مع قرار مقترح بدلاً من لون.

1. 01حدّدالفئات الخمس كلها
2. 02قيّمالاحتمالية × الأثر، من 1 إلى 5
3. 03عيّن مالكاًشخص واحد لا فريق
4. 04حدد الاستجابةالتجنب أو التخفيف أو النقل أو القبول
5. 05راجع أسبوعياًأعد التقييم، وصعّد قرب المحفّزات

16 فما فوق: مالك محدد وإجراء هذا الأسبوع

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

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

كيف تبني مصفوفة مخاطر لمشروع SAP؟

اسرد المخاطر عبر النطاق والموارد والتقني والجدول الزمني والتبنّي، إضافةً إلى Clean Core والتصعيد إلى SAP على RISE. قيّم كلاً منها بالاحتمالية والأثر من 1 إلى 5 ثم اضرب. اعتبر 16 فما فوق عالياً، ومن 8 إلى 15 متوسطاً، وما دون 8 منخفضاً. وامنح كل خطر متوسط وعالٍ مالكاً ومحفّزاً قابلاً للقياس، مثل «إذا كان إنجاز UAT أقل من 80 بالمئة بحلول الأسبوع 16، يخضع موعد التشغيل الفعلي للمراجعة». وأعد التقييم أسبوعياً وعند كل بوابة مرحلة.

ما أكثر المخاطر شيوعاً في تنفيذات SAP؟

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

متى ينبغي إجراء تقييم المخاطر أثناء مشروع SAP؟

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

من ينبغي أن يملك المخاطر في برنامج SAP؟

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

ماذا يحدث حين يُتخطى تقييم مخاطر ERP؟

على نطاق كبير، تحصل على حالات مثل Lidl التي تخلت عن مشروع SAP للتجزئة عام 2018 بعد نحو 500 مليون يورو. أو HP التي كلّف ترحيل نظام طلبات SAP لديها عام 2004 مجموعة الخوادم نحو 400 مليون دولار من الإيرادات. وعلى نطاق أصغر الآلية نفسها: عدم تطابق نماذج البيانات يُكتشف متأخراً، وتكاملات تفشل عند حجم الإنتاج، وإخفاقات تبنٍّ بسبب تدريب ضعيف. كانت المخاطر قابلة للتحديد قبل أن تتحول إلى مشكلات.