ベストプラクティス

Darwinは、一貫性があり、透明で、再利用できる見積を作るための構造化された環境です。以下のベストプラクティスに沿うと、プラットフォームを十分に活用し、プロジェクトを整理された、追跡でき、管理しやすい状態に保てます。

1. モジュールの焦点を絞り、再利用できるようにする

モジュールは、システム全体やあいまいなまとまりではなく、1つの施工の単価内訳を表すようにします。

良い例：

「組積壁 20cm」
「鉄筋コンクリートスラブ 15cm」
「アルミ窓タイプA」

避けるもの：

「壁」
「一般コンクリート」
「開口部」

定義のはっきりしたモジュールのライブラリは、誰にとっても作業をしやすくします。

2. 考え方と単価を分ける

中心にある原則を思い出してください。

モジュールはどうを定義し、単価表はいくらを定義します。

この分離によって、次のことが保証されます。

市場価格が変わったときに、きれいに更新できる
プロジェクトをまたいで前提条件が一貫する
改訂と監査が透明になる

モジュールの中に原価の値を入れないでください。モジュールに入れるのは歩掛と構成です。

3. IFCはあるときに使う。ただし頼り切らない

IFCモデルは、次の作業を速めます。

数量の抽出
マッピング
目での確認

ただし、BIMがなくても、いつでも見積はできます。 IFCは必須条件ではなく、作業を速めるものとして使ってください。

4. 見積の前にマッピングを確かめる

IFCのマッピングを使う場合は、次の点を確認します。

グループを確認する
数量を確認する
外れ値を確認する
各要素に正しいモジュールが割り当てられていることを確かめる

マッピングが見積に数量を提供する前に、確認してください。

5. 単価表を定期的に確認する

価格は変わります。労務単価も変わります。燃料費や物流費も変わります。

良い習慣：

プロジェクトの開始時に単価表を更新する
顧客提案書を確定する前に確認する
大きな単価の更新の後は、見積を計算し直す

編集できる見積で、更新した単価や構成を使うべきときは、明示的に再計算します。通常の保存では既存の単価と構成が保たれます。承認の前に、再計算の変更の概要を確認してください。

6. プロジェクトの書類の保管場所を整理しておく

ファイルは次のようなフォルダーに整理します。

図面
仕様書
見積書
契約書
IFC

重複したファイルをアップロードせず、古いファイルは置き換えます。

将来の自分がきっと感謝します。

7. 共同作業にはタスクを使う

タスクは、次のような作業に向いています。

単価の検証
モジュールのレビュー
書類の依頼
社内の承認

担当がはっきりしていれば、誤解が減ります。

対応の理由を残す必要があるときは、作業依頼を使います。タスクは誰かに対応を求めるもので、作業依頼は仕事がなぜ進んでいるのかを説明し、コメント、ファイル、ステータス、結果をまとめて残します。

8. 上書きせずに改訂を使う

新しい版を作るために、見積を上書きしないでください。代わりに、次のようにします。

関係する変更、単価更新、代替案、確認事項の依頼を作成または承認する
正しい元の見積から、見積の改訂を作成する
改訂に意味のある名前を付ける
新しい版で作業を続ける

これによって、追跡可能性と過去の背景が保たれます。

9. カタログは少しずつ育てる

初日から完璧なカタログを作ろうとしないでください。

まず次のものから始めます。

いくつかのモジュール
中心となる材料
主な労務の職種

実際のプロジェクトで必要になるにつれて広げていきます。

10. わかりやすい名前の付け方を使う

良い名前の付け方は、すべてのユーザーの助けになります。

「間仕切り – 石こうボード – 2枚張り 15mm」
「コンクリート – スラブ – 15cm – 鉄筋入り」
「ドア – 鋼製 – タイプA」

わかりやすい名前は、マッピング、絞り込み、教育を速めます。

11. 前提条件を文書化する

モジュールやプロジェクトの中にメモを追加し、次のことを説明します。

歩掛の前提条件
サプライヤーの参考情報
設計上の制約
除外事項

良い記録は時間を節約し、誤解を防ぎます。

12. プロジェクトの履歴はアクティビティの記録で確認する

アクティビティのフィードを使うと、次のことができます。

誰が何を変えたかを確かめる
IFCの再処理を確認する
単価表の更新を追跡する
タスクの進み具合を見守る

複数のユーザーで作業する環境では、特に役立ちます。

次のステップ

さらに詳しい内容を確認します。