JP2006215601A

JP2006215601A - 統合業務システム

Info

Publication number: JP2006215601A
Application number: JP2005024702A
Authority: JP
Inventors: Katsumi Takano; 勝巳高野
Original assignee: Osk Co Ltd
Current assignee: Osk Co Ltd
Priority date: 2005-02-01
Filing date: 2005-02-01
Publication date: 2006-08-17
Anticipated expiration: 2025-02-01
Also published as: JP4217222B2

Abstract

【課題】
本発明は、基幹系システムとワークフローシステムとからなる統合業務システムに於いて、変換テーブルを用いずにデータの連携を行うことを目的とする。
【解決手段】
ワークフローシステムは、ワークフロー側データテーブルと、申請データを記録する申請処理手段と、申請データを順に承認者に通知し、最終承認者から承認通知を受信すると抽出フラグを抽出対象に更新する承認処理手段と、Ｗｅｂサービスで申請データのデータチェックを行うデータチェック手段と、を有し、基幹系システムは、基幹側データテーブルと、ワークフロー側データテーブルから申請データを取得してデータチェックを行い、エラーがない申請データを基幹側データテーブルに記録し、その申請データの抽出フラグをＷｅｂサービスで抽出済みに更新し、記録しない申請データの抽出フラグをＷｅｂサービスで否決に更新するデータ取込手段と、を有する統合業務システムである。
【選択図】図１

Description

本発明は、企業内の業務を遂行する為の統合業務システムに関する。詳細には、データを記憶・管理する基幹系システムと、そのデータの申請、回覧、閲覧等を行うワークフローシステムとを有する統合業務システムに於いて、変換テーブルを用いずにリアルタイムで連携を行う統合業務システムに関する。

企業で人事、給与、財務会計、販売、購買等の業務を遂行する為に、これらをコンピュータ管理する統合業務システムと呼ばれるコンピュータシステムがあり、企業運営の中枢を担っている。

この統合業務システムは、人事、給与、財務会計、販売、購買等の業務のデータをサーバで記憶、管理する基幹系システムと、そのデータを個々の社員に対して閲覧させたり、社員からデータの申請、回覧、記録等を受け付け、その制御を行うワークフローシステムとの２つの系統のシステムから成立している。本明細書で基幹系システムとは、販売管理システム、財務管理システム、人事給与管理システム、生産管理システム等の各モジュールがリアルタイムに連携し、データを一括管理するシステムであり、ワークフローシステムとは、業務に於ける様々な申請や承認処理をネットワークを介して電子的に行うことで、各種申請が申請者から承認者へ自動的に通知され、次々に承認ルートを経ていくシステムである。

統合業務システムは、このような２つの系統のシステムから成立してるため、ワークフローシステムで入力されたデータを基幹系システムに反映させる為には、ワークフローシステムと基幹系システムとの双方でデータを用意しておき、データの入力時にはワークフローシステムのデータを更新し、後に所定のタイミングに於いて、バッチ処理で基幹系システムにデータを反映するという作業を行っている。この場合、いずれかのシステムに於いてデータが更新された場合、双方のシステムでデータの不整合が発生することとなる。

そこでリアルタイムでデータの更新が行えることが望まれるが、基幹系システムとワークフローシステムのデータは、各々データの管理の方法、表示の方法等が異なる為、単純にデータを反映させることは出来ず、下記特許文献１や特許文献２のように基幹系システムとワークフローシステムとの間に、変換テーブルを用意しておき、その変換テーブルで変換後にデータの反映作業を行うこととしている。

特開２０００−１７２７７０号公報特開２００１−１４４００号公報

変換テーブルを用いることによってリアルタイムでデータの反映を行えるが、変換テーブルのメンテナンスが必要となる。基幹系システムに於いて、例えば新たな得意先企業が増えた場合、ワークフローシステムで新たな得意先企業の情報を記録し、それを基幹系システムに反映させることとなるが、変換テーブルにワークフローシステムと基幹系システムとの間でデータの変換を行う為に変換テーブルの修正作業を行う必要がある。また事前に変換テーブルも用意しておかなければならない。

又、通常はワークフローシステムでデータの申請が承認されたならば基幹系システムにそのデータが自動的に記録されることとなる。

そこで本発明者は、従来のような変換テーブルを用いずにＷｅｂサービスと呼ばれる技術を用いることによってリアルタイムでワークフローシステムと基幹系システムとの間のデータを連携する統合業務システムを発明した。又、本発明の統合業務システムでは、ワークフローシステムで承認されたデータについて、更に基幹系システムでもデータチェックを行った後に、データの記録を行う、いわば、基幹系システムをワークフローシステム申請データを承認する最終承認者として扱う（基幹系システムのデータ取込処理を擬人化する）ことで、記録されるデータの信頼性を向上させる統合業務システムを発明した。

請求項１の発明は、申請者が利用する申請者側端末から送信する申請データの承認を、承認者が利用する承認者側端末で行うことで前記申請データを新たに記録する統合業務システムであって、前記統合業務システムは、前記申請データの申請処理、承認処理を前記申請者側端末と前記承認者側端末との間でネットワークを介して行うワークフローシステムと、前記ワークフローシステムで最終承認された前記申請データを前記ワークフローシステムから取得して記録、管理する基幹系システムと、を有しており、前記基幹系システムは、前記最終承認された前記申請データを前記ワークフローシステムから取得する際に、前記基幹系システムが有する基幹側データテーブルを参照することにより、前記最終承認された前記申請データのエラーの有無についてデータチェックを行い、エラーがない場合に、前記最終承認された前記申請データを前記基幹側データテーブルに記録する、統合業務システムである。

統合業務システムをこのように構成することによって、従来のように変換テーブルを用いずにリアルタイムでワークフローシステムと基幹系システムとのデータの連携が可能となる。又、ワークフローシステムで承認されたデータを、更に基幹系システムでもデータチェックを行った後にデータの記録を行うことで、記録されるデータの信頼性を向上させる。即ち、従来のようにワークフローシステム側でのデータチェック、承認処理のみでは対応しきれない、基幹系システムに依存する問題（例えば基幹側データテーブルの記録領域が不足して記録できない等）によるエラーにも対応することが出来る。

請求項２の発明は、申請者が利用する申請者側端末から送信する申請データの承認を、承認者が利用する承認者側端末で行うことで前記申請データを新たに記録する統合業務システムであって、前記統合業務システムは、前記申請データの申請処理、承認処理を前記申請者側端末と前記承認者側端末との間でネットワークを介して行うワークフローシステムと、前記ワークフローシステムで最終承認された前記申請データを前記ワークフローシステムから取得して記録、管理する基幹系システムと、を有しており、前記ワークフローシステムは、前記申請データと抽出フラグとを対応付けて記録するワークフロー側データテーブルと、前記申請者側端末から前記申請データを受信して前記ワークフロー側データテーブルに記録する申請処理手段と、前記ワークフロー側データテーブルに新たに記録された申請データを予め定められた承認者が利用する承認者側端末に通知し、前記承認者側端末から承認の通知を受信することで、次の順番の承認者が利用する承認者側端末に前記新たに記録された申請データの通知を送信する処理を最終承認者が利用する承認者側端末に通知するまで反復し、前記最終承認者による承認者側端末から承認の通知を受信すると、前記ワークフロー側データテーブルの前記抽出フラグを抽出対象に更新する承認処理手段と、前記基幹系システムをＷｅｂサービスを用いて参照することで前記申請データのデータチェックを行うデータチェック手段と、を有しており、前記基幹系システムは、前記ワークフローシステムから取得した前記申請データを記録する基幹側データテーブルと、前記ワークフロー側データテーブルに於いて前記抽出フラグが抽出対象である申請データを取得し、前記基幹側データテーブルを参照することにより前記取得した申請データのデータチェックを行い、エラーがない申請データについては前記基幹側データテーブルに記録し、エラーがある申請データについては前記基幹側データテーブルに記録せず、前記記録した申請データについてはＷｅｂサービスを用いて前記ワークフローシステムに於ける前記抽出フラグを抽出済みに更新し、前記記録しない申請データについてはＷｅｂサービスを用いて前記ワークフローシステムに於ける前記抽出フラグを否決に更新する、データ取込手段と、を有する統合業務システムである。

請求項１の発明を更に詳細に構成すると、本発明のように構成できる。このように構成することで、上述と同様の効果を得ることが出来る。

請求項３の発明は、前記申請処理手段は、前記受信した申請データを前記ワークフロー側データテーブルに記録する前に、前記データチェック手段に於いてデータチェックを行わせ、前記データチェック手段から記録許可の通知を受信後、前記ワークフロー側データテーブルに前記受信した申請データを記録する、統合業務システムである。

このように申請データをワークフロー側データテーブルに登録する前にデータチェックを行うと良い。

請求項４の発明は、前記承認処理手段は、前記承認者側端末に前記新たに記録された申請データの通知を送信する前に、前記データチェック手段に於いてデータチェックを行わせ、前記データチェック手段からエラーがないことを示す通知を受信後、前記次の承認者側端末に前記新たに記録された申請データの通知を送信する、統合業務システムである。

このように新たに記録された申請データの通知を承認者側端末に送信する前に再度データチェックを行うと良い。

請求項５の発明は、前記データチェック手段は、前記申請データと重複するデータが前記基幹側データテーブルにあるかをチェックする重複チェックと、前記申請データに於ける必須のデータが全て存在するかをチェックする必須チェックのうち、いずれか一以上を含んでいる、統合業務システムである。

データチェック手段が行うデータチェックではこのようなチェックを行える。

本発明によって、変換テーブルを用いずにＷｅｂサービスと呼ばれる技術を用いることによってリアルタイムでワークフローシステムと基幹系システムとの間のデータを連携する統合業務システムが可能となる。又、本発明の統合業務システムでは、ワークフローシステムで承認されたデータについて、更に基幹系システムでもデータチェックを行った後に、データの記録を行う、いわば、基幹系システムをワークフローシステム申請データを承認する最終承認者として扱う（基幹系システムのデータ取込処理を擬人化する）ことで、記録されるデータの信頼性を向上させる統合業務システムが可能となる。

本発明の統合業務システム１の概念図を図１に、システム構成の一例を図２のシステム構成図に示す。本発明の統合業務システム１は、基幹系システム２とワークフローシステム３とを有している。申請者が利用する申請者側端末１０と承認者が利用する承認者側端末１１とは、ワークフローシステム３とデータの送受信が可能であり、申請者は申請者側端末１０から申請事項（申請データ）の入力をし、それをワークフローシステム３で受信した後、所定の承認者端末へ送信し、順次、承認の指示をワークフローシステム３が承認者側端末１１から受信する。そして最終承認者による承認が終了後、基幹系システム２に申請事項（申請データ）が記録、反映される。

ここで基幹系システム２とは、販売管理システム、財務管理システム、人事給与管理システム、生産管理システム等の各モジュールがリアルタイムに連携し、データを一括管理するシステムであり、ワークフローシステム３とは、業務に於ける様々な申請や承認処理をネットワークを介して電子的に行うことで、各種申請が申請者から承認者へ自動的に通知され、次々に承認ルートを経ていくシステムである。

基幹系システム２は、データ取込手段４と基幹側データテーブル５とを有している。

データ取込手段４は、ワークフローシステム３で最終承認された申請データをワークフローシステム３から取得し、基幹側データテーブル５に記録して反映する手段である。データを取得するには、基幹系システム２のオペレータがデータ取込の指示を基幹系システム２で入力し、それを基幹系システム２で受信することによって行っても良いし、最終承認が終了後、ワークフローシステム３からデータ取込要求が送信され、それをデータ取込手段４で受信することによって行っても良い。

オペレータがデータ取込の指示を行う場合には、その指示によりデータ取込手段４がワークフロー側データテーブル９（後述）の抽出フラグを確認し、抽出対象（「１」）のフラグを有している申請データを取得する。ワークフローシステム３から取得する申請データの一覧リストの概念図を図５に示す。

またデータ取込手段４は、申請データを基幹側データテーブル５に記録する前に、最終承認された申請データを記録するかのデータチェックを行う。そして記録可能な申請データのみを基幹側データテーブル５に記録して反映する。申請データを基幹側データテーブル５に取り込んだ結果の通知の概念図を図６に示す。取込結果の通知はその「プレビュー」ボタンを押下することによって、エラーとなった申請データの一覧リストを図７に示すように閲覧できる。

基幹側データテーブル５は、基幹系システム２で用いるシステムの各データを記録するデータテーブルであって、基幹系システム２が販売管理システムの場合には販売管理で用いるデータ、財務管理システムの場合には財務管理で用いるデータ、人事給与管理システムの場合には人事給与管理で用いるデータ、生産管理システムの場合には生産管理で用いるデータを記録している。

ワークフローシステム３は、申請処理手段６と承認処理手段７とデータチェック手段８とワークフロー側データテーブル９とを有している。

申請処理手段６は、申請者が申請する申請事項のデータ（申請データ）を申請者側端末１０から受信し、ワークフロー側データテーブル９に記録する手段である。尚、ワークフローシステム３に記録する前に、後述するデータチェック手段８で申請データのデータチェックが行われ、そこから記録可能の通知を受信した後にワークフロー側データテーブル９に記録を行う。

承認処理手段７は、申請者が申請した申請データがワークフロー側データテーブル９に記録された場合、所定の順番（通常は予め定められた承認順番の下位のものから順番に）で承認者側端末１１に新たな申請が行われたことの通知を送信し、承認者側端末１１から承認の通知を受信すると、次の上位の承認者側端末１１に対して新たな申請が行われたことの通知を送信し、最終承認者が利用する承認者側端末１１から承認の通知を受信すると、ワークフロー側データテーブル９の当該申請データの抽出フラグを「１」（抽出対象）に更新する手段である。尚、この際に基幹側システムにデータ取込要求を送信しても良い。このようにして抽出フラグが「１」（抽出対象）になった場合に、ワークフロー側データテーブル９に記録された申請データは、基幹系システム２から取込処理が行われる。尚、各承認者から承認の通知を受信する場合に、後述するデータチェック手段８で申請データのデータチェックを行い、そこから記録可能の通知を受信した後に、次の承認者の承認者側端末１１に対して新たな申請が行われたことの通知を送信する。

尚、承認処理の承認順番は、所定のデータテーブルにその順番を申請の種類毎に予め記録しておき、それを参照することによって承認の順番を特定する。また申請データに対して承認を行った者を示すフラグを設け、そのフラグを順次更新することで、承認の段階を管理することが出来る。このような承認の回覧等は公知のワークフローシステム３の機能を用いることが出来る。

データチェック手段８は、申請者側端末１０から受信した申請データ、ワークフロー側データテーブル９に記録された各承認者の承認段階に於ける申請データのデータチェックをＷｅｂサービスを用いて基幹系システム２の基幹側データテーブル５を参照して確認する手段である。確認後、エラーがなければ申請処理手段６又は承認処理手段７に対して記録可能の通知又はエラーがないことを示す通知を送信する。

データチェック手段８が基幹側データテーブル５を参照して行うデータチェックには重複チェック、必須チェックのデータチェックがある。重複チェックとは、例えば新たな得意先の情報を記録する場合に於いて、入力された申請データに於ける得意先名、電話番号等のデータと同一のデータが既に基幹側データテーブル５に記録されているかを参照するチェックである。必須チェックとは申請データを入力する際に省略することが出来ないデータ（必須データ）の全てが入力されているか、を行うチェックである。例えば新たな得意先の情報を記録する場合に於いて、得意先名等省略することの出来ない必須データが全て入力されているかをチェックする。又、データチェックとして存在チェックを行うことも好ましい。存在チェックとは、基幹系システム２の基幹側データテーブル５をＷｅｂサービスを用いて参照することにより、申請データに於けるコード（例えば担当者コード）が基幹側データテーブル５に記録しているコードと一致するか否かを確認するチェックである。例えば担当者が既に退職等により存在しない場合、その担当者コードが記述された申請データはエラーとなる。

尚、上記のＷｅｂサービスとは、ＷＷＷ関連の技術を使い、ソフトウェアの機能をネットワークを通じて利用できるようにした技術であり、例えばマイクロソフト社が提供するMicrosoft .NETやIBM社が提供するUDDIプロジェクトなどがある。本発明に於いてＷｅｂサービスは、ワークフローシステム３と基幹系システム２との機能間のデータ呼出・記録手段として用いることが好ましい。

本実施形態では申請処理手段６でワークフロー側データテーブル９に申請データを記録する前、承認処理手段７で承認者側端末１１に承認の通知を送信する前に、データチェック手段８で各々データチェックをする場合を示しているが、これに限定されず、記録した後、承認の通知を送信した後であっても良い。

ワークフロー側データテーブル９は、申請データと抽出フラグとを対応付けて記録するデータテーブルである。抽出フラグは「１」（抽出対象）、「９」（抽出済み）、「２」（否決）が設けられており、各々の申請データにはいずれかのフラグが割り当てられている。「１」の抽出フラグが割り当てられていると、その申請データは基幹系システム２のデータ取込処理の対象となる。「２」の場合には最終承認者による最終承認が行われたが、基幹系システム２でのデータ取込の際のデータチェックで何らかの理由によりエラーとなった場合を示す。「９」の場合には既に基幹系システム２の基幹側データテーブル５に記録、反映されていることを示す。

申請者側端末１０は、申請データを基幹系システム２に記録しようとする申請者が利用するコンピュータ端末であって、各種の申請フォーム（画面）に申請データを入力することによって行う。

承認者側端末１１は、申請者が入力した申請データの記録を承認する承認者が利用するコンピュータ端末であって、ワークフローシステム３から新たな申請が行われたことの通知を受信し、それによってワークフロー側データテーブル９に記録した申請データの承認の通知を送信する。尚、本明細書では承認者側端末１１として１つを示しているが、実際は各承認者が利用する各自のコンピュータ端末となるので、承認者が複数いる場合には複数の承認者側端末１１となる。

尚、申請者及び承認者は、統合業務システム１を用いる企業で働く者である。

次に本発明の統合業務システム１の処理プロセスの一例を図３のフローチャート及び図２のシステム構成図とを用いて説明する。尚、本実施例では基幹系システム２に新規得意先を記録（申請）する場合を説明するが、販売管理システム、財務管理システム、人事給与管理システム、生産管理システム等の様々な申請データを記録することが出来る。

申請者がワークフローシステム３で所定の操作をする（例えば申請データを記録するボタン等を押下する）ことによって、申請データを入力するフォーム（画面）を申請者側端末１０で表示する（Ｓ１００）。ここでは新規得意先を記録（申請）するので、新規得意先を記録するフォームが表示される。図４に新規得意先を記録するフォームの一例を示す。図４では新規得意先の申請データとして、得意先名、得意先略称、郵便番号、住所、電話番号、担当者名、担当者コード等がある。

申請者は申請者側端末１０から申請フォームに申請データを入力し、所定の操作をする（例えば申請フォームの「申請」ボタンを押下する等）ことによって、申請データが申請者側端末１０からワークフローシステム３の申請処理手段６に送信される。

申請データを申請処理手段６で受信すると、データチェック手段８が、申請者側端末１０から受信した申請データのデータチェックをＷｅｂサービスを用いて基幹系システム２の基幹側データテーブル５を参照して確認する（Ｓ１１０）。

ここでデータチェック手段８が行う申請データのチェックは、基幹側データテーブル５を参照して重複チェック、必須チェックのデータチェックを行う。重複チェックは申請データと同一のデータ、ここでは例えば申請データとして同一の得意先名があるか、等をチェックすることによって、重複したデータを記録しないように重複チェックを行う。必須チェックは、申請データのうち、必須項目として指定されているデータを基幹側データテーブル５を参照して確認し、必須データの全てが申請データに含まれているかを確認する。

このデータチェックを行った後、エラーがなければデータチェック手段８は、申請処理手段６に対して記録可能の通知を送信し、それを受信した申請処理手段６は、申請者側端末１０から受信した申請データを新たな申請事項としてワークフロー側データテーブル９に記録する（Ｓ１２０）。エラーがあった場合には、申請処理手段６に対してエラー通知を送信し、それを受けて申請処理手段６は、申請データについてエラーがあったことを申請者側端末１０に送信し、修正を促す。

ワークフロー側データテーブル９に新たな申請データが記録されると、最初の承認者の利用する承認者側端末１１に対して承認処理手段７が新たな申請が行われたことの通知を送信する。承認者の順番は予めワークフロー側データテーブル９や所定のデータテーブルに記憶されており、それを参照することによって承認者を判定すると良い。

この通知を承認者側端末１１で受信して承認者が所定の操作を行う（例えば申請の閲覧等のボタンを押下する）と、承認処理手段７がワークフロー側データテーブル９から当該申請データを抽出して承認者側端末１１に送信する。そしてこの送信の際には、データチェック手段８がワークフロー側データテーブル９に記録された申請データのデータチェックを行い、エラーがないことの通知をデータチェック手段８から受信した後に、送信すると良い（Ｓ１３０）。

承認者は、承認者側端末１１で新たにワークフロー側データテーブル９に記録された申請データを閲覧し（Ｓ１４０）、その承認を行う場合には所定の操作を行う（例えば承認のボタンを押下する）ことによって承認の通知が承認者側端末１１からワークフローシステム３の承認処理手段７に送信される。尚、中間の承認者では申請データの内容の修正は行えないこととすると良い。承認の通知を承認処理手段７で受信すると（Ｓ１５０）、承認処理手段７は、次の順位の承認者が利用する承認者側端末１１に対して新たな申請が行われたことの通知を送信する（Ｓ１６０）。次の順位の承認者も上述と同様の処理を行う。

このようにして複数の承認者を経た後、新たな申請が行われたことの通知を承認処理手段７は、最終承認者が利用する承認者側端末１１に送信する。最終承認者でも上述と同様に、この通知を承認者側端末１１で受信して最終承認者が所定の操作を行う（例えば申請の閲覧等のボタンを押下する）と、承認処理手段７がワークフロー側データテーブル９から当該申請データを抽出して承認者側端末１１に送信する。そしてこの送信の際には、データチェック手段８がワークフロー側データテーブル９に記録された申請データのデータチェックを行い、エラーがないことの通知をデータチェック手段８から受信した後に、送信すると良い（Ｓ１７０）。

最終承認者は、承認者側端末１１で新たに記録された申請データを閲覧し（Ｓ１８０）、その承認を行う場合には所定の操作を行う（例えば承認のボタンを押下する）ことによって承認の通知が承認者側端末１１からワークフローシステム３の承認処理手段７に送信される。承認の通知を承認処理手段７で受信すると（Ｓ１９０）、承認処理手段７は、最終承認者による承認が行われたとして、ワークフロー側データテーブル９の当該申請データの抽出フラグを「１」（抽出対象）に更新する（Ｓ２００）。ワークフロー側データテーブル９の抽出フラグによって、基幹系システム２のデータ取込手段４が取得する申請データを選択するので、当該申請データが基幹系システム２のデータ取込の際の抽出対象になる。

基幹系システム２のオペレータがデータ取込の指示を基幹系システム２で入力し、それを基幹系システム２で受信した場合（Ｓ２１０）、或いは承認処理手段７での最終承認が終了後、抽出フラグを更新したことで承認処理手段７が基幹系システム２に対してデータ取込要求を送信しその要求を受信した場合（Ｓ２１０）、ワークフロー側データテーブル９に於いて、抽出フラグが「１」（抽出対象）である申請データを取得する（Ｓ２２０）。取得する申請データの一覧リストの概念図を図５に示す。尚、ここで取得する申請データの一覧をオペレータの端末で示すことにより、取り込む申請データ、取り込まない申請データの選択の入力をオペレータの端末から受け付け、取り込む申請データのみ取得することとしても良い。

データ取込手段４が申請データをワークフローシステム３から取得後、データ取込手段４は、当該申請データを基幹側データテーブル５に記録する前に、最終承認された申請データを記録するかのデータチェックを行う（Ｓ２３０）。データチェックは上述のデータチェック手段８と同様に重複チェック、必須チェックを基幹側データテーブル５を参照して行い、エラーがなければ取込可能であるとして基幹側データテーブル５に記録する。エラーがあった場合には、データ取込手段４は、当該申請データを記録しない。

Ｓ２３０に於けるデータ取込手段４が申請データを基幹側データテーブル５に記録するか否かの判定は、上述のデータチェック手段８と同様の重複チェックを行い、重複する申請データがある場合にはエラーとなる。更に、申請データを取り込むだけの記憶領域を基幹側データテーブル５に不足している場合も物理的に記録できない場合なので、エラーと判定する。尚、Ｓ２３０に於ける判定の基準には、これ以外にも事前に設定を行うことが出来、それを記録したマスタ（取込対応マスタ）（図示せず）を基幹系システム２に備えておき、それを参照することによって行うことが出来る。取込結果の一覧リストの概念図を図６に示す。図６の「プレビュー」ボタンを押下することによって、エラーとなった申請データの一覧リストを表示することが出来る。これを図７に示す。

データ取込手段４が申請データを基幹側データテーブル５に記録した場合には、データ取込手段４は、Ｗｅｂサービスを用いて、ワークフロー側データテーブル９の当該申請データの抽出フラグを「１」（抽出対象）から「９」（抽出済み）に更新し、記録しない場合には、データ取込手段４は、ワークフロー側データテーブル９の当該申請データの抽出フラグを「１」（抽出対象）から「２」（否決）に更新する（Ｓ２４０）。申請者に否決を通知するように構成しても良い。

このようにＷｅｂサービスを用いることによって、変換テーブルを用いずに基幹系システム２とワークフローシステム３の２つのシステムでリアルタイムにデータの記録、反映が行える。またワークフローシステム３での承認処理のみならず、基幹系システム２での申請データの取込の際にもデータチェックを行うことによって、例えば基幹系システム２に依存する問題でエラーになった場合にも、そのことをワークフロー側データテーブル９の抽出フラグを更新することで反映できる。

本発明に於ける各手段、データテーブルは、その機能が論理的に区別されているのみであって、物理上あるいは事実上は同一の領域を為していても良い。

尚、本発明を実施するにあたり本実施態様の機能を実現するソフトウェアのプログラムを記録した記憶媒体をシステムに供給し、そのシステムのコンピュータが記憶媒体に格納されたプログラムを読み出し実行することによって実現されることは当然である。

この場合、記憶媒体から読み出されたプログラム自体が前記した実施態様の機能を実現することとなり、そのプログラムを記憶した記憶媒体は本発明を当然のことながら構成することになる。

プログラムを供給する為の記憶媒体としては、例えば磁気ディスク、ハードディスク、光ディスク、光磁気ディスク、磁気テープ、不揮発性のメモリカード等を使用することができる。

又、コンピュータが読み出したプログラムを実行することにより、上述した実施態様の機能が実現されるだけではなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているオペレーティングシステムなどが実際の処理の一部又は全部を行い、その処理によって前記した実施態様の機能が実現される場合も含まれることは言うまでもない。

更に、記憶媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わる不揮発性あるいは揮発性の記憶手段に書き込まれた後、そのプログラムの指示に基づき、機能拡張ボードあるいは機能拡張ユニットに備わる演算処理装置などが実際の処理の一部あるいは全部を行い、その処理により前記した実施態様の機能が実現される場合も含まれることは当然である。

本発明によって、変換テーブルを用いずにＷｅｂサービスと呼ばれる技術を用いることによってリアルタイムでワークフローシステム３と基幹系システム２との間のデータを連携する統合業務システム１が可能となる。更に、その統合業務システム１では、ワークフローシステム３で承認されたデータを、更に基幹系システム２でもデータチェックを行った後にデータの記録を行うことで、記録されるデータの信頼性を向上させる統合業務システム１が可能となる

本発明の概念図である。本発明のシステム構成の一例を示すシステム構成図である。本発明の処理プロセスの一例を示すフローチャートである。申請フォームの一例である。ワークフローシステムから取得する申請データの一覧リストの概念図である。申請データを基幹側データテーブルに取り込んだ結果の通知の概念図である。基幹系システムに申請データを取り込む際にエラーとなった申請データの一覧リストの概念図である。

符号の説明

１：統合業務システム
２：基幹系システム
３：ワークフローシステム
４：データ取込手段
５：基幹側データテーブル
６：申請処理手段
７：承認処理手段
８：データチェック手段
９：ワークフロー側データテーブル
１０：申請者側端末
１１：承認者側端末

Claims

申請者が利用する申請者側端末から送信する申請データの承認を、承認者が利用する承認者側端末で行うことで前記申請データを新たに記録する統合業務システムであって、
前記統合業務システムは、前記申請データの申請処理、承認処理を前記申請者側端末と前記承認者側端末との間でネットワークを介して行うワークフローシステムと、前記ワークフローシステムで最終承認された前記申請データを前記ワークフローシステムから取得して記録、管理する基幹系システムと、を有しており、
前記基幹系システムは、
前記最終承認された前記申請データを前記ワークフローシステムから取得する際に、前記基幹系システムが有する基幹側データテーブルを参照することにより、前記最終承認された前記申請データのエラーの有無についてデータチェックを行い、エラーがない場合に、前記最終承認された前記申請データを前記基幹側データテーブルに記録する、
ことを特徴とする統合業務システム。
申請者が利用する申請者側端末から送信する申請データの承認を、承認者が利用する承認者側端末で行うことで前記申請データを新たに記録する統合業務システムであって、
前記統合業務システムは、前記申請データの申請処理、承認処理を前記申請者側端末と前記承認者側端末との間でネットワークを介して行うワークフローシステムと、前記ワークフローシステムで最終承認された前記申請データを前記ワークフローシステムから取得して記録、管理する基幹系システムと、を有しており、
前記ワークフローシステムは、
前記申請データと抽出フラグとを対応付けて記録するワークフロー側データテーブルと、
前記申請者側端末から前記申請データを受信して前記ワークフロー側データテーブルに記録する申請処理手段と、
前記ワークフロー側データテーブルに新たに記録された申請データを予め定められた承認者が利用する承認者側端末に通知し、前記承認者側端末から承認の通知を受信することで、次の順番の承認者が利用する承認者側端末に前記新たに記録された申請データの通知を送信する処理を最終承認者が利用する承認者側端末に通知するまで反復し、前記最終承認者による承認者側端末から承認の通知を受信すると、前記ワークフロー側データテーブルの前記抽出フラグを抽出対象に更新する承認処理手段と、
前記基幹系システムをＷｅｂサービスを用いて参照することで前記申請データのデータチェックを行うデータチェック手段と、を有しており、
前記基幹系システムは、
前記ワークフローシステムから取得した前記申請データを記録する基幹側データテーブルと、
前記ワークフロー側データテーブルに於いて前記抽出フラグが抽出対象である申請データを取得し、前記基幹側データテーブルを参照することにより前記取得した申請データのデータチェックを行い、エラーがない申請データについては前記基幹側データテーブルに記録し、エラーがある申請データについては前記基幹側データテーブルに記録せず、前記記録した申請データについてはＷｅｂサービスを用いて前記ワークフローシステムに於ける前記抽出フラグを抽出済みに更新し、前記記録しない申請データについてはＷｅｂサービスを用いて前記ワークフローシステムに於ける前記抽出フラグを否決に更新する、データ取込手段と、を有する
ことを特徴とする統合業務システム。
前記申請処理手段は、
前記受信した申請データを前記ワークフロー側データテーブルに記録する前に、前記データチェック手段に於いてデータチェックを行わせ、前記データチェック手段から記録許可の通知を受信後、前記ワークフロー側データテーブルに前記受信した申請データを記録する、
ことを特徴とする請求項２に記載の統合業務システム。
前記承認処理手段は、
前記承認者側端末に前記新たに記録された申請データの通知を送信する前に、前記データチェック手段に於いてデータチェックを行わせ、前記データチェック手段からエラーがないことを示す通知を受信後、前記次の承認者側端末に前記新たに記録された申請データの通知を送信する、
ことを特徴とする請求項２に記載の統合業務システム。
前記データチェック手段は、
前記申請データと重複するデータが前記基幹側データテーブルにあるかをチェックする重複チェックと、前記申請データに於ける必須のデータが全て存在するかをチェックする必須チェックのうち、いずれか一以上を含んでいる、
ことを特徴とする請求項２に記載の統合業務システム。