JP2003162590A - 総合的アウトソーシング管理システム - Google Patents

Abstract

(57)【要約】 【課題】 従来のアウトソーシングは、顧客システムの
運用、顧客システムの開発、顧客システムの保守などの
アウトソース種類に応じた個別契約、個別管理であっ
て、これら複数種類のアウトソースを同一顧客と同一ア
ウトソーサとが総合的に契約する総合的アウトソーシン
グが望まれていたが、これを管理する適当なツールがな
い、という課題があった。 【解決手段】 アウトソース種類毎に固有のアウトソー
スセンタ管理サーバに対してサービスを要求する総合ヘ
ルプデスク装置と、このサービス要求を中継して受信解
析し、これを適するアウトソースセンタ管理サーバに送
信し、これに対応するアウトソースセンタ管理サーバか
らのサービス実施報告を中継して受信解析し、これを前
記総合ヘルプデスク装置に送信する総合アウトソース連
携サーバとを有するシステムによって、総合的アウトソ
ーシング管理を効率よく行うことができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、情報処理システム
に関する複数のアウトソース種類を同一顧客に提供する
総合的アウトソーシングを管理する技術に関する。

【０００２】

【従来の技術】ＩＴ技術の進展、拡大に伴い、あらゆる
業務分野で情報処理の規模拡大と地域的拡大が顕著であ
る。このような中で、顧客の情報処理システムに用いる
サーバを場所ごと貸与し、あわせて、システムの運用お
よび管理を担当する事業が出現してきた。このように単
なる外注でなく、顧客の業務全体に深くかかわる外部委
託をアウトソースと呼び、このような事業者をアウトソ
ーサと称する。

【０００３】このようなアウトソーシングは、当初、上
記のような顧客システムの運用を中心とする運用系アウ
トソースから始まったが、近年、顧客業務の効率化検
討、コンサルティング、システム開発、運用中の仕様改
善、改変を顧客と一体化して行う開発系アウトソースも
行われるようになった。また、ユーザ機器、ネットワー
ク、基本ソフトの障害管理、修復、維持を行う保守系ア
ウトソースは運用系アウトソース以前から存在した。

【０００４】図４はこのような従来の複数のアウトソー
ス種類を説明するものである。図４では、（１）運用
系、（２）開発系、（３）保守系の 3種類のアウトソー
スを説明するが、今後、さらに新たな種類が産み出され
る可能性もある。図４に示す如く、これらアウトソース
を司るアウトソースセンタは、運用系はデータセンタ、
開発系は開発センタ、保守系はCEサポートセンタと呼ば
れることが多い。また、これらアウトソースセンタでは
アウトソース機能を管理し、顧客とのコミュニケーショ
ンをはかるためのアウトソースセンタ管理サーバを設置
するが、これらサーバの呼称は、本明細書では、運用系
アウトソースセンタ管理サーバをマネージドサポートデ
スクサーバ、開発系アウトソースセンタ管理サーバを案
件管理サーバ、保守系アウトソースセンタ管理サーバを
保守管理サーバと呼ぶ。

【０００５】また、運用系アウトソースや開発系アウト
ソースでは顧客と密接な連絡を計るヘルプデスクを顧客
サイトに置き、アウトソーサの要員が常駐することが多
く、このような顧客対応窓口を、ここでは運用ヘルプデ
スク、開発ヘルプデスクと呼ぶこととする。図３には上
記の従来のアウトソース例をブロック図で示した。図３
(a) は運用系アウトソースシステムであり、顧客サイト
の運用ヘルプデスククライアントがデータセンタのマネ
ージドサポートデスクサーバと交信して、月例の運用報
告書を作成したり、運用に関するＱ＆Ａを行う。図３
(b) は開発系アウトソースシステムで、顧客サイトの開
発ヘルプデスククライアントが開発センタの案件管理サ
ーバと交信して、月例の開発報告書を作成したり、開発
に関するＱ＆Ａを行う。また、図３(c) の保守系アウト
ソースシステムでは、顧客からのＣＥコールは電話やメ
ールで行われ、保守管理サーバは保守状況を管理してい
る。

【０００６】これらアウトソースは従来、アウトソース
種類ごとにアウトソース契約がなされ、その契約履行状
況が運用報告書や開発報告書でチェックされる。最近で
は、サービスレベルに関する顧客の同意を契約時点で設
定し、これを契約項目に明記するいわゆるＳＬＡ契約(S
ervice Level Agreement契約) が多くなった。図４には
このようなＳＬＡ契約項目の一例を示した。

【０００７】

【発明が解決しようとする課題】上記のように、従来の
アウトソーシングではアウトソース種類ごとに個別の契
約を行い、個別の管理が行われていた。ところが、同一
顧客が同一事業者に対して複数のアウトソース種類を同
一期間に契約するケースがある。例えば、開発系アウト
ソースにおいて、現在運用中の業務システムの仕様につ
いて、運用の状況をフィードバックしながら、仕様の追
加や変更を行うような場合、運用系アウトソースと開発
系アウトソースが同時に行われている。また、保守系ア
ウトソースはほとんどの場合、運用系アウトソーサと同
一事業者に契約される。

【０００８】しかし、このような場合であっても、アウ
トソース種類ごとに別個の契約で管理するため、顧客サ
イトでは運用ヘルプデスクと開発ヘルプデスクが別個に
置かれ別個の担当者が対応する。また、データセンタ、
開発センタ、CEサポートセンタでは相互に密接に連絡し
あっているにもかかわらず、顧客サイトから見た場合に
は、それらが別個にしか見えない。顧客から見て真のサ
ービスレベルとは、運用も開発も保守も含めた総合的な
サービスレベルであるべきなのに、これを設定したり評
価する体制もツールもなかった。

【０００９】このように、従来のアウトソーシングは、
顧客システムの運用、顧客システムの開発、顧客システ
ムの保守などのアウトソース種類に応じた個別契約、個
別管理であって、これら複数種類のアウトソースを同一
顧客と同一アウトソーサとが総合的に契約する総合的ア
ウトソーシングが望まれていたが、これを管理する適当
なツールがない、という課題があった。本発明はこのよ
うな、複数のアウトソース種類を同一顧客に提供する総
合的アウトソーシングを効率よく管理する総合的アウト
ソーシング管理システムを提供することを目的とする。

【００１０】

【課題を解決するための手段】上記課題は、図１に示す
如く、複数のアウトソース種類を同一顧客に提供する総
合的アウトソーシングを管理する総合的アウトソーシン
グ管理システムであって、アウトソース種類毎に固有の
アウトソースセンタ管理サーバ（図１では、データセン
タのマネージドサポートデスクサーバ3 、開発センタの
案件管理サーバ5 、CEサポートセンタの保守管理サーバ
6 、他ベンダCEサポートセンタの保守管理サーバ6aな
ど）に対してサービスを要求するサービスインシデント
を発する総合ヘルプデスク装置1 と、前記サービスイン
シデントを中継して受信解析し、これを適するアウトソ
ースセンタ管理サーバに送信し、これに対応する、アウ
トソースセンタ管理サーバからのサービス実施報告であ
るサービスインシデントを中継して受信解析し、これを
前記総合ヘルプデスク装置1 に送信する総合アウトソー
ス連携サーバ2 と、を有する総合的アウトソーシング管
理システムによって解決される。

【００１１】すなわち、運用系のＱ＆Ａであっても開発
系のＱ＆ＡであってもＣＥコールであっても、すべて同
一要員が担当する総合ヘルプデスク装置1 に通知入力す
ればよく、従来のように問題ごとにヘルプデスクを選択
する必要がない。総合ヘルプデスク装置1 からのサービ
スインシデントはすべて総合アウトソース連携サーバ2
に到達し、総合アウトソース連携サーバ2 によって適当
なアウトソースセンタ管理サーバが選択され、サービス
指示が伝達される。指示を受けたアウトソースセンタ管
理サーバは該当のサービスを実施してその報告をサービ
スインシデントとして総合アウトソース連携サーバ2 に
返却する。総合アウトソース連携サーバ2 はこれを総合
ヘルプデスク装置1 に返すことにより、顧客に回答が与
えられる。これによって、顧客に対するワンストップソ
リューション窓口が提供される。

【００１２】また、総合アウトソース連携サーバ2 は図
２に示す如く、各アウトソースセンタ管理サーバおよび
総合ヘルプデスク装置1 との間で授受するサービスイン
シデントをサービス状況データベースs-dbに蓄積するサ
ービスインシデント蓄積手段24を有している。これによ
って、運用系、開発系、保守系のすべてのサービスイン
シデントの授受履歴がサービス状況データベースs-dbに
蓄積され、これはサービス状況を把握するための原デー
タとして随時利用される。

【００１３】また、図２の実施例では総合ヘルプデスク
装置1 のサービス状況集計手段15、および総合アウトソ
ース連携サーバ2 のサービス状況集計手段27はともに、
サービス状況データベースs-dbの内容に基づいて、複数
アウトソース種類のサービス状況を集計総合した総合Ｓ
ＬＡ指標を含むサービス状況集計を作成する。これによ
って、運用系、開発系、保守系を総合した総合的アウト
ソーシングを評価する総合ＳＬＡ指標を顧客に提示する
ことが可能となる。

【００１４】また、図２の実施例では総合ヘルプデスク
装置1 のサービス状況検索手段13、および総合アウトソ
ース連携サーバ2 のサービス状況検索手段25はともに、
与えられた検索条件に基づいて、サービス状況データベ
ースs-dbを検索する。これによって、総合ヘルプデスク
装置1 または総合アウトソース連携サーバ2 において顧
客や事業管理者は、いつでもリアルタイムで特定サービ
スインシデントの処理状況や現在までの経緯を検索して
知ることができる。

【００１５】

【発明の実施の形態】本発明の総合的アウトソーシング
管理システム、総合的アウトソーシング管理方法、総合
アウトソース連携サーバ、総合ヘルプデスク装置、およ
び総合的アウトソーシング管理プログラムの実施例を図
１〜図９により説明する。なお、本発明におけるコンピ
ュータ処理は、コンピュータプログラムにより当該コン
ピュータの主記憶装置上で実行されるが、このコンピュ
ータプログラムの提供形態は、当該コンピュータに接続
された補助記憶装置をはじめ、ＣＤ−ＲＯＭ等の可搬型
記憶装置やネットワーク接続された他のコンピュータの
主記憶装置及び補助記憶装置等の各記録媒体に格納され
て提供されるもので、このコンピュータプログラムの実
行に際しては、当該コンピュータの主記憶装置上にロー
ディングされ実行されるものである。

【００１６】図１は本発明の総合的アウトソーシング管
理システムの構成例である。顧客は同一事業者と運用、
開発、保守のアウトソース種類を総合した総合的アウト
ソーシング契約を結んでいるものとする。顧客業務はデ
ータセンタの業務サーバgsおよびこれとインターネット
網で接続する顧客サイトの業務クライアントgcによって
稼働している。顧客サイトには部署に応じて複数の業務
クライアントgcが接続されている。データセンタは主と
して顧客の地場にあるが、リモートのバックアップセン
タとも接続されている。データセンタでは図４に示すよ
うに、単に運用を行うだけでなく、顧客サーバの監視管
理、システム環境の管理、全体サービスの調整といっ
た、いわゆるマネージド機能を働かせている。これらを
含む運用履歴は運用履歴データベースu-dbに格納され、
マネージドサポートデスクサーバ3は運用履歴データベ
ースu-dbをアクセスしつつマネージド機能を支援する。

【００１７】図１の開発センタは通常事業者の本部セン
タと地場の出先センタ、およびＳＥ会社、リモートのソ
フトハウスなどが結ばれた開発センタ網である。開発セ
ンタの機能は図４に示す如く、顧客業務システムの構
築、再構築コンサルティング、顧客業務システムのアプ
リケーション設計、開発、再開発、顧客業務システムの
操作研修、教育、顧客業務システムの運用に伴う仕様追
加、変更、データ収集などと幅広い。これらの開発事項
に則して、顧客から種々の案件を受けて、開発が進行す
る。これら開発は開発サーバ4 上で行われ、その成果は
適宜データセンタの業務サーバgsに送られインストール
される。その履歴は開発履歴データベースk-dbに蓄積す
る。案件管理サーバ5 はこれら顧客からの種々の案件と
その反映状況を開発履歴データベースk-dbに蓄積すると
ともに、開発履歴データベースk-dbを検索して顧客に対
する連絡情報を生成する。

【００１８】CEサポートセンタでは顧客業務システムの
ハード、基本ソフトの保守を管理する。保守コールは電
話やメールで受け付け、地場の保守センタから出動す
る。CEサポートセンタでは製品開発元やデータセンタ、
開発センタと連絡をとりながら障害修復をはかり、その
保守履歴は保守管理サーバ6 によって保守履歴データベ
ースh-dbに格納する。また、業務システムが他ベンダの
製品を組み込んでいる場合が多いが、この場合には、他
ベンダのCEサポートセンタとも連絡を取り合い、他ベン
ダの保守管理サーバ6aと情報交換する。

【００１９】上記のように、従来からも、データセン
タ、開発センタ、CEサポートセンタ、他ベンダのCEサポ
ートセンタなどアウトソースセンタ管理サーバ間では密
接な情報交換があったが、これらは必要に応じて個別の
手段で行われ、その履歴は個別の必要に応じて個別に残
されるが、顧客に対して統一的に状況を表示説明する目
的で管理されることはなかった。顧客は図３で説明した
ように、個別の運用ヘルプデスクや開発ヘルプデスクで
個別的に状況を知らされるのみであった。

【００２０】図１の本発明のシステムでは、これを改善
するために顧客サイトに総合ヘルプデスク装置1 を、ま
た、総合アウトソース管理センタに総合アウトソース連
携サーバ2 を設置する。総合アウトソース連携サーバ2
の設置場所は、場合によってはデータセンタや開発セン
タであってもよい。図１に黒着色部で示すように、総合
ヘルプデスク装置1 、総合アウトソース連携サーバ2 、
マネージドサポートデスクサーバ3 、案件管理サーバ5
、保守管理サーバ6 、および保守管理サーバ6aはそれ
ぞれ連携インタフェース手段を備えており、これらの装
置間の情報交換を行う送信手段と受信手段を持ってい
る。これらの装置間で授受される情報を本明細書ではサ
ービスインシデントと呼ぶ。

【００２１】図６にサービスインシデントの発生例を示
した。また総合ヘルプデスク装置1および総合アウトソ
ース連携サーバ2 の機能構成例を図２に示した。以下に
これらを参照して、情報の授受を説明する。図６は従来
のアウトソースにおいても発生していたサービスインシ
デントの例を示す。例えば、運用系アウトソースでは図
６(a) のように、顧客サイトから『JOB1235 で納付申告
書を複数枚印刷する方法。』といった質問や『JOB1218
で延滞金更新区分が更新されない。』といったトラブル
通知がある。これらに対する回答はデータセンタで発生
し、『JOB1235クローズ確認画面で『再設定』、『印
刷』の順を選び、枚数を指定して印刷します。』、『10
/25 現象確認、10/26 開発センタに調査依頼をして回答
待ちです。』などと顧客サイトに伝えられる。 また、
開発系アウトソースでは図６(b) のように、顧客サイト
から『JOB1032 で租税条約還付金通知を窓空き封筒様式
にしたい。』といった要望（仕様変更）が伝えられ、開
発センタがこれを受けて、『10/19 開発センタにて調査
中です。11/2に適用可否、適用時の条件を回答しま
す。』と回答する。次の、データセンタから開発センタ
への調査依頼『JOB1218 で延滞金更新区分が更新されな
い。開発センタにて調査下さい。』は従来、顧客サイト
から見ると内部動作であり、その履歴を顧客サイトに見
せることは従来なかった。本発明ではこれらの連絡もサ
ービスインシデントであり、例えばデータセンタからの
エスカレーションという種類のサービスインシデントで
ある。

【００２２】このように、サービスインシデントは総合
ヘルプデスク装置1 からもマネージドサポートデスクサ
ーバ3 などのアウトソースセンタ管理サーバからも発生
する。また、従来、CEサポートセンタ、データセンタ、
開発センタ相互間で電話等で連絡していた情報も、本発
明では例えば保守管理サーバ6 からマネージドサポート
デスクサーバ3 へ送られる。このような、総合ヘルプデ
スク装置1 、アウトソースセンタ管理サーバ間の情報交
換の履歴を収集管理するために、本発明では総合アウト
ソース連携サーバ2 がこれら情報授受の中継点となる。
この様子を図２によって説明する。

【００２３】図２において二重線の矢印で示したよう
に、すべてのサービスインシデントは総合アウトソース
連携サーバ2 を最初の送信先または発信元とする。この
ため、総合アウトソース連携サーバ2 の連携インタフェ
ース手段21は一般に、対向する総合ヘルプデスク装置1
および個別のアウトソースセンタ管理サーバ毎に異なる
複数種の連携インタフェース手段21をとる。これは、理
想的にはすべて同一種類のプロトコルや内部表現で統一
されれば最も望ましいが、本実施例では、既成のアウト
ソースセンタ管理サーバ内の内部表現や保有する通信プ
ロトコルをできるだけ利用して、新設する総合アウトソ
ース連携サーバ2 の連携インタフェース手段21において
これらの相違を吸収することとした。一般には各連携イ
ンタフェース手段は必要なプロトコル変換やコード変換
を行ってサービスインシデントを送信および受信する機
能をもつ。このようにした場合、サービスインシデント
のデータ構造としては必要データ項目のみを共通に約束
し、データ形式、プロトコルは個別に調整される。

【００２４】図７には総合アウトソース連携サーバ2 に
おけるサービスインシデントのデータ構造例を示す。総
合アウトソース連携サーバ2 内では図７に示すようにタ
グ名とデータとの対で項目データを表現する。このよう
な形式は容易にＸＭＬデータとして授受可能である。図
７で星印の項目はサービスインシデント発生元で記入
し、他はこれを中継した総合アウトソース連携サーバ2
において記入する。図７のデータ例は図６(b) でデータ
センタから発したエスカレーション依頼に対応するもの
である。

【００２５】以上のように総合アウトソース連携サーバ
2 はすべてのサービスインシデントの授受中継点とな
り、アウトソースセンタ管理サーバに対するサービス指
示（ディスパッチ／エスカレーション）やサービスイン
シデント交換を行うとともに、図７に示すように各サー
ビスインシデントの相互関係をリンクリストの形で整理
して記入した上で、サービス状況データベースs-dbに格
納蓄積する。その動作について図５のフロー図によって
以下に詳細に説明する。

【００２６】総合アウトソース連携サーバ2 の連携イン
タフェース手段21は常時電文受信を監視しており、図５
(a) のステップＳ５１１において電文を受信する。ステ
ップＳ５１２においてサービスインシデント解析手段22
は上記受信電文を解析して、ステップＳ５１３でそれが
サービスインシデントであるか否かを判定する。多くの
場合はサービスインシデントであるが、場合によっては
総合ヘルプデスク装置1 からの検索要求や作表要求であ
ることがあり、この場合は図５(b) 、(c) に分岐する。

【００２７】サービスインシデントの受信であった場
合、サービスインシデント解析手段22はステップＳ５１
４でその電文中の直前サービスインシデントNo. タグで
示される直前サービスインシデントNo. を取得し、サー
ビス状況データベースs-dbと照合して、当該サービスイ
ンシデントの位置づけを知る。図７の例では直前サービ
スインシデントNo.xxx-1086-1 は先に総合アウトソース
連携サーバ2 がデータセンタに対して行ったサービス指
示であり、本サービスインシデントがその回答である。
しかし、種類タグがエスカレーション依頼であるので、
サービスインシデント解析手段22は本サービスインシデ
ントを開発センタに指示すべきことを判定し、サービス
指示手段23にその判定結果を渡す。サービス指示手段23
は本サービスインシデントにサービスインシデントNo.x
xx-1086-2 を付して図７の残り項目を書き込むととも
に、サービスインシデントNo.xxx-1086-3 のサービスイ
ンシデントを新たに生成する。連携インタフェース手段
21はこのサービスインシデントをαβγ開発センタに送
出する。

【００２８】次いで、サービスインシデント蓄積手段24
はステップＳ５１５において上記サービスインシデント
No.xxx-1086-2 の完成されたデータをサービス状況デー
タベースs-dbに格納蓄積する。また、ステップＳ５１６
において、新たに生成発信したサービスインシデントN
o.xxx-1086-3 のサービスインシデントをサービス状況
データベースs-dbに蓄積する。また、サービスインシデ
ント蓄積手段24はステップＳ５１７において、このサー
ビスインシデント追加に伴ってサービス状況集計領域の
諸々のインデックス値や累計値などを更新する。

【００２９】次に、総合アウトソース連携サーバ2 にお
いて外部から（例えば、ステップＳ５１３のno分岐のよ
うに、総合ヘルプデスク装置1 などからの電文受信
で、) または、総合アウトソース連携サーバ2 のコンソ
ール入力によってサービス状況データベースs-dbの検索
要求があった場合の総合アウトソース連携サーバ2 の動
作を図５(b) によって説明する。総合アウトソース連携
サーバ2 のサービス状況検索手段25はステップＳ５２１
で検索条件を解析し、サービス状況データベースs-dbか
ら条件に合致するレコードを取り出す。そして、ステッ
プＳ５２２で本検索要求元を判断し、外部からの要求で
あった場合にはステップＳ５２３でこの検索結果を要求
元へ送信する。この場合連携インタフェース手段21に送
信を依頼し、連携インタフェース手段21は予め要求元毎
に設定されたデータ形式にこの検索結果を変換して送信
する。一方、総合アウトソース連携サーバ2 の内部から
の要求であった場合はステップＳ５２４に分岐し、サー
ビス状況表示手段26はこの検索結果を画面表示形式に編
集してこれを表示する。

【００３０】上記ステップＳ５２３で検索要求元が総合
ヘルプデスク装置1 で、現在のサービス状況を総合ヘル
プデスク装置1 のサービス状況表示手段14によって表示
する例を図８に示した。図８(a) は本総合的アウトソー
シングのサービス状況の全体を把握するための表示例で
ある。現時点における運用、開発、保守のすべてにわた
るサービスインシデントを時系列で示したり、未解決の
ものをソートして表示することができる。また図８(b)
は特定のサービスインシデントの発生からこれが対処完
了に至るまでの経過の推移状況を表示する例である。こ
のように、本発明によって総合ヘルプデスク装置1 にお
いて、いつでもリアルタイムで全体の状況把握をするこ
とができ、今誰が何をしているのかがわかる。

【００３１】次に、総合アウトソース連携サーバ2 にお
いて外部から（例えば、ステップＳ５１３のno分岐のよ
うに、総合ヘルプデスク装置1 などからの電文受信
で、) または、総合アウトソース連携サーバ2 のコンソ
ール入力によってサービス状況に関する作表要求があっ
た場合の総合アウトソース連携サーバ2 の動作を図５
(c)によって説明する。総合アウトソース連携サーバ2
のサービス状況集計手段27はステップＳ５３１で作表条
件を解析し、サービス状況データベースs-dbからデータ
を取得加工し、条件に合わせた作表を行う。そして、ス
テップＳ５３２で本作表要求元を判断し、外部からの要
求であった場合にはステップＳ５３３でこの作表結果を
要求元へ送信する。この場合連携インタフェース手段21
に送信を依頼し、連携インタフェース手段21は予め要求
元毎に設定されたデータ形式にこの作表結果を変換して
送信する。一方、総合アウトソース連携サーバ2 の内部
からの要求であった場合はステップＳ５３４に分岐し、
サービス状況印刷手段28はこの作表結果を印刷して提供
する。

【００３２】上記ステップＳ５３３で作表要求元が総合
ヘルプデスク装置1 で、現在のサービス状況を総合ヘル
プデスク装置1 のサービス状況印刷手段16によって印刷
する例を図９に示した。図９は顧客に対する月例報告書
の例であり、運用、開発、保守のすべてにわたる総合的
アウトソーシングの総合報告書である。本報告書のある
一面では、図９に例示するように、ＳＬＡ契約項目に定
める測定項目に関し、ＳＬＡレベル設定と今月度の測定
値、累積の測定値が対比される形式で印刷される。ま
た、これらを総合した総合ＳＬＡ得点が契約時に定めら
れた算出式から算出され、併せて印刷される。これによ
って総合的アウトソーシングの総合的サービスレベルを
把握することができる。

【００３３】図２の実施例では、総合ヘルプデスク装置
1 においてもサービス状況検索手段13が備えられ、先に
総合アウトソース連携サーバ2 の検索機能としてステッ
プＳ５２１で説明したのと同等の機能を持たせた。これ
はある意味で冗長であるが、総合アウトソース連携サー
バ2 の検索機能に頼らずに独自の検索を可能ならしめ
る。同様に、本実施例では総合ヘルプデスク装置1 にお
いてもサービス状況集計手段15を予備的に備えており、
サービス状況データベースs-dbの状況集計をリモートで
独自集計法で集計するなどの効用がある。

【００３４】（付記１） 複数のアウトソース種類を同
一顧客に提供する総合的アウトソーシングを管理する総
合的アウトソーシング管理システムであって、アウトソ
ース種類毎に固有のアウトソースセンタ管理サーバに対
してサービスを要求するサービスインシデントを発する
総合ヘルプデスク装置と、前記サービスインシデントを
中継して受信解析し、これを適するアウトソースセンタ
管理サーバに送信し、これに対応するアウトソースセン
タ管理サーバからのサービス実施報告であるサービスイ
ンシデントを中継して受信解析し、これを前記総合ヘル
プデスク装置に送信する総合アウトソース連携サーバ
と、を有することを特徴とする総合的アウトソーシング
管理システム。

【００３５】（付記２） 複数のアウトソース種類を同
一顧客に提供する総合的アウトソーシングを管理する総
合的アウトソーシング管理方法であって、アウトソース
種類毎に固有のアウトソースセンタ管理サーバに対して
サービスを要求するサービスインシデントをサービス要
求発信元から発する段階と、前記サービスインシデント
を中継点で受信解析し、これを適するアウトソースセン
タ管理サーバに送信する段階と、これに対応する、アウ
トソースセンタ管理サーバからのサービス実施報告であ
るサービスインシデントを前記中継点が受信解析する段
階と、前記受信したサービスインシデントを前記中継点
から前記サービス要求発信元に送信する段階と、を有す
ることを特徴とする総合的アウトソーシング管理方法。

【００３６】（付記３） 複数のアウトソース種類を同
一顧客に提供する総合的アウトソーシングを管理する総
合的アウトソーシング管理システムを形成する総合ヘル
プデスク装置であって、アウトソース種類毎に固有のア
ウトソースセンタ管理サーバに対してサービスを要求す
るサービスインシデントを送信する送信手段と、前記サ
ービスインシデントを実施したアウトソースセンタ管理
サーバの実施報告であるサービスインシデントを受信す
る受信手段と、を有することを特徴とする総合ヘルプデ
スク装置。

【００３７】（付記４） 複数のアウトソース種類を同
一顧客に提供する総合的アウトソーシングを管理する総
合的アウトソーシング管理システムを形成する総合アウ
トソース連携サーバであって、アウトソース種類毎に固
有のアウトソースセンタ管理サーバに対してサービスを
要求する総合ヘルプデスク装置からのサービスインシデ
ントを中継して受信解析する手段と、前記サービスイン
シデントに適するアウトソースセンタ管理サーバに対応
するサービス指示であるサービスインシデントを送信す
る送信手段と、前記サービス指示を受けたアウトソース
センタ管理サーバからサービス実施報告であるサービス
インシデントを中継して受信解析する手段と、前記サー
ビス実施報告であるサービスインシデントを前記総合ヘ
ルプデスク装置に送信する送信手段と、を有することを
特徴とする総合アウトソース連携サーバ。

【００３８】（付記５） 複数のアウトソース種類を同
一顧客に提供する総合的アウトソーシングを管理する情
報処理をコンピュータに実行させるための総合的アウト
ソーシング管理プログラムであって、アウトソース種類
毎に固有のアウトソースセンタ管理サーバに対してサー
ビスを要求するサービスインシデントをサービス要求発
信元から発する段階と、前記サービスインシデントを中
継点で受信解析し、これを適するアウトソースセンタ管
理サーバに送信する段階と、これに対応する、アウトソ
ースセンタ管理サーバからのサービス実施報告であるサ
ービスインシデントを前記中継点が受信解析する段階
と、前記受信したサービスインシデントを前記中継点か
ら前記サービス要求発信元に送信する段階と、をコンピ
ュータに実行させることを特徴とする総合的アウトソー
シング管理プログラム。

【００３９】（付記６） 各アウトソースセンタ管理サ
ーバおよび総合ヘルプデスク装置との間で授受するサー
ビスインシデントをサービス状況データベースに蓄積す
るサービスインシデント蓄積手段をさらに有することを
特徴とする付記４記載の総合アウトソース連携サーバ。 （付記７） 前記サービス状況データベースの内容に基
づいて、複数アウトソース種類のサービス状況を集計総
合した総合ＳＬＡ指標を含むサービス状況集計を作成す
るサービス状況集計手段、をさらに有することを特徴と
する付記６記載の総合アウトソース連携サーバ。

【００４０】（付記８） 与えられた検索条件に基づい
て、前記サービス状況データベースを検索するサービス
状況検索手段、をさらに有することを特徴とする付記６
記載の総合アウトソース連携サーバ。 （付記９） 総合アウトソース連携サーバのサービス状
況データベースの内容に基づいて、複数アウトソース種
類のサービス状況を集計総合した総合ＳＬＡ指標を含む
サービス状況集計を作成するサービス状況集計手段、を
さらに有することを特徴とする付記３記載の総合ヘルプ
デスク装置。

【００４１】（付記１０） 与えられた検索条件に基づ
いて、総合アウトソース連携サーバのサービス状況デー
タベースを検索するサービス状況検索手段、をさらに有
することを特徴とする付記３記載の総合ヘルプデスク装
置。 （付記１１） 前記サービスインシデントをサービス状
況データベースに蓄積するサービスインシデント蓄積手
段と、与えられた検索条件に基づいて、前記サービス状
況データベースを検索するサービス状況検索手段と、を
さらに有することを特徴とする付記１記載の総合的アウ
トソーシング管理システム。

【００４２】

【発明の効果】以上の説明から明らかなように、本発明
によれば、複数のアウトソース種類を同一顧客に提供す
る総合的アウトソーシングにおいて、顧客サイトでリア
ルタイムに総合的に現在のサービス状況を把握でき、ま
た総合的なサービスレベルを顧客サイトと事業者サイト
で合意することができ、総合的アウトソーシングを効率
よく管理できる、という効果がある。

【図面の簡単な説明】

【図１】本発明の総合的アウトソーシング管理システム
の構成例

【図２】本発明の総合ヘルプデスク装置および総合アウ
トソース連携サーバの機能構成例

【図３】従来のアウトソースシステム例

【図４】アウトソース種類と関連装置例

【図５】総合アウトソース連携サーバの動作フロー例

【図６】サービスインシデントの発生例

【図７】総合アウトソース連携サーバにおけるサービス
インシデントのデータ構造例

【図８】総合ヘルプデスク装置1 のリアルタイム状況表
示例

【図９】総合ヘルプデスク装置1 における総合報告書作
表例

【符号の説明】

１ 総合ヘルプデスク装置 ２ 総合アウトソース連携サーバ ３ マネージドサポートデスクサーバ ４ 開発サーバ ５ 案件管理サーバ ６ 保守管理サーバ 11 連携インタフェース手段 12 サービスインシデント生成手段 13 25 サービス状況検索手段 14 26 サービス状況表示手段 15 27 サービス状況集計手段 16 28 サービス状況印刷手段 21 連携インタフェース手段 22 サービスインシデント解析手段 23 サービス指示手段 24 サービスインシデント蓄積手段 業務サーバgs 業務クライアントgc 運用履歴データベースu-db 開発履歴データベースk-db 保守履歴データベースh-db サービス状況データベースs-db

───────────────────────────────────────────────────── フロントページの続き (72)発明者 家塚 章蔵 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 (72)発明者 岸根 真紀 鳥取県鳥取市永楽温泉町271番地 株式会 社富士通鳥取システムエンジニアリング内 (72)発明者 石田 一雄 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 (72)発明者 安藤 羊次 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内

Claims (2)

【特許請求の範囲】
1. 【請求項１】 複数のアウトソース種類を同一顧客に提
   供する総合的アウトソーシングを管理する総合的アウト
   ソーシング管理システムであって、 アウトソース種類毎に固有のアウトソースセンタ管理サ
   ーバに対してサービスを要求するサービスインシデント
   を発する総合ヘルプデスク装置と、 前記サービスインシデントを中継して受信解析し、これ
   を適するアウトソースセンタ管理サーバに送信し、これ
   に対応するアウトソースセンタ管理サーバからのサービ
   ス実施報告であるサービスインシデントを中継して受信
   解析し、これを前記総合ヘルプデスク装置に送信する総
   合アウトソース連携サーバと、 を有することを特徴とする総合的アウトソーシング管理
   システム。
2. 【請求項２】 前記サービスインシデントをサービス状
   況データベースに蓄積するサービスインシデント蓄積手
   段と、 与えられた検索条件に基づいて、前記サービス状況デー
   タベースを検索するサービス状況検索手段と、をさらに
   有することを特徴とする請求項１記載の総合的アウトソ
   ーシング管理システム。