a16z：عندما لم يعد واجهة المستخدم هي المنتج، ماذا يتبقى من الحصن المنيع للبرمجيات؟

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

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

عندما تتجه البرمجيات نحو اللامركزية (headless)، تتغير أيضًا المشكلة الأساسية لبرمجيات المؤسسات: لم يعد الأمر متعلقًا بمن يمتلك البيانات، بل بمن يستطيع تنظيم العمل حول البيانات.

فيما يلي النص الأصلي:

في الشهر الماضي، أعلنت Salesforce عن فتح واجهات برمجة التطبيقات (API)، وأطلقت منتجًا بدون واجهة (headless). جوهريًا، هذا يعني أن Salesforce تراهن: في عصر الوكلاء، لا يعود جوهر القيمة في الواجهة، بل في طبقة البيانات. وهذه إعادة تموضع ذكية جدًا.

لكن من الضروري أيضًا الإشارة إلى أنه من الناحية التقنية، لم يأتِ هذا الإصدار بالكثير من التغييرات الجوهرية. الواجهات البرمجية التي أعيد تغليفها الآن باسم “منتج بدون واجهة” كانت موجودة إلى حد كبير منذ سنوات. بعبارة أخرى، يبدو الأمر أكثر كأنه إصدار تسويقي نموذجي من Salesforce.

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

المكان الحقيقي الذي يستحق النقاش في هذا الإصدار، ليس فقط في ما أطلقته Salesforce من منتجات جديدة، بل في سؤال أعمق: إذا تم تجريد الواجهة، وفتح قاعدة البيانات الأساسية، فماذا يتبقى من نظام التسجيل؟ ما الفرق بينه وبين قاعدة بيانات Postgres، ومخطط البيانات المصمم بشكل جيد، ومجموعة API؟

وبالمزيد من التعمق، هل لا تزال العوامل الكلاسيكية التي كانت تجعل من نظام التسجيل حصنًا دفاعيًا طويل الأمد قائمة؟ أم أن معايير المنافسة الجديدة قد ظهرت بالفعل؟

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

عندما تتجه البرمجيات نحو اللامركزية، إلى أين ستنتقل الحواجز الدفاعية إذن؟

كانت واجهة المستخدم سابقًا جوهر المنتج نفسه

نظام التسجيل (System of Record، SoR)، هو مصدر الحقائق الرسمي لنوع معين من البيانات التجارية. هو المكان الذي توجد فيه النسخة الرسمية للعلاقات مع العملاء، سجلات الموظفين، أو المعاملات المالية، وهو النظام الأساسي الذي يقرأ منه الأدوات الأخرى البيانات ويكتب عليها. CRM هو نظام تسجيل البيانات المتعلقة بالإيرادات، HRIS هو نظام تسجيل بيانات الموظفين، وERP هو نظام تسجيل البيانات المالية والنقدية.

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

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

بمعنى آخر، العامل الحقيقي الذي يحفز ولاء المستخدمين هو واجهة المستخدم.

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

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

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

معايير التقييم السابقة

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

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

السؤال الأول: كم مرة يتم الوصول إليها؟

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

السؤال الثاني: هل تكتب البيانات فقط، أم تقرأ وتكتب؟

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

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

على العكس، أنظمة تتبع المرشحين (ATS) أقرب إلى أن تكون أنظمة كتابة فقط. بعد توظيف أو رفض مرشح، يكون من الصعب على الشركة استخدام البيانات مرة أخرى.

السؤال الثالث: كم من الإجراءات غير الموثقة موجودة؟

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

على سبيل المثال، في أنظمة المبيعات، قد تشمل: معاملات بقيمة تتجاوز 100 ألف دولار تتطلب موافقة نائب الرئيس؛ معاملات منطقة أوروبا والشرق الأوسط وأفريقيا (EMEA) تخضع لمراجعة الخصوصية؛ خصومات العملاء الاستراتيجيين يمكن تجاوز موافقة المالية عليها فقط في نهاية الربع.

هذه السياقات تحدد ما إذا كانت المهام ستُنجز في الوقت المناسب، أو يمكن إتمامها دون انتهاك العمليات الأساسية. نقل النظام يعني إعادة تفكيك كل قاعدة أتمتة، وإلا فإن جزءًا من ذاكرة المنظمة قد يُفقد.

السؤال الرابع: مدى تعقيد الاعتمادات الداخلية أو الخارجية؟

المسألة الأساسية: كم عدد الأنظمة الداخلية، العمليات، أو الأطراف الخارجية التي تعتمد على هذا النظام؟

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

كلما زاد الارتباط، زادت تعقيد العلاقات التي يجب تفكيكها وإعادة بنائها أثناء النقل.

السؤال الخامس: من منظور الامتثال، مدى أهمية البيانات؟

السؤال بسيط: هل هذا النظام ذو أهمية تنظيمية من ناحية الامتثال؟

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

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

ليست كل أنظمة التسجيل لها نفس تكلفة الانتقال. مقارنة CRM و ATS تظهر فرقًا واضحًا.

نظام تتبع المرشحين (ATS) هو أداة سير عمل تخدم عملية التوظيف بشكل محدود. بعد التوظيف أو الرفض، غالبًا ما تصبح البيانات لمرة واحدة، وله نطاق تكامل أصغر، وجمهور مستخدمين أكثر تركيزًا.

أما ERP، فهو سجل محاسبي يتتبع كل شيء، ويكون هدفه التدقيق، ويشترك فيه المدققون والجهات التنظيمية بشكل مباشر.

استبدال ATS مؤلم لكنه ممكن، أما استبدال CRM فهو كعملية جراحية كبرى، واستبدال ERP يشبه إجراء عملية جراحية أثناء ماراثون للمريض.

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

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

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

إذا اختفت واجهة المستخدم، بعد قدوم الوكيل، ماذا يتبقى من البرنامج؟

الوكيل لا يحتاج إلى متصفح. ما يحتاجه هو API، وسياق، وأوامر، وقدرة على تنفيذ الإجراءات. هناك أمران يتيحان ذلك بشكل موسع: الأول، أن نماذج اللغة الكبيرة (LLM) أصبحت تمتلك قدرات استنتاج قوية، لذلك يمكن للوكيل الآن قراءة السياق، وضع خطط، اختيار الأدوات، تنفيذ الإجراءات، وتحليل النتائج، دون تدخل بشري في معظم المهام؛ الثاني، أن معيار MCP موحد طرق الوصول للأدوات، ويوفر واجهة عامة لاستدعاء القدرات الخارجية.

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

ببساطة، هناك ثلاث مسارات للمشتري البرمجي الآن:

الأول، الاستمرار في استخدام الأنظمة الحالية، مع إضافة وكيل عليها.
باستخدام CLI و API الخاصين بها، يمكن استخدام منتجات الوكيل الأصلية مثل Agentforce من Salesforce، أو Joule من SAP، أو بناء وكيل خاص. هنا، نفترض أن API مكتملة ومتاحة، ونتجاهل التعقيدات التي قد تفرضها عملية اللامركزية في التشغيل.

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

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

إذن، ما الذي ستحتفظ به معايير التقييم القديمة؟

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

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

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

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

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

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

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

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

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

السؤال الأول: مدى صعوبة إعادة بناء نظام التسجيل؟

البيانات ستصبح أكثر أهمية على عدة مستويات.

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

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

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

السؤال الثاني: هل تمتلك بيانات ذات قيمة حقيقية؟

ثانيًا، البيانات ستصبح أكثر قيمة.

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

هناك اتجاه آخر للبيانات: هل تعتمد على الأفعال التي تنتجها داخل المنتج؟

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

المهم الآن: البيانات أصبحت السياق.

السؤال الثالث: هل تملك طبقة أفعال؟

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

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

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

السؤال الرابع: هل تتضمن مراحل التنفيذ في العالم الحقيقي؟

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

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

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

السؤال الخامس: هل توجد تأثيرات شبكة (Network Effects)؟

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

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

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

طريقة أخرى، هي المعايير والذكاء: أن يعرض النظام أنماط السوق، الحالات الاستثنائية، والتوصيات، مما يعزز قيمة البيانات التي ذكرناها سابقًا.

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

السؤال السادس: ما مدى قوة قدرات التقنية لدى المشتري؟

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

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

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

كما أن هناك عوامل أخرى مهمة، ستصبح تدريجيًا معايير أساسية للبرمجيات.

على سبيل المثال، يجب أن يتغير المفهوم الوجودي (Ontology). كثير من الأفكار حول “قاعدة البيانات الخاصة” تقلل من قيمة نماذج الكائنات التي تعتمد عليها. الأنظمة الحالية مصممة للواجهات، والتقارير، والمستخدمين البشريين، وتلتقط أشياء مثل الفرص، أو الطلبات، أو المرشحين.

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

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

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

فما هو الاستنتاج إذن؟

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

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

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

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

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

[رابط النص الأصلي]

انقر لمعرفة وظائف BlockBeats في التوظيف

مرحبًا بك في المجتمع الرسمي ل BlockBeats:

قناة تيلجرام: https://t.me/theblockbeats

مجموعة تيلجرام: https://t.me/BlockBeats_App

حساب تويتر الرسمي: https://twitter.com/BlockBeatsAsia