Phần mềm có sẵn cần tùy chỉnh đến đâu?
Doanh nghiệp đã chọn phần mềm có sẵn nhưng khi dùng thử lại thấy thiếu một bước duyệt hoặc báo cáo không giống trước. Sửa cho giống cách cũ có vẻ thuận tiện, nhưng phần phát triển thêm cũng cần được kiểm tra, hỗ trợ và cập nhật. Quyết định nên bắt đầu từ công việc bị ảnh hưởng, không phải từ danh sách khác biệt trên màn hình.
Ví dụ xuyên suốt bài là một doanh nghiệp muốn thêm bước duyệt chi phí theo bộ phận. Đây là tình huống giả định. Khả năng cấu hình, mở rộng và điều kiện hỗ trợ khác nhau giữa các sản phẩm, nên cần xác nhận trên đúng phiên bản và gói dịch vụ đang dùng.
1. Xác định điều đang cản trở công việc
Hãy mô tả một trường hợp không xử lý được: ai lập đề nghị, ai cần duyệt, điều kiện nào làm đổi người duyệt và kết quả cuối phải là gì. “Thêm một cấp duyệt” chưa cho biết khi người đó nghỉ phép hoặc đề nghị bị trả lại thì ai tiếp nhận. Mô tả rõ các tình huống này giúp đối tác đánh giá giải pháp thay vì chỉ thêm một nút.
Sau đó hỏi vì sao quy tắc đó cần thiết. Nếu bước duyệt giúp người có trách nhiệm kiểm soát một khoản chi quan trọng, đây có thể là nhu cầu cần đáp ứng. Nếu chỉ vì phần mềm cũ có đúng bố cục ấy, cần thử xem chức năng chuẩn có cho người dùng làm được việc theo cách khác không. Quen thuộc và bắt buộc là hai lý do khác nhau.
Đừng chỉ hỏi người gửi yêu cầu. Kế toán có thể cần thông tin để đối chiếu, quản lý cần dấu vết phê duyệt, còn nhân viên chỉ cần biết hồ sơ đang ở đâu. Một thay đổi thuận tiện cho một người nhưng làm mất dữ liệu cần cho bộ phận sau chưa giải quyết trọn nhu cầu. Xác nhận kết quả ở cả đầu nhận trước khi chốt phạm vi.
2. So sánh cấu hình, đổi cách làm và phát triển thêm
Cấu hình là dùng những lựa chọn sản phẩm hỗ trợ, chẳng hạn thiết lập điều kiện duyệt nếu có. Đổi cách làm là điều chỉnh quy trình để dùng chức năng chuẩn. Phát triển thêm là bổ sung hành vi chưa có, qua phần mở rộng hoặc kết nối được sản phẩm cho phép. Tên gọi không giống nhau giữa các nhà cung cấp; cần xem cách thực hiện cụ thể.
Với duyệt chi phí theo bộ phận, hãy thử khả năng phân tuyến chuẩn và kiểm tra cả tình huống chuyển người duyệt. Nếu đã đáp ứng, chưa cần viết mới chỉ để giữ cách hiển thị cũ. Nhưng cũng không nên ép quy trình vào chức năng chuẩn khi thiếu một kiểm soát quan trọng đã được doanh nghiệp xác nhận.
Một công cụ ngoài có thể bổ sung bước thiếu, nhưng cần xem toàn bộ đường đi. Khi kết nối lỗi, đề nghị có bị ghi hai lần không, trạng thái duyệt ở đâu là đúng và ai xử lý? Một lựa chọn ít thay đổi sản phẩm chính vẫn có thể tạo thêm việc vận hành ở giữa hai hệ thống.
Nếu yêu cầu mới làm thay đổi phạm vi đã thống nhất với đối tác, cần ghi nhận ảnh hưởng trước khi bắt đầu sửa. Bài Yêu cầu thay đổi giữa dự án: Xử lý thế nào? giúp làm rõ cách tiếp nhận, chọn phương án và phê duyệt thay đổi, để một trao đổi trong buổi dùng thử không tự trở thành việc đã được giao.
3. Kiểm tra chi phí và khả năng cập nhật lâu dài
Hỏi rõ phương án có dùng cơ chế được nhà cung cấp hỗ trợ không và ai kiểm tra khi sản phẩm nâng cấp. “Không code” không có nghĩa không cần quản lý: luồng tự động vẫn có người sở hữu, quyền truy cập và các bước phụ thuộc. Cần có hướng dẫn để người khác tiếp nhận khi người tạo luồng chuyển việc.
Đặt các phương án trên cùng khoảng sử dụng dự kiến để xem chi phí ban đầu, thuê bao bổ sung, thử lại khi cập nhật và sửa sự cố. Phần chưa có báo giá cần được ghi là chưa biết, không tính bằng không. Cũng cần biết nếu sau này thay công cụ, dữ liệu và các quy tắc tự phát triển được lấy lại bằng cách nào.
Phần phát triển thêm chỉ có thể dùng bền vững khi trách nhiệm cập nhật và hỗ trợ được xác định. Bài Bảo trì phần mềm gồm những gì? giúp bạn hỏi rõ phần sửa nào thuộc dịch vụ đang thuê, phần nào cần thỏa thuận thêm và ai theo dõi khi có thay đổi từ nhà cung cấp.
Đối tác nên giải thích việc gì xảy ra khi một bản cập nhật làm phần tùy chỉnh không chạy đúng: ai nhận thông báo, thử lại ở đâu và có phương án tiếp tục công việc nào. Nếu sản phẩm có lịch cập nhật mà doanh nghiệp khó trì hoãn, thời gian kiểm tra phải được tính vào kế hoạch. Không nên đợi đến lần cập nhật đầu tiên mới thỏa thuận cách phối hợp.
Việc giữ chức năng chuẩn cũng cần bằng chứng cụ thể. Với ví dụ duyệt chi phí, hãy kiểm tra đề nghị sau khi duyệt vẫn sang được bước kế toán, người không có quyền vẫn bị chặn và báo cáo nhận đúng trạng thái. Một thay đổi chỉ được thử bằng tài khoản quản trị có thể bỏ sót giới hạn mà nhân viên thực tế sẽ gặp. Người nghiệp vụ phải tham gia xác nhận kết quả.
4. Thử một nhu cầu cụ thể rồi mới quyết định mở rộng
Chọn một nhu cầu quan trọng và thử trong môi trường phù hợp trước khi triển khai cho nhiều bộ phận. Ngoài đường xử lý bình thường, cần thử trả lại, hủy, thiếu thông tin và đổi người duyệt. Sau thay đổi, người dùng phải tiếp tục dùng được các chức năng chuẩn liên quan, không chỉ thấy bước duyệt mới xuất hiện.
Ghi kết quả theo nhu cầu ban đầu và các giới hạn còn lại. Nếu phần mở rộng chỉ đáp ứng một nhóm khách hoặc một bộ phận, đừng kết luận toàn công ty dùng được. Nếu phải can thiệp quá nhiều vào phần lõi và không có đường nâng cấp rõ, hãy xem lại phạm vi, công cụ bổ sung hoặc lựa chọn sản phẩm trước khi đầu tư tiếp.
Khi chấp nhận phương án, cần nhận cả cấu hình, hướng dẫn và người chịu trách nhiệm thay vì chỉ một chức năng chạy được. Bài Bàn giao phần mềm sao cho đội mới tiếp quản được? giải thích cách xác nhận đội nhận có thể tiếp tục vận hành hoặc sửa đổi phần được bàn giao.
Nếu đang cân nhắc tùy chỉnh, hãy trao đổi với Fenix từ một công việc chưa làm được, sản phẩm đang dùng và điều kiện hỗ trợ hiện tại. Làm rõ những điểm này giúp chọn mức thay đổi cần thiết, thay vì sửa mọi khác biệt hoặc chấp nhận mọi hạn chế.
