ຄູ່ມືການອອກແບບ PoC ສຳລັບການນຳໃຊ້ AI — ຂັ້ນຕອນການປະຕິບັດຕົວຈິງເພື່ອໃຫ້ທຸລະກິດ B2B ໃນໄທຕັດສິນໃຈເປີດຕົວ ຫຼື Launch ຢ່າງເປັນທາງການ

PoC (Proof of Concept, ການພິສູດແນວຄວາມຄິດ) ຂອງການນຳ AI ມາໃຊ້ ແມ່ນຂະບວນການກວດສອບໃນຂະໜາດນ້ອຍ ແລະ ໄລຍະເວລາສັ້ນໆ ເພື່ອເບິ່ງວ່າເທັກໂນໂລຊີ AI ໃໝ່ໆຈະສາມາດເຮັດວຽກໃນການປະຕິບັດງານຈິງໄດ້ຫຼືບໍ່. ຫຼາຍບໍລິສັດໄດ້ດຳເນີນການ PoC ແຕ່ກໍມີຫຼາຍກໍລະນີທີ່ບໍ່ສາມາດນຳໄປສູ່ການປະຕິບັດງານຈິງໄດ້ ເຖິງວ່າຈະກວດສອບສຳເລັດແລ້ວ ກໍຄືສະພາວະທີ່ເອີ້ນວ່າ "PoC ຄວາມອິດເມື່ອຍ (PoC 疲れ)".

ບົດຄວາມນີ້ມີຈຸດປະສົງເພື່ອໃຫ້ຜູ້ຮັບຜິດຊອບການຂັບເຄື່ອນ DX, ພະແນກລະບົບຂໍ້ມູນຂ່າວສານ ແລະ ຜູ້ຮັບຜິດຊອບການວາງແຜນທຸລະກິດຂອງບໍລິສັດທີ່ດຳເນີນທຸລະກິດ B2B ໃນປະເທດໄທ ໄດ້ເຂົ້າໃຈເຖິງຮູບແບບທົ່ວໄປທີ່ເຮັດໃຫ້ PoC ກາຍເປັນພຽງຮູບແບບ, ພ້ອມທັງອະທິບາຍ 4 ຂັ້ນຕອນໃນການອອກແບບ PoC ທີ່ນຳໄປສູ່ການຕັດສິນໃຈນຳໃຊ້ຈິງ (ການກຳນົດຂອບເຂດ, ເກນຄວາມສຳເລັດ, ສະຖາປັດຕະຍະກຳ, ແລະ ປະຕູ GO/NO-GO). ເມື່ອອ່ານຈົບ, ທ່ານຈະສາມາດລະບຸສາເຫດທີ່ເຮັດໃຫ້ PoC ຂອງບໍລິສັດທ່ານບໍ່ນຳໄປສູ່ການນຳໃຊ້ຈິງ ແລະ ມີຄວາມຊັດເຈນກ່ຽວກັບຫົວຂໍ້ທີ່ຄວນບັນຈຸລົງໃນເອກະສານອອກແບບ PoC ຄັ້ງຕໍ່ໄປ.

PoC ບໍ່ແມ່ນບ່ອນສຳລັບກວດສອບພຽງແຕ່ວ່າ "ເຮັດວຽກໄດ້ ຫຼື ບໍ່ໄດ້" ເທົ່ານັ້ນ, ແຕ່ເປັນບ່ອນສຳລັບເກັບກຳຂໍ້ມູນທີ່ຈຳເປັນເພື່ອຕັດສິນໃຈໃນການນຳໄປໃຊ້ງານຈິງຢ່າງຕັ້ງໃຈ. ຖ້າເລີ່ມຕົ້ນ PoC ໂດຍບໍ່ມີການແບ່ງປັນເງື່ອນໄຂເບື້ອງຕົ້ນນີ້, ມັນກໍມັກຈະຈົບລົງພຽງແຕ່ໃນຂັ້ນຕອນກອງປະຊຸມລາຍງານຜົນ ແລະ ຈະຫຍຸ້ງຍາກໃນການນຳໄປສູ່ການເປັນຜະລິດຕະພັນຈິງ (Productization). ໃນພາກນີ້, ພວກເຮົາຈະມາຈັດລະບຽບຄວາມແຕກຕ່າງຂອງບົດບາດລະຫວ່າງ PoC, ໂຄງການນຳຮ່ອງ (Pilot), ແລະ ການດຳເນີນງານຈິງ, ລວມເຖິງຮູບແບບທົ່ວໄປ 4 ຢ່າງທີ່ເຮັດໃຫ້ເກີດການເຮັດວຽກແບບຜັກຊີໂຮຍໜ້າ.

PoC, Pilot, ແລະ ການນຳໃຊ້ງານຈິງ (Production) ແມ່ນໄລຍະທີ່ແຕກຕ່າງກັນ ເຊິ່ງມີຈຸດປະສົງ, ຂອບເຂດ ແລະ ເປົ້າໝາຍການປະເມີນທີ່ແຕກຕ່າງກັນ. ການເອີ້ນທຸກຢ່າງລວມກັນວ່າ "PoC" ໂດຍບໍ່ແຍກແຍະ ຈະນຳໄປສູ່ການຕັ້ງຄວາມຄາດຫວັງທີ່ຜິດພາດ ແລະ ເຮັດໃຫ້ເກີດຄວາມຄາດເຄື່ອນໃນມາດຕະຖານການປະເມີນ.

ຫາກພະຍາຍາມຕັດສິນໃຈວ່າ "ສາມາດນຳໄປໃຊ້ໃນການປະຕິບັດງານຈິງໄດ້ຫຼືບໍ່" ຕັ້ງແຕ່ຂັ້ນຕອນ PoC ຈະເຮັດໃຫ້ໄລຍະເວລາໃນການກວດສອບຍາວນານຂຶ້ນ ແລະ ຂອບເຂດຂອງວຽກຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ. ໃນຂັ້ນຕອນ PoC ຄວນຈຳກັດການຕັດສິນໃຈພຽງແຕ່ວ່າ "ມີຄຸນຄ່າພໍທີ່ຈະພັດທະນາຕໍ່ໄປສູ່ການນຳໃຊ້ງານຈິງຫຼືບໍ່" ກໍພຽງພໍແລ້ວ, ສ່ວນການກວດສອບຄວາມເໝາະສົມກັບວຽກງານໃນຂັ້ນສຸດທ້າຍນັ້ນ ຄວນເຮັດໃນໄລຍະ Pilot ເຊິ່ງເປັນວິທີທີ່ເໝາະສົມກັບຄວາມເປັນຈິງຫຼາຍກວ່າ.

ຮູບແບບທົ່ວໄປທີ່ PoC ຈົບລົງດ້ວຍການ "ເຮັດວຽກໄດ້ແລ້ວ" ສາມາດສະຫຼຸບໄດ້ເປັນ 4 ປະການດັ່ງນີ້:

1. ມາດຕະຖານ ຫຼື Specification ໃນການປະເມີນຜົນບໍ່ໄດ້ຖືກບັນທຶກໄວ້ລ່ວງໜ້າ — ເປົ້າໝາຍກາຍເປັນພຽງ "ການທົດລອງໃຊ້ເພື່ອໃຫ້ຮູ້ສຶກເຖິງການເຮັດວຽກ" ໂດຍບໍ່ມີການຕົກລົງກັນກ່ຽວກັບມາດຕະຖານທາງປະລິມານ ແລະ ຄຸນນະພາບ. ໃນຊ່ວງທ້າຍຈຶ່ງເກີດການໂຕ້ວາທີກັນວ່າ "ແບບນີ້ສາມາດເອີ້ນວ່າຄວາມສຳເລັດໄດ້ແລ້ວຫຼືບໍ່".
2. ຂອບເຂດວຽກບໍ່ໄດ້ຖືກຈຳກັດໄວ້ຢ່າງຕັ້ງໃຈ — ພະຍາຍາມຈັດການກັບບັນຫາທີ່ກວ້າງຂວາງໃນ PoC ເຊັ່ນ "ການປ່ຽນລະບົບຕອບຮັບຄຳຖາມຂອງທັງບໍລິສັດໃຫ້ເປັນ AI" ເຮັດໃຫ້ໝົດເວລາໄປກັບການກຽມຂໍ້ມູນເທົ່ານັ້ນ.
3. ຂາດເຈົ້າຂອງວຽກງານ (Business Owner) ແລະ ມີພຽງພະແນກ IT ເທົ່ານັ້ນທີ່ເຄື່ອນໄຫວ — ເຖິງວ່າການກວດສອບຈະສຳເລັດ ແຕ່ຝ່າຍປະຕິບັດງານບໍ່ເຂົ້າໃຈວ່າ "ວຽກຂອງຕົນເອງຈະປ່ຽນແປງໄປແນວໃດ" ເຮັດໃຫ້ການສ້າງຄວາມເຫັນດີເຫັນພ້ອມໃນການສະເໜີເພື່ອເປີດຕົວ ຫຼື Launch ໃຊ້ງານຈິງຕ້ອງໃຊ້ເວລາດົນ.
4. ເງື່ອນໄຂໃນການເປີດຕົວ ຫຼື Launch ໃຊ້ງານຈິງບໍ່ໄດ້ຖືກກຳນົດໄວ້ຕັ້ງແຕ່ເລີ່ມຕົ້ນ PoC — ຫຼັງຈາກ PoC ສິ້ນສຸດລົງ ບໍ່ມີໃຜສາມາດຕອບໄດ້ວ່າ "ຕ້ອງເຮັດແນວໃດຕໍ່ໄປເພື່ອໃຫ້ກ້າວໄປສູ່ການໃຊ້ງານຈິງ". ສຸດທ້າຍກໍຈົບລົງພຽງແຕ່ການຂຽນບົດລາຍງານ.

ສິ່ງເຫຼົ່ານີ້ບໍ່ແມ່ນບັນຫາສະເພາະຂອງແຕ່ລະໜ້າວຽກ ແຕ່ເປັນຂໍ້ບົກຜ່ອງທາງໂຄງສ້າງຂອງການອອກແບບທີ່ກຳນົດໃຫ້ PoC ເປັນພຽງ "ໄລຍະການກວດສອບ" ເທົ່ານັ້ນ.

ການສະແດງ PoC ດ້ວຍການໂຊວ່າ "ລະບົບເຮັດວຽກໄດ້" ໃນສະໄລ້ການລາຍງານ ແລ້ວຈົບລົງດ້ວຍສຽງຕົບມືຈາກຜູ້ເຂົ້າຮ່ວມ — ນີ້ແມ່ນພາບທີ່ເຫັນໄດ້ເລື້ອຍໆໃນໜ້າວຽກການຂັບເຄື່ອນ AI ທັງໃນໄທ ແລະ ຍີ່ປຸ່ນ. ເຖິງວ່າການທີ່ລະບົບເຮັດວຽກໄດ້ຈະເປັນຄວາມຈິງ, ແຕ່ມັນບໍ່ໄດ້ເປັນຫຼັກຖານພຽງພໍທີ່ຈະຢືນຢັນໄດ້ວ່າລະບົບນັ້ນຈະສາມາດຂະຫຍາຍຕົວ (Scale) ໄປສູ່ການນຳໃຊ້ຈິງໄດ້.

ສາເຫດທີ່ເຮັດໃຫ້ບໍ່ສາມາດຂະຫຍາຍຕົວໄດ້ນັ້ນ ບໍ່ໄດ້ມາຈາກຕົວເທັກໂນໂລຊີ ແຕ່ມາຈາກສ່ວນຂອງການເຊື່ອມຕໍ່.

• ຊ່ອງວ່າງລະຫວ່າງສະພາບແວດລ້ອມການທົດສອບ ແລະ ສະພາບແວດລ້ອມການນຳໃຊ້ຈິງ — ໃນ PoC ຈະໃຊ້ຂໍ້ມູນການປະເມີນຜົນທີ່ສະອາດ, ແຕ່ໃນການນຳໃຊ້ຈິງຈະມີສິ່ງລົບກວນ, ຂໍ້ມູນທີ່ຂາດຫາຍ ຫຼື ຮູບແບບຂໍ້ມູນທີ່ບໍ່ໄດ້ຄາດຄິດປົນເຂົ້າມາ. ຄວາມແມ່ນຍຳຈະຫຼຸດລົງຢ່າງຫຼວງຫຼາຍພຽງແຕ່ປ່ຽນສະພາບແວດລ້ອມເທົ່ານັ້ນ.
• ການຂາດຕົວແທນຂອງຂໍ້ມູນ — ຂໍ້ມູນການທົດສອບ 100-500 ລາຍການທີ່ໃຊ້ໃນ PoC ບໍ່ສາມາດເປັນຕົວແທນໃຫ້ກັບຂໍ້ມູນການນຳໃຊ້ຈິງທີ່ມີຫຼາຍໝື່ນລາຍການຕໍ່ປີໄດ້. ເຮັດໃຫ້ບໍ່ເຫັນກໍລະນີພິເສດ (Edge case) ໃນຂັ້ນຕອນການທົດສອບ.
• ການບໍ່ພິຈາລະນາຕົ້ນທຶນການດຳເນີນງານ ແລະ ການກຳກັບດູແລ — ຕົ້ນທຶນການປະມວນຜົນຂອງ Model, ຄວາມຖີ່ໃນການຝຶກຝົນໃໝ່ (Re-training), ລະບົບການຕິດຕາມກວດກາ, ການຈັດເກັບ Log, ການຈັດການຂໍ້ມູນສ່ວນບຸກຄົນທີ່ສອດຄ່ອງກັບ PDPA ແລະ ອົງປະກອບອື່ນໆທີ່ບໍ່ໄດ້ຖືກເນັ້ນໃນ PoC ຈະກາຍເປັນພາລະເມື່ອຄິດໄລ່ຕົ້ນທຶນໃນການນຳໃຊ້ຈິງ.
• ຄວາມບໍ່ສົມດຸນຂອງຄວາມຄາດຫວັງລະຫວ່າງຜູ້ມີສ່ວນກ່ຽວຂ້ອງ — ຝ່າຍບໍລິຫານຄາດຫວັງວ່າ "ຈະນຳໃຊ້ທົ່ວອົງກອນໄດ້ທັນທີ", ຝ່າຍ IT ເຫັນວ່າ "ຈຳເປັນຕ້ອງສ້າງໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ໃໝ່", ສ່ວນຝ່າຍປະຕິບັດງານເຫັນວ່າ "ບໍ່ເໝາະສົມກັບວຽກຂອງຕົນເອງ", ເຊິ່ງຄວາມຄາດຫວັງທີ່ແຕກຕ່າງກັນເຫຼົ່ານີ້ຈະຍັງຄົງຄ້າງຢູ່ໂດຍບໍ່ໄດ້ຖືກບັນທຶກໄວ້ໃນບົດລາຍງານ.

ຖ້າບໍ່ໄດ້ແກ້ໄຂບັນຫາໃນສ່ວນຂອງການເຊື່ອມຕໍ່ເຫຼົ່ານີ້ຕັ້ງແຕ່ຂັ້ນຕອນການອອກແບບ PoC, ຄວາມສຳເລັດໃນການທົດສອບກໍຈະບໍ່ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ການນຳໃຊ້ຈິງໄດ້ໂດຍກົງ.

ກ່ອນທີ່ຈະຕັດສິນໃຈວ່າຈະກວດສອບຫຍັງໃນ PoC, ໃຫ້ຄິດໄລ່ຍ້ອນກັບເຖິງຂໍ້ມູນທີ່ຈຳເປັນເມື່ອກ້າວໄປສູ່ການນຳໃຊ້ຈິງ. ໂດຍການອອກແບບ 3 ຈຸດສຳຄັນ ຄື: ການເຫັນດີເຫັນພ້ອມຂອງຜູ້ມີສ່ວນກ່ຽວຂ້ອງ, ຈຸດເຊື່ອມຕໍ່ກັບການດຳເນີນງານຈິງ, ແລະ ຕັກກະຍະການປະເມີນຜົນ ກ່ອນເລີ່ມ PoC, ຜົນການກວດສອບຈະສາມາດເຊື່ອມຕໍ່ເຂົ້າກັບການຕັດສິນໃຈໃນການນຳໃຊ້ຈິງໄດ້ໂດຍກົງ.

ກຳນົດຜູ້ຕັດສິນໃຈ ແລະ ຜູ້ມີສ່ວນກ່ຽວຂ້ອງຂອງ PoC ຕັ້ງແຕ່ເລີ່ມຕົ້ນ ແລະ ບັນທຶກສິ່ງທີ່ແຕ່ລະຄົນຄາດຫວັງຈາກ PoC ໄວ້ເປັນລາຍລັກອັກສອນ.

ຜູ້ມີສ່ວນກ່ຽວຂ້ອງຫຼັກ ແລະ ຄວາມສົນໃຈທີ່ມີຕໍ່ PoC ສາມາດແບ່ງອອກໄດ້ດັ່ງນີ້:

• ຜູ້ບໍລິຫານລະດັບສູງ ແລະ ຫົວໜ້າພະແນກທຸລະກິດ: ການຕັດສິນໃຈລົງທຶນ (ROI, ການປຽບທຽບກັບຄູ່ແຂ່ງ, ຄວາມສ່ຽງ). ຕ້ອງການຜົນລວມທາງປະລິມານທີ່ຫຍໍ້ສັ້ນ.
• ພະແນກປະຕິບັດງານ ແລະ ຜູ້ໃຊ້ງານໜ້າວຽກ: ວຽກງານຂອງພວກເຂົາຈະປ່ຽນແປງໄປແນວໃດ. ຕ້ອງການໂອກາດໃນການທົດລອງໃຊ້ງານຜ່ານ Use case ຕົວຈິງ.
• ພະແນກ IT ແລະ ລະບົບຂໍ້ມູນຂ່າວສານ: ຄວາມສອດຄ່ອງຂອງສະຖາປັດຕະຍະກຳ, ພາລະໃນການດຳເນີນງານ, ຜົນກະທົບຕໍ່ລະບົບທີ່ມີຢູ່. ຕ້ອງການລາຍລະອຽດທາງດ້ານເຕັກນິກ.
• ພະແນກກົດໝາຍ ແລະ ການປະຕິບັດຕາມກົດລະບຽບ (Compliance): ການຈັດການຂໍ້ມູນ, PDPA ຂອງໄທ ຫຼື ກົດໝາຍປົກປ້ອງຂໍ້ມູນສ່ວນບຸກຄົນຂອງຍີ່ປຸ່ນ, ແລະ ຄວາມສອດຄ່ອງກັບກົດລະບຽບຂອງອຸດສາຫະກຳ.
• ພະແນກການເງິນ: ການປະເມີນຕົ້ນທຶນລວມເມື່ອເປີດໃຊ້ງານຈິງ, TCO, ແລະ ຄວາມໂປ່ງໃສຂອງໂຄງສ້າງຕົ້ນທຶນ.

ບັນທຶກຄວາມຄາດຫວັງເຫຼົ່ານີ້ໄວ້ກ່ອນເລີ່ມຕົ້ນ PoC ແລະ ຄິດຍ້ອນກັບວ່າໃນການປະຊຸມສະຫຼຸບຜົນງານສຸດທ້າຍນັ້ນ "ຈະສະແດງຫຍັງ, ໃຫ້ໃຜ ແລະ ລະດັບຄວາມລະອຽດເທົ່າໃດ". ການກຳນົດໂຄງຮ່າງຂອງການປະຊຸມສະຫຼຸບຜົນງານໄວ້ລ່ວງໜ້າ ຈະເຮັດໃຫ້ຂໍ້ມູນທີ່ຄວນເກັບກຳໃນລະຫວ່າງການກວດສອບມີຄວາມຊັດເຈນຂຶ້ນ.

PoC ບໍ່ແມ່ນການທົດລອງທີ່ຈົບໃນຕົວເອງ ແຕ່ເປັນຂັ້ນຕອນກ່ອນການນຳໃຊ້ງານຈິງ. ໃນຂະນະທີ່ອອກແບບ PoC ໃຫ້ກຳນົດຈຸດເຊື່ອມຕໍ່ຕໍ່ໄປນີ້ໄວ້ລ່ວງໜ້າ:

• ລະບົບປາຍທາງທີ່ລວມຂໍ້ມູນ (Integration destination system) — ລະຫວ່າງລະບົບຫຼັກ (Core system), CRM, Groupware, ຫຼື ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຂໍ້ມູນ, ໃນການນຳໃຊ້ງານຈິງຈະເຊື່ອມຕໍ່ກັບລະບົບໃດ. ເຖິງແມ່ນວ່າໃນ PoC ຈະຫຍໍ້ຂັ້ນຕອນໂດຍໃຊ້ວິທີໄຟລ໌ກາງ (Intermediate file) ກໍຕາມ, ແຕ່ຕ້ອງກຳນົດທິດທາງການອອກແບບສຳລັບການນຳໃຊ້ງານຈິງໄວ້.
• ເສັ້ນທາງຂອງຜູ້ໃຊ້ (User flow) — ໃນການນຳໃຊ້ງານຈິງ ຜູ້ໃຊ້ຈະເຂົ້າເຖິງຟັງຊັນ AI ຈາກໜ້າຈໍໃດ ຫຼື ແອັບພລິເຄຊັນໃດ. ຈະສ້າງ UI ສະເພາະຂຶ້ນມາ ຫຼື ຈະລວມ ຫຼື Merge ເຂົ້າກັບເຄື່ອງມືທີ່ມີຢູ່ແລ້ວ.
• ການໄຫຼວຽນຂອງຂໍ້ມູນ (Data flow) — ເປັນການຄາດຄະເນແບບ Real-time ຫຼື ການປະມວນຜົນແບບ Batch, ໄລຍະເວລາການຈັດເກັບຂໍ້ມູນ ແລະ ຄວາມຖີ່ໃນການເຂົ້າເຖິງຂໍ້ມູນເປັນແນວໃດ.
• ຄວາມປອດໄພ ແລະ ຂໍ້ກຳນົດການກວດສອບ (Security & Audit requirements) — ການເຊື່ອມຕໍ່ເພື່ອການຢືນຢັນຕົວຕົນ, ການຄວບຄຸມການເຂົ້າເຖິງ, ການຈັດເກັບ Log, ແລະ ຫຼັກຖານການກວດສອບ. ໂດຍສະເພາະໃນກໍລະນີທີ່ຈັດການກັບຂໍ້ມູນທາງທຸລະກິດໃນປະເທດໄທ, ຈຳເປັນຕ້ອງມີການອອກແບບເພື່ອຮອງຮັບການຂໍຄວາມຍິນຍອມ ແລະ ການຈັດການສິດທິຂອງເຈົ້າຂອງຂໍ້ມູນຕາມ PDPA.
• ຂໍ້ກຳນົດດ້ານຫຼາຍພາສາ (Multilingual requirements) — ໃນກໍລະນີທີ່ຕ້ອງຈັດການກັບພາສາໄທ, ພາສາຍີ່ປຸ່ນ ແລະ ພາສາອັງກິດປົນກັນ, ເຖິງແມ່ນວ່າໃນ PoC ຈະເລືອກພຽງພາສາດຽວກໍຕາມ, ແຕ່ຈຳເປັນຕ້ອງປະເມີນຕົ້ນທຶນໃນການຮອງຮັບຫຼາຍພາສາເມື່ອນຳໄປໃຊ້ງານຈິງ.

ສິ່ງເຫຼົ່ານີ້ບໍ່ຈຳເປັນຕ້ອງຈັດຕັ້ງປະຕິບັດທັງໝົດໃນ PoC. ໃຫ້ເຮັດລາຍການ "ສິ່ງທີ່ຈຳເປັນຕ້ອງມີໃນການນຳໃຊ້ງານຈິງ" ໄວ້ ເພື່ອໃຫ້ເຫັນປະລິມານວຽກທີ່ຕ້ອງເຮັດເພີ່ມເຕີມເມື່ອ PoC ປະສົບຜົນສຳເລັດ.

ເຫດຜົນໃນການປະເມີນຜົນຄວນຖືກສ້າງໂຄງຮ່າງຂັ້ນຕອນໄວ້ຢ່າງໜ້ອຍກ່ອນເລີ່ມຕົ້ນ PoC. ຖ້າຫາກມາດຕະຖານການປະເມີນປ່ຽນແປງໃນລະຫວ່າງທາງ, ຜົນລັດຈະກາຍເປັນການໂຕ້ວາທີກ່ຽວກັບ "ຄວາມເໝາະສົມຂອງມາດຕະຖານການປະເມີນ" ແທນທີ່ຈະເປັນ "ຄວາມເໝາະສົມຂອງ PoC".

ສິ່ງທີ່ຄວນກຽມໄວ້ຢ່າງໜ້ອຍມີ 4 ຢ່າງດັ່ງນີ້:

• ຊຸດຂໍ້ມູນການປະເມີນ (Evaluation Dataset) — ບັນທຶກເອກະສານວ່າຂໍ້ມູນມີຈຳນວນເທົ່າໃດ, ໃນໄລຍະເວລາໃດ ແລະ ໃຜເປັນຜູ້ຕິດປ້າຍກຳກັບ (Label). ໃຫ້ແຍກລະຫວ່າງຕົວຢ່າງທີ່ມີຄວາມເປັນຕົວແທນ (Representative sample) ກັບຕົວຢ່າງທີ່ທ້າທາຍ (Challenge sample) ເຊິ່ງລວມເອົາກໍລະນີພິເສດ (Edge case) ໄວ້ໂດຍເຈດຕະນາ.
• ການກຳນົດຜົນລັດທີ່ຄາດຫວັງ (Definition of Expected Output) — ໃນກໍລະນີທີ່ "ຄຳຕອບທີ່ຖືກຕ້ອງ" ສາມາດກຳນົດໄດ້ຢ່າງຊັດເຈນ ໃຫ້ໃຊ້ຂໍ້ມູນຄຳຕອບທີ່ຖືກຕ້ອງ, ຖ້າມີກົດລະບຽບທີ່ຕົກລົງກັນໄວ້ໃຫ້ໃຊ້ເອກະສານກົດລະບຽບ, ແລະ ຖ້າຈຳເປັນຕ້ອງມີການຕັດສິນໂດຍມະນຸດ ໃຫ້ກຳນົດມາດຕະຖານການຄັດເລືອກຜູ້ກວດສອບ (Reviewer).
• ຕົວຊີ້ວັດ (Metrics) — ນອກເໜືອໄປຈາກຕົວຊີ້ວັດມາດຕະຖານຂອງການຮຽນຮູ້ຂອງເຄື່ອງ (Machine Learning) ເຊັ່ນ: ຄວາມຖືກຕ້ອງ (Precision), ອັດຕາການກວດພົບ (Recall) ແລະ F1, ໃຫ້ໃຊ້ຕົວຊີ້ວັດທາງທຸລະກິດ (ອັດຕາການຫຼຸດຜ່ອນເວລາໃນການປະມວນຜົນ, ອັດຕາການແຊກແຊງຂອງມະນຸດ, ຄວາມເພິ່ງພໍໃຈຂອງຜູ້ໃຊ້) ຄວບຄູ່ກັນໄປ.
• ຂະບວນການຕັດສິນ (Judgment Process) — ກຳນົດວ່າຈະປະເມີນເມື່ອໃດ, ໃຜເປັນຜູ້ປະເມີນ ແລະ ໃຊ້ເກນໃດໃນການປະເມີນ. ໃນກໍລະນີທີ່ມີຜູ້ປະເມີນຫຼາຍຄົນ ໃຫ້ດຳເນີນການປັບຄວາມເຂົ້າໃຈກ່ຽວກັບການຕັດສິນໃຫ້ກົງກັນລ່ວງໜ້າ.

ການກຳນົດເຫດຜົນໃນການປະເມີນຜົນພາຍຫຼັງຈະສ້າງແຮງຈູງໃຈໃຫ້ເລືອກມາດຕະຖານທີ່ເອື້ອອຳນວຍຕໍ່ຜົນລັດ. ນັ້ນຖືເປັນປັດໄຈສຳຄັນທີ່ສຸດທີ່ເຮັດໃຫ້ຄວາມໜ້າເຊື່ອຖືຂອງ PoC ຫຼຸດລົງ.

ຄວາມສຳເລັດ ຫຼື ຄວາມລົ້ມເຫຼວຂອງ PoC ແມ່ນຖືກກຳນົດໂດຍການກຳນົດໂຈດໃນຕອນເລີ່ມຕົ້ນເຖິງ 7 ສ່ວນ. ສຳລັບໂຈດທີ່ຍັງບໍ່ຈະແຈ້ງນັ້ນ, ບໍ່ວ່າຈະນຳໃຊ້ເທັກໂນໂລຊີ AI ແບບໃດກໍຕາມ ກໍຈະສົ່ງຜົນໃຫ້ເກີດຜົນລັບທີ່ວ່າ "ລະບົບເຮັດວຽກໄດ້ ແຕ່ບໍ່ຮູ້ວ່າຈະມີຄຸນຄ່າແນວໃດ". ໃນ Step 1, ຄວນກຳນົດໂຈດທາງທຸລະກິດໃຫ້ມີຄວາມລະອຽດສູງ ແລະ ຕັ້ງໃຈຈຳກັດຂອບເຂດໃຫ້ແຄບລົງ ເພື່ອໃຫ້ສາມາດຕັດສິນໃຈໄດ້ພາຍໃນໄລຍະເວລາຂອງ PoC.

ການກຳນົດບັນຫາທາງທຸລະກິດແບບກວ້າງໆ ເຊັ່ນ "ເພີ່ມປະສິດທິພາບການຂາຍ" ຈະເຮັດໃຫ້ບໍ່ຮູ້ວ່າຄວນຈະກວດສອບ (Verify) ສິ່ງໃດໃນ PoC. ຮູບແບບທົ່ວໄປໃນການເພີ່ມຄວາມລະອຽດ (Resolution) ມີດັ່ງນີ້:

• NG: ຕ້ອງການເພີ່ມປະສິດທິພາບການຂາຍ — ເປົ້າໝາຍການກວດສອບກວ້າງເກີນໄປ ຈົນບໍ່ສາມາດຕັດສິນໄດ້ວ່າເປັນວຽກທີ່ AI ສາມາດປັບປຸງໄດ້ຫຼືບໍ່.
• OK: ຕ້ອງການຫຼຸດເວລາການເກັບກຳຂໍ້ມູນເບື້ອງຕົ້ນສຳລັບການເຮັດໃບສະເໜີລາຄາ (ການລວບລວມຂໍ້ມູນໂຄງການເກົ່າ, ລາຄາ, ສິນຄ້າຄົງຄັງ) ທີ່ປົກກະຕິໃຊ້ເວລາສະເລ່ຍ 45 ນາທີ ໃຫ້ເຫຼືອພາຍໃນ 10 ນາທີ — ເປົ້າໝາຍວຽກ, ຄ່າປັດຈຸບັນ ແລະ ຄ່າເປົ້າໝາຍມີຄວາມຊັດເຈນ ແລະ ສາມາດວັດແທກຂອບເຂດການປັບປຸງໄດ້.

ເພື່ອເພີ່ມຄວາມລະອຽດ, ໃຫ້ແຍກວຽກງານປັດຈຸບັນອອກເປັນໜ່ວຍຍ່ອຍໆ. ໃຫ້ສັງເກດການເຮັດວຽກ ຫຼື ສຳພາດໜ້າວຽກຈິງເປັນເວລາ 1-2 ອາທິດ ເພື່ອໃຫ້ເຂົ້າໃຈວ່າໃຜ, ເຮັດຫຍັງ, ເວລາໃດ ແລະ ໃຊ້ເວລາເທົ່າໃດ. ຜົນຈາກການສັງເກດອາດຈະໄດ້ຂໍ້ສະຫຼຸບວ່າ ການປ່ຽນແປງຂະບວນການເຮັດວຽກ (Workflow) ມີປະສິດທິຜົນກວ່າການໃຊ້ AI ປັບປຸງ. ໃນກໍລະນີດັ່ງກ່າວ, ໃຫ້ມີທາງເລືອກໃນການດຳເນີນການປະຕິຮູບວຽກງານໂດຍບໍ່ຕ້ອງເຮັດ PoC.

ການລົງທຶນເວລາໃນການເພີ່ມຄວາມລະອຽດໃຫ້ກັບບັນຫາທາງທຸລະກິດ ຄືການກະກຽມເບື້ອງຕົ້ນທີ່ມີປະສິດທິຜົນທີ່ສຸດ ເພື່ອຍົກລະດັບອັດຕາຄວາມສຳເລັດຂອງ PoC ໂດຍລວມ.

ຄວາມຢາກທີ່ຈະຂະຫຍາຍຂອບເຂດວຽກງານນັ້ນມີຢູ່ສະເໝີ ເຊັ່ນ: "ມີຄຳຮ້ອງຂໍມາຈາກພະແນກອື່ນນຳ ຈຶ່ງຢາກທົດສອບໄປພ້ອມກັນ", "ຮອງຮັບຫຼາຍພາສາຈະເປັນປະໂຫຍດໃນອະນາຄົດ", ຫຼື "Vendor ແນະນຳຟີເຈີເພີ່ມເຕີມ" ເປັນຕົ້ນ. ການເຮັດ PoC ທີ່ກວ້າງເກີນໄປຈະບໍ່ສາມາດເຫັນຜົນໄດ້ໃນໄລຍະສັ້ນ ແລະ ເຮັດໃຫ້ການຕັດສິນໃຈຖືກເລື່ອນອອກໄປ.

ກຳນົດມາດຕະຖານໃນການຈຳກັດຂອບເຂດຂອງ PoC ໄວ້ດັ່ງນີ້:

• ໄລຍະເວລາ: 6-8 ອາທິດ. ຖ້າຫາກໃຊ້ເວລາຫຼາຍກວ່ານັ້ນ ຄວນຖືວ່າເປັນຂະໜາດຂອງ Pilot ບໍ່ແມ່ນ PoC.
• ວຽກງານເປົ້າໝາຍ: ຈຳກັດໃຫ້ເຫຼືອພຽງ 1 ຢ່າງ. ຖ້າຫາກຕ້ອງຈັດການຫຼາຍວຽກງານ ໃຫ້ແຍກເຮັດ PoC ແຕ່ລະຢ່າງຕໍ່ເນື່ອງກັນ.
• ຜູ້ໃຊ້ເປົ້າໝາຍ: 5-10 ຄົນ. ພຽງແຕ່ມີຜູ້ໃຊ້ທີ່ມີບົດບາດ ແລະ ລະດັບທັກສະທີ່ເປັນຕົວແທນກໍພຽງພໍແລ້ວ.
• ຂໍ້ມູນເປົ້າໝາຍ: ຈຳກັດໄລຍະເວລາ ເຊັ່ນ: ຂໍ້ມູນຍ້ອນຫຼັງ 3 ເດືອນ. ສ່ວນກໍລະນີພິເສດ (Edge case) ໃຫ້ຮວບຮວມໄວ້ປະເມີນຕ່າງຫາກ.
• ພາສາ ແລະ ພື້ນທີ່ເປົ້າໝາຍ: 1 ພາສາ ແລະ 1 ສູນກາງ. ການຮອງຮັບຫຼາຍພາສາ ຫຼື ຫຼາຍພື້ນທີ່ ໃຫ້ແຍກອອກໄປໄວ້ໃນການປະເມີນລາຄາສຳລັບການນຳໃຊ້ຈິງ.

ສຳລັບຄຳໂຕ້ແຍ້ງທີ່ວ່າ "ຖ້າຈຳກັດຂອບເຂດເກີນໄປ ຈະບໍ່ສາມາດປະເມີນຜົນໄດ້ຢ່າງແທ້ຈິງ" ໃຫ້ຕອບກັບໄປວ່າ "ຖ້າບໍ່ຈຳກັດຂອບເຂດ ກໍຈະບໍ່ໄດ້ຜົນລັດທີ່ສາມາດນຳໄປຕັດສິນໃຈໄດ້". ການເຮັດ PoC ທີ່ກວ້າງເກີນໄປແມ່ນການເລື່ອນການຕັດສິນໃຈອອກໄປ ແລະ ມັກຈະກາຍເປັນພຽງການທົດລອງເພື່ອຫຼີກລ່ຽງການຕັດສິນໃຈເທົ່ານັ້ນ.

ກຳນົດ "ຄວາມສຳເລັດ" ເປັນເອກະສານກ່ອນເລີ່ມ PoC. ໂດຍການຕົກລົງກັນລ່ວງໜ້າທັງດ້ານປະລິມານ ແລະ ຄຸນນະພາບວ່າ "ຖ້າບັນລຸເປົ້າໝາຍນີ້ຈະພິຈາລະນານຳໄປໃຊ້ງານຈິງ" ຫຼື "ຖ້າຕ່ຳກວ່ານີ້ຈະຖອນຕົວ", ຈະຊ່ວຍຫຼີກລ່ຽງຄວາມຄິດເຫັນທີ່ບໍ່ກົງກັນຕໍ່ກັບຜົນລັພທີ່ເກີດຂຶ້ນ.

ພຽງແຕ່ການວັດແທກດ້ານປະລິມານ ຫຼື ດ້ານຄຸນນະພາບຢ່າງໃດຢ່າງໜຶ່ງ ແມ່ນຖືວ່າບໍ່ຄົບຖ້ວນ. ໃນການເຮັດ PoC ທີ່ກ່ຽວຂ້ອງກັບ AI ຕ້ອງນຳທັງສອງຢ່າງມາປະສົມປະສານກັນສະເໝີ.

ຕົວຢ່າງມາດຕະຖານດ້ານປະລິມານ

• ຕົວຊີ້ວັດດ້ານ Machine Learning ເຊັ່ນ: ຄວາມແມ່ນຍຳຂອງຕົວແບບ (Model Accuracy), ອັດຕາການກູ້ຄືນ (Recall), ແລະ F1-score
• ອັດຕາການຫຼຸດຜ່ອນເວລາໃນການປະມວນຜົນ (ປຽບທຽບກັບການເຮັດວຽກດ້ວຍມື)
• ອັດຕາການແຊກແຊງຂອງມະນຸດ (ສັດສ່ວນທີ່ຜົນລັດຈາກ AI ສາມາດນຳໄປໃຊ້ງານໄດ້ໂດຍກົງ)
• ຕົ້ນທຶນຕໍ່ໜຶ່ງໜ້າວຽກ (ລວມຄ່າທຳນຽມການປະມວນຜົນ Inference ແລະ ຄ່າແຮງງານ)

ຕົວຢ່າງມາດຕະຖານດ້ານຄຸນນະພາບ

• ຄວາມເພິ່ງພໍໃຈຂອງຜູ້ໃຊ້ (ການປະເມີນ 5 ລະດັບ, ຄຳເຫັນອິດສະຫຼະ)
• ຄວາມເໝາະສົມກັບຂະບວນການເຮັດວຽກ (ງ່າຍຕໍ່ການນຳໄປລວມເຂົ້າກັບວຽກງານທີ່ມີຢູ່ແລ້ວຫຼືບໍ່)
• ຕົ້ນທຶນໃນການຮຽນຮູ້ (ເວລາທີ່ໃຊ້ຈົນກວ່າຜູ້ໃຊ້ຈະສາມາດນຳໄປໃຊ້ງານໄດ້)
• ຄວາມງ່າຍໃນການຈັດການກັບກໍລະນີຍົກເວັ້ນ (ມະນຸດສາມາດຮັບຜິດຊອບໃນກໍລະນີທີ່ AI ບໍ່ຖະໜັດໄດ້ຫຼືບໍ່)

ຖ້າຕັດສິນໂດຍອີງໃສ່ດ້ານປະລິມານພຽງຢ່າງດຽວ ອາດເຮັດໃຫ້ມອງຂ້າມຜົນລັດທີ່ວ່າ "ໄດ້ຄວາມແມ່ນຍຳແລ້ວ ແຕ່ບໍ່ສາມາດນຳໄປໃຊ້ໃນວຽກງານຈິງໄດ້". ຖ້າອີງໃສ່ດ້ານຄຸນນະພາບພຽງຢ່າງດຽວ ກໍຈະກາຍເປັນ "ຜູ້ໃຊ້ເພິ່ງພໍໃຈ ແຕ່ບໍ່ມີຄວາມຄຸ້ມຄ່າໃນດ້ານ ROI". ການນຳເອົາທັງສອງຢ່າງມາເປັນຂໍ້ມູນໃນການຕັດສິນໃຈຈະຊ່ວຍໃຫ້ໄດ້ຂໍ້ມູນທີ່ຈຳເປັນສຳລັບການຕັດສິນໃຈໃນການນຳໄປໃຊ້ງານຈິງ.

ການໃຫ້ຄວາມສຳຄັນ (Weighting) ໃນການຕັດສິນໃຈຄວນກຳນົດໄວ້ລ່ວງໜ້າ. ຄວນມີການບັນທຶກກົດເກນການຕັດສິນໃຈແບບປະສົມປະສານ ເຊັ່ນ: "ເຖິງແມ່ນວ່າດ້ານປະລິມານຈະບໍ່ບັນລຸເປົ້າໝາຍ ແຕ່ຖ້າດ້ານຄຸນນະພາບສູງຫຼາຍ ກໍໃຫ້ຜ່ານແບບມີເງື່ອນໄຂ (Conditional GO)".

ໃນເວລາເລີ່ມຕົ້ນ PoC ໃຫ້ລະບຸເກນ "ຖ້າຕ່ຳກວ່າລະດັບນີ້ແມ່ນ NO-GO" ໄວ້ຢ່າງຊັດເຈນ. ການຂຽນພຽງແຕ່ເກນຄວາມສຳເລັດໂດຍບໍ່ລະບຸເກນຄວາມລົ້ມເຫຼວໄວ້ໃນ PoC ຈະເຮັດໃຫ້ການຕັດສິນໃຈຖືກຍືດອອກໄປ ເມື່ອຜົນລັພອອກມາບໍ່ຊັດເຈນ ເຊັ່ນ: "ຂໍທົດສອບເພີ່ມອີກໜ້ອຍໜຶ່ງ" ຫຼື "ສາມາດແກ້ໄຂໄດ້ໃນເຟສຕໍ່ໄປ".

ຕົວຢ່າງຂອງເກນການຕັດສິນຄວາມລົ້ມເຫຼວ (ເປັນພຽງຄ່າແນະນຳທີ່ຕ້ອງປັບປ່ຽນຕາມວຽກງານ ແລະ ໂຈດບັນຫາ):

• ຄວາມແມ່ນຍຳຕ່ຳກວ່າຂີດຈຳກັດທີ່ຍອມຮັບໄດ້ໃນການເຮັດວຽກ (ຕົວຢ່າງ: 80%)
• ອັດຕາການຍອມຮັບຂອງຜູ້ໃຊ້ (ອັດຕາສ່ວນຄຳຕອບຂອງຜູ້ເຂົ້າຮ່ວມ PoC ທີ່ວ່າ "ຕ້ອງການໃຊ້ງານຈິງ") ຕ່ຳກວ່າລະດັບທີ່ກຳນົດ (ຕົວຢ່າງ: 60%)
• ຕົ້ນທຶນໃນການປະມວນຜົນຕໍ່ 1 ລາຍການ ສູງກວ່າການເຮັດວຽກດ້ວຍມື
• ຄວາມຫຍຸ້ງຍາກໃນການນຳໄປໃຊ້ງານຈິງໃນແງ່ຂອງກົດໝາຍ ແລະ ການປະຕິບັດຕາມກົດລະບຽບ (ການຂໍຄວາມຍິນຍອມຕາມ PDPA, ການໂອນຂໍ້ມູນສ່ວນບຸກຄົນຂ້າມຊາຍແດນ ແລະ ອື່ນໆ)

ເນື່ອງຈາກຄ່າເຫຼົ່ານີ້ຈະປ່ຽນແປງໄປຢ່າງຫຼວງຫຼາຍຕາມອຸດສາຫະກຳ, ວຽກງານ ແລະ ປະລິມານຂໍ້ມູນ, ດັ່ງນັ້ນຈຶ່ງບໍ່ຄວນກຳນົດເປັນຄ່າຄົງທີ່ເພື່ອເປັນມາດຕະຖານ, ແຕ່ຄວນຕັດສິນໃຈໂດຍການຄິດໄລ່ຍ້ອນກັບຈາກວຽກງານປັດຈຸບັນ ແລະ ມູນຄ່າທາງທຸລະກິດຂອງບໍລິສັດຕົນເອງ.

ການກຳນົດຄວາມລົ້ມເຫຼວໄວ້ລ່ວງໜ້າ ບໍ່ແມ່ນການປະກາດຄວາມພ່າຍແພ້ ແຕ່ເປັນການປະກັນໄພເພື່ອຫຼີກລ່ຽງການລົງທຶນເພີ່ມເຕີມທີ່ສູນເປົ່າ. PoC ທີ່ສາມາດຕັດສິນ NO-GO ໄດ້ໄວ ຈະສົ່ງຜົນໃຫ້ປະສິດທິພາບການລົງທຶນດ້ານ AI ໂດຍລວມຕະຫຼອດປີເພີ່ມຂຶ້ນ.

ກຳນົດທິດທາງຂອງໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ໂດຍຄຳນຶງເຖິງການນຳໄປໃຊ້ງານຈິງໄວ້ໃນ PoC. ບໍ່ຈຳເປັນຕ້ອງສ້າງລະບົບທີ່ໃຊ້ງານຈິງຢ່າງສົມບູນ ແຕ່ໃຫ້ບັນທຶກແຜນຜັງໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ໄວ້ໃນເອກະສານອອກແບບ PoC ໃຫ້ພຽງພໍທີ່ຈະສາມາດຕອບຄຳຖາມໄດ້ວ່າລະບົບຈະເຮັດວຽກແນວໃດໃນສະຖານະການນຳໄປໃຊ້ງານຈິງ.

ໃນການເຮັດ PoC, ການຕັດສິນໃຈວ່າຈະເຊື່ອມຕໍ່ ຫຼື ຊິງຄ໌ຂໍ້ມູນກັບລະບົບທີ່ມີຢູ່ແລ້ວໃນລະດັບໃດນັ້ນ ເປັນຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ. ການເຊື່ອມໂຍງແບບສົມບູນຈະໃຊ້ເວລາ ແລະ ຊັບພະຍາກອນຫຼາຍ ເຊິ່ງຈະສົ່ງຜົນກະທົບຕໍ່ໄລຍະເວລາຂອງ PoC, ແຕ່ຖ້າຂ້າມການເຊື່ອມຕໍ່ຫຼາຍເກີນໄປ ກໍຈະເຮັດໃຫ້ບໍ່ສາມາດປະເມີນຄ່າໃຊ້ຈ່າຍໃນການນຳໄປໃຊ້ງານຈິງໄດ້.

ທາງເລືອກທີ່ເປັນໄປໄດ້ໃນຄວາມເປັນຈິງມີ 3 ຢ່າງດັ່ງນີ້:

• ການເຊື່ອມໂຍງຜ່ານ API ແບບສົມບູນ — ເປັນຮູບແບບທີ່ໃກ້ຄຽງກັບການນຳໄປໃຊ້ງານຈິງ. ໃຊ້ຊັບພະຍາກອນຫຼາຍ. ເລືອກໃຊ້ໃນກໍລະນີທີ່ແນ່ໃຈວ່າຈະມີການນຳໄປໃຊ້ງານຈິງ ຫຼື ໃນກໍລະນີທີ່ຈຸດເຊື່ອມຕໍ່ດັ່ງກ່າວເປັນຈຸດສຳຄັນ ຫຼື ແກນຫຼັກທີ່ຕ້ອງໄດ້ຮັບການກວດສອບ.
• ວິທີການໃຊ້ໄຟລ໌ກາງ (CSV / JSON) — ນຳໄຟລ໌ທີ່ສົ່ງອອກ (Export) ມາຈາກລະບົບທີ່ມີຢູ່ແລ້ວໄປປະມວນຜົນດ້ວຍ AI ແລ້ວສົ່ງໄຟລ໌ຜົນລັພກັບຄືນ. ເປັນວິທີທີ່ເປັນຈິງ ແລະ ຖືກນຳໃຊ້ຫຼາຍທີ່ສຸດໃນ PoC.
• ສະເພາະ UI ແບບ Standalone — ແຍກອອກຈາກລະບົບທີ່ມີຢູ່ແລ້ວ ແລະ ປະເມີນຜົນດ້ວຍ UI ສະເພາະ. ເຖິງວ່າຈະເພີ່ມຄວາມຫຍຸ້ງຍາກໃນການກຽມຂໍ້ມູນ ແຕ່ກໍບໍ່ຈຳເປັນຕ້ອງປັບແຕ່ງໃນສ່ວນຂອງການເຊື່ອມຕໍ່.

ໃຫ້ບັນທຶກວິທີການເຊື່ອມຕໍ່ທີ່ເລືອກໄວ້ ພ້ອມກັບວິທີທີ່ຈະປ່ຽນໄປໃຊ້ໃນການນຳໄປໃຊ້ງານຈິງ. ການລະບຸເສັ້ນທາງການປ່ຽນຜ່ານໃຫ້ຊັດເຈນ ເຊັ່ນ: "PoC ໃຊ້ໄຟລ໌ກາງ, ການນຳໄປໃຊ້ງານຈິງໃຊ້ການເຊື່ອມໂຍງຜ່ານ API" ຈະຊ່ວຍເພີ່ມຄວາມຖືກຕ້ອງໃນການປະເມີນຄ່າໃຊ້ຈ່າຍສຳລັບການນຳໄປໃຊ້ງານຈິງໄດ້.

ຂໍ້ມູນການປະເມີນຜົນມີຜົນຕໍ່ຄວາມໜ້າເຊື່ອຖືຂອງ PoC. ຖ້າປະເມີນດ້ວຍຂໍ້ມູນທີ່ບໍ່ມີຄວາມເປັນຕົວແທນທີ່ດີ ກໍຈະບໍ່ສາມາດຄາດການພຶດຕິກຳໃນການນຳໃຊ້ງານຈິງໄດ້.

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ 5 ປະການໃນການອອກແບບຂໍ້ມູນການປະເມີນຜົນມີດັ່ງນີ້:

• ຈຳນວນຕົວຢ່າງ — ຢ່າງໜ້ອຍ 100–500 ລາຍການ, ຖ້າເປັນວຽກທີ່ຊັບຊ້ອນຄວນມີ 1,000 ລາຍການຂຶ້ນໄປ. ຖ້າມີໜ້ອຍເກີນໄປຈະບໍ່ສາມາດປະເມີນຜົນທາງສະຖິຕິທີ່ມີຄວາມໝາຍໄດ້.
• ຄວາມເປັນຕົວແທນ — ຕ້ອງປະກອບດ້ວຍຂໍ້ມູນຕົວຈິງໃນຮອບ 6 ເດືອນຫາ 1 ປີທີ່ຜ່ານມາຢ່າງຄົບຖ້ວນ ເຊັ່ນ: ກໍລະນີທົ່ວໄປທີ່ມີປະລິມານວຽກສູງ, ການປ່ຽນແປງຕາມລະດູການ, ຄວາມແຕກຕ່າງທາງພູມສາດ ແລະ ຄວາມແຕກຕ່າງລະຫວ່າງພະແນກ.
• Edge case — ຕ້ອງມີການປະສົມຂໍ້ມູນທີ່ມີສຽງລົບກວນ (Noise data), ຂໍ້ມູນທີ່ຂາດຫາຍ, ຮູບແບບທີ່ບໍ່ຄາດຄິດ ແລະ ການປ້ອນຂໍ້ມູນທີ່ບໍ່ຫວັງດີເຂົ້າໄປໂດຍເຈດຕະນາ.
• ການຈັດການຂໍ້ມູນສ່ວນບຸກຄົນ — ໃນກໍລະນີທີ່ໃຊ້ຂໍ້ມູນຈິງໃນການປະຕິບັດງານ, ຕ້ອງມີການເຮັດ Masking ຫຼື ເຮັດໃຫ້ເປັນນາມມະທຳ ເພື່ອໃຫ້ສອດຄ່ອງກັບຂໍ້ກຳນົດຂອງ PDPA ໄທ ແລະ ກົດໝາຍປົກປ້ອງຂໍ້ມູນສ່ວນບຸກຄົນຂອງຍີ່ປຸ່ນ. ຖ້າຈຳເປັນຕ້ອງຂໍຄວາມຍິນຍອມໃໝ່ ໃຫ້ກວດສອບລ່ວງໜ້າ.
• ການຈັດການເວີຊັນຂອງຊຸດຂໍ້ມູນ (Dataset) — ຕ້ອງບັນທຶກປະຫວັດການປ່ຽນແປງວ່າໃຜເປັນຜູ້ສ້າງຂໍ້ມູນການປະເມີນຜົນ, ສ້າງຂຶ້ນເມື່ອໃດ ແລະ ໄດ້ມາຈາກໃສ. ເພື່ອຫຼີກລ່ຽງສະຖານະການທີ່ "ບໍ່ສາມາດເຮັດຊ້ຳຜົນຂອງ PoC ໄດ້" ໃນໄລຍະການນຳໃຊ້ງານຈິງ.

ຄວນໃຊ້ເວລາຢ່າງໜ້ອຍ 1–2 ອາທິດໃນການອອກແບບຂໍ້ມູນການປະເມີນຜົນ. PoC ທີ່ລະເລີຍຂັ້ນຕອນນີ້ ຈະເກີດບັນຫາໃນການຕີຄວາມໝາຍຂອງຜົນລັພຢ່າງແນ່ນອນ.

ອອກແບບ "ປະຕູ" ເພື່ອປິດວຽກ PoC. ໂດຍການກຳນົດລາຍການຕັດສິນໃຈ ແລະ ຜູ້ຕັດສິນສຳລັບ GO, NO-GO, ແລະ GO ແບບມີເງື່ອນໄຂໄວ້ລ່ວງໜ້າ, ຈະຊ່ວຍໃຫ້ການປະຊຸມລາຍງານບໍ່ຈົບລົງພຽງແຕ່ການສົນທະນາ ແຕ່ສາມາດນຳໄປສູ່ການຕັດສິນໃຈໄດ້ຢ່າງແທ້ຈິງ.

ລາຍການທີ່ຕ້ອງປະເມີນໃນຂັ້ນຕອນການຕັດສິນໃຈເພື່ອເປີດຕົວ ຫຼື Launch ລະບົບສູ່ການໃຊ້ງານຈິງ ຄວນຖືກສ້າງເປັນຕາຕະລາງ ແລະ ແບ່ງປັນໃຫ້ຮັບຊາບຕັ້ງແຕ່ເລີ່ມຕົ້ນເຮັດ PoC. ການຕັດສິນໃຈຂັ້ນສຸດທ້າຍຈະດຳເນີນການໂດຍການຕື່ມຂໍ້ມູນໃສ່ຕາຕະລາງນີ້.

ການຕັດສິນໃຈຈະປະເມີນລາຍການເຫຼົ່ານີ້ໃນລະດັບ 5 ຂັ້ນ, ໂດຍພິຈາລະນາຈາກຄະແນນລວມ ແລະ ມາດຕະຖານຂັ້ນຕ່ຳຂອງແຕ່ລະລາຍການ (ເຊັ່ນ: ຄວາມສ່ຽງຕ້ອງໄດ້ 3 ຄະແນນຂຶ້ນໄປ) ເພື່ອກຳນົດວ່າຈະເປັນ GO / GO ແບບມີເງື່ອນໄຂ / ຫຼື NO-GO. ໃນກໍລະນີທີ່ເປັນ GO ແບບມີເງື່ອນໄຂ ຕ້ອງລະບຸລາຍການທີ່ຕ້ອງກວດສອບເພີ່ມເຕີມໃຫ້ຊັດເຈນ.

NO-GO ແມ່ນ "ການຕັດສິນໃຈ" ບໍ່ແມ່ນ "ຄວາມລົ້ມເຫຼວ". ການອອກແບບຂະບວນການຖອນຕົວເມື່ອເຖິງຈຸດ NO-GO ໄວ້ລ່ວງໜ້າ ຈະເຮັດໃຫ້ການລົງທຶນໃນ PoC ຂອງອົງກອນມີຄຸນຄ່າ.

ວຽກງານທີ່ຕ້ອງປະຕິບັດທຸກຄັ້ງເມື່ອມີການຖອນຕົວມີ 4 ຢ່າງດັ່ງນີ້:

• ການສະສົມບົດຮຽນ — ບັນທຶກເຫດຜົນທີ່ບໍ່ປະສົບຜົນສຳເລັດໂດຍແບ່ງອອກເປັນ 4 ແກນຫຼັກ ຄື: ຂໍ້ມູນ, ເຕັກໂນໂລຊີ, ການດຳເນີນງານ ແລະ ອົງກອນ. ຈັດຮູບແບບໃຫ້ສາມາດນຳກັບມາໃຊ້ໃໝ່ໄດ້ໃນ PoC ຄັ້ງຕໍ່ໄປ ຫຼື ເມື່ອທີມອື່ນຕ້ອງການທົດລອງໃໝ່.
• ການນຳສະເໜີແນວທາງຕໍ່ໄປ — ຈັດລະບຽບທາງເລືອກຕ່າງໆ ລວມເຖິງທາງເລືອກທີ່ບໍ່ແມ່ນ AI ເຊັ່ນ: "ສາມາດປັບປຸງຂະບວນການໂດຍໃຊ້ແຮງງານຄົນແທນໄດ້ຫຼືບໍ່", "ການພິຈາລະນາເຕັກໂນໂລຊີອື່ນ (ແບບຈຳລອງສະເພາະທີ່ມີຄວາມແມ່ນຍຳສູງກວ່າ, ລະບົບ Rule-based, ຫຼື ຜູ້ໃຫ້ບໍລິການອື່ນ)", "ການທົບທວນຄືນຂະບວນການເຮັດວຽກເອງ".
• ການເຮັດໃຫ້ການຢຸດຕິການລົງທຶນມີຄວາມຊັດເຈນ — ສ້າງກົນໄກເພື່ອບໍ່ໃຫ້ເກີດ Zombie PoC ເຊັ່ນ: "ຈະບໍ່ມີການເຮັດ PoC ໃນຫົວຂໍ້ດຽວກັນອີກໃນອີກ 6 ເດືອນຂ້າງໜ້າ" ຫຼື "PoC ຄັ້ງຕໍ່ໄປຈະໃຫ້ທີມອື່ນເປັນຜູ້ຮັບຜິດຊອບ".
• ກອງປະຊຸມທົບທວນເພື່ອສ້າງຄຸນຄ່າຈາກຄວາມລົ້ມເຫຼວ — ຈັດກອງປະຊຸມທີ່ມີຜູ້ບໍລິຫານ ແລະ ພາກສ່ວນທີ່ກ່ຽວຂ້ອງເຂົ້າຮ່ວມ ເພື່ອແບ່ງປັນເຫດຜົນໃນການຕັດສິນໃຈ NO-GO. ເຮັດໃຫ້ວັດທະນະທຳທີ່ບໍ່ລົງໂທດຕໍ່ຄວາມລົ້ມເຫຼວປາກົດໃຫ້ເຫັນຢ່າງຊັດເຈນໃນອົງກອນ.

ອົງກອນທີ່ມີການອອກແບບ PoC ທີ່ສາມາດຕັດສິນໃຈ NO-GO ໄດ້ ຈະຊ່ວຍເພີ່ມປະສິດທິພາບຂອງພອດການລົງທຶນ AI ໂດຍລວມໃນແຕ່ລະປີໃຫ້ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.

ຈັດລະບຽບຄວາມຜິດພາດທີ່ພົບເຫັນເລື້ອຍໆໃນ PoC ພ້ອມກັບມາດຕະການແກ້ໄຂ. ຂໍໃຫ້ໃຊ້ເປັນລາຍການກວດສອບ (Checklist) ໃນຂັ້ນຕອນການອອກແບບ.

1. ດຳເນີນການໂດຍມີສົມມຸດຕິຖານວ່າ "ຖ້າມີຂໍ້ມູນກໍຈະແກ້ໄຂໄດ້" — ບໍ່ໃຫ້ຄວາມສຳຄັນກັບຄຸນນະພາບຂອງຂໍ້ມູນ, ຄວາມເປັນຕົວແທນ ແລະ ແຮງງານໃນການຕິດປ້າຍກຳກັບ (Labeling), ເຮັດໃຫ້ໃຊ້ເວລາໝົດໄປກັບການກຽມຂໍ້ມູນຫຼັງຈາກເລີ່ມການກວດສອບແລ້ວ. ມາດຕະການ: ໃຫ້ແຍກໄລຍະເວລາການກຽມຂໍ້ມູນອອກມາຕ່າງຫາກປະມານ 2-4 ອາທິດກ່ອນເລີ່ມ PoC ແລະ ບໍ່ນັບລວມເຂົ້າໃນໄລຍະເວລາຂອງ PoC.
2. ປ່ອຍໃຫ້ເປັນໜ້າທີ່ຂອງ Vendor ໂດຍທີ່ຝ່າຍປະຕິບັດງານບໍ່ມີສ່ວນຮ່ວມ — PoC ທີ່ສ້າງໂດຍ Vendor ອາດຈະເຮັດວຽກໄດ້ທາງດ້ານເຕັກນິກ ແຕ່ຝ່າຍປະຕິບັດງານຮູ້ສຶກວ່າ "ບໍ່ແມ່ນວຽກຂອງພວກເຂົາ", ເຮັດໃຫ້ການຕົກລົງເຫັນດີໃນການສະເໜີໃຫ້ນຳໄປໃຊ້ງານຈິງຢຸດສະງັກ. ມາດຕະການ: ໃຫ້ເຈົ້າຂອງວຽກ (Business Owner) ເຂົ້າຮ່ວມທີມ PoC ໃນຖານະສະມາຊິກຢ່າງເປັນທາງການ ແລະ ຕ້ອງໃຫ້ພວກເຂົາສະແດງຄວາມຄິດເຫັນໃນກອງປະຊຸມທົບທວນທຸກໆອາທິດ.
3. ຄິດໄລ່ຕົ້ນທຶນການນຳໄປໃຊ້ງານຈິງໃນຕອນທ້າຍ — ເມື່ອປະເມີນລາຄາການນຳໄປໃຊ້ງານຈິງຫຼັງຈາກ PoC ສຳເລັດແລ້ວ ພົບວ່າ "ລາຄາສູງກວ່າທີ່ຄິດ" ຈຶ່ງເຮັດໃຫ້ຕ້ອງກັບໄປເລີ່ມຕົ້ນໃໝ່. ມາດຕະການ: ໃຫ້ຄາດຄະເນຕົ້ນທຶນການນຳໄປໃຊ້ງານຈິງໂດຍປະມານໃນຂັ້ນຕອນການອອກແບບ PoC, ຖ້າ ROI ບໍ່ຄຸ້ມຄ່າ ໃຫ້ທົບທວນແຜນການໃໝ່ໃນຈຸດນັ້ນທັນທີ.
4. ຂໍ້ມູນທີ່ໃຊ້ປະເມີນຜົນແຕກຕ່າງຈາກຂໍ້ມູນທີ່ໃຊ້ງານຈິງ — ຂໍ້ມູນທີ່ກຽມໄວ້ສຳລັບການກວດສອບໃຫ້ຄວາມແມ່ນຍຳສູງ ແຕ່ເມື່ອນຳຂໍ້ມູນຈິງມາໃຊ້ ຄວາມແມ່ນຍຳກັບຫຼຸດລົງຢ່າງຫຼວງຫຼາຍ. ມາດຕະການ: ໃຫ້ໃຊ້ຂໍ້ມູນຈິງທີ່ຜ່ານການ Masking ແລ້ວຢ່າງໜ້ອຍ 30% ໃນຂໍ້ມູນປະເມີນຜົນ ເພື່ອຮັບປະກັນຄວາມສາມາດໃນການຈຳລອງສະພາບການນຳໄປໃຊ້ງານຈິງ.
5. ຜູ້ຕັດສິນໃຈບໍ່ເຂົ້າຮ່ວມກອງປະຊຸມລາຍງານຜົນ PoC — ສະມາຊິກທີ່ມີອຳນາດໃນການຕັດສິນໃຈບໍ່ໄດ້ເຂົ້າຮ່ວມກອງປະຊຸມລາຍງານຜົນ ເຮັດໃຫ້ການຕັດສິນໃຈຕ້ອງເລື່ອນໄປກອງປະຊຸມຄັ້ງໜ້າ. ມາດຕະການ: ກຳນົດວັນທີຂອງກອງປະຊຸມລາຍງານຜົນ ແລະ ຜູ້ທີ່ຈຳເປັນຕ້ອງເຂົ້າຮ່ວມໃຫ້ຊັດເຈນຕັ້ງແຕ່ເລີ່ມຕົ້ນ (Kick-off) PoC.
6. PoC ທີ່ປະສົບຄວາມສຳເລັດບໍ່ໄດ້ກ້າວໄປສູ່ "ຂັ້ນຕອນຕໍ່ໄປ" — ກອງປະຊຸມລາຍງານຜົນຈົບລົງດ້ວຍສຽງຕົບມື ແຕ່ບໍ່ມີການວາງແຜນນຳໄປໃຊ້ງານຈິງຕໍ່ ເຮັດໃຫ້ເວລາຜ່ານໄປໂດຍເປົ່າປະໂຫຍດ. ມາດຕະການ: ກຳນົດໄລຍະເວລາສູງສຸດບໍ່ໃຫ້ເກີນ 4 ອາທິດ ນັບຈາກຈົບ PoC ຈົນເຖິງການສະເໜີແຜນການນຳໄປໃຊ້ງານຈິງ ແລະ ຕ້ອງແຕ່ງຕັ້ງຜູ້ຮັບຜິດຊອບໃນການສະເໜີແຜນໄວ້ລ່ວງໜ້າ.

Q1: ໄລຍະເວລາຂອງ PoC ທີ່ເໝາະສົມແມ່ນເທົ່າໃດ?

ສຳລັບ PoC ໂດຍສະເພາະແລ້ວ ໄລຍະເວລາທີ່ເໝາະສົມແມ່ນ 6-8 ອາທິດ. ຖ້າລວມເວລາໃນການກະກຽມຂໍ້ມູນຕື່ມອີກ 2-4 ອາທິດ ແລະ ການວາງແຜນເພື່ອເຂົ້າສູ່ຂັ້ນຕອນການນຳໃຊ້ຈິງອີກ 2-4 ອາທິດ, ໄລຍະເວລາລວມທັງໝົດຈະຢູ່ທີ່ປະມານ 3-4 ເດືອນ. ຖ້າຫາກຍືດໄລຍະເວລາອອກໄປ ມັກຈະເຮັດໃຫ້ການຕັດສິນໃຈຊັກຊ້າ, ແຕ່ຖ້າສັ້ນເກີນໄປກໍຈະເຮັດໃຫ້ຂໍ້ມູນທີ່ໃຊ້ໃນການປະເມີນຜົນບໍ່ຄົບຖ້ວນ.

Q2: ມີງົບປະມານໂດຍປະມານສຳລັບ PoC ບໍ່?

ເນື່ອງຈາກງົບປະມານມີການປ່ຽນແປງຢ່າງຫຼວງຫຼາຍຕາມຂອບເຂດວຽກ, ການມີ ຫຼື ບໍ່ມີ Vendor, ແລະ ຄວາມເລິກຂອງການເຊື່ອມຕໍ່ກັບລະບົບທີ່ມີຢູ່ເດີມ, ຈຶ່ງບໍ່ສາມາດກຳນົດຕົວເລກທີ່ຕາຍຕົວໄດ້. ແນວໃດກໍຕາມ, ເພື່ອເປັນແນວທາງໃນການຕັດສິນໃຈ, ຫຼາຍບໍລິສັດມັກກຳນົດງົບປະມານ PoC ໄວ້ບໍ່ເກີນ 5-15% ຂອງຍອດເງິນລົງທຶນຕໍ່ປີທີ່ຄາດຄະເນໄວ້ສຳລັບການນຳໃຊ້ຈິງ. ຖ້າງົບປະມານ PoC ສູງເກີນໄປເມື່ອທຽບກັບການຄາດຄະເນການນຳໃຊ້ຈິງ, ຄວນພິຈາລະນາທົບທວນຂອບເຂດວຽກ (Scope) ໃໝ່.

Q3: ຄວນດຳເນີນການ PoC ພາຍໃນບໍລິສັດເອງ ຫຼື ຄວນມອບໝາຍໃຫ້ຄູ່ຮ່ວມງານພາຍນອກ?

ການແບ່ງໜ້າທີ່ໂດຍໃຫ້ເຈົ້າຂອງວຽກ, ການກະກຽມຂໍ້ມູນ, ແລະ ການຕັດສິນປະເມີນຜົນເປັນໜ້າທີ່ຂອງພາຍໃນບໍລິສັດ, ສ່ວນການຈັດຕັ້ງປະຕິບັດດ້ານເຕັກນິກໃຫ້ມອບໝາຍແກ່ຄູ່ຮ່ວມງານພາຍນອກ ແມ່ນວິທີທີ່ເປັນໄປໄດ້ຫຼາຍທີ່ສຸດ. ຖ້າມອບໝາຍວຽກດ້ານເຕັກນິກທັງໝົດໃຫ້ຄົນອື່ນເຮັດ, ຈະເຮັດໃຫ້ມີຕົ້ນທຶນເພີ່ມເຕີມໃນການສ້າງທີມງານພາຍໃນ ແລະ ການສ້າງລະບົບການບຳລຸງຮັກສາໃນໄລຍະການນຳໃຊ້ຈິງ.

Q4: ຫຼັງຈາກ PoC ປະສົບຜົນສຳເລັດແລ້ວ ຈະໃຊ້ເວລາເທົ່າໃດຈຶ່ງຈະສາມາດນຳໃຊ້ຈິງໄດ້?

ເຖິງວ່າຈະມີຄວາມແຕກຕ່າງກັນໄປຕາມຂະໜາດຂອງວຽກ ແລະ ອົງກອນ, ແຕ່ໂດຍທົ່ວໄປແລ້ວຈະໃຊ້ເວລາປະມານ 3 ເດືອນ ຫາ 1 ປີ ນັບຕັ້ງແຕ່ເລີ່ມວາງແຜນຈົນເຖິງການເປີດຕົວ ຫຼື Launch ຢ່າງເປັນທາງການ. ໄລຍະເວລານີ້ຈະປ່ຽນແປງຢ່າງຫຼວງຫຼາຍຕາມຈຳນວນວຽກທີ່ເພີ່ມຂຶ້ນໃນການປັບປຸງ Architecture, ການຈັດການຂໍ້ມູນ, ແລະ ການສ້າງລະບົບການດຳເນີນງານທີ່ເຫັນໄດ້ຈາກ PoC.

Q5: ໃນກໍລະນີທີ່ດຳເນີນການ PoC ໃນປະເທດໄທ ມີຈຸດສຳຄັນ ຫຼື ແກນຫຼັກໃດທີ່ຄວນລະວັງເປັນພິເສດ?

ຄວນກວດສອບຄວາມສອດຄ່ອງກັບກົດໝາຍຄຸ້ມຄອງຂໍ້ມູນສ່ວນບຸກຄົນຂອງໄທ (PDPA) ຕັ້ງແຕ່ຂັ້ນຕອນ PoC. ໂດຍສະເພາະແມ່ນ: ສະຖານະການຂໍຄວາມຍິນຍອມໃນການນຳໃຊ້ຂໍ້ມູນສ່ວນບຸກຄົນທີ່ລວມຢູ່ໃນຂໍ້ມູນທີ່ໃຊ້ປະເມີນຜົນ, ຄວາມຖືກຕ້ອງຕາມກົດໝາຍຂອງການໂອນຂໍ້ມູນຂ້າມຊາຍແດນ (ເມື່ອໃຊ້ບໍລິການ AI ທີ່ຢູ່ນອກປະເທດໄທ), ແລະ ຂະບວນການຕອບສະໜອງຕໍ່ສິດທິຂອງເຈົ້າຂອງຂໍ້ມູນ (ການຮ້ອງຂໍເຂົ້າເຖິງ ຫຼື ລຶບຂໍ້ມູນ). ນອກຈາກນີ້, ໃນສະພາບແວດລ້ອມການເຮັດວຽກທີ່ມີການໃຊ້ພາສາໄທ, ພາສາອັງກິດ ແລະ ພາສາຍີ່ປຸ່ນປົນກັນ, ຄວນເພີ່ມການປະເມີນປະສິດທິພາບດ້ານພາສາຂອງ Model ຕື່ມອີກ.

ການອອກແບບ PoC ສຳລັບການນຳ AI ມາໃຊ້ຄວນຖືກອອກແບບໃຫ້ເປັນພື້ນທີ່ສຳລັບ "ການເກັບກຳຂໍ້ມູນທີ່ຈຳເປັນເພື່ອຕັດສິນໃຈໃນການນຳໄປໃຊ້ງານຈິງ" ພາຍໃນໄລຍະເວລາການກວດສອບ ເພື່ອຫຼີກລ່ຽງການເຮັດວຽກທີ່ບໍ່ມີປະສິດທິພາບ. 4 ຂັ້ນຕອນທີ່ໄດ້ອະທິບາຍໄວ້ໃນບົດຄວາມນີ້ມີດັ່ງນີ້:

• Step 1: ການກຳນົດຂອບເຂດ ແລະ ບັນຫາທາງທຸລະກິດ — ແຍກບັນຫາທາງທຸລະກິດອອກເປັນໜ່ວຍງານຍ່ອຍໆ ແລະ ຈຳກັດຂອບເຂດຂອງ PoC ໃຫ້ແຄບລົງຢ່າງຕັ້ງໃຈ ໂດຍກຳນົດໄລຍະເວລາ 6-8 ອາທິດ, ກວມເອົາ 1 ວຽກງານ ແລະ ມີຜູ້ໃຊ້ງານ 5-10 ຄົນ.
• Step 2: ການອອກແບບມາດຕະຖານຄວາມສຳເລັດ ແລະ KPI — ກຳນົດທັງຕົວເລກປະລິມານ ແລະ ຄຸນນະພາບຄວບຄູ່ກັນໄປ, ພ້ອມທັງບັນທຶກມາດຕະຖານການຕັດສິນວ່າລົ້ມເຫຼວໄວ້ເປັນລາຍລັກອັກສອນກ່ອນເລີ່ມຕົ້ນ PoC.
• Step 3: ການສ້າງສະຖາປັດຕະຍະກຳ ແລະ ສະພາບແວດລ້ອມໃນການປະເມີນຜົນ — ກຳນົດວິທີການເຊື່ອມຕໍ່ກັບລະບົບທີ່ມີຢູ່, ຄວາມເປັນຕົວແທນຂອງຂໍ້ມູນທີ່ໃຊ້ປະເມີນ, ແລະ ການປະຕິບັດຕາມກົດລະບຽບລວມເຖິງ PDPA ຂອງໄທໄວ້ເບື້ອງຕົ້ນ, ພ້ອມທັງລະບຸເສັ້ນທາງການຍ້າຍໄປສູ່ການນຳໃຊ້ງານຈິງໃຫ້ຊັດເຈນ.
• Step 4: ການອອກແບບປະຕູການຕັດສິນໃຈສູ່ການນຳໃຊ້ງານຈິງ — ຈັດຕັ້ງຕາຕະລາງເກນການຕັດສິນໃຈແບບ GO / GO ແບບມີເງື່ອນໄຂ / NO-GO ແລະ ດຳເນີນການປະຊຸມລາຍງານຜົນເພື່ອເປັນພື້ນທີ່ໃນການຕັດສິນໃຈ.

ຄຸນນະພາບຂອງການອອກແບບ PoC ມີຜົນໂດຍກົງຕໍ່ໂອກາດທີ່ຈະກ້າວໄປສູ່ການນຳໃຊ້ງານຈິງ. ກ່ອນທີ່ຈະເລີ່ມຕົ້ນການກວດສອບ, ຂໍແນະນຳໃຫ້ອ່ານເອກະສານການອອກແບບຄືນໃໝ່ ແລະ ກວດສອບວ່າລາຍການກວດສອບໃນບົດຄວາມນີ້ໄດ້ຖືກບັນຈຸໄວ້ຄົບຖ້ວນແລ້ວຫຼືບໍ່.

ສຳລັບບົດຄວາມທີ່ກ່ຽວຂ້ອງ, ທ່ານສາມາດອ້າງອີງເພີ່ມເຕີມໄດ້ຈາກ ການນຳ AI Agent ໄປສູ່ການນຳໃຊ້ງານຈິງ ເຊິ່ງກ່າວເຖິງການຂະຫຍາຍຕົວສູ່ການດຳເນີນງານຈິງ, ວິທີການວັດແທກຜົນຫຼັງຈາກການນຳ AI Agent ມາໃຊ້ ເຊິ່ງອະທິບາຍວິທີການປະຕິບັດໃນການວັດແທກຜົນ, ແລະ AI × Synthetic Test ເຊິ່ງກ່າວເຖິງການອອກແບບການປະເມີນຜົນໂດຍໃຊ້ຂໍ້ມູນສັງເຄາະ.