계획 단계 모범 사례

그린필드 SAP 구현의 계획 단계에서 프로젝트는 일반적으로 다양한 과제와 기회에 직면합니다. 이 섹션에서는 AWS 전문 서비스 팀이 관여한 AWS 그린필드 구현에 대한 SAP 기반 5가지 주요 학습에 대해 설명합니다. 프로젝트가 시작되거나 컨설팅 팀이 참여하기 전에도 이러한 권장 사항 중 일부를 구현할 수 있습니다. 역할 및 책임 매트릭스 또는 팀 연락처 목록과 같은 문서 초안을 제공하면 램프업 프로세스를 속도를 높이는 데 도움이 됩니다.

RACI 매트릭스 구축

인프라 팀을 위한 책임 할당 매트릭스 구축은 모든 구현 프로젝트에서 매우 중요합니다. 이 매트릭스는 포괄적인 RACI(Responsible, Accountable, Consulted, and Informed) 차트의 형태를 취합니다. RACI는 복잡한 팀 구조에서 역할, 할당 및 작업을 명확히 하는 데 사용됩니다. SAP 클라우드 팀, AWS SAP Basis 팀, SAP 시스템 통합자(SI) 및 고객과 협력하여 개발해야 합니다. 이러한 그룹이나 프로젝트 관리자가 매트릭스 개발을 주도할 수 있습니다. 이러한 이해관계자의 의견 없이 RACI를 구축하면 불일치와 격차는 물론 충돌이 발생하기도 합니다. 프로젝트의 모든 단계를 고려하는 것이 중요합니다. RACI를 미리 준비하면 모든 관련 당사자 간의 파트너십이 강화되고 명확성이 높아집니다. 프로젝트가 시작되기 전에 RACI를 완료하는 것이 가장 좋습니다.

다음은 그린필드 SAP 구현 프로젝트를 위한 샘플 RACI 매트릭스에서 발췌한 것입니다.

전체 RACI 매트릭스 다운로드

SoW 검토

AWS 컨설팅 및 자문 서비스에 대한 작업 기술서(SoW)의 모든 요소를 이해하고, 주요 이해관계자와 함께 SoW를 검토하여 모든 사람이 결과물을 명확하게 이해할 수 있도록 합니다. 인프라 팀이 SoW가 정의한 것보다 더 많은 작업을 수행하려는 경우 위험, 가정, 작업, 문제, 종속성 및 결정(RAAIDD) 로그에 이를 기록해야 합니다. 그린필드 SAP 구현 프로젝트에서는 민첩함과 민첩성을 유지하는 것이 가장 중요하므로 SoW에서 벗어나는 것이 일반적인 시나리오입니다. 그러나 AWS 구현 파트너가 문서화된 것 이상으로 제공하기 시작하면 기대치가 가려질 수 있습니다. 변경 사항이 발생할 경우 새 작업 범위와 절충해야 할 사항을 나열한 목록을 작성해 두어야 합니다. 워터폴 프로젝트 접근 방식의 경우 범위 변경 관리 프로세스를 정의하고 구현해야 합니다. 애자일 프로젝트의 경우 백로그 우선순위 지정 프로세스가 범위를 관리하는 데 더 적합합니다.

고려 사항:

• 프로젝트를 진행하면서 새 범위를 파악하고 새 결과물을 정의해야 합니다. 이렇게 하면 기대치를 관리하고 백로그의 우선순위를 정하는 데 도움이 됩니다.

• 기존 배송 백로그와 함께 문서 변경 및 작업을 식별하고 우선순위를 지정하면 문서를 끝까지 미루지 않고 프로젝트 수명 주기 내내 작성할 수 있습니다.

• 프로젝트 전반에 걸쳐 SoW 연습을 정기적으로 수행하여 결과물과 우선 순위를 일관되게 유지합니다.

• 프로덕션 전환의 경우 하이퍼케어 지원에 도움이 되도록 최소 12개월 전에 읽기 전용 액세스 권한이 있는 SoW를 승인해야 합니다.

팀 조직도 및 연락처 목록 작성

팀과 리더십 구조를 보여주는 개괄적인 조직도를 작성합니다. 인프라 팀의 모든 멤버 이름, 직함, 역할, 보안, 네트워크 및 방화벽 운영, Microsoft Active Directory, 사내 클라우드 운영, 서버 운영과 같은 다양한 부서의 주요 연락 담당자가 포함된 팀 간 연락처 목록을 작성하여 보다 심층적으로 정보를 제공합니다. 프로젝트에 누가 참여하고 어떤 역할을 하는지 모두 알아야 합니다. 팀에 이 정보가 없으면 지연과 잘못된 의사 소통이 발생할 수 밖에 없습니다. 이해관계자의 직함을 이해하는 것도 중요합니다. 예를 들어, 논의에 핵심적인 기여자가 아닌 이상 디렉터급 이해관계자를 실무 설계 세션이나 일일 스탠드업 미팅에 초대하고 싶지는 않을 것입니다. 직함과 역할을 알면 적절한 사람들을 관련 회의에 초대할 수 있습니다. 조직도에서 팀을 시각화할 수 있으면 팀이 어떻게 구성되어 있는지 이해하고 프로젝트에서 함께 작업하는 방법을 이해하는 데 도움이 됩니다.

다음 다이어그램은 AWS 인프라 조직 차트의 일반적인 SAP의 예를 제공합니다.

사내 클라우드 팀과 함께 참여 모델 수립

IT 조직에 사내 AWS 클라우드 팀이 있는 경우 해당 팀과 참여 모델을 수립하고 AWS 구현 파트너(예: AWS 전문 서비스 또는 AWS 파트너)가 수행해야 하는 작업과 비교하여 해당 팀이 수행할 작업을 명확히 해야 합니다. 고려해야 할 주요 책임은 환경을 구축하고 인도한 후 지원하는 것입니다. 예를 들어 수십 개의 AWS SAP 애플리케이션을 위한 다중 환경 인프라를 구축하는 SAP Cloud 아키텍트가 두 명뿐인 경우 새 환경의 구축과 구축을 완료하는 환경을 동시에 지원할 수 있는 대역폭이 없습니다. 한 가지 옵션은 사내 클라우드 팀에 완성된 환경에 대한 지원을 맡아달라고 요청하는 것입니다. 이를 통해 사내 팀은 환경에 대해 배우고 소유권을 확보할 수 있습니다. 프로젝트가 진행되고 새로운 작업 범위가 정해지면 결국 사내 팀이 이러한 환경을 유지 보수하고 확장하는 책임을 맡게 됩니다.

또한 사내 클라우드 인프라 및 클라우드 DevOps 팀은 사용할 자동화 소프트웨어 유형, 예를 들어 AWS CloudFormation 또는 Terraform을 코드형 인프라(IaC) 도구로 사용할지 여부에 동의해야 합니다. 마찬가지로 부트스트래핑 볼륨 및 SAP 설치와 같은 구성 작업에 AWS Systems Manager 또는 Ansible을 사용하기로 결정할 수 있습니다. 이러한 결정을 문서화해야 합니다. 또한 서드 파티 모니터링 및 관찰성 대시보드에 대한 요구 사항이 있지만 SoW에서 이것이 결과물이 아닌 경우, 그 사이에 Amazon CloudWatch 및 Amazon Simple Notification Service(Amazon SNS)를 사용하여 모니터링 및 로깅 후크를 배치하는 것이 좋습니다. 사내 클라우드 팀은 나중에 타사 모니터링 솔루션과의 통합을 구현할 수 있습니다.

참여 모델 또는 지원 계약도 RACI 매트릭스의 일부여야 하며 SoW에 명시되어 있어야 합니다. AWS 서비스를 사용하여 달성할 수 있는 상당한 수준의 자동화가 있습니다. SoW 및 RACI 매트릭스는 그린필드 SAP 구현 프로젝트의 일환으로 달성해야 할 사항과 운영 팀에 위임할 수 있는 사항을 식별해야 합니다.

참여 모델을 설정할 때 폭포, 애자일 또는 혼합 접근 방식이 발전을 위한 주요 방법인지 확인합니다. AWS 전문 서비스에서는 폭포 접근 방식에 비해 민첩하거나 혼합된 접근 방식을 구현한 참여에서 작업 완료가 300% 증가하고 계획 시간이 94% 감소하는 것을 관찰했습니다. 계획 단계에서는 고객의 도움을 받아 커뮤니케이션 계획 및 도구 접근 방식도 선택해야 합니다. 다음 표에는 샘플 통신 계획이 나와 있습니다.

마지막으로 프로젝트를 조기에 지원할 고객과 SAP Basis 팀을 식별해야 합니다. 새로운 솔루션을 구현하고 마이그레이션할 때 이를 교육하는 것이 지식 이전 세션을 조기에 시작하는 데 중요합니다.

클라우드 구축 및 배포 프로세스 문서화

IT 조직에 사내 클라우드 팀이 있는 경우 해당 팀은 프로세스 흐름도를 사용하여 클라우드 구축 및 배포 프로세스를 문서화하고 이 다이어그램을 팀 전체와 공유해야 합니다. 주요 이해관계자가 프로세스의 병목 현상이나 비효율성을 쉽게 탐지하고 기존 내부 프로세스가 비효율성이나 지연을 초래하는 역할을 이해하고자 합니다. 다음 예제에서는 Active Directory 조인 및 도메인 이름 시스템(DNS) 업데이트 프로세스를 완료하는 데 어떻게 가장 오랜 시간이 걸리는지 확인할 수 있습니다. 이러한 시각적 자료가 있으면 팀이 공동 작업하고 프로세스의 해당 단계에 소요되는 시간을 줄이는 방법을 찾도록 동기를 부여할 수 있습니다.

고려 사항:

• 헬프 데스크 프로세스와 워크플로를 별도로 문서화하고, 이 정보를 인프라 팀과 공유하고, 모든 사람이 헬프 데스크 도구에 액세스할 수 있도록 하여 한 사람에게 의존하지 않도록 합니다. Active Directory 조인, DNS 업데이트, 방화벽 열기 및 암호화 키 요청을 수행하는 데 복잡하고 시간이 많이 걸리는 티켓 프로세스가 있는 경우가 많습니다. 프로젝트 계획 단계에서 이러한 프로세스를 문서화하고 각 팀의 서비스 수준에 관한 계약(SLA)을 고려하는 것이 중요합니다. 이는 제거에 특별한 주의가 필요한 지연이나 병목 현상의 이유를 설명하는 데도 도움이 됩니다.

• Active Directory와 방화벽 또는 네트워킹 작업을 위한 전담 담당자를 지정합니다. 이러한 전용 리소스는 프로젝트의 일부여야 합니다. 서비스 티켓에 의존해야 하는 경우 서비스 SLA를 제어할 수 없습니다.

프로젝트 로드맵 및 마일스톤 트래커

다음 차트는 다년간의 SAP on AWS greenfield 프로젝트에 대한 예제 로드맵을 제공합니다.

다음 차트는 동일한 프로젝트에 대한 AWS Professional Services의 참여 타임라인 예제를 보여줍니다.

다음 차트는이 프로젝트의 가동 마일스톤 트래커를 보여줍니다.