چرا تیم Revit با وجود نیروهای ماهر باز هم کند کار می‌کند؟

مقدمه

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

وقتی افراد ماهرند، چرا تیم هنوز کند است؟

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

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

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

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

ممکن است افراد سریع باشند، اما سیستم کند باشد.

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

مهارت فردی با بهره‌وری تیم یکی نیست

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

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

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

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

مهارت فردی زمانی به بهره‌وری سازمانی تبدیل می‌شود که بتوان آن را در یک روش مشترک و تکرارپذیر به کار گرفت.

بنابراین سؤال اصلی فقط این نیست که «کاربران Revit چقدر حرفه‌ای هستند؟»؛ باید پرسید این مهارت‌ها تا چه اندازه در یک سیستم کاری هماهنگ شده‌اند.

وقتی فرایند کاری، اتلاف زمان تولید می‌کند

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

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

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

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

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

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

وقتی زیرساخت Revit برای کار تیمی طراحی نشده است

بهره‌وری تیم Revit فقط به نحوه مدل‌سازی وابسته نیست؛ بخش بزرگی از آن به زیرساختی بستگی دارد که تیم هر روز روی آن کار می‌کند Template، View Templateها، Familyها، Shared Parameterها، Scheduleها، ساختار Browser و قواعد نام‌گذاری در ظاهر ابزارهای جانبی هستند، اما در عمل تعیین می‌کنند چه مقدار از تصمیم گیری و تنظیمات پروژه باید هر بار از نو انجام شود.

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

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

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

زیرساخت خوب Revit تعداد تصمیم‌هایی را که تیم مجبور است هر روز دوباره بگیرد کاهش می‌دهد.

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

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

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

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

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

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

هر چیزی که می‌توان در Revit مدل کرد، لزوماً نباید مدل شود.

مدل کارآمد مدلی نیست که بیشترین اطلاعات ممکن را در خود نگه دارد؛ مدلی است که اطلاعات موردنیاز پروژه را با کمترین پیچیدگی غیرضروری در اختیار تیم قرار دهد.

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

مستندسازی ضعیف چگونه زمان تولید را چند برابر می‌کند؟

در بسیاری از تیم‌ها، سرعت کار با Revit با سرعت مدل‌سازی سنجیده می‌شود؛ در حالی که بخش بزرگی از زمان پروژه صرف تبدیل مدل به مدارک قابل تحویل می‌شود. اگر ساختار Viewها، Sheetها، Scheduleها، Annotationها و قواعد نمایش از ابتدا منظم نباشد، حتی یک مدل خوب نیز می‌تواند به فرایند مستندسازی کند و پرهزینه منجر شود.

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

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

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

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

بنابراین بهره‌وری تیم Revit را نباید فقط در محیط مدل سنجید؛ باید کل مسیر تولید اطلاعات تا Sheet و خروجی نهایی بررسی شود.

مقاله چرا تولید نقشه از مدل BIM بیش از حد زمان می‌برد؟ این مسیر را از View و Family تا تغییرات، QA و اتوماسیون به‌صورت مستقل باز می‌کند.

وقتی ساختار مدل با نحوه همکاری تیم هماهنگ نیست

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

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

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

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

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

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

اصلاحات مکرر؛ هزینه‌ای که در زمان مدل‌سازی دیده نمی‌شود

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

دوباره‌ کاری معمولاً از یک مشکل واحد ایجاد نمی‌شود. اطلاعات ناقص، روش‌های متفاوت مدل‌سازی، Familyهای نامناسب، نبود استاندارد مشترک، هماهنگی ضعیف میان رشته‌ها یا ساختار نادرست مستندسازی می‌توانند باعث شوند یک تغییر کوچک در مدل، اصلاحات متعددی در Viewها، Sheetها، Scheduleها و حتی مدل‌های مرتبط ایجاد کند.

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

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

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

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

چگونه بفهمیم مشکل آموزش است یا بهینه سازی؟

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

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

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

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

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

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

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

چرا اضافه کردن نیروی بیشتر همیشه مشکل را حل نمی‌کند؟

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

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

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

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

نیروی بیشتر، ظرفیت یک فرایند خوب را افزایش می‌دهد؛ اما ضعف یک فرایند بد را نیز بزرگ‌تر می‌کند.

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

بهینه سازی BIM باید چه چیزی را واقعاً تغییر دهد؟

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

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

به همین دلیل، ابزارهایی مانند Template، Family، View Template، استانداردهای کاری یا Automation خودِ هدف نیستند. آن‌ها فقط زمانی ارزش دارند که یکی از گلوگاه‌های واقعی فرایند را برطرف کنند.

در یک بهینه سازی موفق، نتیجه باید در یکی یا چند مورد دیده شود:

• کاهش زمان انجام فعالیت‌های تکراری؛

• کاهش دوباره‌کاری و اصلاحات؛

• افزایش ثبات مدل و مدارک؛

• کاهش وابستگی به تصمیم‌های فردی؛

• قابل‌پیش‌بینی‌تر شدن زمان تولید و تحویل.

بهینه سازی زمانی اتفاق افتاده است که اتلاف کمتر شده باشد، نه صرفاً زمانی که ابزار جدیدی به فرایند اضافه شده باشد.

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

جمع‌بندی

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

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

به همین دلیل، ارزیابی کندی یک تیم نباید با این سؤال شروع شود که «چه کسی کند کار می‌کند؟» بهتر است ابتدا پرسیده شود: «کدام بخش از فرایند باعث می‌شود زمان، دقت یا ظرفیت تیم هدر برود؟»

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

سرعت یک تیم BIM فقط حاصل سرعت افراد نیست؛ حاصل طراحی گردش‌کار آن‌هاست.

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

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