이 문서에서는 앱, 흐름, 챗봇을 포함한 솔루션 사용자를 지원하는 공식적, 비공식적 방법을 제안합니다. Power Platform
이 다이어그램은 조직을 위한 일반적인 지원 및 졸업 프레임워크를 보여줍니다.
| 타입 | Description |
|---|---|
|
자체 지원(내부) 은 제작자가 자체 솔루션을 지원할 때 발생합니다. 솔루션의 사용자는 지원을 위해 제조업체에게 연락해야 한다는 것을 알고 있으며 제조업체가 제공하는 지원 수준이나 유형에 대해 IT 또는 팀에 대한 가시성이 없는 경우가 많습니다. |
|
팀 지원(내부) 은 팀 구성원이 솔루션을 개발하면서 서로에게서 배우는 방식으로 이루어집니다. Power Platform 팀 구성원은 팀의 앱, 흐름, 챗봇의 공동 담당자가 됩니다. 공동 담당자는 사용자 쿼리를 지원할 수 있으며 작은 버그 수정 및 변경을 수행할 수 있습니다. 팀 보조 지원이 비공식적으로 진행되는 경우도 있지만 채택 및 성장이 성숙해짐에 따라 이 프로세스를 공식화하는 것이 좋습니다. |
|
헬프 데스크 지원(내부) 은 공식적인 지원 문제와 요청을 처리합니다. 헬프 데스크는 모바일 기기에서 앱에 액세스하는 방법이나 백엔드 데이터 소스에 대한 액세스를 요청하는 방법 등의 질문에 도움을 줄 수 있습니다. 솔루션 관련 질문을 솔루션을 지원하는 채널로 리디렉션합니다. |
|
전담 Power Platform 지원(내부) 은 헬프 데스크에서 접수된 복잡한 문제를 처리하는 것을 포함합니다. 위험 애플리케이션은 이 팀에 전달되며 버그 수정을 배포할 수 있습니다. |
|
파트너 지원(외부) 은 내부 지원 서비스를 보완하고, 중요한 애플리케이션을 지원하거나 특정 부서와 협력하여 해당 애플리케이션 지원을 제공할 수 있습니다. 자세한 내용은 파트너로부터 전문가의 도움을 받으세요 Power Apps 에서 확인하세요. |
|
Microsoft 지원(외부) 을 통해 플랫폼 관련 기술 문제를 제기할 수 있습니다. 지원 플랜에 따라 다양한 기술 지원 및 자문 서비스를 이용할 수 있습니다. 자세한 내용은 지원 Microsoft Power Platform에서 확인하세요. |
지원 프레임워크를 공식화하세요
조직의 규모와 로우 코드 및 프로 코드 기술에 대한 기존 제공 방식에 따라 지원을 공식화하는 다양한 방법을 선택할 수 있습니다.
분산형: Power Platform 도입 접근 방식이 대체로 분산형인 경우, 조직 전체에 자율적인 팀이 있어 솔루션을 제공하고 관리합니다. Power Platform 이 모델을 사용하면 지원도 위임할 수 있으며, 팀 지원이 사용자와 제작자에게 가장 적합한 서비스가 될 수 있습니다.
중앙 집중형: 도입 접근 방식이 대체로 Power Platform 중앙 집중형 인 경우, 조직의 사업부 전반에서 부서별 솔루션의 로우코드 제공을 담당하는 제품 소유자로 구성된 중앙 팀이 있게 됩니다. 이 모델을 사용하면 지원도 중앙 집중화되고 중앙 지원 팀이 쿼리와 질문에 답변합니다.
대부분의 조직에서는 다양한 전달 모델을 혼합하는 것이 가장 효과적입니다. 분산형 팀이 제작자를 위한 솔루션을 지원하더라도 기술적 문제, 사용자 질의 및 1차 지원을 위해 헬프 데스크와 중앙 지원팀이 여전히 필요할 수 있습니다.
애플리케이션 계층 정의
지원 프로세스와 에스컬레이션 경로를 정의할 때 중요도에 따라 솔루션을 분류하는 것이 중요합니다. 이러한 접근 방식을 사용하면 생산성 시나리오에서 혁신을 저해하는 것을 피하면서 중요한 애플리케이션에 필요한 보호 장치가 있는지 확인하는 프로세스를 만들 수 있습니다.
| 특성 및 프로세스 | 생산성 | 중요 | 위험 |
|---|---|---|---|
| 사용 사례 | 기존 데이터를 사용할 수 있는 개별 생산성 및 소규모 팀 사용 사례. | 간단한 비즈니스 애플리케이션 또는 팀 이니셔티브. 소규모 독립형 협업 프로세스. | 가동 중지 시간 동안 비즈니스에 상당한 영향을 미칠 수 있는 복잡한 비즈니스 애플리케이션, 기업 전체 이니셔티브 또는 미션 크리티컬 워크로드. |
| 복잡성 | 간단한 프로세스. | 중간 복잡성. | 높은 복잡성. |
| 사용자 기반 | 소규모 사용자 기반: 개별 사용자, 직속 동료 또는 소규모 팀. | 사업부 범위 지정. | 대규모 사용자 기반 또는 전사적 사용량. |
| 개발 라이프사이클 | 높은 수준의 반복. | 일반적으로 개발하는 데 3개월 미만. | 더 긴 개발 주기. |
| 영향 | 낮은 비즈니스 영향. | 중요하지만 중요 비즈니스용은 아님(중간 영향). | 높은 비즈니스 영향. |
| 알엠 | 애플리케이션 수명 주기 관리가 필요 없습니다. | ALM이 필요하며, 수동 솔루션 가져오기/내보내기를 통해 달성할 수 있습니다. | 강력한 ALM 프로세스가 필요합니다. ALM은 Azure DevOps 또는 GitHub 파이프라인을 사용하여 구현됩니다. |
| 환경 전략 | 솔루션은 기본 또는 공유 생산성 환경에서 구축됩니다. | 전담 개발 환경, 공유 테스트 및 프로덕션 환경(예: 사업부별 등 다른 솔루션과 공유) 환경은 사업부(분권화) 또는 중앙 IT(중앙 집중화)에서 관리합니다. | 전용 개발/테스트/생산 환경. 환경은 중앙 IT에서 관리합니다. |
| 메이커 권한 | 제작자에게는 환경에 환경 제작자 보안 역할이 있습니다. | 제조업체는 개발 환경에서 환경 제조업체 또는 시스템 사용자 지정자 보안 역할을 가지고 있지만 테스트 및 프로덕션 환경에서는 사용자 보안 역할만 있습니다. 솔루션은 테스트 및 프로덕션에서 서비스 계정 또는 환경 관리자가 소유할 수 있습니다. | 제조업체는 개발 환경에서 환경 제조업체 또는 시스템 사용자 지정자 보안 역할을 가지고 있지만 테스트 및 프로덕션 환경에서는 사용자 보안 역할만 있습니다. 솔루션 배포는 자동으로 이루어지며 솔루션은 테스트 및 프로덕션의 서비스 주체가 담당합니다. |
| IT 참여 | 반응적 거버넌스. IT 부서는 솔루션이 구축되는 상황을 파악하고 사용을 모니터링합니다. | 솔루션 또는 사용자 수준의 IT 이점 제공. 제조업체는 잠재적인 해결 방법 및 사용된 데이터 원본과 같은 솔루션 세부 정보를 제공합니다. | 프로덕션 환경은 IT가 관리합니다. |
| 지원 모델 | 자체 지원. | 팀 보조 지원. | 공식 지원. |
지원 모델을 정의할 때는 졸업 경로를 고려하세요. 솔루션은 생산성 수준의 지원으로 시작하지만 기능이나 사용자 기반이 확대되어 중요 수준의 지원이 필요할 수도 있습니다. 제작자가 보다 공식적인 지원을 요청하고 솔루션을 지원되는 환경으로 전환할 수 있는 방법을 정의합니다.
제조업체 지원(자체 지원)
메이커 지원이란 메이커가 자신, 팀, 동료를 위해 만든 앱과 흐름을 지원하는 것을 말합니다. 지원에는 사용자 질의에 답변하고, 버그를 수정하고, 변경 요청을 처리하는 것이 포함됩니다. 이런 종류의 지원은 비공식적입니다. 즉, 사용자는 종종 제작자를 알고 있으며 제작자에 직접 연락합니다.
중요
신규 제작자를 위한 온보딩 작업의 일환으로 제작자가 지원, 졸업, 에스컬레이션 경로를 알고 있는지 확인하세요. 중요한 비즈니스 수준 솔루션을 지원하는 데 압도된 제작자는 혁신을 하거나 새로운 솔루션을 만들 수 없습니다. 제작자가 자신의 솔루션을 다음 단계의 지원으로 끌어올리는 방법과 그 프로세스가 무엇인지 정의합니다.
제작자에게 프로세스를 사전에 전달하는 것 외에도, 비즈니스에 중요할 수 있는 공유 및 사용률이 높은 솔루션을 파악하기 위한 반응형 거버넌스를 갖추세요. 해당 솔루션에 필요한 지원 가드레일이 있는지 확인하려면 제조업체에 문의하세요. 테넌트 수준 분석 을 사용하여 애플리케이션 사용량에 대해 자세히 알아보거나, 원격 측정 데이터를 데이터 저장 계정으로 내보내어 향상된 보고서를 만들거나, CoE 스타터 키트 를 시작점으로 사용하세요.
팀 보조 지원
팀 지원이란 팀 구성원이 팀을 위해 구축하거나 팀에서 사용하는 앱과 흐름을 공동 소유하고 일상 업무 중에 이러한 솔루션을 지원하는 것을 의미합니다. 지원에는 사용자의 질의에 답변하고, 버그를 수정하고, 변경 요청을 하는 것이 포함됩니다. 나의 챔피언으로 나타나는 제작자는 도움을 주려는 본질적인 욕구가 있기 때문에 자발적으로 이런 유형의 비공식적인 지원 역할을 맡는 경향이 있습니다.
이러한 활동은 종종 비공식적으로 시작되지만, 많은 조직에서는 규모를 확대하기 위해 팀 지원 지원을 공식화합니다. Power Platform 이 프로세스에는 전담 환경을 소유한 사업부가 환경 관리자 역할을 맡고 해당 환경에서 솔루션을 지원하는 것이 포함됩니다. 대규모 조직에서는 각 사업부 내의 전담팀이 이 역할을 맡습니다. Power Platform
헬프 데스크 지원
헬프 데스크는 IT 부서의 공유 서비스로 운영됩니다.
헬프 데스크는 다음을 수행할 수 있습니다.
- IT 부서의 개입 없이는 해결할 수 없는 기술적인 문제를 지원합니다. 예를 들어, 관리자가 관리 센터에서 지원 티켓을 제출해야 하는 서비스 문제가 있습니다. Power PlatformPower Platform
- 애플리케이션에 대한 액세스를 요청하는 방법이나 애플리케이션을 찾을 수 있는 위치 등 사용자 및 거버넌스 관련 질문에 답합니다.
- 중요한 앱 관련 문제는 해당 지원팀에 전달합니다.
전담 Power Platform 지원 팀
채택이 확대되고 제작자가 비즈니스에 더욱 중요한 솔루션을 개발할수록 전담 Power Platform 지원팀이 필요할 수 있습니다.
이 팀은 복잡한 문제를 지원할 수 있는 Power Platform 기술 전문가로 구성되어야 합니다. 지원 티켓을 사용하여 정의된 경로를 통해 이 팀을 지원 프로세스에 참여시킵니다.
이 팀은 중앙에서 지원되는 전용 환경에 배포되는 미션 크리티컬 Power Platform 솔루션을 지원합니다.
조직 구조가 분산된 경우 중앙 Power Platform 지원 팀이 복잡한 쿼리 또는 데이터 정책과 같은 중앙 구성만 지원하도록 지역 또는 사업부에 맞게 팀 지원 지원을 공식화하는 것이 좋습니다. 일부 고객은 이러한 수준의 지원을 파트너에게 아웃소싱하기로 선택합니다.
헬프 데스크에서 요청을 단순히 에스컬레이션 경로로 관리하는 것은 실행하기 어렵습니다. 이러한 Power Platform 기술 전문가는 종종 비즈니스 사용자에게 잘 알려져 있기 때문입니다. 적절한 채널을 통해 이동하는 습관을 장려하기 위해 이 팀은 사용자가 헬프 데스크 티켓을 제출하도록 리디렉션해야 합니다. 또한 헬프 데스크 요청 분석을 위한 데이터 품질도 향상됩니다.
파트너 지원
많은 고객이 지원을 포함하여 Power Platform 채택에 대해 파트너와 협력하기로 선택합니다. 이러한 파트너십에는 메이커를 위한 개발 지원, CoE 및 기술 지원 절차 수립 지원, 중요 앱에 대한 24시간 연중무휴 기술 지원이 포함될 수 있습니다.
Microsoft 지원
Microsoft 지원은 플랫폼 관련 기술 문제를 제기하는 데 사용할 수 있습니다. 지원 플랜에 따라 다양한 기술 지원 및 자문 서비스를 이용할 수 있습니다.
팁
지원 티켓을 제출하기 전에 Power Apps support, Power Automate support 및 Microsoft Copilot Studio support 에서 모든 고객에게 광범위하게 영향을 미치는 우선 순위가 높은 문제가 있는지 확인하세요.
고려 사항 및 주요 조치
자체 지원 및 팀 지원 솔루션을 개선하기 위해 다음과 같은 주요 조치를 고려하세요.
- 제작자에게 인정과 격려를 제공하십시오.
- 제작자들이 자신의 솔루션을 보다 공식적인 지원 채널로 이전하는 프로세스를 알고 있는지 확인하세요.
- 메이커들이 지속적으로 기술을 향상시킬 수 있도록 근무 시간, 멘토링 기회, 교육 세션을 제공합니다.
- 제작자가 기술 전문가와 소통할 수 있는 에스컬레이션 경로를 제공합니다. Power Platform
- 제작자가 앱에 포함할 수 있는 템플릿 구성 요소(예: 사용자가 헬프 데스크에 문의할 수 있는 양식)를 만듭니다. ...
- 특정 사업 분야에서 지원이 필요한 솔루션의 수와 업무량을 기준으로 팀 지원의 공식화를 평가합니다.
내부 헬프 데스크 지원을 개선하려면 다음과 같은 주요 작업을 고려하세요.
- 헬프 데스크에서 처리할 Power Platform 주제의 초기 범위를 결정합니다.
- 지원을 처리하기 위해 헬프 데스크의 준비 수준을 평가합니다.
- 준비 격차를 해소하기 위해 헬프 데스크 직원을 대상으로 추가 교육을 실시합니다.
- 헬프 데스크에서 직접 처리할 수 없는 요청에 대한 에스컬레이션 경로를 결정합니다.
- 알려진 Power Platform 주제에 대한 헬프 데스크 기술 자료를 업데이트하십시오. 새로운 기능과 향상된 기능을 반영하기 위해 지식 기반을 정기적으로 업데이트할 담당자가 있는지 확인하세요. Power Apps 블로그, Power Automate 블로그, Microsoft Copilot Studio 블로그 RSS 피드를 구독하여 최신 소식을 받아보세요.
- 좋은 이슈 추적 시스템이 마련되어 있는지 확인합니다. 우선 순위 수준을 관리할 수 있는 티켓팅 시스템인 경우가 많습니다.
- Power Platform관련 문제에 대한 대기 인력을 결정하세요. 해당하는 경우 연중무휴 지원에 대한 기대치가 명확한지 확인합니다.
- 어떤 SLA가 존재하는지 확인하고 대응 및 해결에 대한 기대 사항을 명확하게 전달하세요.
- 특정 공통 문제를 신속하게 해결할 수 있도록 준비하십시오. 예를 들어, 새 커넥터 사용 요청은 신속하게 처리되어야 합니다. 지원 응답이 느리면 사용자가 해결 방법을 찾을 수 있습니다.
- 헬프 데스크에 Microsoft를 통해 지원 티켓을 제출할 수 있는 보안 역할이 있는지 확인하십시오. 헬프 데스크 또는 전용 지원 팀에서 이러한 문제를 분류할지 결정합니다.
내부 전담 지원을 개선하려면 다음과 같은 주요 작업을 고려하세요. Power Platform
- 헬프 데스크 책임이 끝나는 곳과 전용 지원 책임이 시작되는 곳을 명확하게 정의하십시오.
- Power Platform 전용 지원 팀이 Microsoft 365 및 Azure의 전역 관리자에게 연락할 수 있는 직접적인 에스컬레이션 경로를 갖고 있는지 확인합니다. Power Platform의 범위를 넘어서는 광범위한 문제가 발생하는 경우 이는 매우 중요합니다. 이러한 문제는 사용자 계정 및 권한, 네트워크 구성 또는 솔루션에 사용되는 데이터 소스와 관련이 있을 수 있습니다. Power Platform
- IT 참조 자료를 업데이트할 수 있도록 전용 지원 팀에서 다시 헬프 데스크로 피드백 루프를 만드십시오. 목표는 기본 헬프 데스크가 앞으로 더 많은 문제를 처리할 수 있도록 점점 더 잘 갖춰지는 것입니다.
- 헬프 데스크에서 전용 지원 팀까지 피드백 루프를 만드십시오. 지원 담당자가 중복 또는 비효율성을 관찰하면 해당 정보를 전용 지원 팀에 전달할 수 있으며, 이 팀은 내부 프로세스를 변경하고 개선할 수 있습니다. 예를 들어, 헬프 데스크가 메이커를 위한 새로운 환경을 만들고 구성하는 일로 넘쳐난다면, 전담팀은 CoE 스타터 키트의 환경 요청 관리 구성요소를 사용하여 이 프로세스를 자동화하는 것을 고려할 수 있습니다. Power Platform
- 개인과 팀이 스스로 해결할 수 없는 문제에 직면했을 때 전담 지원팀에 솔루션을 지원할 수 있는 에스컬레이션 경로를 만들어 방해받지 않도록 합니다.
- 솔루션을 지원하는 개인 및 팀에서 전담 지원 팀으로 인계 경로를 만들어 중요한 애플리케이션을 전환할 수 있도록 합니다.
- 전담팀에 솔루션을 전환하기 위한 전반적인 전략을 결정합니다. 예를 들어, 중요하고 필수적인 솔루션의 수가 늘어남에 따라 전담 지원팀의 인력을 늘릴 것인가요, 아니면 사업부가 해당 분야의 지원팀에 인력을 배치하도록 할 것인가요?