ปรับระบบเดิมหรือสร้างใหม่? เช็กลิสต์ก่อนตัดสินใจลงทุน

REASONING

เหตุผลที่นำไปสู่ข้อสรุป

1. 01

   เริ่มจากผลกระทบ ไม่ใช่อายุเทคโนโลยี

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

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

2. 02

   ทำแผนที่ข้อมูล การเชื่อมต่อ และความรู้ที่ผูกอยู่กับระบบ

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

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

3. 03

   เปรียบเทียบหลายทางเลือกแทนการบังคับเลือกสองขั้ว

   บางส่วนอาจคงไว้และลดความเสี่ยง บางส่วนย้าย Hosting บางส่วน Refactor หรือห่อด้วย API และบาง Capability อาจแทนด้วยผลิตภัณฑ์สำเร็จรูป การแยกตาม Domain หรือ Capability ช่วยหลีกเลี่ยงโครงการยักษ์แบบเปลี่ยนทุกอย่างพร้อมกัน

   อย่างน้อยควรมีทางเลือกฐานเดิม ทางเลือกปรับเฉพาะส่วน และทางเลือกเปลี่ยนหรือสร้างใหม่ พร้อมระบุสิ่งที่แต่ละแบบแก้ไม่ได้ ไม่ใช่เปรียบเทียบเฉพาะฟีเจอร์ที่ทำได้

4. 04

   เทียบต้นทุนรวมตลอดอายุระบบ (TCO) ไม่ใช่เฉพาะค่าพัฒนา

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

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

5. 05

   ทดสอบสมมติฐานที่แพงหรือย้อนกลับยากก่อน

   ใช้ Prototype, Data migration rehearsal, Integration spike หรือ Performance/security test กับเส้นทางสำคัญเพื่อพิสูจน์ว่าสิ่งที่เสนอทำได้จริงกับข้อมูลและข้อจำกัดขององค์กร

   กำหนดเกณฑ์ผ่าน หยุด และเปลี่ยนทางเลือกไว้ล่วงหน้า การทดลองที่ดีต้องสร้างหลักฐานสำหรับการตัดสินใจ ไม่ใช่ Demo ที่หลีกเลี่ยงกรณียาก

6. 06

   ออกแบบการเปลี่ยนผ่านและการดูแลหลังเปิดใช้เป็นส่วนเดียวกับการลงทุน

   กำหนดลำดับย้าย Cohort, Source of truth ในแต่ละช่วง, การซิงก์และตรวจยอด, Rollback, การสื่อสารผู้ใช้ และวันที่ปิดระบบเดิมอย่างมีเงื่อนไข เพื่อไม่ให้เกิดระบบคู่ขนานถาวรโดยไม่ตั้งใจ

   ระบุ Service owner, Support, Monitoring, Access review, Backup/recovery, Change control และงบดูแลหลังส่งมอบ ข้อเสนอที่ไม่มี Operating model ยังไม่ใช่ข้อเสนอที่พร้อมอนุมัติ

BUSINESS IMPLICATIONS

สิ่งที่มีผลต่อการตัดสินใจของธุรกิจ