AI Center of Excellence (CoE) ແມ່ນອົງການຈັດຕັ້ງຖາວອນທີ່ລວບລວມຄວາມຮູ້, ມາດຕະຖານ ຫຼື Specification, ແລະ ການກຳກັບດູແລໃນການຂັບເຄື່ອນ AI ພາຍໃນບໍລິສັດ ເພື່ອເຜີຍແຜ່ໄປທົ່ວທຸກພາກສ່ວນຂອງອົງກອນ. ໃນຂະນະທີ່ Chief AI Officer (CAO) ເປັນບົດບາດສ່ວນບຸກຄົນໃນລະດັບບໍລິຫານ ແລະ AgentOps ເປັນທີມງານຊ່ຽວຊານດ້ານການປະຕິບັດງານ AI Agent, CoE ໝາຍເຖິງໂຄງສ້າງການຂັບເຄື່ອນທີ່ກວມເອົາທົ່ວທັງອົງກອນ.

ບົດຄວາມນີ້ມີຈຸດປະສົງເພື່ອອະທິບາຍເງື່ອນໄຂເບື້ອງຕົ້ນ ແລະ 4 ຂັ້ນຕອນ (ການກຳນົດພາລະກິດ, ໂຄງສ້າງອົງກອນ, ການຈັດຕຽມຄວາມຮູ້, ແລະ ການກຳກັບດູແລ) ໃນການອອກແບບ CoE ໂດຍເນັ້ນໃສ່ CIO, ຜູ້ຮັບຜິດຊອບການຂັບເຄື່ອນ DX, ຝ່າຍວາງແຜນຍຸດທະສາດຂອງສຳນັກງານໃຫຍ່, ແລະ ຜູ້ຮັບຜິດຊອບບໍລິສັດສາຂາໃນທ້ອງຖິ່ນຂອງບໍລິສັດຍີ່ປຸ່ນທີ່ມີການດຳເນີນທຸລະກິດໃນຫຼາຍພື້ນທີ່ທົ່ວ ASEAN. ເມື່ອອ່ານຈົບ, ທ່ານຈະສາມາດຈັດລະບຽບປະເດັນຕ່າງໆທີ່ຈຳເປັນໃນການສ້າງຕັ້ງ CoE ໄດ້ ເຊັ່ນ: ການແບ່ງແຍກບົດບາດລະຫວ່າງສຳນັກງານໃຫຍ່ກັບບໍລິສັດສາຂາ, ການຈັດລະບຽບຄວາມສຳພັນກັບອົງກອນ IT/DX ທີ່ມີຢູ່, ແລະ ການດຳເນີນງານໃນສະພາບແວດລ້ອມທີ່ມີຫຼາຍພາສາ ແລະ ຫຼາຍກົດລະບຽບ.

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

ໃນຖານະຮູບແບບການຈັດຕັ້ງເພື່ອຂັບເຄື່ອນ AI, CoE, CAO ແລະ AgentOps ມັກຈະຖືກເຂົ້າໃຈຜິດກັນ ແຕ່ຄວາມລະອຽດຂອງບົດບາດ ແລະ ລັກສະນະຂອງມັນນັ້ນແຕກຕ່າງກັນ.

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

ເຫດຜົນທາງໂຄງສ້າງທີ່ເຮັດໃຫ້ບໍລິສັດຍີ່ປຸ່ນທີ່ດຳເນີນທຸລະກິດໃນຫຼາຍສາຂາໃນ ASEAN ຈຳເປັນຕ້ອງມີ CoE ສາມາດສະຫຼຸບໄດ້ 3 ປະການດັ່ງນີ້:

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

CoE ຄືຄຳຕອບທາງອົງກອນຕໍ່ກັບບັນຫາທາງໂຄງສ້າງທັງ 3 ປະການນີ້. ຈຸດປະສົງບໍ່ແມ່ນພຽງແຕ່ "ການສ້າງພະແນກທີ່ເກັ່ງດ້ານ AI" ເທົ່ານັ້ນ, ແຕ່ແມ່ນການສ້າງແພລັດຟອມໂດຍອີງໃສ່ 3 ແກນຫຼັກ ຄື: ການໝູນວຽນຄວາມຮູ້, ການປະຕິບັດຕາມກົດລະບຽບ ແລະ ການຈັດສັນການລົງທຶນ.

ຮູບແບບທົ່ວໄປທີ່ເຮັດໃຫ້ CoE ກາຍເປັນພຽງແຕ່ຊື່ຫຼັງຈາກການເປີດຕົວ ຫຼື Launch ສາມາດສະຫຼຸບໄດ້ 4 ປະການດັ່ງນີ້:

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

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

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

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

ການສ້າງຄວາມສົມດຸນລະຫວ່າງສຳນັກງານໃຫຍ່ ແລະ ທ້ອງຖິ່ນ ສາມາດຈັດລະບຽບໄດ້ງ່າຍຂຶ້ນໂດຍການແບ່ງບົດບາດດັ່ງນີ້:

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

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

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

ຄວາມສຳພັນຫຼັກທີ່ຄວນຈັດລະບຽບມີດັ່ງນີ້:

• ການແບ່ງສ່ວນກັບຫ້ອງການສົ່ງເສີມ DX ທີ່ມີຢູ່ — ຖ້າຫ້ອງການສົ່ງເສີມ DX ຈັດການການປະຕິຮູບທຸລະກິດໂດຍລວມ, ໃຫ້ວາງຕຳແໜ່ງ CoE ເປັນອົງກອນຍ່ອຍທີ່ເນັ້ນສະເພາະດ້ານ AI. ຫຼື ລວມ ຫຼື Merge ຟັງຊັນ CoE ເຂົ້າໄປໃນຫ້ອງການສົ່ງເສີມ DX.
• ການຮ່ວມມືກັບພະແນກລະບົບຂໍ້ມູນຂ່າວສານ — ການແບ່ງໜ້າທີ່ທີ່ເປັນໄປໄດ້ຫຼາຍທີ່ສຸດຄື: ພະແນກລະບົບຂໍ້ມູນຂ່າວສານເປັນຜູ້ດຳເນີນງານດ້ານໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ສ່ວນກາງ (Cloud, ໂຄງສ້າງພື້ນຖານຂໍ້ມູນ, ການຢືນຢັນຕົວຕົນ) ແລະ CoE ຮັບຜິດຊອບດ້ານໂຄງສ້າງພື້ນຖານສະເພາະ AI, ການຈັດການ Model, ແລະ ສະພາບແວດລ້ອມການທົດລອງ.
• ຄວາມສອດຄ່ອງກັບຍຸດທະສາດ IT ສາກົນ — ເຮັດໃຫ້ມາດຕະຖານ CoE ສອດຄ່ອງກັບ Technology Stack ແລະ ມາດຕະຖານຄວາມປອດໄພທີ່ກຳນົດໂດຍຍຸດທະສາດ IT ສາກົນຂອງສຳນັກງານໃຫຍ່. ຖ້າ CoE ດຳເນີນງານໃນທິດທາງຂອງຕົນເອງ, ຕົ້ນທຶນໃນການລວມລະບົບໃນໄລຍະຍາວຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.
• ການແບ່ງສ່ວນກັບພະແນກ R&D — ແບ່ງໃຫ້ R&D ເປັນຜູ້ກວດສອບເທັກໂນໂລຊີ AI ໃນໄລຍະການຄົ້ນຄວ້າ ແລະ ພັດທະນາ, ສ່ວນ CoE ເປັນຜູ້ຮັບຜິດຊອບການນຳໄປໃຊ້ໃນວຽກງານຕົວຈິງ. ໃນກໍລະນີທີ່ຂອບເຂດບໍ່ຊັດເຈນ, ໃຫ້ໃຊ້ຮູບແບບໂຄງການຮ່ວມມືໃນການດຳເນີນງານ.

ໃຫ້ບັນທຶກຜັງອົງກອນ ແລະ RACI (Responsible / Accountable / Consulted / Informed) Matrix ເປັນເອກະສານໃນເວລາສ້າງຕັ້ງ CoE ແລະ ຕົກລົງເຫັນດີກັບພະແນກທີ່ກ່ຽວຂ້ອງ.

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

ປະເດັນສຳຄັນສາມາດສະຫຼຸບໄດ້ດັ່ງນີ້:

• ການຈັດການຄວາມຮູ້ຫຼາຍພາສາ — ການໃຊ້ເອກະສານຫຼັກເປັນພາສາຢີ່ປຸ່ນ ຫຼື ພາສາອັງກິດ ໂດຍມີບົດສະຫຼຸບເປັນພາສາທ້ອງຖິ່ນຄຽງຄູ່ກັນໄປແມ່ນວິທີການທີ່ເໝາະສົມ. ຫາກແຕ່ລະສາຂາມີຖານຄວາມຮູ້ທີ່ເປັນເອກະລາດໃນພາສາໄທ, ພາສາຫວຽດນາມ ແລະ ພາສາອິນໂດເນເຊຍ ຈະເຮັດໃຫ້ການຄົ້ນຫາຂໍ້ມູນຈາກສຳນັກງານໃຫຍ່ມີປະສິດທິພາບຫຼຸດລົງຢ່າງຫຼວງຫຼາຍ.
• ຄວາມແຕກຕ່າງຂອງກົດໝາຍປົກປ້ອງຂໍ້ມູນສ່ວນບຸກຄົນ — PDPA ຂອງໄທ, PDPL ຂອງຫວຽດນາມ, ກົດໝາຍປົກປ້ອງຂໍ້ມູນສ່ວນບຸກຄົນຂອງລາວ, ກົດໝາຍ PDP ຂອງອິນໂດເນເຊຍ, PDPA ຂອງສິງກະໂປ, Data Privacy Act ຂອງຟີລິບປິນ ແລະ PDPA ຂອງມາເລເຊຍ ລ້ວນແຕ່ມີຂໍ້ກຳນົດທີ່ແຕກຕ່າງກັນໃນແຕ່ລະປະເທດ ທັງໃນດ້ານການຂໍຄວາມຍິນຍອມ, ການໂອນຂໍ້ມູນຂ້າມຊາຍແດນ ແລະ ສິດທິຂອງເຈົ້າຂອງຂໍ້ມູນ. CoE ຄວນເປັນຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນການປະສານງານກັບຝ່າຍກົດໝາຍຂອງແຕ່ລະປະເທດ ແລະ ແຍກການຈັດການລະຫວ່າງຂໍ້ກຳນົດທົ່ວໄປກັບຂໍ້ກຳນົດສະເພາະຂອງແຕ່ລະປະເທດ.
• ການຈັດການການລົງທຶນດ້ວຍຫຼາຍສະກຸນເງິນ — ຕ້ອງມີກົນໄກທີ່ສຳນັກງານໃຫຍ່ສາມາດຕິດຕາມ PoC ທີ່ດຳເນີນດ້ວຍສະກຸນເງິນທ້ອງຖິ່ນ ເຊັ່ນ: ເງິນບາດໄທ, ເງິນດົງຫວຽດນາມ ຫຼື ເງິນຣູປີອິນໂດເນເຊຍ ໃຫ້ເປັນສະກຸນເງິນເຢນ ຫຼື ໂດລາສະຫະລັດໄດ້. ພ້ອມທັງສະແດງຜົນກະທົບຈາກການປ່ຽນແປງຂອງອັດຕາແລກປ່ຽນໃຫ້ເຫັນຢ່າງຊັດເຈນໃນບົດລາຍງານປະຈຳເດືອນ.
• ຄວາມແຕກຕ່າງຂອງເຂດເວລາ ແລະ ວັນພັກ — ການປະຊຸມທົບທວນຂ້າມສາຂາຄວນກຳນົດວັນ ແລະ ເວລາໃຫ້ຄົງທີ່ ແລະ ຄວນສ້າງຕາຕະລາງປະຈຳປີໂດຍຄຳນຶງເຖິງວັນພັກຂອງແຕ່ລະປະເທດຕັ້ງແຕ່ເລີ່ມຕົ້ນ.

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

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

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

ຕົວຢ່າງຂອບເຂດທີ່ຮັບຜິດຊອບ:

• ມາດຕະຖານ ຫຼື Specification ຂອງບໍລິສັດ (ແມ່ແບບການອອກແບບ PoC, ນະໂຍບາຍການຈັດການຂໍ້ມູນ, ເກນການປະເມີນຜູ້ສະໜອງ)
• ການກຳກັບດູແລແບບແນວນອນ ຫຼື Horizontal (ການກວດສອບການລົງທຶນທີ່ມີມູນຄ່າເກີນກຳນົດ, ການກວດສອບຄວາມສ່ຽງ, ການກວດສອບຄວາມຊ້ຳຊ້ອນ)
• ການພັດທະນາບຸກຄະລາກອນ (ການຝຶກອົບຮົມພາຍໃນ, ການຮ່ວມມືກັບພາຍນອກ, ການບໍລິຫານຈັດການຊຸມຊົນພາຍໃນ)
• ການກຳນົດທິດທາງຂອງໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ສ່ວນກາງ (ການຈັດການແບບຈຳລອງ, ສະພາບແວດລ້ອມການປະເມີນຜົນ, Knowledge DB)
• ການລວບລວມ ແລະ ລາຍງານ KPI ແບບແນວນອນ ຫຼື Horizontal

ຕົວຢ່າງຂອບເຂດທີ່ບໍ່ຮັບຜິດຊອບ:

• ການສະເໜີແນະການປັບປຸງວຽກງານສະເພາະດ້ານ (ພະແນກ ຫຼື ຜູ້ຮັບຜິດຊອບການປັບປຸງວຽກງານຂອງບໍລິສັດຍ່ອຍໃນທ້ອງຖິ່ນເປັນຜູ້ຮັບຜິດຊອບ)
• ການພັດທະນາ ແລະ ດຳເນີນງານລະບົບຢ່າງເຕັມຮູບແບບ (ພະແນກລະບົບຂໍ້ມູນຂ່າວສານ ແລະ ທີມ AgentOps ເປັນຜູ້ຮັບຜິດຊອບ)
• ການຄົ້ນຄວ້າ ແລະ ພັດທະນາບໍລິສຸດ (ພະແນກ R&D ເປັນຜູ້ຮັບຜິດຊອບ)
• ການດຳເນີນການ PoC ສະເພາະດ້ານໂດຍລຳພັງ (ພະແນກທີ່ກ່ຽວຂ້ອງເປັນຫຼັກ, CoE ເປັນພຽງຜູ້ສະໜັບສະໜູນ)

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

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

ສິ່ງທີ່ຄວນກວດສອບໃນການອອກແບບຜູ້ສະໜັບສະໜູນ (Sponsor) ມີດັ່ງນີ້:

• ຕຳແໜ່ງ ແລະ ອຳນາດຂອງຜູ້ສະໜັບສະໜູນ — ຄວນເປັນ CEO, CIO, CDO ຫຼື COO. ຖ້າບໍ່ແມ່ນລະດັບຜູ້ບໍລິຫານ (Executive class), ມັກຈະເສຍປຽບໃນການເຈລະຈາກັບພາກສ່ວນທຸລະກິດອື່ນ.
• ເວລາທີ່ຜູ້ສະໜັບສະໜູນອຸທິດໃຫ້ CoE — ຕ້ອງກຳນົດເວລາທີ່ຊັດເຈນ ເຊັ່ນ: ການທົບທວນວຽກປະຈຳເດືອນ, ການລາຍງານຕໍ່ກອງປະຊຸມບໍລິຫານທຸກໄຕມາດ, ແລະ ການທົບທວນນະໂຍບາຍປະຈຳປີ.
• ເສັ້ນທາງການສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ (Escalation path) — ກຳນົດເສັ້ນທາງໃນການສົ່ງບັນຫາທີ່ CoE ບໍ່ສາມາດແກ້ໄຂໄດ້ (ຄວາມຂັດແຍ່ງທາງຜົນປະໂຫຍດລະຫວ່າງພະແນກ, ການຕັດສິນໃຈລົງທຶນຂະໜາດໃຫຍ່, ການຕັດສິນໃຈຖອນຕົວ) ໃຫ້ຜູ້ສະໜັບສະໜູນຮັບຊາບລ່ວງໜ້າ.
• ຄວາມຮັບຜິດຊອບໃນການສື່ສານ — ຜູ້ສະໜັບສະໜູນມີບົດບາດໃນການສື່ສານຄວາມສຳຄັນຂອງ CoE ຕໍ່ພາຍນອກ (ພາຍໃນ ແລະ ພາຍນອກບໍລິສັດ). ການທີ່ຜູ້ສະໜັບສະໜູນເປັນຜູ້ສື່ສານເອງ ຈະຊ່ວຍໃຫ້ການຮັບຮູ້ພາຍໃນອົງກອນກວ້າງຂວາງກວ່າການທີ່ CoE ສື່ສານດ້ວຍຕົນເອງ.

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

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

ຈັດລະບຽບຄວາມແຕກຕ່າງຂອງ 2 ຮູບແບບຕົວຢ່າງດັ່ງນີ້:

ແນວທາງໃນການເລືອກ:

• ຂະໜາດສາຂານ້ອຍຫາປານກາງ, ໃຫ້ຄວາມສຳຄັນກັບການກຳກັບດູແລຂອງສຳນັກງານໃຫຍ່ → ຮູບແບບ Hub & Spoke
• ຂະໜາດສາຂາໃຫຍ່, ໃຫ້ຄວາມສຳຄັນກັບຄວາມໄວໃນທ້ອງຖິ່ນ, ກົດໝາຍ ແລະ ລະບຽບການຂອງແຕ່ລະປະເທດມີຄວາມແຕກຕ່າງກັນຫຼາຍ → ຮູບແບບ Federation
• ການເລີ່ມຕົ້ນໃນໄລຍະທຳອິດໃຊ້ຮູບແບບ Hub & Spoke, ເມື່ອເຕີບໃຫຍ່ແລ້ວຈຶ່ງປ່ຽນໄປສູ່ຮູບແບບ Federation ກໍເປັນວິທີການທີ່ເປັນໄປໄດ້ໃນທາງປະຕິບັດ

ບໍລິສັດຍີ່ປຸ່ນທີ່ເຂົ້າສູ່ຕະຫຼາດ ASEAN ໃນໄລຍະເລີ່ມຕົ້ນເຖິງໄລຍະກາງ ສ່ວນຫຼາຍມັກເລີ່ມຕົ້ນຈາກຮູບແບບ Hub & Spoke.

ບໍ່ວ່າຈະເລືອກຮູບແບບ Hub & Spoke ຫຼື Federation, ການອອກແບບສ່ວນເຊື່ອມຕໍ່ (Interface) ລະຫວ່າງ CoE ຂອງສຳນັກງານໃຫຍ່ ແລະ ບໍລິສັດສາຂາໃນທ້ອງຖິ່ນ ຈະເປັນ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ທີ່ກຳນົດປະສິດທິພາບຂອງ CoE.

ສ່ວນເຊື່ອມຕໍ່ຫຼັກທີ່ຕ້ອງອອກແບບມີດັ່ງນີ້:

• ການສື່ສານຕາມກຳນົດເວລາ — ການທົບທວນປະຈຳເດືອນ (ທຸກສາຂາເຂົ້າຮ່ວມ, ໃຊ້ພາສາອັງກິດ ຫຼື ມີການແປພາສາອັງກິດ-ຍີ່ປຸ່ນ), ການປະຊຸມດຳເນີນງານປະຈຳອາທິດ (ພາຍໃນ CoE), ແລະ ການລາຍງານຕໍ່ຜູ້ສະໜັບສະໜູນ (Sponsor) ປະຈຳໄຕມາດ.
• ແພລັດຟອມແບ່ງປັນຄວາມຮູ້ — ເຄື່ອງມືພາຍໃນອົງກອນສຳລັບບໍລິຫານຈັດການບັນຊີລາຍຊື່ Use Case, ລາຍງານ PoC, ແລະ ຊຸດແມ່ແບບ (Template) ໄວ້ໃນບ່ອນດຽວ. ການຄົ້ນຫາ ແລະ ການຕັ້ງຄ່າສິດທິການເຂົ້າເຖິງແມ່ນມີຄວາມສຳຄັນຫຼາຍ.
• ເສັ້ນທາງການຍົກລະດັບບັນຫາ (Escalation Path) — ເສັ້ນທາງສຳລັບກໍລະນີທີ່ສາຂາໃນທ້ອງຖິ່ນບໍ່ສາມາດຕັດສິນໃຈເອງໄດ້ (ການລົງທຶນຂະໜາດໃຫຍ່, ການຍົກເວັ້ນໃນການເລືອກ Vendor, ຄວາມສ່ຽງດ້ານກົດລະບຽບ) ເພື່ອສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ CoE ຂອງສຳນັກງານໃຫຍ່ ແລະ ຜູ້ສະໜັບສະໜູນ. ຄວນລະບຸໄລຍະເວລາທີ່ຄາດວ່າຈະໃຊ້ໃຫ້ຊັດເຈນ.
• ການຄຳນຶງເຖິງພາສາ ແລະ ເວລາທີ່ແຕກຕ່າງກັນ — ກຳນົດພາສາກາງໃຫ້ເປັນພາສາອັງກິດ ຫຼື ພາສາຍີ່ປຸ່ນ ແລະ ໃຫ້ CoE ສະໜອງການຊ່ວຍເຫຼືອດ້ານການແປພາສາ. ເວລາປະຊຸມຄວນຍຶດເອົາຊ່ວງເວລາທີ່ Core Time ຂອງແຕ່ລະປະເທດຊ້ອນທັບກັນເປັນຫຼັກ (ຕົວຢ່າງ: ຖ້າເປັນໄທ ແລະ ຍີ່ປຸ່ນ ແມ່ນເວລາ 14:00–17:00 ຕາມເວລາປະເທດໄທ).
• ການກຳນົດບົດບາດຂອງຜູ້ປະສານງານ — ບັນທຶກພາລະກິດ ແລະ ຕົວຊີ້ວັດການປະເມີນຜົນຂອງຜູ້ປະສານງານ CoE ທີ່ປະຈຳຢູ່ແຕ່ລະສາຂາ. ຄວນລະບຸອັດຕາສ່ວນການເຮັດວຽກຄວບຄູ່ກັບວຽກຫຼັກ (ແນະນຳທີ່ 20–40%) ໃຫ້ຊັດເຈນ.

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

ຂັ້ນຕອນທີ 3 ແມ່ນການຈັດຕັ້ງຄວາມຮູ້ ແລະ ປຶ້ມຄູ່ມື (Playbook) ໃຫ້ເປັນຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງ CoE. ການເຮັດໃຫ້ຄວາມຮູ້ທີ່ຢູ່ໃນຫົວຂອງບຸກຄົນສາມາດນຳມາໃຊ້ຊ້ຳໄດ້ໃນລະດັບອົງກອນ ຄືຄວາມໝາຍທີ່ແທ້ຈິງຂອງການມີຢູ່ຂອງ CoE.

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

ລາຍການທີ່ຄວນບັນທຶກໄວ້ໃນບັນຊີລາຍຊື່ Use Case ເປັນຢ່າງໜ້ອຍ:

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

ບັນຊີລາຍຊື່ດັ່ງກ່າວຄວນມີການກວດສອບທຸກໆໄຕມາດ ແລະ ສຳລັບ Use Case ທີ່ຢຸດສະງັກ (ສະຖານະບໍ່ມີການປ່ຽນແປງເກີນເຄິ່ງປີ) ຄວນມີການຕັດສິນໃຈໃຫ້ຍົກເລີກ. ຖ້າຂໍ້ມູນໃນບັນຊີລາຍຊື່ບໍ່ເປັນປັດຈຸບັນ, ຄວາມໜ້າເຊື່ອຖືຂອງໜ້າທີ່ການກຳກັບດູແລ (Governance) ຂອງ CoE ທັງໝົດຈະຫຼຸດລົງ.

ບັນຊີລາຍຊື່ Use Case ແມ່ນຊັບສິນທີ່ພື້ນຖານ ແລະ ສຳຄັນທີ່ສຸດຂອງ CoE, ຂໍແນະນຳໃຫ້ກຳນົດຂະບວນການດຳເນີນງານໃຫ້ຊັດເຈນກ່ອນການເລືອກໃຊ້ເຄື່ອງມື.

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

ກຸ່ມແມ່ແບບທີ່ຄວນຈັດຕຽມ:

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

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

ແມ່ແບບເປັນສິ່ງທີ່ມີການປ່ຽນແປງຢູ່ສະເໝີ. ຄວນເກັບກຳຄຳຕິຊົມຈາກສາຂາທີ່ນຳໄປໃຊ້ເພື່ອປັບປຸງທຸກໆໄຕມາດ. ຄວນຮັກສາປະຫວັດການແກ້ໄຂໄວ້ ເພື່ອໃຫ້ສາມາດເຫັນຄວາມແຕກຕ່າງຈາກສະບັບກ່ອນໜ້າໄດ້.

ຂັ້ນຕອນທີ 4 ແມ່ນການອອກແບບຂະບວນການກວດສອບແບບແນວນອນ ຫຼື Horizontal ແລະ KPI ເພື່ອເຮັດໃຫ້ກິດຈະກຳຂອງ CoE ສາມາດວັດແທກໄດ້ໃນລະດັບອົງກອນ. CoE ທີ່ບໍ່ມີການບໍລິຫານຈັດການ ແລະ ການວັດແທກຜົນທີ່ມີປະສິດທິພາບ ຈະຖືກເບິ່ງວ່າເປັນ "ພະແນກທີ່ບໍ່ຮູ້ວ່າກຳລັງເຮັດຫຍັງຢູ່" ພາຍໃນໄລຍະເວລາ 6 ເດືອນ ຫາ 1 ປີ ເຊິ່ງຈະສົ່ງຜົນໃຫ້ງົບປະມານຖືກຕັດອອກ.

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

ຂະບວນການກວດສອບຫຼັກ:

• ການກວດສອບການລົງທຶນ — ການລົງທຶນດ້ານ AI ທີ່ມີມູນຄ່າເກີນຈຳນວນທີ່ກຳນົດ (ຕົວຢ່າງ: 3 ລ້ານເຢນ / 100,000 USD) ຕ້ອງຜ່ານການກວດສອບຈາກ CoE. ໂດຍຈະມີການກວດສອບຄວາມຊ້ຳຊ້ອນ, ທາງເລືອກອື່ນ ແລະ ROI.
• ການກວດສອບຄວາມສ່ຽງ — ລະບົບ AI ທີ່ຈັດການກັບຂໍ້ມູນສ່ວນບຸກຄົນ, ຂໍ້ມູນທີ່ມີຄວາມລະອຽດອ່ອນ ຫຼື ລະບົບ AI ທີ່ ເປີດຕົວ ຫຼື Launch ສູ່ສາທາລະນະ ຕ້ອງຜ່ານການກວດສອບຄວາມສ່ຽງລ່ວງໜ້າ. ໂດຍຈະມີການທົບທວນໂດຍລວມທັງໃນດ້ານກົດໝາຍ, ຄວາມປອດໄພ ແລະ ຈັນຍາບັນ.
• ການກວດສອບຜູ້ໃຫ້ບໍລິການ (Vendor) — ດຳເນີນການປະເມີນຜົນເມື່ອມີການຮັບຜູ້ໃຫ້ບໍລິການລາຍໃໝ່ ແລະ ທົບທວນຄືນປະຈຳປີສຳລັບຜູ້ໃຫ້ບໍລິການທີ່ມີສັນຍາຢູ່ແລ້ວ.
• ການກວດສອບຄວາມຊ້ຳຊ້ອນ — ໃນເວລາເລີ່ມຕົ້ນ PoC ໃໝ່, CoE ຈະກວດສອບຄວາມຊ້ຳຊ້ອນກັບບັນຊີລາຍຊື່ກໍລະນີການນຳໃຊ້ (Use case) ທີ່ມີຢູ່. ຖ້າພົບຄວາມຊ້ຳຊ້ອນ, ຈະແນະນຳໃຫ້ເຂົ້າຮ່ວມໂຄງການທີ່ມີຢູ່ແລ້ວ.
• ຂະບວນການຍື່ນຄຳຮ້ອງຂໍຍົກເວັ້ນ — ເສັ້ນທາງການຍື່ນຄຳຮ້ອງເພື່ອຫຼີກລ່ຽງຂະບວນການມາດຕະຖານໃນກໍລະນີສຸກເສີນ ຫຼື ສະຖານະການພິເສດ. ຕ້ອງໄດ້ຮັບການອະນຸມັດຈາກຜູ້ສະໜັບສະໜູນ (Sponsor) ແລະ ມີການທົບທວນພາຍຫຼັງເພື່ອເຮັດໃຫ້ການສະສົມຂອງກໍລະນີຍົກເວັ້ນສາມາດເບິ່ງເຫັນໄດ້.

ຂະບວນການກວດສອບຈະບໍ່ຖືກນຳໃຊ້ເປັນ "ເບຣກ" ແຕ່ຈະຖືກນຳໃຊ້ເປັນ "ການຮັບປະກັນຄຸນນະພາບ". ຕ້ອງມີການລະບຸໄລຍະເວລາໃນການອະນຸມັດໃຫ້ຊັດເຈນໃນຮູບແບບ SLA (ຕົວຢ່າງ: ການກວດສອບການລົງທຶນຕ້ອງສຳເລັດພາຍໃນ 2 ອາທິດ) ເພື່ອໃຫ້ເກີດຄວາມສົມດຸນລະຫວ່າງຄວາມວ່ອງໄວ ແລະ ການກຳກັບດູແລ (Governance).

ການເກັບບັນທຶກການກວດສອບ ແລະ ການວິເຄາະເຫດຜົນທີ່ມັກຖືກປະຕິເສດການອະນຸມັດ ຈະກາຍເປັນຂໍ້ມູນນຳເຂົ້າ (Input) ເພື່ອປັບປຸງແມ່ແບບ (Template) ແລະ ໂຄງການຝຶກອົບຮົມໃຫ້ດີຂຶ້ນ.

ຖ້າດຳເນີນງານ CoE ໂດຍບໍ່ມີ KPI, ກິດຈະກຳຕ່າງໆຈະບໍ່ເຫັນຜົນໃນນາມອົງກອນ. KPI ຄວນຖືກອອກແບບເປັນໂຄງສ້າງ 4 ຊັ້ນ ແລະ ປະເມີນຜົນລວມໂດຍການລວມແຕ່ລະຊັ້ນເຂົ້າດ້ວຍກັນ.

ຄວາມຜິດພາດທີ່ມັກພົບໃນການອອກແບບ KPI:

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

KPI ຄວນໄດ້ຮັບການເຫັນດີຈາກຜູ້ສະໜັບສະໜູນລະດັບບໍລິຫານໃນຕອນເລີ່ມຕົ້ນ CoE ແລະ ຄວນມີການທົບທວນຄືນທຸກໆໄຕມາດ. CoE ໃດທີ່ຍັງໃຊ້ KPI ເດີມຕະຫຼອດໄລຍະເວລາ 3 ປີ ມີຄວາມເປັນໄປໄດ້ສູງທີ່ອົງກອນນັ້ນກຳລັງຢຸດສະງັກ.

ຈັດລຽງລຳດັບຄວາມຜິດພາດທີ່ມັກພົບເລື້ອຍໃນໄລຍະເລີ່ມຕົ້ນການສ້າງຕັ້ງ CoE ໄປຈົນເຖິງໄລຍະການດຳເນີນງານ ພ້ອມກັບມາດຕະການແກ້ໄຂດັ່ງນີ້:

1. ແມ່ແບບທີ່ສຳນັກງານໃຫຍ່ເປັນຜູ້ກຳນົດກາຍເປັນພຽງຮູບແບບທີ່ບໍ່ມີປະສິດທິພາບໃນພື້ນທີ່ — ພະນັກງານໃນພື້ນທີ່ເກີດຄວາມບໍ່ພໍໃຈທີ່ຕ້ອງໃຊ້ແມ່ແບບການອອກແບບ PoC ທີ່ບໍ່ເໝາະສົມກັບວຽກງານຕົວຈິງທີ່ສ້າງຂຶ້ນໃນໄທ. ມາດຕະການແກ້ໄຂ: ໃນຂັ້ນຕອນການກຳນົດແມ່ແບບ ຄວນໃຫ້ຜູ້ຮັບຜິດຊອບການປະສານງານຈາກຫຼາຍສາຂາເຂົ້າຮ່ວມເປັນສະມາຊິກໃນໄລຍະເລີ່ມຕົ້ນ ແລະ ດຳເນີນການກວດສອບໂດຍພື້ນທີ່ໃນຂັ້ນຕອນເບຕ້າ.
2. CoE ກາຍເປັນ "ຜູ້ຊ່ວຍເຫຼືອທຸກຢ່າງ" — ເນື່ອງຈາກພາລະກິດບໍ່ຊັດເຈນ ຈຶ່ງເຮັດໃຫ້ເກີດສະພາວະ "ບັນຫາທຸກຢ່າງທີ່ກ່ຽວຂ້ອງກັບ AI ຕ້ອງສົ່ງໃຫ້ CoE" ເຮັດໃຫ້ຊັບພະຍາກອນກະຈັດກະຈາຍ. ມາດຕະການແກ້ໄຂ: ທົບທວນ "ຂອບເຂດທີ່ຮັບຜິດຊອບ ແລະ ບໍ່ຮັບຜິດຊອບ" ໃນ Step 1 ທຸກໆໄຕມາດ ແລະ ປະກາດໃຫ້ທົ່ວອົງກອນຮັບຊາບ.
3. ການກຳກັບດູແລຂອງສຳນັກງານໃຫຍ່ເຂັ້ມງວດເກີນໄປຈົນພື້ນທີ່ຕ້ອງຫາທາງຫຼີກລ່ຽງ — ຖ້າການກວດສອບຊັກຊ້າ ຫຼື ເຂັ້ມງວດເກີນໄປ ຈະເຮັດໃຫ້ເກີດ "Shadow AI" ທີ່ພື້ນທີ່ນຳໄປໃຊ້ງານເອງໃນຂະໜາດນ້ອຍໂດຍບໍ່ໄດ້ຮັບການອະນຸມັດເພີ່ມຂຶ້ນ. ມາດຕະການແກ້ໄຂ: ລະບຸ SLA ໃນການກວດສອບໃຫ້ຊັດເຈນ ແລະ ຈັດຕັ້ງເສັ້ນທາງການກວດສອບແບບງ່າຍສຳລັບໂຄງການຂະໜາດນ້ອຍ.
4. KPI ບໍ່ສາມາດສ້າງຜົນກະທົບຕໍ່ລະດັບຜູ້ບໍລິຫານ — ການລາຍງານພຽງແຕ່ປະລິມານກິດຈະກຳ ເຮັດໃຫ້ມູນຄ່າທາງທຸລະກິດບໍ່ຖືກສົ່ງຕໍ່ໄປ. ມາດຕະການແກ້ໄຂ: ຕ້ອງລວມເອົາ KPI ດ້ານມູນຄ່າທາງທຸລະກິດເຂົ້າໄປນຳສະເໝີ ແລະ ແປຜົນໃຫ້ເປັນຕົວຊີ້ວັດທາງການເງິນທີ່ CFO ຫຼື CEO ໃຫ້ຄວາມສົນໃຈ (ຍອດຂາຍ, ຕົ້ນທຶນ, ຄວາມພໍໃຈຂອງລູກຄ້າ).
5. ຜູ້ຮັບຜິດຊອບການປະສານງານອິດເມື່ອຍຈາກການເຮັດວຽກຄວບຕຳແໜ່ງ — ຜູ້ຮັບຜິດຊອບການປະສານງານໃນພື້ນທີ່ມີອັດຕາການເຮັດວຽກຄວບຕຳແໜ່ງຫຼັກເກີນ 80% ເຮັດໃຫ້ກິດຈະກຳຂອງ CoE ຖືກຈັດໄວ້ໃນລຳດັບຄວາມສຳຄັນຫຼັງໆ. ມາດຕະການແກ້ໄຂ: ຕົກລົງອັດຕາສູງສຸດຂອງການເຮັດວຽກຄວບຕຳແໜ່ງ (ຕົວຢ່າງ: 40%) ລະຫວ່າງສຳນັກງານໃຫຍ່ກັບພື້ນທີ່ ແລະ ຕິດຕາມກວດສອບຢ່າງສະໝ່ຳສະເໝີ.
6. ຕຳແໜ່ງຂອງ CoE ສັ່ນຄອນເມື່ອມີການປ່ຽນແປງຜູ້ສະໜັບສະໜູນ — ເມື່ອມີການປ່ຽນແປງຜູ້ບໍລິຫານລະດັບສູງ ແລະ ຜູ້ສະໜັບສະໜູນປ່ຽນໜ້າໄປ ຈະເຮັດໃຫ້ CoE ສູນເສຍການສະໜັບສະໜູນ. ມາດຕະການແກ້ໄຂ: ກຽມເອກະສານສົ່ງມອບງານ (ຜົນງານໃນອະດີດ, ບັນຫາໃນປັດຈຸບັນ, ແຜນການໃນ 1 ປີຂ້າງໜ້າ) ໄວ້ລ່ວງໜ້າໃນສະພາວະປົກກະຕິ.

Q1: ການສ້າງຕັ້ງ CoE ຄວນມີຂະໜາດຈັກຄົນຈຶ່ງຈະເໝາະສົມ?

ໃນໄລຍະເລີ່ມຕົ້ນ, ມັກຈະເຫັນຕົວຢ່າງການເລີ່ມຕົ້ນດ້ວຍພະນັກງານປະຈຳ 3-5 ຄົນ ແລະ ລວມພະນັກງານທີ່ເຮັດວຽກຄວບຕຳແໜ່ງອີກປະມານ 5-10 ຄົນ. ໂຄງສ້າງພື້ນຖານປະກອບດ້ວຍ ຫົວໜ້າທີມ (Full-time), ຜູ້ຮັບຜິດຊອບດ້ານມາດຕະຖານ ແລະ ຄວາມຮູ້, ຜູ້ຮັບຜິດຊອບດ້ານການກຳກັບດູແລ (Governance), ຜູ້ຮັບຜິດຊອບດ້ານການຝຶກອົບຮົມ, ແລະ ຜູ້ຮັບຜິດຊອບການປະສານງານແຕ່ລະສາຂາ (ເຮັດວຽກຄວບຕຳແໜ່ງ 20-40%). ການສ້າງ CoE ຂະໜາດໃຫຍ່ທີ່ມີພະນັກງານເຖິງ 30 ຄົນນັ້ນ ຄວນຕັ້ງເປົ້າໝາຍໄວ້ໃນໄລຍະທີ່ອົງກອນມີຄວາມພ້ອມດ້ານການຂັບເຄື່ອນ AI ແລ້ວ (ປະມານ 2-3 ປີຫຼັງຈາກເລີ່ມຕົ້ນ) ຈຶ່ງຈະມີຄວາມເປັນໄປໄດ້ຫຼາຍກວ່າ.

Q2: CoE ຄວນຢູ່ພາຍໃຕ້ພະແນກໃດ?

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

Q3: ໃນກໍລະນີທີ່ແຕ່ລະສາຂາໄດ້ເລີ່ມຂັບເຄື່ອນ AI ໄປແລ້ວ, ການສ້າງ CoE ຕາມຫຼັງຍັງມີຄວາມໝາຍຢູ່ບໍ?

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

Q4: ຖ້າສະຖານະການຂັບເຄື່ອນ AI ຂອງສາຂາໃນ ASEAN ເຊັ່ນ: ໄທ, ຫວຽດນາມ, ອິນໂດເນເຊຍ ມີຄວາມແຕກຕ່າງກັນ, ຄວນອອກແບບແນວໃດ?

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

Q5: ຄວນໃຊ້ເວລາຈັກປີໃນການຕັດສິນຄວາມສຳເລັດ ຫຼື ຄວາມລົ້ມເຫຼວຂອງ CoE?

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

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

• ຂັ້ນຕອນທີ 1: ການກຳນົດພາລະກິດ ແລະ ຂອບເຂດ (Mission and Scope) — ລະບຸຂອບເຂດວຽກທີ່ຮັບຜິດຊອບ ແລະ ບໍ່ຮັບຜິດຊອບໃຫ້ຊັດເຈນ, ພ້ອມທັງກຳນົດຜູ້ສະໜັບສະໜູນໃນລະດັບບໍລິຫານ. ເພື່ອປ້ອງກັນບໍ່ໃຫ້ກາຍເປັນ "ຜູ້ຊ່ວຍເຫຼືອທຸກຢ່າງທີ່ແບກຮັບທຸກວຽກ".
• ຂັ້ນຕອນທີ 2: ການອອກແບບໂຄງສ້າງອົງກອນ ແລະ ການແບ່ງໜ້າທີ່ — ເລືອກຮູບແບບ Hub & Spoke ຫຼື Federation ໂດຍອີງຕາມຂະໜາດຂອງບໍລິສັດ ແລະ ຈຳນວນສາຂາ, ພ້ອມທັງອອກແບບການເຊື່ອມຕໍ່ລະຫວ່າງສຳນັກງານໃຫຍ່ ແລະ ທ້ອງຖິ່ນ.
• ຂັ້ນຕອນທີ 3: ການລວບລວມຄວາມຮູ້ ແລະ ການຈັດຕຽມ Playbook — ຈັດຕຽມບັນຊີລາຍຊື່ກໍລະນີການນຳໃຊ້ (Use Case) ແລະ ຊຸດແມ່ແບບມາດຕະຖານ ເພື່ອເຮັດໃຫ້ການຂະຫຍາຍຜົນໃນວົງກວ້າງສາມາດເກີດຂຶ້ນໄດ້ຢ່າງເປັນຮູບປະທຳໃນອົງກອນ.
• ຂັ້ນຕອນທີ 4: ການກຳກັບດູແລ ແລະ ການວັດແທກຜົນ — ເຮັດໃຫ້ກິດຈະກຳຕ່າງໆສາມາດເບິ່ງເຫັນໄດ້ຜ່ານຂະບວນການກວດສອບແບບຂ້າມສາຍງານ ແລະ KPI 4 ຊັ້ນ, ພ້ອມທັງປະເມີນທັງໃນດ້ານຄວາມສ່ຽງ ແລະ ມູນຄ່າທາງທຸລະກິດ.

CoE ເປັນອົງກອນທີ່ຍາກຈະປະເມີນຜົນດ້ວຍຕົວຊີ້ວັດໄລຍະສັ້ນ, ແຕ່ມັນມີບົດບາດສຳຄັນໃນການແກ້ໄຂບັນຫາຄວາມຊ້ຳຊ້ອນ, ຊ່ອງວ່າງ ແລະ ການເຮັດວຽກແບບແຍກສ່ວນ (Silo) ຂອງການລົງທຶນດ້ານ AI ໃນການດຳເນີນງານຫຼາຍສາຂາທົ່ວ ASEAN. ການຍອມຮັບໄລຍະເລີ່ມຕົ້ນ 18-24 ເດືອນ ເປັນໄລຍະສ້າງຕົວ ແລະ ການມີທັດສະນະຄະຕິໃນການທົບທວນການອອກແບບທຸກໆໄຕມາດ ຈະເປັນປັດໄຈຕັດສິນຄວາມສຳເລັດໃນໄລຍະຍາວ.

ສຳລັບບົດຄວາມທີ່ກ່ຽວຂ້ອງ, ຂໍໃຫ້ອ້າງອີງເຖິງ ອົງກອນ AI-Native ແລະ ບົດບາດຂອງ Chief AI Officer ເຊິ່ງກ່າວເຖິງການອອກແບບບົດບາດຂອງຜູ້ບໍລິຫານ, AgentOps ແມ່ນຫຍັງ — ຄູ່ມືການອອກແບບອົງກອນປະຕິບັດການ AI Agent ເຊິ່ງກ່າວເຖິງອົງກອນປະຕິບັດການ AI Agent, ແລະ ຄູ່ມືການສ້າງລະບົບການກຳກັບດູແລ AI ສຳລັບບໍລິສັດທີ່ຂະຫຍາຍຕົວເຂົ້າສູ່ ASEAN ເຊິ່ງໄດ້ຮວບຮວມກົດລະບຽບດ້ານ AI ຂອງແຕ່ລະປະເທດໃນ ASEAN.