JP3731860B2 - 顧客サービス処理システム内のタスクの順序付け - Google Patents
顧客サービス処理システム内のタスクの順序付け Download PDFInfo
- Publication number
- JP3731860B2 JP3731860B2 JP2000050686A JP2000050686A JP3731860B2 JP 3731860 B2 JP3731860 B2 JP 3731860B2 JP 2000050686 A JP2000050686 A JP 2000050686A JP 2000050686 A JP2000050686 A JP 2000050686A JP 3731860 B2 JP3731860 B2 JP 3731860B2
- Authority
- JP
- Japan
- Prior art keywords
- task
- milestone
- feature
- product
- tasks
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、品物、サービス、または情報管理を提供するために使用されるコンピューティング・システムに関する。特に、本発明は、業務関連プロダクトを提供するシステム関連タスクの順序付けに関する。
【０００２】
【従来の技術】
最新の大規模コンピューティング・システムでは、一般的なトポロジは、（ｉ）ユーザ対話に焦点を絞った複数のワークステーションを特徴とするプレゼンテーション層と、（ii）アプリケーション／ビジネス・ロジックを実行する複数のサーバを特徴とする業務層と、（iii）データの記憶と編成を処理する複数のデータベースを特徴とするデータ層との３つの層を有する。この３つの要素は、ローカルまたはワイド・エリア・ネットワーク（ＬＡＮ／ＷＡＮ）によって相互接続される。
【０００３】
このようなコンピューティング・システムは、大学の研究／教育施設から業務応用分野まで及ぶ多種多様な分野に適用されている。実際に、あらゆる企業が、このようなシステムを使用してその業務を処理し、顧客にサービスを提供している。たとえば、このようなシステムは在庫管理、文書処理、会計の用途や、顧客の問い合わせへの対応に使用することができる。多くの企業は、きわめて大規模な顧客基盤を有し、膨大な在庫の商品やサービスを提供する。その一例は、全国規模の顧客基盤にサービスを提供する通信サービス提供者（Telco）である。したがって、Telcoの加入者は、数百万人に達することがあり、各顧客は、請求書発行情報から発注状況の問い合わせ、製品の発注にわたるどのような問い合わせに対しても顧客サービス担当者（ＣＳＲ）からのほとんど即時の応答を期待する。
【０００４】
同様の例は、公益事業、保険会社、銀行、病院、法律事務所、会計事務所、証券取引所、大学、政府機関にも見られ、これらはほんの一例に過ぎない。
【０００５】
このようなすべてのコンピューティング・システムでは、ソフトウェア資源とハードウェア資源の間に本質的な拮抗がある。顧客需要や提供する商品およびサービスの複雑さが増すにつれて、コンピューティング・ハードウェアの規模を拡大しようとするだけでは、経済的に非効率的であり、技術的に限界がある。
【０００６】
そうする代わりに、ソフトウェア・コーディング、データベース管理、およびシステム・ファームウェア・アーキテクチャを改良することによって可能な、システム・パフォーマンスの大幅な向上がある。スケーラビリティを実現する必要がある場合、これらの設計要素をすべて考慮する必要がある。「スケーラビリティ」とは、増大するデータ、取引、およびユーザ基盤に対処する３層コンピューティング・アプリケーションの（ワークステーションとサーバとデータベースとの間で受け渡しされる情報の数とタイプで表した）能力を意味する。
【０００７】
アプリケーション・プログラム・ソフトウェアのメンテナンスの問題の一手法が、特開平１０−３２６１９０（アイ・ビー・エム・コーポレイション）で開示されており、これはオブジェクト指向プログラムと、様々なプログラムを分類制度に従って統制する制御フレームワーク・データベースとを使用する。
【０００８】
【発明が解決しようとする課題】
「提供」とは、業務要求を実行するために実際に行う必要がある作業である。提供アクションは、典型的には、特定の順序で完了しなければならない相互に関係のある複数のタスクを必要とする。この要件のための一手法は、特開平０５−３４２２２７（東京電気株式会社）に記載されている。この参照特許では、個々のアクションは始点と終点によって規定された期間だけ有効な構成が開示されている。よく評価しても、これは制限のある手法である。
【０００９】
本発明は、従来の技術の問題を克服するか少なくとも改善しようとするものである。
【００１０】
【課題を解決するための手段】
本発明は、各プロダクトがロッキング・マイルストーンを規定する属性を持つフィーチャを有する、関連のあるメタ・レベル・ドメインプロダクトを提供する顧客サービス・コンピューティング・システムのシステム・レベル・ドメイン内に存在する一連の順次タスクを実行する方法であって、
（ａ）前記タスクのうちの１つまたは複数のタスクをマイルストーンとして指定するステップと、
（ｂ）前記順次タスクを実行するステップとを含み、前記各マイルストーン・タスクについて、
（ｉ）関連のある前記プロダクト・フィーチャについて照会を行い、前記タスク・マイルストーンが前記ロッキング・マイルストーンに対応するか否かを判断するステップと、対応する場合には、
（ii）前記実行を続行するステップとを含む方法を提供する。
【００１１】
本発明は、顧客サービス・コンピューティング・システムにおいて品物およびサービスを提供する方法であって、
（ａ）各プロダクトが関連するロッキング・マイルストーンを規定する属性を持つフィーチャを有する、前記品物およびサービスに関係するメタ・レベル・ドメイン内に存在する複数のプロダクト・アクションのうちのいずれか１つに必要な提供を表すシステム・レベル・ドメイン内の１つまたは複数の一連の順次タスクを定義するステップと、
前記各シーケンスについて、
（ｂ）前記タスクのうちの１つまたは複数のタスクをマイルストーンとして指定するステップと、
（ｃ）前記順次タスクを実行するステップとを含み、前記各マイルストーン・タスクについて、
（ｉ）前記プロダクト・フィーチャについて照会を行い、前記タスク・マイルストーンが前記ロッキング・マイルストーンに対応するか否かを判断するステップと、対応する場合には、
（ii）前記実行を続行するステップとを含む方法をさらに提供する。
【００１２】
本発明は、品物およびサービスを提供するコンピューティング・システムであって、
各プロダクトが関連するロッキング・マイルストーンを規定する属性を持つフィーチャを有し、前記品物およびサービスに関係するメタ・レベル・ドメイン内に存在する複数のプロダクト・アクションのうちのいずれか１つに必要な提供を表すシステム・レベル・ドメイン内の１つまたは複数の順次タスクを定義し、各シーケンスについて、前記タスクのうちの１つまたは複数のタスクをマイルストーンとして指定し、前記各マイルストーン・について前記プロダクト・フィーチャに関する照会を行って前記タスク・マイルストーンが前記ロッキング・マイルストーンに対応するか否かを判断するように前記シーケンスのタスクを実行するように動作可能なプロセッサ手段を含むコンピューティング・システムをさらに提供する。
【００１３】
照会が真の場合、前記タスク・シーケンスの実行が完了するまでプロダクト・フィーチャの属性を変更することができないように、プロダクト・フィーチャがロック状態にされるので有利である。フィーチャが有効になるようにフィーチャを顧客と関連づける属性を有するか否かを判断するという前提条件がある場合がある。マイルストーン・タスクは、メタ・レベル・ドメイン内の前記フィーチャの局面として反映される。
【００１４】
【発明の実施の形態】
図１は、本発明を実施する３層コンピューティング・システム１０の代表的なトポロジである。プレゼンテーション（またはクライアント／ユーザ）層は、適切なコンピューティング端末、たとえばパーソナル・コンピュータとすることができるいくつか（１．．．ｎ個）のワークステーション２０によって表されている。業務層は、ミニ・コンピュータまたはメインフレーム・コンピュータとすることができるいくつかの（１．．．ｐ個）のサーバ３０によって表されている。データ層は、いくつかの（１．．．ｍ個）のデータベース４０によって表され、これらのデータベースは動的に管理される磁気記憶媒体または光記憶媒体とすることができる。
【００１５】
コンピューティング・システム１０は、「オープン」設計であり、外部ネットワーク７０、７２、７４を介して同様の装置２２、３２、４２および遠隔電話端末２４、２６への通信リンク６０、６２、６４を備える。
【００１６】
ワークステーション２０、サーバ３０、およびデータベース４０は、ローカル・エリア・ネットワークまたはワイド・エリア・ネットワーク（ＬＡＮまたはＷＡＮ）５０によって相互接続されている。ＬＡＮ／ＷＡＮ５０は、前述の３つの各基本要素の間で受渡しされる情報を伝達する。図１に示すトポロジは代表例に過ぎず、ワークステーション２０、サーバ３０、およびデータベース４０間での情報の受渡しという目的が達成されるような他の好都合な形態のネットワークも実施可能であることがわかるであろう。
【００１７】
本発明の実施形態は、前述の「従来の技術」の項に記載の分野において産業的に利用することができる。非限定的例示のために、米国の多くの州にわたって営業しているTelcoの例を考えてみる。このようなTelcoは、一般に、市内、地域、州間、および国際音声およびデータ電話と、セルラ移動体音声およびデータ通信をサポートする。Telcoの顧客は、たとえば第２の電話／ファクス／インターネット回線の設置、呼出しの転送、メッセージ送信を含む、広範囲な品物およびサービスから選択することができる。顧客は、ワークステーション２０に配属された顧客サービス担当者（ＣＳＲ）に請求金額やサービスの障害に関する問い合わせを行うことができることも期待する。現代のTelcoは少なくとも百万人の顧客を有し、一般に、少なくとも５００人のＣＳＲを必要とすると予想するのは妥当である。この規模のTelcoのシステム基盤は、１時間当たり約１５，０００件の業務取引を処理すると予想することができる。各業務取引について、６件のＣＳＲマシン・トランザクションが必要と考えられ、個々のマシン・トランザクションは最大２０件のデータベース・トランザクション（すなわち入出力）必要とする可能性がある。
【００１８】
このようなパフォーマンスを達成するのに必要な規模のコンピューティング・ハードウェアのよりよい例を示すと、ＣＳＲワークステーション２０は、Windows NT（商標）オペレーティング・システムが稼働しているPentium（商標）パーソナル・コンピュータであり、サーバ３０は１つまたは複数のＩＢＭ ＵＮＩＸ（商標）ベースの１２ウェイＲＳ６０００（商標）Ｓ−７０機とすることができ、データベースは、Oracle（商標）またはＩＢＭ ＤＢ−２（商標）システムによって管理された約４０ギガバイトの容量を必要とすることになる。当業者なら容易にわかるように、当然ながら、データ通信を処理する他の稼働ＬＡＮ／ＷＡＮサーバもあるであろう。
【００１９】
Telcoなどの業務システムでは、顧客はＣＳＲに電話をして、国内電話回線での「キャッチホン」を利用できるようにする要求など、品物またはサービスを日常言語で要求する。実際に、ＣＳＲはこのレベルの業務も行い、そのような品物やサービスに関する情報がワークステーションの表示画面上に（ＧＵＩ）としてＣＳＲに提示される。そしてコンピューティング・システム１０は、顧客の注文した品物またはサービス、あるいは問い合わせに応じて動作する。
【００２０】
本発明の目的の１つは、スケーラビリティを実現することである。この目的の達成を支援するために採用されているシステム・モデルは、「ステートレス」である。これは、要求者の前の関連情報の記録がサーバ３０上で保持されずに、データがサーバ３０およびデータベース４０に渡されることを意味する。言い換えると、あらゆるシステム・トランザクションはそれ自体で完結し、いずれかのユーザまたは当該ユーザのためにサーバ内で実行された以前のシステム・トランザクションを知る必要がない。
【００２１】
他の関連する態様は、ワークステーション２０を特定の１つのサーバ３０とのみ通信するように制約しないという設計上の選択である。ワークステーション２０からの情報要求を、「ｐ」個のサーバ３０のいずれか１つに宛てて送ることができる。さらに、「ｍ」個のデータベース４０にアクセスすることができるのはサーバ３０のみである。
【００２２】
他の設計上の選択は、コンポーネント化を可能にするオブジェクト指向プログラミングの使用である。オブジェクト指向プログラミングは、再使用可能性、低（ソフトウェア）メンテナンス、わかりやすさ、および拡張可能性を特徴とする。したがって、関連づけられた動作をプロセス状態のビルディング・ブロックとしリンクすることを可能にする。
【００２３】
オブジェクト指向プログラミングの原理は、ジェームズ・ランボー（James Runbaugh）、アイヴァー・ジェーコブセン（Ivar Jacobsen）、およびグレイディ・ブーク（Grady Booch）による「The Unified Modeling Language Reference Manual」（Addison-Wesley、１９９８年１２月刊）（ＩＳＢＮ０−２０１−３０９９８−Ｘ）に記載されている。
【００２４】
概要
システム１０によってサポートされる「品物やサービス」を「プロダクト」と呼ぶ。プロダクトは、コンピューティング・システム１０のワークステーション２０とサーバ３０の両方に存在するメタ・データである。プロダクトは、「アクション」と「タグ付きアクション」とによって構成される。各アクション内には、「フィーチャ」と「提供タスク」とがあり、それぞれ「属性」で構成されている。
【００２５】
ここで、「定義時点（Definition Time）」と「注文管理時点（Order Management Time）」という概念について概説すれば役に立つであろう。「定義時点」とは、顧客との関連づけのために使用可能なところまで新しい「プロダクト」の定義（または既存のプロダクトの修正）に関係する。「注文管理時点」は、新しい「プロダクト」が有効になって送り出され、ワークステーションにいるＣＳＲにとって使用可能になる時である。「注文管理時点」で、オブジェクトはインスタンシエートされ、定義済み「プロダクト・テンプレート」に「実」データが入れられ、このプロダクト・テンプレートに従って「プロダクト・アクション」の提供またはデータベース照会が行われるようになっている。
【００２６】
プロダクトは、「定義時点」中に定義され、ＣＳＲが顧客の注文に応答してインスタンスをポピュレートするために使用できるようになる。図２に示すように、プロダクト１００は、マッピング・プロセス１１０を施されて、「プロダクト」を実行する一連のタスク１２０になる。タスクは、サーバ３０内とデータベース４０内に存在し、「プロダクト・アクション」に値を返すことができる。返された値によって「プロダクト・アクション」状況情報および構成「フィーチャ」属性が更新される。
【００２７】
図３に、様々な「プロセス・サブシステム」の相互作用を示す。「定義時点」にサブシステム「プロダクト定義」１３０、「価格設定」１３５、および「提供定義」１４０が作成される。「顧客プロダクト」１４５と「提供実行時」１５０サブシステムは、「注文管理時点」中にのみ発生する。
【００２８】
「プロダクト定義」サブシステム１３０は、多くのメタ・データ「プロダクト」を含み、例示のために「コーリング・カード」プロダクト定義が示されている。「コーリング・カード」は、少なくともプロダクト「ワイヤレス・アクセス」（破線で図示されている）との（必要な）関連づけを有する。また、構成フィーチャ「スケジューリング」、「コーリング・カード（Calling Card）」、「メモ」、「認識番号」、および「課金」を持つ「コーリング・カード追加」プロダクト・アクション定義も有する。
【００２９】
「価格設定」サブシステム１３５は、関連づけられたフィーチャ「グローバル・オプション」、「交換料金」、および「幹部特権」を持つ「料金プラン」定義を有する。
【００３０】
同様に、「提供定義」サブシステム１４０は、必要な場合に「コーリング・カードの追加」を提供するために行う必要がある実際の作業に関係する特定の「タスク」が関連づけられた各「プロダクト・アクション」（この場合は「コーリング・カード」のみが図示されている）のための「提供活動プラン」を有する。これらの「タスク」は、「ネットワークの起動」、「請求の更新」、「認識番号の割振り」、および「遂行のディスパッチ」として記載されている。
【００３１】
「注文管理時点」は、（この場合）（「プロダクト」サブシステム１４５において）ＣＳＲに対して行われたコーリング・カード・サービスを求めるジョー・スミスの要求で開始される。この結果、「ジョー・スミスの）コーリング・カード追加」アクションが行われる。ＣＳＲは、ジョー・スミスに、特定の「コーリング・カード・フィーチャ」要件「コーリング・カード」、「認識番号」、「メモ」、「スケジューリング」、および「課金」に関して尋ねる。「課金」フィーチャによって、記憶されている「コーリング・カード課金プラン」記録の照会も行われ、アクションに関連づけられることになる適切な情報が取り出される。
【００３２】
この要求は次に、提供のために「提供実行時」サブシステム１５０に渡される。「コーリング・カード追加」アクションのために「提供活動プラン」がインスタンシエートされ、その形式が「提供定義」サブシステム１４０から取り出され、前述のように「顧客プロダクト」サブシステム１４５において収集された属性と共にポピュレートされる。次に、一連のタスク、すなわち「ジョーのネットワークの起動」および「ジョーの遂行のディスパッチ」が実行される。これらのタスクが実行された後は、「ジョー・スミスのコーリング・カード」が「顧客プロダクト」サブシステム１４５内で有効になり、「認識番号フィーチャ」および「コーリング・カード・フィーチャ」が関連づけられ、さらに、ジョーの既存の「ワイヤレス・アクセス・プロダクト」と関連づけられる。
【００３３】
プロダクト
プロダクトは、特定の業務または顧客の必要に合うように定義することができる。その意味で、既存の「プロダクト」を何らかの方法で修正したり、新しい「プロダクト」を「プロダクト・ブック」に追加したりすることができる。「プロダクト・ブック」は、居住顧客に販売することができるものなど、プロダクトを論理的にグループ化したものである。Telco環境でのプロダクトには、以下のものを含めることができる。
標準ワイヤライン・アクセス：家庭が電話の物理製品を持つことができるようにする家庭へのワイヤライン接続。
キャッチフォン：顧客が電話に出ているときに、顧客の電話に着信した別の呼出があることを顧客に通知する機能。
呼出転送：電話呼出を別の電話／メール・ボックス／ページャなどにリルートする機能。
標準ワイヤレス・アクセス：携帯電話システムへの接続。
【００３４】
再び図２を参照すると、「プロダクト」１００は、（ａ）アクションと、任意選択により（ｂ）「タグ付きアクション」を伴う。アクションは、特定の顧客アカウント／サービスのための特定の「プロダクト」の「追加」または「削除」、あるいは「プロダクト」の構成の変更とすることができる。
【００３５】
たとえば「サービスの場所（ＬＯＳ）」や「ネットワーク識別子（ＮＩ）」など、関連づけられた「フィーチャ」によって構成することができる。「フィーチャ」は、収集されたデータ・インスタンスを定義する。アクションは、関連づけられた「提供活動」も有し、「提供活動」は、「アクション」を実行するために必要なタスク（電子的タスクと、場合によっては人間の介入も指定する）に関係する。
【００３６】
個々の「アクション」は１つまたは複数の他の「プロダクト・アクション」あるいは「プロダクト・アクション」のグループとの関係を有することができることに留意されたい。これらの関係は、「タグ付き」アクションによって表現することができる。この「タグ付きアクション」は、ＣＳＲの観点からは関係に関する明白な知識がなくても、販売の観点から２つのアクションを関連づけることができるようにする。たとえば、Telcoが「保守契約」を「ワイヤレス・アクセス」販売と常に関連づけたいとする。この場合、２つの「プロダクト・アクション」（すなわち「保守契約の追加」と「ワイヤレス・アクセスの追加」）の間に「タグ付き関係」を作成する。これは、ＣＳＲが、いつ「ワイヤレス・アクセス・プロダクト」を販売し、「保守契約」も販売しなければならないかを明白に覚えている必要がなく、ＣＳＲはプロンプトによって指示されることを意味する。
【００３７】
（その属性と共にポピュレートされる際の）「プロダクト」とタスクとの「マッピング・プロセス」１１０では、「タスク・マッパ・キー」を使用する。「属性」は、「プロダクト」をタスクに関連づけるために使用されるデータの単位である。「タスク・マッパ・キー」形式は、インスタンシエートされた形の「プロダクト・テンプレート」によって保持される。
【００３８】
タスク
タスク・ドメイン１２０は、低レベルの抽象化において機能し、メタ状態を記述する。タスクは、（照会であるかプロダクトの提供としてであるかを問わず）「プロダクト・アクション」を実行するために完了する必要がある作業を表す。タスクは、「タスク・プラン」と呼ばれるグラフ型の構造として編成される。
【００３９】
オブジェクト指向の用語では、「タスク」のインスタンスはオブジェクトである。「タスク」の定義はクラス（すなわちプログラムされたコード）である。タスクがインスタンシエートされるとき、１つのタスク・インタンスを他のタスク・インタンスと差別化するデータがデータベース４０から読み取られる。
【００４０】
「提供活動プラン」内で、特定の「タスク」が「マイルストーン」として機能する。これらのタスクは、作業の流れの適切な進行に関するデータの妥当性を保証するチェックポイントとみなすことができる。これらのチェックポイントで、「プロダクト」ドメインと「タスク」ドメインの間でメッセージが送られ、それらが互いに同調され、システム・プロセスの続行にとって妥当であるか否かが判断される。これらの「マイルストーン」が、たとえば「認識番号割振り（ＳＮＡ）活動」内に収まっている様子を示す一例は、「認識番号の割振り」の後にマイルストーンがあることである。タスクは、認識番号データ要素（プロダクト・フィーチャ」が有効であることを保証しなければならない場合がある。有効でない場合、システムはその「認識番号の割振り」活動マイルストーンを越えて進むことはできない。この場合、「認識番号フィーチャ」が有効でなければ、マイルストーンは失敗し、提供は続行することができない。「プロダクト・フィーチャ」をロックすべき時点に関する規則が、「プロダクト定義」時に定義される。すなわち、所与の「プロダクト・アクション」について、所与の「マイルストーン」において「プロダクト・フィーチャ」がロックされ、ＣＳＲによるそれ以上の更新が行われないようにする。
【００４１】
例
プロダクト定義
新しい「プロダクト」定義の第１の例は、顧客に新しい「標準ワイヤライン・アクセス」（ＳＷＡ）プロダクトを提供するTelcoに関するものである。
【００４２】
このプロダクトを定義する以下のステップは、図４を参照しながら読まれたい。
【００４３】
ステップ２０１（必須）：「プロダクト」を作成し、それに「標準ワイヤライン・アクセス」という名前を付ける。これによって、「標準ワイヤレス・アクセス」という名前の「プロダクト」オブジェクトが作成される。
【００４４】
ステップ２０１（ａ）（任意選択）：「前提プロダクト」によって、追加する当該プロダクトの前提状件である他のプロダクトの指定が可能になる。たとえば、「ワイヤレス・アクセスの呼出転送」は、まず、「標準ワイヤライン・アクセス」を定義してからでなければ定義することができない。
【００４５】
ステップ２０２（必須）：「標準ワイヤライン・アクセス」を作成し、「接続」という名前を付けて、そのタイプを事前定義済みのアクション・タイプである「追加」と定義する。これにより、「アクション」オブジェクトが形成され、それに「標準ワイヤライン・アクセス」オブジェクトが関連づけられる。
【００４６】
ステップ２０３（任意選択）：「保守契約」２０９プロダクトの「追加」アクションに対する「タグ付き」関係を作成する。これは、前もって作成されたプロダクト・アクションのリストから「保守契約」−「追加」プロダクト・アクションを選択することによって行われる。
【００４７】
ステップ２０４（必須）：「プロダクト・フィーチャ」関係を作成し、「接続」プロダクト・アクションに追加する。
【００４８】
ステップ２０４ａ：フィーチャの事前定義済みリストから「サービスの場所」フィーチャを選択する。これにより、「サービスの場所」フィーチャ定義が作成され、これが「接続」プロダクト・アクションに関連づけられる。
【００４９】
ステップ２０４ｂ：フィーチャの事前定義済みリストから「ネットワーク」フィーチャを選択する。これにより、「ネットワーク」フィーチャ定義が作成され、これが「接続」プロダクト・アクションに関連づけられる。
【００５０】
ステップ２０４ｃ：フィーチャの事前定義済みリストから「認識番号」フィーチャを選択する。これにより、「認識番号」フィーチャ定義が作成され、これが「接続」プロダクト・アクションが関連づけられる。
【００５１】
ステップ２０４ｄ：フィーチャの事前定義済みリストから「電話帳」フィーチャを選択する。これにより、「電話帳」フィーチャ定義が作成され、これが「接続」プロダクト・アクションに関連づけられる。
【００５２】
ステップ２０４ｅ：フィーチャの事前定義済みリストから「スケジュール」フィーチャを選択する。これにより、「スケジュール」フィーチャ定義が作成され、これが「接続」プロダクト・アクションに関連づけられる。
【００５３】
ステップ２０４ｆ：フィーチャの事前定義済みリストから「課金」フィーチャを選択する。これにより、「課金」フィーチャ定義が作成され、これが「接続」プロダクト・アクションに関連づけられる。
【００５４】
ステップ２０５（必須）：「提供マイルストーン・タスク／マイルストーン」を作成し、「接続」アクション２に追加する。
【００５５】
ステップ２０５ａ：「提供タスク／マイルストーン」の事前定義済みリストから「始点」マイルストーンを選択する。これにより、「始点」マイルストーン定義が作成され、これが「接続」プロダクト・アクションに関連づけられる。
【００５６】
ステップ２０５ｂ：「提供タスク／マイルストーン」の事前定義リストから「実行依頼済み」マイルストーンを選択する。これにより、「実行依頼済み」マイルストーン定義が作成され、これが「接続」プロダクトに関連づけられる。
【００５７】
ステップ２０５ｃ：提供タスク／マイルストーンの事前定義リストから「提供開始済み」マイルストーンを選択する。これにより、「提供開始済み」マイルストーン定義が作成され、これが「接続」プロダクトに関連づけられる。
【００５８】
ステップ２０５ｄ：提供タスク／マイルストーンの事前定義リストから「交換接続」タスクを選択する。これにより、「交換接続」タスク定義が作成され、これが「接続」プロダクトに関連づけられる。
【００５９】
ステップ２０５ｅ：提供タスク／マイルストーンの事前定義済みリストから「サービス起動」マイルストーンを選択する。これにより、「サービス起動」タスク定義が作成され、これが「接続」プロダクトに関連づけられる。
【００６０】
ステップ２０５ｆ：提供タスク／マイルストーンの事前定義角済みリストから「提供完了」マイルストーンを選択する。これにより、「提供完了」マイルストーン定義が作成され、これが「接続」プロダクトに関連づけられる。
【００６１】
ステップ２０５ｇ：その他の提供タスクを選択する。
【００６２】
ステップ２０６（図示せず）：「標準ワイヤライン・アクセス」を「住宅用」プロダクト・ブックに関連づける。このプロダクトがＣＳＲによる販売のためのプロダクト・ブックに追加される。
【００６３】
ステップ２０７（図示せず）：プロダクトをテストする。プロダクト構造の整合性を検証する一連のテストが実行される。
【００６４】
ステップ２０８（図示せず）：プロダクトを送り出す。これで、「標準ワイヤライン・アクセス」が、ＣＳＲが閲覧し、販売するために使用できるようになる。
【００６５】
注１：このリストは、「標準ワイヤライン・アクセス」プロダクトにすでに関連づけられているプロダクト・フィーチャのリストと、プロダクト・アクションに直接関連づけられるように特別に設定されたプロダクト・フィーチャのリストとから作成される。各プロダクト・フィーチャの属性の１つは、フィーチャをロックする必要がある所望の提供マイルストーンの参照である（ステップ２０５の活動の１つを参照）。
【００６６】
注２：これは、提供するタスクの可能な総数のうちの部分的なリストであり、典型的なマイルストーンを示すものである。
【００６７】
図５に、ＳＷＡ−Ｃプロダクト・アクションの図４のプロダクト・テンプレートのインスタンシエートされた形（すなわち「注文管理時点」における形）を示す。インスタンシエートされたＬＯＳ、Ｎ、ＳＮ、Ｓ、およびＣフィーチャの属性は以下の通りである。
【表１】
【表２】
【表３】
【００６８】
ジョー・スミスの「標準ワイヤライン・アクセス」を接続する「提供活動プラン」は、提供のために要求が実行依頼されるときに作成される。
【００６９】
タスク・マッピング
インスタンシエートされた「プロダクト・アクション」を「タスク・プラン」にマッピングするプロセス１１０は、「タスク・マッパ・キー」および関連づけられた「タスク・テンプレート」を必要とする。基本的には、行われるステップは以下の通りである。
１．インスタンシエートされた「プロダクト・テンプレート」の属性のうちから「タスク・マッパ・キー」を作成する（たとえば図５）。
２．各構成「提供活動」について、（事前記憶され、定義されたライブラリの中から）適切な「タスク・テンプレート」を探し出す。
３．構成「タスク・テンプレート」から「タスク・プラン」を作成し、特定の作業タスクのシーケンスとして実行するために使用可能になる。
【００７０】
マッピング・プロセスの一例について、図６のオブジェクト相互作用図を参照しながら以下に説明する。
【００７１】
タスク・マッパ・キー
「タスク・マッパ・キー」は、提供の作業を行わなければならない特定のタスクを識別するためにその値が使用される「プロダクト・アクション」に関連づけられた属性の特定のサブセットである。
【００７２】
サーバ・プロセスによって、ＳＷＡ−Ｃアクションのための「タスク・マッパ・キー」の作成が指示される（MapToTasks()）。マイルストーンとして指定されたものを除き、各「提供活動」２０５が順に検討される。
【００７３】
説明を簡単にするため、「交換接続」提供活動２０５ｄについてのみ考えてみる。この活動のために、getTaskMapperKeyDefinition()コマンドが、「交換接続」２０５ｄの定義フォームから以下のストリングを取り出す。
Region&SwitchID&ExchangeID
【００７４】
コマンドgetActivityDefinitionIDが、「交換接続」２０５ｄの定義フォームから以下のストリングを取り出す。
value
【００７５】
次に、「ジョー・スミスのサービス場所」２０４（ａ）および「ジョー・スミスのネットワーク」２０４（ｂ）の実行時版から入手した各パラメータ（すなわち地域、スイッチＩＤ、および交換ＩＤ）について、コマンドgetAttributeValue()が実行される。
【００７６】
この例では、「活動定義ＩＤ」は「１２３」である。「タスク・マッパ・キー定義」は「Region&SwitchID&Other」であり、この中の「＆」は区切り演算子である。「ジョー・スミスの交換接続」活動に代入される値は、「活動定義ＩＤ」である。「活動定義ＩＤ」で保持される必須キーの数は、この例では「２」である。
【００７７】
「タスク・マッパ・キー」が作成され、「Yorktown&Switch2&AAA」となる。
【００７８】
タスク・テンプレートの探索
「タスク・テンプレート」の事前定義済みリストがデータベース４０で維持され、各タスク・テンプレートは「タスク・プラン」全体の一部を構成する作業タスクのシーケンスを表す。
【００７９】
コマンドSearchForRow（ActivityDefinitionID, TaskMapperKey）が実行され、それによって「タスク・マッパ・キー」が「タスク・テンプレート」のセットと対照される。
【００８０】
データベースで「活動定義ＩＤ」と「タスク・マッパ・キー」を探索する。したがって、１２３、「Yorktown&Switch2&AAA」を探索する。取り出された以下のデータベース項目について考えてみる。
【表４】
【００８１】
完全な一致がある場合、「タスク・テンプレート発見」状態になっている。しかし、上記の項目では、空結果になる。このような場合、探索を制限し、adjust Task Mapper Key()コマンドを呼び出すことになる。必須キーの数は「２」であるため、「タスク・マッパ・キー」は「Yorktown&Switch2」となり、この場合、上掲のデータベース項目の３行目に一致があり、タスク・テンプレートが得られる。
【００８２】
任意選択キーがすべて破棄された後でもなお、縮小された「タスク・マッパ・キー」と「タスク・テンプレート」との間に一致がない場合、SearchForDefaultRow（ActivityDefinitionID）コマンドを呼出し、それによって、活動ＩＤ＝１２３のデフォルトのタスク・テンプレートがデータベース４０から取り出される。
【００８３】
これで「タスク・テンプレート」が見つかった。
【００８４】
タスク・プラン形成
各「タスク・テンプレート」によって、作業タスクのシーケンスが指定される。「ジョー・スミスの交換接続：活動の場合、「タスク・テンプレート」は「Yorktown&Switch2」であり、これはconnectexchangeタスクに対応する。
【００８５】
最新の電話交換局の場合、単一のタスクを発効するだけで十分な場合がある。他のより旧式の交換局では、技術者派遣（dispatchtechnician）、切断（disconnect）、スイッチ２接続（connectswitch2）、および主交換局に対するコールバックなどの１組のタスクが必要な場合がある。
【００８６】
図６に記載のプロセスを、図５の残りの「提供活動」について繰り返し、完成した「タスク・プラン」が基本タスクのシーケンスとして形成される。
【００８７】
補足情報では、タスクによって定義された作業を誰が行うかを指定する。タスク・テンプレートに基づいて、他のデータベース・テーブルでこの情報をさらに探索する。この「作業」は、ローカル交換局で自動的に行うことができることもあり、または技術者が物理的配線を設置し、受話器を備え付ける必要がある場合もある。そのような情報が見つからない場合、デフォルトの情報が使用される。
【００８８】
フィーチャ属性ロッキング
これで「タスク・プラン」が実現されたので、それが実行／提供される。これには、データベース・アクセスと個別の作業アクションが必要である。提供には、タスク・マイルストーンに関係する「属性ロッキング」という概念が含まれる。
【００８９】
属性ロッキングの適用例を例示するために、再び、ジョー・スミスが月曜日にＣＳＲに対してプロダクト・アクション「ジョー・スミスの標準ワイヤライン・アクセスの接続」を要求する例について考えてみる。ジョーは、自分の必要な接続日が次の木曜日であると指定した。これは、図４に示す「スケジューリング・フィーチャ」２０４ｅの構成属性である。この「アクション」が提供のために実行依頼され、「タスク・プラン」が実現した。具体的な作業タスクの１つは、交換局の技術者が適切な回線を接続することである。ジョーが木曜日の朝にＣＳＲに電話をして接続日の延期を要求した場合、そのような遅い段階で変更を行うことができないようにその「フィーチャ」属性を「ロック」しておくことが望ましい。
【００９０】
プロダクト・アクション「標準ワイヤライン・アクセス−接続」について、図７を参照しながら読むように、以下の表にこの順次タスクの一例を示す。
【表５】
【００９１】
図７の「タスク・プラン」は、マイルストーン・タスクに達するまで順次に実行される。マイルストーン・タスクに達した時点で、「プロダクト・アクション」の関係「フィーチャ」について照会を行い、まず、それらが妥当（すなわち顧客情報に関連づけられている）か否かを判断する。妥当でない場合、「タスク・プラン」を進めることができない。遭遇したこの特定のマイルストーンが、ロッキングを行う必要があることを示しているものとしてフィーチャによって保持されているマイルストーンである場合、「フィーチャ・ロック状況フラグ」が真に設定され（図３参照）、マイルストーン・タスクに肯定応答が返され、それによって提供を続行することができる。このフラグが設定されると、その結果として、プロダクト・フィーチャの属性を変更することができなくなり、「ロックされた」状態になる。タスク・マイルストーンがフィーチャによって保持されているマイルストーンと一致しない場合でも、タスク・プランは継続することができ、フィーチャは「ロック解除」状態のままである。
【００９２】
図７には（タスク・プランに加えて）、各プロダクト・フィーチャによって保持されている関係する提供活動マイルストーンが示されている。火曜日に接続するＳＷＡ−Ｃの例の場合、マイルストーン「提供開始」２５４が該当する。すなわち、ＰＳマイルストーンが通過した場合、「スケジューリング・フィーチャ」がそのロック状態フラグを設定し、「顧客要求日付」を変更することができない。
【００９３】
ロッキング・プロセスの他の態様は、ＣＳＲが提供タスクの進捗状況を照会することができ、それによって顧客に「交換接続が今日行われる」と伝えることができる。
【００９４】
「プロダクト定義」および「注文管理」とコンピューティング・システムとの対話
図８、図９は、具体的にクライアント・ワークステーション２０、サーバ３０、およびデータベース４０を参照し、図３を参照しながら前述した、プロダクト定義時点」活動に関する説明を要しない流れ図である。
【００９５】
図１０、図１１、図１２は、具体的にクライアント・ワークステーション２０、サーバ３０、およびデータベース４０を参照し、図４から図７を参照しながら上述した、「注文管理」活動に関する同様の説明を要しない流れ図である。
【００９６】
【発明の効果】
属性ロッキングの利点は、顧客がプロダクトまたはサービスを受ける確約をした後、そのプロダクトまたはサービスを提供するための作業がすべて完了する前に、フィーチャ属性に変更を加えることができることである。たとえば、要求された完了日や（たとえば期限日の前に）割り振られた認識番号に変更を加えることができるようになる。システム管理者は、上述の方式でフィーチャのロックを管理することによって、データの矛盾や請求の誤りを防止することができる。したがって、変更が実施される前に、ＣＳＲおよびその他の利用者に、各フィーチャのメンテナンス可能状況に関する情報を提供することができる。
【００９７】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００９８】
（１）各プロダクトがロッキング・マイルストーンを規定する属性を持つフィーチャを有する、関連のあるメタ・レベル・ドメイン・プロダクトを提供する顧客サービス・コンピューティング・システムのシステム・レベル・ドメイン内に存在する一連の順次タスクを実行する方法であって、
（ａ）前記タスクのうちの１つまたは複数のタスクをマイルストーンとして指定するステップと、
（ｂ）前記順次タスクを実行するステップとを含み、前記各マイルストーン・タスクについて、
（ｉ）関連のある前記プロダクト・フィーチャについて照会を行い、前記タスク・マイルストーンが前記ロッキング・マイルストーンに対応するか否かを判断するステップと、対応する場合には、
（ii）前記実行を続行するステップとを含む方法。
（２）ステップ（ｉ）が真の場合、前記タスク・シーケンスが完了するまで前記フィーチャの属性を変更することができないように前記フィーチャをロック状態にするステップをさらに含む、上記（１）に記載の方法。
（３）ステップ（ｂ）（ｉ）の前に、前提条件として、前記フィーチャが有効であるように前記フィーチャを顧客に関連づける属性を有するか否かを判断するステップをさらに含む、上記（２）に記載の方法。
（４）マイルストーン・タスクが前記メタ・レベル・ドメイン内の前記プロダクト・フィーチャの局面として反映され、前記メタ・レベル・ドメインにおいてマイルストーン状況を規定するステップをさらに含む、上記（３）に記載の方法。
（５）顧客サービス・コンピューティング・システムにおいて品物およびサービスを提供する方法であって、
（ａ）各プロダクトが関連するロッキング・マイルストーンを規定する属性を持つフィーチャを有する、前記品物およびサービスに関係するメタ・レベル・ドメイン内に存在する複数のプロダクト・アクションのうちのいずれか１つに必要な提供を表すシステム・レベル・ドメイン内の１つまたは複数の一連の順次タスクを定義するステップと、
前記各シーケンスについて、
（ｂ）前記タスクのうちの１つまたは複数のタスクをマイルストーンとして指定するステップと、
（ｃ）前記順次タスクを実行するステップとを含み、前記各マイルストーン・タスクについて、
（ｉ）前記プロダクト・フィーチャについて照会を行い、前記タスク・マイルストーンが前記ロッキング・マイルストーンに対応するか否かを判断するステップと、対応する場合には、
（ii）前記実行を続行するステップとを含む方法。
（６）ステップ（ｉ）が真の場合、前記タスク・シーケンスが完了するまで前記プロダクト・フィーチャの属性を変更することができないように前記プロダクト・フィーチャをロック状態にするステップをさらに含む、上記（５）に記載の方法。
（７）ステップ（ｂ）（ｉ）の前に、前提条件として、前記フィーチャが有効であるように前記フィーチャを顧客に関連づける属性を有するか否かを判断するステップをさらに含む、上記（６）に記載の方法。
（８）マイルストーン・タスクが前記メタ・レベル・ドメイン内の前記フィーチャの局面として反映され、前記メタ・レベル・ドメインにおいてマイルストーン状況を定義するステップをさらに含む、上記（７）に記載の方法。
（９）品物およびサービスを提供するコンピューティング・システムであって、各プロダクトが関連するロッキング・マイルストーンを定義する属性を持つフィーチャを有し、前記品物およびサービスに関係するメタ・レベル・ドメイン内に存在する複数のプロダクト・アクションのうちのいずれか１つに必要な提供を表すシステム・レベル・ドメイン内の１つまたは複数の順次タスクを定義し、各シーケンスについて、前記タスクのうちの１つまたは複数のタスクをマイルストーンとして指定し、前記各マイルストーン・について前記プロダクト・フィーチャに関する照会を行って前記タスク・マイルストーンが前記ロッキング・マイルストーンに対応するか否かを判断するように前記シーケンスのタスクを実行するように動作可能なプロセッサ手段を含むコンピューティング・システム。
（１０）前記プロセッサ手段が、前記照会が真の場合に前記タスク・シーケンスの実行が完了するまで前記フィーチャの属性を変更することができないように前記フィーチャをロック状態にするようにさらに動作可能な、上記（９）に記載のシステム。
（１１）前記プロセッサ手段が、前提条件として、前記フィーチャが有効であるように前記フィーチャを顧客に関連づける属性を有するか否かを判断するようにさらに動作可能な、上記（１０）に記載のシステム。
（１２）マイルストーン・タスクが前記メタ・レベル・ドメイン内の前記フィーチャの局面として反映され、前記プロセッサ手段が前記メタ・レベル・ドメインにおいてマイルストーン状況を定義するようにさらに動作可能な、上記（１１）に記載のシステム。
【図面の簡単な説明】
【図１】本発明を実施する３層コンピューティング・システムのトポロジを示す図である。
【図２】「プロダクト」と「タスク」の間のメタ状態マッピングを示す図である。
【図３】「プロダクト」ドメイン内で実行可能なサブシステムを示す図である。
【図４】「プロダクト」定義に関する各状態を示す流れ図である。
【図５】インスタンシエートされた「プロダクト」を示す図である。
【図６】タスク・マッピング・プロセスのオブジェクト相互作用図である。
【図７】属性ロッキングを使用したタスク・プランを示す図である。
【図８】コンピューティング・システム要素を参照しながら新規「プロダクト」定義を説明する流れ図である。
【図９】コンピューティング・システム要素を参照しながら新規「プロダクト」定義を説明する流れ図である。
【図１０】コンピューティング・システム要素を参照しながら「注文管理時点」を説明する流れ図である。
【図１１】コンピューティング・システム要素を参照しながら「注文管理時点」を説明する流れ図である。
【図１２】コンピューティング・システム要素を参照しながら「注文管理時点」を説明する流れ図である。
【符号の説明】
１０ コンピューティング・システム
２０ ワークステーション
２４ 遠隔電話端末
３０ サーバ
４０ データベース
５０ ローカル・エリア・ネットワークまたはワイド・エリア・ネットワーク
６０ 通信リンク
７０ 外部ネットワーク
２５０ マイルストーン
２５６ タスク
【発明の属する技術分野】
本発明は、品物、サービス、または情報管理を提供するために使用されるコンピューティング・システムに関する。特に、本発明は、業務関連プロダクトを提供するシステム関連タスクの順序付けに関する。
【０００２】
【従来の技術】
最新の大規模コンピューティング・システムでは、一般的なトポロジは、（ｉ）ユーザ対話に焦点を絞った複数のワークステーションを特徴とするプレゼンテーション層と、（ii）アプリケーション／ビジネス・ロジックを実行する複数のサーバを特徴とする業務層と、（iii）データの記憶と編成を処理する複数のデータベースを特徴とするデータ層との３つの層を有する。この３つの要素は、ローカルまたはワイド・エリア・ネットワーク（ＬＡＮ／ＷＡＮ）によって相互接続される。
【０００３】
このようなコンピューティング・システムは、大学の研究／教育施設から業務応用分野まで及ぶ多種多様な分野に適用されている。実際に、あらゆる企業が、このようなシステムを使用してその業務を処理し、顧客にサービスを提供している。たとえば、このようなシステムは在庫管理、文書処理、会計の用途や、顧客の問い合わせへの対応に使用することができる。多くの企業は、きわめて大規模な顧客基盤を有し、膨大な在庫の商品やサービスを提供する。その一例は、全国規模の顧客基盤にサービスを提供する通信サービス提供者（Telco）である。したがって、Telcoの加入者は、数百万人に達することがあり、各顧客は、請求書発行情報から発注状況の問い合わせ、製品の発注にわたるどのような問い合わせに対しても顧客サービス担当者（ＣＳＲ）からのほとんど即時の応答を期待する。
【０００４】
同様の例は、公益事業、保険会社、銀行、病院、法律事務所、会計事務所、証券取引所、大学、政府機関にも見られ、これらはほんの一例に過ぎない。
【０００５】
このようなすべてのコンピューティング・システムでは、ソフトウェア資源とハードウェア資源の間に本質的な拮抗がある。顧客需要や提供する商品およびサービスの複雑さが増すにつれて、コンピューティング・ハードウェアの規模を拡大しようとするだけでは、経済的に非効率的であり、技術的に限界がある。
【０００６】
そうする代わりに、ソフトウェア・コーディング、データベース管理、およびシステム・ファームウェア・アーキテクチャを改良することによって可能な、システム・パフォーマンスの大幅な向上がある。スケーラビリティを実現する必要がある場合、これらの設計要素をすべて考慮する必要がある。「スケーラビリティ」とは、増大するデータ、取引、およびユーザ基盤に対処する３層コンピューティング・アプリケーションの（ワークステーションとサーバとデータベースとの間で受け渡しされる情報の数とタイプで表した）能力を意味する。
【０００７】
アプリケーション・プログラム・ソフトウェアのメンテナンスの問題の一手法が、特開平１０−３２６１９０（アイ・ビー・エム・コーポレイション）で開示されており、これはオブジェクト指向プログラムと、様々なプログラムを分類制度に従って統制する制御フレームワーク・データベースとを使用する。
【０００８】
【発明が解決しようとする課題】
「提供」とは、業務要求を実行するために実際に行う必要がある作業である。提供アクションは、典型的には、特定の順序で完了しなければならない相互に関係のある複数のタスクを必要とする。この要件のための一手法は、特開平０５−３４２２２７（東京電気株式会社）に記載されている。この参照特許では、個々のアクションは始点と終点によって規定された期間だけ有効な構成が開示されている。よく評価しても、これは制限のある手法である。
【０００９】
本発明は、従来の技術の問題を克服するか少なくとも改善しようとするものである。
【００１０】
【課題を解決するための手段】
本発明は、各プロダクトがロッキング・マイルストーンを規定する属性を持つフィーチャを有する、関連のあるメタ・レベル・ドメインプロダクトを提供する顧客サービス・コンピューティング・システムのシステム・レベル・ドメイン内に存在する一連の順次タスクを実行する方法であって、
（ａ）前記タスクのうちの１つまたは複数のタスクをマイルストーンとして指定するステップと、
（ｂ）前記順次タスクを実行するステップとを含み、前記各マイルストーン・タスクについて、
（ｉ）関連のある前記プロダクト・フィーチャについて照会を行い、前記タスク・マイルストーンが前記ロッキング・マイルストーンに対応するか否かを判断するステップと、対応する場合には、
（ii）前記実行を続行するステップとを含む方法を提供する。
【００１１】
本発明は、顧客サービス・コンピューティング・システムにおいて品物およびサービスを提供する方法であって、
（ａ）各プロダクトが関連するロッキング・マイルストーンを規定する属性を持つフィーチャを有する、前記品物およびサービスに関係するメタ・レベル・ドメイン内に存在する複数のプロダクト・アクションのうちのいずれか１つに必要な提供を表すシステム・レベル・ドメイン内の１つまたは複数の一連の順次タスクを定義するステップと、
前記各シーケンスについて、
（ｂ）前記タスクのうちの１つまたは複数のタスクをマイルストーンとして指定するステップと、
（ｃ）前記順次タスクを実行するステップとを含み、前記各マイルストーン・タスクについて、
（ｉ）前記プロダクト・フィーチャについて照会を行い、前記タスク・マイルストーンが前記ロッキング・マイルストーンに対応するか否かを判断するステップと、対応する場合には、
（ii）前記実行を続行するステップとを含む方法をさらに提供する。
【００１２】
本発明は、品物およびサービスを提供するコンピューティング・システムであって、
各プロダクトが関連するロッキング・マイルストーンを規定する属性を持つフィーチャを有し、前記品物およびサービスに関係するメタ・レベル・ドメイン内に存在する複数のプロダクト・アクションのうちのいずれか１つに必要な提供を表すシステム・レベル・ドメイン内の１つまたは複数の順次タスクを定義し、各シーケンスについて、前記タスクのうちの１つまたは複数のタスクをマイルストーンとして指定し、前記各マイルストーン・について前記プロダクト・フィーチャに関する照会を行って前記タスク・マイルストーンが前記ロッキング・マイルストーンに対応するか否かを判断するように前記シーケンスのタスクを実行するように動作可能なプロセッサ手段を含むコンピューティング・システムをさらに提供する。
【００１３】
照会が真の場合、前記タスク・シーケンスの実行が完了するまでプロダクト・フィーチャの属性を変更することができないように、プロダクト・フィーチャがロック状態にされるので有利である。フィーチャが有効になるようにフィーチャを顧客と関連づける属性を有するか否かを判断するという前提条件がある場合がある。マイルストーン・タスクは、メタ・レベル・ドメイン内の前記フィーチャの局面として反映される。
【００１４】
【発明の実施の形態】
図１は、本発明を実施する３層コンピューティング・システム１０の代表的なトポロジである。プレゼンテーション（またはクライアント／ユーザ）層は、適切なコンピューティング端末、たとえばパーソナル・コンピュータとすることができるいくつか（１．．．ｎ個）のワークステーション２０によって表されている。業務層は、ミニ・コンピュータまたはメインフレーム・コンピュータとすることができるいくつかの（１．．．ｐ個）のサーバ３０によって表されている。データ層は、いくつかの（１．．．ｍ個）のデータベース４０によって表され、これらのデータベースは動的に管理される磁気記憶媒体または光記憶媒体とすることができる。
【００１５】
コンピューティング・システム１０は、「オープン」設計であり、外部ネットワーク７０、７２、７４を介して同様の装置２２、３２、４２および遠隔電話端末２４、２６への通信リンク６０、６２、６４を備える。
【００１６】
ワークステーション２０、サーバ３０、およびデータベース４０は、ローカル・エリア・ネットワークまたはワイド・エリア・ネットワーク（ＬＡＮまたはＷＡＮ）５０によって相互接続されている。ＬＡＮ／ＷＡＮ５０は、前述の３つの各基本要素の間で受渡しされる情報を伝達する。図１に示すトポロジは代表例に過ぎず、ワークステーション２０、サーバ３０、およびデータベース４０間での情報の受渡しという目的が達成されるような他の好都合な形態のネットワークも実施可能であることがわかるであろう。
【００１７】
本発明の実施形態は、前述の「従来の技術」の項に記載の分野において産業的に利用することができる。非限定的例示のために、米国の多くの州にわたって営業しているTelcoの例を考えてみる。このようなTelcoは、一般に、市内、地域、州間、および国際音声およびデータ電話と、セルラ移動体音声およびデータ通信をサポートする。Telcoの顧客は、たとえば第２の電話／ファクス／インターネット回線の設置、呼出しの転送、メッセージ送信を含む、広範囲な品物およびサービスから選択することができる。顧客は、ワークステーション２０に配属された顧客サービス担当者（ＣＳＲ）に請求金額やサービスの障害に関する問い合わせを行うことができることも期待する。現代のTelcoは少なくとも百万人の顧客を有し、一般に、少なくとも５００人のＣＳＲを必要とすると予想するのは妥当である。この規模のTelcoのシステム基盤は、１時間当たり約１５，０００件の業務取引を処理すると予想することができる。各業務取引について、６件のＣＳＲマシン・トランザクションが必要と考えられ、個々のマシン・トランザクションは最大２０件のデータベース・トランザクション（すなわち入出力）必要とする可能性がある。
【００１８】
このようなパフォーマンスを達成するのに必要な規模のコンピューティング・ハードウェアのよりよい例を示すと、ＣＳＲワークステーション２０は、Windows NT（商標）オペレーティング・システムが稼働しているPentium（商標）パーソナル・コンピュータであり、サーバ３０は１つまたは複数のＩＢＭ ＵＮＩＸ（商標）ベースの１２ウェイＲＳ６０００（商標）Ｓ−７０機とすることができ、データベースは、Oracle（商標）またはＩＢＭ ＤＢ−２（商標）システムによって管理された約４０ギガバイトの容量を必要とすることになる。当業者なら容易にわかるように、当然ながら、データ通信を処理する他の稼働ＬＡＮ／ＷＡＮサーバもあるであろう。
【００１９】
Telcoなどの業務システムでは、顧客はＣＳＲに電話をして、国内電話回線での「キャッチホン」を利用できるようにする要求など、品物またはサービスを日常言語で要求する。実際に、ＣＳＲはこのレベルの業務も行い、そのような品物やサービスに関する情報がワークステーションの表示画面上に（ＧＵＩ）としてＣＳＲに提示される。そしてコンピューティング・システム１０は、顧客の注文した品物またはサービス、あるいは問い合わせに応じて動作する。
【００２０】
本発明の目的の１つは、スケーラビリティを実現することである。この目的の達成を支援するために採用されているシステム・モデルは、「ステートレス」である。これは、要求者の前の関連情報の記録がサーバ３０上で保持されずに、データがサーバ３０およびデータベース４０に渡されることを意味する。言い換えると、あらゆるシステム・トランザクションはそれ自体で完結し、いずれかのユーザまたは当該ユーザのためにサーバ内で実行された以前のシステム・トランザクションを知る必要がない。
【００２１】
他の関連する態様は、ワークステーション２０を特定の１つのサーバ３０とのみ通信するように制約しないという設計上の選択である。ワークステーション２０からの情報要求を、「ｐ」個のサーバ３０のいずれか１つに宛てて送ることができる。さらに、「ｍ」個のデータベース４０にアクセスすることができるのはサーバ３０のみである。
【００２２】
他の設計上の選択は、コンポーネント化を可能にするオブジェクト指向プログラミングの使用である。オブジェクト指向プログラミングは、再使用可能性、低（ソフトウェア）メンテナンス、わかりやすさ、および拡張可能性を特徴とする。したがって、関連づけられた動作をプロセス状態のビルディング・ブロックとしリンクすることを可能にする。
【００２３】
オブジェクト指向プログラミングの原理は、ジェームズ・ランボー（James Runbaugh）、アイヴァー・ジェーコブセン（Ivar Jacobsen）、およびグレイディ・ブーク（Grady Booch）による「The Unified Modeling Language Reference Manual」（Addison-Wesley、１９９８年１２月刊）（ＩＳＢＮ０−２０１−３０９９８−Ｘ）に記載されている。
【００２４】
概要
システム１０によってサポートされる「品物やサービス」を「プロダクト」と呼ぶ。プロダクトは、コンピューティング・システム１０のワークステーション２０とサーバ３０の両方に存在するメタ・データである。プロダクトは、「アクション」と「タグ付きアクション」とによって構成される。各アクション内には、「フィーチャ」と「提供タスク」とがあり、それぞれ「属性」で構成されている。
【００２５】
ここで、「定義時点（Definition Time）」と「注文管理時点（Order Management Time）」という概念について概説すれば役に立つであろう。「定義時点」とは、顧客との関連づけのために使用可能なところまで新しい「プロダクト」の定義（または既存のプロダクトの修正）に関係する。「注文管理時点」は、新しい「プロダクト」が有効になって送り出され、ワークステーションにいるＣＳＲにとって使用可能になる時である。「注文管理時点」で、オブジェクトはインスタンシエートされ、定義済み「プロダクト・テンプレート」に「実」データが入れられ、このプロダクト・テンプレートに従って「プロダクト・アクション」の提供またはデータベース照会が行われるようになっている。
【００２６】
プロダクトは、「定義時点」中に定義され、ＣＳＲが顧客の注文に応答してインスタンスをポピュレートするために使用できるようになる。図２に示すように、プロダクト１００は、マッピング・プロセス１１０を施されて、「プロダクト」を実行する一連のタスク１２０になる。タスクは、サーバ３０内とデータベース４０内に存在し、「プロダクト・アクション」に値を返すことができる。返された値によって「プロダクト・アクション」状況情報および構成「フィーチャ」属性が更新される。
【００２７】
図３に、様々な「プロセス・サブシステム」の相互作用を示す。「定義時点」にサブシステム「プロダクト定義」１３０、「価格設定」１３５、および「提供定義」１４０が作成される。「顧客プロダクト」１４５と「提供実行時」１５０サブシステムは、「注文管理時点」中にのみ発生する。
【００２８】
「プロダクト定義」サブシステム１３０は、多くのメタ・データ「プロダクト」を含み、例示のために「コーリング・カード」プロダクト定義が示されている。「コーリング・カード」は、少なくともプロダクト「ワイヤレス・アクセス」（破線で図示されている）との（必要な）関連づけを有する。また、構成フィーチャ「スケジューリング」、「コーリング・カード（Calling Card）」、「メモ」、「認識番号」、および「課金」を持つ「コーリング・カード追加」プロダクト・アクション定義も有する。
【００２９】
「価格設定」サブシステム１３５は、関連づけられたフィーチャ「グローバル・オプション」、「交換料金」、および「幹部特権」を持つ「料金プラン」定義を有する。
【００３０】
同様に、「提供定義」サブシステム１４０は、必要な場合に「コーリング・カードの追加」を提供するために行う必要がある実際の作業に関係する特定の「タスク」が関連づけられた各「プロダクト・アクション」（この場合は「コーリング・カード」のみが図示されている）のための「提供活動プラン」を有する。これらの「タスク」は、「ネットワークの起動」、「請求の更新」、「認識番号の割振り」、および「遂行のディスパッチ」として記載されている。
【００３１】
「注文管理時点」は、（この場合）（「プロダクト」サブシステム１４５において）ＣＳＲに対して行われたコーリング・カード・サービスを求めるジョー・スミスの要求で開始される。この結果、「ジョー・スミスの）コーリング・カード追加」アクションが行われる。ＣＳＲは、ジョー・スミスに、特定の「コーリング・カード・フィーチャ」要件「コーリング・カード」、「認識番号」、「メモ」、「スケジューリング」、および「課金」に関して尋ねる。「課金」フィーチャによって、記憶されている「コーリング・カード課金プラン」記録の照会も行われ、アクションに関連づけられることになる適切な情報が取り出される。
【００３２】
この要求は次に、提供のために「提供実行時」サブシステム１５０に渡される。「コーリング・カード追加」アクションのために「提供活動プラン」がインスタンシエートされ、その形式が「提供定義」サブシステム１４０から取り出され、前述のように「顧客プロダクト」サブシステム１４５において収集された属性と共にポピュレートされる。次に、一連のタスク、すなわち「ジョーのネットワークの起動」および「ジョーの遂行のディスパッチ」が実行される。これらのタスクが実行された後は、「ジョー・スミスのコーリング・カード」が「顧客プロダクト」サブシステム１４５内で有効になり、「認識番号フィーチャ」および「コーリング・カード・フィーチャ」が関連づけられ、さらに、ジョーの既存の「ワイヤレス・アクセス・プロダクト」と関連づけられる。
【００３３】
プロダクト
プロダクトは、特定の業務または顧客の必要に合うように定義することができる。その意味で、既存の「プロダクト」を何らかの方法で修正したり、新しい「プロダクト」を「プロダクト・ブック」に追加したりすることができる。「プロダクト・ブック」は、居住顧客に販売することができるものなど、プロダクトを論理的にグループ化したものである。Telco環境でのプロダクトには、以下のものを含めることができる。
標準ワイヤライン・アクセス：家庭が電話の物理製品を持つことができるようにする家庭へのワイヤライン接続。
キャッチフォン：顧客が電話に出ているときに、顧客の電話に着信した別の呼出があることを顧客に通知する機能。
呼出転送：電話呼出を別の電話／メール・ボックス／ページャなどにリルートする機能。
標準ワイヤレス・アクセス：携帯電話システムへの接続。
【００３４】
再び図２を参照すると、「プロダクト」１００は、（ａ）アクションと、任意選択により（ｂ）「タグ付きアクション」を伴う。アクションは、特定の顧客アカウント／サービスのための特定の「プロダクト」の「追加」または「削除」、あるいは「プロダクト」の構成の変更とすることができる。
【００３５】
たとえば「サービスの場所（ＬＯＳ）」や「ネットワーク識別子（ＮＩ）」など、関連づけられた「フィーチャ」によって構成することができる。「フィーチャ」は、収集されたデータ・インスタンスを定義する。アクションは、関連づけられた「提供活動」も有し、「提供活動」は、「アクション」を実行するために必要なタスク（電子的タスクと、場合によっては人間の介入も指定する）に関係する。
【００３６】
個々の「アクション」は１つまたは複数の他の「プロダクト・アクション」あるいは「プロダクト・アクション」のグループとの関係を有することができることに留意されたい。これらの関係は、「タグ付き」アクションによって表現することができる。この「タグ付きアクション」は、ＣＳＲの観点からは関係に関する明白な知識がなくても、販売の観点から２つのアクションを関連づけることができるようにする。たとえば、Telcoが「保守契約」を「ワイヤレス・アクセス」販売と常に関連づけたいとする。この場合、２つの「プロダクト・アクション」（すなわち「保守契約の追加」と「ワイヤレス・アクセスの追加」）の間に「タグ付き関係」を作成する。これは、ＣＳＲが、いつ「ワイヤレス・アクセス・プロダクト」を販売し、「保守契約」も販売しなければならないかを明白に覚えている必要がなく、ＣＳＲはプロンプトによって指示されることを意味する。
【００３７】
（その属性と共にポピュレートされる際の）「プロダクト」とタスクとの「マッピング・プロセス」１１０では、「タスク・マッパ・キー」を使用する。「属性」は、「プロダクト」をタスクに関連づけるために使用されるデータの単位である。「タスク・マッパ・キー」形式は、インスタンシエートされた形の「プロダクト・テンプレート」によって保持される。
【００３８】
タスク
タスク・ドメイン１２０は、低レベルの抽象化において機能し、メタ状態を記述する。タスクは、（照会であるかプロダクトの提供としてであるかを問わず）「プロダクト・アクション」を実行するために完了する必要がある作業を表す。タスクは、「タスク・プラン」と呼ばれるグラフ型の構造として編成される。
【００３９】
オブジェクト指向の用語では、「タスク」のインスタンスはオブジェクトである。「タスク」の定義はクラス（すなわちプログラムされたコード）である。タスクがインスタンシエートされるとき、１つのタスク・インタンスを他のタスク・インタンスと差別化するデータがデータベース４０から読み取られる。
【００４０】
「提供活動プラン」内で、特定の「タスク」が「マイルストーン」として機能する。これらのタスクは、作業の流れの適切な進行に関するデータの妥当性を保証するチェックポイントとみなすことができる。これらのチェックポイントで、「プロダクト」ドメインと「タスク」ドメインの間でメッセージが送られ、それらが互いに同調され、システム・プロセスの続行にとって妥当であるか否かが判断される。これらの「マイルストーン」が、たとえば「認識番号割振り（ＳＮＡ）活動」内に収まっている様子を示す一例は、「認識番号の割振り」の後にマイルストーンがあることである。タスクは、認識番号データ要素（プロダクト・フィーチャ」が有効であることを保証しなければならない場合がある。有効でない場合、システムはその「認識番号の割振り」活動マイルストーンを越えて進むことはできない。この場合、「認識番号フィーチャ」が有効でなければ、マイルストーンは失敗し、提供は続行することができない。「プロダクト・フィーチャ」をロックすべき時点に関する規則が、「プロダクト定義」時に定義される。すなわち、所与の「プロダクト・アクション」について、所与の「マイルストーン」において「プロダクト・フィーチャ」がロックされ、ＣＳＲによるそれ以上の更新が行われないようにする。
【００４１】
例
プロダクト定義
新しい「プロダクト」定義の第１の例は、顧客に新しい「標準ワイヤライン・アクセス」（ＳＷＡ）プロダクトを提供するTelcoに関するものである。
【００４２】
このプロダクトを定義する以下のステップは、図４を参照しながら読まれたい。
【００４３】
ステップ２０１（必須）：「プロダクト」を作成し、それに「標準ワイヤライン・アクセス」という名前を付ける。これによって、「標準ワイヤレス・アクセス」という名前の「プロダクト」オブジェクトが作成される。
【００４４】
ステップ２０１（ａ）（任意選択）：「前提プロダクト」によって、追加する当該プロダクトの前提状件である他のプロダクトの指定が可能になる。たとえば、「ワイヤレス・アクセスの呼出転送」は、まず、「標準ワイヤライン・アクセス」を定義してからでなければ定義することができない。
【００４５】
ステップ２０２（必須）：「標準ワイヤライン・アクセス」を作成し、「接続」という名前を付けて、そのタイプを事前定義済みのアクション・タイプである「追加」と定義する。これにより、「アクション」オブジェクトが形成され、それに「標準ワイヤライン・アクセス」オブジェクトが関連づけられる。
【００４６】
ステップ２０３（任意選択）：「保守契約」２０９プロダクトの「追加」アクションに対する「タグ付き」関係を作成する。これは、前もって作成されたプロダクト・アクションのリストから「保守契約」−「追加」プロダクト・アクションを選択することによって行われる。
【００４７】
ステップ２０４（必須）：「プロダクト・フィーチャ」関係を作成し、「接続」プロダクト・アクションに追加する。
【００４８】
ステップ２０４ａ：フィーチャの事前定義済みリストから「サービスの場所」フィーチャを選択する。これにより、「サービスの場所」フィーチャ定義が作成され、これが「接続」プロダクト・アクションに関連づけられる。
【００４９】
ステップ２０４ｂ：フィーチャの事前定義済みリストから「ネットワーク」フィーチャを選択する。これにより、「ネットワーク」フィーチャ定義が作成され、これが「接続」プロダクト・アクションに関連づけられる。
【００５０】
ステップ２０４ｃ：フィーチャの事前定義済みリストから「認識番号」フィーチャを選択する。これにより、「認識番号」フィーチャ定義が作成され、これが「接続」プロダクト・アクションが関連づけられる。
【００５１】
ステップ２０４ｄ：フィーチャの事前定義済みリストから「電話帳」フィーチャを選択する。これにより、「電話帳」フィーチャ定義が作成され、これが「接続」プロダクト・アクションに関連づけられる。
【００５２】
ステップ２０４ｅ：フィーチャの事前定義済みリストから「スケジュール」フィーチャを選択する。これにより、「スケジュール」フィーチャ定義が作成され、これが「接続」プロダクト・アクションに関連づけられる。
【００５３】
ステップ２０４ｆ：フィーチャの事前定義済みリストから「課金」フィーチャを選択する。これにより、「課金」フィーチャ定義が作成され、これが「接続」プロダクト・アクションに関連づけられる。
【００５４】
ステップ２０５（必須）：「提供マイルストーン・タスク／マイルストーン」を作成し、「接続」アクション２に追加する。
【００５５】
ステップ２０５ａ：「提供タスク／マイルストーン」の事前定義済みリストから「始点」マイルストーンを選択する。これにより、「始点」マイルストーン定義が作成され、これが「接続」プロダクト・アクションに関連づけられる。
【００５６】
ステップ２０５ｂ：「提供タスク／マイルストーン」の事前定義リストから「実行依頼済み」マイルストーンを選択する。これにより、「実行依頼済み」マイルストーン定義が作成され、これが「接続」プロダクトに関連づけられる。
【００５７】
ステップ２０５ｃ：提供タスク／マイルストーンの事前定義リストから「提供開始済み」マイルストーンを選択する。これにより、「提供開始済み」マイルストーン定義が作成され、これが「接続」プロダクトに関連づけられる。
【００５８】
ステップ２０５ｄ：提供タスク／マイルストーンの事前定義リストから「交換接続」タスクを選択する。これにより、「交換接続」タスク定義が作成され、これが「接続」プロダクトに関連づけられる。
【００５９】
ステップ２０５ｅ：提供タスク／マイルストーンの事前定義済みリストから「サービス起動」マイルストーンを選択する。これにより、「サービス起動」タスク定義が作成され、これが「接続」プロダクトに関連づけられる。
【００６０】
ステップ２０５ｆ：提供タスク／マイルストーンの事前定義角済みリストから「提供完了」マイルストーンを選択する。これにより、「提供完了」マイルストーン定義が作成され、これが「接続」プロダクトに関連づけられる。
【００６１】
ステップ２０５ｇ：その他の提供タスクを選択する。
【００６２】
ステップ２０６（図示せず）：「標準ワイヤライン・アクセス」を「住宅用」プロダクト・ブックに関連づける。このプロダクトがＣＳＲによる販売のためのプロダクト・ブックに追加される。
【００６３】
ステップ２０７（図示せず）：プロダクトをテストする。プロダクト構造の整合性を検証する一連のテストが実行される。
【００６４】
ステップ２０８（図示せず）：プロダクトを送り出す。これで、「標準ワイヤライン・アクセス」が、ＣＳＲが閲覧し、販売するために使用できるようになる。
【００６５】
注１：このリストは、「標準ワイヤライン・アクセス」プロダクトにすでに関連づけられているプロダクト・フィーチャのリストと、プロダクト・アクションに直接関連づけられるように特別に設定されたプロダクト・フィーチャのリストとから作成される。各プロダクト・フィーチャの属性の１つは、フィーチャをロックする必要がある所望の提供マイルストーンの参照である（ステップ２０５の活動の１つを参照）。
【００６６】
注２：これは、提供するタスクの可能な総数のうちの部分的なリストであり、典型的なマイルストーンを示すものである。
【００６７】
図５に、ＳＷＡ−Ｃプロダクト・アクションの図４のプロダクト・テンプレートのインスタンシエートされた形（すなわち「注文管理時点」における形）を示す。インスタンシエートされたＬＯＳ、Ｎ、ＳＮ、Ｓ、およびＣフィーチャの属性は以下の通りである。
【表１】
ジョー・スミスの「標準ワイヤライン・アクセス」を接続する「提供活動プラン」は、提供のために要求が実行依頼されるときに作成される。
【００６９】
タスク・マッピング
インスタンシエートされた「プロダクト・アクション」を「タスク・プラン」にマッピングするプロセス１１０は、「タスク・マッパ・キー」および関連づけられた「タスク・テンプレート」を必要とする。基本的には、行われるステップは以下の通りである。
１．インスタンシエートされた「プロダクト・テンプレート」の属性のうちから「タスク・マッパ・キー」を作成する（たとえば図５）。
２．各構成「提供活動」について、（事前記憶され、定義されたライブラリの中から）適切な「タスク・テンプレート」を探し出す。
３．構成「タスク・テンプレート」から「タスク・プラン」を作成し、特定の作業タスクのシーケンスとして実行するために使用可能になる。
【００７０】
マッピング・プロセスの一例について、図６のオブジェクト相互作用図を参照しながら以下に説明する。
【００７１】
タスク・マッパ・キー
「タスク・マッパ・キー」は、提供の作業を行わなければならない特定のタスクを識別するためにその値が使用される「プロダクト・アクション」に関連づけられた属性の特定のサブセットである。
【００７２】
サーバ・プロセスによって、ＳＷＡ−Ｃアクションのための「タスク・マッパ・キー」の作成が指示される（MapToTasks()）。マイルストーンとして指定されたものを除き、各「提供活動」２０５が順に検討される。
【００７３】
説明を簡単にするため、「交換接続」提供活動２０５ｄについてのみ考えてみる。この活動のために、getTaskMapperKeyDefinition()コマンドが、「交換接続」２０５ｄの定義フォームから以下のストリングを取り出す。
Region&SwitchID&ExchangeID
【００７４】
コマンドgetActivityDefinitionIDが、「交換接続」２０５ｄの定義フォームから以下のストリングを取り出す。
value
【００７５】
次に、「ジョー・スミスのサービス場所」２０４（ａ）および「ジョー・スミスのネットワーク」２０４（ｂ）の実行時版から入手した各パラメータ（すなわち地域、スイッチＩＤ、および交換ＩＤ）について、コマンドgetAttributeValue()が実行される。
【００７６】
この例では、「活動定義ＩＤ」は「１２３」である。「タスク・マッパ・キー定義」は「Region&SwitchID&Other」であり、この中の「＆」は区切り演算子である。「ジョー・スミスの交換接続」活動に代入される値は、「活動定義ＩＤ」である。「活動定義ＩＤ」で保持される必須キーの数は、この例では「２」である。
【００７７】
「タスク・マッパ・キー」が作成され、「Yorktown&Switch2&AAA」となる。
【００７８】
タスク・テンプレートの探索
「タスク・テンプレート」の事前定義済みリストがデータベース４０で維持され、各タスク・テンプレートは「タスク・プラン」全体の一部を構成する作業タスクのシーケンスを表す。
【００７９】
コマンドSearchForRow（ActivityDefinitionID, TaskMapperKey）が実行され、それによって「タスク・マッパ・キー」が「タスク・テンプレート」のセットと対照される。
【００８０】
データベースで「活動定義ＩＤ」と「タスク・マッパ・キー」を探索する。したがって、１２３、「Yorktown&Switch2&AAA」を探索する。取り出された以下のデータベース項目について考えてみる。
【表４】
完全な一致がある場合、「タスク・テンプレート発見」状態になっている。しかし、上記の項目では、空結果になる。このような場合、探索を制限し、adjust Task Mapper Key()コマンドを呼び出すことになる。必須キーの数は「２」であるため、「タスク・マッパ・キー」は「Yorktown&Switch2」となり、この場合、上掲のデータベース項目の３行目に一致があり、タスク・テンプレートが得られる。
【００８２】
任意選択キーがすべて破棄された後でもなお、縮小された「タスク・マッパ・キー」と「タスク・テンプレート」との間に一致がない場合、SearchForDefaultRow（ActivityDefinitionID）コマンドを呼出し、それによって、活動ＩＤ＝１２３のデフォルトのタスク・テンプレートがデータベース４０から取り出される。
【００８３】
これで「タスク・テンプレート」が見つかった。
【００８４】
タスク・プラン形成
各「タスク・テンプレート」によって、作業タスクのシーケンスが指定される。「ジョー・スミスの交換接続：活動の場合、「タスク・テンプレート」は「Yorktown&Switch2」であり、これはconnectexchangeタスクに対応する。
【００８５】
最新の電話交換局の場合、単一のタスクを発効するだけで十分な場合がある。他のより旧式の交換局では、技術者派遣（dispatchtechnician）、切断（disconnect）、スイッチ２接続（connectswitch2）、および主交換局に対するコールバックなどの１組のタスクが必要な場合がある。
【００８６】
図６に記載のプロセスを、図５の残りの「提供活動」について繰り返し、完成した「タスク・プラン」が基本タスクのシーケンスとして形成される。
【００８７】
補足情報では、タスクによって定義された作業を誰が行うかを指定する。タスク・テンプレートに基づいて、他のデータベース・テーブルでこの情報をさらに探索する。この「作業」は、ローカル交換局で自動的に行うことができることもあり、または技術者が物理的配線を設置し、受話器を備え付ける必要がある場合もある。そのような情報が見つからない場合、デフォルトの情報が使用される。
【００８８】
フィーチャ属性ロッキング
これで「タスク・プラン」が実現されたので、それが実行／提供される。これには、データベース・アクセスと個別の作業アクションが必要である。提供には、タスク・マイルストーンに関係する「属性ロッキング」という概念が含まれる。
【００８９】
属性ロッキングの適用例を例示するために、再び、ジョー・スミスが月曜日にＣＳＲに対してプロダクト・アクション「ジョー・スミスの標準ワイヤライン・アクセスの接続」を要求する例について考えてみる。ジョーは、自分の必要な接続日が次の木曜日であると指定した。これは、図４に示す「スケジューリング・フィーチャ」２０４ｅの構成属性である。この「アクション」が提供のために実行依頼され、「タスク・プラン」が実現した。具体的な作業タスクの１つは、交換局の技術者が適切な回線を接続することである。ジョーが木曜日の朝にＣＳＲに電話をして接続日の延期を要求した場合、そのような遅い段階で変更を行うことができないようにその「フィーチャ」属性を「ロック」しておくことが望ましい。
【００９０】
プロダクト・アクション「標準ワイヤライン・アクセス−接続」について、図７を参照しながら読むように、以下の表にこの順次タスクの一例を示す。
【表５】
図７の「タスク・プラン」は、マイルストーン・タスクに達するまで順次に実行される。マイルストーン・タスクに達した時点で、「プロダクト・アクション」の関係「フィーチャ」について照会を行い、まず、それらが妥当（すなわち顧客情報に関連づけられている）か否かを判断する。妥当でない場合、「タスク・プラン」を進めることができない。遭遇したこの特定のマイルストーンが、ロッキングを行う必要があることを示しているものとしてフィーチャによって保持されているマイルストーンである場合、「フィーチャ・ロック状況フラグ」が真に設定され（図３参照）、マイルストーン・タスクに肯定応答が返され、それによって提供を続行することができる。このフラグが設定されると、その結果として、プロダクト・フィーチャの属性を変更することができなくなり、「ロックされた」状態になる。タスク・マイルストーンがフィーチャによって保持されているマイルストーンと一致しない場合でも、タスク・プランは継続することができ、フィーチャは「ロック解除」状態のままである。
【００９２】
図７には（タスク・プランに加えて）、各プロダクト・フィーチャによって保持されている関係する提供活動マイルストーンが示されている。火曜日に接続するＳＷＡ−Ｃの例の場合、マイルストーン「提供開始」２５４が該当する。すなわち、ＰＳマイルストーンが通過した場合、「スケジューリング・フィーチャ」がそのロック状態フラグを設定し、「顧客要求日付」を変更することができない。
【００９３】
ロッキング・プロセスの他の態様は、ＣＳＲが提供タスクの進捗状況を照会することができ、それによって顧客に「交換接続が今日行われる」と伝えることができる。
【００９４】
「プロダクト定義」および「注文管理」とコンピューティング・システムとの対話
図８、図９は、具体的にクライアント・ワークステーション２０、サーバ３０、およびデータベース４０を参照し、図３を参照しながら前述した、プロダクト定義時点」活動に関する説明を要しない流れ図である。
【００９５】
図１０、図１１、図１２は、具体的にクライアント・ワークステーション２０、サーバ３０、およびデータベース４０を参照し、図４から図７を参照しながら上述した、「注文管理」活動に関する同様の説明を要しない流れ図である。
【００９６】
【発明の効果】
属性ロッキングの利点は、顧客がプロダクトまたはサービスを受ける確約をした後、そのプロダクトまたはサービスを提供するための作業がすべて完了する前に、フィーチャ属性に変更を加えることができることである。たとえば、要求された完了日や（たとえば期限日の前に）割り振られた認識番号に変更を加えることができるようになる。システム管理者は、上述の方式でフィーチャのロックを管理することによって、データの矛盾や請求の誤りを防止することができる。したがって、変更が実施される前に、ＣＳＲおよびその他の利用者に、各フィーチャのメンテナンス可能状況に関する情報を提供することができる。
【００９７】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００９８】
（１）各プロダクトがロッキング・マイルストーンを規定する属性を持つフィーチャを有する、関連のあるメタ・レベル・ドメイン・プロダクトを提供する顧客サービス・コンピューティング・システムのシステム・レベル・ドメイン内に存在する一連の順次タスクを実行する方法であって、
（ａ）前記タスクのうちの１つまたは複数のタスクをマイルストーンとして指定するステップと、
（ｂ）前記順次タスクを実行するステップとを含み、前記各マイルストーン・タスクについて、
（ｉ）関連のある前記プロダクト・フィーチャについて照会を行い、前記タスク・マイルストーンが前記ロッキング・マイルストーンに対応するか否かを判断するステップと、対応する場合には、
（ii）前記実行を続行するステップとを含む方法。
（２）ステップ（ｉ）が真の場合、前記タスク・シーケンスが完了するまで前記フィーチャの属性を変更することができないように前記フィーチャをロック状態にするステップをさらに含む、上記（１）に記載の方法。
（３）ステップ（ｂ）（ｉ）の前に、前提条件として、前記フィーチャが有効であるように前記フィーチャを顧客に関連づける属性を有するか否かを判断するステップをさらに含む、上記（２）に記載の方法。
（４）マイルストーン・タスクが前記メタ・レベル・ドメイン内の前記プロダクト・フィーチャの局面として反映され、前記メタ・レベル・ドメインにおいてマイルストーン状況を規定するステップをさらに含む、上記（３）に記載の方法。
（５）顧客サービス・コンピューティング・システムにおいて品物およびサービスを提供する方法であって、
（ａ）各プロダクトが関連するロッキング・マイルストーンを規定する属性を持つフィーチャを有する、前記品物およびサービスに関係するメタ・レベル・ドメイン内に存在する複数のプロダクト・アクションのうちのいずれか１つに必要な提供を表すシステム・レベル・ドメイン内の１つまたは複数の一連の順次タスクを定義するステップと、
前記各シーケンスについて、
（ｂ）前記タスクのうちの１つまたは複数のタスクをマイルストーンとして指定するステップと、
（ｃ）前記順次タスクを実行するステップとを含み、前記各マイルストーン・タスクについて、
（ｉ）前記プロダクト・フィーチャについて照会を行い、前記タスク・マイルストーンが前記ロッキング・マイルストーンに対応するか否かを判断するステップと、対応する場合には、
（ii）前記実行を続行するステップとを含む方法。
（６）ステップ（ｉ）が真の場合、前記タスク・シーケンスが完了するまで前記プロダクト・フィーチャの属性を変更することができないように前記プロダクト・フィーチャをロック状態にするステップをさらに含む、上記（５）に記載の方法。
（７）ステップ（ｂ）（ｉ）の前に、前提条件として、前記フィーチャが有効であるように前記フィーチャを顧客に関連づける属性を有するか否かを判断するステップをさらに含む、上記（６）に記載の方法。
（８）マイルストーン・タスクが前記メタ・レベル・ドメイン内の前記フィーチャの局面として反映され、前記メタ・レベル・ドメインにおいてマイルストーン状況を定義するステップをさらに含む、上記（７）に記載の方法。
（９）品物およびサービスを提供するコンピューティング・システムであって、各プロダクトが関連するロッキング・マイルストーンを定義する属性を持つフィーチャを有し、前記品物およびサービスに関係するメタ・レベル・ドメイン内に存在する複数のプロダクト・アクションのうちのいずれか１つに必要な提供を表すシステム・レベル・ドメイン内の１つまたは複数の順次タスクを定義し、各シーケンスについて、前記タスクのうちの１つまたは複数のタスクをマイルストーンとして指定し、前記各マイルストーン・について前記プロダクト・フィーチャに関する照会を行って前記タスク・マイルストーンが前記ロッキング・マイルストーンに対応するか否かを判断するように前記シーケンスのタスクを実行するように動作可能なプロセッサ手段を含むコンピューティング・システム。
（１０）前記プロセッサ手段が、前記照会が真の場合に前記タスク・シーケンスの実行が完了するまで前記フィーチャの属性を変更することができないように前記フィーチャをロック状態にするようにさらに動作可能な、上記（９）に記載のシステム。
（１１）前記プロセッサ手段が、前提条件として、前記フィーチャが有効であるように前記フィーチャを顧客に関連づける属性を有するか否かを判断するようにさらに動作可能な、上記（１０）に記載のシステム。
（１２）マイルストーン・タスクが前記メタ・レベル・ドメイン内の前記フィーチャの局面として反映され、前記プロセッサ手段が前記メタ・レベル・ドメインにおいてマイルストーン状況を定義するようにさらに動作可能な、上記（１１）に記載のシステム。
【図面の簡単な説明】
【図１】本発明を実施する３層コンピューティング・システムのトポロジを示す図である。
【図２】「プロダクト」と「タスク」の間のメタ状態マッピングを示す図である。
【図３】「プロダクト」ドメイン内で実行可能なサブシステムを示す図である。
【図４】「プロダクト」定義に関する各状態を示す流れ図である。
【図５】インスタンシエートされた「プロダクト」を示す図である。
【図６】タスク・マッピング・プロセスのオブジェクト相互作用図である。
【図７】属性ロッキングを使用したタスク・プランを示す図である。
【図８】コンピューティング・システム要素を参照しながら新規「プロダクト」定義を説明する流れ図である。
【図９】コンピューティング・システム要素を参照しながら新規「プロダクト」定義を説明する流れ図である。
【図１０】コンピューティング・システム要素を参照しながら「注文管理時点」を説明する流れ図である。
【図１１】コンピューティング・システム要素を参照しながら「注文管理時点」を説明する流れ図である。
【図１２】コンピューティング・システム要素を参照しながら「注文管理時点」を説明する流れ図である。
【符号の説明】
１０ コンピューティング・システム
２０ ワークステーション
２４ 遠隔電話端末
３０ サーバ
４０ データベース
５０ ローカル・エリア・ネットワークまたはワイド・エリア・ネットワーク
６０ 通信リンク
７０ 外部ネットワーク
２５０ マイルストーン
２５６ タスク
Claims (12)
- 各プロダクトが、ロックを行うマイルストーンにより規制される一以上の属性からなるフィーチャを備え、関連のあるメタ・レベル・ドメイン・プロダクトを提供する顧客サービス・コンピューティング・システムのシステム・レベル・ドメイン内に存在する一連のタスクからなる順次タスクを実行する方法であって、
（ａ）前記タスクのうちの１つまたは複数のタスクをユーザの指定によりマイルストーンとしたマイルストーン・タスク及び、１以上の前記タスクにより、タスクプランを生成するステップと、
（ｂ）前記順次タスクを実行するステップと、
を含み、前記マイルストーン・タスクの実行について、
（ｉ）前記マイルストーン・タスクが、所定のフィーチャをロックすべきか否かを判断するために、前記フィーチャのうち関連のあるフィーチャについて照会を行うステップと、
（ii）前記マイルストーン・タスクが、前記順次タスクが完了するまで前記フィーチャの属性を変更することができないように、前記判断にてロックすべきと判断されたフィーチャを、ロック状態にするステップと、
を含む方法。 - 請求項１記載の方法におけるロック状態にするステップは、前記マイルストーン・タスクが複数あることで、複数のフィーチャをロック状態にするステップである方法。
- ステップ（ｂ）（ｉ）の前に、前提条件として、前記フィーチャが有効であるように前記フィーチャを顧客に関連づける属性を有するか否かを判断するステップをさらに含む、請求項１又は２に記載の方法。
- 前記マイルストーン・タスクは、前記メタ・レベル・ドメイン内の前記フィーチャの状態に依存して、前記メタ・レベル・ドメイン内におけるマイルストーンの状況を規定するステップをさらに含む、請求項３に記載の方法。
- 顧客サービス・コンピューティング・システムにおいて品物およびサービスを提供する方法であって、
（ａ）各プロダクトが、ロックを行うマイルストーンにより規制される一以上の属性からなるフィーチャを備え、
前記品物およびサービスに関係するメタ・レベル・ドメイン内に存在する複数のプロダクト・アクションのうちのいずれか１つに必要な提供を表すシステム・レベル・ドメイン内の１つまたは複数の一連のタスクからなる順次タスクを定義するステップと、
前記順次タスクにおいて、
（ｂ）前記タスクのうちの１つまたは複数のタスクをユーザの指定によりマイルストーンとしたマイルストーン・タスク及び、１以上の前記タスクにより、タスクプランを生成するステップと、
（ｃ）前記順次タスクを実行するステップと、
を含み、各々の前記マイルストーン・タスクの実行について、
（ｉ）前記マイルストーン・タスクが、所定のフィーチャをロックすべきか否かを判断するために、前記フィーチャのうち関連のあるフィーチャについて照会を行うステップと、
（ii）前記マイルストーン・タスクが、前記順次タスクが完了するまで前記フィーチャの属性を変更することができないように、前記判断にてロックすべきと判断されたフィーチャを、ロック状態にするステップと、
を含む方法。 - 請求項１記載の方法におけるロック状態にするステップは、前記マイルストーン・タスクが複数あることで、複数のフィーチャをロック状態にするステップである方法。
- ステップ（ｂ）（ｉ）の前に、前提条件として、前記フィーチャが有効であるように前記フィーチャを顧客に関連づける属性を有するか否かを判断するステップをさらに含む、請求項５又は６に記載の方法。
- 前記マイルストーン・タスクは、前記メタ・レベル・ドメイン内の前記フィーチャの状態に依存して、前記メタ・レベル・ドメイン内におけるマイルストーンの状況を規定するステップをさらに含む、請求項７に記載の方法。
- 品物およびサービスを提供するコンピューティング・システムであって、
各プロダクトが、ロックを行うマイルストーンにより規制される一以上の属性からなるフィーチャを備え、
前記品物およびサービスに関係するメタ・レベル・ドメイン内に存在する複数のプロダクト・アクションのうちのいずれか１つに必要な提供を表すシステム・レベル・ドメイン内の１つまたは複数の一連のタスクからなる順次タスクを定義する処理と、
前記順次タスクについて、前記タスクのうちの１つまたは複数のタスクをユーザの指定によりマイルストーンとしたマイルストーン・タスク及び、１以上の前記タスクにより、タスクプランを生成する処理と、
前記順次タスクを実行する処理と、
を含み、各々の前記マイルストーン・タスクの実行について、
前記マイルストーン・タスクが、所定のフィーチャをロックすべきか否かを判断するために、前記フィーチャのうち関連のあるフィーチャについて照会を行う処理と、
前記マイルストーン・タスクが、前記順次タスクが完了するまで前記フィーチャの属性を変更することができないように、前記判断にてロックすべきと判断されたフィーチャを、ロック状態にする処理と、
を含む処理を行うコンピューティング・システム。 - 請求項９記載のシステムにおけるロック状態にする処理は、前記マイルストーン・タスクが複数あることで、複数のフィーチャをロック状態にする処理であるシステム。
- 前記コンピューティング・システムが、前提条件として、前記フィーチャが有効であるように前記フィーチャを顧客に関連づける属性を有するか否かを判断する処理をさらに行う、請求項９又は１０に記載のシステム。
- 前記マイルストーン・タスクは、前記メタ・レベル・ドメイン内の前記フィーチャの状態に依存して、前記メタ・レベル・ドメイン内におけるマイルストーンの状況を定義する処理をさらに行う、請求項１１に記載のシステム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000050686A JP3731860B2 (ja) | 2000-02-28 | 2000-02-28 | 顧客サービス処理システム内のタスクの順序付け |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000050686A JP3731860B2 (ja) | 2000-02-28 | 2000-02-28 | 顧客サービス処理システム内のタスクの順序付け |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001243081A JP2001243081A (ja) | 2001-09-07 |
| JP3731860B2 true JP3731860B2 (ja) | 2006-01-05 |
Family
ID=18572445
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000050686A Expired - Fee Related JP3731860B2 (ja) | 2000-02-28 | 2000-02-28 | 顧客サービス処理システム内のタスクの順序付け |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3731860B2 (ja) |
-
2000
- 2000-02-28 JP JP2000050686A patent/JP3731860B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001243081A (ja) | 2001-09-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6898790B1 (en) | Mapping actions to tasks within customer service processing systems | |
| US6067548A (en) | Dynamic organization model and management computing system and method therefor | |
| US20040083426A1 (en) | System and method for generating pre-populated forms | |
| US6604113B1 (en) | Method and apparatus for providing account information | |
| US6298352B1 (en) | Apparatus and method for managing number sources | |
| US6493742B1 (en) | System and method for providing internet accessible registries | |
| US6724875B1 (en) | Flexible network platform and call processing system | |
| US7882209B1 (en) | Tiered and modular approach to operational support systems | |
| US9864788B2 (en) | Method and system for cascading a middleware to a data orchestration engine | |
| US7844912B2 (en) | System and method using transformation nodes with enhancement layers | |
| US7987287B2 (en) | Method and system for routing data repository messages between computing devices | |
| US6678370B1 (en) | Data extraction process | |
| JP2000115359A (ja) | インテリジェント・ネットワ―ク環境におけるｎｐａ分割管理 | |
| US6556996B1 (en) | Service package application and a service activation manager for use with a service control point in an advanced intelligent network | |
| JP2002259643A (ja) | ビジネスプロセス制御プログラム | |
| US6996771B1 (en) | Dynamic parameter modification | |
| TW476898B (en) | A human resource management service system | |
| US7406471B1 (en) | Scalable multi-database event processing system using universal subscriber-specific data and universal global data | |
| JP3731860B2 (ja) | 顧客サービス処理システム内のタスクの順序付け | |
| US6795537B1 (en) | Method for updating a database using a telephone | |
| US6973652B1 (en) | Sequencing of tasks within customer service processing systems | |
| WO2001086495A1 (en) | Centralized management of a distributed database system | |
| US20040003065A1 (en) | Communication resource system | |
| JP4361170B2 (ja) | 画面表示制御装置および方法ならびに画面表示制御のためのプログラムを記録した媒体 | |
| CN107608690B (zh) | 配置管理的方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040127 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040322 |
|
| RD12 | Notification of acceptance of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7432 Effective date: 20040322 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20040322 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20040914 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041104 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041130 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20041203 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050502 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050726 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050927 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20050927 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20051007 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |