سبعة أطر استشارية لتنفيذ SAP والذكاء الاصطناعي

حين يتعثر برنامج SAP أو الذكاء الاصطناعي، يكون السبب في الغالب بنيوياً، وسبعة أطر بسيطة تكشفه. ارسم خريطة الوضع الحالي. واتفق على من يقرر ماذا بمصفوفة RACI. واربط العمل بقدرات الأعمال. وابحث عن الأسباب الجذرية بأسلوب «لماذا» الخمس. ورتّب المتطلبات بـ MoSCoW. ورتّب المخاطر بحسب ما قد يوقف البرنامج فعلاً. وأجرِ مراجعة لاحقة حقيقية (post-mortem) بعد كل مرحلة. هذا الدليل موجّه إلى مديري البرامج والمستشارين والرعاة في تنفيذ SAP والذكاء الاصطناعي. ابدأ بالجدول أدناه: اعثر على العَرَض الذي تراه واستخدم الإطار المطابق له أولاً.

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

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

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

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

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

طابق العَرَض مع الإطار:

العَرَض الذي تراه	الإطار	ما ينتجه	الجهد المعتاد
وقّع المستخدمون على المتطلبات لكنهم ما زالوا في حيرة	1. رسم الوضع الحالي	خريطة مشتركة لكيفية سير العمل فعلاً اليوم	من 3 إلى 5 أيام من الورش
القرارات تتنقل بين الاجتماعات	2. RACI للقرارات الحرجة	مالكون مسمّون للقرارات الرئيسية، من 20 إلى 30 قراراً	ورشة واحدة، ثم الإنفاذ
ابتعد الرعاة عن «مشروع تقنية المعلومات»	3. رسم خريطة القدرات	التقدم يُعرض كقدرات أعمال	مدمج في Fit-to-Standard
نوع العيب نفسه يتكرر	4. «لماذا» الخمس	سبب جذري يمكنك تغييره	جلسة واحدة بتيسير لكل مشكلة
كل شيء مصنف أولوية عالية	5. MoSCoW	نطاق مرتب مع قائمة Must Have واقعية	جلسة مشتركة واحدة بين الأعمال وتقنية المعلومات
سجل المخاطر يبدو سليماً لكن الفريق متوتر	6. ترتيب المخاطر	قائمتان منفصلتان لمخاطر توقف البرنامج والمخاطر المزعجة	مراجعة أسبوعية مدتها 30 دقيقة
الأخطاء نفسها تتكرر مرحلة بعد مرحلة	7. المراجعة اللاحقة	من ثلاثة إلى خمسة تغييرات بمالكين	نصف يوم بعد كل مرحلة

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

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

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

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

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

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

تمنح مصفوفة RACI (المسؤول عن التنفيذ، والمُساءَل، والمُستشار، والمُطَّلع) كل قرار ومخرج مالكاً. يكون شخص واحد مُساءَلاً، وقد يكون هو المسؤول عن التنفيذ أيضاً أو يفوّضه. ويقدّم المُستشارون مدخلاتهم. ويعلم المُطَّلعون بالنتيجة.

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

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

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

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

في SAP Activate يقابل هذا ورش Fit-to-Standard في Explore. كل عملية ضمن النطاق قدرة، وكل فجوة بين معيار SAP والقدرة المطلوبة قرار: قبول المعيار، أو تهيئة نسخة بديلة، أو التوسيع. والإبقاء على الحوار عند مستوى القدرة يحافظ على انتباه الأعمال طوال البناء، ويكشف قدرات افترض الجميع أنها ضمن النطاق ولم يؤكدها أحد.

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

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

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

1. 01أخطاء التحميل التجريبيالعَرَض
2. 02تعيينات حقول خاطئةلماذا فشل التحميل؟
3. 03مواصفات لم تُراجَع قطلماذا كانت التعيينات خاطئة؟
4. 04مالك عُيّن متأخراًلماذا لم تُراجَع المواصفات؟
5. 05الخطة أغفلت التبعيةلماذا تأخر المالك؟

السبب الجذري قرار حوكمة لا إصلاح بيانات

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

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

يفرض MoSCoW (يجب أن يتوفر Must have، وينبغي أن يتوفر Should have، ويمكن أن يتوفر Could have، ولن يتوفر هذه المرة Won't have) الاختيار. Must Have هو الحد الأدنى اللازم للتشغيل الفعلي. وShould Have مهم لكنه ليس عائقاً. وCould Have مرغوب إذا سمح الوقت والميزانية. وWon't Have مؤجل صراحةً.

والانضباط كله في خط Must Have. الجولة الأولى من تمرين MoSCoW تضع عادةً أكثر مما ينبغي بكثير في Must Have. وإرشادات DSDM من Agile Business Consortium، حيث نشأ MoSCoW، تضع سقفاً قدره 60% من الجهد على Must Have وتحذر من أن تجاوزه يعرّض التسليم للخطر. والفجوة بين الجولة الأولى والقائمة الواقعية هي في معظمها افتراضات لم تُختبر.

شغّل MoSCoW بحضور الأعمال والتقنية في الغرفة نفسها. فإذا شُغّل كل منهما منفصلاً، تتبين قائمة Must Have لتقنية المعلومات وقائمة Must Have للأعمال أنهما غير متوافقتين، ولا يوفّق بينهما أحد إلا بعد أن تبدأ التهيئة.

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

افصل المخاطر التي قد توقف البرنامج عن المخاطر التي تزيده صعوبة. المجموعة الأولى تحتاج إلى مالكين وخطط استجابة ورؤية أسبوعية. والثانية تحتاج إلى مراقبة.

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

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

تمنع المراجعات اللاحقة (post-mortem) بعد مرحلة أو بعد التشغيل الفعلي تكرار الأخطاء نفسها في المرحلة التالية. وهي أيضاً أول ما يُقتطع حين يقع الجدول تحت الضغط.

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

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

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

لم تتغير الأطر. تغيرت طريقة تطبيقها، من ثلاث جهات.

أصبحت الصياغة أسرع، أما الإصغاء فلا. تحوّل أدوات الذكاء الاصطناعي الآن نصوص الورش ووثائق العمليات إلى خريطة أولية خلال دقائق، وتستطيع SAP Cloud ALM صياغة المتطلبات من نصوص Fit-to-Standard. أما الورش نفسها فتستغرق ما كانت تستغرقه دائماً، لأن الإصغاء هو الغاية. والوقت الموفَّر في الصياغة ينبغي أن يُنفق في مساءلة الخريطة مع الناس.

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

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

الحكم المهني فوق هذه الأطر يساوي الآن أكثر لا أقل. وإذا كنت تبني هذه المهارات كمستشار، فإن المسارات المهنية في SAPopedia توضح أيها يهم في كل مرحلة من المسار المهني في SAP.

ما الأطر الاستشارية ولماذا تستخدمها مشاريع SAP؟

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

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

كيف يعمل رسم الوضع الحالي في تنفيذ SAP؟

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

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

ما MoSCoW ومتى يُستخدم في برامج SAP؟

يصنّف MoSCoW المتطلبات إلى Must have وShould have وCould have وWon't have this time. وMust Have هي الحد الأدنى للتشغيل الفعلي، أما Won't Have فتُستبعد صراحةً فلا تتسلل مجدداً.

وهو أكثر فائدة في Explore، حين تقود نتائج Fit-Gap قرارات التوسيع، وفي Realize، حين تتنافس العيوب والتحسينات على وقت البناء. والمشكلة المعتادة هي كثرة Must Have في الجولة الأولى. وتوصي DSDM بألا يزيد جهد Must Have على 60%، وميسِّر يشكك في كل بند منها، بحضور الأعمال وتقنية المعلومات في الجلسة نفسها، يوصلك إلى ذلك.

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

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

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

ما الذي يجعل المراجعة اللاحقة مفيدة بعد التشغيل الفعلي لـ SAP؟

تغييرات محددة وقابلة للتنفيذ للمرحلة التالية. وملخص لما حدث سجل، لا مراجعة لاحقة.

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

كيف تساعد الأطر الاستشارية في تنفيذ الذكاء الاصطناعي في بيئات SAP؟

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

يبيّن رسم الوضع الحالي من يملك البيانات التي يحتاجها النموذج وما جودتها. ويجيب RACI عمن يتحقق من المخرجات ومن يقرر العمل بها ومن يُساءَل حين تكون خاطئة. ويفصل MoSCoW حالات الاستخدام الأساسية عن المثيرة للاهتمام. ابدأ بحالتي استخدام أو ثلاث أساسية بمالكين ومقاييس نجاح واضحة، لا بخمس عشرة دفعة واحدة.