Buổi họp bắt đầu bằng một câu rất quen: "Bên anh cần một dashboard." Không ai nói vậy với ý xấu. Support muốn giảm escalation, sales muốn thấy tình trạng khách hàng rõ hơn, còn management muốn mỗi sáng có một con số để nhìn. Request nghe đủ cụ thể để biến thành ticket.
Một khoảng dừng kiểu Lean BA sẽ làm căn phòng đổi nhịp một chút. Thay vì hỏi dashboard cần những field nào, mình hỏi trước: dashboard này giúp quyết định gì tốt hơn? Vấn đề thật là response time chậm, không rõ owner, nhập liệu trùng, phân khúc khách hàng mơ hồ, hay một process mà dashboard không sửa nổi?
Ghi chú nguồn: Series này được viết từ file Markdown nội bộ về Lean Business Analysis, tổng hợp ý từ Emrah Yayici, PMI và Business Analysis For Dummies. Em xem đây là tư liệu làm việc, không thay thế cho việc đọc các sách gốc.
Business Analysis không chỉ là một job title
Một ý đáng giữ lại từ tư liệu là Business Analysis trước hết là một nhóm hoạt động, rồi sau đó mới là chức danh. Một BA có thể làm việc này chính thức, nhưng trong thực tế Product Owner, Product Manager, Project Manager, systems analyst, designer, QA, tech lead hoặc developer cũng có lúc phải làm BA nếu team cần hiểu vấn đề kinh doanh trước khi định hình solution.
Điều này quan trọng vì nhiều team chỉ nghĩ thiếu BA khi trong org chart không có ai tên là Business Analyst. Thực tế, BA bị thiếu khi team bắt đầu build mà chưa có cách hiểu chung về value, stakeholders, constraint, lựa chọn thay thế và success criteria.
Ví dụ, một team support muốn thêm nút export Excel để lấy danh sách ticket tồn. Nếu chỉ nhìn đây là một requirement UI, developer có thể làm đúng nút export và vẫn không giúp được nhiều. Nhưng nếu cả team cùng làm một chút BA, câu hỏi sẽ đổi thành: ticket tồn vì thiếu dữ liệu phân loại, thiếu người xử lý, hay vì SLA bị đo sai? Có khi thứ cần trước không phải nút export, mà là một cách nhìn rõ ticket nào đang thật sự cần escalation.
| Điểm bắt đầu yếu | Câu hỏi Lean BA | Artifact tốt hơn |
|---|---|---|
| "Build report này." | Report này làm quyết định nào thay đổi? | Decision statement và success metric |
| "Automate process này." | Waste đang nằm ở đâu? | Current-state process và pain points |
| "Đối thủ có feature này." | Nó phục vụ customer need nào của mình? | Problem statement và options |
| "Q3 đã hứa rồi." | Nếu không làm thì risk nào tăng? | Business Case và lý do urgency |
Lean BA bắt đầu từ value
Lean Business Analysis cứ quay lại một câu hỏi đơn giản: điều gì đủ giá trị để xứng đáng với phần attention tiếp theo của team? Value không phải lúc nào cũng là doanh thu. Nó có thể là giảm operational cost, rút ngắn cycle time, giảm lỗi, giảm compliance risk, tăng retention, cải thiện employee experience, hoặc làm rõ vị thế chiến lược.
Ở đây tư duy Lean giúp mình lọc waste trong chính hoạt động analysis: tài liệu không ai dùng, approval lặp lại, đi quá sâu quá sớm, handoff dài, hoặc ceremony làm cho mọi người có vẻ bận nhưng chưa hiểu hơn. Nhưng Lean không có nghĩa là bỏ suy nghĩ. Nó có nghĩa là làm đúng lượng analysis cần thiết để team đủ tự tin đi bước tiếp theo.
Ví dụ, finance team yêu cầu một approval workflow cho vendor payment. Cách làm không Lean có thể là document toàn bộ field, build form, rồi route qua năm cấp duyệt. Cách làm Lean BA sẽ nhìn value stream trước: bao nhiêu invoice bị trễ, lỗi xuất hiện ở bước nào, ai đang chờ ai, approval nào là bắt buộc theo policy, approval nào chỉ tồn tại vì upstream data không đáng tin.
Đôi khi solution là workflow. Đôi khi là master data sạch hơn, threshold rule, policy change, hoặc một exception queue nhỏ hơn.
Một ví dụ khác gần hơn với product: customer support nói người dùng hay hỏi lại phí giao hàng, nên team nghĩ tới việc build chatbot. Nếu nhìn từ value, chatbot chỉ là một option. Value thật có thể là giảm số câu hỏi lặp lại, giảm thời gian checkout bị ngắt quãng, hoặc làm người dùng tự tin hơn trước khi bấm thanh toán. Từ đó team có thể thử hiển thị phí sớm hơn ở cart, thêm tooltip rõ hơn ở checkout, hoặc gửi một email xác nhận dễ đọc hơn trước khi đầu tư vào chatbot.
Needs Assessment giúp tránh giải sai vấn đề
Requirement đắt nhất không phải requirement làm lâu. Requirement đắt nhất là requirement được implement rất đúng, nhưng đúng cho một nhu cầu sai.
Needs Assessment giúp team chậm lại đúng chỗ. Nó thường bắt đầu bằng problem hoặc opportunity statement, rồi đi qua observation, root cause analysis, gap analysis, feasibility và Business Case. Nếu làm gọn, đây không phải bureaucracy. Nó là một lớp bảo hiểm nhẹ chống lại waste có vẻ rất tự tin.
Một pattern hữu ích là đi tới nơi công việc thật sự diễn ra, trong Lean thường gọi là Gemba. Thay vì chỉ nghe "CRM chậm quá", hãy ngồi xem sales rep cập nhật opportunity sau một cuộc gọi khách hàng. Có thể page load không quá tệ, nhưng rep phải copy dữ liệu từ email, tìm đúng account, hỏi operations về contract status, rồi đoán field nào ảnh hưởng pipeline report. Từ "chậm" là đúng, nhưng chưa đủ sắc.
Sau đó dùng root cause analysis vừa đủ. 5 Whys đôi khi đã đủ:
- Vì sao renewal bị trễ? Vì account manager không thấy contract risk đủ sớm.
- Vì sao không thấy sớm? Vì risk signal nằm trong support ticket và billing note.
- Vì sao CRM không hiện các signal đó? Vì integration chỉ sync customer identity và invoice status.
- Vì sao lúc đầu không include risk? Vì project CRM ban đầu tập trung vào sales forecast, không phải renewal operations.
- Vì sao scope bỏ sót renewal operations? Vì customer success không được xem là primary stakeholder.
Requirement cuối cùng vẫn có thể là dashboard, nhưng purpose đã rõ hơn: surface renewal risk từ support, billing và usage signal trước buổi account review.
Với một issue nhỏ hơn, ví dụ người dùng bỏ form đăng ký giữa chừng, Needs Assessment cũng không nên nhảy thẳng vào câu "thêm social login đi". Team có thể xem session replay, hỏi vài người dùng mới, đối chiếu error log và so sánh từng bước của form. Nếu nhiều người dừng ở bước nhập mã số thuế vì không hiểu có bắt buộc không, thêm social login sẽ không chữa đúng chỗ đau. Một dòng microcopy rõ hơn hoặc tách bước nhập thông tin doanh nghiệp sang sau khi tạo tài khoản có thể đáng thử trước.
Business Case là công cụ ra quyết định
Business Case không nhất thiết phải là một tài liệu dày. Công việc của nó là giúp người ra quyết định so sánh options một cách trung thực. Business Case tốt nhiều khi chỉ vài trang, đủ rõ để nói yes, no, hoặc not yet.
Ít nhất, nó nên nói rõ problem, stakeholders bị ảnh hưởng, impact hiện tại, options đã cân nhắc, expected benefits, costs, risks, constraints, assumptions và cách đo success. Khi có nhiều solution option, weighted ranking matrix giúp lộ ra những preference đang ẩn.
| Option | Value | Speed | Risk | Maintainability | Ghi chú |
|---|---|---|---|---|---|
| Build custom workflow | High | Medium | Medium | Medium | Fit process, nhưng tạo ownership cost |
| Configure tool hiện có | Medium | High | Low | High | Tốt cho bước đầu nếu process có thể thích nghi |
| Buy specialist product | High | Medium | Medium | High | Hợp nếu capability này chiến lược và dùng lâu dài |
| Không làm gì | Low | High | High | High | Vẫn là một lựa chọn; risk phải được gọi tên |
Financial analysis như ROI, payback period, NPV, IRR, tangible benefit, intangible benefit và sunk cost awareness có thể làm quyết định chắc hơn. Nhưng con số nên phục vụ judgment, không thay thế judgment. Một spreadsheet rất chính xác nhưng đặt trên assumption yếu có thể nguy hiểm hơn một estimate thô nhưng nói rõ điều mình chưa biết.
Giả sử team đang cân nhắc tự build hệ thống nhắc thanh toán quá hạn. Business Case gọn có thể nói: mỗi tháng có bao nhiêu invoice quá hạn, finance mất bao nhiêu giờ follow-up thủ công, khách hàng khó chịu ở điểm nào, và nếu nhắc sai thì rủi ro quan hệ khách hàng ra sao. Option A là email reminder đơn giản trong tool hiện có, option B là workflow custom nối với billing, option C là chưa automate mà sửa template và owner trước. Khi đặt ba option cạnh nhau, quyết định thường bớt cảm tính hơn: không phải option nào nghe hiện đại nhất cũng là option đáng làm ngay.
Một checklist nhỏ trước khi viết requirement
- Mình có thể nói problem mà chưa nhắc tới solution không?
- Mình đã quan sát công việc hiện tại, hay mới nghe complaint?
- Mình biết ai hưởng lợi, ai phải đổi hành vi, và ai có thể mất gì không?
- Mình đã gọi tên ít nhất hai solution option, bao gồm không làm gì chưa?
- Mình biết evidence nhỏ nhất để chứng minh việc này đáng đi tiếp chưa?
Thói quen bình tĩnh ở đây rất đơn giản: đừng để requirement là câu đầu tiên của cuộc trò chuyện. Bắt đầu từ value, rồi need, rồi options. Requirement sẽ khỏe hơn nhiều nếu nó đến sau những câu hỏi đó.