นี่คือตัวเลขที่ผู้บริหารทุกคนควรหยุดคิดก่อนเซ็นอนุมัติงานพัฒนาซอฟต์แวร์ custom: โดยเฉลี่ยโปรเจกต์ IT ขนาดใหญ่ใช้งบเกิน 45% ใช้เวลาเกิน 7% และส่งมอบคุณค่าน้อยกว่าที่คาดไว้ถึง 56% ตัวเลขนี้มาจาก McKinsey และมหาวิทยาลัย Oxford ที่ศึกษาโปรเจกต์มากกว่า 5,400 โปรเจกต์ งบที่บานปลายรวมกันสูงถึง 66 พันล้านดอลลาร์
True Dev สร้างซอฟต์แวร์ custom เป็นอาชีพ แต่คำแนะนำที่มีค่าที่สุดที่เราให้ลูกค้าบ่อยครั้งกลับเป็น: อย่าเพิ่งสร้าง การตัดสินใจระหว่าง build-buy-customise คือจุดที่งบประมาณซอฟต์แวร์ส่วนใหญ่สูญเปล่าอย่างเงียบ ๆ และสาเหตุมักเหมือนเดิมเสมอ — บริษัทเลือกคำตอบตามความเคยชิน แทนที่จะตัดสินใจอย่างตั้งใจ
บริษัทส่วนใหญ่เลือกผิด — ทั้งสองทาง
มีวิธีพลาดอยู่สองแบบ และทั้งสองเป็นภาพสะท้อนของกันและกัน
แบบแรกคือ build ตามความเคยชิน ทีมที่ทะเยอทะยานตัดสินใจว่าเพราะธุรกิจของตนไม่เหมือนใคร ซอฟต์แวร์ก็ต้องไม่เหมือนใครด้วย จึงสร้าง CRM ระบบออกใบแจ้งหนี้ เครื่องมือภายใน — สิ่งที่ผู้ให้บริการนับพันรายทำได้ดีอยู่แล้ว งานวิจัย CHAOS ของ Standish Group พบว่าโปรเจกต์ซอฟต์แวร์ขนาดใหญ่สำเร็จไม่ถึง 10% ขณะที่โปรเจกต์เล็กและโฟกัสชัดสำเร็จราว 90% การสร้างระบบทั่วไปจากศูนย์คือวิธีที่แพงที่สุดในการได้มาซึ่งฟังก์ชันธรรมดา
แบบที่สองคือ buy ตามความเคยชิน ซึ่งแพงพอ ๆ กัน — เพียงแต่ซ่อนตัวได้ดีกว่า บริษัททั่วไปในวันนี้ใช้ SaaS ราว 130 แอปพลิเคชัน ตาม งานวิจัยด้านการจัดการ SaaS แต่ละตัวแก้ปัญหาจริงในวันแรก แต่เมื่อรวมกันกลับสร้างความรกของค่าสมาชิก ฟีเจอร์ที่ทับซ้อน และงาน integration ที่ไม่มีใครเป็นเจ้าของ การซื้อรู้สึกปลอดภัยเพราะค่าใช้จ่ายน้อยและจ่ายรายเดือน แต่ยอดรวมในอีกสามปีข้างหน้ากลับไม่ใช่ทั้งสองอย่าง
ต้นทุนที่ซ่อนอยู่ไม่เคยอยู่บนใบแจ้งหนี้
ไม่ว่าคุณจะเอนไปทางไหน ราคาบนป้ายคือตัวเลขที่น่าสนใจน้อยที่สุด ราว 65% ของต้นทุนรวมของระบบซอฟต์แวร์เกิดขึ้น หลัง การเปิดใช้งานครั้งแรก — ทั้งการดูแลรักษา integration การฝึกอบรม การอัปเกรด และภาษีที่ค่อย ๆ จ่ายไปกับการทำงานอ้อมสิ่งที่เกือบจะพอดี
ข้อเท็จจริงเดียวนี้เปลี่ยนมุมมองทั้งการตัดสินใจ งาน custom ไม่ใช่ใบแจ้งหนี้ครั้งเดียว แต่เป็นพันธะระยะยาวในการดูแลบางสิ่ง ส่วนค่าสมาชิก SaaS ไม่ใช่ค่าใช้จ่ายรายเดือนคงที่ แต่เป็นราคาที่มักไต่ขึ้น roadmap ที่คุณควบคุมไม่ได้ และข้อมูลที่คุณอาจดึงออกมาได้ยาก การเปรียบเทียบที่ตรงไปตรงมาคือต้นทุนรวมในการเป็นเจ้าของตลอด 3–5 ปี ไม่ใช่ใบเสนอราคาที่อยู่ตรงหน้าวันนี้
กรอบที่ตัดสินใจได้จริง
ตัดเสียงรบกวนออก แล้วสามคำถามจะคลี่คลายเคสส่วนใหญ่ได้
1. สิ่งนี้คือจุดต่างหลัก หรือเป็นแค่ระบบพื้นฐาน? ถ้าซอฟต์แวร์ คือ ความได้เปรียบในการแข่งขัน — สิ่งที่ลูกค้าจ่ายเงินให้คุณ — ก็ build ถ้าเป็นระบบพื้นฐานที่ทุกธุรกิจต้องมี (อีเมล บัญชี เงินเดือน CRM ทั่วไป) ก็ buy อย่า build สิ่งที่ซื้อได้เพื่อดำเนินธุรกิจ แต่ build สิ่งที่ทำให้ธุรกิจมีคุณค่าพอจะดำเนินต่อ
2. เครื่องมือสำเร็จรูปตอบโจทย์ 80% ขึ้นไปได้แล้ววันนี้ไหม? ถ้าใช่ ก็ buy แล้วปรับกระบวนการของคุณเล็กน้อย ถ้าตอบโจทย์ 50–80% ก็ customise — ตั้งค่าและต่อยอดแพลตฟอร์มที่พิสูจน์แล้ว แทนการเริ่มจากศูนย์ ถ้าต่ำกว่า 50% และเป็นงานหลักจริง ๆ เท่านั้น จึง build
3. ความต้องการนี้จะยังเป็นจริงในอีกสามปีไหม? ความต้องการที่นิ่งและเข้าใจชัดเหมาะกับการซื้อ ส่วนความต้องการที่เปลี่ยนเร็วและแตกต่างจริง ๆ คุ้มที่จะสร้าง ถ้าคุณตอบคำถามนี้ไม่ได้ แสดงว่ายังไม่พร้อมตัดสินใจ — และการรู้ตัวก่อนจ่ายเงินก็เป็นเรื่องดี
ทำไมบางครั้งเราถึงบอกลูกค้าว่าไม่ต้องจ้างเรา
True Dev สร้างซอฟต์แวร์มาตั้งแต่ปี 1997 นานพอที่จะได้เห็นโปรเจกต์ custom จำนวนมากที่จริง ๆ แล้วควรเป็นแค่ค่าสมาชิกเดือนละไม่กี่ร้อยบาท และได้เห็นค่าสมาชิกหลายตัวที่เอามาแปะต่อกันทั้งที่ระบบที่สร้างมาดีตัวเดียวจะคุ้มทุนภายในหนึ่งปี
ดังนั้นเมื่อลูกค้าขอให้เรา build งานแรกของเราคือการตั้งคำถามกับสมมติฐานนั้น บางครั้งคำตอบคือระบบ custom ที่สะอาด เพราะความต้องการเป็นของเขาจริง ๆ บางครั้งคือ "ซื้อเครื่องมือตัวนี้ เราจะ integrate ให้ แล้วเก็บงบไว้กับส่วนที่ไม่เหมือนใครจริง ๆ" คำแนะนำที่ตรงไปตรงมาบางครั้งทำให้เราเสียโปรเจกต์ไป แต่ไม่เคยทำให้เราเสียลูกค้า
หากคุณกำลังชั่งใจระหว่าง build, buy หรือ customise เริ่มโปรเจกต์กับเรา แล้วเราจะช่วยคุณตัดสินใจก่อนที่ใครจะเขียนโค้ดสักบรรทัด — หรือดูว่าเรา ทำงานกับซอฟต์แวร์ ตลอดทั้งวงจรอย่างไร
