Data Vault 2.0 접근 방식의 프로젝트 계획 기능은 PMP 에서 제공됩니다. 민첩한 Scrum 방법과 달리 sprint 의 공식적인 프로젝트 계획을 강조합니다. 각 프로젝트에는 완료할 작업, 작업 출력의 예상 결과 및 작업을 수행할 역할을 포함하는 프로젝트 계획이 있습니다. 프로젝트 유형에 따라 프로젝트를 수행하는 역할 유형이 다릅니다.
비즈니스 후원자: 프로젝트, 비즈니스 및 비전 간에 일관성을 유지해야 합니다.
기술 비즈니스 분석가: 비즈니스 부서에 보고하지만 데이터 모델 이해, 직접 SQL 사용 또는 작성 기능 등 특정 기술 기술을 갖춘 고급 사용자입니다.
프로젝트 관리자: 프로젝트 팀이 프로젝트를 완료하도록 할 책임이 있습니다.
IT 관리자: 무중단 업무 운영 및 비즈니스 성공을 보장합니다.
ETL 개발자: ETL (추출, 변환 및 로드) 프로세스를 담당하는 개발자입니다.
보고서 개발자: 정보 마트, 업무 창고 테이블 또는 (드문 경우) 원시 데이터 웨어하우스에서 직접 업무 중심 보고서를 구현합니다.
데이터 설계자/정보 설계자: 정보 아키텍처 및 데이터 통합을 담당합니다.
메타데이터 관리자: 메타데이터 빌드를 담당합니다.
변경 관리자: 새 기능이 시작될 때 다른 IT 또는 비즈니스 서비스를 방해하지 않도록 하고, 새 릴리스가 환경 내에서 진행되며 다른 프로젝트의 방해를 받지 않도록 해야 합니다.
많은 조직에서 역할을 정의하는 대신 책임을 사람에게 잘못 지정합니다. 팀에서 역할을 정의하면 이 역할의 사람이 다른 숙련된 사람으로 대체될 수 있다는 장점이 있습니다. 예를 들어, 현재 사람이 조직을 떠나거나 프로젝트를 변경하는 경우입니다. 역할 정의는 여러 가지 방법으로 조직에 도움이 됩니다. 이러한 역할 정의는 인적 자원 부서가 자유 시장에서 업무에 적합한 사람을 찾는 데 도움이 됩니다. 신입 사원은 자신의 책임을 신속하게 파악하고 자신이 완성해야 할 일을 완성할 수 있다. 마지막으로, 명확한 책임은 팀이 개발 프로젝트에서 자연스럽게 발생하는 문제를 처리할 때 누가 무엇을 할 것인지 결정하는 데 도움이 됩니다.
데이터 웨어하우스에서 프로젝트 팀은 이미 제시된 대부분의 역할을 알고 있습니다. 기술 비즈니스 분석가는 예외입니다. 이 역할은 비즈니스와 IT 사이의 중간 기능 역할을 합니다. 그림 3.2 는 이 역할의 특징과 책임에 대한 자세한 정보를 제공합니다.
이 역할은 업무와 IT 사이에 있기 때문에 기술 업무 분석가의 업무는 쌍방의 관계를 완화하고 쌍방 사이에' 벽 뒤집기' 를 방지하는 것이다. 이런 쌍방이 서로 이해하지 못하고 공동의 노력을 지지하는 마음가짐이 종종 프로젝트 실패의 근본 원인이다. 이러한 프로젝트의 특징은 비즈니스 요구 사항이 명확하지 않고, 기술 가공소재가 비즈니스 요구 사항을 충족하지 못하며, IT 가 이해하는 요구 사항을 충족하지 못하며, 테스트되지 않았거나 테스트가 불완전하여 (비즈니스 관점에서) 발생하는 소프트웨어가 신뢰할 수 없다는 것입니다. 보통 쌍방은 서로 비난하는데, 쌍방은 모두 상대방이 잘못을 저질렀다고 매우 확신한다.
이것이 Data Vault 2.0 팀이 비즈니스 역할을 IT 역할과 분리하지 않는 이유입니다. 반대로, 이 두 집단은 협력해야 하며, 각 캐릭터는 자신의 의무에 주의를 기울여야 한다. 가능하다면, 팀은 효율성을 높이기 위해 같은 장소에서 일해야 한다. 비즈니스와 IT 간, 그리고 각 역할 간에 어느 정도의 공동 작업과 상호 이해를 구축하여 이전 단락에 요약된 상황을 방지하는 것이 중요합니다. 이것은 프로젝트 관리자의 책임입니다. 만약 팀이 프로젝트 과정에서 분리되기 시작한다면, 그들은 지속적인 행동이 필요하다.
업무방면에서 세워야 할 부분 이해는 2 주간의 스퍼트 단계에서 비교적 일상적인 문제의 영향을 받지 않는 작업 방식이 필요하다는 것이다. 운영 중인 문제는 반드시 다음 스퍼트에 배정해야 한다. 이를 위해 IT 부서도 IT 부서의 참여 없이 일부 (다수가 아닌 경우) 문제를 스스로 해결할 수 있도록 해야 한다는 생각을 바꿔야 합니다. 이것이 바로' 관리형' 셀프 서비스 비즈니스 인텔리전스 (BI) 가 작용하는 곳이다. Data Vault 2.0 표준은 IT 부서에 비즈니스 사용자가 직접 사용할 수 있는 방식으로 데이터를 제공하는 방법에 대한 지침을 제공합니다. 이를 위해서는 책임을 기업에 이전해야 한다. 예를 들어, 엔터프라이즈 데이터 웨어하우스의 데이터를 복구하여 비즈니스 시스템의 오류를 보완해서는 안 됩니다. 이러한 오류를 수정하는 것은 비즈니스 부서의 책임이므로 IT 부서는 데이터 웨어하우스를 통해 비즈니스 단위로 데이터를 다시 전송할 수 있습니다. 여기서 비즈니스 규칙을 적용하여 데이터를 정보로 변환할 수 있습니다. 이 지식을 사용하여 일반적으로 사용되는 정보 시장을 표준화합니다.
어떠한 중단도 방지하기 위해 시스템 요구 사항 변경에는 정해진 절차가 필요합니다. 그림 3.3 은 이 DataVault2.0 요구 사항 변경에 대한 커뮤니케이션 프로세스를 보여줍니다.
그림 3.3 커뮤니케이션 프로세스 3.3 DataVault2.0 요구 사항 변경 사항
새 변경 요청은 일반적으로 프로젝트의 비즈니스 측면에서 가져옵니다. 위험과 현재 운영 시스템에 미치는 영향을 평가해야 합니다. 이러한 이유로 변경 요청은 비즈니스 사용자가 후원자 (요구 사항 변경의 우선 순위를 결정) 및 기술 비즈니스 분석가 (비즈니스 요구 사항을 기술 프로젝트로 전환 지원) 를 통해 일정을 담당하는 IT 관리자 및 프로젝트 관리자에게 전달됩니다. 위험 평가를 완료하면 해당 정보를 업무 부서에 반환하므로 위험 및 영향 평가에 따라 요구 사항 변경 여부를 최종 결정할 수 있습니다. 업무 부서가 수요 변경을 계속 처리하기로 결정할 경우 IT 부서는 업무 부서의 이전 우선 순위에 따라 다음 스프린트 단계에서 수요 변경을 계획합니다. 그런 다음 새 가공소재의 개발 및 후속 배송을 담당합니다. 비즈니스 직원이 변경 사항을 테스트 (개발 테스트 제외) 하고 변경 사항을 수락한 후 공식 서명은 IT 부서가 해당 요구 사항 변경에 대한 더 많은 책임에서 벗어날 수 있도록 합니다.
새로운 버전의 데이터 웨어하우스 시스템을 개발할 때 개발 팀은 기존 소프트웨어 개발 팀과 동일한 방법을 사용합니다. 이들은 개발 프로세스 초기에 알파 (베타) 버전을 사용하여 새 버전을 테스트했고, 베타 (베타) 버전은 제한된 비즈니스 고객을 대상으로 쉽게 테스트할 수 있으며, 감마 (후보) 버전을 제작했습니다. 알파 (베타) 버전은 기술 비즈니스 분석가가 될 때까지 기술 팀 구성원에게만 영향을 주어야 합니다.
기술 IT 팀 외에도 알파 버전에는 일반적으로 3 ~ 5 명의 기술 비즈니스 분석가가 있습니다. IT 부서에서 분석가에게 새로운 보고서를 발표할 때, 보고서나 큐브 (데이터 세트) 의 정보가 잘못되었거나 좋지 않을 수 있기 때문에 이러한 보고서가 업무 부서에 배포되지 않을 것임을 분명히 해야 합니다. 그러나 기술 비즈니스 분석가는 이러한 오류를 찾거나 오산을 식별하는 데 도움이 되는 보고서를 받게 됩니다. 데이터 웨어하우스 프로젝트의 처음 두세 번의 스퍼트 이후 알파 버전은 일반적으로 기술 비즈니스 분석가에게 배포됩니다.
새 버전이 테스트 상태에 도달하면 더 많은 기술 비즈니스 분석가, 비즈니스 후원자, 선택된 비즈니스 관리자 및 새 버전의 기능에 대한 기득권을 가진 다른 사용자에게 표시됩니다.
베타 버전은 IT 및 영업 담당자의 철저한 테스트를 거쳤으며 더 이상 명백하거나 알려진 오류를 포함하지 않습니다. 그러나 게시 상태의 특성상 생성된 보고서는 유통에 적합하지 않습니다. 반면, 제한된 팀은 이러한 보고서를 사용하여 개발 및 기술 비즈니스 분석가가 지금까지 식별하지 못한 문제를 식별합니다. 제한된 팀이 제품 출시 준비에 동의하면 데이터 웨어하우스 시스템은 감마 (후보) 상태가 됩니다.
감마 또는 프로덕션 버전이 배포되어 모든 비즈니스 사용자에게 제공됩니다. 이 방법은 Data Vault 2.0 메서드의 일부인 CMMI 를 엄격하게 따릅니다. 후속 문장 에서는 Data Vault 2.0 의 CMMI 방법에 대해 설명합니다.