من SAP إلى Oracle والعكس: ما لا يخبرك به من جرّب التحويل

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

هذا المقال يتناول ما تتركه تلك العروض خارج الصورة.

لماذا تبدأ الشركات بالبحث: المحرّكات الحقيقية وراء التحوّل في ERP

الرواية المعتادة — "تجاوز عملنا قدرات النظام" — ليست القصة الحقيقية في الغالب. المحرّكات الفعلية أكثر فوضى وأشدّ تحديدًا.

ضغوط الدعم والترخيص. دفع موعد انتهاء الدعم الرئيسي لـ SAP ECC في 2027 شريحةً واسعة من السوق الخليجية إلى وضع التقييم الفعلي، لا لأن S/4HANA أفضل موضوعيًا لحالة الاستخدام لديها، بل لأن الاستمرار على الوضع الراهن بات يحمل تكلفةً في تصاعد مستمر ^[2]. وعملاء Oracle في المقابل يواجهون عمليات تدقيق ترخيص خاصة بهم. حين تظهر تكلفة البقاء في قائمة الأرباح والخسائر، يبدو التحوّل منطقيًا حتى حين لا يكون كذلك.

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

الاستحواذات وإعادة الهيكلة. مجموعة سعودية تستوعب شركة تابعة في الإمارات تعمل على ERP مختلف تحتاج إلى توحيد الأنظمة. شركة أسهم خاصة تستحوذ على عمل يعمل بـ Oracle E-Business Suite قد تفرض الانتقال إلى المنصة التي توحّد بها محفظتها الاستثمارية. هذه المحرّكات الهيكلية مشروعة، لكنها نادرًا ما تأتي مصحوبةً بجداول زمنية واقعية للمشروع.

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

ما يستهين به المتحوّلون باستمرار: قائمة مرتّبة من المفاجآت

إليك ما تكشفه مناقشات Reddit وتقارير ما بعد المشاريع وحوارات الممارسين — مرتّبةً حسب تكرارها وحجم الاستهانة بها:

1. تعقيد هجرة البيانات. كل شركة تعتقد أن بياناتها أنظف مما هي عليه فعلًا. البيانات الرئيسية — العملاء، الموردون، المواد، دليل الحسابات — تتراكم فيها عقود من التناقضات. تنظيفها وتعيينها هو المرحلة الأكثر كثافةً في العمل ضمن أي عملية تحوّل في ERP، وتكاد تُقدَّر دائمًا بأقل من قيمتها الحقيقية في مرحلة إعداد العرض.

2. تكلفة إعادة بناء الواجهات البرمجية. SAP مرتبط بنظام إدارة المستودعات لديك، وبوابة بنكك، وعقدة الفوترة الإلكترونية الحكومية، وCRM الخاص بك. Oracle يتصل بأشياء مختلفة، وبطريقة مختلفة. كل تكامل يجب إعادة تعيينه وإعادة اختباره وإعادة اعتماده. وفي منطقة الخليج تحديدًا، تُضيف الاتصالات بمنصة Fatoora التابعة لـ ZATCA، وأنظمة دفع وزارة المالية، وواجهات تخليص الجمارك متطلباتِ تكامل معتمدة لا وجود لها في حالات التطوير الغربية ^[2].

3. إدارة التغيير. من بنوا الحلول الترقيعية حول النظام القديم سيبنون حلولًا ترقيعية جديدة حول النظام الجديد ما لم تسبقهم إعادة هندسة العمليات. التكنولوجيا لا تُصلح السلوك. اضرب الفوضى في الذكاء تحصل على فوضى مُعبِّرة.

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

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

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

SAP مقابل Oracle وجهًا لوجه: القرارات التي تختلف فعلًا

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

العمق القطاعي مقابل البنية المالية. يمتلك SAP S/4HANA قوالب قطاعية أصلية أعمق في التصنيع والخدمات اللوجستية والمرافق. أما المحرّك المالي لـ Oracle Fusion Cloud — المحاسبة الفرعية، والمعايير المتعددة لإعداد التقارير المالية، والمقاصة بين الشركات — فهو أقوى هيكليًا للمجموعات القابضة المعقدة والخدمات المالية. لا يوجد تفوق مطلق لأي منهما؛ السؤال هو أي الثغرات أكثر تكلفةً لسدّها وفق نموذج عملك تحديدًا ^[2].

البنية السحابية وإقامة البيانات. يُشغّل كل من SAP وOracle الآن مناطق سحابية إنتاجية في الإمارات. وتمتلك كل من Microsoft وGoogle وAWS وOracle بنية تحتية في الإمارات، وسوق الاستضافة المشتركة في الإمارات يتوسع بوتيرة متسارعة ^[3]. القيد لم يعد في الطاقة — بل في الدقة التعاقدية حول إقامة البيانات بموجب المرسوم بقانون اتحادي رقم 45 لسنة 2021 (PDPL). أي التزام من مورّد ERP بشأن سيادة البيانات يجب توثيقه على مستوى العقد، لا على مستوى العرض التقديمي ^[3].

قابلية التوسع وخارطة طريق الذكاء الاصطناعي. يُضمّن SAP وكلاء Joule عبر وحدات سلسلة التوريد والمالية — تناولنا ما يعنيه ذلك تشغيليًا في مقالنا عن وكلاء SAP Joule في سلسلة التوريد. Oracle يُوسّع طبقة الذكاء الاصطناعي عبر Oracle Fusion Analytics وبنية OCI للذكاء الاصطناعي. كلا الخارطتين حقيقيتان؛ وكلتاهما في مرحلة أبكر مما يُوحي به التسويق. لا تشترِ القدرات الذكاء الاصطناعي الحالية لأي من المنصتين — قيّم نضج نموذج البيانات الأساسي الذي تُنتجه، لأن ذلك هو ما سيعمل عليه الذكاء الاصطناعي فعلًا.

نموذج الترخيص والتكلفة الإجمالية للملكية. نموذج الاشتراك في Oracle أكثر قابلية للتنبّؤ بصفة عامة في حالات النشر السحابي الأصيل. تسعير SAP — ولا سيما التعقيدات المتعلقة بـ S/4HANA Cloud Public Edition مقابل Private Edition مقابل RISE — يُفرز تعقيدًا يُفاجئ المشترين عند التجديد بانتظام ^[2]. احصل على نموذج تكلفة إجمالية للملكية لثلاث سنوات من مستشار مستقل قبل توقيع أي منهما.

المتغيّر الخليجي: التوطين وضريبة القيمة المضافة وتعقيد التكامل

هذا هو القسم الذي تتجاوزه دراسات الحالة الغربية كليًا.

يحمل كل من SAP وOracle حزمًا توطين معتمدة لفوترة ZATCA الإلكترونية من المرحلة الثانية في المملكة العربية السعودية وضريبة الشركات في الإمارات ^[2]. على الورق، كلا المنصتين ملتزمتان. على أرض الواقع، تقيم تلك الاعتمادات داخل الإعداد القياسي — وكل تخصيص أضافته مؤسستك يُنشئ فجوة بين الخط الأساسي المعتمد ونظامك الفعلي. ردم تلك الفجوة هو ضريبة التوطين التي يكتشفها المتحوّلون في منتصف المشروع.

تعقيدات خليجية بعينها يجب أن تُسعَّر في أي تحوّل ERP:

• تكامل Fatoora لـ ZATCA المرحلة الثانية. فوترة إلكترونية آنية مع توقيع مشفّر وتخليص قبل تسليم الفاتورة. هذه ليست وظيفة تقارير إضافية؛ بل إنها تبعية تعاملية يجب إعادة بنائها من الصفر في النظام الجديد واختبارها في بيئة المحاكاة لدى ZATCA قبل الإطلاق.
• إقامة بيانات PDPL في الإمارات. إن كانت بيئة SAP أو Oracle الحالية تُعالج بيانات مقيمين في الإمارات، فيجب أن يضمن النظام الجديد تعاقديًا التخزين داخل الدولة. لدى المورّدين مناطق سحابية في الإمارات، لكن العقد يجب أن يكون صريحًا، وخريطة تدفق البيانات موثّقة ^[3].
• تقديم ضريبة القيمة المضافة متعدد الكيانات. المجموعات القابضة الخليجية التي تُقدّم إقراراتها عبر الإمارات والمملكة العربية السعودية والبحرين وعُمان تواجه تعقيدًا في ضريبة القيمة المضافة بين الشركات والعابر للحدود لا تتعامل معه قوالب ERP القياسية بكفاءة. عمل الإعداد مخصّص، ولا ينتقل من منصة إلى أخرى.
• نظام حماية الأجور وتوطين الرواتب. نظام حماية الأجور في المملكة العربية السعودية ومتطلبات الإبلاغ المتعلقة بالإجازات ومكافأة نهاية الخدمة والسعودة معتمدة في كلا المنصتين — لكن فقط في الإصدارات التي نفّذها شريك التطبيق فعليًا. اطلب مراجع حية، لا وثائق المنصة.

العنوان القائل بأن الهجرة تستغرق 12 أسبوعًا ^[1] صحيح — لشركة كيان واحد في تقديم الطعام للطيران، تعمل بحد أدنى من التخصيصات، تنتقل من SAP إلى Oracle Cloud. أما مجموعة سعودية مع ضريبة قيمة مضافة متعددة الكيانات، وMRCLة الثانية من ZATCA، وخمس عشرة سنة من ABAP المخصص، فإن الاثني عشر أسبوعًا هي مرحلة الاستكشاف، لا المشروع بأكمله.

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

رأينا: متى يستحق التحوّل — ومتى لا يستحق

نتقاضى الأتعار ذاتها مقابل التدقيق سواء كانت الإجابة "انتقل" أو "ابقَ". إليك النسخة الصريحة.

انتقل حين:

• تغيّر نموذج عملك هيكليًا — جغرافيات جديدة، هيكل كيانات جديد، التزامات تنظيمية جديدة — والنظام الحالي لا يستطيع دعم النموذج الجديد دون إعادة بناء تكلّف أكثر من 60% من تكلفة الهجرة.
• أعلن مورّد ERP الحالي انتهاء الدعم ومسار الصيانة يتطلب أصلًا تغيير المنصة (وضع SAP ECC 2027 محرّك مشروع).
• أنت على إصدار Oracle E-Business Suite سابق للتكامل السحابي وفريق تقنية المعلومات لديك يتقاعد ومعه المعرفة المؤسسية التي تُبقي النظام يعمل.
• لديك شريك تطبيق بمراجع حية موثّقة في السوق الخليجي على المنصة المستهدفة، تغطي قطاعك الصناعي ومتطلبات الامتثال لديك.

ابقَ حين:

• الألم الجوهري هو دين العمليات: سير عمل متعطّل، وجداول بيانات موازية، وتسويات يدوية. تغيير المنصة ينقل الفوضى. أصلح العمليات أولًا — اقرأ مقالنا عن لماذا لا تحتاج معظم الشركات إلى مزيد من الذكاء الاصطناعي للحجة ذاتها مُطبَّقةً على الأتمتة.
• يمكن إعادة إعداد النظام الحالي وإعادة بناء تكاملاته بتكلفة أقل من 40% من عرض الهجرة. هذا أكثر شيوعًا مما سيعترف به معظم الموردين.
• لا يستطيع فريقك تحديد النتائج التجارية المحددة التي يُتيحها النظام الجديد ولا يستطيعها النظام الحالي — بأرقام، لا بصفات.
• أنت في منتصف مبادرة رقمنة أو ذكاء اصطناعي تعتمد على بيانات نظيفة من ERP. تغيير ERP في منتصف المسار يعادل تشغيليًا استبدال المحركات على ارتفاع الرحلة.

لوحة المعلومات التي تعرض بيانات SAP الخاصة بك لا تتخذ قرارات — طرحنا هذه الحجة في مقال لوحة المعلومات ليست قرارًا. المنطق ذاته ينطبق على قرارات التحوّل في ERP: المنصة ليست صاحبة القرار. العملية التجارية التي تقوم عليها هي القرار.

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