พัฒนาระบบ ERP แบบ Custom: เช็ก Requirement ก่อนเริ่ม

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

Requirement ของ ERP คืออะไร

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

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

ข้อมูล 8 กลุ่มที่ควรเตรียมก่อนพัฒนาระบบ ERP

1. เป้าหมายธุรกิจ: ปัญหาปัจจุบัน ผลกระทบ และตัวชี้วัดที่ต้องการปรับปรุง
2. ขอบเขตองค์กร: บริษัท สาขา คลัง แผนก และกลุ่มผู้ใช้งาน
3. กระบวนการ: จุดเริ่มต้น ผู้รับผิดชอบ เอกสาร สถานะ และจุดจบของงาน
4. กติกาและข้อยกเว้น: ส่วนลด วงเงินเครดิต อนุมัติ รับบางส่วน คืน และยกเลิก
5. ข้อมูล: รหัสสินค้า ลูกค้า หน่วยนับ ราคา ยอดตั้งต้น และประวัติที่ต้องเก็บ
6. Integration: ระบบปลายทาง เอกสารที่ส่ง จังหวะส่ง และวิธีจัดการเมื่อส่งไม่สำเร็จ
7. คุณสมบัติระบบ: ปริมาณงาน เวลาตอบสนอง ความพร้อมใช้งาน ความปลอดภัย และการกู้คืน
8. การส่งมอบ: เกณฑ์ตรวจรับ คู่มือ อบรม สิทธิ์ในผลงาน และผู้ดูแลหลังเปิดใช้

ตัวอย่าง Requirement สำหรับพัฒนาระบบ ERP ที่ตรวจรับได้

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

เริ่มจากกระบวนการปัจจุบัน แล้วออกแบบกระบวนการเป้าหมาย

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

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

แบ่งขอบเขตระบบและเจ้าของข้อมูลให้ชัด

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

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

ข้อมูลและการย้ายข้อมูลต้องเป็น Requirement ตั้งแต่ต้น

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

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

ระบุความปลอดภัยและการรองรับงานจริงด้วยตัวเลขที่ตรวจได้

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

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

วางเกณฑ์ทดสอบและผู้อนุมัติผลตั้งแต่ก่อนเริ่มพัฒนา

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

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

ปัญหาที่พบบ่อยและวิธีป้องกัน

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

เผื่อ Automation และ AI โดยไม่ทำ Scope คลุมเครือ

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

สรุป: Requirement เป็นข้อตกลงการทำงานของทั้งทีม

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

ต้องการทีมพัฒนาที่เข้าใจทั้งธุรกิจและเทคโนโลยี?

Zairosoft ให้บริการพัฒนาเว็บไซต์ ระบบ Web Application, AI Chatbot, AI Automation และระบบเฉพาะทางสำหรับองค์กร โดยเน้นการออกแบบที่รองรับการเติบโต การทำ SEO และประสิทธิภาพการใช้งานจริง

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

📞 โทร 065-389-6356
💬 LINE zairosoft

คำถามที่พบบ่อยเกี่ยวกับ พัฒนาระบบ ERP