ปัญหาทางกฎหมายที่เกี่ยวข้องกับการย้ายจากระบบเดิมไปยังระบบใหม่ในการพัฒนาระบบ

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

การย้ายไปใช้ระบบใหม่หมายถึงอะไร

อายุของระบบ IT ไม่ได้เป็นนิรันดร์

ระบบ IT ที่ใช้ในองค์กรไม่ได้เป็นสิ่งที่สร้างขึ้นมาแล้วใช้ได้ตลอดไป และการใช้ระบบเดิมอย่างต่อเนื่องไม่ได้เป็นสิ่งที่ดีเสมอไป แน่นอนว่าจะมีความแตกต่างตามองค์กรและการใช้งานของระบบ แต่โดยประมาณ ระบบหนึ่งๆ ถ้าใช้มานานถึงประมาณ 10 ปี การตัดสินใจในการจัดการที่ดีที่สุดคือการเปลี่ยนเป็นระบบใหม่

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

ระบบที่เก่ามากๆ อาจทำให้วิศวกร IT ต้องทำงานด้วยมือมากขึ้น (เช่น การสร้างคิวรีสำหรับการดึงข้อมูลเฉพาะ) และเมื่อระบบเก่าขึ้น มันก็จะทำให้งานกลายเป็น “งานที่ขึ้นอยู่กับบุคคล” ในทางตรงกันข้าม หากมีงานที่เกี่ยวข้องกับระบบที่มีงานที่ขึ้นอยู่กับบุคคลมากขึ้นเนื่องจากระบบที่เก่าเกินไป และต้องการที่จะใช้ “ระบบ” เพื่อจัดการงานเหล่านี้ จะต้องมีโครงการ “การพัฒนาระบบใหม่เพื่อการย้ายจากระบบเดิม” ที่จะเริ่มต้นขึ้น

การพัฒนาระบบใหม่จะเดินหน้าไปพร้อมกับการยกเลิกระบบเก่า

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

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

ขั้นตอนในการย้ายไปยังระบบใหม่คืออะไร

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

1. ระบุข้อมูลที่ระบบเดิมเก็บรักษาว่าข้อมูลใดควรถูกย้ายไปยังระบบใหม่ → ข้อมูลที่ควรสามารถค้นหาได้ง่ายจากหน้าจอของระบบใหม่คืออะไร และข้อมูลที่ไม่จำเป็นต้องค้นหาได้จากหน้าจอ (เช่น สำหรับการตรวจสอบ) แต่ควรสามารถเรียกใช้ได้ตามความจำเป็นคืออะไร การแยกแยะนี้จำเป็นอย่างยิ่ง
2. ส่งออกข้อมูลที่ระบุไว้ในข้อ 1 ที่ควรนำเข้าระบบใหม่ในรูปแบบของไฟล์ CSV หรืออื่น ๆ
3. นำข้อมูลที่สกัดออกมาในข้อ 2 เข้าสู่ระบบใหม่
4. ตรวจสอบว่าข้อมูลที่ถูกนำเข้าโดยข้อ 3 ได้รับการสะท้อนในระบบใหม่หรือไม่ และยืนยันว่าการย้ายข้อมูลได้ถูกดำเนินการอย่างถูกต้อง → ผลการตรวจสอบว่าการย้ายข้อมูลได้ถูกดำเนินการอย่างถูกต้อง โดยปกติจะเป็นการเก็บหลักฐานโดยการแสดงผลบนหน้าจอหรือพิมพ์รายงาน (กระบวนการทดสอบทั่วไป)

การย้ายไปยังระบบใหม่ทำให้การจัดบทบาทระหว่างผู้ใช้และผู้ขายยาก

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

https://monolith.law/corporate/user-obligatory-cooporation[ja]

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

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

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

https://monolith.law/corporate/project-management-duties[ja]

ตัวอย่างคดีที่ผ่านมาเกี่ยวกับการย้ายไปยังระบบใหม่

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

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

เห็นว่าเป็นสิ่งที่เหมาะสม ในกรณีนี้ ฝ่ายผู้รับเหมามีหน้าที่ที่จะต้องแก้ไขและแก้ปัญหาข้อมูลที่ไม่สอดคล้องในการย้ายข้อมูล

คำพิพากษาศาลจังหวัดโตเกียว วันที่ 30 พฤศจิกายน พ.ศ. 2559 (2016)

ในกรณีนี้ ฝ่ายผู้ใช้รับผิดชอบขั้นตอนที่ 1 และขั้นตอนที่ 4 และฝ่ายผู้ขายรับผิดชอบขั้นตอนที่ 2 และขั้นตอนที่ 3 นั่นคือ ฝ่ายผู้ขายได้รับผิดชอบในการดึงข้อมูลจากระบบเดิม (ขั้นตอนที่ 2) ดังนั้น ศาลได้ตัดสินว่า ถ้าฝ่ายผู้ขายรับผิดชอบในการดึงข้อมูล ฝ่ายผู้ขาย (ในฐานะผู้เชี่ยวชาญในการพัฒนาระบบ) ควรจะสามารถพิจารณาล่วงหน้าว่าการดึงข้อมูลจะสามารถดำเนินการได้ราบรื่นหรือไม่

อย่างไรก็ตาม ถ้าฝ่ายผู้ใช้รับผิดชอบในขั้นตอนที่ 2 (การดึงข้อมูล) และการดึงข้อมูลล้มเหลว จะเกิดอะไรขึ้น? ในกรณีนี้ ฝ่ายผู้ใช้อาจจะถูกตั้งข้อหาว่าได้ละเว้นการสำรวจล่วงหน้าว่าการดึงข้อมูลจะสามารถดำเนินการได้ราบรื่นหรือไม่ ทำให้เกิดความล่าช้าในการส่งมอบ และฝ่ายผู้ใช้อาจจะถูกตั้นข้อหาว่าละเมิดหน้าที่ในการสนับสนุน

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

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

สรุป

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

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