متن مقاله
مقدمه
وقتی پروژه BIM به بنبست میرسد، فشار برای افزایش سرعت معمولاً باعث میشود تیم مستقیماً سراغ نیروی بیشتر، ساعات کاری بیشتر یا ابزار جدید برود. اما اگر گلوگاه اصلی در تصمیم گیری، هماهنگی، مدل سنگین یا گردشکار باشد، این اقدامات فقط هزینه را افزایش میدهند. این مقاله یک مسیر تشخیصی برای بازیابی پروژه ارائه میکند تا ابتدا علت کندی یا توقف مشخص شود، سپس اقدامات اصلاحی بر اساس اثر آنها بر تحویل اولویتبندی شوند و معلوم شود چه زمانی تیم داخلی کافی است و چه زمانی مداخله بیرونی لازم میشود.
پروژه BIM چه زمانی واقعاً به بن بست رسیده است؟
هر پروژهای ممکن است در مقطعی با فشار زمانی، افزایش حجم کار یا تأخیر در بخشی از فعالیتها روبهرو شود. این وضعیت بهتنهایی به معنی به بن بست رسیدن پروژه BIM نیست. مسئله زمانی جدیتر میشود که تیم دیگر نتواند با اطمینان توضیح دهد فاصله میان وضعیت فعلی و تحویل مورد انتظار چگونه قرار است طی شود.
در چنین شرایطی معمولاً نشانههایی مانند افزایش دوباره کاری، باقی ماندن تصمیمهای کلیدی، تکرار تداخلها در چند چرخه هماهنگی، عقب ماندن تولید نقشهها از مدلسازی یا نامشخص بودن وضعیت واقعی خروجیها دیده میشود. افراد ممکن است ساعات بیشتری کار کنند، اما میزان خروجی قابل تحویل متناسب با این افزایش تلاش رشد نمیکند.
گاهی خود مدل نیز به بخشی از مسئله تبدیل میشود؛ برای مثال فایلها سنگین شدهاند، همگامسازی زمان زیادی میگیرد یا تغییر یک بخش باعث اختلال در بخشهای دیگر میشود. اما حتی در این شرایط نیز نمیتوان صرفاً از روی کندی مدل نتیجه گرفت که مشکل اصلی فنی است. ممکن است ریشه مسئله در تغییرات مداوم طراحی، نبود تصمیم گیری به موقع، تقسیم نامناسب مسئولیتها یا گردشکاری باشد که با شرایط فعلی پروژه تناسب ندارد.
پروژه زمانی واقعاً از کنترل خارج میشود که افزایش تلاش دیگر به افزایش قابل پیشبینی در آمادگی برای تحویل منجر نشود.
در این نقطه، هدف نباید صرفاً افزایش سرعت تولید باشد. ابتدا باید مشخص شود چه چیزی جریان تحویل را متوقف کرده و چرا تیم با وجود صرف زمان و انرژی بیشتر، به خروجی مورد انتظار نزدیک نمیشود.
چرا سریعتر کار کردن همیشه پروژه را سریعتر نمیکند؟
وقتی پروژه به موعد تحویل نزدیک میشود و عقب ماندگی افزایش پیدا میکند، واکنش طبیعی معمولاً افزایش سرعت است: نیروی بیشتری به پروژه اضافه شود، ساعات کاری افزایش پیدا کند، مدلسازی سریعتر انجام شود یا بخشی از کار میان افراد بیشتری تقسیم شود. این اقدامات در بعضی پروژهها مفید هستند، اما فقط زمانی که مشکل اصلی کمبود ظرفیت باشد.
اگر علت تأخیر در جای دیگری قرار داشته باشد، افزایش سرعت حتی میتواند وضعیت را پیچیدهتر کند. برای مثال، وقتی اطلاعات طراحی مرتباً تغییر میکند، اضافه کردن مدلساز جدید فقط حجم بیشتری از کاری را تولید میکند که ممکن است دوباره اصلاح شود. اگر مسئول تصمیم گیری مشخص نیست، افزایش تعداد افراد باعث افزایش پرسشها و هماهنگیهای لازم میشود. اگر مدل به دلیل ساختار نامناسب یا Family های سنگین کند شده است، ساعات کاری بیشتر مشکل عملکرد آن را برطرف نمیکند.
همین مسئله درباره Clash Detection، اتوماسیون یا تقسیم مدل نیز صدق میکند. هرکدام از این اقدامات ممکن است مفید باشند، اما تنها در صورتی که مستقیماً یکی از موانع اصلی تحویل را هدف قرار دهند.
در پروژهای که فرایند آن از کنترل خارج شده، سریعتر کار کردن همیشه پروژه را سریعتر نمیکند.
پیش از افزایش ظرفیت یا فشار بر تیم، باید مشخص شود زمان موجود دقیقاً در کجا مصرف میشود و کدام عامل جریان تحویل را محدود کرده است. در غیر این صورت، پروژه ممکن است با سرعت بیشتری همان دوبارهکاریها، انتظارها و تصمیمهای حلنشده را تکرار کند.
نشانههای مشابه میتوانند علتهای کاملاً متفاوتی داشته باشند
یکی از دلایل شکست تلاشهای اصلاحی این است که تیم بر اساس نشانهها تصمیم میگیرد، نه بر اساس علت واقعی. برای مثال، عقب بودن نقشهها میتواند ناشی از کمبود نیرو باشد، اما همان نشانه ممکن است در پروژهای دیگر از تغییرات مداوم طراحی، ضعف در گردشکار مستندسازی یا تأخیر در تصمیم گیری ناشی شود.
کندی مدل نیز همیشه یک مسئله فنی واحد نیست. ممکن است Familyهای سنگین، تعداد زیاد Linkها، Viewهای نامناسب یا ساختار مدل باعث افت عملکرد شده باشند. اما در پروژهای دیگر، مشکل اصلی میتواند شبکه، نحوه کار با Central Model یا حتی تقسیم نامناسب مسئولیت بین اعضای تیم باشد.
همین منطق درباره تداخلها، دوبارهکاری و تأخیر در هماهنگی نیز برقرار است. افزایش تعداد Clashها لزوماً به معنی ضعف مدلسازی نیست؛ شاید مدل مرجع مرتباً تغییر میکند یا تصمیمهای طراحی بهموقع تثبیت نمیشوند. در چنین شرایطی، اجرای Clash Detection بیشتر فقط تعداد گزارشها را افزایش میدهد، بدون آنکه مسئله اصلی حل شود. اگر گزارشهای Clash زیاد میشوند اما مسائل بسته نمیشوند، مقاله چرا Clash Detection بهتنهایی برای هماهنگی BIM کافی نیست؟ کمک میکند این نشانه از مسئله واقعی هماهنگی تفکیک شود.
مشاهده یک نشانه به معنی تشخیص علت آن نیست.
چارچوب دقیقتر تفکیک نشانه، علت نزدیک و علت ریشهای را در مشاور BIM چگونه مشکلات پروژه یا سازمان را تشخیص میدهد؟ توضیح دادهایم.
در پروژههای بحرانی، شباهت ظاهری مشکلات میتواند گمراهکننده باشد. دو پروژه ممکن است هر دو با تأخیر، مدلهای سنگین و نقشههای ناقص روبهرو باشند، اما به دو نوع مداخله کاملاً متفاوت نیاز داشته باشند. به همین دلیل، پیش از انتخاب ابزار یا راه حل، باید مشخص شود چه عاملی واقعاً مانع پیشرفت پروژه شده است.
ابتدا مشخص کنید چه چیزی مانع تحویل شده است
در پروژهای که با تأخیر یا بینظمی روبهرو شده، نقطه شروع نباید بررسی همه مشکلات موجود باشد. تیم ممکن است با دهها مسئله فنی، صدها Clash، تعداد زیادی Warning و بخشهای ناقص مدل مواجه باشد، اما همه این موارد به یک اندازه بر تحویل اثر نمیگذارند.
ابتدا باید مشخص شود چه خروجیهایی در موعد پیش رو باید تحویل شوند و وضعیت واقعی هرکدام چیست. سپس برای هر خروجی باید پرسید: چه چیزی مانع رسیدن آن به وضعیت قابل تحویل شده است؟
ممکن است یک مدل حجیم و کند باشد، اما اگر برای تحویل فعلی به اندازه کافی پایدار است، بهینهسازی آن الزاماً اولویت اول نیست. در مقابل، یک تصمیم حل نشده درباره مسیر رایزر ممکن است همزمان مدل مکانیک، برق، سقف کاذب، مقاطع و هماهنگی چند رشته را متوقف کرده باشد.
مهمترین مسئله پروژه همیشه بزرگترین یا واضحترین مشکل فنی نیست؛ مسئلهای است که بیشترین اثر را بر امکان تحویل دارد.
در این مرحله، بهتر است مشکلات بر اساس رابطه آنها با خروجیهای ضروری دسته بندی شوند: چه چیزی مستقیماً تحویل را متوقف کرده، چه چیزی فقط سرعت را کاهش داده و چه چیزی فعلاً اثر تعیین کنندهای ندارد.
این نگاه کمک میکند تیم به جای پخش کردن انرژی میان همه مشکلات موجود، ابتدا روی موانعی تمرکز کند که حذف آنها بیشترین اثر را بر نزدیک شدن پروژه به تحویل خواهد داشت.
گلوگاه اصلی پروژه را پیدا کنید
پس از مشخص شدن موانع تحویل، باید بررسی شود کدام یک از آنها جریان کار پروژه را بیش از بقیه محدود میکند. وجود تعداد زیادی مشکل به این معنی نیست که همه آنها باید همزمان حل شوند. در بسیاری از پروژهها، تعداد محدودی گلوگاه بخش بزرگی از تأخیر و دوبارهکاری را ایجاد میکنند.
گلوگاه میتواند فنی باشد؛ مانند کندی شدید مدل، ساختار نامناسب Linkها یا روش ناکارآمد تولید نقشه. اما ممکن است منشأ آن کاملاً متفاوت باشد: تأخیر در دریافت اطلاعات طراحی، انتظار برای تأیید کارفرما، نبود مسئول مشخص برای تصمیم گیری یا وابستگی چند رشته به خروجی یک تیم.
برای مثال، ممکن است صدها Clash در مدل وجود داشته باشد، اما اگر بیشتر آنها به یک مسیر تأسیساتی بستگی داشته باشند که هنوز درباره آن تصمیم گیری نشده است، بررسی تکتک تداخلها مسئله اصلی را حل نمیکند. ابتدا باید همان تصمیمی گرفته شود که امکان ادامه هماهنگی را برای چند رشته فراهم میکند.
گلوگاه جایی نیست که بیشترین مشکل دیده میشود؛ جایی است که بیشترین جریان کار در انتظار آن متوقف میشود.
تشخیص گلوگاه کمک میکند میان «مشکلات متعدد پروژه» و «محدودیت اصلی پروژه» تفاوت قائل شویم. هدف این نیست که پیش از ادامه کار همه ایرادها برطرف شوند؛ هدف این است که ابتدا مانعی حذف شود که با برطرف شدن آن، بیشترین بخش از جریان تحویل دوباره امکان حرکت پیدا میکند.
اولویتهای پروژه را بر اساس تحویل دوباره تنظیم کنید
پس از شناسایی گلوگاهها، لازم است اولویت فعالیتها دوباره بر اساس نیاز واقعی تحویل تنظیم شود. در پروژهای که تحت فشار زمانی قرار دارد، ادامه دادن همه فعالیتها با همان اولویت قبلی معمولاً باعث پخش شدن ظرفیت تیم و کندتر شدن بازیابی پروژه میشود.
در این مرحله، کارها را میتوان در سه گروه قرار داد: فعالیتهایی که برای تحویل فعلی ضروری هستند، فعالیتهایی که میتوانند تا پس از تثبیت شرایط به تعویق بیفتند، و فعالیتهایی که فعلاً باید متوقف شوند. این تصمیم ممکن است شامل به تعویق انداختن مدلسازی جزئیات کماهمیت، تکمیل Familyهای غیرضروری، اصلاحات صرفاً ظاهری یا تولید خروجیهایی باشد که برای موعد فعلی الزام مستقیم ندارند.
این رویکرد به معنی کاهش کیفیت یا حذف تعهدات پروژه نیست. هدف، تغییر موقت ترتیب انجام کارهاست تا منابع محدود تیم ابتدا صرف خروجیهایی شوند که بیشترین اثر را بر تحویل دارند.
در پروژهای که تحت فشار است، مشخص کردن کارهایی که فعلاً نباید انجام شوند به اندازه تعیین کارهای ضروری اهمیت دارد.
یکی از خطاهای رایج این است که تیم همچنان تلاش میکند همه بخشهای مدل را با سطح یکسانی از جزئیات و تکمیل پیش ببرد، حتی زمانی که بخشی از این اطلاعات برای مرحله فعلی موردنیاز نیست. بازتنظیم اولویتها باید مستقیماً به نیازهای تحویل، سطح اطلاعات موردنیاز و وابستگی میان رشتهها متصل باشد؛ نه صرفاً به میزان پیشرفت ظاهری هر مدل.
برای مسائل بحرانی، مسئول و مسیر تصمیم گیری مشخص کنید
پس از مشخص شدن اولویتها، هر مسئله بحرانی باید یک مسئول اقدام و یک مسیر روشن برای تصمیم گیری داشته باشد. در بسیاری از پروژهها، مشکل فقط این نیست که یک تداخل یا ابهام فنی وجود دارد؛ مسئله این است که مشخص نیست چه کسی باید آن را حل کند، چه کسی اختیار تصمیم دارد و چه زمانی موضوع باید بسته شود.
ممکن است BIM Coordinator مسئله را شناسایی کرده باشد، اما اختیار تغییر طراحی را نداشته باشد. تیم معماری ممکن است منتظر نظر سازه باشد و سازه نیز تصمیم را به کارفرما ارجاع داده باشد. در چنین شرایطی، مسئله از نظر فنی شناخته شده است، اما همچنان جریان کار چند رشته را متوقف میکند. اگر نقشها روی کاغذ تعریف شدهاند اما اختیار تصمیم و مسیر ارجاع روشن نیست، مقاله چرا پروژه BIM با وجود داشتن BEP باز هم از کنترل خارج میشود؟ این شکست کنترلی را دقیقتر بررسی میکند.
برای مسائل بحرانی حداقل باید این موارد مشخص باشند:
- مسئول اقدام
- فرد یا نقش تصمیمگیر
- اطلاعات یا تأیید موردنیاز
- موعد تصمیم
- معیار بسته شدن مسئله
مسئلهای که مسئول و نقطه تصمیم مشخص ندارد، عملاً هنوز وارد فرایند حل نشده است.
این شفاف سازی به خصوص در دورههای فشرده تحویل اهمیت زیادی دارد، چون تیم فرصت ندارد یک موضوع بارها میان افراد و رشتههای مختلف جابهجا شود. هدف این نیست که برای همه مسائل پروژه ساختار اداری سنگینی ایجاد شود؛ بلکه باید برای موانعی که مستقیماً بر تحویل اثر میگذارند، مالکیت و مسیر تصمیم گیری روشن باشد.
وقتی مسئولیت مشخص شود، تازه میتوان درباره نوع مداخله مناسب تصمیم گرفت: اصلاح مدل، تغییر گردشکار، افزایش ظرفیت، اتوماسیون یا اقدام دیگری که مستقیماً همان مانع را هدف قرار دهد.
فقط در نقاطی مداخله کنید که بر تحویل اثر دارند
پس از مشخص شدن گلوگاهها، اولویتها و مسئولیتها، میتوان درباره نوع مداخله تصمیم گرفت. در این مرحله مهم است که راه حل از روی مسئله انتخاب شود، نه اینکه ابتدا ابزار یا روش مشخصی انتخاب شود و سپس تلاش کنیم آن را به پروژه تحمیل کنیم.
گاهی مسئله واقعاً فنی است و باید مدل اصلاح شود؛ برای مثال Familyهای سنگین سادهسازی شوند، ساختار Linkها بازنگری شود یا روش تولید View و Sheet تغییر کند. در پروژهای دیگر ممکن است مشکل اصلی در تقسیم مسئولیت، توالی فعالیتها، چرخه هماهنگی یا تأخیر در تصمیم گیری باشد. در این شرایط، بهینهسازی مدل بهتنهایی اثر محدودی خواهد داشت.
اتوماسیون نیز فقط زمانی ارزشمند است که یک فعالیت تکراری، قابل پیشبینی و زمانبر به یکی از موانع واقعی تحویل تبدیل شده باشد. خودکار کردن فرایندی که مرتباً تغییر میکند یا به قضاوت انسانی وابسته است، ممکن است فقط پیچیدگی بیشتری ایجاد کند.
همین منطق درباره افزایش نیرو نیز صدق میکند. اگر گلوگاه پروژه کمبود ظرفیت باشد، اضافه کردن نیروی مناسب میتواند مؤثر باشد؛ اما اگر چند نفر در انتظار یک تصمیم یا ورودی مشترک هستند، افزایش تعداد افراد مسئله را حل نمیکند.
بهینهسازی مدل، اتوماسیون، تغییر گردشکار و افزایش نیرو راهحلهای از پیش تعیینشده نیستند؛ هرکدام فقط زمانی ارزش دارند که مانع مشخصی را برطرف کنند.
هدف اصلاح همه بخشهای پروژه نیست. باید مداخلاتی انتخاب شوند که با کمترین تغییر، بیشترین اثر را بر امکان تحویل ایجاد کنند. نمونه عملی این منطق را میتوان در تجربه بازگرداندن پروژه معماران مدام به مسیر تحویل دید؛ جایی که مسئله با افزایش نیرو حل نشد و مداخله روی مدل و گردشکار متمرکز شد.
جمعبندی
هر پروژهای که با تأخیر، دوباره کاری یا کندی مدل روبهرو شده لزوماً به مداخله بیرونی نیاز ندارد. اگر علت اصلی مشکل برای تیم روشن باشد، مسئولیتها مشخص باشند و اعضای داخلی تجربه و اختیار لازم برای اصلاح وضعیت را داشته باشند، معمولاً بهتر است بازیابی پروژه در داخل همان تیم انجام شود.
مداخله بیرونی زمانی ارزشمندتر میشود که خود تشخیص مسئله به مشکل تبدیل شده باشد. برای تصمیم اینکه این وضعیت واقعاً نیازمند مشاور است یا هنوز باید داخل تیم حل شود، راهنمای چه زمانی یک شرکت یا پروژه به مشاور BIM نیاز دارد؟ معیارهای تصمیم را تفکیک میکند. برای مثال، وقتی رشتههای مختلف علت تأخیر را به یکدیگر نسبت میدهند، چند راه حل قبلی نتیجه ندادهاند، یا مسائل فنی و مدیریتی بهقدری درهم تنیده شدهاند که تشخیص گلوگاه اصلی دشوار شده است.
نشانههای دیگری نیز میتوانند نیاز به نگاه بیرونی را تقویت کنند:
- چند رشته همزمان تحت تأثیر قرار گرفتهاند
- تیم درباره علت اصلی مشکل توافق ندارد
- اصلاحات قبلی فقط نشانهها را موقتاً کاهش دادهاند
- زمان باقیمانده اجازه آزمون و خطای طولانی نمیدهد
- افراد کلیدی پروژه درگیر فشار روزمره هستند و فرصت تحلیل ساختاری ندارند
ارزش مداخله بیرونی فقط در انجام بخشی از کار نیست؛ گاهی مهمترین نقش آن تشخیص مسئلهای است که تیم از داخل پروژه دیگر بهوضوح نمیبیند.
تصمیم برای استفاده از مشاور باید بر اساس پیچیدگی مسئله و هزینه ادامه وضعیت موجود گرفته شود، نه صرفاً شدت فشار پروژه. اگر تیم داخلی بتواند علت، مسئولیت و مسیر اصلاح را روشن کند، نیازی به پیچیدهتر کردن ساختار نیست. اما زمانی که همین سه مورد نامشخص ماندهاند، یک ارزیابی مستقل میتواند مسیر بازیابی را کوتاهتر و تصمیمها را دقیقتر کند. اگر پروژه یا سازمان به چنین ارزیابی مستقلی نیاز دارد، خدمت بهینهسازی BIM از تشخیص گلوگاه و تعیین اولویت اصلاح شروع میشود، نه از انتخاب یک ابزار یا راهحل از پیش تعیینشده.