7. D&D Protocol (Delay Analysis) ตอนที่5

เอกสาร "Delay and Disruption Protocol" ตอนที่5

การวิเคราะห์ความล่าช้าในระหว่างดำเนินการก่อสร้าง (Contemporaneous analysis of delay)

หากมีการปฏิบัติตามGood practice เกี่ยวกับแผนงานและการบันทึกข้อมูล(Programme and records)ในระหว่างดำเนินการก่อสร้างตามที่SCLได้แนะนำไว้แล้ว เอกสารนี้ก็จะสามารถนำไปใช้ในการวิเคราะห์ความล่าช้า(Delay Analysis)ในระหว่างดำเนินการก่อสร้างได้

ในทุกๆครั้งที่เกิดเหตุEmployer Risk Eventในระหว่างดำเนินการก่อสร้าง ผู้รับจ้างควรที่จะต้องส่ง Sub-network (หรือที่เรียกกันว่า Fragnet)ที่แสดงผลกระทบของเหตุEmployer Risk Eventที่เกิดขึ้นหรือคาดว่าจะเกิดขึ้นนั้นโดยการนำไปแทรกเข้าไปในUpdated programme ล่าสุด โดยแทรกเข้าที่Activityก่อนหน้าที่ใกล้กับช่วงเวลาที่เกิดเหตุEmployer Risk Eventนั้นต่อผู้ควบคุมงาน(CA)เพื่อพิจารณา

CAควรพิจารณาให้ความเห็นหรือตกลงกันให้ได้ข้อยุติทุกๆครั้งที่เกิดเหตุนั้นๆ (เช่นมีคำสั่งเปลี่ยนแปลงแบบ มีคำสั่งหยุดงาน ฯลฯ) ว่าเป็นเหตุที่ผู้ว่าจ้างต้องรับผิดชอบจริงและส่งผลกระทบต่อCritical pathหรือไม่ มีความจำเป็นต้องแก้ไขการเชื่อมโยงงาน(Logic Link)ในUpdated programmeให้สมเหตุสมผลยิ่งขึ้นเสียก่อนหรือไม่ เรื่องเหล่านี้ควรเจรจากันด้วยเหตุผลพร้อมรายละเอียดสนันสนุน หากต้องอาศัยคนกลางเข้ามาวินิจฉัยก็ควรทำให้จบเป็นกรณีๆไป ไม่ควรปล่อยให้ยังคงเห็นต่างและขัดแย้งกันในเหตุการณ์ต่างๆอยู่อย่างนั้นแบบWait and seeไปจนจบโครงการ แต่ควรสรุปให้ได้ข้อยุติตรงกันว่าเกิดผลกระทบต่อกำหนดแล้วเสร็จตามสัญญาเดิมหรือไม่อย่างไร แล้วปรับแผนที่อนุมัติEOTแล้วนั้นเพื่อยึดถือไว้ใช้ติดตามความก้าวหน้าของงานร่วมกันต่อไป (หากทำได้ดังนี้ก็จะเพิ่มโอกาสที่จะไม่เกิดข้อพิพาทจากการเรียกร้องสิทธิย้อนหลังถึงขั้นต้องฟ้องร้องกันในภายหลัง)

ผู้รับจ้างควรใส่เหตุที่เป็นเหตุที่ผู้รับจ้างเป็นผู้รับผิดชอบ(Contractor Risk Event)เข้าในFragnetนั้นด้วย (ถ้ามี) อย่างไรก็ตาม SCLได้ให้หลักการไว้ว่าถ้ามีความล่าช้าจากทั้งสองฝ่าย(Concurrent delay)เกิดขึ้นพร้อมๆกันหรือแม้ไม่พร้อมกันแต่ก่อให้เกิดผลกระทบขึ้นในช่วงเวลาเดียวกันแล้ว การอนุมัติขยายระยะเวลา(EOT)ที่เกิดจากEmployer Risk Eventที่ยาวกว่าจะไม่ถูกหักลบด้วยระยะเวลาที่ถูกกระทบด้วยContractor Risk Event  (ผู้เขียนเข้าใจว่าในทางกลับกัน หากContractor Risk Event ยาวกว่า ผู้รับจ้างก็ไม่มีสิทธิที่จะเรียกร้องขอEOT)

การวิเคราะห์ความล่าช้า (Delay Analysis)

การวิเคราะห์ผลกระทบของFragnetนี้ เรียกว่า “Delay Analysis” ซึ่งเป็นกระบวนการที่จะไม่สามารถทำได้โดยสมบูรณ์เลยหากปราศจากแผนงานที่ถูกวางไว้ครั้งแรกด้วยการเชื่อมโยงงานต่างๆเข้าด้วยกัน (a logic linked baseline programme)ที่ได้รับการเห็นชอบร่วมกันและอนุมัติใช้งานเป็นAccepted programme และUpdated programmesเพื่อบันทึก%ความคืบหน้าและข้อมูลจริงต่างๆ(Actual start date, Remaining duration, Actual finish date, etc.)ในลำดับต่อๆไป หากขาดซึ่งเอกสารเหล่านี้ก็ย่อมไม่มีหลักฐานอะไรที่จะนำมาใช้พูดคุยเจรจากันด้วยเหตุผล ข้อเรียกร้องที่ขาดเหตุผลสนับสนุนที่หนักแน่นเพียงพอที่ไม่สามารถเจรจากันให้ได้ข้อยุติครั้งแล้วครั้งเล่า ย่อมสุ่มเสี่ยงที่จะนำไปสู่ข้อพิพาทที่ลุกลามใหญ่โตขึ้นได้

ในสัญญาก่อสร้างสากลจึงมักมีEOT Clauseที่ระบุเหตุที่ก่อให้เกิดสิทธิในการขอขยายระยะเวลาก่อสร้างและกำหนดบทบาทหน้าที่ของฝ่ายต่างๆเกี่ยวกับกระบวนการพิจารณาขยายระยะเวลาก่อสร้างที่ถือเป็นข้อตกลงที่ทุกฝ่ายต้องยึดถือปฏิบัติ พร้อมทั้งระบุสิทธิของฝ่ายหนึ่งในการพิจารณาEOTหรือไม่อย่างใด เมื่ออีกฝ่ายหนึ่งไม่ปฏิบัติตามข้อพึงปฏิบัติที่กำหนด

วิธีวิเคราะห์ความล่าช้าแบบต่างๆ (Different method of delay analysis)

วิธีวิเคราะห์ความล่าช้าแบบต่างๆที่ใช้กันอยู่ มีอยู่ด้วยกัน6วิธีขึ้นอยู่กับว่า มีการทำแผนงานที่เป็นเอกสารหลักฐานรองรับเพียงพอที่จะใช้วิธีใด ซึ่งสรุปได้ดังตารางต่อไปนี้
 

1. Impacted As-Planned Analysis
วิธีนี้จะแทรกsub-networksเข้าไปใน logic linked baseline programme แล้วคำนวณด้วยCPMหากำหนดวันก่อสร้างแล้วเสร็จใหม่ที่ได้รับผลกระทบจากการแทรกแบบคาดการณ์ไปข้างหน้า(Prospective impact)  Baseline programmeที่ว่านี้ควรจะได้รับการเห็นชอบเป็นAccepted programmeแล้วว่ามีขั้นตอนและกำหนดเวลาสำหรับงานต่างๆที่เชื่อมโยงกันอย่างเป็นไปได้จริงและสมเหตุสมผล วิธีนี้มีข้อกำจัดตรงที่ไม่ได้พิจารณาactual progressและความเปลี่ยนแปลงไปจากbaselineต่างๆที่เกิดขึ้นจริง จึงเหมาะกับการใช้วิเคราะห์ความล่าช้าจากdelay eventsที่เกิดขึ้นในช่วงแรกๆของการดำเนินการก่อสร้าง 

  2.Time Impact Analysis

วิธีนี้จะแทรกsub-networksเข้าไปใน Updated programme แล้วคำนวณด้วยCPMหากำหนดวันก่อสร้างแล้วเสร็จใหม่ที่ได้รับผลกระทบจากการแทรกแบบคาดการณ์ไปข้างหน้า(Prospective impact) วิธีนี้จะพิจารณาactual progressและความเปลี่ยนแปลงไปจากbaselineต่างๆที่เกิดขึ้นจริงในขณะที่เกิดDelay eventsนั้นๆประกอบด้วย วิธีนี้จึงเหมาะกับการวิเคราะห์ความล่าช้าในระหว่างดำเนินการก่อสร้าง (Contemporaneous analysis of delay)เพื่อหาข้อยุติในการพิจารณาEOTในขณะที่เกิดDelay Eventsขึ้นในช่วงๆต่างๆของโครงการโดยไม่wait and seeวิธีนี้จึงเป็นGood practiceที่SCLแนะนำ

3.Time Slice Windows Analysis

วิธีนี้ต้องใช้Updated programmesที่สะท้อนภาพสถานะความก้าวหน้าของโครงการ ณช่วงเวลาต่างๆ(Time slices)ซึ่งโดยทั่วไปมักจะเป็นทุกๆสิ้นเดือนที่จะแสดงให้เห็นถึงCritical delaysในCritical pathsที่อาจเพิ่มขึ้นในแต่ละจุดสิ้นสุดของแต่ละช่วงเวลา(แต่ละสิ้นเดือน)เพื่อสรุปหาผลกระทบจากเหตุที่เป็นสาเหตุที่แท้จริงของCritical delaysในแต่ละwindow 

4. As Planned vs. As built windows

วิธีนี้จะแบ่งช่วงระยะเวลาโครงการในUpdated programmesออกเป็นหลายๆ windowsตาม ช่วงเวลาที่ครอบคลุมkey dates หรือMilestonesสำคัญๆในแต่ละช่วงโครงการต่างๆ แล้วค้นหาเหตุที่เป็นCritical delaysในแต่ละwindowโดยเปรียบเทียบkey datesหรือMilestonesในUpdated programmes ณ เวลาต่างๆที่เลื่อนออกไปจาก Accepted (baseline) programme


5.Retrospective Longest Path Analysis

วิธีนี้จะต้องกำหนดas-Built critical path ย้อนหลัง โดยพิจารณาแกะรอยจากวันที่แล้วเสร็จงานในdetailed as-built programme ย้อนไปตามสายงานที่ยาวที่สุด แล้วค้นหาเหตุที่เป็นCritical delaysในแต่ละwindowโดยเปรียบเทียบkey datesหรือMilestonesในUpdated programmes ณ เวลาต่างๆที่เลื่อนออกไปจาก Accepted (baseline) programme 

6.Collapsed As-Built (or but-for) Analysis

วิธีนี้จะเป็นการดึงdelay eventsที่แทรกอยู่ใน detailed logic as-built programmeออกมา เพื่อหาสมมุติฐานว่าถ้าไม่มีdelay eventsเข้ามาแทรกแล้ว จะเกิดอะไรขึ้นกับactual programme วิธีนี้จึงไม่ต้องใช้baseline programme ผู้รับจ้างน้อยรายที่จะมีการจัดทำUpdated programmes เรื่อยมาจนสิ้นสุดสุดโครงการและได้เป็นแผนงานบันทึกความจริงชุดสุดท้ายที่เป็นas-built programme ในกรณีนี้ หากจำเป็นต้องใช้วิธีนี้ในการวิเคราะห์ ผู้วิเคราะห์ก็จะต้องจัดทำdetailed logic as-built programmeขึ้นเอง จากข้อมูลอื่นๆที่มีซึ่งจะใช้เวลามาก จากนั้นจึงดึงเอาDelay events sub-networksที่แทรกอยู่ออก เพื่อให้ได้วันเสร็จงานที่ล่าช้านั้นร่นเข้ามา (Collapsed) ทำให้สามารถคำนวณหาผลกระทบสุทธิ(net impact)ที่เกิดจากdelay eventsนั้นๆ 
        

นอกจากนี้ยังมียังทีวิธีการอื่นๆที่SCLเพียงพูดถึงแต่ชื่อวิธีการโดยที่ไม่ได้อธิบายรายละเอียด ได้แก่ วิธี as-planned vs. as builtแบบProject wide(คือไม่ได้ทำเป็นwindows), วิธีTime chainage analysis (สำหรับงานก่อสร้างที่เป็นเส้นทางตามยาว), line of balance analysis, resource curve analysis และ earned value analysis.

ในตอนต่อไปจะหยิบยกบางส่วนอื่นๆของ SCL's D&D Protocol Guidance Part B - Guidance on Core Principles ที่น่าสนใจได้แก่เรื่อง Disruption Analysisซึ่งอาจเป็นเรื่องที่บ้านเราอาจไม่คุ้นเคยกันมาขยายความ หากสนใจ โปรดติดตาม.....

References and Credits:
- https://www.scl.org.uk/resources/delay-disruption-protocol