製品の分解構造または構築戦略は、造船プロジェクトにおける最も重要な情報の 1 つです。 優れた構築戦略は、ヤード施設と労働力のスキルを考慮して最適化し、プロジェクトの構築コストを大幅に削減します。 ShipConstructor の製品階層製品は、プロジェクトのビルド戦略を管理できる SSI のソリューションの主要コンポーネントの 1 つです。 製品階層 (ProductHierarchy 製品によって作成された) では、視覚的かつインタラクティブな方法でプロジェクトを簡単に管理できます。 さらに重要なのは、MIM に完全に統合されています。
製品階層製品は、成果物の図面やレポートの作成、プロジェクトの編成、計画、および調整に使用されるさまざまなダウンストリーム ワークフローを自動化するため、いくつかの点で ShipConstructor のハブと見なすことができます。 ProductHierarchyを適切に使用することで、日付や時間の方法論による必要性などの無駄のないイニシアチブをサポートすることにより、エンジニアリング、オペレーション、生産効率を向上させます。 ProductHierarchy を使用して得られるすべての利点にもかかわらず、多くのクライアントが十分に活用していないとよく見る製品の 1 つです。
製品階層の概要
ProductHierarchy の最新のグラフィカル ユーザー インターフェイス (GUI) を使用すると、絶対 に何らかの理由でアセンブリ、サブアセンブリ、パネル、またはその他の種類のグループ化を簡単に作成できます。 クリックアンドドラッグするだけで、これらのアセンブリ(グループ)間でパーツを移動できます。 プロジェクトに定義した規則と標準を使用して部品名を自動的に更新するため、間違いは事実上排除されます。 既定のアセンブリは、モデラーが必要とする「意思決定」の量を減らすために設定されていますが、プロジェクト のどの段階でも 必要な変更を可能にする柔軟性もあります。
製品階層では、複数の製品階層の作成がサポートされています。 各製品階層は、ShipConstructor に完全に統合されており、任意の製品階層に基づいてレポート、フィルタリング、属性継承、および描画生成を行うことができます。 ユーザーは多くの場合、さまざまな理由で複数の製品階層を作成しています。
- 購買情報
- 施設ルーティング情報
- 兵器システムなどの重要なシステム分析。 これには、すべての専門分野(船体&構造、パイプ、HVAC、サポート、電気など)が含まれます。
- 船がユニークな施設の制約を持つ異なるヤードで建造される場合の複数の構築戦略
- 姉妹船の管理
- 変更管理
- など。
ProductHierarchy のもう 1 つの重要な利点は、任意の ShipConstructor 図面に直接双方向接続を持つ点です。 これにより、あらゆる変更に対する視覚的かつ瞬時のフィードバックが容易になります。 軽量の Navisworks モデルでも使用でき、製品構造の理解を支援します。
クライアントが製品階層を十分に活用していない理由
これにはいくつかの理由があり、私はProductHierarchyが十分に活用されていない理由について、クライアントとの話し合いから主な2つの理由について話し合いたいと思います。
1. プロセスとワークフローの変更が遅い
現在、ほぼすべての船舶は、最新の造船ソフトウェアで設計および設計されています。 当社の業界におけるこの移行により、より近代的でデジタルなツールを使用して、当社の製品の設計とエンジニアリングを向上させてきました。
一方、生産プロセスは実際にはあまり変わっていません。 今日利用可能なツールを使用することで、我々は船のエンジニアリングよりも私たちの船の建設を改善するために、より多くではないにしても、同じくらい多くの機会を持っています。
フォアマンAが管理する同じブロックは、フォアマンBが管理する場合よりも5%速く行われると聞くことは珍しくありません。この不一致の理由は、それぞれが独自の方法でブロックを構築することを決めたためです。 私はこれを大きな問題と、庭がコストを削減できる絶好の機会だと思います。
ビルド シーケンスをデジタルで正確に表現することで、最もコスト効率の高い方法でブロックを構築するための情報を含む包括的なビルド パッケージを作成することで、これらの違いを排除できます。 すべての建設決定には、ウォーターフロントの人員とエンジニアリングを含め、ShipConstructorプロジェクトにキャプチャする必要があります。
この情報を ShipConstructor プロジェクトでキャプチャする利点はいくつかあります。
- 知識の獲得: 業界の大きな問題のひとつは、水辺で経験豊富な人材を失う点です。 古き良き時代には、多くのエンジニアが生産フロアに任せ、船を組み立てる最善の方法を決定しました。 しかし、これらの経験豊富な人員は退職し始めており、多くの組織に穴を残しています。 プロジェクトのエンジニアリング中にこれらの専門家を活用し、ShipConstructorプロジェクトに長年の経験を取り込む事によって、船ができるだけ効率的に組み立てられることを保証します。 ShipConstructor からの出力は、本質的にプロジェクトを構築する方法のステップ バイ ステップのマニュアルになります。 私が与えるたとえは、「 あなたのビルド戦略が適切に行われれば、出力は船のイケア取扱説明書に似ています。 “ これは、我々は現在必要と同じタイプの専門家を必要としない繰り返し可能かつ品質の出力に変換されます。
- より良いスケジューリングと見積もり: 単一ブロックのコストが同じ前のブロックよりも5%遅くなる可能性がある場合に上記のシナリオの影響を見れば、スケジュールが決して正しくないのも不思議ではありません。 1%長く取っても1つのブロックは、1%の追加コストを考慮しなくても、緊密に接続された時刻表に影響を与える可能性があります。 ブロックが時間に完了しない場合は、コストのかかる妥協を行う必要があります。 これは、ブロックを次のステージに移動しないことにより、以前のすべてのアセンブリ、サブアセンブリ、およびパネルが次のステージに進むのを停止するからです。 一方、実際のビルドシーケンスをキャプチャすると、より正確なスケジューリングが可能になり、それは任意のヤードのための巨大なコスト削減です。
- エンジニアリングと生産の間のより良いコミュニケーションを促進する: 私が造船の年に間違いなく見てきたことの一つは、生産とエンジニアリングの間のライバル関係です。 私はまた、多くの企業がギャップを埋めるために大きな進歩を遂げているのを見てきました。 成功を収めている企業は、すべてのチームを 1 つのチームとして連携することで、より良い結果が得られると理解しています。 生産チームがエンジニアリングチームや計画チームと協力して「真の」ビルドシーケンスをキャプチャすることで、チームの関係を強化します。うまくいけばJ。
私はこれらのタイプの変更を行う現実と 困難 を理解していますが、私もそれらを作ることの利点を知っています。
2. 利用可能なリソースの不足
これは、SSIと私たちの代表者がいくつかの所有権を取る必要がある場所です。 製品階層の能力は巨大であり、ハンマーを使用するのと同じくらい直感的です。 ただし、ガイダンスやリソースのないハンマーのように、ShipConstructor 内で製品の分解構造を表現する最善の方法や、二次製品階層を使用して利用できる無限の可能性を理解することは困難な場合があります。
現在、さまざまな形式や配送方法で、より多くのリソースを提供する方法に投資しています。 これらは、ドキュメント、画像、ワークフロー図、フォーラムディスカッション、ビデオ、トレーニング資料、さらにはブログ記事Jです。 他のアイデアがあれば、私に知らせてください。
その間、この投稿が質問やアイデアをかき立てる場合は、お気軽にお問い合わせください。
閉会のコメント
多くの造船所は、ShipConstructor内で正確な製造構築シーケンスを定義しないことで、従来のアプローチを使用しています。 これは間違いなく過去に受け入れられました。 しかし、船の組み立て方法を決定できる経験豊富な労働力が縮小しているため、現在のプロセスを変更し、持続可能な戦略を達成するために考える必要があります。
エンジニアリングソリューション内で(退職を決める前に)生産の専門家から知識を得ることは、この知恵を永遠に確保し記録する唯一の方法です。 これにより、知識がデジタル形式で保証され、将来のチームメンバーがこの情報にアクセスできるようになります。
構造がどのように組み立てられるかの現実を反映した、よく考え抜かされ、設計されたビルド戦略を作り出すことができます。 これにより、施設の制約とシニア生産フロアのスタッフの経験が最大化され、最終的には、工数を削減し、再現性を促進し、スケジュールを改善し、品質を向上させます。
さらに、ProductHierarchy 製品の機能を使用すると、ビルド シーケンスを視覚化およびシミュレートすることで、生産の効率を大幅に向上できます。 ビルドシーケンスを使用した作業のインタラクティブな機能により、エンジニアリング、計画、生産が一緒に動作するように促進されます。 この新しいタイプのコラボレーションとオープンなコミュニケーションは、より持続可能なソリューションになります。 この知識のキャプチャは、部品が切断される前であっても、設計のずっと早い段階で問題を特定することで、追加の利点があります。