กฎหมายในกรณีที่ไม่ได้รับค่าตอบแทนจากการพัฒนาระบบ
สำหรับผู้ขายที่รับงานพัฒนาระบบ ความเสี่ยงที่ใหญ่ที่สุดอาจจะเป็นสถานการณ์ที่ “แม้จะส่งมอบผลงานแล้ว แต่ผู้ใช้งานไม่จ่ายค่าตอบแทน” ค่าใช้จ่ายในการพัฒนาระบบส่วนใหญ่จะเป็นค่าแรงของบุคลากรที่มีทักษะ เช่น โปรแกรมเมอร์ ซึ่งทำให้มีค่าใช้จ่ายสูงในค่าแรงบ่อยครั้ง การไม่สามารถรับคืนรายได้อาจจะกลายเป็นปัญหาที่เกี่ยวข้องกับการดำรงชีวิตได้ ในบทความนี้ เราจะอธิบายเรื่องที่ผู้ขายควรพิจารณาในกรณีที่ผู้ใช้งานไม่ตอบสนองการชำระค่าตอบแทน จากมุมมองทางกฎหมาย
ขั้นแรก ต้องตรวจสอบว่าสามารถเรียกเก็บค่าตอบแทนได้หรือไม่
- ผู้ขายได้ส่งมอบผลงานให้กับผู้ใช้แล้ว แต่ผู้ใช้ไม่ยอมรับการส่งมอบ ทำให้การเรียกเก็บค่าตอบแทนติดขัด
- ถึงแม้จะมีความเข้าใจว่าการตรวจรับเสร็จสิ้นแล้ว แต่ยังมีความขัดแย้งใด ๆ ระหว่างความเข้าใจของผู้ใช้ ทำให้ไม่ยอมจ่ายค่าตอบแทน
สถานการณ์เหล่านี้เป็นสิ่งที่เกิดขึ้นได้ในความเป็นจริง
นอกจากนี้ การที่ผู้ใช้ตรวจสอบข้อกำหนดของระบบที่สร้างขึ้นและยอมรับการส่งมอบ ในภาษาของการพัฒนาระบบ จะเรียกว่า “การตรวจรับ” ความหมายและความสำคัญของการตรวจรับนี้ และสิ่งที่ควรพิจารณาเมื่อความคืบหน้าไม่ดี ได้รับการอธิบายอย่างละเอียดในบทความด้านล่างนี้
บทความที่เกี่ยวข้อง: การตรวจรับการพัฒนาระบบและการประยุกต์ใช้ข้อกำหนดการตรวจรับโดยคิดเองคืออะไร
การอธิบายทั่วไปเกี่ยวกับการตรวจรับเองจะมอบให้กับบทความด้านบน แต่จากมุมมองทางกฎหมาย ต้องพิจารณาว่าการตรวจรับของผู้ใช้เสร็จสิ้นหรือไม่ โดยพิจารณาข้อกำหนด “การตรวจรับโดยคิดเอง”
โดยคำนึงถึงจุดนี้ สิ่งที่ควรพิจารณาเป็นอันดับแรกเมื่อมีปัญหาว่าผู้ใช้ไม่จ่ายค่าตอบแทนคือดังต่อไปนี้
- งานเสร็จสิ้นแล้วหรือยังไม่เสร็จ
- สามารถใช้ความรับผิดชอบในการรับประกันความบกพร่อง (ภาคภูมิศาสตร์ 635) หรือไม่
เหตุผลที่ควรตรวจสอบสองประเด็นด้านบนเป็นอันดับแรกคือ ถ้างานยังไม่เสร็จสิ้น และไม่มีการใช้ความรับผิดชอบในการรับประกันความบกพร่อง (ภาคภูมิศาสตร์ 635) ถ้าไม่ได้ตรวจสอบล่วงหน้า แม้จะยื่นฟ้องก็ไม่คาดหวังได้ว่าจะได้รับการจ่ายค่าตอบแทน
ดังนั้น ผู้รับผิดชอบของผู้ขายควรตรวจสอบอะไรเพื่อพิจารณาสองประเด็นด้านบน ต่อไปนี้เราจะมาดูว่ามีเอกสารที่ควรตรวจสอบอะไรบ้าง
เอกสารที่ควรตรวจสอบเพื่อตรวจสอบความเป็นไปได้ในการเรียกเก็บค่าตอบแทน
| ใบส่งของ หากไม่มีใบส่งของ จะถือว่าการส่งมอบยังไม่เสร็จสิ้น และงานยังไม่เสร็จสิ้น ซึ่งเป็นปัจจัยที่ทำให้การสมมุติว่างานยังไม่เสร็จสิ้นมีความแรงขึ้น |
| เอกสารแจ้งผลการตรวจรับ เป็นเอกสารที่สำคัญที่สุดในการตัดสินใจว่างานที่เสร็จสิ้นนั้นสามารถถือว่าเสร็จสิ้นได้หรือไม่ นอกจากนี้ หากมีเหตุการณ์ที่การตรวจรับถูกเลื่อนออกไปเนื่องจากสาเหตุของผู้ใช้ ควรตรวจสอบว่ามีการระบุ “ข้อกำหนดการตรวจรับที่ถือว่า” อย่างไรบนสัญญา |
| ตารางการจัดการปัญหา เป็นเอกสารที่ใช้ในการทราบว่าปัญหาอะไรบ้างที่พบและมีการจัดการอย่างไร นอกจากนี้ยังเป็นเอกสารที่ใช้ในการทราบสถานะของปัญหาและการแก้ไขที่เกิดขึ้นหลังจากการส่งมอบ |
| เอกสารการกำหนดข้อกำหนด และเอกสารการออกแบบ รวมถึงเอกสารการจัดการการเปลี่ยนแปลงและบันทึกการประชุมต่างๆ เป็นเอกสารที่ใช้ในการชัดเจนว่าผู้ใช้และผู้ขายมีความเข้าใจอย่างไรในตอนแรก ซึ่งจะช่วยให้เราสามารถระบุได้ว่าสิ่งใดควรถือว่าเป็นปัญหาหรือข้อบกพร่อง |
นอกจากนี้ วิธีการจัดการการเปลี่ยนแปลงของระบบที่ควรพัฒนา และวิธีการสร้างเอกสารการจัดการการเปลี่ยนแปลง จะได้รับการอธิบายอย่างละเอียดในบทความอื่น
บทความที่เกี่ยวข้อง: การจัดการการเปลี่ยนแปลงในการพัฒนาระบบจากมุมมองทางกฎหมายคืออะไร
| เอกสารแจ้งการยกเลิกหรือเอกสารที่บันทึกความประสงค์ของผู้ใช้ เป็นวิธีที่ใช้ในการทราบว่าผู้ใช้มีเจตนาอย่างไรเกี่ยวกับการไม่ดำเนินการตรวจรับ (หรือการไม่จ่ายค่าตอบแทน) |
ตรวจสอบว่าสามารถเรียกเก็บค่าตอบแทนได้เท่าไหร่
หลักการทั่วไปคือ จำนวนเงินที่สามารถเรียกเก็บได้จะถูกระบุไว้ในสัญญา แต่ในกรณีที่มีการเปลี่ยนแปลงข้อกำหนดหรือการเพิ่มฟังก์ชันหลังจากนั้น อาจจะไม่มีสัญญาที่ชัดเจน (หรือเอกสารที่เทียบเท่า) ที่เหลืออยู่ วิธีการคำนวณใหม่ของการประเมินค่าใช้จ่ายที่เกิดจากเหตุผลที่เกิดขึ้นภายหลัง เช่น การเปลี่ยนแปลงข้อกำหนด การเพิ่มฟังก์ชัน จะได้รับการอธิบายอย่างละเอียดในบทความต่อไปนี้
บทความที่เกี่ยวข้อง: การเพิ่มจำนวนเงินประเมินในการพัฒนาระบบหลังจากนั้นเป็นไปได้หรือไม่
วิธีการคำนวณใหม่ของการประเมินค่าใช้จ่ายตามที่อธิบายในบทความนี้ โดยเฉพาะถ้าคุณกำลังพิจารณาว่าสามารถเพิ่มจำนวนเงินที่เรียกเก็บได้หรือไม่ คุณควรพิจารณาดังต่อไปนี้:
- การมีหรือไม่มีใบเสนอราคาและเนื้อหาของการพัฒนาเพิ่มเติมและการแก้ไขฟังก์ชัน
- การตอบสนองของผู้ใช้ต่อใบเสนอราคา
- การมีหรือไม่มีข้อตกลงเกี่ยวกับจำนวนเงินที่เกิดจากสถานการณ์ที่ทำให้เกิดการพัฒนาเพิ่มเติมและการแก้ไขฟังก์ชันที่ระบุไว้ในตารางการจัดการปัญหา
จุดสำคัญคือ คุณต้องตรวจสอบว่ามีการตรงกันของความประสงค์ระหว่างผู้ใช้และคุณในเรื่องของ “การสั่งซื้องานด้วยจำนวนเงินนี้” หรือไม่ (นั่นคือ สามารถกล่าวได้ว่าสัญญาได้รับการทำขึ้นแล้วหรือไม่)
สุดท้าย พิจารณาประเด็นที่น่าสนใจในกรณีที่ดำเนินคดีจริง
ระวังความเป็นไปได้ที่จะถูกยื่นคำขอฟ้องคืน
ในการพัฒนาระบบ หากผู้ใช้หรือผู้ขายอย่างใดอย่างหนึ่งยื่นฟ้องต่ออีกฝ่าย มักจะมีกรณีที่ถูกยื่นคำขอฟ้องคืนจากอีกฝ่าย นั่นคือ ในสถานการณ์ที่ไม่ชำระค่าตอบแทน ฝ่ายผู้ใช้ก็อาจมีข้ออ้างอันหนึ่งอันใด
เริ่มแรก การพัฒนาระบบ ฝ่ายผู้ใช้จะต้องรับผิดชอบในหลายๆ ด้าน แต่สิ่งที่ควรจำเป็นคือ ฝ่ายผู้ขายเป็นผู้เชี่ยวชาญในการพัฒนาระบบ มีอำนาจในการตัดสินใจอย่างกว้างขวางและรับผิดชอบที่ใหญ่ ส่วนหน้าที่การจัดการโปรเจคที่ฝ่ายผู้ขายต้องรับผิดชอบในการพัฒนาระบบ ได้รับการอธิบายอย่างละเอียดในบทความด้านล่างนี้
บทความที่เกี่ยวข้อง: หน้าที่การจัดการโปรเจคในการพัฒนาระบบคืออะไร
นั่นคือ สิ่งที่ควรพิจารณาล่วงหน้าคือ สามารถยื่นข้ออ้างว่าฝ่ายผู้ใช้ที่ไม่ชำระค่าตอบแทนเป็นฝ่ายผิดหรือไม่ จากตัวอย่างคดีที่ผ่านมา แม้ว่าฝ่ายผู้ขายจะยื่นคำขอเรียกเก็บค่าตอบแทนและยื่นฟ้องในตอนแรก แต่ฝ่ายผู้ใช้ก็ยื่นข้ออ้างคืน ทั้งหน้าที่ในการคืนสภาพเดิมและคำขอค่าเสียหาย
ควรพิจารณาว่าจริงๆ แล้วมีประโยชน์ในด้านธุรกิจหรือไม่
ถ้าสมมุติว่าฝ่ายผู้ขายมีข้ออ้างที่ถูกต้อง และสถานะที่สามารถเรียกเก็บค่าตอบแทนได้จริงถูกยอมรับในคดี แต่ถ้าสถานการณ์ทำให้ต้องฟ้อง การดำเนินการธุรกิจต่อไปอาจจะยากขึ้น นอกจากนี้ แม้ว่าคำอ้างของตนเองจะถูกยอมรับในคดี แต่อาจจะต้องใช้เวลานานก่อนที่จะได้รับค่าตอบแทนจริงๆ ควรเตรียมตัวสำหรับเวลาที่จะใช้ในการฟ้อง และค่าใช้จ่ายที่ไม่น้อยที่ต้องใช้ในการฟ้อง ถ้าคิดถึงสิ่งเหล่านี้ การพยายามหาจุดที่สามารถทำความตกลงได้อาจจะเป็นทางออกที่ดีกว่า
สรุป
หากผู้ใช้งานไม่ยินยอมที่จะชำระค่าตอบแทน การพิจารณาปัญหานี้ในทางกฎหมายจะต้องตรวจสอบเอกสารหลายประเภท นอกจากนี้ การจัดการเอกสารอย่างละเอียดเพียงอย่างเดียวก็ไม่เพียงพอ คุณยังต้องพิจารณาว่าหากคุณตัดสินใจฟ้องร้องในที่สุด องค์กรของคุณจะต้องเผชิญกับความเสี่ยงและข้อเสียอย่างไร
การจัดการเอกสารอย่างเข้มงวดในชีวิตประจำวันอาจจะเป็นงานระดับสถานที่ทำงานทั่วไป แต่ถ้าคุณตัดสินใจที่จะฟ้องร้องโดยอาศัยเอกสารและข้อมูลที่เก็บรักษาไว้ นั่นอาจจะเป็นการตัดสินใจทางธุรกิจที่สำคัญ ในสถานการณ์ที่ไม่ปกติเช่นนี้ ความสามารถในการรวมกลุ่มและความสามารถในการจัดการของทีมงานและทีมบริหารจะถูกทดสอบ คุณควรทราบถึงกระบวนการทั้งหมดนี้
Category: IT
Tag: ITSystem Development
