روش محاسبه مدت زمان در Summary Bar ها در نرم افزار P6

مدت زمانی که در ستون Original Duration نمایش داده می شود برابر است با اختلاف کمترین تاریخ شروعدر فعالیت های زیر مجموعه با بیشترین تاریخ اتمام در فعالیت های زیر مجموعه با کسر روزهای تعطیل در تقویم مربوطه

.در نسخه 7 به بعد نرم افزار Primavera P6 روش محاسبه Duration در سطوح WBS یا Summary Bar ها نسبت به ورژنهای قبلی تغییر نموده است.

تقویم مربوطه طبق چارت زیر تعیین می شود.

         

 برای مثال در صورتی که زودترین زمان شروع فعالیت های زیر مجموعه یک ردیف WBS برابر با یکم (شنبه) و زودترین زمان پایان فعالیت ها برابر با پانزدهم (شنبه) باشد و تقویم همه فعالیت ها یک تقویم 5 روزه (پنج شنبه و جمعه تعطیل) باشد، مدت زمان ردیف WBS یازده روز نمایش داده می شود.

درصد پیشرفت واقعی را چگونه در نرم افزار P6 محاسبه نمائیم؟

بسته به روش برنامه ریزی و کنترل پیشرفت پروژه ها روش های مختلفی برای محاسبه درصد پیشرفت واقعی در P6 وجود دارد. اما متداول ترین ستون که درصد پیشرفت واقعی را نمایش می دهدPerformance % Complete می باشد که به عنوان معیار محاسبه Earned Value نیز در سیستم مورد استفاده قرار می گیرد.

 

درصد نمایش داده شده در ستون Performance % Complete در سطح فعالیت ها برابر است با درصد پیشرفت فعالیت (Activity % Complete) و در سطوح WBSیا Summary Barاز Roll-Up درصد ها بر اساس هزینه فعالیت ها محاسبه می­شود.

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

1- برنامه دارای Baseline باشد.

2- کلیه فعالیت ها در Baseline دارای هزینه باشند.

3- نوع درصد پیشرفت فعالیت ها به درستی انتخاب شده باشد (انواع درصد پیشرفت)

نکته 1: درصورتی که درصد پیشرفت در Duration % Complete ثبت می شود گزینه Recalculate Actual Cost and Units when Duration % Complete Changes در تنظیمات پروژه تب Calculationتیک بخورد.

نکته 2: در صورتی که در برنامه تخصیص منبع انجام نشده باشد لازم است یک منبع مجازی دارای نرخ هزینه بزرگتر از صفر با کاربری وزن به همه فعالیت ها تخصیص پیدا کند و وزن ها در بودجه آن تخصیص ها تعریف شود

روش محاسبه درصد پیشرفت برنامه ای در P6؟

درصد پیشرفت برنامه ای در نرم افزار Primavera P6 معادل ستون Schedule % Complete می باشد که برای فعالیت ها و سطوح WBS در تاریخ روز محاسبه می شود. درصد پیشرفت برنامه برای هر فعالیت به صورت خطی برابر با میزان گذشت زمان از شروع فعالیت تقسیم بر مدت زمان برنامه ای فعالیت محاسبه می شود.

درصد پیشرفت برنامه در سطوح WBS ازRoll-Up درصد های پیشرفت بر اساس هزینه فعالیت ها در Baseline محاسبه می­شود

برای اینکه درصد پیشرفت برنامه ای به صورت صحیح محاسبه شود لازم است موارد زیر در برنامه لحاظ شود.

1- برنامه حتماً دارای Baseline باشد.

2- کلیه فعالیت ها در Baseline دارای هزینه باشند.

فعالیت

BL Total Cost

BAC

Schedule % Complete

فعالیت 1

100$

100$

100%

فعالیت 2

200$

200$

50%

فعالیت 3

200$

200$

0%

WBS 1

500$

500$

(100% * 100$ + 50% * 200$ + 0% * 200$) / 500$ = 40%

 

در

 

پروژه های ساخت چه تنظیماتی برای پروژه و فعالیت ها مناسب می باشد؟

در پروژه هایی که در صنایع مهندسی و ساخت انجام می شود مثل ساختمان سازی، سد سازی، راه سازی، بخش اجرای طرح­های نفت، گاز و پتروشیمی، نیروگاه و غیره معمولاً فعالیت ها مدت زمان ثابتی داشته و پیشرفت آنها به صورت فیزیکی کنترل می­شود. بر همین اساس پیشنهاد می شود نوع مدت زمان Fixed Duration and Unitsو نوع فعالیت Task Dependentانتخاب شود.

در صورتی که تخصیص منابع انجام گرفته و درصد پیشرفت فعالیت ها بر اساس احجام کار شده کنترل می شود نوع درصد پیشرفت Unitsو در صورت عدم تخصیص منابع یا استفاده از منبع به عنوان وزن فعالیت Durationنوع مناسبی می باشد. نوع Physicalزمانی انتخاب گردد که درصد پیشرفت فعالیت را بر اساس Stepو یا مصاحبه با یک خبره مشخص می کنیم.

نکته1: تنها ارتباطی که بین سه نوع درصد پیشرفت تعریف شده است، یک ارتباط یک طرفه از Duration%به Units%می باشد که در صورتی که تنظیم Recalculate Actual Units and Cost when Duration Percent Complete Changesدر تنظیمات مربوط به Projectبخش Calculationفعال باشد اعمال می شود.

نکته 2: پیشنهاد می شود در صورتی که درصد پیشرفت به صورت Durationجمع آوری می گردد و مقدار واقعی احجام به سیستم گزارش نمی شود Optionذکر شده در نکته 1 فعال شود.

زمانبندی Retained logic با Progress Overrideچه تفاوتی دارد؟

در زمان به روز رسانی برنامه در نرم افزار P6 یکی از تنظیمات Schedule روش برخورد با منطق شبکه پیش نیازی می باشد. آیا می خواهید تحت هر شرایطی منطق پیش نیازی نگهداری شود و یا اینکه زمان شروع فعالیت ها پیش نیازی ها در نظر گرفته نشوند.

در زمان به روز رسانی فعالیت ها، ادامه فعالیت بعد از تاریخ Data Date تا زمان تحقق کامل پیش نیازی ها به سمت جلو کشیده می شود. به این تنظیم زمانبندی در حالت Retained Logicمی گویند.

برای مثال در شکل فوق فعالیت صدور MTO پایپینگ طبق منطق برنامه می بایست پس از طراحی نقشه های لوله کشی ظروع شود اما به دلیل شرایط پروژه زودتر شروع شده است. پس از زمانبندی تاریخ شروع ادامه فعالیت (Remaining Start Date) تا زمانی که فعالیت پیش نیاز محقق شود به جلو رانده می شود.

در حالت دیگر (Progress Override) برای فعالیت های شروع شده (Started) منطق پیش نیازی در نظر گرفته نمی شود. شکل زیر مثال این زمانبندی را نمایش می دهد.

 

 

در مثال پس از شروع فعالیت صدور MTO پایپینگ دیگر پیش نیازی ها لحاظ نمی شوند.

انواع مدت زمان (Duration) در P6 چه می باشد و چه تفاوتی با یکدیگر دارند؟

مدت زمان هر فعالیت بسته به نوع آن، شرایط پروژه و نحوه برنامه ریزی به روشهای متفاوتی تخمین زده می شود. بعضی مواقع از کارشناس مربوطه تخمین مدت زمان انجام را می پرسیم و گاهی بر اساس حجم کار یا میزان منابع مورد نیاز و منابع در دسترس تخمین می زنیم. در صورتی که تخصیص منابع نداشته باشید Duration Type چندان اهمیتی ندارد. اما زمان تخصیص منابع این نوع باید آگاهانه انتخاب شود. مدت زمان در P6 چهار نوع به شرح زیر می باشد.

کد

نوع

شرح

مثال

FDBU

Fixed Duration and Units

مدت زمان مشخصی برای انجام فعالیت تعیین شده و همچنین مقدار منابع مورد نیاز نیز مشخص است.

فعالیت یتن ریزی یک فونداسیون، بنای یک دیوار، نصب یک برج 200 تنی در یک پالایشگاه

FDUT

Fixed Duration and Units/time

مدت زمان مشخصی برای انجام فعالیت تعیین شده و همچنین مشخص شده چه مقداری از منابع به صورت روزانه مصرف می شوند یا کار می کنند.

مجموعه جلسات Kick of Meeting، فعالیت کیورینگ پس از بتن ریزی، فعالیت نگهداری و تعمیرات یک ماشین

FU

Fixed Units

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

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

FUT

Fixed Units/time

فعالیت هایی هستند که حجم و مدت زمان آنها مشخص نمی باشد و ممکن است در طول زمان انجام پروژه تغییر کند. تنها اطلاعاتی که از فعالیت داریم منابع و ظرفیت آنها است.

فعالیت های R&D(فعالیت های تحقیقاتی)، فعالیت جلسات در طول زمان پروژه، فعالیت QCدر زمان انجام فعالیت های Piping، فعالیت های مربوط به مدیریت

 

 

نکته 1: نوع های Fixed Duration& Units و Fixed Duration& Units/timeمعمولاً با نوع فعالیت Task Dependent استفاده و دو نوع دیگر با فعالیت های نوع Resource Dependent مورد استفاده قرار می گیرند.

نکته 2: نوع Fixed Units/time را می توان با فعالیت های نوع WBS Summary و Level of Effort نیز استفاده نمود. برای مثال فعالیت QC در طول زمان پروژه انجام می شود اما حجم کار یا مدت زمان آن مشخص نیست. می توان فعالیت QC را از نوع WBS Summary و یا Level of Effort و نوع مدت زمان Fixed Units/time تعریف کرد

نکته 3: همیشه فرمول Remaining Units=Original Duration × Remaining Unit/time صادق بوده و زمانی که یکی از پارامترها تغییر کند پارامترهای دیگر طبق جدول زیر تغییر می کند.

نوع مدت زمان

هنگامی که Units را تغییر دهید چه چیزی تغییر می کند؟

هنگامی که Duration را تغییر دهید چه چیزی تغییر می کند؟

هنگامی که Unit / Time را تغییر دهید چه چیزی تغییر می کند؟

هنگامی که منبعی را اضافه می کنید چه چیزی تغییر می کند؟

Fixed Units/Times

Duration

Units

Duration

Duration

Fixed Duration & Units/Time

Units/Time

Units

Units

Units

Fixed Units

Duration

Units/Time

Duration

Duration

Fixed Duration & Units

Units/Time

Units/Time

Units

Units/Time

 

نواع فعالیت ها در P6 چه می باشد و چه تفاوتی با یکدیگر دارند؟

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

کد

نوع

شرح

مثال

TD

Task Dependent

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

ساخت یک فونداسیون، ساخت یک مخزن ساده، ساخت یک دیوار، تقشه کشی یک ساختمان، احداث خط لوله انتقال آب

RD

Resource Dependent

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

تولید مدرک Logic Diagramدر بخش کنترل و ابزاردقیق، تراش کاری یک قطعه بسیار حساس توسط یک دستگاه تراش گران قیمت، ساخت یک قطعه از جنس تیتانیوم

SM

Start Milestone

یک واقعه آغاز کننده در پروژه می باشد.

شروع پروژه، تحویل زمین، تحویل گرفتن پکیج Basic Designتوسط کارفرما، دریافت پیش پرداخت، دریافت MRدر بخش تدارکات

FM

Finish Milestone

یک واقعه اختتام دهنده در پروژه می باشد.

پایان پروژه، سنکرون یک نیروگاه، تست یک دستگاه ساخته شده، تحویل یک تجهیز در سایت در بخش تدارکات

LOE

Level of Effort (LOE)

فعالیتی است که مدت زمان آن (OD) بر اساس پیش نیازی ها و پس نیازیهایش مشخص می شود. زمان شروع آن برابر است با زودترین تاریخ شروع یا پایان پیش نیازی ها و پایان آن برابر است با دیر ترین تاریخ شروع یا اتمام پس نیازی ها

فعالیت کلان که زمانبندی کلیه فعالیت های Civilرا در بخش های مختلف نمایش می دهد.
فعالیت کلان که با تقویم 7 روزه بر اساس پیش نیازی مایلستون شروع پروژه و پس نیازی مایلستون اتمام مدت زمان انجام پروژه را نمایش می دهد.

WBS

WBS Summary

فعالیتی است که مدت زمان آن برابر با زمان برنامه ریزی شده WBS Nodeمربوطه می باشد.

عموماً فعالیت هایی هستند که در طول پروژه به طول می کشد و زمانبندی مشخصی ندارند، مثل خدمات QC، خدمات مدیریت پروژه، جلسات

 

نکته 1: در صورتی که نوع فعالیت Task Dependent باشد در زمانبندی فقط تقویم فعالیت در نظر گرفته می شود و اگر Resource Dependent باشد فقط تقویم منابع.

نکته 2: برخی مایلستون ها خاتمه دهنده بخشی از فعالیتها و آغاز کننده برخی دیگر می باشند. جهت استاندارد سازی در هر بخشی که قرار گرفت بسته به موقعیت در آن بخش نوع آن (شروع یا اختتام) مشخص می شود. برای مثال فعالیتی مثل ارسال درخواست خرید اگر در WBS بخش مهندسی قرار گیرد مایلستون شروع و در صورتی که در بخش تدارکات به عنوان فعالیت اضافه شود مایلستون اتمام می باشد.

چهار نوع Baseline در Primavera P6 چه تفاوتی با یکدیگر دارند؟

در نرم افزار Primavera P6 به تعداد نامحدود می توانیم Baseline داشته باشیم، اما در زمان استفاده از خط مبنا (Baseline) یکی از آنها را به عنوان خط مبنای اصلی پروژه Project Baseline انتخاب می کنیم. همچنین Primavera به کاربران اجازه می دهد تا سه خط مبنای دیگر به عنوان Users Baseline تخصیص دهند که Primary Baseline تمامی آنالیز ها و واریانسها را محاسبه نموده اما Secondary و Tertiary Baseline تنها در سطح مدت و تاریخ آنالیز های لازم را ارائه می دهند.

پیشنهاد می شوند آخرین برنامه مبنا که مورد تایید تمامی ذینفعان پروژه می باشد را به عنوان Project Baseline و برنامه اولیه را به عنوان User Primary Baseline تخصیص دهید.

همچنین محاسبات Earned Value در پریماورا بر اساس یکی از خطوط مبنای Project Baseline و User Primary Baseline قابل محاسبه می باشد. تنظیم این مورد در Project Detail برگه Settings مطابق با شکل زیر انجام می شود.

 

پیش نیازی موثر (Driving Predecessor) چیست و چه استفاده ای از آن می توانیم ببریم؟

هر فعالیت می تواند پیش نیازی های مختلفی داشته باشد اما در برنامه زمانبندی لزوماً همه پیش نیازی ها موثر نیستند و فعالیت را به جلو نمی رانند. برای مثال نصب یک پمپ دو پیش نیازی رسید تجهیز به سایت و تکمیل فونداسیون دارد. مطمئناً طبق برنامه هر دو این فعالیت ها همزمان تمام نمی شوند. پیش نیازی که دیرتر انجام می شود را پیش نیازی موثر (Driving) می نامیم. در نرم افزار پریماورا در پنجره Activity Details برگه Relationships می توان ستون Driving را در بخش پیش نیازی ها و پس نیازی های اضافه نمود و بر اساس آن پیش نیازی موثر را تشخیص داد.

از این امکان جهت بررسی مسیرها در برنامه استفاده می کنیم. برای مثال فرض کنید پس از زمانبندی برنامه پروژه 1 ماه از تاریخ اتمام برنامه ای تاخیر دارد. برای اصلاح این مشکل از آخرین فعالیت پیش نیازی ها را بررسی نموده و به صورت Backward تاخیرهای مجاز (Lag) و مدت فعالیت ها را اصلاح می کنیم. ستون Driving به شما کمک می کند که بر روی پیش نیازی های موثر حرکت کرده تا روابط و مدت فعالیت ها را اصلاح نمایید. مطمئناً، پیش نیازی موثر دارای شناوری آزاد صفر می باشد.

به روز آوری پیشرفت (Update Progress) در چه مواقعی استفاده می شود؟

زمانی که می خواهیم Data Date را به یک تاریخ دیگر منتقل کرده و بر اساس روش مسیر بحرانی کارهای باقیمانده را زمانبندی کنیم از ابزار Schedule استفاده می نماییم. زمانی که بخواهیم فعالیت ها را طبق برنامه زمانبندی به روز رسانی کنیم از Update Progress استفاده می کنیم. و در زمانی که از Time Sheet استفاده می کنیم و میخواهیم داده های جمع آوری شده و تایید شده بر اساس Time Sheet در برنامه ثبت شوند از Apply Actuals استفاده می کنیم.

نکته 1: در نسخه های جدید نرم افزار در محیط تحت وب ابزار Update Progress حذف شده و Apply Actuals هر دو کار را انجام می دهد.

روش تهیه S-Curve در Primavera P6 چگونه می باشد؟
برای دیدن S-Curve پروژه در پریماورا و یا تهیه گزارش آن در خارج از محیط پریماورا (برای مثال Excel) لازم است هر فعالیت دارای بودجه باشد. نرم افزار Primavera هیچ درصد پیشرفت یا نموداری را بر اساس مدت زمان فعالیت ها ارائه نمی کند.
بدین منظور در صورتی که فعالیت های برنامه تخصیص منابع شده باشند و یا بودجه آنها مشخص باشد به راحتی می توان گزارش S-Curve را تهیه نمود. در غیر اینصورت می بایست فعالیت ها بودجه ریزی شوند. با توجه به اینکه در بسیاری از پروژه ها برای هر سطح WBS و یا فعالیت یک ارزش وزنی در نظر گرفته می شود و معمولاً گزارش های پیشرفت و S-Curve بر اساس آن تهیه می گردد با روش زیر می توانید ارزش های وزنی را برای فعالیت های Primavera تعریف کرده و گزارش های لازم را تهیه نمایید.

1- یک منبع به نام Weight از نوع Labor و یا Non-Labor با نرخ هزینه (Price/Unit) یک در نرم افزار ایجاد کنید.
2- این منبع را به همه فعالیت های پروژه (به غیر از مایلستون ها که تخصیص منابع نمی شوند) تخصیص دهید.
3- در ستون Budgeted Labor Units یا Budgeted Nonlabor Units (بسته به نوع منبع تعریف شده) ارزش های وزنی را به صورت مطلق وارد نمایید. با توجه به اینکه Primavera اعداد را تا دو رقم اعشار گرد می نماید در صورتی که ارزش های ورنی محاسبه شده مقدار هزارم دارند ارزش های وزنی را ابتدا در یک عدد بزرگ مثل 1000، یا 1،000،000 ضرب و سپس در نرم افزار وارد نمایید.
حال می توانید از نماهای Resource Usage Profile و یا Activity Usage Profile در خود نرم افزار S-Curve پروژه را مشاهده نمایید.

 

در صورتی که می خواهید S-Curve را در نرم افزار Excel بکشید از نماهای Resource Usage Spreadsheet و یا Activity Usage Spreadsheet بر روی نام پروژه راست کلیک نموده و کپی را بزنید. سپس اطلاعات کپی شده را در Excel بچسبانید.

 محاسبه تاخیر پروژه

 1. اولین کار اینه که با Tools| Tracking| Set Baseline خط مبنا رو ذخیره کنین (اگه قبلا نکردین)، چون بهتره به جای این‌که تاریخ‌ها رو از هم کم کنیم، مقدار حاضر و آمدش رو از برنامه بگیریم.

2. درصد‌های پیشرفت رو وارد کنین. شکل زیر وضعیت یه برنامه نمونه رو نشون می‌ده. خط عمودی قرمز هم تاریخیه که درصدهای پیشرفتش وارد شده.

 3. حالا Tools| Traking| Update Project رو اجرا کنین. با این کار کادر محاوره شکل زیر باز می‌شه:

 4. گزینه دوم، یعنی Reschedule uncompleted work رو انتخاب کنین و تاریخ ورود مقادیر پیشرفت رو هم تو کادر مقابلش انتخاب کنین. روی OK کلیک کنین.

الان وضعیت جدید پروژه نشون داده می‌شه. تمام فعالیت‌هایی که می‌بایست تموم بشن و هنوز تموم نشدن به بعد از تاریخ مبنا منتقل شدن و پس‌نیازهای اون‌ها هم به همین ترتیب جابجا شدن. الان تاریخ پایان تمام فعالیت‌ها مقدارهای جدیدی رو نشون می‌دن و می‌تونین اختلافشون رو با مقدارهای قبلی حساب کنین تا تاخیر به دست بیاد. راه ساده‌تر اینه که فیلد Finish Variance رو به جدول اضافه کنین و تاخیر رو از اونجا بخونین. این فیلد زمانی می‌تونه کار کنه که خط مبنا ذخیره کرده باشین.

توضیحات:

  • وضعیت جدید برنامه برای خیلی از روش‌های پایش مناسب نیست؛ بهتره فایل رو ذخیره نکین.
  • تاخیر کل پروژه برابر با حداکثر تاخیر فعالیت‌ها یا خلاصه فعالیت‌ها نیست، چون خیلی از اون‌ها می‌تونن شناوری داشته باشن.
  • هرچه روابط برنامه دقیق‌تر وارد شده باشه، تاخیری که به دست میاد واقعی‌تر خواهد بود.
  • مقدارهای تاخیری که به دست میان وضعیت کنونی رو نشون می‌دن و فرض بر اینه که ادامه کار با سرعت برنامه‌ریزی شده انجام می‌شه.
  • محاسبه تاخیر کاملا مستقل از ضرایب وزنیه.
  • مقدار تاخیر تو متدهای پایش معمولی کمتر از صفر نمی‌شه، یعنی اگه کارها جلوتر از برنامه باشن، تاخیر صفر باقی می‌مونه. اگه بخواین مقدار “تعجیل” رو هم حساب کنین، باید از متودهای پایش پیشرفته‌تر استفاده کنید.

وابسته نبودن تاخیر و انحراف پیشرفت

فرض کنین پروژه‌ای صد روزه باشه، پیشرفت برنامه‌ریزی شده صد درصد باشه و 80٪ پیشرفت واقعی کرده باشیم. مقدار تاخیر چقدره؟ خیلی‌ها به این سوال جواب می‌دن که 20 روز. چنین جوابی اصلا درست نیست؛ در واقع هیچ رابطه مستقیم و ساده‌ای بین انحراف پیشرفت و تاخیر وجود نداره.

ممکنه پیشرفت واقعی بیشتر از برنامه‌ریزی باشه، ولی تاخیر داشته باشیم. این اتفاق زمانی می‌افته که فعالیت‌های بحرانی انجام نشده باشن، ولی مقدار زیادی از فعالیت‌های غیر بحرانی انجام شده باشن. معنیش هم اینه که وضعیت پروژه خوب نیست، چون انجام نشدن فعالیت‌های بحرانی باعث می‌شه که جبهه‌های کاری بسته بشه و به تدریج پیشرفت واقعی هم از پیشرفت برنامه‌ریزی شده عقب بیفته.

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

شکل زیر این حالت رو نشون می‌ده:

 

فرض کنین در زمانی که خط عمودی قرمز رنگ نشون می‌ده می‌خوایم وضعیت را تحلیل کنیم. اگه همه فعالیت‌ها طبق برنامه انجام شده باشن، ولی T4 هنوز انجام نشده باشه، وضعیت چطوری خواهد بود؟

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

حالا حالت زیر را در نظر بگیرین:

 

این دفعه هم فرض کنید همه فعالیت‌ها انجام شدن، به جز T5. اگه وزن فعالیت‌های دیگه به اندازه کافی باشه، به خاطر جلو افتادگی عملیات در چهار فعالیت اول، پیشرفت واقعی از برنامه‌ریزی بیشتر خواهد بود، ولی چون T5 که بحرانی بوده و بحرانی هم باقی مونده انجام نشده، پروژه تاخیر خواهد داشت (چهار روز).

 معیار پیشرفت برنامه‌ریزی شده و پیشرفت واقعی

 نکته مهم دیگر اینست که به هیچ وجه قرار نیست معیاری که برای تعیین پیشرفت واقعی به کار میرود همان معیاری باشه که برای پیشرفت برنامه‌ریزی به کار می‌رود.

 به عنوان مثال، برای کارهای طراحی معمولا معیار وزن‌دهی نفر-روزه. بعد از این‌که ضرایب وزنی وارد بشن، یا مقدارهای اولیه ارزش کسب شده که وابسته به هزینه و اون هم وابسته به نفر-روز هست وارد بشه، اجرا شروع می‌شه و باید پیشرفت واقعی رو ثبت کنیم.

 بعضی‌ها اعتقاد دارن که چون معیار اولیه نفر-روز یا هزینه بوده، باید پیشرفت رو هم بر اساس مقدار کاری که روی فعالیت‌ها انجام شده یا هزینه متناظر با اون حساب کرد. این اصلا درست نیست، چون در چنین شرایطی دقیق نبودن برآورد اولیه یا کاهش راندمان کار، پیشرفت واقعی رو کاملا “غیر واقعی” می‌کنند.

مسئله اینه که این روش، می‌شه محاسبه ACWP و مقایسه اون با پیشرفت برنامه‌ریزی شده که به نوعی BCWS هست، فقط شاخص کارکرد رو نشون می‌دهد، نه پیشرفت. چیزی که باید استفاده کنیم، BCWP هست، که واقعا پیشرفت رو نشون می‌ده. به عبارت دیگه اصلا قرار نیست که وقتی معیار پیشرفت نفر-روز هست، برای محاسبه پیشرفت نفر-روز واقعی رو با نفر-روز برنامه‌ریزی شده بسنجیم؛ در این حالت باید نفر-روز معادل با کاری که واقعا انجام شده رو بر مبنای برنامه‌ریزی محاسبه کنیم، و اون رو با برنامه‌ریزی مقایسه کنیم، یعنی همون BCWP.

برای این‌که بتونیم چنین کاری کنیم، باید معیارهایی برای درجات انجام واقعی کار داشته باشیم، که این خودش مشکلات زیادی داره. باز به نظر من بهترین چیز اینه که به جای این‌که از مسئول اون کار بپرسیم که چند درصد کار رو انجام داده، رویدادهایی برای این کار در نظر بگیریم. مثلا وقتی درفت نقشه‌ها برای کارفرما ارسال می‌شه یه درصدی، مثل 20٪ وارد کنیم، وقتی نقشه‌ها برای تایید ارسال می‌شن، 30٪، وقتی همه چیز تایید می‌شه و نقشه برای اجرا ابلاغ می‌شه، 80٪ و زمانی که از-بیلت تهیه می‌شه 100٪ رو وارد کنیم.و برای این کار می توانیم برای چنین فعالیت هایی از قسمت step نرم افزار کمک بگیریم و برای یک فعالیت چندین مرحله را تعریف و برای هر مرحله درصدی را در نضر بگیریم .

 

عناصر مفید گزارش‌های پیشرفت 

تاخیر!
یه عنصر مهم که باید تو گزارش‌ها ارائه کنیم، مقدار تاخیر پروژه و اجزای اصلی اونه. بهتره تاخیر رو بر حسب روز بگیم.
اگه برنامه جبرانی تصویب شده باشه، عملا تاخیرها در زمان تصویب برنامه جبرانی صفر می‌شوند. به همین خاطر بهتره که همیشه مشخص کنیم که تاخیرهای گزارش شده از چه تاریخی به بعد هستن. مثلا بگیم که در مدت 85 روز، 14 روز تاخیر به وجود اومده، و حتی می‌تونیم بگیم که این مقدار معادل چند درصد اون زمانه، ولی اگه این کار رو بکنیم مقدار اطلاعاتِ گزارش زیاد می‌شن و این هم خودش نکته منفی‌ای هست.

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

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

تاخیر: اگر ادامه کار با سرعتی معادلِ سرعت برنامه‌ریزی پیش برود (و نه سرعت کنونی)، پایان پروژه به اندازه‌ای که در کادر تاخیر مشخص شده است دیرتر از تاریخ برنامه‌ریزی شده پایان خواهد یافت.

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

در مورد تاخیر دو نکته مهم هم وجود دارد:
1. تاخیر به هیچ وجه وابسته به ضرایب وزنی نیست.
2. تاخیر به شدت وابسته به روابطِ تعریف شده در برنامه‌ست. اگه روابط مناسب نباشن، مقدار تاخیر به طور کاذب کم یا زیاد می‌شه. هرچی فعالیت‌های برنامه کلی‌تر باشن،‌روابطشون هم تقریبی‌تر می‌شه و تاخیرها دقت کمتری خواهند داشت.

 تاخیرهای موازی پیمانکار و کارفرما

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

وقتی تاخیر تو بازه‌ای خاص هم به دلیلی از طرف کارفرما برگرده و هم به دلیلی از طرف پیمانکار، یکی از این دو روش استفاده می‌شه:

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

روش کمتر رایج: پیمانکار و کارفرما تو تاخیر شریک می‌شوند و بر اساس معیارهای مختلف سهم اون‌ها رو تو تاخیر در نظر می‌گیرن. به این ترتیب قسمتی از حق پیمانکار در مورد اون تاخیر (مثلا نصفش) محفوظ می‌ماند، با این حال می‌تواند به اندازه همون سهم ادعای مالی هم داشته باشه.
منظورم از ادعای مالی هم اینه که پیمانکار بعدا claim کنه که به ازای تاخیر مجازی که ایجاد شده علاوه بر این‌که به زمانش اضافه می‌شه، فلان مقدار هم خسارت خرده و کارفرما باید بهش پرداخت کند که البته نکات قراردادی هم نقش بسزایی در این خصوص دارد که آیا این حق در قرار داد تعریف شده است یا خیر .

کلا هم به ندرت می‌شه که اون زمان رو کلا تاخیر پیمانکار در نظر نگیرند. با توجه به این‌که تو ایران پیمانکارها معمولا تو دعاوی مالی خیلی ضعیف و سهل‌انگار هستند.

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

 ایراد زیاد بودن شناوری چیه؟

 زیاد بودن شناوری به خودی خود هیچ مشکلی ایجاد نمی‌کند. شناوری‌های زیاد از حد دلیل ایجاد مشکل نیستند، ولی نشونه‌ای که به ما می‌گوید احتمالا جای دیگری مشکلی وجود دارد. مثل این است که یه دکتر مثلا نشونه‌ای رو روی ناخن شما ببینه و مشکوک بشه. اون نشونه روی ناخن به خودی خود مشکلی برای شما ایجاد نمی‌کنه (مگر این‌که خیلی حساس به ظاهرتون باشین)، ولی ممکنه جای دیگه‌ای مشکل مهمی داشته باشین و به همین خاطر باید ماجرا رو بررسی کرد.

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

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

 دو سبک در برنامه‌ریزی زمانی

 روش‌های زمان‌بندی را عموما به دو حالت تقسیم می‌کنند

 زمان‌بندی با انتهای آزاد

زمان‌بندی با انتهای مقید

مهم‌ترین نکته اینه که یکی از این دو روش رو انتخاب کنید و کاملا بهش پایبند باشید. اگر اواسط کار هست یکی از این دو راهکار رو در پیش بگیرید، برنامه‌های خیلی نامناسبی به وجود میاد.

 زمان‌بندی با انتهای آزاد

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

 فرجه و قیدهای “دیرتر از … شروع نشود”، “دیرتر از … تمام نشود”، “حتما در … شروع شود” و “حتما در … تمام شود” همه دوست دارند به شکلی مانع حرکت فعالیت به آینده شوند و در نتیجه نباید استفاده بشوند.

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

 تو این حالت مثلا Finish Variance می‌تواند به شما بگوید که فعالیت ها چقدر به تاخیر افتادند.

 زمان‌بندی با انتهای مقید

 تو این حالت باید تمام قیدهای زمانی رو وارد کنید. یه قید “دیرتر از … تمام نشود” برای پروژه داریم و اگه تو قرارداد یا صورت جلسات تاریخ‌های دیگه‌ای هم مشخص شده باشه، باید اون‌ها رو هم به همین شکل وارد کرد. توجه کنین که این تاریخ‌ها معمولا “دیرتر از … تمام نشود” هستن، نه “حتما در … تمام شود”؛ به عبارت دیگه اگه کار رو زودتر از اون تاریخ تموم کنین هیچکس بهتون ایرادی نمی‌گیره.

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

 تو این حالت باید به جای Finish Variance به شناوری کل توجه داشته باشین که هیچی منفی نشه.

 مقایسه روش‌ها

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

 تو حالت اول اگه شناوری منفی داشته باشین یعنی برنامه‌تون ایراد داره و حواستون نبوده، این دو روش رو با هم مخلوط کردید.

 روش های محاسبه تاخیر مجاز

 شیوه محاسبه تاخیر مجاز رو می توان در یکی از این چهار گروه قرار داد:

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

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

کد انتشار ARAJASB-0052

این مورد را ارزیابی کنید
(0 رای‌ها)
  • آخرین ویرایش در یکشنبه, 02 فروردين 1394 ساعت 13:55
  • اندازه قلم

ارسال نظر


کد امنیتی
بارگزاری مجدد

2797038
بازدید امروز
بازدید دیروز
بازدید هفته جاری
بازدید ماه جاری
بازدید کل
219
5874
6093
106293
2797038

آی‌پی شما: 54.158.250.39
امروز: دوشنبه، 05 تیر 1396 - ساعت: 01:04:13

آرشیو

« June 2017 »
Mon Tue Wed Thu Fri Sat Sun
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    

ورود به سایت

درباره ما

HTML 5 وب سایت کافه مدیران در دی ماه سال 1392 توسط گروهی از متخصصین ایرانی...