スキッドの統合について機械装置メーカ(OEM)が知っておくべきこと

効率的なエンジニアリングは、すべての機械装置メーカ(OEM)、システムインテグレータ、EPCの成功への鍵です。手直しは敵です。

それにもかかわらず、プロセススキッドの統合に関しては、後戻りはよくありがちなことです。実際に、統合上の難問はしばしばプロジェクトの遅延や予算の跳ね上がりの主要な原因になります。

しかし、それは避けられるはずです。機械装置メーカ(OEM)は、システムの開発時間と立上げ時間を最小限に抑え、お客様のスキッド統合リスクの軽減において主要な役割を果たすことができます。

どんな方法でしょうか?自分の仕事では、私は機械装置メーカ(OEM)のスキッドビルダーと完全に統合されたプロセスソリューションのサプライヤという、方程式の両辺で働いているという特権と課題を抱えています。ここで、経験から学んだいくつかのレッスンを紹介しましょう。

レッスン1: 分離ではなく、統合のために構築する

そう遠くない昔、プロセススキッドは分離システムとしてのみ配備されていました。多くの機械装置メーカ(OEM)はいまだに、旧式の制御技術に基づいたスタンドアロンで設置するための実証済みの機器を提供しています。これらのスキッドを最新のプラント･フロア･アーキテクチャに統合することは難問であり、多くの場合、莫大な費用がかかります。

機械装置メーカ(OEM)とお客様が成果をあげられるようにするには、どうすればいいのでしょうか? 統合機能 および制御システムの拡張性を、機器の開発における最優先事項にすることです。

標準の製品では、製造したすべてのスキッドが他の機器と統合されるものと思ってください。企業レベルの統合用に設計された、スケーラブルな最新式のDCSプラットフォームを機器の土台にすることを検討してください。当社では、フェーズ管理を含むバッチソフトウェアで開発を合理化できることもわかりました。

フェーズ管理機能により、機器フェーズがコントローラに追加されます。これで、スタンドアロンスキッドのコードの作成、使用、管理が行ないやすくなり、必要に応じてソリューションを拡大縮小したり、プラントレベルのバッチやレポーティングシステムと統合しやすくなります。

レッスン2: 事前に計画の優先順位をつける

成功するすべてのプロジェクトの土台となるのは、計画です。プロセススキッドの統合については、事前に行なう作業が多いほど、最後はプロジェクトの実行が楽になります。言うまでもなく、プロジェクトの計画はお客様の仕様とプロジェクトの見込みを定義することから始まります。

計画をあまり早くから始めることはできませんが、スキッドの開発は違います。とはいえ、あまり早くから始めると、プロセス設計、制御システムのアーキテクチャ、ソフトウェアモジュールのテンプレート、統合戦略が完了する前に、手直しをする羽目になります。

1回目で正しく行なってください。始める前に、すべてのプロジェクトのパラメータを文書化してください。

レッスン3: 誰に頼めばいいのかを知る

お客様の組織図をたどり、技術上の決定を下せるのが誰であるかを知るのは、必ずしも簡単ではありません。常に生産的なコミュニケーションを行なうために、お客様と共同で、役割と責任を明確に定義するマトリックスを開発してください。そして、仕事に取りかかる前に、それをプロジェクトチーム全体で共有してください。

プロジェクトの範囲によっては、コミュニケーションはスキッドサプライヤから、インストール用の機器を提供する他のベンダーにまで広がることがあります。システム統合とコミュニケーションを容易にすることは、ベンダー間のすべてのコミュニケーションの目標です。他のサプライヤが自分と同じだと思わないでください。誤解を避けるために、必ずすべての機器と制御機能を明確に定義して記述してください。

レッスン4: 早めにテストし、何回もテストする

テストを十分に行なわないと、すぐれたプロジェクトがあっという間に悪くなり、立上げスケジュールをめちゃくちゃにする可能性があります。失敗を軽減するために、プロジェクトのすべての段階でお客様と一緒にテストを定義してください。

適切なテストの実行では、エンジニアによるスキッド設計の内部的なモジュールテストが行なわれます。次に、システムインテグレータによる機能設計仕様に対するプロセスおよび統合テストが行なわれます。これらのテスト段階で見つからなかった問題への対処と、 システムの再テストを行なってから、出荷時受入れ検査(Factory Acceptance Test (FAT))、および最終的なお客様による現地受入れ検査(Site Acceptance Test (SAT))に進んでください。

レッスン5: 間違いから学ぶ

誰でもみな、間違いから学びたいと思っています。しかしながら、実際は、間違いを反映するための時間をあまり取れません。難しいプロジェクトが1つ完了すると、次が始まります。

このサイクルを破るためには、プロジェクト期間の全体に渡って「習得したレッスン」のログを保管することです。最後に思い出して問題を記録しようとするよりずっと簡単です。プロジェクトが完了したら、チームとセッションを行ない、次に何が改良できるかを特定します。

そして忘れないでください。プロジェクトの計画法はイテレーション(反復的)プロセスです。プロジェクトとプロジェクトの間で少しずつ改善を進めることが、長期に渡って成功を収めるのに重要なのです。