プラントエンジニアリングの設計履歴を追跡する専門的な方法は何ですか?


9

私たちのプロジェクト(バイオガスおよび廃棄物からエネルギーへのプラント)の設計ドキュメントを見ると、私たちが計画しているものはわかりますが、他のどのオプションが考慮されなかったか、なぜそれらが破棄されたのかがわかります。この情報は、エンジニアの頭にのみ存在します。ときどき、プラントは何年もの間構想段階にあり、時にはエンジニアを切り替えます。そのため、昨年、同僚が検討して最後に破棄したオプションを再検討しているのです。

設計の決定、「理由」と「理由」を追跡する良い方法は何ですか?私は、業界の他の場所で試され、テストされ、使用されているアプローチを強く望んでいます。

追加情報:私の会社はISO 9001認証を追求します。このQA制度に適合するアプローチが望まれます。

回答:


3

これは、必要な情報の量と、それをどの程度正式に追跡したいかによって異なると思います。現在のように聞こえますが、この情報はどこにも書き留められていません。これが明らかに最初の問題です。しかし、追求するつもりのないソリューションの情報を書き留めておくことは、せいぜい、最適ではない時間の使い方です。記録するのに十分具体化されているアイデアを定義する必要があります。会議があり、12のアイデアがテーブルに置かれているが、半分はほとんどすぐに破棄された場合、それらのアイデアが何であったか、なぜ破棄されたかをメモしますか?これはおそらく非常に低レベルの分析でしたが、多くの努力が必要ですが、それらは依然として設計上の決定です。

実際に作業を行う段階に達したアイデアに対してのみ、これを行うほうが直感的に思えます。このようにして、あなたはすでに具体的なものを手に入れました、そしてこれはちょうどプロジェクトファイルにファイルされなければなりません、私はそれがあなたがすでに持っているものであることを望みます。このシステムは実際には将来のプロジェクトの参照資料を生成するだけなので、これらの資料をアーカイブしたり、既存のシステムをオーバーホールしたりするためのまったく新しいシステムを作成するのは良い考えではないと思います。それを現在の設計管理システムに統合する方法を見つけてください。

私があなたが持っていることを確認する1つの鍵は、それらの主要なパラメータによって異なるデザインを分類する方法です。私はあなたの分野についてはあまり詳しくありませんが、各プロジェクトが満たす必要のある特定の設計パラメータ(物理的なサイズ、容量、プラントのタイプなど)があると思います。新しいプロジェクトを開始するときに、さまざまな点で類似している古いプロジェクトを識別できるように、これらがどこかで簡単に見えるようにしてください。これらの破棄されたアイデアがこれらのフォルダーに保存されている場合は、現在のプロジェクトに対するそれらの有用性を分析できます。

ただし、これについて深く理解しすぎることについても、一般的に警告したいと思います。繰り返しますが、私は別の業界で働いています。プロジェクトははるかに短いため、プロジェクトはもっと多くありますが、一部の製品は何十年もの間何らかの形で存在しており、15から20のリビジョンがあります。実装された実際の設計変更の改訂履歴を維持することは非常に重要です。顧客が過去に何を与えられたか、いつ変更が行われたか、なぜ変更が行われたのかを知ることは、過去の過ちを繰り返さずに古い設計を正しく保守するための鍵です。しかし、完全には実現されなかった設計をカタログ化すると、必須データの上に非必須データを追加することになり、物事が失われ始める前に並べ替えることができるのはそれほど多くありません。あなたのように聞こえる しっかりしたコミュニケーションと良い経験の代わりを探しています。これらのプロジェクトが手を変えるとき、関係するエンジニアはすべての関連情報を伝達しなければなりません。考慮事項を確実に把握したいと思いますが、不要なデータでレコードを溢れさせないように、その欲求を調整することをお勧めします。


最後の段落と2番目の段落のこの回答と警告は本当に気に入っています。他の人の提案を見ていきます。
2015年

1

Trevorからのこの回答は、すべての哲学に対してかなり良い結果をもたらしていますが、詳細をもっと知りたいと思います。

まず、代替レコードが保持されていない理由を理解します。これは、先見性の問題またはストレージ(紙またはコンピューター)の問題として始まった可能性があります。

かつて、誰かが代替案は役に立たないと思っていたため、破棄または削除されました。これはおそらく企業文化の問題です。これが問題として特定されたので、全社的に提起することができます。すでに作成されているレコードを保持するのは簡単です。

元のエンジニアが代替案が有用であると考えていたとしても、ストレージ(物理的またはコンピュータ)のコストのために、ドキュメントを保持していない可能性があります。それでも問題が解決しない場合は、この問題を解決する必要があります。これがもはや当てはまらない場合、記録を維持することはコストのかかる命題ではないということを全社に広める必要があります。

次に、別の比較方法を見てください。代替検討事項には、思考と計算の2つのカテゴリがあります。

思考の比較は、コンセプト形式以外の方法で紙に書き込めないほど迅速に破棄されたアイデアです。これらのアイデアが初めて非常に迅速に破棄された場合は、おそらくそれらを記録する必要はありません。彼らの信用を落とす努力は非常に簡単なので、彼らは再び信用を失います。

実際に計算段階に進んだ代替案は、何らかの形で保持する必要があります。計算または計画が初めて行われた場合、保存するものはすでにあります。アイデアが行き止まりであることが判明しても、作業はすでに完了しているので、ファイルに入れてください!日付が記載されている限り、参照できます。

決定が下されたら、メモを(特に誰かでない場合はファイルに)書いてください。これは将来の時間を節約しますが、プロセスにステップを追加します。これは一般的に改善された文書化とともに取り組むべきものです。

最後に、すべての日付を記入してください!最終記録を保持するためにすでに配置されているシステムで作業してみてください。すべてに日付を追加してください。他の編成方法が失敗した場合でも、アイテムの日付を使用して代替の順序を再構築できます。


0

以下は、白物家電、消費財、OEMが私がドキュメントのアイデアに関連付けている方法の3つの一般的な方法です。


t+1

設計レビュー(NPD-新製品開発)
設計は、エンジニアリング設計の決定を文書化するのに役立つ別の優れたプロセスをレビューします。これはより技術的な文書になる傾向があり、拒否されたアイデアは十分に文書化されない傾向があります。ほとんどの組織では、設計レビューフェーズゲートモデルの一部です。

バックエンド(本番稼働中または終了中)のアイデアのドキュメント
既存の変更管理システムを使用して新しいアイデアをドキュメント化している組織を見つけました。このシステムでは、エンジニアが簡単な1つまたはページのドキュメントでアイデアを提案します。アイデアはレビューされ、承認または将来のために棚上げされます。この特定の組織は、変更管理にSAPを使用していたため、システムはテクノロジーベースの検索にはあまり適していませんでしたが、システムはうまくいきました。

要約すると、ほとんどのアイデアは次の理由で棚上げされます

  • アイデア/提案を実行するための財源の不足
  • アイデア/提案を実行する人材の不足
  • 現在のプロジェクト計画に適合しない
  • 市場はまだ新しいテクノロジーを受け入れる準備ができていません

したがって、障壁を超えるとアイデアが現実的な解決策になるので、トラックのアイデアは適切です。

参照:


0

他の人は一般的にドキュメントについて多くの良いコメントをしましたが、私は途方もなく役立つソフトウェアの特定のクラスを提案したいと思います。

私は、バージョン管理ソフトウェアがこれらの種類の問題に優れていると思います。残念ながら、それはソフトウェア開発以外ではあまり一般的ではありませんが、他の分野で普及するのは時間の問題です。

以下に例を示します。私の研究グループには、ほとんどの人が使用するSubversionリポジトリがあります(人気のある代替ソフトウェアはgitです)。バージョン管理を使用すると、プロジェクトに関連するほとんどのファイルがそこにあると同時に、彼らがいつ何をしたか、そして(彼らが正しく行った場合)彼らの詳細なログとともに、誰かが去った後の研究プロジェクトの継続性を保証するのに役立ちます。根拠。詳しく説明します。

あなたのコンピュータにすべてのファイルを含むフォルダがあるとしましょう

すべてがコミットされたときに自動的に日付が付けられます(他の人が「アップロード」と呼ぶ可能性があるもののバージョン管理用語)。コミットメッセージは短いメモとして機能します(Mahendra Gunawardenaが示唆したように、より大きな決定には、より長く、より公式なメモが必要になる場合があります)。プロジェクトファイルへの変更について、「アプローチXは実行不可能であると判断しました。代わりにYを試します。アプローチXに関連するファイルを削除し、アプローチYの新しいCADモデルを作成しました」と言います。

そして、後で、アプローチXが実際に適切であると判断し、削除されたファイルを掘り下げたい場合、それは難しくありません。すべてのパーツを簡単に古いバージョンにロールバックして、そこから続行できます。

このアプローチには、いくつかの追加の利点があります。まず、他のユーザーとのファイルの共有が非常に簡単になります。彼らはリポジトリ(現在のバージョンまたはすべてのバージョンを意味するバージョン管理用語)をチェックアウトし、定期的に更新します(そのためのコマンドがあります)。基本的に、全員が同期されます。次に、基本的に無料でバックアップ(古いバージョン)を取得できます。そうは言っても、これは通常のバックアップを保持する必要がないという意味ではなく、誤って失われたファイルを復元するための別のオプションがあるということだけです。リポジトリ全体もバックアップすることを強くお勧めします。


VCSはバイナリBLOBをうまく処理できないと思いました。彼らはファイルを処理するかもしれませんが、何が変更されたかを正確に見ることができなくなります。
ハジー

コミットメッセージで変更された内容を正確に記述することで、これをある程度回避できます。さらに、見ているだけでなく変更点を強調するための追加のソフトウェアが必要です。画像を比較する方法や、2つの異なるデータファイルの違いを確認できるCFD視覚化ソフトウェアを見てきました。一部のCADソフトウェアにもこの機能があることを漠然と思い出します。テキストファイルを比較するほど簡単ではありませんが、原則として不可能ではありません。これは、バージョン管理自体の問題ではなく、差分を表示する機能の問題であることも強調しておきます。
Ben Trettel 2015年

ストレージ効率の点では、データベースに違いを置くだけのほうが明らかに優れています。一部のバージョン管理システムは、バイナリファイルに対してそれを行うと思いますが、もっと詳しく調べる必要があります。
Ben Trettel 2015年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.