این متن یک نوشته رسمی خشک یا دانشگاهی نیست. این تجربهٔ واقعی یک DCC کار هستش. کسی که روز اول هیچ چیز از دنیای مهندسی نمیدونست، اشتباه کرد، یاد گرفت و حالا میخواد تجربههای خودش رو ساده و صمیمی با شما آدم حسابی های درجه یک به اشتراک بذاره.
اولین روزی که وارد واحد کنترل و مدیریت اسناد و مدارک (DCC) شدم، هیچ چیز از دنیای مهندسی نمیدونستم. نه اصطلاحات را میفهمیدم، نه زبان مشترکی با مهندسها داشتم، نه میدونستم چرا یک نقشه میتونه اینقدر مهم باشه. کمکم و با صبر یاد گرفتم. گاهی اشتباه کردم و این طبیعی است رفیق. کسی که کار میکنه، اشتباه هم میکنه. همین اشتباهها باعث میشه مسیر رشد واقعی شکل بگیره.
اگر امروز اندک چیزی میدونم، حاصل تجربه، پیگیری، سؤال پرسیدن، تحمل فشار و مواجهه با اشتباههاست.
بخش DCC یعنی کسی که اجازه نمیده پروژه به خاطر مدارک اشتباه، عقب بیفته یا خراب بشه. وقتی میگم "خراب بشه" یعنی: لوله اشتباه نصب بشه، تجهیز غلط سفارش داده بشه، سازه اشتباه ساخته بشه یا حتی کارفرما پروژه رو متوقف کنه و میلیاردها تومان ضرر ایجاد بشه.
وظیفهٔ DCC در یک جمله: مدیریت ورود، خروج، شمارهگذاری، گردش، بایگانی و نسخههای مدارک مهندسی.
هدفهای عملی:
• هیچ مدرکی گم نشه.
• نسخهٔ اشتباه به دست هیچکس نرسه.
• تاریخچهٔ همه چیز مشخص باشه.
• ارسالها دقیق و قابل پیگیری باشه.
• همه بدونند چه مدرکی کجاست و از مدارک بروز استفاده کنند.
یک DCC خوب مثل یک موتور دقیق در پروژه عمل میکند.
در پروژهها هیچکس روز اول همهچیز را بلد نیست. مهندسها با اصطلاحات عجیب حرف میزنند:
Rev C، AFC، As-built، P&ID، Plot Plan، Vendor Doc، NCR، Rev A01،…
اولش ممکنه فکر کنی اینها زبانِ بیگانهاند؛ اما کمکم میفهمی فقط زبان پروژه است و همه یاد میگیرند.
ویژگیهای یک DCC خوب:
• صبر
• دقت
• قدرت پیگیری
• نظم شخصی
• نترسیدن از اشتباه، پذیرش موقع اشتباه و یاد گرفتن از آن
پروژههای صنعتی معمولاً سه فاز طراحی دارند:
1. FEED (Front End Engineering Design)
ببینیم دقیقاً چی میخوایم بسازیم. تعیین ظرفیت، راهبرد کلی، برآورد اولیه هزینه.
2. Basic Design
طرح اولیه قابل اتکا؛ اسناد و نقشههایی که ساختار و مفاهیم اصلی را مشخص میکنند.
3. Detail Design
نقشههایی که با آنها واقعا ساخته میشود: همهٔ پیچها، جوشها، سیمکشیها و تجهیزات مشخص میشود.
نکته: در هر فاز مدارک باید بهدرستی ثبت، نسخهگذاری و منتشر شوند؛ اشتباه در Detail Design، هزینهٔ سنگینی دارد.
MDR — Master Document Register
یعنی لیست کامل مدارکی که پروژه نیاز داره. مثل یک لیست خرید برای یک مراسم بزرگ ولی ممکن است هزاران آیتم داشته باشه.
در MDR مشخص میشه:
• چه مدرکی لازم است
• کدام واحد مسئول تهیه آن است
• تاریخ تحویل
• وضعیت فعلی
بخش DCC باید MDR را دنبال کند تا هیچ مدرکی جا نماند.
شمارهگذاری یا Document Number شناسنامهٔ مدرک است. اگر اشتباه باشه کل جریان قاطی میشه. کدهای ترنسمیتال و Document Number ها باید یونیک (Unique) باشند؛ یعنی هر شماره فقط برای یک سند واحد در یک زمان استفاده شود.
ساختار رایج شمارهٔ مدرک (مثال):
1234-PIP-ISO-021-Rev00B
توضیح بخشها:
• 1234 = شماره پروژه
• PIP = واحد مهندسی (Piping)
• ISO = نوع مدرک (Isometric)
• 021 = شمارهٔ متوالی داخلی
• Rev00B = بازنگری / نسخهٔ فعلی
چند قانون ساده:
• هر شماره باید یکتا باشد.
• قسمت Rev برای نشان دادن تغییرات نسخههاست.
• اگر سند حذف یا منسوخ شد، شمارهاش را نمیگیریم دوباره؛ معمولاً آن را با وضعیت مشخص
(VOID یا Cancelled) بیرون میآوریم.
جریان معمول مدارک:
1. مهندس یا طراح مدرک را آماده میکند.
2. بخش DCC مدرک را ثبت، شمارهگذاری و بارگذاری میکند.
3. مدرک همراه با ترنسمیتال (Transmittal) برای کارفرما یا مراجعی که باید بررسی کنند ارسال میشه.
4. کارفرما/ناظر بررسی و کامنت میدهد (Comment Sheet).
5. مهندس اصلاح میکند و نسخهٔ جدید تولید میشود.
6. بخش DCC نسخهٔ جدید را ثبت میکند.
7. نسخهٔ تأیید شده برای کارگاه و مجریان ارسال میشود.
هر خطا در این مسیر باعث تأخیر و هزینه میشود.
ترنسمیتال (Transmittal / TR) یعنی پاکت رسمی همراه مدارک. یک برگه مدیریتی که میگوید:
• چه مدارکی ارسال شده
• هدف ارسال چیست (Approval / For Review / For Information)
• شمارهٔ نسخهها چیست
• تاریخ ارسال و گیرنده کیست
ترنسمیتال باعث میشود همهچیز قابل پیگیری باشد. کد ترنسمیتال هم باید یکتا باشد.
حالات معمولِ هدف در ترنسمیتال:
• For Approval — نیاز به تأیید رسمی دارد.
• For Review — فقط بررسی و کامنت میخواهند.
• For Information (FYI) — برای اطلاعرسانی است.
• P&ID (Piping & Instrumentation Diagram) — نقشهٔ قلب پروژه؛ جریانها، شیرها، ابزار کنترلی و ارتباط بین آنها.
• Plot Plan — نقشهٔ جانمایی تجهیزات؛ مثل نقشهٔ شهرِ سایت.
• Isometric (ISO) — نقشههای اجرایی لوله بهصورت ایزومتریک.
• Datasheet — شناسنامهٔ تجهیز (ابعاد، جنس، مشخصات فنی).
• Vendor Documents (VENDOR DOC) — مدارکی که سازندهٔ تجهیز میدهد: دادهبرگ، چارتها، نقشههای ساخت.
• Specification (SPEC) — مشخصات فنی کلی برای ساخت/تأمین.
کار DCC: اطمینان از نسخهٔ بروز و ثبت تمامی این مدارک است.
چند اشتباه پرتکرار که خود من هم تجربه کردم:
• ارسال نسخهٔ قدیمی به کارگاه → فاجعه (وقفه و دوبارهکاری)
• شمارهگذاری غلط → مدارک گم میشه
• بایگانی ناقص → کارفرما گیر میده
• گردش اشتباه (فرستادن به نفر اشتباه) → تأیید نمیشه
هر کدام از اینها راهحل مشخصی داره:
چک لیست قبل ارسال، دو بار کنترل نسخه، سیستم قوی ثبت و پیگیری.
یکی از اولین اشتباههایی که کردم این بود که به جای فرستادن Revision جدید، نسخهٔ قدیمی را فرستادم. نتیجه:
• کار مهندس متوقف شد.
• برداشت اشتباه از نقشه شد.
• چند ساعت وقت همه تلف شد.
از آن روز یاد گرفتم:
• همیشه دو بار چک کن.
• به نسخهها حساس باش.
• از اشتباهات فرار نکن؛ بپذیر و اصلاح کن.
(این بخش خیلی مهمه ساده و با مثال نوشته شده تا کسی که دانشگاه مهندسی هم نخونده، بفهمه)
• Rev / Revision — نسخه / بازنگری. نشاندهندهٔ تغییرات در سند.
مثال: RevA → اولین بار، RevB → بازنگری اول.
• AFC — Approved For Construction (تأیید شده برای ساخت). یعنی این نسخه اجازهٔ اجرا دارد.
• As-built — نقشهٔ ساختخورده؛ نشان میدهد بعد از اجرا چه چیزی واقعا ساخته شد (ممکن است با نقشهٔ طراحی متفاوت باشد).
• P&ID — Piping & Instrumentation Diagram — نقشهٔ ابزار و خط لولهها.
کاربرد: مرجع مهندسی ابزار و کنترل و نشاندهندهٔ جریانها.
• Plot Plan — نقشهٔ جانمایی تجهیزات.
کاربرد: تعیین محل نصب تجهیزات در سایت.
• Vendor Doc — مدارک سازنده. کاربرد: مشخصات و اطلاعات فنی تجهیزات.
• MDR — Material/Document Requirement List — لیست نیازمندی مدارک.
• TR — Transmittal — برگهٔ ارسال مدارک (ترنسمیتال).
• CS — Comment Sheet — برگهٔ نظرات/کامنتها.
• RP — Reply Sheet — برگهٔ پاسخ به کامنتها.
• NCR — Non-Conformance Report — گزارش عدم انطباق; وقتی چیزی مطابق با مشخصات نیست.
• PQR — Procedure Qualification Record — سوابق صلاحیت روش جوشکاری (کیفیت جوش).
• WPS — Welding Procedure Specification — دستورالعمل جوشکاری.
• KOM / K.O.M — Kick-Off Meeting — جلسهٔ آغاز پروژه.
• PIM — Pre-Inspection Meeting — جلسهٔ پیش از بازرسی.
• M.O.M — Minutes Of Meeting — صورتجلسه.
• TQ — Technical Query — پرسش فنی؛ وقتی موضوعی نامشخص است.
• Deem Approve — وقتی پاسخ رسمی تأیید نداریم ولی با فرض عدم تأثیر منفی، مدرک قبول میشود (معمولا با شرایط محدود).
• Void (ترنسمیتال یا سند) — ابطال؛ وقتی یک ترنسمیتال یا سند فاسد، اشتباه یا بلااستفاده میشود.
• As-Built Process — فرآیند نهایی کردن مدارک پس از اجرا؛ ثبت تغییرات واقعی سایت در مدارک.
• Final Book / Final Data Book / Vendor Data Book — مجموعهٔ نهایی مدارک پروژه که به کارفرما یا مالک تحویل میشود؛ شامل تمامی مدارک، نقشهها، گواهیها و سوابق تست.
• Transmitter (در بحث ابزار: Transmitter) — دستگاهی که کمیتهای فیزیکی (مثل فشار، دما) را به سیگنال الکتریکی تبدیل و ارسال میکند.(توجه: کلمهٔ ترنسمیتر در پروژه هم ممکن است معنای فنی داشته باشد.)
• Grating — صفحهٔ فلزی مشبک که در سکوها و راهروها استفاده میشود.
وقتی مدرکی ارسال میشود ممکن است پاسخهای مختلفی دریافت شود:
• Approved — تأیید کامل؛ مدارک آماده اجرا.
• Approved with Comments — تأیید همراه با چند نکته که باید در مدارک بعدی لحاظ شود.
• Revise and Resubmit — باید بازنگری شود و دوباره ارسال شود.
• Rejected — رد شده؛ نیاز به اصلاح اساسی.
رویهٔ هماهنگی:
1. ثبت ترنسمیتال و شمارهٔ یکتا.
2. ضمیمه کردن Comment Sheet یا RP اگر وجود دارد.
3. تعیین مسئول اصلاح (مهندس یا پیمانکار).
4. مهلتبندی اصلاح و ثبت در MDR.
5. تأیید نهایی و آرشیو.
• هر سند قبل از ارسال باید حداقل دو بار چک شود (فایل و شماره).
• برای هر ترنسمیتال تاریخ و مسئول پیگیری مشخص باشد.
• پیگیریِ پاسخها در MDR و گزارشگیری هفتگی.
• اگر پاسخ دیر آمد، دلیل تأخیر ثبت و در جلسهٔ هفتگی مطرح شود.
1. پیمانکار مدارک را بر اساس Spec و MDR تهیه میکند.
2. مدارک داخلی پیمانکار بازبینی میشود (QA/QC پیمانکار).
3. مدارک به DCC تحویل داده میشود.
4. بخش DCC ثبت و ترنسمیتال میزند و برای کارفرما ارسال میکند.
5. کارفرما بررسی و یا درخواست اصلاح میدهد.
6. پیمانکار اصلاح میکند و نسخهٔ جدید ارسال میشود.
بخش DCC نقش تسهیلکننده و ثبتکننده را دارد به این معنا که مسیر یکپارچه و قابل پیگیری ایجاد کند.
• EPCC / EPC Contractor — پیمانکار مهندسی، تدارکات، ساخت و راهاندازی.
• Vendor — تولیدکنندهٔ تجهیزات.
• Subcontractor — پیمانکار فرعی که شاید بخشی از کار (مثل عایقکاری یا لولهکشی) را انجام دهد.
بخش DCC باید بداند هرکدام کدام مدارک را تهیه یا تحویل میدهند.
• K.O.M (Kick-Off Meeting)
شروع پروژه: تعیینِ نقشها، برنامهٔ کلی و مدارک پایه.
• PIM (Pre-Inspection Meeting)
پیش از بازرسی: چک لیستها و مدارک مورد نیاز.
• M.O.M (Minutes of Meeting)
صورتجلسه؛ باید دقیق و ثبتشده باشد.
• NCR (Non-Conformance Report)
وقتی چیزی مطابق مشخصات نیست (مثلاً جوش بد یا تجهیز معیوب). این گزارش معمولاً باید ریشهیابی، اقدام اصلاحی و ثبت شود.
• TQ (Technical Query)
پرسش فنی: وقتی مطلبی در مدارک یا اجرا نامشخص است. پاسخ TQ ممکن است منجر به تغییرات مدرک شود.
تفاوت کلیدی:
NCR یک مشکل یا انحراف است ( وقتی خرابکاری پیش میاد، سراغش میرن رفیق)؛ TQ یک سؤال برای روشنسازی یا تصمیمگیری است ( قبل از مشکل سراغش میرن).
وقتی ترنسمیتال یا سندی اشتباه ارسال شده یا لازم نیست، آن را VOID (ابطال) میکنیم .
رویهٔ ساده:
1. ثبت دلیل Void در سیستم.
2. شمارهٔ جدید برای ارسال صحیح تولید شود.
3. اطلاعرسانی به تمام گیرندگان قبلی که ترنسمیتال ابطال شده.
4. در صورت لزوم، بازبینی داخلی برای جلوگیری از تکرار.
گاهی مسئول تأیید پاسخی نمیدهد اما پروژه نیاز به ادامهٔ کار دارد. در این حالات ممکن است از "Deem Approve" استفاده شود: یعنی با قید و شرط (معمولا محدود) مدرک قابل استفاده است تا زمان دریافت جواب رسمی.
قانونی کار: همیشه Deem Approve باید مستند، موقتی و با موافقت مدیریت باشد.
یعنی مدارکی که نشان میدهد واقعاً چه چیزی در سایت ساخته شده است — شامل تغییرات اجرا شده نسبت به نقشهٔ اولیه.
فرآیند سادهٔ As-Built:
1. جمعآوری تغییرات روی نقشهها در حین اجرا.
2. ثبت همهٔ تفاوتها با نقشهٔ طراحی.
3. تهیهٔ نقشهٔ As-Built توسط مهندس و تایید آن.
4. بایگانی و اضافه کردن به Final Book.
مدرک As-Built بسیار مهم است چون آیندهٔ بهرهبرداری و نگهداری بر اساس آن انجام میشود.
هر تغییری در مدارک یا اجرا باید پیگیری و مستند شود:
• چرا تغییر لازم شد؟
• چه تأثیری دارد؟
• چه کسی تأیید کرد؟
• چگونه در مدارک اعمال شد؟
بخش DCC نقش کلیدی در ثبت change requests و تضمین بهروزشدن مدارک دارد.
این مجموعه، کتاب نهایی پروژه است که شامل همهٔ مدارک، گواهیها، گزارشهای تست، As-built و مدارک وندورهاست. تحویل Final Book یعنی پروژه مدارک کاملش را برای بهرهبرداری دارد.
بخش DCC مسئول جمعآوری، مرتبسازی و تحویل این مجموعه است.
• قبل از ارسال: شماره، Rev و پیوستها را چک کن.
• هر ترنسمیتال یک شمارهٔ یکتا نیاز دارد.
• هر پاسخ کارفرما را ثبت و در MDR بهروز کن.
• اگر Rev اشتباه رفت — صادق باش، Void کن و نسخهٔ درست را سریع بفرست.
• پیگیریهای معوق را هفتگی بررسی کن.
مثال شمارهٔ سند:
5678-MEC-DRW-104-Rev0 پروژه 5678 واحد MEC (Mechanical) نوع DRW (Drawing) شمارهٔ 104 Rev0 نسخهٔ اولیه
مثال ترنسمیتال:
TR-5678-2025-045 TR = Transmittal 5678 = شماره پروژه 2025 = سال 045 = شمارهٔ متوالی ترنسمیتال در آن سال
اگر همین TR اشتباه ارسال بشه، آن را VOID میکنیم و یک TR جدید با شمارهٔ بعدی ارسال میشود.
بخش DCC ستون پنهان اما حیاتی هر پروژهٔ صنعتی است. اگر مدارک اشتباه یا دیر برسند، پروژه از ریتم میفته، هزینهها بالا میره، زمان میسوزه و کارگاه سردرگم میشه. اما یک DCC منظم، دقیق و پیگیر مثل یه فرمانده پشتصحنه است؛ کاری میکنه که مدارک مثل خون در رگهای پروژه جریان داشته باشن — تمیز، منظم و قابل ردیابی.
مسیر تبدیلشدن به یک DCC حرفهای از دونستن اصطلاحات شروع نمیشه؛ از اشتباه کردن، پذیرفتن، یاد گرفتن و پیگیری کردن شروع میشه. هر سند، هر ترنسمیتال، هر Rev، هر کامنت، هر MDR، یک قدم رو به جلوست و کسی که این مسیر رو با صبر، نظم و مسئولیتپذیری ادامه بده، تبدیل به بخش جداییناپذیر تیم مهندسی میشه.
این بخش رو جوری نوشتم که مثل یک چک لیست روی دیوار اتاق DCC بزنی و هر روز بهش نگاه کنید رفقا.
* یک اشتباه کوچک در Document No میتونه مثل دومینو کل جریان مدارک رو خراب کنه.
* قبل از ثبت، دو بار چک کن؛ بعد از ثبت، دست نزن مگر با فرآیند Void.
* ۸۰٪ فاجعهها همینجاست.
* نسخه، Rev، تاریخ، پیوستها… همه باید درست باشند.
* هدف واقعی DCC "مرتب کردن" نیست؛ "قابل پیگیری کردن" است.
* هر ارسال → شماره یکتا
* هر اصلاح → Rev یکتا
* هر تأخیر → دلیل ثبت شده
۴. با مهندسها رفیق شو، نه رودربایستی.
* اعتماد دوطرفه کارها را برقآسا جلو میبرد.
* وقتی مهندس بداند DCC دقیق است، خودش هم منظمتر عمل میکند.
* پروژه جایی برای پنهانکاری ندارد.
* سریع اعلام کن، VOID بزن، نسخه درست را بفرست.
* صداقت زمان را نجات میدهد.
* هر تأخیر در MDR یعنی خطر.
* مدرکMDR را هر روز نگاه کن.
* اگر کسی دیر کرد، پیگیری کن. این وظیفه توست، نه لطف.
* برگه TR یعنی اثر انگشت ارسال.
* اگر TR اشتباه باشد، همه چیز زیر سؤال میرود.
* شماره درست؟
* قسمت Rev درست؟
* پیوست کامل؟
* گیرنده درست؟
* هدف ارسال درست؟
آیندهٔ بهرهبرداری به این مدارک وابسته است.
هر تغییری که ثبت نشود، بعدها دردسر میشه.
ابزار جدید یاد میگیره
روشهای مدیریت مدارک را بهبود میده
به گزارشگیری مسلط است
نسخهها، فایلها و فرمتها را مثل کف دست میشناسه
هر چیزی که ثبت نشود، وجود خارجی ندارد.
مکالمهها، هماهنگیها، کامنتها، تغییرات، همه باید مستند شود.
ترکیب این سه ویژگی، DCC را شکستناپذیر میکنه.
اگر امروز داری این مسیر را شروع میکنی یا تازه واردش شدی، نترس!
همهٔ ما اشتباه کردیم، زمین خوردیم، نسخه را اشتباه فرستادیم، ترنسمیتال خراب زدیم… اما رشد واقعی از همینجا شکل میگیرد.
بخش DCC یعنی:
دقیق باشی، اما خشک نباشی.
منظم باشی، اما انعطافپذیر بمانی.
اشتباه کنی، اما روی پا بایستی.
پنهان باشی، اما حیاتی باشی.
و باور کن…
وقتی آخر پروژه Final Book را میگیری دستت و میدونی تمامش رو تو منظم و کامل کردی، حس فوقالعادهای داره انگار یک کتاب تاریخ کوتاه اما دقیق از پروژه ساختی.
کار DCC شبیه پیانو زدنه؛ شاید کسی که تو سالن نشسته فقط ملودیِ پروژه رو بشنوه اما پشت آن صداهای هماهنگ، انگشتهایی هستند که دقیق، منظم و بدون اشتباه روی هر کلید مینشینند و اگر حتی یک نت اشتباه نواخته بشه، تمام قطعه از ریتم میافته رفیق.
