Ở bài viết “Vấn đề của bạn là gì?” trước đây, mình đã đề cập đến 8 bước giải quyết vấn đề. 8 bước này là những giai đoạn cần thiết để chúng ta có thể suy nghĩ rõ ràng, rành mạch tránh bị rơi vào cách giải quyết vấn đề theo kinh nghiệm và cảm tính. Ở Toyota có một phương pháp là “văn bản hóa trên một tờ giấy A3” – nghĩa là chỉ sử dụng 1 tờ giấy A3 duy nhất để tóm tắt thật súc tích và viết ra những tư duy của mình để giải quyết vấn đề đó theo 8 bước.
Để đi sâu vào tìm hiểu 8 bước này thật đầy đủ, có lẽ cần tới một cuốn sách. Trong phạm vi bài viết này, mình sẽ cố gắng rút ngọn nhất mà vẫn giữ được nội dung chủ yếu để chúng ta có thể nắm được cơ bản cách giải quyết vấn đề theo 8 bước này như thế nào.
Có lẽ bạn cũng từng gặp tình huống này: vấn đề cứ tái diễn mãi dù đã “fix” nhiều lần. Lý do thường là vì chúng ta nhảy thẳng vào giải pháp mà không dành thời gian hiểu rõ vấn đề thực sự là gì. Mình cũng từng mắc sai lầm này nhiều lần.
Trong bài viết “Vấn đề của bạn là gì?” trước đây, mình đã đề cập đến 8 bước giải quyết vấn đề. 8 bước này là những giai đoạn cần thiết để chúng ta có thể suy nghĩ rõ ràng, rành mạch tránh bị rơi vào cách giải quyết vấn đề theo kinh nghiệm và cảm tính.
Ở Toyota có một phương pháp là “văn bản hóa trên một tờ giấy A3” – nghĩa là chỉ sử dụng 1 tờ giấy A3 duy nhất để tóm tắt thật súc tích và viết ra những tư duy của mình để giải quyết vấn đề đó theo 8 bước. Nghe có vẻ đơn giản, nhưng thực tế nó đòi hỏi tư duy rất kỷ luật.
Bài viết này mình sẽ chia sẻ chi tiết hơn về từng bước, kèm theo những kinh nghiệm thực tế mà mình đã học được qua các năm.
TẠI SAO CẦN MỘT PHƯƠNG PHÁP CÓ CẤU TRÚC?
Trước khi đi vào chi tiết 8 bước, mình muốn chia sẻ tại sao phương pháp có cấu trúc lại quan trọng.
Theo kinh nghiệm của mình, khi gặp vấn đề, phản ứng tự nhiên của chúng ta là muốn giải quyết nhanh. Thấy máy hỏng thì sửa máy, thấy lỗi thì fix lỗi. Nhưng cách này thường chỉ giải quyết được triệu chứng, không phải nguyên nhân. Rồi vài tuần sau, vấn đề lại xuất hiện.
8 bước này giúp chúng ta:
- Dừng lại và suy nghĩ thật kỹ trước khi hành động
- Dựa vào dữ liệu thực tế, không phải assumption
- Giải quyết triệt để để vấn đề không tái phát
- Tạo ra những cải tiến có thể nhân rộng được
Quan trọng nhất, nó giúp cả team cùng nhìn vấn đề theo một hướng, thay vì mỗi người một kiểu.
BƯỚC 1: LÀM SÁNG TỎ VẤN ĐỀ
Điều đầu tiên cần làm là xác định vấn đề cần giải quyết. Nghe đơn giản nhưng đây là bước mình thấy nhiều người hay vội vàng nhất.
Việc xác định đúng bước 1 và bước 2 quyết định tới 70% kết quả của giải quyết vấn đề. Điều này mình đọc được và sau này thực tế cho thấy đúng như vậy. Khi thiết lập vấn đề, chúng ta phải dựa vào dữ liệu thực tế và thông tin phải đầy đủ. Nếu không có căn cứ thì đôi khi đó không phải là vấn đề để giải quyết.
Ví dụ thực tế mình từng gặp: Có công ty đặt ra vấn đề “Giảm tỷ lệ lỗi phát sinh xuống còn 1%/tháng”. Nhưng thực tế số liệu thống kê cho thấy tỷ lệ lỗi hàng tháng chỉ là 0.8%. Như vậy thì công ty không cần phải làm gì cũng đã đạt mục tiêu. Chọn sai vấn đề do không có căn cứ sẽ dẫn đến các bước tiếp theo trở nên vô nghĩa và lãng phí thời gian.
Làm rõ vấn đề với 5W1H
Khi xác định vấn đề, mình thường tự hỏi:
- What (Cái gì): Vấn đề cụ thể là gì? Không nên chung chung kiểu “chất lượng kém” mà phải rõ ràng như “tỷ lệ scratch trên bề mặt sản phẩm A tăng từ 2% lên 8%”
- Where (Ở đâu): Vấn đề xảy ra ở line nào? Công đoạn nào?
- When (Khi nào): Bắt đầu từ khi nào? Ca nào hay xảy ra hơn?
- Who (Ai): Ai bị ảnh hưởng? Khách hàng? Team nội bộ?
- Why (Tại sao): Tại sao vấn đề này quan trọng?
- How much (Mức độ): Ảnh hưởng đến mức nào? (con số cụ thể)
Sau khi đã xác định được vấn đề, cần làm rõ lý do lựa chọn dựa trên 3 tiêu chí:
- Tại sao lại lựa chọn vấn đề này?
- Tính nghiêm trọng, tính khẩn cấp và khuynh hướng trầm trọng hóa của vấn đề
- Dùng số liệu để hiển thị mức độ nghiêm trọng, khẩn cấp và trầm trọng hóa của vấn đề
Một điều quan trọng mình học được
Đối với người quản lý, khi đi tìm và làm sáng tỏ vấn đề họ sẽ gặp phải trở ngại là khuynh hướng che giấu những điều không tốt từ nhân viên. Khi bắt tay vào giải quyết vấn đề, sẽ có lúc đương đầu với những điều thực sự không muốn đối mặt.
Những lúc đó, nếu cấp trên chỉ biết nổi giận trách mắng cấp dưới thì sẽ chỉ làm cho nhân viên muốn che giấu vấn đề khi phạm lỗi. Điều này không bồi dưỡng được năng lực giải quyế vấn đề cho tập thể.
Mình luôn nhắc nhở bản thân: Đừng đổ lỗi cho con người, hãy tập trung vào hệ thống. Từ đó mới có thể xây dựng được tinh thần cùng nhau giải quyết vấn đề trong tập thể, cùng nhau cải tiến, giúp cho hệ thống ngày càng vững mạnh.
Mẹo nhỏ từ kinh nghiệm
Problem statement tốt nên theo công thức: [Vấn đề gì] + [Con số cụ thể] + [So với baseline] + [Trong khoảng thời gian nào]
Ví dụ tốt: “Thời gian chuyển đổi line sản xuất sản phẩm B tăng từ 45 phút lên 85 phút (cao hơn tiêu chuẩn 60 phút) trong Q3/2024”
Ví dụ chưa tốt: “Changeover time quá lâu”
BƯỚC 2: NẮM RÕ HIỆN TRẠNG
Khi phát hiện ra vấn đề rồi thì điều đầu tiên cần làm là chia nhỏ vấn đề vì hầu hết các vấn đề lớn đều được tạo thành từ những vấn đề nhỏ, khiến chúng trở nên rối rắm, phức tạp.
Sau khi nắm bắt hiện trạng vấn đề dựa trên số liệu, chúng ta sẽ tìm kiếm sai lệch trong số liệu.
Phương pháp 1: Phân nhóm đối tượng
Mình thường dùng Pareto chart cho bước này vì nó giúp nhìn rõ 80% vấn đề thường đến từ 20% nguyên nhân.
Ví dụ thực tế: Đối với vấn đề giảm khiếu nại của khách hàng xuống còn 0 vụ/năm. Chúng ta chia theo bộ phận phát sinh, theo dòng sản phẩm, theo chủng loại lỗi…
Mình từng gặp trường hợp công ty có 50 complaints/tháng. Sau khi phân tích Pareto thì phát hiện:
- Lỗi ngoại quan: 40 vụ (80%)
- Scratch: 25 vụ (chiếm 50% tổng)
- Ố vàng: 10 vụ
- Bavia sắc: 5 vụ
- Lỗi chức năng: 7 vụ (14%)
- Lỗi packaging: 3 vụ (6%)
Từ đó, dễ dàng đưa ra quyết định nên tập trung vào giải quyết scratch trước, vì nó chiếm tới 50% tổng khiếu nại.
Phương pháp 2: Tam hiện – Genchi Genbutsu Genjitsu
Đây là phương pháp mình rất thích ở Toyota: nắm bắt hiện trạng dựa trên chủ nghĩa tam hiện “hiện trường-hiện thực-hiện vật”.
Vấn đề không tự xuất hiện, chắc chắn phải tồn tại quá trình dẫn đến vấn đề đó. Dựa trên việc nắm bắt hiện trạng bằng cách quan sát hiện trường, ta có thể nhìn ra vấn đề nằm ở đâu một cách chân thực nhất.
Kinh nghiệm của mình: Đừng chỉ ngồi trong phòng nhìn report. Đi xuống hiện trường, xem sản phẩm lỗi thực tế, nói chuyện với operator đang làm. Nhiều khi những gì bạn thấy trên giấy rất khác với thực tế dưới line.
Có lần mình gặp vấn đề về defect rate cao, nhìn data thì không hiểu tại sao. Xuống hiện trường mới phát hiện conveyor belt đã mòn, cọ xát vào sản phẩm gây scratch. Điều này không ai report vì họ đã quen với nó.
Lưu ý quan trọng
Nếu bạn không thể chia nhỏ vấn đề thành ít nhất 3-5 categories, có thể bạn chưa phân tích đủ sâu. Cứ tiếp tục breakdown cho đến khi thấy rõ pattern.
BƯỚC 3: THIẾT LẬP MỤC TIÊU
Mục tiêu phải là những kết quả muốn đạt được đối với những vấn đề cụ thể, có thể lượng hóa được như tăng doanh thu lên 40% so với 6 tháng đầu năm, hay giảm chi phí vận tải 5% so với năm 2020.
SMART Goals
Mình học được một framework rất hữu ích là SMART:
- Specific: Cụ thể, không chung chung
- Measurable: Đo lường được bằng con số
- Achievable: Khả thi, không phi thực tế
- Relevant: Liên quan đến mục tiêu lớn hơn của công ty
- Time-bound: Có deadline rõ ràng
So sánh:
- Mục tiêu kém: “Cải thiện chất lượng”
- Mục tiêu tốt: “Giảm tỷ lệ scratch từ 8% xuống 3% trong vòng 3 tháng, đạt mức tiêu chuẩn 2% vào Q1/2025”
Bí quyết từ các chuyên gia
Bí quyết của một số chuyên gia đào tạo giải quyết vấn đề là phải đặt ra mục tiêu cao hơn một chút so với khả năng thực hiện từ 20-30%.
Lý do? Nếu mục tiêu quá dễ dàng đạt được, sẽ không khích lệ tinh thần cố gắng sáng tạo và cải tiến của nhân viên. Nếu mục tiêu quá cao so với khả năng, nhân viên dù cố gắng đến đâu cũng không thể đạt được thì họ sẽ nhanh chóng chán nản và bỏ cuộc từ sớm.
Mình thấy điều này rất đúng. Target vừa đủ challenging sẽ push team nghĩ ra những cách sáng tạo, nhưng vẫn có thể đạt được nếu cố gắng.
Cách kiểm tra mục tiêu
Trước khi finalize mục tiêu, mình thường tự hỏi: “Nếu đạt được con số này, vấn đề có thực sự được giải quyết không?”
Nếu không chắc chắn, có nghĩa mục tiêu cần điều chỉnh. Có thể target sai hoặc chưa đủ ambitious.
BƯỚC 4: TRUY TÌM NGUYÊN NHÂN CỐT LÕI
Đây là bước mình thấy quan trọng nhất, và cũng là bước dễ bị skip nhất.
Ở bước này, chúng ta sẽ dùng phương pháp 5 Why – Đặt 5 lần câu hỏi “Tại sao?” để truy tìm tới cùng nguyên nhân làm phát sinh vấn đề cần giải quyết. Nếu không triệt để tìm kiếm nguyên nhân cốt lõi thì chỉ có được phương án nửa vời và vấn đề có thể sẽ tái phát trong tương lai.
Ví dụ thực tế về 5 Why
Để bạn hình dung rõ hơn, mình chia sẻ một case mình từng gặp:
Vấn đề: Máy CNC dừng đột ngột
Case A: Root cause đúng
5 Why:
- Why: Máy dừng? → Circuit breaker bật
- Why: Circuit breaker bật? → Dòng điện cao
- Why: Dòng điện cao? → Bearing kẹt
- Why: Bearing kẹt? → Không được bôi trơn
- Why: Không bôi trơn? → Không có checklist bảo trì
Validation:
- Kiểm tra hiện trường: Thật sự không có checklist
- Test 1: Nếu tạo checklist → vấn đề giải quyết
- → Root cause đúng
Case B: Root cause sai – cần đào sâu thêm
5 Why ban đầu: 1-4: (giống case A) 5. Why: Không bôi trơn? → Không có checklist
Nhưng khi validation:
- Kiểm tra: À ra ĐÃ CÓ checklist từ 2 năm trước, nhưng không ai làm theo!
- → Root cause SAI! Cần continue:
5 Why đúng: 5. Why: Không bôi trơn? → Có checklist nhưng không follow
6. Why: Có checklist mà không follow? → Không có ai check/audit
7. Why: Không có ai check? → Không có ownership và accountability system
→ Root cause thật sự: Thiếu accountability system, không phải thiếu checklist.
Một lưu ý từ kinh nghiệm
Kỹ thuật phân tích 5 Why là một kỹ thuật tương đối khó, mà những người làm sản xuất lâu năm đôi khi cũng hay mắc sai lầm.
Sai lầm phổ biến:
- Dừng lại quá sớm (chỉ 2-3 Why)
- Blame con người thay vì blame system
- Chấp nhận câu trả lời đầu tiên mà không validate
Root cause thật sự thường nằm ở system/process level, không phải individual level. Nếu câu trả lời của Why thứ 5 là “người này làm sai”, bạn chưa đào đủ sâu. Hãy tiếp tục hỏi: “Tại sao người này làm sai? Có SOP không? Có training không? Có tools đầy đủ không? Có ai check không?”
Cách validate root cause:
Khi nghĩ rằng đã tìm ra root cause, hãy đi xuống hiện trường verify lại:
- Điều này có thật sự đang xảy ra không?
- Nếu fix cái này, vấn đề có biến mất không?
- Có phải chỉ có một root cause hay còn nhiều nguyên nhân khác?
Đừng ngại tiếp tục đào sâu nếu cảm thấy chưa chạm đến tận gốc của vấn đề.
Kết hợp với Fishbone Diagram
Ngoài ra, có thể dùng một số công cụ như biểu đồ xương cá (Fishbone/Ishikawa) kết hợp cùng phương pháp này để kết quả phân tích được chính xác hơn.
Mình thường dùng framework 6M để brainstorm các nguyên nhân có thể:
- Man (Người): Training đủ chưa? Skill level?
- Machine (Máy): Máy móc có vấn đề gì không?
- Material (Nguyên liệu): Chất lượng input có ổn định không?
- Method (Phương pháp): Quy trình có chuẩn chưa?
- Measurement (Đo lường): Cách đo có chính xác không?
- Mother Nature (Môi trường): Nhiệt độ, độ ẩm, ánh sáng có ảnh hưởng không?
Ví dụ với vấn đề scratch:
- Man: Operator không được training đúng cách handling
- Machine: Conveyor belt bị mòn cọ vào sản phẩm
- Material: Film bảo vệ kém chất lượng, dễ bong ra
- Method: Quy trình handling chưa standardized
- Measurement: Không có inspection checkpoint để catch sớm
- Environment: Độ ẩm cao gây tĩnh điện hút bụi
BƯỚC 5: LẬP ĐỐI SÁCH GIẢI QUYẾT VẤN ĐỀ
Sau khi đã hiểu rõ root cause, đến lúc brainstorm solutions.
Đối sách đưa ra càng nhiều thì càng tốt. Nguyên nhân cốt lõi thường không chỉ có một, do đó ta nên xây dựng đối sách cho từng nguyên nhân một cách riêng biệt.
Ở giai đoạn brainstorming, mình luôn nhắc team: “No idea is bad idea”. Đừng judge hay reject ideas ngay, hãy để mọi người thoải mái đưa ra mọi ý tưởng. Sau đó mới filter.
Tiêu chí chọn lọc đối sách
Để chọn lọc các đối sách, mình thường dựa vào 5 tiêu chí sau:
- Đối sách có hiệu quả không? – Nó có giải quyết được root cause không?
- Đối sách có khả thi hay không? – Với resources hiện tại có làm được không?
- Chi phí và thời gian để thực hiện đối sách là như thế nào? Cần bao nhiêu nhân lực?
- Khi thực hiện đối sách, có rủi ro nào xảy ra không? – Side effects?
- Khi thực hiện đối sách, người thực hiện có tiến bộ, hay phát triển bản thân hay không? – Điều này quan trọng cho long-term
Ma trận đánh giá
Mình thường làm một bảng đơn giản để so sánh:
| Đối sách | Hiệu quả | Chi phí | Thời gian | Khả thi | Priority |
|---|---|---|---|---|---|
| A | Cao | Thấp | 2 tuần | Cao | #1 |
| B | Cao | Cao | 3 tháng | Thấp | #3 |
| C | Vừa | Vừa | 1 tháng | Cao | #2 |
Từ đó, dễ dàng quyết định nên làm gì trước, gì sau.
Quick wins vs Long-term solutions
Mình thường phân loại solutions thành:
- Quick wins: Hiệu quả vừa phải, dễ làm → làm ngay để có momentum
- Big bets: Hiệu quả cao, khó làm, cần resources → lên kế hoạch kỹ
- Fill-ins: Hiệu quả thấp, dễ làm → làm khi rảnh
- Thankless tasks: Hiệu quả thấp, khó làm → KHÔNG LÀM
Nguyên tắc quan trọng
Nguyên tắc cơ bản của đối sách là chỉ được suy nghĩ trong phạm vi trách nhiệm của bản thân.
Nếu chỉ đưa ra được đối sách theo kiểu đùn đẩy trách nhiệm sang người khác (ví dụ: “Bộ phận kia phải làm tốt hơn”), thì ngay từ bước 1 đã có sai lầm và cần quay lại từ bước thiết lập vấn đề.
Đây là một điều mình học được và thấy rất đúng: chúng ta chỉ có thể kiểm soát những gì trong tay mình. Focus vào đó sẽ hiệu quả hơn là complain về những gì ngoài tầm kiểm soát.
BƯỚC 6: THỰC HIỆN ĐỐI SÁCH
Khi bắt tay vào làm, cần kiên trì thực hiện cho tới khi có thành quả mới thôi. Kết quả cho dù thất bại cũng là một thành quả.
Bước này nghe đơn giản nhưng thực tế lại là nơi nhiều project “chết” nhất. Lý do? Thiếu discipline và follow-through.
Action plan cụ thể
Mình thường tạo một action plan rõ ràng:
- Ai làm gì (Responsible person)
- Deadline bao giờ (Cụ thể ngày tháng)
- Resources cần gì (Budget, tools, people support)
- KPIs đo như thế nào (Metrics to track)
- Check-in frequency (Weekly? Daily?)
Không có action plan = không có accountability = công việc sẽ bị trôi.
PDCA trong implementation
Trong quá trình thực hiện, mình thường apply PDCA cycle:
- Plan: Kế hoạch chi tiết
- Do: Thực hiện theo plan
- Check: Theo dõi progress, check có đúng hướng không
- Act: Điều chỉnh nếu cần
Đừng chờ đến cuối mới check. Check thường xuyên để kịp điều chỉnh.
Pilot test trước khi scale
Một tip mình học được: nếu solution ảnh hưởng lớn, hãy thử nghiệm quy mô nhỏ trước (pilot).
Ví dụ: Thay vì thay đổi quy trình toàn bộ 10 lines cùng lúc, hãy thử ở 1 line trước. Nếu tốt, mới scale ra. Điều này giảm risk và cho phép learning từ mistakes khi impact còn nhỏ.
BƯỚC 7: XÁC NHẬN HIỆU QUẢ
Sau khi implement, chúng ta cần confirm xem solution có work không.
Khi đối sách không hiệu quả nghĩa là ta đã xác định sai nguyên nhân cốt lõi từ bước số 4 và cần quay lại bước 4 để phân tích lại.
Đừng ngại quay lại bước trước. Đó là phần bình thường của process. Mình từng phải quay lại bước 4 nhiều lần vì nhận ra mình chưa tìm đúng root cause.
Metrics để đo lường
Có hai loại metrics mình thường track:
Leading indicators (chỉ báo sớm): Process metrics
Ví dụ: Tỷ lệ tuân thủ checklist bôi trơn = 95%
Lagging indicators (chỉ báo muộn): Result metrics
Ví dụ: Số lần máy dừng/tháng giảm từ 12 → 2
Leading indicators cho bạn biết bạn đang làm đúng process. Lagging indicators cho bạn biết bạn đang đạt results.
Timeline validation
Việc xác nhận đối sách thường được chia làm nhiều giai đoạn như 6 tháng không phát sinh lỗi, 12 tháng không phát sinh lỗi.
Mình thường set checkpoints:
- Short-term (1-2 tháng): Xem có improvement ban đầu không?
- Mid-term (3-6 tháng): Xem có sustained không? Hay chỉ là “honeymoon effect”?
- Long-term (12 tháng): Xem có regression không? Có new problems phát sinh không?
Chỉ khi kết quả thu được đảm bảo tính tất nhiên và tính kế tục (ai cũng có thể làm được) thì mới được công nhận và đánh giá.
Đây là điểm khác biệt giữa “tạm thời giải quyết được” và “giải quyết bền vững”. Chú
BƯỚC 8: TIÊU CHUẨN HÓA
Tiêu chuẩn hóa là một quá trình để bất kỳ ai, làm vào bất kỳ lúc nào cũng cho ra được kết quả giống nhau. Điều này giúp nhân rộng thành công và ổn định quản lý.
Đây là bước mà nhiều người hay bỏ qua vì nghĩ rằng “vấn đề đã giải quyết rồi thì xong”. Nhưng thực ra, nếu không standardize, knowledge sẽ chỉ nằm trong đầu vài người, và khi họ nghỉ việc hoặc chuyển bộ phận, mọi thứ lại quay về như cũ.
Standardization không chỉ là viết SOP
Khi nói đến tiêu chuẩn hóa, nhiều người nghĩ ngay đến việc viết SOP (Standard Operating Procedure). Đúng, nhưng không chỉ thế.
Một tiêu chuẩn tốt cần có 4 yếu tố:
- Ai cũng hiểu: Ngôn ngữ đơn giản, có hình ảnh minh họa, không dùng thuật ngữ quá kỹ thuật
- Ai cũng làm được: Không cần skill đặc biệt hay phụ thuộc vào kinh nghiệm lâu năm
- Ai làm cũng ra kết quả như nhau: Reproducible, không phụ thuộc vào “tay nghề” cá nhân
- Dễ dàng audit/check: Có checkpoints rõ ràng để verify
Các công cụ standardization
Mình thường dùng:
- SOP/SOM: Quy trình bước by bước
- Work Instructions: Hướng dẫn chi tiết hơn, có hình ảnh, videos
- Checklists: Danh sách kiểm tra để đảm bảo không bỏ sót bước nào
- Visual Management: Biển báo, color coding, andon, one-point lessons ngay tại hiện trường
Yokotenkai – Triển khai ngang
Có một khái niệm mình rất thích trong Lean là Yokoten (横展開) – nghĩa là “triển khai ngang” hay “horizontal deployment”.
Sau khi standardize ở một khu vực và thấy hiệu quả, chúng ta triển khai best practice đó sang các khu vực khác.
Ví dụ thực tế: Giảm được scratch ở Line A từ 8% xuống 2% bằng cách cải tiến quy trình handling và thêm protective film tốt hơn. Sau khi confirm hiệu quả 3 tháng, áp dụng same solution sang Line B, C, D. Không cần phải “reinvent the wheel” mỗi line.
Yokoten giúp scale success nhanh hơn và tránh lãng phí effort.
Tiêu chuẩn là nền tảng của cải tiến
Một lưu ý quan trọng là vấn đề chỉ thực sự được giải quyết và kết thúc khi xây dựng được hệ thống để vấn đề không xảy ra thêm lần nào nữa.
Nhưng tiêu chuẩn không phải là “set and forget”. Trong triết lý Kaizen (cải tiến liên tục), tiêu chuẩn là baseline để chúng ta cải tiến lên mức cao hơn.
Chu trình là: Standardize → Improve → Standardize lại ở level cao hơn → Improve tiếp…
Không có tiêu chuẩn thì không biết mình đang ở đâu để cải tiến. Có tiêu chuẩn rồi thì biết được gap và hướng phát triển.
MỘT CASE STUDY THỰC TẾ
Để bạn thấy rõ hơn cách 8 bước này work trong thực tế, mình chia sẻ một case mình từng tham gia.
Bối cảnh
Công ty sản xuất linh kiện điện tử gặp vấn đề tỷ lệ rework cao, ảnh hưởng đến cost và delivery time.
Áp dụng 8 bước
Bước 1 – Làm sáng tỏ vấn đề:
Vấn đề cụ thể: Tỷ lệ rework của sản phẩm X tăng từ 3% lên 12% trong tháng 10/2024. Nghĩa là cứ 100 sản phẩm thì có 12 cái phải làm lại, gấp 4 lần mức bình thường.
Bước 2 – Nắm rõ hiện trạng:
Phân tích Pareto cho thấy:
- 80% rework do lỗi hàn (soldering defects)
- Trong đó, cold solder joint chiếm 60%
- Xảy ra chủ yếu ở shift 2 (ca chiều tối)
- Tập trung ở 2-3 operators cụ thể
Xuống hiện trường quan sát, phát hiện thêm: Ánh sáng ở shift 2 kém hơn shift 1, và operators shift 2 ít kinh nghiệm hơn.
Bước 3 – Thiết lập mục tiêu:
Giảm tỷ lệ rework xuống 5% trong 2 tháng (từ 12% → 5%), với target dài hạn là quay về 3% như trước.
Bước 4 – Truy tìm nguyên nhân:
Dùng 5 Why:
- Why 1: Tại sao cold solder? → Nhiệt độ mỏ hàn không đủ
- Why 2: Tại sao nhiệt độ không đủ? → Operator không check nhiệt độ trước khi hàn
- Why 3: Tại sao không check? → Không có SOP yêu cầu check nhiệt độ
- Why 4: Tại sao không có SOP? → Training dựa vào kinh nghiệm thợ cũ truyền miệng, không có documentation
- Why 5: Tại sao không có hệ thống training? → Không có ai responsible cho việc standardize process và training
Root cause: Thiếu ownership trong việc xây dựng và duy trì standard work.
Bước 5 – Lập đối sách:
Brainstorm và chọn lọc:
- Xây dựng SOP chi tiết cho quy trình hàn (Priority 1 – Quick win)
- Training lại toàn bộ operators về SOP mới (Priority 1)
- Thêm checkpoint: Check nhiệt độ mỗi 2 giờ và ghi vào checklist (Priority 1)
- Cải thiện ánh sáng ở shift 2 (Priority 2 – Trung hạn)
- Visual aid: Dán ảnh good vs bad solder ngay tại workstation (Priority 1)
- Mua thiết bị auto temperature control (Priority 3 – Dài hạn, đắt)
Bước 6 – Thực hiện:
- Tuần 1: Viết SOP với sự tham gia của thợ giỏi
- Tuần 2: Training toàn bộ shift 2, có hands-on practice
- Tuần 2-3: Deploy checklist và visual aids
- Tuần 4: Cải thiện lighting
Bước 7 – Xác nhận hiệu quả:
Track daily rework rate:
- Sau 2 tuần: 12% → 8% (có improvement)
- Sau 1 tháng: 8% → 6%
- Sau 2 tháng: 6% → 4% (vượt target 5%)
- Sau 3 tháng: stable ở 3-4%
Bước 8 – Tiêu chuẩn hóa:
- SOP được approve chính thức, trở thành standard cho cả công ty
- Checklist nhiệt độ trở thành daily routine, được audit hàng tuần
- Best practice này được yokoten (deploy ngang) sang các line khác đang làm soldering
- Thêm vào onboarding training cho new hire
Bài học rút ra
Điều mình học được từ case này: Vấn đề không nằm ở “tay nghề thợ kém” mà nằm ở “hệ thống chưa có”.
Khi đã có SOP rõ ràng, checklist, training đúng cách, và visual aids, ai cũng có thể làm tốt. Đó là sức mạnh của standardization.
MỘT VÀI SUY NGHĨ CUỐI
Sau nhiều năm áp dụng 8 bước này, mình có vài suy nghĩ muốn chia sẻ:
1. Discipline quan trọng hơn tools
Có rất nhiều tools đẹp mắt: Fishbone, Pareto, 5 Why, A3… Nhưng quan trọng nhất vẫn là discipline để đi qua từng bước một cách nghiêm túc.
Nhiều người biết tools nhưng vẫn hay skip bước, nhảy thẳng vào solution. Đó là lý do vấn đề cứ tái diễn.
2. Không sợ quay lại bước trước
8 bước không phải là đường thẳng. Đôi khi đến bước 7 mới phát hiện solution không work, và phải quay lại bước 4 phân tích lại. Đó là điều bình thường.
Better to admit we were wrong và fix đúng, hơn là cố chấp với solution sai.
3. Team work quan trọng
Giải quyết vấn đề một mình rất khó. Có team để brainstorm, challenge assumptions, và execute together sẽ hiệu quả hơn nhiều.
Và quan trọng là create một môi trường mà mọi người không sợ nói ra vấn đề. Nếu văn hóa công ty là blame và punish, người ta sẽ che giấu vấn đề thay vì giải quyết.
4. Practice makes better
Lần đầu áp dụng 8 bước sẽ thấy khó và mất thời gian. Nhưng càng làm nhiều, càng trở nên tự nhiên.
Mình recommend bắt đầu với những vấn đề nhỏ để practice. Không cần vấn đề lớn mới áp dụng. Vấn đề nhỏ cũng là cơ hội để rèn luyện tư duy.
5. Đừng perfect is the enemy of good
Đừng chờ đến khi có đủ data hoàn hảo, team hoàn hảo, timing hoàn hảo mới bắt đầu. Start với những gì có trong tay, rồi improve dần.
A3 done imperfectly còn tốt hơn A3 perfect mà không bao giờ bắt đầu.
RESOURCES HỮU ÍCH
Nếu bạn muốn học sâu hơn về 8 bước này, mình có chuẩn bị một số tài liệu:
📥 [Download miễn phí A3 Problem Solving Template]
📥 [Download 5 Why Analysis Worksheet]
📥 [Download Action Plan Tracker]
Những templates này sẽ giúp bạn structure suy nghĩ và không bỏ sót bước nào.
CHIA SẺ KINH NGHIỆM CỦA BẠN
Mình rất muốn nghe kinh nghiệm của bạn. Bạn đã từng áp dụng phương pháp có cấu trúc nào để giải quyết vấn đề chưa? Khó khăn lớn nhất bạn gặp phải là gì?
Hãy chia sẻ trong phần comment bên dưới. Có thể câu chuyện của bạn sẽ giúp được người khác đang gặp tình huống tương tự.
HỌC THÊM VỀ PROBLEM SOLVING
Nếu bạn muốn đi sâu hơn vào từng công cụ và techniques, mình có viết thêm các bài chi tiết:
- [5 Why Analysis: Hướng dẫn chi tiết và những sai lầm cần tránh] → Đào sâu vào kỹ thuật 5 Why với nhiều ví dụ thực tế
- [Fishbone Diagram: Cách phân tích nguyên nhân có hệ thống] → Hướng dẫn sử dụng Ishikawa diagram
- [PDCA Cycle: Nền tảng của cải tiến liên tục] → Hiểu rõ Plan-Do-Check-Act
- [ECRS: 4 nguyên tắc cải tiến quy trình] → Eliminate, Combine, Rearrange, Simplify
- [Kaizen: Triết lý cải tiến từng ngày] → Continuous improvement mindset
Những bài này sẽ bổ sung cho kiến thức về 8 bước và giúp bạn có thêm tools trong “túi đồ nghề”.
Muốn thành thạo Problem Solving với practice exercises và case studies thực tế?
Mình đang chuẩn bị khóa học chi tiết về Problem Solving cho Manufacturing, bao gồm video tutorials, templates, và real-world projects để bạn practice.
[Đăng ký nhận thông báo sớm + Ưu đãi 50%]
Bài viết được cập nhật lần cuối tháng 10/2025
Manufacturingway
2 bình luận về “8 BƯỚC GIẢI QUYẾT VẤN ĐỀ”