Bản đồ công trìnhTờ này lắp: Giao diện app, Thanh toán VietQR
Bài nàyĐã họcChưa tớiĐã thay thế
Bạn sẽ học được gì
Tiêu chí nghiệm thu
Bài toán trước, công cụ sau
Ở bài 03-0103-01, chị Lan đã có problem statement và ước tính vấn đề tốn khoảng 13–24 triệu đồng/tháng (số giả định). Ở bài 03-0203-02, chị có sơ đồ to-be và danh sách quy tắc nghiệp vụ. Giờ là câu hỏi mà rất nhiều người bỏ qua vì hào hứng với AI: có nhất thiết phải xây phần mềm riêng không?
Hãy nghĩ như chuyện mở thêm chi nhánh: bạn có thể thuê mặt bằng có sẵn, thuê mặt bằng rồi tự sửa sang, tự xây từ đầu, hay giao cho một công ty xây dựng trọn gói. Không lựa chọn nào luôn đúng; nó phụ thuộc vào vị trí đó quan trọng thế nào với thương hiệu, bạn có bao nhiêu tiền, bao nhiêu thời gian, và bạn có muốn tự quản lý công trình hay không.
Bốn lựa chọn và chi phí thật
1. Mua phần mềm SaaS có sẵn
SaaS (Software as a Service — phần mềm thuê bao qua mạng): bạn trả phí hằng tháng/năm để dùng một phần mềm người khác xây và vận hành. Với bán lẻ F&B, thị trường Việt Nam có nhiều phần mềm quản lý bán hàng, POS (máy tính tiền), quản lý đơn đa kênh.
- Ưu điểm: dùng được ngay trong vài ngày; nhà cung cấp lo bảo mật, sao lưu, cập nhật; thường đã có sẵn tích hợp hóa đơn điện tử, máy in hóa đơn, kết nối ngân hàng.
- Nhược điểm: quy trình của bạn phải uốn theo phần mềm; tính năng đặc thù (như bánh kem tùy chỉnh có chữ, giờ nhận, chuyến xe từ bếp trung tâm) có thể không có hoặc phải “lách” qua ô ghi chú; dữ liệu nằm ở nhà cung cấp; giá tăng theo số chi nhánh/người dùng.
- Chi phí thật gồm: phí thuê bao × số chi nhánh × số năm, phí thiết lập/đào tạo, thời gian chuyển dữ liệu, chi phí “lách” quy trình (giờ công nhân viên phải làm thủ công phần phần mềm không hỗ trợ), chi phí chuyển đi nếu sau này muốn đổi.
2. Dựng bằng no-code / low-code
No-code là công cụ cho phép tạo ứng dụng bằng kéo thả, bảng tính – cơ sở dữ liệu, form và quy tắc tự động mà không viết code; low-code cho viết thêm một ít code khi cần. Ví dụ phổ biến tại thời điểm viết (2026) là các nền tảng dạng bảng tính – cơ sở dữ liệu và trình dựng app nội bộ (như Airtable, Google AppSheet, Glide và nhiều công cụ tương tự); tính năng và bảng giá thay đổi thường xuyên, hãy kiểm tra trang chính thức.
- Ưu điểm: nhanh (vài ngày tới vài tuần), rẻ lúc đầu, người không lập trình tự chỉnh được; rất hợp để thử quy trình mới trước khi đầu tư lớn.
- Nhược điểm: giới hạn khi logic phức tạp (đánh mã đơn theo ngày, quy tắc cọc, phân quyền theo chi nhánh); hiệu năng và giá có thể “đột biến” khi dữ liệu và người dùng tăng; khó kiểm thử tự động; khó tách ra khi muốn chuyển nền tảng.
- Chi phí thật gồm: phí theo người dùng/bản ghi, thời gian dựng và duy trì của bạn, chi phí khi chạm giới hạn và phải làm lại.
3. Tự xây với AI coding agent
Bạn (hoặc một người trong team) chỉ đạo coding agent xây phần mềm riêng trên một stack phổ biến — với Bánh Mộc là Next.js, Supabase, TypeScript (xem lý do ở bài chọn tech stack04-06).
- Ưu điểm: khớp chính xác quy trình; sở hữu dữ liệu và mã nguồn; mở rộng theo lộ trình riêng (10 chi nhánh, nhượng quyền, thậm chí bán lại thành SaaS); chi phí hạ tầng ban đầu có thể thấp.
- Nhược điểm: cần thời gian học và xây (vài tháng với người mới); bạn chịu trách nhiệm toàn bộ về bảo mật, sao lưu, sự cố; rủi ro “app vibe” rối và không bảo trì được nếu làm không bài bản.
- Chi phí thật gồm: thuê bao công cụ AI và chi phí token (xem bài giới hạn và chi phí của AI02-08), hạ tầng (hosting, database, giám sát, tên miền), thời gian của bạn (thường là khoản lớn nhất và hay bị bỏ qua), chi phí thuê chuyên gia review bảo mật theo giờ, chi phí bảo trì lâu dài.
4. Thuê ngoài (agency, freelancer)
Bạn viết yêu cầu, một đơn vị bên ngoài xây và bàn giao.
- Ưu điểm: không cần tự học kỹ thuật sâu; có người chịu trách nhiệm theo hợp đồng; có thể nhanh nếu đối tác giỏi.
- Nhược điểm: chất lượng phụ thuộc rất lớn vào chất lượng yêu cầu bạn viết; chi phí ban đầu cao; thay đổi giữa chừng tốn kém; rủi ro phụ thuộc khi đối tác rời đi mà mã nguồn khó hiểu; vẫn cần người phía bạn nghiệm thu.
- Chi phí thật gồm: giá hợp đồng, chi phí thay đổi yêu cầu, phí bảo trì hằng năm, thời gian của bạn để viết yêu cầu và nghiệm thu, chi phí chuyển giao nếu đổi đối tác. Cách làm việc với đối tác bên ngoài được bàn kỹ ở bài tài liệu dự án và làm việc với dev07-07.
Bảng so sánh tổng quan
| Tiêu chí | SaaS có sẵn | No-code / low-code | Tự xây với AI | Thuê ngoài |
|---|---|---|---|---|
| Thời gian tới khi dùng được | Rất nhanh | Nhanh | Chậm–vừa | Vừa |
| Chi phí ban đầu | Thấp | Thấp | Thấp–vừa (chủ yếu thời gian) | Cao |
| Chi phí định kỳ | Tăng theo chi nhánh/người dùng | Tăng theo người dùng/dữ liệu | Hạ tầng + bảo trì | Phí bảo trì hợp đồng |
| Khớp quy trình đặc thù | Thấp–vừa | Vừa | Cao | Cao (nếu yêu cầu tốt) |
| Sở hữu dữ liệu, mã nguồn | Thấp | Thấp–vừa | Cao | Tùy hợp đồng |
| Năng lực nội bộ cần có | Thấp | Thấp–vừa | Cao | Vừa (viết yêu cầu, nghiệm thu) |
| Rủi ro lớn nhất | Quy trình bị bó | Chạm trần, khó thoát | Tự gánh vận hành | Phụ thuộc đối tác |
Khi nào phần mềm riêng là lợi thế cạnh tranh?
Một câu hỏi hữu ích: nếu đối thủ dùng đúng phần mềm này, mình có mất gì không?
- Kế toán, lương, hóa đơn điện tử, email, máy tính tiền tại quầy: mọi tiệm bánh đều cần, và làm giống nhau theo quy định. Làm tốt hơn đối thủ ở đây không khiến khách chọn bạn. Đây là phần “bối cảnh” (context) — nên mua.
- Cách Bánh Mộc nhận, xác nhận và thực hiện bánh kem tùy chỉnh: chữ đúng dấu, đúng giờ, đúng chuyến xe từ bếp trung tâm; nhớ khách quen và sinh nhật của họ. Đây là thứ khách cảm nhận trực tiếp và quyết định họ quay lại. Đây là phần “cốt lõi” (core) — đáng cân nhắc xây.
Ba dấu hiệu phần mềm riêng có thể là lợi thế:
- Quy trình là điểm khác biệt. Khách chọn bạn vì cách bạn phục vụ, và quy trình đó không có trong phần mềm đại trà.
- Dữ liệu tích lũy tạo giá trị. Lịch sử mua, sinh nhật, sở thích vị bánh của khách là tài sản; bạn muốn toàn quyền khai thác (trong khuôn khổ pháp luật về dữ liệu cá nhân).
- Lộ trình vượt khỏi khả năng phần mềm có sẵn. Chị Lan muốn nhượng quyền, thậm chí đóng gói thành “MộcOS” bán cho tiệm khác (xem bài multi-tenant13-03). Phần mềm thuê không cho bạn làm điều đó.
Ngược lại, nếu quy trình của bạn giống 90% các tiệm khác, nếu bạn không có ai đủ thời gian chịu trách nhiệm kỹ thuật, hoặc nếu vấn đề chỉ tốn vài triệu mỗi tháng — mua hoặc no-code gần như chắc chắn hợp lý hơn.
Ma trận quyết định có trọng số
Ma trận quyết định có trọng số (weighted decision matrix) là công cụ biến một quyết định nhiều chiều thành phép tính minh bạch. Bốn bước:
- SaaS có sẵn
- No-code
- Tự xây với AI
- Thuê ngoài
- Tổng có trọng số
- 3,70
- Liệt kê tiêu chí quan trọng với bạn (5–7 tiêu chí là vừa).
- Gán trọng số cho từng tiêu chí, tổng bằng 100%. Đây là bước quan trọng nhất, vì trọng số chính là chiến lược của bạn được viết ra bằng số.
- Chấm điểm từng lựa chọn theo từng tiêu chí, thang 1–5 (5 là tốt nhất cho bạn). Ghi một dòng lý do cho mỗi điểm.
- Nhân và cộng: điểm có trọng số = tổng (trọng số × điểm). Sau đó kiểm tra độ nhạy: đổi trọng số theo những cách hợp lý khác xem kết quả có lật không.
Vuốt ngang để xem hết sơ đồ
Vuốt ngang để xem hết sơ đồ
Đọc sơ đồ dạng chữ
- Liệt kê tiêu chí → Gán trọng số (tổng 100%)
- Gán trọng số (tổng 100%) → Chấm điểm 1–5 kèm lý do
- Chấm điểm 1–5 kèm lý do → Tính tổng có trọng số
- Tính tổng có trọng số → Kết quả có đứng vững khi đổi trọng số?
- Kết quả có đứng vững khi đổi trọng số? → Quyết định + ghi lại (Có)
- Kết quả có đứng vững khi đổi trọng số? → Thảo luận lại trọng số hoặc thử nghiệm nhỏ để lấy thêm dữ liệu (Không)
- Thảo luận lại trọng số hoặc thử nghiệm nhỏ để lấy thêm dữ liệu → Gán trọng số (tổng 100%)
Ma trận của Bánh Mộc
Chị Lan chọn sáu tiêu chí, rút ra trực tiếp từ problem statement và lộ trình kinh doanh. Điểm dưới đây là đánh giá của chị trong bối cảnh Bánh Mộc, không phải đánh giá chung về một sản phẩm cụ thể nào.
| Tiêu chí | Trọng số | SaaS có sẵn | No-code | Tự xây với AI | Thuê ngoài |
|---|---|---|---|---|---|
| Khớp quy trình bánh kem đặt trước (chữ, giờ nhận, chuyến xe, cọc) | 25% | 2 | 3 | 5 | 4 |
| Tổng chi phí 2 năm (càng thấp càng điểm cao) | 20% | 4 | 4 | 3 | 2 |
| Thời gian tới khi dùng được | 15% | 5 | 4 | 2 | 3 |
| Đáp ứng lộ trình 10 chi nhánh, nhượng quyền, SaaS | 15% | 2 | 2 | 5 | 4 |
| Sở hữu dữ liệu, ít phụ thuộc nhà cung cấp | 10% | 2 | 3 | 5 | 3 |
| Mức năng lực vận hành nội bộ cần có (ít đòi hỏi = điểm cao) | 15% | 5 | 4 | 2 | 3 |
| Tổng có trọng số | 100% | 3,30 | 3,35 | 3,70 | 3,20 |
Cách tính một cột, ví dụ “Tự xây với AI”: 0,25×5 + 0,20×3 + 0,15×2 + 0,15×5 + 0,10×5 + 0,15×2 = 1,25 + 0,60 + 0,30 + 0,75 + 0,50 + 0,30 = 3,70.
Một vài lý do chấm điểm chị ghi lại:
- SaaS — khớp quy trình: 2. Các phần mềm chị dùng thử đều cho ghi chú tự do, nhưng không có trường bắt buộc cho chữ trên bánh, không sắp theo chuyến xe, cọc phải ghi tay.
- No-code — lộ trình: 2. Làm được cho 3 tiệm, nhưng chị lo về phân quyền theo chi nhánh và chi phí theo người dùng khi lên 10 tiệm, chưa nói tới bán cho tiệm khác.
- Tự xây — năng lực vận hành: 2. Chị chưa biết lập trình; phải học bài bản và dành 8–10 giờ/tuần trong vài tháng.
- Thuê ngoài — chi phí: 2. Báo giá chị tham khảo cao hơn đáng kể so với trần ngân sách rút ra từ bảng chi phí ở bài 03-01.
Kiểm tra độ nhạy: kết quả có lật không?
“Tự xây với AI” thắng, nhưng chỉ hơn khoảng 0,35 điểm. Chênh lệch nhỏ như vậy nghĩa là phải hỏi: nếu trọng số khác đi thì sao?
Giả sử chị Lan không có thời gian học (ví dụ đang mở thêm chi nhánh), tiêu chí “năng lực vận hành nội bộ” tăng lên 25% và “lộ trình mở rộng” giảm còn 5%:
| Lựa chọn | Tổng mới |
|---|---|
| SaaS có sẵn | 0,50 + 0,80 + 0,75 + 0,10 + 0,20 + 1,25 = 3,60 |
| No-code | 0,75 + 0,80 + 0,60 + 0,10 + 0,30 + 1,00 = 3,55 |
| Tự xây với AI | 1,25 + 0,60 + 0,30 + 0,25 + 0,50 + 0,50 = 3,40 |
| Thuê ngoài | 1,00 + 0,40 + 0,45 + 0,20 + 0,30 + 0,75 = 3,10 |
Kết quả lật: SaaS lên đầu. Đây không phải điểm yếu của ma trận, mà là giá trị lớn nhất của nó: nó cho thấy quyết định phụ thuộc vào một câu hỏi duy nhất — “chị Lan có dành được 8–10 giờ/tuần trong vài tháng không?”. Thay vì tranh luận “tự xây hay mua” chung chung, chị chỉ cần trả lời trung thực câu hỏi đó.
Chiến lược kết hợp: mua phần chung, xây phần khác biệt
Trên thực tế, câu trả lời hiếm khi là một trong bốn ô. Kiến trúc hợp lý cho đa số doanh nghiệp nhỏ là kết hợp:
- Mua những gì là “bối cảnh” và có quy định chặt: máy tính tiền tại quầy, hóa đơn điện tử, kế toán. Ví dụ, quy định về hóa đơn điện tử (Nghị định 123/2020/NĐ-CP, được sửa đổi, bổ sung bởi Nghị định 70/2025/NĐ-CP) có những yêu cầu riêng với hóa đơn khởi tạo từ máy tính tiền — để nhà cung cấp chuyên nghiệp lo phần này an toàn hơn tự làm. Đây là thông tin tổng quan, không thay thế tư vấn pháp lý/kế toán; hãy kiểm tra văn bản hiện hành.
- Mua dưới dạng dịch vụ hạ tầng những khối kỹ thuật chung, ngay cả khi tự xây: xác thực người dùng (Supabase Auth), gửi thông báo (Zalo ZNS, email giao dịch), mã QR chuyển khoản (VietQR), theo dõi lỗi (Sentry), phân tích hành vi (PostHog). Không ai nên tự viết hệ thống đăng nhập từ đầu.
- Xây đúng phần khác biệt: quy trình đơn đặt trước, màn hình bếp, dữ liệu khách hàng.
- Dùng no-code làm bước thử: trước khi xây, chạy quy trình mới trên một công cụ đơn giản vài tuần để kiểm chứng.
- Thuê chuyên gia theo giờ cho những khâu rủi ro cao: review bảo mật trước khi ra mắt, thiết kế database ban đầu.
Vuốt ngang để xem hết sơ đồ
Đọc sơ đồ dạng chữ
- Mua / dùng dịch vụ có sẵn
- Tự xây với AI: Mộc OMS
- Thử trước bằng no-code
- Sheet có cột bắt buộc + form chuẩn trong 3–4 tuần → Đơn đặt trước + bánh kem tùy chỉnh (kiểm chứng quy trình, đo baseline)
- Đơn đặt trước + bánh kem tùy chỉnh → Auth, thông báo Zalo/email, VietQR, giám sát lỗi, analytics
- Đơn đặt trước + bánh kem tùy chỉnh → Phần mềm kế toán (giai đoạn sau: đồng bộ)
Ghi quyết định lại
Ba tháng sau, khi một nhân viên bán hàng của phần mềm SaaS gọi điện chào mời, hoặc khi việc tự xây gặp khó, bạn sẽ muốn nhớ vì sao mình đã chọn như vậy. Hãy viết một bản ghi quyết định ngắn, theo tinh thần ADR (Architecture Decision Record) mà bạn sẽ học kỹ ở bài tài liệu hóa kiến trúc04-09:
# Quyết định 001: Tự xây Mộc OMS cho đơn đặt trước, mua phần còn lại
- Ngày: 2025-12-15 | Người quyết định: Nguyễn Thị Lan | Trạng thái: Đã chấp nhận
- Bối cảnh: problem statement trong docs/PRD.md; chi phí vấn đề ước tính 13–24 triệu đồng/tháng (giả định).
- Các lựa chọn đã cân nhắc: SaaS bán hàng, no-code, tự xây với AI, thuê ngoài (ma trận đính kèm).
- Quyết định: tự xây phần đơn đặt trước/bếp/khách hàng; giữ máy tính tiền + hóa đơn điện tử hiện có tại quầy;
dùng dịch vụ có sẵn cho auth, thông báo, thanh toán QR; chạy thử quy trình bằng Sheet chuẩn hóa 4 tuần trước.
- Điều kiện để quyết định còn đúng: chị Lan dành được ≥ 8 giờ/tuần; MVP dùng được trong ≤ 4 tháng.
- Khi nào xem lại: nếu sau 8 tuần chưa có bản dùng thử nội bộ, hoặc khi lên 6 chi nhánh.Dòng “điều kiện để quyết định còn đúng” là chi tiết quan trọng nhất: nó biến quyết định thành một giả thuyết có thể kiểm chứng, và cho bạn quyền đổi hướng mà không thấy mình “thất bại”.
Áp dụng vào dự án Bánh Mộc
Nhật ký công trình · Bánh Mộc
BM-261013-025
13.10.2026
- Chị LanChủ chuỗi
- HàBán hàng online
Chị Lan đi qua quy trình trên trong khoảng hai tuần.
Tuần 1 — dùng thử và hỏi giá. Chị dùng thử hai phần mềm bán hàng phổ biến cho F&B và một nền tảng no-code. Chị ghi lại những việc làm được và không làm được theo đúng danh sách quy tắc nghiệp vụ từ bài 03-02. Ví dụ: “sắp bánh theo chuyến xe 7:30 và 13:00” — cả hai SaaS đều không làm được nếu không xuất dữ liệu ra ngoài. Chị cũng xin hai báo giá thuê ngoài để có mốc so sánh.
Tuần 2 — ma trận và độ nhạy. Chị lập ma trận như trên, rồi tự hỏi câu hỏi then chốt: có dành được 8–10 giờ/tuần không? Chị quyết định có, với điều kiện cắt bớt việc khác và giao lại phần trả lời tin nhắn cho Hà hoàn toàn. Chị nhờ AI phản biện ma trận (prompt bên dưới); AI chỉ ra chị đang chấm “chi phí 2 năm” cho phương án tự xây mà chưa tính thời gian của chính chị. Chị chấm lại từ 4 xuống 3.
Quyết định cuối: chiến lược kết hợp như sơ đồ. Một điều chị không ngờ: chính bước “thử trước bằng no-code” — một Google Sheet có cột bắt buộc, danh sách thả xuống cho size và vị, và một tab riêng cho bếp — đã giảm đáng kể số bánh sai ngay trong tuần đầu áp dụng. Chị không xem đó là lý do để dừng lại, mà là bằng chứng rằng quy trình to-be đúng hướng. Sheet đó cũng trở thành nguồn baseline và dữ liệu mẫu cho Mộc OMS sau này.
Chị lưu ma trận và bản ghi quyết định vào docs/adr/001-tu-xay-moc-oms.md trong repo banhmoc-oms.
Prompt mẫu
Prompt 1 — Lập danh sách tiêu chí và chi phí ẩn
Điền ô trống rồi sao chép
Tôi là chủ chuỗi 3 tiệm bánh, đang cân nhắc 4 cách giải vấn đề quản lý đơn đặt trước:
(1) mua phần mềm bán hàng SaaS, (2) dựng bằng no-code, (3) tự xây với AI coding agent, (4) thuê ngoài.
Problem statement: """[dán]"""
Quy tắc nghiệp vụ đặc thù: """[dán danh sách]"""
Hãy:
1. Đề xuất 6 tiêu chí đánh giá phù hợp với bối cảnh này, mỗi tiêu chí một câu giải thích.
2. Với mỗi lựa chọn, liệt kê các khoản chi phí ẩn thường bị bỏ quên trong 2 năm đầu.
Không nêu tên sản phẩm hay giá cụ thể; nói theo loại chi phí.Prompt 2 — Phản biện ma trận quyết định
Điền ô trống rồi sao chép
Đây là ma trận quyết định có trọng số của tôi (trọng số, điểm 1–5, lý do chấm):
"""[dán bảng]"""
Hãy:
1. Kiểm tra lại phép tính.
2. Chỉ ra những điểm chấm có vẻ thiên vị hoặc thiếu căn cứ, đặc biệt chi phí thời gian của chính tôi.
3. Tìm bộ trọng số hợp lý khác làm kết quả lật, và nói rõ kết quả phụ thuộc vào câu hỏi nào.
4. Gợi ý một thử nghiệm nhỏ (≤ 2 tuần) để lấy dữ liệu cho tiêu chí không chắc chắn nhất.Prompt 3 — Viết bản ghi quyết định
Điền ô trống rồi sao chép
Dựa trên ma trận và phân tích ở trên, viết bản ghi quyết định ngắn (≤ 20 dòng) theo mẫu:
tiêu đề, ngày, người quyết định, trạng thái, bối cảnh, các lựa chọn đã cân nhắc, quyết định,
điều kiện để quyết định còn đúng, khi nào xem lại. Viết bằng tiếng Việt, giọng rõ ràng, không quảng cáo.Sai lầm thường gặp
-
Sự cố 01
“AI viết hộ nên tự xây là rẻ nhất.”
Triệu chứngBỏ quên thời gian của chính bạn và chi phí vận hành năm 2, năm 3. *
Cách tránh* định giá giờ công của bạn, tính TCO tối thiểu 2 năm cho cả bốn lựa chọn.
-
Sự cố 02
Tự xây cả những thứ có quy định chặt.
Triệu chứngVí dụ tự làm phần hóa đơn điện tử. *
Cách tránh* mua phần “bối cảnh”, đặc biệt những gì liên quan thuế, kế toán, thanh toán; chỉ tích hợp với chúng.
-
Sự cố 03
Chấm điểm để ra đáp án định sẵn.
Triệu chứng*
Cách tránh* chốt trọng số trước khi chấm điểm; ghi lý do cho mỗi điểm; nhờ một người khác (hoặc AI) phản biện.
-
Sự cố 04
Bỏ qua bước thử nghiệm rẻ.
Triệu chứngLao vào xây ngay mà chưa kiểm chứng quy trình mới. *
Cách tránh* chạy quy trình to-be bằng công cụ đơn giản 2–4 tuần trước.
-
Sự cố 05
Coi quyết định là vĩnh viễn.
Triệu chứng*
Cách tránh* ghi “điều kiện để quyết định còn đúng” và lịch xem lại.
-
Sự cố 06
Quên chi phí thoát ra.
Triệu chứngChọn SaaS hoặc no-code mà không kiểm tra khả năng xuất toàn bộ dữ liệu. *
Cách tránh* trước khi chọn, thử xuất dữ liệu ra CSV và kiểm tra có đủ trường không.
Checklist
Bài tập thực hành
-
Bài 1
Cơ bản
Bối cảnh hay cốt lõi?
Liệt kê 10 hoạt động trong doanh nghiệp của bạn cần phần mềm hỗ trợ. Đánh dấu mỗi hoạt động là “bối cảnh” hay “cốt lõi”, kèm một câu lý do theo câu hỏi “nếu đối thủ dùng đúng phần mềm này, mình có mất gì không?”.
Kết quả mong đợi
đa số là “bối cảnh”; chỉ 1–3 hoạt động là “cốt lõi”.
-
Bài 2
Cơ bản
Thử xuất dữ liệu
Với một phần mềm bạn đang dùng (hoặc đang dùng thử), thử xuất toàn bộ dữ liệu ra CSV/Excel.
Kết quả mong đợi
biết rõ những trường nào xuất được, những gì bị mất, và mất bao lâu — đây là “chi phí thoát ra” của bạn.
-
Bài 3
Nâng cao
Ma trận và độ nhạy
Lập ma trận có trọng số cho một quyết định thật của bạn với ít nhất 3 lựa chọn và 5 tiêu chí. Dùng Prompt 2 để phản biện, rồi tìm bộ trọng số làm kết quả lật.
Kết quả mong đợi
bảng tính đúng, một câu “quyết định này phụ thuộc vào…”, và một thử nghiệm ≤ 2 tuần để trả lời câu hỏi đó.
Thuật ngữ trong bài
- SaaS
- Phần mềm thuê bao dùng qua mạng, nhà cung cấp vận hành.
- No-code / low-code
- Công cụ tạo ứng dụng bằng kéo thả, cấu hình; low-code cho viết thêm ít code.
- POS
- Hệ thống bán hàng tại quầy (máy tính tiền).
- TCO (Total Cost of Ownership)
- Tổng chi phí sở hữu: mua/xây + vận hành + bảo trì + con người trong một khoảng thời gian.
- Bối cảnh (context) vs cốt lõi (core)
- Hoạt động cần làm nhưng không tạo khác biệt vs hoạt động tạo lợi thế cạnh tranh.
- Ma trận quyết định có trọng số
- Bảng chấm điểm các lựa chọn theo tiêu chí có trọng số để ra quyết định minh bạch.
- Phân tích độ nhạy
- Kiểm tra kết quả có đổi không khi thay đổi trọng số/giả định.
- Khóa chặt nhà cung cấp (vendor lock-in)
- Tình trạng khó chuyển đi vì dữ liệu, quy trình phụ thuộc một nhà cung cấp.
- ADR
- Bản ghi quyết định kiến trúc: bối cảnh, lựa chọn, quyết định, hệ quả.
Đọc thêm
Nghiệm thu tờ 03-03
Đọc xong và tự kiểm theo phiếu nghiệm thu, rồi đánh dấu tờ này.
