JP2008522294A - ホスト型テイラードバーティカルアプリケーションを提供するための方法および装置 - Google Patents

Abstract

この発明の実施例は、高度に調整されたホスト型バーティカルアプリケーションを提供するための方法および装置を提供する。一実施例によれば、顧客関係管理アプリケーションのための１組の汎用構成オプションが作成され、ユーザに提示される。ユーザは、提供された１組のオプションから１つ以上のオプションを選択し、選択されたオプションは、調整された顧客関係管理アプリケーションを自動的に構成するために使用される。この発明の一実施例については、１組の構成オプションを顧客会社に提供するために、既存のバーティカルからの多数の矛盾するビジネスエンティティおよびプロセスが分解される。顧客会社は提供された構成オプションから選択し、選択された構成オプションに基づいて、高度に調整されたバーティカルが自動的に構成される。

Description

分野
この発明の実施例は一般に、テイラード（tailored）企業ソフトウェアアプリケーションの分野に関し、より特定的には、ホスト型テイラードバーティカルソフトウェアアプリケーションを提供するための方法に関する。

背景
ホスト型ソフトウェアアプリケーションとは、遠隔で記憶され、インターネット上でアクセスされるアプリケーションを意味する。ホスト型アプリケーションは通常、ホスティング会社のサーバ上に記憶され、使用時に顧客会社のローカルコンピュータにダウンロードされる。ホスト型ソフトウェアアプリケーションにより、顧客会社は、ソフトウェアアプリケーションを維持する責任を委ねることができる。

ホスト型であり得るソフトウェアアプリケーションの一タイプは、顧客関係管理（Customer Relationship Management：ＣＲＭ）アプリケーションである。しかしながら、典型的なＣＲＭアプリケーションは、費用効率の高いホスティングにいくつかの障害を提起する。

ＣＲＭアプリケーションとは、会社が顧客関係の局面を管理できるようにする全社的なアプリケーションである。典型的なＣＲＭアプリケーションは、１組のビジネスオブジェクト（エンティティ）と、そのエンティティ上で動作する１組のビジネスプロセス（プロセス）とを提供する。エンティティは、あるビジネスに対する独特の重要事項を表わす。エンティティはたとえば、コンタクト（contact）、アカウント（account）、またはそれらの間の関係を含んでいてもよい。プロセスは、１つ以上のエンティティ上で、および１つ以上のエンティティにわたって動作し、エンティティの起こり得る状態および移行を定義する。プロセスはたとえば、新しいアカウントを開設するためのアカウント・セットアップ・プロセスを含んでいてもよい。

通常、ＣＲＭアプリケーションは、ベースＣＲＭ機能性（ベースＣＲＭ）と呼ばれる一式の販売およびサービス機能性を含む。ベースＣＲＭアプリケーションは、ある特定の業界のニーズに対処するよう専門化または調整（tailored）可能である。そのような業界固有のＣＲＭアプリケーションは、バーティカルＣＲＭアプリケーション（バーティカル）と呼ばれる。さらに、ベースＣＲＭアプリケーションまたはバーティカルは、そのアプリケーションを使用している特定の顧客会社のニーズに対処するよう、調整されてもよい。そのように高度に調整されたアプリケーションは、会社に固有のエンティティおよびプロセスに関する追加情報をアプリケーションが管理するために追加の演算資源または記憶資源を必要とする。

従来の非ホスト型の環境では、ＣＲＭアプリケーションは顧客会社に固有の場所にインストールされ、これらの追加費用は顧客会社の負担となり得る。

顧客に固有のＣＲＭアプリケーションは、１つ以上のバーティカルの構成要素を採用してもよい。たとえば、大規模自動車ディーラ用に明確に調整されたＣＲＭアプリケーションは、自動車のアカウントおよびサービスを処理するための自動車バーティカルの構成要素と、ローンを管理するための金融バーティカルの構成要素とを含んでいてもよい。多数
のバーティカルからの構成要素を採用しているそのような高度に調整されたＣＲＭアプリケーションについては、バーティカル全体にわたって共有データの一貫性を維持する際に問題が生じる。たとえば、自動車バーティカルおよび金融バーティカルの構成要素を採用しているテイラードＣＲＭアプリケーションについては、車両およびローンが各々、製品と考えられるかもしれず、いずれかのエンティティへの変更が両方に影響を与えるかもしれない。

この場合も、非ホスト型のＣＲＭアプリケーションについては、共有データの一貫性を維持する関連費用はその特定の顧客会社が負担する。調整は、機能性がその特定の顧客会社にとって十分に価値がある場合にのみ行なわれる。

上述のように、ＣＲＭアプリケーションをホストすることは顧客会社に多数の利点を提供する。ホスト型ＣＲＭアプリケーションが高度に調整されたバーティカルアプリケーションである場合、そのような利点はさらにより多くなる。潜在的な顧客会社にとって、高度に調整されたバーティカルアプリケーションを提供するホスティング会社は、ベースＣＲＭ機能性のみを提供するホスティング会社よりも非常に興味深いものであると思われる。

しかしながら、上述の高度に調整されたバーティカルの特徴により、そのようなアプリケーションをホストすることはホスティング会社にとって問題のあるものとなる。ホスティング会社は、多数の顧客会社と資源を効率的に共有することによって提供されるスケールメリットを頼りにしている。高度に調整されたＣＲＭバーティカルアプリケーションは、顧客固有のもの、またはせいぜい少数の顧客会社に適用可能なものであり得る。高度に調整された多数の個々のバーティカルをホストすることは、ホスティングを経済的に魅力ある試みとするのに必要なスケールメリットとは両立しない。つまり、現在、高度に調整されたバーティカルを多数の顧客会社に提供することは、多数のソフトウェアシステムおよびサーバを必要とする。

さらに、正確な費用評価（課金）を提供するために顧客会社をそれらのそれぞれの資源の使用に基づいて区別することができないことは、高度に調整されたバーティカルをホストする上で追加の問題ある領域である。つまり、高度に調整されたバーティカルのホスティングを実際に実現することにより、資源の使用に比例した区別された費用評価が可能となるべきであるが、それは現在のホスティング手法では利用できない。

概要
この発明の実施例は、高度に調整されたホスト型バーティカルアプリケーションを提供するための方法および装置を提供する。一実施例によれば、顧客関係管理アプリケーションのための１組の汎用構成オプションが作成され、ユーザに提示される。ユーザは、提供された１組のオプションから１つ以上のオプションを選択し、選択されたオプションは、調整された顧客関係管理アプリケーションを自動的に構成するために使用される。

この発明の実施例の他の特徴および利点は、添付図面から、および以下の詳細な説明から明らかとなるであろう。

この発明は、以下の説明、およびこの発明の実施例を例示するために使用される添付図面を参照することにより、最良に理解され得る。

詳細な説明
概要
この発明の実施例は高度に調整されたバーティカルを提供し、その一方、そのようなアプリケーションをホストする困難に対処している。この発明の実施例は、１組の汎用構成オプション（Universal Configuration Options：ＵＣＯ）を提供する。ＵＣＯは、動作および実行時間調整能力の使用を介して高度に調整されたバーティカルを作成するために使用可能である。この発明の一実施例については、ＵＣＯのための管理能力は、資源の使用に基づいた費用の区別評価を可能にする態様で分布される。

この発明の一実施例については、多数の既存のバーティカルからの矛盾するビジネスエンティティおよびプロセスは分解されて、１組のＵＣＯを提供する。各バーティカルＣＲＭの深い機能性は保たれ、対応する構成設定の背後に隔離される。

この発明の一実施例は、会社固有の構成を提供することによって多数の顧客会社の各々が高度に調整されたバーティカルを特定できるようにする１組のＵＣＯとベースＣＲＭアプリケーションとを提供する。この発明の一実施例については、顧客会社から構成情報を受取り次第、高度に調整されたバーティカルが自動的に構成される。

したがって、ソフトウェアシステムの多数のインスタンスが発行され、各々が個々に修正されて特定のバーティカルをもたらす先行技術の方式とは異なり、この発明の実施例は、各顧客会社が高度に調整されたバーティカルを特定できるようにする１組のＵＣＯを有する単一のホスト型ソフトウェアシステムを可能にする。

加えて、またはこれに代えて、この発明の実施例は、資源の使用に基づいた区別費用評価方式を行なうために、個々の会社およびユーザに安全かつ追跡可能な態様で権限を付与するためのシステムを提供してもよい。

以下の説明では、多数の特定の詳細が述べられる。しかしながら、この発明の実施例はこれらの特定の詳細なしで実践され得ることが理解される。他の点では、この説明の理解を不明瞭にしないために、周知の回路、構造および手法は詳細には示されていない。

明細書全体を通し、「一実施例」への言及は、その実施例に関連して説明されたある特定の特徴、構造、または特性がこの発明の少なくとも１つの実施例に含まれていることを意味する。このため、明細書全体のさまざまな場所に「一実施例において」という言いまわしが出現することは、必ずしもすべてが同じ実施例に言及しているとは限らない。さらに、１つ以上の実施例において、特定の特徴、構造、または特性は何らかの好適な態様で組合わされてもよい。

さらに、発明の局面は、単一の開示された実施例の全特徴には満たない特徴に存在する。このため、特許請求の範囲はこれにより、この詳細な説明に明白に援用され、各請求項はこの発明の別個の実施例として独立している。

システム
図１は、この発明の一実施例に従った、高度に調整されたバーティカルを特定するための１組のＵＣＯを有するホスト型ＣＲＭアプリケーションを実現するためのシステムを示す。図１に示すシステム１００は、ホスティング会社１０５を含む。ホスティング会社１０５は、ＣＲＭアプリケーション１１０を提供する。ＣＲＭアプリケーション１１０は、特に図示されていない１つまたは多数のサーバ上で実行されてもよい。サーバは、ローカルエリアネットワーク（ＬＡＮ）、イントラネットなどの通信リンクを介して接続された
多数の個々のデジタル処理システム（ＤＰＳ）であってもよい。さらに、ＣＲＭアプリケーションは、単一のソフトウェアプログラムとして、または互いに協働する多数のソフトウェアプログラムとして実現されてもよい。

ＣＲＭアプリケーション１１０は、ベースＣＲＭ構成１１１と１組のＵＣＯ１１２とを含む。代替的な一実施例については、ＣＲＭアプリケーションはベース構成を含まず、１組のＵＣＯ１１２のみを含む。

ホスティング会社１０５は、たとえば顧客会社１２０として図示された１つ以上の顧客会社に通信可能に結合されている。この発明の一実施例では、ＣＲＭアプリケーション１１０は多数の顧客会社に並行して仕える。ホスティング会社１０５は、インターネット、ワイドエリアネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、イントラネットといった、異なる装置同士を通信させ得るネットワーク通信または任意の媒体であり得る通信リンクを介して、顧客会社に接続されてもよい。顧客会社１２０は、たとえば１２１ａ〜１２１ｃとして図示された多数のＤＰＳを含み、それらを介して、顧客会社１２０のユーザはＣＲＭアプリケーション１１０にアクセスして、高度に調整されたバーティカルを構成し使用してもよい。顧客会社のユーザは、ベースＣＲＭ構成を修正するために、１組のＵＣＯ１１２から１つ以上のＵＣＯを選択する。選択されたＵＣＯは、その特定の顧客会社、顧客会社内でのユーザの役割、または個々のユーザに関連する特定のビジネスニーズに基づいていてもよい。ＣＲＭアプリケーションは、顧客会社、各顧客会社内での役割、および各顧客会社での個々のユーザに関する識別情報１１４を記憶する。

この発明の一実施例については、バーティカルを調整するために使用されるＵＣＯは、３クラスのユーザ、すなわち、顧客サービス担当者（Customer Service Representative：ＣＳＲ）、顧客会社管理者（Customer Company Administrator：ＣＣＡ）、および顧客会社従業員（Customer Company Employee：ＣＣＥ）の内の１人によって特定されてもよい。

ＣＳＲはホスティング会社に雇用されており、いくつかの顧客会社にまたがって仕事をしてもよい。ＣＳＲは、顧客会社によって要求された（たとえば購入された）サービスに基づいて顧客会社およびその従業員に設定された（provisioned）アクセスを提供するために、ＣＲＭアプリケーションに対して調整要求を出す。

ＣＣＡは顧客会社に雇用されており、同様に、顧客会社の従業員を管理するためにＣＲＭアプリケーションに対して調整要求を出してもよい。

ＣＣＥも調整要求を出してもよいが、そのような要求は通常、制限されている。ＣＣＥは主として、ビジネスエンティティ状態を表示または移行するために、ＣＲＭアプリケーションに対して動作要求を出す。対照的に、ＣＳＲおよびＣＣＡは通常、動作要求は出さない。

この発明の一実施例によれば、調整能力は実行時間時に（すなわち、ＣＲＭアプリケーションの通常動作中に）ユーザに提供される。この発明の一実施例については、ある特定のユーザに関連する識別情報および選択されたＵＣＯを実行時間構成データベースに記憶させるために、データストア１１５が使用される。設定されたアクセス制御を参照して以下に説明されるような、各ユーザについての付与された権限の直列化された関連付けも、データストア１１５に記憶されてもよい。

汎用ビジネスエンティティおよびプロセス
この発明の一実施例によれば、多数の既存のビジネスエンティティおよびプロセスは、
１組の汎用ビジネスエンティティおよびプロセスへと分解される。分解により、既存のビジネスエンティティおよびプロセスは、ＵＣＯセットへと統合されるようになる。分解により、たとえばベースＣＲＭアプリケーションとある特定のバーティカルといった２つ以上の矛盾するＣＲＭアプリケーションが、ホスティングにより適している高度に調整されたバーティカルへと本質的に組合わされるようになる。

通常、ＣＲＭアプリケーションはいくつかのエンティティといくつかのプロセスとを含む。エンティティは通常、いくつかの関連データを含むデータベースである。プロセスは１つ以上のエンティティ上で動作し、エンティティの状態を修正するかまたは動作を通して追加エンティティを作成する。

たとえば、ベースＣＲＭアプリケーションは、リード（lead）、アカウント、およびアカウント用のコンタクトといったエンティティを含んでいてもよく、アカウント用のコンタクトを識別する新しいアカウントのためのセットアッププロセスを含んでいてもよい。対照的に、バーティカル、たとえば医療教育バーティカルは、病院および医師といったエンティティを含んでいてもよい。病院というエンティティはアカウントを専門としてもよく、このため、病院をセットアップすることは、追加情報を有するアカウントをセットアップする。つまり、エンティティが異なる場合があり、実質的に同じエンティティが異なる属性を有する場合がある。たとえば、医療教育バーティカルについては、各コンタクトは属性認定を含む場合があるが、一方、ベースＣＲＭアプリケーションでは、そのような属性は通常必要とされず、含まれないであろう。

したがって、医療教育バーティカルにおいてコンタクトを定義するプロセスは、ベースＣＲＭアプリケーションまたは異なるバーティカルの対応するプロセスとは異なる、もしくは追加の情報を必要とするであろう。

一般に、１つのＣＲＭアプリケーションのエンティティを、ベースＣＲＭアプリケーションまたは異なるバーティカルの実質的に対応するエンティティと同じ態様で処理することはできない。

たとえば、ベースＣＲＭアプリケーションは通常、アカウント中心の機能性を有する。アカウントは、出荷先住所および課金先住所、ならびに主要コンタクトを含み得る。企業努力はアカウントの主要コンタクトに向けて傾注される。アカウントが終了すれば、関連するコンタクトはアカウントとともに除去されるであろう。アカウントと主要コンタクトとは非常に関連したエンティティであり、密に結合していると考えられる。しかしながら、医療教育バーティカル機能性はコンタクト中心である。病院というアカウントの主要コンタクトは病院経営者であり得るが、その人物は、企業努力を傾注する対象の人物、または唯一の人物ではないかもしれない。企業努力は病院の医療要員に傾注されるであろう。

これら２つのアプリケーションは矛盾しており、矛盾するデータを作成したりまたはデータを失ったりする危険を冒すことなくともに使用することはできない。たとえば、ベースＣＲＭアプリケーションのアカウントと同じ態様で病院というエンティティが処理される場合、アカウントが終了すれば貴重なコンタクト情報が破棄されるおそれがある。

矛盾するＣＲＭアプリケーションのエンティティおよびプロセスにおけるこれらの衝突（conflict）に対処するため、この発明の一実施例は、さまざまなエンティティおよびプロセスを分解することによって、汎用ビジネスエンティティおよびプロセスを作成する。次に、２つ以上のエンティティ間の関係を特定するために、構成が使用される。たとえば、医療教育バーティカルのエンティティである病院は、一般的にアカウントに関係する部分と、ある病院に特に関係する残りの部分とに分解される。病院はアカウントの１タイプ
として見られ、そのタイプはエンティティから分けられ、それは個々に処理され得るようになる。同様に、医師というエンティティは、一般的なコンタクト情報とある医師に関係する追加情報とに分解される。次に、エンティティ間の関係（たとえば、密に結合されているか緩く結合されているか）を判断し、また、ある特定の顧客会社がこれらのエンティティを使用しているかどうかを特定するために、構成が使用される。

エンティティ衝突
この発明の実施例は、２タイプのエンティティ衝突、すなわち重複エンティティ衝突と排他的エンティティ衝突とを解決する。

重複エンティティ衝突は、１つのＣＲＭアプリケーションのあるエンティティが、１つ以上の他のＣＲＭアプリケーションのあるエンティティの上位集合または部分上位集合である場合に起こる。図２は、この発明の一実施例に従った、重複エンティティ衝突が解決されるプロセスを示している。プロセス２００は動作２０５から始まり、そこでは、１つのＣＲＭアプリケーションのあるエンティティが、１つ以上の他のＣＲＭアプリケーションの対応するエンティティに重複しているとして識別される。たとえば、上述のように、医療教育バーティカルの病院エンティティは、ベースＣＲＭアプリケーションのアカウントエンティティの上位集合である場合がある。なぜなら、病院エンティティは、アカウントエンティティの情報のすべて、および追加情報を含むためである。たとえば、病院エンティティは、医師および看護師といったエンティティを参照してもよく、たとえばある医師は外科医であると特定し、またはある看護師は緊急受入スタッフの一員であると特定するというように、これらの要員についての病院内での特定の役割を特定してもよい。対照的に、典型的な顧客会社についてのアカウントエンティティは単に、対応する役職を有する従業員を有していてもよい。

動作２１０で、エンティティは上位集合エンティティおよび下位集合エンティティとして識別される。一般に、エンティティは厳密な下位集合／上位集合の関係を有する必要はないが、そのような関係を部分的にのみ有する必要がある。

図３は、この発明の一実施例に従った、異なるＣＲＭアプリケーションの対応するエンティティ間の部分的な下位集合／上位集合の関係を示す。図３に示すように、円形の領域３０５は第１のＣＲＭアプリケーションのエンティティを表わし、円形の領域３１０は第２のＣＲＭアプリケーションの対応するエンティティを表わす。斜線領域３１５は、２つのエンティティの共通情報を表わす。三日月の領域３０６は非共通情報、すなわち、共通情報を超えた第１のエンティティの拡張情報を表わし、三日月の領域３１１は、共通情報を超えた第２のエンティティの拡張情報を表わす。この説明のために、より大きな拡張情報を有するエンティティを上位集合エンティティとして説明し、より少ない拡張情報を有するエンティティを下位情報エンティティとして説明する。

図２を再度参照すると、動作２１５で、下位集合エンティティのために、下位集合エンティティの直列化（serialization）が開発され、使用される。下位集合エンティティは分析され、そのエンティティのためにベース属性（エンティティおよびプロセス）が決定される。ベース属性は、上位集合エンティティと共通であり、さらにそのような全エンティティに（たとえば、異なるＣＲＭアプリケーションの対応するエンティティに）概して汎用である、エンティティの部分を表わす。この汎用部分は、ベース属性からなる中心記録（たとえばデータベース記録）を作成するために抽出される。

動作２２０で、上位集合エンティティの非共通属性の直列化が開発される。この直列化は下位集合エンティティの直列化への参照を含み、参照直列化と呼ばれる。この発明の一実施例については、参照直列化は、下位集合エンティティの直列化を含むデータベース記
録の拡張記録として実現される。上位集合エンティティはデータベース内の２つの表として実現されてもよい。第１の表は、下位集合エンティティに固有のデータのすべてを含む。たとえば、下位集合エンティティがアカウントである場合、第１の表は出荷先住所、課金先住所、主要アカウント、およびそのようなエンティティに一般に関係する他のエンティティおよびプロセスを含んでもいてもよい。

第２の表は、上位集合エンティティに固有の追加データのすべてを含む。たとえば、上位集合エンティティが病院である場合、第２の表は、アカウント用のデータベース記録において効果的に実現できないであろう病院固有のエンティティおよびプロセス、たとえば病院設備（たとえば、緊急治療室、２４時間看護など）を含む。第２の表も、第１の表を参照して第１の表への直接関係を作成する参照（ＩＤ）を含み、そのため、上位集合エンティティ（たとえば病院）がアクセスされると、下位集合エンティティ（たとえばアカウント）情報も同様に参照される。

動作２２５で、下位集合エンティティを、上位集合エンティティを管理する下位プロセスとして管理するために、ビジネスプロセスが手直しされる。下位集合エンティティは、上位集合エンティティによって共有されていない関連プロセスを有する場合がある。たとえば、病院をセットアップする際、アカウントデータのコアが使用されるが、アカウントに適用可能なプロセスは同じではないかもしれない。上述のように、ベースＣＲＭアプリケーションは、アカウントおよびコンタクトを非常に関連したエンティティと考えて、この密な結合を維持するコードを含む場合がある。したがって、アカウントについて行なわれた課金先住所変更プロセスが、アカウントに関連する全コンタクトの住所を変更することを含む場合がある。そのようなプロセスはアカウント中心ではないが、ある特定の顧客会社にとっては有益かもしれない。そのような顧客会社は、アカウント課金先住所の変更をアカウントに関連する各コンタクトに伝える追加課金ロジックを含むＣＲＭアプリケーションを希望するかもしれない。したがって、プロセス（たとえば課金先住所変更プロセス）は、必要に応じて起動可能なオプションの部分が存在するよう、手直しされる必要がある。一般に、プロセスは、上位集合エンティティに適用可能なプロセスが対応するプロセスと同じではないあらゆる場合に手直しされる。

この発明の一実施例によって解決されるエンティティ衝突の追加のタイプは、排他的エンティティ衝突である。排他的エンティティ衝突は、２つのエンティティが同じ直列化を異なるように解釈する場合に起こる。つまり、２つのＣＲＭアプリケーションの各々が、同じ特定情報を有するものの、その情報を異なるように扱う場合がある。一方のＣＲＭアプリケーションにとって、その情報は、他方には適用できない業界固有の意味を有するかもしれない。たとえば、アカウントエンティティが「分類」という属性を有する場合がある。ベースＣＲＭアプリケーションにとっては、アカウントの「分類」という属性は、特定の顧客会社に固有であり得る一般的な意味を有するかもしれない。しかしながら、特定のやり方でアカウントを実現するバーティカルにとっては、「分類」という属性は、厳密に解釈される業界固有の意味を有するかもしれない。たとえば、「病院」というエンティティに適用されるように、「分類」という属性は、病院で利用可能なサービスを示すかもしれない。

図４は、この発明の一実施例に従った、排他的エンティティ衝突を解決するためのプロセスを示す。図４に示すプロセス４００は動作４０５から始まり、そこでは、排他的エンティティ衝突が識別される。排他的エンティティ衝突は、根底にある（underlying）同じデータベース行列を用いた２つのエンティティがデータから異なる意味を導き出した場合に識別される。

動作４１０で、各エンティティの衝突していない共通の属性が、衝突している属性から
分離される。この発明の一実施例については、第３のエンティティが、衝突していない属性を含むように作成される。そのような一実施例では、結果は３つの直列化、すなわち、共通の衝突していない属性を含む１つのコア直列化、および衝突している属性を含む各ＣＲＭアプリケーションのための別個の直列化である。そのためたとえば、３つの直列化は、アカウントの共通属性を含むコアアカウント直列化、（医療バーティカルについての）病院分類のための直列化、および（ベースＣＲＭアプリケーションについての）アカウント分類のための直列化である場合がある。

動作４１５で、２つの別個の属性直列化間の衝突が別個に解決される。２つの別個の直列化間の衝突は結局、重複エンティティ衝突ということになるため、それは、この発明の一実施例についての図２のプロセス２００を参照して上述されたように解決され得る。

プロセス衝突
エンティティ衝突が解決され次第、プロセス間の衝突が解決される。プロセス衝突の判断はさまざまなやり方で達成可能であり、通常、プロセスに関与するエンティティの状態の分析に依存する。プロセス衝突は、２つの切り離されたプロセスがエンティティの互いに素な（disjoint）属性集合上で動作する付加的プロセス衝突であるかもしれない。プロセス衝突はまた、２つの切り離されたプロセスがエンティティの部分的に互いに素な属性集合上で動作する絶対的プロセス衝突であるかもしれない。

図５は、この発明の一実施例に従った、プロセス衝突を解決するためのプロセスを示す。図５に示すプロセス５００は動作５０５から始まり、そこでは、プロセス衝突を分析して、それが付加的プロセス衝突であるか、または絶対的プロセス衝突であるかを判断する。

プロセス衝突が付加的プロセス衝突であると判断され次第、動作５１０で、２つのプロセスは繋がれる。これにより、切り離されたプロセスの各々はオプションで構成中に実現されるようになる。プロセス同士が切り離されているため、プロセス同士を繋ぐ順序は重要ではない。たとえば、アカウント課金先住所の変更を含む、あるアカウントについての課金先住所変更プロセスと、関連するあらゆるコンタクトの課金先住所を対応して変更するプロセスとを考慮されたい。そのようなプロセスは、ある顧客会社にとっては非常に望ましいものの、他の顧客会社にとってはそうではない場合がある。切り離されたプロセス同士を繋ぐことにより、あるアカウントについての課金先住所を変更するオプションには、そのアカウントについての関連するコンタクトに課金先住所の変更を伝えるようにするさらに別のオプションが提供される。このため、単一の統合され専門化したプロセスオプションが提供された先行技術の手法を上回る、より優れた構成柔軟性が提供される。

プロセス衝突が絶対的プロセス衝突であると判断され次第、プロセス衝突解決策は、以下に説明するような動作５１５〜５３５で継続する。

絶対的プロセス衝突の解決は動作５１５から始まり、そこでは、衝突している各プロセスの、衝突に関係している属性および下位プロセスが識別される。たとえば、アカウント中心の機能性を有するＣＲＭアプリケーションのためのリード変換を実現するロジックは、コンタクト中心の機能性を有するＣＲＭアプリケーションのためのリード変換を実現するロジックとは異なる。

動作５２０で、所与のビジネスプロセスについての解決の各合理的順序のために、１組のオプションが定義される。たとえば、アカウント中心対コンタクト中心のプロセス衝突を解決する際、提示される衝突は、リード変換を行なうために必要とされるのはアカウント情報か、またはコンタクト情報かということである。定義された１組のオプションは、
必要とされるアカウント情報、必要とされるコンタクト情報、または要件なし（たとえばドントケア）であるかもしれない。

動作５２５で、衝突によって影響を受けるユーザにとって適切なレベルでオプションセットが提供される。オプションセットは汎用であってもよく、またはより狭い範囲内にあってもよい。つまり、ビジネス事例に依存して、会社レベルでオプションを提供することが適切な場合があり、または会社内のある役割にオプションを提供することが適切な場合がある。たとえば、経理課の職員はリードをアカウントに変換するかもしれないが、同じ顧客会社の研修課の職員はリードをコンタクトに変換するかもしれない。

動作５３０で、重複する属性を解決するために、オプションセットが使用される。選択されたオプションは、作成されるデータ（すなわち必要とされるデータ）についての値を決定する。たとえば、課金先住所を入力することがアカウント作成プロセスの一部である場合には、アカウントが保存されると課金先住所が必要とされるであろう。

動作５３５で、残りの互いに素な属性があれば識別され、上述のような動作５１０を繰返すことによって付加的プロセス衝突として解決される。

汎用構成オプションの作成
識別されたエンティティ衝突およびプロセス衝突の解決は、１組のＵＣＯに含まれ得るオプションセットを作成する。１組のＵＣＯは、高度に調整された深いバーティカルを自動的に作成するために会社毎またはユーザ毎に選択可能な１組のオプションである。オプション設定は、システムがそれらを理解してデータ完全性を維持できるよう、汎用であるが、それらは個々のユーザに異なるように提示される。

図６は、この発明の一実施例に従った、バーティカルを調整するために組合わされ得る１組のＵＣＯを作成するプロセスを示す。図６に示すプロセス６００は動作６０５から始まり、そこでは、各構成オプション値に一意的なシステム識別子が割当てられる。これはシステムソフトウェアにオプションを区別する能力を提供する。

動作６１０で、すべての初期セット（initial set）から、各オプションに割当てられた一意的なシステム識別子を用いて、マスタセット（master set）が作成される。

動作６１５で、区別できないビジネスエンティティおよびプロセスを識別する多数の別個の値が、マスタセットにおける共通のシステム識別子に割当てられるよう、マスタセットのシステム識別子が正規化される。たとえば、医療バーティカルは医薬品工場というエンティティを含むかもしれないが、ビジネスプロセスを行なうために、医薬品工場というエンティティが、工場というエンティティと区別できなくなっているかもしれない。そのような場合、２つのエンティティ値に同じシステム識別子が割当てられる。

動作６２０で、エンティティ状態が、値ではなくそれらの割当てられたシステム識別子によって表わされる。これは、ビジネス処理におけるエンティティ状態への参照を含む。この発明の一実施例については、システムは確実に汎用システム識別子を作成し、それらの存在を１つ以上のＣＲＭアプリケーション（たとえばベースＣＲＭアプリケーション）に強制する。

設定されたアクセス制御
バーティカルを調整するためにオプションを個々に選択する能力は、資源の使用に基づいた区別費用評価のための基準も提供する。この発明の実施例は、付与された権限に基づいた費用評価を可能にするために、設定されたアクセス制御を使用する。権限とは、バー
ティカル内の識別可能な権利である。権限は、リードまたはコンタクトを更新する、もしくは削除するといった基本動作、または、資産の所有権を変更するといったより高度の動作を含み得る。あるバーティカルに関係している１組の権限は、そのバーティカルの特徴に基づいており、選択された構成オプションに依存している。

図７は、この発明の一実施例に従った、設定されたアクセス制御を実現するためのシステムを示す。図７に示すプロセス７００は動作７０５から始まり、そこでは、権限が、対応する付与権限に関連付けられている。この発明の一実施例については、区別費用評価に適しているバーティカルの特徴は、安全に付与可能でかつ追跡可能な権限に関連付けられている。

この発明の一実施例については、権限は、権限を付与する能力を制御する対応する付与権限を各権限について実現することによって、安全に付与可能となる。この特性は再帰的に適用されてもよい（すなわち、付与権限をその付与権限のために実現する）。加えて、権限を付与する能力は、ユーザのクラスに基づいて制限され得る。たとえば、権限を付与し破棄するＣＣＥの能力はその顧客会社内に制限されるかもしれず、一方、ＣＳＲには、複数の顧客会社にまたがって権限を付与し破棄する能力が与えられる。この発明の一実施例については、権限は、権限を照会可能な内部報告システムを実現することによって追跡可能となる。内部報告システムも、実行時間構成データストアの従業員、役割、および会社の構造を理解している。

動作７１０で、ＣＳＲには発行時に安全に付与可能な権限すべてを付与し破棄する能力が与えられる。この能力は複数の顧客会社にまたがって当てはまる。場合によっては、ＣＳＲには権限自体が付与されず、権限を付与する能力のみが付与される。

動作７１５で、課金可能なサービスが顧客会社によって購入され次第、ＣＳＲは、購入された課金可能なサービスに関連する付与可能なあらゆる権限を、顧客会社の１人以上のＣＣＡに付与する。ＣＲＳはまた、関連する権限を付与する能力をＣＣＡに付与してもよい。

動作７２０で、ＣＣＥに設定可能な、課金可能なサービスに関連する権限が、適切なＣＣＥに付与される。そのような権限のＣＣＥへの付与は、ＣＣＡからまたはＣＳＲから直接行なわれてもよい。

付与された権限は特定のユーザに関連付けられ、この関連付けは直列化されて記憶される。データベースに基づいた実行時間構成データストアを実現するこの発明の一実施例については、ユーザおよび権限の直列化された関連付けがデータベースの表に含まれる。

上述の設定されたアクセス制御方法を使用すると、提供されるサービスに基づいた区別費用評価手法を行なうために、権限の追跡可能な履歴（付与および破棄の双方）が使用可能である。顧客会社は、権限を付与されたＣＣＡおよびＣＣＥの数を含む、付与された権限の数およびタイプに基づいて、費用を評価されてもよい。加えて、またはこれに代えて、顧客会社は、各権限の使用に基づいて費用を評価されてもよい。

この発明の一実施例によれば、設定されたアクセス制御の実現は、ＵＣＯの選択を介して行なわれるバーティカル調整を補完する。バーティカルの特徴は、上述のように付与され得る権限に関連付けられる。ホスティング会社の観点からは、オプションおよび関連付けられた権限のすべてが（たとえば同じハードウェアを使用する）１つのシステム上で利用可能となり、設定されたアクセス制御を介して区別して課金されることが可能である。顧客会社は、ＣＳＲまたはＣＣＥによって決められたように、顧客会社のニーズに調整さ
れたオプションを選択する。選択された（たとえば顧客会社によって購入された）オプションの各特徴について、ＣＳＲは、関連付けられた権限をＣＣＡに付与し、また、権限を付与する能力を付与する。ＣＣＡは次に、ＣＣＥの個々のニーズおよび責任に基づいて、バーティカルの特徴に関連付けられた権限をＣＣＥに付与することにより、個々のＣＣＥのためにバーティカルをさらに調整する。

一般的な事項
この発明の実施例は、高度に調整されたバーティカルを提供するための方法および装置を提供する。この発明のさまざまな実施例によれば、あらゆる数のバーティカルからのエンティティおよびプロセスが１組のＵＣＯに追加されてもよく、このため、各バーティカルＣＲＭからの機能性を要望通りに組合わせる、深く調整されたバーティカルを提供する。調整されたバーティカルは限定されておらず、必要なだけ深く機能できる。ビジネスロジックコアから調整が分離されたため、追加のおよび既存のエンティティおよびプロセス間の衝突が減少する。

この発明の一実施例によれば、区別して課金可能でありかつ費用効率の高い実行可能なビジネスモデルの文脈において、高度に調整されたバーティカルがホスティング会社によって提供されている。追加のフレームワークは、顧客会社の数にではなく、ユーザの数および使用量に基づいている。さらに、高度に調整されたホスト型バーティカルは、動作が実行時間時、統合されたランタイム（実行時間）フレームワークを用いて動的にホストされるため、追加マシンが必要なく、少ない設置面積を保つ。

設定されたアクセス制御により、各顧客は、提供されたサービスの範囲および使用量に基づいて費用を評価されるようになる。この発明の代替的な実施例については、設定されたアクセス制御は、バーティカルを調整するためのＵＣＯを除いて実現される。

特定のオプションおよび業界の点から見て説明されてきたが、この発明の実施例が、関連するエンティティおよびプロセスに関する幅広い範囲のバーティカルおよびオプションへの利用可能性を有することは明らかである。

たとえば、この発明の実施例は、航空宇宙、自動車、通信、金融、保険、製造、小売、エネルギ、健康管理、運輸、ホテルといった業界に、高度に調整されたバーティカルを作成する能力を提供する。

さらに、この発明の実施例は、さまざまなソフトウェアを用いて実現されてもよい。たとえば、下位集合エンティティおよび上位集合エンティティの直列化は、図２を参照して、データベース記録として上述されている。オブジェクト指向プログラミング（Object Oriented Programming：ＯＯＰ）言語が採用されるこの発明の代替的な実施例については、参照直列化は、ＯＯＰ言語オブジェクトと、下位集合エンティティの直列化を実現する別のＯＯＰ言語オブジェクトを参照するポインタとして実現されてもよい。

図１を参照して上述したように、顧客会社は１つ以上のＤＰＳを有していてもよい。図８は、この発明の一実施例に従った、顧客会社内に含まれ得るＤＰＳ８０１の一実施例を示すブロック図である。この発明の代替的な実施例については、ＤＰＳ８０１は、バス８０７に結合されたプロセッサ８０３を含むコンピュータであってもよい。一実施例では、メモリ８０５、ストレージ８１１、ディスプレイコントローラ８０９、通信インターフェイス８１３、入力／出力コントローラ８１５、およびオーディオコントローラ８２７も、バス８０７に結合される。

ＤＰＳ８０１は、通信インターフェイス８１３を介して外部システムにインターフェイ
ス接続している。通信インターフェイス８１３は、無線電話信号と互換性がある無線トランシーバ、またはある装置を他の装置に結合するための他のインターフェイスを含んでいてもよい。この発明の一実施例では、通信インターフェイス８１３とネットワーク８５０との間で搬送波信号８２５が送受信される。この発明の一実施例では、ＤＰＳ８０１を別のコンピュータシステム、ネットワークハブ、ルータなどとインターフェイス接続するために、通信信号８２５が使用されてもよい。この発明の一実施例では、搬送波信号８２５は、ワイヤ、ケーブル、光ファイバを通って、または大気などを通って伝達され得るマシン読取可能な媒体であると考えられる。

この発明の一実施例では、プロセッサ８０３は、インテルｘ８６またはペンティアム（登録商標）ファミリーマイクロプロセッサ、モトローラファミリーマイクロプロセッサなどといった従来のマイクロプロセッサであってもよい。メモリ８０５は、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）といったマシン読取可能な媒体であってもよく、スタティックランダムアクセスメモリ（ＳＲＡＭ）を含んでいてもよい。ディスプレイコントローラ８０９は、従来の態様でディスプレイ８１９を制御し、ディスプレイ８１９は、この発明の一実施例では、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、アクティブマトリックスディスプレイ、テレビモニタなどであってもよい。入力／出力コントローラ８１５に結合された入力／出力装置８１７は、キーボード、ディスクドライブ、プリンタ、スキャナ、および他の入力出力装置（たとえばマウス）であってもよい。この発明の一実施例では、オーディオコントローラ８２７は、従来の態様でオーディオ出力８３１とオーディオ入力８２９とを制御する。

ストレージ８１１は、磁気ハードディスク、フロッピー（登録商標）ディスク、光ディスク、スマートカード、またはデータ用ストレージの別の形態などを含むがこれらに限定されないマシン読取可能な媒体を含んでいてもよい。この発明の一実施例では、ストレージ８１１は、取外し可能媒体、読取専用媒体、読取可能／書込可能媒体などを含んでもよい。コンピュータシステム８０１におけるソフトウェアの実行中、データの一部は直接メモリアクセスプロセスによってメモリ８０５に書込まれてもよい。ソフトウェアはストレージ８１１、メモリ８０５内にあってもよく、またはモデムもしくは通信インターフェイス８１３を介して送受信されてもよいということが理解される。明細書のために、「マシン読取可能な媒体」という用語は、データ、情報を記憶可能な任意の媒体、または、この発明の方法論をプロセッサ８０３に実行させるよう、プロセッサ８０３によって実行される一連の命令を符号化することが可能な任意の媒体を含むと解釈されるべきである。「マシン読取可能な媒体」という用語は、固体メモリ、光ディスクおよび磁気ディスク、搬送波信号などを含むがそれらに限定されないと解釈されるべきである。

この発明をいくつかの実施例の点で説明してきたが、当業者であれば、この発明が説明された実施例に限定されず、特許請求の範囲および精神内で修正および変更して実践され得るということを認識するであろう。このため、この説明は、限定的であるというよりも例示的であると考えられるべきである。

この発明の一実施例に従った、高度に調整されたバーティカルを特定するための１組の汎用構成オプションを有するホスト型ＣＲＭアプリケーションを実現するためのシステムを示す図である。 この発明の一実施例に従った、重複エンティティ衝突が解決されるプロセスを示す図である。 この発明の一実施例に従った、異なるＣＲＭアプリケーションの対応するエンティティ間の部分的な下位集合／上位集合の関係を示す図である。 この発明の一実施例に従った、排他的エンティティプロセスを解決するためのプロセスを示す図である。 この発明の一実施例に従った、プロセス衝突を解決するためのプロセスを示す図である。 この発明の一実施例に従った、バーティカルを調整するために組合わされ得る１組の汎用構成オプションを作成するプロセスを示す図である。 この発明の一実施例に従った、設定されたアクセス制御を実現するためのプロセスを示す図である。 この発明の一実施例に従った、顧客会社内に含まれ得るデジタル処理システムの一実施例を示すブロック図である。

Claims (33)

1. 顧客関係管理（ＣＲＭ）アプリケーションのための１組の汎用構成オプション（ＵＣＯ）を作成するステップと、
   １組のＵＣＯをユーザに提供するステップと、
   １つ以上のＵＣＯの選択をユーザから受けるステップと、
   選択されたＵＣＯに基づいて、テイラードＣＲＭアプリケーションを自動的に構成するステップとを備える、方法。
2. テイラードＣＲＭアプリケーションはホスト型である、請求項１に記載の方法。
3. ユーザは、顧客サービス担当者、顧客会社管理者、および顧客会社従業員からなる群から選択される人物である、請求項２に記載の方法。
4. テイラードＣＲＭアプリケーションはベースＣＲＭアプリケーションへの修正であり、修正は選択されたＵＣＯを反映している、請求項２に記載の方法。
5. １組のＵＣＯを作成するステップは、１組の既存のビジネスエンティティおよびプロセスを分解するステップを含む、請求項２に記載の方法。
6. １組の既存のビジネスエンティティおよびプロセスを分解するステップは、２つ以上のエンティティ間のエンティティ衝突を解決するステップを含み、各エンティティはそれぞれの既存のＣＲＭアプリケーションに関連付けられている、請求項５に記載の方法。
7. エンティティ衝突を解決するステップは、重複するエンティティ衝突を以下の方法によって解決するステップを含み、前記以下の方法は、
   第１の組の属性を有する第１のエンティティと第２の組の属性を有する第２のエンティティとを識別するステップを備え、第２の組の属性の一部は第１の組の属性と共通しており、第２の組の属性の一部は第１の組の属性と共通しておらず、前記以下の方法はさらに、
   第１のエンティティの直列化を開発するステップと、
   第１の組の属性と共通していない第２の組の属性の一部の直列化を開発するステップと、
   第１のエンティティが第２のエンティティを管理する下位プロセスとして管理され得るように、第１のエンティティに影響を与えるプロセスを修正するステップとを備える、請求項６に記載の方法。
8. エンティティ衝突を解決するステップは、絶対的エンティティ衝突を以下の方法によって解決するステップを含み、前記以下の方法は、
   第１の組の属性を有する第１のエンティティと第２の組の属性を有する第２のエンティティとを識別するステップを備え、第１の組の属性の少なくとも１つの属性は、第２の組の属性の対応する属性と衝突しており、前記以下の方法はさらに、
   第２の組の属性の対応する属性と衝突している第１の組の属性の少なくとも１つの属性の直列化を開発するステップと、
   第１の組の属性の対応する属性と衝突している第２の組の属性の少なくとも１つの属性の直列化を開発するステップとを備える、請求項６に記載の方法。
9. １組の既存のビジネスエンティティおよびプロセスを分解するステップは、２つ以上のプロセス間のプロセス衝突を解決するステップを含み、各プロセスはそれぞれの既存のＣＲＭアプリケーションに関連付けられている、請求項５に記載の方法。
10. プロセス衝突を解決するステップは、
    ２つのプロセス間の衝突を分析するステップと、
    衝突が付加的であると判断するステップと、
    ２つのプロセスを繋ぐステップとを含む、請求項９に記載の方法。
11. プロセス衝突を解決するステップは、
    ２つのプロセス間の衝突を分析するステップと、
    衝突が絶対的であると判断するステップと、
    衝突に関係している２つのプロセスの各々からの属性および下位プロセスを識別するステップと、
    衝突を解決するための１組のオプションを定義するステップと、
    １組のオプションをユーザに提供するステップとを含む、請求項９に記載の方法。
12. デジタル処理システムによって実行される際、前記システムに以下の方法を行なわせる実行可能命令を含むマシン読取可能な媒体であって、前記以下の方法は、
    顧客関係管理（ＣＲＭ）アプリケーションのための１組の汎用構成オプション（ＵＣＯ）を作成するステップと、
    １組のＵＣＯをユーザに提供するステップと、
    １つ以上のＵＣＯの選択をユーザから受けるステップと、
    選択されたＵＣＯに基づいて、テイラードＣＲＭアプリケーションを自動的に構成するステップとを備える、マシン読取可能な媒体。
13. テイラードＣＲＭアプリケーションはホスト型である、請求項１２に記載のマシン読取可能な媒体。
14. ユーザは、顧客サービス担当者、顧客会社管理者、および顧客会社従業員からなる群から選択される人物である、請求項１３に記載のマシン読取可能な媒体。
15. テイラードＣＲＭアプリケーションはベースＣＲＭアプリケーションへの修正であり、修正は選択されたＵＣＯを反映している、請求項１３に記載のマシン読取可能な媒体。
16. １組のＵＣＯを作成するための命令は、１組の既存のビジネスエンティティおよびプロセスを分解するための命令を含む、請求項１３に記載のマシン読取可能な媒体。
17. １組の既存のビジネスエンティティおよびプロセスを分解するための命令は、２つ以上のエンティティ間のエンティティ衝突を解決するための命令を含み、各エンティティはそれぞれの既存のＣＲＭアプリケーションに関連付けられている、請求項１６に記載のマシン読取可能な媒体。
18. エンティティ衝突を解決するための命令は、重複するエンティティ衝突を以下の方法によって解決するための命令を含み、前記以下の方法は、
    第１の組の属性を有する第１のエンティティと第２の組の属性を有する第２のエンティティとを識別するステップを備え、第２の組の属性の一部は第１の組の属性と共通しており、第２の組の属性の一部は第１の組の属性と共通しておらず、前記以下の方法はさらに、
    第１のエンティティの直列化を開発するステップと、
    第１の組の属性と共通していない第２の組の属性の一部の直列化を開発するステップと、
    第１のエンティティが第２のエンティティを管理する下位プロセスとして管理され得る
    ように、第１のエンティティに影響を与えるプロセスを修正するステップとを備える、請求項１７に記載のマシン読取可能な媒体。
19. エンティティ衝突を解決するための命令は、絶対的エンティティ衝突を以下の方法によって解決するための命令を含み、前記以下の方法は、
    第１の組の属性を有する第１のエンティティと第２の組の属性を有する第２のエンティティとを識別するステップを備え、第１の組の属性の少なくとも１つの属性は、第２の組の属性の対応する属性と衝突しており、前記以下の方法はさらに、
    第２の組の属性の対応する属性と衝突している第１の組の属性の少なくとも１つの属性の直列化を開発するステップと、
    第１の組の属性の対応する属性と衝突している第２の組の属性の少なくとも１つの属性の直列化を開発するステップとを備える、請求項１７に記載のマシン読取可能な媒体。
20. １組の既存のビジネスエンティティおよびプロセスを分解するための命令は、２つ以上のプロセス間のプロセス衝突を解決するための命令を含み、各プロセスはそれぞれの既存のＣＲＭアプリケーションに関連付けられている、請求項１６に記載のマシン読取可能な媒体。
21. プロセス衝突を解決するための命令は、
    ２つのプロセス間の衝突を分析するステップと、
    衝突が付加的であると判断するステップと、
    ２つのプロセスを繋ぐステップとを備える方法を行なうための命令を含む、請求項２０に記載のマシン読取可能な媒体。
22. プロセス衝突を解決するための命令は、
    ２つのプロセス間の衝突を分析するステップと、
    衝突が絶対的であると判断するステップと、
    衝突に関係している２つのプロセスの各々からの属性および下位プロセスを識別するステップと、
    衝突を解決するための１組のオプションを定義するステップと、
    １組のオプションをユーザに提供するステップとを備える方法を行なうための命令を含む、請求項２０に記載のマシン読取可能な媒体。
23. 顧客関係管理（ＣＲＭ）アプリケーションのための１組の汎用構成オプション（ＵＣＯ）を記憶するためのデータストアと、
    １組のＵＣＯを遠隔ユーザに提供し、１つ以上のＵＣＯの選択を遠隔ユーザから受けるための通信リンクと、
    選択されたＵＣＯに基づいて、テイラードＣＲＭアプリケーションを自動的に構成するための処理システムとを備える、顧客関係管理（ＣＲＭ）アプリケーションホスティングシステム。
24. 通信リンクは、インターネット、ワイドエリアネットワーク、ローカルエリアネットワーク、イントラネット、およびそれらの組合せからなる群から選択される、請求項２３に記載のＣＲＭアプリケーションホスティングシステム。
25. ユーザは、顧客サービス担当者、顧客会社管理者、および顧客会社従業員からなる群から選択される人物である、請求項２４に記載のＣＲＭアプリケーションホスティングシステム。
26. テイラードＣＲＭアプリケーションはベースＣＲＭアプリケーションへの修正であり、
    修正は選択されたＵＣＯを反映している、請求項２４に記載のＣＲＭアプリケーションホスティングシステム。
27. １組のＵＣＯは、１組の既存のビジネスエンティティおよびプロセスを分解することによって作成される、請求項２４に記載のＣＲＭアプリケーションホスティングシステム。
28. １組の既存のビジネスエンティティおよびプロセスを分解することは、２つ以上のエンティティ間のエンティティ衝突を解決することを含み、各エンティティはそれぞれの既存のＣＲＭアプリケーションに関連付けられている、請求項２７に記載のＣＲＭアプリケーションホスティングシステム。
29. エンティティ衝突を解決することは、重複するエンティティ衝突を以下の方法によって解決することを含み、前記以下の方法は、
    第１の組の属性を有する第１のエンティティと第２の組の属性を有する第２のエンティティとを識別するステップを備え、第２の組の属性の一部は第１の組の属性と共通しており、第２の組の属性の一部は第１の組の属性と共通しておらず、前記以下の方法はさらに、
    第１のエンティティの直列化を開発するステップと、
    第１の組の属性と共通していない第２の組の属性の一部の直列化を開発するステップと、
    第１のエンティティが第２のエンティティを管理する下位プロセスとして管理され得るように、第１のエンティティに影響を与えるプロセスを修正するステップとを備える、請求項２８に記載のＣＲＭアプリケーションホスティングシステム。
30. エンティティ衝突を解決することは、絶対的エンティティ衝突を以下の方法によって解決することを含み、前記以下の方法は、
    第１の組の属性を有する第１のエンティティと第２の組の属性を有する第２のエンティティとを識別するステップを備え、第１の組の属性の少なくとも１つの属性は、第２の組の属性の対応する属性と衝突しており、前記以下の方法はさらに、
    第２の組の属性の対応する属性と衝突している第１の組の属性の少なくとも１つの属性の直列化を開発するステップと、
    第１の組の属性の対応する属性と衝突している第２の組の属性の少なくとも１つの属性の直列化を開発するステップとを備える、請求項２８に記載のＣＲＭアプリケーションホスティングシステム。
31. １組の既存のビジネスエンティティおよびプロセスを分解することは、２つ以上のプロセス間のプロセス衝突を解決することを含み、各プロセスはそれぞれの既存のＣＲＭアプリケーションに関連付けられている、請求項１７に記載のＣＲＭアプリケーションホスティングシステム。
32. プロセス衝突を解決することは、
    ２つのプロセス間の衝突を分析するステップと、
    衝突が付加的であると判断するステップと、
    ２つのプロセスを繋ぐステップとを備える方法を行なうことを含む、請求項３１に記載のＣＲＭアプリケーションホスティングシステム。
33. プロセス衝突を解決することは、
    ２つのプロセス間の衝突を分析するステップと、
    衝突が絶対的であると判断するステップと、
    衝突に関係している２つのプロセスの各々からの属性および下位プロセスを識別するス
    テップと、
    衝突を解決するための１組のオプションを定義するステップと、
    １組のオプションをユーザに提供するステップとを備える方法を行なうことを含む、請求項３１に記載のＣＲＭアプリケーションホスティングシステム。

Images