결론부터 말하자. 대부분의 창고 도크 스케줄은 눈을 감고 만든다.
스케줄러는 트럭이 '언제 와야 하는지'를 기준으로 계획을 세운다. 트럭이 '실제로 언제 오는지'는 그 스케줄 어디에도 없다. 2시간 지연은 예외가 아니라 일상이다. 예약 장부는 매일 찢어졌다가 다시 만들어지고, 입고 담당자는 전화와 문자 메시지로 불을 끄느라 바쁘고, YMS는 50건의 예약이 모두 순조롭다고 태연하게 보고한다.
이렇게 묻고 싶을 것이다. 트럭 위치 데이터는 이미 있지 않은가? GPS 위치, 도착 예정 시각. TMS에 다 있다. 문제는 그 어떤 것도 YMS에 들어가지 않는다는 것이다. 두 시스템은 서로 다른 이야기를 하고, 균열은 가장 아픈 곳에 떨어진다. 도크 문 앞이다.
스케줄은 '와야 할 시각'이라고 말한다. 트럭은 '실제로 오는' 시각에 산다
전형적인 아침을 상상해 보자. 오전 8시, 스케줄러는 TMS에서 내보낸 표를 YMS에 다시 입력한다. 도크 번호, 시간대, 예약 ID, 정갈하게. 마지막 한 건을 입력하는 순간, 계획은 식기 시작한다.
TMS 쪽에서는 트럭이 고속도로 정체에 갇혀 있다. GPS는 몇 분마다 신호를 보내고, 도착 예정 시각은 계속 뒤로 밀린다. YMS 쪽에서는 예약이 정적 레코드다. 사람이 움직이지 않으면 아무것도 움직이지 않는다. 도크 작업자들은 1시간 전부터 인력, 지게차, 바닥 공간을 준비한다. 트럭은 오지 않는다. 2시간 뒤에 오지만, 시간대는 만료됐고, 도크는 찼고, 운전사는 게이트에서 화를 내고, 배차 담당자는 전화로 계속 불을 끈다.
2년쯤 전, 캘리포니아 온타리오의 3PL 창고를 방문했다. 입고 매니저는 매일 오전 10시에 '정합 회의'를 연다고 했다. 스케줄러, 입고 리드, 운송 코디네이터 3명이 TMS 운송 중 목록과 YMS 예약 장부를 들고 앉아 손으로 불일치를 찾는다. 3명, 하루 1시간, 두 시스템 사이 데이터 파이프의 일을 하고 있다. 듣고 나서 든 생각은 하나뿐이었다. 이건 사람이 할 일이 아니다.
데이터는 있다. 공백은 조직도에 있고, 주인은 없다
첫 번째 본능은 보통 '통합 문제'다. 아니다. 주류 YMS·TMS 벤더는 모두 문서가 꽤 괜찮은 오픈 API를 제공한다. 진짜 장애물은 세 겹으로 쌓여 있고, 뒤로 갈수록 더 어렵다.
첫 번째 층은 데이터 정의다. TMS의 '예상 도착'은 운송 마일스톤을 기준으로 계산된다. 출발, 운송 중, 50마일 전. YMS 예약은 '도크 점유 시간대'를 기준으로 계산된다. 양쪽은 '도착'이 무슨 뜻인지조차 공유하지 않는다. 트럭은 정문에서 도착으로 치는가, 아니면 문 앞에 후진해서 바퀴 고임을 대는 시점인가. TMS는 YMS의 시간대가 언제부터 돌아가기 시작하는지 모른다.
두 번째 층은 이벤트 세분성이다. TMS GPS는 연속 스트림이고, YMS 스케줄링은 이산 이벤트다. 위치 스트림을 '47분 지연, 오전 10시 예약을 오전 11시로 옮길 것 권고'로 바꾸려면 온전한 비즈니스 규칙 세트가 필요하다. 몇 분 지연되면 리스케줄하는가. 자동인가, 사람이 확인하는가. 예약이 움직이면 비는 도크는 누가 가져가는가. 이런 규칙을 벤더가 써 줄 리가 없다.
세 번째 층. 실제로 프로젝트를 죽이는 층이다. 주인이다. TMS는 운송 부서의 것이고, YMS는 창고 운영의 것이다. 운송은 정시율과 운임 비용으로 평가받고, 창고는 입고 처리량과 인력 효율로 평가받는다. 운송 중 가시성을 도크 스케줄링에 넣는 일은 운송 입장에서는 '창고 스케줄 이야기'이고, 창고 입장에서는 'TMS에 있는 데이터 이야기'로 보인다. 균열은 정확히 두 부서의 경계 위에 있고, 아무도 책임지지 않는다. 내가 본 YMS-TMS 통합 실패 프로젝트 10개 중 9개는 기술이 아니라 여기에서 죽었다.
분명히 해 두자. 데이터 자체는 오래전에 문제가 아니게 됐다. 2017년 12월 미국 ELD 의무화가 시행된 이후, 사실상 모든 장거리 트럭이 위치를 계속 보고하고 있다. 데이터는 있다. 없는 것은 그것을 스케줄에 싣는 책임자다.
공백을 메우는 세 가지 방법, 뒤로 갈수록 비싸다
방법 1: 손으로 한다. 스케줄러가 정해진 주기로 TMS나 가시화 포털에서 도착 예정 시각을 확인하고, 지연된 예약을 YMS에서 수동으로 리스케줄한다. 가장 저렴한 방법. 소프트웨어 비용 제로. 비용은 사람이다. 스케줄러는 전업 화면 감시자가 되고, 하루 수십 건의 예약은 한 사람이 감당하기에 이미 벅차다. 교대가 바뀌면 정보가 떨어진다. 하루 물동량이 적은 작은 창고에는 괜찮다. 규모가 커지면 느린 자살이다.
방법 2: 가시화 플랫폼의 도착 예정 시각을 YMS에 넣는다. 운송사 GPS 데이터를 모아서 꽤 믿을 만한 도착 예정 시각을 내는 운송 중 가시화 전문 플랫폼이 있고, 일부 YMS 벤더는 이를 위한 기성 커넥터를 제공한다. 비용은 구독료 + 한 번의 IT 통합 + 아무도 예산에 넣지 않는 데이터 품질 작업이다. 운송사 단말기는 오프라인이 되고, GPS는 흔들리고, 도착 예정 시각은 왔다 갔다 하고, YMS가 그 흔들림을 일일이 따라갈지 미리 정해야 한다. 제대로 된 IT 팀이 있는 중규모 운영에 맞는다.
방법 3: TMS와 YMS를 한 벤더로 통일하거나, 다리를 직접 짓는다. 데이터 모델은 설계상 일치하고, 지연 이벤트가 리스케줄 워크플로를 직접 트리거할 수 있다. 비용은 압도적으로 가장 높다. 시스템 교체는 대수술이다. 몇 달의 구현, 과거 데이터와 작업자 습관까지 전부 옮긴다. 원래 시스템 교체를 계획하고 있던 게 아니라면, 이 공백 하나 때문에 집을 태우지 마라.
무엇이든 고할 때, 먼저 다음 6가지 질문에 솔직히 답하라. 답할 수 없다면 아직 통합 이야기를 하지 마라.
- 하루에 예약을 몇 건 돌리는가, 그중 1시간 넘게 늦는 비율은 얼마인가. 답할 수 없다면 기준 데이터를 먼저 정리하라.
- 지연 도착 정보는 오늘 창고에 어떻게 닿는가. 전화, 메시지, 이메일, 아니면 아무도 없다?
- YMS 예약 시간대는 외부 이벤트로 바꿀 수 있는가, 아니면 손으로만 가능한가.
- TMS는 도착 예정 시각을 얼마나 자주 갱신하는가. 매분인가, 마일스톤 도달 시에만인가.
- '운송 중 가시성의 도크 스케줄링 반영'의 주인은 운송인가 창고인가. 어떤 KPI가 이를 담당하는가.
- 리스케줄이 자동화되면 규칙은 누가 쓰는가. 몇 분 지연되면 트리거하고, 사람이 확인하는가.
6개를 다 답하면 세 방법 중 어느 것이 자신에게 맞는지 알 수 있다. 이 단계를 건너뛰고 프로젝트로 직행하면, 십중팔구 두 번째 층에서 죽는다. 시스템은 연결되는데, 리스케줄 로직을 아무도 정의하지 않고, 다시 손으로 하게 된다.
기술 이야기는 그만. 누가 책임지는지 이야기하자
내 판단은 이렇다. YMS-TMS 공백은 본질적으로 기술 공백이 아니다. 조직 공백이다. 어떤 API든 연결할 수 있다. 어려운 건 규칙을 쓰고 책임을 배정하는 것이다. 세 가지 기술 옵션 중 무엇이든 된다. 단, '예약 장부는 실제로 오는 트럭과 일치한다'는 한 줄을 한 사람. 또는 작은 팀. 이 책임지고, 그 문장이 인사 평가에 들어갈 때만 된다. 그게 없으면 아무리 멋진 통합도 6개월 안에 수동 정합 회의로 되돌아간다.
IT 리드에게 한 마디. 다음 YMS 평가나 갱신 때 '오픈 API가 있습니까'라고 묻지 말고, 이렇게 물어라. 'TMS의 실시간 도착 예정 이벤트 스트림을 구독해서, 지연이 기준값을 넘으면 리스케줄 워크플로를 자동 트리거할 수 있습니까.' 이에 명확히 답하지 못하는 벤더는 아주 예쁜 문진을 팔고 있는 것이다.
운영 매니저에게 한 마디. 시스템이 연결될 때까지는 스케줄에 여유를 두어라. 하루 중 가장 붐비는 두 시간대(보통 아침 개장 러시와 오후 마감)의 예약 시간대를 각각 30분씩 늘려라. 비용 제로. 즉시 효과 있다.
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
