Quá trình lựa chọn phần mềm từ trước đến nay thường xảy ra theo kịch bản: người mua gửi hồ sơ mời thầu với hướng dẫn để các nhà cung cấp lập hồ sơ dự thầu trong một thời gian. Các hồ sơ mời thầu phần lớn đều có dạng: ngoài phần giới thiệu ngắn gọn và hướng dẫn những điều nhà thầu cần tuân thủ là một danh sách dài các tính năng cần có cùng với một vài câu hỏi kiểu bài luận để nhà thầu trả lời.
Vấn đề đặt ra là: các hồ sơ mời thầu kiểu đó đã là công cụ tối ưu để lựa chọn phần mềm cho doanh nghiệp (DN) chưa? quá trình xét thầu có đảm bảo đưa đến quyết định tối ưu cho DN cần mua phần mềm không?
Các hồ sơ mời thầu truyền thống được thiết kế để mua được các hàng hoá thông dụng với giá tốt nhất và chúng vẫn đang làm tốt nhiệm vụ đó. Khi các món hàng có thể so sánh dễ dàng thì quá trình quyết định mua sắm chỉ tập trung vào giá và một hoặc hai yếu tố (chẳng hạn như ngày giao hàng). Khi đối tượng mua sắm thuộc cùng một nhóm nhưng không thể so sánh được (chẳng hạn như phần mềm cho DN) thì số lượng biến cần xem xét khi mua rất lớn và quá trình xét thầu truyền thống không giúp ích gì nhiều.
Cách phần lớn DN lựa chọn giải pháp phần mềm
Quy trình lựa chọn giải pháp phần mềm ở hầu hết các DN đều diễn ra theo một hình mẫu gần giống nhau, dù đó là phần mềm gì, từ nhà cung cấp nào cũng vậy. Xuất phát điểm của quá trình mua sắm, động lực của việc tìm kiếm phần mềm cho DN đều đến từ một vấn đề nhất định. Vấn đề đó có thể do những nhân viên trực tiếp tác nghiệp hay một vị lãnh đạo cao cấp phát hiện ra. Dù bằng con đường nào thì việc mua sắm phần mềm cũng phải được một trong những người lãnh đạo cấp cao ủng hộ. Sau khi Ban lãnh đạo quyết định về phần mềm cần sử dụng thì một nhà quản lý dự án được chỉ định phụ trách việc lựa chọn phần mềm. Sau khi bỏ công tìm hiểu sơ bộ về hệ thống, nhà quản trị dự án lập nhóm xét thầu từ những người sẽ chịu tác động của việc triển khai hệ thống mới. Một số người trong đó có thể là những cán bộ trực tiếp tác nghiệp đã phát hiện ra nhu cầu. Dù thế nào đi nữa thì trong hầu hết các trường hợp, nhóm xét thầu sẽ bao gồm những người có lợi ích và mong muốn khác nhau đối với phần mềm cần mua sắm. Nhà quản trị dự án sẽ đề nghị các thành viên nhóm xét thầu đóng góp ý kiến về yêu cầu của họ đối với phần mềm mới. Đến lượt mình, các thành viên nhóm xét thầu lại tự mình tìm hiểu hoặc yêu cầu các nhân viên dưới quyền (hoặc nhân viên tại các phòng ban có liên quan) trình lên danh sách các tính năng mà họ cảm thấy quan trọng. Bằng cách tìm kiếm trên Internet, hỏi thăm các DN trong cùng lĩnh vực đã triển khai phần mềm tương tự hoặc tham khảo ý kiến các nhà cung cấp, các đối tác chuyên tích hợp hệ thống, nhóm xét thầu và những cán bộ có liên quan sẽ tập hợp các chức năng mà họ tìm thấy vào hồ sơ mời thầu. Kết quả thu được là một danh sách khổng lồ các yêu cầu, tính năng. Dù được phân loại, sắp xếp, hồ sơ mời thầu vẫn là một tập hợp của những đòi hỏi, đôi khi mâu thuẫn với nhau. Các nhà thầu sẽ phải trả lời danh sách câu hỏi đó bằng các mệnh đề như “Có”, “Không” hay “Đáp ứng với một chút tuỳ chỉnh”. Tất nhiên, mỗi câu hỏi (yêu cầu) đều đã được gắn với một trọng số cho biết tính năng đó là “Bắt buộc”, “Quan trọng” hay “Có thì tốt hơn (không có)”.
Dù có bổ sung thêm một số câu hỏi kiểu bài luận, thường là về kiến trúc kỹ thuật của giải pháp, thì kết quả cuối cùng có thể dẫn đến việc một số yêu cầu mâu thuẫn với nhau (mức độ mâu thuẫn tuỳ thuộc vào số người tham gia xây dựng hồ sơ mời thầu và quan điểm của họ).
Quy trình lựa chọn phần mềm DN điển hình
Nhưng cuối cùng thì mọi việc cũng ổn vì chúng ta đã có hồ sơ mời thầu với tất cả các yêu cầu cần thiết và trong số những hồ sơ dự thầu sẽ có thể tìm được một giải pháp đáp ứng tất cả những yêu cầu của DN! Chắc hẳn các bạn sẽ nghĩ như vậy. Hãy cẩn thận, có một vấn đề căn bản trong quy trình chúng ta vừa xét trên đây: giải pháp phần mềm cho DN khác hẳn những hàng hoá thông thường vì chúng là một giải pháp để giải quyết một vấn đề cụ thể. Nhưng trong quá trình xây dựng hồ sơ mời thầu và xét thầu trên đây chưa xác định cụ thể vấn đề cần giải quyết. Điều nguy hiểm là nhiều người đã chấp nhận nó như một điều đương nhiên.
Tại sao cách làm đó không hiệu quả?
Các DN vẫn dùng cách mua sắm trên hàng chục năm qua và ít ai nghi ngờ hiệu quả của quy trình đó. Nhưng trong số những người từng phải chịu đựng hậu quả của phương pháp lựa chọn phần mềm như vậy, có người đã nhận ra rằng ở đây có “lỗi hệ thống”. Trước hết, việc xây dựng danh sách yêu cầu dài lê thê không thể đảm bảo phần mềm trúng thầu sẽ giải quyết vấn đề về nghiệp vụ mà DN đang đối mặt. Nếu không xác định rõ các vấn đề nghiệp vụ cần giải quyết, việc mua phần mềm chỉ làm cho mọi việc trở nên phức tạp và tệ hại hơn. Quá trình đấu thầu thông thường được thiết kế để mua sắm hàng hoá thông thường, những sản phẩm tương đương dễ so sánh. Với những sản phẩm phức tạp như phần mềm, khi số yếu tố so sánh quá lớn, quy trình chấm thầu thông thường rất khó đem lại kết quả rõ ràng, đúng đắn.
Với phương pháp xét thầu truyền thống, hầu hết các bài dự thầu gần giống nhau vì chúng được tạo ra để trả lời cho cùng một danh sách câu hỏi “có hay không”. Và danh sách câu hỏi đó xuất phát từ danh sách các tính năng mà hầu hết các lãnh đạo tầm trung gửi lên nhà quản trị dự án – người đặt ra câu hỏi “anh/chị cần gì ở hệ thống này”. Kết quả là với hầu hết nhóm chấm thầu, khi lật qua hàng trăm trang tài liệu dự thầu, họ không thấy rõ hơn một chút nào về giải pháp so với khi mới bắt tay vào việc. Với cách làm truyền thống đó, những DN càng bỏ công làm hồ sơ mời thầu càng lãng phí thời gian và công sức vì kết quả cuối cùng có thể vẫn là một mớ bòng bong.
Trong một vài trường hợp, đối với những người bán hàng giàu kinh nghiệm, họ biết rằng quá trình xét thầu sẽ khó đem lại kết quả nên họ không tốn thời gian cho việc viết tài liệu dự thầu. Họ tìm cách làm việc trực tiếp với các lãnh đạo cấp cao – những người có quyền quyết định và thúc đẩy quá trình xét thầu. Và khi kết quả của việc xét thầu đã trở thành một mớ bòng bong thực sự – khi DN không thể lựa chọn giải pháp một cách rõ ràng, các lãnh đạo cấp cao sẽ phải can thiệp để lựa chọn một hệ thống dựa trên quan điểm của mình. Điều đó không phải là xấu như một số người vẫn nghĩ, so với cách xét thầu thông thường, nó tốt hơn ở chỗ đảm bảo sự tham gia của lãnh đạo cấp cao vào quá trình lựa chọn giải pháp cho DN (hay ít nhất là giúp cho DN tránh khỏi nhiều vòng xét thầu vô vọng).
Vai trò của giai đoạn chứng minh khả năng (Proof of Concept – POC) và thử nghiệm (Pilot)
Để khắc phục “lỗi hệ thống” của quá trình lựa chọn giải pháp phần mềm truyền thống, chúng ta cần phải sử dụng một phương pháp khá thông dụng: chứng minh khả năng (Proof of Concept – POC) và thử nghiệm sản phẩm (Pilot Phase). Vậy chúng thực sự là một hay hai? Đôi khi hai khái niệm này được sử dụng lẫn lộn nên chúng ta cần phân biệt rõ vai trò của chúng.
Chứng minh khả năng (POC)
Đây là giai đoạn DN có nhu cầu mua sắm sử dụng thử giải pháp phần mềm với quy mô hạn chế để kiểm tra khả năng đáp ứng yêu cầu kỹ thuật (ví dụ như khả năng kết nối với một hệ thống đặc thù, khả năng xử lý giao dịch với tốc độ cao, khả năng xử lý lưu lượng giao dịch lớn) hay nghiệp vụ (chẳng hạn như khả năng tùy biến để tạo những sản phẩm mới, chính sách khuyến mãi đặc biệt) mà họ đặt ra. Mặc dù chỉ dùng thử ở quy mô hạn chế, DN vẫn có thể kiểm tra những vấn đề chỉ nảy sinh khi triển khai ở quy mô lớn bằng cách sử dụng các công cụ kiểm thử chuyên dụng.
Giai đoạn thử nghiệm (Pilot Phase)
Trong giai đoạn thử nghiệm, DN cũng cài đặt và dùng thử phần mềm với phạm vi hạn chế. Đó có thể là 10 người dùng ở 10 phòng ban liên quan sử dụng đầy đủ các chức năng của phần mềm hoặc một nhóm người dùng sử dụng một nhóm các chức năng quan trọng, chính yếu đối với DN trong khoảng một vài tuần.
Giai đoạn POC và Pilot cần được áp dụng như thế nào?
Những mô tả trên đây có thể khiến nhiều người lẫn lộn giữa hai công đoạn. Vì thế, để hiểu rõ hơn, chúng ta cần xem xét cách vận dụng chúng trong thực tế. Thông thường, rất ít khi DN yêu cầu chứng minh khả năng có thể chỉ rõ họ cần nhà cung cấp giải pháp chứng minh khả năng nào (cũng như phép đo, tiêu chí nào dùng để đánh giá nhà cung cấp có thực sự đáp ứng được nhu cầu của người dùng). Điều đó dẫn đến việc đánh đồng hai công đoạn POC và Pilot. Sau khi một số lãnh đạo tầm trung xác định một giải pháp phần mềm mà họ cho rằng có thể giúp công việc của họ dễ dàng hơn, lãnh đạo cao cấp vẫn không hề tham gia khiến cho những lãnh đạo tầm trung không hiểu rõ vấn đề nghiệp vụ mà họ định giải quyết. Giai đoạn Pilot và POC bị lẫn lộn với nhau, trong đó các lãnh đạo tầm trung cố gắng triển khai hay dùng thử một số giải pháp với hy vọng lãnh đạo cấp cao nhìn nhận kết quả đạt được và cho ý kiến chỉ đạo để triển khai mở rộng.
Cách làm đó rất ít khi thành công. Ngoài việc cần có sự can thiệp của lãnh đạo cấp cao để điều phối các nguồn lực cần thiết đảm bảo khả năng thành công của dự án, sự tham gia của họ từ giai đoạn đầu tiên của quá trình lựa chọn phần mềm là điều kiện tiên quyết để xác định rõ yêu cầu nghiệp vụ, làm rõ những yêu cầu nào là “sống còn” đối với DN. Không có sự tham gia của lãnh đạo cấp cao, không một vụ chứng minh khả năng nào có thể thành công.
Các DN lựa chọn và triển khai giải pháp phần mềm thành công thường phân tách hai công đoạn POC và Pilot. Giai đoạn triển khai thử diễn ra ngay sau khi quyết định mua sắm, khi mà thiết kế của hệ thống đã được xác nhận. Vai trò của nó là kiểm thử thiết kế và tinh chỉnh để chuẩn bị cho triển khi đại trà.
Nếu triển khai thử nghiệm được thực hiện với hy vọng lãnh đạo sẽ lựa chọn giải pháp khi nhìn thấy nó hoạt động, chúng ta sẽ thất bại và quy trình lựa chọn giải pháp sẽ không thể thành công.
Các DN cần lựa chọn giải pháp phần mềm như thế nào?
Trên đây chúng ta đã thấy vì sao quy trình lựa chọn giải pháp phần mềm bằng xét thầu truyền thống ít có cơ hội thành công. Từ những bài học đó, chúng ta có thể khái quát những nét chính của quá trình lựa chọn giải pháp hiệu quả cho DN như sau:
Xác định chính xác vấn đề cần giải quyết
Đây là việc làm đầu tiên và quan trọng nhất. Để làm được điều này cần có sự tham gia của lãnh đạo cấp cao và vì vấn đề xác định là vấn đề nghiệp vụ nên nó cần được làm rõ bằng các thuật ngữ nghiệp vụ. Câu hỏi có thể đặt ra là “Những quyết định kinh doanh nào chúng ta không thể đưa ra hoặc đưa ra một cách khó khăn có thể thực hiện một cách đơn giản sau khi triển khai giải pháp phần mềm?” Có thể có một chuỗi các thách thức về mặt kinh doanh mà giải pháp phần mềm cần giải quyết và lãnh đạo cấp cao cần chỉ rõ cho nhóm xét thầu.
Tạo cơ hội cho các nhà cung cấp xây dựng giải pháp
Sau khi xác định rõ vấn đề cần giải quyết, cần liên hệ với các nhà cung cấp “có khả năng” và đảm bảo quá trình làm việc giữa họ và lãnh đạo DN là minh bạch (để tránh những điều tiếng không hay). Những vụ “đi đêm” trở thành điều không thể vì quy trình lựa chọn giải pháp được giám sát và quản lý ngay từ đầu. Giúp nhà cung cấp hiểu rõ vấn đề và cho họ cơ hội giải quyết nó, DN sẽ hiểu thêm về thực trạng của mình khi cố gắng giải thích cụ thể những thách thức trong kinh doanh. Hơn thế nữa, DN có thể nhận ra “dải” giải pháp rộng hơn khi không tìm cách mô tả nó cho các nhà cung cấp. Tất nhiên, khi trao đổi với nhà cung cấp, DN cần đảm bảo họ hiểu rõ cả hai mặt của vấn đề: thách thức về kinh doanh cũng như những vướng mắc trong công nghệ. Chưa từng có một giải pháp nào không tác động đến quy trình của DN. Vì vậy, nếu nhà cung cấp giải pháp không thể giúp xử lý những phát sinh do thay đổi quy trình, điều đó có nghĩa là bạn mới chỉ xem xét một phần của giải pháp.
Gặp gỡ và tìm hiểu kinh nghiệm của những khách hàng đi trước
Sau khi xác định được những nhà cung cấp có thể giải quyết vấn đề, hãy yêu cầu họ cung cấp danh sách các khách hàng đã triển khai giải pháp. Những nhà cung cấp chất lượng thường có các khách hàng thành công và tốt bụng (để có thể vui lòng trao đổi với bạn về giải pháp họ đang dùng). Nhà cung cấp không thể cung cấp một địa chỉ tham chiếu nào sẽ đáng nghi hơn nhà cung cấp có một số khách hàng hài lòng. Trong khi tìm địa chỉ tham chiếu để tìm hiểu, cần chú ý một điều quan trọng: Các DN thường muốn tìm được một khách hàng gần giống mình nhất (về ngành nghề, về quy mô hay nền tảng công nghệ). Tuy nhiên, điều đó không hoàn toàn đúng. Bạn có thể thu được nhiều kiến thức hữu ích từ những khách hàng có quy mô khác hẳn hay sử dụng một phiên bản khác của phần mềm, điều quan trọng nhất là họ sử dụng phần mềm đó để giải quyết vấn đề gấn giống vấn đề của bạn nhất. Khi gặp gỡ (hay trao đổi qua thư) để tìm hiểu, đừng bỏ sót những câu hỏi sau đây:
1. Quy trình lựa chọn của quý công ty đã tiến hành như thế nào? Tại sao quý công ty lại chọn giải pháp phần mềm này?
2. Giải pháp này tác động đến quy trình kinh doanh của quý công ty như thế nào?
3. Thách thức lớn nhất của quá trình triển khai giải pháp này là gì?
4. Giá trị thu được lớn nhất từ việc áp dụng giải pháp này mà quý công ty nhận thấy là gì?
5. Quý công ty cho rằng giải pháp này sẽ biến đổi (phát triển) như thế nào trong tương lai?
Không có giải pháp nào là hoàn hảo, vì vậy không nên hy vọng sẽ có câu trả lời “hạnh phúc” cho tất cả các câu hỏi của bạn.
(Lưu Hữu Chuẩn – Trưởng bộ phận POC Insight-tec Vina)
Blogger Comment
Facebook Comment