JP2008192042A - 経営分析処理方法、装置及びプログラム - Google Patents

Abstract

【課題】業務への影響を抑えつつ、最新の業務データを集計できるようにする。
【解決手段】ユーザ端末から分析条件を受信し、分析条件に対応する通知フラグをマスタDBから抽出し、分析条件と通知フラグとを含むレコードを生成して管理DBに格納する工程と、管理DB内の特定のレコードの分析条件に基づき分析条件に合致する第1データの更新指示を生成し、記憶部に格納する工程と、特定のレコードの通知フラグに従い、更新指示をデータ更新処理を実施すべき第1業務サーバに送信する工程と、第1業務サーバから、データ更新処理により更新された第2データを受信し、当該第2データに基づきデータ格納部を更新する工程と、全ての第1業務サーバから完了通知を受信したか否か判定する工程と、全ての第1業務サーバから完了通知を受信したと判定された場合、データ格納部内の第1データに基づき分析条件に合致する経営分析データを生成し、ユーザ端末に送信する工程とを含む。
【選択図】図１

Description

本発明は、複数の業務システムにおけるデータを利用し、経営分析を行うための技術に関する。

近年、例えば、複数の部門システム（例えば、医事会計システム、財務会計システム、人事給与システム、物流システム、固定資産システム、電子カルテシステム等）で発生した収支データを病院経営に活かすことを目的とした病院経営分析システムが注目を集めている。従来の病院経営分析システムでは、バッチ処理によって各部門システムから収支データを定期的（例えば、年次、月次等）に吸い上げ、例えば、診療科別、患者別といった集計単位に従って収支データを集計し、利用者に表示している。利用者は、集計結果を分析することで具体的な経営改善等の活動計画を立てることができるようになる。しかし、部門システムの収支データは、実施される診療行為等によって日々変化するため、従来の病院経営分析システムでは、集計結果に最新の収支データが必ず反映されているとは限らない。

一方、従来から、複数の業務システムのデータを基に、様々な分析を行う分析システムに関する技術が存在している。例えば、特開２００２−２１５８６６号公報には、会計処理データ及び業務データを統合することにより、多角的な経営分析を行う経営分析システムが開示されている。具体的には、経営担当者が分析端末によりネットワークで接続された経営分析センターにアクセスして、経営担当者の属する企業等の経営分析データを取得する経営分析システムであって、上記経営分析センターが、当該企業等に関する複数のデータベースから経営分析に必要な各種データを取り込んで経営分析用データベースを構築するデータ生成部と、このデータ生成部により構築された経営分析用データベースを登録する分析データ格納部と、この分析データ格納部に登録された経営分析用データベースを管理すると共に、経営担当者の分析端末からネットワークを介して送られてくる指示情報に基づいて、経営分析用データベースから経営分析に必要なデータを検索して読み出し、ネットワークを介して分析端末に送信するデータ管理部とを含んでおり、上記分析端末が、経営担当者により入力される検索条件に基づいて、指示情報を作成して、ネットワークを介して経営分析センターに送信すると共に、経営分析センターからネットワークを介して送られてくる検索結果のデータに基づいて経営分析を行うものである。しかし、上記公報では、経営分析用データベースは月次決済毎に更新されるようになっており、上記のような問題を解決することはできない。

また、上記のような問題を解決するために、収支データの吸い上げ頻度を高くしたり（例えば、バッチ処理を日次で運用する等）、利用者が病院経営分析システムにアクセスした時点で、リアルタイムに収支データを吸い上げたりすることが考えられる。しかし、収支データの吸い上げ頻度を高くしたとしても、利用者が病院経営分析システムにアクセスした時点における最新の収支データが集計結果に必ず反映されているとは限らない。また、バッチ処理には膨大な処理時間を要するため、リアルタイムに収支データを吸い上げるようにすると、部門システムの本来の業務への影響が大きくなり、さらに利用者へ集計結果を表示するまでのレスポンスが遅くなるという問題が生じる。
特開２００２−２１５８６６号公報

このように従来技術では、分析システムにおいて、業務システム（例えば、医事会計システム）の本来の業務への影響を抑えつつ、利用者が分析システムにアクセスした時点における最新の業務データ（例えば、収支データ）を集計結果に反映することができない。

従って、本発明の目的は、分析システムにおいて、業務システムの本来の業務への影響を抑えつつ、利用者が分析システムにアクセスした時点における最新の業務データを集計できるようにするための技術を提供することである。

本発明の第１の態様に係る経営分析処理方法は、複数の業務システム・サーバのうちデータ更新処理を実施すべき第１業務システム・サーバを特定するためのシステム通知フラグを、分析条件に対応して格納するマスタデータベースと、経営分析依頼に含まれる分析条件と当該分析条件に対応するシステム通知フラグとを含むレコードを経営分析依頼毎に格納する管理データベースと、複数の業務システムの各々の業務に関するデータであって経営分析に用いる分析データを格納するデータ格納部と、記憶装置とを有し、且つ複数の業務システム・サーバに接続されるコンピュータにより実行される経営分析処理方法であって、ユーザ端末から分析条件を含む経営分析依頼を受信した場合、マスタデータベースから当該分析条件に対応するシステム通知フラグを抽出し、分析条件と抽出したシステム通知フラグとを含むレコードを生成して管理データベースに格納するステップと、管理データベースに格納されている特定のレコードに含まれる分析条件に基づき、分析データのうち分析条件に合致する第１分析データの更新指示を生成し、記憶装置に格納する更新指示生成ステップと、特定のレコードに含まれるシステム通知フラグに従って、記憶装置に格納された更新指示を、データ更新処理を実施すべき第１業務システム・サーバに送信する更新指示送信ステップと、第１業務システム・サーバから、第１分析データのうち当該第１業務システム・サーバにおけるデータ更新処理によって更新された第２分析データを受信し、当該第２分析データに基づいてデータ格納部を更新するステップと、更新指示を送信した全ての第１業務システム・サーバから、データ更新処理の完了通知を受信したか否か判定するステップと、更新指示を送信した全ての第１業務システム・サーバから、データ更新処理の完了通知を受信したと判定された場合、データ格納部に格納された第１分析データに基づき、分析条件に合致する経営分析データを生成し、ユーザ端末に送信するステップとを含む。

このようにすれば、利用者から経営分析依頼を受信した時点で、リアルタイムに必要最小限の業務データ（例えば、収支データ等）を吸い上げることができる。すなわち、業務システムの本来の業務への影響を抑えつつ、最新の業務データを反映した経営分析データ（すなわち、集計結果）を利用者に提供することができる。

また、本発明の第１の態様において、上記レコードが、所定の優先度の情報をさらに含むようにしても良い。そして、更新指示生成ステップが、管理データベースに複数のレコードが格納されている場合に、所定の優先度の情報に従って、複数のレコードから上記特定のレコードを特定するステップを含むようにしても良い。なお、所定の優先度の情報が、経営分析依頼の送信元のユーザに関連する第１優先度と分析条件に関連する第２優先度との少なくともいずれかを含む場合もある。このようにすれば、例えば、予めユーザ毎に優先度を設定しておけば、複数の利用者から経営分析依頼があった場合に、優先度の高い利用者（例えば、院長、理事長等）については、優先的に対応することができる。

さらに、本発明の第１の態様において、上記複数の業務システムが、医事会計システムと財務会計システムと人事給与システムと物流システムと固定資産システムと電子カルテシステムとのうち少なくとも２以上のシステムを含む場合もある。

本発明の第２の態様に係る、経営分析における情報処理方法は、業務データを格納するデータ格納部と、業務データの更新履歴情報を格納する更新管理データベースとを有し、且つ経営分析システム・サーバに接続されるサーバにより実行される情報処理方法であって、経営分析システム・サーバから、経営分析システム・サーバにおける経営分析処理で必要となる分析データの条件を含む更新指示を受信した場合、業務データのうち、更新指示に含まれる条件に合致する第１業務データを特定する第１特定ステップと、更新管理データベースに格納されている更新履歴情報に基づき、第１業務データのうち更新されている第２業務データを特定する第２特定ステップと、特定された第２業務データを含む分析データを生成し、経営分析システム・サーバに送信するステップとを含む。

このようにすれば、業務システム・サーバ（例えば、医事会計システムサーバ等）は、経営分析処理に必要なデータのうち、更新されているデータについてのみ処理すれば良いので、業務システムにおける本来の業務の影響を最小限に抑えることができる。

また、本発明の第２の態様において、第２業務データに対応する更新履歴情報を更新管理データベースから削除し、第２特定ステップ以降のステップを実施するステップをさらに含むようにしても良い。そして、第２特定ステップが、更新管理データベースに格納されている更新履歴情報に基づき、第２業務データが存在するか否か判定するステップと、第２業務データが存在しないと判定された場合、更新完了通知を経営分析システム・サーバに送信するステップとを含むようにしても良い。このようにすれば、分析データを経営分析システム・サーバに送信した後、新たにデータ（第２業務データ）が更新されるまでは、処理を行わなくても良くなる。

なお、本発明に係る経営分析処理方法又は経営分析における情報処理方法をコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークを介してディジタル信号にて頒布される場合もある。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。

本発明によれば、分析システムにおいて、業務システムの本来の業務への影響を抑えつつ、利用者が分析システムにアクセスした時点における最新の業務データを集計することができる。

図１に本発明の一実施の形態に係るシステム概要を示す。例えばインターネットであるネットワーク１には、分析サーバ３と、医事会計サーバ５と、財務会計サーバ７とが接続されている。

分析サーバ３は、病院経営分析システム３００内に設けられており、同じく病院経営分析システム３００内に含まれる収支データ格納部４０にアクセス可能となっている。また、分析サーバ３は、病院経営分析システム３００内に含まれるユーザ端末Ａ、ユーザ端末Ｂ及びユーザ端末Ｃに接続されている。ユーザ端末Ａ、ユーザ端末Ｂ及びユーザ端末Ｃの各々には、例えばＷｅｂブラウザがインストールされており、当該Ｗｅｂブラウザにより分析サーバ３にアクセスする。なお、ユーザ端末は３台に限定されない。

医事会計サーバ５は、医事会計システム５００内に設けられており、同じく医事会計システム５００内に含まれる更新管理ＤＢ５１及び会計データ格納部５２にアクセス可能となっている。また、医事会計サーバ５は、医事会計システム５００内に含まれるシステム管理者端末Ａに接続されている。システム管理者端末Ａには、例えばＷｅｂブラウザがインストールされており、当該Ｗｅｂブラウザにより医事会計サーバ５にアクセスする。なお、医事会計システム５００内のシステム管理者端末は１台に限定されない。

財務会計サーバ７は、財務会計システム７００内に設けられており、同じく財務会計システム７００内に含まれる更新管理ＤＢ７１及び財務データ格納部７２にアクセス可能となっている。また、財務会計サーバ７は、財務会計システム７００内に含まれるシステム管理者端末Ｂに接続されている。システム管理者端末Ｂには、例えばＷｅｂブラウザがインストールされており、当該Ｗｅｂブラウザにより財務会計サーバ７にアクセスする。なお、財務会計システム７００内のシステム管理者端末は１台に限定されない。

本実施の形態では、医事会計システム５００又は財務会計システム７００を単に部門システムと呼ぶ場合もある。また、会計データ格納部５２又は財務データ格納部７２に格納されているデータを単に業務データと呼ぶ場合もある。なお、図１では、部門システムの数が２つの例を示しているが、部門システムは２つに限定されない。他の部門システムも、基本的には、医事会計システム５００及び財務会計システム７００と同様の構成を有する。

図２に、分析サーバ３の機能ブロック図を示す。分析サーバ３は、病院経営分析システム３００の利用者の情報を格納するユーザマスタＤＢ３１と、後に説明するシステム通知フラグ及び優先レベルを画面種別毎に格納する画面種別マスタＤＢ３２と、優先レベルのパターンに関するデータを格納する優先レベルパターンデータ格納部３３と、分析条件等を含むレコードを経営分析依頼毎に格納する画面表示管理ＤＢ３５と、後で説明する完了フラグ等を含むレコードを格納する完了管理ＤＢ３６と、ユーザ端末からの経営分析依頼に含まれる分析条件並びにユーザマスタＤＢ３１、画面種別マスタＤＢ３２及び優先レベルパターンデータ格納部３３に格納されているデータに基づき、画面表示管理ＤＢ３５及び完了管理ＤＢ３６にレコードを追加し、完了管理ＤＢ３６及び収支データ格納部４０に格納されているデータに基づき、収支データを集計してユーザ端末に送信する分析画面表示処理部３４と、画面表示管理ＤＢ３５に格納されているデータに基づき、更新指示を部門システムに送信する管理部３７と、部門システムから完了通知を受信した場合に、完了管理ＤＢ３６を更新する完了フラグ設定部３８と、部門システムから収支データを受信した場合に、受信した収支データを基に収支データ格納部４０を更新する収支データ管理部３９と有する。

図３に、医事会計サーバ５の機能ブロック図を示す。医事会計サーバ５は、後で説明する更新条件データを格納するキュー５４と、分析サーバ３から更新指示を受信した場合に、更新条件データをキュー５４に登録するキュー管理部５３と、キュー５４を参照し、後で説明する正規化処理を実施する正規化処理部５５とを有する。

図４に、財務会計サーバ７の機能ブロック図を示す。なお、基本的には、医事会計サーバ５と同様の構成を有する。財務会計サーバ７は、更新条件データを格納するキュー７４と、分析サーバ３から更新指示を受信した場合に、更新条件データをキュー７４に登録するキュー管理部７３と、キュー７４を参照し、正規化処理を実施する正規化処理部７５とを有する。なお、図示しない他の部門システムにおけるサーバも、基本的には、図３及び図４に示した機能ブロック図のような構成を有する。

図５に、ユーザマスタＤＢ３１に格納されるデータの一例を示す。図５の例では、ＩＤの列と、ユーザ名の列と、役職・所属の列と、優先レベルの列とが含まれる。優先レベルの列には、そのユーザに対応する優先度が格納される。また、他にもログインに必要なパスワードを格納する場合もある。

図６に、画面種別マスタＤＢ３２に格納されるデータの一例を示す。図６の例では、画面種別の列と、システム通知フラグの列と、優先レベルの列とが含まれる。優先レベルの列には、その画面種別に対応する優先度が格納される。また、システム通知フラグの列には、その画面種別に対応するシステム通知フラグが格納される。システム通知フラグは、２進数のビット列であり、例えば、図７に示すようにビット毎に部門システムが対応付けられている。図７の例では、ｂｉｔ５は医事会計システム、ｂｉｔ４は財務会計システム、ｂｉｔ３は人事給与システム、ｂｉｔ２は固定資産システム、ｂｉｔ１は物流システム、ｂｉｔ０は電子カルテシステムというような対応付けがなされている。そして、更新指示を送信すべき部門システムに対応するビットには「１」がセットされる。例えば、更新指示を送信すべき部門システムが、医事会計システム（ｂｉｔ５）及び人事給与システム（ｂｉｔ３）である場合には、システム通知フラグは「１０１０００」となる。

図８に、優先レベルパターンデータ格納部３３に格納されるデータの一例を示す。図８の例では、パターンの列と、ユーザ優先レベルの列と、表示画面優先レベルの列とが含まれる。ユーザ優先レベルの列及び表示画面優先レベルの列には、それぞれの優先レベルを使用するか否かを表す情報が格納される。パターン１において、ユーザ優先レベルは「使用」、表示画面優先レベルは「未使用」となっている。また、パターン２において、ユーザ優先レベルは「未使用」、表示画面優先レベルは「使用」となっている。パターン３において、ユーザ優先レベル及び表示画面優先レベルはそれぞれ「使用」となっている。また、パターン４において、ユーザ優先レベル及び表示画面優先レベルはそれぞれ「未使用」となっている。また、優先レベルパターンデータ格納部３３には、どのパターンを適用するかを表す情報も格納される。

図９に、画面表示管理ＤＢ３５に格納されるデータの一例を示す。図９の例では、ユーザＩＤの列と、ユーザ名の列と、画面種別の列と、年月の列と、診療科の列と、医師の列と、ユーザ優先レベルの列と、表示画面優先レベルの列と、システム通知フラグの列と、更新年月日の列と、更新時間の列とが含まれる。画面種別の列、年月の列、診療科の列及び医師の列には、経営分析依頼に含まれる分析条件が格納される。なお、詳細については後で説明するが、利用者から経営分析依頼を受信した場合に画面表示管理ＤＢ３５にレコードが追加される。また、分析サーバ３が、部門システムに更新指示を送信した後に画面表示管理ＤＢ３５から当該レコードが削除される。

図１０に、完了管理ＤＢ３６に格納されるデータの一例を示す。図１０の例では、ユーザＩＤの列と、ユーザ名の列と、画面種別の列と、年月の列と、診療科の列と、医師の列と、完了フラグの列とが含まれる。さらに、完了フラグの列には、医事会計の列と、財務会計の列と、人事給与の列と、固定資産の列と、物流の列と、電子カルテの列とが含まれる。詳細は後で説明するが、ユーザＩＤの列、ユーザ名の列、画面種別の列、年月の列、診療科の列及び医師の列には、画面表示管理ＤＢ３５（図９）のユーザＩＤの列、ユーザ名の列、画面種別の列、年月の列、診療科の列及び医師の列におけるデータをコピーしたものが、それぞれ格納される。また、完了フラグの各列には、部門システムから完了通知を受信したか否かを表すフラグ（１：完了、０：未完了）が格納される。

図１１に、収支データ格納部４０に格納されるデータの一例を示す。図１１の例では、患者ＩＤの列と、日付の列と、勘定科目の列と、診療科の列と、入外区分の列と、医師の列と、金額（円）の列とが含まれる。なお、図示していないが、部門システムで管理されるデータ（例えば、医事会計システム５００であれば、会計データ格納部５２に格納されるデータ）と勘定科目とを対応付けるデータが用意されており、このデータに基づいて金額（円）が算出される。

次に、図１に示したシステムの処理について説明する。まず、図１２及び図１３を用いて、分析サーバ３が経営分析依頼を受信した際の処理を説明する。例えば、利用者は、ユーザ端末Ａを操作して、分析サーバ３が提供する分析ページにアクセスさせる。分析サーバ３の分析画面表示処理部３４は、ユーザ端末Ａからのアクセスに応答して、分析ページのページ・データをユーザ端末Ａに送信する。ユーザ端末Ａは、分析ページのページ・データを受信し、分析画面を表示装置に表示する。例えば図１２のような画面が表示される。図１２の例では、画面種別を選択するためのコンボボックス１２０１、対象年月を選択するためのコンボボックス１２０２及び診療科を選択するためのコンボボックス１２０３が分析条件の項目として設けられている。なお、分析条件の項目は３つに限定されるものではない。例えば、コンボボックス１２０１において「医師別収支」画面を選択した場合には、医師を選択させるためのコンボボックス（図示せず）を表示する場合もある。さらに、図１２の例では、選択された分析条件を送信するための決定ボタン１２０４、利用状況表示欄１２０５、分析結果表示欄１２０６が設けられている。利用状況表示欄１２０５には、利用者のユーザ名及び利用日時が表示される。また、分析結果表示欄１２０６には、初期画面として「分析条件を入力して下さい。」等と表示される。

利用者は、図１２の画面において、分析条件を選択し、決定ボタン１２０４をクリックする。ユーザ端末Ａは、これらの分析条件を受け付け、分析条件を含む経営分析依頼を分析サーバ３に送信する。分析サーバ３の分析画面表示処理部３４は、分析条件を含む経営分析依頼を受信する（図１３：ステップＳ１）。そして、分析画面表示処理部３４は、受信した経営分析依頼に含まれる分析条件を含むレコードを生成し、画面表示管理ＤＢ３５にレコードを追加する（ステップＳ３）。具体的には、画面表示管理ＤＢ３５に追加されるレコードのユーザ名及びユーザ優先レベルには、ユーザＩＤを基にユーザマスタＤＢ３１（図５）を検索し、当該ユーザＩＤに対応するデータがそれぞれ設定される。また、画面種別、年月、診療科及び医師には、経営分析依頼に含まれる分析条件がそれぞれ設定される。さらに、表示画面優先レベル及びシステム通知フラグには、画面種別を基に画面種別マスタＤＢ３２（図６）を検索し、当該画面種別に対応するデータがそれぞれ設定される。また、更新年月日及び更新時間には、経営分析依頼を受信した日時が設定される。

例えば、利用者である院長（ユーザＩＤ：００１）が、図１２の画面において、画面種別を「診療科別収支」、対象年月を「2006年8月」、診療科を「内科」とし、決定ボタン１２０４をクリックした場合、ユーザＩＤ＝００１のレコード（図９）が画面表示管理ＤＢ３５に追加される。ユーザＩＤ＝００１のレコードにおいて、ユーザ名は「田中」、画面種別は「診療科別収支」、年月は「200608」、診療科は「内科」、医師は「−（未設定）」、ユーザ優先レベルは「１」、表示画面優先レベルは「２」、システム通知フラグは「１０００００」、更新年月日は「2006/08/19」、更新時間は「09:00:02」となっている。

そして、分析画面表示処理部３４は、ステップＳ３の処理により追加したレコードを基に、完了管理ＤＢ３６にもレコードを追加し、各部門システムの完了フラグを全て０に設定する（ステップＳ５）。上でも述べたように、画面表示管理ＤＢ３５におけるレコードのユーザＩＤ、ユーザ名、画面種別、年月、診療科及び医師の各々のデータをコピーしたものが、完了管理ＤＢ３６におけるレコードのユーザＩＤ、ユーザ名、画面種別、年月、診療科及び医師に格納される。

次に、図１４乃至図１６を用いて、分析サーバ３が部門システムに更新指示を送信する際の処理を説明する。分析サーバ３の管理部３７は、定期的又は任意のタイミングで図１４に示すような処理を実施する。まず、管理部３７は、画面表示管理ＤＢ３５にレコードが格納されているか判断する（図１４：ステップＳ７）。もし、画面表示管理ＤＢ３５にレコードが格納されていなければ（ステップＳ７：Ｎｏルート）、処理を終了する。一方、画面表示管理ＤＢ３５にレコードが格納されている場合には（ステップＳ７：Ｙｅｓルート）、管理部３７は、更新条件データ生成処理を実施する（ステップＳ９）。更新条件データ生成処理については、図１５及び図１６を用いて説明する。

まず、管理部３７は、画面表示管理ＤＢ３５から最小の優先レベルを含むレコードを抽出する（図１５：ステップＳ２７）。ここでは、ユーザ優先レベルと表示画面優先レベルとの和が最小となるレコードを抽出する。なお、画面表示管理ＤＢ３５にレコードが格納されていない場合（すなわち、ステップＳ７でＮｏルートに移行する場合）は、更新条件データ生成処理は実施されないので、ここでは、必ず１以上のレコードが抽出される。そして、管理部３７は、抽出したレコードが複数存在するか判断する（ステップＳ２９）。もし、抽出したレコードが１レコードのみであれば（ステップＳ２９：Ｎｏルート）、ステップＳ３３の処理に移行する。一方、抽出したレコードが複数存在する場合（ステップＳ２９：Ｙｅｓルート）、管理部３７は、複数のレコードから更新日時が最も古いレコードを抽出する（ステップＳ３１）。管理部３７は、抽出したレコードの分析条件（すなわち、画面種別、年月、診療科及び医師）に基づき、更新条件データを生成し、例えばメインメモリ等の記憶装置に格納する（ステップＳ３３）。そして、更新条件データ生成処理を終了する。

なお、更新条件データの一例を図１６（ａ）乃至（ｃ）に示す。図１６（ａ）は、画面表示管理ＤＢ３５（図９）からユーザＩＤ＝００１のレコードが抽出された場合に生成される更新条件データを示す。また、図１６（ｂ）は、画面表示管理ＤＢ３５（図９）からユーザＩＤ＝００２のレコードが抽出された場合に生成される更新条件データを示す。さらに、図１６（ｃ）は、画面表示管理ＤＢ３５（図９）からユーザＩＤ＝００４のレコードが抽出された場合に生成される更新条件データを示す。いずれの更新条件データも、項目の列と内容の列とを含む。内容の列には、当該項目に対応するデータが設定される。

図１４の説明に戻って、管理部３７は、更新条件データ生成処理によって生成された更新条件データに対応するレコードからシステム通知フラグを取得する（ステップＳ１１）。その後、管理部３７は、カウンタＮを１で初期化する（ステップＳ１３）。そして、管理部３７は、システム通知フラグのＮビット目が１であるか判断する（ステップＳ１５）。もし、システム通知フラグのＮビット目が１の場合（ステップＳ１５：Ｙｅｓルート）、管理部３７は、Ｎビット目に対応する部門システムに更新条件データを含む更新指示を送信する（ステップＳ１７）。一方、システム通知フラグのＮビット目が０の場合（ステップＳ１５：Ｎｏルート）、管理部３７は、完了管理ＤＢ３６内のＮビット目に対応する部門システムの完了フラグを１に設定する（ステップＳ１９）。すなわち、更新指示を送信しなければ、部門システムから完了通知は送信されないので、完了フラグを１（完了）に設定する。

その後、管理部３７は、カウンタＮをインクリメントする（ステップＳ２１）。そして、管理部３７は、カウンタＮが部門システム数を超えたか（「Ｎ＞部門システム数」を満たすか）判断する（ステップＳ２３）。もし、カウンタＮが部門システム数以下の場合（ステップＳ２３：Ｎｏルート）、ステップＳ１５の処理に戻る。一方、カウンタＮが部門システム数を超えた場合（ステップＳ２３：Ｙｅｓルート）、更新条件データに対応するレコードを画面表示管理ＤＢ３５から削除する（ステップＳ２５）。そして、ステップＳ７の処理に戻る。

このような処理を実施することによって、経営分析依頼に含まれる分析条件に関連する業務データを管理している部門システムのみに更新指示が送信される。

次に、部門システムにおける処理を説明する。なお、各部門システムにおける処理は、基本的には同様の処理になるため、本実施の形態では、医事会計システム５００を例に説明する。まず、部門システム（医事会計システム５００）が更新指示を受信した際の処理を説明する。医事会計サーバ５のキュー管理部５３は、分析サーバ３から更新条件データを含む更新指示を受信する（図１７：ステップＳ３５）。そして、キュー管理部５３は、更新条件データをキュー５４に格納する（ステップＳ３７）。これにより、更新指示の受信順に、以下で説明する更新処理を実施できるようになる。

次に、図１８乃至図２２を用いて、部門システム（医事会計システム５００）の更新処理を説明する。医事会計サーバ５の正規化処理部５５は、定期的又は任意のタイミングで図１８に示すような処理を実施する。まず、正規化処理部５５は、キュー５４に更新条件データが格納されているか判断する（図１８：ステップＳ３９）。もし、キュー５４に更新条件データが格納されていなければ（ステップＳ３９：Ｎｏルート）、処理を終了する。一方、キュー５４に更新条件データが格納されている場合（ステップＳ３９：Ｙｅｓルート）、正規化処理部５５は、キュー５４の先頭から更新条件データを取り出し、一旦記憶装置に格納する（ステップＳ４１）。そして、正規化処理部５５は、更新条件に合致するレコードが更新管理ＤＢ５１に格納されているか判断する（ステップＳ４３）。

ここで、更新管理ＤＢ５１及び会計データ格納部５２に格納されるデータについて簡単に説明しておく。図１９に、更新管理ＤＢ５１に格納されるデータの一例を示す。図１９の例では、患者ＩＤの列と、診療科の列と、医師の列と、診療日付の列と、更新年月日の列と、更新時間の列とが含まれる。

図２０に、会計データ格納部５２に格納されるデータの一例を示す。図２０の例では、患者ＩＤの列と、年月の列と、剤情報１の列と、剤情報２の列と、・・・とが含まれる。さらに、剤情報の各々には、日付の列と、診療科の列と、入外区分の列と、医師の列と、診療行為の列と、数量の列と、単価（円）の列とが含まれる。なお、図２０では、その患者の１ヶ月分の剤情報を格納するようになっている。

例えば、医事会計システムの管理者が、システム管理者端末Ａを操作して、新たな会計データとして患者ＩＤ＝００１００１の２００６年８月１８日分の剤情報を医事会計サーバ５へ送信させる。医事会計サーバ５は、システム管理者端末Ａから新たな会計データを受信し、会計データ格納部５２内の当該患者ＩＤのレコードに剤情報（日付＝2006/08/18）を追加すると共に、当該剤情報に関するレコードを生成し、更新管理ＤＢ５１に追加する。

図１８の説明に戻って、例えば、図１６（ａ）に示した更新条件データがキュー５４から取り出された場合、「診療科＝内科」且つ「診療日付＝2006/08/*」（「*」はワイルドカードを表す）が設定されているレコードが、更新管理ＤＢ５１に格納されているか否かステップＳ４３の処理にて判断される。

もし、更新条件に合致するレコードが更新管理ＤＢ５１に格納されていなければ（ステップＳ４３：Ｎｏルート）、ステップＳ４９の処理に移行する。一方、更新条件に合致するレコードが更新管理ＤＢ５１に格納されている場合（ステップＳ４３：Ｙｅｓルート）、正規化処理部５５は、更新管理ＤＢ５１から更新条件に合致するレコードを抽出し、一旦記憶装置に格納する（ステップＳ４５）。すなわち、「診療科＝内科」且つ「診療日付＝2006/08/*」が設定されている、患者ＩＤ＝００１００１のレコードと患者ＩＤ＝００１００７のレコードとが更新管理ＤＢ５１から抽出される。そして、正規化処理部５５は、抽出したレコードに基づき、正規化処理を実施する（ステップＳ４７）。正規化処理については、図２１を用いて説明する。

まず、正規化処理部５５は、処理対象のレコードのうち未処理のレコードを特定する（ステップＳ５１）。そして、正規化処理部５５は、特定したレコードに対応する会計データを会計データ格納部５２から抽出する（ステップＳ５３）。例えば、未処理のレコードとして患者ＩＤ＝００１００１のレコードが特定された場合、「患者ＩＤ＝００１００１」且つ「年月＝2006/08」を含むレコードを会計データとして会計データ格納部５２から抽出し、一旦記憶装置に格納する。そして、正規化処理部５５は、抽出した会計データに基づき、収支データを生成し、分析サーバ３に送信する（ステップＳ５５）。なお、図示していないが、分析サーバ３の収支データ管理部３９は、医事会計サーバ５から収支データを受信し、収支データ格納部４０のデータを更新する。また、他の部門システムにおけるサーバから収支データを受信した場合も、分析サーバ３の収支データ管理部３９は同様の処理を実施する。

その後、正規化処理部５５は、特定したレコードを更新管理ＤＢ５１から削除する（ステップＳ５７）。そして、正規化処理部５５は、処理対象となる全てのレコードについての処理が完了したか否か判断する（ステップＳ５９）。もし、処理対象となる全てのレコードについての処理が完了していなければ（ステップＳ５９：Ｎｏルート）、ステップＳ５１の処理に戻る。一方、処理対象となる全てのレコードについての処理が完了した場合（ステップＳ５９：Ｙｅｓルート）、元の処理に戻る。

図１８の説明に戻って、正規化処理部５５は、分析サーバ３に完了通知を送信する（ステップＳ４９）。なお、更新条件に合致するレコードが更新管理ＤＢ５１に格納されていない場合は（ステップＳ４３：Ｎｏルート）、ステップＳ４５及びＳ４７をスキップし、分析サーバ３に完了通知を送信する。そして、ステップＳ３９の処理に戻る。

また、分析サーバ３の完了フラグ設定部３８は、医事会計サーバ５から完了通知を受信し、完了管理ＤＢ３６内の医事会計システムの完了フラグを１に設定する。なお、完了通知には、どの更新指示に対する完了通知であるかを表す情報を含むものとする。また、他の部門システムにおけるサーバから完了通知を受信した場合には、当該部門システムに該当する完了フラグを１に設定する。

このような処理を実施することによって、分析条件に関連する会計データを処理対象とするので、部門システムの更新処理の負荷を最小限に抑えることができる。

また、正規化処理部５５は、図１８に示した処理とは別の任意のタイミングで、図２２に示すような処理を実施する。まず、正規化処理部５５は、更新管理ＤＢ５１にレコードが格納されているか判断する（ステップＳ６１）。もし、更新管理ＤＢ５１にレコードが格納されていなければ（ステップＳ６１：Ｎｏルート）、処理を終了する。一方、更新管理ＤＢ５１にレコードが格納されている場合（ステップＳ６１：Ｙｅｓルート）、正規化処理部５５は、更新管理ＤＢ５１から更新日時が最も古いレコードを抽出する（ステップＳ６３）。そして、正規化処理部５５は、抽出したレコードに基づき、正規化処理を実施する（ステップＳ６５）。なお、正規化処理については、上で説明した処理と同様であるため、説明は省略する。

例えば、部門システムにおけるサーバのアイドル状態を見計らって、上記のような処理を実施するようにすれば、図１８に示した処理を実施する際にステップＳ４５及びステップＳ４７の処理をスキップできる場合が多くなり、完了通知を迅速に送信することができるようになる。

次に、図２３及び図２４を用いて、分析サーバ３が分析結果を出力する際の処理を説明する。分析サーバ３の分析画面表示処理部３４は、定期的又は任意のタイミングで図２３に示すような処理を実施する。まず、分析画面表示処理部３４は、完了管理ＤＢ３６から未処理のレコードを抽出する（図２３：ステップＳ６７）。そして、分析画面表示処理部３４は、抽出したレコードに含まれる、全ての部門システムの完了フラグが１であるか判断する（ステップＳ６９）。もし、少なくともいずれかの部門システムの完了フラグが０であれば（ステップＳ６９：Ｎｏルート）、ステップＳ７７の処理に移行する。一方、全ての部門システムの完了フラグが１の場合（ステップＳ６９：Ｙｅｓルート）、分析画面表示処理部３４は、当該レコードの分析条件に合致する収支データを収支データ格納部４０から抽出する。そして、分析画面表示処理部３４は、抽出した収支データを集計し、一旦記憶装置に格納する（ステップＳ７１）。そして、分析画面表示処理部３４は、集計した収支データを基に、分析結果ページ・データを生成し、ユーザ端末Ａに送信する（ステップＳ７３）。その後、分析画面表示処理部３４は、完了管理ＤＢ３６から当該レコードを削除する（ステップＳ７５）。そして、分析画面表示処理部３４は、全てのレコードの処理が完了したか判断する（ステップＳ７７）。もし、全てのレコードの処理が完了していなければ（ステップＳ７７：Ｎｏルート）、ステップＳ６７の処理に戻る。一方、全てのレコードの処理が完了した場合（ステップＳ７７：Ｙｅｓルート）、処理を終了する。

また、ユーザ端末Ａは、分析サーバ３から分析結果ページ・データを受信し、分析結果を表示装置に表示する。例えば図２４のような画面が表示される。図２４の例では、分析結果表示欄２４０６に、診療科別収支表（対象年月：2006年8月，診療科：内科）が表示されている。

以上のように、本実施の形態によれば、部門システムにおいて、必要最小限のデータについて更新処理を行うので、部門システムの本来の業務への影響を抑えつつ、利用者が分析サーバ３にアクセスした時点における最新の業務データを集計することができる。

以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上で説明した機能ブロック図は必ずしも実際のプログラムモジュール構成に対応するものではない。また、分析サーバ３又は部門システムにおけるサーバは、１台のコンピュータではなく複数台のコンピュータで実現するようにしても良い。

また、上で説明した各テーブルの構成は一例であって、必ずしも上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変らなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。例えば、ステップＳ１９において、部門システムに更新指示を送信しない場合、当該部門システムの完了フラグを１に設定しているが、完了管理ＤＢ３６にレコードを追加する処理（ステップＳ５）と併せて行うようにしても良い。この場合、システム通知フラグの各ビットを反転させたものを各部門システムの完了フラグとして設定すれば良い。

なお、ユーザ端末Ａ、Ｂ及びＣ、システム管理者端末Ａ及びＢ、分析サーバ３、医事会計サーバ５並びに財務会計サーバ７については、図２５のようなコンピュータ装置であって、メモリ２５０１（記憶装置）とＣＰＵ２５０３（処理装置）とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施の形態における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本発明の実施の形態では、上で述べた処理を実施するためのアプリケーション・プログラムはリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

（付記１）
ユーザ端末から分析条件を含む経営分析依頼を受信した場合、複数の業務システム・サーバのうちデータ更新処理を実施すべき第１業務システム・サーバを特定するためのシステム通知フラグを前記分析条件に対応して格納しているマスタデータベースから、当該分析条件に対応する前記システム通知フラグを抽出し、前記分析条件と抽出した前記システム通知フラグとを含むレコードを生成して管理データベースに格納するステップと、
前記管理データベースに格納されている特定のレコードに含まれる前記分析条件に基づき、前記複数の業務システムの各々の業務に関するデータであって経営分析に用いる分析データを格納するデータ格納部に格納されている前記分析データのうち前記分析条件に合致する第１分析データの更新指示を生成し、記憶装置に格納する更新指示生成ステップと、
前記特定のレコードに含まれる前記システム通知フラグに従って、前記記憶装置に格納された前記更新指示を、前記データ更新処理を実施すべき第１業務システム・サーバに送信する更新指示送信ステップと、
前記第１業務システム・サーバから、前記第１分析データのうち当該第１業務システム・サーバにおける前記データ更新処理によって更新された第２分析データを受信し、当該第２分析データに基づいて前記データ格納部を更新するステップと、
前記更新指示を送信した全ての前記第１業務システム・サーバから、前記データ更新処理の完了通知を受信したか否か判定するステップと、
前記更新指示を送信した全ての前記第１業務システム・サーバから、前記データ更新処理の完了通知を受信したと判定された場合、前記データ格納部に格納された前記第１分析データに基づき、前記分析条件に合致する経営分析データを生成し、前記ユーザ端末に送信するステップと、
をコンピュータに実行させるための経営分析処理プログラム。

（付記２）
前記レコードが、所定の優先度の情報をさらに含み、
前記更新指示生成ステップが、
前記管理データベースに複数の前記レコードが格納されている場合に、前記所定の優先度の情報に従って、複数の前記レコードから前記特定のレコードを特定するステップ
を含む付記１記載の経営分析処理プログラム。

（付記３）
前記所定の優先度の情報が、前記経営分析依頼の送信元のユーザに関連する第１優先度と前記分析条件に関連する第２優先度との少なくともいずれかを含む
付記２記載の経営分析処理プログラム。

（付記４）
前記更新指示送信ステップが、
前記管理データベースから前記特定のレコードを削除するステップ
を含む付記１記載の経営分析処理プログラム。

（付記５）
前記複数の業務システムが、医事会計システムと財務会計システムと人事給与システムと物流システムと固定資産システムと電子カルテシステムとのうち少なくとも２以上のシステムを含む
付記１記載の経営分析処理プログラム。

（付記６）
経営分析システム・サーバから、前記経営分析システム・サーバにおける経営分析処理で必要となる分析データの条件を含む更新指示を受信した場合、データ格納部に格納されている業務データのうち、前記更新指示に含まれる前記条件に合致する第１業務データを特定するステップと、
前記業務データの更新履歴情報を格納する更新管理データベースに格納されている前記更新履歴情報に基づき、前記第１業務データのうち更新されている第２業務データを特定する第２特定ステップと、
特定された前記第２業務データを含む前記分析データを生成し、前記経営分析システム・サーバに送信するステップと、
をコンピュータに実行させるための情報処理プログラム。

（付記７）
前記第２業務データに対応する前記更新履歴情報を前記更新管理データベースから削除し、前記第２特定ステップ以降のステップを実施するステップ
をさらに含み
前記第２特定ステップが、
前記更新管理データベースに格納されている前記更新履歴情報に基づき、前記第２業務データが存在するか否か判定するステップと、
前記第２業務データが存在しないと判定された場合、更新完了通知を前記経営分析システム・サーバに送信するステップと、
を含む付記６記載の情報処理プログラム。

（付記８）
複数の業務システム・サーバのうちデータ更新処理を実施すべき第１業務システム・サーバを特定するためのシステム通知フラグを、分析条件に対応して格納するマスタデータベースと、経営分析依頼に含まれる前記分析条件と当該分析条件に対応する前記システム通知フラグとを含むレコードを前記経営分析依頼毎に格納する管理データベースと、前記複数の業務システムの各々の業務に関するデータであって経営分析に用いる分析データを格納するデータ格納部と、記憶装置とを有し、且つ前記複数の業務システム・サーバに接続されるコンピュータにより実行される経営分析処理方法であって、
ユーザ端末から前記分析条件を含む前記経営分析依頼を受信した場合、前記マスタデータベースから当該分析条件に対応する前記システム通知フラグを抽出し、前記分析条件と抽出した前記システム通知フラグとを含むレコードを生成して前記管理データベースに格納するステップと、
前記管理データベースに格納されている特定のレコードに含まれる前記分析条件に基づき、前記分析データのうち前記分析条件に合致する第１分析データの更新指示を生成し、前記記憶装置に格納する更新指示生成ステップと、
前記特定のレコードに含まれる前記システム通知フラグに従って、前記記憶装置に格納された前記更新指示を、前記データ更新処理を実施すべき第１業務システム・サーバに送信する更新指示送信ステップと、
前記第１業務システム・サーバから、前記第１分析データのうち当該第１業務システム・サーバにおける前記データ更新処理によって更新された第２分析データを受信し、当該第２分析データに基づいて前記データ格納部を更新するステップと、
前記更新指示を送信した全ての前記第１業務システム・サーバから、前記データ更新処理の完了通知を受信したか否か判定するステップと、
前記更新指示を送信した全ての前記第１業務システム・サーバから、前記データ更新処理の完了通知を受信したと判定された場合、前記データ格納部に格納された前記第１分析データに基づき、前記分析条件に合致する経営分析データを生成し、前記ユーザ端末に送信するステップと、
を含む経営分析処理方法。

（付記９）
業務データを格納するデータ格納部と、前記業務データの更新履歴情報を格納する更新管理データベースとを有し、且つ経営分析システム・サーバに接続されるサーバにより実行される、経営分析における情報処理方法であって、
前記経営分析システム・サーバから、前記経営分析システム・サーバにおける経営分析処理で必要となる分析データの条件を含む更新指示を受信した場合、前記業務データのうち、前記更新指示に含まれる前記条件に合致する第１業務データを特定する第１特定ステップと、
前記更新管理データベースに格納されている前記更新履歴情報に基づき、前記第１業務データのうち更新されている第２業務データを特定する第２特定ステップと、
特定された前記第２業務データを含む前記分析データを生成し、前記経営分析システム・サーバに送信するステップと、
を含む情報処理方法。

（付記１０）
複数の業務システム・サーバに接続される経営分析処理装置であって、
複数の業務システム・サーバのうちデータ更新処理を実施すべき第１業務システム・サーバを特定するためのシステム通知フラグを、分析条件に対応して格納するマスタデータベースと、
経営分析依頼に含まれる前記分析条件と当該分析条件に対応する前記システム通知フラグとを含むレコードを前記経営分析依頼毎に格納する管理データベースと、
前記複数の業務システムの各々の業務に関するデータであって経営分析に用いる分析データを格納するデータ格納部と、
ユーザ端末から前記分析条件を含む前記経営分析依頼を受信した場合、前記マスタデータベースから当該分析条件に対応する前記システム通知フラグを抽出し、前記分析条件と抽出した前記システム通知フラグとを含むレコードを生成して前記管理データベースに格納する手段と、
前記管理データベースに格納されている特定のレコードに含まれる前記分析条件に基づき、前記分析データのうち前記分析条件に合致する第１分析データの更新指示を生成し、記憶装置に格納する手段と、
前記特定のレコードに含まれる前記システム通知フラグに従って、前記記憶装置に格納された前記更新指示を、前記データ更新処理を実施すべき第１業務システム・サーバに送信する手段と、
前記第１業務システム・サーバから、前記第１分析データのうち当該第１業務システム・サーバにおける前記データ更新処理によって更新された第２分析データを受信し、当該第２分析データに基づいて前記データ格納部を更新する手段と、
前記更新指示を送信した全ての前記第１業務システム・サーバから、前記データ更新処理の完了通知を受信したか否か判定する手段と、
前記更新指示を送信した全ての前記第１業務システム・サーバから、前記データ更新処理の完了通知を受信したと判定された場合、前記データ格納部に格納された前記第１分析データに基づき、前記分析条件に合致する経営分析データを生成し、前記ユーザ端末に送信する手段と、
を有する経営分析処理装置。

（付記１１）
経営分析システム・サーバに接続されるサーバであって、
業務データを格納するデータ格納部と、
前記業務データの更新履歴情報を格納する更新管理データベースと、
前記経営分析システム・サーバから、前記経営分析システム・サーバにおける経営分析処理で必要となる分析データの条件を含む更新指示を受信した場合、前記業務データのうち、前記更新指示に含まれる前記条件に合致する第１業務データを特定する手段と、
前記更新管理データベースに格納されている前記更新履歴情報に基づき、前記第１業務データのうち更新されている第２業務データを特定する手段と、
特定された前記第２業務データを含む前記分析データを生成し、前記経営分析システム・サーバに送信する手段と、
を有するサーバ。

本発明の実施の形態に係るシステム概要図である。 本発明の実施の形態における分析サーバの機能ブロック図である。 本発明の実施の形態における医事会計サーバの機能ブロック図である。 本発明の実施の形態における財務会計サーバの機能ブロック図である。 ユーザマスタＤＢに格納されるデータの一例を示す図である。 画面種別マスタＤＢに格納されるデータの一例を示す図である。 システム通知フラグの構造を説明するための図である。 優先レベルパターンデータ格納部に格納されるデータの一例を示す図である。 画面表示管理ＤＢに格納されるデータの一例を示す図である。 完了管理ＤＢに格納されるデータの一例を示す図である。 収支データ格納部に格納されるデータの一例を示す図である。 分析画面の表示例を示す図である。 経営分析依頼を受信した際の処理フローを示す図である。 更新指示を送信する際の処理フローを示す図である。 更新条件データ生成処理の処理フローを示す図である。 （ａ）乃至（ｃ）は、更新条件データの一例を示す図である。 更新指示を受信した際の処理フローを示す図である。 部門システムの更新処理の処理フローを示す図である。 更新管理ＤＢに格納されるデータの一例を示す図である。 会計データ格納部に格納されるデータの一例を示す図である。 正規化処理の処理フローを示す図である。 部門システムの更新処理の処理フローを示す図である。 分析結果を出力する際の処理フローを示す図である。 分析画面の表示例を示す図である。 コンピュータの機能ブロック図である。

符号の説明

１ ネットワーク ３ 分析サーバ
５ 医事会計サーバ ７ 財務会計サーバ
３１ ユーザマスタＤＢ ３２ 画面種別マスタＤＢ
３３ 優先レベルパターンデータ格納部 ３４ 分析画面表示処理部
３５ 画面表示管理ＤＢ ３６ 完了管理ＤＢ
３７ 管理部 ３８ 完了フラグ設定部
３９ 収支データ管理部 ４０ 収支データ格納部
５１，７１ 更新管理ＤＢ ５３，７３ キュー管理部
５４，７４ キュー ５５，７５ 正規化処理部
５２ 会計データ格納部 ７２ 財務データ格納部
３００ 病院経営分析システム ５００ 医事会計システム
７００ 財務会計システム

Claims (6)

1. ユーザ端末から分析条件を含む経営分析依頼を受信した場合、複数の業務システム・サーバのうちデータ更新処理を実施すべき第１業務システム・サーバを特定するためのシステム通知フラグを前記分析条件に対応して格納しているマスタデータベースから、当該分析条件に対応する前記システム通知フラグを抽出し、前記分析条件と抽出した前記システム通知フラグとを含むレコードを生成して管理データベースに格納するステップと、
   前記管理データベースに格納されている特定のレコードに含まれる前記分析条件に基づき、前記複数の業務システムの各々の業務に関するデータであって経営分析に用いる分析データを格納するデータ格納部に格納されている前記分析データのうち前記分析条件に合致する第１分析データの更新指示を生成し、記憶装置に格納する更新指示生成ステップと、
   前記特定のレコードに含まれる前記システム通知フラグに従って、前記記憶装置に格納された前記更新指示を、前記データ更新処理を実施すべき第１業務システム・サーバに送信する更新指示送信ステップと、
   前記第１業務システム・サーバから、前記第１分析データのうち当該第１業務システム・サーバにおける前記データ更新処理によって更新された第２分析データを受信し、当該第２分析データに基づいて前記データ格納部を更新するステップと、
   前記更新指示を送信した全ての前記第１業務システム・サーバから、前記データ更新処理の完了通知を受信したか否か判定するステップと、
   前記更新指示を送信した全ての前記第１業務システム・サーバから、前記データ更新処理の完了通知を受信したと判定された場合、前記データ格納部に格納された前記第１分析データに基づき、前記分析条件に合致する経営分析データを生成し、前記ユーザ端末に送信するステップと、
   をコンピュータに実行させるための経営分析処理プログラム。
2. 前記レコードが、所定の優先度の情報をさらに含み、
   前記更新指示生成ステップが、
   前記管理データベースに複数の前記レコードが格納されている場合に、前記所定の優先度の情報に従って、複数の前記レコードから前記特定のレコードを特定するステップ
   を含む請求項１記載の経営分析処理プログラム。
3. 経営分析システム・サーバから、前記経営分析システム・サーバにおける経営分析処理で必要となる分析データの条件を含む更新指示を受信した場合、データ格納部に格納されている業務データのうち、前記更新指示に含まれる前記条件に合致する第１業務データを特定するステップと、
   前記業務データの更新履歴情報を格納する更新管理データベースに格納されている前記更新履歴情報に基づき、前記第１業務データのうち更新されている第２業務データを特定する第２特定ステップと、
   特定された前記第２業務データを含む前記分析データを生成し、前記経営分析システム・サーバに送信するステップと、
   をコンピュータに実行させるための情報処理プログラム。
4. 前記第２業務データに対応する前記更新履歴情報を前記更新管理データベースから削除し、前記第２特定ステップ以降のステップを実施するステップ
   をさらに含み
   前記第２特定ステップが、
   前記更新管理データベースに格納されている前記更新履歴情報に基づき、前記第２業務データが存在するか否か判定するステップと、
   前記第２業務データが存在しないと判定された場合、更新完了通知を前記経営分析システム・サーバに送信するステップと、
   を含む請求項３記載の情報処理プログラム。
5. 複数の業務システム・サーバのうちデータ更新処理を実施すべき第１業務システム・サーバを特定するためのシステム通知フラグを、分析条件に対応して格納するマスタデータベースと、経営分析依頼に含まれる前記分析条件と当該分析条件に対応する前記システム通知フラグとを含むレコードを前記経営分析依頼毎に格納する管理データベースと、前記複数の業務システムの各々の業務に関するデータであって経営分析に用いる分析データを格納するデータ格納部と、記憶装置とを有し、且つ前記複数の業務システム・サーバに接続されるコンピュータにより実行される経営分析処理方法であって、
   ユーザ端末から前記分析条件を含む前記経営分析依頼を受信した場合、前記マスタデータベースから当該分析条件に対応する前記システム通知フラグを抽出し、前記分析条件と抽出した前記システム通知フラグとを含むレコードを生成して前記管理データベースに格納するステップと、
   前記管理データベースに格納されている特定のレコードに含まれる前記分析条件に基づき、前記分析データのうち前記分析条件に合致する第１分析データの更新指示を生成し、前記記憶装置に格納する更新指示生成ステップと、
   前記特定のレコードに含まれる前記システム通知フラグに従って、前記記憶装置に格納された前記更新指示を、前記データ更新処理を実施すべき第１業務システム・サーバに送信する更新指示送信ステップと、
   前記第１業務システム・サーバから、前記第１分析データのうち当該第１業務システム・サーバにおける前記データ更新処理によって更新された第２分析データを受信し、当該第２分析データに基づいて前記データ格納部を更新するステップと、
   前記更新指示を送信した全ての前記第１業務システム・サーバから、前記データ更新処理の完了通知を受信したか否か判定するステップと、
   前記更新指示を送信した全ての前記第１業務システム・サーバから、前記データ更新処理の完了通知を受信したと判定された場合、前記データ格納部に格納された前記第１分析データに基づき、前記分析条件に合致する経営分析データを生成し、前記ユーザ端末に送信するステップと、
   を含む経営分析処理方法。
6. 複数の業務システム・サーバに接続される経営分析処理装置であって、
   複数の業務システム・サーバのうちデータ更新処理を実施すべき第１業務システム・サーバを特定するためのシステム通知フラグを、分析条件に対応して格納するマスタデータベースと、
   経営分析依頼に含まれる前記分析条件と当該分析条件に対応する前記システム通知フラグとを含むレコードを前記経営分析依頼毎に格納する管理データベースと、
   前記複数の業務システムの各々の業務に関するデータであって経営分析に用いる分析データを格納するデータ格納部と、
   ユーザ端末から前記分析条件を含む前記経営分析依頼を受信した場合、前記マスタデータベースから当該分析条件に対応する前記システム通知フラグを抽出し、前記分析条件と抽出した前記システム通知フラグとを含むレコードを生成して前記管理データベースに格納する手段と、
   前記管理データベースに格納されている特定のレコードに含まれる前記分析条件に基づき、前記分析データのうち前記分析条件に合致する第１分析データの更新指示を生成し、記憶装置に格納する手段と、
   前記特定のレコードに含まれる前記システム通知フラグに従って、前記記憶装置に格納された前記更新指示を、前記データ更新処理を実施すべき第１業務システム・サーバに送信する手段と、
   前記第１業務システム・サーバから、前記第１分析データのうち当該第１業務システム・サーバにおける前記データ更新処理によって更新された第２分析データを受信し、当該第２分析データに基づいて前記データ格納部を更新する手段と、
   前記更新指示を送信した全ての前記第１業務システム・サーバから、前記データ更新処理の完了通知を受信したか否か判定する手段と、
   前記更新指示を送信した全ての前記第１業務システム・サーバから、前記データ更新処理の完了通知を受信したと判定された場合、前記データ格納部に格納された前記第１分析データに基づき、前記分析条件に合致する経営分析データを生成し、前記ユーザ端末に送信する手段と、
   を有する経営分析処理装置。

Images