Power BI 구현 계획: BI 솔루션 계획

이 문서는 BI(비즈니스 인텔리전스) 전략을 지원하는 솔루션을 계획하는 데 도움이 됩니다. 주로 다음을 대상으로 합니다.

• BI 및 분석 책임자 또는 관리자: BI 프로그램과 전략적으로 중요한 BI 솔루션을 감독하는 의사 결정자입니다.
• COE(최고 전문가 조직), IT 및 BI 팀: 조직을 위한 엔터프라이즈 BI 솔루션을 설계하고 배포하는 팀입니다.
• SME(실무 전문가), 콘텐츠 소유자 및 작성자: 부서 내 분석을 주도하고 셀프 서비스, 부서별 BI 또는 팀 BI 사용 시나리오를 위한 솔루션을 디자인 및 배포하는 팀과 구성원입니다.

BI 전략은 데이터와 분석을 구현, 사용, 관리하기 위한 계획입니다. BI 전략 계획부터 시작하여 BI 전략을 정의합니다. 전략적 계획을 사용하면 BI 주요 분야와 목표를 식별하는 데 도움이 됩니다. BI 목표를 향한 경로를 결정하기 위해 전술적 계획을 사용하여 구체적인 주요 결과를 설명합니다. 그런 다음 BI 솔루션을 계획하고 배포하여 이러한 주요 결과를 달성하는 데 진전을 이룹니다.

BI 솔루션을 계획하고 구현하는 방법에는 여러 가지가 있습니다. 이 문서에서는 BI 전략을 지원하는 BI 솔루션을 계획하고 구현하기 위해 취할 수 있는 한 가지 방식을 설명합니다.

다음 개략적인 다이어그램은 BI 솔루션 계획을 수행하는 방법을 보여 줍니다.

BI 솔루션 계획을 수행하려면 다음 단계를 수행합니다.

자세한 내용은 Power BI 마이그레이션 시리즈를 참조하세요. 이 시리즈는 마이그레이션에 관한 것이지만 주요 작업과 고려 사항은 솔루션 계획과 관련이 있습니다.

1단계: 요구 사항 수집

먼저 요구 사항을 수집하고 솔루션 디자인을 정의하여 솔루션 계획을 시작합니다.

참고: 전략 계획 및 전술 계획은 이니셔티브를 이끄는 작업팀이 주도합니다. 반면, 솔루션 계획은 콘텐츠 소유자와 작성자로 구성된 프로젝트 팀이 주도합니다.

성공적인 솔루션 배포 및 채택을 위해서는 올바른 요구 사항을 수집해야 합니다. 요구 사항을 수집하는 효과적인 방법은 올바른 관련자를 식별하여 참여시키고, 해결해야 할 문제를 공동으로 정의하고, 문제에 대한 공유된 이해를 활용하여 솔루션 디자인을 만드는 것입니다.

요구 사항을 수집하기 위해 협업적 방식을 사용하면 몇 가지 이점이 있습니다.

• 사용자 입력으로 더욱 유용한 디자인 생성: 사용자를 집중 토론에 참여시켜 요구 사항을 수집함으로써 비즈니스 데이터 요구 사항을 보다 효과적으로 캡처할 수 있습니다. 예를 들어, 사용자는 콘텐츠 작성자에게 기존 솔루션을 사용하는 방법을 보여 주고 이러한 솔루션의 인지된 효과에 대한 피드백을 제공할 수 있습니다.
• 가정 방지 및 변경 요청 완화: 사용자와의 토론을 통해 종종 미묘한 차이, 예외 및 숨겨진 복잡성이 드러납니다. 이러한 인사이트는 처리 비용이 많이 들 수 있는 후기 스테이지 요청의 가능성을 줄여줍니다.
• 사용자 온보딩으로 솔루션 채택 증가: 디자인 및 초기 개발에 사용자를 참여시킴으로써 최종 결과에 영향을 미칠 수 있는 기회를 제공할 수 있습니다. 사용자는 참여함으로써 솔루션에 대한 지적 소유권과 책임감을 갖게 될 수도 있습니다. 참여도가 높은 사용자는 솔루션을 지지하고 솔루션을 효과적으로 사용하는 데 있어 실천 커뮤니티를 이끌 가능성이 더 높습니다.
• 디자인을 통해 관련자와 비즈니스 사용자의 예상 결과치 설정: 솔루션 디자인의 모형이나 일러스트레이션을 제작하여 관련자에게 솔루션이 제공할 내용을 명확하게 보여줄 수 있습니다. 또한 예상되는 프로젝트 결과에 대한 상호 이해를 형성하는 데 도움이 됩니다. 이 프로세스는 디자인 사고라고도 하며 복잡한 문제에 접근하고 이해하는 효과적인 방법이 될 수 있습니다.

사용자의 참여를 유도하고 요구 사항을 수집하기 위해 다양한 방식을 사용할 수 있습니다. 예를 들어, 비즈니스 디자인 및 기술 디자인을 통해 요구 사항을 수집할 수 있습니다(자세한 내용은 이 문서의 후반부 섹션에서 설명).

비즈니스 디자인은 비즈니스 요구 사항을 수집하는 방식입니다. 이는 솔루션을 공동으로 설계하기 위해 비즈니스 디자인 세션에 비즈니스 사용자를 참여시키는 데 중점을 둡니다. 비즈니스 디자인의 결과물은 솔루션 모형과 자세하게 설명하는 디자인 설명서로 구성됩니다.

기술 디자인 방식을 통해 비즈니스 요구 사항을 기술 요구 사항으로 변환하고 디자인 가정을 해결할 수 있습니다. 기술 디자인은 비즈니스 디자인의 유효성을 검사하고 사용할 기술적 방식을 정의하는 데 중점을 둡니다. 디자인의 유효성을 검사하기 위해 콘텐츠 작성자는 필요에 따라 일반적으로 기술 디자인 세션이라는 집중 토론을 통해 기술 전문가와 협력합니다.

솔루션 계획 준비

먼저 다음 섹션에 설명된 요소를 고려하여 솔루션 계획을 준비해야 합니다.

• 솔루션 계획을 수행할 사람 식별: BI 전술 계획의 일환으로 작업팀은 우선 순위가 지정된 솔루션 백로그를 만들었습니다. 솔루션 계획에서 프로젝트 팀은 백로그에서 하나 이상의 솔루션을 디자인, 개발 및 배포하는 일을 담당합니다. 백로그의 각 솔루션에 대해 솔루션을 담당할 프로젝트 팀을 구성해야 합니다. BI 솔루션 계획을 실행하는 것 외에도 프로젝트 팀은 다음을 수행해야 합니다.
  • 솔루션 계획을 위한 타임라인과 마일스톤을 정의합니다.
  • 요구 사항 수집에 적합한 관련자를 식별하고 참여시킵니다.
  • 커뮤니케이션, 문서화, 계획을 위한 중앙 위치를 설정합니다.
  • 요구 사항을 수집하기 위해 관련자를 참여시킵니다.
  • 관련자 및 비즈니스 사용자와 소통하고 조정합니다.
  • 비즈니스 사용자와 함께 반복 개발 및 테스트 주기를 오케스트레이션합니다.
  • 솔루션을 문서화합니다.
  • 학습 계획을 정의하고 실행하여 사용자를 솔루션에 온보딩합니다.
  • 배포 후 솔루션 지원을 제공합니다.
  • 배포 후 솔루션을 변경하거나 업데이트하라는 합리적인 사용자 요청을 처리합니다.
  • 필요한 경우 배포 후 솔루션 핸드오버를 수행합니다.
• 커뮤니케이션 및 설명서 중앙 집중화: 프로젝트 팀이 BI 솔루션 계획을 위한 커뮤니케이션 및 설명서를 중앙 집중화해야 합니다. 예를 들어, 프로젝트 팀은 요구 사항, 관련자 커뮤니케이션, 타임라인 및 결과물을 중앙 집중화해야 합니다. 모든 설명서를 중앙 집중식 포털에 저장하는 것을 고려해 보세요.
• 요구 사항 수집 계획: 프로젝트 팀은 비즈니스 요구 사항을 수집하기 위한 비즈니스 디자인 세션을 계획하는 것부터 시작해야 합니다. 이러한 세션은 대화형 모임 형식을 취하며 전략 계획 워크샵과 유사한 형식을 따를 수 있습니다.

비즈니스 요구 사항 수집

올바른 비즈니스 요구 사항을 수집하는 것은 올바른 솔루션을 설계하는 데 중요합니다. 올바른 요구 사항을 수집하고 효과적인 솔루션 디자인을 정의하기 위해 프로젝트 팀은 비즈니스 사용자와 함께 비즈니스 디자인 세션을 수행할 수 있습니다.

비즈니스 디자인 세션의 목적은 다음과 같습니다.

• 초기 솔루션 범위를 확인합니다.
• 솔루션이 해결해야 하는 문제를 정의하고 이해합니다.
• 솔루션에 적합한 주요 관련자를 식별합니다.
• 올바른 비즈니스 요구 사항을 수집합니다.
• 비즈니스 요구 사항을 충족하는 솔루션 디자인을 준비합니다.
• 지원 디자인 설명서를 준비합니다.

다음 다이어그램은 비즈니스 디자인 방식을 사용하여 비즈니스 요구 사항을 수집하고 솔루션 디자인을 정의하는 방법을 보여 줍니다.

다이어그램에서는 다음 단계를 보여 줍니다.

Item	설명
	프로젝트 팀은 전술 계획에서 처음 문서화한 솔루션 범위를 확인하는 것부터 비즈니스 디자인을 시작합니다. 솔루션이 포함하는 비즈니스 영역, 시스템, 데이터를 명확히 해야 합니다.
	프로젝트 팀은 비즈니스 디자인 세션에 참여할 사용자 커뮤니티의 주요 관련자를 식별합니다. 주요 관련자는 솔루션의 주체 영역을 대표할 만큼 충분한 지식과 신뢰성을 갖춘 사용자입니다.
	프로젝트 팀은 비즈니스 디자인 세션을 계획합니다. 계획에는 관련자에게 알리고, 모임을 조직하고, 결과물을 준비하고, 비즈니스 사용자와 소통하는 활동이 포함됩니다.
	프로젝트 팀은 비즈니스 사용자가 현재 기존 비즈니스 데이터 요구 사항을 해결하기 위해 사용하는 기존 솔루션을 수집하고 연구합니다. 이 프로세스를 가속화하기 위해 프로젝트 팀은 커뮤니케이션 허브에 문서화된 BI 전략 계획의 관련 연구를 사용할 수 있습니다.
	프로젝트 팀은 관련자들과 함께 비즈니스 디자인 세션을 진행합니다. 이러한 세션은 프로젝트 팀이 관련자에게 비즈니스 데이터 요구 사항과 요구 사항을 이해하도록 안내하는 소규모 대화형 모임입니다.
	프로젝트 팀은 피드백과 승인을 위해 관련자와 다른 사용자에게 초안 솔루션 디자인을 제시함으로써 비즈니스 디자인을 마무리합니다. 비즈니스 디자인은 관련자가 디자인이 비즈니스 목표 달성에 도움이 될 것이라는 데 동의할 때 성공합니다.

비즈니스 디자인은 다음 결과물로 마무리됩니다.

• 초안 솔루션 디자인: 모형, 프로토타입 또는 와이어프레임 다이어그램은 솔루션 디자인을 보여 줍니다. 이러한 문서에서는 요구 사항을 구체적인 디자인 청사진으로 변환합니다.
• 비즈니스 메트릭 목록: 비즈니스 정의 및 예상 집계를 포함하여 솔루션에서 예상되는 정량적 필드입니다. 가능하다면 사용자에게 중요도에 따라 순위를 매기세요.
• 비즈니스 특성 목록: 비즈니스 정의 및 특성 이름을 포함하여 솔루션에서 예상되는 관련 특성 및 데이터 구조입니다. 가능하다면 계층 구조를 포함하고 사용자에게 중요도에 따라 특성의 순위를 매기세요.
• 보충 설명서: 주요 기능 또는 규정 준수 요구 사항에 대한 설명입니다. 이 설명서는 필요한 만큼 정확하면서도 최대한 간결해야 합니다.

비즈니스 디자인 결과물은 기술 디자인에 사용되며 이를 통해 유효성이 검사됩니다.

기술 요구 사항 수집

비즈니스 디자인을 완료한 후 프로젝트 팀은 기술 디자인을 사용하여 결과의 유효성을 검사합니다. 기술 디자인은 비즈니스 디자인과 유사한 방식입니다. 비즈니스 디자인은 비즈니스 데이터 요구 사항에 중점을 두는 반면, 기술 디자인은 솔루션의 기술적인 측면에 중점을 둡니다. 기술 디자인의 주요 결과는 최종 솔루션 디자인과 이를 구현하기 위한 활동에 대한 정보에 근거한 예상 비용을 설명하는 솔루션 계획입니다.

기술 디자인의 목적은 다음과 같습니다.

• 비즈니스 디자인 결과의 유효성을 검사합니다.
• 현재 디자인의 기술적 가정을 해결합니다.
• 범위 내에서 관련 데이터 원본을 식별하고 각 데이터 원본에 대한 필드 계산 및 필드-원본 매핑을 정의합니다.
• 비즈니스 요구 사항을 기술 요구 사항으로 변환합니다.
• 구현에 필요한 활동을 예측합니다.

프로젝트 팀은 제한적이고 집중적인 기술 디자인 세션을 통해 기술 관련자 또는 기능 관련자를 참여시킵니다. 이 세션은 기술 요구 사항을 수집하기 위해 기능 관련자와의 대화형 모임입니다. 관련자는 솔루션이 효과적으로 작동하는 데 필요한 특정 기능 영역을 담당합니다.

기술 디자인의 관련자의 예는 다음과 같습니다.

• 보안 및 네트워킹 팀: 데이터 보안 및 규정 준수를 담당합니다.
• 기능 팀 및 데이터 관리자: 원본 데이터 큐레이팅을 담당합니다.
• 설계자: 특정 플랫폼, 도구 또는 기술의 소유자입니다.

프로젝트 팀은 솔루션의 기술적 측면을 다루기 위해 기술 디자인 세션에 관련자를 참여시킵니다. 기술적 측면에는 다음이 포함될 수 있습니다.

• 데이터 원본 연결: 데이터 원본에 연결하고 통합하는 방법에 대한 세부 정보입니다.
• 네트워킹 및 데이터 게이트웨이: 개인 네트워크 또는 온-프레미스 데이터 원본에 대한 세부 정보입니다.
• 필드 원본 매핑: 데이터 원본 필드에 대한 비즈니스 메트릭 및 특성의 데이터 매핑입니다.
• 계산 논리: 비즈니스 정의를 기술 계산으로 변환합니다.
• 기술적 기능: 비즈니스 요구 사항을 지원하는 데 필요한 기능입니다.

다음 다이어그램은 기술 디자인을 사용하여 비즈니스 요구 사항을 기술 요구 사항으로 변환하는 방법을 보여 줍니다.

다이어그램에서는 다음 단계를 보여 줍니다.

Item	설명
	프로젝트 팀은 비즈니스 디자인 결과를 바탕으로 데이터 원본 범위를 정의하는 것부터 기술 디자인을 시작합니다. 데이터 원본 범위는 솔루션을 빌드하는 데 필요한 데이터를 선언합니다. 올바른 데이터 원본을 식별하기 위해 프로젝트 팀은 비즈니스 및 기능 SME와 협의합니다.
	프로젝트 팀은 나중에 기술 디자인 세션에 참여할 기술 또는 기능 관련자를 식별합니다.
	프로젝트 팀은 솔루션의 기술적 측면을 다루기 위해 기능적 관련자와의 제한적이고 집중적인 세션을 계획합니다. 계획에는 관련자에게 알리고, 모임을 조직하고, 결과물을 준비하는 작업이 포함됩니다.
	프로젝트 팀은 기술 요구 사항을 조사합니다. 연구에는 필드 계산 및 데이터 원본 매핑을 정의하고 기술 분석 및 문서화를 통해 비즈니스 디자인 가정을 해결하는 활동이 포함됩니다.
	필요한 경우 프로젝트 팀은 기술 디자인 세션에 관련자를 참여시킵니다. 세션은 보안이나 데이터 원본 연결과 같은 솔루션의 특정 기술 측면에 중점을 둡니다. 이 세션에서 프로젝트 팀은 관련자와 SME로부터 정성적인 피드백을 수집합니다.
	프로젝트 팀은 관련자와 의사 결정자에게 제시하는 솔루션 계획을 사용하여 조사 결과를 준비합니다. 계획은 최종 디자인, 예측 및 기타 결과물을 포함하는 비즈니스 디자인 결과의 반복 및 확장입니다.
	기술 디자인은 관련자 및 의사 결정자와 최종 모임을 통해 진행 여부를 결정하는 것으로 마무리되어야 합니다. 이 모임은 리소스를 솔루션 개발에 투입하기 전에 솔루션 계획을 평가할 수 있는 최종 기회를 제공합니다.

기술 디자인은 다음 결과물로 구성된 솔루션 계획으로 마무리됩니다.

• 도구 및 기술: 솔루션을 구현하는 데 필요한 관련 기술 도구 목록입니다. 이 목록에는 일반적으로 관련 새 라이선스 옵션(예: 패브릭 용량 또는 사용자당 프리미엄), 기능 및 도구가 포함됩니다.
• 정의된 비즈니스 메트릭 목록: 모든 범위 내 데이터 원본에 대한 비즈니스 메트릭을 계산하고 필드-원본을 매핑한 내역입니다. 이 결과물을 만들기 위해 프로젝트 팀은 비즈니스 디자인에서 만들어진 비즈니스 메트릭 목록을 사용합니다.
• 정의된 비즈니스 특성 목록: 모든 범위 내 데이터 원본에 대한 비즈니스 특성의 필드 원본을 매핑한 내역입니다. 이 결과물을 만들기 위해 프로젝트 팀은 비즈니스 디자인에서 만들어진 비즈니스 특성 목록을 사용합니다.
• 수정된 디자인: 비즈니스 디자인의 변경 또는 잘못된 가정을 기반으로 한 솔루션 디자인의 수정 사항입니다. 수정된 디자인은 비즈니스 디자인에서 제작된 모형, 프로토타입 또는 와이어프레임 다이어그램의 업데이트된 버전입니다. 수정이 필요하지 않은 경우 기술 디자인이 비즈니스 디자인의 유효성을 검사했음을 전달합니다.
• 예상되는 활동: 솔루션을 개발, 지원 및 유지하는 데 필요한 리소스를 예상합니다. 예상되는 활동을 통해 솔루션 구현을 진행할지 여부에 대한 최종 결정을 알려 줍니다.

검사 목록 - 요구 사항을 수집할 때 주요 결정과 조치에는 다음이 포함됩니다.

2단계: 배포 계획

프로젝트 팀이 요구 사항 수집, 솔루션 계획 수립, 진행 승인 수신을 마치면 솔루션 배포 계획을 세울 준비가 된 것입니다.

배포 계획 작업은 솔루션, 개발 워크플로 및 배포 프로세스에 따라 다릅니다. 배포 계획은 일반적으로 솔루션을 위한 도구 및 프로세스의 계획 및 설정과 관련된 다양한 활동과 관련됩니다.

주요 영역 계획

프로젝트 팀은 솔루션 배포의 주요 영역을 계획해야 합니다. 일반적으로 계획하려면 다음 영역을 다루어야 합니다.

• 규정 준수: 요구 사항 수집에서 식별된 모든 규정 준수 기준이 특정 작업을 통해 해결되는지 확인합니다. 이러한 각 작업을 특정 사람에게 할당하고 배달 시간 프레임을 명확하게 정의합니다.
• 보안: 다양한 솔루션 액세스 계층을 관리하는 방법과 데이터 보안 규칙 요구 사항을 결정합니다. 솔루션 보안이 테넌트의 표준 콘텐츠보다 더 엄격한지 또는 덜 엄격한지 검토합니다.
• 데이터 게이트웨이: 데이터 원본에 연결하기 위해 데이터 게이트웨이가 솔루션에 필요한지 평가합니다. 특정 게이트웨이 설정이나 고가용성 클러스터가 필요한지 확인합니다. 게이트웨이 보안 역할을 통해 게이트웨이 연결을 관리할 수 있는 사람과 게이트웨이를 모니터링하는 방법을 계획합니다. 자세한 내용은 게이트웨이 액세스 프로비전을 참조하세요.
• 작업 영역: 작업 영역 설정 및 사용 방법을 결정합니다. 솔루션에 Git 통합 및 배포 파이프라인과 같은 수명 주기 관리 도구가 필요한지, 그리고 Azure Log Analytics를 사용한 고급 로깅이 필요한지 여부를 확인합니다.
• 지원: 프로덕션 배포 후 솔루션 지원 및 유지 관리를 담당할 사람을 설정합니다. 지원을 담당하는 사람이 프로젝트 팀과 다른 경우 개발에 참여시키세요. 솔루션을 지원하는 사람은 누구나 솔루션 디자인, 해결해야 할 문제, 이를 사용해야 하는 사용자 및 방법을 이해하고 있는지 확인합니다.
• 사용자 학습: 사용자 커뮤니티가 솔루션을 효과적으로 사용할 수 있도록 학습하는 데 필요한 활동을 예상합니다. 특정 변경 관리 작업이 필요한지 고려합니다.
• 거버넌스: 솔루션에 대한 잠재적인 거버넌스 위험을 식별합니다. 사용자가 솔루션을 효과적으로 사용할 수 있도록 하는 동시에 거버넌스 위험을 완화하는 데 필요한 활동을 예측합니다(예: 민감도 레이블 및 정책 사용).

초기 설정 수행

프로젝트 팀은 개발을 시작하기 위해 초기 설정을 수행해야 합니다. 초기 설정 활동에는 다음이 포함될 수 있습니다.

• 초기 도구 및 프로세스: 개발, 테스트 및 배포에 필요한 새로운 도구와 프로세스에 대한 최초 설정을 수행합니다.
• ID 및 자격 증명: 도구 및 시스템에 액세스하는 데 사용할 보안 그룹 및 서비스 주체를 만듭니다. 자격 증명을 효과적이고 안전하게 저장합니다.
• 데이터 게이트웨이: 온-프레미스 데이터 원본(엔터프라이즈 모드 게이트웨이) 또는 개인 네트워크(가상 네트워크 또는 VNet 게이트웨이)의 데이터 원본에 대해 데이터 게이트웨이를 배포합니다.
• 작업 영역 및 리포지토리: 콘텐츠 게시 및 저장을 위한 작업 영역과 원격 리포지토리를 만들고 설정합니다.

배포 계획에 대한 자세한 내용은 Power BI로 마이그레이션하기 위한 배포 계획을 참조하세요.

검사 목록 - 솔루션 배포를 계획할 때 주요 결정 및 작업은 다음과 같습니다.

3단계: 개념 증명 수행

프로젝트 팀은 솔루션 POC(개념 증명)을 수행하여 뛰어난 가정의 유효성을 검사하고 비즈니스 사용자를 위한 초기 이점을 보여 줍니다. POC는 범위와 성숙도가 제한된 초기 디자인 구현입니다. 잘 실행되는 POC는 기술 디자인에서 검색되지 않은 복잡성(또는 예외)을 식별하고 해결할 수 있기 때문에 대규모 또는 복잡한 솔루션에 특히 중요합니다.

POC를 준비할 때 다음 고려 사항을 고려하는 것이 좋습니다.

• 목표 및 범위: 솔루션 POC의 목적과 이를 통해 해결하려는 기능 영역에 대해 설명합니다. 예를 들어 프로젝트 팀은 POC를 단일 기능 영역이나 특정 요구 사항 또는 기능 집합으로 제한하기로 결정할 수 있습니다.
• 원본 데이터: POC에 사용될 데이터를 식별합니다. 솔루션에 따라 프로젝트 팀은 다음과 같은 다양한 형식의 데이터를 사용하기로 결정할 수 있습니다.
  • 프로덕션(실제) 데이터
  • 샘플 데이터
  • 프로덕션 환경에서 관찰되는 실제 데이터 볼륨 및 복잡성과 유사한 생성된 가상 데이터
• 데모: 프로젝트 팀이 관련자와 사용자에게 POC를 보여 주는 방법과 시기를 설명합니다. 정기 업데이트 중에 또는 POC가 특정 기능 기준을 충족할 때 데모를 제공할 수 있습니다.
• 환경: 프로젝트 팀이 POC를 빌드할 위치를 설명합니다. POC에 고유한 샌드박스 환경을 사용하고 준비가 되면 개발 환경에 배포하는 것이 좋은 방법입니다. 샌드박스 환경은 보다 유연한 정책과 유동적인 콘텐츠를 갖추고 있으며 빠른 결과를 생성하는 데 중점을 둡니다. 이와 대조적으로, 개발 환경은 협업을 가능하게 하는 보다 구조화된 프로세스를 따르며 특정 작업을 완료하는 데 중점을 둡니다.
• 성공 기준: POC가 성공하고 다음 반복으로 이동하여 공식 개발에 들어가야 하는 시점에 대한 임계값을 정의합니다. POC를 시작하기 전에, 프로젝트 팀은 언제 POC가 성공할지에 대한 명확한 기준을 식별해야 합니다. 이러한 기준을 미리 설정함으로써, 프로젝트 팀은 POC 개발이 끝나는 시기와 반복 개발 및 유효성 검사 주기가 시작되는 시기를 정의합니다. POC의 목표에 따라 프로젝트 팀은 다음과 같은 다양한 성공 기준을 설정할 수 있습니다.
  • 관련자의 POC 승인
  • 기능 특징에 대한 유효성 검사
  • 고정된 개발 시간 이후 동료들이 POC에 대해 호의적인 검토를 했습니다.
• 실패: 프로젝트 팀이 POC의 실패를 식별할 수 있는지 확인합니다. 오류를 조기에 식별하면 근본 원인을 조사하는 데 도움이 됩니다. 또한 프로덕션에 배포할 때 예상대로 작동하지 않는 솔루션에 대한 추가 투자를 방지하는 데 도움이 될 수 있습니다.

검사 목록 - POC를 만들 때 주요 결정 및 작업은 다음과 같습니다.

4단계: 콘텐츠 만들기 및 유효성 검사

POC가 성공하면 프로젝트 팀은 POC에서 콘텐츠 만들기 및 유효성 검사로 전환됩니다. 프로젝트 팀은 반복 개발 및 유효성 검사 주기를 통해 BI 솔루션을 개발할 수 있습니다. 이러한 주기는 프로젝트 팀이 개발 환경에서 콘텐츠를 만들고 이를 테스트 환경에 릴리스하는 반복 릴리스로 구성됩니다. 개발 중에 프로젝트 팀은 테스트 환경에서 솔루션의 초기(베타) 버전에 대한 파일럿 프로세스를 통해 점차적으로 사용자 커뮤니티를 온보딩합니다.

프로젝트 팀이 미리 정의된 결론에 도달할 때까지 반복 개발 및 유효성 검사 주기가 진행됩니다. 일반적으로 개발은 더 이상 구현할 기능이 없거나 해결해야 할 사용자 피드백이 없을 때 종료됩니다. 개발 및 유효성 검사 주기가 끝나면 프로젝트 팀은 최종 프로덕션 릴리스와 함께 프로덕션 환경에 콘텐츠를 배포합니다.

다음 다이어그램은 프로젝트 팀이 개발 및 유효성 검사 주기에 따라 BI 솔루션을 반복적으로 제공할 수 있는 방법을 보여 줍니다.

다이어그램에서는 다음 단계를 보여 줍니다.

Item	설명
	프로젝트 팀이 각 릴리스를 사용자 커뮤니티에 전달하여 변경 내용과 새로운 기능을 설명합니다. 이상적인 커뮤니케이션에는 솔루션 데모와 Q&A가 포함되므로 사용자는 릴리스의 새로운 기능을 이해하고 구두로 피드백을 제공할 수 있습니다.
	유효성 검사 중에 사용자는 중앙 도구나 양식을 통해 피드백을 제공합니다. 프로젝트 팀은 피드백을 정기적으로 검토하여 문제를 해결하고, 요청을 수락 또는 거부하고, 예정된 개발 단계를 알려야 합니다.
	프로젝트 팀이 솔루션 사용을 모니터링하여 사용자가 솔루션을 테스트하고 있는지 확인합니다. 사용량이 없는 경우 프로젝트 팀은 사용자 커뮤니티와 협력하여 이유를 이해해야 합니다. 사용량이 적은 경우에는 프로젝트 팀이 추가 지원 및 변경 관리 작업을 수행해야 합니다.
	프로젝트 팀은 사용자 피드백에 신속하게 응답합니다. 프로젝트 팀이 피드백을 처리하는 데 너무 오랜 시간이 걸리면 사용자에게 피드백을 제공하려는 동기가 빨리 없어질 수 있습니다.
	프로젝트 팀은 수락된 피드백을 솔루션 계획에 통합합니다. 필요한 경우 계획 우선 순위를 검토하여 다음 개발 단계가 시작되기 전에 작업을 명확하게 하고 위임합니다.
	프로젝트 팀은 다음 릴리스를 위한 솔루션 개발을 계속합니다.
	프로젝트 팀은 미리 정의된 결론에 도달하고 솔루션이 프로덕션을 배포할 준비가 될 때까지 모든 단계를 반복합니다.

다음 섹션에서는 반복 개발 및 유효성 검사 주기를 사용하여 BI 솔루션을 제공하기 위한 주요 고려 사항을 설명합니다.

콘텐츠 만들기

프로젝트 팀은 일반적인 개발 워크플로에 따라 솔루션을 개발합니다. 다만, 콘텐츠 제작 시에는 다음 사항을 고려해야 합니다.

• 각 개발 주기 동안 솔루션을 설명하는 설명서를 업데이트합니다.
• 사용자 커뮤니티에 공지하여 각 개발 주기를 마무리합니다. 공지 사항은 중앙 포털에 게시되어야 하며, 여기서 각 릴리스의 변경 내용 및 새로운 기능에 대한 간략한 설명을 제공해야 합니다.
• 각 릴리스마다 세션을 구성하여 사용자 커뮤니티에 변경 내용과 새로운 기능을 보여 주고 구두 질문에 답변하는 것이 좋습니다.
• 반복 개발 및 유효성 검사 주기가 언제 종료되는지 정의합니다. 지원 및 채택 활동으로의 전환을 포함하여 프로덕션 환경에 솔루션을 배포하기 위한 명확한 프로세스가 있는지 확인합니다.

콘텐츠 유효성 검사

각 반복 개발 주기는 콘텐츠 유효성 검사로 마무리되어야 합니다. BI 솔루션의 경우 일반적으로 두 가지 종류의 유효성 검사가 있습니다.

• 개발자 유효성 검사: 솔루션 테스트는 콘텐츠 작성자와 동료가 수행합니다. 개발자 유효성 검사의 목적은 솔루션이 비즈니스 사용자에게 제공되기 전에 중요하고 눈에 띄는 모든 문제를 식별하고 해결하는 것입니다. 문제는 데이터 정확성, 기능 또는 사용자 환경과 관련될 수 있습니다. 이상적으로는 콘텐츠를 개발하지 않은 콘텐츠 작성자가 콘텐츠의 유효성을 검사합니다.
• 사용자 유효성 검사: 솔루션 테스트는 사용자 커뮤니티에서 수행됩니다. 사용자 유효성 검사의 목적은 이후 반복에 대한 피드백을 제공하고 개발자가 발견하지 못한 문제를 식별하는 것입니다. 공식적인 사용자 유효성 검사 기간은 일반적으로 UAT(사용자 승인 테스트)라고 합니다.

프로젝트 팀이 콘텐츠의 유효성을 검사할 때 다음 고려 사항에 유의해야 합니다.

• 사용자 피드백 장려: 각 릴리스마다 사용자에게 피드백을 제공하도록 요청하고 효과적으로 피드백을 제공할 수 있는 방법을 보여 줍니다. 최근 변경 내용과 새로운 기능을 가져온 피드백과 요청의 예를 정기적으로 공유해 보세요. 사례를 공유함으로써 피드백이 인정되고 소중하다는 점을 보여 줄 수 있습니다.
• 대규모 요청 격리: 일부 피드백 항목을 해결하려면 더 많은 활동이 필요합니다. 프로젝트 팀이 이러한 항목을 식별하고 구현 여부를 토론할 수 있는지 확인합니다. 이후의 전술 계획 세션에서 토론할 수 있도록 더 큰 요청을 문서화해 보세요.
• 변경 관리 활동 시작: 사용자에게 솔루션 사용 방법을 학습합니다. 새로운 프로세스, 새로운 데이터, 다양한 작업 방식에 더 많이 노력해야 합니다. 변경 관리를 중점적으로 수행하면 장기적인 솔루션 채택에 있어 긍정적인 결과를 얻을 수 있습니다.

솔루션이 미리 정의된 완전성 및 성숙도 수준에 도달하면 프로젝트 팀이 이를 프로덕션에 배포할 준비가 된 것입니다. 배포 후 프로젝트 팀은 반복적인 배달에서 프로덕션 솔루션 지원 및 모니터링으로 전환합니다.

이 문서에서는 개략적인 계획과 실행 가능한 항목만 설명합니다. 반복 개발 및 테스트 주기에 대한 자세한 콘텐츠는 Power BI로 마이그레이션할 콘텐츠 만들기를 참조하세요.

검사 목록 - 콘텐츠를 만들고 유효성 검사할 때 주요 결정 및 작업은 다음과 같습니다.

5단계: 배포, 지원, 모니터링

준비가 되면 프로젝트 팀은 유효성 검사된 솔루션을 프로덕션 환경에 배포합니다. 프로젝트 팀은 배포가 성공할 수 있도록 주요 채택 및 지원 작업을 수행해야 합니다.

성공적인 배포를 위해 다음 지원 및 채택 작업을 수행합니다.

• 최종 릴리스 알림: 경영진 스폰서, 관리자 또는 권한과 신뢰성이 충분한 기타 사람이 사용자 커뮤니티에 릴리스를 공지해야 합니다. 커뮤니케이션은 명확하고 간결해야 하며 관련 솔루션 및 지원 채널에 대한 링크를 포함해야 합니다.
• 콘텐츠 소비자를 위한 학습 실시: 프로덕션 릴리스 후 첫 주 동안 콘텐츠 소비자를 위한 학습이 제공되어야 합니다. 학습은 솔루션 범위를 명확히 하고, 사용자 질문에 답변하고, 솔루션 사용 방법을 설명하는 데 중점을 두어야 합니다.
• 피드백 및 요청 처리: 사용자가 프로젝트 팀에 피드백과 요청을 제출할 수 있는 채널을 제공하는 것이 좋습니다. 배포 후 지원 기간 동안 합리적인 피드백과 요청이 토론되고 적절한 경우 구현되도록 합니다. 프로덕션 릴리스 이후 피드백과 요청에 따라 조치를 취해야 합니다. 변화하는 비즈니스 요구에 대응하는 Agile 솔루션을 나타냅니다.
• 사용자 커뮤니티와의 연결 계획: 배포 후 지원 기간이 종료된 후에도 솔루션 소유자가 정기적으로 사용자 커뮤니티와 모임을 갖도록 합니다. 이러한 모임은 BI 전략 수정을 위한 귀중한 피드백 원본입니다. 또한 사용자를 사용하도록 설정하여 솔루션 채택을 지원하는 데 도움이 됩니다.
• 인계 작업: 프로젝트 팀 멤버는 솔루션 유지 관리에 대한 책임을 지지 않을 수 있습니다. 이 경우 팀은 책임자를 파악하고 인계 작업을 수행해야 합니다. 인계 작업은 프로덕션 릴리스 직후에 이루어져야 하며 솔루션과 사용자 커뮤니티를 모두 다루어야 합니다.

배포 후 프로젝트 팀은 우선 순위가 지정된 솔루션 백로그에서 다음 솔루션을 진행할 계획을 세워야 합니다. 새로운 피드백과 요청을 수집하고 필요한 경우 솔루션 백로그를 포함하여 전술 계획을 수정합니다.

검사 목록 – 솔루션 배포를 고려할 때 주요 결정 및 작업은 다음과 같습니다.

관련 콘텐츠

Power BI 구현 결정에 도움이 되는 더 많은 고려 사항, 작업, 의사 결정 기준 및 권장 사항은 Power BI 구현 계획을 참조하세요.