الخلاصة

  • يعرض Atlassian حالة إضافة على Confluence Cloud يستخدمه 25 شخصاً؛ انتقال الاشتراك إلى Teamwork Collection على موقع فيه 100 مستخدم Jira يجعل سعر الإضافة محسوباً على 100.
  • تحتسب Collection الشخص مرة واحدة بين منتجاتها المضمنة. أما إضافات Marketplace فلها تراخيصها، وقد يتسع جمهورها المدفوع مع تغيير ارتباطها بالمنتجات.
  • الفوترة بحسب المثيل، والاشتراك عبر عدة مثيلات، ونموذج Forge المبكر بحسب منح الوصول، تعالج حدوداً مختلفة. المقارنة المفيدة تجمع النطاق المتاح فعلاً مع سعر الشريك.

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

هذه هي المفارقة التي يتيحها مثال منشور في دليل Atlassian لفوترة التطبيقات السحابية. لدى العميل اشتراك Confluence Cloud يضم 25 مستخدماً وإضافة مثبتة عليه. ينقل الاشتراك إلى Teamwork Collection على الموقع نفسه، حيث يوجد 100 مستخدم Jira. يصبح سعر الإضافة سعر 100 مستخدم.

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

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

شخص واحد في الحزمة، وجمهور أكبر للإضافة

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

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

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

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

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

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

ما الذي يبيعه الترخيص فعلاً؟

تضع نظرة Forge إلى نماذج الترخيص التعريف بوضوح. النموذج القياسي يحاسب على جميع مستخدمي المثيل المضيف، بصرف النظر عن عدد من يستعملون الإضافة فعلياً.

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

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

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

ولإضافات Jira قاعدة أخرى تستحق الانتباه. يعرض الدليل موقعاً فيه 100 مستخدم Jira و80 وكيلاً في Jira Service Management. العدد المستخدم هو الأكبر، أي 100. وعند تعطيل اشتراك Jira ذي المئة مستخدم، ينتقل سعر الإضافة إلى عدد الثمانين المتبقين بدءاً من دورة الفوترة التالية.

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

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

طريق أصغر، لكنه يبدأ عند البائع

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

لكن دليل اعتماد الفوترة بحسب المستخدم يصف مرحلة وصول مبكر محددة. المتاح في هذه المرحلة هو بناء النموذج ونشره واختباره في بيئات غير إنتاجية باستخدام Forge CLI. ويضع النشر في Marketplace وإعداد الأسعار وتعديلها والموافقة ضمن التحديثات اللاحقة لبرنامج الوصول المبكر.

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

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

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

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

المؤسسة ليست مثيلاً واحداً بالضرورة

تُظهر إرشادات فوترة Enterprise أثراً مختلفاً لمكان التثبيت. في مثال Acme الافتراضي، يوجد 8,000 مستخدم Jira موزعون بين مثيل يضم 5,000 وآخر يضم 3,000. إذا ثُبتت الإضافة الخاضعة للفوترة بحسب المثيل على الأول، تُسعّر عند شريحة 5,000.

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

ويوجد مسار Marketplace متعدد المثيلات لخطط Cloud Enterprise في Jira وConfluence. يجمع مثيلات الإضافة تحت اشتراك للمؤسسة، ويحتسب المستخدم نفسه مرة واحدة عبر تلك المثيلات، مع اختيار شريحة مستخدمين عند البدء. وتظل الإضافة بحاجة إلى التثبيت على كل مثيل مطلوب.

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

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

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