لماذا لا يكفي التفاؤل: ما تقوله أرقام 2026 عن مشاريع الترحيل
يبدأ كثير من مشاريع الترحيل السحابي في المملكة بعرض تقديمي متفائل: توفير في التكلفة، مرونة أعلى، وجدول زمني أنيق من ثلاثة أشهر. ثم تصطدم الخطة بالواقع. تشير بيانات 2026 المنشورة استنادًا إلى تقديرات IDC إلى أن 38% من عمليات الترحيل تتجاوز ميزانيتها الأصلية، بمتوسط تجاوز يبلغ 23% فوق المخطط، وأن 31% منها تتأخر عن جدولها الزمني، والسبب الأول المتكرر هو تعقيد التطبيقات القديمة وتشابك اعتمادياتها.
الخبر الجيد أن الصورة تتحسّن: النسبة التي تُنجَز في الوقت وداخل الميزانية ارتفعت إلى نحو 65% في 2026 بعد أن كانت 54% في 2022، مع نضج الأدوات والمنهجيات. لكن الفارق بين المشاريع التي تنجح والتي تتعثر نادرًا ما يكون في جودة المهندسين؛ الفارق في أن الفريق الناجح كتب ما يمكن أن يسوء قبل أن يسوء، وأسند لكل بند مالكًا وميزانية طوارئ.
هنا يدخل سجل المخاطر (Risk Register). هو ليس مستندًا بيروقراطيًا يُطلب لإغلاق بوابة حوكمة، بل قائمة حيّة تُحوّل «قد يحدث» إلى بند له احتمال وأثر ومالك وخطة استجابة ومحفّز يخبرك متى تتحرك. وفي السياق السعودي — حيث يتوسع سوق الخدمات السحابية من نحو 4.77 مليار دولار في 2025 إلى ما يُقدَّر بـ 5.52 مليار دولار في 2026 بحسب تقديرات السوق المنشورة — يتزايد عدد المشاريع المتزامنة، ومعها احتمال أن يتكرر الخطأ نفسه في كل جهة على حدة.
أربع فئات مخاطر لا تغيب عن أي مشروع سحابي سعودي
لا يوجد سجل مخاطر «عام» صالح لكل مشروع، لكن أربع فئات تتكرر في كل مشروع سحابي سعودي تقريبًا، وتستحق أن تكون البنود الأولى في سجلك:
1) مخاطر الامتثال وتوطين البيانات. تصنيف البيانات قبل الترحيل ليس تمرينًا نظريًا: نظام حماية البيانات الشخصية (PDPL) وضوابط الهيئة الوطنية للأمن السيبراني للحوسبة السحابية (CCC) وإطار البنك المركزي السعودي «ساما» تفرض جميعها متطلبات على موقع البيانات وعلى المسؤوليات المشتركة مع المزوّد. الخطر العملي هنا ليس الغرامة فحسب، بل اكتشاف — بعد الترحيل — أن حِملًا معيّنًا يجب إعادته إلى منطقة محلية، فتدفع كلفة الترحيل مرتين.
2) مخاطر الاعتماد على المزوّد (Vendor Lock-in). بحسب استطلاع Flexera State of the Cloud 2026، تستخدم 89% من مؤسسات المستوى المؤسسي إستراتيجية متعددة السحابات، و42% منها تذكر تفادي الاعتماد على مزوّد واحد كسبب رئيسي. وتشير أبحاث منشورة لـAccenture إلى أن 58% من الرؤساء التنفيذيين للتقنية يعدّون الاعتماد على مزوّد واحد خطرًا إستراتيجيًا. الدرس المستفاد من موجة تجديدات VMware بعد استحواذ Broadcom واضح: الخطر لا يظهر يوم التوقيع، بل يوم التجديد.
3) مخاطر الانقطاع والتوافر. أعطال 2025 الكبرى لدى مزوّدين عالميين أعادت تسعير هذا البند. تقديرات ITIC المتداولة في 2026 تضع كلفة ساعة التوقف لدى المؤسسات المتوسطة والكبيرة عند أكثر من 300 ألف دولار، وتذكر أن أكثر من 90% منها تتجاوز هذا الرقم. ولأن هذه الأرقام تُنشر غالبًا من جهات لها مصلحة في بيع حلول التوافر، فالأجدى أن تحسب رقمك أنت: إيراد الساعة × نسبة الاعتماد على الخدمة.
4) مخاطر الخروج والتكاليف الخفيّة. رسوم إخراج البيانات (Egress)، وتراخيص لم تُحتسب، وإنفاق مهدور. يقدّر تقرير Flexera لعام 2026 أن 29% من الإنفاق السحابي مهدور — وهي أول زيادة بعد خمس سنوات من الانخفاض، ويُرجعها التقرير إلى تعقيد أحمال الذكاء الاصطناعي. خطة الخروج التي يطلبها إطار «ساما» صراحةً ليست إجراءً شكليًا: هي ما يمنحك موقفًا تفاوضيًا.
كيف تبني السجل عمليًا: الأعمدة الثمانية ونموذج جاهز
السجل الفعّال بسيط بما يكفي ليُملأ، ومنظّم بما يكفي ليُستخدم. ثمانية أعمدة تكفي:
المعرّف (رقم ثابت للإحالة) — وصف الخطر بصيغة «إذا حدث كذا، فقد ينتج كذا» — الفئة (امتثال / تقني / مالي / تشغيلي / تعاقدي) — الاحتمال (1–5) — الأثر (1–5) — الدرجة (حاصل الضرب، وتُرتَّب البنود تنازليًا) — المالك (شخص بالاسم، لا إدارة) — الاستجابة (تجنّب / تقليل / نقل / قبول) مع المحفّز: العلامة التي تخبرك أن الخطر بدأ يتحقق.
عمود «المحفّز» هو الأكثر إهمالًا والأكثر قيمة. مثال: خطر «تجاوز الميزانية بسبب نمو الاستهلاك أسرع من المتوقع» محفّزه ليس نهاية الشهر، بل «تجاوز الإنفاق التراكمي 60% من ميزانية المرحلة قبل إتمام 40% من الأحمال». عند هذه العتبة تتحرك الخطة تلقائيًا.
ونموذج مختصر يمكن نسخه كما هو للبدء:
| الخطر | الفئة | الاحتمال × الأثر | المالك | الاستجابة والمحفّز |
|---|---|---|---|---|
| اكتشاف بيانات شخصية غير مصنّفة بعد بدء الترحيل | امتثال | 4 × 5 = 20 | مسؤول حماية البيانات | تجنّب: إيقاف موجة الترحيل وإعادة التصنيف. المحفّز: أي عيّنة فحص تُظهر حقلًا شخصيًا غير موسوم. |
| ارتفاع فاتورة التجديد بعد انتهاء الخصم التعريفي | تعاقدي | 4 × 4 = 16 | مدير المشتريات | نقل/تقليل: تثبيت السعر تعاقديًا وبناء حالة بديلة. المحفّز: بقاء 6 أشهر على انتهاء العقد. |
| انقطاع منطقة سحابية يوقف خدمة حرجة | تشغيلي | 2 × 5 = 10 | مدير العمليات | تقليل: نسخ عبر مناطق واختبار تعافٍ ربع سنوي. المحفّز: تجاوز زمن التعافي المُختبَر هدف RTO. |
| تعذّر إخراج البيانات بكلفة معقولة عند الخروج | مالي | 3 × 4 = 12 | مهندس الحلول | تجنّب: تقدير رسوم Egress وتوثيق مسار خروج مُختبَر. المحفّز: نمو حجم البيانات 50% عن التقدير. |
لاحظ أن الدرجة ليست غاية بحد ذاتها؛ فائدتها أنها تفرض ترتيبًا، وتمنع أن يستهلك اجتماع المخاطر ساعةً في بند درجته 4 بينما يقبع بند درجته 20 دون مالك.
من مستند مَنسِيّ إلى أداة حيّة: حوكمة السجل ومراجعته
أكثر ما يقتل سجلات المخاطر أنها تُكتب مرة واحدة عند انطلاق المشروع ثم تُؤرشف. السجل الحيّ يحتاج ثلاث عادات فقط:
مراجعة دورية قصيرة. خمس عشرة دقيقة كل أسبوعين تكفي: هل تغيّر احتمال أي بند؟ هل تحقق محفّز؟ هل ظهر خطر جديد؟ هل أُغلق بند فعلًا؟ إغلاق البنود مهم بقدر فتحها — السجل الذي ينمو ولا ينكمش يفقد مصداقيته لدى الفريق.
اختبار الافتراضات لا تسجيلها فقط. توصي الممارسات المنشورة في 2026 باختبار خطة الخروج سنويًا على الأقل للأحمال غير الحرجة، ومراجعة إجراءات تصدير البيانات كل ربع سنة. خطة تعافٍ لم تُختبر ليست خطة، بل بند نيّة حسنة. الأمر نفسه ينطبق على جرد الاعتماديات: أغلب تجاوزات الجدول الزمني مصدرها اعتمادية لم يعرف أحد بوجودها.
ربط السجل بالحوكمة القائمة. بدل بناء عملية موازية، اربط بنود السجل بما تطلبه الجهات التنظيمية أصلًا: تصنيف البيانات وخطط الخروج في إطار «ساما»، والمسؤولية المشتركة في ضوابط الهيئة الوطنية للأمن السيبراني، وسجل أنشطة المعالجة في PDPL. بهذه الطريقة يخدم السجل غرضين: يحمي المشروع، ويوفّر جزءًا كبيرًا من الأدلة المطلوبة وقت المراجعة.
في النهاية، سجل المخاطر ليس تنبؤًا بالمستقبل. هو اعتراف مكتوب بأن المشروع السحابي يجري في ظل عدم يقين، وأن الفريق اختار أن يواجه هذا اللايقين بقائمة مرتّبة ومالكين محدّدين، بدل أن يواجهه باجتماع طارئ بعد وقوع الحدث.
