OKR dashboard ส่วนใหญ่ในองค์กรไทยไม่ใช่ dashboard จริง — มันคือ slide deck ที่อัพเดทเดือนละครั้ง หรือ Excel sheet ที่อัพเดทตอน quarter end ก่อนประชุมใหญ่ ทีมจะรู้ว่า KR ไหนกำลังจะ miss target ก็ตอนที่มันสายเกินจะแก้ไปแล้ว
Dashboard ที่ทำงานจริงต้องตอบคำถามเดียวภายใน 10 วินาที: “ตอนนี้เราอยู่ตรงไหนของ quarter — และมี KR ไหนที่กำลังหลุด track” ถ้าผู้บริหารต้องเปิดไฟล์ 3 ไฟล์ ถามคน 2 คน เพื่อจะตอบคำถามนี้ — แปลว่า OKR dashboard ของคุณไม่ใช่ infrastructure แต่คือพิธีกรรมรายเดือน บทความนี้จะแยกให้ชัดว่า dashboard ที่ทีมใช้จริงต้องประกอบด้วยอะไร และทำไม Excel ถึงไม่พอเมื่อองค์กรโตเกิน 3 ทีม
ทำไม OKR Dashboard ส่วนใหญ่ไม่มีใครเปิด
ปัญหาไม่ใช่เพราะทีมขี้เกียจ แต่เพราะ dashboard ส่วนใหญ่ออกแบบมาให้ “รายงาน” ไม่ใช่ “ตัดสินใจ” — เมื่อเปิดแล้วไม่ได้ข้อมูลที่ใช้ทำงานทันที คนก็เลิกเปิด นี่คือ failure pattern ที่เห็นซ้ำในองค์กรไทย:
- อัพเดทช้าเกินไป — dashboard อัพเดทรายเดือน (หรือไตรมาส) ทำให้ข้อมูลล้าสมัยตั้งแต่วันที่ 3 ของเดือนใหม่
- ไม่ show trajectory — เห็นแค่ score ปัจจุบัน เช่น KR1 = 45% แต่ไม่รู้ว่ามันควรจะอยู่ที่ 50% ตอนนี้ตามแผน หรือ on track อยู่แล้ว
- ไม่ filter ตาม role — CEO เห็นแบบเดียวกับ IC ทำให้ทุกคนต้อง scroll ผ่าน OKR ของทีมอื่นที่ไม่เกี่ยวข้อง
- ไม่มี alert — KR drop จาก confidence 0.7 เหลือ 0.3 ไม่มีใครรู้จนกว่าจะถึง check-in รอบถัดไป
- Effort สูงในการ maintain — ใครสักคนต้อง copy ข้อมูลจากแต่ละทีมมาใส่ slide ทุกเดือน — งานนี้คนแรกที่ลาออกคือคนที่ทำ dashboard
ถ้าทีมต้อง “เตรียม dashboard” ก่อนประชุม แทนที่จะ “เปิด dashboard” ระหว่างทำงาน — แปลว่า dashboard กลายเป็นภาระ ไม่ใช่ infrastructure การ ตั้งและติดตาม OKRs อย่างมีประสิทธิภาพ ต้องมี dashboard ที่อัพเดทเองโดย workflow ปกติ ไม่ใช่ต้องมีคนนั่งกรอกตอนสิ้นเดือน
6 องค์ประกอบที่ OKR Dashboard ใช้งานได้จริงต้องมี
จากการดู dashboard ที่ทีมใช้จริง vs dashboard ที่เปิดแค่ตอนประชุม — ความต่างอยู่ที่ 6 element ต่อไปนี้:
1. Real-time Progress View ต่อ Objective + KR
แสดง current value vs target value พร้อม trend line ของ 4–8 สัปดาห์ล่าสุด ไม่ใช่แค่ตัวเลข % — เพราะ 60% ที่ขึ้นเป็น trend กับ 60% ที่ flat 3 สัปดาห์เป็นคนละสถานการณ์ ผู้บริหารต้องเห็น velocity ของ KR ไม่ใช่แค่ snapshot ทีมที่ดู trajectory จะ intervene ได้ก่อน KR หลุด track 2–3 สัปดาห์
2. Confidence Score (0.0–1.0) อัพเดทรายสัปดาห์
Confidence score คือ self-assessment ของ owner ว่า “คิดว่าจะถึงเป้าหรือไม่” ตั้งแต่ 0.0 (แน่ใจว่าทำไม่ทัน) ถึง 1.0 (มั่นใจ 100%) — ต้องอัพเดททุกสัปดาห์ ไม่ใช่ทุกไตรมาส เพราะ confidence ที่ลดจาก 0.7 → 0.4 ในสองสัปดาห์เป็น early warning signal ที่ progress % อย่างเดียวบอกไม่ได้
3. Owner + Dependency View
ทุก KR ต้องมี single owner (ไม่ใช่ทั้งทีม) และต้อง show ว่า KR นี้ depend อยู่กับใคร — เช่น KR ทีม Marketing ที่รอ landing page จาก Engineering ถ้า Engineering ดีเลย์ Marketing ต้องเห็นใน dashboard ทันที ไม่ใช่รู้ตอนสิ้นเดือนแล้วโทษกัน
4. Trajectory / Forecast vs Target
นี่คือ element ที่ Excel dashboard ส่วนใหญ่ขาด — แสดงเส้นจริง vs เส้นที่ “ควรจะอยู่” ตามจังหวะของ quarter เช่น KR target = 100, ผ่านไป 6 สัปดาห์จาก 13 สัปดาห์ ควรอยู่ที่ ~46 ถ้าตอนนี้อยู่ที่ 30 = behind pace อย่างชัดเจน Trajectory ทำให้ “on track” / “at risk” / “off track” เป็น objective ไม่ใช่ความรู้สึก
5. Alert เมื่อ KR ออกนอก Track
Dashboard ที่ดีต้อง push notification (Slack / email) เมื่อ KR drop ต่ำกว่า threshold — เช่น confidence < 0.4 หรือ progress ห่างจาก expected pace เกิน 15% ผู้บริหารไม่ควรต้องเปิด dashboard เพื่อ "หา" ปัญหา — dashboard ต้องบอกว่ามีปัญหา
6. Role-based View
CEO ควรเห็น company-level OKR + roll-up ของแต่ละ department — ไม่ใช่ทุก KR ของทุกคน Manager เห็น team OKR + individual KR ของลูกทีม IC เห็น KR ของตัวเองเป็นหลัก พร้อม context ของ team OKR ที่ตัวเอง contribute ดู role-based view แต่ละชั้นต้อง configurable ไม่ใช่ทุกคนเห็นหน้าเดียวกัน
ตัวอย่าง Layout — Company / Department / Team Views
Dashboard เดียวกันต้องแสดง 3 layer ที่แตกต่าง — เพราะคำถามที่แต่ละ role ต้องตอบไม่เหมือนกัน:
| Level | เห็นอะไร | ทำไมต้องเห็นแค่นี้ |
|---|---|---|
| Company View (CEO / Founder) | 5–7 Company Objectives + roll-up confidence ของแต่ละ department + alert ของ KR ที่ off-track เกิน 2 สัปดาห์ | CEO ตัดสินใจระดับ resource allocation — ไม่ต้องเห็น KR รายตัว แต่ต้องเห็นว่า department ไหนกำลังพัง |
| Department View (Department Head / VP) | Department Objectives + KR ทุกตัวของทีมตัวเอง + dependency กับทีมอื่น + trajectory line | Department Head ต้อง intervene ระดับ team — ต้องเห็น velocity และ blocker ที่มาจากทีมอื่น |
| Team / IC View (Manager / Individual) | KR ที่ตัวเอง own + tasks ที่เชื่อมกับ KR + check-in form รายสัปดาห์ | IC ต้องการ workspace ทำงาน ไม่ใช่ executive overview — dashboard ต้องเป็น work surface |
ความผิดพลาดทั่วไปคือทำ dashboard เดียวให้ทุกคนใช้ — สุดท้าย IC รู้สึกว่ามัน overkill, CEO รู้สึกว่ามัน noisy ทุกคนเลิกใช้
Excel vs Software Dashboard — เปรียบเทียบที่เห็นจริง
Excel ทำ OKR dashboard ได้ — ในทีม 5 คนที่อยู่ห้องเดียวกัน เมื่อองค์กรเกิน 20 คน หรือ 3 ทีมขึ้นไป Excel จะเริ่ม break ที่จุดเดียวกันทุกครั้ง:
| Capability | Excel / Google Sheets | Software Dashboard |
|---|---|---|
| Maintenance effort | สูง — ต้องมีคน copy/paste ข้อมูลจากแต่ละทีมทุกสัปดาห์ | ต่ำ — owner อัพเดทเอง dashboard rolled up อัตโนมัติ |
| Real-time updating | ไม่มี — อัพเดทเมื่อมีคนเปิดไฟล์ | มี — sync ทันทีเมื่อ owner เปลี่ยน progress |
| Alert capability | ไม่มี (หรือต้องเขียน macro) | มี — push ไป Slack / email ตาม rule |
| Role-based filtering | ไม่มี — ทุกคนเห็น sheet เดียวกัน | มี — view แตกต่างตาม role / team |
| Version control | ไม่มี — “v3_final_FINAL2.xlsx” | มี — audit log ทุก change |
| Dependency tracking | Manual — ต้องเขียนเอง | Built-in — link KR ↔ KR ระหว่างทีม |
เรื่องนี้ลึกกว่าที่คิด — รายละเอียดของ trade-off ทั้งหมดดูได้ที่ OKR ด้วย Excel หรือ Software ที่เปรียบเทียบเงื่อนไขที่ทีมควรย้าย
Cadence ที่ Dashboard ต้องรองรับ
Dashboard ที่ทำงานจริงต้องรับน้ำหนัก 4 cadence ที่ต่างกัน — ถ้ารองรับไม่ครบ ทีมจะกลับไปใช้ Excel เสริม:
- Daily glance (Manager) — เปิด 30 วินาทีตอนเช้า เห็นว่ามี KR ไหน drop confidence ตั้งแต่เมื่อวาน เพื่อเอาไปคุยใน standup
- Weekly check-in (Team) — ทีม update progress + confidence + blocker ทุกสัปดาห์ — workflow นี้ต้องอยู่ใน dashboard ไม่ใช่ Google Form แยก ดู structure ของ check-in ได้ที่ Weekly OKR Check-in Template
- Monthly review (Department) — Department Head ดู trajectory เทียบกับ plan, ตัดสินใจ rebalance KR ที่ไม่ realistic
- Quarterly scoring (Company) — CEO + ทีม leadership ทำ scoring สิ้นไตรมาส — ขั้นตอนนี้ต้องอ้าง data ทั้งไตรมาส ไม่ใช่ความจำ ใช้ OKR Scoring Method เป็น standard ไม่ให้แต่ละทีมให้คะแนนต่างกัน
Dashboard ที่รองรับแค่ quarterly scoring (= slide สิ้นไตรมาส) คือ dashboard ที่ตายระหว่าง quarter — ทีมไม่มีอะไรดูระหว่างสัปดาห์
5 ข้อผิดพลาดในการสร้าง OKR Dashboard
- Manual update only — ใช้คนกรอก Excel ทุกศุกร์ ทำได้ 4 สัปดาห์แล้วเลิก เพราะคนทำลาออกหรือเบื่อ
- No trajectory — แสดงแค่ % ปัจจุบัน ไม่มีเส้น expected pace ทำให้ “45%” อาจจะ on track หรือ off track ก็ได้ ไม่มีทางรู้
- No alerts — ปล่อยให้ผู้ใช้ “หา” ปัญหาเอง — ผลคือไม่มีใครเปิด dashboard ระหว่างสัปดาห์
- No role-based view — CEO เห็นเหมือน IC ทำให้ทุก role รู้สึกว่า dashboard “ไม่ใช่ของฉัน”
- Design ไม่ scannable ใน 10 วินาที — ถ้าผู้บริหารต้อง scroll เกิน 1 หน้าจอเพื่อจะเห็นภาพรวม company status — dashboard fail แล้ว
เมื่อ Dashboard กลายเป็น Infrastructure
ในจุดหนึ่งของการเติบโต ทีมจะรู้ว่า OKR dashboard ไม่ใช่ “reporting tool” แต่คือ operating system ของการตัดสินใจ — ทุก decision ที่ดีต้องอ้าง data ใน dashboard, ทุก meeting ต้องเปิด dashboard ก่อนเริ่มคุย, ทุก 1-on-1 ต้องดู KR confidence ของลูกทีม
นี่คือจุดที่ Excel หยุดพอ และ platform แบบ myOKR / EsteeMATE เริ่มสมเหตุสมผล — ไม่ใช่เพราะ feature เยอะกว่า แต่เพราะองค์กรต้องการ infrastructure ที่ทำงานต่อเนื่องโดยไม่ขึ้นกับว่าใครยังอยู่ในทีมที่กรอก Excel การลงทุนใน dashboard infrastructure ที่ออกแบบสำหรับ OKR โดยเฉพาะคือสิ่งที่แยกองค์กรที่ “พยายามใช้ OKR” ออกจากองค์กรที่ “ใช้ OKR เป็นระบบจริง”
คำถามที่ต้องตอบก่อนวางแผน quarter ถัดไป: OKR dashboard ของทีมคุณแสดง progress แบบ real-time — หรือต้องรอ slide รายเดือน?