ISO thực chiến-Cẩm nang Hướng dẫn thực hiện

ISO thực chiến-Cẩm nang Hướng dẫn thực hiện Contact information, map and directions, contact form, opening hours, services, ratings, photos, videos and announcements from ISO thực chiến-Cẩm nang Hướng dẫn thực hiện, Hồ Chí Minh, Ho Chi Minh City.

Chia sẻ kiến thức và kinh nghiệm thực tiễn về ISO cho doanh nghiệp

"ISO không chỉ là một tiêu chuẩn mà còn là một phong cách sống - Hải Nam ISO"

ĐÀO TẠO CÓ PHẢI LÀ THUỐC CHỮA BÁCH BỆNH KHI CÓ SỰ KHÔNG PHÙ HỢPHồi mới làm ISO, mỗi lần có lỗi xảy ra là mình nghĩ ngay ...
22/06/2026

ĐÀO TẠO CÓ PHẢI LÀ THUỐC CHỮA BÁCH BỆNH KHI CÓ SỰ KHÔNG PHÙ HỢP

Hồi mới làm ISO, mỗi lần có lỗi xảy ra là mình nghĩ ngay tới chuyện đào tạo lại. Điền sai hồ sơ thì đào tạo lại cách điền hồ sơ. Làm sai quy trình thì đào tạo lại SOP. Quên một bước kiểm tra khiến có sự cố thì đào tạo. Nhiều lúc, khách hàng phàn nàn cũng đào tạo.

Kiểu như đào tạo là giải pháp cho mọi vấn đề vậy.
Mình nhớ có lần một bộ phận liên tục ghi thiếu thông tin trên biểu mẫu. Sau vài lần nhắc nhở, đề xuất đưa ra là tổ chức đào tạo lại, thậm chí còn ràng buộc sai là phạt nữa. Nghe cũng hợp lý.
Nhưng khi xuống hiện trường xem thực tế thì mình thấy phần thông tin cần ghi lại nằm ở mặt sau của biểu mẫu. Trong khi hầu hết mọi người chỉ sử dụng mặt trước. Người làm không phải không biết. Họ đã được hướng dẫn rồi. Chỉ là cách thiết kế biểu mẫu đang khiến họ rất dễ bỏ sót.

Nếu lúc đó chỉ đào tạo lại thì có lẽ vài tuần sau lỗi vẫn sẽ quay lại thôi.
Từ đó về sau, mỗi lần nghe tới cụm từ "đào tạo lại", mình thường tự hỏi thêm một câu nữa: “Người ta không biết làm thật. Hay hệ thống đang khiến người ta khó làm đúng?”
Vì hai chuyện đó hoàn toàn khác nhau. Nếu không biết thì phải đào tạo.
Nhưng nếu nguyên nhân nằm ở biểu mẫu, quy trình, công cụ hay cách tổ chức công việc thì đào tạo chỉ đang xử lý phần ngọn.

Mình gặp khá nhiều trường hợp như vậy. Có lỗi được đào tạo đi đào tạo lại rất nhiều lần. Nhưng chỉ cần sửa một biểu mẫu, thay đổi vị trí đặt dụng cụ hoặc đơn giản hóa một bước trong quy trình là vấn đề gần như biến mất.

Sau nhiều năm làm nghề, mình vẫn thấy đào tạo là một hoạt động rất quan trọng. Nhưng mình không còn mặc định rằng cứ có lỗi là phải đào tạo nữa. Vì nhiều khi vấn đề không nằm ở con người. Mà nằm ở cách mình thiết kế hệ thống để con người làm việc trong đó.

Và rất nhiều lần, sửa hệ thống hiệu quả hơn đào tạo lại.

AUDIT LÀ ĐI TÌM SỰ PHÙ HỢPChuyện này mình tin chắc rất nhiều internal auditor đang mắc phải.Có một câu mình gần như luôn...
18/06/2026

AUDIT LÀ ĐI TÌM SỰ PHÙ HỢP
Chuyện này mình tin chắc rất nhiều internal auditor đang mắc phải.

Có một câu mình gần như luôn nói ở đầu mỗi khóa đào tạo đánh giá nội bộ. Không phải cách viết NC, không phải cách đặt câu hỏi, cũng không phải hướng dẫn đọc điều khoản. Mà là: "Audit là đi tìm sự phù hợp”

Nghe đơn giản vậy thôi nhưng đây là thứ ảnh hưởng nhiều nhất tới chất lượng của một cuộc đánh giá. Mình từng tham gia khá nhiều cuộc audit mà không khí rất căng thẳng. Auditor đi tới đâu là mọi người né tới đó. Né đúng nghĩa đen.
Mà nghĩ lại thì cũng dễ hiểu thôi. Nếu trong đầu mình nghĩ audit là đi tìm lỗi thì gần như mọi thứ phía sau sẽ thay đổi theo. Cách đặt câu hỏi khác. Cách lắng nghe khác. Cách nhìn nhận vấn đề cũng khác. Thay vì tìm hiểu người ta đang làm như thế nào thì mình sẽ vô thức tìm xem người ta đang làm sai chỗ nào. Và chắc chắn là người được đánh giá cũng cảm nhận được điều đó.

Sau này khi bắt đầu đào tạo đánh giá viên nội bộ nhiều hơn, mình thường dành khá nhiều thời gian để trao đổi về chuyện này. Câu hỏi thường xuyên dành cả lớp: "Mục đích của audit là gì?" Và gần như lần nào cũng có những câu trả lời rất quen thuộc như tìm lỗi, tìm sai sót hay tìm điểm chưa phù hợp.
Thực ra những câu trả lời đó không sai. Nhưng không hoàn toàn phù hợp.

Sau nhiều năm làm nghề, mình thích cụm từ "đi tìm sự phù hợp" hơn. Mình muốn hiểu quy trình đang vận hành như thế nào. Yêu cầu đã được đáp ứng tới đâu. Điều gì đang làm tốt. Điều gì chưa phù hợp với những gì tổ chức đã cam kết. Nghe có vẻ giống nhau nhưng thực ra khác rất nhiều.

Khi tư duy thay đổi thì câu hỏi cũng thay đổi. Thay vì hỏi: "Chỗ này sai rồi phải không?" thì mình thường hỏi: "Hiện tại mọi người đang thực hiện việc này như thế nào?" “Điều gì khiến mọi người làm khác hơn so với quy trình?”

Chỉ khác vài chữ thôi nhưng cuộc trao đổi cởi mở hơn rất nhiều. Thông tin đầy đủ hơn rất nhiều. Và kết quả đánh giá cũng khách quan hơn rất nhiều.

Có lẽ vì vậy mà sau nhiều năm làm nghề, mình vẫn tin rằng thứ quan trọng nhất của một auditor không phải là khả năng tìm ra lỗi. Mà là khả năng nhìn thấy mức độ phù hợp của hệ thống để giúp tổ chức cải tiến tốt hơn.

Còn lỗi hay điểm chưa phù hợp, đôi khi nó chỉ là kết quả của quá trình đó thôi. 😄

TÔI TỪNG NGHĨ NGƯỜI TA KHÔNG HỢP TÁC. Sau này mới thấy họ không hiểu mình muốn gì.Hồi mới làm ISO, mình hay có một cảm g...
15/06/2026

TÔI TỪNG NGHĨ NGƯỜI TA KHÔNG HỢP TÁC. Sau này mới thấy họ không hiểu mình muốn gì.

Hồi mới làm ISO, mình hay có một cảm giác khá khó chịu: đã giải thích, đã gửi email rồi, thậm chí là đã họp rồi. Tất nhiên, còn nhắc lại vài lần. Vậy mà tới lúc cần làm thì mọi thứ vẫn không như mong đợi. Lúc đó trong đầu mình thường xuất hiện một suy nghĩ rất nhanh: "Chắc họ không hợp tác."

Có lần mình yêu cầu một bộ phận bổ sung hồ sơ. Trong đầu mình lúc đó hình dung rất rõ phải bổ sung cái gì, làm như thế nào và tại sao phải làm. Nhưng vài ngày sau nhận lại kết quả thì gần như không đúng ý. Mình lại đi giải thích thêm. Rồi lại sửa tiếp. Rồi lại trao đổi tiếp. Cho tới một lúc mình ngồi xuống nói chuyện kỹ hơn với người thực hiện thì mới phát hiện ra một sự thật. Thứ mà nghĩ là đã nói rõ, thực ra chỉ rõ trong đầu mình thôi. Mình hiểu mục đích của việc đó, rủi ro nếu không làm. Mình hiểu mình đang muốn đạt được điều gì.
Nhưng người thực hiện thì không có tất cả những thông tin đó. Họ chỉ nhận được một yêu cầu. Và họ cố hoàn thành yêu cầu theo cách họ hiểu.

Từ đó mình bắt đầu thay đổi một chút. Mỗi lần cần triển khai việc gì đó, mình ít nói về việc phải làm gì hơn. Mà cố gắng nói nhiều hơn về lý do tại sao phải làm.
Và nhận ra khi người ta hiểu mục đích thì thường không cần nhắc quá nhiều về cách làm.
Ngược lại, nếu chỉ nhận được yêu cầu mà không hiểu bức tranh phía sau thì rất khó để mọi người làm đúng như kỳ vọng.
Sau này đi đào tạo hay triển khai hệ thống, câu chuyện đó xảy ra rất nhiều lần.

Và mỗi lần chuẩn bị nghĩ rằng ai đó không hợp tác, mình thường tự hỏi lại trước: Liệu họ đang chống đối mình hay đơn giản là họ chưa hiểu mình đang muốn gì?

Và tất nhiên, câu trả lời luôn là vế 2.

NGƯỜI MỚI HỌC TỪ NGƯỜI CŨ. VẤN ĐỀ LÀ NGƯỜI CŨ ĐANG DẠY GÌ?Nhân viên mới đi làm thì có gì không biết thường sẽ nhìn người...
10/06/2026

NGƯỜI MỚI HỌC TỪ NGƯỜI CŨ. VẤN ĐỀ LÀ NGƯỜI CŨ ĐANG DẠY GÌ?

Nhân viên mới đi làm thì có gì không biết thường sẽ nhìn người bên cạnh làm rồi làm theo. Không hiểu thì hỏi. Sai thì sửa. Dần dần mới quen việc.

Mà nghĩ lại thì đó cũng là cách học nhanh nhất.
Vấn đề chỉ bắt đầu xuất hiện khi hỏi thêm những người khác.
Người này hướng dẫn một kiểu. Người kia hướng dẫn một kiểu. Thậm chí cùng một công việc nhưng mỗi người lại có một cách giải thích khác nhau.

Có lần mình gặp một bộ phận mà ba người cùng hướng dẫn người mới. Cả ba đều rất có kinh nghiệm. Chỉ có điều ba người đó đang làm theo ba cách hơi khác nhau.
Không ai sai cả. Nhưng người mới thì hoang mang. Hỏi anh A thì được câu trả lời này. Hỏi chị B thì lại được hướng dẫn khác. Xong quay qua hỏi anh C thì lại có thêm một phiên bản nữa.

Lúc đó mình mới thấy người mới học rất nhanh từ người cũ. Nhưng người mới cũng nhìn thấy rất nhanh những khác biệt, những thói quen và cả những đường tắt mà người cũ đang sử dụng mỗi ngày.
Sau đó mình ngồi lại với cả nhóm. Không phải để tìm ai đúng ai sai. Mà để cùng nhau trả lời một câu hỏi đơn giản hơn:
"Nếu ngày mai có một người mới vào, chúng ta muốn họ làm được điều gì, đạt được năng lực gì, bằng cách nào?"

Từ câu hỏi đó, mọi người bắt đầu trao đổi với nhau nhiều hơn. Có những cách làm được giữ lại. Có những cách làm được tinh gọn. Có những điểm trước giờ ai cũng nghĩ là giống nhau nhưng thực ra lại hiểu khác nhau.

Và hệ quả tất yếu sau khi thống nhất được cách hướng dẫn, người mới học nhanh hơn hẳn. Mọi người cũng đỡ mất thời gian giải thích lại cùng một câu hỏi nhiều lần.

Lúc đó mình mới thấy quy trình chưa chắc là thứ tạo ra sự thống nhất.
Sự thống nhất bắt đầu từ việc những người có kinh nghiệm ngồi lại với nhau và thống nhất xem mình đang muốn truyền lại điều gì cho người đi sau.
Nghe đơn giản vậy thôi nhưng mình thấy đây là một trong những cách giữ tri thức của tổ chức hiệu quả nhất.

KINH NGHIỆM LÀ THỨ DỄ MẤT NHẤT TRONG CÔNG TY?Mình từng gặp một công ty mà anh tổ trưởng sản xuất nghỉ việc sau gần 10 nă...
09/06/2026

KINH NGHIỆM LÀ THỨ DỄ MẤT NHẤT TRONG CÔNG TY?

Mình từng gặp một công ty mà anh tổ trưởng sản xuất nghỉ việc sau gần 10 năm gắn bó. Nghe thì cũng bình thường thôi. Người nghỉ việc là chuyện công ty nào cũng gặp. Nhưng chỉ vài tuần sau, mọi người mới bắt đầu thấy vấn đề. Có những lỗi trước đây anh ấy nhìn qua là biết nguyên nhân. Có những sự cố máy móc anh ấy xử lý rất nhanh. Có những khách hàng, những sản phẩm, những tình huống đặc biệt mà gần như chỉ mình anh ấy nhớ.
Lúc anh ấy còn ở đó, mọi thứ diễn ra quá tự nhiên nên không ai để ý. Tới khi anh ấy nghỉ rồi mới phát hiện ra nhiều kiến thức chưa từng được ghi lại ở đâu cả.
Thế là dù đã nghỉ, anh ấy vẫn phải hỗ trợ khá nhiều cho đồng nghiệp cũ.

Mình gặp chuyện này khá nhiều khi đi đánh giá hoặc làm việc với các doanh nghiệp. Có những công ty đầu tư rất nhiều vào máy móc. Có những công ty đầu tư rất nhiều vào nhà xưởng. Nhưng lại vô tình để phần tài sản quý nhất nằm hết trong đầu một vài người.
Mà cái khó là kiến thức nằm trong đầu người khác thì mình không thật sự sở hữu nó.

Ngày trước mình cứ nghĩ quy trình, hướng dẫn hay đào tạo chủ yếu để phục vụ vận hành hoặc phục vụ audit. Sau này làm nhiều hơn mới thấy một giá trị khác của nó. Đó là giữ lại những gì tổ chức đã học được sau rất nhiều năm va vấp, thử sai và tích lũy kinh nghiệm.

Có những bài học phải trả bằng rất nhiều thời gian. Có những kinh nghiệm phải xử lý hàng chục lần mới đúc kết được. Nếu không tìm cách giữ lại thì tới một ngày nào đó, tất cả lại quay về điểm xuất phát.

Có lẽ vì vậy mà bây giờ mỗi khi gặp một người rất giỏi trong công ty, mình thường nghĩ tới một câu hỏi: Nếu ngày mai người này nghỉ phép một tháng thì điều gì sẽ xảy ra?

Nghe đơn giản vậy thôi nhưng nhiều khi câu trả lời lại cho mình thấy khá nhiều thứ về cách tổ chức đó đang vận hành.

Theo mọi người, chia sẻ này là điều khoản nào trong tiêu chuẩn ISO 9001?

LÀM HỆ THỐNG, BẠN QUEN NHÌN ĐIỀU GÌ TRƯỚC?Có một điều mình nhận ra khá muộn.Người ta thường rất dễ nhìn thấy vấn đề. Như...
04/06/2026

LÀM HỆ THỐNG, BẠN QUEN NHÌN ĐIỀU GÌ TRƯỚC?

Có một điều mình nhận ra khá muộn.
Người ta thường rất dễ nhìn thấy vấn đề. Nhưng lại ít khi nhìn thấy giá trị của những thứ đang vận hành tốt.
Máy hỏng một lần là cả công ty biết. Khách hàng phàn nàn một lần là họp liên tục. Sai lỗi xảy ra là CAPA, là điều tra nguyên nhân, là hành động khắc phục.
Nhưng có những thứ chạy ổn suốt nhiều tháng, nhiều năm thì gần như chẳng ai nhắc tới.

Mình từng đi đánh giá ở một công ty. Trong buổi họp, mọi người đang tập trung bàn về các vấn đề tồn đọng. Cũng đúng thôi, vì vấn đề cần được giải quyết.
Nhưng lúc đó mình để ý có một quy trình đã vận hành rất ổn trong thời gian dài. Không có khiếu nại. Không có sai lỗi đáng kể. Không có sự cố lớn.
Mà càng không có sự cố thì càng ít người nhớ tới nó.

Và kiểu trong cuộc sống cũng vậy: Mình thường chỉ chú ý tới thứ đang trục trặc. Còn những thứ đang âm thầm vận hành tốt thì mặc định xem đó là điều hiển nhiên.
Sau này làm hệ thống nhiều hơn, mình bắt đầu tập một thói quen khác. Ngoài việc tìm vấn đề để cải tiến, mình cũng cố gắng nhìn xem điều gì đang làm tốt để giữ lại.

Vì đôi khi giá trị của một hệ thống không nằm ở những gì nó sửa được.
Mà nằm ở những sự cố đã không xảy ra.

NGƯỜI ĐÓNG GÓI QUY TRÌNHThầy của mình kể rất nhiều về mô hình doanh nghiệp "Trách nhiệm hữu hạn một mình tui – Mình tui ...
31/05/2026

NGƯỜI ĐÓNG GÓI QUY TRÌNH

Thầy của mình kể rất nhiều về mô hình doanh nghiệp "Trách nhiệm hữu hạn một mình tui – Mình tui cân hết”.
Không phải là câu chuyện, mà kiểu như là thực trạng.

Mình cũng gặp khá nhiều công ty như vậy. Khách gọi thì sếp biết. Báo giá thì sếp duyệt. Mua hàng thì sếp quyết. Có vấn đề phát sinh thì sếp xử. Nhân viên cần hỏi gì cũng tìm sếp.
Ở công ty lớn hơn thì trưởng bộ phận, trưởng phòng biết hết, đôi lúc làm hết.
Nhìn thì có vẻ người đó giỏi thật. Việc gì cũng biết. Chuyện gì cũng xử được. Nhưng rồi tới lúc người đó bận, đi công tác hoặc nghỉ phép vài hôm thì mọi người bắt đầu đứng hình.

Hồi trước, mình có một anh quản lý mà mình rất nể. Anh ấy làm được gần như mọi thứ. Đi tới đâu cũng thấy người ta hỏi. Mà càng hỏi nhiều thì anh ấy càng bận. Càng bận thì mọi người càng phải chờ. Cuối cùng người giỏi nhất lại trở thành chỗ nghẽn lớn nhất của cả hệ thống.
Lúc đó mình mới thấy có những thứ ban đầu là điểm mạnh, nhưng nếu kéo dài quá lâu lại trở thành rủi ro.

Sau này làm hệ thống nhiều hơn, mình bắt đầu nhìn khác đi một chút. Ai chả thích những người giỏi. Nhưng mình còn thích những người giúp người khác làm được việc hơn. Những người biến kinh nghiệm trong đầu mình thành cách làm chung cho cả đội. Những người nghỉ phép mà công việc vẫn chạy bình thường.
Mình tự định nghĩa đó là những người “ĐI ĐÓNG GÓI QUY TRÌNH”

Mình thích nên mình toàn tìm cách đóng gói mọi thứ, mọi hướng dẫn, mọi câu trả lời của mình đều cố gắng quy thành từng bước 1, bước 2...
Lúc đầu nó khô khan, nó cứng ngắc nhưng làm đủ nhiều thì dần logic hơn, dần dễ hiểu hơn. Và mình hoàn toàn tự tin để biến những thứ khó nhằn, khó hiểu thành những thứ cơ bản, dễ hiểu tùy theo mức độ nhận thức của người tiếp nhận.

Sau này mình mới thấy, thứ giá trị nhất mình để lại đôi khi không phải là một quy trình hay một biểu mẫu nào cả. Mà là khi người khác có thể tiếp tục làm tốt công việc đó kể cả khi mình không còn ở đó nữa. Có lẽ đó cũng là lý do mình vẫn thích đi "đóng gói quy trình".

QUY TRÌNH NÀY SINH RA ĐỂ LÀM GÌ?Có một câu hỏi mình rất hay hỏi trong các buổi đào tạo hoặc đánh giá:“Quy trình này sinh...
29/05/2026

QUY TRÌNH NÀY SINH RA ĐỂ LÀM GÌ?

Có một câu hỏi mình rất hay hỏi trong các buổi đào tạo hoặc đánh giá:
“Quy trình này sinh ra để làm gì vậy?”

Nghe đơn giản vậy thôi mà nhiều khi cả phòng ngồi nhìn nhau.

Có những quy trình, những hướng dẫn công việc, những cuốn sổ tay được làm rất đẹp. Trình bày chỉn chu. Có lịch sử sửa đổi. Có phê duyệt đầy đủ. Audit hỏi là lấy ra được ngay.

Nhưng khi hỏi tiếp:
“Quy trình này đang giúp kiểm soát rủi ro gì?”
“Đang giải quyết vấn đề gì?”
“Người nào đang thật sự sử dụng nó?”

Thì bắt đầu không dễ trả lời nữa.

Mà cũng không trách được.
Nhiều tài liệu được sinh ra từ một nhu cầu rất thật. Có thể ngày đó từng xảy ra sai lỗi. Có thể từng có khách hàng phàn nàn. Có thể từng có một sự cố nào đó nên công ty phải xây dựng thêm một quy trình để kiểm soát.

Rồi thời gian trôi qua. Người tạo ra quy trình nghỉ việc. Người quản lý thay đổi. Vấn đề ngày xưa không còn nữa.
Nhưng quy trình thì vẫn ở đó.

Mọi người vẫn ký nhận đào tạo.
Vẫn lưu trong danh mục tài liệu.
Vẫn mang ra khi audit.

Chỉ có điều không còn ai nhớ nó được sinh ra vì điều gì và đang phục vụ cho ai nữa. 😄

Mình gặp chuyện này khá nhiều, hầu như những hệ thống quản lý mình từng gặp, đào tạo, audit đều tồn tại những “đứa con rơi” này.

Và phần lớn mọi người đều nghĩ vấn đề nằm ở chuyện cập nhật tài liệu.
Nhưng mình lại nghĩ vấn đề nằm ở chỗ khác.
Đó là hệ thống đã quên mất lý do tồn tại của chính nó.

Một quy trình được sinh ra để phục vụ vận hành. Một biểu mẫu được sinh ra để kiểm soát rủi ro. Một hướng dẫn công việc được sinh ra để giúp ai đó làm đúng ngay từ đầu.

Nếu một ngày nào đó nó không còn phục vụ được những việc đó nữa thì có lẽ điều cần xem xét không phải là chỉnh lại font chữ hay sửa lại phiên bản hay review nội dung.

Mà là ngồi lại hỏi:
“Nó thực sự còn cần thiết không?”

Nghe thì đơn giản vậy thôi chứ mình thấy đây là một trong những câu hỏi khó nhất khi làm hệ thống.

Nhìn xa hơn, có câu hỏi lớn hơn: “Thứ mình đang duy trì hôm nay có còn tạo ra giá trị như ngày nó được sinh ra không?”

ĐẶT MÃ SỐ TÀI LIỆU.Hồi trước mình khá thích đặt mã tài liệu kiểu thật đầy đủ. Ví dụ: QT-HCNS-TD-01.01, biểu mẫu đi kèm s...
28/05/2026

ĐẶT MÃ SỐ TÀI LIỆU.

Hồi trước mình khá thích đặt mã tài liệu kiểu thật đầy đủ.
Ví dụ: QT-HCNS-TD-01.01, biểu mẫu đi kèm sẽ là QT-HCNS-TD-01-BM-01.01. Nhìn vô thấy rất yên tâm, kiểu có logic, có phân cấp, có nhận diện, nhìn rất “hệ thống”.

Mà sau này lúc training cho nhân viên mới hoặc lúc ngồi cùng mấy bạn vận hành, mình mới để ý có một chuyện khá thú vị. Mỗi lần cần tìm biểu mẫu hay quy trình gì đó là mọi người bắt đầu mở folder, dò từng dòng, hỏi nhau hoặc copy đại file cũ ra xài tiếp.

Có lần mình hỏi một bạn:
“Em nhớ mã biểu mẫu đó không?”
Bạn ấy trả lời rất thật:
“Dạ em nhớ mang máng là BM gì đó dài lắm anh.” 😄

Lúc đó mình mới thấy nhiều khi người làm hệ thống với người trực tiếp sử dụng hệ thống đang nhìn mọi thứ rất khác nhau.
Mình thì muốn hệ thống thật chặt, thật logic. Còn người sử dụng chỉ cần: dễ nhớ, dễ tìm, dễ hiểu.

Sau đó mình bắt đầu thử đổi cách đặt mã. Ví dụ: QT-HCNS-TD-01 đổi thành QT-NS-01. Biểu mẫu QT-HCNS-TD-01-BM-01.01 đổi thành QT-NS-01-01.
Thì ngon lành hơn, người mới đỡ ngợp hơn, training cũng nhanh hơn, folder nhìn cũng dễ thở hơn mà vận hành thực tế thì chả ảnh hưởng gì nhiều.

Hồi trước mình cứ nghĩ hệ thống càng chi tiết thì càng chuyên nghiệp. Sau này mới thấy nhiều khi chuyên nghiệp thật sự là làm sao để người khác dùng được một cách tự nhiên nhất. Chứ không phải làm cho hệ thống nhìn phức tạp hơn.

Nhiều khi cải tiến không phải là làm thêm cái gì lớn lắm. Chỉ là làm cho những thứ đang có trở nên đơn giản hơn một chút, dễ sống hơn một chút thôi.

Address

Hồ Chí Minh
Ho Chi Minh City

Alerts

Be the first to know and let us send you an email when ISO thực chiến-Cẩm nang Hướng dẫn thực hiện posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Share