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

ثلاث طبقات للتخصيص

  • المصمّم المرئي — طبقة الشاشة. يذكر المنتِج أنّ مصمّم الشاشات بالسحب والإفلات والمكوّنات الجاهزة تتيح النشر الفوري. ولا تُكتب شيفرة في هذه الطبقة؛ بل يُعرَّف تخطيط الشاشة والحقول والمسار.
  • NOS — طبقة قاعدة العمل. لغة قواعد العمل الخاصّة بالمنصّة لدى المنتِج. وتُكتب هنا الشروط والحلقات وعمليات البيانات. وهذا موضع تحديد السلوك خلف الشاشة.
  • الوكيل — طبقة التنفيذ. يذكر المنتِج أنّ الوكيل يخطّط المهمّة بنفسه، ويتنقّل بين الشاشات، وينفّذ بموافقة المستخدم. ويُذكَر أنّه يمكن طرح الأسئلة باللغة الطبيعية وإجراء تحليل للعمليات.

وتحمل هذه الثلاث مخاطر مختلفة. فتخصيص الشاشة يمكن التراجع عنه؛ وتخصيص قاعدة العمل يؤثّر في البيانات؛ أمّا تنفيذ الوكيل فـيُنتج سجلّات.

طبقة الشاشة: الخيط الرفيع بين السهولة والنطاق

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

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

طبقة قاعدة العمل: NOS

NOS لغة خاصّة بالمنصّة تُكتب بها قواعد العمل. وتُظهر الصيغة النموذجية التي ينشرها المنتِج شروطًا وحلقات تعمل على مجموعة سجلّات.

والأسئلة المطروحة في طبقة قواعد العمل مستقلّة عن المنتج وهي نفسها في كلّ ERP:

  • أين تعمل القاعدة: على الشاشة، أم عند الحفظ، أم في الخلفية؟
  • إذا مسّت قاعدتان السجلّ نفسه، أيّهما تعمل أولًا؟
  • هل يُصدَّر نصّ القاعدة بأرقام؟ وبأيّ إصدار قاعدة حُسب سجلّ سابق؟
  • عند تغيّر القاعدة، هل يُعاد حساب فترة مقفلة؟

والسؤالان الأخيران حرجان في جانب المالية والتكلفة؛ فالقاعدة غير المصدَّرة بأرقام تغيّر تقارير الفترات المقفلة بصمت.

طبقة الوكيل: ذكاء اصطناعي يُنتج سجلّات

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

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

ثلاثة أرقام تُبقي التخصيص قابلًا للقياس

  • عدد الشاشات المخصَّصة بالمصمّم المرئي.
  • عدد قواعد العمل المكتوبة بـNOS.
  • عدد أنواع العمليات التي يستطيع الوكيل تنفيذها بلا موافقة.

والثالث أكثرها حساسية وينمو بصمت مع الوقت: فكلّ طلب «ليفعل الوكيل هذا أيضًا» يزيده واحدًا. وحين لا يُتابَع هذا الرقم، يحدث توسّع في الصلاحيات لم يمنحه أحد عن وعي.

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

الأسئلة الشائعة

هل يجب توثيق التخصيص المنفَّذ بلا كتابة شيفرة أيضًا؟

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

هل يستطيع وكيل الذكاء الاصطناعي إنشاء قيد محاسبي؟

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

هل تُنشئ لغة خاصّة بالمنصّة مثل NOS تبعية؟

تُنشئ قدرًا منها؛ وهذا يصحّ في كلّ ERP يقدّم منصّة تطويره مع المنتج. والذي يدير التبعية ليس اللغة بل توثيق القواعد وتأهيل المستخدمين الرئيسيين. ونشرح الانضباط نفسه في مقال التخصيص في CANIAS ERP.

لماذا يهمّ الفرق بين اقتراح الوكيل وتنفيذه؟

الاقتراح يمكن تجاهله، أمّا التنفيذ فيترك سجلًّا. فالوكيل العامل في وضع الاقتراح منخفض الخطر؛ أمّا العامل في وضع التنفيذ فيصير جزءًا من نموذج الصلاحيات ويجب تصميمه على هذا الأساس.