JP2003516569A - ビジネス・モデリングの方法および装置 - Google Patents

Abstract

(57)【要約】 プログラミングせずに、ユーザ定義のビジネス・プロセス・モデルに基づいて、アプリケーションまたはテンプレートまたはカスタム・ソリューションを生成する方法を図形による方法で定義する方法および装置。コンピュータ化されたシステムは、プレハブ・ソフトウェア構成要素を使用する。これらの構成要素は、ソリューション・ライブラリに記載されている。ソリューション・ライブラリは、排他的かつ完全に網羅的な構成要素（ビジネス・パターン、データ・マッピング・モデル、状態モデル）のリストを含む。これらの構成要素は、その業界全体にわたってすべてのビジネス・アプリケーションに関して汎用ソリューションを構築する。プレハブ・ソフトウェア構成要素は、注文要素、資源要素、およびプロセス要素を添付の状態表と共に含む。これらは、ビジネス・パターンを構成する。本発明は、最適なビジネス・プロセスの分析を提供する。一旦、最適なビジネス・プロセスが定義されると、既存のコンピュータ・ソフトウェア・システム／サード・パーティ・ソフトウェア・システムのビジネス・プロセスへの秩序だったマッピングは、機能性のギャップを実証する場合がある。既存のコンピュータ・ソフトウェア・システム／サード・パーティ・システムが、ビジネス・プロセスから決定付けられた機能要件を満たすことができない場合、ギャップが存在する。これらのギャップは、特定の業界および顧客のニーズを、プログラミングせず構成によって満たすために、ソリューション・ライブラリ構成要素を拡張することによって、また、現行ソリューションを統合することによってソリューション・ライブラリの構成要素で埋められる。一旦、ギャップが埋められると、そのコンピュータ・ソフトウェア・システムは動作可能になり、ユーザのビジネス・プロセス全体に及ぶ。

Description

【発明の詳細な説明】

【０００１】 （発明の背景） 本発明は、一般に、コンピュータ・プログラムに関し、詳細には、個人がコン
ピュータ・プログラムを書くことを必要とせずに業務用コンピュータ・ソフトウ
ェアを実行できるようにする方法および装置に関する。

【０００２】 現在、競争上の優位性は、柔軟かつ動的なビジネス・プロセスの恩恵を受ける
企業にある。残念ながら、現代の多くのサプライ・チェーンのソリューションは
、柔軟かつ動的な環境をサポートすることができない。多くの普及しているソフ
トウェア・パッケージは、顧客の業務をソフトウェアに合わせるよう顧客に強い
ている。この要求によって、実施コストとアップグレード・コストは途方もなく
高くなり、また、顧客の業務の変更は信じられないほど手際の悪いものとなる。
すなわち、顧客の業務は、ソフトウェアによって限定されているのである。

【０００３】 柔軟かつ動的であるために、顧客は何か全く異なるものを必要とする。顧客は
、ソフトウェアの発売に関係なく、自企業の特定のニーズに合わせてソフトウェ
アをたやすく形成し（この逆は行わない）、業務を遂行する方法を動的に（その
場で）変更することができる標準ソフトウェアを必要とする。顧客は、諸企業（
パートナー）および諸システムの全体にわたってビジネス・プロセスを首尾よく
管理すること、および、サプライ・チェーンを成功に導くために顧客が作業に使
用する多くのシステムを統合することも必要とする。現世代のサプライ・チェー
ン・ソフトウェアは、これらのニーズには全く応じることができない。

【０００４】 さらに、企業は、現代において、実施、監視、および改善のためのサプライ・
チェーンのプロセスをモデル化すること、諸企業全体にわたってサプライ・チェ
ーンのプロセスおよびデータを共有すること、企業の特定のタスクおよびニーズ
を満たすように従業員の作業環境をモデル化すること（すなわち、顧客は拡張可
能なソリューションを必要とする）、企業特有のビジネス・プロセスのモデルか
らサプライ・チェーンのソリューションを生成すること、複数のソフトウェア・
システム全体にわたってビジネス・プロセスを管理すること、動的であること（
すなわち、非常に迅速に変更し、あるいは反応することができること）、および
標準でありながら彼らの企業に合ったサプライ・チェーン・ソリューションを有
することを必要とする。

【０００５】 以下の節は、これらの要求をより詳細に説明する。例えば、ある大手コンピュ
ータ・ハードウェア製造業者は、直接注文を処理する非常に特殊な方法を有して
いる。しかし、彼らのプロセスは、同業界の他の企業におけるプロセスとは異な
る可能性が非常に大きい。彼らは、希望する方法で自社の業務を運営する自由と
、その自由をサポートするソフトウェアとを必要としている。さらに、「今すぐ
注文、明日はお手もとに、」のような個々の企業の理念は、ソフトウェアはサポ
ートすべきだが、すべての企業にこれを強いるべきではない非常に特殊な注文お
よび配達方法を要求する。

【０００６】 企業は、さらに、変更またはプロセスの影響を、その変更を実施せずに確認す
るために、ｗｈａｔ ｉｆを実行することができる。ｗｈａｔ ｉｆを使用する
ことによって、企業は業務を行う方法を安価に最適化することができる。企業は
、業務をサポートするソフトウェアに集中するのではなく、業務に集中できるこ
とが必要である。すなわち、ソフトウェアは、透過的であり、かつ、企業がその
業務を効率よく運営できるようにする必要がある。この要件に満たないソフトウ
ェア・ソリューションはどのようなものであっても受け入れられない。

【０００７】 企業は、サプライ・チェーンのプロセスおよびデータを共有する必要がある。
多くの企業が、自社自ら処理するよりも、特定のタスクを上手に処理することが
できる他社と提携することが競争上の優位性を得る１つの方法であるということ
を既に学んでいる。すなわち、現代の企業は、提携に関してオープンであるとい
うことである。これは、また、ビジネス・プロセスが企業間の境界線を越えるこ
とをも意味している。企業間の境界線を越えるということは、プロセスをアウト
ソーシングすること、拡張サプライ・チェーンを使用すること、またはいくつも
の別の可能性を意味する場合がある。

【０００８】 ビジネス・プロセスが企業間の境界線を越える場合、データもまた、システム
間の境界線を越えることができなければならない。すなわち、現代のいかなるソ
フトウェア・ソリューションも、多数の技術（例えば、インターネット、ＥＤＩ
、ＢＡＰＩ）との協同作業に対してオープンである必要がある。パートナーまた
は顧客は同じシステムを使用していない場合があるが、それでも尚、そのデータ
で作業することができなければならない。

【０００９】 企業は、従業員の作業環境をカストマイズする必要がある。多くの企業が若干
類似したビジネス・プロセスを有するときでさえ、それらのプロセスを個々の従
業員が遂行する方法は全く異なる場合がある。例えば、大手の企業では、ある従
業員が注文を入力し、別の従業員がＡＴＰチェックを実行し、さらに別の従業員
が請求書を作成することある。しかし小規模な企業では、１人の人物が上記のタ
スクのすべてを実行する場合がある。大手の企業の従業員は、画面または連続す
る画面上の不用なデータの中を無理に進むことを強いられるべきではない。同様
に、小規模な企業の従業員も、３つの別個の取引をコールすることを強いられる
べきではない。

【００１０】 企業は、自社の従業員が作業する特定の環境を決める機会を有するべきであり
、それによって、企業は従業員が自分の職務で成功するために必要なものだけを
提供することになる。そのような環境によって、企業は混乱を解消し、生産性を
向上させ、過失の起こる機会を減らすことができる。さらに当然ながら、企業は
、必要以上の苦労またはコード化なしに、このすべてを行うことができるべきで
ある。

【００１１】 企業は、ビジネス・モデルからサプライ・チェーン・ソリューションを生成す
ることができる必要がある。企業が、最も小さい細目にいたるまでそのビジネス
・プロセスをモデル化する大きな努力を払う場合、そのモデルからそのソフトウ
ェア・ソリューションの一部を自動的に生成することができるならば、それは最
も道理に適うものといえる。異なるシステムでモデルを作り直さなければならな
い（構成しなければならない）というだけのために、苦心して作り上げたモデル
を無視すべきであるという理由はない。

【００１２】 企業は、複数のソフトウェア・システム全体にわたってビジネス・プロセスを
管理する必要がある。統合に伴う難問の１つは、システム間でデータ構造がしば
しば異なることである。

【００１３】 一般に、企業は、分散型の環境において、データ配布を制御すること、および
、プロセス配布を制御することの２つの難問に直面する。例えば大手の飲料製造
業者がレシピを配布し、作業計画を配布し、原料データを配布する場合、そのデ
ータの一部は中央に記憶、維持されるが、そのデータの他の部分は分散される。
例えば、コーラの主要な混合物は中央に維持することができるが、生産データま
たは保管データは複数箇所に維持することができる。別の例として、ジーンズの
製造業者は、ローカル・レベルで製造注文を実行するが、これを企画するのは総
合レベルの中央システムである。現在、この企業は、実際に完成し、在庫のある
ジーンズの数量、サイズに関するグローバルな視点を有していない。

【００１４】 企業は動的であることが必要である。柔軟かつ動的なビジネス・プロセスを維
持することができる企業だけが、競争上の優位性を維持することになる。些細な
刺激や、顧客の気まぐれ、または予期せぬ難問に直面したとき、企業はその業務
運営方法を変更できなければならない。ビジネス・モデルが変更すると、ソフト
ウェアも同様に変更しなければならない。ソフトウェアが、人手によって新しい
コードを書くことで変更する必要がある場合、これは厄介である。さらに、企業
は、ｗｈａｔ ｉｆシナリオを使用して、変更による影響を事前にシミュレート
することもできるべきである。そのようなｗｈａｔ ｉｆシナリオをコード化す
ることは時間を要するが、企業にはそれだけの時間がないか、またそれだけの時
間を捻出することが不可能なことがしばしばである。

【００１５】 標準ソフトウェアに関する１つの利点は、企業がそれを自社開発する必要がな
いということである。多くのソフトウェア・パッケージは、そのソフトウェア・
パッケージの方法でユーザに業務を運営するよう強いるか、あるいは、何が影響
を受けるかをユーザが正確に把握していない場合に、ユーザがコードを詳しく調
べなければそのソフトウェアをカストマイズしたり、修正したりできないように
している。

【００１６】 （発明の概要） プログラミングせずに、ユーザ定義のビジネス・プロセス・モデルに基づいて
、アプリケーションまたはテンプレートまたはカスタム・ソリューションを生成
する方法を図形によって定義する方法および装置。コンピュータ化されたシステ
ムは、プレハブ・ソフトウェア構成要素を使用する。これらの構成要素は、ソリ
ューション・ライブラリに記載されている。ソリューション・ライブラリは、排
他的かつ完全に網羅的な構成要素のリスト（ビジネス・パターン、データ・マッ
ピング・モデル、状態モデル）を含む。これらの構成要素は、業界全体にわたっ
てすべてのビジネス・アプリケーションのための汎用ソリューションを構築する
。プレハブ・ソフトウェア構成要素は、注文要素、資源要素、およびプロセス要
素を添付の状態表と共に含む。これらはビジネス・パターンを構成する。その汎
用性により、これらのパターンは、装置産業からサービス業に至る様々な産業分
野に適用することができる。一例は、ビジネス・パターンの分割注文であろう。
販売注文は加工注文と購入注文に分割される。このプロセスで、実際の注文は「
抽象的な」注文オブジェクトによって表現される。使用される資源要素は、この
注文の分割を実行する人物、またはこの分割を実行するシステムであってよい。
プロセス要素は、この分割を実行する上で準拠する規則を含んでいる。

【００１７】 ソリューション・ライブラリは、諸業界に対する分散型ビジネス・アプリケー
ションの開発と実施を容易にすることを目的としている。ビジネス・アプリケー
ションは、例えば、自動車、装置産業、サービスなどの諸業界に対して分散型マ
スタ・データおよび統合された製造の遂行を約束することができることを含む。

【００１８】 本発明は、最適なビジネス・プロセスの分析を提供する。一旦、最適なビジネ
ス・プロセスが定義されると、既存のコンピュータ・ソフトウェア・システム／
サード・パーティ・ソフトウェア・システムのビジネス・プロセスへの秩序だっ
たマッピングは、機能性のギャップを実証する場合がある。既存のコンピュータ
・ソフトウェア・システム／サード・パーティ・システムが、ビジネス・プロセ
スから決定付けられた機能要件を満たすことができない場合、ギャップが存在す
る。これらのギャップは、特定の業界および顧客のニーズを、プログラミングせ
ず構成によって満たすために、ソリューション・ライブラリ構成要素を拡張する
ことによって、また、現行ソリューションを統合することによってソリューショ
ン・ライブラリの構成要素で埋められる。一旦、ギャップが埋められると、その
コンピュータ・ソフトウェア・システムは動作可能になり、ユーザのビジネス・
プロセス全体に及ぶ。

【００１９】 本発明の目的によれば、本明細書で実施され概略的に記載されるように、本発
明は、ユーザがプログラミングすることなく、特定のビジネス・モデルに合わせ
たソフトウェア・コンピュータ・システムをユーザが自動的に生成できるように
するデータ処理システムによって実行される方法であって、１つまたは複数のビ
ジネス・プロセスを有するビジネス・モデルを生成するために、１つまたは複数
のユーザのビジネス・プロセス、ビジネス・オブジェクト、およびビジネス規則
のモデリングを容易にするステップと、そのビジネス・モデルを最適化するステ
ップと、ビジネス・プロセスが既存のコンピュータ・ソフトウェア・システムに
対応しない場合、事前定義されたソフトウェア構成要素ライブラリを使用して、
そのビジネス・プロセスに対して新しいコンピュータ・ソフトウェア・システム
を生成するステップと、ビジネス・プロセスが既存のコンピュータ・ソフトウェ
ア・システムに対応する場合、事前定義された統合ソフトウェア構成要素を使用
して、新しいコンピュータ・ソフトウェア・システムから既存のソフトウェア・
システムに統合コードを生成するステップとを含む方法に関する。

【００２０】 本発明の目的によれば、本明細書で実施され概略的に記載されるように、本発
明は、コンピュータ化された方法であって、諸業界全体にわたってすべてのビジ
ネス・アプリケーションに対してコンピュータ・ソフトウェア・システムを生成
するための、相互排他的かつ完全に網羅的な（ＭＥＣＥ）ソフトウェア構成要素
を提供することと、一般に使用される既存のパッケージ化されたソフトウェア・
システムに対して、統合コードを既存のソフトウェア・システムに生成すること
を提供することを含む方法に関する。

【００２１】 本発明の利点は、一部には以下の説明に記載され、一部にはその説明から明白
になり、または本発明の実施によって学ぶことができる。本発明の目的および利
点は、頭記の特許請求の範囲および相当部分で特に指摘される要素および組み合
わせによって実現され、獲得される。

【００２２】 本明細書に組み込まれ、その一部を構成する添付の図面は、本発明のいくつか
の実施形態を示しており、記述と共に本発明の原理を説明することに役立つ。

【００２３】 （実施形態の詳細な説明） 次に、本発明のいくつかの実施形態に関して詳細に参照するが、その実施形態
を添付の図面に示す。使用可能な場合はいつでも、同一または類似の部分を示す
ために全図面において同一の参照番号を使用する。

【００２４】 Ａ．総論 本発明は、会社員または初心プログラマーがビジネス・プロセスをモデル化し
、そのビジネス・プロセスに関するソフトウェアを設計することを可能にする。
以下の議論は、本発明によるソフトウェアが動作する一般的な環境に関する。そ
の後の議論は、本発明の特定の実施形態に関する。

【００２５】 図２１は、本発明の一実施形態を実施する例示的データ処理システム２１００
を示すブロック図である。データ処理システム２１００は、ネットワーク２１１
４を介して他のシステムと通信する。ネットワーク２１１４は、インターネット
、ＷＡＮ、ＬＡＮ、ワイヤレス・ネットワーク、セルラ電話ネットワーク、無線
周波数ネットワーク、または接続中のいかなる他の適切なネットワークであって
よい。システム２１００は、少なくとも１つのプロセッサ２１０２および記憶装
置２１０４（メモリなど）を含む。システム２１００の記憶装置２１０４は、１
つまたは複数のビジネス・パターン２１５０、１つまたは複数のビジネス・プロ
セス・テンプレート２１５２、１つまたは複数の業界テンプレート２１５４、１
つまたは複数の統合テンプレート２１５６、および少なくとも１つの顧客テンプ
レート２１５８を含めて、様々なソフトウェアおよびデータ構造を含む。記憶装
置２１０４は、本明細書に記載の方法およびデータ構造を実施するために必要な
ソフトウェアも含む。記憶装置２１０４（または類似の記憶装置）に記憶されて
いるコンピュータ・プログラムの命令がプロセッサ２１０２（または別の適切な
プロセッサ）によって実行されるときに、本発明の記載された実施形態のステッ
プが実行される。

【００２６】 システム２１００は、キーボード、タッチスクリーン、マウスなどの少なくと
も１つの入力装置２１１８も含む。システム２１００は、プリンタ、表示画面な
どの少なくとも１つの出力装置２１２０も含む。システム２１００は、コンピュ
ータ可読媒体入力装置２１２２およびコンピュータ可読媒体２１２４も含む。コ
ンピュータ可読媒体２１２４は、命令および／またはデータ構造および／または
オブジェクトを記憶している任意の適切な媒体であってよい。これらの命令その
他は、コンピュータ可読媒体２１２４から記憶領域２１０４にロードされる。命
令その他は、ネットワーク接続２１１４を介して搬送波または類似の信号形式で
記憶領域２１０４にロードすることもできる。したがって、記憶装置２１０４の
命令およびデータは、入力装置、インターネット、ＬＡＮ、またはＷＡＮなどの
ネットワークを介して記憶装置にロードすることができ、または、フロッピー（
登録商標）・ディスク、ＣＤ ＲＯＭ、または他の適切なコンピュータ可読媒体
などのコンピュータ可読媒体からロードすることができる。命令は、ネットワー
ク接続を介して搬送波形式でダウンロードすることもできる。

【００２７】 システム２１００は、オペレーティング・システム（図示せず）も含む。当業
者には、記憶装置／メモリは、図が見やすいように図示していないアプリケーシ
ョン・プログラム、オペレーティング・システム、データなどの付加的な情報も
含んでいることが理解されよう。データ処理システム２１００（または本明細書
に記載の任意の他のデータ処理システム）は、メモリ、ディスク・ドライブ、キ
ーボード、表示装置、ネットワーク接続、追加のメモリ、追加のＣＰＵ、ＬＡＮ
、入出力ラインなどにある付加的なデータ、ソフトウェア、および／または情報
などの、図示していない多数の要素も含むことが理解されよう。

【００２８】 本発明はいかなる特定の実施態様またはプログラミング技術に限定されるもの
ではなく、また、本発明は本明細書に記載の機能性を実施するための任意の適切
な技術を使用して実施することができることが理解されよう。本発明は、任意の
適切なプログラミング言語またはプログラミング技術を使用して任意の適切なオ
ペレーティング・システムで実施することができ、また、ハードウェア、ソフト
ウェア、またはハードウェアおよび／またはソフトウェアの任意の適切な組み合
わせとして実施することができる。

【００２９】 Ｂ．より詳細な議論 コンピュータ化されたシステムは、プログラミングせずに、ユーザ定義のビジ
ネス・プロセス・モデルに基づいてアプリケーションまたはテンプレートまたは
カスタム・ソリューションをどのようにして生成するかを図形による方法で定義
するものと規定されている。このシステムは、ソリューション環境と呼ばれる（
好ましい一実施形態は「Ｓｋｖａソリューション環境」と呼ばれる）。このコン
ピュータ化されたシステムは、ビジネス・プロセス（図４）に設計されたビジネ
ス・オブジェクトを使用して、新しいコンピュータ・ソフトウェア・システムと
既存のコンピュータ・ソフトウェア・システムのデータ・モジュール／データ構
造のマッピングを含み、秩序だった方法でプレハブ・ソフトウェア構成要素を使
用する。これらの構成要素は、ソリューション・ライブラリに記載されている。
（一部の既存ソフトウェアはサード・パーティから入手可能なので、既存のコン
ピュータ・ソフトウェアはサード・パーティ・コンピュータ・ソフトウェアと呼
ばれることがある。）

【００３０】 ソリューション・ライブラリは、排他的かつ完全に網羅的な構成要素（ビジネ
ス・パターン、データ・マッピング・モデル、状態モデル）のリストを含む。こ
れらの構成要素は、その業界全体にわたってすべてのビジネス・アプリケーショ
ンに関する汎用ソリューションを構築する。図２２は、経営資源管理（ＥＲＰ）
データおよびスケジューリング・データがオブジェクト・フレームワークにマッ
ピングされるデータ・マッピングの一例を示す。

【００３１】 プレハブ・ソフトウェア構成要素は、注文要素、資源要素、およびプロセス要
素を、添付の状態表と共に含む。これらはビジネス・パターンを構成する。その
汎用性により、これらのパターンは、装置産業からサービス業に至る様々な産業
分野に適用することができる。一例は、ビジネス・パターンの分割注文であろう
。販売注文は加工注文と購入注文に分割される。このプロセスで、実際の注文は
「抽象的な」注文オブジェクトによって表現される。使用される資源要素は、こ
の注文の分割を実行する人物、またはこの分割を実行するシステムであってよい
。プロセス要素は、この分割を実行する上で準拠する規則を含んでいる。

【００３２】 ソリューション・ライブラリは、諸業界に対する分散型ビジネス・アプリケー
ションの開発および実施を容易にすることを目的としている。ビジネス・アプリ
ケーションは、例えば、自動車、加工産業、サービスなどの諸業界に対して分散
型マスタ・データおよび統合された製造の遂行を約束することができることを含
む。

【００３３】 ソリューションの構成は、ソリューション環境を使用することによって達成さ
れる。この環境は、最適なビジネス・プロセスの秩序だった分析である。一旦、
最適なビジネス・プロセスが定義されると、既存のコンピュータ・ソフトウェア
・システム・ソフトウェアのビジネス・プロセスへの秩序だったマッピングは、
機能性のギャップを実証する場合がある。既存のコンピュータ・ソフトウェア・
システムが、ビジネス・プロセスから決定付けられた機能要件を満たすことがで
きない場合は、ギャップが存在する。これらのギャップは、特定の業界および顧
客のニーズを、プログラミングせず構成によって満たすために、ソリューション
・ライブラリ構成要素を拡張することによって、また、現行ソリューションを統
合することによってソリューション・ライブラリの構成要素で埋められる。

【００３４】 一旦、ギャップが埋められると、そのコンピュータ・ソフトウェア・システム
は動作可能になり、ビジネス・プロセス全体に及ぶ。

【００３５】 様々な業界が、特定のビジネス・アプリケーションに対して特定の要件を有す
るようである。諸業界全体にわたって、本発明者らは完全に網羅的かつ相互排他
的な共通ビジネス・パターンおよび単一データ・モデルのリストがあることに気
付いた。これらは、すべての業界およびビジネス・アプリケーションにおける細
目を満たすために拡張することができる。このビジネス・パターンは、網羅的で
あるため、すべての実現可能なビジネスをカバーする。これらは排他的なので、
所与の状況で適切なのは１つだけである。

【００３６】 ソリューション環境は、顧客のビジネス・プロセス・モデルに基づいてビジネ
ス・アプリケーションを構築することができる固有の方法および固有のツール・
セットからなる。ビジネス・プロセス・モデルは、ビジネス階層、ビジネス・オ
ブジェクト、およびビジネス規則の定義を含む。

【００３７】 ソリューションは、ビジネス・パターンを使用して構成される。この構成は、
以下のステップを含む固有の方法によって遂行される。 ・顧客または業界のビジネス・プロセス、ビジネス・オブジェクトおよびビジネ
ス規則をモデル化する。このモデルは、エンド・ユーザが自分のビジネス・プロ
セスを実行する方法の図形表現である。 ・ビジネス・プロセス・モデルを最適化するステップ。 ・ソリューション・ギャップ分析は、既存ソフトウェア・システムによって、ビ
ジネス・プロセスのどの部分がカバーされ、どの部分がカバーされないかを定義
する。 ・ビジネス・プロセスが既存のコンピュータ・ソフトウェア・システム内に見出
されない場合、事前定義されたソフトウェア構成要素ライブラリを使用して、ビ
ジネス・プロセスから新しいコンピュータ・ソフトウェア・システムを生成する
。 ・ビジネス・プロセスが既存のコンピュータ・ソフトウェア・システム内でカバ
ーされる場合、事前定義された統合ソフトウェア構成要素を使用して、新しいコ
ンピュータ・ソフトウェア・システムから既存のコンピュータ・ソフトウェエア
・システムに統合されたコードを自動的に生成するステップ。

【００３８】 この方法において使用されるソリューション環境は、プログラミングを必要と
せずに、ビジネス・アプリケーションの生成および構成のための環境を提供する
。その環境は以下のものを含む。 ・ビジネス・プロセス・モデリングおよび最適化 ・ビジネス・オブジェクト構成 ・クロス既存ソフトウェア・システム統合およびデータ・マッピング ・グラフィカル・ユーザ・インターフェース構築

【００３９】 この方法は、機能性のギャップを埋めるためにブロックを構築する際に、ビジ
ネス・パターンおよびビジネス・プロセス・テンプレートをさらに活用する。

【００４０】 コンピュータ・ソフトウェア・システムの構成の図形表現を図１から４に示す
。顧客のソフトウェア・ソリューションの秩序だった生成は、そのビジネス・プ
ロセスの図形表現から開始される。そのモデルは、顧客または業界に特有のビジ
ネス・オブジェクト（例えば、ビジネス・オブジェクト１０２）およびビジネス
規則（例えば、ビジネス規則１０４）によって構築される（図１）。

【００４１】 ビジネス・プロセス２０２において、様々なビジネス・プロセスをソフトウェ
ア・システムにマップし、既存ソフトウェア／サード・パーティ・ソフトウェア
・システムによってビジネス・プロセスのどの部分がカバーされていないか２０
４を調べる（図２）。

【００４２】 図２で発見されるべき機能性のギャップは、ソフトウェア・システムによって
埋められる必要がある。機能性のギャップを埋めるために、本発明者らは、ビジ
ネス・プロセス・テンプレート、業界テンプレート、および統合テンプレートを
提案する。これらは、ソリューション環境３０２を使用してアセンブルされ、構
成される。この環境は、ビジネス・プロセス・モデリングおよびシミュレーショ
ン環境、ビジネス・オブジェクト構成環境、クロス・ソフトウェア・システム統
合およびデータ・マッピング環境、およびユーザ・インターフェース構築環境を
含む（図３）。

【００４３】 最終ステップは、事前定義された統合ソフトウェア構成要素を使用して、新し
いコンピュータ・ソフトウェア・システムからサード・パーティのソフトウェア
・システムへの統合コードの生成である。これは、ビジネス・プロセスに設計さ
れたビジネス・オブジェクトを使用して、新しいコンピュータ・ソフトウェア・
システム４０２とサード・パーティのコンピュータ・ソフトウェア・システム４
０４のデータ・モデル／データ構造のマッピングを含む（図４）。

【００４４】 １ ソリューション環境 ソリューション環境は、コンピュータ・ソフトウェア・システムを構成するツ
ールを含む。それらのツールを機能させるために固有の方法が使用される。この
方法は、ビジネス・プロセス定義に始まり、ソリューション環境を利用すること
によって、コンピュータ・ソフトウェア・システムを生成する。この方法を図５
から１１に図形表現する。図５は、この方法で取られる主要ステップを詳述する
。ブロックのそれぞれを、以下のパラグラフでさらに詳述する。以下のパラグラ
フを参照するための凡例を図６に示す。

【００４５】 １．１ 「ｔｏ−ｂｅ」プロセスのモデル化 上述のステップをさらに詳述するのは、図７の「ｔｏ−ｂｅ」モデルの定義で
ある。ｔｏ−ｂｅモデルが定義されると、このモデルのシミュレーションは最適
ソリューションをもたらし、このビジネス・プロセス・モデルを最適化する。ビ
ジネスの機会のリストを定義し、それら機会に基づいて代替シナリオを定義し、
そのシナリオをシミュレートし、それが適切なソリューションかどうかを確認す
る。一旦確認されて最適であることが判明すると、ここで見出されたソリューシ
ョンは次のステップへの、このビジネス・プロセスに合わせるにはどのシステム
が選択されるべきかという入力の役割を果たす。

【００４６】 例示的ビジネス・プロセスを図８に示す。この実施形態では、注文は入ってき
て処理される。注文処理より１レベル下は、その注文のクレジットをチェックす
るプロセスである。この実施形態は、ビジネス・プロセス、およびアクション、
イベント、および資源などのモデルの様々な要素を示す。

【００４７】 １．２ システム選択 ビジネス・プロセスをコンピュータ・ソフトウェア・システムにマップするた
め、以下の手続きが行われる。 図９の異なるビジネス・プロセスにおいて、コンピュータ・ソフトウェア・シ
ステムが、ビジネス・プロセスによって要求される要件に照らして選択される。
ビジネス・プロセスが、既存のコンピュータ・ソフトウェア・システムの中にな
い場合、事前定義されたソフトウェア・コンピュータ・ライブラリを使用してビ
ジネス・プロセスから新しいコンピュータ・ソフトウェアを生成する。

【００４８】 ビジネス・プロセスが、既存のコンピュータ・ソフトウェア・システム／サー
ド・パーティ・ソフトウェア・システムの中でカバーされている場合には、事前
定義された統合ソフトウェア構成要素を使用して、新しいコンピュータ・ソフト
ウェア・システムからサード・パーティ・コンピュータ・ソフトウェア・システ
ムへの統合コードを自動的に生成する。

【００４９】 １．３ 詳細なモデル化 詳細なモデル化は、図７のプロセスを介して獲得されるビジネス・プロセスか
ら、プログラミングなしに、カスタム・ソフトウェア・コンピュータ・システム
を構成するため、ソリューション・ライブラリのどの要素が適用される必要があ
るかを定義することに向けての遷移である。図１０が、詳細なモデル化ステップ
の要素を説明する。 図１０で様々な用語が使用されている。以下に、これらの用語を定義する。便
宜のため、用語は、太字で示し、テキストの中で目立つようにしている。

【００５０】 （ビジネス・プロセスおよびビジネス・オブジェクト） ビジネス・プロセスは、ユーザまたはコンピュータ・ソフトウェア・システム
によって行われるビジネス活動を記述することが可能である。ビジネス・プロセ
スは、他のビジネス・プロセスの組み合わせから構成される。ビジネス・オブジ
ェクトは、動的情報をビジネス処理の出力として記憶するデータ構造である。ビ
ジネス・オブジェクトに含まれる情報、属性は、ビジネス規則およびビジネス処
理のための入力として使用される。ビジネス処理は、ビジネス・オブジェクトに
対して行われる処理であり、そのオブジェクトに関連する状態を変化させること
が可能である。ビジネス規則は、従う必要のある判断パターンを定義する。

【００５１】 これらの異なる要素が、図１１に示され、図１１は、それらの要素の依存関係
も明示している。属性は、データ構造定義の基本構成である。属性は、抽象デー
タ・タイプを定義する。例えば、図１２は、オブジェクト・ファシリティに対す
るいくつかの属性、識別子、名前、および削除されたか否かの記述を示す。各デ
ータ構造は、アスペクトと呼ばれる属性のいくつかのオプションの論理グループ
から構成される。

【００５２】 状態モデルは、ビジネス・オブジェクトがその存続期間中に経験する１組の状
態の点でビジネス・オブジェクトの動的挙動を定義する。ビジネス・オブジェク
トに対する外部イベント−ユーザまたはシステムによって送信された−が、目標
ビジネス・オブジェクトに関連する状態モデルの中で定義された遷移をトリガす
る。トリガされる遷移は、イベントが送達された時点におけるビジネス・オブジ
ェクトのおかれている状態に依存する。トリガ規則条件（遷移に関連する）が、
真であると評価された場合、遷移に関連する処理が実行され、ビジネス・オブジ
ェクトをそのライフ・サイクルに沿って押し進める。ビジネス・オブジェクトの
状態に関連する各遷移は、１つの遷移が取られる（条件が真であると評価される
）か、または全く遷移が取られない場合、イベントが廃棄されるまで順に評価さ
れる。

【００５３】 図１３は、注文のための状態モデルを示している。異なる見方は、どのように
注文が、ＦＲＯＭ状態からＴＯ状態に変るかである。図１４を参照されたい。Ｄ
ＭＯは、Ｄｅｔａｉｌｅｄ Ｍａｎｕｆａｃｔｕｒｉｎｇ Ｏｒｄｅｒである。

【００５４】 ユーザ対話スクリーンを備えたユーザ・インターフェースが、最後に定義され
る。図１５が、ユーザ・インターフェイス、顧客需要注文、および注文の一部を
満たすために提案される製造を示している。

【００５５】 ４ ソフトウェア構成要素 ４．１ 要約 ソリューション・ライブラリは、１組のソフトウェア構成要素を含む。ソフト
ウェア構成要素は、リソース要素、注文要素、およびプロセス要素であり、以下
により詳細に説明する。ビジネス・アプリケーション・ライブラリは、ビジネス
・プロセス・テンプレート、業界テンプレート、統合テンプレートを形成するビ
ジネス・パターンとビジネス・オブジェクトの事前構成されたアセンブリである
。ライブラリは、以下のような業界中立の需要供給に関連する問題を指向してい
ることが可能である。 ・製造注文計画 ・製造注文スケジューリング ・ＡＴＰ検査 ・メンテナンス・スケジューリング ・製造注文の実行および確認 ライブラリは、以下を含む。 ・ソフトウェア構成要素に編成された基本オブジェクトおよびメソッド ・再使用可能なドメイン・レベルのビジネス・プロセス・ソフトウェア構成要素

【００５６】 ビジネス・パターン 業界テンプレート、ビジネス・プロセス・テンプレート、および統合テンプレ
ートにアセンブルされたビジネス・パターンのグループ

【００５７】 ４．２ ソフトウェア構成要素定義 ソフトウェア構成要素は、ソリューション・ライブラリの中のビジネス・オブ
ジェクトである。ソフトウェア構成要素には、リソース要素、注文要素、および
プロセス要素が含まれ、様々な形で互いに関連している。これらの関係は、オブ
ジェクト階層を定義する。以上の３つのオブジェクトは、企業のビジネス・オブ
ジェクトおよびビジネス・プロセスを表現する仕方の抽象性が非常に高い。

【００５８】 ソフトウェア構成要素は、以下の性質を有していなければならない。 ・独立、つまり、１つの構成要素の構成が、その他の構成要素の構成に影響しな
い。 ・相互排他的、つまり、ソフトウェア構成要素の間で概念上の重なり合いが存在
しない。したがって、特定の１つの情報を記憶すること、または特定の機能を実
行することを担う厳密に１つのオブジェクトが、ソリューション・ライブラリの
中に存在する。 ・完全に網羅的、つまり、予期されるすべての種類のオブジェクトおよびビジネ
ス活動を担う１つの部分がソリューション・ライブラリの中に常に存在する。

【００５９】 １．１．１ ソフトウェア構成要素リスト リソース要素は、ビジネス活動を実行する手段、例えば、作業センタ、ツール
、原材料、完成した製品、および廃棄物である。リソース要素は、グループ化す
ることができる。リソース要素をグループ化するための様々な基準、例えば、製
品グループおよび組織単位が存在する。

【００６０】 注文要素は、通信するパートナが、サプライ・チェーンの見方における総合お
よび場所の違いによって隔てられた現実世界における判断の通信および追跡に関
するソフトウェア構成要素である。

【００６１】 プロセス要素は、どのようにビジネス活動を実行することができるかを記述す
るのに使用される。関与の（サブ）ビジネス活動の相対的タイミングおよび／ま
たは条件付きタイミングが、この記述の重要部分である。ビジネス規則は、プロ
セスが、どの規則に従ってどのように実行されるかを定義する。

【００６２】 例として、販売注文が入り、製造注文と購入注文に分割される。２種類の物理
的注文（製造および購入）が、抽象的注文オブジェクトによって表現され、注文
の分割が行われる部署がリソースであり、またプロセス要素は、企業規則に従っ
てどのように注文を分割するかに関する情報を保持することになる。この例では
、使用されるリソースは、プロセス要素を介して処理および注文を行う作業セン
タである。

【００６３】 １．０．０ 事前定義されたアスペクトおよび属性 すべてのソフトウェア構成要素は、様々な事前定義されたアスペクトおよび属
性を有することが可能である。属性は、そのオブジェクトに属するデータを含む
データ・フィールドである。属性は、論理的順序でグループ化してアスペクトを
形成することができる。例えば、注文は、自らに対して事前定義された以下のア
スペクトを有する。 ・注文正当化 注文の正当化部分は、注文の存在の理由を記述する。正当化セクションは、その
注文がインスタンス化されることを生じさせた他の注文に対するリファレンスを
含む。また、正当化セクションは、納期、製造されるべき製品と数量も含む。 ・注文判断 注文要素の判断部分は、注文の処理に関連する判断を収集する。これらの判断は
、注文にリンクされた予想されるプロセス、および注文の予想される納期に関す
る判断を含むことが可能である。 ・注文進行 注文要素の進行部分は、注文の履行から報告される追跡情報を保持するために使
用される。この情報は、個々の注文正当化を使用して１つの注文から上位の注文
に伝播される。

【００６４】 注文の事前定義された属性の例を以下に提供し、図１６に記載する。販売注文
が、購入注文および総合製造注文につながる。したがって、注文正当化部分は、
図１６でそうであるように、注文ネットワークに関する情報を含むことになる。
注文ネットは、販売注文に基づいて生成される注文のネットワークであり、注文
を他の注文に分けたものである。

【００６５】 販売注文の判断アスペクトは、その注文をいつ送る必要があるかないかの情報
、または製造注文上の注文を満たすために行わなければならないプロセスに対す
るリファレンスを含むことが可能である。 進行アスペクトは、製造注文上の所与の時点で製造されている総量などの注文
の実際の進行に関連するデータを保持する。

【００６６】 １．０．０ 特定のソリューションに関するアスペクトおよび属性 例えば、購入注文上で、特定のコンピュータ・システムに関する特定の属性を
定義する。図１７のテーブルにおいて、注文の例を注文に関するいくつかの属性
および正当化アスペクトで拡張している。 データの拡張は、図１８に記載するいくつかの業界の細目によって進められる
ことが可能である。

【００６７】 １．０ ビジネス・パターン ビジネス・パターンは、分散環境で汎用機能、システム統合機能、および業界
特有の機能性を提供することにより、ソフトウェア構成要素を補完する。図１９
は、ソフトウェア構成要素の下でカバーされる様々な要素の全体的構造、ならび
にどのようにそうれらの要素が階層にグループ化されるかを示す。図は、ビジネ
ス・パターン、その構成要素、およびどうようにビジネス・パターンがビジネス
・プロセス・テンプレートを構築するかをカバーしている。

【００６８】 ビジネス・パターンはサブ・ビジネス・パターンから構成されている。ビジネ
ス・パターンは、リポジトリの中のオブジェクト、ユーザ、およびエージェント
と対話する。この対話に関するインターフェースは、ビジネス・パターン内の役
割として定義される。ビジネス・パターンを実行するため、スクリプト記述言語
が、ビジネス・パターンの中で定義された役割を演じるオブジェクト、ユーザ、
およびエージェントを識別する情報を提供する。役割とプレーヤの間の通信は、
役割アダプタを使用して行われ、役割アダプタにより、ビジネス・パターン使用
に対する「プラグ・アンド・プレイ」手法が可能になる。これにより、ビジネス
・パターンを再利用できる度合いが高まる。

【００６９】 また、ビジネス・パターンの挙動に影響を与える条件も使用される。条件は、
ビジネス・パターン自体、ビジネス・パターンの役割に関連するオブジェクト、
ユーザ、またはエージェントに関連していることが可能である。通常、これらの
条件は、ビジネス規則を実施するか、またはビジネス・パターンが使用されるコ
ンテキストに特有のアルゴリズムを提供する。

【００７０】 役割アダプタは、特定の要件に関するオブジェクト上のインターフェースを適
合させるのに使用される。役割アダプタが提供することができる適合のタイプに
は、以下が含まれる。 イベント変換−オブジェクトによって生成されたイベントを受信側が認識する
ことができないとき。 用語変換−オブジェクト上の汎用インターフェースを問題ドメインの期待に応
じて提示しなければならないとき（例えば、リソース要素が、作業センタとして
提示される）。 データ変換−汎用データが、データ消費者のニーズを満たすように特定の形で
提示されるとき（例えば、ユーザが、特定の言語および特定の国の要件に応じた
テキスト、数値、通貨価値を見る必要がある）。

【００７１】 例えば、計画、製造、または倉庫管理などの多種多様な用途のコンテキストで
、汎用注文生成機能を提供するビジネス・パターンを使用することができる。こ
のビジネス・パターンは、特定のコンテキストでパターンがどのように挙動する
かを支配する条件を介して、各用途ごとにカストマイズすることができる。注文
生成には、新しい注文表現を作成し、注文ＩＤ生成を管理することを担う「注文
作成」サブパターンの使用が関与することが可能である。「注文作成」は、注文
ＩＤ生成条件を使用して、どのように注文ＩＤが生成されるかをカストマイズす
ることを可能にする。

【００７２】 ４．４ ビジネス・プロセス・テンプレート ビジネス・プロセス・テンプレートは、１組の認識されたビジネス慣行を実施
する１組のビジネス・パターンである。ビジネス・プロセス・テンプレートは、
特定の業界に関連していることが可能であり、その場合、業界特有のビジネス・
プロセス・テンプレートとなる。また、ビジネス・プロセス・テンプレートは、
ソフトウェア・システムの統合イネーブラ(enablesr)の働きもすることができ、
その場合は、統合導出ビジネス・プロセス・テンプレートである。図２０は、ビ
ジネス・プロセス・テンプレート構成の全体図である。特定の顧客のケースでは
、コンピュータ・ソフトウェア・システムは、拡張されたビジネス・プロセス・
テンプレートから構成されている。図２３は、ユーザがビジネス・オブジェクト
を設計できるようにするプロセスの例としてのスクリーン・ショットである。

【００７３】 ５ 一般的用語 スクリプト記述言語（ＳＳＬ） ＳＳＬは、汎用スクリプト記述言語である。ＳＳＬは、以下の目的で使用される
。 ビジネス・プロセスをモデル化するため、 エージェントの挙動を記述するため、および 記述的ビジネス・プロセスを定義するため。

【００７４】 責任系統 責任系統は、所与の機能またはサービスをオブジェクトが提供できない場合、
要件をどれか別のオブジェクトに渡すことができるシステムの挙動を記述する。
後者のオブジェクトは、その要件を取り扱うか、またはそれを別のオブジェクト
にさらに渡すことができる。

【００７５】 この技法は、階層のルートにおいて一般的技法が実施され、階層が拡張して特化
するにつれて、より特定の技法がオプションとして実施されることが可能なオブ
ジェクトの階層に関連して使用されるとき、非常に強力である。

【００７６】 ビジネス・パターンは、責任系統の関係のなかで編成することができる。これ
は、階層に応じてビジネス・パターンをルックアップすることを可能にして、ユ
ーザが、システム内の個別のすべてのオブジェクトに関するポリシーを定義する
必要性を減らすことができる。

【００７７】 制御システム・ラッパ 制御システム・ラッパは、任意の数の外部制御システムとインターフェースを
取らなければならない。しばしば、このシステムは、独自のプロプラエタリの機
構を使用して通信する。外部の制御システムと標準の仕方で通信できるようにす
るため、一方のシステムからの通信を取り、他方のシステムにその通信を転置す
ることができる、ラッパと呼ばれる標準のインターフェースを定義している。そ
のようなインターフェースは、特定のソリューション（テンプレートではなく）
の一部である。ただし、標準のテンプレートは、外部システムに対するインター
フェースが準拠しなければならない標準のフォーマットを定義する。

【００７８】 イベント・プロセス ビジネス・プロセス・モデル化の目的は、イベント・プロセスを導出すること
である。イベント・プロセスを使用して、ビジネス・プロセスの中で定義された
ビジネス活動に沿ってオブジェクト（注文などの）を押し進める。イベント・プ
ロセスはオブジェクトに関する状態モデルとして表現され、スクリプト記述言語
（ＳＳＬ）を使用してビジネス・パターンをスクリプト記述してまとめることに
より、実現される。

【００７９】 役割アダプタ 役割アダプタは、オブジェクト上のインターフェースを特定の要件に対して適
合させるのに使用される。役割アダプタが提供できる適合のタイプには、以下が
含まれる。 ・イベント変換−オブジェクトによって生成されたイベントを受信側が認識でき
ないとき ・用語変換−オブジェクト上の汎用インターフェースを問題ドメインの期待に応
じて提示しなければならないとき（例えば、リソース要素が、作業センタとして
提示される）。 ・データ変換−汎用データが、データ消費者のニーズを満たすように特定の形で
提示されるとき（例えば、ユーザが、特定の言語および特定の国の要件に応じた
テキスト、数値、通貨価値を見る必要がある）。

【００８０】 シナリオ シナリオは、オペレーション上のコンテキストにおいて判断するエージェント
のオペレーション上の挙動を構成するための構成デバイスである。シナリオは、
事前定義された数組の構成データとして記憶される。特定のコンテキストにおけ
る適切なシナリオは、自動的に、または人間のエージェントによって選択される
ことが可能である。編集は、人間のエージェントだけが行うことができる。

【００８１】 テンプレート

【００８２】 コントロール ときとして「ウィジェット(widgets)」と呼ばれるコントロールは、パネルお
よびスクリーンを構築する基本要素である。 例： タイプイン・ボックス、リスト・ボックス、スクロール・バー等

【００８３】 ビジネス・プロセス・テンプレート ビジネス・プロセス・テンプレートは、１組のビジネス・パターンである。業
界ビジネス・プロセス・テンプレートは、多くの場合、業界特有の情報に基づい
て構築される。以下は、どのようにカスタム・コンピュータ・ソフトウェア・シ
ステムが、ソフトウェア構成要素、ビジネス・パターン、および業界ビジネス・
プロセス・テンプレートから構築されるかを示している。 ・需要−供給割当て−ソフトウェア構成要素の低レベル・メソッド ・注文作成−ビジネス・パターン ・製造注文作成−業界テンプレートの一部 ・特定の規則または特定の条件を伴う製造注文作成−カスタム・コンピュータ・
ソフトウェア・システムの一部

【００８４】 識別属性 識別属性は、何らかのユーザ・インターフェース機能に関する目標オブジェク
トを識別するためにエンド・ユーザによって使用される、オブジェクトを一意的
に識別するオブジェクトの属性である。 例： 注文ＩＤは、注文に関する識別属性である。

【００８５】 非識別属性 非識別属性は、オブジェクトを識別するのを助ける非固有のキーであるオブジ
ェクトの属性である。非識別属性は、何らかのユーザ・インターフェース機能に
関する目標オブジェクトを識別するため、エンド・ユーザによって使用される。
通常、この非固有のキーは、ユーザが目標をそこから選択できるオブジェクトの
リストをもたらす。 例： 顧客ＩＤは、注文に関する非識別属性である。

【００８６】 パネル パネルは、スクリーンを構築するのに使用される。パネルは、共通タスクを行
うコントロールと呼ばれるインターフェース・ソフトウェア構成要素のグループ
から構成される。この場合も、構成して、多数のスクリーンで使用することがで
きる１組の標準パネルを提供することによって共通性を活用する。 例： ツリー・ビュー・パネルを使用して、プロセス記述または注文ネットであること
が可能なオブジェクトの階層を見るのが可能である。

【００８７】 スクリーン スクリーンは、主な機能性要素を実行する高レベル構成要素である。スクリー
ンは、異なる機能コンテキストで動作する場合でも、しばしば、オブジェクトを
選択すること、階層を見ること、およびオブジェクトを編集することのような標
準の機能を行う。パラメータ化された標準のスクリーンのライブラリを提供する
ことによってこの類似性を活用し、テンプレート構成において、異なる規則を有
する異なるオブジェクト・クラスにスクリーンを適合させることができるように
する。

【００８８】 モデル化

【００８９】 ビジネス・イベント ビジネス・イベントは、ビジネス・トリガの結果として生じる、システムによ
って生成されるメッセージである。他のビジネス・プロセスが、ビジネス・イベ
ントによって立ち上げられること、またはビジネスを待っていることが可能であ
る。

【００９０】 ビジネス・オブジェクト ビジネス・オブジェクトは、ビジネス・プロセスの入力または出力であるデー
タベースの中のオブジェクトである。ただし、すべてのビジネス・オブジェクト
を識別する必要はなく、「中心的」ビジネス・オブジェクトを識別するだけでよ
い。 例： 製造注文および販売注文

【００９１】 ビジネス・ポリシー ビジネス・ポリシーは、異なるビジネス・ユニットにおける同一のビジネスの
実行がどのように異なるかを記述するビジネス・ステップである。ビジネス・ポ
リシーは、モデラが、異なるビジネス・ユニットに関するビジネス・プロセスを
単一のモデルに抽象化するのを可能にする機構である（例えば、注文は、常にプ
ラント１では分割されるが、プラント２では決して分割されない）。また、ビジ
ネス・ポリシーを使用して同一の参照されるビジネス・プロセスを限定すること
ができる。

【００９２】 ビジネス・プロセス ビジネス・プロセスは、ビジネス・シナリオまたはより高いレベルのビジネス
・プロセスの中のステップである。ビジネス・プロセスは、ユーザによって行わ
れるビジネス活動（ユーザ・プロセス）またはシステムによって行われるビジネ
ス活動（システム・プロセス）を記述することができる。ビジネス・プロセスは
、他のビジネス・プロセスの組み合わせを有する。

【００９３】 ビジネス・プロセス・モデル化 実行される個々のステップに関して、またドキュメントが辿る可能性がある代
替のパスに関して、注文などのビジネス・ドキュメントの流れを通常、追跡する
ビジネス・プロセスの記述。しばしば、既存のプロセスをカバーする「ａｓ ｉ
ｓ」モデル、および新しく設計されたプロセスまたは再構築されたプロセスをカ
バーする「ｔｏ−ｂｅ」モデルが存在する。

【００９４】 ビジネス・プロセス・シミュレーション ビジネス・プロセスの正確さを確認するため、応答時間、リソース利用率など
の様々なビジネス・メトリックを測定するため、また「ｗｈａｔ−ｉｆ」分析を
行うためのビジネス・プロセス・モデルをシミュレートするコンピュータ化され
たシミュレーション・ツールの使用。

【００９５】 ビジネス規則 ビジネス規則は、流れの中の一時停止または分岐であり、何か（ある条件）に
依存するビジネス・ステップである。この条件は、ビジネス・オブジェクトの状
態（例えば、注文が有効である）、またはビジネス・イベントの出現（例えば、
ＡＴＰ結果が、ワークフローを介して到着した）に基づくことが可能である。

【００９６】 ビジネス・シナリオ ビジネス・シナリオは、ビジネス・ユニットにおける特定の目的を満たす１組
のビジネス・プロセスである。１組のビジネス・シナリオは、当該のビジネス・
ユニットのビジネス活動のすべてを記述する。ビジネス・シナリオは、少なくと
も１つのビジネス・プロセスを含む。

【００９７】 ビジネス・ステップ ビジネス・ステップは、ビジネス・プロセスを補完するのに使用される。２種
類のビジネス・ステップが存在する。 ・ビジネス・トリガ（ワークフロー通知を含む） ・ビジネス規則（待機を含む）

【００９８】 ビジネス・トリガ ビジネス・トリガは、別のビジネス・プロセスを立ち上げる、または別のビジ
ネス・プロセスに何かを行わせるビジネス・イベントを生成するビジネス・ステ
ップである。

【００９９】 ビジネス・ユニット ビジネス・ユニットは、ビジネス階層の単位である。ビジネス・ユニットは、
組織、物理的場所、リソース、または製品であることが可能である。

【０１００】 作業の単位 作業の単位は、本方法によれば、モデラが掘り下げるのを止めた詳細のレベルに
おけるビジネス・プロセスである。技術的には、これは、ビジネス・パターンに
よって機能性が実行されるのが可能なレベルに該当する。機能的には、これは、
以下の基準によって決定される。 ・スクリーンまたはパネル（サブスクリーン）のレベルに到達した ・単一の論理ビジネス活動 ・一時点において１人のユーザによって（またはシステムによって自動的に）行
われる活動 ・取引（ユーザが、「ＯＫ」または「キャンセル」を告げる）と同じサイズ、ま
たは取引より小さいサイズでなければならない。 ・ユーザ関与の最低レベル（「何か」であって、「どのようにか」ではない） ・システムが、ユーザに選択の余地を与えないレベル

【０１０１】 使用ケース 使用ケースは、ビジネス・プロセスの違いに対処するため、オブジェクトに対
する属性をわずかに変更することを必要とする特定の状況である。 例： 注文エントリ使用領域において、新規の注文、再注文、ＥＤＩ注文、注文変更等
のための別個の使用ケースが存在することが可能である。

【０１０２】 状態モデル 状態モデルは、エージェントが従うプログラムの記述である。状態モデルは、
システム構築者が、オブジェクトの特定のステップおよび特定の処理を定義する
のに使用する機構である。 状態モデルは、以下のソフトウェア構成要素を含む。 ・オブジェクトのライフ・サイクルにおける特定の固定ステップまたはオプショ
ンのステップ（状態と呼ばれる）、 ・注文オブジェクトが特定の状態にあるときに予期することができる特定のイベ
ント、 ・ある処理が行われるには、まず満たされなければならないあらゆる特定の条件
、 ・条件が満たされたとき、コンピュータ・ソフトウェア・システムが実行しなけ
ればならない特定の処理。指定されなければならない１つの非常に重要な処理は
、処理が完了した後、オブジェクトの新しい状態が何であるかである。さらに、
・処理を実行しているときに生じる可能性のある例外、および新しい状態が何で
あるか。 ただし、すべてのタイプのエージェントの挙動が、状態モデルによって記述でき
るわけではない。状態モデルは、特別タイプのエージェントにおいて、すなわち
、オブジェクトが他のエージェントによって作成された後、オブジェクトの状態
ライフ・サイクル中、オブジェクトを追跡または誘導するエージェントにおいて
だけ使用される。

【０１０３】 要するに、本発明により、ユーザは、プログラミングなしにユーザ定義のビジ
ネス・プロセス・モデルに基づき、どのようにアプリケーションまたはテンプレ
ートまたはカスタム・ソリューションを生成するかをグラフィックな形で定義す
ることができるようになる。コンピュータ化されたシステムは、プレハブ・ソフ
トウェア構成要素を使用する。この構成要素は、ソリューション・ライブラリの
中で記述される。ソリューション・ライブラリは、排他的で完全に網羅的な構成
要素のリストを含む（ビジネス・パターン、データ・マッピング・モデル、状態
モデル）。この構成要素は、業界全体のすべてのビジネス用途に関する一般的ソ
リューションを構築する。既成のソフトウェア構成要素は、注文要素、リソース
要素、およびプロセス要素を含み、状態テーブルが付加されている。ソフトウェ
ア構成要素は、ビジネス・パターンに構成される。このパターンは、その一般的
性質のため、プロセス産業からサービス事業まで様々な業界の領域に適用するこ
とができる。

【０１０４】 ソリューション・ライブラリは、産業のための分散ビジネス・アプリケーショ
ンの開発および実装を円滑にすることを目的とする。ビジネス・アプリケーショ
ンには、例えば、Ａｖａｉｌａｂｌｅ ｔｏ Ｐｒｏｍｉｓｅ、分散マスタ・デ
ータ、ならびに自動車産業、プロセス産業、サービスなどの産業のための統合さ
れた製造実施が含まれる。

【０１０５】 本発明は、最適ビジネス・プロセスの分析を提供する。最適ビジネス・プロセ
スが定義されると、ビジネス・プロセスに対する既存のコンピュータ・ソフトウ
ェア・システム／サード・パーティ・ソフトウェア・システムの組織的なマッピ
ングにより、機能性のギャップを実証することができる。ギャップは、既存のコ
ンピュータ・ソフトウェア・システム／サード・パーティ・システムが、ビジネ
ス・プロセスから要求される機能上の要件を満たすことができない場合、存在す
る。このギャップは、ソリューション・ライブラリの構成要素を拡張して、プロ
グラミングなしに構成を介して特定の業界および特定の顧客のニーズを満たし、
既存のソリューションを統合することにより、ソリューション・ライブラリから
の構成要素で埋められる。ギャップが埋められると、コンピュータ・ソフトウェ
ア・システムは、オペレーション可能であり、ユーザのビジネス・プロセス全体
をカバーする。したがって、本発明は、頭記の特許請求の範囲および同等物の趣
旨および範囲に入るすべてのそのような代替形態、変更形態、および変形形態を
包含するものとする。

【図面の簡単な説明】

【図１】 顧客または業界に特有のビジネス・オブジェクトおよびビジネス規則によって
構成されたビジネス・プロセスのモデルを示すブロック図である。

【図２】 既存ソフトウェア・システムがカバーしないビジネス・プロセスの部分を示す
ブロック図である。

【図３】 ビジネス・プロセス・モデリングおよびシミュレーション環境、ビジネス・オ
ブジェクト構成環境、クロス・ソフトウェア・システム統合およびデータ・マッ
ピング環境、およびユーザ・インターフェース構築環境を示すブロック図である
。

【図４】 ビジネス・プロセスに設計されたビジネス・オブジェクトを使用して、新しい
コンピュータ・ソフトウェア・システムおよび既存のソフトウェア・システムの
データ・モデル／データ構造のマッピングを示すブロック図である。

【図５】 本発明の好ましい実施形態で取られる主要ステップを示す流れ図である。

【図６】 アクションと、それがビジネス・プロセスにどのように関係するかを示す図で
ある。

【図７】 「ｔｏ−ｂｅ」モデルの定義を示す図である。

【図８】 例示的ビジネス・プロセスを示す図である。

【図９】 ビジネス・プロセスによって決定付けられた要件に対して選択されるコンピュ
ータ・ソフトウェア・システムの一例を示す図である。

【図１０】 詳細なモデリングのステップの要素を示す図である。

【図１１】 様々なシステム要素間の依存関係を示す図である。

【図１２】 オブジェクト機能の例示的属性を列挙する図である。

【図１３】 注文に対する例示的状態モデルを示す図である。

【図１４】 注文がＦＲＯＭ状態からＴＯ状態に移動する方法の異なる視点の一例を示す図
である。

【図１５】 顧客の請求した注文と、その注文の一部を満たすために提案された生産を列挙
する、ユーザ・インターフェース画面を示す図である。

【図１６】 注文の事前定義された属性の一例を示す図である。

【図１７】 注文のいくつかの属性および正当化アスペクトによる、注文例の拡張を示す表
である。

【図１８】 ある種の業界の細目がどのようにしてデータの拡張を動かすことができるかの
一例を示す図である。

【図１９】 ソフトウェア構成要素の下でカバーされる様々な要素の全般的な構造、および
それらが階層注文形式でグループ化される方法を示す図である。

【図２０】 ビジネス・プロセス・テンプレート構成の全体像を示す図である。

【図２１】 本発明の一実施形態を実施する例示的データ処理システムを示すブロック図で
ある。

【図２２】 データ・マッピングの一例を示す図である。

【図２３】 ビジネス・オブジェクトをユーザが設計することを容易にする画面の例示的ス
クリーン・ダンプを示す図である。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ， ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ， ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，Ｃ Ｚ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＧＨ ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＳ，ＪＰ，ＫＥ， ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，Ｌ Ｔ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ， ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，Ｕ Ａ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (72)発明者 バルガヴァ，ロヒット アメリカ合衆国・02481・マサチューセッ ツ州・ウェルズレイ・ハンプシャー ロー ド・133 (72)発明者 デボエック，イヴァン アメリカ合衆国・02144・マサチューセッ ツ州・ソメールヴィル・ハイランド アベ ニュ・289・アパートメント・305 (72)発明者 ディロン，ブピンダー・エス アメリカ合衆国・02139・マサチューセッ ツ州・ケンブリッジ・ワトソン ストリー ト・４・アパートメント・３アール (72)発明者 フラレイ，スティーブン・ピイ アメリカ合衆国・01845・マサチューセッ ツ州・ノース アンドヴァー・クロスボウ レーン・134 (72)発明者 グロス，オリヴィエ アメリカ合衆国・02155・マサチューセッ ツ州・メッドフォード・ハーヴァード ス トリート・54 (72)発明者 ジョナス，ジョルグ アメリカ合衆国・02139・マサチューセッ ツ州・ケンブリッジ・アモリー ストリー ト・107・アパートメント・シイ (72)発明者 リプトン，マイケル・ジェイ アメリカ合衆国・02421・マサチューセッ ツ州・レキシントン・ヒル ストリート・ 64 (72)発明者 ルジュングヴェルグ，マグナス アメリカ合衆国・02421・マサチューセッ ツ州・レキシントン・リンカーン ストリ ート・235 (72)発明者 マシューズ，ブライアン・エル アメリカ合衆国・01450・マサチューセッ ツ州・グロトン・ボストン ロード・302 (72)発明者 マックギリヴレイ，ダンカン・エヌ アメリカ合衆国・02139・マサチューセッ ツ州・ケンブリッジ・チェイザム ストリ ート・34 (72)発明者 モエケッシュ，グエンター アメリカ合衆国・02138・マサチューセッ ツ州・ケンブリッジ・マス アベニュ・ 1008・アパートメント・609 (72)発明者 オドネル，ティモシー・ジェイ アメリカ合衆国・01862・マサチューセッ ツ州・ビレリカ・リオ ヴィスタ ストリ ート・３ (72)発明者 ペリー，アラン・チャールズ アメリカ合衆国・01742・マサチューセッ ツ州・コンコード・ソウ ミル ロード・ 49 (72)発明者 タイヒマン，ルッツ ドイツ連邦共和国・69181・ライメン・ク ーフュアシュテンアレー・14 (72)発明者 ヴァン キュジュケロム，ハンス アメリカ合衆国・02446・マサチューセッ ツ州・ブルックリン・サイプレス ストリ ート・47・アパートメント・３ (72)発明者 ジッリ，カジ・オー アメリカ合衆国・02451・マサチューセッ ツ州・ウォルサム・スティアーンズ ヒル ロード・5108 (72)発明者 ジンク，アンドレアス・ダブリュ アメリカ合衆国・02174・マサチューセッ ツ州・アーリントン・プリモス ストリー ト・15 Ｆターム(参考） 5B076 DC04 DD04 【要約の続き】 は、機能性のギャップを実証する場合がある。既存のコ ンピュータ・ソフトウェア・システム／サード・パーテ ィ・システムが、ビジネス・プロセスから決定付けられ た機能要件を満たすことができない場合、ギャップが存 在する。これらのギャップは、特定の業界および顧客の ニーズを、プログラミングせず構成によって満たすため に、ソリューション・ライブラリ構成要素を拡張するこ とによって、また、現行ソリューションを統合すること によってソリューション・ライブラリの構成要素で埋め られる。一旦、ギャップが埋められると、そのコンピュ ータ・ソフトウェア・システムは動作可能になり、ユー ザのビジネス・プロセス全体に及ぶ。

Claims (13)

【特許請求の範囲】
1. 【請求項１】 ユーザがプログラミングすることなく、特定のビジネス・モ
   デルに合わせたソフトウェア・コンピュータ・システムをユーザが自動的に生成
   できるようにするデータ処理システムによって実行される方法であって、 一つまたは複数のビジネス・プロセスを有するビジネス・モデルを生成するた
   めに、ユーザの一つまたは複数のビジネス・プロセス、ビジネス・オブジェクト
   、およびビジネス規則のモデリングを容易にするステップと、 そのビジネス・モデルを最適化するステップと、 ビジネス・プロセスが既存のコンピュータ・ソフトウェア・システムに対応し
   ない場合、事前定義されたソフトウェア構成要素ライブラリを使用してそのビジ
   ネス・プロセスに対して新しいコンピュータ・ソフトウェア・システムを生成す
   るステップと、 ビジネス・プロセスが既存のコンピュータ・ソフトウェア・システムに対応す
   る場合、事前定義された統合ソフトウェア構成要素を使用して新しいコンピュー
   タ・ソフトウェア・システムから既存のソフトウェア・システムに統合コードを
   生成するステップと を含む方法。
2. 【請求項２】 ビジネス・プロセスのモデリングを容易にする前記ステップ
   が、ビジネス・プロセス、ビジネス・オブジェクト、ビジネス階層、およびビジ
   ネス規則を設計することを容易にするステップを含む請求項１に記載の方法。
3. 【請求項３】 ビジネス・モデルを最適化するステップが、 ビジネス・プロセスの代案をシミュレートするステップと、 企業の基幹成功要因を改善する点において、最適なビジネス・プロセスを特定
   するステップと を含む請求項１に記載の方法。
4. 【請求項４】 事前定義されたソリューション・ライブラリを使用してビジ
   ネス・プロセスから新しいコンピュータ・ソフトウェア・システムを生成するス
   テップが、ビジネス・オブジェクトを生成するステップと、ビジネス階層を生成
   するステップと、状態モデルを生成するステップと、ユーザ・インターフェース
   を生成するステップとを含む請求項１に記載の方法。
5. 【請求項５】 事前定義された統合ソフトウェア構成要素を使用して、新し
   いコンピュータ・ソフトウェア・システムからサード・パーティ・ソフトウェア
   ・システムに統合コードを生成するステップが、ビジネス・プロセスに設計され
   たビジネス・オブジェクトを使用して、新しいコンピュータ・ソフトウェア・シ
   ステムおよびサード・パーティ・コンピュータ・ソフトウェア・システムのデー
   タ・モデル／データ構造のマッピングを生成するステップを含む請求項１に記載
   の方法。
6. 【請求項６】 諸業界全体にわたってすべてのビジネス・アプリケーション
   に対してコンピュータ・ソフトウェア・システムを生成するための、相互排他的
   かつ完全に網羅的（ＭＥＣＥ）なソフトウェア構成要素を提供することと、 一般に使用される既存のパッケージ化されたソフトウェア・システムに対して
   既存のソフトウェア・システムに統合コードを生成するためのソフトウェア構成
   要素を提供すること を含むコンピュータ化された方法。
7. 【請求項７】 諸業界全体にわたってすべてのビジネス・アプリケーション
   に対してコンピュータ・ソフトウェア・システムを生成するための、相互排他的
   かつ完全に網羅的なソフトウェア構成要素が、ビジネス・プロセス・テンプレー
   ト、業界テンプレート、および統合テンプレートのソフトウェア構成要素を含む
   請求項６に記載の方法。
8. 【請求項８】 前記ビジネス・プロセス・テンプレートが、ビジネス・オブ
   ジェクト、オブジェクト属性、オブジェクト間の関係、ビジネス・オブジェクト
   状態モデルによって定義されたオブジェクトの構成可能な挙動、ビジネス・オブ
   ジェクトを視覚化する表示パネル、およびテンプレートのソフトウェア機能を提
   供するビジネス・パターンを含む請求項７に記載の方法。
9. 【請求項９】 前記業界テンプレートが、ビジネス・オブジェクト、オブジ
   ェクト属性、オブジェクト間の関係、ビジネス・オブジェクト状態モデルによっ
   て定義されたオブジェクトの構成可能な挙動、ビジネス・オブジェクトを視覚化
   する表示パネル、およびテンプレートのソフトウェア機能を提供するビジネス・
   パターンを含む請求項７に記載の方法。
10. 【請求項１０】 前記業界テンプレートが、業界特有のビジネス・オブジェ
    クト、業界特有のオブジェクト属性、業界特有のオブジェクト間の関係、業界特
    有のビジネス・オブジェクト状態モデルによって定義された業界特有のオブジェ
    クトの構成可能な挙動、ビジネス・オブジェクトを視覚化する業界特有の表示パ
    ネル、およびテンプレートのソフトウェア機能を提供する業界特有のビジネス・
    パターンを含む請求項７に記載の方法。
11. 【請求項１１】 前記統合テンプレートが、ビジネス・オブジェクト、オブ
    ジェクト属性、オブジェクト間の関係、ビジネス・オブジェクト状態モデルによ
    って定義されたオブジェクトの構成可能な挙動、ビジネス・オブジェクトを視覚
    化する表示パネル、およびテンプレートのソフトウェア機能を提供するビジネス
    ・パターンを含む請求項７に記載の方法。
12. 【請求項１２】 前記統合テンプレートが、統合導出ビジネス・オブジェク
    ト、統合導出オブジェクト属性、オブジェクト間の統合導出関係、統合導出ビジ
    ネス・オブジェクト状態モデルによって定義されたオブジェクトの統合導出構成
    可能な挙動、ビジネス・オブジェクトを視覚化する統合導出表示パネル、および
    テンプレートのソフトウェア機能を提供する統合導出ビジネス・パターンを含む
    請求項７に記載の方法。
13. 【請求項１３】 ユーザがプログラミングすることなく、特定のビジネス・
    モデルに合わせたソフトウェア・コンピュータ・システムをユーザが自動的に生
    成できるようにする装置であって、 一つまたは複数のビジネス・プロセスを有するビジネス・モデルを生成するた
    めに、ユーザの一つまたは複数のビジネス・プロセス、ビジネス・オブジェクト
    、およびビジネス規則のモデリングを容易にするように構成されたソフトウェア
    部分と、 ビジネス・モデルを最適化するように構成されたソフトウェア部分と、 ビジネス・プロセスが既存のコンピュータ・ソフトウェア・システムに対応し
    ない場合、事前定義されたソフトウェア構成要素ライブラリを使用してそのビジ
    ネス・プロセスに対して新しいコンピュータ・ソフトウェア・システムを生成す
    るように構成されたソフトウェア部分と、 ビジネス・プロセスが既存のコンピュータ・ソフトウェア・システムに対応す
    る場合、事前定義された統合ソフトウェア構成要素を使用して新しいコンピュー
    タ・ソフトウェア・システムから既存のソフトウェア・システムに統合コードを
    生成するように構成されたソフトウェア部分と を含む装置。