ERP, CRM 및 이커머스 통합 아키텍처: 플로우별 설계

이 가이드는 스토어, ERP, CRM이 이미 운영 중이며 이를 하나로 연동해야 하는 CTO, IT 관리자, 이커머스 담당자를 위해 작성되었습니다. 엔터프라이즈 시스템 통합 가이드에서 일반 원칙(레코드 소유권, 통합 패턴, 장애를 고려한 설계)을 설명합니다. 이 페이지에서는 해당 원칙을 커머스 삼각형에 플로우별로 적용하고, 토폴로지 선택 및 롤아웃 계획으로 마무리합니다.

이 가이드의 목차

• 세 가지 시스템, 다섯 가지 플로우
• 참조 아키텍처
• 다섯 가지 플로우 설계
• B2B 규칙은 설계를 어떻게 바꾸는가?
• 토폴로지: 대안 및 선택 기준
• 통합 레이어에서의 AI
• 롤아웃 계획
• Netbase 납품 사례
• 어떤 납품 기록이 있으며, 어떤 것이 없는가?
• 이 가이드의 한계는 무엇인가?
• 자주 묻는 질문
• 다음 단계

세 가지 시스템, 다섯 가지 플로우

대부분의 커머스 환경은 중심에 동일한 세 가지 시스템이 있습니다. 스토어는 판매와 결제를 담당합니다. ERP는 상품, 재고, 가격, 이행용 주문, 장부를 보유합니다. CRM은 거래처, 연락처, 견적, 서비스 이력을 보유합니다. 그 주변에 결제 공급자, 창고 또는 배송사, 그리고 종종 상품 정보 시스템이 위치합니다.

이 삼각형에서 발생하는 거의 모든 통합 작업은 다섯 가지 플로우로 나뉩니다.

도구를 선택하기 전에 자사 환경에 맞게 이 표를 작성하십시오. 두 시스템이 같은 행을 모두 소유한다고 주장하는 경우, 소유자는 통합 담당자가 아닌 비즈니스가 결정합니다. 레코드당 단일 소유자가 중요한 이유는 핵심 가이드에서 다룹니다. 이 페이지의 나머지 부분은 소유자가 확정된 후 각 플로우에 필요한 사항을 다룹니다.

참조 아키텍처

내구성 있는 설계는 어떤 제품이 구현하든 동일한 레이어를 가집니다.

• 시스템별 어댑터. 각 스토어, ERP 또는 CRM은 해당 시스템의 API와 데이터 모델을 처리하는 고유한 어댑터를 갖습니다. Microsoft 아키텍처 센터에서는 이를 안티 커럽션 레이어(anti-corruption layer)라고 설명합니다. 한 시스템의 의미론이 다른 시스템으로 유입되는 것을 차단하는 변환 레이어입니다. ERP가 교체될 때는 해당 어댑터만 변경됩니다.
• 단일 공유 데이터 모델. 어댑터는 서로에게 변환하는 대신 상품, 고객, 주문, 인보이스의 정규 모델로 변환합니다. 엔터프라이즈 통합 패턴 카탈로그에서 그 이유를 설명합니다. 공통 형식을 사용하면 새 시스템 추가 시 파트너당 하나의 변환 쌍만 필요합니다.
• 식별자 교차 참조. 작은 저장소가 모든 시스템에서 각 레코드의 키를 매핑합니다. 스토어 주문 번호, ERP 판매 주문, CRM 기회를 포함합니다. 이름이나 이메일로 매칭하지 않습니다.
• 내구성 이벤트. 변경 사항은 이를 만드는 동일한 데이터베이스 트랜잭션에 기록된 후 게시됩니다(트랜잭셔널 아웃박스 패턴). 따라서 충돌이 발생해도 ERP는 업데이트되고 스토어는 알 수 없는 상황을 방지합니다.
• 다단계 플로우에 대한 오케스트레이션. 주문-결제(order-to-cash)는 네 개의 시스템에 접촉합니다. 하나의 컴포넌트가 순서와 보상을 소유하므로 단계가 웹훅에 분산되지 않습니다.
• 모니터링 및 대사. 모든 플로우에는 대시보드, 알림, 소유 시스템과 복사본 간의 카운트 및 합계 일일 비교가 있습니다.

각 레이어에 대한 장애 규칙(멱등성 쓰기, 백오프 재시도, 데드레터 큐)은 핵심 가이드에 있으며 변경 없이 적용됩니다.

다섯 가지 플로우 설계

카탈로그 및 가격. 소유 시스템에서 이벤트로 변경 사항을 푸시하고 야간 전체 비교를 유지하십시오. 가격 이벤트를 놓치는 것은 늦게 도착하는 것보다 더 큰 문제입니다. 가격을 유효 기간과 함께 게시하여 스토어가 ERP가 청구하지 않을 가격을 표시하지 않도록 합니다.

재고. 원시 재고가 아닌 가용성을 전송하십시오. 채널별로 보유 수량 빼기 예약 수량 빼기 안전 재고입니다. 주문 생성 시 재고를 예약하고 취소 시 해제하여 두 채널이 마지막 단위를 두 번 판매하지 않도록 합니다.

고객 및 거래처. B2B에서는 CRM이 일반적으로 거래처와 연락처를 소유하고, ERP가 신용 조건을 소유합니다. 스토어는 둘 다 수신하며, 새 웹 고객은 먼저 소유 시스템에서 생성된 후 복사됩니다. 이렇게 하면 한 사람이 세 개의 레코드가 되지 않습니다.

주문 및 상태. 스토어는 결제가 승인될 때까지 주문을 소유합니다. 그 이후 ERP가 이행을 소유하며 상태, 배송, 추적 정보가 역방향으로 흐릅니다. 주문에는 스토어의 멱등성 키가 포함됩니다. RFC 9110에서 POST는 멱등성이 없다고 정의하므로 재시도된 생성이 두 번째 판매 주문이 되어서는 안 됩니다.

결제, 인보이스, 환불. 결제 공급자가 트랜잭션을 소유하고, ERP가 인보이스와 대변 전표를 소유하며, CRM이 거래처 팀에 둘 다 표시합니다. 캡처된 결제를 매일 인보이스와 대사하고, 환불은 ERP 또는 ERP API를 통해서만 시작되도록 합니다.

B2B 규칙은 설계를 어떻게 바꾸는가?

기업 대상 판매는 소비자 스토어에서는 없는 규칙을 추가하며, 각 규칙은 로직이 위치할 곳을 결정합니다.

• 고객별 가격표 및 계약 가격은 ERP 또는 CRM에 유지되며 거래처별로 조회합니다. 수천 개의 상품 변형으로 복사하지 않습니다.
• 신용 한도 및 결제 조건은 체크아웃 시 ERP에 대해 확인합니다. 한도 초과 주문은 실패하는 대신 승인을 기다립니다.
• 견적은 CRM에서 시작하여 재입력 없이 주문으로 전환되며, ERP 주문에 견적 참조를 유지합니다.
• 구매 주문 및 승인은 구매자 측에서 주문과 함께 저장되어 인보이스가 구매자 재무팀의 기대와 일치하도록 합니다.

토폴로지: 대안 및 선택 기준

네 가지 기준이 결정합니다. 데이터와 규칙이 얼마나 표준적인지, 2년 후 예상되는 시스템과 플로우의 수, 로직을 소유하고 변경해야 하는 주체, 야간에 운영할 주체입니다. 많은 환경이 커넥터로 시작하다 오류 처리와 가시성이 한계에 도달하면 허브로 이동합니다. 통합 허브는 그 단계의 소유 버전입니다. 멀티 벤더 스토어는 셀러 정산 및 벤더 카탈로그를 추가하며, 이는 마켓플레이스 플랫폼 아키텍처에서 다룹니다. 스토어 자체가 변경될 예정이라면 먼저 커스텀 이커머스 플랫폼 가이드로 해결하십시오.

Netbase 납품 사례

• 리워드 쇼핑 플랫폼(고객사명 비공개). 두바이 소재 로열티 회사를 위해 Netbase는 헤드리스 Magento 2 멀티스토어 플랫폼을 고객의 포인트 미들웨어, 주문 서비스, 상품 카탈로그에 연결했습니다. 고객의 시스템이 포인트와 주문을 소유하며, 웹훅이 변경 사항을 전달하고 예약된 동기화가 페일오버 역할을 합니다. 리워드 쇼핑 기록을 참조하십시오.
• 미국 고객을 위한 클라우드 ERP(고객사명 비공개). 2020년부터 오프쇼어 개발 및 매니징 파트너로서 Netbase는 멀티테넌트 클라우드 ERP를 구축하고 있으며, 1단계에는 테넌트가 이미 사용 중인 시스템에 대한 CRM 및 API 통합이 포함됩니다. 클라우드 ERP 기록을 참조하십시오.
• Cloodo Workspace. Netbase의 비즈니스 사업부로, 직장 환경에 CRM, HRM, 클라우드 ERP, AI 모듈을 하나의 제품으로 결합하여 레코드가 동기화되는 대신 하나의 시스템에 존재합니다. Cloodo 기록을 참조하십시오.

Netbase는 또한 카탈로그, 재고, 주문, 고객의 API 동기화를 통해 고객사 스토어를 ERP에 연결했습니다. 해당 고객사명은 공개되지 않습니다.

어떤 납품 기록이 있으며, 어떤 것이 없는가?

• 있는 것. 위의 기록은 범위와 설계를 설명합니다. 어떤 시스템이 연결되었는지, 어떤 시스템이 어떤 데이터를 소유하는지, 변경 사항이 어떻게 이동하는지입니다. Netbase의 제품화된 모듈에는 CRM 및 B2B 영업 엔진, 워크플로우 자동화 툴킷, Smart ERP Light가 포함되며, 납품된 플랫폼에는 WooCommerce, Magento 2, Laravel, 헤드리스 커머스가 포함됩니다.
• 없는 것. 이 기록들 중 어느 것도 통합의 기간, 메시지 볼륨, 오류율 또는 비즈니스 결과를 공개하지 않으며, 수치의 증거로 제시되지 않습니다. ERP 통합 고객사명은 공개되지 않습니다.

이 가이드의 한계는 무엇인가?

• 플로우 표는 B2C 및 B2B 커머스의 기본값입니다. 마켓플레이스, 구독, 제조는 고유한 플로우를 추가합니다.
• 패턴은 공개 설명에서 인용됩니다. 패턴을 적용한다고 해서 실제 데이터에 대한 테스트 없이 통합이 정확해지는 것은 아닙니다.
• 최소 권한 키, 전송 중 TLS, 저장 시 AES 암호화, 관리자 액세스에 대한 MFA 같은 보안 관행은 위험을 줄여줍니다. 이는 보장이 아닙니다.

다음 단계

스토어, ERP, CRM 현황과 가장 자주 문제가 발생하는 플로우, 마감일을 공유해 주시면 소유자, 플로우, 토폴로지를 매핑하는 솔루션 리뷰를 예약해 드립니다. 시스템 및 API 통합, ERP 및 CRM 개발 또는 더 많은 Netbase 인사이트도 확인하실 수 있습니다.

관련 서비스 및 솔루션