JP2007094517A - 図書館情報管理システム - Google Patents

Abstract

【課題】図書館の運用に合わせた作業ワークフローが構築でき、図書館における作業状況を管理しやすくする図書館情報管理システムを提供する。
【解決手段】図書館情報を管理するための複数の機能を有する図書館情報管理システムであって、実行可能な前記機能と対応するアクティビティに、当該アクティビティで処理されるデータの入力状態と出力状態を管理するトレイを定義し、このアクティビティを実行順に並べた作業フローを保持しておき、前記作業フローに定義されたアクティビティの順番で前記機能を実行させ、実行している作業フローに対するアクティビティの完了状況をアクティビティテーブルとして記録する制御部を備えている。また、トレイには、データが受入可能であるか、データに必要なデータ項目が設定されているかどうかを判断するチェック機能が付加されている。
【選択図】図２

Description

本発明は、図書館情報管理システムに関し、特に、図書館における作業状況を管理しやすくするシステムに関し、作業ワークフローのある業務であれば同様に適用することができる。

近年のコンピュータ及びネットワークをはじめとする情報関連技術のめざましい発展により、図書館においてもコンピュータ等を用いた図書に関する各種情報の取得、管理がなされており、図書館業務における情報の電子化・オンライン化が進められている。

通常、図書の受入に焦点をあてた場合、選書／購入依頼⇒発注検討⇒発注⇒受入⇒整理⇒装備⇒配架という作業を順次実施する。
特許文献１に示した従来の発注受入システムでは、このような作業をそれぞれの作業に応じた複数のシステムを利用して、図書館の運用に合わせて、システムを組み合わせて処理を行っていたため、そのための作業が繁雑になり、効率が悪いという問題があった。

例えば、図１に例示したように、学生からの依頼、教員からの依頼、図書館の選書方針に従って業者が選定した本をそのまま購入する見計らいなど、図書の購入形態により、利用するアプリケーションの組み合わせ方が異なり、業務のやり方が煩雑になるという問題があった。

「学生からの依頼」の場合、購入依頼があると、その発注依頼に対して、発注の検討が行われ、業者へ発注が行われる。業者から納入されると、受入処理を行って、登録番号の採番を行って、統合目録の整理を行う。
また、「教員からの依頼」の場合、購入依頼があると、その発注依頼に対して、業者へ発注が行われる。これ以降の処理は「学生からの依頼」と同様である。
また、「見計らい」の場合、業者から納入されたあとの処理は、「学生からの依頼」や「教員からの依頼」の場合と同様である。

また、図書館ごとに、業務の運用が異なり、アプリケーションが提供する機能単位と合わないという問題があった。例えば、受入と同時に目録の整理も行う場合、目録のシステムを使わなければならず、図書発注のシステムで完結できないという問題があった。

また、複数人がデータ作成を行った場合に、自分が作成したデータを判別することができず、担当している業務に対して、どのステップの作業がどれだけ残っているのかを判別することが容易でないという問題があった。
さらに、上述のような発注形態により、次にどの作業を行えば良いのか、システム的に分からないという問題があった。

一方、図書館を取り巻く環境の変化による課題としては、少子化等により、大学の経営環境が厳しくなることが予想され、専門職員から派遣職員への転換、あるいは業務のアウトソーシングによって、経費削減等を行うという環境変化が発生している。
また、図書館の専門知識を持たない派遣職員へ転換した場合、様々な発注形態に即した作業をこなすことが難しくなってきており、参照可能なデータ、利用可能な機能などを制限しなければならない等の問題が起きている。

さらに、文書管理系のワークフローシステムとしては、例えば、審査・承認システムの場合、テンプレートとして文書作成、議事録作成などの書式が用意されている。この場合、作成するテンプレートを選んで、データを入力し、審査対象者に対してメールをすることにより、フローが実行される仕組みになっている。
現在の状況を確認する場合には、ビューを参照することで、審査・承認の状態を把握することができるが、ビューの参照やビュー中の文書の参照・編集等は、特定の権限をもった人が参照、又は、編集できる仕組みになっている。

このような文書管理系のワークフローシステムを図書館情報管理システムに応用した場合、次の問題点が発生する。
審査・承認システムの場合、基本的には、状態としては、作成中・審査中・承認中・承認完了をもっている。しかしながら、図書館の場合は、作業フローに応じて、行うべき作業状態が様々であり、文書管理のようにフローが固定化されていないという問題がある。

また、図書館情報管理システムの場合、各作業によって実行できる機能、参照・編集できるデータの構造が異なっている。例えば、発注作成の作業では、発注データと仮の書誌データが作成され、次に、受入の作業では、所蔵データが作成される。整理の作業においては、正規の書誌データが作成され、仮の書誌データが削除される仕組みになっている。
しかし、文書管理システムの場合、新規作成から、承認完了までの流れにおいて、データ構造は同一であり、作業状態に応じて、データ構造を変えることができないという問題がある。

また、図書館情報管理システムの場合、書店への発注を行う作業においては、書店毎に発注データなどを分類して行う。しかし、文書管理システムの場合、同一状態のデータを任意のグループに振り分けることができないという問題がある。
特開２００３−９９５６３号公報

本発明は、上述のごとき実情に鑑みてなされたものであり、図書館の運用に合わせた作業ワークフローが構築でき、図書館における作業状況を管理しやすくする図書館情報管理システムを提供することを目的とする。

上記課題を解決するために、請求項１に記載の発明は、図書館情報を管理するための複数の機能を有する図書館情報管理システムにおいて、実行可能な前記機能と対応するアクティビティに、当該アクティビティで処理されるデータの入力状態と出力状態を管理するトレイを定義し、このアクティビティを実行順に並べた作業フローを保持しておき、前記作業フローに定義されたアクティビティの順番で前記機能を実行させ、実行している作業フローに対するアクティビティの完了状況をアクティビティテーブルとして記録する制御部を有することを特徴とする図書館情報管理システムである。

請求項２に記載の発明は、請求項１に記載の図書館情報管理システムにおいて、データを受入可能な各アクティビティの状態を設定するアクティビティチェックテーブルを前記トレイに定義しておき、前記制御部は、入力状態あるいは出力状態を管理するトレイにデータを移動するときには、前記アクティビティテーブルと前記アクティビティチェックテーブとを照合し、トレイに移動可能かどうかを判定することを特徴とする図書館情報管理システムである。

請求項３に記載の発明は、請求項２に記載の図書館情報管理システムにおいて、データをトレイに移動するときに必要なデータ項目であるか否かの状態を設定するデータチェックテーブルを前記トレイに定義しておき、前記制御部は、入力状態あるいは出力状態を管理するトレイにデータが移動されたときに、前記データ中のデータ項目と前記データチェックテーブルとを照合して、必要なデータ項目が設定されているかどうかを判断することを特徴とする図書館情報管理システムである。

請求項４に記載の発明は、請求項１、２または３に記載の図書館情報管理システムにおいて、前記制御部は、データがトレイに移動したときに、トレイの状態を所定の連絡先へ通知することを特徴とする図書館情報管理システムである。

請求項５に記載の発明は、請求項１乃至４のいずれかに記載の図書館情報管理システムにおいて、ユーザあるいはユーザグループ毎に実行可能あるいは実行不可の権限を前記作業フローに設定しておき、前記制御部では、前記作業フローの権限に応じて、ユーザに指定された作業フローの実行を制御することを特徴とする図書館情報管理システムである。

請求項６に記載の発明は、請求項１乃至５のいずれかに記載の図書館情報管理システムにおいて、ユーザあるいはユーザグループ毎に参照あるいは実行の権限を前記アクティビティに設定しておき、前記制御部では、前記アクティビティの権限に応じて、ユーザに指定されたアクティビティの実行を制御することを特徴とする図書館情報管理システムである。

本発明によれば、図書館の運用に合わせた作業フローを構築できるため、次に列挙する効果がある。
（１）作業フロー毎に実施すべき作業を明示するため、各作業ステップが把握しやすくなる。
（２）自分が作業しているデータや作業状態の進捗を把握することができる。
（３）作業に応じて、画面に表示すべき項目や機能をカスタマイズできるため、各作業で実施すべき内容が明確になる。
（４）次の作業に移行する際に、データチェックが自動的に行われるため、作業ミスが減る。
（５）必要に応じてデータチェック用のトレイを定義できるため、派遣職員や嘱託職員が作成したデータの内容を管理者がチェックできる。
（６）ルーチンワークの作業工数が減り、その分、利用者サービスなど、その他の作業に時間を割くことができる。

さらに、本発明を利用することによって、経営者には次のような効果がある。
（７）図書館の業務、あるいは、システムに精通していない人でも作業ができる。
（８）業務の切り分けができるため、人材派遣やアウトソーシングの活用がし易くなる。
（９）作業効率の向上により、生産性が高まる。

以下、図面を参照して本発明の好適な実施形態を説明する。

（Ａ）概要：
従来においては、大規模、中規模の図書館においては、作業毎に担当職員が割り当てられていたため、作業＝アプリケーションの単位というモデルは機能していた。
しかしながら、現在においては、業務作業の効率化と利用者向けサービスの拡大という点で、大規模・中規模図書館においても、業務に割り当て可能な要員が減ってきている。 また、小規模図書館においては、各作業を横断して少数の要員で作業をこなす必要があり、できる限り作業ステップを最小化して実施したいという要求がある。

こうした背景を踏まえると、担当者にとっては、次のような要求が生まれてくる。
（１）各作業フローに応じた全体の作業の流れがわかる。
（２）作業毎にすべき作業内容がわかる。
（３）図書館の運用に合わせて作業フローをカスタマイズしたい。

本発明では、「トレイ」という概念を用い、トレイとトレイの連結により各作業の手順を定義し、また、トレイの種類により、各作業の状態がわかる仕組みを提供する。

（Ｂ）データ構造：
まず、本発明の特徴である作業手順を定義するデータ構造について説明する。図２は、１つの作業を定義するためのデータ構造の全体図である。また、図３は、このデータ構造を説明するための作業例（「購入申込による資料購入」と「見計らいによる資料購入」の作業）であり、図４乃至図９は、この作業例に対するデータ構造の実例である。
下記の作業フロー、アクティビティ、トレイについては、本システムを利用する前に定義するものであり、データオブジェクトは作業フローの開始に生成される。

（Ｂ−１）作業フロー：
作業フローは、１つの業務を実行するための各作業（「アクティビティ」ともいう）の実行順序を定義したものである。作業フローの権限は、ユーザ、または、ユーザグループ単位で設定することができ、この権限に応じて、作業フローの実行可・不可を制御することができる。この「作業フロー」には、次のようなデータ項目を定義する。

・ユニークな作業フローＩＤ：
本システムに登録される作業フローを識別するための識別子である、
・作業フローの名称：
作業の指示あるいは進捗状況の表示において、人間が識別しやすく表現した名称である、
・ユニークなアクティビティＩＤのリスト：
作業の流れの順をアクティビティＩＤのリストで示すが、リスト中には、同一のアクティビティＩＤを含むことはできない、
・当該作業フローの権限：
職員や管理者のうち誰が当該作業フローを実行できる、また、実行できないかの権限を示す。

例えば、図４（Ａ）は「購入申込による資料購入」の作業フローのデータ構造例であり、図４（Ｂ）は「見計らいによる資料購入」の作業フローのデータ構造例である。
図４（Ａ）は、作業フローＩＤとして「Ｆ０１」、作業フロー名称として「購入申込による資料購入」、この作業におけるアクティビティリストをそれぞれの作業のアクティビティＩＤで表現している。これにより、「購入申込による資料購入」の作業には、「発注作成」、「発注検討」、「発注検討承認」、「発注」、「受入」、「採番」、「整理」の７つのアクティビティがあり、リストの順に実行されることが定義される。
図４（Ｂ）の「見計らいによる資料購入」についても同様に定義される。

権限については、まず本システムを利用するときに各作業の担当を決定しておく。例えば、「職員A」は「発注作成」〜「発注」の作業を行い、「職員B」は「受入」〜「整理」の作業を行う。また、「職員A」と「職員B」の管理者は「管理者C」であるとする。
すると、「資料購入」の担当である「職員A」、「職員B」、「管理者C」における作業フローの権限は、図５に示したように実行可の権限が与えられる。
これにより、作業フロー「購入申込による資料購入」および「見計らいによる資料購入」の権限は、職員それぞれのユーザＩＤと実行可・不可の対で定義される。例えば、（職員AのユーザＩＤ、実行可）、（職員BのユーザＩＤ、実行可）、（管理者CのユーザＩＤ、実行可）が権限として定義される。この権限に現れないユーザＩＤの時には実行不可として扱う。

（Ｂ−２）アクティビティ：
アクティビティは、作業フローで実行される作業の１つを定義したものである。
アクティビティの権限は、ユーザ、または、ユーザグループ単位で設定することができ、この権限に応じて、アクティビティの参照・実行を管理することができる。ここで、「参照の権限」では、アクティビティ中の全てのトレイの参照の可・不可の制御ができ、「実行の権限」では、アクティビティに定義されたアクションテーブルの機能の実行可・実行不可を制御することができる。この「アクティビティ」には、次のようなデータ項目を定義する。

・ユニークなアクティビティＩＤ：
本システムに登録されているアクティビティを識別するための識別子である、
・アクティビティの名称：
アクティビティの指示あるいは進捗状況の表示において、人間が識別しやすく表現した名称である、
・トレイＩＤのリスト：
通常は、アクティビティのinとoutを管理するトレイのトレイＩＤのリストを定義する、
・アクションテーブル：
当該アクティビティで実行可能な機能を定義する、
・当該アクティビティの権限：
ユーザ、ユーザグループ単位で、アクティビティの実行権限を、作業状況を参照できる「参照」権限と、この作業を実行させる「実行」権限とで定義する。

例えば、図６（Ａ）は「発注作成」のアクティビティのデータ構造例であり、図６（Ｂ）は「発注検討」のアクティビティのデータ構造例である。
図６（Ａ）における「発注作成」のアクティビティの結果（out）としては、「発注作成済」と「発注保留」がある。そのためトレイリストには、「TA0101：発注作成済」と「TA0102:発注保留」とが定義される。データオブジェクトを発注作成済のoutのトレイへ移動すると同時に、発注検討待のinのトレイに移動することを定義するためには、「TA0101：発注作成済→TA0201：発注検討待」のように記述し、管理者による審査がいらない場合に自動移動させるときに使用する。

また、アクションテーブルには、このアクティビティ「発注作成」において、実行可能な機能、即ち、「発注作成済処理」、「発注保留処理」のＩＤが定義される。

また、図７に示したように、アクティビティの権限を担当ごとに実行可能なアクティビティを定める。図７において、○印のついている権限が、担当によって「参照」できる、あるいは「実行」できることを示し、○印のないものは権限を有していないことを示している。例えば、「職員A」の担当が「受入」〜「整理」の作業であるからアクティビティ「発注作成」の「参照」と「実行」が許可されているが、「職員B」の担当が「受入」以降の作業であるから、「発注作成」には「参照」の権限のみが許可される。
したがって、アクティビティ「発注作成」の権限は、担当のユーザＩＤと参照・実行の区別を定義したものになり、例えば、（職員AのユーザＩＤ、「参照」「実行」）、（職員BのユーザＩＤ、「参照」）、（管理者のユーザＩＤ、「参照」「実行」）が定義される。

図６（Ｂ）における「発注検討」のトレイリストには、inのトレイとしては「TA0201：発注検討待」、outのトレイとしては「TA0202：発注検討済」と「TA0203：発注取消」とがある。アクションテーブルや権限については、「発注作成」アクティビティと同様にして定義する。
他のアクティビティについても同様にして定義する。

（Ｂ−３）トレイ：
トレイは、アクティビティで処理されるデータのin／outを管理するための入れ物である。この「トレイ」には、次のようなデータ項目を定義する。

・ユニークなトレイＩＤ：
本システムに登録されているトレイを識別するための識別子である、
・トレイの名称：
進捗状況の表示において、人間が識別しやすく表現した名称である、
・アクティビティチェックテーブル：
データオブジェクト中に記憶されたアクティビティテーブルと照合し、トレイに移動可能かどうかを判定するために利用される、
・データチェックテーブル：
データオブジェクトをトレイに移動するときに、必要なデータが設定されているかどうかを判定するために利用される。

図８は、「発注検討」アクティビティの「発注検討済」のトレイの定義例である。
図８（Ａ）によると「発注検討済」のトレイは、トレイＩＤを「TA0202」、トレイ名称を「発注検討済」とし、アクティビティチェックテーブルの格納されている場所を識別するアクティビティチェックテーブルＩＤと、データチェックテーブルの格納されている場所を識別するデータチェックテーブルＩＤが定義されている。ここで、アクティビティチェックテーブルＩＤあるいはデータチェックテーブルＩＤが設定されていない場合には、チェックをしないことを示す。

アクティビティチェックテーブルでは、データオブジェクトを受入可能な各アクティビティの状態を予め設定しておき、データオブジェクト中のアクティビティテーブルと照合することにより、移動可否の判定を行う。
例えば、図８（Ｂ）のアクティビティチェックテーブルでは、「A01：発注作成」、「A02：発注検討」について、「設定済」が定義してあるので、データオブジェクトを「発注検討済」トレイに移動する場合には、データオブジェクト上の処理が「発注作成」および「発注検討」まで行われている必要があることを示している。

また、データチェックテーブルは、トレイにデータオブジェクトが移動されたときに、必要なデータ項目が設定されているかどうかを判断するために使用するものである。
例えば、図８（Ｃ）に例示したようなデータ項目について「設定済」あるいは「未設定」を設定してあると、トレイ「発注検討済」にデータオブジェクトが移動されたときに、そのデータオブジェクトのデータ項目「発注番号」、「発注日」、「予算区分」、「予算単位」にデータが設定されているかをチェックし、１つでも設定されていないと、このトレイにデータを移動することができない。

（Ｂ−４）データオブジェクト：
データオブジェクトは、冊子体、電子媒体の発注情報、書誌情報、所蔵情報などを管理するための入れ物である。このデータオブジェクトは、作業フローの実行を開始したときに生成されて、次のようなデータ項目が記録される。
・ユニークなデータオブジェクトＩＤ：
このデータオブジェクトが生成されたときに、作成されるユニークな識別子であり、例えば、購入依頼された１件ごとの伝票に対応する、
・１つのアクティビティテーブル：
アクティビティの実行が完了する毎に、実行した実行日と実行した実行者のユーザＩＤなどの情報が記録される、
・カレントなトレイＩＤ：
現在作業がどこまで進んでいるかを示すトレイの識別子（トレイＩＤ）である、
・トレイのinとoutに関する処理履歴：
トレイへの移動が許されたときに、トレイＩＤ、トレイ名称、inのときの実行日と実行者のユーザＩＤ、outのときの実行日と実行者のユーザＩＤとを累積する。

例えば、「発注作成」アクティビティで、新しく購入を申し込んだときには、図９に例示したようなデータオブジェクトが作成される。
この「データオブジェクト」は、１つのレコードとして、発注情報、所蔵情報などを管理しても良いし、データ部と発注情報部を分けて、レコードのリンク関係で管理しても良い。本実施形態では、データ部と発注情報部とに分け、レコードのリンクをデータＩＤで示すものとして説明する。

データオブジェクトを新規に作成すると、「データ部」には、実行している作業フローに対するアクティビティの情報が「アクティビティテーブル」として生成される。このアクティビティテーブルには、各アクティビティが完了する毎に、実行日、実行者の情報が記録される。ここで、職員が発注データ作成の確定処理をした場合、「アクティビティテーブル」の「発注作成」アクティビティには、実行日「2005／07／07」と実行者「職員A」が記録される。

次に、作成した発注データを、「発注作成済」のトレイに移動すると、データオブジェクトのアクティビティテーブルとトレイのアクティビティチェックテーブルを比較して、移動可能かどうかを判定する。移動可能な場合は、次にデータオブジェクトの発注情報の項目とデータチェックテーブルの項目を比較し、所定の項目が設定されているかどうかを検査する。所定項目が設定されている場合は、トレイへの移動が可能となる。
トレイ移動後、トレイ履歴には、図９のような情報が累積される。

（Ｂ−５）ユーザ情報、ユーザグループ情報：
ユーザ情報は、図書館情報管理システムを利用する担当者の情報や図書館を利用する一般の利用者の情報を管理する。このユーザ情報（例えば、ユーザの名前や所属や連絡先等）は、ユニークなユーザＩＤによって識別される。

ユーザグループ情報は、管理者・一般担当者など、ある目的をもった役割の集合体として、複数のユーザを管理する。このユーザグループ情報（例えば、グループ名称、グループに与えられた権限、グループに所属するユーザのユーザＩＤリスト等）は、ユニークなユーザグループＩＤによって識別される。

（Ｂ−６）本発明のデータ構造を利用したときの利点：
業務ごとに、作業フローとアクティビティを定義できるので、例えば、資料の購入形態に合わせた作業フローを構築することができる。
また、各作業のフローを定義するので、次にすべき作業工程が専門知識を持たないものであっても処理できる。
各作業工程にin／outのトレイを設けるようにしたので、各トレイの情報を一望することにより、作業の進捗を容易に把握できる。

（Ｃ）本実施形態の機能構成：
次に、上述した定義を用いた本実施形態の機能構成とその動作について説明する。
図１０は、本実施形態に係る図書館情報管理システムの機能構成を示すブロック図であり、同図において、図書館情報管理システムは、従来の図書館情報管理の機能群、図書館情報データベース（以降、ＤＢと略記する）、本システムを利用する管理者・担当者の情報及びユーザグループの情報を管理するユーザ情報記憶部からなる図書館情報管理システムに加えて、本発明の特徴部である、本システム全般を制御する制御部１０、ログインした担当者が行う作業の選択指示を入力する作業選択部２０、ログインした担当者が行うアクティビティの選択を行うアクティビティ選択部３０、選択されたアクティビティに定義されている図書館情報管理システム中の機能を実行させる機能実行部４０、作業定義ファイル６０、データオブジェクト記憶部７０を含んで構成されている。

作業定義ファイル６０は、上記（Ｂ）で説明した、本実施形態で扱うすべての作業に対して定義された作業フロー、アクティビティおよびトレイを保持している。
データオブジェクト記憶部７０は、上記（Ｂ）で説明したデータオブジェクトを保持する。

次に、上述した機能構成において、本システムの動作について説明する。ここでは、上述した担当者「職員A」が「資料の購入」作業を行う場合を例にとって説明する。
まず、「職員A」は、図書館情報管理システムにログインする。ログインして自分の担当するサブシステム（ここでは「図書発注」）を選択すると、制御部１０は、作業選択部２０を起動させる。

作業選択部２０は、作業定義ファイル６０を参照して、図１１に例示したように、「図書発注」サブシステムに登録されている作業フローのうち、「職員A」が利用可能な作業フローを取り出して、その全リストを画面に表示する。ここで、画面に表示されたメニューには、作業フローの権限設定において、「参照」あるいは「実行」が実行可のものについては表示状態であり、実行不可の場合には非表示の状態で表示される。
「職員A」が図１１のようなメニューから「購入申込による資料購入」をマウス等で選択して、ダブルクリックや実行開始ボタンの押下などによって実行すると、作業選択部２０は、「職員A」から選択された作業フロー「購入申込による資料購入」の作業フローＩＤを取得して、制御部１０へ制御を戻す。

制御部１０は、アクティビティ選択部３０を起動して、「職員A」が選択した作業フローＩＤを送る。
アクティビティ選択部３０は、次の順番で処理を行う。

（１）作業定義ファイル６０を参照して、作業フローＩＤで指定される作業フローの全てのアクティビティＩＤを取得する。
（２）作業定義ファイル６０を参照して、各アクティビティＩＤについて次の順で処理する。
（２−１）アクティビティＩＤで指定されるアクティビティが持つトレイリストに定義された全てのトレイＩＤを取得する。
（２−２）データオブジェクト記憶部７０を参照して、各トレイＩＤと同じトレイＩＤを持つデータＩＤの数を計数する。
（２−３）この計数された数が、アクティビティＩＤで示されたアクティビティに属するトレイのデータオブジェクト件数となる。
（３）指定された作業フローに属するアクティビティのリストからなるメニュー（例えば、図１２参照）を表示する。このメニューの各アクティビティには、アクティビティが保有するトレイの情報（トレイ名称とデータオブジェクト件数など）が表示される。

「職員A」が図１２のようなメニューから「発注作成」をマウス等で選択して、ダブルクリックや実行開始ボタンの押下などによって実行すると、アクティビティ選択部３０は、作業定義ファイル６０を参照して、「職員A」から選択されたアクティビティ「発注作成」のアクティビティＩＤを取得するとともに、「職員A」がこのアクティビティを実行する権限がなければ、権限なしの表示を行う。また、権限を持っていれば制御部１０へ制御を戻す。

次に、制御部１０は、機能実行部４０を起動して、アクティビティＩＤを送る。
機能実行部４０は、アクティビティＩＤで指定されるアクティビティの中で、「保留」トレイや「待ち」トレイを探し、これらのトレイを持つデータオブジェクトをデータオブジェクト記憶部７０から取り出してリスト表示し、この中からデータを動かしたいデータオブジェクトＩＤを選択させる。

機能実行部４０は、選択されたデータオブジェクトＩＤのアクティビティテーブルと、カレントのトレイＩＤのアクティビティチェックテーブルを比較して、移動可能かどうかを判定する。
移動可能な場合は、次にデータオブジェクトの発注情報の項目とデータチェックテーブルの項目を比較し、所定の項目が設定されているかどうかを検査する。所定項目が設定されている場合は、トレイへの移動が可能となる。このとき、アクティビティテーブルのカレントのトレイＩＤを移動したトレイＩＤに書き換えるとともに、トレイ履歴にinに関する実行日と実行者を累積する。また、トレイに移動した際には、トレイの状態を管理者へメール通知したり、あるいは、ＲＳＳ等によりトレイの状態を配信するようにしてもよい。

そして、このアクティビティで実行可能な図書館情報管理の機能を実行させ、実行が完了した場合、アクティビティのoutに関するトレイへデータオブジェクトを移動させて（カレントのトレイＩＤを移動したトレイＩＤに書き換える）、トレイ履歴へoutに関するトレイの実行日と実行者を累積し、アクティビティテーブルにも、アクティビティの実行日と実行者を記録する。
機能実行部４０は、このあと制御部１０へ制御を戻す。

また、機能実行部４０は、新規に「発注作成」アクティビティの実行を指定された場合には、「発注作成」アクティビティを実行すると、図１３に示した発注データを入力するための画面が表示される。
入力後、「職員A」が確定処理を行うと、機能実行部４０は、実行している作業フローに対するアクティビティの情報を「アクティビティテーブル」として生成し、データオブジェクト記憶部７０に記憶する。このとき、アクティビティテーブルには、実行日と実行者が記録される。

機能実行部４０は、次に作成した発注データを、「発注作成済」のトレイに移動すると、データオブジェクトのアクティビティテーブルとトレイのアクティビティチェックテーブルを比較して、移動可能かどうかを判定する。移動可能な場合は、次にデータオブジェクトの発注情報の項目とデータチェックテーブルの項目を比較し、所定の項目が設定されているかどうかを検査する。所定項目が設定されている場合は、トレイへの移動が可能となる。トレイ移動後、アクティビティテーブルのカレントのトレイＩＤを移動したトレイＩＤに書き換えるとともに、トレイ履歴には、outに関するトレイの実行日と実行者を累積する。また、トレイに移動した際には、トレイの状態を管理者へメール通知したり、あるいは、ＲＳＳ等によりトレイの状態を配信するようにしてもよい。

また、担当者及び管理者が必要に応じて、アクティビティ毎のトレイの情報を表示することができるので、作業の進捗を把握することができる。
また、作業定義ファイルに、チェック用のトレイを定義することにより、管理者が各作業ステップにおけるデータの内容を確認することができる。

以上、図書館情報管理を例にして説明したが、これに限定されるものではなく、行うべき作業状態が固定したものではなく、様々に変化していくような業務形態であれば本発明を適用することができる。

本発明は、上述した実施形態のみに限定されたものではない。上述した実施形態を構成する各機能をそれぞれプログラム化して、予め記録媒体に書き込んでおき、この記録媒体に記録されたこれらのプログラムをコンピュータに備えられたメモリあるいは記憶装置に格納し、そのプログラムを実行することによって、本発明の目的が達成されることは言うまでもない。この場合、記録媒体から読み出されたプログラム自体が上述した実施形態の機能を実現することになり、そのプログラムおよびそのプログラムを記録した記録媒体も本発明を構成することになる。
また、上記プログラムは、そのプログラムの指示に基づき、オペレーティングシステムあるいは他のアプリケーションプログラム等と共同して処理することによって上述した実施形態の機能が実現される場合も含まれる。

なお、上述した実施形態の機能を実現するプログラムは、ディスク系（例えば、磁気ディスク、光ディスク等）、カード系（例えば、メモリカード、光カード等）、半導体メモリ系（例えば、ＲＯＭ、不揮発性メモリ等）、テープ系（例えば、磁気テープ、カセットテープ等）等のいずれの形態の記録媒体で提供されてもよい。あるいは、ネットワークを介して記憶装置に格納された上記プログラムをサーバコンピュータから直接供給を受けるようにしてもよい。この場合、このサーバコンピュータの記憶装置も本発明の記録媒体に含まれる。
このように、上述した実施形態の機能をプログラム化して流通させることによって、コストの低廉化、および可搬性や汎用性を向上させることができる。

従来の図書の購入形態による業務のやり方における問題点を説明するための図である。 １つの作業を定義するためのデータ構造の全体図である。 本発明のデータ構造を説明するための作業例である。 作業フローを定義するためのデータ構造例である。 作業フローに設定する権限の例である。 アクティビティを定義するためのデータ構造例である。 アクティビティに設定する権限の例である。 トレイを定義するためのデータ構造例である。 データオブジェクトを記憶するためのデータ構造例である。 実施形態に係る図書館情報管理システムの機能構成を示すブロック図である。 作業フローを選択するときの画面例である。 アクティビティを選択するときの画面例である。 発注データを入力するための画面例である。

符号の説明

１０…制御部、２０…作業選択部、３０…アクティビティ選択部、４０…機能実行部、６０…作業定義ファイル、７０…データオブジェクト記憶部。

Claims (6)

1. 図書館情報を管理するための複数の機能を有する図書館情報管理システムにおいて、実行可能な前記機能と対応するアクティビティに、当該アクティビティで処理されるデータの入力状態と出力状態を管理するトレイを定義し、このアクティビティを実行順に並べた作業フローを保持しておき、前記作業フローに定義されたアクティビティの順番で前記機能を実行させ、実行している作業フローに対するアクティビティの完了状況をアクティビティテーブルとして記録する制御部を有することを特徴とする図書館情報管理システム。
2. 請求項１に記載の図書館情報管理システムにおいて、データを受入可能な各アクティビティの状態を設定するアクティビティチェックテーブルを前記トレイに定義しておき、前記制御部は、入力状態あるいは出力状態を管理するトレイにデータを移動するときには、前記アクティビティテーブルと前記アクティビティチェックテーブとを照合し、トレイに移動可能かどうかを判定することを特徴とする図書館情報管理システム。
3. 請求項２に記載の図書館情報管理システムにおいて、データをトレイに移動するときに必要なデータ項目であるか否かの状態を設定するデータチェックテーブルを前記トレイに定義しておき、前記制御部は、入力状態あるいは出力状態を管理するトレイにデータが移動されたときに、前記データ中のデータ項目と前記データチェックテーブルとを照合して、必要なデータ項目が設定されているかどうかを判断することを特徴とする図書館情報管理システム。
4. 請求項１、２または３に記載の図書館情報管理システムにおいて、前記制御部は、データがトレイに移動したときに、トレイの状態を所定の連絡先へ通知することを特徴とする図書館情報管理システム。
5. 請求項１乃至４のいずれかに記載の図書館情報管理システムにおいて、ユーザあるいはユーザグループ毎に実行可能あるいは実行不可の権限を前記作業フローに設定しておき、前記制御部では、前記作業フローの権限に応じて、ユーザに指定された作業フローの実行を制御することを特徴とする図書館情報管理システム。
6. 請求項１乃至５のいずれかに記載の図書館情報管理システムにおいて、ユーザあるいはユーザグループ毎に参照あるいは実行の権限を前記アクティビティに設定しておき、前記制御部では、前記アクティビティの権限に応じて、ユーザに指定されたアクティビティの実行を制御することを特徴とする図書館情報管理システム。