WEBVTT

00:00:00.000 --> 00:00:04.160
안녕하세요. m365 fm의 마이크로소프트 지식알림 에피소드에 오신 것을 환영합니다.

00:00:04.340 --> 00:00:06.000
저는 진행자 미르코 피터스입니다.

00:00:06.260 --> 00:00:09.180
오늘의 주제는 공급망 관련 업무를 하는 사람이라면 누구나 들어봤지만

00:00:09.180 --> 00:00:11.060
제대로 이해하는 사람은 드문 내용입니다.

00:00:11.240 --> 00:00:13.540
바로 다이나믹스 365운송관리입니다.

00:00:13.760 --> 00:00:14.760
문제가 무엇일까요?

00:00:14.960 --> 00:00:16.800
고객이 주문하면 재고는 창고에 쌓여있고

00:00:16.800 --> 00:00:19.580
운송업체는 픽업시간이 필요하며 고객은 배송을 기다리고

00:00:19.580 --> 00:00:22.160
나중에 누군가의 책상 위에는 화물청구서가 놓이게 됩니다.

00:00:22.380 --> 00:00:25.080
수년동안 이러한 단계들은 별도의 스프레드시트, 전화통화, 요금표,

00:00:25.080 --> 00:00:26.800
그리고 팀간의 업무 인수인계로 처리되어 왔습니다.

00:00:27.000 --> 00:00:28.800
아, 그리고 그것은 업무 공백을 만듭니다.

00:00:28.960 --> 00:00:31.460
운송계획이 세워지기도 전에 창고에서 상품을 준비할 수도 있습니다.

00:00:31.660 --> 00:00:33.720
재무팀은 누군가 얼마를 지불하기로 합의했는지 모르는 상태에서

00:00:33.720 --> 00:00:34.740
청구서를 받게 될 수도 있습니다.

00:00:34.920 --> 00:00:36.940
그렇다면 운송관리란 정확히 무엇일까요?

00:00:37.160 --> 00:00:41.280
쉽게 말해 다이나믹스 365공급망 관리 내에 있는 운송데스크입니다.

00:00:41.500 --> 00:00:44.420
참고문, 공급업체, 고객, 운송업체를 연결합니다.

00:00:44.680 --> 00:00:46.720
우리는 적재를 계획하고 경로와 요금을 선택하며

00:00:46.720 --> 00:00:48.460
상품을 발송하고 운송비를 확인합니다.

00:00:48.640 --> 00:00:49.940
이번 에피소드가 끝날 때쯤이면

00:00:49.940 --> 00:00:51.560
이 모든 조각이 어떻게 맞춰져

00:00:51.560 --> 00:00:53.980
여러분의 업무를 더 수월하게 만드는지 알게 될 것입니다.

00:00:56.000 --> 00:00:57.560
왜 운송관리가 필요한가?

00:00:58.060 --> 00:01:00.060
기본적인 사실부터 시작해보죠.

00:01:00.220 --> 00:01:01.820
화면상에 판매 주문이 있다고 해서

00:01:01.820 --> 00:01:04.120
물리적인 상품이 저절로 이동하지는 않습니다.

00:01:04.340 --> 00:01:07.760
트럭, 트레일러, 컨테이너 또는 다른 이동수단이 필요합니다.

00:01:08.020 --> 00:01:09.980
누군가는 상품의 출발지와 도착지,

00:01:10.380 --> 00:01:14.120
차지하는 공간, 출발시간, 그리고 운송비용을 파악해야 합니다.

00:01:14.120 --> 00:01:17.880
상자 하나가 고객 한 명에게 가는 것을 상상하면 간단하게 들립니다.

00:01:17.880 --> 00:01:21.320
하지만 실제 기업은 같은 날 같은 창고에서 많은 주문을 발송하고

00:01:21.320 --> 00:01:23.440
여러 공급업체로부터 물건을 받으며

00:01:23.440 --> 00:01:26.320
동시에 자체 사업장 간의 재고를 이동시키기도 합니다.

00:01:26.480 --> 00:01:30.080
각 이동에는 사람, 날짜, 공간, 비용이 수반됩니다.

00:01:30.280 --> 00:01:33.260
공유 시스템이 없으면 각 팀은 자신의 영역만 보게 됩니다.

00:01:33.480 --> 00:01:35.080
영업팀은 고객 주문을 봅니다.

00:01:35.300 --> 00:01:37.140
구매팀은 공급업체 주문을 봅니다.

00:01:37.380 --> 00:01:40.980
창고 직원은 피킹, 포장, 입고 또는 보관해야 할 품목을 봅니다.

00:01:41.200 --> 00:01:43.640
운송팀은 다른 모든 부서가 자기 일을 마친 후에야

00:01:43.640 --> 00:01:45.440
이동해야 할 물건들의 목록을 확인합니다.

00:01:45.660 --> 00:01:47.420
거기서부터 지연과 혼란이 시작됩니다.

00:01:47.420 --> 00:01:48.960
구체적인 예를 들어보겠습니다.

00:01:49.260 --> 00:01:52.600
창고에 같은 도시로 보낼 고객 주문 10건이 준비되어 있다고 가정해보죠.

00:01:52.740 --> 00:01:54.820
운송을 예약하기 전에 아무도의 주문들을 연결하지 않으면

00:01:54.820 --> 00:01:56.980
회사는 짐이 덜 찬 운송편을 여러 번 마련하거나

00:01:56.980 --> 00:01:59.140
창고에서 어떤 물건을 실어야 할지 모르는 상태에서

00:01:59.140 --> 00:02:00.540
운송업체가 먼저 도착할 수 있습니다.

00:02:00.760 --> 00:02:03.320
물건은 준비되었지만 이동은 계획되지 않은 상태입니다.

00:02:03.520 --> 00:02:06.680
그래서 운송관리는 다이나믹스 365 공급망 관리 내에서

00:02:06.680 --> 00:02:08.500
이러한 이동에 대한 체계를 제공합니다.

00:02:08.740 --> 00:02:10.240
이것은 운송장 번호를 입력하고

00:02:10.240 --> 00:02:11.980
지도에서 택배가 이동하는 것을 보는

00:02:11.980 --> 00:02:13.860
별도의 소비자용 배송앱이 아닙니다.

00:02:14.020 --> 00:02:15.840
대신 연결된 플랫폼 내에 이미 존재하는

00:02:15.840 --> 00:02:17.400
비즈니스 기록과 함께 작동합니다.

00:02:17.600 --> 00:02:20.060
주문이 발생하면 상품을 이동해야 할 필요성이 생깁니다.

00:02:20.220 --> 00:02:21.780
창고 작업은 상품을 준비합니다.

00:02:22.020 --> 00:02:23.860
운송관리는 해당 상품이 위치 간에

00:02:23.860 --> 00:02:25.220
어떻게 이동할지 계획합니다.

00:02:25.460 --> 00:02:27.980
사무실 건물의 운송 데스크와 같다고 생각하시면 됩니다.

00:02:28.280 --> 00:02:30.520
영업팀은 고객의 요청을 데스크로 가져옵니다.

00:02:30.700 --> 00:02:33.620
구매팀은 공급업체가 상품을 보낼 것이라는 소식을 가져옵니다.

00:02:33.800 --> 00:02:35.940
창고는 실제 재고와 하역장을 제공합니다.

00:02:36.200 --> 00:02:37.740
운송데스크는 이러한 요청을

00:02:37.740 --> 00:02:39.420
회사의 운송 계획과 연결합니다.

00:02:39.620 --> 00:02:40.960
두 가지 주요 방향이 있습니다.

00:02:41.300 --> 00:02:44.220
입고 운송은 상품이 귀하의 비즈니스 안으로 들어오는 것을 의미합니다.

00:02:44.420 --> 00:02:45.800
공급업체의 품목을 주문했으며

00:02:45.800 --> 00:02:47.600
해당 품목은 창고에 도착해야 합니다.

00:02:47.780 --> 00:02:49.460
때로는 공급업체가 이동을 관리하고

00:02:49.460 --> 00:02:50.960
때로는 기사가 준비합니다.

00:02:51.160 --> 00:02:53.160
어느 쪽이든 상품을 올바른 장소로 보내고

00:02:53.160 --> 00:02:55.280
도착 시 수령할 명확한 계획이 필요합니다.

00:02:55.480 --> 00:02:58.660
출고 운송은 상품이 귀하의 비즈니스 밖으로 나가는 것을 의미합니다.

00:02:58.880 --> 00:03:00.280
고객이 제품을 주문했습니다.

00:03:00.620 --> 00:03:01.660
창고에서 준비하고

00:03:01.660 --> 00:03:04.380
운송업체 나 회사 차량이 고객에게 배송합니다.

00:03:04.380 --> 00:03:07.140
두 흐름 모두 이동을 다루지만 시작점은 다릅니다.

00:03:07.360 --> 00:03:09.760
입고는 구매 주문과 공급업체에서 시작됩니다.

00:03:09.960 --> 00:03:12.260
출고는 판매 주문과 고객에서 시작됩니다.

00:03:12.460 --> 00:03:15.540
초보자가 자주 놓치는 세 번째 유형인 이전 주문도 있습니다.

00:03:15.880 --> 00:03:18.680
이전 주문은 자사 위치 간의 재고를 이동시킵니다.

00:03:18.900 --> 00:03:20.320
한 창고에 재고가 너무 많고

00:03:20.320 --> 00:03:22.360
다른 창고에는 재고가 필요할 수 있습니다.

00:03:22.600 --> 00:03:24.100
고객 구매는 포함되지 않지만

00:03:24.100 --> 00:03:26.360
실제 상품은 여전히 운송이 필요합니다.

00:03:26.660 --> 00:03:28.200
365 운송 관리에서

00:03:28.200 --> 00:03:30.500
이전 주문은 출고 시나리오에 속하며

00:03:30.500 --> 00:03:32.740
판매 주문과 함께 계획될 수 있습니다.

00:03:32.740 --> 00:03:35.300
하역장을 생각하면 이해가 쉽습니다.

00:03:35.640 --> 00:03:39.700
팔레트가 유료 고객에게 가든 다른 회사 창고로 가든 누군가는

00:03:39.700 --> 00:03:42.200
차량을 마련하고 공간을 예약하며

00:03:42.200 --> 00:03:43.940
같은 문으로 내보내야 합니다.

00:03:44.180 --> 00:03:45.740
따라서 이 연결된 접근 방식은

00:03:45.740 --> 00:03:48.420
별도의 목록과 전화통화로 이루어지던 기존 방식을

00:03:48.420 --> 00:03:49.740
공유된 정보로 대체합니다.

00:03:50.000 --> 00:03:52.380
주문은 시스템에 이동이 필요한 항목을 알려줍니다.

00:03:52.560 --> 00:03:54.000
창고는 품목을 준비합니다.

00:03:54.240 --> 00:03:56.900
운송 관리는 그 필요성을 운송 계획으로 바꿉니다.

00:03:57.100 --> 00:03:58.140
상품을 이동해야 할 때

00:03:58.140 --> 00:04:00.960
시스템은 먼저 실행 가능한 배송 계획이 필요합니다.

00:04:00.960 --> 00:04:02.220
적재 계획 수립

00:04:02.220 --> 00:04:05.140
오늘의 핵심 지식은 모든 물류팀에게 필요하지만

00:04:05.140 --> 00:04:07.760
종종 다르게 설명되는 내용에 관한 것입니다.

00:04:08.160 --> 00:04:09.020
적재 계획

00:04:09.020 --> 00:04:12.760
주문이나 배송 중 하나에서 운송 계획을 시작할 수 있습니다.

00:04:13.040 --> 00:04:13.280
저는

00:04:13.280 --> 00:04:15.800
그리고 바로 오해를 하나 바로 잡겠습니다.

00:04:16.120 --> 00:04:18.140
배송 계획은 처음부터 새로 시작하지 않습니다.

00:04:18.360 --> 00:04:19.880
이미 가지고 있는 기록에서 시작합니다.

00:04:20.100 --> 00:04:22.040
판매 주문에는 고객이 구매한 내용이 담겨 있습니다.

00:04:22.300 --> 00:04:24.600
구매 주문에는 공급업체가 보내야 할 항목이 나열되어 있습니다.

00:04:24.820 --> 00:04:25.460
추락, 히먼트

00:04:25.460 --> 00:04:27.160
는 항목들을 더 집중적인 배송 기록으로 묶어

00:04:27.160 --> 00:04:29.100
다른 항목들과 결합할 준비를 마친 상태로 만듭니다.

00:04:29.240 --> 00:04:31.020
그렇다면 어떤 시작점을 사용해야 할까요?

00:04:31.020 --> 00:04:32.980
그것은 귀사의 업무 방식에 따라 다릅니다.

00:04:33.160 --> 00:04:35.820
어떤 팀은 주문 라인을 직접 확인하며 일찍 계획을 세웁니다.

00:04:35.980 --> 00:04:37.400
다른 팀은 먼저 출하를 생성한 다음

00:04:37.400 --> 00:04:39.020
무엇을 함께 보낼지 결정합니다.

00:04:39.180 --> 00:04:40.960
두 경로 모두 같은 질문으로 이어집니다.

00:04:41.120 --> 00:04:42.640
무엇을 같은 차량에 실어야 할까요?

00:04:42.840 --> 00:04:44.320
가장 간단한 정의는 이렇습니다.

00:04:44.540 --> 00:04:45.240
적재, 로드

00:04:45.240 --> 00:04:47.480
는 계획된 상품 이동에 대한 디지털 기록입니다.

00:04:47.660 --> 00:04:48.160
트럭 한 대

00:04:48.160 --> 00:04:49.120
트레일러 한 대

00:04:49.120 --> 00:04:50.020
컨테이너 한 대

00:04:50.020 --> 00:04:52.460
또는 함께 이동하는 출하품의 집합으로 생각할 수 있습니다.

00:04:52.460 --> 00:04:56.540
물리적 인작업이 시작되기 전에 어떤 상품이 함께 속하는지 한 곳에서 볼 수 있게 해줍니다.

00:04:56.720 --> 00:04:58.540
이제 많은 사람이 오해하는 부분이 있습니다.

00:04:58.800 --> 00:05:01.560
적재는 모든 항목이 하나의 물리적 상자 안에 들어간다는 의미가 아닙니다.

00:05:01.740 --> 00:05:04.320
시스템이 하나의 운송 계획을 중심으로 상품을 그룹화한다는 의미입니다.

00:05:04.500 --> 00:05:06.680
여러 고객의 출하품이 하나의 트럭을 공유할 수 있습니다.

00:05:06.900 --> 00:05:09.160
대량 주문은 트레일러 하나를 가득 채울 수도 있습니다.

00:05:09.400 --> 00:05:13.540
공급업체로부터 도착하는 컨테이너도 창고가 상품을 입고하기 전부터 적재가 될 수 있습니다.

00:05:13.780 --> 00:05:16.720
요점은 각 주문을 개별적인 이동으로 처리하는 것을 멈추는 것입니다.

00:05:16.720 --> 00:05:20.480
유통업체의 금요일 배송을 위한 6개의 고객 주문이 준비되어 있다고 가정해보십시오.

00:05:20.600 --> 00:05:23.820
6개 모두 같은 구역에 있고 각 주문은 트럭의 일부만 채웁니다.

00:05:24.000 --> 00:05:28.040
반증빈 차량 6대를 보내는 것은 공간 낭비이며 6개의 별도 운송 작업을 생성합니다.

00:05:28.220 --> 00:05:31.100
대신 팀은 호환되는 출하품들을 하나의 적재로 그룹화할 수 있습니다.

00:05:31.300 --> 00:05:34.040
호환된다는 것은 함께 이동하는 것이 합리적이라는 뜻입니다.

00:05:34.240 --> 00:05:39.500
같은 창고에서 출발하고 비슷한 시기에 배송되어야 하며 차량 제한 내에 맞고 배송 규칙을 준수해야 합니다.

00:05:39.500 --> 00:05:43.700
시스템은 누군가 스프레드 시트에서 패턴을 찾을 필요 없이 기록들을 하나로 모으도록 돕습니다.

00:05:43.900 --> 00:05:45.760
이제 그 그룹은 공유된 계획을 갖게 됩니다.

00:05:45.960 --> 00:05:48.180
귀하의 창고는 적재에 무엇이 포함되는지 확인합니다.

00:05:48.360 --> 00:05:50.480
운송 계획자는 총공간과 무게를 확인합니다.

00:05:50.700 --> 00:05:53.800
사람들이 이메일, 메모 또는 별도의 파일에서 같은 목록을 다시 만들 필요가 없습니다.

00:05:54.040 --> 00:05:55.200
하지만 중요한 점이 있습니다.

00:05:55.500 --> 00:05:57.960
상품 그룹화는 단순히 항목들을 많이 모으는 것이 아닙니다.

00:05:58.140 --> 00:06:00.660
트럭에는 무게, 바닥 면적, 높이와 같은 제한이 있습니다.

00:06:00.920 --> 00:06:02.540
컨테이너에는 고유한 규칙이 있습니다.

00:06:02.840 --> 00:06:04.920
시스템이 이러한 제한을 확인하지 않고 상품을 그룹화하면

00:06:04.920 --> 00:06:07.760
화면상에서는 괜찮아 보여도 상차장에서 문제가 발생할 수 있습니다.

00:06:07.960 --> 00:06:11.220
다이나믹스 365는 이를 방지하기 위해 적재 템플릿을 사용합니다.

00:06:11.420 --> 00:06:15.580
적재 템플릿을 차량이나 컨테이너 유형별로 재사용 가능한 제한 세트로 생각하십시오.

00:06:15.700 --> 00:06:20.100
소형 배송 트럭용으로 하나, 대형 트레일러용으로 하나, 배송 컨테이너용으로 하나를 만드십시오.

00:06:20.220 --> 00:06:24.440
각 템플릿은 무게, 부피, 높이 및 귀사가 필요로 하는 기타 규칙에 대한 제한을 담고 있습니다.

00:06:24.700 --> 00:06:27.520
템플릿은 상품을 채우기 전에 적재의 형태를 미리 잡아줍니다.

00:06:27.520 --> 00:06:30.140
따라서 배송 화물의 무게가 너무 무겁거나 공간을 너무 많이 차지하면

00:06:30.140 --> 00:06:32.320
플래너는 해당 적재물에 포함되지 않음을 확인합니다.

00:06:32.480 --> 00:06:35.040
해결책은 두 번째 차량을 이용하거나 다른 템플릿을 사용하거나

00:06:35.040 --> 00:06:36.760
화물을 다르게 그룹화하는 것일 수 있습니다.

00:06:36.960 --> 00:06:38.860
소프트웨어가 팔레트를 직접 들어 올리지는 않지만

00:06:38.860 --> 00:06:41.820
실제 작업이 시작되기 전에 팀에게 더 명확한 계획을 제공합니다.

00:06:42.020 --> 00:06:45.260
내장된 접근 방식 중 하나는 볼륨 기반 적재물 구성입니다.

00:06:45.540 --> 00:06:47.620
이름은 조금 기술적으로 들릴 수 있습니다.

00:06:47.900 --> 00:06:53.160
이는 적재물을 구성하거나 제한할 때 시스템이 적재 템플릿의 최대 높이와 무게를 사용한다는 의미입니다.

00:06:53.160 --> 00:06:56.500
쉽게 말해 상품이 설정한 제한 범위 내에 맞는지 확인하는 것입니다.

00:06:56.680 --> 00:06:58.320
이러한 값은 고정되어 있지 않습니다.

00:06:58.500 --> 00:07:00.980
플래너는 실제 상황의 요구사항이 변경될 때 이를 재설정할 수 있습니다.

00:07:01.160 --> 00:07:02.860
운송업체가 다른 트레일러를 보낼 수도 있습니다.

00:07:03.080 --> 00:07:05.000
운송 경로에 따라 허용되는 높이가 다를 수도 있습니다.

00:07:05.200 --> 00:07:06.620
템플릿은 일반적인 규칙을 제공하고

00:07:06.620 --> 00:07:09.540
재설정 기능은 모든 것을 다시 구성할 필요 없이 예외 상황을 처리합니다.

00:07:09.720 --> 00:07:11.700
다시 그 6개의 고객 주문으로 돌아가 봅시다.

00:07:11.920 --> 00:07:14.320
각각은 트럭의 15% 정도를 차지할 수 있습니다.

00:07:14.600 --> 00:07:17.480
별도로 계획하면 텅 빈 트럭 6대를 보내게 될 수도 있습니다.

00:07:17.480 --> 00:07:18.580
하나의 적재물로 묶으면

00:07:18.580 --> 00:07:21.420
동일한 주문들이 트럭 한 대의 대부분을 채우고도 공간이 남을 수 있습니다.

00:07:21.620 --> 00:07:23.440
그것이 공간을 더 효율적으로 사용하는 방법입니다.

00:07:23.600 --> 00:07:25.640
이제 이 아이디어는 양방향으로 동일하게 적용됩니다.

00:07:25.800 --> 00:07:26.460
입고 계획의 경우

00:07:26.460 --> 00:07:28.960
공급업체로부터 들어오는 품목을 중심으로 적재물을 생성합니다.

00:07:29.140 --> 00:07:30.960
운송 계획이 예상 수령 정보와 연결되므로

00:07:30.960 --> 00:07:33.560
창고는 무엇이 도착할지 알고 미리 준비할 수 있습니다.

00:07:33.780 --> 00:07:36.060
배송이 게이트에 도착했을 때야 비로소 아는 대신

00:07:36.060 --> 00:07:38.480
입고팀은 계획된 기록을 미리 확인할 수 있습니다.

00:07:38.480 --> 00:07:39.640
출고 계획의 경우

00:07:39.640 --> 00:07:43.280
고객에게 보낼 창고 품목을 선택하여 적재물로 그룹화합니다.

00:07:43.520 --> 00:07:47.540
창고는 관련 없는 목록이 아닌 적재물 세부 정보를 바탕으로 상품을 준비합니다.

00:07:47.740 --> 00:07:52.260
완성된 적재물은 여전히 이동수단, 운송할 업체, 예상 비용이 필요합니다.

00:07:52.640 --> 00:07:54.880
경로, 운송업체, 요금입니다.

00:07:55.140 --> 00:07:58.080
이제 적재물은 무엇을 함께 운송해야 하는지를 알려줍니다.

00:07:58.280 --> 00:08:00.720
다음으로 누가 운송할지, 어떤 서비스를 이용할지

00:08:00.720 --> 00:08:02.920
해당 운송에 드는 비용은 얼마인지를 결정해야 합니다.

00:08:02.920 --> 00:08:05.340
상품을 이동시키는 업체를 운송업체라고 합니다.

00:08:05.520 --> 00:08:08.340
화물을 수거하고 배송하는 외부 운송회사일 수 있습니다.

00:08:08.620 --> 00:08:11.840
직접 트럭과 운전기사를 운영하는 경우 귀사의 차량일 수도 있습니다.

00:08:11.840 --> 00:08:15.160
어느 쪽이든 운송업체는 실제 운송에 대한 책임을 집니다.

00:08:15.320 --> 00:08:19.200
트럭이 귀사의 소유일지라도 여전히 계획이 필요하기 때문에 이러한 구분은 중요합니다.

00:08:19.380 --> 00:08:22.560
외부 운송업체를 이용할 때는 사전의 가격과 서비스에 대해 합의합니다.

00:08:22.760 --> 00:08:27.900
귀사의 차량을 이용하더라도 특히 고객 주문서에 배송비가 표시되는 경우 운송료를 계산하고 싶을 수 있습니다.

00:08:28.140 --> 00:08:31.360
다이나믹스 365 운송관리 기능은 두 상황 모드를 지원합니다.

00:08:31.600 --> 00:08:32.980
다음은 경로에 관한 내용입니다.

00:08:33.220 --> 00:08:36.480
경로는 픽업지에서 목적지까지의 계획된 이동 경로와 서비스 선택을 의미합니다.

00:08:36.660 --> 00:08:38.520
이는 실무적인 질문들에 대한 답을 제공합니다.

00:08:38.520 --> 00:08:45.140
운송업체가 어느 창고에서 물품을 수거하나요? 어떤 고객이나 위치가 물품을 받게 되나요? 어떤 운송 서비스가 이 이동을 담당하나요?

00:08:45.300 --> 00:08:48.400
본사 창고에서 전국에 있는 고객에게 배송되는 상황을 떠올려보세요.

00:08:48.640 --> 00:08:51.840
비용은 저렴하지만 시간이 오래 걸리는 표준 육상 운송 경로가 있을 수 있습니다.

00:08:52.040 --> 00:08:54.600
더 빠르지만 비용이 많이 드는 서비스를 이용할 수도 있습니다.

00:08:54.840 --> 00:08:57.860
시작점과 도착점은 같지만 운송수단 선택이 달라지는 것이죠.

00:08:58.060 --> 00:08:59.940
운임은 해당 선택에 대한 예상 비용입니다.

00:09:00.160 --> 00:09:02.160
막판에 임의로 입력하는 숫자가 아닙니다.

00:09:02.160 --> 00:09:06.500
운임은 운송업체와의 가격 계약과 배송 또는 경로 세부 정보가 결합되어 결정됩니다.

00:09:06.660 --> 00:09:10.360
물품의 출발지, 도착지, 사용된 서비스, 운송 물량을 말합니다.

00:09:10.580 --> 00:09:14.400
즉, 경로는 물품이 어떻게 이동해야 하는지를 알려주고, 운임은 예상 지불 비용을 알려줍니다.

00:09:14.560 --> 00:09:20.460
저렴한 경로는 약속된 배송 시간을 맞추지 못할 수 있고, 빠른 배송은 주문 금액보다 비용이 더 많이 들 수 있기 때문에 이 두 가지 개념은 함께 고려해야 합니다.

00:09:20.620 --> 00:09:26.440
운송 계획은 단순히 트럭을 찾는 것이 아니라, 고객과의 약속과 회사의 비용 규칙에 맞는 서비스를 선택하는 과정입니다.

00:09:26.440 --> 00:09:30.440
다이나믹스 365에는 운임 및 경로 작업대, 네이트 루트 워크벤치가 포함되어 있습니다.

00:09:30.660 --> 00:09:32.800
이름은 거창해 보이지만 목적은 단순합니다.

00:09:32.980 --> 00:09:37.280
계획자가 배송에 필요한 경로와 운임 선택지를 나란히 놓고 비교할 수 있는 공간을 제공합니다.

00:09:37.500 --> 00:09:43.140
운송업체 표를 하나씩 확인하고 별도의 파일에서 비교하는 대신, 해당 배송 요구사항과 관련된 선택지들을 검토할 수 있습니다.

00:09:43.380 --> 00:09:47.140
어떤 옵션을 고객에게 더 빨리 도착할 수도 있고, 어떤 옵션을 비용이 더 저렴할 수도 있습니다.

00:09:47.360 --> 00:09:52.600
모든 고객이 비용보다 속도를 중요하게 생각하는 것은 아니면, 비즈니스 방식은 저마다 다르기 때문에 시스템은 이를 스스로 판단하지 않습니다.

00:09:52.600 --> 00:09:56.400
고객이 긴급 배송비를 지불했다면, 더 빠른 경로를 선택하는 것이 합리적입니다.

00:09:56.540 --> 00:10:00.000
다른 고객은 더 긴 배송 시간을 감수하고, 낮은 요금을 선호할 수도 있습니다.

00:10:00.220 --> 00:10:01.960
결정은 여전히 사람이 내리는 것입니다.

00:10:02.180 --> 00:10:07.440
운송관리는 합의된 선택지와 예상 비용을 제공하며, 어떤 상충관계가 효과적일지는 비즈니스 측에서 결정합니다.

00:10:07.640 --> 00:10:10.060
내장된 모듈이 실제로 수행하는 기능은 다음과 같습니다.

00:10:10.360 --> 00:10:14.740
운임 정보는 귀사가 다이나믹스 365에 입력하고, 유지관리하는 운임표에서 가져옵니다.

00:10:14.920 --> 00:10:18.620
이 표들을 합의된 운송업체 가격과 경로 규칙이 저장된 기록이라고 생각하세요.

00:10:18.620 --> 00:10:23.620
특정 서비스와 구간에 대한 가격을 협상했다면, 해당 정보가 시스템에 저장되어 계획 수립을 지원합니다.

00:10:23.760 --> 00:10:26.480
이는 귀하의 운임이 알려진 계약을 따를 때 효과적으로 작동합니다.

00:10:26.660 --> 00:10:31.780
예를 들어, 몇몇 정기 운송업체와 협력하고, 익숙한 경로를 운영하며, 계약 변경 시 가격을 업데이트하는 경우입니다.

00:10:31.940 --> 00:10:35.560
운송계획자는 과거 이메일을 뒤질 필요 없이 이미 기록된 운임을 사용합니다.

00:10:35.760 --> 00:10:37.720
하지만 많은 분이 오해하는 부분이 있습니다.

00:10:38.040 --> 00:10:41.800
내장된 모듈은 모든 운송업체와 연결된 실시간 쇼핑 사이트처럼 작동하지 않습니다.

00:10:41.800 --> 00:10:46.660
실시간 피드에서 새로운 가격을 자동으로 가져와 광범위한 네트워크를 실시간으로 비교하지는 않습니다.

00:10:46.820 --> 00:10:52.620
귀사가 다중운송사 요금 비교, 실시간 예약 링크 또는 상세한 배송상태 업데이트가 필요하다면 일반적으로 타사 시스템을 연결합니다.

00:10:52.780 --> 00:10:54.780
이는 운송관리 시스템의 결함이 아닙니다.

00:10:54.960 --> 00:10:57.100
그만큼 각자의 역할이 명확하기 때문입니다.

00:10:57.300 --> 00:11:04.180
이 도구들은 귀사가 유지관리하는 운송사, 경로 및 요금 정보를 사용하여 공급망 관리 내의 구조화된 운송계획을 처리합니다.

00:11:04.380 --> 00:11:06.900
또한 소비자용 택배 추적 사이트도 아닙니다.

00:11:06.900 --> 00:11:12.820
운송장 번호를 입력하고 차량 아이콘이 도로를 따라 이동하는 것을 지켜보는 지도처럼 사용하지는 않습니다.

00:11:13.020 --> 00:11:16.340
이 모듈은 배송 전후의 비즈니스 운송 결정에 중점을 둡니다.

00:11:16.540 --> 00:11:21.860
어떤 상품을 함께 보낼지, 어떤 운송사가 담당할지, 어떤 경로를 택할지, 비용은 얼마가 들지 등을 결정합니다.

00:11:22.060 --> 00:11:26.100
일단 계획이 선택되면 창고팀과 운송팀이 이를 실행해 옮겨야 합니다.

00:11:26.340 --> 00:11:31.500
창고문에서 고객문 앞까지 운송계획은 실질적인 배송으로 이어질 때만 의미가 있습니다.

00:11:31.800 --> 00:11:35.260
출고 주문의 경우 흐름은 대개 고객의 구매와 함께 시작됩니다.

00:11:35.260 --> 00:11:39.720
판매 주문은 고객이 무엇을 원하는지, 어디로 보내야 하는지, 언제 도착해야 하는지를 알려줍니다.

00:11:39.860 --> 00:11:44.220
그 주문은 배송이 되고, 배송은 같은 경로를 이동하는 다른 상품들과 함께 계획된 적재물에 포함됩니다.

00:11:44.380 --> 00:11:46.080
그 다음 창고팀이 업무를 이어받습니다.

00:11:46.320 --> 00:11:49.980
작업자는 보관소에서 품목을 픽킹하고 포장하여 적절한 상차 구역으로 가져옵니다.

00:11:50.140 --> 00:11:55.060
배송이 적재물에 포함되어 있으므로 팀은 어떤 상품을 함께 보내야 하고, 어떤 운송사가 수거할지 확인할 수 있습니다.

00:11:55.340 --> 00:11:59.940
차량이 도착하면 상품은 창고에서 운송사로 이동하고, 운송사는 이를 고객에게 전달합니다.

00:11:59.940 --> 00:12:04.660
모든 단계가 하나의 이동 기록으로 연결됩니다. 평범하게 들리겠지만 과거의 방식을 떠올려보세요.

00:12:04.900 --> 00:12:07.100
피커는 인쇄된 주문서를 보고 작업했을지도 모릅니다.

00:12:07.320 --> 00:12:13.240
운송 기획자는 별도의 목록을 가지고, 상차 구역 담당자는 이메일을 뒤져 어떤 운송사가 어떤 팔레트를 가져가야 할지 확인했을 것입니다.

00:12:13.440 --> 00:12:16.460
세부사항 하나라도 바뀌면 모두가 업데이트된 버전을 공유받아야 했습니다.

00:12:16.760 --> 00:12:20.040
운송관리를 도입하면 적재물을 통해 팀들이 하나의 기록을 공유하게 됩니다.

00:12:20.300 --> 00:12:22.660
창고팀은 적재물과 연결된 품목을 확인하고,

00:12:23.120 --> 00:12:24.720
기획자는 배송 상세 정보를 보며,

00:12:24.720 --> 00:12:28.060
픽업 담당자는 계획된 운송사와 서비스를 확인할 수 있습니다.

00:12:28.260 --> 00:12:33.900
종이 목록을 돌려보는 대신 사람들은 동일한 주문 및 배송 정보에 연결된 데이터를 바탕으로 작업합니다.

00:12:34.120 --> 00:12:35.380
간단한 예를 들어보겠습니다.

00:12:35.820 --> 00:12:39.120
한 창고에 동일한 배송 지역 내 여러 고객의 주문이 들어왔습니다.

00:12:39.360 --> 00:12:42.300
한 고객은 청소 용품을, 다른 고객은 종이 제품을,

00:12:42.660 --> 00:12:44.740
세 번째 고객은 소량의 장비를 주문했습니다.

00:12:45.060 --> 00:12:46.520
각 주문은 피킹과 포장이 필요하지만,

00:12:46.880 --> 00:12:49.320
운송팀이 이를 완전히 별도의 운송건으로 처리할 필요는 없습니다.

00:12:49.640 --> 00:12:51.960
그들은 배송건들을 하나의 계획된 적재물로 배정합니다.

00:12:51.960 --> 00:12:56.140
창고 직원은 각 주문을 피킹하고 올바르게 포장한 뒤, 하역 구역으로 보낼 준비를 합니다.

00:12:56.320 --> 00:12:59.420
적재 기록을 통해 이 모든 배송물이 함께 운송됨을 알 수 있습니다.

00:12:59.660 --> 00:13:03.620
운송업체가 도착하면 팀은 마지막 순간에 낮게 팔레트를 기사와 맞추려 애쓰는 대신,

00:13:04.060 --> 00:13:06.080
계획된 하나의 이동 단위로 상품을 전달합니다.

00:13:06.300 --> 00:13:08.620
고객은 여전히 자신의 주문품을 그대로 받습니다.

00:13:08.880 --> 00:13:12.600
하지만 그 이면에서 기업은 해당 배송을 더 큰 이동 계획의 일부로 처리했습니다.

00:13:12.920 --> 00:13:17.460
이러한 연계는 창고팀이 운송팀보다 앞서 작업하거나 뒤늦게 도착한 지시를 기다리지 않고,

00:13:17.980 --> 00:13:19.280
서로 협력할 수 있도록 돕습니다.

00:13:19.280 --> 00:13:22.940
입고 운송도 방향만 반대일 뿐 같은 연결 개념을 따릅니다.

00:13:23.180 --> 00:13:27.000
구매 주문서는 귀사가 공급업체로부터 상품을 받을 예정임을 알려줍니다.

00:13:27.160 --> 00:13:33.220
귀사가 운송을 주선할 때, 계획된 입고 적재는 상품이 창고에 도착하기 전 운송 과정과 품목을 연결합니다.

00:13:33.440 --> 00:13:37.580
공급업체가 발송하면 운송업체가 현장으로 가져오고, 창고에서 일을 수령합니다.

00:13:37.780 --> 00:13:40.840
입고 담당 직원은 무엇이 도착할지 미리 알고 준비할 수 있습니다.

00:13:41.080 --> 00:13:46.200
이들은 트럭이 예고 없이 나타나 누군가 팔레트가 어떤 구매 주문서에 속하는지 확인하느라 애쓰는 것보다 훨씬 명확하게,

00:13:46.200 --> 00:13:49.040
계획된 적재물과 도크에 도착한 상품을 대조할 수 있습니다.

00:13:49.220 --> 00:13:51.040
이동 주문도의 절차에 포함됩니다.

00:13:51.280 --> 00:13:54.780
한 회사 사업장에서 재고를 내보내면 다른 사업장에서 일을 수령합니다.

00:13:54.980 --> 00:14:00.640
첫 번째 창고에서 품목을 준비해 발송하면, 두 번째 창고는 같은 품목을 예상하고 이를 재고로 입고합니다.

00:14:00.880 --> 00:14:06.120
그 여정의 끝에 외부 고객은 없지만, 회사 내부의 두 지점 간에도 명확한 인계 과정은 여전히 필요합니다.

00:14:06.360 --> 00:14:10.140
적재 정보는 하나의 계획된 이동을 중심으로 발송 및 수령 작업을 연결합니다.

00:14:10.140 --> 00:14:13.540
고객의 배송 선택 사항도 배송 결정과 계속 연결되어 있습니다.

00:14:13.800 --> 00:14:19.380
고객이 빠른 상품 수령을 원해 계획자가 더 빠른 운송 서비스를 선택하면, 그 선택은 해당 배송과 연결됩니다.

00:14:19.540 --> 00:14:23.800
배송 기한에 여유가 있어 더 저렴한 서비스를 이용할 경우에도 그 선택은 연결됩니다.

00:14:24.000 --> 00:14:28.140
담당자는 배송 비용을 발생시킨 경로와 운송업체 선택까지 거슬러 올라가 추적할 수 있습니다.

00:14:28.380 --> 00:14:32.620
차량이 도크를 떠나 상품이 안전하게 도착했더라도, 작업이 완전히 끝난 것은 아닙니다.

00:14:32.800 --> 00:14:36.380
이후 운송업체가 운임 청구서를 보내오면 누군가 이를 확인해야 합니다.

00:14:36.380 --> 00:14:41.900
운송 비용 및 배조 작업입니다. 상품이 창고를 떠나 배송이 완료되었을 수도 있습니다.

00:14:42.180 --> 00:14:44.100
그때 운송업체의 송장이 도착합니다.

00:14:44.360 --> 00:14:54.460
청구서 금액이 회사에서 미리 계획한 운송업체, 경로, 서비스, 적재 세부 정보 및 예상 운송 요금과 같은 운송 선택 사항과 연결되어야 함으로 송장 확인이 필요합니다.

00:14:54.660 --> 00:15:00.060
계획 단계에서 다이나믹스 365는 회사의 요금 정보를 바탕으로 예상 운송 비용을 계산할 수 있습니다.

00:15:00.360 --> 00:15:04.320
이 예상 금액은 운송업체가 대금을 청구하기 전 기업의 기준점을 제공합니다.

00:15:04.320 --> 00:15:06.860
나중에 운송업체는 화물 청구서를 보냅니다.

00:15:07.060 --> 00:15:12.040
운송 정산이란 해당 청구서를 시스템에 이미 기록된 요금 및 배송 세부 정보와 비교하는 것을 의미합니다.

00:15:12.220 --> 00:15:17.400
쉽게 말해 기업은 운송업체가 실제로 상품을 운송한 서비스에 대해 기업이 예상한 만큼의 비용을 청구했는지 확인합니다.

00:15:17.580 --> 00:15:19.940
계획상 비용이 500달러였다고 가정해봅시다.

00:15:20.160 --> 00:15:23.940
운송업체의 청구서에도 500달러가 표시되어 있고 배송 세부 정보가 일치합니다.

00:15:24.180 --> 00:15:28.260
계획된 기록과 청구서가 일치하므로 해당 청구서는 검토 과정을 순조롭게 통과합니다.

00:15:28.500 --> 00:15:31.040
하지만 청구서가 항상 계획과 일치하는 것은 아닙니다.

00:15:31.040 --> 00:15:37.900
요금표가 잘못되었거나 운송업체가 다른 서비스에 대해 청구했거나 계획 이후 화물이 변경되어 추가 비용에 대한 설명이 필요할 수 있습니다.

00:15:38.080 --> 00:15:44.680
연결된 기록이 없으면 재무부서는 청구서 번호와 금액만 보고 창고 및 운송팀에 무슨 일이 있었는지 일일이 문외하며 시간을 낭비할 수 있습니다.

00:15:44.900 --> 00:15:48.080
운송관리는 운송결정과 검토 과정을 서로 연결해줍니다.

00:15:48.300 --> 00:15:52.680
규칙을 사용하여 운송업체의 청구서를 예상 금액 및 계획된 배송 정보와 비교할 수 있습니다.

00:15:52.940 --> 00:15:56.640
세부 정보가 기업의 허용 규칙 내에 있으면 청구서 처리가 진행됩니다.

00:15:56.640 --> 00:16:00.620
세부 정보가 맞지 않으면 시스템은 차액을 검토 담당자에게 전달합니다.

00:16:00.800 --> 00:16:03.940
즉 모든 화물 비용을 무조건 승인하지 않아도 된다는 뜻입니다.

00:16:04.180 --> 00:16:10.980
운송기획자가 운송업체가 다른 서비스를 사용했음을 확인해야 하거나 재무 담당자가 추가 비용이 발생한 이유를 물어봐야 할 수도 있습니다.

00:16:11.220 --> 00:16:14.100
핵심은 모든 불일치가 잘못되었다고 가정하는 것이 아닙니다.

00:16:14.280 --> 00:16:16.560
핵심은 대금 지급 전에 불일치를 발견하는 것입니다.

00:16:16.760 --> 00:16:19.540
이렇게 하면 운영부서와 재무부서가 동일한 배송건을 중심으로 협업하게 됩니다.

00:16:19.760 --> 00:16:21.820
운송팀은 운송업체와 서비스를 선택합니다.

00:16:22.040 --> 00:16:23.880
그 선택으로 예상 비용이 발생합니다.

00:16:23.880 --> 00:16:29.040
창고에서 상품을 발송하면 재무부서는 나중에 들어온 청구서를 회사가 계획했던 기록과 대조합니다.

00:16:29.220 --> 00:16:32.620
각 팀이 보는 부분은 다르지만 모두 서로 연결된 정보를 확인하는 것입니다.

00:16:32.820 --> 00:16:35.400
하지만 내장된 프로세스에는 명확한 범위가 있습니다.

00:16:35.660 --> 00:16:40.920
대규모의 고도로 자동화된 화물감사가 필요한 기업은 종종 타사 운송관리 시스템을 추가합니다.

00:16:41.180 --> 00:16:45.560
그러한 도구는 더 깊은 운송업체 연결과 더욱 자동화된 검사 규칙을 제공할 수 있습니다.

00:16:45.820 --> 00:16:49.440
내장 모듈은 공급망 관리 내에서 계획 비용과 정산 작업을 처리하며

00:16:49.440 --> 00:16:53.680
비즈니스 요구사항이 늘어나면 다른 시스템으로 그 기능을 확장할 수 있습니다.

00:16:53.920 --> 00:16:57.040
이러한 구성 요소를 모두 조합해보면 전체적인 그림이 드러나며

00:16:57.040 --> 00:16:59.880
어디에 적합하고 무엇을 할 수 없는지 알 수 있습니다.

00:17:00.140 --> 00:17:02.540
그렇다면 운송관리는 실제로 어디에 위치할까요?

00:17:02.720 --> 00:17:06.880
파이낸스 엔드 오퍼레이션즈 앱에서 실행되는 다이나믹스 365 서플라이 체인 매니지먼트 내에 있습니다.

00:17:07.140 --> 00:17:08.680
그곳이 바로 운송관리의 본거지입니다.

00:17:08.900 --> 00:17:10.420
누구에게 적합한지 알려드리겠습니다.

00:17:10.420 --> 00:17:14.580
입고, 출고, 사업장 간 재고 이송을 구조적으로 계획해야 하며

00:17:14.580 --> 00:17:19.140
자체 운송업체 기록, 유율표, 적재 규칙을 사용하는 기업들입니다.

00:17:19.280 --> 00:17:21.680
이제 흔히 혼동하는 부분을 명확히 정리해보겠습니다.

00:17:22.000 --> 00:17:23.480
비즈니스 센트럴은 다릅니다.

00:17:23.700 --> 00:17:26.980
비즈니스 센트럴에는 이러한 내장형 운송관리 모듈이 포함되어 있지 않습니다.

00:17:27.180 --> 00:17:29.740
비즈니스 센트럴을 사용 중인데 운송계획이 필요하다면

00:17:29.740 --> 00:17:31.620
타사 운송관리 시스템을 고려해야 합니다.

00:17:31.820 --> 00:17:32.760
그것이 경계입니다.

00:17:33.000 --> 00:17:34.900
반대쪽 경계도 명확히 해두겠습니다.

00:17:34.900 --> 00:17:40.080
내장형 모듈이 모든 운송업체 포털, 실시간 교통 서비스, 고급 추적 도구를 대체하지는 않습니다.

00:17:40.220 --> 00:17:43.620
기업이 여러 운송업체의 실시간 유율, 더폭 넓은 운송업체 선택,

00:17:43.920 --> 00:17:47.240
상품이 출고된 후에 신층 추적이 필요할 때는 타사 TMS를 연결합니다.

00:17:47.420 --> 00:17:49.320
그런 도구들이 외부 활동을 처리합니다.

00:17:49.500 --> 00:17:51.160
오피스 빌딩을 다시 떠올려 보세요.

00:17:51.420 --> 00:17:53.880
운송관리는 그 건물 내부의 운송 데스크와 같습니다.

00:17:54.260 --> 00:17:56.820
주문, 창고, 업무, 재무와 연결됩니다.

00:17:57.020 --> 00:17:59.260
회사의 자체 운송 계획을 하나로 통합합니다.

00:17:59.260 --> 00:18:02.620
외부 운송업체 도구는 그 데스크 너머의 활동을 처리할 수 있습니다.

00:18:02.820 --> 00:18:05.340
두 개의 서로 다른 계층이 함께 작동하는 것입니다.

00:18:05.660 --> 00:18:06.360
결론입니다.

00:18:06.620 --> 00:18:07.900
다음, 지식정보입니다.

00:18:08.100 --> 00:18:10.300
가장 간단하게 생각하는 방법은 다음과 같습니다.

00:18:10.640 --> 00:18:13.740
운송관리는 비즈니스 주문을 상품의 계획된 이동으로 변환합니다.

00:18:13.940 --> 00:18:17.280
그런 다음 해당 이동을 회사가 나중에 확인하는 운송 비용과 연결합니다.

00:18:17.520 --> 00:18:18.740
그것이 전체 루프입니다.

00:18:19.000 --> 00:18:21.320
즐겨 사용하는 팟캐스트 플랫폼에서 구독하세요.

00:18:21.560 --> 00:18:26.020
이 지식정보를 다이나믹스 365 서플라이 체인 매니지먼트를 배우는 사람과 공유하세요.

00:18:26.260 --> 00:18:28.760
다음으로 창고 및 재고 관련 에피소드를 살펴보세요.

00:18:28.760 --> 00:18:32.120
모든 적재는 결국 창고문 뒤에 있는 재고에 달려있으니까요.