Introducing

The Business Analysis Planining and Monitoring: theo quyển BABOK thì đây là hai kỹ năng không thể thiếu được của một người làm Business Analyst. Nó ảnh hưởng trực tiếp đến các task trong công việc dự án.

Việc Planning và Monitoring sẽ như sau:

• Những nhóm kiến thức liên quan đến công việc
• Phối hợp và tổ chức những công việc của BA và các Stakeholders.
• Những output đầu ra là những key input cho các phần công việc khác.

Thì đầu tiên mình sẽ giới thiệu BA Planning and Monitoring Knowleadge Area, nó bao gôm như 5 nhiệm vụ như sau:

• Plan Business Analyst Approach: Lên kế hoạch phân tích nghiệp vụ và tiếp cận vấn đề mà doanh nghiệp hay tổ chức cần được giải quyết, lúc này các bạn sẽ define những việc cần phần tích và cần đạt được cái gì. Bạn sẽ cần cần giúp cũng cấp và đưa ra các solution ở khâu này.
• Plan Stakeholder Engagement: Khâu này BA cần tham gia hoặc có liên hệ, hợp tác với các Stakeholder.
• Plan BA Governance: Khâu này BA sẽ cần đưa ra những quyết định trong vấn đề resource, cách quản lý như thế nào. Làm thế nào để quản lý được những thay đổi trong quá trình làm project.
• Plan BA Information Management: BA cần define làm thế nào lên kế hoạch tổ chức và sử dụng một cách hiểu quả những thông tin giá trị mà BA đã thu được từ những bước ở trên.
• Identify BA Performance Improvements: BA cần quản lý và giám sát cách phân tích nghiệp vụ như thế đã hiệu quả hay chưa để đảm bảo rằng nó đáp ứng đúng yêu cầu, và phải luôn luôn rút ra được những kinh nghiệm để sao cho có những solution cải thiện và đáp ứng được đúng yêu cầu.

Core Concept Model

The Business Analyst Core Concept Model miêu tả mối quan hệ giữa 6 core concept.

Dưới đây là Diagram miêu tả quá trình Business Analysis Planning and Monitoring Input/Output

Planning Your BA Approach

Mục tiêu của việc này là để định nghĩa những giải pháp được đánh giá cao để tiến hành các hoạt động phân tích nghiệp vụ. BA Approach miêu tả tổng quan những giải pháp khi thực hiện việc phân tích nghiệp vụ trên một sáng kiến nhất định. Làm cách nào và khi nào các task sẽ được thực thi và chúng ta sẽ thu được những gì. BA cần cân nhắc một vài các technique sẽ được sử dụng trong việc phân tích nghiệp vụ , BA cần linh hoạt trong vấn đề sử dụng.

Phân tích nghiệp vụ nên liên kết với những mục tiêu tổng quan của project hay những mục tiêu thay đổi khác trong doanh nghiệp tổ chức.

Và đảm bảo được rằng từ những việc mà chúng ta cải thiện hay phân tích đó sẽ phải support hay cải thiện được hệ thống mà chúng ta đang thay đổi.

Cùng với đó thì Business Analysis Approach cũng bao gồm những nhiệm vụ để quản lý bất cứ những rủi ro có thể làm giảm chất lượng trong việc đạt được trong việc phân tích nghiệp vụ hoặc cản trở hiệu quả công việc. Chú ý rằng người BA tập trung vào hiệu quả trong mỗi việc họ làm và người BA phải thực sự nên chú ý từng những task phân tích nghiệp vụ, cân nhắc những gì hệ thống mà đã được làm trước đó rồi để thay đổi thứ tự sự ưu tiên effort, và những Approach và chọn những technique, các tool mà nó đã từng được áp dụng và sử dụng tốt trước đó.

Cấu trúc của một Planning a business analysis approach như sau:

• Đầu tiên phải clear những vấn đề hoặc hoàn cảnh của tổ chức đang tìm cách giải quyết trước khi bạn bắt đầu đi sâu vào bước Business Analysis Approach. Và output sẽ được cho ra từ bước Business Analysis Approach. Để ta có thể thu được output từ bước Plan BA Approach thì các bạn sẽ cần được hộ trợ ở phần Guideline and Tools .Và khi các bạn đã ra được output từ bước Plan BA Approach rồi thì các bạn sẽ có một cơ số các việc phải làm sau đó, các bạn xem hình dưới đây ở phần Tasks Using This Output

Defining Planning Approach

Khi chúng ta bắt tay vào công việc implementation thì chúng ta bắt buộc phải Define Planning Approach. Có nghĩa là khi các bạn được giao cho một nhiệm vụ là à hãy cải thiện hệ thống hiện tại đang dùng trong doanh nghiệp có thể là không dùng excel của MS để thống kê nữa mà build lên một hệ thống có thể có chức năng sao kê, thống kê, kết hợp AI để phân tích và đưa ra những cảnh báo về doanh số chẳng hạn,... Chính vì vậy mà chúng ta cần phải làm bước này. Vậy chúng ta có các cách approach như thế nào.

Predictive

• Là cách tiếp cận vấn đề truyền thống mà trước đây mọi người hay làm.
• Tất cả các planning được hoàn thành trước khi chúng ta bắt đầu implement, vì vậy công việc và cái kỳ vọng mà hệ thống cần đạt được những gì rất là rõ ràng --> giảm thiểu tối đa rủi ro.
• Và cách tiếp cận này có thể định nghĩa được requirement trước một cách chi tiết đầy đủ trước khi bắt đầu triển khai. Hoặc là đảm bảo chắc chắn là chúng ta triển khải đúng theo requirement vì chúng ta đã định nghĩa nó ra trước rồi.
• Cách này thì chúng ta sẽ phải làm documentation trước, điều này giúp chúng ta khi họp với các stakeholder dễ ràng về mặt giao tiếp hơn vì đã có cái define ra rồi chứ không phải lúc đến cuộc họp mới nghĩ cái để define.

Adaptive

• Cách tiếp cận này thì lại ngược lại hoàn toàn với cách ở trên bời vì nó chấp nhận mức độ không chắc chắn cao hơn. Nghĩa là khi làm theo cái này thì chúng ta sẽ cho sản phẩm nhanh hơn bằng cách lặp vòng lặp sprint.
• Cách này thì thường được áp dụng trong trường hợp khi solution sẽ không được define rõ ràng, tức là khách hàng họ còn không muốn họ muốn gì, chúng ta phải làm ra cho họ xem xem là có phải ý họ muộn hệ thống sẽ thành như này hay không. Làm đến đâu thì đưa ra solution đến đó.
• Việc làm theo hướng này thì sẽ cho ra được sản phẩm để khách hàng hoặc cách stakeholder thấy được sản phẩm nhanh hơn so với cách làm ở trên là phải hoàn thành hết mới cho ra sản phẩm. Lúc đó mà bị lỗi thì rất mất công sửa. Và trong quá trình làm thì thì chúng ta có thể cải thiện được solution cho phù hợp mong muốn và feedback từ các bên.

Để cách bạn quyết định chọn cách tiếp cận vấn đề nào ở trên thì các bạn phải cân nhắc những điều sau:

• Tiêu chuẩn của tổ chức doanh nghiệp
• Mức độ chấp nhận sự rủi ro
• Kinh nghiệm của người BA ví dụ như bạn đã tiếp cận 1 trong 2 cách ở trên chưa, những techniquies nào đã áp dúng rồi, bạn đã làm việc hay có kinh tham gia với các stakeholder bao giờ hay chưa.
• Và làm thế nào các bạn có thể xử lý được những thay đổi

Level of Formality and Detail

Predictive Approaches

• Có documentation chính thức rõ ràng.
• Hầu hết những cách làm này sẽ dựa vào template của doanh nghiệp tổ chức, cái này nó sẽ cung cấp những tiêu chuẩn luôn luôn được sửa dụng.
• Và khi có documentation rõ ràng rồi thì nó sẽ được cần kiểm duyệt bởi các stakeholders.

Adaptive Approaches

• Không có documentation chính thức và rõ ràng.
• Các team sẽ hợp tác với nhau để thiết kế ra requirement và những design được sắp xếp sự ưu tiên và phải được sự đồng ý bởi các bên .
• Với cách này là chúng ta sẽ thay đổi và cải thiện qua những quá trình làm và feedback.

Complexity and risk

Trong quá trình làm thì chúng ta sẽ phải lưu ý tới độ phức tạp và những rủi ro liên quan.

Đầu tiên chúng ta sẽ đi vào độ phức tạp Complexity của vấn đề:

• Change size or scope: khi chúng ta thay đổi từ excel sang dùng một hệ thống mình tự build chẳng hạn thì effort cần cho sự thay đổi này là như nào và pham vị thay đổi nó sẽ ảnh hướng đến những gì mà hiện tại mình vẫn đang dùng.
• System or business areas affected: xác định xem những hệ thống bị thay đổi hoặc ảnh hưởng
• People impacted or involved: những thay đổi này thì cần phải xác định ai sẽ bị ảnh hưởng hoặc liên quan.
• Geographic: về vị trí địa lý trong việc trao đổi với các stakeholder và team dự án.
• Technology: về mặt công nghệ thì có thể tăng nhanh, độ phức tạp cũng dựa vào những gì mà bạn đang làm việc với các công nghê.

Tiếp theo chúng ta sẽ đi vào những yếu tố gây rủi to risk:

• Business analyst's experience level: tùy vào từng level mức độ kinh nghiệm của người BA.
• Business analyst's domainknowledge and expertise: ví như chúng ta nhảy vào còn dự án liên quan đến sale chẳng hạn thì chúng ta phải có kỹ năng hay kiến thức về sale . Việc bạn có kinh nghiệm và đã từng làm những thứ liên quan đến domain kiên thức mà dự án bạn đang làm sẽ giúp cho bạn giảm thiểu được rủi ro.
• Stakeholder engagement: quan điểm của stakeholder trong việc sharing và collaborating với mình và team có thể ảnh hướng lớn đến effort.
• Organizational standard, policies, procedures, or culture: tùy thuộc vào các tiêu chí của doanh nghiệp , của tổ chức, những chính sách và văn hóa.

Guildlines, Tools and Techniques to Build BA Approach

Đọc trong quyển BABOK guide thì nó có hướng dẫn các guildline và tool giúp chúng ta trong mỗi business analysis task.

Guildelines and Tools

• BA Performance Assessment: đánh giá hiệu suất từ công việc trước đây và những bài học rút kinh nghiệm cái gì cần cải thiện, cái gì cần rút kinh nghiệm.
• Business Policies: cần áp dụng sớm trong plan vì chúng thường mô tả những hạn chế và những ảnh hường của chúng ảnh hướng đến việc phân tích nghiệp vụ.
• Expert Judgment: nên được tận dụng khi mà mình không chắc chắn về các những thứ mình đang làm, bao gồm hỏi các stakeholder để biết thêm thông tin về idea. Có thể hỏi các consult hoặc các đồng nghiệp về kinh nghiệm về một domain kiến thức nào đó chẳng hạn.
• Methodologies & Frameworks: ví dụ áp dụng Agile hay Scum, ...
• Stakeholder Engagement Approach: cân nhắc tới việc làm việc với các bên liên quan đến vấn đề mà bạn đang triển khai, làm thế nào để tương tác tốt và các stakeholder support cho công việc của mình.

Techiniques

• Brainstorming: định nghĩa những việc cần phải làm hay những rủi ro có thể xảy ra.
• Business Cases: cái này giúp chúng ta hiểu được mọi khía cạnh vấn đề hay cơ hội ví dụ như timeline, mức độ rủi ro hay bất cứ những giả thiết nào
• Document Analysis: tài liệu phân tích, những tài liệu của doanh nghiệp sẽ giúp chúng ta lên được plan approach.
• Estimation: sẽ estimate được những công việc để quyết định xem là bao lâu chúng ta có thể bắt tay thực hiện được task
• Financial Analysis: thường được dùng ước tính những nội thực hiện của doanh nghiệp tổ chức có thể hỗ trợ kế hoạch mà mình đang làm hay không
• Functional Decomposition: nó rất có ích, giúp bạn có thể break những cái phức tạp thành cái đơn giản khiến bạn có thể giải quyết công việc một cách dễ dàng hơn.
• Interviews: bạn có thể dùng technique này dùng để nói với những người còn lại khi build BA Approach, hỏi những vấn đề còn chưa rõ, còn chưa clear.
• Item Tracking: thường để tracking bất cứ những issue trong suốt quá trình trao đổi với các stakeholder. Hoặc cũng có thể tracking những rủi ro liên quan đến những vấn đề được raise lên trong suốt quá trình bàn bạc bạc khi đang build approach
• Lessons Learned: thường định nghĩa ra những kinh nghiệm của doanh nghiệp trước đó đã từng làm (cả thành công lẫn thách thức) với cái mục tiêu mà chúng ta đang cần phân tích.
• Process Modeling: thường được dùng để định nghĩa và tài liệu hóa the business analysis approach.

Utilizing Stakeholder to Create BA Approach

Khi chúng ta lên kế hoạch cho việc tiếp cận vấn đề mới mà hệ thống doanh nghiệp tổ chức cần được cải thiện hoặc làm mới, nấng cấp. Ví dụ như các bạn tiếp cận nâng cấp hệ thống làm việc của sale thì các bạn cần có những domain kiến thức của sale hay các bạn được giao cho là tìm ra những giải pháp để nâng cấp hệ thống kế toán cũ của ngân hàng này lên với những yêu cầu mới chẳng hạn thì các bạn cũng phải có domain kiến thức về ngân hàng đúng không ? Vì vậy việc nhanh nhất là chúng ta sẽ liên hệ tới những Stakeholder - các bên liên quan để có thể dễ dàng cho chúng ta trong việc tiếp cận vấn để để đưa ra giải pháp. Sau đây là một số các Stakeholder liên quan mà các bạn có thể gặp:

Inconclusion

Vậy qua một số những khái niệm trên cũng giúp các bạn hiểu được phần nào về Planning Your Business Analysis Approach. Cảm ơn các bạn đã đọc bài viết của mình.

Reference

BABOK Guide V3 Corporate