Lựa chọn Phần mềm Mua sắm: Hướng dẫn Đánh giá Ưu tiên Quy trình làm việc

Lựa chọn phần mềm mua sắm là gì?

Việc lựa chọn phần mềm mua sắm không phải là một cuộc thi để thu thập danh sách yêu cầu dài nhất. Đó là một quyết định có quản lý về mức độ phù hợp của một hệ thống ứng cử viên với quy trình làm việc, tích hợp, nghĩa vụ dữ liệu, kiểm soát, người dùng, nhà cung cấp và khả năng thay đổi của tổ chức. Đầu ra phải là một gói quyết định có thể tái tạo: các kịch bản đã thử nghiệm, bằng chứng đã quan sát, các khoảng trống đã chấp nhận, các rủi ro đã sở hữu và các điều kiện triển khai đã đồng ý.

Danh mục có thể bao gồm tiếp nhận, tìm nguồn cung ứng, ký hợp đồng, mua hàng, lập hóa đơn, quản lý nhà cung cấp, phân tích hoặc kết hợp các yếu tố đó. Đừng quyết định giữa bộ phần mềm và giải pháp tốt nhất trong từng lĩnh vực như một học thuyết trừu tượng. Trước tiên, hãy xác định ranh giới quy trình làm việc, sau đó so sánh gánh nặng vận hành, di chuyển dữ liệu, tính liên tục của kiểm soát và đường thoát của từng kiến trúc khả thi.

Tại sao bắt đầu với quy trình làm việc thay vì các tính năng?

Các tính năng rất dễ trình bày riêng lẻ; các điểm lỗi nằm giữa chúng. Hướng dẫn của Ngân hàng Thế giới mô tả mua sắm điện tử rời rạc trong đó các quy trình thủ công và điện tử chạy song song hoặc chỉ các chức năng được chọn được kích hoạt, với hoạt động kém hiệu quả, dữ liệu trùng lặp và giảm tính minh bạch là kết quả được báo cáo. Bối cảnh của nó là mua sắm công, không phải so sánh sản phẩm, nhưng câu hỏi đánh giá vẫn chuyển giao: công việc có thể bị loại khỏi lộ trình được quản lý ở đâu?

Phương pháp ưu tiên quy trình làm việc cũng làm cho các điều kiện phi kỹ thuật trở nên rõ ràng. Một đánh giá hệ thống về mua sắm điện tử công cộng đã nhóm các thách thức triển khai trên công nghệ, tổ chức và môi trường, bao gồm chấp nhận và sử dụng, các vấn đề của các bên liên quan và lãnh đạo, đào tạo, sự phản kháng, quy định và bối cảnh quốc gia. Bài đánh giá đó không xếp hạng phần mềm, nhưng nó cảnh báo không nên coi cấu hình là toàn bộ sự thay đổi.

Những quy trình làm việc nào nên trở thành kịch bản đánh giá?

• Tiếp nhận và phân loại: người yêu cầu gửi một nhu cầu không đầy đủ; lộ trình phải làm nổi bật bằng chứng, quyền sở hữu và tính cấp bách còn thiếu mà không tạo ra một kênh ẩn.
• Tìm nguồn cung ứng và đánh giá: một nhóm khởi chạy một hệ thống được quản lý Quy trình làm việc RFP, thay đổi một tiêu chí, ghi lại các xung đột của người đánh giá và bảo toàn dấu vết quyết định.
• Hợp đồng và mua hàng: một giải thưởng đã được phê duyệt trở thành một yêu cầu, đơn đặt hàng, biên nhận, đối chiếu hóa đơn và ngoại lệ được kiểm soát mà không cần nhập lại dữ liệu quan trọng.
• Thay đổi nhà cung cấp: ngân hàng, thuế, lệnh trừng phạt, quyền sở hữu hoặc dữ liệu liên hệ thay đổi và hệ thống tách biệt việc gửi, xác minh, phê duyệt và bằng chứng kiểm toán.
• Dữ liệu và báo cáo: giao dịch tương tự có thể được truy tìm từ bản ghi nguồn thông qua phân loại đến phân tích chi tiêu, với dữ liệu bị thiếu và chậm trễ hiển thị.
• Thoát và liên tục: các bản ghi, tệp đính kèm, quyết định, quyền hạn, ánh xạ tích hợp và công việc đang mở có thể được xuất và đối chiếu mà không cần giả định sự hợp tác của nhà cung cấp.

Sử dụng thẻ để lập kịch bản kiểm tra tương tự cho mọi ứng viên. Cung cấp cho người trình diễn các vai trò và bản ghi mẫu, không phải yêu cầu tham quan. Ghi lại những gì xảy ra trên màn hình, những gì phải được cấu hình, những gì rời khỏi hệ thống, bước nào vẫn thủ công và cách người thứ hai có thể truy xuất bằng chứng. Lời hứa giải quyết một khoảng trống sau này không tương đương với sự phù hợp được quan sát; hãy theo dõi nó như một điều kiện chưa được giải quyết với một chủ sở hữu và thời hạn.

Mỗi nhà cung cấp nên đưa ra bằng chứng gì?

• Một buổi trình diễn trực tiếp, có kịch bản sử dụng kịch bản của người mua và dữ liệu đại diện—không chỉ là một lộ trình tiêu chuẩn được trau chuốt.
• Một bản ghi cấu hình phân biệt hành vi gốc, thiết lập do người mua quản lý, công việc của đối tác, mã tùy chỉnh và các tuyên bố lộ trình.
• Bằng chứng giao diện: hướng, trường, định danh, tần suất, xử lý lỗi, giám sát, quyền sở hữu và một mẫu đối chiếu.
• Kiểm soát bằng chứng: giới hạn quyền, lịch sử phê duyệt, nhật ký thay đổi, lưu giữ, xuất kiểm toán và xử lý ngoại lệ.
• Bằng chứng giao hàng: trách nhiệm được chỉ định, sự phụ thuộc, môi trường, phương pháp di chuyển và kiểm tra, tiêu chí chấp nhận và đầu ra của giai đoạn cổng.
• Bằng chứng thương mại và thoát: các giả định đằng sau giá cả, các yếu tố thay đổi có thể xảy ra, phương pháp trích xuất dữ liệu, định dạng có thể sử dụng, quy trình xóa và hỗ trợ chuyển đổi.

Bằng chứng phải đủ cụ thể để tồn tại khi chuyển giao từ lựa chọn sang triển khai. Ảnh chụp màn hình có thể hiển thị kết quả; chúng không chứng minh được khả năng lặp lại, quyền hạn, hành vi tích hợp hoặc quyền sở hữu. Ghi lại môi trường, dữ liệu, tác nhân, các bước, kết quả quan sát được, khoảng trống chưa được giải quyết và người đã chấp nhận kết luận. Liên kết mọi yêu cầu được chấm điểm với bản ghi đó.

Làm thế nào để kiểm tra rủi ro về tích hợp, dữ liệu, bảo mật và thoát?

Bắt đầu với kiến trúc và nghĩa vụ thực tế của tổ chức. Trong mua sắm điện tử công, hướng dẫn của Ngân hàng Thế giới cảnh báo rằng SaaS thương mại có thể không đáp ứng được khuôn khổ pháp lý phức tạp, đặc thù theo khu vực và mô tả các đánh đổi liên quan đến tuân thủ, tùy chỉnh, bảo mật dữ liệu, quyền riêng tư, khả năng tương tác và tính bền vững. Đó không phải là bằng chứng cho thấy SaaS kém hơn; đó là bằng chứng cho thấy các nhãn kiến trúc không thể thay thế cho một bài kiểm tra phù hợp.

• Theo dõi một giao dịch theo cả hai hướng trên mọi giao diện bắt buộc, bao gồm một tin nhắn đã sửa, trùng lặp, bị trì hoãn và thất bại.
• Kiểm tra vòng đời danh tính, vai trò có đặc quyền tối thiểu, phê duyệt được ủy quyền, hoạt động của quản trị viên, xem xét quyền truy cập và bằng chứng thay đổi khẩn cấp.
• Đối chiếu dữ liệu chính và dữ liệu giao dịch tại nguồn, giao diện, ứng dụng, kho và báo cáo; chỉ định chủ sở hữu có thẩm quyền cho từng xung đột.
• Truy xuất một mẫu kiểm toán mà không cần sự hỗ trợ của nhà cung cấp và xác nhận dấu thời gian, phiên bản, ngữ cảnh quyết định, tệp đính kèm và khả năng đọc xuất.
• Thực hiện diễn tập thoát trên các bản ghi đại diện và quy trình làm việc đang mở; đo lường mức độ hoàn chỉnh bằng cách đối chiếu, không phải bằng sự tồn tại của nút xuất.

Các bảng câu hỏi và chứng nhận bảo mật có thể hỗ trợ thẩm định, nhưng chúng không thay thế bằng chứng quy trình làm việc. Chọn các bài kiểm tra với chủ sở hữu về bảo mật, quyền riêng tư, pháp lý, hồ sơ, CNTT, mua sắm và kiểm soát nội bộ. Ghi lại rủi ro nào được ngăn chặn, phát hiện, sửa chữa, chuyển giao hoặc chấp nhận, và phân biệt kiểm soát hệ thống với chính sách hoặc xem xét thủ công bên ngoài nó.

Làm thế nào để bạn đánh giá sự phù hợp mà không che giấu một lỗ hổng nghiêm trọng?

Đánh giá bằng chứng, không phải chất lượng trình bày. Xác định các điểm neo trước khi trình diễn: ví dụ, chưa được chứng minh, quan sát thấy có lỗ hổng đáng kể, quan sát thấy có lỗ hổng có thể quản lý được và quan sát thấy từ đầu đến cuối. Giữ sự tự tin tách biệt với sự phù hợp để một lời hứa trong lộ trình không thể nhận được sự chắc chắn tương tự như một thử nghiệm lặp lại. Sau đó chạy kiểm tra độ nhạy và giải thích những giả định nào có thể đảo ngược khuyến nghị.

Làm thế nào để bạn kiểm tra mức độ chấp nhận trước khi ký kết?

Đặt người dùng đại diện vào tình huống, bao gồm những người yêu cầu không thường xuyên và nhà cung cấp bên ngoài, không chỉ riêng nhóm dự án. Một nghiên cứu phương pháp hỗn hợp quy mô nhỏ 2024 liên quan đến các phòng ban mua sắm, CNTT và người dùng và cơ sở hạ tầng, đào tạo và xây dựng năng lực được khuyến nghị cho nhân viên và nhà cung cấp. Môi trường một học viện, 30 người của nó quá hẹp để làm tiêu chuẩn, nhưng nó làm cho ranh giới vai trò trở nên rõ ràng.

• Yêu cầu người yêu cầu lần đầu gửi một nhu cầu thực tế và khắc phục trường bị thiếu mà không cần hướng dẫn.
• Yêu cầu người phê duyệt hiểu ngữ cảnh, ủy quyền chính xác, từ chối với lý do hợp lý và tìm quyết định trước đó.
• Yêu cầu bộ phận mua sắm thay đổi một sự kiện một cách an toàn, so sánh các phản hồi, ghi lại đánh giá và chuyển kết quả vào quy trình làm việc tiếp theo.
• Yêu cầu chủ sở hữu tài chính và kiểm soát theo dõi bằng chứng về mã hóa, dung sai, ngoại lệ, phê duyệt và báo cáo.
• Yêu cầu nhà cung cấp hoàn tất quá trình giới thiệu và phản hồi bằng cách sử dụng quyền truy cập, ngôn ngữ, tệp đính kèm và điều kiện hỗ trợ thực tế.
• Yêu cầu quản trị viên thay đổi một quy tắc, giải thích tác động, kiểm tra nó, hoàn tác và tạo hồ sơ thay đổi.

Quan sát việc hoàn thành, sự do dự, các giải pháp thay thế, lỗi, nhu cầu hỗ trợ và chất lượng của bản ghi kết quả. Đừng biến một phiên thành một dự báo áp dụng chung. Sử dụng nó để tìm ra ma sát, thiết kế lại quy trình làm việc, ước tính nhu cầu kích hoạt và quyết định những gì phải được chứng minh trong một dự án thí điểm. Bảo lưu sự bất đồng từ những người dùng có tần suất thấp và đưa các trường hợp ngoại lệ của họ vào cùng một thử nghiệm theo đường dẫn được quản lý.

Bạn đánh giá rủi ro triển khai và khóa nhà cung cấp như thế nào?

Coi quản trị triển khai là bằng chứng lựa chọn. Một trường hợp được bình duyệt đã sử dụng sự leo thang cam kết—xu hướng tiếp tục đầu tư vào một hành động thất bại—để phân tích sự cố ERP của một nhà sản xuất bao bì. Một trường hợp đơn lẻ không thể ước tính mức độ phổ biến hoặc dự đoán chương trình của bạn, nhưng nó hỗ trợ một biện pháp bảo vệ thiết thực: đồng ý trước về bằng chứng nào cho phép tiếp tục, sửa chữa, tạm dừng hoặc thoát.

Đối với mỗi giai đoạn, hãy nêu tên kết quả, bằng chứng chấp nhận, chủ sở hữu người mua và nhà cung cấp chịu trách nhiệm, các phụ thuộc chưa được giải quyết và điều kiện dừng. Tách biệt khám phá, cấu hình, di chuyển, tích hợp, kiểm tra kiểm soát, xác thực người dùng, chuyển đổi, ổn định và ngừng hoạt động; không đưa ra cam kết tiếp theo chỉ vì thời gian hoặc tiền bạc đã được chi tiêu. Bao gồm trích xuất dữ liệu, tài liệu, chuyển giao kiến thức và chuyển đổi thay thế trong hợp đồng và trong kế hoạch kiểm tra.

Các tác nhân AI thay đổi việc lựa chọn phần mềm mua sắm như thế nào?

Chạy các kịch bản tác nhân với các đầu vào đối nghịch và không đầy đủ: một chính sách xung đột, một tệp đính kèm bị thiếu, một danh tính nhà cung cấp không rõ ràng, một hướng dẫn được nhúng trong nội dung bên ngoài và một yêu cầu vượt quá thẩm quyền được ủy quyền. Kiểm tra hành động được đề xuất, các nguồn được sử dụng, độ tin cậy, leo thang, ghi đè và dấu vết kiểm toán bền vững. Giữ một người chịu trách nhiệm về các quyết định quan trọng của nhà cung cấp, thương mại, pháp lý, bảo mật và trao giải ngay cả khi phần mềm chuẩn bị công việc.

Gói quyết định cuối cùng nên chứa gì?

1. Tuyên bố vấn đề, ranh giới quy trình làm việc, các chế độ lỗi hiện tại, điều kiện thành công, các yếu tố không phải là mục tiêu và chủ sở hữu quyết định.
2. Các kịch bản được lập trình, dữ liệu đại diện, bằng chứng quan sát, kết quả điều chỉnh, điểm số có trọng số, độ tin cậy, khoảng trống và phân tích độ nhạy.
3. Kiến trúc, giao diện, danh tính, bảo mật, quyền riêng tư, hồ sơ, kiểm soát, báo cáo và kết quả thoát với sự chấp nhận có trách nhiệm.
4. Các bài kiểm tra người dùng và nhà cung cấp, các giả định về khả năng kích hoạt, mô hình hỗ trợ, các phát hiện về khả năng tiếp cận và tiêu chí chấp nhận thử nghiệm.
5. Các giai đoạn triển khai, sự phụ thuộc, bằng chứng di chuyển và đối chiếu, điều kiện dừng, rủi ro còn lại và chủ sở hữu được chỉ định.
6. Các giả định thương mại, yếu tố thúc đẩy thay đổi giá, cam kết dịch vụ, biện pháp khắc phục, điều khoản trả lại dữ liệu và lý do cuối cùng. Kết nối khuyến nghị với rộng hơn mô hình vận hành mua sắm gián tiếp, không phải với phần mềm một cách riêng lẻ.