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

TOR ที่ไม่ชัดเจนไม่ได้สร้างปัญหาเฉพาะในช่วงจัดซื้อเท่านั้น แต่สามารถส่งผลต่อทั้ง Project Delivery, Change Request, Cost Overrun และ Operational Readiness หลังส่งมอบ

1. วัตถุประสงค์ของโครงการชัดเจนหรือไม่

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

หาก TOR เริ่มต้นด้วยรายการอุปกรณ์หรือ Specification โดยไม่ได้เชื่อมกลับไปยัง Business Need หรือ Operational Need อาจเป็นสัญญาณว่า Solution ถูกกำหนดเร็วกว่าความต้องการจริง

2. Requirement เชื่อมโยงกับการใช้งานจริงหรือไม่

Requirement ที่สำคัญควรสามารถเชื่อมโยงกลับไปยัง Business Requirement, User Requirement หรือ Operational Requirement ได้

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

การเชื่อม Requirement กับ Use Case จริงช่วยให้ทีมสามารถแยกได้ว่า ข้อใดเป็น Mandatory Requirement และข้อใดเป็นเพียง Preference

3. มี Specification ที่สูงเกินความจำเป็นหรือไม่

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

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

4. มีความเสี่ยงเรื่อง Specification Lock-In หรือไม่

Specification Lock-In เกิดขึ้นเมื่อข้อกำหนดทางเทคนิค ถูกกำหนดในลักษณะที่ทำให้มีผู้ผลิตหรือ Solution เพียงบางรายเท่านั้นที่ผ่าน ทั้งที่ไม่มี Operational Requirement ที่จำเป็นต้องจำกัดการแข่งขันเช่นนั้น

ไม่ใช่ทุกข้อกำหนดเฉพาะจะถือเป็น Lock-In หากองค์กรมีเหตุผลด้าน Compatibility, Standardization, Cybersecurity, Safety หรือ Integration ที่ชัดเจน การกำหนดข้อจำกัดบางอย่างอาจมีเหตุผลรองรับได้

5. Scope of Work ถูกกำหนดครบถ้วนหรือไม่

TOR ที่ระบุเฉพาะสิ่งที่ต้องซื้อแต่ไม่กำหนด Scope รอบข้างอย่างชัดเจน สามารถสร้างค่าใช้จ่ายเพิ่มเติมและข้อโต้แย้งระหว่างโครงการได้

Scope ควรพิจารณาครอบคลุมตั้งแต่ Supply, Installation, Configuration, Integration, Testing, Training, Documentation, Warranty, Support และการส่งมอบเข้าสู่ Operations

6. Inclusion และ Exclusion ชัดเจนเพียงพอหรือไม่

สิ่งที่ไม่ได้กำหนดว่าอยู่ใน Scope หรืออยู่นอก Scope มักกลายเป็นพื้นที่ที่แต่ละฝ่ายตีความไม่เหมือนกัน

ตัวอย่างเช่น Infrastructure, Cable, Network Configuration, Data Migration, Interface Development, Site Preparation หรือการเชื่อมต่อกับระบบเดิม ควรถูกกำหนดผู้รับผิดชอบอย่างชัดเจน

7. Vendor แต่ละรายสามารถตีความ TOR ได้เหมือนกันหรือไม่

หนึ่งในวัตถุประสงค์ของ TOR คือทำให้ Vendor สามารถเสนอ Solution บนพื้นฐาน Requirement เดียวกัน

หากข้อความใน TOR เปิดกว้างหรือกำกวมเกินไป Vendor แต่ละรายอาจเสนอ Scope, Capacity, Service Level หรือ Architecture แตกต่างกันมาก

ผลที่ตามมาคือองค์กรไม่สามารถเปรียบเทียบข้อเสนอแบบ Apples-to-Apples ได้ แม้ราคาจะถูกนำมาเปรียบเทียบในตารางเดียวกัน

8. Evaluation Criteria สอดคล้องกับ TOR หรือไม่

การกำหนด Requirement จำนวนมากใน TOR ไม่มีประโยชน์หากเกณฑ์การประเมินไม่ได้สะท้อนความสำคัญของ Requirement เหล่านั้น

หาก Reliability, Service Capability, Integration, Lifecycle Cost หรือ Delivery Risk เป็นประเด็นสำคัญของโครงการ สิ่งเหล่านี้ควรถูกสะท้อนอยู่ใน Vendor Evaluation Criteria ด้วย

9. Acceptance Criteria และ Test Method ชัดเจนหรือไม่

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

สำหรับ Requirement สำคัญควรตอบได้ว่า จะตรวจด้วยวิธีใด ใครเป็นผู้ตรวจ หลักฐานใดต้องถูกนำเสนอ และผลลัพธ์แบบใดถือว่า Pass หรือ Fail

Acceptance Criteria ที่ดีควรเชื่อมโยงกับ FAT, SAT, UAT หรือ Test Method ที่เหมาะสมตั้งแต่ก่อนเปิดจัดซื้อ ไม่ใช่เริ่มคิดเกณฑ์ตรวจรับเมื่อระบบถูกส่งมอบแล้ว

10. TOR สามารถอธิบายและตรวจสอบย้อนหลังได้หรือไม่

TOR ที่ดีควรมี Decision Traceability โดยเฉพาะ Requirement ที่มีผลต่อการแข่งขัน ต้นทุน หรือการเลือกเทคโนโลยี

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

สิ่งนี้มีความสำคัญทั้งต่อ Procurement Governance, Internal Audit และการป้องกัน Conflict of Interest หรือข้อสงสัยเรื่อง Specification Lock-In

TOR Checklist ก่อนอนุมัติ