차원 디자인 고려 사항

차원을 효과적으로 디자인하는 것은 정확한 보고, 분석 및 성능 관리를 보장하는 데 중요합니다.

차원 디자인 중에는 다음 모범 사례를 따릅니다.

애플리케이션 구조를 생성하는 차원 디자인

비즈니스 프로세스를 지원할 계정, 엔티티 및 기타 차원을 추가합니다.

차원은 데이터 값을 분류합니다. Planning에는 계정, 엔티티, 시나리오, 버전, 기간, 연도 차원이 포함되어 있습니다. 여러 통화로 계획하는 경우 애플리케이션에 통화 차원도 있습니다.

제품, 고객, 시장 등의 사용자정의 차원을 사용하여 고유한 값을 정의할 수도 있습니다. 최대 32개의 차원을 사용할 수 있습니다. 그러나 모범 사례 권장 사항은 12개 미만을 포함하는 것입니다. 로드 파일을 사용하여 차원을 추가하거나 Oracle Smart View for Office에서 차원을 빌드할 수 있습니다.

비디오

목표	비디오 자료
애플리케이션에서 데이터를 익스포트하고 임포트하는 방법을 알아봅니다.	Oracle Planning and Budgeting Cloud에서 데이터 익스포트 및 임포트
파일을 사용하여 차원을 로드하는 방법을 알아봅니다.	Oracle Planning and Budgeting Cloud에서 메타데이터 임포트

프로세스에 따라 차원 확인

이 프로세스를 사용하여 애플리케이션에 포함할 차원을 확인합니다.

요구사항을 기반으로 고유한 계획 프로세스를 확인합니다.
예: 마케팅 계획, 판매 계획, 오버헤드 계획, 자본 계획, 현금 흐름 계획, 인력 계획
각 계획 프로세스의 차원을 확인합니다.
예: 제품, 시장, 채널, 제품 세그먼트, 고객 세그먼트
차원이 서로 어떻게 관련되는지 정의합니다.
예: 제품은 시장과 다대다 관계입니다. 제품 세그먼트 및 제품은 일대다 관계입니다. 노무 리소스 및 자재 리소스는 관계가 없습니다.
계획 및 보고를 위해 차원을 버킷으로 구분합니다.
예: 제품, 시장 및 채널은 계획 차원이며, 제품 세그먼트 및 고객 세그먼트는 보고 차원입니다.
계획 프로세스를 Planning Modules에 매핑합니다.
예: 프로젝트 또는 재무를 사용하여 마케팅 계획을 구성하고, 재무 및 사용자정의 큐브를 사용하여 오버헤드 계획 및 현금 흐름 계획을 구성합니다.

차원에 대한 공통 사용 사례 고려

차원에 대한 다음 공통 사용 사례를 검토하고 해결 방법 가이드라인을 알아봅니다.

표준(필수) 차원
대부분의 상위 레벨 공통 재무 계획 사용 사례는 표준 차원을 사용하여 해결될 수 있으며, 표준 차원 이름을 바꿀 수도 있습니다.
사용자정의 또는 선택적 차원
요구사항에 따라 추가(사용으로 설정)하거나 이름을 바꿀 수 있는 사용자정의 또는 선택적 차원을 사용하여 차원을 확장합니다.
차원의 다중 계층
두 개 이상의 관련이 없는 차원을 하나의 차원으로 조합하여 차원 간 관계없음 상태가 되는 것을 방지합니다.
계획 또는 보고를 위한 대체 계층
하향식 할당이나 보고를 목적으로 동일한 멤버를 여러 상위 아래에 그룹화할 수 있는 경우 대체 계층을 사용합니다.
보고 속성 차원
하나의 차원과 관련이 있거나 두 차원 간 관계가 시간이 지나도 변경되지 않는 경우 속성 차원은 보고 요구사항을 충족하는 데 유용합니다.
보고를 위한 스마트 목록 및 ASO 차원
보고 차원 및 다른 차원 간 관계가 시간에 따라 변경되는 경우 보고를 위한 스마트 목록 및 ASO 차원을 사용하면 유용합니다.
계획을 위한 스마트 목록 및 다중 큐브 BSO 차원
계획 차원이 계획 프로세스의 기본 차원이 아니며 계획 차원을 하위 프로세스로 분할해야 하는 경우 이 전략이 유용합니다.

이 샘플 워크시트는 차원 확인 및 사용 사례 나열을 비롯하여 차원 계획 방법에 대한 예제를 보여 줍니다.

예제 디자인 전략 검토

이러한 예제를 검토하여 차원에 대한 추가 디자인 전략을 이해합니다.

보고 속성 차원 사용

보고 속성 차원을 사용하면 보고 요구사항을 충족하는 데 유용할 수 있습니다. 속성은 하나의 차원과 관련이 있으며 두 차원 간 관계는 시간이 지나도 변경되지 않습니다.

예:

프로젝트 차원에서 프로그램이라는 속성을 정의합니다.
그런 다음 프로그램 차원에서 멤버 계층을 생성할 수 있습니다. 프로그램 차원의 최상위 레벨 멤버는 자동으로 집계됩니다.
각 프로젝트 멤버를 프로젝트 추가 Groovy 규칙에 있는 프로그램 차원의 리프 레벨 멤버와 연계합니다.
이렇게 하면 프로젝트를 프로그램별로 필터링할 수 있습니다.
보고 양식은 프로그램 레벨 비용 및 수익을 보여 줄 수 있습니다.

보고를 위한 스마트 목록 및 ASO 차원 사용

보고 차원 및 다른 차원 간 관계가 시간에 따라 변경되는 경우 이 전략이 유용합니다.

예:

ASO에서 기능 차원을 추가하고 기능 스마트 목록을 기능 차원에 매핑합니다.
BSO에서 ASO 큐브로 데이터를 이동하는 데 사용할 데이터 맵을 생성합니다.
데이터 맵은 뱃치 프로세스로 실행할 수도 있고 양식 또는 Groovy 규칙에서 스마트 푸시를 구현할 수도 있습니다.
ASO 큐브에서 보고 양식을 사용하여 프로젝트 전반의 기능별 노무 요구사항을 보여 줄 수 있습니다.

스마트 목록 및 다중 큐브 BSO 디자인 사용

계획 차원이 계획 프로세스의 기본 차원이 아니며 계획 차원을 하위 프로세스로 분할해야 하는 경우 이 전략이 유용합니다.

예:

직원 및 작업은 프로젝트 계획의 인력 및 스마트 목록에 있는 차원입니다.
프로젝트 계획에서는 라인 항목을 사용하여 작업 및 직원 레벨의 노무 비용을 계획합니다.

차원의 다중 계층

차원에서 다중 계층을 사용할 수 있습니다. 두 개 이상의 관련이 없는 차원을 하나의 차원으로 조합하여 차원 간 관계없음 상태가 되는 것을 방지합니다.

예:

프로젝트에서 작업, 장비 및 자재는 관련이 없으므로 단일 리소스 클래스 차원으로 조합됩니다.
재무에서 수익 센터 및 비용 센터는 관련이 없으므로 단일 엔티티 차원으로 조합될 수 있습니다.

계획 및 보고를 위한 대체 계층

하향식 할당이나 보고를 목적으로 동일한 멤버를 여러 상위 아래에 그룹화할 수 있는 경우 대체 계층을 사용합니다.

예: 브랜드 및 제품 범주별 계획 및 보고를 위해 제품 차원에서 대체 롤업을 생성합니다.

차원에 대한 10대 모범 사례 알아보기

차원을 디자인하는 경우 다음 주요 모범 사례를 따릅니다.

차원 순서는 수정된 모래시계 형식을 따릅니다.
이 형식에서는 가장 밀집된 차원이 첫번째에 오고, 그다음으로 덜 밀집된 차원이 배치됩니다. 그 뒤를 이어 집계 가능한 희소 차원이 오고, 그다음에 집계 불가능한 희소 차원이 배치됩니다. 희소 차원 내에서는 가장 밀집된 희소 차원이 먼저 오고, 그다음으로 가장 덜 밀집된 희소 차원이 배치됩니다.

하이브리드 BSO에서도 순서는 동일하나, 비동적 희소 차원이 동적 희소 차원보다 먼저 옵니다.

Cloud EPM에서 차원 관리 자습서에서 밀집 및 희소 차원에 대해 자세히 알아보십시오.
대형 블록 크기는 성능에 큰 영향을 줍니다.
블록 크기는 밀집 차원 수 및 해당 밀집 차원의 멤버에 따라 결정됩니다. 최적의 블록 크기는 8KB에서 500KB 사이입니다. 밀집 차원 수를 최대 3개로 줄입니다. 밀집 차원의 경우 레벨 1 이상은 레이블 전용 또는 동적 계산이어야 합니다.
텍스트, 스마트 목록, 날짜 및 저장된 퍼센트 유형 계정은 통합 등록정보에 대해 [사용 안함]으로 설정되어야 합니다.
계정이 집계 스크립트에서 명시적으로 제외되지 않는 경우 이러한 값을 집계하면 불필요한 데이터가 생성될 수 있습니다.
2세대 멤버는 모두 [무시]로 설정되어야 합니다.
이러한 루트 멤버에 대해 보안을 정의할 수 없으므로 해당 멤버를 양식에 포함할 수 없습니다. 따라서 2세대 멤버를 루트로 집계할 필요가 없습니다. 이렇게 하면 애플리케이션의 블록 수가 증가합니다.
긴 차원 또는 플랫 차원을 사용하면 집계 성능 관련 이슈가 발생합니다.
하나의 상위 멤버 아래 200개가 넘는 멤버가 있는 경우 중간 상위를 추가합니다.
다중 큐브에 대해 차원 멤버를 사용으로 설정하면 동적 X-Ref가 생성되고 성능 이슈가 발생합니다.
HSP_NOLINK UDA를 사용하여 동적 X-Ref가 생성되는 것을 방지하십시오. 큐브 간 데이터 이동에는 데이터 맵 또는 스마트 푸시를 사용합니다.
간단한 계산의 경우 멤버 공식을 작성하는 대신 아웃라인 계산을 활용합니다.
간단한 계산의 예로는 계정 C = 계정 A – 계정 B가 있습니다.
가능한 경우 1차 하위가 하나뿐인 상위 멤버는 사용하지 마십시오.
1차 하위가 하나뿐인 상위 멤버를 사용하면 내재 공유가 발생하거나, [공유 안함] 설정 시 디스크에 중복 블록 및 데이터가 생성될 수 있습니다.
가능한 경우 BSO가 아닌 ASO의 큰 차원을 집계합니다.
이렇게 하면 예를 들어 큐브 새로고침 및 유지관리 시간 동안 성능이 향상됩니다.
2년이 넘은 과거 데이터는 BSO가 아닌 ASO에 저장합니다.
5년 또는 10년이 경과된 과거 데이터가 있는 경우 일부 데이터만 계산에 필요합니다. 필요한 경우 BSO 큐브에 계산을 위한 2~3년간의 과거 데이터를 보관할 수 있으며, 다른 과거 데이터는 ASO 큐브로 이동할 수도 있습니다. 최적의 성능을 위해 BSO 큐브를 가볍게 유지하고 데이터 입력의 계산에 초점을 맞추도록 하는 것이 좋습니다.

엔티티 차원 계획

엔티티 차원은 비용 센터, 부서, 비즈니스 단위, 사업부 등의 조직 구조를 나타냅니다.

조직이 표시되는 방식을 반영하도록 상위라는 롤업 멤버를 생성하여 비용 센터를 그룹화할 수 있습니다. 예를 들어 비즈니스 단위, 사업부 또는 다른 기능 구조로 롤업할 수 있습니다. 예를 들어 사업부까지 롤업되는 비즈니스 단위까지 롤업되는 비용 센터를 생성할 수 있습니다.

여러 보고 구조를 생성할 수도 있습니다. 예를 들어 지역 보고를 지원하기 위해 대체 구조를 생성할 수 있습니다. 여러 통화로 계획하는 경우 각 엔티티의 기준 통화를 설정합니다.

엔티티 차원은 예산 프로세스에 사용되는 기본 차원 중 하나입니다. 시나리오 및 버전 차원과 함께 엔티티 차원은 사용자 피어가 승인 또는 검토를 위해 승격하거나 강등할 수 있는 불연속적인 구성요소인 승인 단위를 정의하는 데 사용됩니다.

승인 단위 외부의 모든 차원 멤버는 승인 단위 자체와 함께 승격 및 강등됩니다. 예를 들어 승인 단위를 승격하면 12개월 모두 승격됩니다. 개별 월을 개별적으로 승격할 수 없습니다.

각 차원이 로드 또는 업데이트된 후 애플리케이션을 새로고치는 것이 모범 사례입니다.

계정 차원 계획

계정 차원은 계정 차트가 있는 곳입니다. 계획 또는 예측하는 멤버를 포함해야 합니다. 모든 계정을 차트에 포함할 필요는 없습니다.

예를 들어 계정 차원에는 손익계산서, 대차대조표, 현금 흐름 계정이 포함될 수 있습니다. 또는 KPI 및 비율 계정을 포함할 수 있습니다. 경우에 따라 계정에 하위 계정이 있을 수도 있지만 일반적이지는 않습니다.

계정 차원에는 Financial Intelligence가 포함됩니다. 다음과 같은 계정 유형이 지원됩니다.

비용: 비즈니스 수행 비용
수익: 수익 소스
자산: 회사 리소스
부채 및 자기자본: 채권자에 대한 잔존 이자 또는 부채
저장된 가정: 애플리케이션 간에 일관성을 보장하는 중앙 집중화된 계획 가정

계정 유형 설정은 분기별 및 연도별 총계 값 보고 및 차이 분석에 사용됩니다.

Planning은 계층을 사용하여 계정 그룹화 소계 및 총계를 생성합니다. 각 계정 그룹에 해당 상위로 롤업되는 방식을 결정하는 통합 연산자가 지정됩니다.

예:

순이익 = 총 수익 - 총 비용

이 예에서 총 수익에 대한 통합 연산자는 더하기이고, 총 비용에 대한 통합 연산자는 빼기입니다.

데이터를 로드하거나 Smart View를 사용하여 계정 차원을 채울 수 있습니다. 파일에서 데이터를 로드하려면 파일 형식이 특정 요구 사항을 충족해야 합니다.

각 차원이 로드 또는 업데이트된 후 애플리케이션을 새로고치는 것이 모범 사례입니다.

모범 사례:

상위 레벨 멤버를 동적 계산으로 설정해야 합니다.
비율 및 다른 유형의 KPI 또는 비율 계산에 사용되는 멤버 공식의 경우 동적 계산, 2단계로 설정합니다. 2단계 설정은 상위 레벨에서 퍼센트를 올바르게 계산합니다.

버전 차원 계획

버전을 사용하여 계획 프로세스의 여러 반복을 보존할 수 있습니다. 버전은 읽기 또는 쓰기에 대한 데이터 액세스를 제어하는 데에도 유용합니다.

다음 두 가지 유형의 버전을 사용할 수 있습니다.

표준 타겟: 상위 레벨에 입력 데이터를 입력할 수 있습니다.
표준 상향식: 레벨 0에만 입력 데이터를 입력할 수 있습니다.

승인 및 워크플로우 기능은 상향식 버전에 대해서만 사용으로 설정할 수 있습니다.

모범 사례로 다음 버전이 권장됩니다.

작업 중: 사용자가 실제 결과 검토, 계획 및 예측 개발 등의 태스크를 수행합니다.
일차 통과: 계획의 여러 반복을 유지관리하려는 경우 이 버전에 통과를 보존할 수 있습니다. 저장된 반복이 둘 이상 필요한 경우 다른 멤버를 생성할 수 있습니다. 데이터 복사 기능을 활용하여 데이터를 이 버전으로 이동할 수 있습니다. 데이터 복사는 데이터와 텍스트 입력을 복사합니다.
What If: 사용자가 가정을 변경하고 결과를 분석할 수 있는 자리표시자를 제공합니다.

빌드 프로세스에서 각 차원이 로드 또는 업데이트된 후 애플리케이션을 새로고치는 것이 모범 사례입니다.

통화 차원 계획

애플리케이션에 대해 여러 통화를 사용으로 설정한 경우 계획 및 보고에 사용하는 통화를 추가할 수 있습니다.

그런 다음 변환에 사용할 시나리오 및 연도별 환율을 정의할 수 있습니다. 통화 변환을 수행할 수 있게 하는 계산 스크립트가 생성됩니다. 환율을 입력하려면 Planning 관리의 환율 지정에 있는 프로세스를 따릅니다.

모범 사례:

보고 통화 수를 제한합니다. 일반적으로 고객마다 하나의 통화만 있습니다.
적합한 시나리오 및 연도의 각 조합에 대한 환율을 입력합니다.
지금부터 기본적으로 각 양식과 연계된 통화 계산 비즈니스 규칙을 실행하여 통화 변환을 계산할 수 있습니다.
계정의 환율 유형이 수정됩니다(예: 기말에서 평균으로 수정).

다음 전에 통화 변환 계산 스크립트를 실행합니다.

보고 통화로 업데이트된 로컬 데이터 검토
보고 통화 데이터에 종속될 수 있는 특정 계산 실행

환율 계획

각 애플리케이션에는 애플리케이션을 생성할 때 지정된 기본 통화가 있습니다. 환율 테이블을 설정할 때 모든 소스 통화에서 기본 통화로의 환율을 입력합니다. 삼각 분할은 다른 모든 보고 통화로 변환하는 데 사용됩니다.

환율은 시나리오, 연도별로 평균 및 종료 환율에 대해 설정됩니다.

기간 차원 계획

기간 차원을 사용하여 지정된 연도 내의 달력 범위(예: 월별)를 설정합니다.

모범 사례:

이 차원에서 보고 및 계산을 지원하려면 대체 변수를 사용합니다. 잠재적 대체 변수는 CurrMo, CurrQtr 및 PriorMo입니다. 이러한 변수는 월별로 업데이트해야 합니다.
연간 누계(Y-T-D) 또는 분기 누계 등의 기간 계산을 사용하려면 기간 차원에서 동적 시계열 아이콘을 선택합니다. 그런 다음 프로세스를 지원하는 데 필요한 기간 계산을 선택할 수 있습니다.
계산 시간을 줄이려면 분기 총계, 연도 총계 등의 요약 기간을 동적 계산으로 설정해야 합니다.
각 차원이 로드 또는 업데이트된 후 애플리케이션을 새로고침합니다.

연도 및 대체 변수 계획

연도는 양식, 계산, 보고서, Smart View 등 애플리케이션의 여러 위치에 통합되어 있습니다. 향후 몇 년간 애플리케이션을 사용할 것이므로 이 차원을 참조하는 모범 사례는 대체 변수를 사용하는 것입니다.

대체 변수는 정기적으로 바뀌는 정보에 대한 글로벌 자리 표시자로 동작합니다. 변수와 값은 연도에 해당하며, 언제든지 값을 변경할 수 있습니다.

대체 변수의 값은 양식과 보고서에 위치 표시자로 표시됩니다. 이렇게 하면 애플리케이션의 유지관리가 줄어듭니다.

모범 사례로, 프로세스에 포함된 각 연도에 대한 대체 변수를 생성합니다. 예를 들면 다음과 같습니다.

CurrY, 현재 연도
NextYr, 예산(계획) 연도
PriorYr, 이전 연도

사용자정의 차원 디자인

사용자정의 차원을 사용하여 데이터를 추가로 분류할 수 있습니다. 예를 들어 사용자정의 차원에는 제품 또는 시장이 포함될 수 있습니다.

세대 레벨이라고도 하는 차원 레벨에서 액세스 권한을 부여할 수는 없는 점에 유의하십시오. 예를 들어 모든 하위의 제품 멤버에 대한 액세스 권한을 직접 지정할 수 없습니다. 사용자정의 차원에 대해 보안을 사용으로 설정하는 경우 보안 액세스 권한 지정을 고려하여 보안을 적용할 모든 사용자정의 차원에 대해 세대 2를 디자인하는 것이 좋습니다.

각 차원이 로드 또는 업데이트된 후 애플리케이션을 새로 고치는 것이 모범 사례입니다.

추가 모범 사례

차원을 추가 또는 업데이트한 후 다음 태스크를 완료합니다.

애플리케이션을 새로고침합니다.
애플리케이션 구조를 변경할 때마다 애플리케이션을 새로고쳐야 합니다.

애플리케이션에 대한 변경사항은 애플리케이션을 새로고칠 때까지 데이터 입력 및 승인 태스크를 수행하는 사용자에게 반영되지 않습니다.

예를 들어 엔티티 멤버의 등록정보를 수정하거나 시나리오를 추가하거나 액세스 권한을 변경하는 경우 이러한 변경사항은 애플리케이션을 새로 고친 후에 사용자에게 반영됩니다.
과거 데이터를 로드합니다.
계정, 엔티티 등의 모든 구조를 로드한 후 과거 데이터를 로드할 수 있습니다. 여기에는 이전 연도의 실제 결과와 현재 연도의 계획 및 예산 데이터가 포함될 수 있습니다.

과거 데이터를 로드하면 사용자가 결과를 분석하고, 추세를 검토하며, 의미 있는 비교를 할 수 있습니다.

또한 애플리케이션에 빌드한 구조를 확인하는 데 도움이 됩니다. 예를 들어 데이터가 이전에 생성한 보고서에 연결되는지 확인할 수 있습니다. 데이터가 조정되지 않는 경우 데이터 이슈로 인한 것인지 또는 구조 이슈가 있는지 확인해야 합니다.

애플리케이션에서 통합 데이터를 보려면 집계 규칙을 생성합니다.
적합한 교차점을 계획합니다.
적합한 교차점을 사용하면 서비스 관리자가 적합한 교차점 규칙이라는 규칙을 정의할 수 있습니다. 이 규칙은 사용자가 데이터를 입력하거나 런타임 프롬프트를 선택할 때 차원 교차점을 필터링합니다. 예를 들어 특정 프로그램이 특정 부서에만 적합하도록 지정할 수 있습니다. 적합한 교차점을 활용하여 데이터 입력을 적합한 교차점에 대해서만 제어합니다.

양식을 디자인하는 동안 적합한 교차점에 대한 다음 사항에 유의합니다.
- 적합한 교차점이 있는 차원이 페이지에 있으면 멤버 선택기에서 적합한 조합을 통해서만 사용자에게 제공됩니다.
- 적합한 교차점이 사용된 차원이 열 또는 행에 있는 경우 양식 디자이너가 적합한 교차점을 완전히 숨길 수 있습니다. 숨김 옵션을 선택하지 않은 경우 부적합한 교차가 읽기 전용으로 설정됩니다.