Salesforce بلا واجهة مستخدم: ما يكشفه ذلك عن تصميم المؤسسات في عصر الذكاء الاصطناعي الوكيل

Salesforce بلا واجهة مستخدم: ما يكشفه ذلك عن تصميم المؤسسات في عصر الذكاء الاصطناعي الوكيل

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

Ignacio SilvaIgnacio Silva٣ مايو ٢٠٢٦8 دقيقة
مشاركة

سيلزفورس بلا واجهة، وما يكشفه ذلك عن تصميم المؤسسات في عصر الذكاء الاصطناعي الوكيل

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

يُعرف هذا التحول باسم Headless 360، ومنطقه أكثر جذريةً مما يوحي به اسمه التقني. فليس الأمر مجرد تحديث للواجهة، ولا هجرة للبنية التحتية. إنه إعلان صريح عن نوع الشركة التي تطمح سيلزفورس أن تكون في عالم تُدير فيه وكلاء الذكاء الاصطناعي مسارات عمل كاملة دون أن تلمس يدٌ بشرية أيَّ زر. فأكثر من 60 أداة جديدة لبروتوكول سياق النموذج و30 مهارة برمجية مُهيَّأة مسبقًا تفتح الوصول المباشر إلى المنصة لوكلاء من أمثال Claude Code وCursor وCodex. كل ما كان خلف شاشة بات له واجهة برمجية. وكل ما كان ضغطةَ زر أصبح الآن أمرًا مكتوبًا.

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

المشكلة التي لا يُسمّيها أحد حين يتحدث عن وكلاء الذكاء الاصطناعي

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

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

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

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

الاستكشاف دون تدمير ما يعمل بكفاءة

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

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

من يحافظ على التماسك بين ما يفعله الوكيل عبر واجهة برمجة التطبيقات وما يراه المستخدم البشري على شاشته؟ وكيف تُعالَج الأخطاء حين يعدّل وكيل بيانات في بيئة الإنتاج دون أن يتحقق منها أحد يدويًا؟ تذكر سيلزفورس "ضوابط الإنتاج لسلوك الوكيل" ضمن حزمة Headless 360، لكن تفاصيل تلك الحوكمة شحيحة في المصادر المتاحة حتى الآن. هذه الثغرة لا تُبطل التحرك؛ بل تُحدد طبيعته وحجمه. إن السرعة التي تبني بها منصة بهذا الحجم حواجزها التشغيلية ستحدد كم من الإمكانات الوكيلة يتحول إلى قيمة حقيقية للعملاء، وكم منها يتحول إلى دين تقني وتنظيمي متراكم.

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

النقطة التي تتحول فيها المنصة إلى رهان استراتيجي

وصف فيرنان كينان، المحلل في SalesforceDevops.net، نهج Headless 360 بأنه "رهان على جيل Claude Code": مطورون لا ينتظرون أن تتكيف بيئة عملهم مع أدواتهم، بل يجلبون أدواتهم بأنفسهم ويتوقعون أن تتكيف المنصة معهم. يلتقط هذا الوصف شيئًا جوهريًا حول التحول في موازين القوى في سوق برمجيات المؤسسات.

طوال عقدين، كانت سيلزفورس هي مركز الجاذبية: تكيّف الشركات عملياتها مع ما تتيحه المنصة. والآن ينعكس هذا الاتجاه. لن تعيد وكلاء الذكاء الاصطناعي وبيئات التطوير كـCursor أو Windsurf تصميم بنيتها لتتلاءم مع سيلزفورس. وإن لم تتكيف سيلزفورس معها، ستتوقف عن أن تكون نظام السجل الرئيسي، لتتحول إلى مجرد مصدر بيانات إضافي، قابل للاستغناء عنه في سلسلة الأتمتة.

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

والتوازي مع will.i.am أقل تفاهةً مما يبدو عليه. فمساقه في جامعة ولاية أريزونا حول "الذات الوكيلة" يعالج بالضبط الطبقة التي لا تزال سيلزفورس تعمل على حلها: اعتماد الوكلاء الآليين، وحوكمتهم، وتحديد المسؤوليات المترتبة عليهم. وإذا كانت الجامعات بدأت تمنح شهادات اعتماد للوكلاء الذين يُدخلهم طلابها إلى سوق العمل، فإن المنصات التي تستضيف هؤلاء الوكلاء ستحتاج إلى قدرات رقابة مماثلة. البُعد التعليمي ليس تفصيلًا إضافيًا؛ إنه جزء من سياق الحوكمة الذي سيتعين على Headless 360 أن يعمل في إطاره.

التصميم الذي يُختبر الآن ليس تقنيًا

إن تحرك سيلزفورس نحو بنية بلا واجهة راسخٌ في تصوره من حيث المنتج. أما السؤال الهيكلي الجوهري فهو: هل تمتلك المنظمة التي بنته التصميم الداخلي اللازم للمضي فيه؟

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

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

ما يبقى رهين المشاهدة هو ما إذا كانت آليات الحوكمة الوكيلة —ضوابط الإنتاج، وحواجز الثقة التي أشار إليها بينيوف كمبدأ— ستحظى بالاستثمار الهيكلي ذاته الذي حظيت به طبقة الوصول التقني. بناء واجهات برمجة التطبيقات كان الجزء المرئي. أما بناء المنظمة القادرة على مراجعة ما تفعله تلك الواجهات في بيئة الإنتاج، على نطاق واسع، مع ملايين وكلاء العملاء يعملون في آنٍ واحد، فهو العمل الذي لا إطلاق له على خشبة مسرح مؤتمر. إنه العمل الذي يحدد ما إذا كان Headless 360 سيتحول إلى بنية تحتية راسخة ودائمة، أم إلى دين تنظيمي مؤجل.

فتحت سيلزفورس الباب الصحيح. ومتانة التصميم ستُقاس بما تبنيه خلف هذا العتبة.

مشاركة

قد يعجبك أيضاً