프로젝트 관리 지식 시스템

프로젝트 관리 지식 시스템

소개: 프로젝트 헌장은 프로젝트 및 프로젝트 자금을 공식적으로 승인하는 문서입니다. 프로젝트 후원자 또는 프로젝트 조직 외부의 후원자가 발행합니다. 다음은 제가 여러분에게 가져온 프로젝트 관리 지식 시스템입니다. 여러분에게 도움이 되기를 바랍니다.

1. 전체 프로젝트 관리

1. 프로젝트 헌장 개발

프로젝트 헌장의 기능은 다음과 같습니다.

(1) 프로젝트의 존재를 공식적으로 알리고 프로젝트 시행 개시에 법적 지위를 부여합니다.

(2) 프로젝트 범위 관리의 후속 작업을 위한 중요한 기반이기도 한 프로젝트 범위를 대략적으로 지정합니다. (3) 프로젝트 관리자는 프로젝트 활동을 수행하기 위해 조직의 자원을 사용하도록 공식적으로 임명되고 권한을 부여받습니다. 프로젝트 시작, 프로젝트 헌장의 개발, 프로젝트의 공식 승인 또는 다음 단계의 시작. 2. 프로젝트 범위 기술서 개발

프로젝트 범위를 간략하게 설명하는 예비 프로젝트 범위 기술서를 준비합니다.

3. 프로젝트 관리 계획 개발

모든 하위 계획은 전체 프로젝트 관리 계획을 형성하기 위해 결정, 작성, 통합 및 조정됩니다. 4. 프로젝트 실행 안내 및 관리

프로젝트 목표 달성을 위해 프로젝트 관리 계획에 정의된 작업을 실행합니다. 5. 프로젝트 작업 모니터링 및 제어

프로젝트 관리 계획에 정의된 프로젝트 목표를 달성하기 위해 프로젝트의 활동, 계획, 실행 및 종료 프로세스를 감독하고 제어합니다.

6. 전반적인 변경 제어

모든 변경 요청을 검토하고, 변경 사항을 승인하고, 결과물과 조직 프로세스 자산을 제어합니다. 7. 프로젝트 종료

프로젝트 프로세스 중 모든 활동을 완료하여 프로젝트 또는 프로젝트 단계를 공식적으로 종료합니다.

2. 프로젝트 범위 관리

1. 범위 계획

프로젝트 범위를 정의하고 관리하는 것은 전체 프로젝트의 성공에 매우 중요합니다.

2. 범위 정의 3. 작업분류체계 작성 4. 범위 확인 5. 범위 제어

3. 프로젝트 시간 관리

1. 활동 정의 2. 활동 순서 3, 활동 자원 추정 4, ​​활동 기간 추정 5, 일정 계획 6, 진행 관리

프로젝트 시간 관리 각 프로세스의 입력/출력 및 기술/도구/방법

4. 프로젝트 비용 관리

1. 비용 추정

비용 추정은 다양한 프로젝트 활동을 완료하는 데 필요한 다양한 자원의 대략적인 비용 추정을 의미합니다. 비용 추정은 활동 자원 추정에서 결정된 자원 요구 사항(인적 자원, 장비 및 자재 등 포함)과 시장의 다양한 자원 가격 정보를 기반으로 수행되어야 합니다.

프로젝트 비용 추정과 프로젝트 비용은 서로 연관되어 있는 두 가지 개념입니다. 사업비에는 사업비

뿐만 아니라 사업주체가 사업을 수행함으로써 얻는 이익, 즉 사업비 = 사업비 + 이익도 포함된다. 프로젝트 비용은 프로젝트 조직이 프로젝트 견적을 작성할 때 중요한 고려 사항 중 하나입니다. 2. 비용 예산

비용 예산은 프로젝트의 비용 견적을 프로젝트의 각 특정 작업에 할당하고

작업을 결정하며 비용 관리의 기초입니다. 프로젝트 관리는 활동의 비용 할당량을 설정하고, 프로젝트 비용 관리 표준을 공식화하며, 예상치 못한 프로젝트 비용의 분할 및 사용에 대한 규칙을 규정하는 작업을 수행합니다. 3. 비용 관리

5. 프로젝트 품질 관리

1. 품질 계획 준비

프로젝트와 관련된 품질 표준을 결정하고 이를 달성하는 방법을 결정 품질 기준.

2. 품질 보증 3. 품질 관리

6. 프로젝트 인적 자원 관리

1. 인적 자원 계획 준비

프로젝트 식별 조직 내의 역할, 책임 및 보고 관계를 확립하고 안정성을 조성합니다. 인적 자원 계획에는 프로젝트 인력 배치 관리 계획도 포함됩니다.

2. 프로젝트 팀 구성 3. 프로젝트 팀 구성 4. 프로젝트 팀 관리

7. 프로젝트 커뮤니케이션 관리

1. 커뮤니케이션 계획 준비 2 . 정보 공개 3. 성과 보고

상태 보고서, 진행 보고서 및 예측을 포함하여 프로젝트 성과에 대한 정보를 수집하고 배포합니다.

4. 프로젝트 이해관계자 관리

8. 프로젝트 위험 관리

1. 위험 관리 계획 준비

프로젝트 처리 방법 설명 리스크 관리 활동을 수행합니다.

2. 위험 식별

프로젝트에 어떤 위험이 있는지, 이러한 프로젝트 위험의 기본 특성은 무엇인지, 이러한 프로젝트 위험에 발생할 수 있는 위험은 무엇인지 식별하고 확인합니다. >

프로젝트의 어떤 측면이 영향을 받나요? 3. 정성적 위험 분석

4. 정량적 위험 분석 5. 위험 대응 계획 준비 6. 위험 모니터링

9. 프로젝트 조달 관리

1. 준비 및 조달 계획 2. 문의 계획 작성 3. 문의 4. 공급업체 선택 5. 계약 관리 6. 계약 종료

2장 프로젝트 관리 프로세스 그룹 및 단계

1. 프로젝트 관리 프로세스 그룹

1. 2가지 관리 프로세스, 즉 프로젝트 헌장 개발과 예비 프로젝트 범위 기술서를 포함하는 착수 프로세스 그룹. 2. 프로젝트 관리 계획 준비, 범위 계획 준비, 범위 정의, WBS 생성, 활동 정의, 활동 순서 지정, 활동 자원 추정, 활동 기간 추정, 일정 계획 준비 및 비용 등 22개 관리 프로세스를 포함하는 계획 프로세스 그룹 추정, 원가예산, 품질기획 준비, 인적자원기획 준비, 프로젝트팀 구성, 커뮤니케이션 계획 작성, 리스크 관리 계획 작성, 리스크 식별, 리스크 정성분석, 리스크 정량분석, 리스크 대응 계획 작성, 조달계획 작성, 계약서 작성 .

3. 프로젝트 실행 지도 및 관리, 품질 보증 구현, 프로젝트 팀 구축, 정보 공개, 입찰 및 공급업체 선정 등 6개 프로세스를 포함하는 실행 프로세스 그룹.

4. 제어 프로세스 그룹에는 프로젝트 감독 및 제어, 전체 변경 제어, 범위 확인, 범위 제어, 진행 제어, 비용 제어, 품질 제어, 프로젝트 팀 관리, 성과 등 12개의 관리 프로세스가 포함됩니다. 보고, 프로젝트 이해관계자 관리, 위험 모니터링, 계약 관리.

5. 종결 프로세스 그룹에는 프로젝트 종결과 계약 종결이라는 두 가지 관리 프로세스가 포함됩니다.

2. 프로젝트 관리 단계

1. 시작 단계 2, 계획 단계 3, 구현/실행 단계 4, 종료 단계

3. 프로젝트 수명주기< /p>

1. 컨셉 단계: 프로젝트가 실현 가능한지 제안하고 시연합니다.

2. 개발 단계: 개발 전 실현 가능한 프로젝트를 위해 인적, 재정적, 물적, 모든 소프트웨어 및 하드웨어를 준비하는 것이 프로젝트의 전반적인 계획입니다.

3. 구현 단계: 프로젝트 계획에 따라 프로젝트 작업을 구현합니다. 구현 단계는 프로젝트 수명주기에서 가장 오랜 시간이 걸리고, 가장 많은 양의 작업이 완료되고, 가장 큰 자원 소비가 발생하는 단계입니다.

4. 마무리 단계: 즉, 프로젝트 종료와 관련된 작업으로, 프로젝트를 완성하고 최종 제품을 구체화하는 작업입니다.

3장 프로젝트 관리에 대한 일반 지식

1. 프로젝트 조직

1. 프로젝트 조직

프로젝트는 일반적으로 프로젝트의 일부입니다. 기업, 정부 기관, 의료 기관, 국제기구, 전문 협회 등을 포함하여 프로젝트보다 큰 조직.

내부, 합작, 파트너십 프로젝트라 할지라도 여전히 프로젝트를 후원하는 조직이나 조직의 영향을 받게 됩니다. 프로젝트 관리 시스템, 문화, 스타일, 조직 구조 및 프로젝트 관리 사무실 측면에서 조직의 성숙도도 프로젝트에 영향을 미칩니다. 다음 섹션에서는 프로젝트에 영향을 미칠 수 있는 대규모 조직 구조의 주요 요소에 대해 설명합니다. 조직 구조 2. 조직 구조

1. 기능적 조직

2. 매트릭스 조직

3. 프로젝트 기반 조직

2 , 프로젝트 정의

　1. 프로젝트 정의

프로젝트는 특정 목적을 위해 특정 자원을 사용하여 정해진 기간 내에 특정 후원자에게 고유한 제품 및 서비스를 제공하는 것입니다. 결과를 얻기 위한 노력.

여기서 자원은 프로젝트를 완료하는 데 필요한 인력, 재정, 자재 등을 의미하며, 기간은 시작 날짜와 종료 날짜가 명확한 프로젝트를 의미합니다. 2. 프로젝트 목표

프로젝트 목표에는 성취 목표와 구속력 있는 목표가 포함됩니다.

프로젝트의 구속력 있는 목표를 경영목표라고도 하며, 프로젝트의 성취목표를 프로젝트 목표라고도 합니다. 프로젝트 달성 목표는 고객 요구 사항을 충족하는 프로젝트를 통해 개발된 제품, 시스템, 서비스 또는 결과를 나타냅니다. 예를 들어 영상 감시 시스템 구축은 프로젝트이고 완성된 영상 감시 시스템은 프로젝트의 제품입니다. 사무실 건물을 짓는 것도 프로젝트 또는 프로젝트이며, 완성된 사무실 건물은 프로젝트의 산물입니다. 온라인 서점을 발전시키는 것도 하나의 프로젝트이고, 완성된 온라인 서점은 그 프로젝트의 산물이다. ERP 시스템의 구현도 프로젝트이며, 완성된 ERP 시스템은 프로젝트의 결과물입니다. 투어를 준비하는 것도 프로젝트입니다. 티켓 예약, 호텔 예약, 설명 등 관광객을 육체적으로나 정신적으로 행복하게 만드는 모든 서비스가 이 프로젝트에서 제공됩니다. 협상을 진행하는 것도 프로젝트입니다. 협상이 성공하면 계약은 프로젝트의 결과입니다.

프로젝트 바인딩 목표는 프로젝트의 결과 목표를 완료하는 데 필요한 시간, 비용, 품질을 나타냅니다. 예를 들어, ERP 프로젝트는 승인 기준(품질 요구 사항)을 충족하면서 1년 이내에 완료되어야 합니다. 프로젝트의 목표는 SMART 원칙의 준수를 요구합니다. 즉, 프로젝트의 목표는 구체적(Specific), 측정 가능(Measurable), 동의(당사자의 만장일치 동의 필요), 현실적(현실적), 시간-을 요구합니다. 지향적입니다 (특정 시간 제한 있음). 3. 프로젝트 개발 모델

구조적 방법: 하향식 개발 방법의 기본 아이디어는 "하향식, 단계별 개선"이며, 개발 방법과 소프트웨어의 구조적 합리성을 강조합니다. 구조적 합리성이 발달했다.

소프트웨어 개발 모델: 폭포 모델, 증분 모델, 나선형 모델, 분수 모델, 반복 모델, V 모델, 민첩한

방법 및 통합 프로세스.

1. 폭포수 모델

폭포수 모델은 고전적인 소프트웨어 수명주기 모델로 일반적으로 소프트웨어 개발을 타당성 분석(계획), 요구 사항 분석, 소프트웨어 설계(개요 설계)로 나눕니다. ), 세부 설계), 코딩(단위 테스트 포함), 테스트, 운영 및 유지 관리 등을 그림 4-13과 같이 수행합니다. 폭포수 모델의 각 개발 활동에는 다음과 같은 특징이 있습니다.

?2.V 모델

먼저 V 모델의 다이어그램을 살펴보세요. V 모델은 그림 4-14에 나와 있습니다.

V 모델의 왼쪽에 있는 내려가는 부분은 개발 과정의 단계이고, 그에 따라 오른쪽에 있는 올라가는 부분은 테스트 과정의 다양한 단계입니다

테스트 단계는 조직마다 다르게 명명될 수 있습니다.

모델 다이어그램의 개발 단계에서는 비즈니스 요구 사항 정의, 요구 사항 확인 또는 테스트 계획부터 시작하여 이러한 요구 사항을 개요부터 시작하여 개요 디자인, 개요 디자인 검증 및 테스트 계획으로 변환합니다. 설계는 세부 설계, 세부 설계 및 테스트 계획 검증, 최종적으로 프로그램 코드 및 코드 테스트 계획을 얻기 위한 개발로 세분화됩니다.

그런 다음 단위 테스트로 실행이 시작되고 통합 테스트, 시스템 테스트 및 승인 테스트로 시작되는 테스트 실행 단계가 있습니다.

3. 프로토타이핑 모델

프로토타이핑 모델은 폭포수 모델의 단점을 보완하기 위해 만들어졌습니다.

프로토타입 모델의 첫 번째 단계는 고객이나 미래의 사용자가 시스템과 상호 작용할 수 있도록 신속한 프로토타입을 구축하는 것입니다. 프로토타입에 대해 사용자와 논의하고 소통한 후 요구 사항을 명확히 합니다. 사용자에게 필요한 것이 무엇인지 진정으로 파악하십시오. 소프트웨어 제품이 어떻게 생겼는지. 이를 충분히 이해한 후 프로토타입을 기반으로 사용자가 만족할 수 있는 제품을 개발할 수 있습니다. 실제로 프로토타입 제작은 요구사항 분석 및 정의 과정에서 수행되는 경우가 많습니다. 프로토타입 모델은 폭포 모델의 불분명한 소프트웨어 요구 사항으로 인해 개발 작업에 발생하는 위험을 줄입니다. 프로토타입 기반 커뮤니케이션이 더 직관적이고 요구 사항 분석 및 정의를 위한 새로운 방법을 제공하기 때문입니다. 프로토타입 모델의 적용은 매우 중요합니다. 워터폴 및 V자형 모델은 요구사항 분석 프로세스에서 프로토타입 모델 아이디어를 사용하여 불명확한 요구사항으로 인해 제품에 심각한 결과를 초래하는 결함을 해결합니다.

복잡한 대규모 소프트웨어의 경우 프로토타입 개발이 요구 사항을 충족하지 못하는 경우가 많습니다. 개발 위험을 줄이기 위해 폭포수 모델과 프로토타입 모델, 나선형 모델 및 확장 모델의 진화를 기반으로 합니다. RUP의 사용이 나타났습니다.

?4. 나선형 모델

나선형 모델은 프로토타입 구현의 반복적 특성과 선형 순차(폭포수) 모델의 제어되고 체계적인 측면을 결합한 진화적인 소프트웨어 프로세스 모델입니다. .일어서세요. 이를 통해 소프트웨어의 증분 버전을 빠르게 개발할 수 있습니다. 나선형 모델에서 소프트웨어 개발은 ​​일련의 증분 릴리스입니다. 초기 반복에서 릴리스된 증분은 종이 모델이나 프로토타입일 수 있으며, 이후 반복에서는 개발된 시스템의 보다 완전한 버전이 점진적으로 생산됩니다. 나선형 모델의 전체 개발 과정은 그림 4-15와 같다.

그림 4-15의 나선형은 시간에 따른 작업 진행을 나타냅니다. 개발 프로세스는 주기적으로 반복되는 나선형 모양입니다. 4개 사분면은 계획, 위험 분석, 구현 엔지니어링, 고객 평가 등 각 주기의 4단계를 나타냅니다. 나선형 모델은 위험 분석을 강조하며 특히 크고 복잡하며 위험도가 높은 시스템에 적합합니다.

5. 반복 모델

대부분의 전통적인 수명 주기에서 단계는 요구 사항 분석, 설계, 코딩, 테스트 등 주요 활동의 이름을 따서 명명됩니다. 대부분의 전통적인 소프트웨어 개발 작업은 프로세스의 연속 실행을 강조합니다. 즉, 이전 활동이 완료된 후 하나의 활동을 시작해야 하므로 소프트웨어 프로젝트의 라이프사이클을 구성하는 프로세스 시퀀스를 형성합니다. 반복 모델에서 각 단계는 기존의 완전한 직렬 프로세스 문자열을 실행하고 프로세스 문자열을 한 번 실행하는 것이 반복입니다. 각 반복에는 모든 활동의 다양한 비율을 포함하는 프로세스가 포함됩니다.

6. 통합 프로세스(RUP)

RUP(Rarional Unified Process) 소프트웨어 통합 프로세스는 일종의 반복 모델인 '프로세스 방법'입니다.

RUP는 2차원 좌표로 설명할 수 있습니다. 가로축은 프로젝트의 라이프사이클인 시간을 나타내며 주로 Cycle, Phase, Iteration 및 Milestone을 포함하는 개발 프로세스의 동적 구조를 반영합니다. 세로축은 개발을 반영하는 자연스러운 논리적 활동을 나타냅니다. 프로세스에는 주로 Activity, Artifact, Worker 및 Workflow가 포함됩니다. 그림 4-16과 같습니다.

RUP의 소프트웨어 라이프사이클은 시간에 따라 초기 단계(Inception), 정교화 단계(Elaboration), 구성 단계(Construction) 및 전달 단계(Transition)의 네 가지 순차적 단계로 분해됩니다.

이 네 단계가 순차적으로 실행되면서 하나의 사이클이 형성됩니다.

각 단계는 주요 마일스톤(Major Milestones)으로 끝납니다.

각 단계가 끝날 때 단계의 목표가 충족되었는지 여부를 확인하기 위해 평가가 수행됩니다.

각 단계는 위에서 아래로, 즉 핵심 프로세스 워크플로, 비즈니스 모델링, 수요 조사, 분석 및 설계 실행부터 배포까지, 그리고 핵심 지원 작업부터 프로세스 구성 및 변경 관리까지 반복됩니다. 반복을 완료하기 위한 프로젝트 관리, 실행 및 환경. 필요에 따라 한 단계 내에서 하나 이상의 세대를 선택할 수 있습니다. 각 단계의 주요 임무는 다음과 같다.

(1) 초기 단계: 프로젝트 범위를 체계적으로 정교화하고, 프로젝트 경계를 결정하고, 실행 가능한 시스템 아키텍처를 선택하고, 비즈니스 문서를 계획 및 준비합니다. 비즈니스 문서에는 승인 사양, 위험 평가, 필요한 리소스 추정치, 주요 마일스톤 날짜를 반영하는 단계 계획이 포함됩니다.

(2) 개선 단계: 문제 영역을 분석하고, 시스템 구조를 수립 및 개선하고 구성 요소를 선택하며, 프로젝트 계획을 준비하고, 프로젝트에서 가장 높은 위험 요소를 제거합니다. 동시에 개발 사례 작성, 템플릿 작성, 가이드라인 작성, 도구 준비 등 프로젝트 지원 환경을 구축합니다.

(3) 구축 단계: 구성 요소의 개발 및 테스트를 완료하고 완성된 구성 요소를 제품에 통합하며 제품의 모든 기능을 테스트합니다. 구축 단계는 비용, 일정 및 품질을 최적화하기 위해 리소스를 관리하고 운영을 제어하는 ​​데 중점을 두는 제조 프로세스입니다.

(4) 전달 단계: 전달 단계의 목적은 소프트웨어 제품을 사용자 기반에 전달하는 것입니다. 이번에 개발된 제품이 최종 사용자에게 출시될 만큼 성숙해지면 배송 단계에 들어갑니다.

제공 단계의 초점은 최종 사용자가 소프트웨어를 사용할 수 있는지 확인하는 것입니다. 제공 단계는 출시 준비를 위한 제품 테스트, 사용자 피드백을 기반으로 한 사소한 조정 등 여러 번의 반복에 걸쳐 이루어질 수 있습니다.

소프트웨어 제품이 일정 기간 동안 사용할 수 있도록 사용자에게 전달된 후 새로운 요구 사항이 있는 경우 초기화, 개선, 구성 및 전달의 다음 주기를 시작하는 또 다른 개발 주기를 시작할 때입니다. .

3. 소프트웨어 공학

소프트웨어 공학: 공학적 원리와 방법을 이용하여 소프트웨어 문제를 해결하기 위해 컴퓨터 과학, 수학, 경영 과학의 원리를 적용하는 공학을 말하며 그 목적은 다음과 같습니다. 소프트웨어 생산성을 향상시키고, 소프트웨어 품질을 향상시키며, 소프트웨어 비용을 절감합니다. IEEE의 소프트웨어 엔지니어링 정의는 소프트웨어 개발, 운영, 유지 관리의 전 과정에 체계적이고 표준화되었으며 측정 가능한 엔지니어링 방법을 적용하고 이를 연구하는 것입니다.

소프트웨어 엔지니어링은 방법, 도구, 프로세스의 세 부분으로 구성됩니다. 소프트웨어 엔지니어링 방법은 소프트웨어 엔지니어링 프로젝트를 완료하기 위한 기술적 수단입니다. 소프트웨어 엔지니어링에 사용되는 도구는 소프트웨어 개발에 있어 사람들의 적극적인 지능과 체력을 확장하고 확장합니다. 소프트웨어 개발 및 관리는 소프트웨어 개발의 모든 측면을 통해 다양한 소프트웨어 문서 생성을 지원합니다. 소프트웨어 엔지니어링 프로세스 중에 관리자는 소프트웨어의 품질, 진행 상황 및 비용을 평가, 관리 및 제어해야 합니다. 인력 조직, 계획 추적 및 제어, 비용 추정, 품질 보증 및 구성 관리 등을 포함한 개발.

4장 프로젝트 관리에 대한 고급 지식

1. 전략적 관리

2. 사용자 비즈니스 프로세스 관리

3. 지식 관리< /p>

1. 대규모의 복잡한 프로젝트 및 다중 프로젝트 관리

1. 프로젝트 포트폴리오 관리가 프로젝트 위험과 이점 간의 균형을 찾을 수 있다면 상당한 수익을 얻을 수 있습니다. 프로젝트 포트폴리오 관리는 조직 내의 모든 프로젝트를 분석하고 위험과 이점을 기준으로 균형을 맞추는 방법론입니다.

2. 대규모 및 복잡한 프로젝트 관리 일반적으로 대규모 및 복잡한 프로젝트 관리에는 다음과 같은 두 가지 특성이 있습니다. A. 계층적 관리 및 노무 관리 분업 B. 강화된 조정 메커니즘. 크고 복잡한 프로젝트의 분해 A. 하위 프로젝트에 따른 분해 B. 관리 기능에 따른 분해 C. 매트릭스 분해

　3. 프로젝트 성과 평가 및 성과 관리

성과 평가 및 성과관리 구성원의 업무와 성과를 평가하고 관리하는 것을 말한다. PMI에 따르면 전체 프로젝트 성과는 프로젝트의 시간, 비용, 품질 및 범위 정보를 의미합니다. 일부 프로젝트에는 위험 및 조달 정보도 포함됩니다.

구체적으로 여기에는 결과물 완료, 시작된 활동, 종료된 활동, 품질 표준 충족, 사용 완료, 완료 추정, 발생한 위험, 폐기 위험, 위험 모니터링, 조달 조건 및 기타 정보 등의 진행 상황이 포함됩니다.

2. 프로젝트 성과 평가 및 성과 관리

1. 프로젝트 관리란 무엇입니까

프로젝트 관리는 프로젝트에 지식, 기술, 도구 및 기술을 적용하는 것입니다. 프로젝트 투자자의 요구 사항과 기대를 충족하거나 초과하는 활동.

7장 정보 및 시스템 통합 기술

1. ERP

1. ERP 의미

ERP는 전사적 자원 관리(Enterprise Resource Planning) ERP(Planning)는 ERP(Enterprise Resource Planning)의 약자로 1990년대 미국의 한 IT 기업이 컴퓨터 정보, IT 기술의 발전을 바탕으로 미래 정보화 시대 기업 경영 정보 시스템의 발전 동향과 향후 변화를 예측했다. 그리고 당시 공급망 관리에 대한 기업의 요구 사항을 파악하고 이 개념을 제안했습니다. ERP는 자재자원관리(물류), 인적자원관리(사람흐름), 재무자원관리(재무흐름), 정보자원관리(정보흐름)을 위한 통합 기업 관리 소프트웨어이다. 이는 클라이언트/서비스 아키텍처를 포함하고 그래픽 사용자 인터페이스를 사용하며 개방형 시스템 생산을 적용합니다. 기존 표준 기능 외에 품질, 공정 운영 관리, 조정 보고 등의 기타 기능도 포함되어 있습니다.

ERP(Enterprise Resource Planning)는 컴퓨터 기술을 사용하여 회사의 물류, 인력, 자본 및 정보 흐름을 통합 및 관리하고 고객 요구를 회사 내부 생산 및 운영 활동과 통합하며 공급 업체의 자원을 통합합니다. 기업의 의사결정자에게 기업의 제품 비용 문제 해결, 운영 효율성 향상, 자금 운영에 대한 일련의 조치를 제공하여 사용자 요구에 따라 완전히 운영 및 관리할 수 있는 새로운 산업을 만듭니다. 관리회계를 핵심으로 하는 정보시스템으로, 고객 주문을 받고, 처리 및 배송을 완료하고, 최종적으로 고객 대금을 받기 위한 전사적 자원을 식별하고 계획합니다.

성공적인 ERP 애플리케이션의 특징은 다음과 같습니다.

첫째, 시스템 운영이 통합되고 소프트웨어가 여러 부서에 걸쳐 운영됩니다.

둘째, 비즈니스입니다. 프로세스가 합리화되고 각 부서 수준의 비즈니스 부서가 완전히 최적화된 프로세스를 기반으로 재구축됩니다.

3. 성과 모니터링은 동적이며 성과 시스템은 기존 관리 문제를 해결하기 위한 즉각적인 피드백을 제공할 수 있습니다. >

4. 경영 개선 지속적으로 기업은 지속적인 자체 평가와 지속적인 경영 개선을 위한 메커니즘을 구축합니다.

8장 용어

1. 환경 및 조직적 요인

환경 및 조직적 요인: 기존 시설 및 고정 자산 및 기타 인프라, 구현 단위의 현재 인적 자원, 직원의 직업 및 기술, 채용 및 해고 지침과 같은 인적 자원 관리 정책, 직원 성과 평가 및 교육 기록 등, 일반적인 시장 상황 및 국가 또는 산업 표준.

2. 조직 프로세스 자산

조직 프로세스 자산: 프로젝트 실행 조직의 기업 계획, 정책, 절차, 지침 및 관리 시스템과 프로젝트에서 얻은 지식과 교훈 구현 조직.

3. 프로젝트 작업 명세서(sow)

프로젝트 작업 명세서(sow): 프로젝트에서 제공할 제품, 결과 또는 서비스에 대한 설명입니다. 내부 프로젝트의 경우

내부 프로젝트의 경우 프로젝트 개시자 또는 투자자는 비즈니스 요구 사항이나 제품 또는 서비스 요구 사항을 기반으로 작업 명세서를 제안합니다. 내부 작업 명세서를 사명 선언문이라고도 합니다. 외부 프로젝트의 경우 입찰 초대장, 입찰 초대장 또는 계약의 일부와 같은 입찰 문서의 일부로 작업 명세서를 클라이언트로부터 얻습니다. 작업기술서는 다음 사항을 기술해야 합니다.

(1) 비즈니스 요구 사항: 조직의 비즈니스 요구 사항은 시장 수요, 기술 진보, 교육 요구 사항, 법적 요구 사항 또는 정부 표준을 기반으로 할 수 있습니다.

(2) 제품 범위 설명: 프로젝트에서 생성할 제품의 요구 사항과 제품 또는 서비스의 특성을 기록합니다. 일반적인 상황에서 제품 요구 사항 사양은 프로젝트 시작 과정에서 그다지 상세하지 않으며 프로젝트의 후속 프로세스에서 제품 기능이 명확해짐에 따라 점차적으로 개선됩니다. 이러한 요구 사항 사양은 프로젝트에서 생성된 제품과 조직의 비즈니스 요구 사항 간의 관계, 또는 프로젝트에서 생성된 제품과 제품 요구 사항을 초래한 동기 부여 요소 간의 관계도 문서화해야 합니다. 제품 요구 사항 문서의 형식과 내용은 업계마다 다르지만 항상 후속 프로젝트 계획을 지원할 수 있을 만큼 충분히 자세해야 합니다.

(3) 전략적 계획: 모든 프로젝트는 조직의 전략적 목표를 지원해야 합니다. 조직의 전략 계획의 실행은 프로젝트 선택에 있어 중요한 요소로 간주됩니다. ;