متن مقاله
مقدمه
استفاده از BIM معمولاً با این انتظار همراه است که با شکل گیری مدل، تولید نقشهها سریعتر، هماهنگتر و کمخطاتر شود. با این حال، در بسیاری از پروژهها تیمها پس از مدتی با وضعیتی متفاوت روبهرو میشوند: تنظیم Viewها زمان بر است، اطلاعات بارها به صورت دستی وارد نقشه میشود، تغییرات مدل باعث اصلاح چند باره مدارک میشود و آمادهسازی هر Sheet به مجموعهای از کارهای تکراری تبدیل میشود.
در چنین شرایطی، مشکل لزوماً کمبود مهارت کاربران یا کندی Revit نیست. ساختار مدل، کیفیت Familyها، استانداردهای مستندسازی، نحوه مدیریت تغییرات و گردشکار تیم همگی میتوانند مستقیماً بر زمان تولید مدارک اثر بگذارند.
برای پیدا کردن علت واقعی، باید فرایند تولید نقشه را به عنوان یک سیستم بررسی کرد؛ زیرا کندی در خروجی معمولاً فقط نشانهای از مشکلی است که در یکی از مراحل قبل شکل گرفته است.
تولید نقشه از BIM قرار بود سریعتر باشد؛ پس مشکل کجاست؟
یکی از انتظارهای اصلی از BIM این است که اطلاعات یک بار در مدل ایجاد شود و سپس بتوان از همان منبع، پلانها، نماها، مقاطع، جداول و سایر مدارک پروژه را تولید کرد. از این نظر، BIM باید بخشی از دوباره کاری موجود در فرایندهای سنتی ترسیم را حذف کند و هماهنگی میان مدل و نقشهها را افزایش دهد.
اما در عمل همیشه چنین اتفاقی نمیافتد. در برخی پروژهها، با وجود صرف زمان قابل توجه برای مدلسازی، تهیه هر نقشه همچنان نیازمند تنظیمات متعدد، اصلاح گرافیک، جابهجایی Tagها، کنترل Dimensionها، تکمیل دستی اطلاعات و بازبینیهای مکرر است. حتی یک تغییر نسبتاً ساده در مدل ممکن است باعث شود چندین View و Sheet دوباره بررسی و اصلاح شوند.
در این شرایط معمولاً اولین واکنش، نسبت دادن مشکل به سرعت کاربران، پیچیدگی Revit یا ضعف سختافزار است. این عوامل میتوانند مؤثر باشند، اما در بسیاری از موارد علت اصلی در جای دیگری قرار دارد: مدل برای تولید مدارک مناسب سازماندهی نشده، Familyها رفتار قابل پیش بینی ندارند، استاندارد مستندسازی مشخص نیست یا بخشی از اطلاعات موجود در مدل دوباره به صورت دستی در نقشهها تولید میشود.
بنابراین سرعت تولید نقشه را نباید فقط با سرعت کار یک کاربر سنجید. اگر برای هر خروجی بخش قابل توجهی از اطلاعات باید دوباره ساخته، اصلاح یا کنترل شود، مشکل در سطح فرایند تولید اطلاعات قرار دارد، نه صرفاً در سرعت ترسیم.
زمان تولید نقشه دقیقاً کجا مصرف میشود؟
برای کاهش زمان تولید نقشه، قبل از هر اصلاح فنی باید مشخص شود زمان واقعاً در کدام بخش فرایند از دست میرود. این زمان فقط صرف ترسیم یا قرار دادن View روی Sheet نمیشود. بخش قابل توجهی از آن ممکن است در اصلاح، کنترل، هماهنگی و دوبارهکاری مصرف شود.
به طور معمول، زمان مستندسازی را میتوان در چند گروه بررسی کرد:
- ایجاد و تنظیم Viewها
- اعمال تنظیمات گرافیکی و Visibility
- Dimensioning،Tagging و Annotation
- چیدمان Viewها روی Sheet
- کنترل اطلاعات و هماهنگی بین رشتهای
- اصلاح مدارک پس از تغییرات مدل
- بازبینی و کنترل کیفیت نهایی
نکته مهم این است که همه این زمانها ارزش یکسانی ندارند. بخشی از زمان، مستقیماً صرف تولید مدارک مورد نیاز پروژه میشود؛ اما بخشی دیگر برای جبران ضعفهای قبلی فرایند مصرف میشود. برای مثال، تنظیم مجدد یک View Template، اصلاح دستی اطلاعاتی که باید از مدل خوانده شود یا کنترل دوباره نقشه پس از یک تغییر کنترل نشده، زمان تولید واقعی نیست؛ بلکه زمان بازیابی از یک مشکل ساختاری است.
به همین دلیل، تنها اندازه گیری مدت تهیه هر Sheet تصویر دقیقی از عملکرد تیم ارائه نمیدهد. باید مشخص شود چه مقدار از این زمان صرف تولید خروجی و چه مقدار صرف اصلاح، هماهنگی و دوبارهکاری شده است.
تا زمانی که محل مصرف زمان مشخص نباشد، راهکارهایی مانند افزایش نیرو، خرید سختافزار یا استفاده از اتوماسیون ممکن است فقط یکی از نشانهها را سریعتر کنند، بدون اینکه علت اصلی کندی برطرف شود.
این همان منطق تشخیصی است که در مقاله بهینهسازی BIM چیست و چه زمانی یک شرکت به آن نیاز دارد؟ برای جدا کردن نشانه، علت و مداخله توضیح داده شده است.
چرا یک مدل ظاهراً صحیح میتواند برای تولید نقشه نامناسب باشد؟
در BIM، صحیح بودن هندسه به تنهایی به این معنا نیست که مدل برای تولید مدارک نیز مناسب است. یک مدل ممکن است در نمای سه بعدی کاملاً قابل قبول به نظر برسد، اما هنگام تهیه پلان، مقطع، نما یا Schedule مشکلات متعددی ایجاد کند.
یکی از دلایل رایج، روش نامناسب مدلسازی است. تفکیک بیش از حد عناصر، استفاده نادرست از Categoryها، ایجاد جزئیات غیر ضروری یا مدلسازی با روشی که رفتار مناسبی در Viewهای دو بعدی ندارد، مستقیماً بر زمان مستندسازی اثر میگذارد. در چنین شرایطی تیم مجبور میشود بخشی از ضعف مدل را با تنظیمات گرافیکی، Detail Item،Masking Region یا اصلاحات دستی جبران کند.
مشکل دیگر، بیش مدلسازی است. جزئیات بیشتر همیشه به معنی مدل بهتر نیست. اگر هندسهای در خروجی مورد نیاز پروژه نقشی نداشته باشد، ممکن است فقط باعث افزایش حجم مدل، کندی Regeneration، شلوغی Viewها و افزایش زمان کنترل شود.
مدل مناسب برای تولید نقشه باید علاوه بر هندسه صحیح، رفتار قابل پیشبینی در Viewهای مختلف، ساختار اطلاعاتی مناسب و سطح جزئیات متناسب با نیاز مدارک داشته باشد.
به همین دلیل، ارزیابی یک مدل فقط از روی ظاهر سه بعدی آن کافی نیست.
مدل قابل مشاهده لزوماً مدل قابل مستندسازی نیست.
Familyهای نامناسب چگونه تولید مدارک را کند میکنند؟
Family فقط یک عنصر سهبعدی نیست. نحوه طراحی آن میتواند مستقیماً بر کیفیت و سرعت تولید نقشه، Schedule و سایر خروجیهای پروژه اثر بگذارد.
یکی از مشکلات رایج، استفاده از Familyهایی است که هندسه بسیار پیچیده، Nested Familyهای متعدد یا جزئیات غیرضروری دارند. این نوع Familyها ممکن است مدل را سنگین کنند و باعث کندی در باز شدن Viewها، Regeneration و کنترل گرافیکی شوند. با این حال، مشکل فقط عملکرد نرمافزار نیست.
اگر Category، Subcategory،Visibility Setting یا نمایش نمادین یک Family درست تعریف نشده باشد، کاربران مجبور میشوند در هر View آن را به صورت جداگانه اصلاح کنند. همین مسئله میتواند به استفاده گسترده از Override، Detail Line، Masking Region یا سایر اصلاحات دستی منجر شود.
ساختار اطلاعاتی Family نیز اهمیت زیادی دارد. نبود Parameterهای مناسب، نامگذاری نا منظم یا ذخیره اطلاعات به شکلی که امکان Tagging و Scheduling مناسب را فراهم نکند، باعث میشود همان اطلاعات دوباره در نقشهها تایپ یا کنترل شوند.
در یک سیستم مستندسازی مناسب،Family باید بتواند در مقیاسها و Viewهای مختلف رفتار قابل پیش بینی داشته باشد و اطلاعات مورد نیاز نقشهها را در اختیار ابزارهایی مانند Tag و Schedule قرار دهد.
بنابراین کیفیت Family را نباید فقط بر اساس ظاهر سه بعدی آن سنجید. Family بخشی از سیستم تولید اطلاعات و مدارک پروژه است، نه صرفاً یک شیء مدلشده.
نبود استاندارد مستندسازی چگونه زمان تولید نقشه را افزایش میدهد؟
حتی اگر مدل و Familyها به درستی ساخته شده باشند، نبود یک استاندارد مشخص برای مستندسازی میتواند بخش زیادی از زمان تیم را مصرف کند. وقتی هر کاربر Viewها، تنظیمات گرافیکی و Sheetها را بر اساس روش شخصی خود آماده میکند، بخش قابل توجهی از فرایند تولید مدارک در هر پروژه و حتی برای هر نقشه دوباره تکرار میشود.
استاندارد مستندسازی باید مشخص کند Viewها چگونه ایجاد، نامگذاری و سازماندهی شوند، چه View Templateهایی برای انواع مختلف نقشه به کار رود، Filterها و تنظیمات Visibility چگونه تعریف شوند و مقیاس،Detail Level و شیوه نمایش عناصر در هر نوع خروجی چه باشد. همین منطق باید برای Sheetها، Title Blockها، شمارهگذاری و چیدمان مدارک نیز وجود داشته باشد.
نبود این ساختار معمولاً چند پیامد دارد:
- Viewهای مشابه ظاهر متفاوتی پیدا میکنند.
- تنظیمات گرافیکی بارها به صورت دستی تکرار میشوند.
- کنترل کیفیت دشوارتر میشود.
- انتقال کار میان اعضای تیم زمان بیشتری میگیرد.
- اصلاح یک استاندارد نیازمند تغییر جداگانه تعداد زیادی View است.
View Template در چنین سیستمی فقط ابزاری برای تنظیم رنگ و ضخامت خطوط نیست؛ بلکه یکی از ابزارهای کنترل و تکرار پذیری فرایند مستندسازی است.
هرچه تصمیمهای مربوط به نحوه تولید نقشه بیشتر به تشخیص لحظهای کاربران وابسته باشد، زمان و تنوع خروجی افزایش مییابد. استاندارد مستندسازی خوب، تصمیمهای تکراری را یک بار تعریف میکند تا تیم مجبور نباشد آنها را در هر نقشه دوباره اتخاذ کند.
وقتی اطلاعات مدل دوباره به صورت دستی وارد نقشه میشود
یکی از نشانههای نا کارآمدی در مستندسازی BIM این است که اطلاعاتی که از قبل در مدل وجود دارد، دوباره به صورت دستی در نقشهها وارد شود. این کار معمولاً در قالب متن، Note، جدول، Legend یا Annotationهای مستقل دیده میشود.
برای مثال، اگر نوع یک تجهیز، کد یک عنصر، مشخصات یک فضا یا اطلاعات مصالح در Parameterهای مدل ثبت شده باشد، اما همان اطلاعات در نقشه به صورت دستی تایپ شود، عملاً دو منبع اطلاعاتی ایجاد شده است. از این لحظه به بعد، هر تغییر باید در هر دو محل اعمال شود و احتمال ناهماهنگی نیز افزایش پیدا میکند.
مشکل اصلی فقط زمان تایپ نیست. هر داده تکراری باید در مراحل بعدی کنترل، اصلاح و دوباره تأیید شود. در پروژههای بزرگ، همین تکرارهای کوچک میتوانند به حجم قابل توجهی از کار غیرضروری تبدیل شوند.
البته همه Annotationها نباید خودکار یا مستقیماً وابسته به مدل باشند Dimensioning، توضیحات اجرایی و برخی تصمیمهای گرافیکی همچنان به قضاوت حرفهای نیاز دارند. مسئله زمانی ایجاد میشود که دادهای ساختاریافته در مدل وجود دارد اما فرایند مستندسازی نتواند از آن استفاده کند.
در یک گردشکار مناسب، اطلاعات تا حد امکان از منبع اصلی خود خوانده میشود و ابزارهایی مانند Tag، Schedule و Parameter برای انتقال آن به مدارک به کار میروند.
هر بار که یک اطلاعات موجود در مدل دوباره تایپ میشود، باید پرسید چرا سیستم مستندسازی نتوانسته همان اطلاعات را مستقیماً استفاده کند.
تغییرات مکرر مدل چرا نقشهها را دوباره کاری میکند؟
یکی از مهمترین دلایل طولانی شدن فرایند مستندسازی، تغییرات مکرری است که پس از شروع تولید نقشه در مدل اتفاق میافتد. در این شرایط، مشکل الزاماً از روش مستندسازی نیست؛ ممکن است اطلاعات ورودی هنوز به ثبات کافی نرسیده باشند.
هر تغییر در معماری، سازه یا تأسیسات میتواند زنجیرهای از اصلاحات را ایجاد کند. جابهجایی یک دیوار ممکن است Dimensionها، Tagها، Detailها، مقاطع و حتی چیدمان بعضی Sheetها را تحت تأثیر قرار دهد. اگر این تغییرات در چند رشته به صورت هم زمان و بدون یک فرایند مشخص هماهنگی انجام شوند، بخش زیادی از زمان تیم صرف بازبینی و اصلاح مدارکی میشود که قبلاً آماده شدهاند.
این مسئله زمانی شدیدتر میشود که وضعیت اطلاعات مشخص نباشد؛ برای مثال، تیم نداند کدام مدل یا تصمیم مبنای رسمی تولید نقشه است، چه زمانی یک تغییر تأیید شده و از چه مرحلهای به بعد باید در مدارک اعمال شود.
در چنین شرایطی، سرعت بالای تیم مستندسازی هم نمیتواند مشکل را حل کند. اگر ورودیها دائماً تغییر کنند، خروجی نیز دائماً نیازمند بازنگری خواهد بود.
به همین دلیل، تولید سریع نقشه فقط به کیفیت مدل و Template وابسته نیست. زمان بندی هماهنگی، کنترل تغییرات و مشخص بودن نقطهای که اطلاعات برای تولید مدارک قابل اتکا میشوند، نقش مستقیمی در بهرهوری دارند.
فرایند مستندسازی نمیتواند بیثباتی مداوم اطلاعات بالادست را جبران کند.
مشکل همیشه فنی نیست؛ گردشکار تیم هم میتواند گلوگاه باشد
گاهی مدل، Familyها و استانداردهای مستندسازی کیفیت مناسبی دارند، اما تولید نقشه همچنان کند است. در این حالت، باید فراتر از تنظیمات فنی به نحوه سازمان دهی کار تیم نگاه کرد.
اگر مسئولیتها روشن نباشند، یک View ممکن است توسط چند نفر کنترل شود یا برعکس، هیچ کس مالک مشخص آن نباشد. اگر مشخص نباشد چه کسی تغییرات مدل را تأیید میکند، چه کسی مسئول کنترل نقشه است و چه زمانی یک Sheet آماده صدور محسوب میشود، بخش قابل توجهی از زمان تیم صرف پرسش، انتظار، کنترل تکراری و اصلاحات غیرضروری خواهد شد.
نمونههای رایج این مشکل عبارتاند از:
- چند نفر یک کنترل مشابه را جداگانه انجام میدهند.
- مدلساز و مسئول مستندسازی اطلاعات را دوباره تولید میکنند.
- تغییرات بدون اطلاع مسئول نقشه وارد مدل میشوند.
- استاندارد QA مشخص نیست و هر بازبین معیار متفاوتی دارد.
- وضعیت مدارک بین «در حال کار»، «برای بازبینی» و «قابل صدور» به وضوح تفکیک نمیشود.
در چنین شرایطی، افزایش سرعت کاربران تأثیر محدودی دارد؛ زیرا زمان اصلی نه در اجرای دستورهای Revit، بلکه در اصطکاک میان نقشها و مراحل کار از دست میرود.
گردشکار مناسب باید مشخص کند هر اطلاعات از کجا وارد فرایند میشود، چه کسی مسئول آن است، در چه مرحلهای کنترل میشود و چه زمانی برای استفاده در مدارک معتبر است.
اگر مسئولیت و مسیر تصمیم گیری روشن نباشد، حتی یک مدل فنیِ خوب هم نمیتواند فرایند مستندسازی سریعی ایجاد کند.
آیا واقعاً مشکل از سختافزار است؟
وقتی تولید نقشه در Revit کند میشود، یکی از اولین فرضها این است که سیستمهای سختافزاری توان کافی ندارند. این فرض در بعضی پروژهها درست است، اما همیشه علت اصلی نیست. برای تشخیص صحیح، باید میان کندی نرمافزار و کندی فرایند تفاوت قائل شد.
اگر باز شدن مدل، تغییر View، Regeneration،Synchronize یا کار با مدلهای لینک شده زمان زیادی میبرد، ممکن است سختافزار، حجم مدل یا پیچیدگی هندسه واقعاً بخشی از مشکل باشد. در این حالت، بررسی RAM، CPU، فضای ذخیره سازی، ساختار فایل و حجم Familyها منطقی است.
اما بسیاری از تأخیرها منشأ دیگری دارند. برای مثال، کاربری که باید هر View را چند بار تنظیم کند، اطلاعات را دوباره تایپ کند، پس از هر تغییر چند Sheet را کنترل کند یا منتظر تصمیم فرد دیگری بماند، با ارتقای سختافزار فقط بخش کوچکی از زمان خود را پس میگیرد.
برای همین بهتر است قبل از خرید سیستم جدید مشخص شود تأخیر از کدام نوع است:
- انتظار برای پردازش نرمافزار
- کار دستی و تکراری
- اصلاح خطاها
- دوباره کاری ناشی از تغییرات
- انتظار برای هماهنگی یا تأیید
اگر سهم اصلی زمان در چهار مورد آخر باشد، مسئله بیشتر به ساختار فرایند مربوط است تا قدرت کامپیوتر.
**سختافزار سریعتر میتواند اجرای یک فرایند خوب را سریعتر کند، اما نمیتواند یک گردشکار ناکارآمد را اصلاح کند.
اگر کندی نرمافزار نیز بخشی از مسئله است، مقاله قبل از خرید سختافزار قویتر، چه چیزهایی را در مدل Revit بررسی کنیم؟ کمک میکند محدودیت واقعی سیستم از مشکل مدل و Worksharing جدا شود.**
چگونه بفهمیم فرایند مستندسازی BIM نیاز به بهینه سازی دارد؟
کند بودن تولید نقشه به تنهایی نشان نمیدهد که فرایند مستندسازی مشکل دارد. ابتدا باید مشخص شود تأخیر موردی است یا به صورت تکرارشونده در پروژهها و تیمهای مختلف دیده میشود. اگر الگوی مشابهی بارها تکرار شود، احتمال وجود یک ضعف ساختاری بیشتر است.
برای تشخیص، سه پرسش اصلی میتواند مفید باشد:
- زمان کجا مصرف میشود؟ آیا بیشتر زمان صرف تولید واقعی مدارک میشود یا اصلاح، کنترل و دوبارهکاری؟
- مشکل تکرارشونده است یا موقت؟ یک پروژه پیچیده لزوماً نشانه ضعف سیستم نیست، اما تکرار همان مشکلات در چند پروژه اهمیت بیشتری دارد.
- گلوگاه در کدام لایه قرار دارد؟ مدل، Familyها، استاندارد مستندسازی، هماهنگی، گردشکار تیم یا عملکرد نرمافزار؟
نشانههایی مانند تنظیم دستی مکرر Viewها، تفاوت زیاد میان خروجی اعضای تیم، ورود دوباره اطلاعات موجود در مدل، اصلاحات گسترده پس از تغییرات کوچک، تکرار خطاهای مشابه در QA یا افزایش نیافتن خروجی متناسب با اضافه شدن نیرو، میتوانند نشان دهند که مشکل فراتر از عملکرد یک کاربر است.
هدف از بهینه سازی نباید صرفاً «سریعتر کردن کار» باشد. ابتدا باید مشخص شود کدام فعالیت ارزش واقعی ایجاد نمیکند و چرا همچنان تکرار میشود.
بهینه سازی زمانی معنا دارد که بتوان گلوگاه را مشخص، علت آن را شناسایی و نتیجه اصلاح را با کاهش زمان، خطا یا دوبارهکاری اندازهگیری کرد.
اتوماسیون چه زمانی واقعاً تولید نقشه را سریعتر میکند؟
اتوماسیون زمانی بیشترین ارزش را ایجاد میکند که فرایند مورد نظر از قبل تا حد کافی مشخص و استاندارد شده باشد. اگر روش انجام یک کار بین افراد مختلف متفاوت باشد یا تصمیم گیری زیادی در هر مرحله نیاز داشته باشد، خودکارسازی آن معمولاً پیچیده، شکننده و کم اثر خواهد بود.
وظایفی مانند ایجاد Viewهای استاندارد، ساخت Sheet، نامگذاری، پر کردن Parameterها، کنترل برخی خطاهای تکرارشونده یا انجام تغییرات گروهی معمولاً گزینههای مناسبی برای اتوماسیون هستند. ابزارهایی مانند Dynamo یا Revit API میتوانند در این بخشها زمان زیادی را کاهش دهند، به خصوص زمانی که همان عملیات در پروژههای متعدد تکرار میشود.
اما اتوماسیون نباید به عنوان اولین راه حل استفاده شود. اگر مشکل اصلی از ساختار نامناسب مدل، Familyهای ناسازگار، استانداردهای ناقص یا گردشکار مبهم ناشی شود، خودکارسازی فقط همان ضعفها را با سرعت بیشتری تکرار میکند.
برای انتخاب فعالیت مناسب، مقاله کدام فرایندهای Revit ارزش اتوماسیون دارند و کدامها ندارند؟ معیار تکرارپذیری، وضوح قواعد و کیفیت ورودی را با جزئیات بیشتری بررسی میکند.
قبل از تصمیم برای اتوماسیون بهتر است سه سؤال مطرح شود:
- آیا این فعالیت تکرارشونده است؟
- آیا قواعد انجام آن روشن و قابل تعریف هستند؟
- آیا ورودیهای آن استاندارد و قابل اتکا هستند؟
اگر پاسخ این پرسشها مثبت باشد، اتوماسیون میتواند زمان انجام کار را کاهش دهد و یکنواختی خروجی را افزایش دهد.
اتوماسیون یک فرایند بد، فقط همان فرایند بد را سریعتر اجرا میکند.
نتیجهگیری: سرعت تولید نقشه یک خروجی سیستمی است
زمان تولید نقشه در یک فرایند BIM فقط به مهارت کاربر یا سرعت Revit وابسته نیست. کیفیت مدل، ساختار Familyها، استانداردهای مستندسازی، نحوه استفاده از اطلاعات، ثبات تغییرات، گردشکار تیم و حتی تصمیم درباره محل استفاده از اتوماسیون، همگی در سرعت و قابلیت اتکای خروجی نقش دارند.
به همین دلیل، وقتی تولید مدارک بیش از حد زمان میبرد، تمرکز صرف بر افزایش سرعت کاربران معمولاً کافی نیست. ممکن است تیم در حال جبران مشکلاتی باشد که در مراحل قبل ایجاد شدهاند؛ از مدلسازی نامناسب گرفته تا دوباره کاری ناشی از تغییرات، اطلاعات تکراری یا مسیرهای مبهم کنترل و تأیید.
یک فرایند مستندسازی کارآمد باید تا حد امکان تصمیمهای تکراری را استاندارد کند، اطلاعات موجود را مستقیماً از مدل به کار بگیرد، تغییرات را قابل کنترل نگه دارد و مسئولیت هر مرحله را مشخص کند. پس از شکل گیری چنین ساختاری است که ابزارهای اتوماسیون نیز میتوانند اثر واقعی خود را نشان دهند.
بنابراین، کاهش زمان تولید نقشه باید بهعنوان مسئلهای سیستمی بررسی شود، نه صرفاً مسئلهای مربوط به نرمافزار یا نیروی انسانی.
اگر این الگو در پروژه واقعی تکرار میشود، خدمت بهینهسازی BIM مستندسازی، Template و Family، گردشکار و اتوماسیون را بهعنوان بخشهای یک سیستم واحد بررسی میکند.
اگر خروجی کند است، باید کل زنجیره تولید اطلاعات را بررسی کرد؛ زیرا نقشه فقط آخرین مرحله این زنجیره است.