“คลังแรกซ้อมผ่านแล้ว ถ้ารวมอีกสองคลังใน 600,000 บาทเดิมได้ ผมจะเอาเข้าที่ประชุมรอบนี้ครับ” ผู้อำนวยการฝ่ายปฏิบัติการบอก ทีม ERP เพิ่งซ้อมให้เห็นว่าฝ่ายขายพักการยืนยันออเดอร์ได้เมื่อยอดจองมาช้า แต่ยังไม่เคยเห็นไฟล์สต็อกของอีกสองคลัง ถ้าตอบตกลงตอนนี้ ทีมส่งมอบจะต้องรับปากทั้งราคาและวันเริ่มงานโดยยังไม่รู้ว่าต้องแก้ข้อมูลแค่ไหน
นี่คือบริษัทจัดจำหน่ายสมมติรายเดิมจาก ตอน The JOLT Effect คลัง A ผ่านการซ้อมนอกระบบจริง ส่วนการทดลองกับออเดอร์จริงยังต้องขออนุมัติ ตัวเลข ข้อตกลง และบทสนทนาในตอนนี้สมมติขึ้นเพื่อให้เห็นวิธีคุย โดยจำนวนเงินทั้งหมดเป็นค่าบริการก่อนภาษี
ใน Getting to Yes ฉบับปี 2011 Roger Fisher, William Ury และ Bruce Patton เสนอให้แยกเรื่องคนออกจากตัวปัญหา ถามว่าแต่ละฝ่ายต้องการอะไร เปิดทางเลือกที่เป็นประโยชน์กับทั้งสองฝ่าย และตกลงด้วยเกณฑ์ที่มีเหตุผลรองรับ ผมจะลองใช้ทั้งสี่ข้อตอนที่ลูกค้ากับทีม ERP เห็นตัวเลขคนละตัวบนโต๊ะ หน้าหนังสือจาก Penguin Random House · Program on Negotiation, Harvard Law School
ถามว่าคำขอ “รวมทุกคลัง” มาจากปัญหาอะไร
หัวหน้าทีมขายระบบ “ถ้าเริ่มใช้ที่คลัง A ก่อน ส่วนคลัง B กับ C ยังใช้วิธีเดิม จะติดตรงไหนครับ?”
ผู้อำนวยการฝ่ายปฏิบัติการ “ออเดอร์ด่วนวิ่งข้ามคลังครับ ถ้าทีมขายเห็นยอดจาก A อย่างเดียว คนขายจะเข้าใจว่าคลังอื่นไม่มีของหรือเปล่า อีกเรื่องคือฝ่ายการเงินอนุมัติไว้ 600,000 บาทสำหรับรอบนี้”
คำขอนี้มีเหตุผลจากวิธีรับออเดอร์ของลูกค้า พอถามถึงวิธีทำงานของฝ่ายขาย ทีม ERP ก็คุยได้สองเรื่องแยกกัน เรื่องแรกคือฝ่ายขายต้องรู้ว่าคลังไหนยืนยันยอดใน ERP ได้ และคลังไหนยังต้องโทรเช็ก เรื่องที่สองคืองบที่อนุมัติแล้ว ทีมส่งมอบก็บอกข้อจำกัดของตัวเองได้ตรง ๆ ว่ายังต้องดูรูปแบบไฟล์ รหัสสินค้า และวิธีส่งยอดจองของคลัง B และ C ก่อนรับปากวันเริ่มใช้
ลองวางสองทางเลือกให้เห็นงานที่เพิ่มขึ้น
ทางหนึ่งคือทำคลัง A ในงบ 600,000 บาท ตามขอบเขตเดิม ระหว่างนั้นให้ฝ่ายขายเห็นชัดว่าคลัง B และ C ยังต้องใช้ขั้นตอนโทรยืนยันกับคลัง เมื่อตรวจตัวอย่างข้อมูลของทั้งสองคลังได้แล้ว ค่อยเสนอราคาและกำหนดการขยายให้ลูกค้าพิจารณา
อีกทางคือทำทั้งสามคลังในสัญญาเดียว โดยแยกวันเริ่มใช้ตามความพร้อมของข้อมูล สมมติว่าทีมประเมินงานเพิ่มเบื้องต้นไว้ 200 ชั่วโมง × 1,500 บาท = 300,000 บาท รวมกับงานคลัง A แล้วเป็น 900,000 บาท ตัวเลขนี้เป็นประมาณการเพื่อคุยกัน ต้องตรวจตัวอย่างข้อมูลและขออนุมัติงบเพิ่มก่อนตกลงราคา
ฝ่ายจัดซื้อ “ชั่วโมงที่เพิ่มมาคิดจากอะไรครับ?”
หัวหน้าทีมส่งมอบ “เบื้องต้นเราเผื่อไว้สำหรับเทียบรหัสสินค้า ปรับการเชื่อมต่อ และทดสอบซ้ำที่คลัง B กับ C ครับ ถ้าตัวอย่างไฟล์ใช้รูปแบบเดียวกับ A และใช้การเชื่อมต่อเดิมได้ เราจะตัดชั่วโมงส่วนที่ทำซ้ำออกแล้วคิดราคาใหม่ด้วยอัตราที่ตกลงกัน”
ชั่วโมงประเมินช่วยให้เห็นว่างานอยู่ตรงไหน แต่ยังเป็นสมมติฐานของทีมส่งมอบ ให้ลูกค้าและไอทีตรวจด้วยไฟล์ตัวอย่างที่ได้รับอนุญาต ผลทดสอบการเชื่อมต่อ และรายการงานที่ต้องทำจริง ถ้าจะเทียบอัตรากับใบเสนอราคาอื่น ให้เทียบงานที่ใกล้เคียงกันทั้งขอบเขตและหน้าที่รับผิดชอบ
ผูกงวดจ่ายกับงานที่ลูกค้าตรวจได้
ฝ่ายการเงิน “ถ้าเริ่มที่คลัง A ขอจ่ายงวดแรก 30% ได้ไหมคะ แล้วขอเก็บงวดสุดท้ายไว้จนกว่าทีมคลังจะตรวจผลกับออเดอร์จริง”
หัวหน้าทีมส่งมอบ “เราแบ่งเป็น 30%, 40% และ 30% ได้ครับ งวดกลางจ่ายหลังทีมคุณเซ็นรับผลซ้อมตามเกณฑ์ที่เขียนไว้ ส่วนงวดสุดท้ายจ่ายเมื่อปิดผลทดลองและตรวจรับงานคลัง A”
| งวด | จำนวนเงิน | เงื่อนไขจ่ายในตัวอย่าง |
|---|---|---|
| เริ่มงาน 30% | 180,000 บาท | เซ็นขอบเขตคลัง A พร้อมระบุว่าใครเตรียมข้อมูลและใครตรวจรับ |
| ซ้อมผ่าน 40% | 240,000 บาท | หัวหน้าคลังและไอทีลงนามรับผลซ้อมด้วยระบบคลัง A ที่ติดตั้งตามขอบเขตงาน ในสภาพแวดล้อมทดสอบ |
| รับมอบ 30% | 180,000 บาท | ผู้อำนวยการฝ่ายปฏิบัติการอนุมัติผลทดลองและลงนามรับมอบคลัง A ตามเงื่อนไขในสัญญา |
การซ้อมงวดกลางใช้ระบบที่ติดตั้งตามขอบเขตงานของคลัง A หลังเริ่มโครงการ ส่วนการซ้อมก่อนคุยราคาช่วยให้ทีมเลือกได้ว่าจะทดสอบอะไร
ให้เขียนเกณฑ์ชัดพอที่คนที่ไม่ได้อยู่ในห้องประชุมจะทดสอบได้ เช่น ถ้าเลยเวลาที่ควรได้รับยอดจองไปเกิน 5 นาที ระบบต้องแสดงคำเตือน ฝ่ายขายต้องพักการยืนยันออเดอร์ที่ได้รับผลกระทบ และเมื่อข้อมูลมาถึง คลังต้องตรวจว่ายอดจองกับยอดพร้อมขายตรงตามชุดทดสอบก่อนให้ฝ่ายขายกลับมายืนยันออเดอร์ ตัวเลข 5 นาทีเป็นเกณฑ์สมมติที่ฝ่ายขาย คลัง และไอทีเห็นตรงกันสำหรับกรณีนี้
ก่อนทดลองกับออเดอร์จริง ให้ระบุช่วงทดลอง คนอนุมัติ และคนที่มีสิทธิ์สั่งหยุด ถ้ายังไม่ได้อนุมัติในวันที่ตกลงไว้ ให้ทั้งสองฝ่ายทบทวนกำหนดการและงวดสุดท้ายตามเงื่อนไขในสัญญา เมื่อจบการทดลองให้เทียบออเดอร์ที่ได้รับผลกระทบกับรายการจอง และปิดปัญหาที่ขวางการใช้งานตามที่ตกลงกัน ถ้าผลไม่ผ่าน ให้บันทึกสิ่งที่ต้องแก้และนัดทดสอบใหม่ ส่วนการเพิ่มคลังหรือเปลี่ยนเกณฑ์ ให้ตกลงผลต่อราคาและกำหนดการเป็นลายลักษณ์อักษรก่อนเริ่มงานเพิ่ม
ถ้าตกลงกันไม่ได้ จะทำอะไรต่อ
BATNA ย่อมาจาก Best Alternative to a Negotiated Agreement คือทางเลือกที่ดีที่สุดที่ทำได้จริงถ้าการเจรจาครั้งนี้ไม่เกิดข้อตกลง ถ้าลูกค้าตรวจแล้วว่าวิธีเดิมยังใช้ได้ และกันคนไว้ยืนยันยอดด่วนได้ ทางเลือกของลูกค้าอาจเป็นการใช้ระบบเดิมต่ออีกหนึ่งรอบงบพร้อมเก็บตัวอย่างข้อมูลจากทั้งสามคลัง ต้นทุนของทางนี้คือฝ่ายขายยังต้องรอคลังตอบ และทีมคลังยังต้องแบ่งคนมาเช็กยอด ฝั่งผู้ขายอาจจัดทีมไปทำโครงการอื่นที่ยืนยันวันเริ่มได้แล้ว ถ้าตารางคนรองรับจริง Program on Negotiation, Harvard Law School
เอาทางเลือกนั้นมาเทียบกับข้อเสนอตรงหน้า ทั้งเงินที่ต้องจ่าย เวลาที่เสียไป และผลต่อออเดอร์ด่วน ถ้าฝ่ายปฏิบัติการรับภาระโทรยืนยันยอดต่อไม่ได้ ก็ควรคิดใหม่ว่าการรออีกรอบงบทำได้จริงแค่ไหน ส่วนข้อเสนอเริ่มที่คลัง A ยังอยู่บนโต๊ะ ตราบใดที่สองฝ่ายยังพิจารณาจะทำงานร่วมกัน
เช็กลิสต์ก่อนกลับไปคุยเรื่องราคา
- จดคำขอของแต่ละฝ่าย แล้วถามว่างบ วันเริ่มใช้ หรือวิธีทำงานส่วนไหนที่ต้องรักษาไว้
- เตรียมอย่างน้อยสองทางเลือก ระบุคลังที่รวมอยู่ งานที่ยังต้องประเมิน และผลต่อราคาและกำหนดการ
- ตกลงว่าจะใช้ไฟล์ตัวอย่าง ผลทดสอบ และอัตราอะไรตรวจชั่วโมงที่ประเมินร่วมกัน
- เขียนยอดแต่ละงวด ผลที่ต้องส่งมอบ คนลงนาม และวิธีแก้กับทดสอบซ้ำหากไม่ผ่าน
- ระบุว่าใครอนุมัติงบและการทดลอง ใครสั่งหยุดได้ และงานเพิ่มต้องผ่านใครก่อนเริ่ม
- เช็กว่าถ้าคุยไม่ลงตัว แต่ละฝ่ายมีทางไหนที่ทำได้จริงและต้องเสียอะไรบ้าง
ถ้าเป็นผม ก่อนออกใบเสนอราคาฉบับถัดไปจะขอให้ฝ่ายปฏิบัติการตอบให้ชัดเรื่องเดียวก่อนว่า ระหว่างใช้ ERP ที่คลัง A ฝ่ายขายยังโทรยืนยันยอดกับคลัง B และ C ได้หรือเปล่า คำตอบข้อนี้จะบอกได้ว่าข้อเสนอ 600,000 บาทแก้ปัญหาได้พอสำหรับรอบนี้ไหม