
B2B ຈັດຊື້ຕົວແທນ (B2B調達エージェント) ແມ່ນກົນໄກທີ່ AI Agent ຕັດສິນໃຈ ແລະ ດຳເນີນການຕາມລຳດັບວຽກງານຕັ້ງແຕ່ການຮັບຄຳຮ້ອງຂໍຊື້ ຈົນເຖິງການອອກ PO (ໃບສັ່ງຊື້) ຢ່າງອິດສະຫຼະ. ບົດຄວາມນີ້ມີຈຸດປະສົງເພື່ອແນະນຳຜູ້ຮັບຜິດຊອບດ້ານການຈັດຊື້ ແລະ ຜູ້ຮັບຜິດຊອບລະບົບຂໍ້ມູນຂ່າວສານໃນອຸດສາຫະກຳການຜະລິດຂອງໄທ ກ່ຽວກັບຂັ້ນຕອນການອອກແບບເພື່ອດຳເນີນການແບບອັດຕະໂນມັດ ຕັ້ງແຕ່ການສ້າງ RFQ, ການຄັດເລືອກຜູ້ສະໜອງ, ການປຽບທຽບໃບສະເໜີລາຄາ ຈົນເຖິງການອອກ PO. ເປົ້າໝາຍສູງສຸດແມ່ນເພື່ອບັນລຸສະພາວະທີ່ "ມະນຸດພຽງແຕ່ເຮັດໜ້າທີ່ອະນຸມັດກໍລະນີພິເສດເທົ່ານັ້ນ", ເຊິ່ງຈະຊ່ວຍຫຼຸດໄລຍະເວລາໃນການຈັດຊື້ (Lead time) ແລະ ຫຼຸດຜ່ອນຂັ້ນຕອນການເຮັດວຽກຂອງຜູ້ຊື້ໄປພ້ອມກັນ.
B2B ຈັດຊື້ຕົວແທນ (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 ລາຍຈາກຂໍ້ມູນການຊື້ຂາຍໃນອະດີດ, ສ້າງເນື້ອໃນອີເມວໃຫ້ສອດຄ່ອງກັບພາສາ ແລະ ວັດທະນະທຳການຄ້າຂອງແຕ່ລະລາຍ, ພ້ອມທັງວິເຄາະຄຳຕອບເພື່ອສ້າງຕາຕະລາງປຽບທຽບ. ການອອກແບບນີ້ເຮັດໃຫ້ສາມາດສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ມະນຸດສະເພາະກໍລະນີຍົກເວັ້ນເທົ່ານັ້ນ (ເຊັ່ນ: ງົບປະມານເກີນ, ກຳນົດສົ່ງບໍ່ຕົງ, ຫຼື ຜູ້ສະໜອງລາຍໃໝ່).
| ຫົວຂໍ້ | RPA / Workflow | AI Agent |
|---|---|---|
| ຮູບແບບການປະມວນຜົນ | ການອັດຕະໂນມັດຕາມຂັ້ນຕອນທີ່ກຳນົດ | ການປະຕິບັດງານແບບອິດສະຫຼະເພື່ອບັນລຸເປົ້າໝາຍ |
| ການຕັດສິນໃຈ | ມະນຸດ | Agent (ຍົກເວັ້ນກໍລະນີ HITL) |
| ການຕອບໂຕ້ຜູ້ສະໜອງ | ອີເມວແບບ Template | ສ້າງຂຶ້ນຕາມພາສາ ແລະ ວັດທະນະທຳການຄ້າ |
| ການຈັດການກໍລະນີຍົກເວັ້ນ | ມະນຸດທັງໝົດ | ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ຕາມລະດັບຄວາມສຳຄັນ |
ການອັດຕະໂນມັດໃນການຈັດຊື້ຂອງອຸດສາຫະກຳການຜະລິດໃນໄທ ມີ 3 ຄວາມຕ້ອງການທີ່ສຳນັກງານໃຫຍ່ໃນຍີ່ປຸ່ນບໍ່ມີ:
ດ້ວຍຄວາມຄືບໜ້າຂອງ 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 ປະເພດ:
| ລາຍການເຊື່ອມຕໍ່ | ທິດທາງ | ຈຸດປະສົງ |
|---|---|---|
| ການອ່ານໃບຂໍຊື້ (PR) | ERP → ຕົວແທນ | ຕ້ອງການຫຍັງ, ຈຳນວນເທົ່າໃດ, ແລະ ພາຍໃນເວລາໃດ |
| ການອ້າງອີງຂໍ້ມູນຜູ້ສະໜອງ (Supplier Master) | ERP → ຕົວແທນ | ຂໍ້ມູນພື້ນຖານຂອງຜູ້ສະໜອງທີ່ມີສິດ |
| ການຂຽນຂໍ້ມູນໃບສັ່ງຊື້ (PO) | ຕົວແທນ → ERP | ການລົງທະບຽນຂໍ້ມູນການສັ່ງຊື້ທີ່ຢືນຢັນແລ້ວ |
ໃນກໍລະນີທີ່ການກຽມພ້ອມ API ຂອງຝັ່ງ ERP ບໍ່ພຽງພໍ, ໃຫ້ພິຈາລະນາການອອກແບບໂດຍຜ່ານ Read-only replica ຫຼື ຖານຂໍ້ມູນກາງ. ຖ້າຕົວແທນເຂົ້າໄປໃຊ້ງານ API ການຂຽນຂໍ້ມູນຂອງ ERP ໂດຍກົງ, ການເຮັດ Rollback ໃນກໍລະນີທີ່ເກີດການສັ່ງຊື້ຜິດພາດຈະເຮັດໄດ້ຍາກ. ການອອກ PO ຄວນແບ່ງອອກເປັນ 3 ຂັ້ນຕອນຄື: "ການສ້າງຮ່າງ → ການອະນຸມັດຂັ້ນສຸດທ້າຍໂດຍມະນຸດ → ການຂຽນຂໍ້ມູນລົງ ERP" ແລະ ການຈຳກັດສິດໃນການຂຽນຂໍ້ມູນໄວ້ສະເພາະຂັ້ນຕອນສຸດທ້າຍເທົ່ານັ້ນຈະມີຄວາມປອດໄພກວ່າ.
ຄຸນນະພາບການຕັດສິນໃຈຂອງ Agent ແມ່ນຂຶ້ນກັບຄຸນນະພາບຂອງຂໍ້ມູນທີ່ປ້ອນເຂົ້າໂດຍກົງ. ກ່ອນການນຳໃຊ້ ຄວນຈັດກຽມສິ່ງເຫຼົ່ານີ້ໃຫ້ພ້ອມ:
ຫາກນຳໃຊ້ Agent ໃນສະພາບທີ່ຂໍ້ມູນເຫຼົ່ານີ້ບໍ່ຄົບຖ້ວນ ຈະເຮັດໃຫ້ເກີດຄວາມຜິດພາດ ເຊັ່ນ: "ເລືອກ Supplier ລາຍໃໝ່ທີ່ບໍ່ເຄີຍມີປະຫວັດການເຮັດທຸລະກຳມາກ່ອນ" ຫຼື "ບໍ່ສາມາດສະເໜີຊິ້ນສ່ວນທົດແທນໄດ້". ການຈັດກຽມຂໍ້ມູນຄວນເຮັດເປັນໂຄງການຮ່ວມກັນລະຫວ່າງພະແນກຈັດຊື້ ແລະ ພະແນກລະບົບຂໍ້ມູນຂ່າວສານ ໂດຍຄວນເລີ່ມຕົ້ນກ່ອນການຕິດຕັ້ງ Agent.
ຕໍ່ໄປນີ້ແມ່ນຂັ້ນຕອນການປະຕິບັດຕົວຈິງໂດຍແບ່ງອອກເປັນ 3 ຂັ້ນຕອນ. ໃນການປະຕິບັດຕາມເອກະສານອ້າງອີງ (Reference implementation), ພວກເຮົາຈະເລີ່ມຕົ້ນຈາກການຈັດໂຄງສ້າງຄຳຮ້ອງຂໍການຈັດຊື້, ອອກແບບຕົວແທນ (Agent) ໃນການຄັດເລືອກຜູ້ສະໜອງ, ແລະ ສຸດທ້າຍແມ່ນການເຮັດໃຫ້ການປຽບທຽບໃບສະເໜີລາຄາ ແລະ ການອອກ PO ເປັນອັດຕະໂນມັດ. ໃນແຕ່ລະຂັ້ນຕອນ, ຈະຕ້ອງມີການກຳນົດໃຫ້ຈະແຈ້ງວ່າ "ສ່ວນໃດທີ່ຄວນມອບໝາຍໃຫ້ຕົວແທນ (Agent) ເປັນຜູ້ຈັດການ ແລະ ສ່ວນໃດທີ່ມະນຸດຄວນເຂົ້າມາມີສ່ວນຮ່ວມ".
ເມື່ອຄຳຮ້ອງຂໍການຊື້ (PR: Purchase Request) ຖືກສົ່ງມາໃນຮູບແບບຂໍ້ມູນທີ່ບໍ່ມີໂຄງສ້າງ ເຊັ່ນ: "ການຂຽນແບບອິດສະຫຼະໃນ Excel" ຫຼື "ລາຍການໃນເນື້ອຫາອີເມວ", ເອເຈນ (Agent) ຈະບໍ່ສາມາດປະມວນຜົນໄດ້. ຂັ້ນຕອນທຳອິດຄືການປັບ PR ໃຫ້ເປັນມາດຕະຖານຕາມໂຄງສ້າງສະກີມາ (Structured Schema).
ລາຍການທີ່ຈຳເປັນຂັ້ນຕໍ່າມີດັ່ງນີ້:
1{
2 "item_code": "X-201",
3 "item_name": "リニアベアリング φ20",
4 "quantity": 2000,
5 "unit": "pcs",
6 "required_delivery_date": "2026-06-15",
7 "budget_max": 500000,
8 "currency": "THB",
9 "delivery_location": "Rayong Plant A",
10 "quality_requirements": ["ISO9001", "RoHS"]
11}ສຳລັບ 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.
| ຂັ້ນຕອນຍ່ອຍ | ລະດັບການອັດຕະໂນມັດ | ຂໍ້ຄວນລະວັງ |
|---|---|---|
| ສົ່ງອີເມວຂໍໃບສະເໜີລາຄາ | ອັດຕະໂນມັດທັງໝົດ | ສ້າງເນື້ອຫາໃຫ້ສອດຄ່ອງກັບພາສາ ແລະ ວິທີການດຳເນີນທຸລະກິດຂອງຜູ້ສະໜອງ |
| ແຍກວິເຄາະຄຳຕອບໃບສະເໜີລາຄາ | ອັດຕະໂນມັດທັງໝົດ | ໃຊ້ LLM ເພື່ອຈັດໂຄງສ້າງຂໍ້ມູນຈາກ PDF, ເນື້ອຫາອີເມວ ແລະ ໄຟລ໌ Excel ທີ່ແນບມາ |
| ສ້າງຕາຕະລາງປຽບທຽບ | ອັດຕະໂນມັດທັງໝົດ | ຈັດລຽງຂໍ້ມູນອັດຕາແລກປ່ຽນ, ກຳນົດເວລາສົ່ງມອບ ແລະ ຂໍ້ກຳນົດດ້ານຄຸນນະພາບດ້ວຍຫົວໜ່ວຍທີ່ເປັນເອກະພາບ |
| ຕັດສິນໃຈສັ່ງຊື້ | HITL | ສາມາດອະນຸມັດອັດຕະໂນມັດໄດ້ຫາກຢູ່ໃນງົບປະມານ, ກຳນົດເວລາເໝາະສົມ ແລະ ເປັນຜູ້ສະໜອງທີ່ມີຢູ່ແລ້ວ |
| ບັນທຶກຂໍ້ມູນ PO | ເຄິ່ງອັດຕະໂນມັດ | ຮ່າງເອກະສານໂດຍອັດຕະໂນມັດ, ການຢືນຢັນຂັ້ນສຸດທ້າຍຕ້ອງຜ່ານການອະນຸມັດຈາກມະນຸດ |
ມາດຕະຖານ HITL ສຳລັບ "ການຕັດສິນໃຈສັ່ງຊື້" ຄວນຖືກລະບຸໄວ້ເປັນລາຍລັກອັກສອນ. ຕົວຢ່າງເຊັ່ນ: ການນຳໃຊ້ເກນການຕັດສິນໃຈວ່າ "ຖ້າມູນຄ່າຕໍ່າກວ່າ 1 ລ້ານບາດ ແລະ ເປັນຜູ້ສະໜອງໃນ 3 ອັນດັບທຳອິດທີ່ມີຢູ່ແລ້ວ ໃຫ້ອະນຸມັດອັດຕະໂນມັດ, ສ່ວນກໍລະນີອື່ນໆຕ້ອງໃຫ້ມະນຸດເປັນຜູ້ອະນຸມັດ". ຖ້າຫາກມາດຕະຖານບໍ່ຊັດເຈນ, ເອເຈນ (Agent) ຈະຢຸດເຮັດວຽກເມື່ອພົບກໍລະນີທີ່ຢູ່ກ້ຳກິ່ງ ແລະ ຈະບໍ່ສາມາດຫຼຸດຜ່ອນພາລະໃນການດຳເນີນງານໄດ້.

ຫຼັງຈາກນຳໄປໃຊ້ງານຈິງແລ້ວ, ຮູບແບບຄວາມຜິດພາດທີ່ມັກເກີດຂຶ້ນມີ 2 ຢ່າງ ຄື: ຄວາມບົກຜ່ອງໃນການອອກແບບ HITL ແລະ ການຂາດແຄນບັນທຶກການກວດສອບ (Audit log). ທັງສອງຢ່າງນີ້ແມ່ນເບິ່ງເຫັນໄດ້ຍາກໃນຂັ້ນຕອນ PoC ແລະ ມັກຈະກາຍເປັນບັນຫາຫຼັງຈາກເລີ່ມເປີດຕົວ ຫຼື Launch ໃຊ້ງານ.
ຄວາມຜິດພາດທີ່ມັກພົບເລື້ອຍໃນການອອກແບບ HITL ຄືການຕົກຢູ່ໃນສອງຂົ້ວຄື: "ການໃຫ້ມະນຸດອະນຸມັດທຸກລາຍການຈົນເຮັດໃຫ້ການອັດຕະໂນມັດໝົດຄວາມໝາຍ" ແລະ "ການອັດຕະໂນມັດຫຼາຍເກີນໄປຈົນບໍ່ສາມາດກວດຈັບການສັ່ງຊື້ທີ່ຜິດພາດໄດ້".
ແນວທາງໃນການອອກແບບຄື "ການແບ່ງຂະບວນການຕາມການປະສົມປະສານຂອງຈຳນວນເງິນ, ຜົນງານຂອງຜູ້ສະໜອງ ແລະ ທຸງຍົກເວັ້ນ (Exception flag)". ຕົວຢ່າງເຊັ່ນ: ການຕັ້ງຄ່າເກນ (Threshold) ດັ່ງຕໍ່ໄປນີ້ແມ່ນມີຄວາມເປັນໄປໄດ້ໃນການປະຕິບັດຈິງ:
ການແຈ້ງເຕືອນການຍົກລະດັບ (Escalation) ຄວນອອກແບບໃຫ້ສອດຄ່ອງກັບຈັງຫວະການເຮັດວຽກຂອງຜູ້ອະນຸມັດ. ເນື່ອງຈາກຜູ້ບໍລິຫານໃນອຸດສາຫະກຳການຜະລິດມັກຈະມີການປະຊຸມຫຼາຍ ແລະ ຕອບອີເມວຊ້າ, ນອກຈາກການແຈ້ງເຕືອນຜ່ານ Slack, LINE, ຫຼື Microsoft Teams ແລ້ວ, ຄວນມີກົນໄກສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ຜູ້ອະນຸມັດໃນລະດັບຖັດໄປໂດຍອັດຕະໂນມັດ ຫາກລາຍການນັ້ນຍັງບໍ່ທັນໄດ້ຮັບການອະນຸມັດພາຍໃນເວລາທີ່ກຳນົດ (ເຊັ່ນ: 6 ຊົ່ວໂມງ), ເຊິ່ງຈະຊ່ວຍໃຫ້ Lead time ມີຄວາມສະຖຽນຫຼາຍຂຶ້ນ.
ພາຍໃຕ້ລະບົບ Authorized Economic Operator ຂອງປະເທດໄທ, ມີຂໍ້ກຳນົດໃຫ້ເກັບຮັກສາປະຫວັດການເຮັດທຸລະກຳທີ່ກ່ຽວຂ້ອງກັບການນຳເຂົ້າໄວ້ໃນໄລຍະເວລາທີ່ກຳນົດ ແລະ ຕ້ອງນຳສະເໜີຕໍ່ເຈົ້າໜ້າທີ່ພາສີເມື່ອມີການກວດສອບ. ໃນກໍລະນີທີ່ບໍລິສັດທີ່ໄດ້ຮັບການຮັບຮອງ AEO (ຫຼື ບໍລິສັດທີ່ກຳລັງມຸ່ງຫວັງຈະໄດ້ຮັບການຮັບຮອງ) ນຳໃຊ້ຕົວແທນການຈັດຊື້ (Procurement Agent), ຈຳເປັນຕ້ອງເກັບຮັກສາບັນທຶກ (Log) ດັ່ງຕໍ່ໄປນີ້ໃນຮູບແບບທີ່ມີໂຄງສ້າງ:
| ລາຍການບັນທຶກ (Log) | ເນື້ອຫາ |
|---|---|
| ບັນທຶກການຕັດສິນໃຈ | ເຫດຜົນທີ່ຕົວແທນເລືອກຜູ້ສະໜອງ (ພື້ນຖານການຕັດສິນໃຈຂອງ LLM) |
| ບັນທຶກການເອີ້ນໃຊ້ເຄື່ອງມື (Tool) | API, ພາຣາມິເຕີ ແລະ ການຕອບສະໜອງທີ່ຖືກເອີ້ນໃຊ້ |
| ບັນທຶກການອະນຸມັດ | ໃຜ, ເວລາໃດ, ແລະ ອະນຸມັດຫຍັງ |
| ບັນທຶກການປ່ຽນແປງ | ປະຫວັດການແກ້ໄຂກ່ອນການສັ່ງຊື້ |
ນອກຈາກນີ້, ໃນກໍລະນີທີ່ມີການຈັດການຂໍ້ມູນຜູ້ຮັບຜິດຊອບຂອງຜູ້ສະໜອງ ແລະ ປະຫວັດການເຮັດທຸລະກຳ ຈະຕ້ອງປະຕິບັດຕາມກົດໝາຍ PDPA (ກົດໝາຍວ່າດ້ວຍການຄຸ້ມຄອງຂໍ້ມູນສ່ວນບຸກຄົນ) ຂອງໄທ. ດັ່ງນັ້ນ, ຕ້ອງອອກແບບລະບົບໂດຍເນັ້ນການຫຼຸດຜ່ອນຂໍ້ມູນໃຫ້ໜ້ອຍທີ່ສຸດ (Data Minimization - ບໍ່ສົ່ງຂໍ້ມູນສ່ວນບຸກຄົນທີ່ບໍ່ຈຳເປັນໃຫ້ແກ່ຕົວແທນ) ແລະ ມີການລຶບຂໍ້ມູນໂດຍອັດຕະໂນມັດຫຼັງຈາກໝົດກຳນົດເວລາການເກັບຮັກສາ.

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

B2B ຈັດຊື້ຕົວແທນ (B2B調達エージェント) ບໍ່ແມ່ນ "ເວດມົນອັດຕະໂນມັດທັງໝົດ" ແຕ່ເປັນກົນໄກທີ່ຊ່ວຍໃຫ້ມະນຸດສາມາດສຸມໃສ່ການຈັດການກັບກໍລະນີຍົກເວັ້ນຕ່າງໆໄດ້. ເພື່ອໃຫ້ອຸດສາຫະກຳການຜະລິດໃນໄທນຳກົນໄກນີ້ໄປໃຊ້, ຈຳເປັນຕ້ອງໄດ້ກຳນົດການອອກແບບການເຊື່ອມຕໍ່ ERP, ການຈັດການຂໍ້ມູນ Supplier Master, ການກຳນົດເກນ HITL ໃຫ້ຊັດເຈນ, ແລະ ການອອກແບບ Audit Log ທີ່ຮອງຮັບ AEO/PDPA ໃຫ້ຮຽບຮ້ອຍກ່ອນການເລີ່ມນຳໃຊ້ຕົວແທນ.
ສຳລັບບາດກ້າວທຳອິດ, ຄວນເລີ່ມຈາກການຈຳກັດຂອບເຂດໝວດໝູ່ການຈັດຊື້ພຽງ 1 ໝວດ (ຕົວຢ່າງ: ວັດສະດຸສິ້ນເປືອງທົ່ວໄປ, ກຸ່ມຊິ້ນສ່ວນສະເພາະ) ແລະ ດຳເນີນການ PoC ເປັນເວລາ 3-6 ເດືອນ ເພື່ອວັດແທກ "ຊົ່ວໂມງການເຮັດວຽກຂອງຜູ້ຊື້", "Lead time" ແລະ "ອັດຕາການເກີດກໍລະນີຍົກເວັ້ນ". ເມື່ອດັດຊະນີຕ່າງໆດີຂຶ້ນໃນຂັ້ນຕອນ PoC ແລ້ວ, ການຂະຫຍາຍໄປສູ່ໝວດໝູ່ອື່ນຈະເປັນຮູບແບບທີ່ສາມາດສ້າງຜົນປະໂຫຍດໄດ້ພ້ອມກັບການຄວບຄຸມຄວາມສ່ຽງໃນການດຳເນີນງານ.
ການເຮັດໃຫ້ການຈັດຊື້ເປັນອັດຕະໂນມັດບໍ່ແມ່ນການລົງທຶນດ້ານ IT ພຽງຄັ້ງດຽວ, ແຕ່ເປັນຄວາມພະຍາຍາມທີ່ຕ້ອງມີການອອກແບບຍຸດທະສາດການຈັດຊື້ໃໝ່. ການດຳເນີນງານໂດຍບໍ່ມີພຽງແຕ່ພະແນກລະບົບຂໍ້ມູນຂ່າວສານ, ແຕ່ຕ້ອງມີການສ້າງທີມງານທີ່ລວມເອົາພະແນກຈັດຊື້ ແລະ ຜູ້ບໍລິຫານລະດັບສູງເຂົ້າມາມີສ່ວນຮ່ວມນຳ, ເຊິ່ງຖືເປັນເງື່ອນໄຂເບື້ອງຕົ້ນຂອງຄວາມສຳເລັດ.

Yusuke Ishihara
ເລີ່ມຂຽນໂປຣແກຣມຕັ້ງແຕ່ອາຍຸ 13 ປີ ດ້ວຍ MSX. ຫຼັງຈົບການສຶກສາຈາກມະຫາວິທະຍາໄລ Musashi, ໄດ້ເຮັດວຽກໃນການພັດທະນາລະບົບຂະໜາດໃຫຍ່ ລວມທັງລະບົບຫຼັກຂອງສາຍການບິນ ແລະ ໂຄງສ້າງ Windows Server Hosting/VPS ທຳອິດຂອງຍີ່ປຸ່ນ. ຮ່ວມກໍ່ຕັ້ງ Site Engine Inc. ໃນປີ 2008. ກໍ່ຕັ້ງ Unimon Inc. ໃນປີ 2010 ແລະ Enison Inc. ໃນປີ 2025, ນຳພາການພັດທະນາລະບົບທຸລະກິດ, NLP ແລະ ແພລດຟອມ. ປັດຈຸບັນສຸມໃສ່ການພັດທະນາຜະลິດຕະພັນ ແລະ ການສົ່ງເສີມ AI/DX ໂດຍນຳໃຊ້ generative AI ແລະ LLM.