متن مقاله
مقدمه
بسیاری از شرکتها از Revit استفاده میکنند، مدلهای رشتههای مختلف را تولید میکنند، Template و استاندارد داخلی دارند و پروژههای خود را با الزامات BIM تحویل میدهند. با این حال، وجود این اجزا لزوماً نشان نمیدهد که فرایند BIM شرکت سریع، هماهنگ و قابل اتکاست.
ممکن است خروجی نهایی قابل قبول باشد، اما تیم برای تولید آن زمان زیادی صرف فعالیتهای دستی، اصلاحات تکراری، کنترل خطاهای مشابه یا هماهنگ کردن روش کار افراد مختلف کند. در چنین شرایطی، ناکارآمدی فرایند پشت تلاش بیشتر کارکنان پنهان میشود. پروژه تحویل داده میشود، اما هزینه واقعی تولید آن بیش از چیزی است که در برنامه یا گزارشهای رسمی دیده میشود.
از طرف دیگر، روشی که برای یک تیم کوچک یا نوع مشخصی از پروژه مناسب بوده است، ممکن است با افزایش تعداد کارکنان، تنوع پروژهها، تغییر الزامات تحویل یا توسعه ابزارهای داخلی کارایی سابق را نداشته باشد. استانداردها بهتدریج با روش واقعی کار فاصله میگیرند، استثناها بیشتر میشوند و کیفیت خروجی به تجربه چند فرد خاص وابسته میماند.
بنابراین ارزیابی BIM نباید فقط به این پرسش محدود شود که «آیا شرکت از BIM استفاده میکند؟» پرسش مهمتر این است که شرکت با چه میزان زمان، خطا، دوبارهکاری و وابستگی به افراد به خروجی مورد انتظار میرسد.
این همان نقطهای است که بررسی نیاز به بهینهسازی BIM آغاز میشود.
بهینهسازی BIM چیست؟
بهینهسازی BIM فرایندی برای بررسی و بهبود عملکرد ساختاری است که یک شرکت از قبل برای اجرای BIM ایجاد کرده است. در این فرایند، روشهای مدلسازی، مستندسازی، هماهنگی، کنترل کیفیت، مدیریت اطلاعات و استفاده از ابزارها بر اساس شواهد واقعی پروژه بررسی میشوند تا مشخص شود کدام بخشها زمان، خطا، دوبارهکاری یا ناپایداری غیرضروری ایجاد میکنند.
نقطه شروع بهینهسازی، وجود یک BIM قابل استفاده است. شرکت میتواند پروژه تولید و تحویل دهد، نقشها و روشهای کاری تا حدی شکل گرفتهاند و تیم تجربه اجرای BIM دارد؛ اما عملکرد این ساختار با نیاز فعلی سازمان یا پروژهها متناسب نیست. بنابراین هدف، ساختن BIM از ابتدا نیست، بلکه اصلاح قابلیتی است که وجود دارد اما میتواند بهتر عمل کند.
این اصلاح ممکن است به یک فعالیت پرتکرار محدود باشد یا چند بخش متصل از یک گردشکار را دربر بگیرد. برای مثال، منشأ دوبارهکاری میتواند در روش مدلسازی، Template، Family، زمان تبادل مدلها، مسئولیت کنترل یا نحوه ثبت اطلاعات قرار داشته باشد. راهحل نیز باید متناسب با همان علت انتخاب شود.
بهینهسازی زمانی اتفاق میافتد که تغییر ایجادشده فقط متفاوت یا جدید نباشد، بلکه عملکرد فرایند را بهبود دهد. این بهبود باید در شرایط واقعی کار دیده شود؛ برای مثال تیم همان خروجی را با زمان کمتر، خطای محدودتر، هماهنگی بهتر یا کیفیت یکنواختتر تولید کند.
بهینهسازی BIM یعنی بهبود قابل سنجش عملکرد BIM موجود، نه صرفاً تغییر ابزارها و فایلها.
اگر این مسئله در یک شرکت یا پروژه واقعی دیده میشود، خدمت بهینهسازی BIM مسیر تشخیص گلوگاه، آزمون اصلاح و سنجش نتیجه را توضیح میدهد.
تفاوت پیادهسازی BIM با بهینهسازی BIM چیست؟
پیادهسازی و بهینهسازی BIM هر دو میتوانند شامل اصلاح فرایندها، تدوین استانداردها، آموزش تیم و توسعه منابع داخلی باشند؛ اما نقطه شروع و نتیجه مورد انتظار آنها یکسان نیست.
در پیادهسازی BIM، شرکت هنوز روش مشترک و قابل تکراری برای اجرای پروژههای BIM ندارد. ممکن است بعضی کارکنان از Revit استفاده کنند یا چند مدل تولید شده باشد، اما نقشها، استانداردها، روش هماهنگی، کنترل کیفیت و ساختار تحویل هنوز بهصورت منسجم شکل نگرفتهاند. هدف پیادهسازی، ایجاد این قابلیت از پایه و تبدیل BIM به روش اجرایی شرکت است.
در بهینهسازی، قابلیت BIM از قبل وجود دارد. تیم با روش مشخصی پروژه را آغاز، مدلسازی، هماهنگ و تحویل میدهد؛ اما بخشی از این روش کند، پرخطا، بیش از حد دستی یا نامتناسب با شرایط فعلی شده است. هدف در اینجا ایجاد ساختار جدید نیست، بلکه ارتقای عملکرد ساختار موجود است.
| معیار | پیادهسازی BIM | بهینهسازی BIM |
|---|---|---|
| نقطه شروع | نبود روش BIM منسجم | وجود روش BIM قابل اجرا |
| مسئله اصلی | قابلیت لازم هنوز شکل نگرفته است | قابلیت موجود عملکرد مطلوبی ندارد |
| تمرکز | ایجاد نقش، استاندارد، فرایند و توان تیم | شناسایی گلوگاه و اصلاح عملکرد |
| نتیجه | روش BIM قابل تکرار | روش BIM سریعتر، پایدارتر و قابل کنترلتر |
مرز این دو به تعداد نرمافزارها، مدلها یا کارکنان مسلط به Revit وابسته نیست. معیار اصلی این است که آیا شرکت از قبل یک روش مشترک برای اداره پروژه BIM دارد یا خیر.
پیادهسازی، قابلیت BIM را ایجاد میکند؛ بهینهسازی، عملکرد قابلیت موجود را ارتقا میدهد.
چرا یک فرایند BIM پس از مدتی به بهینهسازی نیاز پیدا میکند؟
یک فرایند BIM ممکن است هنگام طراحی اولیه با تعداد کارکنان، نوع پروژهها و الزامات آن زمان کاملاً متناسب باشد؛ اما این تناسب دائمی نیست. شرکت تغییر میکند، درحالیکه استانداردها، منابع و روشهای اجرایی همیشه با همان سرعت تغییر نمیکنند.
با افزایش تعداد پروژهها و اعضای تیم، روشهایی که قبلاً به ارتباط مستقیم و تجربه چند فرد متکی بودند بهتدریج به گلوگاه تبدیل میشوند. انتقال شفاهی روش کار دیگر کافی نیست، کنترل همه مدلها توسط یک نفر دشوار میشود و تفاوت میان روش افراد یا پروژهها افزایش پیدا میکند.
نوع پروژهها و الزامات تحویل نیز ممکن است تغییر کند. Template، Family، پارامترها یا روش هماهنگیای که برای پروژههای قبلی مناسب بوده است، الزاماً از پروژهای با مقیاس، رشتهها یا خروجیهای متفاوت پشتیبانی نمیکند. در این شرایط، تیم برای ادامه کار استثناها و راهحلهای موقت ایجاد میکند.
این اصلاحات موضعی در ابتدا مشکل را حل میکنند، اما با گذشت زمان روی یکدیگر انباشته میشوند. نتیجه میتواند استانداردی پر از استثنا، چند نسخه متفاوت از منابع داخلی، گردشکاری با مراحل اضافی و ابزارهایی باشد که فقط بعضی افراد نحوه استفاده از آنها را میدانند.
بنابراین نیاز به بهینهسازی الزاماً نشانه طراحی ضعیف فرایند اولیه نیست. گاهی ساختار موجود برای شرایط گذشته مناسب بوده، اما همراه با سازمان و پروژههای آن رشد نکرده است. این موضوع در مقاله چرا فرایندهای BIM با رشد پروژه و تیم بهتدریج ناکارآمد میشوند؟ با جزئیات بیشتری بررسی شده است.
فرایند BIM زمانی ناکارآمد میشود که شرایط کار تغییر کند، اما روش اجرا بدون بازبینی باقی بماند.
چرا هر اصلاح فنی، ابزار جدید یا اتوماسیون را نمیتوان بهینهسازی BIM دانست؟
تغییر یک Template، اصلاح چند Family، خرید نرمافزار جدید یا نوشتن اسکریپت Dynamo میتواند مفید باشد، اما انجام این اقدامات بهتنهایی به معنای بهینهسازی BIM نیست. ارزش یک تغییر به جدید یا پیشرفته بودن آن وابسته نیست؛ باید مشخص باشد کدام مشکل را حل میکند و چه اثری بر عملکرد واقعی تیم دارد.
برای مثال، کندی یک مدل ممکن است از Familyهای سنگین ناشی شود، اما میتواند نتیجه جزئیات بیش از نیاز، ساختار نامناسب فایلها، Viewهای کنترلنشده یا روش نادرست Worksharing نیز باشد. اگر پیش از تشخیص علت، فقط چند Family سبکتر شوند، ممکن است بخشی از نشانه کاهش پیدا کند، اما گلوگاه اصلی باقی بماند.
مسیر تشخیص مرحلهای این وضعیت در مقاله چرا مدل Revit سنگین میشود و چگونه علت واقعی آن را پیدا کنیم؟ توضیح داده شده است.
اتوماسیون نیز همیشه پاسخ مناسبی نیست. فعالیتی که مراحل غیرضروری، ورودی نامعتبر یا مسئولیت نامشخص دارد، با خودکارشدن به فرایند بهتری تبدیل نمیشود. ابزار فقط همان روش را سریعتر اجرا میکند و گاهی وابستگی تازهای به سازنده یا نگهدارنده آن به وجود میآورد. برای تصمیم گیری درباره توسعه ابزار، مقاله کدام فرایندهای Revit ارزش اتوماسیون دارند و کدامها ندارند؟ معیارهای عملی این انتخاب را توضیح میدهد.
سه تمایز باید روشن بماند:
رفع یک خطا ≠ اصلاح علت تکرار آن
افزودن ابزار ≠ بهبود گردشکار
خودکارسازی فعالیت ≠ بهینهسازی فرایند
بهینهسازی از انتخاب راهحل آغاز نمیشود. ابتدا باید مسئله، علت، دامنه اثر و معیار نتیجه مشخص شوند. سپس میتوان تصمیم گرفت که راهحل مناسب حذف یک مرحله، اصلاح مسئولیت، بازطراحی استاندارد، آموزش هدفمند یا توسعه ابزار است.
تغییر زمانی بهینهسازی محسوب میشود که یک گلوگاه واقعی را با نتیجهای قابل مشاهده کاهش دهد.
یک شرکت در چه مرحلهای به بهینهسازی BIM نیاز پیدا میکند؟
بهینهسازی زمانی معنا پیدا میکند که BIM از مرحله آزمایش یا استفاده پراکنده عبور کرده و به بخشی از روش واقعی اجرای پروژههای شرکت تبدیل شده باشد. سازمان لازم نیست به بالاترین سطح بلوغ BIM رسیده باشد، اما باید فرایندی وجود داشته باشد که بتوان عملکرد آن را مشاهده، مقایسه و اصلاح کرد.
وجود چند کاربر Revit یا تولید چند مدل برای رسیدن به این مرحله کافی نیست. شرکت زمانی وارد محدوده بهینهسازی میشود که بخشهایی از BIM بهصورت تکرارشونده اجرا شوند؛ برای مثال پروژهها با Template مشخص آغاز شوند، روشهایی برای مدلسازی و مستندسازی وجود داشته باشد، مسئولیتهای اصلی شناخته شده باشند و تیم تجربه تحویل خروجی BIM را به دست آورده باشد.
شرایط معمول این مرحله عبارتاند از:
BIM روش اصلی یا تثبیتشده تولید و تحویل در بخشی از شرکت است.
تیم میتواند پروژه را با ساختار موجود اجرا کند.
استانداردها، منابع و گردشکارهای مشخصی از قبل وجود دارند.
مشکلات مشابه در بیش از یک فعالیت، مرحله یا پروژه مشاهده میشوند.
شرکت شواهد کافی برای مقایسه عملکرد فعلی با وضعیت مطلوب دارد.
مدیریت و تیم اجرایی امکان تغییر روش موجود را پذیرفتهاند.
نقطه تعیینکننده این نیست که فرایند فعلی شکست خورده باشد. ممکن است شرکت همچنان پروژهها را تحویل دهد، اما برای حفظ این عملکرد به زمان اضافه، کنترل دستی، اصلاحات مکرر یا حضور دائمی افراد کلیدی وابسته باشد.
در این مرحله، پرسش سازمان دیگر «چگونه BIM را آغاز کنیم؟» نیست؛ بلکه «چگونه BIM موجود را با اتلاف کمتر و قابلیت اطمینان بیشتر ادامه دهیم؟» است.
بهینهسازی از زمانی آغاز میشود که یک روش BIM قابل اجرا وجود دارد، اما عملکرد آن دیگر متناسب با نیاز شرکت نیست.
نشانههای نیاز به بهینهسازی BIM در یک شرکت
نیاز به بهینهسازی همیشه با شکست پروژه یا ردشدن خروجیها آشکار نمیشود. در بسیاری از شرکتها، تیم با صرف زمان بیشتر، کنترلهای دستی و تلاش افراد باتجربه مشکلات فرایند را جبران میکند. در نتیجه، پروژه تحویل داده میشود، اما اتلاف و ناپایداری روش تولید پشت نتیجه نهایی پنهان میماند.
یک مشکل منفرد نیز لزوماً نشانه نیاز به بهینهسازی نیست. هر پروژه میتواند با شرایط خاص، خطای انسانی یا مسئلهای پیشبینینشده روبهرو شود. موضوع زمانی اهمیت ساختاری پیدا میکند که یک الگو در چند مرحله، چند نفر یا چند پروژه تکرار شود.
برای ارزیابی هر نشانه باید چهار پرسش مطرح شود:
آیا این مسئله مرتب تکرار میشود؟
چه میزان از زمان یا ظرفیت تیم را مصرف میکند؟
آیا نتیجه کار به حضور افراد مشخص وابسته است؟
آیا اصلاح هر مورد از تکرار دوباره آن جلوگیری میکند؟
اگر یک مسئله تکرارشونده باشد، هزینه قابل توجهی ایجاد کند و با اصلاحهای موردی از بین نرود، احتمالاً منشأ آن در خود فرایند BIM قرار دارد. این منشأ میتواند در روش تولید، استانداردها، منابع داخلی، هماهنگی، کنترل کیفیت، ساختار اطلاعات یا نحوه استفاده از ابزارها باشد.
نشانههای بعدی به شرکت کمک میکنند ناکارآمدی را پیش از تبدیل شدن به تأخیر جدی، افت کیفیت یا وابستگی گسترده شناسایی کند. این نشانهها تشخیص نهایی نیستند، اما مشخص میکنند کدام بخشها باید با شواهد دقیقتر بررسی شوند. اگر تیم از نظر فنی توانمند است اما تولید همچنان کند باقی میماند، مقاله چرا تیم Revit با وجود نیروهای ماهر باز هم کند کار میکند؟ این الگو را از زاویه بهرهوری تیم بررسی میکند.
نشانه مهم، یک خطای منفرد نیست؛ الگویی است که سازمان بارها هزینه آن را پرداخت میکند.
وقتی زمان زیادی صرف فعالیتهای تکراری و دستی میشود
یکی از روشنترین نشانههای نیاز به بهینهسازی BIM زمانی است که بخش قابل توجهی از ظرفیت تیم صرف فعالیتهایی میشود که با الگویی مشابه بارها تکرار میشوند، بدون اینکه هر بار تصمیم تخصصی تازهای ایجاد کنند.
تنظیم مکرر Viewها و Sheetها، تکمیل یا اصلاح گروهی پارامترها، کنترل نامگذاری، آمادهسازی خروجیها، انتقال اطلاعات و تهیه گزارشهای مشابه از نمونههای رایج این وضعیت هستند. هرکدام از این فعالیتها ممکن است در یک نوبت فقط چند دقیقه زمان ببرند، اما تکرار آنها توسط چند نفر و در چند پروژه، هزینه پنهان قابل توجهی ایجاد میکند.
برای ارزیابی این نشانه نباید فقط زمان انجام یک نمونه را در نظر گرفت. اثر واقعی از ترکیب چهار عامل به دست میآید:
زمان لازم برای هر بار انجام فعالیت؛
تعداد دفعات تکرار؛
تعداد افراد درگیر؛
تعداد پروژههایی که همان روش را استفاده میکنند.
هر فعالیت دستی الزاماً ناکارآمد نیست. بعضی کارها به قضاوت تخصصی، بررسی شرایط پروژه یا تصمیم انسانی نیاز دارند و خودکارسازی آنها منطقی نیست. مسئله زمانی ایجاد میشود که یک فعالیت دارای قواعد نسبتاً ثابت باشد، مرتب تکرار شود و ارزش تازهای متناسب با زمان مصرفشده تولید نکند.
در چنین شرایطی، راهحل میتواند حذف یک مرحله غیرضروری، استانداردکردن ورودیها، اصلاح Template یا خودکارسازی هدفمند باشد. انتخاب میان این گزینهها باید پس از بررسی خود فعالیت انجام شود.
کار دستی زمانی به گلوگاه تبدیل میشود که تکرار آن ظرفیت تیم را مصرف کند، بدون اینکه به تصمیم یا کیفیت بیشتری منجر شود.
وقتی اصلاحات مشابه در مدلها و نقشهها دائماً تکرار میشوند
تکرار یک نوع اصلاح در مراحل مختلف پروژه یا در چند پروژه متوالی معمولاً نشان میدهد که مشکل به یک فایل یا عملکرد یک فرد محدود نیست. در این وضعیت، تیم خطا را برطرف میکند، اما فرایندی که آن خطا را تولید کرده بدون تغییر باقی میماند.
برای مثال، ممکن است نام Viewها مرتب اصلاح شود، اطلاعات مشخصی در Sheetها یا پارامترها ناقص بماند، تنظیمات گرافیکی مشابه بارها تغییر کند یا یک نوع ایراد مدلسازی در کنترلهای مختلف دوباره مشاهده شود. رسیدگی موردی باعث میشود خروجی فعلی قابل تحویل شود، اما احتمال ایجاد همان مشکل در چرخه بعدی را کاهش نمیدهد.
تکرار اصلاحات معمولاً به یکی از این ضعفها اشاره میکند:
استاندارد یا مسئولیت بهاندازه کافی روشن نیست؛
Template و Family از روش مورد انتظار پشتیبانی نمیکنند؛
کنترل کیفیت دیرتر از نقطه ایجاد خطا انجام میشود؛
بازخورد کنترل به روش تولید بازنمیگردد؛
تیم برای یک فعالیت مشترک روش مرجع ندارد.
اهمیت این مسئله فقط در تعداد خطاها نیست. یک ایراد کوچک ممکن است در چندین View، Sheet، مدل یا رشته گسترش پیدا کند و اصلاح آن در مرحله تحویل چند برابر بیشتر از جلوگیری از ایجادش هزینه داشته باشد.
کنترل کیفیت نباید فقط خطاها را پیدا کند؛ باید الگوهای تکرار را نیز آشکار سازد و به اصلاح روش تولید منتهی شود. اگر گزارشهای کنترل مرتب مشکل مشابهی را ثبت میکنند، اما استاندارد، منبع یا گردشکار تغییر نمیکند، سازمان بارها هزینه یک علت ثابت را پرداخت میکند.
وقتی اصلاحی دائماً تکرار میشود، پرسش اصلی این نیست که چگونه آن را سریعتر انجام دهیم؛ باید پرسید چرا دوباره ایجاد میشود.
وقتی افراد مختلف یک فعالیت BIM را به روشهای متفاوت انجام میدهند
تفاوت روش افراد همیشه به معنای اشتباهبودن یکی از آنها نیست. بسیاری از مسائل طراحی و مدلسازی به قضاوت تخصصی نیاز دارند و نمیتوان برای همه شرایط یک پاسخ ثابت تعیین کرد. مشکل زمانی ایجاد میشود که فعالیتی تکرارشونده و قابل استانداردسازی باشد، اما هر فرد آن را بر اساس ترجیح یا تجربه شخصی خود انجام دهد.
برای مثال، ممکن است اعضای تیم Viewها را با ساختارهای متفاوت ایجاد کنند، اطلاعات یکسان را در پارامترهای مختلف وارد کنند، Sheetها را به روشهای متفاوت سازمان دهند یا برای یک وضعیت مشابه از Familyها و روشهای مدلسازی گوناگون استفاده کنند. همه این روشها ممکن است در ظاهر خروجی قابل قبولی تولید کنند، اما نتیجه نهایی دیگر قابل پیشبینی و کنترل نخواهد بود.
این ناهماهنگی چند پیامد مستقیم دارد:
انتقال مدل یا مسئولیت میان افراد دشوار میشود؛
کنترل کیفیت باید چند روش متفاوت را بررسی کند؛
آموزش نیروهای جدید به توضیحات فردی وابسته میماند؛
انتقال کارکنان میان پروژهها زمان بیشتری میگیرد؛
کیفیت خروجی به حضور افراد باتجربه وابسته میشود.
راهحل، حذف کامل اختیار افراد نیست. شرکت باید مشخص کند کدام فعالیتها به روش مرجع نیاز دارند و در کدام بخشها تصمیم تخصصی باید آزاد باقی بماند. روش مرجع نیز باید دلیل، ورودی، خروجی و معیار کنترل روشن داشته باشد؛ نه اینکه صرفاً به یک دستور غیرقابلتوضیح تبدیل شود.
فعالیتهای تکرارشونده باید قابل انتقال و کنترل باشند؛ تصمیمهای فردی باید برای جایی باقی بمانند که واقعاً به قضاوت تخصصی نیاز است.
وقتی استانداردها، Templateها و Familyها با روش واقعی کار هماهنگ نیستند
استانداردها و منابع داخلی باید انجام کار را سادهتر، یکنواختتر و قابل کنترلتر کنند. اگر تیم برای پیشبرد پروژه مرتب آنها را دور بزند، تغییر دهد یا با فایلها و روشهای موازی جایگزین کند، احتمالاً ساختار موجود دیگر با نیاز واقعی شرکت هماهنگ نیست.
این فاصله معمولاً بهتدریج ایجاد میشود. ممکن است Template برای نوع دیگری از پروژه طراحی شده باشد، استاندارد نامگذاری الزامات جدید تحویل را پوشش ندهد، Shared Parameterهای موجود با اطلاعات موردنیاز پروژهها سازگار نباشند یا کتابخانه Familyها آنقدر پراکنده شده باشد که پیدا کردن منبع معتبر دشوار شود.
نشانه مهم، افزایش استثناها و راهحلهای موقت است. برای مثال:
هر پروژه نسخه جداگانهای از Template ایجاد میکند؛
اعضای تیم Family موردنیاز را دوباره میسازند؛
بخشی از استاندارد فقط روی کاغذ رعایت میشود؛
فایلهای مختلف با عنوان «نسخه نهایی» در گردش هستند؛
کاربران برای انجام کار روزمره به دستورهای شفاهی وابستهاند.
وجود استثنا همیشه نامطلوب نیست؛ پروژهها تفاوتهای واقعی دارند. مسئله زمانی ایجاد میشود که استثناها از قواعد اصلی بیشتر شوند یا شرکت نتواند تشخیص دهد کدام منبع و روش معتبر است.
بهینهسازی در این شرایط الزاماً به معنی ساختن همهچیز از ابتدا نیست. ممکن است حذف منابع بلااستفاده، اصلاح چند قاعده، یکپارچهکردن نسخهها، بازطراحی بخشهای پرمصرف و تعیین مسئول نگهداری کافی باشد.
استاندارد زمانی ارزشمند است که از کار واقعی تیم پشتیبانی کند؛ اگر تیم دائماً مجبور باشد آن را دور بزند، خود استاندارد به بخشی از مسئله تبدیل شده است.
وقتی مدلها سنگین، کند یا دشوار برای مدیریت میشوند
کندشدن مدل یکی از قابل مشاهدهترین نشانههای ناکارآمدی است، اما علت آن همیشه حجم فایل یا ضعیفبودن سختافزار نیست. عملکرد مدل میتواند تحت تأثیر سطح جزئیات بیش از نیاز، Familyهای پیچیده، Viewهای متعدد و کنترلنشده، لینکها و فایلهای واردشده، هشدارهای انباشته، ساختار نامناسب Worksharing یا اطلاعاتی قرار گیرد که دیگر برای پروژه کاربردی ندارند.
مسئله زمانی جدی میشود که عملکرد مدل مستقیماً روش کار تیم را تغییر دهد. بازشدن فایل، Synchronize، بارگذاری لینکها یا جابهجایی میان Viewها زمان زیادی میگیرد؛ کاربران از بعضی عملیات ضروری صرفنظر میکنند؛ یا انجام یک کنترل ساده به دلیل انتظارهای مکرر طولانی میشود. در این مرحله، کندی دیگر فقط یک ناراحتی فنی نیست و به کاهش ظرفیت تولید تبدیل شده است.
اگر واکنش اولیه خرید Workstation قویتر است، مقاله قبل از خرید سختافزار قویتر، چه چیزهایی را در مدل Revit بررسی کنیم؟ معیارهای جدا کردن محدودیت واقعی سیستم از مشکل مدل و Worksharing را بررسی میکند.
با این حال، سبککردن مدل نباید با حذف تصادفی اطلاعات یا کاهش کیفیت خروجی انجام شود. ابتدا باید مشخص شود:
کدام اطلاعات برای طراحی، هماهنگی، مستندسازی یا تحویل ضروریاند؛
پیچیدگی در کدام عناصر یا بخشها ایجاد شده است؛
مشکل از خود مدل است یا از ساختار فایلها، لینکها و محیط همکاری؛
کدام اصلاح بیشترین اثر را بدون آسیبزدن به نیاز پروژه دارد.
گاهی نیز ارتقای سختافزار فقط نشانه را موقتاً پنهان میکند و ساختار ناکارآمد همچنان با پروژه رشد میکند.
مدل زمانی نیاز به بهینهسازی دارد که پیچیدگی آن بیش از ارزشی باشد که برای پروژه ایجاد میکند و این اختلاف، زمان روزانه تیم را مصرف کند.
وقتی هماهنگی بین رشتهها مرتب مشکلات مشابهی را آشکار میکند
هماهنگی بین رشتهها فقط برای پیدا کردن تداخلها نیست. نتایج هماهنگی باید به تیمها نشان دهند خطاها چگونه ایجاد میشوند و چه تغییری در روش تولید میتواند از تکرار آنها جلوگیری کند. اگر در هر چرخه دوباره همان نوع مشکلات مشاهده شود، فرایند در حال کشف خطاست، اما هنوز از ایجاد مجدد آن جلوگیری نمیکند.
برای مثال، ممکن است بازشوهای سازهای دیر تعریف شوند، مسیرهای تأسیسات مرتب با عناصر سازه تداخل داشته باشند، سطوح و محورهای مشترک میان مدلها یکسان نباشند یا فضای لازم برای نصب و نگهداری تجهیزات در زمان مناسب کنترل نشود. افزایش تعداد جلسات یا اجرای مکرر Clash Detection الزاماً این مسائل را حل نمیکند. تفاوت میان گزارش تداخل و هماهنگی قابلکنترل در مقاله چرا Clash Detection بهتنهایی برای هماهنگی BIM کافی نیست؟ بررسی شده است.
در چنین شرایطی باید الگوی مشکلات بررسی شود:
آیا مدلها در زمان مناسب مبادله میشوند؟
آیا هر رشته پیش از انتشار، کنترلهای داخلی لازم را انجام میدهد؟
آیا مسئول ایجاد و تأیید عناصر مشترک مشخص است؟
آیا تیمها از مبناها و اطلاعات معتبر یکسان استفاده میکنند؟
آیا برای بستن هر مسئله، مسئول، مهلت و معیار پذیرش وجود دارد؟
اگر پاسخ این پرسشها روشن نباشد، مشکل از توانایی نرمافزار هماهنگی نیست؛ بلکه در روش تولید، تبادل و پیگیری مسائل قرار دارد.
بهینهسازی زمانی رخ میدهد که نتیجه جلسات و گزارشهای هماهنگی به اصلاح روش کار بازگردد. خطای پرتکرار باید به تغییر در مسئولیت، زمان تبادل، استاندارد مدلسازی یا کنترل پیش از انتشار منجر شود.
هماهنگی مؤثر فقط مشکلات را پیدا نمیکند؛ فرایند تولید را طوری اصلاح میکند که همان مشکلات کمتر تکرار شوند.
وقتی فرایند میان کار دستی و اتوماسیونهای پراکنده گرفتار شده است
وجود اسکریپتهای Dynamo، افزونههای Revit یا ابزارهای داخلی لزوماً نشان نمیدهد که فرایند شرکت بهینه شده است. در بعضی سازمانها، ابزارهای مختلف بهتدریج و برای حل نیازهای فوری پروژهها ساخته میشوند، اما ارتباط، نسخه معتبر و جایگاه آنها در گردشکار مشخص نیست.
در این وضعیت، اعضای تیم ممکن است ندانند یک فعالیت باید به روش دستی انجام شود یا با ابزار خودکار. هر پروژه نسخه متفاوتی از اسکریپت را نگهداری میکند، ابزار فقط روی بعضی فایلها کار میکند یا اجرای آن به حضور سازنده وابسته است. گاهی نیز کاربر ابتدا ابزار را اجرا میکند، نتیجه را دستی کنترل میکند و پس از بروز خطا بخشی از فعالیت را دوباره انجام میدهد.
نشانههای رایج اتوماسیون پراکنده عبارتاند از:
چند نسخه بدون مرجع مشخص از یک ابزار وجود دارد؛
ورودیها و محدودیتهای ابزار مستند نشدهاند؛
تغییر Template یا Family باعث ازکارافتادن اسکریپت میشود؛
مسئول آزمون، انتشار و نگهداری ابزار مشخص نیست؛
تیم به دلیل بیاعتمادی، روش دستی را در کنار ابزار ادامه میدهد.
در چنین شرایطی، مسئله فقط کیفیت کدنویسی نیست. فعالیت، ورودیها، خروجیها، استثناها و مالک فرایند باید ابتدا روشن شوند. سپس ابزارها میتوانند یکپارچه، مستند و متناسب با روش رسمی کار شرکت شوند.
اتوماسیون باید بخشی پایدار از گردشکار باشد؛ نه مجموعهای از راهحلهای شخصی که تنها در شرایط خاص و با حضور افراد مشخص کار میکنند.
ابزار خودکار زمانی ارزش ایجاد میکند که وابستگی به کار دستی را کاهش دهد، نه اینکه وابستگی تازهای به خود ابزار یا سازنده آن ایجاد کند.
وقتی رشد تیم یا تعداد پروژهها باعث افت عملکرد میشود
فرایندی که برای یک تیم کوچک یا یک پروژه بهخوبی کار میکند، الزاماً در مقیاس بزرگتر همان عملکرد را حفظ نمیکند. یکی از نشانههای نیاز به بهینهسازی زمانی است که افزایش کارکنان یا پروژههای همزمان بهجای افزایش متناسب ظرفیت، باعث کندی هماهنگی، دشوارشدن کنترل و نوسان کیفیت میشود.
در یک تیم کوچک، انتقال روش کار میتواند شفاهی باشد و مدیر BIM شخصاً بیشتر مدلها، منابع و تصمیمها را کنترل کند. با رشد تیم، همین روش به گلوگاه تبدیل میشود. پرسشهای مشابه بارها تکرار میشوند، تأییدها در انتظار یک فرد باقی میمانند و کیفیت خروجی به میزان دسترسی او وابسته میشود. در پروژهای که تحت فشار زمانی است، پیش از افزایش ظرفیت باید مشخص شود مشکل واقعاً کمبود نیرو است یا ضعف فرایند.
افزایش تعداد پروژهها نیز میتواند چند روش موازی ایجاد کند. هر پروژه نسخه خود را از Template، Familyها، استانداردها و ابزارها توسعه میدهد و پس از مدتی شرکت نمیتواند به سادگی مشخص کند کدام نسخه باید مبنای پروژه بعدی باشد. انتقال کارکنان میان پروژهها دشوارتر میشود و تجربه بهدستآمده در یک تیم الزاماً به تیمهای دیگر منتقل نمیشود.
نشانههای اصلی این وضعیت عبارتاند از:
کاهش بهرهوری هر فرد با بزرگترشدن تیم؛
افزایش زمان کنترل و هماهنگی؛
وابستگی تصمیمها به چند فرد کلیدی؛
تفاوت محسوس کیفیت میان پروژهها؛
تکثیر منابع و روشهای ناسازگار.
این مشکلات به معنای اشتباه بودن رشد شرکت نیستند. آنها نشان میدهند ساختاری که برای مقیاس قبلی مناسب بوده، برای تعداد جدید پروژهها و افراد طراحی نشده است.
اگر رشد سازمان باعث کاهش قابلیت کنترل و تکرارپذیری BIM شود، خود فرایند نیز باید همراه با سازمان رشد کند.
چرا نشانه قابل مشاهده همیشه علت اصلی مشکل نیست؟
نشانهها محل مشاهده ناکارآمدی را نشان میدهند، نه الزاماً محل ایجاد آن را. اگر راهحل مستقیماً بر اساس نخستین نشانه انتخاب شود، ممکن است مشکل موقتاً کاهش پیدا کند اما دوباره در همان بخش یا نقطهای دیگر ظاهر شود.
برای مثال، کندی تولید نقشه میتواند به تنظیمات نامناسب Template مربوط باشد، اما ممکن است از تغییرات دیرهنگام طراحی، ورود ناقص اطلاعات یا روش مدلسازی ناهماهنگ ناشی شود. تداخلهای تکراری نیز الزاماً با اجرای بیشتر Clash Detection حل نمیشوند؛ شاید زمان تبادل مدلها، مسئولیت ایجاد بازشوها یا معیار بستن مسائل روشن نباشد.
مقاله چرا تولید نقشه از مدل BIM بیش از حد زمان میبرد؟ این گلوگاه را در کل زنجیره مستندسازی بررسی میکند.
| نشانه قابل مشاهده | علتهای احتمالی |
|---|---|
| مدل کند | جزئیات اضافی، Family پیچیده، ساختار نامناسب فایل یا لینک |
| اصلاحات تکراری | استاندارد مبهم، کنترل دیرهنگام یا منبع پایه نامناسب |
| هماهنگی ضعیف | مسئولیت نامشخص، تبادل دیرهنگام یا مبنای مشترک ناهماهنگ |
| کار دستی زیاد | گردشکار غیرضروری، داده نامنظم یا نبود ابزار مناسب |
| کیفیت متغیر | روشهای فردی، آموزش ناکافی یا کنترل غیرقابل تکرار |
تشخیص علت به شواهد نیاز دارد. مدلها و خروجیها باید در کنار گزارشهای کنترل، سوابق اصلاح، زمان فعالیتها و تجربه اعضای تیم بررسی شوند. هدف این نیست که دورترین علت نظری پیدا شود؛ باید عاملی شناسایی شود که هم در ایجاد مشکل نقش دارد و هم با تغییر آن بتوان نتیجه را بهبود داد.
گاهی نیز یک نشانه حاصل چند علت مرتبط است. برای مثال، Template نامناسب، آموزش ناکافی و نبود کنترل اولیه میتوانند همزمان باعث خطاهای مستندسازی شوند. در چنین وضعیتی، اصلاح تنها یکی از آنها نتیجه پایدار ایجاد نمیکند.
بهینهسازی مؤثر از جایی آغاز میشود که سازمان بهجای سریعترین پاسخ، علت قابل اثبات مسئله را پیدا کند.
چه بخشهایی از فرایند BIM میتوانند بهینهسازی شوند؟
بهینهسازی BIM فقط به سبککردن مدل یا سریعترکردن کار در Revit محدود نیست. گلوگاه میتواند در هر بخشی ایجاد شود که تصمیم، اطلاعات یا مدل از طریق آن تولید، بررسی، مبادله و تحویل میشود. بنابراین دامنه اصلاح باید بر اساس محل ایجاد مسئله تعیین شود.
| حوزه | نمونه مسئله |
|---|---|
| تصمیم گیری و مسئولیت | مالک فرایند، مرجع تأیید یا مسئول اصلاح مشخص نیست |
| راهاندازی پروژه | ساختار فایلها، مدلها، دسترسیها و منابع هر بار از ابتدا تعیین میشود |
| مدلسازی | روشهای موازی، جزئیات اضافی یا وابستگی به تصمیمهای فردی وجود دارد |
| مستندسازی | View، Sheet، جدول و دیتیل با اصلاح دستی زیاد تولید میشوند |
| استاندارد و منابع | Template، Family، پارامترها و قواعد با نیاز واقعی پروژه هماهنگ نیستند |
| هماهنگی | مسائل شناسایی میشوند، اما مسئولیت و معیار بستن آنها روشن نیست |
| کنترل کیفیت | خطا دیر کشف میشود یا نتیجه کنترل به اصلاح روش تولید بازنمیگردد |
| اطلاعات | دادهها ناقص، پراکنده، تکراری یا در پارامترهای نامناسب ثبت میشوند |
| ابزار و اتوماسیون | فعالیتهای پرتکرار دستیاند یا ابزارهای موجود قابل اتکا و نگهداری نیستند |
| توان تیم | اجرای روش به دانش چند نفر وابسته است و بهدرستی منتقل نمیشود |
این حوزهها از یکدیگر جدا نیستند. برای مثال، خطای اطلاعاتی ممکن است از Family نامناسب آغاز شود، در کنترل کیفیت دیده نشود و هنگام تحویل باعث اصلاح چندین مدل و Sheet شود. در چنین وضعیتی، تمرکز بر آخرین محل مشاهده خطا کافی نیست.
بهینهسازی نیز الزاماً همه حوزهها را همزمان دربر نمیگیرد. دامنه باید بهاندازهای گسترده باشد که علت مسئله و بخشهای وابسته به آن را پوشش دهد، اما آنقدر وسیع نباشد که نتیجه هر تغییر قابل تشخیص نباشد.
بخش مناسب برای شروع، جایی نیست که مشکل بیشتر دیده میشود؛ جایی است که اصلاح آن بیشترین اثر را بر کل فرایند میگذارد. اگر مشکل به Template، استاندارد یا گردشکار برمیگردد، مقاله استانداردها، Templateها و گردشکارهای BIM در چه مرحلهای باید تدوین شوند؟ توضیح میدهد چه زمانی یک اصلاح باید به روش پایدار سازمان تبدیل شود.
مشکل BIM محدود است یا به بازطراحی یک گردشکار نیاز دارد؟
همه مشکلات BIM به بازطراحی گسترده فرایند نیاز ندارند. اگر علت ناکارآمدی به یک فعالیت، منبع یا مرحله مشخص محدود باشد و سایر بخشهای مرتبط عملکرد قابل قبولی داشته باشند، اصلاح هدفمند معمولاً کمریسکتر و قابلاندازهگیریتر است.
برای مثال، ممکن است یک Family پرکاربرد باعث کندی مدل شود، تنظیمات بخشی از Template اصلاح دستی ایجاد کند یا یک فعالیت تکراری با ورودی و خروجی روشن برای اتوماسیون مناسب باشد. در این موارد، دامنه مسئله مشخص است و میتوان اثر اصلاح را بدون تغییر بخشهای دیگر بررسی کرد.
اما وقتی چند نشانه به یکدیگر متصلاند، اصلاح موضعی ممکن است فقط مشکل را جابهجا کند. اگر استاندارد با روش واقعی کار هماهنگ نیست، افراد مسیرهای متفاوتی دارند، کنترل کیفیت دیر انجام میشود و هماهنگی نیز خطاهای مشابه تولید میکند، احتمالاً خود گردشکار باید بررسی شود.
| اصلاح محدود | بازطراحی گردشکار |
|---|---|
| علت و دامنه مسئله مشخص است | چند علت و مرحله به یکدیگر وابستهاند |
| ورودی و خروجی فعالیت پایدار است | ورودی، مسئولیت یا خروجی مبهم است |
| سایر بخشها عملکرد مناسبی دارند | مشکل در چند بخش ظاهر میشود |
| اثر تغییر مستقیماً قابل سنجش است | اصلاح یک بخش بر بخشهای دیگر اثر میگذارد |
| استثناهای محدود وجود دارند | فرایند با راهحلهای موقت متعدد حفظ میشود |
بازطراحی گردشکار نیز به معنی کنار گذاشتن همه اجزای موجود نیست. بخشهای موفق میتوانند حفظ شوند و فقط ترتیب فعالیتها، مسئولیتها، نقاط کنترل، منابع یا ابزارهای مرتبط تغییر کنند.
اصل مناسب، انتخاب کوچکترین دامنهای است که بتواند علت مسئله و وابستگیهای واقعی آن را پوشش دهد. دامنه بیش از حد محدود، علت را حل نمیکند؛ دامنه بیش از حد گسترده نیز ریسک، هزینه و دشواری سنجش نتیجه را افزایش میدهد.
اصلاح باید بهاندازه مسئله گسترده باشد؛ نه کوچکتر از علت و نه بزرگتر از نیاز.
اگر ناکارآمدی از سطح یک فعالیت یا مدل فراتر رفته و موعد تحویل، چند رشته یا تصمیمهای اصلی پروژه را همزمان تحت تأثیر قرار داده است، مقاله وقتی پروژه BIM به بنبست میرسد، اصلاح را از کجا باید شروع کرد؟ منطق تشخیص گلوگاه و بازتنظیم اولویتها را برای وضعیتهای بحرانیتر توضیح میدهد.
مسیر بهینهسازی BIM از تشخیص تا تثبیت نتیجه چگونه است؟
بهینهسازی BIM نباید با اجرای همزمان مجموعهای از تغییرات آغاز شود. اگر چند استاندارد، ابزار و گردشکار بهطور همزمان اصلاح شوند، مشخص نخواهد بود کدام تغییر نتیجه ایجاد کرده و کدامیک مشکل تازهای به وجود آورده است. مسیر باید از شواهد واقعی شروع شود و به روشی برسد که در کار روزمره قابل تکرار باشد.
این مسیر معمولاً شامل هفت مرحله است:
مشاهده وضعیت موجود: مدلها، خروجیها، گزارشهای کنترل، سوابق اصلاح و تجربه تیم بررسی میشوند.
تعریف مسئله: نشانه قابل مشاهده، دامنه اثر و هزینه آن بر زمان، خطا، دوبارهکاری یا کیفیت مشخص میشود.
تشخیص علت: فرایند، مسئولیت، استاندارد، منبع، مهارت و ابزار بررسی میشوند تا عامل ایجادکننده از محل مشاهده مشکل جدا شود.
ثبت خط مبنا: وضعیت پیش از تغییر با چند شاخص مرتبط ثبت میشود تا مقایسه بعدی به برداشت ذهنی وابسته نباشد.
طراحی اصلاح: کوچکترین مداخلهای انتخاب میشود که علت و وابستگیهای ضروری آن را پوشش دهد.
آزمون در دامنه محدود: روش اصلاحشده در یک فعالیت، مدل، رشته یا پروژه واقعی اجرا میشود تا اثر و عوارض احتمالی آن آشکار شوند.
تثبیت و انتقال: پس از اثبات نتیجه، روش نهایی مستند میشود، مسئول نگهداری مشخص میگردد و دانش لازم به اعضای مرتبط تیم منتقل میشود.
اگر نتیجه مطلوب حاصل نشود، راهحل نباید صرفاً بهعنوان روش جدید سازمان تثبیت شود. علت، فرضیات یا دامنه مداخله باید دوباره بررسی شوند.
بهینهسازی با اعمال تغییر کامل نمیشود؛ زمانی کامل است که تغییر در پروژه واقعی نتیجه دهد و سازمان بتواند آن را مستقل ادامه دهد.
خروجی بهینهسازی چیست و موفقیت آن چگونه سنجیده میشود؟
خروجی بهینهسازی با نتیجه آن یکسان نیست. یک Template اصلاحشده، استاندارد جدید، گردشکار مستند یا ابزار اتوماسیون، محصول مداخله است؛ اما وجود این محصولات به تنهایی اثبات نمیکند که فرایند بهتر شده است.
| خروجی مداخله | نتیجه مورد انتظار |
|---|---|
| Template یا Family اصلاحشده | زمان تولید کمتر و استفاده یکنواختتر |
| گردشکار و مسئولیتهای بازطراحیشده | کاهش انتظار، ابهام و دوبارهکاری |
| کنترلها و چکلیستهای جدید | شناسایی زودتر خطاها |
| ابزار اتوماسیون | کاهش فعالیت دستی بدون افزایش خطا |
| استاندارد و منابع یکپارچه | ثبات بیشتر خروجی میان افراد و پروژهها |
| آموزش و انتقال مالکیت | کاهش وابستگی به افراد یا مشاور بیرونی |
برای سنجش موفقیت، باید پیش از تغییر مشخص شود چه چیزی قرار است بهتر شود. اگر مسئله زمان زیاد تولید Sheetهاست، مدت انجام همان فعالیت پیش و پس از اصلاح مقایسه میشود. اگر مشکل خطاهای تکراری است، تعداد، نوع یا زمان لازم برای اصلاح آنها بررسی میشود. اگر هدف افزایش کیفیت تحویل است، میزان عدم انطباق، برگشت یا اصلاح پس از کنترل مقایسه میشود.
مقایسه باید تا حد امکان در شرایط مشابه انجام شود. کاهش زمان در یک پروژه سادهتر یا کاهش خطا پس از تغییر کامل تیم را نمیتوان مستقیماً به بهینهسازی نسبت داد. همچنین سرعت بیشتر زمانی موفقیت محسوب میشود که کیفیت، قابلیت کنترل و پایداری فرایند کاهش پیدا نکرده باشد.
جزئیات انتخاب خط مبنا و شاخصها در مقاله چگونه میتوان اثر بهینهسازی BIM را در زمان، خطا و کیفیت تحویل اندازهگیری کرد؟ بررسی شده است.
خروجی نشان میدهد چه چیزی تغییر کرده است؛ نتیجه نشان میدهد این تغییر چه ارزشی برای عملکرد واقعی شرکت ایجاد کرده است.
چه زمانی مسئله شرکت آموزش یا پیادهسازی BIM است، نه بهینهسازی؟
هر مشکل مشاهدهشده در پروژه BIM با بهینهسازی حل نمیشود. پیش از انتخاب مسیر باید مشخص شود که مسئله اصلی از کمبود مهارت، نبود ساختار اجرایی یا ناکارآمدی ساختاری موجود ناشی میشود.
| وضعیت شرکت | نیاز اصلی |
|---|---|
| افراد روش یا ابزار لازم را نمیشناسند، اما فرایند مرجع روشن است | آموزش هدفمند |
| استفاده از Revit پراکنده است و روش مشترکی برای اداره پروژه وجود ندارد | پیادهسازی BIM |
| روش BIM وجود دارد و تیم آن را اجرا میکند، اما عملکرد کند، پرخطا یا ناپایدار است | بهینهسازی BIM |
| مشکل فقط در یک فایل یا رخداد استثنایی دیده میشود | پشتیبانی یا رفع اشکال موردی |
اگر تیم هنوز مهارت پایه لازم برای مدلسازی، مستندسازی یا هماهنگی را ندارد، تغییر Template یا افزودن ابزار خودکار ممکن است ضعف را موقتاً پنهان کند، اما توانایی اجرای درست فرایند را ایجاد نمیکند. در این حالت، آموزش باید به نقش و فعالیت واقعی افراد متصل شود.
اگر شرکت فاقد نقشهای مشخص، استاندارد مشترک، روش کنترل کیفیت و گردشکار قابل تکرار است، چیزی برای بهینهسازی وجود ندارد. ابتدا باید ساختار BIM ایجاد و در یک پروژه واقعی تثبیت شود.
در مقابل، اگر این اجزا وجود دارند، تیم آنها را میشناسد و پروژهها نیز تحویل میشوند، اما اجرای کار به اصلاحات مکرر، فعالیت دستی یا حضور افراد خاص وابسته است، مسئله در محدوده بهینهسازی قرار میگیرد.
این نیازها میتوانند همزمان وجود داشته باشند. ممکن است یک گردشکار بهینه شود و تیم برای اجرای روش اصلاحشده به آموزش نیاز داشته باشد. معیار انتخاب، عامل اصلی ایجادکننده مشکل است؛ نه جذابترین یا آشناترین راهحل.
آموزش، پیادهسازی و بهینهسازی جایگزین یکدیگر نیستند؛ هرکدام باید به مسئلهای پاسخ دهند که واقعاً در شرکت وجود دارد.
جمعبندی
بهینهسازی BIM برای شرکتی مطرح میشود که قابلیت اجرای BIM را از قبل ایجاد کرده است، اما عملکرد این قابلیت دیگر با نیاز واقعی پروژهها و سازمان تناسب ندارد. مسئله ممکن است در زمان زیاد تولید، اصلاحات تکراری، روشهای ناهماهنگ، منابع ناکارآمد، هماهنگی ضعیف، مدلهای کند یا وابستگی به کار دستی و افراد خاص دیده شود.
با این حال، مشاهده این نشانهها برای انتخاب راهحل کافی نیست. یک مشکل ظاهراً فنی میتواند از مسئولیت نامشخص، استاندارد نامناسب، کنترل دیرهنگام یا گردشکاری ایجاد شود که برای شرایط قبلی شرکت طراحی شده است. به همین دلیل، بهینهسازی باید از تشخیص علت آغاز شود، نه از خرید ابزار یا اجرای نخستین راهحل در دسترس. چارچوب این بررسی در مقاله مشاور BIM چگونه مشکلات پروژه یا سازمان را تشخیص میدهد؟ بهصورت دقیقتر توضیح داده شده است.
دامنه اصلاح نیز باید متناسب با مسئله باشد. گاهی تغییر یک Family، Template یا فعالیت پرتکرار کافی است؛ گاهی چند مرحله مرتبط باید بهعنوان یک گردشکار بازطراحی شوند. در هر دو حالت، تغییر باید ابتدا در شرایط واقعی آزموده شود و اثر آن با وضعیت قبلی مقایسه گردد.
نتیجه مطلوب فقط یک فایل، سند یا ابزار جدید نیست. روش اصلاحشده باید زمان، خطا، دوبارهکاری یا ناپایداری تحویل را کاهش دهد و تیم داخلی بتواند آن را بدون وابستگی دائمی ادامه دهد.
بنابراین پرسش نهایی این نیست که شرکت چه ابزار تازهای به ساختار BIM خود اضافه کرده است. باید پرسید آیا BIM موجود پس از اصلاح، با هزینه کمتر، کیفیت قابلاتکاتر و قابلیت تکرار بیشتری عمل میکند یا خیر.
بهینهسازی BIM زمانی موفق است که بهبود از سطح تغییرات فنی عبور کند و در عملکرد روزمره سازمان باقی بماند.