ERP 중심
단일 원천
ERP 밖의 신호를 ERP 안으로 들일지, 별도 계층에 둘지 먼저 정합니다. 외부 창고 재고, 3PL 운송 상태, 협력사 생산 일정이 여기 해당합니다.
외부 소스 수동 조회
데이터 통합 가이드 · 스켈바디 주식회사
흩어진 재고와 운송 기록을 잇는 법
데이터 통합은 도구를 사는 일이 아니라 질문을 정하는 일입니다. 이 문서는 ERP·SCM·WMS·TMS와 외부 물류 신호를 하나의 분석 흐름으로 묶는 방식을 사례 유형별로 나눕니다.
먼저 정할 세 가지
통합 전에 순서를 정하는 세 가지
소스 목록을 먼저 만들면 대개 실패합니다. 질문, 공통 키, 시간 축 — 이 셋이 정해져야 어떤 시스템을 붙일지가 결정됩니다.
어떤 질문에서 출발할 것인가
통합 범위는 질문에서 나옵니다. 특정 SKU의 리드타임 편차를 보고 싶은지, 특정 항만 지연이 후속 생산에 미치는 영향을 보고 싶은지에 따라 필요한 소스가 달라집니다. 첫 질문은 좁게 잡는 편이 낫습니다. 좁은 질문 하나를 끝까지 통과시키면 다음 질문을 붙이기가 훨씬 쉬워집니다.
공통 키를 정하는 일
여러 시스템을 잇는 첫 단계는 공통 키를 정하는 것입니다. 대개 주문 번호, SKU와 로케이션 조합, 운송장 번호가 기준이 됩니다. 문제는 시스템마다 키를 다르게 쓴다는 점입니다. WMS의 로케이션 코드와 TMS의 출발지 코드가 다르면 매핑 테이블이 필요합니다. 이 매핑을 누가 관리할지 정하지 않으면 통합은 유지되지 않습니다.
시간 축을 맞추는 일
같은 사건이 시스템마다 다른 시각으로 기록됩니다. 출고 확정 시각과 실제 상차 시각이 다르고, 도착 예정 시각은 여러 번 갱신됩니다. 계획 시각과 실제 시각을 구분해 저장해야 나중에 편차 분석이 가능합니다. 실시간 이벤트를 다룰 때는 갱신 이력을 버리지 않는 설계가 중요합니다.
이 문서가 다루는 범위
ERP·SCM·WMS·TMS를 한 흐름으로 묶는 방식
이 안내는 사내 ERP에서 시작해 물류 신호까지 닿는 흐름을 다룹니다. SCM 계획, WMS 재고, TMS 운송, 그리고 외부 운송 가시성 데이터가 모두 같은 질문에 답하게 만드는 것이 목표입니다. 벤더 목록이 아니라 결정의 순서를 다룹니다.
아래 사례 유형은 조직의 소스 구성과 정리 성숙도를 기준으로 나누었습니다. 각 유형별로 통합 계층에 남는 일과 운영 부담이 다릅니다.
사례 유형 네 가지
조직의 소스 구성에 따라 갈리는 네 가지 길
같은 도구를 써도 시작점이 다르면 통합 난이도가 달라집니다. 아래 네 유형에서 자기 조직과 가장 가까운 줄을 먼저 찾으십시오.
유형
소스 구성
통합에서 먼저 정할 것
주된 부담
다중 시스템 병존
SCM · WMS · TMS
벤더가 다른 세 시스템을 잇는 공통 모델이 필요합니다. 원천을 직접 건드리지 않고 데이터 서비스 계층에서 접근을 통일하는 구조가 유지보수에 유리합니다.
모델 표준 관리
외부 신호 결합
운송 가시성
외부 운송 이벤트를 사내 주문과 붙입니다. 운송장 또는 컨테이너 번호를 기준으로 매핑하고, 배송 도착 예정 시각(EAT) 갱신을 어떻게 보관할지 미리 정합니다.
갱신 이력 관리
반복 정리 자동화
수기 정리 작업
매주 같은 형식으로 내려받아 손으로 맞추는 작업을 워크플로로 옮깁니다. 이 단계를 건너뛰고 대형 플랫폼부터 도입하면 정리되지 않은 데이터가 그대로 올라갑니다.
반복 작업 자동화
키 · 시간 · 계층
이어 붙이는 세 가지 결정
사례 유형이 정해져도 실제 통합에서 반복적으로 부딪히는 지점은 비슷합니다. 같은 일이 다시 생기지 않도록 남겨두어야 할 세 가지 규칙이 있습니다.
결정 하나
공통 키 매핑 표
주문 번호, SKU와 로케이션 조합, 운송장 번호가 보통 기준입니다. WMS 로케이션 코드와 TMS 출발지 코드가 다르면 매핑 표가 필요합니다.
누가 이 표를 갱신하는지 이름을 정해둡니다. 담당이 없으면 통합은 유지되지 않습니다.
결정 둘
계획 시각과 실제 시각 분리
같은 사건이 시스템마다 다른 시각으로 기록됩니다. 출고 확정 시각과 실제 상차 시각이 다르고, 도착 예정 시각은 여러 번 갱신됩니다.
계획과 실제를 구분해 저장하고 갱신 이력을 남겨야 편차 분석이 가능합니다.
결정 셋
통합 계층과 분석 계층 분리
계층을 나누면 원천 컬럼 하나가 바뀌어도 분석 모델 전체를 고치지 않아도 됩니다.
대신 계층 사이의 계약을 문서로 관리합니다. 문서화를 생략하면 시간이 지나면서 아무도 전체 구조를 설명하지 못합니다.
플랫폼이 통합 계층에서 하는 일
계층에 놓이는 도구와 하는 일
도구는 사례 유형이 정해진 뒤에 고릅니다. 각 도구가 통합 계층에서 실제로 하는 일과, 도입 전에 확인할 지점을 정리했습니다.
-
SAP Datasphere
데이터 서비스 계층
SAP Datasphere 같은 데이터 서비스 계층을 두고 소스별 접근을 통일하는 방식이 자주 쓰입니다. 데이터 패브릭이라는 표현이 자주 붙는 이유도 여기에 있습니다. 다만 이름이 붙었다고 통합이 자동으로 되지는 않습니다.
확인할 것 · 기존 SAP 자산과의 경계, 원천을 직접 조회할지 사본을 둘지
-
Microsoft Fabric
레이크하우스 접근
Microsoft Fabric은 데이터 통합, 분석, BI를 하나의 플랫폼으로 묶는 방향으로 평가됩니다. 별도 계층을 두지 않고 분석 플랫폼 자체가 통합 계층을 겸하는 접근입니다.
확인할 것 · 사내 표준이 Microsoft 생태계인지, 워크스페이스와 권한을 누가 관리할지
-
Alteryx
정리 작업 자동화
Alteryx는 이런 반복적인 정리와 조합 작업을 워크플로로 옮기는 데 쓰입니다. 통합 이전에 정리 작업이 병목인 조직에서 먼저 검토할 만합니다.
확인할 것 · 지금 손으로 하는 작업의 목록과 주기, 워크플로를 넘겨받을 담당
-
FourKites · project44
외부 운송 신호
운송 가시성 데이터는 외부에서 들어옵니다. FourKites는 트럭·철도·해상·항공 운송 이벤트를 추적하는 데 쓰이고, project44는 실시간 화물 추적과 예외 알림에 강점이 있습니다. 이 데이터를 사내 주문과 붙이려면 운송장 또는 컨테이너 번호를 기준으로 매핑해야 합니다.
확인할 것 · 사내 주문 번호와 매핑이 가능한지, 예외 알림을 어디로 보낼지
-
운영 점검
통합 이후
파이프라인이 돌기 시작하면 운영 부담이 생깁니다. 스키마 변경, 지연, 누락을 감지하는 점검이 필요합니다. 데이터 품질 지표를 대시보드에 함께 두면 문제를 빨리 찾을 수 있습니다.
확인할 것 · 실패 알림을 받을 담당, 스키마 변경을 감지하는 절차
계층을 나누는 이유
계층을 나눠 두면 나중의 변경이 가벼워집니다
통합 계층과 분석 계층을 분리하면 원천 시스템 변경이 분석에 미치는 영향이 줄어듭니다. 원천에서 컬럼 하나가 바뀌어도 분석 모델 전체를 고치지 않아도 됩니다. 대신 계층 사이의 계약을 문서로 관리해야 합니다. 계약은 무엇을 언제 어떤 단위로 넘기는지를 적은 짧은 문서로 충분합니다.
이 문서화를 생략하면 시간이 지나면서 아무도 전체 구조를 설명하지 못하게 됩니다. 새 담당자가 들어왔을 때 어디부터 읽어야 하는지 알 수 있도록, 계층 이름과 책임 범위를 한 장에 남겨 두십시오.
통합 이후에 남는 일
통합은 끝나는 프로젝트가 아니라 유지되는 구조라는 점을 전제로 계획하십시오. 스키마 변경과 지연·누락을 감지하는 점검을 일정에 넣고, 데이터 품질 지표를 대시보드에 함께 두면 문제를 훨씬 빨리 찾을 수 있습니다. 파이프라인이 조용히 멈추는 일은 대개 실패가 아니라 방치에서 옵니다.
통합을 시작하기 전에 자주 나오는 질문
첫 파이프라인 전에 정해야 할 것들
작은 회사라도 데이터 통합이 필요한가요? +
소스가 두 개 이상이고, 서로 다른 시스템의 값이 매주 손으로 맞춰지고 있다면 필요합니다. 반대로 질문이 아직 하나뿐이고 원천이 ERP 한 곳이라면 통합 계층을 먼저 만들 이유는 적습니다. 그 경우에는 ERP 밖 신호를 어떻게 다룰지만 정리해두어도 충분합니다.
운송 가시성 데이터부터 붙이는 게 좋은가요? +
먼저 매핑 가능성부터 확인합니다. 외부 이벤트의 운송장 번호와 사내 주문 번호가 바로 이어지지 않으면, 매핑 표를 만들 수 있는지가 선행 조건이 됩니다. 매핑이 되지 않는데 대시보드를 먼저 만들면 지도를 못 찾는 상태로 화면만 만드는 셈이 됩니다.
데이터 패브릭이면 통합이 자동으로 되나요? +
아닙니다. 패브릭은 접근 방식을 묶는 개념이고, 어떤 키를 어떤 규칙으로 이을지와 시간 축을 어떻게 구분할지는 여전히 사람이 정합니다. 도구가 결정을 대신하지는 않습니다.
분석 모델은 언제 만들어야 하나요? +
첫 질문이 통과된 직후가 좋습니다. 질문이 정해지기 전에 모델을 만들면 원천이 바뀔 때마다 고쳐야 합니다. 좁은 질문 하나를 끝까지 통과시킨 뒤 그 위에 다음 질문을 얹는 순서가 유지보수에 유리합니다.
다음 단계
통합 범위를 함께 확인해 드립니다
어떤 질문에서 시작할지, 지금 소스가 몇 개인지, 매주 손으로 맞추는 작업이 어디에 있는지 알려주시면 사례 유형과 필요한 계층 구성을 함께 정리해 드립니다. 첫 상담은 범위 확인에서 시작합니다.
- 전화
- +82 2-6209-7608
- 운영 시간
- 평일 09:00 – 18:00 (주말 및 공휴일 휴무)
- 주소
- 서울특별시 강남구 테헤란로 152 (역삼동, 강남파이낸스센터) 20층
스켈바디 주식회사
서울특별시 강남구 테헤란로 152 (역삼동, 강남파이낸스센터) 20층 · 사업자등록번호 214-86-77310
skelvadi.co.kr