GM sa thải 600 người IT để tuyển AI — bài toán mua mới hay sửa cũ

GM sa thải 600 người IT để tuyển AI — bài toán mua mới hay sửa cũ

Khi một tập đoàn ô tô quyết định đổi máu 10% đội IT, câu hỏi không phải "AI có thay thế người không" mà là "team bạn đang bán đúng hàng chưa".

Nếu sáng thứ Hai bạn nhận mail từ HR nói rằng 10% phòng IT sẽ nghỉ việc — không phải vì công ty thua lỗ, mà vì kỹ năng của họ "không còn khớp" — bạn sẽ nghĩ gì?

General Motors vừa làm đúng chuyện đó: cắt khoảng 600 nhân sự IT lương cứng, rồi tuyển lại đúng số đó nhưng đòi skill khác hoàn toàn. Không phải downsizing. Là skills swap — đổi hàng trên kệ.

Bối cảnh: kệ hàng cũ không ai mua

GM không phải startup đốt tiền thử nghiệm. Đây là tập đoàn ô tô truyền thống với 180.000 nhân viên toàn cầu. Đội IT của họ vận hành hệ thống ERP, quản lý hạ tầng on-premise, duy trì legacy code — những thứ vẫn chạy tốt mỗi ngày.

Nhưng từ giữa 2025, khi Sterling Anderson (cựu đồng sáng lập Aurora, chuyên autonomous vehicle) vào làm Chief Product Officer, GM bắt đầu gom tất cả mảng technology rời rạc vào một tổ chức duy nhất. Ba VP cấp cao rời đi. Và chiến lược chuyển hướng rõ ràng: GM không cần người dùng AI như công cụ hỗ trợ — họ cần người xây AI từ gốc.

Danh sách skill họ tuyển mới: AI-native development, data engineering, cloud-based engineering, agent and model development, prompt engineering. Hiểu nôm na: họ muốn người thiết kế hệ thống AI, train model, dựng pipeline — không phải người biết gõ prompt vào ChatGPT.

Quyết định: dọn sạp cũ, bày hàng mới

Đây là điểm mà nhiều team Việt Nam đang hiểu sai: upskill không phải lúc nào cũng là đáp án.

GM có thể chọn đào tạo lại 600 người. Họ không làm. Tại sao? Vì khoảng cách kỹ năng giữa "quản lý hệ thống ERP" và "xây agent pipeline từ đầu" không phải là một khóa học 3 tháng có thể lấp. Đó là hai nghề khác nhau — như bán rau ở chợ truyền thống và vận hành sàn thương mại điện tử. Cùng bán hàng, nhưng cơ bắp hoàn toàn khác.

Quyết định của GM có ba lớp:

  1. Xác định rõ skill gap — không mơ hồ kiểu "cần biết AI", mà liệt kê cụ thể: ai biết build agent, ai biết thiết kế data pipeline, ai biết engineer prompt ở production level.
  2. Chấp nhận chi phí chuyển đổi — severance cho 600 người, thời gian tuyển mới, onboard, mất productivity 6-12 tháng.
  3. Gắn với chiến lược product — không phải sa thải vì trend, mà vì product roadmap đã thay đổi khi Anderson consolidate toàn bộ tech stack.

Hệ quả: không chỉ GM

Cùng tuần đó, BASF Agricultural Solutions — tập đoàn hóa chất Đức với 180 site sản xuất — tiết lộ họ dùng AlphaEvolve trên Google Cloud để xây digital twin (bản sao số) cho toàn bộ supply chain. Hơn 5.000 chuỗi giá trị, bill of materials sâu hơn 30 tầng. Trước đây, hàng nghìn planner ra quyết định cục bộ mỗi ngày mà không thấy được hiệu ứng domino lên toàn mạng.

Điểm chung giữa GM và BASF: cả hai không hỏi "AI có thể làm gì" mà hỏi "skill nào trong tổ chức đang tạo ra quyết định đúng, skill nào đang tạo ra noise?"

Ở Medicare Mỹ, chương trình ACCESS mới cũng vận hành theo logic tương tự: trả tiền dựa trên kết quả sức khỏe (outcome), không dựa trên số lần khám (activity). AI agent có thể theo dõi bệnh nhân giữa các lần khám, gọi nhắc uống thuốc — nhưng chỉ khi tổ chức có người biết build và vận hành agent đó.

Bài học: framework "kệ hàng" cho team Việt Nam

Giả sử team bạn 8 người, đang vận hành hệ thống cho một công ty vừa. Trước khi hoảng "phải học AI ngay", thử đặt ba câu hỏi:

1. Skill nào đang bán chạy? Liệt kê những việc team làm hàng ngày. Cái nào trực tiếp tạo ra quyết định kinh doanh (deploy feature, tối ưu pipeline, build automation)? Cái nào chỉ duy trì trạng thái (maintain legacy, manual report)?

2. Khoảng cách là bao xa? Nếu gap nhỏ — ví dụ từ backend dev sang xây RAG pipeline — upskill là hợp lý. Nếu gap lớn — từ helpdesk sang ML engineer — thì upskill là lời hứa hão.

3. Product roadmap có đổi không? GM sa thải vì product direction thay đổi, không phải vì AI "hot". Nếu công ty bạn vẫn bán cùng sản phẩm theo cùng cách, thì skills swap kiểu GM là giải pháp sai cho bài toán sai.

Áp dụng: thử trong một buổi chiều

Mở một bảng tính, chia làm 4 cột:

| Skill hiện tại | Đang tạo quyết định hay duy trì? | Gap tới AI-native | Hướng xử lý |
|---|---|---|---|
| Quản lý infra on-prem | Duy trì | Lớn | Xem xét outsource/automate |
| Backend API development | Tạo quyết định | Vừa | Upskill (thêm agent integration) |
| Manual QA | Duy trì | Lớn | Chuyển sang AI-assisted testing |
| Data analyst (SQL + dashboard) | Tạo quyết định | Nhỏ | Upskill (thêm prompt engineering cho data pipeline) |

Không phải mọi ô đều cần action ngay. Nhưng ô nào vừa "duy trì" vừa "gap lớn" — đó là vị trí mà GM đã quyết định cắt.

Cái bẫy: đừng biến thành phiên chợ chiều

Một team mình biết ở Sài Gòn từng sa thải 3 dev legacy Java rồi tuyển 3 "AI engineer" — thực chất là fresher biết chạy notebook. Sáu tháng sau, hệ thống cũ không ai maintain, hệ thống mới chưa lên production. Họ mất cả chì lẫn chài.

Bài học: GM không chỉ cắt — họ cắt sau khi có product roadmap rõ ràng và người dẫn dắt (Sterling Anderson) đã consolidate xong tổ chức. Thứ tự quan trọng: chiến lược trước, kỹ năng sau, headcount cuối cùng.

Nếu bạn đang ở vị trí lead, câu hỏi không phải "team mình có đủ skill AI chưa" mà là "product của mình có thật sự cần AI-native capability, hay mình đang kỳ kèo mua hàng chỉ vì thấy sạp bên cạnh đông khách?"

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo