WEBVTT

00:00:00.000 --> 00:00:02.000
마이크로소프트 날리지 너겟지에 오신 것을 환영합니다.

00:00:02.140 --> 00:00:03.160
저는 모피터스입니다.

00:00:03.380 --> 00:00:05.760
오늘의 주제는 사람들이 자주 혼동하는 내용입니다.

00:00:06.000 --> 00:00:07.720
데이터버스란 정확히 무엇일까요?

00:00:07.980 --> 00:00:09.360
데이터베이스일까요? 앱일까요?

00:00:09.640 --> 00:00:13.020
아니면 IT 전문가만 이해해야 하는 숨겨진 다이나믹스 365 서비스일까요?

00:00:13.220 --> 00:00:14.800
가장 간단한 정의는 이렇습니다.

00:00:15.040 --> 00:00:19.020
데이터버스는 많은 다이나믹스 365 환경을 뒷받침하는 공유 데이터 기반입니다.

00:00:19.220 --> 00:00:22.040
다이나믹스 365를 사무용 건물이라고 생각해보세요.

00:00:22.300 --> 00:00:25.280
영업, 고객 서비스 및 기타 앱은 사람들이 일하는 방이며

00:00:25.280 --> 00:00:28.720
데이터버스는 그 벽 뒤에 있는 파일 시스템 이자 규칙입니다.

00:00:28.720 --> 00:00:31.740
이번 에피소드가 끝날 때 쯤이면 다이나믹스 데이터가 어디에 저장되는지

00:00:31.740 --> 00:00:35.960
그리고 하나의 고객 업데이트가 어떻게 영업 업무, 자동화, 보고서에 나타나는지 알게 될 것입니다.

00:00:36.100 --> 00:00:39.520
하지만 제품 이름을 살펴보기 전에 비즈니스의 혼란스러운 상황부터 시작해보겠습니다.

00:00:39.860 --> 00:00:42.440
이것은 반일 공유 공간이라는 해결책을 제시합니다.

00:00:42.660 --> 00:00:47.660
데이터를 따로 복사해두는 대신 영업팀, 지원팀, 재무팀이 있는 회사를 상상해보세요.

00:00:47.940 --> 00:00:50.320
영업팀은 고객 정보를 스프레드 시트에 보관합니다.

00:00:50.540 --> 00:00:52.660
지원팀은 별도의 사례관리 도구에서 작업합니다.

00:00:52.900 --> 00:00:55.160
재무팀은 자체 시스템에 고객 이름을 보관합니다.

00:00:55.160 --> 00:01:00.420
누군가는 이메일 스레드를 공유 사서함에 저장하고 다른 누군가는 아무도 찾을 수 없는 폴더에 메모를 보관합니다.

00:01:00.600 --> 00:01:02.920
이제 동일한 고객 정보가 5군데에 존재하게 됩니다.

00:01:03.160 --> 00:01:06.840
각 팀은 자신 앞에 놓인 업무만 보기 때문에 처음에는 이런 설정이 정상처럼 느껴집니다.

00:01:07.000 --> 00:01:08.420
하지만 문제는 여기서 시작됩니다.

00:01:08.620 --> 00:01:12.400
고객이 전화번호, 주소, 회사명 또는 주요 연락처를 변경하는 즉시 문제가 발생합니다.

00:01:12.560 --> 00:01:14.200
영업팀은 스프레드 시트를 업데이트합니다.

00:01:14.400 --> 00:01:15.680
지원팀은 이를 알지 못합니다.

00:01:15.920 --> 00:01:18.020
재무팀은 여전히 이전 주소로 문서를 보냅니다.

00:01:18.220 --> 00:01:21.300
그러고는 누군가 목록을 내보내고 수동으로 정리하여 이메일로 돌리면

00:01:21.300 --> 00:01:24.000
갑자기 세 사람이 각자 자기 복사본이 맞다고 믿게 됩니다.

00:01:24.160 --> 00:01:25.620
어떤 목록을 신뢰해야 할까요?

00:01:25.800 --> 00:01:28.080
그 질문은 생각보다 훨씬 더 많은 시간을 낭비하게 합니다.

00:01:28.260 --> 00:01:30.100
직원들은 기록을 대조하느라 업무를 멈춥니다.

00:01:30.300 --> 00:01:32.960
관리자는 왜 보고서가 영업 시스템과 일치하지 않는지 묻습니다.

00:01:33.180 --> 00:01:37.340
지원 담당자는 정보가 약간 다르지만 이미 다른 곳에 저장되어 있는 고객을 위해 새로운 사례를 생성합니다.

00:01:37.560 --> 00:01:39.160
아무도 혼란을 만들려고 하는 사람은 없습니다.

00:01:39.460 --> 00:01:41.140
혼란은 데이터 복사본 때문에 발생합니다.

00:01:41.340 --> 00:01:45.880
20년 전에는 시스템이 분리되어 있다는 것은 서버, 데이터베이스, 팀이 각자의 정보를 따로 관리한다는 것을 의미했습니다.

00:01:45.880 --> 00:01:49.700
이를 연결하려면 맞춤 작업, 예약된 가져오기, 그리고 많은 수동 확인 작업이 필요했습니다.

00:01:49.860 --> 00:01:54.240
한 곳에서의 변경사항이 다른 시스템에 반영되기까지는 내일이 될 수도, 다음 주가 될 수도, 혹은 아예 안 될 수도 있었습니다.

00:01:54.420 --> 00:01:57.640
데이터버스는 비즈니스 앱에 이러한 유형의 정보를 위한 공유 공간을 제공합니다.

00:01:57.820 --> 00:02:02.460
쉽게 말해 데이터버스는 비즈니스 정보를 위한 마이크로소프트 위 클라우드 데이터 플랫폼입니다.

00:02:02.460 --> 00:02:10.380
이 플랫폼은 정보를 구조화된 테이블의 저장함으로 데이터는 무작위 메모, 나 흩어진 파일, 연결되지 않은 스프레드 시트 탭으로 존재하지 않고 명확한 형태를 갖추게 됩니다.

00:02:10.600 --> 00:02:15.260
이것을 회사의 서류 보관함이라고 생각할 수 있지만, 여러 승인된 도구가 동시에 사용할 수 있는 보관함입니다.

00:02:15.460 --> 00:02:17.500
고객은 데이터버스에 한 번만 나타납니다.

00:02:17.720 --> 00:02:22.020
영업 담당자가 거래를 진행할 때 다이나믹스 365 세일즈에서 해당 고객이 나타날 수 있습니다.

00:02:22.260 --> 00:02:27.780
상담원이 지원 요청을 처리할 때 다이나믹스 365 커스터머 서비스에서도 동일한 고객 정보가 나타날 수 있습니다.

00:02:27.780 --> 00:02:34.040
파워 앱은 데이터를 새 앱에 먼저 복사할 필요 없이 현장 작업자나 계정 관리자를 위해 동일한 고객 정보를 사용할 수 있습니다.

00:02:34.260 --> 00:02:36.580
하나의 고객 행, 하나의 공유 참조 지점입니다.

00:02:36.820 --> 00:02:39.380
이것이 모든 팀이 갑자기 모든 것을 볼 수 있다는 의미는 아닙니다.

00:02:39.560 --> 00:02:42.400
액세스에는 여전히 규칙이 필요하며 곧 이에 대해 다룰 것입니다.

00:02:42.580 --> 00:02:47.560
이는 승인된 앱들이 자체적인 경쟁 버전을 구축하는 대신 동일한 비즈니스 정보를 기반으로 작업할 수 있다는 의미입니다.

00:02:47.740 --> 00:02:51.340
이것이 다이나믹스 365와 데이터버스가 매우 자연스럽게 어우러지는 이유입니다.

00:02:51.340 --> 00:02:56.320
세일즈 나 커스터머 서비스와 같은 다이나믹스 365 앱은 데이터버스를 사용하여 작업하는 데이터를 저장하고 보호합니다.

00:02:56.460 --> 00:02:57.720
하지만 중요한 점이 있습니다.

00:02:57.980 --> 00:03:04.100
누군가 다이나믹스 365와 데이터버스를 통합하는 것에 대해 이야기할 때 종종 그들은 두 제품 사이에 연결기가 필요한 별개의 제품으로 상상하곤 합니다.

00:03:04.260 --> 00:03:07.260
많은 다이나믹스 365 앱의 경우 실제 상황은 그렇지 않습니다.

00:03:07.460 --> 00:03:09.400
데이터는 이미 데이터버스에 존재합니다.

00:03:09.620 --> 00:03:15.780
다이나믹스 365에서 고객 목록을 추출하여 다른 데이터베이스에 복사하고 양쪽이 최신 상태로 유지되기를 바랄 필요가 없습니다.

00:03:15.780 --> 00:03:21.160
다이나믹스 365가 이미 사용하는 동일한 비즈니스 정보를 사용하여 동일한 기반 위에서 구축할 수 있습니다.

00:03:21.360 --> 00:03:22.980
그것이 대화의 내용을 바꿉니다.

00:03:23.160 --> 00:03:31.300
이 두 고객 목록을 어떻게 동기화할까요? 라고 묻는 대신 어떤 사람과 앱이 고객 레코드로 작업해야 하며 각자 무엇을 할 수 있도록 허용해야 하는지를 물을 수 있습니다.

00:03:31.520 --> 00:03:34.900
이제 데이터버스가 회사가 소유한 모든 시스템을 대체하는 것은 아닙니다.

00:03:35.100 --> 00:03:41.880
기업은 여전히 재무 소프트웨어, 산업 도구, 창고 시스템, 웹사이트 또는 자체 데이터를 보관하는 이전 애플리케이션을 사용할 수 있습니다.

00:03:41.880 --> 00:03:46.040
데이터버스는 하룻밤 사이에 모든 외부 시스템을 없애는 마법의 접착제가 아닙니다.

00:03:46.200 --> 00:03:50.680
이것이 제공하는 것은 연결된 앱들이 공유해야 할 비즈니스 데이터를 위한 공통된 장소입니다.

00:03:50.880 --> 00:03:54.980
고객 세부 정보, 영업 작업, 지원 업무, 작업 및 후속 조치 등이 해당됩니다.

00:03:55.180 --> 00:03:58.860
이러한 레코드는 승인된 도구가 읽고 업데이트할 수 있는 하나의 소스와 함께 공존할 수 있습니다.

00:03:59.060 --> 00:04:01.440
그러니 저와 함께 그 서류 보관함을 열어보시죠.

00:04:01.600 --> 00:04:08.240
데이터버스가 정보를 어떻게 정리하는지 일단 확인하면 전체 다이나믹스 365 연결을 이해하기가 훨씬 쉬워집니다.

00:04:08.240 --> 00:04:11.800
서류 보관함의 테이블, 행, 열, 관계까지 말이죠.

00:04:11.960 --> 00:04:13.540
이제 서류 보관함을 열어봅시다.

00:04:13.740 --> 00:04:15.900
데이터버스 내부의 정보는 테이블에 저장됩니다.

00:04:16.100 --> 00:04:18.540
분리된 서랍이 있는 실제 캐비닛과 같다고 생각하세요.

00:04:18.780 --> 00:04:22.560
한 서랍은 회사를, 다른 서랍은 사람을, 세 번째 서랍은 지원 요청을 보관합니다.

00:04:22.780 --> 00:04:26.520
모든 종이를 하나의 거대한 서랍에 던져넣고 나중에 누군가 분류하기를 바라는 방식이 아닙니다.

00:04:26.700 --> 00:04:28.120
각 서랍에는 맡은 역할이 있습니다.

00:04:28.400 --> 00:04:30.960
데이터버스에서 테이블은 한 가지 유형의 비즈니스 정보를 담습니다.

00:04:31.140 --> 00:04:33.400
계정 테이블은 보통 협력하는 기업 정보를 담습니다.

00:04:33.400 --> 00:04:35.520
연락처 테이블은 개인 정보를 담습니다.

00:04:35.720 --> 00:04:39.140
잠재 고객 테이블은 실제 고객이 되기 전이 잠재적 고객을 담습니다.

00:04:39.340 --> 00:04:45.260
사례 테이블은 지원 요청을, 활동 테이블은 통화, 이메일, 약속, 작업 등의 업무를 추적합니다.

00:04:45.520 --> 00:04:46.860
이것들이 표준 테이블입니다.

00:04:47.080 --> 00:04:51.780
대부분의 기업은 고객, 사람, 업무, 대화 내용을 관리해야 함으로 마이크로소프트는 이를 기본 제공합니다.

00:04:51.920 --> 00:04:55.860
표준 테이블이 이미 그 역할을 한다면 흔한 업무를 위해 굳이 새로운 테이블을 만들 필요는 없습니다.

00:04:55.860 --> 00:04:58.400
하지만 모든 회사에는 저마다의 고유한 업무도 있습니다.

00:04:58.600 --> 00:05:01.160
교육업체 라면 과정과 자격증을 관리해야 할 것입니다.

00:05:01.380 --> 00:05:04.680
부동산 업체는 건물, 유닛, 점검 정보를 관리해야 할 수 있습니다.

00:05:04.920 --> 00:05:07.880
제조업체는 장비 점검이나 서비스 방문을 추적할 수 있습니다.

00:05:08.140 --> 00:05:11.840
이런 경우 N은 회사 업무에 딱 맞는 사용자 지정 테이블을 만들 수 있습니다.

00:05:12.120 --> 00:05:16.260
사용자 지정 테이블은 캐비닛에 새 서랍을 추가하고 명확한 라벨을 붙이는 것이라 생각하세요.

00:05:16.480 --> 00:05:18.100
이제 각 테이블은 행을 포함합니다.

00:05:18.320 --> 00:05:20.320
행은 해당 서랍 안에 있는 하나의 항목입니다.

00:05:20.320 --> 00:05:25.340
예를 들어 연락처 테이블의 한 행은 고객사의 담당자인 마리아 고메즈를 나타낼 수 있습니다.

00:05:25.580 --> 00:05:29.500
그녀의 행에는 시스템의 다른 모든 연락처와 구분되는 그녀만의 세부 정보가 담깁니다.

00:05:29.500 --> 00:05:32.280
열은 각 행에 대해 유지하려는 세부 정보를 설명합니다.

00:05:32.460 --> 00:05:39.480
마리아 위 연락처 행에는 이름, 성, 이메일 주소, 전화번호, 직함, 회사, 레코드 소유자, 상태를 위한 열이 있을 수 있습니다.

00:05:39.700 --> 00:05:42.140
열은 해당 위치에 들어갈 정보의 유형을 결정합니다.

00:05:42.380 --> 00:05:46.700
따라서 이메일 열에는 이메일 주소가, 상태 열에는 승인된 상태의 선택 항목이 들어갑니다.

00:05:46.700 --> 00:05:49.920
이것이 비즈니스 정보가 신뢰할 수 있는 형태를 갖추는 방식입니다.

00:05:50.080 --> 00:05:56.920
열이 없다면 누군가는 메모란에 전화번호를 입력하고, 누군가는 이름 필드에 넣거나 아예 입력하지 않을 수도 있습니다.

00:05:56.920 --> 00:06:01.340
체계적인 연락처 테이블이 있으면 모두가 같은 위치에서 동일한 세부 정보를 다루게 됩니다.

00:06:01.580 --> 00:06:04.140
이러한 구조는 앱이 데이터를 이해하는 데도 도움을 줍니다.

00:06:04.360 --> 00:06:09.900
양식은 올바른 상자를 표시하고, 보고서는 상태별로 연락처를 그룹화하며, 자동화는 소유자가 변경될 때 반응할 수 있습니다.

00:06:10.140 --> 00:06:12.220
정보는 단순히 저장되기만 하는 것이 아닙니다.

00:06:12.400 --> 00:06:15.540
연결된 도구들의 각 부분이 무엇을 의미하는지 알려주는 나벨이 붙어 있습니다.

00:06:15.800 --> 00:06:18.720
비즈니스 요구사항에 부합한다면 표준 테이블부터 시작하세요.

00:06:18.960 --> 00:06:23.420
기업을 대상으로 판매한다면 계정과 연락처는 이미 대부분이 이해하는 패턴을 제공합니다.

00:06:23.420 --> 00:06:26.880
고객 지원 업무를 처리한다면 사례가 좋은 시작점이 됩니다.

00:06:27.100 --> 00:06:31.480
기본 패턴에 맞지 않는 정보가 있는 경우 M1 사용자 지정 테이블을 추가하세요.

00:06:31.740 --> 00:06:36.220
이는 모두 고객을 의미하는 5개의 서로 다른 테이블을 만드는 흔한 문제를 방지합니다.

00:06:36.420 --> 00:06:41.420
한 팀은 클라이언트라고 부르고, 다른 팀은 고객 마스터, 세 번째 팀은 파트너 연락처라고 부릅니다.

00:06:41.620 --> 00:06:44.300
곧 사람들은 어떤 테이블을 사용해야 할지 알 수 없게 됩니다.

00:06:44.540 --> 00:06:49.680
명확한 표준 테이블과 신중하게 명명된 사용자 지정 테이블은 더 많은 사람이 이를 기반으로 작업할 때 캐비닛을 이해하기 쉽게 유지합니다.

00:06:49.860 --> 00:06:52.640
다음 부분은 이러한 서랍들이 함께 작동하기 시작하는 곳입니다.

00:06:52.640 --> 00:06:54.260
연락처는 계정에 속합니다.

00:06:54.500 --> 00:06:56.080
마리아는 콘토소에서 일합니다.

00:06:56.300 --> 00:07:03.880
마리아의 행에 콘토소의 주소, 주요 전화번호, 회사 세부 정보를 다시 입력하는 대신, 데이터버스는 연락처 테이블과 계정 테이블 간의 관계를 만들 수 있습니다.

00:07:04.100 --> 00:07:08.040
마리아는 콘토소에 연결되며, 회사 정보는 회사에 머물러야 함으로 이 연결은 중요합니다.

00:07:08.220 --> 00:07:11.520
콘토소가 사무실 주소를 변경하면 누군가 계정 행을 한 번만 업데이트하면 됩니다.

00:07:11.780 --> 00:07:15.880
관련된 모든 연락처는 자체적인 구식 사본을 유지하지 않고도 동일한 회사를 계속 가리킬 수 있습니다.

00:07:16.120 --> 00:07:19.260
관계는 또한 지원 케이스를 그것을 제기한 고객과 연결합니다.

00:07:19.260 --> 00:07:24.500
관계는 영업기회를 해당 거래와 관련된 통화, 이메일, 회의 및 작업과 연결할 수 있습니다.

00:07:24.700 --> 00:07:30.440
영업사원이 기회를 열면 관련 없는 메모와 캘린더를 검색하는 대신 연결된 활동을 볼 수 있습니다.

00:07:30.720 --> 00:07:32.120
정보에 맥락이 생깁니다.

00:07:32.320 --> 00:07:34.220
단순히 케이스 번호만 보는 것이 아닙니다.

00:07:34.440 --> 00:07:36.460
어떤 고객에게 속한 것인지 확인할 수 있습니다.

00:07:36.740 --> 00:07:38.740
단순히 연락처 정보만 보는 것이 아닙니다.

00:07:38.940 --> 00:07:40.840
그 사람과 연결된 회사를 볼 수 있습니다.

00:07:41.120 --> 00:07:45.420
이러한 링크는 여러 곳에 동일한 사실을 반복적으로 입력하지 않고도 데이터를 유용하게 유지합니다.

00:07:45.420 --> 00:07:49.280
오래된 가이드를 읽거나 이전 동영상을 보기 전에 명칭에 관한 작은 참고사항이 있습니다.

00:07:49.500 --> 00:07:51.980
엔티티, 필드, 레코드라는 단어를 들을 수 있습니다.

00:07:52.220 --> 00:07:54.040
그것들은 이전의 데이터버스 용어입니다.

00:07:54.380 --> 00:07:58.980
마이크로소프트는 이제 엔티티 대신 테이블, 필드 대신 열, 레코드 대신 행이라는 용어를 사용합니다.

00:07:59.180 --> 00:08:00.540
의미는 변하지 않았습니다.

00:08:00.780 --> 00:08:05.440
엔티티를 만들라고 하는 오래된 가이드는 테이블을 만드는 것에 대해 이야기하는 것입니다.

00:08:05.680 --> 00:08:07.960
필드는 열이고 레코드는 행입니다.

00:08:08.200 --> 00:08:12.120
두 용어를 모두 알면 다른 제품을 찾았다고 생각하는 실수를 방지할 수 있습니다.

00:08:12.120 --> 00:08:15.260
따라서 테이블은 정보와 관계를 연결하여 체계화합니다.

00:08:15.420 --> 00:08:17.860
하지만 잘 정리된 캐비닛도 통제가 필요합니다.

00:08:18.040 --> 00:08:22.020
누군가는 사람들이 무엇을 입력하고, 변경하고, 안전하게 액세스할 수 있는지 결정해야 합니다.

00:08:22.180 --> 00:08:24.260
데이터 뒤에는 규칙과 접수 데스크가 있습니다.

00:08:24.540 --> 00:08:27.340
공유 데이터는 적절한 사람들이 안전하게 작업할 수 있을 때만 효과적입니다.

00:08:27.540 --> 00:08:29.320
영업 담당자는 고객 세부 정보가 필요합니다.

00:08:29.520 --> 00:08:31.180
지원 담당자는 케이스 기록이 필요합니다.

00:08:31.380 --> 00:08:33.000
관리자는 더 넓은 시야가 필요합니다.

00:08:33.200 --> 00:08:36.280
그리고 외부 파트너는 프로세스의 작은 부분에만 액세스 권한이 필요할 수 있습니다.

00:08:36.540 --> 00:08:38.260
모두가 동일한 정보를 볼 필요는 없습니다.

00:08:38.260 --> 00:08:43.400
비공개 연락처 메모, 협상된 가격, 진행 중인 지원 케이스가 있는 고객 레코드를 생각해보십시오.

00:08:43.520 --> 00:08:46.540
모든 사용자에게 전체 액세스 권한을 부여하면 빠르게 위험이 초래될 수 있습니다.

00:08:46.760 --> 00:08:50.100
모든 사람을 너무 엄격하게 제한하여 업무를 수행할 수 없게 만드는 것은 또 다른 문제를 야기합니다.

00:08:50.280 --> 00:08:52.200
데이터버스는 이를 위한 제어 기능을 제공합니다.

00:08:52.380 --> 00:08:54.200
첫 번째 제어는 아이디에서 시작됩니다.

00:08:54.380 --> 00:08:58.080
회사 계정으로 로그인하면 마이크로소프트 엔트라 아이디가 사용자를 식별합니다.

00:08:58.320 --> 00:09:01.140
엔트라 아이디를 사무실 입구의 안내데스크라고 생각하세요.

00:09:01.140 --> 00:09:05.020
도착해서 배지를 보여주면 안내원이 누구인지 확인한 후에야 입장할 수 있습니다.

00:09:05.260 --> 00:09:08.740
데이터버스는 이 아이디를 사용하여 어떤 사용자가 데이터를 작업 중인지 파악합니다.

00:09:08.940 --> 00:09:11.740
단지 사람이 입장할 수 있는지 묻는 것에서 그치지 않습니다.

00:09:11.960 --> 00:09:14.620
입장 후에 사람이 무엇을 할 수 있는지도 확인합니다.

00:09:14.840 --> 00:09:16.800
바로 여기서 보안 역할이 필요합니다.

00:09:17.020 --> 00:09:20.280
보안 역할은 직무나 책임과 연결된 권한 집합입니다.

00:09:20.560 --> 00:09:25.240
영업 직원을 위한 역할, 고객 서비스 상담원을 위한 역할, 관리자를 위한 역할을 각각 생성할 수 있습니다.

00:09:25.480 --> 00:09:27.660
각 역할은 테이블에 대한 액세스를 제어할 수 있습니다.

00:09:27.660 --> 00:09:32.680
예를 들어, 영업 담당자는 계정, 연락처, 잠재고객 및 영업기회를 읽고 생성하고 업데이트할 수 있습니다.

00:09:32.860 --> 00:09:35.460
중요한 고객 정보를 삭제하는 권한은 없을 수 있습니다.

00:09:35.720 --> 00:09:39.640
지원 상담원은 사례를 생성 및 업데이트할 수는 있지만, 영업기회를 변경할 수는 없습니다.

00:09:39.920 --> 00:09:43.380
권한은 행을 읽기, 생성, 변경 및 삭제하는 작업을 포괄할 수 있습니다.

00:09:43.600 --> 00:09:47.120
즉, 액세스 권한은 앱마다 어떤 버튼을 숨겨야 하는지 일일이 기억할 필요가 없습니다.

00:09:47.420 --> 00:09:49.440
권한이 데이터 자체에 포함되어 있기 때문입니다.

00:09:49.620 --> 00:09:52.660
따라서 데이터버스 데이터가 나타나는 모든 곳에 동일한 안전장치가 적용됩니다.

00:09:52.660 --> 00:09:54.940
그런 다음 액세스 권한을 훨씬 더 좁힐 수 있습니다.

00:09:55.120 --> 00:09:58.320
행수준 보안은 개인이 어떤 개별 행으로 작업할 수 있는지 결정합니다.

00:09:58.540 --> 00:10:03.940
영업 담당자는 자신이 담당하는 고객만 볼 수 있는 반면, 영업관리자는 팀원 모두가 소유한 고객행을 볼 수 있습니다.

00:10:04.140 --> 00:10:06.200
두 사람 모두 동일한 계정 테이블을 사용합니다.

00:10:06.420 --> 00:10:08.400
단지 동일한 부분의 데이터를 보지 않을 뿐입니다.

00:10:08.600 --> 00:10:12.400
이러한 설정은 사람들이 자신의 업무에 집중하도록 돕는 동시에 관리자에게 필요한 뷰를 제공합니다.

00:10:12.580 --> 00:10:16.520
또한 액세스할 이유가 없는 고객 정보를 누군가가 열어볼 가능성도 줄여줍니다.

00:10:16.760 --> 00:10:19.140
일부 정보는 더욱 엄격한 보호가 필요합니다.

00:10:19.140 --> 00:10:22.320
열 수준 보안은 테이블 내의 개별 열을 보호할 수 있습니다.

00:10:22.540 --> 00:10:28.580
사용자가 고객행을 열 수는 있지만 개인식별자, 급여수치, 은행정보 또는 개인재무 메모는 보지 못하게 할 수 있습니다.

00:10:28.800 --> 00:10:31.640
고객행은 여전히 필요한 작업을 수행할 수 있도록 유지됩니다.

00:10:31.860 --> 00:10:33.960
보호된 열은 제한된 상태로 유지됩니다.

00:10:34.180 --> 00:10:38.060
대기업의 경우 비즈니스 단위를 통해 조직 부서 간의 경계를 만들 수 있습니다.

00:10:38.320 --> 00:10:42.560
회사는 서로 다른 고객 그룹과 작업하는 지역, 부서 또는 자회사를 분리할 수 있습니다.

00:10:42.820 --> 00:10:46.260
비즈니스 단위는 이러한 경계 전반에서 액세스가 작동하는 방식을 구성하는 데 도움을 줍니다.

00:10:46.260 --> 00:10:49.120
이것이 모든 기업의 복잡한 보안 맵이 필요하다는 의미는 아닙니다.

00:10:49.260 --> 00:10:51.760
소규모 팀은 명확한 몇 가지 역할만 있으면 충분할 수 있습니다.

00:10:51.960 --> 00:10:55.700
규모가 큰 기업은 팀, 지역, 업무 분장에 따라 더 많은 계층이 필요할 수 있습니다.

00:10:55.900 --> 00:10:59.440
핵심은 데이터버스가 실제 비즈니스 운영 방식에 맞춰 액세스 권한을 설정할 수 있다는 점입니다.

00:10:59.640 --> 00:11:04.020
액세스 제어는 데이터에 접근할 수 있는 사람을 보호하지만, 규칙은 데이터 자체의 품질을 보호합니다.

00:11:04.200 --> 00:11:08.220
비즈니스 규칙을 설정하면 새 연락처를 저장하기 전에 전화번호를 반드시 입력하도록 할 수 있습니다.

00:11:08.220 --> 00:11:11.740
사례가 종료될 때 사유를 입력해야 하는 것과 같은 조건을 확인할 수도 있습니다.

00:11:11.940 --> 00:11:15.100
사용자가 입력한 정보에 따라 사용자가 보는 화면을 변경할 수도 있습니다.

00:11:15.300 --> 00:11:18.140
동일한 규칙이 해당 테이블을 사용하는 모든 앱에 적용됩니다.

00:11:18.360 --> 00:11:22.660
어떤 앱은 불안전한 데이터를 허용하고, 다른 앱은 거부하는 상황을 방지해야 함으로 이는 중요합니다.

00:11:22.840 --> 00:11:26.180
규칙은 특정 화면이 아니라 비즈니스 정보 자체에 포함되어야 합니다.

00:11:26.380 --> 00:11:30.780
데이터버스는 비즈니스 프로세스를 일관되게 유지하기 위해 백그라운드에서 로직을 실행할 수도 있습니다.

00:11:31.040 --> 00:11:32.860
기억해야 할 세부사항은 간단합니다.

00:11:32.860 --> 00:11:36.020
데이터에는 저장소뿐만 아니라 규칙도 함께 제공됩니다.

00:11:36.220 --> 00:11:41.380
즉, 기반에는 정보, 작업을 허용받은 사람, 그리고 데이터를 유용하게 유지하는 규칙이 포함됩니다.

00:11:41.580 --> 00:11:43.940
다이나믹스 365가 동일한 기반 위에서 작동하면,

00:11:44.360 --> 00:11:47.680
자체 비즈니스 데이터에 액세스하기 위해 별도의 연결 통로가 필요하지 않습니다.

00:11:47.840 --> 00:11:51.000
다이나믹스 365 통합이 실제로 의미하는 바는 무엇일까요?

00:11:51.160 --> 00:11:54.720
대부분은 다이나믹스 365와 데이터버스 위 통합이라는 말을 들으면,

00:11:54.900 --> 00:11:57.380
두 개의 개별 시스템이 커넥터로 연결된 모습을 떠올립니다.

00:11:57.380 --> 00:12:00.840
한 시스템에 고객 데이터가 있고, 다른 시스템에 사본이 필요하면,

00:12:01.320 --> 00:12:05.300
누군가 동기화를 설정하고 실행될 때까지 기다리며 오류가 없기를 바랍니다.

00:12:05.540 --> 00:12:08.200
그런 방식은 많은 비즈니스 도구에서 타당합니다.

00:12:08.420 --> 00:12:15.420
하지만 다이나믹스 365 세일즈와 다이나믹스 365 커스터머 서비스 위 연결은 그보다 훨씬 더 긴밀합니다.

00:12:15.680 --> 00:12:18.820
이 앱들은 데이터버스를 공통 데이터 기반으로 사용합니다.

00:12:19.080 --> 00:12:23.400
서로를 이해하기 위해 고객행 데이터를 주고받는 별도의 데이터베이스가 아닙니다.

00:12:23.620 --> 00:12:26.360
처음부터 동일한 비즈니스 정보를 바탕으로 작업합니다.

00:12:26.360 --> 00:12:27.640
그 점이 핵심입니다.

00:12:29.340 --> 00:12:34.000
영업 담당자로서 다이나믹스 365 세일즈에서 새로운 기업 정보를 생성한다고 가정해보겠습니다.

00:12:34.360 --> 00:12:37.300
주요 연락처를 추가하고 잠재적인 거래를 진행하기 시작합니다.

00:12:37.500 --> 00:12:40.540
해당 세부 정보는 즉시 앱이 사용하는 공유 데이터의 일부가 됩니다.

00:12:40.860 --> 00:12:43.160
나중에 해당 고객이 고객 지원팀에 연락합니다.

00:12:43.440 --> 00:12:46.680
지원 상담원은 동일한 기업 및 연락처 정보로 바로 작업할 수 있습니다.

00:12:46.980 --> 00:12:51.320
누구도 영업팀에서 목록을 내보내거나 별도의 지원 도구에 고객을 다시 등록할 필요가 없습니다.

00:12:51.320 --> 00:12:56.800
상담원은 단순히 지원 사례를 해당 고객에게 연결하고 상황을 이해하는 데 도움이 되는 기록을 확인합니다.

00:12:56.960 --> 00:12:58.300
영업팀은 거래를 확인합니다.

00:12:58.500 --> 00:13:01.800
지원팀은 사례를 확인하며 두 팀 모두 동일한 고객을 중심으로 업무를 처리합니다.

00:13:01.980 --> 00:13:06.280
그렇다고 해서 모든 화면이 동일하거나 모든 팀이 똑같은 프로세스를 따라야 한다는 의미는 아닙니다.

00:13:06.480 --> 00:13:09.760
영업팀에는 잠재 고객, 영업 기회, 통화, 미팅 정보가 필요합니다.

00:13:09.940 --> 00:13:12.920
고객 서비스에는 사례, 대기열, 서비스 이력이 필요합니다.

00:13:13.100 --> 00:13:16.540
각 다이나믹스 365 앱은 사용자 업무에 맞게 구축된 도구를 제공합니다.

00:13:16.540 --> 00:13:19.940
그 기반이 되는 비즈니스 정보는 필요한 곳 어디든 연결될 수 있습니다.

00:13:20.140 --> 00:13:25.520
이 공유 기반이 바로 사람들이 다이나믹스 365와 데이터버스 통합에 대해 이야기할 때 흔히 의미하는 바입니다.

00:13:25.740 --> 00:13:29.240
데이터를 A 지점에서 B 지점으로 옮기는 것만이 전부가 아닙니다.

00:13:29.440 --> 00:13:33.780
앱들이 동일한 행, 관계, 규칙, 액세스 제어를 활용하는 것이 핵심입니다.

00:13:33.980 --> 00:13:36.800
처음부터 사무실에서 간단한 영업 여정을 진행해보겠습니다.

00:13:37.220 --> 00:13:39.840
웹사이트나 행사로부터 잠재 고객이 유입됩니다.

00:13:40.060 --> 00:13:43.380
영업사원은 해당 잠재 고객과 소통하며 그 사람에 대해 더 알아보고,

00:13:43.800 --> 00:13:45.980
잠재 고객을 고객관계이자 기회로 전환합니다.

00:13:45.980 --> 00:13:49.780
통화, 이메일, 약속, 작업 등을 모두 해당 업무와 연결할 수 있습니다.

00:13:49.960 --> 00:13:53.640
따라서 팀은 파편화된 도구들을 일일이 뒤져서 전체 상황을 파악할 필요가 없습니다.

00:13:53.940 --> 00:13:58.020
나중에 고객이 도움이 필요하면 지원 사례를 바로 그 고객에게 다시 연결할 수 있습니다.

00:13:58.280 --> 00:14:01.640
지원 상담원은 단지 이름과 이메일 주소만 확인하는 것이 아닙니다.

00:14:01.820 --> 00:14:05.260
이미 확인된 고객관계라는 맥락 안에서 업무를 처리할 수 있습니다.

00:14:05.520 --> 00:14:08.980
한편 영업팀은 해당 고객에게 미해결된 서비스 문제가 있음을 확인하여

00:14:08.980 --> 00:14:12.020
이전 문제 상황을 모른 채 갱신 상담을 진행하는 실수를 피할 수 있습니다.

00:14:12.260 --> 00:14:14.980
하나의 고객관계가 다양한 유형의 업무를 지원할 수 있습니다.

00:14:14.980 --> 00:14:18.860
이는 단순히 두 시스템에 일치하는 고객 이름을 유지하는 것보다 훨씬 유용합니다.

00:14:19.020 --> 00:14:23.160
공통 데이터 모델, 커먼 데이터 모델, 줄여서 CDM이라는 용어도 들어보셨을 것입니다.

00:14:23.360 --> 00:14:25.840
이름 때문에 너무 어렵게 생각하실 필요는 없습니다.

00:14:26.200 --> 00:14:31.360
단순히 마이크로소프트 가계점, 연락처, 활동, 사례와 같이 많은 기업이 추적하는 항목에 대해

00:14:31.360 --> 00:14:33.580
공통 비즈니스 테이블 패턴을 제공한다는 뜻입니다.

00:14:33.780 --> 00:14:38.060
이러한 패턴은 다이나믹스 365 및 데이터버스 기반 앱에 공통된 시작 언어를 제공합니다.

00:14:38.260 --> 00:14:39.600
계정은 회사를 의미합니다.

00:14:39.820 --> 00:14:41.280
연락처는 사람을 의미합니다.

00:14:41.280 --> 00:14:44.000
활동은 비즈니스 관계와 관련된 업무를 추적합니다.

00:14:44.200 --> 00:14:47.560
기업 상황에 맞게 설정을 조정하고 필요한 테이블을 추가할 수 있지만

00:14:47.560 --> 00:14:50.040
매번 처음부터 다시 시작할 필요는 없습니다.

00:14:50.320 --> 00:14:53.560
한 앱이 계정 테이블을 이해하고 다른 앱이 동일한 테이블을 사용하면

00:14:53.560 --> 00:14:56.400
두 앱 모두 동일한 비즈니스 정보를 참조하게 됩니다.

00:14:56.620 --> 00:14:59.060
이는 여러분이 구축할 수 있는 결과물도 변화시킵니다.

00:14:59.220 --> 00:15:01.400
현장팀이 고객을 조회하고 방문을 확인하며

00:15:01.400 --> 00:15:04.220
약속 후 메모를 추가할 간단한 앱이 필요하다고 가정해봅시다.

00:15:04.400 --> 00:15:06.220
다이나믹스 365가 이미 사용 중인

00:15:06.220 --> 00:15:08.940
동일한 데이터버스 테이블과 연동되는 파워앱을 만들 수 있습니다.

00:15:08.940 --> 00:15:12.560
해당 앱만을 위해 고객 데이터를 새로운 목록으로 내보낼 필요가 없습니다.

00:15:12.840 --> 00:15:16.860
현장 직원은 앱을 열고 고객을 찾아 방문 정보를 업데이트하기만 하면 됩니다.

00:15:17.180 --> 00:15:19.000
데이터는 앞서 다룬 보안 규칙에 따라

00:15:19.000 --> 00:15:22.200
영업이나 고객 서비스 팀이 이미 사용 중인 고객 관계와

00:15:22.200 --> 00:15:23.880
계속 연결된 상태를 유지합니다.

00:15:24.100 --> 00:15:27.140
더 구조화된 업무를 위해서는 모델 기반 앱을 구축할 수 있습니다.

00:15:27.440 --> 00:15:29.500
모델 기반 앱은 데이터 모델에서 시작합니다.

00:15:29.760 --> 00:15:32.200
데이터버스 테이블을 선택하고 관계를 정의하며

00:15:32.200 --> 00:15:34.780
양식과 보기를 설정하고 보안 역할을 적용합니다.

00:15:34.780 --> 00:15:38.600
그러면 파워앱스가 그 구조를 사용하여 작동하는 비즈니스 앱 환경을 만듭니다.

00:15:38.740 --> 00:15:42.380
팀이 실제로 사용하는 도구와 재료에 맞춰 작업대를 정리하는 것과 같다고 생각하면 됩니다.

00:15:42.580 --> 00:15:43.980
테이블은 업무를 설명합니다.

00:15:44.200 --> 00:15:45.660
관계는 조각들을 연결합니다.

00:15:45.900 --> 00:15:48.780
양식은 사람들이 세부 정보를 입력하고 검토할 공간을 제공합니다.

00:15:48.980 --> 00:15:51.100
보기는 주의가 필요한 행을 찾도록 도와줍니다.

00:15:51.320 --> 00:15:54.120
보안은 각 사람이 무엇을 열거나 변경할 수 있는지 결정합니다.

00:15:54.340 --> 00:15:56.160
모델 기반 앱과 다이나믹스 365는

00:15:56.160 --> 00:15:58.540
모두 데이터버스를 기반으로 함으로 함께 사용할 수 있습니다.

00:15:58.540 --> 00:16:02.260
예를 들어 다이나믹스 365세일즈가 전체 영업 프로세스를 처리하는 동안

00:16:02.260 --> 00:16:06.520
더 작은 모델 기반 앱은 계약 관리자가 고객 계약을 추적할 수 있는 집중된 공간을 제공할 수 있습니다.

00:16:06.680 --> 00:16:10.760
두 가지 모두 두 번째 고객 데이터베이스를 만들지 않고도 관련 고객 데이터를 처리할 수 있습니다.

00:16:11.000 --> 00:16:13.260
물론 이러한 액세스 권한 관리는 신중해야 합니다.

00:16:13.480 --> 00:16:15.760
앱이 데이터버스 테이블과 연동된다고 해서

00:16:15.760 --> 00:16:19.800
모든 사용자가 모든 행을 수정하거나 모든 열을 볼 수 있어야 하는 것은 아닙니다.

00:16:19.980 --> 00:16:23.500
역할 기반 행 액세스와 비즈니스 규칙이 여전히 무엇이 가능한지 제어합니다.

00:16:23.500 --> 00:16:29.940
현장 앱은 회사에 나머지 데이터를 노출하지 않고도 사용자에게 필요한 정확한 고객 세부 정보와 작업만 제공할 수 있습니다.

00:16:30.160 --> 00:16:35.620
따라서 데이터버스와 다이나믹스 365의 통합은 이제 두 개의 떨어진 방을 연결하는 케이블과 같습니다.

00:16:35.940 --> 00:16:41.260
다이나믹스 365 앱, 사용자 지정 앱 및 비즈니스 프로세스 모두 동일한 공유 기반 위에서 작동할 수 있습니다.

00:16:41.460 --> 00:16:44.140
그 사실을 알게 되면 다음 질문이 명확해집니다.

00:16:44.340 --> 00:16:49.580
마이크로소프트 연결 플랫폼 전반에서 동일한 고객 업데이트를 또 어디에 활용할 수 있을까요?

00:16:49.800 --> 00:16:52.700
연결된 플랫폼은 실제 업무에서 어떻게 작동할까요?

00:16:52.700 --> 00:16:56.500
공유된 고객 업데이트는 주변 도구들이 반응할 때 비로소 유용해집니다.

00:16:56.660 --> 00:17:02.220
파워 오토메이트는 데이터버스 행위 변경 사항을 감시하고 변경이 발생할 때 작업을 시작하여 후속 업무를 처리합니다.

00:17:02.420 --> 00:17:05.880
예를 들어 새로운 잠재 고객이 다이나믹스 365세일즈에 입력됩니다.

00:17:06.060 --> 00:17:10.940
흐름, 플로우, 을 통해 담당 영업사원에게 알림을 보내거나 팀즈의 메시지를 게시하거나 후속 작업을 생성할 수 있습니다.

00:17:11.140 --> 00:17:13.660
이제 아무도 하루 종일 공유받은 편지함을 지켜볼 필요가 없습니다.

00:17:13.960 --> 00:17:16.980
잠재 고객 정보가 변경되면 다음 단계가 자동으로 시작됩니다.

00:17:16.980 --> 00:17:21.940
파워 오토메이트는 해당 작업을 수행하기 위해 잠재 고객 데이터의 별도 복사본이 필요하지 않습니다.

00:17:22.100 --> 00:17:26.980
파워 오토메이트는 영업 앱이 사용하는 것과 동일한 고객 및 소유권 세부 정보를 사용하여 데이터버스 위행에 반응할 수 있으며

00:17:27.580 --> 00:17:32.580
이를 통해 누군가 파일을 내보내고 수동으로 이메일을 주고받는 대신 비즈니스 프로세스에 밀접하게 자동화를 유지할 수 있습니다.

00:17:32.780 --> 00:17:34.200
그런 다음 파워 BI 가 있습니다.

00:17:34.560 --> 00:17:37.180
영업 관리자는 현재 파이프라인을 확인하고 싶을 것입니다.

00:17:37.180 --> 00:17:44.660
고객 서비스 관리자는 이번 주에 접수된 문외 건수, 미결 상태인 건수, 혹은 가장 자주 문외하는 고객이 누구인지 확인해야 할 수 있습니다.

00:17:44.840 --> 00:17:47.580
파워 BI는 데이터버스 비즈니스 데이터를 보고할 수 있으므로

00:17:47.580 --> 00:17:52.420
팀은 매주 금요일 오후마다 스프레드 시트를 새로 내보낼 필요 없이 진행 중인 업무를 파악할 수 있습니다.

00:17:52.620 --> 00:17:55.600
이 보고서는 사람들이 이미 사용 중인 비즈니스 데이터를 기반으로 합니다.

00:17:55.800 --> 00:17:59.000
즉 영업 기회가 진행됨에 따라 파이프라인 차트도 자동으로 변경될 수 있습니다.

00:17:59.220 --> 00:18:02.720
상담원이 사례를 업데이트하면 사례 데시보드에서 현재 업무 부하를 확인할 수 있습니다.

00:18:02.720 --> 00:18:06.820
핵심은 데시보드가 사람이 일일이 세부사항을 확인하는 과정을 대신한다는 점입니다.

00:18:06.980 --> 00:18:11.280
데시보드를 통해 사용자는 무엇에 집중해야 할지 결정하기 전에 업무 현황을 더 명확하게 파악할 수 있습니다.

00:18:11.480 --> 00:18:14.220
파워 앱스는 동일한 프로세스에 또 다른 접근 경로를 추가합니다.

00:18:14.420 --> 00:18:17.160
현장 작업자가 고객의 현장에 도착하는 상황을 상상해보세요.

00:18:17.440 --> 00:18:21.120
그들에게 전체 다이나믹스 365세일즈 환경이 필요한 것은 아닙니다.

00:18:21.320 --> 00:18:26.680
그저 고객을 찾고 방문 세부 정보를 검토하고 내용을 확인한 뒤 메모나 사진을 추가하기만 하면 됩니다.

00:18:26.960 --> 00:18:30.320
집중적인 파워 앱은 그들에게 딱 필요한 간소화된 환경을 제공할 수 있습니다.

00:18:30.320 --> 00:18:33.380
계정팀에는 고객 계약을 검토하기 위한 앱이 필요할 수 있습니다.

00:18:33.580 --> 00:18:36.440
관리자에게는 요청을 승인하기 위한 간단한 앱이 필요할 수 있습니다.

00:18:36.640 --> 00:18:41.080
각 앱은 한 가지 작업에 집중하면서도 백엔드에서는 동일하게 제어되는 데이터버스 정보를 활용합니다.

00:18:41.280 --> 00:18:43.340
사용자는 자신의 업무에 맞는 도구만 보게 됩니다.

00:18:43.560 --> 00:18:45.600
비즈니스는 연결된 정보를 계속 유지합니다.

00:18:45.760 --> 00:18:48.400
때로는 해당 정보가 데이터버스 외부에서 시작되기도 합니다.

00:18:48.600 --> 00:18:52.400
기업이 온라인 소스에서 가져온 리스트를 비즈니스 데이터의 일부로 통합해야 할 수도 있습니다.

00:18:52.400 --> 00:18:59.600
파워 커리는 지원되는 온라인 소스에서 데이터를 가져오고 가져오는 동안 정리하며 올바른 데이터버스 테이블로 로드할 수 있습니다.

00:18:59.820 --> 00:19:04.740
이는 외부 소스에 다이나믹스 및 파워 플랫폼 도구에서 필요한 정보가 포함되어 있을 때 유용합니다.

00:19:04.980 --> 00:19:09.460
여전히 무엇이 데이터버스에 속하며 기존 테이블과 어떻게 연결되어야 하는지 결정해야 합니다.

00:19:09.680 --> 00:19:13.440
그런 고민 없이 데이터를 가져오면 혼란만 새로운 장소로 옮기는 꼴이 됩니다.

00:19:13.760 --> 00:19:16.300
이 조각들을 하나의 일상적인 흐름으로 모아보겠습니다.

00:19:16.620 --> 00:19:19.080
새로운 리드가 다이나믹스 365에 들어옵니다.

00:19:19.080 --> 00:19:23.000
할당 규칙이 지역이나 제품 등을 기준으로 해당 리드를 담당할 사람을 결정합니다.

00:19:23.180 --> 00:19:27.380
담당자는 파워 오토메이트 흐름을 통해 팀즈 메시지를 받아 대기 중인 업무가 있음을 알게 됩니다.

00:19:27.580 --> 00:19:34.240
영업사원이 리드를 업데이트하고 영업 프로세스를 진행함에 따라 파워 비아이 대시보드가 변경되어 팀과 현재 파이프라인 현황을 보여줍니다.

00:19:34.440 --> 00:19:37.060
한 번의 업데이트가 여러 곳에서 유용한 작업을 시작하게 합니다.

00:19:37.260 --> 00:19:39.780
파워 오토메이트는 업무를 한 단계에서 다음 단계로 이동시킵니다.

00:19:39.940 --> 00:19:42.080
파워 비아이는 사람들이 업무 내용을 파악하도록 돕습니다.

00:19:42.300 --> 00:19:45.160
파워 앱스는 특정 팀의 업무에 참여할 수 있는 최적화된 방식을 제공합니다.

00:19:49.080 --> 00:19:51.180
그 차이가 중요합니다.

00:19:51.340 --> 00:19:55.440
자동화는 파일링 시스템이 아니면 대시보드는 고객 데이터베이스가 아닙니다.

00:19:55.600 --> 00:19:59.100
각 도구에는 고유한 역할이 있지만 모두 동일한 원천 데이터로 작업할 수 있습니다.

00:19:59.320 --> 00:20:05.780
이 점을 알면 모든 스프레드 시트나 간단한 목록이 전체 비즈니스 프로세스를 실행해야 하는 것처럼 다루지 않고 올바른 도구를 선택하는 데 도움이 됩니다.

00:20:05.980 --> 00:20:09.260
데이터버스가 적합한 경우와 대체할 수 없는 경우를 알아봅니다.

00:20:09.460 --> 00:20:10.420
핵심은 이렇습니다.

00:20:10.700 --> 00:20:14.340
여러 사람과 앱이 연결된 비즈니스 데이터로 작업해야 할 때 데이터버스를 선택하세요.

00:20:14.540 --> 00:20:17.040
명확한 액세스 규칙과 반복 가능한 프로세스가 필요합니다.

00:20:17.040 --> 00:20:20.160
데이터버스가 이를 처리하지만 다른 모든 것을 대체하지는 않습니다.

00:20:20.300 --> 00:20:23.400
개인 분석 및 빠른 목록 작성을 위해서는 여전히 엑셀이 최선의 선택입니다.

00:20:23.600 --> 00:20:26.100
셰어포인트 목록은 간단한 팀 추적에 효과적입니다.

00:20:26.300 --> 00:20:29.900
심층적 인재어가 필요한 개발자 라면 SQL이 여전히 강력한 선택지입니다.

00:20:30.080 --> 00:20:32.340
그렇다면 데이터버스는 언제 진정으로 적합할까요?

00:20:32.480 --> 00:20:37.360
데이터를 복사본 생성 없이 다이나믹스 365 앱 자동화 보고서 전반에 걸쳐 연결해야 할 때입니다.

00:20:37.520 --> 00:20:39.380
바로 그 점이 데이터버스 위 강점입니다.

00:20:39.580 --> 00:20:42.940
결론적으로 하나의 기반의 다양한 비즈니스 도구를 활용하는 것입니다.

00:20:43.140 --> 00:20:44.200
핵심은 다음과 같습니다.

00:20:44.200 --> 00:20:51.760
다이나믹스 365와 데이터버스는 모든 데이터, 규칙, 보안, 앱, 자동화 및 보고서가 하나의 공통 기반을 공유할 때 가장 잘 작동합니다.

00:20:51.920 --> 00:20:56.620
다이나믹스 365, 파워 플랫폼 및 마이크로소프트 365에 대한 더 쉬운 설명을 보려면

00:20:56.620 --> 00:20:59.560
M365 FM에서 마이크로소프트 지식나겟을 구독하세요.

00:20:59.740 --> 00:21:01.840
그런 다음 모델 기반 앱에 대한 에피소드를 시청하여

00:21:01.840 --> 00:21:05.320
데이터버스 테이블이 어떻게 작동하는 비즈니스 앱으로 변환되는지 확인해보세요.

00:21:05.320 --> 00:21:06.320
감사합니다.

00:21:06.320 --> 00:21:07.320
감사합니다.

00:21:07.320 --> 00:21:08.320
감사합니다.