کارفرما و مدیریت پروژه
الزامات، تصمیمهای حاکمیتی، تعهدات کارفرما و پذیرش نقاط کلیدی را مدیریت میکند.
بررسی نیاز شماEPC سه فهرست مستقل مهندسی، خرید و ساخت نیست؛ زنجیرهای از وابستگی تا خروجی و تحویل قرارداد است. حدود تضمین عملکرد، ریسک و شروط تحویل باید از پیمان خوانده شوند، نه از مخفف EPC.
وابستگی مراحل اهمیت بیشتری از جمع درصدهای جداگانه دارد.
مبنای طراحی و مدارک بحرانی
وضعیت مجاز و تاریخ نیاز مصرف در خرید یا کارگاه کنترل میشود.
ورودی معتبر تأمین و اجرا
نمای مفهومی خدمات؛ با انتخاب مرحله، ورودی، کنترل و خروجی همان مرحله را ببینید.
قرارداد مهندسی، تأمین و ساخت، مسئولیت طراحی، خرید، اجرا و معمولاً آزمون و تحویل یک دارایی قابل بهرهبرداری را در اختیار یک پیمانکار اصلی قرار میدهد. کارفرما نیازهای عملکردی، حدود پروژه و معیارهای پذیرش را تعیین میکند و پیمانکار باید کل زنجیره را با مسئولیت یکپارچه مدیریت کند.
ویژگی تعیینکننده این مدل، «مسئولیت واحد» است؛ اما این به معنی سادگی کنترل نیست. پیمانکار EPC دهها مشاور، فروشنده و پیمانکار جزء دارد و هر تصمیم مهندسی میتواند خرید، ساخت، هزینه، تضمین عملکرد و تاریخ راهاندازی را تغییر دهد. گزارش سه حوزه جداگانه، تصویر واقعی قرارداد را نمیسازد؛ روابط میان آنها باید قابل ردیابی باشد.
پذیرش نهایی معمولاً به تحقق ظرفیت، کیفیت محصول، مصرف انرژی، قابلیت اطمینان یا سایر تضمینهای عملکردی وابسته است. بنابراین کنترل پروژه باید از همان طراحی، الزامات عملکرد و پرونده تحویل را تا آزمون نهایی دنبال کند.
سامانه زمانی قابل اتکا است که گردش اطلاعات و اختیار تصمیم دقیقاً با ساختار واقعی قرارداد منطبق باشد.
الزامات، تصمیمهای حاکمیتی، تعهدات کارفرما و پذیرش نقاط کلیدی را مدیریت میکند.
مالک برنامه تلفیقی و مسئول هماهنگی همه حوزهها، بستهها و زیرپیمانکاران است.
بخشهای تخصصی را اجرا میکنند ولی اطلاعات آنها باید در مدل واحد پیمانکار اصلی تجمیع شود.
معیار آمادگی، آزمون، پذیرش سیستم و انتقال دارایی به عملیات را شکل میدهد.
هر گلوگاه با علت ریشهای، پیامد قراردادی و علامت هشدار زودهنگام بررسی شده است.
این مثال نشان میدهد چگونه مدرک ناقص یا اختیار ناکافی، عبور از دروازه را متوقف میکند. هیچ عدد عملکرد یا سابقه مشتری در این تصویر ادعا نمیشود.
پیشنیاز ناقص یا نقش فاقد اختیار، اجازه عبور از دروازه نمیدهد.
نمونه تعاملی با داده فرضی و وضعیت محلی مرورگر؛ داشبورد مشتری یا مجوز واقعی نیست. کنترل دسترسی سامانه سفارششده باید در سرور اجرا شود.
عنوان EPC حدود ریسک، تضمین عملکرد و شرایط پرداخت را بهتنهایی تعیین نمیکند. تعهد نتیجه و مسئولیتهای طرفین از اسناد و شرایط خصوصی همان پیمان استخراج میشوند.
تغییر این مدرک یا تأخیر این تجهیز، کدام جبهه و کدام دروازه تحویل را متأثر میکند؟
نمای شروط دروازه و علت هر مانع با مسیر برگشت به مدرک، تجهیز و فعالیت.
یک سیستم هدف یا بسته بحرانی، چند وابستگی واقعی میان E/P/C و یک سناریوی تغییر.
طراحی و آزادسازی اطلاعات
خرید، ساخت و تحویل تجهیز
ساخت، نصب و تکمیل
آزمون، تحویل و خاتمه
پروجکت ۳۶۰ یک ستون فقرات اطلاعاتی EPC میسازد: ساختار شکست، مدارک، تگ تجهیزات، بسته خرید، جبهه ساخت و سیستم راهاندازی به هم نگاشت میشوند. پیشرفت، هزینه، تغییر و ریسک روی همین مدل مشترک مینشینند؛ در نتیجه هر انحراف از علت مهندسی یا تأمین تا اثر کارگاهی و تاریخ تحویل قابل دنبالکردن است.
هر لایه با داده ورودی، مسئول، گردش تصویب، کنترل سیستمی و خروجی قابل تحویل طراحی میشود.
طراحی مدل کدینگ و روابط میان ساختار شکست، مدارک، اقلام، فعالیتها و سیستمهای تحویل.
تعریف نقاط عطف و وزنها و اتصال برنامه تفصیلی حوزهها به نقاط کلیدی قرارداد.
کنترل مدارک، تجهیز، دسترسی، مجوز و کیفیت پیشنیاز قبل از بسیج منابع ساخت.
اتصال بودجه، سفارش، پیمان جزء، هزینه واقعی، تغییر و پیشبینی نهایی به بسته کاری.
پرونده واحد از منشأ فنی تا اثر زمان، هزینه، خرید، ساخت، مصوبه و اجرای تغییر.
تبدیل ساختار اجرا به سیستمهای تحویل و کنترل پانچ، آزمون، مدارک و تضمین عملکرد.
برای هر تصمیم، ورودی لازم، مرجع تصمیم و مدرک اثبات تعریف میشود تا کنترل از حالت سلیقهای خارج شود.
شاخص و گزارش زمانی ارزش دارد که به یک تصمیم، مسئول و اقدام اصلاحی منتهی شود.
کدام وابستگی بین مهندسی، خرید و ساخت مسیر بحرانی را تهدید میکند؟
پیشرفت اعلامی چه میزان به شواهد قابل پذیرش متکی است؟
پیشبینی هزینه و تاریخ نهایی با کدام فرضها ساخته شده است؟
کدام تغییر هنوز در همه حوزههای متأثر اعمال نشده است؟
کدام سیستم برای راهاندازی آماده نیست و مانع دقیق آن چیست؟
داشبورد کلان EPC
گزارش فصل مشترکها
منحنی پیشرفت تلفیقی
اقلام و مدارک بحرانی
پیشبینی هزینه و زمان
گزارش آمادگی تحویل
فرایند، داده، نقش، کنترل و گزارش باید آنقدر شفاف باشند که سازمان بتواند سامانه را واقعاً اداره و توسعه دهد.
دامنه کوچک و قابل آزمون، امکان بررسی قواعد با کاربران واقعی را فراهم میکند. گسترش سامانه پس از تأیید مدل داده و گردش پایلوت انجام میشود.
یک سیستم یا محدوده کوچک که هر سه زنجیره مهندسی، تأمین و اجرا را دارد انتخاب میشود. کدینگ و تاریخهای نیاز در همان محدوده یکپارچه میشوند.
کنار هم قرارگرفتن سه درصد، کنترل یکپارچه نمیسازد. سامانه باید نشان دهد کدام مدرک یا تجهیز، کدام جبهه و نقطه عطف را متوقف کرده است.
سیستم ← بسته ← مدرک ← تجهیز ← جبهه ← پذیرش
یک مانع از منشأ مهندسی یا تأمین تا جبهه و نقطه عطف تحویل متأثر دنبال شود.
سامانه جایگزین قضاوت حقوقی نیست؛ ابزار اجرای منضبط فرایند، مستندسازی و تصمیمگیری مبتنی بر داده است.
با کدینگ و روابط مشترک؛ مدرک به تجهیز، تجهیز به بسته خرید و فعالیت نصب، و فعالیت به سیستم تحویل متصل میشود.
بله. قواعد وزندهی و نقاط عطف هر حوزه تعریف میشوند و گزارش تلفیقی همراه با امکان ردیابی تا جزئیات ارائه میگردد.
اثر تغییر بر مدارک، سفارشها، کارگاه، برنامه، هزینه و تعهدات در یک پرونده بررسی و تصویب میشود.
بله. سیستمها، بستههای تکمیل، پانچ، آزمونها و مدارک نهایی میتوانند تا تحویل به بهرهبردار مدیریت شوند.
کنترل تحویلدادنیهای طراحی، نسخهها و نفرساعت مهندسی
ردیابی خرید، ساخت، بازرسی و تحویل کالا و تجهیزات
اتصال گزارش کارگاه، احجام، کیفیت و صورتوضعیت
هماهنگی مشخصات مهندسی با سفارش و ساخت تجهیزات
حاکمیت، هماهنگی و کنترل بستههای قراردادی متعدد
طراحی داشبورد مدیریت پروژه برای تحلیل زمان، هزینه، پیشرفت، ریسک و تعهدات؛ با تعریف شناسنامه شاخص، کنترل کیفیت داده و ردیابی تا منبع.
سامانه مدیریت قرارداد پروژه برای کنترل تعهدات، مکاتبات، تغییرات، تضامین، صورتوضعیت و پرداخت؛ با گردش تأیید و سابقه تصمیم قابل ردیابی.
سامانه کنترل هزینه و منابع پروژه برای اتصال بودجه، تعهدات، هزینه واقعی، نفرساعت و بسته کاری؛ تحلیل انحراف و پیشبینی هزینه نهایی.
مدل پیمان، یک گلوگاه مشخص و خروجی مطلوب را معرفی کنید. منطق تعهد، اختیار و شواهد باید پیش از توسعه در گردش سامانه تثبیت شود.
یک مدل تعاملی از منطق کنترل این حوزه؛ مراحل را انتخاب کنید و اثر توقف در نقطه حساس را ببینید.
مسیر در حالت عادی نمایش داده میشود.
تغییر مهندسی وقتی دیر به تأمین و اجرا برسد، اثر زمانی و مالی آن پنهان میماند.
درخواست تغییر به مدارک، اقلام خرید، فعالیتها، برآورد اثر و مرجع تصویب متصل میشود.
نسخه مبنا، علت تغییر، ارزیابی اثر، تصمیم مجاز و ابلاغ به ذینفعان باید یک زنجیره واحد بسازند.