ベスト プラクティス: 提出資料パッケージ - はじめに
注
このページでは、提出資料パッケージの使用で推奨されるベスト プラクティスを説明します。プロジェクトの提出資料ツールに関するチュートリアルや動画などを表示するには、こちらをクリックしてください。はじめに
提出資料の作成と送付を始める前に、プロジェクト内で提出資料を整理する方法を理解しておくと、後々問題に直面することがかなり少なくなります。設計チームにとって最適に機能することを考えるだけでなく、現場チームを考慮に入れることも忘れないでください。現場チームはこの段階では十分に考慮されないことがよくありますが、その結果、後になって承認済み文書を探すのに苦労することになりかねません。さらに、設計チームと自分との間で提出資料番号に相違がある可能性があるため、特定の提出資料がすでに承認のために送信された後は、提出資料整理プランを変更することが非常に難しくなります。
文書のパッケージングと承認に関する問題
提出資料とは通常、プロジェクトで (建機、資材などを) 使用するための許可を得るために請負業者が設計チームに提出する文書のことを指します。これまで、建築の専門家の大半は、提出資料パッケージを、表紙とすべての提出資料案件を含む１つの PDF として考えてきました。このようなパッケージが設計チームに送信されると、設計チームは個々の案件についてコメントを出すこともありますが、通常はパッケージ全体について「承認」または「修正して再提出」などの１つの回答を提供します。承認がパッケージ全体に関わると、会社の提出資料の改訂処理によっては問題が生じる可能性があります。
オプション１: パッケージの改訂の際に、否認された案件のみを再提出する
上の画像にあるように、元の提出資料パッケージは一部しか承認されず、否認された案件は後の改訂で承認される予定です。通常、これが最も手っ取り早いので、最も一般的な改訂方法です。しかし、この例で示されているように、同じ提出資料パッケージに関連する承認済み文書に３つのバージョンが存在します。このため現場チームは、たった１つのデータを探して複数の提出資料改訂版に目を通さなければならず、時間の浪費を余儀なくされます。加えて、案件が提出資料登録に個別に掲載されていないため、案件が容易に失われたり忘れられたりします。
オプション２: パッケージ改訂で、パッケージ全体を再度提出する
オプション１ほど一般的ではありませんが、文書管理の観点からはこの方法が最良の方法です。しかし、この方法では、すでに承認済みの案件に遅延が生じ、設計チームがほとんど同じレビューに時間を浪費する可能性があります。さらに、レビューアは最新の改訂版にある承認済み案件にあまり注意を払わない傾向にあるため、改訂版の間で「承認済み」案件が変わってしまう可能性があります。
先のオプションと同様に、案件が個別にリストされていないため、パッケージの改訂の間に、特に以前に承認された案件がその後変更された場合に、簡単に案件が失われる可能性があります。さらに、現場スタッフは特定のデータを探していたとしても、かなり大量の文書に目を通さなければなりません。
これらの提出資料文書の改訂オプションは、いずれもデジタル ファイルが一般的になる前の、提出資料の管理がまだ紙で行われていた、はるか以前に作られたものです。どちらのオプションも、プロジェクトチーム全体にデータへのアクセスを提供する最適な方法ではありません。そこで、Procore はパッケージのために新たな概念を開発しました。
Procore の提出資料パッケージ
Procore では、パッケージ全体ではなく、提出資料パッケージ内の個々の案件に独自のワークフローと承認があります。Procore において、個々の案件は、前述のよく知られたパッケージに近いものであるのに対し、提出資料パッケージは関連項目の柔軟なグループに似ています。
Procore で提出資料パッケージを使用する場合の主な違いは、再提出がどのように管理されるかです。Procore ではパッケージの再提出の際に、否認された案件だけが再提出され、すべての案件が同じパッケージに残っているので、複数のバージョンの文書に目を通す必要がなくなります。Procore は、パッケージ内の提出資料案件の最新バージョンを表示します。
これが少し馴染みがないように感じる場合、設計チームが以前の提出資料とは別に保持したい場合 (下の例)、改訂版を別のパッケージに移動することもできます (パッケージ改訂版として機能します)。しかし、このオプションを使用することはお勧めしません。なぜなら、案件の承認を探すために多くのパッケージを調べなければならない現場スタッフにとっては、非効率となり得るからです。
Procore の独自の提出資料パッケージの概念は、プロジェクトチーム、特に現場スタッフが経験する文書管理の困難の多くに対処します。
- 重要な提出資料が見落とされる可能性を最小限にするため、案件は別々に記載することが強く推奨されます。
- 個々の案件を整理することで、関連付けられたパッケージとの関連性を保ちながら、いつでも特定の提出資料を迅速に処理することができます。
- 個々の案件は何度でも改訂できますが、どの時点でも最新バージョンだけが表示されます。その結果、プロジェクトチームが以前のバージョンを参照するリスクが軽減されます。
- 案件が個別に記載されていれば、現場スタッフは、さまざまなパッケージや複数の案件が記載された大きな PDF を検索する時間が短縮されます。
Procore では、提出資料パッケージはどのように整理するべきですか?
ほとんどの請負業者は、パッケージの整理に次の３つのオプションのうちの１つを使用しています: 専門分野/請負業者 (有責)、仕様区分、または仕様セクション。仕様区分または専門分野/請負業者 (有責) 別のパッケージは、広範囲になりすぎ、巨大なパッケージとなり、取り扱いが難しくなる可能性があるため、仕様セクション別にパッケージを整理することをお勧めしています。また、仕様セクションごとにパッケージ化されたものは、通常、作業しやすく、似たような作業範囲に関する複数の専門分野に適応しやすいです。
例１: 仕様区分別パッケージ
| No. 23 機械パッケージ | |||||
|---|---|---|---|---|---|
| 仕様セクション | 提出資料 No. | 改訂版 No. | タイトル | 種類 | ステータス |
| 23 21 13 ハイドロニック配管 | 1 | 0 | ハイドロニック配管製品データ | 製品データ | 未着手 |
| 23 21 13 ハイドロニック配管 | 2 | 0 | ハイドロニック ポンプ製品データ | 製品データ | 未着手 |
| 23 23 00 冷媒配管 | 3 | 0 | 冷媒配管製品データ | 製品データ | 未着手 |
| 23 25 00 暖房換気空調水処理 | 4 | 0 | 暖房換気空調水処理製品データ | 製品データ | 未着手 |
| 23 31 13 金属ダクト | 5 | 0 | 金属ダクト製品データ | 製品データ | 未着手 |
例２: 仕様セクション別パッケージ、提出資料種類別結合
| No. 23 暖房換気空調水処理パッケージ | |||||
|---|---|---|---|---|---|
| 仕様セクション | 提出資料 No. | 改訂版 No. | タイトル | 種類 | ステータス |
| 23 25 00 暖房換気空調水処理 | 1 | 0 | バイパス フィーダー製品データ | 製品データ | 未着手 |
| 23 25 00 暖房換気空調水処理 | 2 | 0 | pH コントローラ製品データ | 製品データ | 未着手 |
| 23 25 00 暖房換気空調水処理 | 3 | 0 | インジェクション ポンプ製品データ | 製品データ | 未着手 |
| 23 25 00 暖房換気空調水処理 | 4 | 0 | 遠心分離器製品データ | 製品データ | 未着手 |
| 23 25 00 暖房換気空調水処理 | 5 | 0 | マルチメディア フィルター製品データ | 製品データ | 未着手 |
仕様セクション別にパッケージを整理することを選択した場合でも (例２)、単一のパッケージに複数の請負業者 (有責) が関与する場合が依然として存在する可能性があります。その好例が耐火工事であり、この場合に、各会社が最適な情報を確実に受け取るための方法には２つあります。
- 同じ仕様セクションを使用する請負業者 (有責) ごとに異なるパッケージを作成します。例えば、「機械用耐火パッケージ」と「電気用耐火パッケージ」を作ります
- 請負業者 (有責) ごとに、同じパッケージに別の提出資料案件を作成し、各案件を個別に処理します。例えば「耐火パッケージ」を作成し、その中に提出資料として「防火製品データ - 電気」と「防火製品データ - 機械」を入れます。