AI เปรียบเทียบใบเสนอราคาซัพพลายเออร์สำหรับโรงงาน: เงื่อนไขถึงการอนุมัติ

การนำ AI มาเปรียบเทียบใบเสนอราคาซัพพลายเออร์ในโรงงาน ไม่ควรเริ่มจากปุ่ม “เลือกเจ้าที่ถูกที่สุด” แต่ควรเริ่มจากการจัดข้อเสนอหลายรูปแบบให้อยู่บนเงื่อนไขจัดซื้อเดียวกัน แสดงความแตกต่าง และเปิดกลับไปดูเอกสารต้นทางได้ ราคาต่อหน่วยที่ต่ำกว่าอาจเปรียบเทียบไม่ได้ หากปริมาณสั่งซื้อขั้นต่ำหรือ MOQ สูงกว่าความต้องการจริงสองเท่า บทความนี้อธิบายแนวทางสำหรับโรงงานในประเทศไทย ตั้งแต่ AI-OCR การปรับเงื่อนไขให้เทียบกันได้ การจัดการข้อยกเว้น การอนุมัติ ไปจนถึง RFP และ FAT/SAT ตัวเลขราคาในบทความเป็นสมมติฐานเพื่ออธิบายวิธีคิด ไม่ใช่ราคาตลาด

ระบบ AI เปรียบเทียบใบเสนอราคาควรตัดสินใจเรื่องใด

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

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

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

กำหนดคำว่า “เทียบกันได้” ก่อนนำ AI-OCR มาใช้

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

อย่าจับคู่ชิ้นส่วนจากชื่อเพียงอย่างเดียว ชิ้นเดียวกันอาจมีรหัสภายใน รหัสผู้ขาย รหัสเก่า และเลขแบบต่างกัน ขณะที่ชื่อคล้ายกันอาจเป็นคนละชิ้น ให้ใช้รหัสและฉบับแบบเป็นหลัก เมื่อข้อมูลไม่ครบ ให้ AI แสดงตัวเลือกแล้วให้คนยืนยัน มาตรฐาน GTIN ของ GS1 ใช้ช่วยระบุสินค้าทั่วไปที่มี GTIN จริงได้ แต่ชิ้นส่วนผลิตตามแบบจำนวนมากไม่มี GTIN จึงต้องยึดเลขแบบ ฉบับแก้ไข และการอนุมัติทางเทคนิค

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

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

AI-OCR ต้องดึงข้อมูลอะไรจากใบเสนอราคา

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

เอกสารของ Microsoft Document Intelligence อธิบายค่าความเชื่อมั่นของคำ คู่คีย์กับค่า ตาราง และเซลล์ พร้อมแนวทางให้คนตรวจข้อมูลสำคัญ Google Cloud Document AI ก็อธิบายความเชื่อมั่นรายฟิลด์และการส่งค่าที่ความเชื่อมั่นต่ำให้ตรวจด้วยคน คะแนนความเชื่อมั่นเป็นการประมาณของโมเดล ไม่ใช่หลักฐานว่าข้อเท็จจริงถูกต้อง ต้องเทียบรหัสชิ้นส่วน จำนวน หน่วย ราคา และกำหนดส่งกับต้นฉบับ

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

ตัวอย่างคำว่า “30 days” อาจหมายถึง 30 วันปฏิทินหลังออกคำสั่งซื้อ หรือ 30 วันทำการหลังรับเงินล่วงหน้า AI อาจอ่านเลข 30 ถูกแต่พลาดจุดเริ่มนับ ต้องแสดงเชิงอรรถประกอบและระบุว่าวันส่งยังไม่แน่ชัดหากขาดเงื่อนไข เครื่องหมายทศนิยมและหลักพันก็แตกต่างตามภาษา ห้ามเดาว่าสกุลเงินเป็น THB เพียงเพราะโรงงานอยู่ในประเทศไทย

ปรับเงื่อนไขให้เป็นฐานเดียวกันหลังการดึงข้อมูล

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

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

สำหรับการซื้อข้ามประเทศ ต้องอ่าน Incoterms® พร้อมสถานที่ที่ระบุและฉบับของกฎ ICC Incoterms® 2020 จัดสรรต้นทุนและความเสี่ยงระหว่างผู้ขายกับผู้ซื้อ FOB, CIF และ DAP ไม่ใช่ “ราคาส่งถึงรวมทุกอย่าง” เหมือนกัน หากสถานที่ ค่าประกัน หรือผู้รับผิดชอบนำเข้าไม่ชัด ให้ขอคำอธิบายเพิ่ม แม้คำนวณต้นทุนถึงโรงงานได้ ก็ต้องแสดงสูตรและสมมติฐาน

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

ตัวอย่างคำนวณ: ราคา 92 THB ต่อชิ้นอาจไม่ใช่ข้อเสนอที่ถูกที่สุด

สมมติว่าต้องใช้ชิ้นส่วนเหมือนกัน 1,000 ชิ้น ส่งที่แห่งเดียว และคุณภาพเท่ากัน เพื่อให้เห็นวิธีคิดจึงยังไม่รวมภาษีหรืออัตราแลกเปลี่ยน ตัวเลขทั้งหมดเป็นตัวอย่าง ไม่ใช่ใบเสนอราคาจริง

B มีราคาต่อชิ้นต่ำสุด แต่ภายใต้สมมติฐานนี้ไม่ขายเพียง 1,000 ชิ้น หากสั่ง 2,000 ชิ้น จะเหลือ 1,000 ชิ้นที่มีต้นทุนเก็บ ความเสี่ยงหมดอายุ หรือความเสี่ยงจากการเปลี่ยนแบบ A ต่ำกว่า C 2,000 THB สำหรับความต้องการครั้งนี้ แต่ C ส่งเร็วกว่า 6 วัน หากวัสดุนั้นมีผลต่อการหยุดสายผลิต กำหนดส่งอาจสำคัญกว่าส่วนต่างราคา

หากความต้องการทั้งปีเป็น 2,000 ชิ้น A สั่ง 1,000 ชิ้นสองครั้งและเสียค่าขนส่งสองครั้ง จะเท่ากับ 206,000 THB ส่วน B สั่งครั้งเดียวตาม MOQ เท่ากับ 197,000 THB และ C เท่ากับ 210,000 THB แต่ยังต้องคิดว่าค่าทำแม่พิมพ์คิดซ้ำปีหน้าหรือไม่ ต้นทุนสต็อก เงินจม และความเสี่ยงการส่งมีเท่าใด ระบบควรแยกฉากทัศน์ความต้องการ 1,000 ชิ้นครั้งนี้กับ 2,000 ชิ้นทั้งปี และเก็บประวัติการเปลี่ยนสมมติฐาน

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

แยกการตัดสินใจเป็นสามขั้น

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

ขั้นที่สองคือการคำนวณตามกฎที่เปิดเผย: ช่วงราคา MOQ จำนวนทวีคูณ ค่าขนส่ง ค่าใช้จ่ายครั้งเดียว ภาษี เงื่อนไขนำเข้า และอัตราแลกเปลี่ยนที่อนุมัติแล้ว ให้ซอฟต์แวร์คำนวณอย่างกำหนดผลแน่นอนหลังตรวจข้อมูลโครงสร้าง ไม่ให้ LLM คิดเลขในข้อความอิสระ หากหน่วยไม่ตรงกันให้หยุด เอกสาร OpenAI Structured Outputs แสดงวิธีให้โมเดลตอบตาม JSON schema ที่กำหนด แต่โครงสร้างถูกต้องไม่ได้ยืนยันว่าตีความต้นฉบับถูก

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

หน้าจออนุมัติต้องเปิดหลักฐานต้นทางได้

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

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

ส่งเฉพาะตารางที่ผ่านการตรวจจากคนไปยังใบขอซื้อหรือร่าง PO ใน ERP พร้อมเลข RFQ เลขใบเสนอราคา ฉบับการประเมิน และเลขอนุมัติ เมื่อ ERP ออกเลข PO แล้ว ยังต้องย้อนรู้ได้ว่าใช้ข้อเสนอและเงื่อนไขใด PoC แรกไม่ควรให้ AI เขียนคำสั่งซื้อที่มีผลสุดท้ายเข้า ERP โดยตรง

เงื่อนไขการใช้งานที่โรงงานไทยควรจัดการก่อน

โรงงานมักได้รับเอกสารภาษาไทย อังกฤษ และญี่ปุ่นพร้อมกัน ตารางแปลอย่างเดียวอาจซ่อนเงื่อนไขในต้นฉบับ จึงควรแสดงต้นฉบับเคียงคำแปล และคงหน่วย รหัสชิ้นส่วน เครดิตเทอม และรหัส Incoterms ตามเดิม หากจัดซื้อร่วมกับโรงงานเวียดนาม อย่ารวมสกุลเงินและเส้นทางขนส่งคนละแบบเป็นราคาเดียว วัดคุณภาพการดึงข้อมูลแยกตามภาษาและส่งรูปแบบเอกสารที่ทำได้ไม่ดีให้คนตรวจ

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

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

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

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

PoC ควรวัดการป้องกันการตัดสินใจผิด ไม่ใช่ OCR อย่างเดียว

ชุดทดสอบควรมีเอกสารชัดและสแกนเอียง หลายสกุลเงิน หลายหน่วย ราคาตามจำนวน MOQ ค่าขนส่งในเชิงอรรถ ค่าทำแม่พิมพ์ ของทดแทน ราคาเลยกำหนด และเอกสารแก้ไข ตัวอย่างเริ่มต้นอาจเลือกใบเสนอราคาย้อนหลัง 30–50 ฉบับจากหลายผู้ขาย ภาษา และกลุ่มชิ้นส่วน จำนวนนี้เป็นเพียงตัวอย่าง ไม่ใช่เกณฑ์สากล ขนาดจริงขึ้นกับความหลากหลายและความเสี่ยง แยกข้อมูลสำหรับปรับระบบออกจากข้อมูลประเมินสุดท้าย

วัดอย่างน้อยห้าเรื่อง: ความถูกต้องของฟิลด์สำคัญ; ความถูกต้องของลิงก์ไปยังต้นฉบับ; การพักข้อเสนอที่เทียบไม่ได้; จำนวนและเวลาที่คนแก้; และจำนวนข้อเสนอผิดที่หลุดไปถึงร่าง PO ความแม่นของ OCR ทั้งหน้าอย่างเดียวไม่บอกความเสี่ยงในการซื้อ กำหนดจุดให้คนตรวจแยกตามรหัสชิ้นส่วน ราคา MOQ และกำหนดส่ง แล้ววัดทั้งกรณีผิดที่หลุดผ่านกับกรณีถูกที่ถูกพักเกินจำเป็น แนวทางประเมินของ Google Document AI อธิบายความสัมพันธ์ระหว่าง precision กับ recall เมื่อเปลี่ยนค่าความเชื่อมั่นขั้นต่ำ

เปรียบเทียบเวลามัธยฐานจากรับใบเสนอราคาจนทำตารางเสร็จ ก่อนและหลัง PoC อย่าตัดเวลาที่คนตรวจออกจากผลประหยัด รวมปริมาณเอกสาร ค่าใช้ระบบ งาน ERP งานตรวจ และการเก็บ log ในต้นทุนทั้งหมด อย่านำเปอร์เซ็นต์ประหยัดทั่วไปของผู้ขายมาใช้เป็นผลคาดการณ์ของโรงงานโดยไม่วัดฐานของตน

NIST AI Risk Management Framework และเอกสารสำหรับ generative AI ให้กรอบจัดการความเสี่ยงตามบริบท เมื่อนำมาใช้กับการเทียบราคา ต้องมีการทดสอบการอ่านผิดและคำแนะนำที่ชวนเข้าใจผิด วิธีหยุดกระบวนการเมื่อพบความผิดปกติ log ที่ตรวจได้ และผู้รับผิดชอบการตัดสินใจที่ชัดเจน

สิ่งที่ควรใส่ใน RFP

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

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

FAT และ SAT ต้องทดสอบการหยุดอย่างปลอดภัย

ใน FAT ให้เอกสารที่ตกลงกันผ่านการดึงข้อมูล ปรับเงื่อนไข เปรียบเทียบ พัก อนุมัติ และส่งร่าง ERP ตรวจว่ารหัสชิ้นส่วนผิดไม่จับคู่เงียบ ๆ; ข้อเสนอไม่ถึง MOQ ไม่ชนะเพราะราคาต่อหน่วย; สกุลเงินไม่ชัดไม่ถูกแปลงเอง; และราคาหมดอายุไม่แสดงว่าใช้ได้ หากขั้นใดล้มเหลว ต้องไม่สร้างร่าง PO โดยไม่มีวิธีจัดการข้อยกเว้น และยังต้องเปิดต้นฉบับกับเหตุผลได้

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

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

ลำดับเริ่มต้นภายใน 90 วัน

เดือนแรก ฝ่ายจัดซื้อ คุณภาพ และวิศวกรรมเลือกกลุ่มชิ้นส่วนที่เงื่อนไขค่อนข้างคงที่ กำหนดกฎเปรียบเทียบ รวบรวมใบเสนอราคาต้นทางกับตารางที่เคยอนุมัติ ตรวจเลข RFQ ฟิลด์ ERP และ master ชิ้นส่วน ตกลงวิธีแสดงหน่วยหรือ MOQ ที่ไม่ระบุ อย่าเปิดใช้กับทุกผู้ขายพร้อมกัน

30 วันถัดมา ทดลองดึงข้อมูลและปรับเงื่อนไข วัดความถูกต้องของ JSON schema แยกจากความถูกต้องของข้อมูล สร้างลิงก์ต้นฉบับ หน้าจอแก้ และการพักก่อนแต่งตารางอันดับ จับเวลาที่ผู้ซื้อใช้จริง แยกสาเหตุผิดเป็นคุณภาพภาพ การดึง master กฎ หรือสิทธิ์อนุมัติ

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

คำถามที่พบบ่อย

AI-OCR อย่างเดียวใช้เปรียบเทียบใบเสนอราคาซัพพลายเออร์ได้ไหม

ไม่ได้ OCR ดึงค่าที่คาดว่าใช่ ยังต้องจับคู่รหัสและฉบับแบบ ปรับหน่วย MOQ ขนส่ง เงิน วันที่ และกฎพัก ค่าใช้จ่ายที่ไม่ระบุไม่เท่ากับศูนย์ และข้อเสนอที่เทียบไม่ได้ไม่ควรมีอันดับราคาปกติ

AI ปรับเงื่อนไขแล้วให้ออก PO อัตโนมัติได้ไหม

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

AI มักพลาดความแตกต่างข้อใดในใบเสนอราคา

MOQ ในเชิงอรรถ ราคาตามจำนวน หน่วย สถานที่ตาม Incoterms จุดเริ่มนับวันส่ง ค่าทำแม่พิมพ์ วันหมดอายุ และคำเสนอของทดแทน ต้องทดสอบเรื่องฉบับล่าสุดด้วย

ประเมินต้นทุนระบบเปรียบเทียบอย่างไร

รวมค่าติดตั้ง ทำความสะอาด master เชื่อม ERP เวลาคนตรวจ ปรับหลายภาษา บำรุงรักษา และเก็บ log ในช่วงเวลาเดียวกัน วัดเวลาที่ประหยัดและข้อผิดพลาดที่ป้องกันได้จากฐานของโรงงานเอง

RFP, FAT และ SAT ต้องให้ความสำคัญกับอะไร

RFP ระบุความหลากหลายของเอกสารและกฎพัก FAT ตรวจการดึง การคำนวณ หลักฐานและ log SAT ทดสอบเอกสาร ภาษา บทบาท และ ERP ที่โรงงานไทย หัวใจคือข้อผิดพลาดรุนแรงเรื่องรหัส จำนวนหลัก ฉบับแบบ MOQ หรือวันหมดอายุไม่หลุดไปถึงร่าง PO

สรุป

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

TOMAS TECH ช่วยสำรวจใบเสนอราคาปัจจุบันและขอบเขต ERP เพื่อเลือกว่าจะเริ่มจาก AI-OCR กฎเปรียบเทียบ หรือหน้าจออนุมัติ แม้ยังอยู่ในช่วงกำหนดโครงการ ก็สามารถติดต่อเราพร้อมกลุ่มชิ้นส่วนและวิธีเปรียบเทียบที่ใช้อยู่

แหล่งข้อมูล

• Microsoft Learn: Document Intelligence accuracy and confidence — ความเชื่อมั่นและการตรวจโดยคน
• Google Cloud: Document AI custom extractor — การดึงฟิลด์
• Google Cloud: Evaluate Document AI performance — threshold, precision, recall
• OpenAI: Structured Outputs — ผลลัพธ์ตาม schema
• World Bank: Evaluating Bids and Proposals — การประเมินนอกเหนือจากราคา
• GS1: System Architecture Document — GTIN เมื่อใช้กับสินค้านั้นได้
• ICC: Incoterms® 2020 — การแบ่งต้นทุนและความเสี่ยง
• NIST: AI Risk Management Framework — กรอบจัดการความเสี่ยง AI