WEBVTT

00:00:00.120 --> 00:00:02.120
영업사원이 고객 주소를 업데이트 합니다.

00:00:02.320 --> 00:00:05.620
나중에 재무팀이 같은 기록을 열어보지만 여전히 예전 주소가 보입니다.

00:00:05.840 --> 00:00:07.280
그럼 어떤 주소가 맞는 걸까요?

00:00:07.480 --> 00:00:09.340
수년 동안 이 문제를 해결하려면 누군가 데이터를 내보내고,

00:00:09.600 --> 00:00:11.140
스프레드 시트를 편집하고, 이메일을 보내고,

00:00:11.320 --> 00:00:12.920
두 번째 앱에 동일한 업데이트를 두 번 입력해야 했습니다.

00:00:13.140 --> 00:00:16.180
다이나믹스 365 듀얼라이트, 듀얼라이트가 이를 바꿉니다.

00:00:16.340 --> 00:00:19.740
이 기능은 재무 및 운영 앱과 데이터버스 기반 고객 앱을 연결하여

00:00:19.740 --> 00:00:22.920
고객이나 주문 같은 공유 레코드가 자동으로 동기화되도록 합니다.

00:00:22.920 --> 00:00:26.300
M365 FM 위 밀코 피터스와 함께하는 이 지식 나눔 시간에는

00:00:26.300 --> 00:00:28.500
듀얼라이트에 대해 알기 쉽게 설명해 드리겠습니다.

00:00:28.820 --> 00:00:30.540
무엇이 이동하는지, 어떻게 이동하는지,

00:00:30.820 --> 00:00:33.480
듀얼라이트가 어디에 적합하고 어디에 적합하지 않은지 다룰 것입니다.

00:00:33.640 --> 00:00:36.880
먼저 이 기능이 필요하게 된 비즈니스 문제부터 시작하겠습니다.

00:00:38.320 --> 00:00:40.260
듀얼라이트가 해결하는 문제입니다.

00:00:40.700 --> 00:00:42.940
두 그룹이 같은 고객을 대상으로 작업하지만

00:00:42.940 --> 00:00:45.720
매일 완전히 다른 앱을 사용하는 기업을 상상해보세요.

00:00:46.040 --> 00:00:48.340
재무 및 운영 앱은 백오피스 업무를 처리합니다.

00:00:48.600 --> 00:00:52.100
여기에는 자금, 재고, 제품, 주문, 구매 및 공급망이 포함됩니다.

00:00:52.100 --> 00:00:55.260
이곳은 기업이 판매하는 것, 배송할 수 있는 것, 갚아야 할 돈,

00:00:55.540 --> 00:00:57.300
고객이 지불해야 할 금액을 추적하는 곳입니다.

00:00:57.420 --> 00:00:59.800
고객 앱은 고객과 더 가까운 업무에 집중합니다.

00:01:00.020 --> 00:01:02.380
영업팀은 리드를 추적하고 영업기회를 만듭니다.

00:01:02.560 --> 00:01:04.680
고객 서비스팀은 질문과 사례를 처리합니다.

00:01:04.880 --> 00:01:07.560
현장 서비스팀은 작업을 계획하고 현장의 인력을 파견합니다.

00:01:07.760 --> 00:01:10.040
프로젝트팀은 고객에게 약속한 작업을 추적합니다.

00:01:10.260 --> 00:01:12.040
다른 업무에는 다른 화면이 필요합니다.

00:01:12.260 --> 00:01:14.680
영업사원이 통화 후 연락처 정보를 수정하기 위해

00:01:14.680 --> 00:01:16.340
재무 화면을 뒤져야 할 필요는 없습니다.

00:01:16.660 --> 00:01:18.800
하지만 재무 담당자는 영업팀이 보는 것과

00:01:18.800 --> 00:01:21.020
동일한 고객 및 주문 세부 정보가 필요합니다.

00:01:21.240 --> 00:01:23.940
송장과 배송이 해당 정보에 의존하기 때문입니다.

00:01:24.140 --> 00:01:26.960
연결이 없으면 한 고객이 조용히 두 개의 레코드가 됩니다.

00:01:27.280 --> 00:01:29.120
영업팀은 노스인드 바이크스로 등록할 수 있고

00:01:29.120 --> 00:01:31.800
재무팀은 노스인드 바이시클 컴퍼니로 등록할 수 있습니다.

00:01:32.000 --> 00:01:33.560
이런 한 레코드에는 세 주소가 있는데

00:01:33.560 --> 00:01:36.060
다른 레코드는 여전히 예전 사무실로 송장을 보냅니다.

00:01:36.240 --> 00:01:38.180
두 레코드 모두 그 자체로는 합리적으로 보이지만

00:01:38.180 --> 00:01:40.500
더 이상 동일한 비즈니스 관계를 설명하지 못합니다.

00:01:40.660 --> 00:01:42.440
처음에는 작은 문제들이 나타납니다.

00:01:42.640 --> 00:01:43.960
다른 앱에서는 이름이 다르기 때문에

00:01:43.960 --> 00:01:45.660
고객을 찾을 수 없는 경우가 발생합니다.

00:01:45.860 --> 00:01:47.940
영업 담당자가 가격을 약속하거나 재고를 확인하지만

00:01:47.940 --> 00:01:50.020
정보가 운영 측면의 데이터와 일치하지 않습니다.

00:01:50.200 --> 00:01:51.360
재무팀은 주문을 처리해야 하지만

00:01:51.360 --> 00:01:53.360
고객 세부 정보를 확인하고 이메일을 보내고

00:01:53.360 --> 00:01:54.620
수동으로 다시 업데이트해야 합니다.

00:01:54.620 --> 00:01:56.720
그러면 그러한 작은 문제들이 쌓이게 됩니다.

00:01:56.920 --> 00:01:59.260
누군가 고객 데이터를 스프레드 시트로 내보냅니다.

00:01:59.440 --> 00:02:02.120
다른 사람이 몇 행을 수정하고 다른 곳으로 가져오기를 합니다.

00:02:02.320 --> 00:02:04.360
어떤 레코드가 먼저 나타날지 아무도 모르기 때문에

00:02:04.360 --> 00:02:06.440
또 다른 사람은 두 앱 모두에 새 고객을 입력합니다.

00:02:06.620 --> 00:02:08.340
곧 중복 데이터와 서로 다른 주소가 생겨나고

00:02:08.340 --> 00:02:09.960
데이터를 사용하는 시간보다 확인하는데

00:02:09.960 --> 00:02:10.960
더 많은 시간을 쓰게 됩니다.

00:02:11.180 --> 00:02:13.480
이 모든 문제는 사람들이 부주의해서 발생하는 것이 아닙니다.

00:02:13.660 --> 00:02:15.960
시스템이 사람들에게 연결고리 역할을 요구하기 때문에 발생합니다.

00:02:16.180 --> 00:02:17.320
사람들은 데이터를 복사합니다.

00:02:17.580 --> 00:02:19.360
사람들은 어떤 앱을 먼저 사용해야 하는지 기억해야 합니다.

00:02:19.360 --> 00:02:22.020
사람들은 오류가 이미 다른 팀에 전달된 후에야 실수를 발견합니다.

00:02:22.180 --> 00:02:23.940
이러한 방식은 비즈니스 시스템이 분리되어 있고

00:02:23.940 --> 00:02:25.720
팀들이 지연을 감수하던 시절에는 통했습니다.

00:02:25.720 --> 00:02:29.900
하지만 영업, 서비스, 재무, 운영 부서가 하루 종일 동일한 고객 정보가 필요할 때

00:02:29.900 --> 00:02:32.080
스프레드 시트는 부적절한 전달 도구가 됩니다.

00:02:32.260 --> 00:02:33.980
간단한 주문 상담을 생각해보세요.

00:02:34.220 --> 00:02:37.580
고객이 영업팀에 전화해 다음 주에 배송이 가능한가요? 라고 묻습니다.

00:02:37.800 --> 00:02:39.100
그리고 비용은 얼마인가요?

00:02:39.320 --> 00:02:42.700
영업팀은 답변을 위해 제품, 가격, 재고 정보가 필요합니다.

00:02:42.880 --> 00:02:45.840
고객이 동의하면 재무 및 운영팀은 판매를 처리하기 위해

00:02:45.840 --> 00:02:47.940
정확한 고객 및 주문 정보가 필요합니다.

00:02:48.140 --> 00:02:50.120
양쪽 모두 동일한 사실 확인이 필요합니다.

00:02:50.320 --> 00:02:53.220
영업팀은 영업 담당자가 사용하는 앱에서 해당 정보가 필요합니다.

00:02:53.220 --> 00:02:57.560
재무 및 운영팀은 주문, 자금, 배송을 관리하는 앱에서 그 정보가 필요합니다.

00:02:57.700 --> 00:03:01.040
목표는 모든 팀을 하나의 거대한 화면에 강제로 맞추려는 것이 아닙니다.

00:03:01.200 --> 00:03:04.340
목표는 공유된 레코드가 명확하고 합의된 경로를 따르도록 하는 것입니다.

00:03:04.540 --> 00:03:07.460
이 지점에서 바로 이중쓰기, 듀얼라이트가 등장합니다.

00:03:07.660 --> 00:03:09.980
그렇다면 이중쓰기란 정확히 무엇일까요?

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

00:03:12.260 --> 00:03:16.820
이중쓰기는 다이나믹스 365 파이낸스 엔드 오퍼레이션즈 앱과 데이터버스 간의 선택된 데이터를

00:03:16.820 --> 00:03:19.480
동기화 상태로 유지하는 마이크로소프트 위 내장형 연결 기능입니다.

00:03:19.480 --> 00:03:23.360
데이터버스는 수많은 마이크로소프트 비즈니스 앱을 뒷받침하는 공통 데이터 기반입니다.

00:03:23.520 --> 00:03:28.260
다이나믹스 365 세일즈, 커스터머 서비스, 필드 서비스 및 프로젝트 오퍼레이션즈 위 일부가 이를 사용합니다.

00:03:28.420 --> 00:03:30.740
파워 앱스와 파워 오토메이트도 이를 사용할 수 있습니다.

00:03:30.940 --> 00:03:34.440
이중쓰기를 이해하기 위해 데이터버스가 모든 레코드를 어떻게 저장하는지 알 필요는 없습니다.

00:03:34.720 --> 00:03:38.560
그저 다이나믹스 365의 고객 앱 측에 있는 공통 데이터 영역이라고 생각하세요.

00:03:38.780 --> 00:03:41.620
프론트 오피스와 백오피스가 있는 사무실 건물을 상상해보세요.

00:03:41.620 --> 00:03:44.140
프론트 오피스는 고객과의 대화를 처리합니다.

00:03:44.320 --> 00:03:47.660
영업사원, 서비스 상담원, 현장 작업자들이 여기에 해당합니다.

00:03:47.840 --> 00:03:52.180
이들은 고객과 소통하고 요청을 추적하며 업무를 관리하는 데 도움이 되는 화면이 필요합니다.

00:03:52.340 --> 00:03:54.620
백오피스는 회사를 유지하는 업무를 처리합니다.

00:03:54.860 --> 00:03:58.420
재무 기록, 재고, 주문, 구매, 배송 등이 이에 해당합니다.

00:03:58.600 --> 00:04:04.300
두 사무실 모두 같은 회사를 위해 일하지만 적절한 연결고리가 없으면 누군가 직접 정보를 한쪽에서 다른 쪽으로 옮겨야 합니다.

00:04:04.500 --> 00:04:08.220
인쇄된 양식을 전달하거나 이메일을 보내거나 다른 시스템의 데이터를 복사합니다.

00:04:08.220 --> 00:04:12.260
업무는 처리되지만 시간이 더 걸리고 그 과정에서 세부사항이 변경될 수 있습니다.

00:04:12.460 --> 00:04:15.420
이중쓰기는 두 사무실 사이에 직원이 배치된 내부 문과 같습니다.

00:04:15.740 --> 00:04:20.540
한쪽에서 지원되는 레코드가 변경되면 이중쓰기는 그 문을 통해 관련 변경사항을 반대편으로 전달합니다.

00:04:20.720 --> 00:04:22.920
모든 앱을 하나의 거대한 앱으로 합치는 것이 아닙니다.

00:04:23.100 --> 00:04:24.820
영업팀은 여전히 영업앱에서 작업할 수 있습니다.

00:04:25.060 --> 00:04:26.880
재무팀은 여전히 재무앱에서 작업할 수 있습니다.

00:04:27.080 --> 00:04:30.820
각 팀은 업무에 맞게 구축된 화면을 유지하면서 선택된 공유정보만 보이지 않는 곳에서 연결됩니다.

00:04:31.020 --> 00:04:33.040
지원되는 서포티드 이라는 단어가 중요합니다.

00:04:33.040 --> 00:04:36.340
듀얼라이트는 양쪽 시스템의 모든 데이터를 맹목적으로 복사하지 않습니다.

00:04:36.500 --> 00:04:39.340
서로 연관된 레코드 간의 정의된 연결을 통해 작동합니다.

00:04:39.580 --> 00:04:42.640
마이크로소프트는 이러한 연결을 테이블 맵, 테이블 맵스 이라고 부릅니다.

00:04:42.840 --> 00:04:45.420
테이블은 앱이 한 종류의 레코드를 보관하는 장소일 뿐입니다.

00:04:45.620 --> 00:04:47.540
고객 테이블에는 고객 레코드가 저장됩니다.

00:04:47.740 --> 00:04:49.580
제품 테이블에는 제품 레코드가 저장됩니다.

00:04:49.780 --> 00:04:51.760
주소 테이블에는 주소 상세 정보가 저장됩니다.

00:04:51.760 --> 00:04:56.860
테이블 맵은 파이낸스 앤드 오퍼레이션즈 측의 어느 테이블이 데이터버스 위 어느 테이블과 연결되는지 듀얼라이트에 알려줍니다.

00:04:56.960 --> 00:04:59.440
테이블 맵을 합의된 번역 시트라고 생각하십시오.

00:04:59.580 --> 00:05:01.380
한 열은 한쪽의 레코드를 식별합니다.

00:05:01.640 --> 00:05:04.280
다른 열은 그와 일치하는 반대편의 레코드를 식별합니다.

00:05:04.500 --> 00:05:07.360
시트의 나머지 부분은 어떤 필드들이 서로 대응되는지 설명합니다.

00:05:07.540 --> 00:05:10.020
이름, 전화번호, 주소 행과 같은 것들입니다.

00:05:10.240 --> 00:05:11.900
그 합의가 연결 규칙을 제공합니다.

00:05:12.140 --> 00:05:15.720
그렇지 않으면 두 앱은 서로 다른 레이블을 사용하거나 같은 정보를 다른 곳에 저장할 수도 있습니다.

00:05:15.940 --> 00:05:18.820
맵은 듀얼라이트에게 그러한 정보들이 어떻게 연관되는지 알려줍니다.

00:05:19.020 --> 00:05:21.240
따라서 앱은 매번 사람이 해석해줄 필요가 없습니다.

00:05:21.240 --> 00:05:26.440
흔히 듀얼라이트라는 이름을 들으면 모든 변경사항이 항상 양방향으로 이동한다고 생각하기 쉽습니다.

00:05:26.560 --> 00:05:27.480
때로는 그렇습니다.

00:05:27.740 --> 00:05:32.560
지원되는 양방향 맵의 경우 데이터버스에서의 변경사항이 파이낸스 앤드 오퍼레이션즈 위 관련 레코드를 업데이트할 수 있습니다.

00:05:32.720 --> 00:05:36.740
파이낸스 앤드 오퍼레이션즈에서 지원되는 변경사항 역시 데이터버스 위 관련 레코드를 업데이트할 수 있습니다.

00:05:36.940 --> 00:05:38.980
양쪽 모두 동일한 공유 레코드에 참여할 수 있습니다.

00:05:39.240 --> 00:05:41.080
그것이 바로 듀얼 이중이라는 부분입니다.

00:05:45.720 --> 00:05:51.960
사용자가 지원되는 레코드를 업데이트하면 연결을 통해 작업이 진행중인 상태에서 업데이트가 전송됩니다.

00:05:51.960 --> 00:05:55.040
거의 실시간이라는 것이 마법이나 지연시간 0을 의미하는 것은 아닙니다.

00:05:55.200 --> 00:05:59.280
하루에 한 번 파일 교환을 하는 방식이 아니라 실시간 비즈니스 업무를 위해 연결이 구축되었다는 뜻입니다.

00:05:59.440 --> 00:06:03.220
누군가 세부 정보를 변경하면 관련팀은 내일 아침까지 기다릴 필요 없이 즉시 확인할 수 있습니다.

00:06:03.460 --> 00:06:05.020
이것이 팀의 업무 방식을 바꿉니다.

00:06:05.180 --> 00:06:07.800
프런트 오피스는 백오피스에서 오는 데이터를 사용할 수 있습니다.

00:06:08.020 --> 00:06:11.000
백오피스는 고객 대면 앱에서 지원되는 업데이트를 받을 수 있습니다.

00:06:11.260 --> 00:06:12.860
데이터버스는 한쪽의 데이터 기반이 되고

00:06:12.860 --> 00:06:15.880
파이낸스 앤드 오퍼레이션즈는 다른 쪽의 운영 기반이 되며

00:06:15.880 --> 00:06:18.660
듀얼라이트는 승인된 공유 레코드를 연결 상태로 유지합니다.

00:06:18.660 --> 00:06:21.380
하지만 열려있는 내부 통로에는 규칙이 필요합니다.

00:06:21.560 --> 00:06:23.220
레코드가 양방향으로 이동하게 하려면

00:06:23.220 --> 00:06:25.080
레코드가 어디서 시작되어야 하는지

00:06:25.080 --> 00:06:26.480
누가 변경할 수 있는지

00:06:26.480 --> 00:06:29.420
두 앱의 정보가 다를 경우 어느 쪽을 우선할지 알아야 합니다.

00:06:29.600 --> 00:06:30.780
어떤 데이터를 이동할 수 있고

00:06:30.780 --> 00:06:32.660
어느 시스템이 그 데이터를 소유할까요?

00:06:32.840 --> 00:06:35.960
그렇다면 듀얼라이트는 어떤 레코드를 연결 상태로 유지할 수 있을까요?

00:06:36.120 --> 00:06:39.300
흔한 예로는 여러 부서가 매일 공유하는 레코드부터 시작합니다.

00:06:39.300 --> 00:06:44.320
고객 레코드, 주소, 연락처, 제품, 공급업체, 회사 세부 정보,

00:06:44.600 --> 00:06:46.560
그리고 재무 및 채무용 참조 정보가 있습니다.

00:06:46.840 --> 00:06:49.100
고객 레코드에 대해 잠시 생각해 보겠습니다.

00:06:49.420 --> 00:06:54.000
영업부서는 고객 이름, 주요 연락처, 전화번호, 배송 주소가 필요합니다.

00:06:54.220 --> 00:06:56.960
재무부서는 법적 고객 레코드, 청구 세부 정보,

00:06:57.300 --> 00:06:59.120
주문 및 송장에 필요한 정보가 필요합니다.

00:06:59.320 --> 00:07:01.120
각 부서가 별도의 고객 목록을 관리하면

00:07:01.120 --> 00:07:04.580
회사는 고객 서비스 대신 레코드를 대조하는 데 시간을 허비하게 됩니다.

00:07:04.820 --> 00:07:06.220
적절한 듀얼라이트 맵이 설정되면

00:07:06.220 --> 00:07:08.900
각 팀은 연결된 고객 세부 정보를 바탕으로 작업할 수 있습니다.

00:07:09.100 --> 00:07:12.320
그렇다고 해서 영업 사용자가 갑자기 재무 앱을 배워야 한다는 뜻은 아닙니다.

00:07:12.500 --> 00:07:16.140
이는 영업 사용자는 다이나믹스 365세일즈에서 고객 정보를 다루고,

00:07:16.620 --> 00:07:19.840
재무 사용자는 재무 앱에서 관련 고객 정보를 다룰 수 있음을 의미합니다.

00:07:20.040 --> 00:07:23.080
고객은 양쪽 모두에서 동일한 고객으로 인식됩니다.

00:07:23.340 --> 00:07:24.540
주소 또한 중요합니다.

00:07:24.780 --> 00:07:26.660
고객은 청구지 주소, 배송지 주소,

00:07:26.940 --> 00:07:29.600
그리고 서비스 작업자가 방문해야 할 현장 주소를 가질 수 있습니다.

00:07:29.840 --> 00:07:31.140
각 주소마다 역할이 다르기 때문에

00:07:31.140 --> 00:07:34.820
이러한 세부 정보를 단순히 하나의 상자에 복사된 일반 텍스트로 처리할 수는 없습니다.

00:07:34.820 --> 00:07:38.200
듀얼라이트는 이러한 관계에 필요한 공유 레코드 구조를 지원합니다.

00:07:38.360 --> 00:07:40.040
연락처도 동일한 패턴을 따릅니다.

00:07:40.280 --> 00:07:43.960
한 고객 사는 구매자, 매입 채무 담당자, 서비스 관리자를 둘 수 있습니다.

00:07:44.200 --> 00:07:46.360
영업 부서는 누가 의사결정을 내리는지 알아야 합니다.

00:07:46.580 --> 00:07:48.860
재무 부서는 청구 관련 문의를 어디로 보내야 할지 알아야 합니다.

00:07:49.060 --> 00:07:51.340
서비스 부서는 현장에서 누가 기다리고 있는지 알아야 합니다.

00:07:51.540 --> 00:07:54.220
연결된 레코드는 각 팀이 모든 앱에서 정보를 재부축할 필요 없이

00:07:54.220 --> 00:07:56.300
고객과 관련된 사람들을 확인할 수 있도록 돕습니다.

00:07:56.540 --> 00:07:57.780
제품 또한 흔한 예입니다.

00:07:58.040 --> 00:08:00.040
영업 담당자는 회사가 무엇을 판매하는지,

00:08:00.040 --> 00:08:03.080
제품 가격은 얼마인지, 재고가 있는지 알아야 합니다.

00:08:03.240 --> 00:08:08.440
이러한 정보는 보통 제품, 재고, 구매, 이행 업무가 관리되는 운영 측면에서 나옵니다.

00:08:08.640 --> 00:08:11.920
그래서 제품 정보는 재무 및 운영에서 시작되는 경우가 많습니다.

00:08:12.180 --> 00:08:14.920
운영팀이 그곳에서 제품을 생성하고 준비합니다.

00:08:15.160 --> 00:08:16.880
제품이 고객되면 업무에 준비되면

00:08:16.880 --> 00:08:21.100
듀얼라이트를 통해 관련 제품 세부 정보를 데이터버스로 전송할 수 있습니다.

00:08:21.360 --> 00:08:24.480
그러면 영업 사용자는 누군가 제품 목록을 다시 입력할 필요 없이

00:08:24.480 --> 00:08:27.020
자신의 앱에서 제품을 선택하고 논의할 수 있습니다.

00:08:27.240 --> 00:08:31.420
이는 영업 상담이 비즈니스가 실제로 제공할 수 있는 범위 내에서 이루어지도록 돕습니다.

00:08:31.680 --> 00:08:35.480
가격과 재고 세부 정보도 연결된 앱을 통해 영업 부서에 도달할 수 있습니다.

00:08:35.720 --> 00:08:39.960
항목 존재 여부, 가격 변동 또는 재고가 약속을 이행할 수 있는지 추측하는 대신

00:08:39.960 --> 00:08:43.660
영업팀은 운영 측면과 연동된 정보를 바탕으로 업무를 수행할 수 있습니다.

00:08:43.880 --> 00:08:46.720
그렇다고 해서 훌륭한 영업적 판단이 필요 없다는 것은 아닙니다.

00:08:46.900 --> 00:08:49.120
이는 영업 담당자가 기본적인 세부 사항을 확인하려고

00:08:49.120 --> 00:08:51.340
창고에 전화해야 하는 불필요한 이유를 하나 없애줍니다.

00:08:51.340 --> 00:08:54.880
공급업체 정보도 비즈니스 프로세스에 필요한 곳으로 연결할 수 있습니다.

00:08:55.060 --> 00:08:59.360
회사 세부 정보, 조직 구조, 재무참조 데이터, 세금 참조 데이터는

00:08:59.360 --> 00:09:01.800
고객 측과 운영 측 모두에서 중요할 수 있습니다.

00:09:02.040 --> 00:09:05.400
정확한 레코드는 회사가 사용하는 앱과 프로세스에 따라 다르지만

00:09:05.400 --> 00:09:06.860
패턴은 동일하게 유지됩니다.

00:09:07.060 --> 00:09:09.900
양쪽에서 같은 의미를 가져야 하는 레코드를 공유하세요.

00:09:10.160 --> 00:09:13.300
이제 모든 레코드가 양방향으로 이동해야 한다고 가정하지 마십시오.

00:09:13.460 --> 00:09:15.340
일부 앱은 양방향 업데이트를 지원합니다.

00:09:15.560 --> 00:09:18.360
변경사항은 데이터버스에서 시작하여 파이낸�스 엔드 오퍼레이션즈로 이동하거나

00:09:18.360 --> 00:09:21.060
파이낸스 엔드 오퍼레이션즈에서 시작하여 데이터버스로 이동할 수 있습니다.

00:09:21.240 --> 00:09:23.420
이 방식은 양쪽 모두 승인된 세부 정보를 업데이트할

00:09:23.420 --> 00:09:25.420
정당한 비즈니스 사유가 있는 레코드에 적합합니다.

00:09:25.600 --> 00:09:27.320
다른 맵은 단방향으로 실행됩니다.

00:09:27.540 --> 00:09:28.840
제품이 유용한 예가 됩니다.

00:09:29.180 --> 00:09:32.340
많은 기업에서 제품 생성은 파이낸스 엔드 오퍼레이션즈가 담당하는데

00:09:32.340 --> 00:09:36.140
이는 운영 부서가 제품 마스터, 재고, 단위 및 판매와 배송에 필요한

00:09:36.140 --> 00:09:37.820
기타 세부 정보를 관리하기 때문입니다.

00:09:37.980 --> 00:09:40.100
그런 다음 제품 정보는 데이터버스로 흘러들어가

00:09:40.100 --> 00:09:41.900
영업 및 서비스팀이 사용할 수 있게 됩니다.

00:09:41.900 --> 00:09:43.380
이는 명확한 규칙입니다.

00:09:43.560 --> 00:09:46.300
제품에 대해 두 팀이 경쟁하는 버전을 만들 필요는 없습니다.

00:09:46.600 --> 00:09:48.260
한쪽이 제품을 생성하고 관리하며

00:09:48.260 --> 00:09:50.700
다른 한쪽은 이를 받아 업무의 일부로 사용합니다.

00:09:50.900 --> 00:09:53.020
모든 공유 레코드에는 그러한 결정이 필요합니다.

00:09:53.180 --> 00:09:54.700
이 레코드는 어디에서 시작됩니까?

00:09:54.840 --> 00:09:55.920
누가 편집할 수 있습니까?

00:09:56.140 --> 00:09:58.720
이름, 주소, 가격 또는 분류가 잘못된 것처럼 보이면

00:09:58.720 --> 00:09:59.640
어느 팀이 수정합니까?

00:09:59.800 --> 00:10:01.040
이러한 질문은 간단해 보이지만

00:10:01.040 --> 00:10:02.700
나중에 발생할 많은 혼란을 방지해줍니다.

00:10:02.880 --> 00:10:05.000
연결을 통해 변경사항이 매우 빠르게 이동할 수 있습니다.

00:10:05.200 --> 00:10:07.060
변경사항의 소유자가 누구인지 아무도 합의하지 않았다면

00:10:07.060 --> 00:10:08.440
실수도 똑같이 빠르게 전파될 수 있습니다.

00:10:08.440 --> 00:10:10.300
레코드에 대한 소유자를 선택하고 필요한 경우

00:10:10.300 --> 00:10:12.900
해당 레코드 내의 개별 세부 정보에 대한 소유자도 선택하십시오.

00:10:12.980 --> 00:10:15.140
예를 들어 영업부서가 고객의 관계 세부 정보와

00:10:15.140 --> 00:10:16.840
주요 연락처 정보를 소유할 수 있습니다.

00:10:17.080 --> 00:10:18.620
재무부서는 결제 관련 세부 정보를

00:10:18.620 --> 00:10:21.260
운영부서는 제품 및 재고 세부 정보를 소유할 수 있습니다.

00:10:21.480 --> 00:10:23.640
정확한 분담은 비즈니스 방식에 따라 다르지만

00:10:23.640 --> 00:10:26.600
이를 문서화하고 앱을 사용하는 사람들이 이해해야 합니다.

00:10:26.800 --> 00:10:29.060
또한 듀얼라이트가 데이터버스를 확장한 후 보게 될

00:10:29.060 --> 00:10:32.480
파티, 당사자와 컴퍼니, 회사라는 두 가지 용어가 있습니다.

00:10:32.480 --> 00:10:35.620
파티는 사람이나 조직을 일관된 방식으로 처리하기 위한

00:10:35.620 --> 00:10:37.220
마이크로소프트 위 방식입니다.

00:10:37.380 --> 00:10:40.420
이는 모든 관계를 별개에 관련 없는 레코드로 취급하지 않고

00:10:40.420 --> 00:10:44.060
사람, 조직, 연락처 및 주소를 연결하는 데 도움이 됩니다.

00:10:44.300 --> 00:10:46.940
컴퍼니는 데이터버스가 파이낸스 앤드 오퍼레이션즈에서

00:10:46.940 --> 00:10:49.340
사용하는 비즈니스 회사 컨텍스트를 이해하도록 돕습니다.

00:10:49.520 --> 00:10:51.900
첫날부터 두 용어의 전문가가 될 필요는 없습니다.

00:10:52.260 --> 00:10:54.440
재무 및 운영 앱은 레코드가 양측을 오갈 때

00:10:54.440 --> 00:10:56.920
고객 앱이 인식해야 하는 비즈니스 구조를 처리함으로

00:10:56.920 --> 00:10:58.720
그 존재를 알아두기만 하면 됩니다.

00:10:58.720 --> 00:11:00.640
레코드가 양방향으로 이동할 수 있게 되면

00:11:00.640 --> 00:11:04.180
데이터 자체만큼이나 해당 레코드를 둘러싼 프로세스도 중요해집니다.

00:11:04.300 --> 00:11:06.760
변경사항이 앱 간에 어떻게 이동하는지 살펴보겠습니다.

00:11:07.160 --> 00:11:10.640
시스템을 통해 변경사항 하나가 어떻게 처리되는지 실제로 확인해봅시다.

00:11:10.840 --> 00:11:13.980
영업 담당자가 새 사무실로 이전한 고객과 통화 중입니다.

00:11:14.200 --> 00:11:17.300
대화 중에 담당자는 다이나믹스 365세일즈에서

00:11:17.300 --> 00:11:19.640
고객 레코드를 열고 주소를 업데이트합니다.

00:11:19.900 --> 00:11:20.500
간단하죠?

00:11:20.760 --> 00:11:22.300
그런 다음 레코드를 저장합니다.

00:11:22.540 --> 00:11:24.360
바로 여기서 흥미로운 부분이 시작됩니다.

00:11:24.360 --> 00:11:28.600
세일즈는 해당 변경사항을 고객 대면 앱의 데이터 측면인 데이터버스에 저장합니다.

00:11:28.780 --> 00:11:33.660
그러면 듀얼라이트 가이사이트와 재무 및 운영 사이의 고객 및 주소 정보를 연결하는 맵을 확인합니다.

00:11:33.860 --> 00:11:35.860
해당 변경사항을 자동으로 전송합니다.

00:11:36.140 --> 00:11:39.540
누군가 가져가기를 기다리며 공유 폴더에 쌓여있는 내보내기 파일 같은 것은 없습니다.

00:11:39.820 --> 00:11:41.100
이 주소를 업데이트해주세요.

00:11:41.260 --> 00:11:43.660
라는 메모와 함께 재무팀에 이메일을 보낼 필요도 없습니다.

00:11:43.980 --> 00:11:45.820
맵은 이미 연결된 필드를 알고 있으며

00:11:45.820 --> 00:11:49.940
지원되는 변경사항을 재무 및 운영에 관련 고객 레코드로 바로 보냅니다.

00:11:49.940 --> 00:11:53.680
따라서 재무 사용자는 나중에 해당 고객 레코드를 열어 업데이트된 주소를 확인하고

00:11:53.680 --> 00:11:56.520
지체 없이 주문을 처리하거나 송장을 준비할 수 있습니다.

00:11:56.720 --> 00:11:59.160
그것이 바로 실질적인 결과이며 아주 명확합니다.

00:11:59.340 --> 00:12:00.900
두 사람은 서로 다른 앱에서 작업하지만

00:12:00.900 --> 00:12:03.660
누구도 같은 고객 세부 정보를 다시 입력할 필요가 없습니다.

00:12:03.940 --> 00:12:07.020
영업 담당자는 고객 상담에 최적화된 화면에서 작업합니다.

00:12:07.260 --> 00:12:10.200
재무 사용자는 재무 업무에 맞춰진 화면에서 작업합니다.

00:12:10.440 --> 00:12:14.220
각 담당자는 자신이 필요한 고객 정보를 바로 필요한 곳에서 확인합니다.

00:12:14.440 --> 00:12:16.440
이 이동은 반대 방향으로도 작동합니다.

00:12:16.440 --> 00:12:20.660
재무팀이 재무 및 운영에서 지원되는 고객 정보를 업데이트한다고 가정해보세요.

00:12:20.900 --> 00:12:24.820
재무 사용자가 운영 고객 레코드에 속한 세부 정보를 수정한다고 합시다.

00:12:25.020 --> 00:12:27.480
듀얼라이트는 일치하는 맵을 역으로 사용하여

00:12:27.480 --> 00:12:29.740
해당 관련 업데이트를 데이터버스로 보냅니다.

00:12:29.960 --> 00:12:33.560
그러면 세일즈 나다른 데이터버스 기반 앱에서 이를 가져올 수 있습니다.

00:12:33.860 --> 00:12:36.840
이 연결은 일상적인 업무를 위해 동기식으로 작동합니다.

00:12:37.040 --> 00:12:40.820
동기식이라는 것은 앱이 20분 뒤에 실행될지 모르는 백그라운드 작업에 넘기는 대신

00:12:40.820 --> 00:12:44.380
동일한 작업 순간에 관련 업데이트를 완료하려고 시도한다는 의미입니다.

00:12:44.380 --> 00:12:46.460
연결이 업데이트를 완료할 수 없는 경우

00:12:46.460 --> 00:12:51.040
누군가 불일치를 발견할 때까지 숨겨두는 것이 아니라 즉시 주의가 필요합니다.

00:12:51.220 --> 00:12:53.760
이러한 동작은 공유 비즈니스 레코드에 적합합니다.

00:12:53.940 --> 00:12:56.760
일괄 작업이 실행되지 않아 고객 주소, 제품 세부 정보 또는 기타 공유 정보가

00:12:56.760 --> 00:12:59.240
몇 시간 동안 일치하지 않는 상태로 방치되는 것을 원치 않을 테니까요.

00:12:59.400 --> 00:13:02.240
사람들은 지금 당장 화면에 보이는 것을 바탕으로 위사결정을 내립니다.

00:13:02.460 --> 00:13:05.500
따라서 이 연결은 작업이 진행되는 동안 양쪽을 긴밀하게 유지합니다.

00:13:05.720 --> 00:13:08.360
진행 중인 작업이라도 때로는 제어된 일시 중지가 필요합니다.

00:13:08.360 --> 00:13:11.820
이중 쓰기, 듀얼라이트, N은 재생, 일시 중지, 따라잡기 옵션이 포함되어 있습니다.

00:13:12.000 --> 00:13:15.000
재생은 맵이 실행 중이며 지원되는 변경 사항이 정상적으로 전송됨을 의미합니다.

00:13:15.140 --> 00:13:20.200
일시 중지는 팀이 계획된 작업을 수행하거나 문제를 조사하거나 변경 사항을 안전하게 관리해야 할 때 맵을 일시적으로 중단합니다.

00:13:20.340 --> 00:13:22.600
하지만 일시 중지는 연구적인 주차 공간이 아닙니다.

00:13:22.780 --> 00:13:26.360
맵이 일시 중지된 동안에는 제한된 시간과 공간 내에서 변경 사항이 대기열에 쌓일 수 있습니다.

00:13:26.600 --> 00:13:29.740
맵이 다시 시작되면 따라잡기 기능이 대기 중인 변경 사항을 처리합니다.

00:13:29.740 --> 00:13:32.640
이는 팀이 계획된 중단 이후 복구하는 데 도움이 됩니다.

00:13:32.860 --> 00:13:36.960
하지만 누군가는 해당 일시 중지를 책임지고 언제 맵을 다시 시작해야 할지 알고 있어야 합니다.

00:13:37.140 --> 00:13:40.820
일상 업무에서의 모든 것이 시작되기 전에 초기 동기화라는 또 다른 단계가 있습니다.

00:13:41.100 --> 00:13:44.600
초기 동기화는 양쪽의 기존 레코드를 공유된 시작 지점으로 가져옵니다.

00:13:44.780 --> 00:13:49.440
파이낸스 앤드 오퍼레이션즈의 고객이 이미 있고 데이터버스에 고객 레코드가 있는 회사를 생각해보십시오.

00:13:49.540 --> 00:13:53.420
연결이 켜지자마자 모든 기존 레코드가 이미 완벽하게 일치한다고 가정할 수는 없습니다.

00:13:53.760 --> 00:13:54.860
시작선이 필요합니다.

00:13:54.860 --> 00:14:00.000
초기 동기화는 사람들이 실시간 업데이트에 의존하기 전에 기존 데이터를 가져오는데 도움이 됩니다.

00:14:00.220 --> 00:14:07.440
중복 레코드, 불완전한 주소, 오래된 테스트 데이터는 동기화가 시작된다고 해서 마법처럼 스스로 정리되지 않으므로 주의가 필요합니다.

00:14:07.660 --> 00:14:11.520
레코드가 합의된 규칙을 따르지 않으면 오히려 문제를 더 빠르게 일으킬 수 있습니다.

00:14:11.780 --> 00:14:16.140
맵이 실행되면 이중 쓰기를 관리하는 사람들은 상태를 확인할 수 있는 명확한 공간이 필요합니다.

00:14:16.340 --> 00:14:22.360
이중 쓰기는 통합된 활동 및 오류 로그를 제공하여 관리자가 연결이 처리한 내용과 문제가 발생한 위치를 확인할 수 있게 합니다.

00:14:22.360 --> 00:14:24.940
또한 경고 및 임계 값을 설정할 수도 있습니다.

00:14:25.200 --> 00:14:30.160
즉, 사용자가 업데이트 누락이나 실패를 통해 문제를 발견하기 전에 담당자가 미리 알 수 있습니다.

00:14:30.420 --> 00:14:33.360
모든 오류에는 원인이 있기 때문에 이러한 지원 보기가 중요합니다.

00:14:33.540 --> 00:14:35.220
필수 필드가 누락되었을 수도 있습니다.

00:14:35.500 --> 00:14:37.440
관련 레코드가 아직 도착하지 않았을 수도 있습니다.

00:14:37.680 --> 00:14:40.200
누군가 맵에 맞지 않는 방식으로 데이터를 변경했을 수도 있습니다.

00:14:40.440 --> 00:14:44.580
원인을 수정하지 않고 실패한 레코드를 다시 시도하면 보통 똑같은 오류가 다시 발생합니다.

00:14:44.800 --> 00:14:49.360
잘 운영되는 이중 쓰기 설정은 연결을 모니터링하고 오류의 근본 원인을 해결하며

00:14:49.360 --> 00:14:52.880
실제로 연결 상태를 유지해야 하는 레코드에 집중하도록 맵을 관리합니다.

00:14:53.080 --> 00:14:54.720
이중 쓰기가 가장 적합한 곳.

00:14:54.840 --> 00:15:04.080
이중 쓰기는 귀하의 비즈니스가 다이나믹스 365 파이낸스 또는 서플라이 체인 매니지먼트와 함께 영업, 고객 서비스, 현장 서비스, 프로젝트 운영과 같은 고객 대면 앱을 사용할 때 가장 적합합니다.

00:15:04.260 --> 00:15:07.420
이러한 앱은 동일한 비즈니스 대화에 서로 다른 부분을 지원합니다.

00:15:07.420 --> 00:15:13.680
한 팀은 고객과 상담하고 다른 팀은 배송 계획, 재고 관리, 비용 추적 또는 청구서 발송을 담당합니다.

00:15:13.840 --> 00:15:20.780
두 그룹 모두 하루 동안 관련 레코드를 기반으로 작업해야 할 때 듀얼라이트를 사용하면 모두에게 동일한 앱을 강요하지 않고도 작업을 연결할 수 있습니다.

00:15:21.000 --> 00:15:23.520
잠재 고객에서 현금화까지의 과정을 예로 들어보겠습니다.

00:15:23.820 --> 00:15:27.300
영업 담당자는 다이나믹스 365세일즈에서 잠재 고객과 상담합니다.

00:15:27.520 --> 00:15:31.940
그들은 연락처를 추적하고 제품을 논의하고 견적을 작성하며 주문 단계로 나아갑니다.

00:15:31.940 --> 00:15:39.400
상담하는 동안 영업 담당자는 회사 재무부서와 관련된 고객 세부 정보, 제품 정보, 가격 및 주문 정보가 필요합니다.

00:15:39.620 --> 00:15:44.680
판매가 확정되면 재무 및 공급망 관리 부서가 약속 이후의 업무를 인수합니다.

00:15:44.960 --> 00:15:48.200
주문 이행, 재고천구 및 재무 기록을 처리합니다.

00:15:48.440 --> 00:15:51.060
듀얼라이트는 이 두 부분을 계속 연결해줍니다.

00:15:51.320 --> 00:15:57.760
영업 담당자는 자신의 직무에 맞는 고객 앱에서 작업하고 재무 및 운영 부서는 해당 업무용으로 구축된 앱에서 거래를 관리합니다.

00:15:57.760 --> 00:16:02.180
고객 정보가 영업 부서의 이야기와 재무 부서의 이야기라는 두 개의 분리된 기록이 되지 않습니다.

00:16:02.320 --> 00:16:04.800
현장 서비스, 필드 서비스, 다 또 다른 좋은 예입니다.

00:16:04.980 --> 00:16:09.280
고객 현장에 기술자를 보내 장비를 설치, 수리 또는 유지 관리하는 회사를 상상해보십시오.

00:16:09.400 --> 00:16:15.460
현장 작업자는 고객 세부 정보, 작업 내용, 그리고 회사가 설치하거나 지원하는 항목에 고객 자산 정보가 필요합니다.

00:16:15.660 --> 00:16:20.740
보이지 않는 곳에서 회사는 부품, 비용, 구매 및 해당 작업과 관련된 자금을 추적해야 합니다.

00:16:20.960 --> 00:16:23.600
현장 서비스는 방문 계획 및 완료에 집중합니다.

00:16:23.880 --> 00:16:27.100
재무 및 운영은 그와 관련된 운영 및 재무 기록에 집중합니다.

00:16:27.100 --> 00:16:34.200
이 기록들이 제대로 연결되면 기술자의 작업이 사용된 부품, 작업 비용, 또는 연결된 고객 기록과 따로 놀지 않게 됩니다.

00:16:34.420 --> 00:16:39.320
프로젝트 운영, 프로젝트 오퍼레이션즈, 도 프로젝트 단위로 작업을 판매하는 기업의 경우 같은 패턴을 따릅니다.

00:16:39.540 --> 00:16:44.180
프로젝트 팀은 고객 작업, 인력 시간, 계획된 비용 및 프로젝트 마일스톤을 관리합니다.

00:16:44.400 --> 00:16:48.400
재무부서는 구매, 비용, 청구 및 보고의 재무적 측면을 확인해야 합니다.

00:16:48.640 --> 00:16:53.580
연결이 없으면 프로젝트 관리자는 업데이트를 받기 위해 재무부서를 쫓아다니느라 너무 많은 시간을 허비하고,

00:16:53.580 --> 00:16:56.780
재무부서는 작업 내용을 확인해줄 프로젝트 팀을 기다리게 됩니다.

00:16:56.980 --> 00:17:02.580
연결된 프로젝트 기록은 두 그룹 모두에게 고객과의 약속이 재무 활동으로 넘어가는 과정을 더 명확하게 보여줍니다.

00:17:02.760 --> 00:17:04.880
또한 여기에는 더 넓은 파워 플랫폼 혜택도 있는데,

00:17:05.340 --> 00:17:10.860
고객 앱 측에서 데이터버스를 사용하기 때문에 데이터버스 위 승인된 데이터는 파워 앱스 및 파워 오토메이트를 지원할 수 있습니다.

00:17:10.860 --> 00:17:16.820
기업은 내부팀을 위한 작은 앱을 구축하거나, 비즈니스 기록이 특정 지점에 도달할 때 반응하는 흐름을 만들 수 있습니다.

00:17:17.040 --> 00:17:21.080
그렇다고 해서 모든 재무 및 운영 기록이 갑자기 모든 파워 앱에 포함되어야 한다는 의미는 아닙니다.

00:17:21.240 --> 00:17:24.120
이는 기업이 목적을 신중히 선택하고 데이터를 적절히 보호하기만 한다면,

00:17:24.520 --> 00:17:27.620
연결된 내 코드가 더 광범위한 비즈니스 도구 세트의 일부가 될 수 있음을 의미합니다.

00:17:27.780 --> 00:17:29.740
한 가지 경계는 명확히 유지되어야 합니다.

00:17:29.920 --> 00:17:33.220
듀얼라이트는 다이나믹스 365 비즈니스 센트럴을 지원하지 않습니다.

00:17:33.220 --> 00:17:36.980
비즈니스 센트럴은 다른 방식으로 마이크로소프트 제품과 연결될 수 있지만,

00:17:37.500 --> 00:17:42.280
듀얼라이트는 다이나믹스 365의 재무 및 운영 부문과 데이터버스 기반 고객 앱을 위한 것입니다.

00:17:42.440 --> 00:17:45.200
또한 모든 테이블을 복사하기 위한 도구도 아닙니다.

00:17:45.420 --> 00:17:48.300
레코드는 단순히 데이터를 복사하는 것이 안전하다고 느껴서가 아니라,

00:17:48.780 --> 00:17:51.300
양쪽에서 동일한 운영 레코드가 필요할 때 이동되어야 합니다.

00:17:51.480 --> 00:17:55.500
또한 기업의 보고 피드, 타사 시스템과의 연결 또는 대규모 데이터 마이그레이션이 필요할 때,

00:17:55.600 --> 00:17:58.080
듀얼라이트가 더 광범위한 통합계획을 대체하지는 않습니다.

00:17:58.080 --> 00:18:02.240
모든 데이터 연결을 동일한 작업으로 취급하면 금방 문제가 발생합니다.

00:18:02.400 --> 00:18:05.480
제한사항, 준비사항 및 일반적인 실수들입니다.

00:18:05.700 --> 00:18:08.860
듀얼라이트를 두 시스템 간의 악수계약처럼 생각하십시오.

00:18:09.020 --> 00:18:11.420
그들은 특정 공유 레코드를 동기화 상태로 유지하기로 합의하지만,

00:18:11.820 --> 00:18:14.700
모든 테이블, 보고서 또는 외부 시스템을 위한 마법의 통로는 아닙니다.

00:18:14.840 --> 00:18:18.000
설정하기 전에 이미 존재하는 통합 항목이 무엇인지 확인하십시오.

00:18:18.140 --> 00:18:22.740
기존 연결과 듀얼라이트가 동일한 고객 레코드를 모두 업데이트하면 금방 충돌이 발생할 수 있습니다.

00:18:22.960 --> 00:18:24.360
이는 원치 않는 골칫거리입니다.

00:18:24.360 --> 00:18:26.400
그러니 먼저 기본적인 사항에 대해 합의하십시오.

00:18:26.520 --> 00:18:27.780
이름은 어떻게 입력할 것인가요?

00:18:27.940 --> 00:18:29.680
각 레코드는 어느 법적 회사가 소유하나요?

00:18:29.860 --> 00:18:30.940
누가 변경할 수 있나요?

00:18:31.080 --> 00:18:32.920
각 팀에는 어떤 보안 역할이 필요한가요?

00:18:33.140 --> 00:18:35.520
첫 동기화 전에 중복 및 불안전한 레코드를 정리하십시오.

00:18:35.680 --> 00:18:37.680
마이크로소프트 위 사전 구축된 맵으로 시작하십시오.

00:18:37.820 --> 00:18:39.280
공통 레코드는 이미 연결되어 있습니다.

00:18:39.560 --> 00:18:41.740
사용자 지정 테이블과 필드는 신중한 테스트가 필요합니다.

00:18:41.900 --> 00:18:44.000
또한 관련 테이블과 맵 종속성을 확인하십시오.

00:18:44.140 --> 00:18:47.480
한 레코드가 동기화되려면 다른 레코드가 먼저 존재해야 하는 경우가 있기 때문입니다.

00:18:47.480 --> 00:18:49.900
데이터 양을 기반으로 첫 동기화를 계획하십시오.

00:18:50.000 --> 00:18:52.400
점심시간에 켜는 조명 스위치처럼 취급하지 마십시오.

00:18:52.520 --> 00:18:53.800
그러면 문제가 발생합니다.

00:18:54.000 --> 00:18:56.440
일시 중지된 맵도 담당자와 재시작 계획이 필요합니다.

00:18:56.620 --> 00:18:59.360
대기 중인 변경 사항과 실패한 레코드는 영원히 유지되지 않습니다.

00:18:59.560 --> 00:19:02.460
활동 로그, 오류, 경고 및 인계 값을 주시하십시오.

00:19:02.600 --> 00:19:06.480
무언가 실패하면 누락된 필드, 잘못된 레코드 또는 그 이면에 깨진 규칙을 찾으십시오.

00:19:06.620 --> 00:19:09.020
반복적인 제시도로는 잘못된 데이터를 수정할 수 없습니다.

00:19:09.280 --> 00:19:12.760
듀얼라이트를 제어된 교량으로 인식하면 모든 것이 제자리를 찾게 됩니다.

00:19:12.760 --> 00:19:15.740
결론적으로 하나의 공유된 비즈니스 대화입니다.

00:19:15.940 --> 00:19:21.560
듀얼라이트는 지원되는 공유 레코드를 재무 및 운영과 데이터버스 기반 고객 앱 간에 계속 이동시킵니다.

00:19:21.760 --> 00:19:25.280
그렇게 하면 팀은 연결된 비즈니스 데이터를 기반으로 작업할 수 있습니다.

00:19:25.520 --> 00:19:31.960
M365.FM에서 저 미르코 피터스와 함께 더 많은 지식을 얻으려면 즐겨 찾는 팟캐스트 플랫폼에서 구독하시고

00:19:31.960 --> 00:19:37.860
여전히 스프레드 시트로 영업, 서비스, 재무를 연결하고 있는 사람에게 이 에피소드를 공유해주세요.