JP2005284881A - 業務進捗状況管理システム - Google Patents

Abstract

【課題】異なる役割を受けもつ複数の主体が協働して仕事をするシステムにおいて業務の迅速化を図ること
【解決手段】サーバコンピュータ１１と複数の主体の端末とが通信ネットワークを介して接続される仕事管理システムであり、上記サーバコンピュータ１１は、異なる役割を受けもつ複数の主体の作業ステップを管理する手段と、一の主体の端末がサーバコンピュータ１１に接続された場合当該主体の端末画面上に業務全体の流れ図を表示するとともに、自己の業務分担部分と他人の業務分担部分とを識別可能に表示する手段とを備える。上記流れ図は所定のステップをボックスとして表示するとともに各ボックスを矢印にて連結してなる骨格を有し、該流れ図の骨格がいずれの主体にも同一画面として表示される。上記ボックスに主体の業務分担部分の残処理件数の表示がある。
【選択図】図４

Description

本願発明は、異なる役割を受けもつ複数の主体が協働して仕事をするシステムに関し、さらに詳しくは協働して仕事の進捗状況を管理する業務進捗状況管理システムに関する。

現今の各種業務は単独の人又は部署が最初から最後まで受けもつということは殆んどなく、複数の異なる主体が種々の段階で関係することが多い。

このように処理ステップが多くかつ複数な案件の場合、各主体の内部では夫々に管理体制が整っていたとしても全体を通じての管理体制が整っていないため、どこまで処理が進んでいるか判然とせず、現在只今の進捗状況を正確に把握できないことが多い。

例えば、商品の発注及び納品において、所定期間経過したのに納品されない場合、発注者はそもそも発注が成立しているのか否か、製造段階でトラブルが起こっているのか否か、流通段階でトラブルが起こっているのか否か等を瞬時に把握することは殆んど不可能であり、トラブルの処理にかなりの時間と労力を費やしてしまう。

これらのトラブルの原因は、例えば、能力オーバーのための処理の遅れ、書類の紛失や処理漏れといったミス、処理手続ルールが不明確なための不達等々種々のパターンが考えられる。しかし、いずれにしても結果未実現という意味では等価であり、理由不明の状態で待たされるということになって不満を招くこととなり、ビジネスチャンスの喪失という最悪の事態にもなりかねない。

このようなことは対外的な関係だけでなく、対内的な関係例えば社内手続においても同様に起こり得る。

「仕事」×「管理」×「ステップ」及び「タスク」×「管理」×「ステップ」として抽出された特許文献は合計４６件あった。このうち、本願発明の背景技術となる特許文献は見出せなかったが、強いて特許文献を挙げるとすれば次の如くである。
特開２００２−２６９３０８号公報

このような従来のシステムは、個々の主体（例えば各会社、各部門）内での個々の処理乃至データのシステムであって各主体内で完結してしまうため、個別の処理状況しか判らなかった。

つまり、他の主体の動きが把握できず全体の処理の流れ乃至手続が判らないため、どの程度の手間と時間がかかるのか判らず、一般の顧客だけでなく各主体に不満と不安があった。

また現在の処理が終了しても次の処理を要するのか否か、要する場合どのタイミングで行うのか不明のため当該主体の準備が出来ず、かつ該主体の処理に関係する他の主体との連携がとれないという欠点があった。

さらに、各主体が関係する他の主体との連携上、何度も同じ書類を書き直すことが頻発するので、書き損じ、入力ミスその他の人為的ミスが起きていた。

本願発明は上記欠点を解消し、異なる役割を受けもつ複数の主体が協働して仕事をするシステムにおいて、人為的ミスを防止し、業務の迅速化を図ることを目的とする。

上記目的達成のため、本願発明による業務進捗状況管理システムは、サーバコンピュータと複数の主体の端末とが通信ネットワークを介して接続される仕事管理システムにおいて、上記サーバコンピュータは、異なる役割を受けもつ複数の主体の作業ステップを管理する手段と、一の主体の端末がサーバコンピュータに接続された場合当該主体の端末画面上に業務全体の流れ図を表示するとともに、自己の業務分担部分と他者の業務分担部分とを識別可能に表示する手段とを備え、上記流れ図は所定のステップをボックスとして表示するとともに各ボックスを矢印にて連結してなる骨格を有し、該流れ図の骨格がいずれの主体にも同一画面として表示されることを特徴とする。
また、請求項１記載の業務進捗状況管理システムにおいて、上記流れ図のボックスに主体の業務分担部分の残処理件数の表示があることを特徴とする。
また、請求項１記載の業務進捗状況管理システムにおいて、上記流れ図のボックスが進行順に表示されることを特徴とする。
また、請求項１記載の業務進捗状況管理システムにおいて、上記流れ図は一覧画面にて表示されることを特徴とする。
また、請求項１記載の業務進捗状況管理システムにおいて、自己の業務分担部分の識別は色分けにてなされることを特徴とする。
また、請求項１記載の業務進捗状況管理システムにおいて、自己の業務分担部分の識別は点滅にてなされることを特徴とする。
また、請求項４記載の業務進捗状況管理システムにおいて、上記一覧画面がスクローリングにより得られることを特徴とする。

本願発明にかかる業務進捗状況管理システムによれば、業務全体を同一の一覧画面である流れ図として表示するので、各主体は業務全体の中での自分の役割乃至業務分担部分の位置付けを容易に理解することができる。

また業務の進捗状況を各主体全員が同一骨格の流れ図の中で視覚的に確認できるため、業務の流れが明確となり業務処理の透明性が向上する。

よって業務の迅速化を図ることができる。

業務の進捗状況を視覚的に確認できるため、業務の流れを整然と判別することができる。これにより当該ステップ業務に判断を要するのか否かが容易に判別可能となるので、この面からも業務の迅速化を図ることができる。

一覧画面に各ステップ業務の残処理件数を表示することができるので、主体間の相互牽制作用が働き、業務の進捗に寄与する。

また各主体は業務の進捗状況を把握することにより、他の主体と連携をとることができるので、業務の円滑化を図ることができる。この連携において場合によっては止まっている業務に対する他の主体への牽制機能を発揮することができる。

次に、実施の形態を示す図面に基づき本願発明による業務進捗状況管理システムをさらに詳しく説明する。なお、便宜上同一の機能を奏する部分には同一の符号を付してその説明を省略する。

図１乃至図３において、１は本システムを管理・運営するサーバ会社であり、サーバコンピュータ１１を有する。３は一般顧客２に商品（例えばＯＡ機器）を販売する販売会社である。５は一般顧客２を販売会社３、物流会社７、サービス提供会社９の顧客として登録するか否か及びサーバ会社１の依頼により一般顧客２の同一性を審査・確認する保証会社である。７は販売会社３により販売された商品を一般顧客２に配送する物流会社である。９は一般顧客２の使用する商品のメンテナンスを行なうサービス提供会社である。サーバ会社１、販売会社３、保証会社５、物流会社７、サービス提供会社９の各端末はサーバ会社１のサーバコンピュータ１１にインターネット１０を介して通信可能に接続される。

サーバコンピュータ１１の構成は図１に示す通りであり、上記ユーザ１、３、５、７、９の各端末とインターネット１０を介して接続されるウェブサーバ１１Ａと、該ウェブサーバ１１Ａに接続されるファイアウォール１１Ｂと、該ファイアウォール１１Ｂに接続されるデータベースサーバ１１Ｃ、ファクシミリサーバ１１Ｄ及び決済系サーバ１１Ｅとからなる。上記データベースサーバ１１Ｃは長期保存用データ用サーバ１１Ｆを有し、データ保存部を構成する。上記ファクシミリサーバ１１Ｄはファクシミリの送受信及びメールの送信をする。上記決済系サーバ１１Ｅはカード会社等の決済会社と通信する。

サーバコンピュータ１１における処理の概略を図２に基づき説明すると次の通りである。
（１）まずサーバコンピュータ１１のネットワークでは、ウェブサーバ１１Ａ内のデータ送受信部１１ｎで受信された申込情報が業務フロー管理モジュール１１ｍに送られる。
（２）該業務フロー管理モジュール１１ｍでは、申込情報に基づき管理すべきワークフローデータを新規に作成し、データベースサーバ１１Ｃに保存するとともに、管理情報の次タスクを設定する。
（３）次タスクを処理する販売会社３がシステムに参加すると、業務フロー管理モジュール１１ｍは、ログイン処理等から得られる販売会社３の情報に基づき、販売会社３が処理可能なワークフローデータを業務フロー管理モジュール１１ｍにて抽出し、データ送受信部１１ｎを介して販売会社３の端末画面に表示させる。
（４）販売会社３は、その端末画面に表示された処理可能なワークフローにデータを入力する。
（５）販売会社３によって入力されたデータは、データベースサーバ１１Ｃに保存されるとともに、管理情報の次タスクを設定する。
（６）次タスクを処理する保証会社５がシステムに参加すると、業務フロー管理モジュール１１ｍは、ログイン処理等から得られる保証会社５の情報に基づき、保証会社５が処理可能なワークフローデータを業務フロー管理モジュール１１ｍにて抽出し、データ送受信部１１ｎを介して保証会社５の端末画面に表示させる。
（７）保証会社５は、その端末画面に表示された処理可能なワークフローにデータを入力する。
（８）保証会社５によって入力されたデータは、データベースサーバ１１Ｃに保存されるとともに、管理情報の次タスクを設定する。
（９）次タスクを処理するサーバ会社１がシステムに参加すると、業務フロー管理モジュール１１ｍは、ログイン処理等から得られる保証会社ユーザ情報に基づき、サーバ会社１が処理可能なワークフローデータを業務フロー管理モジュール１１ｍにて抽出し、データ送受信部１１ｎを介してサーバ会社１の端末画面に表示させる。
（１０）サーバ会社１は、端末画面に表示された処理可能なワークフローにデータを入力する。
（１１）サーバ会社１によって入力されたデータは、データベースサーバ１１Ｃに保存されるとともに、管理情報の次タスクを設定する。
（１２）以下、申込情報が各ユーザに受信される毎に、各ユーザは（１）〜（１１）のステップを繰り返す。なお、図２では（１１）以降のステップの図示を省略してある。
（１３）上記以外では、ウェブサーバ１１Ａ内のデータ送受信部１１ｎを通して、データベースサーバ１１Ｃ内のデータにアクセスし、検索、進捗状況、統計データなどの確認を行うことができる。

図３は各主体間の関係を示すフローチャートである。この図３と図４以下に基づき本願発明による業務進捗状況管理システムの具体的な実施例を述べる。なお、本願システムの内容と直接関係のないステップは点線で示す。まず、一般顧客２は、申込書に購入したい商品を記入する等して販売会社３に申込む（＜１＞）。申込に際しては、決済手段を選択することができる。販売会社３では、図示しない端末にて当該申込を図５に示す「新規入力」画面により入力し、サーバコンピュータ１１に送信する（Ｓ１、＜２＞）。

入力情報は「申込日」、「受付日」、カード番号、カード有効期限、カード種類等の「決済情報」、申込人の住所、氏名、職業、電話番号、家族、年収等の「申込人情報」、「連帯保証人予定者」、商品コード、リース期間、月額リース料、リース料総額等の「商品情報」、「サービス情報」等である。「受付番号」は送信後自動的に付与される。「連帯保証人予定者」及び「サービス情報」の入力項目は、例えば図５記載の通りである。

この申込があった旨はサーバ会社１に連絡され（＜３＞）、例えばクレジットカード決済の場合、サーバ会社１よりカード会社に連絡される。該カード会社ではそのコンピュータ（図示せず）により当該クレジットカードの自動処理（「オーソリ処理」という）を行なう（＜４＞）。これがＯＫのときはオーソリ結果を入力し（＜５＞）、入力情報を保証会社５に送信し審査を依頼する（＜６＞）。オーソリ結果の入力は、契約に定めるところにより、サーバ会社１又はカード会社のいずれかが行なう。なお、カード会社はこのシステムではサーバ会社１と一体に行動しているので、図４では便宜上サーバ会社１のところに示す。

ＯＫでない（ＮＧ）ときは販売会社３にその旨連絡される（＜７＞）。販売会社３ではその旨「新規入力」画面に入力される。なお、上記申込書が一般顧客２に返戻されるとともにその旨電話連絡する（＜８＞）。

審査依頼された保証会社５は図示しない端末にて「プルーフチェック」を行なう（＜９＞、Ｓ２）。保証会社５は、まず図４に示す一覧画面（ワークリスト画面）を表示させ、「プルーフチェック」ボックスに件数の表示がある場合は「プルーフチェック」ボックスの件数リンクボタンをクリックする。すると端末に図６に示す「プルーフチェック」画面が表示されるので、この一覧画面により一括処理をする。次いでプルーフチェック対象の申込者を選択した後、「送信」ボタンをクリックし、データをサーバコンピュータ１１に送信する。送信されるデータは、例えば、番付番号、申込者氏名、電話番号、リース期間、リース料総額、月額リース料、支払方法等である。データ送信が終了すると、送信されたデータはプルーフチェック画面から削除される。

プルーフチェックにおいて、対象者の受付番号例えば「Ｔ０００００１０」を選択すると、図７に示す「プルーフチェック」画面が表示される。この画面は図５に示す申込書形式の「新規入力」画面と実質上同一であり、とくに「申込人情報」「連帯保証人予定者」「商品情報」「サービス情報」及び「決済情報」が全く同一体裁で表示される。

また、保証会社５は図４のワークリストを表示させ、「審査結果入力」ボックスの件数リンクボタンをクリックする。すると図８に示す「審査結果入力」画面が表示されるので、これにより審査結果の入力を行なう（＜１０＞、Ｓ３）。これは入力されている検索条件に合致するデータを検索するステップである。検索条件は、例えば、受付番号、申込者氏名、自宅の電話番号、携帯電話の番号である。図示例の検索条件は受付番号である。

「審査結果入力」の入力項目は、例えば、審査結果（審査ＯＫまたは審査ＮＧ）、契約書の原本（確認又は未確認）、保証委託番号、リース期間、リース総額、カードレスカード（ＣＬＣ）／カード番号、月額リース料、支払方法、有効期限、備考（特記事項等）である。各項目入力後「送信」ボタンをクリックしデータをサーバコンピュータ１１に送信する。データ送信が終了すると、送信されたデータは「審査結果入力」画面から削除される。

審査結果がＮＧの場合は、販売会社３による結果確認処理を行なう（＜１１＞、Ｓ４）。販売会社３は、まず図４に示す一覧画面（ワークリスト画面）を表示させ、「審査結果確認」ボックスに件数の表示がある場合は「審査結果確認」ボックスの件数リンクボタンをクリックする。すると端末に図９に示す「審査結果確認」画面が表示されるので、所定の検索条件を選択・入力し、確認処理対象者のフォルダボタンをクリックする。すると図７に示す「プルーフチェック」画面と同一体裁のチェック用明細画面（以下「チェック画面」という。図示省略）が表示される。ただし、このチェック画面には、審査結果欄に「ＮＧ」、契約原本欄に「未確認」と表示されている。また、このチェック画面に表示される「申込情報を完了する」又は「申込情報を再考する」のいずれかを選択し（図示省略）、送信ボタンをクリックする。前者選択の場合は受付中止となり、後者選択の場合はプルーフチェック処理待ちデータとなりステップ２（Ｓ２）に移行する。データ送信が終了すると、送信されたデータは「審査結果確認」画面から削除される。なお、販売会社３ではステップ２（Ｓ２）に戻ってプルーフチェックを再確認し、間違いないときはその旨一般顧客２に電話連絡する。

審査結果がＯＫの場合は、サーバ会社１による申込内容承認ステップに移行する（＜１２＞、Ｓ５）。サーバ会社１は、まず図４に示す一覧画面（ワークリスト画面）を表示させ、「申込内容承認」ボックスに件数の表示がある場合は「申込内容承認」ボックスの件数リンクボタンをクリックする。するとサーバ会社１の端末に図１０に示す「申込内容承認」画面が表示されるので、これにより申込内容の承認を行なう。まず所定の検索条件を選択・入力した後、承認対象者のフォルダボタンをクリックする。すると直前ステップ（段落番号［００３２］）まで入力された図７の「プルーフチェック」画面と同一体裁のチェック画面となり、審査結果欄に「ＯＫ」、保証受託番号、新規カード番号及び有効期限の各欄に夫々所定の情報が表示されるので、表示データの確認後「送信」ボタンをクリックしデータをサーバコンピュータ１１に送信する。データ送信が終了すると、送信されたデータは「申込内容承認」画面から削除される。

申込内容が承認されるとサービス提供会社９によるデータエントリーステップに移行する（＜１３＞，Ｓ６）。サービス提供会社９は、まず図４に示す一覧画面（ワークリスト画面）を表示させ、「データエントリー」ボックスに件数の表示がある場合は「データエントリー」ボックスの件数リンクボタンをクリックする。するとサービス提供会社９の端末に図１１に示す「データエントリー」画面が表示されるので、これによりデータエントリー処理を行なう。この処理は所定の検索条件を選択・入力した後、エントリーのフォルダボタンをクリックする。すると直前ステップ（段落番号［００３３］）まで入力された図７の「プルーフチェック」画面と同一体裁のチェック画面となり、所定の情報が表示されるので、表示データの確認後「送信」ボタンをクリックしデータをサーバコンピュータ１１に送信する。データ送信が終了すると、送信されたデータは「データエントリー」画面から削除される。

次いで物流会社７による出荷ステップに移行する（＜１４＞、Ｓ７）。物流会社７はまず図４に示す一覧画面（ワークリスト画面）を表示させ、「出荷」ボックスに件数の表示がある場合は「出荷」ボックスの件数リンクボタンをクリックする。すると物流会社７の端末に図１２に示す「出荷」画面が表示されるので、これにより出荷処理を行なう。まず所定の検索条件を選択・入力した後、対象者のフォルダボタンをクリックする。すると直前ステップ（段落番号［００３４］）まで入力された図７の「プルーフチェック」画面と同一体裁のチェック画面となり、所定の情報が表示されるので、着荷確認情報欄の「Ｂ−ＣＡＳ ＩＤ」に表示されたデータを確認後「送信」ボタンをクリックし、データをサーバコンピュータ１１に送信する。データ送信が終了すると、送信されたデータは「出荷」画面から削除される。

上記出荷ステップになると物流会社７内での事務及び作業となり、物流会社７は現実に一般顧客２に商品を引き渡す（＜１５＞）。

物流会社７は商品の引渡後着荷確認完了処理をする（Ｓ８）。まず図４に示す一覧画面（ワークリスト画面）を表示させ、「着荷確認完了」ボックスに件数の表示がある場合は「着荷確認完了」ボックスの件数リンクボタンをクリックする。すると物流会社７の端末に図１３に示す「着荷確認完了」画面が表示されるので、これにより着荷確認完了処理を行なう。まず所定の検索条件を選択・入力した後、対象者のフォルダボタンをクリックする。すると直前ステップ（段落番号［００３５］）まで入力された図７の「プルーフチェック」画面と同一体裁のチェック画面となり、所定の情報が表示されるので、着荷確認情報欄の「配達先住所」「配達先氏名」「配送先電話」「機体ＩＤ」「着荷日」「製造番号」に表示されたデータを確認後「送信」ボタンをクリックし、データをサーバコンピュータ１１に送信する。データ送信が終了すると、送信されたデータは「着荷確認完了」画面から削除される。

次いで販売会社３による着荷完了報告ステップに移行する（＜１６＞、Ｓ９）。販売会社３はまず図４に示す一覧画面（ワークリスト画面）を表示させ、「着荷完了報告」ボックスに件数の表示がある場合は「着荷完了報告」ボックスの件数リンクボタンをクリックする。すると販売会社３の端末に図１４に示す「着荷完了報告」画面が表示されるので、これにより着荷完了報告の処理を行なう。まず所定の検索条件を選択・入力した後、対象者のフォルダボタンをクリックする。すると直前ステップ（段落番号［００３７］）まで入力された図７の「プルーフチェック」画面と同一体裁のチェック画面となり、所定の情報が表示されるので、表示データの確認後「送信」ボタンをクリックしデータをサーバコンピュータ１１に送信する。データ送信が終了すると、送信されたデータは「着荷完了報告」画面から削除される。

次いでサーバ会社１によるリース／レンタル契約締結ステップに移行する（＜１７＞、Ｓ１０）。サーバ会社１はまず図４に示す一覧画面（ワークリスト画面）を表示させ、「契約締結」ボックスに件数の表示がある場合は「契約締結」ボックスの件数リンクボタンをクリックする。するとサーバ会社１の端末に図１５に示す「契約締結」画面が表示されるので、これによりリース／レンタル契約の締結を行なう。まず所定の検索条件を選択・入力した後、対象者のフォルダボタンをクリックする。すると直前ステップ（段落番号［００３８］）まで入力された図７の「プルーフチェック」画面と同一体裁のチェック画面となり、所定の情報が表示されるので、表示データの確認後「送信」ボタンをクリックしデータをサーバコンピュータ１１に送信する。データ送信が終了すると、送信されたデータは「契約締結」画面から削除される。

サーバ会社１と一般顧客２の間でリース／レンタル契約が締結されると、サーバ会社１、販売会社３、保証会社５は夫々契約内容の「開始確認」をする（Ｓ１１ａ、Ｓ１１ｂ、Ｓ１１ｃ）。夫々の主体１、５、９は、まず図４に示す一覧画面（ワークリスト画面）を表示させ、「開始確認」ボックスに件数の表示がある場合は「開始確認」ボックスの件数リンクボタンをクリックする。すると夫々の主体の端末に図１６に示す「開始確認」画面が表示されるので、これにより契約内容の確認を行なう。まず所定の検索条件を選択・入力した後、対象者のフォルダボタンをクリックする。すると最終ステップ（段落番号［００３９］）まで入力された図７の「プルーフチェック」画面と同一体裁のチェック画面となり、所定の情報が表示されるので、表示データの確認後「送信」ボタンをクリックしデータをサーバコンピュータ１１に送信する。データ送信が終了すると、送信されたデータは「開始確認」画面から削除される。図１６はサーバ会社１と一般顧客２との間のサービス内容の「開始確認」画面であるが、サーバ会社１・保証会社５間、サービス提供会社９・一般顧客２間のサービス内容の「開始確認」画面も当然同一である。

上記契約締結後は夫々の契約内容に基づき契約が実行される。例えば、サーバ会社１と一般顧客２と間ではリース／レンタル契約が開始され（＜１７＞）、また課金が開始される（＜２０＞）。サービス提供会社９と一般顧客２と間では保守契約が開始され（＜１８＞）、サーバ会社１と保証会社５との間では上記リース／レンタル契約の保証が開始される（＜１９＞）。

各主体１、３、５、７、９によるサーバコンピュータ１１へのアクセスは、所定のユーザー名（ＩＤ）、パスワードを入力することにより行なう。サーバコンピュータ１１ではユーザー名（ＩＤ）、パスワードによるアクセス制限を施しているため、共有したい情報と共有したくない情報とを明確に分けて管理している。またアクセスしてきた主体１、３、５、７、９のステップについては例えば赤色にする等他のステップとは色分けされている。

サーバコンピュータ１１のデータベースは業務の進捗状況に応じてその都度更新される。

上記した実施の形態によれば次の如き作用、効果がある。まず業務全体を同一画面にワークリスト化して工程順に表示し、かつ骨格が同一の流れ図の中に各主体１、３、５、７、９ごとに明示的に表示するので、各主体１、３、５、７、９は業務全体の中での自分の役割乃至業務分担部分の位置付けを容易に理解することができる。

また業務の進捗状況を各主体１、３、５、７、９全員が同一骨格の流れ図の中で視覚的に確認できるため、業務の流れが明確となり業務処理の透明性が向上する。

よって、人為的ミスを防止し、かつ業務の迅速化を達成することができる。

業務の進捗状況を視覚的に確認できるため、業務の流れを整然と判別することができる。これにより当該ステップ業務に判断を要するのか否かが容易に判別可能となるので、この面からも業務の迅速化を図ることができる。

ワークリスト全部を表示した一覧画面に各ステップ業務の残処理件数を表示することができるので、主体間１、３、５、７、９の相互牽制作用が働き、業務の進捗に寄与する。

また各主体１、３、５、７、９は業務の進捗状況を把握することにより、他の主体と連携をとることができるので、業務の円滑化を図ることができる。この連携において、場合によっては止まっている業務に対する他の主体への牽制機能を発揮することができる。

さらに主体全員で使用する共通のデータベースが業務の進捗状況に応じてその都度更新されるので、各主体１、３、５、７、９にリアルタイムで情報伝達をすることができる。

各主体１、３、５、７、９は業務の進捗状況を把握することにより、自分の分担業務の有無及びボリューム（件数）を把握することができる。また次のステップに容易に対応することができる。そして自分の現在能力以上の業務分担部分を受けもっていると判断するときは、例えば他の支店や子会社等の応援を取り付けるべく早期に対応することができる。

各主体１、３、５、７、９は、夫々他の主体の処理がどのステップで止まっているのか一目で判明するので、ステップの業務の改善を図ることができる。

各主体１、３、５、７、９が申込内容の確認をする場合に参照する画面はいずれのステップにおいても図７に示す申込書形式の「プルーフチェック」画面及びこれと同一体裁のチェック画面であり、しかもこの画面は各主体共通に利用する。よって申込内容の確認が非常に容易であり、また主体間の連携が容易となる。

よって、これらの面からも業務の迅速化に寄与する効果がある。

共有のサーバコンピュータに各主体個々のデータを格納しておき、主体全員がこの共通のデータベースを使用するため、データの一元管理をすることができる。

また主体全員が共通のデータベースを使用するため、主体は社外、社内いずれからでもアクセスすることができる。

さらに本システムはウェブ（ＷＥＢ）ベースのため、種々の業務に柔軟に対応することができる。また現有のコンピュータハード及びソフトウェアに適用可能なので、コスト低減に寄与する。

本願発明は上記した実施の形態に制限されない、例えば各主体１、２、３、５、７、９の人数には制限がなく、多人数に広く適用することができる。

また販売会社３、サービス提供会社９又は保証会社５が存在しない場合にも適用することができる。例えば、図１７はサービス提供会社９が存在しない場合の例である。この場合はステップ８（Ｓ８）までは前記実施例と同様であり、前記実施例のステップ９（Ｓ９）がなく販売会社３が直接一般顧客２に納品する。また、図１８はサービスのみを受注した場合である。この場合は、申込の際の「新規入力」ステップ（Ｓ１）及び「審査結果確認」ステップ（Ｓ４）を行うのはサーバ会社１であり、「データエントリー」ステップ（Ｓ６）後、サービス内容の「開始確認」となる（Ｓ７ａ、Ｓ７ｂ）。

また、主体として一般顧客２が参加することを妨げない。

「新規入力」画面並びに図７の「プルーフチェック」画面及びチェック画面は同一体裁であれば、適宜に変更可能である。

業務全体のステップを表示する流れ図は、業務の内容により適宜の骨格に変更可能である。

本願発明は対外的な関係の業務処理だけでなく、対内的な関係の業務処理（例えば社内手続）にも適用できる。また両者の混合型もにも適用することができる。

自己の業務分担部分の識別が点滅にてなされることとしてもよい。

ワークリスト画面のボリュームが多いときはスクローリングにより一覧画面としてもよい。

さらに主体は複数存在するのが通例である。

本願発明は大型のプロジェクト、建設工事、商品、役務の販売代理、代理決済、その他異なる役割を受けもつ複数の主体が協働して仕事をするシステムに広く適用することが出来る。

本願発明による業務進捗状況管理システムの一実施例を示すシステム構成図である。 本願発明による業務進捗状況管理システムのフローチャートである。 本願発明による業務進捗状況管理システムのフローチャートである。 本願発明による業務進捗状況管理システムの一実施例を示す一覧画面の図である。 図４の実施例のＳ１の「新規入力」画面を示す。 図４の実施例のＳ２の「プルーフチェック」画面を示す。 図４の実施例のＳ２の「プルーフチェック」画面を示す。 図４の実施例のＳ３の「審査結果入力」画面を示す。 図４の実施例のＳ４の「審査結果確認」画面を示す。 図４の実施例のＳ５の「申込内容承認」画面を示す。 図４の実施例のＳ６の「データエントリー」画面を示す。 図４の実施例のＳ７の「出荷」画面を示す。 図４の実施例のＳ８の「着荷確認完了」画面を示す。 図４の実施例のＳ９の「着荷完了報告」画面を示す。 図４の実施例のＳ１０の「契約締結」画面を示す。 図４の実施例のＳ１１の「開始確認」画面を示す。 本願発明による業務進捗状況管理システムの他の実施例を示す一覧画面の図である。 本願発明による業務進捗状況管理システムのさらに他の実施例を示す一覧画面の図である。

符号の説明

１ サーバ会社
２ 一般顧客
３ 販売会社
５ 保証会社
７ 物流会社
９ サービス提供会社
１０ インターネット
１１ サーバコンピュータ
１１Ａ ウェブサーバ
１１Ｂ ファイアウォール
１１Ｃ データベースサーバ
１１Ｄ ファクシミリサーバ
１１Ｅ 決済系サーバ
１１ｎ データ送受信部
１１ｍ 業務フロー管理モジュール

Claims (7)

1. サーバコンピュータと複数の主体の端末とが通信ネットワークを介して接続される仕事管理システムにおいて、上記サーバコンピュータは、異なる役割を受けもつ複数の主体の作業ステップを管理する手段と、一の主体の端末がサーバコンピュータに接続された場合当該主体の端末画面上に業務全体の流れ図を表示するとともに、自己の業務分担部分と他者の業務分担部分とを識別可能に表示する手段とを備え、上記流れ図は所定のステップをボックスとして表示するとともに各ボックスを矢印にて連結してなる骨格を有し、該流れ図の骨格がいずれの主体にも同一画面として表示されることを特徴とする業務進捗状況管理システム。
2. 請求項１記載の業務進捗状況管理システムにおいて、上記流れ図のボックスに主体の業務分担部分の残処理件数の表示があることを特徴とする業務進捗状況管理システム。
3. 請求項１記載の業務進捗状況管理システムにおいて、上記流れ図のボックスが進行順に表示されることを特徴とする業務進捗状況管理システム。
4. 請求項１記載の業務進捗状況管理システムにおいて、上記流れ図は一覧画面にて表示されることを特徴とする業務進捗状況管理システム。
5. 請求項１記載の業務進捗状況管理システムにおいて、自己の業務分担部分の識別は色分けにてなされることを特徴とする業務進捗状況管理システム。
6. 請求項１記載の業務進捗状況管理システムにおいて、自己の業務分担部分の識別は点滅にてなされることを特徴とする業務進捗状況管理システム。
7. 請求項４記載の業務進捗状況管理システムにおいて、上記一覧画面がスクローリングにより得られることを特徴とする業務進捗状況管理システム。

Images