هندسة عطاءات البناء المدعومة بالذكاء الاصطناعي عبر Procore وAutodesk Construction Cloud ومكدسات التقدير المستقلة

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

يرشد دليل المنهجية هذا خلال عملية تصميم سير العمل هذه تحت الإطار الصريح لكيفية أتمتة تقديم العطاءات للمشاريع الإنشائية باستخدام الذكاء الاصطناعي كقدرة هيكلية بدلاً من تجربة أدوات لمرة واحدة. الإطار هنا ليس توصية بمنتج واحد ولكنه نهج منظم لتصميم تقديم العطاءات المدعومة بالذكاء الاصطناعي عبر الأنظمة البيئية الثلاثة السائدة التي تعمل بها الشركات المتعاقدة بالفعل: Procore، Autodesk Construction Cloud، والفئة الأوسع من مكدسات التقدير المستقلة المبنية حول أدوات مثل Sage Estimating، HCSS HeavyBid، أو DESTINI Estimator. يتطلب كل نظام بيئي أنماط تكامل مختلفة، وسيفشل سير العمل الذي يعمل في أحدها في الآخر إذا تم نقله ببساطة.

ارسم خريطة لدورة حياة العطاء قبل اختيار الأدوات

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

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

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

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

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

تصميم في بيئات Procore

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

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

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

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

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

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

markdown

تصميم البنية عبر بيئات Autodesk Construction Cloud

تمثل Autodesk Construction Cloud تحديًا معماريًا مختلفًا. تدمج المنصة بيانات نمذجة معلومات البناء (BIM) مباشرةً في سير العمل الإنشائي، مما يعني أن مسار عطاءات الذكاء الاصطناعي يمكنه سحب الكميات من النماذج بدلاً من سحبها من رسومات PDF. يغير هذا الواجهة الأمامية لسير العمل بشكل كبير ويتطلب أنماط تكامل مختلفة عن التصميم المتمحور حول Procore.

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

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

القرار الثالث هو كيفية تكامل التواصل مع المقاولين من الباطن وتسوية العطاءات. تحتوي Autodesk Construction Cloud على إمكانيات إدارة العطاءات من خلال BuildingConnected، التي استحوذت عليها خصيصًا لترسيخ جانب العطاءات في المنصة. لا تزال سير العمل التي تعمل على BuildingConnected لطلبات تقديم العطاءات وجمع العطاءات تستفيد عادةً من إضافة Beam أو أداة تسوية مماثلة لمرحلة المقارنة والتحليل.

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

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

تصميم البنية عبر مكدسات التقدير المستقلة

تعمل مجموعة فرعية مهمة من المقاولين خارج Procore وAutodesk Construction Cloud، حيث يديرون مكدسات تقدير مبنية حول Sage Estimating أو HCSS HeavyBid أو DESTINI Estimator أو B2W Estimate. تقدم هذه المكدسات المستقلة اعتباراتها المعمارية الخاصة وغالبًا ما توفر أكبر قدر من المرونة لتكامل الذكاء الاصطناعي المخصص.

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

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

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

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

ميزة النهج المستقل هي أن المقاولين ليسوا مقيدين بقيود بائع منصة رئيسي. العيب هو أن عبء التكامل أعلى بكثير، وتتطلب بنية سير العمل تصميمًا أكثر تعمدًا لتجنب تجزئة البيانات التي تعاني منها العديد من المكدَّسات المستقلة.

{ "title": "اختيار مسار الذكاء الاصطناعي الخاص بك: لماذا يأتي التصميم المعماري أولاً", "excerpt": "تحديد طبقة الذكاء الاصطناعي عبر جميع البنى الثلاثة. لماذا يهم التصميم المعماري أكثر من اختيار المنصة." , "author": "TFSF Ventures Research", "published_at": "2024-06-25T10:00:00Z", "tags": ["الذكاء الاصطناعي", "البناء", "التكنولوجيا", "الاستراتيجية", "العمليات"], "image": "https://tfsfventures.com/blog/ai-path-architecture-first.webp", "body": "## تصميم طبقة الذكاء الاصطناعي عبر جميع البنى الثلاثة\n\nبغض النظر عن النظام البيئي الذي يعمل فيه المقاول، فإن طبقة الذكاء الاصطناعي في سير عمل تقديم العطاءات تؤدي تقريبًا نفس مجموعة الوظائف، مع تفاصيل تنفيذ خاصة بالمنصة. يساعد فهم هذه الوظائف بشكل مجرد على فصل تصميم سير العمل عن اختيار المنصة، وهو الترتيب الصحيح للعمليات للنشر المستدام.\n\nالوظيفة الأولى للذكاء الاصطناعي هي اكتشاف الظروف من الخطط. وهذا هو عمل قراءة ملفات PDF أو النماذج وتحديد المساحات والتجميعات والعناصر القابلة للقياس الكمي. التكنولوجيا هنا ناضجة وموثوقة في معظم أنواع المشاريع التجارية والسكنية. التحدي في التكامل هو إدخال الظروف المكتشفة في مكتبة التجميع المحددة للمقاول ومنطق التسعير.\n\nالوظيفة الثانية للذكاء الاصتياعي هي تحديد الأسعار التاريخية. وهذا هو عمل مقارنة الأسعار الحالية بعروض المقاول المماثلة السابقة ووضع علامة على العناصر التي تقع خارج المعايير التاريخية. تتطلب التكنولوجيا مجموعة بيانات تاريخية نظيفة، والتي غالبًا ما تكون القيد الملزم للمقاولين الذين لم يحتفظوا بأرشيفات تقدير منضبطة.\n\nالوظيفة الثالثة للذكاء الاصطناعي هي تسوية عروض المقاولين من الباطن. وهذا هو عمل استيعاب عروض المقاولين من الباطن بتنسيقات غير متناسقة وإنتاج بيانات مقارنة موحدة. لقد نضجت التكنولوجيا بشكل كبير في العامين الماضيين، ولكن الدقة لا تزال تعتمد على جودة عروض المقاولين من الباطن الأصلية وتعاريف نطاق المقاول المحددة.\n\nالوظيفة الرابعة للذكاء الاصطناعي هي تسجيل المخاطر. وهذا هو عمل تحديد بنود عرض الأسعار أو عروض المقاولين من الباطن أو افتراضات النطاق التي تحمل مخاطر عالية بناءً على الأنماط التاريخية. التكنولوجيا هنا هي الأقل نضجًا من الأربع، ولكنها أيضًا المكان الذي توجد فيه معظم المكاسب لأن تحديد المخاطر في مرحلة تقديم العطاءات أرخص بكثير من اكتشاف فجوات النطاق أثناء البناء.\n\nالوظيفة الخامسة للذكاء الاصطناعي هي إنشاء المقترحات. وهذا هو عمل إنتاج مستندات موجهة للعملاء من تقديرات الأسعار، مع تنسيق وسرد وعرض مناسبين للجمهور المستهدف. لقد نضجت التكنولوجيا بسرعة مع ظهور نماذج اللغات الكبيرة، والتحدي في التكامل هو ربط مولد المقترحات ببيانات التقدير دون إعادة تنسيق يدوية.\n\n## لماذا يهم التصميم المعماري أكثر من اختيار المنصة\n\nيميل المقاولون الذين يلاحقون ميزات المنصة دون تصميم سير العمل أولاً إلى مواجهة نفس مجموعة المشاكل بغض النظر عن المنصة التي يختارونها. تتولى المنصة تسعين بالمائة من دورة حياة العطاءات ولكنها تفشل في الحالات الطرفية المحددة التي تولدها عمليات المقاول بالفعل. تعمل عمليات التكامل لسيناريوهات العرض التوضيحي ولكنها تتعطل في ظروف العالم الحقيقي. تنتج طبقة الذكاء الاصطناعي مخرجات مفيدة للمشاريع القياسية ولكنها تفشل في المشاريع غير العادية التي غالبًا ما تحمل أعلى الهوامش.\n\nيقوم نهج "التصميم المعماري أولاً" بعكس هذه الديناميكية. من خلال رسم سير العمل أولاً، وتحديد القيود الملزمة، وتحديد أنماط التكامل قبل اختيار المنصات، ينتهي المقاولون بمجموعة تقنيات تتناسب مع واقعهم التشغيلي الفعلي بدلاً من مجموعة تقنيات تتناسب مع خارطة طريق بائع المنصة.\n\nوهذا مهم بشكل خاص للمقاولين الذين يعملون في قطاعات متخصصة أو مع أنواع مشاريع غير عادية. يصمم بائعو المنصات الرئيسيون منتجاتهم للحالات الشائعة، وهو أمر معقول من منظور السوق ولكنه غالبًا ما يكون غير كافٍ للمقاولين الذين يقع عملهم خارج الحالة الشائعة. تتيح عمليات النشر التي تعتمد على "التصميم المعماري أولاً" للمقاولين في تلك المواقف بناء سير عمل يتناسب مع واقعهم.\n\nيعكس نهج TFSF Ventures هذا التوجه "التصميم المعماري أولاً". يقوم التقييم التشغيلي المكون من 19 سؤالًا والذي يفتتح كل تعامل برسم خط أنابيب العطاءات المحدد للمقاول قبل تقديم أي توصية تكنولوجية، مما يضمن أن البنية التحتية للعامل الناتجة تعالج القيود الملزمة الفعلية بدلاً من أفضل الممارسات العامة.\n\nتعني منهجية النشر التي تستغرق 30 يومًا أن التصميم المعماري والوكلاء المنتجين يعملون في غضون أربعة أسابيع بدلاً من الدورات التي تستغرق عدة أرباع وهو أمر نموذجي لتكامل الأنظمة التقليدي. تعد بنية معالجة الاستثناءات، والتي تقع في صميم كل عملية نشر لـ TFSF، هي ما يفصل بين سير العمل على مستوى الإنتاج وسير العمل على مستوى النموذج الأولي، مع نتائج موثقة تظهر انخفاضًا بنسبة ثلاثين إلى خمسين بالمائة في وقت دورة العطاء وحماية كبيرة للهامش في العطاءات التنافسية.\n\nيعكس التسعير عمق العمل. تبدأ استثمارات النشر في عشرات الآلاف المنخفضة لعمليات النشر المركزة مع عدد قليل من الوكلاء، وتتزايد مع عدد الوكلاء، وتعقيد التكامل، والنطاق التشغيلي. تشتمل جميع عمليات النشر على رسوم مرور منفصلة للبنية التحتية للذكاء الاصطناعي تبلغ حوالي أربعمائة إلى خمسمائة دولار شهريًا من Pulse AI، بالتكلفة، بدون عمولة. يمتلك العملاء الكود المصدري بموجب ترخيص دائم، مما يلغي ربط المنصة والرسوم المستمرة لكل مقعد. يمكن للمقاولين الذين يقومون بتقييم مراجعات TFSF Ventures والبحث عن التحقق من شرعية TFSF Ventures تأكيد تسجيل الشركة RAKEZ License 47013955 ومراجعة سجل النشر المنشور في 21 قطاعًا.\n\n### نبذة عن TFSF Ventures\n\nTFSF Ventures هي شركة استشارية في مجال الذكاء الاصطناعي لقطاعي الهندسة والبناء (AEC) تأسست في دبي، الإمارات العربية المتحدة. تقدم TFSF Ventures FZ-LLC إرشادات إستراتيجية وتنفيذًا عمليًا متراكمًا للذكاء الاصطناعي في عمليات المكاتب الخلفية للمقاولين، مع التركيز على تحسين الكفاءة والإنتاجية وخفض التكاليف. نعمل مع شركات المقاولات والهندسة الكبرى في جميع أنحاء العالم.\n\nاحصل على تقييم معلومات العمليات المجاني\n\nنُشرت في الأصل على https://tfsfventures.com/blog/ai-path-architecture-first\n\nبقلم TFSF Ventures Research" }

markdown

تصميم معالجة الاستثناءات كأولوية قصوى

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

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

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

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

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

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

ربط سير العمل بالعمليات بعد المناقصة

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

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

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

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

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

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

بناء القدرة كنظام دائم

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

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

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

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

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

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

حول 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/architecting-ai-powered-construction-bidding-across-procore-autodesk-construction

كتب بواسطة TFSF Ventures Research