چرا پروژه BIM با وجود داشتن BEP باز هم از کنترل خارج می‌شود؟

مقدمه

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

BEP چه نقشی در کنترل پروژه BIM دارد و چه نقشی ندارد؟

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

اما تعریف یک فرایند با اجرای واقعی آن یکسان نیست.

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

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

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

بنابراین پرسش اصلی فقط این نیست که «آیا پروژه BEP دارد؟»؛ باید بررسی کرد آیا آنچه در BEP تعریف شده، در جریان واقعی پروژه قابل اجرا، قابل سنجش و قابل پیگیری است یا خیر.

وقتی BEP با واقعیت پروژه تناسب ندارد

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

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

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

BEP خوب سندی نیست که بیشترین جزئیات را داشته باشد؛ سندی است که بتوان آن را در پروژه واقعی اجرا کرد.

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

مسئولیت‌ها مشخص‌اند، اما اختیار تصمیم گیری روشن نیست

در بسیاری از پروژه‌های BIM، نقش‌ها در BEP مشخص شده‌اند، اما مرز میان انجام کار و اختیار تصمیم گیری روشن نیست. ممکن است BIM Coordinator مسئول هماهنگی مدل‌ها باشد، تیم مکانیک موظف به اصلاح تداخل‌ها باشد و BIM Manager نیز بر فرایند نظارت کند؛ اما وقتی دو رشته درباره راه‌ حل یک مسئله اختلاف نظر دارند، مشخص نباشد چه کسی تصمیم نهایی را می‌گیرد.

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

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

مشخص بودن مسئول انجام کار کافی نیست؛ باید مشخص باشد چه کسی اختیار تصمیم گیری درباره نتیجه آن کار را دارد.

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

جلسات هماهنگی برگزار می‌شوند، اما مسائل بسته نمی‌شوند

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

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

یک چرخه ساده می‌تواند چنین باشد:

شناسایی مسئله ← تعیین مسئول ← تصمیم ← تعیین مهلت ← اصلاح ← بازبینی ← بستن

اگر یکی از این مراحل حذف شود، جلسه هماهنگی به محلی برای مرور مشکلات تبدیل می‌شود، نه کنترل آن‌ها.

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

هماهنگی زمانی کامل می‌شود که هر مسئله به تصمیم، مسئول، مهلت و تأیید نهایی منتهی شود.

بنابراین معیار موفقیت جلسه هماهنگی تعداد مسائل مطرح ‌شده نیست؛ تعداد مسائلی است که با تصمیم روشن و نتیجه قابل تأیید بسته می‌شوند.

استانداردهای BIM وجود دارند، اما رعایت آن‌ها کنترل نمی‌شود

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

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

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

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

استاندارد زمانی بخشی از سیستم کنترل پروژه است که انحراف از آن قابل شناسایی و پیگیری باشد.

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

کنترل کیفیت به انتهای فرایند موکول می‌شود

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

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

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

به‌صورت ساده، فرایند باید بیشتر شبیه این باشد:

تولید ← کنترل ← اصلاح ← ادامه توسعه ← کنترل مجدد ← انتشار

نه:

تولید طولانی‌مدت ← کنترل نهایی ← کشف انبوه خطاها

کنترل کیفیت دیرهنگام خطا را کشف می‌کند؛ کنترل مرحله‌ای از انباشته شدن آن جلوگیری می‌کند.

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

زمان تحویل مشخص است، اما معیار پذیرش تعریف نشده است

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

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

تحویل شدن یک خروجی با پذیرفته شدن آن یکسان نیست.

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

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

مسائل حل‌نشده مسیر مشخصی برای ارجاع ندارند

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

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

مسیر ارجاع باید متناسب با ساختار پروژه تعریف شود. برای مثال، یک مسئله ممکن است ابتدا در سطح Coordinator بررسی شود، سپس به مدیر رشته یا BIM Manager منتقل شود و در صورت نیاز به تصمیم طراحی، قراردادی یا کارفرمایی، به سطح مدیریت پروژه یا نماینده مجاز کارفرما برسد.

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

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

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

BEP با تغییرات پروژه به‌روزرسانی نمی‌شود

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

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

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

BEP باید سندی کنترل‌شده باشد؛ نه سندی ثابت و نه سندی که با هر تغییر جزئی بازنویسی شود.

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

در غیر این صورت، پروژه به‌تدریج با دو مرجع پیش می‌رود: یک BEP رسمی که دیگر معتبر نیست و یک روش اجرایی غیررسمی که هیچ‌گاه به‌طور کامل ثبت نشده است.

تفاوت BEP مصوب با فرایند BIM عملیاتی چیست؟

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

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

برای مثال:

تفاوت اصلی میان BEP مصوب و فرایند عملیاتی، وجود سازوکار قابل مشاهده برای اجرا و کنترل الزامات است.

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

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

جمع‌بندی

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

یک حلقه ساده کنترل می‌تواند چنین باشد:

الزام ← مسئول ← اجرا ← شواهد ← کنترل ← تصمیم ← اقدام اصلاحی ← تأیید ← بستن یا ارجاع

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

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

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

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