Thử nghiệm trước khi nhân rộng: Vì sao mô hình tốt ở một nhóm nhỏ chưa chắc phù hợp toàn hệ thống?

Khi một chương trình mới tạo ra kết quả tích cực, phản ứng tự nhiên của người lãnh đạo thường là:

Cách này đang hiệu quả, hãy triển khai ngay cho tất cả mọi người.

Một nhóm tổ chức buổi trải nghiệm rất thành công.

Một người đào tạo thành viên mới đạt tỷ lệ tham gia cao.

Một sản phẩm được khách hàng phản hồi tốt.

Một khu vực áp dụng chính sách mới và doanh số tăng.

Một công cụ giúp tiết kiệm nhiều thời gian.

Một hoạt động cộng đồng thu hút đông người.

Những kết quả đó tạo ra sự hào hứng.

Hệ thống muốn mở rộng thật nhanh để:

• Tiếp cận nhiều khách hàng hơn.
• Tăng doanh thu.
• Tận dụng thời điểm thị trường.
• Tạo lợi thế cạnh tranh.
• Nhân bản một cách làm đang có kết quả.
• Không bỏ lỡ cơ hội.

Nhưng một mô hình hoạt động tốt ở một nhóm nhỏ chưa chắc sẽ tiếp tục hoạt động tốt khi được triển khai cho:

• Nhiều khu vực.
• Nhiều người thực hiện.
• Nhiều loại khách hàng.
• Nhiều nhà cung cấp.
• Nhiều cấp quản lý.
• Khối lượng dữ liệu lớn hơn.
• Những người có năng lực và động lực khác nhau.

Khi quy mô thay đổi, bản chất của vấn đề cũng có thể thay đổi.

Điều từng được giải quyết bằng sự tận tâm của một người có thể không thể lặp lại bởi hàng trăm thành viên.

Quy trình từng phù hợp với 20 khách hàng có thể trở nên quá tải với 2.000 khách hàng.

Một chương trình thành công nhờ người sáng lập trực tiếp dẫn dắt có thể không còn hấp dẫn khi được giao cho người chưa đủ kinh nghiệm.

Một sản phẩm nhận phản hồi tốt từ nhóm dùng thử được lựa chọn kỹ chưa chắc tạo ra kết quả tương tự với toàn bộ thị trường.

Vì vậy, câu hỏi quan trọng không chỉ là:

Mô hình này đã từng thành công chưa?

Mà là:

Thành công đó đến từ yếu tố nào, có thể lặp lại trong điều kiện khác hay không và hệ thống có đủ năng lực kiểm soát những rủi ro xuất hiện khi mở rộng không?

Thành công nhỏ có thể đến từ những điều không thể nhân rộng

Một chương trình thử nghiệm thường có những điều kiện đặc biệt.

Ví dụ:

• Người tham gia được lựa chọn kỹ.
• Người lãnh đạo trực tiếp theo sát.
• Nhóm nhỏ nên giao tiếp thuận lợi.
• Mọi người có động lực cao.
• Nguồn lực được ưu tiên.
• Vấn đề được giải quyết rất nhanh.
• Nhà cung cấp hỗ trợ trực tiếp.
• Khách hàng biết mình đang tham gia thử nghiệm nên thông cảm hơn.
• Đội ngũ triển khai là những người có năng lực tốt nhất.

Những điều kiện này có thể làm kết quả đẹp hơn thực tế khi triển khai rộng.

Ví dụ, một chương trình onboarding thử nghiệm với 20 thành viên đạt tỷ lệ hoàn thành 90%.

Nhưng nhóm thử nghiệm được:

• Gọi điện riêng.
• Nhắc lịch hằng ngày.
• Có người giải đáp ngay.
• Được lãnh đạo trực tiếp hướng dẫn.
• Lựa chọn từ những người đang có động lực mạnh.

Khi triển khai cho 2.000 thành viên, hệ thống không thể duy trì cùng mức hỗ trợ.

Nếu chỉ nhìn tỷ lệ 90% rồi kết luận rằng quy trình đã sẵn sàng nhân rộng, tổ chức có thể đánh giá quá cao mô hình và đánh giá quá thấp nguồn lực đã tạo ra kết quả.

Cần tách biệt:

• Phần nào thuộc về mô hình?
• Phần nào thuộc về người thực hiện?
• Phần nào đến từ điều kiện thử nghiệm?
• Phần nào có thể duy trì khi quy mô tăng?

Nhân rộng không phải là sao chép nguyên trạng

Nhiều hệ thống nghĩ rằng nhân rộng nghĩa là lấy toàn bộ cách làm của một nhóm rồi yêu cầu các nhóm khác làm giống hệt.

Nhưng mỗi khu vực có thể khác nhau về:

• Đối tượng khách hàng.
• Mức thu nhập.
• Thói quen sử dụng công nghệ.
• Khả năng di chuyển.
• Năng lực đội ngũ.
• Đối tác địa phương.
• Mức độ tin tưởng.
• Cơ sở vật chất.
• Văn hóa giao tiếp.
• Cạnh tranh trên thị trường.

Một buổi trải nghiệm thành công tại văn phòng lớn chưa chắc phù hợp với một nhóm nhỏ ở địa phương.

Một chương trình Zoom phù hợp với người quen công nghệ có thể khó áp dụng với người lớn tuổi.

Một chính sách khuyến khích mua theo số lượng có thể hoạt động với nhà phân phối nhưng không phù hợp với khách hàng cá nhân.

Nhân rộng đúng không phải sao chép tất cả.

Nó là xác định:

• Phần cốt lõi bắt buộc phải giữ.
• Phần nào được phép điều chỉnh.
• Điều kiện tối thiểu để mô hình hoạt động.
• Những giới hạn không được vượt qua.
• Cách đo lường thống nhất.

Thử nghiệm là một cách học, không phải một buổi trình diễn

Một chương trình thí điểm đôi khi được tổ chức với tâm lý:

Chúng ta cần chứng minh ý tưởng này thành công.

Khi mục tiêu là chứng minh, đội ngũ dễ:

• Chọn nhóm thuận lợi nhất.
• Bỏ qua phản hồi tiêu cực.
• Dồn quá nhiều nguồn lực.
• Chỉ báo cáo chỉ số đẹp.
• Giải thích mọi khó khăn là lỗi thực hiện.
• Không ghi nhận tác dụng phụ.
• Thay đổi tiêu chí sau khi đã thấy kết quả.

Một thử nghiệm có giá trị phải được thiết kế để học, không chỉ để tạo ra kết quả tích cực.

Nó cần giúp trả lời:

• Giả định nào đúng?
• Giả định nào sai?
• Điều kiện nào cần thiết?
• Khách hàng gặp khó ở đâu?
• Người thực hiện có làm được không?
• Chi phí thật là bao nhiêu?
• Có rủi ro nào chưa nhìn thấy?
• Mô hình cần sửa gì trước khi mở rộng?
• Có nên dừng hoàn toàn không?

Một thử nghiệm thất bại nhưng giúp phát hiện sớm một rủi ro lớn vẫn có thể là một thử nghiệm rất có giá trị.

Nó giúp hệ thống tránh thất bại ở quy mô lớn hơn.

Thử nghiệm cần bắt đầu bằng một giả định rõ

Không nên triển khai thử chỉ vì:

Ý tưởng này nghe có vẻ hay.

Cần viết rõ điều hệ thống đang muốn kiểm chứng.

Ví dụ:

Nếu người mới được hướng dẫn hoàn thành một hành động có giá trị trong bảy ngày đầu, tỷ lệ còn hoạt động sau 30 ngày sẽ tăng.

Hoặc:

Nếu khách hàng được theo dõi sau buổi trải nghiệm trong vòng 48 giờ, họ sẽ hiểu rõ bước tiếp theo hơn và ít cảm thấy bị bỏ quên.

Hoặc:

Nếu toàn bộ tài liệu sản phẩm được chuyển về một nguồn chính thức, số trường hợp tư vấn sai chính sách sẽ giảm.

Một giả định tốt cần có:

• Nhóm đối tượng.
• Thay đổi được thực hiện.
• Kết quả kỳ vọng.
• Khoảng thời gian.
• Cách đo.

Khi giả định rõ, hệ thống biết mình đang học điều gì.

Nếu không, sau thử nghiệm mọi người có thể diễn giải kết quả theo cách có lợi cho quan điểm ban đầu.

Phân biệt mục tiêu thử nghiệm và mục tiêu kinh doanh

Một chương trình thí điểm vẫn có thể tạo doanh thu.

Nhưng mục tiêu học tập cần được đặt rõ.

Ví dụ, thử nghiệm một buổi chăm sóc tóc có thể có mục tiêu:

• Kiểm tra mức độ khách hàng hiểu đúng.
• Xem quy trình tiếp nhận có thuận lợi không.
• Đánh giá thời gian mỗi khách.
• Xác định trường hợp cần chuyển chuyên gia.
• Đo khả năng chăm sóc sau buổi trải nghiệm.
• Ghi nhận mức độ phù hợp của sản phẩm.

Nếu chỉ đặt mục tiêu:

Bán được bao nhiêu bộ sản phẩm?

đội ngũ có thể tối ưu thử nghiệm cho giao dịch mà bỏ qua các bài học về:

• An toàn.
• Kỳ vọng.
• Quy trình.
• Dữ liệu.
• Chất lượng tư vấn.
• Khả năng triển khai lâu dài.

Doanh thu là một phần của kết quả.

Nhưng trong giai đoạn thử nghiệm, điều quan trọng hơn là biết mô hình có tạo ra giá trị bền vững hay không.

Bảy câu hỏi trước khi bắt đầu một thử nghiệm

1. Vấn đề thật sự cần giải quyết là gì?

Không nên thử một công cụ hoặc chương trình chỉ vì nó mới.

Cần xác định:

• Vấn đề đang xảy ra ở đâu?
• Ảnh hưởng đến ai?
• Mức độ nghiêm trọng?
• Có dữ liệu hay chỉ là cảm nhận?
• Cách hiện tại đang thiếu điều gì?

Ví dụ:

Người mới rời đi nhiều.

Câu này còn quá rộng.

Cần cụ thể hơn:

Trong 100 người tham gia gần nhất, 62 người không hoàn thành bước đầu tiên trong 14 ngày và phần lớn không biết người hỗ trợ chính là ai.

Khi vấn đề rõ, giải pháp mới có thể được kiểm chứng.

2. Giả định nào đang được thử?

Ví dụ:

Nguyên nhân người mới rời đi là vì không có một đầu mối đồng hành.

Đây mới chỉ là giả định.

Có thể nguyên nhân thật còn gồm:

• Kỳ vọng sai.
• Quyền lợi không rõ.
• Quá nhiều thông tin.
• Lịch học không phù hợp.
• Họ không còn nhu cầu.

Thử nghiệm cần tập trung kiểm tra một số giả định quan trọng, không cố giải quyết mọi thứ cùng lúc.

3. Ai nên tham gia?

Nhóm thử nghiệm cần đủ phù hợp để sử dụng mô hình, nhưng cũng cần đủ đa dạng để phản ánh thực tế.

Nếu chỉ chọn:

• Thành viên tích cực nhất.
• Khách hàng thân thiết nhất.
• Người có kỹ năng tốt nhất.
• Khu vực thuận lợi nhất.

kết quả có thể quá lạc quan.

Có thể chia người tham gia theo:

• Độ tuổi.
• Kinh nghiệm.
• Mức độ sử dụng công nghệ.
• Khu vực.
• Loại nhu cầu.
• Mức độ chủ động.
• Vai trò.

Không cần nhóm thật lớn.

Nhưng cần có lý do rõ cho cách lựa chọn.

4. Kết quả nào được xem là thành công?

Không nên chờ kết thúc rồi mới chọn chỉ số đẹp để báo cáo.

Cần xác định trước.

Ví dụ:

• Ít nhất 70% người mới hoàn thành bước đầu tiên trong bảy ngày.
• Tỷ lệ hiểu đúng quyền lợi đạt ít nhất 80%.
• Không có sự cố dữ liệu nghiêm trọng.
• Thời gian hỗ trợ trung bình không vượt quá mức hệ thống có thể duy trì.
• Ít nhất 60% người thực hiện có thể làm đúng mà không cần lãnh đạo can thiệp.
• Chi phí trên mỗi người không vượt ngân sách.

Thành công cần bao gồm cả:

• Giá trị.
• Chất lượng.
• Khả năng vận hành.
• Rủi ro.
• Hiệu quả kinh tế.

5. Dấu hiệu nào buộc phải dừng?

Trước khi thử nghiệm, cần xác định các điều kiện dừng.

Ví dụ:

• Có sự cố sức khỏe nghiêm trọng.
• Dữ liệu nhạy cảm bị sử dụng sai.
• Tỷ lệ khiếu nại vượt ngưỡng.
• Người thực hiện liên tục vượt phạm vi.
• Chi phí tăng quá mức.
• Nhà cung cấp không hỗ trợ theo cam kết.
• Công cụ làm mất dữ liệu.
• Quyền lợi khách hàng bị ảnh hưởng.

Nếu không có điều kiện dừng, đội ngũ có thể tiếp tục chỉ vì đã đầu tư nhiều công sức.

6. Ai chịu trách nhiệm?

Cần có một người sở hữu thử nghiệm.

Người này chịu trách nhiệm:

• Giữ mục tiêu.
• Theo dõi tiến độ.
• Ghi nhận thay đổi.
• Thu thập dữ liệu.
• Xử lý rủi ro.
• Báo cáo.
• Đề xuất mở rộng, điều chỉnh hoặc dừng.

Không nên để thử nghiệm trở thành hoạt động chung mà không ai thực sự chịu trách nhiệm.

7. Khi nào đánh giá?

Cần có:

• Ngày bắt đầu.
• Ngày kết thúc.
• Mốc kiểm tra giữa kỳ.
• Thời điểm đánh giá sau thử nghiệm.
• Khoảng thời gian theo dõi thêm.

Một số kết quả không xuất hiện ngay.

Ví dụ, một chương trình onboarding có thể cần theo dõi:

• Bảy ngày.
• 30 ngày.
• 60 ngày.
• 90 ngày.

Nếu chỉ đo mức độ hào hứng ngay sau buổi đầu tiên, hệ thống chưa biết chương trình có tạo ra sự duy trì hay không.

Đừng thay quá nhiều yếu tố trong cùng một thử nghiệm

Giả sử hệ thống đồng thời:

• Đổi tài liệu.
• Đổi người hướng dẫn.
• Đổi lịch.
• Đổi công cụ.
• Thêm chính sách thưởng.
• Thay cách chăm sóc.

Nếu kết quả tốt hơn, rất khó biết yếu tố nào tạo ra thay đổi.

Nếu kết quả xấu hơn, cũng không biết vấn đề nằm ở đâu.

Khi có thể, nên thay đổi một nhóm yếu tố có liên quan rõ.

Ví dụ, thử nghiệm onboarding mới có thể tập trung vào:

• Một người phụ trách chính.
• Một hành động đầu tiên.
• Ba mốc theo dõi.

Không cần đồng thời thay toàn bộ chương trình đào tạo và cơ chế quyền lợi.

Thử nghiệm càng rõ, bài học càng có giá trị.

Nhóm so sánh giúp tránh kết luận vội

Nếu có điều kiện, nên so sánh nhóm thử nghiệm với:

• Nhóm đang dùng cách cũ.
• Kết quả lịch sử.
• Một khu vực tương tự.
• Một giai đoạn trước.

Ví dụ:

Nhóm A

Thực hiện onboarding mới.

Nhóm B

Tiếp tục quy trình hiện tại.

Sau 30 ngày, so sánh:

• Tỷ lệ hoạt động.
• Mức độ hiểu quyền lợi.
• Số câu hỏi.
• Thời gian hỗ trợ.
• Khiếu nại.
• Chi phí.

Không phải mọi thử nghiệm đều cần thiết kế phức tạp.

Nhưng cần một cơ sở để biết kết quả có thật sự tốt hơn hay chỉ do:

• Thời điểm.
• Nhóm người.
• Người thực hiện.
• Chương trình khuyến mãi.
• Sự chú ý đặc biệt.

Dữ liệu định lượng và phản hồi định tính đều cần thiết

Con số cho biết điều gì đã xảy ra.

Phản hồi giúp hiểu vì sao.

Ví dụ, tỷ lệ hoàn thành onboarding tăng từ 40% lên 70%.

Đây là tín hiệu tích cực.

Nhưng cần hỏi người tham gia:

• Bước nào hữu ích nhất?
• Có phần nào gây áp lực?
• Họ có thật sự hiểu hay chỉ hoàn thành cho đủ?
• Người phụ trách có phải làm việc quá nhiều không?
• Có điều gì khiến họ không muốn tiếp tục?

Tương tự, một sản phẩm có tỷ lệ mua lại cao.

Nhưng cần biết:

• Mua lại vì phù hợp?
• Vì được giảm giá?
• Vì người bán liên tục nhắc?
• Vì khách hàng nghĩ phải dùng lâu mới hiệu quả?
• Vì họ không biết lựa chọn khác?

Kết hợp hai loại dữ liệu giúp hệ thống không đánh giá chỉ bằng bề mặt.

Không thay đổi tiêu chí thành công sau khi thấy kết quả

Giả sử thử nghiệm đặt mục tiêu:

Tăng tỷ lệ hoạt động sau 30 ngày từ 50% lên 70%.

Kết quả chỉ đạt 55%.

Nhưng số người tham dự buổi đầu tiên lại tăng.

Hệ thống có thể muốn kết luận:

Thử nghiệm vẫn thành công vì mức độ quan tâm cao.

Mức độ quan tâm có thể là một tín hiệu tốt.

Nhưng không nên thay đổi mục tiêu chính sau khi đã thấy kết quả.

Cách trung thực hơn là nói:

Thử nghiệm chưa đạt mục tiêu duy trì sau 30 ngày, nhưng ghi nhận sự cải thiện ở tỷ lệ tham dự ban đầu. Điều này cho thấy phần thu hút có hiệu quả, còn phần tạo giá trị tiếp nối cần được điều chỉnh.

Cách đánh giá này giúp hệ thống học đúng thay vì bảo vệ ý tưởng.

Ghi nhận mọi thay đổi trong quá trình thử nghiệm

Trong thực tế, thử nghiệm hiếm khi diễn ra đúng hoàn toàn theo kế hoạch.

Đội ngũ có thể:

• Thay lịch.
• Bổ sung người hỗ trợ.
• Sửa tài liệu.
• Tăng quà tặng.
• Loại một số người khỏi nhóm.
• Thay công cụ.
• Điều chỉnh lời mời.

Những thay đổi này cần được ghi lại.

Nếu không, hệ thống có thể nghĩ kết quả đến từ mô hình ban đầu trong khi thực tế đã có nhiều điều chỉnh.

Nhật ký thử nghiệm có thể ghi:

• Ngày.
• Thay đổi.
• Lý do.
• Người quyết định.
• Ảnh hưởng dự kiến.
• Kết quả sau đó.

Nhật ký giúp người khác hiểu đúng khi nhân rộng.

Không dùng nguồn lực đặc biệt mà không tính vào chi phí

Một chương trình thử nghiệm thường được lãnh đạo ưu tiên.

Có thể sử dụng:

• Nhân sự giỏi nhất.
• Địa điểm miễn phí.
• Thiết bị sẵn có.
• Thời gian ngoài giờ.
• Hỗ trợ trực tiếp từ nhà cung cấp.
• Quà tặng đặc biệt.
• Nỗ lực không được tính công.

Nếu các nguồn lực này không được tính, mô hình có thể trông hiệu quả hơn thực tế.

Khi nhân rộng, hệ thống phải trả cho:

• Nhân sự.
• Vận chuyển.
• Đào tạo.
• Công cụ.
• Chăm sóc.
• Không gian.
• Quản lý.
• Xử lý khiếu nại.
• Bảo trì.

Cần tính cả những chi phí đang được “tặng” trong giai đoạn thử nghiệm.

Một mô hình chỉ hiệu quả khi người sáng lập làm miễn phí và nhà cung cấp hỗ trợ đặc biệt chưa chắc có thể vận hành bền vững.

Đo khối lượng công việc thực tế

Một mô hình có thể tạo giá trị tốt nhưng yêu cầu quá nhiều thời gian.

Ví dụ, mỗi khách hàng cần:

• 30 phút tư vấn.
• 45 phút trải nghiệm.
• 20 phút ghi nhận.
• Ba lần theo dõi.
• Một lần trao đổi với chuyên gia.

Nếu hệ thống có 20 khách hàng, điều này có thể thực hiện được.

Nếu có 2.000 khách hàng, cần một nguồn lực rất lớn.

Trong thử nghiệm, cần đo:

• Thời gian mỗi bước.
• Số người cần tham gia.
• Số trường hợp ngoại lệ.
• Tỷ lệ phải làm lại.
• Thời gian quản lý.
• Khối lượng chăm sóc sau đó.

Câu hỏi quan trọng:

Nếu số lượng tăng gấp mười, quy trình có tiếp tục hoạt động không?

Nếu không, cần:

• Đơn giản hóa.
• Tự động hóa phần phù hợp.
• Phân nhóm khách hàng.
• Đào tạo thêm người.
• Giảm bước không tạo giá trị.
• Giới hạn quy mô.

Khả năng thực hiện bởi người bình thường quan trọng hơn người giỏi nhất

Một mô hình thường được thử bởi những người:

• Nhiệt tình.
• Có kinh nghiệm.
• Hiểu mục tiêu.
• Giao tiếp tốt.
• Được lãnh đạo lựa chọn.

Nhưng khi triển khai rộng, người thực hiện sẽ có năng lực khác nhau.

Cần thử xem:

• Người mới có hiểu tài liệu không?
• Họ có làm đúng mà không cần kèm sát không?
• Những lỗi phổ biến là gì?
• Có bước nào phụ thuộc vào trực giác cao không?
• Có cần chứng nhận hoặc đào tạo trước không?
• Điều gì không nên giao cho người chưa đủ năng lực?

Một quy trình chỉ vận hành tốt khi người giỏi nhất thực hiện chưa phải là quy trình có thể nhân rộng.

Chất lượng có giảm khi quy mô tăng không?

Khi số lượng tăng, hệ thống dễ gặp:

• Ít thời gian cho mỗi khách hàng.
• Phản hồi chậm.
• Người mới chưa được đào tạo đủ.
• Tài liệu bị hiểu sai.
• Dữ liệu phân tán.
• Tiêu chuẩn bị linh hoạt.
• Lỗi vận hành tăng.
• Khiếu nại không được xử lý kịp.

Cần xác định những tiêu chuẩn tối thiểu không được giảm.

Ví dụ:

• Mọi khách hàng đều được giải thích phạm vi.
• Dữ liệu chỉ thu thập khi cần.
• Trường hợp bất thường phải chuyển chuyên gia.
• Không dùng nội dung ngoài tài liệu chính thức.
• Mỗi khách hàng có một đầu mối.
• Khiếu nại được xác nhận trong thời gian quy định.

Tăng quy mô không được phép lấy đi những bảo vệ nền tảng.

Thử nghiệm trong lĩnh vực sức khỏe cần hàng rào chặt hơn

Với hoạt động liên quan sức khỏe, thử nghiệm không thể được hiểu là:

Cứ làm rồi xem kết quả.

Cần làm rõ:

• Hoạt động thuộc phạm vi giáo dục, trải nghiệm hay chuyên môn?
• Ai được phép thực hiện?
• Dữ liệu nào được thu thập?
• Người tham gia có hiểu giới hạn không?
• Có dấu hiệu nào buộc phải dừng?
• Khi nào chuyển cơ sở y tế hoặc người có chuyên môn?
• Sản phẩm được giới thiệu ở bước nào?
• Có gây hiểu nhầm thành chẩn đoán không?
• Có dùng nỗi sợ để bán hàng không?

Không nên thử nghiệm những hành vi có nguy cơ gây hại chỉ để xem phản ứng thị trường.

An toàn và giới hạn chuyên môn phải được xác định trước.

Người tham gia phải biết mình đang tham gia thử nghiệm khi điều đó ảnh hưởng đến họ

Không phải mọi cải tiến nội bộ đều cần thông báo như một nghiên cứu.

Nhưng nếu thử nghiệm ảnh hưởng đến:

• Quyền lợi.
• Dữ liệu.
• Giá.
• Cách chăm sóc.
• Quy trình sức khỏe.
• Việc sử dụng hình ảnh.
• Cơ chế thưởng.

người tham gia cần được biết những điều quan trọng.

Có thể nói:

Đây là chương trình thử nghiệm trong bốn tuần nhằm cải thiện quy trình chăm sóc sau trải nghiệm. Người tham gia vẫn được giữ đầy đủ quyền lợi hiện hành. Phản hồi sẽ được sử dụng để điều chỉnh chương trình trước khi triển khai rộng.

Cần làm rõ:

• Mục đích.
• Thời gian.
• Điều gì khác cách thông thường.
• Dữ liệu được dùng thế nào.
• Quyền từ chối.
• Kênh phản hồi.
• Cách xử lý vấn đề.

Không dùng nhóm thử nghiệm như nơi chịu rủi ro thay cho toàn hệ thống

Người tham gia thử nghiệm đang giúp tổ chức học.

Họ cần được bảo vệ.

Không nên:

• Bắt họ tự chịu chi phí do lỗi hệ thống.
• Giảm quyền lợi nhưng không nói rõ.
• Sử dụng dữ liệu ngoài mục đích.
• Đưa sản phẩm chưa đủ hồ sơ.
• Yêu cầu giữ im lặng về phản hồi.
• Bỏ mặc khi chương trình kết thúc.
• Thay đổi điều kiện giữa chừng mà không thông báo.

Nếu thử nghiệm tạo ra ảnh hưởng bất lợi, hệ thống phải có trách nhiệm xử lý.

Ba quyết định sau một thử nghiệm

Sau khi kết thúc, không chỉ có hai lựa chọn thành công hoặc thất bại.

Có thể có ba hướng.

1. Mở rộng

Phù hợp khi:

• Mục tiêu chính đạt.
• Rủi ro được kiểm soát.
• Chi phí có thể duy trì.
• Người khác có thể thực hiện.
• Khách hàng nhận được giá trị.
• Quy trình đủ rõ.
• Hệ thống có nguồn lực.

Mở rộng vẫn nên theo từng giai đoạn, không nhất thiết triển khai toàn bộ ngay.

2. Điều chỉnh và thử lại

Phù hợp khi:

• Ý tưởng nền tảng có tín hiệu tốt.
• Một số bước chưa hiệu quả.
• Có rủi ro có thể khắc phục.
• Dữ liệu chưa đủ.
• Nhóm thử nghiệm chưa đại diện.

Cần xác định rõ điều gì thay đổi trong lần thử tiếp theo.

3. Dừng

Phù hợp khi:

• Không tạo đủ giá trị.
• Chi phí quá cao.
• Rủi ro lớn.
• Không phù hợp khách hàng.
• Đội ngũ không thể thực hiện ổn định.
• Mô hình dựa quá nhiều vào một người.
• Giả định nền tảng không đúng.

Dừng không có nghĩa toàn bộ công sức bị lãng phí.

Hệ thống vẫn nhận được tri thức về điều không nên làm.

Không để “đã đầu tư nhiều” trở thành lý do tiếp tục

Một thử nghiệm có thể đã tiêu tốn:

• Thời gian.
• Tiền.
• Uy tín.
• Công sức.
• Quan hệ.
• Sự kỳ vọng của lãnh đạo.

Điều này khiến mọi người khó dừng.

Họ nghĩ:

Đã làm đến đây rồi, cố thêm chút nữa.

Nhưng nguồn lực đã sử dụng không thể lấy lại bằng cách tiếp tục một mô hình không phù hợp.

Quyết định phải dựa trên:

• Giá trị tương lai.
• Khả năng cải thiện.
• Chi phí tiếp tục.
• Rủi ro.
• Các lựa chọn khác.

Không dựa trên việc đã bỏ ra bao nhiêu.

Người đề xuất không nên là người duy nhất đánh giá thử nghiệm

Người xây ý tưởng thường có niềm tin mạnh vào mô hình.

Họ có thể vô thức:

• Chú ý nhiều hơn đến kết quả tích cực.
• Giải thích thất bại do người khác làm chưa đúng.
• Bỏ qua chi phí.
• Muốn bảo vệ công sức.
• Chọn phản hồi thuận lợi.

Vì vậy, quá trình đánh giá nên có thêm:

• Người vận hành.
• Người tài chính.
• Người chăm sóc khách hàng.
• Người chuyên môn.
• Người không trực tiếp xây mô hình.
• Phản hồi từ người tham gia.

Người đề xuất vẫn cần tham gia sâu.

Nhưng không nên tự mình quyết định rằng thử nghiệm đã thành công.

Không đánh giá chỉ bằng sự hào hứng

Sau một chương trình mới, người tham gia có thể:

• Rất thích.
• Chụp nhiều hình.
• Bình luận tích cực.
• Chia sẻ trên mạng xã hội.
• Nói muốn tiếp tục.
• Đánh giá cao giảng viên.

Sự hào hứng có giá trị.

Nhưng chưa chứng minh:

• Họ đã hiểu.
• Họ sẽ áp dụng.
• Họ nhận được kết quả.
• Mô hình có hiệu quả kinh tế.
• Có thể duy trì.
• Quy trình an toàn.
• Họ sẽ tiếp tục sau một tháng.

Cần đo cả:

• Hành động sau chương trình.
• Tỷ lệ quay lại.
• Tỷ lệ hoàn thành bước tiếp theo.
• Phản hồi sau thời gian sử dụng.
• Chi phí chăm sóc.
• Khiếu nại.
• Mức độ phụ thuộc vào người tổ chức.

Báo cáo thử nghiệm phải gồm cả điều chưa tốt

Một báo cáo trung thực nên có:

Mục tiêu

Thử nghiệm nhằm kiểm chứng điều gì?

Phạm vi

Ai tham gia, trong bao lâu và ở đâu?

Cách triển khai

Những bước chính.

Kết quả

Các chỉ số đã xác định trước.

Phản hồi

Người tham gia và người thực hiện nói gì?

Chi phí

Tiền, thời gian và nguồn lực.

Rủi ro và sự cố

Điều gì đã xảy ra?

Những thay đổi giữa chừng

Điều gì khác với kế hoạch ban đầu?

Bài học

Giả định nào đúng hoặc sai?

Đề xuất

Mở rộng, điều chỉnh hay dừng?

Báo cáo không nên chỉ là tài liệu quảng bá thành công.

Mở rộng theo từng vòng, không nhảy từ 10 lên 10.000

Có thể sử dụng các vòng:

Vòng 1 — Kiểm tra khả năng thực hiện

Nhóm rất nhỏ, tập trung phát hiện lỗi cơ bản.

Vòng 2 — Kiểm tra giá trị

Nhóm lớn hơn, đánh giá khách hàng có nhận được lợi ích không.

Vòng 3 — Kiểm tra vận hành

Nhiều người thực hiện hơn, xem quy trình có ổn định không.

Vòng 4 — Kiểm tra khả năng mở rộng

Áp dụng ở nhiều khu vực hoặc nhóm khác nhau.

Vòng 5 — Triển khai rộng có giám sát

Mở rộng nhưng vẫn theo dõi chặt các chỉ số.

Mỗi vòng cần có cổng quyết định:

• Tiếp tục.
• Điều chỉnh.
• Dừng.

Phần cốt lõi và phần linh hoạt

Trước khi mở rộng, cần xác định hai nhóm.

Phần cốt lõi bắt buộc

Ví dụ:

• Mục tiêu của chương trình.
• Phạm vi tư vấn.
• Nguyên tắc bảo vệ dữ liệu.
• Tiêu chuẩn an toàn.
• Nội dung không được nói.
• Mốc chăm sóc chính.
• Kênh khiếu nại.
• Cách ghi nhận kết quả.

Phần linh hoạt

Ví dụ:

• Thời gian tổ chức.
• Cách trình bày.
• Ví dụ địa phương.
• Hình thức tương tác.
• Kênh nhắc lịch.
• Cách phân nhóm.

Nếu không phân biệt, các nhóm địa phương có thể:

• Thay đổi phần cốt lõi gây rủi ro.
• Hoặc bị buộc sao chép những chi tiết không phù hợp.

Đào tạo trước khi mở rộng

Trước khi triển khai rộng, người thực hiện cần biết:

• Mục tiêu.
• Quy trình.
• Phạm vi quyền hạn.
• Điều bắt buộc.
• Điều được linh hoạt.
• Cách sử dụng công cụ.
• Cách ghi dữ liệu.
• Khi nào cần chuyển cấp.
• Cách báo sự cố.
• Nguồn tài liệu chính thức.

Không nên chỉ tổ chức một buổi giới thiệu rồi cho rằng toàn bộ đội ngũ đã đủ năng lực.

Có thể yêu cầu:

• Làm bài kiểm tra.
• Thực hành tình huống.
• Quan sát một buổi mẫu.
• Thực hiện có giám sát.
• Được xác nhận trước khi tự triển khai.

Xây khả năng hỗ trợ trước khi tăng số lượng

Mở rộng sẽ tạo thêm:

• Câu hỏi.
• Lỗi.
• Khiếu nại.
• Nhu cầu đào tạo.
• Vấn đề kỹ thuật.
• Trường hợp ngoại lệ.

Cần chuẩn bị:

• Người hỗ trợ.
• Câu hỏi thường gặp.
• Kho tài liệu.
• Kênh tiếp nhận sự cố.
• Thời gian phản hồi.
• Người chuyên môn.
• Cơ chế chuyển cấp.
• Phương án dự phòng.

Không nên mở rộng phần đầu vào nhanh hơn khả năng hỗ trợ phía sau.

Cần xác định ngưỡng năng lực

Ví dụ:

• Mỗi người chăm sóc tối đa bao nhiêu khách hàng?
• Mỗi giảng viên có thể hướng dẫn bao nhiêu học viên?
• Một điểm chạm phục vụ bao nhiêu người trong một buổi?
• Hệ thống phản hồi được bao nhiêu khiếu nại?
• Kho dữ liệu xử lý được khối lượng nào?
• Nhà cung cấp đáp ứng bao nhiêu đơn?

Khi vượt ngưỡng, chất lượng có thể giảm nhanh.

Mở rộng cần đi cùng:

• Tuyển thêm người.
• Đào tạo.
• Tự động hóa.
• Đơn giản hóa.
• Phân tầng dịch vụ.
• Giới hạn nhận thêm.

Đừng dùng tăng trưởng để che những điểm chưa hoàn thiện

Có những mô hình liên tục mở rộng vì:

• Doanh số đang tốt.
• Thị trường đang hào hứng.
• Nhiều người muốn tham gia.
• Nhà cung cấp đang khuyến mãi.

Nhưng bên trong:

• Khiếu nại chưa giải quyết.
• Tài liệu chưa chuẩn.
• Người mới chưa được chăm sóc.
• Dữ liệu chưa an toàn.
• Quy trình phụ thuộc vài người.
• Dòng tiền chưa rõ.

Mở rộng trong tình trạng đó không làm vấn đề biến mất.

Nó nhân vấn đề lên.

Nếu một quy trình có tỷ lệ lỗi 5%, với 20 trường hợp chỉ có một lỗi.

Với 20.000 trường hợp, có thể có 1.000 lỗi.

Quy mô làm những điểm yếu nhỏ trở thành rủi ro lớn.

Khi nào một mô hình đã sẵn sàng nhân rộng?

Có thể xem xét khi:

• Vấn đề được xác định rõ.
• Giá trị đối với khách hàng đã được chứng minh.
• Quy trình có thể lặp lại.
• Không phụ thuộc hoàn toàn vào một cá nhân.
• Người khác đã thực hiện thành công.
• Chi phí được tính đủ.
• Nguồn lực có thể đáp ứng.
• Rủi ro được nhận diện.
• Điều kiện dừng rõ.
• Tài liệu hoàn chỉnh.
• Người hỗ trợ đã sẵn sàng.
• Dữ liệu có thể được theo dõi.
• Quyền lợi khách hàng được bảo vệ.
• Nhà cung cấp đủ năng lực.
• Hệ thống biết phần nào bắt buộc và phần nào được linh hoạt.

Dấu hiệu chưa nên nhân rộng

• Kết quả chỉ tốt khi lãnh đạo trực tiếp có mặt.
• Chưa biết chi phí thật.
• Người thực hiện khác nhau cho kết quả quá chênh lệch.
• Tài liệu chưa thống nhất.
• Khiếu nại chưa có quy trình.
• Dữ liệu được lưu thủ công và phân tán.
• Nhà cung cấp chưa đủ khả năng đáp ứng.
• Chưa xác định nhóm khách hàng phù hợp.
• Thành công chủ yếu nhờ khuyến mãi mạnh.
• Chưa theo dõi kết quả dài hạn.
• Người tham gia không hiểu mình đang nhận giá trị gì.
• Hệ thống chưa biết khi nào phải dừng.
• Người đề xuất là người duy nhất đánh giá kết quả.
• Mọi phản hồi tiêu cực đều bị giải thích là người dùng chưa làm đúng.

Bảng kiểm trước khi mở rộng

Giá trị

• Khách hàng có nhận được giá trị thật không?
• Giá trị đó có thể quan sát hoặc đo được không?
• Có phù hợp với nhiều nhóm khác nhau không?

Vận hành

• Quy trình đã rõ chưa?
• Người khác có làm được không?
• Khối lượng tăng có được xử lý không?
• Có đủ người hỗ trợ không?

Kinh tế

• Chi phí thật đã được tính chưa?
• Mô hình có tạo phần đóng góp dương không?
• Có phụ thuộc tài trợ đặc biệt không?
• Dòng tiền có chịu được tốc độ mở rộng không?

Rủi ro

• Có nguy cơ sức khỏe, dữ liệu hoặc pháp lý không?
• Có điều kiện dừng không?
• Có người xử lý sự cố không?

Con người

• Người thực hiện đã được đào tạo chưa?
• Có người dự phòng không?
• Có phụ thuộc một cá nhân không?

Dữ liệu

• Chỉ số được theo dõi thế nào?
• Nguồn dữ liệu có đáng tin không?
• Ai chịu trách nhiệm báo cáo?

Khách hàng

• Kỳ vọng đã được nói rõ chưa?
• Có quyền từ chối không?
• Khiếu nại và hoàn trả được xử lý thế nào?
• Chăm sóc sau đó có đủ không?

Vai trò của người lãnh đạo

Người lãnh đạo thường phải cân bằng hai áp lực.

Áp lực nắm bắt cơ hội

Nếu thử nghiệm quá lâu, hệ thống có thể mất thời điểm.

Áp lực bảo vệ chất lượng

Nếu mở rộng quá nhanh, hệ thống có thể tạo ra rủi ro lớn.

Vai trò của lãnh đạo không phải luôn chọn chậm hay nhanh.

Mà là biết:

• Điều gì có thể thử nhanh?
• Điều gì cần thận trọng?
• Rủi ro nào có thể đảo ngược?
• Rủi ro nào không được phép xảy ra?
• Dữ liệu nào đủ để quyết định?
• Mức mở rộng tiếp theo nên là bao nhiêu?

Lãnh đạo cũng cần bảo vệ quyền được nói:

Thử nghiệm này chưa thành công.

Nếu đội ngũ cảm thấy mọi ý tưởng của lãnh đạo đều phải được chứng minh là đúng, dữ liệu sẽ dần mất trung thực.

Văn hóa thử nghiệm cần đi cùng văn hóa thừa nhận sai

Một hệ thống muốn đổi mới phải cho phép:

• Đặt giả định.
• Thử trong phạm vi an toàn.
• Nhận kết quả không như kỳ vọng.
• Dừng.
• Điều chỉnh.
• Ghi lại bài học.

Nhưng không được dùng “thử nghiệm” để biện minh cho:

• Thiếu chuẩn bị.
• Bỏ qua an toàn.
• Vi phạm quyền lợi.
• Dùng dữ liệu tùy tiện.
• Không chịu trách nhiệm.
• Liên tục thay đổi mà không học.

Thử nghiệm có trách nhiệm là một quá trình có mục tiêu, giới hạn và người chịu trách nhiệm.

Mẫu báo cáo thử nghiệm một trang

Vấn đề

Điều gì cần được cải thiện?

Giả định

Thay đổi nào được cho là sẽ tạo kết quả?

Phạm vi

Ai tham gia, ở đâu, trong bao lâu?

Chỉ số thành công

Đo những gì?

Kết quả

Đạt, chưa đạt hoặc vượt mục tiêu nào?

Chi phí

Tiền, thời gian và nhân lực.

Rủi ro

Sự cố hoặc tác dụng phụ.

Bài học

Điều gì đúng và điều gì sai?

Đề xuất

Mở rộng, thử lại hay dừng?

Điều kiện tiếp theo

Cần hoàn thành gì trước vòng mới?

Kết luận

Một ý tưởng tốt không tự động trở thành một hệ thống tốt.

Giữa ý tưởng và khả năng nhân rộng còn có:

• Quy trình.
• Con người.
• Chi phí.
• Công nghệ.
• Dữ liệu.
• Rủi ro.
• Khả năng hỗ trợ.
• Sự khác biệt giữa các nhóm khách hàng.
• Khả năng duy trì chất lượng khi số lượng tăng.

Thử nghiệm không làm tổ chức chậm lại. Một thử nghiệm được thiết kế đúng giúp tổ chức tránh phải trả giá lớn cho những sai lầm được nhân rộng quá sớm.

Một hệ thống trưởng thành không hỏi:

Làm thế nào để triển khai thật nhanh cho tất cả mọi người?

Nó hỏi:

Chúng ta cần học đủ điều gì trước khi đặt nhiều khách hàng, thành viên và đối tác vào mô hình này?

Thử nghiệm tốt giúp hệ thống biết:

• Điều gì thật sự tạo ra giá trị.
• Điều gì chỉ hiệu quả nhờ điều kiện đặc biệt.
• Phần nào có thể chuẩn hóa.
• Phần nào cần linh hoạt.
• Chi phí thực tế là bao nhiêu.
• Rủi ro nằm ở đâu.
• Khi nào nên mở rộng.
• Khi nào nên dừng.

Mục tiêu cuối cùng không phải biến mọi ý tưởng thành một chương trình lớn.

Mục tiêu là chọn đúng những điều xứng đáng được mở rộng và bảo đảm rằng khi quy mô tăng lên, giá trị không giảm xuống còn rủi ro lại tăng lên.

Một mô hình đáng nhân rộng không chỉ là mô hình từng tạo ra kết quả tốt trong một nhóm nhỏ.

Đó là mô hình đã chứng minh được rằng:

• Người khác cũng có thể thực hiện.
• Khách hàng khác cũng có thể nhận giá trị.
• Chi phí có thể được duy trì.
• Rủi ro có thể được kiểm soát.
• Hệ thống có thể chịu trách nhiệm khi xảy ra sai sót.
• Chất lượng vẫn được giữ khi số lượng tăng.

Khi đó, mở rộng không còn là một quyết định dựa trên sự hào hứng.

Nó trở thành một bước đi có căn cứ, có giới hạn và có trách nhiệm.