TechCut — Technical Case Study · OneSiam Super App Project
E-commerce ส่วนใหญ่ถูกออกแบบมาเพื่อโจทย์ที่ค่อนข้างตรงไปตรงมา
ลูกค้าเลือกสินค้า → ระบบสร้าง Order → ร้านค้าหรือคลังสินค้าเตรียมของ → จัดส่งให้ลูกค้า
แต่เมื่อโจทย์เปลี่ยนจาก “ร้านค้าออนไลน์หนึ่งร้าน” เป็น “ศูนย์การค้าที่มีหลายแบรนด์ หลายระบบ และหลายรูปแบบการให้บริการ” ความซับซ้อนจะเพิ่มขึ้นทันที
ลองนึกภาพ Order หนึ่งใบที่มีสินค้าจากหลายร้านในศูนย์การค้าเดียวกัน
- สินค้าแต่ละชิ้นอาจมาจากคนละแบรนด์
- แต่ละร้านมีสต็อกของตัวเอง มีทีมปฏิบัติการของตัวเอง
- มีเงื่อนไขส่วนลดของตัวเอง และอาจมีระบบหลังบ้านที่ต่างกัน
แต่ในมุมลูกค้า สิ่งที่ควรเกิดขึ้นคือประสบการณ์ที่เรียบง่าย: เลือกสินค้า จ่ายเงินครั้งเดียว แล้วได้รับประสบการณ์ที่ต่อเนื่องเหมือนเป็น Order เดียว
นี่คือโจทย์ทางเทคนิคที่อยู่เบื้องหลัง OneSiam Super App
ความยากของโปรเจกต์นี้ ไม่ใช่การทำหน้าร้านออนไลน์
ถ้ามองจากด้านหน้า OneSiam Super App อาจดูเหมือน E-commerce ที่ลูกค้าสามารถเลือกซื้อสินค้า ใช้สิทธิพิเศษ และติดตามบริการต่าง ๆ ได้
แต่ความยากจริงอยู่ด้านหลัง
เพราะระบบไม่ได้ต้องรองรับแค่สินค้าและตะกร้าสินค้าเท่านั้น แต่ต้องรองรับ Ecosystem ที่มีหลายฝ่ายทำงานร่วมกัน เช่น ลูกค้าที่ใช้งานแอป, ร้านค้าและแบรนด์ต่าง ๆ, ทีมปฏิบัติการภายในศูนย์การค้า, ระบบสมาชิกและสิทธิประโยชน์, ระบบชำระเงิน, ระบบจอดรถ, ระบบพาร์ทเนอร์ภายนอก และระบบหลังบ้านเดิมขององค์กร
ดังนั้นโจทย์ของ OneSiam Super App จึงไม่ใช่แค่การสร้าง E-commerce แต่คือการสร้าง Commerce Orchestration Platform ที่ทำให้หลายระบบ หลายร้าน และหลาย Journey ทำงานร่วมกันได้
Multi-Tenant Commerce: เมื่อแต่ละร้านคือระบบย่อยของตัวเอง
หนึ่งในหัวใจสำคัญของระบบนี้คือแนวคิด Multi-Tenant Commerce
ใน E-commerce ทั่วไป ร้านค้าอาจเป็นเจ้าของระบบเดียว มีคลังเดียว และมี workflow เดียว แต่สำหรับศูนย์การค้า ร้านค้าแต่ละรายมีความเป็นอิสระของตัวเอง ทั้งในแง่สต็อก ราคา โปรโมชั่น วิธีการจัดการสินค้า และเงื่อนไขทางธุรกิจ
ดังนั้นระบบต้องสามารถรองรับร้านค้าหลายรายในแพลตฟอร์มเดียว โดยที่แต่ละร้านยังสามารถมี logic ของตัวเองได้
สิ่งที่ระบบต้องจัดการ เช่น
- แยกสินค้าและคำสั่งซื้อออกตามร้านค้า
- รองรับสถานะของแต่ละร้านแยกจากกัน
- จัดการข้อมูลสินค้า ราคา และสต็อก
- รองรับส่วนลดหรือโปรโมชั่นที่อาจมีเงื่อนไขแตกต่างกัน
- รวมประสบการณ์ทั้งหมดกลับมาให้ลูกค้าเห็นเป็น Journey เดียว
นี่คือความต่างระหว่างการสร้าง Online Store กับการสร้าง Marketplace หรือ Ecosystem Platform
Online Store มองสินค้าเป็นรายการขาย — Ecosystem Platform ต้องมองร้านค้าแต่ละรายเป็น Tenant ที่มี business logic ของตัวเอง
Order Splitting: ความซับซ้อนที่ลูกค้าไม่ควรต้องเห็น
หนึ่งใน logic สำคัญของระบบคือ Order Splitting
ในมุมลูกค้า การซื้อสินค้าหลายร้านควรรู้สึกเหมือนเป็น Order เดียว แต่ในมุมระบบ Order นั้นอาจต้องถูกแยกออกเป็นหลายส่วน เพื่อให้แต่ละร้านสามารถจัดการสินค้าของตัวเองได้อย่างถูกต้อง
เมื่อมี Order ที่ประกอบด้วยสินค้าจากหลายร้าน ระบบต้องสามารถ
- แยก Order ตามร้านค้าที่เกี่ยวข้อง
- ส่งข้อมูลไปยังร้านค้าหรือทีมปฏิบัติการที่รับผิดชอบ
- ติดตามสถานะของแต่ละส่วนแยกกัน
- รวมสถานะกลับมาให้ลูกค้าเข้าใจง่าย
- จัดการกรณีบางรายการถูกยกเลิก เปลี่ยนแปลง หรือคืนเงิน โดยไม่กระทบทั้ง Order
ระบบที่ดีจึงต้องซ่อนความซับซ้อนของ operation ไว้ด้านหลัง และแสดงผลออกมาเป็นประสบการณ์ที่เรียบง่ายที่สุด
Fulfillment ในห้าง ไม่เหมือน Fulfillment ในคลังสินค้า
อีกหนึ่งความแตกต่างสำคัญคือเรื่อง Fulfillment
E-commerce ทั่วไปมักถูกออกแบบโดยมีคลังสินค้าเป็นศูนย์กลาง แต่ในกรณีของศูนย์การค้า สินค้าอาจกระจายอยู่ตามร้านค้าต่าง ๆ ในพื้นที่จริง
นั่นทำให้ fulfillment ไม่ได้เกิดขึ้นใน warehouse ที่มี shelf location ชัดเจนเสมอไป แต่เกิดขึ้นในพื้นที่จริงของศูนย์การค้า
ระบบจึงต้องรองรับ workflow ที่ซับซ้อนกว่า เช่น รับคำสั่งซื้อจากหลายร้าน, สร้างรายการสินค้าที่ต้องไปรับจากแต่ละจุด, ติดตามสถานะการเตรียมสินค้า, รองรับกรณีสินค้าบางรายการไม่พร้อม, รวมสินค้าเข้าด้วยกันก่อนส่งมอบหรือจัดส่ง และแจ้งสถานะให้ลูกค้าเห็นอย่างต่อเนื่อง
นี่คือจุดที่ Technical Architecture ต้องเข้าใจ Operation จริง เพราะถ้าออกแบบระบบจากมุม E-commerce อย่างเดียว อาจได้ flow ที่ดูถูกต้องบนหน้าจอ แต่ใช้งานจริงยากสำหรับทีมที่ต้องเดินงานในพื้นที่จริง
Integration Layer: จุดที่ทำให้ Super App ใช้งานได้จริง
Super App ไม่ได้มีคุณค่าจากจำนวนฟีเจอร์เพียงอย่างเดียว คุณค่าจริงเกิดขึ้นเมื่อฟีเจอร์เหล่านั้นเชื่อมกับระบบจริงขององค์กรและพาร์ทเนอร์ได้
ใน OneSiam Super App ระบบต้องเชื่อมต่อกับหลายส่วน เช่น ระบบสมาชิกและสิทธิประโยชน์, ระบบชำระเงิน, ระบบคะแนนสะสม, ระบบบริการภายในศูนย์การค้า, ระบบร้านค้าและข้อมูลสินค้า และระบบพาร์ทเนอร์ภายนอก
ความท้าทายของ integration ไม่ได้อยู่ที่การเรียก API ได้หรือไม่ได้เท่านั้น แต่อยู่ที่การทำให้ระบบที่มีรูปแบบข้อมูล ความเร็วในการ sync และข้อจำกัดต่างกัน สามารถทำงานร่วมกันได้โดยไม่ทำให้ประสบการณ์ของผู้ใช้สะดุด
- บางระบบอาจเป็น real-time
- บางระบบอาจเป็น batch
- บางระบบมีข้อจำกัดด้านข้อมูล
- บางระบบมี business rule เฉพาะของตัวเอง
ดังนั้น Integration Layer จึงต้องทำหน้าที่มากกว่า “ตัวเชื่อม API” มันต้องเป็นชั้นที่ช่วยแปลข้อมูล จัดการข้อผิดพลาด ควบคุม flow และทำให้หลายระบบสามารถทำงานร่วมกันเป็นประสบการณ์เดียวได้
Financial Logic: ส่วนที่ผู้ใช้ไม่เห็น แต่ผิดพลาดไม่ได้
ในระบบที่มีหลายร้านค้าและหลายเงื่อนไขทางธุรกิจ เรื่องการเงินเป็นอีกส่วนที่ซับซ้อนมาก
เมื่อลูกค้าจ่ายเงินหนึ่งครั้ง ระบบหลังบ้านอาจต้องคำนวณหลายเรื่องพร้อมกัน เช่น รายได้ของแต่ละร้านค้า, ส่วนลดที่มาจากหลายแหล่ง, สิทธิประโยชน์หรือคะแนนที่ถูกใช้, การคืนเงินบางรายการ, การจัดการคำสั่งซื้อที่ถูกยกเลิกบางส่วน และข้อมูลที่ต้องใช้สำหรับการสรุปยอดภายหลัง
ความยากของ financial logic คือมันไม่ได้เป็นแค่การคำนวณตัวเลข แต่มันคือการทำให้ทุกฝ่ายใน ecosystem เห็นข้อมูลที่ถูกต้อง สอดคล้องกัน และตรวจสอบย้อนหลังได้
นี่คือส่วนที่ลูกค้าอาจไม่เคยเห็น แต่เป็นหัวใจสำคัญของความน่าเชื่อถือของแพลตฟอร์ม
Engagement Feature: ฟีเจอร์เล็กที่ช่วยให้แอปไม่ใช่แค่ที่ซื้อของ
Commerce Platform ที่ดีไม่ควรทำงานเฉพาะตอนลูกค้าต้องการซื้อของเท่านั้น เพราะถ้าแอปถูกใช้งานเฉพาะตอน transaction โอกาสที่ลูกค้าจะกลับมาใช้งานซ้ำก็จะขึ้นอยู่กับความต้องการซื้อในช่วงเวลานั้นเท่านั้น
ใน OneSiam Super App จึงมีฟีเจอร์ที่ช่วยขยายบทบาทของแอปออกไปมากกว่าการซื้อสินค้า เช่น
- การบันทึกสินค้าที่สนใจ
- การแจ้งเตือนเมื่อสินค้าหรือสิทธิประโยชน์ที่เกี่ยวข้องกลับมา
- คอนเทนต์ที่เชื่อมกับไลฟ์สไตล์ของลูกค้า
- สิทธิพิเศษและแคมเปญที่ช่วยกระตุ้นการกลับมาใช้งาน
ฟีเจอร์เหล่านี้อาจดูเล็กเมื่อเทียบกับระบบ commerce หลัก แต่ในเชิง product มันช่วยเปลี่ยนแอปจาก Transaction Tool ให้กลายเป็น Engagement Platform และนี่คือจุดที่เทคโนโลยีเริ่มเชื่อมกับพฤติกรรมผู้ใช้จริง
Infrastructure ที่ต้องรองรับ Load ไม่สม่ำเสมอ
Commerce Platform ไม่ได้มี traffic เท่ากันทุกวัน บางช่วงอาจมีผู้ใช้งานเพิ่มขึ้นจากแคมเปญ โปรโมชั่น กิจกรรม หรือช่วงเวลาพิเศษ
ดังนั้นระบบต้องถูกออกแบบให้รองรับ load ที่ไม่สม่ำเสมอได้ โดยไม่ต้อง over-provision เกินความจำเป็นตลอดเวลา
แนวคิดที่สำคัญในระบบลักษณะนี้คือ รองรับการ scale เมื่อ traffic เพิ่มขึ้น, deploy ได้อย่างปลอดภัยและตรวจสอบได้, มี process สำหรับ rollback เมื่อเกิดปัญหา, ทดสอบ load ก่อนเปิดใช้งานจริง และมีการดูแลด้าน security และ data privacy ตามมาตรฐานองค์กร
สิ่งเหล่านี้อาจไม่ใช่ฟีเจอร์ที่ผู้ใช้มองเห็น แต่เป็นรากฐานที่ทำให้แพลตฟอร์มสามารถใช้งานจริงในระดับ enterprise ได้
Build แล้วไม่จบ: Platform ต้องมีวงจรดูแลและต่อยอด
Digital Platform ที่มี ecosystem ซับซ้อนไม่ใช่สิ่งที่ build เสร็จแล้วจบ หลังจากเปิดใช้งานจริง ระบบยังต้องถูกดูแล ปรับปรุง และต่อยอดอย่างต่อเนื่อง
เพราะเมื่อแพลตฟอร์มเริ่มถูกใช้งานจริง จะมีสิ่งใหม่เกิดขึ้นเสมอ เช่น operational issue ที่ไม่เคยเห็นตอนออกแบบ, request ใหม่จากทีมธุรกิจ, campaign ใหม่ที่ต้องตั้งค่า, integration ใหม่ที่ต้องเชื่อมเพิ่ม, performance หรือ usability ที่ต้องปรับ และ insight จากพฤติกรรมผู้ใช้จริง
นี่คือเหตุผลที่งาน platform ไม่ควรถูกมองเป็น project ส่งมอบครั้งเดียว แต่ควรถูกมองเป็น product ที่ต้องเติบโตต่อเนื่อง
สำหรับ Muze บทบาทของ Tech Partner จึงไม่ใช่แค่การ build ระบบให้เสร็จ แต่คือการช่วยให้องค์กรสามารถดูแล ปรับปรุง และต่อยอดแพลตฟอร์มให้ตอบโจทย์ธุรกิจจริงในระยะยาว
5 บทเรียนทางเทคนิคจาก OneSiam Super App
1. E-commerce สำหรับ Ecosystem ต้องคิดเป็น Orchestration ไม่ใช่แค่ Transaction
ถ้าระบบมีหลายร้าน หลายพาร์ทเนอร์ หลายสิทธิประโยชน์ และหลาย workflow การคิดแบบ transaction อย่างเดียวไม่พอ แพลตฟอร์มต้องสามารถ orchestrate หลายระบบให้ทำงานร่วมกันได้ นี่คือความต่างระหว่างการ “รับ order” กับการ “บริหาร order journey ทั้งระบบ”
2. Complexity ที่ดี คือ Complexity ที่ผู้ใช้ไม่ต้องเห็น
ระบบหลังบ้านอาจซับซ้อนมาก ทั้ง order splitting, fulfillment, integration, reconciliation และ exception handling แต่ในมุมผู้ใช้ ประสบการณ์ควรเรียบง่ายที่สุด หน้าที่ของแพลตฟอร์มคือการซ่อนความซับซ้อนไว้ด้านหลัง แล้วส่งมอบประสบการณ์ที่ลื่นไหลด้านหน้า
3. Physical Operation ต้องถูกออกแบบเข้าไปใน System ตั้งแต่แรก
ถ้าแพลตฟอร์มต้องเชื่อมกับพื้นที่จริง เช่น ศูนย์การค้า ร้านค้า หรือทีมปฏิบัติการ offline ระบบไม่สามารถออกแบบจากหน้าจออย่างเดียวได้ Digital Platform ที่เชื่อมกับ physical world จึงต้องออกแบบทั้ง software flow และ operation flow ไปพร้อมกัน
4. Integration Layer คือหัวใจของ Enterprise Platform
ในองค์กรขนาดใหญ่ ระบบใหม่แทบไม่เคยเริ่มจากศูนย์ มักต้องเชื่อมกับระบบเดิม พาร์ทเนอร์เดิม และ workflow เดิมที่มีข้อจำกัดอยู่แล้ว ดังนั้นความสามารถของแพลตฟอร์มจึงไม่ได้วัดจากฟีเจอร์ที่สร้างใหม่เท่านั้น แต่วัดจากความสามารถในการเชื่อมต่อกับ ecosystem ที่มีอยู่จริง
5. Technical Architecture ต้องรองรับการเติบโตของ Business Model
Super App และ Ecosystem Platform มักไม่ได้หยุดอยู่ที่ฟีเจอร์แรกที่เปิดตัว ดังนั้น architecture ที่ดีต้องไม่ใช่แค่รองรับ requirement วันนี้ แต่ต้องเปิดทางให้ธุรกิจสามารถต่อยอดได้ในวันข้างหน้า
สรุป: OneSiam Super App ไม่ใช่แค่ E-commerce แต่คือ Enterprise Commerce Platform
เบื้องหลัง OneSiam Super App คือโจทย์ทางเทคนิคที่ซับซ้อนกว่าการสร้างร้านค้าออนไลน์ทั่วไป เพราะระบบต้องรองรับทั้ง Multi-tenant commerce, Order splitting, Physical fulfillment, Loyalty และสิทธิประโยชน์, Integration กับระบบเดิมและพาร์ทเนอร์, Financial logic, Engagement feature, Infrastructure และ security ระดับองค์กร และการดูแลและต่อยอดหลัง launch
ความท้าทายของโปรเจกต์นี้จึงไม่ได้อยู่ที่การทำให้ลูกค้ากดซื้อสินค้าได้เท่านั้น แต่อยู่ที่การทำให้ Ecosystem ที่ซับซ้อนของศูนย์การค้า สามารถทำงานร่วมกันบน Digital Platform ได้จริง
สำหรับองค์กรที่กำลังสร้างแพลตฟอร์มของตัวเอง บทเรียนสำคัญคือ:
อย่ามอง Digital Platform เป็นแค่หน้าจอใหม่ของธุรกิจ แต่ให้มองเป็นระบบกลางที่เชื่อม Business Logic, Operation, Data, Integration และ Customer Experience เข้าด้วยกัน
เพราะแพลตฟอร์มที่ดีไม่ได้แค่ทำให้ธุรกิจ “ออนไลน์ได้” แต่ทำให้ธุรกิจสามารถขยาย Ecosystem ของตัวเองให้เติบโตต่อไปได้จริง