หลายองค์กรมีประโยคหนึ่งที่ถูกพูดซ้ำบ่อยมาก:

“พนักงานไม่มี Ownership”

พนักงานไม่คิดเอง ไม่ตัดสินใจเอง ต้องรอหัวหน้า ต้องรอ CEO และเมื่อผู้บริหารไม่อยู่ งานหลายอย่างก็หยุดเดิน

เมื่อเห็นอาการแบบนี้ วิธีแก้ที่เกิดขึ้นตามธรรมชาติมักเป็นการพยายามทำให้คน “รับผิดชอบมากขึ้น”

เพิ่ม KPI
เพิ่ม Daily Task
เพิ่ม Dashboard
เพิ่มระบบติดตามงาน
เพิ่มการประชุม
หรือบอกกับทีมว่า “ต้องมี Ownership มากกว่านี้”

แต่คำถามที่สำคัญกว่านั้นคือ:

เรารู้หรือยังว่าปัญหาคือคนไม่มี Ownership จริง ๆ?

หรือสิ่งที่เรากำลังเห็นเป็นเพียง อาการ (Symptom) ของปัญหาเชิงโครงสร้างที่อยู่ลึกกว่านั้น?

ความเห็นไม่ใช่ข้อเท็จจริง

เมื่อแก้ปัญหาที่ซับซ้อนในองค์กร เรามักต้องรับข้อมูลจากหลายฝ่าย

CEO มองเห็นอย่างหนึ่ง
COO อาจมองอีกอย่าง
Manager มีประสบการณ์อีกแบบ
พนักงานที่อยู่หน้างานก็เห็นปัญหาคนละมุม

ข้อมูลเหล่านี้มีคุณค่า แต่ต้องระวังไม่ให้เราเรียกทุกอย่างว่า “Fact”

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

ดังนั้นสิ่งที่เราได้รับในตอนแรกจำนวนมากจึงเป็น Opinion หรือ Perspective

สิ่งเหล่านี้ควรถูกฟัง แต่ไม่ได้หมายความว่าเราต้องนำความคิดเห็นของทุกคนมาหาค่ากลาง แล้วสร้าง Solution ที่ทุกฝ่ายพอใจ

ในปัญหาองค์กรที่ซับซ้อน แทบไม่มีคำตอบที่ทำให้ทุกคนพอใจพร้อมกัน

เป้าหมายของการแก้ปัญหาจึงไม่ใช่ Consensus

แต่คือการตอบให้ได้ว่า:

เรากำลังแก้ปัญหาอะไรอยู่กันแน่?

“พนักงานไม่มี Ownership” เป็นปัญหา หรือเป็นเพียงคำอธิบาย?

ลองสมมติว่า CEO ขององค์กรหนึ่งพูดว่า:

“พนักงานไม่มี Ownership เลย ถ้าผมไม่เข้าออฟฟิศ งานก็ไม่เดิน”

สิ่งแรกที่ควรทำไม่ใช่รีบหาวิธีสร้าง Ownership

แต่ต้องถือประโยคนี้ไว้ก่อนในฐานะ สมมติฐาน

จากมุมของ CEO พฤติกรรมที่เห็นอาจชัดมาก:

พนักงานไม่ตัดสินใจ
ผู้จัดการส่งเรื่องขึ้นมาให้อนุมัติ
เรื่องเล็ก ๆ ก็ต้องรอ
CEO กลายเป็นคอขวดขององค์กร

จึงเป็นเรื่องง่ายที่จะสรุปว่า “คนไม่คิดเอง”

แต่เมื่อไปดูจากอีกด้าน พนักงานอาจพูดว่า:

“ฉันรู้ว่าหน้าที่ตัวเองคืออะไร”

“ฉันรู้ว่าวันนี้ต้องทำอะไร และบางครั้งงานก็มากเกินไปด้วยซ้ำ”

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

ทันทีที่ข้อมูลนี้ปรากฏขึ้น ปัญหาก็เปลี่ยนรูปไปแล้ว

มันอาจไม่ใช่ปัญหาของ Motivation

แต่อาจเป็นปัญหาของ Decision Authority

ถ้าอยากให้คนตัดสินใจ เขาต้องรู้ก่อนว่าเขามีสิทธิ์ตัดสินใจอะไร

ลองนึกถึง Manager คนหนึ่ง

องค์กรบอกว่า:

“คุณเป็น Manager คุณต้องตัดสินใจเอง”

แต่ในชีวิตจริง ทุกครั้งที่เขาตัดสินใจ คนที่มีประสบการณ์มากกว่า CEO หรือผู้บริหารอีกคนสามารถเข้ามา Override การตัดสินใจนั้นได้เสมอ

ถ้าเขาตัดสินใจผิด เขาต้องรับผิดชอบ

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

เมื่อเกิดซ้ำ ๆ คนคนนั้นจะเรียนรู้อะไร?

เขาจะเรียนรู้ว่า:

“คิดไปก็ไม่ได้ใช้”

และเมื่อเกิดเรื่องที่มีความเสี่ยง ทางเลือกที่ปลอดภัยที่สุดก็กลายเป็น:

“ถาม CEO ก่อน”

นี่อาจดูเหมือนคนไม่มี Ownership จากข้างบน

แต่จากข้างล่าง มันคือพฤติกรรมการป้องกันตัวเองที่สมเหตุสมผลมาก

ถ้าฉันตัดสินใจเองแล้วผิด ฉันรับผิด

แต่ถ้าฉันถาม CEO แล้ว CEO เป็นคนตัดสินใจ ความเสี่ยงนั้นก็ไม่ได้อยู่ที่ฉันเพียงคนเดียว

ดังนั้นระบบอาจกำลังสอนให้คน อย่าตัดสินใจเอง ในขณะที่ผู้บริหารกำลังถามว่า

“ทำไมคนของเราไม่กล้าตัดสินใจ?”

Responsibility ที่ไม่มี Authority ไม่ได้สร้าง Ownership

ถ้าเราต้องการ Ownership สิ่งที่ต้องออกแบบไม่ใช่แค่ Responsibility

แต่ต้องมีความสัมพันธ์ที่ชัดเจนระหว่าง:

Responsibility — Authority — Accountability

คนต้องรู้ว่า:

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

แน่นอนว่าไม่ใช่ทุกเรื่องควรกระจายอำนาจ

การตัดสินใจบางอย่างมีผลกระทบต่อธุรกิจสูง มีความเสี่ยงสูง หรือย้อนกลับได้ยาก ก็อาจสมควรต้องได้รับ Approval จากระดับบน

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

ไม่อย่างนั้นสิ่งที่องค์กรสร้างขึ้นคือ

Accountability without Authority

และนั่นเป็นสภาพแวดล้อมที่เอื้อต่อการป้องกันตัวเอง มากกว่าการเกิด Ownership

แล้วปัญหาอยู่ที่ Workflow, JD หรือ Recruitment?

เมื่อขุดลงไปถึงจุดนี้ ปัญหามักไม่หยุดอยู่ที่ Workflow

เราอาจพบว่า Decision Boundary ไม่ชัด เพราะ Job Description ไม่เคยระบุอย่างจริงจังว่าตำแหน่งนี้เป็นเจ้าของการตัดสินใจเรื่องใด

เมื่อกลับไปดู JD อาจพบอีกว่าองค์กรนิยามคำว่า “Manager” แบบกว้างเกินไป

Manager ที่ต้องดูแลทีม Junior จำนวนมาก ต้องการความสามารถในการนำคน พัฒนาคน และจัดการงานของทีม

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

ทั้งสองตำแหน่งอาจมีคำว่า Manager เหมือนกัน

แต่ต้องการคนคนละแบบ

ถ้าตั้งโจทย์ Role ผิดตั้งแต่ต้น Recruitment ก็อาจเลือกคนผิดประเภทเข้ามา

ดังนั้นปัญหาที่เริ่มต้นด้วยประโยคว่า

“พนักงานไม่มี Ownership”

อาจพาเราย้อนกลับไปได้ไกลถึง:

Workflow
Decision-making Structure
Role Design
Job Description
Management Structure
และ Recruitment

นี่คือเหตุผลที่การแก้ปัญหาองค์กรด้วยการกระโดดไปที่ Solution เร็วเกินไปมักไม่ได้ผล

แยก Symptom ออกจาก Root Cause

หนึ่งในขั้นตอนสำคัญที่สุดของการแก้ปัญหาเชิงโครงสร้างคือการไม่เอา Symptom ไปตั้งเป็น Problem

ตัวอย่างของ Symptom คือ:

“CEO ไม่เข้าแล้วงานไม่เดิน”

“คนไม่ตัดสินใจ”

“Manager ต้องถามทุกเรื่อง”

“พนักงานไม่มี Ownership”

สิ่งเหล่านี้บอกเราว่า ระบบกำลังแสดงพฤติกรรมอะไร

แต่ยังไม่ได้บอกว่า อะไรทำให้ระบบสร้างพฤติกรรมนั้น

ถ้าเราแก้ Symptom โดยตรง เราอาจสร้าง Daily Task เพิ่ม

เพิ่ม Tool

สร้าง Approval System ใหม่

เพิ่ม KPI

จัด Training

หรือเปลี่ยนคน

และบางครั้งสิ่งเหล่านี้ทำให้องค์กรดูเหมือนกำลังจัดการปัญหา ทั้งที่ Root Cause เดิมยังอยู่

ผลคือระบบใหม่ถูกวางทับลงบนปัญหาเก่า

และองค์กรซับซ้อนขึ้นเรื่อย ๆ

ข้อมูลมากขึ้น ไม่ได้หมายถึงเข้าใจมากขึ้น

อีกกับดักหนึ่งของการแก้ปัญหาองค์กรคือความเชื่อว่า:

ยิ่งฟังคนมาก ยิ่งมีข้อมูลมาก เรายิ่งตัดสินใจได้ดีขึ้น

ไม่เสมอไป

การฟัง Stakeholder ที่เกี่ยวข้องเป็นสิ่งสำคัญ

แต่คนทุกคนในองค์กรไม่จำเป็นต้องมีน้ำหนักเท่ากันต่อคำถามทุกคำถาม

ถ้าเราไม่รู้ว่ากำลังพยายามตอบคำถามอะไรอยู่ เราจะสะสมความคิดเห็นจำนวนมากโดยไม่มีโครงสร้างในการแยก Signal ออกจาก Noise

เมื่อถึงจุดหนึ่ง:

More opinions ≠ More information

และ

More information ≠ More clarity

บางครั้งข้อมูลที่เพิ่มขึ้นไม่ได้ช่วยให้ตัดสินใจดีขึ้น

มันเพียงเพิ่ม Noise จนการตัดสินใจยากกว่าเดิม

เริ่มจากคำถามที่ถูกต้อง

เวลาฉันเข้าไปมองปัญหาที่ซับซ้อน ฉันจึงไม่เริ่มจากคำถามว่า:

“แต่ละฝ่ายต้องการอะไร?”

และไม่ได้เริ่มจาก:

“เราจะสร้าง Solution ที่ทำให้ทุกคนพอใจได้อย่างไร?”

ฉันเริ่มจาก:

“เรากำลังพยายามแก้อะไร?”

จากนั้นจึงค่อยแยก:

อะไรคือ Fact
อะไรคือ Opinion
อะไรคือ Symptom
อะไรคือ Constraint
อะไรคือผลของโครงสร้างปัจจุบัน
และอะไรคือ Root Cause ที่ทำให้ระบบสร้างพฤติกรรมเหล่านี้ขึ้นมา

เพราะปัญหาหลายอย่างที่ดูเหมือนเป็น People Problem

แท้จริงแล้วอาจเป็น Structural Problem

และถ้าโครงสร้างเป็นสิ่งที่สร้างพฤติกรรมขึ้นมา

การพยายามแก้คน โดยไม่แก้ระบบที่คนเหล่านั้นกำลังทำงานอยู่ภายใน

ก็อาจไม่มีวันแก้ปัญหานั้นได้จริง