중요한 구현 고려 사항

계획 시 고려하는 대부분의 사항은 Microsoft Office PerformancePoint Server 2007 응용 프로그램을 하나 작성할 것인지 여러 개 작성할 것인지에 대한 결정에 영향을 줍니다. 기본적으로 고려해야 할 사항은 공유할 메타데이터와 비즈니스 개체 정의의 양입니다. 응용 프로그램이 여러 개이면 확장성과 융통성은 향상되지만 각 응용 프로그램이 데이터에 대한 별개의 컨테이너로 간주될 수 있고 여러 응용 프로그램에 걸쳐 데이터를 공유할 수 없습니다.

PerformancePoint Server에서는 응용 프로그램당 하나의 일정만 허용되므로 회사에서 진행 중인 여러 비즈니스의 일정이 서로 다른 경우 이러한 조직 구조에 맞게 두 개의 응용 프로그램을 만들어야 합니다. 그러므로 응용 프로그램 일정이 업무 프로세스에 정확하게 일치하는지 확인해야 합니다. 일정을 수정할 수는 없으므로 새 응용 프로그램을 만들어야 합니다.

응용 프로그램의 모델 사이트를 계획할 때는 조직에서 프로세스와 데이터를 중앙 집중화했는지와 조직 내에 비즈니스 유형이 매우 다른 부서가 여러 개 있는지 여부를 확인해야 합니다.

조직이 중앙 집중화되어 있는 경우 여러 개의 모델 사이트가 필요 없을 수 있습니다. 조직이 분산되어 있지만 프로세스가 일관되고 본사에 보고되는 데이터가 비즈니스 유형을 불문하고 표준화되어 있는 경우 회사 수준에서 데이터를 요약하는 여러 개의 모델 사이트를 만들 수 있습니다.

그러나 조직이 중앙 집중화되어 있지 않고 부서 간에 데이터가 일관되지 않을 경우 조직 내의 서로 다른 부분에 대해 별도의 모델 구조가 필요할 수 있습니다. 이를 위해 응용 프로그램을 여러 개 만들어야 할 수 있습니다.

부서 또는 사업부 모델 사이트와 회사 루트 모델 사이트를 분리하면 사용자와 역할을 기반으로 데이터에 액세스할 수도 있습니다. 이는 계획 프로세스에 사용된 가정 모델에 대한 회사의 제어 권한을 유지하는 데 중요합니다.

보안 고려 사항도 사이트 계획 결정에 영향을 줄 수 있습니다. 모델러 역할의 구성원에게 다양한 사용 권한을 지정하려면 모델 하위 사이트를 만들고 모델 사이트 수준에서 사용 권한을 설정합니다.

또한 다음과 같은 몇 가지 사항도 고려해야 합니다.

• 서로 다른 프로젝트 일정: 계획, 예산 작성, 예측, 실제 작업 등을 수행하는 담당자의 일정표가 서로 다르면 단일 응용 프로그램에서 프로젝트를 초기 구현하기가 어렵습니다.

• 소규모의 초기 구현: 구현 시작 시에는 여러 응용 프로그램을 사용하고 장기적으로는 대규모의 단일 응용 프로그램으로 마이그레이션하는 방식을 사용하는 것이 가장 적절할 수 있습니다. 이 방법을 사용하면 업무 팀 간의 조정 작업이 줄어들고 각 팀에서 서로 다른 별도의 일정을 사용할 수 있습니다.

• 서로 다른 지역적 요구 사항: 원격 사이트 또는 지사에서 사이트 또는 작업 관련 항목을 추적하려는 경우 해당 원격 위치에 대해 하위 사이트를 사용할 수 있습니다. 이렇게 하면 지사에서 공유된 데이터를 사용하면서도 사용자 지정 작업을 수행할 수 있습니다.

• 여러 지역의 작업 처리: 계획 서버는 중앙 위치(예: 본사)에 설치하고 원격 사용자가 원격으로 연결하도록 할 수도 있지만, 원격 위치에 대해 하위 사이트를 만들 수도 있습니다. 그러면 원격 사이트에서는 PerformancePoint Server의 데이터 통합 기능을 사용하여 주기적으로 데이터를 본사로 옮길 수 있습니다. 이때 하위 사이트에서는 회사의 사이트 요구 사항이 준수되고 있는지를 확인합니다.

• 확장성: 모든 사용자가 같은 응용 프로그램을 공유하는 경우에는 프로젝트 계획 단계에서 확장성을 중요하게 고려해야 합니다.

PerformancePoint Server 응용 프로그램에서 모델을 만들 때는 다섯 가지 모델 유형, 즉 전역 가정 모델, 환율 모델, 지분 계산 포함 재무 모델, 지분 계산 제외 재무 모델 및 일반 모델의 5가지 모델 유형 중에서 선택할 수 있습니다.

응용 프로그램에 포함할 모델 유형을 결정할 때의 주요 고려 사항은 모델과 해당 데이터의 사용 방법입니다. 예를 들어 비즈니스 모델을 만들지 또는 가정 모델을 만들지를 고려해야 합니다. 또한 최종 사용자마다 다른 수준의 데이터를 원하므로 초기 계획에 광범위한 사용자를 포함하는 것이 중요합니다.

예를 들어 보고서에 표시할 데이터는 재무 보고에만 사용되는 데이터와 다르게 모델링해야 합니다. 재무 보고에 주로 사용되는 모델은 판매원 데이터를 포함하지 않거나 판매원 수준 보고에 적합한 수준이 아닐 수 있지만 이 데이터는 판매 성과 기록표에 꼭 필요합니다. 이 시나리오에서는 재무 보고를 위해 요약할 수 있는 자세한 판매 데이터를 제공하도록 모델을 디자인할 수 있습니다.

또한 지정된 유형의 모델을 하나 만들거나 동일한 유형의 모델을 각각 다른 용도로 여러 개 만들 수 있으므로 이 방법을 위 시나리오에 대한 대체 솔루션으로 사용할 수 있습니다.

모델 유형

PerformancePoint 계획에서는 미리 정의된 차원과 사용자 정의 차원이라는 두 가지 범주의 차원을 제공합니다. 미리 정의된 차원을 생성된 그대로 사용할 수도 있지만 대개 현재 데이터 구조와 명명 규칙에 맞게 일부 수정해야 합니다. 미리 정의된 차원을 사용자 지정할 수 있는 범위는 사용자 정의 차원에 비해 더 제한적입니다.

응용 프로그램을 계획할 때는 각 차원에 포함할 차원 구성원 수를 고려하는 것도 중요합니다. 많은 차원 구성원이 포함될 차원에 대해서는 응용 프로그램 성능 향상에 도움이 되도록 추가 차원 구성원 집합을 만들어 모델당 계정 수를 제한할 수 있습니다.

PerformancePoint 계획에서 비즈니스 계산은 서버 쪽 계산 또는 클라이언트 쪽 계산을 사용하여 수행할 수 있습니다. 계획 서버에서 서버 쪽 계산은 비즈니스 규칙으로 표시됩니다. 이러한 비즈니스 규칙은 PEL(PerformancePoint 표현 언어)을 사용하여 사용자가 수행하려는 계산을 표시합니다. 클라이언트 쪽 계산은 Excel용 PerformancePoint 추가 기능에 포함된 계산 기능을 사용하여 수행합니다.

서버 쪽 계산

클라이언트 쪽 계산

계획에서는 성능 결과를 예측하는 데 Analysis Services의 "쓰기 저장" 기능을 사용합니다. 제안된 성능 결과가 만족스럽지 못한 경우에는 로컬 할당을 사용하여 SSAS 서버에 대한 부하를 줄이는 것이 좋습니다. 자세한 내용은 다음 단원인 "로컬 큐브(오프라인 할당)"을 참조하십시오.

사용자가 데이터 입력 작업을 수행할 때 온라인, 오프라인 또는 둘을 혼용한 모드로 작업하도록 PerformancePoint 계획을 구성할 수 있습니다. 이때 모델 수준별로 또는 사용자 수준별로 구성할 수 있습니다.

계획 모델러는 Planning Business Modeler에서 "AllowOffline" 모델 플래그를 설정하여 대규모 모델이나 중요한 데이터를 포함하는 모델에 대해 오프라인 캐싱을 사용하도록 설정할 수 있습니다.

계획 참가자는 Excel용 PerformancePoint 추가 기능에서 "할당 자동 캐시" 옵션을 설정하여 런타임 환경에서 오프라인 캐시를 설정하거나 해제할 수 있습니다. 기본적으로는 두 옵션 모두 설정되어 있습니다.

온라인 모드: 두 옵션 중 하나가 "끄기"로 설정되면 계획 사용자는 온라인 모드에서 작업하게 되며 데이터가 사용자 컴퓨터로 다운로드되지 않습니다.

로컬 모드: 두 옵션이 모두 "켜기"로 설정되면 데이터가 사용자 컴퓨터로 다운로드된 후에 계획 사용자는 자동으로 로컬 모드(혼합 모드)로 전환됩니다. 이 경우 계산은 로컬 컴퓨터에 캐시된 정보를 기반으로 하기 때문에 온라인 모드보다 계산 속도가 빠를 수 있습니다.

오프라인 모드: 데이터가 사용자 컴퓨터로 다운로드되고 나면 사용자는 완전히 오프라인 상태로 작업할 것인지, 즉 계획 서버에 대한 활성 연결을 사용하지 않을 것인지를 선택할 수 있습니다. 다음과 같은 경우에는 이 모드를 사용하십시오.

• 현재 사무실에 있지 않으며 계획 서버를 실행 중인 컴퓨터에 연결할 수 없는 경우

• 유지 관리 작업으로 인해 계획 서버를 실행 중인 컴퓨터를 사용할 수 없는 경우

• 사용자가 온라인 상태로 다시 전환하여 양식을 제출하기 전까지는 변경 내용이 계획 서버 데이터베이스에 저장되지 않습니다.

하위 큐브

계획 서버는 완벽한 ETL(추출, 변환 및 로드) 프로세스가 아니므로 여러 데이터 원본에서 데이터를 추출, 변환 및 로드하기 위한 작업을 구성하는 데 사용할 수 없습니다.

데이터 원본 및 계획 모델에 대한 원본 데이터 매핑을 정의해야 하고, 차원 및 구성원 유형이 계획 유형과 일치해야 합니다(예: 계정 구성원의 계정 유형을 매핑해야 함). 또한 변환이 가능한지 확인하고 ETL 프로세스 담당자 및 데이터 이동 일정을 정의해야 합니다.

데이터 통합 과정에서는 다음과 같은 몇 가지 단계를 수행해야 합니다.

• 계획 준비 데이터베이스를 만들어야 합니다. 이 단계는 한 번만 수행합니다.

• 계획 준비 데이터베이스를 PerformancePoint 계획과 동기화해야 합니다. 이 단계는 구조가 변경될 때마다 수행해야 합니다.

• 외부 ETL 도구를 사용하여 데이터를 데이터 원본에서 계획 준비 데이터베이스로 로드해야 합니다.

• 참조(차원 및 계층 구조) 데이터 및 팩트 데이터 유효성을 검사해야 하며 오류를 수정해야 합니다.

• 데이터는 계획 준비 데이터베이스에서 계획 응용 프로그램 데이터베이스로 로드됩니다.

이 프로세스는 PPSCmd 및 스크립트를 사용하여 자동화할 수 있습니다.

계획에는 계정에 대한 데이터가 차변 및 대변으로 기본 저장됩니다. 예를 들어 대변 잔액이 있는 대변 계정은 양수 값으로 저장되고 차변 잔액이 있는 대변 계정은 음수 값으로 저장됩니다. 그리고 차변 잔액이 있는 차변 계정은 양수 값으로 저장되고 대변 잔액이 있는 차변 계정은 음수 값으로 저장됩니다.

즉, 원본 시스템에 해당 유형에 따라 기호를 적용하여 데이터를 저장하는 경우 데이터를 로드하기 전에 이러한 계정의 기호를 변경해야 합니다. 계획 데이터 통합에서는 데이터 로드 시 이를 처리하는 기능을 제공하지만 음수로 저장된 대변 유형 원본 계정만을 처리합니다. 시스템에서 다른 규칙을 사용하는 경우에는 원본 시스템에서 계획 준비 데이터베이스로 데이터를 전송하는 데 사용되는 ETL 프로세스가 기호 변경을 처리해야 합니다.

데이터 로드 프로세스를 잘못 계획할 경우 모델, 차원 및 관련 구성원 집합 사이에서 데이터가 제대로 조정되지 않을 수 있기 때문에 데이터 로드 프로세스를 계획할 때는 주의를 기울여야 합니다.

데이터 로드와 관련한 주요 고려 사항으로는 데이터 로드 빈도, 전체 데이터 로드를 수행할지 또는 증분 데이터 로드를 수행할지 여부, 포함되는 데이터의 양, 성능 등이 있습니다.

또한 데이터 로드 시기 및 빈도와 이러한 프로세스를 담당할 사용자를 고려할 수 있습니다. 다중 사이트/다중 모델 구현의 경우에는 이러한 사항이 중요합니다.

업무 프로세스가 진행되는 동안 데이터 참가자, 검토자 및 승인자의 공동 작업을 조정하기 위해 계획 서버에서는 프로세스 주기와 데이터 입력 양식을 사용합니다. 프로세스 관리는 Planning Business Modeler를 통해 수행되는 반면 양식 작성 및 데이터 제출은 Excel용 PerformancePoint 추가 기능을 통해 수행됩니다.

데이터 공동 작업 계획에는 시스템/워크플로 계획과 함께 업무/프로세스 계획 시 고려 사항이 포함됩니다.

시스템 고려 사항 및 워크플로

업무 및 프로세스 계획 시 고려 사항

계획 서버의 보안 모델은 역할을 기반으로 합니다. 사용자가 역할에 할당되면 역할에 따라 계획 서버 시스템에서 해당 사용자의 권한 수준이 결정됩니다. 여기에는 관리 역할 및 비즈니스 역할의 두 가지 역할 유형이 사용됩니다.

비즈니스 역할

관리 역할

배포 계정

• 구성원 집합과 구성원 뷰의 성능 관련 사항: Analysis Services에서 구성원 집합은 부모-자식 계층 구조로 변환되며 구성원 뷰는 수준별 계층 구조로 변환됩니다. Analysis Services에서는 구성원을 미리 집계하기 때문에 부모-자식 계층 구조보다 수준별 계층 구조가 더 효율적으로 처리됩니다. 그러므로 구성원 집합이 매우 크거나 수준이 매우 많은 경우에는 성능 문제가 발생할 수 있습니다. 이러한 경우에는 보고서를 디자인할 때 구성원 뷰 사용을 고려해야 합니다.

• Analysis Services: Analysis Services로 인해 성능 병목 현상이 발생하는 경우 SQL Server 2005 Analysis Services Performance Guide(https://go.microsoft.com/fwlink/?LinkId=103090&clcid=0x412)에서 SSAS 서버를 클러스터링하는 방법에 대한 지침을 참조하십시오.

• 계층 구조: 시간에 따라 변경되거나 재작업되는 계층 구조가 있는 경우에는 여러 구성원 집합을 만들어 서로 다른 모델에 사용할 수 있습니다.

PPSCMD

클라이언트 쪽 매크로

Analysis Services의 사용자 지정

사용자 지정 SQL 저장 프로시저 및 MDX 스크립트(네이티브 규칙)

샘플 응용 프로그램