เป็นไปได้หรือไม่ในการเพิ่มจำนวนเงินที่ประเมินหลังจากการพัฒนาระบบ

งานการพัฒนาระบบคืองานที่ทั้งฝ่ายที่สั่งงานและฝ่ายผู้รับงานจะต้องมีการมีผู้ร่วมมือจำนวนมากเพื่อทำงานดำเนินไป ดังนั้นการทำให้ทุกคนทำงานร่วมกันในโครงการไม่ได้เป็นเรื่องง่าย แน่นอนว่างานนี้ต้องมีการวางแผนอย่างมาก แต่ในเวลาเดียวกัน ฝ่ายที่สั่งงานจะสามารถรวบรวมข้อมูลที่เหมาะสมและสื่อสารกับผู้รับงานได้หรือไม่ ในความเป็นจริงแล้ว ไม่ได้เป็นอย่างนั้น หากมีการเปลี่ยนแปลงข้อกำหนดหรือเพิ่มฟังก์ชันหลังจากที่กระบวนการพัฒนาได้ดำเนินไปแล้ว จะสามารถเรียกเก็บค่าใช้จ่ายที่เพิ่มเติมจากการประเมินค่าใช้จ่ายก่อนหน้านี้ได้หรือไม่ สำหรับฝ่ายที่รับงาน นี่คือสิ่งที่ทำให้พวกเขาสงสัยอย่างมาก

สิทธิ์เหล่านี้จะได้รับการยอมรับในกรณีใดบ้างตามกฎหมาย? และค่าตอบแทนสำหรับการพัฒนาเพิ่มเติมและการแก้ไขฟังก์ชันจะตัดสินอย่างไร? ในบทความนี้ เราจะจัดระเบียบคำถามที่หลากหลายเหล่านี้

เริ่มต้นแล้ว การพัฒนาเพิ่มเติมและการแก้ไขฟังก์ชันคืออะไร

ในโครงการพัฒนาระบบ ประเภทของสัญญาที่เราจะรับงานมักจะเป็นสัญญาเอาที่จะรับหรือสัญญามอบหมายเป็นส่วนหนึ่ง ไม่ว่าจะเป็นประเภทสัญญาใด สิ่งที่ฝ่ายรับงานควรทำ (หน้าที่) และค่าตอบแทนที่เกี่ยวข้อง (สิทธิ์) จะเป็นคู่กันในสัญญา ดังนั้น หากมีงานที่ไม่ได้รวมอยู่ในงานที่เป็นพื้นฐานของค่าตอบแทนเพิ่มเข้ามาในภายหลัง สามารถกล่าวได้ว่าเป็นการพัฒนาเพิ่มเติมหรือการแก้ไขฟังก์ชัน ในทางกลับกัน หากมีงานที่รวมอยู่ในงานที่เป็นพื้นฐาน จะถูกจัดการเป็นสิ่งที่ตามข้อกำหนดเริ่มแรก (ภายในขอบเขตของสัญญาเดิม)

โดยอย่างไรก็ตาม เราได้อธิบายรายละเอียดเกี่ยวกับความแตกต่างระหว่างสัญญาเอาที่จะรับและสัญญามอบหมายเป็นส่วนหนึ่งในบทความอื่น

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]

อย่างไรก็ตาม หากคุณกล่าวว่าการปรับแต่งฟอนต์ที่แสดงบนหน้าจอและอื่น ๆ ทั้งหมดเป็นการพัฒนาเพิ่มเติม มันอาจจะขัดขวางการธุรกรรมทางการค้าที่ราบรื่น ดังนั้น ถ้าคุณพิจารณาถึงการอภิปรายเกี่ยวกับรายละเอียดของข้อกำหนดเหล่านี้ การวาดเส้นแบ่งที่เป็นที่ยอมรับทั่วไปไม่ได้ง่าย แต่ถ้าคุณต้องการแสดงแนวทางทั่วไป

• หลังจากที่ข้อกำหนดได้รับการยืนยันแล้ว คุณได้รับคำสั่งเพิ่มฟังก์ชันเพิ่มเติม
• หลังจากที่การติดตั้งโปรแกรมเสร็จสิ้นแล้ว คุณได้รับคำสั่งทำการแก้ไข

ในกรณีเหล่านี้ ความสำคัญทางกฎหมายของการอ้างอิงนี้มีความเป็นไปได้ที่สูง

ตัวอย่างคดีศาลที่มีข้อพิพาทเกี่ยวกับการพัฒนาเพิ่มเติมและการแก้ไขฟังก์ชัน

ตัวอย่างที่ยืนยัน: การเปลี่ยนแปลงข้อกำหนดของการออกแบบพื้นฐานหลังจากเริ่มงาน

ตัวอย่างต่อไปนี้เป็นการเปลี่ยนแปลงข้อกำหนดหลังจากเริ่มงาน

การพัฒนาซอฟต์แวร์จะต้องผ่านกระบวนการดังนี้ ①การกำหนดความต้องการ ②การออกแบบภายนอก ③การออกแบบภายใน ④การสร้างโปรแกรมต้นฉบับ (การออกแบบโปรแกรม, การเขียนโค้ด) ⑤การทดสอบต่างๆ (การทดสอบยูนิต, การทดสอบการรวม, การทดสอบระบบ) และข้อกำหนดเริ่มต้นจะถูกนำมาใช้ในการออกแบบภายในและการทำงานต่อไป ซึ่งนี่คือขอบเขตของงานที่เกี่ยวข้องกับสิทธิ์การเรียกเก็บค่าตอบแทนตามสัญญาการรับจ้างพัฒนานี้ การเสนอเปลี่ยนแปลงข้อกำหนดจากทางผู้ว่าจ้าง จะถูกเข้าใจว่าเป็นการขอรับจ้างงานใหม่ที่เกินขอบเขตของสัญญาเริ่มต้น และถ้าผู้รับจ้างไม่ได้เสนอค่าใช้จ่ายเพิ่มเติม และทำงานที่เกี่ยวข้องกับการรับจ้างเพิ่มเติมโดยไม่มีข้อตกลงเกี่ยวกับค่าใช้จ่ายเพิ่มเติม จะถูกเข้าใจว่ามีสัญญาการรับจ้างใหม่ที่ไม่ได้กำหนดค่าใช้จ่าย และมีความผูกพันในการชำระค่าใช้จ่ายเพิ่มเติมที่เหมาะสม

คำพิพากษาศาลจังหวัดโอซาก้า วันที่ 29 สิงหาคม พ.ศ. 2002 (ฮีเซ 14)

คำว่า “ความสัมพันธ์ในการชำระค่าตอบแทน” และ “สัญญาใหม่” จะเป็นคำสำคัญในการเข้าใจคำพิพากษานี้

นอกจากนี้ ในคำพิพากษาดังกล่าวยังมีอีกหนึ่งจุดที่น่าสนใจ คือ การปรับเปลี่ยนรายละเอียดเช่น การวางตำแหน่งปุ่ม หรือ รูปแบบตัวอักษร ไม่ถือว่าเป็นการเปลี่ยนแปลงข้อกำหนด ส่วนที่เกี่ยวข้องมีดังนี้

อย่างไรก็ตาม ในการพัฒนาซอฟต์แวร์ ด้วยลักษณะของงาน การกำหนดรายละเอียดเช่น รูปแบบตัวอักษรที่จะแสดงบนหน้าจอ หรือ การวางตำแหน่งปุ่ม ในขั้นตอนการออกแบบภายนอก ไม่ได้ถูกกำหนดไว้ และรายละเอียดเหล่านี้ สามารถปรับเปลี่ยนได้ในระหว่างการประชุมระหว่างผู้เกี่ยวข้องหลังจากการยืนยันข้อกำหนด ดังนั้น การขอรายละเอียดของข้อกำหนดเพิ่มเติมไม่ควรถือว่าเป็นการเปลี่ยนแปลงข้อกำหนด

คำพิพากษาศาลจังหวัดโอซาก้า วันที่ 29 สิงหาคม พ.ศ. 2002 (ฮีเซ 14)

ในคำพิพากษานี้ มีการใช้คำว่า “การระบุรายละเอียดของข้อกำหนด” ซึ่งน่าสนใจ

• การเปลี่ยนแปลงที่ทำให้สิ่งที่ควรจะถูกตัดสินใจไว้แล้วถูกยกเลิก
• การที่ไม่ได้ตัดสินใจเกี่ยวกับสิ่งที่ควรจะตัดสินใจไปในขณะทำงาน

ดังนั้น ควรจะมีการจัดการทางกฎหมายที่แตกต่างกันในสองกรณีนี้

ตัวอย่างการยืนยันอื่น ๆ

นอกจากนี้ยังมีกรณีที่ได้รับการยอมรับเกี่ยวกับการพัฒนาเพิ่มเติมและการแก้ไขฟังก์ชัน ได้แก่

• กรณีที่จำนวนโปรแกรมที่ส่งมอบเพิ่มขึ้นประมาณสองเท่าจากแผนเริ่มแรก (คำพิพากษาศาลแขวงโตเกียว ปี 17 หรือ 2005 วันที่ 22 เมษายน)
• กรณีที่ระยะเวลาการทำงานเพิ่มขึ้นประมาณสามเท่า (คำพิพากษาศาลแขวงโตเกียว ปี 22 หรือ 2010 วันที่ 22 มกราคม)

เมื่อจัดเรียงข้อมูลดังกล่าว จะพบว่าการขยายระยะเวลาการทำงาน ก็ถือเป็นการพัฒนาเพิ่มเติมในความหมายที่กว้างขวาง และได้รับการคุ้มครองทางกฎหมายในระดับหนึ่ง ซึ่งเป็นแนวคิดที่ได้รับการยอมรับ

“ความเห็นพ้องเกี่ยวกับการพัฒนาเพิ่มเติมและการเพิ่มค่าตอบแทน” และ “การทำสัญญาเริ่มแรก” เป็นปัญหาที่แตกต่างกัน

นอกจากนี้ จุดสำคัญเกี่ยวกับปัญหาเหล่านี้คือ

1. “ในตอนแรก สัญญาเกี่ยวกับการพัฒนาระบบระหว่าง 2 บริษัท (สัญญาเริ่มแรก) ได้ทำขึ้นอย่างเป็นทางการหรือไม่”
2. “หลังจากที่สัญญาการพัฒนาระบบได้ทำขึ้นอย่างเป็นทางการ สัญญาเกี่ยวกับการพัฒนาเพิ่มเติมได้ทำขึ้นเพิ่มเติมหรือไม่”

ในที่นี้ มาตรฐานการตัดสินของศาลจะแตกต่างกัน ถ้าพูดอย่างกระชับ ศาลจะ

• สำหรับ 1 มีแนวโน้มที่เข้มงวด (ในสถานการณ์ที่ไม่มีสัญญา ศาลจะไม่ยอมรับการทำสัญญาได้ง่าย)
• สำหรับ 2 มีแนวโน้มที่ค่อนข้างยืดหยุ่น (แม้ว่าจะไม่มีสัญญาเกี่ยวกับการพัฒนาเพิ่มเติม ศาลยังจะยอมรับการเพิ่มค่าตอบแทนและอื่น ๆ อย่างยืดหยุ่น)

สามารถกล่าวได้ สำหรับ 1 มีบทความอื่นที่อธิบายรายละเอียด

https://monolith.law/corporate/system-development-contract[ja]

ตัวอย่างการปฏิเสธ: กรณีที่ถูกพิจารณาว่ารวมอยู่ในเนื้อหาของสัญญาในทางกฎหมาย

อย่างไรก็ตาม, ยังมีตัวอย่างคดีที่ไม่ได้รับการเพิ่มค่าตอบแทนด้วย ในกรณีที่อ้างอิงในคำพิพากษาด้านล่างนี้, สัญญาการพัฒนาระบบได้ถูกทำขึ้นหลังจากที่เนื้อหาของงานได้ถูกเปลี่ยนแปลง จึงเกิดข้อพิพาทว่าควรจะได้รับการเพิ่มค่าตอบแทนหรือไม่

ประเด็นข้อพิพาทในกรณีนี้คือ (1) งานที่ผู้ฟ้องได้รับมอบหมายในสัญญานี้คืออะไร (2) สำหรับงานที่ได้รับมอบหมายดังกล่าว, ผู้ฟ้องและผู้ถูกฟ้องได้ตกลงเพิ่มขนาดและเพิ่มค่าตอบแทนหรือไม่ (ตัดออก)… จุดนี้เป็นประเด็น (ตัดออก)…

เริ่มแรก, สัญญานี้เป็นสัญญาที่ตกลงว่าจะใช้ค่าตอบแทนเป็นค่าตอบแทนที่แน่นอนสำหรับงานที่ได้รับมอบหมาย (สัญญา) จำนวนขั้นตอน, ราคาต่อหน่วย และอื่น ๆ เป็นเพียงเอกสารภายในที่ใช้ในการคำนวณค่าตอบแทนสัญญาภายในองค์กรของผู้ฟ้อง สถานการณ์ที่จำนวนขั้นตอนเพิ่มขึ้นไม่เกี่ยวข้องกับค่าตอบแทนสัญญาเลย (ตัดออก)…

ตามที่ได้รับการยืนยันดังกล่าว, งานที่ผู้ฟ้องได้รับมอบหมายได้ถูกเปลี่ยนแปลงในวันที่ 25 กุมภาพันธ์ พ.ศ. 2530 (1987), การจัดการระบบ, การคำนวณค่าใช้จ่ายของงานที่รับเหมาและบางส่วนของยูทิลิตี้ถูกจำกัดไว้ และส่วนที่เหลือจะเป็นหน้าที่ของผู้ถูกฟ้อง งานของผู้ฟ้องหลังจากการเปลี่ยนแปลงนี้ยังคงอยู่ในขอบเขตของงานพัฒนาตามสัญญาเริ่มแรก ค่าตอบแทนสำหรับงานนี้คือค่าตอบแทนที่ได้รับการยืนยันตั้งแต่เริ่มสัญญาและได้รับการครอบคลุมทั้งหมดด้วยค่าตอบแทนที่ได้รับมอบหมาย

คำพิพากษาศาลแขวงโตเกียว วันที่ 12 มิถุนายน พ.ศ. 2538 (1995)

ในคำพิพากษานี้, แม้ว่าเนื้อหาของงานที่มอบหมายให้แก่ผู้ขายจะถูกเปลี่ยนแปลง, แต่เนื้อหาของการพัฒนายังคงอยู่ในขอบเขตของสัญญาเริ่มแรก และถูกตัดสินว่าควรจะได้รับการครอบคลุมด้วยค่าตอบแทนที่ได้รับการสัญญาตั้งแต่แรก

ในที่สุด, ค่าตอบแทนถูกตัดสินตามงานที่คาดว่าจะทำ และสำหรับงานที่ไม่รวมอยู่ในนั้น, จะยอมรับการเรียกเก็บค่าตอบแทนเพิ่มเติม นี่คือทัศนคติที่ควรจะมี

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

https://monolith.law/corporate/the-minutes-in-system-development[ja]

การกำหนดค่าตอบแทนสำหรับการพัฒนาเพิ่มเติมและการแก้ไขฟังก์ชัน

ในสถานที่ทำงานของการพัฒนาระบบ การเปลี่ยนแปลงข้อกำหนดที่ดูเหมือนจะถูกยืนยันแล้วในภายหลังไม่ใช่เรื่องแปลกประหลาด ทุกครั้งที่เกิดเหตุการณ์เช่นนี้ การเตรียมสัญญาเป็นลายลักษณ์อักษรใหม่และการดำเนินการสัญญาอาจจะไม่เป็นไปได้ ในกรณีที่สามารถยืนยันข้อกำหนดใหม่และทำสัญญาเพิ่มเติมได้ แต่ถ้าไม่สามารถดำเนินการเหล่านี้ได้และโครงการล้มเหลว ควรคำนวณค่าตอบแทนอย่างไร?

สำหรับกรณีเช่นนี้ ควรอ้างอิงถึงข้อความในกฎหมายการค้าข้อที่ 512 ดังนี้ (ขีดเส้นใต้คือส่วนที่ผู้เขียนได้ขีดเส้นใต้)

กฎหมายการค้าข้อที่ 512: เมื่อผู้ค้าทำการกระทำใดๆในขอบเขตธุรกิจของตนเพื่อผู้อื่น ผู้ค้าสามารถเรียกร้องค่าตอบแทนที่เหมาะสม

ปัญหาที่เกิดขึ้นในข้อความนี้คือ “ค่าตอบแทนที่เหมาะสม” ในสถานการณ์ที่เจาะจง จะเท่ากับเท่าใด จากตัวอย่างคดีที่ผ่านมา มีการใช้วิธีคิดที่คำนึงถึงเวลาทำงาน ปริมาณงาน หรือระยะเวลา และควรรับผิดชอบค่าใช้จ่าย นี่เป็นเพราะงานพัฒนาระบบเป็นบริการและค่าใช้จ่ายหลักคือค่าแรงงาน

ดังนั้น แม้ว่าคำว่า “ค่าตอบแทนที่เหมาะสม” ในกฎหมายการค้าจะมีความคลุมเครือ แต่ในบริบทนี้ การประมาณการค่าตอบแทนเพิ่มเติมไม่ได้ต้องการการคำนวณที่ซับซ้อน ต่อไปนี้ จะมีการดูตัวอย่างคดีบางราย

กรณีที่ 1: ตัวอย่างของการยอมรับค่าตอบแทนเพิ่มเติมที่สอดคล้องกับการเพิ่มขึ้นของจำนวนชั่วโมงที่ใช้ในการทำงาน

จำนวนชั่วโมงที่ใช้ในการพัฒนาตามการเปลี่ยนแปลงของข้อกำหนดในคดีนี้ควรถือว่าเหมาะสมที่ 257.5 ชั่วโมง/วัน ซึ่งเป็นผลรวมของจำนวนชั่วโมงที่กล่าวมาแล้ว และถ้าเราแปลงค่านี้เป็นค่าใช้จ่ายในการพัฒนาต่อคนต่อวัน โดยใช้ค่าใช้จ่ายในการพัฒนาต่อคนต่อวันเท่ากับ 32,500 เยน (ในส่วนของ กะ 3, ราคาต่อหน่วยคือ 650,000 เยนต่อคนต่อเดือน และถ้าเราถือว่าจำนวนวันทำงานในหนึ่งเดือนเท่ากับ 20 วัน ค่าใช้จ่ายในการพัฒนาต่อคนต่อวันจะเท่ากับ 32,500 เยน) ค่าใช้จ่ายในการพัฒนาเพิ่มเติมตามความต้องการในการเปลี่ยนแปลงข้อกำหนดในคดีนี้ควรถือว่าเหมาะสมที่ 8,368,750 เยน

คำพิพากษาศาลแขวงโอซาก้า วันที่ 29 สิงหาคม ปี 14 ของรัชกาลฮิเซย์ (2002)

คำว่า “ต่อคนต่อวัน” คือคำสำคัญ ซึ่งแสดงถึงการใช้จำนวนชั่วโมงที่ใช้ในการทำงานเป็นหลักในการคำนวณค่าตอบแทนเพิ่มเติม

กรณีที่ 2: ตัวอย่างของการยอมรับค่าตอบแทนเพิ่มเติมที่สอดคล้องกับจำนวนโปรแกรม

เมื่อพิจารณาเรื่องจำนวนเงินค่าตอบแทนที่เหมาะสมรวมถึงส่วนเพิ่มเติมในกรณีนี้ ส่วนใหญ่ของต้นทุนในการพัฒนาระบบคอมพิวเตอร์คือค่าแรงของวิศวกร และค่าแรงนั้นโดยทั่วไปจะสอดคล้องกับปริมาณโปรแกรมที่สร้างขึ้น ดังนั้น ถ้าเราหารจำนวนเงินสัญญาเริ่มต้นที่ 23,250,000 เยนด้วยจำนวนโปรแกรมที่เสร็จสิ้นถึงการตรวจสอบครั้งที่สอง 206 โปรแกรม แล้วคูณราคาต่อหน่วยของโปรแกรมนี้ด้วยจำนวนโปรแกรมที่ผ่านการตรวจสอบครั้งที่สาม 414 โปรแกรม เราจะได้จำนวนเงินที่เท่ากับ 46,725,728 เยน (23,250,000 ÷ 206 × 414 = 46,725,728) ซึ่งถือว่าเป็นจำนวนที่เหมาะสม

คำพิพากษาศาลแขวงโตเกียว วันที่ 22 เมษายน ปี 17 ของรัชกาลฮีเซย์ (2005)

อาจมีตัวเลขออกมาเยอะ แต่ถ้าคุณอ่านอย่างสงบ คุณจะเห็นว่าไม่ได้ทำการคำนวณที่ซับซ้อนอะไร พวกเราเพียงแค่ตรวจสอบ “ราคาต่อหน่วยของโปรแกรมที่เราได้ประเมินไว้เท่าไหร่” ตามเนื้อหาของสัญญาเริ่มต้น แล้วทำการคูณ “ราคาต่อหน่วย × ปริมาณ” ซึ่งเป็นการคูณที่ง่ายมากเท่านั้นเอง

กรณีที่ 3: ตัวอย่างของการยอมรับค่าตอบแทนเพิ่มเติมที่สอดคล้องกับระยะเวลา

และในสัญญาของผู้ฟ้อง ค.ส.3 ที่กำหนดค่าตอบแทนสำหรับงานที่ทำในฐานะผู้รับมอบหมายระหว่างเดือนมกราคมถึงมีนาคม ปี 2005 (ฮ.17) ในระยะเวลา 3 เดือน จำนวน 60 ล้านเยน ในขณะที่งานที่ทำหลังจากเดือนเมษายนของปีเดียวกันจะไม่มีค่าตอบแทน อย่างไรก็ตาม ในปีก่อนหน้านี้ จำนวนงานที่เพิ่มขึ้นหลังจากเดือนมีนาคมเนื่องจากเริ่มต้นของภาคเรียนใหม่และการทำงานของระบบลงทะเบียนเรียน ฯลฯ ในเดือนเมษายนของปีเดียวกันถูกคาดการณ์ไว้ ดังนั้น จากเหตุการณ์เหล่านี้ ค่าตอบแทนสำหรับงานในระยะเวลา 3 เดือน ที่กำหนดไว้เป็น 60 ล้านเยน ควรเป็นพื้นฐานในการคำนวณค่าตอบแทนสำหรับงานที่ทำระหว่างเดือนเมษายนถึงกันยายน ปี 2005 (ฮ.17) ในระยะเวลา 6 เดือน ซึ่งควรเป็นจำนวน 120 ล้านเยน

คำพิพากษาศาลแขวงโตเกียว วันที่ 22 มกราคม 2010 (ฮ.22)

คำพิพากษาดังกล่าวแสดงว่า สำหรับระยะเวลาที่ขยายออกไป ค่าตอบแทนเพิ่มเติมจะถูกคำนวณโดยใช้การคำนวณอัตราส่วนที่เรียบง่าย

สรุป

ดังที่ได้กล่าวไว้ข้างต้น หากเรามาดูตัวอย่างคดีที่ผ่านมาบางราย จะเห็นได้ว่ามีความเป็นกฎหมายที่เป็นระบบและมีจุดร่วมกันในการจัดการกับค่าตอบแทนเพิ่มเติมสำหรับงานของโปรแกรมเมอร์และวิศวกร นั่นคือ ในหลักการ ค่าตอบแทนจะถูกคำนวณอย่างง่ายๆ โดยอาศัยตัวชี้วัดที่มีความเป็นกลางสูง เช่น จำนวนชั่วโมงที่ทำงาน ปริมาณงานที่ส่งมอบ (เช่น โปรแกรม) ชั่วโมงการทำงานหรือระยะเวลาที่ทำงาน

ถ้าพิจารณาจากที่ว่า การพัฒนาเพิ่มเติมและการแก้ไขฟังก์ชันนี้เกิดขึ้นเนื่องจากการล้มเหลวในการจัดลำดับขั้นตอนอย่างเข้มงวดหรือการประเมินจำนวนชั่วโมงที่ทำงานอย่างสมบูรณ์ ค่าตอบแทนเพิ่มเติมที่เกิดขึ้นจากการลงมือทำงานเพิ่มเติม หรือจากปริมาณงานที่ทำ หรือจากเวลาที่ใช้ทำงาน อาจจะดูเหมือนเรื่องที่ไม่มีรสชาติหรือความสนุกสนานอะไรเลย แต่ถ้าดูจากมุมมองของผู้รับจ้าง แม้ว่าจะมุ่งหมายที่การดำเนินงานที่ให้ความสำคัญกับผลประโยชน์ของลูกค้า การที่สิทธิ์เหล่านี้ได้รับการยอมรับตามกฎหมาย ก็เป็นเรื่องที่มีความหมายในด้านการจัดการกับวิกฤติ ไม่ใช่เปล่าหรือ?