Bảo hành và bảo trì phần mềm là hai việc khác nhau. Bảo hành chủ yếu xử lý những lỗi thuộc phạm vi hệ thống đã được thống nhất và bàn giao, còn bảo trì là công việc duy trì để phần mềm tiếp tục hoạt động ổn định trong quá trình sử dụng lâu dài. Hai khái niệm này thường bị gộp chung nên doanh nghiệp dễ nghĩ rằng sau khi phần mềm được bàn giao thì mọi vấn đề phát sinh đều phải được xử lý miễn phí. Thực tế, cần phân biệt rõ lỗi của phần mềm, thay đổi do môi trường vận hành và những yêu cầu mới phát sinh từ doanh nghiệp.
Bảo hành là sửa những gì phần mềm đáng ra phải làm đúng
Một hệ thống có thể đã được kiểm thử và nghiệm thu nhưng khi đi vào sử dụng thực tế vẫn có khả năng phát sinh lỗi. Một nút không thực hiện đúng chức năng, công thức tính sai so với đặc tả, quyền người dùng hoạt động không đúng, một quy trình bị kẹt ở trạng thái nào đó hoặc dữ liệu hiển thị sai so với logic đã thống nhất đều có thể thuộc phạm vi bảo hành nếu nguyên nhân nằm ở phần mềm được bàn giao.
Điểm quan trọng là lỗi phải được đối chiếu với phạm vi và cách hoạt động đã được hai bên thống nhất trước đó. Nếu tài liệu thiết kế quy định một báo giá sau khi được duyệt phải chuyển sang trạng thái A nhưng hệ thống lại chuyển sang trạng thái B thì đó là lỗi. Nếu hệ thống được thiết kế chỉ có hai cấp phê duyệt nhưng sau khi sử dụng doanh nghiệp muốn bổ sung thêm một cấp thứ ba, đây lại là thay đổi yêu cầu chứ không phải lỗi bảo hành.
Vì vậy, bảo hành không nên được hiểu là khoảng thời gian nhà phát triển phải làm miễn phí mọi thứ khách hàng yêu cầu. Mục đích của bảo hành là đảm bảo phần mềm đã bàn giao hoạt động đúng với những gì hai bên đã thống nhất.
Bảo trì bắt đầu từ thực tế phần mềm không đứng yên sau khi bàn giao
Phần mềm có thể không thay đổi nhưng môi trường xung quanh nó vẫn thay đổi. Hệ điều hành được cập nhật, trình duyệt thay đổi, thư viện phần mềm có phiên bản mới, API của bên thứ ba được điều chỉnh, chứng chỉ bảo mật hết hạn, dung lượng dữ liệu tăng lên hoặc server bắt đầu chịu tải lớn hơn trước. Một hệ thống chạy tốt ở thời điểm nghiệm thu không có nghĩa là vài năm sau vẫn có thể vận hành mà không cần bất kỳ công việc kỹ thuật nào.
Bảo trì tồn tại để xử lý những vấn đề như vậy. Công việc có thể bao gồm cập nhật các thành phần kỹ thuật cần thiết, xử lý lỗ hổng bảo mật, kiểm tra backup, theo dõi tài nguyên server, xử lý sự cố vận hành hoặc điều chỉnh hệ thống để tiếp tục tương thích với các dịch vụ đang tích hợp. Mức độ bảo trì phụ thuộc khá nhiều vào kiến trúc và cách doanh nghiệp vận hành hệ thống.
Một phần mềm chạy hoàn toàn nội bộ với ít tích hợp có thể cần ít bảo trì hơn một hệ thống kết nối email, bản đồ, thanh toán, API của ERP, dịch vụ cloud hoặc các nền tảng bên ngoài. Càng nhiều thành phần phụ thuộc lẫn nhau thì khả năng một thay đổi từ bên ngoài ảnh hưởng tới hệ thống càng cao.
Hết bảo hành không có nghĩa phần mềm sẽ ngừng hoạt động
Nhiều doanh nghiệp nghe đến phí bảo trì thường có cảm giác giống như phải tiếp tục trả tiền nếu muốn phần mềm chạy. Không hẳn như vậy. Nếu doanh nghiệp sở hữu hệ thống và hạ tầng của mình thì phần mềm vẫn có thể tiếp tục hoạt động sau khi hết thời gian bảo hành.
Vấn đề nằm ở chỗ khi hệ thống phát sinh sự cố hoặc môi trường kỹ thuật thay đổi, doanh nghiệp cần có người đủ khả năng kiểm tra và xử lý. Doanh nghiệp có đội IT hoặc đội phát triển nội bộ có thể tự đảm nhận phần này. Nếu không có, họ có thể ký gói bảo trì với đơn vị đã phát triển hệ thống hoặc thuê một bên khác tiếp quản nếu mã nguồn, tài liệu và hạ tầng đã được bàn giao đầy đủ.
Đây cũng là lý do quyền kiểm soát hệ thống rất quan trọng. Doanh nghiệp nên nắm được mã nguồn cần thiết, dữ liệu, tài khoản server và các tài khoản hạ tầng quan trọng để việc vận hành lâu dài không phụ thuộc hoàn toàn vào một nhà cung cấp duy nhất.
Không phải lỗi nào xuất hiện sau này cũng thuộc bảo hành
Một tình huống khá phổ biến là hệ thống đang chạy bình thường nhưng một dịch vụ bên ngoài thay đổi. Nhà cung cấp email có thể đổi cơ chế xác thực, API của một nền tảng có thể ngừng hỗ trợ phiên bản cũ hoặc trình duyệt có thể thay đổi một cơ chế bảo mật. Phần mềm lúc được bàn giao không có lỗi, nhưng một thay đổi bên ngoài khiến một chức năng không còn hoạt động như trước.
Những trường hợp như vậy thường phù hợp với phạm vi bảo trì hơn là bảo hành, vì lỗi không xuất phát từ việc hệ thống ban đầu được xây sai. Tương tự, nếu doanh nghiệp tự thay đổi cấu hình server, xoá dữ liệu, chỉnh database hoặc để một bên thứ ba sửa mã nguồn rồi phát sinh lỗi, việc xử lý cũng cần được xem xét riêng thay vì mặc định đưa vào bảo hành.
Việc phân biệt nguyên nhân giúp hai bên tránh tranh luận sau này. Một hợp đồng tốt nên nói rõ những trường hợp nào được xem là lỗi của phần mềm, những trường hợp nào thuộc môi trường vận hành và những trường hợp nào nằm ngoài trách nhiệm của đơn vị phát triển.
Thêm chức năng mới không phải bảo hành cũng không nên gộp vào bảo trì
Sau vài tháng sử dụng, doanh nghiệp thường bắt đầu nhìn ra những nhu cầu mới. Sales muốn thêm một loại báo cáo, quản lý muốn thay đổi quy trình duyệt, kỹ thuật cần thêm trường dữ liệu hoặc công ty mở thêm một bộ phận mới cần sử dụng hệ thống theo cách khác. Đây là dấu hiệu bình thường của một phần mềm đang được sử dụng thực tế.
Nhưng những thay đổi đó là phát triển thêm, không phải sửa lỗi. Nếu ban đầu hệ thống có hai cấp phê duyệt và doanh nghiệp muốn bổ sung thêm một cấp, cần xem đó là change request. Nếu dashboard hiện năm chỉ số đúng như thiết kế nhưng quản lý muốn thêm ba chỉ số mới, đó cũng là một phần phát triển thêm.
Phân biệt rõ điểm này giúp doanh nghiệp kiểm soát được chi phí và giúp đơn vị phát triển ước lượng công việc chính xác hơn. Những thay đổi nhỏ có thể được gom lại thành một đợt nâng cấp, còn thay đổi lớn có thể được đưa vào một phiên bản mới của hệ thống.
Bảo trì tốt không có nghĩa là liên tục sửa phần mềm
Nếu hệ thống được thiết kế và triển khai tốt, phần lớn thời gian bảo trì không phải là ngồi sửa lỗi liên tục. Giá trị của bảo trì nằm ở việc phát hiện và xử lý vấn đề trước khi nó ảnh hưởng lớn tới hoạt động của doanh nghiệp.
Ví dụ, dung lượng lưu trữ tăng nhanh có thể được phát hiện trước khi server hết ổ đĩa. Một phiên bản thư viện có lỗ hổng bảo mật có thể được cập nhật trước khi trở thành rủi ro. Backup có thể được kiểm tra định kỳ thay vì chỉ đến khi server gặp sự cố mới phát hiện bản sao lưu không sử dụng được. Các cảnh báo về tài nguyên, lỗi ứng dụng hoặc dịch vụ ngừng hoạt động cũng có thể được theo dõi để giảm thời gian gián đoạn.
Với hệ thống quan trọng đối với hoạt động kinh doanh, bảo trì vì vậy giống một lớp đảm bảo vận hành hơn là một khoản phí chỉ để chờ đến khi có lỗi rồi sửa.
Thời gian bảo hành và phí bảo trì nên được thống nhất ngay từ đầu
Khi ký hợp đồng phát triển phần mềm, doanh nghiệp nên biết rõ hệ thống được bảo hành trong bao lâu, thời gian này bắt đầu từ lúc nào và phạm vi bảo hành gồm những gì. Các mức độ lỗi khác nhau cũng có thể cần thời gian phản hồi khác nhau. Một lỗi khiến toàn bộ hệ thống không đăng nhập được rõ ràng cần được xử lý khác với một lỗi hiển thị nhỏ không ảnh hưởng tới công việc.
Sau thời gian bảo hành, hai bên có thể tiếp tục bằng gói bảo trì nếu doanh nghiệp có nhu cầu. Chi phí bảo trì nên gắn với phạm vi công việc thực tế chứ không chỉ ghi chung chung là một tỷ lệ hàng năm. Doanh nghiệp cần hiểu mình đang trả tiền cho việc gì: hỗ trợ sự cố, cập nhật kỹ thuật, theo dõi server, backup, bảo mật hay một số giờ thay đổi nhỏ mỗi tháng.
Nếu doanh nghiệp không muốn sử dụng dịch vụ bảo trì của đơn vị cũ, hệ thống cũng nên có khả năng được bàn giao để một đội khác tiếp quản. Điều đó cần được tính tới từ lúc thiết kế tài liệu, quản lý source code và cấu hình hạ tầng chứ không phải đợi đến khi hai bên ngừng hợp tác mới xử lý.
Bảo hành đảm bảo phần mềm đúng, bảo trì giúp phần mềm tiếp tục ổn định
Có thể hiểu ngắn gọn: bảo hành trả lời câu hỏi “phần mềm đã làm có đúng như cam kết không?”, còn bảo trì trả lời câu hỏi “làm thế nào để hệ thống tiếp tục vận hành tốt trong những năm tiếp theo?”. Hai việc liên quan với nhau nhưng mục đích hoàn toàn khác.
Với phần mềm theo yêu cầu, doanh nghiệp nên làm rõ ngay từ đầu phạm vi bảo hành, thời gian bảo hành, cách tiếp nhận lỗi, trách nhiệm với hạ tầng, chính sách bảo trì và cách xử lý các yêu cầu phát triển thêm. Khi những điều này rõ ràng, doanh nghiệp sẽ biết khoản nào đã nằm trong giá triển khai ban đầu, khoản nào thuộc trách nhiệm bảo hành và khoản nào là chi phí để duy trì hoặc mở rộng hệ thống về sau.