ในบทความก่อนหน้านี้ ผมได้เขียนเกี่ยวกับสถานะปัจจุบันของการนิยามความต้องการด้าน AI—ว่ากระบวนการกำลังเปลี่ยนจาก 'การจัดระเบียบ' ไปเป็น 'การตัดสินใจ' และความกังวลของผมที่ว่าหลายองค์กรกำลังโยนกระบวนการคิดทิ้งไปโดยไม่รู้ตัว
ครั้งนี้ ผมอยากจะส่งสัญญาณเตือนอีกครั้งในประเด็นที่เกี่ยวข้องกัน
ปัญหาคือ CTO และ SE ภายใน ซึ่งตอนนี้สามารถเขียนโค้ดได้เร็วมากด้วย AI-driven development กำลังกลายเป็นเพียง 'คนรับคำสั่ง' จากฝ่ายธุรกิจ หรือพูดง่ายๆ ว่าเป็น 'SI ภายใน'
พลวัตใหม่ที่เกิดจาก AI-Driven Development
เป็นข้อเท็จจริงที่ปฏิเสธไม่ได้ว่าการแพร่กระจายของ AI-driven development ได้ลดอุปสรรคในการเขียนโค้ดลงอย่างมาก
เป็นผลให้คำขอจากฝ่ายธุรกิจ เช่น 'ฉันอยากได้สิ่งนี้' หรือ 'ฉันอยากทำให้สิ่งนี้เป็นระบบ' ถูกส่งเข้ามาด้วยความเร็วที่เทียบไม่ได้กับเมื่อก่อน ไม่ใช่เรื่องแปลกที่พนักงานฝ่ายธุรกิจจะใช้ AI ในการเขียนข้อกำหนดความต้องการเอง หรือ甚至สร้างต้นแบบขึ้นมา
เมื่อมองผิวเผิน นี่ดูเหมือนจะเป็นสิ่งที่ดี ดูเหมือนจะเป็นสถานการณ์ในอุดมคติที่ฝ่ายธุรกิจเป็นผู้นำด้าน DX และร่วมมือกับฝ่าย IT เพื่อเปิดตัวระบบได้อย่างรวดเร็ว
อย่างไรก็ตาม มีกับดักอยู่ตรงนี้
ผมรู้สึกว่า CTO และ SE ภายในกำลังกลายเป็น 'คนที่แค่ทำให้คำขอจากฝ่ายธุรกิจเป็นรูปร่าง' มากขึ้นเรื่อยๆ พวกเขาได้รับคำขอ ทำให้มันเป็นจริงในทางเทคนิค และส่งมอบ นี่คือสิ่งที่ SI ภายใน ทำนั่นเอง
สิ่งรออยู่ที่ปลายทางของการรับคำสั่ง
การตอบสนองต่อคำขอทางธุรกิจนั้นไม่ผิดในตัวของมันเอง ปัญหาคือ สิ่งที่เกิดขึ้นเมื่อคุณยังคงทำตามคำขอของแต่ละแผนกตามที่เป็นอยู่ต่อไป
ผมเรียกสิ่งนี้ว่า การแพร่กระจายของ 'ระบบจรจัด' และ 'ฐานข้อมูลจรจัด'
ฝ่ายขายสร้าง CRM ของตัวเอง ฝ่ายการตลาดตั้งค่าแพลตฟอร์มวิเคราะห์ข้อมูลแยกต่างหาก และฝ่ายสนับสนุนลูกค้าสร้างระบบจัดการ tickets ของตัวเอง แต่ละแผนกพอใจเพราะได้ระบบที่เหมาะกับงานของตัวเองด้วยความเร็วสูง
แต่ในภาพรวมของบริษัทล่ะ?
ข้อมูลกระจัดกระจายอยู่ในที่ต่างๆ รูปแบบไม่เป็นหนึ่งเดียวกัน ข้อมูลลูกค้าคนเดียวกันมีอยู่ในหลายฐานข้อมูลในรูปแบบที่แตกต่างกัน ทุกครั้งที่พยายามเชื่อมโยงข้อมูลระหว่างแผนก ต้องใช้แรงงานคนหรือการพัฒนาที่กำหนดเอง
นี่คือ ไซโลทางเทคนิค
เนื่องจาก AI-driven development ทำให้การสร้างระบบเป็นเรื่องง่ายมาก การเกิดไซโลนี้จึงดำเนินไปด้วยความเร็วที่ไม่เคยมีมาก่อน ก่อนหน้านี้ ต้นทุนการพัฒนาที่สูงทำหน้าที่เป็นเบรกธรรมชาติ มีพลวัตที่ว่า 'สร้างยาก ดังนั้นต้องคัดสรรอย่างเข้มงวดเฉพาะสิ่งที่จำเป็นจริงๆ'
ตอนนี้ เบรกนั้นหายไปแล้ว เพราะสร้างได้ ก็เลยสร้างขึ้นมา ผลลัพธ์คือ ระบบจรจัดและฐานข้อมูลจรจัดทวีคูณ และ จำนวนแอปและโครงสร้างพื้นฐานที่ต้องจัดการก็เพิ่มขึ้นเรื่อยๆ
ทำไมสิ่งนี้ถึงร้ายแรงในยุค AI
คุณอาจคิดว่า 'ถึงระบบจะกระจัดกระจายไปหน่อย แต่ถ้ามันใช้งานได้ก็ไม่เป็นไร' อย่างไรก็ตาม ในยุค AI การเกิดไซโลนี้ทำให้เกิดปัญหาที่ร้ายแรงกว่าที่เคย
เหตุผลง่ายมาก: คุณค่าของ AI แปรผันตามระดับของการบูรณาการข้อมูล
AI จะแสดงพลังที่แท้จริงเมื่อข้อมูลถูกรวมเข้าด้วยกันทั่วทั้งบริษัท ทำให้เกิดข้อมูลเชิงลึกที่ครอบคลุมหลายแผนก เฉพาะเมื่อข้อมูลการขาย ประวัติลูกค้า ผลกระทบทางการตลาด และข้อมูลทางการเงินถูกรวมเข้าไว้ด้วยกัน AI จึงจะให้ข้อมูลเชิงลึกที่ช่วยในการตัดสินใจของผู้บริหาร
ในสภาพแวดล้อมที่เต็มไปด้วยระบบจรจัด ข้อมูลไม่ได้เชื่อมต่อกันตั้งแต่แรก คุณอาจทำการเพิ่มประสิทธิภาพด้วย AI เล็กๆ น้อยๆ ภายในแผนกได้ แต่คุณจะไม่มีวันไปถึงการใช้งาน AI ในระดับบริษัท—แบบที่มีผลกระทบทางธุรกิจอย่างแท้จริง
ด้วยการสะสมการเพิ่มประสิทธิภาพเฉพาะแผนก คุณจะสูญเสียการเพิ่มประสิทธิภาพโดยรวมอย่างถาวร นี่คือความเสี่ยงที่ CTO และ SE ภายในที่รับคำสั่งสร้างขึ้นโดยไม่รู้ตัว
บทบาทที่แท้จริงที่ CTO และ SE ภายในควรเล่น
แล้ว CTO และ SE ภายในควรเป็นอย่างไร?
คำตอบชัดเจน: เป็น 'นักออกแบบและผู้ตัดสินใจ' มากกว่าแค่ 'ผู้สร้าง'
'การออกแบบ' ในที่นี้ไม่ได้หมายถึงการออกแบบระบบเฉพาะ มันหมายถึง การออกแบบสถาปัตยกรรมข้อมูลและระบบสำหรับทั้งบริษัท
เมื่อมีคำขอมาจากฝ่ายธุรกิจ แทนที่จะสร้างมันขึ้นมาเฉยๆ คุณต้องตัดสินว่า 'คำขอนี้ควรอยู่ในตำแหน่งใดภายในสถาปัตยกรรมของทั้งบริษัท' ในบางกรณี คุณต้องพูดว่า 'สิ่งนี้ไม่ควรสร้างแยกต่างหาก' ถ้าสามารถจัดการได้โดยการขยายแพลตฟอร์มที่มีอยู่ ก็แนะนำให้ไปทางนั้น
สิ่งนี้อาจทำให้ฝ่ายธุรกิจรู้สึกไม่สะดวก พวกเขาอาจถามว่า 'ทำไมคุณถึงพูดถึงทั้งบริษัท ในเมื่อฉันแค่อยากให้สร้างสิ่งนี้ตอนนี้?'
แต่มีเพียง CTO และ SE ภายในเท่านั้นที่สามารถตัดสินใจแบบนั้นได้ ฝ่ายธุรกิจมีแรงจูงใจที่จะเพิ่มประสิทธิภาพในพื้นที่ของตัวเอง แต่ไม่มีแรงจูงใจที่จะปกป้องสถาปัตยกรรมของทั้งบริษัท นั่นเป็นเหตุผลว่าทำไมผู้เชี่ยวชาญด้านเทคนิคต้องเล่นบทบาทของ ผู้พิทักษ์แห่งการเพิ่มประสิทธิภาพโดยรวม
'การตัดสินใจไม่สร้าง' คือทักษะทางเทคนิคสูงสุด
ที่น่าขันก็คือ ความสามารถที่สำคัญที่สุดที่จำเป็นสำหรับ CTO และ SE ภายในในยุค AI อาจเป็น 'การตัดสินใจไม่สร้าง' นี่คือสาเหตุที่ผมเรียกพวกเขาว่า 'ผู้ตัดสินใจ'
มีคำขอมาจากฝ่ายธุรกิจ มันเป็นไปได้ทางเทคนิค ด้วย AI มันสามารถทำให้เป็นรูปร่างได้ภายในไม่กี่วัน แต่คุณต้องมีพลังที่จะตั้งคำถามว่าการสร้างมันนั้นถูกต้องสำหรับทั้งบริษัทจริงหรือไม่
คำขอนี้สามารถจัดการได้ด้วยแพลตฟอร์มที่มีอยู่หรือไม่? โครงสร้างข้อมูลสอดคล้องกับกฎของบริษัทหรือไม่? มีระบบที่คล้ายกันกำลังทำงานอยู่ในแผนกอื่นอยู่แล้วหรือไม่? การเพิ่มระบบที่ปรับให้เหมาะสมเฉพาะบุคคลจะทำให้การบูรณาการข้อมูลในอนาคตยากขึ้นหรือไม่?
การสามารถถามคำถามเหล่านี้ได้คือความแข็งแกร่งทางเทคนิคที่แท้จริงในยุค AI
AI จะจัดการเรื่องการเขียนโค้ด อย่างไรก็ตาม การตัดสินใจว่าควรสร้างอะไรและไม่ควรสร้างอะไร นั้น AI ไม่สามารถทำได้ ดังที่ผมกล่าวไว้ในบทความก่อนหน้านี้ว่า 'การนิยามความต้องการจะกลายเป็นกระบวนการของการตัดสินใจ' บทบาทของ CTO และ SE ภายในก็เป็นไปตามโครงสร้างเดียวกันนี้ทุกประการ
แทนที่จะเป็นผู้รับคำสั่ง บทบาทของคุณในฐานะผู้ออกแบบสถาปัตยกรรมทั้งบริษัทมีความสำคัญมากขึ้นเรื่อยๆ เพราะยุค AI
สร้าง 'สถานะแห่งความพร้อม' เพราะอนาคตคาดเดาไม่ได้
ในขณะที่ผมเน้นย้ำถึงความสำคัญของ 'การตัดสินใจไม่สร้าง' ยังมีอีกมุมมองหนึ่งที่ CTO และ SE ภายในควรมี
เพราะอนาคตในยุค AI คาดเดาไม่ได้ คุณต้องทำให้บริษัทอยู่ในสถานะที่สามารถเคลื่อนไหวได้ทุกเมื่อ
ปัจจุบัน วาทกรรมที่ว่า 'SaaS ตายแล้ว' กำลังแพร่กระจาย ตั้งแต่ Satya Nadella ซีอีโอของ Microsoft กล่าวคำเหล่านี้ในช่วงปลายปี 2024 หลายคนทำนายการสิ้นสุดของ SaaS จริงอยู่ที่ valuation ของ SaaS ถูกบีบอัด และความสนใจของนักลงทุนเปลี่ยนไปที่แพลตฟอร์ม AI-native อย่างรวดเร็ว
แต่ SaaS กำลังจะตายจริงหรือ?
ผมคิดว่ามันไม่ง่ายขนาดนั้น บริษัท SaaS กำลังลงทุนอย่างหนักใน R&D เพื่อหารูปแบบซอฟต์แวร์ที่เหมาะสมที่สุดสำหรับยุค AI การผสานรวม AI agentic การคิดค่าบริการตามผลลัพธ์ แพลตฟอร์ม AI เฉพาะอุตสาหกรรม... มีความเป็นไปได้สูงที่ผลิตภัณฑ์จะเกิดขึ้นในรูปแบบที่เราจินตนาการไม่ได้ในตอนนี้
กล่าวอีกนัยหนึ่ง ทั้งการสรุปว่า 'SaaS ตายแล้ว' แล้วรีบพัฒนาภายใน และการหยุดคิดด้วยการคิดว่า 'SaaS ก็เพียงพอแล้ว' ล้วนเป็นความเสี่ยง
ท่าทีที่ CTO/SE ภายในควรมีคือไม่เดิมพันฝั่งใดฝั่งหนึ่ง มันคือ การออกแบบสถาปัตยกรรมที่สามารถตอบสนองได้ไม่ว่าสิ่งต่างๆ จะเปลี่ยนไปทางไหน
โดยเฉพาะอย่างยิ่ง กำหนดมาตรฐานว่าข้อมูลถูกจัดเก็บอย่างไร และสร้างโครงสร้างที่ไม่ถูกล็อกกับ SaaS หรือเครื่องมือใดเครื่องมือหนึ่ง ให้การเชื่อมต่อระบบหลวมผ่าน API อย่าให้ระบบจรจัดแพร่กระจาย รวมรากฐานข้อมูลของบริษัทให้เป็นหนึ่งเดียว
ด้วยปรัชญาการออกแบบนี้ ถ้า SaaS พัฒนาไปและมีผลิตภัณฑ์ที่ดีกว่าออกมา คุณก็สามารถสลับได้ ในทางกลับกัน ถ้าชัดเจนว่าการสร้างภายในดีกว่าสำหรับบางพื้นที่ คุณก็ย้ายไปที่นั่นได้
คุณไม่สามารถทำนายอนาคตได้ แต่คุณสามารถสร้างโครงสร้างที่ตอบสนองต่อมันได้ นั่นคือ แก่นแท้ของการออกแบบสถาปัตยกรรมที่จำเป็นสำหรับ CTO และ SE ภายในในยุค AI และในทางกลับกัน มีเพียงผู้เชี่ยวชาญด้านเทคนิคเท่านั้นที่ทำสิ่งนี้ได้ ผมไม่อยากให้คุณใช้ทรัพยากรอันมีค่าเหล่านั้นในฐานะ SI ภายใน
เร่งกระบวนการต้นน้ำด้วย AI
เพื่อเป็นเครื่องมือสนับสนุนการเปลี่ยนแปลงของกระบวนการต้นน้ำ เราได้เปิดตัว 'GEAR-UI' เครื่องมือ AI สำหรับสร้างนิยามหน้าจอและ mock ในรูปแบบ OSS (ซอฟต์แวร์โอเพนซอร์ส)
ด้วยการทำให้เป็น OSS เราหวังว่าจะปลดปล่อยผู้ใช้จากอุปสรรคในการนำไปใช้ และช่วยให้พวกเขาเผชิญหน้ากับแก่นแท้ของสิ่งต่างๆ โปรดใช้มัน โดยเฉพาะอย่างยิ่งสำหรับการ 'ตัดสินใจก่อนสร้าง' ที่ผมได้กล่าวถึง
การปรับแต่งทำได้ฟรี โปรดนำไปใช้ให้เกิดประโยชน์
