これは私の最初の「カーテンの後ろ」タイプの投稿になります。 時々、私は内側から明らかなSSIやShipConstructorについて何かを共有しますが、おそらく明らかに見られないでしょう。 これら2つの視点をよりよく揃えることで、私たち全員に利益をもたらします。
2週間前、デニス・モライス、パット・デイビッドと私はラスベガスで開催されたオートデスク・ワン・チーム・カンファレンスから帰国しました。 これは、すべてのオートデスクの販売パートナーのための年次販売サミットです。 SSI は、オートデスクの最も重要な開発者の 1 人であり、米国のオートデスクの販売代理店であるため、参加しています。
オートデスクの従業員や他のオートデスクの再販業者との時間を費やすと、その従業員の何人が ShipConstructor を考えているかのアイデアが得られ始めます。 特にオートデスクの自社製品に重点を置くため、大多数のオートデスクが ShipConstructor を AutoCAD へのプラグインと考えていることが明らかになります。 他のオートデスク製品を含む、すべての全体的な実装は、オートデスク ソリューションと考えられています。 (オートデスク内のチャンピオンに公平になるために少し時間を取り、オートデスクの誰もがそう考えていないと言うべきです。確かにSSIクールエイドを飲んだ人が増えています)
率直に言って、クライアントがSSIと一緒にいれば長ければ長いほど、彼らはShipConstructorをこのように考えている可能性が高くなります。 当社のクライアントの場合、それは主にShipConstructorの以前のバージョンはAutoCADへのプラグインだったためです。
ShipConstructor の古いバージョンに公開されたことがない新しいクライアントは、多かれ少なかれ私たち自身と同じ方法で ShipConstructor を考える傾向があります。 造船ソフトウェアに対する 海洋情報モデリング アプローチと、AutoCAD が主に製品モデル データベースに入るビューポートを使用して、ShipConstructor は AutoCAD の基礎に基づいて構築された製品の範囲と考えています。 基本的に造船のためのオートデスク ソリューションは、ShipConstructor になります。
なぜこれが重要なのですか? これは、ユーザーがエンジニアリング部門内に実装するワークフローがShipConstructorワークフローであるため、重要です。 AutoCAD ワークフローではありません。 これを実現したら、完全な ShipConstructor ソリューションを形成する残りのオートデスク製品が、次の手順で実装できることにすぐに気付きます。 のコンテキスト は、シップコンストラクター ワークフローのコンテキストです。
これは、クライアントがエンジニアリング レビューに Autodesk Navisworks のみを使用し、3D 機器モデリングに Autodesk Inventor を使用していた場合は、おそらくそれほど重要ではありませんでした。 しかし、ここ数年で、オートデスクは 現実のキャプチャ、 シミュレーション、 視覚化、 コラボレーション、エンジニアリングツールの範囲を大幅に拡張しました。 多くの場合、クライアントは、特定の課題に対する最良の答えであり、SSIが 答 えとして見ているため、ShipConstructor コンテキストにおけるこれらの機能のすべてを考えることは重要です。
あなたがまだ このようにSSI とShipConstructorを考えていないなら、私はあなたがした時間であるかどうかを自分自身に尋ねるために皆に挑戦します.