入力と出力の識別は、ビジネス プロセスのモデル化において非常に重要な側面であり、プロセスの実行をサポートする情報システムの定義にも密接に関連しています。
共同環境におけるビジネス プロセスのインプットとアウトプットの特定とモデル化のための方法論が提案されています。
ビジネス プロセスのインプットとアウトプットは、ビジネス プロセス管理、ビジネス モデリング アーキテクチャ、またはソフトウェア要件エンジニアリングなど、さまざまな作業分野から取り上げられました。コラボレーション環境では、ビジネス プロセスには従来のビジネス プロセスとはいくつかの違いがあります。一方では
プロセス活動の実行は 2 つ以上のエンティティ (企業、サプライチェーン、またはネットワーク) の責任であり、それに伴い、プロセスをサポートするシステムおよび関連する情報システムの問題が発生します。その一方で、協力関係によってプロセスがどのように変化するかが問題となります。情報はエンティティ間で共有されます。
ビジネス プロセス管理領域では、プロセスの入力と出力を考慮する手法とツールが提供されます。これらの手法の一部は次のとおりです (Aguilar-Saven、2004): フローチャート、データ フロー図 - DFD、役割アクティビティ図 - RAD、役割相互作用図 - RID)、ガント図、IDEF (役割モデリングのための統合定義)、カラー ペトリ ネット ( Couloured Petri-net-CPN)、オブジェクト指向手法 (オブジェクト指向-OO)、またはワークフロー手法 ビジネス モデリング アーキテクチャ これらは、さまざまなモデリング ビューを使用してビジネス プロセス モデリングにアプローチし、それぞれが統合されたビジネス モデルの 1 つの特定の部分に焦点を当てて取り組みます (トー、1999）。
各モデリング アーキテクチャは、独自のモデリング ビューを提案します。たとえば、AIMOSA (組織、リソース、情報、機能ビュー)、GRAI-GIM (製品ビュー)、
物理システム、意思決定システム、情報システム、機能システム）、PERA（組織と人事、情報システムと生産チームのアーキテクチャ）、GERAM（組織、リソース、情報、機能のビジョン）、ARIS（機能、データのビジョン） 、
組織と管理）。プロセスのインプットとアウトプットは、主に機能的および情報的観点から扱われてきました (Melao および Pidd、2000)。最後に、ソフトウェア要件エンジニアリングでは、情報システムの設計を目的としたモデルで表現する必要がある要素を特定できるため、ビジネス プロセスと計算システムの関係を明示的に考慮できます。
要件エンジニアリングでは、ソフトウェア システムのユーザーの正確なニーズを理解して、これらのニーズを、後でシステムの開発に使用できる正確かつ明確な指示に変換しようとします。
さまざまな作業分野がさまざまなモデリング ツールを提供し、多くの場合、独自の方法論が組み込まれています (Cuenca その他、 2006）。プロセス モデリングの方法論は、開発するモデルによって異なります。グローバルな観点から見ると、プロセスの文書化に関連する情報には、 目標, 範囲, 条項 Y 定義, 責任 Y 権限, 活動内容 実行されるもの、 前菜 Y 出る, 指標, 資力, インフラストラクチャ それは 相互関係 他のプロセスとの併用 (Arrascaeta、2005 年、および Athena、2004 年)。 Lin と Polenske (1998) は、生産プロセスのインプットとアウトプットのモデルを提示しています。このモデルは、意思決定のための情報を提供するために、生産プロセスにおける既存のインプットとアウトプットの数学的記述を提供します。このモデルでは、企業の生産活動は、結果を生み出すためにいくつかの要素を組み合わせた一連の生産プロセスとして考慮されます。ただし、このアプローチでは、プロセスとその顧客およびサプライヤーとの関係が考慮されていません。
チェン・リョン その他 (1999) は、情報と素材という 2 つのタイプの入力と出力を区別しています。サプライチェーンのコンテキストでは、SCOR モデル (サプライチェーン運用
参照モデル) は、サプライ チェーン企業とその情報システム間の通信を改善するために使用されます (Athena、2004)。 その他 (2002) 生産プロセスのインプットとアウトプットに基づくアプローチを提案しています。これは、グローバル サプライ チェーンまたはチェーンの一部の生産プロセス間のフローを調査する特定のモデルを開発するために使用されます。ヘルナンデス その他 (2008) 製品フロー (変換プロセスの入力と出力)、情報フロー (情報変換プロセスの入力と出力)、および意思決定フロー (意思決定プロセスとその関係) を区別しています。
プロセスの入力と出力を識別することは、ビジネス プロセス モデリングで満たすべき要件ですが、分析された提案では、これをどのように行うべきかについて詳しく説明されていません。これは、ビジネス プロセスの入力と出力を特定して分析するのに役立つ方法論の必要性を正当化します。
コラボレーション環境におけるビジネスプロセスのインプットとアウトプットを特定し、モデル化するための方法論の提案
この方法論を通じて、実行されるアクティビティの流れの観点から、プロセスのインプットとアウトプットが特定されます。この意味で、入力は出力を生成するアクティビティ中に変換または使用されます。提案された方法論は、トップダウン プロセス アプローチ (Top-Dow) に従っており、プロセス、サブプロセス、およびアクティビティの入力と出力がこの順序で識別されます。
各プロセス、サブプロセス、またはアクティビティで実行する手順は次のとおりです。
1. プロセス、サブプロセス、またはアクティビティを特定します。方法論の次のステップが実行されるプロセス、サブプロセス、またはアクティビティを明確に特定する必要があります。
2. アウトプット (結果) の識別: 顧客に価値を加えるプロセスアウトプットは、インプットを価値アウトプットに変換する活動から生じる他のプロセスアウトプットから区別されなければなりません。
a) プロセスは顧客にどのような価値のアウトプット (結果) を提供しますか?
b) 入力を変換した結果、プロセスは他にどのような出力を生成しますか?
各出力について:
2.1.それは情報またはマテリアルの出力ですか?: プロセスは情報またはマテリアル オブジェクトの出力を提供できます。この方法論では、次のようなことが考えられることが理解されています。
— データまたは情報出力: アクティビティまたはプロセスによって生成されるデータまたは情報。
— オブジェクト (またはマテリアル) の出力: アクティビティまたはプロセスによって生成されるオブジェクト。
2.2.顧客または受取人は誰ですか?: プロセスの出力は、特定の顧客に価値を提供することによって正当化されます (2a)。
変換プロセス (2b) の結果としての他の出力の場合、出力の受信者について話すことができます。
23. 出力の仕様: 出力自体の性質に従って、また受信者の観点から出力を明確に識別するために、出力を仕様化する必要があります。後者は、出力が顧客が期待する値を持つかどうかを判断します。
2.3.1.顧客または受信者の観点から見た出力の仕様は何ですか?
2.3.2.情報か物体かに応じて、その性質に応じた仕様とは何でしょうか？
3. 入力の識別: プロセス入力はさまざまなタイプにすることができます。 IDEF0 のプロセス モデルには、プロセスへの入力として理解できる次の基本要素が含まれています。権限 (プロセスの説明、仕様、または正当化)、制御 (プロセスを起動する条件)、入力 (プロセスに入るオブジェクト)、およびメカニズム (プロセスによって使用されるリソース)。
提案された方法論では、変換されるプロセスに入る入力、または出力を生成するために使用される入力のみが識別されます。
各エントリについて:
3.1.それは情報または資料のエントリですか?: この方法論では、2 種類のエントリが表示される可能性があることが理解されています。
— データまたは情報入力: 出力を生成するためにアクティビティまたはプロセスによって変換または使用されるデータまたは情報。
— オブジェクト (またはマテリアル) 入力: 出力を生成するためにアクティビティまたはプロセスによって変換または使用されるオブジェクト。
3.2.サプライヤーまたはオリジンは誰ですか?: 入力を識別するために必要な情報は、入力を提供するサプライヤーまたはオリジンがすでに確立されている場合、または何らかの種類の関係を確立したい場合です。
3.3.入力の仕様: 入力をそれ自体の性質に従って、また入力を変換または使用するアクティビティの観点から明確に識別するために入力を指定する必要があります。後者は、入力がアクティビティに必要な要件を満たすという事実を条件としているからです。出力を行います:
3.3.1.アクティビティの観点から見た入力仕様は何ですか?
3.3.2.情報か物体かに応じて、その性質に応じた仕様とは何でしょうか？