Hội đồng thành phố Birmingham thoát “ác mộng” Oracle, nhưng di chứng kế toán vẫn kéo dài nhiều năm

Birmingham City Council, chính quyền địa phương lớn nhất châu Âu, đã có tín hiệu tích cực sau khi triển khai lại Oracle Fusion — bộ phần mềm doanh nghiệp trên nền tảng đám mây dùng cho tài chính, nhân sự và vận hành. Tuy nhiên, thành công kỹ thuật ban đầu vẫn chưa đủ để giải quyết cuộc khủng hoảng kế toán kéo dài. Đơn vị kiểm toán Grant Thornton dự kiến sẽ tiếp tục đưa ra “disclaimer opinion” cho các năm tài chính 2025/26, 2026/27 và 2027/28. Đây là loại ý kiến kiểm toán cho thấy kiểm toán viên không thu thập được đủ bằng chứng để kết luận báo cáo tài chính có đáng tin cậy hay không. Nói cách khác, cơ quan này vẫn lập báo cáo tài chính, nhưng các bên liên quan chưa thể nhận được sự bảo chứng độc lập về độ chính xác của các con số.

Theo báo cáo kiểm toán, đợt chuyển đổi sang hệ thống HR và tài chính mới dựa trên Oracle Fusion vào tháng 8 nhìn chung diễn ra suôn sẻ và được quản lý tốt hơn đáng kể so với lần triển khai đầu tiên năm 2022. Dù vậy, vấn đề cốt lõi lại nằm ở “historic data” — dữ liệu lịch sử tích lũy từ các hệ thống cũ và giai đoạn vận hành lỗi trước đây. Trong các dự án ERP, tức hệ thống hoạch định nguồn lực doanh nghiệp tích hợp tài chính, mua sắm, nhân sự và nhiều quy trình nội bộ, dữ liệu lịch sử đóng vai trò nền tảng để đối chiếu số dư, truy vết giao dịch và chứng minh tính đúng đắn của báo cáo tài chính. Khi phần dữ liệu này bị thiếu, sai hoặc không nhất quán, công tác kiểm toán có thể bị đình trệ trong nhiều năm ngay cả khi nền tảng mới đã hoạt động ổn định.

Người nộp thuế tại Birmingham có lý do để lo ngại. Lần triển khai Oracle Fusion đầu tiên từng khiến hội đồng thành phố không thể đối chiếu tài khoản ngân hàng và không nắm chắc tình trạng tiền mặt thực tế. Việc không thể “bank reconciliation” — tức đối chiếu giữa sổ kế toán nội bộ và sao kê ngân hàng — là một lỗi đặc biệt nghiêm trọng trong quản trị tài chính công. Nó không chỉ làm mờ bức tranh dòng tiền mà còn góp phần vào cuộc khủng hoảng tài chính dẫn đến tình trạng gần như phá sản trên thực tế của thành phố. Tổng chi phí dự án, bao gồm cả triển khai lại, hiện được ước tính vào khoảng 144,4 triệu bảng Anh, cao hơn rất nhiều so với dự toán ban đầu chỉ 20 triệu bảng. Nếu cộng thêm phần tiết kiệm hiệu quả vận hành bị bỏ lỡ, một số nhà nghiên cứu cho rằng tổng tổn thất có thể lên tới 216 triệu bảng.

Bất chấp di sản nặng nề từ quá khứ, hệ thống mới đang cho thấy sự cải thiện rõ rệt. Báo cáo cho biết hiện không còn bất kỳ ticket — tức phiếu ghi nhận lỗi hoặc yêu cầu hỗ trợ kỹ thuật — nào ở mức business-critical hay ưu tiên cấp 1, cấp 2. Đây là tín hiệu quan trọng trong các dự án phần mềm doanh nghiệp, nơi số lượng ticket nghiêm trọng thường phản ánh trực tiếp mức độ ổn định của hệ thống. Để so sánh, vào tháng 9/2025, hệ thống Oracle cũ có tên 1B vẫn còn tới 311 ticket mở cùng 2 sự cố lớn. Điều đó cho thấy lần triển khai lại không chỉ sửa lỗi kỹ thuật bề mặt mà còn cải thiện đáng kể năng lực vận hành hàng ngày.

Dù tiến độ khắc phục đã tốt hơn, Birmingham được cho là sẽ chưa thể lấy lại ý kiến kiểm toán “sạch” trước năm tài chính 2028/29 — tức gần 10 năm kể từ khi chương trình Oracle bắt đầu. Ban đầu, thành phố chọn Oracle Fusion để thay thế hệ thống SAP R/3 cũ, một nền tảng ERP thế hệ trước từng rất phổ biến trong doanh nghiệp và khu vực công. Kế hoạch nguyên bản đặt mục tiêu đưa các phân hệ tài chính và mua sắm vào hoạt động từ tháng 12/2020, còn nhân sự và bảng lương từ tháng 2/2021. Tuy nhiên, theo hồ sơ kinh doanh cập nhật năm 2021, cả hai mốc này đều bị lùi sang tháng 4/2022, báo hiệu những khó khăn đã xuất hiện từ sớm.

Một trong những nguyên nhân đáng chú ý là Birmingham ban đầu dự định triển khai Oracle theo mô hình “out of the box”, tức sử dụng phần mềm gần như nguyên bản theo cấu hình tiêu chuẩn của nhà cung cấp để giảm rủi ro và rút ngắn thời gian triển khai. Nhưng trên thực tế, hội đồng đã bổ sung nhiều tùy biến, trong đó có thiết kế đối chiếu ngân hàng không hoạt động đúng như kỳ vọng. Trong thế giới phần mềm doanh nghiệp, tùy biến sâu thường giúp đáp ứng quy trình đặc thù, nhưng cũng làm tăng độ phức tạp, khó bảo trì và khó nâng cấp về sau. Trường hợp Birmingham là ví dụ điển hình cho việc một dự án ERP có thể trượt khỏi quỹ đạo khi tổ chức cố ép phần mềm thích nghi hoàn toàn với quy trình cũ thay vì chuẩn hóa quy trình theo năng lực sẵn có của hệ thống.

Do không thể xác định chính xác vị thế tiền mặt và không cung cấp đủ bằng chứng cho kiểm toán viên, hội đồng thành phố đã phải chi hơn 5 triệu bảng cho các “manual workarounds” — những biện pháp xử lý thủ công tạm thời nhằm bù đắp cho lỗ hổng của hệ thống số. Đây thường là giải pháp bất đắc dĩ trong các tổ chức lớn: nhân sự phải xuất dữ liệu, đối chiếu bằng bảng tính, kiểm tra bằng tay hoặc nhập lại giao dịch để duy trì hoạt động. Vấn đề là các biện pháp này vừa tốn kém, vừa dễ phát sinh sai sót mới, đồng thời làm chậm quá trình quay lại trạng thái kiểm soát tài chính bình thường. Với Birmingham, bài toán công nghệ dường như đã bước sang giai đoạn ổn định hơn, nhưng “cơn say hậu kế toán” từ dữ liệu cũ và sai lầm triển khai vẫn sẽ còn đeo bám trong nhiều năm tới.