Checklist chuyển đổi phần mềm quản lý khách sạn: 10 bước để không mất dữ liệu
Với một khách sạn 4–5 sao, một resort hay một chuỗi đang vận hành trên hệ thống cài tại chỗ nhiều năm, câu hỏi khó nhất khi cân nhắc thay phần mềm hiếm khi là "phần mềm mới có tốt hơn không". Câu hỏi khó là: dữ liệu hai mươi năm nằm trong đó rồi sẽ ra sao — hồ sơ khách, lịch sử lưu trú, công nợ lữ hành, tiền cọc của những đoàn đã đặt cho mùa cao điểm năm sau. Nỗi lo đó hoàn toàn chính đáng, và nó chính là lý do nhiều ban lãnh đạo trì hoãn một quyết định lẽ ra nên làm từ lâu.
Bài viết này không bàn về tính năng. Nó là một checklist vận hành dành cho người chịu trách nhiệm: giám đốc khách sạn, kế toán trưởng, trưởng bộ phận lễ tân và bộ phận công nghệ thông tin. Các bài trước trong chuỗi này đã bàn về tiêu chí thẩm định nhà cung cấp và cách đọc P&L theo chuẩn quốc tế; bài này đi vào đúng một việc — chuyển đổi thế nào để không mất dữ liệu và không gián đoạn kinh doanh.
Phần 1: Thay phần mềm quản lý khách sạn có mất dữ liệu không
Trả lời thẳng: không, nếu chuyển đổi được làm theo quy trình có kiểm soát. Dữ liệu chỉ mất trong ba tình huống, và cả ba đều phòng được:
- Không chốt phạm vi trước khi chuyển. Hai bên hiểu khác nhau về việc "chuyển dữ liệu" gồm những gì. Đến ngày go-live mới phát hiện lịch sử lưu trú năm cũ không nằm trong phạm vi thì đã muộn.
- Không đối soát bằng con số. Chuyển xong, mở lên thấy màn hình có dữ liệu là coi như xong. Sai lệch nằm ở tổng doanh thu theo kỳ, ở số dư công nợ, ở số bản ghi — những thứ chỉ lộ ra khi đặt hai bảng cạnh nhau và so từng dòng.
- Không giữ đường lui. Tắt hệ thống cũ ngay trong đêm chuyển đổi, không sao lưu nguyên trạng, không có phương án hoàn tác. Một sự cố nhỏ lúc này biến thành sự cố lớn vì không còn chỗ nào để quay về.
Trong một dự án chuyển đổi được chuẩn bị đúng, đội ngũ của chúng tôi đã thực hiện đợt chuyển dữ liệu với hơn 60 nghìn hồ sơ khách và hơn 5.000 đặt phòng: máy chạy chưa đầy 15 phút, đối soát khớp 100%, và toàn bộ quá trình có hoàn tác — nếu kết quả đối soát không đạt, hệ thống trở lại nguyên trạng trước khi chuyển. Con số này là của một dự án cụ thể, không phải cam kết áp cho mọi khách sạn; điều đáng rút ra không nằm ở phút giây mà ở chỗ chuyển đổi là việc đo được và đảo ngược được.
Phần 2: Dấu hiệu phần mềm bạn đang dùng đã ngừng tiến hóa
Không phải hệ thống cũ nào cũng cần thay. Có những phần mềm cài tại chỗ chạy ổn định cả chục năm và vẫn phục vụ tốt. Vấn đề chỉ xuất hiện khi phần mềm ngừng được phát triển tiếp — lúc đó nó không xấu đi, nhưng thế giới quanh nó thì thay đổi. Dưới đây là bộ tiêu chí khách quan để bạn tự soi hệ thống của mình, không dành để đánh giá bất kỳ nhà cung cấp cụ thể nào.
Bốn tiêu chí kiểm chứng được
- Lâu không có bản cập nhật mới. Mở nhật ký phiên bản của hệ thống ra xem: bản cập nhật gần nhất ban hành khi nào, gồm những gì. Một sản phẩm còn sống để lại dấu vết đều đặn. Nếu phiên bản đang chạy đã đứng yên vài năm, đó là dữ kiện chứ không phải cảm nhận.
- Không theo kịp quy định mới. Đây là tiêu chí dễ kiểm nhất vì pháp luật có mốc thời gian rõ ràng: chế độ kế toán doanh nghiệp theo Thông tư 99/2025/TT-BTC, hóa đơn điện tử kết nối cơ quan thuế, khai báo lưu trú tự động cho khách trong nước và khách nước ngoài. Hệ thống hỗ trợ được bao nhiêu trong số đó, và phần còn lại bộ phận của bạn đang làm thủ công bao nhiêu giờ mỗi tháng?
- Hỗ trợ chậm hoặc không còn phản hồi. Lấy số liệu thật từ chính đội vận hành: ba yêu cầu hỗ trợ gần nhất mất bao lâu mới có người trả lời, bao lâu mới xử lý xong, còn đầu mối liên hệ nào đang hoạt động. Cảm giác "gọi mãi không ai nghe" nên được quy thành số ngày trước khi đưa vào cuộc họp.
- Không có lộ trình sản phẩm được công bố. Hỏi thẳng nhà cung cấp: mười hai tháng tới sản phẩm sẽ có thêm gì, khi nào đáp ứng quy định sắp có hiệu lực, ai chịu trách nhiệm. Một sản phẩm đang được đầu tư luôn trả lời được câu này bằng văn bản. Không có câu trả lời cũng là một câu trả lời.
Vì sao điều này quan trọng với khách sạn 4–5 sao và chuỗi
- Rủi ro tuân thủ dồn về phía khách sạn, không về phía phần mềm. Khi quy định thay đổi mà hệ thống không cập nhật, người giải trình với cơ quan quản lý và với kiểm toán là ban giám đốc khách sạn.
- Chi phí thủ công là chi phí thật. Mỗi tháng vài chục giờ nhập tay, đối chiếu tay, xuất báo cáo tay — cộng cả năm thường vượt xa chênh lệch phí phần mềm giữa hai lựa chọn.
- Càng để lâu càng khó chuyển. Dữ liệu tích thêm mỗi ngày, người thạo hệ thống cũ nghỉ việc dần, tài liệu kỹ thuật rơi rụng. Thời điểm dễ chuyển nhất luôn là hôm nay so với năm sau.
Nếu hệ thống của bạn dính từ hai tiêu chí trở lên, hướng xử lý hợp lý là chuyển về một nền tảng được phát triển liên tục — có đội kỹ sư đứng sau, có lịch phát hành, có cam kết cập nhật pháp lý bằng văn bản. Đó là điều phần mềm quản lý khách sạn AI DiHotel duy trì suốt hơn hai mươi năm với hơn 300 cơ sở lưu trú tại Việt Nam và Nhật Bản.
Phần 3: Checklist 10 bước chuyển đổi an toàn
Đây là phần lõi của bài. Mười bước dưới đây là quy trình chúng tôi áp dụng cho các dự án chuyển đổi ở phân khúc 4–5 sao và chuỗi; bạn có thể dùng nguyên văn làm danh mục nghiệm thu với bất kỳ nhà cung cấp nào.
Bước 1 — Chốt phạm vi dữ liệu bằng văn bản
- Liệt kê rõ nhóm dữ liệu sẽ chuyển: hồ sơ khách, lịch sử lưu trú, danh mục phòng và hạng phòng, bảng giá và hợp đồng giá, danh mục đối tác lữ hành và kênh bán, số dư công nợ, đặt phòng tương lai, folio của khách đang lưu trú, danh mục hàng hóa dịch vụ.
- Ghi rõ nhóm nào không chuyển và lý do — thường là chứng từ chi tiết nhiều năm cũ, nhật ký thao tác, dữ liệu cấu hình riêng của hệ thống cũ.
- Phạm vi phải có chữ ký của kế toán trưởng và trưởng bộ phận lễ tân, không chỉ của bộ phận công nghệ thông tin.
Bước 2 — Sao lưu nguyên trạng hệ thống cũ và cất giữ độc lập
- Tạo bản sao lưu đầy đủ trước khi động vào bất cứ thứ gì, lưu ở nơi tách biệt với hệ thống đang chạy.
- Kiểm tra bản sao lưu bằng cách phục hồi thử — một bản sao lưu chưa từng phục hồi thành công thì chưa phải là bản sao lưu.
- Ghi biên bản: ai tạo, lúc nào, dung lượng, cất ở đâu, ai giữ quyền truy cập.
Bước 3 — Làm sạch dữ liệu trước khi chuyển
- Gộp hồ sơ khách trùng, chuẩn hóa tên công ty lữ hành, loại bỏ danh mục đã ngừng dùng nhiều năm.
- Nguyên tắc bất di bất dịch: làm sạch ở hệ cũ hoặc ở bảng trung gian, không sửa tay sau khi đã chuyển sang hệ mới — sửa sau sẽ phá vỡ mọi phép đối soát.
- Đây cũng là dịp hiếm hoi để dọn dẹp danh mục mà cả khách sạn đều biết là lộn xộn nhưng chưa ai có cớ để làm.
Bước 4 — Chuyển thử vào môi trường thử nghiệm
- Chuyển toàn bộ dữ liệu vào một môi trường riêng, tách hẳn khỏi hệ thống sẽ dùng thật.
- Chạy trọn một chu trình nghiệp vụ trên đó: nhận phòng, ghi dịch vụ, đổi phòng giữa kỳ, tách và gộp hóa đơn, trả phòng, khóa ngày, xuất báo cáo.
- Lỗi phát hiện ở bước này rẻ hơn lỗi phát hiện sau go-live nhiều lần — nên đây là bước không được rút gọn dù lịch có gấp.
Bước 5 — Đối soát bằng số, không bằng cảm nhận
- Lập bảng đối chiếu ba nhóm: số lượng bản ghi (hồ sơ khách, đặt phòng, hóa đơn), tổng tiền theo kỳ (doanh thu phòng, doanh thu dịch vụ theo từng tháng), số dư (công nợ từng đối tác, tiền cọc).
- Tiêu chí nghiệm thu ghi rõ trong biên bản: chênh lệch bằng không, hoặc mọi chênh lệch đều được giải thích và ký xác nhận.
- Người đối soát phải là người của khách sạn — kế toán và lễ tân — chứ không phải chỉ nhà cung cấp tự kiểm rồi báo đạt.
Bước 6 — Đào tạo trước ngày go-live, không phải trong ngày
- Đào tạo theo ca thật và theo vai trò thật: lễ tân, buồng phòng, nhà hàng và điểm bán, kế toán, quản lý.
- Cho nhân viên thao tác trên chính dữ liệu khách sạn mình trong môi trường thử nghiệm — quen mặt phòng, quen tên hạng giá, quen tên đối tác.
- Chọn ra người thạo việc tại chỗ ở mỗi bộ phận để hỗ trợ đồng nghiệp trong tuần đầu, giảm phụ thuộc vào tổng đài hỗ trợ.
Bước 7 — Chọn đúng thời điểm cắt chuyển
- Ưu tiên ngày công suất thấp trong tuần, tránh mùa cao điểm, tránh ngày có đoàn lớn nhận phòng hoặc sự kiện tiệc hội nghị.
- Mốc cắt nên đặt ngay sau khi khóa sổ một kỳ kế toán — số dư đầu kỳ khi đó là con số đã chốt, không phải con số đang động.
- Thống nhất "giờ G" chính xác đến phút và thông báo trước cho mọi bộ phận, kể cả bộ phận đặt phòng và kinh doanh.
Bước 8 — Chuyển bản dữ liệu chính thức và mở hệ mới
- Chạy lại đúng kịch bản đã diễn tập ở bước 4, lần này trên dữ liệu chốt tại giờ G.
- Hệ thống cũ chuyển sang chế độ chỉ đọc ngay lập tức — còn tra cứu được nhưng không ai nhập thêm được, tránh tình trạng dữ liệu chia làm hai dòng.
- Mục tiêu vận hành: go-live trong 1 ngày, khách sạn vẫn nhận khách bình thường trong suốt quá trình.
Bước 9 — Chạy song song và giám sát tại chỗ
- Trong giai đoạn chạy song song, hệ cũ mở ở chế độ đọc để đối chiếu bất cứ lúc nào có thắc mắc; nghiệp vụ mới chỉ ghi vào hệ mới.
- Bố trí người hỗ trợ trực tiếp tại quầy trong những ca đầu tiên, đặc biệt ca đêm khi chạy kiểm toán cuối ngày lần đầu.
- Đối chiếu doanh thu ngày đầu tiên ngay trong đêm đó, không để sang hôm sau.
Bước 10 — Nghiệm thu, bàn giao và chốt phương án lưu trữ hệ cũ
- Ký biên bản nghiệm thu kèm bảng đối soát đã khớp, danh sách việc còn tồn và người chịu trách nhiệm từng việc.
- Giữ hệ thống cũ ở chế độ chỉ đọc thêm 3–6 tháng để tra cứu lịch sử, sau đó lưu trữ theo quy định nội bộ về lưu giữ hồ sơ.
- Bàn giao tài liệu: sơ đồ ánh xạ dữ liệu, biên bản đối soát, tài khoản và phân quyền, đầu mối hỗ trợ.
Phần 4: Chuyển công nợ, số dư đầu kỳ và hồ sơ khách đang lưu trú
Đây là chỗ nhiều dự án chuyển đổi vấp phải, vì hai loại dữ liệu trông giống nhau nhưng phải xử lý ngược nhau hoàn toàn. Nguyên tắc chúng tôi dùng gọi là "đóng sổ cũ, mở sổ mới".
Công nợ đối tác lịch sử: KHÔNG chuyển chi tiết
- Chỉ chuyển sang hệ mới số dư đầu kỳ: mỗi đối tác một dòng duy nhất, không mang theo từng hóa đơn, từng lần thanh toán của nhiều năm trước.
- Kèm theo mỗi dòng số dư là bảng kê chi tiết đính kèm — vẫn tra được đầy đủ khi cần, nhưng nằm ở dạng tài liệu chứ không phải hàng nghìn bản ghi giao dịch trong hệ mới.
- Phải có biên bản chốt công nợ ký hai bên giữa khách sạn và từng đối tác lữ hành, kênh bán. Đây là căn cứ pháp lý cho con số mở sổ; thiếu nó thì mọi tranh luận về sau đều không có điểm tựa.
- Hệ thống cũ giữ chế độ chỉ đọc 3–6 tháng để tra cứu lịch sử giao dịch khi có khiếu nại hoặc đối chiếu.
- Vì sao không chuyển chi tiết: dữ liệu công nợ nhiều năm hầu như luôn có sai lệch tích tụ. Chuyển nguyên trạng nghĩa là mang toàn bộ sai lệch cũ sang hệ mới rồi trộn lẫn với dữ liệu mới, khiến về sau không ai phân biệt được lỗi đến từ đâu.
Folio khách đang lưu trú: BẮT BUỘC chuyển gắn theo từng booking
- Khách đang ở trong khách sạn tại thời điểm cắt chuyển phải được chuyển sang hệ mới nguyên vẹn từng booking: đúng phòng, đúng hạng giá, đúng ngày đến và ngày đi dự kiến, đúng số khách.
- Mọi khoản đã phát sinh trên folio — tiền phòng các đêm đã ở, dịch vụ nhà hàng, spa, giặt là, ghi nợ dồn về phòng — phải sang theo từng dòng chi tiết, không gộp thành một dòng tổng.
- Lý do rất thực tế: khách sẽ trả phòng ở hệ mới và yêu cầu hóa đơn chi tiết. Một dòng tổng gộp không giải thích được cho khách, không tách được doanh thu về đúng bộ phận, và làm sai báo cáo của cả hai kỳ.
- Trước giờ G, in bản kê folio của toàn bộ khách đang ở từ hệ cũ; sau khi chuyển, đối chiếu từng phòng, từng số tiền. Số lượng phòng đang có khách thường không lớn, nên việc kiểm tra thủ công là hoàn toàn khả thi và rất đáng làm.
Cách tách bạch này giữ cho hệ thống quản lý khách sạn mới sạch ngay từ ngày đầu: sổ mới chỉ chứa những gì còn sống — khách đang ở, đặt phòng tương lai, số dư đã chốt — còn quá khứ nằm gọn ở nơi lưu trữ, tra cứu được nhưng không làm nhiễu số liệu điều hành.
Phần 5: Xử lý tiền cọc đặt phòng tương lai khi đổi hệ thống
Tiền cọc là khoản dễ thất thoát nhất trong một cuộc chuyển đổi, vì nó là tiền đã thu nhưng dịch vụ chưa cung cấp — nằm ở ranh giới giữa dòng tiền và doanh thu. Với resort và khách sạn hội nghị nhận đặt trước cả năm, quy mô khoản này không hề nhỏ.
Nguyên tắc xử lý
- Quy tắc chính — cọc xác định được đặt phòng thì gắn thẳng vào đặt phòng đó. Mỗi khoản cọc đi kèm mã đặt phòng, tên khách hoặc tên đoàn, ngày nhận phòng dự kiến, số tiền, ngày thu, hình thức thanh toán. Gộp thành một số tổng "tiền cọc phải trả" là cách chắc chắn nhất để đến ngày khách đến thì không ai tìm ra khoản của họ.
- Cọc của hợp đồng đoàn và tiệc hội nghị cần thêm một lớp. Nhiều hợp đồng có nhiều đợt cọc theo tiến độ, có điều khoản chuyển đổi ngày, có ràng buộc phạt hủy. Chuyển sang hệ mới phải giữ được cả lịch trình thanh toán chứ không chỉ số tiền đã thu.
- Đối chiếu ba chiều trước giờ G. Danh sách cọc trên hệ cũ — sao kê ngân hàng và sổ quỹ — danh sách đặt phòng tương lai. Ba nguồn phải khớp; lệch chỗ nào thì làm rõ chỗ đó trước khi chuyển, không mang sang hệ mới rồi tính sau.
- Cọc đã thu qua kênh bán trực tuyến cần ghi rõ kênh và trạng thái đối soát, vì thời điểm ghi nhận thường lệch với thời điểm tiền thực về tài khoản.
- Thông báo cho bộ phận kinh doanh và đặt phòng. Trong tuần chuyển đổi, mọi khoản cọc mới thu chỉ ghi vào một hệ thống duy nhất theo mốc giờ G đã thống nhất — đây là quy ước con người, không phải việc của phần mềm, và cũng là chỗ hay xảy ra nhầm lẫn nhất.
Trường hợp biên: khoản cọc chưa xác định được thuộc đặt phòng nào
Hệ thống cũ nào chạy lâu năm cũng để lại một nhóm khoản treo: tiền giữ chỗ khách chuyển đến trước khi chốt ngày, tiền đặt cọc gom theo một đầu mối chưa tách ra từng khách, các khoản nằm trong một tài khoản gom hoặc một "phòng ảo" dùng để giữ tiền. Những khoản này không gắn được vào một đặt phòng cụ thể, và nguyên tắc xử lý là:
- Tuyệt đối không nhét bừa vào một đặt phòng bất kỳ chỉ để "cho đủ chỗ đứng". Làm vậy sẽ tạo ra một khoản cọc giả trên một booking không liên quan, đến lúc trả phòng thì sai tiền và không lần ngược được nguồn gốc.
- Chuyển các khoản này thành số dư đầu kỳ bên phân hệ kế toán, ghi dư Có — vì bản chất là tiền của khách đang do khách sạn giữ, tức một khoản phải trả chứ không phải doanh thu.
- Mỗi khoản một dòng riêng, không gộp chung thành một số tổng, kèm bảng kê chi tiết đính kèm: ngày thu, số tiền, người nộp hoặc đầu mối, ghi chú tình huống. Có bảng kê thì sau này khi khách chốt ngày hoặc đối tác đến đối chiếu, kế toán truy ngược được ngay.
- Khi khoản treo được làm rõ thuộc về ai, xử lý bình thường trên hệ mới: cấn trừ vào đặt phòng tương ứng hoặc hoàn trả, và ghi giảm số dư đầu kỳ đã mở. Kết thúc quý đầu, con số treo còn lại nên gần bằng không — nếu vẫn lớn thì đó là dấu hiệu quy trình nhận cọc cần siết lại, chứ không phải lỗi của cuộc chuyển đổi.
Với chuỗi nhiều cơ sở, việc này nhân lên theo số cơ sở và cần một đầu mối duy nhất theo dõi tiến độ — điều mà phần mềm quản lý chuỗi khách sạn DiHotel xử lý bằng cách hợp nhất danh sách cọc và đặt phòng tương lai của toàn danh mục về một chỗ, tách theo từng cơ sở nhưng vẫn xem được tổng thể.
Phần 6: So sánh hệ cài tại chỗ và hệ đám mây trước khi quyết định
Chuyển đổi là dịp hiếm để xem lại kiến trúc, chứ không chỉ đổi tên phần mềm. Bảng dưới đây so sánh hai mô hình trên những tiêu chí thực sự tác động tới vận hành của khách sạn 4–5 sao, resort và chuỗi.
| Tiêu chí | Hệ cài tại chỗ | Hệ đám mây | Ý nghĩa với khách sạn |
|---|---|---|---|
| Chi phí ban đầu | Đầu tư máy chủ, bản quyền, phòng máy | Trả theo kỳ, không đầu tư phần cứng | Vốn giải phóng cho việc khác |
| Cập nhật phiên bản | Theo từng đợt, cần lịch dừng hệ thống | Liên tục, thực hiện tập trung | Bám kịp quy định mới |
| Sao lưu & khôi phục | Do khách sạn tự tổ chức và tự kiểm | Tự động, có nhiều bản theo thời điểm | Giảm rủi ro mất dữ liệu |
| Quản lý nhiều cơ sở | Mỗi cơ sở một hệ, hợp nhất thủ công | Hợp nhất sẵn theo danh mục | Báo cáo chuỗi trong ngày |
| Truy cập từ xa | Cần cấu hình kết nối riêng | Mở trình duyệt hoặc ứng dụng | Chủ đầu tư nắm số mọi lúc |
| Phụ thuộc đường truyền | Chạy được trong mạng nội bộ | Cần internet ổn định, nên có đường dự phòng | Cân nhắc theo địa điểm |
| Kết nối thiết bị tại chỗ | Kết nối trực tiếp trong mạng | Qua thành phần trung gian đặt tại khách sạn | Cần khảo sát trước khi chốt |
| Nhân sự vận hành hệ thống | Cần người trực máy chủ tại chỗ | Nhà cung cấp đảm nhiệm | Giảm chi phí thường xuyên |
Không có mô hình nào đúng cho mọi trường hợp. Một resort ở vùng đường truyền chưa ổn định, một khách sạn có yêu cầu đặc thù về lưu trữ dữ liệu tại chỗ vẫn có lý do chính đáng để giữ kiến trúc cài tại chỗ — miễn là phần mềm chạy trên đó vẫn đang được phát triển tiếp. Với các cơ sở quy mô nhỏ hơn nằm cùng danh mục, phần mềm quản lý khách sạn cloud AI DiCloud thường là lựa chọn hợp lý hơn về chi phí, trong khi cơ sở lớn, resort và khách sạn hội nghị dùng phần mềm quản lý resort DiHotel cho các nghiệp vụ phức tạp. Hai nền tảng cùng một hệ sinh thái nên báo cáo hợp nhất được, không phải ghép tay.
Phần 7: Chạy song song, đối soát và phương án hoàn tác
Ba việc này là bộ giảm xóc của cả dự án. Bỏ bất kỳ việc nào cũng làm tăng rủi ro nhiều hơn phần thời gian tiết kiệm được.
Chạy song song đúng cách
- Không nhập trùng hai nơi. Nhân viên nhập hai lần sẽ mệt, sẽ sai, và cuối cùng số của hai hệ không khớp — đúng thứ ta muốn tránh. Chạy song song nghĩa là hệ cũ mở để đọc, nghiệp vụ mới chỉ ghi vào hệ mới.
- Thời lượng hợp lý: vài tuần đầu là giai đoạn giám sát chặt, sau đó giữ hệ cũ ở chế độ chỉ đọc trong 3–6 tháng cho nhu cầu tra cứu.
- Một đầu mối quyết định. Trong giai đoạn này luôn có tình huống chưa có tiền lệ; cần một người có thẩm quyền chốt ngay, thay vì mỗi ca xử một kiểu.
Đối soát những con số nào
- Doanh thu theo ngày và theo bộ phận — phòng, ẩm thực, dịch vụ khác — so giữa hai hệ trong những ngày đầu.
- Số phòng có khách, số khách, công suất của từng đêm.
- Số dư công nợ từng đối tác và tổng tiền cọc tại thời điểm cắt chuyển.
- Số lượng bản ghi hồ sơ khách và đặt phòng tương lai.
Phương án hoàn tác phải viết ra trước, không nghĩ ra lúc sự cố
- Ghi rõ điều kiện kích hoạt: sai lệch vượt ngưỡng nào, sự cố loại nào thì dừng và quay lại.
- Ghi rõ ai có quyền quyết định hoàn tác, và trong bao lâu phải quyết.
- Ghi rõ các bước quay về: mở lại quyền ghi trên hệ cũ, xử lý những nghiệp vụ đã phát sinh trên hệ mới trong khoảng thời gian ngắn đó, thông báo cho bộ phận nào.
- Trong đợt chuyển dữ liệu nêu ở đầu bài, phương án hoàn tác đã được chuẩn bị đầy đủ dù cuối cùng không phải dùng đến — và chính vì có nó mà đội ngũ mới dám bấm nút chuyển.
Phần 8: Sau go-live — đối soát những gì, trong bao lâu
Ngày go-live không phải vạch đích. Phần lớn sai lệch thật sự chỉ lộ ra ở lần khóa sổ đầu tiên, nên lịch theo dõi sau go-live cần được ấn định ngay từ khi ký hợp đồng.
Ngày đầu tiên
- Chạy kiểm toán cuối ngày có người của nhà cung cấp đứng cạnh; đối chiếu doanh thu ngày với hệ cũ ngay trong đêm.
- Kiểm tra toàn bộ phòng đang có khách: đúng phòng, đúng giá, folio đủ dòng.
Tuần đầu tiên
- Đối chiếu doanh thu từng ngày; rà các nghiệp vụ ít gặp lần đầu xuất hiện: đổi phòng giữa kỳ, tách và gộp hóa đơn, khách đoàn trả một phần, hoàn tiền, khách không đến.
- Kiểm tra dữ liệu đẩy sang các kênh liên quan: kênh bán trực tuyến, hóa đơn điện tử, khai báo lưu trú.
- Ghi nhật ký vướng mắc theo bộ phận — đây là đầu vào cho buổi đào tạo bổ sung cuối tuần.
Tháng đầu tiên và lần khóa sổ đầu tiên
- Khóa sổ tháng là phép thử quan trọng nhất: doanh thu theo bộ phận, thuế giá trị gia tăng đầu ra, công nợ phải thu, tiền cọc còn lại — tất cả phải khớp với sổ sách kế toán.
- Đối chiếu số dư đầu kỳ đã mở với biên bản chốt công nợ đã ký, xác nhận không phát sinh chênh lệch.
- Rà lại danh sách việc còn tồn trong biên bản nghiệm thu, đóng từng việc có ngày tháng cụ thể.
Quý đầu tiên
- So sánh các chỉ số điều hành — công suất, giá phòng bình quân, doanh thu trên mỗi phòng khả dụng — với cùng kỳ năm trước để phát hiện sai lệch mang tính hệ thống mà đối soát ngày không thấy.
- Quyết định thời điểm ngừng chế độ chỉ đọc của hệ cũ và chuyển sang lưu trữ, sau khi chắc chắn không còn nhu cầu tra cứu thường xuyên.
- Đánh giá lại phân quyền: sau vài tháng vận hành thật mới biết ai thực sự cần quyền gì.
Đến cuối quý đầu, chủ đầu tư nên nhìn được toàn bộ danh mục trên cùng một bộ định nghĩa chỉ số — điều mà giải pháp quản lý khách sạn toàn diện DiHotel và phần mềm quản lý khách sạn online AI DiCloud cung cấp sẵn cho các cơ sở trong cùng hệ sinh thái. Góc nhìn dành cho cơ sở quy mô nhỏ hơn, nơi bài toán thường là chuyển dữ liệu từ Excel sang phần mềm chuyên ngành, được trình bày trong bài cùng đợt bên DiCloud Blog.
Đang cân nhắc thay hệ thống cài tại chỗ?
Đội ngũ DiHotel khảo sát hiện trạng dữ liệu của khách sạn bạn, lập sơ đồ ánh xạ và bảng đối soát trước khi bàn tới hợp đồng — kèm ưu đãi chuyển đổi: miễn phí chuyển đổi dữ liệu, tặng số tháng còn lại của hợp đồng cũ và cho dùng thử trên chính dữ liệu của bạn. Cam kết vận hành: go-live trong 1 ngày, chạy song song, có hoàn tác.
Kết luận
Mất dữ liệu khi thay phần mềm không phải là số phận — nó là hệ quả của việc bỏ qua vài bước có thể liệt kê ra giấy. Mười bước trong bài này rút gọn lại thành ba nguyên tắc: chốt phạm vi và sao lưu trước khi động vào bất cứ thứ gì; đối soát bằng con số do chính người của khách sạn ký xác nhận; và luôn giữ đường lui bằng chế độ chỉ đọc của hệ cũ cùng phương án hoàn tác. Riêng phần nghiệp vụ, hãy nhớ hai chiều ngược nhau: công nợ lịch sử chỉ mang sang số dư đầu kỳ, còn folio khách đang ở và tiền cọc đặt phòng tương lai thì bắt buộc gắn theo từng booking.
Nếu hệ thống bạn đang dùng đã lâu không có bản cập nhật, không theo kịp Thông tư 99/2025/TT-BTC, hóa đơn điện tử và khai báo lưu trú tự động, hỗ trợ chậm và không công bố lộ trình sản phẩm, thì việc chuyển sang một nền tảng được phát triển liên tục là quyết định về quản trị rủi ro chứ không phải về sở thích công nghệ. Với phân khúc 4–5 sao, resort và chuỗi, phần mềm quản lý khách sạn cao cấp DiHotel đứng sau hơn 300 cơ sở lưu trú tại Việt Nam và Nhật Bản với hơn hai mươi năm phát triển liên tục; các cơ sở quy mô nhỏ hơn trong cùng danh mục dùng giải pháp quản lý khách sạn tổng thể DiCloud và vẫn hợp nhất báo cáo về một chỗ. Chuyển đổi làm đúng quy trình thì mất một ngày; làm sai thì mất nhiều hơn thế rất nhiều.
Đối tác của chúng tôi
