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

참고 항목

이 문서는 Power BI 구현 계획 시리즈의 일부를 구성합니다. 이 시리즈는 주로 Microsoft Fabric 내의 Power BI 환경에 중점을 둡니다. 시리즈에 대한 소개는 Power BI 구현 계획을 참조하세요.

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

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

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

참고 항목

OKR(목표 및 주요 결과) 프레임워크 에서 목표는 달성하려는 사항에 대한 명확하고 개략적인 설명입니다. 반면, 주요 결과는 목표 중 하나에 대한 진행률을 측정하기 위한 구체적이고 달성 가능한 결과입니다.

또한 이니셔티브 또는 솔루션은 하나 이상의 주요 결과를 달성하는 데 도움이 되는 프로세스 또는 도구입니다. 솔루션은 사용자의 특정 데이터 요구 사항을 해결합니다. 솔루션은 데이터 파이프라인, 데이터 레이크하우스 또는 Power BI 의미 체계 모델 또는 보고서와 같은 다양한 형태를 취할 수 있습니다.

OKR에 대한 자세한 내용은 OKR 알아보기(Microsoft Viva 목표)를 참조하세요.

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

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

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

Step	설명
1	요구 사항을 수집하고 솔루션 디자인을 정의하는 프로젝트 팀을 구성합니다.
2	도구 및 프로세스의 초기 설정을 수행하여 솔루션 배포를 계획합니다.
3	솔루션 POC(개념 증명)를 수행하여 디자인에 대한 가정의 유효성을 검사합니다.
4	반복 개발 및 유효성 검사 주기를 사용하여 콘텐츠를 만들고 유효성 검사합니다.
5	프로덕션 환경에 릴리스된 후 솔루션을 배포, 지원 및 모니터링합니다.

참고 항목

BI 솔루션 계획은 셀프 서비스 BI 및 엔터프라이즈 BI 프로젝트 모두에 적용됩니다.

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

1단계: 요구 사항 수집

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

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

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

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

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

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

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

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

Important

잘못된 요구 사항을 수집하기 때문에 일반적으로 구현이 실패하게 됩니다. 팀이 빌드할 솔루션에 대해 하향식 요청을 제공하는 의사 결정자와 같은 잘못된 관련자와 협력하기 때문에 잘못된 요구 사항을 수집하는 경우도 있습니다.

비즈니스 디자인과 같은 협업 방식을 사용하여 비즈니스 사용자의 참여를 유도하면 더 나은 요구 사항을 수집하는 데 도움이 될 수 있습니다. 더 나은 요구 사항은 종종 더 효율적인 개발과 더 강력한 솔루션으로 이어집니다.

참고 항목

일부 팀에서는 프로세스를 수집하는 구조적 요구 사항을 채택하는 것이 큰 변화입니다. 이 변경 내용을 관리하고 이로 인해 솔루션 계획이 중단되지 않는지 확인합니다. 팀의 작업 방식에 맞게 이러한 방식을 조정하는 방법을 찾는 것이 좋습니다.

솔루션 계획 준비

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

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

팁

요구 사항 수집 프로세스 초기에 솔루션을 담당하는 지원팀을 식별하고 참여시키는 것이 좋습니다. 솔루션을 효과적으로 지원하려면 지원팀은 솔루션, 솔루션 목적, 사용자에 대한 포괄적인 이해가 필요합니다. 이는 프로젝트 팀이 외부 컨설턴트로만 구성된 경우 특히 중요합니다.

비즈니스 요구 사항 수집

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

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

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

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

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

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

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

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

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

팁

솔루션 모형, 프로토타입 또는 와이어프레임 다이어그램을 통해 개발자와 최종 사용자 모두가 예상되는 결과를 명확하게 이해할 수 있습니다. 효과적인 모형을 만드는 데에는 예술적 기술이나 재능이 필요하지 않습니다. Microsoft Whiteboard, PowerPoint 또는 펜과 종이와 같은 간단한 도구를 사용하여 디자인을 설명할 수 있습니다.

기술 요구 사항 수집

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

참고 항목

비즈니스 디자인과 달리 기술 디자인은 콘텐츠 작성자와 소유자가 수행하는 원본 데이터 및 시스템에 대한 대체로 독립적인 조사입니다.

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

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

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

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

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

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

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

팁

비즈니스 디자인을 수행한 프로젝트 팀은 기술 디자인도 수행해야 합니다. 그러나 실용적인 이유로 인해 서로 다른 사람이 기술 디자인을 주도할 수 있습니다. 이 경우 비즈니스 디자인 결과를 검토하여 기술 디자인을 시작합니다.

이상적으로는 기술 디자인을 주도하는 사람이 결과와 비즈니스 사용자를 철저히 이해하고 있어야 합니다.

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

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

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

참고 항목

기술 디자인에서는 현재 리소스 가용성이나 조직의 준비 상태를 고려할 때 솔루션 계획을 실행 불가능하게 만들 수 있는 예기치 못한 복잡성이 드러날 수 있습니다. 이 경우 이어지는 전술 계획 기간에 솔루션을 다시 평가해야 합니다. 비즈니스 데이터 요구 사항의 긴급성에 따라 경영진 스폰서와 같은 의사 결정자는 여전히 개념 증명을 진행하거나 계획된 솔루션의 일부만 진행하기를 원할 수 있습니다.

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

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

Important

프로젝트 팀이 기술 디자인의 변경 내용이나 예기치 못한 발견 사항을 관련자에게 알리도록 합니다. 이러한 기술 디자인 세션에는 관련 비즈니스 사용자가 계속 참여해야 합니다. 그러나 관련자가 복잡한 기술 정보에 불필요하게 노출되지 않도록 해야 합니다.

팁

비즈니스 목표는 항상 발전하기 때문에 요구 사항도 변경될 것으로 예상됩니다. BI 프로젝트에 대한 요구 사항이 고정되어 있다고 가정하지 않는 것이 좋습니다. 요구 사항 변경으로 인해 어려움을 겪고 있다면 요구 사항 수집 프로세스가 비효율적이거나 개발 워크플로에 정기적인 피드백이 충분히 반영되지 않았다는 의미일 수 있습니다.

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

• 솔루션 계획 책임자의 명확화: 각 솔루션에 대해 프로젝트 팀의 역할과 책임이 명확해야 합니다.
• 솔루션 범위 명시: 솔루션 범위는 BI 전술 계획의 일부로 이미 문서화되어 있어야 합니다. 솔루션 계획을 시작하기 전에 범위를 명확히 하기 위해 추가 시간과 활동이 필요할 수 있습니다.
• 관련자 식별 및 정보 제공: 비즈니스 디자인 및 기술 디자인에 대한 관련자를 식별합니다. 프로젝트에 대해 미리 알리고 비즈니스 디자인의 범위, 목표, 필요한 시간 투자 및 결과물을 설명합니다.
• 비즈니스 디자인 세션 계획 및 진행: 비즈니스 디자인 세션을 진행하여 관련자와 비즈니스 사용자로부터 정보를 이끌어냅니다. 사용자에게 기존 솔루션의 사용 방법을 보여달라고 요청합니다.
• 비즈니스 메트릭 및 특성 문서화: 기존 솔루션과 관련자의 의견을 사용하여 비즈니스 메트릭 및 특성 목록을 만듭니다. 기술 디자인에서는 필드를 데이터 원본에 매핑하고 정량적 필드에 대한 계산 논리를 설명합니다.
• 솔루션 디자인 초안 작성: 관련자의 입력을 기반으로 예상 솔루션 결과를 시각적으로 반영하는 반복적인 모형을 만듭니다. 모형이 비즈니스 요구 사항을 정확하게 표현하고 해결하는지 확인합니다. 기술 디자인 중에 모형의 유효성을 검사(경우에 따라 수정)해야 한다는 점을 비즈니스 사용자에게 전달합니다.
• 솔루션 계획 수립: 비즈니스 디자인이 달성 가능한지 확인하기 위해 원본 데이터 및 관련 기술 고려 사항을 조사합니다. 해당되는 경우 디자인에 대한 주요 위험과 위협, 그리고 대체 방식을 설명합니다. 필요한 경우 솔루션 디자인 수정본을 준비하고 관련자와 토론합니다.
• 예상 활동 만들기: 최종 솔루션 계획의 일부로 솔루션 빌드 및 지원에 소요되는 활동을 예상합니다. 비즈니스 디자인 및 기술 디자인 세션 중에 수집된 정보를 사용하여 이러한 예상 활동을 정당화합니다.
• 계획 진행 여부 결정: 요구 사항 수집 프로세스를 마무리하려면 관련자와 의사 결정자에게 최종 계획을 제시합니다. 이번 모임의 목적은 솔루션 개발 진행 여부를 결정하는 것입니다.

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를 수행할 때 가정과 제한 사항에 대해 주의를 기울여야 합니다. 예를 들어, 프로젝트 팀은 소규모 데이터 집합을 사용하여 솔루션 성능과 데이터 품질을 쉽게 테스트할 수 없습니다. 또한 POC의 범위와 목적이 비즈니스 사용자에게 명확한지 확인합니다. POC가 첫 번째 반복이라는 점을 전달하고 프로덕션 솔루션이 아니라는 점을 강조합니다.

참고 항목

자세한 내용은 Power BI로 마이그레이션하기 위한 개념 증명 수행을 참조하세요.

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

• 목표 정의: POC의 목표가 관련된 모든 사람에게 명확한지 확인합니다.
• POC 범위 정의: POC를 만드는 데 너무 많은 개발 활동이 필요하지 않으면서도 가치를 제공하고 솔루션 디자인을 보여 줄 수 있는지 확인합니다.
• 사용할 데이터 결정: POC를 수행하는 데 사용할 원본 데이터를 식별하여 결정 사항을 정당화하고 잠재적인 위험과 제한 사항을 간략하게 설명합니다.
• POC 데모 시기 및 방법 결정: 의사 결정자와 비즈니스 사용자에게 POC를 제시하여 진행률을 보여줄 계획을 세웁니다.
• POC 종료 시기 명시: 프로젝트 팀이 POC에 대한 명확한 결론을 결정하고 공식 개발 주기로 승격되는 방법을 설명합니다.

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

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

팁

반복적인 배달은 변경 요청을 완화하고 솔루션 채택을 촉진하며 프로덕션 릴리스 전에 이점을 실현할 수 있는 조기 유효성 검사 및 피드백을 장려합니다.

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

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

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

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

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

콘텐츠 만들기

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

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

콘텐츠 유효성 검사

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

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

Important

개발자 유효성 검사 중에(UAT 이전) 데이터 품질 문제가 해결되었는지 확인합니다. 이러한 문제는 솔루션에 대한 신뢰를 빠르게 약화시킬 수 있으며 장기적인 채택에 해를 끼칠 수 있습니다.

팁

사용자 유효성 검사를 수행할 때 주요 사용자와의 가끔씩 짧게 통화하는 것이 좋습니다. 솔루션을 사용할 때 관찰합니다. 사용하기 어려운 부분이나 솔루션의 어떤 부분이 예상대로 작동하지 않는지 기록해 두세요. 이 방식은 피드백을 수집하는 효과적인 방법이 될 수 있습니다.

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

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

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

참고 항목

개발 및 테스트는 솔루션과 기본 설정하는 워크플로에 따라 다릅니다.

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

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

• 반복적인 프로세스를 사용하여 작업을 계획하고 할당합니다. 솔루션의 각 릴리스에 대한 작업을 계획하고 할당합니다. 작업을 계획하고 할당하는 프로세스가 유연하고 사용자 피드백을 통합하는지 확인합니다.
• 콘텐츠 수명 주기 관리 설정: 도구와 프로세스를 사용하여 솔루션 배포와 변경 관리를 간소화하고 자동화합니다.
• 피드백을 중앙 집중화하는 도구 만들기: 사용자와 함께 간단하게 사용할 수 있는 솔루션을 통해 피드백 컬렉션을 자동화합니다. 피드백이 간결하면서도 실행 가능하도록 간단한 양식을 만듭니다.
• 피드백 검토를 위한 모임 일정 수립: 모임을 통해 각각의 새롭거나 뛰어난 피드백 항목을 간략하게 검토합니다. 피드백을 구현할지 여부, 구현을 담당할 사람, 피드백 항목을 종료하기 위해 수행할 작업을 결정합니다.
• 반복적인 배달이 종료되는 시점 결정: 반복적 배달 주기가 종료되는 시점과 콘텐츠를 프로덕션 환경에 릴리스할 시점에 대한 조건을 설명합니다.

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

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

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

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

주의

효과적인 인계 작업을 수행하지 못하면 수명 주기 동안 솔루션 지원 및 채택과 관련하여 예방 가능한 문제가 발생할 수 있습니다.

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

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

• 커뮤니케이션 계획 만들기: 릴리스, 학습, 기타 솔루션 지원 또는 채택 작업을 전달하는 방법을 계획합니다. 배포 후 지원 기간에 중단이나 문제가 전달되고 신속하게 해결되었는지 확인합니다.
• 학습 계획에 따라 수행: 사용자에게 솔루션 사용 방법을 학습합니다. 학습에는 릴리스 후 몇 주 동안 실시간 및 녹화된 학습 세션이 모두 포함되어 있는지 확인합니다.
• 인계 활동 수행: 필요한 경우 개발팀에서 지원팀으로의 인계 작업을 준비합니다.
• 솔루션 근무 시간 실시: 배포 후 지원 기간이 끝난 후 정규 근무 시간 세션을 열어 질문에 답하고 사용자로부터 피드백을 수집하는 것이 좋습니다.
• 지속적인 개선 프로세스 설정: 솔루션에 대한 월간 감사를 예약하여 시간이 지남에 따라 잠재적인 변경 내용이나 개선 사항을 검토합니다. 사용자 피드백을 중앙 집중화하고 감사 사이에 주기적으로 피드백을 검토합니다.

관련 콘텐츠

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