اولویت‌بندی و تعیین روابط میان فعالیت‌ها

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

در ابتدا ما باید منطق بین فعالیت‌ها را مشخص کنیم و وابستگی بین آن‌ها را تعیین نماییم. به صورت تئوری ما 4 نوع رابطه بین فعالیت‌ها داریم:

• رابطه Finish-To-Start
  یعنی فعالیت پسنیاز نمی‌تواند شروع شود تا زمانی‌که فعالیت پیشنیازش به اتمام رسیده باشد.

• رابطه Start-To-Start
  یعنی فعالیت پسنیاز نمی‌تواند شروع شود تا زمانی‌که فعالیت پیشنیازش شروع نشده باشد.

• رابطه Finish-To-Finish
  یعنی فعالیت پسنیاز نمی‌تواند تمام شود تا زمانی‌که فعالیت پیشنیازش تمام شده باشد.

• رابطه Start-To-Finish
  یعنی فعالیت پسنیاز نباید تمام شود تا زمانی‌که فعالیت پیشنیازش شروع شده باشد.

رابطه اول یعنی FS پرکاربردترین و سر راست‌ترین نوع رابطه در تهیه برنامه زمان‌بندی به شمار می‌آید و Best Practiceهای دنیا مثل DCMA و GAO تاکید دارند که بیش‌تر روابط (بیش از 90%) را از این نوع تعیین کنیم و پیشفرض بسیاری از نرم‌افزارهای زمان‌بندی همین رابطه است. در صورتی‌که فعالیت‌ها به خوبی شکسته شده باشند، می‌توانیم اغلب روابط را به صورت FS تعریف کنیم و در آنالیز تاخیرات هم این نوع رابطه بسیار به ما کمک خواهد کرد.

رابطه FS بدین معنا نیست که فعالیت پسنیاز باید بلافاصله بعد از فعالیت پیشنیازش آغاز شود بلکه بدین معناست که قبل از اتمام فعالیت پیشنیازش نمی‌تواند شروع شود.

رابطه SS نیز به معنای شروع همزمان دو فعالیت نیست بلکه این منطق بیانگر این موضوع است که تا زمانی‌که فعالیت پیشنیاز آغاز نشده باشد، فعالیت پسنیاز نمی‌تواند شروع شود.

استفاده از رابطه SF اصلاً توصیه نمی‌شود چون منطق شبکه زمان‌بندی را دچار مشکل می‌کند و باعث ایجاد پیچیدگی بسیار زیاد در شبکه می‌شود. در زمان استفاده از روابط SS و FF باید بسیار دقت شود تا Dangling Logic (جلوتر در مورد آن صحبت خواهیم کرد) ایجاد نشود.

روابط SS و FF برای موازی سازی فعالیت‌ها به کار می‌روند. ما منعی برای استفاده از این روابط در هیچ‌یک از Best Practiceها نداریم، اما توصیه می‌شود در صورت امکان فعالیت‌ها به اندازه کافی شکسته شوند تا بتوانیم از رابطه FS استفاده کنیم و کمتر از روابط SS و FF استفاده کنیم. البته در فازهای ابتدایی که هنوز نمی‌توان برنامه زمان‌بندی را Detail کرد و در سطح Summary Activityها شبکه زمان‌بندی توسعه داده می‌شود، ممکن است از روابط FF و SS بیشتر استفاده کنیم.

نکته مهم در زمان تعریف روابط بین فعالیت‌ها این است که نباید بین Summary Activityها رابطه برقرار کنیم زیرا زمان شروع و پایان این فعالیت‌ها را فعالیت‌های زیر مجموعه‌‌شان مشخص می‌کند. وجود رابطه بین Summary Activityها، vertical traceability (در گام‌های بعدی در موردش توضیح خواهیم داد) را با مشکل مواجه خواهد کرد.

Dangling Logic

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

در برنامه زمان‌بندی باید عموماً برای شناسایی Dangling Logic روابط از نوع SS و FF را بررسی کنیم زیرا Dangling Logic در این نوع روابط رخ می‌دهد.

اولین نوع Dangling Logic مربوط به شروع فعالیت است. و زمانی اتفاق می‌افتد که فعالیت پیشنیاز و پسنیاز دارد ولی زمان شروع فعالیت مقید نشده است، یعنی هیچ فعالیت پیشنیازی روی شروع این فعالیت تاثیر نمی‌گذارد. در واقع این فعالیت با پیشنیاز خود رابطه FF دارد. برای رفع این مشکل باید فعالیتی را با رابطه FS به عنوان پیشنیاز این فعالیت قرار دهیم یا به مایلستون شروع فاز وصلش کنیم.

دومین نوع Dangling Logic مربوط به پایان فعالیت است. اینجا هم فعالیت پیشنیاز و پسنیاز دارد ولی رابطه آن با پسنیازش SS است و در واقع پایان فعالیت مقید نشده است و انتهای فعالیت باز مانده است. این موضوع هم در محاسبات شناوری و آنالیز تاخیرات ممکن است ما را دچار مشکل کند. برای حل این مشکل باید برای فعالیت، پسنیازی با رابطه FS یا FF تعیین کنیم یا به مایلستون پایان فاز متصلش کنیم.

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

قیدها یا محدودیت‌های زمانی

قیدها یا محدودیت‌های زمانی روی زمان شروع و پایان فعالیت‌ها می‌توانند لحاظ شوند و بسیار زیاد انعطاف‌پذیری برنامه زمان‌بندی را کاهش می‌دهند. از قیدهای زمانی فقط در صورتی که مجبور باشیم (مثلاً الزام کارفرما) باید استفاده کنیم و حتماً باید توجیهی برای استفاده از آن‌ها را در برنامه زمان‌بندی داشته باشیم.

این قیدها عبارتند از:

Start no earlier than (SNET): فعالیتی که این قید روی آن اعمال شده است از تاریخ قید زودتر، نمی‌تواند شروع شود حتی اگر پیشنیازهایش زودتر به اتمام رسیده باشند. در واقع این قید از شروع فعالیت زودتر از تاریخ مشخصی جلوگیری می‌کند.

Finish no earlier than (FNET): فعالیتی که این قید روی آن اعمال شده است از تاریخ قید زودتر، نمی‌تواند تمام شود. در واقع این قید از به اتمام رسیدن فعالیت دیرتر از تاریخ مشخصی جلوگیری می‌کند.

Start no later than (SNLT): فعالیتی که این قید روی آن اعمال شده است حتماً باید قبل از تاریخ قید، آغاز شود. در واقع این قید از شروع شدن فعالیت پس از تاریخ مشخصی جلوگیری می‌کند.

Finish no later than (FNLT): فعالیتی که این قید روی آن اعمال شده است نباید بعد از تاریخ قید به اتمام برسد. در واقع این قید از تمام شدن فعالیت بعد از تاریخ مشخصی جلوگیری می‌کند.

Must start on (MSON): فعالیتی که این قید روی آن اعمال شده است دقیقاً باید در تاریخ قید آغاز شود. در واقع این قید از شروع شدن فعالیت زودتر یا دیرتر از تاریخ مشخصی جلوگیری می‌کند.

Must finish on (MFON): فعالیتی که این قید روی آن اعمال شده است دقیقاً باید در تاریخ قید به پایان برسد. در واقع این قید از به اتمام رسیدن فعالیت زودتر یا دیرتر از تاریخ مشخصی جلوگیری می‌کند.

این قیدها به دو دسته قیدهای نرم (یکطرفه) و سخت (غیر قابل انعطاف) تقسیم می‌شوند. قیدهای Start no earlier than (SNET) و Finish no earlier than (FNET) قیدهای نرم محسوب شده و چهار دسته بعدی قیدهای سخت و انعطاف ناپذیر هستند زیرا در صورت تاخیر فعالیت‌های پیشنیازشان این قیدها تحت تاثیر قرار خواهند گرفت.

با اینکه در قیدهای سخت شروع و پایان زودتر فعالیت امکان‌پذیر است، اما قطعاً برای مدیر پروژه دغدغه تسریع فعالیت‌ها به اندازه به تاخیر افتادن آن‌ها نیست. سرسخت‌ترین قیدها Must start on (MSON) و Must finish on (MFON) هستند زیرا کاملاً امکان جایجایی را از فعالیت می‌گیرند.

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

Lag

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

• به جای فعالیت‌ها نباید از Lag استفاده کنیم.
• حتماً دلیل استفاده از Lag باید مشخص باشد و این دلیل باید ذکر شود.
• در زمانی که از Lag برای نمایش انتظار استفاده می‌کنیم باید حتماً به این نکته توجه کنیم که آیا می‌توان به جای این Lag از فعالیت استفاده کرد، برای مثال دوره Curing بتن را بسیاری از افراد به صورت Lag در نظر می‌گیرند در حالی‌که Curing بتن را می‌توان به عنوان یک فعالیت مجزا لحاظ کرد.
• به Lag نمی‌توانیم منبع و هزینه تخصیص دهیم.
• فعالیت‌های فاز تدارکات را نباید به صورت Lag لحاظ کنیم زیرا در این صورت مانیتور این فعالیت‌ها سخت خواهد شد و نمی‌توانیم پیشرفت فعالیت را کنترل کنیم.
• به هیچ وجه نباید از Lag به عنوان بافر یا ذخیره احتیاطی برای فعالیت‌ها استفاده کرد زیرا محاسبات مسیر بحرانی را ممکن است تغییر دهد.
• بهترین حالت استفاده از Lag بین فازها یا تحویل بین پیمانکاران است.

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

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

Lead

تسریعی است که در شروع فعالیت پسنیاز ایجاد می‌کنیم. در وافع Lead همان Lag منفی است. ما از Lead برای همپوشانی فعالیت‌ها یا Overlapping استفاده می‌کنیم.

اغلب اوقات استفاده از Lead غیر ضروری است و می‌توانیم با شکست بیشتر فعالیت‌ها به جزئیات بیشتر لزوم استفاده از Lead را از بین ببریم.

استفاده از Lead ما را در پیش‌بینی زمان شروع فعالیت پسنیاز دچار مشکل حواهد کرد. فرض کنید دو فعالیت A و B با هم رابطه FS با Lead یک روزه دارند. این به این معناست که یک روز قبل از اتمام فعالیت A، میتوانیم فعالیت B را شروع کنیم.

اگر اتمام فعالیت A تاریخ 5 اردیبهشت باشد ما باید فعالیت B را 4 اردیبهشت شروع کنیم (1 روز قبل از اتمام فعالیت A). طبق برنامه 4 اردیبهشت فعالیت B آغاز می‌شود ولی به دلیل رخ دادن مشکلی، فعالیت A در روز 5 اردیبهشت انجام نمی‌شود و به تاخیر می‌افتد و در روز 10 اردیبهشت به اتمام می‌رسد.

بنابراین طبق منطقی که تعیین کرده بودیم باید با توجه به تاخیر پیش آمده فعالیت B در روز 9 اردیبهشت آغاز می‌شد ولی با توجه به استفاده از Lead در همان روز 4 اردیبهشت آغازش کردیم و این نشان می‌دهد که استفاده از Lead باعث می‌شود پیش‌بینی تاریخ شروع فعالیت پسنیاز به درستی صورت نگیرد.

توصیه GAO برای حل این مشکل Lead استفاده از رابطه SS به جای Lead و یا شکستن فعالیت و استفاده از رابطه FS است.

استفاده بیش از حد از Lag و Lead باعث می‌شود برنامه زمان‌بندی از حالت داینامیک خارج شده و در زمان Update برنامه زمان‌بندی مجبور باشیم بسیاری از روابط را به صورت دستی اصلاح کنیم.