依頼から実行予算までのワークフロー

Darwinでの仕事の流れは次のとおりです。

依頼 → 明確化 → 見積 → レビュー → 承認 → 記録 → 学習

これが、プラットフォームを理解するいちばん簡単な方法です。Darwinは、チームの見積づくりを助けるだけでなく、依頼がどう見積になり、見積がどう実行予算になり、実際のプロジェクトの原価がどう今後の仕事を良くするかを管理します。

1. 依頼

仕事は、誰かが何かの見積、明確化、変更、価格付け、レビュー、承認を求めたときに始まります。

Darwinでは、この目的を 作業依頼 として記録します。

良い依頼には、次の内容が含まれます。

求める成果
工事範囲の情報
あれば、ファイルや図面
依頼者と担当者
コメントや、まだ答えの出ていない質問

2. 明確化

建設の仕事が、完璧な情報とともに始まることはめったにありません。

明確化の段階で、チームは次のものを加えます。

図面
工事範囲のメモ
発注者の期待
数量の前提条件
コメント
添付ファイル

目的は、構造化された見積の作業になる前に、依頼を対応できる状態にすることです。

3. プロジェクトと見積を作成する

作業依頼が明確になると、Darwinは依頼の情報からプロジェクトを自動で作成できます。積算担当者は、そのプロジェクトの背景を、構造化された見積に落とし込みます。

作成されたプロジェクトには、工事範囲の情報、ファイル、コメント、依頼者、担当者、アクティビティの履歴など、依頼を対応できる状態にした内容が、仕事の出発点として残ります。

ここでDarwinは、次のものをまとめます。

モジュール（歩掛にもとづく単価内訳）
材料
労務
経費
単価の背景
IFC/BIMや2DのQTOによる数量の入力
必要に応じて、手入力の数量

見積は単なる数字ではなく、背景を伴った構造化された原価の考え方です。

4. レビュー

確定する前に、見積は検証されるべきです。

レビューには、次のものが含まれます。

価格確認
数量の確認
前提条件の確認
改訂の比較
見積の分析
変更の依頼

レビューによって、不完全な前提条件や検証されていない前提条件が実行予算になるのを防げます。

5. 承認

承認は、見積が確定した原価管理の実行予算になる瞬間です。

承認の判断は、次の問いに答えるものであるべきです。

この見積は採用されたか
誰が判断したか
何が承認または却下されたか
どの見積が実行予算になったか
手直しが必要か

却下の判断では実行予算は作成されません。見積は改訂のために差し戻されます。

6. 記録

実行予算が有効になると、Darwinはそれに対して実績原価を追跡できます。

原価の追跡では、次のものを記録します。

請求書
サプライヤー
取引の金額
日付
メモ
出所へのリンク
確認の状態

実績原価は、承認した計画につながる施工の根拠です。

7. 学習

差異は、承認済みの実行予算と施工の現実との違いを説明します。

差異から、次のことがわかることがあります。

価格の変動
数量の違い
工事範囲の変更
施工の実態（歩掛の違いなど）
改善が必要な見積の考え方
次回に見直すべき前提条件

根拠を確認し、どの組み立て方、価格の付け方、前提条件を変えるべきかを判断します。その変更は担当者が行い、レビューします。差異によってカタログが自動で更新されることはありません。原価を記録して差異を確認するを参照してください。

大切な考え方

タスクは、誰かに対応を求めます。作業依頼は、仕事がなぜ進んでいるのかを説明します。承認は実行予算を確定させます。差異は、実際の原価を学びに変えます。

運用の規律

ワークフローが信頼できるのは、各段階に先へ進むのに十分な根拠があるときだけです。

プロジェクトを作成する前に、依頼の情報で、求める成果、工事範囲、ファイル、担当者、次の対応を説明する
明確化では、足りない情報をコメント、ファイル、依頼のステータスに残す
作成したプロジェクトには、元の依頼、ファイル、コメント、アクティビティを残す
見積では、モジュール、単価、数量、前提条件の背景を残す
レビューで見つかった問題は、作業依頼を通じて解決するか割り当てる
承認では、実行予算になる見積の改訂を正確に特定する
実績原価には、請求書、サプライヤーのメモ、リンクなどの出所の根拠を含める
差異の結論では、有効な承認済みの実行予算を参照する