Services-as-Software هي إعادة كتابة لهامش الربح الإجمالي، وليست تحولاً في المنتج

تعجبني الطموحات وراء “Services-as-Software”. طرح ZDNET صحيح من حيث الاتجاه: الذكاء الاصطناعي يحوّل المزيد من تنفيذ الخدمات إلى شيء يمكن تغليفه وتكراره وبيعه باقتصاديات أقرب إلى software.

لكن أغلب الفرق تقع في خطأ واحد بدائي إلى حد محرج. تتعامل معه وكأنه تحول في المنتج. وتضع له ميزانية كما لو أنه SaaS تقليدي. ثم تستيقظ بعد ستة أشهر لتجد “ميزات AI” تتصرف كوكالة لا يمكن توسيعها.

من منظور تشغيلي، المسألة بسيطة: Services-as-Software هي إعادة كتابة لهامش الربح الإجمالي. إن لم تقس التباين وتضبطه، فستلتهم الأطراف قائمة الربح والخسارة قبل أن يبدو الإيراد “مدعوماً بالذكاء الاصطناعي”.

رأيت النمط نفسه في عالمين. في منظمات الخدمات الصناعية، يختبئ التباين في الميدان: السفر، وقت الاستكشاف وإصلاح الأعطال، قطع الغيار، والتصعيدات. وفي SaaS، يختبئ التباين في الدعم والتنفيذ: مسارات عمل مخصصة، تنظيف البيانات، التكاملات، والآن tokens ودقائق human-in-the-loop. اختلاف في السطح. المرض ذاته.

التحول في النموذج ليس “ميزات AI”. بل وضوح cost-to-serve.

اقتصاديات الوحدة في SaaS التقليدي تفترض أن التكلفة الحدّية في الغالب بنية تحتية ودعماً، وأن كليهما يتوسع بشكل معقول مع الإيراد. Services-as-Software يكسر هذا الافتراض لأن التنفيذ يصبح مزيجاً من:

• عمل يتغير مع الحوسبة (tokens لكل مسار عمل، استدعاءات retrieval، تقييم النموذج، أعمال batch).
• عمل يتغير مع البشر (دقائق المراجعة، معالجة الاستثناءات، الإعداد الأولي، تصحيح البيانات، تدريب العميل).
• عمل يتغير مع الدعم (تذاكر، حوادث، تصعيدات “لماذا فعل النموذج هذا؟”).

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

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

الفخ: تسعّر اليقين، لكنك تنفّذ التباين

معظم عروض Services-as-Software تُباع كما لو أن المورّد قادر على توقع حجم العمل لكل عميل: رسم ثابت، شامل، “غير محدود”. هذا يُغلق الصفقات. لكنه أيضاً يدعم الحسابات الأكثر ضجيجاً ويعاقب الهادئة.

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

مقال ZDNET يقدّم Services-as-Software على أنه النموذج القادم. أتفق مع الاتجاه. ما لا أتفق معه هو سهولة التنفيذ الضمنية. التحدي ليس إطلاق المساعد. التحدي هو تحويل التنفيذ إلى عملية مضبوطة بمدخلات قابلة للقياس ومخرجات محدودة.

إن لامس هذا الموضوع واقعك، فهو مرتبط مباشرة بملكية مسارات العمل. كتبت عن ذلك في AI Leadership Is Workflow Leadership: Own the Handoffs. إذا لم تملك handoffs، فلن تملك التكلفة.

قِس كل نقطة تماس للذكاء الاصطناعي كما تقيس إنفاق cloud

هذه هي القاعدة التشغيلية التي سأضعها هذا الربع. ليس العام القادم. هذا الربع.

1) عرّف “وحدة العمل” لكل مسار عمل في المنتج

اختر 3 إلى 5 مسارات عمل لها وزن تجاري. مثال: “توليد رد للعميل واعتماده”، “صياغة ملخص امتثال”، “تصنيف طلب وارد وتوجيهه”. لكل مسار عمل تعريف لوحدة يمكن عدّها.

2) قِس محركات التكلفة الثلاثة لكل وحدة

• Tokens واستدعاءات الأدوات: المتوسط، p95، والحد الأقصى. ليس بدافع الفضول؛ بل لضبط التباين.
• دقائق human-in-the-loop: مراجعة، تصحيح، تصعيد. تتبّع من يقوم بها ولماذا.
• عبء الدعم: تذاكر لكل 100 وحدة، معدل الحوادث، زمن الحل.

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

3) أنشئ “سجل cost-to-serve” لكل حساب

ليس لوحة مؤشرات جميلة. بل سجل يجيب: هذا الحساب استهلك X وحدات، وخلق Y استثناءات، واحتاج Z دقائق عمل بشري، وتسبب في N أحداث دعم.

إذا لم تستطع إنتاج هذا السجل، فلن تستطيع التسعير بعقلانية، ولن تستطيع إدارة نقاش تجديد ناضج.

4) ضع الضوابط داخل المنتج، لا في وثائق السياسات

• حدود المعدلات، الحصص، وسلوك backoff.
• انضباط نافذة السياق وسقوف retrieval.
• مهل مسارات العمل والتدهور السلس (قوالب بديلة، أوضاع عمق أقل).
• قواعد تصعيد قابلة للتدقيق.

هنا تخلط فرق كثيرة بين “AI architecture” والرسومات. الواقع أنها قائمة ضوابط تعمل يومياً. إذا أردت موازاة، راجع AI Architecture Isn’t a Diagram. It’s an Operator’s Checklist.

أعد تصميم التسعير: نتائج + استخدام، مع حدود صارمة لما هو مشمول

بعد أن تصبح قادراً على قياس cost-to-serve، يتحول التسعير إلى مسألة هندسة وتغليف، لا جدال في غرفة اجتماعات.

أستخدم قاعدة بسيطة: بع النتيجة، وفوّتِر التباين.

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

لا تُخفِ الاستثناءات. سمِّها. ضعها في العقد وفي تغليف المنتج. في الخدمات الصناعية، للضمان حدود لسبب واضح. في خدمات الذكاء الاصطناعي، “غير محدود” بلا ضوابط ليس إلا خسارة هامش مؤجلة.

ولهذا أكرر أن Pricing Is Product Management in Disguise. التسعير يجبرك على تعريف مساحة المنتج. الذكاء الاصطناعي يوسّع هذه المساحة. إن لم تقيّدها، سيفعل العملاء ذلك نيابةً عنك، عبر churn أو التصعيدات.

نمط مُعاش: عندما تتوقف عن التخمين، يصبح النموذج قابلاً للتوسع

عندما بنيت وشغّلت منتجات SaaS (بما فيها EatMore، ولاحقاً مشاريعي مثل IBHQ)، كانت المرحلة الخطرة دائماً نفسها: الجذب المبكر يدفعك إلى تنفيذ مُفصّل حسب العميل. تسميه “customer success”. وهو في الحقيقة عمليات يدوية.

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

نقطة التحول هي أن تتوقف عن النقاش حول ما إذا كان الشيء “منتجاً” أم “خدمة”، وتبدأ في التعامل معه كخط إنتاج:

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

إذا لم تستطع شرح cost-to-serve لكل مسار عمل في صفحة واحدة، فأنت لا تملك Services-as-Software. لديك وكالة بواجهة UI.

عدسة قراري لهذا الربع

إذا كنت تفكر في رهان Services-as-Software، فسأتخذ ثلاثة قرارات الآن.

1. اختر مسارات العمل التي ستُصنّعها. ليس كل شيء. ابدأ بما له بنية قابلة للتكرار وقيمة واضحة.
2. التزم بالقياس كميزة منتج من الدرجة الأولى. Tokens، الدقائق البشرية، وأحداث الدعم. بلا قياس، لا توسع.
3. أعد التسعير قبل توسيع التوزيع. إذا دفعت go-to-market على نموذج وحدة مكسور، ستسرّع انهيار الهامش.

رأيي الواضح: Services-as-Software سينتصر، لكن فقط للفرق التي تديره كما لو كان تصنيعاً. قِس الخط. اضبط التباين. سعّر الاستثناءات. وما عدا ذلك مسرح.

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