ลูกค้าขอเพิ่มรายงานอีกชุดในระบบ Odoo โดยบอกว่าใช้ข้อมูลเดิมอยู่แล้ว ฝ่ายผลิตก็มีคำสั่งซื้อด่วนเข้ามาและขอแทรกคิวในสัปดาห์เดียวกัน ทั้งสองเรื่องดูเหมือนโอกาสเพิ่มรายได้ แต่ต้องใช้เวลาของคนหรือเครื่องจักรที่มีงานรออยู่แล้ว
ก่อนตอบว่า “รับได้” ผมอยากชวนมองให้กว้างกว่าราคางานใหม่ ลูกค้าพร้อมซื้อจริงหรือยัง งานนี้เบียดงานไหนออกไป ต้องจ่ายอะไรเพิ่ม และเงินจะเข้าทันค่าใช้จ่ายหรือไม่ คำถามเหล่านี้เชื่อมกันผ่านเศรษฐศาสตร์พื้นฐาน
บทความนี้ปูวิธีคิดสำหรับเจ้าของกิจการและหัวหน้าทีมในธุรกิจรับเหมาพัฒนาซอฟต์แวร์ ผู้วางและเชื่อมระบบ (System Integration หรือ SI), Odoo Partner และซอฟต์แวร์เฮาส์ โดยเทียบกับฝ่ายผลิตไปด้วย เริ่มจากข้อจำกัดและทางเลือก แล้วต่อไปถึงแรงจูงใจ อุปสงค์ อุปทาน ต้นทุนส่วนเพิ่ม และความต่างระหว่างผลผลิต กำไร กับเงินสด
ผมอยากให้ผู้อ่านหยิบงานที่กำลังตัดสินใจสักหนึ่งเรื่องมาอ่านประกอบ จะได้ลองใช้แต่ละแนวคิดกับคำถามเดียวกัน ตัวอย่างทั้งหมดในบทความเป็นสถานการณ์สมมติ ไม่ใช่ผลประกอบการหรือกรณีลูกค้าจริง
ทรัพยากรจำกัด จึงต้องเลือกว่าจะยอมเสียอะไร
เศรษฐศาสตร์ศึกษาการเลือกใช้ทรัพยากรที่มีจำกัด ความจำกัดไม่ได้แปลว่าบริษัทขาดเงินเสมอไป บริษัทอาจมีงบจ้างคน แต่หาผู้เชี่ยวชาญระบบเดิมไม่ทันวันส่งมอบ โรงงานอาจมีพนักงานพร้อม แต่เครื่องจักรเฉพาะทางมีเพียงเครื่องเดียว
ทุกทางเลือกมีสิ่งที่ต้องแลก (trade-off) เช่น รับงานเร่งแล้วต้องเลื่อนการพัฒนาเครื่องมือภายใน หรือผลิตล็อตใหญ่เพื่อลดจำนวนครั้งที่ตั้งเครื่อง แต่ต้องใช้เงินกับวัตถุดิบและเก็บสินค้าไว้นานขึ้น สิ่งที่ต้องแลกอาจเป็นเงิน เวลา คุณภาพ หรือความยืดหยุ่นในการรับงานถัดไป
ผมจึงเริ่มจากการหาข้อจำกัดให้ตรง ถ้าปัญหาอยู่ที่คนอนุมัติแบบ การเพิ่มโปรแกรมเมอร์อาจยังไม่ทำให้งานเดินเร็วขึ้น ถ้าเครื่องจักรรอวัตถุดิบ การเพิ่มชั่วโมงทำงานก็อาจไม่เพิ่มสินค้าที่ส่งได้
แนวคิดนี้อยู่ในระดับเศรษฐศาสตร์จุลภาค คือการตัดสินใจของผู้ซื้อ ผู้ผลิต และตลาด ส่วนเศรษฐศาสตร์มหภาคมองภาพรวม เช่น เงินเฟ้อ ดอกเบี้ย และการจ้างงาน ซึ่งมีผลกับธุรกิจเช่นกัน แต่ควรแยกมาคุยให้พอเห็นกลไก ไม่เหมารวมว่าตัวเลขเศรษฐกิจประเทศใช้ตอบได้ทันทีว่าควรรับโครงการใด อ่านพื้นฐานจาก OpenStax หัวข้อ 1.2
ค่าเสียโอกาสคือทางเลือกที่ดีที่สุดที่เรายอมปล่อยไป
ต้นทุนค่าเสียโอกาส (opportunity cost) คือมูลค่าของทางเลือกที่ดีที่สุดที่เสียไปเมื่อเลือกอีกทางหนึ่ง เช่น เวลาของผู้เชี่ยวชาญหนึ่งวันอาจใช้แก้ปัญหาลูกค้าเดิมหรือทำแบบระบบให้โครงการใหม่ได้ หากเลือกอย่างแรก ทางเลือกที่สองอาจเป็นต้นทุนค่าเสียโอกาสของการตัดสินใจครั้งนี้
เราไม่นำมูลค่าของทุกงานที่ไม่ได้ทำมาบวกกัน เพราะเวลาชุดเดียวกันทำทุกงานพร้อมกันไม่ได้ และไม่ควรนำค่าแรงมาคิดซ้ำอีกครั้งโดยไม่มีเหตุผล ต้นทุนที่จ่ายจริงกับมูลค่าทางเลือกที่เสียไปต้องแยกให้เห็นก่อนเปรียบเทียบ
ตัวอย่างสมมติของซอฟต์แวร์เฮาส์
สมมติว่าสัปดาห์หน้าผู้เชี่ยวชาญคนเดียวกันมีเวลาที่จัดสรรให้สองงานนี้ได้ 12 ชั่วโมง หลังกันเวลางานที่รับปากไว้แล้ว ทั้งสองงานใช้ทักษะของคนนี้แทนกันได้ในกรณีสมมติ และแต่ละงานต้องใช้ครบ 12 ชั่วโมง จึงเลือกทำได้เพียงงานเดียวในสัปดาห์นั้น
งาน A คือปรับรายงานให้ลูกค้าเดิม มีรายรับเพิ่ม 30,000 บาท และค่าใช้จ่ายเงินสดที่เพิ่มเพราะรับงานนี้ 6,000 บาท จึงเหลือ 24,000 บาทก่อนหักค่าใช้จ่ายเดิมของบริษัท
งาน B คือทำต้นแบบการเชื่อมระบบ มีรายรับเพิ่ม 40,000 บาท และค่าใช้จ่ายเงินสดที่เพิ่ม 10,000 บาท จึงเหลือ 30,000 บาทบนฐานการเปรียบเทียบเดียวกัน
ถ้าเลือก A ค่าเสียโอกาสคือ 30,000 บาท
ตัวเลขนี้สมมติให้โอกาสรับเงิน ความเสี่ยง คุณภาพ และผลต่อความสัมพันธ์กับลูกค้าเท่ากัน รวมถึงค่าแรงประจำและค่าใช้จ่ายเดิมที่ไม่เปลี่ยนตามสองทางเลือก หากเลือก A มูลค่าของ B ที่ยอมเสียไปคือ 30,000 บาท และผลต่างจากการเลือก B คือ 6,000 บาท เราไม่ได้เสียโอกาสเท่ากับยอดขาย B ทั้ง 40,000 บาท เพราะการทำ B ก็มีค่าใช้จ่ายเพิ่มเช่นกัน
จำนวน 24,000 และ 30,000 บาทนี้ยังไม่ใช่กำไรสุทธิของบริษัท เป็นเพียงเงินที่เหลือจากรายรับเพิ่มหักค่าใช้จ่ายเงินสดเพิ่มภายใต้สมมติฐานที่ระบุ ใช้ช่วยเปรียบเทียบทางเลือกเฉพาะครั้ง ไม่ใช่สูตรตั้งราคางานทุกประเภท
ในงานจริง A อาจเป็นเรื่องเร่งด่วนที่กระทบระบบหลัก หรือ B อาจมีความเสี่ยงสูงกว่า การคำนวณจึงช่วยให้เห็นราคาของการเลือก แต่ผู้ตัดสินใจยังต้องอธิบายเหตุผลส่วนที่อยู่นอกตัวเลขด้วย
ตัวอย่างสมมติของฝ่ายผลิต
สมมติว่าเครื่องจักรหนึ่งเครื่องมีเวลาให้จัดสรรเพิ่ม 8 ชั่วโมงหลังหักแผนเดิมแล้ว ผลิตสินค้า A ได้ 10 ชิ้นต่อชั่วโมง หรือสินค้า B ได้ 5 ชิ้นต่อชั่วโมง และสมมติว่าอัตรานี้คงที่ ไม่มีเวลาเปลี่ยนงานเพิ่ม วัตถุดิบกับกำลังคนพร้อม และทุกชิ้นผ่านคุณภาพ
ถ้าเลือก A ทั้ง 8 ชั่วโมง จะได้ 80 ชิ้น แต่เสียโอกาสผลิต B จำนวน 40 ชิ้น ส่วนการผลิต A เพิ่มหนึ่งชิ้นจึงมีค่าเสียโอกาสเท่ากับ B ครึ่งชิ้นในตัวอย่างนี้
ชิ้นงานเป็นคนละชนิด การได้จำนวนมากกว่าจึงยังบอกไม่ได้ว่าควรเลือก A ต้องดูคำสั่งซื้อ กำหนดส่ง รายรับ ค่าใช้จ่ายเพิ่ม และเงื่อนไขของแต่ละทางเลือกต่อ หากมีเวลาเปลี่ยนแม่พิมพ์หรืออัตราของเสียต่างกัน ก็ต้องคำนวณใหม่ตามข้อเท็จจริงนั้น
โรงงานกับทีมซอฟต์แวร์ใช้วิธีตั้งคำถามคล้ายกันได้ แต่หน่วยวัดและเงื่อนไขต่างกัน เวลาของนักพัฒนาต่างคนไม่จำเป็นต้องทดแทนกันได้ และชั่วโมงทำงานเพิ่มไม่ได้แปลว่าจะได้งานที่ผ่านการทดสอบเพิ่มตามสัดส่วน
แรงจูงใจเปลี่ยนพฤติกรรมของคนในระบบ
แรงจูงใจ (incentive) คือประโยชน์หรือผลเสียที่ทำให้ทางเลือกหนึ่งน่าทำมากขึ้นหรือน้อยลง อาจเป็นค่าตอบแทน กำหนดส่ง ภาระงาน หรือโอกาสได้รับงานในอนาคต เราใช้แนวคิดนี้ตั้งคำถามกับกติกาของธุรกิจได้ว่า คนที่อยู่ใต้กติกานี้มีเหตุผลจะเลือกทำอะไร
สมมติว่าให้ค่าตอบแทนฝ่ายขายตามยอดเซ็นสัญญาอย่างเดียว ทีมอาจมีแรงจูงใจให้ปิดงานก่อนทำขอบเขตให้ชัด หรือถ้าวัดทีมพัฒนาด้วยจำนวนรายการงาน (ticket) ที่ปิด ทีมอาจเลือกงานชิ้นเล็กที่ปิดง่าย นี่เป็นความเสี่ยงที่ต้องตรวจจากพฤติกรรมจริง ไม่ใช่ข้อกล่าวหาว่าพนักงานจะทำเช่นนั้นทุกคน
ฝ่ายผลิตก็คล้ายกัน หากให้รางวัลตามจำนวนชิ้นโดยไม่ตรวจของเสีย งานแก้ไข หรือความปลอดภัย การเร่งปริมาณอาจผลักภาระไปยังขั้นตอนถัดไปได้
ก่อนเพิ่มเป้าหมาย ผมจะดูว่าคนทำงานควบคุมสิ่งที่วัดได้แค่ไหน และมีเงื่อนไขคุณภาพคอยกำกับหรือยัง เช่น งานที่รับมอบจริง ขอบเขตที่ตรวจแล้ว และชิ้นงานที่ผ่านคุณภาพ กติกาที่ดีต้องตรวจผลที่เกิดขึ้นต่อด้วย ตัวชี้วัดเพียงตัวเดียวไม่ได้อธิบายงานทั้งระบบ
อุปสงค์ อุปทาน และราคาต้องมองร่วมกัน
อุปสงค์ (demand) คือความสัมพันธ์ระหว่างราคากับปริมาณที่ผู้ซื้อเต็มใจและสามารถซื้อได้ในช่วงเวลาที่พิจารณา คนที่สนใจระบบแต่ยังไม่มีงบหรืออำนาจอนุมัติจึงยังไม่ใช่ยอดขายที่พร้อมเกิดขึ้น จำนวนคนสอบถามราคาใช้เป็นข้อมูลตั้งต้นได้ แต่แทนปริมาณที่ซื้อจริงไม่ได้
เมื่อราคาสินค้าหรือบริการนั้นเปลี่ยน โดยปัจจัยอื่นคงเดิม เรากำลังดูการเปลี่ยน “ปริมาณที่ต้องการซื้อ” ตามเส้นอุปสงค์เดิม ส่วนการเปลี่ยนงบประมาณ ความต้องการ หรือราคาของทางเลือกอื่น อาจทำให้อุปสงค์ทั้งเส้นเปลี่ยน การแยกสองเรื่องนี้ช่วยไม่ให้รีบสรุปว่ายอดขายลดเพราะราคาของเราเพียงอย่างเดียว
อุปทาน (supply) มองฝั่งผู้ขายว่าเต็มใจและสามารถเสนอขายเท่าไรในแต่ละราคา กำลังการผลิตเป็นข้อจำกัดอย่างหนึ่ง แต่ไม่ใช่อุปทานทั้งหมด โรงงานอาจมีเครื่องจักรว่างแต่ไม่รับราคาที่ต่ำกว่าต้นทุนที่เกี่ยวข้อง ส่วนทีม SI อาจมีคนว่างแต่ขาดทักษะที่โครงการนั้นต้องใช้
ในแบบจำลองตลาดพื้นฐาน ดุลยภาพคือราคาและปริมาณที่ความต้องการซื้อกับความต้องการขายสอดคล้องกันภายใต้เงื่อนไขที่กำหนด การอยู่ที่ดุลยภาพไม่ได้พิสูจน์ว่าราคานั้นยุติธรรม หรือทุกกิจการจะได้กำไร
งานรับเหมาซอฟต์แวร์ยิ่งต้องระวัง ข้อเสนอแต่ละรายอาจต่างกันเรื่องขอบเขต การย้ายข้อมูล คุณภาพ และบริการหลังส่งมอบ จะเอาราคาจากใบเสนอราคาหลายใบมาเฉลี่ยแล้วเรียกว่า “ราคาดุลยภาพ” ทันทีไม่ได้ ฝ่ายผลิตก็ต้องเทียบเกรดวัสดุ ความคลาดเคลื่อน และเงื่อนไขส่งมอบก่อนเทียบราคา
คำถามที่นำไปใช้ได้คือ ลูกค้ากำลังเปรียบเทียบทางเลือกอะไร มีงบและความพร้อมซื้อแค่ไหน และราคาที่เสนอครอบคลุมสิ่งเดียวกันหรือไม่ ดูนิยามอุปสงค์ อุปทาน และดุลยภาพ และ การเปลี่ยนปัจจัยอื่นที่ทำให้เส้นเปลี่ยน
งานเพิ่มหนึ่งชิ้น ต้องดูประโยชน์และต้นทุนที่เพิ่มตาม
การวิเคราะห์ส่วนเพิ่ม (marginal analysis) ถามว่า ถ้าเพิ่มหรือลดกิจกรรมอีกเล็กน้อย ผลประโยชน์และต้นทุนจะเปลี่ยนเท่าไร สำหรับงานที่แบ่งย่อยไม่ได้ เราประยุกต์โดยเทียบผลของทางเลือกทั้งงานหรือทั้งล็อต ไม่ฝืนคิดว่าทุกโครงการเป็นหน่วยเหมือนกัน
งานรายงาน Odoo ที่ใช้ข้อมูลเดิมอาจยังต้องวิเคราะห์ ทดสอบสิทธิ์เข้าถึง ส่งมอบ และดูแลต่อ ค่าใช้จ่ายเพิ่มจึงไม่ได้มีแค่เวลาเขียนรายงาน ส่วนคำสั่งซื้อพิเศษของโรงงานอาจเพิ่มค่าวัสดุ ค่าตั้งเครื่อง การตรวจคุณภาพ และค่าจัดส่งเร่งด่วน
ต้นทุนเฉลี่ยช่วยดูภาพรวม แต่ใช้แทนต้นทุนเพิ่มของการตัดสินใจครั้งนี้ไม่ได้ สมมติว่าโรงงานมีกำลังว่าง ต้นทุนเพิ่มของล็อตพิเศษอาจต่างจากต้นทุนเฉลี่ยเดิมมาก หากกำลังเต็มแล้ว ต้นทุนค่าเสียโอกาสของงานที่ต้องเบียดออกก็กลับมามีน้ำหนัก
การรับงานที่มีรายรับเพิ่มมากกว่าค่าใช้จ่ายเงินสดเพิ่มจึงยังไม่พอ ต้องคิดภาระคุณภาพ ความเสี่ยง และค่าเสียโอกาสที่ยังไม่รวมด้วย โดยไม่บวกต้นทุนเรื่องเดียวกันซ้ำ และต้องดูผลต่อกิจการในระยะที่ยาวขึ้น ค่าใช้จ่ายเดิมที่ไม่เปลี่ยนเพราะงานครั้งนี้ยังต้องมีรายได้รองรับในภาพรวม
ผมจะใช้มุมส่วนเพิ่มช่วยตอบ “รับงานนี้เพิ่มดีไหม” แล้วใช้ต้นทุนรวมกับแผนตลาดช่วยตอบอีกคำถามว่า “รูปแบบธุรกิจนี้อยู่ได้หรือไม่” สองคำถามนี้ใช้ข้อมูลเชื่อมกัน แต่คนละขอบเขต พื้นฐานการวิเคราะห์ส่วนเพิ่มใน OpenStax 2.1 และ ต้นทุนเฉลี่ยกับต้นทุนส่วนเพิ่มในหัวข้อ 7.3
เงินที่เสียไปแล้วกับเงินที่ยังเลือกหลีกเลี่ยงได้ต่างกัน
ต้นทุนจม (sunk cost) คือต้นทุนที่เกิดไปแล้วและเรียกคืนไม่ได้ การตัดสินใจว่าจะทำต่อจึงควรมองผลประโยชน์กับต้นทุนตั้งแต่ตอนนี้ แทนการทำต่อเพียงเพราะเสียดายเงินเดิม OpenStax 2.1 อธิบายต้นทุนจมไว้ในหัวข้อ Sunk Costs
สมมติว่าทีมใช้เวลาพัฒนาโมดูลภายในไปแล้ว แต่ตอนนี้มีทางเลือกที่ตอบความต้องการได้ดีกว่า เวลาที่เรียกคืนไม่ได้เป็นอดีต ส่วนต้นทุนย้ายข้อมูล ค่าปรับเลิกสัญญา และภาระดูแลที่จะเกิดจากการเลือกแต่ละทางยังต้องนำมาเทียบ
ฝ่ายผลิตอาจซื้อแม่พิมพ์มาแล้ว การตัดสินใจผลิตเพิ่มต้องดูคำสั่งซื้อและต้นทุนข้างหน้า แต่ถ้าขายแม่พิมพ์ต่อได้ มูลค่าขายต่อก็เป็นทางเลือกที่ยังมีอยู่ จึงไม่ใช่ต้นทุนจมทั้งหมด
ต้นทุนคงที่กับต้นทุนจมจึงไม่ใช่คำเดียวกัน ค่าเช่าหรือค่าบริการรายเดือนอาจคงที่ในช่วงหนึ่ง แต่การยกเลิกได้เมื่อไร คืนเงินได้หรือไม่ และมีข้อผูกพันอะไร เป็นเรื่องที่ต้องตรวจจริง หลักต้นทุนจมไม่ได้อนุญาตให้ทิ้งสัญญาหรือภาระต่อลูกค้า
ระยะสั้นกับระยะยาวขึ้นกับสิ่งที่ปรับได้
ทฤษฎีการผลิตมองกระบวนการเปลี่ยนปัจจัยนำเข้าเป็นสินค้าหรือบริการ ฝ่ายผลิตใช้แรงงาน เครื่องจักร วัตถุดิบ และวิธีทำงาน ส่วนธุรกิจซอฟต์แวร์ใช้ทักษะ เวลา เครื่องมือ โครงสร้างพื้นฐาน และข้อมูลจากลูกค้าด้วย
ระยะสั้นคือช่วงที่ยังมีปัจจัยการผลิตอย่างน้อยหนึ่งอย่างปรับไม่ได้ ส่วนระยะยาวเปิดให้ปรับปัจจัยทั้งหมดได้ จึงไม่ได้แบ่งตายตัวว่าไม่เกินกี่เดือนหรือกี่ปี อ่านแนวคิดนี้เพิ่มเติมได้ใน OpenStax 7.2
ทีม SI อาจเพิ่มผู้รับเหมาช่วงได้ แต่ยังเพิ่มผู้ตรวจแบบที่เข้าใจระบบเดิมไม่ทันกำหนดส่ง โรงงานอาจเพิ่มพนักงานในกะได้ แต่ยังเพิ่มเครื่องจักรไม่ทัน ข้อจำกัดที่คงอยู่ทำให้การเพิ่มคนอาจเพิ่มงานได้น้อยกว่าที่คาด
ถ้าเปลี่ยนกรอบเวลาให้ยาวพอ ทางเลือกอาจรวมถึงฝึกคนใหม่ เปลี่ยนกระบวนการ ซื้อเครื่องจักร หรือออกแบบระบบใหม่ การตัดสินใจแก้งานสัปดาห์นี้กับการลงทุนเพื่อปีถัดไปจึงควรเขียนแยกกัน
ผลิตภาพ รายได้ กำไร และเงินสดตอบคนละคำถาม
ผลิตภาพ (productivity) เปรียบเทียบผลผลิตกับปัจจัยที่ใช้ จึงต้องบอกหน่วยและคุณภาพก่อน ฝ่ายผลิตอาจดูชิ้นงานผ่านคุณภาพต่อชั่วโมงเครื่องจักร พร้อมดูของเสีย ส่วนทีมซอฟต์แวร์อาจติดตามงานที่ผู้ใช้รับมอบ ระยะเวลาส่งมอบ และปัญหาหลังใช้งาน โดยไม่ถือว่าทุกงานยากเท่ากัน
จำนวนบรรทัดโค้ด จำนวนรายการงานที่ปิด หรือชั่วโมงที่บันทึกได้ให้ข้อมูลบางด้าน แต่แทนคุณค่าที่ลูกค้าได้รับทั้งหมดไม่ได้ สำหรับ Odoo Partner การใช้ความสามารถมาตรฐานแทนพัฒนาเพิ่มอาจตรงกับความต้องการของลูกค้าโดยใช้โค้ดน้อยลง ต้องเทียบความต้องการ ความเสี่ยง และภาระดูแลจริงด้วย
รายได้บอกมูลค่าที่กิจการรับรู้จากการขายตามหลักการที่ใช้ กำไรพิจารณารายได้หักค่าใช้จ่าย ส่วนเงินสดบอกเงินรับจ่ายที่เกิดขึ้นจริง งานที่รับรู้รายได้หรือกำไรแล้วอาจยังไม่ได้รับชำระ และเงินมัดจำที่เข้ามาก็ไม่ใช่กำไรทั้งหมดทันที
ในทางเศรษฐศาสตร์ เรายังพิจารณาต้นทุนค่าเสียโอกาสที่ไม่อยู่ในต้นทุนทางบัญชีด้วย เช่น เวลาของเจ้าของที่ใช้ได้กับทางเลือกอื่น ต้องระวังไม่คิดรายการเดิมซ้ำ อ่านความต่างของต้นทุนและกำไรทางบัญชีกับเศรษฐศาสตร์ใน OpenStax 7.1
โครงการซอฟต์แวร์จึงต้องดูงวดรับมอบกับงวดเก็บเงินควบคู่กัน โรงงานต้องดูด้วยว่าต้องจ่ายวัตถุดิบเมื่อไร สินค้าขายได้จริงแค่ไหน และลูกค้าจ่ายวันใด การทำงานได้เร็วขึ้นมีประโยชน์ แต่ไม่ได้ทำให้กำไรหรือเงินสดเพิ่มโดยอัตโนมัติ
ใช้แผ่นตัดสินใจหนึ่งหน้า ก่อนรับงานหรือเพิ่มกำลังผลิต
ผมอยากให้กรอบพื้นฐานเหล่านี้จบลงที่การประชุมที่ตัดสินใจได้ชัดขึ้น ลองใช้ตารางนี้กับงานจริงหนึ่งเรื่อง โดยบันทึกแหล่งข้อมูลและคนที่ต้องยืนยันตัวเลขไว้ด้วย
| คำถามก่อนตัดสินใจ | ทีมซอฟต์แวร์ / SI / Odoo | ฝ่ายผลิต |
|---|---|---|
| ใครต้องการซื้อ และเงื่อนไขใดต้องยืนยัน | งบ ผู้อนุมัติ ขอบเขต และเกณฑ์รับมอบ | คำสั่งซื้อ สเปก จำนวน และกำหนดส่ง |
| ทรัพยากรใดจำกัด และต้องปล่อยทางเลือกไหน | ผู้เชี่ยวชาญ เวลาทดสอบ และงานเดิมที่เบียดออก | ชั่วโมงเครื่องจักร วัสดุ และล็อตเดิมที่เลื่อน |
| ประโยชน์และต้นทุนใดเปลี่ยนเพราะทางเลือกนี้ | รายได้เพิ่ม งานทดสอบ ค่าบริการ และภาระดูแล | รายได้เพิ่ม วัสดุ ตั้งเครื่อง ของเสีย และส่งของ |
| อะไรจ่ายไปแล้ว และอะไรยังหลีกเลี่ยงได้ | งานพัฒนาเดิม เทียบค่าย้ายระบบและข้อผูกพัน | ค่าแม่พิมพ์เดิม เทียบราคาขายต่อและค่ายกเลิก |
| กติกาอาจชวนให้คนเร่งสิ่งใดเกินพอดี | ยอดเซ็นสัญญา จำนวนงานปิด และคุณภาพงานที่รับมอบ | จำนวนชิ้น ของเสีย งานแก้ไข และความปลอดภัย |
| เงินเข้าออกเมื่อไร และถ้าคาดผิดจะทำอย่างไร | งวดเก็บเงิน เงินสำรอง และจุดทบทวนขอบเขต | จ่ายวัสดุ เก็บสินค้า เครดิตลูกค้า และแผนสำรอง |
ตัวเลขในตารางควรแยกระหว่างสิ่งที่รู้กับสิ่งที่ประมาณ อย่าตีค่าประโยชน์ที่ยังไม่แน่ใจให้เท่ากับรายได้ที่รับประกันแล้ว ลองคำนวณกรณีที่งานใช้เวลามากขึ้น ลูกค้าจ่ายช้าลง หรือของเสียเพิ่มขึ้น แล้วดูว่าคำตัดสินเปลี่ยนตรงไหน
แบบจำลองช่วยแยกเหตุผล แต่ไม่ได้รู้ข้อมูลแทนเรา หากข้อสรุปไวต่อสมมติฐานข้อใด ควรหาข้อมูลข้อนั้นเพิ่มหรือกำหนดจุดทบทวน แทนการทำตัวเลขให้ละเอียดขึ้นทั้งที่ฐานยังไม่ชัด
ตอนถัดไปจะขยายทฤษฎีการผลิตและผลได้ส่วนเพิ่ม ทำไมเพิ่มคนหรือเพิ่มชั่วโมงแล้วงานอาจไม่เพิ่มตามสัดส่วน ส่วนอุปสงค์ ความยืดหยุ่น การตั้งราคา และภาพเศรษฐกิจมหภาคจะค่อยแยกเป็นตอน เพื่อให้มีพื้นที่ดูตัวอย่างและข้อจำกัดของแต่ละเรื่อง
คำถามที่พบบ่อย
เศรษฐศาสตร์พื้นฐานช่วยธุรกิจซอฟต์แวร์และฝ่ายผลิตอย่างไร
ช่วยแยกว่าธุรกิจกำลังเลือกอะไร มีข้อจำกัดตรงไหน ประโยชน์และต้นทุนใดเปลี่ยนตามทางเลือก และต้องเสียโอกาสอะไรไป ใช้ประกอบการรับงาน ตั้งราคา จัดกำลัง และลงทุนได้ โดยต้องปรับหน่วยวัดกับเงื่อนไขให้ตรงงาน ไม่ใช้จำนวนชั่วโมงหรือจำนวนชิ้นตัดสินเพียงอย่างเดียว
มีคนสนใจมาก แปลว่ามีอุปสงค์พร้อมซื้อแล้วหรือไม่
ยังสรุปไม่ได้ อุปสงค์ต้องมีทั้งความเต็มใจและความสามารถซื้อภายใต้ราคาและช่วงเวลาที่พิจารณา ควรตรวจงบ อำนาจอนุมัติ ความจำเป็น และทางเลือกที่ลูกค้ามี ก่อนนำความสนใจไปคาดเป็นยอดขาย
ควรรับทุกงานที่รายได้เพิ่มมากกว่าค่าใช้จ่ายเพิ่มหรือไม่
ยังต้องดูว่าต้นทุนที่เกี่ยวข้องครบหรือยัง รวมถึงค่าเสียโอกาส คุณภาพ ความเสี่ยง ข้อผูกพัน และจังหวะเงินสด งานอาจดูคุ้มบนตัวเลขเงินสดระยะสั้น แต่เบียดงานที่คุ้มกว่าหรือทำให้ผิดนัดลูกค้าเดิมได้
ที่มาของแนวคิด
ตอนนี้อธิบายแนวคิดเรื่องทรัพยากรที่มีจำกัด ค่าเสียโอกาส แรงจูงใจ อุปสงค์ อุปทาน การวิเคราะห์ส่วนเพิ่ม และต้นทุน เพื่อใช้ตั้งคำถามก่อนตัดสินใจรับงานหรือเพิ่มกำลังผลิต ขอบเขตนี้ยังไม่ครอบคลุมเศรษฐศาสตร์พื้นฐานทั้งหมด
นิยามและกรอบพื้นฐานในตอนนี้อ่านเพิ่มเติมได้จาก OpenStax, Principles of Economics 3e ตามลิงก์ในแต่ละหัวข้อ ส่วนสถานการณ์ธุรกิจ ตัวอย่างกติกาทีม และแผ่นตัดสินใจเป็นการประยุกต์ผ่านกรณีสมมติที่ผมสร้างเพื่อชวนตรวจงานจริง ไม่ใช่ผลทดลองที่ยืนยันว่าทุกองค์กรจะได้ผลเหมือนกัน
