# BAN DỰ ÁN BTCHEM — GIẢI ĐÁP CÁC CÂU HỎI CHI TIẾT

> Tài liệu trả lời các câu hỏi trong file gốc, dựa trên:
> - Cẩm nang triển khai ERP (IZISolution / ERPViet, 36 trang)
> - Đề cương triển khai ERP cho BTChem (09/06/2026)
> - Tài liệu tham khảo ERP (web research, 09/06/2026)
> - Quy trình Bán hàng BTChem (rà soát 05/06/2026)
> - Báo cáo Xử lý Không Phù Hợp (09/06/2026)

---

## 📌 Câu hỏi 1: Làm sao để dịch các yêu cầu kinh doanh và vận hành thành thông số kỹ thuật thiết kế hệ thống?

### Trả lời:

Đây chính là bước **"Phân tích thiết kế hệ thống"** được mô tả trong **Phần III.C của cẩm nang ERP**. Quy trình này có 3 bước cụ thể:

#### Bước 1: Ban dự án lập "Bảng ánh xạ Yêu cầu → Thông số"

Đây là công cụ chính để dịch. Ban dự án và vendor (nhà cung cấp) cùng ngồi lại, đi qua từng yêu cầu và ghi vào bảng:

| Cột               | Mô tả                                                                           | Ví dụ cho BTChem                                                                                                                                                                                                                   |
| ----------------- | ------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Yêu cầu nghiệp vụ | Câu chuyện từ người dùng: "Tôi cần biết khi nào hàng sẵn sàng để trả lời khách" | PKD muốn có ngày giao dự kiến ngay khi nhập đơn                                                                                                                                                                                    |
| Mô tả chi tiết    | Ngữ cảnh, tần suất, ai làm, ngoại lệ                                            | Mỗi đơn hàng, PKD nhập SL + SP → hệ thống tự tính ngày giao dựa trên tồn kho + thời gian SX                                                                                                                                        |
| Thông số kỹ thuật | Vendor dịch ra: field dữ liệu, rule, logic                                      | Thêm field `Ngày giao dự kiến` trên màn hình ĐH. Logic: Nếu tồn kho ≥ SL ĐH → Ngày giao = Ngày hiện tại + 1 ngày (giao từ kho). Nếu thiếu → Ngày giao = Ngày SX dự kiến + 2 ngày (SX + chờ khô). Auto tính khi nhấn "Xác nhận ĐH". |
| Module            | Module nào chịu trách nhiệm                                                     | OM (Order Management)                                                                                                                                                                                                              |
| Ưu tiên           | Cao/Trung bình/Thấp                                                             | Cao                                                                                                                                                                                                                                |

**Lưu ý quan trọng từ cẩm nang (trang 17):** Không chỉ vendor dịch — **ban dự án phải xác nhận** bản dịch đó có đúng ý không. Nguyên tắc: "không có giả định nào được bỏ qua, mọi thứ đều phải được ghi lại và ký xác nhận".

#### Kỹ thuật phỏng vấn Key User — Tránh sa đà vào quy trình hiện tại rời rạc

Một rủi ro rất thực tế: Key Users khi được hỏi sẽ mô tả lại **quy trình hiện tại vốn dĩ đã lộn xộn** — những thói quen được sinh ra vì "tại anh A không biết Excel", "tại chị B quen làm thế này từ lâu", "tại máy chạy chậm quá nên phải bypass", v.v. Nếu vendor cứ ghi y nguyên vào bản khảo sát, ERP sẽ nhân đôi sự lộn xộn đó.

**4 cách tránh sa đà vào quy trình hiện tại rời rạc:**

**Cách 1 — Luôn hỏi "MỤC TIÊU", không hỏi "CÁCH LÀM"**

| Hỏi sai (dễ sa đà) | Hỏi đúng (hướng đến To-Be) |
|--------------------|---------------------------|
| "Hiện tại anh làm cái này thế nào?" | "Anh cần kết quả gì từ cái này?" |
| "Tại sao phải gọi điện xác nhận công nợ?" | "Nếu có hệ thống tự động check công nợ, anh muốn nó báo như thế nào?" |
| "Hồ sơ giấy anh lưu ở đâu?" | "Nếu toàn bộ dữ liệu trên một màn hình, anh muốn xem thông tin gì đầu tiên?" |

Một Key User có thể mất 30 phút kể lể "từ hồi đó tới giờ tôi làm kiểu này" — nếu quên hỏi câu "anh muốn kết quả gì?". Ban dự án + vendor phải luôn lái câu hỏi về **đầu ra mong muốn (desired output)**, không phải **cách làm hiện tại (current method)**.

**Cách 2 — Sử dụng kịch bản "giả định" (hypothetical scenario) thay vì hỏi quá khứ**

Thay vì "kể cho tôi quy trình xuất kho hiện tại", hãy nói:
> *"Giả sử một khách hàng mới (chưa từng mua) gọi đặt 500kg sơn UV, yêu cầu giao trong 3 ngày. Anh sẽ làm những bước nào, theo thứ tự nào?"*

Khi đặt vào tình huống giả định, Key User **không thể sa đà vào quy trình cũ** vì tình huống này chưa từng xảy ra — họ **buộc phải nghĩ về quy trình lý tưởng**. Đây là cách hiệu quả nhất để phát hiện gap: so sánh câu trả lời "lý tưởng" với thực tế.

**Cách 3 — Vẽ "Bản đồ luồng xử lý lý tưởng" trước, điều chỉnh sau**

Vendor chủ động vẽ một flowchart mẫu cho quy trình chuẩn của ERP, rồi nói:
> *"Đây là cách ERP làm việc này. Anh xem có bước nào không phù hợp với nhà máy mình không?"*

Làm vậy, Key User sẽ **chỉ ra ngoại lệ** (exception) thay vì kể toàn bộ câu chuyện rối rắm. Nhanh hơn 3 lần và ít sai lệch hơn.

**Cách 4 — Tách bạch: Nguyên nhân kỹ thuật ≠ Quy trình mong muốn**

Nếu Key User nói "cái này phải làm tay vì máy chạy chậm" hoặc "thủ kho không biết Excel", hãy **gạch dưới** và ghi chú: *"Vấn đề kỹ thuật/skill — sẽ giải quyết sau. KHÔNG nhập vào quy trình To-Be."* 

Những giới hạn như: máy tính chậm, nhân viên không biết Excel, thói quen làm tay — là **vấn đề sẽ được giải quyết bởi ERP**, không phải lý do để thiết kế quy trình xấu đi.

**Tóm lại:**
| Sai lầm | Hậu quả | Cách tránh |
|---------|---------|-----------|
| Hỏi "cách làm hiện tại" | Sao chép sự lộn xộn vào hệ thống mới | Hỏi "kết quả mong muốn" |
| Để Key User kể tự do | Mất thời gian, lạc hướng | Dùng kịch bản giả định |
| Để vendor nghe và ghi | Vendor hiểu sai, thiết kế sai | Vendor chủ động vẽ mẫu trước |
| Nhập vấn đề kỹ thuật vào quy trình | Hệ thống mới cũng chậm và lỗi | Tách bạch technical vs business |

---

#### Bước 2: Sử dụng "Use Case" (kịch bản sử dụng) thay vì mô tả chung chung

Thay vì nói "tôi muốn quản lý tồn kho tốt hơn", hãy viết thành **kịch bản cụ thể**:

> *"Khi nhân viên PKD nhập đơn hàng 100kg sơn UV màu trắng cho khách A, hệ thống sẽ: (1) Kiểm tra tồn kho thành phẩm — nếu còn 50kg → báo thiếu 50kg. (2) Tự động đề xuất sản xuất 50kg dựa trên BOM có sẵn. (3) Tính ra cần 30kg resin A, 10kg pigment B, 8kg dung môi C. (4) Kiểm tra tồn NVL — nếu thiếu → đề xuất mua. (5) Trả về ngày giao dự kiến cho PKD."*

**Đây là cách duy nhất để vendor hiểu chính xác.** Cẩm nang gọi đây là "xác định và mô tả yêu cầu của doanh nghiệp" — nếu yêu cầu mơ hồ, thông số kỹ thuật sẽ sai.

#### Bước 3: Vendor trả lời bằng "Functional Specification" (Đặc tả chức năng)

Sau khi nhận bảng ánh xạ + use case, vendor sẽ trả lời bằng một tài liệu gọi là **Functional Specification (FS)** — đặc tả chức năng. FS gồm:

- **Giao diện người dùng:** Màn hình nào, field nào, nút bấm nào
- **Luật nghiệp vụ:** Điều kiện, công thức, cảnh báo
- **Báo cáo:** Mẫu báo cáo, chỉ tiêu, định kỳ
- **Dữ liệu:** Cấu trúc, quan hệ giữa các bảng

**Nhiệm vụ của ban dự án:** Đọc FS và trả lời "Đúng" hoặc "Sửa". Không thông qua nếu chưa hiểu hoặc chưa đúng.

---

## 📌 Câu hỏi 2: Làm sao đảm bảo vendor hiểu sát nhu cầu và ban quản lý dự án có phản hồi chính xác?

### Trả lời:

Có 4 công cụ để đảm bảo điều này:

#### 1. **Workshop khảo sát (Discovery Workshop) — 2-3 ngày liên tục**

Đây là bước quan trọng nhất trong **Phase 1 của lộ trình triển khai cho BTChem (Đề cương, trang 4)**. Vendor sẽ cử chuyên gia đến doanh nghiệp, phỏng vấn **từng Key User** (người dùng chủ chốt) của từng phòng ban.

**Key User đóng vai trò then chốt** — như đã phân tích trong tài liệu Triết lý vận hành ERP (Phần 2.2). Họ là người hiểu rõ nhất nghiệp vụ của phòng mình và phải tham gia trực tiếp vào việc:
- Giải thích quy trình hiện tại (As-Is)
- Chỉ ra điểm đau (pain point)
- Đề xuất quy trình mong muốn (To-Be)
- Xác nhận bản dịch của vendor có đúng không

**Cách thực hiện cho BTChem:**
| Ngày | Sáng (8h-12h) | Chiều (13h-17h) |
|------|---------------|------------------|
| Ngày 1 | Kho (INV) + Sản xuất (MFG) | Kế hoạch SX + Kỹ thuật |
| Ngày 2 | Bán hàng (OM) + Mua hàng (PO) | QC (QM) |
| Ngày 3 | Kế toán (FIN) + Tổng kết gap | Trình bày Blueprint sơ bộ |

Mỗi buổi: Key User trình bày → Vendor vẽ flowchart ngay tại chỗ → Cả hai xác nhận → Ký biên bản.

#### 2. **Bảng câu hỏi khảo sát (Questionnaire) — gửi trước 1 tuần**

Gửi cho từng Key User trước workshop. Mẫu câu hỏi:
- "Mỗi ngày anh/chị nhận bao nhiêu đơn hàng? Trung bình?"
- "Anh/chị mất bao lâu để xử lý một đơn? Bước nào lâu nhất?"
- "Khi có sai sót, ai phát hiện? Mất bao lâu?"
- "Báo cáo nào anh/chị cần xem hàng ngày/hàng tuần?"
- "Điều gì làm anh/chị khó chịu nhất trong quy trình hiện tại?"

**Kết quả:** Vendor có dữ liệu thực tế, không phải suy luận.

#### 3. **Quy trình phản hồi 3 vòng (3-round review)**

Đây là cơ chế mà **ban quản lý dự án** phải áp dụng để đảm bảo phản hồi chính xác:

| Vòng | Ai làm | Sản phẩm | Thời gian |
|------|--------|----------|-----------|
| Vòng 1 | Vendor gửi FS (đặc tả chức năng) dựa trên workshop | Bản FS draft | Sau workshop 2 tuần |
| Vòng 2 | Key User đọc + góp ý | FS có comment | 1 tuần |
| Vòng 3 | Vendor sửa + gửi lại → Key User xác nhận | FS signed-off | 1 tuần |

**Nguyên tắc:** Key User phải đọc kỹ từng dòng. Nếu không hiểu, **bắt buộc phải hỏi** — không được "xuôi" rồi sau này mới biết sai. Cẩm nang gọi đây là "xác định trách nhiệm của Key User trong việc thẩm định và đề xuất quy trình tối ưu".
  
  
  Câu hỏi : Làm sao để tránh việc chuyên gia hoặc ban quản lý dự án hỏi Key User , họ lại trả lời quá sa đà vào các qui trình hiện tại, vốn dĩ nó là những công việc rời rạc và thiếu nhất quán, được sinh ra xuyên suốt quá trình vận hành vì lý do các nhân con người, điểm yếu của quản lý và các vấn đề giới hạn kĩ thuật ( như máy tính,khả năng tin học, trình độ nhận thực của nhân viên quản lý )? 
#### 4. **Demo kịch bản thực tế (Scenario Demo)**

Trước khi ký hợp đồng, yêu cầu vendor **demo bằng dữ liệu thật của BTChem**, không phải demo mẫu có sẵn. Ví dụ:
> *"Anh show tôi màn hình khi nhập đơn hàng 200kg sơn UV màu AQ 1065, khách Modus, giá 85.000đ/kg, CK 5%. Hệ thống tự động tính ra tổng tiền, kiểm tra công nợ, kiểm tra tồn, và trả ngày giao dự kiến — trong vòng 30 giây."*

Nếu vendor không demo được điều này, họ chưa hiểu nhu cầu của anh.

---

## 📌 Câu hỏi 3: Có lỗ hổng lớn không nếu dùng Microsoft Dynamics 365 Business Central?

### Trả lời:

Dựa trên tài liệu tham khảo ERP (mục 3 + 6), **Microsoft Dynamics 365 Business Central (BC) phù hợp với SME — nhưng có một số lỗ hổng cần lưu ý**:

#### Điểm mạnh của Dynamics 365 BC với BTChem:
- ✅ Batch & Formula Management (quản lý lô & công thức) — **có**
- ✅ Lot Traceability (truy xuất lô) — **có**
- ✅ Integrated financials & costing (kế toán & giá thành tích hợp) — **có**
- ✅ AI forecasting (dự báo bằng AI) — **có**
- ✅ Tích hợp Office 365, Power BI — **có**
- ✅ Cloud-native (bản SaaS), không cần lo hạ tầng

#### Các lỗ hổng tiềm năng (Gap Analysis):
Tôi cần giải thích sâu hơn về các vấn đề : Thuộc tính lô , của vấn đề quản lý BOM, với nữa là nếu công thức chỉ có thành phần, % khối lượng của chúng, và qui trình khuấy như thời gian nhập liệu, qui trình khuấy ,.... thì nó có đáp ứng được không? 

| Yêu cầu của BTChem                                                       | Dynamics 365 BC                                                                                                                                    | Mức độ lỗ hổng            | Giải pháp                                                                                                                                                           |
| ------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Quản lý BOM / công thức pha chế sơn UV**                               | Có tính năng BOM cơ bản, nhưng **không chuyên sâu cho hoá chất** — không quản lý được công thức có biến thiên theo nhiệt độ, độ ẩm, lô nguyên liệu | ⚠️ Lỗ hổng **trung bình** | Cần kiểm tra: BC có hỗ trợ "batch attributes" (thuộc tính lô) không? Nếu không, cần ISV (Independent Software Vendor — giải pháp bổ sung từ bên thứ ba) hoặc custom |
| **Hazardous material handling (quản lý hoá chất nguy hiểm)**             | BC có module cơ bản, nhưng các tính năng GHS/SDS (bảng chỉ dẫn an toàn hoá chất) là **add-on** (phải mua thêm)                                     | ⚠️ Lỗ hổng **trung bình** | Cần yêu cầu vendor báo giá add-on GHS/SDS                                                                                                                           |
| **Regulatory Compliance (tuân thủ quy định)** Tôi cần giải thích thêm ?  | BC có thể đáp ứng qua các extension                                                                                                                | 🟢 Có thể đáp ứng         | Yêu cầu vendor chứng minh (show compliance case study)                                                                                                              |
| **Shelf-life tracking (theo dõi hạn dùng)**                              | Có sẵn, nhưng **cấu hình cho hoá chất phức tạp hơn thực phẩm**                                                                                     | 🟢 Nhẹ                    | Cần cấu hình batch expiration và quality hold                                                                                                                       |
| **Cấp phát NVL theo BOM (pick + consume)**                               | Có, nhưng không hỗ trợ **cấp phát theo lô / phân bổ theo thùng** kiểu hoá chất (mở thùng → dùng 1 phần → còn lại cho SX sau)                       | ⚠️ Lỗ hổng **trung bình** | Cần custom hoặc thêm ISV                                                                                                                                            |
| **Hệ thống QC gắn với lô SX**                                            | Có inspection orders, nhưng **phải kiểm tra khả năng gắn với COA (Certificate of Analysis)**                                                       | 🟢 Nhẹ                    | Test kỹ trong UAT                                                                                                                                                   |
| **Quản lý KTV hiện trường / khiếu nại**                                  | **Không có** — đây là CRM, không phải ERP core                                                                                                     | 🔴 **Lỗ hổng lớn**        | **Không nên cố nhồi vào ERP.** Đây là lý do BTChem cần CRM Phase 2 riêng (chi tiết trong Đề cương, mục 5)                                                           |
| **Quản lý mẫu màu & lịch sử công thức pha màu**                          | **Không có**                                                                                                                                       | 🔴 **Lỗ hổng lớn**        | Dời CRM Phase 2 hoặc làm Excel trước                                                                                                                                |
| **Báo giá kỹ thuật kèm quy trình sơn**                                   | **Không có**                                                                                                                                       | 🔴 **Lỗ hổng lớn**        | CRM Phase 2                                                                                                                                                         |

#### Tổng kết lỗ hổng:

| Mức độ | Số lượng | Có xử lý được không? |
|--------|:--------:|---------------------|
| 🔴 Lỗ hổng lớn (không có trong BC) | 3 | **Có** — dời CRM Phase 2 (theo đúng lộ trình của BTChem) |
| ⚠️ Lỗ hổng trung bình (có nhưng yếu) | 3 | **Có** — cần kiểm tra kỹ demo, có thể cần ISV hoặc custom |
| 🟢 Lỗ hổng nhẹ (cấu hình được) | 2 | **Có** — test UAT là xong |

**Kết luận:** **Không có lỗ hổng "quá lớn" nào không thể xử lý — miễn là anh tách bạch ERP vs CRM.** Nếu cố nhồi tất cả vào Dynamics 365 BC, lỗ hổng sẽ trở nên quá lớn và dự án thất bại. Nhưng nếu theo đúng lộ trình (ERP Phase 1 → CRM Phase 2), Dynamics 365 BC là lựa chọn khả thi cho SME ngành hoá chất.

**Khuyến nghị:**
1. Trước khi ký hợp đồng với Microsoft Dynamics 365 BC, yêu cầu vendor **demo 3 kịch bản khó nhất**: (a) Pha chế sơn UV theo BOM có biến thiên, (b) Kiểm tra tồn kho realtime + cảnh báo hết hạn, (c) Chiết tính giá tự động + kiểm tra công nợ
2. Hỏi vendor về **ISV partners** cho ngành hoá chất (VD: BatchMaster, Logility, v.v.)
3. Yêu cầu vendor cung cấp **case study** (doanh nghiệp sơn/hoá chất Việt Nam đã triển khai BC thành công)

---

### ❓ ISV Partners là gì?

**ISV** = Independent Software Vendor (Nhà cung cấp phần mềm độc lập).

#### Khái niệm đơn giản:

Hãy tưởng tượng Dynamics 365 BC giống như **một căn nhà cơ bản** — có tường, mái, cửa sổ, ổ điện. Nó đủ để ở. Nhưng nếu anh muốn lắp **bếp từ chuyên nghiệp** hay **hệ thống lọc nước trung tâm**, anh phải mua thêm từ các nhà cung cấp chuyên biệt. Đó là ISV.

**ISV partners** là các công ty viết thêm phần mềm chuyên ngành để **cắm vào** Dynamics 365 BC, bổ sung các tính năng mà BC không có sẵn.

#### Ví dụ ISV cho ngành hoá chất/sơn:

| ISV | Tính năng bổ sung | Giá (ước) |
|-----|------------------|:--------:|
| **BatchMaster** | Quản lý công thức hoá chất (Formula Management), GHS/SDS labeling, batch variability, shelf-life tracking | ~$200-500/tháng |
| **Logility** | Supply chain planning, demand forecasting chuyên sâu (dự báo nhu cầu dựa trên dữ liệu lịch sử) | ~$500-2000/tháng |
| **Sana Commerce** | Cổng thông tin KH (Customer Portal) — KH tự tra cứu giá, đặt hàng, xem tồn kho | Giá tuỳ quy mô |
| **Continia** | Quản lý chứng từ, phê duyệt hoá đơn, chi phí | ~$100-300/tháng |

#### Anh có cần ISV không?

**Trong Phase 1 (ERP Core):** Có thể **chưa cần**. Vì:
- BOM % khối lượng + field ghi chú quy trình là đủ dùng cho SME
- BatchMaster hay Logility là chi phí thêm, trong khi nhu cầu hiện tại chưa quá phức tạp
- Vendor Dynamics 365 BC có thể custom nhẹ để xử lý routing cơ bản

**Khi nào cần mua ISV:**
- Khi BTChem phát triển lên 100+ sản phẩm, mỗi sản phẩm có 20+ NVL đầu vào
- Khi cần tự động hoá quy trình khuấy (tốc độ, thời gian, thứ tự) — cần tích hợp với PLC/SCADA
- Khi cần GHS/SDS labeling tự động cho từng lô xuất hàng
- Khi cần KH tự tra cứu giá & đặt hàng online (Customer Portal)

**Khuyên nghị:** Phase 1 dùng BC chuẩn + custom nhẹ. Phase 2 (khi ổn định) mới tính đến ISV.

---

## 📌 Câu hỏi 4: Giải thích về Cấu trúc dữ liệu, Điểm tích hợp và Biện pháp bảo mật

### 4.1 Cấu trúc dữ liệu (Data Structure) là gì?

**Khái niệm đơn giản:**
Cấu trúc dữ liệu giống như **các ngăn trong tủ đồ**. Mỗi ngăn có tên (mã định danh), mô tả (các thuộc tính), và có quy tắc về việc cất đồ vào và lấy ra.

**Trong ERP, có 6 loại dữ liệu chính:**

| Loại | Ví dụ cho BTChem | Mô tả |
|------|------------------|-------|
| **Dữ liệu nền (Master Data)** | Mã SP (UV-White-001), mã KH (KH-Modus), mã NCC (NCC-ResinA), mã vật tư (VT-DungMoi-X) | Dữ liệu ít thay đổi, dùng chung toàn hệ thống. Là "từ điển" của ERP. |
| **Dữ liệu giao dịch (Transaction Data)** | Đơn hàng DH-2026-001, Lệnh SX SX-2026-001, Phiếu nhập kho NK-2026-001 | Dữ liệu phát sinh hàng ngày, gắn với master data. Mỗi giao dịch đều có số chứng từ riêng. |
| **Dữ liệu định mức (BOM/Formula)** | Công thức sơn UV trắng: Resin A 30% + Pigment W 15% + Dung môi X 55% = 100% | Định mức cho sản xuất. Cho biết để làm 1kg SP cần bao nhiêu NVL. |
| **Dữ liệu cấu hình (Configuration)** | Bảng giá, hạn mức công nợ, SLA thời gian xử lý | Các quy tắc kinh doanh được lập trình vào hệ thống. |
| **Dữ liệu phân quyền (Security Data)** | Ai được xem gì, ai được sửa gì, ai được duyệt | Vai trò người dùng và quyền hạn. |
| **Dữ liệu lịch sử (Audit Trail)** | Ai đã sửa đơn hàng số 001 lúc mấy giờ? | Tự động ghi lại mọi thay đổi — phục vụ kiểm tra, truy xuất. |

**Cấu trúc quan trọng nhất với BTChem:**

```
SẢN PHẨM (Master Data)
├── Mã SP: UV-T-001
├── Tên SP: Sơn UV trắng bóng 80%
├── Đơn vị: Kg
├── BOM (định mức):
│   ├── Resin A: 30% (mã: VT-RES-A-001)
│   ├── Pigment W: 15% (mã: VT-PIG-W-001)
│   └── Dung môi X: 55% (mã: VT-DM-X-001)
├── Bảng giá:
│   ├── KH Modus: 85.000đ/kg
│   └── KH Khác: 90.000đ/kg
├── Tồn kho hiện tại: 500kg
└── Quy cách đóng gói: Thùng 20kg
```

**Mỗi khi nhập đơn hàng, ERP sẽ:**
1. Lấy mã SP từ Master Data → tra BOM → biết cần NVL gì, bao nhiêu
2. Tra bảng giá → tự động tính tiền
3. Tra tồn kho → biết còn bao nhiêu
4. Ghi nhận giao dịch → tự động xuất kho, trừ tồn, ghi sổ kế toán

### 4.2 Điểm tích hợp (Integration Points) là gì?

**Khái niệm đơn giản:**
Điểm tích hợp là **những "cây cầu" nối các module lại với nhau**. Khi module A thay đổi, module B tự động biết và cập nhật theo.

**Các điểm tích hợp quan trọng cho BTChem:**

| # | Cầu nối | Mô tả | Lợi ích |
|---|---------|-------|---------|
| 1 | **Bán hàng → Kho** | Khi PKD xác nhận đơn → kho biết cần giữ hàng | Không bán hàng đã hứa cho khách khác |
| 2 | **Bán hàng → Sản xuất** | Khi đơn vượt tồn → tự động tạo lệnh SX | PKD không cần gọi điện báo xưởng |
| 3 | **Sản xuất → Kho NVL** | Khi tạo lệnh SX → kho tự động xuất NVL theo BOM | Không thiếu NVL giữa chừng |
| 4 | **Mua hàng → Kho → QC** | Khi nhận NVL → QC tự động biết cần kiểm tra | Không bỏ sót lô hàng chưa QC |
| 5 | **Bán hàng/SX → Kế toán** | Mọi giao dịch → tự động hạch toán | Kế toán không cần nhập lại |
| 6 | **Kho → SX → Bán hàng** | Khi SX xong, nhập kho → tồn tự động tăng, PKD thấy để hẹn giao | Thông tin realtime |

**Ví dụ cụ thể chuỗi tích hợp khi có đơn hàng 100kg sơn UV cho khách Modus:**

```
Bước 1: PKD nhập ĐH → Kiểm tra tồn (500kg) → Đủ hàng → Hẹn giao T+1
         ↓
Bước 2: Kho nhận lệnh xuất → Xuất 100kg → Ghi giảm tồn (còn 400kg)
         ↓
Bước 3: Kế toán tự động ghi: Nợ 632/Có 156 (giá vốn) + Nợ 131/Có 511 (doanh thu)
```

**Nếu không có tích hợp:** PKD hẹn giao → Gọi điện cho kho: "còn hàng không?" → Kho kiểm tra sổ → Báo lại → Kế toán chờ cuối tháng mới nhập sổ. Mất ít nhất 3 bước điện thoại + 2 lần nhập liệu thủ công + 1 lần đối chiếu.

**Với tích hợp:** Mọi thứ xảy ra tự động trong 5 giây.

### 4.3 Biện pháp bảo mật (Security Measures)

Căn cứ theo cẩm nang ERP (trang 28-29), 3 lớp bảo mật cho hệ thống ERP:

#### Lớp 1: Phân quyền người dùng (Role-Based Access Control — RBAC)

Đây là lớp quan trọng nhất và hay bị bỏ qua nhất. Mỗi người chỉ được thấy và làm những gì liên quan đến công việc của họ.

**Đề xuất phân quyền cho BTChem (dựa trên đề cương):**

| Vai trò | Module được xem | Quyền | Không được làm |
|---------|----------------|-------|----------------|
| **PKD** | OM, INV (tồn kho) | Xem giá, tạo ĐH, in báo cáo | Sửa giá, duyệt CK > hạn mức, xóa ĐH |
| **Thủ kho (KTP)** | INV, PO | Nhập/xuất kho, kiểm kê | Tạo ĐH, sửa giá, duyệt mua hàng |
| **Kế toán** | FIN, OM (công nợ) | Ghi sổ, lập báo cáo TC, theo dõi công nợ | Tạo ĐH, xuất kho |
| **Quản đốc xưởng** | MFG, INV (NVL) | Tạo lệnh SX, cấp phát NVL | Tạo ĐH, sửa giá, duyệt mua |
| **Giám đốc** | Tất cả (xem) | Xem dashboard, duyệt các bước quan trọng | Không nhập liệu — chỉ duyệt và xem |

#### Lớp 2: Bảo vệ dữ liệu (Data Security)

| Biện pháp | Mô tả | Với Cloud ERP (Dynamics 365 BC) |
|-----------|-------|----------------------------------|
| **Mã hóa dữ liệu** | Dữ liệu được mã hóa khi lưu trữ và truyền tải | Microsoft tự động mã hóa AES-256 (chuẩn quân đội Mỹ) |
| **Sao lưu định kỳ** | Tự động backup hàng ngày, lưu nhiều bản | Microsoft backup 30 ngày, có thể khôi phục bất kỳ lúc nào |
| **Phòng chống mất dữ liệu** | Không cho phép xóa dữ liệu gốc, chỉ "đánh dấu" | Trong ERP, không bao giờ xóa — chỉ đánh dấu "hủy" hoặc "đóng" |
| **Audit Trail (nhật ký kiểm tra)** | Ghi lại ai làm gì, lúc nào, trên máy nào | Có sẵn trong Dynamics 365 BC |

> ⚠️ **Lưu ý với Cloud ERP:** Anh không cần lo về máy chủ, firewall, backup — Microsoft lo hết. Nhưng anh **phải lo về kiểm soát nội bộ**: ai có mật khẩu, ai được truy cập từ điện thoại cá nhân, có đổi mật khẩu định kỳ không.

#### Lớp 3: Bảo mật vận hành (Operational Security)

| Hạng mục | Hành động cho BTChem |
|----------|---------------------|
| **Chính sách mật khẩu** | Đặt yêu cầu: tối thiểu 8 ký tự, có chữ hoa + số + ký tự đặc biệt. Đổi mỗi 3 tháng |
| **Xác thực 2 lớp (2FA)** | Bật 2FA cho tài khoản Giám đốc và Kế toán trưởng |
| **Thiết bị truy cập** | Giới hạn chỉ truy cập từ máy tính công ty và VPN (nếu ở ngoài) |
| **Đào tạo bảo mật** | Tập huấn cho nhân viên: không chia sẻ mật khẩu, không ghi mật khẩu ra giấy, báo ngay khi phát hiện bất thường |
| **Phân quyền thiết bị di động** | Nếu dùng Dynamics 365 BC mobile, cho phép xem nhưng không cho chỉnh sửa (trừ khi là quản lý) |

#### Câu hỏi tự kiểm tra bảo mật cho BTChem:

1. PKD có thể xem lương của công nhân không? → **Không** (nếu phân quyền đúng)
2. Thủ kho có thể tự ý xóa phiếu nhập không? → **Không** (chỉ đánh dấu hủy, để lại dấu vết)
3. Nhân viên nghỉ việc có thể mang dữ liệu đi không? → **Không** (vô hiệu hóa tài khoản ngay khi nghỉ)
4. Kế toán có thể tự tạo đơn hàng giả không? → **Không** (kế toán không có quyền tạo ĐH)

Nếu tất cả đều trả lời là "Không", hệ thống an toàn.

---

## PHỤ LỤC: SƠ ĐỒ KIẾN TRÚC HỆ THỐNG ĐỀ XUẤT CHO BTCHEM

```
                          ┌──────────────────────────────────────┐
                          │       DASHBOARD GIÁM ĐỐC            │
                          │  (Power BI / ERP built-in reports)  │
                          └────────────────┬─────────────────────┘
                                           │
          ┌────────────────────────────────┼────────────────────────────┐
          │                                │                            │
          ▼                                ▼                            ▼
┌─────────────────────┐    ┌──────────────────────┐    ┌─────────────────────────┐
│    ERP CORE         │    │   Phân tích & Dự báo   │   │   Báo cáo & Xuất Excel  │
│  (Microsoft         │    │  - AI forecast (SL)   │   │  - Báo cáo tài chính    │
│   Dynamics 365 BC)  │    │  - Trend analysis     │   │  - Báo cáo bán hàng     │
├─────────────────────┤    │  - Anomaly detection  │   │  - Báo cáo SX           │
│ INV │ MFG │ QM      │    └──────────────────────┘   │  - Xuất theo mẫu         │
│ OM  │ PO  │ FIN     │                               └─────────────────────────┘
└─────────────────────┘
          │
          │ (API / Webhook)
          ▼
┌──────────────────────────────────────────────────────┐
│                 CRM (Phase 2)                         │
│  - Ticket KH / Khiếu nại │ - QC Field / KTV hiện trường │
│  - Mẫu màu & công thức   │ - Knowledge Base sự cố       │
│  - Lịch sử tương tác KH  │ - Báo giá kỹ thuật           │
└──────────────────────────────────────────────────────┘
```

**Giải thích kiến trúc:**
1. **Lớp dưới cùng:** Dữ liệu vận hành hàng ngày trong ERP Core (6 module)
2. **Lớp giữa:** Analytics + AI (dự báo nhu cầu, phát hiện bất thường)
3. **Lớp trên cùng:** Dashboard cho Giám đốc — nhìn 1 màn hình là biết tình hình doanh nghiệp
4. **Bên cạnh:** CRM — quản lý tương tác với khách hàng, tách biệt với ERP core

---

## TÀI LIỆU THAM KHẢO

1. Cẩm nang triển khai ERP — IZISolution / ERPViet (36 trang) — Phần III.C (thiết kế hệ thống), Phần IV (gap analysis, phương pháp)
2. Đề cương triển khai ERP cho BTChem (09/06/2026) — Mục 2 (khảo sát hiện trạng), Mục 4 (lộ trình 6 pha)
3. Tài liệu tham khảo ERP (web research 09/06/2026) — Mục 3 (tính năng hoá chất), Mục 6 (so sánh ERP)
4. Quy trình Bán hàng BTChem (rà soát 05/06/2026) — 7 vấn đề cần giải quyết
5. Báo cáo Xử lý Không Phù Hợp (09/06/2026) — Phân tách ERP vs CRM
6. Triết lý & Tư duy vận hành ERP — Phần 2 (vai trò Key User)
7. Cam-nang-trien-khai-ERP-tong-quan.md — bài viết tổng quan cẩm nang
8. Luoc-do-trien-khai-ERP.md — Lưu đồ toàn bộ quá trình triển khai ERP

---