Moi móc thông tin đối với Business Analyst

Hello anh em. Bài này mình sẽ note lại những phương pháp moi móc thông tin của BA mà mình biết và đã từng áp dụng.

Đa phần là các phương pháp từ BABOK v3.0, bên cạnh một số dự án mình làm, và một số khác thỉnh giáo từ các bậc tiền bối 

Ô kê, đầu tiên là cái hình dưới đây.

11 phương pháp moi móc thông tin phổ biến của BA

Sơ bộ thì Elicitation là việc moi móc yêu cầu/ moi móc thông tin từ khách hàng.

Có “n” cách để làm việc này. Tuy nhiên, 11 cách sau đây là những cách thường được Business Analyst chúng ta dùng nhiều nhất.

 

1. MEETING

Đầu tiên là phương pháp cực kỳ phổ biến. Có lẽ được dùng đến 96,69% trong các dự án. Thường thì meeting sẽ được chia thành 4 loại như sau:

1.1. Interview

Phỏng vấn 1-1 hoặc phỏng vấn theo nhóm. Nói phỏng vấn vậy cho pho mồ chứ thực ra cũng là một buổi nói chuyện hay trao đổi công việc thôi.

Đây là cách mình dùng rất nhiều. Không biết thì hỏi, đơn giản mà :3

Tuy nhiên, hỏi sao cho khéo, cho đúng kịch bản mới hay. Làm interview thì dễ nhưng kỹ thuật để interview thì mới khó. Anh em có thể trao đổi với khách hàng qua email, skype hoặc gọi điện thoại.

Với mỗi cách, lại có một phương pháp khác nhau. Thậm chí, gọi điện hỏi người ta để làm rõ vấn đề. Nhưng đôi lúc gọi xong lại càng thấy rối hơn :v

1.2. Workshop

Thường thì người BA phải chuẩn bị rất kỹ và nhiều cho buổi workshop này.

Buổi workshop sẽ có sự tham gia của các stakeholders. Và BA hoặc PM sẽ là MC buổi workshop này.

Output của buổi workshop có đạt được đúng như kỳ vọng đề ra ban đầu không phụ thuộc rất nhiều vào sự chuẩn bị.

Thường thì người BA sẽ cho tổ chức một buổi pre-workshop trước đó tầm 3-4 ngày. Nhằm mục đích giới thiệu dự án và cung cấp các materials trước cho stakeholder. Để họ đỡ tốn thời gian ngâm cứu tài liệu khi buổi Workshop chính thức diễn ra.

Output của buổi workshop sẽ được BA tập hợp lại và được tiến hành phân tích theo bốn bước: Organize -> Specify -> Verify -> Validate.

Cần phải phân biệt rõ, thế nào là Interview, thế nào là Workshop, thế nào là Brainstorm và thế nào là Focus Group?

1.3. Brainstorm

Thường thì mình dùng brainstorm khi cả team đang cần ideas cho một vấn đề nào đó.

Anh em sẽ không phê phán hay reject bất cứ ideas nào hết. Và tất cả các ideas, dù củ chuối nhất cũng đều được welcome! Đó mới là brainstorm thật sự.

Lúc vô thế, cần tìm ideas thì nhiều ca oái ăm lắm. Một ý tưởng củ chuối nhưng lại không hề củ chuối tí nào. Còn 1 ý tưởng “ngỡ” là ổn thì càng bàn càng củ chuối.

Quan trọng nhất là anh em phải ghi nhận lại hết. Một là để tạo tinh thần cho đồng đội mình ra tiếp ý tưởng. Hai là còn có cái để mà bàn.

Thường thì trường hợp cả đám ngồi dòm nhau là hay xảy ra nhất. Chứ không bắn ý tưởng đùng đùng như phim ảnh đâu. Nhưng nếu làm đúng, anh em hợp rơ nhau thì brainstorm lại rất phê.

1.4. Focus Group

Hình thức giống interview theo nhóm. Nhưng Focus Group thường tập trung chuyên sâu về 1 nhóm đối tượng hoặc 1 nhóm các vấn đề. Có thể là làm rõ các chức năng, ở từng bộ phận khác nhau.

Ví dụ cần trao đổi về chức năng tích hợp với 1 hệ thống ABC thì cần tổ chức một buổi Focus Group. Với thành phần tham dự là đội ngũ IT quản trị hệ thống của hệ thống ABC, chứ không cần phải các bộ phận khác.

Nhìn chung thì 4 phương pháp: Interview, Workshop, Brainstorm và Focus Group nhìn rất giống nhau, nhưng lại có 1 mục đích khác nhau:

• Interview: 1-1 hoặc 1 với 1 nùi.
• Workshop: truyền đạt thông tin cho một nhóm người cùng một lúc.
• Brainstorm: khi cần tìm lời giải cho một bài toán.
• Focus Group: trao đổi thông tin với 1 nhóm cụ thể.

2. DATA ANALYSIS

Trong bất cứ hệ thống nào thì thông tin là thứ rất quan trọng.

Nếu anh em hiểu được information của Khách hàng gồm những gì, thì đã phần nào hiểu được cách thức hoạt động của khách hàng rồi.

Cụ thể anh em sẽ tìm hiểu về các dữ liệu mà khách hàng đang làm việc. Ví dụ: khách hàng, đơn hàng, loại đơn hàng, sản phẩm, nhóm sản phẩm, dịch vụ, hợp đồng, nhân viên bán hàng,…

Có thể chia nhỏ thành từng đối tượng, và xác định xem thử mỗi đối tượng có những dữ liệu gì.

Hoặc anh em cũng có thể tham khảo các document của khách hàng, để chắt lọc ra những dữ liệu mà họ đang làm (phần 8.4 bên dưới mình sẽ nói cụ thể).

Data Flow Diagram – Đây là một trong các output của mình sau khi lấy yêu cầu (nguồn ảnh: Lucidchart.com)

Thường thì mình thấy phương pháp này được áp dụng trong các dự án maintain hệ thống cũ, upgrade hệ thống cũ. Hoặc thay thế một hệ thống đã lỗi thời mà doanh nghiệp đang sử dụng.

3. INTERFACE ANALYSIS

Ý tưởng cơ bản là hiểu được sự tương tác:

• Giữa người dùng với hệ thống.
• Hoặc giữa các component này với các component khác, phân hệ này với phân hệ khác, hoặc giữa các hệ thống với nhau.

Hiểu và phân tích sự tương tác này, anh em sẽ hình dung được process mà doanh nghiệp đang áp dụng và các dữ liệu mà họ đang lưu trữ. Chí ít là có thể hình dung mờ mờ về những thông tin đó.

Cụ thể mình có thể nói khách hàng:

“Anh ơi, mình đang triển khai hệ thống CRM, zậy thì anh cấp quyền cho em zô cái hệ thống ERP hiện tại đang chạy của mình nha, em zô em xem cái màn hình quản lý khách hàng, xem thử nó có gì ở trỏng, có dữ liệu gì lạ hông, hoặc có cái gì hay hay để em note lại…”

Ví dụ zậyyyy.

 

4. PROTOTYPING

Phương pháp prototyping (dịch ra tiếng Việt là tạo mẫu, là làm thử, là demo, abc, xyz…).

Phương pháp này dùng khi anh em cần cho khách hàng thấy một cái gì đó nó TRỰC QUAN hơn.

Nôm na là nói một cái gì đó tổng quan hay trừu tượng quá, khách hàng sẽ khó mà nắm bắt được.

Do đó, nên nói cụ thể kết hợp demo hệ thống sẽ giúp người ta mường tượng rõ ràng hơn. Như cái này bấm vào sẽ ra gì, tới bước nào. Để hiện cái đó thì bấm cái gì, quy trình đi ra sao.

Đó là khi chúng ta đã sử dụng phương pháp Prototyping.

Một số công cụ hỗ trợ việc thiết kế màn hình, chức năng để phục vụ việc Propotyping như: Axure, Microsoft Visio, Balsamiq Mockups. Cá nhân mình thấy thì:

• Balsamiq Mockups: giao diện rất đẹp, nhưng hơi…”cartoon”. Vì nó mang tính phác thảo, “sketch” là chủ yếu nên như vậy. Dễ dùng. 100% là kéo thả.
  
• Microsoft Visio: một tool huyền thoại cho anh em nào thích vẽ vời. Tool này mình thấy cũng ổn.
  Anh em dùng Visio để vẽ sơ đồ quen rồi thì chuyển qua vẽ màn hình giao diện cũng không khó lắm. Mà có cái là kho thư viện của Visio khá cũ và không nhiều. Cần update lên bản mới hoặc tải về thêm thì dùng mới đủ áp phê.
• Axure: một tool powerful so với mấy cái trên. Ngoài những điểm mạnh của các tool trên, như: dễ dùng, kéo thả, chọn được nhiều library. Thì Axure còn có điểm mạnh là “động” được. Tức là Axure cho phép anh em tạo một màn hình với nhiều nút. Khi nhấn nút này thì nó sẽ ra màn hình nào tiếp, gồm những gì. Nhấn nút tiếp thì ra gì tiếp. Mọi thứ hiển thị y chang hệ thống thật.
  Điểm tuyệt vời nữa là Axure cho phép xuất file kết quả ra html. Điều này có nghĩa là anh em hoàn toàn đem file này chạy trên bất cứ máy nào mà không cần cài đặt Axure. Quá dữ!

Nhưng nhớ chỉ nên sử dụng phương pháp này đối với những requirement phức tạp và thật sự khó giải thích. Đòi hỏi độ chính xác cao cả về functional lẫn non-functional.

Nếu áp dụng prototyping một cách vô tội vạ thì nguy hiểm vô cùng.

Vì nó sẽ cuốn khách hàng vào một mớ bồng bông. Họ sẽ rối nùi lên và hỏi anh em cả nghìn thứ liên quan đến cái prototype đó, sau cùng thì mọi người sẽ dễ đi lệch đường, lệch với mục tiêu ban đầu.

Và tệ nhất là output buổi đó sẽ chả có tí gì như mình kỳ vọng ban đầu hết. Sẽ rất cực cho BA để một lần nữa, hệ thống lại solution cho họ.

Do đó, để dùng tốt phương pháp này thì anh em phải biết khi nào cần trừu tượng, khi nào cần trực quan, đó chính là Analytical Thinking 

 

5. BUSINESS RULES ANALYSIS

Thường thì doanh nghiệp đều có các quy định riêng.

Trong quá trình chuyển giao từ trạng thái as-is sang to-be, anh em cần phải bám theo những quy định và luật lệ này của khách hàng.

Do đó, người BA cần phải xác định được các System Rules sẽ có trong hệ thống. Các System Rules này sẽ đảm bảo hệ thống tuân thủ được đúng các policies và rules của công ty hay không.

Phương pháp này nói đến việc tham khảo và phân tích các policies và rules của khách hàng. Đây là một trong những kênh vô cùng có giá trị với Business Analyst trong quá trình moi móc thông tin.

Nắm rõ được quy định và luật của công ty, anh em sẽ tránh khả năng làm sai. Làm sai là làm hệ thống hoạt động sai. Làm rõ ngay từ đầu – đỡ cực về sau!

 

6. OBSERVATION

Observation là phương pháp quan sát các công việc mà end user làm hằng ngày.

Đối với phương pháp này, BA sẽ tiếp thu thông tin bằng mắt. Quan sát và chỉ quan sát. Điều này có vẻ đơn giản nhưng không đơn giản chút nào, vì những lý do sau:

6.1. Xu hướng hơi giả tạo và làm khác đi 

Thường thì bà con có vẻ làm khác đi một chút khi bị người khác tập trung quan sát.

Do đó người BA cần phải có cách tiếp cận khéo léo, tránh thu hút sự tập trung của họ. Cũng như vẫn đảm bảo quan sát được toàn vẹn và đầy đủ nhất hành vi của end users.

Tránh tương tác trực tiếp. Anh em đừng nhiệt quá như là bay vô làm phụ người ta :)) Như vậy sẽ làm mất đi tinh thần “chân thật” của đối tượng.

6.2. Tốn thời gian

Phương pháp này thường sẽ không đơn giản như chúng ta nghĩ.

Bởi vì không phải chỉ quan sát 15-20 phút là xong. Đó có thể là quan sát cả một quy trình hay thậm chí có thể là cả một ca làm việc.

Và không chỉ quan sát một người. Chúng ta cần sự so sánh hành vi giữa nhiều người khác nhau trong cùng vai trò, để output có được một cách chính xác và chân thật nhất.

6.3. Tốn luôn cả năng lượng

Chắc chắn là anh em sẽ rất mệt. Có mấy lần mình qua công ty khách hàng ngồi cả ngày mà oải lắm.

Ngồi support rồi quan sát người ta làm. Liệu solution của mình có map vào thực tế được hay chưa. Lâu lâu gặp trúng mấy case oái ăm cũng ớn lắm.

Nói chung là mệt chứ không ngon ăn gì đâu. Sau đó về còn phải tổng hợp, rồi hệ thống lại toàn bộ những gì quan sát được nữa.

Do đó anh em phải cân nhắc thật kỹ nếu muốn sử dụng cách này hiệu quả.

7. BENCHMARKING

Bench là một cái bảng mẫu. Marking là đánh dấu, là cho điểm.

Nói Bench Marking cho nguy hiểm vậy thôi, chứ thực chất nó là phương pháp so sánh. So sánh nhiều đối tượng dựa trên một cách khung mẫu, bảng mẫu.

So sánh quy trình A với quy trình B, hệ thống A với hệ thống B, sản phẩm A với sản phẩm B, hay nói cách khác là solution A với solution B. Nắm rõ B, mình sẽ nắm gần rõ A. Và ngược lại. Hiểu rõ A, mình sẽ hiểu… gần rõ B.

 

8. CÒN LẠI

Những phương pháp này chắc cũng quá quen thuộc với anh em rồi.

8.1. Mind Mapping

Phương pháp này mình nghĩ anh em cũng hay dùng. Mình cũng vậy, nhưng đôi lúc mình thấy giống vẽ… bùa hơn là vẽ mind map :))

Mình thích dùng mind mapping vì nó rất dễ tạo cảm hứng. Người ngoài nhìn vô thấy vẽ vời quá trời, nhìn cho nó nguy hiểm 

 

8.2. Process Analysis and Modelling

Một trong những phương pháp truyền thống và cơ bản nhất.

Tức là anh em sẽ dùng Interview, Questionaire hoặc bất kỳ các phương pháp nào ở trên, để moi móc thông tin khách hàng về QUY TRÌNH NGHIỆP VỤ của họ.

Sau đó thì anh em sẽ modelling, tức là mô hình hóa nó lại bằng BPMN hoặc UML.

Cái này thì ai cũng dùng, ai không dùng… cũng được :)) nhưng có vẻ hơi hiếm. BA mà không modelling thì chắc không có đâu anh em.

 

8.3. Survey

Nếu cần khai thác thông tin trên diện lớn và lấy ý kiến tập thể thì Survey là phương pháp phù hợp nhất.

Nhưng vì trên diện lớn, nên chất lượng kết quả Survey có thể không đạt chất lượng cao lắm. Đòi hỏi sau giai đoạn khảo sát, anh em BA phải chịu khó ngồi lọc lại dữ liệu.

Lúc trước mình có làm một dự án cho 1 tập đoàn xăng dầu Việt Nam. Nó có tới hơn 2 nghìn điểm bán lẻ. Và mỗi điểm bán lẻ là cả mấy chục phiếu khảo sát.

Lúc khảo sát về thì không phải dữ liệu nào cũng đúng cả. Chạy số liệu thông tin ra tùm lum tùm la hết, rất là khó hiểu. Team mất gần cả tháng để xử lý mớ data này.

Dựa vào nhiều thông tin bên lề mới xác định được cái nào đúng hoàn toàn, cái nào tham khảo và cái nào là sai lệch.

Rồi sau đó mới dựa vào kết quả Survey mà đi tiếp được.

Do đó làm Survey rất cần kinh nghiệm của các bật tiền bối trong việc build bảng câu hỏi.

Bảng câu hỏi có 15 câu không có nghĩa là mình kỳ vọng 15 câu đó, người làm khảo sát sẽ trả lời đúng hết.

Có những câu mình biết họ sẽ “né” hoặc cố tình ghi sai. Nhưng hỏi sao cho họ dễ trả lời, tránh hỏi trực diện là cả một… bầu trời nghệ thuật.

 

8.4. Document Analysis

Phương pháp khá cổ điển. Cụ thể là anh em đọc tất cả, tuốt tuồn tuột tất cả những document mà khách hàng share cho mình.

Nhưng để làm tốt phương pháp này, anh em phải có kỹ năng đọc tốt và giữ mình không đi lạc vào mớ bòng bong của khách hàng.

Đặc biệt là tài liệu của các doanh nghiệp… nhà nước.

Cũng trong dự án làm cho công ty xăng dầu mình có kể ở trên. Công ty này có rất nhiều cửa hàng, đại lý nên việc tổ chức là không hề đơn giản tí nào.

Kéo theo đó là bộ thập cẩm các quy trình cũng rất “màu mỡ” và “phong phú”. Từ quy trình xuất kho, nhập kho, chuyển ca, sục bể, xả gió đến quy trình pha chế, tùm lum tùm la hết.

Lúc đó tụi mình đọc rất nhiều tài liệu. Nhiều lúc đọc mấy tài liệu mà mặt ngu thấy rõ. Đó là lúc dùng phương pháp Document Analysis.

 

9. Các bước moi móc thông tin

Các bước để moi móc thông tin

9.1. Prepare 

Phải chuẩn bị thật tốt. Với mỗi phương pháp trên đều có cách chuẩn bị khác nhau. Chuẩn bị sao cho phù hợp và hiệu quả với từng phương pháp là cái mà mình nên hướng đến.

Chuẩn bị luôn là điều quan trọng nhất. FAIL PREPARE = PREPARE FAIL.

Fail prepare = Prepare fail

9.2. Conduct 

Đầu tiên là luôn nắm rõ mình cần gì và mục tiêu của mình là gì. Đừng để rơi vào tình trạng: “tôi là ai và đây là đâu” thì oải lắm.

Thứ hai là mỗi phương pháp đều có cách tiếp cận riêng. Chọn cách tiếp cận sai là coi như thua.

Đúng phương pháp mà sai cách tiếp cận thì là tiêu chắc chắn. Anh em cố gắng chú ý quan sát đối tượng rồi chọn cách tiếp cận cho phù hợp.

Và, cần phải tinh chỉnh cách tiếp cận sao cho phù hợp ngay cả TRƯỚC, TRONG và SAU quá trình moi móc thông tin.

9.3. Document 

Ở bước này, BA có nhiệm vụ sắp xếp lại các tài liệu thu thập được. Vì dữ liệu thu thập được là vô cùng “thập cẩm”.

Có loại thì ghi note, có loại thì hình ảnh, có loại là video hay có loại là ghi âm. Tất cả đều rất lộn xộn và chưa được hệ thống hóa. BA cần phải sắp xếp mọi thứ lại cho ngăn nắp và gọn gàng để đi đến bước tiếp theo.

9.4. Confirm 

BA sẽ gửi những tài liệu này cho stakeholder để họ xác nhận: “à, đây đúng là những gì mà chúng ta đã trao đổi”.

Mục đích của bước này là đảm bảo thông tin mà chúng ta elicit thật sự chính xác. Và đảm bảo được sự đồng thuận giữa các stakeholder với nhau.

Cái này quan trọng lắm anh em.

Cái gì mà đã được confirm thì cũng đều phải document lại hết. Tránh trường hợp khách hàng “lộn cái bàn” sau này :3

.

.

.

 

That’s all. Chém gió dài quá rồi. Mình sẽ summarize lại một số phương pháp moi móc thông tin cơ bản như sau:

• Interview: khi cần những thông tin chung chung hoặc nói về những painpoints lớn của khách hàng, abc, xyz…
• Focus Group: nhắm tới một vấn đề cụ thể, chuyên sâu cho một nhóm đối tượng nào đó.
• Brain Storming: cần sự bùng nổ về ý kiến để giải quyết vấn đề nào đó, output sẽ là một rổ ideas.
• Observation: hiểu về môi trường làm việc thực tế, tận mắt chứng kiến luồng công việc và xác minh lại những thứ mà mình đang nghi ngờ khách hàng giấu hổng chịu khai.
• Prototyping: mang lại sự trực quan cho khách hàng.
• Surveys/ Questionaires: chỉ nên dùng trong 1 giai đoạn ngắn, khó khăn trong việc kết nối, và cần thông tin ở nhiều chiều kích khác nhau.

Bái baiii. Hẹn gặp anh em ở các note sau!!!