JP2007272425A - 作業状況管理支援システム、作業状況管理支援方法、及びプログラム - Google Patents

Abstract

【課題】管理担当者が作業担当者の作業状況をその作業状況を引き起こした原因(休暇中、退勤済等)も含めてリアルタイムで把握できるようにする。
【解決手段】サーバ１０と、本部担当者端末２０と、店舗担当者端末３０と、承認担当者端末４０とを備える。サーバ１０は、店舗担当者のスケジュール情報及び作業状況に関する情報を管理するデータベース１１と、データベース１１の更新/検索等を行うＤＢＭＳ１２と、更新/検索等の要求を受信して結果を送信する通信部１３とを備える。本部担当者端末２０は、スケジュール画面と作業状況画面とを切り替え可能に表示する表示部２１と、これらを含む各種画面からの入力情報を受け付ける入力部２２と、入力情報に基づいて操作言語を生成する操作言語生成部２３と、操作言語をサーバ１０へ送信して結果を受信する通信部２４と、その結果を取得する結果取得部２５とを備え、店舗担当者端末３０も同様の構成を有する。
【選択図】図１

Description

本発明は、管理担当者が作業担当者の作業状況を管理する際に用いられる作業状況管理支援システム等に関する。

商品を製造したり販売したりする企業等においても、また、何らかのサービスを提供する企業等においても、その企業等の営業員が契約先を巡回して商品やサービスを紹介したり受注したりすることは、従来から広く行われている。
近年、情報通信技術の発達により、企業等がこのような営業員の行動を把握する場合にもコンピュータシステムが用いられるようになっている。特に、医療品の分野では、製薬会社が医薬品を卸す卸会社の医薬品卸販売担当者(ＭＳ)を、その卸会社のマスタ端末から管理するシステムが提案されている(例えば、特許文献１参照)。

特開２００３−２６３５９７号公報(第１９−２１頁、第２３−２７図)

しかしながら、特許文献１では、マスタ端末からＭＳに対し、営業、セミナー等の案内や、新薬等の情報の提供を行っているだけであり、ＭＳの行動の詳細についてまでは管理できていない。特に、特許文献１では、ＭＳのスケジュール管理等は行っていないため、ＭＳが提供された情報に従って行動していないとしても、その原因(休暇中なのか、退勤済なのか等)を特定することはできないという問題点があった。

本発明は、以上のような技術的課題を解決するためになされたものであって、その目的は、管理担当者が作業担当者の作業状況をその作業状況を引き起こした原因(休暇中、退勤済等)も含めてリアルタイムで把握できるようにすることにある。

かかる目的のもと、本発明は、作業担当者のスケジュールを表示する画面と、作業担当者の作業状況を表示する画面とを併用して、管理担当者が作業担当者を管理できるようにした。即ち、本発明の作業状況管理支援システムは、作業担当者のスケジュールに関する第１の情報を記憶する第１の記憶手段と、管理担当者が発行した作業指示書に基づく作業担当者の作業状況に関する第２の情報を記憶する第２の記憶手段と、第１の記憶手段に記憶された第１の情報に基づく表示を指示するための領域と、第２の記憶手段に記憶された第２の情報に基づく表示を指示するための領域とを含む画面を表示する表示手段とを備えている。

ここで、第２の情報としては、作業担当者による作業指示書の閲覧の有無及び日付を含むものが考えられる。この場合、作業指示書に関するコメントの入力に応じて、作業担当者による作業指示書の閲覧の有無を、閲覧が無い旨の情報に更新する更新手段を更に備えてもよい。
また、第２の情報としては、作業担当者による作業指示書に対する報告を含むものも考えられる。この場合、特定の作業を行った旨の文章を、その特定の作業について表示されたチェックボックスに対する作業担当者のチェック操作を認識することにより自動作成する入力支援手段と、自動作成された文章を、作業担当者による作業指示書に対する報告として登録する登録手段とを更に備えてもよい。

更に、本発明は、管理担当者による作業担当者の作業状況の管理を支援する方法として捉えることもできる。その場合、本発明の作業状況管理支援方法は、コンピュータが、第１の領域と第２の領域とを含む画面を表示するステップと、コンピュータが、第１の領域における操作に応じて、作業担当者のスケジュールに関する第１の情報を記憶する第１の記憶手段から第１の情報を読み出すステップと、コンピュータが、第１の情報に基づいて作業担当者のスケジュールを表示するステップと、コンピュータが、第２の領域における操作に応じて、作業担当者の作業状況に関する第２の情報を記憶する第２の記憶手段から第２の情報を読み出すステップと、コンピュータが、第２の情報に基づいて作業担当者の作業状況を表示するステップとを含んでいる。

一方、本発明は、所定の機能をコンピュータに実現させるコンピュータプログラムとして捉えることもできる。その場合、本発明のプログラムは、コンピュータに、作業担当者のスケジュールに関する第１の情報を記憶する第１の記憶手段から第１の情報を読み出す機能と、管理担当者が発行した作業指示書に基づく作業担当者の作業状況に関する第２の情報を記憶する第２の記憶手段から第２の情報を読み出す機能と、第１の記憶手段から読み出された第１の情報に基づく表示を指示するための領域と、第２の記憶手段から読み出された第２の情報に基づく表示を指示するための領域とを含む画面を表示する機能とを実現させるものである。

本発明によれば、管理担当者が作業担当者の作業状況をその作業状況を引き起こした原因(休暇中、退勤済等)も含めてリアルタイムで把握できるようになる。

以下、添付図面を参照して、本発明を実施するための最良の形態(以下、「実施の形態」という)について詳細に説明する。但し、本発明は以下の説明に限定されるものではなく、その要旨の範囲内において種々に変更して実施することができる。
尚、本実施の形態では、作業担当者として、契約先である家電量販店を巡回して商品の受注や納品等を行う担当者(以下、「店舗担当者」という)を例示し、管理担当者として、この店舗担当者を管理する本部の統括部門の担当者(以下、「本部担当者」という)を例示する。また、本実施の形態においては、本部担当者のうち、本部近辺の店舗についての店舗担当者ともなる担当者(以下、「店舗担当本部担当者」という)もいる。店舗担当本部担当者は、店舗担当者を管理する際には管理担当者となるが、契約先の家電量販店を巡回する際には作業担当者となる。そして、本実施の形態においては、商品としてＣＤ−Ｒ、ＣＤ−ＲＷ、追記型ＤＶＤ、書き換え型ＤＶＤを一例として用いている。

図１は、本実施の形態におけるコンピュータシステムの一例を示した図である。
図示するように、このコンピュータシステムは、サーバコンピュータ(以下、「サーバ」という)１０と、本部担当者端末２０と、店舗担当者端末３０と、承認担当者端末４０とが、ネットワーク９０を介して接続されることにより構成されている。このコンピュータシステムは、本部担当者が店舗担当者に対して作業を指示したり、その指示に対する報告を受けたりする業務システムを実現するのに好適である。

サーバ１０は、このコンピュータシステムで用いられる情報を管理するコンピュータである。即ち、まず、本部担当者や店舗担当者のスケジュールに関する情報、作業指示やその作業指示に対する報告に関する情報等を記憶するデータベース１１を備えている。また、サーバ１０は、データベース１１に対し更新/検索等の処理を行うＤＢＭＳ(Database Management System)１２と、各端末装置から更新/検索の要求を受信し、ＤＢＭＳ１２による処理の結果を各端末装置に返す通信部１３とを備えている。尚、サーバ１０のハードウェア構成は、一般的なサーバコンピュータと同様、ＣＰＵ、主記憶装置、補助記憶装置、通信インタフェース等を有するものであればよい。

本部担当者端末２０は、本部担当者が、店舗担当者に作業を指示したりその指示に対する報告を受けたりする際に使用する端末装置である。また、本部担当者の中には、本部近辺の店舗についての店舗担当者ともなる担当者(店舗担当本部担当者)もいる。従って、本部担当者端末２０は、本部担当者が、作業指示を受けたりその指示に対する報告を行ったりする際にも使用され得る。
ここで、本部担当者端末２０は、表示部２１と、入力部２２と、操作言語生成部２３と、通信部２４と、結果取得部２５とを備えている。このうち、表示部２１は、ディスプレイに各種画面を表示するための処理及びその表示を行い、入力部２２は、この各種画面からの入力情報を受け付ける。また、操作言語生成部２３は、入力部２２が受け付けた入力情報に基づいて、サーバ１０が保持するデータベース１１に対し更新/検索等を依頼する操作言語(例えば、ＳＱＬ)を生成する。更に、通信部２４は、操作言語生成部２３が生成した操作言語をサーバ１０に送信してサーバ１０から処理の結果を受信し、結果取得部２５は、通信部２４がサーバ１０から受信した結果を取得する。
尚、本部担当者端末２０としては、ＰＣ(Personal Computer)が例示される。

店舗担当者端末３０は、店舗担当者が、本部担当者から作業指示を受けたりその指示に対する報告を行ったりする際に使用する端末装置である。
ここで、店舗担当者端末３０は、表示部３１と、入力部３２と、操作言語生成部３３と、通信部３４と、結果取得部３５とを備えている。但し、これらの機能は、本部担当者端末２０における対応する機能と同様であるので説明を省略する。
尚、店舗担当者端末３０としては、店舗担当者が店舗を巡回する際に持ち運ぶことが前提となることから、ＰＤＡ(Personal Digital Assistants)が例示される。
一方、承認担当者端末４０は、特に、費用に関する承認を行うグループリーダ、部長等の端末装置である。尚、承認担当者端末４０としては、ＰＣ(Personal Computer)が例示される。

ところで、本実施の形態におけるコンピュータシステムは、まず、本部担当者による店舗担当者のスケジュールの把握を支援する機能を有する。また、本部担当者による店舗担当者への作業指示、その作業指示の閲覧状況の把握、その作業指示に対する報告状況の把握を支援する機能も有する。そして、スケジュールの把握と、作業指示に対する状況の把握との両方を、画面を切り替えることにより容易に行えるようにする。更に、本実施の形態におけるコンピュータシステムは、販売促進等に関して発生した費用を円滑に承認できるようにする機能も有する。
そこで、以下では、本実施の形態におけるコンピュータシステムについて、これらの機能ごとに順を追って説明する。

(１) 各担当者のスケジュールの登録
まず、本部担当者又は店舗担当者は、当日のスケジュールを登録する。即ち、本部担当者は本部担当者端末２０を用いて、店舗担当者は店舗担当者端末３０を用いて、当日最初にサーバ１０にアクセスする際に、現在の出勤状態(現在状況)を入力する。或いは、外出する際や、退勤する際にも、サーバ１０にアクセスし、その旨を現在状況として入力することもできる。例えば、次の日に休暇をとることが分かっている人は、退勤時にその旨入力することができる。

次に、本部担当者が当日初めてシステムを起動した場合の動作について説明する。
図２は、この場合の本部担当者端末２０の画面例を示した図である。
本実施の形態において、本部担当者端末２０は、業務システムを起動する際に、自身が、ＬＡＮに接続されているか、ＰＨＳ通信中であるか、スタンドアロン(サーバ１０に接続されていない状態)であるかを自動的に判別する。そして、ＬＡＮ接続又はＰＨＳ通信中である場合は、現在登録されている状態を判断し、不明又は不適切であれば現在状況の変更を強制する。即ち、図示するように、「外出中」、「出張中」、「社内」、「退勤済」、「会議中」のボタンが有する状態変更画面を表示する。そこで、本部担当者は、この中からボタンを選択して押下することにより、自己の状態を登録し直す。

例えば、図２では、担当者「Ｙ．Ｔ」がＬＡＮに接続されたＰＣから業務システムを起動した場合を想定している。ＬＡＮ接続であるということは、社内のどこかにいるはずである。しかしながら、「本日のスケジュール」欄２０１において、担当者「Ｙ．Ｔ」の状態が「外出中」になっているため、適切な状態に修正するよう促しているのである。
尚、本部担当者のうち、店舗担当者としての役割も有する店舗担当本部担当者は、フリーデスク(空いている座席を自由に選んで座れる)の場合がある。そのため、本実施の形態では、状態変更画面において「社内」ボタンを押下すると、右側に数字の書かれた小窓を表示するようにしている。つまり、この数字は、座席の内線番号であり、フリーデスクの本部担当者が現在座っている座席の内線番号を選択できるようにしているのである。
一方、本部担当者のうち固定机を持っている社員は、データベース１１に内線番号が登録されているため、状態変更画面で「社内」ボタンを押下するだけで入力は終了する。

また、会議を行う場合には、在室している会議室を選択できるようにしてもよい。その場合、「社内」ボタンを押下したときと同様、「会議中」ボタンを押下したときに会議室を選択するための小窓を表示する。尚、この小窓に実際のフロアレイアウトを模した表示を行って会議室を選択させれば、会議室を部屋番号ではなく場所をイメージしながら選択できる点で便利である。

尚、図２には、本部担当者端末２０の画面例を示したが、店舗担当者端末３０においても同様に、状態変更を強制する機能は実現可能である。但し、店舗担当者端末３０の画面は、表示できる内容が本部担当者端末２０の画面ほど多くないので、表示内容は限られる。例えば、現在の状況(「出勤中」等)と、変更後の状況の選択肢(「退勤する」等)とを表示する程度である。また、選択可能な現在状況は、本部担当者と店舗担当者とで異なる。即ち、本部担当者の場合、現在状況は、「社内」、「会議中」、「外出中」、「出張中」、「退勤済」のいずれかである。一方、店舗担当者の場合、現在状況は、「出勤中」、「退勤済」、「休暇」のいずれかであり、「社内」、「会議中」の項目はない。店舗担当者は、直行直帰のため、社内に机を持っていないからである。
本実施の形態においては、店舗担当者が登録するスケジュール及び店舗担当本部担当者が店舗担当者として登録するスケジュールが、「作業担当者のスケジュールに関する第１の情報」となっている。

ここで、本部担当者に出勤状態の変更を促す際のコンピュータシステムの動作について詳細に説明する。
図３は、この動作を行う際に必要となるデータベース１１内のデータを示したものである。
このうち、従業員マスタ１１ａは、本実施の形態のコンピュータシステムが導入された企業等の従業員に関する各種情報を管理するマスタファイルである。「ＩＤ」は、このマスタファイルにおけるキー項目であり、各従業員を一意に識別する識別情報である。「氏名」は、各従業員の姓名であり、「部署ＩＤ」は、各従業員が所属する部署の識別情報である。また、「座席内線番号」は、各従業員の座席の内線番号であるが、フリーデスクの従業員の場合にはこの項目は「ｎｕｌｌ」になっている。

部署マスタ１１ｂは、本実施の形態のコンピュータシステムが導入された企業等の部署に関する各種情報を管理するマスタファイルである。「ＩＤ」は、このマスタファイルにおけるキー項目であり、各部署を一意に識別する識別情報である。「部署名」は、各部署の名前である。例えば、企画部、開発部といった部署の名前が登録される。また、「部署内線番号」は、各部署の内線番号である。

スケジュールマスタ１１ｅは、従業員ごと、日付ごとのスケジュールを管理するマスタファイルである。「ＩＤ」は、このマスタファイルにおけるキー項目であり、スケジュール情報を一意に識別する識別情報である。「従業員ＩＤ」は、そのスケジュール情報を有する従業員の識別情報であり、「日付」は、そのスケジュール情報が何年何月何日のものであるかを示す情報である。また、「スケジュール内容」は、スケジュールの具体的な内容を示す。このスケジュールの具体的な内容としては、午前のスケジュール、午後のスケジュール、帰社予定等の詳細な項目が考えられるが、これらは「スケジュール内容」として一括管理してもよいし、別々の項目で自管理してもよい。一方、「現在状況ＩＤ」は、スケジュールの内容に対応する現在状況を識別する識別情報である。

現在状況マスタ１１ｆは、スケジュールの内容の分類である現在状況を管理するマスタファイルである。「ＩＤ」は、このマスタファイルにおけるキー項目であり、現在状況を一意に識別する識別情報である。「現在状況内容」は、現在状況の具体的な内容である。即ち、「現在状況内容」には、「社内」、「会議中」、「外出中」、「出張中」、「退勤済」等の状態が登録され、これらの各状態が「ＩＤ」によって管理されている。
尚、これらのマスタファイルは、あるマスタファイルにおけるキー項目が他のマスタファイルにおける所定の項目と連結することにより、１つの大きな結合ファイルを構成している。即ち、図示するように、従業員マスタ１１ａの「ＩＤ」がスケジュールマスタ１１ｅの「従業員ＩＤ」と連結しており、現在状況マスタ１１ｆの「ＩＤ」がスケジュールマスタ１１ｅの「現在状況ＩＤ」と連結しており、部署マスタ１１ｂの「ＩＤ」が従業員マスタ１１ａの「部署ＩＤ」と連結している。

また、図４は、本部担当者に出勤状態の変更を促す際の本部担当者端末２０の動作を示したフローチャートである。
まず、ユーザがユーザＩＤを入力すると、入力部２２がこれを受け付ける(ステップ２１１)。次に、操作言語生成部２３が、図３の結合ファイルから、従業員マスタ１１ａの「ＩＤ」がここで入力されたユーザＩＤであり、スケジュールマスタ１１ｅの「日付」が本日日付であるレコードを抽出するための操作言語を生成する。そして、通信部２４が、この操作言語をサーバ１０へ送信する(ステップ２１２)。
すると、サーバ１０では、ＤＢＭＳ１２が、操作言語で指定されたレコードを抽出し、通信部１３が、抽出結果を本部担当者端末２０に送る。
これにより、本部担当者端末２０では、通信部２４が抽出結果を受け取り、結果取得部２５に受け渡す。

次に、表示部２１は、抽出したレコード内の現在状況内容と、本部担当者端末２０にて予め識別しておいたＬＡＮかモバイルかスタンドアロンかの状態と照合し、これらが整合しているかどうか判定する(ステップ２１３)。
ここで、整合していれば処理を終了し、整合していなければ、表示部２１が、状態変更画面を表示する(ステップ２１４)。或いは、抽出したレコード内の現在状況内容が「不明」の場合にも、状態変更画面を表示してもよい。これに応じて、ユーザが状態を選択すると、入力部２２がこの選択情報を受け付ける(ステップ２１５)。そして、入力部２２は、入力された情報が「社内」か「会議中」かそれ以外かを判定する(ステップ２１６)。

その結果、「社内」、「会議中」以外であると判定された場合は、入力された情報をそのままデータベース１１に登録する(ステップ２２１)。
一方、「社内」であると判定された場合は、ステップ２１２で抽出したレコード内の座席内線番号が「ｎｕｌｌ」であるかどうかを判定する(ステップ２１７)。ここで、座席内線番号が「ｎｕｌｌ」であれば、図２に示したような内線番号を記載した小窓を表示する(ステップ２１８)。そして、ユーザが、この中から内線番号を選択すると、入力部２２は、その内線番号を受け付け(ステップ２２０)、データベース１１に登録する(ステップ２２１)。
また、「会議中」であると判定された場合は、会議室のレイアウトを記載した小窓を表示する(ステップ２１９)。そして、ユーザが、この中から会議室の番号を選択すると、入力部２２は、その会議室番号を受け付け(ステップ２２０)、データベース１１に登録する(ステップ２２１)。

ここで、ステップ２２１でのデータベース１１への登録は、次のようにして行う。
即ち、操作言語生成部２３が、ステップ２１２で抽出したレコード内の「現在状況ＩＤ」に対し、入力された現在状況のＩＤを設定した新たなレコードを作成し、ステップ２１２で抽出されたレコードをこの新たなレコードで上書きするための操作言語を生成する。ここで、「現在状況ＩＤ」としては、フリーデスクの場合の座席内線を設定してもよい。そして、通信部２４が、この操作言語をサーバ１０へ送信する。
すると、サーバ１０では、ＤＢＭＳ１２が、操作言語で指定されたレコードで上書きする。

尚、ここでは本部担当者端末２０からサーバ１０へのスケジュールの登録について述べたが、店舗担当者端末３０からサーバ１０へのスケジュールの登録もほぼ同様の処理で行われる。但し、上述したように、店舗担当者の出勤状態として「社内」、「会議中」はあり得ないので、ステップ２１６での判定は全て、「『社内』、『会議中』以外」となるので、ステップ２１７〜２２０は実行されない。
本実施の形態においては、店舗担当者及び店舗担当本部担当者のスケジュールが登録されたサーバ１０内のデータベース１１の所定の領域が「第１の記憶手段」となっている。

(２) 各担当者のスケジュールの参照
このように本部担当者又は店舗担当者の現在状況がサーバ１０に登録されると、各担当者は、サーバ１０にアクセスすることで、他の担当者のスケジュールを参照できるようになる。即ち、各担当者は、他の担当者の現在の状態(居場所、連絡先)を知ることができる。尚、行き先が不明の担当者(事前に休暇を登録しておらず、かつ、当日サーバ１０にアクセスしていない担当者)については、「不明」と表示される。

次に、本部担当者がスケジュールを参照する場合の動作について説明する。
図５は、この場合の本部担当者端末２０の画面例を示した図である。この画面は、メインメニュー画面における左側のメニューリストの中から「スケジュール参照(１日単位)」を選択することにより表示される。「本日のスケジュール」欄２０１において、担当者「Ｍ．Ｎ」の状態は「不明」であり、担当者「Ｋ．Ｍ」の状態は「出張中」である。また、その他の担当者の状態としては、数字が示してあるが、これらは座席内線番号を示す。いずれも状態の区分で言えば「社内」である。更に、ここでは図示していないが、状態としては、この他に「外出中」、「退勤済」(「出勤前」)等もある。

ここで、本部担当者が同じ部署の他の担当者のスケジュールを参照する際のコンピュータシステムの動作について詳細に説明する。尚、この動作においても、図３の結合ファイルを用いる。
図６は、このときの本部担当者端末２０の動作を示したフローチャートである。
まず、ユーザがメインメニューから「スケジュール参照(１日単位)」を選択すると、入力部２２がこの選択情報を受け付ける(ステップ２３１)。次に、操作言語生成部２３が、図３の結合ファイルから、従業員マスタ１１ａの「ＩＤ」がシステム起動時に入力されたユーザＩＤであるレコードを抽出するための操作言語を生成する。また、図３の結合ファイルから、従業員マスタ１１ａの「部署ＩＤ」がこの操作言語により抽出されるレコード内の部署ＩＤであり、スケジュールマスタ１１ｅの「日付」が本日日付であるレコードを抽出するための操作言語を生成する。そして、通信部２４が、この操作言語をサーバ１０へ送信する(ステップ２３２)。
すると、サーバ１０では、ＤＢＭＳ１２が、操作言語で指定されたレコードを抽出し、通信部１３が、抽出結果を本部担当者端末２０に送る。
これにより、本部担当者端末２０では、通信部２４が抽出結果を受け取り、結果取得部２５に受け渡す。

次に、表示部２１は、抽出されたレコードのうちの１つ(具体的には、システムを起動したユーザと同じ部署の特定のユーザのスケジュールを含むレコード)に着目し(ステップ２３３)、そのレコードにおける現在状況ＩＤが「ｎｕｌｌ」であるかどうかを判定する(ステップ２３４)。
その結果、現在状況ＩＤが「ｎｕｌｌ」でないと判定された場合は、そのレコードをメモリに格納する(ステップ２３５)。
一方、現在状況ＩＤが「ｎｕｌｌ」であると判定された場合は、現在状況を「不明」とした上でそのレコードをメモリに格納する(ステップ２３６)。
その後、表示部２１は、まだレコードがあるかどうか判定し(ステップ２３７)、レコードがあれば、ステップ２３３に戻る。そして、ステップ２３３〜２３６の処理を繰り返し、レコードがなくなれば、メモリに格納されたレコードに基づいて、表示部２１に画面を表示する(ステップ２３８)。
本実施の形態においては、上記表示された画面が、「第１の記憶手段に記憶された第１の情報に基づく表示」となる。また、上記表示に切りかえるために用いられる、メインメニュー画面における左側のメニューリストの中の「スケジュール参照(１日単位)」が、「第１の情報に基づく表示を指示するための領域」となっている。

(３) 各担当者への作業指示書の発行
また、本部担当者は、本部担当者端末２０から、作業指示書(店舗担当者への作業の指示)を起票する。尚、ここでの作業とは、例えば、店舗への商品の紹介や受注、納品等、種々のものが含まれる。
図７は、作業指示書(以下、単に「指示書」ともいう)を起票する際に用いられる画面例(指示書新規入力画面)を示した図である。この画面は、図５のメインメニュー画面における左側のメニューリストの中から「新規指示書入力」を選択することにより表示される。
ここで、本部担当者は、システム側で保持する指示ＩＤ、発行日、発行者(起票者)に加え、図示するように、契約先、有効期限、タイトル、タイミング(行動を起こすタイミング)、対象店舗(契約先が有する店舗のうち実際に作業を行う店舗)、及び本文(実際の指示の内容)を入力する。

また、図では、タイミング、対象店舗、本文からなる明細として、２個の枠が設けられている。即ち、入力中の明細は左側に表示されるが、入力が終了した明細は、「確定」ボタン２０２を押下することにより、右側に移動するようになっている。但し、枠の数は、必ずしも２個に限るものではなく、これより多くの枠を設けるようにしてもよい。例えば、１６個の枠を設けることにより、一件の作業指示書に１６件の明細を含めるようにすることもできる。例えば、１つの契約先に関し１つのタイトルで作業指示書を発行する場合であっても、店舗ごとに異なる指示を行うことがある。このような場合に、一件の作業指示書に複数の明細を含めることで、作業指示書のリストに同じタイトルの行が幾つも表示されることを防ぐことができる。

ここで、本部担当者が作業指示書を発行する際のコンピュータシステムの動作について詳細に説明する。
図８は、この動作を行う際に必要となるデータベース１１内のデータを示したものである。
このうち、契約先マスタ１１ｃは、本実施の形態のコンピュータシステムが導入された企業等の契約先(例えば、家電量販店)に関する各種情報を管理するマスタファイルである。「ＩＤ」は、このマスタファイルにおけるキー項目であり、各契約先を一意に識別する識別情報である。「契約先名」は、各契約先である家電量販店等の会社名等である。
店舗マスタ１１ｄは、契約先が有する店舗に関する各種情報を管理するマスタファイルである。「ＩＤ」は、このマスタファイルにおけるキー項目であり、各店舗を一意に識別する識別情報である。「契約先ＩＤ」は、各店舗が所属する契約先の識別情報である。また、「店舗名」は、各店舗の名称であり、「巡回担当者ＩＤ」は、各店舗の巡回を担当する店舗担当者の識別情報である。

指示書マスタ１１ｇは、本部担当者が発行した作業指示書に関する各種情報を管理するマスタファイルである。「ＩＤ」は、このマスタファイルにおけるキー項目であり、各作業指示書を一意に識別する識別情報である。「記入者ＩＤ」は、各作業指示書を発行(記入)した担当者の識別情報であり、「契約先ＩＤ」は、各作業指示書によって指示される作業が実際に行われる契約先の識別情報である。
指示書明細マスタ１１ｈは、本部担当者が発行した作業指示書の明細に関する各種情報を管理するマスタファイルである。「ＩＤ」は、このマスタファイルにおけるキー項目であり、各明細を一意に識別する識別情報である。「指示書ＩＤ」は、各明細が属する作業指示書の識別情報であり、「指示内容」は、各明細によって指示されている作業内容である。

指示書コメントマスタ１１ｉは、作業指示書に対して入力されたコメント(以下、「指示書コメント」という)に関する各種情報を管理するマスタファイルである。「ＩＤ」は、このマスタファイルにおけるキー項目であり、各指示書コメントを一意に識別する識別情報である。「指示書ＩＤ」は、各指示書コメントの対象となる作業指示書の識別情報である。また、「記入者ＩＤ」は、各指示書コメントを記入した担当者の識別情報であり、「内容」は、各指示書コメントの内容である。

指示書未読既読マスタ１１ｊは、作業指示書ごと、ユーザごとに、そのユーザがその作業指示書を読んでいるかどうかを管理するマスタファイルである。「ＩＤ」は、このマスタファイルにおけるキー項目であり、未読既読情報を一意に識別する識別情報である。「ユーザＩＤ」は、その未読既読情報の対象となるユーザの識別情報であり、「指示書ＩＤ」は、その未読既読情報の対象となる作業指示書の識別情報である。また、「未読既読フラグ」は、ユーザが作業指示書を読んだかどうかを示すフラグである。このフラグは、例えば、初期値を「０」とし、対応するユーザが作業指示書を読むことにより「１」に設定するようにすればよい。更に、「閲覧日付」は、ユーザが作業指示書を読んだ日付であり、「担当店舗数」は、対応するユーザが担当する店舗の数である。

一方、従業員マスタ１１ａは、図３に示したものと同様なので詳細な説明は省略する。但し、(１)及び(２)の動作では不要なため図示しなかったが、従業員マスタ１１ａは、指示発行フラグを有している。この指示発行フラグは、各従業員が作業指示書による作業指示の対象となり得るかどうかを示すフラグである。例えば、作業指示書による指示の対象とならない従業員の場合は「０」とし、作業指示書による指示の対象となる従業員の場合は「１」とすればよい。

尚、これらのマスタファイルは、あるマスタファイルにおけるキー項目が他のマスタファイルにおける所定の項目と連結することにより、１つの大きな結合ファイルを構成している。即ち、図示するように、指示書マスタ１１ｇの「ＩＤ」が、指示書明細マスタ１１ｈの「指示書ＩＤ」、指示書コメントマスタ１１ｉの「指示書ＩＤ」、指示書未読既読マスタ１１ｊ「指示書ＩＤ」と連結している。また、契約先マスタ１１ｃの「ＩＤ」が、指示書マスタ１１ｇの「契約先ＩＤ」、店舗マスタ１１ｄの「契約先ＩＤ」と連結している。更に、従業員マスタ１１ａの「ＩＤ」が、店舗マスタ１１ｄの「巡回担当者ＩＤ」と連結している。更にまた、作図の都合上図示していないが、従業員マスタ１１ａの「ＩＤ」は、指示書マスタ１１ｇの「記入者ＩＤ」、指示書コメントマスタ１１ｉの「記入者ＩＤ」、指示書未読既読マスタ１１ｊの「ユーザＩＤ」とも連結している。

また、図９は、本部担当者が作業指示書を発行する際の本部担当者端末２０の動作を示したフローチャートである。
まず、本部担当者が、指示書新規入力画面から作業指示書の情報を入力すると、入力部２２がこれを受け付ける(ステップ２４１)。次に、操作言語生成部２３が、指示書マスタ１１ｇに対し、「記入者ＩＤ」をシステム起動時に入力されたユーザＩＤとし、「契約先ＩＤ」をここで入力された契約先のＩＤとするレコードを追加するための操作言語を生成する。また、指示書明細マスタ１１ｈに対し、「指示書ＩＤ」を指示書マスタ１１ｇにおけるこの追加されたレコードの「ＩＤ」とし、「指示内容」をここで入力されたタイミング、対象店舗、本文とするレコードを追加するための操作言語を生成する。そして、通信部２４が、これらの操作言語をサーバ１０へ送信する(ステップ２４２)。
すると、サーバ１０では、ＤＢＭＳ１２が、操作言語で指定されたレコードを追加する。

次に、操作言語生成部２３は、図８の結合ファイルから、従業員マスタ１１ａの「指示発行フラグ」が立っている(例えば「１」になっている)レコードを抽出するための操作言語を生成する。そして、通信部２４が、この操作言語をサーバ１０へ送信する(ステップ２４３)。
すると、サーバ１０では、ＤＢＭＳ１２が、操作言語で指定されたレコードを抽出し、通信部１３が、抽出結果を本部担当者端末２０に送る。
これにより、本部担当者端末２０では、通信部２４が抽出結果を受け取り、結果取得部２５に受け渡す。

また、操作言語生成部２３は、抽出された１つのレコードに着目し、そのレコードにおける従業員を特定する(ステップ２４４)。次に、図８の結合ファイルから、店舗マスタ１１ｄの「巡回担当者ＩＤ」がこの特定した従業員であるレコードを抽出するための操作言語を生成する。そして、通信部２４が、この操作言語をサーバ１０へ送信する(ステップ２４５)。
すると、サーバ１０では、ＤＢＭＳ１２が、操作言語で指定されたレコードを抽出し、通信部１３が、抽出結果を本部担当者端末２０に送る。
これにより、本部担当者端末２０では、通信部２４が抽出結果を受け取り、結果取得部２５に受け渡す。そして、結果取得部２５は、抽出されたレコードの件数を数えることにより、着目する従業員が巡回担当者となっている店舗の数を知ることができる。

その後、操作言語生成部２３は、指示書未読既読マスタ１１ｊに対し、「ユーザＩＤ」を着目しているレコード内の「従業員ＩＤ」とし、「指示書ＩＤ」を作業指示書のＩＤとし、未読既読フラグ及び閲覧日付を初期値とし、担当店舗数をここで求めた店舗の数とするレコードを追加するための操作言語を生成する。そして、通信部２４が、この操作言語をサーバ１０へ送信する(ステップ２４６)。
すると、サーバ１０では、ＤＢＭＳ１２が、操作言語で指定されたレコードを追加する。

そして、操作言語生成部２３は、ステップ２４３で抽出されたレコードの中に未処理のレコードがあるかどうかを判定し(ステップ２４７)、未処理のレコードがあれば、ステップ２４４に戻る。そして、ステップ２４４〜２４６の処理を繰り返し、未処理のレコードがなくなれば、処理を終了する。

(４) 各担当者への作業指示書の参照
このようにサーバ１０に作業指示書が登録されると、各担当者は、サーバ１０にアクセスすることで、この作業指示書を参照することができるようになる。
図１０は、作業指示書を参照する際に用いられる画面例(指示参照画面)を示した図である。この画面は、図５のメインメニュー画面における左側のメニューリストの中から「過去の指示書を見る」を選択することにより表示される。
この指示参照画面には、まず、作業指示書の登録時に入力した内容が表示される。ここでは、担当者「Ｔ．Ｎ」が２００５年１１月４日に発行した「Ｋ電機」についての「［ＡＶ用］新商品の件」と題する作業指示書の例を示している。図示するように、この作業指示書の有効期限は２００５年１２月３１日であり、行動を起こすタイミングは「１１月５日」である。

また、指示参照画面は、「担当店舗のある人」欄２０３と「担当店舗のない人」欄２０４とを有しており、担当者のリストがこれらの欄に表示される。そして、「担当店舗のある人」欄２０３、「担当店舗のない人」欄２０４のリストに挙がった店舗担当者のうち、作業指示書の内容を確認した人(既読の人)については、閲覧日付が表示される。或いは、これと同時に、リスト上で表示色を変化させてもよい。これにより、作業指示書の内容を確認した人(既読の人)と、まだ作業指示書の内容を確認していない人(未読の人)とを一目で確認することができる。
本実施の形態においては、店舗担当者による作業指示書の未読・既読(閲覧)の有無及び閲覧日付を含む情報が、「管理担当者が発行した作業指示書に基づく作業担当者の作業状況に関する第２の情報」となっている。

更に、この指示参照画面では、「コメント記入」ボタン２０５をクリックすることにより、本部担当者が、作業指示書の内容についてのコメントを記入できるようになっている。ここで、コメントとは、例えば、作業指示書の内容に対する質問や情報である。
図１０では、
１) 「担当店舗のある人」欄２０３にリストアップされた担当者「Ｆ．Ｙ」が、２００５年１１月７日に、☆☆☆２の価格が２８８０円で間違いないかのコメントを入力
２) この作業指示書を起票した担当者「Ｔ．Ｎ」が、２００５年１１月９日に、２８８０円で間違いない旨のコメントを入力
３) 「担当店舗のある人」欄２０３にリストアップされた担当者「Ｓ．Ｈ」が、２００５年１１月９日に、価格は２５８０円で登録されている旨のコメントを入力
４) これを受けて、担当者「Ｔ．Ｎ」が、２００５年１１月９日に、価格を再確認してみる旨のコメントを入力
という流れでコメントが入力されている。

また、本実施の形態では、作業指示書を既に読んでいる人であっても、作業指示書に対するコメントがその後に追加されれば、その作業指示書の未読/既読状態は、「既読」から「未読」に変更されるようになっている。この場合、作業指示書を読んだ(閲覧した)最新の日付は表示されたままであるので、いつから未読であるかが分かる。即ち、「日付入り未読」の状態になる。
一方、最初から全く作業指示書を読んでいない人は、日付の入っていない「未読」の状態になっている。
このように、本実施の形態においては、作業指示書に関するコメントの入力に応じて、店舗担当者(作業担当者)による作業指示書の閲覧の有無を、閲覧が無い旨の情報に更新する更新手段が備えられることになる。この更新手段における具体的な処理については後述する。

例えば、図１０では、「担当店舗のある人」欄２０３にリストアップされた店舗担当者は、閲覧日が「Ｔ．Ｎ」からの最新のコメントが入力された日(１１/９)以降の閲覧日が表示されていることから、最新のコメントを含め、作業指示書に対する状態は「既読」となっている。一方、「担当店舗のない人」欄２０４にリストアップされた店舗担当者のうち、担当者「Ｈ．Ｎ」と担当者「Ｍ．Ｍ」は、この作業指示書を最初から全く読んでいない。一方、「担当店舗のない人」欄２０４にリストアップされた店舗担当者のうち、担当者「Ｇ．Ｄ」は、１１月７日までのコメント(担当者「Ｆ．Ｙ」のコメント)までは「既読」であるが、その後に追加されたコメントについては「未読」であることが分かる。

ここで、本部担当者が作業指示書を参照する際のコンピュータシステムの動作について詳細に説明する。尚、この動作においても、図８の結合ファイルを用いる。
図１１は、このときの本部担当者端末２０の動作を示したフローチャートである。
まず、ユーザが指示書ＩＤを入力すると、入力部２２がこれを受け付ける(ステップ２５１)。例えば、ユーザが図５のメインメニューから「過去の指示書を見る」を選択すると、作業指示書の抽出条件を設定する画面が表示され、そこで設定した条件に従って作業指示書のリストを表示する。そして、そのリストの中から詳細を閲覧したい作業指示書を選択することにすればよい。次に、操作言語生成部２３が、図８の結合ファイルから、指示書マスタ１１ｇの「ＩＤ」がこの入力された指示書ＩＤであるレコードを抽出するための操作言語を生成する。そして、通信部２４が、この操作言語をサーバ１０へ送信する(ステップ２５２)。
すると、サーバ１０では、ＤＢＭＳ１２が、操作言語で指定されたレコードを抽出し、通信部１３が、抽出結果を本部担当者端末２０に送る。
これにより、本部担当者端末２０では、通信部２４が抽出結果を受け取り、結果取得部２５に受け渡す。そして、結果取得部２５は、受け渡されたレコードをメモリに格納する。その際、指示書未読既読マスタ１１ｊの「担当店舗数」が１以上であるレコードと、「担当店舗数」が０であるレコードとは、分けて格納する。

次に、操作言語生成部２３が、ステップ２５２で抽出したレコードの中から、指示書未読既読マスタ１１ｊの「ユーザＩＤ」がこの作業指示書を参照している担当者の識別情報であるレコードを特定する。そして、この特定したレコード内の「未読既読フラグ」を「既読」とし、「閲覧日付」を本日日付とした新たなレコードを作成し、特定したレコードをこの新たなレコードで上書きするための操作言語を生成する。そして、通信部２４が、この操作言語をサーバ１０へ送信する(ステップ２５３)。
すると、サーバ１０では、ＤＢＭＳ１２が、操作言語で指定されたレコードで上書きする。これにより、この作業指示書を参照している本部担当者自身については、当該作業指示書を「既読」した状態となる。

次に、表示部２１は、ステップ２５２でメモリに格納した情報を、指示参照画面に反映させる(ステップ２５４)。
ここで、ユーザがコメントを記入し、「コメント記入」ボタン２０５を押下すると、入力部２２は、この操作情報を受け付ける(ステップ２５５)。次に、操作言語生成部２３が、指示書コメントマスタ１１ｉに対し、「指示書ＩＤ」を今参照している作業指示書の指示書ＩＤとし、「記入者ＩＤ」を今参照している担当者のＩＤとし、「内容」をここで記入された内容とするレコードを追加するための操作言語を生成する。そして、通信部２４が、この操作言語をサーバ１０へ送信する(ステップ２５６)。
すると、サーバ１０では、ＤＢＭＳ１２が、操作言語で指定されたレコードを追加する。

また、操作言語生成部２３が、ステップ２５２で抽出したレコードの中から、指示書未読既読マスタ１１ｊの「ユーザＩＤ」がこの作業指示書を参照している担当者以外のＩＤであるレコードを特定する。そして、この特定したレコード内の「未読既読フラグ」を「未読」とした新たなレコードを作成し、特定したレコードをこの新たなレコードで上書きするための操作言語を生成する。そして、通信部２４が、この操作言語をサーバ１０へ送信する(ステップ２５７)。つまり、コメントを登録した本人は、そのコメントを「未読」ということはあり得ないが、その他の担当者については、そのコメントを含めて考えると、作業指示書を「未読」ということになるからである。
すると、サーバ１０では、ＤＢＭＳ１２が、操作言語で指定されたレコードで上書きする。

尚、上記の説明では、本部担当者が作業指示書の内容についてコメントを記入する場合及び作業指示書を参照する場合について説明した。店舗担当者が店舗担当者端末３０から作業指示書の内容についてコメントを記入する場合及び作業指示書を参照する場合においても上記と同様の処理が行われる。
また、本実施の形態においては、店舗担当者の作業指示書の未読・既読(閲覧)の有無(上書き処理)の登録、作業指示書の閲覧日付の登録を行うサーバ１０内のデータベース１１の所定領域が「第２の記憶手段」となっている。そして、図１０に示す図面が「第２の記憶手段に記憶された第２の情報に基づく表示」となっている。そして、図１０に示す画面を表示させるために用いる、メインメニュー画面における左側のメニューリストの中の「過去の指示書を見る」が、「第２の情報に基づく表示を指示するための領域」となっている。また、本実施の形態においては、図２等に示すメインメニューが、「第１の情報に基づく表示を指示するための領域」と「第２の情報に基づく表示を指示するための領域」とを含む画面となっている。

(５) 作業指示書に対する報告の入力
更に、店舗担当者は、作業指示書で指示された作業が終わると、店舗担当者端末３０から日報をサーバ１０に入力する。また、本部担当者のうち本部近辺の店舗の店舗担当者ともなっている者(店舗担当本部担当者)は、作業指示書を発行しながら、自分もその作業指示書通りの作業を行う。このため、店舗担当本部担当者も、作業指示書で指示された作業が終わると、本部担当者端末２０から日報をサーバ１０に入力する。
本実施の形態においては、日報が「作業指示書に対する報告」となっており、この日報も「第２の情報」に含まれるものである。
尚、店舗担当者及び店舗担当本部担当者は、作業指示書で指示された作業のみでなく、各店舗への新製品の紹介、各店舗の売り場担当者とのミーティング等の各種作業を行う。

図１２は、店舗担当本部担当者が日報を入力する際に用いられる画面例(日報新規入力画面)を示した図である。この画面は、図５のメインメニュー画面における左側のメニューリストの中から「新しく日報を記入する」を選択することにより表示される。
まず、店舗担当本部担当者は、この日報新規入力画面上で、日付、滞店時間、契約先、店舗所在地、店舗名を選択する。

次に、店舗担当本部担当者は、活動内容にチェックする。
上述したように、店舗における作業は多岐にわたるので、日報として入力する内容も、作業指示書通りの作業を行った旨の報告以外に様々なものがある。即ち、商品紹介・受注、棚整理・品出し、販促物設置、ミーティング、搬入・改装(ＤＶＤ、ＣＤ売り場ブースの改装)・応援、価格調査・店舗調査、その他コメント(製品納入の際に得た担当店舗の情報やトラブル等の情報)等がある。
これらの項目のうち、「指示書記載事項の処理(指示書通りの作業を行った旨の報告)」、「商品紹介・受注」、「棚整理・品出し」、「販促物設置」、「ミーティング」、「搬入・改装・応援」、「価格調査・店舗調査」等の定型的な情報は、チェックボックスにチェックすることで入力することができるようになっている。

このとき、右側の「自動文章作成を有効にする」にチェックすると、上でチェックした活動内容が自動的に本文に反映される。
例えば、図１２の日報新規入力画面では、「商品紹介・受注」、「搬入・改装・応援」、「ＡＶ担当者」にチェックしているので、これらの内容が本文に反映されている。
尚、本文に直接カーソルを位置づけることにより、自由に文章を記入することも可能である。また、図示してはいないが、日報には、「自己評価欄」を設けてもよい。
本実施の形態においては、上記チェックボックスへ入力や「自動文章作成を有効にする」へのチェック等が、「特定の作業を行った旨の文章を当該特定の作業について表示されたチェックボックスに対する作業担当者のチェック操作を認識することにより自動作成する入力支援手段」となっている。

ところで、図１２の日報新規入力画面において、最下部の本文入力欄に入力された文章は、店舗担当者端末３０には表示されないようになっている。つまり、この欄は、本部担当者間のみで共有する情報を記載する部分である。例えば、未だ確定した情報でないため店舗に伝わると問題がある情報を本部担当者間で交換する場合に用いられる。
尚、店舗担当者端末３０については、本部担当者端末２０における表示内容と同じものを複数の画面に分けて表示するに過ぎないので、詳しい説明は省略する。但し、本部担当者間でのみ共有する情報は、店舗担当者端末３０には表示されない。

また、店舗担当者及び店舗担当本部担当者が、作業指示書に対する報告以外に報告すべき情報(例えば、自社製品の売れ行き情報や、店員に対するインタビュー情報)を入手した場合には、それを特別情報として入力することもできる。

ここで、本部担当者が日報を入力する際のコンピュータシステムの動作について詳細に説明する。
図１３は、この動作を行う際に必要となるデータベース１１内のデータを示したものである。
このうち、従業員マスタ１１ａ、契約先マスタ１１ｃ、店舗マスタ１１ｄについては、既に説明したので、ここでは説明を省略する。
日報マスタ１１ｋは、作業指示書に対する報告である日報に関する各種情報を管理するマスタファイルである。「ＩＤ」は、このマスタファイルにおけるキー項目であり、日報を一意に識別する識別情報である。「記入者ＩＤ」は、各日報を記入した担当者の識別情報であり、「巡回店舗ＩＤ」は、各日報がどの店舗に関するものであるかを示す情報である。「記入日付」は、各日報を記入した日付である。また、「内容」は、各日報に実際に記入された内容のうち店舗担当者に秘匿する必要のない情報であり、「秘匿内容」は、各日報に実際に記入された内容のうち店舗担当者に秘匿する必要がある情報である。

日報コメントマスタ１１ｍは、日報に対して入力されたコメント(以下、「日報コメント」という)に関する各種情報を管理するマスタファイルである。「ＩＤ」は、このマスタファイルにおけるキー項目であり、各日報コメントを一意に識別する識別情報である。「日報ＩＤ」は、各日報コメントの対象となる日報の識別情報である。また、「記入者ＩＤ」は、各日報コメントを記入した担当者の識別情報であり、「内容」は、各日報コメントの内容である。

日報未読既読マスタ１１ｎは、日報ごと、ユーザごとに、そのユーザがその日報を読んでいるかどうかを管理するマスタファイルである。「ＩＤ」は、このマスタファイルにおけるキー項目であり、未読既読情報を一意に識別する識別情報である。「ユーザＩＤ」は、その未読既読情報の対象となるユーザの識別情報であり、「日報ＩＤ」は、その未読既読情報の対象となる日報の識別情報である。また、「未読既読フラグ」は、ユーザが日報を読んだかどうかを示すフラグである。このフラグは、例えば、初期値を「０」とし、対応するユーザが日報を読むことにより「１」に設定するようにすればよい。

日報コメント未読既読マスタ１１ｒは、日報コメントごと、ユーザごとに、そのユーザがその日報コメントを読んでいるかどうかを管理するマスタファイルである。「ＩＤ」は、このマスタファイルにおけるキー項目であり、未読既読情報を一意に識別する識別情報である。「ユーザＩＤ」は、その未読既読情報の対象となるユーザの識別情報であり、「日報コメントＩＤ」は、その未読既読情報の対象となる日報コメントの識別情報である。また、「未読既読フラグ」は、ユーザが日報コメントを読んだかどうかを示すフラグである。このフラグは、例えば、初期値を「０」とし、対応するユーザが日報コメントを読むことにより「１」に設定するようにすればよい。

尚、これらのマスタファイルは、あるマスタファイルにおけるキー項目が他のマスタファイルにおける所定の項目と連結することにより、１つの大きな結合ファイルを構成している。即ち、図示するように、日報マスタ１１ｋの「ＩＤ」が、日報コメントマスタ１１ｍの「日報ＩＤ」、日報未読既読マスタ１１ｎの「日報ＩＤ」と連結している。また、日報コメントマスタ１１ｍの「ＩＤ」が日報コメント未読既読マスタ１１ｒの「日報コメントＩＤ」と連結しており、日報未読既読マスタ１１ｎの「ＩＤ」が日報コメント未読既読マスタ１１ｒの「日報ＩＤ」と連結している。更に、従業員マスタ１１ａの「ＩＤ」が日報マスタ１１ｋの「記入者ＩＤ」、日報コメントマスタ１１ｍの「記入者ＩＤ」と連結しており、店舗マスタ１１ｄの「ＩＤ」が日報マスタ１１ｋの「巡回店舗ＩＤ」と連結しており、契約先マスタ１１ｃの「ＩＤ」が店舗マスタ１１ｄの「契約先ＩＤ」と連結している。

また、図１４は、店舗担当本部担当者が日報を入力する際の本部担当者端末２０の動作を示したフローチャートである。
まず、店舗担当本部担当者が、日報新規入力画面から日報の情報を入力すると、入力部２２がこれを受け付ける(ステップ２６１)。次に、操作言語生成部２３が、日報マスタ１１ｋに対し、「記入者ＩＤ」をシステム起動時に入力されたユーザＩＤとし、「巡回店舗ＩＤ」をここで入力された店舗のＩＤとし、「記入日付」を本日日付とし、「内容」を図１２の上側に入力された本文とし、「秘匿内容」を図１２の下側に入力された本文とするレコードを追加するための操作言語を生成する。そして、通信部２４が、この操作言語をサーバ１０へ送信する(ステップ２６２)。
そして、日報未読既読マスタ１１ｎに対し、「ユーザＩＤ」を各従業員のＩＤとし、「日報ＩＤ」を日報のＩＤとし、未読既読フラグを初期値とするレコードを追加するための操作言語を生成する。そして、通信部２４が、この操作言語をサーバ１０へ送信する(ステップ２６３)。そしてサーバ１０に日報が登録される。
本実施の形態においては、上記サーバ１０への日報登録の一連の処理が「自動作成された文章を、作業担当者による作業指示書に対する報告として登録する登録手段」となっている。

(６) 作業指示書に対する報告の参照
このようにサーバ１０に日報が登録されると、各担当者は、サーバ１０にアクセスすることで、この日報を参照することができるようになる。
図１５は、日報を参照する際に用いられる画面例(日報参照画面)を示した図である。この画面は、図５のメインメニュー画面における左側のメニューリストの中から「日付指定で日報を読む」、「人指定で日報を読む」、「契約先指定で日報を読む」のいずれかを選択し、条件を指定することにより表示される。

図１５では、人指定で日報を選択することが可能となっており、所望の店舗担当者の氏名を選択することで、その店舗担当者の当月の日報の一覧が表示されるようになっている。
ここでは、店舗担当者として担当者「Ｈ．Ｙ」が選択されている。この日報により、担当者「Ｈ．Ｙ」は、２００５年１２月２日の１４時から１５時半にＤソフトの泉店を訪問していることが分かる。そして、「Ａ：指示書通りの作業を行った旨の報告(指示書の処理)」、「Ｂ：商品紹介・受注」を行っていることが分かる。更に、ＰＣ売り場のＹ氏とＡＶ売り場のＩ氏と面談していることが分かる。更にまた、「内容」欄では、Ｉ氏と面談を行いキャンペーン品の紹介等を行ったことが報告されている。

また、日報参照画面では、表示されている日報に対し、本人(店舗担当者、店舗店頭本部担当者)及び他の店舗担当者及び本部担当者が、コメントを記入することができるようになっている。ここで、コメントとは、例えば、本部担当者から店舗担当者へのねぎらいの言葉、店舗担当者間の情報の交換等である。
図１５では、この日報に対して、本部担当者である担当者「Ｔ．Ｎ」と担当者「Ｔ．Ｙ」より、感謝とねぎらいのコメントが入力されている。

更に、(５)において日報とは別に入力された特別情報は、その特別情報に関する店舗の最新の日付の日報に、コメントとして自動挿入されるようになっている。図１５では、コメント欄２０６における売れ行き情報とインタビュー情報に関するコメントが、この特別情報に該当する。これにより、日報以外の特別情報を日報コメントという形で本部担当者、店舗担当者全員がチェックできるようになっている。

ここで、本部担当者が日報を参照する際のコンピュータシステムの動作について詳細に説明する。尚、この動作においても、図１３の結合ファイルを用いる。
図１６は、このときの本部担当者端末２０の動作を示したフローチャートである。
まず、ユーザが日報ＩＤを入力すると、入力部２２がこれを受け付ける(ステップ２７１)。例えば、ユーザが図５のメインメニューから「日付指定で日報を読む」、「人指定で日報を読む」、「契約先指定で日報を読む」のいずれかを選択すると、日報の抽出条件を設定する画面が表示され、そこで設定した条件に従って日報のリストを表示する。そして、そのリストの中から詳細を閲覧したい日報を選択することにすればよい。次に、操作言語生成部２３が、図１３の結合ファイルから、日報マスタ１１ｋの「ＩＤ」がこの入力された日報ＩＤであるレコードを抽出するための操作言語を生成する。そして、通信部２４が、この操作言語をサーバ１０へ送信する(ステップ２７２)。
すると、サーバ１０では、ＤＢＭＳ１２が、操作言語で指定されたレコードを抽出し、通信部１３が、抽出結果を本部担当者端末２０に送る。
これにより、本部担当者端末２０では、通信部２４が抽出結果を受け取り、結果取得部２５に受け渡す。そして、結果取得部２５は、受け渡されたレコードをメモリに格納する。

次に、操作言語生成部２３が、ステップ２７２で抽出したレコードの中から、日報未読既読マスタ１１ｎの「ユーザＩＤ」がこの作業指示書を参照している担当者のＩＤであるレコードを特定する。そして、この特定したレコード内の「未読既読フラグ」を「既読」とした新たなレコードを作成し、特定したレコードをこの新たなレコードで上書きするための操作言語を生成する。そして、通信部２４が、この操作言語をサーバ１０へ送信する(ステップ２７３)。
すると、サーバ１０では、ＤＢＭＳ１２が、操作言語で指定されたレコードで上書きする。これにより、この日報を参照している担当者自身については、当該日報を「既読」した状態となる。

次に、表示部２１は、ステップ２７２でメモリに格納した情報を、日報参照画面に反映させる(ステップ２７４)。
ここで、ユーザが「コメント記入」ボタン２０７を押下してコメントを入力すると、入力部２２は、このコメントを受け付ける(ステップ２７５)。次に、操作言語生成部２３が、日報コメントマスタ１１ｍに対し、「日報ＩＤ」を今参照している日報のＩＤとし、「記入者ＩＤ」を今参照している担当者のＩＤとし、「内容」をここで記入された内容とするレコードを追加するための操作言語を生成する。そして、通信部２４が、この操作言語をサーバ１０へ送信する(ステップ２７６)。
すると、サーバ１０では、ＤＢＭＳ１２が、操作言語で指定されたレコードを追加する。

また、操作言語生成部２３が、日報コメント未読既読マスタ１１ｒに対し、「ユーザＩＤ」を今参照している担当者のＩＤとし、「日報コメントＩＤ」をここで追加されたレコードの「ＩＤ」とし、「日報ＩＤ」を今参照している日報のＩＤとし、「未読既読フラグ」を「既読」とするレコードを追加するための操作言語を生成する。また、「ユーザＩＤ」を今参照している担当者以外のＩＤとし、「日報コメントＩＤ」をここで追加されたレコードの「ＩＤ」とし、「日報ＩＤ」を今参照している日報のＩＤとし、「未読既読フラグ」を初期値とするレコードを追加するための操作言語を生成する。そして、通信部２４が、これらの操作言語をサーバ１０へ送信する(ステップ２７７)。
すると、サーバ１０では、ＤＢＭＳ１２が、操作言語で指定されたレコードを追加する。

(７) 費用処理
本実施の形態におけるコンピュータシステムを用いて販売促進に関する費用の計上を行う時があり、この場合は、本部担当者が、本部担当者端末２０から費用処理伝票を入力する。
本部担当者端末２０から費用処理伝票が入力されると、費用処理承認者とその承認順序のリストがサーバ１０内に作成される。ここで、費用処理の承認順序としては、「グループリーダ→部長→経理」といったものが例示される。

この処理において、「グループリーダ」(一次承認者)→「部長」(二次承認者)→「経理担当者」(三次承認者・処理者)というリストが作成された場合に、一番目の費用処理承認者(上記例では、グループリーダ）が使用する承認担当者端末４０に対し、費用の承認を促す通知がなされる。また、一番目の承認者がその承認担当者端末４０に費用の承認を入力すると、次の費用処理承認者(上記例では、部長)が使用する承認担当者端末４０に対し、費用の承認を促す通知がなされる。以後、上記例で三次承認者である経理担当者に行き着くまでこの操作が繰り返される。尚、現在承認がどの段階にあるかは、費用処理伝票を入力した本部担当者がモニタできるようになっているものとする。

以上、本実施の形態について述べてきたが、本実施の形態によれば、次のような効果が得られる。
即ち、図５に示した店舗担当者のスケジュールを表示する画面と、図１０に示した店舗担当者の作業指示書の閲覧状況を表示する画面とを併用することにより、本部担当者が、店舗担当者の動きをリアルタイムで把握することが可能となる。
つまり、指示書によって作業が発生する人は、担当店舗のある店舗担当者なので、本部担当者にとっては、店舗担当者に指示書を読んでもらう必要がある。そこで、図１０の指示参照画面により、本部担当者は、担当店舗のある店舗担当者が指示書を読んでいるのか否かが分かる。全員が指示書を読んでくれれば問題はないが、指示書未読の店舗担当者がいる場合に、その店舗担当者の動向(なぜ指示書を読んでいないのか)をチェックする必要がある。このような場合、図５の「本日のスケジュール」欄２０１を参照することにより、その店舗担当者がなぜ指示書を読んでいないのかの理由がわかる。例えば、「本日のスケジュール」欄２０１において、その各店舗担当者が「休暇中」、「退勤済」、「不明」と表示されていれば、システム自体にアクセスしていないために指示書の存在を確認することができていないことが分かる。

また、これとは別に、図５に示した店舗担当者のスケジュールを表示する画面と、図１５に示した店舗担当者の作業指示書に対する報告状況を表示する画面とを併用することによっても、本部担当者が、店舗担当者の動きをリアルタイムで把握することが可能となる。つまり、本部担当者は、店舗担当者に作業報告をしてもらう必要があるが、作業報告がない場合に、その原因(「休暇中」、「退勤済」等)を把握することが可能となる。
尚、本実施の形態では、作業指示書の閲覧状況と作業指示書に対する報告情報をリアルタイムで把握することについて説明してきたが、その他の作業状況を把握する際にも本発明は適用可能である。

ここで、本発明は、ソフトウェアとハードウェア資源とが協働することにより実現される。具体的には、サーバ１０、本部担当者端末２０、店舗担当者端末３０、承認担当者端末４０の図示しないＣＰＵが、それぞれの機能を実現するコンピュータプログラムを外部記憶装置から主記憶装置に読み込んで処理を行う。また、このコンピュータプログラムは、コンピュータにより読取り可能な記録媒体から提供することができる。ここで、記録媒体としては、フレキシブルディスク、光ディスク等が例示される。

本発明の実施の形態におけるコンピュータシステムの全体構成を示したブロック図である。 本発明の実施の形態におけるスケジュール登録に用いられる画面の例を示した図である。 本発明の実施の形態におけるスケジュール登録/参照に用いられるデータベースの構造を示した図である。 本発明の実施の形態におけるスケジュール登録時の本部担当者端末の動作を示したフローチャートである。 本発明の実施の形態におけるスケジュール参照に用いられる画面の例を示した図である。 本発明の実施の形態におけるスケジュール参照時の本部担当者端末の動作を示したフローチャートである。 本発明の実施の形態における指示書入力に用いられる画面の例を示した図である。 本発明の実施の形態における指示書入力/参照に用いられるデータベースの構造を示した図である。 本発明の実施の形態における指示書入力時の本部担当者端末の動作を示したフローチャートである。 本発明の実施の形態における指示書参照に用いられる画面の例を示した図である。 本発明の実施の形態における指示書参照時の本部担当者端末の動作を示したフローチャートである。 本発明の実施の形態における日報入力に用いられる画面の例を示した図である。 本発明の実施の形態における日報入力/参照に用いられるデータベースの構造を示した図である。 本発明の実施の形態における日報入力時の本部担当者端末の動作を示したフローチャートである。 本発明の実施の形態における日報参照に用いられる画面の例を示した図である。 本発明の実施の形態における日報参照時の本部担当者端末の動作を示したフローチャートである。

符号の説明

１０…サーバ、２０…本部担当者端末、３０…店舗担当者端末、４０…承認担当者端末

Claims (7)

1. 作業担当者の作業状況の管理担当者による管理を支援するための作業状況管理支援システムであって、
   前記作業担当者のスケジュールに関する第１の情報を記憶する第１の記憶手段と、
   前記管理担当者が発行した作業指示書に基づく前記作業担当者の作業状況に関する第２の情報を記憶する第２の記憶手段と、
   前記第１の記憶手段に記憶された前記第１の情報に基づく表示を指示するための領域と、前記第２の記憶手段に記憶された前記第２の情報に基づく表示を指示するための領域とを含む画面を表示する表示手段と
   を備えたことを特徴とする作業状況管理支援システム。
2. 前記第２の情報は、前記作業担当者による前記作業指示書の閲覧の有無及び日付を含むことを特徴とする請求項１記載の作業状況管理支援システム。
3. 前記作業指示書に関するコメントの入力に応じて、前記作業担当者による当該作業指示書の閲覧の有無を、閲覧が無い旨の情報に更新する更新手段を更に備えたことを特徴とする請求項２記載の作業状況管理支援システム。
4. 前記第２の情報は、前記作業担当者による前記作業指示書に対する報告を含むことを特徴とする請求項１記載の作業状況管理支援システム。
5. 特定の作業を行った旨の文章を、当該特定の作業について表示されたチェックボックスに対する前記作業担当者のチェック操作を認識することにより自動作成する入力支援手段と、
   自動作成された前記文章を、前記作業担当者による前記作業指示書に対する報告として登録する登録手段と
   を更に備えたことを特徴とする請求項４記載の作業状況管理支援システム。
6. 作業担当者の作業状況の管理担当者による管理をコンピュータが支援する作業状況管理支援方法であって、
   前記コンピュータが、第１の領域と第２の領域とを含む画面を表示するステップと、
   前記コンピュータが、前記第１の領域における操作に応じて、前記作業担当者のスケジュールに関する第１の情報を記憶する第１の記憶手段から、当該第１の情報を読み出すステップと、
   前記コンピュータが、前記第１の情報に基づいて、前記作業担当者のスケジュールを表示するステップと、
   前記コンピュータが、前記第２の領域における操作に応じて、前記作業担当者の作業状況に関する第２の情報を記憶する第２の記憶手段から、当該第２の情報を読み出すステップと、
   前記コンピュータが、前記第２の情報に基づいて、前記作業担当者の作業状況を表示するステップと
   を含むことを特徴とする作業状況管理支援方法。
7. 作業担当者の作業状況の管理担当者による管理を支援するためのプログラムであって、
   コンピュータに、
   前記作業担当者のスケジュールに関する第１の情報を記憶する第１の記憶手段から、当該第１の情報を読み出す機能と、
   前記管理担当者が発行した作業指示書に基づく前記作業担当者の作業状況に関する第２の情報を記憶する第２の記憶手段から、当該第２の情報を読み出す機能と、
   前記第１の記憶手段から読み出された前記第１の情報に基づく表示を指示するための領域と、前記第２の記憶手段から読み出された前記第２の情報に基づく表示を指示するための領域とを含む画面を表示する機能と
   を実現させるためのプログラム。

Images