Cách tổ chức demo giải pháp công nghệ trước lựa chọn

Vì vậy, doanh nghiệp nên chuyển demo từ “xem sản phẩm hoạt động” thành một bài kiểm thử có cấu trúc: dùng tình huống nghiệp vụ trọng yếu, quy định trước dữ liệu đầu vào, xác định tiêu chí pass/fail, đo những chỉ số có thể định lượng và yêu cầu bằng chứng cho các điểm quan trọng. Những yêu cầu không thể chứng minh trong demo cần được ghi nhận riêng thay vì mặc nhiên xem là đã đáp ứng.

Demo phải là bài kiểm thử phục vụ quyết định, không phải buổi giới thiệu tính năng

Sai lệch phổ biến nhất của demo giải pháp công nghệ là để nhà cung cấp quyết định toàn bộ kịch bản. Khi đó, họ có xu hướng trình diễn những chức năng đã được chuẩn bị kỹ, với dữ liệu sạch, luồng xử lý lý tưởng và ít ngoại lệ. Một sản phẩm có thể tạo ấn tượng rất tốt trong điều kiện này nhưng gặp khó khăn khi phải xử lý đúng quy trình, dữ liệu và ràng buộc của doanh nghiệp.

Trước buổi demo, doanh nghiệp cần chuyển các yêu cầu quan trọng thành nhiệm vụ có thể quan sát được. Thay vì yêu cầu “hệ thống hỗ trợ phê duyệt nhiều cấp”, hãy yêu cầu nhà cung cấp thực hiện một giao dịch cụ thể đi qua đúng các cấp phê duyệt, thay đổi người phê duyệt giữa chừng, từ chối một bước và cho thấy hệ thống lưu lại lịch sử xử lý như thế nào.

Cách tiếp cận này tạo ra ba lớp kiểm chứng khác nhau:

·         Có chức năng: Giải pháp có cơ chế được yêu cầu hay không

·         Thực hiện được: Cơ chế đó có xử lý đúng tình huống của doanh nghiệp hay không

·         Đáp ứng được: Kết quả có đạt tiêu chí về thời gian, độ chính xác, kiểm soát, bảo mật hoặc vận hành hay không

Chỉ kiểm tra lớp đầu tiên thường chưa đủ cho quyết định lựa chọn. Hai sản phẩm đều có thể ghi “hỗ trợ workflow”, “có API” hoặc “có phân quyền”, nhưng cách những chức năng này vận hành trong quy trình thật có thể rất khác nhau.

Do đó, agenda của buổi demo nên được doanh nghiệp xác định trước. Nhà cung cấp có thể bổ sung phần giới thiệu của họ, nhưng những kịch bản bắt buộc phải được hoàn thành trước khi các điểm trọng yếu được coi là đã chứng minh.

Chọn tình huống thực tế theo mức độ quan trọng và rủi ro

Không cần đưa toàn bộ quy trình của doanh nghiệp vào một buổi demo. Cần ưu tiên những tình huống có khả năng phân biệt rõ giải pháp phù hợp và không phù hợp.

Một bộ kịch bản tốt thường bao gồm ba nhóm.

Nhóm thứ nhất là luồng nghiệp vụ cốt lõi. Đây là những việc người dùng sẽ thực hiện thường xuyên và trực tiếp tạo ra giá trị từ giải pháp. Nhà cung cấp cần thực hiện toàn bộ luồng từ đầu đến kết quả cuối, không chỉ mở từng màn hình để chứng minh tính năng tồn tại.

Nhóm thứ hai là tình huống phức tạp hoặc ngoại lệ. Đây thường là nơi khác biệt kỹ thuật xuất hiện rõ nhất: dữ liệu thiếu, giao dịch bị từ chối, người dùng thay đổi quyền, bản ghi trùng lặp, bước phê duyệt bị bỏ qua, kết nối hệ thống khác không phản hồi hoặc cần sửa dữ liệu sau khi quy trình đã chạy.

Nhóm thứ ba là yêu cầu có rủi ro cao nếu triển khai sai. Ví dụ có thể là phân quyền dữ liệu, truy vết thao tác, tích hợp với hệ thống lõi, khối lượng xử lý lớn hoặc khả năng xuất dữ liệu khi doanh nghiệp cần chuyển đổi hệ thống.

Số lượng kịch bản không quan trọng bằng khả năng bao phủ những yêu cầu quyết định. Trong thực tế, một nhóm nhỏ các kịch bản được chọn đúng thường hữu ích hơn hàng chục màn trình diễn tính năng rời rạc.

Dữ liệu demo cũng cần đủ gần với điều kiện vận hành thật. Nếu dữ liệu thực không thể cung cấp vì bảo mật hoặc quyền riêng tư, doanh nghiệp có thể tạo bộ dữ liệu giả lập nhưng giữ lại những đặc tính làm bài toán trở nên khó: số lượng bản ghi, độ dài trường, quan hệ giữa dữ liệu, trường thiếu, trường trùng, ký tự đặc biệt hoặc các trường hợp ngoại lệ.

Điều cần tránh là để nhà cung cấp thay thế dữ liệu kiểm thử bằng một bộ dữ liệu đã được tối ưu riêng cho sản phẩm mà không ghi nhận sự khác biệt đó.

Định nghĩa tiêu chí đạt trước khi xem demo

Một kịch bản chỉ thực sự dùng được để đánh giá khi doanh nghiệp biết trước thế nào là “đạt”. Nếu tiêu chí chỉ được quyết định sau khi xem sản phẩm, nhóm đánh giá rất dễ bị ảnh hưởng bởi giao diện đẹp, cách thuyết trình hoặc một tính năng nổi bật nhưng không quan trọng.

Tiêu chí nên được chia thành yêu cầu bắt buộc và yêu cầu dùng để phân hạng.

Yêu cầu bắt buộc là những điều giải pháp phải đáp ứng để có thể được lựa chọn. Chẳng hạn, nếu doanh nghiệp bắt buộc phân tách dữ liệu theo đơn vị kinh doanh, một giải pháp không thực hiện được cơ chế này không nên bù điểm bằng một tính năng khác hấp dẫn hơn.

Yêu cầu phân hạng được dùng khi nhiều giải pháp đều vượt qua điều kiện tối thiểu. Lúc đó doanh nghiệp mới so sánh mức độ thuận tiện, thời gian thao tác, số bước cấu hình, hiệu năng hoặc mức độ can thiệp kỹ thuật cần thiết.

Đối với các yêu cầu có thể đo, nên đặt metric cụ thể. Ví dụ, thay cho “phản hồi nhanh”, kịch bản có thể quy định thời gian phản hồi ở phân vị p95 không vượt quá một ngưỡng đã xác định dưới mức tải mục tiêu. Thay cho “nhập dữ liệu tốt”, có thể xác định số lượng bản ghi phải xử lý, thời gian hoàn thành, tỷ lệ lỗi cho phép và cách hệ thống báo lỗi.

Các con số phải xuất phát từ nhu cầu vận hành của doanh nghiệp, không nên sao chép một ngưỡng chung rồi coi đó là chuẩn cho mọi hệ thống. Một ví dụ về tiêu chí kiểm thử có thể là:

·         Xử lý 200 người dùng đồng thời với p95 thời gian phản hồi không quá 2 giây

·         Nhập 100.000 bản ghi trong tối đa 15 phút và chỉ chấp nhận các lỗi đã được định nghĩa trước

·         Hoàn thành 100% kịch bản được xếp loại bắt buộc

·         Không cho phép người dùng thuộc vai trò A xem hoặc sửa dữ liệu được giới hạn cho vai trò B

Đây là ví dụ về cách lượng hóa, không phải ngưỡng mặc định cho mọi doanh nghiệp. Một tổ chức có tải cực đại 2.000 người dùng hoặc yêu cầu giao dịch dưới 500 mili giây phải thiết kế bài kiểm thử tương ứng.

Khi có tiêu chí trước, kết quả demo có thể chuyển từ nhận xét “khá nhanh”, “có vẻ linh hoạt” sang bằng chứng có thể so sánh giữa các giải pháp.

Kiểm tra cả nghiệp vụ, tích hợp, dữ liệu, bảo mật và vận hành

Một giải pháp có thể hoàn thành chức năng chính nhưng vẫn không phù hợp khi đưa vào hệ sinh thái công nghệ hiện tại. Vì thế, demo không nên chỉ kiểm tra màn hình mà người dùng cuối nhìn thấy.

Kiểm tra tích hợp bằng luồng dữ liệu thực tế

Nếu giải pháp phải kết nối với ERP, CRM, hệ thống định danh, kho dữ liệu hoặc dịch vụ nội bộ, doanh nghiệp nên yêu cầu trình diễn ít nhất một luồng tích hợp đại diện.

Không nên dừng ở câu trả lời “có API”. Cần làm rõ API hoặc connector thực hiện được giao dịch nào, phương thức xác thực ra sao, hệ thống xử lý lỗi thế nào và dữ liệu được đồng bộ theo thời gian thực, theo lịch hay theo cơ chế khác.

Một khác biệt quan trọng là khả năng có sẵn và khả năng phải phát triển thêm. Nếu một yêu cầu chỉ thực hiện được sau khi viết custom code hoặc mua thêm module, điều đó phải được ghi nhận đúng trạng thái thay vì tính như tính năng đã có.

Kiểm tra chất lượng và vòng đời dữ liệu

Doanh nghiệp cần quan sát cách hệ thống nhập, xác thực, biến đổi, lưu, tìm kiếm, xuất và xóa dữ liệu trong những tình huống liên quan trực tiếp đến yêu cầu.

Nếu giải pháp tự động đưa ra kết quả dựa trên dữ liệu, cần kiểm tra đầu vào không hoàn hảo thay vì chỉ dùng mẫu sạch. Khi kết quả sai hoặc dữ liệu không hợp lệ, hệ thống phải cho thấy cách phát hiện, thông báo và xử lý ngoại lệ.

Kiểm tra quyền truy cập và khả năng truy vết

Không nên đánh giá bảo mật bằng một slide mô tả. Những kiểm soát có thể quan sát trong demo nên được thực hiện trực tiếp: tạo vai trò, giới hạn quyền, thử truy cập dữ liệu không thuộc phạm vi, thay đổi quyền và kiểm tra audit log.

Đối với các kiểm soát không thể chứng minh trong môi trường demo, doanh nghiệp cần yêu cầu tài liệu hoặc bằng chứng riêng. Việc không thể demo một kiểm soát không đồng nghĩa kiểm soát đó không tồn tại, nhưng cũng không nên tự động được đánh dấu “đạt”.

Kiểm tra hiệu năng trong điều kiện có ý nghĩa

Thời gian phản hồi quan sát được khi một người thao tác trên môi trường mẫu không chứng minh được khả năng chịu tải thực tế.

Nếu hiệu năng là yêu cầu trọng yếu, doanh nghiệp cần quy định dữ liệu, mức tải, loại giao dịch và metric trước. Có thể đo p50, p95 hoặc p99 tùy mức độ quan trọng của độ trễ, cùng throughput và tỷ lệ lỗi nếu phù hợp.

Demo trực tiếp không phải lúc nào cũng thích hợp để chạy load test hoàn chỉnh. Trong trường hợp đó, kết quả kiểm thử hiệu năng có thể được đánh giá bằng một hoạt động kỹ thuật riêng, nhưng phải giữ cùng nguyên tắc: workload, cấu hình, metric và điều kiện thử phải được biết rõ.

Yêu cầu nhà cung cấp trình diễn cả lỗi, ngoại lệ và giới hạn

Một demo chỉ chạy theo “happy path” thường che mất phần khó nhất của quá trình triển khai.

Doanh nghiệp nên cố ý đưa vào một số tình huống không thuận lợi. Ví dụ: API đích ngừng phản hồi, dữ liệu nhập sai định dạng, một người dùng mất quyền giữa quy trình, giao dịch bị gửi hai lần hoặc tác vụ xử lý dở dang.

Điều cần quan sát không chỉ là hệ thống có báo lỗi hay không mà còn là cơ chế phục hồi. Hệ thống có tự thử lại không? Có tạo giao dịch trùng không? Người vận hành biết tác vụ nào thất bại bằng cách nào? Có thể chạy lại một phần hay phải chạy lại toàn bộ? Log có đủ để xác định nguyên nhân không?

Đây cũng là thời điểm cần yêu cầu nhà cung cấp chỉ rõ giới hạn. Nếu một tính năng chỉ hỗ trợ đến một mức dung lượng, một loại dữ liệu hoặc một phương thức tích hợp nhất định, thông tin đó có giá trị cho quyết định hơn một câu trả lời chung rằng sản phẩm “có hỗ trợ”.

Tương tự, doanh nghiệp nên phân biệt rõ bốn trạng thái:

1.    Có sẵn và đã chứng minh: Chức năng tồn tại trong phiên bản được đề xuất và đã hoàn thành kịch bản

2.    Có sẵn nhưng chưa chứng minh: Nhà cung cấp khẳng định chức năng tồn tại nhưng buổi demo chưa kiểm chứng được

3.    Cần cấu hình hoặc phát triển bổ sung: Yêu cầu có thể thực hiện nhưng cần công việc ngoài cấu hình chuẩn

4.    Không đáp ứng: Giải pháp không thực hiện được yêu cầu trong phạm vi đề xuất

Việc phân loại này ngăn một cam kết “có thể làm được” được chấm điểm tương đương với khả năng đã chạy thành công.

Ghi lại bằng chứng thay vì chấm điểm bằng ấn tượng

Sau nhiều buổi demo, người đánh giá rất dễ nhớ sản phẩm có giao diện nổi bật hoặc người trình bày thuyết phục hơn là nhớ chính xác từng yêu cầu đã được chứng minh đến đâu.

Mỗi kịch bản vì vậy nên có một phiếu đánh giá thống nhất, tối thiểu ghi nhận:

·         Yêu cầu và kịch bản kiểm thử

·         Mức độ quan trọng hoặc trọng số

·         Điều kiện và dữ liệu sử dụng

·         Tiêu chí pass/fail

·         Kết quả quan sát được

·         Metric đo được nếu có

·         Chức năng chuẩn, cấu hình thêm hay custom

·         Giả định hoặc giới hạn được phát hiện

·         Bằng chứng hoặc tài liệu cần bổ sung

·         Người chịu trách nhiệm xác nhận kết quả

Các nhà cung cấp phải được đánh giá bằng cùng một tập yêu cầu cốt lõi. Nếu một giải pháp được phép thay thế kịch bản khó bằng một màn trình diễn khác trong khi đối thủ phải thực hiện đầy đủ, điểm số sẽ không còn so sánh được.

Đối với tiêu chí có trọng số, doanh nghiệp có thể dùng công thức đơn giản:

Điểm tổng = Σ (điểm tiêu chí × trọng số tiêu chí)

Tuy nhiên, các yêu cầu bắt buộc nên được đặt thành gate trước khi tính tổng điểm. Nếu không, một sản phẩm có thể thất bại ở yêu cầu mang tính quyết định nhưng vẫn thắng nhờ tích lũy điểm ở nhiều chức năng ít quan trọng hơn.

Một nguyên tắc hữu ích khác là không chấm cao cho những gì chưa được chứng minh chỉ dựa trên lời hứa sẽ có trong roadmap. Nếu roadmap vẫn được xem xét, trạng thái đó nên được ghi riêng cùng điều kiện, thời điểm dự kiến và mức độ phụ thuộc vào cam kết của nhà cung cấp.

Kịch bản demo nên được gửi trước nhưng không để nhà cung cấp kiểm soát bài kiểm tra

Gửi kịch bản trước giúp nhà cung cấp chuẩn bị đúng môi trường, dữ liệu và nguồn lực kỹ thuật. Điều đó không làm bài kiểm thử mất giá trị; mục tiêu của doanh nghiệp không phải tạo một “bài thi bất ngờ” mà là xác định giải pháp có đáp ứng yêu cầu hay không.

Tuy nhiên, doanh nghiệp cần kiểm soát nội dung bài kiểm tra. Nhà cung cấp có thể hỏi để làm rõ yêu cầu và chỉ ra điều kiện kỹ thuật cần thiết, nhưng không nên tự loại bỏ những kịch bản khó hoặc chuyển toàn bộ chúng thành slide mô tả.

Một cấu trúc thực tế có thể dành phần lớn thời gian cho các kịch bản do doanh nghiệp yêu cầu, sau đó mới dành một khoảng riêng để nhà cung cấp trình diễn những năng lực khác mà họ cho rằng có giá trị.

Trong buổi demo, nhóm nghiệp vụ nên xác nhận quy trình và kết quả, nhóm kỹ thuật kiểm tra tích hợp, dữ liệu và vận hành, còn nhóm bảo mật đánh giá các kiểm soát liên quan. Cách phân vai này hạn chế việc một tính năng được đánh giá tốt chỉ vì người xem không có đủ góc nhìn để phát hiện điều kiện hoặc hạn chế phía sau.

Khi nào demo chưa đủ và cần chuyển sang proof of concept

Không phải mọi yêu cầu đều có thể được xác nhận bằng một buổi demo. Khi rủi ro phụ thuộc mạnh vào môi trường thật, tích hợp phức tạp, tải lớn hoặc dữ liệu đặc thù, doanh nghiệp có thể cần một proof of concept trước khi đưa ra quyết định cuối cùng.

Dấu hiệu cho thấy demo chưa đủ gồm việc nhà cung cấp phải dùng slide thay cho thực thi ở một yêu cầu quyết định; tích hợp quan trọng chưa được kết nối; hiệu năng chỉ được mô tả bằng con số không gắn với workload; hoặc phần lớn giá trị dự kiến phụ thuộc vào cấu hình và phát triển chưa tồn tại.

Proof of concept cần thu hẹp vào những rủi ro còn chưa được giải quyết, không phải lặp lại toàn bộ demo. Nếu demo đã chứng minh tốt quy trình người dùng nhưng chưa chứng minh được khả năng xử lý khối lượng dữ liệu, PoC nên tập trung vào dữ liệu và tải. Nếu điểm chưa rõ là tích hợp, PoC nên kiểm tra interface và luồng dữ liệu cần thiết.

Cách này giúp doanh nghiệp sử dụng thêm thời gian kiểm thử đúng vào những giả định có khả năng làm thay đổi quyết định.

Một demo giải pháp công nghệ có giá trị trước lựa chọn phải tạo ra bằng chứng, không chỉ tạo ấn tượng. Doanh nghiệp nên tự xác định các kịch bản trọng yếu, đưa vào điều kiện thực tế và ngoại lệ, đặt tiêu chí pass/fail trước buổi demo, đo các yêu cầu có thể định lượng và ghi rõ điều gì đã được chứng minh, điều gì còn phụ thuộc vào cấu hình, phát triển hoặc cam kết của nhà cung cấp.

Khi cùng một bộ kịch bản, tiêu chí và cách ghi nhận bằng chứng được áp dụng cho các ứng viên, demo trở thành một công cụ giảm rủi ro lựa chọn: giải pháp được ưu tiên không phải vì trình diễn nhiều tính năng nhất, mà vì chứng minh được khả năng đáp ứng những yêu cầu quan trọng nhất trong điều kiện gần với môi trường doanh nghiệp.