TrungTamSoHoa.comTrung Tâm Số Hoá
Tự động hoá quy trình (RPA)

Quản trị bot RPA: trung tâm xuất sắc (CoE), vận hành, bảo mật và vòng đời bot

Khi số bot tăng, rủi ro nằm ở vận hành chứ không ở công nghệ. Mô hình CoE, vai trò, quy chuẩn phát triển, bảo mật tài khoản bot, giám sát và quy trình gỡ bot.

Wide shot of a dim server room aisle with rows of racks and small blinking lights, one technician seen from behind holding a laptop, cool green and graphite tones

Quản trị bot RPA là tập hợp vai trò, quy chuẩn và quy trình giúp doanh nghiệp xây, vận hành, bảo vệ và gỡ bỏ bot một cách có kiểm soát. Với một hai bot, việc này nằm trong đầu một người. Với vài chục bot, thiếu quản trị là nguyên nhân chính khiến chương trình tự động hoá dừng lại: bot hỏng không ai sửa, tài khoản bot có quyền rộng không ai rà, quy trình đã đổi mà bot vẫn chạy theo cách cũ.

Mô hình tổ chức phổ biến nhất là trung tâm xuất sắc (Center of Excellence — CoE): một nhóm nhỏ giữ quy chuẩn, nền tảng và năng lực chung, phối hợp với các phòng ban sở hữu quy trình. CoE không nhất thiết phải là một phòng mới; ở doanh nghiệp vừa, đó có thể là ba bốn người kiêm nhiệm với trách nhiệm rõ ràng.

Bài này trình bày các mô hình tổ chức, vai trò, quy chuẩn phát triển, bảo mật tài khoản bot, vận hành và giám sát hằng ngày, quản lý thay đổi và vòng đời bot.

Ba mô hình tổ chức

Lựa chọn mô hình phụ thuộc quy mô, mức trưởng thành và văn hoá ra quyết định của doanh nghiệp. Nhiều tổ chức đi từ tập trung sang liên kết khi chương trình lớn dần.

Mô hìnhCách vận hànhƯu điểmNhược điểm
Tập trungMột đội duy nhất xây và vận hành mọi botQuy chuẩn đồng nhất, kiểm soát chặt, dễ học hỏi từ dự án trướcDễ thành điểm nghẽn, xa nghiệp vụ
Phân tánMỗi phòng ban tự xây và vận hành botGần nghiệp vụ, nhanhQuy chuẩn rời rạc, trùng lặp, rủi ro bảo mật
Liên kết (hub-and-spoke)CoE giữ nền tảng, quy chuẩn, bảo mật, vận hành; phòng ban có người phát triển và sở hữu quy trìnhCân bằng tốc độ và kiểm soátCần phân định trách nhiệm rõ, tốn công phối hợp

Với doanh nghiệp mới bắt đầu, mô hình tập trung giúp xây khuôn mẫu đúng ngay từ đầu. Khi đã có quy chuẩn và vài chục bot chạy ổn, chuyển dần sang liên kết để mở rộng mà không biến CoE thành điểm nghẽn.

Các vai trò cần có

Người bảo trợ. Một lãnh đạo cấp cao chịu trách nhiệm về kết quả của chương trình, phân xử ưu tiên giữa các phòng, bảo vệ ngân sách. Không có người bảo trợ, CoE chỉ là một nhóm kỹ thuật đi xin việc.

Người sở hữu quy trình. Trưởng bộ phận nghiệp vụ chịu trách nhiệm quy trình mà bot phục vụ: duyệt thiết kế, nghiệm thu, quyết định khi quy trình thay đổi, và chịu trách nhiệm về kết quả đầu ra — bot chỉ là công cụ của họ, không phải của CNTT.

Chuyên viên phân tích quy trình. Ghi chép quy trình, đo khối lượng, đánh giá khả năng tự động hoá, viết tài liệu thiết kế. Đây là vai trò hay bị thiếu nhất và là nguyên nhân của nhiều bot thiết kế sai.

Người phát triển bot. Xây, kiểm thử, sửa lỗi theo quy chuẩn. Có thể ở CoE hoặc ở phòng ban trong mô hình liên kết.

Kiến trúc sư giải pháp. Quyết định khi nào dùng RPA, khi nào dùng API hay workflow, thiết kế cách bot kết nối với hạ tầng và an toàn thông tin. Ở doanh nghiệp vừa, vai trò này thường do một người từ phòng CNTT kiêm nhiệm.

Đội vận hành. Giám sát hằng ngày, khởi động lại khi bot dừng, phân loại sự cố, xử lý hoặc chuyển tiếp. Cần có lịch trực tương ứng với lịch chạy của bot.

Quy chuẩn phát triển tối thiểu

Quy chuẩn là thứ biến năm mươi bot của năm mươi người thành một hệ thống duy trì được. Danh sách tối thiểu:

  • Quy ước đặt tên cho bot, quy trình, biến, tệp cấu hình, gắn với mã quy trình trong danh mục.
  • Khuôn mẫu chuẩn có sẵn phần khởi tạo, đọc cấu hình, xử lý lỗi, ghi nhật ký, dọn dẹp khi kết thúc. Mọi bot mới bắt đầu từ khuôn mẫu.
  • Tách cấu hình khỏi logic: đường dẫn, địa chỉ hệ thống, ngưỡng, danh sách người nhận thông báo nằm trong cấu hình, không viết cứng trong kịch bản.
  • Phân biệt hai loại lỗi: lỗi nghiệp vụ (dữ liệu không hợp lệ — chuyển cho người, bot làm tiếp hồ sơ khác) và lỗi hệ thống (ứng dụng không phản hồi — thử lại có giới hạn, rồi dừng và báo động).
  • Nhật ký có cấu trúc: mỗi giao dịch ghi mã hồ sơ, bước, kết quả, thời gian; không ghi mật khẩu hay dữ liệu nhạy cảm vào nhật ký.
  • Quản lý phiên bản mã nguồn bot trong kho mã, mỗi lần đưa lên môi trường chạy thật có ghi lại phiên bản và người duyệt.
  • Rà soát chéo trước khi triển khai: một người phát triển khác đọc lại kịch bản theo danh mục kiểm tra.
  • Tài liệu bàn giao: sơ đồ quy trình, danh sách hệ thống, tài khoản dùng, ngoại lệ đã biết, cách khởi động lại, người liên hệ nghiệp vụ.

Bảo mật tài khoản bot

Bot cần đăng nhập vào các hệ thống như một người dùng, và đây là điểm rủi ro thường bị đánh giá thấp. Nguyên tắc đầu tiên: mỗi bot một danh tính riêng, không dùng chung tài khoản của nhân viên. Dùng tài khoản của người làm mất khả năng truy vết — không biết thao tác nào do người, thao tác nào do bot — và vi phạm chính sách mật khẩu cá nhân. Tài khoản bot cũng phải được đánh dấu rõ trong danh bạ người dùng, có người sở hữu là con người.

Nguyên tắc thứ hai: quyền tối thiểu. Bot chỉ được cấp đúng quyền cần cho các bước của nó, trên đúng hệ thống cần. Một bot đọc báo cáo không cần quyền ghi; một bot nhập đơn không cần quyền duyệt. Quyền của bot phải đi qua cùng nguyên tắc tách bạch nhiệm vụ như người: một bot không nên vừa tạo nhà cung cấp mới vừa tạo lệnh thanh toán cho nhà cung cấp đó.

Nguyên tắc thứ ba: mật khẩu nằm trong kho bảo mật tập trung của bộ điều phối hoặc hệ thống quản lý bí mật, không nằm trong tệp cấu hình, không nằm trong kịch bản, không gửi qua thư. Mật khẩu bot cũng phải được đổi định kỳ theo chính sách, và quy trình đổi phải được kiểm thử — bot dừng hàng loạt vì mật khẩu hết hạn là sự cố rất phổ biến. Cuối cùng, quyền của tài khoản bot được rà soát định kỳ cùng đợt rà soát quyền người dùng; bot đã gỡ thì tài khoản phải bị vô hiệu hoá ngay.

Vận hành và giám sát hằng ngày

Bot không giám sát chỉ đáng tin khi có người giám sát bot. Quy trình vận hành tối thiểu:

  1. Bảng theo dõi trạng thái: bot nào đang chạy, chạy xong, dừng lỗi; hàng đợi còn bao nhiêu việc; hàng đợi ngoại lệ chờ người bao nhiêu.
  2. Báo động có phân cấp: lỗi hệ thống làm dừng bot báo ngay cho người trực; tỷ lệ ngoại lệ tăng bất thường báo cho người sở hữu quy trình; bot chạy lâu bất thường cũng là một tín hiệu.
  3. Phân loại sự cố theo mức ảnh hưởng và cam kết thời gian khắc phục tương ứng, được người sở hữu quy trình đồng ý từ trước.
  4. Phương án dự phòng thủ công cho mỗi bot quan trọng: nếu bot dừng một ngày, ai làm thay, theo tài liệu nào. Nhân viên đã quen để bot làm sẽ quên quy trình nếu không có tài liệu này.
  5. Đối chiếu đầu ra định kỳ: lấy mẫu kết quả bot làm, so với nguồn, để phát hiện lỗi chạy âm thầm — bot báo thành công nhưng ghi sai.
  6. Báo cáo hằng tháng cho người bảo trợ và người sở hữu quy trình: khối lượng, tỷ lệ chạy thành công, sự cố, giờ công vận hành.

Chỉ số đo sức khoẻ của chương trình

Ngoài chỉ số của từng bot, CoE nên theo dõi một bộ chỉ số cấp chương trình, báo cáo hằng quý cho người bảo trợ.

Chỉ sốĐo cái gìTín hiệu cần chú ý
Tỷ lệ chạy thành côngSố lần chạy hoàn tất trên tổng số lần chạy theo lịchGiảm dần qua các tháng: môi trường thay đổi nhanh hơn khả năng bảo trì
Tỷ lệ chạy thẳngPhần giao dịch bot xử lý trọn không cần ngườiThấp hơn nhiều so với lúc thiết kế: quy trình có biến thể chưa được tính
Thời gian khôi phụcTừ lúc bot dừng đến lúc chạy lạiDài và không đều: thiếu người trực hoặc thiếu tài liệu
Tỷ lệ công bảo trìGiờ công sửa bot cũ so với xây bot mớiTăng đều mỗi quý: nợ kỹ thuật đang tích luỹ
Bot không có người sở hữuSố bot mà người sở hữu đã nghỉ hoặc chuyển việcLớn hơn không là phải xử lý ngay
Lợi ích đã xác minhLợi ích đo được sau triển khai so với đề xuấtChênh lệch lớn: cách ước tính cần hiệu chỉnh

Bộ chỉ số này giúp cuộc trao đổi với lãnh đạo chuyển từ "có bao nhiêu bot" sang "các bot đang tạo ra giá trị bền vững đến đâu" — câu hỏi quyết định chương trình có được tiếp tục đầu tư hay không.

Quản lý thay đổi và vòng đời bot

Mối đe doạ lớn nhất với bot không phải lỗi lập trình mà là thay đổi ở môi trường xung quanh: hệ thống nguồn cập nhật giao diện, quy định mới làm đổi quy tắc nghiệp vụ, phòng ban đổi biểu mẫu. CoE nên được đưa vào quy trình quản lý thay đổi chung của CNTT: mỗi khi có kế hoạch cập nhật một ứng dụng, danh mục bot cho biết ngay bot nào bị ảnh hưởng, để kiểm thử trên môi trường thử trước ngày cập nhật.

Danh mục bot là xương sống của quản trị: mỗi bot có mã, mô tả, quy trình phục vụ, người sở hữu, hệ thống đi qua, tài khoản dùng, lịch chạy, phiên bản hiện hành, ngày rà soát gần nhất, chỉ số khối lượng và chi phí. Không có danh mục, câu hỏi đơn giản như "nếu đổi phần mềm kế toán thì bao nhiêu bot phải sửa" cũng không ai trả lời được.

Vòng đời bot nên có một điểm kết thúc được thiết kế sẵn. Mỗi năm, mỗi bot được rà lại: quy trình còn tồn tại không, khối lượng còn đủ không, có cách thay thế bền hơn không. Bot bị gỡ phải qua các bước: thông báo người sở hữu, chuyển việc sang cách mới, vô hiệu hoá tài khoản, lưu trữ mã và tài liệu, cập nhật danh mục. Những bot "mồ côi" — không còn ai sở hữu nhưng vẫn chạy — là rủi ro vận hành và bảo mật mà kiểm toán nội bộ nên đặc biệt chú ý.

Câu hỏi thường gặp

Doanh nghiệp vừa có cần lập CoE riêng không?

Không cần một phòng mới. Điều cần là các vai trò được giao rõ: một người bảo trợ, một người giữ quy chuẩn và nền tảng, người phát triển, người vận hành và người sở hữu quy trình ở mỗi phòng. Ba bốn người kiêm nhiệm có trách nhiệm ghi rõ trong mô tả công việc thường đủ cho vài chục bot đầu tiên.

Bot nên do phòng CNTT hay phòng nghiệp vụ sở hữu?

Quy trình và kết quả đầu ra thuộc về phòng nghiệp vụ; nền tảng, bảo mật, hạ tầng và quy chuẩn kỹ thuật thuộc về CNTT hoặc CoE. Phân định này nên được ghi thành văn bản, kèm ma trận trách nhiệm cho các tình huống như bot dừng, quy trình thay đổi, hệ thống nguồn cập nhật.

Có nên để nhân viên nghiệp vụ tự viết bot không?

Có thể, trong mô hình liên kết với quy chuẩn và nền tảng do CoE quản lý, cùng phân vùng rủi ro như với ứng dụng low-code: bot cá nhân phạm vi hẹp thì linh hoạt, bot chạy không giám sát trên hệ thống tài chính thì phải qua rà soát và triển khai bởi đội vận hành.

Làm sao biết một bot đang làm sai mà không báo lỗi?

Cần cơ chế đối chiếu độc lập với bot: lấy mẫu kết quả định kỳ để kiểm, so tổng số liệu giữa nguồn và đích, theo dõi các chỉ số bất thường như số giao dịch xử lý tăng giảm đột ngột. Thiết kế bot cũng nên tự kiểm sau khi ghi, đọc lại giá trị vừa nhập để xác nhận.

Kiểm toán nội bộ nên xem gì ở chương trình RPA?

Danh mục bot và người sở hữu, quyền của tài khoản bot so với nhu cầu, việc tách bạch nhiệm vụ giữa các bot, nơi lưu mật khẩu, quy trình kiểm soát thay đổi và triển khai, nhật ký chạy, cơ chế đối chiếu đầu ra, và các bot không còn người sở hữu. Bot thực hiện kiểm soát tài chính cần được kiểm như một kiểm soát tự động.

Bot có nên chạy trên máy tính của nhân viên không?

Bot có giám sát chạy trên máy nhân viên là bình thường. Bot không giám sát nên chạy trên máy chủ hoặc máy ảo riêng, được quản lý, vá lỗi và sao lưu như hạ tầng khác. Chạy bot không giám sát trên máy bàn của một người là rủi ro: máy tắt, cập nhật hệ điều hành hay người nghỉ việc đều làm bot dừng.

Cần tư vấn cụ thể cho trường hợp của bạn?

Chúng tôi sẽ liên hệ trong vòng 24 giờ.

Đăng ký tư vấn ngay

Bài viết liên quan

Bạn cần hỗ trợ thêm?

Để lại thông tin, chúng tôi sẽ liên hệ trong 24 giờ.