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

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

1. เริ่มจาก Business Need ไม่ใช่ชื่อผลิตภัณฑ์

ก่อนถามว่า “ควรซื้อระบบอะไร” ควรถามก่อนว่า:

• ปัญหาปัจจุบันคืออะไร
• ปัญหานี้ส่งผลต่อใคร
• กระบวนการใดต้องได้รับการปรับปรุง
• ผลลัพธ์ที่องค์กรต้องการคืออะไร
• หากไม่ดำเนินโครงการจะเกิดผลกระทบอะไร

2. เก็บ Requirement จากผู้ใช้งานจริง

ผู้ที่อนุมัติงบประมาณ ผู้ที่จัดซื้อ และผู้ที่ใช้งานระบบ อาจมีมุมมองไม่เหมือนกัน จึงควรเก็บข้อมูลจากหลายกลุ่ม เช่น End User, Operations, Maintenance, Engineering / IT / OT, Procurement และ Management

Requirement ที่ดีควรสะท้อนการใช้งานจริง ไม่ใช่ความต้องการของ Stakeholder เพียงกลุ่มเดียว

3. เข้าใจ Workflow ปัจจุบัน

ควรดูว่าผู้ใช้งานทำงานอย่างไรในปัจจุบัน ตั้งแต่ Input → Process → Output และตรวจว่าใครเริ่มกระบวนการ ต้องใช้ข้อมูลอะไร ใครอนุมัติ ระบบใดต้องเชื่อมต่อ และจุดใดเกิดความล่าช้าหรือ Manual Work ซ้ำ ๆ

4. แยก Requirement ออกจาก Specification

Requirement คือสิ่งที่ระบบต้องทำได้ ส่วน Specification คือรายละเอียดทางเทคนิคที่ใช้กำหนดวิธีหรือระดับที่ระบบต้องทำได้

5. ทำให้ Requirement สามารถตรวจสอบได้

คำว่า “ประสิทธิภาพสูง”, “ใช้งานง่าย”, “คุณภาพดี” หรือ “รองรับอนาคต” ไม่ใช่ Requirement ที่ดีหากไม่มีวิธีวัด

Requirement ที่วัดได้จะช่วยเชื่อมต่อไปยัง Acceptance Criteria, FAT, SAT และ UAT ในภายหลัง

6. ตรวจข้อจำกัดของโครงการ

• Budget
• Site Condition
• Existing Infrastructure
• Timeline
• Integration
• Cybersecurity
• Maintenance Capability
• Available Personnel
• Environmental Conditions

ระบบที่ดีที่สุดทางเทคนิคอาจไม่ใช่ระบบที่เหมาะที่สุดกับองค์กร