تحديث أنظمة ERP والخروج من SAP ECC: الهندسة المحيطة بالترحيل التي لم يحسبها أحد

في كل مشروع ترحيل لنظام ERP مشروعان. الأول هو الذي في الخطة (النظام الجديد، وتصميم العمليات، وشريك التكامل) والثاني هو الذي يظهر في الشهر الرابع، حين يجلس أحدهم ويعدّ الواجهات.

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

لماذا صار هذا على الجدول الآن

تنتهي الصيانة الرئيسية لنظام SAP ECC 6.0 في 31 ديسمبر 2027. والصيانة الممتدة قد تحمل الشركة حتى نهاية 2030، بعلاوة سعرية وبنطاق مخفَّض. وجزء كبير من القاعدة المثبَّتة لم يبدأ بعد، وعمليات الترحيل تستغرق عادةً بين ثمانية عشر وستة وثلاثين شهراً، وقدرات الشركاء ومزوّدي السحابة الكبار على تنفيذها تُحجز الآن.

والضغط نفسه قائم خارج عالم SAP. عملاء Oracle EBS يواجهون أفق دعم خاصاً بهم، وتثبيتات Dynamics AX وNAV تُدفع نحو Business Central وDynamics 365، وهناك ذيل طويل من الشركات تشغّل نظام ERP خُصِّص بعمق قبل عقد على يد أشخاص غادروا منذ ذلك الحين.

وأياً كانت الوجهة، شكل المشكلة واحد: نظام ERP ليس جزيرة، وما هو متصل به غير موثَّق في الغالب.

ما الذي نقوم به

اكتشاف الواجهات وحصرها

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

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

إعادة بناء طبقة التكامل

نعيد بناء الواجهات التي يجب أن تبقى، ونفضّل بناءها مقابل طبقة تجريد بدل توجيهها إلى النظام الجديد مباشرة. وجود طبقة تكامل بين تطبيقاتك التابعة ونظام ERP يعني أن الترحيل التالي (وسيكون هناك ترحيل تالٍ) لن يكرر هذا التمرين. كما يتيح لك نقل التطبيقات على موجات بدل عطلة تحويل واحدة.

يمتد العمل هنا إلى واجهات IDoc وBAPI، وخدمات OData، ونقاط SOAP من حقبة سابقة، وتبادلات الملفات المسطّحة وSFTP التي ما زالت تدير نصف التعاملات الأوروبية بين الشركات، وطوابير الرسائل، وواجهات REST الحديثة على الجانب الجديد.

هندسة ترحيل البيانات

استخراج وتنظيف وتحويل وتحميل، ثم (وهو الجزء الذي يُستهان به عادةً) التسوية. نبني الترحيل كوداً قابلاً للتكرار لا سكربتاً لمرة واحدة، حتى يمكن تشغيله عشرات المرات على بيانات تزداد نظافة، مع مقارنة النتائج آلياً في كل مرة.

التسوية هي مكمن المصداقية. الإدارة المالية لن تعتمد ترحيلاً لأن التحميل نجح؛ بل تعتمده لأن الأرصدة متطابقة والأعداد متطابقة والفروق الباقية مفسَّرة ومقبولة كتابةً.

التطبيقات المخصصة التي تعمّر بعد نظام ERP

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

نساعدك على التمييز بين النوعين، ثم نبني ما يستحق البقاء.

التقارير وحقل البيانات الظليّ

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

إيقاف التشغيل والاحتفاظ بالبيانات

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

ما الذي لا نقدّمه

لسنا شركة استشارات وظيفية في SAP. لا نضبط وحدات FI/CO، ولا نصمم قوالب عملياتك، ولسنا الشريك الذي يدير برنامج S/4HANA. هذه أدوار تخصصية وينبغي أن تتعاقد مع مختص لها.

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

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

أين نعمل

إلى جانب برنامج S/4HANA: إعادة بناء التكاملات، وهندسة ترحيل البيانات، والعمل على التطبيقات التابعة، وإيقاف تشغيل المنظومة القديمة.

الترحيل بعيداً عن SAP كلياً: إلى Odoo أو Dynamics 365 Business Central أو ERPNext أو Netsuite أو نظام خاص بالقطاع، وهو الأكثر شيوعاً بين الشركات المتوسطة التي يكون S/4HANA بالنسبة لها غير متناسب. وهنا يشكّل عمل التكامل والبيانات معظم المشروع.

منظومات Oracle وDynamics AX/NAV وInfor التي تواجه ضغط دورة الحياة نفسه باهتمام أقل.

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

كيف تسير التعاقدات

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

البناء، بالتوازي مع البرنامج الرئيسي: طبقة التكامل، وخط الترحيل، وإعادة بناء التطبيقات، وفق جدولك ومقابل تاريخ التحويل لديك.

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

إيقاف التشغيل، بعد استقرار النظام الجديد واعتماد الأرشيف.

التقنيات

Java و.NET وPython وNode.js وPHP على جانب التطبيقات؛ وتقنيات واجهات SAP بما فيها IDoc وBAPI وRFC وOData؛ ووسائط برمجية منها MuleSoft وApache Camel وKafka وAzure Integration Services؛ وSQL Server وOracle وDB2 وHANA وPostgreSQL؛ وAWS وAzure. وحيث تعمل المنظومة القائمة على شيء أقدم (Delphi أو VB6 أو PowerBuilder أو COBOL بجوار نظام ERP) فذلك أرض مألوفة لا مفاجأة.

الأسئلة الشائعة

متى ينتهي دعم SAP ECC بالضبط؟

تنتهي الصيانة الرئيسية لنظام SAP ECC 6.0 في 31 ديسمبر 2027. والصيانة الممتدة متاحة حتى نهاية 2030 بتكلفة إضافية ونطاق مخفَّض. تحقق من التفاصيل الخاصة بحزمة التحسين وعقدك مع SAP مباشرة، فالشروط تختلف.

عيّنّا شريك تكامل بالفعل. أين موقعكم؟

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

هل الانتقال بعيداً عن SAP كلياً واقعي؟

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

كم يستغرق جرد الواجهات؟

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

هل يمكنكم إبقاء النظام القديم متاحاً للتدقيق بعد إطفائه؟

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

وإذا قررنا تأجيل الترحيل؟

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

ابدأ الآن

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

تواصل معنا لتحديد نطاق استكشاف الواجهات والبيانات.

خدمات ذات صلة

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