الاختبار الحقيقي لاستمرارية الأعمال: ماذا تفعل المؤسسة حين يعجز مورد البرمجيات؟

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

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

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

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

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

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

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

ويستشهد المقال بعمل Escode مع Vision Bank، حيث جرى تحقق على مرحلتين لتطبيق سحابي حيوي، جمع بين تقييم لنقل المعرفة واختبار عملي للسيناريوهات. شمل التقييم المواد المودَعة، وتعليمات النشر، ومعلومات الإعداد، وآليات الوصول. ونتج عنه توثيق مستقل لعملية بناء التطبيق يمكن أن يدعم نقل تطويره أو تشغيله إلى فريق آخر، فيما تواصل Escode، بحسب المقال، متابعة تغييرات البرمجيات والإيداعات المحدّثة.

ويذكر الكاتب أيضًا أن شركات تورّد تقنيات الدفع والتقنيات المالية الحيوية للبنوك والمؤسسات المالية والمصارف المركزية في الشرق الأوسط، وهي ProgressSoft وIntellect Design وCMA Small Systems وeMcREY، اختارت Escode لحماية أصولها البرمجية، معتبرًا أن ذلك يبرز أهمية تقييم خبرة شريك الضمان مع الأنظمة الحيوية وقدرته الفنية على الحكم على صلاحية المواد المودَعة.

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

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

يشير المقال إلى أن المرونة التشغيلية في منطقة الخليج أصبحت مرتبطة ارتباطًا وثيقًا بإدارة الاعتماد على الأطراف الثالثة. ففي الإمارات، تُلزم لائحة إدارة المخاطر التشغيلية الصادرة عن المصرف المركزي (C 1/2026)، السارية منذ 14 سبتمبر 2026، المؤسساتِ المرخّصة منه بتحديد العمليات الحيوية، ورسم خريطة الاعتماديات الداعمة لها، والاحتفاظ بخطط طوارئ وخروج قابلة للتطبيق لترتيبات الأطراف الثالثة الجوهرية. كما تتناول اللائحة الحالات التي يكون فيها استبدال المزوّد مكلفًا أو محفوفًا بالمخاطر أو غير عملي.

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

يقترح ماكولوك خمسة أسئلة كنقطة انطلاق عملية لفرق القيادة:

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

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