WEBVTT

00:00:03.570 --> 00:00:06.470
마이크로소프트 지식나겟에 오신 것을 환영합니다.

00:00:06.670 --> 00:00:08.010
저는 미르코 피터스입니다.

00:00:08.270 --> 00:00:10.830
오늘의 주제는 많은 분이 혼란스러워하는 부분입니다.

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

00:00:12.970 --> 00:00:14.450
데이터베이스일까요? 앱일까요?

00:00:14.710 --> 00:00:18.030
아니면 IT 전문가만 알아야 할 숨겨진 다이나믹스 365 서비스일까요?

00:00:18.230 --> 00:00:19.970
가장 간단한 정의를 말씀드리겠습니다.

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

00:00:24.330 --> 00:00:27.050
다이나믹스 365를 사무용 빌딩이라고 생각해보세요.

00:00:27.050 --> 00:00:30.490
영업, 고객 서비스 및 기타 앱은 사람들이 일하는 사무실이며

00:00:30.490 --> 00:00:34.010
데이터버스는 그 벽 뒤에 있는 관리 시스템 이자 규칙입니다.

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

00:00:36.930 --> 00:00:41.250
그리고 고객 정보 변경 사항이 어떻게 영업 업무, 자동화, 보고서에 반영되는지 알게 되실 겁니다.

00:00:41.470 --> 00:00:45.770
제품 이름을 언급하기 전에 이 기술이 해결하는 비즈니스의 복잡함부터 살펴보겠습니다.

00:00:46.170 --> 00:00:49.330
하나의 공유 공간, 각각의 개별 사본 대신 말이죠.

00:00:49.550 --> 00:00:52.750
영업팀, 지원팀, 재무팀이 있는 회사를 상상해보세요.

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

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

00:00:58.010 --> 00:01:00.270
재무팀은 자체 시스템의 고객 이름을 관리합니다.

00:01:00.490 --> 00:01:02.750
누군가는 이메일 대화 내용을 공유 메일함에 저장하고

00:01:02.750 --> 00:01:05.690
또 다른 누군가는 아무도 찾을 수 없는 폴더에 메모를 보관합니다.

00:01:05.890 --> 00:01:08.170
이제 같은 고객 정보가 다섯 곳에 존재하게 됩니다.

00:01:08.430 --> 00:01:12.470
각 팀은 눈앞의 업무만 처리하기 때문에 처음에는 이런 설정이 당연하게 느껴집니다.

00:01:12.650 --> 00:01:17.770
하지만 문제는 고객이 전화번호, 주소, 회사명 또는 담당자를 변경하는 즉시 발생합니다.

00:01:17.770 --> 00:01:20.610
영업팀이 스프레드 시트를 업데이트해도 지원팀은 이를 알 수 없고

00:01:20.610 --> 00:01:22.910
재무팀은 여전히 예전 주소로 문서를 보냅니다.

00:01:22.910 --> 00:01:26.170
그러면 누군가가 목록을 내보내 수동으로 정리한 뒤 이메일로 공유하고

00:01:26.170 --> 00:01:29.150
갑자기 3명 모두 각자의 사본이 정확하다고 믿게 됩니다.

00:01:29.350 --> 00:01:30.690
어떤 목록을 믿어야 할까요?

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

00:01:33.370 --> 00:01:35.210
직원들은 기록을 대조하느라 시간을 허비합니다.

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

00:01:38.310 --> 00:01:41.310
지원 상담원은 이미 다른 곳에 정보가 있는 고객을 위해 사례를 새로 생성하는데

00:01:41.310 --> 00:01:42.530
정보가 조금씩 다릅니다.

00:01:42.730 --> 00:01:44.350
아무도 혼란을 만들려는 것은 아닙니다.

00:01:44.350 --> 00:01:46.270
이러한 혼란은 사본들로부터 발생합니다.

00:01:46.430 --> 00:01:50.910
20년 전에는 시스템이 나뉘어 있으면 서버, 데이터베이스, 팀도 각각 따로 정보를 관리해야 했습니다.

00:01:51.190 --> 00:01:54.830
이들을 연결하려면 맞춤형 작업, 예약된 가져오기, 그리고 많은 수동 검토가 필요했습니다.

00:01:55.070 --> 00:01:59.430
한 곳의 변경사항이 다른 시스템에 반영되는데 내일이 걸릴지, 다음 주가 걸릴지, 아니면 영영 안될지도 모르는 일이었죠.

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

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

00:02:07.630 --> 00:02:15.450
정보를 구조화된 테이블의 저장함으로, 제각각의 메모 나흐터진 파일, 연결되지 않은 스프레드 시트 탭으로 존재하는 대신 명확한 형태를 갖추게 됩니다.

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

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

00:02:22.870 --> 00:02:27.090
영업사원이 거래를 진행할 때 해당 고객이 다이나믹스 365세일즈에 표시될 수 있습니다.

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

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

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

00:02:41.910 --> 00:02:44.550
그렇다고 해서 모든 팀이 갑자기 모든 것을 볼 수 있다는 뜻은 아닙니다.

00:02:44.750 --> 00:02:47.570
액세스에는 여전히 규칙이 필요하며, 이에 대해서는 곧 다룰 예정입니다.

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

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

00:02:56.550 --> 00:03:01.850
영업 및 고객 서비스와 같은 다이나믹스 365 앱은 데이터버스를 사용하여 작업하는 데이터를 저장하고 보호합니다.

00:03:02.030 --> 00:03:09.230
하지만 중요한 점은 누군가 다이나믹스 365와 데이터버스 위 통합을 이야기할 때 종종 연결 도구가 필요한 두 개의 별도 제품으로 상상한다는 것입니다.

00:03:09.410 --> 00:03:12.410
많은 다이나믹스 365 앱의 경우 그런 상황이 아닙니다.

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

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

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

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

00:03:28.230 --> 00:03:36.570
이 두 고객 목록을 어떻게 동기화할까? 라고 묻는 대신 어떤 사람과 앱이 고객 레코드로 작업해야 하며, 각각 무엇을 할 수 있어야 할까? 라고 질문할 수 있습니다.

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

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

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

00:03:51.310 --> 00:03:55.810
데이터버스는 연결된 앱이 공유해야 하는 비즈니스 데이터를 위한 공통된 장소를 제공합니다.

00:03:56.010 --> 00:04:00.050
고객 세부 정보, 영업 작업, 지원 작업, 작업 및 후속 조치 등이 포함됩니다.

00:04:00.250 --> 00:04:03.970
해당 레코드는 승인된 도구가 있고, 업데이트할 수 있는 하나의 소스와 함께 공존할 수 있습니다.

00:04:04.170 --> 00:04:06.530
자, 저와 함께 그 서류 보관함을 열어봅시다.

00:04:06.770 --> 00:04:12.750
데이터버스가 내부 정보를 구성하는 방식을 알게 되면, 다이나믹스 365 전체 연결을 훨씬 쉽게 이해할 수 있습니다.

00:04:12.750 --> 00:04:16.690
서류 보관함, 테이블, 행, 열 그리고 관계들입니다.

00:04:16.810 --> 00:04:18.310
그 서류 보관함을 열어보겠습니다.

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

00:04:21.050 --> 00:04:23.250
별도의 서랍이 있는 실제 보관함이라고 생각하세요.

00:04:23.490 --> 00:04:27.710
아, 한 서랍에는 회사 정보가, 다른 서랍에는 사람 정보가, 세 번째 서랍에는 지원 요청이 들어 있습니다.

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

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

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

00:04:36.250 --> 00:04:38.590
계정 테이블에는 보통 협력 관계인 기업 정보가 담깁니다.

00:04:38.590 --> 00:04:40.730
연락처 테이블에는 개인 정보가 담깁니다.

00:04:40.870 --> 00:04:44.170
잠재 고객 테이블에는 고객이 되기 전이 잠재적 고객 정보가 담깁니다.

00:04:44.350 --> 00:04:50.450
사례 테이블에는 지원 요청이 담기며, 활동 테이블로는 통화, 이메일, 약속, 작업 같은 업무를 추적할 수 있습니다.

00:04:50.690 --> 00:04:52.090
이런 것들이 표준 테이블입니다.

00:04:52.290 --> 00:04:56.910
대부분의 기업이 고객, 사람, 업무, 대화 내용을 추적해야 함으로 마이크로소프트 가이 테이블들을 제공합니다.

00:04:57.070 --> 00:05:00.890
표준 테이블로 충분한 일반적인 업무라면 굳이 처음부터 새 테이블을 만들 필요가 없습니다.

00:05:01.190 --> 00:05:03.410
하지만 모든 기업은 각자 고유한 업무를 가지고 있습니다.

00:05:03.410 --> 00:05:06.390
교육 기업이라면 교육 과정이나 자격증을 추적해야 할 수 있습니다.

00:05:06.570 --> 00:05:09.730
부동산 업체는 건물, 호실, 점검 항목 등이 필요할 수 있습니다.

00:05:09.950 --> 00:05:13.050
제조업체는 장비 점검이나 서비스 방문을 추적할지도 모릅니다.

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

00:05:17.290 --> 00:05:21.150
사용자 지정 테이블은 캐비닛에 새 서랍을 추가하고 명확한 라벨을 붙이는 것과 같습니다.

00:05:21.490 --> 00:05:23.210
이제 각 테이블 N은 행이 포함됩니다.

00:05:23.430 --> 00:05:25.730
행은 해당 서랍에 들어있는 항목 하나하나를 의미합니다.

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

00:05:30.530 --> 00:05:34.690
그녀의 행은 시스템 내 다른 모든 연락처와 구분되는 그녀만의 세부 정보를 담고 있습니다.

00:05:34.950 --> 00:05:37.270
열은 각 행에 보관할 세부 정보를 설명합니다.

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

00:05:44.950 --> 00:05:47.190
열은 해당 위치에 들어갈 정보의 유형을 지정함으로

00:05:47.190 --> 00:05:51.610
이메일 열에는 이메일 주소가 오고 상태 열에는 승인된 상태 항목이 들어갈 수 있습니다.

00:05:51.850 --> 00:05:54.910
비즈니스 정보는 바로 이런 식으로 안정적인 형태를 갖추게 됩니다.

00:05:54.910 --> 00:05:57.950
열이 없다면 누군가는 메모란에 전화번호를 입력하고

00:05:57.950 --> 00:06:02.110
누군가는 이름 필드에 넣거나 아예 입력하지 않는 사람도 있을 것입니다.

00:06:02.270 --> 00:06:06.670
명확한 연락처 테이블을 사용하면 모든 사람이 동일한 위치에서 동일한 세부 정보 세트를 다룰 수 있습니다.

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

00:06:09.610 --> 00:06:10.890
양식은 올바른 상자를 보여주고

00:06:10.890 --> 00:06:13.070
보고서는 상태별로 연락처를 그룹화하며

00:06:13.070 --> 00:06:15.370
자동화는 소유자가 변경될 때 반응할 수 있습니다.

00:06:15.610 --> 00:06:17.070
정보는 단순히 저장되는 것이 아니라

00:06:17.070 --> 00:06:20.490
연결된 도구들의 각 부분이 무엇을 의미하는지 알려주는 나벨을 갖게 됩니다.

00:06:20.490 --> 00:06:23.850
비즈니스 요구사항에 맞는다면 항상 표준 테이블부터 시작하세요.

00:06:23.990 --> 00:06:25.390
기업을 대상으로 판매한다면

00:06:25.390 --> 00:06:28.610
계정과 연락처는 이미 대부분이 이해하는 패턴을 제공합니다.

00:06:28.810 --> 00:06:31.850
고객 지원을 담당한다면 사례가 좋은 시작점이 됩니다.

00:06:32.130 --> 00:06:34.770
기본 패턴에 맞지 않는 비즈니스 정보가 있을 때만

00:06:34.770 --> 00:06:36.690
사용자 지정 테이블을 추가하세요.

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

00:06:41.430 --> 00:06:42.810
어떤 팀은 클라이언트라고 부르고

00:06:42.810 --> 00:06:44.250
다른 팀은 고객 마스터

00:06:44.250 --> 00:06:46.570
또 다른 팀은 파트너 연락처라고 부를 수 있습니다.

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

00:06:49.430 --> 00:06:52.370
명확한 표준 테이블과 신중하게 명명된 사용자 지정 테이블을 사용하면

00:06:52.370 --> 00:06:54.770
더 많은 사람이 작업하더라도 캐비닛을 쉽게 이해할 수 있습니다.

00:06:54.930 --> 00:06:57.730
다음 부분은 이러한 서랍들이 서로 연동되기 시작하는 단계입니다.

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

00:06:59.530 --> 00:07:01.730
마리아는 컨토소 ltd에서 일합니다.

00:07:01.910 --> 00:07:05.650
마리아 위행의 컨토소의 주소, 전화번호, 회사 정보를 반복해서 입력하는 대신

00:07:05.650 --> 00:07:09.030
데이터버스를 통해 연락처 테이블과 계정 테이블 간의 관계를 만들 수 있습니다.

00:07:09.250 --> 00:07:10.610
마리아는 컨토소와 연결되며

00:07:10.610 --> 00:07:13.650
회사 정보가 회사 데이터 내에 유지되기 때문에 이 연결은 중요합니다.

00:07:13.830 --> 00:07:15.330
컨토소가 사무실 주소를 변경하면

00:07:15.330 --> 00:07:16.910
계정행을 한 번만 업데이트하면 되고

00:07:16.910 --> 00:07:19.670
관련 연락처들은 각자 오래된 정보를 보관할 필요 없이

00:07:19.670 --> 00:07:20.990
동일한 회사를 참조하게 됩니다.

00:07:21.190 --> 00:07:24.310
관계는 또한 지원 사례를 이를 제기한 고객과 연결합니다.

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

00:07:29.790 --> 00:07:33.470
영업사원이 기회를 열면 관련 없는 메모나 캘린더를 뒤질 필요 없이

00:07:33.470 --> 00:07:35.710
해당 기회에 연결된 활동을 볼 수 있습니다.

00:07:35.970 --> 00:07:37.610
정보의 맥락이 생기는 것입니다.

00:07:37.890 --> 00:07:39.450
단순히 사례번호만 보는 것이 아니라

00:07:39.450 --> 00:07:41.930
어느 고객에게 속한 사례인지 확인할 수 있습니다.

00:07:41.930 --> 00:07:45.710
연락처만 보는 것이 아니라 그 사람과 연결된 회사도 볼 수 있습니다.

00:07:45.950 --> 00:07:48.310
이러한 링크 덕분에 동일한 사실을 여러 곳에 반복해서

00:07:48.310 --> 00:07:50.690
입력하지 않고도 데이터를 유용하게 활용할 수 있습니다.

00:07:50.910 --> 00:07:54.110
오래된 가이드나 영상을 보기 전에 용어에 관한 작은 참고사항이 있습니다.

00:07:54.370 --> 00:07:57.390
엔터티, 엔터티, 필드, 필드, 레코드, 레코드 라는 용어를 들을 수도 있습니다.

00:07:57.610 --> 00:07:59.230
이것들은 예전 데이터버스 용어입니다.

00:07:59.430 --> 00:08:02.370
현재 마이크로소프트는 엔터티 대신 테이블, 필드 대신 열,

00:08:02.630 --> 00:08:04.270
레코드 대신 행이라는 용어를 사용합니다.

00:08:04.450 --> 00:08:05.890
의미는 변하지 않았습니다.

00:08:05.890 --> 00:08:09.970
엔터티를 만들라는 예전 가이드는 테이블을 만들라는 의미이며

00:08:09.970 --> 00:08:12.910
필드는 열, 레코드는 행을 뜻합니다.

00:08:13.090 --> 00:08:16.870
두 용어를 모두 알아두면 다른 제품이라고 오해하는 일을 방지할 수 있습니다.

00:08:17.110 --> 00:08:20.450
결론적으로 테이블은 정보를 정리하고 관계는 정보를 연결합니다.

00:08:20.630 --> 00:08:23.010
하지만 잘 정리된 캐비닛에도 제어 장치는 필요합니다.

00:08:23.210 --> 00:08:25.110
누군가는 사람들이 무엇을 입력하고 변경하며

00:08:25.110 --> 00:08:27.090
무엇에 안전하게 접근할 수 있는지 결정해야 합니다.

00:08:27.250 --> 00:08:29.110
규칙과 안내데스크가 필요한 이유입니다.

00:08:29.310 --> 00:08:31.350
데이터버스 내부의 데이터는 권한이 있는 사용자가

00:08:31.350 --> 00:08:33.210
안전하게 작업할 때만 제대로 작동합니다.

00:08:33.210 --> 00:08:36.330
영업 담당자는 고객 세부 정보가, 지원 상담원은 사례 내역이,

00:08:36.630 --> 00:08:38.150
관리자는 더 넓은 시야가 필요하며

00:08:38.150 --> 00:08:41.130
외부 파트너는 프로세스의 일부에만 접근할 권한이 필요할 수 있습니다.

00:08:41.330 --> 00:08:43.250
이들이 모두 같은 정보를 볼 수는 없습니다.

00:08:43.550 --> 00:08:45.490
비공개 연락처 메모, 협상된 가격,

00:08:45.810 --> 00:08:48.590
진행 중인 지원 사례가 포함된 고객 레코드를 생각해 보십시오.

00:08:48.710 --> 00:08:51.710
모든 사용자에게 전체 액세스 권한을 주면 금세 위험이 발생합니다.

00:08:51.910 --> 00:08:55.070
너무 영격하게 제한하여 업무를 수행할 수 없게 만드는 것도 또 다른 문제입니다.

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

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

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

00:09:03.410 --> 00:09:06.330
엔트라 아이디를 사무실 입구의 안내데스크라고 생각해 보세요.

00:09:06.530 --> 00:09:09.910
도착해서 배지를 보여주면 접수원이 입실 전 신원을 확인하는 것과 같습니다.

00:09:10.230 --> 00:09:13.610
데이터버스는 그 아이디를 사용하여 어떤 사용자가 데이터를 다루는지 파악합니다.

00:09:13.770 --> 00:09:16.730
이 사람이 들어올 수 있는가? 라는 질문에서 멈추지 않습니다.

00:09:16.930 --> 00:09:18.870
들어온 후이 사람이 무엇을 할 수 있는가?

00:09:19.010 --> 00:09:20.150
또 함께 질문합니다.

00:09:20.350 --> 00:09:21.990
여기서 보안 역할이 필요합니다.

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

00:09:25.390 --> 00:09:30.310
영업 직원용 역할, 고객 서비스 상담원용 역할, 관리자용 역할을 각각 만들 수 있습니다.

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

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

00:09:38.050 --> 00:09:40.530
중요한 고객 정보를 삭제할 권한은 없을 수 있습니다.

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

00:09:44.990 --> 00:09:48.610
이 권한은 행을 읽고, 만들고, 변경하고, 삭제하는 작업까지 포함합니다.

00:09:48.810 --> 00:09:52.510
즉, 액세스 권한은 앱마다 어떤 버튼을 숨길지 기억하는 것에 의존하지 않습니다.

00:09:52.510 --> 00:09:54.490
권한은 데이터 자체에 귀속됩니다.

00:09:54.630 --> 00:09:57.870
따라서 데이터버스 데이터가 어디에 나타나든 동일한 가드레일이 적용됩니다.

00:09:58.050 --> 00:10:00.110
그런 다음 액세스 범위를 더 좁힐 수 있습니다.

00:10:00.330 --> 00:10:03.430
행 수준 보완은 어떤 개별 행을 작업할 수 있는지 결정합니다.

00:10:03.670 --> 00:10:08.970
영업 담당자는 본인 소유의 고객만 볼 수 있지만, 영업 관리자는 팀원 소유의 모든 고객 행을 볼 수 있습니다.

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

00:10:11.450 --> 00:10:13.630
단지 전체 데이터 중 서로 다른 부분만 보는 것입니다.

00:10:13.850 --> 00:10:17.430
이러한 설정은 각자가 업무에 집중하도록 독고 관리자에게 필요한 뷰를 제공합니다.

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

00:10:21.910 --> 00:10:24.110
더 엄격한 보호가 필요한 정보도 있습니다.

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

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

00:10:34.030 --> 00:10:36.710
고객 행은 여전히 업무 수행을 위해 열람 가능합니다.

00:10:36.910 --> 00:10:39.090
보호된 열만 제한된 상태로 유지됩니다.

00:10:39.290 --> 00:10:43.190
대기업의 경우 비즈니스 단위를 사용하여 조직 간의 경계를 설정할 수 있습니다.

00:10:43.190 --> 00:10:47.710
기업은 서로 다른 고객 그룹을 담당하는 지역, 부서 또는 자회사를 분리할 수 있습니다.

00:10:47.930 --> 00:10:51.370
비즈니스 단위는 이러한 경계를 넘어 액세스가 작동하는 방식을 결정하는 데 도움을 줍니다.

00:10:51.570 --> 00:10:54.350
그렇다고 해서 모든 기업의 복잡한 보안 맵이 필요한 것은 아닙니다.

00:10:54.530 --> 00:10:56.810
소규모 팀은 몇 가지 명확한 역할만 필요할 수 있습니다.

00:10:57.030 --> 00:11:00.830
규모가 큰 기업은 팀, 지역, 책임이 다르기 때문에 더 많은 계층이 필요할 수 있습니다.

00:11:01.050 --> 00:11:04.570
핵심은 데이터버스가 실제 비즈니스 운영 방식에 맞춰 액세스를 조정할 수 있다는 점입니다.

00:11:04.790 --> 00:11:09.050
액세스 제어는 데이터 접근 권한을 보호하지만, 규칙은 데이터 자체의 품질을 보호합니다.

00:11:09.050 --> 00:11:13.370
비즈니스 규칙을 설정하면 새 연락처를 저장하기 전에 전화번호 입력을 필수로 만들 수 있습니다.

00:11:13.570 --> 00:11:16.710
사례가 종료될 때 사유를 요구하는 것과 같은 조건을 검사할 수도 있습니다.

00:11:16.910 --> 00:11:20.250
또한 사용자가 입력한 정보에 따라 사용자에게 표시되는 내용을 변경할 수도 있습니다.

00:11:20.470 --> 00:11:23.250
동일한 규칙이 해당 테이블을 사용하는 앱 전체에 적용됩니다.

00:11:23.450 --> 00:11:27.850
이는 한 앱은 불안전한 데이터를 허용하고, 다른 앱은 거부하는 상황을 방지해야 하기 때문에 중요합니다.

00:11:28.030 --> 00:11:31.310
규칙은 특정 화면이 아니라 비즈니스 정보와 함께 존재해야 합니다.

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

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

00:11:38.270 --> 00:11:41.130
데이터는 단순한 저장을 넘어 규칙과 함께 제공됩니다.

00:11:41.330 --> 00:11:46.650
따라서 기반에는 정보, 정보를 다룰 수 있는 사람, 그리고 사용 가능한 상태로 유지하는 규칙이 포함됩니다.

00:11:46.850 --> 00:11:52.750
다이나믹스 365가 동일한 기반 위에서 작동하면, 자체 비즈니스 데이터에 액세스하기 위해 기존의 브릿지가 필요하지 않습니다.

00:11:52.950 --> 00:11:56.050
다이나믹스 365 통합 위 진정한 의미는 무엇일까요?

00:11:56.050 --> 00:12:02.470
대부분은 데이터버스와 다이나믹스 365 통합이라는 말을 들으면 커넥터로 연결된 두 개의 별도 시스템을 떠올립니다.

00:12:02.710 --> 00:12:10.450
한 시스템이 고객 데이터를 보유하고 다른 시스템이 복사본을 필요로 하면, 누군가가 동기화를 설정하고 실행을 기다리며 오류가 없기를 바랍니다.

00:12:10.690 --> 00:12:13.270
이러한 방식은 많은 비즈니스 도구에 적합합니다.

00:12:13.510 --> 00:12:20.670
하지만 여기 다이나믹스 365 세일즈와 다이나믹스 365 커스터머 서비스의 경우에는 연결 방식이 훨씬 더 긴밀합니다.

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

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

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

00:12:31.810 --> 00:12:33.230
구체적인 예를 들어보겠습니다.

00:12:33.730 --> 00:12:39.090
영업 담당자라고 가정하고 다이나믹스 365 세일즈에서 새 회사를 만든다고 해보죠.

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

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

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

00:12:48.390 --> 00:12:51.930
지원 상담원은 동일한 회사 및 연락처 정보를 그대로 사용하여 작업할 수 있습니다.

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

00:12:56.830 --> 00:13:02.090
상담원은 지원 사례를 해당 고객에게 연결하기만 하면 상황을 이해하는 데 필요한 이력을 즉시 확인할 수 있습니다.

00:13:02.310 --> 00:13:06.830
영업 부서는 거래를 보고 지원 부서는 사례를 보며 두 팀 모두 동일한 고객을 중심으로 업무를 수행합니다.

00:13:07.010 --> 00:13:11.430
그렇다고 해서 모든 화면이 동일하거나 모든 팀이 같은 프로세스를 따르는 것은 아닙니다.

00:13:11.630 --> 00:13:14.630
영업에는 리드, 기회, 통화, 미팅이 필요합니다.

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

00:13:18.010 --> 00:13:21.990
각 다이나믹스 365 앱은 사용자에게 해당 직무에 최적화된 도구를 제공합니다.

00:13:22.150 --> 00:13:24.870
기저의 비즈니스 정보는 필요한 곳 어디든 연결될 수 있으며,

00:13:25.310 --> 00:13:30.510
이러한 공유 기반 이야말로 사람들이 다이나믹스 365와 데이터버스 통합을 말할 때 흔히 의미하는 바입니다.

00:13:30.690 --> 00:13:34.490
이는 단순히 데이터를 A 지점에서 B 지점으로 옮기는 것이 아닙니다.

00:13:34.670 --> 00:13:39.830
모든 앱이 처음부터 동일한 행, 관계, 규칙 및 액세스 제어를 기반으로 작동하는 것입니다.

00:13:40.050 --> 00:13:41.830
간단한 영업 과정을 살펴보겠습니다.

00:13:42.330 --> 00:13:44.830
웹사이트나 이벤트를 통해 리드가 유입됩니다.

00:13:44.830 --> 00:13:51.050
영업 담당자는 해당 리드를 관리하고 고객에 대해 더 많이 파악하며 리드를 고객관계 및 기회로 전환합니다.

00:13:51.230 --> 00:13:54.910
통화, 이메일, 약속, 작업 모드를 해당 업무에 연결할 수 있습니다.

00:13:55.130 --> 00:13:58.710
따라서 팀이 전체 맥락을 파악하기 위해 별도의 도구를 찾아다닐 필요가 없습니다.

00:13:59.030 --> 00:14:03.130
나중에 고객이 도움이 필요하면 지원 사례를 동일한 고객에게 다시 연결할 수 있습니다.

00:14:03.390 --> 00:14:06.670
지원 상담원은 단순히 이름과 이메일 주소만 보는 것이 아닙니다.

00:14:06.870 --> 00:14:10.350
이미 식별된 고객관계의 맥락 속에서 업무를 수행할 수 있습니다.

00:14:10.350 --> 00:14:17.410
그동안 영업팀은 고객에게 미해결 서비스 문제가 있음을 확인하여 문제를 모른 채 갱신 상담을 진행하는 상황을 피할 수 있습니다.

00:14:17.650 --> 00:14:23.570
하나의 고객관계는 단순히 두 시스템에서 고객 이름을 일치시키는 것보다 훨씬 유용한 다양한 업무를 지원할 수 있습니다.

00:14:23.770 --> 00:14:28.410
공통 데이터 모델, 커먼 데이터 모델이라는 용어를 들어보셨을 수도 있으며 줄여서 cdm이라고도 합니다.

00:14:28.610 --> 00:14:31.090
이름 때문에 너무 복잡하게 생각할 필요는 없습니다.

00:14:31.090 --> 00:14:38.770
이는 마이크로소프트 가 계정, 연락처, 활동, 사례와 같이 많은 기업이 추적하는 항목에 대해 공통 비즈니스 테이블 패턴을 제공한다는 의미일 뿐입니다.

00:14:38.910 --> 00:14:43.230
이러한 패턴은 다이나믹스 365와 데이터버스 기반 앱들이 공통의 시작 언어를 갖게 해줍니다.

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

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

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

00:14:49.350 --> 00:14:55.070
회사에 맞춰 설정을 조정하고 필요할 때 자체 테이블을 추가할 수 있지만 매번 빈시트에서 시작할 필요는 없습니다.

00:14:55.070 --> 00:15:01.490
한 앱이 계정 테이블을 이해하고 다른 앱이 동일한 테이블을 사용하면 두 앱 모두 동일한 유형의 비즈니스 정보를 참조하게 됩니다.

00:15:01.690 --> 00:15:04.090
이는 또한 구축할 수 있는 기능의 범위를 변화시킵니다.

00:15:04.250 --> 00:15:09.390
현장팀이 고객을 조회하고 방문을 확인하며 약속 후 메모를 추가할 수 있는 간단한 앱이 필요하다고 가정해보십시오.

00:15:09.530 --> 00:15:14.250
다이나믹스 365에서 이미 사용 중인 동일한 데이터버스 테이블과 연동되는 파워 앱을 구축할 수 있습니다.

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

00:15:18.170 --> 00:15:21.890
현장 작업자가 앱을 열어 고객을 찾고 방문 정보를 업데이트합니다.

00:15:21.890 --> 00:15:28.990
데이터는 앞서 살펴본 보안 규칙에 따라 영업이나 고객 서비스 부서가 이미 사용 중인 고객 관계와 연결된 상태로 유지됩니다.

00:15:29.170 --> 00:15:32.490
더 체계적인 비즈니스 작업을 위해서는 모델 기반 앱을 구축할 수 있습니다.

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

00:15:35.050 --> 00:15:39.870
데이터버스 테이블을 선택하고 관계를 정의하며 양식과 보기를 설정하고 보안 역할을 적용합니다.

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

00:15:44.090 --> 00:15:47.530
팀이 실제로 사용하는 도구와 자료를 중심으로 작업대를 정리하는 것과 같습니다.

00:15:47.850 --> 00:15:50.590
테이블은 작업을 설명하고 관계는 항목들을 연결합니다.

00:15:50.590 --> 00:15:53.710
양식을 통해 사용자는 세부 정보를 입력하고 검토할 수 있습니다.

00:15:53.910 --> 00:15:56.170
보기는 주의가 필요한 행을 찾는 데 도움을 줍니다.

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

00:15:59.390 --> 00:16:03.790
모델 기반 앱은 다이나믹스 365와 함께 사용할 수 있는데 둘 다 데이터버스를 기반으로 하기 때문입니다.

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

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

00:16:11.750 --> 00:16:15.730
두 앱 모두 두 번째 고객 데이터베이스를 만들지 않고도 관련 고객 데이터를 작업할 수 있습니다.

00:16:15.990 --> 00:16:18.310
물론 이러한 액세스에는 여전히 주의가 필요합니다.

00:16:18.310 --> 00:16:24.910
앱이 데이터버스 테이블과 연동된다고 해서 모든 사용자가 모든 행을 편집하거나 모든 열을 볼 수 있어야 하는 것은 아닙니다.

00:16:25.110 --> 00:16:28.570
역할, 행 액세스 및 비즈니스 규칙이 여전히 작업 내용을 제어합니다.

00:16:28.770 --> 00:16:31.870
현장 앱은 회사의 나머지 데이터, 나타사 데이터를 노출하지 않고도

00:16:31.870 --> 00:16:35.190
사용자에게 필요한 고객 세부 정보와 작업만 정확히 제공할 수 있습니다.

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

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

00:16:46.310 --> 00:16:49.110
일단 이를 이해하면 다음 질문이 분명해집니다.

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

00:16:55.030 --> 00:16:57.850
연결된 플랫폼이 실제 업무에서 작동하는 방식입니다.

00:16:58.050 --> 00:17:01.670
공유된 고객 업데이트는 주변 도구가 그에 대응할 수 있을 때 유용해집니다.

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

00:17:07.330 --> 00:17:10.930
예를 들어 새로운 리드가 다이나믹스 365세일즈에 입력됩니다.

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

00:17:16.410 --> 00:17:18.910
누구도 하루 종일 공유받은 편지함을 지켜볼 필요가 없습니다.

00:17:19.210 --> 00:17:22.030
리드가 변경되면 다음 단계가 자동으로 시작됩니다.

00:17:22.250 --> 00:17:26.730
파워 오토메이트는 작업을 수행하기 위해 리드의 별도 복사본이 필요하지 않습니다.

00:17:26.930 --> 00:17:31.910
판매 앱이 사용하는 것과 동일한 고객 및 소유권 세부 정보를 사용하여 데이터버스 위행에 반응할 수 있습니다.

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

00:17:38.170 --> 00:17:39.450
다음은 파워 비아이입니다.

00:17:39.690 --> 00:17:42.450
영업관리자는 현재 파이프라인을 확인하고 싶어 할 수 있습니다.

00:17:42.710 --> 00:17:49.690
고객 서비스 관리자는 이번 주에 접수된 사례수, 미해결 사례 또는 가장 자주 문외하는 고객이 누구인지 확인해야 할 수 있습니다.

00:17:49.910 --> 00:17:57.470
파워 비아이는 데이터버스 비즈니스 데이터를 보고할 수 있으므로 팀은 매주 금요일 오후에 스프레드 시트를 새로 내보낼 필요 없이 진행 중인 업무를 파악할 수 있습니다.

00:17:57.710 --> 00:18:00.630
보고서는 이미 사용 중인 비즈니스 데이터를 바탕으로 작성됩니다.

00:18:00.630 --> 00:18:04.190
즉 영업기회가 진행됨에 따라 파이프라인 차트도 실시간으로 변경될 수 있습니다.

00:18:04.370 --> 00:18:07.790
상담원이 사례를 업데이트하면 사례 데시보드에 현재 업무량이 표시됩니다.

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

00:18:12.130 --> 00:18:16.250
데시보드를 통해 무엇을 처리해야 할지 결정하기 전에 업무를 더 명확하게 파악할 수 있습니다.

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

00:18:19.470 --> 00:18:22.190
현장 직원이 고객 사이트에 도착하는 상황을 상상해보세요.

00:18:22.470 --> 00:18:26.090
그들에게 다이나믹스 365 영업환경 전체가 필요한 것은 아닙니다.

00:18:26.090 --> 00:18:31.790
고객을 찾고 방문 세부 정보를 검토하고 내용을 확인한 뒤 메모나 사진을 추가하는 것만으로도 충분할 수 있습니다.

00:18:31.990 --> 00:18:35.570
집중적 인파워 앱을 사용하면 필요한 기능만 제공하는 간소화된 환경을 경험할 수 있습니다.

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

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

00:18:41.690 --> 00:18:46.150
각 앱은 하나의 작업에 집중하면서도 백엔드에서는 동일하게 제어되는 데이터버스 정보를 사용합니다.

00:18:46.370 --> 00:18:48.430
사용자는 자신의 업무에 맞는 도구를 보게 됩니다.

00:18:48.710 --> 00:18:50.490
기업은 연결된 정보를 유지하게 됩니다.

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

00:18:53.370 --> 00:18:57.550
기업이 비즈니스 데이터에 일부러 포함해야 할 온라인 소스의 목록을 가지고 있을 수 있습니다.

00:18:57.770 --> 00:19:04.730
파워 커리는 지원되는 온라인 소스에서 데이터를 가져와 가져오는 과정에서 정리하고 적절한 데이터버스 테이블에 로드할 수 있습니다.

00:19:04.990 --> 00:19:09.790
이는 외부 소스의 다이나믹스 및 파워 플랫폼 도구에서 사용해야 할 정보가 있을 때 유용합니다.

00:19:09.990 --> 00:19:14.630
어떤 데이터를 데이터버스에 포함할지 기존 테이블과 어떻게 연결할지는 여전히 결정해야 합니다.

00:19:14.850 --> 00:19:18.670
이러한 고민 없이 데이터를 가져오면 혼란만 새로운 장소로 옮겨갈 뿐입니다.

00:19:18.870 --> 00:19:21.970
오톰 이 조각들을 하나의 일상적인 흐름으로 결합하도록 해봅시다.

00:19:21.970 --> 00:19:28.110
새로운 잠재고객이 다이나믹스 365에 입력되면 할당규칙이 지역인화제품 등에 따라 누가의 잠재고객을 담당해야 할지 확인합니다.

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

00:19:32.710 --> 00:19:39.490
영업 담당자가 잠재고객 정보를 업데이트하고 영업 프로세스를 진행함에 따라 파워 비아이 대시보드가 변경되어 팀에게 현재 파이프라인 상황을 보여줍니다.

00:19:39.670 --> 00:19:42.110
하나의 업데이트가 여러 곳에서 유용한 작업을 시작합니다.

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

00:19:45.050 --> 00:19:47.270
파워 비아이는 사람들이 업무를 파악할 수 있도록 돕습니다.

00:19:47.270 --> 00:19:50.370
파워 앱스는 특정팀이 업무에 집중적으로 참여할 방법을 제공합니다.

00:19:50.550 --> 00:19:54.910
데이터버스는 이러한 도구들이 작동하는 동안 비즈니스 정보를 체계적이고 안전하게 유지합니다.

00:19:55.090 --> 00:19:56.270
그 차이가 중요합니다.

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

00:20:00.750 --> 00:20:04.170
각 도구는 별도의 역할을 하지만 모두 같은 원천 데이터로 작업할 수 있습니다.

00:20:04.410 --> 00:20:10.530
이를 알면 모든 스프레드 시트나 단순 목록으로 전체 비즈니스 프로세스를 운영하려 하기 보다 올바른 도구를 선택하는 데 도움이 됩니다.

00:20:11.370 --> 00:20:14.350
데이터버스가 적합한 경우와 대체하지 못하는 것들.

00:20:14.490 --> 00:20:15.550
중요한 점은 이 겁니다.

00:20:15.550 --> 00:20:19.470
여러 사람과 앱이 연결된 비즈니스 데이터를 다뤄야 할 때 데이터버스를 선택하세요.

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

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

00:20:25.510 --> 00:20:28.390
개인적인 분석이나 빠른 목록 정리에는 여전히 엑셀이 최선입니다.

00:20:28.610 --> 00:20:31.230
쉐어포인트 목록은 단순한 팀 추적 업무에 효과적입니다.

00:20:31.470 --> 00:20:34.970
그리고 세밀한 제어가 필요한 개발자라면 SQL은 여전히 강력한 선택지입니다.

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

00:20:37.710 --> 00:20:42.710
데이터가 중복 생성 없이 다이나믹스 365앱, 자동화, 보고서 전반에 걸쳐 연결되어야 할 때입니다.

00:20:42.710 --> 00:20:45.370
그 점이 바로 강점입니다. 결론을 맺겠습니다.

00:20:45.750 --> 00:20:49.290
하나의 기반, 다양한 비즈니스 도구, 핵심은 이렇습니다.

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

00:20:57.030 --> 00:21:01.710
다이나믹스 365, 파워 플랫폼 및 마이크로소프트 365에 대한 더 쉬운 가이드를 보려면

00:21:01.710 --> 00:21:04.870
M365.FM에서 마이크로소프트 날리지 너게츠를 구독하세요.

00:21:05.090 --> 00:21:09.870
그런 다음 데이터버스 테이블이 어떻게 실무 비즈니스 앱으로 변하는지 모델 기반 앱 에피소드를 시청하세요.