BA Sau Kỷ Nguyên AI

BA Sau Kỷ Nguyên AI

Hoặc Tiến Hóa Lên Functional Architecture — Hoặc Bị Thay Thế

Thesis Của Bài Này

OLD WORLD

AI-NATIVE WORLD

Nếu requirement chỉ là document, AI sẽ thay thế BA.

Nếu requirement trở thành knowledge node, BA trở thành kiến trúc sư của tri thức hệ thống.

Toàn bộ bài này nói về một sự chuyển hóa duy nhất.

Requirement → Knowledge Node

Đừng Tự Huyễn Hoặc Bằng Danh Xưng "Analyst"

Nếu công việc mỗi ngày của mày chỉ là:

• nghe stakeholder nói
• viết lại thành user story
• ném cho dev

thì mày không phải analyst.

Mày chỉ là API chạy bằng cơm.

Một lớp middleware sống tạm giữa business và developer.

Trong kỹ thuật có một quy luật rất rõ.

Middleware luôn là thứ bị thay thế đầu tiên.

Suốt gần hai mươi năm qua, nghề BA bị hiểu sai thành nghề viết lách.

Mày tự hào vì viết được bản spec dày 80 trang?

Xin lỗi.

Đó chỉ là xác của tri thức.

AI có thể tạo ra đống đó trong vài giây.

Thứ có giá trị thật sự không phải document.

Thứ có giá trị là sự hiểu hệ thống.

Và sự thật khó chịu là:

phần lớn BA ngoài kia không hiểu hệ thống.

Họ chỉ đang viết lại những thứ họ chưa hiểu.

Nếu Chỉ Để Viết — AI Làm Tốt Hơn Mày

AI có thể:

• generate requirement
• generate diagram
• generate test case
• summarize meeting

Trong vài giây.

Không mệt.

Không drama.

Không cần salary review.

Nếu công việc chính của mày là viết document, AI chắc chắn sẽ làm tốt hơn.

Nhanh hơn. Rẻ hơn. Ít drama hơn.

Đó không phải prediction.

Đó là logic.

Sự Dịch Chuyển Của Nghề BA

Traditional BA (Document Writer)

Artifact đang trở thành commodity.

Thứ còn lại có giá trị là system intelligence.

Phần Lớn BA Thực Ra Là Human Middleware

Workflow BA trong nhiều công ty trông như thế này.

Stakeholder nói.

BA viết lại.

Developer đọc.

Nếu nói thẳng ra:

Stakeholder → BA → Developer

Đó chính là middleware.

Trong kỹ thuật:

• khi API đủ tốt → middleware biến mất
• khi automation đủ tốt → middleware biến mất

Nếu BA chỉ làm nhiệm vụ dịch lời nói thành document, thì mày đang làm một API chạy bằng cơm.

Bottleneck Của Software Đã Dịch Chuyển

Hai mươi năm trước:

Ngày nay:

Build software ngày càng dễ.

Nhưng biết nên build cái gì ngày càng khó.

Và đó là nơi BA thật sự nên tồn tại.

Một Change Request Nhỏ Có Thể Làm Run Cả Hệ Thống

Khoảng tám tháng trước, team tao nhận một change request.

Yêu cầu:

Trước khi nhập kho NVL phải hoàn thành biên bản kiểm nghiệm.

Trước đó:

Khách hàng muốn đổi thành:

Nghe rất nhỏ.

Chỉ đảo thứ tự hai bước.

Nhưng NVL đầu vào là điểm bắt đầu của cả chuỗi sản xuất.

Một thay đổi ở đầu chuỗi có thể làm run cả hệ thống.

Ba Ngày Chỉ Để Hiểu Impact

Để đánh giá change request đó, team BA mất gần ba ngày.

Không phải để viết spec.

Chỉ để trả lời một câu hỏi.

Nếu rule này thay đổi, hệ thống sẽ bị ảnh hưởng như thế nào?

Team phải kiểm tra:

• inventory
• production workflow
• reporting
• batch traceability
• quality control

Tri thức hệ thống nằm rải rác khắp nơi.

• document
• diagram
• đầu BA
• đầu dev

Tụi tao phải reconstruct lại hệ thống bằng tay.

Ba ngày.

Chỉ để hiểu chuyện gì sẽ xảy ra.

Vấn Đề Không Nằm Ở Requirement

Requirement không phải vấn đề.

Requirement vẫn đúng.

Vấn đề nằm ở cách tri thức được lưu trữ.

Tri thức hệ thống nằm rải rác:

• document
• meeting
• diagram
• đầu từng người

Muốn hiểu hệ thống, tụi tao phải ghép trí nhớ của cả team lại.

Đó không phải knowledge system.

Đó là tribal knowledge.

Và tribal knowledge luôn là một quả bom hẹn giờ.

Insight Quan Trọng Nhất

Requirement không phải document.

Requirement là knowledge node.

Một requirement luôn gắn với:

entity process business rule data dependency decision

Khi requirement được cấu trúc như vậy, nó không còn là document.

Nó trở thành structured knowledge.

Và structured knowledge có một đặc tính cực kỳ quan trọng.

AI có thể reasoning trên nó.

Requirement → Knowledge Node

Nếu requirement chỉ là paragraph, AI không hiểu gì cả.

Nếu requirement là node trong hệ thống tri thức:

AI có thể:

• tìm dependency
• phát hiện conflict
• phân tích impact

Requirement lúc này trở thành machine-readable knowledge.

BA-OS: Khi Requirement Trở Thành Node Tri Thức

Từ insight đó tụi tao build một hệ thống nội bộ.

Tên của nó là: BA-OS — Business Analysis Operating System

Workflow của BA-OS:

Requirement không còn là document. Requirement trở thành node tri thức.

Impact Analysis: Từ Ba Ngày Xuống Vài Phút

Nếu change request NVL xảy ra sau khi BA-OS tồn tại:

Impact analysis từ ba ngày.

Xuống vài phút.

Không phải vì AI thông minh hơn con người.

Mà vì tri thức đã được cấu trúc đúng cách.

Hit-List: Những BA Sẽ Biến Mất

AI không giết BA.

AI chỉ giết một số loại BA.

Human Middleware

Stakeholder → Document → Dev

API chạy bằng cơm.

Jira BA

Sống trong ticket.

Workshop Addict

Meeting nhiều. System understanding ít.

Business-Blind BA

Không hiểu business model.

Bộ Skill BA Phải Có Trong Thời AI

Business Acumen

Hiểu:

• revenue model
• growth engine
• strategic objective

System Thinking

Thấy được:

• dependency
• cascading impact
• system boundary

Functional Architecture Literacy

BA không cần biết database là SQL hay NoSQL.

Nhưng BA phải biết:

• entity nào tồn tại
• entity nào phụ thuộc entity nào
• module nào chiếm dụng dữ liệu nào

Decision Framing

AI có thể generate option.

Nhưng option không phải quyết định.

AI có thể đưa ra 100 phương án.

Nhưng khi hệ thống sập, AI không đứng trong phòng họp.

BA đứng đó.

BA nói:

Chúng ta chọn phương án này.

AI cung cấp dữ liệu.

BA chịu trách nhiệm.

Dirty Reality

AI không giết nghề BA.

AI chỉ giết: Documentation BA

Câu Hỏi Cuối

Nếu AI có thể viết requirement tốt hơn mày.

> Mày còn mang lại giá trị gì cho hệ thống?

Bonus — Khi Requirement Trở Thành Hạ Tầng Tri Thức

Nếu mày đọc tới đây, có lẽ mày đã nhận ra một điều.

Vấn đề của nghề BA không phải là viết requirement.

Vấn đề là tri thức của hệ thống không nằm trong một hệ thống nào cả.

Nó nằm rải rác:

• trong document
• trong diagram
• trong meeting
• trong code
• trong đầu từng người

Muốn hiểu hệ thống, team phải ghép trí nhớ của nhiều người lại với nhau.

Đó không phải knowledge system.

Đó là tribal knowledge.

Software Có System Architecture — Nhưng Không Có Knowledge Architecture

Hầu hết hệ thống phần mềm có:

• system architecture
• data architecture
• service architecture

Nhưng gần như không có thứ gọi là:

knowledge architecture.

Tri thức của hệ thống thường tồn tại dưới dạng:

• document
• wiki page
• diagram

Những thứ này chỉ là ảnh chụp của tri thức.

Chúng không biết dependency. Chúng không biết impact. Chúng không biết logic quan hệ.

Chúng chỉ là text.

AI Không Thể Reasoning Trên Document

AI rất giỏi đọc text.

Nhưng AI không thể reasoning trên document.

Document không có cấu trúc logic.

Document không có relation.

Document không có dependency graph.

AI có thể tóm tắt document.

Nhưng AI không thể hiểu hệ thống từ document.

Requirement Phải Trở Thành Knowledge Node

Muốn AI giúp BA thật sự, requirement phải tiến hóa.

Requirement không thể chỉ là paragraph.

Requirement phải trở thành knowledge node.

Một requirement thực ra chứa nhiều loại tri thức:

Context Rule Entity Data Dependency Process Decision

Khi requirement được cấu trúc như vậy, nó trở thành machine-readable knowledge.

BA-OS Trong 12 Tháng Tới

BA-OS mới chỉ là hạ tầng tri thức.

Trong 12 tháng tới hệ thống sẽ tiến hóa theo ba hướng.

Automatic Context Retrieval

Requirement Stress Engine

Autonomous Impact Reasoning

Khi ba hệ thống này kết hợp:

BA không còn là document writer.

BA trở thành system decision architect.

BA-OS Blueprint

Mày đã đọc đến đây rồi, và nếu mày thuộc nhóm số ít thực sự hiểu và muốn build ra cái BA-OS của riêng mày

Tao gửi dưới đây là bản blueprint của cái BA-OS mà tụi tao đã build và đang sử dụng

Không quảng cáo, không marketing

AI-Native Business Analysis Operating System (Enterprise Edition)

BA-OS defines a complete operating system for Business Analysis.

It integrates:

• Requirement engineering
• AI reasoning
• Semantic knowledge retrieval
• Governance & traceability
• CI-style validation pipelines

Goal:

Transform requirements from documents → into an organizational reasoning system.

1. System Philosophy

BA-OS v3 is based on five principles.

1. Requirements are Knowledge Nodes

Each requirement is an atomic knowledge unit.

1 requirement
=
1 rule
=
1 reasoning node

2. Traceability is Mandatory

Every artifact has an ID.

REQ-xxx   Requirement
RULE-xxx  Business Rule
DATA-xxx  Data Entity
UIF-xxx   UI Flow
DEC-xxx   Decision
SPEC-xxx  Technical Spec

3. AI is a Reasoning Engine

AI is not used for writing documents.

AI is used for:

analysis
conflict detection
dependency discovery
impact reasoning

4. Human BA Owns Judgment

AI generates reasoning.

BA governs correctness.

5. Repository is Organizational Memory

The spec repository becomes:

organizational knowledge system

2. BA-OS Architecture

Stakeholder Input
        ↓
Requirement Extraction
        ↓
Requirement Structuring
        ↓
Requirement Stress Testing
        ↓
Conflict Detection
        ↓
Dependency Detection
        ↓
Specification Creation
        ↓
Feature Aggregation
        ↓
SRS Generation
        ↓
Knowledge Embedding
        ↓
Vector Knowledge Retrieval
        ↓
Impact Analysis

3. Repository Architecture

BA-OS/

Requirement/
 ├─ Analysis/
 ├─ Elicitation/
 ├─ decision-logs/
 └─ Final/

Rules/
 ├─ BusinessRules/
 └─ DomainRules/

specs/
 ├─ active/
 ├─ Feature/
 └─ SRS/

knowledge/
 ├─ embeddings/
 └─ graph/

.cursor/
 ├─ rules/
 ├─ skills/
 └─ commands/

4. Requirement Structure Standard

Each requirement must follow the atomic template.

REQ-142
Version: 1.1
Type: Business Rule

Context
When creating shipment order.

Rule
Shipment must not be created if available_stock < reserved_stock.

Entities
Shipment
Inventory

Fields
available_stock
reserved_stock

Dependencies
Inventory Service

Related Artifacts
DATA-INV-02
UIF-033
RULE-INV-07

5. Workflow Stages

Stage B1 — Requirement Pre-Analysis

Objective

Transform raw stakeholder requirement into draft analysis.

Command

/analyze-req

Rule

requirement-analysis.mdc

Skill

requirement-analysis

Output

Requirement/Analysis/REQ-XXX-Draft.md

Stage B2 — Requirement Elicitation

Resolve ambiguity.

Commands

/extract-open-questions
/elicit-req

Rule

requirement-elicitation.mdc

Skill

requirement-elicitation

Loop until:

All questions resolved

Stage B3 — Decision Logs

Record architectural decisions.

Command

/create-decision-log

Rule

requirement-decision-log.mdc

Output

ADR-REQ-XXX-YY.md

Decision logs store:

context
decision
rationale
impact

Stage B4 — Final Requirement

Generate the official requirement.

Command

/update-req-final

Rule

requirement-final-update.mdc

Skill

requirement-final-update

Output:

Requirement/Final/REQ-XXX.md

Stage B4.5 — Requirement Stress Testing

This is a critical stage.

AI attempts to break the requirement.

Command

/req-stress

Skill

requirement-stress-test

AI analyzes:

edge cases
invalid states
race conditions
data conflicts
integration failures

Output:

Stress Report

Stage B4.6 — Requirement Conflict Detection

Detect conflicting requirements.

Command

/req-conflict

Skill

requirement-conflict-analysis

Pipeline:

vector similarity search
↓
structural filtering
↓
AI reasoning

Output:

Conflict Report

Stage B4.7 — Dependency Detection

Identify hidden dependencies.

Command

/req-dependency

AI analyzes:

shared entities
shared data fields
service dependency
workflow dependency

Stage B5 — Feature Specification

Generate implementation spec.

Command

/specs type=feature

Rule

speckit-feature-spec.mdc

Skill

feature-spec-discovery

Output:

specs/active/[task-id]-spec.md

Stage B6 — Sync Spec to Azure DevOps

Command

!sync-ado SPEC_PATH WORK_ITEM_ID

Rule

speckit-to-workitem-azure-devops-html.mdc

Skill

ado-workitem-sync

Stage B7 — Feature Aggregator

Combine specs into business feature.

Command

aggregate-specs

Rule

feature-aggregator.mdc

Output:

specs/Feature/[feature-name].feature.md

Stage B8 — SRS Generation

Command

generate-srs

Rule

SRS-generator.mdc

Output:

specs/SRS/SRS_MD/*.md

Stage B9 — SRS Export

Command

export-srs

Rule

SRS-exporter.mdc

Output:

specs/SRS/SRS_Exported/*.docx

6. BA Command System (BA-CLI)

BA-OS uses a command interface.

Command	Function
/analyze-req	requirement analysis
/extract-open-questions	extract elicitation questions
/elicit-req	analyze stakeholder answers
/create-decision-log	create ADR
/update-req-final	finalize requirement
/req-stress	requirement stress testing
/req-conflict	detect requirement conflict
/req-dependency	detect dependencies
/specs type=feature	generate feature spec
!sync-ado	sync spec to ADO
aggregate-specs	build feature aggregator
generate-srs	generate SRS markdown
export-srs	export SRS docx

7. Skill System

Skills perform AI reasoning.

requirement-analysis
requirement-analysis-export
requirement-elicitation
requirement-final-update
requirement-stress-test
requirement-conflict-analysis
feature-spec-discovery
ado-workitem-sync

8. Rule System

Rules enforce structure.

requirement-analysis
requirement-analysis-html-export
requirement-elicitation
requirement-decision-log
requirement-final-update
speckit-feature-spec
speckit-to-workitem-azure-devops-html
feature-aggregator
SRS-generator
SRS-exporter

9. Vector Knowledge Layer

All requirements are embedded.

1 requirement
=
1 embedding

Metadata example:

requirement_id
entity
data_fields
module
version
status

Vector search enables:

similar requirement search
dependency detection
conflict discovery
knowledge reuse

10. Knowledge Graph Layer

Requirements form a graph.

Nodes:

Requirement
Entity
Process
UI Flow
System
Decision

Edges:

depends_on
produces
consumes
conflicts_with
validates

Graph reasoning enables:

impact prediction
dependency tracing
system analysis

11. CI Pipeline for Requirements

Spec repository behaves like code repository.

Pipeline:

spec commit
      ↓
requirement stress test
      ↓
conflict detection
      ↓
dependency scan
      ↓
impact analysis
      ↓
approval

12. BA Skill Model

Layer 1 — Analysis

elicitation
requirement structuring
business rule analysis

Layer 2 — System Thinking

domain modeling
service boundaries
dependency reasoning
data integrity

Layer 3 — AI Orchestration

context engineering
semantic retrieval
prompt orchestration
AI validation

Final Principle

Requirements are not documents. Requirements are structured knowledge nodes in a reasoning system.