프로그램의 계획, 승인과 지원 절차
프로그램 거버넌스는 업무의 목적, 필요한 데이터, 행동할 수 있는 사용자와 결정의 검토 방식을 정합니다. 개인정보 보호 및 시민적 자유에 관한 판단도 운영 출시 전의 계획에 포함해야 합니다.
다음은 조직이 조정해 사용할 수 있는 운영 모델입니다. 회의 이름이나 주기를 모든 조직에 강제하는 규정은 아니며, 실제 책임자와 업무 규모에 맞춰 적용합니다.
계획과 개발의 주기
| 절차 | 시작 단계 | 주기 | 책임자 | 주요 참여자 |
|---|---|---|---|---|
| SteerCo | 1단계부터 | 분기 | Head of Program | Program Manager, 경영진 및 주요 이해관계자, 업무 영역 책임자 |
| 개발 및 로드맵 검토 | 1단계부터 | 월간 | Program Manager | Head of Program, 업무 영역 책임자 |
| Standup | 1단계부터 | 매일 | Data Lead | Ontology Lead, Use Case Lead, 필요 시 Data Governance Administrator |
| Sprint planning | 1단계부터 | 격주 | Data Lead | Ontology Lead, Use Case Lead, 필요 시 Data Governance Administrator |
SteerCo
운영위원회는 플랫폼 전체의 전략 방향, 범위와 비용을 검토합니다. 우선순위가 높은 개별 프로젝트도 논의할 수 있지만 그 프로젝트만을 다루는 회의로 만들지 않습니다.
주요 안건은 운영 중이거나 개발 중 및 검토 중인 사례의 비용, 진행과 가치, 사용자 수 및 그룹이나 사례별 사용 변화, 전사 IT 목표 안에서의 Foundry 위치입니다.
개발 및 로드맵 검토
지난달 진행과 다음 달 산출물 및 장기 방향을 맞춥니다. 진행 중 개발, 기존 사례 개선과 새 사례의 우선순위를 함께 다룹니다.
안건에는 진행 현황, 사업 타당성과 가치 확인, 프로젝트 계획 변경 승인, 산출물 우선순위 결정, 개발 전략 검토 및 승인, 성공을 막는 주요 문제의 해결 방안이 포함됩니다.
Standup
30분 미만의 짧은 회의에서 각 구성원이 전날 작업, 오늘 작업과 진행을 막는 문제를 공유합니다. 상세 설계 논의와 별도로 현재 진행 및 의존 관계를 확인하는 데 집중합니다.
Sprint planning
이전 스프린트의 완료 및 미완료 작업을 확인하고 다음 스프린트 범위를 정합니다. 팀의 목표와 산출물, 장애 요인 및 우선순위 변화, 가용 인력과 요구사항 변경을 검토합니다. 이후 작업 크기를 추정하고 포함할 범위와 담당자를 정합니다.
플랫폼 거버넌스
| 절차 | 시작 단계 | 주기 | 책임자 | 주요 참여자 |
|---|---|---|---|---|
| 프로젝트 생성 검토 | 1단계부터 | 월간 | 1단계 Head of Program, 2단계부터 Head of Data Governance | Program Manager |
| 프로젝트 접근 검토 | 1단계부터 | 상시 | 같은 단계별 책임자 | Program Manager |
| 데이터 권한 검토 | 1단계부터 | 상시 | 같은 단계별 책임자 | Use Case Lead |
프로젝트 생성
이 운영 모델에서는 프로그램팀이 Project Creation Request Portal과 Project Approval Inbox라는 접수 및 승인 앱을 구축합니다. 사용자는 생성 요청을 제출하고 담당자는 승인하거나 거절합니다. 두 앱은 프로그램팀이 업무에 맞게 만드는 앱입니다.
승인하면 요청에 맞는 그룹과 역할을 적용해 프로젝트를 만듭니다. 공간(Space)의 프로젝트 생성 권한을 중앙 플랫폼 거버넌스팀에 제한하는 구성을 권장하며, 그 팀을 구성하는 역할은 프로그램 성숙도에 따라 바뀔 수 있습니다.
프로젝트 접근
프로젝트 역할은 지정한 그룹을 통해 부여하고 가능하면 조직 IdP의 그룹과 연결합니다. 담당자는 Project Approval Inbox에서 접근 요청을 검토해 승인하거나 거절합니다. 승인하면 요청자를 해당 역할을 가진 그룹에 추가합니다.
그룹을 IdP에서 관리하면 조직 계정을 IdP 그룹에, Foundry 내부에서 관리하면 Foundry 계정을 내부 그룹에 추가합니다. 개별 사용자에게 프로젝트 역할을 직접 부여하는 방식은 일반 운영 경로로 권장하지 않습니다.
데이터 권한
권한 범위는 데이터셋이나 파이프라인 전체에서 개별 행의 가시성까지 달라질 수 있습니다. 프로젝트 생성 검토 때 필요한 접근 구조를 정하고 개발 중에 구체적으로 문서화 및 적용합니다. 접근 통제와 데이터 보호를 업무 목적에 맞게 연결합니다.
사용자 지원과 교육
| 절차 | 시작 단계 | 주기 | 책임자 | 주요 참여자 |
|---|---|---|---|---|
| 내부 지원 체계 개발 | 1단계부터 | 상시 | Data Lead, Program Manager | 업무 영역 책임자, Data Governance Administrator, Use Case Lead |
| 교육 체계 개발 | 2단계부터 | 상시 | Education & Training Expert | 업무 영역 책임자, Use Case Lead |
지원 체계
내부에서 문의를 분류, 조사 및 해결할 수 있어야 프로그램이 자립할 수 있습니다. Palantir에 전달할 문제도 충분한 기술 및 업무 맥락을 정리한 뒤 올릴 수 있습니다.
1~2단계에는 프로그램팀이 지원을 함께 맡을 수 있습니다. 2단계부터는 전담 내부 Foundry 지원팀을 만드는 것이 권장됩니다. 사례가 늘어나는 3단계에는 플랫폼 관리와 지원의 전담 책임을 특히 강화합니다.
교육 체계
Palantir의 공통 교육과 함께 조직의 각 사례에 맞는 내부 과정을 만듭니다. 데이터 계보와 온톨로지 구성 요소를 문서화하고 핵심 앱을 사용하는 실습을 유지합니다.
플랫폼 내부 및 외부 문서, 화면 안내, 녹화 교육과 대면 실습을 조합할 수 있습니다. 사용자가 실제 수행할 업무와 필요한 역할별 이정표를 정하고 결과에 맞춰 교육을 개선합니다.
프로그램의 역할별 책임은 단계별 운영 모델을 참조합니다.