(57)【特許請求の範囲】
【請求項１】
コンピュータシステムのプロセッサが、既存の複数の顧客関係管理（ＣＲＭ）アプリケーションから、ニーズに応じて調整されたＣＲＭアプリケーションを作成するための方法であって、前記既存のＣＲＭアプリケーションは、複数の汎用構成オプション（ＵＣＯ）の組を有しており、
前記調整された顧客関係管理（ＣＲＭ）アプリケーションのための１組の汎用構成オプション（ＵＣＯ）を作成するステップを備え、
前記作成するステップは、
前記既存の複数のＣＲＭアプリケーションにアクセスするステップを含み、各前記既存のＣＲＭアプリケーションは、複数のエンティティと、複数のプロセスとを含み、各前記エンティティは、複数の関連データを有しており、各前記プロセスは、１つ以上のエンティティ上で動作し、
前記複数のＣＲＭアプリケーションのエンティティとプロセスとを汎用のビジネスエンティティおよびプロセスに分解するステップを含み、２つ以上のエンティティの関係は、構成により特定され、
前記分解するステップは、重複エンティティ衝突を解決するために、各エンティティを上位集合エンティティまたは下位集合エンティティとして識別して、下位集合エンティティを分析して当該下位集合エンティティのベース属性を決定するステップを含み、前記上位集合エンティティは、下位集合エンティティに固有のデータと、上位集合エンティティに固有のデータとを含み、前記ベース属性は、上位集合エンティティと共通であり、汎用な部分を表し、
分解によって得られた前記汎用のビジネスエンティティにおいて識別される前記上位集合エンティティおよび前記下位集合エンティティとプロセスとを用いて汎用構成オプション（ＵＣＯ）を作成するステップを含み、
前記方法は、さらに、
前記コンピュータシステムにアクセス可能なユーザコンピュータに１組のＵＣＯを提供するステップと、
１つ以上のＵＣＯの選択を前記ユーザコンピュータから受けるステップと、
選択されたＵＣＯに基づいて、前記調整されたＣＲＭアプリケーションを構成するステップとを備える、方法。
【請求項２】
前記重複エンティティ衝突の解決後にプロセス間の衝突を解決するステップをさらに備え、
前記プロセス間の衝突を解決するステップは、当該衝突が、各プロセスがエンティティの互いに素な属性集合で動作する付加的プロセス衝突であるか、各プロセスが、エンティティの一部が互いに素な属性集合で動作する絶対的プロセス衝突であるかを判断するステップを含む、請求項１に記載の方法。
【請求項３】
プロセス間の衝突が付加的プロセス衝突である場合に、当該二つのプロセスを繋ぐステップをさらに備える、請求項２に記載の方法。
【請求項４】
前記選択されたＵＣＯに権限を付与するステップをさらに備える、請求項１〜３のいずれかに記載の方法。
【請求項５】
請求項１〜４のいずれかに記載の方法をコンピュータに実現させるためのプログラム。
【請求項６】
請求項５に記載のプログラムを実行するためのコンピュータシステム。
【請求項７】
既存の複数の顧客関係管理（ＣＲＭ）アプリケーションから、ニーズに応じて調整されたＣＲＭアプリケーションを作成するための装置であって、前記既存のＣＲＭアプリケーションは、複数の汎用構成オプション（ＵＣＯ）の組を有しており、
前記調整された顧客関係管理（ＣＲＭ）アプリケーションのための１組の汎用構成オプション（ＵＣＯ）を作成するための作成手段を備え、
前記作成手段は、
前記既存の複数のＣＲＭアプリケーションにアクセスするための手段を含み、各前記既存のＣＲＭアプリケーションは、複数のエンティティと、複数のプロセスとを含み、各前記エンティティは、複数の関連データを有しており、各前記プロセスは、１つ以上のエンティティ上で動作し、
前記複数のＣＲＭアプリケーションのうちの矛盾するエンティティとプロセスとを汎用のビジネスエンティティおよびプロセスに分解するための手段を含み、２つ以上のビジネスエンティティの関係は、構成により特定され、前記分解するための手段は、重複エンティティ衝突を解決するために、各エンティティを上位集合エンティティまたは下位集合エンティティとして識別して、下位集合エンティティを分析して当該下位集合エンティティのベース属性を決定するように構成されており、前記上位集合エンティティは、下位集合エンティティに固有のデータと、上位集合エンティティに固有のデータとを含み、前記ベース属性は、上位集合エンティティと共通であり、汎用な部分を表し、
分解によって得られた前記汎用のビジネスエンティティにおいて識別される前記上位集合エンティティおよび前記下位集合エンティティとプロセスとを用いて汎用構成オプション（ＵＣＯ）を作成するための手段を含み、
前記装置は、さらに、
当該装置に接続可能なユーザコンピュータに１組のＵＣＯを提供するための手段と、
１つ以上のＵＣＯの選択を前記ユーザコンピュータから受けるための手段と、
選択されたＵＣＯに基づいて、前記調整されたＣＲＭアプリケーションを構成するための手段とを備える、装置。
【発明の詳細な説明】
【技術分野】
【０００１】
分野
この発明の実施例は一般に、テイラード（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：ＯＯＰ）言語が採用されるこの発明の代替的な実施例については
、参照直列化は、ＯＯＰ言語オブジェクトと、下位集合エンティティの直列化を実現する別のＯＯＰ言語オブジェクトを参照するポインタとして実現されてもよい。
【００８１】
図１を参照して上述したように、顧客会社は１つ以上のＤＰＳを有していてもよい。図８は、この発明の一実施例に従った、顧客会社内に含まれ得るＤＰＳ８０１の一実施例を示すブロック図である。この発明の代替的な実施例については、ＤＰＳ８０１は、バス８０７に結合されたプロセッサ８０３を含むコンピュータであってもよい。一実施例では、メモリ８０５、ストレージ８１１、ディスプレイコントローラ８０９、通信インターフェイス８１３、入力／出力コントローラ８１５、およびオーディオコントローラ８２７も、バス８０７に結合される。
【００８２】
ＤＰＳ８０１は、通信インターフェイス８１３を介して外部システムにインターフェイス接続している。通信インターフェイス８１３は、無線電話信号と互換性がある無線トランシーバ、またはある装置を他の装置に結合するための他のインターフェイスを含んでいてもよい。この発明の一実施例では、通信インターフェイス８１３とネットワーク８５０との間で搬送波信号８２５が送受信される。この発明の一実施例では、ＤＰＳ８０１を別のコンピュータシステム、ネットワークハブ、ルータなどとインターフェイス接続するために、通信信号８２５が使用されてもよい。この発明の一実施例では、搬送波信号８２５は、ワイヤ、ケーブル、光ファイバを通って、または大気などを通って伝達され得るマシン読取可能な媒体であると考えられる。
【００８３】
この発明の一実施例では、プロセッサ８０３は、インテルｘ８６またはペンティアム（登録商標）ファミリーマイクロプロセッサ、モトローラファミリーマイクロプロセッサなどといった従来のマイクロプロセッサであってもよい。メモリ８０５は、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）といったマシン読取可能な媒体であってもよく、スタティックランダムアクセスメモリ（ＳＲＡＭ）を含んでいてもよい。ディスプレイコントローラ８０９は、従来の態様でディスプレイ８１９を制御し、ディスプレイ８１９は、この発明の一実施例では、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、アクティブマトリックスディスプレイ、テレビモニタなどであってもよい。入力／出力コントローラ８１５に結合された入力／出力装置８１７は、キーボード、ディスクドライブ、プリンタ、スキャナ、および他の入力出力装置（たとえばマウス）であってもよい。この発明の一実施例では、オーディオコントローラ８２７は、従来の態様でオーディオ出力８３１とオーディオ入力８２９とを制御する。
【００８４】
ストレージ８１１は、磁気ハードディスク、フロッピー（登録商標）ディスク、光ディスク、スマートカード、またはデータ用ストレージの別の形態などを含むがこれらに限定されないマシン読取可能な媒体を含んでいてもよい。この発明の一実施例では、ストレージ８１１は、取外し可能媒体、読取専用媒体、読取可能／書込可能媒体などを含んでもよい。コンピュータシステム８０１におけるソフトウェアの実行中、データの一部は直接メモリアクセスプロセスによってメモリ８０５に書込まれてもよい。ソフトウェアはストレージ８１１、メモリ８０５内にあってもよく、またはモデムもしくは通信インターフェイス８１３を介して送受信されてもよいということが理解される。明細書のために、「マシン読取可能な媒体」という用語は、データ、情報を記憶可能な任意の媒体、または、この発明の方法論をプロセッサ８０３に実行させるよう、プロセッサ８０３によって実行される一連の命令を符号化することが可能な任意の媒体を含むと解釈されるべきである。「マシン読取可能な媒体」という用語は、固体メモリ、光ディスクおよび磁気ディスク、搬送波信号などを含むがそれらに限定されないと解釈されるべきである。
【００８５】
この発明をいくつかの実施例の点で説明してきたが、当業者であれば、この発明が説明された実施例に限定されず、特許請求の範囲および精神内で修正および変更して実践され得るということを認識するであろう。このため、この説明は、限定的であるというよりも例示的であると考えられるべきである。
【図１】
0005705257.tif 000002
【図２】
0005705257.tif 000003
【図３】
0005705257.tif 000004
【図４】
0005705257.tif 000005
【図５】
0005705257.tif 000006
【図６】
0005705257.tif 000007
【図７】
0005705257.tif 000008
【図８】
0005705257.tif 000009