ວິທີອັດຕະໂນມັດການຈັດຊື້ B2B ດ້ວຍ AI Agent — ຂັ້ນຕອນການເລືອກຜູ້ສະໜອງ ແລະ ອອກ PO ໂດຍອັດຕະໂນມັດສຳລັບອຸດສາຫະກຳການຜະລິດໃນໄທ

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

ຕົວແທນການຈັດຊື້ແບບ B2B ບໍ່ແມ່ນຮູບແບບການພັດທະນາຂອງ "RPA + Chatbot". ມັນສາມາດເອີ້ນໃຊ້ເຄື່ອງມືຫຼາຍຢ່າງ (ERP, Supplier API, Email Client) ໄດ້ຢ່າງອິດສະຫຼະ ແລະ ປະຕິບັດວຽກງານຕັ້ງແຕ່ການຂໍໃບສະເໜີລາຄາ, ການປຽບທຽບ, ການຮ້ອງຂໍການອະນຸມັດ ຈົນເຖິງການອອກ PO ໃຫ້ສຳເລັດຕາມເປົ້າໝາຍ. ໃນທີ່ນີ້, ພວກເຮົາຈະສະຫຼຸບຄວາມແຕກຕ່າງຈາກວຽກງານການຈັດຊື້ແບບດັ້ງເດີມ ແລະ ຄວາມຕ້ອງການສະເພາະຂອງອຸດສາຫະກຳການຜະລິດໃນໄທ.

ວຽກງານການຈັດຊື້ແບບດັ້ງເດີມແມ່ນຮູບແບບ Workflow. ຜູ້ຊື້ຈະດຳເນີນການຕາມຂັ້ນຕອນທີ່ກຳນົດໄວ້ຄື: ສ້າງ RFQ → ຮ້ອງຂໍໃບສະເໜີລາຄາຈາກ 3 ບໍລິສັດ → ສ້າງຕາຕະລາງປຽບທຽບໃນ Excel → ຂໍການອະນຸມັດຈາກຫົວໜ້າ → ອອກ PO ໃນ ERP. RPA ເປັນພຽງການອັດຕະໂນມັດໃນລະດັບ "ການຄັດລອກຂໍ້ມູນໃນ Excel" ເທົ່ານັ້ນ, ສ່ວນການຕັດສິນໃຈຕ່າງໆ ເຊັ່ນ: ການປັບແຕ່ງເນື້ອໃນໃບສະເໜີລາຄາໃຫ້ເໝາະສົມກັບຜູ້ສະໜອງແຕ່ລະລາຍ ຫຼື ການພິຈາລະນາຊິ້ນສ່ວນທົດແທນໃນກໍລະນີສິນຄ້າຂາດສະຕັອກ ແມ່ນຍັງຕ້ອງອາໄສມະນຸດເປັນຜູ້ຈັດການ.

AI Agent ແມ່ນຮູບແບບການບັນລຸເປົ້າໝາຍ. ເມື່ອໃຫ້ເປົ້າໝາຍວ່າ "ຕ້ອງການຮຸ່ນ X-201 ຈຳນວນ 2,000 ຊິ້ນ, ກຳນົດສົ່ງພາຍໃນ 4 ອາທິດ, ງົບປະມານບໍ່ເກີນ 500,000 ບາດ", ມັນຈະເລືອກຜູ້ສະໜອງທີ່ມີສັກກະຍະພາບສູງສຸດ 3 ລາຍຈາກຂໍ້ມູນການຊື້ຂາຍໃນອະດີດ, ສ້າງເນື້ອໃນອີເມວໃຫ້ສອດຄ່ອງກັບພາສາ ແລະ ວັດທະນະທຳການຄ້າຂອງແຕ່ລະລາຍ, ພ້ອມທັງວິເຄາະຄຳຕອບເພື່ອສ້າງຕາຕະລາງປຽບທຽບ. ການອອກແບບນີ້ເຮັດໃຫ້ສາມາດສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ມະນຸດສະເພາະກໍລະນີຍົກເວັ້ນເທົ່ານັ້ນ (ເຊັ່ນ: ງົບປະມານເກີນ, ກຳນົດສົ່ງບໍ່ຕົງ, ຫຼື ຜູ້ສະໜອງລາຍໃໝ່).

ການອັດຕະໂນມັດໃນການຈັດຊື້ຂອງອຸດສາຫະກຳການຜະລິດໃນໄທ ມີ 3 ຄວາມຕ້ອງການທີ່ສຳນັກງານໃຫຍ່ໃນຍີ່ປຸ່ນບໍ່ມີ:

1. ການຮອງຮັບຫຼາຍສະກຸນເງິນ: ມີການປະສົມປະສານກັນລະຫວ່າງຊິ້ນສ່ວນຈາກຈີນ (CNY), ວັດຖຸດິບຈາກອົດສະຕຣາລີ (AUD), ຜູ້ສະໜອງໃນທ້ອງຖິ່ນ (THB) ແລະ ຊິ້ນສ່ວນພິເສດທີ່ຜ່ານສຳນັກງານໃຫຍ່ (JPY). ຈຳເປັນຕ້ອງມີກົນໄກໃນການດຶງອັດຕາແລກປ່ຽນ ແລະ ປັບໃຫ້ເປັນມາດຕະຖານດຽວກັນເພື່ອໃຫ້ສາມາດປຽບທຽບໄດ້.
2. ການຮອງຮັບຜູ້ສະໜອງຫຼາຍພາສາ: ມີການປະສົມປະສານກັນຂອງອີເມວພາສາໄທ, ພາສາອັງກິດ, ພາສາຈີນ ແລະ ພາສາຍີ່ປຸ່ນ. ຈຳເປັນຕ້ອງມີຂະບວນການສ້າງໃບສະເໜີລາຄາໃຫ້ກົງກັບພາສາທີ່ຜູ້ສະໜອງໃຊ້ ແລະ ປ່ຽນຂໍ້ມູນການຕອບກັບໃຫ້ເປັນຂໍ້ມູນທີ່ມີໂຄງສ້າງ.
3. ການກວດສອບອັດຕະໂນມັດຕາມຂໍ້ກຳນົດ AEO ແລະ ການພາສີ: ພາຍໃຕ້ລະບົບ Authorized Economic Operator ຂອງໄທ, ຈຳເປັນຕ້ອງມີການບັນທຶກລະຫັດ HS, ປະເທດຕົ້ນກຳເນີດ ແລະ ການຈັດປະເພດພາສີຂອງຊິ້ນສ່ວນທີ່ນຳເຂົ້າໃນເວລາທີ່ຊື້. ຕ້ອງມີການຕິດຕັ້ງກົນໄກກວດສອບອັດຕະໂນມັດວ່າລາຍການເຫຼົ່ານີ້ຄົບຖ້ວນຫຼືບໍ່ ກ່ອນທີ່ຈະມີການສັ່ງຊື້.

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

ໃນອຸດສາຫະກຳການຜະລິດຂອງໄທ, ໄລຍະເວລາໃນການຈັດຊື້ຊິ້ນສ່ວນແມ່ນປັດໄຈທີ່ກຳນົດໄລຍະເວລາໃນການສົ່ງອອກສິນຄ້າ. ຜູ້ຜະລິດຊິ້ນສ່ວນລົດຍົນ ແລະ ຜູ້ຜະລິດອຸປະກອນອີເລັກໂທຣນິກຂອງຍີ່ປຸ່ນ ຈຳເປັນຕ້ອງດຳເນີນການຕັ້ງແຕ່ການຮ້ອງຂໍໃບສະເໜີລາຄາ (RFQ) ໄປຈົນເຖິງການຢືນຢັນການສັ່ງຊື້ກັບຜູ້ສະໜອງໃຫ້ສຳເລັດພາຍໃນບໍ່ເທົ່າໃດມື້ ເພື່ອຮັກສາລະບົບການຜະລິດແບບ Just-in-time.

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

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

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

ການນຳໃຊ້ຕົວແທນຈັດຊື້ (Procurement Agent) ບໍ່ຄວນເລີ່ມຕົ້ນດ້ວຍການຈັດຕັ້ງປະຕິບັດຕົວແທນໃນທັນທີ. ການອອກແບບການເຊື່ອມຕໍ່ ຫຼື ຊິງຄ໌ຂໍ້ມູນກັບລະບົບຫຼັກ (Core System) ແລະ ການປັບປຸງຖານຂໍ້ມູນຜູ້ສະໜອງ (Supplier Master) ແມ່ນປັດໄຈທີ່ຕັດສິນຄວາມສຳເລັດຂອງໂຄງການທັງໝົດ. ຕໍ່ໄປນີ້ແມ່ນການຈັດລຽງລາຍການກຽມຄວາມພ້ອມທີ່ເປັນເງື່ອນໄຂເບື້ອງຕົ້ນ.

ຕົວແທນການຈັດຊື້ (Procurement Agent) ຈະບໍ່ເຮັດວຽກໂດຍລຳພັງ. ມັນຈຳເປັນຕ້ອງມີການເຊື່ອມຕໍ່ ຫຼື ຊິງຄ໌ຂໍ້ມູນແບບສອງທາງກັບລະບົບ ERP ທີ່ມີຢູ່ (SAP, Oracle, Microsoft Dynamics, ERP ທ້ອງຖິ່ນ) ຫຼື ລະບົບການຈັດການການຈັດຊື້ (Coupa, Ariba, ລະບົບທີ່ພັດທະນາຂຶ້ນເອງ).

ການເຊື່ອມຕໍ່ທີ່ຈຳເປັນຢ່າງໜ້ອຍສາມາດແບ່ງອອກໄດ້ເປັນ 3 ປະເພດ:

ໃນກໍລະນີທີ່ການກຽມພ້ອມ API ຂອງຝັ່ງ ERP ບໍ່ພຽງພໍ, ໃຫ້ພິຈາລະນາການອອກແບບໂດຍຜ່ານ Read-only replica ຫຼື ຖານຂໍ້ມູນກາງ. ຖ້າຕົວແທນເຂົ້າໄປໃຊ້ງານ API ການຂຽນຂໍ້ມູນຂອງ ERP ໂດຍກົງ, ການເຮັດ Rollback ໃນກໍລະນີທີ່ເກີດການສັ່ງຊື້ຜິດພາດຈະເຮັດໄດ້ຍາກ. ການອອກ PO ຄວນແບ່ງອອກເປັນ 3 ຂັ້ນຕອນຄື: "ການສ້າງຮ່າງ → ການອະນຸມັດຂັ້ນສຸດທ້າຍໂດຍມະນຸດ → ການຂຽນຂໍ້ມູນລົງ ERP" ແລະ ການຈຳກັດສິດໃນການຂຽນຂໍ້ມູນໄວ້ສະເພາະຂັ້ນຕອນສຸດທ້າຍເທົ່ານັ້ນຈະມີຄວາມປອດໄພກວ່າ.

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

• Supplier Master: ປະຫວັດການເຮັດທຸລະກຳ, ຂະແໜງການທີ່ຊ່ຽວຊານ, ສະກຸນເງິນ/ພາສາທີ່ຮອງຮັບ, ຜົນງານດ້ານ Lead time, ຄະແນນຄຸນນະພາບ
• Catalog ຊິ້ນສ່ວນ: ເລກລຸ້ນ (Model number), ຊິ້ນສ່ວນທົດແທນ, ລະຫັດ HS, ແຫຼ່ງກຳເນີດສິນຄ້າ, ລາຄາຊື້ຄັ້ງຫຼ້າສຸດ, Supplier ທີ່ແນະນຳ
• ຂໍ້ມູນການເຮັດທຸລະກຳໃນອະດີດ: ປະຫວັດ PO ໃນຮອບ 2-3 ປີຜ່ານມາ. ໂດຍສະເພາະປະຫວັດການຕໍ່ລອງລາຄາແມ່ນມີຄວາມສຳຄັນຫຼາຍ

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

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

ເມື່ອຄຳຮ້ອງຂໍການຊື້ (PR: Purchase Request) ຖືກສົ່ງມາໃນຮູບແບບຂໍ້ມູນທີ່ບໍ່ມີໂຄງສ້າງ ເຊັ່ນ: "ການຂຽນແບບອິດສະຫຼະໃນ Excel" ຫຼື "ລາຍການໃນເນື້ອຫາອີເມວ", ເອເຈນ (Agent) ຈະບໍ່ສາມາດປະມວນຜົນໄດ້. ຂັ້ນຕອນທຳອິດແມ່ນການປັບປ່ຽນ PR ໃຫ້ເປັນໂຄງສ້າງສະກີມາ (Structured Schema) ທີ່ເປັນລະບຽບ.

ລາຍການທີ່ຈຳເປັນຂັ້ນຕໍ່າມີດັ່ງນີ້:

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

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

Tools the agent can call:
  - search_suppliers(item_code, quantity, currency, delivery_date) → ລາຍຊື່ຜູ້ສະໜອງທີ່ເປັນໄປໄດ້
  - get_supplier_history(supplier_id, item_code) → ປະຫວັດການຊື້ຂາຍຜ່ານມາ
  - get_supplier_capacity(supplier_id, delivery_date) → ຄວາມເໝາະສົມຂອງກຳນົດເວລາສົ່ງມອບ
  - calculate_score(supplier_id) → ຄະແນນລວມ

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

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

ສົ່ງຄຳຮ້ອງຂໍໃບສະເໜີລາຄາ (RFQ) ໄປຍັງຜູ້ສະໜອງທີ່ຖືກຄັດເລືອກ, ເກັບກຳຄຳຕອບ ແລະ ສ້າງຕາຕະລາງປຽບທຽບ. ສຸດທ້າຍແມ່ນດຳເນີນການອອກ PO.

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

ຫຼັງຈາກນຳໄປໃຊ້ງານຈິງແລ້ວ, ຮູບແບບຄວາມຜິດພາດທີ່ມັກເກີດຂຶ້ນມີ 2 ຢ່າງ ຄື: ຄວາມບົກຜ່ອງໃນການອອກແບບ HITL ແລະ ການຂາດແຄນບັນທຶກການກວດສອບ (Audit log). ທັງສອງຢ່າງນີ້ແມ່ນເບິ່ງເຫັນໄດ້ຍາກໃນຂັ້ນຕອນ PoC ແລະ ມັກຈະກາຍເປັນບັນຫາຫຼັງຈາກເລີ່ມເປີດຕົວ ຫຼື Launch ໃຊ້ງານ.

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

ແນວທາງໃນການອອກແບບຄື "ການແບ່ງຂະບວນການຕາມການປະສົມປະສານຂອງຈຳນວນເງິນ, ຜົນງານຂອງຜູ້ສະໜອງ ແລະ ທຸງຍົກເວັ້ນ (Exception flag)". ຕົວຢ່າງເຊັ່ນ: ການຕັ້ງຄ່າເກນ (Threshold) ດັ່ງຕໍ່ໄປນີ້ແມ່ນມີຄວາມເປັນໄປໄດ້ໃນການປະຕິບັດຈິງ:

• ຕ່ຳກວ່າ 500,000 ບາດ + ຜູ້ສະໜອງທີ່ມີຢູ່ແລ້ວ + ຢູ່ໃນງົບປະມານ → ອະນຸມັດອັດຕະໂນມັດ
• 500,000 - 2,000,000 ບາດ → ຫົວໜ້າພະແນກອະນຸມັດ (ແຈ້ງເຕືອນຜ່ານ Slack + ກົດປຸ່ມເພື່ອອະນຸມັດ)
• 2,000,000 ບາດຂຶ້ນໄປ, ຫຼື ຜູ້ສະໜອງລາຍໃໝ່, ຫຼື ເກີນງົບປະມານ → ຜູ້ອຳນວຍການຝ່າຍອະນຸມັດ
• ເສັ້ນທາງອະນຸມັດພິເສດສຳລັບກໍລະນີສຸກເສີນ (ຄວາມສ່ຽງຕໍ່ການຢຸດສາຍການຜະລິດ) → ເສັ້ນທາງແຍກຕ່າງຫາກ

ການແຈ້ງເຕືອນການຍົກລະດັບ (Escalation) ຄວນອອກແບບໃຫ້ສອດຄ່ອງກັບຈັງຫວະການເຮັດວຽກຂອງຜູ້ອະນຸມັດ. ເນື່ອງຈາກຜູ້ບໍລິຫານໃນອຸດສາຫະກຳການຜະລິດມັກຈະມີການປະຊຸມຫຼາຍ ແລະ ຕອບອີເມວຊ້າ, ນອກຈາກການແຈ້ງເຕືອນຜ່ານ Slack, LINE, ຫຼື Microsoft Teams ແລ້ວ, ຄວນມີກົນໄກສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ຜູ້ອະນຸມັດໃນລະດັບຖັດໄປໂດຍອັດຕະໂນມັດ ຫາກລາຍການນັ້ນຍັງບໍ່ທັນໄດ້ຮັບການອະນຸມັດພາຍໃນເວລາທີ່ກຳນົດ (ເຊັ່ນ: 6 ຊົ່ວໂມງ), ເຊິ່ງຈະຊ່ວຍໃຫ້ Lead time ມີຄວາມສະຖຽນຫຼາຍຂຶ້ນ.

ພາຍໃຕ້ລະບົບ Authorized Economic Operator ຂອງປະເທດໄທ, ມີຂໍ້ກຳນົດໃຫ້ເກັບຮັກສາປະຫວັດການເຮັດທຸລະກຳທີ່ກ່ຽວຂ້ອງກັບການນຳເຂົ້າໄວ້ໃນໄລຍະເວລາທີ່ກຳນົດ ແລະ ຕ້ອງນຳສະເໜີຕໍ່ເຈົ້າໜ້າທີ່ພາສີເມື່ອມີການກວດສອບ. ໃນກໍລະນີທີ່ບໍລິສັດທີ່ໄດ້ຮັບການຮັບຮອງ AEO (ຫຼື ບໍລິສັດທີ່ກຳລັງມຸ່ງຫວັງຈະໄດ້ຮັບການຮັບຮອງ) ນຳໃຊ້ຕົວແທນການຈັດຊື້ (Procurement Agent), ຈຳເປັນຕ້ອງເກັບຮັກສາບັນທຶກ (Log) ດັ່ງຕໍ່ໄປນີ້ໃນຮູບແບບທີ່ມີໂຄງສ້າງ:

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

ROI ຂອງຕົວແທນການຈັດຊື້ (Procurement Agent) ຈະຖືກປະເມີນຕໍ່າກວ່າຄວາມເປັນຈິງ ຖ້າວັດແທກພຽງແຕ່ "ການຫຼຸດຜ່ອນຕົ້ນທຶນ" ເທົ່ານັ້ນ. ການວັດແທກດ້ວຍ 3 ແກນຫຼັກຕໍ່ໄປນີ້ແມ່ນມີຄວາມເປັນຈິງຫຼາຍກວ່າ:

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

ຖ້າຫາກລວມ KPI ໃຫ້ເປັນໜ່ວຍທີ່ຝ່າຍບໍລິຫານສາມາດນຳໄປໃຊ້ໃນການລາຍງານການບໍລິຫານໄດ້ (ເຊັ່ນ: ຈຳນວນເງິນທີ່ຫຼຸດຜ່ອນຕົ້ນທຶນຕໍ່ປີ, ຄ່າສະເລ່ຍຂອງ Lead time ໃນການຈັດຊື້, ແລະ ອື່ນໆ) ຈະເຮັດໃຫ້ການຕັດສິນໃຈລົງທຶນເພີ່ມເຕີມເຮັດໄດ້ງ່າຍຂຶ້ນ.

ຕົວແທນການຈັດຊື້ແບບ B2B ບໍ່ແມ່ນ "ເວດມົນອັດຕະໂນມັດທັງໝົດ" ແຕ່ເປັນກົນໄກທີ່ຊ່ວຍໃຫ້ມະນຸດສາມາດສຸມໃສ່ການຈັດການກັບຂໍ້ຍົກເວັ້ນຕ່າງໆໄດ້. ເພື່ອໃຫ້ອຸດສາຫະກຳການຜະລິດໃນໄທນຳກົນໄກນີ້ໄປໃຊ້, ຈຳເປັນຕ້ອງໄດ້ກຳນົດການອອກແບບການເຊື່ອມຕໍ່ ERP, ການຈັດການຖານຂໍ້ມູນຜູ້ສະໜອງ (Supplier Master), ການກຳນົດເກນມາດຕະຖານຂອງ HITL ໃຫ້ຊັດເຈນ, ແລະ ການອອກແບບບັນທຶກການກວດສອບ (Audit Log) ທີ່ຮອງຮັບ AEO/PDPA ໃຫ້ສຳເລັດກ່ອນການນຳຕົວແທນໄປໃຊ້ງານຈິງ.

ສຳລັບບາດກ້າວທຳອິດ, ຄວນເລີ່ມຈາກການຈຳກັດຂອບເຂດໝວດໝູ່ການຈັດຊື້ພຽງ 1 ໝວດ (ຕົວຢ່າງ: ເຄື່ອງໃຊ້ສຳນັກງານທົ່ວໄປ, ຫຼື ກຸ່ມຊິ້ນສ່ວນສະເພາະ) ແລະ ດຳເນີນການ PoC ເປັນເວລາ 3-6 ເດືອນ ເພື່ອວັດແທກ "ຊົ່ວໂມງການເຮັດວຽກຂອງຜູ້ຊື້", "ໄລຍະເວລາໃນການດຳເນີນງານ (Lead time)", ແລະ "ອັດຕາການເກີດຂໍ້ຍົກເວັ້ນ". ເມື່ອຕົວຊີ້ວັດຕ່າງໆປັບຕົວດີຂຶ້ນໃນຂັ້ນຕອນ PoC, ການຂະຫຍາຍໄປສູ່ໝວດໝູ່ອື່ນຈະເປັນວິທີທີ່ສາມາດເພີ່ມປະສິດທິຜົນໄປພ້ອມກັບການຄວບຄຸມຄວາມສ່ຽງໃນການດຳເນີນງານໄດ້.

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