โครงการนำร่องทั่วไปหน้าตาเป็นอย่างไร
มีคนในองค์กรถูกขอให้ “ทำอะไรสักอย่างกับ AI” ผู้ขายหรือทีมภายในเลือกกระบวนการมาหนึ่งอย่าง เช่น ใบแจ้งหนี้ เคลม หรือเรื่องร้องเรียน แล้วสร้างเดโมขึ้นมา มันอ่าน PDF ภาษาอังกฤษที่สะอาดเรียบร้อย กรอกฟิลด์ และเสนอคำตอบ เดโมผ่านไปด้วยดี ทุกคนเห็นตรงกันว่าน่าประทับใจ
หกเดือนต่อมา มันก็ยังเป็นเดโม ไม่มีใครปิดมัน มันแค่ไม่เคยกลายเป็นวิธีทำงานจริง ทีมยังคงคีย์ข้อมูล ตามเอกสาร และตัดสินใจแบบเดิม
ทั่วทั้งภูมิภาค นี่คือผลลัพธ์ปกติ ไม่ใช่ข้อยกเว้น เวลามีคนอธิบาย มักโทษโมเดล ว่าไม่แม่นพอ ยังไม่พร้อมสำหรับเอกสารของเรา แต่นั่นแทบไม่เคยเป็นเหตุผลที่แท้จริง
สี่เรื่องที่ถูกข้ามไป
ข้อมูลขาเข้าจริง เดโมอ่าน PDF ที่สะอาด แต่งานจริงมาในรูปภาพถ่ายใบแจ้งหนี้จากมือถือ เอกสารสแกนที่มีตราประทับทับยอดรวม ข้อความ WhatsApp ที่แนบไฟล์สามไฟล์กับข้อความเสียง อีเมลที่ถูกส่งต่อมาสองทอด โครงการนำร่องที่ไม่เคยเห็นข้อมูลจริงเลย ถือว่ายังไม่เคยถูกทดสอบ
ระบบ การตัดสินใจต้องอาศัยข้อเท็จจริงที่ไม่มีในเอกสาร: ซัพพลายเออร์รายนี้เป็นที่รู้จักไหม มีใบสั่งซื้อที่ยังเปิดอยู่ไหม เคลมนี้เคยเข้ามาแล้วหรือยัง ลูกค้าจ่ายไปเท่าไร ถ้าโครงการนำร่องอ่านระบบบัญชี ระบบหลัก หรือ CRM ของคุณไม่ได้ มันก็ได้แต่เดา และถ้ามันเขียนผลลัพธ์กลับเข้าระบบไม่ได้ ก็ยังต้องมีคนคีย์เองอยู่ดี
ภาษา ไทย เวียดนาม บาฮาซา ตากาล็อก และอังกฤษ ซึ่งมักปนกันในหน้าเดียวหรือในแชตเดียว โมเดลที่อ่านภาษาอังกฤษได้ดีแต่ภาษาอื่นได้แค่คร่าว ๆ จะพลาดตรงเอกสารและข้อความที่เป็นปริมาณงานส่วนใหญ่พอดี
ขั้นตอนตรวจทานและอนุมัติ ทุกการตัดสินใจมีคนรับผิดชอบ โครงการนำร่องที่ให้คำตอบออกมาโดยไม่มีที่ให้คนตรวจ แก้ และลงนามรับรอง ย่อมไม่ให้เหตุผลที่คนคนนั้นจะไว้ใจ และไม่มีทางให้เขาอธิบายการตัดสินใจต่อผู้ตรวจสอบบัญชี หน่วยงานกำกับ หรือลูกค้าในภายหลัง
ทำไมคุณภาพของโมเดลแทบไม่เคยเป็นสาเหตุ
โมเดลทุกวันนี้อ่านเอกสารได้ดี และโมเดลขนาดเล็กก็ปรับจูนกับเอกสารและภาษาของคุณได้ด้วยต้นทุนไม่สูง เมื่อโครงการนำร่องล้มเหลว แทบไม่เคยเป็นเพราะอ่านไม่ได้ แต่เป็นเพราะการอ่านคือส่วนเดียวที่ถูกสร้างขึ้นมา
ส่วนที่เหลือ ทั้งการเชื่อมต่อกับระบบของคุณ การรับมือกับช่องทางที่ยุ่งเหยิง กฎที่ทีมคุณใช้อยู่แล้ว รายการการตัดสินใจ หน้าจอตรวจทาน และบันทึก ล้วนเป็นงานวิศวกรรมที่ไม่หวือหวา แต่มันคืองานส่วนใหญ่ และเป็นตัวตัดสินว่าจะมีใครใช้ผลลัพธ์นั้นหรือไม่
“ใช้งานจริงแล้ว” ต้องมีอะไรบ้าง
กระบวนการหนึ่งถือว่าใช้งานจริงแล้ว เมื่อเคสเข้ามาทางช่องทางจริง เอเจนต์จัดการเคสโดยใช้ระบบจริงของคุณ การตัดสินใจถูกเขียนกลับไปยังที่ที่ควรอยู่ เคสที่ไม่แน่ใจส่งไปยังคนที่ระบุชื่อไว้ และทุกขั้นตอนถูกบันทึกละเอียดพอจะตอบคำถาม “ทำไม?” ได้แม้ผ่านไปหลายเดือน
และอีกข้อหนึ่ง: คนที่มีอำนาจได้ดูตัวเลขแล้ว ว่าจัดการได้กี่รายการ ผิดบ่อยแค่ไหน แต่ละรายการมีต้นทุนเท่าไร และตัดสินใจเปิดใช้ ถ้าไม่มีการตัดสินใจนั้น มันก็ยังเป็นโครงการนำร่อง ไม่ว่าจะทำงานได้ดีแค่ไหน
วิธีการของเราแก้แต่ละเรื่องอย่างไร
วางผัง คือบันทึกกระบวนการจริงก่อนสร้างอะไร: ทุกช่องทางที่งานเข้ามา ทุกระบบที่เกี่ยวข้อง รายการการตัดสินใจ ใครตัดสินใจในปัจจุบัน และผู้ตรวจสอบบัญชีต้องการอะไร ไม่มีอะไรที่อนุมานเอาจากตัวอย่างที่สะอาดเรียบร้อย
วัดผล รันบนใบแจ้งหนี้ เคลม หรือใบสมัครในอดีตของคุณ 200–500 รายการ ในภาษาของคุณ พร้อมผลลัพธ์ที่รู้อยู่แล้ว การประเมินบอกว่าเอเจนต์จะจัดการได้กี่เปอร์เซ็นต์ ผิดตรงไหน และคุ้มค่าแค่ไหน ก่อนที่คุณจะตกลงสร้าง ถ้าตัวเลขไม่ลงตัว เราจะบอกตรง ๆ
การรันคู่ขนาน สร้างการเชื่อมต่อ กฎ และหน้าจอตรวจทาน แล้วรันบนข้อมูลจริงคู่ขนานไปกับทีมของคุณโดยไม่มีอะไรถูกดำเนินการ ผู้ตรวจทานของคุณเห็นทุกขั้นตอน คุณเห็นตัวเลขทุกสัปดาห์
เปิดใช้ เป็นการตัดสินใจของคุณ ทีละประเภทการตัดสินใจ การจ่ายเงินและการคืนเงินยังอยู่ในมือคน จนกว่าตัวเลขจะบอกเป็นอย่างอื่น
ไม่มีอะไรในนี้ที่ฉลาดล้ำ มันคืองานที่โครงการนำร่องส่วนใหญ่ข้ามไป