고객·공급사·포워딩이 ‘같은 화면’을 보게 되기까지
플랫폼을 오래 운영하다 보면, 기술보다 더 복잡해지는 것이 있다.
그것은 기능도 아니고, 트래픽도 아니다.
관계다.
REINDEERS 플랫폼 역시 마찬가지였다.
고객사, 공급사, 포워딩.
각각은 분명 자신의 역할을 충실히 수행하고 있었지만,
플랫폼 안에서는 항상 어딘가 어긋나 있었다.
고객사는 “견적을 요청했다”고 생각했고,
공급사는 “주문이 확정되지 않았다”고 말했으며,
포워딩은 “물류 조건이 확정되지 않았다”고 답했다.
문제는 누구의 잘못도 아니었다.
문제는 각자가 서로 다른 기준점에서 같은 주문을 바라보고 있었다는 것이었다.
같은 주문, 다른 해석
초기의 구조에서 가장 큰 문제는
견적 → 주문 → 물류가 단선적인 흐름으로 설계되어 있었다는 점이다.
현실의 무역에서는 이 세 단계가 결코 직선으로 이어지지 않는다.
-
견적은 여러 번 바뀌고
-
주문은 조건부로 확정되며
-
물류는 생산과 일정에 따라 다시 재조정된다
하지만 시스템은 이를 “한 번 정해지면 끝나는 단계”로 취급했다.
그 결과, 주문 하나를 두고 상태 값은 맞는데 의미는 다른 상황이 반복해서 발생했다.
이 문제를 해결하기 위해, 우리는 기능을 추가하는 대신
구조를 다시 정의하기로 했다.
Draft라는 개념을 중심에 두다
재설계의 출발점은 단순했다.
“확정되지 않은 것은, 확정되지 않았다고 명확하게 표현하자.”
그래서 모든 흐름의 중심에 Draft 개념을 두었다.
-
고객사의 요청은 Draft Purchase Order
-
Draft PO를 기반으로 Draft Delivery Order
-
Draft DO를 기준으로 포워딩의 물류 견적 발행
이 구조에서 중요한 점은
누구도 ‘확정된 것처럼 행동하지 않아도 된다는 것이다.
-
고객사는 여러 시나리오를 비교할 수 있고
-
공급사는 생산 가능 범위 안에서 조건을 제시하며
-
포워딩은 실제 실행 가능한 물류 조건으로 입찰한다
모든 참여자가 같은 상태, 같은 맥락, 같은 화면을 보게 된 순간이었다.
UI/UX 변경은 결과이지, 목적이 아니었다
최근 진행된 주문·견적 UI 개편은
디자인을 바꾸기 위한 작업이 아니었다.
구조가 바뀌면, 화면도 반드시 바뀌어야 했다.
이전의 UI는 “입력 화면”에 가까웠다면,
현재의 UI는 “의사결정 화면”에 가깝다.
-
지금 이 주문이 어디까지 확정되었는지
-
누가 다음 액션을 가져가야 하는지
-
내가 바꿀 수 있는 것과 없는 것이 무엇인지
이 모든 정보가 한 화면 안에서 자연스럽게 읽히도록 재구성되었다.
기술적으로는 상태 의존성이 높은 영역이었고,
여러 번의 충돌과 재설계가 필요했다.
하지만 이 과정을 거치지 않고서는
플랫폼의 다음 단계를 이야기할 수 없었다.
AI는 ‘결정자’가 아니라 ‘보조자’로 들어온다
이번 구조 개편에서 AI는 전면에 등장하지 않는다.
대신 조용히, 그러나 핵심적인 지점에 배치되었다.
-
고객사 견적 요청 단계에서의 조건 정리
-
공급사 상품 정보 기반 견적 보조
-
포워딩 물류 견적 비교와 조건 추천
AI는 결정을 대신하지 않는다.
대신 결정을 하기 좋은 상태를 만들어준다.
이 철학은 이후 DVRP, 재고, 배차, 물류 전반으로 그대로 이어진다.
그리고 이제, DVRP로 넘어간다
고객·공급사·포워딩의 관계 구조가 정리되면서
플랫폼은 자연스럽게 다음 질문에 도달했다.
“이 주문은, 실제로 어떻게 움직이는가?”
그 답이 바로 DVRP다.
현재 REINDEERS에서는
DVRP 2월 중순 BETA를 목표로 한 개발이 진행 중이다.
이제 주문은 문서로 끝나지 않는다.
재고, 창고, 트럭, 일정, 그리고 실제 이동까지 이어진다.
이번 관계 모델 재설계는
DVRP를 붙이기 위한 준비 작업이기도 했다.
다음 글에서는
무역 플랫폼과 3PL 엔진이 만나는 지점,
그리고 왜 DVRP를 독립 서비스가 아닌 플랫폼 코어로 설계했는지를 이야기하려 한다.
구조를 정리했으니,
이제 움직일 차례다.
Comments
Post a Comment