تحديث الأنظمة القديمة: الصيانة أم تغيير المنصة أم إعادة البناء أم الاستبدال؟

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

يتناول هذا الدليل مؤشرات التحذير، والخيارات المتاحة، وكيفية الاختيار بينها، وضوابط المخاطر التي تحول دون تعطيل التحديث للعمليات.

مؤشرات حاجة النظام القديم إلى إجراء

التقادم وحده ليس سببًا للتحديث؛ فالنظام المستقر والآمن والمدعوم والنادر التغيير قد يكون الأفضل تركه كما هو. وتحرّكوا حين تظهر المؤشرات الآتية:

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

فإذا انطبق عدد من هذه المؤشرات على نظام تعتمد عليه الأعمال يوميًا، فإن عدم فعل شيء يكون في الغالب الخيار الأخطر.

خيارات التحديث

كثيرًا ما تصف أطر الترحيل السحابي والتحديث هذه الخيارات بمجموعة «Rs». فعلى سبيل المثال، تتمثل الاستراتيجيات السبع (7 Rs) في الإرشادات التوجيهية من AWS، وهي من أكثرها تداولًا، في: الإيقاف (Retire)، والإبقاء (Retain)، وإعادة الاستضافة (Rehost)، وإعادة التوطين (Relocate)، وإعادة الشراء (Repurchase)، وتغيير المنصة (Replatform)، وإعادة الهيكلة (Refactor). أما في تحديث التطبيقات عمومًا، فتبدو الخيارات العملية على النحو الآتي، من الأقل تغييرًا إلى الأكثر:

الإبقاء والصيانة

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

التغليف بواجهات API

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

إعادة الاستضافة (Rehost)

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

تغيير المنصة (Re-platform)

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

إعادة الهيكلة أو إعادة التصميم المعماري (Refactor)

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

إعادة البناء (Rebuild)

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

الاستبدال بنظام ERP أو منتج SaaS

أوقفوا النظام المخصص وانقلوا إجراءاته إلى نظام ERP جاهز أو منتج SaaS. ويناسب ذلك الأنظمة التي تدعم إجراءات قياسية، مثل المالية والمشتريات والمخزون والموارد البشرية، تتعامل معها المنتجات الجاهزة جيدًا. ويحقق أفضل النتائج بعد تحليل الملاءمة والفجوات (Fit-Gap) الذي يبيّن مدى توافق إجراءاتكم مع المنتج؛ اطّلعوا على دليلينا حول تحليل الملاءمة والفجوات في ERP واختيار نظام ERP في المملكة العربية السعودية.

الإيقاف (Retire)

بعض التطبيقات القديمة، أو أجزاء منها، لم تعد مطلوبة. أرشفوا بياناتها بصيغة قابلة للقراءة لأغراض التدقيق والاحتفاظ، ثم أوقفوها.

معايير القرار

قيّموا كل نظام وفق المعايير نفسها، ويُفضَّل أن يحضر التقييمَ أصحابُ الأعمال وفريق تقنية المعلومات معًا:

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

مصفوفة القرار

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

الاستبدال التدريجي بنمط «التين الخانق» (Strangler Fig)

يُحوِّل الاستبدال الشامل دفعة واحدة كل شيء في تاريخ واحد، فإذا وقع خطأ شعرت به الأعمال كلها. والبديل هو نمط «التين الخانق»، الذي وصفه Martin Fowler ووثّقه مركز Microsoft Azure للبنية المعمارية: بناء النظام الجديد إلى جانب القديم ونقل الوظائف إليه تدريجيًا حتى يمكن إيقاف النظام القديم.

وعمليًا:

1. ضعوا واجهة وسيطة (Façade) في المقدمة. يصل المستخدمون والأنظمة الأخرى إلى التطبيق عبر طبقة توجيه أو مجموعة من واجهات API، بحيث يمكن إرسال الطلبات إلى النظام القديم أو الجديد دون أن يلاحظ المستخدمون.
2. اختاروا الجزء الأول. اختاروا وظيفة واضحة الحدود، مثل تقرير أو شاشة استعلام أو نوع واحد من المستندات، بمدخلات ومخرجات واضحة.
3. ابنوه ووجّهوا الطلبات إليه. نفّذوا الجزء في النظام الجديد ووجّهوا طلباته إليه، مع إبقاء المسار القديم متاحًا.
4. عالجوا البيانات المشتركة. حدّدوا أي النظامين يملك كل جزء من البيانات خلال المرحلة الانتقالية، وزامنوا البيانات حيث يحتاج إليها النظامان. ويمكن لطبقة مُواءمة أن تترجم بين نموذجي البيانات القديم والجديد حتى لا تتسرب أعراف النظام القديم إلى التصميم الجديد.
5. كرّروا ثم أوقفوا. انقلوا الأجزاء واحدًا تلو الآخر، ثم أوقفوا النظام القديم حين لا يعتمد عليه شيء.

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

التشغيل المتوازي والتحقق من ترحيل البيانات والتراجع

التشغيل المتوازي

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

التحقق من ترحيل البيانات

نقل البيانات هو الموضع الذي تتعثر فيه مشاريع تحديث كثيرة. تحققوا على طبقات:

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

واحتفظوا بالنتائج والاعتمادات أدلةً للتدقيق، ولا سيما في ظل ISO 9001 أو أنظمة الإدارة المماثلة.

ضوابط المخاطر والتراجع

• حدّدوا معايير قرار المضي أو التوقف (Go/No-Go) كتابيًا، مع تسمية صاحب القرار.
• خذوا نسخًا احتياطية كاملة من النظام القديم وتحققوا منها قبيل الانتقال مباشرة.
• جمّدوا التغييرات على النظام القديم خلال نافذة الانتقال.
• أبقوا النظام القديم متاحًا للقراءة فقط بعد الانتقال، حتى يمكن الرجوع إليه، وإعادة تفعيله عند الضرورة.
• اتفقوا على نقطة التراجع: آخر لحظة يمكنكم فيها العودة إلى النظام القديم، وكيفية التعامل مع المعاملات المُدخلة في النظام الجديد.
• خطّطوا لفترة دعم مكثف بعد التشغيل (Hypercare)، مع مسار واضح للمستخدمين للإبلاغ عن المشكلات.
• أرشفوا بيانات النظام القديم بصيغة قابلة للقراءة لأغراض التدقيق والاحتفاظ بعد إيقافه.

خطوات التحديث خطوة بخطوة

1. احصروا وقيّموا. دوّنوا وظائف النظام ومستخدميه وتكاملاته وبياناته وبنيته التحتية وحالة دعمه، ووثّقوا مخاطر الأعمال.
2. قيّموا وفق المعايير. قدّروا الأهمية، وتواتر التغيير، ومخاطر المهارات، وحالة الدعم، وجودة البيانات، والتكاملات، والامتثال.
3. اختاروا المسار لكل مكوّن. استخدموا مصفوفة القرار، وتقبّلوا أن تسلك أجزاء مختلفة مسارات مختلفة.
4. ثبّتوا الاستقرار أولًا. انسخوا احتياطيًا، وحدّثوا أمنيًا، ووثّقوا، ووزّعوا المعرفة، حتى يبقى النظام القديم آمنًا أثناء تحديثه.
5. ابدأوا تنظيف البيانات مبكرًا. عالجوا التكرارات والرموز غير المتسقة في المصدر قبل بدء التجارب التحضيرية للترحيل.
6. سلّموا تدريجيًا. استخدموا نهج «التين الخانق» حيثما أمكن، بإطلاق جزء واحد في كل مرة.
7. تحققوا وشغّلوا بالتوازي ثم انتقلوا. طابقوا البيانات، وقارنوا المخرجات، وطبّقوا معايير المضي أو التوقف، وأبقوا التراجع متاحًا.
8. أوقفوا وأرشفوا. أوقفوا النظام القديم وأبقوا بياناته متاحة للتدقيق.

أخطاء شائعة

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

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

ما المقصود بتحديث الأنظمة القديمة؟

هو تحديث البرمجيات المتقادمة أو استبدالها لتصبح قابلة للدعم وآمنة وقادرة على مواكبة تغيّر الأعمال، بدءًا من صيانتها وتغليفها بواجهات API وصولًا إلى تغيير منصتها أو إعادة بنائها أو استبدالها.

هل الأفضل إعادة البناء أم الاستبدال بنظام ERP؟

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

هل يمكننا التحديث دون إيقاف العمليات؟

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

كيف نعرف أن البيانات المرحّلة صحيحة؟

طابقوا أعداد السجلات والمجاميع الرقابية، مثل ميزان المراجعة والأرصدة المفتوحة، وتحرّوا كل فرق، وافحصوا عيّنات من السجلات حقلًا بحقل، واطلبوا اعتماد مالكي البيانات. ونفّذوا الترحيل تجريبيًا عدة مرات قبل الترحيل الفعلي.

ماذا لو غادر المطوّرون الأصليون؟

ابدأوا بتثبيت استقرار النظام وتوثيقه: استعيدوا الشيفرة المصدرية، وارسموا نموذج البيانات، ودوّنوا قواعد الأعمال من المستخدمين ومن الشيفرة نفسها. ويمكن لأدوات تحليل الشيفرة، بما فيها الأدوات المدعومة بالذكاء الاصطناعي، تسريع الفهم، لكن ينبغي أن يؤكد النتائجَ أشخاصٌ يعرفون الأعمال.

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