Ứng dụng nhật ký sự cố an toàn nơi làm việc để báo cáo nhanh

Tại sao việc ghi nhật ký sự cố thất bại ở nơi làm việc thực tế

Ghi nhật ký sự cố thường thất bại vì những lý do đơn giản: công cụ chậm, lúc đó mọi người căng thẳng, và họ còn việc thực sự cần làm.

Sổ tay giấy và bảng tính tạo thêm ma sát. Mẫu không ở ngay chỗ xảy ra sự cố, chữ viết tay khó đọc, và “tôi sẽ nhập sau” biến thành “tôi sẽ cố nhớ vào ngày mai.” Ngay cả khi ai đó nhập, bản ghi thường nằm trong một tệp chia sẻ mà chỉ một người có thể chỉnh sửa cùng lúc.

Tổn thất lớn nhất xảy ra khi chi tiết được ghi lại muộn. Ước lượng thời gian dịch chuyển, vị trí chính xác trở nên mơ hồ, và những chi tiết nhỏ nhưng quan trọng biến mất: ai ở gần đó, PPE nào được sử dụng, sàn trông như thế nào. Ảnh làm bằng chứng là ví dụ kinh điển. Khi ai đó quay lại với điện thoại thì vết tràn đã được dọn, tấm bảo vệ đã được thay, hoặc thùng hỏng đã vào thùng rác.

Trì hoãn cũng làm ảnh hưởng đến việc thực thi. Nếu giám sát xem báo cáo sau vài ngày, hành động khắc phục khởi động muộn, người chịu trách nhiệm không rõ, và cùng nguy cơ có thể làm ai đó bị thương lần nữa. Một "gần-sự-cố" nhỏ có thể đã sửa nhanh bằng rào chắn hoặc nhắc nhở nhưng nếu để trễ sẽ lặp lại và giờ bạn phải quản lý chấn thương, thời gian chết và những cuộc nói chuyện khó khăn.

Một ứng dụng nhật ký sự cố an toàn tốt loại bỏ lý do biện minh bằng cách khiến hành động đúng trở nên dễ thực hiện ngay lúc xảy ra. Ít nhất, nó cần thu được:

• Chuyện gì đã xảy ra, khi nào và chính xác ở đâu
• Ai tham gia và ai chứng kiến
• Các bước ngay lập tức đã thực hiện
• Ảnh rõ ràng và ghi chú ngắn khi hiện trường còn mới
• Người chịu trách nhiệm theo dõi và hạn chót để không có gì bị bỏ quên

Ví dụ: một công nhân kho vấp phải tấm pallet lỏng. Nếu báo cáo được ghi ngay với hai ảnh, tên lối đi chính xác, và một hành động theo dõi được giao cho bộ phận bảo trì, việc sửa chữa có thể hoàn tất trước ca tiếp theo. Nếu chờ đến cuối tuần, bạn phụ thuộc vào ký ức và hy vọng không ai khác vấp trước.

Nếu bạn xây quy trình riêng, AppMaster có thể là lựa chọn thực tế để tạo biểu mẫu báo cáo di động đơn giản, thêm tải ảnh và điều phối theo dõi mà không biến việc báo cáo thành giấy tờ rườm rà.

Những gì bạn nên ghi (và không nên)

Nếu mọi người không chắc chắn cái gì “được tính,” họ sẽ ngừng báo cáo. Ứng dụng nhật ký sự cố an toàn hoạt động tốt nhất khi danh mục rõ ràng và nhất quán, để ai cũng ghi cùng loại sự kiện.

Ba nhóm bao phủ phần lớn nơi làm việc:

• Incident: Có người bị thương, thiết bị hỏng hoặc công việc bị dừng.
• Near-miss: Không ai bị hại, nhưng có thể đã xảy ra.
• Hazard observation: Một điều kiện không an toàn cần chú ý, dù chưa xảy ra sự kiện cụ thể.

Giữ cách diễn đạt đơn giản. “Incident” là kết quả (thương tích, thiệt hại, mất thời gian). “Near-miss” là gần như xảy ra. “Hazard” là tình huống rủi ro.

Cũng tách việc báo cáo và đánh giá. Hầu hết báo cáo đến từ những người gần công việc nhất (nhân viên vận hành, kho, kỹ thuật hiện trường, giám sát). Đánh giá thường do quản lý, người phụ trách EHS/an toàn hoặc HR, họ có thể thêm phân loại, mức độ nghiêm trọng và ghi chú cuối cùng sau.

Nếu muốn tăng tỉ lệ báo cáo, giữ bước đầu nhẹ: chuyện gì, ở đâu, khi nào, và cần làm gì để an toàn ngay bây giờ. Lưu phân tích (nguyên nhân gốc, nhu cầu đào tạo, cập nhật chính sách) cho giai đoạn rà soát.

Một quy tắc thực tế: ghi bất cứ điều gì bạn muốn nhớ trong buổi rà soát an toàn hàng tháng. Thường bao gồm chấn thương, sơ cứu, hư hại tài sản, tràn (kể cả nhỏ), near-miss nghiêm trọng, nguy cơ lặp lại, và bất kỳ sự kiện nào khiến phải dừng công việc hoặc khách hàng phàn nàn.

Không nên ghi: tranh chấp cá nhân không liên quan an toàn, ghi chú mơ hồ kiểu “ngày tệ” không có vị trí hay thời gian, và báo cáo dựa trên tin đồn. Nếu không thể hành động, nó nên được bàn trong cuộc trò chuyện chứ không phải vào nhật ký.

Ví dụ: một pallet nghiêng nhưng không rơi. Ghi là near-miss, không ghi “không có gì.” Người đánh giá sau này có thể liên kết với hành động như kiểm tra chất lượng quấn pallet hoặc đào tạo lại xếp chồng.

Các trường tối thiểu để hồ sơ hữu ích sau này

Một ứng dụng sự cố hữu ích phụ thuộc vào chi tiết mọi người ghi được khi chịu áp lực. Quá nhiều trường làm chậm báo cáo. Quá ít khiến mỗi lần rà soát phải suy đoán.

Bắt đầu với vài trường trả lời ba câu hỏi sau: chuyện gì đã xảy ra, xảy ra ở đâu và khi nào, và chúng ta đã làm gì ngay lập tức.

Bộ trường “đủ chi tiết”

Các trường này giữ hồ sơ dùng được để phân tích xu hướng và theo dõi mà không biến báo cáo thành giấy tờ:

• Khi và ở đâu: ngày, giờ và vị trí chính xác (tòa nhà, tầng, dây chuyền, khoang, phòng).
• Ai: người bị ảnh hưởng cộng vai trò/đội, và bất kỳ nhân chứng nào (tên hoặc mã số nhân viên).
• Chuyện gì đã xảy ra: mô tả ngắn, thực tế.
• Hành động ngay lập tức: sơ cứu, phong tỏa khu vực, ngắt thiết bị, báo giám sát.
• Mức độ nghiêm trọng và rủi ro: thang đơn giản để sắp xếp ưu tiên.

Giữ ô “chuyện gì” ngắn và thực tế. “Sàn ướt gần Cổng 2, nhân viên trượt khi mang thùng” hữu ích. “Hành vi bất cẩn” thì không. Ý kiến và đổ lỗi có thể xử lý sau.

Thang đánh giá đơn giản mà mọi người sẽ dùng

Một thang nhỏ tốt hơn ma trận phức tạp khi cần dữ liệu nhất quán.

Ví dụ:

• Mức độ (1 đến 4): 1 (near-miss), 2 (sơ cứu), 3 (điều trị y tế), 4 (mất thời gian làm việc)
• Rủi ro (Thấp/Trung bình/Cao): dựa trên điều gì có thể xảy ra nếu điều kiện khác một chút

Làm ảnh thành bằng chứng tiêu chuẩn cho sự cố. Một bức ảnh nhanh về khu vực, điều kiện (tràn, bảo vệ hỏng, lối thoát bị chặn), và biển báo liên quan thường trả lời những câu hỏi mà gọi điện nhiều lần mới xong.

Ví dụ: một nhân viên báo near-miss với xe nâng lúc 9:10 sáng ở Lối đi 7. Họ thêm một ảnh cho thấy góc khuất, ghi “đã thêm người dẫn ngay lập tức,” chọn mức độ 1 và rủi ro Cao. Hai tuần sau, ảnh và số lối đi chính xác giúp xác nhận xu hướng và biện minh cho thay đổi.

Các bước: ghi một sự cố trong vài phút

Tốc độ quan trọng vì chi tiết phai rất nhanh. Mục tiêu là một hồ sơ sạch có thể tin tưởng sau này, mà không khiến người ở hiện trường cảm thấy đang làm giấy tờ.

Bắt đầu với đường dẫn nhanh nhất: mở nhật ký trên điện thoại và chạm “Sự cố mới.” Nếu mất quá nhiều thao tác để tới biểu mẫu trống, người ta sẽ trì hoãn và quên chi tiết.

Giữ các lựa chọn đầu tiên đơn giản: chọn loại sự cố và vị trí từ danh sách ngắn, quen thuộc. Danh sách ngắn giảm lỗi gõ và giúp tìm kiếm, báo cáo dễ dàng hơn sau này.

Rồi ghi câu chuyện bằng ngôn ngữ đơn giản. Hai đến ba câu thường đủ: chuyện gì đã xảy ra, điều gì diễn ra trước đó, và bạn đã làm gì ngay sau. Thêm ảnh ngay, trước khi hiện trường thay đổi. Ảnh rộng của hiện trường và vị trí thiết bị thường hữu ích hơn ảnh cận quá mức.

Quy trình báo cáo trên điện thoại thân thiện:

• Chọn loại và vị trí
• Thêm mô tả nhanh (2–3 câu)
• Đính kèm 1–3 ảnh (thêm chú thích ngắn nếu cần)
• Gửi để tự động chuyển đến người kiểm duyệt phù hợp
• Lưu nháp nếu mất sóng, rồi gửi khi có mạng

Nháp quan trọng ở tầng hầm, kho và ngoài trời. Ứng dụng tốt cho phép bạn ghi lại trước rồi đồng bộ sau.

Ví dụ: một near-miss với xe nâng. Người điều khiển ghi trong dưới hai phút, thêm hai ảnh lối đi và hàng, rồi gửi. Người phụ trách an toàn nhận thông báo tự động, rà soát và quyết định cần theo dõi hay điều tra đầy đủ.

Nếu bạn xây luồng này trong AppMaster, hãy hướng tới biểu mẫu di động một màn hình với tải ảnh và thông báo người kiểm duyệt tự động khi nộp.

Giao việc theo dõi và giữ hành động khắc phục tiếp tục

Ứng dụng nhật ký chỉ hữu ích khi chuyển báo cáo thành hành động. Ngay khi báo cáo được ghi, nắm bắt bước tiếp theo khi chi tiết còn tươi và người liên quan vẫn có mặt.

Bắt đầu bằng giao một chủ sở hữu duy nhất cho mỗi hành động theo dõi. “Đội” thường có nghĩa là không có chủ sở hữu. Chọn một người sẽ phối hợp công việc, dù có người khác giúp.

Để theo dõi hành động rõ ràng, mỗi việc nên trả lời ba câu:

• Ai là người chịu trách nhiệm?
• Khi nào đến hạn?
• “Xong” trông như thế nào?

Hạn chót quan trọng, nhưng kết quả mong đợi còn quan trọng hơn. “Sửa kệ” chung chung. “Lắp lan can ở mép kệ thấp và xác nhận nó vượt qua bài kiểm tra đẩy” là điều giám sát có thể kiểm tra được.

Khi công việc hoàn tất, yêu cầu bằng chứng chứ không phải lời hứa. Ghi chú ngắn cộng ảnh khu vực sau khi sửa (hoặc biển báo mới, PPE thay thế, bộ dụng cụ tràn được dọn) giúp rà soát sau này dễ dàng. Điều này cũng hữu ích khi nhân sự thay đổi hoặc vấn đề lặp lại.

Các mục quá hạn cần quy tắc leo thang đơn giản. Ví dụ: nếu hành động không hoàn thành đến hạn, tự động thông báo giám sát ca tiếp theo. Giữ leo thang có tính sự thật và nhất quán để không gây cảm giác cá nhân.

Đóng sự cố chỉ sau khi các hành động được xác minh. Một luồng xác minh đơn giản thường đủ:

• Chủ sở hữu đánh dấu hoàn thành kèm ghi chú và ảnh
• Giám sát xác nhận kết quả (hoặc yêu cầu làm lại)

Ví dụ: một trượt gần kho hàng dẫn đến hai hành động: “Thay thảm rách” (chủ: cơ sở, hạn chót Thứ Sáu, yêu cầu ảnh) và “Thêm biển báo trơn ở cửa kho” (chủ: trưởng ca, hạn hôm nay). Sự cố chỉ đóng khi cả hai được kiểm tra.

Nếu bạn xây trong AppMaster, bạn có thể làm bước “Đóng sự cố” chỉ khả dụng sau khi tất cả theo dõi được xác minh, để không có gì bị chôn vùi.

Quyền truy cập và quyền riêng tư để tránh tình huống khó xử

Ứng dụng cần quy tắc truy cập rõ ràng. Nếu không, người ta ngừng báo cáo vì lo rằng ghi chú, ảnh hay tên sẽ rơi vào inbox không phù hợp.

Bắt đầu với vai trò phù hợp cách công việc diễn ra:

• Reporter: tạo báo cáo, đính kèm ảnh và xem các báo cáo của mình
• Reviewer: kiểm tra tính đầy đủ, hỏi thêm, và điều hướng đến người chịu trách nhiệm
• Manager: giao hành động, đặt hạn chót và đóng sự cố
• Admin: quản lý cài đặt, trường và quyền (không quyết định hàng ngày)

Tiếp theo, tách thông tin theo mục đích: điều gì đội cần để an toàn so với điều gì nên giới hạn cho nhóm nhỏ.

Ghi chú chia sẻ vs ghi chú riêng tư

Ghi chú chia sẻ cho các sự kiện giúp tránh lặp lại: chuyện gì đã xảy ra, nơi nào, biện pháp tạm thời và kế hoạch khắc phục. Ghi chú riêng tư cho bối cảnh nhạy cảm như thông tin y tế, quan ngại về HR, hoặc thông tin liên hệ nhân chứng.

Mặc định thực tế:

• Đưa thông tin y tế và định danh cá nhân vào ghi chú riêng tư
• Giữ ghi chú chia sẻ tập trung vào nguy cơ, biện pháp kiểm soát và bước tiếp theo
• Hạn chế hiển thị ảnh khi có khuôn mặt, thẻ hoặc màn hình
• Cho phép báo cáo ẩn danh khi văn hóa vẫn cần cải thiện

Xử lý chỉnh sửa mà không thay đổi im lặng

Không gì tạo ra mất tin tưởng nhanh hơn một hồ sơ bị thay đổi lặng lẽ sau thực tế. Dùng bước phê duyệt cho chỉnh sửa các trường quan trọng (mức độ thương tích, nguyên nhân gốc, trạng thái hành động). Tốt hơn nữa là giữ nhật ký thay đổi cho biết ai đã sửa gì và khi nào.

Nếu bạn xây nhật ký với AppMaster, bạn có thể mô hình vai trò, kiểm soát truy cập trường, và thêm luồng rà soát để cập nhật có thể thấy, có chủ ý và dễ giải thích khi rà soát.

Lịch sử có thể tìm kiếm hỗ trợ rà soát và kiểm toán

Nhật ký chỉ hữu ích khi lịch sử có thể tra cứu. Khi giám sát cần trả lời “Việc này xảy ra bao lần?” hoặc kiểm toán yêu cầu bằng chứng theo dõi, bạn muốn câu trả lời trong vài giây chứ không phải đi tìm thủ công qua tin nhắn và giấy tờ.

Ứng dụng nên giúp hồ sơ an toàn có thể tìm kiếm theo cách đội thực sự rà soát công việc:

• Khoảng thời gian (tuần này, quý trước, từ đầu năm)
• Site hoặc khu vực (kho, bến xếp, tầng 2)
• Đội hoặc ca (đội A, ca đêm)
• Loại sự cố (near-miss, sơ cứu, hư hại tài sản)
• Trạng thái (mở, đang tiến hành, đóng)

Tag hữu ích nhưng chỉ khi giữ nhất quán. “Forklift” và “fork lift” biến tìm kiếm thành đoán mò. Dùng bộ tag được phê duyệt nhỏ và ưu tiên danh sách chọn thay vì gõ tự do.

Tìm kiếm cũng là cách phát hiện vấn đề lặp lại. Nếu bạn có thể lọc theo vị trí và thiết bị, các mô hình hiện ra nhanh: ba vụ trượt gần cùng cống, hoặc nhiều báo cáo điểm kẹp ở cùng máy ép. Xu hướng đó thường chỉ ra cách sửa thật sự.

Cho rà soát và kiểm toán, dòng thời gian quan trọng như kết quả cuối cùng. Mỗi hồ sơ nên cho thấy rõ ai thay đổi mức độ, ai giao theo dõi, quyết định nào được đưa ra và khi nào bằng chứng được thêm.

Sai lầm phổ biến khiến ứng dụng thất bại

Hầu hết công cụ thất bại vì làm “việc đúng” khó hơn lối tắt. Ứng dụng an toàn nên cảm thấy nhanh hơn gửi tin nhắn, đồng thời vẫn tạo hồ sơ tin cậy.

Một bẫy phổ biến là biến biểu mẫu thành một cuộc điều tra nhỏ. Nếu người dùng phải điền nhiều trường bắt buộc, họ bỏ cuộc hoặc gõ nội dung nhạt như “N/A” để nộp. Thu thập một lõi nhỏ, đáng tin cậy ngay bây giờ, rồi cho phép thêm chi tiết sau.

Vấn đề khác là phân loại lộn xộn. Nếu để người ta gõ tên loại sự cố ("slip", "slipped", "near slip", "almost fell"), báo cáo khó tổng hợp và kiểm toán. Dùng một tập chọn ngắn, rồi một ô ghi chú cho ngữ cảnh.

Hành động khắc phục thường chết yểu vì không ai chịu trách nhiệm. Nếu không có người được giao và hạn chót, đó không phải là nhiệm vụ. Hiển thị người chịu trách nhiệm, đặt nhắc và cho thấy mục quá hạn.

Mô hình thất bại lặp lại:

• Quá nhiều chi tiết bắt buộc ban đầu
• Danh mục văn bản mở làm vỡ xu hướng và dashboard
• Hành động không có người chịu trách nhiệm hoặc hạn chót
• Ảnh giữ trên điện thoại cá nhân thay vì trong hồ sơ
• Chỉnh sửa ghi đè lịch sử

Ví dụ: ai đó chụp ảnh bậc thang gãy và nhắn cho giám sát. Ảnh không vào hồ sơ, sửa chưa được giao, và hai tuần sau không ai chứng minh được đã thấy hay đã làm gì.

Nếu bạn xây trong AppMaster, những vấn đề này có thể tránh bằng các lựa chọn đơn giản: danh sách chọn, bắt buộc người chịu trách nhiệm và hạn chót cho hành động, ảnh đính kèm lưu chung với sự cố, và nhật ký chỉnh sửa ghi lại ai thay đổi khi nào.

Danh sách kiểm tra nhanh để chọn hoặc cải thiện hệ thống

Ứng dụng chỉ giúp khi mọi người thực sự dùng khi bận. Trước khi mua, xây hay “cải thiện” gì, thử thiết lập hiện tại bằng một sự cố thực và bấm giờ.

Danh sách kiểm tra:

• Người công nhân thời tuyến có thể ghi các thông tin cơ bản trong dưới 2 phút, một tay trên điện thoại, mà không phải đoán phải gõ gì không?
• Họ có thể đính kèm ảnh tại chỗ, và ảnh có rõ đủ để thấy điều quan trọng (vị trí, thiết bị, nhãn, nguy cơ) không?
• Mỗi sự cố có người chịu trách nhiệm và hạn chót cho bước tiếp theo không?
• Quản lý có thể lọc nhanh sự cố quý trước bằng các bộ lọc đơn giản (khoảng thời gian, site, loại, trạng thái) không?
• Hành động quá hạn có hiển thị rõ trong view hàng ngày mà không cần xuất ra bảng tính không?

Nếu trả lời “không” cho bất kỳ câu nào, bắt đầu với sửa nhỏ nhất. Nếu báo cáo quá lâu, giảm gõ phím: dùng danh sách chọn cho loại và vị trí, rồi cho một ô văn bản ngắn cho chuyện đã xảy ra.

Bài kiểm tra thực tế: nhờ hai người báo cùng một sự kiện nhỏ (ví dụ vướng nguy cơ vấp gần cửa kho). Nếu hai hồ sơ khác nhau quá nhiều, biểu mẫu của bạn quá mở hoặc các lựa chọn không rõ ràng.

Ví dụ: một sự cố đơn giản từ báo cáo tới đóng

Một nhân viên kho bước lên một vết ướt nhỏ gần tủ lạnh, trượt và tự vịn kệ. Không bị thương nhưng có thể tệ hơn. Mười phút sau, một lái xe nâng báo near-miss: một pallet trên tầng cao bị nhô ra lối đi.

Giám sát mở ứng dụng trên điện thoại và lập hai báo cáo nhanh trong khi chi tiết còn tươi. Mỗi báo cáo được đánh dấu “near-miss” và gắn vị trí Stockroom cùng ca làm việc giống nhau.

Những gì được ghi ngay tại chỗ

Báo cáo đầu có hai ảnh: vết ướt (không có nón cảnh báo) và đường ống thoát nước tủ lạnh. Ghi chú ngắn, thực tế: “Nước trên sàn, rộng 1m. Không có nón. Nhân viên trượt, không ngã, không bị thương.”

Near-miss với pallet có ảnh toàn cảnh kệ và ảnh cận cho thấy thùng nhô ra. Ghi chú: “Pallet đặt lệch tâm. Lối đi bị chắn 2 phút. Xe nâng dừng trước khi vào.”

Trước khi lưu, giám sát giao theo dõi:

• Bảo trì: kiểm tra ống thoát tủ lạnh và sửa leak trước cuối ngày
• Trưởng kho: bổ sung bộ dụng cụ tràn và đặt nón cảnh báo, hôm nay
• Quản lý kho: nhắc lại quy tắc xếp pallet trong cuộc họp toolbox tuần tới
• Chủ nhiệm đào tạo: xác nhận rà soát cho lái xe nâng trong tuần này

Đóng, xác minh và rà soát hàng tháng

Khi nhiệm vụ xong, người xác minh (không phải người hoàn thành) thêm ghi chú kiểm tra và ảnh “sau”: sàn khô có nón, pallet được chỉnh và lối đi thông.

Trong buổi rà soát an toàn hàng tháng, nhóm lọc lịch sử theo vị trí và near-miss. Họ thấy mô hình: hầu hết vấn đề kho xảy ra gần tủ lạnh và khi restocking bận rộn. Hành động tháng sau: thêm kiểm tra ống thoát hàng tuần và biển nhắc trên cửa tủ lạnh.

Bước tiếp theo: triển khai ứng dụng nhật ký mà không làm gián đoạn công việc

Ứng dụng chỉ giúp khi mọi người dùng khi họ bận. Cách triển khai an toàn là nhỏ, rõ ràng và nhất quán.

Viết phiên bản đầu trên một trang trước khi xây bất cứ gì. Giữ vài trường bạn thực sự cần, cộng luồng đơn giản cho việc tiếp theo: ai được thông báo, ai giao theo dõi, và cách xác nhận đóng. Nếu bạn không thể giải thích luồng trong 60 giây, nó quá phức tạp cho bản phát hành đầu.

Thí điểm với một site, ca hoặc đội trong 2–4 tuần. Chọn nhóm báo cáo đủ thường xuyên để có phản hồi, và ít nhất một giám sát sẽ xử lý theo dõi. Trong giai đoạn thí điểm, quan sát điểm gây cản trở: chỗ người dừng lại, chỗ họ bỏ qua và câu hỏi khiến bối rối.

Kế hoạch triển khai ngắn:

• Huấn luyện 10 phút: khi nào báo, cách thêm ảnh và ý nghĩa của “đóng”
• Thống nhất thời gian rà soát (cùng ca hoặc trong 24 giờ)
• Giao một người chịu trách nhiệm sắp xếp trường và danh mục sau phản hồi
• Đặt phương án dự phòng cho sự cố (ghi giấy, nhập lại sau)

Khi sống, thiết lập thói quen rà soát hàng tháng dùng hồ sơ có thể tìm kiếm. Tìm vị trí lặp lại, nguyên nhân phổ biến và hành động quá hạn. Chia sẻ một chỉ số đơn giản với đội, ví dụ “% đóng đúng hạn,” để công cụ liên kết rõ với cải thiện thực tế.

Nếu bạn muốn xây không cần viết mã, AppMaster có thể giúp tạo nhật ký web và mobile với biểu mẫu, tải ảnh, vai trò và luồng theo dõi phù hợp với cách trang của bạn vận hành.