Chuyển dữ liệu từ Excel sang phần mềm quản lý khách sạn: hướng dẫn từng bước

Kỳ trước chúng tôi bàn về cách thẩm định một nhà cung cấp phần mềm trước khi ký hợp đồng. Kỳ này đi tiếp một bước rất thực tế và cũng là nỗi lo lớn nhất của chủ khách sạn nhỏ khi đứng trước quyết định đổi hệ thống: dữ liệu của tôi sẽ đi đâu, có mất không, mất bao lâu, và nếu hỏng thì quay lại kiểu gì? Bài viết này không nói về tính năng. Nó là một quy trình chuyển đổi cụ thể — dọn gì, chuyển gì, chuyển ở mức chi tiết nào, kiểm tra thế nào, và những khoản nào tuyệt đối không được gộp.

Nói ngay từ đầu cho công bằng: bảng tính không phải kẻ thù. Với một cơ sở 8 phòng, một người trực, khách gọi điện đặt trực tiếp, thì một file bảng tính làm tốt gần như mọi việc mà lại miễn phí. Vấn đề không nằm ở công cụ, mà ở ngưỡng quy mô. Vượt qua ngưỡng đó, cùng một file từng giúp bạn tiết kiệm bắt đầu âm thầm gây tốn kém. Phần lớn nội dung dưới đây là để bạn nhận ra mình đang ở phía nào của ngưỡng, và nếu đã vượt thì đi qua giai đoạn chuyển đổi một cách có kiểm soát.

Phần 1: Rủi ro khi quản lý khách sạn bằng Excel

Những rủi ro dưới đây không phải chuyện lý thuyết. Chúng là các tình huống lặp đi lặp lại mà đội triển khai gặp khi tiếp nhận dữ liệu từ các cơ sở đang dùng bảng tính. Điểm chung của chúng: đều rất nhỏ vào ngày nó xảy ra, và chỉ lộ ra khi đã muộn.

1. Mất file — rủi ro một lần, thiệt hại toàn bộ

• File nằm trên máy tính quầy lễ tân hoặc trong USB. Ổ cứng hỏng, máy dính mã độc, máy bị mượn mang đi — cả lịch sử kinh doanh biến mất trong một buổi sáng.
• Có sao lưu bằng cách "thỉnh thoảng copy sang chỗ khác" thì bản sao luôn cũ hơn thực tế vài ngày đến vài tuần, và không ai biết chắc bản nào mới nhất.
• Nhiều bản song song — bang_ke_thang8, bang_ke_thang8_moi, bang_ke_thang8_final — dẫn tới tình huống hai người cùng đúng theo hai file khác nhau.

2. Sai công thức không báo lỗi

• Thêm một dòng đặt phòng dưới cùng bảng nhưng công thức tính tổng chỉ chạy tới dòng trên: tổng vẫn ra một con số đẹp, chỉ là thiếu.
• Kéo công thức lệch một ô, ô tham chiếu tuyệt đối bị mất, một ô số bị lưu thành chữ — bảng tính không báo gì cả. Đây là điểm khác biệt lớn nhất so với một hệ thống có ràng buộc dữ liệu: bảng tính luôn cho ra kết quả, kể cả khi kết quả sai.
• Hệ quả dây chuyền: doanh thu ghi sai thì công suất, giá bán bình quân và mọi quyết định giá của tháng sau đều lệch theo.

3. Không ai biết ai đã sửa gì

• Một số tiền bị đổi, một dòng đặt phòng biến mất — file không lưu lại người thao tác, thời điểm và giá trị trước đó.
• Điều này gây thiệt cho cả hai phía. Chủ không truy được nguyên nhân, còn nhân viên làm đúng thì không có gì để chứng minh mình làm đúng. Chúng tôi đã bàn kỹ khía cạnh này ở bài kiểm soát thất thoát doanh thu khách sạn.

4. Không xem được từ xa, không xem được đồng thời

• Chủ đi vắng phải nhắn tin xin số. Số nhận được là bản đã tổng hợp lại bằng tay, tức là đã đi qua một lần diễn giải.
• Đặt file lên dịch vụ lưu trữ đám mây thì xem được từ xa, nhưng hai người cùng sửa một lúc vẫn sinh ra bản xung đột — và bản xung đột thường bị chọn bừa một cái để giữ.

5. Trùng phòng

• Đây là rủi ro tốn tiền và tốn uy tín nhất. Bảng tính không biết một phòng đã bị chiếm dụng trong khoảng thời gian nào — nó chỉ là các ô chữ và số. Người nhập phải tự nhớ và tự dò.
• Rủi ro tăng vọt ngay khi bạn bắt đầu nhận khách từ nhiều kênh cùng lúc: khách gọi điện, khách nhắn tin, khách đặt qua kênh trực tuyến. Ba nguồn đặt phòng, một file, không có khóa chống trùng.
• Giá của một lần trùng phòng không chỉ là tiền chuyển khách sang cơ sở khác, mà còn là đánh giá xấu để lại trên kênh bán — thứ ảnh hưởng tới doanh thu nhiều tháng sau đó.

6. Những việc bảng tính không làm được

• Khai báo lưu trú cho cơ quan chức năng phải gõ lại thủ công từng lượt khách.
• Không tra cứu được lịch sử một khách đã ở bao nhiêu lần, thích phòng nào, còn nợ gì.
• Không xuất được hóa đơn điện tử thẳng từ dữ liệu đang có, phải nhập lại lần hai sang phần mềm khác — mỗi lần nhập lại là một cơ hội sai lệch.

Phần 2: Phần mềm bán hàng đa ngành và phần mềm quản lý khách sạn chuyên ngành khác nhau ở đâu

Nhiều chủ cơ sở, khi thấy bảng tính đuối, chọn giải pháp gần tay nhất: một phần mềm bán hàng đa ngành — loại vốn sinh ra cho cửa hàng bán lẻ hoặc quán ăn, rồi được thêm một mục "khách sạn". Cách này giải quyết được việc thu tiền và in phiếu, nhưng để trống đúng phần lõi của nghiệp vụ lưu trú. Khác biệt không nằm ở giao diện, nó nằm ở bản chất thứ đang được bán.

Bán lẻ bán món hàng, khách sạn bán đêm-phòng

• Một cửa hàng bán một món hàng: trừ kho một đơn vị, thu tiền, kết thúc. Một khách sạn bán quyền chiếm dụng một phòng trong một khoảng thời gian — cùng một phòng được bán lại vô số lần cho vô số đêm khác nhau.
• Vì thế "tồn kho" của khách sạn là một tấm lịch hai chiều (phòng × ngày), không phải một con số tồn. Phần mềm bán lẻ không có cấu trúc này, nên nó không thể tự chặn trùng phòng — đúng thứ bạn cần thoát khỏi khi rời bảng tính.
• Doanh thu phòng phải được ghi nhận rải đều theo từng đêm khách ở, chứ không dồn hết vào ngày trả phòng. Ghi dồn thì mọi chỉ số theo ngày đều sai, kể cả khi tổng cả tháng vẫn đúng.

Folio — hóa đơn mở kéo dài nhiều ngày

• Hóa đơn bán lẻ mở ra và đóng lại trong vài phút. Folio của khách lưu trú mở từ lúc nhận phòng tới lúc trả phòng, cộng dồn tiền phòng mỗi đêm cùng mọi dịch vụ phát sinh.
• Folio phải tách và gộp được: công ty trả tiền phòng, khách tự trả phần đồ uống và giặt là; hai người ở chung tách đôi hóa đơn; một đoàn khách gộp về một hóa đơn chung nhưng vẫn giữ chi tiết từng phòng.
• Phải chuyển được khoản mục từ folio này sang folio khác mà vẫn giữ dấu vết ai chuyển, chuyển lúc nào — đây là nghiệp vụ hằng ngày ở quầy, không phải trường hợp hiếm.

Ghi nợ về phòng

• Khách ăn sáng ở nhà hàng, ký tên, khoản đó chạy thẳng về folio phòng và được thanh toán một lần khi trả phòng. Phần mềm bán lẻ không có khái niệm "ký nợ về phòng" — nó cần tiền ngay tại điểm bán.
• Thiếu cơ chế này, thực tế ở quầy sẽ là: ghi ra giấy rồi tối gõ lại. Bạn vừa rời bảng tính để tránh việc nhập tay, lại quay về đúng việc nhập tay.

Đặt phòng tương lai và tiền cọc

• Khách đặt hôm nay cho kỳ nghỉ ba tháng sau và chuyển cọc. Số tiền đó chưa phải doanh thu hôm nay — đó là khoản khách sạn đang giữ và sẽ phải trừ vào hóa đơn của đúng lần lưu trú đó, hoặc hoàn lại theo chính sách hủy.
• Phần mềm bán lẻ ghi nhận tiền vào là doanh thu ngay. Sai lệch này lớn dần theo mùa: cao điểm nhận cọc nhiều thì báo cáo trông rất đẹp, tới lúc khách thực sự đến ở thì doanh thu lại "hụt" không giải thích được.

Khai báo lưu trú và hồ sơ khách

• Lưu trú là ngành có nghĩa vụ khai báo thông tin khách với cơ quan chức năng. Một hệ chuyên ngành lưu thông tin giấy tờ ngay lúc nhận phòng và gửi khai báo từ chính dữ liệu đó, không gõ lại lần hai.
• Hồ sơ khách còn phải nối được với lịch sử lưu trú, sở thích phòng và công nợ — thứ mà một danh sách khách hàng kiểu bán lẻ không giữ.

Những nghiệp vụ chỉ khách sạn mới có

• Kiểm đêm: chốt ngày kinh doanh, tự động ghi tiền phòng cho từng phòng đang có khách, sang ngày mới.
• Trạng thái phòng và buồng phòng: sạch, bẩn, đang dọn, đã kiểm; phòng hỏng chờ sửa (OOO) và phòng tạm dừng dịch vụ (OOS) được xử lý khác nhau khi tính công suất.
• Các tình huống biên: đổi phòng giữa kỳ, khách đi sớm, khách không đến, trả phòng muộn có phụ thu, kéo dài lưu trú. Mỗi tình huống đều phải tính đúng tiền và đúng đêm.
• Đồng bộ hai chiều với kênh bán trực tuyến: bán một phòng ở đây thì tồn phòng trên mọi kênh khác phải giảm theo, tính bằng giây.

Đây chính là lý do một giải pháp quản lý khách sạn tổng thể tồn tại như một ngành phần mềm riêng, thay vì là một mục nhỏ trong phần mềm bán hàng. Không phải vì nó "nhiều tính năng hơn", mà vì nó mô tả đúng thứ mà khách sạn đang bán.

Phần 3: Dấu hiệu khách sạn nhỏ cần đổi phần mềm

Thay vì cảm giác "hình như đến lúc rồi", hãy dùng các tiêu chí đếm được dưới đây. Kinh nghiệm triển khai cho thấy khi chạm từ ba dấu hiệu trở lên, chi phí ẩn của việc giữ cách làm cũ đã vượt chi phí phần mềm.

Dấu hiệu về quy mô

• Vượt khoảng 15–20 phòng. Dưới ngưỡng này một người còn nhớ hết lịch trong đầu; vượt lên thì trí nhớ bắt đầu là điểm yếu của hệ thống.
• Có từ cơ sở thứ hai. Hai file cho hai cơ sở đồng nghĩa không bao giờ có một con số tổng đáng tin theo thời gian thực.
• File dữ liệu vượt vài nghìn dòng, mở chậm, phải tách theo năm, và không ai dám xóa sheet cũ vì sợ mất công thức.

Dấu hiệu về con người

• Từ hai người trở lên cùng nhập liệu, hoặc có ca đêm. Đây là dấu hiệu quan trọng nhất — mọi vấn đề về xung đột dữ liệu và dấu vết sửa đổi đều bắt đầu từ đây.
• Chủ không có mặt hằng ngày và phải hỏi số qua tin nhắn.
• Có nhân sự mới vào: thời gian đào tạo một người dùng file tự chế luôn dài hơn đào tạo trên một hệ thống có quy trình rõ.

Dấu hiệu về kinh doanh

• Bắt đầu bán qua kênh trực tuyến. Đây là lằn ranh dứt khoát: từ thời điểm này, cập nhật tồn phòng bằng tay là rủi ro trùng phòng thường trực.
• Đã xảy ra ít nhất một lần trùng phòng trong ba tháng gần nhất. Một lần là tai nạn, hai lần là dấu hiệu hệ thống.
• Bắt đầu có công nợ với công ty, đại lý hoặc đoàn khách — nghĩa là bạn cần theo dõi tuổi nợ, không chỉ theo dõi thu chi.
• Cần hóa đơn điện tử và khai báo lưu trú thường xuyên, tần suất đủ để việc gõ lại thủ công chiếm thời gian thật.
• Muốn biết giá bán bình quân và doanh thu trên mỗi phòng sẵn có nhưng tính tay không xuể — trong khi đây là hai chỉ số quyết định việc bạn định giá đúng hay sai.

Nếu bạn đang vận hành khách sạn mini, nhà nghỉ hay vài căn homestay và thấy mình ở trong phần lớn các dấu hiệu trên, thì thứ bạn cần là một phần mềm quản lý khách sạn cloud chuyên ngành, không phải một bảng tính tốt hơn hay một phần mềm bán hàng có thêm mục phòng. Chúng tôi đã phân tích đặc thù từng loại hình này ở bài khách sạn mini, nhà nghỉ và homestay.

Phần 4: Chuẩn bị dữ liệu trước khi chuyển — dọn gì, giữ gì

Phần lớn sự cố chuyển đổi không sinh ra lúc nạp dữ liệu, mà sinh ra trước đó, ở khâu chuẩn bị. Máy móc chỉ nạp đúng những gì được đưa vào; dữ liệu vào lộn xộn thì hệ mới sẽ là một bản sao gọn gàng hơn của sự lộn xộn cũ. Đây cũng là phần chỉ chủ cơ sở làm được — không đơn vị triển khai nào biết dòng nào là thật, dòng nào là ghi thử.

Bước chuẩn bị bắt buộc

• Sao lưu bản gốc và khóa lại. Trước khi động vào bất cứ ô nào: chép toàn bộ file hiện có sang một thư mục riêng, đặt tên kèm ngày, đặt thuộc tính chỉ đọc. Đây là mỏ neo để mọi tranh luận sau này có chỗ quay về.
• Chốt ngày cắt. Chọn một mốc rõ ràng — thường là ngày đầu của một tháng — làm ranh giới: trước mốc thuộc sổ cũ, từ mốc trở đi thuộc sổ mới. Không có mốc này thì không ai biết một giao dịch phải nằm ở đâu.
• Cử một người chịu trách nhiệm dữ liệu. Một người duy nhất có quyền chốt "dòng này đúng". Nhiều người cùng dọn một file là cách nhanh nhất tạo ra ba phiên bản sự thật.

Dọn cái gì

• Danh mục phòng: mỗi phòng một mã duy nhất, không trùng, không đổi giữa chừng. Ghi rõ hạng phòng, số khách tiêu chuẩn và số khách tối đa. Bỏ các phòng đã dỡ hoặc đã đổi công năng.
• Bảng giá: đây là phần hay bị bỏ sót nhất vì nhiều nơi giá nằm trong đầu chủ chứ không nằm trên giấy. Viết ra thành bảng: giá công bố theo hạng phòng, giá hợp đồng cho từng đối tác, phụ thu khách thêm, chính sách trẻ em, giá cuối tuần và mùa cao điểm.
• Hồ sơ khách: khử trùng lặp theo số giấy tờ hoặc số điện thoại. Thống nhất định dạng — số điện thoại giữ số 0 đầu, ngày tháng một kiểu duy nhất, tên viết hoa chữ đầu. Xóa các dòng thử nghiệm kiểu "khách test", "aaa".
• Danh mục đối tác: công ty, đại lý, đoàn khách. Gộp các bản ghi trùng tên viết khác nhau. Đối tác đã ngừng hợp tác trên hai năm và không còn số dư thì để lại trong hồ sơ lưu trữ, không đưa sang.

Giữ cái gì — và giữ ở đâu

• Đưa sang hệ mới: toàn bộ danh mục và bảng giá; hồ sơ khách; các đặt phòng tương lai; khách đang ở; số dư công nợ tại ngày cắt.
• Giữ để tra cứu, không đưa sang: lịch sử giao dịch chi tiết của các năm trước. Với vận hành hằng ngày, dữ liệu 12–24 tháng gần nhất là quá đủ; phần xa hơn để ở kho lưu trữ đọc, cần thì mở ra xem.
• Không đưa sang: dòng trùng lặp, dòng ghi thử, ghi chú cá nhân trong ô, và mọi thông tin đang được thể hiện bằng màu tô — vì màu không chuyển được. Nếu ô vàng của bạn nghĩa là "đã cọc", hãy thêm một cột ghi rõ chữ "đã cọc" trước khi chuyển.

Định dạng file bàn giao

• Mỗi loại dữ liệu một sheet riêng; hàng đầu tiên là tên cột; từ hàng thứ hai trở đi là dữ liệu.
• Không gộp ô, không dòng tiêu đề phụ chen giữa bảng, không dòng tổng nằm giữa các dòng dữ liệu.
• Một ô một giá trị. Ô ghi "0901xxxxxx / chị Hoa / thanh toán sau" phải tách thành ba cột.
• Cột số là số, cột ngày là ngày — không để lẫn chữ trong cột số ("chưa rõ", "hỏi lại").

Phần 5: Chuyển dữ liệu từng bước

Thứ tự dưới đây không phải tùy chọn. Mỗi bước là nền của bước sau: không có danh mục phòng thì không gắn được đặt phòng; không có hồ sơ khách thì không gắn được folio; không có đối tác thì không ghi được công nợ. Sau mỗi bước, dừng lại đối chiếu rồi mới đi tiếp — phát hiện lệch ở bước hai rẻ hơn rất nhiều so với phát hiện ở bước năm.

Bước 1 — Danh mục phòng, hạng phòng và bảng giá

• Nạp hạng phòng trước, phòng sau, rồi tới bảng giá gắn với từng hạng.
• Kiểm ngay: tổng số phòng trong hệ mới phải bằng đúng số phòng thực tế đang kinh doanh. Lệch một phòng ở bước này sẽ làm sai công suất mãi mãi về sau.
• Thử tạo một đặt phòng giả ở mỗi hạng để xem giá tự nhảy ra có đúng bảng giá vừa nạp không, rồi xóa đi.

Bước 2 — Hồ sơ khách và đối tác

• Nạp danh sách khách đã khử trùng lặp và danh mục công ty, đại lý, đoàn khách.
• Kiểm ngay: số bản ghi vào hệ mới so với số dòng trong file sau khi dọn. Chênh lệch phải giải thích được bằng số dòng bị loại vì trùng, chứ không được là con số bí ẩn.
• Tìm thử vài khách quen theo tên và theo số điện thoại để chắc chắn dấu tiếng Việt và định dạng số không bị vỡ.

Bước 3 — Khách đang ở và folio đang mở

• Đây là nhóm nhạy cảm nhất vì khách sẽ trả phòng trên hệ thống mới. Từng khách đang lưu trú phải được chuyển gắn đúng phòng, đúng ngày đến, đúng ngày đi dự kiến, đúng giá.
• Các khoản đã phát sinh trong folio (tiền phòng các đêm đã ở, dịch vụ đã ký nợ, khoản đã thu trước) chuyển theo từng dòng chi tiết, không gộp thành một dòng "tạm tính".
• Kiểm ngay: đứng ở quầy, mở sơ đồ phòng của hệ mới và đối chiếu bằng mắt với thực tế từng tầng.

Bước 4 — Đặt phòng tương lai và tiền cọc

• Mọi đặt phòng từ ngày cắt trở đi phải sang hệ mới, kèm nguồn đặt, giá đã thỏa thuận và chính sách hủy.
• Tiền cọc gắn theo từng đặt phòng cụ thể — không cộng dồn thành một khoản chung. Cọc là nghĩa vụ với một khách xác định vào một ngày xác định. (Riêng các khoản cọc còn treo, không xác định được của khách nào, xử lý theo hướng dẫn ở Phần 6.)
• Kiểm ngay: mở lịch 60 ngày tới, đối chiếu từng ngày có bao nhiêu phòng đã bán với bảng tính cũ. Đây là bước đối soát quan trọng nhất của cả đợt chuyển đổi.

Bước 5 — Công nợ

• Công nợ đối tác chuyển ở dạng số dư đầu kỳ, theo nguyên tắc trình bày ở Phần 6.
• Kiểm ngay: tổng số dư trong hệ mới bằng đúng tổng trên biên bản chốt công nợ đã ký.

Bước 6 — Các số dư đầu kỳ còn lại

• Quỹ tiền mặt tại quầy, số dư tài khoản dùng cho hoạt động của cơ sở tại ngày cắt.
• Voucher, phiếu quà tặng, đêm nghỉ đã bán chưa sử dụng — đây là nghĩa vụ với khách, bỏ sót là mất tiền khi khách quay lại đòi quyền lợi.
• Kiểm ngay: đếm tiền mặt thật tại quầy vào cuối ngày cắt và so với số đã nạp.

Phần 6: "Đóng sổ cũ, mở sổ mới" — nguyên tắc xử lý công nợ và tiền cọc

Đây là phần quyết định một đợt chuyển đổi diễn ra gọn gàng hay kéo dài lê thê hàng tháng. Nguyên tắc rất ngắn: đóng sổ cũ, mở sổ mới. Nhưng nó áp dụng theo hai hướng ngược nhau cho hai loại số tiền, và đây chính là chỗ hay bị làm sai.

Công nợ đối tác lịch sử: chỉ chuyển số dư

• Không chuyển chi tiết từng hóa đơn, từng lần thu của nhiều năm trước. Với mỗi đối tác, chuyển sang hệ mới đúng một dòng số dư đầu kỳ tại ngày cắt.
• Kèm theo dòng số dư đó là bảng kê chi tiết đính kèm — liệt kê các chứng từ tạo nên số dư — và một biên bản chốt công nợ có chữ ký của cả hai bên.
• Hệ cũ giữ ở chế độ chỉ đọc trong 3–6 tháng để tra cứu khi đối tác hỏi lại một hóa đơn cụ thể. Sau khoảng thời gian đó, mọi thắc mắc thực tế đã được xử lý xong.
• Vì sao làm vậy: chuyển chi tiết công nợ nhiều năm là công đoạn tốn thời gian nhất và sinh lỗi nhiều nhất trong mọi đợt chuyển đổi — dữ liệu càng cũ càng thiếu chuẩn, và không ai đủ thẩm quyền xác nhận từng dòng. Trong khi đó, thứ có giá trị pháp lý và giá trị vận hành thực sự là con số cuối cùng mà hai bên cùng ký, không phải đường đi dẫn tới con số đó.

Folio khách đang ở và tiền cọc: bắt buộc chi tiết

• Chiều ngược lại, folio của khách đang lưu trú và tiền cọc của các đặt phòng tương lai bắt buộc phải chuyển gắn theo từng booking. Tuyệt đối không gộp thành số tổng.
• Lý do rất cụ thể: khách đang ở sẽ trả phòng trên hệ thống mới. Nếu folio của họ chỉ là một con số tổng, quầy sẽ không xuất được hóa đơn đúng chi tiết, không tách được phần công ty trả với phần khách trả, và không xử lý được khi khách thắc mắc một khoản.
• Với tiền cọc cũng vậy: một khoản cọc gộp chung không thể tự trừ đúng vào hóa đơn của khách đã đặt ba tháng trước. Cọc phải nằm ngay trên đặt phòng của người đó.

Trường hợp cọc chưa rõ của khách nào

• Thực tế triển khai luôn gặp một nhóm nhỏ: những khoản tiền giữ chỗ đã nhận nhưng đang treo chung một chỗ ở cách ghi chép cũ, không còn xác định được là của khách nào, phòng nào.
• Nguyên tắc xử lý: cọc nào biết chắc của khách nào, đặt phòng nào thì gắn thẳng vào đặt phòng đó; cọc còn treo chưa rõ chủ thì không gán bừa vào một đặt phòng bất kỳ — hãy chuyển thành một khoản khách sạn còn phải trả, ghi mỗi khoản một dòng kèm bảng kê chi tiết ở phần kế toán.
• Cách này giữ được hai điều quan trọng cùng lúc: tiền của khách không biến mất khỏi sổ, và khi khách quay lại đòi quyền lợi thì vẫn truy ngược được khoản đó đến từ đâu.

Phần 7: Chạy song song và hoàn tác — vì sao không được cắt cầu ngay

Một đợt chuyển đổi được thiết kế tốt luôn có đường lui. Không phải vì người làm thiếu tự tin, mà vì nguyên tắc: hệ thống nào cũng có thể gặp tình huống không lường trước, và khách sạn thì không có quyền dừng bán phòng để chờ xử lý. Ba lớp bảo vệ dưới đây nên được thống nhất bằng văn bản trước khi bắt đầu.

Lớp 1 — Giữ nguyên hệ cũ ở chế độ chỉ đọc

• Không xóa, không dọn dẹp, không "tranh thủ sửa lại cho gọn" file cũ. Đóng băng nguyên trạng tại ngày cắt và chuyển sang chỉ đọc.
• Giữ tối thiểu 3–6 tháng. Đây là nguồn đối chiếu duy nhất khi có tranh luận, và chi phí giữ nó gần như bằng không.

Lớp 2 — Chạy song song một khoảng ngắn

• Chạy song song không có nghĩa là nhập đôi mọi thứ — với cơ sở nhỏ, bắt lễ tân gõ hai nơi là cách nhanh nhất khiến cả hai nơi cùng sai và cả đội cùng nản.
• Cách làm thực tế: từ ngày cắt, mọi nghiệp vụ chỉ nhập trên hệ mới. Song song đó, trong 3–7 ngày đầu, cuối mỗi ngày dành mười lăm phút đối chiếu ba con số với cách ghi chép cũ: doanh thu trong ngày, số phòng có khách, số lượt khách đến và đi.
• Ba con số này khớp liên tục một tuần thì có thể yên tâm. Lệch ở đâu thì phát hiện ngay trong ngày, lúc mọi người còn nhớ chuyện gì đã xảy ra.

Lớp 3 — Hoàn tác theo lô

• Mỗi lần nạp dữ liệu được đánh dấu thành một lô riêng. Nếu phát hiện lô nạp sai, gỡ toàn bộ lô đó và đưa hệ thống về đúng trạng thái trước khi nạp, thay vì đi sửa tay từng bản ghi.
• Điều kiện để hoàn tác sạch: chưa phát sinh giao dịch mới đè lên phần dữ liệu đó. Vì vậy việc đối chiếu ngay sau mỗi bước ở Phần 5 không phải thủ tục hình thức — nó là thứ giữ cho cánh cửa hoàn tác còn mở.

Chọn đúng thời điểm

• Chọn ngày công suất thấp trong tuần, tránh mùa cao điểm, tránh cuối tuần và các dịp lễ.
• Nên trùng với đầu một kỳ kế toán để sổ sách không bị cắt giữa kỳ.
• Đào tạo đội trước ngày chuyển, không đào tạo trong lúc chuyển. Ca đêm cần một buổi hướng dẫn riêng vì họ là người chạy kiểm đêm đầu tiên trên hệ mới.

Phần 8: Sau khi chuyển — kiểm tra những gì để yên tâm số liệu đúng

Chuyển xong không phải là hết. Một đợt chuyển đổi chỉ được coi là thành công khi bạn tự kiểm chứng được rằng số trong hệ mới đúng — bằng thao tác của chính mình, chứ không bằng lời khẳng định của người triển khai. Dưới đây là ba vòng kiểm tra theo thời gian.

Ngay trong ngày go-live

• Đối chiếu vật lý: cầm điện thoại mở sơ đồ phòng, đi một vòng các tầng. Phòng nào có khách trên hệ thống thì thực tế phải có khách.
• Chạy trọn một quy trình mẫu: tạo một đặt phòng → nhận phòng → ghi một khoản dịch vụ về phòng → đổi sang phòng khác → trả phòng → xuất hóa đơn. Toàn bộ chuỗi này phải đi hết không vướng, và số tiền cuối cùng phải đúng.
• Thử khai báo lưu trú cho một lượt khách để chắc chắn dữ liệu giấy tờ đã sang đủ.
• Kiểm tra phân quyền: đăng nhập bằng tài khoản lễ tân xem có nhìn thấy những mục lẽ ra chỉ chủ mới xem được không.
• Cuối ngày: đếm tiền mặt thực tế tại quầy và so với doanh thu tiền mặt hệ thống ghi nhận.

Trong tuần đầu

• Ba con số mỗi ngày: doanh thu, số phòng có khách, số lượt khách — đối chiếu với cách ghi chép cũ như đã nói ở Phần 7.
• Lịch 60 ngày tới: rà lại một lần nữa, đặc biệt các ngày cao điểm đã bán gần hết phòng. Đây là nơi một đặt phòng bị sót gây thiệt hại lớn nhất.
• Tổng tiền cọc trong hệ mới khớp với sổ quỹ và sao kê ngân hàng.
• Tổng số dư công nợ khớp với biên bản chốt đã ký ở Phần 6.
• Kiểm đêm chạy được trọn vẹn mấy đêm liên tiếp và tiền phòng được ghi tự động đúng cho từng phòng đang có khách.

Sau tháng đầu tiên

• Đối chiếu báo cáo tháng của hệ mới với cách tổng hợp cũ. Chênh lệch nếu có phải giải thích được bằng nguyên nhân cụ thể — thường là do cách cũ ghi dồn doanh thu vào ngày trả phòng, còn hệ mới rải theo từng đêm. Đây là chênh lệch đúng, không phải lỗi.
• Xem lại các chỉ số vận hành: công suất, giá bán bình quân, doanh thu trên mỗi phòng sẵn có — lần đầu tiên có được mà không phải tính tay.
• Ký biên bản nghiệm thu chuyển đổi, ghi rõ phạm vi dữ liệu đã chuyển, kết quả đối soát và ngày kết thúc thời hạn giữ hệ cũ ở chế độ chỉ đọc.

Khi các vòng kiểm tra này đi qua sạch sẽ, bạn không chỉ có một phần mềm mới. Bạn có một bộ số mà mình tin được — và từ đó mọi thứ tiếp theo, từ định giá phòng tới việc theo dõi cơ sở từ xa, mới có nền để đứng. Cùng một nền dữ liệu đó là chỗ dựa để sau này mở rộng sang các phần khác của phần mềm quản lý khách sạn cloud AI DiCloud: bán phòng đa kênh, trợ lý trả lời khách tự động, hay báo cáo cho chủ đầu tư trên điện thoại.

Kết luận

Chuyển dữ liệu từ bảng tính sang phần mềm quản lý khách sạn online chuyên ngành không phải một canh bạc, nếu bạn đi theo đúng trình tự: dọn dữ liệu và chốt ngày cắt trước, chuyển theo sáu nhóm và đối chiếu sau mỗi nhóm, áp dụng nguyên tắc đóng sổ cũ mở sổ mới cho công nợ lịch sử trong khi giữ nguyên chi tiết cho khách đang ở và tiền cọc, giữ hệ cũ ở chế độ chỉ đọc, và luôn có đường hoàn tác. Nỗi sợ mất dữ liệu là chính đáng — câu trả lời cho nó phải là một quy trình kiểm chứng được, không phải một lời hứa.

Với khách sạn mini, nhà nghỉ và homestay, ngưỡng để rời bảng tính thường đến sớm hơn chủ cơ sở nghĩ: khoảng 15–20 phòng, hai người cùng nhập liệu, hoặc ngày đầu tiên bán qua kênh trực tuyến. Từ mốc đó, một phần mềm quản lý nhà nghỉ và phần mềm quản lý khách sạn mini đúng nghiệp vụ trả lại cho bạn thứ đáng giá nhất: sự yên tâm rằng con số mình đang nhìn là con số thật. Khi cơ sở lớn lên thành chuỗi hoặc lên hạng 4–5 sao, cùng triết lý dữ liệu chuẩn từ gốc đó tiếp tục ở tầng cao hơn với phần mềm quản lý khách sạn AI DiHotel và phần mềm quản lý chuỗi khách sạn — nơi bài toán chuyển đổi phức tạp hơn nhiều lần, và bạn có thể xem trước checklist chuyển đổi hệ thống cho khách sạn 4–5 sao trong bài cùng kỳ trên DiHotel Blog. Còn nếu bạn muốn tìm hiểu thêm về nền tảng mà mọi dữ liệu sau chuyển đổi sẽ nằm lên, hãy đọc về phần mềm quản lý khách sạn online AI DiCloud và phần mềm quản lý homestay trong hệ sinh thái DiHotel Solutions.