ช่วงที่ผ่านมา หลายองค์กรเริ่มเปิดพื้นที่ให้พนักงานได้ทดลองใช้ AI มากขึ้น ทั้งในรูปแบบ Training, Workshop ไปจนถึง Hackathon ภายในบริษัท
รูปแบบของกิจกรรมก็พัฒนาไปไกลกว่าการสอนเขียน Prompt มากแล้ว หลาย Workshop ให้แต่ละทีมลองหยิบปัญหาจากงานประจำมาสร้างเป็น Prototype จริง เช่น ระบบช่วยค้นหาข้อมูลจากเอกสาร ระบบสรุปรายงาน เครื่องมือช่วยตรวจข้อมูล หรือ Internal Tool ที่ลดขั้นตอนการทำงานบางอย่างลง
ผลลัพธ์ที่เกิดขึ้นในวัน Workshop มักน่าสนใจ คนที่ไม่เคยเขียนโปรแกรมมาก่อนสามารถสร้าง Tool ง่าย ๆ ขึ้นมาได้ ทีมที่เคยคิดว่าปัญหาบางอย่างต้องรอ Development หลายสัปดาห์เริ่มเห็นว่าบางแนวคิดสามารถทดลองได้ภายในวันเดียว และหลาย Prototype ก็แสดงให้เห็นชัดเจนว่า ถ้านำไปพัฒนาต่อ มันมีโอกาสช่วยลดเวลาหรือขั้นตอนการทำงานได้จริง
แต่หลังจากกิจกรรมจบไปสักระยะ องค์กรจำนวนไม่น้อยกลับพบว่า Workflow ของคนส่วนใหญ่ยังเหมือนเดิม Prototype ที่สร้างขึ้นบางตัวหยุดอยู่ที่ Demo บางตัวถูกส่งต่อกันใช้ในทีมเล็ก ๆ และบางตัวไม่ได้ถูกเปิดใช้อีกเลยหลัง Workshop ตรงนี้เป็นช่วงที่หลายองค์กรเริ่มตั้งคำถามว่า ปัญหาเกิดจากพนักงานยังใช้ AI ไม่คล่อง หรือ Workshop ที่จัดไปยังไม่ตอบโจทย์
ในความเป็นจริง สิ่งที่เกิดขึ้นมักเกี่ยวข้องกับเรื่องที่อยู่หลัง Workshop มากกว่า เพราะการสร้าง Prototype ให้ทำงานได้ กับการนำ Tool หนึ่งตัวเข้าไปอยู่ในระบบการทำงานขององค์กร เป็นงานคนละช่วงกัน และมีเงื่อนไขต่างกันมาก
วันที่ Prototype เริ่มมีประโยชน์จริง เรื่องจะเริ่มซับซ้อนขึ้น
ลองนึกถึงทีมหนึ่งที่ต้องทำงานกับเอกสารจำนวนมากทุกวัน พนักงานต้องเปิดไฟล์ทีละฉบับ อ่านข้อมูลบางจุด แล้วนำข้อมูลเหล่านั้นไปกรอกต่อในระบบอีกแห่ง ขั้นตอนนี้ใช้เวลามากและมีโอกาสเกิด Human Error อยู่เสมอ
ใน Workshop ทีมลองสร้าง Tool ที่ใช้ AI อ่านเอกสารและดึงข้อมูลสำคัญออกมาให้อัตโนมัติ ในเวลาสั้น ๆ Prototype ตัวแรกก็เริ่มทำงานได้ ทีมลองกับเอกสารตัวอย่างแล้วพบว่าผลลัพธ์ค่อนข้างดี และถ้านำไปใช้กับงานจริงได้ ก็อาจลดเวลาในกระบวนการนี้ไปได้มาก ตอน Demo เรื่องดูไม่ซับซ้อนนัก เพราะคนที่สร้างเป็นคนเปิด Tool จากเครื่องของตัวเอง ใส่ข้อมูลตัวอย่าง และแสดงผลให้คนในห้องดู
แต่ทันทีที่ทีมต้องการให้พนักงานคนอื่นเริ่มใช้งาน สิ่งที่ต้องจัดการจะเพิ่มขึ้นทันที ต้องมีที่สำหรับ Deploy Application เพื่อให้คนอื่นเข้าถึงได้ ต้องกำหนดว่าใครสามารถใช้งานได้บ้าง ต้องดูว่าเอกสารที่นำเข้าไปมีข้อมูลประเภทไหน และข้อมูลเหล่านั้นสามารถส่งไปให้ AI Model ประมวลผลได้หรือไม่
หาก Tool ต้องดึงข้อมูลจากระบบภายใน ก็ต้องออกแบบวิธีการเชื่อมต่อ หากมีข้อมูลที่แต่ละคนมองเห็นไม่เหมือนกัน ระบบก็ต้องรู้จักสิทธิ์ของผู้ใช้แต่ละกลุ่มด้วย จาก Tool เล็ก ๆ ที่สร้างขึ้นเพื่อพิสูจน์ไอเดีย เรื่องจึงเริ่มเกี่ยวข้องกับ Infrastructure, Security, Data และระบบขององค์กรอย่างหลีกเลี่ยงไม่ได้
และนี่เป็นจุดที่ Prototype จำนวนมากหยุดอยู่ ไม่ได้หยุดเพราะ Use Case ไม่มีประโยชน์ หรือ AI ทำงานไม่ได้ แต่เพราะสิ่งที่สร้างขึ้นในช่วงทดลองยังไม่ได้ถูกเตรียมมาให้รองรับการใช้งานในระดับองค์กรตั้งแต่แรก
Prototype ที่ทำงานได้ในตอน Demo ยังต้องผ่านอีกหลายเรื่องก่อนเข้า Workflow จริง
ช่วงทดลองและช่วงใช้งานจริงมีเป้าหมายต่างกัน เวลาทำ Prototype ทีมต้องการรู้ก่อนว่าไอเดียนี้เป็นไปได้ไหม AI สามารถจัดการกับข้อมูลแบบนี้ได้หรือไม่ และ User Experience แบบไหนน่าจะเหมาะกับคนใช้งาน
ในช่วงนี้ การทำให้เร็วมีความสำคัญมาก หลายอย่างจึงสามารถลดรูปลงได้ ใช้ข้อมูลตัวอย่างแทนข้อมูลจริง ใช้ Account ของคนสร้าง ใช้ Environment ชั่วคราว หรือยังไม่จำเป็นต้องออกแบบทุก Edge Case ให้ครบ
วิธีนี้เหมาะกับการทดลอง เพราะไม่มีเหตุผลที่จะลงทุนสร้างระบบเต็มรูปแบบให้กับไอเดียที่ยังไม่รู้ว่าจะเวิร์กหรือไม่สถานการณ์จะเปลี่ยนทันทีเมื่อตัดสินใจนำ Tool ไปใช้ในงานจริง ระบบต้องรับข้อมูลจริงจากผู้ใช้หลายรูปแบบ ต้องรองรับกรณีที่ AI ตอบผิดหรือระบบภายนอกที่เชื่อมต่อมีปัญหา ต้องมีการจัดการสิทธิ์ของผู้ใช้ และต้องรู้ว่าเกิดอะไรขึ้นหากระบบหยุดทำงาน
เรื่อง Maintenance ก็เริ่มเข้ามาเกี่ยวข้องเช่นกัน คนที่สร้าง Prototype ใน Workshop อาจไม่ได้เป็นคนดูแล Application นี้ในระยะยาว หากเจ้าของเดิมเปลี่ยนทีม ใครจะรับช่วงต่อ หาก Model หรือ API ที่ใช้อยู่เปลี่ยน จะมีใครรู้ว่าต้องแก้ตรงไหน ระบบที่เริ่มถูกใช้ใน Business Process ต้องมีเจ้าของที่ชัดเจน และต้องถูกดูแลเหมือน Software ตัวหนึ่ง ไม่ว่าจะเริ่มต้นมาจาก Workshop หรือสร้างจากทีม Development โดยตรงก็ตาม
ยิ่ง AI ทำให้สร้าง Tool ได้ง่าย เรื่องมาตรฐานยิ่งสำคัญขึ้น
ก่อนหน้านี้ การสร้าง Internal Application สักตัวมักต้องผ่านทีม Technology ตั้งแต่ต้น Business อธิบาย Requirement ทีม Tech ประเมินงาน วาง Architecture พัฒนา Test แล้วจึง Deploy กระบวนการนี้อาจใช้เวลา แต่ข้อดีอย่างหนึ่งคือ Technology, Infrastructure และวิธีการ Deploy มักอยู่ภายใต้กรอบขององค์กรตั้งแต่แรก
คนจากทีม Business สามารถสร้าง Prototype เองได้มากขึ้น Developer สามารถเขียน Application ได้เร็วขึ้น และทีมเล็ก ๆ สามารถสร้างเครื่องมือเฉพาะทางโดยไม่ต้องรอ Project ขนาดใหญ่ ในองค์กรหนึ่งจึงอาจเริ่มมี Tool เกิดขึ้นพร้อมกันจากหลายทีม
- Marketing อาจมีระบบช่วยวิเคราะห์ Performance ของ Content
- Finance มี Tool อ่านเอกสารและดึงข้อมูลบางประเภท
- HR มีระบบให้พนักงานค้นหาข้อมูล Policy
- Operation มี Workflow สำหรับตรวจเอกสาร
- Sales มี AI Assistant สำหรับค้นหาข้อมูลสินค้า
แต่ละ Use Case สามารถสร้างคุณค่าให้ทีมของตัวเองได้ และความสามารถในการสร้างของคนในองค์กรก็เพิ่มขึ้นอย่างเห็นได้ชัด
สิ่งที่องค์กรต้องระวังคือ เมื่อแต่ละทีมเริ่มสร้างกันเองโดยไม่มี Environment กลาง ความแตกต่างด้าน Technology จะเพิ่มขึ้นตามไปด้วย บางทีมใช้ Platform หนึ่ง ขณะที่อีกทีมใช้คนละ Platform บาง Application ใช้ Account ส่วนตัวในการเรียก AI Service บางตัวมี Source Code อยู่ในพื้นที่ของทีม บาง Tool ใช้ Authentication ของตัวเอง ขณะที่บางตัวแทบไม่มี Access Control เพราะช่วงแรกตั้งใจให้ใช้กันเพียงไม่กี่คน
ช่วงทดลองสิ่งเหล่านี้อาจยังไม่สร้างปัญหาชัดเจนแต่เมื่อมี Application จำนวนมากขึ้น ฝ่าย IT จะเริ่มต้องเข้าไปทำความเข้าใจระบบที่แต่ละทีมสร้างขึ้นทีละตัว ก่อนจะอนุญาตให้นำไปใช้กับข้อมูลจริงหรือเปิดให้คนในองค์กรใช้งาน
องค์กรอาจสร้าง Prototype ได้เร็วขึ้น แต่ Production ยังเดินด้วยความเร็วเดิม
นี่เป็นสถานการณ์ที่เริ่มเห็นได้มากขึ้นเมื่อองค์กรเปิดให้คนทดลอง AI ด้านหนึ่ง จำนวนไอเดียและ Prototype เพิ่มขึ้นอย่างรวดเร็ว อีกด้านหนึ่ง กระบวนการตรวจสอบ Infrastructure, Security และ Integration ขององค์กรยังต้องทำตามมาตรฐานเดิม หาก Prototype แต่ละตัวถูกสร้างขึ้นด้วยวิธีที่ต่างกัน ฝ่าย Technology ก็ต้องใช้เวลาทำความเข้าใจแต่ละระบบใหม่
- Application นี้ใช้ Framework อะไร
- เชื่อมกับ Model ไหน
- เก็บข้อมูลไว้ที่ไหน
- มีข้อมูลอะไรถูกส่งออกไปภายนอกบ้าง
- Authentication ทำอย่างไร
- Log ถูกเก็บหรือไม่
- ใครเป็น Owner
- ระบบรองรับผู้ใช้ได้กี่คน
สิ่งเหล่านี้เป็นงานที่จำเป็น เพราะเมื่อ Application เริ่มเชื่อมกับข้อมูลบริษัท ความเสี่ยงไม่ได้อยู่เฉพาะในตัว AI Model เท่านั้น แต่รวมถึงวิธีที่ Application ถูกสร้างและนำไปใช้งานด้วย
ปัญหาจึงไม่ใช่ว่าองค์กรทดลอง AI มากเกินไป ประเด็นอยู่ที่โครงสร้างรองรับการทดลองเหล่านั้นอาจยังไม่ได้ถูกออกแบบมาให้รองรับจำนวน Tool ที่เพิ่มขึ้น ยิ่ง AI ทำให้คนสร้างได้เร็ว ความแตกต่างระหว่างความเร็วในการสร้างกับความเร็วในการนำขึ้นใช้จริงก็ยิ่งเห็นชัด
AI Adoption ในองค์กรจึงดูจากจำนวนคนเข้า Workshop อย่างเดียวไม่ได้
จำนวนพนักงานที่ผ่าน AI Training เป็นข้อมูลที่มีประโยชน์ อย่างน้อยมันช่วยบอกว่าองค์กรเริ่มสร้างความเข้าใจและเปิดโอกาสให้คนได้ทดลอง Technology ใหม่แล้ว จำนวน Prototype ก็มีความหมายเช่นกัน เพราะสะท้อนว่าคนเริ่มมองเห็น Use Case จากงานของตัวเอง แต่เมื่อเวลาผ่านไป องค์กรควรเริ่มมองต่อว่า สิ่งที่เกิดขึ้นจากกิจกรรมเหล่านั้นถูกนำไปต่อยอดมากน้อยแค่ไหน
- มี Tool ตัวไหนถูกนำกลับไปใช้ในทีม
- มี Process ไหนที่เปลี่ยนไปแล้วจริง ๆ
- มี Application ไหนถูกพัฒนาต่อหลังจบ Workshop
- พนักงานใช้งานได้โดยไม่ต้องพึ่งคนที่สร้างอยู่ตลอดหรือไม่
- ระบบเหล่านั้นผ่านมาตรฐานที่องค์กรต้องการแล้วหรือยัง
ถ้า Prototype จำนวนมากเกิดขึ้นทุก Quarter แต่ไม่มีตัวไหนเข้าไปอยู่ใน Workflow จริง องค์กรอาจกำลังสร้างกิจกรรมเกี่ยวกับ AI ได้ดี แต่ผลในระดับ Operation ยังเกิดขึ้นไม่มากนัก
AI Adoption จะเริ่มมีน้ำหนักมากขึ้นเมื่อพนักงานสามารถนำ AI ไปใช้กับงานที่ต้องทำจริงในชีวิตประจำวัน และองค์กรสามารถรักษาระบบเหล่านั้นให้ใช้งานต่อได้
Workshop ยังมีบทบาทสำคัญ โดยเฉพาะในการหา Use Case จากคนที่ทำงานกับปัญหาจริง
การมองเห็นข้อจำกัดหลัง Workshop ไม่ได้ทำให้ Workshop มีความสำคัญน้อยลง ในหลายองค์กร คนที่รู้ว่ากระบวนการไหนควรถูกปรับปรุงที่สุด อาจไม่ได้อยู่ในทีม Technology
- คนใน Finance รู้ว่าตรงไหนของการตรวจเอกสารที่เสียเวลามากที่สุด
- ทีม Operation รู้ว่าข้อมูลอะไรต้องถูก Copy จากระบบหนึ่งไปอีกระบบหนึ่งทุกวัน
- ทีม HR รู้ว่าคำถามประเภทไหนที่พนักงานถามเข้ามาซ้ำตลอดทั้งปี
- คนที่อยู่กับงานจริงมี Context ที่สำคัญต่อการหา AI Use Case มาก
Workshop จึงเป็นโอกาสที่ดีในการทำให้คนกลุ่มนี้ได้ทดลองสร้าง Solution จากสิ่งที่ตัวเองเจออยู่ทุกวัน โดยไม่ต้องรอให้ทุกไอเดียเข้าสู่กระบวนการ Development เต็มรูปแบบตั้งแต่แรก บางไอเดียอาจทดลองแล้วพบว่า AI ยังไม่เหมาะ บางไอเดียอาจช่วยได้เพียงเล็กน้อย และบางไอเดียอาจกลายเป็น Tool ที่ช่วยคนทั้งทีมได้จริง
การทดลองเร็วช่วยให้องค์กรแยกสิ่งเหล่านี้ออกจากกันได้โดยใช้ต้นทุนไม่สูงเกินไป สิ่งที่ควรเตรียมต่อจากนั้นคือ เมื่อเจอ Use Case ที่ควรไปต่อแล้ว ทีมจะพัฒนาอย่างไรโดยไม่ต้องเริ่มสร้างทุกอย่างใหม่
สิ่งที่เกิดหลัง Workshop ควรถูกคิดไว้ตั้งแต่ก่อน Workshop เริ่ม
ถ้าองค์กรต้องการให้ Prototype มีโอกาสไปถึง Production กระบวนการหลัง Workshop ไม่ควรเริ่มจากการถามว่า “ทีนี้จะทำอย่างไรกับ Tool ตัวนี้” ควรมีภาพคร่าว ๆ ไว้ตั้งแต่ต้นว่า หากมี Use Case ที่ดีเกิดขึ้น จะถูกส่งต่อไปที่ไหน บาง Prototype อาจเหมาะกับการใช้เป็น Productivity Tool ส่วนบุคคล ไม่จำเป็นต้องทำเป็น Application กลาง บางตัวอาจมีประโยชน์กับคนเพียงทีมเดียว และสามารถพัฒนาเป็น Internal Tool ขนาดเล็ก บางตัวอาจเกี่ยวข้องกับ Process หลักขององค์กรและต้องผ่าน Security, Architecture หรือ Data Review อย่างละเอียด
นอกจากนี้ ทีมที่เข้าร่วม Workshop ก็ควรรู้ด้วยว่า ถ้าต้องการพัฒนาต่อ มี Environment หรือเครื่องมืออะไรที่องค์กรเตรียมไว้ให้ แทนที่จะสร้าง Application ใหม่จากศูนย์ทุกครั้ง องค์กรสามารถเตรียมองค์ประกอบพื้นฐานบางอย่างไว้ล่วงหน้า เช่น วิธี Authentication, Deployment Pattern, การเชื่อมต่อกับ AI Model, Logging หรือการจัดการ Permission
สิ่งเหล่านี้ไม่ได้ทำให้การทดลองช้าลง หากออกแบบดี ๆ กลับช่วยให้ทีมเริ่มต้นได้เร็วกว่าเดิม เพราะหลายเรื่องที่เคยต้องตั้งค่าใหม่ทุก Project ถูกเตรียมไว้แล้ว
ฝ่าย IT เองก็ต้องเปลี่ยนจากการเข้ามาจัดระเบียบทีหลัง
ในองค์กรที่เปิดให้ Business สร้าง AI Tool ได้มากขึ้น บทบาทของ Technology Team จะเปลี่ยนตามไปด้วย ถ้าทุก Prototype ต้องถูกโยนกลับมาให้ IT จัดการทั้งหมดก่อน Production ความสามารถในการสร้างของคนในองค์กรอาจเพิ่มขึ้น แต่ Capacity ของทีม IT ไม่ได้เพิ่มตามไปด้วย
ผลที่เกิดขึ้นคือ Queue ยาวขึ้น Prototype ที่น่าสนใจต้องรอ Review Business เริ่มรู้สึกว่าทำของได้เร็วแต่เอาขึ้นใช้จริงช้า ส่วน IT ก็ต้องรับงานจากระบบที่ตัวเองไม่ได้มีส่วนในการออกแบบตั้งแต่ต้น
วิธีที่จัดการได้ในระยะยาวกว่าคือ Technology Team ช่วยกำหนดขอบเขตและเครื่องมือที่ทีมอื่นสามารถใช้ได้ตั้งแต่ช่วงพัฒนา บางเรื่องสามารถทำให้เป็น Standard บางเรื่องสามารถทำเป็น Shared Service บางข้อกำหนดสามารถฝังอยู่ใน Platform โดยไม่ต้องให้ Developer ของแต่ละ Project ทำเอง
เมื่อกรอบเหล่านี้ชัด ทีม Business ยังสามารถทดลองได้ ส่วน IT ก็มี Visibility มากขึ้นว่าสิ่งที่ถูกสร้างขึ้นอยู่บน Technology แบบไหนและเชื่อมกับข้อมูลอะไร งาน Review จึงไม่จำเป็นต้องเริ่มจากศูนย์ทุกครั้ง
Production Readiness ควรถูกมองเป็นส่วนหนึ่งของ AI Adoption
เวลาพูดถึง AI Adoption หลายองค์กรให้ความสำคัญกับคนและเครื่องมือเป็นหลัก
- พนักงานใช้ AI เป็นหรือยัง
- องค์กรมี License ของ Platform ไหน
- มี Use Case อะไรที่เริ่มทดลองแล้วบ้าง
- อีกส่วนหนึ่งที่ควรอยู่ในภาพเดียวกันคือ Production Readiness
เพราะเมื่อมี Use Case ที่พิสูจน์แล้วว่ามีคุณค่า การที่มันจะไปถึงผู้ใช้ได้เร็วแค่ไหนขึ้นอยู่กับความพร้อมของระบบองค์กรด้วย
- Infrastructure รองรับ Application รูปแบบนี้หรือไม่
- มี Environment สำหรับพัฒนาต่อหรือยัง
- Security Review มีขั้นตอนชัดเจนหรือไม่
- มีมาตรฐานสำหรับการใช้ AI Model และ Data หรือไม่
- ทีมรู้หรือไม่ว่า Application ต้องผ่านอะไรบ้างก่อนเปิดใช้งาน
หากทุกครั้งที่มี Prototype ใหม่เกิดขึ้น องค์กรต้องกลับมาออกแบบสิ่งเหล่านี้ใหม่ทั้งหมด การ Scale AI Use Case จะยากขึ้นเรื่อย ๆ ตามจำนวน Project ตรงกันข้าม หากส่วนพื้นฐานถูกเตรียมไว้แล้ว ทีมจะสามารถใช้เวลาไปกับ Business Logic และ Use Case มากขึ้น สิ่งที่ควรถูกทำซ้ำในทุก Project ก็ยังทำซ้ำได้ ส่วนสิ่งที่สามารถใช้ร่วมกันได้ไม่จำเป็นต้องถูกสร้างใหม่
AEGIS ถูกออกแบบมาสำหรับช่วงต่อระหว่าง Prototype กับการใช้งานจริง
AEGIS เริ่มจากโจทย์ที่ Muze เห็นว่าองค์กรเริ่มสร้าง AI Prototype ได้เร็วขึ้นมาก แต่ช่วงหลังจาก Prototype ยังมีงานด้าน Technology อีกหลายส่วนที่ต้องจัดการก่อนนำไปใช้จริง ตั้งแต่ Environment สำหรับพัฒนา เครื่องมือและมาตรฐานที่ทีมสามารถใช้ร่วมกัน กระบวนการ Review ไปจนถึง Infrastructure สำหรับ Deploy Application
แนวคิดของ AEGIS คือช่วยให้องค์กรมีพื้นที่กลางสำหรับพัฒนา AI Application โดยที่เรื่องพื้นฐานของ Enterprise ไม่ต้องถูกคิดใหม่ทุกครั้ง ทีมยังสามารถทดลองและสร้าง Prototype ได้เร็วเหมือนเดิม แต่เมื่อเจอ Use Case ที่ต้องการพัฒนาต่อ จะมีเส้นทางที่ชัดขึ้นสำหรับการนำไป Production
ในฝั่ง Technology องค์กรสามารถกำหนดมาตรฐานเรื่อง Infrastructure, Security, Data และ Access ไว้ในกระบวนการเดียวกัน
ในฝั่ง Business ทีมที่สร้าง Solution ไม่จำเป็นต้องเรียนรู้รายละเอียดของ Infrastructure ทุกอย่างด้วยตัวเองก่อนที่จะพัฒนา Application ต่อได้
เป้าหมายของโครงสร้างแบบนี้คือทำให้การทดลองกับการใช้งานจริงไม่แยกออกจากกันจนเกินไป เพราะยิ่งระยะห่างระหว่างสองช่วงนี้มากเท่าไร โอกาสที่ Prototype จะหยุดอยู่ระหว่างทางก็มากขึ้นเท่านั้น
จาก Workshop ไปสู่ Workflow
Workshop เป็นจุดเริ่มต้นที่ดีสำหรับองค์กรที่ต้องการให้พนักงานเห็นว่า AI สามารถเข้ามาช่วยงานของตัวเองตรงไหนได้บ้าง หลาย Use Case ที่มีคุณค่าจริงอาจไม่ได้เริ่มจาก Strategy ระดับองค์กร แต่อาจเริ่มจากพนักงานคนหนึ่งที่รู้สึกว่างานบางขั้นตอนซ้ำเกินไป และลองสร้าง Tool เล็ก ๆ ขึ้นมาแก้ปัญหานั้น
สิ่งสำคัญคือ เมื่อ Tool นั้นพิสูจน์แล้วว่ามีประโยชน์ องค์กรมีวิธีพามันเดินต่อหรือไม่ ถ้ามี Environment ที่เหมาะสม มีมาตรฐานที่ทีมเข้าใจตรงกัน และมี Infrastructure รองรับ การทดลองจาก Workshop ก็มีโอกาสพัฒนาเป็น Application ที่ถูกใช้ในงานประจำได้
เมื่อถึงจุดนั้น ผลลัพธ์ของ AI Adoption จะไม่ได้อยู่ที่จำนวน Prototype ที่สร้างขึ้นในวัน Workshop มันจะอยู่ใน Workflow ของคนในองค์กร อยู่ในขั้นตอนที่เคยต้องทำด้วยมือแต่วันนี้ทำได้เร็วขึ้น อยู่ในข้อมูลที่เคยต้องค้นจากหลายระบบแต่วันนี้เข้าถึงได้ง่ายขึ้น และอยู่ใน Internal Tool ที่เริ่มจากไอเดียเล็ก ๆ ของทีมหนึ่ง ก่อนจะกลายเป็นสิ่งที่ช่วยให้คนทำงานได้ดีขึ้นจริง
พัฒนา AI Prototype ให้พร้อมสำหรับการใช้งานจริงด้วย AEGIS
AEGIS ช่วยวาง Environment, Process และ Infrastructure สำหรับการพัฒนา AI Application ตั้งแต่ช่วง Prototype ไปจนถึง Production ภายใต้มาตรฐานที่เหมาะกับการใช้งานในองค์กร
