الحوسبة السيادية ليست شراءً. إنها operating model.

هناك نوع محدد من الفشل لا يظهر إلا بعد قص الشريط.

النظام موجود. الفواتير دُفعت. لوحات المتابعة خضراء. ثم لا يحدث شيء. أو أسوأ: يستخدمه بضعة متحمسين بينما يلتف الجميع حوله، لأنه أبطأ، وأصعب، وأكثر مخاطرة، أو ببساطة غير مرتبط بأهداف أي طرف.

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

رد الفعل الغريزي هو تحويلها إلى قصة تقنية: مورد خاطئ. تحجيم خاطئ. معمارية خاطئة. تدريب غير كافٍ. أو «استراتيجية ذكاء اصطناعي» غير كافية.

لكنها قصة operating model. تفشل الحوسبة السيادية عندما تُعامل كحدث مشتريات، لا كمنتج له عملاء وقيود ومسار تبنٍّ قابل للقياس.

الخطأ الجوهري: السعة أولًا، والطلب لاحقًا

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

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

عندما لا ينقل الناس أعمالهم إلى بيئة حوسبة جديدة، فهم غالبًا يستجيبون للحوافز لا للأيديولوجيا. يختارون ما يحافظ على تدفق التسليم لديهم:

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

المعالجة ليست المزيد من التواصل. بل تشكيل الطلب عبر التزامات صلبة.

امنحها مالكًا يستطيع أن يقول «لا» و«توقف»

غالبًا ما تموت مبادرات الحوسبة السيادية بسبب تقاسم المسؤولية. الجميع يُستشار. ولا أحد يُحاسَب.

تحتاج إلى شخص واحد مُساءل عن النتائج عبر ثلاثة مسارات في الوقت نفسه:

• صحة المنصة (الإتاحة، الأداء، الوضع الأمني، التكلفة لكل نوع workload).
• التبني (زمن onboarding، عدد المشاريع النشطة، الاستخدام المتكرر، ترحيل workloads).
• ملاءمة المحفظة (أي workloads تنتمي هنا، وأيها لا، وما الذي يجب رفضه).

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

شاهدتُ منصة cloud داخل مؤسسة منتجات متعددة البلدان لا تصبح مفيدة إلا بعد أن سُمِح للفريق المشغّل لها برفض workloads كانت ستشوّهها بشكل دائم. نقطة التحول لم تكن تقنية أفضل؛ بل governance تحمي غاية المنصة.

عرّف KPIs للاستخدام تفرض النقاش الحقيقي

«معدل الاستغلال» أداة غليظة. يمكنك رفع الاستغلال عبر workloads خاطئة ومع ذلك تفشل المهمة. ما تحتاجه هو KPIs تكشف ما إذا كانت المنصة تتحول إلى المسار الافتراضي للعمل الصحيح.

هذه سبعة مؤشرات تميل إلى إظهار الحقيقة بسرعة:

• Time to first job: الوسيط الزمني من الطلب إلى أول تشغيل ناجح.
• Monthly active projects: ليس المستخدمين؛ بل مشاريع تُخرج نتائج.
• Repeat rate: نسبة المشاريع التي تعود للتشغيل في الشهر التالي.
• Workload mix: نسبة تجارب البحث مقابل مسارات الإنتاج مقابل تحليلات الدُفعات.
• Data gravity fit: نسبة workloads التي تعمل حيث توجد البيانات أصلًا (أو يمكن أن توجد قانونيًا).
• Cost per outcome proxy: تكلفة كل نموذج مُدرَّب، أو كل cohort مُعالَج، أو كل دورة تقارير، أو كل تشغيل محاكاة. اختر مؤشرات بديلة تناسب المهمة.
• Abandonment reasons: أسباب مُعلَّمة، تُراجع شهريًا، ومربوطة بمالك إصلاح.

معظم المؤسسات لا توثق أسباب التخلي. هناك يختبئ فشل operating model: قيود المشتريات، احتكاك الوصول، حدود الدعم غير الواضحة، مكتبات مفقودة، غموض المسؤولية عن الامتثال، وبطء الاستجابة للحوادث.

chargeback ليس عن المال. بل عن الجدية.

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

وإذا سُعّرت الحوسبة بشكل سيئ، تحصل على العكس: تحمي الإدارات ميزانياتها بتجنب المنصة، حتى عندما تكون أرخص على مستوى المؤسسة.

هدف chargeback هو صنع قرار واضح عند الهامش. بعض الأنماط العملية تنجح أفضل من مسرحية أسعار التحويل الداخلية المعتادة:

• ابدأ بـ showback لمدة 1 إلى 2 ربع: شفافية التكلفة الفعلية حسب المشروع والقسم، بلا فواتير بعد.
• انتقل إلى chargeback بسيط بمعدلين: واحد للسعة المحجوزة وآخر للاندفاع (burst). اجعله مفهومًا.
• خصص صندوق ترحيل مركزيًا: يمكن للفرق طلب اعتمادات محدودة الزمن تغطي إعادة الهيكلة وأول تشغيلات.
• سعّر الألم لا الجمال: حمّل تكلفة أعلى على workloads التي تتطلب دعمًا مخصصًا، أو اعتماديات هشة، أو استثناءات أمنية غير قياسية.

عندما تشعر الفرق بكلفة «الحالة الخاصة»، فهي إما أن تُقيّس وتُوَحِّد، أو تبرر بوضوح لماذا لا ينبغي لها ذلك. كلا النتيجتين أصح من تآكل صامت.

القطعة المفقودة التي تتجاهلها أغلب المشتريات: مسارات الخروج

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

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

في الحوسبة السيادية، ينبغي أن تكون مسارات الخروج صريحة في خمسة مواضع:

1. قابلية نقل البيانات: صيغ واضحة، وملكية محددة، ومسارات تصدير مؤتمتة لمجموعات البيانات وmetadata وlineage.
2. قابلية نقل workloads: معايير الحاويات، وخطوط أساس infrastructure-as-code، وقوالب CI يمكن توجيهها إلى بيئة أخرى.
3. الهوية والوصول: تجنب بنى IAM الخاصة بمزوّد بعينه التي لا يمكن مواءمتها في مكان آخر.
4. سقوف الاعتماد على الدعم: خدمات استشارية محددة زمنًا، مع التزام بنقل المعرفة ومعايير تسليم قابلة للقياس.
5. بنود فك ارتباط تجارية: خيارات متفق عليها مسبقًا لتقليل النطاق أو إنهاء مكونات بعينها إذا لم تتحقق KPIs التبني.

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

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

operating model عملي للحوسبة السيادية، في صفحة واحدة

إذا كنت تعيد البناء هذا الربع، فسأبدأ بميثاق من صفحة واحدة يفرض الوضوح:

• المهمة: ما النتائج التي وُجدت هذه الحوسبة لتمكينها، وما الذي لا تهدف إليه.
• قائمة العملاء: إدارات وبرامج مسماة مع workloads ملتزم بها.
• الاستقبال: مسار طلب بسيط مع SLA للقرار ومعايير للرفض.
• المسارات الذهبية: نمطان أو ثلاثة من workloads المدعومة، موثقة بالكامل.
• KPIs: time to first job، المشاريع النشطة، repeat rate، workload mix، وأسباب التخلي.
• الاقتصاديات: showback الآن، ثم chargeback لاحقًا، إضافة إلى صندوق ترحيل محدود الزمن.
• مسارات الخروج: معايير قابلية النقل وبنود فك الارتباط المرتبطة بمقاييس التبني.

ثم أدرها كمنتج. قرارات استقبال أسبوعية. مراجعة KPIs شهرية. فرز محفظة ربع سنوي. تركيز صارم على المسارات الذهبية. هكذا تتجنب بناء منصة جميلة لا يختارها أحد.

ولهذا أيضًا تفوت نقاشات «sovereign cloud» النقطة غالبًا. السؤال ليس فقط أين تعمل workloads، بل هل تستطيع تشغيلها بموثوقية، ونقلها عند الحاجة، وتبرير التكلفة. كتبت عن هذا الإطار الأوسع للمحفظة في Sovereign Cloud هو فرز للمحفظة، لا تبديل مورد.

رأيي: تُكتسب الحوسبة السيادية ولا تُعلَن

اللغة السياسية حول السيادة قد تكون مفيدة؛ فهي تخلق إلحاحًا وتمويلًا. لكنها قد تخفي حقيقة أبسط: المنصات لا تهم إلا عندما تُستخدَم.

الحالة الدنماركية التي بقي فيها أكثر من 90% من السعة خاملة ليست فضيحة لأن الاستغلال منخفض. إنها تحذير من أن المشتريات بلا operating model هي الطريقة التي تتحول بها استثمارات حسنة النية إلى سرديات تكلفة غارقة.

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