الخلاصة

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

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

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

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

من يستطيع نقل المشروع قد لا يستطيع إلزام الدافع الجديد

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

ويميز دليل أدوار النقل بين صلاحية تحريك المشروع وصلاحيات تغيير حساب الفوترة. يورد للأخيرة أدواراً منها Billing Account User على حساب الوجهة وProject Billing Manager على المشروع. وتفصل وثيقة الفوترة المتخصصة أيضاً صلاحيات العرض وفك الارتباط وإنشاء الارتباط الجديد. امتلاك زر النقل لا يعطي صاحبه تلقائياً حق تحميل حساب آخر تكاليف التشغيل.

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

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

الموافقة التي لا يعوضها موظف أسرع

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

أما تغيير حساب الأوامر النشطة، للمنتجات المشتراة مباشرة من Cloud Marketplace، فيبدأ من العميل لدى مورّد البرمجيات المستقل. يحتاج مقدم الطلب إلى دور Billing Account Administrator. إذا وافق المورّد، يطلب النقل من Google. تعالج Google الطلب وترسل رسائل الموافقة، ثم يجب أن ترد الأطراف المعنية كلها بالموافقة قبل إتمام النقل وإرسال إشعار الإنجاز.

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

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

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

الحساب القديم يتلقى ذيلاً من المصروفات

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

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

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

وتقدم الوثيقة مثالاً آخر محدداً: المشروع المشترك في Cloud Armor Enterprise Annual يعود إلى Standard إذا افتقر حساب الوجهة إلى الاشتراك السنوي. ثبات الموارد لا يحفظ كل شروط الخدمة التجارية المحيطة بها.

التمويل المؤقت قد يكون الاختيار المتعمد

ناقشت Google هذه المفاضلة في مقال عن فصل الشركات نشرته في 2 مايو 2023. يستخدم المقال شركتين افتراضيتين باسم RemainCo وNewCo، ويعرض إبقاء التمويل من حساب الفوترة الأصلي للوفاء بعقد التزام قائم. كما أن الأرصدة الترويجية وحزم الدعم لا تمتد تلقائياً إلى الشركة أو الحساب الجديدين.

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

يتطلب الحكم على حالة بعينها سجلات IAM وارتباطات الفوترة والمشتريات والموافقات الفعلية؛ هذه السجلات الخاصة لا توفرها الوثائق العامة.

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