ธุรกิจส่วนใหญ่มักมีอย่างน้อยหนึ่งระบบที่ทุกคนบ่นถึง ทั้งเก่า ดูล้าสมัย และมีเพียงไม่กี่คนที่เข้าใจการทำงานของมันจริงๆ ปฏิกิริยาแรกที่เกิดขึ้นคืออยากจะโละทิ้ง ซึ่งบางครั้งก็เป็นการตัดสินใจที่ถูก แต่หลายครั้งก็ยังไม่ใช่ หรืออย่างน้อยก็ยังไม่ใช่ตอนนี้
คำถามที่พยายามหาคำตอบไม่ใช่ "ระบบนี้เก่าหรือไม่?" แต่คือ "ระบบนี้ยังคงทำงานได้ตามเป้าหมายในต้นทุนที่ธุรกิจรับได้หรือไม่?"
เริ่มต้นจากสิ่งที่ผิดปกติจริงๆ
มักจะเริ่มจากปัญหาที่ผู้ใช้งานสามารถอธิบายได้ด้วยคำพูดของตนเอง เช่น การเปลี่ยนแปลงง่ายๆ กลับต้องใช้เวลาเป็นสัปดาห์ รายงานไม่ตรงกับสินค้าที่มีอยู่จริง ทุกอย่างหยุดชะงักเมื่อพนักงานคนหนึ่งลาพักร้อน เพราะเขารู้เรื่องการปิดงบเดือนเพียงคนเดียว หรือระบบล่มสองครั้งในไตรมาสที่แล้วจนคำสั่งซื้อค้างเป็นจำนวนมาก
ข้อมูลเหล่านี้มีประโยชน์เพราะเชื่อมโยงซอฟต์แวร์เข้ากับเวลาและเงินจริงๆ คำว่า "มันเก่า" ไม่ได้อยู่ในรายการนี้ ระบบที่ใช้งานมาสิบปีแต่แทบไม่ต้องแก้ไขอะไรเลยอาจมีค่าใช้จ่ายในการดูแลถูกกว่าการเปลี่ยนใหม่ ในขณะที่ระบบที่สร้างขึ้นเมื่อสองปีที่แล้วอาจกลายเป็นปัญหาได้หากธุรกิจมีการเปลี่ยนแปลงไปจากเดิม
คำนวณต้นทุนที่แท้จริงในการรักษาระบบไว้
ต้นทุนของระบบเก่ามีมากกว่าแค่ค่าโฮสติ้ง ซึ่งรวมถึง:
- เวลาที่พนักงานต้องเสียไปกับการหาวิธีเลี่ยงปัญหาและการพิมพ์ข้อมูลซ้ำซ้อน
- โครงการต่างๆ ที่ล่าช้าเพราะระบบแก้ไขได้ยาก
- เวลาที่ระบบล่มและความวุ่นวายที่ตามมา
- ความเสี่ยงด้านความปลอดภัยหากระบบไม่สามารถอัปเดตได้อีกต่อไป
- ความยากในการหาคนมาดูแลระบบ
ต้นทุนเหล่านี้มักกระจายอยู่ตามแผนกต่างๆ ทำให้ไม่มีใครเห็นภาพรวม การตรวจสอบสั้นๆ จะช่วยแก้ปัญหานี้ได้ โดยการลิสต์งานสำคัญที่ระบบทำ ใครต้องพึ่งพามันบ้าง อะไรที่เสียบ่อย และธุรกิจคาดหวังอะไรในอีกสองถึงสามปีข้างหน้า ตัวเลขคร่าวๆ ก็เพียงพอแล้ว แต่ต้องซื่อสัตย์ว่าข้อมูลส่วนไหนเป็นการคาดเดา
คุณมีทางเลือกมากกว่าแค่สองทาง
ไม่ค่อยมีการเลือกแค่ระหว่างการไม่ทำอะไรเลยกับการสร้างใหม่ทั้งหมด แต่ยังมีทางเลือกอื่นๆ เช่น:
- แก้ไขเฉพาะส่วนที่สร้างปัญหามากที่สุด
- เปลี่ยนเฉพาะบางส่วน เช่น ระบบรายงาน หรือส่วนที่เชื่อมต่อกับซอฟต์แวร์บัญชี
- สร้างเลเยอร์ที่ทันสมัยครอบส่วนที่แก้ไขยากไว้ เพื่อให้เครื่องมือใหม่ๆ สามารถทำงานร่วมกันได้
อย่างไรก็ตาม การค่อยๆ ทำทีละนิดอาจไม่ใช่คำตอบเสมอไป หากข้อมูลในระบบไม่น่าเชื่อถือ หรือระบบไม่สามารถตอบสนองความต้องการในอนาคตของธุรกิจได้ การปะผุไปเรื่อยๆ อาจเป็นการยื้อปัญหา ประเด็นสำคัญคือการตัดสินใจอย่างรอบคอบแทนที่จะทำไปตามความเคยชิน
กฎที่ไม่ได้บันทึกไว้คือส่วนที่ยากที่สุด
เมื่อต้องเปลี่ยนระบบ การสร้างหน้าจอใหม่เป็นเรื่องง่าย แต่ส่วนที่ยากคือบรรดากฎเกณฑ์เล็กๆ น้อยๆ ที่ไม่มีใครจดบันทึกไว้ เช่น ลูกค้าที่ได้ราคาพิเศษ คำสั่งซื้อที่ข้ามขั้นตอนได้ หรือไฟล์ส่งออกที่ฝ่ายบัญชีต้องใช้ทุกวันศุกร์ รายละเอียดเหล่านี้มักเป็นหัวใจสำคัญของระบบ
ก่อนจะเปลี่ยนไปใช้ระบบใหม่ จำเป็นต้องรู้ว่าข้อมูลที่เชื่อถือได้อยู่ที่ไหน จะจัดการข้อมูลซ้ำและข้อมูลเก่าอย่างไร และจะพิสูจน์ได้อย่างไรว่าระบบใหม่ให้คำตอบที่ถูกต้องเหมือนเดิม นอกจากนี้ยังควรวางแผนวิธีเปลี่ยนกลับหากเกิดข้อผิดพลาด และพิจารณาว่าจะรันระบบเก่าและใหม่ควบคู่กันไปสักระยะหรือไม่ แผนงานที่ดีต้องอธิบายได้ว่าคุณจะรู้ได้อย่างไรว่าข้อมูลนั้นถูกต้อง ไม่ใช่แค่การคัดลอกข้อมูลมาเท่านั้น
5 คำถามก่อนตัดสินใจ
ก่อนจะให้คำแนะนำใดๆ มักจะต้องการคำตอบสำหรับ 5 คำถามนี้:
- เรากำลังแก้ปัญหาอะไรที่เฉพาะเจาะจง?
- หากปล่อยไว้เหมือนเดิม จะมีต้นทุนและความเสี่ยงอย่างไร?
- ข้อจำกัดใดที่เปลี่ยนแปลงไม่ได้จริงๆ เช่น งบประมาณ กำหนดการ หรือกฎระเบียบ?
- เราจะตรวจสอบได้อย่างไรว่าแนวทางใหม่ทำงานได้อย่างถูกต้อง?
- ขั้นตอนที่เล็กที่สุดแต่มีประโยชน์คืออะไร ที่จะช่วยลดความเสี่ยงโดยไม่จำกัดทางเลือกของเราในภายหลัง?
หากคำตอบเหล่านี้ยังไม่ชัดเจน ขั้นตอนต่อไปที่เหมาะสมมักจะเป็นการตรวจสอบสั้นๆ ที่มีกำหนดเสร็จแน่นอน แทนที่จะเริ่มโครงการใหญ่ ผลลัพธ์ที่ได้ควรเป็นแผนผังระบบที่ชัดเจน รายการความเสี่ยงหลักตามลำดับความสำคัญ ทางเลือกที่เป็นไปได้ และลำดับขั้นตอนที่เหมาะสมในการจัดการ
บทสรุป
การอัปเดตซอฟต์แวร์เก่าไม่ใช่การวิ่งตามเทคโนโลยีใหม่ แต่เป็นการทำให้มั่นใจว่าระบบจะยังคงสนับสนุนธุรกิจต่อไปได้ บางครั้งนั่นหมายถึงการสร้างใหม่ แต่ส่วนใหญ่มักหมายถึงการแก้ไขในจุดที่ตรงเป้าหมาย การทำให้มองเห็นการทำงานได้ดีขึ้น และการหาแนวทางที่ปลอดภัยกว่าในการก้าวไปข้างหน้า