متن مقاله
مقدمه
فرایندی که برای یک تیم کوچک و چند پروژه محدود خوب کار میکند، لزوماً با رشد سازمان همان عملکرد را حفظ نمیکند. افزایش کاربران، پروژهها، Familyها، استثناها و اتوماسیونهای پراکنده میتواند بهتدریج بدهی فرایندی ایجاد کند و فاصله میان روش رسمی و کار واقعی تیم را بیشتر سازد. این مقاله منابع اصلی این ناکارآمدی تدریجی را بررسی میکند و نشان میدهد چرا بازبینی دورهای استانداردها، ابزارها و گردشکارها برای حفظ سرعت و قابلیت اتکای BIM ضروری است.
چرا فرایند BIM برای همیشه کارآمد باقی نمیماند؟
یک فرایند BIM ممکن است در زمان طراحی اولیه کاملاً مناسب باشد، اما این به معنی آن نیست که برای همیشه کارآمد باقی میماند. پروژهها تغییر میکنند، تعداد اعضای تیم افزایش پیدا میکند، الزامات کارفرما متفاوت میشوند و ابزارها و روشهای تولید نیز بهمرور توسعه پیدا میکنند. اگر فرایند همزمان با این تغییرات بازبینی نشود، فاصله میان ساختار رسمی و روش واقعی کار بیشتر میشود.
برای مثال ممکن است Template ای که برای یک نوع پروژه طراحی شده بود، بعداً برای پروژههای بزرگتر یا رشتههای بیشتر استفاده شود. استانداردی که در تیم پنجنفره بهراحتی اجرا میشد، در تیم بیستنفره به کنترلهای بیشتری نیاز داشته باشد. همچنین فعالیتی که در گذشته فقط چند بار در ماه انجام میشد، با افزایش تعداد پروژهها ممکن است هر روز تکرار شود و هزینه زمانی آن دیگر قابل چشمپوشی نباشد.
در چنین شرایطی معمولاً مشکل بهصورت ناگهانی ظاهر نمیشود. ناکارآمدی از مجموعهای از تغییرات کوچک شکل میگیرد: یک استثنا به استاندارد اضافه میشود، یک راهحل موقت باقی میماند، یک ابزار جدید بدون حذف روش قبلی وارد فرایند میشود و هر پروژه بخشی از ساختار را به روش خود تغییر میدهد.
فرایند BIM زمانی کارآمد باقی میماند که همراه با پروژه، تیم و نیازهای سازمان بازبینی شود؛ نه زمانی که یکبار طراحی و برای همیشه ثابت فرض شود.
وقتی این فاصله میان روش رسمی و کار واقعی به اتلاف زمان، خطای تکراری یا پیچیدگی غیرضروری منجر میشود، بهینهسازی BIM باید فرایند موجود را بر اساس شواهد واقعی بازبینی و اصلاح کند، نه اینکه صرفاً ابزار تازهای به آن اضافه شود.
برای تشخیص اینکه این فرسایش واقعاً به مداخله نیاز دارد یا فقط یک مسئله موقت پروژه است، مقاله بهینهسازی BIM چیست و چه زمانی یک شرکت به آن نیاز دارد؟ معیارهای تصمیم را توضیح میدهد.
چرا روش مناسب یک تیم کوچک در تیم بزرگتر جواب نمیدهد؟
در یک تیم کوچک، بسیاری از مسائل بدون ساختار رسمی حل میشوند. اعضا معمولاً یکدیگر را میشناسند، روش کار همدیگر را میدانند و بخش زیادی از هماهنگی از طریق گفتوگوی مستقیم انجام میشود. اگر استانداردی مبهم باشد یا یک تصمیم ثبت نشده باشد، معمولاً میتوان با یک سؤال سریع مسئله را حل کرد.
اما با بزرگتر شدن تیم، همین وابستگی به ارتباط مستقیم به نقطه ضعف تبدیل میشود. تعداد ارتباطات بیشتر میشود، افراد جدید وارد پروژه میشوند و دیگر نمیتوان فرض کرد همه اعضا از تصمیمها، روشهای مدلسازی یا استثناهای پروژه اطلاع دارند. در این مقیاس، چیزی که قبلاً با تجربه مشترک کنترل میشد، باید به روش اجرایی مشخص تبدیل شود.
برای مثال ممکن است در یک تیم پنجنفره همه بدانند چه زمانی یک View باید ایجاد شود، کدام Family مورد تأیید است یا چه کسی مسئول کنترل مدل است. در تیم بزرگتر، اگر این قواعد فقط در ذهن افراد باقی بمانند، روشهای مختلف بهتدریج شکل میگیرند و کیفیت خروجی به فردی که کار را انجام میدهد وابسته میشود.
رشد تیم همچنین نیاز به تفکیک روشنتر نقشها، نقاط کنترل، استانداردهای قابل دسترس و روش انتقال دانش دارد. بدون این ساختار، افزایش تعداد افراد الزاماً باعث افزایش ظرفیت نمیشود و حتی ممکن است هماهنگی و دوبارهکاری را بیشتر کند.
فرایندی که بر شناخت شخصی و ارتباط مستقیم تکیه دارد، در تیم کوچک میتواند کارآمد باشد؛ اما در مقیاس بزرگ به ساختار قابل تکرار نیاز دارد.
افزایش تعداد پروژهها چگونه پیچیدگی فرایند BIM را بیشتر میکند؟
افزایش تعداد پروژههای همزمان فقط به معنی افزایش حجم کار نیست؛ هر پروژه میتواند الزامات، تیم، کارفرما، سطح جزئیات و روش تحویل متفاوتی داشته باشد. اگر شرکت برای مدیریت این تفاوتها ساختار مشخصی نداشته باشد، فرایند BIM بهتدریج به مجموعهای از روشهای موازی تبدیل میشود.
برای مثال ممکن است هر پروژه نسخه متفاوتی از Template ایجاد کند، Familyهای مخصوص خود را توسعه دهد یا استانداردهای نامگذاری و پارامترهای جداگانهای داشته باشد. بخشی از این تفاوتها ضروری است، اما اگر مشخص نباشد چه چیزی استاندارد سازمانی و چه چیزی استثنای پروژه است، منابع مشترک بهمرور چندشاخه و نگهداری آنها دشوار میشوند.
مشکل دیگر، انتقال تجربه میان پروژههاست. اگر هر تیم مسئلهای را جداگانه حل کند، ممکن است چند پروژه برای یک مشکل مشابه چند راهحل مختلف بسازند. در نتیجه بهجای آنکه تجربه یک پروژه باعث بهبود سیستم سازمان شود، دانش در همان پروژه باقی میماند.
افزایش پروژهها همچنین فعالیتهایی مانند کنترل کیفیت، بهروزرسانی منابع، نگهداری ابزارهای اتوماسیون و پشتیبانی از تیمها را چند برابر میکند. روشی که برای یک پروژه هزینه ناچیزی داشت، در ده پروژه میتواند به یک بار عملیاتی جدی تبدیل شود.
با افزایش تعداد پروژهها، شرکت باید میان «استاندارد مشترک سازمان» و «نیاز خاص هر پروژه» مرز روشنی ایجاد کند؛ در غیر این صورت هر پروژه بهتدریج یک سیستم BIM مستقل میسازد.
چگونه راهحلهای موقت به روش دائمی کار تبدیل میشوند؟
در بسیاری از پروژهها، تیم برای حل یک مسئله فوری راهحلی موقت ایجاد میکند. ممکن است یک Naming Rule برای یک پروژه تغییر کند، یک Shared Parameter جدید بدون ساختار مشخص اضافه شود، یک Family بهصورت سریع اصلاح شود یا برای دور زدن محدودیت یک Template روش جداگانهای شکل بگیرد. در لحظه، این تصمیمها منطقی به نظر میرسند چون هدف اصلی ادامه دادن پروژه است.
مشکل زمانی ایجاد میشود که این راهحلهای موقت بعد از پایان مسئله حذف یا بازبینی نمیشوند. فرد دیگری همان روش را در پروژه بعدی تکرار میکند، نسخه اصلاحشده یک فایل وارد کتابخانه عمومی میشود یا تیم بهتدریج یک استثنا را بهعنوان روش عادی کار میپذیرد.
با تکرار این وضعیت، فرایند اصلی آرامآرام با لایههایی از استثنا و میانبر پوشانده میشود. ممکن است دیگر کسی نداند چرا یک مرحله وجود دارد یا کدام نسخه از یک ابزار باید استفاده شود. حذف هر بخش نیز دشوار میشود، چون احتمال دارد پروژه یا فرد دیگری به آن وابسته شده باشد.
راهحل موقت ذاتاً مشکل نیست؛ پروژهها گاهی به تصمیم سریع نیاز دارند. مسئله زمانی است که هیچ مکانیزمی برای ثبت، ارزیابی و تعیین تکلیف این تصمیمها وجود نداشته باشد.
بدهی فرایندی زمانی شکل میگیرد که راهحلهای موقت بدون بازبینی باقی بمانند و بهتدریج به بخشی از روش رسمی کار تبدیل شوند.
چرا استانداردها و Templateها بهمرور از نیاز واقعی پروژه فاصله میگیرند؟
استانداردها و Templateهای BIM معمولاً بر اساس نیازهای مشخصی در یک مقطع زمانی طراحی میشوند. اما نوع پروژهها، الزامات کارفرما، روش تحویل و ساختار تیمها در طول زمان تغییر میکنند. اگر این منابع همزمان با تغییر شرایط بازبینی نشوند، بهتدریج فاصله میان آنچه روی کاغذ تعریف شده و آنچه تیم واقعاً انجام میدهد بیشتر میشود.
برای مثال ممکن است Template شامل Viewها، Sheetها، فیلترها یا پارامترهایی باشد که دیگر در اغلب پروژهها استفاده نمیشوند، در حالی که نیازهای جدید باید در هر پروژه بهصورت دستی اضافه شوند. یا استاندارد نامگذاری برای ساختاری طراحی شده باشد که با شیوه فعلی تحویل مدلها هماهنگ نیست. در این شرایط، اعضای تیم برای انجام کار ناچار به ایجاد استثنا و تغییرات محلی میشوند.
با افزایش تعداد این استثناها، Template از یک ابزار تسهیلکننده به یک نقطه شروع ناقص تبدیل میشود که هر پروژه باید بخش قابل توجهی از آن را دوباره تنظیم کند. مشکل دیگر زمانی ایجاد میشود که نسخههای اصلاحشده در پروژههای مختلف باقی بمانند و مشخص نباشد کدام تغییر باید به استاندارد اصلی سازمان منتقل شود.
استاندارد خوب نباید فقط ثابت و یکسان باشد؛ باید بتواند میان قواعد پایدار سازمان و نیازهای متغیر پروژه تعادل ایجاد کند.
وقتی هر پروژه مجبور است استاندارد یا Template را بارها اصلاح کند، مسئله فقط تفاوت پروژهها نیست؛ ممکن است خود استاندارد دیگر با واقعیت کار سازمان هماهنگ نباشد.
چگونه Familyها و محتوای کنترلنشده پیچیدگی سیستم را افزایش میدهند؟
با رشد پروژهها، کتابخانه Familyها معمولاً بهسرعت بزرگتر میشود. هر پروژه ممکن است Family جدیدی ایجاد کند، نسخهای از یک Family موجود را تغییر دهد یا پارامترهای متفاوتی به آن اضافه کند. اگر این محتوا بدون ساختار مشخص وارد منابع مشترک سازمان شود، کتابخانه بهتدریج از یک ابزار مفید به مجموعهای از گزینههای مشابه و نامطمئن تبدیل میشود.
یکی از نشانههای این وضعیت، وجود چند Family برای یک کاربرد مشابه است که تفاوت آنها برای کاربران روشن نیست. ممکن است بعضی نسخهها پارامترهای متفاوت داشته باشند، برخی بیش از حد پیچیده باشند یا گروهی از آنها فقط برای یک پروژه خاص طراحی شده باشند. در نتیجه اعضای تیم برای انتخاب محتوا زمان بیشتری صرف میکنند و احتمال استفاده از نسخه نامناسب افزایش مییابد.
محتوای کنترلنشده همچنین میتواند بر عملکرد مدل اثر بگذارد. Geometry بیش از حد پیچیده، Nested Familyهای متعدد، پارامترهای غیرضروری یا روشهای متفاوت ساخت Family میتوانند حجم و پیچیدگی مدل را افزایش دهند، بدون اینکه ارزش متناسبی برای خروجی ایجاد کنند.
مسئله اصلی تعداد زیاد Familyها نیست؛ نبود چرخه مشخص برای ایجاد، بررسی، تأیید، انتشار و بازنشسته کردن آنهاست. یک کتابخانه سازمانی باید مشخص کند چه محتوایی مرجع است و چه چیزی فقط برای یک پروژه ایجاد شده است.
وقتی هر پروژه بدون کنترل به کتابخانه محتوا اضافه کند، تنوع بهتدریج جای استاندارد را میگیرد و نگهداری سیستم از تولید محتوا دشوارتر میشود.
چگونه وابستگی به چند فرد باتجربه به گلوگاه تبدیل میشود؟
در بسیاری از تیمهای BIM، بخشی از دانش عملی فرایند بهجای آنکه در استانداردها، Templateها و روشهای اجرایی ثبت شود، در تجربه چند نفر باقی میماند. در مقیاس کوچک این وضعیت ممکن است مشکل جدی ایجاد نکند، زیرا افراد باتجربه میتوانند مستقیماً به سؤالات پاسخ دهند و خطاها را اصلاح کنند. اما با رشد تیم و پروژهها، همین وابستگی بهتدریج به گلوگاه تبدیل میشود.
نشانه این مشکل زمانی است که برای تصمیمهای روزمره تقریباً همیشه باید به یک BIM Manager، Coordinator یا Modeler باتجربه مراجعه شود. تأیید Familyها، حل مشکلات مدل، تنظیم پروژههای جدید، کنترل استانداردها یا حتی اجرای بعضی ابزارهای اتوماسیون ممکن است بدون حضور این افراد متوقف شود.
در نتیجه، ظرفیت واقعی تیم دیگر فقط به تعداد اعضا وابسته نیست؛ به زمان در دسترس چند فرد کلیدی محدود میشود. هرچه پروژهها بیشتر شوند، این افراد بخش بیشتری از زمان خود را صرف پاسخگویی به مشکلات تکراری میکنند و فرصت کمتری برای فعالیتهای مهمتر مانند کنترل کیفیت، توسعه استانداردها یا بهبود فرایند خواهند داشت.
راهحل نیز صرفاً افزایش تعداد افراد باتجربه نیست. دانش تکرارشونده باید تا حد ممکن به استاندارد، راهنمای اجرایی، Template، ابزار یا نقطه کنترل مشخص تبدیل شود تا تیم برای مسائل عادی وابسته به حافظه و حضور یک فرد خاص نباشد.
اگر اجرای صحیح BIM فقط با حضور چند فرد مشخص امکانپذیر باشد، دانش وجود دارد اما هنوز به قابلیت سازمانی تبدیل نشده است.
چرا افزایش حجم و جزئیات مدل همیشه به بهبود خروجی BIM منجر نمیشود؟
با رشد پروژه، معمولاً اطلاعات و جزئیات بیشتری وارد مدل میشوند. این افزایش در بسیاری از موارد ضروری است، اما اگر بدون ارتباط روشن با نیازهای طراحی، هماهنگی، مستندسازی یا تحویل انجام شود، میتواند مدل را پیچیدهتر کند بدون اینکه ارزش متناسبی به خروجی اضافه کند.
یکی از اشتباهات رایج این است که کیفیت مدل با مقدار جزئیات آن سنجیده شود. برای مثال ممکن است عناصر با Geometry بسیار دقیق ساخته شوند، پارامترهای زیادی به Familyها اضافه شود یا اطلاعاتی ثبت شود که در هیچ مرحلهای از پروژه مورد استفاده قرار نمیگیرد. نتیجه، مدلی است که نگهداری و کنترل آن دشوارتر شده، اما تصمیم گیری یا تحویل پروژه را بهتر نکرده است.
افزایش جزئیات همچنین هزینه پنهان دارد. هر داده یا عنصر جدید باید ایجاد، کنترل، بهروزرسانی و در صورت تغییر طراحی اصلاح شود. اگر این اطلاعات در خروجی نهایی، هماهنگی یا تصمیم گیری استفاده نشوند، تیم برای تولید و نگهداری چیزی زمان صرف میکند که ارزش عملی محدودی دارد.
بهینهسازی در اینجا به معنی سادهسازی بیهدف مدل نیست. باید مشخص شود هر نوع اطلاعات یا جزئیات برای چه استفادهای تولید میشود و چه زمانی وجود آن ضروری است. سطح جزئیات باید متناسب با هدف مدل و مرحله پروژه تعیین شود.
مدل بهتر مدلی نیست که بیشترین اطلاعات را داشته باشد؛ مدلی است که اطلاعات لازم را با کمترین پیچیدگی غیرضروری در اختیار تیم قرار دهد.
چگونه کارهای دستی کوچک در مقیاس بزرگ به اتلاف جدی زمان تبدیل میشوند؟
بسیاری از فعالیتهای دستی در BIM به تنهایی زمان زیادی نمیگیرند. تغییر یک پارامتر، اصلاح نام یک View، تنظیم یک Sheet یا کنترل یک مورد مشخص ممکن است فقط چند دقیقه طول بکشد. به همین دلیل این فعالیتها معمولاً در نگاه اول ارزش بهینهسازی ندارند. مسئله زمانی آشکار میشود که همین کار در صدها عنصر، چندین فایل، توسط چند نفر و در چند پروژه تکرار شود.
برای مثال اگر یک اصلاح دستی فقط سه دقیقه زمان ببرد اما هر هفته صد بار انجام شود، همان فعالیت بیش از پنج ساعت زمان مصرف میکند. اگر چند نفر درگیر آن باشند یا این الگو در پروژههای مختلف تکرار شود، هزینه آن بهسرعت افزایش پیدا میکند.
علاوه بر زمان مستقیم، کار دستی هزینه دیگری نیز دارد: احتمال خطا و ناهماهنگی. هرچه تعداد تکرارها بیشتر شود، احتمال جا افتادن یک مورد، وارد کردن مقدار اشتباه یا اجرای متفاوت یک دستورالعمل نیز افزایش مییابد. در نتیجه بخشی از زمانی که صرف تولید شده، بعداً دوباره برای کنترل و اصلاح مصرف میشود.
البته هر کار دستی نباید خودکار شود. ابتدا باید مشخص شود فعالیت چقدر تکرار میشود، چقدر زمان میگیرد و آیا قواعد آن بهاندازه کافی ثابت هستند. گاهی حذف یک مرحله یا اصلاح Template از ساخت یک ابزار اتوماسیون مؤثرتر است.
در مقیاس سازمانی، اتلاف بزرگ معمولاً از یک فعالیت بسیار کند ایجاد نمیشود؛ از صدها فعالیت کوچک و تکراری شکل میگیرد که کسی مجموع هزینه آنها را اندازهگیری نکرده است.
چرا اتوماسیونهای پراکنده بدون نگهداری خودشان به منبع مشکل تبدیل میشوند؟
اتوماسیون میتواند زمان انجام فعالیتهای تکراری را بهشدت کاهش دهد، اما فقط زمانی که بخشی کنترلشده از فرایند باشد. در بسیاری از شرکتها ابزارهای Dynamo، اسکریپتها یا افزونههای داخلی به تدریج و برای حل مسائل پروژههای مختلف ساخته میشوند، بدون اینکه ساختار مشخصی برای نگهداری، نسخهبندی یا تعیین مسئول آنها وجود داشته باشد.
در ابتدا هر ابزار ممکن است یک مشکل واقعی را حل کند، اما با تغییر نسخه Revit، Template، Shared Parameterها، Familyها یا روش اجرایی پروژه، بعضی ابزارها دیگر همان عملکرد قبلی را ندارند. اگر این تغییرات کنترل نشوند، تیم با مجموعهای از اسکریپتها روبهرو میشود که مشخص نیست کدام نسخه معتبر است، روی چه پروژهای کار میکند و چه کسی باید خطای آن را برطرف کند.
وابستگی اتوماسیون به سازنده آن نیز میتواند مشکل را تشدید کند. اگر فقط یک نفر منطق ابزار را بداند، خروج او از تیم یا در دسترس نبودنش ممکن است استفاده از یک بخش مهم گردشکار را متوقف کند. در این حالت ابزاری که برای کاهش وابستگی به کار دستی ساخته شده بود، وابستگی جدیدی ایجاد میکند.
اتوماسیون پایدار به مستندسازی، نسخهبندی، تست، مالک مشخص و بازبینی دورهای نیاز دارد. همچنین باید مشخص باشد چه زمانی یک ابزار باید اصلاح، جایگزین یا حذف شود.
اتوماسیون بدون نگهداری، بدهی فنی ایجاد میکند؛ هرچه ابزارهای پراکنده بیشتر شوند، احتمال اینکه خود آنها به منبع خطا و توقف فرایند تبدیل شوند بیشتر میشود.
وقتی هیچکس مالک بهبود فرایند نیست چه اتفاقی میافتد؟
یکی از دلایل اصلی انباشته شدن ناکارآمدی در فرایندهای BIM این است که مسئولیت اجرای کار مشخص است، اما مسئولیت بهبود خود فرایند مشخص نیست. تیم میداند چه کسی مدلسازی میکند، چه کسی هماهنگی را انجام میدهد و چه کسی خروجی را کنترل میکند، اما ممکن است هیچ فرد یا نقشی مسئول بررسی این نباشد که آیا روش انجام این فعالیتها هنوز کارآمد است یا نه.
در چنین شرایطی، مشکلات معمولاً بهصورت موردی حل میشوند. یک پروژه Template را تغییر میدهد، پروژه دیگر اسکریپت جدیدی میسازد و فردی باتجربه برای یک مشکل تکراری راهحل شخصی پیدا میکند. اما این اصلاحات لزوماً به دانش و روش مشترک سازمان تبدیل نمیشوند.
نبود مالک فرایند باعث میشود تصمیمهای مهم نیز معلق بمانند: چه زمانی باید یک استاندارد بازبینی شود؟ کدام Family باید از کتابخانه حذف شود؟ آیا یک فعالیت دستی ارزش اتوماسیون دارد؟ کدام ابزار قدیمی باید بازنشسته شود؟ چه کسی بازخورد پروژهها را جمعآوری و به تغییرات سازمانی تبدیل میکند؟
مالک بهبود فرایند الزاماً نباید همه اصلاحات را شخصاً انجام دهد. وظیفه اصلی او ایجاد چرخهای برای مشاهده مشکل، اولویتبندی، آزمایش راهحل، مستندسازی تغییر و ارزیابی نتیجه است.
وقتی همه مسئول اجرای فرایند هستند اما هیچکس مسئول بهتر شدن آن نیست، ناکارآمدیها بهتدریج به بخشی عادی از روش کار تبدیل میشوند.
جمعبندی
فرایندهای BIM معمولاً در اثر یک مشکل بزرگ ناکارآمد نمیشوند؛ بیشتر اوقات مجموعهای از تغییرات کوچک، استثناها و راهحلهای موقت در طول زمان روی هم انباشته میشوند. بازبینی دورهای کمک میکند این مشکلات پیش از آنکه به بخشی ثابت از روش کار تبدیل شوند، شناسایی و اصلاح شوند.
این بازبینی نباید فقط به بررسی Template یا ابزارهای Revit محدود باشد. بهتر است کل مسیر انجام کار بررسی شود: کدام فعالیتها بیش از حد زمان میگیرند، چه خطاهایی مرتب تکرار میشوند، کدام استانداردها دیگر استفاده نمیشوند، چه ابزارهایی نیاز به نگهداری دارند و اعضای تیم در چه بخشهایی مجبور به استفاده از راهحلهای غیررسمی شدهاند.
بازخورد پروژهها در این مرحله اهمیت زیادی دارد. مشکلاتی که در یک پروژه دیده میشوند میتوانند نشانهای از ضعف عمومی فرایند باشند. اگر این تجربه ثبت و بررسی شود، شرکت میتواند پیش از شروع پروژه بعدی استاندارد، Template، کتابخانه، اتوماسیون یا روش اجرایی خود را اصلاح کند.
فاصله زمانی بازبینی نیز باید متناسب با سرعت تغییر سازمان باشد. تیمی که پروژههای متعدد و متنوع دارد احتمالاً به بازبینی منظمتری نسبت به تیمی با ساختار ثابت نیاز دارد.
هدف این نیست که فرایند دائماً تغییر کند؛ تغییر زیاد نیز میتواند باعث سردرگمی شود. هدف ایجاد چرخهای کنترلشده برای تشخیص، اولویتبندی و اعمال اصلاحات ضروری است.
فرایند BIM زمانی پایدار میماند که بهبود آن بخشی از کار عادی سازمان باشد، نه واکنشی که فقط پس از جدی شدن مشکلات آغاز شود.
پس از اصلاح نیز باید نتیجه را با خط مبنا مقایسه کرد؛ مسیر سنجش در مقاله اندازهگیری اثر بهینهسازی BIM توضیح داده شده است.