Information Technology Governance

Dual Operating Model: เมื่อองค์กรต้องทำงานสองมิติพร้อมกัน จาก Functional Excellence สู่ Enterprise Value Creation

องค์กรไม่จำเป็นต้องเลือกว่าจะเป็น Function หรือ Outcome

จากตอนที่ 3 เราได้เห็นว่าองค์กรจำเป็นต้องขยับจาก Output-Based ไปสู่ Outcome-Based และจากตอนที่ 4 เราได้เห็นว่า เมื่อ Outcome ต้องอาศัยหลาย Function ทำงานร่วมกัน องค์กรจึงต้องมี Outcome Owner เพื่อให้เกิด Accountability ที่ชัดเจน แต่เมื่อมาถึงตรงนี้ จะเกิดคำถามสำคัญอีกข้อหนึ่งว่า

“ถ้า Outcome ต้องทำงานข้าม Function แล้วเรายังจำเป็นต้องมี Functional Organization อยู่หรือไม่?” คำตอบคือ ยังจำเป็น เพราะองค์กรยังต้องมีความเชี่ยวชาญเฉพาะด้าน

IT ยังต้องดูแล Technology

Finance ยังต้องดูแล Financial Management

HR ยังต้องดูแล People Capability

Risk ยังต้องดูแล Risk และ Control

Marketing ยังต้องดูแล Brand และ Customer Acquisition

Operations ยังต้องดูแล Operational Excellence

ปัญหาจึงไม่ใช่การมี Functional Organization แต่คือการที่องค์กรมี Functional Organization เพียงมิติเดียว เมื่อทุกอย่างถูกออกแบบตาม Function องค์กรจะเก่งในการบริหาร “ส่วน” แต่เมื่อโลกธุรกิจต้องการ Value ที่เกิดจากหลายส่วนทำงานร่วมกัน องค์กรก็จำเป็นต้องมีอีกมิติหนึ่งเข้ามาเสริม นั่นคือ Outcome / Value Dimension จึงเกิดแนวคิดที่เรียกว่า Dual Operating Model ซึ่งหมายถึงการที่องค์กรสามารถบริหาร Functional Excellence และ Outcome & Value Creation ไปพร้อมกัน โดยไม่จำเป็นต้องทำลายโครงสร้างเดิมทั้งหมด

1. ทำไม Functional Organization เพียงอย่างเดียวจึงไม่เพียงพอ?

Functional Organization มีข้อดีอย่างมาก เพราะช่วยให้องค์กรสร้างความเชี่ยวชาญ ตัวอย่างเช่น

IT สามารถพัฒนาความเชี่ยวชาญด้าน Technology

Finance สามารถสร้างมาตรฐานด้าน Financial Management

HR สามารถพัฒนาความสามารถด้าน People

Risk สามารถสร้างมาตรฐานด้าน Risk Management

และแต่ละ Function สามารถพัฒนาคน กระบวนการ และความรู้ของตัวเองได้อย่างต่อเนื่อง นี่คือสิ่งที่เรียกว่า Functional Excellence แต่ปัญหาจะเกิดขึ้นเมื่อองค์กรต้องสร้าง Outcome ที่อยู่ระหว่างหลาย Function

ตัวอย่างเช่น

Improve Customer Experience

Outcome นี้ไม่ได้อยู่ใน Department ใด Department หนึ่ง

แต่ต้องอาศัย

Marketing
   ↓
Sales
   ↓
Product
   ↓
Operations
   ↓
Customer Service
   ↓
IT / Data / AI

หากทุก Function Optimize ตัวเอง แต่ไม่มีใคร Optimize End-to-End Journey องค์กรอาจมีหลาย Function ที่ทำงานได้ดี แต่ Customer Experience โดยรวมไม่ได้ดีขึ้นตามไปด้วย นี่คือปัญหาของ Functional Optimization เมื่อเทียบกับ Enterprise Optimization

2. Function Optimization กับ Enterprise Optimization

ลองพิจารณาตัวอย่างง่าย ๆ สมมติ Customer Service ต้องการลดต้นทุน จึงกำหนด KPI ว่า Average Handling Time ต้องลดลง พนักงานจึงพยายามให้บริการแต่ละ Case ให้เร็วขึ้น

ในมุมของ Function

AHT ↓

ดูเหมือนเป็นผลลัพธ์ที่ดี แต่ถ้าลูกค้าได้รับคำตอบไม่ครบ ลูกค้าอาจต้องติดต่อกลับอีกครั้ง ทำให้

Repeat Contact ↑

และ

Customer Effort ↑

เมื่อมองในระดับ Enterprise ต้นทุนรวมอาจไม่ได้ลดลงจริง นี่คือความแตกต่างระหว่าง Local Optimization กับ Enterprise Value Optimization

Functional Organization ช่วยให้แต่ละส่วนทำงานได้ดี แต่ Dual Operating Model ต้องเพิ่มความสามารถในการถามว่า “เมื่อทุกส่วนรวมกันแล้ว องค์กรสร้าง Value ได้ดีขึ้นหรือไม่?”

3. Dual Operating Model คืออะไร?

ในบริบทของ Outcome-Based Organization สามารถอธิบายง่าย ๆ ได้ว่า

องค์กรหนึ่งองค์กรทำงานอยู่บนสองมิติพร้อมกัน

มิติที่ 1 — Functional Dimension

เน้น

• ความเชี่ยวชาญ
• มาตรฐาน
• Governance
• Capability
• People Development
• Professional Practice
• Risk & Control
• Resource Management

มิติที่ 2 — Outcome Dimension

เน้น

• Strategic Outcomes
• Value Streams
• Customer Outcomes
• Business Outcomes
• Cross-functional Collaboration
• Value Creation
• Enterprise Impact

จึงสามารถมองเป็นภาพได้ว่า

สองมิตินี้ไม่ได้แข่งขันกัน แต่ทำหน้าที่คนละอย่าง Function สร้างความแข็งแรงของ Capability ขณะที่ Outcome สร้างการเชื่อม Capability เหล่านั้นเข้าด้วยกัน

4. Function เป็น “บ้าน” แต่ Outcome เป็น “สนามที่ต้องลงไปเล่น”

แนวคิดหนึ่งที่ช่วยอธิบาย Dual Operating Model ได้ง่ายคือ Functional Home + Outcome Team

Functional Home คือพื้นที่ที่บุคลากรมี

• หัวหน้า
• Career Path
• Professional Development
• Knowledge
• Standards
• Methodology
• Community of Practice

แต่เมื่อองค์กรมี Strategic Outcome สำคัญ บุคลากรจากหลาย Functional Home สามารถเข้ามาทำงานร่วมกันใน Outcome Team ตัวอย่างเช่น

ดังนั้น คนคนหนึ่งอาจมี Functional Home หนึ่งแห่ง แต่สามารถมี Outcome Assignment หลายช่วงเวลา ตาม Strategic Priority ขององค์กร

5. แล้วสองมิตินี้ต่างกันอย่างไร?

จะเห็นว่าทั้งสองมิติไม่ได้ทับซ้อนกันทั้งหมด และนี่คือเหตุผลที่องค์กรไม่ควรพยายามบังคับให้ Function ทำหน้าที่เป็น Outcome Team หรือในทางกลับกัน เพราะจะทำให้ทั้งสองบทบาทสูญเสียความแข็งแรง

6. Dual Operating Model ไม่ใช่ Matrix Organization แบบเดิมทั้งหมด

เมื่อพูดถึงโครงสร้างสองมิติ หลายคนอาจนึกถึง Matrix Organization ทันที แต่ Dual Operating Model ในบริบทนี้ไม่จำเป็นต้องหมายถึง Matrix ที่มี Reporting Line สองสายแบบเต็มรูปแบบ ประเด็นสำคัญกว่า Reporting Line คือ การสร้างสองกลไกในการบริหาร กลไกหนึ่งดูแล Functional Excellence อีกกลไกหนึ่งดูแล Outcome & Value Creation

ดังนั้นองค์กรสามารถออกแบบระดับความซับซ้อนให้เหมาะกับตัวเองได้

บางองค์กรอาจใช้

• Cross-functional Squad

บางองค์กรอาจใช้

• Product Team

บางองค์กรอาจใช้

• Value Stream Team

บางองค์กรอาจใช้

• Strategic Initiative Team

และบางองค์กรอาจใช้

• Enterprise Outcome Team

สิ่งสำคัญไม่ใช่ชื่อของโครงสร้าง แต่คือ สามารถสร้าง Accountability ต่อ Outcome ได้จริงหรือไม่

7. Value Stream คือสะพานเชื่อม Function กับ Outcome

ใน Dual Operating Model แนวคิด Value Stream จะกลายเป็นองค์ประกอบสำคัญ เพราะ Function บอกว่า “ความเชี่ยวชาญอยู่ที่ไหน?” แต่ Value Stream บอกว่า “คุณค่าถูกสร้างขึ้นอย่างไรตั้งแต่ต้นจนจบ?”

ตัวอย่างเช่น

Customer Need
      ↓
Marketing
      ↓
Sales
      ↓
Onboarding
      ↓
Product Usage
      ↓
Customer Service
      ↓
Customer Success
      ↓
Customer Retention
      ↓
Customer Lifetime Value

แต่ละขั้นตอนอาจมี Functional Owner ต่างกัน แต่ Value Stream ต้องมองเป็นภาพเดียว จึงเกิดบทบาทของ Value Stream Owner หรือในบางบริบทอาจใช้ Outcome Owner เป็นผู้ดูแลภาพรวม เพื่อให้แน่ใจว่า Value ไม่ตกหล่นระหว่างรอยต่อของ Function

8. ปัญหาใหญ่ไม่ได้อยู่ใน Function แต่อยู่ที่ “รอยต่อ”

องค์กรจำนวนมากลงทุนอย่างมากในการพัฒนาแต่ละ Function แต่ปัญหาที่สร้างความเสียหายจริงอาจไม่ได้เกิดภายใน Function แต่อยู่ที่ Handover

ตัวอย่างเช่น

Marketing ส่ง Lead ให้ Sales

Sales ส่งลูกค้าให้ Operations

Operations ส่งข้อมูลให้ Finance

Finance ส่งข้อมูลให้ Customer Service

Customer Service ส่ง Feedback กลับ Product

แต่ละฝ่ายอาจทำงานได้ตามมาตรฐาน แต่ข้อมูลอาจสูญหายระหว่างทาง ลูกค้าอาจต้องอธิบายเรื่องเดิมซ้ำ Decision อาจช้า และไม่มีใครมองเห็นปัญหาทั้งเส้น นี่คือเหตุผลว่า Value Leakage มักเกิดที่รอยต่อระหว่าง Function ไม่ใช่เฉพาะภายใน Function ดังนั้น Dual Operating Model ต้องออกแบบ Cross-functional Interfaces ให้ชัดเจน

9. จาก Handover สู่ Collaboration

องค์กรแบบเดิมมักทำงานในลักษณะ Function A → ส่งงาน → Function B จึงมีลักษณะคล้ายสายพาน แต่ Outcome-Based Organization ต้องเปลี่ยนไปสู่ Function A + B + C → Outcome แทน

ตัวอย่างเช่น หาก Outcome คือ Improve Digital Customer Adoption แทนที่จะให้

IT → สร้าง Application

Marketing → ทำ Campaign

Customer Service → ทำคู่มือ

Product → ออก Feature

แต่ละฝ่ายทำงานของตัวเอง Outcome Team ควรทำงานร่วมกันตั้งแต่ต้น

จึงเปลี่ยนจาก Handover Model ไปสู่ Collaboration Model

10. Outcome Team ไม่ได้ทำให้ Function อ่อนแอลง

ข้อกังวลที่เกิดขึ้นได้คือ “ถ้าเอาคนเก่งจาก Function ไปทำ Outcome Team แล้ว Function จะเหลืออะไร?”

คำตอบคือ องค์กรต้องออกแบบ Capacity ให้เหมาะสม เพราะ Functional Home ยังคงเป็นแหล่งสร้าง Capability Outcome Team เป็นกลไกนำ Capability นั้นไปใช้กับ Strategic Priority จึงสามารถคิดเป็น

FUNCTION
สร้าง Capability
      ↓
OUTCOME TEAM
นำ Capability ไปใช้
      ↓
OUTCOME
      ↓
VALUE
      ↓
Feedback
      ↓
FUNCTION
พัฒนา Capability ให้ดีขึ้น

นี่เป็นวงจรที่สำคัญ เพราะ Outcome ที่เกิดขึ้นจริงสามารถย้อนกลับมาเป็นข้อมูลให้ Function ปรับปรุง Capability ของตัวเอง

11. Dual Operating Model กับ Balanced Scorecard ยุคใหม่

เมื่อเชื่อมกลับมาที่ Balanced Scorecard จะเห็นว่า Dual Operating Model ช่วยทำให้ Strategy Map มีชีวิตมากขึ้น

Strategy ไม่ควรเป็นเพียงภาพที่ผู้บริหารกำหนดไว้ด้านบน แต่ต้องถูกแปลงเป็น Strategic Outcomes จากนั้นจึงเชื่อมลงไปสู่ Value Streams, Capabilities, Initiatives, People, Data, Technology, AI และสุดท้าย Outcome และ Value

สามารถมองเป็นภาพได้ว่า

STRATEGY
   ↓
STRATEGIC OBJECTIVES
   ↓
STRATEGIC OUTCOMES
   ↓
VALUE STREAMS
   ↓
CAPABILITIES
   ↓
PEOPLE + PROCESS + DATA + TECHNOLOGY + AI
   ↓
OUTPUT
   ↓
OUTCOME
   ↓
VALUE

นี่ทำให้ Balanced Scorecard ไม่ได้เป็นเพียง Scorecard แต่กลายเป็น Strategy-to-Value Architecture

12. แล้ว AI อยู่ตรงไหนใน Dual Operating Model?

AI ไม่ควรถูกวางไว้เฉพาะใน Function ใด Function หนึ่ง แม้ว่าองค์กรอาจมี AI Team หรือ Center of Excellence แต่ AI Capability สามารถถูกนำไปใช้กับหลาย Outcome

ตัวอย่างเช่น

Outcome: Customer Experience

AI ใช้กับ

• Customer Service
• Recommendation
• Personalization
• Complaint Analysis

Outcome: Operational Efficiency

AI ใช้กับ

• Process Automation
• Forecasting
• Document Processing
• Predictive Analytics

Outcome: Employee Productivity

AI ใช้กับ

• Copilot
• Knowledge Search
• Content Generation
• Decision Support

Outcome: Risk Management

AI ใช้กับ

• Anomaly Detection
• Risk Monitoring
• Transaction Analysis
• Early Warning

ดังนั้น AI Function อาจทำหน้าที่เป็น Capability Provider ขณะที่ Outcome Team เป็นผู้ตอบคำถามว่า Capability นี้จะสร้าง Value ที่ไหน? นี่คือความแตกต่างระหว่าง AI-Centric Organization กับ Outcome-Centric AI Organization

13. AI Center of Excellence ไม่ควรกลายเป็น AI Silo

องค์กรจำนวนมากเมื่อเริ่มต้น AI Transformation อาจสร้าง AI Center of Excellence หรือ AI Team ขึ้นมา

ซึ่งมีประโยชน์ในการสร้าง

• AI Standards
• AI Skills
• Architecture
• Governance
• Model Management
• Security
• Responsible AI
• Knowledge

แต่ถ้า AI Team กลายเป็นเจ้าของ AI ทุกอย่าง อาจเกิดปัญหาใหม่ขึ้นมา

AI Silo

เพราะ Business มองว่า “AI เป็นเรื่องของทีม AI” ขณะที่ AI Team อาจมองว่า “Business ไม่รู้ว่าจะใช้ AI อย่างไร” Dual Operating Model จึงช่วยแบ่งบทบาทให้ชัด

AI / Technology Function

ดูแล Capability + Platform + Standard + Governance

Outcome Team

ดูแล Business Problem + Outcome + Value

Business Function

ดูแล Domain Expertise + Process + Adoption

ทั้งสามส่วนจึงต้องทำงานร่วมกัน

14. Decision Rights ต้องชัด

หนึ่งในปัญหาของโครงสร้างสองมิติคือ ใครมีสิทธิ์ตัดสินใจ? หากไม่กำหนดให้ชัด การประชุมจะเพิ่มขึ้นอย่างรวดเร็ว แต่ Decision กลับช้าลง

ดังนั้นองค์กรควรกำหนด Decision Rights ระหว่าง

• Functional Owner
• Outcome Owner
• Product / Value Stream Owner
• Technology Owner
• Risk / Control Owner

ให้ชัดเจน

ตัวอย่างเช่น

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

15. Budget ก็ต้องเปลี่ยนตาม

ถ้าองค์กรมี Outcome Team แต่ Budget ยังถูกแบ่งตาม Function ทั้งหมด ก็อาจเกิดปัญหาเดิมกลับมา เช่น

IT บอกว่าไม่มี Budget

Marketing บอกว่าเป็น Initiative ของ IT

Operations บอกว่าไม่ใช่ Priority ของตน

Data บอกว่าต้องรอ Project รอบถัดไป

สุดท้าย Outcome ที่ทุกคนเห็นว่าสำคัญกลับไม่สามารถเดินหน้าได้ ดังนั้น Dual Operating Model อาจต้องมีทั้ง

Functional Budget

สำหรับ

• People
• Capability
• Platform
• Standards
• Operations

และ

Strategic / Outcome Investment

สำหรับ

• Strategic Initiatives
• Value Streams
• Transformation
• AI Use Cases
• Cross-functional Programs

นี่ทำให้เงินลงทุนสามารถเคลื่อนตาม Strategic Priority ได้มากขึ้น

16. People Management ต้องรองรับสองมิติ

โครงสร้างสองมิติจะเกิดขึ้นไม่ได้ หากระบบ People Management ยังมองคนเพียงผ่าน Department องค์กรจึงต้องเริ่มตอบคำถามว่า คนคนหนึ่งมี Functional Home ที่ไหน? และ วันนี้เขากำลังสร้าง Outcome อะไร?

ตัวอย่างเช่น

Data Scientist คนหนึ่งอาจสังกัด Data & Analytics Function แต่ในช่วง 6 เดือนอาจถูก Assign ให้ Customer Value Outcome Team เพื่อทำงานร่วมกับ

• Marketing
• Sales
• Product
• Customer Service

หลังจาก Outcome สำคัญเสร็จ หรือ Strategic Priority เปลี่ยน เขาอาจย้ายไปสนับสนุน Outcome อื่น นี่ทำให้ Workforce เริ่มมีลักษณะ Capability Pool มากกว่า Fixed Functional Resource

17. จาก Fixed Organization สู่ Dynamic Organization

นี่คืออีกหนึ่งความเปลี่ยนแปลงสำคัญ Organization Chart แบบเดิมมักมีลักษณะค่อนข้างคงที่ แต่ในโลกที่ Strategy และ Technology เปลี่ยนเร็ว องค์กรต้องสามารถจัดกำลังคนใหม่ตาม Strategic Priority ได้เร็วขึ้น

ตัวอย่างเช่น วันนี้ Strategic Priority คือ Customer Experience จึงจัด Outcome Team ขึ้นมา อีกช่วงหนึ่ง Priority เปลี่ยนเป็น Cost Transformation ทีมและ Capability บางส่วนก็สามารถถูกจัดใหม่ จากนั้นอาจเปลี่ยนเป็น AI-enabled Growth แล้วจัดทีมใหม่อีกครั้ง ไม่ได้หมายความว่าคนต้องย้าย Department ทุกเดือน แต่หมายถึง การจัดสรร Capability ต้องมีความยืดหยุ่นมากกว่า Organization Chart แบบเดิม

18. Dual Operating Model กับ Agile

แนวคิดนี้มีความสัมพันธ์กับ Agile อย่างชัดเจน Agile ช่วยให้องค์กรทำงานเป็นทีมข้าม Function และส่งมอบ Value ได้เร็วขึ้น แต่ Agile เพียงอย่างเดียวไม่ได้แก้ปัญหาเรื่อง

• Functional Governance
• Professional Standards
• Career Development
• Risk Management
• Enterprise Architecture
• Resource Ownership

Dual Operating Model จึงสามารถทำให้สองสิ่งนี้อยู่ร่วมกันได้ Functional Excellence และ Agile / Outcome Delivery

ตัวอย่างเช่น

Functional Home
      ↓
Professional Excellence
      ↓
       ↘
        Outcome Team
       ↗
      ↓
Agile Delivery
      ↓
Outcome
      ↓
Value

จึงไม่จำเป็นต้องเลือกว่า “จะเป็น Agile หรือ Functional” แต่สามารถออกแบบให้ Function เป็นฐาน และ Outcome Team เป็นกลไกการส่งมอบ Value

19. สิ่งที่องค์กรต้องระวัง: Dual Operating Model อาจกลายเป็น “Double Bureaucracy”

แนวคิดนี้มีประโยชน์ แต่ก็มีความเสี่ยง ถ้าองค์กรสร้าง

• Functional Meeting
• Outcome Meeting
• Steering Committee
• Project Committee
• AI Committee
• Transformation Committee

เพิ่มขึ้นทั้งหมด แทนที่จะสร้างความคล่องตัว องค์กรอาจได้ ประชุมสองเท่า แต่ตัดสินใจช้ากว่าเดิม

ดังนั้น Dual Operating Model ไม่ควรถูกตีความว่า “สร้างโครงสร้างเพิ่มทุกอย่าง” แต่ควรถูกตีความว่า “จัดบทบาทและ Decision Rights ใหม่ให้ชัดเจน” เป้าหมายคือ More Alignment ไม่ใช่ More Meetings

20. หลัก 5 ประการของ Dual Operating Model

เพื่อไม่ให้โครงสร้างสองมิติกลายเป็นความซับซ้อน สามารถยึดหลัก 5 ประการ

1. One Strategy

ทุก Function และ Outcome Team ต้องเชื่อมกับ Strategy เดียวกัน

2. Clear Accountability

ต้องรู้ว่าใครเป็น Functional Owner และใครเป็น Outcome Owner

3. Shared Outcomes

Outcome สำคัญต้องถูกสร้างร่วมกัน ไม่ใช่โยนข้าม Function

4. Clear Decision Rights

ต้องรู้ว่าใครตัดสินใจเรื่องใด

5. Measure Value

สุดท้ายต้องวัดว่า Outcome สร้าง Value หรือไม่

จึงสรุปได้ว่า Dual Operating Model ไม่ใช่การเพิ่มโครงสร้าง แต่คือการเพิ่มมิติในการบริหาร

21. Framework: Functional Home + Outcome Network

จากแนวคิดทั้งหมด สามารถสรุปเป็นภาพรวมได้ดังนี้

ในโมเดลนี้ Functional Home ทำหน้าที่ Build Capability ขณะที่ Outcome Network ทำหน้าที่ Apply Capability และสุดท้าย Value Stream ทำหน้าที่ Create Value

22. แล้วองค์กรควรเริ่มอย่างไร?

องค์กรไม่จำเป็นต้องเปลี่ยนเป็น Dual Operating Model ทั้งองค์กรในครั้งเดียว วิธีที่เหมาะสมกว่าคือเริ่มจาก Strategic Outcome ที่สำคัญหนึ่งหรือสองเรื่อง

ตัวอย่างเช่น Improve Customer Lifetime Value จากนั้นทดลองออกแบบ

Step 1 — Define Outcome

Outcome ต้องชัดและวัดได้

Step 2 — Identify Value Stream

มองกระบวนการตั้งแต่ต้นจนจบ

Step 3 — Identify Required Capabilities

ต้องใช้

People + Process + Data + Technology + AI

อะไรบ้าง?

Step 4 — Appoint Outcome Owner

ใครรับผิดชอบผลลัพธ์?

Step 5 — Form Outcome Team

Function ใดต้องเข้ามาร่วม?

Step 6 — Define Decision Rights

ใครตัดสินใจเรื่องอะไร?

Step 7 — Align Metrics

มีทั้ง Functional KPI + Outcome Metrics

Step 8 — Align Investment

จัดสรร Resource ตาม Strategic Priority

Step 9 — Measure Value

Outcome ที่เกิดขึ้นสร้าง Value จริงหรือไม่?

Step 10 — Learn and Scale

เมื่อ Model ทำงานได้ จึงค่อยขยายไป Outcome อื่น

นี่คือแนวทางที่ช่วยลดความเสี่ยงจากการ Reorganization ครั้งใหญ่โดยไม่จำเป็น

23. Executive Checklist: องค์กรของเราพร้อมสำหรับ Dual Operating Model หรือยัง?

ผู้บริหารสามารถใช้คำถามเหล่านี้เป็นจุดเริ่มต้น

หากองค์กรตอบคำถามเหล่านี้ได้ จะเริ่มเห็นภาพว่า ปัญหาอยู่ที่ Organization Chart หรือจริง ๆ แล้วอยู่ที่ Operating Model ซึ่งสองเรื่องนี้ไม่ใช่เรื่องเดียวกัน

สรุป: องค์กรยุค AI ต้องเก่งทั้ง “ส่วน” และ “ทั้งระบบ”

Functional Organization ไม่ได้ล้าสมัย และ Outcome-Based Organization ก็ไม่ได้หมายความว่า Function ต้องหายไป สิ่งที่องค์กรต้องทำคือการนำจุดแข็งของทั้งสองระบบมาประกอบกัน

Function ทำให้องค์กรมี

• Expertise
• Capability
• Standards
• Governance
• Professional Excellence

ขณะที่ Outcome ทำให้องค์กรสามารถ

• Connect Capabilities
• Break Silos
• Manage Value Streams
• Create Business Outcomes
• Deliver Enterprise Value

ดังนั้นจุดหมายไม่ได้อยู่ที่การเปลี่ยน Function → Outcome แต่คือการเปลี่ยนจาก Function Only ไปสู่ Function + Outcome และนี่คือหัวใจของ “Dual Operating Model”

องค์กรมี “บ้าน” ให้คนสร้างความเชี่ยวชาญ แต่ขณะเดียวกันก็มี “เครือข่าย” ให้ความเชี่ยวชาญเหล่านั้นมาทำงานร่วมกันเพื่อสร้าง Outcome จึงสามารถมองเป็นสมการง่าย ๆ ว่า

Functional Excellence
        +
Cross-functional Collaboration
        +
Outcome Accountability
        +
Value Stream
        ↓
Enterprise Value Creation

ในโลกที่ AI เข้ามาเปลี่ยนรูปแบบการทำงานอย่างรวดเร็ว ความสามารถขององค์กรไม่ได้ขึ้นอยู่กับว่าแต่ละ Function มี AI มากเพียงใด แต่ขึ้นอยู่กับว่า องค์กรสามารถนำ People + Process + Data + Technology + AI จากหลาย Function มาประกอบกันเพื่อสร้าง Outcome ได้เร็วและมีประสิทธิภาพเพียงใด

ดังนั้น AI Transformation ที่แท้จริงจึงไม่ใช่เพียงการนำ AI เข้าไปใส่ใน Organization Chart แต่คือการออกแบบ Operating Model ที่ทำให้ AI สามารถไหลไปยังจุดที่สร้าง Value ได้ และเมื่อเราพูดถึงการทำให้ Capability, Data, Technology และ AI ไหลไปตาม Outcome สิ่งหนึ่งที่หลีกเลี่ยงไม่ได้ก็คือ “องค์กรจะรู้ได้อย่างไรว่า Capability ที่มีอยู่เพียงพอต่อ Outcome ที่ต้องการหรือยัง?” เพราะการมีคน มีระบบ มี Data และมี AI ไม่ได้แปลว่าองค์กรมี Capability ที่พร้อมสร้าง Value องค์กรต้องสามารถมองเห็นว่า Strategy ต้องการ Outcome อะไร → Outcome ต้องใช้ Capability อะไร → Capability ปัจจุบันมี Gap ตรงไหน → และต้องลงทุนอะไรเพื่อปิด Gap เหล่านั้น จากคำถามนี้ เราจะก้าวไปสู่หัวข้อสำคัญของตอนถัดไป คือ ตอนที่ 6 — Capability-Based Organization: จากการจัดคนตาม Function สู่การจัดองค์กรตาม Capability เมื่อ Strategy ไม่ได้ต้องการเพียง “คน” แต่ต้องการ “ความสามารถในการสร้าง Outcome” โปรดติดตามนะครับ

Outcome Owner: จากเจ้าของงานสู่เจ้าของผลลัพธ์

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

เมื่อทุกคนรับผิดชอบ อาจกลายเป็นไม่มีใครรับผิดชอบ

ในตอนที่ 3 เราได้เห็นแล้วว่า Outcome-Based Organization ไม่ได้มองความสำเร็จจากสิ่งที่แต่ละ Function ส่งมอบเพียงอย่างเดียว แต่ต้องมองไปถึง Outcome และ Value ที่เกิดขึ้นจริง แต่ทันทีที่องค์กรเริ่มคิดแบบ Outcome-Based จะเกิดคำถามสำคัญขึ้นมาอีกข้อหนึ่งว่า “ถ้า Outcome หนึ่งต้องอาศัยหลายฝ่าย แล้วใครเป็นคนรับผิดชอบผลลัพธ์?”

คำถามนี้สำคัญกว่าที่ดูเหมือน เพราะในองค์กรแบบ Functional เราสามารถตอบได้ค่อนข้างง่ายว่า

IT รับผิดชอบระบบ
HR รับผิดชอบคน
Marketing รับผิดชอบ Campaign
Finance รับผิดชอบการเงิน
Operations รับผิดชอบกระบวนการ

แต่ Outcome ไม่ได้เดินตามเส้นแบ่งของ Organization Chart

ตัวอย่างเช่น

Increase Customer Lifetime Value ไม่ใช่ Outcome ของ Marketing เพียงฝ่ายเดียว หรือ Reduce Customer Churn ก็ไม่ได้เกิดจาก Customer Service เพียงฝ่ายเดียว และ Improve Employee Productivity ก็ไม่ใช่เรื่องของ HR เพียงฝ่ายเดียว

Outcome เหล่านี้เกิดจากหลาย Capability ที่ทำงานเชื่อมโยงกัน จึงเกิดปัญหาที่เรียกว่า Shared Responsibility without Clear Accountability ทุกคนมีส่วนเกี่ยวข้อง แต่ไม่มีใครเป็นเจ้าภาพของผลลัพธ์ทั้งหมด

ดังนั้น หากองค์กรต้องการเปลี่ยนไปสู่ Outcome-Based อย่างจริงจัง สิ่งที่ต้องเปลี่ยนไม่ใช่แค่ KPI หรือ Workflow แต่ต้องเปลี่ยนแนวคิดเรื่อง

Ownership

1. Functional Owner กับ Outcome Owner คือคนละบทบาทกัน

ก่อนอื่นต้องแยกให้ชัดว่า Functional Owner ไม่ได้หายไป ในองค์กรยังคงต้องมีผู้บริหารหรือหัวหน้าที่รับผิดชอบ Function ของตนเอง เช่น

• CIO / IT
• CHRO / HR
• CMO / Marketing
• CFO / Finance
• COO / Operations
• Chief Risk Officer / Risk

Functional Owner มีหน้าที่ดูแลความสามารถของ Function ให้แข็งแรง เช่น

คนมีความสามารถหรือไม่?

Process มีมาตรฐานหรือไม่?

Technology พร้อมหรือไม่?

Resource เพียงพอหรือไม่?

Risk และ Control ถูกบริหารหรือไม่?

แต่ Outcome Owner มีคำถามอีกแบบหนึ่ง “Outcome ที่องค์กรต้องการกำลังเกิดขึ้นหรือไม่?” ดังนั้น ทั้งสองบทบาทจึงไม่ได้มาแทนที่กัน แต่ต้องทำงานร่วมกัน

2. Functional Owner vs Outcome Owner

ความแตกต่างสามารถสรุปได้ดังนี้

ความแตกต่างที่สำคัญที่สุดอยู่ที่คำว่า Optimize Function กับ Optimize Outcome เพราะสองสิ่งนี้ไม่ได้เหมือนกันเสมอไป

3. เมื่อ Function ทำงานได้ดี แต่ Outcome ไม่เกิดขึ้น

ลองดูตัวอย่างง่าย ๆ องค์กรต้องการ ลด Customer Churn

Marketing ทำ Campaign ได้ตามแผน

Sales เพิ่มจำนวนลูกค้าใหม่ได้

Customer Service ลดเวลารับสายได้

IT ส่งมอบระบบใหม่ได้

Finance ควบคุมต้นทุนได้

ทุก Function สามารถรายงานว่า “เราทำตาม KPI ได้ครบ” แต่ Customer Churn กลับไม่ได้ลดลง คำถามคือ ใครเป็นเจ้าของปัญหานี้? ถ้าแต่ละฝ่ายตอบว่า “ส่วนของฉันทำครบแล้ว” องค์กรอาจพบสถานการณ์ที่ทุก Function ประสบความสำเร็จ แต่ Enterprise กลับไม่ได้ Outcome ที่ต้องการ นี่คือ Silo Optimization

แต่ Outcome Owner จะมองอีกแบบ เขาจะไม่หยุดที่คำถามว่า “แต่ละฝ่ายทำครบหรือยัง?” แต่จะถามว่า “ทำไม Customer Churn ยังไม่ลด?” แล้วจึงย้อนกลับไปวิเคราะห์ทั้ง Value Stream

Customer Acquisition
        ↓
Customer Onboarding
        ↓
Product Experience
        ↓
Customer Service
        ↓
Customer Satisfaction
        ↓
Customer Retention
        ↓
Customer Lifetime Value

นี่คือความแตกต่างระหว่าง Managing Functions กับ Managing Outcomes

4. Outcome Owner ไม่ใช่ “หัวหน้าของทุกคน”

จุดนี้ต้องทำความเข้าใจให้ชัด เพราะเป็นความเข้าใจผิดที่เกิดขึ้นได้ง่าย Outcome Owner ไม่ได้หมายความว่า “คนนี้มีอำนาจเหนือทุก Function” และไม่ได้หมายความว่า Functional Manager ต้องสูญเสียอำนาจ

Outcome Owner มีหน้าที่แตกต่างออกไป คือ เป็นเจ้าภาพของ Outcome โดยอาศัย Capability จากหลาย Function

ตัวอย่างเช่น Outcome คือ Reduce Customer Resolution Time

Outcome Owner อาจต้องทำงานร่วมกับ

• Customer Service
• IT
• Data
• Product
• Operations
• Risk
• AI Team

แต่ไม่ได้หมายความว่า Outcome Owner ต้องเป็นผู้บริหารทุกทีมเหล่านี้ เขาต้องสามารถ

1. กำหนด Outcome ให้ชัด
2. กำหนด Success Metrics
3. มอง End-to-End Value Stream
4. ระบุ Capability ที่จำเป็น
5. ประสาน Functional Owner
6. จัดลำดับความสำคัญ
7. ติดตาม Outcome
8. แก้ปัญหาที่เกิดขึ้นข้าม Function

ดังนั้น Outcome Owner จึงมีลักษณะเป็น Integrator of Capabilities มากกว่าจะเป็น Controller of Functions

5. Outcome Owner ต้องมอง End-to-End

หนึ่งในคุณสมบัติสำคัญที่สุดของ Outcome Owner คือการไม่มองปัญหาเฉพาะจุด สมมติว่าองค์กรต้องการ Increase Digital Customer Adoption หากมองแบบ

Function Marketing อาจบอกว่า เราทำ Campaign แล้ว

IT อาจบอกว่า Application พร้อมแล้ว

Product อาจบอกว่า Feature เปิดใช้งานแล้ว

Customer Service อาจบอกว่า มีคู่มือให้ลูกค้าแล้ว

แต่ Outcome Owner ต้องถามต่อว่า

ลูกค้ารู้จักหรือไม่?

ลูกค้าเริ่มใช้งานหรือไม่?

ขั้นตอนการสมัครง่ายหรือไม่?

ลูกค้าเข้าใจวิธีใช้หรือไม่?

ลูกค้าใช้งานต่อเนื่องหรือไม่?

ลูกค้าได้รับ Value จริงหรือไม่?

จึงต้องมอง Customer Journey ทั้งเส้น

Awareness
    ↓
Consideration
    ↓
Registration
    ↓
Activation
    ↓
Usage
    ↓
Value Realization
    ↓
Retention

เพราะ Outcome ไม่ได้เกิดขึ้นที่ขั้นตอนใดขั้นตอนหนึ่ง แต่เกิดจาก End-to-End Experience

6. Outcome Owner กับ Balanced Scorecard ยุคใหม่

เมื่อย้อนกลับมาที่แนวคิด Balanced Scorecard จะเห็นว่าเรื่องนี้มีความเชื่อมโยงกันโดยตรง Balanced Scorecard แบบดั้งเดิมช่วยให้องค์กรมอง Performance ผ่านหลายมิติ เช่น

• Financial
• Customer
• Internal Process
• Learning & Growth

แต่ในบริบทขององค์กรยุค Digital และ AI สิ่งที่สำคัญมากขึ้นคือการเชื่อมโยงว่า Perspective หนึ่งส่งผลต่ออีก Perspective อย่างไร และสุดท้ายสร้าง Strategic Outcome และ Value อย่างไร

ตัวอย่างเช่น

Learning & Growth
        ↓
People Capability
        ↓
AI Adoption
        ↓
Process Improvement
        ↓
Customer Experience
        ↓
Customer Outcome
        ↓
Revenue / Margin
        ↓
Enterprise Value

Outcome Owner จึงต้องมอง Cause-and-Effect Relationship ไม่ใช่ดู KPI แต่ละตัวแยกจากกัน เพราะ KPI ที่ดีอาจไม่ได้สร้าง Outcome หากความสัมพันธ์ระหว่าง KPI เหล่านั้นไม่ได้เชื่อมกับ Strategy อย่างแท้จริง

7. จาก KPI Owner สู่ Outcome Owner

ในระบบเดิม องค์กรอาจมีคนรับผิดชอบ KPI แต่ละตัว

เช่น

Marketing → Conversion Rate

IT → System Availability

Customer Service → Average Handling Time

HR → Training Completion

แต่การมี KPI Owner จำนวนมากไม่ได้หมายความว่าองค์กรมี Outcome Owner เพราะ KPI เป็นเพียง Measurement ขณะที่ Outcome เป็น ผลลัพธ์ที่องค์กรต้องการให้เกิด

ตัวอย่างเช่น

Training Completion
        ↓
Skill Adoption
        ↓
Employee Productivity
        ↓
Customer Service Quality
        ↓
Customer Satisfaction
        ↓
Customer Retention

HR อาจเป็นเจ้าของ Training Completion แต่ไม่จำเป็นต้องเป็นเจ้าของ Customer Retention และ Customer Service ก็ไม่สามารถรับผิดชอบ Customer Retention เพียงฝ่ายเดียว จึงต้องแยกให้ชัดว่า ใครเป็นเจ้าของตัวชี้วัด กับ ใครเป็นเจ้าของ Outcome สองสิ่งนี้อาจเป็นคนละคนกัน

8. Outcome Owner ต้องมี Authority เพียงพอ

นี่เป็นจุดที่สำคัญมากในทางปฏิบัติ การแต่งตั้ง Outcome Owner แต่ไม่ให้ Authority ในการประสานงานหรือจัดลำดับความสำคัญ อาจทำให้บทบาทนี้กลายเป็นเพียง “คนที่ต้องรายงานผล แต่ไม่มีอำนาจเปลี่ยนอะไร” ซึ่งไม่สามารถแก้ปัญหาได้ Outcome Owner จึงควรมีอำนาจหรือกลไกในการ

• กำหนด Priority
• เรียก Cross-functional Team
• ขอข้อมูลจาก Function ต่าง ๆ
• เสนอการจัดสรร Resource
• Escalate Dependency
• ติดตาม Decision
• ปรับ Initiative ให้สอดคล้องกับ Outcome

โดยยังต้องเคารพ Governance และ Accountability ของ Functional Owner จึงเกิดหลักสำคัญว่า Accountability ต้องมาพร้อมกับ Decision Rights ที่เพียงพอ ไม่เช่นนั้น Outcome Owner จะกลายเป็นเพียง “ชื่อใน Organization Chart”

9. Outcome Team ไม่ใช่ Project Team

อีกเรื่องที่ต้องแยกให้ชัดคือ Outcome Team ≠ Project Team

Project Team มีเป้าหมายหลักว่า ส่งมอบ Project ให้สำเร็จ เมื่อ Project เสร็จ ทีมอาจถูกยุบหรือเปลี่ยนไปทำ Project ใหม่

แต่ Outcome Team มีเป้าหมายว่า ทำให้ Outcome เกิดขึ้น ดังนั้นแม้ Project จะเสร็จแล้ว แต่ถ้า Outcome ยังไม่เกิด ทีมก็ยังมีเหตุผลที่จะต้องทำงานต่อ

ตัวอย่าง

Project Thinking

พัฒนา Mobile Application ให้เสร็จภายใน 6 เดือน เมื่อ Application เปิดใช้งาน Project Complete

แต่ใน Outcome Thinking คำถามเพิ่งเริ่มต้น

ลูกค้าใช้งานจริงหรือไม่?

Activation Rate เป็นอย่างไร?

ลูกค้าได้รับ Value หรือไม่?

Retention ดีขึ้นหรือไม่?

ดังนั้น Project Completion ไม่ใช่ Outcome Completion นี่เป็นอีกจุดที่องค์กรต้องเปลี่ยนวิธีคิดอย่างมาก

10. Outcome Owner กับ AI Transformation

เรื่องนี้ยิ่งสำคัญเมื่อองค์กรนำ AI มาใช้ เพราะ AI Initiative จำนวนมากเริ่มต้นจากคำถามว่า “เราจะใช้ AI กับงานอะไรได้บ้าง?” จึงเกิดรายการ Use Cases จำนวนมาก เช่น

• AI Chatbot
• AI Document Processing
• AI Copilot
• AI Forecasting
• AI Recommendation
• AI Analytics

แต่การมี AI Use Cases จำนวนมากไม่ได้หมายความว่าองค์กรกำลังสร้าง Value มากขึ้น Outcome Owner จึงควรย้อนคำถามกลับไปว่า “เราต้องการเปลี่ยน Outcome อะไร?” แล้วจึงถามต่อว่า AI สามารถช่วยเปลี่ยน Outcome นี้ได้ตรงไหน?

ตัวอย่าง

Strategic Outcome

Improve Customer Experience

Business Outcome

Reduce Customer Resolution Time

Capability

Intelligent Customer Service

AI Capability

AI Agent Assistance

Output

AI Assistant เปิดใช้งาน

Outcome

Resolution Time ลดลง

Value

Cost per Resolution ลดลง + Customer Satisfaction เพิ่มขึ้น

โครงสร้างนี้ช่วยป้องกันปัญหาที่องค์กรลงทุน AI แล้วจบลงที่ “เรามี AI แล้ว” แต่ไม่สามารถตอบได้ว่า “แล้ว AI สร้างอะไรให้กับธุรกิจ?”

11. Outcome Owner กับ Data

Outcome Owner ยังต้องให้ความสำคัญกับ Data อย่างมาก เพราะหากไม่สามารถวัด Outcome ได้ องค์กรจะไม่สามารถรู้ได้ว่า Outcome เกิดขึ้นจริงหรือไม่

ตัวอย่างเช่น

Outcome:

Reduce Customer Churn

อาจต้องใช้ข้อมูลจาก

• CRM
• Sales
• Customer Service
• Product Usage
• Transaction
• Complaint
• Customer Feedback
• Digital Channels

ข้อมูลเหล่านี้มักกระจายอยู่หลายระบบ ดังนั้น Outcome Owner ไม่จำเป็นต้องเป็น Data Owner แต่ต้องสามารถตอบได้ว่า “เราต้องใช้ Data อะไรเพื่อพิสูจน์ว่า Outcome เกิดขึ้น?” ตรงนี้จะทำให้ Data Governance และ AI Governance เชื่อมเข้ากับ Business Outcome โดยตรง

12. Outcome Ownership กับ Governance

เมื่อหลาย Function ทำงานร่วมกัน Governance จะยิ่งสำคัญ เพราะองค์กรต้องตอบให้ได้ว่า

• ใครตัดสินใจ?
• ใครให้ข้อมูล?
• ใครอนุมัติ?
• ใครรับผิดชอบความเสี่ยง?
• ใครเป็นผู้ดำเนินการ?
• ใครเป็นผู้รับผิดชอบ Outcome?
• ใครเป็นผู้ตรวจสอบ?

จึงอาจต้องออกแบบ Governance Model ที่แยก Functional Accountability รับผิดชอบมาตรฐาน ความเชี่ยวชาญ และการควบคุมของ Function ออกจาก Outcome Accountability รับผิดชอบผลลัพธ์ที่องค์กรต้องการ โดยทั้งสองต้องเชื่อมกัน

นี่คือโครงสร้าง Accountability ที่เหมาะกับองค์กรที่ต้องทำงานข้าม Function

13. Outcome Owner ต้องมี “Outcome Contract”

แนวคิดหนึ่งที่สามารถนำมาใช้ในการบริหารคือการกำหนด Outcome Contract ไม่จำเป็นต้องเป็นสัญญาทางกฎหมาย แต่เป็นข้อตกลงที่ชัดเจนว่า Outcome หนึ่งมีองค์ประกอบอะไรบ้าง อย่างน้อยควรระบุ

1. Outcome

ต้องการให้เกิดอะไร?

2. Baseline

ปัจจุบันอยู่ที่ระดับใด?

3. Target

ต้องการไปถึงระดับใด?

4. Time Horizon

ต้องการให้เกิดขึ้นเมื่อไร?

5. Value

Outcome นี้สร้างคุณค่าอะไร?

6. Outcome Owner

ใครเป็นเจ้าภาพ?

7. Contributing Functions

Function ใดต้องเข้ามามีส่วนร่วม?

8. Key Initiatives

ต้องทำอะไรเพื่อให้ Outcome เกิด?

9. Leading Indicators

เราจะรู้ได้อย่างไรว่ากำลังเดินมาถูกทาง?

10. Risks & Dependencies

มีอะไรที่อาจทำให้ Outcome ไม่เกิด?

ตัวอย่างเช่น

สิ่งนี้ทำให้ Outcome ไม่ใช่เพียงคำสวย ๆ ใน Strategy Presentation แต่กลายเป็น Management Object ที่สามารถบริหารได้จริง

14. จาก Organization Chart สู่ Accountability Architecture

นี่คือจุดที่แนวคิด Outcome Owner เริ่มเปลี่ยนวิธีมองโครงสร้างองค์กร Organization Chart แบบเดิมตอบคำถามว่า “ใครอยู่ฝ่ายไหน?” แต่ Outcome-Based Organization ต้องตอบเพิ่มว่า “ใครทำงานร่วมกับใครเพื่อสร้าง Outcome อะไร?” จึงอาจต้องมองโครงสร้างสองมิติ

Dimension 1 — Functional Structure

ตอบว่า

บุคลากรอยู่ที่ไหน?

ความเชี่ยวชาญอยู่ที่ไหน?

Professional Standard อยู่ที่ไหน?

Dimension 2 — Outcome Structure

ตอบว่า

บุคลากรกำลังสร้าง Outcome อะไร?

Outcome ใดเป็น Strategic Priority?

ใครเป็น Outcome Owner?

Function ใดเป็น Contributor?

จึงเกิดแนวคิด Two-Dimensional Organization หรือมองในเชิงง่าย ๆ ว่า Functional Home + Outcome Network นี่จะเป็นพื้นฐานสำคัญสำหรับการออกแบบองค์กรในยุค AI

15. แล้ว Outcome Owner ควรอยู่ตรงไหนใน Organization Chart?

ไม่มีคำตอบเดียวสำหรับทุกองค์กร เพราะขึ้นอยู่กับขนาดองค์กร ความซับซ้อนของธุรกิจ และประเภทของ Outcome แต่มีหลักคิดสำคัญคือ Outcome Owner ควรอยู่ในตำแหน่งที่สามารถเชื่อมโยง Strategy → Value → Capability → Execution ได้

สำหรับ Strategic Outcome ที่มีผลกระทบสูง อาจอยู่ในระดับ Enterprise หรือได้รับ Sponsorship จากผู้บริหารระดับสูง

สำหรับ Business Outcome อาจอยู่ในระดับ Business Unit หรือ Product / Customer Domain

สำหรับ Operational Outcome อาจอยู่ในระดับ Process หรือ Value Stream

ดังนั้นไม่ควรสร้างตำแหน่ง Outcome Owner แบบเดียวกันทั้งหมด สิ่งสำคัญกว่าตำแหน่งคือ Scope + Accountability + Authority + Measurement ต้องสอดคล้องกัน

16. Outcome Owner ไม่ใช่คนที่ “ทำทุกอย่าง”

นี่เป็นอีกประเด็นที่สำคัญ เมื่อมีคนหนึ่งเป็นเจ้าของ Outcome ไม่ได้หมายความว่าคนนั้นต้องทำทุกอย่างเอง ตรงกันข้าม Outcome Owner ต้องเก่งเรื่อง Orchestration มากกว่าการลงมือทำทุกงาน เขาต้องสามารถมองเห็นว่า

Outcome ต้องการ Capability อะไร?

Capability นั้นอยู่ที่ Function ใด?

Dependency อยู่ตรงไหน?

ใครต้องตัดสินใจ?

ใครต้องลงมือทำ?

อะไรเป็น Bottleneck?

อะไรควรใช้ Technology หรือ AI?

จึงอาจกล่าวได้ว่า Outcome Owner ไม่ใช่ Superhero ขององค์กร แต่เป็น Conductor ของ Value Creation เหมือนวาทยกรที่ไม่ได้เล่นเครื่องดนตรีทุกชิ้น แต่ต้องทำให้เครื่องดนตรีทุกชิ้นเล่นไปในทิศทางเดียวกัน

17. Outcome Owner กับ Performance Management

เมื่อ Outcome Owner เกิดขึ้น ระบบ Performance Management ก็ต้องเปลี่ยนตาม ไม่เช่นนั้นจะเกิดความขัดแย้งว่า องค์กรต้องการ Outcome แต่คนถูกประเมินด้วย Functional KPI เพียงอย่างเดียว จึงอาจต้องมี Performance แบบสองมิติ

Functional Performance

วัดว่า Function ทำหน้าที่ของตัวเองได้ดีเพียงใด? เช่น

• Quality
• Efficiency
• Compliance
• Capability
• Cost

และ Outcome Contribution

วัดว่า บุคลากรหรือทีมมีส่วนทำให้ Strategic Outcome เกิดขึ้นอย่างไร? เช่น

• Outcome Achievement
• Cross-functional Contribution
• Value Creation
• Customer Impact
• Business Impact

สิ่งนี้จะช่วยลดปัญหาที่คนเก่ง Function ของตัวเองมาก แต่ไม่สามารถทำงานข้าม Function ได้

18. Outcome Owner ต้องระวัง “Local Optimization”

หนึ่งในหน้าที่สำคัญของ Outcome Owner คือการป้องกัน Local Optimization

ตัวอย่างเช่น

Customer Service ต้องการลด Average Handling Time จึงพยายามปิด Case ให้เร็วที่สุด แต่ถ้าการปิดเร็วทำให้ลูกค้าต้องโทรกลับอีกครั้ง สิ่งที่เกิดขึ้นอาจเป็น

AHT ↓

แต่

Repeat Contact ↑

และ

Customer Effort ↑

ดังนั้น KPI ของ Function อาจดีขึ้น แต่ Outcome ของ Customer กลับแย่ลง Outcome Owner จึงต้องมอง System Performance ไม่ใช่เพียง Local Performance นี่คือหนึ่งในบทบาทที่สำคัญที่สุดของ Outcome Owne

19. Outcome Owner กับ Value Creation

ท้ายที่สุด Outcome Owner ไม่ควรหยุดที่คำว่า “Outcome เกิดแล้ว” แต่ต้องถามต่อว่า “Outcome นี้สร้าง Value จริงหรือไม่?”

ตัวอย่าง

องค์กรสามารถลด Processing Time ลงได้ 30% ดูเหมือนเป็น Outcome ที่ดี แต่หากลูกค้าไม่ได้รับประสบการณ์ที่ดีขึ้น และต้นทุนรวมขององค์กรไม่ได้ลดลง Value Creation อาจไม่ได้เกิดขึ้นตามที่คาด ดังนั้น Outcome Owner ต้องเชื่อม

Outcome
   ↓
Business Impact
   ↓
Economic Value
   ↓
Enterprise Value

จึงเกิดหลักสำคัญว่า Outcome is necessary, but Value is the destination.

20. Framework ของ Outcome Ownership

จากทั้งหมดสามารถสรุปเป็น Framework ได้ดังนี้

ในโมเดลนี้ Outcome Owner ทำหน้าที่เชื่อม Strategy กับ Execution และเชื่อม Functions กับ Value Stream และสุดท้ายเชื่อม Output กับ Outcome และ Value

21. 7 คำถามสำหรับออกแบบ Outcome Owner

หากองค์กรกำลังจะนำแนวคิดนี้ไปใช้จริง ผู้บริหารอาจเริ่มจากคำถามง่าย ๆ 7 ข้อ

1. Outcome นี้สำคัญต่อ Strategy หรือไม่?

หากไม่สำคัญ ก็ไม่จำเป็นต้องสร้าง Governance ที่ซับซ้อน

2. Outcome นี้ต้องอาศัยกี่ Function?

หากต้องใช้หลาย Function นี่คือสัญญาณว่าอาจต้องมี Outcome Owner

3. ใครสามารถมอง End-to-End ได้?

ไม่ใช่เพียงคนที่เก่ง Function ใด Function หนึ่ง

4. Outcome Owner มี Authority เพียงพอหรือไม่?

รับผิดชอบโดยไม่มีอำนาจตัดสินใจไม่ใช่โครงสร้างที่ยั่งยืน

5. Outcome มี Baseline และ Target หรือไม่?

ถ้าวัดไม่ได้ ก็ไม่สามารถบริหารได้อย่างจริงจัง

6. Outcome เชื่อมกับ Value อย่างไร?

ไม่ควรหยุดเพียง Outcome Metric

7. Outcome Owner ทำงานร่วมกับ Functional Owner อย่างไร?

เพราะสองบทบาทนี้ต้องเสริมกัน ไม่ใช่แข่งขันกัน

สรุป: จาก “เจ้าของงาน” สู่ “เจ้าของผลลัพธ์”

การเปลี่ยนจาก Functional Organization ไปสู่ Outcome-Based Organization ไม่ได้หมายความว่า Function จะหมดความสำคัญ แต่หมายความว่าองค์กรต้องเพิ่มอีกหนึ่งมิติของ Accountability เข้าไป

Functional Owner ยังคงรับผิดชอบ

Capability

Professional Standard

Governance

Resource

Risk

ขณะที่ Outcome Owner รับผิดชอบ

Outcome

End-to-End Performance

Cross-functional Alignment

Value Creation

ทั้งสองจึงต้องทำงานร่วมกัน ไม่ใช่เลือกอย่างใดอย่างหนึ่ง

Functional Excellence
        +
Outcome Accountability
        ↓
Enterprise Value

นี่คือหัวใจสำคัญ เพราะองค์กรอาจมี Function ที่เก่งมากทุก Function แต่หากไม่มีใครเชื่อมความสามารถเหล่านั้นเข้าหากันเพื่อสร้าง Outcome องค์กรก็ยังไม่สามารถสร้าง Value ได้เต็มศักยภาพ

ในยุค AI ประเด็นนี้จะยิ่งสำคัญขึ้นอีก เพราะ AI สามารถทำให้เส้นแบ่งระหว่าง Function จางลงอย่างรวดเร็ว

• AI สามารถใช้ Data จากหลายฝ่าย
• ทำงานข้าม Process
• สนับสนุนหลาย Function
• และสร้าง Output ได้พร้อมกันหลายส่วน

ดังนั้นคำถามในอนาคตอาจไม่ใช่เพียง “AI จะเข้ามาช่วย Function ไหน?” แต่จะเป็น “AI จะช่วย Outcome ไหน และใครเป็นเจ้าของ Outcome นั้น?” เมื่อคำถามเปลี่ยน โครงสร้างองค์กรก็ต้องเปลี่ยนตาม จาก Organization ที่ออกแบบตาม “ใครทำอะไร” ไปสู่ Organization ที่ออกแบบตาม “ใครร่วมกันทำให้เกิดอะไร” และเมื่อองค์กรเริ่มคิดเช่นนี้ เราจะเข้าสู่คำถามที่ใหญ่ขึ้นอีกระดับหนึ่งว่า ถ้า Function ยังคงอยู่ แต่คนต้องทำงานข้าม Function เพื่อสร้าง Outcome แล้วองค์กรควรออกแบบ Operating Model อย่างไร? นั่นคือจุดที่เราจะเข้าสู่เรื่อง Dual Operating Model: เมื่อองค์กรต้องทำงานสองมิติพร้อมกัน จาก Functional Excellence สู่ Enterprise Value Creation กันในตอนต่อไปนะครับ

จาก Output-Based สู่ Outcome-Based Organization

เมื่อองค์กรต้องเปลี่ยนจาก “เราทำอะไร” ไปสู่ “สิ่งที่เราทำ ทำให้เกิดอะไร”

ทำงานเสร็จ ไม่ได้แปลว่าเป้าหมายสำเร็จ

ในองค์กรทั่วไป คำว่า “งานเสร็จ” มักเป็นสัญญาณของความสำเร็จ ไม่ว่าจะเป็น โครงการถูกส่งมอบตามกำหนด ระบบถูกพัฒนาจนใช้งานได้ รายงานถูกจัดทำเสร็จ พนักงานผ่านการอบรม ลูกค้าได้รับการติดต่อ หรือ กระบวนการถูกปรับให้เป็น Digital แล้ว

เมื่อสิ่งเหล่านี้เกิดขึ้น องค์กรก็มักสรุปว่าโครงการประสบความสำเร็จ แต่คำถามที่สำคัญกว่านั้นคือ “แล้วหลังจากงานเสร็จ มีอะไรเปลี่ยนแปลงขึ้นจริง?” คำถามนี้เป็นเส้นแบ่งระหว่าง Output-Based Organization กับ Outcome-Based Organization

Output บอกว่าองค์กร ผลิตหรือส่งมอบอะไร

Outcome บอกว่า สิ่งที่องค์กรส่งมอบทำให้เกิดการเปลี่ยนแปลงอะไร

และ Value บอกต่อไปว่า

การเปลี่ยนแปลงนั้นมีคุณค่าอย่างไรต่อองค์กร ลูกค้า และผู้มีส่วนได้เสีย

ในยุค AI ความแตกต่างนี้จะยิ่งชัดเจนขึ้น เพราะ AI สามารถเพิ่มความเร็วในการสร้าง Output ได้อย่างมหาศาล แต่การสร้าง Output ที่มากขึ้นไม่ได้รับประกันว่า Outcome หรือ Value จะเพิ่มขึ้นตาม

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

1. Output-Based Organization คืออะไร?

องค์กรแบบ Output-Based ไม่ได้หมายความว่าเป็นองค์กรที่ไม่มีประสิทธิภาพ ตรงกันข้าม องค์กรลักษณะนี้มักมีระบบบริหารงานที่ชัดเจน มีการแบ่งหน้าที่ มี KPI และสามารถควบคุมการส่งมอบงานได้ดี ลักษณะสำคัญคือการให้ความสำคัญกับคำถามว่า “หน่วยงานของเราต้องส่งมอบอะไร?”

ตัวอย่างเช่น :

ฝ่าย IT ต้องพัฒนาระบบให้เสร็จตามแผน

ฝ่าย HR ต้องจัด Training ให้ครบตามเป้าหมาย

ฝ่าย Marketing ต้องสร้าง Leads ตามจำนวนที่กำหนด

ฝ่าย Operations ต้องลด Processing Time ลงตาม KPI

ฝ่าย Finance ต้องปิดบัญชีภายในเวลาที่กำหนด

ทุกฝ่ายสามารถทำงานได้ดีตามหน้าที่ของตัวเอง แต่ปัญหาอาจเกิดขึ้นเมื่อเราถามว่า “แล้วสิ่งเหล่านี้รวมกันทำให้ Strategy ขององค์กรดีขึ้นอย่างไร?”

หากไม่มีคำตอบที่ชัดเจน องค์กรอาจกำลังประสบความสำเร็จในระดับ Function แต่ไม่ประสบความสำเร็จในระดับ Enterprise

2. Output ไม่ใช่ Outcome

ความแตกต่างระหว่างสองคำนี้ดูเหมือนเป็นเรื่องของคำศัพท์ แต่จริง ๆ แล้วเป็นเรื่องของวิธีคิดในการบริหารองค์กร ลองพิจารณาตัวอย่างง่าย ๆ องค์กรต้องการปรับปรุง Customer Service จึงจัดโครงการพัฒนา Chatbot

Output: Chatbot ได้รับการพัฒนาและเปิดใช้งาน นี่คือสิ่งที่โครงการส่งมอบ แต่ยังไม่ใช่ Outcome

Outcome: หลังจากใช้ Chatbot แล้ว

• ลูกค้าสามารถหาคำตอบได้ด้วยตัวเองมากขึ้น
• จำนวนการติดต่อเจ้าหน้าที่ลดลง
• ระยะเวลาการแก้ปัญหาลดลง
• Customer Effort ลดลง
• Customer Satisfaction เพิ่มขึ้น

และเมื่อมองต่อไป

Value :

• ต้นทุนการให้บริการลดลง
• Customer Retention เพิ่มขึ้น
• Customer Lifetime Value เพิ่มขึ้น
• บุคลากรสามารถใช้เวลาไปกับงานที่สร้างคุณค่ามากขึ้น

ดังนั้น Chatbot ไม่ใช่ Value มันเป็นเพียงหนึ่งใน Means ที่นำไปสู่ Outcome และ Outcome ต่างหากที่เป็นสะพานไปสู่ Value Creation

ตารางนี้สะท้อนประเด็นสำคัญว่า Output ไม่ได้ผิด และไม่ควรถูกละทิ้ง เพราะ Output เป็นสิ่งที่องค์กรต้องส่งมอบ แต่ปัญหาเกิดขึ้นเมื่อองค์กร หยุดการวัดผลอยู่ที่ Output ตัวอย่างเช่น “เราพัฒนา Application เสร็จแล้ว” เป็น Output แต่คำถามต่อไปควรเป็น “แล้วลูกค้าใช้งานจริงหรือไม่?” จากนั้น “ประสบการณ์ของลูกค้าดีขึ้นหรือไม่?” และสุดท้าย “การเปลี่ยนแปลงนี้สร้าง Business Value หรือไม่?”

นี่คือการเคลื่อนจาก Delivering Things ไปสู่ Creating Outcomes และสุดท้ายคือ Creating Value

3. ทำไมองค์กรจำนวนมากจึงติดอยู่กับ Output?

เหตุผลสำคัญประการหนึ่งคือ Output วัดง่ายกว่า Outcome ซึ่งเราสามารถนับได้ว่า

• ทำ Training กี่ครั้ง
• พัฒนา Application กี่ระบบ
• ปิด Ticket ได้กี่รายการ
• ส่ง Report กี่ฉบับ
• ติดต่อ Customer กี่ราย
• ทำ Project สำเร็จกี่โครงการ

แต่ Outcome ต้องพิจารณาถึงการเปลี่ยนแปลงที่เกิดขึ้นจริง ตัวอย่างเช่น:

Training 20 หลักสูตรไม่ได้หมายความว่า Capability ขององค์กรเพิ่มขึ้น

Digital Process 100% ไม่ได้หมายความว่า Customer Experience ดีขึ้น

AI Projects 10 โครงการไม่ได้หมายความว่า Business Value เพิ่มขึ้น

และ Revenue ที่เพิ่มขึ้นในระยะสั้นก็ไม่ได้หมายความว่า Enterprise Value เพิ่มขึ้นในระยะยาวเสมอไป การวัด Output จึงมีข้อดีคือ ง่าย ชัด และควบคุมได้ แต่ข้อเสียคือ สิ่งที่วัดได้ง่าย อาจไม่ใช่สิ่งที่สำคัญที่สุด

4. Outcome-Based Organization เปลี่ยนคำถามขององค์กร

การเปลี่ยนจาก Output-Based ไปสู่ Outcome-Based ไม่ได้เริ่มจากการเปลี่ยน KPI แต่เริ่มจากการเปลี่ยน คำถาม จากเดิม “เราทำอะไร?” เป็น “เราส่งมอบอะไร?” จากนั้นเปลี่ยนเป็น “สิ่งที่เราส่งมอบทำให้เกิดอะไร?” และสุดท้าย “สิ่งที่เกิดขึ้นนั้นสร้างคุณค่าอะไร?” จึงสามารถมองเป็นลำดับได้ว่า Activity → Output → Outcome → Value

ตัวอย่าง: Training

→ พนักงานเข้าร่วม 500 คน

→ พนักงานสามารถใช้ทักษะใหม่ในการทำงาน

→ Productivity และ Decision Quality ดีขึ้น

→ Cost ลดลง / Customer Value เพิ่มขึ้น

ตรงนี้เองที่องค์กรเริ่มเปลี่ยนจาก Task Orientation ไปสู่ Value Orientation

5. Outcome ต้องเริ่มจาก Strategy ไม่ใช่เริ่มจาก Department

นี่เป็นจุดที่สำคัญมาก ในองค์กรแบบเดิม เรามักเริ่มจาก Department เช่น

“ฝ่าย IT ต้องทำอะไร?”

“ฝ่าย HR ต้องทำอะไร?”

“ฝ่าย Marketing ต้องทำอะไร?”

แต่ Outcome-Based Organization ควรเริ่มจาก “องค์กรต้องการให้เกิด Outcome อะไร?” แล้วจึงย้อนกลับมาถามว่า

“ต้องใช้ Capability อะไร?”

“ต้องเปลี่ยน Process อะไร?”

“ต้องมี Function ใดเข้ามาร่วม?”

“ต้องใช้ Data และ AI อย่างไร?”

ตัวอย่างเช่น องค์กรกำหนด Strategic Outcome ว่า Increase Customer Lifetime Value Outcome นี้ไม่ได้เป็นของ Marketing เพียงฝ่ายเดียว แต่ต้องอาศัย Marketing, Sales, Product, Customer Service, IT, Data, Finance ทุกฝ่ายทำงานร่วมกัน ดังนั้น Outcome จึงกลายเป็น จุดเชื่อมของหลาย Function แทนที่จะเป็นทรัพย์สินของ Department ใด Department หนึ่ง

6. จาก Functional Silos สู่ Value Streams

ปัญหาคลาสสิกขององค์กรขนาดใหญ่คือ Functional Silo แต่ละฝ่ายมีเป้าหมายของตัวเอง มีระบบของตัวเอง มีข้อมูลของตัวเอง และมี KPI ของตัวเอง เมื่อลูกค้าติดต่อเข้ามาหนึ่งครั้ง กระบวนการที่ลูกค้าเห็นอาจเป็นเพียง “บริการเดียว” แต่เบื้องหลังอาจเกี่ยวข้องกับ Sales → Operations → Finance → IT → Risk → Customer Service ลูกค้าไม่ได้สนใจว่าใครเป็นเจ้าของขั้นตอนใด ลูกค้าสนใจเพียงว่า “ฉันได้รับคุณค่าที่ต้องการหรือไม่?” นี่คือเหตุผลที่แนวคิด Value Stream มีความสำคัญมากขึ้น

Value Stream มองกระบวนการตั้งแต่ต้นจนจบ โดยมี Outcome หรือ Value ที่ต้องการเป็นศูนย์กลาง

ตัวอย่างเช่น

Customer Need
      ↓
Product / Service
      ↓
Process
      ↓
Digital / AI
      ↓
Customer Experience
      ↓
Customer Outcome
      ↓
Business Value

โดยมีหลาย Function เข้ามาสนับสนุน Value Stream เดียวกัน

7. Outcome-Based ไม่ได้หมายความว่า “ยุบทุก Department”

นี่เป็นความเข้าใจผิดที่อาจเกิดขึ้นได้ง่าย เมื่อพูดว่าองค์กรควรเปลี่ยนจาก Function-Based ไปสู่ Outcome-Based บางคนอาจคิดว่า “ถ้าอย่างนั้นก็ไม่ต้องมี Finance, HR, IT หรือ Risk แล้วหรือ?” คำตอบคือ ไม่ใช่ Functional Organization ยังคงมีความสำคัญอย่างมาก เพราะ Function เป็นแหล่งของ

• Expertise
• Professional Standards
• Governance
• Control
• Resource Management
• Risk Management
• Knowledge

สิ่งที่เปลี่ยนคือ วิธีที่ Function เหล่านั้นนำความสามารถของตัวเองไปสร้าง Outcome ดังนั้นรูปแบบที่เหมาะสมอาจไม่ใช่ Function OR Outcome แต่เป็น Function AND Outcome หรือที่เราจะขยายในตอนต่อไปคือแนวคิด Dual Operating Model

8. Outcome-Based Organization ต้องมี Outcome Owner

เมื่อ Outcome กลายเป็นศูนย์กลาง สิ่งที่หลีกเลี่ยงไม่ได้คือคำถามว่า “ใครรับผิดชอบ Outcome?” สมมติองค์กรกำหนด Outcome ว่า Reduce Customer Churn หากกำหนดความรับผิดชอบว่า

Marketing 25%
Sales 25%
Customer Service 25%
IT 25%

ดูเหมือนทุกคนรับผิดชอบ แต่ในความเป็นจริงอาจไม่มีใครรับผิดชอบ Outcome โดยรวม นี่คือเหตุผลที่ต้องมีแนวคิด Outcome Owner

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

ตัวอย่างเช่น

นี่เป็นการเปลี่ยน Accountability ครั้งใหญ่ จาก “ฉันรับผิดชอบงานของฉัน” เป็น “ฉันรับผิดชอบผลลัพธ์ที่องค์กรต้องการให้เกิด”

9. Outcome-Based Organization กับ AI

AI ทำให้แนวคิดนี้มีความสำคัญมากขึ้น เพราะ AI สามารถทำงานข้าม Function ได้

ตัวอย่างเช่น AI Customer Agent อาจต้องใช้

• Customer Data
• Product Information
• Pricing
• Transaction Data
• Risk Rules
• Knowledge Base
• Customer History

ข้อมูลเหล่านี้อาจอยู่ในหลายระบบและหลายหน่วยงาน ดังนั้นการนำ AI มาใช้จึงไม่ใช่เพียงการซื้อ AI Tool แต่เป็นการเชื่อม Enterprise Capability เข้าด้วยกัน และนี่ทำให้เกิดคำถามว่า AI Initiative นี้ถูกสร้างขึ้นเพื่อ Outcome อะไร? ไม่ใช่ “เราจะเอา AI มาใช้ตรงไหนดี?”

ตัวอย่างเช่น

หาก Outcome คือ Reduce Customer Resolution Time AI อาจเข้ามาช่วย

• วิเคราะห์คำถาม
• ค้นหา Knowledge
• สรุป Customer History
• แนะนำคำตอบ
• Predict ปัญหา
• Automate บางขั้นตอน

แต่ทุกความสามารถเหล่านี้ต้องถูกวัดกลับไปที่ Outcome เดียวกัน เช่น

Resolution Time ↓

First Contact Resolution ↑

Customer Effort ↓

Cost per Resolution ↓

เมื่อเชื่อมเช่นนี้ AI จึงกลายเป็น Outcome Enabler ไม่ใช่เพียง Technology Project

10. Outcome-Based Organization ต้องเปลี่ยนระบบ KPI ด้วย

เมื่อองค์กรเปลี่ยนโครงสร้างการทำงาน ระบบการวัดผลก็ต้องเปลี่ยนตาม ไม่เช่นนั้นจะเกิดความขัดแย้งขึ้นทันที เมื่อองค์กรบอกว่า “เราบริหารแบบ Outcome-Based” แต่กลับประเมินพนักงานด้วย KPI แบบเดิมทั้งหมด ผลที่เกิดขึ้นคือพนักงานก็ยังทำสิ่งที่ทำให้ตัวเองได้คะแนนสูงที่สุด นี่เป็นพฤติกรรมที่เป็นธรรมชาติ ถ้า KPI ของฉันคือ “ปิดงานให้ได้ 100 รายการต่อวัน” ฉันก็จะพยายามปิดงานให้ได้ 100 รายการ แม้ว่าการปิดงานเร็วเกินไปอาจทำให้คุณภาพลดลง ดังนั้น Outcome-Based Organization ต้องปรับ Performance Management ให้เชื่อมโยงกับ Outcome มากขึ้น

ตัวอย่างเช่น

เดิม

Customer Service

• จำนวน Calls
• Average Handling Time
• Number of Cases Closed

ใหม่

• First Contact Resolution
• Customer Effort
• Customer Satisfaction
• Retention Impact
• Cost per Successful Resolution

จากการวัด “ทำงานมากแค่ไหน?” เปลี่ยนเป็น “สร้างผลลัพธ์ได้ดีแค่ไหน?”

11. Outcome Metrics และ Leading Indicators ต้องเดินคู่กัน

อย่างไรก็ตาม ไม่ควรตีความว่าองค์กรต้องเลิกวัด Output ทั้งหมด เพราะ Outcome บางอย่างเกิดขึ้นช้า

ตัวอย่างเช่น

Customer Retention อาจต้องใช้เวลาหลายเดือนกว่าจะเห็นผล หากองค์กรวัดแต่ Outcome ปลายทาง ผู้บริหารอาจไม่รู้ว่ากำลังเกิดปัญหาระหว่างทาง ดังนั้นระบบวัดผลควรมีทั้ง Leading Indicators ตัวชี้วัดที่บอกว่า Outcome มีแนวโน้มจะเกิดหรือไม่ และ Outcome / Lagging Indicators ตัวชี้วัดที่บอกว่าผลลัพธ์เกิดขึ้นจริงหรือไม่

ตัวอย่าง:

AI Adoption
     ↓
Response Quality
     ↓
Resolution Time
     ↓
Customer Satisfaction
     ↓
Customer Retention
     ↓
Customer Lifetime Value

ตัวชี้วัดแต่ละระดับมีบทบาทแตกต่างกัน จึงไม่ใช่การเลือก KPI หรือ Outcome แต่เป็นการออกแบบ Measurement Architecture ที่เชื่อมโยงทั้งสองเข้าด้วยกัน

12. Outcome-Based ต้องการ “Cross-Functional Collaboration”

เมื่อ Outcome เป็นศูนย์กลาง เส้นแบ่งระหว่าง Function จะเริ่มมีความยืดหยุ่นมากขึ้น ทีมหนึ่งอาจต้องร่วมงานกับอีกหลายทีม

Data Scientist ทำงานร่วมกับ Marketing

IT ทำงานร่วมกับ Operations

Risk ทำงานร่วมกับ Product

HR ทำงานร่วมกับ AI Team

Finance เข้ามาประเมิน Value

รูปแบบนี้ไม่ใช่การทำลายโครงสร้างเดิม แต่เป็นการสร้าง Network of Capabilities ที่สามารถนำความเชี่ยวชาญจากหลายส่วนมารวมกันเพื่อสร้าง Outcome เดียว จึงเกิดโครงสร้างแบบ Functional Home + Outcome Team บุคลากรยังมี Functional Home ของตัวเอง แต่สามารถเข้าไปทำงานใน Outcome Team ตาม Strategic Priority แนวคิดนี้จะมีความสำคัญมากเมื่อองค์กรต้องการ Scale AI เพราะ AI Transformation แทบไม่มีทางสำเร็จได้ด้วยฝ่าย IT เพียงฝ่ายเดียว

13. Outcome-Based Organization ต้องเปลี่ยนวิธีจัดสรรทรัพยากร

อีกประเด็นหนึ่งที่มักถูกมองข้ามคือ Budget หากองค์กรบอกว่าต้องการบริหารด้วย Outcome แต่ยังจัดงบประมาณแบบ

IT Budget
Marketing Budget
HR Budget
Operations Budget

โดยแทบไม่มีการจัดสรรทรัพยากรตาม Strategic Outcome ก็ยังคงมีแรงผลักให้แต่ละ Function optimize ตัวเอง ในอนาคตองค์กรอาจต้องเริ่มพิจารณา Outcome-Based Investment เช่น Customer Value Initiative มีงบประมาณรวมที่ดึงจาก

• Marketing
• IT
• Data
• Operations
• Customer Service

มาร่วมกัน โดยมีเป้าหมายเดียวคือ Increase Customer Lifetime Value เมื่อ Value เกิดขึ้นจึงสามารถประเมินได้ว่าเงินลงทุนทั้งหมดสร้างผลตอบแทนอย่างไร นี่จะทำให้ Budget เริ่มเชื่อมกับ Strategy และ Outcome อย่างแท้จริง

14. Outcome-Based ไม่ใช่การ “เอาใจลูกค้า” อย่างเดียว

คำว่า Outcome บางครั้งอาจถูกตีความว่าเป็น Customer Outcome เท่านั้น แต่จริง ๆ แล้ว Outcome สามารถเกิดขึ้นได้หลายระดับ

Customer Outcome

• ลูกค้าได้รับคุณค่าที่ดีขึ้น

Operational Outcome

• กระบวนการมีประสิทธิภาพมากขึ้น

Employee Outcome

• บุคลากรสามารถทำงานที่มีคุณค่ามากขึ้น

Risk Outcome

• ความเสี่ยงลดลง

Sustainability Outcome

• ผลกระทบต่อสิ่งแวดล้อมหรือสังคมดีขึ้น

Financial Outcome

• Revenue, Margin, Cash Flow หรือ Economic Value ดีขึ้น

ดังนั้น Outcome-Based Organization ต้องพิจารณา Portfolio of Outcomes ไม่ใช่ไล่ล่า Outcome เพียงตัวเดียว

15. จาก Outcome-Based สู่ Value-Based Organization

เมื่อองค์กรสามารถบริหาร Outcome ได้แล้ว ขั้นต่อไปคือการถามว่า “Outcome ไหนสำคัญที่สุด?” เพราะ Outcome ทุกอย่างไม่ได้มี Value เท่ากัน สมมติองค์กรสามารถ

• ลดเวลาการทำงานได้ 10%
• ลดต้นทุนได้ 5%
• เพิ่ม Customer Satisfaction ได้ 3%
• ลด Risk ได้ 20%

คำถามต่อไปคือ ผลรวมของสิ่งเหล่านี้สร้าง Strategic Value เท่าไร? นี่คือจุดที่ Outcome ต้องเชื่อมกับ Value Architecture

Strategic Intent
       ↓
Strategic Outcome
       ↓
Business Outcome
       ↓
Customer / Operational / Risk Outcome
       ↓
Economic Value
       ↓
Enterprise Value

ดังนั้นเป้าหมายสูงสุดไม่ใช่การมี Outcome จำนวนมาก แต่คือการเลือก Outcome ที่มี Strategic Value สูง

16. Framework: จาก Output-Based สู่ Outcome-Based Organization

จากแนวคิดทั้งหมด สามารถสรุปเป็น Framework ได้ดังนี้

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

17. แล้วองค์กรต้องเริ่มเปลี่ยนจากตรงไหน?

การเปลี่ยนไปสู่ Outcome-Based Organization ไม่จำเป็นต้องเริ่มด้วยการ Reorganization ครั้งใหญ่ ผมกลับมองว่า ไม่ควรเริ่มจากการวาด Organization Chart ใหม่ด้วยซ้ำ ให้เริ่มจาก Strategy ก่อน

Step 1 — Identify Strategic Outcomes

ถามว่า องค์กรต้องการให้เกิดอะไรขึ้นจริง ๆ?

Step 2 — Define Value

ถามว่า Outcome นี้สร้างคุณค่าอะไร?

Step 3 — Identify Critical Value Streams

ถามว่า กระบวนการใดมีผลโดยตรงต่อ Outcome?

Step 4 — Identify Capabilities

ถามว่า ต้องมี People, Process, Data, Technology และ AI อะไร?

Step 5 — Assign Outcome Owner

ถามว่า ใครเป็นเจ้าภาพให้ Outcome เกิดขึ้น?

Step 6 — Redesign Metrics

สร้างตัวชี้วัดตั้งแต่ Activity → Output → Outcome → Value

Step 7 — Align Resources

จัด Budget → People → Technology → AI ให้สอดคล้องกับ Strategic Outcomes

นี่เป็นการเปลี่ยนองค์กรจาก “โครงสร้างก่อน แล้วค่อยหาว่าจะทำอะไร” ไปสู่ “รู้ก่อนว่าต้องสร้าง Value อะไร แล้วจึงออกแบบโครงสร้างเพื่อสร้าง Value นั้น”

ประเด็นสำหรับผู้บริหาร

ก่อนจะประกาศว่าองค์กรกำลังทำ Outcome-Based Transformation ผู้บริหารควรถามอย่างน้อย 7 คำถาม

1. เรารู้หรือไม่ว่า Strategic Outcomes ที่สำคัญที่สุดคืออะไร?

2. Outcome แต่ละตัวมี Value Creation ที่ชัดเจนหรือไม่?

3. มีใครเป็น Outcome Owner หรือไม่?

4. Outcome นั้นต้องอาศัยกี่ Function ในการสร้าง?

5. KPI ปัจจุบันวัด Output หรือวัด Outcome?

6. Budget และ Resource ถูกจัดสรรตาม Function หรือ Strategic Outcome?

7. AI ที่องค์กรกำลังลงทุนอยู่กำลังเร่ง Outcome ตัวใด?

หากตอบคำถามเหล่านี้ไม่ได้ องค์กรอาจยังอยู่ในช่วง Activity / Output-Based Management แม้จะมี Digital Technology และ AI อยู่เต็มองค์กรก็ตาม

สรุป: องค์กรยุคใหม่ไม่ได้ต้องการคนที่ “ทำงานให้เสร็จ” มากขึ้นเพียงอย่างเดียว

ในโลกที่ Technology สามารถทำงานซ้ำ ๆ ได้มากขึ้น และ AI สามารถสร้าง Output ได้เร็วขึ้นเรื่อย ๆ ความสามารถในการ “ทำงานให้เสร็จ” จะไม่ใช่ความได้เปรียบเพียงพออีกต่อไป สิ่งที่สำคัญกว่าคือความสามารถในการตอบคำถามว่า “งานที่เราทำกำลังเปลี่ยนแปลงอะไร?” และ “การเปลี่ยนแปลงนั้นสร้างคุณค่าอะไร?” นี่คือหัวใจของการเปลี่ยนจาก Output-Based Organization ไปสู่ Outcome-Based Organization

การเปลี่ยนแปลงนี้ไม่ได้หมายความว่าองค์กรต้องยุบ Functional Department หรือเลิกใช้ KPI แต่หมายถึงการเปลี่ยน จุดศูนย์กลางของการบริหาร จาก Function → Task → Output → KPI ไปสู่ Strategy → Outcome → Value → Capability → Execution และในโลก AI เราสามารถเพิ่มอีกหนึ่งคำถามเข้าไปว่า “AI จะช่วยให้ Outcome นี้เกิดเร็วขึ้น ดีขึ้น หรือสร้าง Value ได้มากขึ้นอย่างไร?”

เมื่อคำถามนี้กลายเป็นส่วนหนึ่งของการบริหาร AI จะไม่ใช่เพียงโครงการของฝ่าย IT และ Outcome ก็จะไม่ใช่เพียง KPI ของฝ่ายใดฝ่ายหนึ่ง แต่ทั้งองค์กรจะเริ่มทำงานในลักษณะ Value Creation Network

อย่างไรก็ตาม เมื่อ Outcome ต้องอาศัยหลาย Function ทำงานร่วมกัน ปัญหาสำคัญก็จะเกิดขึ้นทันทีว่า “ใครคือเจ้าของ Outcome?” เพราะการบอกว่า “ทุกฝ่ายร่วมกันรับผิดชอบ” อาจฟังดูดี แต่ในทางปฏิบัติกลับอาจทำให้ไม่มีใครเป็นเจ้าของผลลัพธ์อย่างแท้จริง

ดังนั้น ขั้นต่อไปของการออกแบบ Outcome-Based Organization จึงต้องตอบเรื่อง Accountability และ Outcome Ownership และนั่นคือหัวใจของตอนที่ 4 Outcome Owner: จากเจ้าของงานสู่เจ้าของผลลัพธ์ เมื่อความรับผิดชอบขององค์กรต้องเปลี่ยนจาก “ฉันทำอะไร” สู่ “ฉันทำให้เกิดอะไร”

ข้อจำกัดของ Balanced Scorecard แบบดั้งเดิมในยุค AI

จาก Performance Measurement สู่ Strategic Value Management

ปัญหาไม่ได้อยู่ที่ Balanced Scorecard แต่อยู่ที่ “โลกเปลี่ยนไป”

เมื่อพูดถึง Balanced Scorecard (BSC) หลายองค์กรยังคงคุ้นเคยกับกรอบ 4 มุมมอง ได้แก่

Financial → Customer → Internal Process → Learning & Growth

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

แต่เมื่อเข้าสู่ยุค Digital และ AI คำถามที่น่าสนใจจึงไม่ใช่ “Balanced Scorecard ยังใช้ได้หรือไม่?” แต่คือ “เรากำลังใช้ Balanced Scorecard เพื่อบริหารองค์กรในโลกที่เปลี่ยนไปด้วยวิธีเดิมหรือไม่?” เพราะสภาพแวดล้อมขององค์กรในปัจจุบันแตกต่างจากช่วงเวลาที่ BSC ถูกนำเสนออย่างมีนัยสำคัญ
ข้อมูลสามารถไหลแบบ Real-time
การตัดสินใจเกิดขึ้นเร็วขึ้น
Business Model เปลี่ยนแปลงได้รวดเร็ว
Digital Platform เชื่อมโยงหลายหน่วยงานเข้าด้วยกัน
และ AI สามารถเข้ามามีบทบาท ตั้งแต่การวิเคราะห์ข้อมูล การคาดการณ์ ไปจนถึงการสนับสนุนหรือดำเนินการบางส่วนของกระบวนการ

ดังนั้น สิ่งที่องค์กรต้องการจาก BSC ในปัจจุบันอาจไม่ใช่เพียง “การวัดว่าเราทำได้ตามแผนหรือไม่” แต่ต้องสามารถตอบได้ด้วยว่า “สิ่งที่เรากำลังทำอยู่กำลังสร้าง Outcome และ Value ให้กับ Strategy หรือไม่?” นี่คือจุดเริ่มต้นของการยกระดับ BSC จาก Performance Measurement System ไปสู่ Strategic Value Management System

1. Balanced Scorecard ไม่ได้มีปัญหา แต่ “วิธีใช้” อาจมีปัญหา

ก่อนจะพูดถึงข้อจำกัด สิ่งสำคัญคือเราต้องเข้าใจว่า BSC ไม่ได้ถูกออกแบบมาให้เป็นเพียงตาราง KPI แก่นของ BSC คือการแปลง Vision และ Strategy ให้กลายเป็น Strategic Objectives และแสดงความสัมพันธ์เชิงเหตุและผลระหว่างองค์ประกอบต่าง ๆ ขององค์กร กล่าวอย่างง่ายคือ ถ้าเราพัฒนาความสามารถบางอย่าง → กระบวนการจะดีขึ้น → ลูกค้าได้รับคุณค่ามากขึ้น → ผลลัพธ์ทางการเงินดีขึ้น นี่เป็นแนวคิดที่ยังมีคุณค่าอย่างมากแม้ในยุค AI ปัญหาจึงเกิดขึ้นเมื่อองค์กรนำ BSC ไปใช้ในลักษณะ Strategy → KPI → Target → Report แล้วจบ

เมื่อเป็นเช่นนั้น BSC จะค่อย ๆ เปลี่ยนจาก Strategic Management Tool กลายเป็น Performance Reporting Tool และเมื่อเกิดเหตุการณ์เช่นนี้ จำนวน KPI มักเพิ่มขึ้นเรื่อย ๆ แต่ความเข้าใจ Strategy กลับไม่ได้เพิ่มขึ้นตาม องค์กรอาจมี Dashboard ที่สวยขึ้น มีข้อมูลมากขึ้น มี Real-time Analytics มากขึ้น แต่ยังไม่สามารถตอบคำถามพื้นฐานได้ว่า “อะไรคือ Outcome ที่สำคัญที่สุด และ Outcome นั้นสร้าง Value ให้กับองค์กรอย่างไร?”

2. ข้อจำกัดประการแรก: 4 Perspectives อาจไม่เพียงพอสำหรับโลกที่ซับซ้อนขึ้น

BSC ดั้งเดิมประกอบด้วย 4 Perspectives:

Financial Perspective

องค์กรสร้างผลตอบแทนทางการเงินได้อย่างไร?

Customer Perspective

องค์กรสร้างคุณค่าให้ลูกค้าอย่างไร?

Internal Process Perspective

องค์กรต้องปรับปรุงกระบวนการใด?

Learning & Growth Perspective

องค์กรต้องพัฒนาความสามารถอะไร?

ทั้งสี่มุมมองยังมีประโยชน์อย่างมาก แต่ในยุค AI เราอาจต้องถามเพิ่มว่า

Data อยู่ตรงไหน?

AI Capability อยู่ตรงไหน?

Digital Architecture อยู่ตรงไหน?

AI Governance อยู่ตรงไหน?

องค์กรสามารถตัดสินใจจาก Intelligence ได้เร็วและแม่นเพียงใด?

สิ่งเหล่านี้ไม่ใช่เพียงเรื่องของ IT เพราะ Data และ AI กำลังกลายเป็น Enterprise Capability

ดังนั้น หากองค์กรยังวาง AI ไว้เพียงภายใต้ Internal Process หรือ IT Initiative อาจทำให้มองไม่เห็นบทบาทเชิงกลยุทธ์ของมันอย่างเต็มที่

3. AI ไม่ควรถูกมองเป็น “อีกหนึ่งโครงการ”

นี่เป็นจุดเปลี่ยนทางความคิดที่สำคัญ องค์กรจำนวนมากเริ่มต้น AI ด้วยคำถามว่า “เราจะนำ AI มาใช้ที่ฝ่ายไหนได้บ้าง?” จึงเกิดโครงการ เช่น

• AI Chatbot
• AI Customer Service
• AI Marketing
• AI Document Processing
• AI Coding
• AI Analytics
• AI Assistant

แต่คำถามในระดับ Strategy ควรกลับด้าน แทนที่จะถามว่า “เราจะเอา AI ไปใช้ตรงไหน?” ควรถามว่า “Strategic Outcome ใดที่เราต้องการเร่ง และ AI สามารถช่วยให้ Outcome นั้นเกิดเร็วขึ้น ดีขึ้น หรือมีต้นทุนต่ำลงได้อย่างไร?” ความแตกต่างของสองคำถามนี้มีความสำคัญมาก

คำถามแรกนำไปสู่ AI Adoption

คำถามที่สองนำไปสู่ AI-enabled Value Creation

4. ข้อจำกัดประการที่สอง: KPI มักถูกแยกออกจาก Causal Relationship

หนึ่งในแนวคิดที่สำคัญของ BSC คือ Cause-and-Effect Relationship ตัวอย่างเช่น

Learning & Growth
↓
Internal Process
↓
Customer
↓
Financial

แต่ในการนำ BSC ไปใช้จริง หลายองค์กรกลับแยก KPI ออกเป็นชุด ๆ

ฝ่าย HR มี KPI ชุดหนึ่ง

IT มี KPI ชุดหนึ่ง

Operations มี KPI ชุดหนึ่ง

Marketing มี KPI ชุดหนึ่ง

Finance มี KPI ชุดหนึ่ง

ทุกฝ่ายอาจบรรลุ KPI ของตัวเอง แต่ไม่ได้หมายความว่า Causal Chain ของ Strategy จะเกิดขึ้นจริง นี่คือปัญหาที่เรียกว่า KPI Optimization without Strategic Optimization หรือพูดง่าย ๆ ว่า “ทุกคนทำคะแนนได้ แต่ Strategy ไม่ได้คะแนน”

ตัวอย่างเช่น

HR ทำ Training ได้ครบ 100%

IT ลด System Downtime ได้ตามเป้า

Operations เพิ่ม Productivity ได้ 15%

Marketing เพิ่ม Leads ได้ 20%

แต่ Revenue กลับไม่เพิ่ม

Customer Retention ลดลง

และ Margin หดตัว

คำถามจึงไม่ใช่ว่า KPI ไหนล้มเหลว แต่คือ ความสัมพันธ์ระหว่าง KPI เหล่านั้นกับ Strategic Outcome อยู่ตรงไหน?

5. ข้อจำกัดประการที่สาม: BSC มักถูกใช้เป็น “Annual Cycle” ในโลกที่เปลี่ยนแบบ Real-Time

องค์กรจำนวนมากยังมีวงจร Strategy Planning → Budget → KPI → Annual Review ซึ่งเหมาะสมกับสภาพแวดล้อมที่มีการเปลี่ยนแปลงไม่รวดเร็วนัก แต่ในโลก Digital และ AI ความเร็วของการเปลี่ยนแปลงสูงขึ้นอย่างมาก สิ่งที่วางแผนไว้ต้นปีอาจไม่เหมาะสมเมื่อผ่านไป 6 เดือน

Customer Behavior เปลี่ยน

คู่แข่งเปลี่ยน

Technology เปลี่ยน

AI Capability เปลี่ยน

ต้นทุนเปลี่ยน

Regulation เปลี่ยน

ดังนั้นองค์กรไม่สามารถมอง Strategy เป็นสิ่งที่กำหนดครั้งเดียวแล้วรอวัดผลปลายปีได้เสมอไป BSC ยุคใหม่จึงควรมีลักษณะเป็น Dynamic Strategy Management มากขึ้น นั่นหมายถึง Measure → Learn → Adapt → Execute → Measure Again แทนที่จะเป็นเพียง Plan → Execute → Report

6. ข้อจำกัดประการที่สี่: การวัด “Performance” ไม่เหมือนการวัด “Value”

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

องค์กรตั้ง KPI ว่า ลดเวลาการอนุมัติจาก 3 วันเหลือ 1 วัน องค์กรทำสำเร็จ Performance = ดีขึ้น แต่ถ้าการอนุมัติเร็วขึ้นไม่ได้ทำให้

• Customer Experience ดีขึ้น
• Revenue เพิ่มขึ้น
• Cost ลดลง
• Risk ลดลง
• Decision Quality ดีขึ้น

แต่แล้ว Value Creation เกิดขึ้นจริงหรือไม่? อาจเกิดขึ้น หรืออาจไม่เกิดขึ้นเลยก็ได้ ดังนั้นเราจำเป็นต้องสร้างสะพานระหว่าง Performance → Outcome → Value

7. จาก KPI Tree สู่ Value Tree

แนวคิดนี้สามารถพัฒนาไปอีกขั้นได้ด้วยการสร้าง Value Tree

ตัวอย่างเช่น

Strategic Objective
│
▼
Improve Customer Experience
│
▼
Reduce Customer Effort
│
▼
Faster Resolution
│
▼
AI-enabled Service
│
▼
First Contact Resolution ↑
│
▼
Customer Retention ↑
│
▼
Customer Lifetime Value ↑
│
▼
Enterprise Value ↑

นี่คือสิ่งที่ BSC ยุคใหม่ควรทำให้ชัดเจนขึ้น ไม่ใช่เพียงถามว่า KPI บรรลุหรือไม่? แต่ควรถามว่า KPI นี้อยู่ตรงไหนของ Value Chain? และ ถ้า KPI เปลี่ยนแปลง จะส่งผลต่อ Outcome และ Value ตัวใด?

8. AI ทำให้ “Learning & Growth” ต้องถูกตีความใหม่

ใน BSC แบบดั้งเดิม Learning & Growth มักเน้นเรื่อง

• People
• Skills
• Culture
• Organizational Capability

แต่ในยุค AI คำว่า Capability มีความหมายกว้างขึ้น องค์กรอาจมีพนักงานเก่งมาก แต่ถ้า Data ไม่พร้อม AI ใช้ไม่ได้ ถ้า Process ไม่เป็นมาตรฐาน AI ก็ Scale ไม่ได้ ถ้า Governance ไม่ชัดเจน AI อาจสร้าง Risk

ดังนั้น AI Capability ไม่ใช่เพียงการมี AI Tool แต่ประกอบด้วยอย่างน้อย People + Process + Data + Technology + AI + Governance ซึ่งความสามารถเหล่านี้ต้องทำงานร่วมกันจึงจะสามารถสร้าง Outcome ได้

9. Governance ไม่ควรอยู่ “หลังบ้าน” ของ AI

เมื่อพูดถึง AI หลายองค์กรคิดถึง Innovation → Speed → Productivity แต่ในระดับ Enterprise จำเป็นต้องคิดถึงอีกด้านหนึ่งด้วย คือ Governance → Risk → Trust → Sustainability

AI ที่สร้างผลลัพธ์เร็วแต่สร้างความเสี่ยงสูง อาจไม่ได้สร้าง Enterprise Value ในระยะยาว ดังนั้น AI Governance, Data Governance, Cybersecurity, Privacy, Model Risk และ Human Oversight จึงไม่ควรถูกมองเป็นเพียง Compliance Layer ที่เข้ามาตรวจสอบภายหลัง แต่ควรเป็น Strategic Guardrails ที่ช่วยให้องค์กรสามารถสร้าง Value จาก AI ได้อย่างยั่งยืน นี่เป็นจุดที่จะเชื่อมต่อ BSC เข้ากับ GRC และ AI Governance ในตอนต่อ ๆ ไป

10. BSC ยุคใหม่จึงต้อง “วัดสิ่งที่สำคัญกว่า KPI”

เมื่อพิจารณาทั้งหมด เราสามารถมองวิวัฒนาการของ BSC ได้เป็น 3 ระดับ

ระดับที่ 1 — Performance Measurement

คำถามคือ

เราทำได้ตามเป้าหรือไม่?

ระดับที่ 2 — Strategic Performance Management

คำถามคือ

Performance ของเราสนับสนุน Strategy หรือไม่?

ระดับที่ 3 — Strategic Value Management

คำถามคือ

สิ่งที่เราทำกำลังสร้าง Outcome และ Value ที่ Strategy ต้องการหรือไม่?

และเมื่อ AI เข้ามาเป็น Enterprise Capability เราสามารถต่อยอดไปสู่ AI-Enabled Strategic Value Management โดยมี Logic ดังนี้

สิ่งที่เปลี่ยนไปจึงไม่ใช่การทิ้ง BSC แต่คือการ เพิ่มความละเอียดของความสัมพันธ์ระหว่าง Strategy, Outcome, Capability และ Value

แล้ว 4 Perspectives ของ BSC ควรหายไปหรือไม่?

คำตอบคือ ไม่ควร นี่เป็นข้อสรุปที่ผมอยากเน้นเป็นพิเศษ เราไม่จำเป็นต้องสร้าง “BSC 2.0” ด้วยการเอา 4 Perspectives เดิมทิ้งแล้วสร้าง 6 หรือ 7 Perspectives ใหม่ เพราะจะกลายเป็นการเพิ่ม Framework เพื่อแก้ปัญหา Framework ซึ่งสุดท้ายผู้บริหารอาจได้ Dashboard เพิ่มอีกหนึ่งอัน แต่ไม่ได้ Strategy เพิ่มเลย

ทางที่เหมาะสมกว่าคือ รักษา 4 Perspectives ไว้เป็น Strategic Architecture แต่ยกระดับ Logic ภายในให้มุ่ง Outcome และ Value Creation มากขึ้น กล่าวคือ

Financial ไม่ใช่แค่ “กำไรเท่าไร?” แต่ถามว่า Strategy สร้าง Economic Value อย่างไร?

Customer ไม่ใช่แค่ “ลูกค้าพอใจหรือไม่?” แต่ถามว่า Customer Outcome ใดนำไปสู่ Customer Value และ Business Value?

Internal Process ไม่ใช่แค่ “Process เร็วขึ้นหรือไม่?” แต่ถามว่า Process ใดเป็น Critical Value-Creating Process?

Learning & Growth ไม่ใช่แค่ “พนักงานได้รับการพัฒนาหรือไม่?” แต่ถามว่า Capability ใดทำให้เกิด Outcome ที่ Strategy ต้องการ?

และในทุก Perspective สามารถมี Data + AI + Governance เป็นความสามารถและกลไกสนับสนุนที่เชื่อมข้ามทุกมิติ

สรุป: อนาคตของ BSC ไม่ใช่การมี KPI มากขึ้น

ข้อจำกัดของ Balanced Scorecard ในยุค AI ไม่ได้เกิดจากแนวคิด 4 Perspectives ที่ผิด แต่เกิดจากการที่องค์กรจำนวนมากนำ BSC ไปใช้ในลักษณะของ KPI Management มากกว่า Strategy Management เมื่อโลกธุรกิจเคลื่อนตัวเร็วขึ้น และ AI เข้ามาเป็นส่วนหนึ่งของ Enterprise Capability องค์กรจำเป็นต้องมองให้ไกลกว่า Performance จาก “เราทำได้ตาม KPI หรือไม่?” ไปสู่ “KPI นี้สนับสนุน Outcome ใด?” และจากนั้นไปสู่คำถามที่สำคัญที่สุดว่า “Outcome นี้สร้าง Value อะไรให้กับองค์กร?”

ดังนั้น BSC ยุคใหม่ไม่จำเป็นต้องทิ้งอดีต แต่ควร ต่อยอดจากรากฐานเดิม จาก Performance Measurement สู่ Strategic Performance Management และก้าวต่อไปสู่ Strategic Value Management โดยมี AI และ Data เป็นส่วนหนึ่งของ Organizational Capability และมี Governance เป็นกลไกสร้างความเชื่อมั่นและควบคุมความเสี่ยง

ท้ายที่สุด องค์กรที่มี BSC ที่ดีจึงไม่ใช่องค์กรที่มี KPI ครบทุกฝ่าย แต่คือองค์กรที่สามารถตอบคำถามได้อย่างชัดเจนว่า

Strategy ของเราต้องการให้เกิด Outcome อะไร?

Outcome นั้นสร้าง Value อะไร?

เราต้องมี Capability อะไรจึงจะสร้าง Outcome นั้นได้?

และ AI จะช่วยเร่งการสร้าง Value นั้นได้อย่างไร?

เมื่อคำถามเหล่านี้เริ่มเปลี่ยน วิธีบริหารก็ต้องเปลี่ยน และสิ่งที่ต้องเปลี่ยนถัดไปก็คือ “โครงสร้างองค์กร” เพราะตราบใดที่องค์กรยังถูกออกแบบให้ทุกคนรับผิดชอบเพียง Function และ KPI ของตัวเอง การสร้าง Outcome ที่ต้องอาศัยหลายหน่วยงานร่วมกันก็ยังคงเป็นเรื่องยาก นี่จึงนำไปสู่แนวคิดสำคัญของตอนที่ 3: จาก Output-Based สู่ Outcome-Based Organization เมื่อองค์กรต้องเปลี่ยนจาก “เราทำอะไร” ไปสู่ “สิ่งที่เราทำ ทำให้เกิดอะไร” ซึ่งผมจะมาพูดคุยในครั้งต่อไปนะครับ