MDL در پروژه‌های EPC

برنامه‌ی مهندسی را نمی‌شود نوشت مگر این‌که بدانیم دقیقاً چه چیزهایی باید تحویل بدهیم. پاسخ این پرسش «لیست مدارک اصلی پروژه» است که در ادبیات مهندسی با نام‌های MDL (Master Document List) و گاهی Deliverables List شناخته می‌شود. در چارچوب ISO ۱۹۶۵۰ همین مفهوم با عنوان MIDP (Master Information Delivery Plan) آمده و کمی جلوتر می‌رود، چون زمان تحویل هر مدرک را هم در بر می‌گیرد. نام‌ها فرق می‌کند، کارکرد یکی است: فهرست کامل و کنترل‌شده‌ی مدارکی که پیمانکار به تحویل آن‌ها متعهد است، همراه با زمان، مسئول و وزن هر کدام.

در این نوشته می‌خواهم چهار پرسش عملی را باز کنم که هر برنامه‌ریز مهندسی دیر یا زود با آن‌ها روبه‌رو می‌شود: MDL را از کجا بسازیم (و قراردادهای مختلف مثل نشریه ۴۳۱۱، پیمان EPC همسان، FIDIC و پروژه‌های نفت و گاز درباره‌ی مدارک مهندسی چه رویکردی دارند)، آیا کارفرما باید آن را تأیید کند، آیا ساخت و تأیید خودش باید در برنامه‌ی زمانی بیاید، و در عمل چگونه آن را تهیه کنیم تا به Primavera P6 هم منتقل شود. بعد از آن سراغ MDR می‌رویم، مسیری که یک نقشه تا صدور IFC طی می‌کند و فرم‌های نمونه‌ی آن و در پایان اطلاعاتی که کنترل پروژه باید از مهندسی بگیرد تا برنامه روی پایه‌ی محکم بنا شود.

لیست مدارک را از کجا می‌سازیم؟

در بیشتر پروژه‌ها MDL آماده‌ای در قرارداد نیست که فقط امضایش کنیم. قرارداد می‌گوید چه چیزی را باید تحویل بدهیم و ساختن فهرست مدارک به عهده‌ی پیمانکار است. مواد اولیه‌ی این کار از چند جا می‌آید: شرح کار و پیوست‌های قرارداد، مشخصات فنی کارفرما، رویه‌ی کنترل مدارک او (که کدگذاری، فرمت و مراحل صدور مثل IFR و IFA و IFC را تعیین می‌کند)، فهرست تجهیزات و برآورد مقادیر (MTO یا BOQ)، پیشنهاد فنی خود پیمانکار در مناقصه و البته MDL پروژه‌های مشابه قبلی که در عمل مفیدترین الگوست.

این منطق در قراردادهای بین‌المللی جا افتاده است. در کتاب‌های زرد و نقره‌ای FIDIC (ویرایش ۲۰۱۷) طراحی بر عهده‌ی پیمانکار است، او «مدارک پیمانکار» (Contractor’s Documents) را برای بررسی می‌فرستد و برنامه‌ی زمانی را ظرف ۲۸ روز از ابلاغ شروع کار ارائه می‌کند؛ برنامه‌ای که باید زمان‌بندی مراحل طراحی و مدارک را هم نشان بدهد. ISO ۱۹۶۵۰-۲ هم از این فراتر می‌رود و می‌خواهد MIDP همان مرحله‌ی پیشنهاد تهیه شود و پس از انعقاد قرارداد تثبیت و به‌روز گردد. یعنی فهرست مدارک بخشی از پیشنهاد است، نه کاری که بعد از قرارداد به آن فکر کنیم.

در ایران بسته به نوع قرارداد وضع فرق می‌کند. در پیمان‌های متعارف ساختمانی که بر پایه‌ی شرایط عمومی پیمان (معروف به نشریه ۴۳۱۱) بسته می‌شوند، طراحی معمولاً با مهندس مشاور است و پیمانکار بیشتر درگیر نقشه‌های کارگاهی و برنامه‌ی زمانی تفصیلی است. اما در پیمان‌های طرح و ساخت و EPC، که در نفت، گاز، پتروشیمی و بخشی از زیرساخت‌ها رایج‌اند، مهندسی در دست پیمانکار است و MDL اهمیت اصلی پیدا می‌کند. شرح خدمات هر فاز (فاز یک یا پایه و فاز دو یا تفصیلی) سرفصل مدارک را می‌دهد ولی ریز آن را باید خودتان بنویسید.

یک مثال ساده: قراردادی برای نمای یک ساختمان اداری می‌گوید پیمانکار باید «نقشه‌های اجرایی و کارگاهی، محاسبات و مدارک تأیید مصالح» را ارائه کند و فهرستی هم ضمیمه نیست. من از اقلام فیزیکی شروع می‌کنم، نه از حافظه. اگر پروژه سه سیستم نما دارد (مثلاً کامپوزیت آلومینیوم، سنگ و کرتین‌وال)، برای هر سیستم نقشه‌ی کارگاهی، محاسبه‌ی بار باد بر اساس مبحث ششم مقررات ملی ساختمان، کنترل نیروهای لرزه‌ای اجزای غیرسازه‌ای طبق آیین‌نامه‌ی ۲۸۰۰، طراحی مهارها، دیتاشیت مصالح، نمونه‌ی ساخته‌شده (Mock-up) و گزارش آن لازم است و روی این‌ها نقشه‌ی هماهنگی با صفحات کارگذاشته‌شده‌ی اسکلت اضافه می‌شود. فهرستی که از این راه به دست می‌آید با «نقشه‌های نما» به‌عنوان یک ردیف کلی فاصله‌ی زیادی دارد و همین فاصله بعداً در اختلاف‌ها خودش را نشان می‌دهد.

در پروژه‌ی صنعتی هم همین است. اگر ده دستگاه پمپ دارید، یک ردیف «پمپ‌ها» کافی نیست: هر پمپ دیتاشیت پمپ و موتور، نقشه‌ی فونداسیون، محاسبه‌ی هیدرولیک و مدارک سازنده (Vendor Data) دارد و مدارک سازنده به تاریخ سفارش‌گذاری وابسته است، که به برنامه‌ی تدارکات گره می‌خورد. نکته‌ی دیگر این‌که ساعت‌کارهایی که در پیشنهاد مناقصه داده‌اید پایه‌ی قیمت شماست. MDL باید با آن اعداد همخوان باشد وگرنه کارفرما یا مشاور او سؤال می‌کند چرا مهندسی تفصیلی با پیشنهاد فاصله دارد.

هر قرارداد مدارک مهندسی را به شکلی می‌بیند

پیش از این‌که MDL را ببندید، متن قرارداد را یک بار دیگر بخوانید، این بار نه برای بندهای مالی، بلکه برای این‌که ببینید درباره‌ی مدارک چه گفته است. چند پرسش ساده در آن پنهان است که مستقیم روی برنامه‌ی شما اثر می‌گذارد: طراحی با کیست؟ کدام مدارک باید تأیید شوند و کدام فقط برای اطلاع‌اند؟ کارفرما چند روز وقت بررسی دارد؟ اگر پاسخ نداد چه می‌شود؟ و بعد از تأیید، مسئولیت اشتباه با کیست؟ در کلاس‌ها بیشترین سؤال را همین‌جا می‌شنوم، چون خیلی از برنامه‌ریزها MDL کاملی می‌نویسند ولی مدت بررسی و پیامد سکوت را از روی عادت در برنامه می‌گذارند. در ادامه سه خانواده‌ی قرارداد را که در ایران بیشتر می‌بینیم کنار هم می‌گذارم: پیمان ساختمانی بر پایه‌ی نشریه ۴۳۱۱، پیمان EPC همسان برای کارهای صنعتی و پروژه‌های نفت و گاز. FIDIC را هم برای مقایسه کوتاه می‌آورم.

پیمان ساختمانی (نشریه ۴۳۱۱): نقشه از مشاور می‌آید

در شرایط عمومی پیمان، ماده‌ی ۲۲ با عنوان «ترتیب گردش مدارک، نقشه‌ها و ابلاغ دستورکارها» تکلیف را روشن کرده است. فلسفه‌ی کلی این است که طراح مهندس مشاور است، پیمانکار اجرا می‌کند و فقط بخشی از مدارک (نقشه‌های کارگاهی، چون‌ساخت و مدارک سازندگان) از دست پیمانکار بیرون می‌آید. نکته‌هایی که برای برنامه‌ریز اهمیت دارد این‌هاست:

• نسخه‌ی کارگاه. نقشه‌ها و مشخصات مهرشده‌ی مشاور به تعداد نسخه‌های درج‌شده در پیمان (و اگر تعداد معین نشده باشد، دو نسخه) رایگان به پیمانکار می‌رسد و نسخه‌ی اضافی به هزینه‌ی خود اوست. پیمانکار باید همیشه یک نسخه با آخرین تغییرات را در کارگاه نگه دارد و اصل مدارک تا پایان کار نزد مشاور می‌ماند. در عمل یعنی کنترل Rev. در کارگاه بخشی از وظیفه‌ی شماست، نه فقط دفتر فنی.
• مطالعه پیش از شروع هر قسمت. پیمانکار باید پیش از هر قسمت از کار نقشه‌ها و مدارک آن را بخواند و اندازه‌ها را کنترل کند. کمبود نقشه از تعهد او به اجرای کامل کار کم نمی‌کند، اما اگر اشتباه، ابهام یا کسری دید باید به‌موقع رفعش را از مشاور بخواهد و مشاور هم موظف است با توجه به برنامه‌ی زمانی اجرا، نقشه‌ها را تکمیل و ابلاغ کند. این دو جمله پایه‌ی برنامه‌ریزی شماست: برای هر بسته‌ی اجرایی «تاریخ نیاز به نقشه» داشته باشید و درخواست‌ها را کتبی و به‌موقع بدهید. اگر ندهید، در ادعای تأخیر دستتان خالی است.
• ایراد پیمانکار. اگر در درستی نقشه‌ها، محاسبات یا دستورکارها ایرادی ببیند، با ذکر دلیل به مشاور اطلاع می‌دهد. اگر مشاور مدارک را تأیید کند ولی پیمانکار هنوز ایراد داشته باشد، موضوع را به کارفرما منعکس می‌کند و طبق نظر او عمل می‌کند. در این حالت پیمانکار فقط مسئول اجرای درست کار است و هزینه‌ی رفع عیب هم با او نیست. یعنی قرارداد راه ایراد گرفتن را باز گذاشته، به شرط این‌که مسیر مکاتبه را رفته باشید.
• نقشه‌های کارگاهی. پیمانکار آن‌ها را بر پایه‌ی نقشه‌های اجرایی، مشخصات فنی و دستورالعمل سازندگان تهیه می‌کند و در سه نسخه (که یکی قابل تکثیر باشد) به مشاور می‌دهد؛ مشاور پس از بررسی و اصلاح، تأیید می‌کند و یک نسخه را ابلاغ می‌کند. ردیف نقشه‌ی کارگاهی نما در MDL مثال بالا دقیقاً از همین‌جا می‌آید. نکته این‌که در همین ماده مهلت عددی برای بررسی ندیدم. به شرایط خصوصی و پیوست‌ها نگاه کنید و اگر آن‌جا هم نبود، مدت مورد انتظار را با مشاور مکتوب کنید و فرض خودتان را در برنامه بنویسید.
• نقشه‌های چون‌ساخت. قرار است «به‌تدریج و طبق نظر مشاور» تهیه شوند، در سه نسخه و مشاور یک نسخه‌ی تأییدشده را برمی‌گرداند. کلمه‌ی «به‌تدریج» را جدی بگیرید: چون‌ساخت را برای آخر پروژه نگذارید و برای هر ناحیه‌ای که تمام می‌شود در برنامه فعالیتی داشته باشید.
• مدارک سازندگان. مشخصات، نقشه‌ها و دستورالعمل‌های نصب، راه‌اندازی و بهره‌برداری تجهیزاتی که تأمین‌شان با پیمانکار است را باید از سازنده بگیرد و در دو نسخه به مشاور بدهد.
• ابلاغ کتبی. مشاور موافقت‌ها، تصویب‌ها، اخطارها و دستورکارها را کتبی ابلاغ می‌کند. پیمانکار پس از وصول می‌تواند برای اصلاح نظر بدهد ولی موظف به اجراست. اگر دستور شفاهی باشد، پیمانکار می‌تواند ابلاغ کتبی بخواهد و مشاور مکلف است کتبی ابلاغ کند وگرنه آن دستور برای پیمانکار معتبر نیست. به تیم‌ها همیشه می‌گویم هر دستور شفاهی را همان روز کتباً درخواست کنید که ابلاغ شود.
• پیش از تحویل موقت. طبق ماده ۳۹، دستورالعمل‌های راه‌اندازی، راهبری، تعمیر و نگهداری همراه با نقشه‌های چون‌ساخت باید به مشاور تحویل شود و اگر پیمان تعداد نسخه یا مشخصات ویژه‌ای تعیین کرده باشد، طبق آن عمل می‌شود. این تحویل را پیش از تحویل موقت در برنامه ببینید، نه بعد از آن.

نتیجه برای MDL این است که در ۴۳۱۱ فهرست مدارک پیمانکار کوتاه‌تر است ولی ریسک «نقشه‌ی دیررسیده» بزرگ‌تر. پس نقشه‌هایی را که از مشاور می‌گیرید مثل یک ورودی بیرونی با تاریخ نیاز در برنامه بیاورید و درخواست‌های اطلاعات (RFI) را پیگیری کنید.

پیمان EPC همسان: مهندسی با پیمانکار است، مسئولیتش هم

شرایط عمومی پیمان همسان طراحی و مهندسی، تأمین مصالح و تجهیزات، ساختمان و نصب (EPC) برای کارهای صنعتی از پایه‌ی دیگری شروع می‌کند: طراحی و مهندسی در تعهد پیمانکار است. ماده‌های ۲ و ۴ تا ۹ آن برای برنامه‌ریز مهندسی خواندنی‌اند:

• اولویت اسناد. در ماده‌ی ۲ موافقتنامه (و ماده‌ی ۵ شرایط عمومی) اگر تناقض یا ابهامی پیش بیاید، اولویت به ترتیب با موافقتنامه، شرایط عمومی، شرایط خصوصی، پیوست‌ها و سپس سایر اسناد و مدارکی است که در مدت اجرا تنظیم می‌شود و به تأیید دو طرف می‌رسد. میان پیوست‌ها هم منطق موضوعی حاکم است: درباره‌ی مبلغ، پیوست ۱ و درباره‌ی کارها، پیوست ۱۱ اولویت دارد. به نظر من MDL تأییدشده در همان دسته‌ی آخر می‌نشیند، پس اگر با پیوست‌های قرارداد تعارض پیدا کند پیوست‌ها مقدم‌اند. MDL را با پیوست ۱۱ تطبیق دهید و فکر نکنید فهرست امضاشده‌ی شما دامنه‌ی کار را کم می‌کند.
• هدف اسناد. ماده‌ی ۴ می‌گوید هر بخش از کارهای طراحی و مهندسی، تأمین و ساخت که با استنباط از اسناد پیمان یا طبق عرف فنی و تجاری برای انجام موضوع پیمان لازم باشد، به عهده‌ی پیمانکار است. یعنی مدرکی که در MDL جا افتاده، بهانه نیست.
• استانداردها. طبق ماده‌ی ۶ همه‌ی کارها باید طبق آخرین ویرایش استانداردها و آیین‌نامه‌ها در تاریخ ارائه‌ی پیشنهاد قیمت انجام شود، مگر در پیمان چیز دیگری آمده باشد. در موارد مسکوت، پیمانکار باید پیش از صحه‌گذاری اسناد فنی پایه، استانداردهای پیشنهادی خود را به کارفرما بدهد و تأییدیه‌ی نهایی بگیرد. اگر پس از پیشنهاد قیمت ویرایش جدیدی بیاید و کارفرما بخواهد از آن استفاده شود، موضوع طبق ماده‌ی ۴۹ به‌عنوان تغییر دیده می‌شود. «فهرست استانداردها و مراجع طراحی» پس باید یکی از اولین مدارک MDL باشد.
• صحه‌گذاری اسناد پایه. پیمانکار باید حداکثر ۴۲ روز پس از تاریخ شروع کار (یا مهلتی که شرایط خصوصی تعیین می‌کند) صحت و دقت اطلاعات و مدارک پایه‌ی پیوست ۱۸ را صحه‌گذاری کند. پس از آن مسئولیت هر اشتباه و اصلاح لازم با پیمانکار است، حتی اگر مشاور یا کارفرما آن را تأیید کرده باشند. استثنا: اشتباهی که از داده‌هایی بیاید که طبق پیوست ۱۸ نیاز به صحه‌گذاری پیمانکار نداشته، با کارفرماست. این ۴۲ روز را به‌صورت یک فعالیت واقعی با منابع مشخص در برنامه بگذارید؛ مرور سطحی بعداً گران تمام می‌شود.
• مدارک برای تأیید یا اطلاع. پیمانکار باید مدارک بخش ۲-۱۸ پیوست ۱۸ را حسب مورد برای تأیید و تصویب یا اطلاع کارفرما بفرستد و کار روی مدارکی که تصویب کارفرما لازم دارند فقط پس از تصویب مجاز است. این بخش نزدیک‌ترین چیز به یک MDL قراردادی است و ستون «تأیید / اطلاع» MDL شما از همین‌جا می‌آید. اگر تصویب بخشی از کار به صاحبان لیسانس یا شرکت‌های مهندسی طرف قرارداد کارفرما سپرده شده باشد، تصویب آن‌ها در حکم تصویب کارفرما است.
• چرخه‌ی بررسی. این‌جا برخلاف ماده‌ی ۲۲ نشریه ۴۳۱۱، مدت‌ها را عددی و دقیق می‌بینیم:

اگر نظر کمیته با دستور کارفرما نخواند، کارفرما هزینه‌های اضافی را طبق ماده ۴۹ می‌پردازد و تمدید مدت طبق بند ۱-۶۴ بررسی می‌شود. تصویب مدارک هم از مسئولیت‌های پیمانکار نمی‌کاهد، جز در مواردی که کمیته نظر داده و کار به‌رغم نظر پیمانکار به روش کارفرما انجام شده است. معنی «روز» را با شرایط خصوصی خودتان بسنجید.

چند چیز از این جدول به برنامه می‌رسد. مدرکی که یک بار برگردد، در بدترین حالتِ بدون ارجاع به کمیته، حدود ۱۴ + ۷ + ۱۴ یعنی ۳۵ روز از ارسال تا تصویب نهایی طول می‌کشد و این همان چرخه‌ی دومی است که در نمونه‌ی MDR بالا دیدیم. چون کارفرما فرصت دارد همه‌ی نظراتش را فقط «یک‌جا» بدهد، کیفیت بررسی داخلی پیش از ارسال اهمیت بیشتری پیدا می‌کند. و قاعده‌ی تصویب‌شده‌تلقی‌شدن فقط وقتی به کار می‌آید که ثابت کنید مدرک چه روزی تحویل شده، پس ترنسمیتال و رسید دبیرخانه حیاتی است. ماده‌ی ۸ هم همین را تأیید می‌کند: هر ابلاغیه و مدرک فقط کتبی معتبر است، ارسال الکترونیکی مدارک فنی ممکن است ولی فرستنده باید تأییدیه‌ی کتبی ارسال و دریافت را با ذکر نوع فایل و روش ارسال بگیرد و مبدأ محاسبه‌ی مهلت‌ها زودتر از میان تاریخ ثبت در دبیرخانه و رسید پستی است.

سه نکته‌ی کوچک‌تر ولی کاربردی: نقشه‌های پیمانکار باید متریک باشند و حداقل عنوان پروژه، موضوع نقشه، نام کارفرما، مشاور و پیمانکار، مقیاس، ابعاد و شماره‌ی شناسایی مدرک را داشته باشند (مگر در بخش ۲-۲-۱۸ پیوست ۱۸ چیز دیگری آمده باشد). مالکیت مدارک تهیه‌شده‌ی پیمانکار، جز آنچه از نظر ثبتی قبلاً حمایت می‌شود، با کارفرماست و او می‌تواند برای بهره‌برداری، تعمیر و نگهداری از آن‌ها استفاده کند؛ ولی اگر بخواهد در طرح‌های توسعه یا پروژه‌های مشابه به کار ببرد، مسئولیت ناهماهنگی با خود اوست. و زبان مدارکی که در طول کار رد و بدل می‌شود در شرایط خصوصی مشخص می‌شود؛ اگر متن قرارداد دو زبانه باشد، فارسی ملاک است. زبان مکاتبه و مدارک می‌تواند ساعت‌کار شما را بالا ببرد، مخصوصاً وقتی کارفرما انگلیسی می‌خواهد.

FIDIC: «عدم‌اعتراض» به‌جای «تأیید»

در ویرایش ۲۰۱۷ کتاب‌های زرد و نقره‌ای، مدارک پیمانکار آن‌هایی‌اند که در الزامات کارفرما تعیین شده‌اند، به‌اضافه‌ی مدارک لازم برای مجوزهای قانونی و مدارک چون‌ساخت و دستورالعمل‌های بهره‌برداری و نگهداری (بندهای ۵.۶ و ۵.۷). اگر در الزامات کارفرما چیز دیگری نیامده باشد، مدت بررسی هر مدرک بیش از ۲۱ روز نیست. تغییر مهم ۲۰۱۷ این است که واژه‌ی «تأیید» کنار رفته و جایش «عدم‌اعتراض» (No-objection) آمده: مهندس یا نماینده‌ی کارفرما یا مدرک را ناسازگار با پیمان اعلام می‌کند یا عدم‌اعتراض می‌دهد و می‌تواند درباره‌ی موارد جزئی نظر هم بنویسد. بند ۵.۸ نیز رویه‌ی اصلاح خطای طراحی را برای مدارکی که قبلاً عدم‌اعتراض گرفته‌اند تعیین کرده است. پیام فلسفی روشن است: کارفرما مدرک را در برابر الزامات خودش می‌سنجد و مسئولیت طراحی با پیمانکار می‌ماند. شباهت زیادی با رویکرد EPC همسان دارد، با این تفاوت که EPC همسان مدت‌ها و پیامد سکوت را صریح‌تر نوشته است.

پروژه‌های نفت و گاز: MDL سیستم کامل

در پروژه‌های نفت، گاز و پتروشیمی، متن قرارداد معمولاً فقط چارچوب را می‌دهد. جزئیات واقعی در اسناد کارفرما است: رویه‌ی مهندسی و کنترل مدارک، پیوست الزامات مدارک (Document Requirements) و جدول مدارک مورد نیاز از سازندگان (Vendor Document Requirements) که برای هر سفارش خرید ضمیمه می‌شود. این بخش را از تجربه‌ی عمومی پروژه‌های صنعتی می‌نویسم؛ فهرست هر پروژه را قرارداد و رویه‌ی همان کارفرما تعیین می‌کند. چند ویژگی در آن‌ها زیاد دیده می‌شود.

تهیه‌ی فهرست مدارک در این پروژه‌ها معمولاً وظیفه‌ی واحد کنترل پروژه است. کارشناس کنترل پروژه در چند جلسه با مسئولان دیسیپلین‌ها، هماهنگ‌کننده‌ها و مدیر پروژه (و گاهی خود کارفرما) فهرست را نهایی می‌کند و برای تأیید به کارفرما می‌فرستد. دیسیپلین‌های رایج عبارت‌اند از ساختمان (Civil)، برق، مکانیک، کنترل و ابزاردقیق، پایپینگ، فرآیند، مدیریت پروژه، عمومی و گاهی جانمایی (PLD). حجم مدارک هم زیاد است: در یک نیروگاه سیکل ترکیبی معمولاً از چهار هزار مدرک بالاتر می‌روید و هر کدام چند بار بازنگری می‌شود، برای همین آن‌ها را در یک سامانه‌ی مدیریت مدارک مهندسی (EDMS) و مرکز کنترل مدارک (DCC) نگه می‌دارند و بخش زیادی از گزارش‌های کنترل پروژه از همان‌جا درمی‌آید.

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

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

این صرفاً یک مثال است. فهرست واقعی را قرارداد، پیوست الزامات مدارک و رویه‌ی کارفرما تعیین می‌کنند.

دوم، هر مدرک در این پروژه‌ها معمولاً نوع بررسی دارد: تأیید (Approval)، بررسی (Review) یا اطلاع (Information). مدارک کلیدی مثل P&ID، پلات‌پلان، نقشه‌ی تک‌خطی یا HAZOP عموماً تأیید کارفرما می‌خواهند و بسیاری از مدارک دیگر فقط برای اطلاع‌اند. در برنامه فعالیت «بررسی کارفرما» را فقط برای مدارک تأییدی و بررسی بگذارید و مدارک اطلاعی را فقط تا ارسال ببرید؛ این هم از شلوغی برنامه می‌کاهد و هم واقع‌بینانه‌تر است.

سوم، مدارک سازندگان. در هر سفارش خرید، فهرستی (معمولاً با نام VDRL) از مدارک و زمان تحویلشان به سازنده داده می‌شود. این مدارک روی مسیر بحرانی طراحی اثر می‌گذارند: فونداسیون پمپ بدون بار و ابعاد سازنده تمام نمی‌شود. پس در برنامه، «وصول مدارک سازنده» را فعالیت یا حداقل نقطه‌ی عطف کنید، با تاریخ نیاز و تاریخ موعود سازنده و از روز اول با واحد تدارکات هماهنگ باشید.

چهارم، اصطلاح‌های ارسال و وضعیت. اینجا باید مراقب باشید، چون نام‌ها از پروژه‌ای به پروژه‌ی دیگر فرق می‌کند. در بعضی رویه‌ها، به‌ویژه در پروژه‌های نیروگاهی و نفت و گاز ایران، هدف ارسال این‌طور تعریف می‌شود: IFI برای اطلاع (بدون نیاز به بررسی)، IFA برای بررسی و تأیید، IFC برای اظهارنظر کارفرما، IFR برای پاسخ یا اصلاح، IFH برای نسخه‌ی کاغذی، IFS برای مهر کارفرما، IFM برای تأیید مارک‌آپ و IFB برای چون‌ساخت. در این رویه IFC یعنی «برای نظر کارفرما»، در حالی که در این نوشته و در بسیاری از رویه‌های دیگر IFC به معنای «صدور برای ساخت» (Issued for Construction) است. پیش از این‌که کدها را در برنامه و MDR بگذارید، تعریف‌های همان پروژه را از رویه‌ی کنترل مدارک بخوانید و در MDL ستونی برای معنی هر کد بگذارید.

نوع ارسال هم مهم است: اولین ارسال (First Issue)، ارسال‌های بازنگری‌شده با توجه به نظرات کارفرما (Revise)، ارسال برای پیشرفت طراحی (Design Progress) که مدرکی را که قبلاً تأیید شده به‌خاطر اشتباه یا تغییر در بخشی از کار دوباره طراحی می‌کند و نیازی به نظر کارفرما ندارد و پاسخ (Reply) که مدرک را عوض نمی‌کند و فقط با نامه به نظرات پاسخ می‌دهد. نظرات کارفرما یا مشاور در «برگه‌ی نظرات» (Comment Sheet) می‌آید و وضعیتش معمولاً یکی از این‌هاست: Approved (تأیید)، No comment (برای مدارک اطلاعی؛ تأییدشده تلقی می‌شود)، Approved As Noted (تأیید مشروط به اعمال نظرات)، Commented یا Return to Revise (اعمال نظرات و ارسال مجدد)، Rejected (طراحی مجدد)، Canceled (مدرک دیگر لازم نیست) و Void یا Hold (طبق درخواست کارفرما مدرک فعلاً متوقف شده است). همین وضعیت‌ها درصد پیشرفت هر فعالیت را تعیین می‌کنند، پس معنی هر کدام و درصد متناظر را باید در MDR و برنامه یکی کنید. توجه کنید که این Hold با «نقطه‌ی معلق» داخل یک مدرک فرق دارد: گاهی مدرک با بخشی از اطلاعات که هنوز نرسیده صادر می‌شود و آن بخش به رفع معلق‌بودن بسته است. هر دو باید در MDR و برنامه دیده شوند در غیر این صورت مدرک به‌ظاهر صادر شده ولی کار ادامه ندارد.

پنجم، ارزش‌گذاری. در بسیاری از این پروژه‌ها پرداخت و پیشرفت مهندسی بر مبنای MDL و وزن‌هاست و در بعضی قراردادهای خدمات مهندسی قیمت حتی بر پایه‌ی نرخ واحد هر مدرک در فهرست مدارک بسته می‌شود. در این‌گونه قراردادها مدرکی که در فهرست نیست، تغییر کار است. ششم و آخر، مدارک تحویل: دوسیه‌ی نهایی (Handover Dossier)، چون‌ساخت، مدارک راه‌اندازی و کتابچه‌های بهره‌برداری. معمولاً کمتر از همه در برنامه دیده می‌شوند و تأخیر در آن‌ها گاهی پرداخت نهایی را نگه می‌دارد.

یک نمونه‌ی واقعی: از جلد مدرک تا ترنسمیتال تأیید

برای این‌که این‌ها از حالت تعریف دربیایند، یک مدرک واقعی از یک پروژه‌ی پتروشیمی (واحد پلی‌اتیلن سنگین) را با هم نگاه می‌کنیم: «رویه‌ی بسته‌بندی و علامت‌گذاری سازه‌ی فولادی». محتوای فنی‌اش برای ما مهم نیست؛ جلد و ترنسمیتال تأییدش مهم است، چون هر دو در MDR و برنامه‌ی هر پروژه‌ی مشابهی دوباره ظاهر می‌شوند. نام شرکت‌ها و افراد را حذف کرده‌ام.

نخست شماره‌ی مدرک. در جلد، شماره‌ی مدرک از هفت بخش ساخته شده است که هر کدام در جدول عنوان‌بلوک ستون خودش را دارد:

شماره‌ی کامل به شکل PRJ-000-000-QH-PR-2050-0847 نوشته می‌شود. کد پروژه در این نمونه عمداً جایگزین شده است. معنی هر کد را رویه‌ی کنترل مدارک همان پروژه می‌دهد.

این ساختار همان چیزی است که در بخش MDL گفتم: اگر شماره‌گذاری بر پایه‌ی ناحیه واحد و دیسیپلین باشد، فیلتر کردن MDL و ساختن WBS برنامه از روی همین ستون‌ها تقریباً بی‌زحمت می‌شود. جلد همچنین «کلاس» مدرک (در این نمونه A) و شماره‌ی بازنگری را دارد و فرم «جدول صفحات بازنگری‌شده» (Tabulation of Revised Pages) که مشخص می‌کند در هر Rev. کدام صفحه‌ها تغییر کرده‌اند؛ در نمونه‌ی ما D0 تا صفحه‌ی ۱۸ علامت خورده ولی D1 و D2 فقط تا صفحه‌ی ۱۴. این جدول کوچک برای بررسی‌کننده وقت می‌خرد، چون لازم نیست کل مدرک را از اول بخواند.

جدول تاریخچه‌ی بازنگری‌های جلد هم برای برنامه‌ریز یک منبع داده است:

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

این سه ردیف داستان کوتاهی می‌گویند: مدرک سه بار برای تأیید رفته (D0 و D1 و D2) و از اولین ارسال تا ترنسمیتال تأیید ۴۴ روز گذشته است. فاصله‌ی بین دو ارسال هم زمان بررسی کارفرما را در خود دارد و هم زمان اعمال نظرات پیمانکار را و از روی همین جدول نمی‌شود این دو را جدا کرد. برای جداکردنشان به تاریخ‌های ثبت‌شده در MDR نیاز دارید، یعنی همان ستون‌های «ارسال» و «بازگشت». نکته‌ی برنامه‌ریزی روشن است: اگر برای چنین مدرکی فقط یک چرخه‌ی بررسی گذاشته بودید، در برنامه ۴۴ روز تأخیر خودنمایی می‌کرد، در حالی که اگر سه چرخه را از ابتدا برای مدارکی با ریسک رد بالا در نظر گرفته بودید، همین عدد از پیش در برنامه بود. مدارک را بر اساس ریسک رد شدن چرخه‌بندی کنید، نه همه را یک‌جور.

دومین سند، ترنسمیتال برگشتی است. شکل کلی آن این‌طور است:

چند چیز در این فرم کوچک ارزش دقت دارد. اول، «شماره‌ی ارجاع»: ترنسمیتال برگشتی به ترنسمیتال ارسالی پیمانکار (...T-00039) وصل شده، یعنی رفت و برگشت قابل ردیابی است و در MDR می‌توانید هر دو شماره را کنار هم بنویسید. دوم، راهنمای وضعیت: شش وضعیت دارد و با فهرست بالاتر (Approved، No comment، Approved As Noted، Commented، Rejected و غیره) جور است ولی همان نیست؛ AW و RW را می‌شود تقریباً معادل «تأیید با اعمال نظر» و «اعمال نظر و ارسال مجدد» گرفت ولی معنی دقیق‌شان را رویه‌ی همان پروژه می‌دهد. پس برای هر پروژه جدول تبدیل بسازید: هر وضعیت چه معنایی دارد، آیا نیاز به Rev. جدید دارد و چه درصدی از پیشرفت مدرک را می‌دهد. سوم، جمله‌ی «دریافت را تأیید می‌کنیم و نسخه‌ی امضاشده را برگردانید»: این همان رسید تحویل است که در پیمان‌هایی مثل EPC همسان مبدأ محاسبه‌ی مهلت‌هاست. نسخه‌ی امضاشده‌ی ترنسمیتال را در MDR یا آرشیو نگه دارید، چون اگر روزی بحث تأخیر بررسی پیش بیاید، همین کاغذ ثابت می‌کند مدرک چه روزی تحویل شده و چه روزی جواب گرفته.

یک نکته‌ی آخر درباره‌ی آنچه در این نمونه نیست: وضعیت AP فقط می‌گوید این Rev. تأیید شد، نه این‌که کل کار تمام شده است. در MDR باید مدرک را «تأییدشده در Rev. D2» ثبت کنید و، اگر رویه‌ی پروژه اجازه می‌دهد، پیشرفت آن را به ۱۰۰٪ برسانید. مدارکی مثل همین رویه که هنوز نقشه‌ی چون‌ساخت ندارند، معمولاً با همین تأیید بسته می‌شوند؛ مدارک تفصیلی مثل ایزومتریک ادامه‌ی عمر دارند و در انتهای کار Rev. چون‌ساخت می‌گیرند.

وضعیت مقایسه‌ای رویه‌ها در قراردادهای مختلف چیزی شبیه جدول زیر می شود:

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

پیش از نوشتن MDL این موارد را از قرارداد بیرون بکشید و در یک صفحه کنار هم بگذارید:

1. محدوده‌ی خدمات مهندسی و این‌که طراحی با کیست (در EPC همسان پیوست ۱۱).
2. فهرست یا چارچوب مدارک و نوع بررسی هر کدام (تأیید، بررسی، اطلاع).
3. مدت بررسی، تعداد چرخه‌ها و تعریف «روز» (تقویمی یا کاری).
4. پیامد سکوت کارفرما یا مشاور.
5. مهلت صحه‌گذاری اسناد و اطلاعات پایه (در EPC همسان ۴۲ روز).
6. ویرایش استانداردها و آیین‌نامه‌ها و این‌که چه کسی تأییدشان می‌کند.
7. قالب مدارک: زبان، مقیاس، شماره‌گذاری، عنوان‌بلوک، تعداد نسخه و شرایط ارسال الکترونیکی.
8. زمان و محتوای چون‌ساخت و دستورالعمل‌های بهره‌برداری و نگهداری و شرط تحویل موقت.
9. ارتباط پرداخت‌ها با مدارک.
10. ملاک معتبربودن مکاتبه: کتبی بودن، مخاطب و مبدأ محاسبه‌ی مهلت.

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

آیا کارفرما باید MDL را تأیید کند؟

معمولاً بله و دلیلش فقط تشریفات نیست. تأیید MDL یعنی دو طرف روی محدوده‌ی تحویلی‌ها و مبنای اندازه‌گیری پیشرفت مهندسی توافق کرده‌اند. هرچه این توافق روشن‌تر باشد، بحث «این مدرک جزو تعهد شما بود یا نبود» کوتاه‌تر می‌شود. استاندارد ISO ۹۰۰۱:۲۰۱۵ هم از زاویه‌ی دیگری همین را می‌خواهد: برنامه‌ریزی طراحی (بند ۸.۳.۲) باید مراحل، بازنگری‌ها و مسئولیت‌ها را روشن کند، مدارک باید کنترل‌شده باشند (بند ۷.۵) و تغییرات طراحی (بند ۸.۳.۶) شناسایی و مدیریت شوند. MDL ابزار اجرای همین الزام‌هاست.

قرارداد معمولاً تکلیف را مشخص کرده است: مهلت تحویل MDL (مثلاً ظرف چهارده یا بیست‌ویک روز پس از ابلاغ)، مدت بررسی و وضعیت‌های ممکن. عباراتی مثل Document Register، Deliverables List و Submittal Schedule را در قرارداد و پیوست‌ها جست‌وجو کنید. در ایران نکته‌ی عملی این است که بررسی‌کننده همیشه خود کارفرما نیست؛ ممکن است مهندس مشاور، مدیر طرح یا دستگاه نظارت باشد. پیش از ارسال، مسیر مکاتبه و مرجع تأیید را از متن قرارداد دربیاورید و نامه را دقیقاً به همان مرجع بزنید، با شماره‌ی ترنسمیتال و تاریخ ثبت. در هر دعوای تأخیری اولین پرسش‌ها این است که چه روزی ارسال شد، چه روزی پاسخ آمد و قرارداد چند روز مهلت داده بود. اگر اصلاً پاسخی نیامد، متن قرارداد را درباره‌ی سکوت کارفرما بخوانید و پیگیری‌ها را کتبی انجام دهید.

این را هم بدانید که تأیید همیشه در یک جمله خلاصه نمی‌شود. گاهی کارفرما می‌نویسد «تأیید برای مبنای برنامه‌ریزی»، گاهی «تأیید با اعمال نظرات» و گاهی چیزی شبیه «بررسی شد». هیچ‌کدام یکسان نیست؛ در نامه‌ی پاسخ ببینید کدام حالت است و اگر مبهم بود، رفع ابهام را بخواهید. در رویه‌های بسیاری از شرکت‌ها وضعیت بررسی با کدهایی مثل ۱ تا ۴ یا A تا C مشخص می‌شود و معنی هر کد در رویه‌ی کنترل مدارک همان پروژه آمده است.

MDL سندی زنده است. مدرکی اضافه یا حذف می‌شود، ساعت‌کاری جابه‌جا می‌شود، ناحیه‌ای به پروژه افزوده می‌شود. هر بازنگری (Rev.A، Rev.B و …) باید دلیل تغییر، اثر آن بر ساعت‌کار کل و وزن‌ها را ثبت کند. تفکیکی که اینجا بسیار مهم است: اضافه‌کردن مدرکی که فراموش شده بود و ذاتاً جزو شرح کار بوده، «تکمیل MDL» است؛ اضافه‌شدن مدرک به‌خاطر درخواست جدید کارفرما، «تغییر کار». اگر این دو را در بازنگری‌ها قاطی کنید، بعداً نمی‌توانید برای تغییر واقعی ادعا بدهید.

اگر تأیید طول کشید چه؟ در عمل مهندسی را نمی‌توان یک ماه منتظر گذاشت. معمولاً مدارک پایه‌ای مثل مبانی طراحی (Design Basis) با MDL پیش‌نویس شروع می‌شود. فقط در نامه‌ی ارسال صریحاً بنویسید که فعالیت‌ها بر مبنای نسخه‌ی پیش‌نویس در جریان است و منتظر تأیید رسمی می‌مانید. این جمله بعدها خیلی کارآمد است.

مراحل ساخت و تأیید MDL را در برنامه بیاوریم؟

بله و هر برنامه‌ریزی که این را از قلم بیندازد در واقع تصویر ناقصی از مسیر بحرانی ساخته است. چند دلیل دارد: FIDIC برنامه را مبنای زمان‌بندی طراحی و مدارک می‌داند؛ راهنمای ارزیابی برنامه‌ی GAO تأکید دارد که برنامه باید همه‌ی کارها را شامل شود، از جمله بررسی‌ها و تأییدهای طرف‌های دیگر؛ و در استانداردهای PMI، تعریف و توالی‌دهی فعالیت‌ها بدون تکیه بر WBS و تحویلی‌ها ممکن نیست. از همه مهم‌تر، تا MDL نهایی نشود وزن‌ها و Baseline پیشرفت مهندسی هم تثبیت نمی‌شود.

یک چینش معمول در بخش مدیریت مهندسی و کنترل مدارک این است:

دو نکته در تنظیم این فعالیت‌ها در P6 زیاد نادیده گرفته می‌شود. نخست، مدت بررسی کارفرما را بر اساس قرارداد بگذارید، حتی اگر می‌دانید در عمل بیشتر طول می‌کشد؛ Baseline باید بر مبنای تعهد قراردادی باشد و تأخیرهای محتمل را در تحلیل ریسک بررسی کنید. دوم، تقویم. دفتر مهندسی شما و دفتر کارفرما یا مشاور ممکن است هفته‌ی کاری متفاوت داشته باشند، برای مثال شنبه تا چهارشنبه در یک سازمان دولتی و شنبه تا پنجشنبه در دفتر شما. فعالیت‌های بررسی را به تقویم خود بررسی‌کننده وصل کنید. تعطیلات رسمی تقویم شمسی، نوروز و ساعات کاری ماه رمضان را هم وارد کنید، چون روی مدت واقعی بررسی اثر مستقیم دارند. P6 با تاریخ میلادی کار می‌کند و گزارش‌های رسمی شما شمسی است؛ در MDL هر دو ستون را نگه دارید تا هنگام مکاتبه دچار اشتباه نشوید.

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

روش تهیه‌ی MDL؛ گام‌به‌گام و با یک مثال عددی

اصل راهنمای من این است که MDL را از روی کار فیزیکی بسازید، نه از روی حافظه. استاندارد عملی PMI برای WBS «قاعده‌ی ۱۰۰ درصد» را مطرح می‌کند: هر آنچه در محدوده‌ی کار هست باید در شکست کار بیاید و چیزی بیرون آن نباشد. در مهندسی این یعنی هر ساختمان، ناحیه، تجهیز و سیستم باید مدارک خودش را داشته باشد و چیزی از قلم نیفتد. عملاً این‌طور جلو می‌روم: ابتدا دیسیپلین‌ها و نواحی را هم‌راستا با WBS برنامه تعریف می‌کنم؛ سپس برای هر ناحیه و دیسیپلین نوع مدارک لازم را از روی اقلام و سیستم‌ها بیرون می‌کشم؛ بعد MDL پروژه‌ی مشابه را کنار آن می‌گذارم و ردیف‌های جاافتاده یا اضافی را اصلاح می‌کنم؛ در گام بعد ساعت‌کار هر مدرک را برآورد می‌کنم و در پایان مدارک پیش‌نیاز، نوع بررسی کارفرما (تأیید، بررسی یا اطلاع) و تاریخ‌های هدف IFR، IFA و IFC را می‌نویسم.

شماره‌گذاری را از اول جدی بگیرید. ISO ۱۹۶۵۰ خودش فقط می‌گوید باید یک قرارداد نام‌گذاری وجود داشته باشد؛ ساختار معروف چندبخشی شامل پروژه، تولیدکننده، سیستم، طبقه، نوع، نقش و شماره‌ی ترتیبی از BS ۱۱۹۲ و ضمیمه‌ی ملی بریتانیا می‌آید. اگر کارفرما سیستم کدگذاری دارد از او پیروی کنید. اگر ندارید، چیزی مثل FAC-ST-DWG-001 (پروژه، دیسیپلین، نوع مدرک، سریال) ساده و کافی است. کدها را لاتین بنویسید تا در نرم‌افزارها و اکسل مشکلی ایجاد نشود.

برای دیدن چگونگی وزن‌دهی، همان مثال نما را با اعداد فرضی ادامه می‌دهیم (عددها برای توضیح‌اند، نه مرجع برآورد):

وزن هر مدرک از تقسیم ساعت‌کار آن بر جمع کل به دست می‌آید. حالا ببینید این جدول چگونه به برنامه می‌رسد. محاسبه‌ی بار باد باید پیش از نقشه‌ی کارگاهی نهایی مهارها کامل شود. تولید انبوه هم به تأیید نمونه‌ی اولیه بسته است، پس گزارش Mock-up روی مسیر تدارکات و ساخت اثر دارد، حتی اگر در جدول وزن کمی داشته باشد. وزن‌ها را اهمیت زمانی تعیین نمی‌کند، ساعت‌کار تعیین می‌کند؛ این دو را با هم اشتباه نگیرید.

در P6 هر ردیف می‌تواند یک فعالیت باشد، با شناسه‌ای برگرفته از شماره‌ی مدرک. ساعت‌کار را به‌عنوان Budgeted Units بگذارید و برای چرخه‌ی هر مدرک Step تعریف کنید (تهیه، بازبینی داخلی، ارسال، دریافت نظر، صدور نهایی) و وزن‌ها را در Step لحاظ کنید تا درصد پیشرفت یکسان و قابل دفاع شود. این مبنا همان است که در مدیریت ارزش کسب‌شده (مثل ANSI/EIA-۷۴۸) انتظار می‌رود: بودجه‌ی روشن، معیار مشخص برای اندازه‌گیری پیشرفت و ارتباط با برنامه. در قراردادهای ایرانی بخشی از مبلغ مهندسی اغلب به تحویل یا تأیید مدارک گره می‌خورد، پس بررسی کنید وزن‌های MDL با جدول پرداخت قرارداد تعارض نداشته باشد؛ در غیر این‌صورت دو عدد پیشرفت دارید و هیچ‌کدام مورد قبول نیست.

اگر مدارک زیاد است (چند هزار نقشه‌ی مشابه)، گروه‌بندی منطقی می‌تواند راه‌حل باشد: مثلاً «نقشه‌های جزئیات نمای ضلع شمالی» به‌صورت یک فعالیت با وزن مجموع و ریز مدارک در سیستم کنترل مدارک. یک قاعده را همیشه رعایت کنید: منبع اصلی داده یکی باشد، معمولاً فایل MDL یا سامانه‌ی کنترل مدارک و P6 از آن تغذیه شود، نه این‌که هر دو جداگانه ویرایش شوند. دو MDL موازی در عمل به دو واقعیت متفاوت می‌انجامد.

MDL و MDR؛ فهرستِ برنامه و ثبتِ وضعیت واقعی

تا اینجا از MDL گفتیم. در بسیاری از پروژه‌ها کنار آن سند دیگری هم هست به نام MDR (Master Document Register). تفکیک دقیق و یک‌دست این دو نام در استانداردها نیامده و بعضی شرکت‌ها آن‌ها را مترادف می‌گیرند، پس نخست رویه‌ی کنترل مدارک همان پروژه را ببینید. تفکیکی که در عمل بیشترین کاربرد را دارد این است: MDL فهرست آنچه قرار است تهیه شود، با ساعت‌کار، وزن و تاریخ‌های هدف؛ و MDR دفتر ثبت آنچه واقعاً رخ داده، یعنی آخرین Rev.، وضعیت، شماره‌ی ترنسمیتال‌ها، تاریخ ارسال و بازگشت و کد پاسخ کارفرما. MDL شبیه برنامه‌ی هدف است و MDR شبیه گزارش واقعی. فاصله‌ی این دو همان جلوافتادگی یا تأخیر مهندسی است. ISO ۱۹۶۵۰ هم مفهوم مشابهی دارد: MIDP از جمع برنامه‌های تحویل هر تیم یا بسته (TIDP) ساخته می‌شود و در طول پروژه با وضعیت واقعی مقایسه می‌شود.

MDR باید هر بار که ترنسمیتالی خارج یا وارد می‌شود، همان روز به‌روز شود، نه آخر ماه. چون پیشرفت واقعی مهندسی از آن بیرون می‌آید، تاریخ‌های واقعی ارسال و بازگشت از آن به P6 می‌رود (Actual Start و Finish) و اگر روزی ادعای تأخیر پیش بیاید، اولین مدرک همین است. در بسیاری از پروژه‌های ایرانی MDR یک فایل اکسل است که کنترل‌کننده‌ی مدارک (Document Controller) نگه می‌دارد و نامه‌ها از راه اتوماسیون اداری یا ایمیل رد و بدل می‌شوند. اشکال از اکسل نیست؛ اشکال وقتی است که MDR با نامه‌های واقعی یکی نباشد. هفته‌ای یک بار آن را با دفتر ثبت مکاتبات یا سامانه تطبیق دهید. نمونه‌ی ساده‌شده‌ای از MDR برای همان پروژه‌ی نما:

داده‌ها فرضی‌اند. معنی کدها را رویه‌ی هر پروژه مشخص می‌کند؛ در این نمونه ۱ تأیید، ۲ تأیید با اعمال نظر، ۳ رد و ارسال مجدد و ۴ فقط جهت اطلاع است.

همین چند سطر اطلاعات مهمی دارد. نقشه‌ی کارگاهی ۲۲ روز در بررسی بوده؛ اگر قرارداد (فرض کنید) ۱۴ روز مهلت داده، هم تأخیر بررسی ثبت شده و هم چرخه‌ی دومی لازم شده است که روی تاریخ IFC اثر می‌گذارد. اگر این ثبت‌ها دقیق نباشد، نه می‌توانید دلیل تأخیر را توضیح دهید و نه مدت بررسی را در به‌روزرسانی‌های بعدی برنامه واقع‌بینانه‌تر کنید.

یک نقشه چگونه تا IFC می‌رسد؟

نقشه‌ی کارگاهی نمای کامپوزیت (همان ردیف ۲۴۰ ساعتی MDL) را دنبال کنیم. مسیر آن، با تفاوت‌هایی که از شرکتی به شرکت دیگر هست، تقریباً این است:

1. دریافت ورودی‌ها. نقشه‌های معماری تأییدشده‌ی نما، مبانی طراحی، نتیجه‌ی محاسبات بار باد، اطلاعات سازنده‌ی پروفیل و ورق و موقعیت صفحات کارگذاشته‌شده در اسکلت. نقشه‌ای که بر ورودی تأییدنشده بنا شود، بعداً بازکاری می‌شود.
2. تهیه. طراح یا نقشه‌کش زیر نظر مهندس مسئول مدرک نقشه را می‌کشد.
3. بازبینی داخلی. نفر دوم (Checker) نقشه را با چک‌لیست بررسی می‌کند و مهندس ارشد دیسیپلین آن را تأیید داخلی می‌کند.
4. هماهنگی بین‌دیسیپلینی (IDC). اسکلت، تأسیسات و معماری نقشه را می‌بینند. در پروژه‌ی نما همین‌جاست که فاصله‌ی نما از سازه یا محل مهارها با واقعیت اسکلت تطبیق داده می‌شود.
5. تأیید مدیر مهندسی و ارسال. نقشه با ترنسمیتال به کارفرما یا مشاور فرستاده می‌شود: IFR برای نظر یا IFA برای تأیید. بعضی رویه‌ها فقط یکی از این دو را دارند.
6. بررسی کارفرما. در مدت قراردادی انجام می‌شود و نقشه با یک کد پاسخ برمی‌گردد.
7. رفع نظرات. به هر نظر در برگه‌ی پاسخ (CRS) جواب داده می‌شود، نقشه اصلاح می‌شود و با Rev. بعدی دوباره می‌رود. این چرخه تا تأیید می‌تواند چند بار تکرار شود.
8. صدور IFC. پس از تأیید، نقشه با وضعیت IFC صادر و به کارگاه یا کنترل مدارک اجرا توزیع می‌شود. در بسیاری از پروژه‌ها در این لحظه شماره‌ی Rev. از حرف به عدد می‌رود (مثلاً از B به ۰). این قاعده رایج است، ولی الزام همگانی نیست.
9. پس از IFC. تغییرات حین ساخت با Rev. جدید وارد می‌شود و در پایان کار نسخه‌ی چون‌ساخت (As-Built) صادر می‌شود.

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

درصدها فرضی‌اند. جدول پرداخت قرارداد تعیین می‌کند آیا پیشرفت مرحله‌های وابسته به کارفرما (بررسی و تأیید) را می‌شود به نام پیمانکار نوشت یا نه.

در برنامه، مدت تهیه از ساعت‌کار می‌آید: ۲۴۰ ساعت با دو نفر و هشت ساعت کار روزانه می‌شود ۱۵ روز کاری. فرض کنیم بازبینی داخلی و IDC سه روز، بررسی کارفرما ۱۴ روز طبق قرارداد و رفع نظرات هفت روز طول بکشد. نقشه‌های بحرانی یا طولانی، مثل همین نقشه‌ی کارگاهی یا دیتاشیت یک تجهیز بلندمدت، را می‌ارزد به چند فعالیت بشکنید: «تهیه تا ارسال»، «بررسی کارفرما» و «رفع نظرات تا IFC»، با رابطه‌ی پایان به شروع. در این حالت اگر کارفرما دیر جواب بدهد، در برنامه معلوم می‌شود تأخیر از کجاست. مدارک معمولی را با یک فعالیت و Step نگه دارید تا برنامه سنگین و غیرقابل نگهداری نشود. اگر ریسک رد شدن بالاست، یک چرخه‌ی دوم بررسی کوتاه‌تر هم می‌توانید پس از اولی قرار دهید. خروجی هر دو مسیر، IFC است که شروع تولید یا اجرا را آزاد می‌کند.

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

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

تعداد نظرات و روزهایی که صرف بستن آن‌هاست، پایه‌ی برآورد مدت «رفع نظرات» در بازنگری‌های بعدی برنامه می‌شود. سومین فرم گزارش هفتگی پیشرفت مهندسی است که مسئولان دیسیپلین‌ها پر می‌کنند و کنترل پروژه بر مبنای آن برنامه را به‌روز می‌کند:

عددها فرضی‌اند. در این نمونه معماری و سازه با ساعت‌کار مصرف‌شده و باقی‌مانده به پیش‌بینی بیش از ساعت‌کار کل می‌رسند (۱۹۰ از ۱۸۰ و ۴۳۰ از ۴۰۰) و همین می‌تواند هشدار زودهنگام باشد.

ستون «ساعت باقی‌مانده» مهم‌ترین ستون این فرم است. مسئول دیسیپلین آن را از روی کار باقی‌مانده برآورد می‌کند و کنترل پروژه از روی درصد حدسش نمی‌زند. دو عدد «پیشرفت واقعی» و «ساعت مصرف‌شده» را کنار هم ببینید تا بفهمید مهندسی زودتر از آنچه انتظار می‌رفت ساعت می‌سوزاند یا نه.

دست آخر باید به کاری برسیم که کمتر درباره‌اش حرف می‌زنیم: گرفتن اطلاعات درست از مهندسی. برنامه را کنترل پروژه می‌نویسد، اما مدت‌ها، ظرفیت‌ها و پیش‌نیازها را مهندسان می‌دانند. اگر این اطلاعات را منظم و کتبی نگیرید، برنامه‌ای می‌نویسید که هیچ‌کس خود را به آن متعهد نمی‌داند. معمولاً با یک جلسه‌ی کارگاهی با مسئولان دیسیپلین‌ها شروع می‌کنم، یک فرم یا اکسل ساده می‌دهم، پاسخ‌ها را مکتوب می‌گیرم و فرضیات را در خود برنامه ثبت می‌کنم (AACE 38R-۰۶ هم بر مستندسازی مبنای برنامه تأکید دارد). فهرست کامل چیزهایی که کنترل پروژه باید از مهندسی بگیرد این است:

1. MDL و MDR تأییدشده. شماره، عنوان، دیسیپلین، ناحیه، نوع مدرک و آخرین Rev.
2. ساعت‌کار هر مدرک. همراه با مبنای برآورد (نرخ تاریخی یا برآورد مسئول) و اگر ممکن است تفکیک به تهیه، بازبینی و رفع نظرات.
3. مراحل صدور و وزن‌ها. رویه‌ی IFR، IFA و IFC، Stepها و درصدهایشان و جدول پرداخت مرتبط با مدارک.
4. ورودی‌های هر مدرک. چه اطلاعات و مدارکی از دیسیپلین‌های دیگر، کارفرما یا سازندگان لازم است و چه کسی مسئول تأمین آن‌هاست.
5. تاریخ نیاز هر مدرک. IFC هر مدرک کدام ناحیه یا بسته‌ی اجرایی، کدام درخواست خرید یا کدام سفارش را آزاد می‌کند و تاریخ لازم در کارگاه چیست.
6. نیروی انسانی. تعداد و تخصص هر دیسیپلین، تاریخ ورود و خروج، سهم هر نفر از پروژه (اگر هم‌زمان روی پروژه‌ی دیگری کار می‌کند) و ساعت کاری واقعی.
7. بهره‌وری مورد انتظار. تجربه‌ی پروژه‌های مشابه، مثلاً ساعت لازم برای نقشه‌ای با اندازه و پیچیدگی معین.
8. مدت چرخه‌های داخلی. بازبینی، IDC و تأیید مدیر مهندسی.
9. مدت بررسی کارفرما. هم طبق قرارداد و هم بر اساس سابقه‌ی واقعی پاسخ‌دهی او یا مشاور، همراه با تعداد چرخه‌ی محتمل تا تأیید.
10. تقویم‌ها. هفته‌ی کاری و تعطیلات دفتر مهندسی، سازنده و بررسی‌کننده، اضافه‌کاری یا شیفت.
11. تاریخ‌های قراردادی. مهلت MDL، مدارکی که در قرارداد تاریخ مشخص دارند و نقاط عطف پرداخت وابسته به مدارک.
12. ورودی‌های کارفرما و مراجع ثالث. اطلاعات پایه، نتایج مطالعات خاک و برداشت، مجوزها و تأییدیه‌های شهرداری، نظام مهندسی، آتش‌نشانی یا مراجع دیگر و زمان تحویل هر کدام.
13. مدارک سازندگان (Vendor Data). اقلامی که طراحی به آن‌ها وابسته است، تاریخ سفارش‌گذاری، تاریخ موعود ارسال مدارک و وضعیت تأیید.
14. بررسی‌ها و مطالعات ویژه. مثل بررسی مدل سه‌بعدی در مراحل ۳۰، ۶۰ و ۹۰ درصد، HAZOP و بازبینی ایمنی در پروژه‌های صنعتی، یا آزمون نمونه و مصالح، با مدت و ظرفیت لازم.
15. ماتریس تعامل بین‌دیسیپلینی. کدام دیسیپلین به کدام وابسته است و چه اطلاعاتی را چه زمانی رد و بدل می‌کنند.
16. بسته‌های مهندسی. هر ناحیه برای آغاز ساخت چه مجموعه‌ای از مدارک لازم دارد، تا IFC هر بسته به اجرا وصل شود.
17. وضعیت واقعی هر مدرک. Rev.، وضعیت، تاریخ واقعی ارسال و بازگشت و کد پاسخ، از MDR و نه از حافظه.
18. ساعت مصرف‌شده و باقی‌مانده. از مسئول هر دیسیپلین، نه فقط درصد پیشرفت، تا پیش‌بینی پایان کار قابل سنجش باشد.
19. درخواست‌های اطلاعات (RFI) و موارد باز. چه سؤالاتی بی‌پاسخ مانده، از چه کسی، از چه تاریخ و کدام مدرک به آن‌ها وابسته است.
20. تغییرات. مدارک اضافه یا حذف‌شده، دستورکارهای تغییر، اثر آن‌ها بر ساعت‌کار و تاریخ‌ها و بازنگری‌های در انتظار MDL.
21. موانع و فرضیات. مواردی که مسئول دیسیپلین فکر می‌کند ممکن است تأخیر بسازد، با احتمال و اثر تقریبی، برای ثبت در برنامه یا فهرست ریسک.
22. برنامه‌ی نقشه‌های چون‌ساخت. چه زمانی، بر اساس چه اطلاعاتی و در قرارداد پیش یا پس از تحویل موقت.

این اطلاعات باید در هر دوره‌ی گزارش‌دهی، معمولاً هفتگی یا دوهفته‌ای، به‌روز شود؛ برای همین قالب MDR و گزارش پیشرفت باید ثابت بماند. اگر مسئولی ساعت باقی‌مانده را «حدسی» می‌دهد، مبنایش را بپرسید و بنویسید. اشتباه‌هایی که بیشتر می‌بینم فنی نیستند: شروع کار بدون MDL، ارسال MDL بدون پیگیری تأیید، مدارکی که پیش‌نیاز مشخص ندارند، بررسی کارفرمایی که در برنامه نیامده و وزنی که با صورت‌وضعیت نمی‌خواند. همه‌ی این‌ها با انضباط و مستندسازی درست می‌شوند.

منابع برای مطالعه‌ی بیشتر

• FIDIC, Conditions of Contract for Plant and Design-Build (Yellow Book) و for EPC/Turnkey Projects (Silver Book)، ویرایش ۲۰۱۷؛ بندهای مربوط به Contractor’s Documents (۵.۲ و ۵.۶ تا ۵.۸) و Programme
• ISO ۱۹۶۵۰-۱ و ISO ۱۹۶۵۰-۲:۲۰۱۸، مدیریت اطلاعات با BIM؛ مفهوم MIDP و TIDP
• ISO ۹۰۰۱:۲۰۱۵، بندهای ۷.۵ (اطلاعات مستند) و ۸.۳ (طراحی و توسعه)
• ISO ۲۱۵۰۲:۲۰۲۰ و ISO ۱۰۰۰۶:۲۰۱۷، راهنمای مدیریت پروژه و کیفیت در پروژه‌ها
• PMI، The PMBOK Guide (مدیریت زمان‌بندی پروژه)، Practice Standard for Work Breakdown Structures و Practice Standard for Scheduling
• AACE International، RP 37R-۰۶ (سطوح جزئیات برنامه در پروژه‌های EPC)، RP 38R-۰۶ (مستندسازی مبنای برنامه) و RP 29R-۰۳ (تحلیل پیشینه‌ی تأخیر)
• US GAO, Schedule Assessment Guide (GAO-۱۶-89G) و DCMA ۱۴-Point Assessment برای ارزیابی کیفیت برنامه
• ANSI/EIA-۷۴۸، استاندارد سامانه‌های مدیریت ارزش کسب‌شده
• شرایط عمومی پیمان (نشریه ۴۳۱۱)، به‌ویژه ماده‌ی ۲۲ (ترتیب گردش مدارک، نقشه‌ها و ابلاغ دستورکارها) و ماده‌ی ۳۹
• موافقتنامه، شرایط عمومی، شرایط خصوصی و پیوست‌های پیمان همسان طراحی و مهندسی، تأمین مصالح و تجهیزات، ساختمان و نصب (EPC) برای کارهای صنعتی؛ ماده‌های ۲ و ۴ تا ۹ (نظام فنی و اجرایی کشور، سازمان برنامه و بودجه)
• مبحث ششم مقررات ملی ساختمان و استاندارد ۲۸۰۰