پرش به محتوا
مقاله تحلیلی19 دقیقه مطالعه

چرا برون‌سپاری مدل‌سازی BIM معمولاً شکست می‌خورد؟

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

متن مقاله

مقدمه

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

برون‌سپاری مدل‌سازی BIM دقیقاً چه مسئله‌ای را قرار است حل کند؟

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

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

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

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

پیش از برون‌سپاری باید مشخص شود:

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

مدل BIM یک خروجی است؛ نه جایگزین فرایند BIM

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

اما مدل BIM فقط یکی از خروجی‌های یک فرایند بزرگ‌تر است.

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

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

به همین دلیل، واگذاری مدل‌سازی به یک تیم بیرونی نمی‌تواند جایگزین ساختار داخلی پروژه برای موارد زیر شود:

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

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

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

وقتی هدف مدل‌سازی از ابتدا روشن نیست

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

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

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

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

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

بنابراین پیش از آغاز مدل‌سازی باید حداقل مشخص باشد:

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

مدل‌ساز بیرونی چگونه باید الزامات پروژه را بشناسد؟

حتی زمانی که هدف مدل‌سازی مشخص است، یک مسئله مهم باقی می‌ماند: این هدف چگونه به یک تیم بیرونی منتقل می‌شود؟

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

این برداشت ممکن است از نظر فنی منطقی باشد، اما لزوماً با روش کار پروژه یکسان نیست.

برای جلوگیری از این مشکل، تیم مدل‌سازی باید پیش از شروع کار به مجموعه‌ای روشن از ورودی‌ها دسترسی داشته باشد؛ از جمله:

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

برون‌سپاری موفق نیازمند انتقال الزام است، نه صرفاً انتقال نقشه.

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

نبود استاندارد مشترک چگونه کیفیت مدل را غیرقابل پیش‌بینی می‌کند؟

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

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

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

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

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

استاندارد مشترک فقط برای منظم‌کردن مدل نیست؛ برای این است که همه طرف‌ها از ابتدا بدانند یک خروجی قابل قبول چه ویژگی‌هایی دارد.

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

چرا تحویل مدل بدون گردش‌کار مشخص مشکل را حل نمی‌کند؟

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

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

گردش‌کار باید حداقل روشن کند:

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

تحویل مدل یک رویداد است، اما BIM یک فرایند مستمر است.

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

هماهنگی بین‌رشته‌ای را نمی‌توان صرفاً به تولید مدل واگذار کرد

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

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

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

برای هماهنگی مؤثر باید مشخص باشد:

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

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

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

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

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

اگر مسئول تصمیم گیری مشخص نباشد، چند وضعیت رایج ایجاد می‌شود:

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

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

تداخل حل‌نشده همیشه نتیجه ضعف مدل نیست؛ گاهی مسئله اصلی نبود مرجع تصمیم گیری است.

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

تغییرات طراحی چگونه باید به مدل برون‌سپاری‌شده منتقل شوند؟

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

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

برای جلوگیری از این وضعیت باید مشخص باشد:

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

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

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

فاصله میان مدل‌ساز و تیم پروژه چگونه دوباره‌کاری ایجاد می‌کند؟

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

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

این فاصله زمانی و اطلاعاتی چند اثر رایج دارد:

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

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

برون‌سپاری زمانی پرهزینه می‌شود که مدل‌سازی از جریان تصمیم گیری پروژه جدا شود.

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

چرا کنترل کیفیت نباید فقط به خود مدل‌ساز وابسته باشد؟

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

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

این کنترل می‌تواند شامل مواردی مانند:

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

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

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

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

برون‌سپاری مدل‌سازی BIM چه زمانی موفق می‌شود؟

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

برون‌سپاری معمولاً زمانی موفق‌تر است که چند شرط از ابتدا برقرار باشد:

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

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

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

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

چه مسئولیت‌هایی باید داخل تیم پروژه باقی بمانند؟

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

مسئولیت‌هایی که بهتر است در داخل تیم پروژه باقی بمانند شامل این موارد هستند:

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

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

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

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

جمع‌بندی

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

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

برای تشخیص این تفاوت می‌توان چند سؤال ساده مطرح کرد:

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

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

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

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

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

مسیر مناسب به منشأ مشکل بستگی دارد:

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

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

مسیر اجرایی مرتبط

موضوع مقاله را به مسیر خدمت مناسب تبدیل کنید.

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

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