マインドマップギャラリー システムインテグレーションプロジェクトマネジメントエンジニアマップ
これは、情報の品質属性、情報システムの特性、情報システムの構成、情報システムのライフサイクル、情報レベル、情報技術の発展と傾向を含む、システム統合プロジェクト管理エンジニアに関するマインド マップです。
2024-03-21 15:29:01 に編集されました第1章 情報知識
情報の品質属性
正確さ
誠実さ
信頼性
適時性
経済
検証可能性
安全性
情報システムの特徴
目的
入れ子性
安定性
開放性
脆弱性
堅牢性
情報システムのコンポーネント
ハードウェア
ソフトウェア
データベース
通信網
ストレージデバイス
センシングデバイス
周辺機器
人員
データを情報に加工する手順
時点:
1948年10月、シャノンは「コミュニケーションの数学理論」という論文を発表した。
1997年、国務院情報技術指導グループが発表した「国家情報化『第9次5カ年計画』と2010年長期目標概要」で提案された国家情報化システムは、我が国の情報化建設に重大な影響を与えた。
2014 年 2 月に、ネットワーク セキュリティと情報化に関する中央主導グループが設立されました。
2013年9月、工業情報化部と国務院の関連部門は「情報化発展計画」の行動計画を策定した。
指導的イデオロギー
基本原則
開発を調整し、秩序ある方法で進める
需要主導、市場志向
仕組みを改善し、イノベーションを推進する
管理の強化と安全の確保
1996 年にガートナー グループはビジネス インテリジェンスの概念を提案しました
情報システムのライフサイクル
システム企画
実行可能性分析
プロジェクト開発計画
システム分析
需要分析
システムデザイン
概要設計
きめ細かなデザイン
システム導入
コーディング
テスト
運用・保守
情報レベル
製品の情報化
企業の情報化
産業の情報化
国民経済の情報化
社会生活の情報化
情報技術の発展と動向
高速かつ大容量
統合とプラットフォーム化
知的
仮想コンピューティング
通信技術
リモートセンシングとセンシング技術
モバイルスマート端末
人間指向
情報セキュリティー
情報化と情報化の融合
電子政府コンテンツ
政府間 電子政府 G2G
政府から企業への電子政府 G2B
政府間電子政府 G2C
政府から公務員への G2E
ビジネス インテリジェンスを実装する手順
需要分析
データウェアハウスのモデリング
データ抽出
ビジネスインテリジェンス分析レポートを作成する
ユーザートレーニングとデータスキーマテスト
システムの改善と改良
ビッグデータ
特徴
大量のボリューム
高速速度
バラエティ
価値価値
真実性
クラウドコンピューティング
タイプ
サービスとしての IaaS インフラストラクチャ
サービスとしての PaaS プラットフォーム
SaaS サービスとしてのソフトウェア
スマートシティリファレンスモデル P100
スマート シティ建設参照モデルには、依存関係を持つ 5 つのレイヤーと、建設上の制約を持つ 3 つのサポート システムが含まれています。
5つの機能層
IoT知覚層
通信ネットワーク層
コンピューティング層とストレージ層
データサービスサポート層
スマートアプリケーション層
3層のサポート体制
セキュリティシステム
建設施工管理システム
標準仕様システム
第2章 情報システムの統合とサービス管理
時間枠
コンピュータ情報システムインテグレーション資格認定制度は、2000年1月1日から施行されました。
情報システムインテグレーション資格レベル条件 P116
2015 年 7 月 1 日より発効
総合的な条件
勤続年数
登録資本金
財務状況
過去3年間の財務状況
評判
パフォーマンス
過去3年間のシステムインテグレーションプロジェクトの完了件数、プロジェクト規模、プロジェクトの技術内容、プロジェクトソフトウェア原価率、実装品質、事業分野レベル
マネジメント能力
品質管理システム
顧客サービス管理
技術力
事業分野
ソフトウェア開発力
才能の強さ
技術系・技術系人材の割合、学士以上の人材比率、プロジェクトマネージャー数、研修制度、人事管理レベル
マネジメントシステムP109
情報技術サービス基準評価 ITSS
ITサービスマネジメントシステム認証ITSMS
情報セキュリティマネジメントシステム認証ISMS
IT監査
ITガバナンス
テーマ
ITIL-P117
ITIL情報技術インフラストラクチャライブラリ
これは、1980 年代後半に CCTA (英国国立コンピュータ電気通信庁) によって開発された IT サービス管理仕様ライブラリのセットです。
ITIL は、IT インフラストラクチャを管理する方法を記述したプロセスであり、IT サービスとエンタープライズ サービスを統合することで、企業の IT サービス提供とサービス サポートの能力とレベルを向上させます。
TITLの開発
V1:1989~1995
V2:2000~2004
V3: 2007 年に公開され、V1 と V2 の優れた部分が統合されています。
ITIL2011: V3 の更新バージョン
ITサービスマネジメント(ITSM) P118
本旨
IT 組織は IT サービスプロバイダーです
ITSM の本来の基本的な目標を実装する
顧客中心のITサービスの提供
高品質・低価格のサービスを提供します
提供されるサービスの価格を正確に設定できる
ITSMの基本原則
二次変換の概要
初めてはとかします
2回目は荷造りです
ITSMの範囲
ITSMはIT管理のためのものです
ITSM は IT の運用と管理に重点を置いています
ITSS (情報技術サービス標準)-P121
原則 P122
コンポーネント (PPRT)
人々
プロセス
テクノロジー
リソース
ライフサイクル(PIOIS)
企画・デザイン
導入と実装
サービス運営(運営)
継続的改善
監督
情報システムインテグレーションの専門的な技術知識
3.1 情報システム構築
情報システムのライフサイクル
情報システム構築には、
機器の購入
システム統合
ソフトウェア開発
運用保守サービス
情報システムのライフサイクル
プロジェクト設立
コンセプト段階または要件段階
開発する
プロジェクト立ち上げ段階でのニーズ分析をもとに全体計画を立案
運用・保守
情報システムは検収を経て正式に利用者に引き渡されると、運用・保守の段階に入ります。
死ぬ
情報システムには、システムの更新や機能拡張、あるいは廃棄や再構築が必ず発生します。
情報システム開発手法
構造化されたアプローチ
最も広く使用されている開発手法
開発プロセスはいくつかの段階に分かれており、前段階が後の段階の作業の基礎となり、順番に完了します。
特徴: 開発プロセスの完全性と全体的な性質に焦点を当てる
短所: 開発サイクルが長い、ドキュメントと設計指示が煩雑、作業効率が低い
プロトタイプメソッド
ユーザーのニーズを最初に理解し、まずプロトタイプ システムを迅速に開発し、それを繰り返し修正してユーザーの最終的なシステム ニーズを達成します。
特徴: ユーザーのニーズへの動的な対応と段階的な包含
プロトタイプは使い捨てプロトタイプと進化プロトタイプに分けられます
オブジェクト指向アプローチ
オブジェクトを使用して客観的なものを表現します。 オブジェクトは、システム開発において共有され、繰り返し参照される厳密にモジュール化されたエンティティです。
3.2 情報システムの設計
デザイン
全体的なデザイン
全体的なアーキテクチャ設計、ソフトウェア システムの全体的なアーキテクチャ設計、データ ストレージの全体的な設計、コンピュータおよびネットワーク システムの設計
各部の詳細設計(物理設計)
コード設計
データベース設計
ヒューマン/マシンインターフェース設計
プロセス設計
システム アーキテクチャ: システムをより小さなサブシステムとコンポーネントに分解し、異なる論理層とサービスを生成します。
機器、DBMS、およびテクノロジーの選択: 内部環境および外部環境、システム導入の主観的および客観的条件を考慮することを指します。
3.3 ソフトウェアエンジニアリング
ソフトウェア要件の分析と定義
ソフトウェア要件は解決すべき問題の説明です
定義された要件は検証可能でなければなりません
ソフトウェアの設計、テスト、保守
ソフトウェアの品質保証と品質評価
内部品質、外部品質、使用品質
ソフトウェアの品質保証、検証と検証、レビューと監査
ソフトウェア構成管理
製品の構成要素を特定し、変更を管理および制御し、構成情報を検証、記録および報告することにより、製品の進化と完全性を制御します。
含む
ソフトウェア構成管理計画
組織構造環境と組織単位の関係を理解し、ソフトウェア構成管理タスクを明確にする
ソフトウェア構成識別子
制御する構成項目を特定し、これらの構成項目とそのバージョンのベースラインを確立します。
ソフトウェア構成制御
ソフトウェアのライフサイクル中の変更管理に重点を置く
ソフトウェア構成ステータス記録
構成管理のための構成ステータス情報を識別、収集、維持、および報告する記録
ソフトウェア構成の監査
ソフトウェア製品とプロセスが確立されたルール、標準、ガイドライン、計画、プロセスに準拠しているかどうかを独立して評価します。
ソフトウェアのリリース管理と配信
管理と配信には特定の配信バージョンの作成が必要ですが、これを実現するための鍵となるのはソフトウェア ライブラリです
ソフトウェア管理プロセス
1. プロジェクトの開始と範囲の定義: プロジェクトを開始し、ソフトウェア要件を決定します。
2. プロジェクト計画: 計画を作成し、主要な時点で適切なソフトウェア ライフ サイクル プロセスを決定します。
3. プロジェクトの実施
4. プロジェクトのモニタリングとレビュー
5. プロジェクトの終了と終了
ソフトウェア開発ツール
デマンドツール
要件モデリングツール
要件追跡ツール
デザインツール
プログラムエディタ
翻訳者
コードジェネレーター
通訳者
デバッガ
建設ツール
テストジェネレーター
テスト実行フレームワーク
テスト評価ツール
テスト管理ツール
パフォーマンス分析ツール
メンテナンスツール
理解ツール
リエンジニアリング ツール (リファクタリング ツールなど)
構成管理ツール
追跡ツール
バージョン管理ツール
公開ツール
プロジェクト管理ツール
プロジェクト計画
追跡ツール
リスク管理ツール
測定ツール
エンジニアリングプロセスツール
モデリングツール
管理ツール
ソフトウェア開発環境
高品質のツール
チェックツール
分析ツール
ソフトウェアの活用: さまざまな既存の関連知識を利用して新しいソフトウェアを構築し、ソフトウェアの開発と保守のコストを削減します。
3.4 オブジェクト指向システムの分析と設計
基本的な考え方
物体:
システムが客観的なものを記述するために使用するモジュールであり、システムを構成する基本単位です。
基本要素
オブジェクトのステータス
オブジェクトID
オブジェクトの動作
クラス: エンティティの属性 (データ) と操作 (関数) を一緒にカプセル化します。
抽象化: 特定のインスタンスから共通の特徴を抽出することによって形成される特性
カプセル化: 関連する概念をユニット モジュールにグループ化し、名前を通じてそれを参照します。
継承: クラス間の階層関係を表します。あるタイプのオブジェクトは、別のタイプのオブジェクトの特性を継承できます。
ポリモーフィズム: 同じ操作名または属性名を定義すると、クラスごとに異なる実装が存在する可能性があります。
インターフェース: 操作が何を行うべきかを説明しますが、操作がどのように実行されるべきかは定義しません。
メッセージ: オブジェクト間の対話、関連する操作のターゲット オブジェクトへの指示の送信
コンポーネント: システムの交換可能な物理部分を表します。
再利用
モデル
プロジェクト設立管理
1. 1. 企画提案書
プロジェクト提案書はプロジェクトアプリケーションとも呼ばれます
実現可能性調査の基礎
企画提案書の主な内容
プロジェクトの説明
プロジェクト提案ユニットの概要
プロジェクト構築の必要性
ビジネス分析
全体的な建設計画
このフェーズのプロジェクト建設計画
環境保護、防火、労働安全
プロジェクト実施の進捗状況
投資見積りと資金調達
利益とリスクの分析
2. 2. プロジェクトの実現可能性分析
プロジェクト実現可能性分析内容
投資の必要性
技術的な実現可能性
経済的な実現可能性
組織的な実現可能性
経済的実現可能性
社会的実現可能性
リスク要因と対策
市場リスク
テクノロジーリスク
財務リスク
組織リスク
法的リスク
経済的および社会的リスク
レポート作成
一、 プロジェクト概要
プロジェクト名
プロジェクト構築単位と責任者、プロジェクト責任者
実現可能性調査報告書作成ユニット
実現可能性調査報告書作成の基礎
プロジェクトの建設目標、規模、内容、工期
プロジェクトへの総投資額と資金源
経済的および社会的利益
プロジェクト提案の承認に関する調整
主な結論と提案
二、 プロジェクト構築ユニットの概要
プロジェクト構築単位と機能
プロジェクトの実施組織と責任
三、 ニーズ分析とプロジェクト構築の必要性
ビジネス機能、ビジネスプロセス、およびビジネス量の分析
情報量の分析と予測
システム機能とパフォーマンス要件の分析
情報システムの設備と適用状況とギャップ
プロジェクト構築の必要性
四、 全体的な建設計画
建設の原則と戦略
全体的な目標と段階的な目標
工事全体の課題と段階的な工事内容
全体のデザイン
五、 このフェーズのプロジェクト建設計画
建設目標と規模と内容
情報資源計画とデータベース構築計画
アプリケーション支援基盤とアプリケーションシステム構築計画
データ処理・保管システム構築計画
端末システム構築計画
ネットワークシステム構築計画
セキュリティシステム構築計画
バックアップシステム構築計画
運用保守体制構築計画
その他のシステム構築ソリューション
主なソフトウェアおよびハードウェアの選択原則と詳細なソフトウェアおよびハードウェア構成リスト
機械室および補助エンジニアリング建設計画
事業提案承認に伴う施工計画の変更・調整の詳細な説明
六、 プロジェクト入札計画
入札範囲
入札方法
入札団体様式
七、 環境保護、防火、労働安全
環境影響と環境対策
火災対策
労働安全
八、 プロジェクト組織と人材育成
リーダーシップと管理組織
事業実施機関
運用保守組織
技術力と人材配置
人材育成プログラム
九、 プロジェクト実施の進捗状況
プロジェクトの建設期間
実施スケジュール
十、 投資の見積もりと資金源
投資見積りに関連する指示
プロジェクトの総投資額の見積もり
資金源と実施状況
資金利用計画
プロジェクトの運営・維持管理とコストの見積り
十一、 効果と評価指標の分析
経済的利益の分析
社会的利益の分析
プロジェクトの安価な指標分析
十二、 プロジェクトのリスクとリスク管理
リスクの特定と分析
リスク対策と管理
3. 3. プロジェクトの承認
プロジェクト構築の主な基礎
プロジェクトの提案書
実現可能性調査報告書
予備設計計画
投資予算
4. 4. プロジェクト入札
1. 入札に関する規定
事前資格書類または入札書類の販売期間は 5 日以上とする。
事前予選を通過した応募者が 3 名に満たない場合は、再度入札を行うものとします。
入札保証は、入札プロジェクトの見積価格の 2% 以下を超えてはなりません。
2. プロジェクト入札
プロジェクトの意図の特定
プロジェクトのプリセールスコミュニケーション
入札書類を入手する
入札書類の作成
入札活動に参加する
3. 開札と評価
入札者が 3 名に満たない場合は、入札は行われません。
入札評価委員会は、上級専門職の称号又は同等の専門レベルを有する技術、経済その他の関連分野の専門家、入札者及び入札機関の代表者を含む5名以上の奇数名で構成され、そのうち有識者は5名以上とする。技術、経済、その他の分野の会員は総会員数の3分の2以上でなければならない。
落札者は 3 名以内とし、順位を表示するものとします。
入札者は、入札評価報告書の受領日から3日以内に落札者を公告しなければならず、公知期間は3日を下ることはできません。
入札者は、書面による契約締結後 5 日以内に、入札保証金及び同期間の銀行預金利息を落札者及び落札者に返還しなければならない。
落札者は、入札書類の要件に従って履行保証金を提出するものとし、保証金は落札契約額の 10% 以下を超えてはなりません。
落札者は、落札プロジェクトを他人に譲渡したり、落札プロジェクトを切断して別途他人に譲渡したりすることはできません。
4. 契約交渉と署名
契約交渉
まずは専門用語について話しましょう。
契約の技術添付文書の内容
契約履行テクニカルルート
品質評価基準
機器の購入とシステムの見積もり
開発に投入される人員の割合
ビジネス用語については後ほど説明します。
入札価格の優遇条件
品質
工期
サービス違反に対する罰則
その他交渉が必要なこと
契約書に署名する
契約条件
1||| 当事者の名前と住所
2||| 目標
3||| 量
4||| 品質
5||| 価格と対価
6||| 公演期間、場所、公演方法
7||| 契約違反に対する責任と紛争解決方法
技術契約
1||| プロジェクト名
2||| 主題の内容、範囲および要件
3||| 計画、スケジュール、期限、場所、地域および実施方法
4||| 技術文書および情報の機密保持
5||| リスク責任の引き受け
6||| 技術成果の帰属と利益の共有方法
7||| 受け入れ基準と方法
8||| 価格、報酬またはロイヤルティおよび支払い方法
9||| 損害賠償金または損失補償金の計算方法
10||| 紛争の解決方法
11||| 名詞用語などの解説。
5. 5. サプライヤープロジェクトの確立
プロジェクト内部の理由
プロジェクトの承認を通じてプロジェクトにリソースを割り当てる
プロジェクトの確立を通じて合理的なプロジェクトのパフォーマンス目標を決定することは、従業員のモチベーションの向上に役立ちます
プロジェクトベースの作業方法でプロジェクトの実施効率を向上
社内プロジェクトの内容
プロジェクトリソースの見積もり
プロジェクトリソースの割り当て
プロジェクトの概要を準備する
プロジェクトマネージャーを任命する
プロジェクト管理全般
1. プロジェクト管理全体の概要
全体的なプロジェクト管理には、さまざまなプロジェクト管理プロセス グループのさまざまなプロセスとアクティビティを特定、定義、結合、統合、調整するために実行される作業が含まれます。これは、プロジェクト管理における包括的かつ全体的な管理作業です。
6工程
プロジェクト憲章の作成
プロジェクト管理計画を作成する
プロジェクト作業を指示および管理する
プロジェクトの作業を監視する
総合的な変更管理を実装する
プロジェクトまたはフェーズの終了
プロジェクト管理チームが実行できるアクティビティには次のものがあります。
プロジェクトの範囲を分析して理解する
製品要件の文書承認基準
特定された情報を取得し、それを構造化された方法でプロジェクト管理計画に組み込む方法を理解する
作業分解構造を準備する
計画された範囲と全体的な管理プロセスに従ってプロジェクトが確実に実施されるように、適切な措置を講じます。
プロジェクトのステータス、プロセス、製品を測定および監視する
プロジェクトのリスクを分析する
2. プロジェクトの全体的な実施プロセス
プロジェクト憲章の作成
1||| プロジェクト憲章の役割
プロジェクトマネージャーを決定し、プロジェクトマネージャーの権限を定義する
プロジェクトの存在を正式に確認し、プロジェクトに法的地位を与える
範囲、時間、コスト、品質など、プロジェクトの全体的な目標を定義します。
プロジェクトを開始する理由を説明することで、プロジェクトと実行組織の日常業務や戦略計画を結び付けます。
2||| プロジェクト憲章を作成するためのインプット
a. プロジェクト作業明細書 SOW
ビジネスニーズ
製品範囲の説明
戦略計画
b. ビジネスケース
プロジェクトが投資する価値があるかどうかを判断するために、ビジネスの観点から必要な情報を提供する
c. プロトコル
プロジェクトを開始する当初の意図を定義します (契約書、覚書 (MOU)、サービス品質契約 (SLA)、合意書、意向書、口頭合意、電子メール、またはその他の書面による合意)
d. 組織プロセス資産
組織の標準手順、ポリシー、プロセス定義
テンプレート (プロジェクト憲章テンプレートなど)
歴史情報と教訓知識ベース (プロジェクトの記録と文書、完全なプロジェクト終了情報と文書、以前のプロジェクト選択決定の結果と過去のプロジェクトの実績に関する情報、リスク管理活動中に生成された情報など)
e. 事業環境要因
政府の基準
業界標準または規制 (職業上の行動規範、品質基準、労働者保護規制など)
組織文化と構造
市況
3||| プロジェクト憲章を作成するためのツールとテクニック
専門家の判断
誘導技術
ブレーンストーミング
競合の処理
問題が解決しました
会議の管理
4||| プロジェクト憲章の成果物を作成する
プロジェクト計画書
3. プロジェクト管理計画を作成する
入力
プロジェクト計画書
他の計画プロセスからの出力
組織プロセス資産
スケジュール
リスクデータ
価値のあるデータを実現する
財務管理手順
履歴情報
教訓ナレッジベース、操作ガイド
事業環境要因
ツールとテクニック
専門家の判断
誘導技術
ブレーンストーミング
競合の処理
問題が解決しました
会議の管理
出力
プロジェクト管理計画
使用されるプロジェクト管理プロセス
それぞれの特定のプロジェクト管理プロセスがどの程度実装されているか
このプロセスを実行するために使用されるツールとテクニックの説明
プロジェクトで使用されるライフサイクルと各フェーズで使用されるプロセス
選択したプロセスを使用して特定のプロジェクトを管理する方法
プロジェクトの目的を達成するために作業がどのように実行されるか、およびプロジェクトの目的の説明
変更をどのように監視および制御し、変更をどのように監視するかを明確にする方法
構成管理の実行方法を定義する構成管理計画
プロジェクトのパフォーマンスのベースラインの整合性を維持するための指示
プロジェクトの関係者とコミュニケーションをとるための要件とテクニック
プロジェクトに選択されたライフサイクル モデル
特定のレガシーおよび保留中の決定の内容、重大度、緊急性に関する重要な管理レビュー
補助計画
1||| スコープ管理計画
2||| 需要管理計画
3||| 進捗管理計画
4||| コスト管理計画
5||| 品質管理計画
6||| プロセス改善計画
7||| 人事管理計画
8||| コミュニケーション管理計画
9||| リスク管理計画
10||| 調達管理計画
11||| ステークホルダー管理計画
4. プロジェクト作業を指示および管理する
入力
プロジェクト管理計画
承認された変更リクエスト
事業環境要因
組織文化、企業文化、または顧客文化
実施組織または主催組織の構成
インフラストラクチャー
人事管理制度
ステークホルダーのリスク許容度
プロジェクト管理情報システム
組織プロセス資産
ツールとテクニック
プロジェクト管理情報システム
スケジュール計画ツール
就労許可制度
構成管理システム
情報収集・公開体制
記録保持ポリシーとセキュリティ要件
問題および欠陥の管理プロセス
プロセス測定データベース
過去のプロジェクトのプロジェクトアーカイブ
問題および欠陥管理データベース
ミーティング
情報交換
マインドプラン、計画評価、または計画設計
決定する
専門家の判断
出力
成果物
仕事のパフォーマンスデータ
変更要求
是正処置
注意事項
欠陥の修復
更新する
プロジェクト管理計画の更新
プロジェクトファイルの更新
要件文書
プロジェクトログ
リスク記録簿
利害関係者登録簿
5. プロジェクトの作業を監視する
入力
プロジェクト管理計画
進捗予測
進捗偏差SV
スケジュールパフォーマンスインデックスSPI
コスト予測
確認された変更点
仕事のパフォーマンス情報
事業環境要因
組織プロセス資産
組織のコミュニケーション要件
財務管理手順
問題と欠陥の管理手順
変更管理手順
リスク管理手順
プロセス測定データベース
教訓データベース
ツールとテクニック
分析能力
回帰分析
グループ分析
原因と結果の分析
根本原因分析 RCA
予測方法
故障モードと影響解析 FMEA
フォールトツリー解析FTA
埋蔵量分析
トレンド分析
収益価値管理
ETC 完了までの推定所要時間
プロジェクト管理情報システム
ミーティング
専門家の判断
出力
変更要求
是正処置
注意事項
欠陥の修復
仕事のパフォーマンスレポート
プロジェクト管理計画の更新
プロジェクトファイルの更新
スケジュールとコストの予測
仕事のパフォーマンスレポート
問題ログ
6. 総合的な変更管理を実装する
入力
プロジェクト管理計画
仕事のパフォーマンスレポート
変更要求
組織プロセス資産
事業環境要因
ツールとテクニック
ミーティング
変更管理ツール
専門家の判断
出力
承認された変更リクエスト
変更ログ
プロジェクト管理計画の更新
プロジェクトファイルの更新
7. プロジェクトまたはフェーズの終了
入力
プロジェクト管理計画
受領のための成果物
組織プロセス資産
ツールとテクニック
分析能力
ミーティング
専門家の判断
出力
最終的な製品、サービス、または結果
組織プロセス資産の更新
プロジェクトの範囲管理
一、 プロジェクトの範囲管理
重要性
1||| プロジェクトの具体的な範囲と具体的な作業内容を明確にし、コスト、時間、リソースの見積もりの精度を向上させるための基礎を提供します。
2||| プロジェクト スコープによってどのような具体的な作業を完了するかが決まるため、プロジェクト スコープ ベースラインはプロジェクトの進捗状況の測定と管理を決定するためのベースラインとなります。
3||| プロジェクトのスコープの決定は、プロジェクトの具体的な作業タスクを決定することであり、これは責任を明確に分割し、タスクを割り当てるのに役立ちます。
6工程
1||| プロジェクトのスコープを定義、確認、管理する方法のプロセスを説明するスコープ管理計画プロセスを準備します。
2||| 要件を収集する
3||| 範囲を定義する
4||| 作業分解構造を作成する
5||| 範囲の確認
6||| スコープ制御
二、 範囲管理計画を作成する
入力
プロジェクト管理計画
プロジェクト計画書
組織プロセス資産
事業環境要因
ツールとテクニック
ミーティング
専門家の判断
出力
プロジェクト範囲管理計画
詳細なプロジェクトスコープステートメントを作成する
詳細なスコープステートメントに基づいて WBS を作成する
作業分解構造 (WBS) の維持と承認
完了したプロジェクト成果物の正式な受領
詳細なプロジェクト スコープ ステートメントまたは WBS への変更を処理する
需要管理計画(内容)
さまざまな要件アクティビティを計画、追跡、レポートする方法
構成管理アクティビティ
製品の変更を開始する方法
その影響を分析する方法
追跡、追跡、報告する方法
承認権限の変更
要件の優先順位付けプロセス
製品の寸法と使用理由
どの要件属性がトレース マトリックスに含まれるかを反映するために使用されるトレース構造
要件の収集プロセス
三、 要件を収集する
入力
スコープ管理計画
需要管理計画
ステークホルダー管理計画
プロジェクト計画書
利害関係者登録簿
ツールとテクニック
インタビュー
フォーカスグループ
ガイド付きセミナー
グループ革新技術
グループでの意思決定テクニック
アンケート
観察する
プロトタイプメソッド
ベンチマーク
システム相互作用図
ファイル分析
出力
要件文書(内容を含む)
(1) ビジネスニーズ
1||| 追跡可能な目標とプロジェクトの目標
2||| 組織のビジネスルールを強制する
3||| 組織の基本原則
(2) ステークホルダーのニーズ
1||| 組織の他の領域への影響
2||| 実行組織の内部または組織外部のグループへの影響
3||| 利害関係者のコミュニケーションと報告のニーズ
(3) ソリューションの要件
1||| 機能要件と非機能要件
2||| 技術的および標準準拠のニーズ
3||| サポートとトレーニングのニーズ
4||| 品質要件
5||| 報告要件
(4) プロジェクトの要件
1||| サービスレベル、パフォーマンス、セキュリティ、コンプライアンスなど。
2||| 合否基準
(5) 移行のニーズ
(6) 要件に関連する前提、依存関係、および制約
要件追跡マトリックス (内容を含む)
1||| ビジネスのニーズ、機会、目標および目的
2||| プロジェクトの目的
3||| プロジェクトの範囲/WBS 成果物
4||| 製品デザイン
5||| 製品開発
6||| テスト戦略とテストシナリオ
7||| 大まかな要件から詳細な要件まで
四、 範囲の定義
入力
スコープ管理計画
プロジェクト計画書
要件文書
組織プロセス資産
ツールとテクニック
製品分析
(1) 製品の内訳
(2) システム分析
(3) 需要分析
(4) システムエンジニアリング
(5) バリューエンジニアリング
(6) 価値分析
専門家の判断
代替世代
ガイド付きセミナー
出力
プロジェクトのスコープステートメント(内容を含む)
(1) プロジェクトの目的
(2) 製品範囲の説明
(3) プロジェクトの要件
(4) プロジェクトの境界
(5) プロジェクトの成果物
(6) プロジェクトの制約
(7) 仮定
プロジェクトファイルの更新
利害関係者登録簿
要件文書
要件追跡マトリックス
五、 作業分解構造を作成する
入力
スコープ管理計画
プロジェクトスコープステートメント
要件文書
組織プロセス資産
事業環境要因
ツールとテクニック
壊す
プロジェクト作業全体を作業パッケージに分割するには、次のアクティビティが必要です。
(1) 成果物と関連作業を特定して分析する
(2) WBSの構造と配置を決定する
(3) 上から下へレイヤーごとに分解
(4) 識別コードを開発して WBS コンポーネントに割り当てる
(5) 成果物の分解の適切なレベルを検証する
一般に、プロジェクトを 3 ~ 5 つのレベルに分割するのが適切です。レベルが多すぎる場合は、プロジェクトをさらに複数のサブプロジェクトに分割するのが最善です。レベルが少なすぎると、制御が不便になります。大規模なプロジェクトを管理します。
作業構造を分解するときは、次の原則に従う必要があります。
(1) プロジェクトの整合性を階層的に維持して、重要なコンポーネントの欠落を回避します
(2) 相互従属を避けるために、作業ユニットは上位レベルのユニットにのみ従属できます。
(3) 同じレベルのワークユニットには同じプロパティが適用されます
(4) 作業単位は異なる責任者と異なる作業内容を分離できる必要があります
(5) プロジェクト管理計画とプロジェクト管理のニーズを促進する
(6) 最下位レベルの作業は比較可能で、管理可能で、定量的に確認できる必要があります。
(7) 下請け作業を含むプロジェクト管理作業を含める必要があります
専門家の判断
出力
スコープベースライン
承認された範囲ステートメント、作業分解構造 (WBS)、および対応する WBS 辞書が範囲ベースラインを形成します
成分
(1) プロジェクトスコープステートメント
(2) WBS は、プロジェクトの目標を達成し、必要な成果物を作成するためにプロジェクト チームが実行する必要がある作業の全範囲を階層的に分類したものです。
(3) WBS ディクショナリは WBS コンポーネントごとにあり、WBS ディクショナリの内容は次のとおりです。
a. アカウントコード識別子
b. 作業説明
c. 仮定と制約
d. 責任ある組織
e. 進歩のマイルストーン
f. 関連する進捗活動
g. 必要なリソース
h. 原価見積
i. 品質要件
j. 合否基準
k. 技術参考資料
l. プロトコル情報
(4) プロジェクトファイルの更新
プロジェクトファイルの更新
WBSの役割と意義
作業分解構造の作成は、プロジェクトの成果物とプロジェクトの作業を、より小さく管理しやすいコンポーネントに分割するプロセスです。
作業分解構造 (WBS) はプロジェクト管理の基礎です。プロジェクトのすべての計画および管理作業は、作業分解構造に基づいて行う必要があります。
主な機能は、配信されるコンテンツの構造化されたビューを提供することです
WBS は、プロジェクトの目標を達成し、成果物を作成するために実装する必要があるすべての作業範囲を階層的に分解したものです。
WBS は、プロジェクトの全体的な範囲を整理および定義し、承認された現在のプロジェクト範囲ステートメントで指定された作業を表します。
各ワーク パッケージを制御アカウントに割り当て、「アカウント コード」に基づいてワーク パッケージの一意の識別子を確立することが、WBS 作成の最後のステップです。
意義:
(1) 作業構造分解により、プロジェクト関係者が一目でプロジェクトを理解できるようにプロジェクトをブレークダウンし、プロジェクトの概要や構成を明確、明確、透明、具体的にすることができます。
(2) プロジェクト構造の体系性と整合性を確保する
(3) 作業構造の分解を通じて、完全なプロジェクト保証システムを確立できます。この分解プロセスでは、スケジュール、コスト、品質などのプロジェクト全体の目標の重要なポイントが制御可能なプロジェクト単位に分解され、目標要件の実行と実現が促進されるためです。
(4) プロジェクトの作業構造を分解すると、プロジェクトに関与するすべての関係者の作業インターフェースが明確になり、責任の分割と実行が容易になります。
(5) 最終的な作業分解構造は、スケジュールの計画と管理のためのツールとして直接使用できます。
(6) プロジェクトのコミュニケーション管理を確立するための基盤を提供し、情報の重要なポイントを把握しやすくします。
(7) これは、プロジェクトの各サブプランおよび管理手段の策定の基礎および主要な基盤です。
(8) 要件やスコープクリープの防止に役立ちます
コンテンツ
(1) WBS の最下位の作業単位は作業パッケージと呼ばれ、スケジュールの調整、コストの見積もり、監視の基礎となります。
(2) 作業分解構造は、プロジェクトの範囲を決定するために使用されます。プロジェクトのすべての作業は作業分解構造に含まれている必要があり、作業分解構造に含まれていない作業はプロジェクトの一部ではないため、実行できません。
(3) 作業分解構造の準備には、プロジェクトのすべての関係者とプロジェクト チームのメンバーの参加が必要です。
(4) 作業分解構造は層ごとに分解されます。一般的に、作業分解構造は 3 ~ 6 層で管理されます。
(5) 作業分解構造の各要素は比較的独立しており、相互の重複は最小限に抑える必要があります。
作業分解構造の表現
(1) 階層ツリー構造
組織図のようなもの
ツリー構造図の WBS は明確なレベルを持ち、非常に直感的で、強力な構造を持っています。一般に、小規模および中程度のアプリケーション プロジェクトでよく使用されます。
(2) 表形式
階層型書籍カタログに似ています
このテーブルはプロジェクトのすべての作業要素を反映できますが、直感的ではありませんが、それでも一部の大規模で複雑なプロジェクトでよく使用されます。
特徴
各層のすべての要素の合計は、次の層の作業の合計になります。
各作業要素は、複数のレベルではなく 1 つのレベルに明確に割り当てる必要があります。
プロジェクト チームのメンバーが完了すべき作業を包括的に理解できるように、作業分解構造には、その作業の範囲を説明する必要があります。
(3) コンセプト
マイルストーン
マイルストーンは、成果物またはフェーズの正式な完了を示します。
ワークパッケージ
作業分解構造の各ブランチの最下位レベルにある成果物またはプロジェクトの作業コンポーネントです。
作業パッケージのサイズが完了するまでに少なくとも 8 時間かかり、合計完了時間が 80 時間を超えないようにすることをお勧めします。
特徴
小規模で短時間(80時間)で完了可能
論理的に言えば、それ以上分割することはできません。
必要なリソース、時間、コストなどをより正確に見積もることができ、効果的な時間、コスト、品質、範囲、リスク管理を行うことができます。
WBSコーディング設計
六、 プロジェクト範囲の確認
入力
プロジェクト管理計画
要件追跡マトリックス
要件文書
検証された成果物
仕事のパフォーマンスデータ
ツールとテクニック
診る
グループでの意思決定テクニック
出力
受領のための成果物
変更要求
仕事のパフォーマンス情報
プロジェクトファイルの更新
プロジェクト確認作業のポイント
検証手順の開発と実装
(1) スコープをいつ確認する必要があるかを判断する
(2) スコープを検証するためにどのような入力が必要かを特定する
(3) 正式に受け入れられた範囲設定の基準と要素を決定する
(4) 範囲会議の組織的な手順を決定する
(5) 範囲確認会議を開催する
プロジェクト関係者からのプロジェクト範囲の正式な確認
(1) 成果物が具体的であるか、確認可能であるか、検証可能であるか
(2) 各成果物には明確なマイルストーンがありますか? マイルストーンは明確で識別可能ですか?
(3) 明確な品質基準はありますか?
(4) レビューやコミットメントが明確に表現されているかどうか
(5) プロジェクトの範囲は、製品またはサービスを完成させるために必要なすべての活動をカバーしていますか?
(6) プロジェクト全体のリスク発生の確率、および管理者がプロジェクトに対する予見可能なリスクの影響を軽減できるかどうか
七、 プロジェクト範囲の制御
入力
プロジェクト管理計画(スコープ管理用)
(1) スコープベースライン
(2) スコープ管理計画
(3) 変更管理計画
(4) 構成管理計画
(5) 需要管理計画
要件追跡マトリックス
要件文書
仕事のパフォーマンスデータ
組織プロセス資産
ツールとテクニック
偏差分析
出力
プロジェクト管理計画の更新
(1) スコープベースラインの更新
(2) その他のベンチマークのアップデート
変更要求
仕事のパフォーマンス情報
プロジェクトファイルの更新
組織プロセス資産の更新
プロジェクトの進捗管理(時間管理)
一、 プロジェクトを期限内に完了するまで管理するために必要な 7 つのプロセス
(1) スケジュール管理プロセスの計画 - プロジェクトのスケジュールを管理するためのポリシー、手順、文書を作成します。
(2) 活動プロセスを定義する - プロジェクトの成果物を完了するために実行する必要がある特定のアクションを特定して文書化します。
(3) アクティビティのプロセスの順序付け - プロジェクトのアクティビティ間の関係を特定して文書化する
(4) 活動リソースのプロセスの見積もり - 各活動を実行するために必要な資材、人員、設備、消耗品の種類と数量を見積もります。
(5) アクティビティ期間の見積もりプロセス - リソース見積もりの結果に基づいて、1 つのアクティビティを完了するのに必要な期間を見積もります。
(6) スケジュール計画プロセス - アクティビティの順序、期間、リソース要件、スケジュールの制約を分析して、プロジェクトのスケジュール モデルを作成します。
(7) スケジュール プロセスを制御する - プロジェクトのアクティビティ ステータスを監視し、プロジェクトの進行状況を更新し、計画を達成するためのスケジュール ベースラインの変更を管理します。
上で説明したプロセスは、相互に相互作用するだけでなく、他の知識領域のプロセスとも相互作用します。
二、 企画プロジェクトの進捗管理
入力
プロジェクト管理計画
スコープベースライン
プロジェクトスコープステートメント
WBS
WBS辞書
その他の情報 (コスト、リスク、計画スケジュールに関連するコミュニケーション上の決定など)
プロジェクト計画書
組織プロセス資産
事業環境要因
ツールとテクニック
専門家の判断
分析能力
ミーティング
出力
プロジェクト進捗管理計画(規定)
(1) プロジェクトスケジュールモデルの開発
(2) 正確さ
(3) 測定の単位
(4) 組織プログラムのリンク
(5) プロジェクトスケジュールモデルのメンテナンス
(6) 制御閾値
(7) パフォーマンス測定ルール
(8) レポート形式
(9) 過程説明
三、 アクティビティを定義する
入力
プロジェクトスケジュール管理計画
スコープベースライン
組織プロセス資産
事業環境要因
ツールとテクニック
壊す
分解は、プロジェクトの範囲とプロジェクトの成果物を、より小さく管理しやすいコンポーネントに段階的に分割する手法です。
ローリングプランニング
これは反復的な計画手法です。つまり、近い将来に完了する作業は作業分解構造の最下位レベルで詳細に計画され、長期的に完了する予定の作業は上位レベルで大まかに計画されます。作業分解構造のレベル。
これは、プロジェクト チームが計画を徐々に改善できる、進歩的で詳細な計画方法です。
専門家の判断
出力
アクティビティリスト
アクティビティのプロパティ
アクティビティ リストのアクティビティの説明を拡張したものです
マイルストーンリスト
プロジェクトの重要なポイントまたはイベントです
すべてのプロジェクトのマイルストーンをリストし、各マイルストーンが必須かオプションかを示します。
四、 シーケンスアクティビティ
入力
プロジェクトスケジュール管理計画
アクティビティリスト
アクティビティのプロパティ
マイルストーンリスト
プロジェクトスコープステートメント
事業環境要因
組織プロセス資産
ツールとテクニック
誘導図法 P299
シングルコードネットワーク図またはアクティブノード図
関係
(1) エンドスタート(F-Sタイプ)
(2) エンド-エンド(F-Fタイプ)
(3) スタート-スタート(S-Sタイプ)
(4) 始端-終端(S-Fタイプ)
アローチャート法 P300
ダブルコードネットワーク図またはアクティブアロー図
基本原則
(1) ネットワーク図内の各アクティビティとイベントには一意のコード名が必要です。つまり、ネットワーク図内に同じコード名は存在しません。
(2) 任意の 2 つのアクティビティの前後イベントのコードの少なくとも一方が異なり、矢印の方向に沿ってノード コードが大きくなります。
(3) 同じノードに流入する (または流出する) アクティビティには、共通の後続アクティビティ (または先行アクティビティ) があります。
依存関係の決定 P302
(1) 必須の依存関係
ハード論理関係またはハード依存関係とも呼ばれます
(2) 選択的な依存関係
優先論理関係、優先論理関係、ソフトウェア論理関係とも呼ばれることもあります。
(3) 外部依存関係
プロジェクトアクティビティと非プロジェクトアクティビティ間の依存関係はどうか
(4) コンテンツの依存関係
プロジェクト活動間の直接的な関係はありますか
進みと遅れ
出力
プロジェクト進捗ネットワーク図
プロジェクトファイルの更新
活動リストを更新
アクティビティのプロパティを更新する
マイルストーンリストを更新
リスク登録を更新する
効果
プロジェクト間のすべての制約を考慮して最大の効率を達成するために、タスク間の論理シーケンスを定義します。
五、 活動リソースの見積り P303
入力
プロジェクトスケジュール管理計画
アクティビティリスト
アクティビティのプロパティ
リソースカレンダー
リスクレジスター
活動コストの見積もり
事業環境要因
組織プロセス資産
ツールとテクニック
専門家の判断
代替案分析
公表されている推定値
プロジェクト管理ソフトウェア
ボトムアップ推定
出力
アクティビティのリソース要件
リソースの内訳構造
プロジェクトファイルの更新
活動リストを更新
アクティビティのプロパティを更新する
リソースカレンダーを更新する
意味
さまざまな活動を実行するために必要な資材、人員、設備、または消耗品の種類と数量を見積もるプロセスです
効果
より正確なコストと期間の見積もりを行えるように、アクティビティを完了するために必要なリソースの種類、数量、特性を特定します。
六、 イベント期間の推定 P306
入力
プロジェクトスケジュール管理計画
アクティビティリスト
アクティビティのプロパティ
アクティビティのリソース要件
リソースカレンダー
プロジェクトスコープステートメント
仮定
現在の状況
情報の入手可能性
報告期間の長さ
制約
熟練したリソースが利用可能
契約条件と要件
リスクレジスター
リソースの内訳構造
事業環境要因
組織プロセス資産
ツールとテクニック
専門家の判断
類推推定
パラメータ推定
三点推定 P308
予想される期間
式 tE=(tO 4tM tP)/6
最も可能性の高い時間 tM
最も楽観的な時間 t0
最も悲観的な時間 tP
標準偏差=(tP-tO)/6
グループでの意思決定テクニック
埋蔵量分析
出力
アクティビティ所要時間の見積もり
プロジェクトファイルの更新
意味
これは、リソース見積もりの結果に基づいて、1 つのアクティビティを完了するのに必要な作業期間数を見積もるプロセスです。
効果
各アクティビティを完了するのに必要な時間を決定し、スケジュール計画プロセスへの主要な入力を提供します。
七、 進捗計画を作成する
入力
プロジェクトスケジュール管理計画
アクティビティリスト
アクティビティのプロパティ
プロジェクト進捗ネットワーク図
リソースカレンダー
アクティビティ所要時間の見積もり
リスクレジスター
プロジェクトスタッフの配置
リソースの内訳構造
事業環境要因
組織プロセス資産
ツールとテクニック
(1) ネットワーク分析の進捗
(2) クリティカルパス方式 P312
(2)1. フォワードメソッド
(2)1.1. 論理関係の方向に従って: ネットワーク図の最初から最後まで計算されます。
(2)1.2. 最初のアクティビティの最も早い開始時刻がプロジェクトの最も早い開始時刻になります。
(2)1.3. アクティビティの最も早い終了時間は、アクティビティの最も早い開始時間にアクティビティの継続時間を加えたものです。
(2)1.4. アクティビティの最も早い開始時間は、先行アクティビティの最も早い完了時間によって決まります。複数の先行アクティビティが存在する場合は、最後に完了したアクティビティの最も早い完了時間が使用されます。
(2)2. バックキャスティング法
(2)2.1. 論理関係の方向に従って: 端末からネットワーク図の先頭まで計算
(2)2.2. 最後のアクティビティの最も遅い完了時刻がプロジェクトの最も遅い完了時刻となります。
(2)2.3. アクティビティの最も遅い開始時刻は、アクティビティの最も遅い終了時刻からアクティビティの継続時間を引いたものです。
(2)2.4. アクティビティの最新の完了時刻は、後続アクティビティの最新の開始時刻に基づきます。複数の後続アクティビティが使用可能な場合は、最初に開始された後続アクティビティの最新の開始時刻が使用されます。
(2)3. フロート時間
(2)3.1. 合計フローティング時間: このアクティビティの最も遅い完了時間からこのアクティビティの最も早い完了時間を引いた時間、またはこのアクティビティの早い開始時間と遅い開始時間からこのアクティビティの最も早い開始時間を引いた時間
(2)3.2. 自由浮動小数点: 後続アクティビティの最も早い開始時刻からこのアクティビティの最も早い終了時刻を引いた最小値
(3) クリティカルチェーン法
(4) モデリング技術
(5) 進みと遅れ
(6) 進行状況の圧縮
(7) スケジュール計画ツール
出力
進行状況のベースライン
スケジュールのベースラインは承認されたプロジェクトのスケジュールです
プロジェクトスケジュール
横棒グラフは、概要スケジュールまたはガント チャートとも呼ばれ、縦軸にアクティビティがリストされ、横軸に日付が配置され、アクティビティの期間が開始日と終了日によって配置された横棒で表されます。経営陣に状況を報告すること。
マイルストーン スケジュールとも呼ばれるマイルストーン図は、主要な成果物と主要な外部インターフェイスの計画された開始日と完了日をマークするだけです。
プロジェクト スケジュール ネットワーク図は詳細スケジュール計画とも呼ばれ、通常は時間スケールを持ち、純粋にアクティビティとその相互関係を表示します。純粋な論理図とも呼ばれます。
進捗データ
プロジェクトカレンダー
プロジェクト管理計画の更新
進捗ベースラインを更新しました
進捗管理計画を更新しました
プロジェクトファイルの更新
イベントリソース要件を更新しました
更新されたアクティビティのプロパティ
カレンダーを更新しました
リスク登録簿を更新しました
八、 制御進捗 P320
入力
プロジェクト管理計画
プロジェクトスケジュール
仕事のパフォーマンスデータ
プロジェクトカレンダー
進捗データ
組織プロセス資産
ツールとテクニック
人事考課
トレンド分析
クリティカルパス方式
クリティカルチェーン法
収益価値管理
サブトピック
プロジェクト管理ソフトウェア
リソース最適化技術
モデリング技術
リードとラグ
進行状況の圧縮
スケジュール計画ツール
出力
仕事のパフォーマンス情報
進捗予測
変更要求
プロジェクト管理計画の更新
進捗ベースラインを更新しました
進捗管理計画を更新しました
コストベースラインを更新しました
プロジェクトファイルの更新
進捗データを更新しました
プロジェクトスケジュールを更新しました
リスク登録簿を更新しました
組織プロセス資産の更新
効果:
計画からの逸脱を検出する方法を提供し、リスクを軽減するために修正および予防措置を迅速に講じることができるようにする
進捗管理は次の点に重点を置いています。
(1) プロジェクトの進捗状況を確認する
(2) スケジュール変更を引き起こす要因に影響を与え、そのような変更が確実に好ましい方向に進むようにする
(3) プロジェクトのスケジュールが変更されたかどうかを確認する
(4) 実際に変更が発生した場合は、変更管理プロセスに厳密に従って管理します
スケジュールベースラインへの変更は、統合された変更管理プロセスを通じて承認される必要があります。
アクティビティの時間を短縮する方法:
(1) 重要な活動の期間を短縮するために、仕事を急ぐ、より多くのリソースを投資する、または労働時間を増やす
(2) 高速フォローアップ、並列構築、クリティカルパス長の短縮
(3) 高度な資格を持つリソースまたはより経験豊富な人材を使用する
(4) 活動範囲を減らすか、活動要件を減らす
(5) 方法や技術を改善して規模の効率を高める
(6) 品質管理を強化し、問題を時間内に発見し、手戻りを減らし、工期を短縮します。
プロジェクトのコスト管理
一、 コスト管理の概念と関連用語
概念: コストとは、プロジェクト活動またはその構成要素の金銭的価値または価格を指します。これには、活動またはその構成要素を実装、完了、または作成するために必要なリソースの金銭的価値も含まれます。
コストには、直接労働時間、その他の直接経費、間接労働時間、その他の諸経費、調達コストが含まれます。
プロジェクト管理は、範囲、時間、コスト、品質によって制限されます。プロジェクトのコスト管理は、プロジェクト管理において重要な役割を果たします。
プロジェクトのコストが制御不能になる理由:
(1) エンジニアリングプロジェクトに対する理解が不十分
(2) 組織体制が健全ではない
(3) 方法論的な問題
(4) 技術的な制約
(5) 不適切な需要管理
プロジェクトのコスト管理プロセス
(1) コスト管理計画の策定
(2) 原価見積
(3) コストの予算
(4) 原価管理
関連用語
(1) 製品ライフサイクルコスト
(2) タイプ
1||| 変動費
2||| 固定費
3||| 直接費
a. プロジェクトチームの旅費
b. 給料
c. プロジェクトで使用した素材
d. 設備使用料
4||| s
このプロジェクトに割り当てられたコスト
税金、付加給付、セキュリティ料
5||| 機会費用
6||| 埋没費用
(3) 危険準備金と管理準備金
(4) 原価ベース
二、 プロジェクトのコスト管理計画を作成する
入力
プロジェクト管理計画
スコープベースライン
進行状況のベースライン
プロジェクト計画書
事業環境要因
組織プロセス資産]
ツールとテクニック
専門家の判断
分析能力
ミーティング
出力
コスト管理計画
三、 プロジェクト費用の見積り
見落とされやすい主な要因
間接費
学習曲線
プロジェクトの完了期限: プロジェクトの期間はコストに影響します
品質要件: 品質要件が高くなるほど、品質コストも高くなります
予約する
コスト見積もりの手順
コスト構成要素の特定と分析
特定されたプロジェクトのコスト構成要素に基づいて、各アカウントのコストを見積もります
コスト見積り結果を分析し、代替可能な各種コストを特定し、各コスト間の比例関係を調整する
入力
コスト管理計画
人事管理計画
スコープベースライン
スコープステートメント
WBS
WBS辞書
プロジェクトスケジュール
リスクレジスター
事業環境要因
組織プロセス資産
ツールとテクニック
専門家の判断
類推推定
パラメータ推定
ボトムアップ推定
三点推定
式: Ce=(Co 4Cm Cp)/6
おそらく費用は Cm
最も楽観的なコストコ
最も悲観的なコストCP
埋蔵量分析
品質コスト
プロジェクト管理ソフトウェア
販売者の入札分析
グループでの意思決定テクニック
出力
活動コストの見積もり
推定根拠
見積もりの根拠の文書化 (例: 見積もりの作成方法)
すべての仮定の文書化
さまざまな既知の制約の文書化
推定間隔の説明
最終推定値の信頼レベルの説明
プロジェクトファイルの更新
四、 事業費予算
コスト予算作成は、プロジェクトのパフォーマンスを測定するための全体的なコストの基準を確立するための、個々のアクティビティまたは作業パッケージの推定コストの概要です。
基本コンセプト:
プロジェクトのコスト予算の特徴:
計画
バインディング
制御する
従うべき原則
プロジェクトのコスト予算はプロジェクトのニーズに基づく必要があります
プロジェクトのコスト予算はプロジェクトの目標に関連付けられている必要があり、プロジェクトの品質やスケジュールなどの目標も考慮する必要があります。
プロジェクトのコスト予算は現実的かつ実現可能でなければなりません
プロジェクトのコスト予算には柔軟性を考慮する必要があります
プロジェクトコストの予算ステップ
プロジェクトの作業分解構造内の個々の作業パッケージにプロジェクトの総コストを割り当てます。
各作業パッケージのコストを、作業パッケージに含まれるアクティビティに再配分します。
各コスト予算支出の時間計画とプロジェクトコスト予算計画を決定します。
入力
コスト管理計画
スコープベースライン
活動コストの見積もり
推定根拠
プロジェクトスケジュール
リソースカレンダー
リスクレジスター
プロトコル
組織プロセス資産
ツールとテクニック
費用の概要
埋蔵量分析
専門家の判断
歴史的な関係
資金調達限度額残高
出力
原価ベース
プロジェクトの資金要件
プロジェクトファイルの更新
五、 プロジェクトのコスト管理
プロジェクトのコスト管理の内容:
(1) コストベースラインの変更を引き起こす影響要因
(2) すべての変更リクエストが速やかに処理されるようにする
(3) 実際に発生した変更を管理する
(4) コスト支出が承認された資金制限を超えず、期間別、WBS コンポーネント別、活動別の割り当て制限を超えず、プロジェクト全体の制限を超えないことを確認します。
(5) コストパフォーマンスを監視し、コストベースラインからの逸脱を特定して分析する
(6) 設備投資に対する作業パフォーマンスを監視する
(7) コストまたはリソース使用量レポートの未承認の変更を防止する
(8) 承認されたすべての変更とそれに関連するコストを関係者に報告します。
(9) 予想されるコスト超過を許容範囲内に抑えるように努めてください
入力
プロジェクト管理計画
原価ベース
コスト管理計画
プロジェクトの資金要件
仕事のパフォーマンスデータ
組織プロセス資産
ツールとテクニック
(1) 収益価値管理 (EVM)
1||| 主要な指標
a. 計画値PV
b. 獲得価値EV
c. 実費AC
2||| 偏差
a. 進捗偏差 SV=EV-PV
b. コスト偏差 CV=EV-AC
c. スケジュールパフォーマンス指数 SPI=EV/PV
d. コストパフォーマンス指数CPI=EV/AC
(2) 予測する
1||| 非定型偏差に基づいて ETC=BAC-EV を計算します
2||| 一般的な偏差に基づいて ETC=(BAC-EV)/CPI または ETC=BAC/CPI を計算します
3||| BAC は完了時の予算です
4||| EAC (完了時見積り) は、完了した AC に実際にかかる費用と、完了する予定の残りの作業の推定額を加算したものです。 EAC = AC ETC
(3) 完了までのパフォーマンス指数 TCPI
1||| 残りの作業を完了するのに必要なコストを残りの予算で割ったものです
2||| TCPI=(BAC-EV)/(BAC-AC)
(4) 人事考課
1||| 偏差分析
2||| トレンド分析
3||| 獲得価値パフォーマンス
4||| プロジェクト管理ソフトウェア
5||| 埋蔵量分析
出力
仕事のパフォーマンス情報
コスト予測
変更要求
プロジェクト管理計画の更新
プロジェクトファイルの更新
組織プロセス資産の更新
プロジェクトの品質管理
一、 プロジェクトの品質管理
品質の定義: 主体の明示的および暗黙的なニーズを満たすエンティティの能力を反映する特性の合計
プロジェクトの品質: プロジェクトを 1 回限りの活動として見ると、プロジェクトの品質は、WBS によって反映されるプロジェクト範囲内のすべてのステージ、サブプロジェクト、およびプロジェクトの作業単位の品質に反映されます。
プロジェクトの品質は、そのパフォーマンスや使用価値に反映されます。
品質管理とその発展の歴史:
品質管理: 品質方針、目標、責任を決定し、品質計画、品質保証、品質管理、品質システムの品質改善を通じてすべての管理機能を実現するすべての活動を指します。
品質管理開発の歴史:
職人の時代 20世紀以前
品質検査の段階:20世紀初頭
統計的品質管理段階: 1024
総合的品質管理段階:1960年代
二、 品質管理を計画する
入力
1||| プロジェクト管理計画
a. スコープベースライン
b. 進行状況のベースライン
c. 原価ベース
d. その他の経営計画
2||| 利害関係者登録簿
3||| リスクレジスター
4||| 要件文書
5||| 事業環境要因
6||| 組織プロセス資産
ツールとテクニック
1||| 費用便益分析
2||| 品質コスト
3||| 7 つの重要な品質ツール
(1) 因果関係図
(2) フローチャート
(3) チェックリスト
(4) パレート図
(5) ヒストグラム
(6) 管理図
(7) 散布図
4||| 標準ドライコントロール
5||| 実験計画
6||| 統計的サンプリング
7||| その他の品質管理ツール
(1) ブレーンストーミング
(2) 力場図
(3) 名目上のグループ手法
8||| ミーティング
出力
1||| 品質管理計画
2||| プロセス改善計画
(1) プロセス境界
(2) プロセス構成
(3) プロセス測定インジケーター
(4) プロセス改善の目標
3||| 品質対策
4||| 品質チェックリスト
5||| プロジェクトファイルの更新
利害関係者登録簿
責任割り当てマトリックス
WBSとWBS辞典
三、 品質保証の実施
入力
品質管理計画
プロセス改善計画
品質対策
品質管理測定結果
プロジェクトファイル
ツールとテクニック
品質監査
目標
(1) 実装されているすべての優れたベストプラクティスを特定する
(2) すべての不規則性、ギャップ、欠陥を特定する
(3) 組織や業界の同様のプロジェクトからの優れた実践例を共有する
(4) チームの生産性を高めるために、プロセスの実行を改善するための支援を積極的かつ積極的に提供します。
(5) 各監査が組織の教訓の蓄積に貢献する必要があることを強調する
品質管理および制御ツール
(1) 親和性図
(2) プロセス意思決定図
(3) 関連図
(4) 樹形図
(5) 優先順位マトリックス
(6) アクティビティネットワーク図
(7) マトリックス図
プロセス分析
出力
変更要求
プロジェクト管理計画の更新には以下が含まれます
品質管理計画
スコープ管理計画
進捗管理計画
コスト管理計画
プロジェクトファイルのアップデートが含まれています
品質監査報告書
研修プログラム
プロセスの文書化
組織プロセス資産の更新
四、 品質管理
入力
1. プロジェクト管理計画
2. 品質対策
3. 品質チェックリスト
4. 仕事のパフォーマンスデータ
(1) 実際の技術的パフォーマンス
(2) 実際のスケジュールパフォーマンス
(3) 実際のコストパフォーマンス
5. 承認された変更リクエスト
6. 成果物
7. プロジェクトファイル
(1) プロトコル
(2) 品質監査レポートと変更ログ
(3) 研修講義と効果評価
(4) プロセス文書 (7 つの基本的な品質ツールや品質管理および制御ツールを使用して生成された文書など)
8. 組織プロセス資産
ツールとテクニック
1. 7 つの重要な品質ツール
2. 統計的サンプリング
3. 診る
4. 承認された変更リクエストを確認する
出力
1. 品質管理測定結果
2. 確認された変更点
3. 検証された成果物
4. 仕事のパフォーマンス情報
5. 変更要求
6. プロジェクト管理計画の更新
品質管理計画
プロセス改善計画
7. プロジェクトファイルの更新
(1) 品質基準
(2) プロトコル
(3) 品質監査レポートと変更ログ
(4) 研修講義と効果評価
(5) プロセス文書 (7 つの基本的な品質ツールや品質管理および制御ツールを使用して生成された文書など)
8. 組織プロセス資産の更新
完了したチェックリスト
教訓ドキュメント
プロジェクト人事管理
一、 プロジェクトの人的資源管理とプロセス定義
プロジェクト人材管理には、人材管理計画の作成、プロジェクトチームの設立、プロジェクトチームの構築、プロジェクトチームの管理などのさまざまなプロセスが含まれます。
プロジェクト管理チームは、計画、実装、管理、終了などのプロジェクト管理活動を担当するプロジェクト チームのサブセットです。
このサブセットは、プロジェクト管理チーム、コア チーム、実行チーム、またはリーダーシップ チームと呼ばれることもあります。
プロジェクト管理チームの管理とリーダーシップのコンテンツ
プロジェクトチームに影響を与える
職業倫理を強化し、職業上の行動を標準化する
プロジェクトの人的資源管理のプロセス:
(1) プロジェクトの人的資源管理計画の作成
(2) プロジェクトチームを構築する
(3) 建設プロジェクトチーム
(4) プロジェクトチームを管理する
人材の制約に対処するためにプロジェクト チームを管理するには、次のスキルも必要です。
(1) リーダーシップ、コミュニケーション、交渉、相談、その他の管理スキル
(2) 委任、モチベーション、コーチング、説得、および個人関係に関連するその他のスキル
(3) チームビルディング、紛争解決、およびチーム関係に関連するその他のスキル
(4) 業績評価、採用、定着、労使関係、安全衛生規則、その他人的資源の管理に関連するスキル
プロジェクトの人的資源管理に関する概念
(1) モチベーション
(2) 組織図
(3) 責任
(4) 専門知識
(5) スタッフのパフォーマンス
二、 プロジェクトの人的資源管理計画の作成
入力
プロジェクト管理計画
アクティビティのリソース要件
事業環境要因
(1) 組織、文化、構造
(2) 既存の人事および人事方針
(3) 後日保証
(4) 人事管理方針
(5) 市況
(6) 対人的および政治的要因
組織プロセス資産
ツールとテクニック
組織図と職務内容
階層図
作業分解図
組織内訳構造
リソースの内訳構造
マトリックス図
ファイル形式
プロジェクト計画のその他の部分
対人コミュニケーション
組織論
専門家の判断
ミーティング
出力
プロジェクト人材管理計画
役割と責任の割り当て
役割
権限
責任
能力
プロジェクト組織図
人員配置管理計画
募集
リソースカレンダー
退職計画
トレーニングのニーズ
表彰と受賞
遵守すべき規制
安全性
三、 プロジェクトチームの組織構築
プロジェクトチームを構築する
入力
プロジェクト人材管理計画
事業環境要因
組織プロセス資産
ツールとテクニック
事前に割り当てられた
交渉
リクルート
仮想チーム
多次元の意思決定分析
出力
プロジェクト人員配置表
リソースカレンダー
プロジェクト管理計画の更新の可能性
プロジェクトチームの構築
1. プロジェクトチーム構築の主な目標
(1) プロジェクト チーム メンバーの個人スキルを向上させ、コストを削減し、スケジュールを短縮し、品質を向上させ、パフォーマンスを向上させながら、プロジェクト活動を完了する能力を強化します。
(2) プロジェクト チームのメンバー間の信頼と団結を向上させ、士気を向上させ、対立を減らし、チームワークを促進します
(3) ダイナミックで協力的なチーム文化を生み出す
2. 成功するプロジェクトチームの特徴
(1) チームの目標は明確であり、メンバーは目標に対する自分の仕事の貢献を理解しています。
(2) チームには明確な組織構造と明確なポジションがある
(3) 文書化された、または慣例的な作業プロセスと方法があり、プロセスが簡潔かつ効果的である
(4) プロジェクトマネージャーはチームメンバーに対して明確な評価・評価基準を持ち、仕事の成果は公平かつオープンで賞罰も明確です。
(5) 共同で開発および遵守される組織規律
(6) 共同作業、つまり、あるメンバーの仕事が他のメンバーの結果に依存しており、要約と学習が得意です。
3. プロジェクトチーム構築の 5 つの段階
(1) 形成段階
(2) ショックステージ
(3) 標準化段階
(4) プレイステージ
(5) 終盤
4. 入力
プロジェクト人材管理計画
プロジェクトスタッフ配置表
リソースカレンダー
5. ツールとテクニック
(1) 対人能力
(2) トレーニング
(3) チームビルディング活動
(4) 基本的なルール
(5) 集中オフィス
(6) 評価と報酬
(7) 強化評価ツール
6. 出力
チームのパフォーマンス評価
事業環境要因に関する最新情報
7. プロジェクトチームのパフォーマンス評価の指標
1||| スキルの向上
2||| 能力と感情の向上
3||| チームメンバーの離職率が低い
4||| チームの結束力を高める
四、 プロジェクトチームの管理
入力
(1) プロジェクト人材管理計画
(2) プロジェクトスタッフ配置表
(3) チームのパフォーマンス評価
(4) 問題ログ
(5) パフォーマンスレポート
(6) 組織文化と組織プロセス資産
1||| お礼状、お祝い宴会
2||| ニュースレター、掲示板、その他のプロジェクトに関するニュースレポート
3||| Webサイト
4||| ボーナス構造
5||| スタッフの服装
6||| その他の組織手当
ツールとテクニック
観察して話す
プロジェクトのパフォーマンス評価
競合管理
対人管理
出力
変更要求
プロジェクト管理計画を更新しました
プロジェクトファイルの更新
事業環境要因に関する最新情報
組織プロセス資産の更新
競合管理
1. 対立を認識する
(1) 紛争を順番に並べ替える
1||| コンセプト段階
2||| 計画段階
3||| 実行フェーズ
4||| 終盤
(2) 特徴
1||| 紛争は自然なものであり、解決策を見つけなければなりません
2||| 対立はチームの問題であり、誰かの個人的な問題ではない
3||| 対立はオープンに処理されるべきである
4||| 紛争解決では個人攻撃ではなく問題に焦点を当てるべきです
5||| 紛争解決は過去ではなく現在に焦点を当てるべきです
2. 紛争の原因
(1) プロジェクトのプレッシャーのかかる環境
(2) 責任の曖昧さ
(3) 上司は複数人いる
(4) 新技術の活用
3. 競合解決について
(1) 紛争解決に影響を与える要因
1||| 紛争の重要性と激しさ
2||| 紛争を解決するための時間的プレッシャー
3||| 紛争当事者の所在地
4||| 長期または短期の紛争解決に基づく動機
(2) 紛争解決
1||| 問題が解決しました
2||| 協力する
3||| 力
4||| 妥協
5||| 相違点を保持しながら共通点を探す
6||| 退却
プロジェクトのコミュニケーション管理と関係者管理
一、 コミュニケーションの概念と定義
人々がお互いにコミュニケーションをとるためのツール
コミュニケーションとは、人々が情報を共有し、考えや感情を表現するプロセスであり、情報の生成、送信、受信、理解、確認が含まれます。
通信方法は次の要素に基づいて選択されます。
(1) 情報を把握する能力
(2) 他の人の意見やアイデアを聞く必要がありますか?
(3) 情報コンテンツを制御する必要がありますか?
通信チャネル選択の要素
1. 情報そのものの特徴
2. 参加者の好み
3. コミュニケーションの目的
4. 参加の習熟度および理解度
通信オプションの寸法
1. 即時性の次元
高度なインタラクティブ性
媒体相互作用
低レベルの相互作用
2. 表現の次元
(1) 言葉
1||| アドバンテージ
永続的に保存でき、簡単にクエリできます
時間を節約し、言語速度よりも読む速度が速くなります。
地理的な場所の要件なし
より正確かつ正確に
理論的には、損失することなく複数回コピーして伝播することができます。
2||| 欠点がある
純粋なテキスト資料では多くの非言語記号が失われるため、感情の伝達には役立ちません。
読者の選択をコントロールできない
いつ読み取られるかは制御できません
(2) 言語
1||| アドバンテージ
感情を伝えることができる
リージョンを越えて同時に通信可能
電子メールよりも速い
必須ではありません メッセージを配信するための優先チャネルを保存します
2||| 欠点がある
個人的な関係を築くのに役立たない(対面と比較して)
ボディランゲージを表現できない
文書の正確性や正確性が達成できず、詳細を把握する能力が不十分である
スピーキングは読むよりも比較的遅い
(3) ミックス
1||| アドバンテージ
2||| 欠点がある
3. 適切な条件がなければなりません
時間
場所
ネットワークの状態
ソフトウェアの条件
関連情報を保持する必要がある場合は、ビデオ録画や会議議事録などの追加作業を行う必要があります。
コミュニケーションチャネルとその特徴
(1) 紙の書類
(2) ウェブページ
(3) Eメール
(4) ブログ
(5) ウィキ
(6) ショートメッセージ
(7) インスタントメッセージング
(8) ボイスメール
(9) ポッドキャスト
(10) 電話
(11) 電話会議
(12) スピーチとカンファレンス
(13) 生放送
(14) 対面での会話
(15) 対面相談参加型ミーティング
(16) ビデオ会議
コミュニケーションスキルの内容
(1) アクティブリスニング
(2) さまざまな手段を効果的に活用して、情報内容をできるだけ理解できるようにする
(3) 複数のツールを効果的に活用してチームのコミュニケーションスキルを強化する
(4) 質問を避けず、真実を理解しようと努めてください
(5) コミュニケーション目標を設定し、コミュニケーション目標が達成されたかどうかを判断するために必要な追跡および検証方法を講じます。
(6) 複数の当事者の利益を最大限に満たせるよう、マルチレベルのコミュニケーションおよび交渉スキルを備えている
(7) 強いカリスマ性と信頼性は、他の人が自信を築くのに役立ちます
(8) 優れた表現スキルは、他の人の士気を高め、チームの実行能力を高めるのに役立ちます
二、 コミュニケーション管理計画を策定する
入力
プロジェクト管理計画
戸籍の開設
主なコミュニケーション対象
主要な影響力のある人
二次通信オブジェクト
事業環境要因
組織プロセス資産
ツールとテクニック
1. コミュニケーションのニーズを分析する
(1) 組織図
(2) 組織とそのステークホルダー間の責任
(3) プロジェクトに関与する専門分野、学部、専攻
(4) プロジェクトに関与する人の数と場所
(5) 内部情報のニーズ
(6) 外部情報のニーズ
(7) ステークホルダーの情報とコミュニケーションのニーズ
2. 通信技術
3. コミュニケーションモデル
4. 通信方法
(1) インタラクティブコミュニケーション
(2) プッシュコミュニケーション
(3) プルコミュニケーション
5. ミーティング
出力
プロジェクトコミュニケーション管理計画
プロジェクトファイルの更新
三、 経営コミュニケーション
入力
プロジェクトコミュニケーション管理計画
仕事のパフォーマンスレポート
事業環境要因
組織プロセス資産
ツールとテクニック
通信技術
コミュニケーションモデル
通信方法
情報管理システム
パフォーマンスレポート
出力
プロジェクトコミュニケーション
プロジェクト管理計画を更新しました
プロジェクトファイルの更新
組織プロセス資産の更新
(1) 関係者への通知
(2) プロジェクトレポート
(3) プロジェクトプレゼンテーション資料
(4) プロジェクトログ
(5) フィードバック情報
(6) 教訓文書
四、 制御通信
入力
プロジェクト管理計画
プロジェクトコミュニケーション
問題ログ
仕事のパフォーマンスデータ
組織プロセス資産
ツールとテクニック
情報管理システム
専門家の判断
ミーティング
プロジェクトの定例会議
プロジェクトキックオフミーティング
プロジェクト概要会議
出力
仕事のパフォーマンス情報
変更要求
プロジェクト管理計画を更新しました
他のプロジェクト ファイルを更新しました
組織プロセス資産の更新
五、 プロジェクト関係者の管理
詳細
1. 利害関係者の特定
2. プロジェクトの利害関係者管理計画を作成する
3. 利害関係者の関与を管理する
4. プロジェクト関係者の参加状況のモニタリング
典型的な利害関係者
1. クライアント
2. ユーザー
3. 上級リーダーシップ
4. プロジェクトチーム
5. 社会人
6. 他の
サポーター
対戦相手
利害関係者の特定
入力
プロジェクト計画書
調達書類
事業環境要因
組織プロセス資産
ツールとテクニック
関連する会議を開催する
専門家の判断
ステークホルダー分析
出力
利害関係者登録簿
プロジェクトの利害関係者管理計画を作成する
入力
プロジェクト管理計画
利害関係者登録簿
事業環境要因
組織プロセス資産
ツールとテクニック
関連する会議を開催する
専門家の判断
分析能力
出力
ステークホルダー管理計画
プロジェクトファイルの更新
経営陣のステークホルダーの関与
入力
ステークホルダー管理計画
コミュニケーション管理計画
変更ログ
組織プロセス資産
ツールとテクニック
通信方法
対人能力
管理能力
出力
問題ログ
変更要求
プロジェクト管理計画の更新
プロジェクトファイルの更新
組織プロセス資産の更新
利害関係者の関与を制御する
入力
プロジェクト管理計画
問題ログ
仕事のパフォーマンスデータ
プロジェクトファイル
ツールとテクニック
情報管理システム
専門家の判断
ミーティング
出力
仕事のパフォーマンス情報
変更要求
プロジェクト管理計画の更新
プロジェクトファイルの更新
組織プロセス資産の更新
プロジェクト契約管理
一、 プロジェクト契約
契約の法的特徴
1. 契約は民事法行為です
2. 契約は二者以上の当事者間の民事法行為です
3. 契約の目的は、当事者間の財産公民権および義務を確立、変更、または終了することです。
4. 契約の締結および履行の際には、関連する法律および行政規制を遵守しなければなりません。
5. 契約は法律に従って成立する、つまり法的拘束力がある
効果的な契約原則
1. 契約に署名する当事者は、相応の公民権能力および民事産業能力を有するものとします。
2. 意味は真実を意味する
3. 法律や社会公益に違反しないもの
無効な契約状況
1. 一方の当事者が詐欺または強要によって契約を締結した場合
2. 国、集団または第三者の利益を害するための悪意のある共謀
3. 違法な目的を隠すために合法的な形式を使用する
4. 社会的および公共的利益への損害
5. 法律および行政法規の強制規定に違反すること
二、 契約区分
情報システム工学プロジェクト別分類
1. 情報システムスコープ部門
(1) 一般契約
(2) 単一プロジェクト契約
(3) 下請
2. プロジェクトの支払い方法別
(1) 一括契約
定額契約
(2) 費用償還契約
このタイプの契約では、雇用主は、仕事を完了するために発生したすべての法定実費に加えて、事前に合意された特定の方法で売り手の利益として手数料を請負業者に支払います。
早急な作業が必要なプロジェクト
事業内容や技術的・経済的指標が未定の事業
危険なプロジェクト
(3) 仕事と資材の契約
費用補償契約と一括契約の特徴を組み合わせたハイブリッド契約
三、 契約書にサインする
プロジェクト契約の内容
1. 当事者のそれぞれの権利と義務
2. 事業費・プロジェクト費用の支払い方法
(1) 支払条件
(2) 決済・支払方法
(3) 支払いを拒否する条件 契約者は、支払いの一部または全額を拒否する権利を有します。
3. プロジェクト変更契約書
4. 契約違反に対する責任
(1) パフォーマンスを続ける
(2) 是正措置を講じます(品質が契約を満たしていない場合は、修理、交換、やり直し、返品、減額または補償を求めることができます)
(3) 補償
(4) 合意された清算損害金または保証金を支払う
工事契約時の注意点
1. 当事者の法的資格
2. 品質の合格基準
3. 受付時間
4. テクノロジー決済サービス
5. 損害賠償の罰金
6. 秘密保持契約
7. 契約書の添付
8. 法的公証
プロジェクト契約の交渉と署名
1. 交渉の見方
2. 交渉プロセス
交渉の6段階
(1) 準備段階
1||| 広範囲にわたる情報を調査して収集する
2||| 交渉の目標を設定する
3||| 交渉時間と場所を選択する
4||| 交渉チームを結成する
5||| 交渉計画を立てる
(2) 探索の初期段階
(3) 見積段階
1||| お見積りフォーム
2||| 引用の原則
3||| 見積もりの開始点を決定する
4||| 見積方法
(4) 相談段階
1||| 相手の見積書の根拠を理解する
2||| 相談しながら交渉する
3||| 交渉におけるカウンターオファー
(5) トランザクション段階
(6) 承認段階
3. 契約当事者間の契約を一貫して理解することに優れている
(1) 国家または業界標準の契約書を使用する
(2) 不完全または曖昧な条件によって引き起こされる契約紛争を回避するために、システム インテグレーターは建設部門が作成した契約条件を慎重に検討する必要があります。
4. 契約内容が不明確な場合の対処が得意
四、 プロジェクト契約管理
契約管理の主な内容
1. 契約締結管理
(1) 契約前の事前調査
1||| 市場調査を行う必要がある
2||| 相手の真意を正確に把握し、競争の激しさを正しく判断するために、潜在的なパートナーや競合企業の信用調査を実施する必要があります。
3||| 関係環境を理解し、リスク分析を正しく判断する
(2) 契約交渉・契約締結(注意事項)
1||| 現実的な交渉目標を設定する
2||| 本当の問題を把握するには、
3||| 平等に相談できる雰囲気を作り出す
2. 契約履行管理
(1) 契約の執行
(2) 契約紛争の解決
3. 契約変更管理(プロセス)
(1) 変更の提案
(2) 変更リクエストのレビュー
(3) 変更の承認
(4) 変更の実施
4. 契約ファイル管理
五、 プロジェクト契約のクレーム処理
1. 請求の種類
(1) 請求目的による分類:時限請求と費用請求に分けられます
(2) 請求の根拠による分類:契約に定められた債権と契約に定めのない債権に分けられます。
(3) クレームのビジネス上の性質に応じた分類: 技術クレームと商業クレームに分けられます。
(4) 請求の処理方法によって分類: 個別の請求と合計請求に分けることができます
2. 請求の条件と根拠
(1) 契約上の請求の成立条件
(2) 契約上の請求の根拠
1||| 契約法などの関連国内法、行政法規、地方条例など
2||| 情報システムエンジニアリングに関連する国、部門、地方の標準、仕様、および文書
3||| 本プロジェクトの実施契約書類(入札書類、契約書、添付書類など)
4||| 通信文書、ビザおよび変更通知、会議議事録、スケジュール、製品購入などの関連文書。
5||| 市場記録やさまざまな会議の会計資料などのその他の関連文書
3. クレームの処理
(1) 請求手続き
1||| 請求を提出する
2||| 請求情報を送信する
3||| 監理技術者の返答
4||| 請求の承認
5||| 継続請求について
(2) 請求の審査
(3) クレーム処理の原則
1||| 請求は契約に基づいていなければなりません
2||| データの蓄積には注意が必要
3||| クレームを迅速かつ合理的に処理する
4||| 請求の精度を高める
4. 契約違反の管理
(1) 建設部門による契約違反の管理
(2) 建設部門による契約違反の管理
(3) 他のタイプのデフォルトの管理