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