エンタープライズエンジニアリング

エンタープライズ エンジニアリングは、企業の全体または一部を設計するために使用される知識、原則、および実践の集合体です。 ^[1]エンタープライズは、共通のミッションをサポートするために相互に作用し、環境と相互作用する人、情報、およびテクノロジで構成される複雑な社会技術システムです。1 つの定義は、「エンタープライズの識別、設計、実装、および継続的な進化のためのエンタープライズ ライフサイクル指向の分野」です。^[2]エンタープライズ モデリングによってサポートされています。この分野では、ビジネス プロセス、情報フロー、マテリアル フロー、組織構造など、エンタープライズの各側面を調査します。^[3]エンタープライズ エンジニアリングは、エンタープライズ全体の設計、または特定のビジネス コンポーネントの設計と統合に焦点を当てる場合があります。^[4]

いくつかの種類のエンタープライズ エンジニアリングが登場しました。

エンジニアリングにおいて、エンタープライズエンジニアリングは多種多様な活動をカバーしています。^[5]「企業に関連するすべての要素の分析、設計、実装、運用に関連する知識、原則、分野の応用。本質的には、これはシステムエンジニアリングと戦略的管理を組み合わせた学際的な分野であり、製品、プロセス、ビジネスオペレーションの観点から企業全体をエンジニアリングすることを目指しています。」^{[5]この分野は、}エンジニアリング管理、運用管理、サービス管理、システムエンジニアリングに関連しています。

ソフトウェア開発において、エンタープライズエンジニアリングは、ビジネスプロセスと機能のさまざまな組織的および技術的部分のモデリングと統合を扱います。^{[6]情報システム開発では、これは}システム分析の組織化の活動領域となり、情報モデリングの既存の範囲の拡張となっています。^{[7]これは、}ソフトウェア開発プロセスのシステム分析フェーズとシステム設計フェーズの拡張および一般化と見なすこともできます。^{[8]ここで、エンタープライズモデリングは、}情報システム開発ライフサイクルの初期、中期、後期の一部を形成します。組織的および技術的なシステムインフラストラクチャの明示的な表現は、既存の作業慣行の秩序ある変換を理解するために開発されています。^[8]この分野は、エンタープライズアーキテクチャ、またはエンタープライズオントロジーとともに、エンタープライズアーキテクチャの2つの主要なサブフィールドの1つとして定義されています。^[3]

エンタープライズ エンジニアリングには、組織に再利用可能なビジネス プロセス ソリューションを提供するために設計、テスト、および広範囲に使用される正式な方法論、メソッド、およびテクニックが含まれます。

• 組織のための設計とエンジニアリングの方法論^{[9] [3]}
• コンピュータ統合製造オープンシステムアーキテクチャ（CIMOSA）方法論^[10]
• 統合定義（IDEF）方法論^[11]
• ペトリネット^[12]
• 統一モデリング言語（UML）または統一エンタープライズモデリング言語（UEML）^{[13] [14]}
• エンタープライズ機能図(EFD)

これらの方法論、テクニック、手法はすべて、企業とその基盤となるプロセスをモデル化するのに多かれ少なかれ適しています。

DEMO は、組織の設計とエンジニアリングのための方法論です。中心となる概念は「コミュニケーション アクション」です。コミュニケーションは組織の機能に不可欠であると考えられています。従業員、顧客、サプライヤー間の合意は、まさにコミュニケーションを目的として作成されます。提供された結果の受け入れについても同様です。^{[9] [3]}

DEMO方法論は以下の原則に基づいています: ^[15]

• 組織の本質は、行動し交渉する権限と責任を持つ人々で構成されていることです。
• ビジネス プロセスと情報システムのモデリングは、統一性につながる合理的なアクティビティです。
• モデルは関係者全員が理解できるものでなければなりません。
• 情報はユーザーに「適合」している必要があります。

DEMO 方法論は、コミュニケーション、情報、アクション、組織について一貫した理解を提供します。ここでは、情報と中心組織の両方を明確に理解しながら、範囲が「情報システム エンジニアリング」から「ビジネス システム エンジニアリング」に移行します。

CIMOSA は、企業要件のビジネス、人材、情報技術 (IT) の側面をコード化するためのテンプレートと相互接続されたモデリング構造を提供します。これは、情報ビュー、機能ビュー、リソース ビュー、組織ビューなど、複数の観点から行われます。これらの構造は、詳細な IT システムの設計と実装を構造化し、促進するためにも使用できます。

さまざまなビューに分割されているため、企業エンジニアやソフトウェア エンジニアにとってわかりやすいリファレンスとなります。アクティビティ、プロセス、操作などのさまざまな企業機能の情報ニーズが、対応するリソースとともに表示されます。これにより、特定のアクティビティとそれに関連するプロセスの情報ニーズを満たす IT システムを簡単に判断できます。

IDEF は、当初は製造システムをモデル化するためのモデリング言語として開発され、1981 年から米国空軍で使用されており、当初は特定の観点から企業をモデル化するための 4 つの異なる表記法を提供していました。これらは、機能、データ、動的、およびプロセス分析のそれぞれに対応するIDEF0、IDEF1、IDEF2、および IDEF3 でした。過去数十年にわたって、これらの異なる表記法を統合するための多数のツールと手法が段階的に開発されてきました。

IDEF は、ビジネス プロセスが、対応する情報の入力、出力、アクターを含むさまざまな分解されたビジネス機能を通じてどのように流れるかを示します。CIMOSA と同様に、IDEF もさまざまなエンタープライズ ビューを使用します。さらに、IDEF はIT システムをさらに開発するためにUML ダイアグラムに簡単に変換できます。これらの優れた特性により、IDEF は機能ソフトウェア アーキテクチャの開発に強力な方法となります。

ペトリネットは、製造システムをモデル化するために使用される確立されたツールです。^{[16]非常に表現力があり、}並行システムのモデル化に適した形式を提供します。最も有利な特性は、状態、並行システムの遷移、および機能の単純な表現を作成できるため、遷移の期間をモデル化できることです。その結果、ペトリネットを使用して、対応する状態と遷移またはアクティビティ、および出力を持つ特定のビジネスプロセスをモデル化できます。さらに、ペトリネットを使用して、さまざまなソフトウェアシステムとこれらのシステム間の遷移をモデル化できます。このように、プログラマーはペトリネットを図式的なコーディングリファレンスとして使用できます。

近年の研究では、ペトリネットがビジネスプロセス統合の発展に貢献できることが示されています。その1つが、IBMの中国研究所が開発した「モデルブルー」方法論です。モデルブルーは、統合ソフトウェアプラットフォームを構築するための新しいアプローチとして、モデル駆動型ビジネス統合の重要性を概説しています。^[17]モデルブルーのビジネスビューと同等のペトリネットの対応も示されており、これは彼らの研究がビジネスとITのギャップを埋めたことを示しています。ただし、研究者はペトリネットの代わりに、変換エンジンを介してビジネスビューから派生できる独自のモデルブルーITビューを使用しています。

統一モデリング言語(UML) は、ソフトウェア システムおよびアプリケーションの開発に広く受け入れられているモデリング言語です。オブジェクト指向分析および設計コミュニティの多くも、エンタープライズ モデリングの目的で UML を使用しています。ここでは、複雑なエンタープライズ システムを作成するためのエンタープライズ オブジェクトまたはビジネス オブジェクトの使用に重点が置かれています。これらのオブジェクトのコレクションとそれらの間の対応する相互作用は、複雑なビジネス システムまたはプロセスを表すことができます。ペトリ ネットはオブジェクトの相互作用と状態に焦点を当てていますが、UML はビジネス オブジェクト自体に重点を置いています。これらは「エンタープライズ ビルディング ブロック」と呼ばれることもあり、リソース、プロセス、目標、ルール、およびメタモデルが含まれます。^[18] UML を使用して統合ソフトウェア システムをモデル化できるという事実にもかかわらず、ビジネスの現実はソフトウェア モデリング言語でモデル化できると主張されてきました。これに応じて、オブジェクト指向コミュニティは UML のビジネス拡張機能を作成し、それに応じて言語を適応させます。拡張エンタープライズ モデリング言語(EEML) は UML から派生したもので、ビジネス モデリング言語として提案されています。 UML を他の「純粋な」ビジネス手法と組み合わせる方がより良い選択肢になる可能性があると以前に述べたように、このビジネス変革が正しい方法であるかどうかという疑問が残ります。

EFD は、エンタープライズ機能とそれに対応する相互作用を表現するモデリング手法として使用されます。これらの表現では、「機能モジュール」とトリガーを使用して、さまざまなビジネス プロセスをモデル化できます。開始ビジネス プロセスは、さまざまな機能にさまざまな入力を提供します。すべての機能とサブ機能を通過するプロセスは、複数の出力を作成します。エンタープライズ機能図は、ビジネス プロセスとそれに対応する機能、入力、出力、トリガーについて、使いやすく詳細な表現を提供します。このように、EFD は、機能とトリガーの組み合わせとして階層的にビジネス プロセスを表現する IDEF0 図と多くの類似点があります。この 2 つの違いは、EFD ではビジネス機能が組織の階層的な観点に配置され、組織内の特定のプロセスの下流の概要が示されることです。一方、IDEF0 図では、矢印を使用して特定のビジネス機能の責任を示します。さらに、IDEF0 では、すべての (サブ) 機能の入力と出力が明確に表現されます。

EFDはUMLのようなソフトウェアモデリング言語のビジネスフロントエンドとして使用できます。モデリングツールとしてのIDEFとの大きな類似性は、これが実際に可能であることを示しています。ただし、UMLへの正式なマッピングが行えるようにEFD技術を改善するには、さらなる研究が必要です。^[19] IDEFとUMLの相補的使用に関する研究は、IDEFをビジネスフロントエンドとして受け入れることに貢献しており、したがってEFDとUMLでも同様の研究を行う必要があります。

• ビジネスエンジニアリング
• ビジネスアーキテクチャ
• 組織向けの設計とエンジニアリングの方法論
• エンタープライズアーキテクチャ
• エンタープライズアーキテクチャ計画
• エンタープライズ統合
• エンタープライズライフサイクル
• エンタープライズシステムエンジニアリング
• 汎用エンタープライズリファレンスアーキテクチャと方法論
• 機能的なソフトウェアアーキテクチャ
• 工業工学
• エンジニアリング管理
• エンジニアリング管理
• ソフトウェア工場
• モデルを表示

• エンタープライズエンジニアリング研究所 [1] 2018-11-25にWayback Machineでアーカイブ
• CIAO!ネットワーク [2]
• 通知する
• 産業技術者協会

Wikiquote には、エンタープライズ エンジニアリングに関連する引用があります。

• Jan LG Dietz (2008) (編)。エンタープライズ エンジニアリングの進歩 I: 第 4 回国際ワークショップ CIAO! および第 4 回国際ワークショップ EOMAS、CAiSE 2008、フランスのモンペリエで 2008 年 6 月 16 ～ 17 日に開催。議事録。
• Cheng Hsu (2007) (編)サービスエンタープライズ統合：エンタープライズエンジニアリングの観点。
• Duane W. Hybertson (2009).モデル指向システム工学科学：従来型システムと複雑系システムの統合フレームワーク。
• Kurt Kosanke、François Vernadat、Martin Zelm、「CIMOSA: エンタープライズエンジニアリングと統合」、Computers in Industry、40 (2-3) (1999) 83-97。
• Liles, Donald H.他「エンタープライズ エンジニアリング: 専門分野か?」エンタープライズ エンジニアリング協会会議議事録。第 6 巻。1995 年。
• Liles, Donald H.および Adrien R. Presley。「エンタープライズ エンジニアリング フレームワーク内でのエンタープライズ モデリング」。第 28 回 Winter シミュレーション カンファレンスの議事録。IEEE Computer Society、1996 年。
• Dietz, JLG, Hoogervorst, JAP, et al., The Discipline of Enterprise Engineering. Int. j. Organisational Design and Engineering. Vol. 3. 2013. 28.
• Dietz、JLG、Mulder、HBF、「エンタープライズ オントロジー、組織の本質を理解するための人間中心のアプローチ」、Springer、2020 年。
• de Boer A.、De Vries M. (2021) エンタープライズ エンジニアリングに基づくアプローチによるエンタープライズ キャパシティの開発。Aveiro D.、Guizzardi G.、Pergl R.、Proper HA (編) エンタープライズ エンジニアリングの進歩 XIV。EEWC 2020。ビジネス情報処理の講義ノート、vol 411。Springer、Cham。https://doi.org/10.1007/978-3-030-74196-9_11。