معماری مناقصه ساخت و ساز مبتنی بر هوش مصنوعی در Procore، Autodesk Construction Cloud و پشته‌های تخمین مستقل

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

این راهنمای روش‌شناسی، فرآیند طراحی گردش کار را تحت چارچوب صریح نحوه خودکارسازی مناقصه ساخت و ساز با هوش مصنوعی به عنوان یک قابلیت ساختاری و نه یک آزمایش ابزاری یک‌باره، توضیح می‌دهد. چارچوب اینجا توصیه‌ی یک محصول واحد نیست، بلکه یک رویکرد ساختاریافته برای معماری مناقصه مبتنی بر هوش مصنوعی در سه اکوسیستم غالب است که پیمانکاران در واقع از آن‌ها استفاده می‌کنند: Procore، Autodesk Construction Cloud، و دسته‌ی وسیع‌تر پشته‌های تخمین مستقل که حول ابزارهایی مانند Sage Estimating، HCSS HeavyBid، یا DESTINI Estimator ساخته شده‌اند. هر اکوسیستم نیازمند الگوهای یکپارچه‌سازی متفاوتی است، و گردش کاری که در یکی کار می‌کند، در دیگری اگر به سادگی منتقل شود، شکست خواهد خورد.

ترسیم مراحل چرخه عمر مناقصه قبل از انتخاب ابزارها

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

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

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

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

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

معماری در محیط‌های Procore

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

اولین تصمیم معماری این است که برداشت کجا قرار گیرد. Procore ابزار برداشت بومی ندارد، بنابراین پیمانکاران معمولاً آن را با Togal، Stack یا PlanSwift برای لایه‌ی تشخیص شرایط ترکیب می‌کنند. الگوی یکپارچه‌سازی که کار می‌کند این است که خروجی‌های برداشت به Procore Bid Management به عنوان مقادیر مرتبط با بسته‌های مناقصه خاص جریان یابند، که این اجازه می‌دهد تا بقیه‌ی گردش کار Procore به طور عادی پیش برود.

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

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

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

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

معماری در محیط‌های Autodesk Construction Cloud

Autodesk Construction Cloud یک چالش معماری متفاوت را ارائه می‌دهد. این پلتفرم داده‌های BIM را مستقیماً در گردش کار ساخت و ساز ادغام می‌کند، به این معنی که خط لوله مناقصه مبتنی بر هوش مصنوعی می‌تواند مقادیر را از مدل‌ها به جای برداشت PDF استخراج کند. این امر بخش جلویی گردش کار را به طور قابل توجهی تغییر می‌دهد و نیازمند الگوهای یکپارچه‌سازی متفاوتی نسبت به طراحی متمرکز بر Procore است.

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

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

تصمیم سوم این است که ارتباط با پیمانکاران فرعی و سطح‌بندی پیشنهاد چگونه ادغام شود. Autodesk Construction Cloud قابلیت‌های مدیریت مناقصه را از طریق BuildingConnected دارد، که به طور خاص برای لنگر انداختن بخش مناقصه پلتفرم خریداری شده است. گردش کارهایی که از BuildingConnected برای ITB و جمع‌آوری پیشنهاد استفاده می‌کنند، همچنان معمولاً از افزودن Beam یا ابزار مشابهی برای مرحله مقایسه و تحلیل بهره می‌برند.

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

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

معماری در پشته‌های تخمین مستقل

بخش قابل توجهی از پیمانکاران خارج از Procore و Autodesk Construction Cloud فعالیت می‌کنند و از پشته‌های تخمینی استفاده می‌کنند که حول Sage Estimating، HCSS HeavyBid، DESTINI Estimator یا B2W Estimate ساخته شده‌اند. این پشته‌های مستقل ملاحظات معماری خاص خود را دارند و اغلب بیشترین انعطاف‌پذیری را برای یکپارچه‌سازی هوش مصنوعی سفارشی ارائه می‌دهند.

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

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

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

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

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

طراحی لایه هوش مصنوعی در هر سه معماری

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

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

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

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

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

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

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

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

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

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

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

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

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

طراحی رسیدگی به استثنائات به عنوان یک ملاحظه درجه اول

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

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

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

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

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

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

اتصال گردش کار به عملیات پس از مناقصه

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

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

دومین ارتباط با حسابداری است. داده‌های مناقصه باید به لایه قرارداد و صورتحساب جریان یابد، که معمولاً به معنای ادغام با یک سیستم حسابداری ساخت و ساز مانند Sage 300 CRE، Viewpoint یا Foundation است. طراحی گردش کار باید دقیقاً مشخص کند که چه داده‌هایی از سیستم مناقصه به حسابداری منتقل می‌شود و چگونه تغییرات در طول اجرای پروژه بازگردانده می‌شوند.

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

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

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

ساخت قابلیت به عنوان یک سیستم پایدار

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

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

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

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

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

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

درباره TFSF Ventures

TFSF Ventures FZ-LLC (RAKEZ License 47013955) یک شرکت معماری سرمایه‌گذاری است که زیرساخت عامل هوشمند را از طریق سه ستون یکپارچه در سطح کسب‌وکارها مستقر می‌کند: زیرساخت عامل‌محور، مسیرهای پرداخت غیرسنتی، و یک موتور کامل سرمایه‌گذاری. TFSF با 27 سال تجربه در زمینه پرداخت‌ها و نرم‌افزار، در سطح جهانی فعالیت می‌کند و 21 صنعت را با روش استقرار 30 روزه خود پوشش می‌دهد. برای اطلاعات بیشتر به https://tfsfventures.com مراجعه کنید.

ارزیابی رایگان هوش عملیاتی را انجام دهید. به چند سوال سریع درباره کسب‌وکار خود پاسخ دهید. یک طرح اولیه استقرار هوش مصنوعی سفارشی شامل توصیه‌های عامل، معماری و نقشه راه خاص عملیات شما را ظرف 24 تا 48 ساعت دریافت کنید. بدون تماس فروش. بدون تعهد. فقط داده. شروع کنید در https://tfsfventures.com/assessment

Originally published at https://tfsfventures.com/blog/architecting-ai-powered-construction-bidding-across-procore-autodesk-construction

Written by TFSF Ventures Research