RFP ระบบบริหารการผลิต 2026 – ส่วนต่างราคา 3 เท่าคือส่วนต่างของสมมติฐาน

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

ทำไม RFP ของระบบบริหารการผลิตถึงถูกเลื่อนออกไปเสมอ

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

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

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

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

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

ความต่างระหว่าง RFP กับ RFI และเอกสารกำหนดความต้องการ – ใช้เอกสารไหน เมื่อไร โดยใคร

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

ตามคำอธิบายของ Computer Management นั้น RFP คือเอกสารที่ฝ่ายว่าจ้างจัดทำขึ้นก่อนการคัดเลือกผู้ขาย แล้วนำเสนอต่อผู้ขายหลายราย ในทางกลับกัน เอกสารกำหนดความต้องการคือเอกสารที่ฝ่ายว่าจ้างและผู้ขายร่วมกันสร้างขึ้นหลังจากที่ตัดสินใจเลือกผู้ขายได้แล้ว ถ้าคิดว่าอย่างแรกคือ “เอกสารเพื่อการเปรียบเทียบ” ส่วนอย่างหลังคือ “เอกสารเพื่อการลงมือทำจริง” ก็จะจัดระเบียบความคิดได้ง่ายขึ้น

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

ถ้าจัดระเบียบความสัมพันธ์ของเอกสารทั้ง 3 ชนิด จะได้ดังนี้

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

ขอใบเสนอราคาหลายเจ้าโดยไม่มี RFP แล้วเกิดอะไรขึ้น – ผู้ขายเป็นคนกำหนดสมมติฐานเอง

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

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

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

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

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

กรณีตัวอย่าง – การเปลี่ยนระบบบริหารการผลิตของโรงงานในอยุธยา

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

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

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

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

ใบเสนอราคาครั้งแรกโดยไม่มี RFP – ยอดของ 3 บริษัทและสมมติฐานที่แนบมา

ยอดเสนอราคาที่ได้กลับมาจาก 3 บริษัท พร้อมขอบเขตที่รวมอยู่ในแต่ละใบเสนอราคา เป็นดังนี้ จำนวนเงินเป็นสกุล THB

ยอดสูงสุดของบริษัท C ที่ 3,450,000 คิดเป็น 3.0 เท่า ของยอดต่ำสุดของบริษัท A ที่ 1,150,000 เป็นใบเสนอราคาสำหรับโรงงานเดียวกัน สำหรับปัญหาชุดเดียวกัน แต่ยอดเงินถ่างออกถึง 3 เท่า

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

พูดอีกอย่างคือ ทั้ง 3 บริษัทกำลังเสนอราคาสำหรับงาน 3 งานที่ต่างกัน คิดว่ากำลังเปรียบเทียบราคาอยู่ แต่จริง ๆ แล้วกำลังเปรียบเทียบความกว้างของการตีความ

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

ความต่างของสมมติฐาน 4 ข้อที่ทำให้ราคาแตกต่างกัน

เมื่อแยกส่วนประกอบของใบเสนอราคาทั้ง 3 ใบออกมา จะจัดระเบียบสมมติฐานที่สร้างส่วนต่างได้เป็น 4 ข้อ ราคาตลาดด้านล่างเป็นตัวเลขคร่าว ๆ จากประมาณการเฉพาะของเรา

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

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

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

ทั้งนี้ ในขั้นนี้อาจอยากคิดว่า “ถ้าเอาราคาตลาดของรายการที่ขาดไปบวกเข้ากับยอดของบริษัท A ก็น่าจะได้ราคาที่แท้จริงออกมา” แต่เราไม่แนะนำ เพราะราคาตลาดเป็นเพียงตัวเลขคร่าว ๆ และจะรู้ว่าบริษัท A คิดเท่าไรเมื่อรับงานในขอบเขตนั้นจริง ก็ต่อเมื่อถามบริษัท A เท่านั้น ในทางปฏิบัติ ให้หยุดอยู่แค่การรับรู้ว่าสมมติฐานต่างกันตรงไหน แล้วไปเก็บตัวเลขที่แม่นยำด้วยการขอใบเสนอราคาใหม่

จัดทำ RFP แล้วจัดความต้องการให้ตรงกันด้วย Must/Want/Better

สิ่งที่โรงงานแห่งนี้ลงมือทำต่อมาคือการจัดทำ RFP เป้าหมายไม่ใช่การสร้างเอกสารที่ดูดี แต่คือการสร้างสภาพที่ทั้ง 3 บริษัทเสนอราคาบนขอบเขตเดียวกันได้

หัวใจของงานคือการจัดลำดับความสำคัญของความต้องการ โดย GeNEE ผู้เผยแพร่คู่มือการจัดทำ RFP ได้แนะนำวิธีจัดลำดับความสำคัญของความต้องการออกเป็น 3 ระดับ คือ Must (จำเป็นต้องมี) Want (อยากได้) และ Better (มีแล้วดี) ผลของการแบ่ง 3 ระดับนี้ไม่ได้อยู่แค่ความเป็นระเบียบที่ดูง่ายขึ้น แต่อยู่ที่การทำให้ฝั่งผู้ขายตัดสินได้ว่าควรรวมอะไรไว้ในใบเสนอราคาถึงระดับไหน

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

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

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

เมื่อรักษา 3 ระดับนี้ไว้ รูปร่างของข้อเสนอจากผู้ขายจะเปลี่ยนไป ถ้าทำ Must ไม่ได้ก็ถอนตัว ส่วน Want นำเสนอแยกกรอบ ส่วน Better ตอบด้วยแผนพัฒนาผลิตภัณฑ์ เมื่อกติกาของการตัดสินถูกแบ่งปันร่วมกัน ระดับความละเอียดของข้อเสนอก็จะตรงกัน

ผลของการขอใบเสนอราคาใหม่ – ส่วนต่างลดจาก 3.0 เท่าเหลือ 12.8%

หลังจากนำเสนอ RFP และรวมขอบเขตให้เป็นหนึ่งเดียวด้วยเงื่อนไขว่ารวมการย้ายข้อมูล รองรับ BOM หลายระดับชั้น (Must) อบรม 3 วัน (Must) และบำรุงรักษา 1 ปี (Must) แล้วขอใบเสนอราคาใหม่จากผู้ขาย 3 รายเดิม ผลที่ได้เป็นดังนี้

ส่วนต่างระหว่างยอดสูงสุดของบริษัท C ที่ 2,460,000 กับยอดต่ำสุดของบริษัท A ที่ 2,180,000 คือ 280,000 THB และสัดส่วนของส่วนต่างเมื่อเทียบกับยอดต่ำสุดคือ 12.8% หดลงจาก 3.0 เท่าในครั้งแรก มาอยู่ในระดับที่เปรียบเทียบกันได้

การอ่านผลลัพธ์นี้มีจุดที่ต้องระวังอยู่ 2 ข้อ

ข้อแรกคือ มันไม่ได้แปลว่าถูกลง ยอดของบริษัท A เพิ่มขึ้นจาก 1,150,000 ในครั้งแรก มาเป็น 2,180,000 นี่ไม่ใช่การขึ้นราคา แต่เป็นผลของการที่ขอบเขตซึ่งไม่ได้รวมอยู่ในครั้งแรกถูกเพิ่มเข้ามา ผลของ RFP ไม่ได้อยู่ที่การกดราคาให้ต่ำลง แต่อยู่ที่การทำให้จำนวนเงินที่จำเป็นจริง ๆ มองเห็นได้ ถ้าตอนนั้นสั่งงานไปด้วยยอดของบริษัท A ในครั้งแรก จะต้องมีใบเสนอราคาเพิ่มเติมเกิดขึ้นที่จุดใดจุดหนึ่งก่อนเปิดใช้งานจริง และยอดที่จ่ายจริงในท้ายที่สุดก็จะปรากฏออกมาในรูปของการใช้งบเกิน

ข้อที่สองคือ ส่วนต่าง 12.8% ต่างหากที่มีความหมาย ส่วนต่างที่เหลืออยู่จากการเสนอราคาบนขอบเขตเดียวกัน สะท้อนความต่างของฝีมือและเงื่อนไขจริง ทั้งความต่างของวิธีการพัฒนา ความต่างของโครงสร้างไลเซนส์แพ็กเกจ และความต่างของค่าแรงวิศวกรในประเทศไทย ในขั้นนี้เองที่ราคาจึงจะเริ่มใช้เป็นข้อมูลประกอบการตัดสินใจได้ ส่วนต่าง 3.0 เท่าใช้เปรียบเทียบอะไรไม่ได้ แต่ส่วนต่าง 12.8% เป็นส่วนต่างที่นำไปชั่งน้ำหนักกับโครงสร้างการซัพพอร์ตและผลงานที่ผ่านมาแล้วตัดสินใจได้

และในทางปฏิบัติ เราแนะนำว่าอย่าตัดสินช่วง 12.8% นี้ด้วยราคาเพียงอย่างเดียว เพราะส่วนต่าง 280,000 THB นั้นไม่ได้ใหญ่เลย เมื่อเทียบกับความต่างของคุณภาพการดูแลที่จะเกิดขึ้นตลอดการใช้งานระยะยาว

ปริมาณงานและตารางเวลาในการจัดทำ RFP

“เข้าใจแล้วว่าทำ RFP แล้วจะตรงกัน แต่จะใช้เวลานานแค่ไหน” คือด่านถัดไป ระยะเวลาโดยประมาณที่ใช้จริงในกรณีตัวอย่างนี้เป็นดังนี้

GeNEE แบ่งการจัดทำ RFP ออกเป็น 5 ขั้นตอน และให้ตัวเลขคร่าว ๆ ไว้ว่าการจัดทำตัวเนื้อหา RFP เอง ตั้งแต่การวิเคราะห์สภาพปัจจุบันจนถึงการทำเป็นเอกสาร ใช้เวลาราว 1 ถึง 1.5 เดือน ส่วนภาพรวมทั้งหมดที่รวมการนำเสนอต่อผู้ขายจนถึงการรับข้อเสนอกลับมา ใช้เวลาราว 1.5 ถึง 2.5 เดือน ระยะเวลา 7 สัปดาห์ของกรณีตัวอย่างนี้จึงอยู่ในกรอบของภาพรวมซึ่งรวมการนำเสนอต่อผู้ขายและการตอบคำถามแล้ว ถือได้ว่าเป็นการเดินหน้าแบบมาตรฐาน ไม่ได้เร็วหรือช้าเป็นพิเศษ

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

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

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

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

โครงสร้าง 3 ส่วนที่ควรเขียนใน RFP

สำหรับการประกอบเนื้อหาของ RFP นั้น GeNEE นำเสนอโครงสร้าง 3 ส่วน ได้แก่ ภาพรวม เนื้อหาที่ขอข้อเสนอ และแนวทางการคัดเลือก กรอบนี้ใช้กับงานระบบบริหารการผลิตได้โดยตรง

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

ส่วนที่ 2 คือเนื้อหาที่ขอข้อเสนอ เป็นส่วนที่เทียบเท่าตัวเนื้อหาหลักของ RFP เขียนความต้องการเชิงฟังก์ชัน ความต้องการที่ไม่ใช่เชิงฟังก์ชัน โครงสร้างทีม ตารางเวลา และแนวคิดเรื่องงบประมาณ ตรงนี้เองที่การจัดระเบียบ Must/Want/Better จะออกฤทธิ์ นอกจากนี้ การระบุขอบเขตที่อยากให้รวมไว้ในใบเสนอราคาให้ชัดเจนก็สำคัญอย่างยิ่ง ได้แก่ เป้าหมายและช่วงเวลาของการย้ายข้อมูล จำนวนวันและจำนวนคนของการอบรม และจำนวนปีของสัญญาบำรุงรักษา แค่เขียน 3 ข้อนี้ ส่วนต่างส่วนใหญ่ที่เกิดขึ้นในการขอใบเสนอราคาครั้งแรกก็หายไปแล้ว

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

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

จัดระเบียบความต้องการเชิงฟังก์ชันด้วย Must/Want/Better

การจัดระเบียบ Must/Want/Better ในเชิงแนวคิดนั้นง่าย แต่พอลงมือทำจริงจะติดขัดทุกครั้ง สาเหตุของการติดขัดคือทุกคนในหน้างานคิดว่าความต้องการของตนเองเป็น Must

สิ่งที่ได้ผลในการข้ามกำแพงนี้คือการกำหนดคำถามสำหรับตัดสินไว้ล่วงหน้า ในทางปฏิบัติเราตัดสินด้วยจุดเดียว คือ “ถ้าไม่มีฟังก์ชันนี้ งานยังเดินได้ไหม” ถ้าเดินไม่ได้คือ Must ถ้าเดินได้แต่เพิ่มภาระคือ Want ถ้ามีแล้วจะเป็นประโยชน์ในอนาคตคือ Better เนื่องจากคำถามว่าเดินได้หรือไม่เป็นเรื่องของข้อเท็จจริง ฝ่ายที่มีจุดยืนต่างกันจึงตกลงกันได้ง่ายขึ้น

ถ้ายกกรณีของโรงงานในอยุธยามาเป็นตัวอย่าง จะได้การจำแนกดังนี้

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

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

และตารางจัดระเบียบนี้จะถูกใช้ต่อไปแม้หลังจากส่ง RFP ออกไปแล้ว เพราะตอนประเมินข้อเสนอ จะวางเรียงได้บนแกนเดียวกันว่าแต่ละเจ้าตอบสนอง Must อย่างไร และจัดการกับ Want อย่างไร ตัวตารางจัดระเบียบนี้เองจึงกลายเป็นโครงร่างของตารางประเมินในภายหลัง

ความต้องการที่ไม่ใช่เชิงฟังก์ชันต้องเขียนเป็นตัวเลข – คำคุณศัพท์เทียบกันไม่ได้

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

GeNEE ก็ชี้ว่าความต้องการที่ไม่ใช่เชิงฟังก์ชันจำเป็นต้องเขียนให้เป็นรูปธรรมด้วยตัวเลขหรือมาตรฐาน เหตุผลนั้นชัดเจน เพราะคำคุณศัพท์เทียบกันไม่ได้ หาก RFP เขียนไว้เพียงว่า “ต้องตอบสนองเร็ว” ผู้ขาย A อาจตั้งสมมติฐานไว้ที่ 1 วินาที ส่วนผู้ขาย B อาจตั้งไว้ที่ 5 วินาที ทั้งสองเจ้าต่างก็ “เร็ว” ตามเกณฑ์ของตนเอง

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

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

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

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

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

ประเด็นเฉพาะของโรงงานในไทยและอาเซียน

มีประเด็นเฉพาะของโรงงานในไทยที่ไม่ปรากฏในคำอธิบายเรื่อง RFP ของญี่ปุ่น ขอยกเฉพาะข้อที่ได้ผลจริงในทางปฏิบัติ

ความพร้อมของข้อมูลปัจจุบัน newsclip.be ชี้ว่าในการนำระบบบริหารการผลิตมาใช้ในประเทศไทย มีหลายกรณีที่ระบบรหัสของข้อมูลลูกค้า ข้อมูลสินค้า และข้อมูลวัตถุดิบ ซึ่งแต่ละฝ่ายบริหารจัดการแยกกันด้วย Excel และเครื่องมืออื่น ๆ นั้นไม่ตรงกันในแต่ละฝ่าย นี่คือประเด็นที่ต้องตรวจสอบให้ได้ในขั้น “การสำรวจปัญหาของสภาพปัจจุบัน” ของ RFP ถ้าเขียน RFP โดยไม่รู้ว่าระบบรหัสไม่ตรงกันระหว่างฝ่าย ก็จะประเมินขอบเขตของการย้ายข้อมูลต่ำเกินไป เหตุที่กรณีตัวอย่างจัดค่าย้ายข้อมูลไว้เป็นรายการอิสระ ก็เพราะความต่างของสมมติฐานข้อนี้เชื่อมตรงกับราคานั่นเอง

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

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

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

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

สิ่งที่ควรดูนอกเหนือจาก RFP ในการเปรียบเทียบใบเสนอราคา

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

ASPIC ยกประเด็นสำหรับการเปรียบเทียบระบบบริหารการผลิตไว้ 3 ข้อ ได้แก่ ขอบเขตของงานที่รองรับ การรองรับผู้ประกอบการขนาดเล็กหรือไม่ และความสมบูรณ์ของฟังก์ชันจัดตารางการผลิต ขอบเขตของงานที่รองรับนั้น ความต้องการระดับ Must ใน RFP จะกลายเป็นแกนเปรียบเทียบได้โดยตรง ส่วนการรองรับผู้ประกอบการขนาดเล็กและความจำเป็นของฟังก์ชันจัดตารางการผลิต ก็เป็นประเด็นที่น้ำหนักจะเปลี่ยนไปตามขนาดและรูปแบบการดำเนินงานของบริษัทตนเอง นอกจากนี้ ในทางปฏิบัติของการขอใบเสนอราคาหลายเจ้า ยังมีอีก 3 ข้อที่เป็นข้อมูลประกอบการตัดสินใจซึ่งมีน้ำหนักเทียบเท่าราคา

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

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

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

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

รูปแบบความผิดพลาดที่พบบ่อย 5 ข้อในการจัดทำ RFP

ในทางปฏิบัติของการจัดทำ RFP มักพบรูปแบบความผิดพลาดดังต่อไปนี้ ขอสรุปโดยนำมาปรับใช้กับงานระบบบริหารการผลิต

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

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

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

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

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

เส้นแบ่งระหว่างส่วนที่ทำเองภายในกับส่วนที่จ้างภายนอก

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

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

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

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

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

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

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

RFP ของระบบบริหารการผลิตต้องมีประมาณกี่หน้า

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

RFP กับเอกสารกำหนดความต้องการต่างกันอย่างไร

ต่างกันที่จังหวะเวลาที่ใช้และผู้จัดทำ ตามคำอธิบายของ Computer Management นั้น RFP คือเอกสารที่ฝ่ายว่าจ้างจัดทำก่อนการคัดเลือกผู้ขายแล้วนำเสนอต่อผู้ขายหลายราย ส่วนเอกสารกำหนดความต้องการคือเอกสารที่ฝ่ายว่าจ้างและผู้ขายร่วมกันสร้างขึ้นหลังตัดสินใจเลือกผู้ขายแล้ว ถ้าคิดว่า RFP คือเอกสารเพื่อการเปรียบเทียบ ส่วนเอกสารกำหนดความต้องการคือเอกสารเพื่อการลงมือทำจริง ก็จะจัดระเบียบความคิดได้ง่ายขึ้น ในขั้นของ RFP ไม่จำเป็นต้องกำหนดข้อกำหนดระดับการพัฒนาให้แน่นอน ยิ่งกำหนดแน่นเกินไป จะยิ่งดึงองค์ความรู้เรื่องวิธีการทำให้เป็นจริงที่ผู้ขายมีอยู่ออกมาเป็นข้อเสนอไม่ได้

เมื่อยอดในใบเสนอราคาหลายเจ้าต่างกันมาก ควรตัดสินอย่างไร

ก่อนจะเปรียบเทียบยอดเงิน ขอให้นำขอบเขตที่รวมอยู่ในใบเสนอราคาของแต่ละเจ้ามาเรียงลงในตารางแผ่นเดียวก่อน ในกรณีตัวอย่าง ยอดเสนอราคาของ 3 บริษัทถ่างจาก 1,150,000 ถึง 3,450,000 คิดเป็น 3.0 เท่า แต่สิ่งที่สร้างส่วนต่างคือความต่างของสมมติฐาน 4 ข้อ ได้แก่ การย้ายข้อมูล การรองรับ BOM หลายระดับชั้น จำนวนวันอบรม และจำนวนปีของการบำรุงรักษา การนำใบเสนอราคาที่ขอบเขตไม่ตรงกันมาเทียบกัน ไม่ใช่การเปรียบเทียบราคา เมื่อจัดสมมติฐานให้ตรงกันแล้วขอใหม่ ส่วนต่างราคาจะหดลงเหลือ 12.8% และเมื่อนั้นราคาจึงจะกลายเป็นข้อมูลประกอบการตัดสินใจได้ ลำดับที่ถูกต้องคือการตรวจสอบว่าอะไรไม่ได้รวมอยู่ ไม่ใช่การสงสัยข้อเสนอที่ราคาถูก

การทำ RFP ใช้เวลานานแค่ไหน

GeNEE ให้ตัวเลขคร่าว ๆ ของระยะเวลาในการจัดทำ RFP ไว้ว่า การจัดทำตัวเอกสารใช้เวลา 1 ถึง 1.5 เดือน ส่วนภาพรวมที่รวมตั้งแต่การนำเสนอต่อผู้ขายจนถึงการรับข้อเสนอกลับมา ใช้เวลาราว 1.5 ถึง 2.5 เดือน ในกรณีตัวอย่าง ใช้เวลา 2 สัปดาห์กับการสำรวจปัญหาของสภาพปัจจุบัน 1.5 สัปดาห์กับการจัดลำดับความสำคัญของความต้องการ 1.5 สัปดาห์กับการจัดทำเอกสารและการทบทวนภายในบริษัท และ 2 สัปดาห์กับการนำเสนอต่อผู้ขายและการตอบคำถาม รวมเป็น 7 สัปดาห์ ขั้นที่ใช้เวลามากที่สุดคือการสำรวจปัญหาในตอนต้น เพราะผู้รับผิดชอบที่ควบตำแหน่งต้องสอบถามแต่ละฝ่ายในช่องว่างของงานอื่น เวลารอคอยจึงยาวกว่าเวลาทำงานจริง ในทางกลับกัน การทำให้เป็นเอกสารไม่ใช้เวลานาน ถ้าข้อมูลตั้งต้นพร้อมแล้ว

ควรใช้เกณฑ์อะไรแบ่งความต้องการเป็น Must/Want/Better

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

สรุป

ขอสรุปประเด็นสำคัญ

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

ในประมาณการของกรณีตัวอย่าง โรงงานประกอบชิ้นส่วนยานยนต์สัญชาติญี่ปุ่นในจังหวัดพระนครศรีอยุธยา ซึ่งมีพนักงาน 300 คน ขอใบเสนอราคาจาก 3 บริษัท ได้ยอดครั้งแรกเป็นบริษัท A 1,150,000 THB บริษัท B 2,300,000 THB และบริษัท C 3,450,000 THB โดยยอดสูงสุดเป็น 3.0 เท่าของยอดต่ำสุด สิ่งที่สร้างส่วนต่างคือความต่างของสมมติฐาน 4 ข้อ ได้แก่ ค่าย้ายข้อมูล 400,000 การรองรับ BOM หลายระดับชั้น 550,000 ความต่างของจำนวนวันอบรมที่วันละ 60,000 คือบริษัท A 0 วัน บริษัท B 2 วัน และบริษัท C 5 วัน และการต่อสัญญาบำรุงรักษาอีก 1 ปี 300,000 หลังจากจัดทำ RFP แล้วรวมขอบเขตให้เป็นหนึ่งเดียวด้วยเงื่อนไขว่ารวมการย้ายข้อมูล รองรับ BOM หลายระดับชั้น อบรม 3 วัน และบำรุงรักษา 1 ปี แล้วขอใบเสนอราคาใหม่ ยอดที่ได้คือบริษัท A 2,180,000 บริษัท B 2,340,000 และบริษัท C 2,460,000 ส่วนต่างระหว่างยอดสูงสุดกับยอดต่ำสุดจึงหดลงเหลือ 280,000 THB คิดเป็นสัดส่วน 12.8% ทั้งหมดนี้เป็นประมาณการเฉพาะของเรา ไม่ใช่ตัวเลขของบริษัทที่มีอยู่จริง จึงขอให้ดูที่โครงสร้างว่าจัดอะไรให้ตรงกันแล้วส่วนต่างจะหดลง มากกว่าการดูที่ตัวยอดเงิน

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

RFP ประกอบด้วย 3 ส่วน คือภาพรวม เนื้อหาที่ขอข้อเสนอ และแนวทางการคัดเลือก ความต้องการเชิงฟังก์ชันให้จัดลำดับความสำคัญด้วย Must/Want/Better ส่วนความต้องการที่ไม่ใช่เชิงฟังก์ชันให้เขียนด้วยตัวเลขและมาตรฐาน ไม่ใช่คำคุณศัพท์ สำหรับโรงงานในไทย การเขียนให้ชัดเจนถึงความพร้อมของระบบรหัสข้อมูลปัจจุบัน ขอบเขตของภาษาและเอกสาร ความต้องการในการเชื่อมกับสำนักงานใหญ่ ที่ตั้งของฐานสนับสนุน และความต้องการด้านภาษีและกฎหมาย จะช่วยลดเรื่องเหนือความคาดหมายหลังเปิดใช้งานได้

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

ขอให้เริ่มจากการรวบรวม 3 ข้อ คือวัตถุประสงค์ ความต้องการระดับ Must และขอบเขตที่อยากให้รวมในใบเสนอราคา ลงในกระดาษแผ่นเดียว แล้วยื่นสิ่งเดียวกันให้ทุกบริษัทดูก่อน เพียงเท่านี้ หน้าตาของใบเสนอราคาที่ได้กลับมาก็จะเปลี่ยนไปแล้ว

แม้จะยังอยู่ในขั้นที่รู้สึกว่าเขียน RFP ตั้งแต่ศูนย์นั้นยากก็ไม่เป็นไร TOMAS TECH ดูแลการนำระบบบริหารการผลิตมาใช้และการดำเนินงานให้แก่โรงงานญี่ปุ่นในประเทศไทย และรับปรึกษาตั้งแต่ขั้นของการช่วยกันสำรวจปัญหาในปัจจุบันแล้วจัดลำดับความสำคัญของความต้องการ หากอยากตรวจสอบร่วมกันว่าควรตัดสินอะไรไว้ก่อนการคัดเลือกผู้ขาย ติดต่อได้ที่หน้าติดต่อเรา

ข้อมูลอ้างอิง

• GeNEE — คู่มือการเขียน RFP หรือเอกสารขอข้อเสนอ พร้อมตัวอย่างและเทมเพลต (คู่มือการจัดทำ RFP)
• Computer Management — RFP หรือเอกสารขอข้อเสนอคืออะไร อธิบายความต่างจาก RFI และเอกสารกำหนดความต้องการ พร้อมขั้นตอนการจัดทำ (บทความอธิบายเรื่อง RFP)
• ASPIC — เปรียบเทียบระบบบริหารการผลิต 17 ระบบ วิธีเลือกตามขนาดกิจการ ประเภทอุตสาหกรรม และรูปแบบการผลิต (บทความเปรียบเทียบระบบบริหารการผลิต)
• I-O System Integration — ฉบับล่าสุดปี 2026 เปรียบเทียบระบบบริหารการผลิต 22 ระบบ (มกราคม 2026)
• newsclip.be — เคล็ดลับการนำระบบบริหารการผลิตมาใช้ในประเทศไทย ตอนที่ 1 การเตรียมการล่วงหน้าเพื่อไม่ให้ล้มเหลว (บทความอธิบายการนำระบบมาใช้ที่ฐานปฏิบัติการในไทย)