متن مقاله
مقدمه
برای کارفرما، داشتن BEP فقط زمانی ارزش دارد که سند بتواند اجرای واقعی BIM را هدایت و کنترل کند. یک BEP ممکن است از نظر ساختار ظاهری کامل باشد، اما در مسئولیتها، معیارهای تحویل، روش هماهنگی یا واکنش به انحراف پاسخ اجرایی روشنی نداشته باشد. این مقاله توضیح میدهد کارفرما هنگام بررسی BEP باید چه چیزهایی را بسنجد تا پیش از تأیید مشخص شود برنامه پیشنهادی تا چه حد با الزامات پروژه همراستاست و آیا میتواند مبنای کنترل عملکرد تیمها قرار گیرد.
چرا بررسی BEP برای کارفرما اهمیت دارد؟
ارائه BEP به تنهایی نشان نمیدهد که اجرای BIM پروژه تحت کنترل است. این سند ممکن است از نظر ظاهری کامل باشد، تمام سرفصلهای متداول را داشته باشد و حتی شامل نمودارهای سازمانی، برنامههای هماهنگی و دستورالعملهای فنی باشد؛ اما همچنان نتوان بر اساس آن عملکرد واقعی تیم را ارزیابی کرد.
برای کارفرما، مسئله اصلی این نیست که آیا BEP ارائه شده است یا خیر. مسئله این است که آیا این سند توضیح میدهد تعهدات BIM پروژه چگونه قرار است به یک فرایند اجرایی تبدیل شوند.
یک BEP قابل اتکا باید بتواند به پرسشهای عملی پاسخ دهد: چه کسی مسئول هر فعالیت است؟ چه اطلاعاتی باید تولید و تحویل شود؟ هماهنگی مدلها چگونه انجام میشود؟ خروجیها بر اساس چه معیارهایی کنترل و تأیید میشوند؟ و اگر بخشی از برنامه اجرا نشد، چه سازوکاری برای اصلاح یا تصمیم گیری وجود دارد؟
به همین دلیل، بررسی BEP نباید به کنترل فهرست مطالب یا وجود چند عبارت استاندارد محدود شود. کارفرما باید بتواند میان الزامات پروژه و روش پیشنهادی تیم برای اجرای آنها ارتباط مشخصی پیدا کند.
وجود BEP به معنی کنترل BIM پروژه نیست؛ BEP زمانی ارزش دارد که بتوان اجرای واقعی پروژه را بر اساس آن سنجید و پیگیری کرد.
بررسی BEP در واقع بررسی این موضوع است که آیا سند ارائه شده میتواند به عنوان یک مبنای عملی برای مدیریت، کنترل و ارزیابی اجرای BIM در طول پروژه مورد استفاده قرار گیرد یا صرفاً توضیحی کلی از نحوه کار تیم است.
اولین معیار بررسی: پاسخ BEP به الزامات کارفرما
BEP را نمیتوان مستقل از الزامات پروژه ارزیابی کرد. اولین سؤال کارفرما باید این باشد که این سند دقیقاً چگونه به الزامات BIM که کارفرما پیش از مناقصه مشخص کرده است پاسخ میدهد؟
اگر کارفرما در اسناد مناقصه یا الزامات اطلاعاتی، خروجیهای مشخصی مانند مدل هماهنگ شده، برنامه تحویل اطلاعات، کنترل تداخلها، مدل As-Built یا ساختار معینی برای تبادل اطلاعات درخواست کرده است،BEP باید روش دستیابی به هر یک از این موارد را روشن کند.
در یک BEP ضعیف، ممکن است اصطلاحات درست و فرایندهای آشنا دیده شوند، اما ارتباط آنها با الزامات واقعی پروژه مشخص نباشد. برای مثال، سند ممکن است درباره هماهنگی مدلها توضیح دهد، بدون آنکه مشخص کند این هماهنگی چگونه به نقاط تحویل مورد انتظار کارفرما متصل میشود.
بهتر است بررسی به صورت تطبیقی انجام شود:
الزام کارفرما ← پاسخ BEP ← روش اجرا ← خروجی قابل ارزیابی
اگر برای یکی از الزامات اصلی، این زنجیره قابل تشخیص نباشد، آن بخش از BEP هنوز پاسخ اجرایی کافی ارائه نمیدهد.
همچنین باید مشخص شود آیا تیم پیشنهاد دهنده بخشی از الزامات را تغییر داده، محدود کرده یا با برداشت متفاوتی تفسیر کرده است. چنین اختلافهایی بهتر است پیش از شروع اجرا شناسایی شوند، نه زمانی که اولین تحویل پروژه انجام شده است.
BEP زمانی قابل ارزیابی است که بتوان هر تعهد مهم پروژه را به یک روش اجرای مشخص در سند متصل کرد.
به همین دلیل، کیفیت BEP با تعداد صفحات آن سنجیده نمیشود؛ معیار اصلی این است که آیا سند واقعاً نشان میدهد تیم چگونه تعهدات BIM کارفرما را اجرا خواهد کرد.
BEP باید برای همین پروژه تنظیم شده باشد
استفاده از Template برای تدوین BEP به خودی خود ایرادی ندارد. در بسیاری از سازمانها، یک ساختار پایه برای حفظ انسجام اسناد استفاده میشود. مسئله زمانی ایجاد میشود که محتوای عمومی Template بدون تطبیق کافی با شرایط واقعی پروژه باقی بماند.
کارفرما باید بتواند در BEP ردپای خود پروژه را ببیند: ساختار تیمها، رشتههای درگیر، روش قرارداد، نقاط تحویل، نرمافزارها و محیطهای مورد استفاده، نحوه تقسیم مدلها، سطح پیچیدگی هماهنگی و الزامات خاص کارفرما.
اگر سند درباره نقشهایی صحبت میکند که در پروژه وجود ندارند، به نرمافزار یا CDE دیگری اشاره میکند، milestoneهای واقعی پروژه را منعکس نمیکند یا روش هماهنگی آن با ساختار واقعی تیمها سازگار نیست، احتمال زیادی وجود دارد که BEP بیشتر یک سند عمومی باشد تا برنامه اجرایی این پروژه.
یکی از نشانههای مهم، وجود عبارتهای مبهمی است که تقریباً در هر پروژهای قابل استفادهاند؛ مانند اینکه «مدلها بهطور منظم کنترل میشوند» یا «هماهنگی بین رشتهها انجام خواهد شد»، بدون آنکه این فرایندها با ساختار و زمانبندی پروژه مرتبط شده باشند.
یک BEP خوب ممکن است بر اساس Template نوشته شده باشد، اما نباید مانند Template خوانده شود.
هدف کارفرما نباید پیدا کردن متنهای اختصاصی یا طولانی باشد. هدف این است که مطمئن شود سند به اندازه کافی با واقعیت پروژه تطبیق یافته و تصمیمهای اجرایی آن بر اساس شرایط همین پروژه گرفته شدهاند.
مسئولیتها باید به فعالیتها و تصمیمهای واقعی متصل باشند
وجود عنوانهایی مانند BIM Manager،BIM Coordinator یا Discipline Lead در BEP به تنهایی نشان نمیدهد که مسئولیتها به درستی تعریف شدهاند. آنچه برای کارفرما اهمیت دارد این است که بداند برای هر فعالیت مهم و هر تصمیم کلیدی، چه کسی مسئول است و حدود اختیار او تا کجاست.
برای مثال، باید روشن باشد چه کسی مدل هر رشته را کنترل میکند، چه کسی اجازه انتشار اطلاعات را دارد، چه کسی مسئول تجمیع مدلهاست، چه کسی مسائل هماهنگی را پیگیری میکند و چه کسی میتواند یک خروجی را برای تحویل تأیید کند. اگر این مسئولیتها فقط در قالب عناوین سازمانی بیان شده باشند، در زمان بروز مشکل ممکن است مشخص نباشد چه کسی باید اقدام کند.
یک روش ساده برای ارزیابی این بخش آن است که کارفرما چند سناریوی واقعی را در نظر بگیرد: اگر یک مدل با تأخیر تحویل شود چه کسی پاسخگوست؟ اگر یک تعارض مهم میان معماری و تأسیسات حل نشود، چه کسی باید تصمیم بگیرد؟ اگر اطلاعات اشتباهی منتشر شود، مسئول کنترل و اصلاح آن چه کسی است؟
ساختار مسئولیت زمانی مؤثر است که در شرایط واقعی پروژه بتوان بر اساس آن تصمیم گرفت و پیگیری کرد.
در BEP قوی، نقشها به فعالیتها، نقاط کنترل و تصمیمهای مشخص متصل هستند. در BEP ضعیف، نقشها وجود دارند اما مرز مسئولیتها و اختیار مبهم است.
کارفرما باید بتواند از روی سند بفهمد نه فقط «چه کسانی در تیم BIM حضور دارند»، بلکه هر یک دقیقاً مسئول چه چیزی هستند، چه اختیاری دارند و در چه مرحلهای باید پاسخگو باشند.
چه اطلاعاتی، چه زمانی و توسط چه کسی تحویل میشود؟
یکی از مهمترین بخشهای BEP این است که مشخص کند اطلاعات پروژه چگونه در طول زمان تولید و تحویل میشوند. برای کارفرما کافی نیست که بداند «مدلها در مراحل مختلف ارائه خواهند شد»؛ باید بتواند بفهمد دقیقاً چه چیزی، توسط چه کسی و در چه زمانی باید تحویل شود.
در یک برنامه قابل اجرا، هر تحویل باید حداقل از چند جهت روشن باشد: نوع اطلاعات یا مدل، مسئول تهیه، زمان تحویل، قالب مورد انتظار، گیرنده و هدف استفاده از آن. پیشنیاز این بخش، تعریف تحویلهای BIM پیش از شروع مدلسازی است؛ BEP باید روش تولید و کنترل همان تحویلهای از پیش تعریفشده را توضیح دهد.
برای مثال، اگر قرار است در یک مرحله مشخص مدل هماهنگ شده تأسیسات برای بررسی ارائه شود، BEP باید نشان دهد این مدل از کدام مدلهای رشتهای تشکیل میشود، چه کسی مسئول آماده سازی آن است، پیش از تحویل چه کنترلهایی روی آن انجام میشود و این تحویل برای چه تصمیم یا milestoneای مورد استفاده قرار خواهد گرفت.
ابهام در این بخش معمولاً بعداً به اختلاف تبدیل میشود. یک تیم ممکن است تصور کند «تحویل مدل» انجام شده است، درحالیکه کارفرما انتظار مجموعه کاملتری از اطلاعات یا سطح متفاوتی از جزئیات را داشته باشد.
هر تحویل BIM باید به یک خروجی مشخص، یک مسئول مشخص و یک زمان مشخص متصل باشد.
کارفرما باید بتواند با مطالعه BEP یک تصویر زمانی از جریان اطلاعات پروژه به دست آورد. اگر مشخص نباشد چه اطلاعاتی در هر مرحله باید در دسترس باشد، برنامهریزی برای بررسی، هماهنگی و تصمیم گیری نیز قابل اتکا نخواهد بود.
در این بخش، هدف صرفاً داشتن یک جدول زمان بندی نیست؛ هدف این است که زنجیره تولید و تحویل اطلاعات پروژه قابل پیشبینی و قابل کنترل باشد.
ساختار مدلها و روش تجمیع آنها
BEP باید مشخص کند مدلهای پروژه چگونه تقسیم میشوند و این تقسیم بندی چه ارتباطی با روش واقعی اجرای پروژه دارد. صرف اینکه هر رشته یک مدل جداگانه داشته باشد، به معنی وجود یک ساختار مناسب نیست.
کارفرما باید بتواند تشخیص دهد مرز میان مدلهای معماری، سازه و تأسیسات چگونه تعریف شده، در پروژههای بزرگ مدلها بر چه اساسی به ساختمان، طبقه، زون یا بخشهای اجرایی تقسیم میشوند و مسئولیت مالکیت هر مدل بر عهده کدام تیم است.
این موضوع مستقیماً بر هماهنگی، عملکرد فایلها، مدیریت لینکها و کنترل تغییرات اثر میگذارد. اگر تقسیم مدلها نامناسب باشد، حتی تیمی با مهارت فنی بالا ممکن است با مدلهای سنگین، وابستگیهای پیچیده یا ابهام در مسئولیت مواجه شود.
BEP همچنین باید روش تجمیع مدلها را روشن کند: چه کسی مدلهای رشتهای را برای هماهنگی کنار هم قرار میدهد، کدام نسخهها مبنای تجمیع هستند، هماهنگی مختصات چگونه کنترل میشود و مدل تجمیعی در چه زمانهایی بهروزرسانی خواهد شد.
ساختار مدلها یک تصمیم فنی صرف نیست؛ بخشی از ساختار مدیریت و هماهنگی پروژه است.
برای کارفرما مهم است که این ساختار با اندازه، پیچیدگی و روش تحویل پروژه تناسب داشته باشد. یک روش مناسب برای پروژهای کوچک ممکن است در پروژهای چندساختمانی یا چندرشتهای ناکارآمد باشد.
بنابراین، هنگام بررسی BEP باید پرسید آیا روش تقسیم و تجمیع مدلها واقعاً اجرای پروژه را سادهتر و قابل کنترلتر میکند یا فقط یک ساختار عمومی بدون ارتباط روشن با شرایط پروژه ارائه شده است.
وقتی تعارضی میان مدلها پیدا میشود، چه اتفاقی میافتد؟
ذکر عبارتی مانند «Clash Detection به صورت هفتگی انجام میشود» به تنهایی نشان نمیدهد که فرایند هماهنگی پروژه بهدرستی تعریف شده است. سؤال مهمتر این است که پس از شناسایی یک تعارض چه اتفاقی میافتد؟
BEP باید مشخص کند چه کسی مسئول اجرای کنترل تداخلهاست، کدام مدلها با یکدیگر بررسی میشوند، معیار تشخیص تعارض چیست و نتایج چگونه ثبت و بین تیمها توزیع میشوند. اما این فقط آغاز فرایند است.
برای هر مسئله باید مسیر مشخصی وجود داشته باشد:
شناسایی ← ثبت ← تعیین مسئول ← اصلاح ← بازبینی ← تأیید ← بستهشدن
اگر تعارضی به تیم مربوطه ارجاع شود اما زمان اصلاح، مسئول پیگیری یا معیار بسته شدن آن مشخص نباشد، گزارش Clash به تنهایی ارزش مدیریتی محدودی خواهد داشت.
همچنین BEP باید روشن کند با مسائل حل نشده چه برخوردی میشود. برخی تعارضها ممکن است به دلیل محدودیت طراحی، اختلاف میان رشتهها یا نیاز به تصمیم کارفرما در سطح تیم هماهنگی قابل حل نباشند. در این شرایط باید مسیر escalation و مرجع تصمیم گیری مشخص باشد.
Clash Detection بدون مسئول اصلاح، زمان پاسخ و معیار بستهشدن Issue، فرایند هماهنگی کامل نیست.
کارفرما هنگام بررسی این بخش باید بتواند تشخیص دهد که آیا BEP فقط روش پیدا کردن مشکلات را توضیح میدهد یا یک سازوکار واقعی برای مدیریت آنها تا رسیدن به نتیجه تعریف کرده است.
مسیر بررسی، تأیید و انتشار اطلاعات
در بسیاری از BEPها نام CDE ذکر میشود، اما صرف تعیین یک نرمافزار یا فضای مشترک برای نگهداری فایلها به معنی تعریف گردش اطلاعات نیست. کارفرما باید بداند اطلاعات از زمان تولید تا زمانی که بهعنوان مرجع رسمی پروژه منتشر میشوند، چه مراحلی را طی میکنند.
برای هر نوع اطلاعات باید مشخص باشد چه کسی آن را ایجاد میکند، چه کسی بازبینی میکند، در چه شرایطی اجازه اشتراک گذاری یا انتشار دارد و کدام نسخه باید به عنوان مرجع معتبر مورد استفاده قرار گیرد.
این موضوع به ویژه زمانی اهمیت پیدا میکند که چند تیم به صورت هم زمان روی پروژه فعالیت میکنند. اگر وضعیت یک مدل یا فایل روشن نباشد، ممکن است یک تیم بر اساس نسخهای قدیمی کار کند، اطلاعاتی که هنوز تأیید نشدهاند مبنای تصمیم قرار گیرند یا مشخص نباشد کدام نسخه برای اجرا معتبر است.
BEP باید مسیرهایی مانند کار در حال انجام، اشتراک برای هماهنگی، انتشار رسمی و نگهداری سوابق را به صورت متناسب با پروژه تعریف کند. همچنین باید مشخص باشد تغییر وضعیت اطلاعات توسط چه نقشی انجام میشود و چه سابقهای از این تصمیم باقی میماند.
CDE زمانی به کنترل پروژه کمک میکند که وضعیت، نسخه، مسئولیت و اختیار انتشار اطلاعات در آن روشن باشد.
کارفرما هنگام بررسی این بخش نباید فقط بپرسد «از چه CDEای استفاده میشود؟» سؤال مهمتر این است که آیا میتوان از روی BEP تشخیص داد کدام اطلاعات قابل استفادهاند، چه کسی آنها را تأیید کرده و مسیر انتشار آنها چگونه قابل ردیابی است؟
کنترل کیفیت بدون معیار قابل سنجش کافی نیست
یکی از عبارتهای رایج در BEP این است که «مدلها پیش از تحویل کنترل میشوند». این جمله به تنهایی برای کارفرما کافی نیست، زیرا تا زمانی که معیار کنترل مشخص نباشد، نمیتوان کیفیت خروجی را به صورت یکنواخت ارزیابی کرد.
BEP باید روشن کند چه چیزهایی کنترل میشوند و این کنترل بر اساس چه معیارهایی انجام میشود. بسته به نوع پروژه، این موارد میتوانند شامل صحت اطلاعات، پارامترهای موردنیاز، نامگذاری، طبقهبندی، مختصات، ساختار فایلها، لینکها، هشدارهای مدل، کیفیت هندسه و میزان انطباق خروجی با الزامات پروژه باشند.
همچنین باید مشخص باشد چه کسی کنترل کیفیت را انجام میدهد، این کنترل در چه مرحلهای صورت میگیرد، نتیجه آن چگونه ثبت میشود و در صورت مشاهده عدم انطباق چه فرایندی برای اصلاح وجود دارد.
اگر معیارها فقط به صورت کلی بیان شده باشند، ممکن است هر تیم برداشت متفاوتی از «مدل قابل قبول» داشته باشد. در این شرایط، اختلافها معمولاً هنگام تحویل نهایی ظاهر میشوند؛ یعنی زمانی که اصلاح آنها پرهزینهتر است.
کنترل کیفیت زمانی قابل اتکاست که معیار، مسئول، زمان و نتیجه کنترل قابل مشاهده و قابل پیگیری باشد.
کارفرما هنگام بررسی این بخش باید بتواند تشخیص دهد که آیا کیفیت صرفاً به تجربه و قضاوت افراد وابسته است یا BEP یک روش مشخص برای سنجش انطباق خروجیها تعریف کرده است.
هدف از این کنترل، رسیدن به مدل «بینقص» نیست؛ هدف این است که کیفیت مورد انتظار پروژه از قبل تعریف شده و به صورت قابل تکرار کنترل شود.
تحویل پروژه چه زمانی برای کارفرما قابل پذیرش است؟
کنترل کیفیت داخلی تیم تحویل با پذیرش خروجی توسط کارفرما یکسان نیست. ممکن است یک مدل از نظر تیم تولید کننده کنترل شده باشد، اما همچنان الزامات مورد انتظار کارفرما را برآورده نکند.
BEP باید مشخص کند در هر مرحله چه چیزی تحویل میشود و کارفرما بر چه اساسی میتواند آن را تأیید یا رد کند. این معیارها میتوانند شامل کامل بودن اطلاعات، انطباق با الزامات BIM، وضعیت هماهنگی، قالب فایلها، ساختار مدل، سطح اطلاعات مورد انتظار و تکمیل کنترلهای پیش از تحویل باشند.
همچنین باید فرایند بررسی روشن باشد: خروجی چه زمانی ارائه میشود، چه کسی آن را بررسی میکند، زمان پاسخ چقدر است، نظرها چگونه ثبت میشوند و اگر تحویل پذیرفته نشد، چه مسیری برای اصلاح و ارسال مجدد وجود دارد.
اگر این موارد از ابتدا تعریف نشده باشند، «تحویل» ممکن است برای دو طرف معنای متفاوتی داشته باشد. تیم تحویل ممکن است ارائه فایل را پایان تعهد خود بداند، درحالی که کارفرما انتظار خروجی تأیید شده و قابل استفاده را داشته باشد.
تحویل، زمانی کامل است که معیار پذیرش آن از پیش مشخص باشد؛ نه صرفاً زمانی که فایل ارسال شده است.
کارفرما باید بتواند از روی BEP برای هر milestone تشخیص دهد چه خروجیای انتظار میرود، چه شرایطی برای پذیرش آن وجود دارد و در صورت عدم پذیرش چه اتفاقی میافتد.
این تفکیک میان تولید، کنترل داخلی، تحویل و پذیرش یکی از مهمترین نشانههای یک BEP قابل اجراست. در مرحله تحویل، همین منطق باید به ارزیابی و پذیرش مدل BIM تحویلی تبدیل شود.
اگر برنامه اجرا نشود یا شرایط پروژه تغییر کند چه اتفاقی میافتد؟
BEP فقط برای شرایط عادی پروژه نوشته نمیشود. بخش مهمی از ارزش آن زمانی مشخص میشود که یک تعهد انجام نشود، یک مسئله حل نشده باقی بماند یا شرایط پروژه تغییر کند.
کارفرما باید بتواند از روی BEP بفهمد در صورت بروز انحراف چه مسیری طی میشود. برای مثال، اگر یک تیم مدل خود را در موعد مقرر تحویل ندهد، یک Issue هماهنگی چند بار بدون نتیجه باز بماند یا خروجی ارائه شده با معیارهای تعیین شده منطبق نباشد، باید مشخص باشد موضوع چگونه ثبت، پیگیری و در صورت نیاز به سطح بالاتر ارجاع میشود.
همین موضوع درباره تغییرات نیز صادق است. در طول پروژه ممکن است ساختار تیم، الزامات کارفرما، برنامه تحویل، نرمافزارهای مورد استفاده یا حتی نحوه تقسیم مدلها تغییر کند. اگر این تغییرات روی روش اجرای BIM اثر بگذارند، BEP نیز باید بهصورت کنترلشده بهروزرسانی شود.
BEP نباید سندی ثابت باشد که فقط در ابتدای پروژه تأیید میشود و بعد از آن از جریان واقعی کار فاصله میگیرد.
یک BEP قابل اتکا باید مشخص کند چه تغییراتی نیازمند بازنگری سند هستند، چه کسی مجاز به پیشنهاد یا تأیید این تغییرات است و نسخه جدید چگونه به تیمها ابلاغ میشود.
برای کارفرما، وجود این سازوکار مهم است؛ زیرا کنترل BIM فقط به تعریف فرایندها محدود نمیشود. باید مشخص باشد وقتی پروژه از مسیر برنامهریزیشده خارج میشود، چه کسی مسئول بازگرداندن آن به یک وضعیت قابل کنترل است.
آزمون قابلیت اجرای BEP
پس از بررسی بخشهای مختلف BEP، کارفرما باید بتواند یک سؤال ساده اما تعیین کننده مطرح کند: آیا میتوان اجرای واقعی پروژه را بر اساس این سند کنترل کرد؟
برای پاسخ به این سؤال، هر فرایند مهم در BEP را میتوان با شش معیار بررسی کرد:
اقدام: دقیقاً چه کاری باید انجام شود؟
مسئول: چه کسی مسئول انجام یا تأیید آن است؟
زمان: این اقدام در چه مرحله یا زمانی انجام میشود؟
معیار: بر اساس چه ضابطهای درست یا کامل بودن آن سنجیده میشود؟
مدرک: چه سابقهای نشان میدهد این اقدام انجام شده است؟
واکنش به انحراف: اگر انجام نشد یا نتیجه قابل قبول نبود، چه اتفاقی میافتد؟
برای مثال، جمله «مدلها پیش از تحویل کنترل میشوند» از نظر ظاهری درست است، اما پاسخ روشنی به بیشتر این پرسشها نمیدهد. در مقابل، اگر BEP مشخص کند چه کسی مدل را بررسی میکند، این کنترل چه زمانی انجام میشود، از چه چکلیست یا معیارهایی استفاده میشود، نتیجه کجا ثبت میشود و عدم انطباق چگونه پیگیری خواهد شد، فرایند قابل ارزیابیتر میشود.
هرچه یک تعهد در BEP قابل اندازهگیری، قابل ردیابی و قابل پیگیریتر باشد، احتمال اجرایی بودن آن بیشتر است.
این آزمون را میتوان برای هماهنگی مدلها، کنترل کیفیت، انتشار اطلاعات، تحویلهای مرحلهای یا هر فرایند مهم دیگری به کار برد.
هدف، تبدیل BEP به مجموعهای از جزئیات غیرضروری نیست؛ هدف این است که سند از سطح «توضیح نیت» عبور کند و به مبنایی برای کنترل عملکرد واقعی پروژه تبدیل شود.
جمعبندی
تأیید BEP به این معنا نیست که BIM پروژه از آن لحظه به بعد تحت کنترل خواهد بود. در بهترین حالت، BEP یک مبنای توافقشده برای اجرا ایجاد میکند؛ اما ارزش واقعی آن زمانی مشخص میشود که عملکرد تیمها در طول پروژه با همین مبنا مقایسه شود.
پس از شروع کار، کارفرما باید بتواند بررسی کند آیا تحویلهای برنامه ریزی شده در زمان مقرر انجام میشوند، فرایند هماهنگی مطابق روش تعریفشده پیش میرود، مسئولیتها در عمل رعایت میشوند و خروجیها پیش از پذیرش بر اساس معیارهای توافق شده کنترل شدهاند.
همچنین باید مشخص باشد آیا تغییرات پروژه در BEP منعکس شدهاند یا سند به تدریج از روش واقعی کار فاصله گرفته است. اگر تیمها روش دیگری برای تبادل اطلاعات، هماهنگی مدلها یا کنترل کیفیت در پیش گرفتهاند، کارفرما باید بداند این تغییر چرا ایجاد شده و آیا به صورت رسمی تأیید شده است.
BEP نقطه پایان کنترل نیست؛ نقطه شروع مقایسه میان آنچه تعهد شده و آنچه واقعاً اجرا میشود است.
به همین دلیل، بررسی BEP تنها یکی از نقاط کنترل در طول پروژه است. در چارچوب مشاوره BIM سمت کارفرما، این سند در کنار الزامات پروژه، برنامههای تحویل اطلاعات، کیفیت خروجیها و عملکرد واقعی تیمها بررسی میشود تا کارفرما بتواند انحرافها را پیش از تبدیل شدن به مسئلهای جدی شناسایی کند. اگر میخواهید ببینید یک عبارت مبهم در BEP چگونه بعداً به دوبارهکاری، اختلاف مسئولیت یا مشکل پذیرش تبدیل میشود، مقاله پیامدهای ابهام در BEP ادامه منطقی همین بحث است. تجربههای همکاری BIMFlow با کارفرما نمونههایی از ممیزی مستقل و پایش دورهای این نقش را نشان میدهند.
در نهایت، یک BEP خوب زمانی ارزشمند است که از یک سند قراردادی یا تشریفاتی فراتر برود و به مرجعی عملی برای پایش، تصمیم گیری و کنترل اجرای BIM پروژه تبدیل شود.