WEBVTT

00:00:00.000 --> 00:00:01.980
고객이 웹사이트에서 구매 버튼을 클릭할 때

00:00:01.980 --> 00:00:04.380
원하는 상품은 창고, 시내 다른 지역의 매장

00:00:04.380 --> 00:00:06.340
또는 배송 파트너가 보유하고 있을 수 있습니다.

00:00:06.540 --> 00:00:09.060
하지만 고객이 진정으로 기대하는 것은 단 두 가지 뿐입니다.

00:00:09.220 --> 00:00:11.380
명확한 약속과 문 앞까지 배송되는 택배입니다.

00:00:11.580 --> 00:00:13.640
M365 FM 위 마이크로소프트 날리지 너게츠

00:00:13.640 --> 00:00:15.260
또 다른 에피소드에 오신 것을 환영합니다.

00:00:15.420 --> 00:00:16.220
저는 모 피터스이며

00:00:16.220 --> 00:00:19.080
오늘은 다이나믹스 365인텔리전트 오더 매니지먼트에 대해

00:00:19.080 --> 00:00:20.080
쉬운 언어로 알아보겠습니다.

00:00:20.280 --> 00:00:22.580
결제 클릭부터 실제 배송이 이루어지기까지의

00:00:22.580 --> 00:00:23.860
주문 과정을 따라가 보겠습니다.

00:00:23.860 --> 00:00:26.800
바쁜 사무실 건물의 중앙 안내 데스크를 생각해보세요.

00:00:27.000 --> 00:00:28.200
또 다른 온라인 쇼핑몰이 아니면

00:00:28.200 --> 00:00:29.920
직접 상자를 포장하지도 않습니다.

00:00:30.120 --> 00:00:31.980
그저 적절한 사람과 시스템을 연결하여

00:00:31.980 --> 00:00:34.360
올바른 곳에서 업무가 처리되도록 지시할 뿐입니다.

00:00:34.900 --> 00:00:36.720
왜 주문 관리는 복잡해질까요?

00:00:37.040 --> 00:00:39.980
웹사이트, 오프라인 매장, 온라인 마켓플레이스,

00:00:40.380 --> 00:00:43.100
콜센터를 통해 동일한 헤드폰을 판매한다고 상상해보세요.

00:00:43.380 --> 00:00:46.440
고객에게는 이 모든 것이 그저 헤드폰을 구매하는 방법일 뿐입니다.

00:00:46.620 --> 00:00:49.220
하지만 내부적으로는 각 채널이 서로 완전히 다른 시스템으로

00:00:49.220 --> 00:00:50.440
주문 세부 정보를 보냅니다.

00:00:50.440 --> 00:00:53.980
웹사이트는 하나의 기록을 보관하고 매장 POS는 또 다른 기록을 가지며

00:00:53.980 --> 00:00:56.240
마켓플레이스는 자체 형식으로 데이터를 보내고

00:00:56.240 --> 00:00:58.780
콜센터 상담원은 완전히 다른 곳에 주문을 생성합니다.

00:00:58.940 --> 00:01:01.280
단 하나의 단순한 고객 약속이 서로 소통하지 않는

00:01:01.280 --> 00:01:03.060
여러 개의 복잡한 부품으로 나뉩니다.

00:01:03.260 --> 00:01:05.540
여기에 재고 상황이 또 다른 복잡성을 더합니다.

00:01:05.760 --> 00:01:07.520
메인 창고에 20개가 있을 수 있습니다.

00:01:07.780 --> 00:01:10.800
시내 반대편 매장에 5개가 있고 다른 창고에도 재고가 있습니다.

00:01:11.100 --> 00:01:13.500
하지만 그곳은 더 멀어서 배송 비용이 더 많이 듭니다.

00:01:13.680 --> 00:01:17.360
일부 재고는 다른 주문, 반품된 상품 또는 매장 방문 고객을 위해 이미 예약되어 있습니다.

00:01:17.360 --> 00:01:20.600
따라서 제품 옆에 적힌 숫자만 보는 것으로는 문제를 해결할 수 없습니다.

00:01:20.840 --> 00:01:22.440
이제 배송 방법을 결정해야 합니다.

00:01:22.640 --> 00:01:25.240
창고에서 배송해야 할까요? 매장에서 배송해야 할까요?

00:01:25.420 --> 00:01:27.400
아니면 고객이 직접 매장에서 수령할 수 있을까요?

00:01:27.580 --> 00:01:29.740
만약 두 가지 상품을 샀는데 어느 한 곳에도 두 가지가 다 없다면

00:01:29.740 --> 00:01:32.840
주문을 두 개의 택배로 나눌까요? 아니면 모두 준비될 때까지 기다릴까요?

00:01:33.020 --> 00:01:36.500
모든 선택은 비용, 배송 시간, 그리고 고객에게 한 약속에 영향을 미칩니다.

00:01:36.700 --> 00:01:39.960
20년 전만 해도 기업들은 별도의 팀이 관리하는 개별 시스템으로 이러한 작업을 처리했습니다.

00:01:40.180 --> 00:01:41.260
영업팀이 주문을 받았습니다.

00:01:41.580 --> 00:01:42.620
누군가 재고를 확인했습니다.

00:01:42.620 --> 00:01:44.060
창고에 요청이 전달되었습니다.

00:01:44.300 --> 00:01:46.000
배송 파트너에게 또 다른 요청이 전달되었습니다.

00:01:46.220 --> 00:01:47.700
결제는 나중에 별도로 처리되었습니다.

00:01:47.980 --> 00:01:50.360
주문이 단순하고 물량이 적었을 때는 잘 작동했습니다.

00:01:50.620 --> 00:01:51.820
하지만 중요한 점이 있습니다.

00:01:52.100 --> 00:01:55.320
시스템 간 업데이트가 느려지면 사람들이 그 빈틈을 메우기 시작합니다.

00:01:55.520 --> 00:01:59.500
고객 서비스 상담원이 한 화면을 확인하고 창고팀에 이메일을 보낸 뒤 배송업체에 전화하는 동안

00:01:59.500 --> 00:02:03.540
재고 업데이트가 웹사이트에 반영되기 전에 다른 채널에서 제품이 판매될 수도 있습니다.

00:02:03.800 --> 00:02:05.960
이제 보낼 수 없는 물건에 대한 주문이 들어왔습니다.

00:02:06.180 --> 00:02:07.600
과잉 판매는 그렇게 발생합니다.

00:02:07.600 --> 00:02:10.020
배송 선택에 너무 오랜 시간이 걸리는 이유이기도 하죠.

00:02:10.160 --> 00:02:14.340
팀은 세부 정보를 계속 복사해서 옮기고 고객은 명확한 답변 대신 모호한 업데이트만 받게 됩니다.

00:02:14.540 --> 00:02:17.240
고객의 입장에서는 그런 복잡한 상황은 중요하지 않습니다.

00:02:17.480 --> 00:02:19.200
그저 한 가지만 물어볼 뿐이니까요.

00:02:19.340 --> 00:02:20.580
내 주문은 어디에 있나요?

00:02:20.720 --> 00:02:24.300
기업에 정말 필요한 것은 모든 연결된 비즈니스 앱 전반에서 주문 여정을 확인하면서

00:02:24.300 --> 00:02:27.240
각 앱이 본연의 기능을 충실히 수행할 수 있게 하는 통합된 공간입니다.

00:02:27.400 --> 00:02:28.880
영업 부서는 판매를 기록합니다.

00:02:29.080 --> 00:02:30.720
창고는 피킹과 패킹을 관리합니다.

00:02:30.920 --> 00:02:32.200
배송 부서는 발송을 처리합니다.

00:02:32.200 --> 00:02:33.820
격리부서는 자금 결제를 관리합니다.

00:02:33.940 --> 00:02:35.460
기존 시스템을 모두 버릴 필요는 없습니다.

00:02:35.740 --> 00:02:37.760
부족한 것은 그 사이를 조율하는 조정자입니다.

00:02:38.020 --> 00:02:40.300
주문을 접수하고 다음 단계를 파악하며

00:02:40.300 --> 00:02:44.220
수동 인계 절차에 의존하지 않고 작업을 지시할 수 있는 공간이 필요합니다.

00:02:44.400 --> 00:02:45.580
그게 바로 문제입니다.

00:02:45.800 --> 00:02:50.500
다이나믹스 365 인텔리전트 오더 매니지먼트가 바로 그 명확한 해답을 제시합니다.

00:02:50.740 --> 00:02:55.220
그렇다면 다이나믹스 365 인텔리전트 오더 매니지먼트란 정확히 무엇일까요?

00:02:55.420 --> 00:02:58.120
오늘은 이를 알기 쉽게 풀어서 설명해드리겠습니다.

00:02:58.500 --> 00:03:00.340
가장 간단한 정의는 다음과 같습니다.

00:03:00.340 --> 00:03:04.220
주문이 접수되는 순간부터 이행과 결제가 완료될 때까지

00:03:04.220 --> 00:03:09.200
기업이 이미 사용하는 모든 시스템을 거쳐 주문을 안내하는 클라우드 앱입니다.

00:03:09.380 --> 00:03:11.120
바쁜 기차역을 상상해보세요.

00:03:11.420 --> 00:03:13.040
기차는 여러 방향에서 들어옵니다.

00:03:13.260 --> 00:03:15.060
승객은 각기 다른 승강장이 필요합니다.

00:03:15.260 --> 00:03:17.520
어떤 연결편은 빠르지만 다른 연결편은 기다려야 합니다.

00:03:17.720 --> 00:03:20.540
인텔리전트 오더 매니지먼트는 마치 기차역의 관제실처럼 작동합니다.

00:03:20.720 --> 00:03:22.600
기차를 직접 운전하거나 티켓을 판매하지는 않지만

00:03:22.600 --> 00:03:25.180
전체 경로를 파악하고 각 시스템에 다음할 일을 지시합니다.

00:03:25.460 --> 00:03:27.080
마이크로소프트는 데이터버스를 기반으로

00:03:27.080 --> 00:03:28.760
인텔리전트 오더 매니지먼트를 구축했습니다.

00:03:29.000 --> 00:03:32.560
데이터버스는 많은 다이나믹스 365 및 파워 플랫폼 앱을 뒷받침하는

00:03:32.560 --> 00:03:33.740
공통 데이터 기반입니다.

00:03:33.940 --> 00:03:36.860
쉽게 말해 비즈니스 앱들이 정보를 저장할 수 있는

00:03:36.860 --> 00:03:39.060
공통 공간과 공통 형식을 제공합니다.

00:03:39.280 --> 00:03:43.060
즉 주문 정보가 화면이나 시스템마다 다르게 해석되지 않는다는 뜻입니다.

00:03:43.280 --> 00:03:44.600
이러한 공통 기반이 도움이 되긴 하지만

00:03:44.600 --> 00:03:46.620
인텔리전트 오더 매니지먼트를 사용하기 위해

00:03:46.620 --> 00:03:48.860
다른 모든 다이나믹스 365 앱을 구매할 필요는 없습니다.

00:03:48.860 --> 00:03:51.040
어떤 회사는 다이나믹스 365 파이낸스

00:03:51.040 --> 00:03:53.140
나 서플라이 체인 매니지먼트를 운영할 수도 있습니다.

00:03:53.340 --> 00:03:55.860
다른 회사는 아예 다른 창고 시스템이나 온라인 스토어

00:03:55.860 --> 00:03:58.300
또는 다른 업체의 배송 서비스를 사용할 수도 있죠.

00:03:58.500 --> 00:04:00.140
이 앱은 마이크로소프트 제품뿐만 아니라

00:04:00.140 --> 00:04:01.740
타사 비즈니스 앱과도 연동됩니다.

00:04:01.940 --> 00:04:04.220
이 연결 지점을 공급자, 프로바이더 라고 합니다.

00:04:04.440 --> 00:04:06.400
공급자는 인텔리전트 오더 매니지먼트와

00:04:06.400 --> 00:04:08.760
다른 시스템 간의 주문 및 이행 정보를 전달합니다.

00:04:09.000 --> 00:04:11.300
공급자들 입구의 통역사라고 생각하시면 됩니다.

00:04:11.300 --> 00:04:13.500
한 시스템이 자체 형식으로 주문을 보내면

00:04:13.500 --> 00:04:15.180
공급자가 그 형식을 이해하고

00:04:15.180 --> 00:04:17.460
정보를 인텔리전트 오더 매니지먼트로 전달하며

00:04:17.460 --> 00:04:19.560
다시 다른 시스템이 이해할 수 있는 형식으로

00:04:19.560 --> 00:04:20.780
다음 요청을 보낼 수 있습니다.

00:04:20.980 --> 00:04:22.880
이 앱은 주문이 다른 곳에서 시작되었더라도

00:04:22.880 --> 00:04:24.660
모든 주문 정보를 하나로 통합합니다.

00:04:24.900 --> 00:04:27.420
고객은 AIO 커머스 사이트를 통해 구매할 수 있습니다.

00:04:27.680 --> 00:04:30.400
다른 고객은 POS 시스템을 통해 주문할 수도 있습니다.

00:04:30.680 --> 00:04:32.580
기업 고객은 BEB 프로세스를 통해

00:04:32.580 --> 00:04:34.000
전자주문을 보낼 수 있습니다.

00:04:34.280 --> 00:04:35.460
지능형 주문 관리를 통해

00:04:35.460 --> 00:04:37.100
기업은 한 곳에서 주문을 확인하고

00:04:37.100 --> 00:04:39.140
각 주문의 이행 상태를 파악할 수 있습니다.

00:04:39.380 --> 00:04:41.480
모든 주문이 같은 경로를 따르는 것은 아닙니다.

00:04:41.680 --> 00:04:43.180
재고를 기다려야 하는 주문도 있습니다.

00:04:45.180 --> 00:04:47.160
배송 후 청구 단계가 필요한 주문도 있습니다.

00:04:47.480 --> 00:04:48.660
이 앱은 상태를 추적하므로

00:04:48.660 --> 00:04:50.980
팀은 단순한 주문 접수 그 이상을 볼 수 있습니다.

00:04:51.240 --> 00:04:52.700
주문이 현재 어떤 단계에 있는지

00:04:52.700 --> 00:04:53.900
정확히 파악할 수 있습니다.

00:04:54.180 --> 00:04:56.160
여기서 사람들이 가끔 놓치는 부분이 있습니다.

00:04:56.420 --> 00:04:59.260
지능형 주문 관리가 모든 업무를 대신하는 것은 아닙니다.

00:04:59.440 --> 00:05:01.020
갑자기 창고 직원의 피킹 화면,

00:05:01.380 --> 00:05:02.640
운송사의 배송 네트워크,

00:05:03.020 --> 00:05:05.000
재무팀의 청구 시스템이 되는 것은 아닙니다.

00:05:05.200 --> 00:05:08.100
연결된 앱들은 여전히 각자의 전문적인 업무를 수행합니다.

00:05:08.320 --> 00:05:11.200
지능형 주문 관리는 그들 사이의 업무 인계를 지휘합니다.

00:05:11.440 --> 00:05:14.400
요청을 받고 경로를 확인한 다음 작업을 전달하고

00:05:14.400 --> 00:05:16.220
다음 업데이트를 기다립니다.

00:05:16.720 --> 00:05:20.580
이제 주문 여정을 따라가 보며 이 개념을 더 쉽게 이해해 보겠습니다.

00:05:22.140 --> 00:05:24.460
주문 여정 규칙이 업무를 지시합니다.

00:05:24.860 --> 00:05:28.380
고객이 오후 늦게 웹사이트에서 두 가지 상품을 주문하고

00:05:28.380 --> 00:05:31.000
내일 배송받기를 원한다고 가정해 봅시다.

00:05:31.260 --> 00:05:33.940
온라인 스토어는 고객 이름, 배송지 주소,

00:05:34.320 --> 00:05:36.700
두 개의 주문 품목, 배송 옵션을 캡처합니다.

00:05:36.980 --> 00:05:40.180
공급자가 해당 주문을 지능형 주문 관리 시스템으로 가져오면

00:05:40.180 --> 00:05:41.460
주문 여정이 시작됩니다.

00:05:41.460 --> 00:05:44.500
이 행을 시도하기 전에 시스템은 주문을 검증하여

00:05:44.500 --> 00:05:46.380
여정에 필요한 모든 정보가 있는지,

00:05:46.840 --> 00:05:48.640
회사 규칙을 따르는지 확인합니다.

00:05:48.840 --> 00:05:51.500
주문 헤더에서 고객 및 배송 정보를 확인합니다.

00:05:51.720 --> 00:05:53.700
각 라인의 상품과 수량을 확인합니다.

00:05:53.920 --> 00:05:56.300
주소의 배송을 위한 충분한 정보가 있는지 확인하고,

00:05:56.760 --> 00:05:59.080
해당 판매 채널의 규칙을 준수하는지 검토합니다.

00:05:59.320 --> 00:06:02.220
이 첫 번째 확인 과정은 잘못된 정보가 하류 단계로 이동하여

00:06:02.220 --> 00:06:03.780
문제를 일으키는 것을 방지합니다.

00:06:03.980 --> 00:06:06.140
아파트 호수가 누락된 주문을 예로 들어보겠습니다.

00:06:06.140 --> 00:06:11.820
바로 창고로 이동하여 운송사로 전달된다면 배송 불가 상태가 되어서야 문제를 발견할 수도 있습니다.

00:06:12.040 --> 00:06:16.900
검증 단계는 고객에게 연락하거나 주문을 보류할 시간이 있을 때 문제를 조기에 포착합니다.

00:06:17.160 --> 00:06:19.560
이 작업의 근간은 오케스트레이션 흐름에 있습니다.

00:06:19.920 --> 00:06:22.520
기술적 인용어처럼 들리지만 실제로는 간단합니다.

00:06:22.720 --> 00:06:24.820
오케스트레이션 흐름은 주문 정보가 도착하고,

00:06:24.980 --> 00:06:29.880
연결된 시스템에서 이벤트가 돌아올 때 무엇을 해야 할지 지능형 주문 관리에 알려주는 시각적 지도입니다.

00:06:30.140 --> 00:06:32.740
여러분은 자체 비즈니스 프로세스에 맞춰 이 지도를 만듭니다.

00:06:32.740 --> 00:06:35.620
기본적인 주문 흐름은 새 주문이 도착할 때 시작될 수 있습니다.

00:06:35.820 --> 00:06:37.180
헤더와 라인을 검증합니다.

00:06:37.400 --> 00:06:39.320
이행 결정을 위해 주문을 전송합니다.

00:06:39.560 --> 00:06:42.500
그 후 올바르게 연결된 시스템으로 이행 주문을 보냅니다.

00:06:42.740 --> 00:06:46.280
작업이 적절한 단계에 도달하면 주문 정보를 청구업체로 보낼 수 있습니다.

00:06:46.520 --> 00:06:48.220
각 작업에는 명확한 역할이 있습니다.

00:06:48.560 --> 00:06:51.160
주문 헤더 검증은 주요 주문 세부 정보를 확인합니다.

00:06:51.400 --> 00:06:54.260
주문 라인 검증은 개별 상품과 수량을 확인합니다.

00:06:54.520 --> 00:06:58.360
이행 전송은 해당 작업을 처리하는 업체에 이행 주문을 전달합니다.

00:06:58.640 --> 00:07:01.360
총장 전송은 청구업체의 주문 정보를 전달합니다.

00:07:01.360 --> 00:07:04.020
이 이름들은 마치 공장 제어판의 라벨처럼 들리는데

00:07:04.020 --> 00:07:08.360
각 라벨이 흐름에 해당 지점에서 무슨 일이 일어나는지 정확히 알려주기 때문에 유용합니다.

00:07:08.540 --> 00:07:11.780
하지만 실제 비즈니스에는 종종 하나 이상의 직선 경로가 필요합니다.

00:07:11.980 --> 00:07:15.840
웹사이트 주문은 한 경로를 따르고 기업 고객 주문은 다른 경로를 따를 수 있습니다.

00:07:16.100 --> 00:07:18.340
어떤 상품 유형은 특별 승인이 필요할 수도 있습니다.

00:07:18.560 --> 00:07:21.380
첫 번째 단계가 성공해야만 주문이 다음으로 넘어갈 수도 있습니다.

00:07:21.600 --> 00:07:24.460
지능형 주문 관리에는 이러한 선택을 위한 조건이 포함됩니다.

00:07:24.680 --> 00:07:26.880
조건은 예 경로와 아니오 경로를 만듭니다.

00:07:27.080 --> 00:07:30.600
이전 작업이 성공하면 주문은 예 경로를 따라 계속 진행될 수 있습니다.

00:07:30.600 --> 00:07:33.800
실패하면 흐름은 주문을 다른 경로로 안내할 수 있습니다.

00:07:34.040 --> 00:07:36.220
그것만으로 모든 문제가 해결되지는 않지만

00:07:36.220 --> 00:07:40.720
팀이 우연히 오류를 발견하게 하는 대신 프로세스에 계획된 대응을 제공합니다.

00:07:40.900 --> 00:07:41.820
분할기도 있습니다.

00:07:42.160 --> 00:07:45.700
분할기는 사용자가 정의한 규칙에 따라 흐름을 하나 이상의 경로로 보냅니다.

00:07:45.940 --> 00:07:48.320
서로 다른 출처의 주문에 대해 서로 다른 확인이 필요하거나

00:07:48.320 --> 00:07:51.280
작업의 각 부분이 다른 경로를 거쳐야 할 때 이를 사용할 수 있습니다.

00:07:51.480 --> 00:07:53.260
일부 분할된 경로는 나중에 다시 합쳐질 수도 있고

00:07:53.260 --> 00:07:55.380
다른 경로는 독립적으로 계속 진행될 수도 있습니다.

00:07:55.580 --> 00:07:58.200
사용자 지정 작업은 비즈니스 고유의 업무를 다룹니다.

00:07:58.200 --> 00:08:00.120
회사가 자체 제조 시스템을 가지고 있거나

00:08:00.120 --> 00:08:03.040
표준 작업에서 다루지 않는 파트너 시스템을 사용할 수 있습니다.

00:08:03.240 --> 00:08:05.700
사용자 지정 작업을 사용하면 해당 단계를 주문 흐름에 연결하여

00:08:05.700 --> 00:08:07.680
한 부분이 이메일이나 수작업 속에 숨겨지지 않고

00:08:07.680 --> 00:08:09.660
전체 프로세스가 경로에 표시되도록 할 수 있습니다.

00:08:09.840 --> 00:08:11.640
두 품목 주문으로 다시 돌아가 보겠습니다.

00:08:11.960 --> 00:08:16.040
시스템은 웹사이트에서 주문을 받아 고객 정보, 주소, 상품 라인을 확인합니다.

00:08:16.220 --> 00:08:18.520
그러면 주문은 이행 결정 단계에 도달합니다.

00:08:18.760 --> 00:08:20.760
두 품목 모두 같은 경로를 따를 수 있다면

00:08:20.760 --> 00:08:23.820
흐름은 이행 요청을 하나의 단위로 계속 보낼 수 있습니다.

00:08:23.820 --> 00:08:27.860
회사의 규칙상 다른 결과가 필요하다면 주문은 다른 경로를 취할 수 있습니다.

00:08:28.020 --> 00:08:29.980
두 품목의 별도의 이행 요청이 필요하거나

00:08:29.980 --> 00:08:32.300
주문의 다른 배송 옵션이 필요할 수도 있습니다.

00:08:32.500 --> 00:08:33.800
흐름은 추측하지 않습니다.

00:08:34.020 --> 00:08:37.620
비즈니스가 만든 규칙과 연결된 시스템이 반환하는 이벤트를 따릅니다.

00:08:37.880 --> 00:08:39.220
마지막 부분이 중요합니다.

00:08:39.440 --> 00:08:41.280
지능형 주문 관리는 작업을 지시할 수 있지만

00:08:41.280 --> 00:08:44.360
작업이 진행됨에 따라 연결된 시스템이 다시 보고를 합니다.

00:08:44.580 --> 00:08:46.500
이행 업체가 요청을 수신할 수 있습니다.

00:08:46.780 --> 00:08:49.240
결제 업체가 주문 세부 정보를 수신할 수 있습니다.

00:08:49.540 --> 00:08:52.280
이러한 이벤트들이 주문 여정을 흐름에 따라 이동시킵니다.

00:08:52.280 --> 00:08:55.060
따라서 이 앱은 하나의 거대한 대체 시스템이 아닙니다.

00:08:55.220 --> 00:08:59.380
전문 시스템을 연결하여 각 시스템에 필요한 작업을 적시에 제공하는 일련의 규칙입니다.

00:08:59.580 --> 00:09:01.340
온라인 스토어가 주문을 접수합니다.

00:09:01.580 --> 00:09:03.200
이행 시스템이 이행을 처리합니다.

00:09:03.420 --> 00:09:05.240
결제 시스템이 결제를 처리합니다.

00:09:05.480 --> 00:09:08.340
지능형 주문 관리는 이러한 작업 간의 경로를 관리합니다.

00:09:08.580 --> 00:09:12.280
주문 프로세스 담당자는 앱에서 직접 이러한 흐름을 설계할 수 있습니다.

00:09:12.580 --> 00:09:14.560
모든 경로를 기존 코드로 작성하거나

00:09:14.560 --> 00:09:18.380
IT 관리자에게 모든 비즈니스 규칙 변경을 요청할 필요가 없습니다.

00:09:18.720 --> 00:09:21.880
이를 통해 공급망팀는 실제로 필요한 프로세스를 모델링할 수 있습니다.

00:09:21.880 --> 00:09:24.240
그럼에도 이러한 변경 사항에는 주의가 필요합니다.

00:09:24.440 --> 00:09:27.740
오케스트레이션 흐름은 구축 및 테스트 단계에서 개시되지 않은 상태로 유지됩니다.

00:09:27.920 --> 00:09:30.800
해당 단계에서는 들어오는 데이터가 흐름을 거치지 않습니다.

00:09:31.020 --> 00:09:34.780
개시하면 데이터가 시스템에 들어올 때 흐름과 해당 작업이 실행됩니다.

00:09:35.000 --> 00:09:37.680
개시 후에는 개시된 흐름을 직접 편집할 수 없습니다.

00:09:38.000 --> 00:09:40.860
비즈니스 변경이 필요하면 팀이 개시된 흐름을 중지하여

00:09:40.860 --> 00:09:42.820
개시되지 않은 상태로 되돌릴 수 있습니다.

00:09:43.080 --> 00:09:45.840
흐름을 편집한 다음 준비가 되면 새 버전을 개시할 수 있습니다.

00:09:46.140 --> 00:09:48.440
이러한 설정은 실시간 주문이 경로를 통과하기 전에

00:09:48.440 --> 00:09:50.160
팀이 경로를 테스트하도록 유도합니다.

00:09:50.360 --> 00:09:53.120
경로는 실제 가용 재고를 파악해야만 작동합니다.

00:09:53.340 --> 00:09:57.060
이는 각 이행 결정의 이면에 있는 실시간 재고 정보로 이어집니다.

00:09:57.280 --> 00:10:00.860
재고 가시성, 즉 실제로 판매 가능한 상품을 확인하는 것입니다.

00:10:01.100 --> 00:10:03.120
솔직히 말해 명백한 사실이 하나 있습니다.

00:10:03.440 --> 00:10:05.760
재고가 있는지 모르면 주문을 이행할 수 없습니다.

00:10:06.100 --> 00:10:06.940
당연하게 들리겠지만

00:10:06.940 --> 00:10:10.280
재고는 창고, 매장, 파트너 위치 또는 같은 회사 내의

00:10:10.280 --> 00:10:11.800
서로 다른 법인에 숨어 있을 수 있습니다.

00:10:12.000 --> 00:10:13.440
각 위치에서 재고를 따로 관리하면

00:10:13.440 --> 00:10:15.640
지금이 고객에게 무엇을 약속할 수 있는가?

00:10:15.780 --> 00:10:17.620
라는 기본적인 질문에 답할 수 없습니다.

00:10:17.900 --> 00:10:19.820
재고 가시성을 통해 지능형 주문 관리 시스템은

00:10:19.820 --> 00:10:22.480
공급 네트워크 전반의 모든 재고를 실시간으로 파악할 수 있습니다.

00:10:22.680 --> 00:10:25.020
물류센터의 재고 현황판과 같다고 생각하세요.

00:10:25.300 --> 00:10:27.380
모든 선반에 전화하여 확인을 요청하는 대신

00:10:27.380 --> 00:10:30.920
주문 프로세스가 모든 시스템이 통합된 단일 공유뷰를 참조합니다.

00:10:31.220 --> 00:10:33.500
이제 상품이 어딘가에 재고로 표시된다고 해서

00:10:33.500 --> 00:10:35.580
모든 주문을 이행할 수 있는 것은 아닙니다.

00:10:35.580 --> 00:10:37.740
상품이 창고에 있지만 이미 예약되었거나

00:10:37.740 --> 00:10:40.560
현장 판매만 가능하고 배송이 안 되는 매장에 있거나

00:10:40.560 --> 00:10:44.300
단순히 고객이 선택한 배송 약속을 지키기에 너무 멀리 있을 수 있습니다.

00:10:44.520 --> 00:10:45.760
어딘가에 존재하는 재고와

00:10:45.760 --> 00:10:49.140
지금 당장이 주문을 이행할 수 있는 재고 사이에는 큰 차이가 있습니다.

00:10:49.420 --> 00:10:51.060
고객이 온라인으로 재킷을 구매하고

00:10:51.060 --> 00:10:52.820
내일 받기를 원한다고 가정해봅시다.

00:10:53.020 --> 00:10:54.840
주요 창고에는 재고가 하나도 없습니다.

00:10:55.160 --> 00:10:56.400
최신 재고 데이터가 없으면

00:10:56.400 --> 00:10:59.500
웹사이트는 예전 수치를 기준으로 주문을 계속 받을 수 있고

00:10:59.500 --> 00:11:02.100
창고는 보낼 수 없는 상품에 대한 요청을 받아

00:11:02.100 --> 00:11:04.300
고객이 결제 후에야 그 사실을 알게 됩니다.

00:11:04.560 --> 00:11:06.200
그건 모두에게 헛수고가 됩니다.

00:11:06.500 --> 00:11:07.940
연결된 재고 정보를 활용하는

00:11:07.940 --> 00:11:10.840
지능형 주문 관리 시스템은 주창고에 재킷이 없더라도

00:11:10.840 --> 00:11:12.920
근처 매장에 재고가 있음을 확인합니다.

00:11:13.080 --> 00:11:14.520
해당 매장이 배송을 지원한다면

00:11:14.520 --> 00:11:16.140
그곳에서 주문을 처리할 수 있습니다.

00:11:16.360 --> 00:11:17.620
고객이 수령을 선택했다면

00:11:17.620 --> 00:11:19.400
동일한 매장이 픽업 장소가 됩니다.

00:11:19.680 --> 00:11:22.000
결정은 더 나은 재고 파악에서 시작됩니다.

00:11:22.240 --> 00:11:23.700
여러 법인을 가진 기업의 경우

00:11:23.700 --> 00:11:26.240
이 시안은 모든 법인의 재고를 포괄합니다.

00:11:26.500 --> 00:11:28.980
여러 국가, 지역, 사업 단위에서 운영되어

00:11:28.980 --> 00:11:31.860
재고가 하나의 기록체계에만 있지 않을 때 더욱 중요합니다.

00:11:32.080 --> 00:11:34.620
주문 프로세스는 실시간 재고 데이터를 사용하여

00:11:34.620 --> 00:11:36.300
어떤 경로를 취할지 결정합니다.

00:11:36.520 --> 00:11:38.800
참고, 매장 또는 기타 재고 소스는

00:11:38.800 --> 00:11:40.980
여전히 자체적인 재고 기록을 관리합니다.

00:11:41.220 --> 00:11:44.560
재고 가시성은 현재 수치를 더 넓은 주문 프로세스로 가져와

00:11:44.560 --> 00:11:46.260
이행 규칙에 활용할 수 있게 합니다.

00:11:46.260 --> 00:11:49.000
이는 어제의 데이터를 기반으로 한 약속을 피하게 해주며

00:11:49.000 --> 00:11:51.820
고객 서비스팀이 상품이 제때 도착할 수 있는지 묻는

00:11:51.820 --> 00:11:54.020
고객에게 명확한 답변을 제공하도록 돕습니다.

00:11:54.220 --> 00:11:55.340
여러 시스템을 검색하고

00:11:55.340 --> 00:11:56.940
정보가 일치하기를 바라는 대신

00:11:56.940 --> 00:12:00.120
주문팀은 이행 선택을 이끈� 재고 상태를 직접 확인합니다.

00:12:00.320 --> 00:12:02.240
물론 모든 가능한 위치를 확인한다고 해서

00:12:02.240 --> 00:12:03.920
모든 문제가 해결되는 것은 아닙니다.

00:12:03.920 --> 00:12:06.240
다섯 곳의 위치에서 상품을 찾을 수도 있습니다.

00:12:06.480 --> 00:12:08.520
고객과 가장 가까운 곳, 재고가 더 많은 곳,

00:12:08.780 --> 00:12:09.960
두 제품을 함께 배송할 수 있는

00:12:09.960 --> 00:12:11.360
세 번째 장소 등이 있을 수 있습니다.

00:12:11.600 --> 00:12:14.020
누군가 혹은 무언가가 여전히 선택을 해야 합니다.

00:12:14.020 --> 00:12:16.420
그 역할은 이행 최적화의 목입니다.

00:12:18.630 --> 00:12:18.990
이행

00:12:18.990 --> 00:12:20.930
최적화

00:12:20.930 --> 00:12:24.250
이행을 위해 배송할 최적의 장소를 선택하는 것입니다.

00:12:24.470 --> 00:12:26.930
최적화는 주문에 대해 가능한 위치들을 비교하고

00:12:26.930 --> 00:12:29.450
회사가 설정한 규칙에 따라 하나를 선택합니다.

00:12:29.690 --> 00:12:30.250
쉽게 말해

00:12:30.250 --> 00:12:31.950
이 주문을 어디서 보낼 것인가?

00:12:32.170 --> 00:12:33.470
라는 질문에 답하는 것입니다.

00:12:33.470 --> 00:12:35.750
최고가 항상 가장 가까운 곳을 의미하지는 않습니다.

00:12:35.930 --> 00:12:37.370
가장 가까운 매장에 상품이 있을 수 있지만

00:12:37.370 --> 00:12:39.390
거기서 배송하는 비용이 더 많이 들 수도 있습니다.

00:12:39.570 --> 00:12:42.130
더먼 창고의 두 제품이 모두 포장 준비가 되어 있을 수도 있고

00:12:42.130 --> 00:12:43.470
다른 위치의 재고는 있지만

00:12:43.470 --> 00:12:45.910
고객이 선택한 배송 날짜를 맞추지 못할 수도 있습니다.

00:12:46.130 --> 00:12:48.890
모든 회사는 어떤 규칙을 우선시 할지 결정해야 합니다.

00:12:49.130 --> 00:12:51.110
어떤 기업은 배송 속도를 최우선으로 합니다.

00:12:51.370 --> 00:12:53.590
다른 기업들은 배송 비용을 낮게 유지하고 싶어 합니다.

00:12:53.810 --> 00:12:55.490
또한 회사는 매장을 방문하는 고객을 위해

00:12:55.490 --> 00:12:56.530
매장 재고를 확보하거나

00:12:56.530 --> 00:12:58.010
선택의 여지가 없는 경우가 아니면

00:12:58.010 --> 00:13:00.490
주문을 여러 패키지로 나누는 것을 피하고자 할 수도 있습니다.

00:13:00.490 --> 00:13:04.230
지능형 주문 관리는 이러한 선택을 반영하는 이행 전략을 사용합니다.

00:13:04.390 --> 00:13:06.810
배송 차량의 경로를 선택하는 것과 같다고 생각하세요.

00:13:07.050 --> 00:13:09.210
가장 짧은 도로가 항상 가장 빠른 것은 아닙니다.

00:13:09.390 --> 00:13:12.390
교통체증이나 도로 공사 혹은 정차 시간이 길어질 수 있기 때문입니다.

00:13:12.590 --> 00:13:16.010
마찬가지로 재고 비용, 서비스 약속, 배송 옵션을 고려하면

00:13:16.010 --> 00:13:19.450
가장 가까운 건물이 반드시 최고의 이행 결과를 제공하는 것은 아닐 수 있습니다.

00:13:19.670 --> 00:13:22.510
온라인에서 두 가지 상품을 구매한 고객의 사례로 돌아가 보겠습니다.

00:13:22.810 --> 00:13:25.070
10분 거리에 있는 매장에 첫 번째 상품이 있습니다.

00:13:25.390 --> 00:13:28.110
창고에는 두 상품이 모두 있지만 거리는 더 멉니다.

00:13:28.110 --> 00:13:31.770
매장에서 첫 번째 상품을 보내고 창고에서 두 번째 상품을 보낸다면

00:13:31.770 --> 00:13:36.050
고객은 배송 기한에 맞춘 두 개의 소포를 받을 수 있지만 배송비는 상승합니다.

00:13:36.230 --> 00:13:38.530
창고에서 두 상품을 함께 보낼 수도 있습니다.

00:13:38.770 --> 00:13:40.170
약속된 배송 기한을 맞출 수 있다면

00:13:40.170 --> 00:13:43.350
해당 위치에서 하나의 소포로 보내는 것이 더 나은 선택일 수 있습니다.

00:13:43.530 --> 00:13:46.550
규칙에 따라 배송 횟수를 줄이고 배송비를 낮추는 것을 우선할 수 있습니다.

00:13:46.770 --> 00:13:49.370
하지만 두 상품을 함께 보내는 것보다 내일 도착하는 것이 더 중요하다면

00:13:49.370 --> 00:13:52.910
시스템은 한 상품은 매장에서, 다른 상품은 창고에서 보내 도록 선택할 수 있으며

00:13:52.910 --> 00:13:53.870
이를 분할 주문이라고 합니다.

00:13:53.870 --> 00:13:56.530
분할 주문이 곧 시스템 오류를 의미하는 것은 아닙니다.

00:13:56.690 --> 00:14:00.670
단일 위치에서 전체 주문을 제대로 처리할 수 없을 때 위도된 선택이 될 수 있습니다.

00:14:00.910 --> 00:14:04.590
기업은 설정된 이행 전략을 통해 언제 분할하는 것이 합리적인지 결정합니다.

00:14:04.790 --> 00:14:08.210
이와 같은 사고 방식은 온라인 구매 후 매장 배송, 시프롬 스토어 방식도 뒷받침합니다.

00:14:08.370 --> 00:14:12.570
고객이 웹사이트에서 주문하면 근처 매장의 재고가 있어 빠르게 배송할 수 있는 경우입니다.

00:14:12.730 --> 00:14:16.230
따라서 고객이 직접 방문한 적이 없더라도 해당 매장이 이행 거점이 됩니다.

00:14:16.530 --> 00:14:19.950
이는 온라인 구매 후 매장 수령, 클릭 엔드 컬렉트도 지원합니다.

00:14:19.950 --> 00:14:24.090
시스템은 재고 및 위치 정보를 활용해 수령 가능한 매장을 찾고

00:14:24.090 --> 00:14:29.870
고객에게는 지역 내 수령 선택지를 제공하며 기업은 주문을 적절한 곳으로 전달합니다.

00:14:30.310 --> 00:14:34.150
이러한 선택 사항들이 각 판매 채널마다 별도로 존재할 필요는 없습니다.

00:14:34.490 --> 00:14:40.930
통합된 이행 결정 프로세스가 없다면 웹사이트, 마켓플레이스, 콜센터는 각각 자체적 인나우팅 규칙이 필요할 수 있습니다.

00:14:41.150 --> 00:14:44.610
기업이 배송 정책을 변경하거나 매장을 이행 거점으로 활용하기 시작할 때

00:14:44.610 --> 00:14:47.370
팀은 여러 시스템을 일일이 업데이트해야 할 수 있습니다.

00:14:47.370 --> 00:14:51.350
이행 최적화는 이러한 결정 프로세스를 주문 여정 중 한 곳으로 통합합니다.

00:14:51.550 --> 00:14:56.650
웹사이트는 주문을 계속 받고 마켓플레이스도 주문을 받으며 매장은 계속 상품을 판매합니다.

00:14:56.850 --> 00:15:01.830
하지만 기업은 모든 채널의 규칙을 재설정하지 않고도 이행 거점 선정 방식을 변경할 수 있어

00:15:01.830 --> 00:15:07.030
재고 변동이나 배송 약속 변경, 새로운 이행 옵션 추가 시 더 큰 통제력을 갖게 됩니다.

00:15:07.250 --> 00:15:13.290
다만 이행 전략이 효과를 발휘하려면 각 정보를 보유한 시스템으로부터 필요한 데이터가 제때 전달되어야 합니다.

00:15:13.290 --> 00:15:19.590
주문이 들어오고 재고 업데이트가 수신되며 이행 파트너들이 업무를 전달받아 진행 상황을 다시 보고 해야 합니다.

00:15:19.770 --> 00:15:22.770
이 연결 작업은 공급자, 프로바이더에 달려 있습니다.

00:15:23.050 --> 00:15:25.950
공급자와 연결, 즉 건물로 들어가는 문입니다.

00:15:26.190 --> 00:15:31.010
지능형 주문 관리가 제 역할을 하려면 주변의 모든 것과 소통할 신뢰할 수 있는 방법이 필요합니다.

00:15:31.210 --> 00:15:32.850
공급자가 바로 그 역할을 합니다.

00:15:33.110 --> 00:15:39.210
공급자는 기본적으로 지능형 주문 관리와 다른 시스템 간의 주문 상세 정보와 이행 업데이트를 주고받는 연결고리입니다.

00:15:39.430 --> 00:15:42.690
정보는 양방향으로 흐름으로 아무도 수동으로 복사할 필요가 없습니다.

00:15:42.690 --> 00:15:45.210
여러 개의 배송문이 있는 건물을 상상해보세요.

00:15:45.470 --> 00:15:47.590
한 문은 온라인 스토어에서 주문을 받습니다.

00:15:47.870 --> 00:15:49.850
다른 문은 재고 시스템에 연결됩니다.

00:15:50.070 --> 00:15:52.890
세 번째 문은 창고나 배송 파트너에게 작업을 보냅니다.

00:15:53.090 --> 00:15:57.070
각 문에는 명확한 목적이 있으며 공급자가 각 문을 통과하는 정보를 관리합니다.

00:15:57.330 --> 00:15:59.890
마이크로소프트는 이러한 커넥터 중 일부를 직접 구축합니다.

00:16:00.110 --> 00:16:02.530
이를 자사 공급자, 퍼스트 파티의 프로바이더라고 부릅니다.

00:16:02.750 --> 00:16:05.790
이들은 지능형 주문 관리를 다이나믹스 365 서플라이 체인 매니지먼트,

00:16:05.790 --> 00:16:10.070
다이나믹스 365 커머스 또는 다이나믹스 365 파이낸스와 같은 앱에 연결합니다.

00:16:10.070 --> 00:16:15.250
지능형 주문 관리 내의 재고 및 이행 서비스도 이러한 공급자들 사용하여 데이터를 교환합니다.

00:16:15.410 --> 00:16:17.630
그런데 이미 다른 시스템을 사용하고 계실 것입니다.

00:16:17.810 --> 00:16:19.970
이때 타사 공급자, 서드 파티 프로바이더가 필요합니다.

00:16:20.130 --> 00:16:22.330
이들은 마이크로소프트가 구축하지 않은 서비스를 연결합니다.

00:16:22.510 --> 00:16:26.290
기존 전자상거래 플랫폼, 마켓플레이스, 물류회사 또는 창고 시스템일 수 있습니다.

00:16:26.530 --> 00:16:28.950
핵심은 특정 앱 세트를 강제로 사용하게 하는 것이 아닙니다.

00:16:29.150 --> 00:16:32.330
오히려 이미 비즈니스에 적합한 시스템을 연결할 수 있도록 하는 것입니다.

00:16:32.510 --> 00:16:35.650
배후에서 이러한 공급자는 파워 오토메이트 커넥터를 사용합니다.

00:16:35.850 --> 00:16:38.410
파워 플랫폼에는 200개 이상의 사전 구축된 커넥터가 있으므로

00:16:38.410 --> 00:16:40.290
시작할 수 있는 충분한 기반이 마련되어 있습니다.

00:16:40.590 --> 00:16:43.950
만약 적합한 것이 없다면 귀하 또는 파트너가 직접 공급자를 구축할 수도 있습니다.

00:16:44.150 --> 00:16:46.310
각 연결된 앱은 여전히 고유한 작업을 수행합니다.

00:16:46.490 --> 00:16:48.130
온라인 스토어는 구매를 처리합니다.

00:16:48.390 --> 00:16:50.030
재고 시스템은 재고를 추적합니다.

00:16:50.290 --> 00:16:52.430
이행 파트너는 주문을 포장하고 배송합니다.

00:16:52.670 --> 00:16:54.430
청구 시스템은 재물을 처리합니다.

00:16:54.430 --> 00:16:58.190
지능형 주문 관리는 이들 모두 간의 메시지와 다음 단계를 조정합니다.

00:16:58.370 --> 00:17:01.310
시스템이 업데이트를 공유하면 비즈니스는 전체 주문 프로세스에서

00:17:01.310 --> 00:17:03.090
무슨 일이 일어나고 있는지 확인할 수 있습니다.

00:17:03.290 --> 00:17:05.890
더 이상 별도의 화면에서 정보를 찾을 필요 없이

00:17:05.890 --> 00:17:08.850
인사이트와 전체적인 상황을 파악할 수 있습니다.

00:17:09.130 --> 00:17:12.690
공유된 정보는 주문 작업에 대한 훨씬 더 명확한 그림을 제공합니다.

00:17:12.930 --> 00:17:15.810
지능형 주문 관리에는 주문 및 이행 지표를 한 곳으로 모아주는

00:17:15.810 --> 00:17:17.890
파워 BI 대시보드가 포함되어 있습니다.

00:17:18.210 --> 00:17:20.850
고객 서비스 팀은 이동이 중단된 주문을 찾을 수 있습니다.

00:17:21.070 --> 00:17:23.790
운영팀은 차단된 경로 또는 이행 지연을 발견할 수 있습니다.

00:17:23.790 --> 00:17:27.190
그리고 비즈니스 리더는 전체 프로세스 전반에서 패턴을 찾을 수 있습니다.

00:17:27.390 --> 00:17:30.590
이러한 뷰가 없으면 지연은 단순한 개별 문제처럼 보일 수 있습니다.

00:17:30.830 --> 00:17:34.870
하지만 데이터가 모이면 팀은 특정 이행 파트너에서 많은 주문이 지연되거나

00:17:34.870 --> 00:17:38.930
특정 배송 옵션에서 예상보다 많은 예외가 발생한다는 것을 알 수 있습니다.

00:17:39.170 --> 00:17:41.390
대시보드가 스스로 문제를 해결하지는 못하지만

00:17:41.390 --> 00:17:43.670
정확히 어디를 확인해야 할지 알려줍니다.

00:17:43.890 --> 00:17:45.410
사무실 건물을 떠올려 보세요.

00:17:45.710 --> 00:17:48.430
지능형 주문 관리는 요청을 접수하는 안내 데스크,

00:17:48.810 --> 00:17:50.390
재고 현황을 보여주는 게시판,

00:17:50.390 --> 00:17:52.850
주문 이행 위치를 정하는 경로 플래너,

00:17:53.150 --> 00:17:56.370
그리고 모든 진행 상황을 확인하는 보고 시를 하나로 통합합니다.

00:17:56.590 --> 00:18:00.090
각 부분의 역할은 다르지만 주문이 모든 것을 연결합니다.

00:18:00.930 --> 00:18:04.390
결론적으로 하나의 주문, 하나의 조율된 여정인 셈이죠.

00:18:04.630 --> 00:18:06.790
오늘의 핵심 정보를 함께 해주셔서 감사합니다.

00:18:07.190 --> 00:18:09.630
지능형 주문 관리는 초기 접수부터 최종 청구까지

00:18:09.630 --> 00:18:12.430
전체 프로세스를 가로지르는 단일 직통 경로를 그려냅니다.

00:18:12.650 --> 00:18:14.350
즐겨 찾는 팟캐스트 플랫폼에서 구독하고

00:18:14.350 --> 00:18:15.670
다음 에피소드를 시청해 보세요.

00:18:15.670 --> 00:18:18.030
다이나믹스 365와 파워 플랫폼 이 보이지 않는 곳에서

00:18:18.030 --> 00:18:19.910
어떻게 작업을 처리하는지 정확히 확인하실 수 있습니다.