متن مقاله
مقدمه
در پروژههای BIM، تغییر یک جزء اجتناب ناپذیر از فرایند طراحی، هماهنگی و توسعه اطلاعات است. محل یک بازشو جابهجا میشود، مسیر یک تأسیسات اصلاح میشود، مشخصات یک عنصر تغییر میکند یا بخشی از مدل بر اساس تصمیم جدید پروژه بازنگری میشود. مسئله اصلی اما خود تغییر نیست؛ مسئله این است که چه کسی حق دارد آن را پیشنهاد کند، چه کسی درباره آن تصمیم بگیرد، چه کسی آن را در مدل اعمال کند و چه زمانی نتیجه این تغییر میتواند مبنای عمل دیگران قرار گیرد.
در بسیاری از پروژهها این مرزها بهروشنی تعریف نشدهاند. دسترسی به مدل با اختیار تصمیم گیری اشتباه گرفته میشود، هماهنگی بین رشتهای به جای تأیید رسمی تلقی میشود و ارسال یا بارگذاری یک فایل به معنای انتشار معتبر آن فرض میشود. در چنین شرایطی ممکن است یک تغییر از نظر فنی درست باشد، اما مشخص نباشد بر اساس چه اختیاری انجام شده، چه کسی آن را پذیرفته و آیا سایر تیمها مجاز بودهاند بر مبنای آن کار کنند.
حاکمیت تغییر در BIM برای حل همین مسئله است. هدف آن محدود کردن تغییر نیست، بلکه تعریف زنجیرهای روشن از اختیار، مسئولیت، تأیید و انتشار است؛ بهگونهای که هر تغییر بتواند از زمان طرح شدن تا تبدیل شدن به اطلاعات معتبر و قابل استفاده، قابل ردیابی باشد.
تغییر در BIM فقط ویرایش مدل نیست
در یک پروژه BIM، هر تغییر در مدل الزاماً یک «تصمیم» نیست. برخی تغییرها صرفاً اصلاح خطا، تکمیل اطلاعات یا هماهنگ سازی مدل با تصمیمی هستند که پیشتر گرفته شده است. برای مثال اصلاح نام یک فضا، تصحیح پارامتر یک تجهیز یا بهروزرسانی یک مدل بر اساس نقشه مصوب، میتواند بدون ایجاد تصمیم طراحی جدید انجام شود. در مقابل، جابه جایی یک دیوار، تغییر ابعاد یک بازشو، اصلاح مسیر تأسیسات یا تغییر مشخصات یک سیستم ممکن است بر طراحی سایر رشتهها، هزینه، زمان یا الزامات پروژه اثر بگذارد.
تفاوت میان این دو وضعیت مهم است، زیرا در محیط BIM تغییر اطلاعات میتواند بسیار سریعتر از فرایند تصمیم گیری پروژه اتفاق بیفتد. کسی که به مدل دسترسی دارد ممکن است بتواند یک عنصر را در چند ثانیه تغییر دهد، در حالی که تصمیمی که پشت آن تغییر قرار دارد باید میان چند نقش یا سازمان بررسی و تأیید شود.
بنابراین مدیریت تغییر در BIM نباید فقط بر این سؤال متمرکز باشد که «چه کسی مدل را ویرایش کرده است؟». سؤال مهمتر این است که تغییر موردنظر چه ماهیتی داشته، بر چه اطلاعات یا تصمیمهایی اثر گذاشته و آیا اجرای آن نیازمند اختیار یا تأیید دیگری بوده است.
در یک فرایند کنترل شده، ویرایش مدل آخرین بخش قابل مشاهده یک زنجیره تصمیم است؛ نه خودِ تصمیم.
توانایی تغییر با اختیار تغییر یکی نیست
در محیط BIM، دسترسی فنی به مدل میتواند بسیار گسترده باشد. اعضای تیم ممکن است بتوانند عناصر را جابهجا کنند، پارامترها را تغییر دهند، Familyها را جایگزین کنند یا حتی بخشهایی از مدل را حذف و بازسازی کنند. اما این توانایی فنی به خودی خود هیچ اختیاری برای تصمیم گیری ایجاد نمیکند.
برای مثال، یک مدلساز مکانیک ممکن است تشخیص دهد که مسیر یک کانال با سازه تداخل دارد و حتی بتواند مسیر جدیدی برای آن ترسیم کند. با این حال، اگر مسیر پیشنهادی بر ارتفاع سقف، معماری فضا یا عملکرد سیستم اثر بگذارد، تصمیم نهایی ممکن است نیازمند بررسی و تأیید نقشهای دیگری باشد. در اینجا مدلساز توانایی اعمال تغییر را دارد، اما اختیار تعیین اینکه تغییر باید به همان شکل اجرا شود الزاماً متعلق به او نیست.
همین مسئله در سطح مدیریتی نیز وجود دارد. داشتن عنوانی مانند BIM Manager یا BIM Coordinator نیز به این معنا نیست که آن فرد در همه موضوعات پروژه اختیار طراحی یا قراردادی دارد. نقش او ممکن است کنترل فرایند، هماهنگی اطلاعات یا مدیریت گردشکار باشد، نه تصمیم گیری درباره محتوای تخصصی هر رشته.
در نتیجه، یکی از اصول پایه حاکمیت BIM این است که دسترسی، مسئولیت اجرایی و اختیار تصمیم گیری از یکدیگر تفکیک شوند.
دسترسی به مدل مشخص میکند چه کسی میتواند تغییر ایجاد کند؛ ساختار اختیار مشخص میکند چه کسی حق دارد درباره آن تغییر تصمیم بگیرد.
پنج سطح مسئولیت: پیشنهاد، تصمیم، اعمال تغییر، تأیید و انتشار
برای کنترل تغییر در BIM، بهتر است مسئولیت تغییر به یک نقش واحد نسبت داده نشود. در بسیاری از پروژهها، یک نفر مسئله را شناسایی میکند، فرد دیگری درباره تغییر تصمیم میگیرد، شخص دیگری آن را در مدل اعمال میکند و در نهایت نقش یا واحد دیگری مسئول تأیید و انتشار اطلاعات است.
این زنجیره را میتوان در پنج سطح تفکیک کرد:
پیشنهاد: شناسایی نیاز به تغییر و ارائه راهحل یا درخواست اصلاح.
تصمیم: تعیین اینکه تغییر باید انجام شود یا خیر و در چه محدودهای.
اعمال تغییر: پیادهسازی تصمیم در مدل، نقشه، پارامترها یا سایر اطلاعات پروژه.
تأیید: بررسی اینکه تغییر مطابق تصمیم، الزامات فنی و گردشکار پروژه انجام شده است.
انتشار: در دسترس قرار دادن نسخه تأیید شده برای استفادهای که از قبل مشخص شده است.
این پنج مسئولیت ممکن است در پروژههای کوچک میان تعداد محدودی از افراد توزیع شوند و در پروژههای بزرگ میان چند تیم و سازمان قرار گیرند. مهم این نیست که برای هر مرحله یک عنوان شغلی جداگانه تعریف شود؛ مهم این است که مشخص باشد در هر مرحله چه کسی اختیار اقدام یا تصمیم دارد.
تفکیک این سطوح از یک خطای رایج جلوگیری میکند: اینکه چون یک فرد تغییر را پیشنهاد کرده یا در مدل اعمال کرده است، همان فرد را صاحب تصمیم نهایی یا مسئول انتشار نیز بدانیم.
تغییر کنترل شده زمانی شکل میگیرد که مسیر آن از پیشنهاد تا انتشار، بدون ابهام میان نقشها توزیع شده باشد.
اختیار تغییر از کجا میآید؟
اختیار تغییر در یک پروژه BIM نباید از روی عنوان شغلی، دسترسی نرمافزاری یا سابقه افراد حدس زده شود. این اختیار باید از یک ساختار مشخص ناشی شود؛ ساختاری که معلوم کند چه کسی در چه موضوعی حق تصمیم گیری دارد و این حق بر چه مبنایی به او واگذار شده است.
منشأ اختیار میتواند در پروژههای مختلف متفاوت باشد. گاهی از قرارداد و شرح خدمات میآید، گاهی از مسئولیت طراحی یک رشته، گاهی از تفویض اختیار سازمانی و در مواردی از رویهها و گردشکارهای مصوب پروژه. اسنادی مانند BEP، ماتریس مسئولیت یا روشهای اجرایی نیز میتوانند این حدود را ثبت و عملیاتی کنند، اما وجود یک عنوان در این اسناد به تنهایی جایگزین منشأ واقعی اختیار نمیشود.
برای مثال، ممکن است BIM Coordinator مسئول هماهنگی مدلها و ثبت تداخلها باشد، اما این مسئولیت لزوماً به او اجازه نمیدهد درباره تغییر طراحی سازه یا معماری تصمیم نهایی بگیرد. به همین ترتیب، مدیر پروژه میتواند اختیار مدیریتی گستردهای داشته باشد، اما تصمیم تخصصی درباره یک سیستم ممکن است همچنان در حوزه مسئولیت طراح مربوط باقی بماند.
بنابراین در حاکمیت تغییر باید دو موضوع از هم جدا شوند: چه کسی مسئول اجرای فرایند است و چه کسی صاحب اختیار تصمیم است.
هرچه این مرزها از ابتدا شفافتر باشند، احتمال اینکه تصمیمها بر اساس برداشت شخصی، نفوذ سازمانی یا دسترسی فنی گرفته شوند کمتر خواهد شد.
مالک مدل لزوماً مالک تصمیم نیست
در پروژههای BIM معمولاً هر رشته مسئول تولید و نگهداری بخشی از اطلاعات است. تیم معماری مدل معماری را توسعه میدهد، تیم سازه اطلاعات سازه را مدیریت میکند و تیمهای تأسیسات نیز مسئول مدلهای تخصصی خود هستند. اما این مالکیت اطلاعاتی نباید با مالکیت تصمیم اشتباه گرفته شود.
ممکن است یک تغییر در مدل معماری در نتیجه نیاز سازه، هماهنگی تأسیسات، تصمیم کارفرما یا محدودیت اجرایی ایجاد شود. در چنین شرایطی، تیم معماری همچنان مسئول اعمال صحیح تغییر در مدل خود است، اما منشأ تصمیم الزاماً در همان تیم قرار ندارد.
همین موضوع در جهت معکوس نیز صادق است. اینکه یک تیم مسئول یک مدل است به این معنا نیست که سایر رشتهها میتوانند مستقیماً در آن مدل تغییر ایجاد کنند. درخواست تغییر باید از مسیر مشخص عبور کند تا مسئولیت اطلاعات و اختیار تصمیم با یکدیگر مخلوط نشوند.
این تفکیک به ویژه در پروژههای بزرگ اهمیت دارد، زیرا یک تغییر کوچک در یک مدل میتواند چندین رشته و خروجی دیگر را تحت تأثیر قرار دهد. اگر مسئول نگهداری مدل، صاحب تصمیم نیز فرض شود، خطر تصمیم گیری خارج از حدود مسئولیت افزایش پیدا میکند.
بنابراین باید میان سه مفهوم تفاوت روشن وجود داشته باشد: مسئول تولید اطلاعات، صاحب اختیار تصمیم و مسئول انتشار اطلاعات.
مدل میتواند متعلق به یک تیم باشد، اما تصمیمی که محتوای آن را تغییر میدهد ممکن است از جای دیگری در ساختار پروژه صادر شود.
کنترل داخلی، هماهنگی و تأیید رسمی یک چیز نیستند
در فرایند BIM، یک تغییر ممکن است از چند مرحله بررسی عبور کند، اما عبور از هر مرحله به معنای تأیید نهایی آن نیست. این تفاوت باید از ابتدا روشن باشد، زیرا یکی از رایجترین خطاها این است که کنترل فنی، هماهنگی بین رشتهای و تأیید رسمی به جای یکدیگر استفاده شوند.
کنترل داخلی معمولاً بررسی میکند که اطلاعات تولیدشده از نظر کیفیت، استانداردهای مدلسازی و الزامات همان تیم صحیح باشد.
هماهنگی بین رشتهای بررسی میکند که اطلاعات یک رشته با سایر مدلها و نیازهای پروژه تعارض نداشته باشد.
اما تأیید رسمی مرحلهای متفاوت است و باید توسط شخص یا نقشی انجام شود که برای آن تصمیم مشخص اختیار لازم را دارد.
برای مثال، ممکن است تغییر مسیر یک کانال از نظر مدلسازی صحیح باشد و پس از Clash Detection نیز با سازه تداخلی نداشته باشد. این دو نتیجه نشان میدهند که تغییر از نظر فنی و هماهنگی قابل قبول است، اما اگر تغییر بر ارتفاع سقف یا طراحی معماری اثر بگذارد، هنوز ممکن است نیازمند تأیید مرجع دیگری باشد.
بنابراین حل شدن یک Clash، بسته شدن یک Issue یا عبور یک مدل از کنترل کیفیت، به تنهایی نباید به معنای تأیید نهایی تصمیم تلقی شود.
هر مرحله باید پاسخ یک سؤال مشخص را بدهد: آیا اطلاعات درست تولید شده، آیا هماهنگ است، و آیا فرد دارای اختیار آن را برای مرحله بعد پذیرفته است؟
انتشار؛ نقطهای که اطلاعات برای استفاده مشخص معتبر میشود
در پروژه BIM، قرار گرفتن یک فایل روی سرور، ارسال آن در پیام رسان یا حتی بارگذاری آن در CDE به خودی خود به معنای انتشار رسمی نیست. انتشار زمانی معنا پیدا میکند که اطلاعات پس از طی کنترلها و تأییدهای لازم، برای یک هدف مشخص در اختیار سایر افراد یا تیمها قرار گیرد.
این هدف اهمیت زیادی دارد. یک مدل ممکن است برای هماهنگی بین رشتهای مناسب باشد، اما هنوز برای تهیه نقشه اجرایی یا استفاده در کارگاه مجاز نباشد. به همین ترتیب، اطلاعاتی که برای بررسی کارفرما منتشر شده است الزاماً همان وضعیتی را ندارد که برای اجرا یا تحویل نهایی مورد استفاده قرار میگیرد.
بنابراین انتشار باید همیشه با دو پرسش همراه باشد: چه کسی اجازه انتشار این اطلاعات را دارد؟ و گیرنده مجاز است از آن برای چه کاری استفاده کند؟
اگر این دو موضوع روشن نباشند، تیمها ممکن است بر اساس اطلاعاتی تصمیم بگیرند که هنوز در مرحله بررسی بوده، یا نسخهای را مبنای کار قرار دهند که برای آن کاربرد خاص تأیید نشده است. در این شرایط، حتی اگر مدل از نظر فنی صحیح باشد، استفاده از آن میتواند زود هنگام یا خارج از حدود مجاز باشد.
انتشار، فقط انتقال فایل نیست؛ اعلام این است که یک مجموعه اطلاعات برای یک کاربرد مشخص از مسیر کنترل عبور کرده و میتواند وارد مرحله بعدی فرایند پروژه شود.
هر وضعیت اطلاعات چه نوع استفادهای را مجاز میکند؟
در یک فرایند کنترل شده BIM، معتبر بودن اطلاعات به وضعیت آن وابسته است. همه اطلاعات موجود در پروژه برای یک نوع استفاده تولید نمیشوند و قرار گرفتن آنها در یک محیط مشترک نیز به این معنا نیست که همه اعضای پروژه مجازند بر اساس آنها تصمیم بگیرند یا اجرا کنند.
اطلاعات در وضعیتWIP هنوز در حال توسعه است و معمولاً برای استفاده داخلی همان تیم در نظر گرفته میشود. وقتی اطلاعات وارد وضعیتShared میشود، میتواند برای هدفی مشخص مانند هماهنگی، بازبینی یا دریافت نظر در اختیار سایر تیمها قرار گیرد. اما Shared بودن نباید با مجاز بودن برای اجرا یا استفاده نهایی اشتباه گرفته شود.
اطلاعاتPublished از مسیرهای تعریف شده کنترل و تأیید عبور کرده و برای کاربرد مشخصی منتشر شده است. همین کاربرد باید روشن باشد؛ برای مثال اطلاعاتی که برای هماهنگی منتشر شده، الزاماً برای ساخت مناسب نیست. در نهایت، اطلاعاتArchive بهعنوان سابقه نگهداری میشود تا نسخهها، تصمیمها و وضعیتهای گذشته قابل ردیابی باقی بمانند.
بنابراین وضعیت اطلاعات فقط یک برچسب مدیریتی نیست. هر وضعیت باید به روشنی مشخص کند که اطلاعات در چه مرحلهای قرار دارد و دیگران مجازند با آن چه کنند.
کنترل واقعی زمانی شکل میگیرد که وضعیت اطلاعات، حدود استفاده از آن را نیز مشخص کند.
چه زمانی تغییر از پیشنهاد به تصمیم الزامآور تبدیل میشود؟
در پروژههای BIM، بسیاری از تغییرها ابتدا به صورت یک نظر، درخواست، Issue، پیشنهاد هماهنگی یا نتیجه یک جلسه مطرح میشوند. اما هیچ کدام از این موارد به تنهایی به این معنا نیست که تغییر باید حتماً اجرا شود. فاصله میان «پیشنهاد» و «تصمیم الزامآور» همان جایی است که ساختار اختیار اهمیت پیدا میکند.
برای مثال، یک تیم ممکن است جابهجایی یک بازشو را برای رفع تداخل پیشنهاد کند. این پیشنهاد میتواند از نظر فنی منطقی باشد، اما تا زمانی که مرجع دارای اختیار آن را نپذیرفته باشد، نباید صرفاً به دلیل ثبت شدن در جلسه یا سیستم مدیریت Issue بهعنوان تصمیم نهایی تلقی شود.
تصمیم زمانی الزام آور میشود که از مسیر تعریف شده پروژه عبور کرده، توسط مرجع دارای اختیار تأیید شده و به گونهای ثبت شده باشد که دامنه، نسخه و اثر آن برای تیمهای مربوط قابل تشخیص باشد.
در اینجا باید میان اعتبار اطلاعات و الزام قراردادی نیز تفاوت قائل شد. انتشار یک مدل یا سند میتواند آن را برای یک هدف مشخص معتبر کند، اما الزام قراردادی تنها زمانی شکل میگیرد که سازوکار قراردادی و اختیار مربوط نیز آن تصمیم را پشتیبانی کند.
بنابراین نه هر Comment یک دستور است، نه هر Issue یک تصمیم، و نه هر فایل Published الزاماً یک تغییر قراردادی ایجاد میکند.
تغییر زمانی از پیشنهاد به تصمیم تبدیل میشود که اختیار، پذیرش و ثبت رسمی آن بهطور مشخص قابل اثبات باشد.
مسیر تغییر از درخواست تا انتشار چگونه باید قابل ردیابی باشد؟
اگر تغییر در BIM فقط در خود مدل دیده شود، بخش مهمی از منطق تصمیم از بین میرود. یک عنصر ممکن است تغییر کرده باشد، اما بدون سابقه روشن مشخص نباشد چه کسی آن را درخواست کرده، بر چه مبنایی پذیرفته شده، چه کسی آن را اعمال کرده و کدام نسخه برای استفاده دیگران معتبر بوده است.
به همین دلیل، مسیر تغییر باید از ابتدا تا انتها قابل ردیابی باشد. این مسیر معمولاً از ثبت نیاز یا مسئله آغاز میشود، سپس به پیشنهاد تغییر و شناسایی مرجع دارای اختیار تصمیم میرسد. پس از تصمیم، تغییر در اطلاعات پروژه اعمال میشود و از مراحل کنترل، هماهنگی و تأیید عبور میکند. در نهایت، نسخه موردنظر با هدف مشخص منتشر میشود و سابقه آن باید باقی بماند.
آنچه اهمیت دارد الزاماً استفاده از یک نرمافزار یا فرم خاص نیست؛ مهم این است که بتوان بعداً پاسخ داد:
چه چیزی تغییر کرد؟
چرا تغییر کرد؟
چه کسی آن را درخواست و چه کسی تأیید کرد؟
تغییر در کدام نسخه اعمال شد؟
از چه زمانی دیگران مجاز بودند بر اساس آن کار کنند؟
این زنجیره باعث میشود تصمیمها فقط در جلسات، پیامها یا حافظه افراد باقی نمانند.
تغییر زمانی قابل کنترل است که بتوان مسیر آن را از مسئله اولیه تا نسخه منتشرشده، همراه با تصمیمها و مسئولیتهای میان این دو نقطه بازسازی کرد.
وقتی معماری اختیار مشخص نیست چه اتفاقی میافتد؟
وقتی حدود اختیار در پروژه مشخص نباشد، تغییرها لزوماً متوقف نمیشوند؛ فقط کنترل ناپذیر میشوند. افراد همچنان مسئلهها را حل میکنند، مدلها تغییر میکنند و تصمیمها گرفته میشوند، اما مشخص نیست هر تصمیم تا چه اندازه معتبر است و چه کسی مسئول پیامد آن خواهد بود.
در چنین شرایطی، چند الگوی شکست تکرار میشود: یک تغییر ممکن است بر اساس نظر شفاهی اجرا شود و بعداً توسط فرد دیگری رد شود؛ هماهنگی بین رشتهای ممکن است بهاشتباه بهعنوان تأیید طراحی تلقی شود؛ یک مدلساز ممکن است برای حل سریع یک مشکل، تغییری ایجاد کند که از حدود اختیار او خارج است؛ یا تیمی کار خود را بر اساس نسخهای ادامه دهد که هنوز برای آن استفاده منتشر نشده است.
مشکل زمانی جدیتر میشود که چند مرجع مختلف درباره یک موضوع دستورهای متفاوت بدهند. در این حالت، اختلاف فقط فنی نیست؛ پروژه دیگر نمیتواند به سادگی تشخیص دهد کدام تصمیم معتبرتر است، چه کسی حق لغو تصمیم قبلی را داشته و از چه زمانی اطلاعات جدید جایگزین نسخه قبلی شده است.
نتیجه معمولاً دوباره کاری، تأخیر، اختلاف میان تیمها و دشواری در تعیین مسئولیت است. حتی یک CDE منظم نیز نمیتواند این ضعف را به تنهایی حل کند، اگر ساختار اختیار پشت فرایند مشخص نباشد.
فقدان معماری اختیار به این معنا نیست که تصمیمی گرفته نمیشود؛ به این معناست که تصمیمها بدون مرجع روشن، بدون مرز مشخص و با قابلیت دفاع محدود گرفته میشوند.
جمعبندی
حاکمیت تغییر یعنی اختیار پیش از اختلاف تعریف شده باشد.
حاکمیت تغییر زمانی مؤثر است که پروژه پیش از بروز اختلاف مشخص کرده باشد چه کسی میتواند تغییر را پیشنهاد کند، چه کسی درباره آن تصمیم بگیرد، چه کسی آن را اعمال کند، چه کسی تأیید کند و چه کسی اجازه انتشار اطلاعات را دارد. اگر این مرزها فقط پس از بروز مشکل بررسی شوند، پروژه عملاً در حال واکنش به شکست است، نه مدیریت آن.
هدف از تعریف این ساختار، افزایش بوروکراسی یا کند کردن تصمیم گیری نیست. برعکس، هرچه مسیر اختیار روشنتر باشد، تیمها سریعتر میتوانند تشخیص دهند یک موضوع باید به چه کسی ارجاع شود و چه نوع تأییدی برای ادامه کار لازم است. همچنین تصمیمها کمتر به روابط شخصی، برداشتهای شفاهی یا حافظه افراد وابسته میشوند.
در یک فرایند بالغ، نقشها فقط با عنوان شغلی تعریف نمیشوند؛ حدود تصمیم گیری، مسیر ارجاع، سطح تأیید و اختیار انتشار نیز برای هر موضوع مشخص است. به این ترتیب، وقتی یک تغییر ایجاد میشود، پروژه مجبور نیست از ابتدا بحث کند که «چه کسی حق تصمیم داشت؟»
حاکمیت تغییر یعنی مسئولیت و اختیار قبل از وقوع اختلاف طراحی شده باشند؛ نه اینکه بعد از بروز دوبارهکاری یا ادعا، تازه تلاش کنیم آنها را بازسازی کنیم.