ในขณะที่ฉันกำลังส่งเสริมการนำ AI Agent เข้ามาใช้ในแผนกอื่นๆ ภายใน Notion ซึ่งเป็นส่วนหนึ่งของงาน และให้การสนับสนุนการนำไปปฏิบัติจริงกับบริษัทที่ใช้แนวทาง FDE ฉันก็สังเกตเห็นรูปแบบบางอย่างเกิดขึ้น ฉันได้สร้าง Agent สำหรับฝ่ายขาย, ฝ่ายขายภายใน, การตลาด, การพัฒนาผลิตภัณฑ์, ความสำเร็จของลูกค้า และอื่นๆ อีกมากมาย แต่ทั้งหมดล้วนเผชิญกับอุปสรรคทั่วไปในระดับปฏิบัติการ และอุปสรรคในระดับองค์กร อุปสรรคทั้งสองประเภทนี้เลี่ยงไม่ได้ และฉันเชื่อว่าบริษัทส่วนใหญ่ก็ติดอยู่ที่จุดเดียวกัน
▍อุปสรรคในระดับปฏิบัติการ
① ปัญหาขอบเขตงานที่แคบเกินไป
ฉันลองสร้าง Agent สำหรับฝ่ายขายที่ "ค้นคว้าข้อมูลโดยอัตโนมัติเมื่อมีลีดใหม่เข้ามา" ฉันจินตนาการถึงเวิร์กโฟลว์ทั้งหมด: เมื่อมีผู้มีโอกาสเป็นลูกค้าเข้ามาในลิสต์ Agent จะค้นคว้าและวิเคราะห์ข้อมูลทั้งภายในและภายนอก จากนั้นจึงสร้างร่างอีเมล ฉันเริ่มต้นด้วยการสร้างส่วนที่ค้นคว้าข้อมูลเมื่อมีรายการใหม่เข้ามาในฐานข้อมูลลีด ความตั้งใจของฉันคือเมื่อมีพื้นฐานตรงนี้แล้ว การสร้างอีเมลอัตโนมัติก็จะเป็นเรื่องง่าย
อย่างไรก็ตาม หลังจากตั้งค่าระบบเริ่มต้นและส่งมอบความรับผิดชอบให้ทีมปฏิบัติการ พวกเขาก็ยังไม่ได้ทำให้การร่างอีเมลเป็นอัตโนมัติแม้เวลาจะผ่านไปหลายสัปดาห์ เมื่อฉันสัมภาษณ์พวกเขา พวกเขากลับพูดว่า "แค่ให้มันค้นหาลีดก็สะดวกมากแล้ว!" ทีมงานไม่รู้ว่าพวกเขาสามารถทำได้ถึงขั้นร่างอีเมล หรือความคิดที่จะทำให้เป็นอัตโนมัติขนาดนั้นไม่เคยเกิดขึ้นกับพวกเขาเลย ดูเหมือนพวกเขาจะลังเลเพราะคิดว่ามันยากเกินไป
นี่คือรูปแบบแรกที่ทำให้การนำ Agent ไปใช้หยุดชะงัก: การทำให้ขอบเขตงานแคบเกินไป ส่งผลให้การใช้งานให้ผลตอบแทนต่ำ ทั้งที่สร้าง Agent ขึ้นมาแล้ว มันกลับถูกใช้แค่ฟังก์ชันเดี่ยวๆ หรืองานเล็กๆ น้อยๆ เท่านั้น
② ปัญหาการหยุดชะงักเพราะขอบเขตใหญ่เกินไป
ปัญหาที่สองคือตรงกันข้าม: การพยายามเปลี่ยนกระบวนการทางธุรกิจที่ซับซ้อนให้เป็น Agent แต่กลับพบว่ากระบวนการนั้นไม่ได้ถูกจัดโครงสร้างไว้อย่างละเอียดชัดเจน คนแต่ละคนมีวิธีการทำงานที่แตกต่างกัน หรือมีความรู้ที่ฝังลึก (tacit knowledge) มากเกินไป การพยายามทำให้ละเอียดถี่ถ้วนเกินไปส่งผลให้เวลาหมดไปกับการสัมภาษณ์เพียงอย่างเดียว โดยไม่เคยถึงขั้นตอนการสร้างเลย จำนวนผู้มีส่วนได้ส่วนเสียเพิ่มขึ้น และต้นทุนในการสร้างฉันทามติก็พองตัว ความกระตือรือร้นในช่วงแรกค่อยๆ จางหายไป...
นี่คือปัญหาเรื่องการกำหนดขอบเขตในการบริหารโครงการ คุณต้องการทำอะไรกับ Agent? คุณต้องการบรรลุผลลัพธ์อะไร? ถ้าผลลัพธ์ถูกกำหนดไว้แล้ว ขอบเขตที่จำเป็นและเพียงพอสำหรับ Agent ก็จะถูกกำหนดตามนั้น การตั้งเป้าอย่างคลุมเครือว่า "เพิ่มประสิทธิภาพทางธุรกิจด้วย Agent" จะนำไปสู่ความยุ่งยาก
③ การไม่มีเจ้าของที่ชัดเจน
แม้ว่าผู้ริเริ่มจะสร้างมันขึ้นมาด้วยแรงผลักดัน แต่ถ้าความรับผิดชอบในการปรับปรุงหรือแก้ไขข้อบกพร่องไม่ชัดเจน การใช้งานก็จะค่อยๆ ลดลง ผู้ริเริ่มก็หมดแรงเช่นกัน ตามหลักการแล้ว ทีมปฏิบัติการควรดูแล Agent เสมือนเป็นของตัวเอง หากสิ่งนี้ขาดหายไป ทุกอย่างจะดูดีในช่วงสามเดือนแรก แต่จะไม่สามารถขยายผลได้ เมื่อจำนวนผู้มีส่วนได้ส่วนเสียเพิ่มขึ้น โดยเฉพาะอย่างยิ่งเมื่อขอบเขตงานกว้างขึ้น ความจำเป็นในการสร้างฉันทามติและการยืนยันก็เพิ่มขึ้น และความรู้สึกเป็นเจ้าของ (ใครเป็นเจ้าของมัน) ก็ค่อยๆ จางหายไป
ปัญหาทั้งสามนี้ไม่ได้แยกจากกัน แต่เชื่อมโยงกันทั้งหมด หากการออกแบบขอบเขตผิดพลาด ความเป็นเจ้าของก็จะไม่เกิดขึ้น และหากไม่มีเจ้าของ ขอบเขตก็จะไม่ขยายออก
▍อุปสรรคในระดับองค์กร
แม้ว่าคุณจะเอาชนะอุปสรรคในระดับปฏิบัติการได้แล้ว ก็ยังมีกำแพงอีกสี่ประการที่อยู่นอกเหนือแค่ "การสร้างสิ่งที่ใช้งานได้" ในองค์กรขนาดใหญ่
④ ความโปร่งใสของทุน Token
แม้ว่าการใช้ Token จะมองเห็นได้ในแต่ละแผนก แต่ก็มักจะไม่ชัดเจนว่า "ทำงานประเภทไหนและได้ผลลัพธ์อะไร" สิ่งนี้กลายเป็นปัญหาในมุมมองของทุน Token และการจัดการ Token ทำให้ไม่สามารถอธิบายเหตุผลของงบประมาณได้ ผลที่ตามมาคือฝ่ายบริหารมองว่า Token เป็นเพียงต้นทุนการบริโภค และถามว่า "แล้วมันจะเสียค่าใช้จ่ายเท่าไหร่?"
⑤ การกำกับดูแล (Governance)
ใครสามารถสร้าง Agent ได้บ้าง ใครสามารถดูได้บ้าง และใครเป็นผู้จัดการ? ถ้าสิ่งนี้ไม่ชัดเจน องค์กรจะเต็มไปด้วย "Agent ไร้สังกัด" หรือ "Agent ซอมบี้" ที่ทำงานแต่ไม่มีใครใช้ ไม่มีใครรับผิดชอบ ไม่มีงบประมาณที่มั่นคง Token ถูกใช้ไปอย่างสิ้นเปลือง ความเสี่ยงด้านความปลอดภัยเพิ่มขึ้น จนกระทั่งทุกอย่างต้องหยุดชะงัก
⑥ การสังเกตการณ์ได้ (Observability)
Agent ทำงานกี่ครั้ง สำเร็จบ่อยแค่ไหน และล้มเหลวตรงไหน? นี่คือข้อกำหนดขั้นต่ำสำหรับการดำเนินงาน แต่เครื่องมือหลายอย่างยังอ่อนแอในจุดนี้ คุณไม่สามารถปรับปรุงสิ่งที่คุณมองไม่เห็นได้ การมี Observability เท่านั้นจึงจะสามารถสร้างวงจรป้อนกลับสำหรับการปรับปรุง Agent ได้
⑦ ความยืดหยุ่นในการเลือกโมเดล
การพึ่งพาผู้ให้บริการ LLM รายใดรายหนึ่งมากเกินไปถือเป็นความเสี่ยง จะเกิดอะไรขึ้นถ้าประสิทธิภาพลดลงชั่วคราว? จะเกิดอะไรขึ้นถ้ามันหยุดทำงานเนื่องจากความล้มเหลว? จะเกิดอะไรขึ้นถ้าข้อจำกัดการส่งออกทำให้ไม่สามารถใช้งานได้? หากคุณไม่สามารถเปลี่ยนไปใช้ผู้ให้บริการรายอื่นได้ทันที คุณจะไม่สามารถนำ Agent ที่เชื่อมโยงโดยตรงกับการดำเนินธุรกิจไปใช้ได้ AI กลายเป็นโครงสร้างพื้นฐานแล้ว แต่การพึ่งพาอย่างสุดขั้วยังคงถูกยอมรับอย่างไม่ลืมหูลืมตาในปัจจุบัน
สรุป
การนำ Agent ไปใช้ดูเหมือนเป็นการพูดคุยเชิงเทคนิค แต่แท้จริงแล้วมันเกี่ยวกับการออกแบบธุรกิจและความเป็นเจ้าของ เพื่อให้แน่ใจว่ามันจะไม่จบลงแค่ "AI นั้นน่าทึ่ง" จำเป็นต้องมีพื้นฐานสำหรับการกำกับดูแลและการสังเกตการณ์ได้ก่อน
ไม่เล็กเกินไป ไม่ใหญ่เกินไป และได้รับการดูแลโดยผู้ที่มีความรับผิดชอบ และมีระบบที่สนับสนุนสิ่งนั้นในฐานะองค์กร ฉันเชื่อว่า Agent จะหยั่งรากได้ก็ต่อเมื่อทั้งระดับปฏิบัติการและระดับองค์กรสอดคล้องกันเท่านั้น
