มุมมองภาษาเรียบง่ายว่าแลร์รีย์ เอลลิสันและ Oracle สร้างความมั่งคั่งยาวนานอย่างไร ผ่านฐานข้อมูล ต้นทุนการเปลี่ยน การให้ไลเซนส์ และวินัยในการขายให้องค์กร
สูตรของแลร์รีย์ เอลลิสันสำหรับความมั่งคั่งที่ยั่งยืนสรุปได้แบบนี้: ขายฐานข้อมูลที่เป็นระบบสำคัญ ห่อด้วยสัญญาหลายปี และสร้างเครื่องจักรการขายให้ภาคธุรกิจที่ทำให้การอยู่ต่อรู้สึกปลอดภัยกว่าการเปลี่ยน
นี่คือเรื่องราวธุรกิจเกี่ยวกับว่าทำไม Oracle จึงยากจะถูกแทนที่—ไม่ใช่คู่มือเชิงเทคนิคว่าระบบฐานข้อมูลทำงานอย่างไร คุณไม่จำเป็นต้องรู้ว่า SQL optimizer ทำงานอย่างไรเพื่อเข้าใจว่าทำไม Oracle ถึงกลายเป็นเครื่องสร้างกระแสเงินสดเป็นเวลาหลายสิบปี
“ยั่งยืน” ไม่ได้แปลว่าลูกค้าจะชอบทุกการต่อสัญญา แต่หมายความว่า Oracle วางตำแหน่งตัวเองให้รายได้มีแนวโน้มเกิดซ้ำ
ความยั่งยืนปรากฏเป็น:
เมื่อฐานข้อมูลอยู่ใต้ระบบเรียกเก็บเงิน สต็อก HR หรือระบบการเทรด มันไม่ได้เป็นแค่เครื่องมือไอทีชิ้นหนึ่ง แต่มันกลายเป็นการพึ่งพา และการพึ่งพานั่นแหละที่ทำให้ยึดติด
1) ฐานข้อมูลเป็นรากฐาน. Oracle เน้นชั้น "system of record"—ที่ซึ่งข้อมูลปฏิบัติการมีมูลค่าสูงสุด
2) การผูกมัด (บางทีก็โดยไม่ตั้งใจ). ไม่ใช่แค่ความเข้ากันได้เชิงเทคนิค แต่รวมถึงกระบวนการ การผสาน ระบบการฝึกอบรม และฟีเจอร์เฉพาะผู้ขายที่สะสมขึ้นมาหลายปี
3) การขายให้ภาคธุรกิจ. Oracle ไม่ชนะเหมือนแอปสำหรับผู้บริโภค แต่มันชนะด้วยวงจรจัดซื้อ ความสัมพันธ์ระดับผู้บริหาร และสัญญาที่ออกแบบมาเพื่อขยายความสัมพันธ์
ร่วมกัน เสาหลักเหล่านี้สร้างผลทบต้น: แต่ละดีลใหม่ไม่ได้เป็นแค่การขายครั้งเดียว—มันเพิ่มโอกาสของการรับเงินในอนาคตหลายครั้ง
แลร์รีย์ เอลลิสันไม่ได้เริ่มต้นเป็นคนดังด้านซอฟต์แวร์ ช่วงต้นอาชีพของเขาเป็นการผสมผสานงานโปรแกรมมิงและการเรียนรู้ว่าหน่วยงานขนาดใหญ่ซื้อเทคโนโลยีอย่างไร—ช้า รอบคอบ และชอบผู้ขายที่ดูมั่นคง
Oracle เริ่มในปี 1977 (ในชื่อ Software Development Laboratories) ด้วยสมมติฐานชัดเจน: เงินมากที่สุดในซอฟต์แวร์จะมาจากการขายโครงสร้างพื้นฐานให้หน่วยงานขนาดใหญ่ ไม่ใช่จากการสร้างระบบเฉพาะกิจทีละชิ้น แทนที่จะไล่ตามตลาดงานอดิเรกหรือตลาดผู้บริโภคในระยะแรก Ellison และผู้ร่วมก่อตั้งมุ่งเป้าไปที่บริษัทและหน่วยงานราชการที่ต้องการระบบเพื่อรันเงินเดือน สต็อก การเรียกเก็บเงิน และบัญชี
ในเวลานั้น คอมพิวติ้งถูกครอบงำโดยเมนเฟรมและการจัดการข้อมูลแบบศูนย์กลาง ถึงแม้การตั้งค่า client-server จะเริ่มปรากฏขึ้น แต่สมมติฐานเริ่มต้นในบริษัทใหญ่คือระบบต้องเชื่อถือได้ ตรวจสอบได้ และได้รับการซัพพอร์ตเป็นปี
สภาพแวดล้อมแบบนี้ให้รางวัลแก่ซอฟต์แวร์ที่สามารถกลายเป็นมาตรฐานที่ทีมไอทีสามารถสร้างขึ้นรอบๆ ได้ ฐานข้อมูลจึงเหมาะอย่างยิ่ง: มันอยู่ใต้แอปหลายตัว สัมผัสข้อมูลสำคัญ และทำให้การบำรุงรักษาและการซัพพอร์ตต่อเนื่องมีเหตุผล
ลูกค้าองค์กรไม่ได้ซื้อแบบบุคคล พวกเขาซื้อผ่านคณะกรรมการ กระบวนการจัดหา และแผนหลายปี นั่นผลักดันให้ผู้ขายเน้น:
มันยังเปลี่ยนโปรไฟล์ทางการเงิน ข้อตกลงขนาดใหญ่เพียงครั้งเดียวสามารถสนับสนุนงานพัฒนาผลิตภัณฑ์เป็นปี แต่ต้องการการขายที่สร้างขึ้นรอบความสัมพันธ์ หลักฐาน และการลดความเสี่ยง
เดิมพันตั้งแต่ต้นของ Oracle ตรงไปตรงมา: หาให้ได้ที่ตั้งในแกนกลางของการปฏิบัติงานองค์กร แล้วคุณไม่ได้ขายแค่ซอฟต์แวร์—คุณขายความต่อเนื่องผ่านการอัปเดต การซัพพอร์ต และการอัปเกรดที่องค์กรจะจ่ายต่อเนื่องเมื่อการพึ่งพาเพิ่มขึ้น
ฐานข้อมูลคือ system of record ของบริษัท: ที่ซึ่ง "ความจริงอย่างเป็นทางการ" อยู่ บัญชีลูกค้า ใบแจ้งหนี้ ยอดสต็อก รายการเงินเดือน สถานะการจัดส่ง—สิ่งเหล่านี้ไม่ใช่แค่ไฟล์ แต่เป็นข้อเท็จจริงที่ธุรกิจพึ่งพาเพื่อเรียกเก็บเงิน ปฏิบัติตามข้อกำหนด และดำเนินงานทุกวัน
เมื่อองค์กรสร้างซอฟต์แวร์มากขึ้น—ERP, CRM, การเรียกเก็บเงิน, ห่วงโซ่อุปทาน—แอปเหล่านั้นยิ่งแชร์แหล่งความจริงเดียวกัน ถ้าฐานข้อมูลไม่พร้อมใช้งาน แอปที่อ่านและเขียนข้อมูลเหล่านั้นจะไม่ทำงาน นั่นทำให้ฐานข้อมูลกลายเป็นการพึ่งพาหลัก ไม่ใช่แค่องค์ประกอบไอทีอีกชิ้น
ฐานข้อมูลยึดติดเพราะแอปถูกเขียนรอบมัน เมื่อเวลาผ่านไปคุณจะสะสม:
การสลับไม่เหมือนการเปลี่ยนเครื่องมือสเปรดชีต คุณต้องย้ายปริมาณข้อมูลมหาศาล รักษาประวัติ ทดสอบการทำงานสำคัญใหม่ทั้งหมด และมักต้องเขียนส่วนของแอปใหม่ แม้ตัวเลือกใหม่จะถูกกว่า โครงการเสี่ยงอาจทับซ้อนการประหยัดได้
สำหรับระบบที่สำคัญ ความกลัวไม่ใช่แค่ "ช้ากว่านิดหน่อยในสัปดาห์นี้" แต่มันคือการหยุดทำงานที่หยุดการประมวลผลคำสั่งซื้อ หรือการสูญหายของข้อมูลที่บังคับให้ต้องกระทบยอด คืนเงิน และเรื่องกฎระเบียบ
เมื่อราคาของวันที่แย่อาจถึงล้านบาท—หรือทำลายความเชื่อมั่น—ผู้ซื้อจะระมัดระวัง "ทำงานได้เชื่อถือได้" ดีกว่า "ใหม่และมีแนวโน้มดี"
ฝ่ายไอทีถูกตัดสินจากความเสถียร นั่นผลักดันให้พวกเขาเลือกผู้ขายที่มีประวัติยาวนาน เครื่องมือครบ และทีมซัพพอร์ตที่เคยเห็นรูปแบบความล้มเหลวมาทุกแบบแล้ว
เมื่อการตัดสินใจนั้นเกิดขึ้น ฐานข้อมูลกลายเป็นสมอสำหรับสแต็กที่เหลือ—ดึงแอป กระบวนการ และงบประมาณเข้ามาในวงโคจรของมัน
ฐานข้อมูลเชิงสัมพันธ์คือวิธีเก็บข้อมูลธุรกิจ—ลูกค้า ใบแจ้งหนี้ การจัดส่ง—ในตาราง (คิดว่าคล้ายสเปรดชีต) ที่เชื่อมโยงกัน แทนการค้นหาในไฟล์ คุณถามคำถามเช่น "แสดงใบแจ้งหนี้ค้างชำระที่มากกว่า 30 วัน" และได้คำตอบอย่างรวดเร็วและสม่ำเสมอ
SQL (Structured Query Language) คือภาษาที่ใช้สื่อสารกับฐานข้อมูลเชิงสัมพันธ์ เพราะ SQL ถูกสอนอย่างกว้างและได้รับการสนับสนุนอย่างกว้างขวาง จึงง่ายที่จะสมมติว่าผลิตภัณฑ์ฐานข้อมูลแลกเปลี่ยนกันได้
แต่ในบริษัทจริง สิ่งที่สำคัญไม่ใช่ว่าระบบจะเข้าใจ SQL หรือไม่ ความแตกต่างอยู่รอบๆ มัน: ฐานข้อมูลทำงานได้อย่างไรภายใต้ภาระหนัก ฟื้นตัวอย่างไรหลังจากล้มเหลว การสำรองทำงานอย่างไร การจัดการสิทธิ์ และทีมมอนิเตอร์จูนประสิทธิภาพอย่างไร
Oracle ไม่ได้ขายแค่ "SQL" Oracle ขายสัญญาว่าระบบสำคัญจะยังทำงานต่อไป
แม้คู่แข่งจะจับคู่ฟีเจอร์ได้ การตัดสินใจมาตรฐานฐานข้อมูลแพร่ไปทั่วทีม งบประมาณ และนิสัยการปฏิบัติงานหลายปี เมื่อฐานข้อมูลกลายเป็นศูนย์กลางของการรายงาน การผสาน และการปฏิบัติตาม เทคโนโลยีที่ "พอใช้" มักไม่เพียงพอที่จะชนะ
ความได้เปรียบของตลาดมักสะท้อนการผสมผสานของคุณภาพผลิตภัณฑ์ การจัดการความเสี่ยง และการปฏิบัติการการขาย—ไม่ใช่แค่ฟีเจอร์เดียวที่เลิศเลอ
Oracle ไม่ได้ชนะโดยรอให้ผู้พัฒนาจ่ายบัตรเครดิต มันเรียนรู้ว่าบริษัทใหญ่ซื้ออย่างไร: ช้า รอบคอบ และมีหลายคนเกี่ยวข้อง
การจัดซื้อขององค์กรเป็นกีฬาประเภททีม ดีลทั่วไปดึงผู้นำไอที ความปลอดภัย การเงิน ฝ่ายกฎหมาย และหน่วยธุรกิจที่เป็นเจ้าของระบบเข้ามา นั่นหมายถึงไทม์ไลน์ยาว ความต้องการอย่างเป็นทางการ และการเมืองภายใน
Oracle ใช้ประโยชน์จากความจริงนี้ด้วย proofs of concept (PoCs), ลูกค้าอ้างอิง และคำยืนยันความเข้ากันได้ PoC ไม่ใช่แค่การทดสอบเชิงเทคนิค แต่มันคือวิธีช่วยผู้สนับสนุนชี้แจงเหตุผลให้คนอื่นในห้องเห็นด้วย
Oracle สร้างการขายแบบบัญชี: พนักงานประจำบัญชี บัญชีที่ระบุชื่อ และจังหวะการทบทวนธุรกิจไตรมาสต่อไตรมาส ก่อนที่คำว่า "ABM" จะเป็นกระแส
เป้าหมายไม่ใช่แค่สัญญาแรก แต่มันคือการเป็นตัวเลือกฐานข้อมูลเริ่มต้นสำหรับโครงการต่อๆ ไป ความไว้วางใจกับ CIO หรือทีม DBA อาจคงอยู่ยาวกว่างบประมาณ การปรับองค์กร หรือแม้แต่ความไม่พอใจระยะสั้นต่อผลิตภัณฑ์
สัญญาซัพพอร์ต การรับรอง (DBAs, นักพัฒนา) และ systems integrators สร้างโมเมนตัม เมื่อลูกค้ามีพนักงานที่ฝึกแล้ว สถาปัตยกรรมที่ผ่านการอนุมัติ และพาร์ทเนอร์ที่รู้ Oracle ลึก การเปลี่ยนผู้ขายรู้สึกเหมือนเพิ่มความเสี่ยง
พาร์ทเนอร์ยังมีอิทธิพลต่อสิ่งที่แนะนำใน RFP ทักษะที่มี และแพลตฟอร์มที่ถือว่า "ปลอดภัย"
การต่ออายุอาจสำคัญกว่าการได้ลูกค้าใหม่ หาก Oracle ถูกฝังอยู่ในระบบหลัก การต่ออายุประจำปีกลายเป็นการตัดสินใจด้านความต่อเนื่องทางธุรกิจ ไม่ใช่การซื้อใหม่ ซึ่งเป็นเวลาที่ราคา ข้อคลอมนิยมการตรวจสอบ และโครงสร้างสัญญาเริ่มกำหนดพฤติกรรมเท่าๆ กับฟีเจอร์ผลิตภัณฑ์
(สำหรับกลไกของเลเวอเรจนี้ ดูโพสต์เกี่ยวกับกลไกของการล็อกอิน.)
การผูกมัดกับผู้ขายไม่จำเป็นต้องมีเจตนาร้าย มันคือการที่การพึ่งพาผลิตภัณฑ์ของผู้ขายเพิ่มขึ้น ควบคู่กับต้นทุนการสลับที่เพิ่มขึ้น เมื่อระบบแกนกลางอย่างฐานข้อมูลอยู่ใต้แอป รายงาน ความปลอดภัย และการปฏิบัติการประจำวัน การรวมกันนี้สามารถทรงพลัง
เกิดขึ้นเมื่อระบบของคุณพึ่งพาความสามารถที่ไม่สามารถทำซ้ำได้ง่ายที่อื่น ในฐานข้อมูล มักปรากฏเป็นฟีเจอร์กรรมสิทธิ์ (ส่วนขยาย SQL เฉพาะ การให้คำแนะนำสมรรถนะ วิธีการคลัสเตอร์เฉพาะผู้ขาย), เครื่องมือของผู้ขาย และการผสานลึกกับแอปและมิดเดิลแวร์
แม้เมื่อ "มันเป็นแค่ SQL" การติดตั้งใช้งานจริงจะสะสม stored procedures, triggers, สคริปต์สำรองข้อมูล เอเจนต์มอนิเตอร์ และคอนเน็กเตอร์ที่กำหนดเอง ยิ่งสแตกนั้นจูนเข้ากับฐานข้อมูลหนึ่งมากเท่าไร การย้ายสะอาดก็ยากขึ้นเท่านั้น
เกี่ยวกับคนและกระบวนการ ทีมฝึกบนแพลตฟอร์มเฉพาะ จ้างผู้ดูแลที่มีเส้นทางการรับรองเฉพาะ และสร้าง runbooks รอบพฤติกรรมเฉพาะ—เช่นวิธี failover วิธีอัปเกรด และรูปลักษณ์ของประสิทธิภาพปกติ
เมื่อเวลาผ่านไป เอกสารการปฏิบัติตามและการตรวจสอบก็กลายเป็นเฉพาะฐานข้อมูล: การควบคุมการเข้าถึง การตั้งค่าการเข้ารหัส นโยบายการเก็บรักษา และขั้นตอนตอบสนองเหตุการณ์ การเปลี่ยนผู้ขายจึงหมายถึงการฝึกซ้ำ เขียนกระบวนการใหม่ และยืนยันการควบคุมอีกครั้ง
การผูกมัดเชิงสัญญาทำให้ต้นทุนการสลับกลายเป็นความเป็นจริงตามปฏิทิน — ระยะสัญญาหลายปี โครงสร้างซัพพอร์ตแบบรวม วงจรการต่ออายุ และข้อตกลงทั่วทั้งองค์กรสามารถทำให้การเปลี่ยนในไตรมาหนึ่งเป็นไปไม่ได้
การซัพพอร์ตเป็นคันโยกใหญ่: เมื่อระบบสำคัญพึ่งพาการซัพพอร์ตจากผู้ขายเพื่อแพตช์และคำแนะนำด้านความปลอดภัย การเดินออกอาจรู้สึกเหมือนรับความเสี่ยงปฏิบัติการใหม่—โดยเฉพาะถ้าสัญญาระบุคำนิยามการใช้งานและบทลงโทษที่ซับซ้อนสำหรับการย้ายบางส่วน
คู่อุปสรรคของ Oracle มิได้อยู่แค่เชิงเทคนิค แต่ยังเป็นการเงิน—สร้างผ่านรูปแบบไลเซนส์ที่ทำให้ฐานข้อมูลดูฝังอยู่ในงบประมาณเท่ากับในระบบ
ไลเซนส์ของ Oracle มักขายตามหน่วยที่พบได้ทั่วไป:
แนวคิดหลักง่ายๆ คือ: เมื่อฐานข้อมูลกลายเป็นศูนย์กลาง การเติบโตมักจะเพิ่มหนึ่งในมาตรวัดเหล่านี้—คอร์เพิ่ม ผู้ใช้เพิ่ม หรือฟีเจอร์เพิ่ม
เมื่อการตั้งราคามีลูกบิดหลายตัว—เมตริก ข้อยกเว้น สิทธิการใช้งานผลิตภัณฑ์ ตัวเลือกแบบรวม—การเจรจามักเอียงไปหาฝ่ายที่เข้าใจกฎดีกว่า
ความซับซ้อนยังทำให้ลูกค้ายากต่อการจำลองต้นทุนรวมในหลายปี ซึ่งทำให้การเปรียบเทียบทางเลือกหรือการตัดสินใจย้ายเป็นเรื่องยากขึ้น
Oracle (เช่นผู้ขายใหญ่หลายราย) ใช้การตรวจสอบไลเซนส์เพื่อยืนยันว่าลูกค้าใช้ซอฟต์แวร์ตามข้อตกลง หากทำอย่างเป็นกลาง การตรวจสอบสามารถปกป้องทั้งสองฝ่ายได้
ในทางปฏิบัติ การตรวจสอบยังสร้างความเสี่ยงทางการเงิน: หากการใช้งานถูกตีความว่าเกินขอบเขต ลูกค้าอาจต้องจ่ายเพิ่มอย่างรวดเร็ว
การต่ออายุซัพพอร์ตประจำปี—มักผูกกับเปอร์เซ็นต์ของไลเซนส์—สร้างรายได้สม่ำเสมอแม้ว่าการขายใหม่จะชะลอ การอัปเกรดและ edition ใหม่กลายเป็นคันโยกที่สอง: ลูกค้าจ่ายเพื่อให้ทันสมัย เข้ากันได้ และได้รับการซัพพอร์ต ซึ่งเสริมวงจรการเกิดรายได้ต่อเนื่อง
"ยั่งยืน" หมายความว่าธุรกิจถูกจัดโครงสร้างให้รายได้เกิดซ้ำได้อย่างเชื่อถือได้—แม้ลูกค้าอาจไม่พึงพอใจทุกรายการก็ตาม
ในกรณีของ Oracle ความยั่งยืนเกิดจาก:
เพราะฐานข้อมูลอยู่ใต้ระบบที่ทำให้ธุรกิจเดินได้: การเรียกเก็บเงิน เงินเดือน สต็อก การเทรด และรายงานด้านการปฏิบัติตามข้อกำหนด
เมื่อฐานข้อมูลเป็น ระบบของบันทึกอย่างเป็นทางการ การเสียหายหรือการสูญหายของข้อมูลทำให้เกิดความเสี่ยงทางปฏิบัติการและกฎระเบียบ ดังนั้นผู้ซื้อจึงให้ความสำคัญกับความเสถียรและการซัพพอร์ตที่พิสูจน์ได้มากกว่านวัตกรรมใหม่ๆ
ไม่ใช่ทั้งหมด SQL เป็นมาตรฐาน แต่องค์กรไม่ได้ซื้อแค่ "ไวยากรณ์" พวกเขาซื้อผลลัพธ์: เวลาทำงาน (uptime), การกู้คืน, ประสิทธิภาพภายใต้ภาระงาน, การควบคุมความปลอดภัย, เครื่องมือและการซัพพอร์ต
สองผลิตภัณฑ์อาจ "พูด SQL" ได้แต่ยังแตกต่างอย่างมากใน:
ต้นทุนการสลับค่อยๆ เพิ่มขึ้นตามเวลา
แหล่งทั่วไปได้แก่:
แม้ทางเลือกจะถูกกว่า ความเสี่ยงโครงการย้ายข้อมูลอาจมากกว่าการประหยัด
Oracle ขายให้คณะกรรมการตัดสินใจ ไม่ใช่บุคคลคนเดียว แล้วดูแลลูกค้าเป็นความสัมพันธ์ระยะยาว
ยุทธศาสตร์ทั่วไปได้แก่:
มักเป็นจุดที่อำนาจต่อรองสูงสุด
เมื่อฐานข้อมูลรองรับการปฏิบัติงานหลัก การต่ออายุกลายเป็นการตัดสินใจเรื่อง ความต่อเนื่องทางธุรกิจ ไม่ใช่การประเมินใหม่ทั้งหมด นั่นเปลี่ยนบทสนทนาจาก "ควรซื้อไหม" เป็น "สามารถเปลี่ยนได้อย่างปลอดภัยหรือไม่"—ซึ่งทำได้ยากกว่า
ตรงจุดนี้ข้อกำหนดด้านราคา ข้อคลอมนิยมการตรวจสอบ และนโยบายซัพพอร์ตมีผลมาก
ชั้นล็อกอินสามแบบมักเสริมซึ่งกันและกัน:
ชั้นเหล่านี้รวมกันทำให้การย้ายออกมีต้นทุนสูงขึ้นทั้งทางเทคนิค ปฏิบัติการ และกฎหมาย
สัญญาไลเซนส์ของ Oracle มักมีหลายตัวชี้วัดและการเติบโตมักเพิ่มหนึ่งในตัวชี้วัดเหล่านั้น
คันโยกที่พบบ่อยได้แก่:
ความซับซ้อนทำให้คาดการณ์ต้นทุนรวมได้ยากขึ้น และง่ายต่อการเลื่อนออกจากความสอดคล้องโดยไม่ตั้งใจ
การตรวจสอบไลเซนส์เป็นการตรวจสอบว่าการใช้งานตรงตามข้อตกลงหรือไม่
ในทางปฏิบัติอาจสร้าง:
ทีมลดความเสี่ยงโดยติดตามการปรับใช้ เข้าใจคำนิยามของเมตริก (virtualization, DR, dev/test) และเก็บรายงานการใช้งานภายในให้ชัดเจน
ไม่โดยอัตโนมัติ—คลาวด์เปลี่ยนรูปร่างของการล็อกอินแต่ไม่ทำลายมัน
ฐานข้อมูลที่บริหารจัดการช่วยลดภาระปฏิบัติการ (patching, backups, HA) แต่ยังต้องระวัง:
องค์กรขนาดใหญ่ส่วนมากอยู่ในสภาวะไฮบริดเป็นเวลาหลายปี ผสมผสานการใช้งานบนออน-พรีมและคลาวด์
