Một yêu cầu duyệt đơn đang đi qua 4 người, 3 file bảng tính và 1 nhóm chat — và không ai trả lời được nó đang kẹt ở đâu.
Đó là dấu hiệu quy trình đã lớn hơn khả năng của bảng tính và tin nhắn. Lập trình web app là việc đặt lại quy trình đó lên một đường ray rõ ràng: mỗi thao tác có một màn hình, mỗi trạng thái có một người chịu trách nhiệm, dữ liệu chỉ nhập một lần và ai cần tra cứu đều thấy cùng một sự thật.
Một nhân viên tạo yêu cầu trong file bảng tính. Người phụ trách xem qua tin nhắn, trả lời miệng. Quản lý muốn duyệt thì phải hỏi lại “cái này đến đâu rồi”. Cuối tháng, ai đó ngồi góp ba nguồn dữ kiện lại để làm báo cáo — và ba nguồn không khớp nhau.
Không ai trong chuỗi này làm việc cẩu thả. Vấn đề là công việc đang đi trên một con đường không có biển báo: không trạng thái, không dấu vết, không một nơi duy nhất để nhìn. Web app không thay con người trong chuỗi đó; nó dựng biển báo, vạch đường và đặt một bảng theo dõi chung cho cả chuỗi.
Website và web app khác nhau ở hành động của người dùng
Hai thứ này thường bị gọi lẫn, và sự lẫn đó làm nhiều dự án đi sai ngay từ brief:
Nếu “khách” của hệ thống là đội ngũ của chính bạn và công việc có trạng thái phải theo dõi, thứ bạn cần là web app. Nếu chỉ cần giới thiệu và nhận liên hệ, một website tốt là đủ — làm web app cho nhu cầu đó là thừa chi phí.
- Website phục vụ người dùng đọc và liên hệ: xem dịch vụ, sản phẩm, gửi form. Người dùng là khách lạ, không cần tài khoản.
- Web app phục vụ người dùng thao tác nghiệp vụ: đăng nhập, tạo yêu cầu, duyệt, cập nhật trạng thái, xem báo cáo. Người dùng là nhân viên, đối tác hoặc khách hàng đã có tài khoản — và mỗi người chỉ thấy phần việc của mình.
Giải phẫu một thao tác: từ “việc chạy trong chat” thành cấu trúc web app
Lấy thao tác “duyệt một yêu cầu nội bộ” làm ví dụ. Khi số hóa tử tế, nó gồm bốn lớp:
Lớp 1 — Dữ liệu của thao tác
Yêu cầu gồm những trường nào: người tạo, nội dung, giá trị/mức độ, hạn xử lý, tài liệu đính kèm. Lớp này quyết định sau này báo cáo có dùng được hay không.
Lớp 2 — Các trạng thái
Mới tạo → chờ duyệt → đã duyệt / bị trả lại kèm lý do → đang thực hiện → hoàn thành. Mỗi trạng thái là một cam kết: ai nhìn thấy trạng thái này đều hiểu việc đang ở đâu mà không cần nhắn hỏi.
Lớp 3 — Quyền theo trạng thái
Ai được tạo, ai được duyệt, ai được trả lại, ai chỉ được xem. Phân quyền gắn với trạng thái giúp web app phản ánh đúng cách doanh nghiệp đang vận hành, thay vì “ai cũng sửa được mọi thứ”.
Lớp 4 — Thông báo và dấu vết
Khi trạng thái đổi, người liên quan được báo; mọi thay đổi đều có lịch sử: ai làm, lúc nào. Đây là lớp biến web app thành công cụ quản lý, không chỉ là nơi nhập liệu.
Khi bạn kể được một thao tác của mình theo bốn lớp này, bạn đã có 80% bản mô tả mà đội lập trình cần. Ba lớp đầu thường rõ rất nhanh khi ngồi vẽ cùng nhau.
Quy trình nào nên số hóa trước, quy trình nào chưa nên đụng vào
Không phải việc gì chạy tay cũng nên đưa lên web app ngay:
Đề xuất phạm vi sẽ giúp bạn xếp thứ tự này bằng mức độ kẹt thực tế, không làm tất cả cùng lúc.
- Nên trước: việc lặp lại hằng ngày/hằng tuần, có nhiều người cùng tham gia, hay bị hỏi “đến đâu rồi”, và dữ liệu của nó được dùng lại cho báo cáo hoặc cho bước tiếp theo.
- Để sau: việc thỉnh thoảng mới xảy ra, chỉ một người làm từ đầu đến cuối, hoặc hình thức còn đang thay đổi liên tục.
- Chưa nên số hóa: quy trình mà chính đội ngũ còn chưa thống nhất cách làm. Web app sẽ đóng băng một quy trình chưa chín — lúc đó phần mềm bị chê “cứng”, nhưng gốc vấn đề là quy trình chưa được chốt.
Vì sao nên dựng theo module thay vì làm một lần cho xong
Một web app “làm hết mọi quy trình của công ty” trong một đợt thường chết ở hai chỗ: đợt làm kéo dài đến mức quy trình đã đổi khác, và người dùng bị dội một hệ thống lạ quá lớn nên quay về file cũ.
Cách làm an toàn hơn:
1. Module lõi trước: một quy trình kẹt nhất, số hóa trọn vòng từ tạo đến báo cáo.
2. Dùng thật, đo bằng việc thật: đội ngũ chạy module đó trong vận hành hằng ngày; điểm vướng được ghi lại.
3. Mở rộng theo dữ liệu đã có: các module sau nối vào cùng một nền người dùng và dữ liệu, thay vì sinh thêm một hệ thống rời nữa.
Thời gian từng module được chốt trong đề xuất theo độ phức tạp của luồng và số vai trò tham gia — không có một con số chung cho mọi web app.
Quy trình triển khai
Kể lại quy trình bằng ngôn ngữ vận hành
Bạn mô tả một thao tác điển hình: ai bắt đầu, đi qua những ai, dữ liệu đang nằm ở đâu, đoạn nào hay kẹt. Chưa cần tài liệu kỹ thuật hay sơ đồ chuẩn.
Nhận đề xuất phạm vi trong 24–48 giờ làm việc
Đề xuất gồm: bản đồ luồng và trạng thái dự kiến, module nên làm trước và lý do, các vai trò/phân quyền liên quan, thời gian dự kiến theo phạm vi và phần để giai đoạn sau.
Dựng module lõi và duyệt bằng tình huống thật
Bạn kiểm tra bản dựng bằng chính dữ liệu và tình huống của đội: một yêu cầu bình thường, một yêu cầu bị trả lại, một thay đổi người phụ trách giữa chừng.
Bàn giao, hướng dẫn và hỗ trợ
Đội ngũ được hướng dẫn theo thao tác hằng ngày của từng vai trò. Sau khi chạy thật, các điều chỉnh về luồng hoặc thêm module được báo phạm vi riêng trước khi làm.
Câu hỏi thường gặp
Tôi không biết mô tả yêu cầu kỹ thuật thì có tư vấn được không?
Được. Bạn chỉ cần kể quy trình bằng ngôn ngữ vận hành: ai làm gì, qua tay ai, hay kẹt ở đâu. Việc chuyển câu chuyện đó thành luồng, trạng thái và phân quyền là phần việc của Dũng Virgo trong đề xuất.
Nhân viên đã quen Excel và Zalo, liệu họ có chịu dùng web app không?
Rủi ro này có thật và được xử lý bằng cách làm: bắt đầu bằng một module gắn với việc kẹt nhất của chính họ, kiểm thử bằng tình huống thật trước bàn giao và hướng dẫn theo vai trò. Hệ thống giảm việc hỏi–đáp và nhập lại cho nhân viên trước, thay vì chỉ thêm việc nhập liệu cho họ.
Dữ liệu đang nằm trong nhiều file Excel thì chuyển lên thế nào?
Dữ liệu cũ được rà soát, chuẩn hóa trường và nhập vào hệ thống theo phạm vi thống nhất trong đề xuất. Phần dữ liệu quá cũ hoặc không còn dùng có thể không cần chuyển — việc này được chốt khi xem hiện trạng, không mặc định chuyển tất cả.
Sau này muốn đổi luồng hoặc thêm tính năng thì có bị khóa cứng không?
Luồng được dựng theo module trên một nền dữ liệu và phân quyền thống nhất, nên việc thêm trạng thái, thêm vai trò hay thêm module là phần mở rộng có báo phạm vi trước — không phải đập đi làm lại, với điều kiện nền ban đầu được thiết kế đúng.
Web app làm trong bao lâu?
Không có mốc chung đáng tin cho mọi web app. Thời gian phụ thuộc số quy trình, số vai trò và mức tích hợp. Đề xuất phạm vi — phản hồi trong 24–48 giờ làm việc — sẽ ghi thời gian dự kiến cho từng module để bạn quyết định theo giai đoạn.
Dữ liệu trên web app có an toàn và phân quyền được không?
Phân quyền theo vai trò và theo trạng thái là một phần của thiết kế ngay từ đầu: ai xem được gì, sửa được gì đều được chốt trong đề xuất và kiểm thử trước bàn giao. Dữ liệu nằm trên hạ tầng do bạn sở hữu tài khoản quản trị.
Lần tới có người hỏi “việc này đến đâu rồi?”, câu trả lời nên nằm sẵn trên một màn hình — không nằm trong trí nhớ của một nhân viên
Bạn không cần viết đặc tả, không cần vẽ sơ đồ chuẩn. Hãy gửi cách quy trình đang chạy hôm nay — kể cả khi nó đang chạy bằng file bảng tính và tin nhắn. Từ câu chuyện vận hành đó, đề xuất sẽ chỉ ra thao tác nào nên số hóa trước, module nào để sau và vì sao. Quyết định làm hay chưa vẫn là của bạn, nhưng nó sẽ dựa trên một bản đồ rõ ràng thay vì cảm giác “chắc cũng đến lúc cần phần mềm”. Đề xuất phạm vi được phản hồi trong 24–48 giờ làm việc. Văn phòng Hà Nội: 144 Trần Vỹ · Văn phòng Phú Thọ: Số 2 Chùa Cấm, Phúc Yên. Liên hệ nhanh qua các nút Điện thoại/Zalo trên trang.
