조직 및 사용자 관리

제품 개발 과정에서 역할(Role)과 팀(Team)은 데이터 접근, 작업 할당, 협업을 효율적으로 관리하는 데 핵심적인 요소

1. Windchill에서 역할(Role)의 개념

역할은 Windchill 내에서 사용자가 특정 작업이나 책임을 수행하도록 정의된 권한 집합입니다. 역할은 사용자의 직무와 관련된 활동을 그룹화하여 데이터 접근 및 작업 흐름을 체계적으로 관리합니다.

▷ 역할의 정의:

• 역할은 제품(Product), 라이브러리(Library), 프로젝트(Project) 등의 컨텍스트(Context) 내에서 정의됩니다.
  예: 디자이너(Designer), 리뷰어(Reviewer), 제품 관리자(Product Manager), 변경 관리자(Change Administrator) 등.
• 각 역할은 특정 작업(예: 데이터 수정, 승인, 검토)에 대한 권한(Access Control)을 가집니다.
• 예를 들어, "설계자(Designer)" 역할은 문서 생성 및 편집 권한을, "승인자(Approver)" 역할은 변경 요청 승인 권한을 가질 수 있습니다.

▷ 권한(Access Control) 정의:

역할에 부여된 권한은 접근 제어 정책(Access Control Policies)을 통해 설정됩니다. 주요 작업 권한은 다음과 같습니다:

• 읽기(Read): 객체(문서, CAD 파일 등) 조회.
• 쓰기(Modify): 객체 편집.
• 생성(Create): 새 객체 생성.
• 삭제(Delete): 객체 삭제.
• 승인(Approve): 변경 요청 또는 워크플로우 승인.
• 관리(Administer): 객체의 권한 또는 속성 관리.

▷ 제품 > 팀 > 로컬 팀 역활 및 멤버 

[필터 : 로콜팀 역활 및 멤버]

1) 제품 매니저(Product Manager)

제품 수명주기 관리(PLM) 프로세스 내에서 제품 개발, 데이터 관리, 팀 조정, 워크플로우 감독을 책임지는 핵심 역할

프로젝트/프로그램 관리:

• 제품 개발 프로젝트의 범위, 일정, 자원을 정의하고 관리.
• Windchill ProjectLink를 활용해 프로젝트 계획 수립, 작업 할당, 진행 상황 추적.
• 마일스톤 설정 및 주요 성과 지표(KPI) 모니터링.

팀 조정 및 역할 할당:

• 로컬 팀 및 공유 팀의 구성원을 추가/제거하고 역할(예: 설계자, 검토자, 상담자)을 지정.
• 참여자 관리 유틸리티를 통해 사용자, 그룹, 조직의 권한 관리.
• 팀원의 작업 표시(Tasks View) 구성 및 역할별 권한 설정.

데이터 및 워크플로우 관리:

• Windchill PDMLink를 사용해 CAD 데이터, BOM(부품표), 문서, 변경 요청 등을 중앙에서 관리.
• 변경 관리 프로세스(예: 변경 요청, 문제 보고서, ECO/ECN) 감독.
• 워크플로우 자동화를 설정하여 설계 검토, 승인, 릴리스 프로세스 효율화.

제품 현지화 및 변형 관리: (옵션 라이선스 필요)

• 지역별 요구사항을 반영한 제품 변형 생성(예: FlexPLM 활용 시 패션/리테일 제품의 지역별 스타일 조정).
• 구성 관리자를 지원하여 모듈식 제품군 구성 및 관리.

품질 및 규정 준수 감독: (옵션 라이선스 필요)

• Windchill Quality Solutions를 활용해 품질 관리 시스템(QMS) 운영, 결함 추적, 시정 조치 관리.
• 지역별 규제 준수(예: ISO, FDA) 확인 및 문서화.

협업 및 커뮤니케이션:

• 다분야 팀(설계, 제조, 서비스, 품질) 및 외부 파트너(공급업체, 고객) 간 협업 촉진.
• Windchill의 데이터 공유 기능을 통해 실시간 정보 접근 및 동시 엔지니어링 지원.

성과 분석 및 보고:

• 제품 개발 성과를 분석하고, 보고서를 통해 이해관계자에게 진행 상황 공유.
• 데이터 분석을 통해 제품 출시 시간 단축 및 비용 절감 방안 제안.

제품 매니저(Product Manager) 주요 책임

• 소유자 역할: 제품 매니저는 기본적으로 프로젝트 소유자로 설정되며, 필요 시 소유자를 다른 팀원으로 변경 가능.
• 데이터 무결성 유지: Windchill의 중앙 데이터베이스를 통해 설계, 제조, 서비스 데이터의 일관성 보장.
• 효율성 최적화: 재사용 가능한 설계, 템플릿, 표준화된 프로세스를 통해 개발 효율성 향상.
• 문제 해결: 팀 간 충돌, 데이터 접근 문제, 워크플로우 지연 등을 조정 및 해결.

2)  설계자  (Designer)

주요 역활은 CAD 관리, 문서 작성, BOM 편집, 변경 요청 입니다. CAD 데이터 및 관련 문서의 작성 및 편집 권한을 갖습니다. 승인 권한 및 팀 구성 권한은 없습니다. 개발 단계에서 핵심 기여자 역할 수행 입니다.

기능 항목	설계자 권한
CAD 문서 체크인/체크아웃	가능
부품/문서 생성	가능
BOM 작성 및 수정	가능 (일부 제품 제한될 수 있음)
변경 요청(ECR) 생성	가능
변경 명령(ECO) 승인	불가능 (일반적으로 Change Admin 권한 필요)
제품 구조 브라우징	가능
문서 승인	또는 제한적 (Reviewer/Manager가 승인)
팀 구성 변경	불가능

3) 검토자 (Reviewer 또는 Review Participant )

설계나 문서, BOM, 변경 사항 등을 검토하고 피드백하는 사용자 역할입니다. 설계자(Designer)처럼 데이터를 직접 생성하거나 수정하진 않지만, 검토 및 승인 프로세스에 참여하는 중요한 역할입니다.

기능	사용 가능 여부	설명
설계 문서 보기	가능	CAD 파일, 도면, 문서 등 열람
설계 문서 수정	불가	직접 편집은 불가능
주석/마크업 추가	가능	PDF 또는 3D 뷰어에서 검토 의견 남김
워크플로우 승인 참여	조건부 가능	프로세스에 따라 승인자 역할 포함 시 가능
변경 요청(ECR) 보기	가능	설계 변경 요청 검토
변경 명령(ECO) 승인	기본적으로 불가	Change Admin 역할 필요

승인 권한은 Reviewer에게 자동 부여되지는 않으며, 워크플로우 내 "Approver" 역할로 별도 지정해야 승인 가능합니다.

사용 예시 시나리오

 

1. 설계자가 도면을 Windchill에 체크인
2. Reviewer는 해당 도면을 열람 (CAD 뷰어 사용)
3. 3D 모델에 마크업/주석을 추가하여 피드백 제공
4. 설계자는 피드백을 반영해 변경
5. 최종 승인자는 설계를 승인 후 변경 반영

 

4) 승인자 (Approver)

문서, 변경 요청(ECR), 변경 명령(ECO) 등 다양한 항목에 대해 승인(Approve) 할 수 있는 권한을 가진 역할입니다. 승인자 역할을 가진 사용자는 워크플로우에서 승인을 요구받으며, 이 승인 절차는 보통 릴리스나 변경 절차의 중요한 부분입니다.

• Approver 역할은 기본적으로 승인 권한만 보유합니다. 직접 생성, 편집, 삭제 권한은 일반적으로 없습니다.
• 승인을 위한 권한이 있어도, 시스템 또는 객체에 대한 보기(View) 권한이 함께 부여되어야 승인할 수 있습니다.

 

예시: 
1. 문서 릴리스 워크플로우: 작성자가 초안을 작성 → 검토자 검토 → 승인자 승인 → 릴리스
2. 변경 관리: ECR 생성 → 영향 분석 → 승인자 승인 → ECO 실행

기능	사용 가능 여부	비고
문서 승인 (Document Release)	사용 가능	문서 릴리스 프로세스에서 승인 단계에 참여 가능
변경 요청 승인 (ECR - Change Request)	사용 가능	ECR 워크플로우에서 승인 단계 지정 가능
변경 명령 승인 (ECO - Change Notice)	사용 가능	ECO 실행 전 승인자로 설정 가능
CAD 데이터 릴리스 승인	사용 가능	CAD 문서에도 릴리스 승인 가능
승인 요청 알림 수신	사용 가능	워크플로우 진행 시 승인 요청이 작업 항목으로 할당됨
승인 거절 또는 의견 첨부	사용 가능	승인 보류, 거절 사유 입력 가능
컨텐츠 직접 수정	불가	일반적으로 작성자(Author) 역할에게만 허용됨
워크플로우 정의 변경	불가	관리자 또는 프로세스 설계자만 가능
감사 로그 및 변경 이력 보기	제한적 사용	역할 설정 또는 추가 권한 필요
승인 결과에 따른 릴리스 자동 처리	사용 가능	조건에 따라 승인 시 자동 릴리스 가능 (워크플로우 설정 필요)

 

▷ 시스템 그룹 연계:

• 각 역할은 자동으로 동일한 이름의 시스템 그룹(System Group)으로 생성됩니다.
  예: "Change Admin II" 역할은 "CHANGE ADMINISTRATOR II"라는 시스템 그룹에 매핑됩니다.
• 사용자가 역할에 추가되면 해당 시스템 그룹에도 자동으로 추가되며, 관리자는 정책 관리 유틸리티(Policy Administration Utility)를 통해 접근 정책을 설정할 수 있습니다.

 

2. 기본 역할:

• 모든 제품 또는 라이브러리에는 기본적으로 Product Manager, Library Manager, Guest 같은 고정 역할이 포함됩니다.

• Guest 역할은 읽기 전용 접근 권한을 가진 사용자(활성 팀원이 아닌 사용자)에게 할당되며, 필요 시 숨길 수 있습니다.