인쇄      온라인 도움말의 PDF 버전 열기


이전 항목

다음 항목

장부 구조 설계 정보

효율적인 장부 구조를 설정하려면 장부 계층 구조를 신중하게 계획해야 합니다. 회사의 장부 계층 구조를 설계 및 재정의할 때 다음 지침을 고려합니다.

  • 사용자 장부를 복제하는 사용자 정의 장부를 생성하지 마십시오.
  • 비즈니스 데이터에 대한 조직 및 접근 정책을 결정합니다.
  • 회사 구조가 데이터 관리에 적합한지 여부를 확인합니다.
  • 회사에서 데이터 제휴를 확인합니다.
  • 사용자 요구에 기초하여 장부를 설계하고 사용자가 가장 일반적으로 장부를 사용하여 태스크를 고려합니다.
  • 회사 프로필의 [관리자 가시성 사용] 확인란에 의해 제공된 기능이 가능한 적게 사용되도록 장부를 설계합니다.
  • 장부 계층 구조의 수준 수를 최소한으로 유지합니다.
  • 가능하면 장부 구조에서 교차 리스트 양을 줄입니다. 교차 리스트는 여러 장부에서 레코드를 중복하는 관행입니다.
  • Workflow 규칙을 사용하여 장부 관리를 자동화합니다. 또한 장부 이름을 설계할 때 장부 이름으로 확인되는 표현식을 사용하여 단일 워크플로 작업에서 다른 레코드에 다른 장부를 할당할 수 있는 기능을 고려합니다.

사용자 장부

사용자 장부를 복제하는 사용자 정의 장부를 생성할 경우 사용자 정의 장부 및 기본 사용자 장부의 데이터가 동기화되어야 한다는 단점이 있습니다. 이 추가 태스크로 인해 서버 처리 시간이 증가하고 레코드를 가져오는 속도가 느려집니다.

참고: 회사에서는 다른 사용자의 데이터에 대한 임시 접근 권한을 제공하기 위해 사용자 장부를 복제할 수도 있습니다. 이 요구 사항을 충족하는 더 나은 방법은 데이터에 접근하려는 사용자를 데이터를 담당하는 사용자의 위임자로 추가하는 것입니다.

데이터 접근 요구

장부 구조에서 회사의 회사 계층 구조를 반영할 필요는 없습니다. 대신에 회사에서 데이터를 구성하는 방법을 장부 구조에서 최대한 반영하는 것이 좋습니다. 비즈니스의 일부는 판매 구역별로 구성되고 일부는 제품 라인 또는 산업별로 구성될 수 있습니다. 특히 다음과 같은 경우에 주의합니다.

  • 둘 이상의 부서가 다른 부서에 속하는 데이터에 접근할 수 없어야 합니다.
  • 둘 이상의 부서가 다른 부서에 속하는 데이터에 접근할 수 있어야 합니다.

회사 구조의 적절성

대부분의 회사에서 상위 조직은 하위 조직의 모든 데이터에 완전히 접근할 수 있습니다. 이러한 상위 조직의 멤버는 일반적으로 모든 하위 조직의 데이터에 대한 전체 접근 권한을 가집니다.

조직이 이와 같은 방식으로 구조화된 경우 상위 조직 수준에서 조직 구조를 반영하는 장부를 설정하지 않는 것이 좋습니다. 하지만 다음을 고려합니다.

  • 다른 수준(예: 하위 조직 수준)에서 조직 구조를 반영하는 장부를 설정합니다.
  • 상위 조직 수준에서 다른 장부 계층 구조를 설정합니다. 예를 들어, 상위 조직 수준의 사용자가 모든 하위 조직에서 중요한 예상 매출을 가진 기회를 볼 수 있도록 허용하는 장부 또는 장부 계층 구조를 상위 조직 수준에서 생성할 수 있습니다.

데이터 제휴

사용자가 한 부서에서 다른 부서로 이동할 때 회사에서 따라야 하는 절차를 확인합니다. 예를 들면 다음과 같습니다.

  • 사용자가 관리하는 데이터가 항상 사용자와 함께 새 부서로 이동하기 때문에 데이터의 연속 제휴가 존재하는 경우 레코드 소유권 및 팀을 통해 데이터를 관리하는 것이 가장 좋습니다. 일반적으로 약속 및 태스크는 모든 수준에서 사용자와 함께 이동합니다. 일부 영업 환경에서는 모든 고객 데이터가 사용자와 함께 이동합니다. 소규모 및 중간 규모 기업과 가치가 높은 소규모 영업에 초점을 두는 기업의 경우 이 데이터 제휴가 적용됩니다.
  • 데이터가 일반적으로 고정 조직(예: 지역 조직)에서 유지되어 데이터의 조직 소유권이 존재하는 경우 조직 구조를 반영하는 장부를 통해 데이터를 관리하는 것이 가장 좋습니다.
  • 사용자가 다른 부서로 이동한 후 연속 제휴 및 조직 소유권이 둘 다 일정 기간 유지될 경우 두 계층 구조가 공존할 수 있습니다.

사용자 요구 및 태스크

장부 구조를 설계할 때 리스트를 통한 작업, 레코드 검색, 보고서 생성 및 사용 등을 비롯하여 사용자가 장부를 가장 일반적으로 사용하는 태스크를 고려합니다.

리스트를 통한 작업

사용자에게 필요한 리스트를 식별하는 데 도움이 되도록 가장 일반적으로 사용되는 리스트의 유형과 사용자에게 이상적인 리스트를 확인합니다. 회사의 사용자에게 의견을 물으면 이 작업을 수행하는 데 도움이 됩니다. 장부 구조의 장부에 이상적인 리스트에 필요한 모든 레코드가 포함되지 않은 경우 장부 구조에 계층 구조가 없는 것일 수 있습니다. 예를 들어, 지리 계층 구조 및 제품 지향 계층 구조를 둘 다 설정할 수 있습니다.

사용자가 한 개의 장부에 대한 특정 하위 집합에서 많은 시간을 들여 작업하는 경우, 하위 집합에 대한 하위 장부를 생성합니다. 사용자가 인식할 수 있는 방법으로 하위 장부의 이름을 지정합니다. 하위 장부는 장부 선택기의 기본값으로 설정할 수도 있으므로 사용자가 매번 적절한 장부를 선택하지 않아도 됩니다. 장부 선택기의 기본값 설정에 대한 자세한 내용은 사용자 및 사용자 역할에서 장부를 사용으로 설정을 참조하십시오.

레코드 검색

회사에서 사용자의 검색 요구를 확인하려면 특정 레코드를 검색하는 시나리오에 대해 사용자에게 물어봅니다. 사용자가 가장 자주 수행하는 검색 및 검색 조건을 장부 구조와 장부 크기에서 반영해야 합니다.

참고: 이미 장부 구조가 있으며 이를 재정의하려는 경우 특정 레코드가 계층 구조에서 특정 장부의 일부라는 것을 일반적으로 식별할 수 있는지 여부를 사용자에게 물어봅니다. 사용자가 상위 수준에서만 장부에 대해 확실히 알 수 있다고 일관되게 답변할 경우 장부 구조의 또 다른 부분을 통해 검색 범위를 좁힐 수 있는지 여부를 사용자에게 물어봅니다. 일반 검색의 예외적인 경우로만 상위 수준 장부를 검색하도록 사용자에게 강제해야 합니다.

또한 검색에서 사용되는 필드는 검색 속도에 영향을 줍니다.

  • 색인화된 필드를 사용하여 장부에서 레코드를 검색하면 성능이 최적화됩니다. 색인화된 필드는 검색 섹션에서 녹색 텍스트로 표시됩니다.
  • 색인화된 필드가 아니라 색인화되지 않은 필드를 사용하여 장부의 레코드를 검색할 경우 검색이 더 느려지며 검색하는 레코드 양에 따라 성능이 영향을 받습니다. 색인화되지 않은 검색 필드는 검색 섹션에서 검은색 텍스트로 표시됩니다.

예를 들어, 사용자가 일반적으로 색인화된 필드에 기초하여 컨택트 레코드를 검색한다는 것이 결정된 경우 최하위 수준 장부(리프 노드 장부라도 함)에 대한 레코드 수는 각 레코드 유형에 대해 최대 100,000개일 수 있습니다. 하지만 사용자가 일반적으로 색인화되지 않은 필드에 기초하여 컨택트 레코드를 검색할 경우 리프 노드 장부의 크기를 각 레코드 유형에 대해 20,000개에서 30,000개 사이의 레코드로 제한할 수 있습니다.

데이터 구성이 회사별로 다르므로 장부에 권장되는 레코드 수는 없으며 장부 크기를 지속적으로 관리해야 합니다. 장부는 검색되는 레코드 수를 줄여 검색 속도를 빠르게 합니다.

보고서 생성 및 사용

관리자를 제외한 모든 사용자는 보고서에 대한 데이터 가시성 규칙이 적용됩니다. 보고를 위해 장부 선택기에서 사용자 장부 또는 사용자 정의 장부를 지정한 경우 해당 보고서에 대해 고려되는 데이터는 다음과 같습니다.

  • [보고서] 및 [대시보드] 탭에서 접근하는 내역 분석 및 레코드 홈페이지에 포함된 보고서를 비롯한 내역 분석의 모든 콘텐츠는 장부로 한정되며 선택된 장부의 모든 하위 수준을 포함합니다. 사용자가 담당하는 레코드 또는 사용자가 팀 구성원으로 있는 레코드는 선택된 장부 또는 해당 하위 장부 중 하나에 없는 경우 포함되지 않습니다.
  • 실시간 보고는 장부 선택기에서 선택한 장부(사용자 정의 장부 또는 사용자 장부)에 직접 연결된 데이터로 제한됩니다. 선택된 장부에 하위 장부 또는 하위 항목이 있는 경우 하위 장부 또는 하위 항목의 데이터는 실시간 보고서에서 무시됩니다.

참고: 일반적으로 장부 구조를 설정한 후 변경할 필요가 없지만 원할 경우 변경할 수 있습니다. 이러한 변경을 수행하기 위해 작동 중지가 필요하지 않으며 변경 사항은 즉시 적용됩니다. 하지만 실시간 보고서의 데이터에서 변경 사항이 즉시 반영되지는 않습니다.

보고서에서 레코드 표시에 대한 자세한 내용은 보고서를 참조하십시오.

관리자 가시성

장부 계층을 설계할 때는 다음 원칙에 기초하여 설계합니다.

  • 회사 프로필의 [관리자 가시성 사용] 확인란에 의해 제공된 기능이 가능한 적게 사용됩니다.
  • [하위 항목 포함] 옵션은 대량의 데이터 검색에서 거의 또는 전혀 사용되지 않습니다. 대량의 데이터를 구성하는 레코드 수는 회사마다 다르고 검색 패턴에 따라 다릅니다.

    [하위 항목 포함] 옵션을 사용해야 하는 경우가 있습니다. 예를 들어, 해당 하위 항목에서 서로 간에 데이터를 공유할 수 없기 때문에 관리자가 하위 항목을 포함하는 사용자 장부에서 리스트를 실행해야 합니다. 양이 많은 경우 검색 시간이 증가합니다. 하지만 성능을 최적화하기 위해 [하위 항목 포함] 옵션을 필요한 경우에만 선택해야 합니다.

계층 구조 수준

많은 수의 수준이 있고 모든 수준에 레코드가 포함된 장부 계층 구조는 관리자 가시성이 사용으로 설정된 팀 기능과 비슷한 방식으로 작동합니다. 이러한 계층 구조는 작은 데이터 집합에서 잘 작동합니다. 하지만 데이터 양이 증가하면 계층 구조 수준이 적거나 없는 장부가 팀 기능보다 훨씬 더 성능이 뛰어납니다.

장부 계층 구조의 한 수준에서 데이터 보안 또는 데이터 구성에 추가 값을 제공하지 않을 경우 중복 장부 및 해당 하위 장부를 병합합니다. 동일한 상위 장부의 특정 하위 장부 또는 다른 하위 장부에 레코드가 있는지 여부를 일반적으로 식별할 수 있는지 장부 사용자에게 물어봅니다. 이를 식별할 수 없는 경우 두 하위 장부를 상위 장부로 축소하는 것이 최선의 방법입니다.

장부 계층 구조에서 수준 수를 줄이는 간단한 방법은 상위 장부 이름을 하위 장부의 접두어로 추가하는 것입니다. 예를 들어, 북미라는 상위 장부가 있는 북쪽이라는 하위 장부가 있는 경우 상위 장부를 제거하고 하위 장부의 이름을 NA – 북쪽으로 변경합니다.

교차 리스트

교차 리스트는 여러 장부에서 레코드를 중복하는 관행입니다. 교차 리스트를 사용하면 동기화가 필요하므로 사용자에게 관리 부담이 발생하며, 결과적으로 읽기-쓰기 작업이 많아져서 서버 성능에 영향을 줍니다. 교차 리스트를 최소한으로 유지하십시오.

자동화된 장부 관리

일반적으로 장부 할당 기준은 레코드 유형에 있는 하나 이상의 필드에 매핑됩니다. 이러한 필드 중 하나가 변경될 때 장부 할당을 자동으로 다시 구성하도록 Workflow 규칙을 생성할 수 있습니다.

예를 들어, 판매 구역이라는 장부 계층 구조가 있는 경우 Workflow 규칙을 생성하여 레코드 유형의 필드(예: 고객사의 [판매 구역] 필드)를 모니터링한 다음 규칙에서 [장부 할당] 작업을 생성하여 고객사의 [판매 구역] 필드가 변경될 때 레코드의 [판매 구역] 장부를 새 장부로 갱신할 수 있습니다.

장부 이름을 설계할 때 장부 이름으로 확인되는 표현식을 기반으로 단일 워크플로 작업에서 다른 레코드에 다른 장부를 할당할 수 있는 것과 같은 방법으로 [장부 할당] 워크플로 작업을 사용할지 여부를 고려합니다.

예를 들어 북미에 고객사가 있고 유럽/중동 아시아에 근거지를 둔 고객사도 있다고 가정합니다. 서로 다른 위치에 대해 두 개의 개별 장부를 설정하고 고객사 위치에 따라 고객사에 적절한 장부를 할당할 수도 있습니다. 이 구성을 설정하려면 북미 및 유럽/중동 아시아라는 이름의 장부 두 개를 생성합니다. 다음으로 북미 및 유럽/중동 아시아 값이 포함된 판매 지역이라는 사용자 정의 선택 리스트 필드를 생성하고 해당 역할의 고객사 레코드 유형에 대한 페이지 레이아웃에 사용자 정의 필드를 추가할 수 있습니다. 그런 다음 고객사 레코드가 갱신될 때 다음을 수행하는 장부 할당 워크플로 작업을 생성할 수 있습니다.

  • 표현식을 평가하여 고객사 레코드의 판매 지역 필드에서 선택하는 값을 결정합니다.
  • 고객사 레코드를 표현식에서 반환된 값과 일치하는 이름의 장부에 연결합니다.

관련 항목

다음 항목에서 관련 정보를 참조하십시오.


2017년 9월 게시됨 Copyright © 2005, 2017, Oracle. All rights reserved. Legal Notices.