لماذا يفشل ترحيل بيانات SAP وكيف تصلحه

يفشل ترحيل بيانات SAP لسبب واحد أكثر من غيره: الخطة تُبنى على ما تظنه الأعمال عن شكل بياناتها، لا على ما يُظهره الاستخراج. هذا الدليل موجّه إلى مديري البرامج وقادة البيانات وقادة المالية في برنامج S/4HANA. ويتناول لماذا تنهار عمليات الترحيل، والأخطاء الخمسة وراء معظم إخفاقات الانتقال، وخطة لتحميلات التجربة يمكنك نسخها، وأي أدوات SAP تناسب أي مهمة في 2026. وإذا فعلت شيئاً واحداً هذا الأسبوع، فاستخرج نسخة كاملة من البيانات الرئيسية للعملاء والموردين والمواد وعُدّ السجلات بنفسك.

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

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

لم يكن السبب البرنامج ولم يكن فريق التنفيذ. كان الفشل في الفجوة بين ما ظنّته الأعمال عن شكل بياناتها وما كانت عليه فعلاً.

نموذج بيانات SAP ليس استيراداً مسطحاً. فالسجلات تعتمد بعضها على بعض. للمادة الرئيسية سجل عام (MARA)، وبيانات المصنع (MARC)، وبيانات التقييم (MBEW)، وبيانات منطقة MRP (MDMA) حيثما تُستخدم مناطق MRP. وإذا حمّلت الرأس دون العروض التابعة، فإن المادة موجودة لكن لا يمكن استخدامها في معاملة.

ويضيف S/4HANA قاعدته الخاصة. فالعملاء والموردون هم شركاء أعمال (Business Partners). يتحول العميل القديم إلى شريك أعمال بدور عميل، ويتحول المورّد إلى شريك أعمال بدور مورّد. وترتبط حدود الائتمان والتفاصيل المصرفية والأرقام الضريبية بشريك الأعمال هذا. والسجل الذي كان النظام القديم يتسامح مع ثغراته سيفشل في التحقق هنا.

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

تقدير الأعمالالاستخراج الكامل

سجلات المواد ضمن النطاق500,000+450,000 · +900%

تقدير الأعمال50,000

الاستخراج الكامل500,000

• جرى عدّ كل صنف وكل سجل خاص بالمصنع
• الخطة التي حُجمت على التقدير لا تصمد أمامه

لم تكن تلك مشكلة ترحيل بيانات. كانت مشكلة تحديد نطاق تحولت إلى مشكلة ترحيل.

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

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

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

1. معاملة الترحيل كمهمة تقنية متأخرة

مكان الترحيل في كل مرحلة من مراحل SAP Activate. فمرحلة Explore تحدد النطاق: الكائنات والأنظمة المصدر والأحجام والجودة. ومرحلة Realize تبني القوالب وتشغّل التحميلات التجريبية. ومرحلة Deploy تجري البروفة الأخيرة وتحميل الانتقال. ومرحلة Run تطابق إقفال الفترة الأولى على بيانات حية.

المشاريع التي تبدأ عمل الترحيل في Deploy تبدأه متأخرة بأشهر. وتظهر مشكلات الجودة التي كان ينبغي حلها في Realize في أول تحميل تجريبي، قبل الانتقال بأسابيع. ويبيّن دليلي لتخطيط الجدول الزمني لـ SAP موقع الترحيل في الخطة الإجمالية.

2. مشاركة محدودة جداً من الأعمال

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

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

3. التخطيط لعدد قليل من التحميلات التجريبية

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

4. عدم مطابقة التحميلات التجريبية

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

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

5. تحميل انتقال يختلف عن البروفات

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

والجزء الأقل اختباراً هو عادةً الدلتا (Delta). فبين التحميل التجريبي الأخير والانتقال، تواصل الأعمال إضافة الموردين وتغيير الطلبات وتحريك المخزون. حدّد تاريخ تجميد البيانات ودرّب على تحميل الدلتا ضمن التحميل التجريبي الأخير.

استخدم بنية الدورات هذه نقطة انطلاق. لكل دورة هدف ومعيار خروج، ولا تكتمل حتى توقَّع المطابقة.

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

وحول هذه الخطة، خمسة أمور تصنع الفرق:

1. استخراج كامل في Prepare. كله، لا عينة. حلّل الاكتمال والدقة والاتساق والتكرار، ثم حجّم التنظيف والجدول الزمني من النتائج.
2. ربط كائناً كائناً. لكل كائن (شركاء الأعمال، والمواد، وأوامر الشراء والمبيعات المفتوحة، والبنود المفتوحة، والمخزون، والأصول الثابتة)، وثّق الحقول من المصدر إلى الهدف وقواعد التحويل وفحوصات التحقق وقواعد الاستثناء.
3. أمناء بيانات مسمّون. تملك المالية البيانات المالية للعملاء والموردين. وتملك المشتريات البيانات الرئيسية للمواد. ويملك المستودع المخزون. ويوقّع كل أمين على مجاله بعد كل دورة.
4. مطابقة محددة مسبقاً. اتفق على الأعداد والمجاميع التي تثبت صحة التحميل قبل أول تحميل تجريبي، حتى لا يجادل أحد في ذلك عند الانتقال.
5. تسلسل انتقال مكتوب. التجميد، والاستخراج، والتحويل، والتحميل، والتحقق، وتوقيع الأعمال، وقرار المضي أو عدمه (Go/No-Go). وهو التسلسل نفسه في البروفة الأخيرة.

في تنفيذ S/4HANA جديد، يُعدّ SAP S/4HANA Migration Cockpit الأداة التي توصي بها SAP للتحميل الأولي. ومنذ S/4HANA 2020 يعمل بوصفه تطبيق Fiori باسم Migrate Your Data. والمعاملة LTMC متقادمة، ولا يمكن إلا عرض مشاريع LTMC القائمة. ويقدّم التطبيق نهجين: ترحيل البيانات باستخدام جداول تجهيز (Staging Tables) تُملأ من ملفات أو بأدواتك الخاصة، وترحيل البيانات مباشرة من نظام SAP مصدر. وتستخدم فرق On-Premise والسحابة الخاصة المعاملة LTMOM، أي مصمم كائنات الترحيل، لتعديل الكائنات القياسية أو بناء كائناتها. وقد بُني Cockpit للتحميلات الأولية، لا للواجهات المتكررة أو التغييرات الجماعية.

SAP Data Services هي منصة ETL من SAP. استخدمها للأحجام الكبيرة، ومنطق التحويل الثقيل، والأنظمة المصدر المتعددة، أو حين تريد إطاراً قابلاً لإعادة الاستخدام لجودة البيانات يعيش بعد المشروع.

أدوات ETL من أطراف ثالثة مثل Informatica أو Talend أو Microsoft SSIS منطقية حيث تملكها المؤسسة أصلاً ولديها المهارات.

SAP Datasphere، وهو الآن جزء من SAP Business Data Cloud، ليس أداة ترحيل. مكانه طبقة التحليلات بعد التشغيل الفعلي. وهو مهم إذا تركت السجل التاريخي في النظام القديم وما زلت بحاجة إلى إعداد تقارير عنه.

في معظم التنفيذات القياسية، يغطي Migration Cockpit غالبية الكائنات. أما الأحجام الكبيرة أو الأنظمة القديمة الكثيرة التخصيص أو هياكل المصدر غير المعتادة فتحتاج عادةً إلى Data Services أو أداة ETL إلى جانبه. والتحويلات من ECC تمرين مختلف، يتناوله دليلي للانتقال من ECC إلى S/4HANA.

ما هو ترحيل بيانات SAP؟

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

ما النهج الرئيسية لترحيل بيانات SAP؟

التنفيذ الجديد (Greenfield) يحمّل بيانات رئيسية وبنوداً مفتوحة مختارة في نظام S/4HANA جديد، تاركاً السجل التاريخي في النظام القديم أو في أرشيف. والتحويل المباشر للنظام (Brownfield) يحوّل نظام ECC القائم وسجله التاريخي في مكانه. والانتقال الانتقائي للبيانات يقع بين الاثنين، فينقل رموز شركات أو كائنات أو شرائح زمنية مختارة. ويعتمد الاختيار الصحيح على جودة البيانات ومتطلبات السجل التاريخي ومقدار ما تريد الاحتفاظ به من العملية القديمة.

ما هو SAP Migration Cockpit ومتى تستخدمه؟

SAP S/4HANA Migration Cockpit هو الأداة التي توصي بها SAP للتحميل الأولي للبيانات إلى S/4HANA في جميع الإصدارات. ومنذ S/4HANA 2020 يعمل بوصفه تطبيق Fiori باسم Migrate Your Data؛ والمعاملة LTMC متقادمة. ويوفّر كائنات ترحيل معدّة مسبقاً، ويتحقق من البيانات قبل الترحيل المحاسبي ويبلغ عن الأخطاء على مستوى الحقل. استخدمه للكائنات القياسية بأحجام عادية. وأضف SAP Data Services أو أداة ETL أخرى حين تتجاوز الأحجام أو منطق التحويل أو هياكل المصدر ما تتعامل معه القوالب.

كم تحميلاً تجريبياً ينبغي أن تخطط له عملية ترحيل بيانات SAP؟

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

كيف ترحّل العملاء والموردين إلى SAP S/4HANA؟

بوصفهم شركاء أعمال. ففي S/4HANA تُصان البيانات الرئيسية للعملاء والموردين عبر شريك الأعمال، مع إلحاق دور العميل ودور المورّد به. وفي التنفيذ الجديد يحمّلهم Migration Cockpit عبر كائنات شريك الأعمال لديه. وفي التحويل من ECC، لا بد من إعداد تكامل العميل والمورّد وتشغيله قبل التحويل نفسه.

ما الذي يتسبب في فشل ترحيل بيانات SAP عند الانتقال؟

خمسة أنماط تسبب معظم إخفاقات الانتقال. عدد قليل جداً من التحميلات التجريبية. وتسلسل انتقال لم يُختبر قط من البداية إلى النهاية. وتغييرات في النظام القديم بعد التحميل التجريبي الأخير مع تحميل دلتا غير مختبر. وفجوات مطابقة تُركت مفتوحة. وتوقيع من الأعمال مبني على فحص عيّنة عابرة. «بدت أول 1,000 سجل سليمة» ليس تحققاً. والتشغيل الفعلي يحتاج إلى أعداد ومجاميع مطابَقة.