Bỏ qua menu, vào nội dung chính

Giải phẫu dự án: POS đa chi nhánh cho chuỗi F&B

Trạng thái:  Đã bàn giao
Dự án:  Hệ thống POS đa chi nhánh + đồng bộ kho realtime
Ngành:  F&B · Chuỗi nhà hàng
Năm:  2025
Thời lượng:  10 tuần
Đội ngũ:  4 người (1 PM, 2 dev, 1 QC)

Trang này không kể lại kết quả. Nó kể lại cách nghĩ: bài toán vận hành khách mang tới, những hướng đã cân nhắc rồi bỏ, kiến trúc chốt lại và cái giá phải trả cho kiến trúc đó.

Bài toán khách mang tới

Đây là những gì khách mô tả trước khi có bất kỳ chữ nào về công nghệ được nói ra.

  • Tám chi nhánh đang chạy tám phần mềm POS đóng gói khác nhau, và kho của chúng không nói chuyện được với nhau.
  • Cuối mỗi ngày từng chi nhánh gửi một file Excel doanh thu. Ban giám đốc chờ một tới hai ngày mới có bức tranh chung.
  • Không ai nhìn được tồn kho tại thời điểm đang bán, nên chuyện hết nguyên liệu giữa ca vẫn xảy ra.
  • Muốn biết một chi nhánh đang thế nào thì quản lý phải gọi điện hỏi ca trưởng ở đó.

Những hướng đã cân nhắc

Phần khó nhất của một dự án nội bộ không phải chọn được cái đúng, mà là nói rõ vì sao bỏ những cái còn lại.

Giữ nguyên các gói POS đóng gói đang chạy

Loại. Đây chính là hiện trạng sinh ra bài toán: tám chi nhánh, tám gói phần mềm khác nhau, kho không đồng bộ được với nhau và không có chỗ nào để cắm báo cáo chung vào.

Các hướng còn lại

Cần bổ sung

{{CAN BO SUNG: liệt kê những phương án khác đã thực sự cân nhắc và lý do loại từng cái. Ví dụ có thể có: thay đồng loạt bằng một gói POS chuỗi thương mại, hay viết ứng dụng Android chạy máy thay vì POS chạy trong trình duyệt. Repo hiện chưa ghi lại phần này nên không được đoán.}}

Kiến trúc chốt lại

  • POS chạy trong trình duyệt, dùng trên máy tính bảng Android đặt tại quầy. Thiết kế offline-first: quầy vẫn bán được khi mất mạng, dữ liệu đồng bộ lại khi mạng trở lại.
  • Kho đồng bộ theo thời gian thực qua API, kèm cảnh báo khi nguyên liệu sắp hết.
  • Một dashboard điều hành cho ban giám đốc: doanh thu theo chi nhánh, món bán chạy, tách theo giờ.
  • Phân quyền ba cấp, đúng theo cách chuỗi đang vận hành: nhân viên, ca trưởng, quản lý chuỗi.
Thành phần kỹ thuật
  • Next.js 16
  • Node.js + Express
  • PostgreSQL
  • Cloudflare Workers
  • Tablet Android
  • Zalo OA tích hợp

Đánh đổi phải chấp nhận

Offline-first là quyết định đắt nhất trong kiến trúc này. Chọn nó nghĩa là chấp nhận có lúc hai quầy cùng ghi lên một bản ghi kho trong khi đang mất mạng, nên quy tắc xử lý xung đột phải được chốt trước khi viết dòng code đồng bộ đầu tiên.

Cần bổ sung

{{CAN BO SUNG: quy tắc xử lý xung đột đã chốt là gì (ghi sau thắng, gộp theo dòng, hay đưa cho ca trưởng quyết), và những đánh đổi khác đã chấp nhận khi chọn POS chạy trình duyệt trên máy tính bảng.}}

Một chỗ đã làm sai

Mục này chỉ có giá trị khi kể đúng chuyện đã xảy ra, nên nó để trống cho tới khi được điền bằng dữ kiện thật. Chúng tôi không dựng một lỗi tưởng tượng để nghe cho khiêm tốn.

Chuyện gì đã xảy ra

Cần bổ sung

{{CAN BO SUNG: chỗ đã làm sai là gì. Một quyết định cụ thể, kể thẳng.}}

Vì sao lúc đó lại chọn như vậy

Cần bổ sung

{{CAN BO SUNG: vì sao lúc đó lại chọn như vậy, và dấu hiệu nào cho thấy nó sai.}}

Sửa thế nào

Cần bổ sung

{{CAN BO SUNG: đã sửa thế nào, mất bao lâu, và thay đổi gì trong cách làm việc sau đó.}}

Bàn giao

Mã nguồn thuộc về doanh nghiệp. Đây là điều chủ đầu tư nhắc tới đầu tiên khi nói về dự án, chứ không phải tính năng.

Cần bổ sung

{{CAN BO SUNG: danh sách bàn giao cụ thể. Ví dụ: kho mã nguồn bàn giao ở đâu, tài liệu vận hành và tài liệu kỹ thuật gồm những gì, tài khoản hạ tầng chuyển giao thế nào, buổi đào tạo cho quản lý chuỗi, thời gian bảo hành sau nghiệm thu.}}

Trước phải gọi từng chi nhánh hỏi tồn kho, giờ mở dashboard là biết. Quan trọng nhất là mã nguồn đứng tên công ty mình - sau này có gì cần đổi đội nào cũng làm tiếp được.

Anh M.Q · Giám đốc vận hành

Cách chúng tôi mổ xẻ một chi tiết kỹ thuật khác có ở giải phẫu logo intro.

Muốn xem cách nghĩ này
áp vào một bài toán cụ thể?

Khảo sát nghiệp vụ miễn phí. Báo giá chi tiết trong 48 giờ.