Phần lớn hệ thống kiểm soát trong doanh nghiệp được xây quanh một câu hỏi quen thuộc:
> **Giá trị hiện tại có vượt ngưỡng hay không?**
Ví dụ:
- AR overdue > 30 ngày;
- BOM variance > 5%;
- Inventory Days > 90;
- Cash Runway < 3 tháng.
Cách tiếp cận này hữu ích, nhưng chưa đủ.
Bởi rất nhiều vấn đề kinh doanh không xuất hiện dưới dạng “một con số vượt threshold”. Chúng xuất hiện khi:
> **trạng thái thực tế khác với trạng thái mà doanh nghiệp kỳ vọng phải xảy ra.**
Đây chính là khái niệm:
# Expected State / Expected Behavior
Có thể hiểu đơn giản:
> **Expected State là trạng thái mà một Business Object, transaction hoặc process đáng lẽ phải có tại một thời điểm hoặc điều kiện nhất định.**
Khi Actual State khác Expected State đủ material:
`Deviation`
→ `Detection`
→ `Issue`
→ `Case`
→ `Action`
→ `Outcome`.
Đây có thể trở thành abstraction chung cho:
- Finance Value Leakage;
- Tax Health Check;
- Continuous Accounting Detection;
- Smart Factory Lite.
## 1. Threshold chỉ là một loại Expected State
Ví dụ đơn giản:
`AR Days ≤ 30`.
Đây là một Expected State dạng threshold.
Nhưng Expected State có thể phức tạp hơn nhiều.
### AP
Expected:
`Invoice`
phải có:
`PO + Receipt + Approval`
trước posting.
### Tax
Expected:
`GL Revenue`
phải reconcile với:
`E-Invoice + VAT + CIT`
sau các adjustment hợp lệ.
### Manufacturing
Expected:
`Batch`
phải chạy theo:
`BOM Revision + Standard Yield + Approved Material`.
Như vậy:
> **Threshold chỉ là một trường hợp con của Expected Behavior.**
## 2. Doanh nghiệp thực chất vận hành bằng Expected States
Mọi process đều có một kỳ vọng ngầm.
Ví dụ Order-to-Cash:
`Sales Order`
→ `Delivery`
→ `Invoice`
→ `Payment`.
Procure-to-Pay:
`PO`
→ `Receipt`
→ `Invoice`
→ `Approval`
→ `Payment`.
Production:
`Production Order`
→ `Material Issue`
→ `Processing`
→ `Quality Check`
→ `Finished Goods`.
Finance:
`Transaction`
→ `Posting`
→ `Reconciliation`
→ `Close`.
Nếu process đi khác chuỗi này, system nên hỏi:
> **đây là exception hợp lệ hay control failure?**
## 3. Expected State cần được biểu diễn như dữ liệu
Một sai lầm phổ biến là Expected State chỉ nằm trong:
- SOP;
- policy document;
- Excel;
- kinh nghiệm của nhân viên.
Nếu muốn AI hoặc Diagnostic Engine kiểm tra tự động, Expected State phải được biểu diễn thành:
**machine-readable rule / model.**
Ví dụ:
`Invoice_Status = Posted`
thì expected:
`PO_Matched = True`
`Receipt_Matched = True`
`Approval_Status = Approved`.
Đây là:
**policy-as-data.**
## 4. Expected State có thể đến từ nhiều nguồn
Có thể chia thành:
### Business Rule
Ví dụ: Invoice > 100 triệu phải có manager approval.
### Process Rule
Ví dụ: Goods Receipt phải có trước AP posting.
### Accounting Rule
Ví dụ: Subledger phải reconcile với GL.
### Tax Rule
Ví dụ: Obligation phải filed trước due date.
### Master Data Rule
Ví dụ: Supplier phải có valid tax ID.
### Historical Pattern
Ví dụ: Material usage thường trong ±2%.
### Statistical Pattern
Ví dụ: Journal pattern bất thường so với 12 tháng trước.
Expected Behavior có thể là:
**deterministic**
hoặc:
**learned.**
## 5. Ba loại Detector vẫn cần, nhưng cùng dựa trên Expected Behavior
Common Diagnostic Engine có thể giữ ba detector:
### RULE
Kiểm tra điều kiện xác định trước.
Ví dụ:
`AR_Days > 30`.
### RECONCILIATION
Kiểm tra expected relationship giữa nhiều nguồn.
Ví dụ:
`GL Revenue ≈ E-Invoice Revenue`.
### ANOMALY
Kiểm tra deviation khỏi historical pattern.
Ví dụ:
Expense ratio tăng bất thường.
Điểm chung:
> **cả ba đều so Actual với Expected.**
## 6. Expected State cần gắn với Business Object
Expectation không nên tồn tại mơ hồ.
Phải biết expectation áp dụng cho object nào.
Ví dụ:
`Customer`
có Expected Credit Limit.
`Supplier`
có Expected Payment Term.
`Invoice`
có Expected Approval Flow.
`Batch`
có Expected Yield.
`BOM`
có Expected Material Usage.
`Employee`
có Expected Payroll/PIT relationship.
Đây là lý do:
**Business Object Model phải đi trước Detection Engine.**
## 7. Ví dụ Finance: AP Invoice
Business Object:
`Invoice`.
Expected State:
- PO exists;
- Receipt exists;
- amount within tolerance;
- supplier active;
- approval complete.
Actual State:
- PO exists;
- Receipt missing;
- invoice posted.
Deviation:
`Receipt_Missing`.
Detection:
`AP Control Exception`.
Issue:
`Potential unsupported liability`.
Case:
`CASE-AP-014`.
Action:
Buyer review.
Outcome:
Validated / reversed / corrected.
Đây là Continuous Accounting Detection.
## 8. Ví dụ Finance: AR Collection
Business Object:
`Invoice`.
Expected Behavior:
`Payment by Due Date`.
Actual:
`Overdue 47 days`.
Nhưng có thể có Expected Behavior sâu hơn:
Nếu invoice overdue >30:
expected:
`Collection Case = Open`.
Nếu >45:
expected:
`Escalation = Sales Manager`.
Nếu >60:
expected:
`Credit Review = Required`.
Như vậy system không chỉ kiểm tra invoice có overdue không, mà còn kiểm tra:
> **doanh nghiệp đã phản ứng đúng chưa?**
## 9. Transaction Control và Management Control khác nhau
Transaction Control hỏi:
> transaction đúng không?
Management Control hỏi:
> khi exception xảy ra, organization có phản ứng đúng không?
Ví dụ:
AR overdue 50 ngày.
Transaction có thể hoàn toàn đúng.
Nhưng nếu không có:
- owner;
- collection action;
- escalation;
thì:
**management process đang sai Expected Behavior.**
## 10. Ví dụ Tax: Revenue Consistency
Business Objects:
`GL Revenue`
`E-Invoice`
`VAT Return`
`CIT Return`.
Expected State:
sau các timing/reconciliation adjustment hợp lệ, các nguồn phải reconcile.
Actual:
VAT Revenue thấp hơn GL 8%.
Detection:
`Tax Data Consistency Exception`.
System không nên kết luận ngay:
> tax error.
Nó nên hỏi:
- timing?
- non-taxable revenue?
- credit note?
- posting issue?
Nếu không có reason code hợp lệ:
→ create Tax Case.
## 11. Ví dụ Tax: Obligation Behavior
Business Object:
`Tax Obligation`.
Expected State:
- filed before due date;
- payment completed;
- evidence retained.
Actual:
Filed = Yes.
Evidence = Missing.
Compliance Status:
Filed.
Risk:
Medium/High.
Điểm quan trọng:
> **Expected State nhiều chiều hơn một Yes/No field.**
## 12. Ví dụ Payroll
Business Objects:
`Employee`
`Payroll`
`PIT`
`Social Insurance`
`GL Expense`.
Expected Relationship:
`Payroll`
↔ `PIT`
↔ `BHXH`
↔ `GL`.
Actual:
Payroll Expense tăng 30%.
PIT base không đổi.
System tạo:
`Consistency Deviation`.
Sau đó cần reasoning:
- bonus non-taxable?
- contractor?
- foreign employee?
- timing?
Đây là reconciliation-driven detection.
## 13. Ví dụ Manufacturing: Batch Yield
Business Object:
`Batch`.
Expected State:
`Yield ≥ 97%`.
Actual:
`91%`.
Detection:
`Yield Exception`.
Nếu Yield < 95%, expected process có thể là:
- Quality Review;
- Production Review;
- Root Cause Case.
Nếu system không tạo case thì đó lại là:
**process-control exception.**
Như vậy có thể có:
`Operational Exception`
và:
`Control Exception`
cùng lúc.
## 14. Ví dụ Manufacturing: BOM Usage
Expected:
`Actual Material Usage`
nằm trong tolerance của:
`BOM Standard`.
Actual:
+7%.
Detection:
`Material Variance`.
Nhưng system nên kiểm tra thêm:
- correct BOM revision?
- approved substitution?
- valid material lot?
- rework?
- scrap recorded?
Expected State vì vậy không chỉ là:
`Variance ≤ 5%`.
Nó là:
**context-dependent behavior.**
## 15. Context quyết định Expected State
Một threshold cố định thường quá đơn giản.
Ví dụ:
Yield 95% có thể tốt với SKU A nhưng xấu với SKU B.
AR 45 ngày có thể bình thường với customer terms 60 days nhưng nghiêm trọng với terms 30 days.
Do đó Expected State phải gắn với:
**Business Context.**
Ví dụ:
`Expected_Due_Date = Invoice Date + Customer Payment Term`.
Không nên hard-code:
`30 days`.
## 16. Expected State nên hỗ trợ Conditional Logic
Ví dụ:
IF:
`Vendor_Type = New`
THEN:
`2-level approval required`.
IF:
`Amount > 500M`
THEN:
`CFO approval required`.
IF:
`Material = Critical`
THEN:
`QA certificate required`.
Expected Behavior phải hỗ trợ:
`Context → Condition → Expected State`.
## 17. Expected State cũng cần versioning
Business rule thay đổi theo thời gian.
Ví dụ:
Approval threshold 2026:
`100 triệu`.
2027:
`200 triệu`.
Nếu system audit transaction năm 2026, phải dùng:
**rule version năm 2026.**
Do đó Expected State cần:
- Effective From;
- Effective To;
- Rule Version.
Đây là:
**temporal control context.**
## 18. Không có versioning sẽ tạo false positive
Nếu dùng rule hiện tại để kiểm tra historical transaction, system có thể báo sai.
Ví dụ:
Tax Rule 2027 áp vào transaction 2026.
Hoặc BOM Rev.08 áp vào batch chạy bằng Rev.07.
Do đó:
> **Expected State phải đúng theo thời điểm.**
## 19. Expected Behavior có thể học từ lịch sử
Không phải mọi expectation đều viết được thành rule.
Ví dụ Journal Entries thường có:
- account combination;
- amount range;
- posting time;
- user pattern.
System có thể học:
**normal behavior.**
Sau đó Actual khác pattern:
→ anomaly.
Đây là:
**learned Expected Behavior.**
## 20. Anomaly không đồng nghĩa Issue
Một anomaly chỉ là:
> khác bình thường.
Nó chưa chắc sai.
Ví dụ Marketing Expense tăng gấp 5 có thể vì campaign launch.
Do đó:
`Anomaly Detection`
→ `Context Check`
→ `Materiality`
→ `Issue`.
Không nên:
`Anomaly = Issue`.
## 21. Detection ≠ Issue
Một engine tốt phải tách:
### Detection
Một deviation được phát hiện.
### Issue
Deviation đủ material và meaningful để quản trị.
Ví dụ:
1.000 journal anomalies.
Sau dedupe + materiality:
chỉ còn:
12 Issues.
Nếu không tách hai lớp, doanh nghiệp sẽ bị:
**alert fatigue.**
## 22. Materiality phải nằm giữa Detection và Issue
Một deviation nhỏ có thể không cần action.
Ví dụ:
GL vs VAT difference:
`0,02%`.
Có thể do rounding.
System nên có:
`Materiality Filter`.
Ví dụ:
`Absolute Value`
+
`Percentage`
+
`Risk Type`
+
`Frequency`.
Sau đó mới quyết định:
`Create Issue?`
## 23. Materiality cũng phải theo Context
Variance 1 triệu không đáng kể với doanh nghiệp lớn nhưng có thể material với một branch nhỏ.
Do đó Materiality Rule nên có:
- entity;
- account;
- process;
- risk class.
Không nên chỉ dùng một threshold toàn doanh nghiệp.
## 24. Detection Result cần lưu Actual và Expected
Data Model nên lưu tối thiểu:
`Actual_State`
`Expected_State`
`Deviation`
`Tolerance`
`Context`
`Evidence`
`Detector_Type`
`Rule_Version`.
Đây là dữ liệu rất quan trọng.
Nó cho phép:
- audit;
- explainability;
- learning.
## 25. Root Cause không nên nằm trong Detection Rule
Detection Rule chỉ nên trả lời:
> có deviation không?
Root Cause là bước sau.
Ví dụ:
Detection:
`Yield < Standard`.
Root Cause có thể là:
- material;
- machine;
- operator;
- BOM.
Không nên encode toàn bộ reasoning vào detector.
Điều này giúp kiến trúc:
**modular.**
## 26. AI nên tham gia ở đâu?
AI phù hợp sau Detection.
`Detection`
→ AI phân tích context.
AI có thể:
- classify issue;
- suggest root cause;
- find similar cases;
- recommend action.
Nhưng Expected State cốt lõi nên càng:
**explicit và explainable**
càng tốt.
## 27. Continuous Diagnostic Engine thực chất là “Expectation Engine”
Nếu nhìn sâu hơn:
Common Diagnostic Engine không chỉ là detector.
Nó là:
> **Expectation Engine.**
Nó quản lý:
- doanh nghiệp kỳ vọng điều gì;
- actual đang là gì;
- deviation bao nhiêu;
- có material không;
- ai xử lý.
Đây là cách nhìn rất mạnh.
## 28. Một schema đơn giản cho Expected State
Có thể bắt đầu với:
`Expected_State_ID`
`Business_Object_Type`
`Condition`
`Expected_Field`
`Expected_Value / Range`
`Tolerance`
`Effective_From`
`Effective_To`
`Rule_Source`
`Owner`
`Severity_Default`
`Detector_Type`
`Version`.
Không cần phức tạp hơn ngay từ đầu.
## 29. Rule Source cần được lưu
Expected State đến từ đâu?
Ví dụ:
- Regulation;
- Accounting Policy;
- SOP;
- Contract;
- BOM Standard;
- Management Rule;
- Historical Pattern.
Lưu `Rule_Source` giúp:
**explainability.**
Ví dụ system nói:
> Invoice cần 2-level approval.
Finance có thể biết:
> rule này đến từ Approval Policy v3.1.
## 30. Owner của Expected State cũng quan trọng
Ai chịu trách nhiệm cho expectation?
Ví dụ:
BOM Standard:
Engineering.
Tax Obligation:
Tax Manager.
Approval Matrix:
CFO.
Supplier Lead Time:
Supply Chain.
Nếu rule sai, phải biết ai update.
Đây là:
**Rule Governance.**
## 31. Expected State và Protected Business Objects
Một số Expected State liên quan Protected Objects.
Ví dụ:
- BOM Revision;
- Standard Cost;
- Tax Rule;
- Approval Matrix.
AI có thể phát hiện:
> Expected State có vẻ không còn phù hợp.
Nhưng không nên tự sửa.
Nó chỉ nên:
`Propose Change`.
Sau đó:
`Impact Analysis`
→ `Approval`
→ `Version Update`.
## 32. Expected State và Finance Case
Detection phát hiện deviation.
Sau materiality filter:
Issue được tạo.
Issue đủ quan trọng:
→ Finance Case.
Flow:
`Expected State`
vs
`Actual State`
↓
`Deviation`
↓
`Detection`
↓
`Issue`
↓
`Case`
↓
`Action`
↓
`Outcome`.
## 33. Expected State và Tax Case
Ví dụ:
Expected:
`VAT ↔ GL reconciled`.
Actual:
Mismatch 8%.
Detection:
Tax Consistency Deviation.
Issue:
Unexplained Revenue Difference.
Case:
`CASE-TAX-014`.
Owner:
Tax Manager.
Action:
Reconciliation.
Outcome:
Documented timing difference.
Risk reduced.
## 34. Expected State và Smart Factory Lite
Digital Batch Record cung cấp:
**Actual State.**
BOM / Routing / Yield Standard cung cấp:
**Expected State.**
Difference tạo:
**Operational Exception.**
Đây là cách rất tự nhiên để Smart Factory Lite chạy Continuous Detection mà không cần AI phức tạp ngay từ đầu.
## 35. Common Diagnostic Engine lúc này có thể được hiểu rất đơn giản
Input:
`Business Objects + Transactions`.
Layer 1:
**Expected State Registry.**
Layer 2:
**Detection Engine.**
Layer 3:
**Issue Engine.**
Layer 4:
**Case / Action.**
Layer 5:
**Outcome.**
AI có thể tham gia ở nhiều layer nhưng không phải nền tảng duy nhất.
## 36. Hai Diagnostic Pack đầu tiên
### Finance Value Leakage Pack
Expected States như:
- AR within terms;
- margin within threshold;
- inventory within target;
- cost within standard;
- forecast within tolerance.
### Tax Health Check Pack
Expected States như:
- obligation complete;
- evidence available;
- master data valid;
- returns consistent;
- transactions explainable.
Cùng một engine.
Khác expectation library.
## 37. Sau này Smart Factory Lite cũng chỉ là một Diagnostic Pack khác
Expected States:
- Yield;
- BOM Usage;
- Scrap;
- Downtime;
- Quality;
- Material Availability.
Điều này cho thấy:
> **một Common Diagnostic Engine có thể mở rộng khá xa mà không thay kiến trúc lõi.**
## 38. Từ Rule Engine sang Expectation Management
Rule Engine thường nghe rất kỹ thuật.
Nhưng business thực chất đang quản lý:
> **kỳ vọng vận hành.**
Finance kỳ vọng:
Invoice đúng control.
Tax kỳ vọng:
Data reconcile.
Production kỳ vọng:
Yield đạt chuẩn.
Supply Chain kỳ vọng:
Material đến đúng lúc.
Expected State Model chính là cách số hóa:
**management expectations.**
## 39. Continuous Detection chỉ có ý nghĩa khi có Continuous Action
Phát hiện liên tục nhưng không hành động chỉ tạo nhiều alert hơn.
Do đó:
`Detection`
phải dẫn tới:
`Issue`
→ `Owner`
→ `Action`
→ `Outcome`.
Expected State không phải dashboard concept.
Nó là:
**management-control concept.**
## 40. Nguyên tắc cốt lõi
Có thể tóm gọn toàn bộ bằng một câu:
> **Một doanh nghiệp có thể được quản trị như tập hợp các Business Objects có Expected States; khi Actual State lệch khỏi Expected State đủ material, hệ thống phải tạo Issue và kích hoạt Action.**
Đây là abstraction rất mạnh.
# Kết luận
Continuous Diagnostic Engine không nhất thiết bắt đầu bằng AI.
Nó bắt đầu bằng một câu hỏi cơ bản:
> **Điều gì đáng lẽ phải xảy ra?**
Sau đó mới hỏi:
> **Điều gì thực sự đang xảy ra?**
Khoảng cách giữa hai thứ là:
**Deviation.**
Nếu deviation đủ material, nó trở thành:
`Detection`
→ `Issue`
→ `Case`
→ `Action`
→ `Outcome`.
Với cách nhìn này:
Finance Value Leakage,
Tax Health Check,
Continuous Accounting Detection,
và Smart Factory Lite
đều có thể dùng chung một logic lõi:
`Business Object`
→ `Expected State`
→ `Actual State`
→ `Deviation`
→ `Issue`
→ `Action`
→ `Outcome`.
Điểm quan trọng không nằm ở việc doanh nghiệp có AI mạnh tới đâu.
Mà nằm ở việc doanh nghiệp có biết:
> **mình kỳ vọng hệ thống phải vận hành như thế nào hay không.**
Khi Expected State được số hóa, version hóa và gắn với Business Object:
AI mới có context để reasoning.
Rule Engine mới có cơ sở để kiểm tra.
Management mới biết deviation nào cần xử lý.
Và khi đó Continuous Detection mới thực sự trở thành:
**Continuous Management.**
> **Giá trị hiện tại có vượt ngưỡng hay không?**
Ví dụ:
- AR overdue > 30 ngày;
- BOM variance > 5%;
- Inventory Days > 90;
- Cash Runway < 3 tháng.
Cách tiếp cận này hữu ích, nhưng chưa đủ.
Bởi rất nhiều vấn đề kinh doanh không xuất hiện dưới dạng “một con số vượt threshold”. Chúng xuất hiện khi:
> **trạng thái thực tế khác với trạng thái mà doanh nghiệp kỳ vọng phải xảy ra.**
Đây chính là khái niệm:
# Expected State / Expected Behavior
Có thể hiểu đơn giản:
> **Expected State là trạng thái mà một Business Object, transaction hoặc process đáng lẽ phải có tại một thời điểm hoặc điều kiện nhất định.**
Khi Actual State khác Expected State đủ material:
`Deviation`
→ `Detection`
→ `Issue`
→ `Case`
→ `Action`
→ `Outcome`.
Đây có thể trở thành abstraction chung cho:
- Finance Value Leakage;
- Tax Health Check;
- Continuous Accounting Detection;
- Smart Factory Lite.
## 1. Threshold chỉ là một loại Expected State
Ví dụ đơn giản:
`AR Days ≤ 30`.
Đây là một Expected State dạng threshold.
Nhưng Expected State có thể phức tạp hơn nhiều.
### AP
Expected:
`Invoice`
phải có:
`PO + Receipt + Approval`
trước posting.
### Tax
Expected:
`GL Revenue`
phải reconcile với:
`E-Invoice + VAT + CIT`
sau các adjustment hợp lệ.
### Manufacturing
Expected:
`Batch`
phải chạy theo:
`BOM Revision + Standard Yield + Approved Material`.
Như vậy:
> **Threshold chỉ là một trường hợp con của Expected Behavior.**
## 2. Doanh nghiệp thực chất vận hành bằng Expected States
Mọi process đều có một kỳ vọng ngầm.
Ví dụ Order-to-Cash:
`Sales Order`
→ `Delivery`
→ `Invoice`
→ `Payment`.
Procure-to-Pay:
`PO`
→ `Receipt`
→ `Invoice`
→ `Approval`
→ `Payment`.
Production:
`Production Order`
→ `Material Issue`
→ `Processing`
→ `Quality Check`
→ `Finished Goods`.
Finance:
`Transaction`
→ `Posting`
→ `Reconciliation`
→ `Close`.
Nếu process đi khác chuỗi này, system nên hỏi:
> **đây là exception hợp lệ hay control failure?**
## 3. Expected State cần được biểu diễn như dữ liệu
Một sai lầm phổ biến là Expected State chỉ nằm trong:
- SOP;
- policy document;
- Excel;
- kinh nghiệm của nhân viên.
Nếu muốn AI hoặc Diagnostic Engine kiểm tra tự động, Expected State phải được biểu diễn thành:
**machine-readable rule / model.**
Ví dụ:
`Invoice_Status = Posted`
thì expected:
`PO_Matched = True`
`Receipt_Matched = True`
`Approval_Status = Approved`.
Đây là:
**policy-as-data.**
## 4. Expected State có thể đến từ nhiều nguồn
Có thể chia thành:
### Business Rule
Ví dụ: Invoice > 100 triệu phải có manager approval.
### Process Rule
Ví dụ: Goods Receipt phải có trước AP posting.
### Accounting Rule
Ví dụ: Subledger phải reconcile với GL.
### Tax Rule
Ví dụ: Obligation phải filed trước due date.
### Master Data Rule
Ví dụ: Supplier phải có valid tax ID.
### Historical Pattern
Ví dụ: Material usage thường trong ±2%.
### Statistical Pattern
Ví dụ: Journal pattern bất thường so với 12 tháng trước.
Expected Behavior có thể là:
**deterministic**
hoặc:
**learned.**
## 5. Ba loại Detector vẫn cần, nhưng cùng dựa trên Expected Behavior
Common Diagnostic Engine có thể giữ ba detector:
### RULE
Kiểm tra điều kiện xác định trước.
Ví dụ:
`AR_Days > 30`.
### RECONCILIATION
Kiểm tra expected relationship giữa nhiều nguồn.
Ví dụ:
`GL Revenue ≈ E-Invoice Revenue`.
### ANOMALY
Kiểm tra deviation khỏi historical pattern.
Ví dụ:
Expense ratio tăng bất thường.
Điểm chung:
> **cả ba đều so Actual với Expected.**
## 6. Expected State cần gắn với Business Object
Expectation không nên tồn tại mơ hồ.
Phải biết expectation áp dụng cho object nào.
Ví dụ:
`Customer`
có Expected Credit Limit.
`Supplier`
có Expected Payment Term.
`Invoice`
có Expected Approval Flow.
`Batch`
có Expected Yield.
`BOM`
có Expected Material Usage.
`Employee`
có Expected Payroll/PIT relationship.
Đây là lý do:
**Business Object Model phải đi trước Detection Engine.**
## 7. Ví dụ Finance: AP Invoice
Business Object:
`Invoice`.
Expected State:
- PO exists;
- Receipt exists;
- amount within tolerance;
- supplier active;
- approval complete.
Actual State:
- PO exists;
- Receipt missing;
- invoice posted.
Deviation:
`Receipt_Missing`.
Detection:
`AP Control Exception`.
Issue:
`Potential unsupported liability`.
Case:
`CASE-AP-014`.
Action:
Buyer review.
Outcome:
Validated / reversed / corrected.
Đây là Continuous Accounting Detection.
## 8. Ví dụ Finance: AR Collection
Business Object:
`Invoice`.
Expected Behavior:
`Payment by Due Date`.
Actual:
`Overdue 47 days`.
Nhưng có thể có Expected Behavior sâu hơn:
Nếu invoice overdue >30:
expected:
`Collection Case = Open`.
Nếu >45:
expected:
`Escalation = Sales Manager`.
Nếu >60:
expected:
`Credit Review = Required`.
Như vậy system không chỉ kiểm tra invoice có overdue không, mà còn kiểm tra:
> **doanh nghiệp đã phản ứng đúng chưa?**
## 9. Transaction Control và Management Control khác nhau
Transaction Control hỏi:
> transaction đúng không?
Management Control hỏi:
> khi exception xảy ra, organization có phản ứng đúng không?
Ví dụ:
AR overdue 50 ngày.
Transaction có thể hoàn toàn đúng.
Nhưng nếu không có:
- owner;
- collection action;
- escalation;
thì:
**management process đang sai Expected Behavior.**
## 10. Ví dụ Tax: Revenue Consistency
Business Objects:
`GL Revenue`
`E-Invoice`
`VAT Return`
`CIT Return`.
Expected State:
sau các timing/reconciliation adjustment hợp lệ, các nguồn phải reconcile.
Actual:
VAT Revenue thấp hơn GL 8%.
Detection:
`Tax Data Consistency Exception`.
System không nên kết luận ngay:
> tax error.
Nó nên hỏi:
- timing?
- non-taxable revenue?
- credit note?
- posting issue?
Nếu không có reason code hợp lệ:
→ create Tax Case.
## 11. Ví dụ Tax: Obligation Behavior
Business Object:
`Tax Obligation`.
Expected State:
- filed before due date;
- payment completed;
- evidence retained.
Actual:
Filed = Yes.
Evidence = Missing.
Compliance Status:
Filed.
Risk:
Medium/High.
Điểm quan trọng:
> **Expected State nhiều chiều hơn một Yes/No field.**
## 12. Ví dụ Payroll
Business Objects:
`Employee`
`Payroll`
`PIT`
`Social Insurance`
`GL Expense`.
Expected Relationship:
`Payroll`
↔ `PIT`
↔ `BHXH`
↔ `GL`.
Actual:
Payroll Expense tăng 30%.
PIT base không đổi.
System tạo:
`Consistency Deviation`.
Sau đó cần reasoning:
- bonus non-taxable?
- contractor?
- foreign employee?
- timing?
Đây là reconciliation-driven detection.
## 13. Ví dụ Manufacturing: Batch Yield
Business Object:
`Batch`.
Expected State:
`Yield ≥ 97%`.
Actual:
`91%`.
Detection:
`Yield Exception`.
Nếu Yield < 95%, expected process có thể là:
- Quality Review;
- Production Review;
- Root Cause Case.
Nếu system không tạo case thì đó lại là:
**process-control exception.**
Như vậy có thể có:
`Operational Exception`
và:
`Control Exception`
cùng lúc.
## 14. Ví dụ Manufacturing: BOM Usage
Expected:
`Actual Material Usage`
nằm trong tolerance của:
`BOM Standard`.
Actual:
+7%.
Detection:
`Material Variance`.
Nhưng system nên kiểm tra thêm:
- correct BOM revision?
- approved substitution?
- valid material lot?
- rework?
- scrap recorded?
Expected State vì vậy không chỉ là:
`Variance ≤ 5%`.
Nó là:
**context-dependent behavior.**
## 15. Context quyết định Expected State
Một threshold cố định thường quá đơn giản.
Ví dụ:
Yield 95% có thể tốt với SKU A nhưng xấu với SKU B.
AR 45 ngày có thể bình thường với customer terms 60 days nhưng nghiêm trọng với terms 30 days.
Do đó Expected State phải gắn với:
**Business Context.**
Ví dụ:
`Expected_Due_Date = Invoice Date + Customer Payment Term`.
Không nên hard-code:
`30 days`.
## 16. Expected State nên hỗ trợ Conditional Logic
Ví dụ:
IF:
`Vendor_Type = New`
THEN:
`2-level approval required`.
IF:
`Amount > 500M`
THEN:
`CFO approval required`.
IF:
`Material = Critical`
THEN:
`QA certificate required`.
Expected Behavior phải hỗ trợ:
`Context → Condition → Expected State`.
## 17. Expected State cũng cần versioning
Business rule thay đổi theo thời gian.
Ví dụ:
Approval threshold 2026:
`100 triệu`.
2027:
`200 triệu`.
Nếu system audit transaction năm 2026, phải dùng:
**rule version năm 2026.**
Do đó Expected State cần:
- Effective From;
- Effective To;
- Rule Version.
Đây là:
**temporal control context.**
## 18. Không có versioning sẽ tạo false positive
Nếu dùng rule hiện tại để kiểm tra historical transaction, system có thể báo sai.
Ví dụ:
Tax Rule 2027 áp vào transaction 2026.
Hoặc BOM Rev.08 áp vào batch chạy bằng Rev.07.
Do đó:
> **Expected State phải đúng theo thời điểm.**
## 19. Expected Behavior có thể học từ lịch sử
Không phải mọi expectation đều viết được thành rule.
Ví dụ Journal Entries thường có:
- account combination;
- amount range;
- posting time;
- user pattern.
System có thể học:
**normal behavior.**
Sau đó Actual khác pattern:
→ anomaly.
Đây là:
**learned Expected Behavior.**
## 20. Anomaly không đồng nghĩa Issue
Một anomaly chỉ là:
> khác bình thường.
Nó chưa chắc sai.
Ví dụ Marketing Expense tăng gấp 5 có thể vì campaign launch.
Do đó:
`Anomaly Detection`
→ `Context Check`
→ `Materiality`
→ `Issue`.
Không nên:
`Anomaly = Issue`.
## 21. Detection ≠ Issue
Một engine tốt phải tách:
### Detection
Một deviation được phát hiện.
### Issue
Deviation đủ material và meaningful để quản trị.
Ví dụ:
1.000 journal anomalies.
Sau dedupe + materiality:
chỉ còn:
12 Issues.
Nếu không tách hai lớp, doanh nghiệp sẽ bị:
**alert fatigue.**
## 22. Materiality phải nằm giữa Detection và Issue
Một deviation nhỏ có thể không cần action.
Ví dụ:
GL vs VAT difference:
`0,02%`.
Có thể do rounding.
System nên có:
`Materiality Filter`.
Ví dụ:
`Absolute Value`
+
`Percentage`
+
`Risk Type`
+
`Frequency`.
Sau đó mới quyết định:
`Create Issue?`
## 23. Materiality cũng phải theo Context
Variance 1 triệu không đáng kể với doanh nghiệp lớn nhưng có thể material với một branch nhỏ.
Do đó Materiality Rule nên có:
- entity;
- account;
- process;
- risk class.
Không nên chỉ dùng một threshold toàn doanh nghiệp.
## 24. Detection Result cần lưu Actual và Expected
Data Model nên lưu tối thiểu:
`Actual_State`
`Expected_State`
`Deviation`
`Tolerance`
`Context`
`Evidence`
`Detector_Type`
`Rule_Version`.
Đây là dữ liệu rất quan trọng.
Nó cho phép:
- audit;
- explainability;
- learning.
## 25. Root Cause không nên nằm trong Detection Rule
Detection Rule chỉ nên trả lời:
> có deviation không?
Root Cause là bước sau.
Ví dụ:
Detection:
`Yield < Standard`.
Root Cause có thể là:
- material;
- machine;
- operator;
- BOM.
Không nên encode toàn bộ reasoning vào detector.
Điều này giúp kiến trúc:
**modular.**
## 26. AI nên tham gia ở đâu?
AI phù hợp sau Detection.
`Detection`
→ AI phân tích context.
AI có thể:
- classify issue;
- suggest root cause;
- find similar cases;
- recommend action.
Nhưng Expected State cốt lõi nên càng:
**explicit và explainable**
càng tốt.
## 27. Continuous Diagnostic Engine thực chất là “Expectation Engine”
Nếu nhìn sâu hơn:
Common Diagnostic Engine không chỉ là detector.
Nó là:
> **Expectation Engine.**
Nó quản lý:
- doanh nghiệp kỳ vọng điều gì;
- actual đang là gì;
- deviation bao nhiêu;
- có material không;
- ai xử lý.
Đây là cách nhìn rất mạnh.
## 28. Một schema đơn giản cho Expected State
Có thể bắt đầu với:
`Expected_State_ID`
`Business_Object_Type`
`Condition`
`Expected_Field`
`Expected_Value / Range`
`Tolerance`
`Effective_From`
`Effective_To`
`Rule_Source`
`Owner`
`Severity_Default`
`Detector_Type`
`Version`.
Không cần phức tạp hơn ngay từ đầu.
## 29. Rule Source cần được lưu
Expected State đến từ đâu?
Ví dụ:
- Regulation;
- Accounting Policy;
- SOP;
- Contract;
- BOM Standard;
- Management Rule;
- Historical Pattern.
Lưu `Rule_Source` giúp:
**explainability.**
Ví dụ system nói:
> Invoice cần 2-level approval.
Finance có thể biết:
> rule này đến từ Approval Policy v3.1.
## 30. Owner của Expected State cũng quan trọng
Ai chịu trách nhiệm cho expectation?
Ví dụ:
BOM Standard:
Engineering.
Tax Obligation:
Tax Manager.
Approval Matrix:
CFO.
Supplier Lead Time:
Supply Chain.
Nếu rule sai, phải biết ai update.
Đây là:
**Rule Governance.**
## 31. Expected State và Protected Business Objects
Một số Expected State liên quan Protected Objects.
Ví dụ:
- BOM Revision;
- Standard Cost;
- Tax Rule;
- Approval Matrix.
AI có thể phát hiện:
> Expected State có vẻ không còn phù hợp.
Nhưng không nên tự sửa.
Nó chỉ nên:
`Propose Change`.
Sau đó:
`Impact Analysis`
→ `Approval`
→ `Version Update`.
## 32. Expected State và Finance Case
Detection phát hiện deviation.
Sau materiality filter:
Issue được tạo.
Issue đủ quan trọng:
→ Finance Case.
Flow:
`Expected State`
vs
`Actual State`
↓
`Deviation`
↓
`Detection`
↓
`Issue`
↓
`Case`
↓
`Action`
↓
`Outcome`.
## 33. Expected State và Tax Case
Ví dụ:
Expected:
`VAT ↔ GL reconciled`.
Actual:
Mismatch 8%.
Detection:
Tax Consistency Deviation.
Issue:
Unexplained Revenue Difference.
Case:
`CASE-TAX-014`.
Owner:
Tax Manager.
Action:
Reconciliation.
Outcome:
Documented timing difference.
Risk reduced.
## 34. Expected State và Smart Factory Lite
Digital Batch Record cung cấp:
**Actual State.**
BOM / Routing / Yield Standard cung cấp:
**Expected State.**
Difference tạo:
**Operational Exception.**
Đây là cách rất tự nhiên để Smart Factory Lite chạy Continuous Detection mà không cần AI phức tạp ngay từ đầu.
## 35. Common Diagnostic Engine lúc này có thể được hiểu rất đơn giản
Input:
`Business Objects + Transactions`.
Layer 1:
**Expected State Registry.**
Layer 2:
**Detection Engine.**
Layer 3:
**Issue Engine.**
Layer 4:
**Case / Action.**
Layer 5:
**Outcome.**
AI có thể tham gia ở nhiều layer nhưng không phải nền tảng duy nhất.
## 36. Hai Diagnostic Pack đầu tiên
### Finance Value Leakage Pack
Expected States như:
- AR within terms;
- margin within threshold;
- inventory within target;
- cost within standard;
- forecast within tolerance.
### Tax Health Check Pack
Expected States như:
- obligation complete;
- evidence available;
- master data valid;
- returns consistent;
- transactions explainable.
Cùng một engine.
Khác expectation library.
## 37. Sau này Smart Factory Lite cũng chỉ là một Diagnostic Pack khác
Expected States:
- Yield;
- BOM Usage;
- Scrap;
- Downtime;
- Quality;
- Material Availability.
Điều này cho thấy:
> **một Common Diagnostic Engine có thể mở rộng khá xa mà không thay kiến trúc lõi.**
## 38. Từ Rule Engine sang Expectation Management
Rule Engine thường nghe rất kỹ thuật.
Nhưng business thực chất đang quản lý:
> **kỳ vọng vận hành.**
Finance kỳ vọng:
Invoice đúng control.
Tax kỳ vọng:
Data reconcile.
Production kỳ vọng:
Yield đạt chuẩn.
Supply Chain kỳ vọng:
Material đến đúng lúc.
Expected State Model chính là cách số hóa:
**management expectations.**
## 39. Continuous Detection chỉ có ý nghĩa khi có Continuous Action
Phát hiện liên tục nhưng không hành động chỉ tạo nhiều alert hơn.
Do đó:
`Detection`
phải dẫn tới:
`Issue`
→ `Owner`
→ `Action`
→ `Outcome`.
Expected State không phải dashboard concept.
Nó là:
**management-control concept.**
## 40. Nguyên tắc cốt lõi
Có thể tóm gọn toàn bộ bằng một câu:
> **Một doanh nghiệp có thể được quản trị như tập hợp các Business Objects có Expected States; khi Actual State lệch khỏi Expected State đủ material, hệ thống phải tạo Issue và kích hoạt Action.**
Đây là abstraction rất mạnh.
# Kết luận
Continuous Diagnostic Engine không nhất thiết bắt đầu bằng AI.
Nó bắt đầu bằng một câu hỏi cơ bản:
> **Điều gì đáng lẽ phải xảy ra?**
Sau đó mới hỏi:
> **Điều gì thực sự đang xảy ra?**
Khoảng cách giữa hai thứ là:
**Deviation.**
Nếu deviation đủ material, nó trở thành:
`Detection`
→ `Issue`
→ `Case`
→ `Action`
→ `Outcome`.
Với cách nhìn này:
Finance Value Leakage,
Tax Health Check,
Continuous Accounting Detection,
và Smart Factory Lite
đều có thể dùng chung một logic lõi:
`Business Object`
→ `Expected State`
→ `Actual State`
→ `Deviation`
→ `Issue`
→ `Action`
→ `Outcome`.
Điểm quan trọng không nằm ở việc doanh nghiệp có AI mạnh tới đâu.
Mà nằm ở việc doanh nghiệp có biết:
> **mình kỳ vọng hệ thống phải vận hành như thế nào hay không.**
Khi Expected State được số hóa, version hóa và gắn với Business Object:
AI mới có context để reasoning.
Rule Engine mới có cơ sở để kiểm tra.
Management mới biết deviation nào cần xử lý.
Và khi đó Continuous Detection mới thực sự trở thành:
**Continuous Management.**