動的エンタープライズモデリング（DEM）は、Baan社によって開発されたエンタープライズモデリング手法であり、Baanのエンタープライズリソースプランニングシステムに使用され、「エンドユーザー企業の組織アーキテクチャに合わせて実装する」ことを目的としています。[1] [2]
Koning (2008)によると、Baanは1996年に「Baan ERP製品の実装手段として動的エンタープライズモデリングを導入しました。このモデリングは、Baanアプリケーションユニットがリンクされるビジネスプロセスモデリングのためのペトリネットベースの技術に重点を置いていました。DEMには、企業の物流ネットワークとエンタープライズ機能モデリング図のためのサプライチェーン図ツールも含まれています。」[3]
概要
特定の企業を動的エンタープライズモデリングに適合させるため、組織構造は高レベルのビジネスプロセスから低レベルのプロセスへとトップダウンで設計されます。この設計図は、ソフトウェアパッケージの構造ロードマップと互換性のある組織のロードマップとして使用されます。両方のロードマップを持つことで、ソフトウェアパッケージと組織構造は相互に連携できます。動的エンタープライズモデリングにおける組織構造の設計図は、参照モデルと呼ばれます。参照モデルとは、ビジョン、機能、組織構造、そしてプロセスの全体像であり、これらを総合的に捉えることで、特定の組織類型におけるビジネスの代表的な手法として定義することができます。
DEM参照モデルは、組織アーキテクチャをトップダウンで表現する一連の基礎モデルで構成されています。基礎モデルは以下のとおりです。
- 企業構造図：企業の拠点構造は、分散した地理的拠点、本社、製造工場、倉庫、仕入先および顧客の拠点によって視覚化されます。社内物流や財務フローの最適化のための物理的および論理的なマルチサイト組織を図示できます。[4]
- ビジネスコントロールモデル ：ビジネスコントロールモデルは、組織の主要なプロセスとそのコントロールを、ビジネス機能ごとにグループ化して表します。DEM参照モデルは、1つの主要なビジネスコントロールモデルで構成され、組織の機能領域ごとに複数のビジネスコントロールモデルが存在します。
- ビジネス機能モデル : ビジネス機能モデルは、企業内の複数の機能の対象に焦点を当てた機能モデルです。
- ビジネスプロセスモデル ：ビジネスプロセスモデルは、ビジネスコントロールモデルとビジネス機能モデルから派生した機能とプロセスの実行に焦点を当てています。プロセスフローが図示され、プロセスが詳細化されます。
- ビジネス組織モデル : ビジネス組織モデルは、プロセスよりも、役割や責任などの組織的な側面に重点を置いています。
これらのモデルを組み合わせることで、組織全体の構造と、動的エンタープライズモデリングの実装に必要な側面を描写することができます。これらのモデルは、組織の類型に基づいて区別することができます（例：受注設計型組織と受注組立型組織では、異なるモデル構造が必要です）。参照モデルがソフトウェア実装にどのように使用され、実装方法の範囲を把握するかを詳しく説明するために、ビジネスコントロールモデルとビジネスプロセスモデルについて詳しく説明します。
動的エンタープライズモデリングのトピック
ビジネス管理モデル
ビジネスコントロールモデルは、組織のビジネス機能とそれらの内部および外部の連携をモデル化したものです。このモデルの基本的な特徴は次のとおりです。
- リクエスト・フィードバック・ループ：ビジネス機能間の、あるいはビジネス機能間の、あるいはビジネス機能から、あるいはビジネス機能への、あるいはビジネス機能間のリンクは、リクエスト・フィードバック・ループと呼ばれます。これは、プロセスと両ビジネス機能間の情報の流れを完了させる4つの状態から構成されます。各状態は、リクエスト済み、コミット済み、完了済み、承認済みとラベル付けされています。
- ワークフローケース。ワークフローケースとは、2つのビジネス機能間で発生するプロセスの実行とターゲットを記述したものです。ワークフローケースにおいて最も重要な要素は、量、品質、そして時間です。リクエスト、フィードバック、ループの4つの状態が組み合わさって、ワークフローケースを構成します。
- トリガー: ビジネス機能はビジネス プロセスの集合体であり、主にプロセス間のトリガー (制御) に焦点を当てており、情報フローには焦点を当てていません。
- 業務機能 ：モデリングプロセスにおいて最適な状況では、企業は1つの業務機能のみを有します。ただし、以下の場合には業務機能は細分化されます。
- ワークフローケースの性質と特徴は変動する
- 基礎プロセスの頻度は変動する
- 詳細レベルは変動する
- 1 つ以上の種類のリクエストが関数をトリガーします
2つのビジネス機能間の相互作用に加え、参照モデルのスコープ外にあるオブジェクト間の相互作用も存在します。これらのオブジェクトには、外部ビジネス機能やエージェントなどがあります。
- 外部ビジネス機能 : これは組織の一部であるプロセスのグループ (つまり、組織が機能を制御できる) ですが、参照モデルの範囲外です。
一方、エージェントは、ビジネスの外部にあるという点を除けば、ビジネス機能に似たエンティティです (顧客やサプライヤーなど)。
- ビジネス機能内またはビジネス機能間のプロセスは、イベント駆動型または時間駆動型のトリガーによって実行されます。
- モデルの成功パスが実際に満たされなかった場合、システム内の例外は、ビジネス プロセス構成で設定された処理レベルに従って処理されます。
プロセスのサブルーチンをビジネス コントロール モデルでモデル化して、プロセスの実行中に発生する可能性のある例外 (商品の配送の遅延処理など) に対処できます。
組織の主要なプロセスを構成するビジネス機能に加えて、管理機能が存在します。
- 管理ビジネス機能: ビジネス プロセス自体を管理し、主要なビジネス機能の実行とトリガーをサポートする機能です。
この参照により、組織の主要なプロセスをビジネスコントロールモデルに取り込むことができます。組織の主要な機能は、特定のビジネス機能を構成するプロセスで構成されるビジネス機能にグループ化されます。ビジネス機能間の相互作用は、リクエスト・フィードバック・ループを用いて表現されます。
ビジネスコントロールモデルの構築
ビジネス制御モデルは、設定されたパスに従って構築されます。
- まず、ビジネスの範囲を定義します。範囲には、モデル化の対象範囲の決定、ビジネスに関連するエージェントと外部ビジネス機能の定義が含まれます。
- 次に、ブラック ボックスを囲むすべてのエージェントと外部ビジネス機能を含むブラック ボックスのモデルにスコープが描画されます。
- 次のステップは、エージェントと外部ビジネス機能の間、そしてビジネスコントロールモデルのブラックボックスとの間のプロセスと情報フロー（リクエスト・フィードバックフロー）を定義することです。リクエスト・フィードバックフローを定義することで、モデル作成者はブラックボックス内のプロセスを定義できるようになります。
ビジネス制御モデル内で主要なビジネス機能を作成した後、いくつかのビジネス機能が詳細化されます。
- 生産ビジネスの場合、プロセスが予測ではなく顧客注文に基づいている物理プロセスの分割を指す、顧客注文分離ポイントを定義することが重要です。
- 一方、サービス型ビジネスでは物理的な商品フローが存在しないため、物理的なプロセスモデルは必要ありません。しかしながら、サービスは製品と解釈できるため、同様のプロセスフローを用いてサービス型ビジネスのビジネスコントロールモデルを構築できると考えられます。このように、有形財ではなく無形財を扱う物理的な商品生産ビジネスと同様に、サービス型ビジネスでもビジネスコントロールモデルを構築することができます。
- 低レベルの物理的な生産プロセスに加えて、高レベルのビジネス機能も定義する必要があります。多くの場合、高レベルのビジネス機能は計画機能やその他の戦術的・戦略的なビジネス機能に関連し、続いて販売や購買などの機能が続きます。
高レベルの詳細定義の後、ビジネス機能はより低レベルの詳細定義に分解され、ビジネス制御モデルを参照モデル内の下位モデル（このプラクティスでは主にビジネスプロセスモデル）に関連付けることができます。ビジネスプロセスモデルでは、プロセスは最下位の詳細レベルまで詳細化されます。この詳細レベルに基づいて、Baanソフトウェアの機能がビジネスプロセスモデルに記述されたプロセスに投影されます。
ビジネスプロセスモデル
DEMにおけるプロセスのモデリング、つまりビジネスプロセスモデルのモデリングは、ペトリネットの構成要素を用いて行われます。DEMは4つの構成要素を使用します。
- 状態: 状態要素はジョブ トークンの状態を表し、その状態のジョブ トークンを実行するアクティビティが続きます。
- 処理アクティビティ: 処理アクティビティは、ある状態のジョブ トークンを処理し、ジョブ トークンの状態を別の状態に変換するアクティビティです。
- 制御アクティビティ: 制御アクティビティはプロセス アクティビティをナビゲートしますが、実行はしません。
- サブプロセス: サブプロセスは、複雑性管理によって単一の要素に集約された、さまざまな他のプロセスの集合です。
これら4つの構成要素によって、DEMモデルのモデリングが可能になります。モデリングは、モデリング制約の集合によって実現され、異なるモデラーによって同様のモデルが作成されるようにモデリングプロセスを導きます。プロセスフローの異なる経路を設定するために、制御アクティビティは異なる構造で存在します。制御アクティビティに使用される構造は次のとおりです。
- OR分割 / XOR分割：この構造は、1つの状態から2つの新しい状態を作成し、1つのジョブトークンから2つのジョブトークンを作成することを示します。新しい状態が出力トークンの両方に当てはまる場合、分割はOR分割となり、当てはまらない場合は排他的論理和分割（XOR）となります。
- AND 結合構築: 制御アクティビティを有効にするには 2 つのジョブ トークンの両方が必要であり、1 つの新しいジョブ トークン (つまり 1 つの新しい状態) が作成されます。
- OR 結合 / XOR 結合: 制御アクティビティを有効にするには 2 つのジョブ トークンが必要で、新しいジョブ トークンが 1 つ作成されます。
OR は、2 つの開始ジョブ トークンの 1 つまたは両方を使用できることを意味します。XOR は、出力ジョブ トークンを作成するためにトークンの 1 つだけを使用できることを意味します。
例
以下の例は、ペトリネットのビルディング ブロックを使用して結婚と離婚の概念をモデリングする方法を示しています。
- ペトリネットで構築されたモデルは、独身の男女が結婚を通じて夫婦になり、離婚によって再び独身者に戻る変化を表現します。
- モデルは、男性と女性と呼ばれる 2 つの状態から始まります。
- AND 結合構造 (カップルを形成するには男性と女性の両方が必要) を通じて、2 つの状態がカップリングと呼ばれる制御アクティビティ内でカップルと呼ばれる新しい状態に結合されます。
- その後、カップルの状態は、結婚と呼ばれる処理活動を通じて変換され、結婚したカップルの変化した状態になります。
- 次に、「離婚」というプロセス アクティビティを使用して、「結婚したカップル」という状態が「離婚したカップル」という状態に変換され、「離婚したカップル」という状態になります。
- デカップリングと呼ばれる制御活動は、最終的に離婚した夫婦の状態を男と女の状態に分割します。
評価
組み込みメソッドを使用すると、そのメソッドが付属するソフトウェア製品を実装するように設計されているという利点があります。これは、メソッドの使用がよりシンプルになり、サポートの可能性が広がることを意味します。組み込みメソッドの欠点は、特定の製品ソフトウェアにしか使用できないことです。複数のソフトウェア製品を扱うエンジニアやコンサルタントは、汎用的なメソッドをより有効に活用し、単一の作業方法に絞り込むことができます。
参照
参考文献
- ^ Hossein Bidgoli (2003).情報システム百科事典. 177ページ.
- ^ Heinz-Dieter Knoll他 (2003).標準ソフトウェアシステムによるビジネスパフォーマンスの最適化. p. 95.
- ^ Hendrik Koning (2008). ITアーキテクチャのコミュニケーション Archived 2011-08-05 at the Wayback Machine . Thesis Dutch Research School for Information and Knowledge Systems. ISBN 978-90-5335-163-5. p.94.
- ^ Sjaak Brinkkemper (2001). エンタープライズアプリケーションの開発と実装のためのビジネスモデリング（抄録）Wayback Machineで2011年7月6日にアーカイブ。2009年8月1日にアクセス。
さらに読む
- Fred DrieseとMartin Hromek (1999).「動的エンタープライズモデリングの戦略的、戦術的、運用的利用のいくつかの側面」
- Van Es, RM, Post, HA編 (1996). 『ダイナミック・エンタープライズ・モデリング：ソフトウェア実装におけるパラダイムシフト』 Kluwer.
外部リンク
- Baan Dynamic Enterprise Management Archived 2011-07-10 at the Wayback Machineショートイントロ
- DynamicEnterprise Modeling プレゼンテーション 1999。
