Tất cả dự ánChọn hệ trên bản đồ
Hệ 04Truyền thôngĐang chạy
NoLimit ERP
Giám đốc vận hành (COO), từ 11/2025
ERP nội bộ cho một agency truyền thông 19 người: ý tưởng → viết → duyệt → thiết kế → lên lịch → đăng → đo, kèm trợ lý Telegram nhắc việc và duyệt bài.
- Pháp nhân
- NoLimit Group - agency truyền thông (Đà Nẵng)
- Vai trò
- Giám đốc vận hành (COO) - quản trị, tuân thủ, kiểm soát nội bộ; đồng thời là người xây và vận hành toàn bộ hệ thống
- Trạng thái
- Web trên Vercel, bot trên Fly.io (Singapore), Supabase riêng. Dùng thật với nhân sự từ tháng 7/2026. Hệ nội bộ - không có link công khai.
Mô phỏng dựng lại từ cấu trúc thật, không phải ảnh chụp: hệ nội bộ, không có địa chỉ công khai.
Số đo, mỗi số có dấu nguồn
- 19người dùng nội bộ: 3 giám đốc, 1 PM, 15 nhân viên
- 64thao tác bot, 41 lệnh, 15 cron theo giờ Việt Nam
- 9trạng thái bài viết, cổng duyệt cứng ở tầng DB (service role cũng không lách được)
- 138test case cho bot (12 file) - web mới có 5
Câu chuyện
Trước khi xây, tôi đo hai dự án mẫu của agency: gần một nửa bài trễ lịch (43/87 và 27/103), không một bài nào trong 190 bài đi qua cổng duyệt, số liệu sau đăng để trống, và một người gánh 80-90% công việc. Lỗi không phải thiếu người mà là bài trôi giữa các khâu: ai đang giữ, đã duyệt chưa, sao lại đăng bản chưa duyệt.
Tôi không xây từ số 0. Tôi lấy hệ ERP đã xây cho công ty kỹ thuật của mình (Aerosky), đảo trọng tâm sang vận hành nội dung, và dựng lại: khách hàng → chiến dịch → bảng việc kéo-thả → pipeline bài 9 bước, cộng một trợ lý Telegram hiểu tiếng Việt để giao việc, duyệt bài, chụp hoá đơn ra chi phí, nhắc trước hạn và gửi điểm tin mỗi sáng.
Nguyên tắc: AI soạn nháp có watermark "AI Draft - cần duyệt"; người bấm duyệt; trigger ở tầng cơ sở dữ liệu từ chối chuyển trạng thái nếu chưa có dòng duyệt - service role của bot cũng không lách được. Mọi cải tiến bám vào số đo vận hành thật, có runbook rollback và backup trước mỗi gói thay đổi.
Tôi ghi lại nợ kỹ thuật một cách không né tránh: bốn lớp dữ liệu cùng tồn tại, khoảng 44 bảng di sản không còn code chạm, hai hệ vai trò không trùng nhau. Bản hồ sơ dự án nói rõ "đếm lại trước khi tin".
Quyết định đáng kể
Cổng duyệt nằm ở trigger DB, không ở app
Chuyển sang `scheduled`/`published` bắt buộc có dòng approvals đã duyệt, nếu không thì raise exception. Ma trận trạng thái phải khớp ở hai nơi (trigger và code) - sửa một là sửa cả hai.
Không bịa số liệu - kể cả khi production trống
Từng có lúc production hiện 1.000 dự án và 300 khách hàng bịa vì app rơi lặng lẽ về dữ liệu demo. Sửa thành empty-state có chủ ý; luật #1 của repo là số phải đến từ query thật.
Đo trước khi sửa
Bộ chỉ số vận hành chỉ đọc, đo lại được: baseline 25/07/2026 có 82% thẻ mở vô chủ và chỉ 4,2% thông báo "nộp duyệt" được đọc (so với 84% cho "giao việc"). Mỗi thay đổi trong gói điều hành bám vào một con số như vậy.
"Web chậm" - đo rồi mới chữa
DB trả 67-266 ms, bundle 102-222 kB đều bình thường; thủ phạm là 0 file loading.tsx nên chuyển trang đứng im. Thêm 12 skeleton bám bố cục thật, từ chối bỏ force-dynamic vì rủi ro người này thấy dữ liệu người kia.
Tiếp theo