راهنماى جامع و كاربردى آناليز تأخيرات در پروژه هاى صنعت ساخت؛ از انتخاب روش تا تهيه لايحه قابل دفاع

پادکست مقاله

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

راهنماى جامع و كاربردى آناليز تأخيرات در پروژه هاى صنعت ساخت؛ از انتخاب روش تا تهيه لايحه قابل دفاع
با مهندس محمدامین غفاری
مدت زمان: حدود 45 دقیقه

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

به همین دلیل، نتیجه قابل دفاع از جمع ساده روزهای مکاتبات، دستورکارها، تأخیر پرداخت‌ها یا توقف‌ها به دست نمی‌آید. ممکن است یک رویداد ۳۰ روز ادامه داشته باشد، اما فقط ۸ روز بر مسیر بحرانی اثر بگذارد. برعکس، رویدادی کوتاه می‌تواند توالی اجرا را تغییر دهد و اثری طولانی‌تر بر تکمیل پروژه ایجاد کند. تأخیرهای پیمانکار، کارفرما، عوامل بیرونی، تغییر مسیر بحرانی، اقدامات جبرانی و تأخیرهای همزمان نیز می‌توانند نتیجه اولیه را تغییر دهند.

دو مرجع مهم در این حوزه، «پروتکل تأخیر و اختلال انجمن حقوق ساخت» (SCL) و «رویه پیشنهادی شماره 29R-03 انجمن AACE برای تحلیل تخصصی و مستند برنامه زمان‌بندی در ادعاها و اختلاف‌ها» هستند. SCL و AACE هیچ‌کدام قانون یا شرط قراردادی خودکار نیستند و یک روش واحد را برای همه پروژه‌ها تجویز نمی‌کنند. قرارداد، قانون حاکم، هدف تحلیل، زمان انجام تحلیل و کیفیت داده‌ها همواره مقدم‌اند.

در این مقاله ابتدا مبانی مشترک توضیح داده می‌شود؛ سپس شش روش SCL و نه پروتکل پیاده‌سازی AACE 29R-03 بررسی و با یکدیگر مقایسه می‌شوند. در ادامه، رویکردهای رایج و اسناد قراردادی داخل ایران، معیارهای انتخاب روش، نحوه کار در Primavera P6 و Microsoft Project و خطاهای متداول در تهیه و رسیدگی به لایحه تأخیرات تحلیل خواهد شد.

پیشنهاد می‌گردد جهت تسلط بر انواع تأخیرات، طبقه‌بندی جامع و آثار قراردادی آن‌ها در پروژه‌های صنعت ساخت، مقاله تهیه شده در این خصوص را مطالعه بفرمایید:

انواع تأخیرات در پروژه‌های صنعت ساخت؛ راهنمای جامع طبقه‌بندی و آثار قراردادی

آنالیز تأخیرات چیست و چه چیزی را باید اثبات کند؟

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

یک تحلیل کامل معمولاً باید به پنج سؤال پاسخ دهد:

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

زنجیره اثبات در یک ادعای تأخیر

حلقه	سؤال اصلی	نمونه مدرک یا تحلیل
مبنای قراردادی	آیا رویداد از نظر قرارداد قابلیت ایجاد حق زمانی دارد؟	شرایط عمومی و خصوصی، دستور تغییر، اخطار و مکاتبات
وقوع رویداد	چه اتفاقی، در چه زمانی و در چه محدوده‌ای رخ داده است؟	گزارش روزانه، صورت‌جلسه، نامه، گردش مدرک و عکس پیشرفت
اثر بر فعالیت	کدام فعالیت و کدام بخش کار تحت تأثیر قرار گرفته است؟	تطبیق WBS، فعالیت برنامه، نقشه و جبهه کاری
اثر بر مسیر بحرانی	آیا فعالیت در زمان اثر، بحرانی یا نزدیک به بحرانی بوده است؟	برنامه مبنا، برنامه به‌روزشده معتبر، تحلیل شناوری و طولانی‌ترین مسیر
اثر بر تکمیل	تاریخ تکمیل یا نقطه عطف چند روز جابه‌جا شده است؟	محاسبه قبل و بعد، تحلیل پنجره‌ای یا مدل چون‌ساخت
همزمانی و کاهش اثر	آیا تأخیر دیگری همزمان یا اقدام جبرانی مؤثر وجود داشته است؟	تحلیل همزمانی، برنامه بازیابی، منابع و پیشرفت واقعی
نتیجه قراردادی	چه مقدار تمدید مدت یا جبران مالی قابل مطالبه یا پذیرش است؟	ماتریس مسئولیت، مفاد قرارداد و اسناد هزینه

تفاوت‌های بنیادی پیش از انتخاب روش

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

تحلیل آینده‌نگر و گذشته‌نگر

تحلیل آینده‌نگر (Prospective) پیش از وقوع کامل اثر یا همزمان با رویداد انجام می‌شود و می‌پرسد: «با اطلاعاتی که در این تاریخ در اختیار داشتیم، انتظار می‌رفت این رویداد چه اثری بر تکمیل پروژه بگذارد؟» نتیجه آن پیش‌بینی است. SCL برای رسیدگی همزمان با اجرای پروژه، به‌طور معمول استفاده از روش Time Impact Analysis را پیشنهاد می‌کند و رویکرد «صبر کنیم تا پایان پروژه» را مناسب نمی‌داند. (در ادامه به طور مفصل در خصوص انواع روش‌ها توضیحات ارائه خواهد شد.)

تحلیل گذشته‌نگر (Retrospective) پس از وقوع اثر، یا پس از تکمیل پروژه، انجام می‌شود و به داده‌های واقعی دسترسی دارد. این تحلیل می‌تواند اثر واقعی، تغییر مسیر بحرانی، بازیابی، توالی اجرا و تأخیرهای همزمان را بررسی کند.

یک نکته اصطلاح‌شناختی مهم وجود دارد: استفاده از محاسبه رو‌به‌جلو لزوماً تحلیل را «آینده‌نگر» نمی‌کند. اگر تحلیلگر پس از پایان پروژه، زیرشبکه یا اصطلاحا Fragnet یک رویداد تأخیر را در یکی از برنامه‌های به‌روزشده پیشین وارد کند، زمان انجام تحلیل گذشته‌نگر است؛ هرچند محاسبه اثر از تاریخ داده به آینده انجام می‌شود. AACE این تفاوت میان «زمان انجام تحلیل» و «جهت محاسبه» را صریح نگه می‌دارد.

رویکردهای علت و معلولی

در روش‌های علت و معلول (Cause & Effect) تحلیل از رویداد تأخیر آغاز می‌شود و سپس پیامد زمانی آن بر برنامه محاسبه می‌گردد. روش «اثرگذاری رویدادها بر برنامه مبنا یا آینده‌نگر ساده» (Impacted As-Planned)، روش «تحلیل اثر زمانی یا آینده‌نگر پیشرفته» (Time Impact Analysis) و روش «حذف رویدادها از برنامه چون‌ساخت یا گذشته‌نگر نیمه‌ساده» (Collapsed As-Built) در طبقه‌بندی SCL در این گروه قرار می‌گیرند. در روش آخر، رویدادِ مورد بررسی از مدل چون‌ساخت حذف می‌شود تا وضعیت فرضی پروژه در نبود آن رویداد محاسبه شود.

در روش‌های معلول و علت (Effect & Cause) تحلیل از تأخیر بحرانیِ مشاهده‌شده آغاز می‌شود و سپس اسناد بررسی می‌شوند تا علت یا علل مؤثر آن دوره مشخص شوند. روش «تحلیل پنجره‌های زمانی یا گذشته‌نگر پیشرفته» (Time Slice Windows)، روش «مقایسه پنجره‌ای برنامه مبنا با برنامه چون‌ساخت یا گذشته‌نگر ساده» (As-Planned versus As-Built Windows) و روش «بررسی گذشته‌نگر طولانی‌ترین مسیر» (Retrospective Longest Path) در این گروه قرار دارند.

SCL برای تحلیل‌هایی که با فاصله زمانی زیاد از رویداد انجام می‌شوند، روش‌های معلول و علت را عموماً برای بررسی مستند ادعاها و اختلاف‌ها قابل اتکاتر می‌داند؛ زیرا تحلیل از تأخیر واقعاً رخ‌داده آغاز می‌شود و همه علل محتمل را جست‌وجو می‌کند. این ترجیح یک حکم مطلق نیست و به داده‌ها و قرارداد بستگی دارد.

مشاهده‌ای و مدل‌سازی‌شده

در روش مشاهده‌ای (Observational)، تحلیلگر رفتار برنامه‌ها، تفاوت تاریخ‌ها، تغییر مسیر بحرانی و پیشرفت را بررسی می‌کند و برای ساخت یک سناریوی خاص، رویدادی را به شبکه اضافه یا از آن حذف نمی‌کند. اصلاح خطاهای آشکار و مستند ممکن است لازم باشد، اما روش بر مشاهده داده‌های موجود استوار است.

در روش مدل‌سازی‌شده (Modeled)، تحلیلگر یک سناریو می‌سازد: رویدادها را به یک برنامه اضافه می‌کند یا از مدل چون‌ساخت حذف می‌کند و نتیجه قبل و بعد را مقایسه می‌کند. شفافیت فرضیات، کیفیت مدل و ترتیب ورود یا حذف رویدادها در این روش‌ها اهمیت زیادی دارد.

منطق ایستا و منطق پویا

روش‌های منطق ایستا (Static Logic) عمدتاً بر یک مجموعه روابط، منطق برنامه مبنا یا یک مدل چون‌ساخت، تکیه دارند. روش‌های منطق پویا (Dynamic Logic) تغییرات روابط، توالی، راهبرد اجرا و مسیر بحرانی را در دوره‌های مختلف لحاظ می‌کنند.

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

تمدید مدت و جبران مالی

اثبات استحقاق تمدید مدت به معنی اثبات خودکار هزینه تطویل نیست. SCL در اصل بنیادین ۱۲ این دو را از یکدیگر جدا می‌کند. ممکن است رویدادی از نظر زمانی مجاز باشد، اما هزینه آن بر عهده پیمانکار بماند؛ یا دوره جبران مالی با تعداد روزهای تمدیدشده یکسان نباشد. تحلیل زمان، استحقاق قراردادی و کمی‌سازی هزینه سه لایه مرتبط اما مستقل‌اند.

پیش‌شرط‌های فنی و قراردادی آنالیز تأخیرات

انتخاب نام یک روش پیش از کنترل داده‌ها، ترتیب کار را معکوس می‌کند. AACE تأکید می‌کند که حتی اجرای دقیق یک روش، با ورودی معیوب می‌تواند شکست بخورد. SCL نیز برنامه و سوابق را نخستین اصل بنیادین خود قرار داده است.

۱. بررسی قرارداد و تاریخ‌های حاکم

پیش از تحلیل باید مشخص شود:

– تاریخ شروع، مدت اولیه و تاریخ تکمیل قراردادی چیست؛

– چه تمدیدهایی قبلاً ابلاغ یا توافق شده‌اند؛

– نقاط عطف و تاریخ‌های بخشی کدام‌اند؛

– کدام رویدادها طبق قرارداد می‌توانند مبنای تمدید مدت باشند؛

– اخطار، ارائه جزئیات و مهلت رسیدگی چه تشریفاتی دارد؛

– قرارداد درباره شناوری، همزمانی، تسریع، برنامه به‌روزشده و روش تحلیل چه می‌گوید؛

– شرایط خصوصی یا الحاقیه‌ها چه تغییری در شرایط عمومی داده‌اند.

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

۲. انتخاب و اعتبارسنجی برنامه مبنا

برنامه مبنا باید تا حد لازم برای تحلیل، کامل، منطق‌دار و قابل محاسبه باشد. کنترل‌های اصلی عبارت‌اند از:

– پوشش کامل محدوده قرارداد و نقاط عطف؛

– وجود مسیر پیوسته از شروع تا تکمیل؛

– نداشتن فعالیت معلق بدون پیش‌نیاز یا پس‌نیاز، جز نقاط شروع و پایان؛

– تقویم‌های کاری درست؛

– مدت‌های معقول و قابل دستیابی؛

– محدودیت‌های تاریخی مستند و غیرتحمیلی؛

– ثبت تنظیمات نرم‌افزار؛

– انطباق تاریخ داده با وضعیت واقعی برنامه مبنا؛

– روشن‌بودن منبع نسخه انتخاب‌شده و تفاوت آن با نسخه‌های دیگر.

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

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

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

به همین دلیل مجموعه مدیر ادعا یک راهنمای اجرایی برای همین مسئله تدوین کرده است. برای دریافت آن اینجا کلیک کنید.

۳. کنترل برنامه‌های به‌روزرسانی‌شده

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

– تاریخ داده و دوره گزارش‌گیری؛

– تاریخ‌های واقعی شروع و پایان؛

– درصد پیشرفت و مدت باقی‌مانده؛

– فعالیت‌های جدید، حذف‌شده یا تقسیم‌شده؛

– تغییر منطق، فاصله زمانی روابط، تقویم و قیود؛

– تغییرات غیرمرتبط با پیشرفت مانند بازتوالی و برنامه بازیابی؛

– روش برخورد نرم‌افزار با فعالیت‌های خارج از توالی؛

– انطباق با گزارش‌های روزانه، صورت‌جلسات و اسناد پیشرفت.

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

۴. ساخت و اعتبارسنجی برنامه چون‌ساخت

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

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

۵. رجیستر رویدادهای تأخیر

برای هر رویداد حداقل این اطلاعات لازم است:

– شناسه یکتا و شرح بی‌طرفانه؛

– مبنای قراردادی و طرف مسئول مورد ادعا؛

– تاریخ اطلاع، شروع علت، شروع اثر، پایان علت و پایان اثر؛

– فعالیت‌ها و جبهه‌های کاری متأثر؛

– مدارک اثبات وقوع و اثر؛

– اقدامات کاهش اثر، بازیابی یا تسریع؛

– ارتباط با رویدادهای دیگر؛

– وضعیت تأیید یا اختلاف طرفین.

تفکیک «دوره وقوع علت» از «دوره ظهور اثر» ضروری است. تأخیر در تأیید یک نقشه ممکن است چند هفته طول بکشد، اما اثر آن بر فعالیت اجرایی در تاریخی دیگر ظاهر شود.

۶. تعیین معیار بحرانی‌بودن و همزمانی

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

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

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

تأخیر همگام (Pacing Delay) زمانی مطرح می‌شود که یک طرف، با آگاهی از تأخیر موجود طرف دیگر، سرعت فعالیت خود را متناسب می‌کند؛ زیرا اجرای سریع‌تر در آن مقطع تاریخ تکمیل را جلو نمی‌اندازد. تأخیر همگام را نباید صرفاً از افت پیشرفت نتیجه گرفت. وجود تأخیر غالب، امکان واقعی اجرای سریع‌تر، تصمیم یا رفتار آگاهانه و نبود علت مستقل باید با برنامه و سوابق اثبات شوند.

شش روش اصلی آنالیز تأخیر در پروتکل SCL

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

۱. روش اثرگذاری رویدادها بر برنامه مبنا یا آینده‌نگر ساده (Impacted As-Planned)

ماهیت روش: علت و معلول؛ تعیین مسیر بحرانی و پیامد زمانی رویداد هر دو به‌صورت آینده‌نگر.

در این روش، زیرشبکه‌ای کوچک از فعالیت‌ها که رویداد تأخیر را نشان می‌دهد که «فرگنت» (Fragnet) نامیده می‌شود، به برنامه مبنای منطق‌دار افزوده می‌شود. سپس برنامه دوباره محاسبه و تاریخ تکمیل قبل و بعد مقایسه می‌گردد. اختلاف تاریخ، پیامد نظری رویداد بر برنامه اولیه را نشان می‌دهد.

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

مراحل اجرای متعارف:

اعتبارسنجی برنامه مبنا و تعیین تاریخ تکمیل جاری؛
تعریف فعالیت‌ها، مدت‌ها و روابط زیرشبکه بر اساس دامنه واقعی رویداد؛
اتصال زیرشبکه رویداد به فعالیت‌های صحیح، بدون استفاده بی‌دلیل از قیود ثابت؛
ورود رویدادها، ترجیحاً به ترتیب زمانی؛
محاسبه مجدد و ثبت تغییر مسیر بحرانی و تاریخ تکمیل؛
کنترل نتیجه با منطق اجرایی و قرارداد.

مزایا: ساده، نسبتاً سریع، قابل فهم برای مخاطب غیرمتخصص و مناسب برای رویدادهای ابتدای پروژه یا زمانی که پیشرفت واقعی اندک است.

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

موقعیت مناسب: وقوع رویداد در ابتدای پروژه، نبود داده چون‌ساخت، پروژه ساده یا الزام صریح قرارداد؛ مشروط بر بیان روشن محدودیت‌ها.

نزدیک‌ترین طبقه در AACE: معمولاً MIP3.6؛ یعنی مدل‌سازی افزایشی با مبنای واحد.

۲. روش تحلیل اثر زمانی یا آینده‌نگر پیشرفته (Time Impact Analysis یا TIA)

ماهیت روش در SCL: علت و معلول؛ مسیر بحرانی به‌صورت همزمان با رویداد و پیامد زمانی آن به‌صورت آینده‌نگر تعیین می‌شود.

تفاوت اصلی روش تحلیل اثر زمانی (TIA) با روش اثرگذاری رویدادها بر برنامه مبنا (IAP)، در برنامه‌ای است که زیرشبکه رویداد به آن وارد می‌شود. در TIA، برنامه مبنا یا برنامه به‌روزشده باید تا مقطع بلافاصله پیش از رویداد با پیشرفت و تأخیرهای رخ‌داده به‌روز شود. سپس زیرشبکه رویداد به همان وضعیت زمانی افزوده می‌شود و پیامد آن بر تاریخ تکمیل پیش‌بینی‌شده محاسبه می‌گردد.

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

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

مزایا: رویداد را در شرایطی نزدیک به زمان وقوع بررسی می‌کند، پیشرفت قبلی و مسیر بحرانی همان مقطع را بهتر از Impacted As-Planned لحاظ می‌کند و برای تصمیم‌گیری درباره تمدید مدت در جریان پروژه مفید است.

محدودیت‌ها: نتیجه معمولاً پیامد پیش‌بینی‌شده است و لزوماً با پیامد نهایی یکسان نیست. هرچه فاصله تاریخ داده تا رویداد بیشتر باشد، احتمال خطا افزایش می‌یابد. کیفیت برنامه به‌روزشده، مدت و منطق زیرشبکه رویداد، ترتیب ورود رویدادها و وجود تسریع یا بازتوالی در مدل می‌توانند نتیجه را تغییر دهند. حداقل اجرایMIP3.7 در AACE به‌تنهایی برای تعیین تأخیر قابل‌جبران کافی نیست؛ همزمانی، تأخیر همگام و مسئولیت باید جداگانه تحلیل شوند.

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

ارتباط با AACE: در کاربرد چنددوره‌ای معمولاً به MIP3.7 نزدیک است. با این حال، AACE نشان می‌دهد نام عمومی TIA برای پیاده‌سازی‌های متفاوت، از جمله MIP3.6 و 3.7، به‌کار رفته است؛ بنابراین صرف نام TIA روش واقعی اجرا را ثابت نمی‌کند.

۳. روش تحلیل پنجره‌های زمانی یا گذشته‌نگر پیشرفته (Time Slice Windows Analysis)

ماهیت روش: معلول و علت؛ مسیر بحرانی به‌صورت همزمان با هر دوره و پیامد تأخیر به‌صورت گذشته‌نگر تعیین می‌شود.

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

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

مراحل اجرای متعارف:

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

مزایا: تغییر مسیر بحرانی، توالی زمانی رویدادها، تأخیر و بازیابی دوره‌ای و شرایط واقعی‌تر پروژه را نشان می‌دهد. برای پروژه‌های طولانی و پیچیده، در صورت وجود برنامه‌های به‌روزشده معتبر، معمولاً از روش‌های ایستا گویاتر است.

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

ارتباط با AACE: اگر برنامه‌های به‌روزشده تقریباً بدون تغییر تحلیل شوند، روش بهMIP3.3 نزدیک است. اگر برای جداسازی پیشرفت از تغییرات منطق، یک فایل میانی ساخته شود، به MIP3.4 نزدیک می‌شود. اگر برنامه‌های به‌روزشده به‌طور گسترده اصلاح یا بازسازی شوند، بخش مربوط می‌تواند به MIP3.5 نزدیک شود.

۴. روش مقایسه پنجره‌ای برنامه مبنا با برنامه چون‌ساخت یا گذشته‌نگر ساده (As-Planned versus As-Built Windows Analysis)

ماهیت روش: معلول و علت؛ مسیر بحرانی هر پنجره به‌صورت همزمان یا واقعی و پیامد تأخیر به‌صورت گذشته‌نگر بررسی می‌شود.

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

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

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

محدودیت‌ها: چون تعیین بحرانی‌بودن می‌تواند کمتر متکی به محاسبه مستقیم CPM باشد، تحلیلگر باید منطق، شواهد و استدلال خود را شفاف ارائه کند. انتخاب پنجره و فعالیت‌های مقایسه‌شده می‌تواند نتیجه را تحت تأثیر قرار دهد.

ارتباط با AACE: نزدیک‌ترین عنوان، MIP3.2 یعنی As-Planned versus As-Built دوره‌ای است؛ اما معادل‌سازی کامل صحیح نیست. MIP3.2 در AACE عمدتاً منطق اولیه را ایستا نگه می‌دارد، در حالی که روش SCL می‌تواند مسیر بحرانی واقعی هر پنجره را با شواهد همزمان تعیین کند. بسته به نحوه اجرا، ممکن است عناصری از MIP3.3 یا 3.5 نیز وجود داشته باشد.

۵. روش بررسی گذشته‌نگر طولانی‌ترین مسیر (Retrospective Longest Path Analysis)

ماهیت روش: معلول و علت؛ مسیر بحرانی و پیامد تأخیر هر دو از دیدگاه گذشته‌نگر تعیین می‌شوند.

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

داده‌های اصلی: برنامه مبنا و برنامه چون‌ساخت تفصیلی.

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

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

ارتباط با AACE:AACE یک MIP مستقل با همین نام ندارد. نزدیک‌ترین حالت، اجرای پیشرفتهMIP3.1 همراه با تعیین مسیر بحرانی چون‌ساخت و رویه‌های شناسایی As-Built Critical Path است. این ارتباط تقریبی است، نه تطابق یک‌به‌یک.

۶. روش حذف رویدادها از برنامه چون‌ساخت یا گذشته‌نگر نیمه‌ساده (Collapsed As-Built یا But-For)

ماهیت روش: علت و معلول؛ تحلیل گذشته‌نگر با مدل‌سازی کاهشی.

در این روش، یک برنامه چون‌ساخت منطق‌دار ساخته می‌شود که بتواند تاریخ‌های واقعی را با منطق و مدت‌های واقعی بازتولید کند. سپس رویدادهای منتخب، بخش‌های تأخیری مدت فعالیت‌ها یا فاصله‌های زمانیِ منتسب به آن رویدادها از مدل حذف می‌شوند. تاریخ تکمیل جدید نشان می‌دهد پروژه، با فرض نبود آن رویدادها، چه زمانی می‌توانست تمام شود. اختلاف تاریخ تکمیل واقعی با تاریخ تکمیل فرضی در نبود رویدادهای منتخب (But-For)، پیامد خالص رویدادهای حذف‌شده در مدل است.

داده‌های اصلی: برنامه چون‌ساخت تفصیلی، منطق چون‌ساخت معتبر، اطلاعات رویدادهای منتخب و اسناد لازم برای مسئولیت و مدت.

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

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

ارتباط با AACE: مدل واحد به MIP3.8 و مدل چنددوره‌ای یا پنجره‌ای به MIP3.9 مربوط است.

روش‌های دیگری که SCL نام می‌برد

SCL علاوه بر شش روش اصلی، استفاده از روش‌هایی مانند مقایسه کلی As-Planned و As-Built، Time Chainage، Line of Balance، تحلیل منحنی منابع و Earned Value را در شرایط خاص ممکن می‌داند. این ابزارها به‌ویژه در پروژه‌های خطی، تولید تکراری یا تحلیل منابع مفیدند؛ اما انتخاب آن‌ها باید با ماهیت پروژه و هدف تحلیل سازگار باشد.

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

نه روش پیاده‌سازی درAACE 29R-03

AACE29R-03 به‌جای ارائه فهرستی بر پایه نام‌های رایج، یک طبقه‌بندی فنی می‌سازد. دلیل این کار آن است که نام‌هایی مانند TIA، Windows Analysis یا But-For در بازار با معانی متفاوت استفاده می‌شوند. AACE روش‌ها را بر اساس زمان تحلیل، مشاهده‌ای یا مدل‌سازی‌شده‌بودن، منطق ایستا یا پویا، افزودن یا حذف رویداد و استفاده از یک یا چند مبنا طبقه‌بندی می‌کند.

ساختار طبقه‌بندی AACE

– مشاهده‌ای / منطق ایستا: مقایسه برنامه و واقعیت با یک منطق اصلی؛ MIP3.1 و 3.2.

– مشاهده‌ای / منطق پویا: مشاهده رفتار برنامه‌های به‌روزشده و تغییر منطق دوره‌ای؛ MIP3.3 تا 3.5.

– مدل‌سازی افزایشی: افزودن رویداد به یک یا چند برنامه؛ MIP3.6 و 3.7.

– مدل‌سازی کاهشی: حذف رویداد از یک یا چند مدل چون‌ساخت؛ MIP3.8 و 3.9.

جدول نه MIP در AACE29R-03

MIP	عنوان فنی	نام رایج نزدیک	داده محوری	نکته اصلی	محدودیت شاخص
3.1	Observational / Static / Gross	As-Planned vs As-Built	یک برنامه مبنا و چون‌ساخت	مقایسه کل پروژه در یک دوره	تغییر مسیر بحرانی را به‌طور طبیعی نشان نمی‌دهد
3.2	Observational / Static / Periodic	Periodic APAB / Windows	مبنا و چون‌ساخت تقسیم‌شده	مقایسه در چند دوره با منطق اولیه	تقسیم‌بندی، روش را لزوماً پویا یا دقیق‌تر نمی‌کند
3.3	Observational / Dynamic / Contemporaneous As-Is	Contemporaneous Period Analysis	برنامه‌های به‌روزشده هم‌زمان با اجرا	مشاهده افت یا بازیابی میان برنامه‌های به‌روزشده	تفکیک اثر پیشرفت از تغییرات منطق دشوار است
3.4	Observational / Dynamic / Contemporaneous Split	Half-Step / Bifurcated Analysis	برنامه‌های به‌روزشده معتبر و فایل میانی	جداسازی پیشرفت خالص از اصلاحات غیرپیشرفتی	پیچیده‌تر و حساس به اعتبار برنامه‌های به‌روزشده
3.5	Observational / Dynamic / Modified or Recreated	Reconstructed Update Analysis	برنامه‌های به‌روزشده اصلاح‌شده یا بازسازی‌شده	پرکردن شکاف داده و بازسازی منطق پویا	مداخله تحلیلگر و احتمال چالش بیشتر است
3.6	Modeled / Additive / Single Base	Impacted As-Planned / TIA	یک برنامه و زیرشبکه‌های رویدادها	افزودن رویداد به یک مبنا	فرضی، حساس به ترتیب ورود و دوری از تاریخ داده
3.7	Modeled / Additive / Multiple Base	TIA / Impacted Update / Windows	چند برنامه به‌روزشده و زیرشبکه‌های رویداد	ورود رویداد به مبناهای دوره‌ای	زمان‌بر و در حداقل اجرا برای همزمانی کافی نیست
3.8	Modeled / Subtractive / Single Simulation	Collapsed As-Built / But-For	یک مدل چون‌ساخت	حذف رویداد از کل مدل	بازسازی منطق چون‌ساخت قضاوت‌محور است
3.9	Modeled / Subtractive / Multiple Base	Windows Collapsed As-Built	چند مدل چون‌ساخت دوره‌ای	حذف رویداد در پنجره‌ها	پیچیده، پرهزینه و حساس به مدل هر پنجره

MIP 3.1 و 3.2؛ مشاهده‌ی ایستای برنامه و واقعیت

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

MIP 3.2 همان مقایسه را به چند دوره تقسیم می‌کند. این تقسیم‌بندی، سازمان‌دهی و ارائه را بهتر می‌کند و زمان وقوع انحراف را محدودتر نشان می‌دهد؛ اما چون همچنان عمدتاً بر منطق اولیه تکیه دارد، نباید صرف داشتن «پنجره» آن را معادل تحلیل پویای تغییرات میان برنامه‌های به‌روزشده پیاپی دانست.

MIP 3.3 تا 3.5؛ مشاهده منطق پویای برنامه‌های به‌روزشده

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

MIP 3.4 برای حل این مسئله یک «فایل میانی» می‌سازد. ابتدا فقط پیشرفت برنامه به‌روزشده جدید به فایل قبلی اعمال می‌شود؛ اختلاف فایل قبلی و فایل میانی، اثر پیشرفت را نشان می‌دهد. سپس اختلاف فایل میانی و برنامه به‌روزشده جدید، اثر تغییرات غیرپیشرفتی را آشکار می‌کند. این تفکیک برای شناسایی بازتوالی، کاهش مدت، برنامه بازیابی و تغییر منطق مفید است.

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

MIP 3.6 و 3.7؛ مدل‌سازی افزایشی

در MIP 3.6 رویدادها به یک مبنای واحد، مانند برنامه مبنا یا یک برنامه به‌روزشده، افزوده می‌شوند. این همان خانواده‌ای است که روش اثرگذاری رویدادها بر برنامه مبنا (IAP) و برخی کاربردهای موسوم به TIA در آن دیده می‌شوند. روش ساده‌تر و سریع‌تر است، اما تغییر شرایط پروژه پس از تاریخ داده را کمتر پوشش می‌دهد.

در MIP 3.7 از چند مبنا یا چند برنامه به‌روزشده استفاده می‌شود و رویدادها در نزدیک‌ترین دوره مناسب وارد می‌شوند. این روش ترتیب زمانی و تغییر مسیر بحرانی را بهتر از MIP3.6 منعکس می‌کند. بااین‌حال، مدل همچنان به کیفیت برنامه‌های به‌روزشده و زیرشبکه‌های رویداد وابسته است و پیامد پیش‌بینی‌شده لزوماً همان پیامد واقعی نهایی نیست.

MIP 3.8 و 3.9؛ مدل‌سازی کاهشی

MIP 3.8 رویدادها را از یک مدل چون‌ساخت واحد حذف می‌کند. MIP3.9 همین کار را در چند مدل یا پنجره انجام می‌دهد تا تغییر منطق و مسیر بحرانی دوره‌ای بهتر لحاظ شود. هر دو روش به یک مدل چون‌ساخت محاسبه‌پذیر نیاز دارند و در صورت بازسازی منطق، باید فرضیات تحلیلگر آشکار و قابل رسیدگی باشند.

AACE هیچ‌یک از این نه روش را «بهترین» معرفی نمی‌کند. حتی ممکن است در دوره‌های مختلف یک پروژه از روش‌های متفاوت استفاده شود؛ به شرط آنکه علت انتخاب، داده‌های مورد استفاده و نحوه اتصال نتایج شفاف باشد.

مقایسه روش‌های SCL و AACE 29R-03

SCL و AACE درباره یک موضوع صحبت می‌کنند، اما هدف و زبان یکسانی ندارند. SCL سندی گسترده‌تر درباره مدیریت تأخیر، اختلال، تمدید مدت، همزمانی، شناوری، تسریع، سوابق و هزینه است. AACE29R-03 بر جنبه‌های فنی و مستند تحلیل برنامه زمان‌بندی مبتنی بر روش مسیر بحرانی در ادعاها و اختلاف‌ها تمرکز دارد و روش‌ها را با جزئیات اجرایی طبقه‌بندی می‌کند.

مقایسه کلی دو مرجع

معیار	SCL Delay and Disruption Protocol، ویرایش دوم ۲۰۱۷	AACE RP 29R-03، بازنگری ۲۰۱۱
دامنه	تأخیر، اختلال، تمدید مدت، همزمانی، شناوری، تسریع، سوابق و هزینه	جنبه‌های فنی و مستند تحلیل برنامه زمان‌بندی مبتنی بر روش مسیر بحرانی در ادعاها و اختلاف‌ها
ماهیت	راهنمای حرفه‌ای؛ متمرکز بر بازار بریتانیا و با توجه ویژه به حقوق انگلیس	Recommended Practice غیرتجویزی؛ فنی و قابل استفاده با توجه به قرارداد و حوزه قضایی
زمان تحلیل	هم رسیدگی همزمان با اجرا و هم تحلیل گذشته‌نگر	تمرکز اصلی بر تحلیل گذشته‌نگر؛ محاسبات رو‌به‌جلو نیز ممکن است در تحلیل گذشته‌نگر استفاده شوند
تعداد روش‌های اصلی	شش روش رایج برای تحلیل با فاصله از رویداد	نه Method Implementation Protocol
منطق طبقه‌بندی	رابطه علت و معلولی، زمان تعیین مسیر بحرانی، زمان تعیین پیامد و داده لازم	مشاهده/مدل‌سازی، ایستا/پویا، افزایشی/کاهشی، مبنای واحد/چندگانه
روش ترجیحی	برای تحلیل گذشته‌نگر روش واحدی را ترجیح نمی‌دهد؛ برای رسیدگی همزمان TIA را پیشنهاد می‌کند	هیچ روش را بهترین یا برتر برای همه موارد نمی‌داند
انتخاب روش	هشت معیار در بند 11.3	یازده عامل فنی، حقوقی و عملی در بخش 5
اعتبارسنجی داده	تأکید گسترده بر برنامه و سوابق هم‌زمان با اجرا	پروتکل‌های تفصیلی SVP 2.1 تا 2.4
رابطه با قرارداد	قرارداد و قانون حاکم مقدم‌اند	قرارداد، واقعیت‌ها، قانون و کیفیت داده‌ها تعیین‌کننده‌اند

تطبیق تقریبی روش‌های SCL با MIPهای AACE

این جدول «معادل قطعی» ارائه نمی‌کند. نام روش‌ها در صنعت یکدست نیست و نحوه اجرا می‌تواند یک تحلیل را از یک MIP به MIP دیگر منتقل کند.

روش SCL	نزدیک‌ترین طبقه AACE	درجه تطابق	توضیح ضروری
Impacted As-Planned	MIP 3.6	زیاد	افزودن زیرشبکه رویداد به یک مبنای واحد
Time Impact Analysis	معمولاً MIP 3.7؛ گاهی MIP 3.6	متوسط تا زیاد	تعداد مبناها و زمان ورود زیرشبکه رویداد باید بررسی شود؛ نام TIA به‌تنهایی کافی نیست
Time Slice Windows	MIP 3.3 یا 3.4؛ در بازسازی گسترده MIP 3.5	زیاد در خانواده روش	SCL تفکیک As-Is، Split و Recreated را مانند AACE نام‌گذاری نمی‌کند
As-Planned vs As-Built Windows	نزدیک به MIP 3.2؛ گاهی دارای عناصر 3.3 یا 3.5	متوسط	SCL می‌تواند مسیر واقعی هر پنجره را با شواهد پویا تعیین کند؛ MIP 3.2 عمدتاً منطق ایستا دارد
Retrospective Longest Path	نزدیک به MIP 3.1 همراه با تحلیل مسیر چون‌ساخت	کم تا متوسط	در AACE MIP مستقل و هم‌نامی وجود ندارد
Collapsed As-Built	MIP 3.8 یا 3.9	زیاد	مدل واحد برابر خانواده 3.8 و اجرای پنجره‌ای برابر خانواده 3.9 است

نکاتی که نباید نادیده گرفته شوند

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

چگونه روش مناسب آنالیز تأخیر را انتخاب کنیم؟

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

ماتریس راهنمای انتخاب

وضعیت پروژه و داده‌ها	گزینه‌های قابل بررسی	هشدار اصلی
پروژه در حال اجرا، رویداد مشخص، برنامه به‌روزشده معتبر و نزدیک به رویداد	TIA همزمان با اجرا	نتیجه پیش‌بینی است و باید بعداً با اثر واقعی کنترل شود
رویداد در ابتدای پروژه، پیشرفت اندک، فقط برنامه مبنای معتبر	Impacted As-Planned	تأخیرهای بعدی و تغییر مسیر بحرانی را نشان نمی‌دهد
پروژه تکمیل‌شده، برنامه‌های به‌روزشده منظم و معتبر	Time Slice Windows، MIP 3.3 یا 3.4، گاهی MIP 3.7	تفاوت پیشرفت و تغییر منطق و مرز پنجره‌ها باید کنترل شود
برنامه‌های به‌روزشده ناقص، اما برنامه مبنا و داده‌ی چون‌ساخت مناسب	APAB Windows، Retrospective Longest Path، MIP 3.2 یا 3.5	بازسازی و استدلال مسیر بحرانی باید شفاف باشد
برنامه مبنای قابل اتکا موجود نیست، اما چون‌ساخت منطق‌دار قابل تهیه است	Collapsed As-Built، MIP 3.8 یا 3.9	منطق چون‌ساخت و رویدادهای حذف‌شده محل اصلی چالش‌اند
پروژه کوتاه و ساده با تغییر منطق ناچیز	MIP 3.1 یا مقایسه ساده APAB	محدودیت روش و عدم تعمیم به پروژه پیچیده تصریح شود
پروژه طولانی، چندمسیره و دارای بازتوالی‌های متعدد	روش پویا و پنجره‌ای	روش ایستا احتمالاً تغییر مسیر بحرانی را پنهان می‌کند
هدف، تعیین تأخیر قابل‌جبران یا همزمانی است	روش پایه به‌همراه تحلیل مستقل همزمانی و مسئولیت	خروجی خام نرم‌افزار برای نتیجه مالی کافی نیست

یادداشت انتخاب روش

پیش از شروع مدل‌سازی، بهتر است یک «یادداشت انتخاب روش» تهیه شود که در آن این موارد ثبت شوند:

– سؤال یا هدف تحلیل؛

– نسخه و بند قراردادی مرتبط؛

– فهرست داده‌های موجود و شکاف‌ها؛

– روش انتخابی و MIP نزدیک؛

– علت رد یا عدم امکان سایر روش‌ها؛

– فرضیات، محدودیت‌ها و سطح دقت مورد انتظار؛

– شیوه تحلیل مسیر بحرانی، شناوری، همزمانی و تأخیر همگام؛

– نرم‌افزار، نسخه، تنظیمات و فایل‌های مرجع؛

– کنترل‌های مستقلی که برای آزمون نتیجه انجام خواهد شد.

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

انتخاب روش آنالیز تأخیر فقط با شناخت نام روش‌ها ممکن نیست. کیفیت برنامه، وضعیت پروژه، اسناد در دسترس، مسیر بحرانی و الزامات قرارداد باید همزمان بررسی شوند. «دوره جامع آنالیز تأخیرات در صنعت ساخت» این مسیر را از مبانی تا اجرای تحلیل و تهیه لایحه به‌صورت ساختاریافته دنبال می‌کند.

اطلاعات بیشتر >>

رویکردهای آنالیز تأخیرات در ایران

در ایران نمی‌توان یک «روش داخلی واحد» را بر تمام پروژه‌ها حاکم دانست. قراردادهای تابع نشریه ۴۳۱۱، قراردادهای EPC یا PC، پیمان‌های سرجمع، قراردادهای وزارت نفت و قراردادهای خصوصی از نظر رویدادهای قابل تمدید، اخطار، نقش مشاور یا مدیر طرح، تأخیرهای همزمان و آثار مالی یکسان نیستند. روش فنی باید در چارچوب همان قرارداد انتخاب و اجرا شود.

نشریه ۴۳۱۱؛ سازوکار قراردادی، نه روش محاسباتی واحد

در پیمان‌های مشمول موافقتنامه و شرایط عمومی پیمان موضوع بخشنامه 102/1088-54/842 مورخ 1378/03/03 ماده ۳۰ موارد قابل بررسی برای تغییر مدت، فرآیند درخواست و رسیدگی و تعیین تأخیرهای مجاز و غیرمجاز را بیان می‌کند. معادل مدت تأخیر مجاز، مدت پیمان تمدید می‌شود و تأخیر غیرمجاز می‌تواند در چارچوب ماده ۵۰ آثار خسارت تأخیر داشته باشد.

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

ماده ۳۰ نام یکی از روش‌های SCL یا AACE را الزام نمی‌کند. بنابراین «مجاز بودن علت» و «مقدار اثر بحرانی» باید از هم جدا شوند: نخست قرارداد مشخص می‌کند رویداد اصولاً قابل بررسی هست یا نه؛ سپس روش فنی مقدار اثر آن را تعیین می‌کند.

پیمان‌های EPC، PC، سرجمع و قراردادهای خصوصی

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

در پیمان‌های EPC و PC برای کارهای صنعتی ابلاغی سال ۱۴۰۳، سازوکارهای زمان، تغییر و تمدید باید از متن همان الگوی قراردادی و پیوست‌های آن خوانده شوند. «پیمان طرح و ساخت غیرصنعتی» که در ادبیات حرفه‌ای ایران با عنوان EPC Package 84 شناخته می‌شود نیز سندی جداگانه است و نباید با الگوهای صنعتی ۱۴۰۳ یکسان فرض شود. همین احتیاط درباره شرایط عمومی اختصاصی وزارت نفت و سایر کارفرمایان صنعتی لازم است. ذکر یک روش بین‌المللی در گزارش، جای اثبات رعایت تشریفات پیمان حاکم را نمی‌گیرد.

تأخیرات مالی؛ تحلیل قراردادی و اثر برنامه‌ای

در قراردادهایی که بخشنامه‌های تأخیرات مالی (منتشر شده توسط سازمان برنامه و بودجه کشور) مانند ۵۰۹۰ یا ۱۳۰۰ بر آن‌ها قابل اعمال‌اند، محاسبه دوره منتسب به تأخیر پرداخت یک تحلیل قراردادی مهم است؛ اما عدد حاصل از فرمول، به‌خودی‌خود ثابت نمی‌کند که همان تعداد روز تاریخ تکمیل را جابه‌جا کرده است. برای اثبات استحقاق تمدید مدت باید نشان داده شود کمبود نقدینگی در چه زمانی چه منابع، خرید یا فعالیتی را متأثر کرده و پیامد آن چگونه به مسیر بحرانی رسیده است.

چارچوب پیشنهادی برای پروژه‌های ایران

شناسایی نظام قراردادی: تعیین دقیق شرایط عمومی، خصوصی، بخشنامه‌ها، الحاقیه‌ها و تاریخ‌های حاکم.
ساخت ماتریس استحقاق: رویداد، بند قرارداد، اخطار، مسئولیت اولیه و نتیجه زمانی یا مالی بالقوه.
حفظ فایل‌های بومی برنامه: دریافت و قفل نسخه‌های MPP، XML، XER یا فایل‌های متناظر، همراه با گزارش تنظیمات.
اعتبارسنجی برنامه و سوابق: برنامه مبنا، برنامه‌های به‌روزشده، برنامه چون‌ساخت، تقویم، منطق، قیود و تاریخ‌های واقعی.
انتخاب مستدل روش: تهیه یادداشت انتخاب روش و بیان محدودیت‌ها.
تحلیل فنی: مسیر بحرانی، شناوری، رویدادها، همزمانی، تأخیر همگام، بازیابی و تسریع.
تحلیل قراردادی: تبدیل یافته فنی به تأخیر مجاز، غیرمجاز، قابل‌جبران یا غیرقابل‌جبران.
بسته دفاع: فایل‌های قبل و بعد، جداول محاسبه، نمودارها، اسناد پشتیبان و پاسخ به سناریوهای طرف مقابل.

اجرای روش‌ها در Primavera P6 و Microsoft Project

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

قواعد مشترک در هر دو نرم‌افزار

– فایل اصلی هرگز مستقیماً ویرایش نشود؛ نسخه تحلیل با شناسه، تاریخ و Hash یا کنترل نسخه نگهداری شود.

– تاریخ داده یا تاریخ وضعیت برای هر محاسبه ثبت شود.

– تقویم‌ها، ساعات کاری، تعطیلات و استثناها مستند شوند.

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

– پیش و پس از ورود هر زیرشبکه رویداد یا حذف هر رویداد، فایل مستقل و گزارش مقایسه ذخیره شود.

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

– فعالیت‌های نزدیک‌به‌بحرانی نیز بررسی شوند؛ زیرا ممکن است پس از حذف یا ورود رویداد به مسیر بحرانی تبدیل شوند.

– تغییرات منطق، مدت اولیه، مدت باقی‌مانده، تاریخ‌های واقعی و تقویم ثبت و توجیه شوند.

– خروجی PDF یا تصویر صفحه، جای فایل اصلی نرم‌افزار را نمی‌گیرد.

نکات ویژه Primavera P6

در P6 باید فایل‌های XER یا XML، تاریخ داده، تنظیمات محاسبه برنامه، تقویم‌ها، قیود، تاریخ‌های واقعی، روش محاسبه فعالیت‌های خارج از توالی و تنظیمات تشخیص فعالیت‌های بحرانی ثبت شوند. تفاوت میان «حفظ منطق برنامه» (Retained Logic) و «غلبه پیشرفت واقعی بر منطق» (Progress Override) می‌تواند تاریخ‌های آینده و مسیر بحرانی را تغییر دهد؛ بنابراین تنظیم انتخاب‌شده باید با وضعیت واقعی اجرا و روش تحلیل سازگار و در گزارش افشا شود.

نکات ویژه Microsoft Project

در MSP باید فایل MPP یا XML، تاریخ وضعیت، حالت محاسبه، تقویم پروژه و منابع، نوع قید، تاریخ واقعی شروع و پایان، مدت باقی‌مانده و نسخه‌های ذخیره‌شده برنامه مبنا کنترل شوند. نمایش وضعیت «بحرانی» در MSP تابع محاسبات و آستانه بحرانی‌بودن است و نباید بدون بررسی شناوری و منطق به‌عنوان نتیجه نهایی پذیرفته شود.

حداقل خروجی فنی تحلیل

– فهرست فایل‌های منبع و نسخه‌های تحلیل؛

– گزارش اعتبارسنجی برنامه مبنا، برنامه‌های به‌روزشده و برنامه چون‌ساخت؛

– جدول تغییرات هر فایل؛

– رجیستر رویدادها و زیرشبکه‌های آن‌ها؛

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

– محاسبات قبل و بعد؛

– جدول همزمانی و تأخیر همگام؛

– تفکیک روزهای مجاز، غیرمجاز و در صورت وجود قابل‌جبران؛

– گزارش تشریحی برنامه زمان‌بندی و توضیح فرضیات و محدودیت‌ها.

مثال فرضی مقایسه چند روش

فرض کنید برنامه زمان‌بندی پروژه هر ماه به‌روزرسانی شده و سه رویداد مهم رخ داده است:

– در پنجره دوم، ابلاغ نقشه یک بخش با تأخیر انجام شده است؛

– در پنجره سوم، کمبود منابع پیمانکار باعث افت پیشرفت در جبهه دیگری شده است؛

– در پنجره چهارم، یک تغییر عمده توالی اجرا و مسیر بحرانی را جابه‌جا کرده است.

این مثال واقعی نیست و فقط تفاوت منطق روش‌ها را نشان می‌دهد.

اگر روش اثرگذاری رویدادها بر برنامه مبنا (IAP) استفاده شود

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

اگر روش تحلیل اثر زمانی (TIA) استفاده شود

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

اگر روش تحلیل پنجره‌های زمانی (WA) استفاده شود

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

اگر روش پنجره‌ای حذف رویدادها از برنامه چون‌ساخت (CAB) استفاده شود

برای هر پنجره یک مدل چون‌ساخت محاسبه‌پذیر ساخته می‌شود. تأخیرهای منتخب کارفرما حذف و تاریخ But-For محاسبه می‌شود؛ کمبود منابع پیمانکار در مدل باقی می‌ماند. اگر همین کمبود منابع مانع تکمیل زودتر شود، مقدار Collapse کمتر از مجموع مدت رویدادهای کارفرما خواهد بود.

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

خطاهای رایج در تهیه و رسیدگی به لایحه تأخیرات

انتخاب روش پس از مشاهده نتیجه

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

استفاده از برنامه مبنا بدون اعتبارسنجی

منطق ناقص، تقویم اشتباه، قیود تحمیلی یا دامنه ناقص می‌توانند مسیر بحرانی مصنوعی بسازند. تأیید کارفرما یا مشاور، کنترل فنی را حذف نمی‌کند.

ثابت فرض‌کردن مسیر بحرانی

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

افزودن فقط رویدادهای طرف مقابل

مدلی که فقط رویدادهای کارفرما یا فقط رویدادهای پیمانکار را وارد کند، ممکن است همزمانی، تأخیر همگام و مسیر جایگزین را پنهان کند.

یکسان‌گرفتن همپوشانی و همزمانی

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

جمع مضاعف روزها

یک رویداد ممکن است چند فعالیت را متأثر کند یا چند نامه درباره یک اثر وجود داشته باشد. روزهای یک اثر نباید با نام‌های مختلف چند بار شمرده شوند.

زیرشبکه غیرواقعی برای رویداد

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

فاصله زیاد زیرشبکه رویداد از تاریخ داده

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

نادیده‌گرفتن بازیابی و تسریع

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

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

تعداد روزهای تمدیدشده الزاماً دوره جبران هزینه نیست. مبنای مالی، همزمانی، اسناد هزینه و رابطه سببیت باید جداگانه بررسی شوند.

ارائه خروجی نرم‌افزار بدون مسیر ممیزی

جدول و تصویر صفحه، بدون فایل منبع، تنظیمات، تغییرات و فایل‌های قبل و بعد قابل بازتولید نیستند و ارزش دفاعی محدودی دارند.

پیچیدگی نمایشی

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

چک‌لیست تهیه یک تحلیل قابل دفاع

کنترل	پرسش نهایی	وضعیت
قرارداد	تاریخ‌ها، رویدادهای قابل تمدید، اخطار و روش مقرر کنترل شده‌اند؟	☐
نسخه‌ها	همه نسخه‌های برنامه مبنا، برنامه‌های به‌روزشده و فایل‌های اصلی نرم‌افزار فهرست و قفل شده‌اند؟	☐
اعتبارسنجی	منطق، تقویم، قیود، تاریخ داده و اطلاعات عملکرد واقعی کنترل شده‌اند؟	☐
چون‌ساخت	تاریخ‌ها و منطق واقعی با اسناد مستقل تطبیق داده شده‌اند؟	☐
رویدادها	علت، اثر، فعالیت متأثر، تاریخ‌ها و مدارک هر رویداد مشخص‌اند؟	☐
انتخاب روش	علت انتخاب و رد روش‌های دیگر پیش از محاسبه ثبت شده است؟	☐
مسیر بحرانی	معیار بحرانی‌بودن و مسیر هر دوره مستند است؟	☐
شناوری	شناوری و نحوه مصرف آن بر اساس قرارداد و برنامه به‌روزشده معتبر بررسی شده است؟	☐
همزمانی	همپوشانی تقویمی از علت مؤثر همزمان تفکیک شده است؟	☐
تأخیر همگام	وجود تأخیر غالب و امکان یا قصد واقعی اجرای سریع‌تر بررسی شده است؟	☐
بازیابی	اقدامات کاهش اثر، تسریع و تغییر توالی در نتیجه لحاظ شده‌اند؟	☐
محاسبه	فایل‌های قبل و بعد و تنظیمات هر بار اجرای محاسبات نگهداری شده‌اند؟	☐
مسئولیت	یافته فنی از نتیجه قراردادی و حقوقی تفکیک شده است؟	☐
هزینه	تمدید مدت از تأخیر قابل جبران مالی و دوره محاسبه هزینه جدا شده است؟	☐
کنترل متقابل	نتیجه با روش یا شواهد مستقل و عقل سلیم آزمون شده است؟	☐
گزارش	فرضیات، محدودیت‌ها و شکاف‌های داده صریحاً اعلام شده‌اند؟	☐

لایحه تأخیرات قابل دفاع باید قرارداد، برنامه زمان‌بندی، مسیر بحرانی، رویدادها، همزمانی و اسناد پروژه را در یک زنجیره منسجم به هم متصل کند. خدمت «تهیه لایحه تأخیرات و دفاع از آن» مدیر ادعا، بررسی فنی و قراردادی پرونده را از انتخاب روش تا ارائه و پاسخ به ایرادهای رسیدگی پوشش می‌دهد.

اطلاعات بیشتر >>

پرسش‌های متداول

بهترین روش آنالیز تأخیرات کدام است؟

روش برتر و ثابتی برای همه پروژه‌ها وجود ندارد. قرارداد، هدف تحلیل، زمان انجام، کیفیت برنامه و سوابق، پیچیدگی پروژه، ارزش اختلاف و مرجع رسیدگی تعیین می‌کنند کدام روش مناسب‌تر است. AACE صریحاً روش‌ها را رتبه‌بندی نمی‌کند و SCL نیز برای تحلیل گذشته‌نگر روش واحدی را ترجیح نمی‌دهد.

تفاوت روش تحلیل اثر زمانی (TIA) با تحلیل پنجره‌های زمانی (WA) چیست؟

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

آیا همه روش‌های پنجره‌ای یکسان‌اند؟

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

آیا برنامه زمان‌بندی تأییدشده حتماً معتبر است؟

خیر. تأیید قراردادی و اعتبار فنی دو موضوع مرتبط اما متفاوت‌اند. برنامه تأییدشده ممکن است از نظر منطق، تقویم، دامنه، مدت‌ها یا قیود برای تحلیل تأخیر قابل اتکا نباشد.

اگر برنامه‌های به‌روزشده پروژه موجود نباشند، از چه روشی می‌توان استفاده کرد؟

بسته به داده‌های باقی‌مانده می‌توان روش مقایسه برنامه مبنا با چون‌ساخت (APAB)، روش بررسی گذشته‌نگر طولانی‌ترین مسیر، روش حذف رویدادها از برنامه چون‌ساخت (CAB) یا برنامه‌های به‌روزشده بازسازی‌شده را بررسی کرد. نبود برنامه‌های به‌روزشده، انتخاب‌ها را محدود و میزان قضاوت تحلیلگر را بیشتر می‌کند؛ بنابراین قطعیت نتیجه باید متناسب با کیفیت داده بیان شود.

آیا جمع مدت عوامل تأخیر برای تمدید مدت کافی است؟

معمولاً خیر. مدت وقوع رویداد با پیامد خالص آن بر تاریخ تکمیل یکسان نیست. شناوری، مسیر بحرانی، همپوشانی، تأخیرهای دیگر، بازیابی و تغییر توالی باید بررسی شوند.

آیا همپوشانی دو رویداد به معنی تأخیر همزمان است؟

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

آیا تمدید مدت به معنی استحقاق هزینه است؟

خیر. تمدید مدت و جبران مالی مبانی قراردادی و اثباتی جدا دارند. ممکن است تأخیر مجاز اما غیرقابل‌جبران باشد یا دوره هزینه با تعداد روزهای تمدید یکسان نباشد.

برای آنالیز تأخیرات P6 بهتر است یا MSP؟

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

آیا می‌توان برای یک پروژه از چند روش استفاده کرد؟

بله. AACE استفاده از روش‌های متفاوت برای دوره‌ها یا اهداف متفاوت را منتفی نمی‌داند. ترکیب روش‌ها باید از پیش توجیه، مرز هر روش مشخص و نتایج به‌صورت شفاف با هم آشتی داده شوند.

آیا SCL و AACE در قراردادهای ایران الزام‌آورند؟

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

جمع‌بندی

روش آنالیز تأخیر باید از داده و سؤال پرونده انتخاب شود، نه از نتیجه‌ای که یک طرف انتظار دارد. روش اثرگذاری رویدادها بر برنامه مبنا (IAP) و روش تحلیل اثر زمانی (TIA) از رویداد آغاز می‌کنند و پیامد زمانی آن را مدل می‌سازند؛ روش پنجره‌های زمانی (WA) و روش مقایسه پنجره‌ای برنامه مبنا با برنامه چون‌ساخت (APAB) از تأخیر واقع‌شده در هر دوره آغاز می‌کنند و علت را می‌جویند؛ روش بررسی گذشته‌نگر طولانی‌ترین مسیر، مسیر کنترل‌کننده نهایی را دنبال می‌کند و روش حذف رویدادها از برنامه چون‌ساخت (CAB)، وضعیت فرضی پروژه در نبود رویدادهای منتخب را محاسبه می‌کند.

SCL این روش‌ها را در یک چارچوب گسترده قراردادی و مدیریتی قرار می‌دهد. AACE 29R-03 با نه MIP، تفاوت‌های فنی نحوه اجرای آن‌ها را دقیق‌تر می‌کند. این دو مرجع رقیب یکدیگر نیستند، اما معادل یک‌به‌یک هم نیستند.

در پروژه‌های ایران، نخست باید قرارداد حاکم مشخص شود. ماده ۳۰ نشریه ۴۳۱۱، شرایط پیمان‌های EPC و PC، قراردادهای سرجمع یا خصوصی و بخشنامه‌های مرتبط می‌توانند مبنای استحقاق و تشریفات را تغییر دهند. سپس برنامه مبنا، برنامه‌های به‌روزشده، برنامه چون‌ساخت و سوابق اعتبارسنجی می‌شوند و روش متناسب انتخاب می‌گردد.

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

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