جاهزية المورّدين والشبكاتVendor and scheme readiness

المورّد شركة تشتري منها جزءاً من منتجك: التحقق من الهوية، أو معالجة البطاقات، أو الاستضافة. والشبكة هي من يضع القواعد التي يلتزم بها الجميع، كمدى وفيزا.

يبقى اسم شركتك على شكوى العميل حتى حين يكون الخلل داخل نظام شركة أخرى.

إذا المزوّد تعطّل، ليش أنا اللي أتحمّل؟

وهذا شعور عادل. فأنت اشتريت خدمة من شركة متخصصة، ودفعت ثمنها، وتعطّلت هي لا أنت. فلماذا يقع اللوم عليك؟

لأن العميل لم يتعاقد مع مزوّدك. تعاقد معك.

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

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

فالقاعدة أنك تسند العمل ولا تسند المسؤولية.

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

فالشركة التي تجيب هذه الأسئلة يوم العطل تخسر ساعات. والتي أجابتها قبله تخسر دقائق.

أسند العمل لا المسؤولية

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

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

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

افحص الدليل لا الإجابة

وتعني «العناية الواجبة» Due diligence فحص المورد قبل الاعتماد عليه وحفظ سجل الفحص. فاطلب هيكل الملكية والتراخيص والسياسات ونتائج الاختبارات والحوادث الجوهرية وخطة الاستمرارية. ولا تجعل استبياناً مكتمل الخانات بديلاً عن الدليل.

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

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

اقرأ تقرير SOC 2 بدقة

ويقدم «تقرير SOC 2» SOC 2 رأي مدقق مستقل في ضوابط شركة خدمية. ولا يعد شهادة بأن كل شيء آمن. ويغطي النوع الأول تصميم الضوابط في يوم محدد، بينما يغطي النوع الثاني تشغيلها خلال فترة.

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

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

احسب مخاطر التركّز

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

وارسم سلسلة كل خدمة حرجة حتى البنية التحتية. فسجل السحابة والمنطقة ومزود الشبكة ومقاول البيانات والبنك الراعي. وقارن السلاسل بين الموردين لكشف نقطة مشتركة.

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

ضع وقت الانتظار في الخطة

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

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

واختبر بيئة المورد كما ستعمل في الإنتاج. فبيئة الاختبار التي توافق كل شيء لا تكشف حدود السرعة أو حالات الرفض أو ملفات التسوية. واطلب حالات فشل معروفة ونتائج متوقعة.

اكتب عقداً قابلاً للتشغيل

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

وحدد من يتحمل المطابقة والاسترداد وشكاوى العملاء. فقد يظن كل طرف أن الآخر يراقب العمليات المعلقة. ويمنع جدول مسؤوليات صريح فراغاً لا يظهر إلا بعد فقد المال.

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

راقب المورد بعد التوقيع

ولا تنتهي العناية الواجبة عند الشراء. فراجع الأداء والحوادث والتقارير والتغييرات المالية والأمنية دورياً. واطلب تقرير SOC 2 الجديد، واختبار الاختراق، وإثبات معالجة الاستثناءات.

وتابع مؤشرات يشعر بها العميل مثل فشل التحقق وتأخر الدفع، لا توفر واجهة المورد وحده. وقد ترد الواجهة بنجاح بينما تتراكم الأعمال خلفها. واربط كل خرق بخطة تصحيح وموعد.

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

اكتب الخروج قبل الدخول

ويحتاج «خطة الخروج» إلى بديل أو طريقة تشغيل مؤقتة، وخطوات نقل البيانات، وحذف النسخ، وتسوية الأموال، وإبلاغ العملاء. ولا تكتبها بعد فساد العلاقة حين تقل مساعدة المورد.

وحدد تنسيق التصدير وتكراره وكلفة النقل ومدة الاحتفاظ. واختبر استعادة عينة لدى بديل. فإذا كانت بياناتك حبيسة تنسيق خاص، فقد يملك المورد قرارك حتى دون بند صريح.

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

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