เมื่อ ERP ที่พัฒนาเอง กลายเป็นภาระของทั้งบริษัท

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

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

ต้นทุนที่ไม่เคยปรากฏในงบประมาณ

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

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

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

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

เปลี่ยนคำถามจากเทคโนโลยีเป็นความต่อเนื่อง

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

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