Trình giải pháp cho kế toán: đừng đòi họ bỏ Excel

Hi lại là Hoàng đây! Tuần rồi mình ngồi hóng một buổi anh em bàn chuyện làm việc với phòng kế toán, và có một bạn đúc kết một câu làm mình nghĩ tới mấy ngày sau:

"yêu cầu đầu tiên khi muốn trình bày giải pháp với kế toán là hỗ trợ làm việc với excel đó anh"

Rồi ngay sau đó là câu chốt hạ, mình cho là câu hay nhất cả tháng:

"kêu họ thay excel là họ thay luôn mình :))"

Đọc thì buồn cười, mà ngẫm kỹ thì đúng tới mức hơi rát. Mình từng ngồi trong đúng cái phòng họp đó: BA mở slide, vẽ luồng, nói "hệ thống sẽ thay thế toàn bộ file Excel hiện tại, số liệu tập trung một chỗ, không còn sai lệch nữa" — nghe rất gọn, rất hợp lý, và chị kế toán trưởng ngồi im tới cuối buổi. Sau đó thì mọi thứ bắt đầu chậm lại: hỏi rule thì trả lời cầm chừng, xin file mẫu thì "để chị coi lại", tới lúc UAT thì lỗi nào cũng thành lỗi nghiêm trọng. Không ai nói thẳng là họ chống, mà giải pháp thì cứ nằm đó.

Nếu bạn là BA và sắp phải làm việc với phòng kế toán — kể cả khi hệ thống bạn làm không phải hệ thống kế toán, chỉ cần có số tiền chạy qua là thế nào cũng gặp — thì chuyện này đáng quan tâm, vì nó quyết định bạn lấy được rule thật hay chỉ lấy được rule mà người ta chịu kể cho bạn nghe.

Vì sao kế toán bám Excel — ba lý do rất thật

Cái nhãn "bảo thủ", "ngại công nghệ" mà dân IT hay dán cho phòng kế toán, mình thấy sai. Họ bám Excel vì ba lý do mà nếu ở vị trí họ, mình cũng làm y vậy.

Thứ nhất, họ tự sửa được. Tháng này sếp đổi cách tính hoa hồng, chị kế toán mở file, thêm một cột, sửa công thức, mười lăm phút xong. Còn với hệ thống thì quy trình là: gửi yêu cầu cho IT, chờ BA viết mô tả, chờ ưu tiên, chờ sprint, chờ test, chờ release. Cũng chuyện đó nhưng mất ba tuần. Với người có deadline chốt sổ cố định hằng tháng, ba tuần là không sài được.

Thứ hai, họ nhìn thấy hết cùng lúc. Đối soát là công việc quét mắt qua vài trăm dòng, thấy chỗ nào lệch thì tô vàng, ghi chú bên cạnh, lọc ra rồi so tiếp. Hệ thống thì bắt họ đi từng màn hình, mỗi màn hai chục dòng, muốn so hai kỳ với nhau phải mở hai tab. Cái họ mất không phải là tính năng, mà là khả năng bao quát.

Thứ ba, và cái này ít người để ý nhất: khi có sai sót, họ chứng minh được mình đúng bằng chính file của mình. Số này ra từ công thức này, công thức này lấy từ ô kia, ô kia là số phòng kinh doanh gửi qua ngày mấy. Toàn bộ chuỗi bằng chứng nằm trong tay họ. Hệ thống mới thì số cứ hiện ra, muốn biết vì sao ra số đó phải đi hỏi IT — mà người chịu trách nhiệm trước sếp về con số đó vẫn là họ.

Ba thứ đó, một giải pháp mới thường lấy đi cùng một lúc.

Excel sống dai không phải vì công ty nghèo

Có một chi tiết trong buổi hôm đó mình thấy đáng nhớ: một công ty tài chính rất lớn, hệ thống đủ cả, mà "vẫn chỉ dùng SAP để tính lương nhân viên văn phòng, còn sale tính excel".

Không phải họ không mua nổi module. Lương văn phòng thì ổn định, cấu hình một lần chạy được nhiều năm. Còn lương sale thì quý nào cũng đổi chính sách, đổi mức, đổi cách chia team, đổi cả cách tính phần thưởng đột xuất. Đưa cái đó vô hệ thống nghĩa là ký hợp đồng đổi cấu hình vĩnh viễn. Nên Excel ở lại — đó là một lựa chọn tỉnh táo, không phải một sự lạc hậu. Khi bạn thấy Excel còn sống dai ở một chỗ nào đó, câu hỏi đúng không phải "sao chưa bỏ" mà là "phần việc này thay đổi nhanh cỡ nào".

Câu "thay luôn mình" thật ra đang nói điều gì

Mình nói thẳng nhưng không có ý cay: khi giải pháp của bạn ngụ ý rằng phần việc thủ công kia là thừa, người ngồi đối diện tự hiểu rằng vị trí của họ cũng thừa theo.

Bạn nghĩ bạn đang bỏ đi một thao tác. Người nghe thì hiểu là bạn đang bỏ đi cái phần mà họ giỏi nhất, cái phần mà nhờ nó họ được hỏi ý kiến, được giữ lại qua mấy đợt cắt giảm. Bạn càng khoe hệ thống chạy tự động ngon nghẻ cỡ nào thì thông điệp ngầm càng rõ.

Cho nên trong mấy buổi đó, người ta phản đối giải pháp không phải vì giải pháp dở. Họ phản đối vì cái được đem ra đánh đổi không nằm trên slide của bạn. Và vì lý do thật không tiện nói ra, nó sẽ hiện ra dưới dạng khác: "cái này không đúng nghiệp vụ đâu em", "hệ thống làm sao xử lý được ca đặc thù", "chị thấy làm tay vẫn nhanh hơn".

Sai lầm quen thuộc: trình giải pháp bằng cách chê cái cũ

BA hay mở bài bằng phần "hiện trạng và vấn đề": file rời rạc, phiên bản lộn xộn, dễ sai, không lưu vết, không kiểm soát được quyền. Đúng hết. Nhưng cả cái danh sách đó, dịch sang tiếng người ngồi nghe, là "quy trình chị đang làm mấy năm nay dở".

Mình bỏ hẳn cách mở đó. Bây giờ mình mở bằng cách công nhận trước, và câu này bạn cứ mượn nguyên văn đem đi họp:

"File này chị dựng chắc lâu rồi ha, nhìn công thức là biết. Hôm nay em không tính thay nó, em muốn hiểu nó trước đã — vì rule thật nằm trong đây chứ không nằm trong tài liệu nào hết."

Câu đó không phải nịnh. Nó đúng thật: file Excel của kế toán thường là bản đặc tả nghiệp vụ chính xác nhất của công ty, chỉ là không ai viết nó ra thành tài liệu.

Neo giải pháp vô Excel thay vì đối đầu với nó

Đây là phần thao tác được. Nguyên tắc chung: đi cùng Excel, đừng đi ngược. Bốn thứ dưới đây mình đưa vô gần như mọi giải pháp có dính tới kế toán:

• Nhập từ Excel. Cho upload đúng cái file mẫu họ đang dùng, đừng bắt họ gõ lại từ đầu vô form. Nếu file của họ lệch chuẩn thì bạn viết mapping, chứ đừng bắt họ đổi thói quen ngay từ ngày đầu.
• Xuất ra Excel. Mọi báo cáo phải tải về được, và tải về đúng định dạng họ quen — đúng thứ tự cột, đúng cách gom nhóm, đúng cách hiện số âm. Xuất ra một file lạ hoắc rồi bắt họ ngồi sắp lại cột thì coi như chưa xuất.
• Đối soát. Có một màn cho họ tải file của họ lên, hệ thống so với số của hệ thống, lệch dòng nào chỉ ra dòng đó kèm lệch bao nhiêu. Đây là màn khiến họ tin hệ thống nhanh nhất, vì nó không bắt họ tin — nó cho họ tự kiểm.
• Phân vai rõ. Excel giữ bản nháp, giữ phần tính thử, giữ mấy kịch bản "nếu sếp duyệt mức này thì sao". Hệ thống giữ bản chốt và lưu vết ai chốt lúc nào. Nói rõ cái ranh giới này ra, người ta sẽ bớt cảm giác bị lấy mất đồ nghề.

Bốn cái đó gộp lại thành một thông điệp duy nhất mà bạn nên nói thành lời trong buổi họp:

"Em không đụng tới file của chị. Chị cứ giữ file, cứ tính nháp trong đó. Hệ thống nhận đúng file đó, trả về đúng định dạng đó, và chỗ nào lệch thì chỉ ra cho chị coi. Khi nào chị thấy số nó ra giống chị rồi thì mình tính tiếp."

Những câu mình hay hỏi trong buổi làm việc đầu tiên

Buổi đầu mình cố gắng không trình bày gì hết, chỉ hỏi. Mà hỏi cũng phải hỏi trúng, chứ hỏi "quy trình hiện tại của chị như thế nào" thì nhận lại một câu trả lời sạch sẽ và vô dụng.

Mình hay hỏi: file này ai dựng vậy chị, dựng lâu chưa? Câu này ra được một thứ quan trọng — nếu người dựng đã nghỉ và không ai dám sửa công thức nữa, thì bạn vừa tìm thấy lý do để họ muốn có hệ thống. Rồi: tháng nào là tháng dễ sai nhất? Thường sẽ ra tháng có thưởng, tháng quyết toán, tháng đổi chính sách — tức là ra luôn mấy ca ngoại lệ mà bạn sẽ không bao giờ tự nghĩ ra được. Rồi: chỗ nào chị phải sửa tay nhiều nhất sau khi công thức chạy xong? Chỗ đó chính là chỗ rule chưa được viết thành rule, còn nằm trong đầu người làm.

Và một câu nữa mình luôn hỏi trước khi kết thúc: nếu số cuối cùng ra sai thì chị lấy gì để chứng minh là mình làm đúng? Câu trả lời cho câu này quyết định bạn phải thiết kế log và màn tra cứu ra sao. Đây là kinh nghiệm cá nhân của mình, mình chưa thấy ai viết nó thành checklist, nhưng chưa lần nào hỏi mà không lòi ra thứ hay.

Khi nào mới nên đề xuất bỏ Excel

Bỏ Excel là kết quả đến sau, không phải điều kiện mở đầu. Mình chỉ đặt vấn đề đó khi có đủ hai thứ.

Thứ nhất, cái đau đã được chứng minh bằng số của chính họ, không phải bằng lập luận của mình: mỗi kỳ mất bao nhiêu giờ ngồi ghép file, một quý sai mấy lần, mấy lần phải làm lại từ đầu vì nhận file trễ. Số này bạn không tự bịa ra được, phải hỏi và ghi lại từ mấy buổi trước đó. Khi họ tự nói ra "tháng nào chị cũng mất nguyên hai ngày cuối tuần", thì lời đề nghị bỏ bớt việc thủ công không còn là mối đe doạ nữa.

Thứ hai, hệ thống đã chạy song song với file của họ vài kỳ liền và ra đúng số. Không phải một kỳ. Vài kỳ, gồm cả cái tháng dễ sai nhất mà họ đã kể cho bạn ở buổi đầu tiên. Chạy song song tốn công, nhưng nó là cách duy nhất mua được niềm tin thật.

Ghi vô tài liệu như thế nào cho khỏi rớt

Phần này BA hay làm hụt, để rồi tới lúc gần release mới cãi nhau. Có ba thứ mình luôn ghi cứng:

• Import và export không phải "nice to have" mà là điều kiện nghiệm thu. Ghi vô acceptance criteria (tạm dịch là tiêu chí nghiệm thu), có số hiệu đàng hoàng, để không ai cắt được nó khi scope phình ra.
• File mẫu phải đính kèm làm phụ lục, đúng cái file thật đã bôi xoá thông tin nhạy cảm, kèm ghi chú cột nào bắt buộc, cột nào tính ra được. Mô tả bằng lời không đủ, tới lúc dev làm là lệch.
• Rule đối soát phải viết rõ lệch bao nhiêu thì báo — lệch tuyệt đối, hay lệch theo phần trăm, hay chênh do làm tròn thì bỏ qua. Không có ngưỡng thì màn đối soát sẽ đỏ lòm và không ai thèm nhìn nữa.

Ba dòng này ngắn nhưng nó là thứ giữ cho giải pháp của bạn không bị bào mòn ở mấy vòng cắt scope cuối dự án.

Mặt trái: chiều Excel quá lâu thì hệ thống thành cái máy xuất file

Nói vậy không có nghĩa là chiều tới cùng. Mình thấy trường hợp này rồi: hệ thống làm import, làm export, làm đối soát rất ngon, và kết cục là không ai chịu nhập liệu vô hệ thống nữa. Mọi người vẫn làm hết trên Excel, cuối kỳ upload một phát lấy báo cáo. Dữ liệu thật vẫn nằm ngoài, hệ thống chỉ còn là cái máy xuất file cho đẹp.

Nên khi thiết kế theo hướng neo vô Excel, bạn phải đặt luôn mốc thời gian ngay từ đầu và nói ra trong buổi họp: giai đoạn một chạy song song, giai đoạn hai một số nghiệp vụ nhập thẳng trên hệ thống, giai đoạn ba Excel chỉ còn dùng để đối soát. Có mốc thì việc chuyển dần là kế hoạch đã thống nhất; không có mốc thì nó là chuyện sẽ bàn sau, và "sau" thường là không bao giờ.

Kết

Tóm lại, nếu tuần sau bạn có buổi trình giải pháp cho phòng kế toán: đừng mở đầu bằng phần chê hiện trạng, đừng hứa thay thế Excel, và nhớ rằng file của họ là bản đặc tả nghiệp vụ chính xác nhất mà công ty đang có. Hỏi trước, công nhận trước, rồi mới thiết kế — với import, export và đối soát nằm trong tiêu chí nghiệm thu chứ không nằm ở mục mở rộng. Còn chuyện bỏ Excel thì để dành, khi nào có số đau của chính họ và hệ thống đã ra đúng số vài kỳ liền thì tính.

Mấy thứ này phụ thuộc bối cảnh dự án kha khá — công ty có quy trình chốt sổ chặt hay lỏng, phòng kế toán mạnh hay yếu tiếng nói, đều làm đổi cách bạn đi. Nhưng cái nguyên tắc gốc thì mình nghĩ chỗ nào cũng đúng: người ta không chống công nghệ, người ta chống việc bị lấy mất chỗ đứng.

Hi vọng bài viết giúp bạn đỡ mất một buổi họp như mình từng mất. Cảm ơn bạn đã đọc tới đây, có kinh nghiệm nào khác khi làm việc với phòng kế toán thì để lại comment cho mình với nha :D