เมื่อต้นทุนเฉลี่ยไม่พอ: ทำไมธุรกิจต้องเห็นต้นทุนจริงในระดับ Job

TechCut — Technical Case Study · AXONS Cost Production Platform Project

ถ้าถามว่าธุรกิจมี “ต้นทุนการผลิต” เท่าไหร่ คำตอบที่หลายองค์กรมักมีอยู่แล้ว คือ “ต้นทุนเฉลี่ย”

เฉลี่ยต่อตัน เฉลี่ยต่อล็อต เฉลี่ยตามจำนวนสินค้าที่ผลิตออกมา

ในหลายสถานการณ์ ตัวเลขเฉลี่ยอาจเพียงพอสำหรับการดูภาพรวมของธุรกิจ

แต่เมื่อคำถามเปลี่ยนจาก “ต้นทุนเฉลี่ยของสินค้ากลุ่มนี้เท่าไหร่?” เป็น:

“Job นี้กำไรจริง ๆ เท่าไหร่?” “Batch นี้คุ้มไหมที่จะผลิตต่อ?” “ต้นทุนที่สูงขึ้นเกิดจาก Activity ไหนกันแน่?”

ตัวเลขเฉลี่ยเริ่มไม่พอ

เพราะในการผลิตจริง แต่ละ Job ไม่ได้ใช้ทรัพยากรเท่ากัน บาง Job ผ่านหลายขั้นตอนกว่า บาง Batch ต้อง re-process บางรายการข้ามบาง process บางต้นทุนถูกยกมาจากรอบก่อนหน้า

ถ้าทุกอย่างถูกเฉลี่ยรวมกันหมด ธุรกิจอาจเห็นภาพรวมที่ดูถูกต้อง แต่ตัดสินใจผิดในระดับปฏิบัติการได้

นี่คือโจทย์สำคัญของ AXONS และเป็นเหตุผลที่ Muze ได้เข้ามาช่วยออกแบบและพัฒนา Cost Production Platform ที่ไม่ได้ทำหน้าที่แค่ “คำนวณเร็วขึ้น” แต่ช่วยเปลี่ยนวิธีมองต้นทุน — จากระดับเฉลี่ย ไปสู่ระดับ Job ที่สะท้อนความเป็นจริงของการผลิตมากขึ้น

ปัญหาที่ Excel ไม่ได้ผิด แต่เริ่มไม่พอ

ก่อนมีระบบนี้ AXONS ใช้ Excel ในการคำนวณต้นทุนการผลิต

ซึ่งไม่ได้แปลว่า Excel ไม่ดี หรือทีมทำงานไม่เก่ง ในความเป็นจริง Excel เป็นเครื่องมือที่ยืดหยุ่นมาก และมักเป็นจุดเริ่มต้นของหลาย business process ที่สำคัญในองค์กร

แต่เมื่อกระบวนการผลิตมีความซับซ้อนมากขึ้น จำนวน transaction เพิ่มขึ้น ข้อมูลมาจากหลายระบบ และ business logic เริ่มมีเงื่อนไขมากขึ้น — Excel ก็เริ่มกลายเป็นข้อจำกัด

AXONS มีธุรกิจหลักที่เกี่ยวข้องกับกระบวนการผลิตหลายรูปแบบ ได้แก่ เมล็ดพันธุ์ข้าวโพด (Corn Seed) และ ปุ๋ยเคมี (Chemical Fertilizer) แต่ละหน่วยธุรกิจมีลักษณะการผลิตต่างกัน มี Activity ต่างกัน มีวิธีที่ต้นทุนไหลผ่านระบบต่างกัน และมีเงื่อนไขเฉพาะของตัวเอง

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

1. ต้นทุนถูกเฉลี่ยข้ามทุก Job

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

Job ที่มีกระบวนการซับซ้อนกว่า ใช้เวลาและทรัพยากรมากกว่า อาจได้รับต้นทุนต่ำกว่าความเป็นจริง ในขณะที่ Job ที่ง่ายกว่า อาจต้องแบกรับต้นทุนเฉลี่ยมากเกินไป

ผลลัพธ์คือ ธุรกิจอาจเข้าใจผิดว่า Job บางประเภทมีกำไร ทั้งที่จริงอาจไม่ได้กำไรเท่าที่คิด

2. ไม่สามารถ trace ต้นทุนกลับสู่ Job จริงได้

คำถามที่สำคัญสำหรับธุรกิจไม่ใช่แค่ “ต้นทุนรวมเท่าไหร่” แต่คือ “ต้นทุนนี้มาจากไหน”

ถ้าระบบ trace กลับไม่ได้ว่าต้นทุนเกิดจาก Activity ใด มีต้นทุนจาก process ก่อนหน้าถูกส่งต่อมาหรือไม่ มีการ re-process หรือ skip process เกิดขึ้นหรือเปล่า — ตัวเลขต้นทุนสุดท้ายก็อาจตอบได้แค่ว่า “ประมาณนี้” แต่ไม่สามารถอธิบายที่มาได้

และเมื่ออธิบายที่มาไม่ได้ ความเชื่อมั่นในตัวเลขก็จะลดลง

Core Insight: ต้นทุนไม่ได้อยู่แค่ใน Activity เดียว แต่มันไหลต่อกัน

หัวใจของระบบนี้ไม่ใช่การเปลี่ยน Excel ให้เป็น Web App และไม่ใช่แค่การทำ automation เพื่อให้คำนวณเร็วขึ้น

แต่คือการเปลี่ยนวิธีคิดเรื่องต้นทุน

ในการผลิตจริง Activity หนึ่งอาจไม่ได้จบในตัวเอง Output ของ Activity หนึ่งอาจกลายเป็น Input ของ Activity ถัดไป

ถ้า Activity A ผลิต semi-finished product แล้ว Activity B นำผลผลิตนั้นไปใช้ต่อ — ต้นทุนของ Activity A ต้องถูกส่งต่อไปยัง Activity B ด้วย และถ้า Activity C ใช้ผลผลิตจาก Activity B ต่ออีกทอดหนึ่ง — ต้นทุนจาก A และ B ก็ต้องถูกส่งต่อไปถึง C

นี่คือแนวคิดที่เราเรียกว่า Cost Forwarding by Dependency Degree

Activity A → ผลิต Output X
Activity B → ใช้ Output X + วัตถุดิบอื่น → ผลิต Output Y
Activity C → ใช้ Output Y → ผลิต Finished Product

ต้นทุนของ Finished Product =
  ต้นทุนของ Activity C
  + ต้นทุนของ Activity B (forwarded)
  + ต้นทุนของ Activity A (forwarded ผ่าน B)

ถ้าระบบไม่เข้าใจ dependency เหล่านี้ ตัวเลขต้นทุนสุดท้ายจะผิดตั้งแต่โครงสร้าง ไม่ใช่ผิดแค่สูตร

จาก Business Logic สู่ Dependency Graph

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

แนวคิดสำคัญคือการสร้าง Dependency Graph ที่แสดงความสัมพันธ์ระหว่าง Activity ต่าง ๆ ว่า Activity ใดต้องถูกคำนวณก่อน Activity ใดต้องรับต้นทุนต่อ และต้นทุนควรถูกส่งต่อไปยังจุดใดใน chain การผลิต

ในเชิง engineering ระบบใช้แนวคิด Topological Sort เพื่อจัดลำดับการประมวลผลตาม dependency ของ Activity ให้แน่ใจว่า Activity ที่เป็นต้นทางจะถูกคำนวณก่อน Activity ที่นำ output ไปใช้ต่อเสมอ

สถาปัตยกรรมของ AXONS Cost Production Platform

ระบบถูกออกแบบเป็น 4 Module ที่ทำงานร่วมกัน ตั้งแต่การรับข้อมูลจากระบบ ERP เดิม ไปจนถึงการคำนวณต้นทุนสุดท้ายในระดับ Job

Module 1: Data Parsing

หน้าที่ของส่วนนี้คือรับข้อมูลจาก QSoft ผ่าน ETL pipeline (Apache NiFi) แล้วแปลงข้อมูลให้อยู่ในรูปแบบที่ระบบใหม่สามารถประมวลผลได้ ทั้ง stock transaction, expense line items, production records และข้อมูล Job/Batch แต่ละรอบ

ความสำคัญของ Data Parsing ไม่ได้อยู่แค่การแปลง format แต่รวมถึงการ validate ข้อมูลก่อนเข้าสู่ระบบคำนวณ เพราะถ้าข้อมูลต้นทางผิด — Cost Calculation Engine ที่อยู่ปลายทางก็จะคำนวณผิดตามไปด้วย

Module 2: Activity Resolver

หลังจากข้อมูลถูก parse เข้ามาแล้ว ระบบต้องแปลง raw transaction ให้กลายเป็น Activity ที่มีความหมายในบริบทของการผลิต

คำถามที่ module นี้ต้องตอบ เช่น transaction นี้เป็นส่วนหนึ่งของ Activity ไหน อยู่ใน Job ใด อยู่ในหน่วยธุรกิจใด รายการนี้เป็นต้นทุนปัจจุบัน หรือต้นทุนที่ยกมาจากรอบก่อนหน้า

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

Module 3: Cost Component

เมื่อระบบรู้แล้วว่า transaction แต่ละรายการเกี่ยวข้องกับ Activity ใด ขั้นตอนถัดไปคือการจัดกลุ่มต้นทุนตามประเภท:

• Material — วัตถุดิบที่ใช้ในการผลิต
• Labor — ค่าแรงโดยตรง
• Overhead — ค่าใช้จ่ายของโรงงาน เช่น ค่าไฟ ค่าน้ำ ค่าเสื่อมราคา
• General Expense — ค่าใช้จ่ายทั่วไปที่ต้องปันส่วนตาม logic ที่กำหนด

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

Module 4: Cost Calculation Engine

ส่วนที่เป็นหัวใจของระบบ Engine นี้รับ Dependency Graph, Cost Component, และ business rule ของการ forward cost เข้ามาพร้อมกัน จากนั้นคำนวณต้นทุนตามลำดับ dependency และส่งต่อต้นทุนตาม Cost Forwarding Logic

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

Tech Stack ที่ใช้ในระบบ

จาก ECS Monolith ถึง EKS

ในช่วงเริ่มต้น ระบบสามารถเริ่มจาก architecture แบบ Containerized Monolith บน AWS ECS ที่รวม 4 Module ไว้ด้วยกัน เหมาะสำหรับช่วงแรกที่ต้องการ deploy และ manage ได้ง่าย

เมื่อระบบโตขึ้นและ module ต่าง ๆ มีความต้องการ scale ไม่เท่ากัน architecture ก็สามารถพัฒนาไปสู่ EKS-based architecture พร้อม Kong API Gateway เพื่อให้ scale แต่ละ service ได้อิสระ

นี่คือแนวทางที่ practical สำหรับ enterprise system หลายประเภท — ไม่จำเป็นต้องเริ่มจาก microservices ที่ซับซ้อนตั้งแต่วันแรก แต่ต้องออกแบบให้มีทางไปต่อเมื่อ scale และ complexity เพิ่มขึ้น

Scenario พิเศษที่ไม่ใช่ Edge Case

ระบบคำนวณต้นทุนที่ดีต้องไม่ได้รองรับเฉพาะ happy path ในกระบวนการผลิตจริง มักมี scenario พิเศษที่เกิดขึ้นเป็นประจำ

Re-process

บาง Batch อาจต้องถูกนำกลับมาผ่านกระบวนการเดิมอีกครั้ง เช่น QC ไม่ผ่าน หรือผลลัพธ์จากขั้นตอนก่อนหน้าไม่เป็นไปตามเงื่อนไข

ในกรณีนี้ ต้นทุนของการ re-process ต้องถูกบันทึกและนำไปรวมในต้นทุนของ Batch นั้นอย่างถูกต้อง ระบบต้องเข้าใจว่า re-process เป็นส่วนหนึ่งของ journey ของ Batch เดิม ไม่ใช่ transaction แยกที่ไม่มีความสัมพันธ์กับงานก่อนหน้า

Skip Process

ในบางกรณี Batch อาจข้ามบางขั้นตอนของกระบวนการผลิต เนื่องจาก condition ของวัตถุดิบหรือเงื่อนไขเฉพาะของ production flow

ฟังดูเป็นเรื่องตรงไปตรงมา แต่ในระบบที่มี dependency ซับซ้อน การ skip process ส่งผลต่อ Dependency Graph และ cost forwarding logic ด้วย ระบบต้องสามารถปรับ Graph ให้สอดคล้องกับ process จริงที่เกิดขึ้น ไม่ใช่บังคับให้ทุก Batch เดินตาม process มาตรฐานเดียวกันทั้งหมด

BF Cost: Brought Forward Cost

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

ระบบต้องสามารถแยก BF Cost ออกจาก Current Period Cost ได้อย่างชัดเจน เพื่อให้การ reconcile กับข้อมูลบัญชีถูกต้อง และเพื่อให้ทีมธุรกิจเข้าใจว่าต้นทุนที่เห็นในรอบนี้เกิดจาก activity ปัจจุบันเท่าไหร่ และเป็นต้นทุนที่ยกมาจากอดีตเท่าไหร่

ผลลัพธ์: จากคำนวณเร็วขึ้น สู่การตัดสินใจที่แม่นขึ้น

หนึ่งในผลลัพธ์ที่เห็นได้ชัดคือเวลาคำนวณลดลง จากเดิมที่ใช้เวลาประมาณ 1 วันทำการต่อรอบ เหลือประมาณ 15 นาที

แต่สำหรับโปรเจกต์นี้ ความเร็วไม่ใช่ value หลักที่สุด

value ที่สำคัญกว่าคือความแม่นยำและความน่าเชื่อถือของตัวเลข

เมื่อทีมธุรกิจถามว่า “Job นี้กำไรเท่าไหร่?” — ระบบสามารถให้คำตอบที่มีที่มาที่ไป ไม่ใช่แค่ตัวเลขเฉลี่ยจากภาพรวม

เมื่อทีมต้องตัดสินใจว่า Batch แบบใดควรผลิตต่อ หรือ process ไหนควรปรับปรุง — ระบบสามารถ drill down กลับไปดูได้ว่าต้นทุนกระจุกตัวอยู่ที่ Activity ใด

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

4 บทเรียนจากการสร้างระบบนี้

1. Business Logic ต้องมาก่อน Code

Dependency Graph และ Cost Forwarding ไม่ใช่แค่ technical design แต่เป็นการแปลง logic ของธุรกิจให้กลายเป็นระบบ ถ้าไม่เข้าใจกระบวนการผลิตจริง ไม่เข้าใจว่า Activity ใดส่งผลต่อ Activity ใด — Architecture ที่ออกแบบมาก็อาจผิดตั้งแต่ต้น

ในระบบประเภทนี้ code ที่ทำงานได้ ไม่ได้แปลว่าระบบถูกต้อง ตัวเลขที่ถูกต้องต้องเริ่มจาก business logic ที่ถูกต้องก่อน

2. Data Quality คือ Foundation ของ Calculation Accuracy

Calculation Engine จะดีแค่ไหนก็ไม่พอ ถ้าข้อมูลต้นทางถูก parse ผิด หรือ Activity ถูก resolve ผิด Data Parsing และ Activity Resolver จึงเป็น module ที่ critical มาก เพราะเป็นด่านแรกที่กำหนดว่าข้อมูลจะเข้าสู่ระบบคำนวณอย่างถูกต้องหรือไม่

3. Special Scenario คือ Business Reality

Re-process, Skip Process และ BF Cost เกิดขึ้นเป็นประจำใน production cycle ถ้าระบบรองรับเฉพาะ process มาตรฐาน ระบบอาจดูดีใน demo แต่ใช้งานจริงแล้วตัวเลขจะเริ่มไม่น่าเชื่อถือ Enterprise system ที่ดีต้องเข้าใจ reality ของ operation จริง ไม่ใช่ออกแบบจาก happy path อย่างเดียว

4. Speed เป็น Benefit แต่ Accuracy คือ Value

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

สำหรับองค์กรที่ยังใช้ Excel กับ Logic สำคัญของธุรกิจ

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

แต่เมื่อ logic นั้นเริ่มสำคัญต่อการตัดสินใจ เมื่อข้อมูลเริ่มใหญ่ขึ้น เมื่อผู้ใช้งานมากขึ้น และเมื่อตัวเลขต้องถูก trace กลับได้ — คำถามอาจไม่ใช่ “ควรเลิกใช้ Excel หรือยัง?” แต่คือ:

“Business logic ใดใน Excel ที่สำคัญพอจะถูกยกระดับเป็นระบบจริง?”

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

บทสรุป

AXONS Cost Production Platform เป็นตัวอย่างของระบบที่ไม่ได้เริ่มจากคำถามว่า “อยากได้ software แบบไหน?” แต่เริ่มจากคำถามที่ลึกกว่า:

“ตัวเลขแบบไหนที่ธุรกิจยังตอบไม่ได้ แต่จำเป็นต้องตอบให้ได้?”

เมื่อคำถามชัด — Architecture ก็เริ่มชัด Module ก็เริ่มชัด และ technology stack ก็กลายเป็นเครื่องมือในการทำให้ business logic นั้นเกิดขึ้นจริง

นี่คือบทบาทของ Muze ในฐานะ Tech Partner ไม่ใช่แค่สร้างระบบให้ใช้งานได้ แต่ช่วยองค์กรแปลง business complexity ให้กลายเป็น digital platform ที่ตัดสินใจได้ดีขึ้น แม่นขึ้น และ scale ได้จริง

Muze ช่วยองค์กรออกแบบและสร้าง Digital Platform ที่เชื่อม Business Logic, Data Architecture และ Engineering เข้าด้วยกัน — เพื่อให้ technology ไม่ได้แค่ทำงานได้ แต่สร้างผลลัพธ์ทางธุรกิจได้จริง

คุยกับทีม Muze →