Quy trình “As-Is” – “To-Be” trong chuyển đổi số: Vì sao doanh nghiệp phải hiểu hiện trạng trước khi thay đổi?

Last updated on 27 August, 2026

Trong một dự án chuyển đổi số, doanh nghiệp thường nhanh chóng nghĩ đến việc lựa chọn phần mềm, tự động hóa công việc hoặc triển khai một hệ thống mới. Tuy nhiên, công nghệ chỉ thực sự tạo ra giá trị khi doanh nghiệp biết mình đang cần thay đổi điều gì. Đây là lý do quy trình “As-Is” – “To-Be” trở thành một công cụ quan trọng trong phân tích và tái thiết kế quy trình. Thay vì đưa ngay quy trình hiện tại lên môi trường số, doanh nghiệp cần xác định cách công việc đang thực sự diễn ra, hình dung trạng thái mong muốn và phân tích khoảng cách giữa hai trạng thái trước khi quyết định giải pháp công nghệ.

Quy trình “As-Is” – “To-Be” là gì?

Quy trình “As-Is” – “To-Be” mô tả hai trạng thái của một quy trình: As-Is là cách công việc đang được thực hiện ở hiện tại, còn To-Be là cách doanh nghiệp mong muốn quy trình vận hành trong tương lai sau khi được cải tiến hoặc tái cấu trúc.

Có thể hiểu đơn giản:

As-Is = Hiện tại đang làm như thế nào?

To-Be = Sau khi thay đổi, muốn làm như thế nào?

Ví dụ, một doanh nghiệp đang xử lý đơn hàng theo cách:

Nhận đơn → Nhập Excel → Gửi email cho kho → Kho kiểm tra tồn → Phản hồi → Kế toán xác nhận → Quản lý phê duyệt → Nhập lại hệ thống → Tạo phiếu xuất kho.

Đây là trạng thái As-Is.

Sau khi phân tích, doanh nghiệp nhận thấy một số bước đang bị trùng lặp và dữ liệu tồn kho có thể được kết nối trực tiếp với hệ thống. Quy trình mới có thể được rút gọn thành:

Nhận đơn → Hệ thống kiểm tra tồn kho → Phê duyệt theo hạn mức → Tạo phiếu xuất kho.

Đây là trạng thái To-Be.

Như vậy, quy trình “As-Is” – “To-Be” không chỉ giúp doanh nghiệp mô tả quy trình mà còn cho thấy công việc cần thay đổi như thế nào.

As-Is không phải là quy trình được ghi trong tài liệu

Một trong những sai lầm phổ biến khi xây dựng quy trình “As-Is” – “To-Be” là coi tài liệu quy trình hiện hành như một bản mô tả chính xác về thực tế.

Trên giấy, doanh nghiệp có thể quy định một quy trình chỉ gồm năm bước.

Nhưng trong công việc hằng ngày, nhân viên có thể phải gửi email xác nhận, nhập dữ liệu vào Excel, gọi điện cho một phòng ban khác hoặc xin phê duyệt qua nhóm chat trước khi có thể chuyển sang bước tiếp theo.

Những thao tác này có thể không xuất hiện trong tài liệu chính thức nhưng vẫn tiêu tốn thời gian và nguồn lực.

Vì vậy, phân tích As-Is cần phản ánh quy trình thực tế, không chỉ quy trình được thiết kế trên giấy.

Doanh nghiệp có thể kết hợp phỏng vấn nhân viên, quan sát công việc, phân tích dữ liệu vận hành và kiểm tra các hệ thống đang sử dụng để xác định dòng công việc thực sự.

Nếu As-Is đã sai ngay từ đầu, To-Be được xây dựng phía sau cũng rất dễ sai.

Vì sao doanh nghiệp cần xác định As-Is trước?

Không thể thiết kế một trạng thái tương lai tốt nếu doanh nghiệp không hiểu vấn đề của trạng thái hiện tại.

Một quy trình có thể chậm vì quá nhiều bước phê duyệt.

Một quy trình khác lại mất nhiều thời gian do nhân viên phải nhập cùng một dữ liệu ở nhiều hệ thống.

Có trường hợp bottleneck nằm ở một bộ phận duy nhất khiến toàn bộ quy trình bị đình trệ.

Nếu không xác định được nguyên nhân, doanh nghiệp rất dễ lựa chọn giải pháp công nghệ không giải quyết đúng vấn đề.

Ví dụ, nếu nguyên nhân khiến quy trình xử lý đơn hàng mất ba ngày là do quản lý phải phê duyệt mọi đơn hàng, việc mua một phần mềm quản lý đơn hàng mới không nhất thiết giải quyết được vấn đề.

Doanh nghiệp có thể cần thay đổi cơ chế phân quyền và phê duyệt trước.

Đây chính là giá trị của việc phân tích As-Is trong quy trình As-Is – To-Be.

To-Be không phải là As-Is được đưa lên phần mềm

Một hiểu nhầm khác là coi To-Be đơn giản như phiên bản điện tử của quy trình hiện tại.

Ví dụ:

As-Is: Nhân viên điền biểu mẫu giấy → quản lý ký → kế toán nhập dữ liệu.

To-Be sai: Nhân viên điền biểu mẫu điện tử → quản lý bấm duyệt → kế toán nhập dữ liệu.

Doanh nghiệp đã loại bỏ giấy nhưng vẫn giữ nguyên logic vận hành.

Một To-Be tốt hơn có thể là:

Nhân viên gửi yêu cầu → hệ thống kiểm tra dữ liệu → tự động phân loại → quản lý chỉ phê duyệt trường hợp cần thiết → dữ liệu tự động chuyển sang kế toán.

Lúc này, công nghệ không chỉ thay đổi phương tiện thực hiện mà còn giúp thiết kế lại cách công việc vận hành.

Đó mới là mục tiêu quan trọng của quy trình As-Is – To-Be trong chuyển đổi số.

Từ As-Is đến To-Be cần trải qua bước nào?

Sau khi xác định As-Is, doanh nghiệp cần phân tích những điểm đang tạo ra lãng phí hoặc hạn chế hiệu quả.

Có thể xem xét thời gian xử lý của từng bước, thời gian chờ, số lần chuyển giao giữa các phòng ban, số lượng thao tác thủ công, dữ liệu bị nhập lặp lại và những điểm thường xuyên xảy ra lỗi.

Từ đó, doanh nghiệp xác định những thay đổi cần thiết để xây dựng To-Be.

Một bước không tạo thêm giá trị có thể được loại bỏ.

Hai bước kiểm tra giống nhau có thể được hợp nhất.

Dữ liệu đã tồn tại trong hệ thống có thể được tự động đồng bộ thay vì nhập lại.

Một quy trình phê duyệt nhiều cấp có thể chuyển sang cơ chế phân quyền theo hạn mức.

Khi đó, To-Be không còn là một phiên bản “đẹp hơn” của As-Is mà trở thành một quy trình được thiết kế dựa trên mục tiêu vận hành mới.

Gap Analysis: Khoảng cách giữa hiện tại và tương lai

Sau khi có As-Is và To-Be, doanh nghiệp có thể thực hiện Gap Analysis, tức phân tích khoảng cách giữa hai trạng thái.

Ví dụ, hiện tại nhân viên nhập dữ liệu thủ công nhưng trạng thái mục tiêu yêu cầu dữ liệu được đồng bộ tự động. Khoảng cách ở đây có thể nằm ở việc doanh nghiệp chưa có kết nối giữa hai hệ thống.

Nếu As-Is có ba cấp phê duyệt nhưng To-Be chỉ cần một cấp theo hạn mức, khoảng cách lại nằm ở chính sách phân quyền.

Nếu nhân viên chưa có khả năng sử dụng hệ thống mới, vấn đề không còn nằm ở công nghệ mà liên quan đến đào tạo và thay đổi hành vi.

Điều này cho thấy Gap Analysis giúp doanh nghiệp tránh một suy nghĩ khá phổ biến: mọi khoảng cách đều phải được giải quyết bằng phần mềm.

Trên thực tế, một số khoảng cách cần công nghệ, một số cần thay đổi quy trình, còn những trường hợp khác cần thay đổi chính sách hoặc năng lực nhân sự.

Quy trình As-Is – To-Be giúp kiểm soát đầu tư công nghệ

Một dự án chuyển đổi số có thể nhanh chóng trở nên tốn kém nếu doanh nghiệp không xác định rõ phạm vi cần thay đổi.

Khi phân tích As-Is, doanh nghiệp có thể phát hiện rằng một số bước hoàn toàn không cần tồn tại.

Sau đó, To-Be được thiết kế với ít bước hơn và phạm vi tự động hóa cũng thu hẹp lại.

Điều này có thể giúp giảm số lượng chức năng cần phát triển, giảm yêu cầu tích hợp và hạn chế việc mua những phân hệ phần mềm không thực sự cần thiết.

Ví dụ, nếu một quy trình ban đầu có 12 bước nhưng sau khi tái cấu trúc chỉ còn 7 bước, doanh nghiệp không cần đầu tư để số hóa cả 12 bước đó.

Nói cách khác, quy trình “As-Is” – “To-Be” có thể trở thành một lớp lọc giúp doanh nghiệp xác định công nghệ nào thực sự cần thiết trước khi ngân sách được phân bổ.

Ai nên tham gia xây dựng quy trình “As-Is” – “To-Be”?

Phân tích quy trình không nên chỉ được thực hiện bởi phòng IT.

Nhân viên trực tiếp xử lý công việc cần tham gia vì họ hiểu những vấn đề phát sinh trong thực tế.

Quản lý bộ phận có thể cung cấp góc nhìn về mục tiêu, hiệu suất và các yêu cầu kiểm soát.

Đội IT hoặc đơn vị tư vấn chịu trách nhiệm đánh giá khả năng công nghệ và mức độ tự động hóa.

Lãnh đạo doanh nghiệp cần tham gia khi To-Be dẫn đến những thay đổi lớn về cách vận hành, quyền hạn hoặc nguồn lực.

Sự phối hợp giữa các bên giúp To-Be vừa có tính thực tế, vừa phù hợp với mục tiêu kinh doanh và khả năng triển khai.

Những sai lầm thường gặp khi xây dựng As-Is và To-Be

Một lỗi phổ biến là chỉ vẽ quy trình mà không đo lường hiệu quả của từng bước.

Một sơ đồ có thể rất đẹp nhưng không cho biết bước nào đang chiếm nhiều thời gian nhất.

Sai lầm khác là xây dựng As-Is dựa hoàn toàn trên tài liệu chính thức mà không kiểm tra cách nhân viên thực sự làm việc.

Ở chiều ngược lại, doanh nghiệp cũng có thể thiết kế To-Be quá lý tưởng, đưa vào hàng loạt công nghệ mới mà không xem xét khả năng triển khai, chi phí hoặc mức độ sẵn sàng của nhân viên.

Một To-Be tốt cần đạt được sự cân bằng giữa hiệu quả mong muốn và khả năng thực hiện.

Không phải quy trình nào cũng cần AI.

Không phải công việc thủ công nào cũng cần tự động hóa.

Và không phải bước nào đang tồn tại cũng cần bị loại bỏ.

Điều quan trọng là doanh nghiệp phải hiểu tại sao một bước tồn tại trước khi quyết định giữ lại, thay đổi hay loại bỏ nó.

Quy trình “As-Is” – “To-Be” trong chuyển đổi số nên bắt đầu bằng câu hỏi nào?

Thay vì bắt đầu bằng câu hỏi:

“Doanh nghiệp nên mua phần mềm gì?”

Hãy bắt đầu bằng:

“Công việc đang thực sự diễn ra như thế nào?”

Sau đó:

“Điểm nào đang khiến quy trình chậm, tốn kém hoặc dễ xảy ra lỗi?”

Tiếp theo:

“Nếu được thiết kế lại từ đầu, quy trình nên vận hành như thế nào?”

Và cuối cùng:

“Công nghệ có thể giúp chúng ta đạt được trạng thái đó ở đâu?”

Chuỗi câu hỏi này giúp doanh nghiệp đi theo đúng thứ tự:

Hiểu hiện trạng → Xác định vấn đề → Thiết kế trạng thái mục tiêu → Phân tích khoảng cách → Lựa chọn công nghệ → Triển khai.

Đó cũng là logic cốt lõi phía sau quy trình “As-Is” – “To-Be”.

Kết luận

Quy trình “As-Is” – “To-Be” giúp doanh nghiệp nhìn nhận chuyển đổi số không phải là việc đưa mọi hoạt động hiện tại lên một hệ thống mới.

As-Is giúp tổ chức hiểu cách công việc thực sự đang diễn ra, từ những bước chính thức đến các thao tác phát sinh, thời gian chờ và điểm nghẽn.

To-Be mở ra trạng thái vận hành mà doanh nghiệp muốn đạt được sau khi cải tiến, với mục tiêu đơn giản hóa quy trình, giảm lãng phí và tập trung nguồn lực vào những hoạt động tạo ra giá trị.

Khoảng cách giữa hai trạng thái sau đó trở thành cơ sở để doanh nghiệp quyết định nên thay đổi quy trình, đào tạo nhân sự, điều chỉnh chính sách hay đầu tư công nghệ.

Bởi chuyển đổi số không bắt đầu từ phần mềm.

Nó bắt đầu từ việc doanh nghiệp đủ hiểu quy trình hiện tại để nhận ra rằng không phải thứ gì đang được làm cũng cần tiếp tục được làm theo cách cũ.