TFSF VENTURESCORPORATE INTELLIGENCE / UAE
زبانFA
FIELD NOTESthe framework
سابقه سازمانی

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

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

منتشرشده
26 آوریل 2026
نویسنده
TFSF VENTURES
زمان مطالعه
20 دقیقه
چرا اکثر پیمانکاران هنگام اتوماسیون مناقصه‌های ساختمانی با هوش مصنوعی حاشیه سود را از دست می‌دهند و چگونه جریان کاری را به درستی طراحی کنیم

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

الگوی از دست دادن حاشیه سود که هیچ کس در نمایش‌های فروش از آن صحبت نمی‌کند

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

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

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

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

چرا سرعت بدون انضباط، حاشیه سود را از بین می‌برد

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

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

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

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

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

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

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

دومین نقطه تصمیم‌گیری، انتخاب و ارزیابی پیمانکاران فرعی (Subcontractor Selection and Leveling) است. در اینجا، برآوردگر تصمیم می‌گیرد که کدام پیشنهادهای پیمانکاران فرعی را استفاده کند و چگونه آنها را با دامنه اصلی متعادل کند. یک خطای ارزیابی در اینجا، مانند پذیرش پیشنهاد پیمانکار فرعی که کار مهمی را که پیمانکار فرض کرده بود شامل می‌شود، مستثنی می‌کند، یکی از رایج‌ترین عوامل از بین برنده حاشیه سود در پروژه‌های ساختمانی تجاری است.

سومین نقطه تصمیم‌گیری، قیمت‌گذاری کارهای خوداجرا شده و شرایط عمومی (Pricing of Self-performed Work and General Conditions) است. در اینجا، پیمانکار تصمیم می‌گیرد که هزینه نیروی کار، تجهیزات و سربار خود در پروژه چقدر خواهد بود. خطاها در اینجا معمولاً از نظر دلاری کوچکتر از خطاهای دامنه یا ارزیابی هستند، اما در هر پروژه ترکیب می‌شوند و به آرامی سودآوری کلی پیمانکار را کاهش می‌دهند.

چهارمین نقطه تصمیم‌گیری، مبلغ نهایی، شامل سود، ذخیره و استراتژی مناقصه (Final Number, Including Markup, Contingency, and Bid Strategy) است. در اینجا، پیمانکار تصمیم می‌گیرد که آیا مبلغ مناقصه ریسک واقعی پروژه را منعکس می‌کند یا خیر. مبلغی که رقابتی است اما ذخیره کافی برای ریسک‌های خاص پروژه را شامل نمی‌شود، پروژه را می‌برد اما حاشیه سود را از دست می‌دهد.

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

چرا اکثر معماری‌های هوش مصنوعی در کیفیت تصمیم‌گیری شکست می‌خورند

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

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

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

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

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

معماری صحیح از داده‌های تاریخی آغاز می‌شود، نه برنامه‌ها

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

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

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

اولین مرحله از یک استقرار صحیح، تجمیع آن داده‌های تاریخی در یک فرم ساختاریافته است که به حقیقت مطلق (ground truth) برای هر تصمیم بعدی تبدیل می‌شود. پروژه‌های مشابه واقعاً چقدر هزینه داشتند؟ کدام پیمانکاران فرعی واقعاً با مبلغ پیشنهاد خود عمل کردند و کدام یک به طور معمول به تغییر سفارشات نیاز داشتند؟ بهره‌وری نیروی کار در این نوع کار در واقع در محل چه مقداری به دست آمد؟ اینها سوالاتی هستند که معماری باید بتواند قبل از اینکه هر بازبینی مناقصه با هوش مصنوعی بتواند خروجی معنی‌داری تولید کند، به آنها پاسخ دهد.

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

ساخت لایه پشتیبانی تصمیم

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

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

عامل ارزیابی پیمانکاران فرعی (subcontractor leveling agent) پیشنهادات پیمانکاران فرعی را در هر فرمتی دریافت کرده و آنها را در برابر قالب دامنه اصلی نرمال‌سازی می‌کند. این عامل موارد مستثنی شده و گنجانده شده را پرچم‌گذاری می‌کند، پیشنهادات پیمانکاران فرعی را که نسبت به قیمت‌گذاری تاریخی پیمانکار برای آن دامنه به طور غیرمعمول پایین یا بالا هستند، شناسایی می‌کند، و الگوهایی را در مورد پیمانکاران فرعی خاص که مربوط به این مناقصه هستند، مانند اینکه کدام پیمانکاران فرعی به طور معمول نیاز به تغییر سفارش دارند یا کدام یک در کارهای مشابه مشکلات قابلیت اطمینان برنامه‌زمانی دارند، مشخص می‌کند.

عامل قیمت‌گذاری کار خوداجرا (self-perform pricing agent) قیمت‌گذاری نیروی کار، تجهیزات و شرایط عمومی پیشنهادی را با مقادیر واقعی تاریخی پیمانکار در پروژه‌های مشابه مقایسه می‌کند. این عامل به برآوردگر نمی‌گوید که چه چیزی را شارژ کند. به جای آن، به برآوردگر می‌گوید که اعداد پیشنهادی او از واقعیت تاریخی چقدر فاصله دارند و از او می‌خواهد که قبل از پیشبرد مناقصه، این تفاوت را توجیه کند. این همان عملکرد بازبینی مناقصه هوش مصنوعی و امتیازدهی ریسک است که اکثر پلتفرم‌های بسته‌بندی شده ارائه نمی‌دهند زیرا به داده‌های تاریخی پیمانکار دسترسی ندارند.

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

چرا این معماری به استقرار سفارشی نیاز دارد

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

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

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

TFSF Ventures FZ-LLC (RAKEZ License 47013955) این معماری‌ها را به عنوان استقرار سفارشی به جای نرم‌افزار بسته‌بندی شده، با استفاده از یک متدولوژی استقرار 30 روزه که در 21 صنعت مختلف بهبود یافته است، می‌سازد. دلیل این امر این است که لایه پشتیبانی تصمیم تنها زمانی کارآمد است که بر اساس داده‌های تاریخی خاص پیمانکار، استانداردهای دامنه، شبکه پیمانکاران فرعی و الگوهای ریسک ساخته شود. یک پیمانکار عمومی تجاری با اندازه متوسط، حاشیه سود متوسط خود را در پروژه‌های بسته شده حدود سیصد و چهل واحد پایه (3.4%) در 9 ماه اول پس از استقرار، بهبود بخشید، که بزرگترین سهم آن از عامل قیمت‌گذاری کارهای خوداجرا (self-perform pricing agent) بود که الگوی مکرر برآورد کمتر از حد در کارهای بتنی آنها را شناسایی کرد.

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

چگونه استقرار را بدون ایجاد اختلال در میز مناقصه دنبال کنیم

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

توالی صحیح با عوامل فقط خواندنی (read-only agents) آغاز می‌شود که جریان کار مناقصه موجود را بدون تغییر آن مشاهده می‌کنند. عامل کامل بودن دامنه (scope completeness agent) و عامل قیمت‌گذاری کارهای خوداجرا (self-perform pricing agent) هر دو می‌توانند موازی با جریان کار دستی اجرا شوند و امتیازات ریسک و خروجی‌های چالش‌برانگیز را تولید کنند که برآوردگران می‌توانند آنها را بررسی کنند اما ملزم به عمل بر اساس آنها نیستند. این کار اعتماد به عوامل را قبل از اینکه در مسیر حیاتی مناقصه قرار گیرند، ایجاد می‌کند.

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

مرحله سوم، عامل استراتژی مناقصه (bid strategy agent) را فعال می‌کند، که قابل مشاهده‌ترین تغییر است زیرا یک چالش ساختاریافته را در بررسی نهایی مناقصه وارد می‌کند. این مرحله نیازمند حمایت اجرایی است زیرا نحوه تعامل برآوردگر ارشد و تیم اجرایی با هر مناقصه را تغییر می‌دهد و تصمیماتی را که قبلاً به صورت غیررسمی گرفته می‌شدند، آشکار می‌کند.

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

موفقیت واقعی چگونه به نظر می‌رسد

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

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

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

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

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

تصمیمی که پیمانکاران واقعاً باید بگیرند

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

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

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

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

درباره 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/why-most-contractors-lose-margin-when-they-automate-construction-bidding-with-ai-and

Written by TFSF Ventures Research