عندما تبدو كل الشاشات صحيحة لكن النظام نفسه غير متماسك

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

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

اتبع المعاملة لا الشاشة

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

• المبيعات ترى عميلاً محتملاً.
• التمويل يرى طلباً.
• التسليم يرى طلب شحن أو تسليم.
• العميل يرى حالة مختصرة.
• الإدارة ترى الصورة الأوسع.

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

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

ما الذي يجب أن يبقى ثابتاً؟

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

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

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

الواجهة بحسب الدور، لا نظام منفصل لكل دور

قد يبدو من السهل بناء تطبيق مستقل للمبيعات وآخر للتمويل وثالث للتسليم. لكن الفصل في الواجهات لا ينبغي أن يعني فصل المعنى في البيانات.

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

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

الاستثناءات تكشف جودة التصميم

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

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

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

أين يدخل الذكاء الاصطناعي؟

ينتقد المقال سؤالاً شائعاً: «في أي شاشة نضع وكيلاً ذكياً؟». السؤال الأهم هو: ما العمل الذي يمكن تنفيذه على حالة العمل الحالية قبل أن يحتاج الإنسان إلى اتخاذ قرار؟

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

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

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

من تصميم الشاشات إلى تصميم النظام

يقترح المقال تحولاً في ترتيب التفكير التصميمي. بدلاً من البدء بـ:

شاشة → تدفق → ميزة

يبدأ العمل بـ:

كائن → علاقة → حالة → إجراء → صلاحية

وعندما يشارك الذكاء الاصطناعي في العمل، يصبح التسلسل:

كائن → حالة → عمل → وكيل → قرار بشري

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

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