# Thực hành: vẽ quy trình thật của khách trước khi để AI tự động hoá nó

> Quy trình trong tài liệu và quy trình nhân viên đang thật sự làm hiếm khi trùng nhau, và agent bạn xây sẽ hỏng đúng ở những chỗ hai bản đó lệch nhau.

Bản gốc: https://fdetimes.net/vi/bach-khoa/thuc-hanh-ve-quy-trinh-nghiep-vu-truoc-khi-tu-dong-hoa/

Trong một dự án logistics, công ty tư vấn Edana vẽ lại quy trình tích hợp dữ liệu của khách và tìm ra bốn lượt trao đổi email không hề có trong tài liệu. Kèm theo đó là các file dùng chung mà nhân viên mở ra để sửa dữ liệu bằng tay trước khi nạp vào hệ thống.

Nếu đội kỹ thuật tự động hoá theo sơ đồ chính thức, những bước này sẽ biến mất khỏi luồng mới và dữ liệu sai sẽ đi thẳng vào hệ thống.

Đến khách hàng nào, bạn cũng nên tính trước rằng chuyện này sẽ xảy ra. Edana nhận xét rằng nhân viên tự thích nghi với ràng buộc: họ đi vòng qua công cụ hoặc tự chế cách làm tắt cho nhanh.

Vì thế quy trình thật lệch khỏi quy trình trên giấy, và theo Edana, số hoá mà không nhìn thấy những khoảng lệch đó thì chỉ là chuyển mớ hỗn độn sang dạng số.

Bài này hướng dẫn bạn vẽ một bản đồ quy trình as-is theo đúng thứ tự cần làm. Bạn không cần phần mềm chuyên dụng. Một trình soạn văn bản, một bảng tính và quyền ngồi cạnh người làm việc thật là đủ.

## Bạn sẽ dựng được gì?

Kết quả cuối cùng gồm ba thứ: danh sách mọi bước (kể cả bước thủ công), sơ đồ swimlane theo vai trò, và danh sách điểm ma sát đã gắn nhãn. Trong ba thứ đó, danh sách điểm ma sát là phần đáng giá nhất.

Edana viết rằng việc vẽ bản đồ làm lộ ra các điểm ma sát và gợi ý cách đơn giản hoá hoặc loại bỏ chúng trước khi tự động hoá bất cứ thứ gì.

Để dễ theo dõi, các ví dụ dưới đây dùng một tình huống giả định: một nhà phân phối nhận đơn từ đại lý, kế toán kiểm công nợ, kho xuất hàng. Khách muốn một agent tự đọc đơn và tạo phiếu xuất.

## Bước 1: Gom bằng chứng trước khi hỏi ai

Hướng dẫn mô hình hoá as-is của Visual Paradigm khuyên bắt đầu bằng việc thu thập mọi bằng chứng sẵn có: biểu mẫu, email, log hệ thống, sổ tay chính sách. Với tình huống giả định, bạn sẽ xin mẫu đơn hàng, vài chuỗi email giữa sales và kế toán, export log từ phần mềm kế toán và tài liệu quy trình nếu có.

Kiểm tra sau bước này: bạn có ít nhất một bản ghi thật cho mỗi bộ phận tham gia. Nếu bộ phận nào chỉ có tài liệu mà không có dấu vết thật, hãy đánh dấu lại vì đó thường là nơi quy trình thật lệch nhiều nhất.

## Bước 2: Phỏng vấn bằng câu "kể lại"

Đừng hỏi "Anh có làm đúng quy trình không?". Câu đó chỉ nhận về câu trả lời người ta nghĩ bạn muốn nghe. Visual Paradigm gợi ý một câu mở, đại ý: "Kể tôi nghe chuyện gì xảy ra khi khách đặt một đơn hàng."

Khi người được phỏng vấn nói "rồi em nhập vào hệ thống", hãy hỏi tiếp: nhập từ đâu, nếu thiếu thông tin thì làm gì, có phải hỏi ai không. Mỗi câu "rồi thì…" là một bước tiềm năng. Hãy phỏng vấn riêng từng vai trò, vì sales và kế toán thường kể hai phiên bản khác nhau của cùng một đơn hàng.

## Bước 3: Liệt kê mọi bước, chưa cần đẹp

MockFlow khuyên liệt kê hết các bước trước, đừng cố làm bản đồ hoàn hảo ngay. Mẫu dưới đây là một bảng văn bản đơn giản, tự soạn để minh hoạ, không phải chuẩn ký hiệu nào. Ba dòng đầu:

```text
# | Vai trò | Việc làm                     | Ghi chú
1 | Sales   | Nhận đơn qua điện thoại/chat | ngoài tài liệu
2 | Sales   | Gõ lại đơn vào Excel         | nhập lần 1
3 | Sales   | Email nhờ kế toán kiểm nợ    | bước ngầm
```

Ba dòng tiếp theo:

```text
4 | Kế toán | Kiểm nợ, trả lời email       | phần mềm KT
5 | Sales   | Nhập đơn vào phần mềm BH     | nhập lần 2
6 | Kho     | Xuất hàng theo phiếu         | phần mềm kho
```

Visual Paradigm nói rõ: việc nào làm thủ công qua email thì phải xuất hiện trên mô hình. Dòng 3 là loại bước người ta hay bỏ qua vì "nó không phải quy trình". Thực ra đó chính là quy trình.

Kiểm tra: mọi lượt chuyển việc giữa hai người đều có một dòng riêng trong bảng.

## Bước 4: Thêm ngoại lệ, làm lại và điểm chờ

Happy path chỉ là một phần câu chuyện. MockFlow nhắc phải ghi cả vòng làm lại, ngoại lệ, trạng thái chờ và điểm nghẽn. Hãy quay lại từng dòng và hỏi: chuyện gì xảy ra khi bước này sai?

Trong tình huống giả định, có thể bạn phát hiện: nếu đại lý vượt hạn mức nợ, kế toán chuyển email cho trưởng phòng duyệt, và đơn nằm chờ đến khi có trả lời. Agent bạn định xây sẽ gặp đúng trường hợp này. Nếu bản đồ không có nhánh đó, agent sẽ không biết phải làm gì.

## Bước 5: Xếp swimlane rồi đem đi kiểm chứng

Khi quy trình đi qua nhiều vai trò, phòng ban hoặc hệ thống, MockFlow khuyên dùng swimlane. ManageEngine mô tả workflow như một chuỗi giai đoạn, nối với nhau bằng các hành động trung gian đưa công việc từ giai đoạn này sang giai đoạn kế tiếp. Nhìn theo cách đó, việc xếp làn sẽ dễ hơn.

Bản phác thảo dạng văn bản (đã đơn giản hoá, số trong ngoặc khớp với bảng ở Bước 3):

```text
[Sales]        (1) Nhận đơn → (2) Gõ Excel → (3) Email hỏi nợ
↓
[Kế toán]                          (4) Kiểm nợ → trong hạn mức? ── có ──┐
└ không              │
↓               │
[Trưởng phòng]                                   Duyệt (CHỜ) ────────────┤
↓
[Sales]        (5) Nhập phần mềm BH ←────────────────────────────────────┘
↓
[Kho]          (6) Xuất hàng
```

Cả hai nhánh, có hay không cần duyệt, đều quay về Sales để nhập phần mềm bán hàng rồi mới sang Kho. Nhìn vào swimlane, bạn thấy ngay đơn hàng chạy qua lại giữa các làn bao nhiêu lần. Mỗi lần đổi làn là một chỗ có thể chậm, mất thông tin hoặc phải nhập lại.

Nhưng bản đồ do bạn vẽ vẫn chỉ là giả thuyết. Visual Paradigm khuyên đưa bản nháp as-is ra một buổi workshop với chính những người vận hành quy trình. Hãy in to hoặc chiếu lên màn hình và để họ cầm bút sửa trực tiếp.

Câu hỏi hiệu quả nhất trong buổi này là "Có chỗ nào sai không?", không phải "Thế này đúng chưa?". Kiểm tra: mỗi vai trò trên swimlane đã có ít nhất một người xác nhận làn của mình.

## Bước 6: Gắn nhãn ma sát trước khi chọn chỗ cho AI

Edana cảnh báo rằng hiện đại hoá một quy trình chưa được chẩn đoán sẽ mang theo mọi cách làm tắt: nhập liệu lặp lại, duyệt nhiều tầng, đường vòng. Vì vậy, trước khi viết dòng code agent nào, hãy đánh dấu từng điểm ma sát:

```text
Bước 2 + 5   [NHẬP-LẶP]  đơn được gõ hai lần vào hai hệ thống
Bước 3       [EMAIL-NGẦM] kiểm nợ qua email, không có dấu vết trong hệ thống
Nhánh duyệt  [CHỜ]        đơn đứng yên đến khi trưởng phòng trả lời
```

Danh sách này thay đổi đề bài. Có thể khách không cần agent đọc đơn mà cần bỏ bước gõ Excel trước, rồi mới để agent lo phần còn lại.

**Điểm mấu chốt:** Bản đồ as-is có giá trị khi nó cho bạn biết cần bỏ bước nào trước, không phải khi nó vẽ đẹp.

## Những lỗi hay gặp

Lỗi phổ biến nhất là vẽ theo tài liệu rồi gọi đó là as-is. Lỗi thứ hai là chỉ phỏng vấn quản lý: họ mô tả quy trình như nó nên chạy, còn nhân viên mới là người biết nó đang chạy thế nào. Lỗi thứ ba là bỏ ngoại lệ vì "hiếm khi xảy ra".

Trong khi đó, ngoại lệ chính là nơi agent dễ hỏng nhất khi lên production.

## Kỹ năng này hiện ra thế nào trong công việc FDE?

Sáu bước trên dựa trên kỹ năng elicitation của business analyst: phỏng vấn, mô hình hoá, phân tích kịch bản. Khoá Requirements Gathering in Business Analysis của Microsoft trên Coursera dạy đúng các phần này và có cả một project viết yêu cầu cho một quy trình thủ công.

Đó là chỗ luyện tập tốt nếu bạn chưa từng làm.

Khi đọc mô tả công việc, bạn nên để ý những đoạn nói về làm việc trực tiếp với bộ phận vận hành của khách, tìm hiểu hay vẽ lại quy trình nghiệp vụ. Nếu thấy những yêu cầu như vậy, hãy đưa kinh nghiệm vẽ quy trình lên phần đầu CV. Đừng ghi chung chung "phân tích nghiệp vụ".

Hãy ghi số bước thủ công bạn tìm ra và bạn đã loại bỏ bước nào trước khi tự động hoá.

Agent giỏi đến đâu cũng chỉ chạy theo quy trình bạn đưa cho nó. Nếu bạn đưa quy trình trên giấy, nó sẽ làm sai ngay từ email ngầm đầu tiên mà tài liệu không ghi.

**Thử ngay tuần này:**

- Chọn một quy trình ở công ty bạn (duyệt chi phí, onboarding, xử lý ticket), hỏi một đồng nghiệp đúng câu 'kể mình nghe chuyện gì xảy ra khi…' rồi ghi lại mọi bước, kể cả email và file Excel.
- Vẽ bản đồ đó thành swimlane trong một file văn bản, gắn nhãn ít nhất ba điểm ma sát, rồi ngồi 30 phút với người làm để họ sửa.
- Viết một dòng trong CV mô tả kết quả theo dạng: 'vẽ quy trình as-is, phát hiện N bước thủ công không có trong tài liệu, loại bỏ trước khi tự động hoá'.

## Nguồn

- [Business Process Mapping: Why It's Essential Before Digitizing, Automating or Developing Custom Software](https://edana.ch/?p=51813)

- [Mapping the As-Is Process (BPD): Seeing Reality Clearly](https://skills.visual-paradigm.com/?p=434)

- [How to Create a Process Map: A Step-by-Step Guide for Teams](https://mockflow.com/blog/how-to-create-a-process-map)

- [What is enterprise workflow management?](https://www.manageengine.com/appcreator/enterprise-workflow-management.html)

- [Requirements Gathering in Business Analysis](https://www.coursera.org/learn/requirements-gathering-in-business-analysis)