38 người, 6 hệ thống — gỡ nghẽn không cần AI phức tạp

38 người, 6 hệ thống — gỡ nghẽn không cần AI phức tạp

Khi thông tin nằm rải rác 6 nơi và mỗi lần tìm mất 30 phút, câu trả lời không phải model xịn hơn — mà là nối đúng mạch.

Bối cảnh: tìm thông tin mất lâu hơn giải quyết vấn đề

Bao nhiêu phút mỗi ngày team bạn mất vào việc tìm thông tin — không phải vì thiếu, mà vì nó nằm rải rác quá nhiều nơi?

Aderant — công ty phần mềm quản lý cho ngành luật — có team Cloud Engineering 38 người chịu trách nhiệm vận hành Expert Sierra, nền tảng quản lý pháp lý trên cloud. Mỗi ngày, team nhận hơn 200 ticket hỗ trợ và cam kết vận hành 24/7 toàn cầu.

Vấn đề không nằm ở thiếu người hay thiếu tool. Thông tin cần thiết nằm rải rác trong 6 hệ thống khác nhau — mỗi hệ thống một dashboard riêng, không ai nói chuyện với ai. Mỗi lần engineer cần tra cứu, họ mất 30–45 phút chỉ để tìm đúng chỗ chứa câu trả lời.

Dịch sang thực tế vận hành: nếu mỗi engineer xử lý 5–6 ticket/ngày và mỗi ticket mất thêm 30 phút tìm kiếm, team đang đốt hàng trăm giờ mỗi tuần vào việc... lục tủ.

Khi dòng thông tin phải chạy qua 6 đoạn mạch nối tiếp mà không có bus bar (thanh dẫn chung) nào nối tắt, điện trở cộng dồn — và team quá tải là chuyện sớm muộn.

Quyết định: không build custom, chọn lớp tìm kiếm hợp nhất

Aderant có thể đi con đường quen thuộc: thuê thêm người, hoặc xây hệ thống nội bộ tích hợp tất cả. Nhưng họ chọn khác.

Tháng 10/2025, team triển khai Amazon Q — một unified search layer (lớp tìm kiếm hợp nhất bằng AI) — kết nối cả 6 hệ thống hiện có mà không cần viết lại gì. Bước đầu là một bot nội bộ tên CloudOps Helper, kèm Chrome extension để engineer dùng ngay trong workflow hàng ngày.

Điểm đáng chú ý: họ không cố "AI hóa" toàn bộ quy trình. Họ chỉ giải quyết đúng một nút thắt — tìm thông tin — và để phần còn lại (ra quyết định, xử lý ticket) vẫn do người thực hiện. Không agent phức tạp, không multi-step orchestration. Chỉ search + tổng hợp.

Hệ quả: con số và điều con số không kể hết

Kết quả sau triển khai:

Nhưng hệ quả quan trọng hơn không nằm ở metric: team 38 người giờ xử lý được khối lượng mà trước đó có lẽ cần gấp rưỡi nhân sự nếu tiếp tục làm thủ công. Không ai bị cắt, năng lực vận hành tăng rõ rệt.

Đặt cạnh câu chuyện GM — cùng khoảng thời gian, GM cắt 600 người IT để tuyển người có kỹ năng AI (như mình đã phân tích ở bài trước). Hai hướng đối lập: một bên tối ưu team hiện có bằng AI, một bên thay máu để build AI. Với team quy mô vừa ở Việt Nam — 5 đến 40 người — hướng tối ưu trước gần như luôn khả thi hơn, vì chi phí tuyển dụng và onboard ở thị trường mình không hề rẻ.

Bài học: framework "Circuit Check" cho team Việt Nam

Từ case này, mình rút ra một khung đánh giá để xem team bạn có đang mắc cùng bệnh:

1. Đếm số nguồn thông tin bị tách rời

Giả sử team bạn 8 người, mỗi ngày phải mở: Jira + Confluence + Slack search + Google Drive + monitoring dashboard + internal wiki. Đó là 6 "đoạn mạch" không nối nhau. Nếu con số này ≥ 4, bạn có vấn đề phân mảnh đáng giải quyết.

2. Đo tỷ lệ "tìm" so với "làm"

Thử tracking 1 tuần: mỗi task, bao nhiêu thời gian dành cho tìm thông tin vs. thực sự xử lý? Nếu tỷ lệ vượt 30%, đó là tín hiệu rõ ràng.

3. Xác định cầu chì đang ở đâu

Cầu chì trong mạch điện nổ trước để bảo vệ phần còn lại. Trong team, "cầu chì" thường là người biết nhiều nhất — người mà ai cũng ping khi không tìm được thông tin. Nếu người đó nghỉ phép 2 tuần và team tê liệt, thông tin đang bị khóa trong đầu người thay vì trong hệ thống.

Áp dụng: pilot cho team 3–10 người trong một buổi chiều

Bạn không cần budget lớn để bắt đầu:

Bước 1 — Inventory (30 phút):
Liệt kê tất cả nơi team lưu thông tin. Spreadsheet đơn giản: tên tool, loại thông tin, ai dùng, có API/connector không.

Bước 2 — Chọn unified search layer:

Bước 3 — Pilot 2 tuần:
Chọn 1–2 nguồn quan trọng nhất, kết nối trước. Đo thời gian tìm kiếm trước/sau. Không cần hoàn hảo — chỉ cần engineer thấy nhanh hơn là đủ tín hiệu mở rộng.

Bẫy cần tránh: Đừng cố kết nối hết mọi thứ cùng lúc. Mình từng thấy một team fintech ở TP.HCM hăm hở index toàn bộ Confluence + Jira + 3 repo GitHub trong tuần đầu — kết quả search trả về quá nhiều noise, engineer chán và quay lại hỏi nhau trên Slack như cũ. Bắt đầu với nguồn có giá trị cao nhất, đo, rồi mới mở rộng.

Một dòng mang về

Nói thẳng ra thì: AI đắt nhất không phải AI phức tạp nhất — mà là AI giải sai bài toán. Trước khi hỏi "dùng model gì", hãy hỏi "thông tin đang tắc ở đâu".

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo