ทะเบียนคู่ค้าและความเสี่ยง

18 ÷ 86 = 20.9% · 1 ÷ 18 = 5.6% · 14 ÷ 68 = 20.6% · 7 ÷ 12 = 58.3% · อัตราปัญหาโดยรวม 186 ÷ 1,488 = 12.5% · 58.3% ÷ 12.5% = 4.7 เท่า

ตัวเลขนี้วัดได้เพราะบังเอิญมีสองกลุ่มให้เทียบกัน คือรอบที่ดูคะแนนกับรอบที่ไม่ดู — ถ้าทุกรอบทำเหมือนกันหมด จะไม่มีทางรู้ว่าการดูคะแนนช่วยหรือไม่ · รูปแบบนี้เหมือนกับที่โมดูล 19 ใช้เทียบดัชนีต้นทุนของสองกลุ่มโครงการทุกประการ · ข้อควรระวังคือ 12 รอบเป็นจำนวนน้อย และอัตรา 58.3% มาจากเหตุการณ์เพียง 7 ครั้ง จึงเป็นทิศทางที่ชัด แต่ไม่ใช่ตัวเลขที่ใช้ทำนายได้แม่นยำ · ระบบจึงแสดงจำนวนรอบคู่กับอัตราเสมอ และไม่แสดงเปอร์เซ็นต์เดี่ยว ๆ ซึ่งเป็นข้อบังคับเดียวกับที่โมดูล 19 ใช้ · เรื่องนี้คือเรื่องเดียวกับที่โมดูล 19 หน้า 195 เขียนไว้แล้วว่าประวัติผู้รับเหมาจากโมดูล 08 ยังไม่ถูกใช้ตอนเลือก ต่างกันที่ตอนนั้นยังไม่มีตัวเลขว่าไม่ใช้แล้วเกิดอะไรขึ้น · ทางแก้ที่ทำได้ทันทีคือให้หน้าจอเปรียบเทียบใบเสนอราคาแสดงคะแนนของผู้ขายแต่ละรายอยู่ข้างราคาเสมอ ไม่ใช่ให้ต้องเปิดอีกหน้าหนึ่งไปดู · ซึ่งเป็นการเพิ่มคอลัมน์เดียวในหน้าจอที่มีอยู่แล้ว ไม่ใช่การสร้างขั้นตอนใหม่

186.40 + 300.00 + 284.60 + 469.00 = ฿1,240.00M ✓ ตรงกับยอดจัดซื้อในหน้า 224 · 186.40 ÷ 1,240.00 = 15.0% · (186.40 + 300.00) ÷ 1,240.00 = 39.2% · สัดส่วนรวม 100.0% จากการปัดทศนิยม (ค่าจริง 15.03 + 24.19 + 22.95 + 37.82 = 99.99)

คำว่า "วิกฤต" ในทะเบียนนี้หมายถึงคู่ค้าที่ถ้าหยุดส่งของแล้วสายการผลิตหยุดตาม ไม่ได้หมายถึงคู่ค้าที่มีปัญหา — เป็นการจัดกลุ่มตามผลกระทบ ไม่ใช่ตามพฤติกรรม · 8 รายวิกฤตถือยอดจัดซื้อ 39.2% และยังไม่มีแผนสำรองรายใดเลย ซึ่งหมายความว่าถ้ารายใดรายหนึ่งหยุดกะทันหัน ไม่มีใครรู้ว่าจะซื้อจากที่ไหนแทน · รูปแบบนี้เหมือนกับที่โมดูล 18 พบว่าผู้ให้บริการขนส่งรายเดียวถือ 43.9% ของงานทุกประการ และข้อเสนอก็เหมือนกัน คือหารายสำรองไว้ล่วงหน้าและให้งานส่วนน้อยเพื่อให้พร้อมรับงานเพิ่มได้ · ต้นทุนของการมีรายสำรองคือราคาที่สูงกว่าเล็กน้อยเพราะปริมาณน้อย ซึ่งเป็นค่าใช้จ่ายที่ถูกกว่าการหยุดสายการผลิตหนึ่งสัปดาห์มาก · ระบบไม่เสนอว่าควรหารายสำรองกี่ราย เพราะขึ้นกับว่าของแต่ละรายการหาแทนได้ยากแค่ไหน ซึ่งเป็นเรื่องที่ฝ่ายจัดซื้อกับฝ่ายผลิตต้องตัดสินร่วมกัน

35 + 30 + 20 + 10 + 5 = 100% · ส่วนประกอบที่ใหญ่ที่สุดคือการส่งมอบตรงเวลาที่ 35% ซึ่งคำนวณจาก OTD ที่หน้า 224 พบว่าใช้วันกำหนดฉบับล่าสุดเป็นฐาน

ส่วนประกอบที่มีน้ำหนักมากที่สุด 35% คือส่วนที่ฐานยังไม่ตรง ซึ่งแปลว่าคะแนนรวมยังไม่ตรงไปด้วย — คู่ค้าที่ขอเลื่อนวันบ่อยแต่ส่งตรงตามวันที่เลื่อนแล้ว จะได้คะแนนส่วนนี้เต็มเท่ากับคู่ค้าที่ไม่เคยขอเลื่อนเลย · เมื่อเปลี่ยนไปใช้วันกำหนดฉบับแรก คะแนนของคู่ค้าหลายรายจะตกลง และคะแนนเฉลี่ย 78.6 จะตกลงตาม · เรื่องนี้ต้องแก้ก่อนเปิดคะแนนให้คู่ค้าเห็น ซึ่งเป็นข้อเสนอในหน้า 228 เพราะการเปิดคะแนนที่ยังคำนวณผิดจะสร้างข้อโต้แย้งที่ไม่จำเป็น · ส่วนประกอบสุดท้าย 5% เป็นการให้คะแนนโดยเจ้าหน้าที่จัดซื้อ ซึ่งเป็นการประเมินโดยคนที่ทำงานกับคู่ค้ารายนั้นโดยตรง · น้ำหนัก 5% เล็กพอที่จะไม่พลิกผล แต่เป็นส่วนเดียวที่คู่ค้าโต้แย้งไม่ได้ด้วยหลักฐาน จึงต้องแสดงแยกไว้เสมอเมื่อเปิดคะแนนให้คู่ค้าดู

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