Information Technology Governance

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 กันในตอนต่อไปนะครับ