كيفية نشر وكلاء الذكاء الاصطناعي للمقاولين العموميين دون تعطيل سير العمل الحالي في Procore أو Sage أو Viewpoint التي يثق بها الميدان

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

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

لماذا تُعد ثقة النظام الحالي القيد المهم

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

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

يحدد هذا القيد كل شيء حول كيفية تصميم نشر وكلاء الذكاء الاصطناعي للمقاولين العموميين. يجب أن يعيش الوكلاء جنبًا إلى جنب مع Procore وSage وViewpoint بدلاً من التنافس معهم. يجب أن يقرأ الوكلاء من وإلى تلك الأنظمة من خلال واجهات برمجة التطبيقات (APIs) بدلاً من مطالبة الميدان بتسجيل الدخول إلى بوابة جديدة. يجب أن تظهر مخرجات الوكيل داخل الأدوات التي يستخدمها الميدان بالفعل، وليس في نظام موازٍ يجب على الميدان تذكر التحقق منه.

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

يفترض ما تبقى من هذه المنهجية أن المقاول العام قد استوعب قيد ثقة الميدان ويلتزم بنشر وكلاء يعملون جنبًا إلى جنب مع Procore وSage وViewpoint بدلاً من استبدالهم.

الخطوة الأولى: رسم خريطة لبيئة النظام الحالي

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

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

يجب أن يحدد رسم الخرائط أيضًا التكاملات الموجودة بالفعل بين الأنظمة والتكاملات المطلوبة ولكن المفقودة. توجد تكاملات Procore-to-Sage ولكنها تختلف في الجودة عبر عمليات التنفيذ. تتمتع تكاملات Procore-to-Viewpoint بتقلبات مماثلة. سيحتاج نشر الوكيل عادةً إلى الاستفادة من التكاملات الموجودة واستكمالها عند وجود فجوات.

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

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

الخطوة الثانية: تحديد سير العمل التنسيقي الذي يستحق الأتمتة

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

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

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

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

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

الخطوة الثالثة: تصميم الوكلاء الذين يقرأون من ويكتبون إلى الأنظمة الحالية

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

يعني نمط القراءة أن الوكيل يستمد بياناته التشغيلية من الأنظمة الموجودة من خلال واجهات برمجة التطبيقات الموثقة. يقرأ وكلاء طلبات المعلومات (RFI) طلبات المعلومات من Procore. يقرأ وكلاء طلبات التغيير بيانات طلبات التغيير من Procore و Sage. يقرأ وكلاء التقارير اليومية بيانات المشروع من Procore وبيانات الحقل من أي أداة التقاط يستخدمها الفريق. لا يحافظ الوكيل على نسخة منفصلة من هذه البيانات لأن القيام بذلك يخلق مشاكل مزامنة ويقوض حالة مصدر الحقيقة للأنظمة الموجودة.

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

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

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

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

الخطوة الرابعة: دمج معالجة الأخطاء في البنية من اليوم الأول

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

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

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

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

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

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

الخطوة الخامسة: النشر من خلال تجارب ميدانية مرحلية

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

تتضمن المرحلة الأولى عادةً فريق مشروع واحد يدير نوعًا واحدًا من الوكلاء. غالبًا ما يكون التعامل مع طلبات المعلومات (RFIs) هو نقطة البداية الطبيعية لأن طلبات المعلومات تحدث بشكل متكرر، وتتبع أنماطًا يمكن التنبؤ بها، وتنتج تحسينات مرئية عندما تتسارع دورة الاستجابة. يعمل فريق المشروع التجريبي عن كثب مع فريق النشر للتحقق من سلوك الوكيل والكشف عن المشكلات.

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

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

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

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

لماذا تُعد البنية أكثر أهمية من اختيار المنصة

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

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

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

يعكس نهج TFSF Ventures هذا التوجه المبني على البنية أولاً. تُقيِّم تقييمات العمليات المكونة من 19 سؤالاً، والتي تفتح كل مشاركة، بيئة نظام المقاول العام المحددة وسير العمل التنسيقي قبل تقديم أي توصية تقنية، مما يضمن أن بنية الوكيل الناتجة تعالج الواقع العملي الفعلي بدلاً من أفضل الممارسات العامة.

تعني منهجية النشر لمدة 30 يومًا أن التصميم المعماري والوكلاء الإنتاجيين يعملون في غضون أربعة أسابيع بدلاً من الدورات التي تستغرق عدة أرباع والتي تُعد نموذجية لتكامل الأنظمة التقليدية. إن بنية معالجة الاستثناءات، التي تقع في قلب كل نشر لشركة TFSF Ventures FZ-LLC، هي ما يميز بنية الوكلاء على مستوى الإنتاج عن عروض النماذج الأولية، مع نتائج موثقة تظهر انخفاضًا بنسبة ثلاثين إلى خمسين بالمائة في ساعات إدارة المشاريع لكل مشروع والقدرة على إدارة مشروعين إلى ثلاثة مشاريع إضافية متزامنة لكل مدير مشروع.

تعكس الأسعار عمق العمل. تبدأ استثمارات النشر بعشرات الآلاف المنخفضة لعمليات النشر المركزة مع عدد قليل من الوكلاء، وتتزايد مع عدد الوكلاء، وتعقيد التكامل، والنطاق التشغيلي. تتضمن جميع عمليات النشر رسومًا منفصلة لتمرير البنية التحتية للذكاء الاصطناعي تبلغ حوالي أربعمائة إلى خمسمائة دولار شهريًا من Pulse AI، بسعر التكلفة، بدون هامش ربح. يمتلك العملاء الشيفرة المصدرية بموجب ترخيص دائم، مما يزيل قفل المنصة والرسوم المستمرة لكل مقعد. يمكن للمقاولين العموميين الذين يقومون بتقييم مراجعات TFSF Ventures والبحث عن التحقق من شرعية TFSF Ventures تأكيد تسجيل الشركة بموجب RAKEZ License 47013955 ومراجعة سجل النشر المكون من 21 قطاعًا.

التصميم حول Procore على وجه التحديد

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

تدعم واجهة برمجة تطبيقات Procore أنماط القراءة والكتابة الموصوفة أعلاه، مع نقاط نهاية موثقة لطلبات المعلومات (RFIs)، والإرساليات (Submittals)، وأوامر التغيير (Change Orders)، والتقارير اليومية (Daily Reports)، وسير العمل التنسيقي الأخرى التي يعالجها الوكلاء عادةً. تستفيد بنية التكامل لعمليات النشر التي تركز على Procore من واجهات برمجة التطبيقات هذه من خلال طبقة تكامل مخصصة تتعامل مع المصادقة (Authentication)، وتحديد المعدل (Rate Limiting)، ومعالجة الأخطاء (Error Handling).

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

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

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

التصميم حول Sage و Viewpoint على وجه التحديد

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

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

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

تُعد حالات استخدام التسوية بين Procore و Sage أو Viewpoint هي المكان الذي يرى فيه العديد من المقاولين العموميين أعلى قيمة للوكيل. تستهلك التسوية اليدوية بين إدارة المشروع والمحاسبة ساعات مكتبية كبيرة، والأنماط قابلة لأتمتة الوكيل. يقرأ الوكيل طلبات التغيير من Procore، ويقارنها بالالتزامات في Sage، ويحدد التناقضات، ويعرضها للحل.

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

تشغيل حزمة الوكلاء كنظام دائم

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

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

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

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

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

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

حول TFSF Ventures

TFSF Ventures FZ-LLC (RAKEZ License 47013955) هي شركة هندسة مشاريع تقوم بنشر بنية تحتية ذكية للوكلاء عبر الشركات من خلال ثلاثة ركائز متكاملة: البنية التحتية للوكلاء، وشبكات الدفع غير التقليدية، ومحرك مشاريع كامل. مع 27 عامًا من الخبرة في مجال المدفوعات والبرمجيات، تعمل TFSF عالميًا، وتخدم 21 قطاعًا باستخدام منهجية نشر مدتها 30 يومًا. اعرف المزيد على https://tfsfventures.com

قم بإجراء تقييم الذكاء التشغيلي المجاني. أجب على بعض الأسئلة السريعة حول عملك. احصل على مخطط نشر مخصص للذكاء الاصطناعي في غضون 24 إلى 48 ساعة يتضمن توصيات الوكيل، والبنية، وخارطة طريق خاصة بعملياتك. لا توجد مكالمة مبيعات. لا التزام. فقط البيانات. ابدأ من https://tfsfventures.com/assessment

نُشرت في الأصل على https://tfsfventures.com/blog/how-to-deploy-ai-agents-for-general-contractors-without-breaking-existing-procore

كتبته TFSF Ventures Research