ملاحظة المحرر: على مدار العقدين الماضيين، كان جدار السواتل الخاص بـ SaaS يُبنى إلى حد كبير على واجهة المستخدم. لوحات القيادة، والحقول، وتدفقات الموافقة، وعادات المستخدمين ليست مجرد واجهات تشغيل، بل شكلت أيضًا طريقة عمل المنظمات وترتيب بياناتها. عندما يمكن للذكاء الاصطناعي قراءة البيانات مباشرة، واستدعاء الأدوات، وتنفيذ العمليات، يبدأ التعلق الناتج عن الذاكرة العضلية البشرية في التراجع، ولم تعد واجهة المستخدم بالضرورة الواجهة الأساسية للبرمجيات المؤسسية.
هذا لا يعني أن نظام التسجيل فقد قيمته، بل أن دفاعه ينتقل: من واجهة المستخدم وعادات الاستخدام، إلى نموذج البيانات، ونظام الصلاحيات، والمسؤولية الامتثالية، والمنطق التجاري، وحلقة التنفيذ، وشبكة التعاون متعددة الأطراف. قد لا تكون البرمجيات ذات الحواجز الحقيقية في المستقبل مجرد قواعد بيانات تسجل عمل البشر، بل أنظمة إجرائية قادرة على التقاط السياق، وبدء المهام، وتنسيق الوكلاء، وتوليد بيانات جديدة باستمرار أثناء التنفيذ.
عندما تتجه البرمجيات نحو الوضع بدون واجهة، يتغير السؤال الأساسي للبرمجيات المؤسسية: لم يعد القيمة مقتصرة على من يملك البيانات، بل من يستطيع تنظيم الإجراءات حول البيانات.
Below is the original text:
في الشهر الماضي، أعلنت Salesforce عن فتح واجهات برمجة التطبيقات وطرح منتج headless (خالٍ من واجهة المستخدم). جوهر ذلك يعني أن Salesforce تُركز على أن قيمتها الأساسية لم تعد تأتي بشكل رئيسي من واجهة المستخدم، بل من طبقة البيانات. إنها إعادة توجيه ذكية إلى حد كبير.
ومع ذلك، يجب الإشارة إلى أنه من الناحية التقنية، يبدو أن هذا الإصدار لم يجلب الكثير من التغييرات الجوهرية. فواجهات برمجة التطبيقات التي أعادت Salesforce تسميتها كـ "منتجات بدون رأس" كانت موجودة إلى حد كبير لسنوات عديدة. وبعبارة أخرى، إنها أكثر شبهاً بإطلاق تسويقي نموذجي من Salesforce.
الفكرة الأساسية لهذا المنتج الجديد هي أن العامل يمكنه الوصول مباشرة إلى بيانات نظام السجلات، دون الحاجة إلى التفاعل عبر واجهة مستخدم مصممة للبشر. تتمثل وظيفة واجهات المستخدم التقليدية في مساعدة المستخدمين البشريين على تتبع العمليات وإدارة المهام ودفع سير العمل؛ لكن مع دخول العامل، يبدأ دور هذه الطبقة من الواجهة في الانخفاض.
الجانب الحقيقي الذي يستحق المناقشة في هذا الإصدار ليس فقط ما أطلقه Salesforce من منتجات جديدة، بل السؤال الأعمق الذي طرحه: إذا تم إزالة واجهة المستخدم وفتح قاعدة البيانات الأساسية فقط، فماذا يبقى من نظام تسجيل؟ وما الفرق الحقيقي بينه وبين قاعدة بيانات Postgres، ومجموعة مصممة جيدًا من مخططات البيانات، ومجموعة من واجهات برمجة التطبيقات؟
بشكل أعمق، هل لا تزال العوامل الكلاسيكية التي جعلت أنظمة التسجيل قادرة على الدفاع عن نفسها على المدى الطويل سارية المفعول؟ أم أن معايير تنافسية جديدة ظهرت؟
في عصر SaaS، تمتلك أنظمة التسجيل حواجز دفاعية لأن المستخدمين البشريين يعيشون لفترات طويلة داخل واجهاتها. فالواجهة تحمل عادات التشغيل، وعمليات التنظيم، وتراكم البيانات، مما يخلق تكلفة انتقال عالية. لكن في عصر الوكلاء، يُضعف هذا الميزة. إن الطبقات التي تمتلك فعلاً قدرة دفاعية تتجه إلى الأسفل نحو نماذج البيانات، وأنظمة الصلاحيات، ومنطق سير العمل، وقدرات الامتثال؛ وفي الوقت نفسه تتجه إلى الأعلى نحو تأثير الشبكة، وقدرات توليد البيانات الحصرية، وقدرات التنفيذ في العالم الحقيقي.
عندما تصبح البرمجيات بدون واجهة رسومية، أين ستنتقل حواجز المنافسة؟
كانت واجهة المستخدم ذاتها هي المنتج
يُشار إلى نظام السجل (System of Record، SoR) على أنه المصدر الموثوق لبيانات الأعمال من نوع معين. إنه المكان الذي توجد فيه النسخة الرسمية للبيانات مثل علاقات العملاء أو سجلات الموظفين أو المعاملات المالية، وهو النظام الأساسي الذي تقرأ منه الأدوات الأخرى البيانات وتكتب إليها. يُعد CRM نظام سجل للبيانات المتعلقة بالإيرادات، وHRIS هو نظام سجل للبيانات المتعلقة بالموظفين، بينما يُعد ERP نظام سجل للبيانات المتعلقة بالمال والمحاسبة.
قوة هذه الأنظمة لا تكمن فقط في تخزينها للبيانات، بل في أنها تصبح في النهاية الإصدار الوحيد للواقع الذي تعتمد عليه整个 المنظمة في عملها.
على مدار العقدين الماضيين، كانت Salesforce تبيع للعملاء مجموعة من الطرق التي تساعد قادة المبيعات على إدارة فرقهم. كانت اللوحات الإحصائية، وعرض أنابيب المبيعات، وأدوات التنبؤ، وتدفق المعلومات الديناميكي هي المنتجات الفعلية التي تم شراؤها. وقد بُني نموذج عملها على بيع مقاعد للمستخدمين، والتي توفر في جوهرها وصولاً إلى الوظائف المذكورة أعلاه. إن قاعدة البيانات الأساسية بالطبع أساسية، لكنها تبدو في تجربة المنتج كبنية تحتية خفية.
بمعنى آخر، ما يدفع ولاء المستخدمين حقًا هو واجهة المستخدم.
واجهة المستخدم قيدت المعايير البيانات وشكلت لغة مشتركة: التلميحات، فرص المبيعات، حسابات العملاء. لقد جعلت آلاف ممثلي المبيعات يدخلون باستمرار بيانات كانوا في الأصل غير راغبين في إدخالها. في الماضي، كانت واجهة المستخدم هي الآلية التي حافظت على اتساق البيانات وصلاحيتها. السبب في أن Salesforce يتمتع بدرجة عالية من الالتصاق، لدرجة أن العديد من مديري المبيعات يحافظون على استخدام Salesforce عند الانتقال إلى شركات جديدة، ليس بسبب جودة واجهته، بل لأنه أصبح عادة عضلية.
لكن الوكلاء يبدأون في تغيير هذا النموذج. فلم تعد تحتاج إلى التفاعل مع البرامج عبر واجهة المستخدم، بل يمكنها قراءة وكتابة البيانات الأساسية مباشرة. وهذا أدى أيضًا إلى ظهور مجموعة من الأدوات والبدائل الجديدة التي تتجاوز الواجهات التقليدية. Salesforce ليس المثال الوحيد: فقد ناقشنا مؤخرًا كيف ينمو نظام بيئي كامل حول SAP أكثر ملاءمة لاستدعاءات الذكاء الاصطناعي.
في الوقت نفسه، سيجعل وجود وكلاء قادرين على تشغيل أجهزة الكمبيوتر العوامل التقليدية على المستوى البشري، مثل التفضيلات والتدريب والسياقات غير الموثقة، تدريجيًا أقل أهمية مع مرور الوقت. وبعبارة أخرى، تتغير الشروط المطلوبة لتصبح نظامًا تسجيليًا مستمرًا.
معايير التقييم السابقة
قبل مناقشة ما الذي سيتغير في عصر الوكلاء، من الضروري العودة بدقة إلى سؤال واحد: ما الذي جعل أنظمة التسجيل لاصقة في الماضي؟
العوامل القليلة الأولى تتعلق بشكل رئيسي بكيفية استخدام البشر للبرمجيات، وتحيزات البشر أنفسهم. يصعب استبدال البرمجيات إلى حد كبير بسبب واجهة المستخدم، وعادات الاستخدام، وسير العمل البشري، والترتيبات المؤسسية المدمجة بالفعل في عمليات المنظمة.
أولاً، ما مدى تكرار زيارته؟
يُستخدم CRM يوميًا من قبل فريق GTM وعدد أكبر من الأقسام المعنية. إن هذا الاستخدام العالي التكرار يجعله بنية تحتية حاسمة. أما الطبقة البشرية المبنية عليه — مثل اجتماعات الفريق، العادات التشغيلية، وإيقاع الإدارة، وهي عادات تنظيمية تشكلت على مدار سنوات — فهي غالبًا الجزء الأصعب في النقل. السبب هو أنه غالبًا لا يُعترف حتى كـ"شيء يحتاج إلى النقل".
ثانيًا، هل هو للقراءة فقط أم للقراءة والكتابة؟
نظام سجلات حقيقي ذو قابلية ترابط، عادةً ما يكون نظامًا ثنائي الاتجاه للقراءة والكتابة. على سبيل المثال، نظام إدارة علاقات العملاء (CRM)، ليس نظامًا يُستخدم فقط لتخزين البيانات، بل يتم قراءته باستمرار. كل تسجيل مكالمة، وكل تحديث للمرحلة، وكل إنشاء مهمة، يتم إدخاله من قبل مستخدم معين، وغالبًا ما يكون هذا المستخدم مهتمًا بكيفية استخدام هذه البيانات لاحقًا.
هذا التدفق الثنائي يعني أن أي بديل يجب أن يكون قادرًا على استيعاب بيانات التشغيل في الوقت الفعلي، وليس فقط تصدير نسخة من البيانات التاريخية. لا يوجد تقريبًا نقطة تحول آمنة مطلقة أثناء عملية النقل. لذلك، بمجرد أن تكمل الشركة الت上线، غالبًا ما تبقى على المدى الطويل ضمن نظام المزود الأصلي.
على العكس، فإن أنظمة تتبع المرشحين (ATS) تكون عادةً أقرب إلى أنظمة "الكتابة فقط". بعد تعيين المرشح أو رفضه، تصبح الأسباب لاستخدام الشركة لهذه البيانات لاحقًا محدودة نسبيًا.
ثالثًا، كم عدد إجراءات العمل القياسية غير الموثقة؟
السياق التجاري الحقيقي المهم غالبًا لا يُكتب في أي wiki، بل يترسب في قواعد سير العمل التي بناها المشرفون ودمجوا الأنظمة على مدار سنوات.
على سبيل المثال، في نظام المبيعات، قد تشمل هذه السياقات غير الموثقة ما يلي: تتطلب المعاملات المؤسسية التي تزيد عن 100 ألف دولار موافقة نائب الرئيس؛ يجب أن تخضع معاملات منطقة أوروبا والشرق الأوسط وأفريقيا لمراجعة الخصوصية؛ لا يمكن تجاوز الموافقة المالية على الخصومات الممنوحة للعملاء الاستراتيجيين إلا في نهاية الربع.
غالبًا ما تحدد هذه السياقات ما إذا كان يمكن دفع شيء ما في الوقت المناسب، أو إكماله دون انتهاك العمليات الأساسية. نقل النظام يعني إعادة تفكيك كل قاعدة أتمتة؛ وإلا، فقد تفقد الشركة جزءًا من ذاكرة المنظمة مباشرة.
رابعًا، مدى تعقيد الاعتمادات الداخلية أو الخارجية؟
المشكلة الأساسية هي: كم من الأنظمة الداخلية، وعمليات الفرق، أو الأطراف المعنية الخارجية تعتمد على نظام التسجيل هذا؟
الاتصال الداخلي يشير إلى عدد البرامج أو سير العمل التابعة التي تعتمد عليه. أما الاتصال الخارجي، فيشير إلى ما إذا كانت الجهات الخارجية مثل مراجعي الحسابات والمحاسبين والهيئات التنظيمية تحتاج إلى الوصول المباشر إلى بياناته. يُعد ERP مثالًا نموذجيًا.
كلما زادت الاتصالية، سواء كانت داخلية أو خارجية، زادت تعقيد العلاقات التي يجب تفكيكها وإعادة بنائها أثناء النقل.
خامسًا، من منظور الامتثال، ما مدى أهمية البيانات؟
السؤال الأساسي هنا بسيط: هل هذا النظام ذو طابع متوافق مع التنظيمات؟
يجب أن توفر الأنظمة الحاسمة للامتثال، مثل أنظمة الرواتب وERP وبيانات الموارد البشرية، مصدرًا واقعيًا قانونيًا وتحكمًا صارمًا في صلاحيات المشرفين. قد يتطلب أي نقل تدخلًا مباشرًا من مدققي الحسابات والهيئات التنظيمية. وهذا يجعلها أكثر ارتباطًا بشكل ملحوظ.
توجد بيانات المبيعات وأدوات دعم العملاء مثل Zendesk في الطرف الآخر. بالطبع، تهتم الشركات بالاستمرارية والسياق، ولكن عادةً لا تُثير تغييرات البيانات أو منح صلاحيات الوصول مخاطر تنظيمية فورية.
ليست جميع أنظمة التسجيل تمتلك نفس مستوى تكلفة التحول. مقارنة CRM وATS ضمن نفس مجموعة الأبعاد ستظهر الفجوة بوضوح شديد.
ATS أداة تدفق عمل مصممة لعمليات محدودة، وتتمحور حول التوظيف. بمجرد قبول المرشح أو رفضه، تصبح السجلات ذات الصلة غالبًا بيانات تُكتب مرة واحدة فقط. نطاق تكاملها أضيق، ومجتمع مستخدميها أصغر وأكثر تركيزًا.
يوجد ERP في الطرف الآخر من الطيف. فالميزانية العمومية هي نفسها أثر التدقيق، وسيصبح المحاسبون ومراجعو الحسابات والهيئات التنظيمية أطرافًا مهتمة مباشرة في عملية الهجرة.
استبدال ATS مؤلم، لكنه لا يزال مقبولاً. استبدال CRM مثل إجراء جراحة فتح الصدر. واستبدال ERP مثل إجراء جراحة فتح الصدر للمرضى أثناء ركضهم ماراثونًا.
تقليديًا، لم تستغل أنظمة التسجيل حقًا مصادر الحواجز التنافسية مثل البيانات الحصرية وتأثيرات الشبكة؛ عادةً ما كان تدفق العمل نفسه كافيًا لتشكيل الحواجز. إلى حد ما، فإن دمج الأدوات مع الشبكة كان أكثر شيوعًا في الأعمال الاستهلاكية؛ ولم تسلك أنظمة السجلات التاريخية هذا المسار.
بيانات حصرية. على الرغم من أن العديد من أنظمة التسجيل تراكم كميات كبيرة من بيانات العملاء، إلا أنها لم تستغل هذه البيانات بشكل عميق حقًا، وفي كثير من الحالات، لا تسمح شروط العقد بذلك. وبالتالي، على الرغم من أن أنظمة إدارة علاقات العملاء تمتلك مجموعات بيانات غنية ويمكن نظريًا تجميع بيانات العملاء المختلفين لإنشاء رؤى عبر العملاء، إلا أنها لم تفعل ذلك أبدًا بطريقة ذات مغزى حقيقي. بالطبع، كانت هناك بعض المحاولات من قبل منتجات مثل Einstein من Salesforce.
التأثير الشبكي. كانت أفضل حواجز التنافس المثالية لأنظمة التسجيل هي التأثير الشبكي: على سبيل المثال، تصبح أنظمة إدارة علاقات العملاء أكثر قيمة عندما يمكن للبائعين البرمجيات العثور على مشترين داخلها. لكن مثل البيانات، كانت التأثيرات الشبكية لأنظمة التسجيل تاريخيًا ضعيفة جدًا، بل ويمكن القول إنها شبه معدومة.
إذا اختفى الواجهة، ماذا يبقى من البرنامج بعد وصول العامل؟
لا يحتاج الوكيل إلى متصفح. ما يحتاجه هو واجهة برمجة التطبيقات، والسياق، والتعليمات، وقدرة تنفيذ الإجراءات. هناك أمرين يجعلان كل هذا ممكنًا على نطاق واسع: أولًا، أن نماذج اللغة الكبيرة تمتلك الآن قدرة استدلال كافية، لذا يمكن للوكيل اليوم قراءة السياق، ووضع خطة، واختيار الأدوات، وتنفيذ الإجراءات، ومراجعة النتائج، دون الحاجة إلى تدخل بشري في معظم المهام؛ ثانيًا، أن MCP قيّس طريقة الوصول إلى الأدوات، وقدم واجهة عامة للوكيل لاستدعاء القدرات الخارجية.
ع agent يمتلك صلاحيات الوصول إلى MCP يمكنه إنجاز العمليات التي كان يقوم بها المستخدمون البشريون على المنصة في زمن ميلي ثانية وبحجم كبير، دون الحاجة إلى متصفح. وفي حال توفر السياق الكافي، يمكن لـ agent قادر على تشغيل الكمبيوتر استخدام واجهات البرامج الحالية مباشرة، دون الحاجة بالضرورة إلى واجهات برمجة التطبيقات (API).
ببساطة، يمتلك مشترو البرمجيات الآن ثلاث مسارات:
أولاً، استمر في استخدام النظام الحالي وقم بإضافة العامل عليه.
استخدامها من خلال واجهة سطر الأوامر (CLI) وواجهة برمجة التطبيقات (API) للنظام الحالي، يمكن استخدام منتجات الوكلاء الأصلية من البائع، مثل Agentforce من Salesforce وJoule من SAP، أو بناء وكلاء مخصصين عليها. بالطبع، نفترض هنا مؤقتًا أن واجهة برمجة التطبيقات (API) كاملة وقابلة للاستخدام، ونستبعد مؤقتًا التعقيدات التي قد تنشأ من "الإزالة الكاملة للواجهة" في التشغيل الفعلي.
ثانيًا، نظام تسجيل مُنشأ بالكامل ذاتيًا.
يمكن للشركات بناء نماذج بياناتها وعملياتها ونظام صلاحياتها وتتبع المراجعة وتكامل أنظمتها، بالإضافة إلى مكدس Agent الخاص بها، من الصفر. من المرجح أن تعتمد هذه المسار على أدوات تطوير Agent من طرف ثالث وأدوات قواعد البيانات.
Third, purchase AI-native alternatives.
يمكن للشركات أيضًا شراء البرمجيات الجديدة التي تم تصميمها من البداية لعصر الوكلاء. تُركّز هذه المنتجات على قابلية القراءة من قبل الآلات، وتعتبر ترتيب الوكلاء قدرة أساسية، وليس إضافة وظيفة ذكاء اصطناعي كتصحيح لأنظمة قديمة. قد تكون هذه المنتجات أيضًا بدون واجهة مستخدم.
ما الذي سيتم الاحتفاظ به من معايير التقييم القديمة؟
العوامل التي تُدفع بواسطة السلوك البشري والتفضيلات، مثل تكرار الزيارات وخصائص القراءة والكتابة المرتبطة بذاكرة العضلات البشرية، ستتضاءل تدريجيًا. قد يُضعف الوكيل قيمة "ذاكرة العضلات" كحاجز تنافسي، لكنه لن يُزيل الحاجز التنافسي المتمثل في المنطق التشغيلي والسياق التجاري. وبطريقة ما، فإنه يجعل هذه المنطقات أكثر أهمية، لأن الوكلاء يجب أن يعتمدون على قواعد وصلاحيات وتعريفات إجرائية واضحة لتنفيذ المهام بأمان.
الإجراءات التشغيلية القياسية غير الموثقة لا تزال مهمة على المدى القصير.
المنطق المؤسسي المُخزّن في قواعد سير العمل هو بالضبط ما يحتاجه العامل لتنفيذ المهام نيابةً عنك بشكل صحيح. وفي الوقت نفسه، فهو أصعب جزء لإعادة بنائه. على الأقل حاليًا، لا يمكن تصديره بشكل نظيف، خاصةً عندما لا تزال بعض العمليات تتطلب مشاركة بشرية. ومع ذلك، فإن التقاط السياق يصبح أسهل تدريجيًا؛ مع استبدال العامل لمزيد من العمل اليدوي، ستقل أهمية هذا العامل تدريجيًا.
الاتصال لا يزال صعب التفكيك، وسيمتد إلى أعماق أكبر.
معنى الاتصال يتغير. لم يعد يهدف فقط إلى دعم العمل البشري، بل إلى الحفاظ على الاتصال بين الوظائف والبرمجيات التي كانت تقليديًا منفصلة عن بعضها البعض.
يحتاج وكيل CRM إلى ربط البيانات والسياق من مراحل مختلفة مثل المبيعات والفواتير ونجاح العملاء. إذا أصبح منصتك أيضًا عقدة تتعامل مع عدة منظمات خارجية، مثل المشترين والبائعين والشركاء الذين يكملون تفاعلاتهم من خلالها، فستزداد التبعيات بشكل أكبر.
عند دمج وكلاء من شركات مختلفة، قد يكون من الصعب تحقيق تعاون سلس بين الكائنات والمنطق الأساسي للبرمجيات الأساسية المختلفة؛ كما ستواجه الشركات التي تعتمد فقط على قاعدة بيانات مخصصة ومجموعة من الوكلاء مشاكل مشابهة.
البيانات الأساسية للامتثال لا تزال مهمة.
لا تزال البيانات المتعلقة بالجهات التنظيمية، أو المخاطر التنظيمية، أو المخاطر القانونية بحاجة إلى مصدر واحد موثوق لحقائق البيانات. إذا كان العملاء قد ثقوا بالمنتجات الحالية، فإن احتمالية تبديلهم للنظام ستكون أقل.
على سبيل المثال، قد يحتاج العامل حقًا إلى الوصول إلى بيانات الرواتب والمحاسبة، لكن الشركات عادةً ما تكون أقل احتمالًا لاختيار بناء وصيانة هذه الأنظمة داخليًا على المدى الطويل.
في عالمٍ مُكَمَّلٍ بالوكلاء، أحد أصعب المشكلات التي يجب حلها هو: ما الذي يُصرح للوكلاء بفعله؟ ومن يمثلون؟ كيف يتم مراجعة هذه السلوكيات؟ إذا استطاع نظام تسجيل أن يصبح طبقة هوية وصلاحيات للتفاعل بين الوكلاء، فإنه سيكتسب دورًا هيكليًا صعبًا جدًا لاستبداله. الحواجز هنا ليست فقط في البيانات التي يمتلكها، بل في هيكل الثقة الذي ينفذه.
بالنظر إلى الأمام، ستصبح مجموعة من العوامل الجديدة أكثر أهمية بالنسبة للشركات الناشئة الأصلية في مجال الذكاء الاصطناعي، وستحدد قدرتها على تكوين حماية تنافسية.
أولاً، ما مدى صعوبة إعادة بناء نظام السجل هذا؟
ستصبح البيانات أكثر أهمية على عدة مستويات.
أولاً، على المدى القصير، يكمن المفتاح في سهولة استخراج وإعادة بناء بيانات نظام السجل الأساسي. إن الذكاء الاصطناعي يجعل هذا الأمر أسهل، وتساعد مجموعة من الأدوات المستخدمين على إجراء هذه الهجرات وإعادة البناء.
على المدى القصير، يمكن للشركات الحالية، وستكون من المحتمل جداً، أن تجعل هذا الأمر أكثر صعوبة: يمكنها جعل واجهات برمجة التطبيقات صعبة الاستخدام، أو محدودة، أو غير كاملة، أو غير اقتصادية من الناحية المالية، أو حتى عدم توفير واجهات برمجة التطبيقات على الإطلاق. لكن مع تطور أدوات الاستخراج باستمرار، خاصة مع تحسن قدرات الوكلاء القادرة على تشغيل الحواسيب، سيصبح إعادة بناء البيانات أسهل وأسهل.
في الوقت نفسه، تقوم الشركة الجديدة أيضًا بإعادة بناء مجموعة بيانات أكثر ثراءً من البريد الإلكتروني والمكالمات الهاتفية ووكلاء الصوت والوثائق الداخلية. لقد خفّض الذكاء الاصطناعي تكلفة إعادة بناء نظام تسجيل أول 80٪. ما يميز نقطة دخول مفيدة عن بديل حقيقي هو الـ 20٪ المتبقية: الحالات الاستثنائية، وعمليات الموافقة، ومتطلبات الامتثال، وسير العمل في السيناريوهات الحدية.
ثانيًا، هل تمتلك بيانات خاصة ذات مغزى حقيقي؟
Secondly, the data itself will become more valuable.
البيانات ذات الخصائص الدفاعية الحقيقية ليست البيانات التي تستوردها، بل البيانات التي يُنتجها منتجك بطريقة فريدة. نحن نتحدث غالبًا عن "حديقة جدارية للبيانات": هذه البيانات إما حصرية، أو خاضعة لقيود تنظيمية، أو تتطلب تحديثًا مستمرًا. سيكون مزود البرمجيات الذي يستثمر موارد كبيرة في جمع بيانات سليمة وشاملة متفوقًا بوضوح على الموردين العامين أو المنافسين الذين يفتقرون إلى هذه البيانات.
البيانات لها اتجاه مهم آخر: هل هي تعتمد على الإجراءات التي تُنتج داخل المنتج؟
أفضل الشركات لا تكتفي بتخزين البيانات المُدخلة من مصادر خارجية. بل تُنتج باستمرار أثرًا جديدًا من البيانات بسبب مشاركتها في العمليات، مثل السلوك الملاحظ، ومعدلات الاستجابة، وأنماط الوقت، ونتائج العمليات، ومعايير الصناعة، وأنماط الاستثناءات، ومسارات تنفيذ الوكلاء.
المفتاح هو: البيانات هي السياق الآن.
ثالثًا، هل تتقن طبقة الحركة؟
في العالم القديم، كان تخزين السجلات كافيًا بحد ذاته. لكن في العالم الجديد، سيتخذ الوكيل إجراءات مباشرة، وقد تتحول الدفاعية نحو المنتجات القادرة على تكوين حلقة مغلقة: من اتخاذ الإجراء، إلى التقاط النتائج، ثم استخدام التغذية الراجعة لتحسين القرارات المستقبلية.
بالنسبة لـ ERP، قد يشمل ذلك الموافقة على المصروفات، وتفعيل صرف الرواتب، ومطابقة الفواتير، وإرسال الإشعارات. المنتجات القادرة على إغلاق الحلقة تكون أكثر دفاعًا لأنها تدمج عملية التنفيذ، وليس فقط البقاء على مستوى المراقبة. فهي تولد بيانات فريدة تتحسن مع الاستخدام، وتكون أصعب في الاستبدال لأن إزالتها ستُعطّل سير العمل.
Of course, as more context is accumulated and edge cases are handled more thoroughly, the value here will continue to rise.
رابعًا، هل يشمل مراحل تنفيذ في العالم الحقيقي؟
بعض نماذج الأعمال متصلة بعمليات في العالم الحقيقي، وهذه الحلقات لا تُؤتمت بالكامل. المثال الأكثر وضوحًا هو الشركات التي تمتلك شبكات تشغيلية، مثل DoorDash. لم تكن هذه الشركات جزءًا من أنظمة التسجيل تاريخيًا، لكنها ذات دلالة كبيرة هنا.
بشكل أوسع، أي شركة يمكنها توسيع الحل البرمجي المغلق ليشمل الخدمات، أو التنفيذ، أو اللوجستيات، أو العمليات الميدانية، أو الدفع، تمتلك نوعًا من الحماية يختلف عن نموذج SaaS البحت. هذه الشركات لا تقتصر فقط على تخزين السجلات أو اقتراح الإجراءات؛ بل تقوم بإرسال أشخاص، أو نقل البضائع، أو إتمام خدمات محددة.
بالنسبة لرواد الأعمال، فهذا يعني أن الفرص قد تظهر في أسواق حيث تصبح البرمجيات أكثر قدرة على اتخاذ القرارات، وتصبح الوكلاء أكثر قدرة على تنسيق العمليات، لكن آخر كيلومتر لا يزال يتطلب تنفيذًا في العالم الحقيقي. على سبيل المثال، فإن البرمجيات الرأسية المرتبطة بالخدمات الميدانية هي اتجاه نموذجي.
خامساً، هل هناك تأثير شبكي؟
تاريخيًا، كانت تأثيرات الشبكة في معظم أنظمة التسجيل ضعيفة، لأنها كانت في основном برامج داخلية. لكن في عصر الوكلاء، إذا تم تضمين نظام في سير عمل متعددة الأطراف، فقد تصبح تأثيرات الشبكة أكثر أهمية بكثير.
إذا كان نظام ما مسؤولًا عن تيسير التفاعلات المتكررة بين أطراف متعددة، مثل المشترين والبائعين، وأصحاب العمل والموظفين، والشركات والمدققين، والموردين والعملاء، والمدفعين ومرسلي الخدمة، فإن كل طرف إضافي قد يزيد من قيمة هذا الشبكة للطرف التالي.
إحدى الطرق هي مشاركة سير العمل التعاوني: حيث يصبح المنتج مكانًا لإجراء المعاملات وتبادل السياق ومعالجة الاستثناءات من قبل الطرفين.
طريقة أخرى هي المعيار والذكاء: يمكن للنظام أن يعرض الوضع الطبيعي للصناعة، والحالات الاستثنائية، والتوصيات الإجرائية بناءً على الأنماط الملاحظة في الشبكة، وهو ما يعزز قيمة البيانات المذكورة سابقًا.
الطريقة الثالثة هي الثقة والتوحيد: بمجرد أن يبدأ الطرف المقابل في الاعتماد على نفس مجموعة المسارات لإتمام الموافقة أو التسليم أو الامتثال أو الدفع، يصبح هذا المنتج أكثر من مجرد قاعدة بيانات، بل يصبح البنية التحتية التعاونية للسوق نفسه، وبالتالي يصبح من الصعب استبداله.
سادسًا، ما مدى قوة القدرة التقنية للمشترين؟
في عالم يمكن لأي شخص نظريًا بناء عامل ذكي خاص به، لا تزال القدرة الفعلية على البناء بين المشترين المختلفين متفاوتة بشكل كبير. خاصة في القطاعات الرأسية، وبين المشترين الوظيفيين الذين لم يمتلكوا سابقًا موارد هندسية داخلية قوية، لا تزال احتمالية قيامهم ببناء أنفسهم وصيانتها وتحسينها المستمر لقواعد البيانات ومنطق سير العمل وطابور العامل الذكي وطبقة الحوكمة منخفضة جدًا.
التكاليف مهمة هنا أيضًا. قد يقلل التصميم الذاتي نظريًا من تكاليف ترخيص البرمجيات، لكنه غالبًا ما يحول النفقات إلى التنفيذ والصيانة والتعقيد الداخلي.
هذا يعني أنه لا تزال هناك فرص حقيقية في الفئات التي تتميز بعمليات معقدة ولكن بها نقص في العرض التقني. على سبيل المثال، التصنيع، وخلفيات البناء، وعمليات الصناعة، وسير عمل الخدمة الميدانية، ومحاسبة المجالات.
هناك عوامل أخرى مهمة بنفس القدر وستصبح تدريجيًا الحد الأدنى الأساسي للبرمجيات.
على سبيل المثال، يجب أن تتغير نظرية الكيان. العديد من أفكار "قواعد البيانات المخصصة" تقلل من قيمة النموذج الكائني نفسه. البرمجيات الحالية مبنية لوحات التحكم والتقارير والمستخدمين البشريين، وهي تلتقط الكيانات ضمن سير العمل، مثل فرص المبيعات، والتذاكر، والمرشحين، إلخ.
لكن مخطط عصر الوكلاء يحتاج إلى التقاط الاستدلال، والإجراءات، وتتبع الحالة، ومعالجة الاستثناءات، وتفويض المهام، والتعاون عبر الأنظمة. قد لا تكون النماذج الكائنية الأصلية هي الفرص، والتذاكر، والمرشحين، بل المهام، والنية، والخيوط، والاستراتيجيات، أو النتائج.
كما يجب تحديث نظام الصلاحيات. فهو لم يعد يدير المستخدمين البشريين فحسب، بل يجب أن يدير الوكلاء. ويشمل ذلك: من يمكنه做什么، من خلال أي وكيل، وتحت أي استراتيجية، وما هي الموافقات المطلوبة، وما هي أثر المراجعة المتروكة، وكيفية التراجع والتعامل مع الاستثناءات.
بالطبع، كل هذا لا ينفصل عن تكلفة بناء وصيانة العوامل وقواعد البيانات، وتكلفة الوصول إلى واجهات برمجة التطبيقات. وهذا يعيدنا مجددًا إلى عدة أسئلة جوهرية: ما مدى صعوبة إعادة بناء البيانات، وكم عدد التبعيات، وكم هو عمق تضمين النظام؟
فما هو الاستنتاج؟
مع اتجاه شركات البرمجيات الحالية نحو النموذج headless، فإنها تضع في الواقع رهانًا ضمنيًا على أن طبقة البيانات ستظل المصدر الأساسي للقيمة. في بعض الفئات، خاصةً مجالات الخدمات المالية الخاضعة لقيود تنظيمية شديدة، قد يستمر هذا الرهان في البقاء صالحًا لفترة من الوقت، وقد يتباطأ أيضًا تقدم عملية headless.
لكن بالنسبة لرواد الأعمال في البرمجيات، مع بدء الشركات القائمة في إزالة الواجهات، تغيرت طبيعة التحديات المتعلقة بكيفية المنافسة معها وكيفية بناء برامج ذات دفاع طويل الأمد.
أنظمة التسجيل من الجيل التالي بدأت تظهر بأشكال مختلفة: لم تعد مجرد مستودعات بيانات لتسجيل عمل البشر، بل أصبحت تمتلك خصائص وكيل — قادرة على التقاط السياق، وبدء العمل تلقائيًا، وتسجيل الأثر البيانات الناتج عن التنفيذ.
بشكل أعمق، ستتمدد الشركات الأكثر إثارةً إلى طبقة التنفيذ في العالم الحقيقي: فهي ستُنسق فرق العمل الميداني، ومزودي الخدمات اللوجستية، وفرق الخدمة، والأصول المادية، أو ستكون في موقع وسط بين عدة أطراف، كطبقة وسطى للتعاون متعدد الأطراف.
ستجمع هذه الشركات بين نماذج عمل متعددة من العالم القديم. وستتراجع البيانات، التي تُعد جوهر أنظمة التسجيل التقليدية، تدريجيًا إلى الخلفية، لتُصبح الأساس الداعم لتشغيل النظام بأكمله.
انقر لمعرفة الوظائف الشاغرة لدى BlockBeats
مرحبًا بانضمامك إلى المجتمع الرسمي لـ BlockBeats
قناة تيليجرام للاشتراك: https://t.me/theblockbeats
مجموعة Telegram للتفاعل：https://t.me/BlockBeats_App
الحساب الرسمي على تويتر: https://twitter.com/BlockBeatsAsia