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 4. Nguyên tắc sử dụng công cụ hiệu

1. Công cụ chỉ hiệu quả khi được dùng đúng nguyên tắc

Công cụ quản lý chất lượng không phải cứ sử dụng là có hiệu quả. Cùng một công cụ, cùng một biểu mẫu, cùng một tên gọi, nhưng kết quả có thể rất khác nhau giữa các tổ chức. Nơi dùng đúng, công cụ giúp phát hiện vấn đề, phân tích nguyên nhân, cải tiến quy trình và duy trì kết quả. Nơi dùng sai, công cụ tạo thêm giấy tờ, tăng gánh nặng hành chính và làm nhân viên mất niềm tin vào hoạt động chất lượng.

Vì vậy, trước khi học sâu từng công cụ, cần nắm vững các nguyên tắc sử dụng công cụ. Những nguyên tắc này giúp tổ chức tránh lạm dụng, tránh hình thức hóa và đảm bảo công cụ phục vụ mục tiêu cuối cùng là cải tiến chất lượng vận hành.

Nguyên tắc chung là: bắt đầu từ vấn đề, chọn công cụ phù hợp, sử dụng dữ liệu đáng tin cậy, phân tích trung thực, chuyển kết quả thành hành động, chuẩn hóa sau cải tiến và duy trì trong hệ thống. Nếu thiếu một trong các mắt xích này, công cụ có thể vẫn được dùng nhưng giá trị cải tiến sẽ giảm đáng kể.

2. Nguyên tắc 1: Bắt đầu từ vấn đề, không bắt đầu từ công cụ

Sai lầm phổ biến là tổ chức quyết định triển khai một công cụ trước khi xác định rõ vấn đề cần giải quyết. Ví dụ, tổ chức phát động 5S toàn đơn vị nhưng chưa phân tích khu vực nào đang có lãng phí lớn nhất; yêu cầu các bộ phận làm Fishbone nhưng chưa xác định vấn đề cụ thể; xây dashboard nhưng chưa rõ chỉ số nào thật sự cần cho điều hành.

Cách đúng là bắt đầu từ vấn đề. Tổ chức cần mô tả rõ vấn đề đang xảy ra: vấn đề là gì, xảy ra ở đâu, ảnh hưởng đến ai, mức độ ra sao, có xu hướng tăng hay giảm, liên quan đến quy trình nào và nếu không cải tiến thì hậu quả là gì. Khi vấn đề đã rõ, việc chọn công cụ sẽ hợp lý hơn.

Ví dụ, nếu vấn đề là “thời gian chờ của khách hàng tăng”, công cụ ban đầu có thể là flowchart để mô tả luồng xử lý, check sheet để ghi nhận thời gian từng công đoạn, Pareto để xác định điểm nghẽn chính, sau đó dùng 5 Why để phân tích nguyên nhân tại điểm nghẽn. Nếu bắt đầu ngay bằng việc yêu cầu nhân viên “làm PDCA” mà chưa hiểu vấn đề, kế hoạch cải tiến dễ chung chung.

Câu hỏi kiểm tra nguyên tắc này là: công cụ đang dùng giúp trả lời câu hỏi quản lý nào? Nếu không trả lời được, có thể tổ chức đang dùng công cụ theo phong trào.

3. Nguyên tắc 2: Chọn công cụ phù hợp với giai đoạn cải tiến

Mỗi công cụ có vai trò riêng trong chu trình cải tiến. Không nên dùng một công cụ cho mọi mục đích. Cũng không nên dùng nhiều công cụ chỉ để chứng minh rằng hoạt động cải tiến có vẻ đầy đủ. Chọn công cụ phù hợp cần dựa vào giai đoạn của vấn đề.

Khi cần nhận diện và mô tả vấn đề, có thể dùng check sheet, flowchart, SIPOC, run chart hoặc khảo sát. Khi cần xác định ưu tiên, Pareto là công cụ phù hợp. Khi cần phân tích nguyên nhân, có thể dùng Fishbone, 5 Why hoặc phân tích quy trình. Khi cần thiết kế giải pháp, có thể dùng 5W1H, brainstorming, action plan hoặc risk assessment. Khi cần thử nghiệm và theo dõi, có thể dùng PDCA/PDSA, pilot testing, run chart, control chart hoặc KPI. Khi cần chuẩn hóa và duy trì, có thể dùng SOP, checklist, dashboard, audit checklist và visual management.

Chọn sai công cụ có thể làm lệch hướng cải tiến. Ví dụ, dùng checklist để kiểm tra tuân thủ khi quy trình chưa được chuẩn hóa sẽ tạo ra tranh cãi. Dùng KPI khi chưa thống nhất định nghĩa dữ liệu sẽ dẫn đến báo cáo không đáng tin cậy. Dùng Fishbone khi chưa mô tả rõ vấn đề sẽ tạo ra phân tích quá rộng và khó hành động.

Một nguyên tắc thực tế là không chọn công cụ vì công cụ đó nổi tiếng, mà chọn vì nó giúp nhóm cải tiến đi tiếp một bước cụ thể trong quá trình giải quyết vấn đề.

4. Nguyên tắc 3: Dữ liệu phải đủ tin cậy trước khi phân tích

Công cụ quản lý chất lượng phụ thuộc nhiều vào chất lượng dữ liệu. Nếu dữ liệu đầu vào sai, thiếu hoặc không nhất quán, kết quả phân tích sẽ sai. Đây là nguyên tắc đặc biệt quan trọng nhưng thường bị xem nhẹ.

Trước khi phân tích, tổ chức cần kiểm tra một số điểm cơ bản: dữ liệu có được định nghĩa rõ không, nguồn dữ liệu có đáng tin cậy không, người ghi nhận có hiểu giống nhau không, dữ liệu có bị thiếu không, có thiên lệch do ngại báo cáo không, có sự khác biệt giữa các bộ phận trong cách ghi nhận không. Nếu các câu hỏi này chưa được trả lời, tổ chức cần củng cố cách thu thập dữ liệu trước khi lập biểu đồ hoặc kết luận.

Ví dụ, nếu các bộ phận hiểu khác nhau về khái niệm “hồ sơ trễ hạn”, dữ liệu tổng hợp toàn tổ chức sẽ không đáng tin cậy. Nếu lỗi nhỏ không được ghi nhận vì nhân viên sợ bị phê bình, Pareto sẽ chỉ phản ánh phần nổi của vấn đề. Nếu dữ liệu được nhập lại thủ công qua nhiều bước, cần kiểm tra nguy cơ sai lệch trong quá trình tổng hợp.

Dữ liệu không nhất thiết phải hoàn hảo mới được dùng, nhưng phải đủ rõ về nguồn gốc, định nghĩa và giới hạn. Khi dữ liệu còn hạn chế, báo cáo cần nêu rõ hạn chế đó để tránh kết luận quá mức.

5. Nguyên tắc 4: Phân tích trung thực, không dùng công cụ để hợp thức hóa kết luận có sẵn

Một nguy cơ lớn khi sử dụng công cụ là nhóm cải tiến đã có sẵn kết luận trong đầu, sau đó dùng công cụ để minh họa cho kết luận đó. Khi đó, công cụ không còn là phương tiện khám phá sự thật mà trở thành công cụ hợp thức hóa quan điểm có sẵn.

Phân tích trung thực đòi hỏi nhóm cải tiến chấp nhận khả năng nguyên nhân thật có thể khác với suy đoán ban đầu. Có thể vấn đề không nằm ở nhân viên mà nằm ở thiết kế quy trình. Có thể lỗi không nằm ở bộ phận cuối cùng phát hiện sai sót mà nằm ở đầu vào từ bộ phận trước. Có thể chỉ số xấu không phải do năng lực cá nhân mà do mục tiêu đặt ra không phù hợp với nguồn lực. Có thể giải pháp tổ chức đang muốn triển khai không phải là giải pháp tốt nhất.

Để bảo đảm phân tích trung thực, cần có dữ liệu, sự tham gia của người trực tiếp làm việc, không khí thảo luận không đổ lỗi và cơ chế kiểm chứng nguyên nhân. Với Fishbone, không nên xem mọi nguyên nhân ghi trên sơ đồ đều là nguyên nhân thật; đó mới là giả thuyết cần kiểm chứng. Với 5 Why, không nên dừng lại ở câu trả lời thuận tiện nhất; cần tiếp tục hỏi cho đến khi tìm được nguyên nhân có thể can thiệp bằng thay đổi hệ thống.

Một công cụ được dùng trung thực có thể làm lộ ra những bất cập khó nghe. Nhưng chính những phát hiện này mới có giá trị cải tiến.

6. Nguyên tắc 5: Công cụ phải dẫn đến quyết định hoặc hành động

Công cụ không nên dừng lại ở sản phẩm đầu ra như biểu đồ, sơ đồ hoặc bảng phân tích. Sau mỗi công cụ cần có quyết định hoặc hành động tiếp theo. Nếu không có hành động, công cụ chỉ tạo ra tài liệu.

Sau Pareto, tổ chức cần quyết định vấn đề nào được ưu tiên. Sau Fishbone, cần chọn nguyên nhân nào cần kiểm chứng. Sau 5 Why, cần xác định nguyên nhân gốc và giải pháp tương ứng. Sau flowchart, cần chỉ ra điểm nghẽn hoặc bước không tạo giá trị. Sau run chart, cần quyết định có tiếp tục can thiệp, điều chỉnh hay chuẩn hóa. Sau checklist, cần xử lý các điểm không tuân thủ và phân tích xu hướng sai lệch.

Một cách đơn giản để kiểm tra là thêm câu hỏi cuối cùng vào mọi buổi sử dụng công cụ: “Vậy quyết định tiếp theo là gì?” hoặc “Ai sẽ làm gì sau phân tích này?” Nếu cuộc họp kết thúc với một sơ đồ đẹp nhưng không có hành động cụ thể, công cụ chưa hoàn thành vai trò.

Hành động sau phân tích cần rõ người chịu trách nhiệm, rõ thời hạn, rõ nguồn lực, rõ chỉ số theo dõi và rõ cách kiểm tra kết quả. Đây là lý do 5W1H hoặc action plan thường cần đi kèm sau các công cụ phân tích.

7. Nguyên tắc 6: Ưu tiên giải pháp tác động vào hệ thống, không chỉ nhắc nhở cá nhân

Công cụ quản lý chất lượng nên giúp tổ chức cải thiện hệ thống, không chỉ tìm lỗi cá nhân. Trong nhiều vấn đề chất lượng, con người là người thực hiện sai lệch, nhưng hệ thống là nơi tạo điều kiện cho sai lệch xảy ra. Nếu hệ thống không được cải thiện, việc nhắc nhở cá nhân chỉ có tác dụng ngắn hạn.

Giải pháp tác động vào hệ thống có thể bao gồm thiết kế lại quy trình, đơn giản hóa biểu mẫu, chuẩn hóa hướng dẫn, cải thiện phần mềm, bố trí lại môi trường làm việc, thêm cảnh báo trực quan, phân quyền rõ hơn, thay đổi điểm kiểm soát, thiết kế checklist bắt buộc tại khâu nguy cơ cao hoặc điều chỉnh cơ chế giám sát.

Điều này không có nghĩa là bỏ qua trách nhiệm cá nhân. Những hành vi vi phạm quy định, cố ý làm sai hoặc thiếu trách nhiệm nghiêm trọng vẫn cần xử lý. Tuy nhiên, trong cải tiến chất lượng thường quy, nếu tổ chức chỉ dừng ở nhắc nhở và kỷ luật, các lỗi hệ thống sẽ tiếp tục lặp lại.

Nguyên tắc này có thể được diễn đạt ngắn gọn: sau mỗi phân tích nguyên nhân, hãy hỏi “chúng ta sẽ thay đổi điều kiện làm việc như thế nào để việc đúng dễ hơn và việc sai khó hơn?”

8. Nguyên tắc 7: Thử nghiệm trước khi nhân rộng

Không phải giải pháp nào hợp lý trên giấy cũng hiệu quả trong thực tế. Trước khi triển khai rộng, đặc biệt với các thay đổi ảnh hưởng đến nhiều bộ phận hoặc nhiều người, nên thử nghiệm ở phạm vi nhỏ. Pilot testing giúp tổ chức phát hiện vấn đề phát sinh, điều chỉnh giải pháp và tăng khả năng chấp nhận khi nhân rộng.

Thử nghiệm cần có mục tiêu rõ, phạm vi rõ, thời gian rõ, tiêu chí đánh giá rõ và người chịu trách nhiệm rõ. Không nên thử nghiệm một cách mơ hồ. Ví dụ, nếu muốn giảm thời gian xử lý hồ sơ, cần xác định thử nghiệm tại bộ phận nào, trong bao lâu, đo thời gian ở các công đoạn nào, so sánh với giai đoạn trước ra sao và tiêu chí nào cho thấy giải pháp đủ tốt để nhân rộng.

Thử nghiệm cũng giúp giảm tâm lý phản kháng. Khi nhân viên thấy giải pháp được thử, được lắng nghe và được điều chỉnh theo thực tế, họ có xu hướng tham gia tích cực hơn so với khi giải pháp được áp đặt ngay trên toàn hệ thống.

9. Nguyên tắc 8: Chuẩn hóa ngay sau khi cải tiến có hiệu quả

Một cải tiến thành công nhưng không chuẩn hóa sẽ khó duy trì. Vì vậy, sau khi giải pháp chứng minh hiệu quả, tổ chức cần nhanh chóng chuyển cách làm mới thành chuẩn vận hành. Chuẩn hóa không chỉ là viết lại SOP, mà còn bao gồm cập nhật biểu mẫu, checklist, phần mềm, phân công trách nhiệm, tài liệu đào tạo, chỉ số giám sát và cơ chế đánh giá.

Chuẩn hóa cần đủ cụ thể để người mới có thể thực hiện đúng, người quản lý có thể kiểm tra được và tổ chức có thể đo lường kết quả. Một SOP quá chung chung sẽ không giúp duy trì cải tiến. Một checklist quá dài và không tập trung vào điểm nguy cơ sẽ dễ bị đánh dấu hình thức. Một dashboard có quá nhiều chỉ số sẽ làm người quản lý khó nhận diện bất thường thật sự.

Nguyên tắc là chuẩn hóa những gì quan trọng nhất để duy trì kết quả, không chuẩn hóa quá mức gây nặng nề cho vận hành.

10. Nguyên tắc 9: Đơn giản, dễ dùng và phù hợp với người thực hiện

Công cụ quản lý chất lượng càng gần thực tế vận hành thì càng phải dễ dùng. Nếu công cụ quá phức tạp, biểu mẫu quá dài, thuật ngữ quá khó hoặc yêu cầu quá nhiều bước, người thực hiện sẽ có xu hướng đối phó. Một công cụ tốt không chỉ đúng về lý thuyết, mà còn phải phù hợp với năng lực, thời gian và điều kiện làm việc của người sử dụng.

Ví dụ, một check sheet dùng tại hiện trường cần ngắn gọn, rõ tiêu chí, dễ ghi nhận và không làm gián đoạn công việc. Một dashboard cho lãnh đạo cần tập trung vào chỉ số trọng yếu, xu hướng và cảnh báo, không nên biến thành bảng số liệu quá chi tiết. Một SOP cho nhân viên tuyến đầu cần mô tả hành động cụ thể, tránh văn phong quá hành chính.

Đơn giản không có nghĩa là sơ sài. Đơn giản là loại bỏ phần không cần thiết để công cụ tập trung vào quyết định hoặc hành động quan trọng nhất.

11. Nguyên tắc 10: Đưa công cụ vào nhịp vận hành thường quy

Công cụ quản lý chất lượng không nên chỉ xuất hiện khi có phong trào, dự án hoặc đợt đánh giá. Muốn tạo ra văn hóa chất lượng, công cụ phải được đưa vào nhịp vận hành thường quy của tổ chức.

Điều này có nghĩa là dữ liệu được ghi nhận thường xuyên, chỉ số được xem xét định kỳ, sai lệch được phân tích kịp thời, bảng kiểm được dùng trong công việc thực tế, dashboard được dùng trong cuộc họp điều hành, kết quả cải tiến được cập nhật vào quy trình, và các bài học được chia sẻ giữa các đơn vị.

Khi công cụ trở thành một phần của công việc hằng ngày, quản lý chất lượng không còn là nhiệm vụ tách rời. Nhân viên sẽ hiểu rằng công cụ giúp họ làm việc an toàn hơn, hiệu quả hơn, ít sai sót hơn và phối hợp tốt hơn. Đây là nền tảng để chuyển từ cải tiến theo phong trào sang cải tiến liên tục.

12. Checklist tự đánh giá việc sử dụng công cụ QLCL

Tổ chức có thể sử dụng checklist sau để tự đánh giá nhanh xem công cụ quản lý chất lượng đang được sử dụng hiệu quả hay hình thức:

Câu hỏi tự đánh giáCó/Không
Vấn đề cần giải quyết đã được mô tả rõ trước khi chọn công cụ chưa? 
Công cụ được chọn có phù hợp với giai đoạn cải tiến hiện tại không? 
Dữ liệu đầu vào có định nghĩa rõ và đủ tin cậy không? 
Người trực tiếp thực hiện công việc có tham gia phân tích không? 
Kết quả từ công cụ có dẫn đến quyết định hoặc hành động cụ thể không? 
Giải pháp có tác động vào nguyên nhân gốc hoặc điều kiện hệ thống không? 
Giải pháp có được thử nghiệm hoặc đánh giá trước khi nhân rộng không? 
Kết quả sau cải tiến có được đo lường bằng chỉ số hoặc dữ liệu không? 
Cách làm mới có được chuẩn hóa vào SOP, checklist hoặc quy trình không? 
Công cụ có được đưa vào họp, giám sát hoặc vận hành định kỳ không? 

Nếu nhiều câu trả lời là “Không”, tổ chức cần xem lại cách triển khai công cụ. Vấn đề có thể không nằm ở công cụ, mà ở việc công cụ chưa được gắn với hệ thống cải tiến.

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

Sử dụng công cụ quản lý chất lượng hiệu quả đòi hỏi kỷ luật tư duy và kỷ luật vận hành. Tổ chức cần bắt đầu từ vấn đề thật, chọn công cụ phù hợp, dựa trên dữ liệu đáng tin cậy, phân tích trung thực, hành động vào nguyên nhân gốc, thử nghiệm có kiểm chứng, chuẩn hóa sau cải tiến và duy trì trong hệ thống.

Khi tuân thủ các nguyên tắc này, công cụ quản lý chất lượng sẽ không còn là biểu mẫu hành chính. Nó trở thành phương tiện giúp tổ chức học từ dữ liệu, cải tiến từ thực tế và vận hành ổn định hơn theo thời gian. Đây chính là nền tảng để đi vào các chương tiếp theo, nơi từng nhóm công cụ sẽ được học và áp dụng một cách cụ thể hơn.