ما يفعله الاستشاريون فعلاً: نظرة واقعية

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

يطرح السؤال نفسه كلما فكّر أحدهم في دعم خارجي: ما الذي يفعله الاستشاري تحديداً مما لا نستطيع فعله بأنفسنا؟

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

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

وهذا عادةً هو الوقت الذي تأتي فيه المكالمة.

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

1. Exploreورش العمل والفجواتورش Fit-to-Standard وتوثيق الفجوات
2. Realizeالبناء وجولات الشرحالإعداد والتوسعات. ومنتصف المشروع هو الوقت الذي تأتي فيه مكالمات التعافي عادةً
3. Deployفرز عيوب UAT والانتقالفجوة في الإعداد أم في العملية أم في التدريب؟ الفرز هو الذي يحسم
4. Hypercareالتثبيتأول إقفال شهري وطابور المشكلات

نقاط الدخول النموذجية:

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

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

توضيح النطاق والعمليات

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

والحل ليس تقنياً. إنها فجوة في الحوار. والمهمة أن تأخذ مستخدمي الأعمال في جولة عبر الإعداد قبل UAT، وتُعدّ قائمة واضحة بالتغييرات قبل أن يُفتح الاختبار.

هذا ليس مبهراً. هكذا يبدو العمل.

الترجمة بين الفرق التقنية وفرق الأعمال

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

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

دعم UAT

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

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

التثبيت بعد التشغيل الفعلي

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

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

بنية العمل لم تتغير. أما توزيع الوقت فتغيّر.

التوثيق يصوغ نفسه في الغالب. يجيب SAP Joule for Consultants، المتاح عموماً منذ 2025، عن أسئلة الإعداد من قاعدة معرفة SAP نفسها، بما في ذلك SAP Notes، ويشرح شيفرة ABAP. وتصوغ المساعدات المبنية على Joule في SAP Cloud ALM المتطلبات وحالات الاختبار من مواد ورش العمل. فيقضي الاستشاري الوظيفي وقتاً أقل في كتابة الوثائق ووقتاً أكثر في مساءلة استنتاجات ورش العمل.

الشيفرة تُراجَع أكثر مما تُكتب. تصوغ مساعدات المطورين من SAP الشيفرة، بما في ذلك SAP Build Code لتوسعات Java وJavaScript على SAP BTP. ويراجعها الاستشاريون التقنيون الآن ويؤمّنونها ويختبرونها.

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

الغاية من الاستعانة باستشاري لم تتغير. فالاستشاريون الذين أتقنوا هذه الأدوات يقضون وقتاً أكثر في الحكم والتواصل والتصعيد، ووقتاً أقل في أعمال يصوغها الذكاء الاصطناعي الآن بما يكفي. ووصف SAP نفسها لـ Joule for Consultants ملخص عادل لما يغطيه.

الاستشاريون الوظيفيون يتخصصون في وحدات مثل FI وCO وSD وMM وPP وEWM وSuccessFactors. يضبطون النظام حول عمليات الأعمال ويسدّون الفجوة بين معيار SAP ومتطلبات العميل. وقيمتهم هي عمق الوحدة مع معرفة بعمليات الأعمال.

الاستشاريون التقنيون (مطورو ABAP، ومتخصصو SAP BTP، ومعماريو التكامل، وBasis) يبنون التوسعات والتكاملات التي لا يغطيها الإعداد. وفي برامج S/4HANA الحديثة تدفع مبادئ Clean Core التوسعات الجديدة إلى SAP BTP أو إلى واجهات API المُصرَّح بها (Released APIs)، وهذا يحتاج إلى مجموعة مهارات مختلفة عن تعديل ABAP التقليدي.

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

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

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

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

يعرض الجدول الإشارات والمساعدة التي تستدعيها كل إشارة.

الإشارة	ما تعنيه عادةً	المساعدة المطلوبة	ما ينبغي أن يسلّموه خلال أسبوعين
بنود في سجل المشكلات مفتوحة أكثر من أربعة أسابيع دون موعد للحل	مشكلة حوكمة لا مشكلة تقنية	مستشار برنامج مستقل	قائمة قرارات بأصحابها ومواعيدها
التشغيل الفعلي خلال 60 يوماً ولا بروفة للانتقال	انتقال لم يُختبر؛ ولا يمكن تدارك مفاجآت التشغيل الفعلي في الوقت الفعلي	قائد الانتقال أو البرنامج	خطة انتقال جُرّبت بالبروفة ومعايير قرار المضي أو عدمه (Go/No-Go)
توقف أصحاب الأعمال عن الحضور	سيفشل UAT دون تدخل متعمد	قائد التغيير مع قائد وظيفي	جولات شرح مع المستخدمين الرئيسيين وخطة لإعادة إشراكهم
مسار عمل واحد عالق عند معدل الأخطاء نفسه أسابيع	لم يُعثر على السبب الجذري	متخصص في ذلك المسار	تحليل للسبب الجذري وخطة تعافٍ
تقارير شركة التكامل هي المنظور الوحيد لصحة البرنامج	لا فحص مستقل	مستشار في جانب العميل	تقييم صريح لصحة البرنامج للراعي

ماذا يفعل مستشارو SAP فعلاً في المشروع؟

يحللون متطلبات الأعمال، ويضبطون SAP لدعمها، ويسدّون الفجوة بين إعدادات SAP الافتراضية وما تحتاجه الأعمال. في Explore يديرون ورش Fit-to-Standard ويوثّقون الفجوات. وفي Realize يبنون الإعداد ويعملون مع المطورين على التوسعات. وفي Deploy يدعمون UAT ويديرون العيوب ويجهّزون الانتقال. وفي Hypercare يحلّون مشكلات ما بعد التشغيل الفعلي. أما الجزء الغائب عن الأوصاف الوظيفية فهو فرز الفجوات بين المراحل والحفاظ على انضباط التسليم تحت الضغط.

متى تحتاج المؤسسات إلى استشاري فعلاً؟

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

ما الفرق بين مستشار SAP الوظيفي والتقني؟

يضبط الاستشاريون الوظيفيون SAP لدعم عمليات الأعمال في وحدات مثل FI/CO وSD وMM وPP وEWM، ويعملون مباشرة مع مستخدمي الأعمال على المتطلبات. ويبني الاستشاريون التقنيون ما لا يستطيعه الإعداد: توسعات ABAP وBTP، والتكاملات، وإدارة النظام عبر Basis. وتنقل مبادئ Clean Core العمل التقني من تعديلات ABAP داخل النظام نحو توسعات BTP وواجهات API المُصرَّح بها (Released APIs).

كيف تعرف أن الاستشاري يضيف قيمة؟

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

ما أصعب جزء في العمل الاستشاري؟

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

لماذا نستعين باستشاري مستقل إذا كان لدى العميل شركة تكامل أنظمة أصلاً؟

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