چگونه عوامل هوش مصنوعی را برای پیمانکاران عمومی بدون تغییر فرآیندهای موجود Procore، Sage یا Viewpoint که مورد اعتماد هستند، به کار بگیریم

اکثر پیمانکاران عمومی که به استقرار عوامل نزدیک می‌شوند، به یک دیوار برخورد می‌کنند. تیم عملیاتی از Procore برای مدیریت پروژه، Sage یا Viewpoint برای حسابداری و تعداد معدودی ابزارهای قدیمی که به اندازه کافی خوب کار می‌کنند و هیچ‌کس نمی‌خواهد آنها را مختل کند، استفاده می‌کنند. سپس یک فروشنده با یک پلتفرم هوش مصنوعی درخشان ظاهر می‌شود که از تیم عملیاتی می‌خواهد هر گردش کار را تغییر دهد، به یک سیستم جدید وارد شود و ابزارهایی را که واقعاً استفاده می‌کند، کنار بگذارد. استقرار شکست می‌خورد، نه به این دلیل که هوش مصنوعی بد است، بلکه به این دلیل که رویکرد یکپارچه‌سازی اشتباه است.

این راهنمای روش‌شناسی چگونگی استقرار عوامل هوش مصنوعی برای پیمانکاران عمومی را بدون شکستن سیستم‌های موجود که مورد اعتماد تیم عملیاتی هستند، توضیح می‌دهد. تمرکز در اینجا جایگزینی Procore، Sage یا Viewpoint با چیز جدیدی نیست. تمرکز بر روی افزودن هوش عوامل بر روی آن سیستم‌ها به گونه‌ای است که تیم عملیاتی آن را به عنوان یک بهبود آرام و نه یک اختلال تجربه کند. اگر به درستی انجام شود، عوامل به زیرساخت نامرئی تبدیل می‌شوند که ابزارهای موجود را بهتر کار می‌کنند. اگر اشتباه انجام شود، عوامل به مجوزهای رها شده و آسیب‌های سیاسی تبدیل می‌شوند که سال‌ها پذیرش عوامل را به تأخیر می‌اندازد.

چرا اعتماد به سیستم موجود محدودیتی است که اهمیت دارد

قبل از پرداختن به روش‌شناسی فنی، محدودیت اعتماد به تیم عملیاتی مستلزم بررسی صریح است، زیرا بیشتر استقرارهای ناموفق عوامل به کم‌اهمیت جلوه دادن آن بازمی‌گردد. تیم عملیاتی سال‌ها وقت صرف یادگیری Procore، ایجاد عادت‌های گزارش روزانه در Sage و ادغام حقوق و دستمزدهای Viewpoint در نحوه اجرای واقعی کارها کرده است. این آشنایی انباشته فقط یک ترجیح نیست. این سرمایه عملیاتی است که سال‌ها طول کشید تا ساخته شود.

از تیم عملیاتی خواستن برای کنار گذاشتن آن سیستم‌ها به نفع یک پلتفرم هوش مصنوعی که وعده گردش کارهای بهتر را می‌دهد، به معنای درخواست از آنها برای کنار گذاشتن سرمایه عملیاتی واقعی به امید سرمایه آتی است. حتی زمانی که پلتفرم جدید واقعاً بهتر است، هزینه انتقال معمولاً از مزایای آن بیشتر است، و تیم عملیاتی به درستی مقاومت می‌کند. استقرارهایی که موفق می‌شوند، این انتقال را درخواست نمی‌کنند. آنها سیستم‌های موجود تیم عملیاتی را حفظ کرده و هوش عوامل را در اطراف آنها اضافه می‌کنند.

این محدودیت همه چیز را در مورد چگونگی طراحی استقرار عامل هوش مصنوعی برای پیمانکاران عمومی شکل می‌دهد. عوامل باید در کنار Procore، Sage و Viewpoint زندگی کنند، نه اینکه با آنها رقابت کنند. عوامل باید از طریق APIها از این سیستم‌ها بخوانند و در آنها بنویسند، نه اینکه از تیم عملیاتی بخواهند که به یک پورتال جدید وارد شوند. خروجی‌های عامل باید در ابزارهایی که تیم عملیاتی از قبل استفاده می‌کند، ظاهر شوند، نه در یک سیستم موازی که تیم عملیاتی باید به خاطر داشته باشد آن را بررسی کند.

پیمانکاران عمومی که این محدودیت را درونی می‌کنند، استقرار عوامل خود را بسیار متفاوت از پیمانکاران عمومی که این کار را نمی‌کنند، طراحی می‌کنند. نسخه درونی شده، سیستم‌های موجود را به عنوان زیرساختی می‌داند که عوامل آن را گسترش می‌دهند. نسخه غیردرونی شده، سیستم‌های موجود را به عنوان قدیمی می‌داند که عوامل در نهایت جایگزین خواهند کرد. نسخه اول موفق می‌شود. نسخه دوم شکست می‌خورد.

بقیه این روش‌شناسی فرض می‌کند که پیمانکار عمومی محدودیت اعتماد به تیم عملیاتی را درونی کرده و متعهد به استقرار عواملی است که در کنار Procore، Sage و Viewpoint کار می‌کنند، نه اینکه آنها را جایگزین کنند.

گام اول: ترسیم نقشه چشم‌انداز سیستم موجود

اولین گام روش‌شناسی، تولید یک نقشه صادقانه از چشم‌انداز سیستم موجود است. اکثر پیمانکاران عمومی چشم‌انداز سیستمی پیچیده‌تری نسبت به آنچه رهبری تصور می‌کند، دارند، با مدیریت پروژه که از طریق Procore انجام می‌شود، اما همچنین از طریق ماژول‌های خاص Procore که برخی تیم‌ها از آنها استفاده می‌کنند و برخی دیگر نه، حسابداری که از طریق Sage یا Viewpoint انجام می‌شود اما با فرآیندهای دستی قابل توجهی در اطراف آن، و مجموعه‌ای طولانی از ابزارهای خاص پروژه یا خاص حرفه که شکاف‌ها را در سیستم‌های اصلی پر می‌کنند.

تمرین نقشه‌برداری باید یک تصویر واضح از اینکه کدام سیستم منبع حقیقت برای هر عنصر داده را در خود نگه می‌دارد، کدام گردش کارها واقعاً در داخل هر سیستم اجرا می‌شوند، و کدام گردش کارها خارج از سیستم‌ها از طریق ایمیل، صفحات گسترده یا فرآیندهای مستند نشده اتفاق می‌افتد، ارائه دهد. اکثر پیمانکاران عمومی در طول این تمرین کشف می‌کنند که کار عملیاتی قابل توجهی خارج از سیستم‌های اعلام شده آنها اتفاق می‌افتد، که دقیقاً همان جایی است که استقرار عوامل باید روی آن تمرکز کند.

نقشه‌برداری همچنین باید مشخص کند که کدام یکپارچگی‌ها از قبل بین سیستم‌ها وجود دارند و کدام یکپارچگی‌ها مورد نیاز هستند اما وجود ندارند. یکپارچگی‌های Procore به Sage وجود دارند اما کیفیت آنها در پیاده‌سازی‌های مختلف متفاوت است. یکپارچگی‌های Procore به Viewpoint نیز تغییرپذیری مشابهی دارند. استقرار عامل معمولاً نیاز به استفاده از یکپارچگی‌های موجود و تکمیل آنها در صورت وجود شکاف‌ها دارد.

خروجی نقشه‌برداری، یک سند چشم‌انداز سیستم است که به پایه معماری برای استقرار عامل تبدیل می‌شود. بدون این سند، استقرار بر اساس فرضیاتی در مورد نحوه عملکرد سیستم‌ها پیش می‌رود که اغلب اشتباه از آب در می‌آیند، که منجر به استقرارهایی می‌شود که در نقاط یکپارچگی که تیم پیش‌بینی نکرده بود، شکست می‌خورند.

تمرین نقشه‌برداری معمولاً یک تا دو هفته کار اختصاصی طول می‌کشد و باید شامل نمایندگانی از عملیات، مدیریت پروژه و پشته فناوری باشد. نادیده گرفتن یا کوتاه‌کردن این مرحله یکی از شایع‌ترین پیش‌بینی‌کننده‌های شکست استقرار است.

گام دوم: شناسایی گردش کارهای هماهنگی که ارزش خودکارسازی را دارند

گام دوم، شناسایی این است که کدام گردش کارهای هماهنگی ارزش خودکارسازی با عوامل را دارند و کدام‌ها باید در سیستم‌های موجود بدون تغییر باقی بمانند. همه گردش کارها از خودکارسازی عامل سود نمی‌برند، و انضباط انتخاب دقیق، چیزی است که استقرارهای متمرکز را که نتایج تولید می‌کنند، از استقرارهای گسترده‌ای که منابع را بدون ارائه ارزش مصرف می‌کنند، متمایز می‌کند.

معیارهای انتخاب گردش کارها شامل حجم، تکرارپذیری و دردسر فعلی است. گردش کارهایی که به طور مکرر در پروژه‌ها اتفاق می‌افتند، از الگوهای ثابتی پیروی می‌کنند که برای خودکارسازی مناسب هستند، و در حال حاضر ساعت‌های قابل توجهی از مدیریت پروژه را مصرف می‌کنند، کاندیداهای طبیعی برای استقرار عامل هستند. گردش کارهایی که نادر، بسیار متغیر یا از قبل کارآمد هستند، معمولاً ارزش تلاش برای استقرار را ندارند.

برای اکثر پیمانکاران عمومی، گردش کارهایی که این معیارها را برآورده می‌کنند شامل دسته‌بندی و مسیردهی RFI، پردازش و مسیردهی زیرمجموعه‌ها، تولید گزارش روزانه، گردش کار تغییر سفارش، هماهنگی خرید با پیمانکاران فرعی، و تطبیق دفتر پشتیبان بین سیستم‌های مدیریت پروژه و حسابداری است. این گردش کارها حجم بالا، از الگوهای قابل پیش‌بینی پیروی می‌کنند و ساعت‌های قابل توجهی از مدیریت پروژه را مصرف می‌کنند.

گردش کارهایی که معمولاً این معیارها را برآورده نمی‌کنند شامل تصمیمات استراتژیک پروژه، مدیریت روابط با مالک، ارزیابی‌های پیچیده ریسک، و وظایف هماهنگی یکباره هستند. این گردش کارها از قضاوت انسانی بهره می‌برند و به ندرت تکرارپذیری لازم را برای خودکارسازی عامل با صرفه اقتصادی دارند.

خروجی انتخاب، یک لیست اولویت‌بندی شده از گردش کارهای هدف برای استقرار عامل است، با محدودیت الزام‌آور که ابتدا به آن پرداخته می‌شود. تلاش برای خودکارسازی همه چیز به یکباره معمولاً منجر به یک استقرار گسترده می‌شود که در هیچ گردش کار خاصی ارزش قابل مشاهده‌ای ارائه نمی‌دهد، در حالی که استقرارهای متمرکز که بهبودهای قابل مشاهده‌ای را در گردش کارهای اولویت‌دار تولید می‌کنند، اعتماد سازمانی را ایجاد می‌کنند که از گسترش بیشتر حمایت می‌کند.

گام سوم: طراحی عواملی که از سیستم‌های موجود می‌خوانند و در آنها می‌نویسند

گام سوم، طراحی خود عوامل با محدودیت صریح است که آنها به جای ایجاد انبارهای داده موازی، از سیستم‌های موجود می‌خوانند و در آنها می‌نویسند. این انضباط طراحی چیزی است که به عوامل اجازه می‌دهد تا با Procore، Sage و Viewpoint یکپارچه شوند بدون اینکه تیم عملیاتی را مجبور به تغییر گردش کارهای خود کنند.

الگوی خواندن از به این معنی است که عامل داده‌های عملیاتی خود را از سیستم‌های موجود از طریق APIهای مستند شده می‌گیرد. عوامل RFI، RFIs را از Procore می‌خوانند. عوامل تغییر سفارش، داده‌های تغییر سفارش را از Procore و Sage می‌خوانند. عوامل گزارش روزانه، داده‌های پروژه را از Procore و داده‌های میدانی را از هر ابزار ثبت داده‌ای که تیم استفاده می‌کند، می‌خوانند. عامل یک کپی جداگانه از این داده‌ها را نگهداری نمی‌کند، زیرا انجام این کار مشکلات همگام‌سازی ایجاد می‌کند و وضعیت منبع-حقیقت سیستم‌های موجود را تضعیف می‌کند.

الگوی نوشتن در به این معنی است که عامل خروجی‌های خود را به سیستم‌های موجود بازمی‌گرداند، جایی که تیم عملیاتی واقعاً آنها را خواهد دید. عوامل RFI، پاسخ‌های پیش‌نویس را به عنوان نظرات یا تکالیف Procore ارسال می‌کنند. عوامل زیرمجموعه، سوابق زیرمجموعه Procore را به‌روزرسانی می‌کنند. عوامل گزارش روزانه، گزارش‌های روزانه Procore را ایجاد یا تکمیل می‌کنند. خروجی عامل در ابزار موجود تیم عملیاتی ظاهر می‌شود، نه در یک پلتفرم جدید که تیم عملیاتی باید آن را یاد بگیرد.

معماری یکپارچگی برای الگوهای خواندن از و نوشتن در معمولاً از APIهای پلتفرم موجود از طریق یک لایه یکپارچگی سفارشی استفاده می‌کند. Procore، Sage و Viewpoint همگی APIهایی را ارائه می‌دهند که از این الگوی یکپارچگی پشتیبانی می‌کنند، و استقرار عامل از این APIها استفاده می‌کند، نه اینکه سعی کند آنها را دور بزند.

لایه هوش عامل بین عملیات خواندن و نوشتن قرار می‌گیرد، داده‌های گرفته شده از سیستم‌های موجود را پردازش می‌کند و خروجی‌هایی را تولید می‌کند که دوباره نوشته می‌شوند. این لایه هوش جایی است که استدلال مبتنی بر LLM، تخصص حوزه ساخت و ساز، و منطق گردش کار در آن قرار دارند. لایه هوش، ارزش افزوده است، در حالی که الگوهای خواندن و نوشتن زیرساختی هستند که اجازه می‌دهند این ارزش افزوده به تیم عملیاتی برسد.

این انضباط طراحی عواملی را تولید می‌کند که تیم عملیاتی آنها را به عنوان بهبودهای آرام در گردش کارهای موجود خود تجربه می‌کند، نه به عنوان سیستم‌های جدیدی که نیاز به توجه دارند. پاسخ‌های RFI سریع‌تر می‌رسند. زیرمجموعه‌ها با دقت بیشتری مسیردهی می‌شوند. تغییر سفارش‌ها با هماهنگی دستی کمتر از طریق گردش کار حرکت می‌کنند. تیم عملیاتی بهبودها را بدون نیاز به یادگیری چیز جدیدی متوجه می‌شود.

گام چهارم: رسیدگی به خطا را از روز اول در معماری بگنجانید

گام چهارم، گنجاندن رسیدگی به خطا در معماری عامل از روز اول است، نه به عنوان یک فکر بعدی. رسیدگی به خطا جایی است که بسیاری از استقرار عوامل در تولید شکست می‌خورند، زیرا مسیر خوشایندی که در دموها کار می‌کند، در مواجهه با کارهای هماهنگی واقعی دوام نمی‌آورد.

اصل اول طراحی رسیدگی به خطا، شناسایی صریح است. هر عامل به یک مکانیسم شناسایی صریح برای شرایطی نیاز دارد که خودکارسازی آن نباید بدون بازبینی انسانی ادامه یابد. عوامل RFI باید RFIs را که شامل هزینه یا تأثیر قابل توجهی بر برنامه هستند، شناسایی کرده و آنها را به بازبینی انسانی هدایت کنند. عوامل زیرمجموعه باید زیرمجموعه‌هایی را که خارج از الگوهای استاندارد هستند، شناسایی کرده و آنها را بالا ببرند. عوامل تغییر سفارش باید تغییر سفارش‌هایی را که شامل دامنه غیرمعمول هستند، شناسایی کرده و آنها را برای توجه مدیر اجرایی پروژه برجسته کنند.

اصل دوم، تنزل نرم است. هنگامی که یک استثنا شناسایی می‌شود، گردش کار نباید به سادگی از کار بیفتد. طراحی باید مشخص کند که در هر سناریوی استثنا چه اتفاقی می‌افتد، از جمله اینکه کدام مراحل به طور خودکار ادامه می‌یابند، کدام مراحل به بازبینی انسانی با چه زمینه‌ای ارتقا می‌یابند، و کدام مراحل به حالت پایدار برمی‌گردند.

اصل سوم، مسیرهای صعود انسانی است. برخی از استثناها را نمی‌توان به طور خودکار مدیریت کرد و باید با زمینه مناسب به فرد مناسب منتقل شوند. طراحی صعود باید دقیقاً بیان کند که بازبین انسانی چه چیزی را می‌بیند، چه تصمیمی باید بگیرد، و چگونه تصمیم او به گردش کار بازمی‌گردد. بدون این طراحی، صعودها یا گم می‌شوند یا با زمینه ناکافی برای اقدام مؤثر می‌رسند.

اصل چهارم، ثبت و یادگیری استثناها است. هر استثنایی که با آن روبرو می‌شویم، اطلاعاتی است که می‌تواند عامل را در طول زمان بهبود بخشد. معماری باید الگوهای استثنا، علل ریشه‌ای و راه‌حل‌ها را به گونه‌ای ثبت کند که از بهبود مستمر منطق عامل حمایت کند. بدون این حلقه یادگیری، عوامل بارها و بارها با همان استثناها روبرو می‌شوند بدون اینکه در مدیریت آنها بهتر شوند.

اصل پنجم، آزمایش است. رسیدگی به خطا باید به طور صریح با سناریوهای استثنای مصنوعی قبل از ورود به تولید آزمایش شود. استقرارهایی که در تولید شکست می‌خورند، معمولاً آنهایی هستند که در موارد تمیز به زیبایی کار می‌کردند اما در موارد پیچیده فروپاشیدند، که دقیقاً برعکس چیزی است که زیرساخت عامل تولیدی باید انجام دهد.

گام پنجم: راه‌اندازی از طریق آزمایش‌های میدانی مرحله‌ای

گام پنجم، راه‌اندازی استقرار عامل از طریق آزمایش‌های میدانی مرحله‌ای است، نه به عنوان یک راه‌اندازی در سطح شرکت. آزمایش‌های مرحله‌ای به تیم استقرار اجازه می‌دهد تا تأیید کند که عوامل طبق طراحی در شرایط تولید کار می‌کنند، بازخورد تیمی را جمع‌آوری کند که منطق عامل را بهبود می‌بخشد، و اعتماد سازمانی را ایجاد کند که از راه‌اندازی گسترده‌تر حمایت می‌کند.

فاز اول معمولاً شامل یک تیم پروژه واحد است که یک نوع عامل را اجرا می‌کند. مدیریت RFI اغلب نقطه شروع طبیعی است، زیرا RFIs به طور مکرر اتفاق می‌افتند، از الگوهای قابل پیش‌بینی پیروی می‌کنند، و هنگام سرعت بخشیدن به چرخه پاسخ، بهبود قابل مشاهده‌ای ایجاد می‌کنند. تیم پروژه آزمایشی با تیم استقرار همکاری نزدیک دارد تا رفتار عامل را تأیید کند و مسائل را مشخص کند.

فاز دوم معمولاً شامل گسترش به چندین تیم پروژه است که نوع عامل تأیید شده را اجرا می‌کنند. این گسترش تأیید می‌کند که عامل در انواع پروژه‌ها، ترکیب تیم‌ها، و تغییرات عملیاتی کار می‌کند. فاز گسترش اغلب تغییراتی را در نحوه استفاده تیم‌های مختلف از سیستم‌های زیربنایی مشخص می‌کند، که پیکربندی اضافی یا تنظیمات منطق عامل را آگاهی می‌دهد.

فاز سوم شامل افزودن انواع عوامل اضافی به تیم‌های پروژه آزمایشی است. عوامل زیرمجموعه، عوامل تغییر سفارش، و عوامل گزارش روزانه معمولاً عوامل RFI را در توالی استقرار دنبال می‌کنند، و بر اعتماد عملیاتی و معماری یکپارچگی که با اولین نوع عامل ایجاد شده است، بنا می‌شوند. هر عامل اضافی، تلاش حاشیه‌ای عوامل بعدی را کاهش می‌دهد، زیرا معماری از قبل وجود دارد.

فاز چهارم شامل راه‌اندازی در سطح شرکت از پشته عامل تأیید شده است. در این مرحله، عوامل در انواع پروژه‌ها و تیم‌های مختلف تأیید شده‌اند، تیم عملیاتی با نحوه عملکرد عوامل راحت شده است، و معیارهای عملیاتی برای اندازه‌گیری عملکرد مداوم وجود دارد. راه‌اندازی در سطح شرکت به یک فعالیت نسبتاً کم‌خطر تبدیل می‌شود، نه یک جهش ایمان.

راه‌اندازی مرحله‌ای معمولاً سه تا شش ماه از آزمایش اولیه تا استقرار در سطح شرکت طول می‌کشد، بسته به اندازه، سبد پروژه و ظرفیت سازمانی پیمانکار عمومی برای تغییر. فشرده‌سازی تهاجمی این جدول زمانی اغلب منجر به شکست‌های استقراری می‌شود که راه‌اندازی مرحله‌ای به طور خاص برای جلوگیری از آنها طراحی شده است.

چرا معماری مهمتر از انتخاب پلتفرم است

پیمانکاران عمومی که بدون طراحی اولیه رویکرد استقرار، به دنبال ویژگی‌های پلتفرم می‌روند، معمولاً با مشکلات یکسانی روبرو می‌شوند، بدون توجه به اینکه کدام پلتفرم را انتخاب می‌کنند. پلتفرم بخشی از گردش کار را مدیریت می‌کند، اما یکپارچگی با سیستم‌های موجود شکننده است. هوش عامل در موارد استاندارد کار می‌کند اما در موارد حاشیه‌ای شکست می‌خورد. تیم عملیاتی با پذیرش مقاومت می‌کند، زیرا پلتفرم نیاز به تغییرات گردش کار دارد که آنها نمی‌خواهند انجام دهند.

رویکرد معماری-اول این پویایی را معکوس می‌کند. با درونی کردن محدودیت اعتماد به تیم عملیاتی، نقشه‌برداری چشم‌انداز سیستم موجود، شناسایی گردش کارهای اولویت‌دار، طراحی عواملی که از سیستم‌های موجود می‌خوانند و در آنها می‌نویسند، ساخت رسیدگی به خطا از روز اول، و راه‌اندازی از طریق خلبانان میدانی مرحله‌ای، پیمانکاران عمومی با استقرارهایی روبرو می‌شوند که تیم عملیاتی آنها را به عنوان بهبودهای آرام و نه اختلالات تجربه می‌کند.

این امر به ویژه برای پیمانکاران عمومی که با سیستم‌های عملیاتی بالغ کار می‌کنند، مهم است. فروشندگان اصلی پلتفرم محصولات خود را برای موارد عمومی طراحی می‌کنند، که از دیدگاه بازار منطقی است اما اغلب برای پیمانکاران عمومی که سرمایه‌گذاری‌های سیستمی موجود و الگوهای عملیاتی آنها نیاز به سفارشی‌سازی عمیق‌تری دارد، ناکافی است. استقرارهای معماری-اول به پیمانکاران عمومی در این موقعیت‌ها اجازه می‌دهد تا زیرساخت عامل را بسازند که با واقعیت آنها مطابقت دارد، نه اینکه واقعیت آنها را مجبور به مطابقت با یک پلتفرم کند.

رویکرد TFSF Ventures این گرایش معماری-اول را منعکس می‌کند. ارزیابی عملیاتی 19 سؤالی که هر تعامل را آغاز می‌کند، چشم‌انداز سیستمی خاص و گردش کارهای هماهنگی پیمانکار عمومی را قبل از هر توصیه فناوری ترسیم می‌کند، و اطمینان می‌دهد که زیرساخت عامل حاصل، واقعیت عملیاتی واقعی را در مقابل بهترین شیوه‌های عمومی مورد بررسی قرار می‌دهد.

روش‌شناسی استقرار 30 روزه به این معنی است که طراحی معماری و عوامل تولیدی در عرض چهار هفته عملیاتی می‌شوند، نه چرخه‌های چند فصلی معمول یکپارچگی سیستم‌های سنتی. معماری رسیدگی به خطا، که در قلب هر استقرار TFSF Ventures FZ-LLC قرار دارد، چیزی است که زیرساخت عامل درجه تولیدی را از نمایش‌های درجه نمونه اولیه جدا می‌کند، با نتایج مستند شده که کاهش سی تا پنجاه درصدی ساعت‌های مدیریت پروژه در هر پروژه و توانایی اجرای دو تا سه پروژه همزمان اضافی در هر مدیر پروژه را نشان می‌دهد.

قیمت‌گذاری عمق کار را منعکس می‌کند. سرمایه‌گذاری‌های استقرار از ده‌ها هزار دلار برای استقرارهای متمرکز با تعداد کمی عامل شروع می‌شود و با تعداد عوامل، پیچیدگی یکپارچگی و دامنه عملیاتی مقیاس‌بندی می‌شود. تمام استقرارها شامل هزینه اضافی زیرساخت هوش مصنوعی تقریباً 400 تا 500 دلار در ماه از Pulse AI، با قیمت تمام شده، بدون هیچ گونه نشانه‌گذاری. مشتریان کد منبع را تحت یک مجوز دائمی مالک هستند، که از قفل شدن پلتفرم و هزینه‌های مداوم به ازای هر صندلی جلوگیری می‌کند. پیمانکاران عمومی که بررسی‌های TFSF Ventures را ارزیابی می‌کنند و به دنبال تأیید قانونی بودن TFSF Ventures هستند، می‌توانند ثبت RAZEK License 47013955 شرکت و سوابق استقرار 21 بخش منتشر شده را تأیید کنند.

طراحی خاص پیرامون Procore

استقرارهای پیمانکار عمومی متمرکز بر Procore دارای الگوهای معماری خاصی هستند که ارزش بررسی صریح را دارند. Procore پلتفرم غالب مدیریت پروژه در بازار پیمانکاری عمومی تجاری است، و اکثر استقرارهای عامل در این فضا شامل یکپارچگی Procore به عنوان نقطه تماس اصلی با تیم عملیاتی هستند.

API Procore از الگوهای خواندن از و نوشتن در که در بالا توضیح داده شد پشتیبانی می‌کند، با نقاط پایانی مستند شده برای RFIs، زیرمجموعه‌ها، سفارش‌های تغییر، گزارش‌های روزانه، و سایر گردش کارهای هماهنگی که عوامل معمولاً به آنها می‌پردازند. معماری یکپارچگی برای استقرارهای متمرکز بر Procore از این APIها از طریق یک لایه یکپارچگی سفارشی استفاده می‌کند که احراز هویت، محدودیت نرخ و رسیدگی به خطا را مدیریت می‌کند.

مدل داده Procore دارای ویژگی‌های خاصی است که استقرار عوامل باید به آنها احترام بگذارد. داده‌های پروژه در سلسله مراتب شرکت و پروژه زندگی می‌کنند، با مجوزهایی که در نقش‌های کاربری متفاوت است. یکپارچگی عامل باید با مجوزهای مناسب کار کند و به جداسازی داده‌ای که Procore بین پروژه‌ها اعمال می‌کند احترام بگذارد.

رابط کاربری Procore جایی است که کارکنان میدانی خروجی‌های عامل را خواهند دید، به این معنی که طراحی عامل باید نحوه نمایش خروجی‌ها در Procore را در نظر بگیرد. پاسخ‌های RFI تولید شده توسط عوامل باید به عنوان نظرات طبیعی Procore ظاهر شوند، نه به عنوان محتوای آشکارا تولید شده توسط هوش مصنوعی. تصمیمات مسیردهی زیرمجموعه باید به عنوان اقدامات گردش کار استاندارد Procore ظاهر شوند. تیم عملیاتی باید خروجی‌های عامل را به عنوان کار بهتر Procore تجربه کند، نه به عنوان Procore که توسط یک سیستم خارجی تقویت شده است.

رسیدگی به خطای خاص Procore معمولاً بر روی مواردی تمرکز دارد که پاسخ‌های API نشان‌دهنده شرایط پروژه غیرعادی هستند، جایی که منطق گردش کار با الگوهای داده‌ای روبرو می‌شود که خارج از آموزش عامل هستند، یا جایی که امتیاز اعتماد عامل کمتر از آستانه اقدام خودمختار است. این شرایط استثنایی باید به بازبین‌های انسانی مناسب در داخل گردش کار Procore هدایت شوند، نه اینکه خارج از پلتفرم بالا بروند.

طراحی خاص پیرامون Sage و Viewpoint

استقرار Sage و Viewpoint لایه سیستم مالی را به معماری عامل اضافه می‌کند، با الگوهای خاص برای گردش کار تغییر سفارش، پردازش درخواست پرداخت و تطبیق دفتر پشتیبان. استقرار عامل برای این سیستم‌ها به معماری دقیق‌تری نسبت به استقرارهای فقط Procore نیاز دارد، زیرا داده‌های مالی الزامات یکپارچگی بالاتری دارند.

APIهای Sage و Viewpoint معمولاً نسبت به API 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 شروع کنید.

Originally published at https://tfsfventures.com/blog/how-to-deploy-ai-agents-for-general-contractors-without-breaking-existing-procore

Written by TFSF Ventures Research