دامنه خدمات BIM در قرارداد چگونه تعریف شود تا اختلاف و دوباره‌کاری ایجاد نشود؟

مقدمه

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

چرا عبارت «خدمات BIM» برای قرارداد کافی نیست؟

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

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

برای مثال، عبارت «مدل‌سازی BIM تأسیسات پروژه» مشخص نمی‌کند که مدل شامل کدام سیستم‌ها، در چه محدوده‌ای، تا چه مرحله‌ای از طراحی و با چه سطحی از اطلاعات است. همچنین روشن نمی‌کند آیا تهیه مدارک، هماهنگی با معماری و سازه، شناسایی تداخل‌ها، اصلاح تداخل‌ها یا به‌روزرسانی مدل پس از تغییرات طراحی نیز بخشی از همان خدمت محسوب می‌شود یا خیر.

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

مشکل بسیاری از قراردادهای BIM کمبود خدمات نیست؛ نامشخص بودن مرز خدمات است.

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

دامنه خدمات باید از هدف استفاده از BIM شروع شود

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

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

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

به همین دلیل، شروع قرارداد با عباراتی مانند «مدل‌سازی با LOD 300» لزوماً دامنه را روشن نمی‌کند. سطح توسعه مدل باید تابع هدف استفاده از آن باشد، نه جایگزین تعریف هدف.

هدف BIM مشخص می‌کند چه کاری باید انجام شود؛ نه برعکس.

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

دامنه خدمات را بر اساس فعالیت، محدوده و مرحله پروژه تعریف کنید

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

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

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

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

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

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

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

چه چیزی باید در قرارداد مشخص شود و چه چیزی می‌تواند در BEP تعریف شود؟

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

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

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

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

قرارداد مشخص می‌کند چه چیزی تعهد شده است؛ BEP توضیح می‌دهد آن تعهد چگونه اجرا می‌شود.

هرچه این تفکیک روشن‌تر باشد، احتمال اینکه اختلافات اجرایی به اختلافات قراردادی تبدیل شوند کمتر خواهد شد.

انجام، بررسی و تأیید یک خدمت BIM ممکن است بر عهده طرف‌های متفاوت باشد

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

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

برای مثال، ممکن است BIM Coordinator مسئول شناسایی و ثبت تداخل‌ها باشد، اما این به معنی مسئولیت او برای اصلاح طراحی معماری، سازه یا تأسیسات نیست. اصلاح هر تداخل معمولاً باید توسط رشته‌ای انجام شود که تصمیم طراحی در اختیار آن است. اگر این تفاوت در قرارداد روشن نباشد، فعالیت «Clash Detection» می‌تواند به ‌اشتباه به تعهد «رفع تمام Clashها» تبدیل شود.

همین مسئله در کنترل مدل نیز وجود دارد. شخصی که مدل را بررسی می‌کند الزاماً مسئول تولید یا اصلاح آن نیست و فردی که تأیید نهایی را انجام می‌دهد نیز ممکن است نقش متفاوتی از تیم BIM داشته باشد.

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

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

هر تعهد BIM به ورودی‌ها، وابستگی‌ها و پیش‌فرض‌هایی متکی است

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

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

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

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

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

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

هر خدمت BIM باید به یک خروجی قابل تحویل ختم شود

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

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

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

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

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

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

بدون معیار پذیرش، تحویل BIM قابل ارزیابی نیست

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

معیار پذیرش بسته به نوع خروجی متفاوت است. برای یک مدل BIM، ممکن است شامل کامل‌ بودن عناصر موردنیاز، صحت مختصات، رعایت ساختار نام‌گذاری، تکمیل پارامترهای الزامی، کنترل تداخل‌ها، کیفیت مستندسازی، فرمت فایل و وضعیت Model Health باشد. برای یک گزارش هماهنگی نیز ممکن است تعداد Issueهای باز، نحوه دسته ‌بندی، مسئول هر مورد و وضعیت تأیید آن اهمیت داشته باشد.

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

تحویل زمانی قابل کنترل است که «شرایط قابل قبول بودن» آن از قبل تعریف شده باشد.

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

زمان‌بندی BIM فقط تاریخ تحویل نهایی نیست

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

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

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

برنامه BIM باید جریان تولید و تصمیم گیری را کنترل کند، نه فقط آخرین تاریخ تحویل را.

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

اصلاح نقص، بازنگری و تغییر طراحی یکسان نیستند

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

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

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

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

اصلاح نقص تحویل با بازطراحی ناشی از تغییرات پروژه یکسان نیست.

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

وقتی دامنه تغییر می‌کند، اثر آن بر زمان و تعهدات باید کنترل شود

تغییر در پروژه‌های BIM اجتناب ‌ناپذیر است. مسئله اصلی این نیست که دامنه خدمات هرگز تغییر نکند؛ مسئله این است که مشخص باشد تغییر چگونه شناسایی، ارزیابی و تأیید می‌شود.

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

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

بهتر است تغییر دامنه از یک مسیر روشن عبور کند: درخواست تغییر، بررسی اثر آن بر خروجی‌ها و زمان‌بندی، توافق درباره تعهدات جدید و سپس اجرا.

تغییر زمانی قابل کنترل است که قبل از اجرا، اثر آن بر دامنه و برنامه مشخص شده باشد.

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

دامنه خدمات فقط با نوشتن تعهدات روشن نمی‌شود

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

برای مثال، ممکن است «مدل‌سازی BIM» شامل توسعه Familyهای اختصاصی، برداشت از وضع موجود، تهیه مدل ساخت، تولید Shop Drawing یا به‌روزرسانی مدل پس از اجرای کار نباشد. همچنین «هماهنگی BIM» لزوماً به معنی پذیرش مسئولیت طراحی رشته‌ها، انجام محاسبات مهندسی یا اصلاح تمام مسائل شناسایی‌ شده نیست.

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

این موضوع در خدماتی مانند مدل‌سازی شرایط موجود، پردازش Point Cloud، تولید Family، استخراج مقادیر، آموزش تیم، تهیه مدارک اجرایی یا پشتیبانی پس از تحویل اهمیت بیشتری پیدا می‌کند، زیرا ممکن است هر یک از آن‌ها از نظر یکی از طرفین به ‌طور ضمنی بخشی از «خدمات BIM» تلقی شوند.

مرز یک خدمت هم با آنچه شامل می‌شود مشخص می‌شود و هم با آنچه شامل نمی‌شود.

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

نمونه عملی: یک شرح خدمات مبهم چگونه به اختلاف تبدیل می‌شود؟

فرض کنید در قرارداد فقط نوشته شده باشد:

«مدل‌سازی BIM تأسیسات و انجام Clash Detection پروژه».

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

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

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

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

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

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

جمع‌بندی

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

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

همچنین باید روشن باشد چه مواردی در دامنه قرار ندارند و چه چیزی در صورت درخواست، به تغییر دامنه یا خدمت اضافی تبدیل می‌شود.

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

همین شفافیت یکی از معیارهای مهم در انتخاب شرکت یا مشاور خدمات BIM نیز هست.

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