Khi nào nên dùng IT Current-State Diagram?

Doanh nghiệp muốn triển khai AI Assistant cho đội kinh doanh, thay ERP hoặc migrate lên cloud. Nhưng trước khi nói đến hệ thống mới, có một câu hỏi thường khó trả lời hơn tưởng tượng:

Hệ thống IT hiện tại thực sự đang gồm những gì và chúng đang kết nối với nhau thế nào?

Sales có thể nói dữ liệu nằm trong CRM. Kế toán lại dùng một phần mềm riêng. Chi nhánh vẫn gửi Excel. Đội chăm sóc khách hàng còn một mailbox khác. Một số luồng đã có API, trong khi một số bước vẫn export CSV hoặc copy/paste thủ công.

Nếu mỗi người đang hình dung một phiên bản khác nhau của hệ thống hiện tại, việc thiết kế hệ thống tương lai rất dễ bắt đầu từ giả định sai.

Trong trường hợp này, IT Current-State Diagram là một cách nhìn phù hợp.

Current-state là gì?

Current-state, còn thường được gọi là as-is, là cách mô tả trạng thái đang tồn tại và vận hành thực tế hôm nay.

Điểm cần lưu ý là “current-state” không phải một notation cứng như Flowchart, Sequence Diagram hay UML State Machine. Nó gần với một view/baseline hơn: chọn đúng những thành phần của hiện trạng cần nhìn để hỗ trợ một quyết định cụ thể.

Trong Enterprise Architecture, current state thường được tách với future state hoặc to-be state. Current state trả lời “chúng ta đang ở đâu?”, còn future state mô tả “chúng ta muốn đi tới đâu?”.

IT Current-State Diagram giúp trả lời câu hỏi gì?

Một current-state view về IT thường giúp làm rõ:

• Những ứng dụng và hệ thống nào đang thực sự được sử dụng?
• Dữ liệu chính đang nằm ở đâu?
• Hệ thống nào đang tích hợp bằng API, message, batch hoặc file?
• Chỗ nào vẫn phụ thuộc vào thao tác thủ công?
• Phần nào nằm trên SaaS hoặc cloud, phần nào vẫn on-premise?
• Có dependency, hệ thống legacy hoặc constraint nào phải tính tới?
• Một dữ liệu có đang tồn tại ở nhiều nơi hay không?

Không phải diagram nào cũng cần đưa tất cả những thứ trên vào cùng lúc.

Nếu mục tiêu là rà soát application landscape, chỉ cần tập trung vào ứng dụng và integration. Nếu chuẩn bị cloud migration, hạ tầng và dependency sẽ quan trọng hơn. Nếu chuẩn bị làm AI, vị trí dữ liệu và quyền truy cập lại trở thành trọng tâm.

Ví dụ: chuẩn bị triển khai AI Assistant cho đội kinh doanh

Giả sử một doanh nghiệp vừa muốn xây AI Assistant hỗ trợ đội kinh doanh.

Nghe qua, bài toán có vẻ là:

Nhân viên đặt câu hỏi → AI đọc dữ liệu khách hàng → trả lời.

Nhưng khi map current-state, bức tranh thực tế có thể là:

• Sales làm việc trên một CRM SaaS.
• Chi nhánh duy trì thêm file Excel hoặc Google Drive.
• Đội CSKH tiếp nhận thông tin qua một mailbox chung.
• CRM gửi một phần dữ liệu sang Dashboard bằng API.
• Kế toán dùng phần mềm chạy on-premise.
• Một số dữ liệu từ CRM và Excel được export CSV rồi nhập sang kế toán thủ công.
• Thông tin khách hàng vì thế có thể xuất hiện ở nhiều hệ thống.

Lúc này, câu hỏi “dùng model AI nào?” chưa phải câu hỏi đầu tiên.

Trước tiên cần biết AI sẽ đọc nguồn nào, nguồn nào là đáng tin nhất, có thể truy cập qua API hay không, dữ liệu nào vẫn bị khóa trong hệ thống on-premise và luồng thủ công nào có thể làm dữ liệu bị chậm hoặc lệch.

Đó là giá trị của current-state: đưa thực tế vận hành ra khỏi trí nhớ của từng phòng ban và đặt nó lên cùng một mặt phẳng để mọi người cùng nhìn.

Khác gì với Architecture Diagram và High-Level Diagram?

Ba loại góc nhìn này khá dễ bị dùng lẫn.

Architecture Diagram

Architecture Diagram phù hợp khi cần hiểu một hệ thống gồm những thành phần nào và chúng liên kết với nhau ra sao.

Nó có thể mô tả current-state hoặc future-state. Từ “architecture” nói về cấu trúc; “current-state” nói về thời điểm và thực tế đang tồn tại.

High-Level Diagram

High-Level Diagram ở ngày 2 tập trung vào những giai đoạn lớn của một hành trình.

Ví dụ:

Nguồn dữ liệu → Tiếp nhận → Lưu trữ → Xử lý → Dashboard

Nó cố tình bỏ qua nhiều chi tiết.

IT Current-State Diagram

Current-state tập trung vào câu hỏi khác:

Hệ thống IT hôm nay thực sự đang như thế nào?

Vì thế nó thường cần giữ lại những thứ mà future-state hay slide high-level muốn làm sạch đi: hệ thống legacy, file Excel, manual handoff, ranh giới SaaS/on-premise, duplicate data hoặc integration chưa hoàn chỉnh.

Những chi tiết đó có thể không đẹp, nhưng lại rất quan trọng khi chuẩn bị thay đổi hệ thống.

Khi nào nên dùng?

Current-state đặc biệt hữu ích trước những việc như:

• triển khai AI vào một quy trình hiện có;
• thay ERP/CRM;
• cloud migration;
• tích hợp nhiều hệ thống;
• hợp nhất dữ liệu;
• tái thiết kế kiến trúc;
• audit công nghệ hoặc application portfolio.

Nó tạo ra một baseline để thảo luận. Sau khi mọi người thống nhất “đây là thứ đang có”, việc thiết kế future-state mới có nền tảng rõ ràng hơn.

Khi nào không cần vẽ quá lớn?

Current-state cũng không toàn năng.

Nếu chỉ cần hiểu một service nhỏ, một Architecture Diagram đơn giản có thể đủ. Nếu cần mô tả từng bước xử lý, Process Diagram hoặc Flowchart phù hợp hơn.

Một lỗi phổ biến là cố vẽ “toàn bộ IT của công ty” vào một trang. Kết quả thường quá dày để dùng cho bất kỳ quyết định nào.

Current-state tốt không nhất thiết là current-state đầy đủ nhất.

Nó nên đủ đúng và đủ chi tiết cho câu hỏi đang cần trả lời.

Trước khi vẽ hệ thống tương lai, hãy bắt đầu bằng việc nhìn đúng hệ thống đang tồn tại.

---

Series Diagram Design: Ngày 3/45 · Bài trước: Khi nào nên dùng High-Level Diagram? · Bài tiếp theo: Deployment Diagram

Nguồn tham khảo

• WA Enterprise Architecture Framework — Current State Architecture Views.
• State of Hawaii Enterprise Architecture — Current State / Future State.
• Documenting Current-State Architecture: Clarity Before Change.