ซอฟต์แวร์ไม่ตอบโจทย์ หรือองค์กรยังไม่พร้อมเปลี่ยนวิธีทำงาน?

ซอฟต์แวร์ไม่ตอบโจทย์ หรือองค์กรยังไม่พร้อมเปลี่ยนวิธีทำงาน?

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

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

คำถามสำคัญไม่ใช่ได้กี่เปอร์เซ็นต์ แต่ส่วนที่ขาดสำคัญแค่ไหน

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

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

เหตุการณ์ที่ทำให้ผมคิดเรื่องนี้มากขึ้น

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

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

คำว่าไม่ตอบโจทย์ อาจซ่อนปัญหาคนละชนิด

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

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

ผู้บริหารซื้อระบบได้ แต่จ้างคนอื่นเปลี่ยนองค์กรแทนทั้งหมดไม่ได้

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

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

เริ่มเล็ก แต่ต้องเริ่มจากงานจริง

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

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