ทำไมการไล่ตามความเร็วจึงสร้างปัญหา软件ในอนาคต

ความกดดันที่จะส่งมอบ ERP และซอฟต์แวร์ธุรกิจที่สำคัญให้เร็วขึ้น มักสร้างค่าใช้จ่ายที่ซ่อนอยู่ที่องค์กรจะต้องจัดการในอนาคต ตามที่ Carl Andrews ซีอีโอของ Original Software กล่าว

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

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

ที่ที่หนี้เริ่มต้น

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

การปรับแต่งถูกทิ้งไว้เพราะการแทนที่มันรู้สึกว่าเป็นการรบกวนมากเกินไป

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

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

ทำไมองค์กรจึงมองข้ามปัญหา

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

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

ผลลัพธ์คือหนี้ทางเทคนิคมักได้รับความสนใจเฉพาะเมื่อมันเริ่มส่งผลกระทบต่อประสิทธิภาพทางธุรกิจ

ผลกระทบต่อนวัตกรรม ความสามารถในการผลิต และความยืดหยุ่น

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

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

การหาสมดุลที่ถูกต้อง

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

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

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

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