هناك رقم يجب أن يرعب كل مسؤول تقنية في القطاع المصرفي والتأمين: من 60 إلى 80 بالمائة. هذه هي حصة ميزانيات تكنولوجيا المعلومات التي تنفقها معظم المؤسسات المالية على صيانة الأنظمة القديمة — ليس لبناء قدرات جديدة، وليس للابتكار. فقط للحفاظ على الأضواء مشتعلة.
لقد أمضيت أكثر من 12 عاماً في بناء وتحديث البرمجيات المؤسسية لمنظمات في القطاع المالي والتأمين والدفاع والطاقة. رأيت منصات مصرفية أساسية بلغة COBOL كُتبت قبل وجود الإنترنت. ورأيت ما يحدث عندما تقرر المؤسسات أخيراً التحديث — النجاحات والإخفاقات المذهلة على حد سواء.
التكلفة الحقيقية للحفاظ على الأنظمة القديمة
دعوني أكون صريحاً: أكبر تكلفة للأنظمة القديمة ليست الصيانة. إنها تكلفة الفرصة البديلة. كل دولار وكل ساعة مهندس تُنفق في ترقيع نظام عمره 25 عاماً هي دولار وساعة لا تُستثمر في منتجات رقمية يمكن أن تفتح مصادر إيرادات جديدة.
التكاليف المرئية
- عقود الصيانة: يفرض مزودو الأنظمة القديمة أسعاراً متميزة. رأيت عقود دعم تكلف 2-5 مليون دولار سنوياً.
- الكفاءات المتخصصة: مطورو COBOL يتقاعدون أسرع مما يمكن استبدالهم. المتوفرون يطلبون 150-250 دولار/ساعة.
- عبء التكامل: كل منتج رقمي جديد يحتاج اتصالاً بالأنظمة القديمة عبر تكاملات هشة.
- عبء الامتثال: تلبية المتطلبات التنظيمية الجديدة (DORA، PSD3) على البنية القديمة تتطلب حلولاً بديلة فوق حلول بديلة.
التكاليف الخفية
- سرعة الوصول للسوق: ميزة تستغرق أسبوعين في شركة فنتك تستغرق 6-12 شهراً في بنك مقيد بالأنظمة القديمة.
- استقطاب المواهب: أفضل المهندسين لا يريدون العمل على COBOL.
- التعرض الأمني: الأنظمة القديمة غالباً لا تدعم بروتوكولات الأمان الحديثة.
- صوامع البيانات: البيانات الحيوية محتجزة في أنظمة لا تتواصل مع بعضها.
رأي ميكيلي
أقول لكل مسؤول تنفيذي نفس الشيء: السؤال ليس هل يمكنكم تحمل تكلفة التحديث. السؤال هو هل يمكنكم تحمل عدم التحديث. كل شهر تتأخرون فيه، شركات الفنتك تبني المستقبل الذي سيطالب به عملاؤكم.
الاستراتيجيات الخمس للتحديث (ومتى تستخدم كل منها)
1. التغليف (واجهة API)
ما هو: تحافظ على النظام القديم لكن تغلفه بواجهات API حديثة. الأفضل لـ: الأنظمة المستقرة لكن صعبة التكامل. المخاطرة: منخفضة.
2. إعادة الاستضافة (النقل للسحابة)
ما هو: نقل النظام للسحابة دون تغيير الكود. المخاطرة: منخفضة إلى متوسطة.
3. إعادة المنصة (تحديث البنية)
ما هو: الانتقال إلى منصة حديثة — مثل الانتقال من Oracle إلى PostgreSQL السحابي. المخاطرة: متوسطة.
4. إعادة الهيكلة (نمط Strangler Fig)
ما هو: استبدال أجزاء من النظام القديم تدريجياً بخدمات حديثة. هذا هو النهج الذي أوصي به لمعظم المنصات المصرفية. المخاطرة: متوسطة.
Strangler Fig في الممارسة
قدت مشاريع حيث استخرجنا خدمة مصغرة واحدة في كل مرة من منصة تأمين متجانسة. في 18 شهراً، 60% من النظام كان يعمل على بنية حديثة. صفر توقف. صفر فقدان بيانات.
5. الاستبدال (إعادة الكتابة الكاملة)
ما هو: بناء نظام جديد بالكامل من الصفر. المخاطرة: عالية.
تحذير
فخ إعادة الكتابة الكاملة: رأيت مشاريع تحديث تفشل بسبب إعادة الكتابة الشاملة أكثر من أي سبب آخر. قاعدتي: أعد كتابة ما يمكنك تحمل خطأه لمدة 6 أشهر فقط.
إطار القرار: أي استراتيجية لأي نظام؟
| العامل | التغليف | إعادة الاستضافة | إعادة المنصة | إعادة الهيكلة | الاستبدال |
|---|---|---|---|---|---|
| منطق الأعمال سليم | ✓ | ✓ | ✓ | ✓ | — |
| الكود قابل للصيانة | ✓ | ✓ | جزئي | — | — |
| نحتاج واجهات حديثة | ✓ | — | — | ✓ | ✓ |
| نطاق الميزانية | $200K-500K | $100K-300K | $300K-800K | $500K-2M | $1M-5M+ |
| الجدول الزمني | 2-4 أشهر | 1-3 أشهر | 3-6 أشهر | 6-18 شهراً | 12-36 شهراً |
الأخطاء السبعة التي تقتل مشاريع التحديث
- البدء بالنظام الأكثر أهمية. دفتر الحسابات المصرفي ليس المكان المناسب للتعلم.
- التقليل من شأن ترحيل البيانات. عادة ما يمثل 40-60% من الجهد.
- عدم وجود خطة تراجع. يجب أن تكون كل خطوة قابلة للعكس.
- تجاهل الأشخاص. خصص 20% على الأقل لإدارة التغيير والتدريب.
- اختيار التكنولوجيا قبل فهم المشكلة.
- عدم تقديم قيمة تدريجية. إذا لم تحقق قيمة قابلة للقياس في 6 أشهر، ستفقد الدعم التنفيذي.
- معاملته كمشروع تقنية معلومات. تحديث الأنظمة القديمة هو تحول أعمال.
بناء دراسة الجدوى: كيف تحصل على الموافقة التنفيذية
رأي ميكيلي
أنجح عرض تحديث رأيته اتبع هذا الهيكل: "نحن ننفق 3.2 مليون دولار سنوياً لصيانة النظام X. بمبلغ 400 ألف دولار يمكننا تحديث الوحدة A في 4 أشهر، مما يقلل تكاليف الصيانة بمقدار 600 ألف دولار سنوياً."
دور الذكاء الاصطناعي في تحديث الأنظمة القديمة
- فهم الكود: أدوات الذكاء الاصطناعي يمكنها قراءة وشرح كود COBOL أو RPG القديم.
- إنشاء الاختبارات الآلية: يمكن للذكاء الاصطناعي إنشاء مجموعات اختبار من الكود القديم.
- استعادة التوثيق: يمكن للذكاء الاصطناعي تحليل الكود لإعادة بناء قواعد الأعمال.
- المساعدة في الترحيل: يمكن للذكاء الاصطناعي ترجمة أنماط الكود، مما يسرع العملية بنسبة 30-40%.
في Lasting Dynamics، قمنا بدمج الذكاء الاصطناعي في سير عمل التحديث لدينا خصوصاً لفهم كود COBOL وإنشاء الاختبارات الآلية.
كيف يبدو النجاح: جدول زمني واقعي
هذا ما تبدو عليه رحلة تحديث منفذة جيداً لمؤسسة مصرفية أو تأمينية متوسطة الحجم.
| المرحلة | المدة | المخرج | الأثر التجاري |
|---|---|---|---|
| الاكتشاف والتقييم | 4-6 أسابيع | جرد الأنظمة، خريطة الاعتماديات، تقييم المخاطر | صورة واضحة لما لديك وما يجب تغييره |
| طبقة API (التغليف) | 2-4 أشهر | واجهات API حديثة فوق النواة القديمة | منتجات رقمية جديدة دون لمس الكود القديم |
| ترحيل أول وحدة | 3-6 أشهر | نطاق أعمال واحد على بنية حديثة | إثبات أن التحديث يعمل واكتساب الفريق للثقة |
| ترحيل تدريجي | 12-24 شهراً | نقل الأنظمة الأساسية تدريجياً | انخفاض تكاليف الصيانة 30-50% وتحسن سرعة الوصول للسوق 3-5x |
| إيقاف النظام القديم | 3-6 أشهر | إطفاء الأنظمة القديمة | تحقيق الوفورات الكاملة وتشغيل stack حديث |
الجدول الزمني الإجمالي: 18 إلى 36 شهراً لتحول كامل. لكن الفكرة الأهم هي أنك تبدأ بتسليم القيمة في الشهر الثالث، لا في الشهر السادس والثلاثين. كل مرحلة تمول نفسها.
الخلاصة
تحديث الأنظمة القديمة ليس مشروعاً تقنياً. إنه قرار استراتيجي حول ما إذا كانت مؤسستك ستنافس في العقد القادم. ابدأ بالتقييم. افهم ما لديك، وكم يكلفك. ثم اختر الاستراتيجية الصحيحة لكل نظام ونفّذ على مراحل تقدم قيمة قابلة للقياس كل ربع سنة.
“أفضل وقت لبدء التحديث كان قبل خمس سنوات. ثاني أفضل وقت هو هذا الربع.”
— ميكيلي تشيمينو