
المحتويات
- كيف كان الوضع في البداية
- ما الذي كان يسير على نحو خاطئ
- التقارير عبر نظامين
- الإقفال الشهري والتجميع
- التقارير التشغيلية
- جدل الأداة
- مقاومة المستخدمين
- التدخل: الحوكمة والنطاق وإدارة التغيير
- لماذا فازت SAP Analytics Cloud في الجدل
- أبرز محطات التنفيذ
- النتائج التجارية بعد ستة أشهر
- الدروس المستفادة
- كيف سيبدو هذا المشروع في 2026
- الأسئلة الشائعة
دراسة الحالة هذه موجهة إلى المديرين الماليين وقادة تقنية المعلومات الذين يشغّلون أكثر من نظام ERP ولا يحصلون على مجموعة أرقام واحدة. الخلاصة: استُعيد في ستة أشهر مشروع تقارير متعثر عبر الحدود بين Oracle في سنغافورة وSAP في بريطانيا. وتحقق ذلك بخمسة أمور. لجنة توجيهية أصغر بصلاحية حقيقية. ونطاق قُلّص إلى التقارير التي تدفع القرارات. وتعريفات متفق عليها في النظامين. وSAP Analytics Cloud طبقةً واحدة للتقارير. ورواد محليون بدلاً من التدريب في القاعات. إن كنت في الموقف نفسه، فابدأ بالحوكمة والتعريفات، لا بجدل الأدوات.
تبدأ القصة بمشروع تحليلات ERP متعثر في مجموعة FMCG معروفة يقع مقرها الرئيسي في سنغافورة. كانت المجموعة تملك حصة 26% في شركة مشروبات الطاقة البريطانية. ورغم أن الحصة أقلية، فإن السيطرة الإدارية كانت في سنغافورة، فكانت استراتيجية مجلس الإدارة في آسيا هي التي تشكّل التقارير والتخطيط اليوميين في أوروبا.
وزادت التقنية الأمر صعوبة. كانت سنغافورة تشغّل Oracle ERP، وبريطانيا تشغّل SAP ERP. كل نظام يعمل بمعزل عن الآخر، وخلقا معاً مشكلة تقارير استهلكت أشهراً من الجهد.
نادراً ما تطابقت الأرقام. وامتدت المطابقات أياماً. وحتى تقرير الإيرادات الأساسي كان يخرج مختلفاً بحسب النظام الذي تراجعه.
وخلال ستة أشهر من بدء مهمة التعافي، تحوّل ما بدا مبادرة فاشلة إلى نموذج تقارير عابر للحدود وثقت به الإدارتان المالية والتشغيلية.
يلخص الجدول نقطة الانطلاق وكيف حُلّت كل مشكلة.
| التحدي | الأثر | الحل باستخدام SAP Analytics Cloud |
|---|---|---|
| نظامان لتخطيط موارد المؤسسات: Oracle في سنغافورة وSAP في بريطانيا | الأرقام غير متطابقة؛ والمطابقة تستغرق أياماً | تغذية نموذج تقارير واحد من النظامين |
| ملكية التقارير غير واضحة عبر الحدود | تصادمت الاستراتيجية في آسيا مع البيانات التشغيلية في أوروبا | مؤشرات أداء موحدة جعلت الكيانين يرفعان المقاييس نفسها |
| بطء تقارير الإيرادات | اختلفت الأرقام باختلاف النظام المصدر وتأخرت القرارات | اختصر التخطيط والتقارير الموحدان الدورة |
| عدم اتساق التخطيط | وضعت سنغافورة الاستراتيجية ونفّذت بريطانيا بافتراضات مختلفة | نماذج التخطيط المشتركة وحّدت الكيانين |
التقارير عبر نظامين
مع Oracle في سنغافورة وSAP في بريطانيا، بدت التقارير كإدارة شركتين منفصلتين. كان فريق المالية يسحب المقياس نفسه من كل نظام فيحصل على إجابات مختلفة. في إحدى المراجعات الشهرية، عرضت سنغافورة رقم إيرادات فاعترضت عليه بريطانيا فوراً برقم آخر. واستغرق الجدال وقتاً أطول من المراجعة نفسها.
عاد الناس إلى Excel لأنه بدا أكثر أماناً: ساعات من التصدير والمطابقة وبناء نسخة كل شخص من الحقيقة. نجح ذلك على المدى القصير، وأنتج تأخيراً مزمناً في تقارير المجموعة. يتناول مقالي عن سبب استمرار المديرين الماليين في اللجوء إلى Excel هذا النمط على نطاق أوسع.
الإقفال الشهري والتجميع
كان الإقفال الشهري أصعب جزء. فالتكلفة التي تقع تحت «العمليات» في أحد النظامين كانت تنتهي أحياناً تحت «الإدارة» في الآخر. رأيت مرة مسودة تجميع ظهر فيها المصروف نفسه مرتين تحت بندين مختلفين. قتل ذلك الثقة بالأرقام. وصار تأخر النتائج هو المعتاد، وحين كانت المجموعة تنشرها كانت التعديلات تتبعها عادة.
التقارير التشغيلية
تجاوزت المشكلات حدود المالية. كان Oracle يتتبع الشحنات وSAP يتتبع المخزون، ولم يكن هناك مصدر واحد. أخبرني مدير مستودع أنه تلقى ثلاثة تقارير مخزون مختلفة في أسبوع واحد، بأرصدة مختلفة كلها. ضحك وهو يقول ذلك، لكن الأمر كان يبطئ قرارات حقيقية. تأخر التزويد، وصار تفسير تأخر الشحن أصعب لأن العمليات لم تكن تثق باللوحات.
جدل الأداة
تحول اختيار أداة التقارير إلى مشروع بحد ذاته. أعجبت بعض المديرين بنسبة كلفة Power BI، وألح آخرون على SAP لطول خريطة طريقها. حضرت ورشة ذهب نصف وقتها في «لماذا SAC وليس Power BI» بدلاً من احتياجات التقارير. استمر الجدل أشهراً واستنزف الزخم.
مقاومة المستخدمين
حتى بعد تشغيل أولى اللوحات، بقي التبني ضعيفاً. أذكر أنني رأيت شخصاً في اجتماع مالي يفتح لوحة، ويلقي عليها نظرة، ثم يغلقها ويعود إلى ملف Excel الخاص به. لم يسأله أحد. يثق الناس بما يعرفونه، ولم تكن اللوحات قد كسبت هذه الثقة بعد.
إعادة ضبط الحوكمة. كانت الاجتماعات تبدو بلا نهاية، وكان الناس يغادرونها دون أن يعرفوا من اتخذ القرار. قلّصت القيادة اللجنة التوجيهية إلى أصحاب القرار الفعليين. صارت الجلسات أقصر وأكثر حسماً، ووصلت التصعيدات إلى المعنيين بسرعة. لم يكن الأمر مثالياً، لكن الأمور بدأت تتحرك. ويعرض دليلي عن إدارة لجنة توجيهية لمشروع SAP المبادئ نفسها.
ضبط النطاق. كان الناس يتجادلون باستمرار حول الأرقام التي تنتمي إلى عرض المجموعة، وصارت قائمة المتطلبات عصية على الإدارة. أذكر سبورة في إحدى الورش امتلأت من طرفها إلى طرفها بالطلبات، وكان نصفها لا صلة له بأي قرار حقيقي. والصياغة التي نجحت: التقارير لا تحتاج إلى تغطية إلا ما يدفع القرارات. وما إن اتُّفق على ذلك حتى تسارع التنفيذ.
تواصل ذو صلة بالمتلقي. كانت التحديثات السابقة عامة، فخرجت المالية والعمليات وتقنية المعلومات بتفسير مختلف لكل منها. انتقلنا إلى تحديثات مفصّلة: جداول زمنية للتقارير للمالية، وتغييرات في عمليات الخدمات اللوجستية للعمليات، وخريطة طريق تقنية لتقنية المعلومات. بدأ الناس يطرحون أسئلة أفضل لأن التحديثات تخاطبهم بلغتهم.
الرواد المحليون. لم يكن التدريب وحده كافياً: كان الناس يجلسون في الجلسات ثم يعودون إلى Excel صباح اليوم التالي. جاء التغيير من الرواد المحليين، وهم زملاء يتمتعون أصلاً بمصداقية في فرقهم، شرحوا اللوحات بشكل غير رسمي وبكلماتهم. حضرت إحدى تلك الجلسات وكان الفرق لافتاً. طرح الناس أسئلة ما كانوا ليطرحوها في قاعة تدريب. وتحسن التبني فريقاً بعد فريق.
يلخص الجدول ما تغيّر ولماذا نجح.
| مجال التركيز | ما الذي تغيّر | الأثر |
|---|---|---|
| إعادة ضبط الحوكمة | قُلّصت اللجنة التوجيهية إلى أصحاب القرار الفعليين؛ وجلسات أقصر وأكثر حدة | اتُّخذت القرارات في الاجتماع؛ وتحركت التصعيدات بسرعة |
| ضبط النطاق | قُلّصت المتطلبات إلى التقارير التي تدفع القرارات | جدل أقل ونماذج بيانات أوضح وأهداف متحركة أقل |
| تواصل مفصّل | تحديثات منفصلة للمالية والعمليات وتقنية المعلومات | فهم كل فريق ما يهمه؛ وعادت الثقة |
| الرواد المحليون | تدريب بين الأقران في مجموعات صغيرة بدلاً من الصفوف الرسمية | تحسن التبني فريقاً بعد فريق؛ وانخفض الاعتماد على Excel |
حين انتهى اختيار الأداة أخيراً، فاز SAC، ويعود ذلك جزئياً إلى قدرته على جلب بيانات Oracle وSAP في نموذج واحد دون تطوير مخصص ثقيل. وقد خفّف ذلك حدة النقاش. وعكست التقارير التغييرات أسرع بكثير من دورة التصدير القديمة. قالت إحدى المراقبات المالية إنها المرة الأولى التي لا تنتظر فيها تحديث البيانات الليلي لتبدأ يومها.
حين رأى المدير المالي بيانات Oracle وبيانات SAP جنباً إلى جنب في لوحة واحدة لأول مرة، زال عنه عبء ثقيل. أنهت تلك اللحظة الجدل.
وغطى SAC أكثر من المالية. أرادت العمليات رؤية للخدمات اللوجستية والمستودعات، وأرادت الموارد البشرية تخطيطاً للقوى العاملة. وكان وجود التخطيط والتقارير والتصور المرئي في منصة واحدة هو الفارق بين حل تكتيكي وأساس طويل الأمد. أعطت القوالب الجاهزة الفريق بداية متقدمة، وإن بدا بعضها عاماً، وأعادت سرعة أول تسليم الثقة بعد أشهر من التأخير.
نقطة تقنية واحدة إن كنت تنوي تقليد هذا التصميم. اتصالات SAC الحية مقتصرة على مصادر SAP مثل SAP HANA وBW وS/4HANA وBPC المضمّن وuniverses في BusinessObjects وSAP Datasphere. أما البيانات غير التابعة لـ SAP، مثل Oracle ERP، فتدخل عادة عبر اتصال استيراد أو universe أو طبقة بيانات وسيطة. حدد هذه البنية مبكراً، لأنها تقرر مدى حداثة أرقام كل جانب.
حين رأى المدير المالي بيانات Oracle وبيانات SAP جنباً إلى جنب في لوحة واحدة لأول مرة، زال عنه عبء ثقيل. كانت تلك اللحظة هي الدليل الذي انتظره المشروع كله.
كان أول إنجاز هو نموذج البيانات. كان على Oracle وSAP أن يغذيا بنية واحدة، وكان ذلك أصعب مما بدا. كانت الحقول تحمل التسمية نفسها لكنها تعني أشياء مختلفة في كل نظام. استغرق الأمر أسابيع من مطابقة التعريفات قبل أن تتفق المالية على المقصود فعلاً بالإيرادات والتكلفة والهامش.
وأُطلقت اللوحات على مراحل. بدأت المالية، ثم المبيعات والعمليات، ولكل منها تقارير مبنية حول عملها الفعلي. بدت النسخ الأولى جامدة أكثر من اللازم. قال المستخدمون ذلك، وكانوا محقين. تحسنت اللوحات، وحلت مؤشرات الأداء المتفق عليها محل ما كان خلافات شهرية متواصلة.
اكتملت إعادة الإطلاق خلال ستة أشهر. وللمرة الأولى، صارت بيانات Oracle وSAP في نموذج واحد داخل SAC. تراجعت خلافات المطابقة، وراجع التنفيذيون الأرقام دون انتظار تداول ملفات Excel.
وأصبحت دورات التخطيط التي كانت تستغرق أسابيع تستغرق أياماً. صار بوسع المخططين نمذجة السيناريوهات ومقارنتها بالفعلي. أراد بعض المديرين تفصيلاً أكبر مما تقدمه اللوحات، لكن مجرد أنهم وثقوا بالأرقام كان مهماً بحد ذاته.
ذكر مدير المستودع أنه، للمرة الأولى، تطابقت مستويات المخزون في تقريره مع ما تعرضه المالية. هذا التوافق الهادئ بين الإدارات هو المؤشر الحقيقي. لم يطلب أحد العودة إلى العملية القديمة.
يسرد الجدول الأخطاء التي أوقفت المشروع والدرس من كل منها.
| الخطأ | ما تسبب فيه | الدرس |
|---|---|---|
| حوكمة غير واضحة | اجتماعات بلا نهاية وبلا قرارات وتأخيرات متراكمة | أعد ضبط الأدوار وصلاحيات القرار مبكراً |
| انجراف النطاق | استمرار تغيّر أهداف التقارير | أبقِ النطاق محدوداً ومرتبطاً بالقرارات |
| تجاهل المستخدمين | فقد المستخدمون الثقة وتباطأ التبني | أشرك المستخدمين مبكراً وزوّدهم بالسياق |
| الإفراط في التخصيص | ضاع الوقت في إعادة بناء التقارير | ابدأ بالقوالب والموصلات القياسية؛ وخصّص لاحقاً |
| ضعف إدارة التغيير | أخطأ التدريب هدفه؛ وبقيت العادات القديمة | استعن بالرواد المحليين والتدريب بين الأقران مبكراً |
ثلاثة دروس تعلو على غيرها. الحوكمة أهم من الأداة: ففي بيئة متعددة الأنظمة، بلا ملكية واضحة تنهار التقارير أياً كانت المنصة. ووحّد تعريفات البيانات قبل اختيار الأداة: فجدل Power BI مقابل SAC أخطأ جوهر المسألة، لأن أي أداة لا تصلح تعريفات غير متطابقة. وإدارة التغيير تقرر التبني: فبلا رواد وتواصل موجّه، كانت اللوحات ستبقى بلا استخدام.
ثلاثة أمور كانت ستتغير لو بدأ العمل نفسه الآن.
ستوضع طبقة بيانات بين SAC والمصادر. يتيح SAP Datasphere، وهو الآن جزء من SAP Business Data Cloud، وصولاً اتحادياً إلى مصادر SAP وغير SAP مع نموذج دلالي فوقها. وفي حالة نظامين مثل هذه، يكون توحيد بيانات Oracle وSAP في تلك الطبقة أنظف من فعله داخل كل story في SAC. كما يمنح SAC اتصالاً حياً بالنموذج الموحد.
ستحل الأسئلة باللغة الطبيعية محل بعض بناء اللوحات. يتيح الاستعلام باللغة الطبيعية في SAC وJoule أن تطلب المالية، مثلاً، الإيرادات حسب المنطقة للربع، سنغافورة مقابل بريطانيا. دون بناء story أولاً. وهذا يسرّع العمل بعد توحيد البيانات. لكنه لا يسدّ فجوة التعريفات.
ستبدأ المحادثة التجارية من عقد ERP. تحقق مما يشمله عقد ERP السحابي لديك من تحليلات قبل التفاوض على SAC. التخطيط الكامل في SAC يُرخَّص بشكل منفصل، والبيئات الهجينة التي يعمل فيها كيان على ERP سحابي وآخر لا يزال يتطلب ترخيصاً دقيقاً.
لن تتغير إعادة ضبط الحوكمة وانضباط النطاق والرواد المحليون والتواصل المفصّل. فهذه الأنماط تصمد أياً كانت التقنية. أما العمل البشري المتمثل في جعل نظامين يرفعان الأرقام نفسها فلا يُؤتمت. وللمزيد عن SAC نفسها، راجع دليلي عن SAP Analytics Cloud.
لماذا تعثر مشروع تقارير ERP في مجموعة FMCG هذه؟
كانت سنغافورة تشغّل Oracle وبريطانيا تشغّل SAP، وكانت المالية كل شهر تجمع الأرقام يدوياً. كان ذلك يستغرق أياماً ولم يثق أحد بالنتيجة تماماً. وتعثرت المراجعات حين عرضت سنغافورة رقماً فاعترضت عليه بريطانيا برقم آخر. وكانت اللجنة التوجيهية كبيرة أيضاً، فلم يتخذ أحد القرارات. ارتفعت التكاليف، وتراجعت الثقة، وانجرف المشروع.
ما الذي غيّر اتجاه التعافي؟
أقرت القيادة بأن المشروع متعثر ووافقت على خطة تعافٍ. قُلّصت اللجنة التوجيهية إلى مجموعة صغيرة من أصحاب القرار الفعليين، وحُددت الأولويات، واختير SAP Analytics Cloud أداة تقارير وحيدة، وأصبح التواصل موجهاً بحسب الجمهور. انتقلت الاجتماعات من اللوم إلى ما يأتي بعده، وبدأ الناس يؤمنون بأن المشروع قادر على التسليم.
كيف تعامل SAP Analytics Cloud مع Oracle وSAP معاً؟
جمع SAC بيانات Oracle وSAP في نموذج تقارير واحد، فظهرا جنباً إلى جنب في لوحة واحدة دون ملفات مطابقة يدوية. ورؤية النظامين في عرض واحد هي اللحظة التي أنهت جدل الأداة. لاحظ أن الاتصالات الحية في SAC تدعم مصادر SAP فقط؛ أما بيانات Oracle فتصل عادة عبر اتصال استيراد أو universe في BusinessObjects أو طبقة بيانات مثل SAP Datasphere.
لماذا قاوم المستخدمون اللوحات في البداية؟
أُطلقت اللوحات دون سياق أعمال كافٍ. قيل للمستخدمين أن يستخدموا SAC، لكن أحداً لم يُرهم كيف ينطبق على عملهم اليومي، وكان التدريب عاماً. يثق الناس بما يعرفونه، ولم تكن اللوحات قد كسبت تلك الثقة بعد. وغيّر الرواد المحليون ذلك حين شرحوا اللوحات بكلماتهم.
كيف يبدو التعافي الناجح لتقارير ERP؟
نادراً ما يكون شيئاً واحداً. في هذه الحالة كان إعادة ضبط للحوكمة وتقليصاً للنطاق وتعريفات متفقاً عليها وتواصلاً مفصّلاً ورواداً من الأقران يعملون معاً. أفاد SAC لأنه جمع النظامين في نموذج واحد دون تطوير مخصص ثقيل، لكن التقنية وحدها ما كانت لتنقذ المشروع. وبعد ستة أشهر، كان من انتظروا انهياره يعرضون لوحات بنوها بأنفسهم.
الخطوة التالية
هل تدير برنامج ERP الآن؟
إذا مسّ هذا المقال برنامجاً أنت في خضمه الآن، فإن حديثاً مدته 30 دقيقة يوصلك عادةً أبعد من أسبوع آخر من التحليل الداخلي.




