การจัดซื้อซอฟต์แวร์ยังคงวัดผลด้วยจำนวนคน: ในยุคของเอเจนต์อัจฉริยะ ควรเขียนเกณฑ์การประเมินและรับงานอย่างไร

เผยแพร่: 2026-09-16 แหล่งที่มา: 许愿牛科技

การประกวดราคาขององค์กรยังคงใช้เกณฑ์ประเมินตามจำนวนวันทำงานและจำนวนบุคลากรที่ประจำการในสถานที่ ซึ่งขาดความสอดคล้องกับแนวนโยบาย “ปัญญาประดิษฐ์ + ซอฟต์แวร์” บทความนี้นำเสนอตารางเปรียบเทียบเพื่ออธิบายค...

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

คณะกรรมการจัดซื้อพิจารณาแผนของผู้ให้บริการซอฟต์แวร์

บริบทเชิงนโยบาย: ตรรกะการจัดซื้อกำลังเปลี่ยนแปลง

แผนการดำเนินงานเฉพาะกิจว่าด้วย “ปัญญาประดิษฐ์+ซอฟต์แวร์” ซึ่งกระทรวงอุตสาหกรรมและเทคโนโลยีสารสนเทศได้เผยแพร่เมื่อเดือนกันยายน ปี 2026 ได้เสนอให้ผลักดันการปรับเปลี่ยนซอฟต์แวร์สู่ความเป็นอัจฉริยะ และพัฒนารูปแบบการให้บริการแบบเอเจนต์อัจฉริยะ เป็นต้น พร้อมทั้งเน้นย้ำว่าไม่ดูว่าลงทุนไปเท่าไร แต่ดูว่าได้ผลลัพธ์เป็นอย่างไรสำหรับฝ่ายจัดซื้อแล้ว สัญญาณนั้นชัดเจนมาก: หากยังคงวัดกันเพียงจำนวนวันทำงานและจำนวนพนักงานที่ประจำการ อาจได้มาซึ่ง “การดำเนินการที่คึกคัก” แต่กลับไม่ได้รับการปรับปรุงทางธุรกิจที่สามารถตรวจสอบได้

การประเมินผ่านเกณฑ์ของบุคคลกับการประเมินผลลัพธ์: ความแตกต่างอยู่ที่ใด

มิติการประเมินผู้เข้าร่วมประมูลแบบดั้งเดิมตามจำนวนคน/หัวคนการประเมินผลตามผลลัพธ์
ตัวชี้วัดหลักจำนวนคน ระดับ จำนวนวันที่ประจำการ ราคาต่อหน่วยวงจรปิดของสถานการณ์ สคริปต์การรับรองผล การวัดผล KPI หลังจากการเปิดใช้งาน
การแสดงความต้องการการเลือกทำเครื่องหมายในรายการฟังก์ชันการปฏิบัติงานประจำตำแหน่ง + ขอบเขตข้อมูล + กฎเกณฑ์กรณีพิเศษ
การจัดการการเปลี่ยนแปลงการเจรจาในสถานที่เพิ่มพนักงานและเพิ่มเงินคำสั่งเปลี่ยนแปลงส่งผลกระทบต่อหลักชัยใดบ้าง และ KPI ใดบ้าง
AI/เอเจนต์อัจฉริยะโดยทั่วไปไม่ได้ถูกนำเข้าสู่การให้คะแนนต้องการคำอธิบายเกี่ยวกับจุดที่เพิ่มประสิทธิภาพ จุดที่ต้องตรวจสอบด้วยมนุษย์ และขอบเขตสิทธิ์
โหนดการชำระเงินชำระเงินตามไตรมาสหรือรายเดือนต่อคนชำระเงินตามการรับรองผ่านเกณฑ์ตามหลักไมล์สโตน
ประเด็นข้อพิพาท“คนอยู่ครบหรือไม่”“สคริปต์ทำงานได้หรือไม่ ตัวชี้วัดมีการปรับปรุงหรือไม่”

ตรรกะทางธุรกิจ: ไฟล์เอกสารการประกวดราคาจะแก้ไขอย่างไร

เปลี่ยนเอกสารการจัดซื้อจาก “ซื้อแรงงาน” เป็น “ซื้อผลลัพธ์” ขอแนะนำให้เขียนใหม่สี่ส่วน:

  1. รายการสถานการณ์: เขียนตามตำแหน่งงานว่า “สถานการณ์ปัจจุบันและปัญหา → ขั้นตอนการทำงานที่ต้องการ” เช่น “พนักงานจัดซื้อเปลี่ยนจากการสั่งซื้อผ่านอีเมลมาเป็นการอนุมัติ PO ในระบบแบบครบวงจร”
  2. สคริปต์การรับงาน: แต่ละสถานการณ์ต้องแนบขั้นตอนการทดสอบ ข้อมูลป้อนเข้า และผลลัพธ์ที่คาดหวัง โดยผู้เสนอราคาต้องตอบกลับเป็นรายข้อถึงความเป็นไปได้ในการดำเนินการ
  3. คำมั่นสัญญา KPI: ภายใน 90 วันหลังจากเปิดใช้งาน สามารถกำหนดตัวชี้วัดเชิงปริมาณได้ เช่น สัดส่วนการลดลงของระยะเวลาการอนุมัติ อัตราความแตกต่างในการตรวจสอบยอดคงเหลือ และอัตราความถูกต้องของสินค้าคงคลัง — ตัวชี้วัดดังกล่าวต้องสามารถดึงข้อมูลจากระบบได้
  4. ขอบเขตการให้บริการ: การฝึกอบรม การดำเนินงานและการบำรุงรักษา การโยกย้ายข้อมูล และการดูแลรักษากฎของระบบอัจฉริยะ ต่างมีความรับผิดชอบในส่วนใด เพื่อหลีกเลี่ยงปัญหา “เมื่อเปิดใช้งานแล้วก็จบลงทันที”

คำแนะนำเกี่ยวกับน้ำหนักการให้คะแนน:ความสอดคล้องระหว่างแผนงานกับการรับรองผล 40% + ประสิทธิผลของกรณีศึกษาในประเภทเดียวกัน 30% + ราคา 20% + ความสามารถของทีม 10%. ทีมงานยังคงต้องดู แต่ไม่ควรครอบงำ มิฉะนั้นก็จะกลับไปสู่การเพิ่มจำนวนคนอีกครั้ง

ตรรกะการออกแบบ: ระบบอัจฉริยะและการทำงานอัตโนมัติจะเข้าสู่การประเมินใบเสนอราคาได้อย่างไร

หากแผนงานประกอบด้วยระบบบริการลูกค้าอัจฉริยะ การติดตามผลอัตโนมัติ และกลไกกฎเกณฑ์ ผู้ซื้อควรกำหนดให้ผู้เสนอราคาตอบคำถามดังนี้:

  • การป้อนข้อมูลและการส่งออก: อ่านเอกสารใดบ้าง เขียนกลับสถานะใดบ้าง และสามารถตรวจสอบได้หรือไม่
  • สิทธิ์และการอัปเกรด: การดำเนินการใดบ้างที่ต้องได้รับการยืนยันด้วยตนเอง และหากเกินเวลาจะมีการอัปเกรดอย่างไร
  • ความแม่นยำและการสุ่มตรวจ: บรรทัดฐานการรับประกันว่าจะวัดได้อย่างไร และการดำเนินการผิดพลาดจะย้อนกลับได้อย่างไร
  • การผูกขาดซัพพลายเออร์: โมเดล กฎเกณฑ์ และคลังความรู้สามารถส่งออกได้หรือไม่ เพื่อหลีกเลี่ยงปัญหาที่ระบบจะหยุดทำงานเมื่อเปลี่ยนโรงงาน

ทีมงานรับชมการสาธิตซอฟต์แวร์และตรวจสอบตัวชี้วัดผลลัพธ์

การดำเนินการและการรับรองผล: ระบบควบคุมการเข้าออกช่วงที่สาม

ขอแนะนำให้ระบุในสัญญาให้ชัดเจนว่าเป็นระบบควบคุมการเข้าออกแบบสามขั้นตอน และผูกการชำระเงินกับการตรวจรับงาน:

  1. ระยะที่หนึ่ง (4–8 สัปดาห์): สคริปต์สถานการณ์หลักผ่าน 100% และการฝึกอบรมบุคลากรสำคัญเสร็จสิ้นแล้ว หากไม่ผ่านจะไม่ชำระเงินงวดที่สอง
  2. ระยะที่สอง (8–12 สัปดาห์): กระบวนการข้ามแผนกเชื่อมต่อได้อย่างราบรื่น อินเทอร์เฟซและข้อมูลหลักมีความเสถียร การเก็บรวบรวมข้อมูลพื้นฐาน KPI ได้เปิดใช้งานแล้ว
  3. ระยะที่สาม (การดำเนินงาน 90 วัน): ทำการทบทวนตาม KPI ในสัญญา โดยหากไม่บรรลุเป้าหมายจะมีระยะเวลาแก้ไขและข้อกำหนดการหักเงิน แทนที่จะต้องอยู่ประจำสถานที่แบบไม่มีกำหนดเวลา

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

ข้อเข้าใจผิดที่พบบ่อยของฝ่ายจัดซื้อ

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

ความเข้าใจผิดข้อที่สอง: ยิ่งมีฟังก์ชันมากยิ่งดี——อัตราการออนไลน์ต่ำ แนวทางแก้ไข: แบ่งเป็นขั้นตอนตามสถานการณ์ โดยในระยะแรกให้มีจำนวนน้อยแต่ครบวงจร

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

ข้อเข้าใจผิดข้อที่สี่: ไม่กำหนดเกณฑ์การคำนวณ KPI——เมื่อมีการถกเถียงกัน ต่างฝ่ายต่างคิดคำนวณของตนเอง แนวทางแก้ไข: ให้ใส่สูตรตัวชี้วัด แหล่งข้อมูล และรอบการคำนวณลงในเอกสารแนบ พร้อมทั้งให้ฝ่ายสารสนเทศยืนยันว่าระบบสามารถดึงข้อมูลได้โดยอัตโนมัติ

การดำเนินการขั้นต่อไป

หากคุณกำลังจัดหา ERP, OA, SRM หรือโครงการดิจิทัลแบบกำหนดเองอยู่ สามารถเริ่มต้นด้วยการตรวจสุขภาพการประกวดราคาเป็นเวลาหนึ่งสัปดาห์: ให้ทำเครื่องหมายสีแดงบนข้อกำหนดจำนวนวันทำงานทั้งหมดในเอกสาร RFP ปัจจุบัน แล้วเขียนใหม่ทีละข้อ โดยระบุเป็นสถานการณ์ + สคริปต์ + KPI หากยังแก้ไขไม่เสร็จก็ไม่เป็นไร อย่างน้อยการประกวดราคาฉบับถัดไปก็จะไม่เลือกผู้ให้บริการตามตรรกะของปี 2015 อีกต่อไป

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

ข้อควรระวังเพิ่มเติมสำหรับการจัดซื้อของรัฐวิสาหกิจและกลุ่มบริษัท

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

ในช่วงการนำเสนอของคณะกรรมการจัดซื้อ ขอแนะนำให้สุ่มเลือกสคริปต์ 2–3 ฉบับมาให้ผู้ยื่นข้อเสนอทดลองดำเนินการ โดยกรรมการจะประเมินคะแนนโดยเทียบเคียงกับผลลัพธ์ที่คาดหวัง—วิธีนี้ใกล้เคียงกับประสบการณ์จริงหลังระบบออนไลน์มากกว่าการประเมินจากจำนวนคนในสไลด์ PPT ในขั้นตอนการเจรจาสัญญา ควรระบุ “ระยะเวลาปรับปรุงและสูตรการหักค่าปรับเมื่อไม่บรรลุ KPI” ไว้ในเนื้อหาหลักของสัญญา ซึ่งจะช่วยปกป้องทั้งสองฝ่ายได้ดีกว่าการใช้วิธีเจรจาแบบอาศัยความสัมพันธ์ภายหลัง การปฏิรูปกระบวนการประเมินราคาไม่จำเป็นต้องรอให้มาตรฐานแห่งชาติรุ่นถัดไปออกมา สามารถนำสคริปต์หนึ่งฉบับ KPI หนึ่งรายการ และระบบควบคุมการเข้าออกหนึ่งระยะ มาทดลองใช้ได้ตั้งแต่การจัดซื้อครั้งถัดไป การทดลองอย่างเป็นขั้นตอนและกล้าลองผิดลองถูก จะช่วยให้ทันต่อการเปลี่ยนแปลงทั้งด้านนโยบายและเทคโนโลยีได้ดีกว่าการรอคอยแม่แบบที่สมบูรณ์แบบ