ถอดบทเรียน TOR ภาครัฐด้าน Endpoint
6 ข้อที่ทำให้ "ตกสเปก"
ลองนึกภาพ: ทีมขายเตรียมข้อเสนอด้าน endpoint security มาอย่างดี โซลูชันตรวจจับภัยคุกคามได้แม่นยำ ราคาแข่งขันได้ มี reference จากลูกค้าเอกชนรายใหญ่หลายแห่ง แต่พอเปิดซองคุณสมบัติกลับ "ตกสเปก" ตั้งแต่รอบแรก ทั้งที่ยังไม่ได้มีโอกาสอธิบายประสิทธิภาพของสินค้าเลยด้วยซ้ำ
ในวงการจัดซื้อภาครัฐไทย เรื่องนี้เป็นเรื่องที่คนขายซอฟต์แวร์ security มือใหม่มักไม่รู้ตัวจนสาย — "ตกสเปก" ไม่ได้แปลว่าสินค้าไม่ดีเสมอไป บ่อยครั้งมันคือกลไกของ TOR (Terms of Reference) เองที่ถูกออกแบบมาโดยไม่รู้ตัว หรือรู้ตัว ให้เอื้อกับผู้เล่นรายใดรายหนึ่ง
จากประสบการณ์ตรงในการยื่นข้อเสนอด้าน endpoint security ให้หน่วยงานรัฐและรัฐวิสาหกิจไทย นี่คือ 6 ข้อที่ทำให้โซลูชันดีๆ หลุดวงในทุกครั้ง — และสิ่งที่ทำได้เพื่อไม่ให้เจอเหตุการณ์แบบนี้ซ้ำอีก
ภาพรวม: 6 จุดที่ควรอ่าน TOR ให้ทะลุ
| จุดที่ควรระวังใน TOR | สัญญาณที่สังเกตได้ | สิ่งที่ควรทำ |
|---|---|---|
| 1. ศัพท์เทคนิคเฉพาะตัว | ระบุชื่อเอนจิ้น/ฟีเจอร์จดสิทธิบัตรของแบรนด์เดียว | ถามความต้องการทางธุรกิจเบื้องหลังคำนั้นตรงๆ |
| 2. Reference Site สูงเกินจริง | ต้องมีผลงานภาครัฐไทย 3-5 แห่งขึ้นไป | ขอให้นับ reference เอกชนขนาดใหญ่/ต่างประเทศร่วมด้วย |
| 3. Certification ที่ไม่เกี่ยวการใช้งาน | ขอ Gartner Magic Quadrant เป็นคุณสมบัติ | ชี้ให้เห็นว่าโซลูชันภูมิภาคก็ตอบโจทย์ได้จริง |
| 4. อายุบริษัท/ทีมในประเทศ | ต้องมีสำนักงานไทยมา 3-5 ปี | เตรียมเอกสาร SLA และแผนสำรองทีมสนับสนุนให้ชัด |
| 5. ราคาต่ำสุด (E-bidding) | สเปกกว้าง แต่ตัดสินที่ราคาอย่างเดียว | ผลักดันเกณฑ์ "คะแนนเทคนิค + ราคา" ตั้งแต่ร่าง TOR |
| 6. TOR ก็อปปี้จาก Brochure | ถ้อยคำคุ้นเหมือนโบรชัวร์เจ้าใดเจ้าหนึ่ง | เข้าร่วมขั้นตอนรับฟังความเห็นร่าง TOR ตั้งแต่ต้น |
1. สเปกที่ "ล็อกยี่ห้อ" ด้วยศัพท์เทคนิคเฉพาะตัว
จุดสังเกตแรกที่ต้องอ่านให้ทะลุคือประโยคที่ดูเป็นเทคนิคทั่วไป แต่จริงๆ แล้วมีเพียงผลิตภัณฑ์เดียวในตลาดที่ทำได้ตามนั้น เช่น การระบุเทคโนโลยีตรวจจับแบบเจาะจงชื่อเอนจิ้น หรือฟีเจอร์ที่จดสิทธิบัตรของแบรนด์ใดแบรนด์หนึ่งโดยเฉพาะ ทั้งที่ในทางปฏิบัติ ปัญหาที่หน่วยงานต้องการแก้ไขสามารถแก้ได้ด้วยหลายเทคโนโลยี
สิ่งที่ต้องทำคือกลับไปถามเจ้าของ TOR ตรงๆ ว่า "ความต้องการทางธุรกิจ" เบื้องหลังคำนี้คืออะไร ไม่ใช่เถียงเรื่องคำศัพท์
2. ข้อกำหนด Reference Site ที่สูงเกินความจำเป็นจริง
TOR จำนวนมากกำหนดว่าต้องมีผลงานติดตั้งในหน่วยงานภาครัฐไทยมาแล้วไม่น้อยกว่า 3-5 แห่ง มูลค่าสัญญาละไม่น้อยกว่า X ล้านบาท ซึ่งฟังดูสมเหตุสมผลถ้าเป้าหมายคือลดความเสี่ยง แต่ในทางปฏิบัติ เกณฑ์แบบนี้ปิดประตูให้ทุกแบรนด์ใหม่ที่เพิ่งเข้าตลาดไทย ไม่ว่าประสิทธิภาพจะดีแค่ไหน
จุดที่ควรเจรจาคือขอให้นับ reference จากภาคเอกชนขนาดใหญ่หรือต่างประเทศร่วมด้วย ไม่ใช่จำกัดเฉพาะภาครัฐไทยเท่านั้น
3. การรับรอง (Certification) ที่ไม่เกี่ยวกับการใช้งานจริง
การขอ ISO 27001 ของบริษัทผู้ขายเป็นเรื่องสมเหตุสมผล แต่บาง TOR ไปไกลถึงขั้นระบุอันดับใน Magic Quadrant ของ Gartner หรือรายงานนักวิเคราะห์เจ้าใดเจ้าหนึ่งเป็นเงื่อนไขคุณสมบัติ ทั้งที่รายงานเหล่านี้มีค่าใช้จ่ายสูงมากสำหรับผู้ผลิตซอฟต์แวร์ขนาดกลาง และไม่ได้สะท้อนความเหมาะสมกับบริบทองค์กรไทยเลย
ผลคือโซลูชันจากญี่ปุ่นหรือเอเชียที่เน้นตลาดภูมิภาคแทนที่จะไล่ตามอันดับโลก มักหลุดจากเกณฑ์นี้ทั้งที่ตัวผลิตภัณฑ์เหมาะกับองค์กรไทยมากกว่า
4. ข้อกำหนดสำนักงาน/ทีมสนับสนุนในประเทศ ที่นับ "อายุบริษัท" แทน "ความสามารถจริง"
หลาย TOR กำหนดว่าผู้ขายต้องมีสำนักงานในประเทศไทยมาไม่น้อยกว่า 3-5 ปี หรือมีทีมวิศวกรประจำจำนวนขั้นต่ำ เจตนาดีคือป้องกันบริษัทที่ตั้งมาขายเดี๋ยวเดียวแล้วปิดหนี ปัญหาคือมันกันดีลเลอร์ใหม่ที่อาจมีทีมสนับสนุนคุณภาพสูงแต่เพิ่งเปิดตัวไม่นาน
วิธีรับมือคือเตรียมเอกสารแสดง SLA และแผนสำรองทีมสนับสนุนให้ชัดเจนกว่าคู่แข่ง แทนที่จะแข่งที่ "อายุบริษัท" อย่างเดียว
5. เกณฑ์ราคาต่ำสุด (E-bidding) ที่ทำให้คุณภาพหลุดสเปกแบบไม่รู้ตัว
นี่คือกับดักที่ใหญ่ที่สุด — เมื่อ TOR เขียนสเปกเทคนิคแบบกว้างพอให้หลายเจ้าเข้าประมูลได้ แต่ตัดสินด้วยราคาต่ำสุดเพียงอย่างเดียว ผลลัพธ์คือหน่วยงานมักได้ผลิตภัณฑ์ที่ "ผ่านสเปกขั้นต่ำ" แต่ไม่ใช่ตัวที่ตอบโจทย์จริง เพราะผู้ขายที่เข้าใจปัญหาลึกและเสนอโซลูชันที่เหมาะสมที่สุด มักมีต้นทุนสูงกว่าคู่แข่งที่ตัดฟีเจอร์ออกเพื่อกดราคา
6. TOR ที่ก็อปปี้มาจาก Brochure ของเจ้าเดิม แทนที่จะเขียนจาก Use Case จริง
ข้อสุดท้ายนี้พบบ่อยที่สุดแต่สังเกตยากที่สุด — เมื่ออ่าน TOR แล้วรู้สึกว่าเรียงลำดับหัวข้อและถ้อยคำ "คุ้นๆ" เหมือนโบรชัวร์ของผลิตภัณฑ์ใดผลิตภัณฑ์หนึ่ง นั่นมักหมายความว่าผู้เขียน TOR ไม่ได้เริ่มจากการวิเคราะห์ความเสี่ยงและ use case ขององค์กรตัวเอง แต่เริ่มจากการขอสเปกจากผู้ขายเจ้าที่คุ้นเคยอยู่แล้ว
Checklist: ก่อนยื่นข้อเสนอ TOR ภาครัฐครั้งหน้า
ขั้นก่อนประกาศ TOR (ถ้ามีช่องทางร่วมให้ความเห็น)
- ติดตามประกาศร่าง TOR ของหน่วยงานเป้าหมายอย่างสม่ำเสมออย่ารอให้ TOR ประกาศแล้วค่อยเริ่มอ่าน
- ส่งความเห็นเป็นลายลักษณ์อักษรทันทีที่พบคำศัพท์ที่ล็อกยี่ห้อก่อนที่ร่าง TOR จะกลายเป็น TOR ตัวจริง
- เสนอมุมมอง use case จริงแทนการเสนอสเปกฟีเจอร์ตรงๆช่วยให้ผู้เขียน TOR เห็นภาพปัญหาที่แท้จริงขององค์กร
ขั้นอ่าน TOR ที่ประกาศแล้ว
- ไล่เช็คทุกข้อสเปกเทียบกับ Checklist 6 ข้อในบทความนี้ทำเป็นตารางเทียบทีละบรรทัด
- แยกให้ออกว่าเงื่อนไขไหนคือ "ล็อกสเปก" กับเงื่อนไขไหนคือ "ความเสี่ยงที่สมเหตุสมผล"ไม่ใช่ทุกเงื่อนไขที่เข้มงวดจะเป็นการล็อกสเปกเสมอไป
- เตรียมคำถามส่งเข้าสู่กระบวนการชี้แจง TOR (ถ้ามี) เป็นลายลักษณ์อักษรเสมอเพื่อให้มีบันทึกเป็นทางการ
ขั้นเตรียมข้อเสนอ
- เตรียมเอกสาร SLA และแผนสำรองทีมสนับสนุนให้ชัดเจนกว่าคู่แข่งแทนการแข่งที่อายุบริษัทอย่างเดียว
- รวบรวม reference จากภาคเอกชน/ต่างประเทศไว้เสริมแม้ TOR จะระบุเฉพาะภาครัฐไทยก็ยื่นเสนอเพิ่มเติมได้
- เก็บบันทึกทุกครั้งที่พบ TOR ล็อกสเปกไว้ใช้เป็นข้อมูลอ้างอิงสำหรับหน่วยงานกำกับดูแล หรือใช้ยื่นอุทธรณ์หากจำเป็น
สรุป
การตกสเปกไม่ได้แปลว่าผลิตภัณฑ์ไม่ดี — บ่อยครั้งมันคือสัญญาณว่ากระบวนการเขียน TOR เองมีช่องโหว่ ทีมขายและทีมเทคนิคที่เข้าใจกลไกทั้ง 6 ข้อนี้ จะสามารถเข้าไปมีบทบาทตั้งแต่ขั้นตอนก่อนออกประกาศจัดซื้อ ซึ่งเป็นจุดที่ตัดสินผลแพ้ชนะมากกว่าวันยื่นซองจริงเสียอีก
กำลังเตรียมยื่นข้อเสนอ TOR ภาครัฐด้าน Endpoint Security อยู่ใช่ไหม?
CyberAlpha ช่วยทีมขายและทีมเทคนิคอ่าน TOR ให้ทะลุ พร้อมเตรียมเอกสารอ้างอิง SLA และแผนสนับสนุนที่ตอบโจทย์เงื่อนไขภาครัฐไทย
ขอคำปรึกษาฟรี ดูบทความอื่นๆ