Enterprise AI has shifted. A few years back, convincing leadership to even test machine learning was an uphill battle. N

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

حيث تموت المشاريع التجريبية

الجميع يحب العروض التوضيحية. النموذج الأولي يتنبأ بمعدل فقدان العملاء (churn) بدقة مذهلة، فيومئ مجلس الإدارة بالموافقة وتتدفق الأموال. ثم يسود الصمت. يتم اعتماد إثبات المفهوم (proof of concept)، لكن التقدم يتوقف. ماذا حدث؟

تحدق فرق العمل في لوحة البيانات ولا تستطيع فهم كيفية ملاءمتها لسير عملهم اليومي. مسار البيانات (data pipeline) الذي غدّى النموذج كان مجرد عملية استخراج يدوية لمرة واحدة لا يملكها أحد. تتغير قواعد الامتثال في منتصف الطريق. يتطلب النظام مدخلات نظيفة لم ينتجها نظام إدارة علاقات العملاء (CRM) قط. يعمل الذكاء الاصطناعي في بيئة العمل البرمجية (notebook)، لكن المؤسسة لا تعرف ماذا تفعل به.

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

فجوة التواصل

لنسمِّ الأمور بمسمياتها. يريد التنفيذيون نمواً في الإيرادات أو خفضاً في التكاليف. وتريد العمليات السرعة دون فوضى. وتريد فرق البيانات مخططات (schemas) منطقية. بينما يريد المهندسون استمرارية الخدمة (uptime) وواجهات برمجة تطبيقات (APIs) نظيفة. لا تتماشى هذه الرغبات بشكل طبيعي.

إذا تُركت كل مجموعة بمفردها، فإنها ستحسن شيئاً مختلفاً. قد يقضي المهندس أسابيع في تقليل زمن الاستجابة (latency) لنقطة نهاية التنبؤ، بينما لا يزال فريق المبيعات يصدر كل شيء إلى Excel لأن واجهة المستخدم تربكهم. قد ينشغل عالم البيانات بالتدقيق في الخانة العشرية الرابعة لـ AUC، بينما يقوم فريق المستودع بتسجيل قيم فارغة (nulls) في حقل حيوي لمدة ستة أشهر. لا أحد مخطئ، هم فقط يتحدثون لغات مختلفة.

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

ما الذي يفعله مهندسو النشر الميداني (Forward Deployed Engineers) حقاً

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

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

في أي مهمة نموذجية، سيقوم مهندس النشر الميداني بما يلي:

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

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

قِس مدى التبني، وليس الدقة فحسب

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