ซื้อซอฟต์แวร์สำเร็จรูปหรือสั่งพัฒนาเอง เลือกอย่างไรให้คุ้ม

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

เปรียบเทียบสองทางเลือก

เกณฑ์ตัดสินใจ 4 ข้อ

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

ค่าใช้จ่ายจริงตลอด 5 ปีต่างกันแค่ไหน

การเทียบเฉพาะราคาเริ่มต้นทำให้ตัดสินใจผิดได้ง่าย เพราะซอฟต์แวร์สำเร็จรูปคิดค่าบริการต่อเนื่อง ส่วนการพัฒนาเองจ่ายก้อนใหญ่ครั้งเดียวแล้วเหลือค่าดูแล วิธีเทียบที่ตรงกว่าคือคิดรวมตลอดอายุการใช้งาน สมมติองค์กรมีผู้ใช้ 60 คน และซอฟต์แวร์สำเร็จรูปคิด 200 บาทต่อคนต่อเดือน ค่าใช้จ่ายจะอยู่ที่ประมาณ 144,000 บาทต่อปี หรือ 720,000 บาทใน 5 ปี ขณะที่การพัฒนาเองอาจอยู่ที่ 400,000 บาทตอนเริ่ม บวกค่าดูแลปีละ 60,000 บาท รวมเป็นประมาณ 640,000 บาทในช่วงเวลาเดียวกัน

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

ความเสี่ยงของแต่ละทางเลือก

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

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

ทางเลือกแบบผสมที่หลายองค์กรใช้

ไม่จำเป็นต้องเลือกอย่างใดอย่างหนึ่งทั้งองค์กร วิธีที่พบบ่อยที่สุดคือซื้อสำเร็จรูปสำหรับงานมาตรฐาน เช่น ระบบลางานออนไลน์ หรือเว็บไซต์จัดหางาน–สมัครงาน แล้วสั่งพัฒนาเฉพาะงานที่เป็นจุดแข็งของธุรกิจ จากนั้นใช้บริการเชื่อมต่อระบบและพัฒนา APIให้ข้อมูลไหลถึงกัน ซึ่งได้ทั้งความเร็วในการเริ่มใช้และความยืดหยุ่นในส่วนที่สำคัญ ผู้ประกอบการ SME ที่กำลังเริ่มนำซอฟต์แวร์มาใช้สามารถตรวจสอบมาตรการสนับสนุนที่มีอยู่ได้จากสำนักงานส่งเสริมเศรษฐกิจดิจิทัล (depa)

สัญญาณว่าถึงเวลาเลิกฝืนซอฟต์แวร์สำเร็จรูป

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

ประเมินผู้พัฒนาอย่างไรถ้าจะสั่งทำ

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

เริ่มจากส่วนไหนก่อนถึงจะเสี่ยงน้อยที่สุด

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

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

ขั้นตอนถัดไป

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

สรุปเลือกอย่างไรให้ไม่เสียใจภายหลัง

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