Phụ lục C. Checklist đánh giá sản phẩm EdTech

Phụ lục A giúp hỏi trước khi mua hoặc xây. Phụ lục B giúp nhìn các stakeholder. Phụ lục C là công cụ để đánh giá một sản phẩm EdTech cụ thể: một LMS, AI tutor, app luyện tập, công cụ feedback, dashboard, hệ thống phụ huynh, credential platform, kho học liệu, hoặc một tính năng mới trong sản phẩm đang có. Mục tiêu không phải chấm điểm để tạo cảm giác khách quan giả. Mục tiêu là làm rõ sản phẩm mạnh ở đâu, yếu ở đâu, rủi ro nào không được phép bỏ qua, và điều kiện nào phải có trước khi dùng thật.

Checklist này được viết theo tinh thần của quyển sách: giá trị EdTech thường nhỏ, có điều kiện, và dễ bị thổi phồng. Vì vậy, một sản phẩm không cần hoàn hảo ở mọi mục để đáng thử. Nhưng nó phải trung thực về job của mình. Một công cụ luyện tập low-stakes không cần hệ thống governance nặng như công cụ chấm thi high-stakes. Một app thông báo phụ huynh không cần learning evidence như AI tutor. Nhưng bất kỳ sản phẩm nào xử lý dữ liệu người học, ảnh hưởng đánh giá, dùng AI, hoặc đi vào workflow giáo viên đều phải trả lời nghiêm túc hơn.

Checklist này nên được dùng theo ba lớp. Lớp thứ nhất là cổng chặn: có những rủi ro đủ nghiêm trọng để chưa được triển khai, dù sản phẩm có điểm tốt ở nơi khác. Lớp thứ hai là chấm theo 12 tiêu chí: learning value, operational value, equity, workload, agency, data, AI, chi phí, bằng chứng, failure mode, exit và sustainability. Lớp thứ ba là quyết định: dừng, thử nhỏ, triển khai có điều kiện, triển khai rộng hoặc gia hạn.

1. Thang điểm

Dùng thang điểm 0-3 cho từng tiêu chí. Không dùng số thập phân. Nếu phân vân giữa hai điểm, chọn điểm thấp hơn và ghi điều kiện cần để nâng điểm. Việc chấm thấp không phải để “bắt lỗi” sản phẩm. Nó giúp biết còn thiếu gì trước khi đưa sản phẩm vào đời sống học tập thật.

| Điểm | Ý nghĩa | Cách hiểu | |---|---|---| | 0 | Không đạt | Không có bằng chứng, không rõ thiết kế, rủi ro không được quản, hoặc câu trả lời chỉ là marketing. | | 1 | Yếu | Có ý tưởng đúng nhưng thiếu triển khai, thiếu bằng chứng, thiếu bảo vệ, hoặc phụ thuộc quá nhiều vào người dùng tự xoay. | | 2 | Đạt có điều kiện | Có giá trị và rủi ro được quản ở mức chấp nhận được, nhưng cần điều kiện triển khai, giới hạn phạm vi hoặc theo dõi thêm. | | 3 | Mạnh | Giá trị rõ, phù hợp bối cảnh, rủi ro được quản, có bằng chứng hoặc dữ liệu triển khai tốt, có khả năng duy trì và rời đi. |

Không nên cộng điểm một cách máy móc rồi ra quyết định. Một sản phẩm có tổng điểm cao nhưng điểm 0 ở privacy hoặc exit vẫn có thể không được dùng. Một sản phẩm có tổng điểm trung bình nhưng dùng trong phạm vi low-stakes, dữ liệu ít, job rõ, có thể đáng pilot. Điểm số là cách tổ chức thảo luận, không phải thay thế phán đoán.

2. Cổng chặn trước khi chấm điểm

Trước khi chấm 12 tiêu chí, hãy kiểm tra các cổng chặn. Nếu sản phẩm vướng một cổng chặn, không triển khai rộng. Có thể dừng, yêu cầu sửa, hoặc chỉ thử trong sandbox không có dữ liệu thật.

| Cổng chặn | Câu hỏi | Nếu câu trả lời xấu | |---|---|---| | Vấn đề không rõ | Sản phẩm giải vấn đề giáo dục/vận hành cụ thể nào? | Dừng. Không mua công nghệ chỉ vì tính năng hấp dẫn. | | Dữ liệu người học mơ hồ | Sản phẩm thu gì, dùng làm gì, lưu bao lâu, chia sẻ với ai? | Không triển khai với dữ liệu thật. | | AI high-risk không có human review | AI có ảnh hưởng điểm, phân luồng, kỷ luật, cơ hội, wellbeing không? | Không dùng cho quyết định high-stakes. | | Không có quyền khiếu nại | Người học/giáo viên có thể sửa lỗi hoặc yêu cầu human review không? | Không dùng cho đánh giá hoặc nhãn hóa. | | Không có export/exit | Dữ liệu, nội dung, credential có xuất được không? | Không ký dài hạn, không đưa vào hạ tầng cốt lõi. | | Workload giáo viên không được tính | Công cụ thêm việc gì và giảm việc gì? | Không rollout. Phải pilot workload trước. | | Accessibility bị bỏ qua | Người khuyết tật hoặc người dùng thiết bị yếu có dùng được không? | Không triển khai bắt buộc cho toàn bộ người học. | | Vendor né trách nhiệm | Khi hỏi privacy, security, AI, export, vendor chỉ trả lời chung chung? | Dừng đàm phán hoặc yêu cầu tài liệu chính thức. |

Cổng chặn giúp tránh tình trạng một sản phẩm được điểm cao ở tính năng nhưng thất bại ở quyền. Trong giáo dục, có những lỗi không được bù bằng giao diện đẹp.

3. Bảng chấm tổng hợp

| Tiêu chí | Điểm 0 | Điểm 1 | Điểm 2 | Điểm 3 | |---|---|---|---|---| | Learning value | Không rõ học được gì | Có lời hứa nhưng đo bằng usage | Có giá trị học tập rõ, cần pilot | Có bằng chứng học tập và điều kiện triển khai rõ | | Operational value | Không giảm việc thật | Giảm một việc, thêm nhiều việc khác | Cải thiện vận hành có điều kiện | Giảm ma sát rõ và bền trong workflow thật | | Equity effect | Bỏ qua nhóm yếu thế | Có access nhưng thiếu hỗ trợ | Có thiết kế cho một số nhóm rủi ro | Equity được thiết kế, đo và hỗ trợ | | Teacher workload | Không tính workload | Tăng việc hoặc mơ hồ | Có giảm việc nhưng cần đo thêm | Giảm/tái phân bổ workload rõ, giáo viên có agency | | Student agency | Người học bị quản lý nhiều hơn | Có lựa chọn hình thức | Có hỗ trợ tự chủ có giới hạn | Tăng tự chủ, metacognition và quyền phản hồi | | Data minimization | Thu nhiều, mục đích mơ hồ | Có policy nhưng mặc định rộng | Thu dữ liệu tương đối phù hợp | Dữ liệu tối thiểu, mục đích rõ, retention/xóa/export tốt | | AI governance | AI mơ hồ, tự tin quá mức | Có cảnh báo chung | Có human review và giới hạn cơ bản | Job AI rõ, audit, escalation, fallback và age-appropriate | | Total cost of ownership | Chỉ tính license | Tính thêm vài chi phí | Tính training/support/integration | Tính đầy đủ workload, renewal, migration, exit, support | | Evidence quality | Testimonial/demo | Usage/case study yếu | Pilot hoặc evidence phù hợp bối cảnh | Evidence đa chiều, có giới hạn và đo tác dụng phụ | | Failure mode | Không biết khi nào hỏng | Có support chung | Có quy trình xử lý lỗi chính | Có failure criteria, incident response, rollback, communication | | Exit cost | Không export được | Export thô, khó dùng | Export được nhưng chưa thử | Exit drill, format dùng được, migration support, xóa dữ liệu | | Environmental sustainability | Không tính thiết bị/năng lượng | Nhắc chung chung | Có tính thiết bị/cloud cơ bản | Có vòng đời thiết bị, bảo trì, e-waste, cloud/AI cost |

Sau khi chấm, ghi thêm một câu cho mỗi tiêu chí: “điểm này dựa trên bằng chứng nào?”. Nếu không có bằng chứng mà vẫn cho điểm cao, điểm đó là cảm giác.

4. Tiêu chí 1: Learning value

Learning value hỏi sản phẩm làm gì cho học tập, không phải làm gì cho hoạt động. Một sản phẩm có thể có video đẹp, AI nói mượt, quiz nhiều, badge hấp dẫn, nhưng nếu không rõ người học hiểu sâu hơn ở đâu, learning value vẫn yếu. Hãy mô tả chính xác cơ chế học tập: retrieval practice, feedback, revision, worked examples, spaced practice, explanation, transfer, collaboration, metacognition, accessibility hay teacher mediation.

Chấm 0 nếu sản phẩm chỉ nói “tăng engagement”, “cá nhân hóa” hoặc “học vui hơn” mà không chỉ ra học tập cải thiện thế nào. Chấm 1 nếu có logic học tập nhưng đo bằng usage, completion hoặc time-on-task. Chấm 2 nếu có giá trị học tập rõ và có kế hoạch pilot đo học tập trong bối cảnh thật. Chấm 3 nếu có evidence phù hợp, biết rõ tác dụng với nhóm nào, điều kiện nào, và không thổi phồng sang mọi bối cảnh.

Câu hỏi kiểm chứng: người học sau khi dùng có giải thích tốt hơn, sửa bài tốt hơn, nhớ lâu hơn, chuyển giao sang nhiệm vụ mới tốt hơn, hay chỉ làm nhiều hoạt động hơn? Giáo viên có thấy dữ liệu từ sản phẩm giúp họ dạy tốt hơn không? Sản phẩm có tạo cơ hội revision không? Feedback có đúng thời điểm không? Nếu AI trả lời, nó có buộc người học nghĩ hay chỉ đưa đáp án?

Red flag: sản phẩm dùng “engagement” như bằng chứng học tập. Green flag: sản phẩm nói rõ nó không đo được toàn bộ học tập và chỉ nhận trách nhiệm ở một phần cụ thể.

5. Tiêu chí 2: Operational value

Operational value là giá trị vận hành: giảm thất lạc thông tin, giảm nhập liệu trùng, gom bài nộp, tự động hóa lịch, cập nhật phụ huynh, làm sạch dữ liệu lớp, hỗ trợ báo cáo, giảm support thủ công. Đây là giá trị thật, dù ít lãng mạn. Một tổ chức giáo dục có thể tốt hơn chỉ vì bớt rối.

Chấm 0 nếu sản phẩm không cải thiện workflow thật hoặc chỉ tạo thêm một nơi phải nhập liệu. Chấm 1 nếu nó giảm một việc nhưng thêm nhiều việc khác. Chấm 2 nếu nó giải quyết một bottleneck vận hành rõ nhưng cần tích hợp/support để không tạo gánh nặng. Chấm 3 nếu nó giảm ma sát ổn định trong điều kiện thật, có owner, support, integration và không làm giáo viên/học sinh rối hơn.

Câu hỏi kiểm chứng: công cụ thay thế quy trình cũ hay chỉ thêm lên trên? Có giảm số lần đăng nhập, số file, số kênh thông báo, số lần copy điểm không? Dữ liệu có chảy tự động đúng không? Nếu công cụ chết một ngày, trường có vận hành được không? Có giúp giáo viên và đội vận hành bớt việc thật không?

Red flag: sản phẩm tạo dashboard mới nhưng không giảm bước làm cũ. Green flag: sản phẩm có thể chỉ làm một việc vận hành nhỏ nhưng làm rất chắc và có export tốt.

6. Tiêu chí 3: Equity effect

Equity effect hỏi ai được lợi và ai bị bỏ lại. Sản phẩm không công bằng chỉ vì nó online, miễn phí hoặc “ai cũng có tài khoản”. Công bằng cần xét thiết bị, mạng, điện, ngôn ngữ, khuyết tật, kỹ năng tự học, thời gian, hỗ trợ gia đình, bối cảnh địa phương và chi phí ẩn.

Chấm 0 nếu sản phẩm không xét nhóm yếu thế. Chấm 1 nếu có access rộng nhưng thiếu hỗ trợ, thiếu offline, thiếu accessibility hoặc chỉ dùng tốt trong điều kiện đẹp. Chấm 2 nếu có thiết kế cho một số nhóm rủi ro nhưng cần đo adoption và outcome theo nhóm. Chấm 3 nếu equity được thiết kế, đo và hỗ trợ: low-bandwidth, mobile, offline khi cần, đa ngôn ngữ, accessibility, hỗ trợ giáo viên/phụ huynh, và dữ liệu nhóm không dùng.

Câu hỏi kiểm chứng: sản phẩm chạy trên máy cũ không? Mạng yếu thì sao? Người học khuyết tật dùng được không? Phụ huynh ít rành công nghệ hiểu được không? Người học yếu kỹ năng tự học có cấu trúc hỗ trợ không? Có đo ai không dùng không, hay chỉ đo người dùng tích cực?

Red flag: “Chỉ cần có internet là học được.” Green flag: sản phẩm có thiết kế cho người dùng ít thuận lợi nhất, không chỉ người dùng lý tưởng.

7. Tiêu chí 4: Teacher workload

Teacher workload là nơi nhiều lời hứa EdTech vỡ. Giảm tải không phải sản phẩm làm một việc nhanh hơn trong demo. Giảm tải là tổng công việc của giáo viên giảm hoặc được chuyển sang việc có ý nghĩa hơn trong tuần làm việc thật. Một công cụ AI tạo bài nhanh nhưng giáo viên phải sửa nhiều, kiểm nguồn, điều chỉnh rubric, giải thích cho học sinh, thì chưa chắc giảm tải.

Chấm 0 nếu sản phẩm không tính workload giáo viên. Chấm 1 nếu có khả năng tăng việc hoặc chỉ giảm việc cho admin. Chấm 2 nếu có dấu hiệu giảm việc nhưng cần đo trong pilot. Chấm 3 nếu workload được đo trước/sau, giáo viên có quyền chỉnh, bỏ qua, phản hồi, và tổ chức giảm việc cũ tương ứng.

Câu hỏi kiểm chứng: mất bao lâu để giáo viên học công cụ? Tạo lớp? Giao bài? Xem dữ liệu? Sửa lỗi? Liên lạc phụ huynh? Duyệt AI output? Khi sản phẩm gửi cảnh báo, giáo viên có thời gian can thiệp không? Nếu sản phẩm tạo dữ liệu, ai đọc và hành động? Có dữ liệu nào dùng để đánh giá giáo viên không?

Red flag: vendor nói “giáo viên chỉ cần vài phút” nhưng chưa quan sát trong lớp thật. Green flag: sản phẩm thừa nhận phần việc mới và có thiết kế giảm việc cũ.

8. Tiêu chí 5: Student agency

Student agency hỏi người học có thêm quyền học hay chỉ bị điều khiển tốt hơn. Một learning path tự động có thể giúp người học không lạc, nhưng cũng có thể làm họ chỉ đi theo máy. Một AI tutor có thể hỗ trợ, nhưng cũng có thể làm hộ. Một dashboard tiến độ có thể giúp tự quản, nhưng cũng có thể tạo áp lực.

Chấm 0 nếu sản phẩm biến người học thành đối tượng bị giao, đo và nhắc. Chấm 1 nếu có một số lựa chọn bề mặt nhưng không tăng tự chủ thật. Chấm 2 nếu sản phẩm hỗ trợ tự chủ có giới hạn: người học xem tiến độ, nhận feedback, chọn nhịp trong phạm vi an toàn. Chấm 3 nếu sản phẩm giúp người học hiểu cách mình học, tự kiểm tra, sửa lỗi, giải thích, phản biện AI/dữ liệu, và có quyền phản hồi hoặc khiếu nại.

Câu hỏi kiểm chứng: người học có biết mục tiêu hoạt động không? Có hiểu feedback không? Có được sửa không? Có thể xem và giải thích dữ liệu của mình không? Có quyền hỏi lại khi bị hệ thống gắn cờ không? AI có khuyến khích tự giải thích trước khi trả lời không? Công cụ có rút dần hỗ trợ không?

Red flag: sản phẩm gọi mọi điều hướng tự động là “cá nhân hóa”. Green flag: sản phẩm làm người học mạnh hơn cả khi không còn dùng sản phẩm.

9. Tiêu chí 6: Data minimization

Data minimization hỏi sản phẩm có thể làm đúng job với ít dữ liệu hơn không. Trong EdTech, dữ liệu không chỉ là asset. Nó là dấu vết của người học, giáo viên và gia đình. Thu nhiều hơn không tự động làm sản phẩm thông minh hơn theo nghĩa giáo dục. Nó có thể chỉ làm rủi ro lớn hơn.

Chấm 0 nếu sản phẩm thu rộng, mục đích mơ hồ, retention không rõ. Chấm 1 nếu có privacy policy nhưng mặc định vẫn thu nhiều, chia sẻ rộng hoặc dùng dữ liệu cho secondary purpose. Chấm 2 nếu dữ liệu tương đối phù hợp job, có phân quyền và retention cơ bản. Chấm 3 nếu dữ liệu tối thiểu, mục đích rõ, quyền truy cập hẹp, retention/xóa/export rõ, không dùng dữ liệu học sinh cho AI training mặc định, và có privacy by default.

Câu hỏi kiểm chứng: từng trường dữ liệu phục vụ hành động nào? Có thể dùng dữ liệu tổng hợp không? Có thể xử lý cục bộ không? Có thể không lưu hội thoại AI không? Có thể rút ngắn retention không? Ai xem được dữ liệu? Có log truy cập không? Có deletion certificate khi kết thúc hợp đồng không?

Red flag: “Chúng tôi cần dữ liệu để cải thiện sản phẩm” nhưng không nói cải thiện gì. Green flag: vendor chủ động đề xuất cấu hình ít dữ liệu hơn.

10. Tiêu chí 7: AI governance

AI governance chỉ áp dụng nếu sản phẩm có AI, nhưng hiện nay AI có thể ẩn trong nhiều tính năng: feedback, recommendation, chatbot, analytics, scoring, summarization, support, content generation. Đừng hỏi chung “AI có tốt không?”. Hãy hỏi AI giữ vai trò gì và ảnh hưởng quyết định nào.

Chấm 0 nếu AI mơ hồ, output tự tin, không rõ dữ liệu, không có human review. Chấm 1 nếu chỉ có cảnh báo chung “AI có thể sai”. Chấm 2 nếu có giới hạn cơ bản, human review, không dùng cho high-stakes, và dữ liệu tương đối rõ. Chấm 3 nếu có job description cho AI, phạm vi cấm, audit, escalation, fallback, age-appropriate design, incident reporting, model/update transparency và quyền dừng.

Câu hỏi kiểm chứng: AI là người nháp, người gợi ý, người phản hồi hay người quyết định? AI có ảnh hưởng điểm/cơ hội/kỷ luật/wellbeing không? Có biết nói không chắc không? Có gọi người khi vượt phạm vi không? Có log vừa đủ không? Có thể tắt AI không? Model đổi có thông báo không? Có đánh giá bias/hallucination trong bối cảnh thật không?

Red flag: AI nói như người có thẩm quyền nhưng không có trách nhiệm. Green flag: AI được thiết kế để khiêm tốn, có giới hạn và giúp con người phán đoán tốt hơn.

11. Tiêu chí 8: Total cost of ownership

Total cost of ownership không chỉ là license. Nó gồm training, onboarding, migration, integration, support, thiết bị, mạng, data cleanup, security review, legal review, downtime, renewal, AI token/API cost, monitoring, evaluation, incident response, exit và thời gian con người. Một sản phẩm rẻ có thể rất đắt nếu nó làm tổ chức rối hơn.

Chấm 0 nếu chỉ tính giá mua. Chấm 1 nếu tính thêm vài chi phí nhưng bỏ qua workload và exit. Chấm 2 nếu tính training/support/integration/renewal cơ bản. Chấm 3 nếu tính đầy đủ chi phí trực tiếp, chi phí thời gian, chi phí dữ liệu, chi phí rời đi, chi phí duy trì sau pilot, và có ngân sách dài hạn.

Câu hỏi kiểm chứng: năm hai giá thế nào? Có phí API/export/AI/storage/support không? Ai training người mới? Ai support phụ huynh? Có cần thiết bị mới không? Có tăng workload giáo viên không? Nếu vendor tăng giá, trường có phương án không? Nếu ngừng dùng, migration tốn bao nhiêu?

Red flag: “Miễn phí” nhưng thu dữ liệu, có upsell, hoặc tạo lock-in. Green flag: giá và chi phí vận hành được nói rõ trước khi ký.

12. Tiêu chí 9: Evidence quality

Evidence quality hỏi bằng chứng có phù hợp với quyết định không. Không phải mọi sản phẩm cần bằng chứng nghiên cứu lớn, nhưng sản phẩm càng ảnh hưởng học tập, quyền, dữ liệu và high-stakes thì bằng chứng càng phải mạnh. Testimonial không phải evidence. Usage không phải learning. Case study đẹp không phải implementation trong bối cảnh của bạn.

Chấm 0 nếu chỉ có demo và lời hứa. Chấm 1 nếu có testimonial, usage hoặc case study yếu. Chấm 2 nếu có pilot, nghiên cứu phù hợp hoặc dữ liệu triển khai trong bối cảnh gần. Chấm 3 nếu evidence đa chiều: learning, workload, adoption, equity, privacy incidents, support burden, sustainability, và có nêu giới hạn.

Câu hỏi kiểm chứng: bằng chứng đến từ ai? Có độc lập không? Có so sánh với baseline không? Có đo nhóm không dùng không? Có đo tác dụng phụ không? Có phù hợp tuổi, môn, ngôn ngữ, hạ tầng, loại trường không? Sản phẩm hiện tại có giống sản phẩm trong nghiên cứu không, hay đã đổi nhiều?

Red flag: “Có nghiên cứu nói công nghệ kiểu này hiệu quả” nhưng không liên quan sản phẩm/bối cảnh cụ thể. Green flag: vendor nói rõ bằng chứng của họ chưa trả lời được điều gì.

13. Tiêu chí 10: Failure mode

Failure mode hỏi sản phẩm hỏng như thế nào và ai bị ảnh hưởng. Một sản phẩm giáo dục không được giả định mình luôn chạy đúng. Server lỗi, dữ liệu sai, AI hallucination, dashboard nhầm, phụ huynh nhận thông báo sai, học sinh bị gắn cờ sai, giáo viên mất quyền truy cập, vendor đổi điều khoản, tất cả đều có thể xảy ra. Trưởng thành là có khả năng hỏng ít hại.

Chấm 0 nếu không có mô tả lỗi và quy trình xử lý. Chấm 1 nếu chỉ có support chung. Chấm 2 nếu có quy trình xử lý lỗi chính, backup và communication cơ bản. Chấm 3 nếu có failure criteria, incident response, rollback, human override, escalation, thông báo người bị ảnh hưởng, postmortem và cải tiến.

Câu hỏi kiểm chứng: nếu AI feedback sai, ai sửa? Nếu dữ liệu lớp sai, ai có quyền sửa? Nếu gắn cờ gian lận sai, học sinh khiếu nại thế nào? Nếu hệ thống down trong kỳ thi, fallback là gì? Nếu phụ huynh nhận thông báo sai, ai phục hồi quan hệ? Nếu vendor đổi model, trường có được báo trước không?

Red flag: “Chưa từng xảy ra lỗi lớn.” Green flag: sản phẩm có kịch bản lỗi được diễn tập.

14. Tiêu chí 11: Exit cost

Exit cost là chi phí rời sản phẩm. Nó gồm export dữ liệu, migration, training lại, mất tài liệu, mất credential, mất tích hợp, downtime, phí egress, phí hỗ trợ, và mất niềm tin. Một sản phẩm càng đi sâu vào workflow và dữ liệu, exit càng quan trọng.

Chấm 0 nếu không xuất được dữ liệu hoặc điều khoản mơ hồ. Chấm 1 nếu export thô nhưng thiếu metadata, khó import, có phí hoặc vendor kiểm soát quá chặt. Chấm 2 nếu export được nhưng chưa thử, migration cần điều kiện. Chấm 3 nếu có exit drill, định dạng dùng được, metadata đủ, migration support, xóa dữ liệu, deletion certificate, và hợp đồng quy định thời hạn.

Câu hỏi kiểm chứng: export gồm gì? User, lớp, nội dung, bài làm, điểm, feedback, credential, logs cần thiết, rubric, file đính kèm, metadata? Có machine-readable không? Có import sang hệ khác được không? Nội dung giáo viên tạo thuộc ai? AI artifacts thuộc ai? Nếu vendor đóng cửa thì sao?

Red flag: vendor nói “chưa khách nào cần rời đi”. Green flag: vendor có tài liệu migration trước khi bạn hỏi.

15. Tiêu chí 12: Environmental sustainability

Environmental sustainability thường bị bỏ qua trong EdTech, nhưng thiết bị, cloud, AI compute, pin, màn hình, e-waste, vận chuyển, bảo trì đều có chi phí môi trường và ngân sách. Một chương trình thiết bị không có vòng đời sẽ tạo rác thải. Một AI feature dùng nhiều compute cho giá trị học tập mỏng có thể là lãng phí. Một nền tảng buộc nâng cấp thiết bị có thể đẩy chi phí sang trường và gia đình.

Chấm 0 nếu không tính thiết bị, điện, cloud hoặc e-waste. Chấm 1 nếu nhắc sustainability chung chung. Chấm 2 nếu có tính chi phí thiết bị/cloud cơ bản và hỗ trợ máy cũ. Chấm 3 nếu có chiến lược vòng đời: thiết bị bền, sửa được, dùng lại được, e-waste, low-bandwidth, tối ưu compute, offline khi hợp lý, và không dùng AI nặng cho việc nhẹ.

Câu hỏi kiểm chứng: sản phẩm chạy trên thiết bị hiện có không? Có buộc nâng cấp không? Có dùng được offline/low-bandwidth không? AI có cần gọi model lớn cho mọi thao tác không? Dữ liệu lưu vô hạn có làm tăng chi phí cloud không? Có kế hoạch thu hồi, sửa chữa, tái sử dụng hoặc xử lý thiết bị không?

Red flag: “Chúng tôi là phần mềm nên không có tác động môi trường.” Green flag: sản phẩm thiết kế nhẹ, bền, dùng được trên hạ tầng thật.

16. Diễn giải kết quả

Sau khi chấm, hãy phân loại sản phẩm theo hai trục: giá trị và rủi ro. Giá trị gồm learning value, operational value, equity và teacher workload. Rủi ro gồm data, AI, failure, exit, TCO và sustainability. Một sản phẩm có giá trị cao nhưng rủi ro cao cần triển khai có điều kiện, không rollout nhanh. Một sản phẩm giá trị thấp nhưng rủi ro thấp có thể không đáng thời gian. Một sản phẩm giá trị vừa phải nhưng rủi ro thấp, job rõ, có thể đáng pilot. Một sản phẩm giá trị cao, rủi ro được quản tốt, có thể triển khai rộng hơn.

| Kết quả | Diễn giải | Quyết định gợi ý | |---|---|---| | Có cổng chặn nghiêm trọng | Rủi ro chưa được quản dù sản phẩm hấp dẫn | Dừng hoặc sandbox không dữ liệu thật | | Nhiều điểm 0-1 ở dữ liệu/AI/exit | Quyền và trách nhiệm chưa đủ | Không ký dài hạn; yêu cầu sửa trước | | Điểm learning thấp, operational cao | Công cụ vận hành, không nên bán như công cụ học tập | Dùng nếu giải bottleneck thật, đừng thổi phồng | | Điểm learning cao, workload thấp | Có nguy cơ giá trị chỉ nằm trong demo | Pilot với giáo viên thật và đo workload | | Điểm equity thấp | Có thể làm bất bình đẳng sâu hơn | Giới hạn phạm vi, thêm hỗ trợ hoặc dừng | | Điểm exit thấp | Lock-in tương lai | Không đưa vào hạ tầng cốt lõi | | Đa số điểm 2 | Có thể đáng thử nhưng cần điều kiện | Pilot hoặc triển khai có điều kiện | | Nhiều điểm 3, không có cổng chặn | Sản phẩm trưởng thành hơn mức trung bình | Có thể triển khai rộng, vẫn cần review định kỳ |

Không có điểm nào là vĩnh viễn. Một sản phẩm có thể được nâng điểm nếu vendor thêm export, giảm dữ liệu, cải thiện accessibility, viết tài liệu AI, đo workload, hoặc hoàn thành pilot tốt. Một sản phẩm cũng có thể bị hạ điểm nếu bật tính năng AI mới, đổi điều khoản dữ liệu, tăng giá, giảm support, hoặc mở rộng sang high-stakes.

17. Checklist nhanh trước khi ký hợp đồng

Trước khi ký, hãy đảm bảo có câu trả lời bằng văn bản cho các điểm sau: vấn đề cụ thể, phạm vi triển khai, dữ liệu thu và mục đích, DPA hoặc điều khoản xử lý dữ liệu, quyền truy cập theo vai trò, retention và deletion, AI role nếu có, human review nếu high-risk, accessibility, security, integration standards, export format, migration support, support SLA, pricing/renewal, quyền audit, incident response, termination clause, deletion certificate và điều kiện vendor không được dùng dữ liệu người học cho mục đích thứ cấp nếu chưa được phép rõ ràng.

Nếu vendor không trả lời bằng văn bản, coi như chưa có. Nếu câu trả lời nằm trong slide bán hàng nhưng không vào hợp đồng hoặc tài liệu kỹ thuật, coi như chưa có. Nếu export được hứa miệng nhưng chưa thử, coi như chưa có. Nếu AI được gọi là “chỉ hỗ trợ” nhưng workflow cho phép output đi thẳng tới người học hoặc quyết định, coi như high-risk hơn lời nói.

18. Checklist nhanh trước khi pilot

Trước khi pilot, hãy xác định baseline, nhóm người dùng, nhóm không dùng nếu có, mục tiêu học tập/vận hành, dữ liệu sẽ thu trong pilot, điều kiện thành công, điều kiện dừng, người hỗ trợ, kênh báo lỗi, cách đo workload, cách lấy phản hồi người học/giáo viên/phụ huynh, và cách xử lý dữ liệu sau pilot. Pilot không nên dùng dữ liệu nhạy cảm hoặc high-stakes nếu governance chưa sẵn.

Pilot nên có một câu hỏi chính, không phải mười lời hứa. Ví dụ: “Công cụ này có giúp giáo viên giảm thời gian phản hồi bài viết mà vẫn tăng chất lượng revision không?” tốt hơn “Công cụ này có chuyển đổi dạy học không?”. Một pilot hẹp nhưng rõ tạo kiến thức tốt hơn một pilot rộng nhưng mơ hồ.

19. Checklist nhanh trước khi gia hạn

Gia hạn là thời điểm tốt nhất để hỏi lại. Sản phẩm có còn giải đúng vấn đề ban đầu không? Usage có đi cùng learning hoặc operational value không? Workload giáo viên thay đổi thế nào? Nhóm nào không dùng? Có sự cố dữ liệu không? Vendor có đổi điều khoản, giá, AI, API, support không? Export đã thử chưa? Có công cụ khác tốt hơn không? Nếu bỏ sản phẩm, tổ chức mất gì và giữ được gì?

Đừng gia hạn chỉ vì đã quen. Thói quen là một dạng lock-in mềm. Nếu sản phẩm vẫn đáng dùng, gia hạn bằng lý do rõ. Nếu không, hãy lên exit plan trước khi sự phụ thuộc sâu hơn.

20. Mẫu phiếu chấm một sản phẩm

Tên sản phẩm: Mục đích chính: Nhóm người dùng: Mức rủi ro: Thấp / Trung bình / Cao / High-stakes AI có tham gia: Không / Có low-stakes / Có high-risk Dữ liệu nhạy cảm: Không / Có Phạm vi đề xuất: Sandbox / Pilot / Triển khai có điều kiện / Triển khai rộng / Gia hạn

| Tiêu chí | Điểm 0-3 | Bằng chứng dùng để chấm | Điều kiện cần trước khi triển khai | |---|---:|---|---| | Learning value | | | | | Operational value | | | | | Equity effect | | | | | Teacher workload | | | | | Student agency | | | | | Data minimization | | | | | AI governance | | | | | Total cost of ownership | | | | | Evidence quality | | | | | Failure mode | | | | | Exit cost | | | | | Environmental sustainability | | | |

Cổng chặn phát hiện: Ba rủi ro lớn nhất: Ba giá trị đáng giữ nhất: Điều kiện dừng: Quyết định cuối: Dừng / Sandbox / Pilot / Triển khai có điều kiện / Triển khai rộng / Gia hạn / Không gia hạn

21. Dấu hiệu đỏ

Sản phẩm tự nhận “cá nhân hóa toàn diện” nhưng không nói rõ logic. Sản phẩm dùng AI trong feedback hoặc assessment nhưng không có human review. Sản phẩm thu dữ liệu hành vi dày nhưng không có mục đích giáo dục cụ thể. Sản phẩm không export được dữ liệu học tập. Vendor không nói rõ dữ liệu có dùng để huấn luyện AI không. Dashboard tạo nhãn rủi ro nhưng không có quy trình hỗ trợ. Sản phẩm tăng notification nhưng không đo wellbeing. Pilot chỉ dùng với lớp đẹp. Evidence toàn testimonial. Giá rẻ năm đầu nhưng renewal mơ hồ. API có nhưng tính phí hoặc thiếu dữ liệu quan trọng. Accessibility nằm trong roadmap xa. Vendor nói sản phẩm phù hợp mọi trường, mọi tuổi, mọi môn.

Dấu hiệu đỏ không có nghĩa phải hủy ngay, nhưng nghĩa là không được triển khai rộng trước khi sửa. Một tổ chức trưởng thành biết dừng đúng lúc. Dừng một sản phẩm chưa đủ trách nhiệm là tiết kiệm niềm tin cho các đổi mới sau.

22. Dấu hiệu xanh

Sản phẩm mô tả job hẹp và rõ. Nó nói được trường hợp không nên dùng. Nó có bằng chứng phù hợp nhưng không thổi phồng. Nó thu ít dữ liệu. Nó có export thật. Nó hỗ trợ chuẩn tích hợp. Nó có accessibility cơ bản. Nó đo workload giáo viên. Nó có AI job description nếu dùng AI. Nó cho người học quyền hiểu và khiếu nại khi bị ảnh hưởng. Nó có incident response. Nó có pricing minh bạch. Nó có migration support. Nó thiết kế notification tiết chế. Nó giúp giáo viên có thêm phán đoán, không chỉ thêm dashboard. Nó làm người học mạnh hơn sau khi rời công cụ.

Dấu hiệu xanh quan trọng nhất là sản phẩm không cần hứa quá lớn để đáng dùng. Nó biết mình làm gì, biết mình không làm gì, và để tổ chức giữ quyền quyết định.

Ghi chú nguồn nền cho phụ lục

Phụ lục này tổng hợp từ các chương về feedback, accessibility, dữ liệu sớm, giáo viên, phụ huynh, screen time, đánh giá, quyền riêng tư, AI tutor, AI theo tuổi, tự động hóa, bất bình đẳng, sustainability, bằng chứng, pilot, total cost of ownership, khung quyết định công bằng, EdTech nhỏ/vừa đủ/địa phương, AI governance, hạ tầng công và quyền rời đi. Khi dùng checklist trong quyết định thật, nên đọc cùng Phụ lục A để đặt câu hỏi trước quyết định và Phụ lục B để kiểm tra phân phối lợi ích/rủi ro giữa các stakeholder.