تخطّط VISCAP لعمليات الترحيل في SAP وتنفّذها من طرف إلى طرف، وتتعامل مع كل عملية بوصفها قرار أعمال يترتب عليه نقل نظام. نقيّم ما ينتقل معكم وما تستطيع الأعمال استيعابه، ثم نوصي بالمسار الذي تحتمله بيئة أنظمتكم: تنفيذ جديد، أو تحويل نظام، أو انتقال انتقائي للبيانات — ونبقى معكم إلى أن تستقر البيئة الجديدة في الإنتاج.
نُحدّد ما يجري نقله فعليًا — خط الأساس للإصدار، والعمليات، والبيانات، والشيفرة، والواجهات — ثم نحوّل نتائج SAP Readiness Check وعناصر التبسيط إلى توصية بمسار الانتقال، مرفقة بمسوّغاتها.
يحتفظ التحويل بالإعدادات والسجل التاريخي الذي بنيته، بعد معالجة عناصر التبسيط وتكييف الشيفرة المخصّصة وتقليص حجم البيانات. عندها يُنسَّق التحويل التقني وتغيير نموذج البيانات، ويُختبر ويُتحقَّق منه.
حين لا يناسبكم تحويل كامل ولا إعادة بناء من الصفر، ينقل الانتقال الانتقائي ما يستحق النقل وحده: كيانات وشرائح زمنية مختارة، والبيانات الرئيسية والبنود المفتوحة، مع التعامل مع السجل التاريخي بوصفه قرارًا لا خيارًا افتراضيًا. هنا تجري إعادة الهيكلة والمواءمة، وتُسوّى كل دورة قبل تشغيل التالية.
تحمل معظم بيئات SAP شيفرة مخصّصة تفوق كثيرًا ما يشغّله أحد فعلًا. نجردها على الاستخدام الحقيقي، ونسحب من الخدمة ما لا يستدعيه شيء، ونعالج ما يتطلب S/4HANA تكييفه، وننقل ما تبقّى إلى خيارات التوسعة على SAP BTP — لتصبح الترقية التالية مهمة لا برنامجًا.
الترحيل هو اللحظة الوحيدة التي تنفتح فيها الواجهات التي لا يرغب أحد في الاقتراب منها. تُجرد كل وصلة مع أنظمة SAP وغير SAP وتُرشَّد، وينتقل الوسيط البرمجي نحو تكامل تقوده واجهات API على SAP Integration Suite، وتُعاد بناء التقارير وتجربة Fiori — بينما تُدمج التطبيقات القديمة التي لم تعد تستحق مكانها أو تُؤرشف أو تُسحب من الخدمة.
يُتمرَّن على الانتقال إلى النظام الجديد قبل تنفيذه. تُخطَّط فترة التوقف وفق تقويم الأعمال، وتسير الدورة الأخيرة على سيناريو سبق إثباته. ثم تُسوّى النتائج، ويُتحقَّق من العمليات وأدوار الأمان، ويستمر دعم hypercare إلى أن ينبسط منحنى الأعطال ويتسلّم الدعم زمام الأمور.
نراجع الأهداف والأنظمة والعمليات والبيانات والتبعيات، ثم نضع المعايير التي سيُبنى عليها القرار.
نقارن مسارات الترحيل، ونحدّد وجهة النشر، والعمليات المُحتفظ بها، ومتطلبات السجل التاريخي، والبنية المستهدفة.
تُعالَج نتائج الجاهزية، وتُنقّى البيانات وتُقلَّص، وتُكيَّف الشيفرة المخصّصة، وتُرسى حوكمة الاختبار والتسوية والانتقال إلى النظام الجديد.
تُشغَّل دورات الترحيل أو التحويل، وتُتحقَّق البيانات والعمليات، وتُسوَّى النتائج، ويُنفَّذ الانتقال إلى النظام الجديد، ويُنقَل المستخدمون إلى البيئة المستهدفة.
يمتد hypercare ومعالجة الأعطال حتى التسوية النهائية والتسليم إلى AMS أو الدعم، مع سحب الأنظمة القديمة من الخدمة ووضع خارطة طريق للتحسينات.
1,900+ موظف نُقلوا من نظام HRMS قديم، مع ESS وMSS والتكامل مع كشوف الرواتب والمالية.
مزامنة نظامَي SAP أخيرًا — إعادة تنفيذ Employee Central وربطه بـ HCM Payroll عبر CPI.
مقارنة مسارات الترحيل الثلاثة على ما يحسمها فعليًا: التاريخ، والشيفرة المخصّصة، وتحمّل التوقف، والاستعداد لتغيير العمليات.
يمنحكم التقرير عددًا. لكنه لا يخبركم أيّ الكائنات لا يزال مهمًا، وأيّها مهجور، وكم ستكلّف إعادة بنائها.
كل شيء من تقييم الجاهزية للترحيل ومسار الانتقال، مرورًا بتحويل النظام إلى S/4HANA، والانتقال الانتقائي للبيانات وترحيلها، وتحديث الشيفرة المخصّصة وclean core، وتحديث التكامل والتقارير وبيئة الأنظمة، وصولًا إلى الانتقال إلى النظام الجديد والتحقق والاستقرار بعد الترحيل. والأمر يتعلق بما تتركه خلفك بقدر ما يتعلق بما تنقله.
ثلاثة. التنفيذ الجديد يعيد بناء العمليات على معيار SAP، ولا ينقل سوى البيانات التي تستحق النقل. تحويل النظام يمضي بالنظام القائم إلى الأمام بإعداداته وسجله التاريخي كاملَين. ويقع الانتقال الانتقائي للبيانات بينهما، إذ ينقل كيانات أو عمليات أو فترات زمنية مختارة إلى بيئة مُعاد تصميمها. وتعقيد بيئة الأنظمة، ودَين العمليات، وجودة البيانات، والشيفرة المخصّصة، والاستعداد للتغيير هي ما يحدّد الأنسب.
ينقل تحويل النظام المنظومة بأكملها — الإعدادات والشيفرة المخصّصة والبيانات الرئيسية والسجل التاريخي — في عملية واحدة، فيأتي معكم الجيد وغير الجيد. أما الانتقال الانتقائي فينقل نطاقًا محددًا فقط: رموز شركات أو وحدات أعمال بعينها، وشريحة زمنية، والبيانات الرئيسية والبنود المفتوحة، مع بيئة مُعاد تصميمها لا موروثة. التحويل يحمي الاستمرارية؛ والانتقال الانتقائي يمنحكم فرصة إعادة الهيكلة، بكلفة مختلفة.
لا — ترحيل البيانات مسار عمل واحد داخله. فالترحيل يشمل أيضًا قرارات العمليات، ومعالجة الشيفرة المخصّصة، والتعامل مع الإضافات والواجهات، وإعادة بناء التكامل والتقارير، والتحقق من الأمان والأدوار، والانتقال وجاهزية الأعمال. وحين يُعامَل الترحيل كمهمة بيانات فقط، تظهر بقية النطاق متأخرة، بمجال أضيق للتخطيط.
أداة من SAP تحلّل نظامكم وتُبلغ عمّا يفصله عن S/4HANA: عناصر التبسيط، وتوافق الإضافات ووظائف الأعمال، وأثر الشيفرة المخصّصة، وأحجام البيانات، وتطبيقات Fiori المقترحة، واعتبارات التكامل. وهي نقطة انطلاق قوية لا خطة — إذ تحتاج النتائج إلى تفسير وتقدير حجم وأعمال معالجة لها مسؤول.
تُجرد وتُقاس على الاستخدام الحقيقي — تكتشف معظم المؤسسات أن جزءًا كبيرًا منها لم يعد يستدعيه أحد، وهذا مصيره الإلغاء. أما ما يبقى فيُفحص توافقه مع S/4HANA، ثم يُعالَج، أو يُستبدل بوظيفة معيارية، أو يُعاد بناؤه توسعةً: داخل التطبيق، أو عبر توسعة المطوّرين، أو جنبًا إلى جنب على SAP BTP. الغاية: شيفرة أقل، وخارج النواة.
أقل مما تطلبه معظم المؤسسات في البداية. فالمتطلب الحقيقي عادةً هو الاحتفاظ القانوني، وإتاحة التدقيق، وفترة مقارنة عملية للتقارير — لا كل بند منذ إطلاق النظام. نضبط المتطلب وفق تلك الالتزامات، ونلبّي الباقي عبر الأرشفة أو مصدر للقراءة فقط. فكل سنة إضافية تُطيل دورات الترحيل والاختبار والتسوية والتوقف — قرار، لا خيار افتراضي.
تحكمه طبيعة المسار وحالة بيئة الأنظمة لا حجم الشركة: الكيانات والوحدات المشمولة، والشيفرة المخصّصة التي تحتاج معالجة، ونظافة البيانات، والواجهات القائمة، والتوقف الذي تحتمله الأعمال. تحويل مركّز على نظام حسن الصيانة مسألة أشهر؛ أما انتقال انتقائي عبر كيانات متعددة بإعادة هيكلة وتكامل مُحدَّث فيستغرق وقتًا أطول، على موجات مخطط لها. ونضع خطة المراحل وبواباتها ومخرجاتها قبل انطلاق العمل، بدل ذكر مدة مجردة.
نعم. نقيّم أولًا ما إذا كان RISE with SAP وSAP Cloud ERP الخاصة هما الوجهة الصحيحة لبيئة أنظمتكم، ثم نتولى ما لا يشمله الاشتراك: الجاهزية والمعالجة، والشيفرة المخصّصة والتوسعات، ونطاق البيانات، وإعادة بناء التكامل، والاختبار، والانتقال، والاستقرار. النموذج التجاري يغيّر من يشغّل البنية التحتية — لا ما يجب أن يتحقق في نظامكم قبل انتقاله.
تحدّث مع فريق الترحيل في VISCAP عن النظام الذي تغادره، والسجل التاريخي الذي تحتاج إلى الاحتفاظ به، ومسار الانتقال الأقل مخاطرة.
