ベスト プラクティス: 提出資料

はじめに

チームが提出資料の作成を始める前に、会社レベルの設定がすべて完了していることを確認してください。これは、後で問題ややり直しが発生するのを防ぐのに役立ちます。準備はよいですか?

カスタム提出資料の種類

Procore の提出資料ツールを使用すると、プロジェクトで承認ワークフローを必要とする可能性のあるあらゆる種類の文書をルーティングできます。提出資料の種類を使用すると、提出資料の個別のカテゴリーを作成して、それらの文書を整理できます。「カスタム提出資料の種類を作成する」を参照してください。プロジェクトチームは、提出資料を種類に基づいてフィルタリングして報告し、必要なデータを簡単に見つけることができます。

カスタム提出資料ステータス

Procore では提出資料に、未着手、終了、草案の３つの既定のステータスを設定しています。提出資料が提出・承認プロセスのどの段階にあるかを正確に示すために、ステータスを追加することもできます。

「未着手」提出資料とは、以下ようなものです:

• 依頼したがまだ受領されていない提出資料
• 受領され、レビュー (内部または外部) 中である提出資料

「終了」提出資料とは、以下ようなものです:

• 例外付き、または無しで承認された提出資料。
• 否認された提出資料、または「修正して再提出」とマークをつけた提出資料

構成可能なフィールドのセット

構成可能なフィールドのセットを使用することで、プロジェクトチームが会社の処理に当てはまるフィールドのみを確認し、入力できるようにします。「新しい構成可能なフィールドのセットを作成する」を参照してください。

カスタム フィールド

会社やプロジェクトに固有のデータは、カスタム フィールドを使用してチームが収集することができます。「新しいカスタム フィールドを作成する」を参照してください。

はじめに

提出資料ツールを最大限に活用するには、提出資料を作成する前に、プロジェクトレベルの構成がすべて整っていることを確認する必要があります。この記事では、最も重要な設定のベスト プラクティスについて説明します。準備はよいですか?

仕様セクションごとに提出資料に番号を付ける

この設定により、リンクした仕様セクションで提出資料番号と改訂版に区分番号を付けるオプションが有効になります。この設定を有効にすると、例えば、提出資料の仕様セクション フィールドで仕様セクション No. 03 30 00 と特定されている場合、提出資料番号 (No. 007 など) と改訂版番号 (No. 01 など) が No. 03 30 00-007.01 のようにフォーマットされます。この設定が有効でない場合、提出資料番号と改訂版番号は No. 007.01 のようにフォーマットされます。

さらに、この設定を有効にすると、各仕様セクションの提出資料には、他の仕様セクションの提出資料とは無関係な連続番号が付けられます。例:

• 仕様セクション: 03 30 00
  • No. 03 30 00-001: コンクリート混合設計
  • No. 03 30 00-002: 製品データ
  • No. 03 30 00-003: エキスパンション・ジョイント レイアウト
• 仕様セクション: 07 45 00
  • No. 07 45 00-001: 製品データ
  • No. 07 45 00-002: サンプル

動的期日

動的期日はオプションですが、固定期日の代わりにワークフロー ステップ期間を規定するのに推奨される構成です。これにより、各ワークフローのステップと役割が、それぞれの提出資料案件をレビューして回答するために契約で割り当てられた時間を確保することが保証されます。ワークフロー ステップが終了すると、次のステップの期日が自動的に先に (前のステップが遅れた場合) または前に (前のステップが早かった場合) 調整され、規定した期間が常に守られるようになります。ワークフロー ステップが期日までに回答しない場合には、期限超過のルールも適用されます。「動的承認者期日とは何ですか?」を参照してください。

提出資料スケジュール計算

提出資料スケジュール計算はオプションですが、提出資料案件に関連するマイルストーンの日付を表示する強く推奨される機能です。これらのフィールドには以下が含まれます:

• 現場での利用開始期日: 提出資料が現場で設置または使用される日付のユーザー データ フィールド。
• リードタイム: 提出資料の処理、製造、および発送に必要な暦日数を示すユーザー データ フィールド。
• 設計チームのレビューの時間: 提出資料のレビューと承認のために外部チームに割り当てられた暦日数を示すユーザー データ フィールド。
• 内部レビュー時間: 提出資料のレビューのために内部チームに割り当てられた暦日数を示すユーザー データ フィールド。
• 返送予定日: 現場での利用開始期日マイルストーンに間に合うように外部レビューアからの承認済み提出資料が必要になるマイルストーン日付を表示する、システムが作成するフィールド。「ドロップ デッド日付」とも呼ばれます。
  • これを決定するために使用される計算式は次の通りです: 現場での利用開始期日 - リードタイム
• 内部レビュー完了予定日: 現場での利用開始期日マイルストーンに間に合うように内部レビューアからのレビュー済み提出資料が必要になるマイルストーン日付を表示する、システムが作成するフィールド。
  • これを決定するために使用される計算式は次の通りです: 現場での利用開始期日 - リードタイム - 設計チームのレビュー時間
• 提出期限予定日: 現場での利用開始期日マイルストーンに間に合うように提出者から提出資料が提出される必要があるマイルストーン日付を表示する、システムが作成するフィールド。
  • これを決定するために使用される計算式は次の通りです: 現場での利用開始期日 - リードタイム - 設計チームのレビュー時間 - 内部レビュー時間

これらのフィールドは、現場での利用開始期日、リードタイム、および割り当てられたレビュー時間に基づいて、ワークフロー プロセスの各メンバーのために予定期日を逆算する機能をサポートします。この設定により、提出資料の進捗のレポートを作成して、順調に進んでいるかどうかを確認することが容易になります。

「提出資料スケジュール計算」オプションを有効にしたら:

• 初めに、[現場での利用開始期日] フィールドに日付を入れます。
• 次に、[リードタイム] フィールドに日数を入力します。例えば、10 日と入力すると、現場での利用開始期日からリードタイムの 10 日を差し引いた返送予定日が自動的に追加されます。
• [設計チームのレビュー時間] フィールドに入力する日付についても同様です。例えば、７日と入力すると、内部レビュー完了予定日の自動入力を計算するために、システムは返却予定日から７日を差し引きます。
• 最後に、[内部レビュー時間] フィールドに日数を入力します。例えば、５日と入力すると、内部レビュー時間の日付から５日を差し引いて提出期限予定日を自動的に計算します。

ワークフローの拒否を有効にする

この設定を強くおすすめします。有効にすると、ワークフロー承認者からの「拒否」または「修正して再提出」の提出資料への回答によって、アクション待ちの責任が提出資料管理者に自動的にルーティングされ、次のステップが決定されます。

• 提出資料管理者には、「拒否」または「修正して再提出」の回答により、アクション待ちのユーザーになったことが電子メールで通知されます。アクション待ちが提出資料管理者にルーティングされると、提出資料管理者は次のことを選択できます:
  • 提出資料を閉じ、必要に応じて修正を作成します。
  • アクション待ちをワークフローの前のステップに戻します。
  • ワークフローを再開します。
    • ワークフローが再開されると、中断したところから再開されます。例:
      • 他の承認者がいないステップで「拒否」または「修正して再提出」の回答が入力された場合、ワークフローは次のステップに進みます。次のステップがない場合、ワークフローは完了します。
      • まだ回答していない必須の承認者がさらにいるステップで「拒否」または「修正して再提出」の回答が入力された場合、ワークフローは同じステップで再開され、他の必須の承認者が回答できるようになります。

提出資料の電子メール

これらの設定は、特定の提出資料アクションから発生する電子メール通知にコピーされる提出資料の役割を制御します。 送信される通知の数は、これらの通知を設定することにより、必要に応じて変更できます。 「提出資料が作成または更新されたときに電子メールを受け取るのは誰ですか?」を参照してください。

提出者、承認者、およびレビューアの役割の定義

提出資料案件で担当者がしなければならない特定のアクションは、これらの役割によって示されます。その役割とそれぞれの具体的なアクションには次のものがあります:

• 提出者: 提出者の役割は、オプションではあるが推奨されるワークフローの最初のステップとして、必要な文書の提出を担当します。「提出資料」の役割には複数のユーザーに割り当てることができますが、ワークフローでの提出者ステップは１つだけです。
• 承認者: このユーザーは提出資料案件への回答を担当します。回答の選択肢は、プロジェクトの提出資料ツール構成で設定することができます。「カスタム提出資料回答を管理する」を参照してください。
• レビューア: この役割は一般に、承認者の役割に、同じワークフロー ステップに前は含まれていなかった別のユーザーに、レビューのために案件を転送する柔軟性を提供するために使用されます。承認者がこれを行うことができるのは、自分がその案件のアクション待ちになっているときだけです。レビューアは、案件が送信された後、承認者と同様の回答アクションを行うことができます。アクション待ちは、最終回答のために承認者に戻されます。「レビューのために提出資料を転送する」を参照してください。

提出資料のライフサイクルでのこれらの役割の働きをまとめて見るには、「提出資料 - ワークフロー図」を参照してください。

提出資料の回答

レビューアと承認者が使用できる回答は、これらの設定を使用してカスタムできます。例えば、プロジェクトの推奨回答として「承認済み」の代わりに「レビュー済み」を追加できます。それぞれ１つのカスタム回答を可能にする「保留中」と「提出済み」を除き、提出資料管理者は、既定の各回答に対して最大 12 個のカスタム回答を作成できます。提出資料で使用されている場合、カスタム回答を削除することはできません。それらは編集できますが、編集された回答は、編集前の回答が使用されいたすべての場所で、編集前の回答と置き換わることに注意してください。「カスタム提出資料回答を管理する」を参照してください。

ワークフロー テンプレート

チームは、プロジェクト期間中、複数の提出資料で同じワークフローを常に再利用します。複数の提出資料について同じワークフローの手作業での再作成を必要とするのではなく、チームはこれらのワークフローをテンプレートとして定義し、必要に応じて適用できる必要があります。プロジェクト・エンジニアが 10 の別の案件について同じワークフローをビルドする場合、繰り返しのアクションに多くの余計な時間を費やすことになります。この機能を使えば、テンプレートを作成し、必要に応じて再利用することができます。

次のステップ

プロジェクトの提出資料構成が完了したので、提出資料の作成を開始することができます。提出資料登録を作成する最速の方法は、Procore の提出資料ビルダーまたは提出資料インポートを使用することです。これらの方法の使用に関する詳細と推奨については、「ベスト プラクティス: 提出資料ビルダー」および「ベスト プラクティス: 提出資料インポート」を参照してください。

はじめに

提出資料インポートは、プロジェクトの提出資料やパッケージの詳細なデータを含む提出資料レジストリを一括作成する最も効果的な方法です。このガイドでは、提出資料インポートの利用に際して効果を最大にするのに役立つベスト プラクティスを紹介します。準備はよいですか?

インポート テンプレートの使用

まず、Procore Imports アプリケーションから直接、または「提出資料インポート テンプレートをダウンロードする」のサポートサイトから提出資料インポート テンプレートをダウンロードします。

次のステップ

インポートから提出資料レジストリを作成したら、Procore の提出資料パッケージ機能を使用して、多数の提出資料案件に対するワークフローを開始することをお勧めします。「ベスト プラクティス: 提出資料パッケージ - 作成とレビュー」を参照してください。

別の方法として、Procore の一括アクション機能を使用して、リストビューから複数の提出資料案件にワークフローを追加することもできます。「ベスト プラクティス: 提出資料プロジェクトの構成」を参照してください。

はじめに

プロジェクトの仕様書が出版されている場合、Procore の提出資料ビルダーを使用することは、提出資料レジストリを作成する最も迅速な方法の一つでしょう。提出資料ビルダーは、特定の書式に基づいて仕様書内の提出資料を検索し、基本的な提出資料レジストリを作成することができます。このガイドでは、提出資料ビルダーを使用する際のベスト プラクティスを紹介し、可能な限り効率的に作業を行えるようにします。準備はよいですか?

なぜ提出資料ビルダーを利用する必要があるのですか?

プロジェクト開始時に提出資料レジストリを作成することで、重要な提出資料が忘れられるのを防ぐことができます。提出資料ビルダーを使えば、手作業で何週間もかかるようなタスクを、大幅に短い時間と労力でこなすことができます。

提出資料ビルダーの理想的な仕様書フォーマット

提出資料ビルダーが仕様書を処理する際、特定の構成要素を検索します。これらの構成要素がない場合、提出資料案件はほとんど、あるいはまったく検出されません。以下詳細を確認し、仕様書を参照して、これら規則が守られていることを確認してください:

1. OCR 技術は PDF 文書の品質に大きく依存します。したがって、可能な限りベクターベースの PDF を使用することを強くお勧めします。詳しくは「PDF ラスター コンテンツとベクター コンテンツの違いは?」を参照してください。
2. 提出資料ビルダーで検索されるのは、「submittals (提出資料)」という英単語を含むセクションの見出しに記載されている提出資料情報のみです。
3. 「提出資料」サブセクションの中では、個別の提出資料案件として正しく記録されるよう、案件には字下げが必要です。
4. 各案件名については、提出資料ビルダーは、コロン (:) の前の会社の提出資料種類 (既定のまたはカスタムの) に正確に一致するものを探します。正確に一致するものが見つからない場合、提出資料種類として「その他」が既定で選択されます。

提出資料ビルダーからの提出資料案件の作成

提出資料ビルダーのレビュー処理で提出資料を確認する前に、Procore でプロジェクトの提出資料をどのように整理したいかを確認しておく必要があります。Procore の提出資料の整理については、「ベスト プラクティス: 提出資料パッケージ - はじめに」を参照してください。

提出資料ビルダーは、以下のユーザー確認フィールドが入力された提出資料案件を作成します:

• タイトル
  • 注: タイトルには通常、提出資料種類に関するテキストが含まれるので、タイトルを構成して適用する前に「提出資料種類」フィールドが正確であることを確認してください。構成されたタイトルを適用すると、確認待ちの提出資料の既存のタイトルは自動的に更新されます。タイトル設定後に提出資料の「種類」を手動で変更しても、提出資料の「タイトル」は自動更新されません。
• 種類
• 説明
• 提出資料管理者

提出資料ビルダーは、以下のフィールドがあらかじめシステムに入力された提出資料案件を作成します:

• 仕様セクション番号と説明
• ステータス (作成された提出資料はすべて草案ステータスになります。)
• 提出資料番号
  • 注:
    • プロジェクトの「仕様セクション別提出資料番号」設定が有効になっている場合、提出資料には仕様セクション内でそれに従って番号が付けられます。例えば:
      • 06 25 09 - 001
      • 06 25 09 - 002
      • 06 25 09 - 003
    • プロジェクトの「仕様セクション別提出資料番号」設定が無効になっている場合、レビュー済み提出資料のリスト全体は、仕様セクション番号に関係なく、連番で番号付けされます。

次のステップ

提出資料レジストリが前述のフィールドで作成されたので、追加のコンテキストのために更新が必要なフィールドがいくつもあります。提出資料に残りの情報を追加するには、Procore の一括アクション機能を利用して、パッケージ内の複数の提出資料案件を編集することをお勧めします。「パッケージ内の提出資料を一括編集する」を参照してください。パッケージ外の複数の提出資料案件を編集するのにも、Procore の一括アクション機能を使用できます。「提出資料ツールで [一括アクション] > [編集] を使用する」を参照してください。

関連項目

ベスト プラクティス: 提出資料パッケージ - 作成とレビュー

はじめに

提出資料の作成と送付を始める前に、プロジェクト内で提出資料を整理する方法を理解しておくと、後々問題に直面することがかなり少なくなります。設計チームにとって最適に機能することを考えるだけでなく、現場チームを考慮に入れることも忘れないでください。現場チームはこの段階では十分に考慮されないことがよくありますが、その結果、後になって承認済み文書を探すのに苦労することになりかねません。さらに、設計チームと自分との間で提出資料番号に相違がある可能性があるため、特定の提出資料がすでに承認のために送信された後は、提出資料整理プランを変更することが非常に難しくなります。

文書のパッケージングと承認に関する問題

提出資料とは通常、プロジェクトで (建機、資材などを) 使用するための許可を得るために請負業者が設計チームに提出する文書のことを指します。これまで、建築の専門家の大半は、提出資料パッケージを、表紙とすべての提出資料案件を含む１つの PDF として考えてきました。このようなパッケージが設計チームに送信されると、設計チームは個々の案件についてコメントを出すこともありますが、通常はパッケージ全体について「承認」または「修正して再提出」などの１つの回答を提供します。承認がパッケージ全体に関わると、会社の提出資料の改訂処理によっては問題が生じる可能性があります。

Procore の提出資料パッケージ

Procore では、パッケージ全体ではなく、提出資料パッケージ内の個々の案件に独自のワークフローと承認があります。Procore において、個々の案件は、前述のよく知られたパッケージに近いものであるのに対し、提出資料パッケージは関連項目の柔軟なグループに似ています。

Procore で提出資料パッケージを使用する場合の主な違いは、再提出がどのように管理されるかです。Procore ではパッケージの再提出の際に、否認された案件だけが再提出され、すべての案件が同じパッケージに残っているので、複数のバージョンの文書に目を通す必要がなくなります。Procore は、パッケージ内の提出資料案件の最新バージョンを表示します。

これが少し馴染みがないように感じる場合、設計チームが以前の提出資料とは別に保持したい場合 (下の例)、改訂版を別のパッケージに移動することもできます (パッケージ改訂版として機能します)。しかし、このオプションを使用することはお勧めしません。なぜなら、案件の承認を探すために多くのパッケージを調べなければならない現場スタッフにとっては、非効率となり得るからです。

Procore の独自の提出資料パッケージの概念は、プロジェクトチーム、特に現場スタッフが経験する文書管理の困難の多くに対処します。

• 重要な提出資料が見落とされる可能性を最小限にするため、案件は別々に記載することが強く推奨されます。
• 個々の案件を整理することで、関連付けられたパッケージとの関連性を保ちながら、いつでも特定の提出資料を迅速に処理することができます。
• 個々の案件は何度でも改訂できますが、どの時点でも最新バージョンだけが表示されます。その結果、プロジェクトチームが以前のバージョンを参照するリスクが軽減されます。
• 案件が個別に記載されていれば、現場スタッフは、さまざまなパッケージや複数の案件が記載された大きな PDF を検索する時間が短縮されます。

この続きへ

ベスト プラクティス: 提出資料パッケージ - 提出資料の案件分類

関連項目

• ベスト プラクティス: 提出資料パッケージ - 作成とレビュー
• ベスト プラクティス: 提出資料パッケージ - 配信と改訂
• ベスト プラクティス: 会社レベルの提出資料設定

はじめに

提出資料パッケージの整理方法が決まったら、次に、各パッケージ内の提出資料案件の案件分類方法 (通常、提出資料レジストリと呼ばれます) を決めます。提出資料レジストリの設定方法に正解も不正解もありませんが、どのオプションにもメリットとデメリットがあります。

通常、提出資料レジストリは仕様から始まるので、まずはそこから始めましょう。以下は、照明器具提出資料の標準仕様書小項目です:

提出資料レジストリのビルドは、仕様に要求事項として記載されている各案件の個別項目を作成することから始めることをお勧めします。上記の仕様セクションの例には、次の案件があります: 製品データ、施工図、認定データ、製品証明書、現場品質管理レポート、O&M、保証書。

案件分類オプション

この続きへ

ベスト プラクティス: 提出資料パッケージ - 作成とレビュー

関連項目

• ベスト プラクティス: 提出資料パッケージ - はじめに
• ベスト プラクティス: 提出資料パッケージ - 配信と改訂
• ベスト プラクティス: 会社レベルの提出資料設定

はじめに

この記事では、提出資料パッケージを最大限に活用するために推奨される手順を提示します。

ステップ１: 提出資料パッケージと案件を作成する

ステップ２: (オプション) パッケージ内の提出資料案件の番号付けを管理する

提出資料の受送信順序を知ることは困難であるため、提出資料を作成する際には、提出資料番号の一時的なプレースホルダーとして 0 を使用することをお勧めします。パッケージの「編集」ボタンは、提出資料案件を受け取ったらすぐに、ただしレビューのために送信する前にクリックしてください。この編集モードでは、提出資料番号をインラインで編集することができます。提出資料番号がセットされた後、次の段階に進んでパッケージを一括編集してから、レビューのために案件を送信します。

ステップ３: パッケージ内の提出資料案件を一括編集する

早い時期 (例えば、バイアウト前) に提出資料登録が作成されると、提出資料案件に含まれる既知の情報は一般に制限されます。提出資料パッケージの「一括編集」ボタンを使用すると、情報がわかり次第、パッケージ内の複数の提出資料案件に不足しているデータをすばやく追加することができます。同じ画面からワークフローを適用することもできます。パッケージを使用せず、リストビューの一括編集オプションを使用して同じことを行った場合、提出資料のグループごとに２つの別々のステップが必要になります。

ステップ4: ワークフローの対応開始と電子メール通知のダイジェスト化

提出資料パッケージの案件にワークフローが追加されると、ワークフローの最初の受信者に「要対応」電子メールを送信できるようになります。提出資料を１つずつ作成する場合、「作成して電子メールを送信」をクリックすると複数の電子メールが送信されますが、パッケージでは異なる方法を採用し、各ユーザーに送信する電子メールは１通のみです。

パッケージ内の少なくとも１つの提出資料にワークフローが追加された場合、パッケージ表示ページに新しい警告バナーが表示されます。管理者ユーザーは、このバナーを使用して、ワークフローの最初の担当者への１通の「要対応」電子メールを開始することができます。パッケージ機能を使用することで、提出資料の電子メール数を減らすことができるという大きなメリットがあります。

パッケージの全提出資料案件について、同時に電子メールを送信することを推奨しました。いつでもパッケージに案件を追加することができますが、パッケージの警告バナーにある「今すぐ送信」をクリックすると、以前に送信した電子メールも再送信されるため、提出者や承認者が混乱する可能性があります。

ステップ５: 提出者の役割 - パッケージのレビューと回答

「要対応」電子メールは、「今すぐ送信」ボタンをクリックすると、受領者の回答が必要となるすべての提出資料 (この場合は４案件) を受領者に通知します。「Procore でレビュー」リンクをクリックすると、ユーザーは直接 Procore のページに移動し、必要な回答と文書を提出することができます。

下のレビュー ページの例では、Door 請負業者は、４つの案件すべてで「アクション待ち」とされています。このビューでは、ユーザーは１つのページからすべての案件を確認して回答することができ、これはパッケージを活用するもう１つの大きな利点です。各案件の「レビュー」をクリックすると、期日が表示され、ユーザーが回答、コメント、添付書類を入力するフィールドが表示されます。

ワークフローは個々の提出資料案件に含まれているため、パッケージ内の各提出資料の期日が同じである必要はありません。上記の例では、閉鎖保証書の提出資料案件が含まれていますが、その提出期限は何ヶ月も先です。Door 請負業者は、この時点でこの案件を提出する準備ができていない場合、この閉鎖案件によって遅延することなく他の３つの案件を提出することができます。提出するされるまでは、Door 請負業者は保証書の「アクション待ち」としてリストアップされ続けます。また、Door 請負業者には、提出期限までに提出しなかった場合、期限超過の電子メール通知も送信されます。こうすることで、閉鎖の成果物のスケジュールを維持することができます。プロジェクトの設計チームが「完全な」パッケージの受け取りを希望する場合は、閉鎖案件を別のパッケージに簡単に移動できます。

ステップ６: 承認者の役割 - パッケージのレビューと回答

承認者のプロセスは、上記の提出者のプロセスと同様です。レビューが必要なパッケージ内の３つの案件について、承認者は「要対応」電子メールを１通受け取ります。電子メールにある「Procore でレビュー」リンクをたどると、提出者の役割とほぼ同様のレビュー画面が表示されます。唯一の違いは、「回答」ドロップダウンと「前回の回答」セクションで利用できるオプションです。

ここでも、ワークフローは個々の提出資料案件に含まれているため、それぞれ別のユーザーに転送することも、個別に承認することもできます。回答を提出するまでは、提出資料の案件がどのように進もうとも、各ユーザーは「アクション待ち」としてリストアップされたままです。

この続きへ

ベスト プラクティス: 提出資料パッケージ - 配信と改訂

関連項目

• ベスト プラクティス: 提出資料パッケージ - はじめに
• ベスト プラクティス: 提出資料パッケージ - 提出資料の案件分類

はじめに

この最後の提出資料パッケージの記事では、提出資料の終了、作成者への返却、改訂版の作成、その他有用な情報について説明します。

パッケージ配信

提出資料管理者は通常、提出資料ワークフローが終了すると、個々の案件を請負業者 (有責) または提出者に返送します。提出資料案件にはそれぞれワークフローや承認があるため、「提出資料を配信する」で説明したように、すべての提出資料案件は個別の電子メールで配信されます。

パッケージ改訂

配信と同様、提出資料案件は異なるワークフローで個別に承認されるため、パッケージ レベルの改訂版はありません。「ベスト プラクティス: 提出資料パッケージ - はじめに」を再び参照すると、これにより「業界」パッケージで指定した２つのオプションのうち１つを選択する必要がなくなります。再提出が必要な案件だけを処理することで、全体の承認時間が短縮されます。パッケージ内の案件の改訂を管理する方法は他にもありますが、最もよく使われるのはこの２つです:

結論

これらの記事により、Procore の提出資料パッケージ機能の目的と利点がより明確になったことと思います。この機能がすべてのチームやプロジェクトに理想的にマッチするわけではないことは理解していますが、次のプロジェクトで提出資料の整理方法を計画する際には、この結論を念頭に置いてください。

1. パッケージから送信されるワークフロー通知がないと、提出資料パッケージは単なる整理ツールとしてしか使用されない可能性があります。提出資料案件を表示し、グループ化するためのもう一つの方法に過ぎないと考えられます。
2. 提出資料パッケージの活用方法がまだ不明な場合は、幅の広い案件分類を試しに使ってみることをお勧めします。このオプションは、あなたがこれまで案件を扱ってきた方法に近いと思われるかもしれません。自分に合わないと判断すれば、多くの提出資料案件を管理する必要がなくなります。
3. 提出資料パッケージの使用は、あなたのプロジェクトにとって今すぐには最適な選択肢ではないかもしれませんが、その機能は時間とともに進化し、将来、あるいは別のプロジェクトで、よりうまく機能する可能性があります。ぜひニュー リリース ウェビナーに登録し、新リリースの更新情報を入手してください。

関連項目

• ベスト プラクティス: 提出資料パッケージ - はじめに
• ベスト プラクティス: 提出資料パッケージ - 提出資料の案件分類
• ベスト プラクティス: 提出資料パッケージ - 作成とレビュー

はじめに

ワークフロー セクションは、提出資料ツールの通知とアクション待ち追跡のコンポーネントを有効にします。ワークフローは、自動的にワークフローを進め、アクションまたは期限切れ通知を出すという利点を提供します。この記事では、提出資料ワークフローを編集するためのベスト プラクティスについて説明します。準備はよいですか?

[一括アクション] > [ワークフローを適用]

この機能により、管理者ユーザーは、提出資料案件をまとめて選択して、新しいワークフローや作成済みのワークフロー テンプレートを適用することができます。ワークフローをまとめて適用するには、すべての提出資料案件が草案ステータスであり、過去にワークフローが適用されていないことが必要です。提出資料にワークフローを一括追加する２つの方法について以下で説明します。

ユーザーの一括置き換え

プロジェクトへの人の出入りが頻繁にあるため、ワークフロー ユーザーを別のユーザーに簡単に置き換える方法が必要です。多数の提出資料の承認者、提出者、またはレビュー担当者を置き換える必要がある場合は、プロジェクトの提出資料ツールに対して「管理者」レベルの権限を持つユーザーが、提出資料ツールの構成設定でこれを行うことができます。「設定の構成: 提出資料ツール」を参照してください。

ワークフローを拒否し、アクション待ちを前のステップに戻す

多くの場合、管理者は提出資料のアクション待ちを前のワークフロー ステップに戻すことが必要になります。いくつか事例を挙げてみましょう:

• ワークフロー ユーザーが回答への添付書類のアップロードを忘れた、または間違った添付書類をアップロードした
• ワークフロー ユーザーが間違った回答をした
• 提出資料が間違った承認者に渡ってしまった

提出資料管理者はいつでも、アクション待ちを前のステップに戻すことができます。特定の回答に基づいてより自動化されたエクスペリエンスを実現するには、「ワークフローを拒否」設定を有効にすることをおすすめします。「設定の構成: ワークフローの拒否を有効にする」を参照してください。

提出資料の改訂

「改訂版を作成する」機能は、すでにワークフローに入力されたデータを除外し、元の案件情報の (改訂版番号のついた) コピーを作成します。ワークフローのステップは複製されますが、提出者の役割から新しい提出資料を要求するために、ステップ１から再スタートします。この機能により、過去のすべてのデータが元の提出資料案件の中に残ることを保証しながら、新しいデータを改訂版に追加することができます。