อันโตน ออนูฟริเยนโค ผู้อำนวยการบริหารที่ Devart – ซีรีส์สัมภาษณ์

อันโตน ออนูฟริเยนโค ผู้อำนวยการบริหารที่ Devart เป็นผู้บริหารและผู้ดำเนินธุรกิจที่มีประสบการณ์ในการขยายธุรกิจซอฟต์แวร์ การขับเคลื่อนการเติบโตของรายได้ และการนำทีมงานข้ามฟังก์ชันต่างๆ ในด้าน SaaS ซอฟต์แวร์องค์กร และบริการทางการเงิน ในช่วงอาชีพการงานของเขา เขาได้พัฒนาตัวเองจากการจัดตั้งองค์กรขายและการเปิดตัวสตาร์ทอัพ ไปสู่การดูแลการดำเนินงาน P&L ที่สมบูรณ์สำหรับหน่วยธุรกิจหลัก รวมถึงส่วนงานที่ใหญ่ที่สุดของ Devart ซึ่งมีพนักงานมากกว่า 130 คน ก่อนที่จะกลายเป็นผู้อำนวยการบริหาร เขาเคยดำรงตำแหน่งผู้อำนวยการฝ่ายรายได้และหัวหน้าฝ่ายขายของ Devart โดยที่เขานำกลยุทธ์การตลาด การเปลี่ยนแปลงราคา และการเติบโตระหว่างประเทศ เขายังเป็น CEO ของ TMetric ซึ่งเป็นแพลตฟอร์มติดตามเวลาและความสามารถในการทำกำไรที่มุ่งเน้นช่วยให้ธุรกิจที่ขับเคลื่อนด้วยบริการได้รับความชัดเจนในการดำเนินงาน

Devart เป็นบริษัทซอฟต์แวร์ที่เชี่ยวชาญด้านการพัฒนาฐานข้อมูล การเชื่อมต่อข้อมูล การบูรณาการ และเครื่องมือความผลิตสำหรับนักพัฒนา DBA วิเคราะห์ และทีมองค์กร ก่อตั้งขึ้นในปี 1997 บริษัทเป็นที่รู้จักมากที่สุดจากชุดเครื่องมือการจัดการฐานข้อมูล dbForge ซึ่งสนับสนุนระบบฐานข้อมูลหลักๆ รวมถึง SQL Server, MySQL, Oracle (ORCL ) และ PostgreSQL Devart ยังพัฒนาโซลูชันการเชื่อมต่อข้อมูล เช่น ODBC, ADO.NET, Python และ Delphi connectors รวมถึง Skyvia ซึ่งเป็นแพลตฟอร์มบูรณาการข้อมูลบนคลาวด์สำหรับ ETL การอัตโนมัติ การสำรองข้อมูล และการบูรณาการการทำงาน บริษัทให้บริการผู้ใช้มากกว่า 500,000 คนในระดับโลก รวมถึงองค์กร Fortune 100 จำนวนมาก และได้เพิ่มการรวมความสามารถที่ขับเคลื่อนด้วย AI เข้าไปในผลิตภัณฑ์ผ่านเครื่องมือ เช่น dbForge AI Assistant ซึ่งช่วยให้นักพัฒนาสามารถสร้าง ปรับให้เหมาะสม แก้ไขปัญหา และอธิบายคำถาม SQL โดยใช้ภาษาธรรมชาติ

คุณได้พัฒนาตัวเองจากการจัดตั้งและนำทีมขายไปสู่การดำเนินงาน P&L ที่สมบูรณ์ และปัจจุบันคุณดูแลส่วนธุรกิจที่ใหญ่ที่สุดของ Devart การเดินทางนี้ได้กำหนดแนวทางของคุณในการรวม AI เข้ากับกลยุทธ์ผลิตภัณฑ์และการตัดสินใจในระดับใหญ่ๆ อย่างไร

การขายสอนให้ฉันวัด ROI ทุกอย่าง เมื่อเข้าสู่ตำแหน่ง CRO ฉันขยายวินัยนี้ไปทั่วฟังก์ชันต่างๆ การดำเนินงาน BU บังคับให้ฉันต้องใช้วินัยนี้กับ AI เอง

ฉันมีมุมมองเชิงปฏิบัติเกี่ยวกับ AI ไม่ใช่ว่าฉันไม่เชื่อ แต่ฉันเชื่อว่าความฮือฮาเข้ามาขัดขวางผลลัพธ์ที่แท้จริงและยั่งยืน

มีเรื่องตลกที่กำลังแพร่กระจายซึ่งสรุปได้ว่าอุตสาหกรรมมักจะผิดพลาดที่ไหน บริษัทต่างๆ มีการเปลี่ยนจากซอฟต์แวร์ SaaS ที่มีค่าใช้จ่าย 400 ดอลลาร์เป็นเครื่องมือที่พัฒนาขึ้นเองซึ่งมีค่าใช้จ่าย 1,000 ดอลลาร์ต่อเดือนในค่าธรรมเนียม API และต้องการการแก้ไขอย่างต่อเนื่อง นั่นไม่ใช่การเปลี่ยนแปลงที่แท้จริง มันแค่การแสดงออกที่มีค่าใช้จ่ายสูง

บทเรียนที่ฉันได้รับจากงานขายคือเรื่องง่ายๆ ทุกโครงการต้องมีผลตอบแทนที่ชัดเจน หรือจะไม่เกิดขึ้น ฉันจัดการการเปิดตัว AI ในลักษณะเดียวกับที่ฉันเคยจัดการพื้นที่ขาย

เรามีเป้าหมายหลักคือ Revenue per Employee และเราตั้งเป้าที่จะเพิ่มเป็นสองเท่าภายในสิ้นปี 2028 คุณไม่สามารถปิดช่องว่างนี้ได้ด้วยการ雇งคน คุณต้องเปลี่ยนแปลงลักษณะของงาน และ AI เป็นกลไกเดียวที่สมจริงที่ขนาดนั้น

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

Devart มีชื่อเสียงที่แข็งแกร่งในด้านเครื่องมือฐานข้อมูลและความสามารถในการพัฒนาผลิตภัณฑ์อย่างไร คุณรวม AI เข้ากับผลิตภัณฑ์เหล่านี้เพื่อมอบคุณค่าที่แท้จริงมากกว่าการทำให้ทำงานอัตโนมัติแบบผิวเผิน

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

สองปีที่แล้ว เมื่อความฮือฮาเกี่ยวกับ AI ถึงจุดสูงสุดและคู่แข่งเร่งรีบในการเพิ่มแผงพูดเข้ากับองค์ประกอบ UI ทุกอย่าง ความ诱惑ที่จะทำตามมันคือเรื่องจริง ฉันเคยเห็นรูปแบบนี้มาก่อน ในมือถือ ในคลาวด์ ใน low-code และฉันปฏิเสธที่จะทำซ้ำ

วินัยนั้นตรงไปตรงมา: คุณค่าของลูกค้าเป็นอันดับแรก การสร้างคุณสมบัติ AI ที่ไม่มีใครขอเป็นเรื่องที่แย่ที่สุดในการใช้ทรัพยากรพัฒนาแบบจำกัด

สิ่งที่เปลี่ยนแปลงไปในปี 2026 คือ AI ได้เคลื่อนจากความฮือฮาไปสู่การปฏิวัติทางเทคนิคที่แท้จริง ช่องว่างระหว่างสิ่งที่ระบบเหล่านี้สามารถทำได้ในปี 2023 และสิ่งที่พวกเขาสามารถทำได้ในปัจจุบันไม่ใช่สิ่งที่เพิ่มขึ้นเล็กน้อย มันเป็นหมวดหมู่ความสามารถที่แตกต่าง

เราสามารถแก้ปัญหาที่แท้จริงไม่สามารถแก้ไขได้ก่อนหน้านี้: การเข้าถึงข้อมูลองค์กรที่ปลอดภัยสำหรับตัวแทน AI, ความฉลาดฐานข้อมูลที่มีบริบทภายใน IDE ของนักพัฒนา และการวิเคราะห์ธุรกิจอัตโนมัติที่ไม่ต้องการนักวิเคราะห์เฉพาะ

สิ่งเหล่านี้คือผลิตภัณฑ์ใหม่ที่มีอยู่เนื่องจาก AI ทำให้ปัญหาที่ซ่อนอยู่สามารถแก้ไขได้ นั่นคือมาตรฐานที่เราตั้งไว้สำหรับตัวเอง: ผลิตภัณฑ์ AI ที่แท้จริงคือผลิตภัณฑ์ที่ถ้าคุณเอาชั้น AI ออกไป ผลิตภัณฑ์จะไม่ทำงานอีกต่อไป

อุตสาหกรรมใช้เวลาสองปีในการเรียกแผงพูดว่า “ผลิตภัณฑ์ AI” สิ่งเหล่านั้นคือคุณสมบัติ ไม่ใช่ผลิตภัณฑ์

เราต้องใช้เวลาในการทำสิ่งนี้ให้ถูกต้อง เดือนหน้าจะแสดงว่าวินัยนั้นได้ผลหรือไม่

AI กำลังเขียน ปรับให้เหมาะสม และแก้ไขโค้ดอย่างไร คุณเห็นว่าสิ่งนี้จะเปลี่ยนแปลงบทบาทของนักพัฒนาที่ทำงานกับฐานข้อมูลในอีกไม่กี่ปีข้างหน้าอย่างไร

คุณค่าของการรู้จักไวยากรณ์ SQL กำลังลดลงอย่างรวดเร็ว หาก AI สามารถสร้าง JOIN ที่ซับซ้อนได้ภายในไม่กี่วินาที และระบุอินเด็กซ์ที่หายไปจากบันทึกภายในไม่กี่นาที คุณค่าของวิศวกรจะไม่มาจากการพิมพ์ SQL อีกต่อไป ส่วนนั้นของงานกำลังจะกลายเป็นสินค้าโภคภัณฑ์

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

ฐานข้อมูลเก็บสถานะ มันไม่ให้อภัยการหลอกลวง

ความไม่สมดุลนี้กำหนดบทบาทใหม่โดยสิ้นเชิง ในช่วงสองถึงสามปีข้างหน้า นักพัฒนาฐานข้อมูลและ DBA จะพัฒนาตัวเองจากนักเขียนโค้ดไปสู่สถาปนิกและผู้ตรวจสอบ

งานหลักของพวกเขาจะเปลี่ยนไปสู่สามสิ่ง:

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

แบบจำลองจิตที่ฉันกลับมาที่มันเสมอ คือ วิศวกรจะจัดการกองทัพของตัวช่วย AI เครื่องมือ เช่น dbForge จะต้องพัฒนาไปจาก IDE ทั่วไปเป็นศูนย์กลางคำสั่งและตรวจสอบ

งานจะเปลี่ยนไปจากการที่คุณพิมพ์ SQL ด้วยมือเป็นการที่คุณตรวจสอบสิ่งที่ AI สร้างขึ้น ตรวจสอบความถูกต้อง และบังคับใช้ขอบเขตที่ AI ไม่สามารถข้ามได้อย่างปลอดภัย

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

คุณเห็นข้อจำกัดที่สำคัญที่สุดของเครื่องมือ AI ในการจัดการฐานข้อมูลในปัจจุบันอย่างไร และคุณเห็นความก้าวหน้าที่มีความหมายที่สุดมาจากที่ไหน

AI ในปัจจุบันยังคงติดอยู่กับการทำให้ทำงานอัตโนมัติแบบผิวเผิน การสร้างคำถาม SQL พื้นฐานหรือโค้ดโบイเลอร์เพลทไม่น่าประทับใจอีกต่อไป ปัญหาใหญ่กว่าคือระบบ AI ส่วนใหญ่ยังคงทำงานเหมือนคนพิมพ์แบบไม่เห็น ไม่ใช่เหมือนสถาปนิกระบบ

ฉันเห็นข้อจำกัดหลักๆ สามประการของ AI ในสภาพแวดล้อมฐานข้อมูล

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

ประการที่สอง มีปัญหาเรื่องการหลอกลวง องค์กรไม่มีความอดทนแม้แต่น้อยต่อการหลอกลวงที่ระดับฐานข้อมูล การหลอกลวง JOIN สามารถชะลอระบบการผลิตได้ การอัปเดตที่ผิดพลาดสามารถลบข้อมูลที่สำคัญได้

ประการที่สาม คือเรื่องความปลอดภัยและธรรมาภิบาล องค์กรที่จริงจังไม่จะวางแผนการผลิตหรือ PII ไปยังเครื่องมือ AI สาธารณะโดยไม่มีการรับประกันการแยกข้อมูลและควบคุมที่เข้มงวด

ความก้าวหน้าที่มีความหมายจะเกิดขึ้นเมื่อ AI เคลื่อนตัวออกจากการสร้างไวยากรณ์ไปสู่การทำงานเหมือนสถาปนิกหรือผู้วิเคราะห์

ส่วนหนึ่งของสิ่งนี้คือชั้นเซมานติก: การย้ายจากชื่อตารางไปสู่ความหมายทางธุรกิจที่แท้จริง ไม่ใช่แค่ “ตารางผู้ใช้” แต่เข้าใจแนวคิด เช่น กลุ่มลูกค้า ความเสี่ยงในการทิ้งลูกค้า หรือแนวโน้ม LTV ในไตรมาสที่ 3

การเปลี่ยนแปลงอีกส่วนหนึ่งคือ AI ทำงานเหมือน DBA อาวุโสในพื้นหลัง การวิเคราะห์งานอย่างต่อเนื่อง การระบุจุดอ่อน การแนะนำอินเด็กซ์ การตรวจจับคำถามที่มีความเสี่ยง และการตรวจจับปัญหา قبلที่ระบบจะล้มเหลว

แล้วคุณมีการดำเนินการระหว่างเครื่องจักร โดยมีตัวแทนอัตโนมัติที่ตรวจสอบการโหลดฐานข้อมูล ทดสอบกลยุทธ์การปรับให้เหมาะสมใน môi trườngที่แยกออก และปรับใช้การปรับปรุงภายใต้การดูแลของมนุษย์

สิ่งเหล่านี้คือการพัฒนาที่จะกำหนดรูปแบบเครื่องมือฐานข้อมูลในอีกห้าปีข้างหน้า

จากประสบการณ์ของคุณในการนำกลยุทธ์รายได้และการตลาด AI กำลังเปลี่ยนแปลงรูปแบบการกำหนดราคา การจัดแพ็คเกจผลิตภัณฑ์ และการได้ลูกค้าใหม่ๆ ในบริษัทซอฟต์แวร์อย่างไร

คู่มือการตลาดแบบดั้งเดิมถูกทำลายแล้ว เราเห็นสิ่งนี้ในตัวเลขของเราเองและทั่วทั้งหมวดเครื่องมือสำหรับนักพัฒนา

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

ห้าปีที่แล้ว กลยุทธ์ nội dung ที่แข็งแกร่งเพียงพอในการขับเคลื่อนการเติบโต ปัจจุบันกลายเป็นเรื่องพื้นฐาน การจัดอันดับเนื้อหาที่แข็งแกร่งไม่เพียงพอในการขับเคลื่อนการเติบโตอีกต่อไป

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

การเปลี่ยนแปลงของราคา: จากที่นั่งไปสู่ PLG 3.0 เรากำลังเข้าสู่ขั้นตอนต่อไปของ PLG การกำหนดราคาแบบต่อที่นั่งเริ่มแตกเมื่อตัวแทน AI หนึ่งตัวสามารถทำงานของพนักงานหลายคนได้ ในสภาพแวดล้อมดังกล่าว การเรียกเก็บเงินตามจำนวนพนักงานไม่มีเหตุผลอีกต่อไป บริษัทที่ไม่จัดแพ็คเกจผลิตภัณฑ์ใหม่ตามมูลค่ามากกว่าจำนวนพนักงานจะสูญเสียรายได้ประจำเดือนในอีก 24 เดือนข้างหน้า

ขั้นตอนต่อไปคือ PLG 3.0: ช่วงเวลาที่ตัวแทน AI อัตโนมัติ ไม่ใช่คน เป็นผู้ประเมิน ทดสอบ และซื้อซอฟต์แวร์องค์กร การนำรูปแบบนี้ไปใช้อย่างแพร่หลายยังคงอยู่ห่างออกไปอีกไม่กี่ปี แต่การออกแบบผลิตภัณฑ์และการกำหนดราคาเพื่อผู้ซื้อเครื่องจักรเป็นงานในปี 2026 ไม่ใช่ปี 2028

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

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

ฉันเห็นข้อผิดพลาดเดียวกันซ้ำๆ ในบริษัทที่ดิ้นรนในการย้าย AI จากการทดลองไปสู่ผลกระทบการผลิตที่แท้จริง

ข้อผิดพลาดแรกคือการสร้างฟีเจอร์ AI ที่ไม่มีใครขอ เมื่อคุณบังคับฟีเจอร์ AI โดยไม่มีความต้องการที่แท้จริง ทีมงานจะทำงานย้อนกลับจากเทคโนโลยีเพื่อสร้างกรณีการใช้งาน ผลลัพธ์คือคาดเดาได้: แผงพูดที่ถูกยึดเข้ากับ UI ที่มีอยู่ การเติมอัตโนมัติที่ขัดขวางการทำงาน และปุ่ม “สรุป” ที่ผลิตผลลัพธ์ที่แย่กว่าที่ผู้ใช้สามารถเขียนเองได้

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

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

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

มีปัจจัยที่ห้าที่กำลังจะกลายเป็นเรื่องสำคัญและที่ทีมผลิตภัณฑ์ส่วนใหญ่ไม่สนใจ

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

นี่คือปัญหาที่เรากำลังแก้ไขด้วย AI Connectivity ไม่ใช่การถอด AI ออก แต่การให้โครงสร้าง AI ที่เหมาะสมกับข้อจำกัดของลูกค้า

ทีมที่ทำสิ่งนี้ได้ถูกต้องจะออกแบบสำหรับการปฏิบัติตามมาตรฐานตั้งแต่วันแรก ทีมที่ทำผิดพลาดค้นพบปัญหานี้ระหว่างการตรวจสอบการซื้อ เมื่อสделка已经 потеряна

Devart ดำเนินธุรกิจในหลายระบบฐานข้อมูล AI สามารถช่วยให้การจัดการข้อมูลที่ซับซ้อนในหลายแพลตฟอร์มง่ายขึ้นได้อย่างไร

ความเจ็บปวดเป็นเรื่องจริง องค์กร Fortune 500 ทั่วไปใช้ฐานข้อมูลที่แตกต่างกัน 8-12 ระบบพร้อมๆ กัน: Oracle ที่มีประวัติยาวนานสำหรับการเงิน PostgreSQL สำหรับบริการใหม่ๆ SQL Server สำหรับการดำเนินงาน Snowflake หรือ BigQuery สำหรับการวิเคราะห์ และมักจะมี vector store สำหรับการฝังตัว

AI ไม่สามารถแก้ปัญหาความซับซ้อนนี้ได้ด้วยตัวเอง มันเพิ่มสิ่งที่ได้รับจากบริบท AI สิบฐานข้อมูลที่ไม่เชื่อมต่อกันสร้างชุดคำแนะนำที่ไม่เชื่อมต่อกัน

โอกาสนี้อยู่ในชั้นบริบทที่อยู่ระหว่างตัวแทน AI และฐานข้อมูลที่ซ่อนอยู่ ชั้นที่พูดได้กับทั้งหมด Normalize เมตาดาต้า บังคับใช้นโยบายการกำกับดูแลที่เป็นเอกภาพ และเปิดเผยอินเทอร์เฟซ MCP ที่สะอาดเพื่อให้ตัวแทน AI ใดๆ ที่ทำงานทั่วทั้นอสังหาริมทรัพย์ด้วยกฎที่สอดคล้องกัน

นั่นคือโครงสร้างที่เรากำลังสร้างไปสู่ AI Connectivity: เซิร์ฟเวอร์ MCP อน-premise ที่รองรับหลายฐานข้อมูล ชั้นเซมานติกที่จับคำจำกัดความทางธุรกิจหนึ่งครั้งแทนการบังคับตัวแทน AI ทุกตัวให้เรียนรู้ซ้ำๆ การควบคุมการเข้าถึงตามบทบาทในระดับการดำเนินการ SQL และบันทึกการตรวจสอบเต็มรูปแบบ

การทำให้ง่ายขึ้นไม่ฟรี บางคนยังคงต้องสร้างชั้นเซมานติกและตั้งค่านโยบาย แต่งานนั้นเกิดขึ้นเพียงครั้งเดียว ไม่ใช่ซ้ำๆ สำหรับตัวแทน AI ทุกตัวที่คุณเพิ่ม

คุณเคยเป็นผู้นำทีมงานข้ามฟังก์ชันต่างๆ มาก่อน AI กำลังเปลี่ยนแปลงการทำงานร่วมกันและการตัดสินใจภายในระหว่างผลิตภัณฑ์ วิศวกรรม การตลาด และการขายอย่างไร

ความเสี่ยงส่วนใหญ่ระหว่างทีมงานข้ามฟังก์ชันคือคนกำลังรอข้อมูลจากทีมอื่นๆ AI ลดความเสี่ยงนี้ได้เร็วกว่ากรอบการบริหารจัดการใดๆ ที่เคยเป็นมา

การเปลี่ยนแปลงเป็นเรื่องปฏิบัติและทันที

ในผลิตภัณฑ์และวิศวกรรม: ผู้จัดการผลิตภัณฑ์ถามคำถามฐานข้อมูลในภาษาธุรกิจที่เรียบง่าย “ความแปรผันของ LTV ในสามระดับราคาที่ดีที่สุดคืออะไร?” และได้รับคำตอบที่ใช้งานได้ทันที แทนที่จะส่งตั๋ว Jira ไปยังทีมวิเคราะห์และรอสามวัน

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

ในด้านการขายและวิศวกรรม: คำตอบทางเทคนิคสำหรับลูกค้ามือใหม่ไม่ต้องการการนัดหมายกับวิศวกรอาวุโสอีกต่อไป ตัวแทนการขายได้รับคำตอบทางเทคนิคที่น่าเชื่อถือในเวลาจริง และวงจรการทำธุรกรรมย่อลง

การตัดสินใจเคลื่อนไปสู่การอภิปราย มากกว่าการตามมาด้วยหมายเลขที่จะตามมา “ให้ฉันกลับมาพบกับคุณด้วยตัวเลขนั้น” เป็นรูปแบบที่กำลังจะตาย การประชุมย่อลงเพราะ AI จัดการการอ่านล่วงหน้าและสรุปซึ่งเคยใช้เวลาก่อนหน้านี้ครึ่งหนึ่งของทุกเซสชัน

การเปลี่ยนแปลงนี้บังคับให้เกิดการเปลี่ยนแปลงการบริหารจัดการที่ลึกซึ้งยิ่งขึ้น และเป็นสิ่งที่ทีมผู้นำส่วนใหญ่ประเมินต่ำเกินไป

ทุกบริษัทอ้างว่าตัวเองมุ่งเน้นผลลัพธ์ แต่เมื่อดูอย่างใกล้ชิด ส่วนใหญ่ยังคงทำงานบนเมตริกที่เป็นไปแทน: จุดเรื่อง วงจรโค้ด ตั๋วที่ปิด ลูกเล่นหรือชั่วโมงที่บันทึกไว้ เราใช้กิจกรรมเป็นไปแทนคุณค่าเพราะคุณค่าที่แท้จริงยากที่จะวัด เมื่อ AI สามารถเขียนโค้ด 10,000 บรรทัดหรือปิดตั๋ว 500 ตัวในหนึ่งนาที การวัดกิจกรรมจะกลายเป็นความผิดพลาดที่อันตราย

เรากำลังย้ายไปสู่การบริหารจัดการที่มุ่งเน้นผลลัพธ์อย่างแท้จริง โดยที่ประสิทธิภาพจะวัดจากผลลัพธ์เท่านั้น และการตัดสินใจ

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

ด้วยการเพิ่มขึ้นของการพัฒนาที่ได้รับการช่วยเหลือจาก AI และเครื่องมือแบบไม่ต้องเขียนโค้ด เรากำลังจะเข้าสู่ยุคที่การจัดการฐานข้อมูลจะกลายเป็นเรื่องที่สามารถเข้าถึงได้สำหรับผู้ใช้ที่ไม่ใช่คนเทคนิคหรือไม่

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

สำหรับโปรเจ็กต์ขนาดเล็กและใหม่ การทำให้ประชาชนทั่วไปเข้าถึงได้แล้ว ฉันเคยสร้างแอปพลิเคชันขนาดเล็กจากศูนย์โดยไม่ต้องมีความรู้ด้านการจัดการฐานข้อมูลลึกๆ หากสเคมาทั้งหมดของคุณพอดีกับหน้าต่างบริบทของ LLM AI ก็ทำงานเหมือนเวทมนตร์ นักพัฒนาที่ไม่ใช่คนเทคนิคที่สร้างเครื่องมือภายในในขนาดเล็กจะเป็นหมวดหมู่ที่แท้จริงและเติบโต

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

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

ดังนั้น การจัดการฐานข้อมูลองค์กรจึงไม่ได้กลายเป็นสนามเด็กเล่นสำหรับผู้ใช้ที่ไม่ใช่คนเทคนิค

นักพัฒนาที่ไม่ใช่คนเทคนิคคือเรื่องราวที่ไม่มีอยู่ในระดับใหญ่

อนาคตเป็นของสถาปนิกข้อมูลที่เชี่ยวชาญซึ่งใช้เครื่องมือมืออาชีพเพื่อสร้างโครงสร้างพื้นฐานที่ทำให้ AI สามารถทำงานอย่างปลอดภัยบนฐานข้อมูลได้

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

หากไม่มีสิ่งนี้ การเข้าถึงจะกลายเป็นความเสี่ยง

เมื่อมองไปข้างหน้า เครื่องมือพัฒนาที่ “เป็นมิตรกับ AI” จะเป็นอย่างไร และทีมควรเตรียมตัวสำหรับการเปลี่ยนแปลงนี้อย่างไรในปัจจุบัน

เครื่องมือพัฒนาที่เป็นมิตรกับ AI จริงๆ ไม่ใช่แค่การเพิ่มช่องพูดเข้ากับ IDE ส่วนใหญ่ของสิ่งที่ถูกตลาดเป็น “เป็นมิตรกับ AI” ในปัจจุบันคืออินเทอร์เฟซช่องพูดบวกโมเดลการเติมอัตโนมัติ นั่นคือสิ่งพื้นฐาน ไม่ใช่จุดหมาย

สำหรับฉัน เครื่องมือพัฒนาที่เป็นมิตรกับ AI จริงๆ ต้องมีสามสิ่ง

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

ประการที่สอง เครื่องมือต้องสามารถพูดคุยกันเองได้อย่างเหมาะสม IDE ของคุณจะต้องสามารถพูดคุยกับฐานข้อมูล ฐานข้อมูลกับสตैकการดูแลระบบ และ CI/CD กับเครื่องมือตรวจสอบ AI

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

วิธีการเตรียมตัวที่เป็นรูปธรรม

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

สร้างโครงสร้างบริบทตอนนี้ ระบุสเคม่า คำจำกัดความทางธุรกิจ และการตัดสินใจด้านสถาปัตยกรรมในรูปแบบที่เครื่องจักรสามารถอ่านได้ บริบทที่มีความ豊富ไม่ได้ถูกสร้างขึ้นในหนึ่งในสี่ โทษที่ทำสิ่งนี้ได้ดีก่อนปี 2027 คือทีมที่กำลังบันทึกวันนี้

ใช้ AI ในการผลิตก่อนที่คุณจะคิดว่าคุณพร้อม ทีมที่รอจนกว่าจะมี “กลยุทธ์ AI” อย่างเป็นทางการก่อนที่จะจัดส่งจะอยู่หลังทีมที่เรียนรู้จากความล้มเหลวในการผลิตจริงแล้ว เลือกกรณีการใช้งานที่มีความเสี่ยงต่ำ จัดส่ง มันสร้างกล้ามเนื้อ

ทีมที่ตัดสินใจเหล่านี้วันนี้จะกำหนดทิศทางของซอฟต์แวร์ที่จะถูกสร้างในอีกสิบปีข้างหน้า ช่องโหว่นี้แคบ และเปิดอยู่ตอนนี้

ขอขอบคุณสำหรับการสัมภาษณ์ที่ดี ผู้อ่านสามารถเรียนรู้เพิ่มเติมได้ที่ Devart