마이크로소프트 지식나겟에 오신 것을 환영합니다.저는 미르코 피터스입니다.오늘의 주제는 많은 분이 혼란스러워하는 부분입니다.데이터버스란 정확히 무엇일까요?데이터베이스일까요? 앱일까요?아니면 IT 전문가만 알아야 할 숨겨진 다이나믹스 365 서비스일까요?가장 간단한 정의를 말씀드리겠습니다.데이터버스는 많은 다이나믹스 365 환경을 뒷받침하는 공유 데이터 기반입니다.다이나믹스 365를 사무용 빌딩이라고 생각해보세요.영업, 고객 서비스 및 기타 앱은 사람들이 일하는 사무실이며데이터버스는 그 벽 뒤에 있는 관리 시스템 이자 규칙입니다.이번 에피소드가 끝날 때 쯤이면 다이나믹스 데이터가 어디에 저장되는지그리고 고객 정보 변경 사항이 어떻게 영업 업무, 자동화, 보고서에 반영되는지 알게 되실 겁니다.제품 이름을 언급하기 전에 이 기술이 해결하는 비즈니스의 복잡함부터 살펴보겠습니다.하나의 공유 공간, 각각의 개별 사본 대신 말이죠.영업팀, 지원팀, 재무팀이 있는 회사를 상상해보세요.영업팀은 고객 세부 정보를 스프레드 시트에 보관합니다.지원팀은 별도의 사례관리 도구에서 작업합니다.재무팀은 자체 시스템의 고객 이름을 관리합니다.누군가는 이메일 대화 내용을 공유 메일함에 저장하고또 다른 누군가는 아무도 찾을 수 없는 폴더에 메모를 보관합니다.이제 같은 고객 정보가 다섯 곳에 존재하게 됩니다.각 팀은 눈앞의 업무만 처리하기 때문에 처음에는 이런 설정이 당연하게 느껴집니다.하지만 문제는 고객이 전화번호, 주소, 회사명 또는 담당자를 변경하는 즉시 발생합니다.영업팀이 스프레드 시트를 업데이트해도 지원팀은 이를 알 수 없고재무팀은 여전히 예전 주소로 문서를 보냅니다.그러면 누군가가 목록을 내보내 수동으로 정리한 뒤 이메일로 공유하고갑자기 3명 모두 각자의 사본이 정확하다고 믿게 됩니다.어떤 목록을 믿어야 할까요?

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

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

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

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

마리아는 컨토소와 연결되며회사 정보가 회사 데이터 내에 유지되기 때문에 이 연결은 중요합니다.컨토소가 사무실 주소를 변경하면계정행을 한 번만 업데이트하면 되고관련 연락처들은 각자 오래된 정보를 보관할 필요 없이동일한 회사를 참조하게 됩니다.관계는 또한 지원 사례를 이를 제기한 고객과 연결합니다.관계는 판매 기회를 해당 거래와 관련된 통화, 이메일, 회의, 작업과 연결할 수 있습니다.영업사원이 기회를 열면 관련 없는 메모나 캘린더를 뒤질 필요 없이해당 기회에 연결된 활동을 볼 수 있습니다.정보의 맥락이 생기는 것입니다.단순히 사례번호만 보는 것이 아니라어느 고객에게 속한 사례인지 확인할 수 있습니다.연락처만 보는 것이 아니라 그 사람과 연결된 회사도 볼 수 있습니다.이러한 링크 덕분에 동일한 사실을 여러 곳에 반복해서입력하지 않고도 데이터를 유용하게 활용할 수 있습니다.오래된 가이드나 영상을 보기 전에 용어에 관한 작은 참고사항이 있습니다.엔터티, 엔터티, 필드, 필드, 레코드, 레코드 라는 용어를 들을 수도 있습니다.이것들은 예전 데이터버스 용어입니다.현재 마이크로소프트는 엔터티 대신 테이블, 필드 대신 열,레코드 대신 행이라는 용어를 사용합니다.의미는 변하지 않았습니다.엔터티를 만들라는 예전 가이드는 테이블을 만들라는 의미이며필드는 열, 레코드는 행을 뜻합니다.두 용어를 모두 알아두면 다른 제품이라고 오해하는 일을 방지할 수 있습니다.결론적으로 테이블은 정보를 정리하고 관계는 정보를 연결합니다.하지만 잘 정리된 캐비닛에도 제어 장치는 필요합니다.누군가는 사람들이 무엇을 입력하고 변경하며무엇에 안전하게 접근할 수 있는지 결정해야 합니다.규칙과 안내데스크가 필요한 이유입니다.데이터버스 내부의 데이터는 권한이 있는 사용자가안전하게 작업할 때만 제대로 작동합니다.영업 담당자는 고객 세부 정보가, 지원 상담원은 사례 내역이,관리자는 더 넓은 시야가 필요하며외부 파트너는 프로세스의 일부에만 접근할 권한이 필요할 수 있습니다.

이들이 모두 같은 정보를 볼 수는 없습니다.비공개 연락처 메모, 협상된 가격,진행 중인 지원 사례가 포함된 고객 레코드를 생각해 보십시오.모든 사용자에게 전체 액세스 권한을 주면 금세 위험이 발생합니다.너무 영격하게 제한하여 업무를 수행할 수 없게 만드는 것도 또 다른 문제입니다.데이터버스는 이를 위한 제어 기능을 제공합니다.그 첫 번째 제어는 아이디에서 시작됩니다.회사 계정으로 로그인하면 마이크로소프트 엔트라 아이디가 사용자를 식별합니다.엔트라 아이디를 사무실 입구의 안내데스크라고 생각해 보세요.도착해서 배지를 보여주면 접수원이 입실 전 신원을 확인하는 것과 같습니다.데이터버스는 그 아이디를 사용하여 어떤 사용자가 데이터를 다루는지 파악합니다.이 사람이 들어올 수 있는가? 라는 질문에서 멈추지 않습니다.들어온 후이 사람이 무엇을 할 수 있는가?또 함께 질문합니다.여기서 보안 역할이 필요합니다.보안 역할은 직무나 책임에 연결된 권한 집합입니다.영업 직원용 역할, 고객 서비스 상담원용 역할, 관리자용 역할을 각각 만들 수 있습니다.각 역할은 테이블에 대한 액세스를 제어할 수 있습니다.예를 들어 영업 담당자는 계정, 연락처, 잠재 고객, 영업 기회를 읽고 만들고 업데이트할 수 있습니다.중요한 고객 정보를 삭제할 권한은 없을 수 있습니다.지원 상담원은 사례를 생성하고 업데이트할 수는 있지만 영업 기회를 변경할 수는 없습니다.이 권한은 행을 읽고, 만들고, 변경하고, 삭제하는 작업까지 포함합니다.즉, 액세스 권한은 앱마다 어떤 버튼을 숨길지 기억하는 것에 의존하지 않습니다.권한은 데이터 자체에 귀속됩니다.따라서 데이터버스 데이터가 어디에 나타나든 동일한 가드레일이 적용됩니다.그런 다음 액세스 범위를 더 좁힐 수 있습니다.행 수준 보완은 어떤 개별 행을 작업할 수 있는지 결정합니다.영업 담당자는 본인 소유의 고객만 볼 수 있지만, 영업 관리자는 팀원 소유의 모든 고객 행을 볼 수 있습니다.

두 사람 모두 동일한 계정 테이블을 사용합니다.단지 전체 데이터 중 서로 다른 부분만 보는 것입니다.이러한 설정은 각자가 업무에 집중하도록 독고 관리자에게 필요한 뷰를 제공합니다.또한 액세스할 이유가 없는 고객 정보를 누군가가 열어볼 가능성도 줄여줍니다.더 엄격한 보호가 필요한 정보도 있습니다.열 수준 보완은 테이블 내의 개별 열을 보호할 수 있습니다.사용자가 고객 행을 열 수는 있지만 개인식 별자, 급여, 은행 정보 또는 개인 재무 메모는 보지 못하게 할 수 있습니다.고객 행은 여전히 업무 수행을 위해 열람 가능합니다.보호된 열만 제한된 상태로 유지됩니다.대기업의 경우 비즈니스 단위를 사용하여 조직 간의 경계를 설정할 수 있습니다.기업은 서로 다른 고객 그룹을 담당하는 지역, 부서 또는 자회사를 분리할 수 있습니다.비즈니스 단위는 이러한 경계를 넘어 액세스가 작동하는 방식을 결정하는 데 도움을 줍니다.그렇다고 해서 모든 기업의 복잡한 보안 맵이 필요한 것은 아닙니다.소규모 팀은 몇 가지 명확한 역할만 필요할 수 있습니다.규모가 큰 기업은 팀, 지역, 책임이 다르기 때문에 더 많은 계층이 필요할 수 있습니다.핵심은 데이터버스가 실제 비즈니스 운영 방식에 맞춰 액세스를 조정할 수 있다는 점입니다.액세스 제어는 데이터 접근 권한을 보호하지만, 규칙은 데이터 자체의 품질을 보호합니다.비즈니스 규칙을 설정하면 새 연락처를 저장하기 전에 전화번호 입력을 필수로 만들 수 있습니다.사례가 종료될 때 사유를 요구하는 것과 같은 조건을 검사할 수도 있습니다.또한 사용자가 입력한 정보에 따라 사용자에게 표시되는 내용을 변경할 수도 있습니다.동일한 규칙이 해당 테이블을 사용하는 앱 전체에 적용됩니다.이는 한 앱은 불안전한 데이터를 허용하고, 다른 앱은 거부하는 상황을 방지해야 하기 때문에 중요합니다.규칙은 특정 화면이 아니라 비즈니스 정보와 함께 존재해야 합니다.

데이터버스는 백그라운드에서 로직을 실행하여 비즈니스 프로세스를 일관되게 유지할 수도 있습니다.기억해야 할 세부사항은 간단합니다.데이터는 단순한 저장을 넘어 규칙과 함께 제공됩니다.따라서 기반에는 정보, 정보를 다룰 수 있는 사람, 그리고 사용 가능한 상태로 유지하는 규칙이 포함됩니다.다이나믹스 365가 동일한 기반 위에서 작동하면, 자체 비즈니스 데이터에 액세스하기 위해 기존의 브릿지가 필요하지 않습니다.다이나믹스 365 통합 위 진정한 의미는 무엇일까요?대부분은 데이터버스와 다이나믹스 365 통합이라는 말을 들으면 커넥터로 연결된 두 개의 별도 시스템을 떠올립니다.한 시스템이 고객 데이터를 보유하고 다른 시스템이 복사본을 필요로 하면, 누군가가 동기화를 설정하고 실행을 기다리며 오류가 없기를 바랍니다.이러한 방식은 많은 비즈니스 도구에 적합합니다.하지만 여기 다이나믹스 365 세일즈와 다이나믹스 365 커스터머 서비스의 경우에는 연결 방식이 훨씬 더 긴밀합니다.이 앱들은 데이터버스를 공유 데이터 기반으로 사용합니다.서로를 이해하기 위해 고객행을 주고받는 두 개의 별도 데이터베이스가 아닙니다.처음부터 동일한 비즈니스 정보를 바탕으로 작업합니다.구체적인 예를 들어보겠습니다.영업 담당자라고 가정하고 다이나믹스 365 세일즈에서 새 회사를 만든다고 해보죠.주요 연락처를 추가하고 잠재적인 거래를 진행하기 시작합니다.해당 세부 정보는 즉시 앱이 사용하는 공유 데이터의 일부가 됩니다.나중에 해당 고객이 지원팀에 연락합니다.지원 상담원은 동일한 회사 및 연락처 정보를 그대로 사용하여 작업할 수 있습니다.영업팀에서 목록을 내보내거나 별도의 지원 도구에서 고객을 다시 생성할 필요가 없습니다.상담원은 지원 사례를 해당 고객에게 연결하기만 하면 상황을 이해하는 데 필요한 이력을 즉시 확인할 수 있습니다.

영업 부서는 거래를 보고 지원 부서는 사례를 보며 두 팀 모두 동일한 고객을 중심으로 업무를 수행합니다.그렇다고 해서 모든 화면이 동일하거나 모든 팀이 같은 프로세스를 따르는 것은 아닙니다.영업에는 리드, 기회, 통화, 미팅이 필요합니다.고객 서비스에는 사례, 대기열, 서비스 이력이 필요합니다.각 다이나믹스 365 앱은 사용자에게 해당 직무에 최적화된 도구를 제공합니다.기저의 비즈니스 정보는 필요한 곳 어디든 연결될 수 있으며,이러한 공유 기반 이야말로 사람들이 다이나믹스 365와 데이터버스 통합을 말할 때 흔히 의미하는 바입니다.이는 단순히 데이터를 A 지점에서 B 지점으로 옮기는 것이 아닙니다.모든 앱이 처음부터 동일한 행, 관계, 규칙 및 액세스 제어를 기반으로 작동하는 것입니다.간단한 영업 과정을 살펴보겠습니다.웹사이트나 이벤트를 통해 리드가 유입됩니다.영업 담당자는 해당 리드를 관리하고 고객에 대해 더 많이 파악하며 리드를 고객관계 및 기회로 전환합니다.통화, 이메일, 약속, 작업 모드를 해당 업무에 연결할 수 있습니다.따라서 팀이 전체 맥락을 파악하기 위해 별도의 도구를 찾아다닐 필요가 없습니다.나중에 고객이 도움이 필요하면 지원 사례를 동일한 고객에게 다시 연결할 수 있습니다.지원 상담원은 단순히 이름과 이메일 주소만 보는 것이 아닙니다.이미 식별된 고객관계의 맥락 속에서 업무를 수행할 수 있습니다.그동안 영업팀은 고객에게 미해결 서비스 문제가 있음을 확인하여 문제를 모른 채 갱신 상담을 진행하는 상황을 피할 수 있습니다.하나의 고객관계는 단순히 두 시스템에서 고객 이름을 일치시키는 것보다 훨씬 유용한 다양한 업무를 지원할 수 있습니다.공통 데이터 모델, 커먼 데이터 모델이라는 용어를 들어보셨을 수도 있으며 줄여서 cdm이라고도 합니다.이름 때문에 너무 복잡하게 생각할 필요는 없습니다.

이는 마이크로소프트 가 계정, 연락처, 활동, 사례와 같이 많은 기업이 추적하는 항목에 대해 공통 비즈니스 테이블 패턴을 제공한다는 의미일 뿐입니다.이러한 패턴은 다이나믹스 365와 데이터버스 기반 앱들이 공통의 시작 언어를 갖게 해줍니다.계정은 회사를 의미합니다.연락처는 사람을 의미합니다.활동은 비즈니스 관계와 관련된 업무를 추적합니다.회사에 맞춰 설정을 조정하고 필요할 때 자체 테이블을 추가할 수 있지만 매번 빈시트에서 시작할 필요는 없습니다.한 앱이 계정 테이블을 이해하고 다른 앱이 동일한 테이블을 사용하면 두 앱 모두 동일한 유형의 비즈니스 정보를 참조하게 됩니다.이는 또한 구축할 수 있는 기능의 범위를 변화시킵니다.현장팀이 고객을 조회하고 방문을 확인하며 약속 후 메모를 추가할 수 있는 간단한 앱이 필요하다고 가정해보십시오.다이나믹스 365에서 이미 사용 중인 동일한 데이터버스 테이블과 연동되는 파워 앱을 구축할 수 있습니다.해당 앱을 위해 고객 데이터를 새로운 목록으로 내보낼 필요가 없습니다.현장 작업자가 앱을 열어 고객을 찾고 방문 정보를 업데이트합니다.데이터는 앞서 살펴본 보안 규칙에 따라 영업이나 고객 서비스 부서가 이미 사용 중인 고객 관계와 연결된 상태로 유지됩니다.더 체계적인 비즈니스 작업을 위해서는 모델 기반 앱을 구축할 수 있습니다.모델 기반 앱은 데이터 모델에서 시작합니다.데이터버스 테이블을 선택하고 관계를 정의하며 양식과 보기를 설정하고 보안 역할을 적용합니다.그러면 파워 앱스가 해당 구조를 사용하여 작동하는 비즈니스 앱 환경을 만듭니다.팀이 실제로 사용하는 도구와 자료를 중심으로 작업대를 정리하는 것과 같습니다.테이블은 작업을 설명하고 관계는 항목들을 연결합니다.양식을 통해 사용자는 세부 정보를 입력하고 검토할 수 있습니다.보기는 주의가 필요한 행을 찾는 데 도움을 줍니다.

보안은 각 사람이 무엇을 열거나 변경할 수 있는지 결정합니다.모델 기반 앱은 다이나믹스 365와 함께 사용할 수 있는데 둘 다 데이터버스를 기반으로 하기 때문입니다.예를 들어 다이나믹스 365세일즈가 전체 영업 프로세스를 처리하는 동안더 작은 모델 기반 앱은 계약 관리자가 고객 계약을 추적할 수 있는 집중된 공간을 제공할 수 있습니다.두 앱 모두 두 번째 고객 데이터베이스를 만들지 않고도 관련 고객 데이터를 작업할 수 있습니다.물론 이러한 액세스에는 여전히 주의가 필요합니다.앱이 데이터버스 테이블과 연동된다고 해서 모든 사용자가 모든 행을 편집하거나 모든 열을 볼 수 있어야 하는 것은 아닙니다.역할, 행 액세스 및 비즈니스 규칙이 여전히 작업 내용을 제어합니다.현장 앱은 회사의 나머지 데이터, 나타사 데이터를 노출하지 않고도사용자에게 필요한 고객 세부 정보와 작업만 정확히 제공할 수 있습니다.따라서 다이나믹스 365와 데이터버스 위 통합은 이제 두 개의 떨어진 방을 연결하는 케이블과 같습니다.다이나믹스 365 앱, 사용자 지정 앱, 비즈니스 프로세스 모두 동일한 공유 기반 위에서 작동할 수 있습니다.일단 이를 이해하면 다음 질문이 분명해집니다.마이크로소프트 또는 타사에 연결된 플랫폼 전반에서 동일한 고객 업데이트를 어디에 활용할 수 있을까요?연결된 플랫폼이 실제 업무에서 작동하는 방식입니다.공유된 고객 업데이트는 주변 도구가 그에 대응할 수 있을 때 유용해집니다.파워 오토메이트는 데이터버스 행위 변경 사항을 감시하고 변경이 발생할 때 작업을 시작하여 후속 업무를 처리합니다.예를 들어 새로운 리드가 다이나믹스 365세일즈에 입력됩니다.흐름, 플로우, 물통에 담당 영업사원에게 알림을 보내거나 팀즈의 메시지를 게시하거나 후속 작업을 생성할 수 있습니다.누구도 하루 종일 공유받은 편지함을 지켜볼 필요가 없습니다.

리드가 변경되면 다음 단계가 자동으로 시작됩니다.파워 오토메이트는 작업을 수행하기 위해 리드의 별도 복사본이 필요하지 않습니다.판매 앱이 사용하는 것과 동일한 고객 및 소유권 세부 정보를 사용하여 데이터버스 위행에 반응할 수 있습니다.이렇게 하면 누군가가 파일을 내보내고 수동으로 이메일을 주고받는 대신 비즈니스 프로세스에 밀접한 자동화를 유지할 수 있습니다.다음은 파워 비아이입니다.영업관리자는 현재 파이프라인을 확인하고 싶어 할 수 있습니다.고객 서비스 관리자는 이번 주에 접수된 사례수, 미해결 사례 또는 가장 자주 문외하는 고객이 누구인지 확인해야 할 수 있습니다.파워 비아이는 데이터버스 비즈니스 데이터를 보고할 수 있으므로 팀은 매주 금요일 오후에 스프레드 시트를 새로 내보낼 필요 없이 진행 중인 업무를 파악할 수 있습니다.보고서는 이미 사용 중인 비즈니스 데이터를 바탕으로 작성됩니다.즉 영업기회가 진행됨에 따라 파이프라인 차트도 실시간으로 변경될 수 있습니다.상담원이 사례를 업데이트하면 사례 데시보드에 현재 업무량이 표시됩니다.핵심은 데시보드가 사람이 일일이 세부사항을 확인하는 과정을 대신한다는 것입니다.데시보드를 통해 무엇을 처리해야 할지 결정하기 전에 업무를 더 명확하게 파악할 수 있습니다.파워 앱스는 동일한 프로세스에 또 다른 접근 경로를 추가합니다.현장 직원이 고객 사이트에 도착하는 상황을 상상해보세요.그들에게 다이나믹스 365 영업환경 전체가 필요한 것은 아닙니다.고객을 찾고 방문 세부 정보를 검토하고 내용을 확인한 뒤 메모나 사진을 추가하는 것만으로도 충분할 수 있습니다.집중적 인파워 앱을 사용하면 필요한 기능만 제공하는 간소화된 환경을 경험할 수 있습니다.계정팀은 고객 계약을 검토하기 위한 앱이 필요할 수 있습니다.관리자는 요청을 승인하기 위한 간단한 앱이 필요할 수 있습니다.

각 앱은 하나의 작업에 집중하면서도 백엔드에서는 동일하게 제어되는 데이터버스 정보를 사용합니다.사용자는 자신의 업무에 맞는 도구를 보게 됩니다.기업은 연결된 정보를 유지하게 됩니다.때로는 해당 정보가 데이터버스 외부에서 시작되기도 합니다.기업이 비즈니스 데이터에 일부러 포함해야 할 온라인 소스의 목록을 가지고 있을 수 있습니다.파워 커리는 지원되는 온라인 소스에서 데이터를 가져와 가져오는 과정에서 정리하고 적절한 데이터버스 테이블에 로드할 수 있습니다.이는 외부 소스의 다이나믹스 및 파워 플랫폼 도구에서 사용해야 할 정보가 있을 때 유용합니다.어떤 데이터를 데이터버스에 포함할지 기존 테이블과 어떻게 연결할지는 여전히 결정해야 합니다.이러한 고민 없이 데이터를 가져오면 혼란만 새로운 장소로 옮겨갈 뿐입니다.오톰 이 조각들을 하나의 일상적인 흐름으로 결합하도록 해봅시다.새로운 잠재고객이 다이나믹스 365에 입력되면 할당규칙이 지역인화제품 등에 따라 누가의 잠재고객을 담당해야 할지 확인합니다.담당자는 파워 오토메이트 흐름을 통해 팀즈 메시지를 받음으로 대기 중인 업무가 있음을 알게 됩니다.영업 담당자가 잠재고객 정보를 업데이트하고 영업 프로세스를 진행함에 따라 파워 비아이 대시보드가 변경되어 팀에게 현재 파이프라인 상황을 보여줍니다.하나의 업데이트가 여러 곳에서 유용한 작업을 시작합니다.파워 오토메이트는 업무를 한 단계에서 다음 단계로 이동시킵니다.파워 비아이는 사람들이 업무를 파악할 수 있도록 돕습니다.파워 앱스는 특정팀이 업무에 집중적으로 참여할 방법을 제공합니다.데이터버스는 이러한 도구들이 작동하는 동안 비즈니스 정보를 체계적이고 안전하게 유지합니다.그 차이가 중요합니다.자동화는 파일 시스템이 아니면 대시보드는 고객 데이터베이스가 아닙니다.각 도구는 별도의 역할을 하지만 모두 같은 원천 데이터로 작업할 수 있습니다.

이를 알면 모든 스프레드 시트나 단순 목록으로 전체 비즈니스 프로세스를 운영하려 하기 보다 올바른 도구를 선택하는 데 도움이 됩니다.데이터버스가 적합한 경우와 대체하지 못하는 것들.중요한 점은 이 겁니다.여러 사람과 앱이 연결된 비즈니스 데이터를 다뤄야 할 때 데이터버스를 선택하세요.분명한 액세스 규칙과 반복 가능한 프로세스가 필요합니다.데이터버스는 이를 처리하지만 다른 모든 것을 대체하지는 않습니다.개인적인 분석이나 빠른 목록 정리에는 여전히 엑셀이 최선입니다.쉐어포인트 목록은 단순한 팀 추적 업무에 효과적입니다.그리고 세밀한 제어가 필요한 개발자라면 SQL은 여전히 강력한 선택지입니다.그렇다면 데이터버스는 언제 진정으로 적합할까요?데이터가 중복 생성 없이 다이나믹스 365앱, 자동화, 보고서 전반에 걸쳐 연결되어야 할 때입니다.그 점이 바로 강점입니다. 결론을 맺겠습니다.하나의 기반, 다양한 비즈니스 도구, 핵심은 이렇습니다.다이나믹스 365와 데이터버스는 모든 데이터, 규칙, 보안, 앱, 자동화 및 보고서가 하나의 공통 기반을 공유할 때 가장 잘 작동합니다.다이나믹스 365, 파워 플랫폼 및 마이크로소프트 365에 대한 더 쉬운 가이드를 보려면M365.FM에서 마이크로소프트 날리지 너게츠를 구독하세요.그런 다음 데이터버스 테이블이 어떻게 실무 비즈니스 앱으로 변하는지 모델 기반 앱 에피소드를 시청하세요.