Nhận biết thời điểm thay thế phần mềm doanh nghiệp lỗi thời

Tất cả các phần mềm doanh nghiệp rồi cũng sẽ lỗi thời. Dưới đây là cách xác định chính xác đâu là lúc phải thay thế phần mềm doanh nghiệp của bạn.

Gần đây có một khách hàng hỏi rằng liệu họ nên giữ lại hay đã đến lúc phải thay thế phần mềm quản trị doanh nghiệp ERP hiện tại của họ. Cũng như nhiều công ty khác, họ đã đổ tiền vào rất nhiều phần mềm suốt nhiều năm để xử lý các vấn đề trong môi trường kinh doanh của mình. Những phần mềm này chắc chắn rằng đã tạo nên những silo gây khó khăn trong việc đồng bộ các thông tin trùng lặp. Sử dụng phần mềm lạc hậu đồng nghĩa với việc nhân viên mới sẽ không biết gì về công nghệ đó (hãy nghĩ tới những phần mềm hiển thị với màu chữ xanh lá trên phông nền đen) và cần được đạo tạo chuyên sâu để sử dụng. Tương tự, việc báo cáo cũng vất vả khi mà doanh nghiệp không có đủ thông tin mà họ muốn. Câu hỏi của khách hàng như sau: Họ có hỗ trợ thêm thứ gì khác, chẳng hạn như thêm một lớp ứng dụng thông minh cho doanh nghiệp đè lên hệ thống có sẵn không, hay phải nâng cấp lên phiên bản ERP mới?

Jack Welch đã từng nói rằng “Nếu tốc độ thay đổi bên ngoài vượt quá tốc độ thay đổi bên trong doanh nghiệp thì ngày kết thúc đã gần lắm rồi.” Câu hỏi mà các công ty đối mặt trong tình huống này là liệu rằng các hệ thống có sẵn có thể được mở rộng cho phù hợp với sự phát triển như kế hoạch hay không, hay là chính những hạn chế của chúng sẽ kìm nén sự tăng trưởng. Ngay cả nếu các hệ thống hiện tại có thể mở rộng tạm thời thì viễn cảnh trong tương lai gần và lâu sài sẽ ra sao?

Với tốc độ thay đổi trong kinh doanh ngày nay, sẽ đến một lúc nào đó các hệ thống hiện tại sẽ không thể thích ứng được với các nhu cầu của các tổ chức. Ví dụ, những ứng dụng đó có thể hỗ trợ những quy định mới của chính phủ hay không? Với sự mai một tự nhiên thì sẽ sinh ra khoảng cách lớn dần giữa các nhân viên cũ và mới. Các tổ chức có thật sự muốn đầu tư đào tạo nhân viên mới sử dụng những ứng dụng lỗi thời này không? Vì thế, câu hỏi không phải là “Chúng ta có nên thay đổi không?”, mà là “Khi nào chúng ta nên thay đổi?”

Đáp án cho câu hỏi này là hãy tham khảo ý kiến của những người giàu kinh nghiệm, tuy nhiên quan điểm thì luôn mang tính thành kiến. Không có cách nào để né tránh thành kiến cả bởi vì mọi người đều bị giới hạn trong chính kinh nghiệm của mình. Ví dụ như với mức độ hiểu biết toàn diện về phần mềm ERP, thì kinh nghiệm thường sẽ hoặc là sâu hoặc là rộng, nhưng hầu như không bao giờ là cả hai. Kinh nghiệm cũng có tính kịp thời hoặc cũ kĩ, và với tốc độ thay đổi của thị trường thì kinh nghiệm sẽ trở nên lỗi thời rất nhanh.

Cách để tránh khỏi thành kiến chính là đánh giá xem phần mềm hiện thời đáp ứng được các yêu cầu đến mức nào và so sánh nó với các hệ thống thay thế tiềm năng. Nếu điểm của hệ thống hiện tại gần với hệ thống thay thế tiềm năng thì không cần phải tự tạo áp lực thay thế làm gì. Ngược lại, nếu khoảng cách điểm số giữa 2 hệ thống là khá lớn thì hãy thay thế càng sớm càng tốt.

Bắt đầu dựa trên nền tảng

Bước đầu tiên trong việc trả lời “giữ hay thay thế” là tạo ra danh sách các yêu cầu toàn diện. Vì chúng ta đang nói tới ERP nên sẽ có hàng ngàn yêu cầu được đặt ra.

Phân tích sai sẽ dẫn đến việc trả lời sai. Nếu khách hàng quyết định dùng hệ thống ERP mới, thì bất cứ yêu cầu quan trọng nào chưa được tìm ra trong quá trình phân tích sơ bộ sẽ được khám phá ra trong quá trình thực hiện. Nếu như có quá nhiều yêu cầu quan trọng bị bỏ lỡ trong quá trình phân tích thì hoàn toàn có khả năng sẽ chọn sai phần mềm. Thậm chí ngay cả nếu phần mềm thích hợp nhất được lựa chọn, mà không thể đáp ứng được tính năng “dùng được ngay” cho từng yêu cầu “mới” thì cũng đồng nghĩa với việc phải tốn nhiều thời gian cho việc thiết lập và chi phí đi kèm cao hơn. Các yêu cầu lẽ ra phải được phát hiện ra trong quá trình phân tích yêu cầu chính là nguyên nhân cơ bản của việc cài đặt trễ hạn và bội chi ngân sách.

Khi nói đến yêu cầu phát triển, hãy bắt đầu bằng việc xem xét các tính năng của phần mềm hiện tại đang được dùng, và viết lại chúng dưới dạng những yêu cầu. Quá trình này được gọi là đảo ngược các yêu cầu kỹ thuật từ các tính năng. Khá quan trọng khi áp dụng cùng kỹ thuật này với những hệ thống thay thế tiềm năng bởi vì đó là cách mà bạn tìm ra những yêu cầu mà bạn không biết được rằng bạn sẽ cần đến chúng. Kiểu yêu cầu mà khi người ta nhìn vào chúng và nói “Hm, chưa từng nghĩ về nó. Nhưng tôi có thể thấy được chỗ quan trọng để…”

Một khi bạn có được danh sách các yêu cầu chi tiết, bạn cần phải sắp xếp chúng theo thứ tự quan trọng với tổ chức của bạn. Tức là nắm được ai là người muốn các yêu cầu đó, tại sao họ muốn nó và nó quan trọng với họ tới mức nào. Khi bạn hoàn thành vấn đề này bạn sẽ phát triển được bản mô tả sơ lược các yêu cầu của mình, chính là nền tảng cho việc đưa ra lựa chọn tốt nhất cho những từng huống cụ thể của bạn.

Tính toán khoảng cách

Có được bảng mô tả sơ lược các yêu cầu hoàn chỉnh, bạn có thể tính toán được phần mềm hiện thời và phần mềm tiềm năng đáp ứng được như cầu đến mức nào. Bắt đầu bằng việc dùng bảng mô tả yêu cầu để tạo ra các đề nghị cung cấp thông tin RFI và đề nghị đưa ra đề xuất RFP đã được gửi cho các nhà cung cấp tiềm năng. Sử dụng bảng RFI hoặc RFP hoàn chỉnh để phân tích khoảng cách.

Sử dụng hệ thống tính điểm chuẩn hóa với 100% chính là điểm số cao nhất cho mức độ đáp ứng các yêu cầu, bạn có thể thấy có trường hợp điểm số của hệ thống hiện tại là khoảng 85%, trong khi điểm số của hệ thống mới cao nhất ở khoảng 90%. Điều đó cho thấy rằng thay thế hệ thống ngay bây giờ cũng không tạo ra kết quả khác nhiều lắm. Ngược lại, nếu hệ thống hiện tại rơi vào khoảng 65% và điểm cao nhất của hệ thống mới là khoảng 90% thì rõ ràng cần phải bắt đầu dự án thay thế ngay bây giờ. Nếu chuẩn bị thực hiện dự án thay thế mới, hãy kiểm tra lại các phân tích của bạn bằng cách tính toán lợi tức đầu tư ROI của dự án

Đề xuất

Cho phép tôi nhấn mạnh tầm quan trọng của việc đảo ngược các yêu cầu kỹ thuật từ nhiều sản phẩm khác nhau. Nếu bạn không tạo ra đủ các yêu cầu từ những tính năng của sản phẩm tiềm năng mới, thì hệ thống hiện tại sẽ có điểm số rất cao trong phân tích khoảng cách. Mặc dù bạn sẽ thu thập yêu cầu dựa trên các điểm yếu của phần mềm hiện tại, bạn vẫn cần đến các tính năng của các sản phẩm mới nhằm giúp mình tìm ra các yêu cầu mà bạn không biết được là bạn sẽ cần đến.

Để thu thập được các yêu cầu thích hợp cần phải mất rất nhiều công sức, nhưng dẫn lời của một khách hàng thì: “Lựa chọn phần mềm giống như việc sơn một tòa nhà. Công việc thật sự chính là khâu chuẩn bị, không phải khâu lựa chọn.” Với khách hàng này, việc sử dụng phân tích khoảng cách để tính toán mức độ đáp ứng yêu cầu của các sản phẩm hiện tại và tiềm năng dẫn đến một quyết định dựa trên dữ liệu có tính lý trí là có nên và khi nào thì thay thế hệ thống ERP hiện tại.

Nguồn bài viết : https://www.cio.com