ビジネスプロセスモデリング

ビジネスプロセスモデリング( BPM ) は、企業のプロセスをキャプチャして表現する (つまり、モデル化する)アクションであり、これにより、現在のビジネスプロセスを分析し、安全かつ一貫して適用し、改善し、自動化することができます。

BPM は通常、ビジネスアナリストによって実行され、各分野の専門家がこれらのチームと連携してプロセスを正確にモデル化します。主に、ビジネスプロセス管理、ソフトウェア開発、またはシステムエンジニアリングで使用されます。

あるいは、イベントログなどの IT システムからプロセスモデルを直接モデル化することもできます。

概要

ビジネスプロセスマネジメント専門家協会（ABPMP）によれば、ビジネスプロセスモデリングは、次の5つの分野で構成されるビジネスプロセスマネジメントの1つの分野です。 ^[1] ^{（第1.4章CBOK®構造）←ドイツ語からの自動翻訳}

プロセスモデリング
プロセス分析（現状のプロセスと会社の目的との整合性の理解 - ビジネス活動の分析）
プロセス設計 (再設計 - ビジネスプロセスリエンジニアリング - またはビジネスプロセスの再設計 - ビジネスプロセス最適化)
プロセスパフォーマンス測定（時間、コスト、容量、品質の要素に焦点を当てることも、無駄の包括的な視点に焦点を当てることもできます）
プロセス変革（計画的かつ構造化された開発、技術的実現、および継続的な運用への移行）

ただし、分野を完全に別々に検討することはできません。ビジネスプロセスモデリングでは、現状のプロセスをモデリングするためのビジネスプロセス分析(「ビジネスアクティビティの分析」セクションを参照) または将来のプロセスをモデリングするためのプロセス設計の仕様(「ビジネスプロセスリエンジニアリング」および「ビジネスプロセス最適化」セクションを参照) が常に必要になります。

ビジネスプロセスモデリングの焦点は、アクション（アクティビティ）の流れを表現することにあります。Hermann J. SchmelzerとWolfgang Sesselmannによると、これは「顧客が期待する特定のサービスを生み出し、その結果が会社にとって戦略的意義を持つ付加価値活動を部門横断的に特定すること」です。これらは会社の境界を越えて、顧客、サプライヤー、さらには競合他社の活動にまで及ぶ可能性があります。^[2] ^{（第2.1章プロセスとビジネスプロセスの違い）←ドイツ語からの自動翻訳}

ただし、データやビジネスオブジェクト(入力/出力として) 、正式な組織と役割(責任者/説明責任者/相談先/情報提供先、RACI を参照)、リソースとIT システム、ガイドライン/指示 (作業機器)、要件、主要な数値などの他の品質 (事実) もモデル化できます。

これらの特性がビジネスプロセスモデリングに多く組み込まれるほど、ビジネスプロセスモデルの抽象化が現実をより良く反映するようになり、ビジネスプロセスモデルはより複雑になります。「複雑さを軽減し、モデルの理解度と透明性を向上させるには、ビューコンセプトの使用が推奨されます。」^[3]^{(第 2.4 章プロセスモデリングのビュー) ← ドイツ語からの自動翻訳また、ドイツ語圏の}ビジネス情報学の 5 つの関連学派のビューコンセプトの簡単な比較もあります。1) August W. Scheer、2) Hubert Österle、3) Otto K. Ferstl および Elmar J. Sinz、4) Hermann Gehring、5) Andreas Gadatsch。

ビュー( August W. Scheer 、Otto K. Ferstl、Elmar J. Sinz、Hermann Gehring、Andreas Gadatsch)という用語は、ビジネス情報学のすべての学校で一様に使用されているわけではありません。代替用語としては、デザインディメンション(Hubert Österle) やパースペクティブ(Zachman) などがあります。

M. Rosemann、A. Schwegmann、P. Delfmann もビューの概念に欠点があると指摘しています。「各パースペクティブに対して個別に、したがって部分的に冗長な情報モデルを作成することは考えられます。しかし、冗長性は常にメンテナンスの労力の増加を意味し、モデルの一貫性を危険にさらします。」^[4] ^{(第 3.2.1 章プロセスモデルに関する関連するパースペクティブ) ← ドイツ語からの自動翻訳}

アンドレアス・ガダッチによれば、ビジネスプロセスモデリングは、プロセス定義やプロセス管理と並んで、ビジネスプロセス管理の一部として理解されている。^[3] ^{（第1.1章プロセス管理）←ドイツ語からの自動翻訳}

ビジネスプロセスモデリングは、総合的な企業マッピングの中心的な側面でもあります。総合的な企業マッピングでは、企業のミッションステートメント、企業ポリシー/企業統治、組織構造、プロセス編成、アプリケーションアーキテクチャ、規制、利益団体、市場のマッピングも扱います。

欧州ビジネスプロセス管理協会 (EABPM) によると、「エンドツーエンドのビジネスプロセスには 3 つの異なるタイプがあります。

リーダーシップのプロセス。
実行プロセスと
「プロセスをサポートする」^[1] ^{（第2.4章プロセスの種類）←ドイツ語からの自動翻訳}

これらの 3 つのプロセスタイプは、どの企業でも識別でき、ビジネスプロセスモデルを構造化するための最上位レベルとして、ほぼ例外なく実際に使用されています。^[5]リーダーシッププロセスという用語の代わりに、管理プロセスという用語が一般的に使用されています。実行プロセスという用語の代わりに、コアプロセスという用語が広く受け入れられるようになりました。^[2] ^{(第 6.2.1 章目的と概念) ← ドイツ語からの自動翻訳、}^[6] ^{(第 1.3 章プロセスの概念) ← ドイツ語からの自動翻訳、}^[7] ^{(第 4.12.2 章コア目的とサポート目的の区別) ← ドイツ語からの自動翻訳、}^[8] ^{(第 6.2.2 章識別と下書き) ← ドイツ語からの自動翻訳}

その後、コアプロセスがサプライチェーン管理(SCM)、顧客関係管理(CRM)、製品ライフサイクル管理(PLM)の次のレベルで編成/分解されると、 SCOR モデルなどの大規模組織や業界団体の標準モデルもビジネスプロセスモデリングに統合できます。

歴史

フローチャート、機能フローブロック図、制御フロー図、ガントチャート、PERT図、IDEFなどのビジネスプロセスをモデル化する手法は、20世紀初頭から登場しています。ガントチャートは1899年頃に最初に登場したものの1つで、フローチャートは1920年代、機能フローブロック図とPERTは1950年代、データフロー図とIDEFは1970年代に登場しました。最新の手法としては、統一モデリング言語やビジネスプロセスモデルと表記法などがあります。しかし、これらはビジネスプロセスを文書化するために長年使用されてきた方法論のほんの一部にすぎません。^[9]ビジネスプロセスモデリングという用語は、1960年代にシステムエンジニアリングの分野でS.ウィリアムズが1967年の論文「ビジネスプロセスモデリングによる管理制御の向上」で作りました。^{[10]彼のアイデアは、物理的な制御システムをより深く理解するための手法を、}ビジネスプロセスにも同じように使用できるというものでした。この用語が普及したのは 1990 年代になってからでした。

1990年代には、プロセスという用語が新しい生産性パラダイムになりました。^{[11]企業は、}機能や手順ではなくプロセスで考えるよう奨励されました。プロセス思考は、購入から供給、注文の取得から販売など、企業内の一連のイベントに注目します。従来のモデリングツールは時間とコストを説明するために開発されましたが、最新のツールは機能横断的な活動に焦点を当てています。これらの機能横断的な活動は、複雑性と依存性の増大により、数と重要性が大幅に増加しました。新しい方法論には、ビジネスプロセスの再設計、ビジネスプロセスイノベーション、ビジネスプロセス管理、統合ビジネスプランニングなどがあり、すべて「企業を構成する従来の機能全体のプロセスを改善することを目指しています」。^[11]

ソフトウェアエンジニアリングの分野では、ビジネスプロセスモデリングという用語は、一般的なソフトウェアプロセスモデリングに対抗するものであり、ソフトウェア開発中の実践の状態に重点を置くことを目的としていました。^[12]当時（1990年代初頭）、ビジネスプロセスを説明するための既存および新しいモデリング手法はすべて、「ビジネスプロセスモデリング言語」として統合されました^[要出典]。オブジェクト指向アプローチでは、これはビジネスアプリケーションシステムの仕様策定における重要なステップであると考えられていました。ビジネスプロセスモデリングは、データ収集、データフロー分析、プロセスフロー図、レポート機能などをサポートする新しい方法論の基盤となりました。1995年頃、ビジネスプロセスモデリングと実装のための最初の視覚指向ツールが発表されました。

ビジネスプロセスモデリングの目的

ビジネスプロセスモデリングの目的は、エンドツーエンドのプロセスを通常はグラフィカルに表現することです。これにより、現実の複雑な事実が統一された (体系化された) 表現を使用して文書化され、実質的な (品質) ものにまで削減されます。プロセスの文書化に関する規制要件も、ここでは多くの場合役割を果たします (例:文書管理、追跡可能性、整合性)。たとえば、品質管理、情報セキュリティ管理、データ保護などです。

ビジネスプロセスモデリングは、通常、環境要件の決定から始まります。まず、モデリングの目標(ビジネスプロセスモデリングのアプリケーション) を決定する必要があります。ビジネスプロセスモデルは現在、多機能的に使用されることがよくあります (上記を参照)。次に、モデルの宛先を決定する必要があります。作成するモデルのプロパティは、その要件を満たす必要があるためです。次に、モデル化するビジネスプロセスを決定します。

モデルで表現されるビジネスプロセスの品質は、モデリングの目的に応じて指定されます。通常、プロセスを構成する機能 (それらの関係を含む) だけでなく、形式的な組織、入力、出力、リソース、情報、メディア、トランザクション、イベント、状態、条件、操作、メソッドなど、他の多くの品質も含まれます。

詳細には、ビジネスプロセスモデリングの目的には以下が含まれます（比較：ビジネスプロセス管理専門家協会（ABPMP）^[1] ^{（第3.1.2章プロセスの特性とプロパティ）←ドイツ語からの自動翻訳}）：

会社のビジネスプロセスの文書化
- ビジネスプロセスに関する知識を得る
- 事業部門を該当する規制にマッピングする
- ビジネスプロセスを他の場所に移転する
- 新たな事業活動の要件を決定する
- 手順と作業指示書からの一連のルールの外部フレームワークを提供する
- ビジネスパートナーや団体の要件を満たすため（例：認証）
- 競争相手より優位に立つ（例：入札において）
- 法的規制を遵守するため（例：重要なインフラの運営者、銀行、兵器製造者など）
- 基準とコンプライアンス要件の達成を確認する
- コミュニケーションと議論の基盤を築く
- 従業員を訓練したり、慣れさせる
- 知識の損失を避けるため（例：スタッフの退職による）
- 品質と環境管理をサポートする
プロセスパフォーマンス指標の定義とプロセスパフォーマンスの監視
- 処理速度を上げる
- サイクルタイムを短縮する
- 品質を高める
- 人件費、材料費、スクラップ費、資本費などのコストを削減する
ビジネスプロセス最適化の準備/実装（通常は現状の分析から始まります）
- 現状分析をサポートする
- 代替プロセスを開発する
- 新しい組織構造を導入する
- 会社の業務をアウトソーシングする
- 会社のプロセスを再設計、合理化、または改善する（例： CMMの助けを借りて）
情報技術プロジェクトの準備
- ソフトウェア評価/ソフトウェア選択をサポートする
- 市販のソフトウェアのカスタマイズをサポートする
- ワークフロー管理システムによる自動化やITサポートを導入する
インターフェースとSLAの定義
企業プロセスのモジュール化
社内部門、パートナー、競合他社間のベンチマーク
活動基準原価計算とシミュレーションの実行
- プロセスがさまざまなストレス儀式や予想される変化にどのように反応するかを理解する
- ビジネスプロセス最適化のための対策の有効性を評価し、代替案を比較する
ベストプラクティスを見つける
組織変更に伴う
- 売却や部分売却など
- 企業または企業の一部を買収、統合するなど
- ITシステムや組織構造の導入や変更など
コンテストへの参加（ EFQMなど）。

ビジネスプロセスモデリングの応用

ビジネスプロセスモデリング自体は企業の財務上の成功に直接貢献しないため、企業の最も重要な目標である利益を上げるという意図からビジネスプロセスモデリングの動機は生まれません。したがって、企業がビジネスプロセスモデリングに取り組む動機は常にそれぞれの目的から生じます。Michael Rosemann、Ansgar Schwegmann、Patrick Delfmann は、ビジネスプロセスモデリングの動機としていくつかの目的を挙げています。

組織文書、「プロセスに関するコミュニケーションの効率を高めるために、プロセスに関する透明性を高めること」を目的とした文書^[4] ^{(第3.2.1章プロセスモデルに関する関連する観点) ← ドイツ語からの自動翻訳、}^[3] ^{(第2.5.4章プロセスモデリングの実際の適用分野) ← ドイツ語からの自動翻訳、} ビジネス機能を再配置または複製するためのプロセステンプレートを作成する機能、または完全な企業モデルを作成する目的を含む
プロセス指向の再編成、「（革命的な）ビジネスプロセスリエンジニアリングと継続的な（進化的な）プロセス改善の両方の意味」^[4] ^{（第3.2.1章プロセスモデルに関する関連する観点）←ドイツ語からの自動翻訳、}脆弱性評価の目的^[3] ^{（第2.5.4章プロセスモデリングの実際の適用分野）←ドイツ語からの自動翻訳}、プロセス最適化（例えば、カイゼン、シックスシグマなどを通じて、総サイクルタイム^[13]（TCT）の制御と短縮による）またはプロセス標準化
継続的なプロセス管理、「持続可能性に向けたプロセスの計画、実装、制御」^[4] ^{（第3.2.1章プロセスモデルに関する関連する視点）←ドイツ語からの自動翻訳}
DIN ISO/IEC 9001に準拠した認証（またはISO/IEC 14001、ISO/IEC 27001などに準拠した認証）
ベンチマーキングは、「企業固有の構造とパフォーマンスを、選択された内部または外部の参照と比較すること」と定義されます。プロセスモデリングの文脈では、これにはプロセスモデルの比較（構造的ベンチマーキング）またはプロセスの主要な数値の比較が含まれます」^[4] ^{（第3.2.1章プロセスモデルに関する関連する観点）←ドイツ語からの自動翻訳}
「知識の特定、獲得、活用、開発、配布のプロセスを改善するために、企業の知識リソースに関する透明性を高めることを目指す」ナレッジマネジメント^[4] ^{（第3.2.1章プロセスモデルに関する関連する観点）←ドイツ語からの自動翻訳}
ERPソフトウェアの選択は、「多くの場合、（ソフトウェア固有の）参照モデルの形式でその機能を文書化しているため、ソフトウェアの選択には、企業固有のプロセスモデルとこれらのソフトウェア固有のモデルの比較も使用すると合理的です」^[4] ^{（第3.2.1章プロセスモデルの関連する観点）←ドイツ語からの自動翻訳、} < ^[3] ^{（第2.5.4章プロセスモデリングの実際の適用分野）←ドイツ語からの自動翻訳}
モデルベースのカスタマイズ、すなわち「市販のソフトウェアの構成」は、多くの場合「参照モデルの構成によるソフトウェアのパラメータ化」によって行われます。^[4] ^{（第3.2.1章プロセスモデルに関する関連する観点）←ドイツ語からの自動翻訳、}^[3] ^{（第2.5.4章プロセスモデリングの実際の適用分野）←ドイツ語からの自動翻訳}
ソフトウェア開発、「要件エンジニアリングの一環として概念レベルで開発されるソフトウェアの要件を記述する」ためのプロセスを使用する^[4]^{(第 3.2.1 章プロセスモデルに関する関連する観点) ← ドイツ語からの自動翻訳、}^[14] ^{(第 3 章プロセス指向のアプリケーションランドスケープへの道) ← ドイツ語からの自動翻訳、}^[3] ^{(第 2.5.4 章実際のプロセスモデリングの適用分野) ← ドイツ語からの自動翻訳}
ワークフロー管理では、プロセスモデルは「インスタンス化可能なワークフローモデルを作成するための基礎」です^[4] ^{（第3.2.1章プロセスモデルに関する関連する観点）←ドイツ語からの自動翻訳}
「時間の経過に伴うシステムの動作の調査」と「純粋なモデルビューでは明らかにならない弱点の特定」を目的としたシミュレーション^[4] ^{（第3.2.1章プロセスモデルに関する関連する観点）←ドイツ語からの自動翻訳}

ビジネスプロセスリエンジニアリング（BPR）

1984 年にMITで開始された「1990 年代の経営」と題する大規模な研究プログラムの中で、1990 年代初頭にプロセスリエンジニアリングのアプローチが生まれました。この研究プログラムは、1990 年代以降の競争環境において組織が生き残り、繁栄するために情報技術が及ぼす影響を調査するために設計されました。最終報告書で、N. Venkat Venkatraman ^[15]は結果を次のように要約しています。「生産性の最大の向上は、情報技術と並行して新しいプロセスを計画した場合に達成できます。」

このアプローチは、トーマス・H・ダベンポート^[16] ^{（パートI：プロセスイノベーションのフレームワーク、章：はじめに）}やマイケル・M・ハマー、ジェームズ・A・チャンピー^[17]によって取り上げられ、今日私たちが理解しているビジネスプロセスリエンジニアリング（BPR）へと発展しました。BPRによれば、コスト、品質、サービス、時間などの測定可能なパフォーマンス指標の改善を達成するために、ビジネスプロセスが根本的に再構築されます。

ビジネスプロセスリエンジニアリングは、一部では「グリーンフィールド」から開始されるため、既存の企業では直接実装できないという批判を受けています。Hermann J. Schmelzer と Wolfgang Sesselmann は、これを次のように評価しています。「BPR に対する批判は、多くの点で学術的な性格を持っています。... 提起された批判の一部は、実践的な観点から正当化されています。これには、過度に急進的なアプローチには失敗のリスクがあることの指摘が含まれます。組織と従業員が BPR に十分に備えていない場合は特に問題になります。」^[2] ^{(第 6.2.1 章目的と概念) ← ドイツ語からの自動翻訳}

Thomas H. Davenport によると、BPR への高レベルのアプローチは次のようになります。

イノベーションのプロセスの特定
変化の要因を特定する
プロセスビジョンの開発
既存のプロセスを理解する
新しいプロセスの設計とプロトタイプ作成

ISOに準拠した管理システムの認証

ISO/IEC 27001:2022 により、管理システムの標準要件はすべての主要な ISO 規格に対して標準化され、プロセス特性を持つようになりました。

プロセスに関する管理システムの一般的な標準要求事項

ISO/IEC 9001、ISO/IEC 14001、ISO/IEC 27001 規格では、それぞれのケースで第 4.4 章にこれが規定されています。

これらの規格はいずれも、組織が「必要なプロセスとその相互作用を含む」適切な管理システムを確立、実施、維持し、継続的に改善することを要求している。^[18]^、^[19]^、^[20]

ISO/IEC 9001は、必要なプロセスとその相互作用に関する標準要件の定義において、他のどの管理システムのISO規格よりも条項4.4.1でより具体的であり、「組織は、組織全体にわたって適切な管理システムに必要なプロセスを決定し、適用しなければならない」^[18]と定義し、プロセスに関する詳細な要件も列挙しています。

必要な入力と期待される出力を決定する
順序と相互作用を決定する
効果的な運用と管理のための基準と方法（監視、測定、関連するパフォーマンス指標を含む）を定義して適用する
必要なリソースを決定する
責任と権限を割り当てる
リスクと機会に対処する
これらのプロセスを評価し、効果的な運用と管理に必要な変更を実施する
改善する

さらに、ISO/IEC 9001 の条項 4.4.2 には、プロセスに関するより詳細な要件がいくつか記載されています。

文書化された情報を維持する
正しい実装のために文書化された情報を保持する

必要なプロセスとその相互作用に関する標準要件の実装、特に適切な文書による標準要件の実装の証明 (ビジネスプロセスモデリング) は、一般的な慣行です。これは、文書化された情報に関する標準要件が、ISO 管理システムの一部としてのビジネスプロセスモデリングにも関連していることを意味します。

文書化された情報に関する管理システムの特定の標準要件

ISO/IEC 9001、ISO/IEC 14001、ISO/IEC 27001 規格では、文書化された情報に関する要件は、第 7.5 項に規定されています (各規格の「7.5.1. 一般」、「7.5.2. 作成と更新」、および「7.5.3. 文書化された情報の管理」の項で詳しく説明されています)。

ここで例として使用されている ISO/IEC 9001 の標準要件には、「7.5.1. 一般」の項が 含まれています。

標準要件に従って文書化された情報。
管理システムの有効性に関する文書化された情報を含める必要があります。

「7.5.2. 作成と更新」の項の要求

ラベル付けと説明（例：タイトル、日付、著者、参照番号など）
適切な形式（言語、ソフトウェアバージョン、グラフィックなど）と媒体（紙、電子など）
審査と承認

そして、「7.5.3. 文書化された情報の管理」の条項で 要求される。

必要に応じて、場所と時間に適切かつ利用可能であることを確保する。
保護を確実にするため（例：機密性の喪失、不適切な使用、完全性の喪失に対する保護）。
配布、アクセス、検索、使用を考慮する。
ファイリング・保管・保存（読みやすさの維持を含む）を考慮する。
変更の監視（バージョン管理など）を実行するため。
今後の所在の保管と処分について検討する。

標準要件に基づいて、

必要なプロセスとその相互作用を決定し、継続的に改善する
必要と思われる文書化された情報の内容を決定し維持し、
文書化された情報の安全な取り扱いを確保する（保護、アクセス、監視、保守）

管理システムの ISO 認証を準備することは、組織内でビジネスプロセスモデリングを確立または推進する非常に良い機会です。

ビジネスプロセスの最適化

Hermann J. Schmelzer と Wolfgang Sesselmann は、プロセス最適化の例として挙げられた 3 つの方法 (総サイクル時間 (TCT) の制御と短縮、カイゼン、シックスシグマ) の改善分野はプロセスであると指摘しています。総サイクル時間 (TCT) の場合、それはビジネスプロセス (エンドツーエンドのプロセス) とサブプロセスであり、カイゼンの場合はプロセスステップとアクティビティであり、シックスシグマの場合はサブプロセス、プロセスステップ、アクティビティです。^[2] ^{(第 6.3.1 章総サイクル時間 (TCT)、カイゼン、シックスシグマの比較) ← ドイツ語からの自動翻訳}

総サイクル時間（TCT）については、Hermann J. SchmelzerとWolfgang Sesselmannが以下の重要な特徴を挙げています。^[2] ^{（第6.3.2章総サイクル時間（TCT））←ドイツ語からの自動翻訳}

プロセスフローを妨げる障壁を特定する
障壁を排除し、プロセスを代替する
障壁除去の効果を測定する
測定変数と目標値の比較

したがって、TCT のビジネスプロセスモデリングでは、障壁、障壁の処理、および測定の適切なドキュメントをサポートする必要があります。

カイゼンツールを検討する際、最初はビジネスプロセスやビジネスプロセスモデリングに直接的なつながりはありません。しかし、カイゼンとビジネスプロセス管理は相互に強化することができます。ビジネスプロセス管理の領域では、カイゼンの目標はビジネスプロセスとサブプロセスの目標から直接導き出されます。この連携により、カイゼン対策が包括的なビジネス目標を効果的にサポートすることが保証されます。" ^[2] ^{(第6.3.3章カイゼン) ← ドイツ語からの自動翻訳}

シックスシグマは、エラーを防止し、プロセス能力を向上させるように設計されています。これにより、要件を満たすプロセス結果の割合が 6σ になります。つまり、100 万のプロセス結果に対して、3.4 のエラーしか発生しません。Hermann J. Schmelzer と Wolfgang Sesselmann は次のように説明しています。「企業は 4σ レベルでかなりの抵抗に遭遇することが多く、ビジネスプロセスリエンジニアリング (シックスシグマの設計) という意味でビジネスプロセスを再設計する必要があります。」^[2] ^{(第 6.3.4 章シックスシグマ) ← ドイツ語からの自動翻訳}プロセス能力を再現可能に測定するには、ビジネスプロセスに関する正確な知識が必要であり、ビジネスプロセスモデリングはシックスシグマの設計に適したツールです。したがって、シックスシグマでは、方法論の重要な部分としてSIPOCに従ったビジネスプロセスモデリングを使用しており、SIPOC を使用したビジネスプロセスモデリングは、シックスシグマの標準ツールとしての地位を確立しています。

企業間ビジネスプロセスモデリング

企業間ビジネスプロセスモデリングの目的は、分析に外部の利害関係者の影響を含めること、またはベンチマークを可能にするなど、企業間のビジネスプロセスの比較可能性を実現することです。

Martin Kuglerは、この文脈でビジネスプロセスモデリングの要件を次のように挙げています。^[21] ^{(第14.2.1章企業間ビジネスプロセスモデリングの要件) ← ドイツ語からの自動翻訳}

さまざまな企業の従業員はビジネスプロセスモデルを理解する必要があり、モデリング手法に精通していることが極めて重要です。ビジネスプロセスモデリングの受け入れは、表現のシンプルさによって強化されます。モデルは明快で、理解しやすく、可能な限り自明である必要があります。さまざまな企業間での企業間ビジネスプロセスモデルの表現の標準化は、特にさまざまな組織内で使用されるさまざまな表現を考慮すると、一貫した理解と受け入れを保証するために不可欠です。通常はさまざまな業界にまたがるバリューチェーン (サプライヤー、メーカー、小売業者、顧客) に沿った企業の多様な背景に対応するには、業界に依存しないモデリング手法を採用することが不可欠です。

トピック

事業活動の分析

フレームワーク条件を定義する

ビジネス活動の分析は、ビジネスプロセスモデリングを成功させるための枠組み条件を決定し定義します。企業が最初に行うべきことはここです。

ビジネスモデルとそれがバリューチェーンのどこに位置づけられるかに基づいて、ビジネスプロセスモデリングの関連するアプリケーションを定義する。
ビジネス戦略からビジネスプロセスモデリングの長期的な成功のための戦略を導き出し、

ビジネスプロセスモデルを構造化するためのアプローチを開発します。関連する目的と戦略の両方がプロセスマップに直接影響します。

ビジネスプロセスモデリングの長期的な成功のためのこの戦略は、市場指向の視点と/またはリソースベースの視点によって特徴付けられます。Jörg Becker と Volker Meise は次のように説明しています。「市場指向の視点では、業界と競合他社の行動が会社の戦略を直接決定しますが、リソース指向のアプローチでは、会社の強みと弱みを分析し、そこから戦略の開発の方向性を導き出すことによって、内部の視点を取り入れます。」^[7] ^{(第 4.6 章リソースベースの視点) ← ドイツ語からの自動翻訳}さらに、「文献で最初に定式化された市場ベースの視点とリソースベースの視点の代替特性は、現在では差別化された視点に取って代わられています。コアコンピタンスアプローチは、既存の市場指向のアプローチと並行して使用される、成功の可能性の説明に重要な貢献をしていると考えられています。」^[7]^{(第4.7章ビューの組み合わせ) ← ドイツ語からの自動翻訳したがって}、企業の戦略に応じて、プロセスマップは、市場開発を目的としたビジネスプロセスモデル、リソースの最適化を目的としたビジネスプロセスモデル、またはバランスのとれた方法になります。

ビジネスプロセスを特定する

識別フェーズに続いて、企業のビジネスプロセスは、それぞれのビジネスアクティビティの分析を通じて互いに区別されます (ビジネスプロセス分析も参照)。ビジネスプロセスは、特定の顧客または顧客グループに特定のサービスまたは製品 (特定の目標を達成するため) を提供することを目的とした、相互接続され組織化された一連のアクション (アクティビティ) で構成されます。

欧州ビジネスプロセスマネジメント協会（EABPM）によれば、現在のプロセスと目標との整合性についての共通理解を確立することが、プロセス設計またはリエンジニアリングの最初のステップとなります。" ^[1] ^{（第4章プロセス分析）←ドイツ語からの自動翻訳}

現状のプロセスを分析するための労力は、特にビジネスプロセスリエンジニアリング (BPR) の支持者によって文献で繰り返し批判されており、目標状態の定義を直ちに開始する必要があることが示唆されています。

一方、ヘルマン・J・シュメルツァーとヴォルフガング・ゼッセルマンは、文献でビジネスプロセスリエンジニアリング（BPR）の急進的なアプローチに向けられた批判について議論し、評価し、「現状分析を実施することを推奨します。再編成では、現在の弱点を把握して、それを排除できるようにする必要があります。分析の結果は、プロセスリエンジニアリングが必要な理由についても議論を提供します。現在の状態から目標状態への移行の初期状況を把握することも重要です。ただし、分析の取り組みは狭い範囲内にとどめる必要があります。分析の結果が再設計にあまり強く影響しないようにする必要があります。」^[2] ^{（第6.2.2章 BPRの批判的評価）←ドイツ語からの自動翻訳}

ビジネスプロセスの構造化 - プロセスマップの構築

Timo Füermannは次のように説明しています。「ビジネスプロセスが識別され、名前が付けられたら、それらを概要にまとめます。このような概要はプロセスマップと呼ばれます。」^[22] ^{（第2.4章プロセスマップの作成）←ドイツ語からの自動翻訳}

Jörg Becker と Volker Meise は、ビジネスプロセスを構造化するためのアクティビティのリストを次のように提供しています。

主なプロセスの列挙、
プロセス境界の定義、
各プロセスの戦略的関連性を判断し、
プロセスの改善の必要性の分析と
プロセスの政治的および文化的重要性の決定^[7] ^{（第4.10章プロセス構造の定義）←ドイツ語からの自動翻訳}

通常、ビジネスプロセスの構造化は、管理プロセス、コアプロセス、サポートプロセスを区別することから始まります。

管理プロセスは、企業の運営を統制します。一般的な管理プロセスには、コーポレートガバナンスと戦略管理が含まれます。これらのプロセスは、企業目標を定義し、目標の達成を監視します。
コアプロセスはコアビジネスを構成し、主要なバリューストリームを生み出します。典型的な運用プロセスは、購買、製造、マーケティング、販売です。これらは、目に見える直接的な顧客メリットを生み出します。
サポートプロセスは、運用リソースを提供および管理します。ビジネスオペレーションの円滑な実行を確保することで、コアプロセスと管理プロセスをサポートします。例としては、会計、採用、技術サポートなどがあります。

ビジネスプロセスモデリングの長期的な成功のための戦略に基づいてコアプロセスを構築する

コアビジネスプロセスが企業の特定されたビジネスプロセスの大部分を占めていることは明らかなので、コアプロセスを再度細分化することが一般的な慣行となっています。これには、企業やビジネス活動の種類に応じてさまざまなアプローチがあります。これらのアプローチは、ビジネスプロセスモデリングの定義された適用と、ビジネスプロセスモデリングの長期的な成功のための戦略によって大きく影響されます。

主に市場ベースの戦略の場合、エンドツーエンドのコアビジネスプロセスは、顧客またはサプライヤーから小売業者または顧客まで定義されることがよくあります (例: 「オファーから注文まで」、「注文から請求書まで」、「注文から納品まで」、「アイデアから製品まで」など)。リソースに基づく戦略の場合、コアビジネスプロセスは、企業の中心機能に基づいて定義されることがよくあります (「注文の獲得」、「材料の調達と提供」、「製品の開発」、「サービスの提供」など)。

市場ビューやリソースビューに明確に焦点を当てない差別化されたビューでは、コアビジネスプロセスは通常、CRM、PLM、SCM に分割されます。

CRM（顧客関係管理）は、顧客獲得、見積、注文作成、サポート、メンテナンスのビジネスプロセスを表します。
PLM（製品ライフサイクル管理）は、製品ポートフォリオ計画、製品計画、製品開発、製品保守から製品の廃止、個々の開発までのビジネスプロセスを説明します。
SCM（サプライチェーンマネジメント）は、サプライヤー管理から購買、すべての生産段階、顧客への配送まで、必要に応じて設置や試運転を含むビジネスプロセスを表します。

ただし、顧客、製品、販売チャネルの観点からコアビジネスプロセスを構築する他のアプローチも一般的です。

「顧客」は、特定の顧客グループ（個人顧客、ビジネス顧客、投資家、機関顧客など）に割り当てることができるビジネスプロセスを表します。
「製品」は、製品固有のビジネスプロセス（例：当座預金、証券口座、ローン、発行）を表します。
「販売チャネル」は、顧客獲得とサポートの種類 (直接販売、パートナー販売、オンラインなど) に典型的なビジネスプロセスを表します。

企業のビジネスプロセスを構造化すると、プロセスマップが作成されます(たとえば、バリューチェーン図として表示されます)。Hermann J. Schmelzer と Wolfgang Sesselmann は次のように付け加えています。「ビジネスプロセス間には接続と依存関係があります。これらはサービスと情報の転送に基づいています。ビジネスプロセスを理解、管理、制御するには、これらの相互関係を知ることが重要です。」^[2] ^{(第 2.4.3 章プロセスマップ) ← ドイツ語からの自動翻訳}

ビジネスプロセスの定義

製品開発の定義

ビジネスプロセスの定義は、多くの場合、企業のコアプロセスから始まる。

自らの市場要件を満たす、
他の事業分野から独立して、ほぼ自律的に運営し、
会社の事業の成功に貢献し、

会社にとって

外部に強い影響力を持ち、
他のビジネスプロセスと簡単に区別でき、
プロセスのパフォーマンスや生産性の向上とコストの削減の両方により、ビジネスプロセス最適化の最大の可能性を提供します。

ビジネスプロセスの範囲は、管理可能な数のサブプロセスを含み、同時にビジネスプロセスの総数を妥当な範囲内に抑えるように選択する必要があります。通常、ビジネスユニットごとに 5 ～ 8 個のビジネスプロセスで、企業のパフォーマンス範囲をカバーできます。

各ビジネスプロセスは独立している必要がありますが、プロセスは相互にリンクされています。

ビジネスプロセスの定義には、完了時にどのような結果を達成する必要があるか、これを達成するにはどのようなアクティビティが必要か、どのオブジェクトを処理する必要があるか (注文、原材料、購入、製品など) が含まれます。

変化を受け入れる傾向が強い企業文化と、現状維持とコミュニケーションの有効性を守る傾向が強い企業文化のどちらであるかによって、ビジネスプロセスの定義は簡単になることもあれば、難しいこともあります。これは、部門長など、組織内の主要な関係者が取り組みを支援する意思があるかどうかにかかっています。この文脈では、効果的なコミュニケーションが極めて重要な役割を果たします。

この点を明らかにするにあたり、Jörg Becker と Volker Meise は、組織設計イニシアチブにおけるコミュニケーション戦略は、意図された構造的変更に対する組織のメンバーの支持を集めることを目標とすべきであると説明しています。ビジネスプロセスモデリングは通常、プロセス組織の再構成を伴うビジネスプロセス最適化に先行するものであり、関係者はこれを十分に理解しています。したがって、コミュニケーション戦略は、計画された構造的調整を組織のメンバーに承認するよう説得することに焦点を当てる必要があります。" ^[7] ^{(第 4.15 章規制フレームワークの設計への影響) ← ドイツ語からの自動翻訳}ただし、かなりの抵抗がある場合は、外部の知識を使用してビジネスプロセスを定義することもできます。

一般的なプロセス識別と個別のプロセス識別

Jörg Becker と Volker Meise は、 2 つのアプローチ (一般プロセス識別と個別プロセス識別) を挙げ、一般プロセス識別について次のように述べています。「一般プロセス定義では、すべての企業で同じ基本的で一般的に有効なプロセスが存在すると想定されます。」さらに、「詳細な参照モデルも一般プロセス識別に使用できます。詳細な参照モデルは、組織の業界またはアプリケーションシステム固有のプロセスを記述しますが、個々のケースに適応させる必要はありますが、構造的にはすでに調整されています。」^[7] ^{(第 4.11 章一般プロセス識別) ← ドイツ語からの自動翻訳}

ヨルグ・ベッカーとフォルカー・マイゼは、個別プロセス識別について次のように述べています。「個別または単一プロセス識別では、各企業のプロセスは顧客のニーズや競争状況に応じて異なり、個別の問題状況に基づいて帰納的に識別できると想定されます。」^[7] ^{（第4.12章個別プロセス識別）←ドイツ語からの自動翻訳}

ビジネスプロセスの定義の結果は、通常、バリューチェーン図のようなビジネスプロセスの大まかな構造になります。

ビジネスプロセスのさらなる構造化

ビジネスプロセスをサブプロセスに分解する例 - マイルストーン、ビジネスユニット、データオブジェクト、IT システムによって補完されます

これまでに作成したビジネスプロセスの大まかな構造は、独自の属性を持ちながらもビジネスプロセスの目標達成にも貢献するサブプロセスに分割することで分解されます。この分解は、ビジネスプロセスモデリングの長期的な成功のためのアプリケーションと戦略によって大きく左右されるはずであり、このように定義されたサブプロセスの調整が目的と戦略の実現に貢献する限り継続する必要があります。

このようにして作成されたサブプロセスは、モデルを使用して、会社の意図された運用目標を達成するために手順を実行する方法を記述します。モデルは現実 (または目標状態) を抽象化したものであり、その具体的な形式は意図された使用 (アプリケーション) によって異なります。

必要に応じて、ビジネスプロセスモデリング中にサブプロセスをさらに分解できます。ビジネスプロセスをマイルストーンで区切られた一連のフェーズとして表現できる場合は、フェーズへの分解が一般的です。可能な場合は、マイルストーンを次のレベルの分解に転送すると、全体的な理解に役立ちます。

ビジネスプロセスをさらに構造化すると、通常はサブプロセスの階層が形成され、バリューチェーン図で表現されます。すべてのビジネスプロセスが同じ深さに分解されるわけではありません。特に、安全性に関連せず、コストがかからず、運用目標にも貢献しないビジネスプロセスは、はるかに浅い深さに分解されます。同様に、(ずっと)後で計画されるプロセスの分解の準備段階として、バリューチェーン図よりも単純で複雑でない手段、たとえばテキストによる説明やタートル図^[22] ^{(第 3.1 章プロセスの詳細の定義) ← ドイツ語からの自動翻訳(}タートルグラフィックと混同しないでください) を使用して、まず共通の理解を深めることができます。

プロセス責任の割り当て

完全な自己完結型プロセスがまとめられ、責任者またはチームに引き渡されます。プロセス所有者は成功の責任を負い、フレームワーク条件を作成し、他のプロセス所有者のアプローチと自分のアプローチを調整します。さらに、ビジネスプロセス間の情報交換も担当します。この調整は、全体的な目標指向を実現するために必要です。

ビジネスプロセスのモデリング

プロセスチェーンの設計

ビジネスプロセスが特定の IT システムと表現 (たとえばグラフィカル) を使用して文書化される場合、これは一般にモデリングと呼ばれます。文書化の結果がビジネスプロセスモデルです。

モデリングとモデリング

ビジネスプロセスモデルをそのままのモデリングで作成するか、またはモデリングする予定かという問題は、定義されたアプリケーションと、ビジネスプロセスモデリングの長期的な成功のための戦略によって大きく左右されます。いずれの場合も、ビジネスアクティビティの分析、ビジネスプロセスの定義、およびビジネスプロセスのさらなる構造化を伴う前の手順が推奨されます。

現状のままのモデリング

アンスガー・シュヴェーグマンとマイケル・ラスケは次のように説明しています。「現状を把握することは、弱点を特定し、改善の余地がある箇所を特定するための基礎となります。たとえば、組織的な崩壊や不十分なIT浸透などの弱点を特定できます。」^[23] ^{（第5章1「現状のままのモデリングの意図」）←ドイツ語からの自動翻訳}

モデリングには次のような欠点があります。

下流のターゲットモデリングや設計に反映されることなく古い構造やプロセスが採用される可能性があるため、最適なターゲットプロセスを開発するプロジェクト関係者の創造性が抑制される。
詳細な現状モデルの作成には相当の労力が必要であり、インターフェースや責任の移行においてプロジェクト参加者間で合意に達するために必要な労力も影響します。

ビジネスプロセスリエンジニアリング (BPR) がいずれにせよ計画されている場合、これらの議論は特に重要になります。

アンスガー・シュヴェーグマンとマイケル・ラスケも、アズ・イズ・モデリングの利点をいくつか挙げている。^[23] ^{（第5章1 アズ・イズ・モデリングの目的）←ドイツ語からの自動翻訳}

現状をモデル化することは、弱点と改善の可能性を特定するための基礎となります。
現在の状態に関する知識は、目標状態への移行戦略を策定するための前提条件である。
現在の状態をモデル化することで、既存の状況の概要がわかり、これは特に新しくプロジェクトに関与する人や外部の参加者にとって有益です。
現状のモデリングは、プロジェクト参加者にツールや手法をトレーニングし、紹介するための出発点となり得る。
現状モデルは、関連する問題が見落とされないように、後のターゲットモデリングのチェックリストとして機能します。
現状モデルは、少なくとも一部の領域において、ターゲットの状態が現在の状況と非常に類似している場合、ターゲットモデリングの開始モデルとして使用できます。

他にも次のような利点があります。

現状モデルは管理システムの認証をサポートするのに適しています
現状モデルは、組織の文書化（組織の書面による規則、仕様、規制など）の基礎として機能します。
ワークフロー管理の要件は、現状のモデルに基づいて確認できます(プロセスの定義、繰り返し率など)
現状モデルに基づいて主要な数値を収集し、再編後に達成された主要な数値と比較し、対策の成功を測定することができます。

モデルになる

Mario Speck と Norbert Schnetgöke は、 to beモデリングの目的を次のように定義しています。「ターゲットプロセスは、会社の戦略目標に基づいています。つまり、会社のすべてのサブプロセスと個々のアクティビティは、ターゲットへの貢献度の観点から分析する必要があります。したがって、付加価値として識別できず、少なくとも 1 つの非金銭的な企業目標に役立たないサブプロセスまたはアクティビティは、ビジネスプロセスから排除する必要があります。」^{[8] (第 6.2.3 章} ^{to be}^{モデルのキャプチャとドキュメント化)}

また、モデルの作成においてその価値が証明されている 5 つの基本原則も挙げています。

サブプロセスと個々のアクティビティの並列処理は、順次処理よりも優先されます。並列処理の方が、最適化の可能性が高くなります。
サブプロセスの開発は、1 人の人物またはグループによって可能な限り一貫して実行する必要があります。これにより、最高のモデル品質が達成されます。
処理中の個々のサブプロセスと個々のアクティビティに対して自己監視を可能にする必要があります。これにより、品質保証コストが削減されます。
他の方法では不可能な場合は、各プロセスに対して少なくとも 1 人の内部顧客/ユーザーを定義する必要があります。これにより、顧客の認識が強化され、プロセスパフォーマンスの評価可能性が向上します。
対象プロセスの導入中に生じる学習効果を考慮する必要があります。これにより、従業員の価値創造に対する意識が強化されます。

現状モデリングまたはモデリング予定によって作成されたビジネスプロセスモデルは、次の要素で構成されます。

サブプロセス

境界設定

ビジネスプロセスの内訳フェーズに基づいて販売パイプラインをサブプロセスに処理する

August W. Scheer は講義で「プロセスはプロセスであり、プロセスである」と述べたと言われています。これは、用語の再帰性を表現することを意図しています。なぜなら、ほぼすべてのプロセスは、より小さなプロセス (サブプロセス) に細分化できるからです。この点で、ビジネスプロセス、メインプロセス、サブプロセス、基本プロセスなどの用語は、プロセス分解のレベルに名前を付けるための必死の試みにすぎません。ビジネスプロセス、メインプロセス、サブプロセス、基本プロセスの粒度に関する普遍的に有効な合意はないため、これらの用語は普遍的に定義されておらず、それぞれのビジネスプロセスモデルのコンテキストでのみ理解できます。

さらに、ドイツ語圏のビジネス情報学の学派の中には、プロセス（一連のアクションを表すという意味）や機能（企業機能の所有者に明確に割り当てられた、区切られた企業機能/アクション（アクティビティ）領域の意味で）という用語を使用しないところもあります。

典型的な企業活動の抜粋、*販売パイプライン*に関連する機能がマークされた機能ツリー

たとえば、August W. Scheer の ARIS では、機能ビューの機能を制御ビューのプロセスとして使用したり、その逆を行ったりすることができます。これには、すでに定義されているプロセスや機能を全面的に再利用できるという利点がありますが、機能ビューの本来の目的が薄れ、ARIS ユーザーがプロセスと機能を互いに分離できなくなることも意味します。

最初の画像は、ビジネスプロセス「販売パイプラインの編集」が、そのフェーズに基づいてサブプロセス(アクション (アクティビティ) のシーケンスを表すという意味) に分割されている様子をバリューチェーン図として示しています。

2 番目の画像は、能力と責任の階層に基づいて構造化された、一般的な機能(企業機能所有者に割り当てられている、区切られた企業機能/ アクション (アクティビティ) 領域の意味で) の抜粋を示しています。ビジネスプロセス「販売パイプラインの編集」をサポートする企業機能は、機能ツリーにマークされています。

利用

ビジネスプロセスは、それ以上の分解が意味をなさなくなる/不可能になるまでサブプロセスに分解できます (意味のある最小のサブプロセス =基本プロセス)。通常、ビジネスプロセスの分解のすべてのレベルは、プロセスシンボルという同じ方法論で文書化されます。1 つの分解レベルをモデル化するときに使用されるプロセスシンボルは、基本プロセスのレベルに達するまで、通常、次のレベルのサブプロセスを参照します。バリューチェーン図は、ビジネスプロセス、メインプロセス、サブプロセス、基本プロセスを表すためによく使用されます。

ワークフロー

ワークフローは、人、単純または複雑なメカニズム、人々のグループ、^[24]スタッフの組織、または機械（ITシステムを含む）の仕事として宣言された一連のタスクの表現です。したがって、ワークフローは常に基本プロセスレベルにあります。ワークフローは、実際の作業を抽象化したもの、ワークシェア、作業分割、またはその他の種類の順序に分離したものと見なすことができます。制御の目的で、ワークフローは、選択した側面での実際の作業のビューである場合があります。

機能（タスク）

境界設定

機能という用語は、多くの場合、企業機能所有者に割り当てられる限定された企業機能/アクション (アクティビティ) 領域と、基本プロセスレベルの原子アクティビティ (タスク)の同義語として使用されます。機能という用語の二重の意味を避けるために、 BPMN の命名に従って、基本プロセスレベルの原子アクティビティにタスクという用語を使用できます。最新のツールでは、タスクをプロセスに自動的に変換する機能も提供されているため、いつでもさらに次のレベルのプロセス分解を作成できます。その場合、タスクを基本プロセスにアップグレードする必要があります。

利用

基本プロセスのレベルで使用されるグラフィカル要素は、関数 (タスク) の助けを借りて (時間的論理的) シーケンスを記述します。基本プロセス内の関数 (タスク) のシーケンスは、入出力関係またはマイルストーンによってまだ指定されていない限り、論理演算子またはゲートウェイによる相互の論理リンクによって決定されます。プロセスをより明確にするために、インターフェイス、状態 (イベント)、条件 (ルール)、マイルストーンなどを示す追加のグラフィカル要素を使用するのが一般的です。使用するモデリングツールに応じて、非常に異なるグラフィカル表現 (モデル) が使用されます。

プロセスモデルの可読性を維持するために、マスターデータを別のビューにアウトソーシングするための機能**割り当て**図( FAD)のサンプル

さらに、機能 (タスク) には、説明の正確さを向上させたり詳細の数を増やしたりすることを目的として、入力、出力、システム、役割などを説明するグラフィカル要素を追加することができます。ただし、これらの追加により、モデルはすぐにわかりにくくなります。説明の正確さと明瞭さの矛盾を解決するには、主に 2 つの解決策があります。入力、出力、システム、役割などを説明する追加のグラフィカル要素を機能割り当て図 (FAD) にアウトソーシングするか、質問やアプリケーションに応じてこれらの要素を選択的に表示/非表示にします。

画像に示す機能割り当て図は、機能（タスク）に入力、出力、システム、役割などを説明するグラフィカル要素が追加されていることを非常によく示しています。

マスターデータ（成果物）

マスターデータという用語は、The Open Group ( The Open Group Architecture Framework、TOGAF) やJohn A. Zachman (Zachman Framework)、あるいはドイツ語圏の 5 つのビジネス情報学の学派 (1) August W. Scheer、2) Hubert Österle、3) Otto K. Ferstl および Elmar J. Sinz、4) Hermann Gehring、5) Andreas Gadatsch のいずれによっても定義されておらず、文献に適切な用語がない場合によく使用されます。これは、運用上関連するオブジェクトに関する基本情報を表すデータに対する一般用語に基づいており、ビジネスプロセスの主要情報ではない基本情報を指します。

ARISのAugust W. Scheerにとって、これは組織ビュー、データビュー、機能ビュー、パフォーマンスビューの基本情報です。^[25] ^{（第1章ビジョン：ITと管理の共通言語）←ドイツ語からの自動翻訳}

Andreas Gadatsch の GPM (ドイツ語: G anzheitliche Prozess modellierung 、全体論的プロセスモデリング)では、これは組織構造ビュー、アクティビティ構造ビュー、データ構造ビュー、アプリケーション構造ビューの基本情報となります。 ^[3] ^{(第 3.2 章 GPM - 全体論的プロセスモデリング) ← ドイツ語からの自動翻訳}

SOM (セマンティックオブジェクトモデル) の Otto K. Ferstl と Elmar J. Sinz にとって、これはビジネスプランレベルとリソースレベルの基本情報になります。

マスターデータの例:

プロセスが実行される責任範囲の事業部門
プロセスを実行するために情報が必要なビジネスオブジェクト
プロセスによって生産される製品
プロセスを実行する際に遵守すべきポリシー
プロセスで発生するリスク
工程能力を高めるために実施される対策
プロセスのガバナンスを確保するために実行される制御
ビジネスプロセスの実行をサポートするITシステム
プロセスをプロセスフェーズに分割するマイルストーン
等

ビジネスプロセスモデリングにマスターデータを追加することで、同じビジネスプロセスモデルをさまざまなアプリケーションに使用できるようになり、その結果得られる相乗効果により、ビジネスプロセスモデリングの投資収益をより迅速に達成できます。

ビジネスプロセスモデリングでマスターデータにどの程度の価値を与えるかに応じて、モデルの可読性に悪影響を与えることなくマスターデータをプロセスモデルに埋め込むことも可能です。あるいは、マスターデータを機能割り当て図などの別のビューにアウトソーシングする必要があります。

マスターデータがビジネスプロセスモデルに体系的に追加される場合、これはアーティファクト中心のビジネスプロセスモデルと呼ばれます。

成果物中心のビジネスプロセス

成果物中心のビジネスプロセスモデルは、ビジネスプロセスの運用仕様をキャプチャするための非常に柔軟なソリューションを提供するため、ビジネスプロセスをモデリングするための総合的なアプローチとして登場しました。特に、ビジネス関連のデータオブジェクト、そのライフサイクル、および関連サービスを特徴付けることで、「成果物」と呼ばれるビジネスプロセスのデータを記述することに重点を置いています。成果物中心のプロセスモデリングアプローチは、ビジネス操作の自動化を促進し、ワークフローの制定と進化の柔軟性をサポートします。^[26]

外部文書とITシステムの統合

外部ドキュメントと IT システムを統合すると、ビジネスプロセスモデルの付加価値が大幅に高まります。

たとえば、ナレッジデータベース内のオブジェクトやルールフレームワーク内のドキュメントに直接アクセスすると、日常生活におけるビジネスプロセスモデルの利点が大幅に向上し、ビジネスプロセスモデリングの受け入れが促進されます。関係するすべての IT システムは、それぞれの固有の利点を活用し、相互に補完し合うことができます (たとえば、相互にリンクしたり、ファイル構造を標準化したりします)。

知識データベースの応答時間が短い。監査人の数が比較的多い、コンテンツの適応が非常に速い、コンテンツの公開要件が低い（例えばウィキで実現）などの特徴がある。
ルールフレームワークの法的に準拠した文書。非常に少数の特別に訓練された監査人、検証されたコンテンツの適応、およびコンテンツのリリースに対する高い要件（たとえば、文書管理システムで実装）を特徴とする。
BPM システムによるプロセスのグラフィカルな表現の統合。監査人の数が中程度、コンテンツの適応が中程度に速く、コンテンツのリリース要件が中程度であることを特徴とする。

ナレッジデータベースのすべての関連オブジェクトおよび/またはルールフレームワークのドキュメントがプロセスに接続されている場合、エンドユーザーはコンテキストに関連したこの情報にアクセスでき、接続されたシステムのそれぞれのファイル構造に精通している必要はありません。

外部システムを直接接続すると、現在の測定結果やシステムステータスをプロセスに統合したり (たとえば、プロセスの現在の動作ステータスを表示したり)、ウィジェットを表示して外部システムからの出力を表示したり、外部システムにジャンプして事前設定されたダイアログでトランザクションを開始したりすることもできます。

外部システムへのさらなる接続は、たとえば電子データ交換(EDI) に使用できます。

モデルの統合

これは、冗長性があるかどうかをチェックすることです。冗長性がある場合、関連するサブプロセスが結合されます。または、複数回使用されるサブプロセスは、サポートプロセスにアウトソースされます。モデル統合を成功させるには、サブプロセスの元の分解を修正する必要があるかもしれません。

アンスガー・シュヴェーグマンとマイケル・ラスケは次のように説明しています。「統合されたモデルを得るためには、異なるモデリング複合体のモデルを統合する必要があります。」^[23] ^{（第5.2.4章モデルの統合）←ドイツ語からの自動翻訳}彼らはまた、モデルの統合が重要であるいくつかの側面を列挙しています。

「モデリングチームは、後の統合を容易にするために、モデル作成中にモデルの調和を推進する必要があります。」
「問題領域のオブジェクト指向分解を実行する場合、異なるオブジェクトの類似の構造とプロセスが存在するかどうかを早い段階で分析する必要があります。」
「問題領域の機能指向分解を行う場合、特にモデル化された領域間のインターフェースを調和させる必要があります。」
「一般に、サブモデルの比較可能性とインターフェースの正確な定義を容易にするために、モデリング中にモデルの詳細レベルを均一にすることを目指す必要があります」（各分解レベル）。
「個々のモデリング複合体のチームによるモデリング活動が完了した後、作成された部分モデルは全体モデルに統合されます。」
「マッピングされたプロセスの追跡可能性を容易にするために、会社にとって特に重要な選択されたビジネストランザクションを明示的にモデル化し、それらをトップレベルでマッピングすることは理にかなっています。...たとえば、色分けを使用して、関連する組織単位を区別することもできます。」^[23] ^{（第5.2.4章モデルの統合）←ドイツ語からの自動翻訳}

プロセス連鎖と制御フローパターン

サブプロセス間の連鎖とサブプロセス内の機能 (タスク) の連鎖は、制御フローパターンを使用してモデル化されます。

連鎖の重要な詳細 (先行プロセスが後続プロセスに提供するものは何ですか?) は、意図されている場合、プロセスインターフェイスで指定されます。

プロセスインターフェース

プロセスインターフェースは、

ビジネスプロセスを分解した後のサブプロセス間の関係を示すか、
ビジネスプロセスまたはそのサブプロセスが互いに何を「渡す」必要があるかを決定します。

原則として、この「何」とその構造は、後続のプロセスの要件によって決まります。

プロセスインターフェイスは、現在のビジネスプロセス/サブプロセスからの終了と、後続のビジネスプロセス/サブプロセスへの開始を表します。

EPC 構文 (上) と BPMN 構文 (下) のサービスプロセスへのインターフェイスを備えたプロセスフロー

プロセスインターフェースは、プロセスをセクションごとにリンクするための記述要素です。プロセスインターフェースは、

参照先のビジネスプロセスモデルがまだ定義されていない状態で、ビジネスプロセスモデル/サブプロセスモデルを表します。
2 つまたは複数の上位または隣接するビジネスプロセスモデルから参照されるビジネスプロセスモデル/サブプロセスモデルを表します。
同じビジネスプロセスモデル/サブプロセスモデルの 2 つまたは複数のバリアントを表します。

プロセスインターフェイスは、上位/下位または隣接するビジネスプロセスモデルの参加者間で合意されます。プロセスインターフェイスは一度定義およびリンクされ、プロセスモデルで必要な回数だけ使用されます。

インターフェースは次のように定義できます。

ある事業部門から別の事業部門への責任/説明責任の移管、
あるITシステムから別のITシステムへのデータの転送、
オリジナルインプット（ビジネスプロセス開始時の情報・資料）、
サブプロセス間の中間結果の転送（先行プロセスの出力と後続プロセスの入力は通常同一である）または
最終出力（ビジネスプロセスの実際の結果/目標）。

実際には、転送される入力/出力はデータまたは情報であることが多いですが、その他のビジネスオブジェクトも考えられます (材料、最終または半完成状態の製品、納品書などの文書)。これらは適切な転送メディア (データの場合はデータストレージなど) を介して提供されます。

ビジネスプロセス管理

記事「ビジネスプロセス管理」を参照してください。

改善されたビジネスプロセスを実践するには、通常、変更管理プログラムが必要です。ソフトウェア設計の進歩により、BPM モデルが完全に実行可能 (シミュレーションとラウンドトリップエンジニアリングが可能) になるというビジョンが現実に近づきつつあります。

プロセスモデルの適応

ビジネスプロセス管理では、プロセスフローは定期的に確認され、必要に応じて最適化 (適応) されます。プロセスフローの適応が継続的なプロセス改善によって開始されるか、プロセスの再編成 (ビジネスプロセスリエンジニアリング) によって開始されるかに関係なく、個々のサブプロセスまたはビジネスプロセス全体の更新が伴います。

表現の種類と表記

実際には、非公式モデル、半公式モデル、公式モデルの組み合わせが一般的です。説明のための非公式テキスト記述、視覚化のための半公式グラフィカル表現、シミュレーションをサポートし実行可能コードに転送するための形式言語表現です。

モデリング技術

表記にはさまざまな標準がありますが、最も一般的なものは次のとおりです。

ビジネスプロセスモデルと表記法（BPMN）は、2002年にStephen A. Whiteによって提案され、Business Process Management Initiativeによって公開されました。2005年6月にObject Management Groupと統合されました。
イベント駆動型プロセスチェーン（EPC）は、1992年にアウグスト＝ヴィルヘルム・シェアーのリーダーシップの下でワーキンググループによって提案されました。
付加価値連鎖図（VAD）は、主に高レベルの抽象化でプロセスを視覚化します。
ペトリネットは、 1962年にカール・アダム・ペトリによって開発された。
1997年にフィッシャーマンズとリーベルトによって提案されたフォローアップ計画（例えばフローチャートの具体的な形式）
HIPO モデルは、IBM が 1970 年頃にソフトウェアの設計支援およびドキュメント化技術として開発したモデルです (技術的ではないが、ビジネス指向の形式)。
ライフサイクルモデリング言語（LML）は、もともとLML運営委員会によって設計され、2013年に公開されました。
主題指向ビジネスプロセス管理(S-BPM)
認知強化自然言語情報分析法(CogNIAM)
SIPOC図は、1980年代に総合的品質管理運動の一環として発明され、その後リーンマネジメントやシックスシグマの実践者によって採用されました。
統一モデリング言語(UML) は、1996 年にGrady Booch、Ivar Jacobson、James Rumbaughによって提案され、OMG の支援の下で継続的に改訂されています (ビジネスプロセスの拡張機能を提供します)。
ICAM DEDefinition ( IDEF0 ) は、1980年代初頭に米国空軍向けに開発された。
形式化された行政記法 (FAN) は、1990年代にパブロ・イアクーブとレオナルド・マヨによって作成されました。
ハーバリアンプロセスモデリング(HPM)
ビジネスプロセス実行言語(BPEL) は、ビジネスプロセスの記述と自動化のためにOASISによって 2002 年に開発された XML ベースの言語です。
タートル図（タートル法、タートルモデル、8W法とも呼ばれる）、プロセスに関する事実をシンプルで明確かつ分かりやすくグラフィカルに表現したもの

さらに：

コミュニケーション構造分析は、1989 年にベルリン工科大学のシステム分析学部のヘルマン・クラルマン教授によって提案されました。
拡張ビジネスモデリング言語（xBML）^[27]（創設企業がオンラインではないため、時代遅れのようです^[28]）
1995 年にuta Fahrwinkel によって提示されたOMEGA (ビジネスプロセスモデリングと分析のためのオブジェクト指向手法、O bjektorientierte Me thode zur G eschäftsprozessmodellierung und - a nalyse in Germany)による表記^[29]
セマンティックオブジェクトモデル（SOM）は、1990年にOtto K. FerstlとElmar J. Sinzによって提案されました。
PICTURE-行政におけるビジネスプロセスの文書化とモデリングの方法
データフロー図、プロセスまたはシステムを通るデータの流れを表す方法
スイムレーン技法は、主にBPMNで知られていますが、SIPOC、プロセスチェーン図（PCD）などの方法でもこの技法が使用されています。
ビジネスエンジニアリングのためのメソッドセット ProMet
状態図、システムの動作を説明するために使用される

さらに、ソフトウェアアーキテクチャの表現タイプも使用できます。

フローチャート、1966 年 9 月から DIN 66001 で標準化され、1983 年 12 月に最終改訂、または1985 年からISO 5807で標準化されました。
ナッシ・シュナイダーマン図または構造図は、1972/73 年にアイザック・ナッシとベン・シュナイダーマンによって提案され、DIN 66261 で標準化されました。

ビジネスプロセスモデルと表記法 (BPMN)

ビジネスプロセスモデルと表記法(BPMN) は、ビジネスプロセスモデルでビジネスプロセスを指定するためのグラフィカルな表現です。

BPMNはもともとビジネスプロセスマネジメントイニシアチブ（BPMI）によって開発されましたが、2005年に2つの組織が合併して以来、オブジェクトマネジメントグループ（OMG）によって維持されています。BPMNのバージョン2.0は2011年1月にリリースされましたが、 ^[30]その時点で、既存の表記法と図表要素とともに導入された実行セマンティクスの導入を反映して、名前がビジネスプロセスモデルと表記法に変更されました。OMG仕様ではありますが、BPMNはISO 19510としても承認されています。最新バージョンは2014年1月に公開されたBPMN 2.0.2です。^[31]

イベント駆動型プロセスチェーン (EPC)

イベント駆動型プロセスチェーン(EPC) は、ビジネスプロセスモデリング用のフローチャートの一種です。EPC は、エンタープライズリソースプランニングの実行を構成したり、ビジネスプロセスの改善に使用できます。また、ワークシェアリングにおける自律的なワークフローインスタンスを制御するためにも使用できます。

イベント駆動型プロセスチェーン手法は、初期にザールラント大学ビジネス情報システム研究所のアウグストヴィルヘルムシェアーによって統合情報システムアーキテクチャ(ARIS)の枠組み内で開発されました。 1990年代。^[32]

ペトリネット

ペトリネットは、場所/遷移ネット (PT ネット) とも呼ばれ、分散システムを記述するための数学的モデリング言語の 1 つです。離散イベント動的システムの一種です。ペトリネットは、場所と遷移という 2 種類の要素を持つ有向二部グラフです。場所要素は白い円で表され、遷移要素は長方形で表されます。場所には、黒い円で表されたトークンをいくつでも含めることができます。遷移は、入力として接続されているすべての場所に少なくとも 1 つのトークンが含まれている場合に有効になります。一部の情報源^{[33]によると、ペトリネットは 1939 年 8 月に 13 歳の}Carl Adam Petriによって化学プロセスを記述する目的で発明されました。

UML アクティビティ図、ビジネスプロセスモデルと表記法、イベント駆動型プロセスチェーンなどの業界標準と同様に、ペトリネットは、選択、反復、同時実行を含む段階的なプロセスのグラフィカル表記法を提供します。これらの標準とは異なり、ペトリネットでは実行セマンティクスが正確に数学的に定義されており、プロセス分析のための十分に開発された数学理論があります^[^{引用が必要}^]。

フローチャート

フローチャートは、ワークフローまたはプロセスを表す図の一種です。フローチャートは、タスクを解決するための段階的なアプローチであるアルゴリズムを図式的に表現したものとしても定義できます。

フローチャートは、ステップをさまざまな種類のボックスで示し、ボックスを矢印で接続して順序を示します。この図式表現は、特定の問題に対する解決モデルを示しています。フローチャートは、さまざまな分野でプロセスやプログラムの分析、設計、文書化、管理に使用されます。^[34]

階層的入力プロセス出力モデル (HIPO)

HIPOモデル（階層的入力プロセス出力モデル）は、1970年代のシステム分析設計支援および文書化技術であり、 ^[35]システムのモジュールを階層として表現し、各モジュールを文書化するために使用されます。^[36]^[37]

ライフサイクルモデリング言語 (LML)

ライフサイクルモデリング言語（LML）は、システムエンジニアリング用に設計されたオープンスタンダードのモデリング言語です。概念、利用、サポート、廃止の各段階を含むライフサイクル全体をサポートします。プログラム管理、システムおよび設計エンジニアリング、検証と妥当性確認、展開、保守を含むすべてのライフサイクル分野を1つのフレームワークに統合します。 ^[38] LMLはもともとLML運営委員会によって設計されました。仕様は2013年10月17日に公開されました。

これはUMLやSysMLのようなモデリング言語であり、リスク分析やスケジュールなどの追加のプロジェクト管理用途をサポートします。LMLは共通言語を使用して、エンティティ、属性、スケジュール、コスト、関係などのモデリング要素を定義します。^[39]

主題指向のビジネスプロセス管理

サブジェクト指向ビジネスプロセス管理（S-BPM）は、ビジネスプロセスのオーケストレーションまたは振り付けを構成するアクター（サブジェクト）に対するコミュニケーションベースのビューです。 ^[40]モデリングパラダイムは、5つのシンボルを使用して任意のプロセスをモデル化し、実行可能な形式に直接変換できるようにします。

各ビジネスプロセスは、メッセージを交換する2 つ以上のサブジェクトで構成されます。各サブジェクトには内部動作(カプセル化) があり、これはメッセージの受信と送信、および何らかの処理という異なる状態間の制御フローとして定義されます。実際の使用と構文の糖衣化のために、さらに多くの要素を使用できますが、必須ではありません。

2011 年と 2012 年に、S-BPM はGartner のハイプサイクルに含まれました。

認知強化型自然言語情報分析法

認知強化型自然言語情報分析法 (CogNIAM) は、データ、ルール、プロセス、セマンティクスなど、知識のさまざまな次元を統合することを目的とした概念的な事実ベースのモデリング手法です。これらの次元を表現するために、オブジェクト管理グループ( OMG )の世界標準であるSBVR、BPMN、DMN が使用されます。NIAM の後継である CogNIAM は、知識科学者Sjir Nijssenの研究に基づいています。^[^{引用が必要}^]

CogNIAMは人、文書、ソフトウェアから集められた知識を分類して構造化します。この目的のために、CogNIAMはいわゆる「知識の三角形」を使用します。^{[41] CogNIAMの結果は、それを適用する人に依存しません。結果として得られるモデルにより、知識を}図式形式だけでなく、制御された自然言語でも表現できます。^[42]

SIPOC（サプライヤー、入力、プロセス、出力、顧客）

プロセス改善において、SIPOCまたはサプライヤー、入力、プロセス、出力、顧客（逆の順序：COPIS）は、1つまたは複数のビジネスプロセスの入力と出力を表形式でまとめるツールであり、各単語が分析で使用される表の列を形成します。^[43]^[44]これは、プロセス改善の作業を開始する前に、ビジネスプロセスを最初から最後まで定義するために使用されます。^[要出典]

統一モデリング言語 (UML)

統一モデリング言語（UML）は、システムの設計を視覚化する標準的な方法を提供することを目的とした汎用ビジュアルモデリング言語です。 ^[45]

UML は、多くの種類の図の標準表記法を提供します。これらの図は、動作図、相互作用図、構造図の 3 つの主要なグループに大まかに分類できます。

UMLはもともと、ソフトウェア設計におけるさまざまな表記法やアプローチを標準化したいという思いから生まれた。 1994年から1995年にかけてRational Software社で開発され、1996年まで同社が主導して開発が進められた。^[46]

1997年、UMLはオブジェクト管理グループ（OMG）によって標準として採用され、それ以来この組織によって管理されてきました。2005年には、UMLは国際標準化機構（ISO）と国際電気標準会議（IEC）によってISO/IEC 19501標準として発行されました。^[47]それ以来、この標準は定期的に改訂され、UMLの最新版をカバーしています。^[48]

ソフトウェアエンジニアリングでは、ほとんどの専門家はUMLを使用せず、代わりに非公式の手描きの図を作成します。ただし、これらの図にはUMLの要素が含まれていることがよくあります。^[49]^{: 536}

統合定義 (IDEF)

IDEF は、当初は ICAM Definition の略称で、1999 年に Integration Definition に改名された、システムおよびソフトウェアエンジニアリングの分野におけるモデリング言語のファミリーです。機能モデリングからデータ、シミュレーション、オブジェクト指向分析と設計、知識獲得まで、幅広い用途をカバーしています。これらの定義言語は、米国空軍の資金提供を受けて開発され、現在でも米国空軍やその他の軍隊、米国国防総省 (DoD) の機関で最もよく使用されていますが、パブリックドメインとなっています。

IDEF ファミリーの中で最も広く認識され、使用されているコンポーネントは、SADT に基づいて構築された機能モデリング言語である IDEF0 と、情報モデルとデータベース設計の問題に対処する IDEF1X です。

形式化された行政表記法 (FAN)

形式化された行政記法(FAN) は、さまざまな組織の管理者が業務の流れと順序を記述し、責任を特定し、取引を定義および統合できるようにする方法です。その目的は、特定のシステムの実装モードを定式化して、さらに体系化を進めることです。スペイン語では元々 MECAF ( Metodo de expresion de circuitos administrativos formalizado )と呼ばれていました。

ハーバリアンプロセスモデリング (HPM)

ハーバリアンプロセスモデリング (HPM) は、組織から内部プロセス情報を取得し、その情報を視覚的に効果的かつシンプルな方法で文書化する方法です。

HPM メソッドには 2 つのレベルがあります。

プロセス図: 特定のプロセスまたはワークフローの概要を示します。
システム図: 各プロセスの相関関係、およびさまざまな入力、出力、目標、フィードバックループ、外部要因をマッピングします。

ビジネスプロセス実行言語 (BPEL)

Webサービスビジネスプロセス実行言語（WS-BPEL）は、一般にBPEL（ビジネスプロセス実行言語）として知られ、Webサービスを使用してビジネスプロセス内のアクションを指定するためのOASIS ^[50]標準実行言語です。BPELのプロセスは、Webサービスインターフェイスのみを使用して情報をエクスポートおよびインポートします。

ツール

ビジネスプロセスモデリングツールは、ビジネスユーザーにビジネスプロセスのモデリング、それらのモデルの実装と実行、および実行データに基づくモデルの改良機能を提供します。その結果、ビジネスプロセスモデリングツールは、ビジネスプロセスの透明性と、企業のビジネスプロセスモデルと実行メトリックの集中化を実現できます。^[51]モデリングツールを使用すると、チームで作業するユーザーによる複雑なプロセスの共同モデリングも可能になり、ユーザーは共同でモデルを共有してシミュレーションできます。^[52]ビジネスプロセスモデリングツールをビジネスプロセス自動化システムと混同しないでください。どちらのプラクティスも、プロセスのモデリングを同じ初期ステップとしていますが、違いは、プロセス自動化によって「実行可能なダイアグラム」が提供され、それが従来のグラフィカルなビジネスプロセスモデリングツールとは大きく異なることです。^[要出典]

プログラミング言語ツール

BPMスイートソフトウェアは、BPMエンジンを活用するエンタープライズアプリケーションの構築を可能にするプログラミングインターフェイス（Webサービス、アプリケーションプログラムインターフェイス（API））を提供します。^[51]このコンポーネントは、 BPMスイートの エンジンと呼ばれることがよくあります。

BPMに導入されているプログラミング言語には以下のものがある: ^[53]

ベンダー固有の言語の一部:

統合情報システムアーキテクチャ（ARIS）はEPCをサポートします。
Javaプロセス定義言語（JBPM）、

ビジネスプロセスモデリングに関連するその他のテクノロジには、モデル駆動型アーキテクチャやサービス指向アーキテクチャなどがあります。

シミュレーション

このようなツールのシミュレーション機能により、実行前の「what-if」モデリング（このアプリケーションには特別な要件があります）とシミュレーションが可能になります。実行後の最適化は、実際に実行されたメトリックの分析に基づいて利用できます。^[51]

ユースケース図は、Ivar Jacobson によって 1992 年に作成されました (UML に統合)
アクティビティ図（UMLでも採用）

参照

参考文献

^ abcd ビジネスプロセス管理専門家協会 ABPMP (発行元):ビジネスプロセス管理共通知識体系ガイド - BPM CBOK®、翻訳・編集されたドイツ語版 → 欧州ビジネスプロセス管理協会 EABPM (発行元):ビジネスプロセス管理共通知識体系 - BPM CBOK®、第 2 版、Verlag Dr. Götz Schmidt、Gießen 2009、ISBN 978-3-921313-80-0
^ abcdefghi Hermann J. Schmelzer and Wolfgang Sesselmann: Geschäftsprozessmanagement in der Praxis、第 9 版、ハンザー、ミュンヘン、2020 年、ISBN 978-3-446-44625-0
^ abcdefgh Andreas Gadatsch: Management von Geschäftsprozessen / Methoden und Werkzeuge für die IT-Praxis: Eine Einführung für Studenten und Praktiker、第 2 改訂増補版、Vieweg、ブラウンシュヴァイク/ヴィースバーデン、2002 年、ISBN 978-3-528-15759-3
^ abcdefghijk Michael Rosemann、Ansgar Schwegmann、および Patrick Delfmann: Vorbereitung der Prozessmodellierung in Jörg Becker、Martin Kugler、Michael Rosemamm (出版社): Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung、第 2 修正および拡張版、Springer、ベルリン/ハイデルベルク/ニューヨーク 2002、ISBN 978-3-540-00107-2
^ 知識データベース: In 6 einfachen Schritten zur Prozesslandkarte, DER PROZESSMANAGER GmbH (最終アクセス日: 2024 年 1 月 25 日)
^ Jörg Becker and Dieter Kahn: Der Prozess im Fokus in Jörg Becker、Martin Kugler、Michael Rosemamm (出版社): Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung、第 2 修正および拡張版、Springer、ベルリン/ハイデルベルク/ニューヨーク 2002、ISBN 3-540-00107-7
^ abcdefg Jörg Becker and Volker Meise: Strategie und Organisationsrahmen in Jörg Becker、Martin Kugler、Michael Rosemamm (出版社): Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung、第 2 修正および拡張版、Springer、ベルリン/ハイデルベルク/ニューヨーク、2002 年、ISBN 3-540-00107-7
^ ab Mario Speck and Norbert Schnetgöke: Sollmodellierung und Prozessoptimierung in Jörg Becker、Martin Kugler、Michael Rosemamm (出版社): Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung、第 2 修正および拡張版、シュプリンガー、ベルリン/ハイデルベルク/ニューヨーク 2002、 ISBN 3-540-00107-7
^ Thomas Dufresne & James Martin (2003). 「E-ビジネスのためのプロセスモデリング」。INFS 770 情報システムエンジニアリングの方法: ナレッジマネジメントと E-ビジネス。2003 年春^{[リンク切れ‍ ]}
^ Williams, S. (1967)「ビジネスプロセスモデリングによる管理制御の向上」『Automation』1967 年 12 月、44 - 50 ページ。
^ ab Asbjørn Rolstadås (1995)。「ビジネスプロセスのモデリングとリエンジニアリング」。『パフォーマンス管理: ビジネスプロセスのベンチマークアプローチ』p. 148-150。
^ Brian C. Warboys (1994).ソフトウェアプロセステクノロジー: 第3回ヨーロッパワークショップ EWSPT'94、ヴィラール・ド・ランス、フランス、1994年2月7～9日: 議事録。p. 252。
^ ジョン・ミルテンバーグ、デイヴィッド・スパーリング：総サイクル時間の管理と短縮：モデルと分析、エルゼビア国際生産経済ジャーナル、1996年12月、89-108ページ
^ Michael Molter: Die Prozessorientierte Applicationslandschaft in August-W. Scheer、Wolfram Jost、Karl Wagner (出版社): Von Prozessmodellen zu lauffähigen Anwendungen、Springer Berlin、ハイデルベルク、ニューヨーク 2005、ISBN 3-540-23457-8
^ N. ベンカットベンカトラマン: MS におけるIT によるビジネス再構成スコットモートン (出版社): 1990 年代の企業: 情報技術と組織変革、第 1 版、オックスフォード大学出版局、1991 年、ISBN 978-0-19-506358-5
^ トーマス・H・ダベンポート：プロセスイノベーション：情報技術による仕事の再構築、ハーバードビジネスプレス、ボストン、1993年、ISBN 978-0-87584-366-7
^ マイケル・M・ハマー、ジェームズ・A・チャンピー：企業の再構築：ビジネス革命の宣言、ハーパー・ビジネス、ニューヨーク、1993年、ISBN 978-0-88730-640-2
^ ab ISO 9001:2015:品質マネジメントシステム - 要求事項、第 5 版 2015-09、ISO、国際標準化機構 2015。
^ ISO 14001:2015:環境マネジメントシステム - 要求事項及び使用の手引き、第 3 版 2015-09、ISO、国際標準化機構 2015。
^ ISO 27001:2022:情報セキュリティ、サイバーセキュリティ、プライバシー保護情報セキュリティ管理システム - 要件、第 3 版 2022-10、ISO、国際標準化機構 2022。
^ Martin Kugler: Supply Chain Management und Customer Relationship Management - Prozessmodellierung für Extended Enterprises in Jörg Becker、Martin Kugler、Michael Rosemamm (出版社): Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung、2. 修正および拡張版、シュプリンガー、ベルリン/ハイデルベルク/ 2002年ニューヨーク、 ISBN 3-540-00107-7
^ ab Timo Füermann: Prozessmanagement: Kompaktes Wissen、Konkrete Umsetzung、Praktische Arbeitshilfen、Hanser、ミュンヘン 2014、ISBN 978-3-446-43858-3
^ abcd Ansgar Schwegmann and Michael Laske: Istmodellierung und Istanalyse in Jörg Becker、Martin Kugler、Michael Rosemamm (出版社): Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung、第 2 修正および拡張版、Springer、ベルリン/ハイデルベルク/ニューヨーク 2002、ISBN 3-540-00107-7
^ 「ISO - 国際標準化機構」。ISO。2024年5月27日。
^ オーガスト-W.シェーア: ARIS: Von der Vision zur praktischen Geschäftsprozesssteuerung in August-W. Scheer および Wolfram Jost (Hrsg.): ARIS in der Praxis: Gestaltung, Implementierung und Optimierung von Geschäftsprozessen、Springer、ベルリン/ハイデルベルク/ニューヨーク、2002 年、ISBN 3-540-43029-6
^ Yongchareon, Sira (2015). 「アーティファクト中心の組織間ビジネスプロセスのモデリングと変更検証のためのビューフレームワーク」.情報システム. 47 : 51–81. doi :10.1016/j.is.2014.07.004.
^ Cedric G. Tyler と Stephen R. Baker:ビジネス遺伝学: xBML を用いた 21 世紀企業の理解、John Wiley & Sons Ltd、2007 年、ISBN 978-0-470-06654-6
^ 「ビジネスプロセス改善」。2014年1月9日時点のオリジナルよりアーカイブ。2024年2月19日閲覧。{{cite web}}: CS1 maint: bot: original URL status unknown (link)2024年2月19日にアクセス。
^ prof-mayr.de にアーカイブ(日付がありません) (エラー: アーカイブ URL が不明)、auf prof-mayr.de、2024 年 2 月 5 日に取得。 PDF "VL4030_OMEGA+-Beschreibungsmethode.pdf" の詳細情報
^ OMG. 「BPMN 2.0」。2011年3月29日閲覧。
^ 「ビジネスプロセスモデルと表記法の仕様バージョン2.0.2について」www.omg.org 。 2020年12月7日閲覧。
^ <trans oldtip="A.-W.シェアー (2002). " newtip="A.-W.シェアー(2002年)。">A.-W.シェアー(2002年)。</trans> <trans oldtip="ARIS.Vom Geschäftsprozess zum Anwendungssystem" newtip="阿里斯。vm Gesch ftsprozess zum Anwendungssystem">アリシス。vm Gesch ftsprozess zum Anwendungssystem</trans>。スプリンガー。 p.20。
^ ペトリ、カール・アダム;ライシヒ、ヴォルフガング (2008)。「ペトリネット」。スカラーペディア。3 (4): 6477。書誌コード:2008SchpJ...3.6477P。土井：10.4249/scholarpedia.6477。
^ SEVOCAB: ソフトウェアシステムエンジニアリング用語集。用語:フローチャート。2008年7月31日閲覧。
^ IBM Corporation (1974). HIPO—設計支援およびドキュメンテーション技術、発行番号 GC20-1851、IBM Corporation、ニューヨーク州ホワイトプレーンズ、1974 年。
^ Katzan, Harry Jr. (1976).システム設計とドキュメンテーション: HIPO メソッドの紹介。Van Nostrand Reinhold。ISBN 0-442-24267-0。
^ サンディア国立研究所 (1992)。サンディアソフトウェアガイドライン第5巻ツール、テクニック、および方法論 2009年8月25日アーカイブ、Wayback MachineにてSANDIA REPORTS 85–2348qUC–32
^ LML運営委員会。「LML仕様」。 2023年3月1日閲覧。
^ 「ライフサイクルモデリング言語について」。LML運営委員会。2014年6月5日閲覧。
^ Fleischmann, Albert; Stary, Christian (2011). 「誰と話をするか? ビジネスプロセス開発に関する利害関係者の視点」情報社会におけるユニバーサルアクセス11 ( 2): 1–28. doi : 10.1007/s10209-011-0236-x .
^ Sjir Nijssenと André Le Cat. Kennis Gebaseerd Werken]、 2009。p. 118-148
^ Nijssen, Gerardus Maria、およびTerence Aidan Halpin。概念スキーマとリレーショナルデータベース設計: 事実指向アプローチ。Prentice -Hall, Inc.、1989 年。
^ Simon, Kerri (2010 年 2 月 26 日). 「SIPOC ダイアグラム」.リッジフィールド、コネチカット州: iSixSigma . 2012 年 7 月 3 日閲覧。
^ 「SIPOC (サプライヤー、入力、プロセス、出力、顧客) 図」。ミルウォーキー、ウィスコンシン州：アメリカ品質協会。 2020年1月29日閲覧。
^ 統一モデリング言語 2.5.1。OMG文書番号 formal/2017-12-05。オブジェクト管理グループ標準化機構 (OMG SDO)。2017 年 12 月。
^ 統一モデリング言語ユーザーガイド（第2版）。Addison-Wesley。2005年。p.496。ISBN 0321267974。サンプルコンテンツを見る: 履歴を探す
^ 「ISO/IEC 19501:2005 - 情報技術 - オープン分散処理 - 統一モデリング言語 (UML) バージョン 1.4.3」。Iso.org。2005 年 4 月 1 日。2015年 5 月 7 日閲覧。
^ 「ISO/IEC 19505-1:2012 - 情報技術 - オブジェクト管理グループ統一モデリング言語 (OMG UML) - パート 1: インフラストラクチャ」。Iso.org。2012 年 4 月 20 日。2014年 4 月 10 日閲覧。
^ Sebastian Baltes、Stephan Diehl (2014-11-11) 。「スケッチとダイアグラムの実践」。第 22 回ACM SIGSOFT国際ソフトウェア工学基礎シンポジウム議事録。FSE 2014。Association for Computing Machinery。pp . 530–541。arXiv : 1706.09172。doi : 10.1145 / 2635868.2635891。ISBN 978-1-4503-3056-5. S2CID 2436333。
^ OASIS 標準 WS-BPEL 2.0
^ abc ワークフロー/ビジネスプロセス管理 (BPM) サービスパターン、 2007 年 6 月 27 日、 Wayback Machineで2009 年 1 月 13 日にアーカイブ。2008 年 11 月 29 日にアクセス。
^ Christensen、Lars Rune、Thomas Hildebrandt (2017)「医療部門における共同作業のモデル化」。第 8 回国際コミュニティとテクノロジー会議の議事録。フランス、トロワ。ACM。
^ 「ビジネスプロセスモデリング FAQ」。2008 年 11 月 9 日時点のオリジナルよりアーカイブ。2008年 11 月 2 日に取得。
^ FEA (2005) FEA 記録管理プロファイル、バージョン 1.0。2005 年 12 月 15 日。
^ FEA 統合参照モデル文書、Wayback Machineに 2010-10-11 にアーカイブ。2007 年 10 月。
^ abcd Paul R. Smith & Richard Sarfaty (1993)。コンピュータ支援ソフトウェアエンジニアリング (CASE) ツールを使用した構成管理の戦略計画の作成。1993 年 National DOE/請負業者および施設 CAD/CAE ユーザーグループ向け論文。
^ビジネスプロセスリエンジニアリング評価ガイド、 Wayback Machineに 2017-02-18 にアーカイブ、米国会計検査院、1997 年 5 月。

さらに読む

Aguilar-Saven、Ruth Sara。「ビジネスプロセスモデリング：レビューとフレームワーク」Wayback Machineで2020年8月7日にアーカイブされました。国際生産経済ジャーナル90.2（2004）：129–149。
Barjis, Joseph (2008). 「ソフトウェアシステム設計におけるビジネスプロセスモデリングの重要性」.コンピュータプログラミングの科学. 71 : 73–87. doi : 10.1016/j.scico.2008.01.002 .
Becker、Jörg、Michael Rosemann、および Christoph von Uthmann。「ビジネスプロセスモデリングのガイドライン」。ビジネスプロセス管理。Springer Berlin Heidelberg、2000 年。30 ～ 49 ページ。
Hommes, LJビジネスプロセスモデリング技術の評価。博士論文。デルフト工科大学。
Håvard D. Jørgensen (2004)。インタラクティブプロセスモデル。論文、ノルウェー科学技術大学トロンハイム、ノルウェー。
Manuel Laguna、Johan Marklund (2004)。『ビジネスプロセスモデリング、シミュレーション、および設計』。Pearson/Prentice Hall、2004 年。
Ovidiu S. Noran (2000)。ビジネスモデリング: UML vs. IDEF 論文グリフ大学
Jan Recker (2005) 「21 世紀のプロセスモデリング」。BP Trends、2005 年 5 月。
Ryan KL Ko、Stephen SG Lee、Eng Wah Lee (2009)「ビジネスプロセス管理 (BPM) 標準: 調査」。Business Process Management Journal、Emerald Group Publishing Limited。第 15 巻第 5 号。ISSN 1463-7154。
Jan Vanthienen、S. Goedertier、R. Haesen (2007)。「EM-BrA2CE v0.1: 宣言型ビジネスプロセスモデリングの語彙と実行モデル」。DTEW - KBI_0728。

外部リンク

ウィキメディア・コモンズのビジネスプロセスモデリングに関連するメディア

[EABPM-1] ビジネスプロセス管理専門家協会 ABPMP (発行元):ビジネスプロセス管理共通知識体系ガイド - BPM CBOK®、翻訳・編集されたドイツ語版 → 欧州ビジネスプロセス管理協会 EABPM (発行元):ビジネスプロセス管理共通知識体系 - BPM CBOK®、第 2 版、Verlag Dr. Götz Schmidt、Gießen 2009、ISBN 978-3-921313-80-0

[SCHMELZER-2] Hermann J. Schmelzer and Wolfgang Sesselmann: Geschäftsprozessmanagement in der Praxis、第 9 版、ハンザー、ミュンヘン、2020 年、ISBN 978-3-446-44625-0

[GADATSCH-3] Andreas Gadatsch: Management von Geschäftsprozessen / Methoden und Werkzeuge für die IT-Praxis: Eine Einführung für Studenten und Praktiker、第 2 改訂増補版、Vieweg、ブラウンシュヴァイク/ヴィースバーデン、2002 年、ISBN 978-3-528-15759-3

[ROSEMANN-4] Michael Rosemann、Ansgar Schwegmann、および Patrick Delfmann: Vorbereitung der Prozessmodellierung in Jörg Becker、Martin Kugler、Michael Rosemamm (出版社): Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung、第 2 修正および拡張版、Springer、ベルリン/ハイデルベルク/ニューヨーク 2002、ISBN 978-3-540-00107-2

[5] 知識データベース: In 6 einfachen Schritten zur Prozesslandkarte, DER PROZESSMANAGER GmbH (最終アクセス日: 2024 年 1 月 25 日)

[BECKER-KAHN-6] Jörg Becker and Dieter Kahn: Der Prozess im Fokus in Jörg Becker、Martin Kugler、Michael Rosemamm (出版社): Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung、第 2 修正および拡張版、Springer、ベルリン/ハイデルベルク/ニューヨーク 2002、ISBN 3-540-00107-7

[BECKER-MEISE-7] Jörg Becker and Volker Meise: Strategie und Organisationsrahmen in Jörg Becker、Martin Kugler、Michael Rosemamm (出版社): Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung、第 2 修正および拡張版、Springer、ベルリン/ハイデルベルク/ニューヨーク、2002 年、ISBN 3-540-00107-7

[SPECK-SCHNETT-8] Mario Speck and Norbert Schnetgöke: Sollmodellierung und Prozessoptimierung in Jörg Becker、Martin Kugler、Michael Rosemamm (出版社): Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung、第 2 修正および拡張版、シュプリンガー、ベルリン/ハイデルベルク/ニューヨーク 2002、 ISBN 3-540-00107-7

[TD03-9] Thomas Dufresne & James Martin (2003). 「E-ビジネスのためのプロセスモデリング」。INFS 770 情報システムエンジニアリングの方法: ナレッジマネジメントと E-ビジネス。2003 年春^{[リンク切れ‍ ]}

[10] Williams, S. (1967)「ビジネスプロセスモデリングによる管理制御の向上」『Automation』1967 年 12 月、44 - 50 ページ。

[Rol95-11] Asbjørn Rolstadås (1995)。「ビジネスプロセスのモデリングとリエンジニアリング」。『パフォーマンス管理: ビジネスプロセスのベンチマークアプローチ』p. 148-150。

[12] Brian C. Warboys (1994).ソフトウェアプロセステクノロジー: 第3回ヨーロッパワークショップ EWSPT'94、ヴィラール・ド・ランス、フランス、1994年2月7～9日: 議事録。p. 252。

[MILTENBURG-SPARLING-13] ジョン・ミルテンバーグ、デイヴィッド・スパーリング：総サイクル時間の管理と短縮：モデルと分析、エルゼビア国際生産経済ジャーナル、1996年12月、89-108ページ

[MOLTER-14] Michael Molter: Die Prozessorientierte Applicationslandschaft in August-W. Scheer、Wolfram Jost、Karl Wagner (出版社): Von Prozessmodellen zu lauffähigen Anwendungen、Springer Berlin、ハイデルベルク、ニューヨーク 2005、ISBN 3-540-23457-8

[15] N. ベンカットベンカトラマン: MS におけるIT によるビジネス再構成スコットモートン (出版社): 1990 年代の企業: 情報技術と組織変革、第 1 版、オックスフォード大学出版局、1991 年、ISBN 978-0-19-506358-5

[DAVENPORT-16] トーマス・H・ダベンポート：プロセスイノベーション：情報技術による仕事の再構築、ハーバードビジネスプレス、ボストン、1993年、ISBN 978-0-87584-366-7

[HAMMER-CHAMPY-17] マイケル・M・ハマー、ジェームズ・A・チャンピー：企業の再構築：ビジネス革命の宣言、ハーパー・ビジネス、ニューヨーク、1993年、ISBN 978-0-88730-640-2

[ISO-9001-18] ISO 9001:2015:品質マネジメントシステム - 要求事項、第 5 版 2015-09、ISO、国際標準化機構 2015。

[19] ISO 14001:2015:環境マネジメントシステム - 要求事項及び使用の手引き、第 3 版 2015-09、ISO、国際標準化機構 2015。

[20] ISO 27001:2022:情報セキュリティ、サイバーセキュリティ、プライバシー保護情報セキュリティ管理システム - 要件、第 3 版 2022-10、ISO、国際標準化機構 2022。

[KUGLER-21] Martin Kugler: Supply Chain Management und Customer Relationship Management - Prozessmodellierung für Extended Enterprises in Jörg Becker、Martin Kugler、Michael Rosemamm (出版社): Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung、2. 修正および拡張版、シュプリンガー、ベルリン/ハイデルベルク/ 2002年ニューヨーク、 ISBN 3-540-00107-7

[FUEERMANN-22] Timo Füermann: Prozessmanagement: Kompaktes Wissen、Konkrete Umsetzung、Praktische Arbeitshilfen、Hanser、ミュンヘン 2014、ISBN 978-3-446-43858-3

[SCHWEGMANN-LASKE-23] Ansgar Schwegmann and Michael Laske: Istmodellierung und Istanalyse in Jörg Becker、Martin Kugler、Michael Rosemamm (出版社): Prozessmanagement: Ein Leitfaden zur prozessorientierten Organisationsgestaltung、第 2 修正および拡張版、Springer、ベルリン/ハイデルベルク/ニューヨーク 2002、ISBN 3-540-00107-7

[24] 「ISO - 国際標準化機構」。ISO。2024年5月27日。

[SCHEER-25] オーガスト-W.シェーア: ARIS: Von der Vision zur praktischen Geschäftsprozesssteuerung in August-W. Scheer および Wolfram Jost (Hrsg.): ARIS in der Praxis: Gestaltung, Implementierung und Optimierung von Geschäftsprozessen、Springer、ベルリン/ハイデルベルク/ニューヨーク、2002 年、ISBN 3-540-43029-6

[26] Yongchareon, Sira (2015). 「アーティファクト中心の組織間ビジネスプロセスのモデリングと変更検証のためのビューフレームワーク」.情報システム. 47 : 51–81. doi :10.1016/j.is.2014.07.004.

[27] Cedric G. Tyler と Stephen R. Baker:ビジネス遺伝学: xBML を用いた 21 世紀企業の理解、John Wiley & Sons Ltd、2007 年、ISBN 978-0-470-06654-6

[28] 「ビジネスプロセス改善」。2014年1月9日時点のオリジナルよりアーカイブ。2024年2月19日閲覧。{{cite web}}: CS1 maint: bot: original URL status unknown (link)2024年2月19日にアクセス。

[29] rof-mayr.de にアーカイブ(日付がありません) (エラー: アーカイブ URL が不明)、auf prof-mayr.de、2024 年 2 月 5 日に取得。 PDF "VL4030_OMEGA+-Beschreibungsmethode.pdf" の詳細情報

[Business_Process_Model_and_Notation_BPMN20-30] OMG. 「BPMN 2.0」。2011年3月29日閲覧。

[31] 「ビジネスプロセスモデルと表記法の仕様バージョン2.0.2について」www.omg.org 。 2020年12月7日閲覧。

[32] <trans oldtip="A.-W.シェアー (2002). " newtip="A.-W.シェアー(2002年)。">A.-W.シェアー(2002年)。</trans> <trans oldtip="ARIS.Vom Geschäftsprozess zum Anwendungssystem" newtip="阿里斯。vm Gesch ftsprozess zum Anwendungssystem">アリシス。vm Gesch ftsprozess zum Anwendungssystem</trans>。スプリンガー。 p.20。

[33] ペトリ、カール・アダム;ライシヒ、ヴォルフガング (2008)。「ペトリネット」。スカラーペディア。3 (4): 6477。書誌コード:2008SchpJ...3.6477P。土井：10.4249/scholarpedia.6477。

[Flowchart_SSEV-34] SEVOCAB: ソフトウェアシステムエンジニアリング用語集。用語:フローチャート。2008年7月31日閲覧。

[35] IBM Corporation (1974). HIPO—設計支援およびドキュメンテーション技術、発行番号 GC20-1851、IBM Corporation、ニューヨーク州ホワイトプレーンズ、1974 年。

[36] Katzan, Harry Jr. (1976).システム設計とドキュメンテーション: HIPO メソッドの紹介。Van Nostrand Reinhold。ISBN 0-442-24267-0。

[HIPO_model_Sandia92-37] サンディア国立研究所 (1992)。サンディアソフトウェアガイドライン第5巻ツール、テクニック、および方法論 2009年8月25日アーカイブ、Wayback MachineにてSANDIA REPORTS 85–2348qUC–32

[Lifecycle_Modeling_Language_specification-38] LML運営委員会。「LML仕様」。 2023年3月1日閲覧。

[39] 「ライフサイクルモデリング言語について」。LML運営委員会。2014年6月5日閲覧。

[Subject-oriented_business_process_management_Fleischmann.2011-40] Fleischmann, Albert; Stary, Christian (2011). 「誰と話をするか? ビジネスプロセス開発に関する利害関係者の視点」情報社会におけるユニバーサルアクセス11 ( 2): 1–28. doi : 10.1007/s10209-011-0236-x .

[41] Sjir Nijssenと André Le Cat. Kennis Gebaseerd Werken]、 2009。p. 118-148

[42] Nijssen, Gerardus Maria、およびTerence Aidan Halpin。概念スキーマとリレーショナルデータベース設計: 事実指向アプローチ。Prentice -Hall, Inc.、1989 年。

[43] Simon, Kerri (2010 年 2 月 26 日). 「SIPOC ダイアグラム」.リッジフィールド、コネチカット州: iSixSigma . 2012 年 7 月 3 日閲覧。

[44] 「SIPOC (サプライヤー、入力、プロセス、出力、顧客) 図」。ミルウォーキー、ウィスコンシン州：アメリカ品質協会。 2020年1月29日閲覧。

[Unified_Modeling_Language_OMG-45] 統一モデリング言語 2.5.1。OMG文書番号 formal/2017-12-05。オブジェクト管理グループ標準化機構 (OMG SDO)。2017 年 12 月。

[Unified_Modeling_Language_:1-46] 統一モデリング言語ユーザーガイド（第2版）。Addison-Wesley。2005年。p.496。ISBN 0321267974。サンプルコンテンツを見る: 履歴を探す

[47] 「ISO/IEC 19501:2005 - 情報技術 - オープン分散処理 - 統一モデリング言語 (UML) バージョン 1.4.3」。Iso.org。2005 年 4 月 1 日。2015年 5 月 7 日閲覧。

[48] 「ISO/IEC 19505-1:2012 - 情報技術 - オブジェクト管理グループ統一モデリング言語 (OMG UML) - パート 1: インフラストラクチャ」。Iso.org。2012 年 4 月 20 日。2014年 4 月 10 日閲覧。

[49] ^ Sebastian Baltes、Stephan Diehl (2014-11-11) 。「スケッチとダイアグラムの実践」。第 22 回ACM SIGSOFT国際ソフトウェア工学基礎シンポジウム議事録。FSE 2014。Association for Computing Machinery。pp . 530–541。arXiv : 1706.09172。doi : 10.1145 / 2635868.2635891。ISBN 978-1-4503-3056-5. S2CID 2436333。

[50] OASIS 標準 WS-BPEL 2.0

[NIH07-51] ワークフロー/ビジネスプロセス管理 (BPM) サービスパターン、 2007 年 6 月 27 日、 Wayback Machineで2009 年 1 月 13 日にアーカイブ。2008 年 11 月 29 日にアクセス。

[52] Christensen、Lars Rune、Thomas Hildebrandt (2017)「医療部門における共同作業のモデル化」。第 8 回国際コミュニティとテクノロジー会議の議事録。フランス、トロワ。ACM。

[bpmfaq-53] 「ビジネスプロセスモデリング FAQ」。2008 年 11 月 9 日時点のオリジナルよりアーカイブ。2008年 11 月 2 日に取得。

[54] FEA (2005) FEA 記録管理プロファイル、バージョン 1.0。2005 年 12 月 15 日。

[55] FEA 統合参照モデル文書、Wayback Machineに 2010-10-11 にアーカイブ。2007 年 10 月。

[SS93-56] Paul R. Smith & Richard Sarfaty (1993)。コンピュータ支援ソフトウェアエンジニアリング (CASE) ツールを使用した構成管理の戦略計画の作成。1993 年 National DOE/請負業者および施設 CAD/CAE ユーザーグループ向け論文。

[GAO97-57] ^ビジネスプロセスリエンジニアリング評価ガイド、 Wayback Machineに 2017-02-18 にアーカイブ、米国会計検査院、1997 年 5 月。

概要

歴史

ビジネスプロセスモデリングの目的

ビジネスプロセスモデリングの応用

ビジネスプロセスリエンジニアリング（BPR）

ISOに準拠した管理システムの認証

プロセスに関する管理システムの一般的な標準要求事項

文書化された情報に関する管理システムの特定の標準要件

ビジネスプロセスの最適化

企業間ビジネスプロセスモデリング

トピック

事業活動の分析

フレームワーク条件を定義する

ビジネスプロセスを特定する

ビジネスプロセスの構造化 - プロセスマップの構築

ビジネスプロセスモデリングの長期的な成功のための戦略に基づいてコアプロセスを構築する

ビジネスプロセスの定義

一般的なプロセス識別と個別のプロセス識別

ビジネスプロセスのさらなる構造化

プロセス責任の割り当て

ビジネスプロセスのモデリング

プロセスチェーンの設計

サブプロセス

機能（タスク）

マスターデータ（成果物）

外部文書とITシステムの統合

モデルの統合

プロセス連鎖と制御フローパターン

プロセスインターフェース

ビジネスプロセス管理

プロセスモデルの適応

表現の種類と表記

モデリング技術

ビジネスプロセスモデルと表記法 (BPMN)

イベント駆動型プロセスチェーン (EPC)

ペトリネット

フローチャート

階層的入力プロセス出力モデル (HIPO)

ライフサイクルモデリング言語 (LML)

主題指向のビジネスプロセス管理

認知強化型自然言語情報分析法

SIPOC（サプライヤー、入力、プロセス、出力、顧客）

統一モデリング言語 (UML)

統合定義 (IDEF)

形式化された行政表記法 (FAN)

ハーバリアンプロセスモデリング (HPM)

ビジネスプロセス実行言語 (BPEL)

ツール

プログラミング言語ツール

シミュレーション

関連概念

ビジネスリファレンスモデル

ビジネスプロセス統合

ビジネスプロセスリエンジニアリング

ビジネスプロセス管理

プロセスモデルの適応

参照

参考文献

さらに読む

外部リンク