Hệ thống cũ: Nên cải tiến hay xây lại?
Khi phần mềm đã dùng nhiều năm bắt đầu khiến công việc chậm đi, doanh nghiệp dễ nghĩ đến việc xây một hệ thống mới. Tuy nhiên, tuổi đời chưa cho biết vấn đề nằm ở đâu. Điều cần xem xét là hệ thống còn đáp ứng nhu cầu quan trọng hay không, có thể điều chỉnh đến mức nào và việc tiếp tục sử dụng đang tạo ra những chi phí, rủi ro gì.
Hãy lấy một tình huống giả định: phần mềm kho vẫn ghi nhận nhập xuất, nhưng khi mở thêm địa điểm, nhân viên phải dùng các file riêng rồi đối chiếu số liệu hằng ngày. Doanh nghiệp có thể cần thay hệ thống, nhưng cũng có khả năng chỉ thiếu chức năng quản lý nhiều kho hoặc một cách kết nối dữ liệu phù hợp. Muốn lựa chọn, trước hết phải biết phần đang thiếu có bổ sung được không và những công việc nào đang phụ thuộc vào hệ thống hiện tại.
Bài viết giúp người phụ trách nghiệp vụ và người ra quyết định so sánh các hướng xử lý trước khi đầu tư. Ví dụ trên chỉ dùng để giải thích cách đánh giá, không phải kết quả dự án của Fenix.
1. Xác định công việc đang gặp khó trước khi chọn cách sửa
Nhận xét “hệ thống cũ quá” chưa đủ để quyết định nên làm lại. Với doanh nghiệp phân phối trong ví dụ, vấn đề có thể là không xem được tồn kho theo địa điểm, mất thời gian tổng hợp báo cáo hoặc chưa kiểm soát được ai có quyền điều chuyển hàng. Mỗi vấn đề cần được mô tả bằng công việc bị ảnh hưởng, tần suất xảy ra và nhu cầu sắp tới, chẳng hạn mở thêm kho, tăng giao dịch hoặc kết nối với đối tác.
Cách mô tả này giúp tách nhu cầu thực tế khỏi mong muốn thay đổi giao diện. Một báo cáo chạy chậm có thể liên quan đến chất lượng dữ liệu, cách truy vấn, hạ tầng hoặc việc tổng hợp thủ công bên ngoài. Nếu chưa biết nguyên nhân, thay toàn bộ phần mềm có thể chưa phải câu trả lời phù hợp.
Người hiểu nghiệp vụ sẽ giúp làm rõ công việc cần cải thiện, còn phần đánh giá kỹ thuật nên do người có chuyên môn thực hiện. Họ có thể cần tài liệu, phiên bản phần mềm, cấu trúc dữ liệu, thông tin kết nối, cách triển khai và mã nguồn nếu được phép truy cập. Khi thiếu một đầu vào quan trọng, kết luận cần nói rõ điều gì đã kiểm tra được và điều gì còn chưa chắc chắn.
Trước khi bàn đến phương án công nghệ, hai bên vì thế nên có cùng một cách hiểu về vấn đề cần giải quyết. Nếu chưa rõ cách chuyển những bất tiện hằng ngày thành yêu cầu cụ thể, doanh nghiệp có thể tham khảo bài dưới đây.
2. Xem xét các lựa chọn từ cải tiến đến thay thế
Sau khi đã xác định vấn đề, doanh nghiệp không nhất thiết chỉ chọn giữa giữ nguyên và bỏ toàn bộ hệ thống. Có thể cân nhắc các hướng dưới đây, tùy khả năng kỹ thuật và phạm vi công việc cần thay đổi.
Cải thiện phần đang gây khó khăn
Nếu hệ thống vẫn được duy trì, cấu trúc còn phù hợp và vấn đề tập trung ở một phần, có thể tối ưu hoặc bổ sung phần đó trước. Với phần mềm kho, đây có thể là cải thiện báo cáo tồn kho trong khi vẫn giữ cách ghi nhận nhập xuất đang hoạt động ổn định.
Tuy nhiên, phạm vi trên màn hình không phản ánh đầy đủ công việc phía sau. Một thay đổi nhỏ vẫn có thể tác động đến dữ liệu và các chức năng khác, nên phương án cải tiến cần được kiểm tra ảnh hưởng thay vì mặc định là dễ hoặc rẻ.
Bổ sung kết nối thay vì thay cả hệ thống
Có trường hợp chức năng chính vẫn đáp ứng nhưng nhân viên phải nhập lại thông tin vì các phần mềm chưa trao đổi được dữ liệu. Khi đó, một công cụ hỗ trợ hoặc phần kết nối có thể đáng cân nhắc, nếu hệ thống và điều kiện sử dụng cho phép.
Kết nối chỉ hữu ích khi dữ liệu và quy tắc đã được hiểu thống nhất. Nếu mã kho không khớp hoặc dữ liệu nguồn đang sai, tự động chuyển thông tin có thể khiến sai lệch lan sang phần mềm khác. Doanh nghiệp nên làm rõ luồng dữ liệu trước khi yêu cầu kết nối.
Tích hợp API giúp các phần mềm kết nối thế nào?
Thay từng nhóm chức năng theo giai đoạn
Nếu có thể xác định rõ phần nào được tách ra, doanh nghiệp có thể thay một nhóm chức năng trước và duy trì phần còn lại trong thời gian chuyển tiếp. Điều cần làm rõ là dữ liệu do bên nào quản lý, hai phần cùng hoạt động ra sao và ai xử lý khi thông tin không khớp.
Cách làm này tạo điều kiện thay đổi theo từng phần, nhưng đồng thời phát sinh công đồng bộ, đối chiếu và vận hành song song. Lợi ích phụ thuộc vào cách phân chia thực tế, chứ không thể kết luận cứ triển khai từng bước là ít rủi ro hơn.
Thay bằng sản phẩm khác hoặc xây lại
Khi nền tảng không thể đáp ứng các yêu cầu quan trọng và việc sửa đổi không khả thi hoặc không hợp lý, thay thế có thể là lựa chọn phù hợp. Phương án mới có thể dùng sản phẩm có sẵn, phát triển riêng hoặc kết hợp cả hai.
Dù chọn cách nào, phạm vi đầu tư cũng không dừng ở việc tạo ra phần mềm mới. Dữ liệu cần được chuyển, kết nối cần được thiết lập lại, người dùng cần được hướng dẫn và một số chức năng cũ có thể phải tiếp tục hoạt động trong giai đoạn chuyển tiếp.
3. So sánh các phương án trên cùng nhu cầu
Để so sánh có ý nghĩa, hãy đặt mỗi phương án trước cùng những yêu cầu bắt buộc. Với phần mềm kho, cả cải tiến lẫn thay thế đều phải được xem xét về khả năng quản lý nhiều địa điểm và những trường hợp ngoại lệ quan trọng. Một phương án có giao diện mới nhưng chưa giải quyết công việc đang bị vướng vẫn chưa đáp ứng mục tiêu.
Tiếp đó, hãy xem khả năng bảo trì và thay đổi sau triển khai. Doanh nghiệp cần biết ai có thể tiếp tục hỗ trợ, tài liệu có đủ không, công nghệ còn được hỗ trợ không và việc sửa một phần có thể ảnh hưởng đến đâu. Những câu trả lời này nên dựa trên bằng chứng khảo sát, thay vì suy từ tên công nghệ.
Dữ liệu và các hệ thống liên quan cũng phải được đưa vào so sánh. Một phần mềm ít người trực tiếp đăng nhập vẫn có thể cung cấp số liệu cho nhiều bộ phận. Vì vậy, cần xác định nơi đang nhận dữ liệu, những mã phải giữ lại và các báo cáo dùng để đối chiếu, để phương án mới không vô tình làm gián đoạn công việc ở nơi khác.
Cuối cùng, hãy so tổng nguồn lực cần thiết từ khảo sát, xây dựng, vận hành song song, chuyển đổi đến duy trì sau đó. Chỉ đặt giá sửa hiện tại cạnh giá phát triển mới sẽ bỏ qua nhiều công việc ảnh hưởng đến ngân sách và mức độ gián đoạn.
Doanh nghiệp có thể lập bảng với mỗi phương án là một dòng, rồi ghi khả năng đáp ứng yêu cầu bắt buộc, các phụ thuộc, chi phí cần xác minh, rủi ro và thông tin còn thiếu. Bảng này giúp nhìn ra khác biệt để trao đổi; không nên dùng tổng điểm để bù cho một điều kiện quan trọng chưa được đáp ứng.
4. Khảo sát những điểm còn thiếu căn cứ
Khi chưa rõ dữ liệu nào là nguồn chính, không có tài liệu kết nối hoặc nhiều nhà cung cấp cùng tham gia bảo trì, việc ước tính phương án sẽ còn nhiều điểm chưa chắc chắn. Thay vì yêu cầu một kết luận chung cho toàn hệ thống, doanh nghiệp có thể đặt câu hỏi khảo sát cụ thể: có bổ sung quản lý nhiều kho được không, phần kết nối có tách riêng được không, dữ liệu có xuất ra đúng cấu trúc cần dùng không?
Kết quả khảo sát nên phân biệt điều đã xác nhận, giả định còn lại và phần cần thử thêm. Nhờ đó, doanh nghiệp biết kết luận dựa trên căn cứ nào và còn thiếu gì trước khi quyết định. Một nhận định như “nên nâng cấp để tăng hiệu quả” chưa giúp trả lời các câu hỏi đó.
Nếu dữ liệu là điểm quyết định việc thay thế, khảo sát cần xem cả khả năng đưa dữ liệu sang hệ thống mới và cách kiểm tra sau chuyển đổi. Việc xuất được một file chưa đủ để kết luận dữ liệu đã sẵn sàng sử dụng. Nội dung chuẩn bị và kiểm tra dữ liệu sẽ được trình bày riêng trong bài sau.
Chuyển dữ liệu sang hệ thống mới: Cần chuẩn bị và kiểm tra gì?
Không phải trường hợp nào cũng cần một đợt khảo sát dài. Điều quan trọng là giới hạn công việc theo mức ảnh hưởng của quyết định và những thông tin thực sự còn thiếu, thay vì khảo sát nhiều nhưng vẫn chưa giải đáp được câu hỏi lựa chọn phương án.
5. Chọn bước tiếp theo và chuẩn bị việc chuyển đổi
Với doanh nghiệp phân phối trong ví dụ, bước tiếp theo có thể là kiểm tra khả năng quản lý nhiều kho trên môi trường thử hoặc đối chiếu dữ liệu của một kho mẫu. Kết quả sẽ giúp xác định nên sửa phần hiện tại, tách một chức năng hay đầu tư thay thế. Đây là cách thu hẹp những điểm chưa chắc chắn trước khi cam kết một phạm vi lớn hơn.
Nếu quyết định thay hệ thống, cần lập kế hoạch đưa vào sử dụng bên cạnh kế hoạch phát triển. Doanh nghiệp sẽ phải xác định khi nào chuyển sang cách làm mới, phần cũ nào còn cần duy trì và người dùng được hỗ trợ ra sao. Những việc này cần được chuẩn bị riêng, không coi là vài hạng mục phát sinh ở cuối dự án.
Đưa hệ thống mới vào sử dụng: Làm gì để hạn chế gián đoạn công việc?
Lựa chọn phù hợp vì thế không chỉ phụ thuộc vào hệ thống cũ đã tồn tại bao lâu. Nó cần dựa trên công việc muốn cải thiện, khả năng thay đổi đã được kiểm tra và nguồn lực để chuyển đổi. Khi trao đổi với đối tác phát triển, hãy mang theo những vấn đề cụ thể, tài liệu đang có và cả các điểm chưa rõ để cùng xác định phần cần đánh giá trước.
