業務管理システム、及び、業務処理実行方法
【課題】 複数の手順を有する業務処理を効率的に実行する業務管理システム、及び、業務処理実行方法を提供することを目的とする。
【解決手段】 業務管理システム２が備えるサーバ２０の業務実行受付部２１は、業務処理の実行命令を受け付ける。業務シナリオ解析部２２は業務シナリオを解析する。業務処理実行部２３は、業務シナリオの解析結果に基づいて、業務処理を実行すべきサーバ２０に対して業務処理の実行命令を行う。
【解決手段】 業務管理システム２が備えるサーバ２０の業務実行受付部２１は、業務処理の実行命令を受け付ける。業務シナリオ解析部２２は業務シナリオを解析する。業務処理実行部２３は、業務シナリオの解析結果に基づいて、業務処理を実行すべきサーバ２０に対して業務処理の実行命令を行う。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、業務処理を効率的に行う業務管理システム、及び、業務処理実行方法に関する。
【背景技術】
【０００２】
従来の通信網に存在するネットワークエレメント（Network Element、以降、「ＮＥ」という）等のオペレーションにおいて、ファイル更新を始めとする業務フロー化が可能な業務をシステム化するための業務管理技術のひとつとして、特許文献１に記載された技術が知られている。特許文献１に記載されているファイル更新方法では、ファイル更新の手順をコマンド投入処理とコマンド応答判定処理とに分離し、これらの処理を指定するステップと指定された処理の実行を制御するステップとを有することに代表される特徴を持っている。
【０００３】
また、コマンド投入処理等で投入される部品と称されるプログラムの一部は変更容易な簡易言語で記述され、柔軟性を持たせている。また、ファイル更新の業務を、作業項目に当たる部品と、部品を指定する手順に当たるシナリオとで成立させることでも柔軟性も持たせている。このように、特許文献１においては、部品をシナリオで指定することで、変化に柔軟なファイル更新方法を実現している。
【０００４】
図１２は、特許文献１に開示されているシステムの構成図である。ファイル更新操作端末１００、及び、ファイル更新装置２００は汎用的なコンピュータである。これらの装置において上記の技術に従った専用のプログラムを動作させることにより、ファイル更新システム５００は、ＮＥ監視制御装置３００を介してＮＥ４００と通信回線で接続し、ＮＥ４００に対するファイル更新の業務機能を実現させている。
【０００５】
また、シナリオを利用した他のシステムとして、特許文献２には、プログラムの実行順序が記述されたシナリオを用いてサービスを実行するサービス実行制御システムが開示されている。
【特許文献１】特開２００３−２８９３８１号公報
【特許文献２】特開平９−１４６７６５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
特許文献１に記載の技術においては、プログラム構造的に柔軟性を持たせる工夫を行っている。しかし、特許文献１に記載の技術は、単一マシンを用いた集中型システムの中でプログラムを動作させることを念頭に置いた技術である。同様に、特許文献２に記載の技術も集中型システムを前提としており、シナリオには単一装置内のプログラム格納部に格納されているプログラムのみが記述されている。
【０００７】
現在、複数機器をネットワークに接続して構成する分散システムが提案され、開発が盛んに行われている。分散システムにおいては、安価なハードウェアを用いることができることや、たくさんのマシンを用いることによってシステムの大規模故障が発生しないといったメリットがある。このように、ハードウェア構成に柔軟性を持つ分散環境において、ファイル更新を初めとする、業務フロー化が可能な業務を対象とした業務管理システムの構築が要求されている。
【０００８】
特許文献１においてはＮＥのファイル更新について触れているが、通信網のオペレーション業務においては、ファイル更新に限らず、業務フロー化できる業務が複数存在する。これらも含め、効率的なシステム構築が課題である。
その業務の中のひとつとして、個々のＮＥが正確に動作するために必要なデータ（以降、「局データ」という）をＮＥに設定する方法についての課題がある。
【０００９】
局データをＮＥに設定する場合には、通常は、あらかじめ作成した局データファイルをＮＥに投入する。ただし、このようにあらかじめ局データファイルを作成する場合には、局データを作成するまでにいくつかの工程が必要であり、効率的でない場合もある。しかし、現状ではこのあらかじめ作成しておくという考え方に基づいたＮＥ仕様が多数である。
【００１０】
一方、局データ一つ一つをＮＥへのデータ設定命令と捕らえることで、いくつかの局データ作成工程やシステムを縮小し、必要最小限の命令のみを作成することで、実質的に必要なデータをＮＥへ投入することができるＮＥ仕様も存在する。このＮＥ仕様を用いた場合、先に触れた一括投入形式の局データを作成するまでのいくつかの工程は効率化される。その代わりに、その局データが複数種あり、また複数種を同じタイミングでシーケンシャルに、またはパラレルに設定するような場合、これらのデータが重要なデータであるために、ＮＥへの投入前後でデータ種別毎に異なる確認作業が必要となるという設定上の課題が発生する。このように、データを個々に投入する業務において、投入前後でデータ種別毎に異なる確認作業があり、かつ、複数かつ複数種の投入すべき局データがあるような手順の多い業務である場合には、業務処理の効率化が必要である。
【００１１】
本発明は以上のような課題に鑑みてなされたものであり、複数の手順を有する業務処理を効率的に実行する業務管理システム、及び、業務処理実行方法を提供することを目的とする。
【課題を解決するための手段】
【００１２】
上記課題を解決するために、請求項１に記載の発明は、複数の通信装置を含む分散型の業務管理システムにおいて、前記通信装置は、業務処理の実行命令を受け付ける業務実行受付手段と、前記業務実行受付手段により受け付けられた業務処理を行うための単機能処理と該単機能処理の実行順序とが記述された業務シナリオデータを解析する業務シナリオ解析手段と、前記業務シナリオ解析手段による解析結果に基づいて、前記業務処理を実行すべき通信装置に対して該業務処理の実行命令を行う業務処理実行手段とを備えることを特徴とする業務管理システムを提供する。
【００１３】
この構成によれば、業務管理システムは、業務シナリオデータの解析結果に基づいて、業務処理を実行すべき通信装置に対して業務処理の実行命令を行うため、実行命令を受けた通信装置が自動的に業務処理を実行することができ、複数の手順を有する業務処理であっても効率的に業務処理を遂行することができる。
請求項２に記載の発明は、請求項１に記載の業務管理システムにおいて、前記業務シナリオデータには、前記単機能処理を表す情報として、実行すべきプログラムと、解析すべき他の業務シナリオデータと、の少なくとも１を識別するための情報が記述されていることを特徴とする。
【００１４】
この構成によれば、業務シナリオデータに、単機能処理を表す情報として、プログラムを識別するための情報のみならず、他の業務シナリオデータを識別するための情報も記述することができ、複雑な手順の業務処理にも柔軟に対応することができる。このような多次元構造の業務シナリオデータを利用して多次元構造の業務フローを実現し、業務シナリオデータ間の再利用性を最大限に生かした業務管理システムを構築することができる。
【００１５】
請求項３に記載の発明は、請求項１又は２に記載の業務管理システムにおいて、前記業務処理実行手段は、前記業務シナリオデータに記述された実行順序に従って、前記単機能処理の実行命令を、該単機能処理を実行すべき通信装置に対して順次送信することを特徴とする。
この構成によれば、１つの通信装置が、業務シナリオデータに記述された実行順序に従って、単機能処理の実行命令を該単機能処理を実行すべき通信装置に対して順次送信するため、複数の手順を有する業務処理であっても、複数の通信装置において効率的に業務処理を行うことができる。
【００１６】
請求項４に記載の発明は、請求項１から３のいずれか１項に記載の業務管理システムにおいて、前記業務処理実行手段は、前記単機能処理の実行命令を含んだ前記業務シナリオデータを、該単機能処理を実行すべき通信装置に対して送信することを特徴とする。
この構成によれば、業務シナリオデータが業務処理の実行順序に従って通信装置間を巡回し、業務シナリオを受信した通信装置が単機能処理の実行制御を行うことができる。これにより、業務管理システム内における業務処理の負荷分散を行ことができ、複数の手順を有する業務処理であっても、複数の通信装置において効率的に業務処理を行うことができる。
【００１７】
請求項５に記載の発明は、請求項１から４のいずれか１項に記載の業務管理システムにおいて、前記業務処理の実行制御を行う実行制御手段をさらに備え、
前記実行制御手段は、前記業務処理の中断と再試行とを制御することを特徴とする。
この構成によれば、業務管理システムは、業務処理の実行を柔軟に制御することができる。
【００１８】
請求項６に記載の発明は、請求項５に記載の業務管理システムにおいて、前記実行制御手段は、中断された業務処理を、外部より指示された箇所から再試行することを特徴とする。
この構成によれば、業務管理システムは、中断された業務処理を外部からの指示により任意の箇所から再試行することができ、業務処理の実行を柔軟に制御し、効率的に業務処理を行うことができる。
【００１９】
請求項７に記載の発明は、請求項５又は６に記載の業務管理システムにおいて、前記業務シナリオデータには、階層的なグループに分類された単機能処理が記述されており、前記実行制御手段は、前記業務シナリオデータに記述されているグループ分けに基づいて、前記業務処理の実行制御を行うことを特徴とする。
この構成によれば、業務管理システムは、単機能処理をグループ毎に管理することができ、グループ毎に各種操作や設定を行うことにより、業務処理の実行制御を行い易い。また、階層的にグループ化することにより、柔軟性のある多次元の業務フローを容易に実現することができる。
【００２０】
請求項８に記載の発明は、請求項５から７のいずれか１項に記載の業務管理システムにおいて、前記業務シナリオデータには、前記単機能処理の実行結果に基づいて次に実行すべき単機能処理を決定するための制御文が記述されており、前記実行制御手段は、前記業務シナリオデータに記述されている制御文に従って前記業務処理の実行制御を行うことを特徴とする。
【００２１】
この構成によれば、業務管理システムは、制御文に従って柔軟に業務処理の実行手順を制御することができる。
請求項９に記載の発明は、請求項１から８のいずれか１項に記載の業務管理システムにおいて、前記業務シナリオデータと業務キーワードとを対応付けて記憶する業務キーワード記憶手段と、外部からの指示に対応する業務キーワードと対応付けられて前記業務キーワード記憶手段に記憶されている業務シナリオデータに基づいて、１又は複数の業務シナリオデータを含む一連の業務処理手順を表す情報を生成する業務シナリオ生成部とを備えることを特徴とする。
【００２２】
この構成によれば、外部からの指示に対応する業務キーワードから容易に一連の業務処理手順を表す情報を生成することができ、多くの制御を必要とする業務処理についての業務効率化が可能となる。
請求項１０に記載の発明は、複数の通信装置を含む分散型の業務管理システムが行う業務処理実行方法において、業務処理の実行命令を受け付ける業務実行受付ステップと、前記業務実行受付ステップにおいて受け付けられた業務処理を行うための単機能処理と該単機能処理の実行順序とが記述された業務シナリオデータを解析する業務シナリオ解析ステップと、前記業務シナリオ解析ステップにおける解析結果に基づいて、前記業務処理を実行すべき通信装置に対して該業務処理の実行命令を行う業務処理実行ステップとを有することを特徴とする業務処理実行方法を提供する。
この方法による作用、効果は、請求項１と同様である。
【発明の効果】
【００２３】
以上のように本発明によれば、業務管理システムは、業務シナリオデータの解析結果に基づいて、業務処理を実行すべき通信装置に対して業務処理の実行命令を行うため、実行命令を受けた通信装置が自動的に業務処理を実行することができ、複数の手順を有する業務処理であっても効率的に業務処理を遂行することができる。
【発明を実施するための最良の形態】
【００２４】
次に、図面を参照しながら、本発明を実施するための実施の形態について説明する。なお、以下の説明において参照する各図においては、他の図と同等部分に同一符号が付されている。
図１は、本発明の実施の形態に係る業務管理システム２の構成を示す図である。同図に示すように、業務管理システム２は、ユーザ操作用の通信端末である業務管理システム端末１と、交換機等のネットワーク設備であるＮＥ４と、ＮＥ４を監視及び制御するＮＥ監視制御装置３と、に通信ネットワークを介して接続されている。
【００２５】
次に、業務管理システム２の構成について説明する。業務管理システム２は分散型のシステムであり、分散配備された複数のサーバ２０により構成されている。サーバ２０は、例えば、小型ＩＡサーバである。サーバ２０同士は、ギガビットイーサネット（登録商標）等の通信ネットワークで接続されている。業務管理システム２は、通信網オペレーションに関わる各種業務を管理及び実行する。
【００２６】
サーバ２０は、ハードウェア構成として、図示せぬＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）とＲＡＭ（Random Access Memory）とハードディスク装置を含む記憶部、及び、通信ネットワークを介してデータの授受を制御する通信インターフェースとを備えている。
サーバ２０の記憶部には、各種ソフトウェアが記憶されている。各種ソフトウェアには、ＯＳ（Operating System）と、Ｊａｖａ（登録商標）実行環境を構築するためのソフトウェアと、業務シナリオデータ（以下「業務シナリオ」という）を解析するためのプログラムと、Ｄ３Ａ（Distributed Data Driven Architecture；分散型データ駆動アーキテクチャ）シナリオデータ（以下「Ｄ３Ａシナリオ」という）を解析するためのプログラムとが含まれている。
【００２７】
図２は、サーバ２０の記憶部に記憶されるソフトウェアやＣＰＵの動作により実現されるソフトウェア環境の一例を説明するための図である。
同図に示すように、ソフトウェア環境は、Ｄ３Ａ層と業務アプリケーション層とで構成されている。Ｄ３Ａ層は、Ｊａｖａ（登録商標）ＶＭと、当該Ｊａｖａ（登録商標）ＶＭ上で動作するＤ３Ａ基盤と、Ｄ３Ａシナリオとを含んで構成される。Ｄ３Ａ基盤は、Ｄ３Ａシナリオを解析し、解析結果に従った処理の実行を制御する。Ｄ３Ａ基盤はＪａｖａ（登録商標）でコーディングされており、Ｄ３ＡシナリオはＸＭＬ（eXtensible Markup Language）で記述されている。
【００２８】
ここで、Ｄ３Ａシナリオとは、システム内部の処理命令の手順が記述され、処理命令を与えるための記述と、処理結果として返されたデータ格納場所とをもつデータである。また、Ｄ３Ａ基盤とは、Ｄ３Ａシナリオを解析し駆動させる役目を持つエンジンプログラムである。
このように、サーバ２０のソフトウェア環境は、分散システム用に開発された分散型データ駆動型アーキテクチャ（Ｄ３Ａ）をベースとする。集中型システムが、単一マシンにおいてメインプログラムを動作させ、そこから単機能プロセスを呼び出して処理を実行していくのに対し、Ｄ３Ａでは、図３に示すように、従来のメインプログラムに変わる部分となるシナリオが単機能プロセスを経由して処理を実行していく。
【００２９】
Ｄ３Ａにおいては、Ｄ３Ａシナリオが処理を実行するのでははく、ＸＭＬで書かれたＤ３Ａシナリオの実行条件をＤ３Ａ基盤が解析し、単機能プロセスに指示を出す。単機能プロセスで処理を行った結果はＤ３Ａシナリオにデータとして格納され、次の単機能プロセスにＤ３Ａシナリオが駆動される。Ｄ３Ａシナリオには単機能プロセスを経由する順番が記述されており、ネットワークで接続され分散配備されたマシン間を経由していくことも可能である。指定された単機能プロセスを全て経由し終わると一連の処理が完了したことになる。シナリオによる駆動動作の変更は、単機能プロセスがすでに存在していれば、Ｄ３Ａシナリオに記述する経路を変更すればよいし、単機能プロセスが存在しない、または、既存にある単機能プロセスを変更するような場合には、その単機能プロセスを実現するためのプログラムを適当なマシンに配備し、経路を変更することで対応可能である。ユーザの指示により、Ｄ３Ａで構築されたシステムに命令が送られると、システムが命令を受け取り、命令を解析してＤ３Ａシナリオを生成し動作することになる。
【００３０】
また、サーバ２０が備えるソフトウェア環境においては、Ｄ３Ａ層の上位層として、図２に示すように業務アプリケーション層が設けられている。業務アプリケーション層は、Ｊａｖａ（登録商標）ＶＭと、当該Ｊａｖａ（登録商標）ＶＭ上で動作する業務解析エンジンと、業務シナリオとを含んで構成される。業務解析エンジンは、業務シナリオの記述を解析し、解析結果に従って処理を実行するためのプログラムである。業務解析エンジンはＪａｖａ（登録商標）でコーディングされており、業務シナリオはＸＭＬで記述されている。
【００３１】
Ｄ３Ａ層を内部処理的なシナリオとするならば、業務アプリケーション層は、Ｄ３Ａをベースにしながら、上位層アーキテクチャとして、シナリオと個々の処理プログラムとを組み合わせた構造をとる。
ここで、システムの内部処理で使用されるＤ３Ａシナリオと、業務管理システム２において業務効率化のために使用される業務シナリオとの違いを整理する。両者ともＸＭＬで記述されたテキストベースの定義ファイルであり、技術的には共通のものであるが、定義体が異なっている。従って、Ｄ３Ａ基盤は業務シナリオを解析することができない。このため、本実施形態に係る業務管理システム２においては、Ｄ３Ａ基盤とは別に、上位アプリケーションとしての業務解析エンジンを設ける構成とした。なお、このような業務解析エンジンを設ける構成は一例であり、例えば、Ｄ３Ａ基盤が理解可能な定義体で業務シナリオを作成してもよいし、または、Ｄ３Ａ基盤を改造して、業務シナリオを理解できるようにしてもよい。
【００３２】
このように、Ｄ３Ａシナリオと業務シナリオとは同一の技術を利用した言語を用いて記述されているため、システム変更、構築上の柔軟性、及び、選択性を確保することができる。なお、本実施形態においては、ソフトウェア環境をＤ３Ａ層と業務アプリケーション層との２段階に構築したが、このような関係の層を複数段階に構築することもできる。段階数はシナリオと解析エンジンの開発の仕方による。
【００３３】
［業務シナリオ］
次に、業務シナリオについて説明する。業務シナリオには業務処理の一連の手順が記述される。業務処理の手順は、業務処理の手順毎の処理内容である単機能処理と、当該単機能処理の実行順序とで表すことができる。
【００３４】
ここで、ユーザがシステムに対して命令を行い、ＸＭＬで記述されたＤ３Ａシナリオにより単機能としてのプログラムが次々と処理されて、処理が完結するまでをひとつの単シナリオとする。この単シナリオは、ユーザに取ってみれば、ひとつの単機能と捉えることもできる。本実施形態においては、人が行う業務手順を業務シナリオという形で定義し、業務シナリオに沿って、ユーザにとっての単機能つまり単シナリオを動作させる。
【００３５】
業務シナリオの記述においては、Ｄ３Ａシナリオの記述と異なり、実行すべきプログラム名の代わりに他の業務シナリオ名や単シナリオ名を記述することが可能である。すなわち、業務シナリオには、単機能処理を表す情報として、実行すべきプログラムと、解析すべき単シナリオと、解析すべき他の業務シナリオと、の少なくとも１を識別するための情報を記述することができる。従って、ある業務シナリオが単機能として扱う処理は、プログラムにより実行される処理と、Ｄ３Ａシナリオ（単シナリオ）を解析することにより実行される処理と、他の業務シナリオを解析することにより実行される処理を含むこととなる。
【００３６】
図４には、業務シナリオの記述例を示す。同図に示すように、業務シナリオＡには、単機能処理を表す情報として、実行すべきプログラム名と、解析すべき他の業務シナリオ名と、解析すべき単シナリオ名とが記述されている。また、単機能処理の実行順序を表す情報として、手順の番号が記述されている。
このように、業務シナリオに他の業務シナリオを記述することができるため、業務シナリオやプログラムの多段階の再利用が可能となり、すなわちこれが業務シナリオの多次元構造となる。
【００３７】
また、Ｄ３Ａシナリオは、単機能として主にプログラムを使用するが、業務シナリオは、他の業務シナリオが動作し他の単機能や単シナリオの連続実施により得られた結果を次の処理に渡すことが可能である。このため、業務シナリオを定義するときに、実際の単機能を意識することなく、３ＤＡシナリオや別の業務シナリオを単機能として扱って業務シナリオを定義することができる。そして、業務シナリオによって定義された業務処理の実行手順において、同一の処理についてはシナリオやプログラムを再利用可能であるという利点が得られる。このように、本実施形態に係る業務シナリオを用いることで、同一手順を複数回行うような業務において業務効率化を図ることが可能となる。
【００３８】
図４には２次元構造に近い例を示したが、実際の扱い方は、多段構造または、多次元構造といえる。処理が完結した業務シナリオは再利用が可能であり、また、互いに独立したシナリオ間において上下関係は存在しない。互いに直接関係するときに、使う側なのか使われる側なのかでその処理においての上下関係があるだけであり、多次元構造によるこれらの業務シナリオの再利用性は多次元にわたる。よって、これらの形態において、業務シナリオは次元が互いに変わる多次元シナリオということができる。
【００３９】
また、図５に示すように、業務シナリオには、単機能処理の処理結果に応じて、次に実行すべき単機能処理を決定するための制御文を含めることができる。制御文としては、例えば、分岐、ループ、並列処理等が考えられる。
また、ＸＭＬのような簡易な言語を用いて業務シナリオを記述していることにより、経路、プログラム、単シナリオ、他の業務シナリオ等の選択実行指示について、変更、追加及び削除を容易に行うことができる。指示される側のシナリオや単機能についても同様なことがいえる。単機能としてのプログラムは、あくまでも単機能としての最小限プログラムであるため、変更等によるシステム全体としての影響範囲を小さくすることができる。
【００４０】
［機能構成］
次に、サーバ２０の機能構成について説明する。サーバ２０が備える上述したハードウェア及びソフトウェアにより、図６に示す機能部が実現される。
【００４１】
同図に示す業務実行受付部２１は、業務管理システム端末１や他のサーバ２０から、業務処理の実行命令を受け付ける。
業務シナリオ解析部２２は、業務実行受付部２１が受け付けた業務処理を行うための業務シナリオを記憶部より取得し、当該取得した業務シナリオを解析する。なお、業務シナリオ解析部２２は、記憶部から取得した業務シナリオを解析する以外に、他のサーバ２０から送信されてきた業務シナリオを解析する場合もあるし、また、業務処理の実行命令に応じて新たに生成した業務シナリオを解析する場合もある。
【００４２】
業務処理実行部２３は実行命令を受けた業務処理を実行する。具体的には、業務処理実行部２３は、業務シナリオ解析部２２が業務シナリオを解析した結果に基づいて、業務処理を実行すべきサーバ２０に業務処理の実行命令を行う。業務処理を実行すべきサーバ２０は、複数の他のサーバ２０である場合も自サーバ２０である場合もある。業務処理を実行すべきサーバ２０の決定方法としては、例えば、業務シナリオに記述されている内容や、サーバ２０が予め保持している経路指定情報や、受信した実行命令に含まれる情報から決定される。
【００４３】
ここで、業務管理システム２は、Ｄ３Ａのアーキテクチャをベースに、Ｄ３Ａシナリオの部分を業務の手順レベルに発展させたものである。業務管理システム２は、業務シナリオを解析エンジンで解析させ、実行すべきプログラムを選択し、実行命令をだす、という基本的な処理方式の基に構築される。この基本的な処理方式を実現するためのシステム構成には２つの構成がある。
【００４４】
第１の構成は、Ｄ３Ａとは異なる構成である。具体的には、業務管理システム２において使用する業務シナリオが複数あっても、ある１つのサーバ２０の業務シナリオ解析部２２が業務シナリオを解析し、順次、実行させるべきプログラムや業務シナリオを選択及び実行し、処理結果をシナリオのデータ格納部分に格納するという処理を繰り返す。このように、第１の構成は、はじめに担当した解析エンジンが、業務処理が完了するまで全てを担うシステム構成である。
【００４５】
この第１の構成においては、サーバ２０の業務処理実行部２３は、業務シナリオに記述された実行順序に従って、単機能処理の実行命令を当該単機能処理を実行すべきサーバ２０に対して順次送信することとなる。
図７を参照しながら、第１の構成における業務処理の実行手順を説明する。
まず、サーバ２０の業務実行受付部２１は、業務管理システム端末１から業務処理の実行命令を受け付ける（ステップＳ１１）。
【００４６】
業務シナリオ解析部２２は、業務実行受付部２１により受け付けられた業務処理を行うための業務シナリオを解析する（ステップＳ１２）。
業務処理実行部２３は、業務シナリオに記述された実行順序に従って、単機能処理の実行命令を、当該単機能処理を実行すべきサーバ２０に対して送信する（ステップＳ１４）。
【００４７】
業務処理実行部２３は、業務シナリオに記述された単機能処理分全て実行命令を送信し終わるまで（ステップＳ１３；Ｙｅｓ）、単機能処理の実行命令の送信を繰り返す。
次に、図４及び図７を参照しながら、第１の構成において、サーバ２０が業務管理システム端末１から、業務シナリオＡに対応する業務処理Ａの実行命令を受けた時の動作について説明する。
【００４８】
サーバ２０の業務実行受付部２１が業務処理Ａの実行命令を受け付けると（ステップＳ１１）、業務シナリオ解析部２２は、業務実行受付部２１が受け付けた業務処理Ａを行うための業務シナリオＡを記憶部より読み出して、業務シナリオＡの記述内容を解析する（ステップＳ１２）。
業務処理実行部２３は、業務シナリオＡに記述された実行順序に従って、まず、手順１のプログラムＡの実行命令を、当該処理を実行すべきサーバ２０に対して送信する（ステップＳ１４）。
【００４９】
業務処理実行部２３は、プログラムＡの実行処理終了の応答メッセージを受信すると、次に実行すべき手順２の処理が存在するため（ステップＳ１３；Ｎｏ）、手順２の単シナリオＡの実行命令を、当該単機能処理を実行すべきサーバ２０に対して送信する（ステップＳ１４）。業務処理実行部２３は、単シナリオＡの実行処理終了の応答メッセージを受信すると、次に実行すべき手順３の処理が存在するため（ステップＳ１３；Ｎｏ）、手順３の業務シナリオＢの実行命令を、当該処理を実行すべきサーバ２０に対して送信する（ステップＳ１４）。
【００５０】
業務処理実行部２３は、以上のようにして、業務シナリオに記述された手順ｎ個の単機能処理について全て実行命令を送信し終わるまで（ステップＳ１３；Ｙｅｓ）、単機能処理の実行命令の送信を繰り返す。
次に、第２の構成について説明する。第２の構成は、Ｄ３Ａと同様な構成であり、業務管理システム２で使用する業務シナリオを分散データ駆動型にした構成である。すなわち、分散配置されたサーバ２０の業務シナリオ解析部２２が、他のサーバ２０から受け取った業務シナリオを解析し、業務処理実行部２３が、解析結果に基づいて自サーバ２０内のプログラムを起動して自サーバ２０が担当する処理を行い、処理結果を業務シナリオのデータ格納部分に格納した後、当該業務シナリオを次の処理を行うべきサーバ２０（シナリオ解析エンジン）に渡すというシステム構成である。
【００５１】
この第２の構成では、サーバ２０の業務処理実行部２３は、次の単機能処理の実行命令を含み、かつ、ある単機能処理の処理結果を格納した業務シナリオを、当該次の単機能処理を実行すべきサーバ２０に対して送信することとなる。
第２の構成における業務処理の実行手順を、図８を参照しながら説明する。まず、あるサーバ２０の業務処理実行部２３は、ある単機能処理の実行命令を含んだ業務シナリオを、当該ある単機能処理を実行すべきサーバ２０に対して送信する。
【００５２】
ある単機能処理を実行すべきサーバ２０の業務実行受付部２１が、ある単機能処理の実行命令を含んだ業務シナリオを受信すると（ステップＳ２１）、業務シナリオ解析部２２が、受信した業務シナリオを解析する（ステップＳ２２）。業務処理実行部２３は、実行命令を受けた単機能処理を実行し、実行結果を業務シナリオに格納する。業務処理実行部２３は、次の単機能処理を実行すべきサーバ２０に対して、次の単機能処理の実行命令を含んだ業務シナリオを送信する（ステップＳ２３）。
【００５３】
次に、図４及び図８を参照しながら、サーバ２０が、業務シナリオＡに対応する業務処理Ａの実行命令を受け付けた時の動作について説明する。
サーバ２０の業務実行受付部２１が、業務管理システム端末１から業務処理Ａの実行命令を受け付けると（ステップＳ２１）、業務シナリオ解析部２２が、業務処理Ａを処理するための業務シナリオＡを記憶部より読み出して解析する（ステップＳ２２）。業務処理実行部２３は、解析結果に基づいて、手順１を実行すべきサーバ２０に対して、手順１の実行命令を含んだ業務シナリオＡを送信する（ステップＳ２３）。
【００５４】
手順１を実行すべきサーバ２０の業務実行受付部２１が、手順１の実行命令を含んだ業務シナリオＡを受信すると（ステップＳ２１）、業務シナリオ解析部２２が業務シナリオＡを解析する（ステップＳ２２）。業務処理実行部２３は、実行命令を受けた手順１のプログラムＡを記憶部より読み出して実行する。そして、業務処理実行部２３は、業務シナリオＡにプログラムＡの実行結果を格納して、次の手順２を実行すべきサーバ２０に対して、次の手順２の実行命令を含んだ業務シナリオＡを送信する（ステップＳ２３）。
【００５５】
手順２を実行すべきサーバ２０の業務実行受付部２１が、手順２の実行命令を含んだ業務シナリオＡを受信すると（ステップＳ２１）、業務シナリオ解析部２２は、受信した業務シナリオＡを解析する（ステップＳ２２）。業務処理実行部２３は、実行命令を受けた手順２の単シナリオＡを記憶部より読み出して解析する。そして、業務処理実行部２３は、単シナリオＡに記述されたプログラムを順次自サーバ２０又は他サーバ２０で実行する。業務処理実行部２３は、単シナリオＡに記述されたプログラムの処理が全て終了した場合に、処理結果を業務シナリオＡに格納する。業務処理実行部２３は、次の手順３の単機能処理を実行すべきサーバ２０に対して、次の手順３の実行命令を含んだ業務シナリオＡを送信する（ステップＳ２３）。同様に、手順３、・・・、手順ｎを実行すべきサーバ２０も、手順２を実行すべきサーバ２０と同じ処理手順を繰り返すことにより、業務処理Ａを遂行する。
【００５６】
次に、図６に示す実行制御部２５について説明する。実行制御部２５は、業務処理の実行を制御する。制御のひとつとして、実行制御部２５は、業務シナリオに記述されているグループ分けに基づいて、業務処理の実行制御を行う。
ここで、業務シナリオに記述された単機能処理は、階層的なグループに分類することが可能である。階層的なグループ分けとは、例えば、業務シナリオに記述された単位機能処理のグループを規定し、また、そのグループ内におけるグループを規定するといったグループ分けをいう。
【００５７】
図９には業務シナリオにおけるグループ分けの一例を示す。同図に示すフェーズ番号と作業項目番号とは実行順序に対応し、「警報確認」、「系構成確認」等の作業項目は単機能処理に対応する。同図に示すように作業項目はフェーズでグループ化されている。
また、フェーズというグループを多次元構造化することも可能である。図９に示す例においては、作業項目１の作業項目定義に部品名が記述されており、業務解析エンジンによって当該部品名に対応するプログラムが呼び出される仕組みとなっている。このように、作業項目定義の中に、部品名、プログラム名、業務シナリオ名、又は、単シナリオ名を記述することで、多次元構造化したグループを作成することができ、シナリオやプログラムの再利用が可能となる。
【００５８】
また、実行制御部２５は、実行中の業務処理の中断と再試行とを制御する。
具体的には、実行制御部２５は、業務処理を実行している途中で、外部からの指示や故障を検知したときに、業務処理の中断点についての情報をメモリに保持した上で、業務処理を中断する。このように中断点をメモリに保持しておくことで、実行制御部２５は業務シナリオによる業務処理がどこまで進んだかを把握することができ、中断点からの再試行が可能となる。また、業務シナリオが通過すべきプログラムに関するハード故障を含む故障が起こったことを検知すると、実行制御部２５は、業務シナリオによる業務処理を中断し、中断点を保持する。故障修理等によりシステムが正常に戻ったことを検知すると、実行制御部２５は、中断点から業務処理を再試行する。
【００５９】
なお、実行制御部２５は、再試行の際には、ユーザ入力等によって外部より指示された箇所から、中断された業務処理を再試行することも可能である。このように、再試行の際に、実行する手順やどの箇所から業務処理を開始するかはユーザが任意に指定することが可能である。
また、図５に示すように、業務シナリオの中に制御文が記述されている場合には、実行制御部２５は、当該制御文に従って業務処理の実行制御を行う。例えば、実行制御部２５は、ある手順において単機能処理を実行することにより得られた結果を分析し、次に行うべき単機能処理を選択する。これにより、分岐、ループ、並列処理等の各種処理を制御することができ、業務シナリオ自体を動的に変化させることができる。また、実行制御部２５は、業務処理の即時起動も制御し、システム操作性としての柔軟性も確保する。このように、実行制御部２５により操作の柔軟性を確保することができるため、ユーザ主導の業務が可能である。
【００６０】
これらの業務シナリオは、あらかじめ生成して記憶部に記憶しておく他に、ユーザが端末を用いて編集することができる。ユーザが業務シナリオを編集する場合には、業務管理システム２の記憶部に、業務シナリオのデフォルトフォーマットをあらかじめ記憶させておく。端末からのユーザ指示により、デフォルトフォーマットが端末に表示される。ユーザが、表示されたデフォルトフォーマットの中の指定すべき部分を埋めることにより、業務シナリオを編集する。ユーザが指定可能な情報の一例としては、発動日時、終了日時等の基本的な情報や、業務シナリオ内部のグループ及び単機能処理各々についての処理ステータスである。処理ステータスとしては、自動進行、確認、スキップ等が存在する。図１０には、業務シナリオへの処理ステータス設定の一例を示す。同図に示すように、処理ステータスは業務シナリオ内のフェーズや作業項目毎に設定されている。また、Ｄ３Ａのアーキテクチャに従って、業務シナリオ編集専用のクライアント端末も用意してもよい。
【００６１】
このように、デフォルトで用意されているシナリオが、業務シナリオ作成の補助となる。また、業務シナリオに従った業務処理の起動時刻の指定や、業務シナリオ内部に記述されている手順（グループ、単機能処理）の処理ステータス、制御文等を記述し、記述内容を柔軟に変えることができるようにすることで、一連の業務処理について柔軟性を確保することができる。
【００６２】
次に、図６に示す業務キーワード記憶部２６について説明する。業務キーワード記憶部２６は、ハードディスク装置等の記憶部に、業務キーワードと業務シナリオとを対応付けて記憶する。業務キーワード記憶部２６により記憶される情報は、業務シナリオの生成に用いられる。業務キーワードと業務シナリオとの対応付け方法としては、１対１の対応付けであっても、多対１の対応付けであってもよい。
【００６３】
業務シナリオ生成部２７は、業務シナリオを生成する。具体的な業務シナリオの生成方法としては、業務シナリオ生成部２７は、ユーザ入力等により、外部から業務キーワードが入力された場合に、当該入力された業務キーワードと一致する業務キーワードと対応付けられて業務キーワード記憶部２６に記憶されている業務シナリオを取得する。取得された業務シナリオが複数存在する場合には、業務シナリオ生成部２７は、複数の業務シナリオで構成される一連の業務処理手順を示す情報を生成する。
【００６４】
このように、業務シナリオ生成部２７は、自動的に業務シナリオを組み合わせた一連の業務処理手順を示す情報を生成することができ、業務管理システム２はこの情報を用いて業務処理を行うことができるため、複雑な多制御の業務処理についての業務効率化が可能となる。
例えば、個々のＮＥ４に投入する局データを、コマンドによるＮＥへのデータ設定命令と捕らえることができるようなＮＥ４の場合、個々データの設定方法は大幅に簡素化されているが、複数種かつ複数のデータをＮＥ４に設定する場合には大きな稼動を要することになる。このときに業務シナリオを使用することで、容易に複数種かつ複数のデータを容易にＮＥ４に設定することが可能となる。
【００６５】
局データ投入業務に関する業務シナリオ生成処理について、図１１を参照しながら説明する。まず、ユーザは、業務管理システム端末１を操作して、設定したい局データを定義するファイル（ここでは、キーワードＢ、キーワードＡ及びキーワードＣが記述されたファイル）を作成する（ステップＳ３１）。この作成処理は、事前に局データを作成するために使用する局データ作成システムを使用する必要がなく、非常に簡素なものになる。
【００６６】
業務管理システム２の業務実行受付部２１は、ユーザの指示によりそのファイルを読み込む（ステップＳ３２）。業務管理システム２の業務キーワード記憶部２６では、局データの種類によって、前後処理や前後処理から得られる結果の判定ロジックをあらかじめ業務シナリオとして記憶している。業務シナリオ生成部２７は、業務キーワード記憶部２６に記憶されている業務シナリオを含んだ、一連の業務シナリオを自動生成する（ステップＳ３３）。ここにおいても業務シナリオの多次元構造化の有効性が得られる。
【００６７】
ここで、複数の局データを投入するときには、個々の局データにより生成される業務シナリオを組み合わせたものが一連の業務シナリオ（一連の業務処理手順を示す情報）になる。また、ひとつの局データを投入する場合には、ひとつの局データから生成される業務シナリオそのものが、一連の業務処理手順を示す情報となる。
以上説明したように、業務管理システム２は、業務シナリオに基づいて業務処理を順次自動的に実行することができ、複数の手順を有する業務処理を効率的に実行することができる。特に、業務管理システム２は、ユーザが業務管理システム２に対して行う作業のうち、業務フロー化可能な業務の効率化を行うことができる。また、業務シナリオに多次元構造をとることにより、多次元構造の業務フローを実現することができ、業務シナリオ間の再利用性を最大限に生かすことができる。このように、本発明により、分散コンピューティングによるハードウェア構成の柔軟性とプログラム構造の柔軟性とを併せ持つ業務管理システム２を構築することができる。
【００６８】
なお、以上の説明では、業務シナリオをＸＭＬで記述し、業務管理システム２を構成する複数のサーバ２０にはＩＡサーバ、サーバ２０間にはギガビットイーサネット（登録商標）を使用する例で説明したが、業務管理システム２に使用するプログラム言語、通信装置、及び、ネットワーク環境は、Ｄ３Ａの思想、形態をベースにできればよく、その範囲においては同様の効果が得られる。
【００６９】
また、本発明を利用可能な分野は通信網オペレーションの業務管理システム２にとどまらない。Ｄ３Ａは多様なシステムに対応できる基盤アーキテクチャであり、その基盤の上での業務シナリオの多次元構造化は共通的な思想となる。
なお、Ｄ３Ａをベースとする以外に、Ｄ３Ａ基盤を業務シナリオ解析エンジンとして使用することも可能である。
【産業上の利用可能性】
【００７０】
複数の手順を有する業務処理全般に利用することができる。特に、パターン化され、かつ、複数の同一手順を有する業務処理についての効率化を図ることができる。例えば、通信網オペレーションの業務管理システムにおけるファイル更新、局データ更新、ファームダウンロード、マクロ機能等の業務処理が存在する。
【図面の簡単な説明】
【００７１】
【図１】本発明の実施の形態に係る業務管理システムの構成を示す図である。
【図２】同実施の形態に係るサーバが備えるソフトウェア環境の一例を説明するための図である。
【図３】同実施の形態に係る分散データ駆動型アーキテクチャを説明するための図である。
【図４】同実施の形態に係る業務シナリオの多次元構造化の概念を示す図である。
【図５】同実施の形態に係る業務シナリオのさまざまな制御文挿入例を示す図である。
【図６】同実施の形態に係るサーバの機能構成を示す図である。
【図７】同実施の形態に係る業務処理の実行手順の一例を示すフローチャートである。
【図８】同実施の形態に係る業務処理の実行手順の一例を示すフローチャートである。
【図９】同実施の形態に係る業務シナリオのグループ分けの一例を示す図である。
【図１０】同実施の形態に係る業務シナリオへの処理ステータス設定の一例を示す図である。
【図１１】同実施の形態に係る局データ投入業務に関する業務シナリオ自動生成処理を説明するための図である。
【図１２】従来のファイル更新システムとＮＥとを含んだシステムの構成図である。
【符号の説明】
【００７２】
１ 業務管理システム端末
２ 業務管理システム
３ ＮＥ監視制御装置
４ ＮＥ（ネットワークエレメント）
２０ サーバ
２１ 業務実行受付部
２２ 業務シナリオ解析部
２３ 業務処理実行部
２５ 実行制御部
２６ 業務キーワード記憶部
２７ 業務シナリオ生成部
１００ ファイル更新操作端末
２００ ファイル更新装置
３００ ＮＥ監視制御装置
４００ ＮＥ
５００ ファイル更新システム
【技術分野】
【０００１】
本発明は、業務処理を効率的に行う業務管理システム、及び、業務処理実行方法に関する。
【背景技術】
【０００２】
従来の通信網に存在するネットワークエレメント（Network Element、以降、「ＮＥ」という）等のオペレーションにおいて、ファイル更新を始めとする業務フロー化が可能な業務をシステム化するための業務管理技術のひとつとして、特許文献１に記載された技術が知られている。特許文献１に記載されているファイル更新方法では、ファイル更新の手順をコマンド投入処理とコマンド応答判定処理とに分離し、これらの処理を指定するステップと指定された処理の実行を制御するステップとを有することに代表される特徴を持っている。
【０００３】
また、コマンド投入処理等で投入される部品と称されるプログラムの一部は変更容易な簡易言語で記述され、柔軟性を持たせている。また、ファイル更新の業務を、作業項目に当たる部品と、部品を指定する手順に当たるシナリオとで成立させることでも柔軟性も持たせている。このように、特許文献１においては、部品をシナリオで指定することで、変化に柔軟なファイル更新方法を実現している。
【０００４】
図１２は、特許文献１に開示されているシステムの構成図である。ファイル更新操作端末１００、及び、ファイル更新装置２００は汎用的なコンピュータである。これらの装置において上記の技術に従った専用のプログラムを動作させることにより、ファイル更新システム５００は、ＮＥ監視制御装置３００を介してＮＥ４００と通信回線で接続し、ＮＥ４００に対するファイル更新の業務機能を実現させている。
【０００５】
また、シナリオを利用した他のシステムとして、特許文献２には、プログラムの実行順序が記述されたシナリオを用いてサービスを実行するサービス実行制御システムが開示されている。
【特許文献１】特開２００３−２８９３８１号公報
【特許文献２】特開平９−１４６７６５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
特許文献１に記載の技術においては、プログラム構造的に柔軟性を持たせる工夫を行っている。しかし、特許文献１に記載の技術は、単一マシンを用いた集中型システムの中でプログラムを動作させることを念頭に置いた技術である。同様に、特許文献２に記載の技術も集中型システムを前提としており、シナリオには単一装置内のプログラム格納部に格納されているプログラムのみが記述されている。
【０００７】
現在、複数機器をネットワークに接続して構成する分散システムが提案され、開発が盛んに行われている。分散システムにおいては、安価なハードウェアを用いることができることや、たくさんのマシンを用いることによってシステムの大規模故障が発生しないといったメリットがある。このように、ハードウェア構成に柔軟性を持つ分散環境において、ファイル更新を初めとする、業務フロー化が可能な業務を対象とした業務管理システムの構築が要求されている。
【０００８】
特許文献１においてはＮＥのファイル更新について触れているが、通信網のオペレーション業務においては、ファイル更新に限らず、業務フロー化できる業務が複数存在する。これらも含め、効率的なシステム構築が課題である。
その業務の中のひとつとして、個々のＮＥが正確に動作するために必要なデータ（以降、「局データ」という）をＮＥに設定する方法についての課題がある。
【０００９】
局データをＮＥに設定する場合には、通常は、あらかじめ作成した局データファイルをＮＥに投入する。ただし、このようにあらかじめ局データファイルを作成する場合には、局データを作成するまでにいくつかの工程が必要であり、効率的でない場合もある。しかし、現状ではこのあらかじめ作成しておくという考え方に基づいたＮＥ仕様が多数である。
【００１０】
一方、局データ一つ一つをＮＥへのデータ設定命令と捕らえることで、いくつかの局データ作成工程やシステムを縮小し、必要最小限の命令のみを作成することで、実質的に必要なデータをＮＥへ投入することができるＮＥ仕様も存在する。このＮＥ仕様を用いた場合、先に触れた一括投入形式の局データを作成するまでのいくつかの工程は効率化される。その代わりに、その局データが複数種あり、また複数種を同じタイミングでシーケンシャルに、またはパラレルに設定するような場合、これらのデータが重要なデータであるために、ＮＥへの投入前後でデータ種別毎に異なる確認作業が必要となるという設定上の課題が発生する。このように、データを個々に投入する業務において、投入前後でデータ種別毎に異なる確認作業があり、かつ、複数かつ複数種の投入すべき局データがあるような手順の多い業務である場合には、業務処理の効率化が必要である。
【００１１】
本発明は以上のような課題に鑑みてなされたものであり、複数の手順を有する業務処理を効率的に実行する業務管理システム、及び、業務処理実行方法を提供することを目的とする。
【課題を解決するための手段】
【００１２】
上記課題を解決するために、請求項１に記載の発明は、複数の通信装置を含む分散型の業務管理システムにおいて、前記通信装置は、業務処理の実行命令を受け付ける業務実行受付手段と、前記業務実行受付手段により受け付けられた業務処理を行うための単機能処理と該単機能処理の実行順序とが記述された業務シナリオデータを解析する業務シナリオ解析手段と、前記業務シナリオ解析手段による解析結果に基づいて、前記業務処理を実行すべき通信装置に対して該業務処理の実行命令を行う業務処理実行手段とを備えることを特徴とする業務管理システムを提供する。
【００１３】
この構成によれば、業務管理システムは、業務シナリオデータの解析結果に基づいて、業務処理を実行すべき通信装置に対して業務処理の実行命令を行うため、実行命令を受けた通信装置が自動的に業務処理を実行することができ、複数の手順を有する業務処理であっても効率的に業務処理を遂行することができる。
請求項２に記載の発明は、請求項１に記載の業務管理システムにおいて、前記業務シナリオデータには、前記単機能処理を表す情報として、実行すべきプログラムと、解析すべき他の業務シナリオデータと、の少なくとも１を識別するための情報が記述されていることを特徴とする。
【００１４】
この構成によれば、業務シナリオデータに、単機能処理を表す情報として、プログラムを識別するための情報のみならず、他の業務シナリオデータを識別するための情報も記述することができ、複雑な手順の業務処理にも柔軟に対応することができる。このような多次元構造の業務シナリオデータを利用して多次元構造の業務フローを実現し、業務シナリオデータ間の再利用性を最大限に生かした業務管理システムを構築することができる。
【００１５】
請求項３に記載の発明は、請求項１又は２に記載の業務管理システムにおいて、前記業務処理実行手段は、前記業務シナリオデータに記述された実行順序に従って、前記単機能処理の実行命令を、該単機能処理を実行すべき通信装置に対して順次送信することを特徴とする。
この構成によれば、１つの通信装置が、業務シナリオデータに記述された実行順序に従って、単機能処理の実行命令を該単機能処理を実行すべき通信装置に対して順次送信するため、複数の手順を有する業務処理であっても、複数の通信装置において効率的に業務処理を行うことができる。
【００１６】
請求項４に記載の発明は、請求項１から３のいずれか１項に記載の業務管理システムにおいて、前記業務処理実行手段は、前記単機能処理の実行命令を含んだ前記業務シナリオデータを、該単機能処理を実行すべき通信装置に対して送信することを特徴とする。
この構成によれば、業務シナリオデータが業務処理の実行順序に従って通信装置間を巡回し、業務シナリオを受信した通信装置が単機能処理の実行制御を行うことができる。これにより、業務管理システム内における業務処理の負荷分散を行ことができ、複数の手順を有する業務処理であっても、複数の通信装置において効率的に業務処理を行うことができる。
【００１７】
請求項５に記載の発明は、請求項１から４のいずれか１項に記載の業務管理システムにおいて、前記業務処理の実行制御を行う実行制御手段をさらに備え、
前記実行制御手段は、前記業務処理の中断と再試行とを制御することを特徴とする。
この構成によれば、業務管理システムは、業務処理の実行を柔軟に制御することができる。
【００１８】
請求項６に記載の発明は、請求項５に記載の業務管理システムにおいて、前記実行制御手段は、中断された業務処理を、外部より指示された箇所から再試行することを特徴とする。
この構成によれば、業務管理システムは、中断された業務処理を外部からの指示により任意の箇所から再試行することができ、業務処理の実行を柔軟に制御し、効率的に業務処理を行うことができる。
【００１９】
請求項７に記載の発明は、請求項５又は６に記載の業務管理システムにおいて、前記業務シナリオデータには、階層的なグループに分類された単機能処理が記述されており、前記実行制御手段は、前記業務シナリオデータに記述されているグループ分けに基づいて、前記業務処理の実行制御を行うことを特徴とする。
この構成によれば、業務管理システムは、単機能処理をグループ毎に管理することができ、グループ毎に各種操作や設定を行うことにより、業務処理の実行制御を行い易い。また、階層的にグループ化することにより、柔軟性のある多次元の業務フローを容易に実現することができる。
【００２０】
請求項８に記載の発明は、請求項５から７のいずれか１項に記載の業務管理システムにおいて、前記業務シナリオデータには、前記単機能処理の実行結果に基づいて次に実行すべき単機能処理を決定するための制御文が記述されており、前記実行制御手段は、前記業務シナリオデータに記述されている制御文に従って前記業務処理の実行制御を行うことを特徴とする。
【００２１】
この構成によれば、業務管理システムは、制御文に従って柔軟に業務処理の実行手順を制御することができる。
請求項９に記載の発明は、請求項１から８のいずれか１項に記載の業務管理システムにおいて、前記業務シナリオデータと業務キーワードとを対応付けて記憶する業務キーワード記憶手段と、外部からの指示に対応する業務キーワードと対応付けられて前記業務キーワード記憶手段に記憶されている業務シナリオデータに基づいて、１又は複数の業務シナリオデータを含む一連の業務処理手順を表す情報を生成する業務シナリオ生成部とを備えることを特徴とする。
【００２２】
この構成によれば、外部からの指示に対応する業務キーワードから容易に一連の業務処理手順を表す情報を生成することができ、多くの制御を必要とする業務処理についての業務効率化が可能となる。
請求項１０に記載の発明は、複数の通信装置を含む分散型の業務管理システムが行う業務処理実行方法において、業務処理の実行命令を受け付ける業務実行受付ステップと、前記業務実行受付ステップにおいて受け付けられた業務処理を行うための単機能処理と該単機能処理の実行順序とが記述された業務シナリオデータを解析する業務シナリオ解析ステップと、前記業務シナリオ解析ステップにおける解析結果に基づいて、前記業務処理を実行すべき通信装置に対して該業務処理の実行命令を行う業務処理実行ステップとを有することを特徴とする業務処理実行方法を提供する。
この方法による作用、効果は、請求項１と同様である。
【発明の効果】
【００２３】
以上のように本発明によれば、業務管理システムは、業務シナリオデータの解析結果に基づいて、業務処理を実行すべき通信装置に対して業務処理の実行命令を行うため、実行命令を受けた通信装置が自動的に業務処理を実行することができ、複数の手順を有する業務処理であっても効率的に業務処理を遂行することができる。
【発明を実施するための最良の形態】
【００２４】
次に、図面を参照しながら、本発明を実施するための実施の形態について説明する。なお、以下の説明において参照する各図においては、他の図と同等部分に同一符号が付されている。
図１は、本発明の実施の形態に係る業務管理システム２の構成を示す図である。同図に示すように、業務管理システム２は、ユーザ操作用の通信端末である業務管理システム端末１と、交換機等のネットワーク設備であるＮＥ４と、ＮＥ４を監視及び制御するＮＥ監視制御装置３と、に通信ネットワークを介して接続されている。
【００２５】
次に、業務管理システム２の構成について説明する。業務管理システム２は分散型のシステムであり、分散配備された複数のサーバ２０により構成されている。サーバ２０は、例えば、小型ＩＡサーバである。サーバ２０同士は、ギガビットイーサネット（登録商標）等の通信ネットワークで接続されている。業務管理システム２は、通信網オペレーションに関わる各種業務を管理及び実行する。
【００２６】
サーバ２０は、ハードウェア構成として、図示せぬＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）とＲＡＭ（Random Access Memory）とハードディスク装置を含む記憶部、及び、通信ネットワークを介してデータの授受を制御する通信インターフェースとを備えている。
サーバ２０の記憶部には、各種ソフトウェアが記憶されている。各種ソフトウェアには、ＯＳ（Operating System）と、Ｊａｖａ（登録商標）実行環境を構築するためのソフトウェアと、業務シナリオデータ（以下「業務シナリオ」という）を解析するためのプログラムと、Ｄ３Ａ（Distributed Data Driven Architecture；分散型データ駆動アーキテクチャ）シナリオデータ（以下「Ｄ３Ａシナリオ」という）を解析するためのプログラムとが含まれている。
【００２７】
図２は、サーバ２０の記憶部に記憶されるソフトウェアやＣＰＵの動作により実現されるソフトウェア環境の一例を説明するための図である。
同図に示すように、ソフトウェア環境は、Ｄ３Ａ層と業務アプリケーション層とで構成されている。Ｄ３Ａ層は、Ｊａｖａ（登録商標）ＶＭと、当該Ｊａｖａ（登録商標）ＶＭ上で動作するＤ３Ａ基盤と、Ｄ３Ａシナリオとを含んで構成される。Ｄ３Ａ基盤は、Ｄ３Ａシナリオを解析し、解析結果に従った処理の実行を制御する。Ｄ３Ａ基盤はＪａｖａ（登録商標）でコーディングされており、Ｄ３ＡシナリオはＸＭＬ（eXtensible Markup Language）で記述されている。
【００２８】
ここで、Ｄ３Ａシナリオとは、システム内部の処理命令の手順が記述され、処理命令を与えるための記述と、処理結果として返されたデータ格納場所とをもつデータである。また、Ｄ３Ａ基盤とは、Ｄ３Ａシナリオを解析し駆動させる役目を持つエンジンプログラムである。
このように、サーバ２０のソフトウェア環境は、分散システム用に開発された分散型データ駆動型アーキテクチャ（Ｄ３Ａ）をベースとする。集中型システムが、単一マシンにおいてメインプログラムを動作させ、そこから単機能プロセスを呼び出して処理を実行していくのに対し、Ｄ３Ａでは、図３に示すように、従来のメインプログラムに変わる部分となるシナリオが単機能プロセスを経由して処理を実行していく。
【００２９】
Ｄ３Ａにおいては、Ｄ３Ａシナリオが処理を実行するのでははく、ＸＭＬで書かれたＤ３Ａシナリオの実行条件をＤ３Ａ基盤が解析し、単機能プロセスに指示を出す。単機能プロセスで処理を行った結果はＤ３Ａシナリオにデータとして格納され、次の単機能プロセスにＤ３Ａシナリオが駆動される。Ｄ３Ａシナリオには単機能プロセスを経由する順番が記述されており、ネットワークで接続され分散配備されたマシン間を経由していくことも可能である。指定された単機能プロセスを全て経由し終わると一連の処理が完了したことになる。シナリオによる駆動動作の変更は、単機能プロセスがすでに存在していれば、Ｄ３Ａシナリオに記述する経路を変更すればよいし、単機能プロセスが存在しない、または、既存にある単機能プロセスを変更するような場合には、その単機能プロセスを実現するためのプログラムを適当なマシンに配備し、経路を変更することで対応可能である。ユーザの指示により、Ｄ３Ａで構築されたシステムに命令が送られると、システムが命令を受け取り、命令を解析してＤ３Ａシナリオを生成し動作することになる。
【００３０】
また、サーバ２０が備えるソフトウェア環境においては、Ｄ３Ａ層の上位層として、図２に示すように業務アプリケーション層が設けられている。業務アプリケーション層は、Ｊａｖａ（登録商標）ＶＭと、当該Ｊａｖａ（登録商標）ＶＭ上で動作する業務解析エンジンと、業務シナリオとを含んで構成される。業務解析エンジンは、業務シナリオの記述を解析し、解析結果に従って処理を実行するためのプログラムである。業務解析エンジンはＪａｖａ（登録商標）でコーディングされており、業務シナリオはＸＭＬで記述されている。
【００３１】
Ｄ３Ａ層を内部処理的なシナリオとするならば、業務アプリケーション層は、Ｄ３Ａをベースにしながら、上位層アーキテクチャとして、シナリオと個々の処理プログラムとを組み合わせた構造をとる。
ここで、システムの内部処理で使用されるＤ３Ａシナリオと、業務管理システム２において業務効率化のために使用される業務シナリオとの違いを整理する。両者ともＸＭＬで記述されたテキストベースの定義ファイルであり、技術的には共通のものであるが、定義体が異なっている。従って、Ｄ３Ａ基盤は業務シナリオを解析することができない。このため、本実施形態に係る業務管理システム２においては、Ｄ３Ａ基盤とは別に、上位アプリケーションとしての業務解析エンジンを設ける構成とした。なお、このような業務解析エンジンを設ける構成は一例であり、例えば、Ｄ３Ａ基盤が理解可能な定義体で業務シナリオを作成してもよいし、または、Ｄ３Ａ基盤を改造して、業務シナリオを理解できるようにしてもよい。
【００３２】
このように、Ｄ３Ａシナリオと業務シナリオとは同一の技術を利用した言語を用いて記述されているため、システム変更、構築上の柔軟性、及び、選択性を確保することができる。なお、本実施形態においては、ソフトウェア環境をＤ３Ａ層と業務アプリケーション層との２段階に構築したが、このような関係の層を複数段階に構築することもできる。段階数はシナリオと解析エンジンの開発の仕方による。
【００３３】
［業務シナリオ］
次に、業務シナリオについて説明する。業務シナリオには業務処理の一連の手順が記述される。業務処理の手順は、業務処理の手順毎の処理内容である単機能処理と、当該単機能処理の実行順序とで表すことができる。
【００３４】
ここで、ユーザがシステムに対して命令を行い、ＸＭＬで記述されたＤ３Ａシナリオにより単機能としてのプログラムが次々と処理されて、処理が完結するまでをひとつの単シナリオとする。この単シナリオは、ユーザに取ってみれば、ひとつの単機能と捉えることもできる。本実施形態においては、人が行う業務手順を業務シナリオという形で定義し、業務シナリオに沿って、ユーザにとっての単機能つまり単シナリオを動作させる。
【００３５】
業務シナリオの記述においては、Ｄ３Ａシナリオの記述と異なり、実行すべきプログラム名の代わりに他の業務シナリオ名や単シナリオ名を記述することが可能である。すなわち、業務シナリオには、単機能処理を表す情報として、実行すべきプログラムと、解析すべき単シナリオと、解析すべき他の業務シナリオと、の少なくとも１を識別するための情報を記述することができる。従って、ある業務シナリオが単機能として扱う処理は、プログラムにより実行される処理と、Ｄ３Ａシナリオ（単シナリオ）を解析することにより実行される処理と、他の業務シナリオを解析することにより実行される処理を含むこととなる。
【００３６】
図４には、業務シナリオの記述例を示す。同図に示すように、業務シナリオＡには、単機能処理を表す情報として、実行すべきプログラム名と、解析すべき他の業務シナリオ名と、解析すべき単シナリオ名とが記述されている。また、単機能処理の実行順序を表す情報として、手順の番号が記述されている。
このように、業務シナリオに他の業務シナリオを記述することができるため、業務シナリオやプログラムの多段階の再利用が可能となり、すなわちこれが業務シナリオの多次元構造となる。
【００３７】
また、Ｄ３Ａシナリオは、単機能として主にプログラムを使用するが、業務シナリオは、他の業務シナリオが動作し他の単機能や単シナリオの連続実施により得られた結果を次の処理に渡すことが可能である。このため、業務シナリオを定義するときに、実際の単機能を意識することなく、３ＤＡシナリオや別の業務シナリオを単機能として扱って業務シナリオを定義することができる。そして、業務シナリオによって定義された業務処理の実行手順において、同一の処理についてはシナリオやプログラムを再利用可能であるという利点が得られる。このように、本実施形態に係る業務シナリオを用いることで、同一手順を複数回行うような業務において業務効率化を図ることが可能となる。
【００３８】
図４には２次元構造に近い例を示したが、実際の扱い方は、多段構造または、多次元構造といえる。処理が完結した業務シナリオは再利用が可能であり、また、互いに独立したシナリオ間において上下関係は存在しない。互いに直接関係するときに、使う側なのか使われる側なのかでその処理においての上下関係があるだけであり、多次元構造によるこれらの業務シナリオの再利用性は多次元にわたる。よって、これらの形態において、業務シナリオは次元が互いに変わる多次元シナリオということができる。
【００３９】
また、図５に示すように、業務シナリオには、単機能処理の処理結果に応じて、次に実行すべき単機能処理を決定するための制御文を含めることができる。制御文としては、例えば、分岐、ループ、並列処理等が考えられる。
また、ＸＭＬのような簡易な言語を用いて業務シナリオを記述していることにより、経路、プログラム、単シナリオ、他の業務シナリオ等の選択実行指示について、変更、追加及び削除を容易に行うことができる。指示される側のシナリオや単機能についても同様なことがいえる。単機能としてのプログラムは、あくまでも単機能としての最小限プログラムであるため、変更等によるシステム全体としての影響範囲を小さくすることができる。
【００４０】
［機能構成］
次に、サーバ２０の機能構成について説明する。サーバ２０が備える上述したハードウェア及びソフトウェアにより、図６に示す機能部が実現される。
【００４１】
同図に示す業務実行受付部２１は、業務管理システム端末１や他のサーバ２０から、業務処理の実行命令を受け付ける。
業務シナリオ解析部２２は、業務実行受付部２１が受け付けた業務処理を行うための業務シナリオを記憶部より取得し、当該取得した業務シナリオを解析する。なお、業務シナリオ解析部２２は、記憶部から取得した業務シナリオを解析する以外に、他のサーバ２０から送信されてきた業務シナリオを解析する場合もあるし、また、業務処理の実行命令に応じて新たに生成した業務シナリオを解析する場合もある。
【００４２】
業務処理実行部２３は実行命令を受けた業務処理を実行する。具体的には、業務処理実行部２３は、業務シナリオ解析部２２が業務シナリオを解析した結果に基づいて、業務処理を実行すべきサーバ２０に業務処理の実行命令を行う。業務処理を実行すべきサーバ２０は、複数の他のサーバ２０である場合も自サーバ２０である場合もある。業務処理を実行すべきサーバ２０の決定方法としては、例えば、業務シナリオに記述されている内容や、サーバ２０が予め保持している経路指定情報や、受信した実行命令に含まれる情報から決定される。
【００４３】
ここで、業務管理システム２は、Ｄ３Ａのアーキテクチャをベースに、Ｄ３Ａシナリオの部分を業務の手順レベルに発展させたものである。業務管理システム２は、業務シナリオを解析エンジンで解析させ、実行すべきプログラムを選択し、実行命令をだす、という基本的な処理方式の基に構築される。この基本的な処理方式を実現するためのシステム構成には２つの構成がある。
【００４４】
第１の構成は、Ｄ３Ａとは異なる構成である。具体的には、業務管理システム２において使用する業務シナリオが複数あっても、ある１つのサーバ２０の業務シナリオ解析部２２が業務シナリオを解析し、順次、実行させるべきプログラムや業務シナリオを選択及び実行し、処理結果をシナリオのデータ格納部分に格納するという処理を繰り返す。このように、第１の構成は、はじめに担当した解析エンジンが、業務処理が完了するまで全てを担うシステム構成である。
【００４５】
この第１の構成においては、サーバ２０の業務処理実行部２３は、業務シナリオに記述された実行順序に従って、単機能処理の実行命令を当該単機能処理を実行すべきサーバ２０に対して順次送信することとなる。
図７を参照しながら、第１の構成における業務処理の実行手順を説明する。
まず、サーバ２０の業務実行受付部２１は、業務管理システム端末１から業務処理の実行命令を受け付ける（ステップＳ１１）。
【００４６】
業務シナリオ解析部２２は、業務実行受付部２１により受け付けられた業務処理を行うための業務シナリオを解析する（ステップＳ１２）。
業務処理実行部２３は、業務シナリオに記述された実行順序に従って、単機能処理の実行命令を、当該単機能処理を実行すべきサーバ２０に対して送信する（ステップＳ１４）。
【００４７】
業務処理実行部２３は、業務シナリオに記述された単機能処理分全て実行命令を送信し終わるまで（ステップＳ１３；Ｙｅｓ）、単機能処理の実行命令の送信を繰り返す。
次に、図４及び図７を参照しながら、第１の構成において、サーバ２０が業務管理システム端末１から、業務シナリオＡに対応する業務処理Ａの実行命令を受けた時の動作について説明する。
【００４８】
サーバ２０の業務実行受付部２１が業務処理Ａの実行命令を受け付けると（ステップＳ１１）、業務シナリオ解析部２２は、業務実行受付部２１が受け付けた業務処理Ａを行うための業務シナリオＡを記憶部より読み出して、業務シナリオＡの記述内容を解析する（ステップＳ１２）。
業務処理実行部２３は、業務シナリオＡに記述された実行順序に従って、まず、手順１のプログラムＡの実行命令を、当該処理を実行すべきサーバ２０に対して送信する（ステップＳ１４）。
【００４９】
業務処理実行部２３は、プログラムＡの実行処理終了の応答メッセージを受信すると、次に実行すべき手順２の処理が存在するため（ステップＳ１３；Ｎｏ）、手順２の単シナリオＡの実行命令を、当該単機能処理を実行すべきサーバ２０に対して送信する（ステップＳ１４）。業務処理実行部２３は、単シナリオＡの実行処理終了の応答メッセージを受信すると、次に実行すべき手順３の処理が存在するため（ステップＳ１３；Ｎｏ）、手順３の業務シナリオＢの実行命令を、当該処理を実行すべきサーバ２０に対して送信する（ステップＳ１４）。
【００５０】
業務処理実行部２３は、以上のようにして、業務シナリオに記述された手順ｎ個の単機能処理について全て実行命令を送信し終わるまで（ステップＳ１３；Ｙｅｓ）、単機能処理の実行命令の送信を繰り返す。
次に、第２の構成について説明する。第２の構成は、Ｄ３Ａと同様な構成であり、業務管理システム２で使用する業務シナリオを分散データ駆動型にした構成である。すなわち、分散配置されたサーバ２０の業務シナリオ解析部２２が、他のサーバ２０から受け取った業務シナリオを解析し、業務処理実行部２３が、解析結果に基づいて自サーバ２０内のプログラムを起動して自サーバ２０が担当する処理を行い、処理結果を業務シナリオのデータ格納部分に格納した後、当該業務シナリオを次の処理を行うべきサーバ２０（シナリオ解析エンジン）に渡すというシステム構成である。
【００５１】
この第２の構成では、サーバ２０の業務処理実行部２３は、次の単機能処理の実行命令を含み、かつ、ある単機能処理の処理結果を格納した業務シナリオを、当該次の単機能処理を実行すべきサーバ２０に対して送信することとなる。
第２の構成における業務処理の実行手順を、図８を参照しながら説明する。まず、あるサーバ２０の業務処理実行部２３は、ある単機能処理の実行命令を含んだ業務シナリオを、当該ある単機能処理を実行すべきサーバ２０に対して送信する。
【００５２】
ある単機能処理を実行すべきサーバ２０の業務実行受付部２１が、ある単機能処理の実行命令を含んだ業務シナリオを受信すると（ステップＳ２１）、業務シナリオ解析部２２が、受信した業務シナリオを解析する（ステップＳ２２）。業務処理実行部２３は、実行命令を受けた単機能処理を実行し、実行結果を業務シナリオに格納する。業務処理実行部２３は、次の単機能処理を実行すべきサーバ２０に対して、次の単機能処理の実行命令を含んだ業務シナリオを送信する（ステップＳ２３）。
【００５３】
次に、図４及び図８を参照しながら、サーバ２０が、業務シナリオＡに対応する業務処理Ａの実行命令を受け付けた時の動作について説明する。
サーバ２０の業務実行受付部２１が、業務管理システム端末１から業務処理Ａの実行命令を受け付けると（ステップＳ２１）、業務シナリオ解析部２２が、業務処理Ａを処理するための業務シナリオＡを記憶部より読み出して解析する（ステップＳ２２）。業務処理実行部２３は、解析結果に基づいて、手順１を実行すべきサーバ２０に対して、手順１の実行命令を含んだ業務シナリオＡを送信する（ステップＳ２３）。
【００５４】
手順１を実行すべきサーバ２０の業務実行受付部２１が、手順１の実行命令を含んだ業務シナリオＡを受信すると（ステップＳ２１）、業務シナリオ解析部２２が業務シナリオＡを解析する（ステップＳ２２）。業務処理実行部２３は、実行命令を受けた手順１のプログラムＡを記憶部より読み出して実行する。そして、業務処理実行部２３は、業務シナリオＡにプログラムＡの実行結果を格納して、次の手順２を実行すべきサーバ２０に対して、次の手順２の実行命令を含んだ業務シナリオＡを送信する（ステップＳ２３）。
【００５５】
手順２を実行すべきサーバ２０の業務実行受付部２１が、手順２の実行命令を含んだ業務シナリオＡを受信すると（ステップＳ２１）、業務シナリオ解析部２２は、受信した業務シナリオＡを解析する（ステップＳ２２）。業務処理実行部２３は、実行命令を受けた手順２の単シナリオＡを記憶部より読み出して解析する。そして、業務処理実行部２３は、単シナリオＡに記述されたプログラムを順次自サーバ２０又は他サーバ２０で実行する。業務処理実行部２３は、単シナリオＡに記述されたプログラムの処理が全て終了した場合に、処理結果を業務シナリオＡに格納する。業務処理実行部２３は、次の手順３の単機能処理を実行すべきサーバ２０に対して、次の手順３の実行命令を含んだ業務シナリオＡを送信する（ステップＳ２３）。同様に、手順３、・・・、手順ｎを実行すべきサーバ２０も、手順２を実行すべきサーバ２０と同じ処理手順を繰り返すことにより、業務処理Ａを遂行する。
【００５６】
次に、図６に示す実行制御部２５について説明する。実行制御部２５は、業務処理の実行を制御する。制御のひとつとして、実行制御部２５は、業務シナリオに記述されているグループ分けに基づいて、業務処理の実行制御を行う。
ここで、業務シナリオに記述された単機能処理は、階層的なグループに分類することが可能である。階層的なグループ分けとは、例えば、業務シナリオに記述された単位機能処理のグループを規定し、また、そのグループ内におけるグループを規定するといったグループ分けをいう。
【００５７】
図９には業務シナリオにおけるグループ分けの一例を示す。同図に示すフェーズ番号と作業項目番号とは実行順序に対応し、「警報確認」、「系構成確認」等の作業項目は単機能処理に対応する。同図に示すように作業項目はフェーズでグループ化されている。
また、フェーズというグループを多次元構造化することも可能である。図９に示す例においては、作業項目１の作業項目定義に部品名が記述されており、業務解析エンジンによって当該部品名に対応するプログラムが呼び出される仕組みとなっている。このように、作業項目定義の中に、部品名、プログラム名、業務シナリオ名、又は、単シナリオ名を記述することで、多次元構造化したグループを作成することができ、シナリオやプログラムの再利用が可能となる。
【００５８】
また、実行制御部２５は、実行中の業務処理の中断と再試行とを制御する。
具体的には、実行制御部２５は、業務処理を実行している途中で、外部からの指示や故障を検知したときに、業務処理の中断点についての情報をメモリに保持した上で、業務処理を中断する。このように中断点をメモリに保持しておくことで、実行制御部２５は業務シナリオによる業務処理がどこまで進んだかを把握することができ、中断点からの再試行が可能となる。また、業務シナリオが通過すべきプログラムに関するハード故障を含む故障が起こったことを検知すると、実行制御部２５は、業務シナリオによる業務処理を中断し、中断点を保持する。故障修理等によりシステムが正常に戻ったことを検知すると、実行制御部２５は、中断点から業務処理を再試行する。
【００５９】
なお、実行制御部２５は、再試行の際には、ユーザ入力等によって外部より指示された箇所から、中断された業務処理を再試行することも可能である。このように、再試行の際に、実行する手順やどの箇所から業務処理を開始するかはユーザが任意に指定することが可能である。
また、図５に示すように、業務シナリオの中に制御文が記述されている場合には、実行制御部２５は、当該制御文に従って業務処理の実行制御を行う。例えば、実行制御部２５は、ある手順において単機能処理を実行することにより得られた結果を分析し、次に行うべき単機能処理を選択する。これにより、分岐、ループ、並列処理等の各種処理を制御することができ、業務シナリオ自体を動的に変化させることができる。また、実行制御部２５は、業務処理の即時起動も制御し、システム操作性としての柔軟性も確保する。このように、実行制御部２５により操作の柔軟性を確保することができるため、ユーザ主導の業務が可能である。
【００６０】
これらの業務シナリオは、あらかじめ生成して記憶部に記憶しておく他に、ユーザが端末を用いて編集することができる。ユーザが業務シナリオを編集する場合には、業務管理システム２の記憶部に、業務シナリオのデフォルトフォーマットをあらかじめ記憶させておく。端末からのユーザ指示により、デフォルトフォーマットが端末に表示される。ユーザが、表示されたデフォルトフォーマットの中の指定すべき部分を埋めることにより、業務シナリオを編集する。ユーザが指定可能な情報の一例としては、発動日時、終了日時等の基本的な情報や、業務シナリオ内部のグループ及び単機能処理各々についての処理ステータスである。処理ステータスとしては、自動進行、確認、スキップ等が存在する。図１０には、業務シナリオへの処理ステータス設定の一例を示す。同図に示すように、処理ステータスは業務シナリオ内のフェーズや作業項目毎に設定されている。また、Ｄ３Ａのアーキテクチャに従って、業務シナリオ編集専用のクライアント端末も用意してもよい。
【００６１】
このように、デフォルトで用意されているシナリオが、業務シナリオ作成の補助となる。また、業務シナリオに従った業務処理の起動時刻の指定や、業務シナリオ内部に記述されている手順（グループ、単機能処理）の処理ステータス、制御文等を記述し、記述内容を柔軟に変えることができるようにすることで、一連の業務処理について柔軟性を確保することができる。
【００６２】
次に、図６に示す業務キーワード記憶部２６について説明する。業務キーワード記憶部２６は、ハードディスク装置等の記憶部に、業務キーワードと業務シナリオとを対応付けて記憶する。業務キーワード記憶部２６により記憶される情報は、業務シナリオの生成に用いられる。業務キーワードと業務シナリオとの対応付け方法としては、１対１の対応付けであっても、多対１の対応付けであってもよい。
【００６３】
業務シナリオ生成部２７は、業務シナリオを生成する。具体的な業務シナリオの生成方法としては、業務シナリオ生成部２７は、ユーザ入力等により、外部から業務キーワードが入力された場合に、当該入力された業務キーワードと一致する業務キーワードと対応付けられて業務キーワード記憶部２６に記憶されている業務シナリオを取得する。取得された業務シナリオが複数存在する場合には、業務シナリオ生成部２７は、複数の業務シナリオで構成される一連の業務処理手順を示す情報を生成する。
【００６４】
このように、業務シナリオ生成部２７は、自動的に業務シナリオを組み合わせた一連の業務処理手順を示す情報を生成することができ、業務管理システム２はこの情報を用いて業務処理を行うことができるため、複雑な多制御の業務処理についての業務効率化が可能となる。
例えば、個々のＮＥ４に投入する局データを、コマンドによるＮＥへのデータ設定命令と捕らえることができるようなＮＥ４の場合、個々データの設定方法は大幅に簡素化されているが、複数種かつ複数のデータをＮＥ４に設定する場合には大きな稼動を要することになる。このときに業務シナリオを使用することで、容易に複数種かつ複数のデータを容易にＮＥ４に設定することが可能となる。
【００６５】
局データ投入業務に関する業務シナリオ生成処理について、図１１を参照しながら説明する。まず、ユーザは、業務管理システム端末１を操作して、設定したい局データを定義するファイル（ここでは、キーワードＢ、キーワードＡ及びキーワードＣが記述されたファイル）を作成する（ステップＳ３１）。この作成処理は、事前に局データを作成するために使用する局データ作成システムを使用する必要がなく、非常に簡素なものになる。
【００６６】
業務管理システム２の業務実行受付部２１は、ユーザの指示によりそのファイルを読み込む（ステップＳ３２）。業務管理システム２の業務キーワード記憶部２６では、局データの種類によって、前後処理や前後処理から得られる結果の判定ロジックをあらかじめ業務シナリオとして記憶している。業務シナリオ生成部２７は、業務キーワード記憶部２６に記憶されている業務シナリオを含んだ、一連の業務シナリオを自動生成する（ステップＳ３３）。ここにおいても業務シナリオの多次元構造化の有効性が得られる。
【００６７】
ここで、複数の局データを投入するときには、個々の局データにより生成される業務シナリオを組み合わせたものが一連の業務シナリオ（一連の業務処理手順を示す情報）になる。また、ひとつの局データを投入する場合には、ひとつの局データから生成される業務シナリオそのものが、一連の業務処理手順を示す情報となる。
以上説明したように、業務管理システム２は、業務シナリオに基づいて業務処理を順次自動的に実行することができ、複数の手順を有する業務処理を効率的に実行することができる。特に、業務管理システム２は、ユーザが業務管理システム２に対して行う作業のうち、業務フロー化可能な業務の効率化を行うことができる。また、業務シナリオに多次元構造をとることにより、多次元構造の業務フローを実現することができ、業務シナリオ間の再利用性を最大限に生かすことができる。このように、本発明により、分散コンピューティングによるハードウェア構成の柔軟性とプログラム構造の柔軟性とを併せ持つ業務管理システム２を構築することができる。
【００６８】
なお、以上の説明では、業務シナリオをＸＭＬで記述し、業務管理システム２を構成する複数のサーバ２０にはＩＡサーバ、サーバ２０間にはギガビットイーサネット（登録商標）を使用する例で説明したが、業務管理システム２に使用するプログラム言語、通信装置、及び、ネットワーク環境は、Ｄ３Ａの思想、形態をベースにできればよく、その範囲においては同様の効果が得られる。
【００６９】
また、本発明を利用可能な分野は通信網オペレーションの業務管理システム２にとどまらない。Ｄ３Ａは多様なシステムに対応できる基盤アーキテクチャであり、その基盤の上での業務シナリオの多次元構造化は共通的な思想となる。
なお、Ｄ３Ａをベースとする以外に、Ｄ３Ａ基盤を業務シナリオ解析エンジンとして使用することも可能である。
【産業上の利用可能性】
【００７０】
複数の手順を有する業務処理全般に利用することができる。特に、パターン化され、かつ、複数の同一手順を有する業務処理についての効率化を図ることができる。例えば、通信網オペレーションの業務管理システムにおけるファイル更新、局データ更新、ファームダウンロード、マクロ機能等の業務処理が存在する。
【図面の簡単な説明】
【００７１】
【図１】本発明の実施の形態に係る業務管理システムの構成を示す図である。
【図２】同実施の形態に係るサーバが備えるソフトウェア環境の一例を説明するための図である。
【図３】同実施の形態に係る分散データ駆動型アーキテクチャを説明するための図である。
【図４】同実施の形態に係る業務シナリオの多次元構造化の概念を示す図である。
【図５】同実施の形態に係る業務シナリオのさまざまな制御文挿入例を示す図である。
【図６】同実施の形態に係るサーバの機能構成を示す図である。
【図７】同実施の形態に係る業務処理の実行手順の一例を示すフローチャートである。
【図８】同実施の形態に係る業務処理の実行手順の一例を示すフローチャートである。
【図９】同実施の形態に係る業務シナリオのグループ分けの一例を示す図である。
【図１０】同実施の形態に係る業務シナリオへの処理ステータス設定の一例を示す図である。
【図１１】同実施の形態に係る局データ投入業務に関する業務シナリオ自動生成処理を説明するための図である。
【図１２】従来のファイル更新システムとＮＥとを含んだシステムの構成図である。
【符号の説明】
【００７２】
１ 業務管理システム端末
２ 業務管理システム
３ ＮＥ監視制御装置
４ ＮＥ（ネットワークエレメント）
２０ サーバ
２１ 業務実行受付部
２２ 業務シナリオ解析部
２３ 業務処理実行部
２５ 実行制御部
２６ 業務キーワード記憶部
２７ 業務シナリオ生成部
１００ ファイル更新操作端末
２００ ファイル更新装置
３００ ＮＥ監視制御装置
４００ ＮＥ
５００ ファイル更新システム
【特許請求の範囲】
【請求項１】
複数の通信装置を含む分散型の業務管理システムにおいて、
前記通信装置は、
業務処理の実行命令を受け付ける業務実行受付手段と、
前記業務実行受付手段により受け付けられた業務処理を行うための単機能処理と該単機能処理の実行順序とが記述された業務シナリオデータを解析する業務シナリオ解析手段と、
前記業務シナリオ解析手段による解析結果に基づいて、前記業務処理を実行すべき通信装置に対して該業務処理の実行命令を行う業務処理実行手段と
を備えることを特徴とする業務管理システム。
【請求項２】
前記業務シナリオデータには、前記単機能処理を表す情報として、実行すべきプログラムと、解析すべき他の業務シナリオデータと、の少なくとも１を識別するための情報が記述されていることを特徴とする
請求項１に記載の業務管理システム。
【請求項３】
前記業務処理実行手段は、
前記業務シナリオデータに記述された実行順序に従って、前記単機能処理の実行命令を、該単機能処理を実行すべき通信装置に対して順次送信することを特徴とする
請求項１又は２に記載の業務管理システム。
【請求項４】
前記業務処理実行手段は、
前記単機能処理の実行命令を含んだ前記業務シナリオデータを、該単機能処理を実行すべき通信装置に対して送信することを特徴とする
請求項１から３のいずれか１項に記載の業務管理システム。
【請求項５】
前記業務処理の実行制御を行う実行制御手段をさらに備え、
前記実行制御手段は、前記業務処理の中断と再試行とを制御することを特徴とする請求項１から４のいずれか１項に記載の業務管理システム。
【請求項６】
前記実行制御手段は、中断された業務処理を、外部より指示された箇所から再試行することを特徴とする
請求項５に記載の業務管理システム。
【請求項７】
前記業務シナリオデータには、階層的なグループに分類された単機能処理が記述されており、
前記実行制御手段は、前記業務シナリオデータに記述されているグループ分けに基づいて、前記業務処理の実行制御を行うことを特徴とする
請求項５又は６に記載の業務管理システム。
【請求項８】
前記業務シナリオデータには、前記単機能処理の実行結果に基づいて次に実行すべき単機能処理を決定するための制御文が記述されており、
前記実行制御手段は、前記業務シナリオデータに記述されている制御文に従って前記業務処理の実行制御を行うことを特徴とする
請求項５から７のいずれか１項に記載の業務管理システム。
【請求項９】
前記業務シナリオデータと業務キーワードとを対応付けて記憶する業務キーワード記憶手段と、
外部からの指示に対応する業務キーワードと対応付けられて前記業務キーワード記憶手段に記憶されている業務シナリオデータに基づいて、１又は複数の業務シナリオデータを含む一連の業務処理手順を表す情報を生成する業務シナリオ生成部とを備えることを特徴とする
請求項１から８のいずれか１項に記載の業務管理システム。
【請求項１０】
複数の通信装置を含む分散型の業務管理システムが行う業務処理実行方法において、
業務処理の実行命令を受け付ける業務実行受付ステップと、
前記業務実行受付ステップにおいて受け付けられた業務処理を行うための単機能処理と該単機能処理の実行順序とが記述された業務シナリオデータを解析する業務シナリオ解析ステップと、
前記業務シナリオ解析ステップにおける解析結果に基づいて、前記業務処理を実行すべき通信装置に対して該業務処理の実行命令を行う業務処理実行ステップと
を有することを特徴とする業務処理実行方法。
【請求項１】
複数の通信装置を含む分散型の業務管理システムにおいて、
前記通信装置は、
業務処理の実行命令を受け付ける業務実行受付手段と、
前記業務実行受付手段により受け付けられた業務処理を行うための単機能処理と該単機能処理の実行順序とが記述された業務シナリオデータを解析する業務シナリオ解析手段と、
前記業務シナリオ解析手段による解析結果に基づいて、前記業務処理を実行すべき通信装置に対して該業務処理の実行命令を行う業務処理実行手段と
を備えることを特徴とする業務管理システム。
【請求項２】
前記業務シナリオデータには、前記単機能処理を表す情報として、実行すべきプログラムと、解析すべき他の業務シナリオデータと、の少なくとも１を識別するための情報が記述されていることを特徴とする
請求項１に記載の業務管理システム。
【請求項３】
前記業務処理実行手段は、
前記業務シナリオデータに記述された実行順序に従って、前記単機能処理の実行命令を、該単機能処理を実行すべき通信装置に対して順次送信することを特徴とする
請求項１又は２に記載の業務管理システム。
【請求項４】
前記業務処理実行手段は、
前記単機能処理の実行命令を含んだ前記業務シナリオデータを、該単機能処理を実行すべき通信装置に対して送信することを特徴とする
請求項１から３のいずれか１項に記載の業務管理システム。
【請求項５】
前記業務処理の実行制御を行う実行制御手段をさらに備え、
前記実行制御手段は、前記業務処理の中断と再試行とを制御することを特徴とする請求項１から４のいずれか１項に記載の業務管理システム。
【請求項６】
前記実行制御手段は、中断された業務処理を、外部より指示された箇所から再試行することを特徴とする
請求項５に記載の業務管理システム。
【請求項７】
前記業務シナリオデータには、階層的なグループに分類された単機能処理が記述されており、
前記実行制御手段は、前記業務シナリオデータに記述されているグループ分けに基づいて、前記業務処理の実行制御を行うことを特徴とする
請求項５又は６に記載の業務管理システム。
【請求項８】
前記業務シナリオデータには、前記単機能処理の実行結果に基づいて次に実行すべき単機能処理を決定するための制御文が記述されており、
前記実行制御手段は、前記業務シナリオデータに記述されている制御文に従って前記業務処理の実行制御を行うことを特徴とする
請求項５から７のいずれか１項に記載の業務管理システム。
【請求項９】
前記業務シナリオデータと業務キーワードとを対応付けて記憶する業務キーワード記憶手段と、
外部からの指示に対応する業務キーワードと対応付けられて前記業務キーワード記憶手段に記憶されている業務シナリオデータに基づいて、１又は複数の業務シナリオデータを含む一連の業務処理手順を表す情報を生成する業務シナリオ生成部とを備えることを特徴とする
請求項１から８のいずれか１項に記載の業務管理システム。
【請求項１０】
複数の通信装置を含む分散型の業務管理システムが行う業務処理実行方法において、
業務処理の実行命令を受け付ける業務実行受付ステップと、
前記業務実行受付ステップにおいて受け付けられた業務処理を行うための単機能処理と該単機能処理の実行順序とが記述された業務シナリオデータを解析する業務シナリオ解析ステップと、
前記業務シナリオ解析ステップにおける解析結果に基づいて、前記業務処理を実行すべき通信装置に対して該業務処理の実行命令を行う業務処理実行ステップと
を有することを特徴とする業務処理実行方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【公開番号】特開２００６−６５６３７（Ｐ２００６−６５６３７Ａ）
【公開日】平成１８年３月９日（２００６．３．９）
【国際特許分類】
【出願番号】特願２００４−２４８５０６（Ｐ２００４−２４８５０６）
【出願日】平成１６年８月２７日（２００４．８．２７）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
【公開日】平成１８年３月９日（２００６．３．９）
【国際特許分類】
【出願日】平成１６年８月２７日（２００４．８．２７）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
[ Back to top ]