ความลับสกปรกของการค้าขายหัวขาด: สิ่งที่ผู้ขายบางรายไม่จงใจพูด

ความลับสกปรกของโซลูชันการค้าที่ไม่มีหัว: สิ่งที่ผู้ขายบางราย (โดยเจตนา) ไม่บอกคุณอาจทำให้คุณต้องเสียค่าใช้จ่ายครั้งใหญ่

การค้าขายหัวขาด—หรือเรียกง่ายๆ ว่า “หัวขาด”—เป็นที่รักของโลก B2C ในตอนนี้ ตาม Google Trends คำขอค้นหาการค้าหัวขาดได้เพิ่มขึ้นอย่างมากตั้งแต่ต้นปี 2020 จากมุมมองของอีคอมเมิร์ซ เข้าใจได้ง่ายว่าทำไม

ผู้บริโภคถูกกักบริเวณในบ้าน โดยถูกผูกไว้กับฟีดโซเชียลมีเดียในช่วงการระบาดใหญ่ แบรนด์โดยตรงต่อผู้บริโภคสามารถใช้ประโยชน์จากสื่อเช่น Instagram, TikTok หรือ Facebook และนำสินค้าของตนไปสู่กลุ่มเป้าหมายโดยตรง โซลูชั่นการค้าหัวขาดเป็นเกมง่ายๆ

สถาปัตยกรรมหัวขาดมีความยืดหยุ่นสูง เนื่องจากการแยกส่วนฟรอนต์เอนด์และแบ็กเอนด์ (และความพร้อมใช้งานของ API) มันง่ายกว่ามากสำหรับองค์กรที่ต้องการปรับใช้การค้าบนช่องทางใหม่ ให้ทำด้วยแพลตฟอร์มที่รองรับหัวขาด

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

โซลูชั่นการค้าหัวขาด: ตัดผ่านโฆษณา

แต่การค้าขายหัวขาดคืออะไรกันแน่? ตามปกติแล้วในโลกของเทคโนโลยีและการตลาด มีแนวโน้มที่จะยึดติดกับคำศัพท์ล่าสุด — ลองนึกย้อนกลับไปที่ข้อมูลขนาดใหญ่หรือปัญญาประดิษฐ์/แมชชีนเลิร์นนิงเมื่อสองสามปีก่อน — และใส่เข้าไปในบทสนทนาให้ได้มากที่สุด .

เมื่อผู้คนไม่สามารถกำหนดได้จริงๆ ว่าสิ่งของคืออะไร แต่น่านน้ำรอบๆ สิ่งนั้นมักจะขุ่นมัว นั่นคือสิ่งที่เกิดขึ้นกับการค้าขายหัวขาด

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

พูดง่ายๆ การค้าหัวขาดหมายถึง:

1. ส่วนหน้า/หน้าร้าน/กระจกแยกออกจากกลไกการค้า (เช่น ส่วนหลัง)
2. เนื่องจากแยกจากกัน จึงใช้ความสามารถแบ็กเอนด์ เช่น การกำหนดราคาและโปรโมชันผ่านการเรียก API
3. ดังนั้น ตามคำนิยาม สำหรับแพลตฟอร์มการค้าเพื่อรองรับการปรับใช้แบบไม่มีส่วนหัว จำเป็นต้องมีการครอบคลุม API ของฟังก์ชันแบ็กเอนด์การค้า

มาดูกันดีกว่าว่าหัวขาดคืออะไร (และไม่ใช่อะไร) มันมาจากไหน และเพื่อใคร

การค้าหัวขาดไม่ใช่เรื่องใหม่

แม้ว่าคำศัพท์ดังกล่าวอาจเพิ่งเริ่มต้นขึ้นในช่วงสองสามปีที่ผ่านมา แต่แนวคิดเรื่อง headless ก็ไม่ใช่เรื่องใหม่ ดังที่กล่าวไว้ข้างต้น นี่เป็นแนวทางแรกสำหรับ API ที่ส่วนหน้า/เลเยอร์การนำเสนอ/แก้วถูกแยกออกจากแกนกลาง (โดยใช้ API)

ตัวอย่างเช่น ที่ SAP (และเดิมคือ Hybris) เราได้เปิดใช้งานความสามารถทางการค้าผ่านเลเยอร์ Restful API (การเชื่อมต่อ Omni-Commerce) มานานกว่าทศวรรษ ประมาณครึ่งหนึ่งของลูกค้ากว่า 3,500 รายที่ใช้ SAP Commerce (ในองค์กรและในระบบคลาวด์) ดำเนินการในลักษณะที่ไม่มีหัวเรื่องด้วย CMS บุคคลที่สามหรือหน้าร้านที่แยกส่วนกันตามสั่ง

ประเด็นคือ อย่าหลงกลโดยฉวัดเฉวียน หัวขาดไม่ได้เพิ่งโผล่เข้ามาในที่เกิดเหตุ

โซลูชันการค้าหัวขาดล้วนไม่ใช่สำหรับทุกคน

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

แต่นั่นไม่ใช่ทั้งหมด พวกเขาต้องการวุฒิภาวะด้านไอทีและความสามารถในการพัฒนา เนื่องจากต้องสร้างเลเยอร์การนำเสนอ/หน้าร้านตามสั่งทั้งหมดตั้งแต่เริ่มต้นโดยใช้เฟรมเวิร์กและไลบรารีส่วนหน้า (เช่น Angular/React/Vue) หรือผ่านโซลูชันของพาร์ทเนอร์อย่างน้อยที่สุด โดยทั่วไปส่วนหน้าที่กำหนดเองเหล่านี้ไม่รองรับผู้ขาย

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

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

หัวขาดไม่เท่ากับไมโครเซอร์วิส

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

ไม่ Microservices ไม่เทียบเท่ากับ API และไม่ (ฉันกำลังจะใช้เสียง "ภายนอก" ของฉันที่นี่) สถาปัตยกรรมแบบ MICROSERVICE-Based ไม่ใช่ข้อกำหนดเบื้องต้นสำหรับการไม่มีหัว (ในทางกลับกัน API เป็น)

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

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

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

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

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

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

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

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

หัวขาดอยู่ที่นี่เพื่ออยู่

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

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

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

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