sarunjade_

ทำไมองค์กรทำ AI Transformation แล้วไม่สำเร็จ — Pilot ถึงค้างอยู่ที่ PoC

จ้างที่ปรึกษามาวางแผน AI transformation ไปแล้ว ประชุมกันหลายรอบ ทำ proof of concept (PoC) จนเดโมออกมาสวยงาม แต่ผ่านไปสามเดือน หกเดือน โปรเจกต์ก็ยังค้างอยู่ตรงนั้น ไม่มีใครในทีมใช้งานจริง ไม่มีระบบไหน "ไปต่อ" เป็นโปรดักชันจริง

นี่ไม่ใช่เรื่องแปลกหรือเป็นเพราะทีมของคุณไม่เก่งพอ

งานวิจัยของ MIT พบว่า 95% ของโครงการ generative AI ในองค์กรที่สำรวจไม่สร้างผลตอบแทนที่วัดได้เลย และ RAND Corporation พบว่า 80.3% ของโครงการ AI องค์กรล้มเหลวในการส่งมอบคุณค่าทางธุรกิจตามที่ตั้งเป้า

ฝั่ง BCG เองก็รายงานตัวเลขที่ไปในทิศทางเดียวกัน — ในการสำรวจปี 2024 มีถึง 74% ขององค์กรที่ยังพิสูจน์คุณค่าที่จับต้องได้จาก AI ไม่ได้ และในรายงานปี 2025 มีเพียง 5% ขององค์กรเท่านั้นที่ทำให้ AI สร้างมูลค่าได้ "ในสเกล" จริง ขณะที่ 60% ยังไม่ได้มูลค่าที่เป็นชิ้นเป็นอันเลยแม้จะลงทุนไปมาก (bcg.com)

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

สารบัญ

PoC ค้าง คืออะไร ทำไมถึงเกิดขึ้นบ่อยขนาดนี้

"Pilot ค้างที่ PoC" หมายถึงสถานการณ์ที่องค์กรทำโครงการ AI ในสเกลเล็ก (มักเป็น 1 แผนก หรือ 1 use case) จนเดโมสำเร็จ พิสูจน์ได้ว่า "เทคโนโลยีทำงานได้จริง" แต่ไม่เคยขยับไปสู่การใช้งานจริงในสเกลทั้งองค์กร (production) เลย ในทางปฏิบัติ อาการที่เจอบ่อยคือโครงการเข้าสู่สถานะ "เกือบเสร็จตลอดกาล" — เอกสารสรุปผล PoC เขียนเสร็จ ผู้บริหารพยักหน้าในที่ประชุม แต่ไม่มีใครกำหนดวันที่ระบบจะย้ายเข้าสู่ขั้นตอนถัดไปอย่างเป็นทางการ

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

พูดอีกแบบ PoC ตอบคำถามว่า "ทำได้ไหม" แต่ไม่เคยตอบคำถามที่สำคัญกว่าคือ "ทำแล้วใครดูแล ใครใช้ต่อ และใช้ต่อได้นานแค่ไหนโดยไม่มีที่ปรึกษาคอยประคอง" องค์กรจำนวนมากจึงติดอยู่ในวงจรทำ PoC ใหม่ทุกปีโดยไม่เคยมีระบบไหนไปถึง production เลยสักตัว

บริษัทวิจัย Connected Paths อ้างอิงข้อมูลจาก RAND ว่าใน 33 โครงการ PoC ที่องค์กรเริ่มทำ มีเพียง 4 โครงการเท่านั้นที่ไปถึงขั้น production จริง

คิดเป็นอัตราความสำเร็จเพียงราว 12% เท่านั้น

ส่วนที่เหลืออีกเกือบ 9 ใน 10 โครงการจบลงที่สไลด์นำเสนอผล ไม่ใช่ระบบที่พนักงานเปิดใช้งานทุกวัน (connectedpaths.com)

ทำไมเรื่องนี้ถึงสำคัญ — ต้นทุนของการปล่อยให้ pilot ค้าง

การปล่อยให้ PoC ค้างไม่ใช่แค่เสียเวลา แต่มีต้นทุนจริงที่วัดได้ และต้นทุนเหล่านี้มักไม่ปรากฏในรายงานการเงินจนกว่าจะสายเกินไป:

  • เงินจม — ตามข้อมูลของ S&P Global ที่อ้างอิงในงานวิจัยเดียวกัน องค์กรขนาดใหญ่ (พนักงานมากกว่า 10,000 คน) ยกเลิกโครงการ AI เฉลี่ย 2.3 โครงการต่อปีในปี 2025 โดยแต่ละโครงการที่ถูกพับมีต้นทุนจมเฉลี่ยราว 7.2 ล้านดอลลาร์สหรัฐ (connectedpaths.com) ตัวเลขนี้ไม่ได้รวมแค่ค่าที่ปรึกษาหรือค่าไลเซนส์ซอฟต์แวร์ แต่รวมชั่วโมงทำงานของทีมภายในที่ถูกดึงออกจากงานประจำมาเข้าประชุม ทดสอบ และรีวิว PoC ตลอดหลายเดือน ซึ่งเป็นต้นทุนแฝงที่แทบไม่เคยถูกนับรวมในงบโครงการตั้งแต่แรก
  • ความเชื่อมั่นในทีมลดลง — เมื่อ pilot ตายซ้ำหลายรอบ พนักงานเริ่มมองโครงการ AI ใหม่ ๆ ว่าเป็น "ของเล่นผู้บริหาร" ไม่ใช่เครื่องมือทำงานจริง ทำให้ครั้งต่อไปยิ่งได้ buy-in ยากขึ้น ผลข้างเคียงที่พบบ่อยคือทีมงานเริ่มปฏิเสธเข้าร่วมโครงการ AI รอบใหม่อย่างเงียบ ๆ — ไม่ปฏิเสธตรง ๆ แต่ให้ความร่วมมือน้อยลง ตอบช้าลง ทดสอบไม่ครบ เพราะเรียนรู้จากรอบก่อนว่าโครงการแบบนี้ "ไม่ไปไหนต่ออยู่ดี" การกู้ความเชื่อมั่นกลับมาหลัง pilot ตายซ้ำสองสามรอบ ใช้เวลานานกว่าการสร้างความเชื่อมั่นในโครงการแรกเสียอีก
  • คู่แข่งไปไกลกว่า — ขณะที่องค์กรหนึ่งวนอยู่กับ PoC รอบที่สาม คู่แข่งที่แก้จุดคนและกระบวนการได้ก่อนก็เอาความสามารถนั้นไปใช้แข่งขันจริงแล้ว ข้อมูลของ BCG ปี 2025 ชี้ให้เห็นช่องว่างนี้ชัดเจน — องค์กรที่จัดอยู่ในกลุ่ม "ผู้นำ" ด้าน AI มีการเติบโตของรายได้เป็นสองเท่าและประหยัดต้นทุนได้มากกว่ากลุ่ม "ผู้ตาม" ถึง 40% (bcg.com) ช่องว่างนี้ไม่ได้เกิดจากการเข้าถึงเทคโนโลยีที่ต่างกัน เพราะทุกองค์กรซื้อโมเดล AI ตัวเดียวกันได้ในราคาใกล้เคียงกัน

ช่องว่างเกิดจากว่าใครทำให้ pilot ไปถึง production ได้ก่อน

สาเหตุหลักที่ pilot ไปไม่ถึง production

1. ลงทุนกับเทคโนโลยี แต่ไม่ลงทุนกับคน

งานวิจัยที่สรุปโดย Bosio Digital ชี้ว่ามีเพียง 37% ขององค์กรเท่านั้นที่ลงทุนอย่างจริงจังกับ change management แรงจูงใจ หรือการฝึกอบรม

หมายความว่า 63% ขององค์กรที่ทำ AI transformation กำลังทุ่มงบส่วนใหญ่ไปกับเทคโนโลยีและอัลกอริทึม (30% ของสมการมูลค่า) แต่ละเลยฝั่งคน องค์กร และกระบวนการ (70% ของสมการ) (bosio.digital) นี่คือสาเหตุอันดับต้น ๆ ที่ PoC ที่ "ทำงานได้" ทางเทคนิค กลับไม่มีใครใช้ต่อ

ในทางปฏิบัติ สัดส่วนงบประมาณที่พบบ่อยในโครงการ AI transformation คือ 80-90% ไหลไปที่ค่าที่ปรึกษา ค่าไลเซนส์ซอฟต์แวร์ และค่าพัฒนาโมเดล เหลือให้กับการฝึกอบรมทีมงาน การออกแบบ workflow ใหม่ และการสื่อสารการเปลี่ยนแปลงเพียงเศษเสี้ยว ทั้งที่งานวิจัยชี้ตรงกันข้ามว่าสัดส่วนนี้ควรกลับด้าน

2. ผู้บริหารหายไปหลังเดโมจบ

ผู้บริหารมักโฟกัสพลังงานตอนอนุมัติงบและช่วงเดโม แต่หายไปตอนที่งานยากจริง ๆ เริ่มขึ้น — การปรับกระบวนการทำงาน การจัดสรรทรัพยากรให้ทีมดูแลระบบต่อ การผลักดันให้แผนกอื่นยอมเปลี่ยนวิธีทำงาน

งานวิเคราะห์จาก Vantage Point ระบุว่าความล้มเหลวของโครงการ AI ราว 77% มีต้นตอจากปัจจัยองค์กร ไม่ใช่ปัจจัยทางเทคนิค และผู้นำที่ไม่ติดตามงานต่อเนื่อง (ไม่ใช่ความพร้อมของพนักงาน) คือตัวแปรหลักที่ขวางการขยายสเกล (vantagepoint.io)

รูปแบบที่พบซ้ำ ๆ คือผู้บริหารระดับ sponsor เข้าร่วมประชุม kickoff และประชุมสรุปผล PoC สองครั้งเท่านั้น ระหว่างนั้นมอบหมายให้ทีมกลางระดับปฏิบัติการดูแลเอง โดยไม่มีอำนาจตัดสินใจข้ามแผนกหรืออนุมัติงบขยายสเกล เมื่อ PoC จบและต้องการการตัดสินใจระดับองค์กร (เช่น จะให้แผนกอื่นเปลี่ยนวิธีทำงานตามระบบใหม่หรือไม่) ก็ไม่มีใครมีอำนาจตัดสินใจนั้นในห้องประชุม โครงการจึงค้างรอการอนุมัติที่ไม่มีวันมาถึง

3. ไม่มีการถ่ายโอนความสามารถให้ทีมภายใน

ที่ปรึกษาวางแผนและสร้าง PoC ให้ แต่เมื่อโปรเจกต์จบ ไม่มีใครในองค์กรเข้าใจวิธีดูแล ปรับแต่ง หรือขยายระบบต่อด้วยตัวเอง — โครงการเลยจอดสนิททันทีที่สัญญาที่ปรึกษาหมด อาการที่พบบ่อยคือทีมภายในไม่เคยได้เข้าถึง source code หรือเอกสารทางเทคนิคเต็มรูปแบบระหว่างโครงการ เพราะที่ปรึกษาทำงานแบบ "ปิดกล่อง" ส่งมอบแค่ผลลัพธ์และรายงานสรุป เมื่อเกิดปัญหาเล็ก ๆ หลังส่งมอบ เช่น ข้อมูลเปลี่ยนรูปแบบ หรือระบบต้นทางอัปเดตเวอร์ชัน ทีมภายในไม่มีความสามารถแก้ไขเอง ต้องกลับไปจ้างที่ปรึกษาคนเดิมซ่อม ซึ่งมักไม่คุ้มค่าเมื่อเทียบกับสัญญาที่ปิดไปแล้ว ระบบจึงถูกปล่อยทิ้งไว้เงียบ ๆ

นี่คือรูปแบบที่ผูกกับหัวข้ออื่นในชุดบทความนี้เรื่อง "บริษัทเคยจ้างที่ปรึกษา/ซื้อคอร์ส AI แล้วแต่ทีมทำต่อเองไม่ได้ — ทำไม" ซึ่งขยายความสาเหตุด้านนี้โดยเฉพาะ

4. เลือก use case ที่น่าตื่นเต้นทางเทคนิค แต่ไม่ตรงกับปัญหาธุรกิจจริง

Use case ที่ทำ PoC มักถูกเลือกเพราะ "เจ๋งดี" หรือโชว์ศักยภาพของ AI ได้ชัด ไม่ใช่เพราะแก้ปัญหาที่ทีมงานเจอทุกวันจริง ๆ เมื่อ PoC จบ ก็ไม่มีใครรู้สึกว่ามันช่วยงานตัวเองได้จริง แรงผลักดันให้ไปต่อจึงหายไป ตัวอย่างรูปแบบที่พบบ่อยคือทีมเทคโนโลยีเลือก use case จากมุมมองว่า "โมเดลอะไรทำสิ่งนี้ได้ดีที่สุดตอนนี้" แทนที่จะเริ่มจากมุมมองว่า "งานไหนที่พนักงานเสียเวลามากที่สุดต่อสัปดาห์" ผลคือได้ PoC ที่โชว์ในที่ประชุมบอร์ดได้สวยงาม แต่พนักงานหน้างานที่ต้องใช้จริงกลับไม่เห็นความเชื่อมโยงกับงานตัวเอง เพราะไม่เคยถูกถามความเห็นตั้งแต่ขั้นตอนเลือกโจทย์

5. ข้อมูลใน PoC สะอาดเกินจริง

PoC ส่วนใหญ่รันบนชุดข้อมูลที่คัดสรรและทำความสะอาดมาอย่างดี ซึ่งไม่ตรงกับสภาพข้อมูลจริงในระบบงานประจำวัน Gartner ประเมินว่าราว 85% ของงาน AI ที่ล้มเหลวมีต้นตอจากคุณภาพข้อมูลที่ไม่ดีและโครงสร้างข้อมูลที่กระจัดกระจายไม่มีธรรมาภิบาล (blog.aimactgrow.com)

พอเอาไปใช้กับข้อมูลจริงที่ไม่สมบูรณ์ ผลลัพธ์ที่เคยสวยในเดโมก็ทำซ้ำไม่ได้

ปัญหานี้มักไม่ปรากฏจนกว่าจะขยับจาก PoC ไปสู่การใช้งานจริง เพราะระหว่างทำ PoC ทีมงานมักคัดกรองเคสที่ผิดปกติออกด้วยมือ (เช่น ข้อมูลที่กรอกไม่ครบ ชื่อไฟล์ผิดรูปแบบ ข้อมูลซ้ำซ้อนจากหลายระบบ) เพื่อให้เดโมรันได้ราบรื่น แต่ในระบบงานจริง เคสผิดปกติเหล่านี้คือสิ่งที่เกิดขึ้นทุกวัน หากไม่มีการวางแผนจัดการข้อมูลสกปรกไว้ล่วงหน้า ระบบที่เคยแม่นยำ 95% ในเดโม อาจตกลงเหลือ 60-70% เมื่อเจอข้อมูลจริง และความแม่นยำระดับนั้นมักไม่พอให้พนักงานไว้ใจใช้งานต่อเนื่อง

6. วัฒนธรรมองค์กรไม่พร้อมรับการเปลี่ยนแปลง

McKinsey พบซ้ำหลายครั้งว่าวัฒนธรรมองค์กร ไม่ใช่เทคโนโลยี คืออุปสรรคใหญ่ที่สุดของ digital transformation และองค์กรที่ลงทุนกับการเปลี่ยนวัฒนธรรมควบคู่ไปด้วยมีอัตราความสำเร็จสูงกว่าองค์กรที่โฟกัสแค่เทคโนโลยีถึง 5.3 เท่า (aiassemblylines.com)

ถ้าไม่มีใครในองค์กรรู้สึกว่าจำเป็นต้องเปลี่ยนวิธีทำงาน ระบบ AI ที่ดีแค่ไหนก็จะถูกเมินอยู่ดี

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

7 สัญญาณเตือนว่า pilot กำลังจะค้างอยู่ที่ PoC

ก่อนที่ PoC จะเข้าสู่สถานะ "เกือบเสร็จตลอดกาล" มักมีสัญญาณเตือนล่วงหน้าให้เห็นเสมอ ต่อไปนี้คือจุดที่ผู้นำโครงการควรเช็กตัวเองตอนนี้เลย ไม่ต้องรอถึงเดือนที่สาม:

  1. ไม่มีวันที่ชัดเจนสำหรับก้าวถัดไปหลัง PoC จบ — ถ้าถามทีมงานว่า "หลัง PoC เสร็จ ขั้นตอนต่อไปคืออะไร วันไหน" แล้วไม่มีใครตอบได้เป็นวันที่ที่ชัดเจน (ตอบแค่ "เดี๋ยวดูผลก่อน") นี่คือสัญญาณแรกและชัดที่สุด
  2. Sponsor ระดับผู้บริหารเข้าประชุมน้อยลงเรื่อย ๆ — ถ้าผู้บริหารที่เคยอนุมัติงบเริ่มส่งตัวแทนเข้าประชุมแทนตัวเอง หรือขอเลื่อนประชุมติดตามผลซ้ำ ๆ นั่นคือสัญญาณว่าความสนใจกำลังลดลงก่อนที่ใครจะพูดออกมาตรง ๆ
  3. ไม่มี KPI ทางธุรกิจที่ผูกกับตัวเลขจริง มีแต่ตัวชี้วัดทางเทคนิค — ถ้าเกณฑ์ความสำเร็จของ PoC คือ "ความแม่นยำโมเดลถึง 90%" แต่ไม่มีใครตอบได้ว่า 90% นั้นแปลว่าประหยัดเวลาหรือเงินเท่าไหร่ ให้สงสัยไว้ก่อนว่าเมื่อ PoC จบ จะไม่มีใครรู้ว่าควรไปต่อหรือหยุด
  4. ทีมที่ต้องใช้ระบบจริงไม่เคยถูกดึงเข้ามาตั้งแต่ขั้นตอนออกแบบ — ถ้าคนที่จะใช้งานระบบทุกวันเพิ่งได้เห็นระบบครั้งแรกตอนเดโม ไม่ได้มีส่วนร่วมเลือก use case หรือให้ feedback ระหว่างทาง โอกาสสูงที่พวกเขาจะไม่รู้สึกเป็นเจ้าของและเลิกใช้หลังช่วงทดลองผ่านไป
  5. ยังไม่มีใครในทีมภายในแตะ source code หรือ config ของระบบด้วยตัวเอง — ถ้าทุกการปรับแก้ยังต้องผ่านที่ปรึกษาเท่านั้น แม้แต่เรื่องเล็ก ๆ อย่างแก้ข้อความแจ้งเตือน นี่คือสัญญาณว่ายังไม่มีการถ่ายโอนความสามารถเกิดขึ้นจริง
  6. ไม่มีแผนงบประมาณหรือทีมดูแลระบบหลัง PoC จบ — ถ้าถามฝ่ายการเงินหรือฝ่ายบุคคลว่ามีการกันงบหรือกันอัตรากำลังไว้สำหรับดูแลระบบหลัง go-live หรือยัง แล้วคำตอบคือ "ยังไม่ได้คุยกันเรื่องนี้" นั่นหมายความว่าองค์กรยังไม่ได้วางแผนสำหรับความสำเร็จ มีแต่แผนสำหรับการทดลอง
  7. PoC ทดสอบเฉพาะเคสที่ "สวย" ไม่เคยลองกับข้อมูลตกหล่นหรือเคสยาก — ถ้าไม่มีใครถามคำถามว่า "แล้วถ้าข้อมูลกรอกผิด กรอกไม่ครบ หรือมาจากหลายระบบไม่ตรงกันล่ะ ระบบจะรับมือยังไง" ระหว่างช่วง PoC แปลว่ายังไม่มีใครทดสอบกับสภาพจริง และปัญหานี้จะโผล่มาทีเดียวตอนขยายสเกล

ตัวอย่างสถานการณ์จำลอง: pilot ค้าง 4 เดือน แล้วแก้อย่างไรถึงไปต่อได้

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

สมมติว่าบริษัทผลิตสินค้าอุปโภคบริโภคขนาดกลางแห่งหนึ่ง จ้างที่ปรึกษาทำ PoC ระบบ AI ช่วยพยากรณ์ความต้องการสินค้า (demand forecasting) ให้ฝ่ายวางแผนการผลิต โครงการเริ่มดี — ที่ปรึกษาส่งมอบโมเดลที่พยากรณ์แม่นกว่าวิธีเดิมของบริษัทถึง 20% เมื่อทดสอบกับข้อมูลย้อนหลัง 6 เดือน ผู้บริหารพอใจมาก อนุมัติให้เดินหน้าต่อ

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

ทีมข้อมูลภายในไม่เคยเห็น pipeline การเทรนโมเดลเลย เพราะที่ปรึกษาทำงานอยู่บนเซิร์ฟเวอร์ของตัวเองทั้งหมด และเมื่อลองใช้กับข้อมูลสินค้าที่เพิ่งเปิดตัวใหม่ (ซึ่งไม่มีในข้อมูลย้อนหลังที่ใช้เทรน) โมเดลพยากรณ์ผิดเพี้ยนไปมาก ทำให้ทีมงานเริ่มไม่ไว้ใจตัวเลขที่ระบบให้มา

จุดที่ทำให้โครงการเริ่มขยับได้อีกครั้งคือการเปลี่ยนวิธีทำงาน 3 อย่างพร้อมกัน ไม่ใช่การแก้โมเดลให้แม่นขึ้น:

  1. ผู้บริหารกำหนด KPI ทางธุรกิจใหม่ให้ชัดว่าภายในไตรมาสถัดไปต้องลดสต๊อกสินค้าค้างเกินจำเป็นลง 15% โดยผูกกับตัวเลขที่วัดได้จริง ไม่ใช่แค่ "ความแม่นยำโมเดล"
  2. จัดให้พนักงานฝ่ายวางแผน 2 คนเข้าร่วมทำงานกับที่ปรึกษาโดยตรงในการปรับโมเดลให้รองรับสินค้าใหม่ แทนที่จะรอรับมอบระบบสำเร็จรูป ทำให้พวกเขาเข้าใจวิธีปรับแต่งค่าพารามิเตอร์เองได้บางส่วนก่อนที่สัญญาที่ปรึกษาจะจบ
  3. ผู้จัดการฝ่ายผลิตกำหนดวันตัดสินใจชัดเจนว่าจะเลิกใช้สเปรดชีตแบบเดิมภายใน 6 สัปดาห์ พร้อมประกาศให้ทั้งแผนกรู้ล่วงหน้า แทนที่จะปล่อยให้สองระบบวิ่งขนานกันไปเรื่อย ๆ อย่างไม่มีกำหนด

ภายในสองเดือนถัดมา โครงการที่เคยค้างจึงเริ่มเข้าสู่การใช้งานจริงในสเกลเต็มแผนก

ตัวอย่างนี้สะท้อนแพตเทิร์นเดียวกับที่งานวิจัยของ Vantage Point ชี้ไว้ — สิ่งที่ทำให้ pilot ไปต่อไม่ใช่การทำโมเดลให้แม่นขึ้น แต่คือการตัดสินใจระดับองค์กร 3 เรื่อง: กำหนด KPI ธุรกิจที่ชัด ให้ทีมภายในมีส่วนร่วมทำงานจริงไม่ใช่แค่รอรับมอบ และมีผู้บริหารกำหนดเส้นตายเปลี่ยนผ่านที่ชัดเจน

ทำอย่างไรให้ pilot ไปถึง production ได้จริง

จากสาเหตุทั้งหมดข้างต้น ทางแก้ที่ตรงจุดไม่ใช่การทำ PoC ให้ "เนียนกว่าเดิม" แต่คือการวางเงื่อนไขให้ถูกตั้งแต่ก่อนเริ่ม:

  1. กำหนด KPI ทางธุรกิจก่อนเริ่ม PoC ไม่ใช่แค่ตัวชี้วัดทางเทคนิค (ความแม่นยำของโมเดล) แต่เป็นตัวชี้วัดที่ผูกกับงานจริง เช่น ลดเวลาทำงานกี่ชั่วโมงต่อสัปดาห์ ลดข้อผิดพลาดกี่เปอร์เซ็นต์ ลดสต๊อกค้างกี่เปอร์เซ็นต์ — ตัวเลขที่ตอบได้ว่า "คุ้มไหมที่จะไปต่อ" โดยไม่ต้องอาศัยความรู้สึก
  2. ให้ผู้บริหารติดตามงานต่อเนื่องหลังเดโม ไม่ใช่แค่ตอนอนุมัติงบ — ต้องมีคนระดับบริหารเป็นเจ้าของ KPI นั้นจริง ไม่ใช่แค่ผู้สนับสนุนตอนเปิดโครงการ และควรมีตารางติดตามผลที่กำหนดล่วงหน้าเป็นสัปดาห์หรือเดือน ไม่ใช่ "ประชุมทีหลังเมื่อมีเวลา"
  3. ลงทุนกับการฝึกอบรมและถ่ายโอนความสามารถให้ทีมภายในตั้งแต่ต้น ไม่ใช่รอให้ที่ปรึกษาส่งมอบแล้วค่อยคิดเรื่องนี้ทีหลัง — ทีมในองค์กรต้องเข้าใจและดูแลระบบต่อได้เองก่อนที่โครงการจะจบ วิธีที่ได้ผลจริงคือให้ทีมภายในทำงานร่วมกับที่ปรึกษาแบบลงมือทำเองบางส่วนตั้งแต่กลางโครงการ ไม่ใช่แค่นั่งดูรายงานสรุป
  4. เลือก use case จากปัญหาที่ทีมงานเจอจริงทุกวัน ไม่ใช่ use case ที่โชว์ศักยภาพ AI ได้สวยที่สุด วิธีเช็กง่าย ๆ คือถามทีมงานหน้างานเองว่า "ถ้าเลือกได้ อยากให้ AI ช่วยงานไหนที่เสียเวลาที่สุด" แล้วเริ่มจากคำตอบนั้น ไม่ใช่จากสิ่งที่ทีมเทคโนโลยีคิดว่าน่าสนใจ
  5. ทดสอบกับข้อมูลสภาพจริง ไม่ใช่ข้อมูลที่คัดสรรมาอย่างดีเพื่อให้เดโมออกมาสวย — ตั้งใจใส่เคสข้อมูลตกหล่น ข้อมูลผิดรูปแบบ หรือเคสที่ไม่เคยเจอมาก่อนเข้าไปทดสอบตั้งแต่ช่วง PoC เพื่อรู้ล่วงหน้าว่าระบบจะรับมือกับความไม่สมบูรณ์ของโลกจริงได้แค่ไหน
  6. กำหนดเส้นตายเปลี่ยนผ่านที่ชัดเจน ว่าจะเลิกใช้กระบวนการเดิมเมื่อไหร่ ไม่ปล่อยให้ระบบใหม่กับระบบเก่าวิ่งขนานกันไปโดยไม่มีกำหนด เพราะยิ่งวิ่งขนานนานเท่าไหร่ แรงจูงใจให้เปลี่ยนไปใช้ระบบใหม่เต็มรูปแบบก็ยิ่งลดลงเท่านั้น

พูดให้ตรงที่สุด: การที่ pilot ค้างอยู่ที่ PoC ไม่ใช่เพราะ AI "ยังไม่พร้อม" แต่เพราะองค์กรได้คำแนะนำและแผนงาน โดยไม่ได้สร้างความสามารถให้คนในทีมพาระบบไปต่อได้เอง นี่คือจุดที่การอบรมและถ่ายโอนทักษะให้ทีมภายในต้องเป็นส่วนหนึ่งของแผน AI transformation ตั้งแต่วันแรก ไม่ใช่ขั้นตอนที่คิดถึงทีหลังหลังจากที่ปรึกษาจากไปแล้ว — ดูรายละเอียดแนวทางอบรมที่ออกแบบมาเพื่อแก้จุดนี้โดยตรงได้ที่หน้า AI Transformation Training

คำถามที่พบบ่อย

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

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

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

ต้องมีทีม data/AI ภายในก่อนถึงจะเริ่ม AI transformation ได้ไหมไม่จำเป็นต้องมีทีมผู้เชี่ยวชาญเต็มรูปแบบตั้งแต่วันแรก แต่การอบรมและถ่ายโอนทักษะให้ทีมที่มีอยู่ควรเป็นส่วนหนึ่งของแผนตั้งแต่ต้น ไม่ใช่ขั้นตอนที่คิดถึงทีหลัง — นี่คือความต่างสำคัญระหว่างองค์กรที่ pilot ไปต่อได้กับที่ค้างอยู่ที่ PoC

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

หากองค์กรของคุณกำลังเจอสถานการณ์นี้ — มีแผน AI transformation อยู่แล้วแต่ pilot ไม่ไปไหนต่อ — ลองอ่านเพิ่มเติมว่าการอบรมที่ออกแบบมาเพื่อถ่ายโอนความสามารถให้ทีมภายในทำงานอย่างไรที่หน้า AI Transformation Training หรือทักมาคุยเพื่อประเมินสถานการณ์ของทีมคุณตรง ๆ ก่อนตัดสินใจว่าจะแก้จุดไหนก่อน

เขียนโดย Jade (Sarunjade) — ที่ปรึกษาและผู้ออกแบบหลักสูตร AI Transformation Training ให้องค์กรไทย