เราช่วยแยก Business Capabilities ออกจากระบบ ERP แบบ Monolith ทีละส่วนอย่างเป็นขั้นเป็นตอน โดยดำเนินการในสภาพแวดล้อมจริง (Production) โดยไม่กระทบต่อการเงิน คลังสินค้า หรือการปฏิบัติงาน และสามารถส่งมอบ Production API แรกได้ภายใน 8 สัปดาห์

เดิมที ERP ถูกออกแบบมาให้เป็นระบบบันทึกข้อมูลหลัก แต่กลับกลายเป็นระบบที่จำกัดการทำงาน

เริ่มจากการตั้งค่า (Configuration) ตามด้วยการปรับแต่ง (Customisation) และสะสม Business Logic มานานหลายปี จนฝังแน่นอยู่ในแพลตฟอร์มที่ไม่ได้ออกแบบมาเพื่อรองรับสิ่งเหล่านี้ ปัจจุบัน การปรับใช้กฎการกำหนดราคาใหม่ต้องอาศัยที่ปรึกษา SAP, การร้องขอการเปลี่ยนแปลง, รอบการทดสอบ และการรอคอยหลายสัปดาห์ การเชื่อมโยงระบบใหม่ส่งผลกระทบต่อ 15 โมดูล และการแก้ไขรายงานเพียงฉบับเดียวใช้เวลาถึง 3 วันทำการ

คำตอบไม่ใช่การเปลี่ยนระบบ ERP ทั้งหมด จากการวิจัยของ Panorama Consulting พบว่าโครงการเปลี่ยนระบบ ERP ขนาดใหญ่มักใช้งบประมาณเกินกว่า 50% และใช้เวลาหลายปีกว่าจะเห็นผลลัพธ์ที่คุ้มค่า ทางออกที่แท้จริงคือการหยุดเพิ่มสิ่งต่างๆ เข้าไปใน ERP และเริ่มดึงส่วนที่จำเป็นออกมา ย้าย Business Logic ไปยังบริการที่สร้างขึ้นมาโดยเฉพาะพร้อม API ที่ชัดเจน ให้ ERP ทำหน้าที่ที่ถนัดต่อไป เช่น บัญชีการเงิน, Master Data และการปฏิบัติตามกฎระเบียบ ในขณะที่ทุกสิ่งที่ต้องการความรวดเร็ว ความยืดหยุ่น หรือการเชื่อมโยงระบบ ควรอยู่นอกเหนือจาก ERP

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

เหตุผลทางธุรกิจ

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

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

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

ERP ยังคงอยู่ ข้อจำกัดต่างๆ จะหมดไป

แนวทางการทำงานร่วมกับเรา

คู่แข่งในตลาด DACH มักมองว่าการแยกส่วนระบบ ERP เป็นโครงการเปลี่ยนแปลงที่ใช้เวลาหลายปี ต้องใช้ทีมขนาดใหญ่ การค้นคว้าข้อมูลที่ยาวนาน และเห็นผลลัพธ์ช้า แต่ Gradion สามารถกำหนดเป้าหมายการแยกส่วนแรกได้ภายใน 2 สัปดาห์ และส่งมอบ Production API แรกได้ภายใน 8 สัปดาห์

ขั้นตอน	สิ่งที่เกิดขึ้น	ระยะเวลาโดยประมาณ
การประเมินขอบเขต	เราจะระบุ Business Capabilities ที่ถูกจำกัดอยู่ในระบบ ERP จัดลำดับตามระดับปัญหา ความถี่ในการเปลี่ยนแปลง และจุดเชื่อมโยง คุณจะได้รับแผนงานการแยกส่วนที่จัดลำดับความสำคัญพร้อมคำจำกัดความของ API Contract ซึ่งเป็นแผนการดำเนินงานที่เป็นรูปธรรม ไม่ใช่เพียงแค่สไลด์นำเสนอ	2 สัปดาห์
การแยกส่วนครั้งแรก	ดึง Business Capability ที่มีปัญหามากที่สุดออกมาเป็นบริการที่สร้างขึ้นมาโดยเฉพาะพร้อม API ที่เสถียร โดยใช้ข้อมูลจริงและรองรับปริมาณการใช้งานจริง ด้วยเทคนิค Strangler-fig Routing ทำให้ ERP ยังคงทำงานได้ตลอดเวลา และผ่านการตรวจสอบภายใต้ภาระงานจริง (Production Load) ก่อนการเปลี่ยนผ่านระบบ	6–8 สัปดาห์
การแยกส่วนต่อเนื่อง	การแยกส่วนในครั้งถัดๆ ไปจะรวดเร็วและประหยัดยิ่งขึ้น เนื่องจากรูปแบบการเชื่อมโยงระบบ, เลเยอร์การซิงค์ข้อมูล และโครงสร้างพื้นฐานสำหรับการติดตั้งใช้งานมีอยู่แล้ว เราจะดำเนินการตามแผนงานตามลำดับความสำคัญ	ดำเนินการต่อเนื่อง, 4–6 สัปดาห์ต่อหนึ่ง Capability

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

สิ่งที่เราส่งมอบ

ความสามารถหลักสองประการในหน้านี้ สามารถขอรายละเอียดระเบียบวิธีปฏิบัติงานฉบับเต็มได้

การระบุขอบเขตและแผนงานการแยกส่วน

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

การออกแบบ API Layer และการกำหนด Contract

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

ความสามารถในการส่งมอบเพิ่มเติม

ความสามารถ	สรุป
การแยกส่วนแบบ Strangler-Fig	การเรียกใช้ API ใหม่จะถูกส่งไปยังบริการที่แยกออกมา ในขณะที่การเรียกใช้ ERP เดิมยังคงทำงานต่อไปจนกว่าบริการใหม่จะได้รับการตรวจสอบและมีความเสถียร การรับส่งข้อมูลจะถูกเปลี่ยนผ่านอย่างค่อยเป็นค่อยไป ERP จะไม่ถูกแก้ไขในระหว่างการแยกส่วน มีเพียงเลเยอร์การกำหนดเส้นทางเท่านั้นที่เปลี่ยนแปลง ทำให้ไม่มีการหยุดชะงักต่อการเงิน คลังสินค้า หรือการดำเนินงาน
การเชื่อมต่อระบบ SAP และระบบเดิม	สำหรับ SAP: ใช้ BAPIs, IDocs, OData, RFC โดยการเรียกใช้จากอินเทอร์เฟซที่เผยแพร่ หลีกเลี่ยงการเขียน ABAP แบบกำหนดเอง สำหรับ Oracle และระบบเดิม: ใช้รูปแบบ Adapter และ Anti-Corruption Layer เพื่อแยกบริการที่แยกออกมาจากโครงสร้างภายในของ ERP
การซิงโครไนซ์ข้อมูล	รับประกันความสอดคล้องของข้อมูลอย่างชัดเจนในแต่ละเอนทิตี: แหล่งข้อมูลหลัก การแก้ไขข้อขัดแย้ง ความล่าช้าที่ยอมรับได้สูงสุด การตรวจจับและกู้คืนความล้มเหลว ใช้โมเดลที่เข้มงวดกว่าสำหรับข้อมูลทางการเงิน และใช้ Eventual Consistency ในกรณีที่ยอมรับได้
การย้ายระบบแบบค่อยเป็นค่อยไป	เราจะไม่แยกส่วนความสามารถใดๆ ออกมา จนกว่าบริการทดแทนจะทำงานคู่ขนานและได้รับการตรวจสอบภายใต้ภาระงานจริงในระบบการผลิต ฝ่ายการเงินยังคงปิดบัญชีสิ้นเดือนได้ คลังสินค้ายังคงจัดส่งคำสั่งซื้อได้ ไม่มีสิ่งใดหยุดชะงักระหว่างการแยกส่วนระบบ

เทคโนโลยี

เลเยอร์	สิ่งที่เราใช้
การเชื่อมต่อ	REST และ GraphQL APIs (ตามข้อกำหนด OpenAPI), รูปแบบ Event-Driven (Kafka, RabbitMQ), Adapter และ Anti-Corruption Layer สำหรับ SAP RFC/BAPI/IDoc
บริการ	ทำงานในคอนเทนเนอร์บน Kubernetes, มี Deployment Pipeline แยกอิสระสำหรับแต่ละบริการที่แยกออกมา, มี Observability ตั้งแต่วันแรก (Structured Logging, Distributed Tracing, Alerting)
ข้อมูล	Read Model ที่สร้างขึ้นเพื่อวัตถุประสงค์เฉพาะสำหรับการรายงานและการวิเคราะห์ แยกออกจาก Transactional Store ของ ERP ใช้ Change Data Capture สำหรับการซิงโครไนซ์ในกรณีที่ไม่สามารถเข้าถึง API ได้โดยตรง
ระบบ ERP ที่รองรับ	SAP S/4HANA, SAP ECC, Oracle E-Business Suite, Microsoft Dynamics, และระบบเดิมที่พัฒนาขึ้นเองซึ่งมีจุดเชื่อมต่อระดับฐานข้อมูลหรือไฟล์

ผลลัพธ์ที่พิสูจน์ได้ในการใช้งานจริง

ผู้จัดพิมพ์หนังสือศิลปะหรูหรา - เลเยอร์การเชื่อมต่อ ERP, แพลตฟอร์ม GMV มูลค่า €27M
ผู้จัดพิมพ์หนังสือศิลปะหรูหราที่มีชื่อเสียงซึ่งดำเนินงาน 12 สาขาทั่วโลก ประสบปัญหาการดำเนินงานส่วนหลังบ้านที่แยกส่วนกันในหลายระบบ ทั้งข้อมูลสินค้าคงคลัง และคำสั่งซื้อ ซึ่งต้องใช้การจัดการด้วยตนเองจำนวนมาก Gradion ได้คง Microsoft Business Central ไว้เป็นระบบ ERP และระบบบันทึกหลัก พร้อมสร้างเลเยอร์การค้า Shopify Plus แบบ Dual-Instance รอบระบบดังกล่าว โดยมีการซิงค์ข้อมูลแบบเรียลไทม์กับ ERP, Akeneo (PIM) และ Makaira (CMS) ผ่านการเชื่อมต่อ API ที่สะอาด การประสานงานด้วยตนเองที่เคยเชื่อมโยงระบบเหล่านี้ถูกกำจัดออกไปโดยสิ้นเชิง ปัจจุบันแพลตฟอร์มนี้สามารถรองรับ GMV ต่อปีได้ถึง €27M และกิจกรรมการขายแต่ละครั้งที่มีมูลค่าสูงถึง €5M โดยไม่มีความไม่เสถียร

ผู้ผลิตเทคโนโลยีสุขภาพ - แยก ERP และ PIM ออกจากระบบการค้า, ธุรกิจมูลค่า €400M
ผู้ผลิตเทคโนโลยีสุขภาพรายใหญ่ที่มีรายได้ต่อปี €400M และมีผลิตภัณฑ์ในกว่า 100 ตลาด ประสบปัญหาข้อมูล ERP และ PIM ไม่ตรงกันกับสิ่งที่ลูกค้าเห็นบน Shopify Plus Storefronts สามแห่งใน EU, UK และ US ในบริบทของเทคโนโลยีสุขภาพ ความถูกต้องของข้อมูลมีความสำคัญทางคลินิก Gradion ได้คงระบบ ERP และ PIM ที่มีอยู่เดิมไว้ และออกแบบเลเยอร์การเชื่อมต่อ API แบบกำหนดเองที่ซิงค์ทั้งสองระบบโดยอัตโนมัติทุก 15 นาทีในทั้งสามอินสแตนซ์ ความล้มเหลวในการดำเนินการและภาระงานด้วยตนเองลดลงทันที ปัจจุบันสถาปัตยกรรมนี้รองรับ GMV มูลค่า €400M ในกว่า 100 ตลาด โดยที่ ERP หรือ PIM ไม่จำเป็นต้องเปลี่ยนแปลง

ตัวเลขทั้งหมดมาจากโครงการที่ดำเนินการจริง สามารถขอข้อมูลอ้างอิงลูกค้าได้ภายใต้ข้อตกลงการไม่เปิดเผยข้อมูล (NDA)

ดึง Business Logic ออกจาก ERP โดยไม่ต้องเปลี่ยนระบบเดิม