North Star Metric Dashboard ที่ทุกคนเชื่อถือ

TL;DR

ทุกคนดูตัวเลข Cloud คนละตัว CFO ดูบิลรวม, CTO ดู cost per service, PO ไม่ดูเลย → ประชุมคุยกันไม่รู้เรื่อง
สร้าง Dashboard ใน Power BI ดึงข้อมูลจาก AWS CUR → S3 → Athena → Power BI
Cost per Booking 50 บาท (Fully Loaded) คือ North Star Metric ที่ทุกคนใช้ตัดสินใจจากฐานเดียวกัน

จากเครื่องคิดเลขสู่ระบบอัตโนมัติ

จำตอนที่ 1 ได้ไหมครับ? ที่ CTO หยิบเครื่องคิดเลขมากด Cost per Booking = 42 บาท โชว์ CFO กลางห้องประชุม เพื่อพิสูจน์ว่าบิล AWS ที่พุ่ง 40% ไม่ใช่ปัญหา

ตอนนั้นมันช่วยชีวิตเราไว้ แต่มันคือการ “คำนวณมือ” ที่หยาบและเสี่ยงต่อความผิดพลาด แถมยังไม่ได้รวม “ต้นทุนแฝง” อย่าง Shared Tools และค่าคนที่ดูแลระบบ

หลังจากนั้นเราผ่านอะไรมาบ้าง?

ตอน 4-5: ติด Tag เพื่อแยก Cost ตาม Service และ Team
ตอน 6: แยก COGS กับ OpEx เพื่อคำนวณ Gross Margin
ตอน 7: ทำ Showback/Chargeback เพื่อให้แต่ละทีมรับผิดชอบ

วันนี้ถึงเวลา “รวมร่าง” ทุกอย่างที่เรียนมา สร้างเป็น Dashboard อัตโนมัติที่แม่นยำกว่าเดิม

ทำไมต้องรอถึงตอนที่ 8?

ถ้าเราสร้าง Dashboard ตั้งแต่ตอนที่ 2 ข้อมูลจะ “มั่ว” เพราะยังไม่มี Tag แยก Cost, ยังไม่รู้ว่าอะไรคือ COGS, และยังไม่รู้ว่าทีมไหนใช้เท่าไหร่ Garbage In, Garbage Out

ประชุมที่คุยกันไม่รู้เรื่อง

หลังจากทำ Showback ในตอนที่แล้ว ทุกทีมเห็นตัวเลขของตัวเองแล้ว แต่ FinOps Practitioner สังเกตว่าทุกครั้งที่ประชุมเรื่อง Cloud Cost ยังมีปัญหาเดิม คือ ทุกคนดูตัวเลขคนละตัว

CFO เปิด AWS Bill แล้วพูดว่า

เดือนนี้จ่าย 2.1 ล้านบาท ลดลงจากเดือนก่อนได้ไหม?

CTO เปิด Cost Explorer แยกตาม service แล้วตอบว่า

Lambda ลดไม่ได้แล้ว ต้องไปดู RDS

Product Owner นั่งเงียบ เพราะไม่เคยดู Cloud Cost เลย ไม่รู้ว่าตัวเลขพวกนี้เกี่ยวอะไรกับ product ของตัวเอง

ประชุมจบ ไม่มีใครตัดสินใจอะไรได้ เพราะคุยกันคนละภาษา

ปัญหาที่พบบ่อย

CFO ดูบิลรวม, CTO ดู cost per service, Product Owner ไม่ดูเลย ทุกคนมี “ความจริง” คนละชุด ตัดสินใจจากฐานต่างกัน

ทางออก: สร้าง Dashboard ที่ทุกคนดูตรงกัน

FinOps Practitioner เสนอว่า

เราต้องมี Dashboard กลางที่ทุกคนเปิดดูได้ แสดงตัวเลขเดียวกัน ไม่ใช่ต่างคนต่างเปิด tool คนละตัว

ทำไมต้อง Power BI?

Tool	ข้อดี	ข้อเสีย
AWS Cost Explorer	ฟรี, ข้อมูล real-time	Customize ยาก, แชร์ให้คนนอก AWS ไม่ได้
Excel	ทุกคนใช้เป็น	Manual, ไม่ real-time, version control ยาก
Power BI	Customize ได้เต็มที่, แชร์ง่าย, connect หลาย data source	ต้องเรียนรู้, มีค่าใช้จ่าย
Looker / Tableau	Enterprise-grade	แพงกว่า Power BI

FinOps Practitioner เลือก Power BI เพราะ:

HotelGO ใช้ Microsoft 365 อยู่แล้ว มี Power BI Pro license
CFO และทีม Finance คุ้นเคยกับ Microsoft ecosystem
Connect กับ AWS ได้ผ่าน Athena

Architecture: จาก AWS สู่ Power BI

Step 1

AWS CUR → S3

AWS ส่ง Cost and Usage Report ไปเก็บใน S3 ทุกวัน

Step 2

S3 → Athena

ใช้ Athena query ข้อมูลจาก S3 ด้วย SQL

Step 3

Athena → Power BI

Power BI connect กับ Athena ผ่าน ODBC driver

Step 4

Power BI Dashboard

สร้าง Dashboard แสดง Cost per Booking

ทำไมต้องผ่าน Athena?

CUR (Cost and Usage Report) เป็นไฟล์ CSV/Parquet ขนาดใหญ่มาก (หลายล้านบรรทัด) Power BI ไม่สามารถ import ไฟล์ขนาดนี้โดยตรงได้

Athena ทำหน้าที่เป็น “SQL layer” ที่ query ข้อมูลจาก S3 ได้โดยไม่ต้อง import ทั้งหมด Power BI จึง connect กับ Athena แล้ว query เฉพาะข้อมูลที่ต้องการ

ค่าใช้จ่ายของ Architecture นี้

Component	ค่าใช้จ่าย/เดือน
S3 (เก็บ CUR)	~500 บาท
Athena (query)	~1,000 บาท
Power BI Pro	~350 บาท/user
รวม (5 users)	~3,250 บาท

เทียบกับ FinOps tools เฉพาะทาง (CloudHealth, Apptio) ที่เริ่มต้น 50,000+ บาท/เดือน ถือว่าประหยัดมาก

Fully Loaded Cost: ต้นทุนจริงทั้งหมด

ก่อนสร้าง Dashboard ต้องเข้าใจก่อนว่าจะแสดงตัวเลขอะไร

Fully Loaded Cost คืออะไร?

Fully Loaded Cost คือต้นทุน Cloud ที่รวมทุกอย่างแล้ว ไม่ใช่แค่บิล AWS แต่รวมค่าใช้จ่ายร่วมและค่าคนที่ดูแลระบบด้วย

เปรียบเทียบให้เห็นภาพ:

ราคาอาหารในเมนู = 200 บาท
บวกค่าบริการ 10% = 20 บาท
บวก VAT 7% = 16 บาท
จ่ายจริง = 236 บาท

Fully Loaded Cost คือราคา 236 บาทที่จ่ายจริง ไม่ใช่ 200 บาทในเมนู

องค์ประกอบของ Fully Loaded Cost

Fully Loaded Cost: จากบิล AWS สู่ต้นทุนจริง

Component	จำนวน	รายละเอียด
AWS Bill	2.1 ล้านบาท	ค่า AWS ทั้งหมด (COGS + OpEx)
Shared Tools	2.5 แสนบาท	Datadog, PagerDuty, Jira, Slack
Platform Overhead	1.5 แสนบาท	เงินเดือน DevOps/SRE ที่ support infrastructure
Fully Loaded	2.5 ล้านบาท

จาก 42 บาท สู่ 50 บาท: ตัวเลขที่แม่นยำกว่า

จำได้ไหมครับว่าตอนที่ 1 เราคำนวณ Cost per Booking ได้ 42 บาท? ตัวเลขนั้นคิดจากบิล AWS เพียวๆ (2.1 ล้าน ÷ 50,000 Bookings)

แต่ตอนนี้เรารู้แล้วว่าต้นทุนจริงมีมากกว่านั้น:

วิธีคำนวณ	ต้นทุน	Cost per Booking
ตอนที่ 1: AWS Bill เพียวๆ	2.1 ล้านบาท	42 บาท
ตอนที่ 8: Fully Loaded Cost	2.5 ล้านบาท	50 บาท

ตัวเลข 50 บาท นี้คือ “ความจริง” ที่แม่นยำกว่า เพราะรวมทุกต้นทุนที่เกี่ยวข้องกับการให้บริการ

Dashboard Design: 3 Layers

FinOps Practitioner ออกแบบ Dashboard เป็น 3 ระดับ

Layer 1: Executive Summary (สำหรับ CFO)

หน้าแรกที่เปิดมาต้องเห็นตัวเลขสำคัญทันที

Fully Loaded Cost 2.5 ล้านบาท เพิ่มขึ้น 5% จากเดือนก่อน

Bookings 50,000 เพิ่มขึ้น 10% จากเดือนก่อน

Cost per Booking 50 บาท ลดลง 5% จากเดือนก่อน

Key Insight: Cost เพิ่ม 5% แต่ Bookings เพิ่ม 10% → Cost per Booking ลดลง = ดี

Layer 2: Team Breakdown (สำหรับ Manager)

Drill down ดูว่าแต่ละทีมใช้ AWS เท่าไหร่ (ตัวเลขเดียวกับที่ทำ Chargeback ในตอนที่ 7)

Team	Cost	% of Total	Cost per Booking
Search	8.5 แสนบาท	40%	17 บาท
Booking	6 แสนบาท	29%	12 บาท
Payment	4.5 แสนบาท	21%	9 บาท
Shared	2 แสนบาท	10%	4 บาท
รวม (AWS Bill)	2.1 ล้านบาท	100%	42 บาท

หมายเหตุ: ตารางนี้แสดงเฉพาะ AWS Bill (2.1 ล้าน) ยังไม่รวม Shared Tools และ Platform Overhead

Layer 3: Service Detail (สำหรับ DevOps)

Drill down อีกชั้นดูว่าแต่ละ service ใช้เท่าไหร่ (ตัวเลขเดียวกับตอนที่ 4)

Service	Cost	% Change	Action
RDS	6 แสนบาท	+5%	ปกติ ตาม traffic
Lambda	5 แสนบาท	+15%	ตรวจสอบ function ที่ invoke เยอะ
ElastiCache	3 แสนบาท	0%	Fixed cost

North Star Metric: Cost per Booking

FinOps Practitioner พูดว่า

ตัวเลขที่สำคัญที่สุดใน Dashboard นี้คือ Cost per Booking เพราะมันเชื่อม Cloud Cost เข้ากับ Business Value

ทำไม Cost per Booking ถึงเป็น North Star?

North Star Metric คือตัวเลขหลักตัวเดียวที่ทุกคนในองค์กรใช้วัดความสำเร็จ

คุณสมบัติ	Cost per Booking
เข้าใจง่าย	✅ ทุกคนเข้าใจว่า “50 บาทต่อการจอง” หมายความว่าอะไร
วัดได้	✅ มีตัวเลขชัดเจน คำนวณได้ทุกวัน
ผูกกับธุรกิจ	✅ สะท้อนต้นทุนต่อหน่วยที่สร้าง Revenue
ทุกคนมีส่วนร่วม	✅ DevOps optimize ได้, Product ลด feature bloat ได้

แต่ละ Role ใช้ตัวเลขนี้ยังไง

CFO: ทุก Booking มีต้นทุน 50 บาท ได้ Revenue 450 บาท เหลือ Margin 400 บาท (88.9%)

CTO: ถ้า optimize ให้ Cost per Booking ลดเหลือ 45 บาท จะ ประหยัดได้ 2.5 แสนบาท/เดือน

Product Owner: Feature ใหม่ที่เพิ่ม Cloud Cost 1 แสนบาท/เดือน ต้องสร้าง Bookings เพิ่มอย่างน้อย 2,000 Bookings ถึงจะคุ้ม

Common Lexicon: พูดภาษาเดียวกัน

FinOps Practitioner เสริมว่า

นอกจาก Dashboard แล้ว ต้องตกลงคำศัพท์ให้ตรงกันด้วย

ตกลงคำศัพท์ให้ตรงกัน

คำ	หมายถึง	ไม่ใช่
”Cost”	Fully Loaded Cost	แค่บิล AWS
”Savings”	ต้องระบุ Gross หรือ Net	ตัวเลขลอยๆ
”Margin”	Revenue − Fully Loaded Cost	Revenue − AWS Bill

ต่อไปนี้เวลาประชุม ถ้าใครพูดว่า “Cost” ทุกคนจะเข้าใจตรงกันว่าหมายถึง Fully Loaded Cost

ผลลัพธ์: ประชุมครั้งถัดไป

หลังจากมี Dashboard แล้ว การประชุมเปลี่ยนไป

CFO เปิด Dashboard แล้วพูดว่า

Cost per Booking เดือนนี้ 50 บาท ลดลงจากเดือนก่อน 5% ดีมาก

CTO ตอบว่า

ใช่ครับ ทีม Search optimize Lambda ได้ Cost per Booking ของทีมลดจาก 18 บาท เหลือ 16 บาท

Product Owner พูดว่า

Feature ใหม่ที่ผมจะทำ คาดว่าเพิ่ม Bookings ได้ 5,000 ต่อเดือน แต่เพิ่ม Cost 1.5 แสนบาท Cost per Booking ของ feature นี้คือ 30 บาท ต่ำกว่าค่าเฉลี่ย 50 บาท น่าจะคุ้ม

ทุกคนใช้ตัวเลขเดียวกัน ตัดสินใจจากฐานเดียวกัน

สรุป

สิ่งที่ทำ	ผลลัพธ์
สร้าง Dashboard ใน Power BI	ทุกคนเห็นตัวเลขเดียวกัน
ดึงข้อมูลจาก CUR → Athena	ข้อมูล update ทุกวัน
กำหนด Cost per Booking เป็น North Star	ทุกคนใช้ตัดสินใจจากฐานเดียวกัน
ตกลง Common Lexicon	พูดภาษาเดียวกัน

บทเรียนจากตอนนี้:

บทเรียน	รายละเอียด
Dashboard ต้องมี 3 Layers	Executive → Team → Service ให้แต่ละ Role drill down ได้
North Star Metric ต้องผูกกับธุรกิจ	Cost per Booking ดีกว่า Total Cost เพราะเข้าใจง่ายและ actionable
Common Lexicon สำคัญ	ถ้าใช้คำต่างกัน ก็คุยกันไม่รู้เรื่อง

Action Item

FinOps: ตั้ง CUR → S3 → Athena pipeline
DevOps: ช่วย setup ODBC connection
CFO: Review Dashboard design ก่อน publish
ทุกคน: ใช้ Cost per Booking เป็นตัวเลขหลักในการตัดสินใจ

ตอนนี้ HotelGO มี Dashboard ที่ทุกคนดูตรงกันแล้ว CTO เห็นว่า Lambda คือต้นทุนก้อนใหญ่ที่ผันผวนตาม traffic จึงคิดจะล็อคราคาด้วย Savings Plans หวังประหยัด 17% ตอนหน้าจะเล่าว่าเกิดอะไรขึ้นเมื่อซื้อ Savings Plans ตาม Peak usage โดยลืมคิดเรื่อง Low Season