Cùng tìm hiểu về “Business Analyst là gì và làm những gì?” theo góc nhìn của “thinhnotes” nhé.
Hế lô a ji nô mô tô anh em.
Business Analyst là gì?
Mình thấy anh em vẫn hay nói Business Analyst là cầu nối, giúp kết nối và truyền đạt yêu cầu của khách hàng với đội ngũ lập trình. Thực ra hiểu vậy cũng đúng, nhưng rất tối nghĩa và không thoát được hết ý nghĩa của nghề BA.
Lúc trước mình cũng nghĩ như vậy. Mình còn nghĩ công việc Business Analyst chỉ tồn tại trong ngành IT nữa. Nhưng thực chất thì BA không phải là một chức danh công việc. Và nó cũng không chỉ đơn thuần như một chiếc cầu nối mà mọi người thường hay nói.
Business Analyst là gì và làm những gì? Bài này mình sẽ chia sẻ về những gì mình hiểu và áp dụng thực tế cho anh em 😎 Lét gâuuu.
1. Business Analyst là gì
Cụ thể thì Business Analyst sẽ là người thực hiện chính xác quy trình trên.
1.1. Business Analyst Concept
Cụ thể nhé. Từ các vấn đề mà doanh nghiệp đang gặp phải, doanh nghiệp có mục tiêu phải giải quyết được các vấn đề này. Các mục tiêu đó gọi là Business Objectives.
Từ các Business Objective, BA sẽ làm việc với Stakeholders để đưa ra các Solution cụ thể. Các Solution này phải đáp ứng được yêu cầu của các Stakeholder.
Sau đó, BA cùng đồng bọn sẽ xây dựng và triển khai Solutions đó cho doanh nghiệp. Giai đoạn triển khai này gọi là Transition. Sẽ “biến” hiện trạng của doanh nghiệp ở thời điểm hiện tại thành trạng thái mong muốn trong tương lai.
Và lúc này, các vấn đề mà doanh nghiệp gặp phải đã được giải quyết.
Do đó, Business Analyst là một loại công việc, người nào làm một loạt các việc trên sẽ được gọi là Business Analyst.
Mình nghĩ có nhiều anh em vẫn nghĩ trong đầu là: BA phải nói được ngôn ngữ kinh doanh và ngôn ngữ lập trình. Hiểu được cả các khái niệm kinh doanh, lẫn các khái niệm đặc thù trong ngành IT, như database, web service, API, cloud, bla bla…
Nên mọi người vẫn cứ nghĩ: nhắc đến BA là nhắc đến “cầu nối” hay “người phiên dịch”. Nhưng như mình nói thì đó chỉ là điều kiện cần của BA thôi chứ không nói lên được nghề này là gì và làm những gì.
Và solution không chỉ là một hệ thống, phần mềm hay một giải pháp công nghệ nào đó. Mà Solution có thể là bất kỳ điều gì. Từ việc thay đổi chính sách, quy trình trong doanh nghiệp. Hay đơn thuần chỉ là training lại cho doanh nghiệp mình.
Miễn giải quyết được Business Objectives thì đó đều là Solutions 🙂
1.2. Một vài ví dụ
Có một công ty muốn mở rộng thị trường.
Họ cần quản lý khách hàng và các cơ hội kinh doanh một cách tốt hơn. Thay vì thời điểm hiện tại, tất cả đều được quản lý bằng excel. Thì đâu đó, một hệ thống CRM có thể giúp sẽ họ quản lý được tốt hơn những thứ trên.
Business Objective ở đây là muốn quản lý tốt hơn khách hàng và các cơ hội kinh doanh. BA cần phải nhìn ra điều này và cung cấp solution chính là việc áp dụng hệ thống CRM vào bộ máy hoạt động của công ty đó.
Tuy nhiên đâu dễ ăn của ngoại :3
Không phải lúc nào Business Objectives cũng rõ ràng và đơn giản như vậy. Đa phần thì khách hàng họ cũng không biết họ muốn gì, hoặc họ muốn quá nhiều. Khiến cho công việc Business Analyst cần phải có nhiều đồ nghề hơn nữa, để nhìn ra được, đâu mới là Business Objectives thật sự của khách hàng.
Họ nói cần A không có nghĩa là họ đang thiếu A. Hoặc họ nói cần A nhưng thực chất lại là cần B.
Oái ăm là ở chỗ này.
Do đó để phát hiện chính xác vấn đề của họ đã khó, đề xuất solutions cho phù hợp lại càng khó hơn. Nên đâu có chuyện chỉ đơn giản như người… phiên dịch 😀
Một điểm nữa là không phải lúc nào, việc áp dụng một hệ thống mới cũng là phương án hay. Và việc sử dụng Excel cũng là cách hoạt động lỗi thời cả.
Có rất nhiều doanh nghiệp lớn bên Nhật Bản vận hành cả một bộ máy chỉ với những sheet Excel. Do họ “trưởng thành”, và họ biết họ cần gì, và bao nhiêu là đủ với họ.
Excel là một công cụ tuyệt vời với khả năng vô tận của nó. Thậm chí Bill Gates còn chưa chắc biết hết chức năng của Excel mà 😂
Kể chuyện này anh em nghe mất hồn chơi.
Cũng bên Nhật Bản, có một ông tên Tatsuo Horiuchi. Ông này là họa sĩ nhưng không hiểu vì sao mà ổng không vẽ trên giấy bút hay các phần mềm đồ họa khác như mọi người. Mà ổng vẽ bằng……Excel.
Ổng chọn Excel như giải pháp để ổng thể hiện ý tưởng của mình. Một giải pháp mà không ai ngờ được.
1.3. Business Analyst xuất hiện ở mọi ngóc ngách trong cuộc sống
Thiệt đúng là như zậy. Công việc BA tồn tại ở mọi ngóc ngách trong cuộc sống của mình.
Ví dụ bữa nọ đi làm về, xe hết xăng.
Rõ ràng là ngay lúc đó anh em muốn: tìm trạm xăng >> đổ xăng >> chạy tiếp về nhà.
Vậy thì Business Objectives lúc này của anh em sẽ là: “ xe được đổ xăng để chạy tiếp về nhà” đúng không nào.
Sẽ có rất nhiều Solutions anh em có thể nảy sinh ra ngay, như:
- Dắt bộ đến trạm xăng gần nhất.
- Gọi bạn bè ra cứu bồ.
- Nhờ bà con bên đường giúp đỡ.
- Tìm cây xăng lẻ.
- Hoặc thậm chí gửi xe đâu đó, bắt Grab đến cây xăng gần nhất rồi mua bịch xăng về đổ.
Anh em sẽ phải chọn, xem đâu là Solution phù hợp nhất ngay lúc này. Và Solution này có đáp ứng được mức độ hài lòng của các Stakeholders hay không.
Stakeholders trong trường hợp này có thể là:
- Vợ con đang ở nhà chờ cơm.
- Đồng bọn đang chờ ở bàn nhậu.
- Một cuộc hẹn cà phê nào đó vào buổi tối.
- Hoặc có thể là mình chẳng phụ thuộc vào ai cả, tự mình chính là Stakeholder của chính mình.
Anh em cần phải tìm ra được solution đáp ứng tốt nhất nhu cầu của các stakeholders ngay lúc này.
Khi đã có solution, anh em phải thực hiện quá trình Transition một cách hiệu quả. Nếu không muốn tốn quá nhiều thời gian vào chuyện này.
Anh em có thể khẩn trương dắt xe tới ngay một trạm xăng gần đó. Hoặc có thể thư thả gọi đồng bọn tới cứu bồ. Tất cả những điều này đều tùy ở bản thân mình. Miễn đáp ứng được mục tiêu xe được đổ xăng để chạy về nhà là thành công.
Nếu thực hiện các công việc trên, thì anh em đã làm công việc của một Business Analyst rồi. Chỉ khác ở chỗ không phải là phiên bản công việc, mà là phiên bản cuộc sống thực tế thôi 🙂
1.4. Business Analyst không chỉ có riêng trong ngành IT
Thoát ra khỏi bối cảnh IT, công việc BA vẫn tồn tại ở những ngành nghề và lĩnh vực khác.
Từ “business” không chỉ có nghĩa là kinh doanh hay nghiệp vụ, mà còn là “vấn đề”. Anh em xem phim Mỹ hay có câu: “This is not your business!”.
Business đồng nghĩa với matter.
Do đó, Business Analyst hiểu rộng ra hơn là người đi phân tích và giải quyết các vấn đề.
Ở Việt Nam mình thấy chia ra rõ ràng nhất là IT BA và BA. IT BA chiếm số đông hơn hẳn, họ làm Business Analyst trong ngành IT.
Nhưng BA không phải là siêu nhân, BA sẽ không bao giờ tự chém gió ra các solutions mà không có đồng bọn. Người làm Business Analyst sẽ phải kết nối với rất nhiều với stakeholders để đưa ra solution phù hợp nhất.
Giá trị rõ nhất mà một BA có thể mang lại đó là họ nhìn nhận rõ được hiện trạng của tổ chức, và hệ thống hóa được những gì cần làm để đạt được trạng thái “tốt hơn” của tổ chức đó.
Sau đó, nhiệm vụ thực thi là của cả team, cả tổ chức. Và khi mọi thứ đã rõ ràng, khả năng hiện thực hóa sẽ cao hơn rất nhiều.
Tiện thể, Stakeholder dịch ra tiếng Việt là các bên liên quan. Nhưng dịch ra như vậy cũng chưa bám sát ý nghĩa lắm. Cho đơn giản mà chính xác, anh em cứ hiểu: “stake” là cái cột, “holder” là người nắm giữ. Ghép lại, Stakeholder là “Người nắm giữ những cái cột”.
Mà cái cột thì rất quan trọng trong bất kỳ ngôi nhà nào. Nó chống đỡ cho ngôi nhà. Trong dự án cũng vậy, có những người sẽ giữ vai trò quyết định rất quan trọng. Những người này được gọi là Stakeholders.
Stakeholders thường được chia thành các nhóm chính sau:
- Project team
- Project sponsor
- Performing organization
- Partners
- Client
- Và một số “đối tượng” khác.
Làm việc với stakeholder là cả một chủ đề bao la, nên mình sẽ nói kỹ về stakeholder ở những bài sau nhé anh em.
2. Business Analyst làm gì?
Công việc BA được thực hiện dưới rất nhiều vai trò khác nhau. Họ cũng làm y như sơ đồ đầu bài.
Từ Business Objectives >> làm việc với Stakeholders >> đề xuất Solutions >> làm Transition
Nhưng mỗi người sẽ thực hiện ở một mức độ khác nhau.
Theo BABOK ver3.0, công việc IT Business Analyst được thực hiện bởi 6 vai trò sau.
2.1. Business Requirement Analyst
Đầu tiên là Business Requirement Analyst. Người đảm nhiệm vai trò này thường sẽ là người đưa ra các giải pháp ngay thời điểm ban đầu làm việc với khách hàng.
Giải pháp ở đây rất đa dạng, có thể là: thay đổi chính sách công ty, điều chỉnh quy trình nghiệp vụ hoặc training cho nhân viên. Sau đó mới là đề xuất áp dụng phần mềm, hệ thống hay một giải pháp công nghệ. Hoặc áp dụng nhiều giải pháp với nhau để giải quyết bài toán mà doanh nghiệp gặp phải.
Người giữ vai trò này thường là Project Manager, Senior Business Analyst hoặc _ Principle Business Analyst._ Nói chung thường là trùm cuối thì mới giữ vai trò này 😎
Vai trò này xuất hiện thường xuyên nhất trong giai đoạn Pre-Sales. Thường thì các PM hoặc những người làm Business Analyst giàu kinh nghiệm sẽ tham gia vào quá trình này.
Họ sẽ tiếp nhận các vấn đề và yêu cầu ban đầu của doanh nghiệp. Phân tích một bức tranh toàn cảnh và đưa ra 1 giải pháp tổng quan phù hợp nhất.
2.2. System Analyst
System Analyst thường là vai trò dành cho những người làm kỹ thuật. Họ có nhiều kinh nghiệm và rất am hiểu về hệ thống.
System Analyst thường là chuyên gia về một khái niệm kỹ thuật hoặc một phương pháp kỹ thuật phức tạp nào đó. Như blockchain chẳng hạn. Họ thường tham gia vào các dự án có độ phức tạp về kỹ thuật cao.
Thường có một số dự án liên quan đến migrate data, đưa hệ thống lên mây hoặc tích hợp hệ thống sẽ cần sự tham gia rất nhiều của System Analyst.
System Analyst sẽ phân tích hệ thống hiện tại, xem xét các yêu cầu và thiết kế một kiến trúc hệ thống mới dựa trên những gì đã có.
2.3. Business System Analyst
Đây là vai trò chính yếu và nổi trội nhất của một người làm BA. Theo trình tự timeline của dự án, một người có vai trò Business System Analyst sẽ có những nhiệm vụ chính sau:
Moi móc và khai thác thông tin từ các Stakeholders về chức năng và yêu cầu của dự án. Có thể thông qua email, phỏng vấn trực tiếp hoặc demo hệ thống.
Làm tài liệu. Đây là một trong những công việc và kỹ năng rất quan trọng của BA. Document thì có rất nhiều loại, mỗi loại dành riêng cho một Stakeholder. Vì không thể nào đưa bản thiết kế nhà cho thợ điện lắp ráp điện được đúng không. Nói dễ, viết mới khó. Viết sao cho người khác dòm zô là hiểu cái một là một kỹ năng đòi hỏi phải thực hành nhiều 🙂
Truyền đạt thông tin. BA phải đảm bảo được tất cả Stakeholders đã hiểu đúng các vấn đề. Mà một dự án thì có rất nhiều vấn đề, và có rất nhiều thông tin cần truyền tải. BA có kỹ năng ăn nói tốt, giải quyết mâu thuẫn và giải quyết vấn đề tốt thì thông tin trong dự án được truyền đi rất mượt và nhất quán.
Vắt não ra nghĩ solution. Mang tiếng là người đi giải quyết các vấn đề mà không làm công việc này thì hơi kỳ đúng không anh em. Vấn đề có vấn đề lớn, vấn đề nhỏ. Từ khâu làm việc nội bộ với team cho đến làm việc với khách hàng.
Sẽ có hàng trăm thứ xảy ra đòi hỏi mình phải xử lý rất nhiều. Việc đối mặt với vấn đề không phải lúc nào cũng thuận tiện, nhưng somehow nó sẽ giúp anh em tư duy logic và cứng hơn rất nhiều.
2.4. Functional Analyst
Vai trò này giống như Business System Analyst. Nhưng thay vì phát triển mới một sản phẩm giải pháp từ hư vô (build from scratch), người làm Functional Analyst sẽ dựa trên một sản phẩm hay một platform sẵn có. Từ đó configure hoặc customize sao cho sản phẩm đó mapping được với yêu cầu của khách hàng. Giúp giải quyết bài toán mà doanh nghiệp gặp phải.
Trên thị trường có rất nhiều ông lớn cung cấp các sản phẩm hoặc nền tảng sẵn có như: Microsoft, SAP, Oracle, Sharepoint, Salesforce, vâng vâng và mây mây.
2.5. Agile Analyst
Người giữ vai trò Agile Analyst sẽ có trách nhiệm đảm bảo deliver thông tin một cách chính xác, kịp thời và phù hợp với các đối tượng Stakeholder.
Ensure the right info, with the _ right level_ & at the _ right time_.
Ngoài ra, Agile Analyst là vai trò không thể thiếu trong các dự án triển khai theo phương pháp Agile như Scrum chẳng hạn.
Deliver những gì đã cam kết với khách hàng là một trong những yếu tố cực kỳ quan trọng trong dự án Agile. Do đó Agile Analyst đóng một vai trò rất quan trọng trong dự án kiểu như vậy.
2.6. Service Request Analyst
Thường thì BA sẽ giữ vai trò này trong giai đoạn triển khai giải pháp cho khách hàng (transition).
Người giữ vai trò Service Request Analyst sẽ có nhiệm vụ training cho end-users, thực hiện các buổi User Acceptance Test (UAT), xử lý khi gặp lỗi nếu có và có thể là t iếp nhận thêm những yêu cầu tính năng mới từ phía khách hàng.
…
Business Analyst có 6 vai trò khác nhau, nhưng không phải mỗi người chỉ được đảm nhận một vai trò. Mà là một người làm Business Analyst phải đảm nhận nhiều vai trò cùng một lúc.
Thường thì Business Requirement Analyst là vai trò dành cho PM hoặc BA nhiều năm kinh nghiệm.
Còn hầu như một người làm BA bình thường đều đảm nhận các vai trò còn lại.
Riêng anh em nào có vai trò Business System Analyst thì sẽ không có vai trò Functional Analyst. Và ngược lại, người làm Functional Analyst sẽ không làm Business System Analyst. Nhưng các vai trò khác vẫn được đảm bảo.
3. Tạm kết
Business Analyst là một nghề cũ trên thế giới, nhưng mới ở Việt Nam (khoảng hơn 15 năm).
Thực sự thì mình thấy đây là một nghề rất thú vị và có khá nhiều challenge. Điểm mạnh điểm yếu của mình được cọ xát rất nhiều. Nhiều vấn đề thực sự rất chuối nhưng khi gỡ rồi thì đã lắm.
BA xuất hiện để giải quyết vấn đề. Vấn đề có thể là biến cái chưa tốt thành cái tốt. Hoặc biến cái đã tốt rồi thành cái tốt hơn.
Thật sự cảm giác đem lại cái gì đó ý nghĩa cho người khác là một thứ khiến mình khó mà nản được.
Okayyyy, những gì mình**** chém gió ở trên là mang tính tổng quan. Nếu anh em nào muốn hiểu sâu hơn về nghề BA làm những gì thì có thể đọc tiếp series bài viết về các công việc hằng ngày của một người làm BA nhé.
Business Analyst là gì và làm những gì? Hi vọng qua bài viết này, anh em đã có câu trả lời và có cái nhìn sâu sắc hơn về nghề BA.
Bái bai, hẹn gặp lại anh em ở những bài sau 😎
Bình luận