FinOps ไม่ใช่การลดค่าใช้จ่าย Cloud ซะหน่อย

ค่าใช้จ่าย Cloud พุ่งขึ้น 40%

เช้าวันจันทร์ CFO เปิด AWS Cost Explorer ดูตามปกติ เห็นค่าใช้จ่ายเดือนที่แล้วพุ่งจาก 1.5 ล้านบาท เป็น 2.1 ล้านบาท เพิ่มขึ้น 40% ทั้งที่เดือนก่อนหน้ายังปกติดี

AWS Cost Explorer คืออะไร?

เครื่องมือของ AWS ที่แสดงค่าใช้จ่าย cloud แบบละเอียด ดูได้ว่าแต่ละ service ใช้เงินเท่าไหร่ แนวโน้มเป็นยังไง เหมือนแอปธนาคารที่แสดงรายจ่ายแยกตามหมวดหมู่

ไม่ถึงครึ่งชั่วโมงก็มีนัดประชุมด่วนโผล่ในปฏิทินของ CTO กับทีม DevOps พร้อมข้อความว่า

ค่า cloud ขึ้น 40% ต้องลดให้ได้ภายในเดือนนี้

เมื่อ CTO เปิดเข้ามาในห้องประชุม เห็นกราฟที่ CFO ฉายบนจอ เส้นค่าใช้จ่ายพุ่งขึ้นชัดเจน แต่แทนที่จะตกใจ เขากลับบอกว่า

เดี๋ยวดูตัวเลขให้ครบก่อนละกัน ผมว่ามันอาจไม่ได้แย่อย่างที่คิด

ทำไม CFO ถึงตกใจ แต่ CTO กลับไม่? เพราะทั้งคู่มองตัวเลขคนละมุม ฝั่ง CFO เห็น ค่าใช้จ่ายที่เพิ่มขึ้น ส่วน CTO เห็น ค่าใช้จ่ายที่สัมพันธ์กับธุรกิจ มาดูกันว่าตัวเลขจริงๆ บอกอะไร

แนะนำ HotelGO (แอปสมมุติ)

ก่อนจะไปดูตัวเลข มาทำความรู้จัก HotelGO กันก่อน

HotelGO เป็นแอปที่ผมสมมุติขึ้นเพื่อใช้อธิบายเรื่อง FinOps เป็นแอปจองโรงแรมออนไลน์ เหมือน Agoda หรือ Booking.com

รายได้ของ HotelGO มาจากไหน?

HotelGO ไม่ได้เป็นเจ้าของโรงแรม แต่เป็นตัวกลางที่เก็บค่าธรรมเนียม 15% จากทุกการจอง

• ลูกค้าจองโรงแรมราคา 3,000 บาท
• HotelGO เก็บ commission 15% = 450 บาท
• โรงแรมได้รับ 2,550 บาท

ดังนั้น revenue ของ HotelGO คือ 450 บาท ต่อการจอง ไม่ใช่ 3,000 บาท

Tech Stack ระบบหลังบ้านของ HotelGO

ระบบทั้งหมดรันบน AWS ด้วย stack นี้ (เป็นการสมมุติขึ้นมาเช่นกัน):

Service	หน้าที่
API Gateway และ Lambda	รับ request + ประมวลผล (search, booking, payment)
RDS	ฐานข้อมูลหลัก (โรงแรม, การจอง, ผู้ใช้)
ElastiCache	cache ข้อมูลที่ใช้บ่อย ให้โหลดเร็วขึ้น
S3 และ CloudFront	เก็บรูปโรงแรม + ส่งหน้าเว็บให้เร็ว

ศัพท์ Tech สำหรับคนไม่ใช่สาย IT

• Lambda = คิดถึงคอมพิวเตอร์ที่ทำงานและคิดเงินเราเฉพาะตอนที่ใช้ ไม่ใช้ก็ไม่เสียเงิน
• RDS = ฐานข้อมูลที่เก็บข้อมูลทั้งหมด (เหมือนไฟล์ Excel ขนาดใหญ่)
• ElastiCache = หน่วยความจำชั่วคราวที่เก็บข้อมูลที่ใช้บ่อยให้ดึงได้เร็ว
• CloudFront = เครือข่ายที่กระจายข้อมูลไปทั่วโลก ให้โหลดเร็วไม่ว่าอยู่ที่ไหนบนโลก

Variable Cost vs Fixed Cost: หัวใจของเรื่องนี้

จุดสำคัญที่ต้องเข้าใจคือ ค่า cloud ไม่ได้โตตาม traffic แบบเส้นตรง เพราะมี 2 ประเภท:

1. Variable Cost (ต้นทุนผันแปร)

• ต้นทุนที่จ่ายตามการใช้งานจริง ใช้มากจ่ายมาก ใช้น้อยจ่ายน้อย
• Lambda ยิ่งมี request การใช้งานเยอะ ยิ่งจ่ายเยอะ
• เหมือนค่าไฟ ใช้มากจ่ายมาก ใช้น้อยจ่ายน้อย

2. Fixed Cost (ต้นทุนคงที่)

• ต้นทุนที่จ่ายเท่าเดิมทุกเดือน ไม่ว่า traffic จะมากหรือน้อย
• RDS หรือ ElastiCache จ่ายตาม instance size ที่เลือก
• เหมือนค่าเช่าออฟฟิศ ไม่ว่าจะมีพนักงานกี่คน ค่าเช่าก็เท่าเดิมจนกว่าที่นั่งจะไม่พอ

ดูตัวเลขให้ครบก่อนค่อยตัดสินใจ

CTO เปิด dashboard ขึ้นมาแล้วพูดว่า

ก่อนจะลดอะไร มาดูตัวเลขทั้งหมดกันก่อน ไม่ใช่แค่ค่าใช้จ่าย cloud

แล้วก็เริ่มอธิบายทีละตัว

ตัวเลขที่ 1: จำนวนการจอง (Bookings) เพิ่มขึ้นเท่าไหร่?

จำนวนการจอง (bookings) คือจำนวนการจองที่สำเร็จ ซึ่งเป็น ตัวขับเคลื่อนธุรกิจหลัก ของ HotelGO

Metric	เดือนก่อน	เดือนนี้	เปลี่ยนแปลง
ค่า AWS	1.5 ล้านบาท	2.1 ล้านบาท	เพิ่มขึ้น 40%
Bookings	30,000	50,000	เพิ่มขึ้น 67%

CFO เห็นแค่บรรทัดแรก คือ ค่า AWS เพิ่มขึ้น 40% แต่ CTO ชี้ให้ดูว่าจำนวนการจองโตจาก 30,000 เป็น 50,000 นั่นคือ เพิ่มขึ้น 67% ซึ่งหมายความว่า ธุรกิจโตเร็วกว่าค่า cloud

ตัวเลขที่ 2: Revenue เพิ่มขึ้นเท่าไหร่?

จำได้ไหมว่า HotelGO เก็บ commission 15% ต่อการจอง? ถ้าราคาห้องเฉลี่ยคือ 3,000 บาท ดังนั้น revenue ต่อการจอง ก็จะเท่ากับ 450 บาท

Metric	เดือนก่อน	เดือนนี้	เปลี่ยนแปลง
Revenue (450 บาท × Bookings)	13.5 ล้านบาท	22.5 ล้านบาท	เพิ่มขึ้น 67%

สังเกตว่า revenue โตตามจำนวนการจอง เพราะทั้งคู่เป็นสัดส่วนกัน

ตัวเลขที่ 3: Cost per Booking คืออะไร?

นี่คือ unit metrics ที่สำคัญที่สุด คำนวณง่ายๆ โดยการนำค่า cloud หารด้วยจำนวนการจอง

• เดือนก่อน: 1,500,000 ÷ 30,000 = 50 บาท ต่อการจอง
• เดือนนี้: 2,100,000 ÷ 50,000 = 42 บาท ต่อการจอง

Metric	เดือนก่อน	เดือนนี้	เปลี่ยนแปลง
Cost per Booking	50 บาท	42 บาท	ลดลง 16%

ตัวเลขนี้ยิ่งน้อยยิ่งดี มันบ่งบอกว่า ระบบมีประสิทธิภาพดีขึ้น รองรับคนได้มากขึ้นในราคาที่ถูกลง

ตัวเลขที่ 4: Cloud as % of Revenue คืออะไร?

ตัวนี้บอกว่า ค่า cloud กินสัดส่วนรายได้เท่าไหร่ คำนวณจาก (ค่า AWS ÷ revenue) × 100

• เดือนก่อน: (1.5 ÷ 13.5) × 100 = 11.1%
• เดือนนี้: (2.1 ÷ 22.5) × 100 = 9.3%

Metric	เดือนก่อน	เดือนนี้	เปลี่ยนแปลง
Cloud as % of Revenue	11.1%	9.3%	ลดลง 1.8%

ยิ่งตัวเลขนี้ต่ำยิ่งดี แปลว่าธุรกิจโตเร็วกว่าต้นทุน

ภาพรวมทั้งหมด

Metric	เดือนก่อน	เดือนนี้	เปลี่ยนแปลง
ค่า AWS	1.5 ล้านบาท	2.1 ล้านบาท	เพิ่มขึ้น 40%
Bookings	30,000	50,000	เพิ่มขึ้น 67%
Revenue	13.5 ล้านบาท	22.5 ล้านบาท	เพิ่มขึ้น 67%
Cost per Booking	50 บาท	42 บาท	ลดลง 16%
Cloud as % of Revenue	11.1%	9.3%	ลดลง 1.8%

จากตารางจะเห็นว่า มีแค่บรรทัดเดียวที่เป็นสีแดง (ค่า AWS) ที่เหลือเขียวหมด ค่าใช้จ่ายที่เพิ่มขึ้นนี้เป็นสัญญาณที่ดี ไม่ใช่ปัญหา

ทำไมค่า Cloud ถึงโตช้ากว่าธุรกิจ?

1. RDS และ ElastiCache เป็น Fixed Cost: จ่ายเท่าเดิมไม่ว่าจะมีการจอง 30,000 หรือ 50,000 ครั้ง
2. Cache ช่วยลดการเรียก Lambda: request บางส่วนถูก ElastiCache ดักไว้ ไม่ต้องเรียก Lambda ทุกครั้ง ยิ่ง traffic เยอะ cache hit rate ยิ่งสูง

อัตราการเติบโต: ธุรกิจ vs ค่า Cloud (% เทียบเดือนก่อน)

ดูจากกราฟจะเห็นชัดว่าแท่งการเติบโตของรายได้ (สีเขียว) สูงกว่าแท่งการเติบโตของค่า AWS (สีส้ม) ทุกเดือน และยิ่งห่างขึ้นเรื่อยๆ ซึ่งแปลว่า ธุรกิจโตเร็วกว่าต้นทุน นี่คือสัญญาณที่ดี ไม่ใช่ปัญหา

Unit Metrics: ตัวชี้วัดความเก่งของทีม Tech

CTO ชี้ให้เห็นว่า ยอดค่าใช้จ่าย cloud ที่เพิ่มขึ้นไม่ได้เกิดจากความสิ้นเปลือง แต่เกิดจากการใช้งานที่มากขึ้น สิ่งที่เราต้องดูคือ “ต้นทุนต่อหน่วยผลิต” หรือที่เรียกว่า Unit Metrics

ตัวเลข 42 บาท ต่อการจองที่คำนวณไปเมื่อกี้ คือตัวชี้วัด efficiency (ประสิทธิภาพ) ของระบบ แปลว่าทีม engineer ปรับจูนระบบได้เก่งขึ้น รองรับคนได้มากขึ้นในราคาที่ถูกลง (ต่อหัว)

Unit Economics: ตัวชี้วัดความอยู่รอดของบริษัท

แต่… แค่ระบบ “ประหยัดขึ้น” ไม่ได้แปลว่าบริษัทจะ “รวยขึ้น” เสมอไป CFO จะยังไม่วางใจจนกว่าจะเห็นตัวเลขชุดถัดมา นั่นคือ Unit Economics

ในขณะที่ unit metrics สนใจแค่รายจ่าย แต่ unit economics จะเอารายรับมาเทียบด้วย เพื่อตอบคำถามว่า “ยิ่ง scale ยิ่งกำไร หรือ ยิ่งขาดทุนกันแน่?”

สมการความอยู่รอดจากกำไรเบื้องต้น (Contribution Margin)

เราลองมาถอดสมการกำไรต่อการจอง 1 ครั้งของ HotelGO กันอีกรอบ

• Revenue per Booking (รายได้): 22.5 ล้านบาท ÷ 50,000 การจอง = 450 บาท
• Cost per Booking (ต้นทุน cloud): คำนวณเมื่อกี้ = 42 บาท
• Contribution Margin (กำไรเบื้องต้น): 450 - 42 = 408 บาท

แปลว่า ทุกๆ การจอง 1 ครั้ง หลังจากหักค่า cloud แล้ว บริษัทจะเหลือเงิน 408 บาท (Contribution Margin) เงินก้อนนี้คือกำไรเบื้องต้นที่จะเอาไปจ่ายเงินเดือนพนักงาน ค่าเช่าออฟฟิศ และเป็นกำไรสุทธิ

สรุปง่ายๆ คือ ยิ่งมีการจองเยอะ → ตัวคูณ 408 บาทก็ยิ่งเยอะ → บริษัทยิ่งรวย

แล้วถ้า Unit Economics พังจะเป็นยังไง?

สมมติทีม marketing จัดโปรโมชั่นลดแหลกจนรายได้ต่อการจองเหลือแค่ 30 บาท

• Revenue per Booking: 30 บาท
• Cost per Booking: 42 บาท
• Contribution Margin: 30 - 42 = -12 บาท

แบบนี้คือ Unit Economics ติดลบ ยิ่ง scale (คนจองเยอะ) บริษัทยิ่ง “ขาดทุนสะสม” เร็วขึ้น ถ้าเจอแบบนี้ต้องรีบหาสาเหตุ ไม่ใช่ดีใจที่คนเข้าแอปเยอะ

Economies of Scale: ทำไมยิ่งโต ต้นทุนยิ่งถูก?

กลับมาที่เคสปัจจุบันที่ Cost per Booking ลดจาก 50 เหลือ 42 บาท มันเกิดจากสิ่งที่เรียกว่า Economies of Scale หรือการประหยัดต่อขนาด

ใน HotelGO เรามี fixed cost (ต้นทุนคงที่) เช่น ค่า Database (RDS) เดือนละ 4.5 แสนบาท ซึ่งเราจ่ายเท่าเดิมไม่ว่าจะมีลูกค้ากี่คน

• ตอนมี 30,000 การจอง: ค่า RDS ตกอยู่ที่ 15 บาท/การจอง
• ตอนมี 50,000 การจอง: ค่า RDS ตกอยู่ที่ 9 บาท/การจอง (ถูกลง 40%)

ยิ่งเรา scale ธุรกิจให้ใหญ่ขึ้น ตัวหาร (จำนวนการจอง) ยิ่งเยอะ ทำให้ต้นทุนต่อหน่วยถูกลงเรื่อยๆ

สรุป: อย่าปล่อยให้ตัวเลขหลอกตา

CTO พูดปิดท้ายการประชุมว่า

ค่า cloud 2.1 ล้านอาจจะดูน่าตกใจ แต่ถ้าดู unit economics แล้วพบว่าเรากำไร 408 บาททุกครั้งที่มีการจอง ผมว่านี่คือค่าใช้จ่ายแห่งความสำเร็จครับ

3 Metrics ที่ต้องดูคู่กับค่า Cloud เสมอ

การทำ FinOps ไม่ใช่แค่การกดดันให้ลด cost แต่คือการมองบริบทให้รอบด้าน ทุกครั้งที่เห็นค่า cloud เพิ่มขึ้น ให้ถามตัวเองด้วย 3 คำถามนี้

Metric	สูตร	ดูเพื่ออะไร	ยิ่ง… ยิ่งดี
Cost per Booking	ค่า Cloud ÷ จำนวนการจอง	ทีม Tech จูนระบบดีไหม? (Efficiency)	ต่ำ
Cloud as % of Revenue	(ค่า Cloud ÷ Revenue) × 100	ต้นทุนกินสัดส่วนรายได้เยอะไปไหม? (Health)	ต่ำ
Contribution Margin	Revenue ต่อหน่วย − Cost ต่อหน่วย	ธุรกิจยิ่งโตยิ่งกำไรไหม? (Profitability)	สูง

ถ้าทั้ง 3 ตัวนี้เขียวหมด การที่ค่าใช้จ่ายรวม (total spend) จะพุ่งขึ้น 40% หรือ 100% ก็ไม่ใช่ปัญหา แต่มันคือสัญญาณว่าธุรกิจกำลังรุ่ง