Chuyển đổi quy trình số được thực hiện như thế nào?

Điểm quyết định nằm ở thứ tự này. Nếu số hóa trước khi phân tích và tái thiết kế, phần mềm có thể tự động hóa cả những bước thừa, luồng phê duyệt không cần thiết và thao tác nhập liệu lặp lại. Nếu thiết kế quy trình đích trước, công nghệ trở thành phương tiện thực thi một cách vận hành đã được làm rõ.

Chuyển đổi quy trình số bắt đầu từ tái thiết kế, không phải từ phần mềm

Một quy trình số không đơn thuần là phiên bản điện tử của biểu mẫu giấy hoặc chuỗi email hiện tại. Nó phải xác định được công việc đi từ trạng thái nào sang trạng thái nào, ai chịu trách nhiệm, dữ liệu nào được sử dụng, điều kiện nào quyết định hướng xử lý, trường hợp nào là ngoại lệ và hệ thống nào cần trao đổi dữ liệu với nhau.

Vì vậy, chuyển đổi thường diễn ra theo logic As-Is → phân tích → To-Be → số hóa → đo lường. As-Is mô tả cách quy trình thực sự đang chạy. To-Be mô tả cách nó nên vận hành sau khi các bước không cần thiết, điểm chờ, trùng lặp dữ liệu và quy tắc thiếu rõ ràng đã được xử lý.

Đây cũng là lý do mô hình hóa quy trình có giá trị trước khi triển khai công nghệ. BPMN do OMG duy trì cung cấp các thành phần như activity, event, gateway, pool và lane để thể hiện công việc, sự kiện, quyết định và trách nhiệm giữa các bên. Cách tiếp cận theo quá trình trong quản lý chất lượng cũng nhấn mạnh việc nhìn một quy trình qua đầu vào, đầu ra, trách nhiệm, tiêu chí kiểm soát và mối liên hệ với các quy trình khác. Hai cách nhìn này giúp tránh thiết kế workflow chỉ dựa trên danh sách thao tác rời rạc.

Tuy nhiên, không phải quy trình nào cũng cần tái cấu trúc lớn. Nếu quy trình hiện tại đã đơn giản, ổn định, có trách nhiệm rõ, ít ngoại lệ và các bước kiểm soát đều có lý do nghiệp vụ hoặc pháp lý xác định, giai đoạn tái thiết kế có thể rất nhẹ. Điều không nên bỏ qua là việc kiểm chứng các giả định đó trước khi tự động hóa.

Bước 1: Khoanh phạm vi và dựng bản đồ quy trình hiện trạng

Không thể cải tiến một quy trình nếu ranh giới của nó chưa được xác định. Trước khi vẽ sơ đồ, cần biết sự kiện nào làm quy trình bắt đầu, kết quả nào đánh dấu quy trình kết thúc và đối tượng giao dịch nào đang được xử lý. Một quy trình “phê duyệt mua hàng”, chẳng hạn, có thể bắt đầu từ lúc nhu cầu được tạo hoặc chỉ từ lúc yêu cầu đã đầy đủ hồ sơ; hai cách xác định sẽ tạo ra dữ liệu thời gian xử lý hoàn toàn khác nhau.

Mô tả As-Is theo cách công việc thực sự diễn ra

Bản đồ As-Is cần phản ánh thực tế thay vì chỉ sao chép quy trình trong tài liệu nội bộ. Với mỗi chặng quan trọng, cần xác định người hoặc bộ phận thực hiện, dữ liệu đầu vào, kết quả đầu ra, hệ thống đang dùng, điều kiện ra quyết định, điểm bàn giao, thời gian chờ và các trường hợp phải xử lý khác luồng chuẩn.

Nguồn thông tin có thể đến từ phỏng vấn người thực hiện, quan sát công việc, hồ sơ giao dịch, nhật ký hệ thống hoặc dữ liệu sự kiện nếu hệ thống hiện tại đã ghi nhận chúng. Khi có event log đủ chất lượng, process mining có thể hỗ trợ phát hiện đường đi thực tế của hồ sơ, số lần quay lại bước trước hoặc các biến thể mà tài liệu quy trình không thể hiện.

Mức chi tiết nên dừng ở nơi nó còn giúp ra quyết định. Nếu hai thao tác liên tiếp do cùng một người thực hiện, không có điểm kiểm soát, không tạo dữ liệu riêng và việc tách chúng không ảnh hưởng phân tích, mô hình hóa thành hai bước riêng có thể chỉ làm sơ đồ phức tạp hơn. Ngược lại, một bước “kiểm tra hồ sơ” cần được tách rõ nếu bên trong có nhiều điều kiện khiến hồ sơ đi theo các nhánh khác nhau.

Khóa trách nhiệm, dữ liệu và ngoại lệ ngay từ hiện trạng

Ba loại thông tin thường bị bỏ sót trong bản đồ quy trình là quyền sở hữu, nguồn dữ liệu và ngoại lệ. Nếu không biết ai chịu trách nhiệm cuối cùng cho một bước, workflow số khó xác định quyền xử lý và cơ chế escalations. Nếu không biết dữ liệu nào là nguồn chính thức, hệ thống mới dễ tạo thêm một bản sao dữ liệu. Nếu chỉ mô hình hóa “happy path”, các trường hợp thiếu hồ sơ, vượt hạn mức hoặc cần phê duyệt đặc biệt sẽ xuất hiện muộn và buộc đội triển khai sửa thiết kế.

Kết quả của bước này không phải là một sơ đồ đẹp, mà là một mô hình đủ đáng tin cậy để giải thích quy trình hiện tại đang mất thời gian, phát sinh lỗi và phụ thuộc vào con người ở đâu.

Bước 2: Phân tích điểm nghẽn và xác định thứ gì nên thay đổi

Sau khi có As-Is, mục tiêu không phải tìm càng nhiều vấn đề càng tốt mà là xác định nguyên nhân nào thực sự làm giảm hiệu quả hoặc tăng rủi ro. Một bước mất hai ngày không nhất thiết cần tự động hóa nếu chỉ mất vài phút thao tác và phần còn lại là thời gian chờ phê duyệt. Trong trường hợp đó, tự động hóa thao tác không xử lý được nguyên nhân chính.

Đo thời gian chờ tách biệt với thời gian xử lý

Baseline cần được thiết lập trước khi thay đổi quy trình. Những chỉ số hữu ích phụ thuộc từng trường hợp nhưng thường bao gồm lead time từ lúc bắt đầu đến lúc hoàn tất, touch time thực tế có người hoặc hệ thống xử lý, số lần bàn giao, tỷ lệ hồ sơ bị trả lại, tỷ lệ ngoại lệ và mức tuân thủ SLA.

Việc tách lead time khỏi touch time đặc biệt quan trọng. Nếu một hồ sơ có lead time 24 giờ nhưng tổng thời gian xử lý thực tế chỉ 20 phút, vấn đề nằm chủ yếu ở hàng đợi, lịch phê duyệt hoặc cách phân công chứ không nằm ở tốc độ thao tác. Ngược lại, touch time lớn do người dùng phải tra cứu nhiều nguồn và nhập cùng một dữ liệu sang nhiều hệ thống là tín hiệu rõ cho tích hợp hoặc tự động hóa.

Không có một mức phần trăm cải thiện chung có thể dùng làm benchmark cho mọi quy trình. Một quy trình tài chính có yêu cầu kiểm soát khác quy trình chăm sóc khách hàng; giao dịch có giá trị cao cũng không thể áp cùng mục tiêu tự động hóa với giao dịch tiêu chuẩn. Benchmark có ý nghĩa nhất ở giai đoạn này là baseline của chính quy trình, được đo bằng cùng định nghĩa dữ liệu trước và sau thay đổi.

Phân biệt vấn đề quy trình với vấn đề công nghệ

Mỗi điểm nghẽn nên được truy về nguyên nhân. Nếu một hồ sơ phải qua ba cấp phê duyệt vì chính sách yêu cầu như vậy, đó là vấn đề thiết kế hoặc yêu cầu kiểm soát. Nếu nhân viên nhập cùng mã khách hàng ba lần vì các hệ thống không kết nối, đó là vấn đề dữ liệu và tích hợp. Nếu hồ sơ bị trả lại thường xuyên vì người gửi không biết trường nào bắt buộc, nguyên nhân nằm ở chất lượng đầu vào và quy tắc kiểm tra.

Sự phân loại này quyết định giải pháp. Thêm robot vào một bước phê duyệt không cần thiết chỉ làm bước thừa chạy nhanh hơn. Ngược lại, bỏ một bước kiểm soát bắt buộc chỉ để giảm lead time có thể tạo rủi ro lớn hơn phần thời gian tiết kiệm được.

Bước 3: Tái thiết kế quy trình đích trước khi tự động hóa

To-Be là thiết kế vận hành sau cải tiến, chưa phải cấu hình của một phần mềm cụ thể. Ở giai đoạn này, mỗi vấn đề được phát hiện trong As-Is phải dẫn đến một quyết định thiết kế: loại bỏ, hợp nhất, thực hiện song song, chuẩn hóa, chuyển trách nhiệm, tự động kiểm tra hoặc giữ nguyên có chủ đích.

Tối giản luồng chuẩn nhưng không xóa các kiểm soát cần thiết

Những bước không tạo kết quả mới, không giảm rủi ro và không đáp ứng yêu cầu bắt buộc là ứng viên để loại bỏ. Các kiểm tra trùng nhau có thể được hợp nhất. Hai phê duyệt độc lập có thể chạy song song thay vì nối tiếp. Dữ liệu đã tồn tại trong hệ thống nguồn nên được lấy lại thay vì yêu cầu người dùng nhập lần nữa.

Các quyết định lặp lại cũng nên được chuyển thành business rule rõ ràng. Thay vì quy định “đơn hàng lớn cần phê duyệt thêm”, To-Be phải xác định điều kiện nào kích hoạt cấp phê duyệt, dữ liệu nào được dùng để đánh giá và điều gì xảy ra khi dữ liệu không đầy đủ. Quy tắc càng mơ hồ, phần mềm càng phải dựa vào xử lý thủ công.

Tuy nhiên, “không tạo giá trị trực tiếp cho khách hàng” không đồng nghĩa với “có thể xóa”. Kiểm soát tuân thủ, phân tách nhiệm vụ, xác minh danh tính hoặc phê duyệt rủi ro có thể làm quy trình dài hơn nhưng vẫn cần tồn tại. Tái thiết kế tốt là giảm những bước không cần thiết mà không làm suy yếu nghĩa vụ kiểm soát.

Thiết kế cả luồng ngoại lệ, không chỉ luồng lý tưởng

Một workflow chỉ vận hành tốt khi biết phải làm gì lúc điều kiện bình thường không còn đúng. To-Be cần xác định trường hợp nào hệ thống được phép tự xử lý, trường hợp nào phải chuyển sang con người, ai có quyền override và sau override cần lưu lại thông tin gì.

Đây là ranh giới quan trọng của tự động hóa. Các giao dịch có dữ liệu đầy đủ, quy tắc ổn định và kết quả xác định thường phù hợp với xử lý tự động. Những trường hợp cần phán đoán, dữ liệu không chắc chắn hoặc có tác động rủi ro cao nên giữ điểm kiểm tra của con người. Mục tiêu không phải đạt tỷ lệ tự động hóa lớn nhất, mà là tự động hóa phần đủ xác định và làm cho ngoại lệ dễ nhận biết, dễ kiểm soát hơn.

Đến cuối bước To-Be, quy trình cần có ít nhất một luồng chuẩn, các nhánh quyết định, đường xử lý ngoại lệ, vai trò chịu trách nhiệm, dữ liệu sử dụng, điểm kiểm soát và tiêu chí hoàn tất. Khi những thành phần này chưa rõ, cấu hình phần mềm thường chỉ đẩy các quyết định chưa giải quyết sang giai đoạn triển khai.

Bước 4: Chuyển quy trình đích thành workflow số

Khi To-Be đã ổn định, thiết kế nghiệp vụ được ánh xạ sang các thành phần kỹ thuật. Một activity có thể trở thành task của người dùng hoặc tác vụ hệ thống; gateway trở thành rule định tuyến; dữ liệu đầu vào được chuyển thành trường dữ liệu và validation; handoff trở thành cơ chế giao việc; các mốc thời gian trở thành timer, SLA hoặc cảnh báo.

Số hóa đồng thời workflow, dữ liệu và business rule

Workflow engine chỉ giải quyết phần luồng. Để quy trình thực sự chạy số, dữ liệu và quy tắc phải được xử lý cùng lúc. Biểu mẫu nên kiểm tra dữ liệu ngay khi nhập nếu điều kiện kiểm tra đã xác định được. Business rule nên được biểu diễn đủ rõ để hệ thống quyết định tuyến xử lý. Trạng thái hồ sơ phải nhất quán để người dùng biết một giao dịch đang ở đâu và đang chờ ai.

Hệ thống cũng cần lưu dấu các sự kiện quan trọng như ai thực hiện hành động, thời điểm xảy ra, trạng thái trước và sau, lý do thay đổi hoặc quyết định override. Audit trail không chỉ phục vụ kiểm tra; nó còn tạo dữ liệu để đo quy trình sau triển khai.

Ưu tiên tích hợp dữ liệu thay vì sao chép thao tác thủ công

Nếu một bước cần dữ liệu từ CRM, ERP hoặc hệ thống lõi khác, tích hợp qua giao diện máy-máy thường tạo cấu trúc bền vững hơn việc để người dùng đọc ở một màn hình rồi nhập sang màn hình khác. Khi hệ thống nguồn có API phù hợp, workflow có thể lấy dữ liệu, gửi giao dịch và nhận trạng thái trực tiếp.

RPA hữu ích khi một hệ thống cũ không cung cấp phương thức tích hợp khả thi nhưng vẫn phải tham gia quy trình. Đổi lại, tự động hóa dựa trên giao diện người dùng thường nhạy hơn với thay đổi màn hình, bố cục hoặc trình tự thao tác. Vì vậy, RPA nên được xem là một lựa chọn tích hợp theo điều kiện cụ thể, không phải cách mặc định để số hóa mọi bước thủ công.

Ví dụ, trong quy trình đề nghị mua hàng, hiện trạng có thể gồm biểu mẫu gửi qua email, quản lý phê duyệt, phòng tài chính kiểm tra ngân sách rồi một nhân viên nhập lại dữ liệu vào ERP. To-Be có thể dùng một biểu mẫu duy nhất để kiểm tra trường bắt buộc, lấy mã đơn vị từ nguồn dữ liệu chuẩn, định tuyến theo hạn mức, cho các kiểm tra độc lập chạy song song và gửi giao dịch đã duyệt vào ERP qua tích hợp. Con người chỉ nhận những trường hợp vượt ngưỡng, thiếu dữ liệu hoặc thuộc nhóm ngoại lệ. Giá trị của workflow số trong ví dụ này đến từ việc thay đổi luồng, dữ liệu và rule cùng nhau, không phải từ việc biến email thành một biểu mẫu điện tử.

Bước 5: Kiểm thử, triển khai và đo hiệu quả sau số hóa

Quy trình số chỉ nên được xem là hoàn thành khi kết quả vận hành được kiểm chứng. Kiểm thử chức năng cho biết các màn hình và rule có chạy đúng hay không, nhưng chưa đủ. Cần kiểm thử cả hành vi của quy trình: hồ sơ chuẩn có đi đúng tuyến, ngoại lệ có đến đúng người, quyền truy cập có phù hợp vai trò, tích hợp thất bại được xử lý thế nào và có thể truy vết một quyết định sau khi giao dịch kết thúc hay không.

Triển khai theo phạm vi kiểm soát giúp tách lỗi thiết kế khỏi tác động của quy mô. Một pilot nên sử dụng đúng nhóm giao dịch mà quy trình đích được thiết kế để xử lý, đồng thời giữ cách đo nhất quán với baseline. Nếu phạm vi, loại giao dịch hoặc cách tính KPI thay đổi giữa hai giai đoạn, số liệu trước và sau sẽ không còn so sánh trực tiếp.

Đánh giá bằng KPI của quy trình, không bằng việc phần mềm đã chạy

Một bộ đo cơ bản có thể được xác định như sau:

Các chỉ số phải được đọc cùng nhau. Straight-through processing tăng nhưng exception bị phân loại sai không phải là cải tiến. Lead time giảm trong khi rework tăng mạnh cũng có thể chỉ cho thấy lỗi được chuyển sang công đoạn sau. Vì vậy, mục tiêu số hóa cần gắn cả với tốc độ, chất lượng và mức kiểm soát phù hợp với bản chất quy trình.

Dữ liệu vận hành sau triển khai còn có một vai trò khác: nó biến cải tiến quy trình từ dự án một lần thành vòng phản hồi. Audit log và event data cho thấy nhánh nào xuất hiện nhiều hơn dự kiến, rule nào tạo quá nhiều ngoại lệ hoặc công đoạn nào tiếp tục hình thành hàng đợi. Khi đó, quy trình có thể được điều chỉnh dựa trên hành vi thực tế thay vì quay lại dựa chủ yếu vào nhận định chủ quan.

Chuyển đổi một quy trình hiện có sang quy trình số vì thế không phải là thao tác “đưa quy trình lên phần mềm”. Quy trình cần được hiểu đúng ở trạng thái As-Is, đo được vấn đề, tái thiết kế thành To-Be rồi mới ánh xạ thành workflow, dữ liệu, business rule và tích hợp. Sau triển khai, hiệu quả phải được kiểm chứng bằng cùng hệ chỉ số đã dùng để tạo baseline. Trình tự này giúp công nghệ tự động hóa một cách vận hành đã được cải thiện, thay vì chỉ làm cho những bất hợp lý cũ diễn ra nhanh hơn trên môi trường số.