영업사원이 고객 주소를 업데이트 합니다.나중에 재무팀이 같은 기록을 열어보지만 여전히 예전 주소가 보입니다.그럼 어떤 주소가 맞는 걸까요?수년 동안 이 문제를 해결하려면 누군가 데이터를 내보내고,스프레드 시트를 편집하고, 이메일을 보내고,두 번째 앱에 동일한 업데이트를 두 번 입력해야 했습니다.다이나믹스 365 듀얼라이트, 듀얼라이트가 이를 바꿉니다.이 기능은 재무 및 운영 앱과 데이터버스 기반 고객 앱을 연결하여고객이나 주문 같은 공유 레코드가 자동으로 동기화되도록 합니다. M365 FM 위 밀코 피터스와 함께하는 이 지식 나눔 시간에는듀얼라이트에 대해 알기 쉽게 설명해 드리겠습니다.무엇이 이동하는지, 어떻게 이동하는지,듀얼라이트가 어디에 적합하고 어디에 적합하지 않은지 다룰 것입니다.먼저 이 기능이 필요하게 된 비즈니스 문제부터 시작하겠습니다.듀얼라이트가 해결하는 문제입니다.두 그룹이 같은 고객을 대상으로 작업하지만매일 완전히 다른 앱을 사용하는 기업을 상상해보세요.재무 및 운영 앱은 백오피스 업무를 처리합니다.여기에는 자금, 재고, 제품, 주문, 구매 및 공급망이 포함됩니다.이곳은 기업이 판매하는 것, 배송할 수 있는 것, 갚아야 할 돈,고객이 지불해야 할 금액을 추적하는 곳입니다.고객 앱은 고객과 더 가까운 업무에 집중합니다.영업팀은 리드를 추적하고 영업기회를 만듭니다.고객 서비스팀은 질문과 사례를 처리합니다.현장 서비스팀은 작업을 계획하고 현장의 인력을 파견합니다.프로젝트팀은 고객에게 약속한 작업을 추적합니다.다른 업무에는 다른 화면이 필요합니다.영업사원이 통화 후 연락처 정보를 수정하기 위해재무 화면을 뒤져야 할 필요는 없습니다.하지만 재무 담당자는 영업팀이 보는 것과동일한 고객 및 주문 세부 정보가 필요합니다.송장과 배송이 해당 정보에 의존하기 때문입니다.연결이 없으면 한 고객이 조용히 두 개의 레코드가 됩니다.

영업팀은 노스인드 바이크스로 등록할 수 있고재무팀은 노스인드 바이시클 컴퍼니로 등록할 수 있습니다.이런 한 레코드에는 세 주소가 있는데다른 레코드는 여전히 예전 사무실로 송장을 보냅니다.두 레코드 모두 그 자체로는 합리적으로 보이지만더 이상 동일한 비즈니스 관계를 설명하지 못합니다.처음에는 작은 문제들이 나타납니다.다른 앱에서는 이름이 다르기 때문에고객을 찾을 수 없는 경우가 발생합니다.영업 담당자가 가격을 약속하거나 재고를 확인하지만정보가 운영 측면의 데이터와 일치하지 않습니다.재무팀은 주문을 처리해야 하지만고객 세부 정보를 확인하고 이메일을 보내고수동으로 다시 업데이트해야 합니다.그러면 그러한 작은 문제들이 쌓이게 됩니다.누군가 고객 데이터를 스프레드 시트로 내보냅니다.다른 사람이 몇 행을 수정하고 다른 곳으로 가져오기를 합니다.어떤 레코드가 먼저 나타날지 아무도 모르기 때문에또 다른 사람은 두 앱 모두에 새 고객을 입력합니다.곧 중복 데이터와 서로 다른 주소가 생겨나고데이터를 사용하는 시간보다 확인하는데더 많은 시간을 쓰게 됩니다.이 모든 문제는 사람들이 부주의해서 발생하는 것이 아닙니다.시스템이 사람들에게 연결고리 역할을 요구하기 때문에 발생합니다.사람들은 데이터를 복사합니다.사람들은 어떤 앱을 먼저 사용해야 하는지 기억해야 합니다.사람들은 오류가 이미 다른 팀에 전달된 후에야 실수를 발견합니다.이러한 방식은 비즈니스 시스템이 분리되어 있고팀들이 지연을 감수하던 시절에는 통했습니다.하지만 영업, 서비스, 재무, 운영 부서가 하루 종일 동일한 고객 정보가 필요할 때스프레드 시트는 부적절한 전달 도구가 됩니다.간단한 주문 상담을 생각해보세요.고객이 영업팀에 전화해 다음 주에 배송이 가능한가요? 라고 묻습니다.그리고 비용은 얼마인가요?영업팀은 답변을 위해 제품, 가격, 재고 정보가 필요합니다.

고객이 동의하면 재무 및 운영팀은 판매를 처리하기 위해정확한 고객 및 주문 정보가 필요합니다.양쪽 모두 동일한 사실 확인이 필요합니다.영업팀은 영업 담당자가 사용하는 앱에서 해당 정보가 필요합니다.재무 및 운영팀은 주문, 자금, 배송을 관리하는 앱에서 그 정보가 필요합니다.목표는 모든 팀을 하나의 거대한 화면에 강제로 맞추려는 것이 아닙니다.목표는 공유된 레코드가 명확하고 합의된 경로를 따르도록 하는 것입니다.이 지점에서 바로 이중쓰기, 듀얼라이트가 등장합니다.그렇다면 이중쓰기란 정확히 무엇일까요?가장 간단한 정의는 다음과 같습니다.이중쓰기는 다이나믹스 365 파이낸스 엔드 오퍼레이션즈 앱과 데이터버스 간의 선택된 데이터를동기화 상태로 유지하는 마이크로소프트 위 내장형 연결 기능입니다.데이터버스는 수많은 마이크로소프트 비즈니스 앱을 뒷받침하는 공통 데이터 기반입니다.다이나믹스 365 세일즈, 커스터머 서비스, 필드 서비스 및 프로젝트 오퍼레이션즈 위 일부가 이를 사용합니다.파워 앱스와 파워 오토메이트도 이를 사용할 수 있습니다.이중쓰기를 이해하기 위해 데이터버스가 모든 레코드를 어떻게 저장하는지 알 필요는 없습니다.그저 다이나믹스 365의 고객 앱 측에 있는 공통 데이터 영역이라고 생각하세요.프론트 오피스와 백오피스가 있는 사무실 건물을 상상해보세요.프론트 오피스는 고객과의 대화를 처리합니다.영업사원, 서비스 상담원, 현장 작업자들이 여기에 해당합니다.이들은 고객과 소통하고 요청을 추적하며 업무를 관리하는 데 도움이 되는 화면이 필요합니다.백오피스는 회사를 유지하는 업무를 처리합니다.재무 기록, 재고, 주문, 구매, 배송 등이 이에 해당합니다.두 사무실 모두 같은 회사를 위해 일하지만 적절한 연결고리가 없으면 누군가 직접 정보를 한쪽에서 다른 쪽으로 옮겨야 합니다.인쇄된 양식을 전달하거나 이메일을 보내거나 다른 시스템의 데이터를 복사합니다.

업무는 처리되지만 시간이 더 걸리고 그 과정에서 세부사항이 변경될 수 있습니다.이중쓰기는 두 사무실 사이에 직원이 배치된 내부 문과 같습니다.한쪽에서 지원되는 레코드가 변경되면 이중쓰기는 그 문을 통해 관련 변경사항을 반대편으로 전달합니다.모든 앱을 하나의 거대한 앱으로 합치는 것이 아닙니다.영업팀은 여전히 영업앱에서 작업할 수 있습니다.재무팀은 여전히 재무앱에서 작업할 수 있습니다.각 팀은 업무에 맞게 구축된 화면을 유지하면서 선택된 공유정보만 보이지 않는 곳에서 연결됩니다.지원되는 서포티드 이라는 단어가 중요합니다.듀얼라이트는 양쪽 시스템의 모든 데이터를 맹목적으로 복사하지 않습니다.서로 연관된 레코드 간의 정의된 연결을 통해 작동합니다.마이크로소프트는 이러한 연결을 테이블 맵, 테이블 맵스 이라고 부릅니다.테이블은 앱이 한 종류의 레코드를 보관하는 장소일 뿐입니다.고객 테이블에는 고객 레코드가 저장됩니다.제품 테이블에는 제품 레코드가 저장됩니다.주소 테이블에는 주소 상세 정보가 저장됩니다.테이블 맵은 파이낸스 앤드 오퍼레이션즈 측의 어느 테이블이 데이터버스 위 어느 테이블과 연결되는지 듀얼라이트에 알려줍니다.테이블 맵을 합의된 번역 시트라고 생각하십시오.한 열은 한쪽의 레코드를 식별합니다.다른 열은 그와 일치하는 반대편의 레코드를 식별합니다.시트의 나머지 부분은 어떤 필드들이 서로 대응되는지 설명합니다.이름, 전화번호, 주소 행과 같은 것들입니다.그 합의가 연결 규칙을 제공합니다.그렇지 않으면 두 앱은 서로 다른 레이블을 사용하거나 같은 정보를 다른 곳에 저장할 수도 있습니다.맵은 듀얼라이트에게 그러한 정보들이 어떻게 연관되는지 알려줍니다.따라서 앱은 매번 사람이 해석해줄 필요가 없습니다.흔히 듀얼라이트라는 이름을 들으면 모든 변경사항이 항상 양방향으로 이동한다고 생각하기 쉽습니다.

때로는 그렇습니다.지원되는 양방향 맵의 경우 데이터버스에서의 변경사항이 파이낸스 앤드 오퍼레이션즈 위 관련 레코드를 업데이트할 수 있습니다.파이낸스 앤드 오퍼레이션즈에서 지원되는 변경사항 역시 데이터버스 위 관련 레코드를 업데이트할 수 있습니다.양쪽 모두 동일한 공유 레코드에 참여할 수 있습니다.그것이 바로 듀얼 이중이라는 부분입니다.

사용자가 지원되는 레코드를 업데이트하면 연결을 통해 작업이 진행중인 상태에서 업데이트가 전송됩니다.거의 실시간이라는 것이 마법이나 지연시간 0을 의미하는 것은 아닙니다.하루에 한 번 파일 교환을 하는 방식이 아니라 실시간 비즈니스 업무를 위해 연결이 구축되었다는 뜻입니다.누군가 세부 정보를 변경하면 관련팀은 내일 아침까지 기다릴 필요 없이 즉시 확인할 수 있습니다.이것이 팀의 업무 방식을 바꿉니다.프런트 오피스는 백오피스에서 오는 데이터를 사용할 수 있습니다.백오피스는 고객 대면 앱에서 지원되는 업데이트를 받을 수 있습니다.데이터버스는 한쪽의 데이터 기반이 되고파이낸스 앤드 오퍼레이션즈는 다른 쪽의 운영 기반이 되며듀얼라이트는 승인된 공유 레코드를 연결 상태로 유지합니다.하지만 열려있는 내부 통로에는 규칙이 필요합니다.레코드가 양방향으로 이동하게 하려면레코드가 어디서 시작되어야 하는지누가 변경할 수 있는지두 앱의 정보가 다를 경우 어느 쪽을 우선할지 알아야 합니다.어떤 데이터를 이동할 수 있고어느 시스템이 그 데이터를 소유할까요?그렇다면 듀얼라이트는 어떤 레코드를 연결 상태로 유지할 수 있을까요?흔한 예로는 여러 부서가 매일 공유하는 레코드부터 시작합니다.고객 레코드, 주소, 연락처, 제품, 공급업체, 회사 세부 정보,그리고 재무 및 채무용 참조 정보가 있습니다.고객 레코드에 대해 잠시 생각해 보겠습니다.영업부서는 고객 이름, 주요 연락처, 전화번호, 배송 주소가 필요합니다.재무부서는 법적 고객 레코드, 청구 세부 정보,주문 및 송장에 필요한 정보가 필요합니다.각 부서가 별도의 고객 목록을 관리하면회사는 고객 서비스 대신 레코드를 대조하는 데 시간을 허비하게 됩니다.적절한 듀얼라이트 맵이 설정되면각 팀은 연결된 고객 세부 정보를 바탕으로 작업할 수 있습니다.그렇다고 해서 영업 사용자가 갑자기 재무 앱을 배워야 한다는 뜻은 아닙니다.

이는 영업 사용자는 다이나믹스 365세일즈에서 고객 정보를 다루고,재무 사용자는 재무 앱에서 관련 고객 정보를 다룰 수 있음을 의미합니다.고객은 양쪽 모두에서 동일한 고객으로 인식됩니다.주소 또한 중요합니다.고객은 청구지 주소, 배송지 주소,그리고 서비스 작업자가 방문해야 할 현장 주소를 가질 수 있습니다.각 주소마다 역할이 다르기 때문에이러한 세부 정보를 단순히 하나의 상자에 복사된 일반 텍스트로 처리할 수는 없습니다.듀얼라이트는 이러한 관계에 필요한 공유 레코드 구조를 지원합니다.연락처도 동일한 패턴을 따릅니다.한 고객 사는 구매자, 매입 채무 담당자, 서비스 관리자를 둘 수 있습니다.영업 부서는 누가 의사결정을 내리는지 알아야 합니다.재무 부서는 청구 관련 문의를 어디로 보내야 할지 알아야 합니다.서비스 부서는 현장에서 누가 기다리고 있는지 알아야 합니다.연결된 레코드는 각 팀이 모든 앱에서 정보를 재부축할 필요 없이고객과 관련된 사람들을 확인할 수 있도록 돕습니다.제품 또한 흔한 예입니다.영업 담당자는 회사가 무엇을 판매하는지,제품 가격은 얼마인지, 재고가 있는지 알아야 합니다.이러한 정보는 보통 제품, 재고, 구매, 이행 업무가 관리되는 운영 측면에서 나옵니다.그래서 제품 정보는 재무 및 운영에서 시작되는 경우가 많습니다.운영팀이 그곳에서 제품을 생성하고 준비합니다.제품이 고객되면 업무에 준비되면듀얼라이트를 통해 관련 제품 세부 정보를 데이터버스로 전송할 수 있습니다.그러면 영업 사용자는 누군가 제품 목록을 다시 입력할 필요 없이자신의 앱에서 제품을 선택하고 논의할 수 있습니다.이는 영업 상담이 비즈니스가 실제로 제공할 수 있는 범위 내에서 이루어지도록 돕습니다.가격과 재고 세부 정보도 연결된 앱을 통해 영업 부서에 도달할 수 있습니다.항목 존재 여부, 가격 변동 또는 재고가 약속을 이행할 수 있는지 추측하는 대신영업팀은 운영 측면과 연동된 정보를 바탕으로 업무를 수행할 수 있습니다.

그렇다고 해서 훌륭한 영업적 판단이 필요 없다는 것은 아닙니다.이는 영업 담당자가 기본적인 세부 사항을 확인하려고창고에 전화해야 하는 불필요한 이유를 하나 없애줍니다.공급업체 정보도 비즈니스 프로세스에 필요한 곳으로 연결할 수 있습니다.회사 세부 정보, 조직 구조, 재무참조 데이터, 세금 참조 데이터는고객 측과 운영 측 모두에서 중요할 수 있습니다.정확한 레코드는 회사가 사용하는 앱과 프로세스에 따라 다르지만패턴은 동일하게 유지됩니다.양쪽에서 같은 의미를 가져야 하는 레코드를 공유하세요.이제 모든 레코드가 양방향으로 이동해야 한다고 가정하지 마십시오.일부 앱은 양방향 업데이트를 지원합니다.변경사항은 데이터버스에서 시작하여 파이낸�스 엔드 오퍼레이션즈로 이동하거나파이낸스 엔드 오퍼레이션즈에서 시작하여 데이터버스로 이동할 수 있습니다.이 방식은 양쪽 모두 승인된 세부 정보를 업데이트할정당한 비즈니스 사유가 있는 레코드에 적합합니다.다른 맵은 단방향으로 실행됩니다.제품이 유용한 예가 됩니다.많은 기업에서 제품 생성은 파이낸스 엔드 오퍼레이션즈가 담당하는데이는 운영 부서가 제품 마스터, 재고, 단위 및 판매와 배송에 필요한기타 세부 정보를 관리하기 때문입니다.그런 다음 제품 정보는 데이터버스로 흘러들어가영업 및 서비스팀이 사용할 수 있게 됩니다.이는 명확한 규칙입니다.제품에 대해 두 팀이 경쟁하는 버전을 만들 필요는 없습니다.한쪽이 제품을 생성하고 관리하며다른 한쪽은 이를 받아 업무의 일부로 사용합니다.모든 공유 레코드에는 그러한 결정이 필요합니다.이 레코드는 어디에서 시작됩니까?누가 편집할 수 있습니까?이름, 주소, 가격 또는 분류가 잘못된 것처럼 보이면어느 팀이 수정합니까?이러한 질문은 간단해 보이지만나중에 발생할 많은 혼란을 방지해줍니다.연결을 통해 변경사항이 매우 빠르게 이동할 수 있습니다.

변경사항의 소유자가 누구인지 아무도 합의하지 않았다면실수도 똑같이 빠르게 전파될 수 있습니다.레코드에 대한 소유자를 선택하고 필요한 경우해당 레코드 내의 개별 세부 정보에 대한 소유자도 선택하십시오.예를 들어 영업부서가 고객의 관계 세부 정보와주요 연락처 정보를 소유할 수 있습니다.재무부서는 결제 관련 세부 정보를운영부서는 제품 및 재고 세부 정보를 소유할 수 있습니다.정확한 분담은 비즈니스 방식에 따라 다르지만이를 문서화하고 앱을 사용하는 사람들이 이해해야 합니다.또한 듀얼라이트가 데이터버스를 확장한 후 보게 될파티, 당사자와 컴퍼니, 회사라는 두 가지 용어가 있습니다.파티는 사람이나 조직을 일관된 방식으로 처리하기 위한마이크로소프트 위 방식입니다.이는 모든 관계를 별개에 관련 없는 레코드로 취급하지 않고사람, 조직, 연락처 및 주소를 연결하는 데 도움이 됩니다.컴퍼니는 데이터버스가 파이낸스 앤드 오퍼레이션즈에서사용하는 비즈니스 회사 컨텍스트를 이해하도록 돕습니다.첫날부터 두 용어의 전문가가 될 필요는 없습니다.재무 및 운영 앱은 레코드가 양측을 오갈 때고객 앱이 인식해야 하는 비즈니스 구조를 처리함으로그 존재를 알아두기만 하면 됩니다.레코드가 양방향으로 이동할 수 있게 되면데이터 자체만큼이나 해당 레코드를 둘러싼 프로세스도 중요해집니다.변경사항이 앱 간에 어떻게 이동하는지 살펴보겠습니다.시스템을 통해 변경사항 하나가 어떻게 처리되는지 실제로 확인해봅시다.영업 담당자가 새 사무실로 이전한 고객과 통화 중입니다.대화 중에 담당자는 다이나믹스 365세일즈에서고객 레코드를 열고 주소를 업데이트합니다.간단하죠?그런 다음 레코드를 저장합니다.바로 여기서 흥미로운 부분이 시작됩니다.세일즈는 해당 변경사항을 고객 대면 앱의 데이터 측면인 데이터버스에 저장합니다.그러면 듀얼라이트 가이사이트와 재무 및 운영 사이의 고객 및 주소 정보를 연결하는 맵을 확인합니다.

해당 변경사항을 자동으로 전송합니다.누군가 가져가기를 기다리며 공유 폴더에 쌓여있는 내보내기 파일 같은 것은 없습니다.이 주소를 업데이트해주세요.라는 메모와 함께 재무팀에 이메일을 보낼 필요도 없습니다.맵은 이미 연결된 필드를 알고 있으며지원되는 변경사항을 재무 및 운영에 관련 고객 레코드로 바로 보냅니다.따라서 재무 사용자는 나중에 해당 고객 레코드를 열어 업데이트된 주소를 확인하고지체 없이 주문을 처리하거나 송장을 준비할 수 있습니다.그것이 바로 실질적인 결과이며 아주 명확합니다.두 사람은 서로 다른 앱에서 작업하지만누구도 같은 고객 세부 정보를 다시 입력할 필요가 없습니다.영업 담당자는 고객 상담에 최적화된 화면에서 작업합니다.재무 사용자는 재무 업무에 맞춰진 화면에서 작업합니다.각 담당자는 자신이 필요한 고객 정보를 바로 필요한 곳에서 확인합니다.이 이동은 반대 방향으로도 작동합니다.재무팀이 재무 및 운영에서 지원되는 고객 정보를 업데이트한다고 가정해보세요.재무 사용자가 운영 고객 레코드에 속한 세부 정보를 수정한다고 합시다.듀얼라이트는 일치하는 맵을 역으로 사용하여해당 관련 업데이트를 데이터버스로 보냅니다.그러면 세일즈 나다른 데이터버스 기반 앱에서 이를 가져올 수 있습니다.이 연결은 일상적인 업무를 위해 동기식으로 작동합니다.동기식이라는 것은 앱이 20분 뒤에 실행될지 모르는 백그라운드 작업에 넘기는 대신동일한 작업 순간에 관련 업데이트를 완료하려고 시도한다는 의미입니다.연결이 업데이트를 완료할 수 없는 경우누군가 불일치를 발견할 때까지 숨겨두는 것이 아니라 즉시 주의가 필요합니다.이러한 동작은 공유 비즈니스 레코드에 적합합니다.일괄 작업이 실행되지 않아 고객 주소, 제품 세부 정보 또는 기타 공유 정보가몇 시간 동안 일치하지 않는 상태로 방치되는 것을 원치 않을 테니까요.

사람들은 지금 당장 화면에 보이는 것을 바탕으로 위사결정을 내립니다.따라서 이 연결은 작업이 진행되는 동안 양쪽을 긴밀하게 유지합니다.진행 중인 작업이라도 때로는 제어된 일시 중지가 필요합니다.이중 쓰기, 듀얼라이트, N은 재생, 일시 중지, 따라잡기 옵션이 포함되어 있습니다.재생은 맵이 실행 중이며 지원되는 변경 사항이 정상적으로 전송됨을 의미합니다.일시 중지는 팀이 계획된 작업을 수행하거나 문제를 조사하거나 변경 사항을 안전하게 관리해야 할 때 맵을 일시적으로 중단합니다.하지만 일시 중지는 연구적인 주차 공간이 아닙니다.맵이 일시 중지된 동안에는 제한된 시간과 공간 내에서 변경 사항이 대기열에 쌓일 수 있습니다.맵이 다시 시작되면 따라잡기 기능이 대기 중인 변경 사항을 처리합니다.이는 팀이 계획된 중단 이후 복구하는 데 도움이 됩니다.하지만 누군가는 해당 일시 중지를 책임지고 언제 맵을 다시 시작해야 할지 알고 있어야 합니다.일상 업무에서의 모든 것이 시작되기 전에 초기 동기화라는 또 다른 단계가 있습니다.초기 동기화는 양쪽의 기존 레코드를 공유된 시작 지점으로 가져옵니다.파이낸스 앤드 오퍼레이션즈의 고객이 이미 있고 데이터버스에 고객 레코드가 있는 회사를 생각해보십시오.연결이 켜지자마자 모든 기존 레코드가 이미 완벽하게 일치한다고 가정할 수는 없습니다.시작선이 필요합니다.초기 동기화는 사람들이 실시간 업데이트에 의존하기 전에 기존 데이터를 가져오는데 도움이 됩니다.중복 레코드, 불완전한 주소, 오래된 테스트 데이터는 동기화가 시작된다고 해서 마법처럼 스스로 정리되지 않으므로 주의가 필요합니다.레코드가 합의된 규칙을 따르지 않으면 오히려 문제를 더 빠르게 일으킬 수 있습니다.맵이 실행되면 이중 쓰기를 관리하는 사람들은 상태를 확인할 수 있는 명확한 공간이 필요합니다.이중 쓰기는 통합된 활동 및 오류 로그를 제공하여 관리자가 연결이 처리한 내용과 문제가 발생한 위치를 확인할 수 있게 합니다.

또한 경고 및 임계 값을 설정할 수도 있습니다.즉, 사용자가 업데이트 누락이나 실패를 통해 문제를 발견하기 전에 담당자가 미리 알 수 있습니다.모든 오류에는 원인이 있기 때문에 이러한 지원 보기가 중요합니다.필수 필드가 누락되었을 수도 있습니다.관련 레코드가 아직 도착하지 않았을 수도 있습니다.누군가 맵에 맞지 않는 방식으로 데이터를 변경했을 수도 있습니다.원인을 수정하지 않고 실패한 레코드를 다시 시도하면 보통 똑같은 오류가 다시 발생합니다.잘 운영되는 이중 쓰기 설정은 연결을 모니터링하고 오류의 근본 원인을 해결하며실제로 연결 상태를 유지해야 하는 레코드에 집중하도록 맵을 관리합니다.이중 쓰기가 가장 적합한 곳.이중 쓰기는 귀하의 비즈니스가 다이나믹스 365 파이낸스 또는 서플라이 체인 매니지먼트와 함께 영업, 고객 서비스, 현장 서비스, 프로젝트 운영과 같은 고객 대면 앱을 사용할 때 가장 적합합니다.이러한 앱은 동일한 비즈니스 대화에 서로 다른 부분을 지원합니다.한 팀은 고객과 상담하고 다른 팀은 배송 계획, 재고 관리, 비용 추적 또는 청구서 발송을 담당합니다.두 그룹 모두 하루 동안 관련 레코드를 기반으로 작업해야 할 때 듀얼라이트를 사용하면 모두에게 동일한 앱을 강요하지 않고도 작업을 연결할 수 있습니다.잠재 고객에서 현금화까지의 과정을 예로 들어보겠습니다.영업 담당자는 다이나믹스 365세일즈에서 잠재 고객과 상담합니다.그들은 연락처를 추적하고 제품을 논의하고 견적을 작성하며 주문 단계로 나아갑니다.상담하는 동안 영업 담당자는 회사 재무부서와 관련된 고객 세부 정보, 제품 정보, 가격 및 주문 정보가 필요합니다.판매가 확정되면 재무 및 공급망 관리 부서가 약속 이후의 업무를 인수합니다.주문 이행, 재고천구 및 재무 기록을 처리합니다.듀얼라이트는 이 두 부분을 계속 연결해줍니다.

영업 담당자는 자신의 직무에 맞는 고객 앱에서 작업하고 재무 및 운영 부서는 해당 업무용으로 구축된 앱에서 거래를 관리합니다.고객 정보가 영업 부서의 이야기와 재무 부서의 이야기라는 두 개의 분리된 기록이 되지 않습니다.현장 서비스, 필드 서비스, 다 또 다른 좋은 예입니다.고객 현장에 기술자를 보내 장비를 설치, 수리 또는 유지 관리하는 회사를 상상해보십시오.현장 작업자는 고객 세부 정보, 작업 내용, 그리고 회사가 설치하거나 지원하는 항목에 고객 자산 정보가 필요합니다.보이지 않는 곳에서 회사는 부품, 비용, 구매 및 해당 작업과 관련된 자금을 추적해야 합니다.현장 서비스는 방문 계획 및 완료에 집중합니다.재무 및 운영은 그와 관련된 운영 및 재무 기록에 집중합니다.이 기록들이 제대로 연결되면 기술자의 작업이 사용된 부품, 작업 비용, 또는 연결된 고객 기록과 따로 놀지 않게 됩니다.프로젝트 운영, 프로젝트 오퍼레이션즈, 도 프로젝트 단위로 작업을 판매하는 기업의 경우 같은 패턴을 따릅니다.프로젝트 팀은 고객 작업, 인력 시간, 계획된 비용 및 프로젝트 마일스톤을 관리합니다.재무부서는 구매, 비용, 청구 및 보고의 재무적 측면을 확인해야 합니다.연결이 없으면 프로젝트 관리자는 업데이트를 받기 위해 재무부서를 쫓아다니느라 너무 많은 시간을 허비하고,재무부서는 작업 내용을 확인해줄 프로젝트 팀을 기다리게 됩니다.연결된 프로젝트 기록은 두 그룹 모두에게 고객과의 약속이 재무 활동으로 넘어가는 과정을 더 명확하게 보여줍니다.또한 여기에는 더 넓은 파워 플랫폼 혜택도 있는데,고객 앱 측에서 데이터버스를 사용하기 때문에 데이터버스 위 승인된 데이터는 파워 앱스 및 파워 오토메이트를 지원할 수 있습니다.기업은 내부팀을 위한 작은 앱을 구축하거나, 비즈니스 기록이 특정 지점에 도달할 때 반응하는 흐름을 만들 수 있습니다.

그렇다고 해서 모든 재무 및 운영 기록이 갑자기 모든 파워 앱에 포함되어야 한다는 의미는 아닙니다.이는 기업이 목적을 신중히 선택하고 데이터를 적절히 보호하기만 한다면,연결된 내 코드가 더 광범위한 비즈니스 도구 세트의 일부가 될 수 있음을 의미합니다.한 가지 경계는 명확히 유지되어야 합니다.듀얼라이트는 다이나믹스 365 비즈니스 센트럴을 지원하지 않습니다.비즈니스 센트럴은 다른 방식으로 마이크로소프트 제품과 연결될 수 있지만,듀얼라이트는 다이나믹스 365의 재무 및 운영 부문과 데이터버스 기반 고객 앱을 위한 것입니다.또한 모든 테이블을 복사하기 위한 도구도 아닙니다.레코드는 단순히 데이터를 복사하는 것이 안전하다고 느껴서가 아니라,양쪽에서 동일한 운영 레코드가 필요할 때 이동되어야 합니다.또한 기업의 보고 피드, 타사 시스템과의 연결 또는 대규모 데이터 마이그레이션이 필요할 때,듀얼라이트가 더 광범위한 통합계획을 대체하지는 않습니다.모든 데이터 연결을 동일한 작업으로 취급하면 금방 문제가 발생합니다.제한사항, 준비사항 및 일반적인 실수들입니다.듀얼라이트를 두 시스템 간의 악수계약처럼 생각하십시오.그들은 특정 공유 레코드를 동기화 상태로 유지하기로 합의하지만,모든 테이블, 보고서 또는 외부 시스템을 위한 마법의 통로는 아닙니다.설정하기 전에 이미 존재하는 통합 항목이 무엇인지 확인하십시오.기존 연결과 듀얼라이트가 동일한 고객 레코드를 모두 업데이트하면 금방 충돌이 발생할 수 있습니다.이는 원치 않는 골칫거리입니다.그러니 먼저 기본적인 사항에 대해 합의하십시오.이름은 어떻게 입력할 것인가요?각 레코드는 어느 법적 회사가 소유하나요?누가 변경할 수 있나요?각 팀에는 어떤 보안 역할이 필요한가요?첫 동기화 전에 중복 및 불안전한 레코드를 정리하십시오.마이크로소프트 위 사전 구축된 맵으로 시작하십시오.

공통 레코드는 이미 연결되어 있습니다.사용자 지정 테이블과 필드는 신중한 테스트가 필요합니다.또한 관련 테이블과 맵 종속성을 확인하십시오.한 레코드가 동기화되려면 다른 레코드가 먼저 존재해야 하는 경우가 있기 때문입니다.데이터 양을 기반으로 첫 동기화를 계획하십시오.점심시간에 켜는 조명 스위치처럼 취급하지 마십시오.그러면 문제가 발생합니다.일시 중지된 맵도 담당자와 재시작 계획이 필요합니다.대기 중인 변경 사항과 실패한 레코드는 영원히 유지되지 않습니다.활동 로그, 오류, 경고 및 인계 값을 주시하십시오.무언가 실패하면 누락된 필드, 잘못된 레코드 또는 그 이면에 깨진 규칙을 찾으십시오.반복적인 제시도로는 잘못된 데이터를 수정할 수 없습니다.듀얼라이트를 제어된 교량으로 인식하면 모든 것이 제자리를 찾게 됩니다.결론적으로 하나의 공유된 비즈니스 대화입니다.듀얼라이트는 지원되는 공유 레코드를 재무 및 운영과 데이터버스 기반 고객 앱 간에 계속 이동시킵니다.그렇게 하면 팀은 연결된 비즈니스 데이터를 기반으로 작업할 수 있습니다. M365.FM에서 저 미르코 피터스와 함께 더 많은 지식을 얻으려면 즐겨 찾는 팟캐스트 플랫폼에서 구독하시고여전히 스프레드 시트로 영업, 서비스, 재무를 연결하고 있는 사람에게 이 에피소드를 공유해주세요.