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” โปรดติดตามนะครับ