กลยุทธ์ AI Adoption ของบริษัทส่วนใหญ่นั้นมักจะเดินย้อนศร โดยเริ่มจากการที่ผู้บริหารจัดสรรงบประมาณ จากนั้นทีมพัฒนาก็พยายามควานหาแอปพลิเคชันที่จะนำมาใช้ ซึ่งแรงผลักดันหลักมักมาจากความกลัวว่าคู่แข่งจะแซงหน้าไปก่อน แนวทางแบบ "มีโซลูชันแล้วค่อยไปหาปัญหา" คือเหตุผลสำคัญที่ทำให้โปรเจกต์การใช้ AI จำนวนมากล้มเหลวและไม่สามารถสร้างมูลค่าได้จริง
อย่างไรก็ตาม ยังมีเส้นทางที่ใช้งานได้จริงมากกว่า ซึ่งใช้การลงทุนล่วงหน้าน้อยกว่า แต่ช่วยสร้างศักยภาพที่แท้จริงภายในองค์กรของคุณได้ แต่ก่อนอื่น เรามาทำความเข้าใจกับข้อผิดพลาดในการทำ AI Adoption ที่มักจะทำให้โปรเจกต์ล่มกลางคันกันก่อน
รูปแบบที่ผมเห็นซ้ำแล้วซ้ำเล่าคือ บริษัทหนึ่งตัดสินใจว่า "เราต้องใช้ AI" จากนั้นก็ตั้งงบประมาณ แล้วค่อยไปตามหาปัญหาที่จะเอา AI ไปเสียบไว้ แรงจูงใจนี้มาจากความรู้สึกที่ว่าตลาดกำลังแซงนำไปแล้ว และพวกเขาต้องตามให้ทัน
นี่คือการเรียงลำดับที่ผิดพลาด เพราะเมื่อคุณเริ่มด้วยโจทย์ว่า "เราต้องการ AI" แล้วค่อยไปหาที่ลง คุณจะไม่มีบรรทัดฐานในการวัดผลเลย คุณจะไม่สามารถบอกได้ว่าระบบที่สร้างขึ้นนั้นคุ้มค่าหรือแค่เผาผลาญทรัพยากรไปวันๆ และสุดท้ายคุณอาจจบลงด้วยการใช้ AI แก้ปัญหาที่ไม่จำเป็นต้องใช้ AI เลยก็ได้
ปัจจุบันมีความกังวลอย่างมากในตลาด หลายบริษัทรู้สึกกดดันให้ต้องลงทุนในกลยุทธ์ AI Adoption เพราะคนอื่นเขาก็ทำกัน พวกเขาจึงทุ่มงบหลายล้านบาทให้กับแผนงานในปีถัดไปด้วยความกลัวว่าจะตกเทรนด์ มากกว่าจะดูจากหลักฐานของมูลค่าที่จะได้รับจริง
สิ่งนี้นำไปสู่ความล้มเหลวอีกประการ คือการสร้างระบบ AI ที่จบลงแค่ขั้น Proof of Concept (POC) ทีมงานสร้างอะไรบางอย่างที่ดูน่าประทับใจในระบบจำลอง นำเสนอให้ผู้มีส่วนเกี่ยวข้องดู แล้วก็ไม่มีอะไรเกิดขึ้นต่อ โดยปกติแล้วนั่นหมายความว่าความแตกต่างระหว่าง POC กับการใช้งานจริงนั้นมากเกินไป โปรเจกต์นำร่องกลายเป็นเพียงผลงานส่งมอบชิ้นเดียว และองค์กรก็แทบไม่ได้เรียนรู้อะไรเลยว่าทำไมโปรเจกต์ AI ถึงล้มเหลว หรือ AI ของพวกเขาจะทำงานได้จริงในสเกลที่ใหญ่ขึ้นหรือไม่
มีความเสี่ยงเฉพาะตัวอย่างหนึ่งที่ไม่ค่อยได้รับความสนใจนัก คือแม้เครื่องมือ AI จะช่วยให้ Developer เขียนโค้ดได้เร็วขึ้น แต่ก็ยังต้องมีใครสักคนคอยตัดสินว่าโค้ดนั้นดีจริงหรือไม่
จากการที่ผมได้ไปบรรยายตามงานประชุมสัมมนาและพบปะ Developer ทั่วทั้งวงการ ผมสังเกตเห็นรูปแบบที่ชัดเจน คือ Developer ระดับ Junior และ Mid-level จะรับเครื่องมือ AI มาใช้เร็วมากและเริ่มสร้างโค้ดทันที แต่คุณภาพนั้นไม่สม่ำเสมอ และพวกเขามักจะดูไม่ออกว่ามีจุดผิดพลาดตรงไหน ในขณะที่ Senior Developer มักจะเริ่มใช้ช้ากว่า แต่ผลลัพธ์ที่ได้กลับดีกว่าอย่างเห็นได้ชัด ความแตกต่างอยู่ที่ Mental Model หรือประสบการณ์สะสมที่ทำให้มองเห็นปัญหาเชิงโครงสร้าง, กรณีที่อาจเกิดข้อผิดพลาด, และรูปแบบที่จะส่งผลเสียต่อระบบในระยะยาว
องค์กรที่นำเครื่องมือ AI มาใช้โดยไม่มี Engineer ประสบการณ์สูงคอยกำกับดูแล อาจจะได้โค้ดในปริมาณที่มากขึ้นและเร็วขึ้น แต่จะแฝงไปด้วยปัญหาด้านคุณภาพที่จะปะทุขึ้นในภายหลัง
หากคุณกำลังคิดจะปรับปรุงกลยุทธ์ AI Adoption หลักการเหล่านี้จะช่วยให้คุณหลีกเลี่ยงอุปสรรคที่กล่าวไว้ข้างต้น และสร้างระบบที่สามารถใช้งานจริงได้
อย่ามองหาปัญหาเพื่อจะเอา AI ไปใช้ แต่จงมองดูปัญหาที่คุณกำลังแก้ไขอยู่ในปัจจุบัน แล้วถามว่า การใช้ AI สามารถเข้าไปช่วยปรับปรุงวิธีเดิมให้ดีขึ้นได้ไหม
ความแตกต่างนี้สำคัญมากเพราะมันทำให้คุณมีบรรทัดฐานที่ถูกต้อง เมื่อคุณประยุกต์ใช้ AI กับเวิร์กโฟลว์ปัจจุบันที่มีคำตอบอยู่แล้ว คุณจะวัดผลได้ทันทีว่า AI ช่วยให้งานเร็วขึ้น ถูกลง หรือดีขึ้นจริงหรือไม่ คุณสามารถคำนวณผลตอบแทนจากการลงทุนได้จากตัวเลขจริง ไม่ใช่แค่การคาดการณ์
เทคโนโลยีไม่ได้แก้ปัญหาด้วยตัวมันเอง การละเลยข้อนี้คือสาเหตุที่โปรเจกต์ AI ล้มเหลว คุณต้องเข้าใจโซลูชันก่อน แล้วจึงนำ AI เข้าไปใช้ในจุดที่สร้างมูลค่าที่วัดผลได้จริง
การใช้แนวทางเชิงประจักษ์ได้ผลดีกว่าการทุ่มไปกับมันในทันที เริ่มจากทำสิ่งเล็กๆ ให้สำเร็จ เห็นผลลัพธ์ แล้วนำผลนั้นมาประกอบการตัดสินใจในขั้นต่อไป วนลูปแบบนี้ไปเรื่อยๆ เพื่อขยายผลอย่างค่อยเป็นค่อยไปตามหลักฐานที่มี ไม่ใช่ตามข้อสมมติฐาน
ทีมเล็กๆ ที่โฟกัสกับปัญหาที่ชัดเจนจะให้บทเรียนแก่คุณได้มากกว่าแผน AI Adoption ระดับองค์กรที่พยายามจะเปลี่ยนทุกอย่างพร้อมกัน วิธีนี้ยังช่วยประหยัดงบประมาณของคุณด้วย แทนที่จะทุ่มเงินล้านตามกระแส คุณจะค่อยๆ ลงทุนเพิ่มตามหลักฐานที่ปรากฏ โดยปกติโปรเจกต์นำร่องที่เน้นจุดสำคัญจะใช้เวลาประมาณ 3-6 เดือน ตั้งแต่เริ่มจนถึงการใช้งานจริง
ในช่วง 6 เดือนที่ผ่านมา ผมได้ส่งมอบโปรเจกต์ที่ใช้งานจริงไป 2 งาน โดยที่ AI เป็นตัวสร้างโค้ดส่วนใหญ่ แต่คุณค่าที่ผมมอบให้ไม่ใช่ "ปริมาณ" ของโค้ด แต่คือ การตรวจสอบ การรู้ว่าผลลัพธ์ไหนควรเก็บไว้ อันไหนควรแก้ไข และการตัดสินใจเชิงโครงสร้างส่วนไหนที่ AI ไม่สามารถทำเองได้
นี่คือเหตุผลว่าทำไมการจัดทีม หรือการเลือกพาร์ตเนอร์ถึงสำคัญมากกว่าเมื่อก่อน คุณต้องการคนที่มีวิจารณญาณในการตัดสินผลลัพธ์จาก AI ไม่ใช่แค่คนที่ใช้ AI สร้างงานออกมาเฉยๆ
ไม่ใช่ทุกปัญหาจะเหมาะกับกลยุทธ์ AI Adoption จากประสบการณ์ของผม Use Case ที่เหมาะสมมักมีลักษณะดังนี้:
ความท้าทายในการใช้ AI มักเกิดจาก Use Case ที่ไม่เหมาะสม เช่น ปัญหาแบบใหม่ที่ไม่มีข้อมูลในอดีต, งานที่ต้องใช้การตัดสินใจที่ละเอียดอ่อนและอธิบายเป็นตรรกะได้ยาก, หรือสถานการณ์ที่ความผิดพลาดเพียงเล็กน้อยอาจส่งผลกระทบร้ายแรง
เมื่อเร็วๆ นี้ เราได้ร่วมงานกับบริษัทพลังงานแห่งหนึ่งที่ต้องการสร้างกลยุทธ์ AI Adoption ที่ยั่งยืน พวกเขามีงบประมาณเพียงพอที่จะจัดอบรมให้คนทั้งองค์กร แต่พวกเขากลับเลือกที่จะเริ่มต้นกับทีมเล็กๆ ก่อน
เราจัดเวิร์กช็อปสอนขั้นตอนการทำงานแบบ AI-Assisted Development และวิธีสร้างเครื่องมือ AI ด้วยตัวเอง ปัจจุบันทีมนั้นกำลังสร้างเครื่องมือภายในและนำไปโชว์ให้ผู้บริหารดู เพื่อของบประมาณในการใช้ AI ในวงกว้าง โดยอิงจากผลลัพธ์ที่พิสูจน์แล้ว ไม่ใช่แค่ตัวเลขคาดการณ์
Use Case ของพวกเขาทำตามหลักการข้างต้นทุกประการ คือเริ่มจากปัญหาที่มีอยู่แล้วและมีโซลูชันชัดเจน เพื่อก้าวข้ามอุปสรรคในการทำ AI Adoption ทีมเล็กๆ นี้ได้ตั้งคำถามว่า AI จะมาช่วยพัฒนาวิธีการเดิมได้อย่างไร และสร้างศักยภาพเพื่อหาคำตอบนั้นด้วยข้อมูลจริง
หากองค์กรของคุณกำลังพิจารณาการใช้ AI คุณมีทางเลือกคือ สร้างทีมเองทั้งหมด หรือร่วมมือกับพาร์ตเนอร์ที่เชี่ยวชาญการให้คำปรึกษาด้าน AI และสามารถถ่ายทอดความรู้ให้ทีมของคุณได้ โดยมีปัจจัยที่สำคัญ ได้แก่
องค์กรขนาดเล็กมักจะปรับตัวได้เร็วกว่า ที่ Seven Peaks เราผนวก AI เข้ากับวิธีการทำงานพื้นฐานของเรา ไม่ใช่แค่เครื่องมือเสริม เมื่อลูกค้าจ้าง Engineer ของเรา พวกเขาจะได้ร่วมงานกับคนที่ใช้ AI ในชีวิตประจำวัน และรู้ซึ้งถึงศักยภาพ รวมถึงข้อจำกัดของมัน
ปัญหาเรื่องการตรวจสอบความถูกต้องหมายความว่า "ประสบการณ์" สำคัญกว่ายุคก่อน AI เสียอีก คุณต้องการ Engineer ที่ตัดสินผลลัพธ์จาก AI ได้ ทีมของเราส่วนใหญ่เป็น Senior Engineer เพราะวิจารณญาณที่เก๋าเกมคือสิ่งที่จะสร้างผลลัพธ์ที่มีคุณภาพในโปรดักต์ที่พัฒนาด้วย AI
บ่อยครั้งที่ลูกค้ามาหาเราพร้อมกับโซลูชันในใจ ซึ่งบางครั้งอาจไม่ตรงกับปัญหาที่แท้จริง มุมมองของพวกเขาอาจถูกจำกัดด้วยตำแหน่งในองค์กรหรือความเข้าใจผิดเกี่ยวกับเทคโนโลยี หน้าที่ส่วนหนึ่งของเราคือการช่วยนิยามปัญหาให้ถูกต้องก่อนที่จะลงมือสร้างอะไรก็ตามผ่านกระบวนการ Product Discovery ที่เป็นระบบ ที่ Seven Peaks เรามีทั้งคนที่สามารถคัดเลือก Use Case ที่ใช่และสร้างมูลค่าได้จริง และคนที่สามารถนำ AI มาใช้งานจริงได้
เคสที่ผมเล่าไปก่อนหน้านี้เป็นตัวอย่างที่ดี เราไม่ได้แค่สร้างเครื่องมือให้พวกเขา แต่เราฝึกฝนทีมของเขาให้สร้างเองเป็นด้วย ตอนนี้ทีม In-House เล็กๆ นั้นกำลังขยายศักยภาพ AI ไปทั่วองค์กร โดยไม่ต้องพึ่งพาเราในทุกๆ โปรเจกต์ใหม่
แนวทาง "เทรนไปพร้อมกับสร้าง" สร้างมูลค่าได้มากกว่าโมเดลการจ้างงานแบบเดิมที่ลูกค้าต้องพึ่งพาคนนอกตลอดเวลา คุณจะได้ทั้งโซลูชันที่ใช้งานได้จริง และทีมงานที่สามารถดูแลและต่อยอดระบบได้เอง
การทำ AI Adoption ไม่จำเป็นต้องเป็นการเดิมพันที่มีความเสี่ยงสูง หรือกลายเป็นบทเรียนจากความล้มเหลว โดยเริ่มจากปัญหาที่คุณเข้าใจดีอยู่แล้ว ทำโปรเจกต์นำร่องกับทีมเล็กๆ วัดผลเทียบกับบรรทัดฐานปัจจุบัน สร้างศักยภาพให้ภายในองค์กรควบคู่ไปกับการใช้พาร์ตเนอร์จากภายนอก และต้องแน่ใจว่าใครก็ตามที่คุณร่วมงานด้วยมีวิจารณญาณระดับ Senior มากพอที่จะตรวจสอบผลลัพธ์จาก AI ได้ ไม่ใช่แค่สั่งให้มันสร้างงานออกมาเท่านั้น
สนใจนำ AI มาใช้ในโปรเจกต์ถัดไปของคุณไหม? ติดต่อทีมงานของเรา หรือ เรียนรู้เพิ่มเติมเกี่ยวกับบริการ AI ของเรา