(57)【要約】      （修正有）【課題】  受託者と委託者が締結したSLAに受託業務の制御権限を規定し、権限の範囲内で受託業務を受託者の判断で制御する手段を提供するとともに、制御権限などのSLAを継続的に改善可能なアウトソーシングシステムの運用手段を提供する。【解決手段】  業務サービスをアウトソーシングする際に、業務サービスの機能、性能、信頼性、課金等に関わる合意契約を結ぶ。受託企業が受託業務を実行する業務システムの稼動情報を収集・蓄積し、この稼動情報をSLAとビジネスルールにもとづいて診断する。診断の結果、業務システムを制御する必要あると判断した場合には、診断結果に従って当該業務システムを制御する。さらに、業務システムの稼動情報を用いて、SLAに規定される業務システムの制御権限の修正案を立案し、委託者と受託者のトータル利益を最大化する観点からSLAの修正案を評価する。トータル利益が改善されると判断した場合にはSLAを修正する。【選択図】図１
2007042011.tif 000002
【特許請求の範囲】
【請求項１】
業務システムの管理装置であって、
業務システムの稼動情報を収集・蓄積する手段と、
業務システムが提供するサービスの委託者と受託者の間で契約した業務システムの機能・性能・信頼性の品質に関する合意事項（ＳＬＡ:Service Level Agreement）および当該ＳＬＡで規定される業務システムの制御権限、業務システムの稼動状況、業務システムの制御規則（ビジネスルール）にもとづいて、業務システムの稼動情報を診断する手段と、
診断結果にもとづいて業務システムを制御する手段と
を有することを特徴とする業務システムの管理装置。
【請求項２】
業務システムの管理装置であって、
業務システムが提供するサービスの委託者と受託者の間で契約した業務システムの機能・性能・信頼性の品質に関する合意事項（ＳＬＡ:Service Level Agreement）の修正案を生成する手段と、
業務システムの運用履歴にもとづいてＳＬＡの修正案を評価する手段と、
ＳＬＡの修正案を業務システムが提供するサービスの委託者および受託者の端末装置に表示する手段と、
端末装置を介して委託者および受託者からの要求入力を受け付ける手段と、
要求内容を相手側の端末装置に表示する手段と
を有することを特徴とする業務システムの管理装置。
【請求項３】
複数の事業者または複数の拠点で管理する商品の在庫を統合管理し、販売業務を支援する管理装置において、
商品の販売状況を監視する手段と、
販売状況とあらかじめ設定された業務システムの制御規則（ビジネスルール）にもとづいて、商品の在庫を特定の事業者または販売チャネルが優先または独占販売できる在庫と、それ以外の在庫に分割する手段と
を有することを特徴とする管理装置。
【請求項４】
複数の事業者または複数の拠点で管理する商品の在庫を統合管理し、販売業務を支援する管理装置であって、
商品の販売状況を監視する手段と、
販売状況とあらかじめ設定されたビジネスルールにもとづいて、商品の在庫を特定の事業者または販売チャネルが優先または独占販売できる在庫と、それ以外の在庫に分割する手段と、これらの在庫属性とビジネスルールにもとづいて販売価格を設定する手段とを
有することを特徴とする管理装置。
【請求項５】
業務システムの管理装置としてコンピュータを機能させるコンピュータプログラムであって、
業務システムの稼動情報を収集・蓄積する手段と、
業務システムが提供するサービスの委託者と受託者の間で契約した業務システムの機能・性能・信頼性の品質に関する合意事項（ＳＬＡ:Service Level Agreement）および当該ＳＬＡで規定される業務システムの制御権限、業務システムの稼動状況、業務システムの制御規則（ビジネスルール）にもとづいて、業務システムの稼動情報を診断する手段と、
診断結果にもとづいて業務システムを制御する手段として、
前記コンピュータを機能させることを特徴とするコンピュータプログラム。
【請求項６】
業務システムの管理装置としてコンピュータを機能させるコンピュータプログラムであって、
業務システムが提供するサービスの委託者と受託者の間で契約した業務システムの機能・性能・信頼性の品質に関する合意事項（ＳＬＡ:Service Level Agreement）の修正案を生成する手段と、
業務システムの運用履歴にもとづいてＳＬＡの修正案を評価する手段と、
ＳＬＡの修正案を業務システムが提供するサービスの委託者および受託者の端末装置に表示する手段と、
端末装置を介して委託者および受託者からの要求入力を受け付ける手段と、
要求内容を相手側の端末装置に表示する手段として、
前記コンピュータを機能させることを特徴とするコンピュータプログラム。
【請求項７】
複数の事業者または複数の拠点で管理する商品の在庫を統合管理し、販売業務を支援する管理装置としてコンピュータを機能させるコンピュータプログラムであって、
商品の販売状況を監視する手段と、
販売状況とあらかじめ設定された業務システムの制御規則（ビジネスルール）にもとづいて、商品の在庫を特定の事業者または販売チャネルが優先または独占販売できる在庫と、それ以外の在庫に分割する手段として、
前記コンピュータを機能させることを特徴とするコンピュータプログラム。
【請求項８】
複数の事業者または複数の拠点で管理する商品の在庫を統合管理し、販売業務を支援する管理装置としてコンピュータを機能させるコンピュータプログラムであって、
商品の販売状況を監視する手段と、
販売状況とあらかじめ設定されたビジネスルールにもとづいて、商品の在庫を特定の事業者または販売チャネルが優先または独占販売できる在庫と、それ以外の在庫に分割する手段と、これらの在庫属性とビジネスルールにもとづいて販売価格を設定する手段として、
前記コンピュータを機能させることを特徴とするコンピュータプログラム。
【請求項９】
業務システムの管理装置の管理方法であって、
業務システムの稼動情報を収集・蓄積するステップと、
業務システムが提供するサービスの委託者と受託者の間で契約した業務システムの機能・性能・信頼性の品質に関する合意事項（ＳＬＡ:Service Level Agreement）および当該ＳＬＡで規定される業務システムの制御権限、業務システムの稼動状況、業務システムの制御規則（ビジネスルール）にもとづいて、業務システムの稼動情報を診断するステップと、
診断結果にもとづいて業務システムを制御するステップと
を有することを特徴とする管理装置の管理方法。
【請求項１０】
業務システムを運用管理するシステムであって、
業務システムが提供するサービスの委託者と受託者の間で契約した業務システムの機能・性能・信頼性の品質に関する合意事項（ＳＬＡ:Service Level Agreement）の修正案を生成するステップと、
業務システムの運用履歴にもとづいてＳＬＡの修正案を評価するステップと、
ＳＬＡの修正案を業務サービスの委託者および受託者に提案表示するステップと、
提案内容に対して委託者と受託者の合意を確認するステップと
を有することを特徴とする業務システムのサービスレベル管理方法。
【請求項１１】
複数の事業者または複数の拠点で管理する商品の在庫を統合管理し、販売業務を支援する管理装置の管理方法であって、
商品の販売状況を監視するステップと、
販売状況とあらかじめ設定されたビジネスルールにもとづいて、商品の在庫を特定の事業者または販売チャネルが優先または独占販売できる在庫と、それ以外の在庫に分割するステップと
を有することを特徴とする管理装置の管理方法。
【請求項１２】
複数の事業者または複数の拠点で管理する商品の在庫を統合管理し、販売業務を支援する管理装置の管理方法であって、
商品の販売状況を監視するステップと、販売状況とあらかじめ設定されたビジネスルールにもとづいて、商品の在庫を特定の事業者または販売チャネルが優先または独占販売できる在庫と、それ以外の在庫に分割し、これらの在庫属性とビジネスルールにもとづいて販売価格を設定するステップを有することを特徴とする管理装置の管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、業務システムの稼動状況を監視し、監視結果を診断し、診断結果にもとづいて業務システムを制御する技術に関する。
【背景技術】
【０００２】
近年、企業経営においては自社の強みとなる業務サービスを活用して他社業務を受託する、あるいは、自社業務の非コア部分を他社に業務委託するといったアウトソーシングが拡大しており、今後、アウトソーシングは、非コア業務だけでなく、予約・販売業務などのコア周辺業務まで拡大すると予想される。このような背景のもと、ＳＬＡ（Service Level Agreement）を経営的な視点から適切に設定し、ビジネス環境変化やＳＬＡの充足状況に対して柔軟性・即応性の高い業務システムが求められている。
【０００３】
システムの稼動状況を経営的な視点で監視し、状況に応じたシステム制御を行う方法としては、特許文献１の「業務サービス管理システムおよびサービスプロバイダの評価方法」が公知である。本公知例では、旧来からのＳＬＡにおける監視項目であった実行時間などＯＳで取得可能な情報だけでなく、業務システムから取得可能な経営指標を監視することにより、ビジネス的な問題点を把握する方法について示している。
【０００４】
【特許文献１】特開２００５−１１０５３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従来、経営の視点で業務システムを監視し、業務システムに組み込まれた経営を左右するパラメータの制御を行う場合には、委託企業の経営判断にもとづく制御実施の承認が必要であった。しかしながら予約・販売業務など、日々刻々とビジネス環境が変化する業務を外部企業に委託する場合には、従来からのアウトソーシングで用いられてきたＳＬＡの枠組みでは状況変化に迅速に即応することは難しい。本発明の目的は、受託者と委託者が締結したＳＬＡに受託業務の制御権限を規定し、権限の範囲内で受託業務を受託者の判断で制御する技術を提供するとともに、制御権限などのＳＬＡを継続的に改善可能なアウトソーシングシステムの運用管理技術を提供することにある。
【課題を解決するための手段】
【０００６】
本発明の業務システムの管理装置は、業務サービスをアウトソーシングする際に委託者と受託者間で締結された、業務サービスの機能、性能、信頼性、課金等に関わる合意契約（ＳＬＡ）をとともに、業務システムの制御権限についても管理する。また、業務システムの稼動状況に応じた業務システムの制御規則（ビジネスルール）も管理する。
【０００７】
また、前記サービスレベル管理装置は、受託企業が受託業務を実行する業務システムの稼動情報を収集・蓄積し、この稼動情報をＳＬＡとビジネスルールにもとづいて診断する。診断の結果、業務システムを制御する必要あると判断した場合には、診断結果に従って当該業務システムを制御する。
【０００８】
さらに、前記サービスレベル管理装置は、業務システムの稼動情報を用いて、ＳＬＡに規定されている業務システムの制御権限の修正案を生成し、委託者と受託者のトータル利益を最大化する観点からＳＬＡの修正案を評価する。ここで、トータル利益が改善されると判断した場合には、委託者と受託者の合意を受け付けた後、ＳＬＡを修正する。
【発明の効果】
【０００９】
システムの稼動状況を経営的な視点で監視し、ビジネス状況に応じて迅速にシステム制御を行うことが可能となる、また、アウトソーシングの委託企業と受託企業が合意しつつ効率的にＳＬＡを改善することにより、協業関係の維持・発展に寄与することができる。
【発明を実施するための最良の形態】
【００１０】
以下、図１〜図１２を用いて、企業Ｃが、相互乗り入れのある輸送業Ａ社、輸送業Ｂ社の輸送機関の座席予約業務（例えば、鉄道の座席予約業務）を一括してアウトソーシング受託する場合を例に、本発明の一実施形態を説明する。
【００１１】
図１は、業務システム300と、業務システム300を運用管理するアウトソーシング運用管理システム100の全体構成である。
【００１２】
業務システム300は、輸送業Ａ社、輸送業Ｂ社の座席予約販売業務をＣ社が受託してなすものである。アウトソーシング運用管理システム100は、Ｃ社が業務システム300を運用管理するためのものである。
【００１３】
アウトソーシング運用管理システム100は、業務システム300の業務状態を監視する監視部110と、監視結果をＳＬＡ（Service Level Agreement）170とビジネスルール150にもとづいて診断する診断部120と、診断結果にもとづいて、業務システムの制御を行う制御部130と、監視部110を介して収集した業務システムの稼動情報を蓄積する運用履歴140と、予約業務の状況に応じた業務システムの制御ルールを格納するビジネスルール150と、ＳＬＡ修正案を立案し、ＳＬＡ修正案を評価するＳＬＡ評価部160と、受託企業と委託企業の提携契約を含むＳＬＡ170と、ＳＬＡの修正案を関係各社に提案するとともに、各社の入力装置850からの入力内容を受け付ける合意形成支援部180と、を備えている。
【００１４】
図２は、業務システム300の構成である。業務システム300は、輸送業Ａ社またはＢ社の販売システム800からの予約要求を処理する予約管理部320と、予約状況が格納される予約管理ＤＢ（データベース）310と、外部からの要求により在庫管理処理を行う在庫管理部340と、輸送業Ａ社及びＢ社の座席在庫を管理する在庫管理ＤＢ330と、商品販売価格の調整などの収益管理業務を行う収益管理部360と、座席在庫の販売価格を管理する価格管理ＤＢ350と、Ａ社とＢ社の直販率を格納する直販率格納部380とを備えている。業務システム300は、通信制御部370を介して、輸送業Ａ社が運用する販売システム及び輸送業Ｂ社が運用する販売システム800と、先に説明した受託Ｃ社が運用するアウトソーシング運用管理システム100と接続する。
【００１５】
なお、販売システム800は、駅や旅行会社の「予約・販売窓口」に設置された端末装置に入力された入力内容を受信し、受信した内容を、業務システム300に送るための装置（販売チャネル）である。
【００１６】
上記のアウトソーシング運用管理システム100、業務システム300、Ａ社及びＢ社の販売システム800、各社に置かれる入力装置端末850は、いずれも例えば汎用的なコンピュータシステムにより構成され、システム内の構成要素又は機能は、例えば、ＣＰＵ（中央演算装置）がメモリにロードされたコンピュータプログラムを実行することにより実現される。
【００１７】
次に、業務システム300の処理概要について説明する。
【００１８】
図３は、業務システム300の基本処理フローである。
【００１９】
ステップ1001において、業務システム300の予約管理部320は、輸送業Ａ社またはＢ社の販売システム800から座席の予約要求を受け付ける。販売システム800から送信される予約要求には、予約する列車の識別コード（後述の列車ＩＤ）、利用区間、予約を受け付けた「予約・販売窓口」等に関する情報が含まれている。
【００２０】
次に、ステップ1002において、在庫管理部340は、在庫管理ＤＢ330を参照して、当該要求に対応する在庫があるかどうか判断する。
【００２１】
この在庫の確認の方法について具体的に説明する。図４は、在庫管理ＤＢ330の構成である。在庫管理ＤＢ330には、列車ＩＤ311毎、運行区間（利用区間）332毎、チケット分類333毎に、在庫数334が格納されている。チケット分類333には、Ａ社だけが販売可能な定額のチケット（Ａ社直販定額チケット）、Ｂ社だけが販売可能な定額のチケット（Ｂ社直販定額チケット）、Ａ社だけが販売可能な割引チケット（Ａ社直販割引チケット）、Ｂ社だけが販売可能な割引チケット（Ｂ社直販割引チケット）、Ａ社及びＢ社が共に販売可能な定額のチケット（Ａ社Ｂ社共有定額チケット）がある。そして、それぞれのチケット分類333について、在庫数334（Ａ社直販定額在庫数、Ｂ社直販定額在庫数、Ａ社直販割引在庫数、Ｂ社直販割引在庫数、Ａ社Ｂ社共有定額在庫数）が格納されている。また、在庫管理部340は、各「予約・販売窓口」が取り扱うチケット分類を特定するためのテーブルを保持している。
【００２２】
まず、在庫管理部340は、予約要求の中の「列車ＩＤ」、「利用区間」に対応するチケット分類333毎の在庫数334を取得する。次に、在庫管理部340は、予約要求の中の「予約・販売窓口」を参照して、その「予約・販売窓口」が、どのチケット分類を取り扱う窓口かを特定する。そして、「予約・販売窓口」が取り扱うチケット分類の在庫数334が１以上の場合、在庫があると判定する。
【００２３】
具体的には、「予約・販売窓口」が「Ａ社直販定額チケットの取扱窓口」である場合で、Ａ社直販定額チケットの在庫数が１以上の場合、在庫があると判定する。一方、Ａ社直販定額のチケットの在庫数が０の場合でも、Ａ社Ｂ社共有定額チケットの在庫数が１以上の場合、在庫があると判定する。また、「予約・販売窓口」が「Ｂ社直販定額チケットの取扱窓口」である場合で、Ｂ社直販定額チケットの在庫数が１以上の場合、在庫があると判定する。一方、Ｂ社直販チケットの在庫数が０の場合でも、Ａ社Ｂ社共有定額チケットの在庫数が１以上の場合、在庫があると判定する。また、「予約・販売窓口」が「Ａ社Ｂ社共有定額チケットの取扱窓口」の場合で、Ａ社直販定額チケット、Ｂ社直販定額チケット、Ａ社Ｂ社共有定額チケットのいずれかの在庫数が１以上の場合は、在庫があると判定する。「予約・販売窓口」が割引チケットの取扱窓口である場合も同様である。
【００２４】
ここで、在庫確保ができない場合には、在庫管理部340は、ステップ1006にて、当該販売システム800に対して予約拒否の通知を行う。
【００２５】
一方、在庫確保ができた場合には、予約管理部340は、ステップ1003にて、当該予約要求に予約ＩＤを付した後、予約管理ＤＢ310に登録し更新する。
【００２６】
図５は、予約管理ＤＢ310の構成である。予約管理ＤＢ310には、列車ＩＤ311毎かつ予約ＩＤ312毎に、顧客ＩＤ313、チケット分類314、運行区間（利用区間）315、座席ＩＤ316、予約・販売窓口317などの情報が格納される。チケット分類314は、ステップ1002で確保した在庫の属するチケット分類333である。
【００２７】
次に、ステップ1004において、在庫管理部340は、登録した予約に対応する在庫管理ＤＢ330の在庫数334から１を引き更新する。具体的には、Ａ社直販定額チケットの在庫があることにより在庫ありと判定した場合には、Ａ社直販定額チケットの在庫数から１を引く。また、Ｂ社直販定額チケットの在庫があることにより在庫ありと判定した場合には、Ｂ社直販定額チケットの在庫数から１を引く。また、Ａ社Ｂ社共有定額チケットの在庫があることにより在庫ありと判定した場合には、Ａ社Ｂ社共有定額チケットの在庫数から１を引く。割引チケットの在庫により在庫ありと判定した場合も同様に、対応する割引チケットの在庫数から１を引く。
【００２８】
次に、ステップ1005において、在庫管理部340は、価格管理ＤＢ350を参照して、登録した予約に対応するチケットの価格を求める。そして、販売システム800に対して、求めた価格を送信して、予約完了を通知する。
【００２９】
図６は、価格管理ＤＢ350の構成である。価格管理ＤＢ350には、列車ＩＤ351毎、運行区間352毎、チケット分類毎に、販売価格354が格納されている。在庫管理部340は、予約要求された列車ＩＤ及び区間に対応し、かつチケット分類に対応する価格353を特定する。なお、販売価格354は、後述するように、収益管理部360により、アウトソーシング運用管理システム100からの要求に基づいて変更される。
【００３０】
次に、アウトソーシング運用管理システム100の処理概要について説明する。
【００３１】
アウトソーシング運用管理システム100は、ビジネスルール150にもとづいて業務システム300を改善する業務システム改善機能と、複数の経営主体の合意形成を支援しつつ、ＳＬＡを継続的に評価・修正するＳＬＡ改善支援機能を有する。
【００３２】
まず、業務システム改善機能について説明する。業務システムの改善機能は、監視部110、診断部120、制御部130によって構成される。
【００３３】
まず、監視部110の処理概要を説明する。
【００３４】
監視部110は、監視対象の業務システム300の稼動状況を収集し、これをもとに予め設定された重要経営指標ＫＰＩ（Key Performance indicator）の各指標値を算出し、これを運用履歴140として蓄積する。また、現在のＫＰＩ値、またはＫＰＩ値の推移と、ＫＰＩ毎にあらかじめ設定された閾値を超える、あるいは条件満たす状態を検出した場合には、診断部120に対して問題となったＫＰＩ情報とともに診断要求メッセージを送信する。なお、本実施例では、監視部120は予め設定された時間間隔で定期的に起動されるものとする。
【００３５】
図7は、かかる監視部110の処理フローである。ここでは、監視処理を、監視部110の処理フロー2000と、監視対象となる業務システム300の処理フロー3000に分けて説明する。
【００３６】
まず、監視部110は、ステップ2001にて、予め定義された監視対象ＫＰＩ項目にもとづいて、業務システム300に対しＫＰＩ値を算出するために必要な稼働情報の収集要求を送信する。以下では、チケット分類毎の各運行区間の予約状況（予約数と在庫数）がＫＰＩの項目として設定されている場合の例を説明する。
【００３７】
ステップ3001において、業務システム300は、監視部110からの要求を受信する。そして、ステップ3002にて、必要な情報（例えば、特定の列車ＩＤにかかる予約管理ＤＢ310及び在庫管理ＤＢ330の格納情報）の収集を行ない、ステップ3003にて、収集した情報を監視部110に送信する。
【００３８】
ステップ2002において、監視部110は、ＫＰＩ値の元となる情報を受信する。そして、ステップ2003において、個々のＫＰＩ値を算出し、ステップ2004において、ＫＰＩ値を運用履歴140として登録する。図８は、予約管理ＤＢ310及び在庫管理ＤＢ330の格納情報をもとに、列車ＩＤ141毎、運行区間143毎、チケット分類142毎に、ＫＰＩ値（予約数と在庫数）145を求めた場合の運用履歴140を示す。なお、予約数は、予約管理ＤＢ310中の、列車ＩＤ311、運行区間315及びチケット分類314が同一の予約の数から求められる。
【００３９】
次に、ステップ2005にて、監視部110は、運用履歴140とＫＰＩ値毎にあらかじめ設定された閾値や判定条件を照合することにより、運用状況の問題箇所の有無を判定する。図８の例では、チケット分類143毎のＫＰＩ値が所定の閾値や判定条件を満たした場合、そのＫＰＩ値を与えた運用状況（そのＫＰＩ値が導かれることとなった列車ＩＤ141の運行区間143のチケット分類142）を問題箇所とする。  
そして、問題箇所があった場合、ステップ2006にて、監視部110は、問題箇所とともに診断部130に診断要求を送信する。一方、診断が不要と判断された場合には処理を終了する。
【００４０】
次に診断部130の処理概要を説明する。
【００４１】
診断部130は、監視部110から送られた診断要求メッセージを受信すると、ＳＬＡ170とビジネスルール150にもとづいて、業務システム300の制御要否を判断し、制御が必要と判断した場合には、制御部130に対して制御要求メッセージを送信する。
【００４２】
図9は、かかる診断部120の処理フローである。まず、診断部120は、ステップ4001にて診断要求メッセージを受信し、ステップ4002でＳＬＡ170及びビジネスルール150をそれぞれローカルメモリに保持する。
【００４３】
図１０は、ビジネスルール150の構成である。ビジネスルール150は、ルールＩＤ151によって管理され、個々のビジネスルール152は、条件とその条件を満たす場合の制御内容とがIF-THEN形式で定義されている。
【００４４】
図１１は、ＳＬＡ170の構成例である。ＳＬＡ170は、提携する業務171毎に、規約172を格納している。業務171は、例えば、在庫管理業務、座席割業務、収益管理業務などである。規約172は、例えば、サービスレベル規約173、課金規則174、業務内容を制御する権限（権限委譲規約）175などである。
【００４５】
また、本実施形態では、ＳＬＡ170の中に、委託業務に対して本来は委託側が持つ制御権限を受託側に委譲する内容173についても規定している。図１１の例では、権限委譲規約の中には、各社の直販率の初期値とともに、Ｃ社の判断で制御可能な上限値と下限値が格納されている。すなわち、この情報を参照すれば、本来は委託Ａ社が持つＡ社の直販率を、上限値と下限値の範囲で、受託Ｃ社の判断で制御可能であることが分かる。
【００４６】
図９に戻って説明を続ける。ステップ4003において、診断部130は、診断要求に含まれている問題箇所について、ビジネスルール150およびＳＬＡ170を照合させる。
【００４７】
診断部120は、照合の結果、条件に合致するビジネスルール150が存在しなかった場合には、制御不要と判断して処理を終了する。一方、条件に合致するビジネスルール150が存在する場合には、制御が必要と判断し、ステップ4005にて制御部130に当該ビジネスルール150を含む制御要求メッセージを送信する。
【００４８】
具体的に説明する。例えば、図１０に示すような、ビジネスルール150があったとする。すなわち、このビジネスルールの適用の条件は、区間の運行会社がＡ社であり、平日であり、チケット分類が定額チケットであり、予約率が７０％を超え、Ａ社占有率が６０％未満であり、かつ、Ａ社直販率を１０％上方修正可能であることである。そして、この条件を満たした場合の制御内容は、Ａ社が運行区間の、平日の、定額チケットのＡ社直販率を１０％情報修正するというものである。かかるビジネスルールに対して、診断部120は、ＫＰＩ値により特定された問題箇所が各条件を満たすか否か判定する。
【００４９】
なお、診断部120は、区間ごとの運行会社を特定するための情報を予め保持しており、この情報を用いて、区間の運行会社を特定する。また、診断部120は、列車ＩＤで特定される列車の運行日時を特定するための情報を予め保持しており、この情報を用いて、列車ＩＤで特定される列車の運行日時を特定する。
【００５０】
また、予約率は、式：（予約率）＝（予約数）／｛（予約数）＋（在庫数）｝により求められる。また、占有率は、同一列車の同一運行区間の同一価格帯の各社の予約の占有率である。例えば、図８の運用履歴140において、列車ＩＤ「0001」、運行区間「駅１〜駅２」、チケット分類「直販定額」のＡ社占有率は、
（占有率）＝（Ａ社直販定額の予約数）／｛（Ａ社直販定額の予約数）＋（Ｂ社直販定額の予約数）｝  により求められる。
【００５１】
また、チケット分類「直販割引」のＡ社占有率は、
（占有率）＝（Ａ社直販割引の予約数）／｛（Ａ社直販割引の予約数）＋（Ｂ社直販割引の予約数）｝  により求められる。
【００５２】
Ａ社の直販率を１０％上方修正可能か否かは、ＳＬＡ170のＡ社直販率制御の上限値から判定できる。すなわち、診断部120は、直販率格納部380に格納されている現在の直販率を取得し、現在の直販率を１０％上方修正した場合に、ＳＬＡ170のＡ社直販率制御の上限値を超えないか否か判定し、超えない場合、修正可能と判定する。一方、超える場合は、修正不可と判定する。
【００５３】
診断部120は、問題箇所がビジネスルールの条件に合致した場合、そのビジネスルールの制御内容を制御部130に送信する。
【００５４】
これを受けて、制御部130は、制御要求メッセージを業務システム300に送信する。
【００５５】
業務システムの在庫管理部340は、制御要求メッセージを受信すると、メッセージに含まれる制御内容にもとづいて、直販率格納部380の直販率を変更する。具体的には、図１０で示したビジネスルールが適用される場合は、平日に運行される列車ＩＤのＡ社運行区間の定額チケットのＡ社直販率を１０％上方修正する。例えば、現在の直販率が50％の場合、60％に修正する。
【００５６】
さらに、在庫管理部340は、在庫管理ＤＢ330の在庫数334を、新たに設定した直販率に従って設定し直す。具体的には、例えば、まず、直販定額チケットに関する全在庫数を、
式：（全在庫数）＝（現在のＡ社直販定額チケットの在庫数）＋（現在のＢ社直販定額チケットの在庫数）＋（Ａ社Ｂ社共有定額チケットの在庫数）により求める。つぎに、Ａ社とＢ社の直販定額チケットの在庫数を、式：
（新たなＡ社直販定額チケットの在庫数）＝（全在庫数）×（Ａ社直販率）、
（新たなＢ社直販定額チケットの在庫数）＝（全在庫数）×（Ｂ社直販率）により求める。
【００５７】
また、Ａ社Ｂ社共有定額チケットの在庫数を、
式：（Ａ社Ｂ社共有定額チケットの在庫数）＝（全在庫数）−（新たなＡ社直販定額チケットの在庫数）−（新たなＢ社直販定額チケットの在庫数）により求める。
【００５８】
なお、制御メッセージに、チケットの販売価格を変動させる内容が含まれている場合には、収益管理部360は、その制御内容に従って、価格管理ＤＢ350の列車ＩＤ351、運行区間352、チケット分類353毎の販売価格354を設定し直す。例えば、図１０に示すように、チケットの販売価格を変動させるビジネスルール153があるとする。このビジネスルールが適用され、制御メッセージにチケットの割引率を変動させる内容が含まれている場合には、収益管理部360は、その制御内容に従って、価格管理ＤＢ350の列車ＩＤ351、運行区間352、チケット分類353毎の販売価格354（割引チケットの価格）を設定し直す。
【００５９】
次に、ＳＬＡ改善支援機能について説明する。ＳＬＡ改善支援機能は、ＳＬＡ評価部160と合意形成支援部180によって構成される。
【００６０】
図１２は、ＳＬＡ改善支援機能の処理フローである。まず、合意形成支援部180は、ステップ5001において、委託企業と受託企業の入力装置850から、ＳＬＡ項目の中の改善すべき項目の選択を受け付ける。
【００６１】
以下では、平日、定額チケットのＡ社直販率の制御権限が改善対象として選択されたことを想定して説明する。
【００６２】
合意形成支援部180は、ステップ5002にて、現在の直販率の制御権限を規定するパラメータ（図１１における上限、または下限、またはその両方）をあらかじめ定められた値だけ調整したＳＬＡ修正案を作成する。
【００６３】
次に、ＳＬＡ評価部160は、ステップ5003にて、一定期間の運用履歴に対して、ＳＬＡ修正案を用いてシミュレーションし、新たに要求される制御内容を導く。具体的には、まず、上記ステップ2005と同様に、監視部110に一定期間の運用履歴に対する問題箇所を抽出させる。続いて、上記ステップ4003と同様に、診断部120に、抽出した問題箇所に対して、ＳＬＡ修正案を用いて、ビジネスルールの適用を試みて、制御内容を導き出させる。
【００６４】
次に、ＳＬＡ評価部160は、ステップ5004にて、新たに制御内容が導き出されたか否か判定する。ここで、新たな制御内容が存在しない場合には、ステップ5002に戻る。一方、新たな制御内容が存在する場合には、合意形成支援部180は、ステップ5005にて、Ａ社入出力装置及びＢ社入出力装置850に対してＳＬＡ修正案、新たな制御内容、新たな制御内容を導出するに用いられたビジネスルールを提示する。
【００６５】
次に、合意形成支援部180は、ステップ5006において、提示したＳＬＡ修正案に対して合意したか否か判定する。ここで、当該ＳＬＡに関係する会社（Ａ社及びＢ社）がすべて提案に合意した場合には、合意形成支援部180は、ステップ5007にて、修正案を新しいＳＬＡとして登録する。
【００６６】
以上、本発明の一実施形態について説明した。
【００６７】
上記実施形態によれば、受託者と委託者が締結したＳＬＡに受託業務の制御権限を規定し、権限の範囲内で受託業務を受託者の判断で制御する技術を提供するとともに、制御権限などのＳＬＡを継続的に改善可能となる。
【００６８】
なお、本発明は、上記実施形態に制限されない。上記実施形態は、本発明の技術的思想の範囲において様々な変形が可能である。
【００６９】
また、本発明で示したシステム運用管理方法は，アウトソーシング受託業務をITシステムで運用する際の、システム監視、運用、制御を行うソフトウェアとして利用可能である。
【図面の簡単な説明】
【００７０】
【図１】アウトソーシング運用管理システムの全体構成である。
【図２】業務システムの構成である。
【図３】業務システムの基本処理フローである。
【図４】在庫管理DBの構成である。
【図５】予約管理DBの構成である。
【図６】価格管理DBの構成である。
【図７】監視部の処理フローである。
【図８】運用履歴の構成である。
【図９】診断部の処理フローである。
【図１０】SLAの構成である。
【図１１】ビジネスルールの構成である。
【図１２】SLA評価部の処理フローである。
【符号の説明】
【００７１】
100…アウトソーシング運用管理システム
110…監視部、120…診断部、130…制御部、140…運用履歴、150…ビジネスルール、160…SLA評価部、170…SLA、180…合意形成支援部
300…業務システム、850…入力装置
【図１】
2007042011.tif 000003
【図２】
2007042011.tif 000004
【図３】
2007042011.tif 000005
【図４】
2007042011.tif 000006
【図５】
2007042011.tif 000007
【図６】
2007042011.tif 000008
【図７】
2007042011.tif 000009
【図８】
2007042011.tif 000010
【図９】
2007042011.tif 000011
【図１０】
2007042011.tif 000012
【図１１】
2007042011.tif 000013
【図１２】
2007042011.tif 000014