WEBVTT

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

00:00:04.220 --> 00:00:06.020
진행을 맡은 미르코 피터스입니다

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

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

00:00:10.880 --> 00:00:13.720
바로 다이나믹스 365 트랜스포테이션 매니지먼트입니다

00:00:13.720 --> 00:00:14.880
문제가 무엇일까요?

00:00:15.080 --> 00:00:16.800
고객이 주문을 하면 재고는 창고에 쌓이고

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

00:00:19.680 --> 00:00:22.240
나중에 누군가의 책상 위로 화물청구서가 전달됩니다

00:00:22.240 --> 00:00:25.280
수년간의 과정들은 각각 별도의 스프레드 시트, 전화통화, 요금표

00:00:25.280 --> 00:00:26.820
그리고 팀 간의 업무 인계로 이루어졌습니다

00:00:26.820 --> 00:00:28.780
아 그리고 거기서 공백이 발생하죠

00:00:28.780 --> 00:00:31.540
운송계획이 나오기도 전에 창고에서 상품을 미리 준비할 수도 있습니다

00:00:31.540 --> 00:00:34.700
재무팀은 누가 무엇을 지불하기로 합의했는지 모르는 상태에서 청구서를 볼 수도 있고요

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

00:00:37.000 --> 00:00:41.440
쉽게 말해 다이나믹스 365 서플라이 체인 매니지먼트 내의 운송 데스크라고 할 수 있습니다

00:00:41.440 --> 00:00:44.620
창고 출입구, 공급업체, 고객, 운송업체를 하나로 연결해줍니다

00:00:44.620 --> 00:00:48.560
이를 통해 적재를 계획하고 경로와 요금을 선택하며 상품을 발송하고 운송비를 점검합니다

00:00:48.560 --> 00:00:53.840
이번 에피소드가 끝날 때 찜이 면이 모든 조각이 어떻게 맞춰져 업무를 더 수월하게 만드는지 알게 될 것입니다

00:00:53.840 --> 00:00:57.720
운송관리가 존재하는 이유입니다

00:00:57.720 --> 00:00:59.560
기본적인 사실부터 짚고 넘어가죠

00:01:00.140 --> 00:01:04.160
판매 주문이 화면에 떠있다고 해서 물리적 상품이 저절로 움직이지는 않습니다

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

00:01:07.820 --> 00:01:14.160
누군가는 상품의 출발지와 목적지, 차지하는 공간, 출발시간, 그리고 운송비용을 파악해야 합니다

00:01:14.160 --> 00:01:17.980
상자 하나가 고객 한 명에게 전달되는 상황을 떠올리면 단순하게 들립니다

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

00:01:21.540 --> 00:01:26.300
여러 공급업체로부터 물품을 받으며 동시에 자사 사업장 간의 재고를 이동시킵니다

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

00:01:30.120 --> 00:01:33.280
공유 시스템이 없으면 각 팀은 자신의 부분만 보게 됩니다

00:01:33.280 --> 00:01:35.100
영업팀은 고객 주문만 봅니다

00:01:35.100 --> 00:01:37.200
구매팀은 공급업체 주문만 봅니다

00:01:37.200 --> 00:01:40.960
창고 직원은 피킹, 포장, 입고, 정리해야 할 품목만 봅니다

00:01:40.960 --> 00:01:45.540
운송팀은 다른 모든 팀이 자신의 역할을 마친 후에야 이동해야 할 물품 목록을 전달받는 경우가 많습니다

00:01:45.540 --> 00:01:47.540
바로 여기서 지연과 혼란이 시작됩니다

00:01:47.540 --> 00:01:49.080
구체적인 예를 들어볼까요?

00:01:49.240 --> 00:01:52.640
창고의 동일한 도시로 향하는 10건의 고객 주문이 준비되어 있다고 가정해봅시다

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

00:01:54.860 --> 00:01:57.180
회사는 짐이 덜 찬 상태로 여러 번 운송을 준비하거나

00:01:57.180 --> 00:02:00.600
창고에서 어떤 물품을 실어야 할지 모르는 상태에서 운송업체가 도착할 수도 있습니다

00:02:00.600 --> 00:02:03.200
상품은 준비되었지만 이동 계획은 없는 셈이죠

00:02:03.200 --> 00:02:08.700
그래서 운송관리는 다이나믹스 365 서플라이 체인 매니지먼트 내에서 이러한 이동에 필요한 공간을 제공합니다

00:02:08.700 --> 00:02:13.780
단순히 운송장 번호를 입력하고 지도에서 택배의 이동을 확인하는 소비자용 배송 앱과는 다릅니다

00:02:13.780 --> 00:02:17.480
대신 연결된 플랫폼 내에 이미 존재하는 비즈니스 기록을 활용합니다

00:02:17.480 --> 00:02:20.040
주문이 발생하면 상품 이동의 필요성이 생깁니다

00:02:20.040 --> 00:02:21.840
창고 작업은 상품을 준비합니다

00:02:21.840 --> 00:02:25.300
운송관리는 해당 상품이 위치 간에 이동하는 방법을 계획합니다

00:02:25.300 --> 00:02:27.980
회사 건물의 운송 데스크와 같다고 생각하면 됩니다

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

00:02:30.480 --> 00:02:33.560
구매팀은 공급업체가 상품을 보낼 것이라는 소식을 전달합니다

00:02:33.560 --> 00:02:36.060
창고는 실제 재고와 상하차 도크를 제공합니다

00:02:36.060 --> 00:02:39.480
운송 데스크는 이러한 요청을 회사의 운송 계획과 연결합니다

00:02:39.480 --> 00:02:41.100
두 가지 주요 방향이 있습니다

00:02:41.100 --> 00:02:44.220
인바운드 운송은 상품이 사업장 안으로 들어오는 것을 의미합니다

00:02:44.220 --> 00:02:47.540
공급업체의 품목을 주문했고 그 품목이 창고에 도착해야 합니다

00:02:47.540 --> 00:02:50.940
공급업체가 운송을 관리할 때도 있고 기사가 직접 마련할 때도 있습니다

00:02:50.940 --> 00:02:55.420
어떤 경우 든 상품을 올바른 장소로 보내고 도착 시 수령하기 위한 명확한 계획이 필요합니다

00:02:55.420 --> 00:02:58.660
아웃바운드 운송은 상품이 사업장 밖으로 나가는 것을 의미합니다

00:02:58.660 --> 00:03:00.320
고객이 제품을 주문했습니다

00:03:00.320 --> 00:03:04.440
창고에서 일을 준비하고 운송업체 나 회사 차량이 고객에게 전달합니다

00:03:04.440 --> 00:03:07.100
두 흐름 모두 이동을 다루지만 출발점은 다릅니다

00:03:07.100 --> 00:03:09.760
인바운드는 구매 주문과 공급업체에서 시작됩니다

00:03:09.760 --> 00:03:12.380
아웃바운드는 판매 주문과 고객에서 시작됩니다

00:03:12.380 --> 00:03:15.700
초보자들이 종종 놓치는 세 번째 유형인 이전 주문이 있습니다

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

00:03:18.720 --> 00:03:22.380
한 창고에 재고가 너무 많고 다른 창고에 재고가 필요할 때 발생합니다

00:03:22.380 --> 00:03:26.420
고객 구매는 포함되지 않지만 물리적 상품은 여전히 운송이 필요합니다

00:03:26.420 --> 00:03:30.580
365 운송 관리에서 이전 주문은 아웃바운드 시나리오에 속하며

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

00:03:32.740 --> 00:03:35.360
상하차 도크를 떠올려보면 이해가 됩니다

00:03:35.360 --> 00:03:38.620
팔레트가 고객에게 가든 다른 회사 창고로 가든

00:03:38.620 --> 00:03:42.060
누군가는 차량을 수배하고 공간을 확보하며

00:03:42.060 --> 00:03:44.040
같은 문을 통해 내보내야 합니다

00:03:44.040 --> 00:03:45.840
즉, 이러한 연결된 접근 방식은

00:03:45.840 --> 00:03:49.740
별도의 목록과 전화통화로 이루어지던 기존 방식을 공유된 정보로 대체합니다

00:03:49.740 --> 00:03:52.420
주문은 시스템에 무엇을 이동해야 하는지 알려줍니다

00:03:52.420 --> 00:03:54.080
창고는 품목을 준비합니다

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

00:03:56.960 --> 00:04:00.980
상품 이동이 필요하면 시스템은 먼저 실행 가능한 배송 계획이 필요합니다

00:04:00.980 --> 00:04:02.160
적재 계획 수립

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

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

00:04:07.660 --> 00:04:09.060
적재 계획 세우기

00:04:09.060 --> 00:04:12.320
주문이나 선적 중 하나를 기준으로 운송 계획을 시작할 수 있습니다

00:04:12.320 --> 00:04:14.380
저는 M365 위 미르코 피터스입니다

00:04:14.380 --> 00:04:16.140
먼저 5회 하나를 확실히 풀어보겠습니다

00:04:16.140 --> 00:04:18.320
배송 계획은 처음부터 새로 만드는 것이 아닙니다

00:04:18.320 --> 00:04:20.060
이미 보유하고 있는 기록에서 시작됩니다

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

00:04:22.120 --> 00:04:24.680
구매 주문서에는 공급업체가 보내야 할 품목이 나열되어 있습니다

00:04:24.680 --> 00:04:27.640
출하, 쉬먼트는 그러한 품목을 더 구체적인 배송 기록으로 그룹화하여

00:04:27.640 --> 00:04:29.100
다른 항목과 결합할 수 있도록 준비합니다

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

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

00:04:33.000 --> 00:04:35.860
일부 팀은 주문 라인을 직접 확인하며 일찍 계획을 세웁니다

00:04:35.860 --> 00:04:38.980
다른 팀은 먼저 출하를 생성한 다음 무엇을 함께 보낼지 결정합니다

00:04:38.980 --> 00:04:40.940
두 경로 모두 같은 질문으로 이어집니다

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

00:04:42.780 --> 00:04:44.380
가장 간단한 정의를 알려드리겠습니다

00:04:44.380 --> 00:04:47.520
로드, 로드는 계획된 상품 이동을 위한 디지털 기록입니다

00:04:47.520 --> 00:04:52.460
트럭 한 대, 트레일러 한 대, 컨테이너 하나 또는 함께 이동하는 출하물의 집합으로 생각할 수 있습니다

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

00:04:56.460 --> 00:04:58.740
자, 많은 사람이 잘못 알고 있는 부분이 있습니다

00:04:58.740 --> 00:05:01.580
로드가 모든 항목이 하나의 물리적 상자에 들어간다는 의미는 아닙니다

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

00:05:04.360 --> 00:05:06.740
여러 고객의 출하물이 하나의 트럭을 공유할 수 있습니다

00:05:06.740 --> 00:05:09.260
대형 주문은 트레일러 하나를 가득 채울 수도 있습니다

00:05:09.260 --> 00:05:13.540
공급업체로부터 도착하는 컨테이너도 창고에 상품이 입고되기 전에 로드가 될 수 있습니다

00:05:13.540 --> 00:05:16.840
핵심은 각 주문을 개별적인 운송으로 처리하는 것을 멈추는 것입니다

00:05:16.840 --> 00:05:20.240
유통업체의 금요일 배송 예정인 고객 주문이 6건 있다고 가정해보겠습니다

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

00:05:23.860 --> 00:05:27.540
반쯤 빈 차량 6대를 보내면 공간이 낭비되고 6개의 별도 운송 작업이 발생합니다

00:05:28.100 --> 00:05:31.120
대신 팀은 호환되는 출하물을 하나의 로드로 그룹화할 수 있습니다

00:05:31.120 --> 00:05:34.020
호환된다는 것은 함께 이동하는 데 무리가 없다는 뜻입니다

00:05:34.020 --> 00:05:39.620
같은 창고에서 출발하고 비슷한 시기에 이동해야 하며 차량 제한 내에 적합하고 배송 규칙을 따라야 합니다

00:05:39.620 --> 00:05:43.640
시스템은 누군가 스프레드 시트에서 패턴을 찾지 않아도 되도록 이러한 기록을 통합합니다

00:05:43.640 --> 00:05:45.800
이제 해당 그룹은 공유된 계획을 가지게 됩니다

00:05:45.800 --> 00:05:48.040
창고는 로드에 포함된 항목을 확인할 수 있습니다

00:05:48.040 --> 00:05:50.600
운송 계획 담당자는 총 공간과 무게를 확인할 수 있습니다

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

00:05:53.800 --> 00:05:55.300
그런데 중요한 점이 있습니다

00:05:55.300 --> 00:05:58.080
상품을 그룹화하는 것은 단순히 더 많은 항목을 합치는 것만이 아닙니다

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

00:06:00.740 --> 00:06:02.600
컨테이너도 그에 따른 규칙이 있습니다

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

00:06:04.800 --> 00:06:07.800
로드가 화면상으로는 괜찮아 보여도 상차 구역에서 문제가 발생할 수 있습니다

00:06:07.800 --> 00:06:11.180
다이나믹스 365는 이를 방지하기 위해 로드 템플릿을 사용합니다

00:06:11.180 --> 00:06:13.540
로드 템플릿을 특정 유형의 차량이나 컨테이너에 대한

00:06:13.540 --> 00:06:15.680
재사용 가능한 제한 설정 세트로 생각하십시오

00:06:15.680 --> 00:06:20.120
소형 배달 트럭용, 대형 트레일러용, 운송 컨테이너용 템플릿을 각각 만드십시오

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

00:06:24.600 --> 00:06:27.440
템플릿은 화물을 채우기 전에 미리 형태를 잡아줍니다

00:06:27.440 --> 00:06:29.840
따라서 배송품이 너무 무겁거나 공간을 너무 많이 차지하면

00:06:29.840 --> 00:06:32.260
플래너는 해당 화물에 적합하지 않다는 것을 알 수 있습니다

00:06:32.260 --> 00:06:35.040
그 해결책은 두 번째 차량을 쓰거나 다른 템플릿을 선택하거나

00:06:35.040 --> 00:06:36.900
배송품을 다르게 그룹화하는 것일 수 있습니다

00:06:36.900 --> 00:06:39.060
소프트웨어가 직접 팔레트를 옮기지는 않지만

00:06:39.060 --> 00:06:41.920
실제 작업 전에 팀에게 더 명확한 계획을 제시합니다

00:06:41.920 --> 00:06:45.040
내장된 방식 중 하나는 용량 기반 화물 구성입니다

00:06:45.040 --> 00:06:47.760
말은 복잡해 보이지만 실제로는 간단합니다

00:06:47.760 --> 00:06:49.800
시스템이 화물을 구성하거나 제한할 때

00:06:49.800 --> 00:06:53.280
사용자가 설정한 템플릿의 최대 높이와 무게를 활용한다는 뜻입니다

00:06:53.280 --> 00:06:56.680
쉽게 말해 물품이 설정된 제한 범위 내에 들어오는지 확인하는 것입니다

00:06:56.680 --> 00:06:58.440
그 값들이 고정된 것은 아닙니다

00:06:58.440 --> 00:07:01.140
현장 상황이 바뀌면 플래너가 이를 재설정할 수 있습니다

00:07:01.140 --> 00:07:02.720
운송사가 다른 트레일러를 보낼 수도 있고

00:07:02.720 --> 00:07:04.740
운송 경로에 따라 높이 제한이 달라질 수도 있습니다

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

00:07:06.460 --> 00:07:09.520
재설정 기능은 전체를 다시 만들 필요 없이 예외 상황을 처리합니다

00:07:09.520 --> 00:07:11.660
다시 6개의 고객 주문으로 돌아가 봅시다

00:07:11.660 --> 00:07:14.400
각 주문은 트럭의 15% 정도를 차지할 수 있습니다

00:07:14.400 --> 00:07:17.620
따로 계획하면 6대의 차량을 거의 비운 채로 보낼 수도 있습니다

00:07:17.620 --> 00:07:19.300
하나의 화물로 묶으면 동일한 주문들로

00:07:19.300 --> 00:07:21.420
트럭 한 대를 거의 채우고도 여유 공간이 남을 수 있습니다

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

00:07:23.600 --> 00:07:25.540
이 개념은 양방향 모두에 적용됩니다

00:07:25.540 --> 00:07:29.000
입고 계획 시에는 공급업체로부터 오는 품목을 중심으로 화물을 만듭니다

00:07:29.000 --> 00:07:31.020
운송 계획이 예상 입고와 연결되어

00:07:31.020 --> 00:07:33.560
창고는 무엇이 도착할지 미리 알고 준비합니다

00:07:33.560 --> 00:07:35.640
배송이 도착했을 때야 알게 되는 대신

00:07:35.640 --> 00:07:38.460
입고팀은 이미 계획된 기록을 가지고 있게 됩니다

00:07:38.460 --> 00:07:41.800
출고 계획 시에는 고객에게 보낼 창고 품목을 선택하여

00:07:41.800 --> 00:07:43.260
하나의 화물로 그룹화합니다

00:07:43.260 --> 00:07:44.940
창고는 관련 없는 목록이 아닌

00:07:44.940 --> 00:07:47.560
화물 세부 정보를 바탕으로 상품을 준비합니다

00:07:47.560 --> 00:07:52.220
완성된 화물은 여전히 이동 수단, 운송업체, 그리고 예상 비용이 필요합니다

00:07:52.220 --> 00:07:54.980
경로, 운송업체, 그리고 요금입니다

00:07:54.980 --> 00:07:58.220
이제 화물 정보는 무엇이 함께 이동해야 하는지를 알려줍니다

00:07:58.220 --> 00:08:02.740
다음으로 누가 운송할지, 어떤 서비스를 이용할지, 비용은 얼마가 적당할지 결정해야 합니다

00:08:02.740 --> 00:08:05.500
상품을 옮기는 회사를 운송업체, 캐리어라고 부릅니다

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

00:08:08.440 --> 00:08:12.080
자체 트럭과 운전기사가 있는 경우 라면 회사의 자체 차량 대일 수도 있습니다

00:08:12.080 --> 00:08:15.120
어떤 경우 든 운송업체가 실제 운송을 책임집니다

00:08:15.120 --> 00:08:19.220
트럭이 자사 소유일지라도 계획은 여전히 필요하기 때문에의 구분은 중요합니다

00:08:19.220 --> 00:08:22.540
외부 운송업체를 이용하면 가격과 서비스를 미리 합의합니다

00:08:22.540 --> 00:08:27.880
자체 차량을 이용하더라도, 특히 고객 주문에 배송비가 포함된다면 운송비를 계산해야 할 수 있습니다

00:08:27.880 --> 00:08:31.500
다이나믹스 365 운송관리 기능은 두 가지 상황을 모두 지원합니다

00:08:31.500 --> 00:08:32.940
다음으로 경유지가 있습니다

00:08:32.940 --> 00:08:36.520
경유지는 픽업에서 목적지까지의 계획된 경로와 서비스 선택을 의미합니다

00:08:36.520 --> 00:08:38.520
이는 실무적인 질문들에 답을 제시합니다

00:08:38.520 --> 00:08:40.800
운송업체가 어느 창고에서 물품을 수거합니까?

00:08:40.980 --> 00:08:43.000
어떤 고객 인하 위치가 물품을 수령합니까?

00:08:43.160 --> 00:08:45.080
어떤 운송 서비스가 이동을 담당합니까?

00:08:45.080 --> 00:08:48.560
본사 창고에서 전국에 있는 고객에게 물품을 배송하는 상황을 상상해보십시오

00:08:48.560 --> 00:08:51.840
한 경로는 비용은 저렴하지만 시간이 오래 걸리는 일반 화물 운송을 사용할 수 있습니다

00:08:51.840 --> 00:08:54.880
다른 경로는 더 빠르지만 비용이 많이 드는 서비스를 사용할 수 있습니다

00:08:54.880 --> 00:08:57.760
시작점과 도착점은 같지만 운송 선택이 달라집니다

00:08:57.760 --> 00:08:59.840
요율은 해당 선택에 대한 예상 비용입니다

00:08:59.840 --> 00:09:02.340
마지막 순간에 임의로 입력하는 숫자가 아닙니다

00:09:02.340 --> 00:09:06.440
요율은 운송업체와의 가격 계약을 배송 또는 경로 세부 정보와 결합하여 산출됩니다

00:09:06.440 --> 00:09:10.060
물품의 출발지, 목적지, 사용 서비스, 운송량 등이 포함됩니다

00:09:10.060 --> 00:09:12.480
즉, 경유지는 물품이 어떻게 이동해야 하는지를 알려줍니다

00:09:12.480 --> 00:09:14.780
요율은 지불할 것으로 예상되는 금액을 알려줍니다

00:09:14.780 --> 00:09:16.680
저렴한 경유지는 배송 약속을 얻길 수 있고

00:09:16.680 --> 00:09:20.520
빠른 속도는 주문 대비 비용이 과다할 수 있기 때문에 이 두 개념은 함께 고려해야 합니다

00:09:20.520 --> 00:09:22.820
운송 계획은 단순히 트럭을 찾는 것이 아니라

00:09:22.820 --> 00:09:26.640
고객 약속과 회사의 비용 규칙에 맞는 서비스를 선택하는 것입니다

00:09:26.640 --> 00:09:30.200
다이나믹스 365에는 요율 경로 워크벤치가 포함되어 있습니다

00:09:30.200 --> 00:09:32.760
이름은 거창해 보이지만 목적은 간단합니다

00:09:32.760 --> 00:09:37.260
기획자가 배송을 위한 경로와 요율 선택지를 나란히 두고 비교할 수 있는 공간을 제공합니다

00:09:37.260 --> 00:09:40.260
운송업체별 표를 하나씩 확인하고 별도 파일로 비교하는 대신

00:09:40.260 --> 00:09:43.000
해당 배송 요구사항에 연결된 선택지들을 검토합니다

00:09:43.000 --> 00:09:45.400
한 옵션을 고객에게 더 빨리 도착할 수 있습니다

00:09:45.400 --> 00:09:47.460
다른 옵션을 비용이 더 저렴할 수 있습니다

00:09:47.460 --> 00:09:49.640
모든 고객이 비용보다 속도를 중시하는 것은 아니면

00:09:49.640 --> 00:09:52.840
기업마다 운영 방식이 다르기 때문에 시스템은 이를 미리 알지 못합니다

00:09:52.840 --> 00:09:56.400
고객이 긴급 배송비를 지불했다면 더 빠른 경로가 적합합니다

00:09:56.400 --> 00:09:59.960
다른 고객은 배송이 늦더라도 저렴한 비용이 더 나을 수 있습니다

00:09:59.960 --> 00:10:01.800
결정은 여전히 사람이 내립니다

00:10:01.800 --> 00:10:04.720
운송관리는 합의된 선택지와 예상 비용을 제공하며

00:10:04.720 --> 00:10:07.760
어떤 절충하니 효과적인 지는 귀사의 비즈니스가 결정합니다

00:10:07.760 --> 00:10:10.180
내장 모듈이 실제로 하는 일은 다음과 같습니다

00:10:10.180 --> 00:10:13.100
요율 정보는 귀사가 다이나믹스 365에 입력하고

00:10:13.100 --> 00:10:14.880
유지관리하는 요율표에서 가져옵니다

00:10:14.880 --> 00:10:18.860
이 표들을 합의된 운송업체 가격과 경로규칙이 저장된 기록으로 생각하십시오

00:10:18.860 --> 00:10:21.380
특정 서비스와 노선에 대한 가격을 협상했다면

00:10:21.380 --> 00:10:23.960
그 정보가 시스템에 저장되어 계획 수립을 지원합니다

00:10:23.960 --> 00:10:26.420
요율이 알려진 계약을 따를 때 잘 작동합니다

00:10:26.420 --> 00:10:28.760
예를 들어 몇몇 정기운송업체와 협력하고

00:10:28.760 --> 00:10:31.940
익숙한 경로를 운행하며 계약이 변경될 때 가격을 업데이트합니다

00:10:31.940 --> 00:10:35.520
운송기획자는 과거 이메일을 뒤지는 대신 이미 기록된 요율을 사용합니다

00:10:35.520 --> 00:10:37.820
하지만 많은 사람이 오해하는 부분이 있습니다

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

00:10:41.940 --> 00:10:44.380
실시간 피드에서 최신 가격을 자동으로 가져와

00:10:44.380 --> 00:10:46.620
광범위한 네트워크 전반을 비교하지는 않습니다

00:10:46.620 --> 00:10:49.340
기업의 다중운송 사요금 비교, 실시간 예약 링크,

00:10:49.700 --> 00:10:52.820
상세한 배송현황 업데이트가 필요하다면 보통 파사 시스템을 연결합니다

00:10:52.820 --> 00:10:54.760
이는 운송관리의 결함이 아닙니다

00:10:54.760 --> 00:10:56.980
자신의 역할을 명확히 정의할 뿐입니다

00:10:56.980 --> 00:11:01.340
이 도구들은 귀사가 보유한 운송사, 경로, 요금 정보를 사용하여

00:11:01.340 --> 00:11:04.140
공급망 관리 내의 구조화된 운송계획을 처리합니다

00:11:04.140 --> 00:11:07.000
또한 소비자용 택배 추적 웹사이트도 아닙니다

00:11:07.000 --> 00:11:10.640
운송장 번호를 입력하고 차량 아이콘이 도로를 이동하는 모습을

00:11:10.640 --> 00:11:12.780
지켜보는 지도처럼 사용하지는 않습니다

00:11:12.780 --> 00:11:16.380
이 모듈은 배송 전후의 비즈니스 운송 의사 결정에 집중합니다

00:11:16.380 --> 00:11:19.020
어떤 상품을 함께 운송할지, 어느 운송사가 담당할지,

00:11:19.280 --> 00:11:21.820
어떤 경로를 적용할지, 운송비용은 얼마인지가 중요합니다

00:11:21.820 --> 00:11:26.060
일단 회사가 계획을 선택하면 창고팀과 운송팀이 이를 실행해야 합니다

00:11:26.060 --> 00:11:29.400
창고문에서 고객문까지 운송계획은 사람들이 실제로 이를

00:11:29.400 --> 00:11:31.700
실제 배송으로 전환할 수 있을 때만 의미가 있습니다

00:11:31.700 --> 00:11:35.360
출고 주문의 경우 흐름은 보통 고객이 상품을 구매할 때 시작됩니다

00:11:35.360 --> 00:11:37.920
판매 주문은 고객이 무엇을 원하는지, 어디로 보내야 하는지,

00:11:38.220 --> 00:11:39.740
언제 도착해야 하는지를 기업에 알려줍니다

00:11:39.740 --> 00:11:42.200
해당 주문은 배송이 되고, 이 배송은 같은 경로로 이동하는

00:11:42.200 --> 00:11:44.260
다른 상품들과 함께 계획된 적재물에 합류합니다

00:11:44.260 --> 00:11:46.120
그 다음은 창고가 작업을 이어받습니다

00:11:46.120 --> 00:11:50.020
작업자는 보관소에서 품목을 피킹하고 포장하여 적절한 적재 구역으로 가져옵니다

00:11:50.020 --> 00:11:53.040
배송이 적재물에 속해 있으므로 팀은 어떤 상품이 함께 나가야 하고

00:11:53.040 --> 00:11:55.100
어떤 운송사가 수거할지 확인할 수 있습니다

00:11:55.100 --> 00:11:57.940
차량이 도착하면 상품은 창고에서 운송사로 이동하고

00:11:57.940 --> 00:12:00.020
운송사는 이를 고객에게 전달합니다

00:12:00.020 --> 00:12:02.340
모든 단계는 동일한 이동 기록에 연결됩니다

00:12:02.340 --> 00:12:04.620
평범하게 들리겠지만 과거의 방식을 떠올려보세요

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

00:12:06.820 --> 00:12:09.180
운송기획자는 별도의 목록을 들고 있었을 것입니다

00:12:09.180 --> 00:12:12.500
그리고 적재 구역의 누군가는 어떤 운송사가 어떤 팔레트를 가져가야 하는지 확인하려고

00:12:12.500 --> 00:12:13.480
이메일을 뒤졌을 것입니다

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

00:12:16.540 --> 00:12:20.140
운송관리를 사용하면 적재물을 통해 팀원들이 공유된 기록을 볼 수 있습니다

00:12:20.140 --> 00:12:24.160
창고는 적재물에 연결된 품목을 운송기획자는 배송 상세 정보를

00:12:24.160 --> 00:12:28.040
픽업을 준비하는 담당자는 계획된 운송사와 서비스를 볼 수 있습니다

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

00:12:33.940 --> 00:12:35.500
간단한 예를 들어보겠습니다

00:12:35.500 --> 00:12:38.540
창고의 동일한 배송지역에 있는 여러 고객의 주문이 들어옵니다

00:12:39.120 --> 00:12:42.500
한 고객은 청소용품 상자를 다른 고객은 종이 제품을

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

00:12:44.900 --> 00:12:46.720
모든 주문은 픽힌과 패킹이 필요하지만

00:12:46.720 --> 00:12:49.420
운송팀이 이를 완전히 별개의 이동으로 처리할 필요는 없습니다

00:12:49.420 --> 00:12:52.080
그들은 여러 화물을 하나의 계획된 적재물로 할당합니다

00:12:52.080 --> 00:12:56.140
창고 직원은 각 주문을 픽힌하고 올바르게 포장하여 적재 구역으로 준비합니다

00:12:56.140 --> 00:12:59.440
적재 기록은 이 모든 화물이 함께 이동한다는 것을 알려줍니다

00:12:59.440 --> 00:13:03.340
운송업체가 도착하면 팀은 마지막 순간에 개별 팔레트를 기사에게 맞추려

00:13:03.340 --> 00:13:06.120
애쓰는 대신 하나의 계획된 이동으로 물품을 전달합니다

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

00:13:08.660 --> 00:13:12.660
하지만 보이지 않는 곳에서 기업은 그 배송을 더 큰 이동의 일부로 계획했습니다

00:13:12.660 --> 00:13:15.680
이러한 연결고리는 창고가 운송팀보다 앞서 작업하거나

00:13:15.680 --> 00:13:19.040
늦게 도착하는 지시를 기다리는 대신 함께 협력하도록 돕습니다

00:13:19.040 --> 00:13:21.480
인바운드 운송도 같은 연결된 개념을 따르며

00:13:21.480 --> 00:13:23.280
단지 방향만 반대일 뿐입니다

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

00:13:27.000 --> 00:13:29.920
귀사가 운송을 준비할 때 계획된 인바운드 적재물은

00:13:29.920 --> 00:13:33.280
물품이 창고에 도착하기 전에 들어오는 품목들을 운송과 연결합니다

00:13:33.280 --> 00:13:36.240
공급업체가 화물을 보내고 운송업체가 현장으로 가져오며

00:13:36.240 --> 00:13:37.500
창고가 이를 인수합니다

00:13:37.500 --> 00:13:40.760
입고 담당 직원은 무엇이 도착할지 알고 있기 때문에 미리 준비할 수 있습니다

00:13:40.760 --> 00:13:43.920
그들은 계획된 적재물과 도크에 나타난 물품을 대조할 수 있습니다

00:13:43.920 --> 00:13:46.960
경고 없이 트럭이 나타나 팔레트가 어떤 구매 주문서에 속하는지

00:13:46.960 --> 00:13:49.000
파악하려 애쓰는 상황보다 훨씬 명확합니다

00:13:49.000 --> 00:13:51.420
재고 이전 주문도의 프로세스에 적합합니다

00:13:51.420 --> 00:13:54.720
한 회사 지점에서 재고를 보내고 다른 지점에서 이를 받습니다

00:13:54.720 --> 00:13:57.200
첫 번째 창고가 품목을 준비하여 발송하면

00:13:57.200 --> 00:14:00.820
두 번째 창고는 동일한 품목을 예상하고 재고로 인수합니다

00:14:00.820 --> 00:14:03.000
외부 고객이 여정의 끝에 있지는 않지만

00:14:03.000 --> 00:14:06.100
회사 내 두 지점 간에도 명확한 인계가 필요합니다

00:14:06.100 --> 00:14:10.160
적재물은 하나의 계획된 이동을 중심으로 발송과 수령 작업을 연결합니다

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

00:14:13.580 --> 00:14:15.420
고객이 물품을 빠르게 필요로 하여

00:14:15.420 --> 00:14:17.480
기획자가 더 빠른 운송 서비스를 선택하면

00:14:17.480 --> 00:14:19.340
그 선택은 화물과 연결됩니다

00:14:19.340 --> 00:14:22.280
배송 날짜가 여유로워 기업이 더 저렴한 서비스를 이용한다면

00:14:22.280 --> 00:14:23.860
그 선택 또한 연결됩니다

00:14:23.860 --> 00:14:25.800
사람들은 배송 비용을 그 비용을 발생시킨

00:14:25.800 --> 00:14:28.240
경로와 운송업체 선택까지 거슬러 올라가 추적할 수 있습니다

00:14:28.240 --> 00:14:30.780
차량이 도크를 떠나 물품이 안전하게 도착할 수 있지만

00:14:30.780 --> 00:14:32.580
작업은 아직 끝난 것이 아닙니다

00:14:32.580 --> 00:14:34.860
운송업체는 나중에 운송 청구서를 보내며

00:14:34.860 --> 00:14:36.580
누군가는 이를 확인해야 합니다

00:14:36.580 --> 00:14:38.320
운송 비용과 정산입니다

00:14:38.320 --> 00:14:42.060
물품은 이미 창고를 떠났고 배송까지 완료되었을 수도 있습니다

00:14:42.060 --> 00:14:44.180
그때 운송업체의 송장이 도착합니다

00:14:44.180 --> 00:14:45.860
해당 청구서는 확인이 필요한데

00:14:45.860 --> 00:14:51.600
이는 청구 금액이 운송업체, 경로, 서비스, 화물 세부 정보, 예상 운임 등 회사가

00:14:51.600 --> 00:14:54.520
이전에 계획한 운송 선택과 연결되어야 하기 때문입니다

00:14:54.520 --> 00:14:56.780
계획 단계에서 다이나믹스 365는

00:14:56.780 --> 00:15:00.100
회사의 요금 정보를 바탕으로 예상 운송 비용을 계산할 수 있습니다

00:15:00.100 --> 00:15:02.860
이 예상 금액은 운송업체가 대금을 청구하기 전에

00:15:02.860 --> 00:15:04.400
기업의 기준점을 제공합니다

00:15:04.400 --> 00:15:06.940
나중에 운송업체는 운송 청구서를 보냅니다

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

00:15:12.060 --> 00:15:15.260
쉽게 말해 회사는 운송업체가 실제로 물품을 운송한 서비스에 대해

00:15:15.260 --> 00:15:17.400
회사가 예상한 금액을 청구했는지 확인하는 것입니다

00:15:17.400 --> 00:15:19.840
계획상 비용이 500달러라고 가정해보겠습니다

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

00:15:24.000 --> 00:15:28.300
계획된 기록과 청구서가 일치하므로 해당 청구서는 확인 절차를 순조롭게 통과합니다

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

00:15:31.080 --> 00:15:34.440
요금표가 잘못되었거나 운송업체가 다른 서비스에 대해 청구했거나

00:15:34.440 --> 00:15:37.920
계획 수립 후 화물이 변경되어 추가 비용에 대한 설명이 필요할 수 있습니다

00:15:37.920 --> 00:15:41.060
연결된 기록이 없으면 재무팀은 청구서 번호와 금액만 확인하고

00:15:41.060 --> 00:15:44.580
창고 및 운송팀에 무슨 일이 있었는지 문의 하느라 시간을 허비하게 됩니다

00:15:44.580 --> 00:15:48.180
운송관리는 운송결정을 해당 확인 과정과 계속 연결해줍니다

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

00:15:52.640 --> 00:15:56.680
세부 정보가 회사에 승인된 규칙 내에 있으면 청구서 처리가 진행될 수 있습니다

00:15:56.680 --> 00:16:00.680
세부 정보가 맞지 않으면 시스템은 차이점을 담당자에게 보내 검토하게 합니다

00:16:00.680 --> 00:16:03.980
즉 모든 운임 청구를 맹목적으로 승인하지 않는다는 뜻입니다

00:16:03.980 --> 00:16:07.640
운송계획 담당자가 운송업체가 다른 서비스를 사용했음을 확인해야 하거나

00:16:07.640 --> 00:16:11.080
재무팀 누군가가 추가 비용이 발생한 이유를 물어봐야 할 수도 있습니다

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

00:16:14.060 --> 00:16:16.720
중요한 것은 대금을 지급하기 전에 불일치를 파악하는 것입니다

00:16:16.720 --> 00:16:19.600
이를 통해 운영팀과 재무팀이 동일한 배송권을 중심으로 협업하게 됩니다

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

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

00:16:23.940 --> 00:16:26.900
창고는 물품을 발송하고 재무팀은 나중에 들어온 청구서를

00:16:26.900 --> 00:16:29.120
회사가 계획했던 기록과 대조하여 확인합니다

00:16:29.120 --> 00:16:32.600
각 팀은 서로 다른 부분을 보지만 연결된 정보를 확인하는 것입니다

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

00:16:35.460 --> 00:16:38.580
대규모의 고도로 자동화된 운임감사가 필요한 기업은

00:16:38.580 --> 00:16:40.980
종종 타사 운송 관리 시스템을 추가합니다

00:16:40.980 --> 00:16:43.240
이러한 도구는 더 깊은 운송업체 연결과

00:16:43.240 --> 00:16:45.560
더 자동화된 확인 규칙을 제공할 수 있습니다

00:16:45.560 --> 00:16:49.220
내장 모듈은 공급망 관리 내에서 계획 비용 및 조정 작업을 처리하며

00:16:49.220 --> 00:16:51.080
기업에 더 많은 기능이 필요할 때

00:16:51.080 --> 00:16:53.620
다른 시스템을 통해 해당 작업을 확장할 수 있습니다

00:16:53.620 --> 00:16:56.640
이 모든 구성 요소를 합치면 전체적인 그림이 나타나기 시작하며

00:16:56.640 --> 00:17:00.040
어떤 부분에 적합하고 어떤 부분은 수행하지 않는지 파악할 수 있습니다

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

00:17:02.760 --> 00:17:04.480
파이낸스 엔드 오퍼레이션즈 앱에서 실행되는

00:17:04.480 --> 00:17:07.200
다이나믹스 365 서플라이 체인 매니지먼트 내에 속해 있습니다

00:17:07.200 --> 00:17:08.620
그곳이 바로 본거지입니다

00:17:08.620 --> 00:17:10.260
적합한 대상은 다음과 같습니다

00:17:10.260 --> 00:17:16.080
자체 운송업체 기록, 요금표, 적재 규칙을 사용하여 입고 배송, 고객 출고 배송,

00:17:16.080 --> 00:17:19.140
사업장 간 재고 이전을 체계적으로 계획해야 하는 기업입니다

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

00:17:21.740 --> 00:17:23.560
비즈니스 센트럴은 다릅니다

00:17:23.560 --> 00:17:26.980
비즈니스 센트럴 N은이 내장된 운송관리 모듈이 포함되어 있지 않습니다

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

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

00:17:31.620 --> 00:17:32.800
그것이 경계입니다

00:17:32.800 --> 00:17:35.060
다른 쪽의 경계도 명확히 해두겠습니다

00:17:35.060 --> 00:17:38.140
내장 모듈이 모든 운송업체 포털, 실시간 교통서비스

00:17:38.140 --> 00:17:40.060
또는 고급 추적 도구를 대체하지는 않습니다

00:17:40.060 --> 00:17:43.380
기업이 여러 운송업체의 실시간 요금, 더 넓은 운송업체의 선택권

00:17:43.380 --> 00:17:45.900
또는 상품이 출하된 후에 심층적인 추적이 필요할 때는

00:17:45.900 --> 00:17:47.260
타사 TMS를 연결합니다

00:17:47.260 --> 00:17:49.380
그러한 도구들이 외부 활동을 처리합니다

00:17:53.560 --> 00:17:56.860
주문, 창고, 작업, 재무와 연결됩니다

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

00:17:59.320 --> 00:18:02.640
외부 운송업체 도구는 그 데스크 밖의 활동을 처리할 수 있습니다

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

00:18:05.380 --> 00:18:06.420
결론입니다

00:18:06.420 --> 00:18:07.920
다음 지식 조각입니다

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

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

00:18:13.740 --> 00:18:17.360
그런 다음 그 이동을 회사가 사후에 확인하는 운송비용과 연결합니다

00:18:17.360 --> 00:18:18.880
그것이 전체 루프입니다

00:18:18.880 --> 00:18:21.260
선호하는 팟캐스트 플랫폼에서 구독하세요

00:18:21.260 --> 00:18:26.140
다이나믹스 365 서플라이 체인 매니지먼트를 배우는 사람과의 지식 조각을 공유하세요

00:18:26.140 --> 00:18:28.840
그런 다음 창고 및 재고 에피소드를 확인해보세요

00:18:28.840 --> 00:18:32.040
모든 적재는 결국 창고문 뒤에 있는 재고에 달려있습니다

00:18:32.040 --> 00:18:37.840
Один 그루프가 지원 마지막으로 지식 조각을 받습니다

00:18:37.840 --> 00:18:39.780
그 창고문이 줄지어fort하는 사람들을 위해

00:18:39.780 --> 00:18:40.740
안성 блок� wife