تحديث الأنظمة القديمة في السعودية دون توقف العمل

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

ما الفرق بين طرق تحديث الأنظمة القديمة الأربع؟

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

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

السؤال الذي يفصل بين هذه الخيارات ليس «كم عمر النظام؟» بل: لو توقّف هذا النظام أسبوعاً كاملاً، ماذا سيتوقّف معه؟ كلما كبرت الإجابة، وجب أن تكون الخطة أكثر تدريجاً وأكثر قابلية للعكس.

flowchart TD
  A(["النظام القديم"]) --> B{"لو توقّف أسبوعاً كاملاً، ماذا سيتوقّف معه؟"}
  B -->|"لا شيء حرج"| C(["أعد الكتابة أو غيّر المنصّة"])
  B -->|"إدارة واحدة"| D(["غيّر المنصّة، ثم اخنق الأجزاء المؤلمة"])
  B -->|"العمل كله"| E(["الخنق: استبدال قطعةً قطعة، لا مفتاحاً واحداً كبيراً"])
  E --> F(["كل خطوة قابلة للعكس بمفردها"])

السؤال الواحد الذي يحدّد طريقة التحديث المناسبة لنظامك.

لماذا تفشل مشاريع «الانفجار الكبير» بهذا الانتظام؟

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

الأرقام الموثّقة قاسية. في دراسة شملت أكثر من 5,400 مشروع تقني مع جامعة أكسفورد، وجدت McKinsey أن المشاريع التقنية الكبيرة (بميزانية أولية تتجاوز 15 مليون دولار) تتجاوز ميزانياتها بنسبة 45% في المتوسط، وجداولها الزمنية بنسبة 7%، وتقدّم قيمة أقل بنسبة 56% مما كان متوقعاً، وأن 17% منها تسوء إلى درجة تهدّد وجود الشركة نفسها (McKinsey, 2012). ولا استثناء لأنظمة تخطيط موارد المؤسسات (ERP): فبحسب Gartner، تفشل نسبة كبيرة من مبادرات ERP في تحقيق أهدافها التجارية المقصودة.

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

نمط الخنق: كيف تستبدل نظامك الجوهري وهو يعمل؟

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

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

flowchart LR
  A(["ارسم خريطة النظام كما يعمل فعلاً"]) --> B(["ضع الواجهة أمامه"])
  B --> C(["استبدل شريحة عالية الألم ضيّقة الأثر"])
  C --> D(["شغّل القديم والجديد بالتوازي وقارن"])
  D --> E(["تقدّم نحو القلب أخيراً"])
  E --> F(["أوقف النظام القديم بمعلَم مؤرَّخ"])

مراحل الخنق الخمس: كل واحدة تُسلّم قيمة وتبقى قابلة للعكس.

ماذا تفعل قبل أن تلمس النظام القديم؟

ارسم خريطة ما يفعله النظام فعلاً، لا ما تقوله وثائقه. ثلاث وثائق لا غنى عنها: جرد الواجهات (كل ما يقرأ من النظام أو يكتب إليه)، وقائمة المهام المجدولة (وما ينكسر إن لم تُشغَّل)، وسجلّ سلوك يكتبه المشغّلون شهراً كاملاً بكل حيلة التفافية يستخدمونها.
افصل بين القديم والسيّئ. ليس كل ما هو قديم خطأ؛ بعضه يختزن سنوات من منطق عمل مكتسب بشقّ الأنفس. حدّث ما يكبّلك، واحفظ ما يعمل بصمت وصواب.
احسم مسألة البيانات قبل اختيار المنصّة. الترحيل هو حيث تعيش هذه المشاريع أو تموت: تدرّب عليه شهرياً على نسخة من بيئة الإنتاج، وأبقِ طريق عودة دائماً. وإذا كان النظام يحمل بيانات شخصية، فموقع المنصّة الجديدة مسألة قانونية قبل أن تكون تقنية: دخل نظام حماية البيانات الشخصية (PDPL) حيّز التنفيذ في 14 سبتمبر 2023، واكتملت مهلة الامتثال الكامل في 14 سبتمبر 2024، والجهة التنظيمية هي سدايا (SDAIA)، ويحكم النقل عبر الحدود المادة 29 ولوائح النقل (Morgan Lewis, 2024). احسم توطين البيانات قبل أن توقّع مع أي مورّد.
رتّب الشرائح حسب الألم وضيق نطاق التأثير. ابدأ حيث الألم مرتفع ونطاق الانفجار صغير، وانتصر هناك قبل أن تتقدّم. البنوك تواجه أقلّ الأنظمة الجوهرية تسامحاً على الإطلاق، ونفس منطق الترتيب يسري في دليل تحديث الأنظمة البنكية الجوهرية.
احصل على قراءة مستقلة قبل التعاقد. تقييم تقني قصير يخبرك أي المشاريع الأربعة تواجهه فعلاً، وهل المورّد الذي يقترح إعادة كتابة كاملة يحلّ مشكلتك أم يبيعك منصّته.

مثال محسوب: تحديث نظام فوترة عمره خمسة عشر عاماً

لنفترض أن شركة توزيع سعودية تُصدر 40,000 فاتورة شهرياً من نظام عمره خمسة عشر عاماً، ويعرض عليها مورّد إعادة كتابة مدتها 24 شهراً تنتهي بانتقال واحد. الأرقام افتراضية لتوضيح الشكل.

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

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

أين يفشل تحديث الأنظمة القديمة؟

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

كيف تبدأ التحديث دون المخاطرة بالعمل؟

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

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