ارکستر نامرئی

چگونه ماتریس RACI پروژه ساخت فید واتر پمپ را از غرق شدن نجات داد؟
(روایتی از مدیریت سیستمی در دل صنعت نیروگاهی)
مقدمه: چرا پروژهها قبل از شکست فنی، در سکوت میمیرند؟
آیا تا به حال دیدهاید که در یک اتاق جلسه، همه سر تکان میدهند و لبخند میزنند، اما وقتی پای عمل به میان میآید، توپ در زمین خالی میافتد و هیچکس مسئولیت آن را بر عهده نمیگیرد؟
داستان ما در شرکت مهندسی و ساخت اتفاق میافتد. جایی که قرار است یکی از حیاتیترین تجهیزات یک نیروگاه سیکل ترکیبی، یعنی قطعات اصلی "فید واتر پمپ" (Feed Water Pump) ساخته شود. این پمپها قلب تپنده نیروگاه هستند؛ اگر نزنند، بخاری تولید نمیشود و اگر بخاری نباشد، برقی نیست. اما چالش اصلی فنی نبود؛ چالش اصلی، هماهنگی بین دهها دپارتمان و پیمانکار بود.
مدیرعامل شرکت، مهندس کاوه، مردی با موهای جوگندمی و نگاهی نافذ، همیشه یک جمله معروف داشت که روی تخته وایتبرد اتاقش نوشته بود:
"یک پروژه، قبل از اینکه شروع شود، شروع میشود."
این داستان، روایتگر چگونگی استفاده از ابزار RACI Matrix (ماتریس مسئولیتها) در یک پروژه واقعی است. جایی که ما به جای تئوریهای خشک، میبینیم که چگونه تعیین دقیق نقشها در زمان مناقصه، ارزیابی پیمانکاران و ساخت، جلوی فاجعه را گرفت.
تذکر : اسامی فرضی است
پردهبرداری از ابزار: رمزگشایی کد RACI و تاریخچه آن
قبل از اینکه وارد کارگاه شویم، بیایید جعبه ابزارمان را بشناسیم. این چهار حرف جادویی از کجا آمدهاند و دقیقاً چه معنایی دارند؟
تاریخچه کوتاه: از هرجومرج تا نظم
ریشههای ماتریس مسئولیتها به دهه ۱۹۵۰ میلادی و مفهوم "نمودار مسئولیت خطی" (Linear Responsibility Charting - LRC) برمیگردد. در دوران پس از جنگ جهانی دوم و رشد سازمانهای پیچیده صنعتی، مدیران دریافتند که ساختار سازمانی سنتی (چارت درختی) نمیتواند پیچیدگی روابط بین واحدها را نشان دهد. این ابزار در دهه ۱۹۷۰ تکامل یافت و به شکل امروزی RACI (که گاهی ARCI نیز نامیده میشود) درآمد تا به یک سوال ساده اما حیاتی پاسخ دهد: "چه کسی، چه کاری را انجام میدهد؟"
تشریح حروف چهارگانه:
ماتریس RACI یک جدول است که در آن سطرها "فعالیتها" و ستونها "نقشها" هستند. تقاطع آنها با یکی از این چهار حرف پر میشود:
- R - مسئول اجرا (Responsible):
- مفهوم: "انجامدهنده کار". سربازی که در میدان میجنگد.
- توضیح: فرد یا واحدی که عملاً کار را انجام میدهد. هر فعالیت حداقل باید یک R داشته باشد.
- مثال در داستان ما: واحد مهندسی که نقشه را میکشد.
- A - پاسخگو (Accountable):
- مفهوم: "کسی که گردنش گرو است".
- توضیح: فردی که مسئولیت نهایی نتیجه کار با اوست. او اختیار "وتو" کردن دارد. طبق قانون طلایی RACI، برای هر فعالیت فقط و فقط یک نفر باید A باشد تا از سردرگمی جلوگیری شود.
- مثال در داستان ما: مدیر پروژه که اگر نقشه غلط باشد، او باید پاسخگوی کارفرما باشد.
- C - مورد مشورت (Consulted):
- مفهوم: "عقل کل یا متخصص موضوع".
- توضیح: کسانی که قبل از تصمیمگیری یا اقدام، نظر تخصصی آنها پرسیده میشود. ارتباط با آنها دو طرفه است.
- مثال در داستان ما: واحد متالورژی که در مورد جنس قطعه نظر میدهد اما خودش آن را نمیسازد.
- I - مطلع (Informed):
- مفهوم: "تماشاچی آگاه".
- توضیح: کسانی که باید از نتیجه کار باخبر شوند، اما در حین انجام کار نظری نمیدهند. ارتباط با آنها یک طرفه است.
- مثال در داستان ما: انباردار که باید بداند کی قطعه میرسد تا جا را خالی کند.

بخش اول: مه مه آلود مناقصه؛ چه کسی ماشه را میکشد؟
سؤال کلیدی: وقتی هنوز قراردادی وجود ندارد و همه چیز در حد حدس و گمان است، چه کسی مسئول ریسک قیمتگذاری است؟
همه چیز با یک فکس شروع شد (یا شاید یک ایمیل رسمی در اتوماسیون). کارفرما، درخواست ساخت "کیسینگ" (Casing) و "ایمپلر" (Impeller) فید واتر پمپ بویلر را ارسال کرده بود. زمان تحویل؟ غیرممکن. متریال؟ سوپر آلیاژهای پیچیده.
در شرکتهای سنتی، واحد بازرگانی قیمت را تخمین میزند و واحد مهندسی بعداً غر میزند. اما در شرکت ، مهندس کاوه تیم را فراخواند. هنوز پروژهای وجود نداشت، اما تیم سایه تشکیل شد.
در جلسه مناقصه، دعوا بالا گرفت. مدیر تولید میگفت: "ریختهگری این قطعه با این متریال در ایران ریسک ۵۰ درصدی خرابی دارد." مدیر فروش میگفت: "اگر قیمت ریسک را اضافه کنیم، مناقصه را میبازیم."
اینجا بود که اولین RACI غیررسمی شکل گرفت. مهندس کاوه پرسید: "چه کسی تصمیم نهایی قیمت را میگیرد؟ (Accountable)" و "چه کسی باید کار را انجام دهد؟ (Responsible)".
در این مرحله، ماتریس ما اینگونه تعریف شد:
- مسئول انجام کار (Responsible): واحد مهندسی و تولید (برای برآورد دقیق نفر-ساعت و متریال). آنها باید دیتا را میآوردند.
- پاسخگو (Accountable): مدیر پروژه مناقصه. او کسی بود که باید سرش را برای قیمت نهایی گرو میگذاشت. نه مدیر فروش!
- مشورت (Consulted): واحد بازرگانی (برای استعلام قیمت مواد خام) و واحد QC (برای تخمین هزینههای تست).
- مطلع (Informed): مدیرعامل.
نکته کلیدی منتورینگ: در فاز مناقصه، بزرگترین اشتباه این است که واحد فروش (که معمولاً Consulted است) نقش Accountable را بازی میکند. فروشنده میخواهد بفروشد، اما مدیر پروژه باید آن را بسازد.
بخش دوم: ارواح پیش از تولد؛ ارزیابی پیمانکاران قبل از ابلاغ
سؤال کلیدی: آیا میتوانیم بازیگران نمایش را قبل از اینکه سناریو نهایی شود، انتخاب کنیم؟
مناقصه ارسال شد. اما مهندس کاوه به سیستم "شروع قبل از شروع" اعتقاد داشت. او میدانست که گلوگاه این پروژه، عملیات ماشینکاری پیچیده روی پوستههای پمپ است. اگر بعد از برنده شدن تازه به دنبال پیمانکار بگردیم، سه ماه عقب هستیم.
بنابراین، فاز "ارزیابی و شناسایی" کلید خورد. در اینجا ماتریس RACI تغییر کرد و پیچیدهتر شد. ما نیاز به ارزیابی کیفی پیمانکاران داشتیم.
سناریوی واقعی: واحد تدارکات سه کارگاه ماشینکاری را معرفی کرد. اما واحد مهندسی معتقد بود دستگاههای آنها دقت میکرونی لازم برای "شفت" (Shaft) پمپ را ندارند. دعوای همیشگی بین "ارزانتر بودن" (تدارکات) و "با کیفیتتر بودن" (مهندسی).
ماتریس RACI در این فاز (پیش از قرارداد) این گره را باز کرد:
- R (مسئول اجرا): واحد تدارکات (وظیفه: پیدا کردن سورس و گرفتن استعلام).
- C (مورد مشورت - با حق وتو): واحد مهندسی و QC. (نکته مهم: در اینجا C فقط یک مشورت ساده نبود، بلکه یک مشورت الزامآور فنی بود).
- A (پاسخگو): مدیر زنجیره تأمین. او باید تصمیم میگرفت که آیا ریسک پیمانکار ارزانتر را میپذیرد یا خیر.
مهندس کاوه میگفت: "وقتی نقش A مشخص نباشد، تدارکات ارزانترین را میخرد و مهندسی بعداً میگوید من که گفته بودم خراب میشود! اما وقتی مدیر زنجیره تأمین A باشد، میداند که اگر قطعه خراب شود، او مقصر است، نه پیمانکار."
بخش سوم: کیکآف (Kick-off) و رونمایی از نقشه راه؛ چه کسی سکاندار است؟
سؤال کلیدی: آیا اعضای تیم میدانند که "تأیید نهایی" با "انجام دادن" تفاوت دارد؟
خبر آمد: مناقصه برنده شد!
حالا وقت جشن نبود، وقت جنگ بود. جلسه "کیکآف" برگزار شد. روی میز، نقشههای پیچیده پمپ فید واتر پهن شد. ۷۰۰ قطعه، از پیچهای کوچک تا حلزونیهای غولپیکر.
مهندس کاوه پای تخته رفت و جدول ماتریس RACI اصلی پروژه را کشید. او نمیخواست فقط وظایف را بگوید، او میخواست "مالکیت" را مشخص کند.
یک چالش بزرگ مطرح شد: تهیه مدارک فنی (WPS/PQR) جوشکاری.
- واحد جوشکاری فکر میکرد باید بنویسد.
- واحد مهندسی فکر میکرد باید بنویسد.
- واحد کنترل کیفیت فکر میکرد باید تأیید کند.
- کارفرما هم نظر داشت.
جدول اینگونه ترسیم شد:
فعالیت | واحد مهندسی | واحد جوشکاری | واحد QC | مدیر پروژه | کارفرما |
تهیه WPS | C | R | I | A | - |
تأیید داخلی | R | I | C | A | - |
تصویب نهایی | I | I | I | R | A |
تحلیل ماتریس: دقت کنید! واحد جوشکاری R است (باید بنویسد). اما مدیر پروژه A است (یعنی اگر WPS دیر آماده شود، مدیر پروژه بازخواست میشود، نه مهندس جوش). این باعث میشود مدیر پروژه هر روز پیگیر مهندس جوش باشد. این همان پویایی است که RACI ایجاد میکند.
بخش چهارم: بحران در ریختهگری؛ وقتی "R" کم میآورد، "A" چه میکند؟
سؤال کلیدی: وقتی بحران رخ میدهد، همه انگشت اتهام را به سوی هم میگیرند؛ RACI چگونه انگشتها را به سمت راه حل میبرد؟
ماه سوم پروژه. خبر بدی از کارگاه ریختهگری رسید. در تست رادیوگرافی (RT) قطعه اصلی ایمپلر، مکهای گازی (Porosity) دیده شد. قطعه رد شد (Reject).
فاجعه یعنی ۳۰ روز تأخیر در زمانبندی پروژه.
در حالت عادی، واحد بازرگانی به پیمانکار فحش میدهد، واحد مهندسی به بازرگانی میگوید "گفتم جای ارزان نرو" و مدیر پروژه گریه میکند.
اما در شرکت ماتریس فعال شد.
- فعالیت: مدیریت عدم انطباق (NCR)
- مسئول (R): واحد کنترل کیفیت (QC). وظیفه آنها شناسایی و ثبت دقیق مشکل بود.
- مورد مشورت (C): واحد مهندسی متالورژی. آنها باید راه حل فنی (مثلاً عملیات حرارتی مجدد یا جوش تعمیری) را ارائه میدادند.
- پاسخگو (A): مدیر پروژه.
مدیر پروژه (A) وارد عمل شد. او نمیتوانست متالورژی را حل کند، اما "اختیار" داشت. او جلسهای فوری با واحد مهندسی (C) گذاشت. مهندسی پیشنهاد داد که طبق استاندارد API 610، ترمیم مجاز است.
مدیر پروژه سریعاً این راه حل را برداشت و با کارفرما وارد مذاکر شد.
درس مدیریتی: اگر RACI نبود، واحد QC فقط گزارش خرابی میداد و کنار میکشید. اما چون مدیر پروژه A بود، میدانست که باید بین QC (شناسایی مشکل) و مهندسی (حل مشکل) پل بزند.
بخش پنجم: ارتباطات و ذینفعان؛ چه کسی باید بداند و چه کسی نباید دخالت کند؟
سؤال کلیدی: آیا ایمیلهای "CC" (رونوشت) شما صندوق پستی را پر کردهاند یا واقعاً اطلاعرسانی میکنند؟
پروژه به مراحل پایانی مونتاژ روتور پمپ رسیده بود. حساسیت بالا بود. بالانس دینامیکی روتور باید در دور ۳۰۰۰ rpm انجام میشد.
کارفرما نگران بود و مدام تماس میگرفت. از طرفی، مدیر مالی شرکت نگران جریان نقدینگی بود.
اینجا نقش I (Informed) حیاتی شد.
بسیاری از مدیران فکر میکنند I یعنی "به همه ایمیل بزن". اشتباه است! I یعنی "به کسی خبر بده که دانستنش روی تصمیمات بعدی او تأثیر دارد".
در ماتریس RACI برای تست نهایی:
- تیم اجرایی: R و A
- کارفرما: I (باید بداند تا برای تحویل آماده شود).
- مدیر مالی: I (باید بداند، چون بعد از تست موفقیتآمیز، صورتوضعیت صادر میشود و پول میآید).
مهندس کاوه یک قانون گذاشت: "گزارش تست را برای مدیرعامل نفرستید، فقط نتیجه نهایی (Pass/Fail) را بفرستید. اما برای مدیر فنی کارفرما، تمام نمودارهای ارتعاشسنجی را ارسال کنید."
این یعنی تفکیک هوشمندانه I در ماتریس. این کار باعث شد تیم فنی غرق در سؤالات غیرتخصصی مدیران ارشد نشود و تمرکزش روی بالانس پمپ باقی بماند.
بخش ششم: پایان سمفونی؛ تحویل و درس آموختهها
سؤال کلیدی: وقتی پمپ بارگیری شد و از در کارخانه بیرون رفت، چه کسی مسئول بستن پرونده است؟
پمپ فید واتر با موفقیت تست شد، رنگآمیزی شد و روی تریلی نشست. پروژه تمام شد؟ خیر. طبق فلسفه مهندس کاوه، "پروژه وقتی تمام میشود که دانش آن ثبت شود."
آخرین سطر ماتریس RACI: مستندسازی و درس آموختهها (Lessons Learned).
معمولاً در پایان پروژه، همه خستهاند و به پروژه بعدی میروند. مدارک گم میشوند.
اما ماتریس میگفت:
- R: مسئول دفتر فنی (جمعآوری تمام مدارک Final Book).
- A: مدیر تضمین کیفیت (QA). (او باید تضمین میکرد که اگر ۱۰ سال دیگر پمپ خراب شد، ما میدانیم چه آلیاژی در آن به کار رفته است).
- C: تمام مدیران واحدها (باید بیایند و بگویند چه اشتباهاتی کردند).
در جلسه نهایی، مدیر تولید گفت: "آن قالبی که برای پروانه ساختیم، در دفعات بعد باید تغییر شیب داشته باشد." این جمله میلیونها تومان ارزش داشت. اگر ثبت نمیشد، در پروژه بعدی دوباره همان اشتباه تکرار میشد. RACI تضمین کرد که یک نفر (A) یقهی بقیه را بگیرد تا این جملات ثبت شوند.
نتیجهگیری: عبور از هرج و مرج به هارمونی
داستان ساخت فید واتر پمپ در شرکت ،داستان تبدیل آهن و فولاد به یک ماشین پیچیده نبود؛ داستان تبدیل آشفتگی انسانی به نظم سازمانی بود.
ماتریس RACI در این پروژه یک جدول کاغذی نبود که به دیوار چسبانده شود و خاک بخورد. این ماتریس:
- در زمان مناقصه، مالکیت ریسک را مشخص کرد.
- در زمان پیش از اجرا، کیفیت تأمینکنندگان را تضمین کرد.
- در زمان بحران، مسیر حل مسئله را روشن کرد.
- در زمان پایان، دانش را در سازمان رسوب داد.
ما دیدیم که چگونه یک رویکرد سیستمی ("پروژه قبل از شروع، شروع میشود") همراه با ابزار درست، میتواند پیچیدهترین پروژههای مهندسی را مدیریت کند.
و حالا، سؤال نهایی از شما:
در پروژهای که همین الان درگیر آن هستید، آیا دقیقاً میدانید چه کسی توپ را در دست دارد، یا همه منتظرند تا دیگری آن را از زمین بردارد؟
نویسنده : علی منتظرالظهور 1404
ارکستر نامرئی.pdf
منابع و مراجع پیشنهادی برای مطالعه بیشتر
- Project Management Institute (PMI). (2021). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Seventh Edition. (فصل مربوط به مدیریت ذینفعان و تیم).
- Kerzner, H. (2017). Project Management: A Systems Approach to Planning, Scheduling, and Controlling. (مرجع کلاسیک مدیریت سیستمی پروژه).
- Smith, M. & Roebuck, J. (2019). The RACI Model: How to Assign Roles and Responsibilities.
- استاندارد API 610 (Centrifugal Pumps for Petroleum, Petrochemical and Natural Gas Industries) - جهت آشنایی با الزامات فنی و مستندسازی پروژههای پمپسازی.


