View a markdown version of this page

CCoE 설정 - AWS 권장 가이드

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

CCoE 설정

트랜스포메이션 사무소 또는 클라우드 혁신 센터(CCoE)를 통해 클라우드 리더십 기능을 발전시키는 방법을 고려합니다. CCoE는 조직 전체에서 클라우드 기술을 대규모로 구현하기 위한 접근 방식을 개발하고 전파합니다. 클라우드를 성공적으로 채택하려면 관련된 팀 및 부서를 대신하여 발언할 수 있는 담당자를 포함하도록 CCoE를 설계합니다. 처음에는 작게 시작했다가 트랜스포메이션 여정을 진행하면서 필요에 맞게 CCoE를 점진적으로 발전시킵니다. AWS 계정 관리자 및 솔루션 아키텍트와 같은 기본 클라우드 제공업체 담당자가 CCoE 생성을 안내하는 리소스를 제공할 수 있습니다. CCoE는 주제 전문 지식을 확립하고, 동의를 얻으며, 조직 전체에서 신뢰를 얻고, 미션 요구 사항을 충족하기 위한 효과적인 지침을 수립하는 능력을 가속화합니다. 모든 기관에 사용할 수 있는 단일 조직 구조는 없지만, 다음 질문은 고유한 CCoE를 설계하는 데 도움이 됩니다.

  • CCoE에 누가 포함되어야 하나요?

    처음에는 CCoE에 얼리어답터와 클라우드 옹호자 몇 명만 포함될 수 있습니다. CCoE는 여전히 작을 수 있지만 클라우드 채택의 영향을 받는 비즈니스 기능과 기술 기능을 모두 담당할 수 있는 옹호자를 포함하도록 발전해야 합니다. 비즈니스 기능에는 변경 관리, 이해관계자 요구 사항, 거버넌스, 교육, 조달 및 통신이 포함됩니다. 이러한 기능은 일반적으로 기관의 관리 및 교육 팀 멤버가 대표합니다. 기술 기능에는 인프라, 자동화, 운영 도구, 보안, 성능 및 가용성이 포함됩니다. 이러한 기능은 일반적으로 기관의 IT 팀 멤버가 대표합니다. 또한 CCoE는 주제 전문 지식을 제공하기 위해 필요에 따라 벤더 및 파트너를 참여시켜야 합니다. CCoE는 유기적인 조직입니다. 멤버십, 양식 및 기능은 시간이 지남에 따라 변경될 가능성이 크며 향후 성숙도 시점에 해체될 수도 있습니다.

  • CCoE는 이해관계자와 어떻게 상호 작용하나요?

    CCoE는 다른 팀을 지원하며 클라우드 채택을 성공적으로 알리고 활성화하기 위해 설계되었습니다. 다양한 부서, 학교 및 기능 부문에서 CCoE의 임베딩 부분을 살펴봅니다. 이를 통해 더 광범위한 리소스에 액세스하고 내부 피드백을 더 빠르게 제공할 수 있습니다. 초기에 이해관계자 사이에서 열린 통신 라인과 파트너십 구축에 집중하여 기관 내에서 신뢰를 쌓고 조직 사일로를 해소합니다. CCoE에는 이해관계자와 소통하고, 피드백을 수집하며, 사용자를 교육하기 위한 메커니즘이 정의되어 있어야 합니다. CCoE의 성공 지표는 이러한 협업 및 통신을 반영해야 합니다. 팀이 기술 빌드를 기준으로만 측정되는 경우 앞으로 더 많은 기술이 빌드되어도 해당 사용 및 성과는 나중의 고려 사항입니다. 대신 지표로, CCoE의 작업을 통해 자체적으로 충분한 팀 수, CCoE가 이니셔티브의 중요한 경로에 존재하는 횟수, 진행된 교육 이벤트 수 또는 CCoE 출력 채택 범위와 같은 사항을 측정해야 합니다. 잘 구성되고 신뢰할 수 있는 CCoE는 신뢰를 기반으로 구축된 더 큰 조직 트랜스포메이션을 위한 초석이 될 수 있습니다.

  • CCoE를 설정하려면 어떻게 해야 하나요?

    대부분의 조직은 특정 대상 파일럿 프로젝트에서 클라우드 채택을 시작합니다. 이러한 프로젝트의 일부로 CCoE를 설정합니다. 좋은 출발은 전체 여정의 성공을 정의하는 데 매우 중요합니다.

    • 비즈니스 문제부터 시작합니다. 기술을 위한 기술은 잘못된 전략입니다. 클라우드 기술을 실험하는 경우 작은 규모라도 매력적인 비즈니스 사용 사례를 식별합니다. 그런 다음 해당 사용 사례부터 작업을 시작해 기술이 어떻게 도움이 될 수 있는지에 대한 명확한 목표를 세웁니다. 사일로에서 솔루션을 구현하지 마세요. 프로젝트 구현 이전과 도중에 비즈니스 이해관계자로부터 지속적인 의견을 구합니다. 성공적인 모든 클라우드 프로젝트는 기술을 사용할 기관 유닛과의 긴밀한 협업에 의존합니다.

    • 작게 시작합니다. 양방향 문을 제공하는 위험도가 낮은 프로젝트를 선택합니다. 즉, 프로젝트를 되돌릴 수 있으며 실수를 신속하게 수정할 수 있습니다. 파일럿 프로젝트는 모두 실험에 관한 것입니다. 대규모 고위험 프로젝트를 피하면 구현과 결과를 더 잘 제어할 수 있습니다. 광범위한 목표 대신 구체적이고 정의 가능한 문제를 대상으로 하는 데 도움이 됩니다. 예를 들어 자동화가 궁극적인 목표인 경우 전체 작업 대신 특정 태스크의 자동화를 목표로 합니다.

    • 성과를 정의하고 측정합니다. 명확한 지표를 설정하여 각 프로젝트의 진행 상황과 성과를 평가합니다. 이해관계자 간 기대치의 불일치를 방지하기 위해 원하는 종료 상태를 미리 정의합니다. 비즈니스 이해관계자 및 조직 내 다른 리더와 긴밀히 협력하여 기대치와 측정 가능한 이익을 정의합니다. 또한 결과를 비기술적 언어로 변환하는 것도 중요합니다. 프로젝트가 보존을 개선하고 이탈을 줄이는 방법, 비용을 낮추고 전달 속도를 높이는 방법 등 기관의 목표에 대해 논의합니다.

    • 안전 영역에서 시작합니다. 기관이 익숙한 도메인에서 프로젝트를 선택합니다. 그러면 프로젝트에 실제 영향을 미치는 의미 있고 이해하기 쉬운 목표가 있는지 확인할 수 있습니다. 이러한 프로젝트는 신뢰를 구축하고 조직에 대한 장기적인 결과를 선사합니다. 예를 들어 데이터 분석에 대한 전문 지식이 이미 있는 경우 분석 프로젝트로 시작하여 기존 기술을 활용하면서 클라우드 여정을 시작할 수 있습니다. 모든 기관은 여러 전문 지식을 보유하고 있으며 성공적인 디지털 트랜스포메이션 전략을 수립하려면 고유한 구성 요소를 파악해야 합니다.