องค์กรอยากเริ่มใช้ AI แต่ควรเริ่มจากปัญหาไหนก่อน

เมื่อผู้บริหารบอกว่าองค์กรควรมีโครงการ AI คำถามถัดไปมักสร้างความเงียบในห้องประชุม: แล้วจะเริ่มจากงานอะไร

แต่ละฝ่ายอาจมีคำตอบของตัวเอง ทีมขายอยากได้ผู้ช่วยสรุปข้อมูล ทีมบริการอยากลดงานซ้ำ ทีม Operations อยากให้ขั้นตอนเร็วขึ้น ส่วน IT ต้องมองเรื่องระบบ ข้อมูล และความปลอดภัยพร้อมกัน หากรีบเลือกจากรายการเทคโนโลยี โครงการอาจมีขอบเขตกว้างจนไม่มีใครตอบได้ว่าผลลัพธ์ที่ต้องการคืออะไร

การเริ่มต้นที่ดีจึงอยู่ที่การหา Business Problem ซึ่งมีเจ้าของปัญหา ผลกระทบ และกระบวนการที่มองเห็นได้ชัด แล้วจึงพิจารณาว่า AI Solution เหมาะกับส่วนใดของปัญหานั้น

ทำไมคำว่า “อยากใช้ AI” ยังไม่ใช่โจทย์โครงการ

AI เป็นแนวทางหนึ่งในการแก้ปัญหา ไม่ได้อธิบายว่าธุรกิจกำลังติดขัดตรงไหน ประโยคอย่าง “อยากทำ AI Agent” หรือ “อยากนำ Generative AI มาใช้” ช่วยบอกความสนใจด้านเทคโนโลยี แต่ยังขาดข้อมูลสำคัญสำหรับออกแบบ Solution

โจทย์ที่นำไปทำงานต่อได้ควรระบุให้เห็นว่า:

•          ใครกำลังพบปัญหา

•          ปัญหาเกิดขึ้นในขั้นตอนไหน

•          วิธีปัจจุบันสร้างภาระ ความล่าช้า หรือความเสี่ยงอย่างไร

•          ผลลัพธ์แบบใดถือว่าดีขึ้น

•          มีข้อจำกัดด้านข้อมูล ระบบ หรือการอนุมัติอะไรบ้าง

ตัวอย่างเช่น “ทีมบริการใช้เวลาหลังจบสายเพื่ออ่านโน้ตและส่งเรื่องให้หน่วยงานที่เกี่ยวข้อง” ให้ภาพที่ชัดกว่า “อยากใช้ Voice AI” เพราะทีมสามารถสำรวจขั้นตอน ผู้รับผิดชอบ และข้อมูลที่ต้องใช้ต่อได้ทันที

วิธีค้นหา Business Problem ที่เหมาะกับ AI

1. มองหางานที่เกิดซ้ำและกินเวลาของคน

งานซ้ำเป็นจุดเริ่มต้นที่สำรวจได้ง่าย เช่น การอ่านเอกสารจำนวนมาก การสรุปบทสนทนา การจัดประเภทข้อมูล หรือการค้นหาคำตอบจากข้อมูลหลายแหล่ง อย่างไรก็ตาม ความถี่เพียงอย่างเดียวยังไม่พอ ต้องดูด้วยว่างานนั้นมีกติกาและข้อมูลรองรับมากน้อยเพียงใด

2. หาจุดที่ข้อมูลมีอยู่ แต่ทีมใช้ประโยชน์ได้ยาก

หลายองค์กรมีข้อมูลอยู่ในไฟล์เสียง เอกสาร ข้อความ หรือระบบหลายชุด ปัญหาอาจไม่ได้อยู่ที่การขาดข้อมูล แต่อยู่ที่ข้อมูลค้นหายาก ไม่มีโครงสร้าง หรือไม่ถึงมือคนที่ต้องตัดสินใจทันเวลา จุดนี้อาจเปิดโอกาสให้ AI ช่วยประมวลผล จัดระเบียบ หรือสนับสนุนการค้นหา

3. สำรวจจุดตัดสินใจที่ต้องใช้ข้อมูลจำนวนมาก

บางงานไม่ได้ทำซ้ำในรูปแบบเดิมทุกครั้ง แต่ผู้ปฏิบัติงานต้องรวบรวมข้อมูลหลายส่วนก่อนตัดสินใจ AI อาจช่วยเตรียมข้อมูลหรือเสนอสิ่งที่ควรตรวจสอบ ส่วนการตัดสินใจสุดท้ายยังสามารถอยู่กับคนตามระดับความเสี่ยงของงาน

4. ฟังปัญหาจากผู้ใช้หน้างาน

Workflow ที่เขียนบนกระดาษอาจต่างจากวิธีทำงานจริง พนักงานอาจต้องสลับหน้าจอ คัดลอกข้อมูล หรือใช้ไฟล์ส่วนตัวเพื่ออุดช่องว่างของระบบ การพูดคุยกับผู้ใช้ช่วยให้ทีมเห็น Pain Point ที่เอกสาร Process ไม่ได้บันทึกไว้

จัดลำดับ Use Case อย่างไรให้ตัดสินใจง่ายขึ้น

เมื่อได้รายการปัญหาแล้ว ไม่จำเป็นต้องทำทุกเรื่องพร้อมกัน การจัดลำดับควรมองอย่างน้อย 5 ด้าน

ผลกระทบต่อธุรกิจ

ปัญหาส่งผลต่อรายได้ ต้นทุน คุณภาพบริการ ความเสี่ยง หรือประสบการณ์ของลูกค้าอย่างไร ควรอธิบายผลกระทบด้วยหลักฐานที่องค์กรมีอยู่ แทนการตั้งเป้ากว้าง ๆ ว่า “เพิ่มประสิทธิภาพ”

ความชัดเจนของกระบวนการ

ทีมเข้าใจขั้นตอนปัจจุบันหรือยัง รู้หรือไม่ว่าใครส่งข้อมูลให้ใคร และจุดใดเป็นคอขวด หาก Process ยังไม่ชัด การใส่ AI อาจทำให้ความซับซ้อนเดิมถูกย้ายเข้าไปอยู่ในระบบใหม่

ความพร้อมของข้อมูล

ต้องใช้ข้อมูลอะไร ข้อมูลอยู่ที่ใด มีรูปแบบอย่างไร และสามารถนำมาใช้ตามข้อกำหนดขององค์กรได้หรือไม่ การตรวจเรื่องนี้ตั้งแต่ต้นช่วยให้ทีมประเมินความเป็นไปได้ตรงกับสภาพจริง

ความพร้อมในการเชื่อมต่อ

AI ต้องทำงานร่วมกับระบบใดบ้าง หากผลลัพธ์ยังต้องถูกคัดลอกด้วยคนทุกครั้ง ประโยชน์อาจเกิดขึ้นเพียงบางส่วน ทีมควรเห็นภาพ Data Flow และเจ้าของระบบที่เกี่ยวข้องก่อนเริ่มพัฒนา

ความสามารถในการวัดผล

Use Case แรกควรมี Baseline ที่พอใช้เปรียบเทียบได้ เช่น เวลาที่ใช้ จำนวนขั้นตอน ปริมาณงานที่ต้องแก้ไข หรือคุณภาพตามเกณฑ์ภายใน ตัวชี้วัดต้องสอดคล้องกับปัญหา ไม่จำเป็นต้องเริ่มด้วยตัวเลขผลตอบแทนขนาดใหญ่

จากคำขอ “อยากใช้ AI กับ Call Center” สู่โจทย์ที่ออกแบบได้

สมมติว่าทีมบริการเสนอให้ใช้ AI กับ Call Center หากหยุดอยู่ตรงนี้ ขอบเขตอาจครอบคลุมตั้งแต่ตอบคำถาม ถอดเสียง วิเคราะห์บทสนทนา ไปจนถึงประเมินพนักงาน

ทีมโครงการควรลงไปดูขั้นตอนจริงและอาจพบว่า หลังจบสาย พนักงานต้องสรุปประเด็น เลือกประเภทเรื่อง และส่งต่อให้ทีมอื่น ปัญหาที่ควรทดลองจึงอาจถูกกำหนดใหม่เป็น “ช่วยจัดเตรียมสรุปและข้อมูลที่จำเป็นสำหรับการส่งต่อ โดยให้พนักงานตรวจสอบก่อนบันทึก”

โจทย์ใหม่นี้มีผู้ใช้ ข้อมูล Input จุดตรวจสอบ และผลลัพธ์ชัดกว่าเดิม ทีมสามารถออกแบบการทดลอง ประเมินคุณภาพ และดูว่าการเชื่อมกับระบบเดิมจำเป็นตรงไหน โดยไม่ต้องสร้างทุกความสามารถในครั้งเดียว

เริ่มเล็กอย่างไรโดยไม่เสียภาพใหญ่

การเริ่มจาก Use Case เดียวไม่ได้แปลว่าองค์กรต้องคิดแบบแยกส่วน แผนที่ดีควรมองทั้งเส้นทางตั้งแต่ข้อมูล ผู้ใช้ ระบบ ไปจนถึงการดูแลหลังใช้งาน แล้วเลือกขอบเขตแรกที่เรียนรู้ได้เร็วและมีความหมายต่อธุรกิจ

แนวทางเริ่มต้นประกอบด้วย:

1.        นิยามปัญหาและเจ้าของปัญหาให้ชัด

2.        บันทึก Workflow ปัจจุบันจากการทำงานจริง

3.        กำหนดผลลัพธ์และ Baseline ก่อนออกแบบ Solution

4.        ตรวจข้อมูล ระบบ ข้อกำหนด และจุดที่ต้องมีคนควบคุม

5.        ทดลองในขอบเขตที่บริหารจัดการได้

6.        เก็บ Feedback จากผู้ใช้และปรับ Solution

7.        ตัดสินใจขยายผลจากหลักฐานที่ได้

สรุป: เริ่มจากปัญหาที่สำคัญและเรียนรู้ได้จริง

องค์กรไม่จำเป็นต้องรอให้มี AI Strategy ที่ตอบได้ทุกเรื่องก่อนเริ่ม สิ่งที่ต้องมีคือปัญหาที่นิยามชัด เจ้าของงานที่พร้อมเข้าร่วม ข้อมูลที่ตรวจสอบได้ และวิธีวัดว่ากระบวนการดีขึ้นหรือไม่

AppMan วางบทบาท One Partner เพื่อช่วยเชื่อมมุมมองของ Business, Operations และ Technology ตั้งแต่การหาโจทย์ วางแนวทาง ออกแบบ พัฒนา เชื่อมต่อ และปรับปรุง Solution ให้สอดคล้องกับการใช้งานจริง

หากทีมมีหลายไอเดียเกี่ยวกับ AI แต่ยังเลือกจุดเริ่มต้นไม่ได้ ติดต่อ AppMan เพื่อร่วมสำรวจ Business Problem จัดลำดับ Use Case และวาง Success Blueprint สำหรับโครงการ AI ขององค์กร