Website CLBV.VN và các nền tảng trong hệ sinh thái QuanTriBenhVien.Vn được xây dựng bởi các thành viên có kinh nghiệm tại các bệnh viện, công ty. Web không có liên quan tới bất kỳ Vụ, Cục nào của BYT hay SYT --> chi tiết
Nội dung bạn cần không thấy trên website, có thể do bạn chưa đăng nhập hoặc tài khoản đã hết hạn. Nếu là thành viên của website, bạn cũng có thể yêu cầu trong nhóm Zalo "CLBV Members" các nội dung bạn quan tâm.

Kính gửi Anh/Chị/Em đồng nghiệp,

Trong thời gian qua, CLBV nhận được sự ủng hộ rất lớn từ cộng đồng. Website đã nằm trong nhóm đầu kết quả tìm kiếm với nhiều từ khóa liên quan đến Quản lý chất lượng (QLCL) và An toàn người bệnh (ATNB) trong lĩnh vực y tế.

Tuy nhiên, khi lượng truy cập ngày càng tăng, Công ty M.I.U nhận thấy một số vấn đề cần được điều chỉnh để đảm bảo phù hợp với đặc thù chuyên môn:

1. Nội dung QLCL & ATNB có tính chuyên ngành cao

  • Nhiều nội dung mang tính học tập từ sự cố, cải tiến sau sai sót.
  • Nếu tiếp cận ngoài bối cảnh chuyên môn, có thể bị hiểu chưa đầy đủ hoặc sai lệch.

2. Một số tài liệu quản trị cần được sử dụng đúng đối tượng

  • Dù là văn bản công khai, việc áp dụng hiệu quả đòi hỏi hiểu đúng bối cảnh ngành.
  • Phù hợp hơn khi chia sẻ trong cộng đồng những người trực tiếp làm công tác y tế.

3. Hạn chế nguy cơ nhầm lẫn về nhận diện

  • Tên miền clbv.vn có thể gây hiểu nhầm với các hệ thống chính thức của Bộ Y tế.
  • Việc làm rõ và chuẩn hóa nhận diện là cần thiết.

Công ty M.I.U quyết định nâng cấp hệ thống phục vụ đúng đối tượng chuyên môn

Để đảm bảo chất lượng nội dung và phục vụ tốt hơn cho cộng đồng, chúng tôi thực hiện các điều chỉnh:

  • Giới hạn truy cập nội dung: Website dành cho thành viên đã đăng ký, là các đồng nghiệp đang công tác trong lĩnh vực y tế.
  • Chuyển đổi nhận diện sang tên miền mới: QLCL.NET để đồng bộ thương hiệu với các trang trong hệ sinh thái QuanTriBenhVien.Vn như KHTH.VN; CNTT.IT; KSNK.VN; VTTB.VN; HCQT.VN ... hướng đến chia sẻ kiến thức quản trị hiện đại, liên ngành trong bệnh viện không chỉ giới hạn ở QLCL & ATNB.

Chúng tôi tin rằng đây là bước điều chỉnh cần thiết nhằm:

  • Bảo vệ giá trị chuyên môn của nội dung.
  • Đảm bảo thông tin được sử dụng đúng đối tượng, đúng bối cảnh.
  • Xây dựng cộng đồng chia sẻ chất lượng, hiệu quả.

Rất mong tiếp tục nhận được sự đồng hành của Anh/Chị/Em đồng nghiệp.

Công ty M.I.U

Bài 3. Vì sao nhiều tổ chức " có công cụ nhưng không cải tiến được"

1. Vấn đề không nằm ở tên công cụ, mà ở cách sử dụng

Trong nhiều tổ chức, các công cụ quản lý chất lượng không còn xa lạ. Nhân viên có thể đã từng được đào tạo về 5S, PDCA, 5 Why, Fishbone, Pareto, checklist, KPI hoặc dashboard. Một số nơi có đầy đủ biểu mẫu cải tiến, phiếu phân tích nguyên nhân, bảng theo dõi chỉ số và báo cáo định kỳ. Tuy nhiên, kết quả cải tiến vẫn mờ nhạt, sai sót vẫn lặp lại, quy trình vẫn không ổn định và nhân viên vẫn xem hoạt động chất lượng như một việc bổ sung ngoài chuyên môn.

Điều này cho thấy vấn đề không nằm ở việc tổ chức có biết tên công cụ hay không. Vấn đề nằm ở cách công cụ được lựa chọn, sử dụng, tích hợp và duy trì. Một công cụ tốt nhưng dùng sai mục đích có thể tạo ra kết quả sai. Một biểu mẫu đúng nhưng dữ liệu đầu vào không đáng tin cậy sẽ dẫn đến phân tích sai. Một dự án cải tiến có kế hoạch nhưng không có cơ chế theo dõi sẽ khó duy trì. Một dashboard đẹp nhưng không gắn với quyết định điều hành sẽ không tạo ra thay đổi.

Nói cách khác, công cụ quản lý chất lượng chỉ tạo ra cải tiến khi nó được gắn với vấn đề thật, dữ liệu thật, trách nhiệm thật và quyết định thật. Nếu thiếu bốn yếu tố này, công cụ rất dễ trở thành hình thức.

2. Nguyên nhân thứ nhất: dùng công cụ để hoàn thành hồ sơ thay vì giải quyết vấn đề

Một trong những nguyên nhân phổ biến nhất khiến công cụ không tạo ra cải tiến là tổ chức sử dụng công cụ với mục tiêu chính là hoàn thành hồ sơ. Khi có yêu cầu đánh giá, kiểm tra hoặc báo cáo, các bộ phận bắt đầu lập kế hoạch cải tiến, điền biểu mẫu phân tích nguyên nhân, tạo bảng kiểm, cập nhật chỉ số và lưu minh chứng. Các hoạt động này có thể đầy đủ về mặt tài liệu, nhưng không nhất thiết phản ánh quá trình cải tiến thật.

Khi mục tiêu là hoàn thành hồ sơ, người thực hiện thường quan tâm đến việc biểu mẫu có đủ nội dung hay không, chữ ký đã đầy đủ chưa, báo cáo có đúng hạn không. Họ ít quan tâm hơn đến câu hỏi: vấn đề có được mô tả đúng không, dữ liệu có đáng tin cậy không, nguyên nhân có được kiểm chứng không, giải pháp có tác động vào nguyên nhân gốc không và kết quả có được duy trì không.

Đây là tình trạng chất lượng hình thức. Tổ chức “có công cụ” nhưng công cụ không tham gia vào quá trình ra quyết định. Khi đó, hoạt động quản lý chất lượng dễ bị xem là công việc của bộ phận chất lượng, phòng kiểm soát nội bộ hoặc nhóm phụ trách hồ sơ, thay vì là trách nhiệm cải tiến của toàn bộ hệ thống vận hành.

Để khắc phục, mỗi công cụ phải được gắn với một câu hỏi quản lý cụ thể. Ví dụ, dùng Pareto để quyết định ưu tiên cải tiến, dùng Fishbone để xác định nhóm nguyên nhân cần kiểm chứng, dùng checklist để phát hiện điểm không tuân thủ, dùng run chart để biết giải pháp có tạo ra thay đổi hay không. Nếu một công cụ không giúp đưa ra quyết định hoặc hành động, cần xem lại cách sử dụng công cụ đó.

3. Nguyên nhân thứ hai: chọn công cụ không đúng vấn đề

Không phải công cụ nào cũng phù hợp với mọi tình huống. Một số tổ chức có xu hướng dùng công cụ theo phong trào hoặc theo thói quen, thay vì căn cứ vào bản chất vấn đề. Khi có sự cố thì yêu cầu làm 5 Why; khi có nhiều lỗi thì vẽ Fishbone; khi có dữ liệu thì lập biểu đồ; khi cần báo cáo thì làm dashboard. Cách làm này có thể tạo cảm giác đang quản lý chất lượng, nhưng không đảm bảo giải quyết đúng vấn đề.

Ví dụ, nếu tổ chức chưa có dữ liệu đáng tin cậy về các loại lỗi, việc lập Pareto sẽ không có nhiều giá trị. Nếu quy trình chưa được mô tả rõ, việc đánh giá tuân thủ bằng checklist có thể thiếu cơ sở. Nếu nguyên nhân chưa được kiểm chứng, việc viết SOP mới có thể chỉ chuẩn hóa một cách làm chưa đúng. Nếu chỉ số KPI được thiết kế sai, dashboard sẽ theo dõi những thông tin không giúp điều hành.

Chọn công cụ đúng cần bắt đầu từ câu hỏi: hiện tại tổ chức đang cần hiểu điều gì hoặc quyết định điều gì? Nếu cần hiểu quy trình đang diễn ra ra sao, nên dùng flowchart hoặc SIPOC. Nếu cần biết loại lỗi nào quan trọng nhất, cần check sheet và Pareto. Nếu cần tìm nguyên nhân gốc, có thể dùng Fishbone kết hợp 5 Why. Nếu cần thử nghiệm giải pháp, nên dùng PDCA/PDSA và pilot testing. Nếu cần duy trì tuân thủ, cần SOP và checklist.

Công cụ đúng không phải là công cụ phức tạp nhất, mà là công cụ phù hợp nhất với câu hỏi quản lý đang đặt ra.

4. Nguyên nhân thứ ba: dữ liệu yếu, thiếu hoặc không được tin cậy

Quản lý chất lượng dựa nhiều vào dữ liệu. Tuy nhiên, trong nhiều tổ chức, dữ liệu phục vụ cải tiến thường không đầy đủ, không nhất quán hoặc không phản ánh đúng thực tế. Có nơi dữ liệu được ghi nhận không đều; có nơi nhân viên ngại báo cáo lỗi; có nơi phân loại lỗi không thống nhất; có nơi số liệu được tổng hợp thủ công nhiều lần nên dễ sai lệch; có nơi chỉ ghi nhận những sự việc nghiêm trọng mà bỏ qua sai lệch nhỏ lặp lại hằng ngày.

Khi dữ liệu yếu, công cụ phân tích sẽ cho kết quả yếu. Pareto dựa trên dữ liệu sai sẽ chỉ ra ưu tiên sai. Run chart dựa trên số liệu không ổn định sẽ làm tổ chức hiểu sai xu hướng. KPI không rõ định nghĩa sẽ gây tranh cãi giữa các đơn vị. Fishbone không có dữ liệu kiểm chứng sẽ trở thành danh sách suy đoán.

Một biểu hiện thường gặp là tổ chức phân tích nguyên nhân chủ yếu bằng ý kiến trong cuộc họp. Ý kiến chuyên gia và kinh nghiệm thực tế rất quan trọng, nhưng nếu không được đối chiếu với dữ liệu, tổ chức có thể rơi vào thiên lệch nhận thức. Người có vị trí cao hơn, nói tự tin hơn hoặc có trải nghiệm gần đây hơn dễ ảnh hưởng đến kết luận của nhóm.

Để khắc phục, trước khi dùng công cụ phân tích, tổ chức cần chuẩn hóa cách thu thập dữ liệu. Cần xác định rõ dữ liệu nào được ghi nhận, ai ghi, ghi khi nào, định nghĩa từng loại lỗi là gì, kiểm tra độ đầy đủ ra sao và dữ liệu được sử dụng trong cuộc họp nào. Một check sheet đơn giản nhưng được thiết kế tốt và sử dụng nhất quán có thể tạo nền tảng tốt hơn nhiều so với một dashboard phức tạp nhưng dữ liệu đầu vào không đáng tin cậy.

5. Nguyên nhân thứ tư: phân tích nguyên nhân dừng ở bề mặt

Nhiều tổ chức có thực hiện phân tích nguyên nhân nhưng thường dừng ở mức bề mặt. Các nguyên nhân thường được ghi nhận là “nhân viên chưa tuân thủ”, “thiếu kiểm tra”, “chưa được đào tạo”, “áp lực công việc cao”, “thiếu phối hợp” hoặc “chưa có quy trình”. Những nguyên nhân này có thể đúng, nhưng nếu chỉ dừng ở đó thì giải pháp thường sẽ là nhắc nhở, đào tạo lại, tăng cường kiểm tra hoặc ban hành thêm quy định. Đây là những giải pháp quen thuộc nhưng không phải lúc nào cũng hiệu quả.

Phân tích nguyên nhân gốc đòi hỏi tổ chức phải đi sâu hơn vào điều kiện hệ thống tạo ra sai lệch. Vì sao nhân viên chưa tuân thủ? Quy trình có khó thực hiện không? Biểu mẫu có phức tạp không? Thời gian có đủ không? Công cụ hỗ trợ có thuận tiện không? Người mới có được kèm cặp không? Giám sát có phát hiện sớm không? Chỉ số có phản ánh đúng hành vi cần cải thiện không? Lãnh đạo bộ phận có ưu tiên vấn đề này không?

Nếu nguyên nhân gốc thuộc về thiết kế quy trình nhưng giải pháp chỉ là nhắc nhở cá nhân, vấn đề sẽ tái diễn. Nếu nguyên nhân là phần mềm bắt buộc nhập liệu trùng lặp nhưng giải pháp là yêu cầu nhân viên cẩn thận hơn, cải tiến sẽ không bền. Nếu nguyên nhân là chưa phân quyền rõ giữa hai bộ phận nhưng giải pháp là tổ chức thêm một buổi đào tạo chung, xung đột vẫn có thể tiếp tục.

Công cụ như 5 Why và Fishbone chỉ có giá trị khi người sử dụng đủ trung thực và đủ kiên trì để đi đến nguyên nhân có thể can thiệp ở cấp hệ thống, không dừng ở lỗi cá nhân hoặc lời giải thích dễ chấp nhận.

6. Nguyên nhân thứ năm: giải pháp không tác động vào nguyên nhân gốc

Ngay cả khi phân tích nguyên nhân tương đối đúng, tổ chức vẫn có thể thất bại nếu giải pháp không tác động trực tiếp vào nguyên nhân gốc. Đây là khoảng cách phổ biến giữa “biết vấn đề” và “cải tiến được vấn đề”.

Ví dụ, nếu nguyên nhân gốc của sai sót là biểu mẫu có nhiều trường dễ nhầm, giải pháp phù hợp có thể là thiết kế lại biểu mẫu, thêm hướng dẫn trực quan, cấu hình cảnh báo hoặc loại bỏ trường không cần thiết. Nếu tổ chức chỉ đào tạo lại nhân viên, sai sót có thể giảm tạm thời nhưng dễ quay lại. Nếu nguyên nhân gốc là thiếu bước kiểm tra chéo ở điểm bàn giao quan trọng, giải pháp phải bổ sung cơ chế kiểm soát tại điểm bàn giao, không chỉ nhắc nhở chung.

Một cách kiểm tra đơn giản là đặt câu hỏi: giải pháp này có làm thay đổi điều kiện tạo ra lỗi không? Nếu câu trả lời là không, giải pháp có thể chỉ mang tính hành chính. Các giải pháp như “rút kinh nghiệm”, “nhắc nhở”, “tăng cường kiểm tra”, “đào tạo lại” không phải lúc nào cũng sai, nhưng thường không đủ nếu không đi kèm thay đổi quy trình, công cụ hỗ trợ, phân công trách nhiệm, thiết kế môi trường làm việc hoặc cơ chế đo lường.

Cải tiến chất lượng hiệu quả cần ưu tiên giải pháp làm cho việc đúng trở nên dễ thực hiện hơn và việc sai trở nên khó xảy ra hơn. Đây là tư duy quan trọng khi chuyển từ xử lý con người sang cải tiến hệ thống.

7. Nguyên nhân thứ sáu: thiếu thử nghiệm và đo lường sau can thiệp

Một số tổ chức sau khi xác định giải pháp thường triển khai ngay trên diện rộng mà không thử nghiệm ở quy mô nhỏ. Cách làm này có rủi ro cao, nhất là với các quy trình phức tạp hoặc có nhiều bên liên quan. Giải pháp tưởng như hợp lý trên giấy có thể gặp khó khăn khi áp dụng thực tế: nhân viên không hiểu, phần mềm không hỗ trợ, phát sinh bước thừa, tăng thời gian xử lý hoặc tạo gánh nặng cho bộ phận khác.

Pilot testing giúp tổ chức thử nghiệm thay đổi trong phạm vi nhỏ để học nhanh và điều chỉnh trước khi nhân rộng. Tuy nhiên, thử nghiệm chỉ có ý nghĩa nếu có đo lường. Nếu không đo trước và sau can thiệp, tổ chức sẽ khó biết giải pháp có hiệu quả thật không. Nếu chỉ dựa vào cảm nhận sau triển khai, kết luận dễ bị thiên lệch.

Run chart, KPI theo thời gian, bảng theo dõi lỗi hoặc phản hồi người sử dụng là những công cụ giúp đánh giá kết quả sau can thiệp. Quan trọng hơn, tổ chức cần theo dõi đủ lâu để xem cải tiến có duy trì hay chỉ cải thiện tạm thời trong giai đoạn được chú ý.

8. Nguyên nhân thứ bảy: không chuẩn hóa sau cải tiến

Một lỗi rất phổ biến là tổ chức có cải tiến nhưng không chuẩn hóa. Sau khi giải pháp tạo ra kết quả tốt, nhóm cải tiến kết thúc dự án, báo cáo thành công và chuyển sang việc khác. Tuy nhiên, nếu cách làm mới không được cập nhật vào SOP, không có checklist kiểm soát, không đào tạo lại người liên quan, không đưa vào giám sát định kỳ và không gắn với chỉ số theo dõi, kết quả sẽ phụ thuộc vào trí nhớ và sự tự giác của từng cá nhân.

Chuẩn hóa là cầu nối giữa cải tiến và vận hành. Không chuẩn hóa, cải tiến chỉ là một đợt can thiệp tạm thời. Có chuẩn hóa, cải tiến trở thành cách làm mới của tổ chức.

Việc chuẩn hóa cần trả lời rõ: quy trình nào thay đổi, tài liệu nào cần cập nhật, ai cần được đào tạo, điểm kiểm soát nào cần bổ sung, chỉ số nào cần theo dõi, ai chịu trách nhiệm duy trì và khi nào đánh giá lại. Đây là phần nhiều tổ chức làm chưa tốt vì thường chú trọng giai đoạn phát động cải tiến hơn giai đoạn duy trì sau cải tiến.

9. Nguyên nhân thứ tám: văn hóa tổ chức không ủng hộ cải tiến thật

Công cụ quản lý chất lượng chỉ phát huy tác dụng trong một môi trường cho phép nói thật về vấn đề. Nếu tổ chức có văn hóa đổ lỗi, che giấu sai sót, né tránh dữ liệu xấu hoặc chỉ thích báo cáo thành tích, công cụ sẽ bị bóp méo. Nhân viên sẽ ngại ghi nhận lỗi, nhóm phân tích sẽ tránh nguyên nhân nhạy cảm, báo cáo sẽ trình bày theo hướng an toàn, và cải tiến sẽ chỉ xử lý phần nổi.

Văn hóa chất lượng không có nghĩa là chấp nhận sai sót một cách dễ dãi. Văn hóa chất lượng là tạo điều kiện để sai lệch được phát hiện sớm, báo cáo trung thực, phân tích công bằng và xử lý theo hướng cải tiến hệ thống. Trách nhiệm cá nhân vẫn cần được xem xét khi có vi phạm rõ ràng, nhưng phần lớn vấn đề chất lượng trong vận hành hằng ngày cần được nhìn như tín hiệu để cải tiến quy trình và hệ thống.

Lãnh đạo bệnh viện, lãnh đạo doanh nghiệp hoặc lãnh đạo tổ chức giữ vai trò quyết định trong việc này. Nếu lãnh đạo chỉ hỏi “ai sai?”, công cụ sẽ phục vụ truy lỗi. Nếu lãnh đạo hỏi “hệ thống đã tạo điều kiện cho lỗi xảy ra như thế nào và cần thay đổi gì?”, công cụ sẽ phục vụ cải tiến.

10. Dấu hiệu nhận biết tổ chức đang dùng công cụ hình thức

Một tổ chức có thể đang dùng công cụ theo hướng hình thức nếu xuất hiện các dấu hiệu sau:

  • Có nhiều biểu mẫu chất lượng nhưng ít quyết định cải tiến dựa trên biểu mẫu đó.
  • Báo cáo phân tích nguyên nhân thường kết luận chung chung, lặp lại các nguyên nhân như thiếu ý thức, thiếu kiểm tra, chưa tuân thủ.
  • Giải pháp cải tiến chủ yếu là nhắc nhở, đào tạo lại, tăng cường giám sát nhưng ít thay đổi quy trình hoặc hệ thống.
  • Dashboard có nhiều chỉ số nhưng cuộc họp điều hành không sử dụng để ra quyết định.
  • Checklist được điền đầy đủ nhưng sai sót thực tế vẫn lặp lại.
  • Dự án cải tiến có báo cáo kết thúc nhưng không cập nhật SOP, không theo dõi duy trì.
  • Nhân viên xem hoạt động chất lượng là việc của một phòng ban riêng, không phải công việc của mình.
  • Công cụ chỉ được dùng mạnh trước các đợt kiểm tra, đánh giá hoặc tổng kết.

Nhận diện các dấu hiệu này không nhằm phê phán, mà để tổ chức điều chỉnh cách triển khai. Hầu hết tổ chức đều có thể rơi vào hình thức hóa nếu thiếu cơ chế kết nối công cụ với vận hành thật.

11. Cách chuyển từ “có công cụ” sang “cải tiến được”

Để công cụ tạo ra cải tiến thật, tổ chức cần thay đổi từ tư duy triển khai công cụ sang tư duy giải quyết vấn đề. Trọng tâm không phải là hôm nay dùng công cụ nào, mà là vấn đề nào cần giải quyết và công cụ nào giúp giải quyết vấn đề đó tốt nhất.

Một cách tiếp cận thực tế gồm năm bước:

  1. Bắt đầu từ vấn đề thật: chọn vấn đề có ảnh hưởng rõ đến chất lượng, chi phí, thời gian, an toàn, trải nghiệm khách hàng hoặc hiệu quả vận hành.
  2. Thu thập dữ liệu đủ tin cậy: dùng check sheet hoặc nguồn dữ liệu hiện có, nhưng phải thống nhất định nghĩa và cách ghi nhận.
  3. Phân tích nguyên nhân có kiểm chứng: dùng Pareto, Fishbone, 5 Why nhưng không dừng ở suy đoán.
  4. Thiết kế giải pháp tác động vào hệ thống: ưu tiên thay đổi quy trình, công cụ hỗ trợ, phân công, điểm kiểm soát, đào tạo và môi trường làm việc.
  5. Theo dõi, chuẩn hóa và duy trì: đo kết quả sau can thiệp, cập nhật SOP, dùng checklist hoặc dashboard để giám sát lâu dài.

Cách làm này giúp công cụ trở lại đúng vai trò: hỗ trợ con người hiểu vấn đề và cải tiến hệ thống.

12. Kết luận của bài

Nhiều tổ chức có công cụ nhưng không cải tiến được vì công cụ bị sử dụng sai vai trò. Khi công cụ trở thành hồ sơ, phong trào hoặc biểu mẫu hình thức, nó không thể tạo ra thay đổi. Khi công cụ được gắn với vấn đề thật, dữ liệu thật, nguyên nhân thật, giải pháp thật và trách nhiệm duy trì thật, nó trở thành phương tiện mạnh mẽ để cải tiến.

Bài học quan trọng là không nên hỏi tổ chức có bao nhiêu công cụ quản lý chất lượng, mà nên hỏi: công cụ đó có giúp tổ chức ra quyết định tốt hơn không, có làm giảm sai sót không, có cải thiện quy trình không, có duy trì kết quả không và có thay đổi cách con người làm việc hằng ngày không. Chỉ khi trả lời được những câu hỏi này, công cụ mới thực sự trở thành năng lực quản lý chất lượng.Bài 3.