คำถามที่ผู้บริหารถามหลังอนุมัติ Claude Code ให้ทีมพัฒนาคือ "เดือนนี้จ่ายเท่าไร และได้อะไรกลับมา" ซึ่งเป็นคำถามที่ตอบไม่ได้ถ้าไม่ตั้งเครื่องมือวัดไว้ตั้งแต่ต้น บทความนี้สรุปว่าค่าใช้จ่ายเกิดจากอะไร คุมอย่างไร วัดผลด้วยอะไรได้บ้าง และตัวเลขไหนที่ไม่ควรใช้วัด
ค่าใช้จ่ายเกิดจากสองส่วน
ส่วนแรกคือ ค่าที่นั่ง ซึ่งคาดเดาได้ จ่ายรายเดือนต่อคน ที่นั่งที่รวมสิทธิ์ใช้ Claude Code มีราคาสูงกว่าที่นั่งมาตรฐานหลายเท่า และออกแบบมาให้มีปริมาณการใช้งานพอสำหรับการทำงานหนึ่งวันตามปกติ
ส่วนที่สองคือ การใช้งานส่วนเกิน ซึ่งคิดตามอัตรา API เมื่อทีมใช้เกินปริมาณที่มากับที่นั่ง ส่วนนี้เองที่ทำให้งบเดือนหนึ่งไม่เท่ากับอีกเดือนหนึ่ง และเป็นส่วนที่ต้องตั้งเพดาน
องค์กรที่ประเมินงบผิดมักผิดเพราะคูณจำนวนพนักงานทั้งหมดด้วยราคาที่นั่งแพง ทั้งที่ควรนับแยกสองกลุ่ม คือคนที่ต้องเขียนโค้ดจริงกับคนที่ไม่ต้อง (วิธีนับที่นั่งแยกกลุ่ม)
คุมไม่ให้บานปลายอย่างไร
ตั้งเพดานก่อนเปิดใช้ ไม่ใช่หลังได้บิล บนแผน Enterprise ผู้ดูแลตั้งเพดานค่าใช้จ่ายได้ทั้งระดับองค์กรและระดับผู้ใช้รายคน ซึ่งเป็นวิธีที่ตรงที่สุด เพราะการใช้งานหนักของคนไม่กี่คนกระทบงบรวมได้มากกว่าที่คาด
ตั้งเพดานความพยายามในการคิดของโมเดล งานประจำวันส่วนใหญ่ไม่ต้องใช้ระดับสูงสุด การจำกัดเพดานนี้ผ่านนโยบายระดับองค์กรช่วยลดค่าใช้จ่ายได้โดยคุณภาพงานทั่วไปไม่ตก (ตั้งผ่าน managed settings)
จำกัดรายการโมเดลที่เลือกได้ เพื่อไม่ให้ทุกงานวิ่งไปที่โมเดลที่แพงที่สุดโดยอัตโนมัติ
สอนทีมว่างานแบบไหนคุ้ม ข้อนี้ได้ผลกว่าการตั้งค่าใด ๆ งานที่คุ้มคือการอ่านโค้ดเก่า เขียนเทสต์ และแก้บั๊กที่ต้องไล่หลายไฟล์ ส่วนงานที่ไม่คุ้มคือสิ่งที่นักพัฒนาพิมพ์เองเสร็จในสองนาที
วัดผลด้วยอะไรได้บ้าง
มีสามชั้น เลือกตามสิ่งที่ต้องรายงาน
ชั้นที่ 1 หน้าสถิติสำเร็จรูป สำหรับองค์กรบนแผน Team และ Enterprise มีหน้าสถิติที่ดูภาพการใช้งานและการมีส่วนร่วมของทีมได้ทันที ไม่ต้องตั้งอะไร เหมาะกับการดูว่าทีมไหนเริ่มใช้จริงและทีมไหนเงียบ
ชั้นที่ 2 รายงานค่าใช้จ่ายรายคน ตัวเลขการใช้งานและค่าใช้จ่ายรายผู้ใช้อยู่ในรายงานค่าใช้จ่ายในหน้าตั้งค่าขององค์กร ซึ่งเป็นคนละที่กับหน้าสถิติ จุดนี้ทำให้หลายองค์กรหาไม่เจอ
ชั้นที่ 3 ดึงออกมาเข้าระบบของเราเอง องค์กรบนแผน Enterprise ดึงข้อมูลการใช้งานและค่าใช้จ่ายรายคนผ่าน API ได้ และส่งข้อมูลการทำงานออกมาในรูปแบบมาตรฐานอย่าง OpenTelemetry เข้าระบบติดตามที่องค์กรใช้อยู่ได้ เหมาะกับองค์กรที่ต้องรวมตัวเลขนี้เข้ารายงานรวมของฝ่าย IT
ตัวเลขที่ไม่ควรใช้วัดผล
อย่าวัดด้วยจำนวนบรรทัดโค้ดหรือสัดส่วนโค้ดที่ AI เขียน ตัวเลขพวกนี้ขึ้นได้ง่ายโดยคุณภาพลดลง และถ้าเอาไปผูกกับการประเมินผลพนักงาน จะได้พฤติกรรมที่ทำให้ตัวเลขสวยแต่ระบบแย่ลง
อย่าวัดด้วยอัตราการยอมรับข้อเสนอแนะเพียงอย่างเดียว มันบอกว่าคนกดรับบ่อยแค่ไหน ไม่ได้บอกว่างานดีขึ้นหรือไม่
ตัวเลขที่ควรใช้
วัดสิ่งที่ทีมสนใจอยู่แล้วก่อนมี AI สามตัว
- เวลาตั้งแต่รับงานจนขึ้นใช้จริง ตัวชี้วัดที่ตรงกับคุณค่าทางธุรกิจที่สุด
- จำนวนรอบแก้ในการรีวิว ถ้าเพิ่มขึ้น แปลว่าความเร็วที่ได้มาถูกย้ายไปเป็นภาระของคนรีวิว
- อัตราบั๊กที่หลุดไปโปรดักชัน ตัวคุมคุณภาพ ถ้าตัวนี้ขึ้น ผลที่ได้ไม่ใช่กำไร
วัดฐานทั้งสามตัวก่อนเริ่มเสมอ เพราะไม่มีตัวเลขก่อนหน้า ก็พิสูจน์อะไรไม่ได้ในรอบงบถัดไป (วิธีวัดผล AI ที่ผู้บริหารเชื่อ)
รายงานหน้าเดียวสำหรับผู้บริหาร
โครงที่ผ่านห้องประชุมงบประมาณได้มีห้าบรรทัด คือ จำนวนที่นั่งและค่าใช้จ่ายรวมเดือนนี้ · สัดส่วนคนที่ได้ที่นั่งแล้วใช้จริงอย่างน้อยสัปดาห์ละครั้ง · ตัวเลขฐานกับตัวเลขปัจจุบันของสามตัวชี้วัดข้างบน · งานตัวอย่างหนึ่งชิ้นที่เล่าได้ว่าเปลี่ยนไปอย่างไร · และสิ่งที่จะทำต่อในรอบถัดไป
อ่านต่อ
บทความนี้อยู่ในคลัสเตอร์Claude ในองค์กร ควรอ่านคู่กับClaude Code ในองค์กรและการวาง managed settings ส่วนหลักการวางงบอบรมและโครงการ AI ทั้งองค์กรอยู่ที่วิธีวางงบอบรม AI