- AI ไม่ได้ทำให้ตำแหน่งหายไปทั้งตำแหน่ง แต่ค่อย ๆ รับงานย่อยที่เป็นมาตรฐานไปทีละอย่าง
- ให้แยกตำแหน่งเป็นงานย่อยก่อนตัดสินใจ จะเห็นชัดว่าส่วนไหนควรให้ระบบทำ และส่วนไหนต้องเก็บไว้กับคน
- งานที่มีค่าขึ้นคืองานที่ต้องใช้ความรับผิดชอบ ความสัมพันธ์ และการตัดสินใจในกรณีที่ไม่มีในคู่มือ
1. วิเคราะห์ Task ก่อนทำนายชื่อตำแหน่ง
ตำแหน่ง “แอดมินฝ่ายขาย” หนึ่งตำแหน่ง จริง ๆ แล้วประกอบด้วยงานย่อยสิบกว่าอย่าง บางอย่างเป็นการคีย์ข้อมูลซ้ำ ๆ บางอย่างต้องโทรง้อลูกค้าที่กำลังโมโห ถ้าตัดสินทั้งตำแหน่งพร้อมกันว่าแทนได้หรือไม่ได้ คุณจะตอบผิดทั้งสองทาง
ตำแหน่ง “แอดมินฝ่ายขาย” อาจประกอบด้วยรับ Lead คีย์ CRM เตรียมเอกสาร นัดหมาย ตามสถานะ และประสานลูกค้า บาง Task Automate ได้สูง บาง Task ต้องใช้ความสัมพันธ์ หากบริษัทประเมินทั้งตำแหน่งว่าแทนได้หรือไม่ได้ จะพลาดโอกาสออกแบบงานใหม่
แบ่ง Task เป็น Routine Information, Variable Information, Physical, Relationship และ Accountability งานอ่าน คัดลอก จัดหมวด สรุป และสร้างเอกสารมีแนวโน้มถูก AI รับมากขึ้น งานที่ต้องรับผิดผลกระทบ เจรจา สัมผัสหน้างาน และสร้างความไว้วางใจยังต้องมีคน แต่จะได้รับข้อมูลจาก AI มากขึ้น
2. กลุ่มงานที่มีแนวโน้มหดตัวหรือเปลี่ยนรูปแบบมาก
งานที่ลดลงก่อนมักมีหน้าตาคล้ายกัน คือเป็นการอ่าน คัดลอก จัดหมวด และส่งต่อ ส่วนงานที่ยังอยู่คืองานที่ต้องตัดสินใจในสถานการณ์ที่ไม่มีในคู่มือ
งานธุรการข้อมูล เช่น คีย์ข้อมูล จัดไฟล์ ตรวจรูปแบบ และรวบรวมรายงาน จะลดลงเมื่อ Agent เชื่อมระบบและรับเอกสารหลากหลายได้ดีขึ้น งานเนื้อหามาตรฐาน เช่น Product Description, Caption และรายงานสรุปจะใช้คนน้อยลงต่อชิ้น แต่ยังต้องมีคนกำหนดทิศและตรวจข้อเท็จจริง
งานประสานสถานะ ที่มีหน้าที่ถามว่าใครทำถึงไหนและส่งต่อข้อมูลจะถูก Workflow แทนมากขึ้น Support ระดับแรก จะเปลี่ยนจากตอบ FAQ เป็นดูแลเคสที่มีอารมณ์ ความเสี่ยง หรือข้อยกเว้น ส่วน Junior Analysis ที่เน้นรวบรวมข้อมูลและทำ Slide อาจลดจำนวน แต่ผู้เริ่มงานจะต้องเรียนรู้ผ่านงานจริงรูปแบบใหม่
การหดตัวไม่ได้เท่ากันทุกอุตสาหกรรม งานที่ข้อมูลไม่เป็นดิจิทัล กฎซับซ้อน หรือมีข้อกำกับอาจเปลี่ยนช้ากว่า เจ้าของต้องใช้ข้อมูลกระบวนการตนเอง ไม่ใช้รายชื่อตำแหน่งจากอินเทอร์เน็ตตัดสินคน
3. งานและบทบาทที่มีค่ามากขึ้น
Domain Expert ที่สอนระบบได้ จะมีค่ากว่าผู้ที่ทำตามขั้นตอนแต่ไม่อธิบายเหตุผล เพราะองค์กรต้องเปลี่ยนความรู้เป็น Rule, Example และ Evaluation Process Designer เชื่อมธุรกิจ เทคโนโลยี และประสบการณ์ลูกค้าเพื่อกำจัด Handoff
สำหรับทีมพัฒนา · รายละเอียดเชิงเทคนิค
AI Quality and Risk ดูแลชุดทดสอบ การสุ่มตรวจ Incident และ Bias Customer Specialist รับสถานการณ์ที่ AI แก้ไม่ได้และมีอำนาจตัดสินใจ Product Experimenter ใช้ AI สร้างและทดสอบไอเดียเร็ว แต่เลือกจากหลักฐานตลาด
ทักษะมนุษย์อย่างการคิดวิเคราะห์ ความคิดสร้างสรรค์ ความยืดหยุ่น ภาวะผู้นำ และการร่วมมือยังสำคัญ เพราะเมื่อการผลิต Draft ถูกลง มูลค่าจะย้ายไปอยู่ที่การเลือกปัญหา ตัดสิน Trade-off และรับผิดชอบผลลัพธ์
4. ใช้ Workforce Matrix แทนการลดแบบเหมา
| กลุ่ม | ลักษณะ Task | กลยุทธ์ |
|---|---|---|
| Automate | ซ้ำ มีกฎ ปริมาณสูง ตรวจง่าย | ลด Touch Time และไม่รับทดแทน |
| Augment | ต้องวิเคราะห์แต่มีข้อมูลช่วยได้ | ฝึกใช้ AI และเพิ่ม Output ต่อคน |
| Human-led | สัมพันธ์ ความรับผิด และข้อยกเว้น | รักษาคนเก่งและเพิ่มอำนาจตัดสินใจ |
| New Work | Agent, Data, Evaluation, Governance | สร้างบทบาทหรือ Skill ใหม่ |
ให้หัวหน้าระบุชั่วโมงต่อกลุ่มของทุกบทบาท แล้วสร้าง Scenario เมื่อ Automate ได้ 25, 50 และ 70 เปอร์เซ็นต์ คำนวณ Capacity และบทบาทที่ต้องเพิ่ม การทำเช่นนี้ทำให้บริษัทเห็นทั้งตำแหน่งที่หดและ Skill Gap ที่อาจขัดขวางการเปลี่ยนแปลง
5. ทักษะสำคัญสำหรับคนทำงานปี 2029
- Problem Framing: เปลี่ยนเป้าหมายกว้างเป็นงาน เกณฑ์ และข้อจำกัดที่ระบบเข้าใจ
- Data Judgment: รู้ว่าแหล่งใดเชื่อได้ เห็นข้อมูลขาด และไม่สรุปเกินหลักฐาน
- Process Thinking: มองงานจากต้นจนจบ แยก Rule, AI และ Human Decision
- Evaluation: สร้างตัวอย่างที่ดี ตรวจคุณภาพ และจำแนกข้อผิดพลาด
- Exception Handling: ตัดสินใจเมื่อข้อมูลคลุมเครือหรือผลกระทบสูง
- Customer Empathy: เข้าใจบริบท ความไว้วางใจ และความต้องการที่ไม่ได้เขียน
- AI Safety Literacy: รู้เรื่องข้อมูลลับ สิทธิ์ Prompt Injection และการตรวจย้อนกลับ
การพิมพ์ Prompt เป็นเพียงทักษะพื้นฐาน เครื่องมือจะช่วยเขียน Prompt ได้เองมากขึ้น สิ่งที่ยั่งยืนคือความเข้าใจธุรกิจและการตัดสินว่าผลลัพธ์ “เหมาะกับบริบทและสร้างคุณค่า” หรือไม่
6. Reskill ต้องผูกกับ Workflow จริง
การอบรม AI ทั่วไปหนึ่งวันทำให้คนทดลอง แต่ไม่เปลี่ยนงาน เลือก Workflow จริง ให้ทีมออกแบบ Before/After ทดลองระบบ และรับผิด KPI ผู้เรียนต้องใช้ข้อมูลที่อนุญาต สร้าง Evaluation และนำเสนอผลธุรกิจ การเรียนรู้จึงกลายเป็นสินทรัพย์ของบริษัท
สำหรับทีมพัฒนา · รายละเอียดเชิงเทคนิค
แบ่งระดับ: AI Literacy สำหรับทุกคน, Workflow Practitioner สำหรับผู้ใช้งาน, Builder สำหรับผู้สร้าง และ Owner สำหรับผู้บริหารความเสี่ยง ให้ Certification ภายในอิงงานที่ส่งมอบ ไม่อิงชั่วโมงเรียน สร้าง Community of Practice แชร์ Template และ Incident
7. วาง Headcount Plan แบบ Scenario
สำหรับทีมพัฒนา · รายละเอียดเชิงเทคนิค
ทำแผน Base, Accelerated และ Constrained ในแต่ละแผนระบุปริมาณงาน Productivity Gain, Attrition, Hiring Freeze, Redeploy และ Role ใหม่ ไม่ควรนับชั่วโมงที่ประหยัดเป็นการลดคนทันที ต้องเห็นว่าชั่วโมงรวมกันเป็น FTE และบริษัท Capture Value อย่างไร
ตั้ง Hiring Gate สำหรับตำแหน่ง Routine: ก่อนอนุมัติรับเพิ่ม ต้องแสดงว่าได้ปรับ Process และประเมิน Automation แล้ว ส่วนตำแหน่ง Human-led ให้เร่งรักษาคนและพัฒนา Skill การใช้ AI เพราะคนกลุ่มนี้จะสร้างผลต่างสูง
8. แผน 12 เดือนสำหรับเจ้าของและ HR
- ไตรมาส 1: ทำ Task Inventory และ Workforce Matrix ใน Workflow สำคัญ
- ไตรมาส 2: ทดลอง Automate/Augment สองกระบวนการ พร้อมหลักสูตรจากงานจริง
- ไตรมาส 3: ปรับ Job Description, KPI, Hiring Gate และ Career Path
- ไตรมาส 4: สร้าง Headcount Scenario 2028–2029 จากผล Productivity จริง
สรุป: งาน Routine Information และ Coordination มีแนวโน้มหดตัว ขณะที่ Domain Judgment, Process Design, Customer Trust และ AI Governance มีค่าขึ้น บริษัทควรเปลี่ยนจากวางกำลังคนตามตำแหน่งเป็นตาม Task และ Workflow พร้อม Reskill บนงานจริง วิธีนี้ลดทั้งการจ้างเกินจำเป็นและความเสี่ยงขาดทักษะในอนาคต
เปลี่ยนแผนกำลังคนให้เป็นข้อมูลที่ตัดสินใจได้ ไม่ใช่ความรู้สึก
คำตอบว่าตำแหน่งไหนควรเพิ่ม ลด หรือเปลี่ยนบทบาท ต้องมาจาก HR และหัวหน้าสายงานที่รู้เนื้องานจริง ไม่ใช่จากบริษัทซอฟต์แวร์ เราจึงเริ่มด้วยการช่วยจัดโครงสร้างสิ่งที่ทีมของคุณรู้อยู่แล้ว โดยแยกหนึ่งตำแหน่งเป็น Task ย่อย ระบุว่าแต่ละ Task ใช้เวลาเท่าไร มีข้อมูลอะไรรองรับ ต้องใช้วิจารณญาณระดับใด และผลกระทบถ้าทำผิดคือเท่าไร เมื่อข้อมูลชุดนี้อยู่ในรูปแบบเดียวกันทั้งบริษัท การเปรียบเทียบระหว่างแผนกจึงเป็นไปได้
ระบบที่ช่วยให้ HR และหัวหน้างานเห็นตรงกัน
สิ่งที่เราสร้างต่อมักเป็น Web Application ภายในสำหรับทำ Task Inventory และ Workforce Matrix ที่หัวหน้าแต่ละทีมกรอกได้เอง มี Role-based View ให้ HR เห็นภาพรวมและให้หัวหน้าเห็นเฉพาะทีมตัวเอง พร้อมโมดูลจำลอง Scenario ว่าถ้าประสิทธิภาพเพิ่ม 20, 40 หรือ 60 เปอร์เซ็นต์ จำนวนคนและบทบาทควรเป็นอย่างไร เราส่งมอบเป็นรอบสั้น เริ่มจากสองสามแผนกก่อนขยายทั้งองค์กร ถ้าตอนนี้คุณกำลังตัดสินใจเรื่องรับคนเพิ่มโดยยังไม่มีข้อมูล Task อยู่ในมือ เรายินดีช่วยตั้งโครงข้อมูลชุดแรกให้
SOFTWARE ENGINEERING GLOSSARY
คลังคำศัพท์การพัฒนาซอฟต์แวร์
คำศัพท์กลุ่มนี้ช่วยให้คุยกับทีมพัฒนาเรื่องระบบข้อมูลบุคลากรได้ตรงจุด
| คำศัพท์ | คืออะไร | ตัวอย่างที่เข้าใจง่าย | คำถามที่ผู้บริหารควรถามทีมพัฒนา |
|---|---|---|---|
| Role-based View | การแสดงข้อมูลต่างกันตามบทบาทของผู้ใช้ในระบบเดียว | หัวหน้าเห็นเฉพาะทีมตน HR เห็นทั้งบริษัท | ใครเห็นข้อมูลระดับใด และเปลี่ยนสิทธิ์เมื่อย้ายตำแหน่งอย่างไร? |
| Data Model | โครงสร้างว่าข้อมูลมีอะไรบ้างและสัมพันธ์กันอย่างไร | ตำแหน่งหนึ่งมีหลาย Task และแต่ละ Task มีเวลาและความเสี่ยง | ถ้าเราอยากเพิ่มมิติใหม่ภายหลัง ต้องรื้อระบบหรือไม่? |
| Scenario Modeling | การจำลองผลลัพธ์ภายใต้สมมติฐานหลายแบบเพื่อเปรียบเทียบทางเลือก | จำลองกำลังคนเมื่อ Automate ได้ 20, 40, 60 เปอร์เซ็นต์ | สมมติฐานมาจากข้อมูลจริงส่วนใด และใครเป็นคนยืนยัน? |
| Capstone | งานจริงที่ผู้เรียนต้องส่งเมื่อจบหลักสูตร ใช้วัดว่าทำได้จริงไม่ใช่แค่ผ่านการอบรม | ให้ทีมออกแบบ Workflow ใหม่ของตัวเองและวัดผลก่อนหลัง | เราวัดผลการเรียนรู้จากงานจริงหรือจากแบบทดสอบ? |
| Adoption Analytics | ข้อมูลว่าคนใช้ระบบจริงแค่ไหนและใช้ทำอะไร | ดูว่ามีหัวหน้ากี่คนอัปเดต Task Inventory ต่อเดือน | เราวัดการใช้งานจริงหรือแค่จำนวนบัญชีที่เปิด? |