เริ่มจากออเดอร์ที่ไม่มีใครเห็นทั้งเส้น
16:42 น. ลูกค้าถามว่า “ของจะออกพรุ่งนี้ไหมครับ?”
พนักงานขายเปิดอีเมลแล้วพบว่าใบสั่งซื้อด่วนที่ส่งเข้ามาตั้งแต่เมื่อวานยังไม่กลายเป็น Order ใน ERP เขาจำได้ว่าตนส่งต่อไฟล์ให้ Sales Operations แล้ว ฝ่ายนั้นบอกว่ารอ Customer ID จาก Finance ส่วนคลังสินค้าตอบว่าไม่เคยเห็นคำขอจองสต็อก
ฝ่าย IT ตรวจระบบและยืนยันว่าไม่มี Error เพราะแต่ละระบบทำงานตามปกติ ปัญหาคืองานกำลังนอนอยู่ระหว่างระบบ—ใน Inbox หนึ่งรายการ ในแชตอีกสองข้อความ และใน Spreadsheet แถวหนึ่งที่ไม่มีใครรู้ว่าใครต้องทำต่อ
ถ้ารีบนำ Agent มาวางตรงจุดนี้ มันอาจอ่านอีเมลได้เร็วขึ้น แต่ยังตอบไม่ได้ว่าใครมีสิทธิ์สร้างลูกค้าใหม่ เมื่อไรควรจองสต็อก หรือกรณีเครดิตไม่ผ่านต้องเข้าคิวของใคร
บทนี้จึงไม่ได้เริ่มจากคำถามว่า Agent ใช้เครื่องมืออะไร แต่เริ่มจากคำถามที่ง่ายและมักถูกมองข้ามกว่า: งานหนึ่งชิ้นเดินทางจากต้นทางถึงปลายทางอย่างไร
คุณจะตามรอยงานหนึ่งรายการตั้งแต่ Trigger ถึง Outcome แยกเวลาที่คนลงมือออกจากเวลาที่งานนอนรอ มองเห็น Decision และ Exception ที่ซ่อนอยู่ แล้วออกแบบ Future State ซึ่งบอกได้ชัดว่า Automation, Agent และคนรับช่วงกันตรงไหน
ก่อนวาดกล่องสวย ๆ
Process บอกว่าองค์กรทำอะไร ส่วน Workflow บอกว่างานชิ้นนี้ไปต่ออย่างไร
คำว่า Process มักอยู่ในระดับภาพรวม เช่น “รับคำสั่งซื้อและส่งมอบสินค้า” มันช่วยให้เราเห็นเป้าหมาย เจ้าของ และขอบเขตของงาน แต่ยังไม่พอสำหรับออกแบบ Agent เพราะ Agent ต้องเผชิญเหตุการณ์จริงทีละรายการ: อีเมลเข้ามา ไฟล์เปิดไม่ได้ รหัสลูกค้าหาย สินค้าบางตัวหมด เครดิตไม่พอ หรือ API ไม่ตอบ
Workflow คือภาพที่ละเอียดลงมาอีกชั้นหนึ่ง มันบอกว่าอะไรเป็น Trigger ข้อมูลเข้ามาจากไหน ใครหรือระบบใดทำอะไร ใช้เกณฑ์อะไรตัดสินใจ แล้วส่งงานต่อพร้อมหลักฐานอะไร เมื่อวาดดี ๆ เราจะเห็นว่าบางช่วงควรใช้กฎตายตัว บางช่วงต้องตีความภาษา และบางช่วงต้องให้ผู้มีอำนาจตัดสินใจ
Anthropic เรียกระบบที่โมเดลและเครื่องมือเดินตามเส้นทางซึ่งกำหนดไว้ล่วงหน้าว่า Workflow และแยกจาก Agent ที่เลือกกระบวนการและเครื่องมือแบบพลวัต พร้อมแนะนำให้เริ่มจากรูปแบบที่ง่ายที่สุดซึ่งยังแก้ปัญหาได้ [1] ดังนั้นการวาด Workflow ไม่ใช่งานเอกสารก่อนสร้าง Agent แต่มันคือวิธีตัดสินใจว่าเราต้องใช้ Agent จริงตรงไหน
OpenAI ให้ภาพคล้ายกันว่า Agent จัดการการเดินของ Workflow เลือกเครื่องมือ และควรหยุดหรือคืนการควบคุมให้ผู้ใช้เมื่อทำงานต่อไม่ได้ แนวทางยังชี้ให้เขียนขั้นตอนเป็นการกระทำที่ชัดและเก็บ Edge Case ไว้ในเส้นทางงาน [2] คำว่า “ส่งให้คน” จึงไม่ใช่ปลายทางที่เพียงพอ เราต้องตอบต่อว่า ส่งให้ใคร ผ่านคิวใด ภายในกี่ชั่วโมง และส่งข้อมูลอะไรไปด้วย
อย่าเริ่มจากการวาดสิ่งที่อยากให้ Agent ทำ ให้ตามรอยงานจริงหนึ่งชิ้นก่อน เพราะรอยต่อที่งานค้างและข้อยกเว้นที่ไม่มีเจ้าของมักเป็นต้นเหตุของปัญหา มากกว่าความเร็วในการทำแต่ละขั้น
ภาษากลางของคนหน้างานและคนสร้างระบบ
อ่าน Workflow ให้เป็นเรื่องของ “งานหนึ่งชิ้น”
เลือก Order หนึ่งรายการแล้วเล่าเส้นทางของมันให้เหมือนติดกล้องตามของหนึ่งกล่อง อย่าเพิ่งรวมหลายกรณีเข้าด้วยกัน ถ้าคำอธิบายมีคำว่า “ปกติก็…” ให้ถามต่อทันทีว่า แล้ววันที่ไม่ปกติเกิดอะไรขึ้น
TRIGGER + DONE
กำหนดจุดเริ่มและคำว่า “เสร็จ” ให้ตรงกัน
“ลูกค้าส่งอีเมล” เป็น Trigger ที่สังเกตได้ แต่ “ฝ่ายขายอยากปิดงาน” ไม่ใช่ ส่วนคำว่าเสร็จอาจหมายถึงสร้าง Draft Order, ยืนยัน Order หรือจองสต็อกแล้ว คนแต่ละฝ่ายมักใช้คำเดียวกันแต่คิดถึงคนละเส้นชัย
ลองถาม: ถ่ายภาพหน้าจอหรือชี้เหตุการณ์ที่บอกว่าเริ่มและเสร็จได้หรือไม่ ถ้าไม่ได้ ขอบเขตยังคลุมเครือเกินไป
TASK + HAND-OFF
แยกการลงมือออกจากการส่งต่อ
“ตรวจข้อมูลลูกค้า” เป็นงานหนึ่งชิ้น แต่ “ส่งให้ Finance เช็ก” คือ Hand-off ซึ่งสร้างคิวและเวลารอ การรวมสองอย่างไว้ในกล่องเดียวทำให้เราเห็นเพียงเวลาทำงาน แต่ไม่เห็นเวลาที่ลูกค้าต้องรอจริง
ลองถาม: หลังขั้นนี้ คนถัดไปรู้หรือไม่ว่าต้องรับช่วง มีข้อมูลครบหรือไม่ และถ้าเขาไม่อยู่ งานจะไปที่ไหน
DECISION + JUDGEMENT
แยกกฎที่เขียนได้ออกจากดุลยพินิจ
“ถ้า Customer ID ว่าง ให้ขอข้อมูลเพิ่ม” เป็นกฎที่ตรวจได้ แต่ “ลูกค้ารายนี้สำคัญ ควรยอมเกินวงเงินหรือไม่” ต้องพิจารณาบริบทและผู้มีอำนาจ หากวาดทั้งคู่เป็นรูปเพชรเหมือนกัน เราจะเผลอมอบการตัดสินใจสำคัญให้ระบบ
ลองถาม: คนสองคนที่มีข้อมูลเท่ากันจะตอบเหมือนกันเสมอหรือไม่ ถ้าไม่ นี่อาจเป็น Judgement ไม่ใช่ Rule
EVIDENCE + OWNER
ทุกทางออกต้องทิ้งร่องรอยและมีผู้รับช่วง
ถ้า Agent บอกว่าเครดิตไม่ผ่าน ผู้รับช่วงต้องเห็นวงเงิน ยอดค้าง วันที่ของข้อมูล และกฎที่ใช้ ไม่ใช่เห็นเพียงป้ายสีแดง ส่วนคำว่า Owner ต้องหมายถึงบทบาทหรือทีมที่รับผิดชอบจริง ไม่ใช่ “Business” หรือ “ผู้เกี่ยวข้อง”
ลองถาม: หากต้องย้อนตรวจในอีกหนึ่งเดือน เราจะรู้หรือไม่ว่าใช้ข้อมูลอะไร ใครอนุมัติ และงานกลับเข้าสู่เส้นทางหลักเมื่อไร
สิ่งที่แผนภาพทั่วไปมักซ่อน
นาฬิกาสองเรือน และสัญญาของเส้นทางข้อยกเว้น
นาฬิกาเรือนแรก: Touch Time
Touch Time คือเวลาที่คนหรือระบบกำลังลงมือกับงาน เช่น อ่านไฟล์ 6 นาที ตรวจรหัสสินค้า 8 นาที และบันทึก ERP 13 นาที หากรวมกันอาจดูเหมือนงานนี้ใช้เพียง 27 นาที
นาฬิกาเรือนที่สอง: Wait Time
Wait Time คือช่วงที่ไม่มีใครทำงานชิ้นนั้น แต่ลูกค้ายังรอ เช่น นอนใน Inbox 5 ชั่วโมง รอ Finance ตอบข้ามคืน และรอเจ้าของข้อมูลกลับจากประชุมอีกครึ่งวัน องค์กรมักลงทุนลด Touch Time เพราะวัดง่าย ทั้งที่ Lead Time ส่วนใหญ่อาจซ่อนอยู่ในคิว
งาน 27 นาทีที่ลูกค้ารอ 31 ชั่วโมง
ก่อนหา AI ให้เก็บตัวอย่างงานจริง 10–20 รายการ จด Timestamp ที่รับ ส่งต่อ เปิดทำ และปิดงาน แยกค่ามัธยฐานออกจากกรณีช้าที่สุด อย่าใช้เพียงความรู้สึกว่า “ส่วนใหญ่ไม่นาน” เพราะงานที่หลุดคิวมักเป็นงานที่สร้างข้อร้องเรียนมากที่สุด
เส้นทางข้อยกเว้นต้องมี “สัญญา”
คำว่า “ถ้าไม่แน่ใจให้ส่งคน” ฟังปลอดภัย แต่ยังใช้งานไม่ได้ มันอาจทำให้ Agent สร้างกองงานที่ไม่มีใครเปิดดู เส้นทางข้อยกเว้นที่ดีต้องตอบหกเรื่อง: เหตุผลที่ส่ง, คิวปลายทาง, เจ้าของ, เวลาตอบรับ, หลักฐานที่แนบ และวิธีกลับเข้าสู่ Workflow
- เหตุผล
- Customer ID ไม่พบ และชื่อบริษัทตรงได้มากกว่าหนึ่งรายการ
- ปลายทาง
- Sales Operations → คิว Customer Master Review
- SLA
- รับเรื่องภายใน 2 ชั่วโมงทำการ; หากเกินให้แจ้งหัวหน้าคิว
- หลักฐาน
- ข้อความต้นทาง รายการที่ค้นพบ คะแนนความตรง และสิ่งที่ระบบยังไม่ทราบ
- การกลับเข้าเส้นทาง
- ผู้ตรวจเลือก Customer ID หรือขอข้อมูลเพิ่ม แล้วส่งสถานะกลับไปเริ่มขั้น Credit Check
NIST AI RMF ระบุให้กำหนดและบันทึกขอบเขตการใช้งานตามบริบท รวมทั้งกระบวนการ Human Oversight [3] ในทางปฏิบัติ Exception Contract คือจุดที่หลักการนี้กลายเป็นงานประจำวันที่ทีมทำต่อได้จริง
กรณีศึกษาต่อเนื่อง · สยามโฟลว์
ตามรอย PO-7842 ก่อนแก้กระบวนการ
ทีมไม่ได้เริ่ม Workshop ด้วยการถามว่าอยากให้ Agent ทำอะไร แต่พิมพ์ใบสั่งซื้อสมมติหนึ่งใบ วางไว้กลางโต๊ะ แล้วให้ทุกฝ่ายเล่าว่ากระดาษใบนี้เดินไปไหนบ้าง ผลที่เห็นต่างจาก SOP บน SharePoint อย่างชัดเจน
Current State: งานไม่ได้ไหล มันถูกโยน
08:56 ลูกค้าส่ง PO ทางอีเมล ฝ่ายขายเปิดอ่าน 09:18 แล้วส่งต่อให้ Sales Operations เพราะในเอกสารมีเพียงชื่อลูกค้า 10:05 พนักงานค้น Spreadsheet รายชื่อลูกค้าแต่พบสองชื่อใกล้เคียง จึงถาม Finance ทางแชตโดยไม่ได้สร้าง Ticket
Finance ตอบ 14:20 ว่าต้องใช้เลขผู้เสียภาษี ฝ่ายขายจึงขอลูกค้าในเช้าวันถัดมา หลังได้ข้อมูล ทีมตรวจพบว่ายอด Order เกินวงเงิน 45,000 บาท งานถูกส่งต่ออีกครั้งโดยไม่มี SLA ระหว่างนั้นสต็อกสินค้า A-17 ยังไม่ถูกจอง และถูกใช้กับ Order อื่น
รอยเท้าของงานหนึ่งรายการใน Current State
ทีมตกลงกันว่าปัญหาไม่ใช่ “พนักงานคีย์ช้า” อย่างเดียว แต่มีสามรอยรั่ว: ตัวระบุลูกค้าไม่ครบ, ข้อยกเว้นเครดิตไม่มีคิวกลาง และการจองสต็อกเกิดช้าเกินไป การออกแบบ Future State จึงต้องแก้รอยรั่วเหล่านี้ ไม่ใช่เพียงให้ AI คัดลอกข้อมูลแทนคน
ออกแบบ Future State ให้ทำงานได้จริง
Agent เตรียมงาน คนตัดสินใจ ระบบหลักยืนยันความจริง
ทีมเริ่มจากขอบเขตแบบ Draft-only: Agent รับอีเมล แยกข้อมูล และอ่านข้อมูลจากระบบที่อนุญาตได้ แต่ยังสร้างลูกค้า อนุมัติเครดิต ยืนยัน Order หรือส่งอีเมลออกเองไม่ได้ เป้าหมายคือทำให้ผู้รับช่วงเห็นข้อมูลครบและตัดสินใจเร็วขึ้น
Future State ของ Order Intake แบบ Draft-only
ลองเดิน PO-7842 ผ่านเส้นทางใหม่ทีละจุด
รับและตีความ
Agent อ่านอีเมลและไฟล์ พบ SKU กับจำนวนครบ แต่ Customer ID หาย จึงไม่เดาจากชื่อบริษัทแล้วเดินต่อ
ค้นหาแบบ Read-only
ระบบค้น Customer Master ด้วยชื่อ ที่อยู่ และเลขผู้เสียภาษีที่มีอยู่ พบผู้สมัครสองรายการ คะแนนใกล้กัน จึงเข้าเงื่อนไขหยุด
ส่งข้อยกเว้นพร้อมบริบท
Agent เปิด Work Item ให้ Sales Operations พร้อมข้อความต้นทาง สอง Customer ID ที่อาจตรง เหตุผลที่ยังตัดสินไม่ได้ และปุ่มเลือกหรือขอข้อมูลเพิ่ม
กลับเข้าสู่เส้นทางหลัก
เมื่อพนักงานยืนยัน Customer ID ระบบจึงตรวจเครดิตและสต็อก หากเครดิตเกิน ให้ Finance เห็นยอดเกิน ประวัติชำระ และ Order Value แล้วตัดสินใจตามอำนาจ
สร้าง Draft ไม่ใช่ Commit
หลังผ่านเงื่อนไข Agent เตรียม Draft Order ให้ Sales Operations ตรวจครั้งสุดท้าย การยืนยันจริงใช้บัญชีพนักงานและถูกบันทึกใน ERP
| จุดใน Workflow | ผู้ทำ | ข้อมูล/เครื่องมือ | เงื่อนไขไปต่อ | หลักฐานที่เก็บ |
|---|---|---|---|---|
| รับ PO | Automation | Mailbox เฉพาะงาน | ไฟล์เปิดได้และประเภทที่รองรับ | Message ID, File Hash, เวลา |
| แยกข้อมูล | Agent | เอกสารจำลอง + Instruction | ฟิลด์บังคับครบตามเกณฑ์ | ค่าที่แยกและ Confidence |
| จับคู่ลูกค้า | Agent → Sales Ops | Customer Master แบบ Read-only | ตรงหนึ่งรายการตามเกณฑ์ มิฉะนั้น Escalate | Candidates และเหตุผล |
| ข้อยกเว้นเครดิต | Finance | Credit Status + ประวัติชำระ | ผู้มีอำนาจอนุมัติหรือปฏิเสธ | ผู้ตัดสิน เวลา และเหตุผล |
| สร้าง Order | Agent → Sales Ops | ERP Draft API | คนตรวจและ Commit | Draft ID และ Approval ID |
จุดที่สำคัญที่สุด: Agent หยุดเมื่อพบผู้สมัครลูกค้าสองราย ไม่ใช่เพราะมัน “ไม่ฉลาดพอ” แต่เพราะทีมออกแบบให้ความไม่แน่ใจชนิดนี้อยู่เหนือ Autonomy Budget การหยุดอย่างถูกจุดคือพฤติกรรมที่ดี ไม่ใช่ความล้มเหลว
TRY IT WITH YOUR ORGANIZATION
เดินตามงานจริงหนึ่งชิ้น อย่าเริ่มจากห้องประชุม
- วาด Current State ตั้งแต่ Trigger ถึง Outcome และใส่ Wait Time/Touch Time
- วงขั้นที่เป็น Decision, Copy/Paste, Rework และ Exception
- ออกแบบ Future State โดยระบุ Human Review และเงื่อนไขหยุดทุกจุดสำคัญ
- บันทึกลงแท็บ Workflow พร้อม Owner และ Evidence ที่ต้องเก็บ
การขึ้นทะเบียนผู้ขายรายใหม่
- Trigger
- ฝ่ายจัดซื้อสร้างคำขอในระบบพร้อมชื่อผู้ขายและหมวดสินค้าที่จะซื้อ
- Done
- Vendor ID ถูกสร้างใน ERP หลังผ่านการตรวจเอกสาร ภาษี บัญชีธนาคาร และผู้มีอำนาจอนุมัติ
- Touch / Wait
- ลงมือรวมประมาณ 38 นาที แต่รอเอกสารและการอนุมัติมัธยฐาน 4.5 วัน ตัวเลขเป็นข้อมูลสมมติ
- Agent Role
- จัดรายการเอกสาร อ่านค่าจากเอกสารจำลอง เปรียบเทียบความสอดคล้อง และเตรียม Case Summary
- Human Review
- Procurement ตรวจความสัมพันธ์ทางธุรกิจ, Finance ยืนยันบัญชี, Compliance ตัดสินใจกรณีชื่อใกล้รายการเฝ้าระวัง
- Stop Condition
- ชื่อหรือเลขบัญชีไม่ตรง เอกสารหมดอายุ หรือพบข้อมูลขัดแย้ง ระบบเปิด Work Item และไม่สร้าง Vendor
- Evidence
- Document ID, ผลตรวจแต่ละข้อ, เวอร์ชันกฎ, ผู้อนุมัติ และ Timestamp
Blueprint ที่ทีมสร้างและทีมหน้างานอ่านรู้เรื่อง
ชิ้นงานต้องตอบได้ทั้งทางปกติและวันที่อะไร ๆ ไม่เป็นใจ
Agentic Workflow Blueprint ที่เห็น Current State, Future State, Trigger, Decision, Tool, Data, Exception และ Human Review
- Current/Future Workflow
- Agent Boundary
- Exception Path
- Human Review Point
เพิ่ม Trigger, Definition of Done, Touch/Wait Time, Queue Owner, SLA, Evidence และ Return Path ให้ครบ หากกล่องใดใช้คำว่า “ตรวจสอบ” ให้เขียนต่อว่าใครตรวจ ตรวจอะไร และใช้เกณฑ์ใด
คำนวณ Baseline กระบวนการ →ก่อนนำ Blueprint ไปสร้างจริง
ลองทำให้แผนภาพล้มบนกระดาษก่อน
- หากระบบหลักไม่ตอบ ไฟล์เปิดไม่ได้ หรือข้อมูลขัดกัน งานไปอยู่ที่ใคร และลูกค้ารู้อะไร?
- จุดใดเป็นกฎที่ทดสอบได้ จุดใดเป็นดุลยพินิจ และเราเผลอใช้คำว่า “AI ตัดสินใจ” ปิดบังความต่างนี้หรือไม่?
- Human Review แต่ละจุดให้ข้อมูลพอสำหรับตัดสินใจจริง หรือเป็นเพียงปุ่ม Approve ที่คนมีแนวโน้มกดผ่าน?
Agent ที่ดีไม่ได้ทำทุกขั้นเอง แต่ทำให้แต่ละงานเดินหน้าอย่างมีเจ้าของ ใช้สิทธิ์เท่าที่จำเป็น ทิ้งหลักฐาน และหยุดเมื่อการตัดสินใจเกินขอบเขตที่องค์กรยอมมอบให้
จุดที่ควรหยุดตรวจ
- ทำแผนภาพเฉพาะ Happy Path
- ไม่ระบุเจ้าของ Exception
- ทำให้คนกดอนุมัติโดยไม่มีข้อมูลประกอบ
- วาดชื่อฝ่ายเรียงกัน แต่ไม่ตามงานหนึ่งรายการและไม่ใส่เวลาที่เกิดขึ้นจริง
- เขียน “ส่งให้คน” โดยไม่มี Queue, Owner, SLA, Context และ Return Path
อ่านต่อจากแหล่งต้นทาง
ที่มาของหลักคิดในบทนี้
- Anthropic — Building effective agents ↗
- OpenAI — A practical guide to building agents ↗
- NIST AI RMF — Core functions: Govern, Map, Measure and Manage ↗
- ETDA/AIGC — แนวทางการประยุกต์ใช้ Generative AI อย่างมีธรรมาภิบาลสำหรับองค์กร ↗
ตรวจสอบแหล่งอ้างอิงล่าสุดเมื่อ 17 กันยายน 2569 · กรณีสยามโฟลว์ PO-7842 ตัวเลข แผนภาพ และแบบฝึกเป็นงานต้นฉบับของ ThinkToFinish และเป็นข้อมูลสมมติทั้งหมด