마이크로소프트 날리지 너겟지에 오신 것을 환영합니다.저는 모피터스입니다.오늘의 주제는 사람들이 자주 혼동하는 내용입니다.데이터버스란 정확히 무엇일까요?데이터베이스일까요? 앱일까요?아니면 IT 전문가만 이해해야 하는 숨겨진 다이나믹스 365 서비스일까요?가장 간단한 정의는 이렇습니다.데이터버스는 많은 다이나믹스 365 환경을 뒷받침하는 공유 데이터 기반입니다.다이나믹스 365를 사무용 건물이라고 생각해보세요.영업, 고객 서비스 및 기타 앱은 사람들이 일하는 방이며데이터버스는 그 벽 뒤에 있는 파일 시스템 이자 규칙입니다.이번 에피소드가 끝날 때 쯤이면 다이나믹스 데이터가 어디에 저장되는지그리고 하나의 고객 업데이트가 어떻게 영업 업무, 자동화, 보고서에 나타나는지 알게 될 것입니다.하지만 제품 이름을 살펴보기 전에 비즈니스의 혼란스러운 상황부터 시작해보겠습니다.이것은 반일 공유 공간이라는 해결책을 제시합니다.데이터를 따로 복사해두는 대신 영업팀, 지원팀, 재무팀이 있는 회사를 상상해보세요.영업팀은 고객 정보를 스프레드 시트에 보관합니다.지원팀은 별도의 사례관리 도구에서 작업합니다.재무팀은 자체 시스템에 고객 이름을 보관합니다.누군가는 이메일 스레드를 공유 사서함에 저장하고 다른 누군가는 아무도 찾을 수 없는 폴더에 메모를 보관합니다.이제 동일한 고객 정보가 5군데에 존재하게 됩니다.각 팀은 자신 앞에 놓인 업무만 보기 때문에 처음에는 이런 설정이 정상처럼 느껴집니다.하지만 문제는 여기서 시작됩니다.고객이 전화번호, 주소, 회사명 또는 주요 연락처를 변경하는 즉시 문제가 발생합니다.영업팀은 스프레드 시트를 업데이트합니다.지원팀은 이를 알지 못합니다.재무팀은 여전히 이전 주소로 문서를 보냅니다.그러고는 누군가 목록을 내보내고 수동으로 정리하여 이메일로 돌리면갑자기 세 사람이 각자 자기 복사본이 맞다고 믿게 됩니다.

어떤 목록을 신뢰해야 할까요?그 질문은 생각보다 훨씬 더 많은 시간을 낭비하게 합니다.직원들은 기록을 대조하느라 업무를 멈춥니다.관리자는 왜 보고서가 영업 시스템과 일치하지 않는지 묻습니다.지원 담당자는 정보가 약간 다르지만 이미 다른 곳에 저장되어 있는 고객을 위해 새로운 사례를 생성합니다.아무도 혼란을 만들려고 하는 사람은 없습니다.혼란은 데이터 복사본 때문에 발생합니다. 20년 전에는 시스템이 분리되어 있다는 것은 서버, 데이터베이스, 팀이 각자의 정보를 따로 관리한다는 것을 의미했습니다.이를 연결하려면 맞춤 작업, 예약된 가져오기, 그리고 많은 수동 확인 작업이 필요했습니다.한 곳에서의 변경사항이 다른 시스템에 반영되기까지는 내일이 될 수도, 다음 주가 될 수도, 혹은 아예 안 될 수도 있었습니다.데이터버스는 비즈니스 앱에 이러한 유형의 정보를 위한 공유 공간을 제공합니다.쉽게 말해 데이터버스는 비즈니스 정보를 위한 마이크로소프트 위 클라우드 데이터 플랫폼입니다.이 플랫폼은 정보를 구조화된 테이블의 저장함으로 데이터는 무작위 메모, 나 흩어진 파일, 연결되지 않은 스프레드 시트 탭으로 존재하지 않고 명확한 형태를 갖추게 됩니다.이것을 회사의 서류 보관함이라고 생각할 수 있지만, 여러 승인된 도구가 동시에 사용할 수 있는 보관함입니다.고객은 데이터버스에 한 번만 나타납니다.영업 담당자가 거래를 진행할 때 다이나믹스 365 세일즈에서 해당 고객이 나타날 수 있습니다.상담원이 지원 요청을 처리할 때 다이나믹스 365 커스터머 서비스에서도 동일한 고객 정보가 나타날 수 있습니다.파워 앱은 데이터를 새 앱에 먼저 복사할 필요 없이 현장 작업자나 계정 관리자를 위해 동일한 고객 정보를 사용할 수 있습니다.하나의 고객 행, 하나의 공유 참조 지점입니다.이것이 모든 팀이 갑자기 모든 것을 볼 수 있다는 의미는 아닙니다.

액세스에는 여전히 규칙이 필요하며 곧 이에 대해 다룰 것입니다.이는 승인된 앱들이 자체적인 경쟁 버전을 구축하는 대신 동일한 비즈니스 정보를 기반으로 작업할 수 있다는 의미입니다.이것이 다이나믹스 365와 데이터버스가 매우 자연스럽게 어우러지는 이유입니다.세일즈 나 커스터머 서비스와 같은 다이나믹스 365 앱은 데이터버스를 사용하여 작업하는 데이터를 저장하고 보호합니다.하지만 중요한 점이 있습니다.누군가 다이나믹스 365와 데이터버스를 통합하는 것에 대해 이야기할 때 종종 그들은 두 제품 사이에 연결기가 필요한 별개의 제품으로 상상하곤 합니다.많은 다이나믹스 365 앱의 경우 실제 상황은 그렇지 않습니다.데이터는 이미 데이터버스에 존재합니다.다이나믹스 365에서 고객 목록을 추출하여 다른 데이터베이스에 복사하고 양쪽이 최신 상태로 유지되기를 바랄 필요가 없습니다.다이나믹스 365가 이미 사용하는 동일한 비즈니스 정보를 사용하여 동일한 기반 위에서 구축할 수 있습니다.그것이 대화의 내용을 바꿉니다.이 두 고객 목록을 어떻게 동기화할까요? 라고 묻는 대신 어떤 사람과 앱이 고객 레코드로 작업해야 하며 각자 무엇을 할 수 있도록 허용해야 하는지를 물을 수 있습니다.이제 데이터버스가 회사가 소유한 모든 시스템을 대체하는 것은 아닙니다.기업은 여전히 재무 소프트웨어, 산업 도구, 창고 시스템, 웹사이트 또는 자체 데이터를 보관하는 이전 애플리케이션을 사용할 수 있습니다.데이터버스는 하룻밤 사이에 모든 외부 시스템을 없애는 마법의 접착제가 아닙니다.이것이 제공하는 것은 연결된 앱들이 공유해야 할 비즈니스 데이터를 위한 공통된 장소입니다.고객 세부 정보, 영업 작업, 지원 업무, 작업 및 후속 조치 등이 해당됩니다.이러한 레코드는 승인된 도구가 읽고 업데이트할 수 있는 하나의 소스와 함께 공존할 수 있습니다.

그러니 저와 함께 그 서류 보관함을 열어보시죠.데이터버스가 정보를 어떻게 정리하는지 일단 확인하면 전체 다이나믹스 365 연결을 이해하기가 훨씬 쉬워집니다.서류 보관함의 테이블, 행, 열, 관계까지 말이죠.이제 서류 보관함을 열어봅시다.데이터버스 내부의 정보는 테이블에 저장됩니다.분리된 서랍이 있는 실제 캐비닛과 같다고 생각하세요.한 서랍은 회사를, 다른 서랍은 사람을, 세 번째 서랍은 지원 요청을 보관합니다.모든 종이를 하나의 거대한 서랍에 던져넣고 나중에 누군가 분류하기를 바라는 방식이 아닙니다.각 서랍에는 맡은 역할이 있습니다.데이터버스에서 테이블은 한 가지 유형의 비즈니스 정보를 담습니다.계정 테이블은 보통 협력하는 기업 정보를 담습니다.연락처 테이블은 개인 정보를 담습니다.잠재 고객 테이블은 실제 고객이 되기 전이 잠재적 고객을 담습니다.사례 테이블은 지원 요청을, 활동 테이블은 통화, 이메일, 약속, 작업 등의 업무를 추적합니다.이것들이 표준 테이블입니다.대부분의 기업은 고객, 사람, 업무, 대화 내용을 관리해야 함으로 마이크로소프트는 이를 기본 제공합니다.표준 테이블이 이미 그 역할을 한다면 흔한 업무를 위해 굳이 새로운 테이블을 만들 필요는 없습니다.하지만 모든 회사에는 저마다의 고유한 업무도 있습니다.교육업체 라면 과정과 자격증을 관리해야 할 것입니다.부동산 업체는 건물, 유닛, 점검 정보를 관리해야 할 수 있습니다.제조업체는 장비 점검이나 서비스 방문을 추적할 수 있습니다.이런 경우 N은 회사 업무에 딱 맞는 사용자 지정 테이블을 만들 수 있습니다.사용자 지정 테이블은 캐비닛에 새 서랍을 추가하고 명확한 라벨을 붙이는 것이라 생각하세요.이제 각 테이블은 행을 포함합니다.행은 해당 서랍 안에 있는 하나의 항목입니다.예를 들어 연락처 테이블의 한 행은 고객사의 담당자인 마리아 고메즈를 나타낼 수 있습니다.

그녀의 행에는 시스템의 다른 모든 연락처와 구분되는 그녀만의 세부 정보가 담깁니다.열은 각 행에 대해 유지하려는 세부 정보를 설명합니다.마리아 위 연락처 행에는 이름, 성, 이메일 주소, 전화번호, 직함, 회사, 레코드 소유자, 상태를 위한 열이 있을 수 있습니다.열은 해당 위치에 들어갈 정보의 유형을 결정합니다.따라서 이메일 열에는 이메일 주소가, 상태 열에는 승인된 상태의 선택 항목이 들어갑니다.이것이 비즈니스 정보가 신뢰할 수 있는 형태를 갖추는 방식입니다.열이 없다면 누군가는 메모란에 전화번호를 입력하고, 누군가는 이름 필드에 넣거나 아예 입력하지 않을 수도 있습니다.체계적인 연락처 테이블이 있으면 모두가 같은 위치에서 동일한 세부 정보를 다루게 됩니다.이러한 구조는 앱이 데이터를 이해하는 데도 도움을 줍니다.양식은 올바른 상자를 표시하고, 보고서는 상태별로 연락처를 그룹화하며, 자동화는 소유자가 변경될 때 반응할 수 있습니다.정보는 단순히 저장되기만 하는 것이 아닙니다.연결된 도구들의 각 부분이 무엇을 의미하는지 알려주는 나벨이 붙어 있습니다.비즈니스 요구사항에 부합한다면 표준 테이블부터 시작하세요.기업을 대상으로 판매한다면 계정과 연락처는 이미 대부분이 이해하는 패턴을 제공합니다.고객 지원 업무를 처리한다면 사례가 좋은 시작점이 됩니다.기본 패턴에 맞지 않는 정보가 있는 경우 M1 사용자 지정 테이블을 추가하세요.이는 모두 고객을 의미하는 5개의 서로 다른 테이블을 만드는 흔한 문제를 방지합니다.한 팀은 클라이언트라고 부르고, 다른 팀은 고객 마스터, 세 번째 팀은 파트너 연락처라고 부릅니다.곧 사람들은 어떤 테이블을 사용해야 할지 알 수 없게 됩니다.명확한 표준 테이블과 신중하게 명명된 사용자 지정 테이블은 더 많은 사람이 이를 기반으로 작업할 때 캐비닛을 이해하기 쉽게 유지합니다.

다음 부분은 이러한 서랍들이 함께 작동하기 시작하는 곳입니다.연락처는 계정에 속합니다.마리아는 콘토소에서 일합니다.마리아의 행에 콘토소의 주소, 주요 전화번호, 회사 세부 정보를 다시 입력하는 대신, 데이터버스는 연락처 테이블과 계정 테이블 간의 관계를 만들 수 있습니다.마리아는 콘토소에 연결되며, 회사 정보는 회사에 머물러야 함으로 이 연결은 중요합니다.콘토소가 사무실 주소를 변경하면 누군가 계정 행을 한 번만 업데이트하면 됩니다.관련된 모든 연락처는 자체적인 구식 사본을 유지하지 않고도 동일한 회사를 계속 가리킬 수 있습니다.관계는 또한 지원 케이스를 그것을 제기한 고객과 연결합니다.관계는 영업기회를 해당 거래와 관련된 통화, 이메일, 회의 및 작업과 연결할 수 있습니다.영업사원이 기회를 열면 관련 없는 메모와 캘린더를 검색하는 대신 연결된 활동을 볼 수 있습니다.정보에 맥락이 생깁니다.단순히 케이스 번호만 보는 것이 아닙니다.어떤 고객에게 속한 것인지 확인할 수 있습니다.단순히 연락처 정보만 보는 것이 아닙니다.그 사람과 연결된 회사를 볼 수 있습니다.이러한 링크는 여러 곳에 동일한 사실을 반복적으로 입력하지 않고도 데이터를 유용하게 유지합니다.오래된 가이드를 읽거나 이전 동영상을 보기 전에 명칭에 관한 작은 참고사항이 있습니다.엔티티, 필드, 레코드라는 단어를 들을 수 있습니다.그것들은 이전의 데이터버스 용어입니다.마이크로소프트는 이제 엔티티 대신 테이블, 필드 대신 열, 레코드 대신 행이라는 용어를 사용합니다.의미는 변하지 않았습니다.엔티티를 만들라고 하는 오래된 가이드는 테이블을 만드는 것에 대해 이야기하는 것입니다.필드는 열이고 레코드는 행입니다.두 용어를 모두 알면 다른 제품을 찾았다고 생각하는 실수를 방지할 수 있습니다.따라서 테이블은 정보와 관계를 연결하여 체계화합니다.

하지만 잘 정리된 캐비닛도 통제가 필요합니다.누군가는 사람들이 무엇을 입력하고, 변경하고, 안전하게 액세스할 수 있는지 결정해야 합니다.데이터 뒤에는 규칙과 접수 데스크가 있습니다.공유 데이터는 적절한 사람들이 안전하게 작업할 수 있을 때만 효과적입니다.영업 담당자는 고객 세부 정보가 필요합니다.지원 담당자는 케이스 기록이 필요합니다.관리자는 더 넓은 시야가 필요합니다.그리고 외부 파트너는 프로세스의 작은 부분에만 액세스 권한이 필요할 수 있습니다.모두가 동일한 정보를 볼 필요는 없습니다.비공개 연락처 메모, 협상된 가격, 진행 중인 지원 케이스가 있는 고객 레코드를 생각해보십시오.모든 사용자에게 전체 액세스 권한을 부여하면 빠르게 위험이 초래될 수 있습니다.모든 사람을 너무 엄격하게 제한하여 업무를 수행할 수 없게 만드는 것은 또 다른 문제를 야기합니다.데이터버스는 이를 위한 제어 기능을 제공합니다.첫 번째 제어는 아이디에서 시작됩니다.회사 계정으로 로그인하면 마이크로소프트 엔트라 아이디가 사용자를 식별합니다.엔트라 아이디를 사무실 입구의 안내데스크라고 생각하세요.도착해서 배지를 보여주면 안내원이 누구인지 확인한 후에야 입장할 수 있습니다.데이터버스는 이 아이디를 사용하여 어떤 사용자가 데이터를 작업 중인지 파악합니다.단지 사람이 입장할 수 있는지 묻는 것에서 그치지 않습니다.입장 후에 사람이 무엇을 할 수 있는지도 확인합니다.바로 여기서 보안 역할이 필요합니다.보안 역할은 직무나 책임과 연결된 권한 집합입니다.영업 직원을 위한 역할, 고객 서비스 상담원을 위한 역할, 관리자를 위한 역할을 각각 생성할 수 있습니다.각 역할은 테이블에 대한 액세스를 제어할 수 있습니다.예를 들어, 영업 담당자는 계정, 연락처, 잠재고객 및 영업기회를 읽고 생성하고 업데이트할 수 있습니다.중요한 고객 정보를 삭제하는 권한은 없을 수 있습니다.

지원 상담원은 사례를 생성 및 업데이트할 수는 있지만, 영업기회를 변경할 수는 없습니다.권한은 행을 읽기, 생성, 변경 및 삭제하는 작업을 포괄할 수 있습니다.즉, 액세스 권한은 앱마다 어떤 버튼을 숨겨야 하는지 일일이 기억할 필요가 없습니다.권한이 데이터 자체에 포함되어 있기 때문입니다.따라서 데이터버스 데이터가 나타나는 모든 곳에 동일한 안전장치가 적용됩니다.그런 다음 액세스 권한을 훨씬 더 좁힐 수 있습니다.행수준 보안은 개인이 어떤 개별 행으로 작업할 수 있는지 결정합니다.영업 담당자는 자신이 담당하는 고객만 볼 수 있는 반면, 영업관리자는 팀원 모두가 소유한 고객행을 볼 수 있습니다.두 사람 모두 동일한 계정 테이블을 사용합니다.단지 동일한 부분의 데이터를 보지 않을 뿐입니다.이러한 설정은 사람들이 자신의 업무에 집중하도록 돕는 동시에 관리자에게 필요한 뷰를 제공합니다.또한 액세스할 이유가 없는 고객 정보를 누군가가 열어볼 가능성도 줄여줍니다.일부 정보는 더욱 엄격한 보호가 필요합니다.열 수준 보안은 테이블 내의 개별 열을 보호할 수 있습니다.사용자가 고객행을 열 수는 있지만 개인식별자, 급여수치, 은행정보 또는 개인재무 메모는 보지 못하게 할 수 있습니다.고객행은 여전히 필요한 작업을 수행할 수 있도록 유지됩니다.보호된 열은 제한된 상태로 유지됩니다.대기업의 경우 비즈니스 단위를 통해 조직 부서 간의 경계를 만들 수 있습니다.회사는 서로 다른 고객 그룹과 작업하는 지역, 부서 또는 자회사를 분리할 수 있습니다.비즈니스 단위는 이러한 경계 전반에서 액세스가 작동하는 방식을 구성하는 데 도움을 줍니다.이것이 모든 기업의 복잡한 보안 맵이 필요하다는 의미는 아닙니다.소규모 팀은 명확한 몇 가지 역할만 있으면 충분할 수 있습니다.규모가 큰 기업은 팀, 지역, 업무 분장에 따라 더 많은 계층이 필요할 수 있습니다.

핵심은 데이터버스가 실제 비즈니스 운영 방식에 맞춰 액세스 권한을 설정할 수 있다는 점입니다.액세스 제어는 데이터에 접근할 수 있는 사람을 보호하지만, 규칙은 데이터 자체의 품질을 보호합니다.비즈니스 규칙을 설정하면 새 연락처를 저장하기 전에 전화번호를 반드시 입력하도록 할 수 있습니다.사례가 종료될 때 사유를 입력해야 하는 것과 같은 조건을 확인할 수도 있습니다.사용자가 입력한 정보에 따라 사용자가 보는 화면을 변경할 수도 있습니다.동일한 규칙이 해당 테이블을 사용하는 모든 앱에 적용됩니다.어떤 앱은 불안전한 데이터를 허용하고, 다른 앱은 거부하는 상황을 방지해야 함으로 이는 중요합니다.규칙은 특정 화면이 아니라 비즈니스 정보 자체에 포함되어야 합니다.데이터버스는 비즈니스 프로세스를 일관되게 유지하기 위해 백그라운드에서 로직을 실행할 수도 있습니다.기억해야 할 세부사항은 간단합니다.데이터에는 저장소뿐만 아니라 규칙도 함께 제공됩니다.즉, 기반에는 정보, 작업을 허용받은 사람, 그리고 데이터를 유용하게 유지하는 규칙이 포함됩니다.다이나믹스 365가 동일한 기반 위에서 작동하면,자체 비즈니스 데이터에 액세스하기 위해 별도의 연결 통로가 필요하지 않습니다.다이나믹스 365 통합이 실제로 의미하는 바는 무엇일까요?대부분은 다이나믹스 365와 데이터버스 위 통합이라는 말을 들으면,두 개의 개별 시스템이 커넥터로 연결된 모습을 떠올립니다.한 시스템에 고객 데이터가 있고, 다른 시스템에 사본이 필요하면,누군가 동기화를 설정하고 실행될 때까지 기다리며 오류가 없기를 바랍니다.그런 방식은 많은 비즈니스 도구에서 타당합니다.하지만 다이나믹스 365 세일즈와 다이나믹스 365 커스터머 서비스 위 연결은 그보다 훨씬 더 긴밀합니다.이 앱들은 데이터버스를 공통 데이터 기반으로 사용합니다.서로를 이해하기 위해 고객행 데이터를 주고받는 별도의 데이터베이스가 아닙니다.

처음부터 동일한 비즈니스 정보를 바탕으로 작업합니다.그 점이 핵심입니다.영업 담당자로서 다이나믹스 365 세일즈에서 새로운 기업 정보를 생성한다고 가정해보겠습니다.주요 연락처를 추가하고 잠재적인 거래를 진행하기 시작합니다.해당 세부 정보는 즉시 앱이 사용하는 공유 데이터의 일부가 됩니다.나중에 해당 고객이 고객 지원팀에 연락합니다.지원 상담원은 동일한 기업 및 연락처 정보로 바로 작업할 수 있습니다.누구도 영업팀에서 목록을 내보내거나 별도의 지원 도구에 고객을 다시 등록할 필요가 없습니다.상담원은 단순히 지원 사례를 해당 고객에게 연결하고 상황을 이해하는 데 도움이 되는 기록을 확인합니다.영업팀은 거래를 확인합니다.지원팀은 사례를 확인하며 두 팀 모두 동일한 고객을 중심으로 업무를 처리합니다.그렇다고 해서 모든 화면이 동일하거나 모든 팀이 똑같은 프로세스를 따라야 한다는 의미는 아닙니다.영업팀에는 잠재 고객, 영업 기회, 통화, 미팅 정보가 필요합니다.고객 서비스에는 사례, 대기열, 서비스 이력이 필요합니다.각 다이나믹스 365 앱은 사용자 업무에 맞게 구축된 도구를 제공합니다.그 기반이 되는 비즈니스 정보는 필요한 곳 어디든 연결될 수 있습니다.이 공유 기반이 바로 사람들이 다이나믹스 365와 데이터버스 통합에 대해 이야기할 때 흔히 의미하는 바입니다.데이터를 A 지점에서 B 지점으로 옮기는 것만이 전부가 아닙니다.앱들이 동일한 행, 관계, 규칙, 액세스 제어를 활용하는 것이 핵심입니다.처음부터 사무실에서 간단한 영업 여정을 진행해보겠습니다.웹사이트나 행사로부터 잠재 고객이 유입됩니다.영업사원은 해당 잠재 고객과 소통하며 그 사람에 대해 더 알아보고,잠재 고객을 고객관계이자 기회로 전환합니다.통화, 이메일, 약속, 작업 등을 모두 해당 업무와 연결할 수 있습니다.따라서 팀은 파편화된 도구들을 일일이 뒤져서 전체 상황을 파악할 필요가 없습니다.

나중에 고객이 도움이 필요하면 지원 사례를 바로 그 고객에게 다시 연결할 수 있습니다.지원 상담원은 단지 이름과 이메일 주소만 확인하는 것이 아닙니다.이미 확인된 고객관계라는 맥락 안에서 업무를 처리할 수 있습니다.한편 영업팀은 해당 고객에게 미해결된 서비스 문제가 있음을 확인하여이전 문제 상황을 모른 채 갱신 상담을 진행하는 실수를 피할 수 있습니다.하나의 고객관계가 다양한 유형의 업무를 지원할 수 있습니다.이는 단순히 두 시스템에 일치하는 고객 이름을 유지하는 것보다 훨씬 유용합니다.공통 데이터 모델, 커먼 데이터 모델, 줄여서 CDM이라는 용어도 들어보셨을 것입니다.이름 때문에 너무 어렵게 생각하실 필요는 없습니다.단순히 마이크로소프트 가계점, 연락처, 활동, 사례와 같이 많은 기업이 추적하는 항목에 대해공통 비즈니스 테이블 패턴을 제공한다는 뜻입니다.이러한 패턴은 다이나믹스 365 및 데이터버스 기반 앱에 공통된 시작 언어를 제공합니다.계정은 회사를 의미합니다.연락처는 사람을 의미합니다.활동은 비즈니스 관계와 관련된 업무를 추적합니다.기업 상황에 맞게 설정을 조정하고 필요한 테이블을 추가할 수 있지만매번 처음부터 다시 시작할 필요는 없습니다.한 앱이 계정 테이블을 이해하고 다른 앱이 동일한 테이블을 사용하면두 앱 모두 동일한 비즈니스 정보를 참조하게 됩니다.이는 여러분이 구축할 수 있는 결과물도 변화시킵니다.현장팀이 고객을 조회하고 방문을 확인하며약속 후 메모를 추가할 간단한 앱이 필요하다고 가정해봅시다.다이나믹스 365가 이미 사용 중인동일한 데이터버스 테이블과 연동되는 파워앱을 만들 수 있습니다.해당 앱만을 위해 고객 데이터를 새로운 목록으로 내보낼 필요가 없습니다.현장 직원은 앱을 열고 고객을 찾아 방문 정보를 업데이트하기만 하면 됩니다.데이터는 앞서 다룬 보안 규칙에 따라영업이나 고객 서비스 팀이 이미 사용 중인 고객 관계와계속 연결된 상태를 유지합니다.

더 구조화된 업무를 위해서는 모델 기반 앱을 구축할 수 있습니다.모델 기반 앱은 데이터 모델에서 시작합니다.데이터버스 테이블을 선택하고 관계를 정의하며양식과 보기를 설정하고 보안 역할을 적용합니다.그러면 파워앱스가 그 구조를 사용하여 작동하는 비즈니스 앱 환경을 만듭니다.팀이 실제로 사용하는 도구와 재료에 맞춰 작업대를 정리하는 것과 같다고 생각하면 됩니다.테이블은 업무를 설명합니다.관계는 조각들을 연결합니다.양식은 사람들이 세부 정보를 입력하고 검토할 공간을 제공합니다.보기는 주의가 필요한 행을 찾도록 도와줍니다.보안은 각 사람이 무엇을 열거나 변경할 수 있는지 결정합니다.모델 기반 앱과 다이나믹스 365는모두 데이터버스를 기반으로 함으로 함께 사용할 수 있습니다.예를 들어 다이나믹스 365세일즈가 전체 영업 프로세스를 처리하는 동안더 작은 모델 기반 앱은 계약 관리자가 고객 계약을 추적할 수 있는 집중된 공간을 제공할 수 있습니다.두 가지 모두 두 번째 고객 데이터베이스를 만들지 않고도 관련 고객 데이터를 처리할 수 있습니다.물론 이러한 액세스 권한 관리는 신중해야 합니다.앱이 데이터버스 테이블과 연동된다고 해서모든 사용자가 모든 행을 수정하거나 모든 열을 볼 수 있어야 하는 것은 아닙니다.역할 기반 행 액세스와 비즈니스 규칙이 여전히 무엇이 가능한지 제어합니다.현장 앱은 회사에 나머지 데이터를 노출하지 않고도 사용자에게 필요한 정확한 고객 세부 정보와 작업만 제공할 수 있습니다.따라서 데이터버스와 다이나믹스 365의 통합은 이제 두 개의 떨어진 방을 연결하는 케이블과 같습니다.다이나믹스 365 앱, 사용자 지정 앱 및 비즈니스 프로세스 모두 동일한 공유 기반 위에서 작동할 수 있습니다.그 사실을 알게 되면 다음 질문이 명확해집니다.마이크로소프트 연결 플랫폼 전반에서 동일한 고객 업데이트를 또 어디에 활용할 수 있을까요?

연결된 플랫폼은 실제 업무에서 어떻게 작동할까요?공유된 고객 업데이트는 주변 도구들이 반응할 때 비로소 유용해집니다.파워 오토메이트는 데이터버스 행위 변경 사항을 감시하고 변경이 발생할 때 작업을 시작하여 후속 업무를 처리합니다.예를 들어 새로운 잠재 고객이 다이나믹스 365세일즈에 입력됩니다.흐름, 플로우, 을 통해 담당 영업사원에게 알림을 보내거나 팀즈의 메시지를 게시하거나 후속 작업을 생성할 수 있습니다.이제 아무도 하루 종일 공유받은 편지함을 지켜볼 필요가 없습니다.잠재 고객 정보가 변경되면 다음 단계가 자동으로 시작됩니다.파워 오토메이트는 해당 작업을 수행하기 위해 잠재 고객 데이터의 별도 복사본이 필요하지 않습니다.파워 오토메이트는 영업 앱이 사용하는 것과 동일한 고객 및 소유권 세부 정보를 사용하여 데이터버스 위행에 반응할 수 있으며이를 통해 누군가 파일을 내보내고 수동으로 이메일을 주고받는 대신 비즈니스 프로세스에 밀접하게 자동화를 유지할 수 있습니다.그런 다음 파워 BI 가 있습니다.영업 관리자는 현재 파이프라인을 확인하고 싶을 것입니다.고객 서비스 관리자는 이번 주에 접수된 문외 건수, 미결 상태인 건수, 혹은 가장 자주 문외하는 고객이 누구인지 확인해야 할 수 있습니다.파워 BI는 데이터버스 비즈니스 데이터를 보고할 수 있으므로팀은 매주 금요일 오후마다 스프레드 시트를 새로 내보낼 필요 없이 진행 중인 업무를 파악할 수 있습니다.이 보고서는 사람들이 이미 사용 중인 비즈니스 데이터를 기반으로 합니다.즉 영업 기회가 진행됨에 따라 파이프라인 차트도 자동으로 변경될 수 있습니다.상담원이 사례를 업데이트하면 사례 데시보드에서 현재 업무 부하를 확인할 수 있습니다.핵심은 데시보드가 사람이 일일이 세부사항을 확인하는 과정을 대신한다는 점입니다.데시보드를 통해 사용자는 무엇에 집중해야 할지 결정하기 전에 업무 현황을 더 명확하게 파악할 수 있습니다.

파워 앱스는 동일한 프로세스에 또 다른 접근 경로를 추가합니다.현장 작업자가 고객의 현장에 도착하는 상황을 상상해보세요.그들에게 전체 다이나믹스 365세일즈 환경이 필요한 것은 아닙니다.그저 고객을 찾고 방문 세부 정보를 검토하고 내용을 확인한 뒤 메모나 사진을 추가하기만 하면 됩니다.집중적인 파워 앱은 그들에게 딱 필요한 간소화된 환경을 제공할 수 있습니다.계정팀에는 고객 계약을 검토하기 위한 앱이 필요할 수 있습니다.관리자에게는 요청을 승인하기 위한 간단한 앱이 필요할 수 있습니다.각 앱은 한 가지 작업에 집중하면서도 백엔드에서는 동일하게 제어되는 데이터버스 정보를 활용합니다.사용자는 자신의 업무에 맞는 도구만 보게 됩니다.비즈니스는 연결된 정보를 계속 유지합니다.때로는 해당 정보가 데이터버스 외부에서 시작되기도 합니다.기업이 온라인 소스에서 가져온 리스트를 비즈니스 데이터의 일부로 통합해야 할 수도 있습니다.파워 커리는 지원되는 온라인 소스에서 데이터를 가져오고 가져오는 동안 정리하며 올바른 데이터버스 테이블로 로드할 수 있습니다.이는 외부 소스에 다이나믹스 및 파워 플랫폼 도구에서 필요한 정보가 포함되어 있을 때 유용합니다.여전히 무엇이 데이터버스에 속하며 기존 테이블과 어떻게 연결되어야 하는지 결정해야 합니다.그런 고민 없이 데이터를 가져오면 혼란만 새로운 장소로 옮기는 꼴이 됩니다.이 조각들을 하나의 일상적인 흐름으로 모아보겠습니다.새로운 리드가 다이나믹스 365에 들어옵니다.할당 규칙이 지역이나 제품 등을 기준으로 해당 리드를 담당할 사람을 결정합니다.담당자는 파워 오토메이트 흐름을 통해 팀즈 메시지를 받아 대기 중인 업무가 있음을 알게 됩니다.영업사원이 리드를 업데이트하고 영업 프로세스를 진행함에 따라 파워 비아이 대시보드가 변경되어 팀과 현재 파이프라인 현황을 보여줍니다.

한 번의 업데이트가 여러 곳에서 유용한 작업을 시작하게 합니다.파워 오토메이트는 업무를 한 단계에서 다음 단계로 이동시킵니다.파워 비아이는 사람들이 업무 내용을 파악하도록 돕습니다.파워 앱스는 특정 팀의 업무에 참여할 수 있는 최적화된 방식을 제공합니다.

그 차이가 중요합니다.자동화는 파일링 시스템이 아니면 대시보드는 고객 데이터베이스가 아닙니다.각 도구에는 고유한 역할이 있지만 모두 동일한 원천 데이터로 작업할 수 있습니다.이 점을 알면 모든 스프레드 시트나 간단한 목록이 전체 비즈니스 프로세스를 실행해야 하는 것처럼 다루지 않고 올바른 도구를 선택하는 데 도움이 됩니다.데이터버스가 적합한 경우와 대체할 수 없는 경우를 알아봅니다.핵심은 이렇습니다.여러 사람과 앱이 연결된 비즈니스 데이터로 작업해야 할 때 데이터버스를 선택하세요.명확한 액세스 규칙과 반복 가능한 프로세스가 필요합니다.데이터버스가 이를 처리하지만 다른 모든 것을 대체하지는 않습니다.개인 분석 및 빠른 목록 작성을 위해서는 여전히 엑셀이 최선의 선택입니다.셰어포인트 목록은 간단한 팀 추적에 효과적입니다.심층적 인재어가 필요한 개발자 라면 SQL이 여전히 강력한 선택지입니다.그렇다면 데이터버스는 언제 진정으로 적합할까요?데이터를 복사본 생성 없이 다이나믹스 365 앱 자동화 보고서 전반에 걸쳐 연결해야 할 때입니다.바로 그 점이 데이터버스 위 강점입니다.결론적으로 하나의 기반의 다양한 비즈니스 도구를 활용하는 것입니다.핵심은 다음과 같습니다.다이나믹스 365와 데이터버스는 모든 데이터, 규칙, 보안, 앱, 자동화 및 보고서가 하나의 공통 기반을 공유할 때 가장 잘 작동합니다.다이나믹스 365, 파워 플랫폼 및 마이크로소프트 365에 대한 더 쉬운 설명을 보려면M365 FM에서 마이크로소프트 지식나겟을 구독하세요.그런 다음 모델 기반 앱에 대한 에피소드를 시청하여데이터버스 테이블이 어떻게 작동하는 비즈니스 앱으로 변환되는지 확인해보세요.감사합니다.