From Pilot to Enterprise-Wide: Scaling AI Across the Organization
ในยุคที่ทุกองค์กรต่างเร่งเครื่องทำ AI Transformation สิ่งที่น่าตกใจคือผลวิจัยล่าสุดที่ชี้ว่า 46% ของโครงการ AI Pilots มักจะถูกพับ และยกเลิกก่อนที่จะถูกนำไปทดลองใช้งานจริง
ทำไมองค์กรระดับโลกมากมายจึงติดอยู่ในสถานะ "Pilot Purgatory" ซึ่งหมายถึงการที่โครงการเหล่านั้นติดอยู่ในสุญญากาศของขั้นตอนการทดลองที่ไม่จบสิ้น จนกระทั่งถูกล้มเลิกไปในที่สุด แต่คำถามที่สำคัญกว่านั้น คือองค์กรเหล่านี้จะต้องทำอย่างไร จึงจะพัฒนาจากโครงการทดลองเล็กๆ ให้กลายเป็น "AI Factory" ที่ขับเคลื่อนทั้งองค์กรได้จริง
ในบทความนี้ เราสรุป Key Insights จาก Session "From Pilot to Enterprise-Wide: Scaling AI Across the Organization" ในงาน AI-VOLUTION ที่เจาะลึกมุมมองของ Kees Lemmens, CTO (ASEAN) จาก Microsoft โดยมี คุณกสิมา (ออม) ธารพิพิธชัย, Head of AI Strategy จาก SCB 10X เป็นผู้ดำเนินรายการ
6 หลุมพรางที่ทำให้องค์กรติดอยู่ใน “Pilot Purgatory”
เมื่อพูดถึงตัวเลขความล้มเหลว 46% คุณ Kees Lemmens ให้ความเห็นที่น่าสนใจว่า "I think the number is actually on the low end" (ตัวเลขจริงอาจสูงกว่านี้ด้วยซ้ำ) สิ่งที่น่าตกใจไม่ใช่แค่จำนวนความล้มเหลว แต่คือแพทเทิร์นของปัญหาที่เหมือนกันอย่างน่าประหลาด (Remarkably consistent) ไม่ว่าจะเป็นองค์กรไหน เมื่อติดหล่ม Pilot Purgatory มักจะหนีไม่พ้น 6 สาเหตุนี้:
- ขาดโจทย์ธุรกิจ: เริ่มต้นด้วยการอยากลองเทคโนโลยี แต่ไม่มีสมมติฐานทางธุรกิจ (Business Hypothesis) รองรับ ไม่มีการวิเคราะห์ผลกระทบที่แท้จริง ทำให้สุดท้ายขาดงบประมาณและแรงสนับสนุนจากผู้บริหาร
- Bad Data (ข้อมูลไม่พร้อม): การใช้ข้อมูล Sandbox หรือ Batch file มาทำ Pilot นั้นง่าย แต่เมื่อต้องขึ้นระบบจริงที่ต้องการข้อมูล Real-time หรือข้อมูลที่มีความปลอดภัยสูง กลับทำไม่ได้เพราะโครงสร้างข้อมูลจริงไม่รองรับ
- Operation Ops (ขาดระบบหลังบ้าน): โปรเจกต์ส่วนใหญ่เป็นเพียง "Scripts" ที่ปะติดปะต่อกัน ขาดระบบตรวจสอบ (Observability), การกู้คืน (Rollbacks) หรือการรองรับ Traffic มหาศาล เมื่อส่งต่อให้ทีม Engineering หรือ Operations ดูแลต่อ จึงกลายเป็นภาระที่ไม่มีใครอยากรับ
- Compliance Crisis (ติดปัญหากฎระเบียบ): โดยเฉพาะในธุรกิจธนาคาร Pilot ส่วนใหญ่มักขาด Audit Trails, ขาดระบบป้องกันข้อมูลส่วนบุคคล (PII) หรืออธิบายที่มาที่ไปของคำตอบไม่ได้ (Explainability) ทำให้ถูกปัดตกโดยฝ่ายดูแล Compliance ขององค์กร
- Isolated Projects (ต่างคนต่างทำ): การทำ Pilot แบบแยกส่วน (Silo) ทำให้ไม่มีการนำกลับมาใช้ใหม่ (Reusability) ยิ่งขยายสเกล ยิ่งซับซ้อนและแพง จนต้องล้มเลิกไปเพราะแนวคิดพื้นฐานของโปรเจกต์ไม่รองรับการสร้าง "AI Factory" อย่างแท้จริง
- Trust & Adoption (คนไม่กล้าใช้): ผู้ใช้งานไม่ได้รับการฝึกฝน และที่สำคัญคือ "ไม่เชื่อใจระบบ" หากผู้ใช้รู้สึกว่า AI เป็นกล่องดำที่ตรวจสอบไม่ได้ พวกเขาก็จะไม่ใช้งานมัน
Case Study: "คน" คือปัญหา 70% ของการ Scale ระบบ
Kees ย้ำประเด็นสำคัญจากรายงานของ BCG ว่า 70% ของปัญหามาจากเรื่อง "People & Process" ไม่ใช่เทคโนโลยี เขายกตัวอย่างเคสจริงของ ธนาคารแห่งหนึ่งในยุโรป ที่พยายามใช้ AI เข้ามาช่วยงานเอกสารจำนวนมหาศาล (Document-intensive work) เช่น การสรุปกฎหมายและการตรวจสอบ Compliance ซึ่งผลลัพธ์ที่ได้กลายเป็นบทเรียนราคาแพง:
- The Start: ในช่วงแรก Pilot ทำงานได้ดีเยี่ยม สรุปเอกสารร้อยหน้าได้ในวินาที
- The Fail: แต่เมื่อให้พนักงานใช้จริง การใช้งานกลับเป็นศูนย์ เพราะพนักงาน "ไม่ไว้ใจ" ผลลัพธ์ ต้องมานั่งตรวจสอบเองใหม่ทั้งหมด อีกทั้งกลัวว่าจะถูก AI แย่งงาน
- The Pivot: ธนาคารเปลี่ยนกลยุทธ์จากแค่ทำ POC มาเป็นการสร้าง AI Factory
- ใช้ Azure AI Foundry เป็นแกนกลางในการจัดการ Governance และความปลอดภัย
- เปลี่ยน Mindset จาก "AI มาแทนคน" เป็น "AI คือเพื่อนร่วมงาน" ที่มีระบบ Human-in-the-loop
- สร้างระบบที่ตรวจสอบที่มาของข้อมูลได้ และให้พนักงานมีส่วนร่วมใน Feedback loop
ผลลัพธ์: เมื่อพนักงานเห็นว่า AI โปร่งใสและตรวจสอบได้ พวกเขาจึงเปลี่ยนจากผู้ต่อต้านกลายเป็น "AI Champions" ที่ช่วยเทรนเพื่อนร่วมงาน จนเกิดการใช้งานอย่างแพร่หลาย
"สาเหตุที่ AI ส่วนใหญ่ไปไม่รอด ไม่ใช่เพราะโมเดลไม่เก่ง แต่เพราะองค์กรยังไม่พร้อมรับมือกับการใช้งานจริงต่างหาก" (Kees Lemmens, CTO, ASEAN)
Integration Shock: วิธีเชื่อมต่อ AI เข้ากับระบบ Legacy อย่างไรให้รอด?
อีกหนึ่งด่านหินที่ Kees ระบุว่าเป็น "เรื่องที่ทุกคนประมาทมากที่สุด" คือการนำ AI Pilot ที่เคยรันบน Cloud สวยหรู ไปเชื่อมต่อกับระบบ Core Banking หรือ ERP ของจริง ปรากฏการณ์นี้เรียกว่า Integration Shock เพราะระบบเก่าเหล่านี้ไม่ได้ถูกออกแบบมาให้รองรับ "Hot path data flows" หรือการดึงข้อมูลแบบ Real-time ของ AI ทำให้ระบบล่มหรือข้อมูลผิดพลาด เพื่อแก้ปัญหานี้ Kees แนะนำ 3 ขั้นตอน:
- Stabilize Data Foundation: ต้องระบุให้ชัดเจนว่าข้อมูลชุดไหนคือ "Gold Data" ที่ AI เชื่อถือได้ โดยใช้เครื่องมืออย่าง Microsoft Fabric มาช่วยจัดการ Lineage และความเป็นเจ้าของข้อมูล
- Standardize Connection: เลิกเขียน Script เชื่อมต่อแบบจุดต่อจุด (Point-to-point) แต่ให้สร้างเป็น Service Layer ตรงกลางที่นำกลับมาใช้ใหม่ได้
- Scale with Orchestration: ใช้ AI Foundry เข้ามาช่วยจัดการ (Orchestrate) โมเดลและการเชื่อมต่อทั้งหมด เพื่อให้เห็นภาพรวมของระบบ (Observability) และควบคุมได้จากจุดเดียว
The Future Model: จาก Centralized สู่ "AI Factory Mesh"
ในอดีต องค์กรมักเริ่มต้นด้วยทีม Central AI ทีมเดียวที่ทำทุกอย่าง แต่ Kees มองว่าโมเดลนี้ไปต่อไม่ได้ในระยะยาว โดยกล่าวว่า “ผมจินตนาการไม่ออกเลยว่าธนาคารขนาดใหญ่จะขยาย Use case เป็นร้อยๆ ตัวด้วยทีมกลางทีมเดียวได้อย่างไร”
เขาจึงเสนอโมเดลที่เรียกว่า "AI Factory Mesh" ซึ่งเป็นการกระจายอำนาจแบบมีแบบแผน แยกเป็นสองส่วน คือ:
- Hub (ส่วนกลาง): ทำหน้าที่กำหนดมาตรฐาน, Governance, Security และ Policy (AI Guardrails)
- Spoke (หน่วยงานธุรกิจ): เช่น ฝ่ายสินเชื่อ, ฝ่ายบุคคล หรือฝ่ายความเสี่ยง จะมีทีม AI ของตัวเองที่สามารถพัฒนา Copilot หรือ Agent เฉพาะทางได้เอง ภายใต้มาตรฐานที่ส่วนกลางกำหนด
โมเดลนี้จะช่วยให้เกิดนวัตกรรมที่รวดเร็ว แต่ยังคงไว้ซึ่งความปลอดภัยและการควบคุม ซึ่งเป็นหัวใจสำคัญของการทำ AI Transformation ให้ยั่งยืน
ก้าวต่อไปของ Microsoft และเครื่องมือใหม่ที่ต้องจับตา
เพื่อให้องค์กรก้าวข้ามจาก Pilot สู่ Production ได้อย่างมั่นคง Kees ได้เปิดเผยถึงทิศทางเทคโนโลยีของ Microsoft ที่กำลังเปลี่ยนโฟกัสจากแค่ "Model" ไปสู่ "System Trust" โดยเฉพาะการเปิดตัว Microsoft Agent Framework ที่จะเข้ามาแก้ปัญหาคลาสสิกขององค์กร:
- Microsoft Agent Framework: Microsoft ได้รวมสองเฟรมเวิร์กสำคัญอย่าง Semantic Kernel (สำหรับ Developer) และ AutoGen หรือ O2Gen (สำหรับ Experimental Multi-agent) เข้าด้วยกันเป็นหนึ่งเดียว ภายใต้ Azure AI Foundry เพื่อแก้ปัญหาคลาสสิกขององค์กรต่างๆ :
- Make the Invisible Visible: ใช้ OpenTelemetry เพื่อให้เห็นการทำงานของระบบแบบ End-to-end ทั้ง Latency, Lineage และ Content Safety
- Resiliency: เพิ่มความทนทานให้ระบบด้วย State management, Retries และ Rollbacks ป้องกันระบบล่มเมื่อ API หรือ Data Schema เปลี่ยนแปลง
- Governance by Default: ฝัง Policy-as-code, RBAC และ Content moderation ลงไปในระดับเฟรมเวิร์ก เพื่อให้มั่นใจว่าทุก Agent ที่สร้างขึ้นมาจะปลอดภัยและตรวจสอบได้
- Looking Ahead: สิ่งที่ต้องจับตาในงาน Ignite และอนาคต Kees ทิ้งท้ายถึงฟีเจอร์ใหม่ๆ ที่จะเข้ามาช่วยเร่งสปีดองค์กร:
- Agentic Patterns & Models-as-a-Service: รูปแบบการใช้งาน Agent ที่ซับซ้อนขึ้นและการเข้าถึงโมเดลแบบ Service ที่ยืดหยุ่น
- Fabric & Foundry Integration: การเชื่อมต่อที่ลึกซึ้งยิ่งขึ้นระหว่าง Data Platform และ AI Platform
- Purview Upgrades: การยกระดับเครื่องมือ Data Governance เพื่อรองรับ AI Workflow
- AI Factory White Paper: เตรียมพบกับคู่มือฉบับสมบูรณ์ (Playbook) ในการสร้าง AI Factory ที่ Kees และทีมงานกำลังพัฒนาขึ้นเพื่อเป็นแนวทางให้กับองค์กร
การพาองค์กรออกจาก Pilot Purgatory ไม่ใช่การเร่งสร้างโมเดลให้เยอะที่สุด แต่คือการสร้าง "ความชัดเจน" ในเป้าหมายทางธุรกิจ สร้าง "ความเชื่อมั่น" ผ่านระบบ Governance ที่โปร่งใส และสร้าง "คอมมูนิตี้" ของคนในองค์กรที่พร้อมจะเปลี่ยนผ่านไปด้วยกัน เหมือนที่ Kees ทิ้งท้ายไว้ว่า "ความเชื่อมั่นนั้นไม่ใช่แค่ความโปร่งใสเท่านั้น... แต่คือการช่วยให้ Users รู้สึกสบายใจกับผลลัพธ์สุดท้ายต่างหาก"
รับชมทั้งหมดได้ที่ https://www.youtube.com/watch?v=sDiYniIKLV4
RELATED BLOG
