以下、本発明の一実施の形態の例について図面を参照して説明する。
図1は、本発明の一実施の形態に係る帳票照会システム500の構成例を示すブロック図である。図1に示すように、帳票照会システム500は、携帯端末管理サーバ10と、中継機20と、複数の携帯端末31〜3N(Nは任意の正の整数)と、統合基幹業務システム100と、統合基幹業務システム200と,統合基幹業務システム300とを含む。携帯端末管理サーバ10と各携帯端末31〜3Nとは、それぞれ、インターネットなどの通信ネットワーク40及び中継機20を介して接続される。携帯端末管理サーバ10は、統合基幹業務システム100、統合基幹業務システム200、統合基幹業務システム300と、それぞれLAN(Local Area Network)や専用通信回線などの通信ネットワーク51,52,53を介して接続される。なお、携帯端末同士や統合基幹業務システム同士は、携帯端末管理サーバを介して通信可能な構成としてもよいし、通信不能な構成としてもよい。
統合基幹業務システム100は、基幹業務サーバ110と、データウェアハウスサーバ(DWHサーバ)120と、プロセスフローDB101とを含む。統合基幹業務システム200は、DWHサーバ220と、プロセスフローDB201とを含む。統合基幹業務システム300は、基幹業務サーバ310と、プロセスフローDB301とを含む。
構成が異なる複数の統合基幹業務システム100,200,300は、必要に応じて(すなわち、それぞれが有する機能に応じて)携帯端末管理サーバ10と通信(各種情報の送受信)を行うことにより、統合基幹業務システムとしての機能を発揮する。すなわち、帳票照会システムにおいては、基幹業務サーバを有さないシステム200や、DWHサーバを有さないシステム300であっても、携帯端末管理サーバ10との通信を行うことにより、統合基幹業務システムとしての機能を発揮することができる。なお、図示しないが、プロセスフローDBを有さないシステムであっても、携帯端末管理サーバ10にてプロセスフローデータを記憶することにより、統合基幹業務システムとしての機能を発揮することができる。各基幹業務システムが備える基幹業務サーバ等には公知の技術が用いられるため、以下、統合基幹業務システム100を例にして説明を行う。
基幹業務サーバ110とDWHサーバ120とは、専用通信回線により接続されているものとする。
基幹業務サーバ110は、例えば帳票照会システム500の管理者によって管理されるサーバであり、各種業務に関する帳票情報を管理(例えば、情報の作成や更新、保存など。)するための各種の機能を有する。基幹業務サーバ110は、OS(Operating System)やリレーショナルDBを備えた一般的な情報処理装置によって構成される。
ここで、帳票とは、帳簿や伝票類の総称である。また、帳簿とは、金銭や品物の出納に関する事項が記入されるものであり、伝票とは、帳簿を作成する際の基となるデータであり業務上の取引等の証拠となるものである。本例においては、基幹業務サーバ110が、帳票データとして伝票データのみを示すプロセスデータを扱う場合を例に説明を行なう。
基幹業務サーバ110は、業務アプリケーションプログラムに従って各種の処理を実行する。業務アプリケーションプログラムとしては、例えば、販売業務管理プログラム、販売業務管理プログラム、生産管理プログラム、財務会計管理プログラム、および管理会計管理プログラムなどがある。
DWHサーバ120は、例えば本システムのシステム管理者によって管理されるサーバであり、データウェアハウスを実現するための各種の機能を有する。ここで、データウェアハウスとは、時系列で蓄積された帳票データなどの業務データの中から各項目間の関連性を分析するシステムをいう。また、DWHサーバ120は、基幹業務サーバ110から転送されたCSV形式のファイルを所定のデータ形式に変換するなどして、所定の格納領域(後述する業務関連データDB101b)に各種データを登録する機能を有する。なお、DWHサーバ120は、データ形式の変換を行わず、CSV形式の状態から各格納領域に応じたデータを抽出する構成とされていてもよい。
プロセスフローDB101は、基幹業務サーバ110の業務アプリケーションプログラムDB(図示せず)に記憶された各種プログラムを用いた各種情報処理によって収集・整理等された各種のプロセスデータ(または帳票データ)により構成されるプロセスフローデータを記憶する記憶媒体である。なお、プロセスフローデータについては、後で詳しく説明する。また、本例においては、統合基幹業務システム100は、DWHサーバ120によって管理される業務関連データDB(図示せず)を含み、基幹業務サーバ110は、プロセスフローDB101に記憶されたプロセスデータを、所定の抽出条件に応じてCSV
(Comma Separated Values)形式に変換して携帯端末管理サーバ10に送信する機能を有する。なお、本例においては、基幹業務サーバ110は、FTP(File Transfer Protocol)によりCSV形式にしたデータファイルを携帯端末管理サーバ10に転送する。
携帯端末管理サーバ10は、ERPが稼動するサーバであって、ユーザが使用する携帯端末からの要求に応じて通信ネットワークを介して各種データを提供するサーバである。携帯端末管理サーバ10は、例えばWWWサーバなどの情報処理装置によって構成され、帳票照会システム500のシステム管理者によって管理される。
図2は、携帯端末管理サーバ10の構成例を示すブロック図である。図2に示すように、携帯端末管理サーバ10は、プロセスフローデータの管理に関する処理を行うプロセスフローデータ管理部11と、ログインの管理に関する処理を行うログイン管理部12と、携帯端末31〜3Nにプロセスフローデータを提供する処理などを実行するプロセスフローデータ提供処理部13と、携帯端末31〜3Nからの要求に応じてプロセスフローデータを更新する処理などを実行するプロセスフローデータ更新処理部14と、顧客情報の管理に関する処理を行う顧客情報管理部15と、プロセスフローデータ一時保管DB16と、業務アプリケーションプログラムDB17と、プロセスフローDB18と、一般的な基幹業務サーバとしての機能を実現するために必要な各種データ(例えば、業務アプリケーションプログラムDB17に格納される各種プログラムが利用するデータ)を格納するその他DB19とを備えている。なお、その他DB19については、本発明に特に関係しない部分であるため、詳しい説明は省略する。
プロセスフローデータ一時保管DB16は、統合基幹業務システム100側から取得したプロセスフローデータや、プロセスフローDB18に記憶されたプロセスフローデータを一時的に保存する記憶媒体である。プロセスフローデータ一時保管DB16に記憶されるプロセスフローデータは、例えば定期的(1日毎、3日毎、12時間毎など)に更新される。
業務アプリケーションプログラムDB17は、各種業務に用いられるプログラムを記憶する記憶媒体である。業務アプリケーションプログラムDB17に記憶されるプログラムとしては、販売業務管理プログラム、購買業務管理プログラム、生産管理プログラム、財務会計管理プログラム、および管理会計管理プログラムなどがある。
プロセスフローDB18は、業務アプリケーションプログラムDB17に記憶された各種プログラムを用いた各種情報処理によって収集・整理等された各種のプロセスデータ(または帳票データ)により構成されるプロセスフローデータを記憶する記憶媒体である。本例においては、プロセスフローDB18において、複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータがプロセスフローテーブルPTに格納される場合について説明する。また、本例においては、携帯端末管理サーバ10が、プロセスフロー毎に発生するプロセスフローデータを1つのプロセスフローテーブルPTにて一元管理する場合について説明する。なお、本例においては、プロセスフローデータには、一般的に用いられている伝票データ(例えば、受注伝票に対応する伝票データについては、受注伝票ヘッダ情報、受注伝票明細情報、および納入日日程などが対応付けされ、伝票番号などのキーを元に検索可能な構造で記憶されたデータ。なお、伝票番号には、受注番号、発注番号、出荷番号、入出庫番号、請求書照会、請求番号、会計番号などが含まれる。)が含まれるものとする。
なお、携帯端末管理サーバ10が、プロセスフローデータを、例えば、後述するタイプ毎に、あるいは後述する共通データの内容の一部(例えば、受注先など)が同じもの毎に、複数のテーブルで管理する構成としてもよい。
図3は、プロセスフローDB18におけるプロセスフローデータの格納状態の例を示す説明図である。図3に示すように、本例におけるプロセスフローデータは、主キー部と、参照キー部と、タイプ部と、ステータス部と、共通データ部と、プロセス固有データ部とを含む。なお、プロセスフローデータの各部に対応する項目(すなわち、プロセスフローテーブルPTにおける各列項目)が、それぞれ、プロセスフローデータを構成するプロセスデータの種類を示す。すなわち、プロセスフローを構成する各業務プロセスに関するデータは、プロセスフローデータを構成する各部に割り当てられて格納される。なお、1つのプロセスフロー(例えば、ある企業からの受注から納品までの一連のプロセスフロー)に関するプロセスデータは、プロセスフローテーブルPTにおいて同一エントリ(すなわち、プロセステーブルPTにおける同一行)に格納される。このような構成とすることにより、各プロセスデータ間の対応関係を定義することができる。
ここで、「主キー部」とは、プロセスフローデータのうち、プロセスフローデータを一意に特定するためのデータである主キーデータが格納される部分である。本例においては、主キー部は、プロセスフロー番号とプロセスフロー明細番号とにより構成される。すなわち、本例においては、プロセスフロー番号とプロセスフロー明細番号との組み合わせが、各プロセスフローデータの識別子(ID)となる。主キー部は、プロセスフローデータの初回登録時に更新される。なお、ここでの「プロセスフローデータの初回登録時」とは、プロセスフローデータにエントリ(データ行)が追加されるとき、例えば、あるプロセスフローに属するプロセスデータであって、対応する他のプロセスデータが未登録のプロセスデータが登録されるときを意味するものとする。また、ここでの「更新」とは、データの追加を含むものとする。
なお、「プロセスフロー番号」とは、1つのプロセスフローデータ(すなわち、図3に示すプロセスフローテーブルPTにおける1列)を特定するための識別子である。プロセスフロー番号は、所定の項目が同じプロセスデータ毎に付与される。本例においては、プロセスフロー番号は、プロセスフローデータにおけるタイプと受注先とが同じプロセスフローデータに対して同一の番号が付与される。
また、「プロセスフロー明細番号」とは、同一のプロセスフロー番号が付与されたプロセスフローデータの中から特定のプロセスフローデータを特定するための識別子である。すなわち、例えば図3に示すプロセスフローテーブルPTは、プロセスフローのタイプ「在庫売上」における業務プロセス「受注」において、受注先「T001」から金額「1200」と「2600」の業務を受注したことを示すプロセスデータを含むプロセスフローデータを、それぞれプロセスフロー番号「000001」とプロセスフロー明細番号「0010」または「0020」の組み合わせにより一意に特定することができる。
次いで、「参照キー部」とは、プロセスフローデータのうち、売上返品に対する元取引など、プロセスフローに関連する他のプロセスフローデータ(または、他のプロセスデータ)を特定するためのデータである参照キーデータが格納される部分である。本例においては、参照キー部は、参照番号と参照明細番号とにより構成される。参照キー部は、プロセスフローデータの初回登録時に更新される。
なお、参照番号と参照明細番号には、それぞれ、プロセスフローに関連する他のプロセスフローのプロセスフロー番号とプロセスフロー明細番号とが格納される。ただし、新規取引の場合など、プロセスフローに関連する他のプロセスフローがない場合には、参照キー部には、同一エントリの主キー部と同じ値を示すデータが(すなわち、参照番号にはプロセスフロー番号が、参照明細番号にはプロセスフロー明細番号がそれぞれ)格納される。また、参照キー部が、プロセスフローに関連する他のプロセスデータを示す場合、参照キー部には、プロセスデータの種類を特定するためのデータがさらに設けられる。
また、「タイプ部」とは、プロセスフローデータのうち、在庫売上やサンプル出荷など、プロセスフローの種類を示すデータであるタイプデータが格納される部分である。タイプ部は、プロセスフローデータの初回登録時に更新される。なお、プロセスフローの種類は、在庫売上やサンプル出荷に限られない。また、プロセスフローの種類毎にどのプロセスが必要なのかが予め決まっているものとする(すなわち、プロセスフローの種類毎に含まれる業務プロセスの種類や数が異なる)。なお、プロセスフローの他の種類については、後で複数提示する(図17参照)。
また、「ステータス部」とは、プロセスフローデータのうち、プロセスフローの進捗を表すデータ(すなわち、プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータ)であるステータスデータが格納される部分である。本例においては、ステータスデータは、プロセスフローが必要とする業務プロセスに対し、未済のものには「0」、既済のものには「1」が設定されることにより、各業務プロセスの進捗を示す。すなわち、例えば図3に示すように、「在庫売上」のプロセスフローであって、プロセスフローに含まれる業務プロセスが「受注」、「出荷」、「出庫」、「出庫検収」、および「売上」である場合に、業務プロセス「受注」に関するプロセス固有データ(例えば、受注日)が登録されたとする。この場合、ステータスデータは、「売上」に対応する部分が「1」になり、その他の部分は初期状態(すなわち、「0」が設定された状態)のままとなる。
すなわち、本例におけるステータス部は、業務プロセス毎に更新される。言い換えれば、ステータス部は、後述するプロセス固有データの入力のとき、具体的には、所定のステータス変更条件が満たされたことにより各業務プロセスが完了した判定されたときに更新される。なお、ステータス変更条件は特に限定されないが、本例においては、「1つの業務プロセスに対応するプロセス固有データが全て入力されること」がステータス変更条件として携帯端末管理サーバ10の所定の記憶領域に記憶されているものとする。
なお、本例においては、異なる種類のプロセスフローが同一のテーブルに格納されるため、テーブルを構成する項目(列項目)のうち、特定のプロセスフローには不要なプロセスデータを格納する部分が生じる場合もある。この場合、プロセスフローテーブルにおいては、不要なプロセスデータを格納する部分が空データとなり、空データに対応するステータスデータには「0」が格納されるものとする。
また、「共通データ部」とは、プロセスフローデータのうち、受注先や出荷先など、業務プロセスによらないデータ(すなわち、同一のプロセスフローに含まれる業務プロセス間で共通するデータ)である共通データが格納される部分である。共通データ部は、プロセスフローデータの初回登録時に更新される。
また、「プロセス固有データ部」とは、プロセスフローデータのうち、受注日や各業務プロセスにおいて登録されるデータ(例えば、「納期必着」や「ワレモノ(割れ物注意)」などの注意事項を示すテキストデータ)など、同一のプロセスフローに含まれる各業務プロセスに固有のデータであるプロセス固有データが格納される部分である。プロセス固有データ部は、業務プロセス毎に更新される。よって、本例においては、プロセスフローデータのうち、業務プロセスによるものが「プロセス固有データ」であり、業務プロセスによらないものが「共通データ」であるといえる。
以上が本例におけるプロセスフローデータに関する説明となるが、ここで、図3に示す各種用語の定義について簡単に説明する。
先ず、「受注」とは、得意先から注文を受け、得意先との契約を結んだ状態を意味する。また、「出荷指示」とは、倉庫業者や物流担当者に商品を出荷する指示を行った状態を意味する。また、「出庫」とは、商品が倉庫から出荷され、移動が開始された状態を意味する。また、「検収」とは、得意先の検収が完了し、商品の所有権が得意先に移行した状態を意味する。また、「売上」とは、得意先の検収を確認し、得意先に対する債権金額が確定(=債権を計上)した状態を意味する。
また、「検収」の用語は、「納入品やサービスが、注文通りの仕様(=注文通りの数量、色や形、品質)になっているかを検査する業務」や「検収完了時、資産の所有権が移行する」という意味でも用いられる。なお、財務会計上(または、制度会計上)やERPシステム上では、資産の所有権の移行タイミングを明確にするために、「検収」というイベントが出庫と区別して定義される。
また、本例においては、プロセスフローDB18には、プロセスフローデータ(または、プロセスフローテーブルPT)の更新条件を示す更新条件データが登録される更新条件テーブルUTが備えられる。
図4は、プロセスフローDB18における更新条件テーブルUTに格納される更新条件データの格納状態の例を示す説明図である。図4に示すように、本例における更新条件データは、業務プロセスの名称と、プロセスフローのタイプと、プロセスフローデータ更新条件とを含む。
ここで、「プロセスフローデータ更新条件」とは、プロセスフローのタイプに応じたプロセスデータの登録条件を示すものである。本例においては、プロセスフローデータ更新条件は、ある業務プロセスに関するプロセスデータをプロセスフローデータに追加する場合に、その前提としてプロセスフローデータが有しているべきプロセスデータの種類(すなわち、プロセスフローにおいて完了しているべき業務プロセスの種類)を示す。すなわち、更新条件テーブルUTが図4に示したものである場合、例えば業務プロセス「出庫検収」に関するプロセスデータがタイプ「在庫売上」のプロセスフローデータに追加されるには、予め定められた業務プロセス「受注」、「出荷指示」、および「出庫」(すなわち、図4において業務プロセス名称「出庫検収」とタイプ「在庫売上」と同一列のセルに「1」が設定された業務プロセス)に関するプロセスデータがプロセスフローデータに登録されている必要がある。なお、更新条件テーブルUTは、帳票照会システム500の管理者によって作成される構成としてもよいし、携帯端末31〜3Nのユーザにより作成可能な構成とされていてもよい。
携帯端末管理サーバ10は、プロセスフローDB18およびその他DB19に格納された各種データを、所定の外部装置、本例においては携帯端末31〜3N及び統合基幹業務システム100,200,300からの要求に応じて提供する機能を有する。すなわち、携帯端末管理サーバ10は、基幹業務サーバとしての機能を有する。言い換えれば、携帯端末管理サーバ10は、ERPエンジンを備える。
なお、図示しないが、本例においては、携帯端末管理サーバ10は、データウェアハウスを実現するための各種の機能を有するDWHサーバとしての機能を有するものとする。携帯端末管理サーバ10が、ERPエンジンと、DWHサーバとして機能するための構成とを備えることにより、構成の異なる統合基幹業務システム(例えば、基幹業務サーバとDWHサーバのうち、両方を有する統合基幹業務システム100と、DWHサーバのみを有する統合基幹業務システム200と、DWHサーバのみを有する統合基幹業務システム300。)に対しても、統合基幹業務システムとして要求される情報の提供を行うことができるようになる。
各携帯端末31〜3Nは、CPU(中央処理装置)、ROM、RAM、および表示部などを備えた例えばIpad(登録商標)などの情報処理装置である。本例においては、各携帯端末31〜3Nは、Webブラウザなど、帳票データを扱うために利用可能な各種アプリケーションを有しているものとする。また、本例においては、各携帯端末31〜3Nは、例えばユーザによる操作入力に応じて、携帯端末管理サーバ10から必要な帳票データ(本例においては、プロセスフローデータ)を取得するためのクエリ(検索項目、検索キー、抽出キーなど)を定義し、携帯端末管理サーバ10に送信する機能を有する。
本例においては、各携帯端末31〜3Nは、中継機20及び通信ネットワーク40を介して携帯端末管理サーバ10と通信し、携帯端末管理サーバ10から取得したデータを例えば所定のWebアプリケーション(Webブラウザ)などのソフトウェアの機能により表示部に出力する機能を有する。
ここで、プロセスフローデータ一時保管DB16に記憶されるプロセスフローデータを更新する処理について説明する。本例において、携帯端末管理サーバ10は、データ更新のタイミング(例えば、1日毎に更新する場合は、予め定められた所定の時間(深夜2時など)。)になると、携帯端末管理サーバ10が備えるプロセスフローDB18に格納されているプロセスフローデータ(最新のデータとなる)を読み出して、プロセスフローデータをプロセスフローデータ一時保管DB16の所定の格納領域に格納(新規保存、あるいは上書保存)し、プロセスフローデータ一時保管DB16の記憶情報を更新する。このようにして、バッチ処理によりプロセスフローデータ一時保管DB16の記憶情報が更新される。なお、プロセスフローDB18に記憶されるプロセスフローデータの更新については、後で詳しく説明する。
次に、本例の帳票照会システム500の動作について図面を参照して説明する。なお、本発明に特に関係しない動作や処理については、その内容を省略している場合がある。
図5は、本例の帳票照会システム500における携帯端末管理サーバ10などが実行するプロセスフローデータ提供処理の例を示すフローチャートである。ここでは、携帯端末管理サーバ10が、ユーザXが使用する携帯端末31からの要求に応じてプロセスフローデータを提供する場合を例に説明する。
プロセスフローデータ提供処理において、先ず、携帯端末31は、ユーザXのログイン操作によるログイン要求を受け付ける(ステップS101)。このログイン操作は、例えば予め設定された暗証番号の入力操作などが考えられる。携帯端末31へのログインが許可されると、携帯端末31に搭載されている各種の機能を利用するための各種の操作を行うことが許容される。
ユーザXが携帯端末31にログインしている状態であるときに、ユーザXによって所定のログイン操作が実行されると、携帯端末31は、携帯端末管理サーバ10に対してアクセスし、ログイン要求を行う(ステップS102)。このログイン要求は、例えば、予め定められたログイン判定に用いられる所定の情報(例えばユーザXに対して発行された電子証明書)が提示されて行われる。
携帯端末管理サーバ10のログイン管理部12は、ログイン要求を受けると、ログインを許可するか否かを判定する(ステップS103)。この判定は、例えば、ID、パスワード、電子証明書などによって行うようにすればよい。
ログイン管理部12は、ログインを許可すると判定した場合には(ステップS103のY)、携帯端末31をログイン状態に設定する。ログイン状態に設定されると、携帯端末管理サーバ10のプロセスフローデータ提供処理部13は、データ検索画面を示すデータ検索画面情報を携帯端末31に送信する(ステップS104)。なお、ログインを許可しないと判定した場合には(ステップS103のN)、ログイン管理部12は、携帯端末31をログイン状態に設定することなくプロセスフローデータ提供処理を終了する。なお、ログインを許可しないと判定した場合には、ログイン管理部12が、その旨を携帯端末31に対して通知する処理を行う。
データ検索画面情報を受信すると、携帯端末31は、受信したデータ検索画面情報が示すデータ検索画面を自己が備える表示部に表示する(ステップS105)。
図6は、データ検索画面の例を示す説明図である。図6に示すように、データ検索画面には、検索対象とする項目(検索項目)を入力する検索項目入力領域601と、検索の際に用いるキーワード(検索ワード)を入力する検索ワード入力領域602と、前画面に戻る際に押下される戻るボタンB1と、検索を実行する際に押下される検索ボタンB2とが設けられている。
データ検索画面において、ユーザXは、携帯端末31が備える操作部(例えばタッチパネルが配置された表示部に表示されたキーボード)を操作して、検索項目と検索ワードとを入力し、検索ボタンB2を押下する。検索項目には、プロセスフローデータを構成し得る項目(例えば、受注伝票、在庫、取引先、商品名。)が入力される。検索ワードには、プロセスフローデータに関連する文字列(例えば、取引先の名称や商品の名称。)が入力される。
検索項目及び検索ワードが入力された状態で検索ボタンB2が押下されると、携帯端末31は、携帯端末管理サーバ10に対して、入力された検索項目及び検索ワードを検索条件として提示して、プロセスフローデータの提供要求を行う(ステップS106)。なお、上記の検索条件は一例であり、任意のプロセスフローデータ(または、プロセスフローデータを構成するプロセスデータ)を検索可能な条件であれば他のどのような条件であってもよい。
携帯端末管理サーバ10は、プロセスフローデータの提供要求を受け付けると、プロセスフローデータ一時保管DB16を参照して、受け付けた提供要求によって提示された検索条件に従ってプロセスフローデータを検索する(ステップS107)。
検索条件に従ってプロセスフローデータを検索すると、携帯端末管理サーバ10は、検索したプロセスフローデータを検索結果として表示する検索結果画面を示す検索結果画面情報を携帯端末31に送信する(ステップS108)。
検索結果画面情報を受信すると、携帯端末31は、受信した検索結果画面情報が示す検索結果画面を自己が備える表示部に表示する(ステップS109)。
図7は、検索結果画面の例を示す説明図である。図7に示すように、検索結果画面には、検索結果を表示する表示領域701と、前画面に戻る際に押下される戻るボタンB1と、検索結果の編集を行う際に押下される編集ボタンB3とが設けられている。
その後、ユーザXによるブラウザを終了する操作などのアクセスを終了するための操作がなされた場合には(ステップS110のY)、携帯端末31は、携帯端末管理サーバ10に対してログアウト要求を行う(ステップS111)。なお、戻るボタンB1の押下などアクセスを継続するための操作がなされた場合には(ステップS110のN)、携帯端末31は、ステップS105の処理に移行してデータ検索画面(図6参照)を表示する。
ステップS108にて検索結果画面情報を送信すると、ログイン管理部12は、携帯端末31との情報のやりとりが行われていない時間(待機時間)の計測を開始し、この待機時間が所定時間(例えば5分、10分、30分など)を経過(所定時間に到達)したか否かを監視する(ステップS112)。
待機時間の計測中にログアウト要求を受けると(ステップS113のY)、ログイン管理部12は、待機時間の計測を中止し、携帯端末31に対して今回の通信による履歴情報(通信履歴情報、操作履歴情報など)の消去要求を行い(ステップS114)、ログイン状態を解除するログアウト処理を行う(ステップS115)。
また、待機時間が所定時間を経過したと判定した場合には(ステップS112のY)、ログイン管理部12は、待機時間の計測を終了し、携帯端末31に対して今回の通信による履歴情報(通信履歴情報、操作履歴情報など)の消去要求を行い(ステップS114)、ログイン状態を解除するログアウト処理を行う(ステップS115)。
一方、携帯端末31は、履歴情報の消去要求を受けると、携帯端末管理サーバ10との今回の通信によって蓄積された履歴情報を消去する処理を行う(ステップS116)。
上記のようにして、ログイン処理によって操作可能となった携帯端末31からのログイン要求に応じて携帯端末管理サーバ10に対するログインを許可するか否か判定し、許可した場合にプロセスフローデータの提供要求を受け付けて、要求に応じたプロセスフローデータを提供する処理が実行される。
上記のようにしてプロセスフローデータの提供処理を行うことによって、ステップS101及びステップS103にて2重に認証を行うことができるため、携帯端末31に対してプロセスフローデータを提供する際の安全性を向上させることが可能となる。また、プロセスフローデータ提供処理において、プロセスフローを検索する対象をプロセスフローデータ一時保管DB16とすることで、携帯端末31が携帯端末管理サーバ10において基幹業務サーバとして機能する部分(具体的には、業務アプリケーションプログラムDB17とプロセスフローDB18)にアクセスする必要が無いようにすることができるため、携帯端末31に対してプロセスフローデータを提供する際の安全性を向上させることが可能となる。
図8は、携帯端末管理サーバ10と携帯端末31が実行するプロセスフローデータ更新処理の例を示すフローチャートである。ここでは、ユーザXが使用する携帯端末31からの要求に応じてプロセスフローデータを更新する場合を例に説明する。
プロセスフローデータ更新処理におけるステップS201〜S209は上述したプロセスフローデータ提供処理におけるステップS101〜S109(図5参照)と同様の処理であり、業務データ更新処理におけるステップS219〜S225は上述したプロセスフローデータ提供処理におけるステップS110〜S116(図5参照)と同様の処理であるため、業務データ更新処理におけるステップS201〜S209,S219〜S225についての詳細な説明は省略する。
プロセスフローデータ更新処理におけるステップS209にて検索結果画面情報が示す検索結果画面(図7参照)を自己が備える表示部に表示したあと、携帯端末31は、編集ボタンB3の押下を受け付けると、表示領域701に表示されている検索結果を編集可能な編集画面を表示する。図9は、編集画面の例を示す説明図である。図9に示すように、編集画面には、検索結果を編集可能に表示する編集領域901と、前画面に戻る際に押下される戻るボタンB1と、編集結果を携帯端末管理サーバ10側で保存されているプロセスフローデータに反映させる際に押下される更新ボタンB4とが設けられている。
ユーザXは、編集画面において、携帯端末31を操作して、編集領域604に表示されているプロセスフローデータを追加(例えば、伝票の新規登録)、消去、変更などすることにより、検索結果として表示されているプロセスフローデータを編集する作業を行う。そして、編集作業を終えたあと、編集結果を携帯端末管理サーバ10側で保存されているプロセスフローデータに反映させる場合には、ユーザXは、携帯端末31を操作して、更新ボタンB4を押下する。
更新ボタンB4の押下を受け付けた場合には、携帯端末31は、携帯端末管理サーバ10に対して編集結果の反映を要求するための情報書換要求を行う(ステップS210)。この要求においては、編集内容や、携帯端末管理サーバ10に関する携帯端末管理サーバ情報(例えば、携帯端末管理サーバ10に対して発行された電子証明書)、ユーザXに関するユーザ情報(例えば、ユーザXに対して発行された電子証明書など)などが提示される。
情報書換要求を受け付けると、携帯端末管理サーバ10は、プロセスフローDB18にアクセスし、ログイン前の所定の処理(ログイン前処理)を行う(ステップS211)。本例においては、ログイン前処理として、携帯端末管理サーバ10は、ログイン判定に用いられる所定の情報(ログイン判定情報。例えば、携帯端末管理サーバ10に対して発行された電子証明書、ユーザXに対して発行された電子証明書など。)を確認するための処理を行う。
ログイン前処理によりログイン判定情報を確認すると、携帯端末管理サーバ10は、ログインを許可するか否かを判定する(ステップS212)。この判定は、例えば、ID、パスワード、電子証明書などによって行うようにすればよい。
携帯端末管理サーバ10は、ログインを許可すると判定した場合には、携帯端末31からの情報の受け入れに関して携帯端末31をログイン状態(ここでは、プロセスフローDB18へのアクセスが許容された状態)に設定する(ステップS213)。
携帯端末31をログイン状態に設定すると(すなわち、ログインを許可すると)、携帯端末管理サーバ10は、ログイン状態に設定された携帯端末31からの情報書換要求に従って、プロセスデータDB18に保存されている該当するプロセスフローデータを書き換える処理を実行する(ステップS214)。そして、携帯端末管理サーバ10は、統合基幹業務システム100,200,300に対して編集内容に従って書き換えたことを通知するための書換通知を送信する(ステップS215)。その後、各統合基幹業務システム100,200,300は、受信した書換通知に応じて自己が備えるプロセスフローDB101,201,301を更新する。なお、各プロセスフローDB18,101,201,301には、携帯端末31による情報書換要求に応じて書き換えられた内容が記憶される構成としてもよい。すなわち、誰がいつプロセスフローデータを書き換えたかが記録される構成としてもよい。
プロセスフローDB18に記憶されている情報を書き換えると、携帯端末管理サーバ10は、同様に、プロセスフローデータ一時保管DB16に保存されている該当するプロセスフローデータを書き換える処理を実行する(ステップS216)。そして、携帯端末管理サーバ10は、携帯端末31に対して編集内容に従って書き換えたことを通知するための書換通知を送信する(ステップS217)。
書換通知を受信すると、携帯端末31は、自己が編集画面の所定領域に、編集結果が反映された旨をユーザXに報知するための書換反映通知を表示する(ステップS218)。
その後、上述したプロセスフローデータ提供処理(図5参照)と同様にして、ステップS219以降の処理が実行される。
上記のようにして、ログイン処理によって操作可能となった携帯端末31からのログイン要求に応じて携帯端末管理サーバ10に対するログインを許可するか否か判定し(ステップS203)、許可した場合にプロセスフローデータの書換要求を受け付けて(ステップS210)、書換要求を受け付けた場合にプロセスフローDB18に対してログイン前処理を行い(ステップS211)、許可された場合にプロセスフローDB18のプロセスフローデータを書き換える処理が行われる(ステップS214)。そして、プロセスフローデータ一時保管DB16に対しても、プロセスフローデータを書き換える処理が実行される。
上記のようにしてプロセスフローデータの書換処理を行うことによって、ステップS201、ステップS203及びステップS212にて3重に認証を行うことができるため、携帯端末31からの要求に応じてプロセスフローデータを更新する際の安全性を向上させることが可能となる。なお、情報(データ)の書き換えを行う場合には、情報の提供を行う場合と異なるログイン判定を行う構成とすることにより、携帯端末31が各種DBにアクセスすることを制限することができるため、携帯端末31からの要求に応じてプロセスフローデータを更新する際の安全性を向上させることが可能となる。
上記の例では、携帯端末管理サーバ10が携帯端末31からの書換要求を受け付ける毎にプロセスフローDB18に対してログイン判定を行い、ログイン許可をした場合にデータを書き換える処理が行われる構成としていたが、携帯端末管理サーバ10が、携帯端末31〜3Nからの書換要求を受け付けた場合に、その編集内容及び書換要求元となる携帯端末31〜3Nに関する情報(認証に必要な情報)を蓄積しておき、所定のタイミング(例えば、毎日23時など)でバッチ処理によりプロセスフローDB18に対して書換処理を行う構成としてもよい。この場合、所定のタイミングで、書換要求元となる各携帯端末31〜3Nに関する情報を提示してログイン判定を行い、ログインが許可された端末装置を書換要求元とする編集内容のみをプロセスフローDB18にてプロセスフローデータに反映するようにすればよい。
すなわち、携帯端末管理サーバ10が、ログイン状態の携帯端末からのプロセスフローデータの更新要求(情報書換要求)を受け付け、受け付けた更新要求の更新内容(編集内容)と、その更新要求を行った携帯端末を示す端末情報(例えば電子証明書)とを含む更新関連情報を蓄積(例えば携帯端末管理サーバ10が備える記憶媒体に蓄積する。)し、所定のタイミング(例えば、毎日23時など)となったときに、蓄積されている更新関連情報を用いて一括してプロセスフローデータを更新し、ログイン状態であった各携帯端末から受け付けた更新要求に応じた更新処理(情報書換)を一括して行う構成としてもよい。このように構成すれば、プロセスフローDB18へのアクセス回数を大幅に減らすことが可能となり、安全性をより向上させることができるようになる。
図10は、携帯端末管理サーバ10が実行するデータベース更新処理の例を示すフローチャートである。データベース更新処理では、携帯端末管理サーバ10にてプロセスフローDB18に記憶されたプロセスフローデータを更新するための処理が実行される。なお、本例においては、携帯端末管理サーバ10は、業務アプリケーションプログラムDB17に記憶された各種プログラムを用いた各種情報処理によって収集・整理等された各種のプロセスデータやプロセスフローデータを所定の時機に取得するものとし、以下で説明するデータベース更新処理は、携帯端末31〜3Nからの更新要求に応じて更新する場合(例えば、上述したプロセスフローデータ更新処理。図8参照。)とは異なる。
データベース更新処理において、先ず、携帯端末管理サーバ10は、新たなプロセスフローデータ(新規プロセスフローデータ)を取得したか否かを判定する(ステップS301)。ここで、新規プロセスフローデータを取得していないと判定すると(ステップS301のN)、携帯端末管理サーバ10は、後述するステップS303の処理に移行する。
一方、新規プロセスフローデータを取得したと判定すると(ステップS301のY)、携帯端末管理サーバ10は、取得したプロセスフローデータをプロセスフローテーブルPTに登録する(ステップS302)。
次いで、携帯端末管理サーバ10は、登録済みのプロセスフローデータに対応するプロセスデータ(すなわち、プロセスフローを構成する業務プロセスに関するデータ)を取得したか否かを判定する(ステップS303)。
なお、携帯端末管理サーバ10による取得したプロセスデータが登録済みのプロセスデータである否かの判定は、取得したデータが有するプロセスフロー番号とプロセスフロー明細番号との組み合わせを有するプロセスフローデータがプロセスフローテーブルPTに格納されているか否かを判定することにより行う。そのため、本例においては、携帯端末管理サーバ10が取得するデータ(業務の実行者により入力されたデータ、または業務アプリケーションプログラムにより作成されたデータ)に、主キー部を構成するデータ(すなわち、プロセスフロー番号とプロセスフロー明細番号)が含まれることが必要となる。
ここで、登録済みのプロセスフローデータに対応するプロセスデータを取得していないと判定すると(ステップS303のN)、携帯端末管理サーバ10は、その他DB19を参照し、取得したデータに対応する記憶領域を特定して、取得したデータを登録し(ステップS304)、ステップS301の処理に移行する。
一方、登録済みのプロセスフローデータに対応するプロセスデータを取得したと判定すると(ステップS303のY)、携帯端末管理サーバ10は、取得したプロセスデータに対応する更新条件テーブルUTを参照して、取得したプロセスデータに応じた更新条件データを特定する(ステップS305)。本例においては、携帯端末管理サーバ10は、プロセスデータが示す業務プロセスの種類とプロセスフローの識別情報(すなわち、プロセスフロー番号とプロセスフロー明細番号)に基づいて更新条件データを特定する。
更新条件データを特定すると、携帯端末管理サーバ10は、プロセスフローデータが、特定した更新条件データが示す更新条件を満たしているか否か判定する(ステップS306)。すなわち、携帯端末管理サーバ10は、プロセスフローデータと更新条件データとに基づいて、取得したプロセスデータをプロセスフローデータの一部としてプロセスフローテーブルPTに登録するか否か判定する。本例においては、携帯端末管理サーバ10は、取得したプロセスデータに対応するプロセスフローデータのステータス部と更新条件データとを比較し、更新条件データにて「1」が設定された業務プロセスがステータス部においても全て「1」に設定されている場合に、プロセスフローデータが更新条件を満たしていると判定する。
ここで、プロセスフローデータが、特定した更新条件データが示す更新条件を満たしていないと判定すると(ステップS306のN)、携帯端末管理サーバ10は、所定のエラー処理を実行し(ステップS307)、ステップS301の処理に移行する。なお、「エラー処理」とは、プロセスフローデータを更新しない処理であれば特に限定されず、例えば、更新条件が満たされるまでプロセスデータを所定の記憶領域に一時的に保存する処理であってもよいし、更新条件を満たしていないプロセスデータを取得することとなった原因を調べるための処理(すなわち、エラーを管理者に報知する処理や、充足されていない更新条件の内容を管理者に報知する処理など。)であってもよい。
一方、プロセスフローデータが、特定した更新条件データが示す更新条件を満たしていると判定すると(ステップS306のY)、携帯端末管理サーバ10は、プロセスフローテーブルPTに登録されたプロセスフローデータを更新する(ステップS308)。すなわち、携帯端末管理サーバ10は、取得したプロセスデータをプロセスフローテーブルPTに登録する。
プロセスフローデータを更新すると、携帯端末管理サーバ10は、プロセスフローデータの更新によりプロセスフローデータに関する所定のステータス変更条件が満たされたか否かを判定する(ステップS309)。ここで、プロセスフローデータが更新されたことに応じて所定のステータス変更条件が満たされていないと判定すると(ステップS309のN)、携帯端末管理サーバ10は、ステップS301に移行する。
一方、プロセスフローデータが更新されたことに応じて所定のステータス変更条件が満たされたと判定すると(ステップS309のY)、携帯端末管理サーバ10は、満たされたステータス変更条件に基づいて、プロセスフローデータが含むステータスデータを更新し(ステップS310)、ステップS301の処理に移行する。
本例におけるデータベース更新処理は、例えば、携帯端末管理サーバ10の管理者による終了操作により終了する。
なお、データベース更新処理は、リアルタイムに実行される処理であってもよいし、特定の単位時間毎に実行されるバッチ処理であってもよい。また、例えば指定された期間だけリアルタイム処理を行うような、一部にリアルタイム性を有した処理(準リアルタイム処理)であってもよい。
図11は、携帯端末管理サーバ10と携帯端末31とが実行する帳票出力処理の例を示すフローチャートである。帳票出力処理では、携帯端末管理サーバ10が携帯端末31に対してプロセスフローデータ(プロセスフローデータの一部または全部)を提供することにより、携帯端末31が備える表示画面に帳票を表示するための処理が実行される。なお、ログイン管理については上述したプロセスフローデータ提供処理(図5参照)と同様の処理を行うため、ここでの説明は省略する。なお、帳票出力処理は、所定形式の帳票を出力する点でプロセスフローデータ提供処理とは異なる。
また、本例においては、携帯端末31からの要求に応じて、携帯端末管理サーバ10がプロセスフローデータを更新する場合についての説明も行う。なお、本例においては、ここで説明するプロセスフローDB18更新処理(すなわち、帳票出力処理におけるプロセスフローDB18の更新処理)は、データベース更新処理(図10参照)の1例である。
帳票出力処理において、先ず、携帯端末31は、例えば携帯端末31のユーザXによる操作入力に応じて、プロセスフローデータ更新要求入力画面要求を携帯端末管理サーバ10に送信する(ステップS501)。
プロセスフローデータ更新要求入力画面要求を受信すると、携帯端末管理サーバ10は、受信したプロセスフローデータ更新要求入力画面要求に応じたプロセスフローデータ更新要求入力画面を送信する(ステップS401)。
プロセスフローデータ更新要求入力画面を受信すると、携帯端末31は、自己が備える表示部の表示画面にプロセスフローデータ更新要求入力画面を表示する(ステップS502)。
図12は、プロセスフローデータ更新要求入力画面の例を示す説明図である。図12に示すように、プロセスフローデータ更新要求入力画面には、更新対象の識別情報(本例においては、プロセスフローデータの主キー部に対応するデータ。すなわち、プロセスフロー番号とプロセスフロー明細番号。)の入力を受け付ける主キーデータ入力領域1201と、ユーザXによるプロセスデータが示す業務プロセスの種類の入力を受け付ける業務プロセス入力領域1202と、その他のプロセスデータの内容の入力を受け付ける詳細データ入力領域1203と、表示部に出力される表示画面を他の表示画面に切替える要求を受け付ける戻るボタン1204と、各入力領域(本例においては、主キーデータ入力領域1201、業務プロセス入力領域1202、詳細データ入力領域1203。)に入力された内容に基づくプロセスフローデータの更新要求を受け付ける更新ボタン1205とが設けられる。
プロセスフローデータ更新要求入力画面において、ユーザXは、携帯端末31が備える操作部(例えば、タッチパネルが配置された表示部に表示された表示領域やボタン)を操作する。すなわち、携帯端末31は、例えばユーザXの指により各入力領域が押下されると、押下された入力領域に対するテキストデータ(数字と文字とを含む。)の入力の受付を開始する。そして、携帯端末31は、例えばタッチパネルが配置された表示部にキーボードを表示して(図示せず)、ユーザXによるテキストデータの入力を受け付け、受け付けたテキストデータを選択された領域に表示する。また、携帯端末31は、業務プロセス入力領域1202の選択を受け付けると、プルダウン形式で、所定の業務プロセス名称を選択可能に表示する。なお、プロセスデータの入力を受け付ける方法はこれに限定されず、例えば、携帯端末31が、所定のデータ形式にまとめられた複数のプロセスデータを一度に受け付ける構成としてもよい。
携帯端末31は、ユーザXによる更新ボタン1205の選択を受け付けると、各入力領域に入力されたデータにより構成されるプロセスデータによるプロセスフローデータの更新要求を受け付けたものと判定する(ステップS503)。
プロセスフローデータの更新要求(更新要求)を受け付けたものと判定すると、携帯端末31は、受け付けた更新要求を携帯端末管理サーバ10に送信する(ステップS504)。
更新要求を受信すると、携帯端末管理サーバ10は、プロセスフローテーブルPTに登録されたプロセスフローデータのうち、受信した更新要求に応じたプロセスフローデータを取得する(ステップS402)。なお、このとき携帯端末管理サーバ10は、更新要求が示す主キーデータ(すなわち、主キーデータ入力領域1201に入力されたデータ)を含むプロセスフローデータを、更新要求(すなわち、受信したプロセスデータ)に応じたプロセスフローデータとして取得する。また、ここでの「取得」とは、後述する処理においてプロセスフローデータと更新条件データとを比較等するために一時的に所定の記憶領域に記憶するという意味である。
更新要求に応じたプロセスフローデータを取得すると、携帯端末管理サーバ10は、更新要求に応じた更新条件データを取得する(ステップS403)。ここで、更新要求に応じた更新条件データとは、更新要求が示す業務プロセスとプロセスフローデータのタイプ(すなわち、業務プロセス入力領域1202に入力された業務プロセスと、ステップS402の処理にて取得したプロセスフローデータが示すタイプ)とにより特定可能な更新条件データを意味する(図4参照)。
更新条件データを取得すると、携帯端末管理サーバ10は、取得したプロセスフローデータと更新条件データとを比較し(ステップS404)、プロセスフローデータの更新条件が満たされているか否か判定する(ステップS405)。
ここで、更新条件データにおいて「1」が設定された項目の何れか1つ以上がプロセスフローデータのステータス部において「1」に設定されていないことにより、プロセスフローデータの更新条件が満たされていないと判定すると(ステップS405のN)、携帯端末管理サーバ10は、更新エラー通知を作成して携帯端末31に送信し(ステップS406)、ここでの処理を終了する。
更新エラー通知を受信すると(ステップS505のY)、携帯端末31は、受信した更新エラー通知に基づいて、自己が備える表示部の表示画面に更新エラー通知表示画面を表示する(ステップS506)。
図13は、更新エラー通知表示画面の例を示す説明図である。図13に示すように、更新エラー通知表示画面には、プロセスフローデータ更新要求入力画面に重畳して表示される更新エラー通知表示領域1301が設けられる。ここで、本例における更新エラー通知表示領域1301には、更新エラーをユーザXに報知するための定型文の他、更新条件の詳細を表示する旨の要求を受け付けるための詳細表示ボタン1302と、更新エラー通知表示領域1301を表示画面から消去する旨の要求を受け付ける閉じるボタン1303とが設けられる。
携帯端末31は、ユーザXによる詳細表示ボタン1302の選択を受け付けたことに応じて、例えば、携帯端末管理サーバ10におけるプロセスフローデータと更新条件データとの比較結果をユーザXが認識可能な形態(例えば、プロセスフローデータのステータス部と更新条件データのプロセスフローデータ更新条件とを示す対照表。)で表示する。
一方、更新条件データにおいて「1」が設定された項目の全てが、プロセスフローデータのステータス部において「1」に設定されていることによりプロセスフローデータの更新条件が満たされていると判定すると(ステップS405のY)、携帯端末管理サーバ10は、更新要求が示すプロセスデータをプロセスフローデータに追加してプロセスフローデータを更新する(ステップS407)。
プロセスフローデータを更新すると、携帯端末管理サーバ10は、更新したプロセスフローデータを携帯端末31に送信して(ステップS408)、ここでの処理を終了する。
一方、プロセスフローデータを受信すると、携帯端末31は、受信したプロセスフローデータに基づいて、自己が備える表示部の表示画面に帳票表示画面を表示する(ステップS507)。
図14は、帳票表示画面の例を示す説明図である。図14に示すように、帳票表示画面には、プロセスフローデータに基づいた帳票を表示する帳票表示領域1401と、帳票ステータス表示領域1402と、戻るボタン1403と、変更ボタン1404とが設けられる。なお、携帯端末31は、例えば携帯端末31に備えられたキーボードなどの操作に応じて帳票表示領域1401に表示される帳票の縮尺を変更する。
ここで、帳票表示領域1401には、所定の表示形態でプロセスフローデータの一部または全部が表示される。なお、本例においては、所定の表示形態でプロセスフローデータの一部または全部を表示するための情報が、携帯端末管理サーバ10により作成されて、例えば帳票出力処理におけるステップS408のタイミングで、携帯端末31に送信されるものとする。なお、携帯端末31が、自己が備える記憶装置に記憶された情報に基づいて、受信したプロセスフローデータの一部または全部を所定の表示形態で帳票表示領域1401に表示する構成としてもよい。
また、帳票ステータス表示領域1402は、帳票表示領域1401に表示される帳票の種類(または、状況。以下、ステータスという。)を表示する領域である。なお、帳票のステータスとしては、例えば、受注伝票、出庫伝票、検収伝票、および請求書など、種々のものが考えられる。
また、戻るボタン1403は、表示画面をプロセスフローデータ更新要求入力画面に戻す旨の要求を受け付けるためのボタンである。なお、携帯端末31が、ユーザXによる戻るボタン1403の選択を受け付けたことに応じて、表示画面をプロセスフローデータ更新要求入力画面に戻すだけでなく、携帯端末管理サーバ10に対して、更新要求に基づくプロセスフローデータの更新を取り消す旨の要求を送信する構成としてもよい。この場合、携帯端末31は、戻すボタン33の選択に応じて、各入力領域(本例においては、主キーデータ入力領域1201、業務プロセス入力領域1202、詳細データ入力領域1203。)に入力されていたテキストデータ(業務プロセス入力領域1202においては、選択されていた業務プロセス)を示す状態でプロセスフローデータ更新要求入力画面を表示する構成とされていてもよい。このような構成とすることにより、ユーザXによる入力内容の確認を容易にすることができるようになる。
また、変更ボタン1404は、帳票表示領域1401の表示内容を変更する旨の要求を受け付けるためのボタンである。以下、帳票表示領域1401の表示内容の変更処理に関して説明する。
帳票表示画面を表示すると、携帯端末31は、ユーザXによる帳票ステータス変更要求を受け付けたか否かを判定する(ステップS508)。
本例においては、携帯端末31は、先ず、ユーザXによる帳票ステータス表示領域1402の選択を受け付ける。そして、ユーザXによる帳票ステータス表示領域1402の選択を受け付けると、携帯端末31は、表示可能な帳票の形態を示す帳票ステータス名称のリストを、例えばプルダウン形式で選択可能に表示する。
なお、ここで表示する帳票ステータス名称については、携帯端末管理サーバ10からプロセスフローデータと共に受信しているものとする。具体的には、携帯端末管理サーバ10は、予め所定の記憶領域に記憶された帳票の形態に関するデータ(帳票形態データ)とプロセスフローデータの状態(すなわち、プロセスフローテーブルPTの各列項目の入力状態)とに基づいて、表示可能な帳票の形態を示す帳票ステータス名称を特定する。すなわち、例えば携帯端末31に送信するプロセスフローデータのタイプが「在庫売上」であり、プロセス固有データ部に業務プロセス「受注」に関するプロセスデータしか登録されていない場合には、携帯端末管理サーバ10は、帳票ステータス名称として「受注伝票」のみを特定する。また、業務プロセス「受注」に関するプロセスデータの他、業務プロセス「出庫」に関するプロセスデータが登録されている場合、携帯端末管理サーバ10は、帳票ステータス名称として、「受注伝票」と「出庫伝票」とを特定する。
図15は、プロセスフローデータの状態に基づく帳票ステータスの遷移について説明するための説明図である。図15において、画像1501〜1504が、それぞれプロセスフローデータに基づいて帳票表示領域1401に表示され得る帳票(具体的には、伝票)の形態であるとする。なお、画像1501〜1504は、帳票ステータスの遷移について説明するための説明図であり、各種帳票としての役割を果たすための具体的記載例を示すものではない。
ここで、画像1504を例にして説明すると、画像1504における領域1511が帳票ステータス名称を、領域1512がプロセスフローのタイプを、領域1513がプロセスフローデータに含まれるプロセスデータの業務プロセスの名称をそれぞれ示す領域(本例においては、文字列表示領域)であるものとする。なお、本例においては、プロセスフローデータに含まれるプロセスデータの種類に対応した帳票ステータス名称を領域1511に表示している。
この場合、図15における画像1501から画像1504への遷移が示すように、1つのプロセスフローデータに対して各業務プロセスに応じたプロセスデータが登録されていく度に、帳票ステータス名称(すなわち、プロセスフローデータに基づいて表示可能な帳票の形態)の種類が増えていくことになる。これは、「次の種類の帳票があるかないか」ではなく、「プロセスフローデータの状態に応じて帳票のステータスが上がっていく(すなわち、表示可能な帳票の種類が増えていく)」ことを意味する。
以下、帳票出力処理におけるステップS507の処理の前に、携帯端末31が、業務プロセス「受注」,「出荷指示」,「出庫」,「出庫検収」を含むプロセスフローデータを受信した場合を例にして説明を続ける。なお、本例においては、ステップS507の処理にて、携帯端末31が、受信したプロセスフローデータが示すプロセスフローにおいて業務プロセス「受注」,「出荷指示」,「出庫」,「出庫検収」のうち最も上位に位置する業務プロセス「受注」に対応する帳票ステータス名称「受注伝票」に対応する帳票を、帳票表示領域1401に表示していたものとする(図14参照)。なお、携帯端末31は、ステップS407の処理にて新たにプロセスフローデータに追加されたプロセスデータに応じた業務プロセスに対応する帳票を帳票表示領域1401に表示する構成とされていてもよい。
帳票ステータス変更要求の受付判定処理(ステップS508)において、ユーザXによる帳票ステータス変更要求を受け付けていないと判定すると(ステップS508のN)、携帯端末31は、後述するステップS510の処理に移行する。
一方、ユーザXによる帳票ステータス変更要求を受け付けたと判定すると(ステップS508のY)、携帯端末31は、帳票表示領域1401に、受け付けた変更要求に応じた帳票を表示する(ステップS509)。本例においては、携帯端末31が、ユーザXによる業務プロセス「出庫」に対応する帳票ステータス名称「出庫伝票」の選択を受け付けて、業務プロセス「出庫」に対応する帳票(出庫伝票)を帳票表示領域1401に表示するものとする。なお、この場合、携帯端末31は、帳票ステータス表示領域1402に、帳票ステータス名称「出庫伝票」を表示する。
帳票ステータス変更要求に応じた帳票を表示すると、携帯端末31は、帳票出力処理を終了するか否かを判定する(ステップS510)。ここで、帳票出力処理を終了しないと判定すると(ステップS510のN)、携帯端末31は、ステップS508の処理に移行する。
一方、例えばユーザXによる所定の終了操作を受け付けたことにより帳票出力処理を終了するものと判定すると(ステップS510のY)、携帯端末31は、ここでの処理を終了する。
以上に説明したように、上述した実施の形態では、ERPが稼動するサーバであって、ユーザが使用する携帯端末31〜3Nからの要求に応じて通信ネットワーク40を介して各種データを提供する携帯端末管理サーバ10が、複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータを記憶するプロセスフローDB18を備え、プロセスフローの進捗状況に応じてプロセスフローDBに記憶されているプロセスフローデータを更新し、携帯端末31〜3N(以下、携帯端末31。)からのログイン要求があったときに、携帯端末31に対してログインを許可するか否か判定し(例えば、ステップS203。図8参照。)、ログインを許可すると判定した場合にログイン処理を行い、ログイン処理が実行されたログイン状態の携帯端末31からのプロセスフローデータの閲覧要求を受け付け(例えば、提供要求を受け付けるステップS106。図5参照。)、受け付けた閲覧要求に応じて、プロセスフローDB18に記憶されているプロセスフローデータを携帯端末31に対して提供し(例えば、ステップS108。図5参照。)、プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、ステータスデータが、プロセスフローに含まれる複数の業務プロセス(例えば、受注、出荷指示、出庫、出庫検収、売上。)それぞれの進捗状況を示すデータであり、共通データが、同一のプロセスフローに含まれる業務プロセス間で共通するデータ(例えば、受注先や金額などを示すデータ)であり、プロセス固有データが、同一のプロセスフローに含まれる各業務プロセスに固有のデータ(例えば、受注日や受注テキスト。)であり、ステータスデータが、プロセス固有データが更新されたことに応じて更新される(例えば、プロセス固有データが追加されたことに応じて、対応するステータスデータが「0」から「1」に変更される。)構成としているので、携帯通信端末に帳票に関する情報を提供する業務システム(例えば、帳票照会システム。)において、より安全性を向上させるとともに、(業務システムにおける)ERPシステム(例えば、携帯端末管理サーバ10における基幹業務サーバとして機能する部分)におけるデータの更新や検索に要する処理負荷を軽減させることができるようになる。
すなわち、ERPが稼動するサーバにてログイン管理を行ってデータを提供するため、携帯端末31に対して業務データ(プロセスフローデータ)を提供する際の安全性を向上させることができ、サーバが取り扱うデータをプロセスフローデータとすることにより、データ更新時に発生するI/Oデータ(入出力データ)の量を少なくすることができるようになる。
また、上述した実施の形態では、プロセスフローDB18に記憶されているプロセスフローデータには、プロセスフローデータの更新条件を示す更新条件データが対応付けされており、携帯端末管理サーバ10が、更新するプロセスフローデータに対応付けされている更新条件データに基づいてプロセスフローデータを更新する(例えば、ステップS405。図11参照。)構成としているので、業務データを更新する際の安全性を向上させることが可能となる。すなわち、例えばデータ管理の都合上、業務プロセスの一種である「出庫検収」を必ず業務プロセス「受注」、「出荷指示」、「出庫」に関するデータが登録された後にしか登録できないようにすることをユーザが望む場合に、更新条件データを設定するだけで、ユーザが望むようにプロセスフローデータの更新を制限することができるようになる。
なお、上述した実施の形態では特に言及していないが、携帯端末管理サーバ10が、プロセスフローDB18に記憶されたプロセスフローデータのうち所定条件(例えば、プロセスフローDB18に記憶されるプロセスフローデータのうち特に重要な情報についてはプロセスフローデータ一時保管DB18に保存しない条件。)を満たすデータを一時保管データベース(例えば、プロセスフローデータ一時保管DB16。)に保存し、プロセスフローDB18に記憶されているプロセスフローデータのうち、一時保管データベースに保存されているプロセスフローデータを携帯端末31に提供する(例えば、ステップS107。図5参照。)構成としてもよい。このような構成とすることにより、携帯端末31に対して提供するデータを制限することができるようになるため、安全性を向上させることが可能となる。
また、上述した実施の形態では、携帯端末31〜3Nが、予め定められた正規のログイン操作を受け付けた場合にのみログインを許可する構成としているので、携帯端末31〜3Nでの認証も必要とするようにすることができ、2重あるいは3重の認証を必要とするようにすることができ、安全性をさらに高めることが可能となる。
また、上述した実施の形態では、携帯端末管理サーバ10が、携帯端末31〜3Nからのログアウト要求があったことに応じて、ログイン状態を解除するログアウト処理を行い、ログアウト処理が実行されたことに応じて、携帯端末31〜3Nに対して伝票データの提供に関わる通信履歴情報を削除するよう要求する構成としているので(例えば、ステップSS114。図5参照。)、通信履歴情報を消去させることが可能となり、携帯端末31〜3Nの紛失等によって情報が漏洩してしまうことを防止することができるようになる。
また、上述した実施の形態では、携帯端末管理サーバ10が、ログイン状態の携帯端末31〜3Nとの情報のやりとりが行われていない時間を計測し、その計測時間が所定時間に達した場合に(例えば、ステップS112。図5参照。)、携帯端末31〜3Nに対してプロセスフローデータの提供に関わる通信履歴情報を削除するよう要求する構成としているので、通信履歴情報を消去させることが可能となり、携帯端末31〜3Nの紛失等によって情報が漏洩してしまうことを防止することができるようになる。
ここで、サーバが取り扱うデータをプロセスフローデータとすることによりデータ更新時に発生するI/Oデータ(入出力データ)の量を少なくすることができるようになると考えられる理由について、上述したデータベース更新処理(図10参照)を例にして説明する。
図16は、上述した携帯端末管理サーバ10が実行するデータベース更新処理(図10参照。)の有用性について説明するための説明図である。
図16(A)は、最初のプロセスデータの入力時におけるデータ更新量の比較結果を示す表である。ここで、最初に入力するプロセスデータの種類(すなわち、業務プロセスの種類)は特に限定されない。また、「従来型」とは、図18に示したように、各業務プロセス毎にテーブルを備えたデータベースを意味する。また、「データ量の差」とは、厳密な数値を示すものではなく、従来型テーブルに格納されたデータを更新する場合と新規型プロセスフローテーブル(すなわち、プロセスフローテーブルPT、図3参照。以下、従来型と比較する場合には適宜「新規型」と呼ぶ。)に格納されたデータを更新する場合とを比較した場合に、新規型の方が扱うデータ量が多くなる場合を+(プラス)、新規型の方が扱うデータ量が少なくなる場合を−(マイナス)、新規型と従来型とで扱うデータ量が同じとみなせる場合を「0」とする。
この場合、最初のプロセスデータの入力時においては、ステータス部の更新が必要である分だけ新規型のほうが扱うデータ量が多くなる。ただし、ステータス部のデータ量は小さいので、実質的には従来型と新規型とで、I/Oデータ(入力データと出力データ)の量に大きな差はないといえる。
一方、図16(B)は、2つ目のプロセス以降のプロセスデータの入力時におけるデータ更新量の比較結果を示す表である。すなわち、例えば、主キー部、参照キー部、タイプ部、ステータス部、共通データ部、およびプロセス固有データ部の一部(例えば、業務プロセス「受注」に応じたプロセス固有データ「受信日」,「受注テキスト」)がプロセスフローテーブルPTに入力済みのプロセスフローに含まれる業務プロセスに応じたプロセスデータの入力時におけるデータ更新量の比較結果を示す表である。なお、「従来型」は、入力済みのプロセスデータとの対応関係を定義するために、例えば受注テーブルに登録されたプロセスデータ(受注データ)に対応する他のプロセスデータ(例えば、業務プロセス「出荷指示」に対応するプロセスデータ(出荷指示データ))を入力する場合には、出荷指示データとして、本例における主キー部、参照キー部、タイプ部、共通データ部、およびプロセス固有データ部に対応するデータ(図3と図18参照)の他、対応する受注データを示す「受注番号」と「受注明細」とを入力する必要がある。
この場合、2つ目のプロセス以降のプロセスデータの入力時においては、ステータス部以外の全ての部分を必要とする従来型に比べて、新規型は、ステータス部とプロセス固有データ部のみを更新するので、I/Oデータの量が少なくなる。
よって、新規型の方が従来型よりもI/Oデータの量が少なくなり、システムのパフォーマンス上、有利となる。
すなわち、データベースのI/Oが削減することができるようになるため、書き込み量の減少、データベース全体の容量の縮減、およびデータの検索処理に要する処理負荷の軽減を実現することができるようになる。なお、検索処理に要する処理負荷の軽減に関しては、プロセス(プロセスデータ)が複数のテーブルにまたがっていないことも1つの要因となる。
また、新規型では、プレセスデータの入力順序をある程度、順不同にできるというメリットがある。すなわち、例えばタイプ「在庫売上」で考えると、従来型の場合、プロセスフローの順序が、受注、出荷指示、出庫、出庫検収、売上の順に限定され、順序を変えることができない。これは、従来型のテーブル構造では、業務プロセス間の関係を、後の業務プロセスのデータに前の業務プロセスの主キーを持たせることで表現しているためである(例えば、出荷指示テーブルにおける「受注番号」と「受注明細」。図18参照)。一方、新規型のテーブル構造では、関係する業務プロセスのデータは、同一のエントリ(すなわち、同一テーブルの同一列)に格納される。このため、業務プロセス間の前後関係に制約を持たず、業務プロセスの順序を柔軟に組み替えることができるようになる。すなわち、例えば実際の業務の順序が「出荷指示の後に受注」であった場合に、プロセスデータの入力順序を、実際の業務の順序に沿った形にすることができるようになる。そのため、進捗管理上(言い換えれば、内部統制上)、従来型に対して有利である。なお、具体的には、現在の卸売業界の業務順序が「出荷指示の後に受注」である。
また、新規型では、更新条件データの内容を、例えばシステムの管理者やユーザにより設定可能な構成とすることにより、不正なプロセスデータの入力を防止することができるようになる。すなわち、更新条件データの設定によりプロセスデータの更新に制限を持たせることができるようになるため、例えば「出庫実績のない売上を計上できてしまう」など、内部統制上で問題のある順序に制限を設けることができるようになり、データベースに対する信頼性を向上させることができるようになる。
また、新規型では、プロセスフローの進捗の照会に要する負荷を軽減させることができるようになる。すなわち、プロセスフローがどこまで進んでいるか確認する場合、従来型のテーブル構造では、開始伝票のテーブルから順に、最終伝票のテーブルまでのすべてのテーブルの登録状況を確認する必要がある。例えば、タイプ「在庫売上」を例に考えると、受注、出荷指示、出庫、出庫検収、請求の5つのテーブルを確認する必要がある。一方、新規型のテーブル構造では、プロセスフローの進捗状況を「ステータス部」として持っているため、1つのテーブル、1つのエントリを照会するだけで進捗の確認ができるようになる。これは、進捗状況の照会画面を使用もしくは開発する際に、有利である。
また、データベース(例えば、プロセスフローDB18。)が、プロセスフロー毎に発生するプロセスフローデータを管理するプロセスフローデータ管理サーバ(例えば、携帯端末管理サーバ10。)に備えられ、プロセスフローデータ管理サーバが、クライアント(例えば、携帯端末31〜3Nや統合基幹業務システム100,200,300。)からの要求に応じて、プロセスフローデータの一部又は全部をクライアントに提供する構成とすることで、業務フローに関するデータ(例えば、帳票の作成に必要な帳票情報を示すプロセスフローデータ。)の提供に要する処理負荷が従来に比べて軽減されたシステムを構築することができるようになる。
なお、上述した実施の形態では特に言及していないが、プロセスフローデータ管理サーバ(例えば、携帯端末管理サーバ10。)が、プロセスデータを登録しないと判定したことに応じて、満たされていない更新条件である非充足更新条件を特定し、特定した非充足更新条件をクライアント(例えば、携帯端末31〜3Nや統合基幹業務システム100,200,300。)に報知し、所定のタイミングで、非充足更新条件として特定した更新条件が満たされたか判定し、非充足更新条件として特定された更新条件が満たされたと判定したことに応じて、更新条件に対応するプロセスデータをプロセスフローテーブルPTに登録する構成としてもよい。このような構成とすることにより、クライアントが、同じデータを複数回入力しなければならないということを防止することができるようになる。すなわち、非充足更新条件を報知されたユーザは、非充足条件を満たすための操作を行えば既に入力済みのプロセスデータがプロセスフローテーブルに登録されることとなるので、改めてプロセスフローデータを入力する必要がなくなる。また、プロセスフローデータを管理するサーバ側にとっては、受け付けたプロセスデータに対応するプロセスフローデータの特定や更新条件の充足判定に必要な処理を再度行わずにすむこととなるため、同一処理の実行回数を減らすことができるようになる。
なお、上述した実施の形態では特に言及していないが、データベース(例えば、プロセスフローDB18)が、プロセスフローの進捗状況の判定条件を示すデータである進捗状況判定条件データが登録された進捗状況判定条件テーブルを備え、プロセスフローデータ管理サーバ(例えば、携帯端末管理サーバ10。)が、進捗状況判定条件に基づいてステータスデータ(例えば、プロセスフローテーブルPTにおけるステータス部に格納されたデータ。図3参照。)が進捗状況判定条件を満たしているか判定し、満たしていると判定した進捗状況判定条件に応じた進捗状況をクライアント(例えば、携帯端末31〜3Nや統合基幹業務システム100,200,300。)に報知する構成としてもよい。
図17は、進捗状況判定条件テーブルに格納された進捗状況判定条件データの格納状態の例を示す説明図である。図17に示すように、本例における進捗状況判定条件データは、プロセスフローのタイプと、プロセスフローのタイプに応じた進捗状況判定条件とを含む。
ここで、プロセスフローのタイプには、上述した在庫売上の他、サンプル出荷、サービス売上、名義変更(売上)、名義変更(出荷)、売上返品(元取引参照あり)、売上返品(元取引参照なし)、売上金額調整(プラス)、売上金額調整(マイナス)など、業務プロセスの異なる種々のものが考えられる。
また、「進捗状況判定条件」とは、プロセスフローの進捗状況の判定基準を示すものであり、本例においては、プロセスフローのタイプ毎に必要な業務プロセス(例えば、受注、出荷指示、出庫、出庫検収、および売上のうち予めタイプ別に設定された業務プロセス)に「1」が設定されているものとする。
携帯端末管理サーバ10は、プロセスフローテーブルPTに格納されたプロセスフローデータのうち、ステータス部の状態が進捗状況判定条件データと一致した場合に、プロセスフローデータのエントリが「完了」の状態にあると判定し(すなわち、プロセスフローデータが示すプロセスフローが完了したと判定し)、その旨を所定のクライアントに報知するための処理(報知処理)を行う。このような構成とすることにより、業務遂行状況の判定が可能なシステムを構築することができるようになる。特に、プロセスフローデータが含むステータスデータと進捗状況判定条件データとを比較するだけで業務遂行状況の判定処理が可能となるため、複数のテーブルに格納されたデータの入力状況を参照する必要がある従来のものと比べて、業務遂行状況の判定に要する処理負荷を軽減させることができる。
なお、進捗状況の判定処理または報知処理の開始時機は、クライアントからの要求があったときであってもよいし、予め設定された時機であってもよい。
また、上述した進捗状況判定条件テーブルの例では、進捗状況判定条件データが、プロセスフローが完了したか判定するための完了条件を含む構成としているので、一連の業務の完了判定が容易に可能なシステムを構築することができるようになる。
なお、進捗状況判定条件データは、プロセスフローが「完了」の状態にあると判定するためのものに限定されず、例えば、「50%完了」の状態にあると判定するためのデータが含まれる構成としてもよい。また、進捗状況判定条件データが、最初のプロセスデータの入力時から所定時間が経過するまでに入力されるべきであるプロセスデータの種類を示す構成としてもよい。
また、進捗状況判定条件テーブルに、上述したような「入力されるべきデータが全て入力されたか」の判定機能だけでなく、「入力されるべきではないデータが入力されないよう」にデータの入力を制限する機能を持たせる構成としてもよい。この場合、例えば、携帯端末管理サーバ10が、プロセスフローテーブルPTを更新するときに、追加するプロセスデータがプロセス固有データである場合に、追加するプロセス固有データの種類と進捗状況判定条件テーブルとを比較して、追加するプロセス固有データの種類が進捗状況条件テーブルに「1」が設定されていない業務プロセスに対応するものである場合にはプロセスフローテーブルの更新をしない構成とすればよい。
なお、上述した実施の形態では特に言及していないが、データベース(例えば、プロセスフローDB18)が、所定のデータが入力されたことに応じて、プロセスフローテーブルPTに登録済みのデータのうち少なくとも一部に、データ内容の変更に関する制限を設ける構成としてもよい。すなわち、例えば、プロセスフローDB18が備えるプロセスフローテーブルPTにプロセス「出庫検収」に関するプロセス固有データが登録される前では、プロセスフローテーブルPTにおける共通データ部の変更(例えば、データの削除や上書き)が可能であるが、プロセスフローテーブルPTにプロセス「出庫検収」に関するプロセス固有データが登録された後では、共通データ部の変更が自由にできないようになる構成としてもよい。この場合、例えば、ユーザが共通データ部の内容を変更する場合に入力すべきパスワードや満たすべき条件などの制限を加える構成とすればよい。このような構成とすることにより、一部のデータの変更に伴うデータ全体における矛盾の発生(すなわち、入力済みのデータの修正に伴う関連データの整合性の欠落)を防止することができるようになる。
なお、上述した実施の形態では特に言及していないが、携帯端末管理サーバ10は、自己が備える記憶媒体に記憶されている処理プログラム(携帯端末管理プログラム)に従って、上述した各処理(図5、図8、図10、図11参照)を実行する。
本発明の携帯端末管理サーバは、ERPが稼動するサーバであって、ユーザが使用する携帯端末からの要求に応じて通信ネットワークを介して各種データを提供する携帯端末管理サーバにおいて、複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータを記憶するプロセスフローデータ記憶手段と、前記プロセスフローの進捗状況に応じて前記プロセスフローデータ記憶手段に記憶されているプロセスフローデータを更新するプロセスフローデータ更新手段と、前記携帯端末からのログイン要求があったときに、当該携帯端末に対してログインを許可するか否か判定するログイン判定手段と、該ログイン判定手段によってログインを許可すると判定された場合にログイン処理を行うログイン処理手段と、該ログイン処理手段によってログイン処理が実行されたログイン状態の前記携帯端末からのプロセスフローデータの閲覧要求を受け付ける閲覧要求受付手段と、該閲覧要求受付手段によって受け付けられた閲覧要求に応じて、前記プロセスフローデータ記憶手段に記憶されているプロセスフローデータを前記携帯端末に提供するプロセスフローデータ提供手段とを含み、前記プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、前記ステータスデータは、前記プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであり、前記共通データは、同一のプロセスフローに含まれる業務プロセス間で共通するデータであり、前記プロセス固有データは、同一のプロセスフローに含まれる各業務プロセスに固有のデータであり、前記プロセスフローデータ記憶手段に記憶されているプロセスフローデータには、プロセスフローデータの更新条件を示す更新条件データが対応付けされており、前記更新条件データは、前記プロセスフローデータ記憶手段に記憶されている更新条件テーブルに格納されており、前記プロセスフローデータ更新手段は、前記更新条件データに基づいてプロセスフローデータを更新し、前記プロセス固有データの更新状況に応じて前記ステータスデータを更新することを特徴とする。
また、本発明の携帯端末管理プログラムは、ERPを稼動させ、ユーザが使用する携帯端末からの要求に応じて通信ネットワークを介して各種データを提供する処理を携帯端末管理サーバに実行させる携帯端末管理プログラムであって、複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータを記憶するプロセスフローデータ記憶手段を備えた前記携帯端末管理サーバに、前記プロセスフローの進捗状況に応じて前記プロセスフローデータ記憶手段に記憶されているプロセスフローデータを更新するプロセスフローデータ更新処理と、前記携帯端末からのログイン要求があったときに、当該携帯端末に対してログインを許可するか否か判定するログイン判定処理と、該ログイン判定処理にてログインを許可すると判定した場合にログイン処理を行うログイン処理実行処理と、該ログイン処理実行処理にてログイン処理が実行されたログイン状態の前記携帯端末からのプロセスフローデータの閲覧要求を受け付ける閲覧要求受付処理と、該閲覧要求受付処理にて受け付けた閲覧要求に応じて、前記プロセスフローデータ記憶手段に記憶されているプロセスフローデータを前記携帯端末に提供するプロセスフローデータ提供処理とを実行させ、前記プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、前記ステータスデータは、前記プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであり、前記共通データは、同一のプロセスフローに含まれる業務プロセス間で共通するデータであり、前記プロセス固有データは、同一のプロセスフローに含まれる各業務プロセスに固有のデータであり、前記プロセスフローデータ記憶手段が記憶するプロセスフローデータには、プロセスフローデータの更新条件を示す更新条件データが対応付けされており、前記更新条件データは、前記プロセスフローデータ記憶手段が記憶する更新条件テーブルに格納されており、前記プロセスフローデータ更新処理において、前記更新条件データに基づいてプロセスフローデータを更新する処理と、前記プロセス固有データの更新状況に応じて前記ステータスデータを更新する処理とを実行させるためのものである。
すなわち、本例におけるステータス部は、業務プロセス毎に更新される。言い換えれば、ステータス部は、後述するプロセス固有データの入力のとき、具体的には、所定のステータス変更条件が満たされたことにより各業務プロセスが完了したと判定されたときに更新される。なお、ステータス変更条件は特に限定されないが、本例においては、「1つの業務プロセスに対応するプロセス固有データが全て入力されること」がステータス変更条件として携帯端末管理サーバ10の所定の記憶領域に記憶されているものとする。
本発明の携帯端末管理サーバは、ERPが稼動するサーバであって、ユーザが使用する携帯端末からの要求に応じて通信ネットワークを介して各種データを提供する携帯端末管理サーバにおいて、複数の業務プロセスを含むプロセスフローに関するプロセスデータを含むプロセスフローデータを記憶するプロセスフローデータ記憶手段と、前記プロセスフローの進捗状況に応じて入力されるプロセスデータに基づいて、前記プロセスフローデータ記憶手段に記憶されているプロセスフローデータを更新するプロセスフローデータ更新手段と、前記携帯端末からのログイン要求があったときに、当該携帯端末に対してログインを許可するか否か判定するログイン判定手段と、該ログイン判定手段によってログインを許可すると判定された場合にログイン処理を行うログイン処理手段と、該ログイン処理手段によってログイン処理が実行されたログイン状態の前記携帯端末からのプロセスフローデータの閲覧要求を受け付ける閲覧要求受付手段と、該閲覧要求受付手段によって受け付けられた閲覧要求に応じて、前記プロセスフローデータ記憶手段に記憶されているプロセスフローデータを前記携帯端末に提供するプロセスフローデータ提供手段とを含み、前記プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、前記ステータスデータは、前記プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであり、前記共通データは、同一のプロセスフローに含まれる業務プロセス間で共通するデータであり、前記プロセス固有データは、同一のプロセスフローに含まれる各業務プロセスに固有のデータであり、前記プロセスフローデータ記憶手段に記憶されているプロセスフローデータには、プロセスフローデータの更新条件を示す更新条件データが対応付けされており、前記更新条件データは、前記プロセスフローデータ記憶手段に記憶されている更新条件テーブルに格納されており、前記プロセスフローデータ更新手段は、入力されたプロセスデータが前記更新条件を満たしている場合に当該プロセスデータに基づいてプロセスフローデータを更新し、当該入力されたプロセスデータが前記更新条件を満たしていない場合に満たされていない更新条件である非充足更新条件を特定し、所定のタイミングで前記非充足更新条件として特定した更新条件が満たされたか判定し、前記非充足更新条件として特定された更新条件を満たしている場合に当該プロセスデータに基づいてプロセスフローデータを更新し、前記プロセス固有データの更新状況に応じて前記ステータスデータを更新する
ことを特徴とする。
また、本発明の携帯端末管理プログラムは、ERPを稼動させ、ユーザが使用する携帯端末からの要求に応じて通信ネットワークを介して各種データを提供する処理を携帯端末管理サーバに実行させる携帯端末管理プログラムであって、複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータを記憶するプロセスフローデータ記憶手段を備えた前記携帯端末管理サーバに、前記プロセスフローの進捗状況に応じて前記プロセスフローデータ記憶手段に記憶されているプロセスフローデータを更新するプロセスフローデータ更新処理と、前記携帯端末からのログイン要求があったときに、当該携帯端末に対してログインを許可するか否か判定するログイン判定処理と、該ログイン判定処理にてログインを許可すると判定した場合にログイン処理を行うログイン処理実行処理と、該ログイン処理実行処理にてログイン処理が実行されたログイン状態の前記携帯端末からのプロセスフローデータの閲覧要求を受け付ける閲覧要求受付処理と、該閲覧要求受付処理にて受け付けた閲覧要求に応じて、前記プロセスフローデータ記憶手段に記憶されているプロセスフローデータを前記携帯端末に提供するプロセスフローデータ提供処理とを実行させ、前記プロセスフローデータは、ステータスデータと、共通データと、プロセス固有データとを含むデータであり、前記ステータスデータは、前記プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータであり、前記共通データは、同一のプロセスフローに含まれる業務プロセス間で共通するデータであり、前記プロセス固有データは、同一のプロセスフローに含まれる各業務プロセスに固有のデータであり、前記プロセスフローデータ記憶手段が記憶するプロセスフローデータには、プロセスフローデータの更新条件を示す更新条件データが対応付けされており、前記更新条件データは、前記プロセスフローデータ記憶手段が記憶する更新条件テーブルに格納されており、前記プロセスフローデータ更新処理において、前記更新条件データに基づいてプロセスフローデータを更新する処理と、前記プロセス固有データの更新状況に応じて前記ステータスデータを更新する処理とを実行させるためのものである。