(57)【要約】【課題】フォームの入力やレイアウトなどの設定において、役割に応じた設定を可能にする。【解決手段】クライアントと、前記クライアントとネットワーク接続されるとともに、各種データテーブルを格納するデータベースと関連付けされるサーバであって、前記データベースに格納される前記各種データテーブルを管理するテーブル管理部を有するサーバと、を有する業務管理システムにおいて、前記クライアントは、フォームのレイアウト情報を作成するフォーム編集処理部を有し、前記サーバは、前記クライアントから受け取った前記レイアウト情報を、前記フォームを一意に識別するフォームＩＤとともに前記データベースに記憶することを特徴とする業務管理システムであって、前記フォーム編集処理部は、前記クライアントにおける入力操作により、前記クライアントへのログインユーザの属性や業務プロセスのノードと関連付けて前記フォームの設定を行うことを特徴とする業務管理システム。【選択図】図２３
2017199075.tif 000002
【特許請求の範囲】
【請求項１】
クライアントと、前記クライアントとネットワーク接続されるとともに、各種データテーブルを格納するデータベースと関連付けされるサーバであって、前記データベースに格納される前記各種データテーブルを管理するテーブル管理部を有するサーバと、を有する業務管理システムにおいて、前記クライアントは、フォームのレイアウト情報を作成するフォーム編集処理部を有し、前記サーバは、前記クライアントから受け取った前記レイアウト情報を、前記フォームを一意に識別するフォームＩＤとともに前記データベースに記憶することを特徴とする業務管理システムであって、
前記フォーム編集処理部は、
前記クライアントにおける入力操作により、前記クライアントから前記サーバにログインするログインユーザの属性と関連付けて前記フォームの設定を行うことを特徴とする業務管理システム。
【請求項２】
前記フォーム編集処理部は、
フォームの項目毎に、項目の表示、非表示を前記クライアントへのログインユーザの属性と関連付けて設定可能であることを特徴とする請求項１に記載の業務管理システム。
【請求項３】
前記フォーム編集処理部は、
業務プロセスのノード毎に、フォームを任意に設定可能であることを特徴とする請求項１に記載の業務管理システム。
【請求項４】
前記フォーム編集処理部は、
前記クライアントにおける入力操作により、項目の属性として、当該項目が入力必須か否か、編集禁止であるか否かを、前記ノード毎に設定可能であることを特徴とする請求項３に記載の業務管理システム。
【請求項５】
クライアントと、前記クライアントとネットワーク接続されるとともに、各種データテーブルを格納するデータベースと関連付けされるサーバであって、前記データベースに格納される前記各種データテーブルを管理するテーブル管理部を有するサーバと、を有する業務管理システムにおいて、前記クライアントは、フォームのレイアウト情報を作成するフォーム編集処理部を有し、前記サーバは、前記クライアントから受け取った前記レイアウト情報を、前記フォームを一意に識別するフォームＩＤとともに前記データベースに記憶することを特徴とする業務管理システムにおけるクライアントであって、
前記フォーム編集処理部は、
前記クライアントにおける入力操作により、前記クライアントから前記サーバにログインするログインユーザの属性と関連付けて前記フォームの設定を行うことを特徴とするクライアント。
【請求項６】
クライアントと、前記クライアントとネットワーク接続されるとともに、各種データテーブルを格納するデータベースと関連付けされるサーバであって、前記データベースに格納される前記各種データテーブルを管理するテーブル管理部を有するサーバと、を有する業務管理システムにおいて、前記クライアントは、フォームのレイアウト情報を作成するフォーム編集処理部を有し、前記サーバは、前記クライアントから受け取った前記レイアウト情報を、前記フォームを一意に識別するフォームＩＤとともに前記データベースに記憶することを特徴とする業務管理システムにおけるサーバであって、
前記クライアントにおける入力操作により、前記クライアントから前記サーバにログインするログインユーザの属性と関連付けて設定され、前記クライアントから前記フォームを一意に識別する業務に応じたフォームＩＤが選択されて送信要求されたレイアウト情報を前記クライアントに送信しフォームの表示を促すことを特徴とするサーバ。
【請求項７】
クライアントと、前記クライアントとネットワーク接続されるとともに、各種データテーブルを格納するデータベースと関連付けされるサーバであって、前記データベースに格納される前記各種データテーブルを管理するテーブル管理部を有するサーバと、を有する業務管理システムにおいて、前記クライアントは、フォームのレイアウト情報を作成するフォーム編集処理ステップを実行し、前記サーバは、前記クライアントから受け取った前記レイアウト情報を、前記フォームを一意に識別するフォームＩＤとともに前記データベースに記憶するステップを実行することを特徴とする業務管理システムにおける業務管理方法であって、
前記フォーム編集処理ステップは、
前記クライアントにおける入力操作により、前記クライアントから前記サーバにログインするログインユーザの属性と関連付けて前記フォームの設定を行うステップであることを特徴とする業務管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、業務プロセス管理技術に関し、特に、業務プロセスの役割に応じた入力表示制御機能等を構築することができる業務プロセス管理技術に関する。
【背景技術】
【０００２】
利用部門（下位組織、例えば、「部」、「課」など）をまたがるようなプロセスをもつ業務システムは、従来から、情報システム部門（上位組織、例えば、業務システムの開発・運用を行うＩＴ専門組織など）により開発、改良される（例えば、特許文献１、２参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平１０-１０５６２３号公報
【特許文献２】特開２００７-２９９３４０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上位組織に全ての業務システムの開発、改良等が委託されていると、特定の利用部門に特有の改良等を実現するためにも、下位組織単独における改良は難しく、上位組織と下位組織との連携が必要になるため、大がかりな作業となってしまうという問題があった。
【０００５】
特に、業務情報の入力フォームの管理、業務プロセスの管理において、以下のような業務要件を満たす入力フォームを開発するためには、制御処理や管理方式を設計、プログラミングする必要があり、設計やプログラミングなどシステム構築の専門知識を有する技術者が必要であるという課題が存在した。
【０００６】
（業務要件）
業務システムの入力フォームにおいて、
１）役割(承認者・部門など)で、フォームの表示項目・レイアウトを変えたい。
２）役割(承認者・部門など)で、フォームの表示項目毎に表示・入力可否を独自に設定、変更したい。
３）フォームの項目間の関連付け、例えば第１の項目の入力状態により第２の項目が必須入力であるか任意入力であるかなどの関連付けをしたい。
本発明は、上記の１）から３）などのような、フォームの入力やレイアウトなどの設定において、役割に応じた設定を可能にすることを目的とする。
【課題を解決するための手段】
【０００７】
本発明の一観点によれば、クライアントと、前記クライアントとネットワーク接続されるとともに、各種データテーブルを格納するデータベースと関連付けされるサーバであって、前記データベースに格納される前記各種データテーブルを管理するテーブル管理部を有するサーバと、を有する業務管理システムにおいて、前記クライアントは、フォームのレイアウト情報を作成するフォーム編集処理部を有し、前記サーバは、前記クライアントから受け取った前記レイアウト情報を、前記フォームを一意に識別するフォームＩＤとともに前記データベースに記憶することを特徴とする業務管理システムであって、前記フォ
ーム編集処理部は、前記クライアントにおける入力操作により、前記クライアントから前記サーバにログインするログインユーザの属性と関連付けて前記フォームの設定を行うことを特徴とする業務管理システムが提供される。
【０００８】
上記のフォームＩＤは、フォーム編集処理毎に固有に設定されるＩＤであり、システム中で一意である。これにより、クライアントによるフォーム設定において、例えば共通のフォームを編集した独自のフォームを設定することができる。
【０００９】
前記クライアントからサーバへログインする際の、ログインユーザの属性、より詳細には、業務管理システムの利用時の役割に応じたフォームの設定が可能である。
【００１０】
前記データベースには、前記クライアントからのフォーム作成要求の操作に基づいて前記サーバが作成した、前記ログインユーザのＩＤと前記フォームＩＤとを対応付けしたテーブルが設けられていることを特徴とする。
【００１１】
前記フォーム編集処理部は、フォームの項目毎に、項目の表示、非表示を前記クライアントへのログインユーザの属性と関連付けて設定可能であることを特徴とする。
【００１２】
前記フォーム編集処理部は、業務プロセスのノード毎に、フォームを任意に設定可能であることを特徴とする。
【００１３】
ログインユーザの属性によって提示できるフォームＩＤが制限される。
【００１４】
各クライアントが編集したレイアウト情報は、サーバと関連付けされるフォームＩＤにより、クライアント毎に識別されるため、複数のユーザが、他のユーザのフォーム変更の影響を受けずにデータ入力が可能である。また、業務に応じて、フォームを切り替えることが可能である。 
【００１５】
クライアント（利用部門の開発者）は、業務プロセスの下位組織の各ノードに、固有のフォームを任意に定義することができる。
【００１６】
前記データベースには、前記クライアントからの業務プロセス作成要求の操作に基づいて前記サーバが作成した、業務プロセスの各ノードを識別するノードＩＤに対応させて前記フォームＩＤを定義したノード定義テーブルが設けられていることを特徴とする。
【００１７】
前記フォーム編集処理部は、前記クライアントにおける入力操作により、項目の属性として、当該項目が入力必須か否か、編集禁止であるか否かを、前記ノード毎に設定可能であることを特徴とする。
【００１８】
本発明は、クライアントと、前記クライアントとネットワーク接続されるとともに、各種データテーブルを格納するデータベースと関連付けされるサーバであって、前記データベースに格納される前記各種データテーブルを管理するテーブル管理部を有するサーバと、を有する業務管理システムにおいて、前記クライアントは、フォームのレイアウト情報を作成するフォーム編集処理部を有し、前記サーバは、前記クライアントから受け取った前記レイアウト情報を、前記フォームを一意に識別するフォームＩＤとともに前記データベースに記憶することを特徴とする業務管理システムにおけるクライアントであって、前記フォーム編集処理部は、前記クライアントにおける入力操作により、前記クライアントから前記サーバにログインするログインユーザの属性と関連付けて前記フォームの設定を
行うことを特徴とするクライアントである。
【００１９】
また、本発明は、クライアントと、前記クライアントとネットワーク接続されるとともに、各種データテーブルを格納するデータベースと関連付けされるサーバであって、前記データベースに格納される前記各種データテーブルを管理するテーブル管理部を有するサーバと、を有する業務管理システムにおいて、前記クライアントは、フォームのレイアウト情報を作成するフォーム編集処理部を有し、前記サーバは、前記クライアントから受け取った前記レイアウト情報を、前記フォームを一意に識別するフォームＩＤとともに前記データベースに記憶することを特徴とする業務管理システムにおけるサーバであって、前記クライアントにおける入力操作により、前記クライアントから前記サーバにログインするログインユーザの属性と関連付けて設定され、前記クライアントから前記フォームを一意に識別する業務に応じたフォームＩＤが選択されて送信要求されたレイアウト情報を前記クライアントに送信しフォームの表示を促すことを特徴とするサーバである。
【００２０】
本発明の他の観点によれば、クライアントと、前記クライアントとネットワーク接続されるとともに、各種データテーブルを格納するデータベースと関連付けされるサーバであって、前記データベースに格納される前記各種データテーブルを管理するテーブル管理部を有するサーバと、を有する業務管理システムにおいて、前記クライアントは、フォームのレイアウト情報を作成するフォーム編集処理ステップを実行し、前記サーバは、前記クライアントから受け取った前記レイアウト情報を、前記フォームを一意に識別するフォームＩＤとともに前記データベースに記憶するステップを実行することを特徴とする業務管理システムにおける業務管理方法であって、前記フォーム編集処理ステップは、前記クライアントにおける入力操作により、前記クライアントから前記サーバにログインするログインユーザの属性と関連付けて前記フォームの設定を行うステップであることを特徴とする業務管理方法が提供される。
【発明の効果】
【００２１】
本発明によれば、業務情報のフォーム管理、業務プロセスの管理において、フォームの入力やレイアウトなどの設定において、役割に応じた設定が可能となる。
【図面の簡単な説明】
【００２２】
【図１Ａ】本発明の一実施の形態による業務プロセス管理システムの一構成例を示す機能ブロック図である。
【図１Ｂ】業務プロセス管理システムのうち、クライアントの一構成例を示す機能ブロック図である。
【図２】本実施の形態による業務管理システムのイメージの一例を示す図である。
【図３】フォームを新規に作成する際の処理の流れを示すフローチャート図である。
【図４】データベースＤＢ２１に、格納される項目とデータ（テーブル）の一例を示す図である。
【図５】フォームコントロールの一例を示す図である。
【図６Ａ】クライアント側で、フォームのレイアウト編集（作成）処理の流れを示すフローチャート図である。
【図６Ｂ】クライアントの表示部のＧＵＩを利用した操作等における項目群変数の一例を示す図である。
【図６Ｃ】クライアントの表示部のＧＵＩを利用した操作等を示す図である。
【図６Ｄ】クライアントの表示部のＧＵＩを利用した操作等を示す図である。
【図６Ｅ】クライアントの表示部のＧＵＩを利用した操作等を示す図である。
【図６Ｆ】クライアントの表示部のＧＵＩを利用した操作等を行う際の、部署とユーザの属性の例を示す図である。
【図６Ｇ】クライアントの表示部のＧＵＩを利用した操作等を行う際の、項目の属性、ユーザの属性等の設定例を示す図である。
【図６Ｈ】クライアントの表示部のＧＵＩを利用した操作等を示す図である。
【図６Ｉ】クライアントの表示部のＧＵＩを利用した操作等を示す図である。
【図６Ｊ】レイアウト情報のデータ例を示す図である。
【図６Ｋ】図６Ｊの文言（説明のためにわかりやすく表現した文言）と実際に用いられる文字列との対応関係を示す図である。
【図７】フォームのレイアウト情報を文字列で示した例えばＪＳＯＮ文字列の一例を示す図である。
【図８】レイアウト情報のより詳細な構成例を示す図である。
【図９Ａ】サーバ側でのフォームの保存処理の流れを示すフローチャート図である。
【図９Ｂ】データベースＤＢに、格納される項目とデータ（テーブル）の一例を示す図である。
【図９Ｃ】データベースＤＢに、格納される項目とデータ（テーブル）の一例を示す図である。
【図１０】役割毎のフォームの表示処理の流れの一例を示すフローチャート図である。
【図１１】処理に関連するテーブルの構成例を示す図である。
【図１２】図１１の処理後のクライアント側の詳細を示すフローチャート図である。
【図１３】図１１の処理後のクライアント側の詳細を示すフローチャート図である。
【図１４】図１１の処理後のクライアント側の詳細を示すフローチャート図である。
【図１５】役割毎のフォームの表示処理に沿った表示例と、関連入力制限処理に応じた表示例とを示した図である。
【図１６】ノードに起票というフォームを設定する例を示すイメージ図である。
【図１７】図１６の処理の流れの一例を示すフローチャート図である。
【図１８】処理に沿った各テーブルの構成を示す図である。
【図１９】プロセスの各ノードに、フォームを定義する処理の流れの一例を示すフローチャート図である。
【図２０】図１９の処理に沿った、各種テーブルの構成例を示す図である。
【図２１】回答フォームのレイアウトの詳細な例を示す図である。
【図２２】回答確認フォームのレイアウトの詳細な例を示す図である。
【図２３】プロセスの各ノードにフォームを設定する時の状態の一例を示す図である。
【図２４】回答フォームと回答確認フォームを示す図である。
【発明を実施するための形態】
【００２３】
本明細書において、業務プロセスとは、例えばノードで示した業務について、一連の業務の流れ（工程）の順番をノード間の矢印等で示したものであり、特に、１つのノードで示す業務に関して、他の部門において行われる業務の流れを示すサブノードを含むような複雑な業務プロセスにも対応できるようになっている。
【００２４】
また、業務帳票（フォーム）とは、業務情報を所定の形式で管理するためのフォームにより設計された文書であり、例えば、項目と複数の項目を含むＢＯＸ単位で管理することができる。
【００２５】
本明細書では、業務をフォームで管理する際の、取り扱う業務の大まかな単位をＢＯＸ
と称し、ＢＯＸ内には、複数の入力、表示される項目が、項目のタイトルと項目の内容とが関連付けられて配置されている。このような形態により、決め細かなフォーム設計と権限管理を自己の部門で行うことができる。
【００２６】
上位組織とは、例えば、以下の例では、システム開発部門などの上位の組織であり、例えば社内（部門、会社など）サーバ等により業務システム全体を管理する組織であり、下位組織とは、システム利用部門などの下位の組織であり、例えば、以下の例では、サーバにアクセスできるクライアント（部、課の端末など）により業務を管理する組織である。
役割とは、承認者や部門あるいはその権限などを指す。
【００２７】
以下に説明する技術において、開発部門が、ＩＴ専門部門だけでなく、本実施の形態による業務プロセス管理システムの利用部門になりうるようにした。
以下、本発明の実施の形態について図面を参照しながら詳細に説明する。
【００２８】
図１Ａは、本発明の一実施の形態による業務プロセス管理システムの一構成例を示す機能ブロック図である。図１Ｂは、業務プロセス管理システムのうち、クライアントの一構成例を示す機能ブロック図である。
【００２９】
本実施の形態による業務プロセス管理システムＡは、業務プロセス管理装置として機能するサーバ１と、例えばネットワークＮＴによりサーバ１と接続される複数のクライアント２３（２３−１、２３−２、…、２３−ｎ）と、例えばネットワークＮＴによりサーバ１と接続されるデータベースＤＢ２１と、を有している。
【００３０】
サーバ１は、全体の機能部を制御する制御部３と、文書等を管理する文書管理部５と、ＤＢ２１内のテーブルを管理するテーブル管理部７と、ネットワークを介してクライアントと通信を行う通信部１１と、各機能部の処理を制御部（ＣＰＵ）３に実行させるためのプログラム等を記憶するメモリ１７と、メモリ１７内への記憶を制御する記憶制御部１５と、を有している。サーバ１は、各部又は課などで共通であり、上位組織である部門により管理されている例を示す。
【００３１】
図１Ｂは、例えば、クライアント２３−１の一構成例を示す図である。各部、課でそれぞれ個別に使用しているクライアント２３−１は、例えば、各機能部を制御する制御部３１と、サーバ１と通信を行う通信部３３と、入力キーやタッチパネルなどの入力部３５と、ディスプレイなどの表示部３７と、各機能をコンピュータに実行させるためのプログラムやデータなどを記憶するメモリ４１と、を有している。クライアント２３−１としては、端末、例えば、パーソナルコンピュータ、スマートフォンなどを用いることができる。下位組織である各部門には、少なくとも１つのクライアントが配置されている。そこで、以下では、それぞれのクライアントが、異なる部門の業務管理を行うための情報処理装置として機能するとして説明を行う。
【００３２】
図２は、本実施の形態による業務管理システムのイメージの一例を示す図である。プロセス５１は、階層構造を有しており、上位組織のプロセスのノードに対して、下位組織のプロセス５１−１から５１−４が設定される。すなわち、業務管理のプロセス（処理）５１は、１つのノードに対して、例えば、開始ノード５１−１、回答ノード５１−２、回答確認ノード５１−３、終了ノード５１−４を有する。
【００３３】
そして、本実施の形態による業務管理システムでは、例えば、ノード毎に、異なるフォームを設定することができるように構成されている。例えば、ノード５１−２に対してはフォーム５３が、ノード５１−３に対してはフォーム５５が設定されており、ノードにより異なるフォームを設定できるように構成されている。
【００３４】
また、例えば、フォーム５３において、項目Ａに入力されると、項目Ｃが必須入力項目になるなど、項目間で入力状態により必須入力か任意入力かを制御することができる。
【００３５】
さらに、例えば、フォーム５５において、非社員がこのフォームを参照した場合には、項目Ｎについて非表示にするなど、役割でフォームの表示項目毎に表示・入力可否を変更できる。
【００３６】
この点については、以下において詳細に説明する。
以下、本発明の実施の形態による業務管理システムにおける、処理の流れについて詳細に説明する。
【００３７】
１）サーバ側でのフォーム新規作成時の処理について：
まず、サーバ側でのフォームを新規に作成する際の処理について説明する。図３は、フォームを新規に作成する際の処理の流れを示すフローチャート図である。図４は、データベースＤＢ２１に、格納される項目とデータ（テーブル）の一例を示す図である。図５は、フォームコントロールの一例を示す図である。
【００３８】
まず、ステップＳ１において、例えば、クライアント２３−１が、その入力部３５からの入力により、フォーム作成要求、例えば回答フォームの作成要求（信号）をサーバ１に送り、その要求をサーバ１が受け取る。
【００３９】
ステップＳ２において、サーバ１は、図４（ａ）に示すフォーム定義テーブルにフォーム名（この例では、回答）を登録する。ここで、フォーム定義テーブルは、フォームＩＤ欄と、フォームデータ格納テーブル名欄と、フォーム名欄と、レイアウト欄とを有しており、帳票の様式、例えば入力域の配置、ラベル配置、ボタンの位置などを定義するテーブルである。
【００４０】
ステップＳ３において、サーバ１は、図４（ｂ）に示すフォームデータ格納テーブルを作成する。フォームデータ格納テーブルは、データＩＤ欄と、フォームＩＤ欄と、プロセスＩＤ欄と、太線で囲まれた、プリセット列とを有している。ここで、データは値、情報であり、フォームは帳票であり、プロセスは工程である。プリセットとは、設定値などを前もって調整したものであり、また、前もって調整された設置値や、その組み合わせである。いわゆる、「初期設定」、「デフォルト設定」などと同義である。つまり、帳票上の入力域にデータを表示したり、ボタンを押して処理を進められるようにしたものである。
【００４１】
ステップＳ４において、サーバ１は、フォームデータ格納テーブルの列定義情報（図４（ｃ））を登録する。フォーム格納テーブルのプリセット列定義情報は、フォームＩＤ欄と、フォームデータ格納テーブル名と、列名と、列の表示名と、データ型と、フォームコントロールと、フォームでの使用有無の欄とを有している。
図４（ｂ）のプリセット列の情報が、図４（ｃ）の列名とリンクしている。
【００４２】
これらのテーブルは、サーバ１が自動的に作成して、データベースＤＢ２１に自動的に格納する。フォームコントロールがテキストボックスであれば、図５に示すように、テキストボックス（項目１）と、テキストエリア（項目２）と、リッチテキスト（項目３）と、の項目が作成され、より詳細には、テキストエリアに、右図のような例で示される種々の項目や尾端を有するフォームが作成される。
【００４３】
以上のように、１）フォーム新規作成時の処理によって、図４に示すテーブルが作成される。
【００４４】
２）フォームのレイアウト保存時の処理について：
次に、フォームのレイアウト保存時の処理について説明する。この処理は、クライアント２３−１側で、フォームのレイアウト作成（編集）処理を行い、クライアント２３−１側からのフォームのレイアウト編集処理の結果を受けて、サーバ１側において、フォームの保存処理を行うものである。
【００４５】
（クライアント側の新規フォーム作成処理）
図６Ａは、クライアント２３−１側で、フォーム編集処理部３１−１（制御部３１内）による、例えば図２に示すノード毎に行うこともできる、フォームのレイアウト編集（作成）処理の流れを示すフローチャート図である。図６Ｂから図６Ｉまでは、クライアント２３−１の表示部３７のＧＵＩを利用した操作等を示す図であり、図６Ｊは、レイアウト情報のデータ例、図６Ｋは、図６Ｊの文言（説明のためにわかりやすく表現した文言）と実際に用いられる文字列との対応関係を示す図である。この編集処理は、制御部における編集処理部において実行される。
【００４６】
図７は、フォームのレイアウト情報を文字列で示した例えばＪＳＯＮ文字列の一例を示す図であり、図８は、レイアウト情報のより詳細な構成例を示す図である。
【００４７】
図９Ａは、クライアント側で新規に作成されたフォームについて、サーバ側でフォームの保存を行う保存処理の流れを示すフローチャート図である。図９Ｂ、図９Ｃは、データベースＤＢ２１に、格納される項目とデータ（テーブル）の一例を示す図である。
【００４８】
以下に、図６Ａのフローチャート図と、ＧＵＩの説明レイアウト情報とその説明に沿って、クライアント２３−１側でのフォームのレイアウトの編集（作成）処理について詳細に説明する。クライアント２３−１側のフォームのレイアウトの編集（作成）処理は、主として、メモリ４１に格納されているプログラムを制御部（ＣＰＵ）３１により実行することにより行われる。専用ハードウェアによる処理であっても良い。すなわち、以下の処理は、以下では処理ステップとして記載されている各機能部により実行される。
【００４９】
クライアント２３−１の入力部３５等の操作に応じて処理が開始され（Ｓｔａｒｔ）、まず、ステップＳ１１において、レイアウト情報変数を用意する。レイアウト情報変数とは、例えば、図８の、ラベル、フィールド、コントロール等である。
【００５０】
次いで、ステップＳ１２において、レイアウト情報のフォームＩＤとして、例えば、“Ｆｏｒｍ００１”などのような一意の識別子を設定する（図６ＪのＳ１２の記載も参照）。
【００５１】
ステップＳ１３において、“項目群”変数を用意する（図６ＪのＳ１３の記載も参照）。“項目群”変数は、例えば、図６Ｂに示すような、タイトル、回答担当者、回答、回答日等である。
【００５２】
ステップＳ１４において、クライアント２３−１の表示部３７の表示画面に配置されている項目数分、例えば、図６Ｂのコントロールの配置におけるコントロールペインから目的のコントロールを選択し、図６Ｃに示すように、画面中央の領域にドラッグ＆ドロップして表示させた符号Ｌ１で示す表示項目数分（図６Ｃでは、５つ）の項目数分変数を準備し、各項目群変数分だけＳ１４からＳ２５までの処理手順を実行する。図６Ｊの１つの段落がこれらの処理手順の１つの手順に対応する。尚、ステップＳ１５からＳ２４までにおいては、説明をわかりやすくするため、「タイトル」を例にして説明している。
【００５３】
以下、タイトルに次いで、回答担当者、回答、回答日の順番にＳ１４からＳ２５までの処理を繰り返し行う。
【００５４】
（繰り返し処理の例）
ここでは、タイトルを例として繰り返し処理のうちの１つの処理を示す。以下の処理が、図６Ｊの第１段落（フィールドＩＤがＴｉｔｌｅ）の各行に対応する。
【００５５】
ステップＳ１５において、“項目”変数を用意する。
まず、ステップＳ１６において、“項目”フィールドＩＤに、例えば、“Ｔｉｔｌｅ”を設定する。
ステップＳ１７において、“項目”コントロールに、例えば、“テキスト（１行）”を設定する。
ステップＳ１８において、“項目”ラベルに、例えば、“タイトル”を設定する。
ステップＳ１９において、“項目”デフォルト値に、例えば、“”を設定する。
ステップＳ２０において、“項目”入力必須に、例えば、“はい（Ｙｅｓ）”を設定する。
ステップＳ２１において、“項目”最小値に、例えば、“０”を設定する。
ステップＳ２２において、“項目”最大値に、例えば、“１０００”を設定する。
ステップＳ２３において、“項目”表示条件に、例えば、“すべてのユーザで表示”を設定する。
ステップＳ２４において、項目群に項目を追加し、ステップＳ２５で全ての項目分の処理が終わるまで、ステップＳ１４に戻る処理を行う。
【００５６】
図６Ｄは、ステップＳ２０に関連する各項目の属性（入力必須、編集禁止など）を設定するためのＧＵＩの一例を示す図である。
【００５７】
まず、タイトルの属性は、クライアント２３−１の表示部３７に表示された図６Ｄの中央の表示領域のタイトル欄に対して、右上領域の画面のパーツ属性、フィールド属性の属性値の中から、ユーザが選択した項目を設定することができる（Ｔ１、Ｔ２）。
【００５８】
さらに、Ｔ３に示すように、右上領域の画面右下隅のチェックボックス（全てのユーザで表示）をチェックすると、例えば、図６Ｅに示すようなダイアログが表示される。すなわち、１）全てのユーザで表示、２）特定（入力可能）のユーザ選択、３）特定（入力可能）の部署選択、４）ユーザの属性が以下の値と一致しているユーザのみを表示（例えば、「社員種別」が「正社員」と一致している、など、表示条件を設定することができる（Ｔ３）。尚、４）のように、ユーザの属性を選択することができる（Ｔ４）と好ましい。
【００５９】
ここで、図６Ｆに示すように、部署の属性、ユーザの属性を、部署ＩＤで関連付けして設定することが可能である。この情報は、例えば、ＤＢ２１に記憶されていれば、サーバ１と適宜連絡をとって、クライアント２３−１側でも情報を適宜参照することもできる。
【００６０】
このようにして、図６Ｇに示すように、項目の属性、ユーザの属性をフォームに設定することが可能である。この図６Ｇのような各項目の属性は、クライアント２３−１のメモリ４１に記憶しておけば良い。
【００６１】
全ての項目分の処理が終わるまでステップＳ１４に戻る。
ステップＳ２６において、レイアウト情報に項目群変数を設定する。
ステップＳ２７において、レイアウト情報の関連入力制限に、“回答が設定ありの場合、回答日は入力必須”を設定する。
【００６２】
関連入力制限の設定例は、例えば、図６Ｈに示すように、クライアント２３−１の表示部３７において図６Ｄと同様の表示をさせ、例えば、関連入力制限のチェックボックスにチェックすることで（Ｔ５）、関連入力制限の追加のためのダイアログが表示され、例えば、フィールド１が条件を満たす場合、フィールド２は入力必須などの条件を任意に設定することができる。
【００６３】
ステップＳ２８において、レイアウト情報をシリアライズする。シリアライズとは、ＪａｖａＳｃｒｉｐｔ商標に用意されている公知の仕組みである。
ステップＳ２９において、ステップＳ２８でシリアライズされたレイアウト情報のＤＢ２１へのサーバ１側でのデータ保存を、通信部３３からサーバ１に要求する。
【００６４】
図６Ｉは、ステップＳ２８、Ｓ２９の処理を行わせるためのＧＵＩの一例を示す図であり、保存ボタンを押すことで、上記の処理により設定されたレイアウト情報を、ＪＳＯＮ文字列で作成することができる。
【００６５】
図７は、上記の処理により作成されたＪＳＯＮ文字列の一例を示す図である。図８は、ＪＳＯＮ文字列により決定されるレイアウト情報の詳細例を示す図である。
【００６６】
ＪＳＯＮ文字列では、ａｓＩＴＥＭの配列（[]）の順番によって、フォームを表示するコントロールの順番が決定する。また、関連入力制限では、ｆｉｅｌｄ１に指定した項目が、ｏｐｅｒａｔｏｒ１の操作（入力済みなど）を行ったとき、ｆｉｅｌｄ２に指定した項目の入力制限（必須など）がａｃｔｉｏｎに設定されている。
【００６７】
以下、図９Ａ等で説明するサーバ側の処理が行われ、ステップＳ３０で、サーバ１からの成功可否を受信する。これにより、クライアント側の処理が終了する。
【００６８】
但し、クライアント側では、レイアウト情報等は、編集処理中において一時的に作成されるが、作成されたレイアウト情報等は、サーバに送られて、ＤＢ２１において半永久的に保持されることとなる。
【００６９】
（サーバ側の処理）
図９Ａから図９Ｃまでは、サーバ側の処理と、それに伴う、データベースＤＢ２１内のテーブルの構成例を説明する図である。
図９Ａに示すように、クライアント側２３−１からデータ（レイアウト情報）の保存要求を受けて、図７（内容は図８参照）のＪＳＯＮ文字列により受け取り、処理が開始される（Ｓｔａｒｔ）。
【００７０】
ステップＳ３１において、受け取ったレイアウト情報、項目数分の繰り返し処理を行う（Ｓ３１からＳ３５）。
【００７１】
まず、ステップＳ３２において、図９Ｂ（ａ）に示す（＝図４（ｃ））フォームデータ格納テーブルの列定義テーブルの列名に、項目、フィールドＩＤが存在するか否かを判定する。ここでは、列名にＴｉｔｌｅ（図７、図８参照）が存在するか否かを判定する。
【００７２】
ステップＳ３２において、列名にＴｉｔｌｅが存在する場合には、ステップＳ３５に進む。ステップＳ３２において、列名にＴｉｔｌｅが存在しない場合には、ステップＳ３３に進む。
【００７３】
図９Ｂ（ａ）に示すように、実際には、列名にＴｉｔｌｅが存在しないので、ステップＳ３３に進み、図９Ｂ（ｂ）に示すフォームデータ格納テーブルに項目フィールドＩＤの
列（Ｔｉｔｌｅ）を追加する。
【００７４】
次いで、ステップＳ３４において、図９Ｂ（ｃ）に示すように、フォームデータ格納テーブルの列定義テーブルに、新たな項目（１行目、列名Ｔｉｔｌｅ、…）を追加する。
【００７５】
ステップＳ３５において、タイトル、回答者、回答、回答日について、同様に、ステップＳ３１からＳ３５までの処理を実行する。
【００７６】
次いで、ステップＳ３６において、図９Ｂ（ｄ）に示すフォーム定義テーブル（図４（ａ）のレイアウトに、上記のクライアント２３−１側の処理で作成されたＪＳＯＮ文字列によるレイアウト情報を追加して、ＤＢ２１に保存する。
【００７７】
ステップＳ３７において、レイアウト保存に関する成功可否情報をクライアント２３−１に返信（送信）する。
【００７８】
図９Ｃは、サーバ１側のレイアウト保存処理の終了後の、ＤＢ２１内に格納されるテーブルの一構成例を示す図である。
【００７９】
図９Ｃ（ａ）に示すように、処理後のフォームデータ格納テーブルの列定義テーブルは、クライアント２３−１側で処理された項目を追加した構成となっている。また、図９Ｃ（ｂ）に示すように、フォームデータ格納テーブルは、図９Ｂ（ｂ）に加えて、回答者、コンテンツ、回答日が加えられている。
【００８０】
さらに、図９Ｃ（ｃ）に示すように、フォーム定義テーブルは、レイアウト情報（ＪＳＯＮ文字列）を含む構成を有する。
【００８１】
上記の処理により、クライアント２３−１側で作成されたレイアウト情報（ＪＳＯＮ文字列）を、Ｆｏｒｍ００１のようなクライアント端末２３−１側で作成されたフォームＩＤと関連付けてサーバ１側に接続されるＤＢ２１内に格納することができる。すなわち、サーバ側でも、クライアント２３−１側で設定された図８に示すようなレイアウト情報を、作成したクライアント端末２３−１との共有情報として保持することができる。
【００８２】
クライアント２３−１とサーバ１とにおけるレイアウト情報の関連付けは、フォームＩＤにより行うことができる。
【００８３】
尚、クライアント側では、フォームＩＤと、フォームをユーザが特定できるような情報とを、サーバ−クライアント間の情報のやり取りに応じて作成しておくと良い。このようにすれば、クライアントからサーバへのフォームの要求において、どのフォームを要求するかをユーザが把握することができるため便利である。
【００８４】
３）フォームの表示時の処理について：
次に、２）で保存されたレイアウトに従って、サーバ１側において、クライアント端末２３−１でフォームを表示するためのデータをクライアント端末２３−１に返信するための処理について説明する。ここでは、クライアント２３−１側で設定された、役割毎のフォームの表示処理を例にして説明する。
【００８５】
図１０は、役割毎のフォームの表示処理の流れの一例を示すフローチャート図である。図１１は、処理に関連するテーブルの構成例を示す図である。図１２から図１４までは、図１１の処理後のクライアント側の詳細を示すフローチャート図である。
【００８６】
図１０に示すように、処理が開始され（Ｓｔａｒｔ）、ステップＳ４１において、サーバ１側において処理が開始されると、すなわち、ステップＳ４１において、クライアント２３−１側から、例えば、フォーム名「回答」を提示したフォームの表示の要求がサーバ１側で受信されると、ステップＳ４２において、図１１（ａ）に示すフォーム定義テーブルから、指定されたフォーム（例：「回答」）のデータ（レイアウト情報）をＤＢ２１から取得する。
【００８７】
ステップＳ４３において、図１１（ｂ）に示すフォームデータ格納テーブルから指定されたフォーム（Ｆｏｒｍ  ＩＤ＝ｆｏｒｍ００１）のデータ（フォームに表示するデータ）を作成する。
【００８８】
次いで、ステップＳ４４において、図１１（ｃ）に示すユーザテーブルからログインユーザのログインＩＤを含むユーザのデータを取得する。
【００８９】
次いで、ステップＳ４５において、ユーザのデータをクライアント２３−１に返却し、処理が終了する（ｅｎｄ）。
【００９０】
４）クライアント側の処理：
図１２から図１４までに、図１１の処理後のクライアント側の詳細な処理の流れを示す。これらの処理も、メモリ４１に格納されているプログラムを制御部（ＣＰＵ）３１により実行することで行われる。
【００９１】
図１２（ａ）に示すように、まず、図１２のステップＳ４５においてサーバ１から返却されたデータ（レイアウト情報：図７、図８参照）の解析処理とコントロール描画処理を開始する（ステップＳ１０１＝Ｓ４５）。
【００９２】
ステップＳ１０２において、コントロール数分だけループ処理を行う。ステップＳ１０３で、コントロール種別を判定する。
【００９３】
ステップＳ１０３の判定処理の結果、コントロール種別がテキストボックスであれば（ステップＳ１０４）、ステップＳ１０５において、画面のラベル付きでテキストボックスを描画する。次いで、ステップＳ１０６においてコントロールの属性を設定し（図１３参照）、ステップＳ１０７でデータを設定する。図１２（ｂ）は、この処理により描画される例を示す図である。
【００９４】
ステップＳ１０３の判定処理の結果、コントロール種別がテキストエリアであれば（ステップＳ１０８）、ステップＳ１０９において、画面のラベル付きでテキストエリアを描画する。次いで、ステップＳ１１０においてコントロールの属性を設定し（図１３参照）、ステップＳ１１１でデータを設定する。
【００９５】
ステップＳ１０３の判定処理の結果、コントロール種別がｄａｔｅｔｉｍｅであれば（ステップＳ１１２）、ステップＳ１１３において、画面のラベル付きで日付を描画する。次いで、ステップＳ１１４においてコントロールの属性を設定し（図１３参照）、ステップＳ１１５でデータを設定する。
【００９６】
ステップＳ１０３からＳ１１５までの処理をループ処理し（ステップＳ１１６）、ステップＳ１１７で関連入力制限を設定する（図１４を参照）。
【００９７】
図１３に示すように、ステップＳ１２１のコントロール属性の設定処理（Ｓ１０６，Ｓ１１０，Ｓ１１４）は、まず、ステップＳ１２２で、コントロールの高さを設定する（Ｈ
ｅｉｇｈｔ）。次いで、ステップＳ１２３で、編集可否（ＦＡＬＳＥ）を設定する（Ｄｉｓａｂｌｅ）。次いで、ステップＳ１２４で、表示可否を設定する（Ｖｉｓｉｂｌｅ）。次いで、ステップＳ１２５で、初期値を設定する（ＤｅｆａｕｌｔＶａｌｕｅ）。次いで、ステップＳ１２６で、入力制限を設定する（Ｍｉｎｌｅｎｇｔｈ，Ｍａｘｌｅｎｇｔｈ）。次いで、ステップＳ１２７で、必須かどうかを設定する（Ｒｅｑｕｉｒｅｄ）。
【００９８】
尚、ステップＳ１２４では、ステップＳ１２８で表示可否を判定し、ステップＳ１２９に示すように表示可否＝ａｌｌ（誰でも表示）であれば、ステップＳ１３０でＶｉｓｉｂｌｅ＝ｔｒｕｅ（表示）とし、ステップＳ１３１に示すように、表示可否＝ｎｏｎｅ（誰でも非表示）であれば、ステップＳ１３２でＶｉｓｉｂｌｅ＝ｆａｌｓｅ（非表示）とし、ステップＳ１３３のように表示可否＝条件式であれば、ステップＳ１３４で条件式に該当するか否かを判定し、条件式に該当すれば、ステップＳ１３５でＶｉｓｂｌｅ＝ｔｒｕｅ（表示）とし、条件式に該当しない場合には、ステップＳ１３６で、Ｖｉｓｉｂｌｅ＝ｆａｌｓｅ（非表示）と設定する。
【００９９】
これらの処理により、コントロール属性の設定をクライアント２３−１側で行うことができる。
【０１００】
図１４は、クライアント側での関連入力制限の設定処理の詳細な例を示す図である（図８の関連入力制限参照）。まず、ステップＳ１４１（＝Ｓ１１７）における関連入力制限の設定処理では、ステップＳ１４２において、ｆｉｅｌｄＩｄ  １に指定されているコントロールを取得し、コントロール１とする。ステップＳ１４３において、ｆｉｅｌｄＩｄ
２に指定されているコントロールを取得し、コントロール２とする。ステップＳ１４４において、ｏｐｅｒａｔｏｒ１を解析する。ステップＳ１４５のように、ｏｐｅｒａｔｏｒ１＝ｉｎｐｕｔｔｅｄであれば、ステップＳ１４６において、コントロール１のフォーカスアウトイベントで、コントロール１が入力状態ならコントロール２の必須入力(Ｒｅｑｕｉｒｅｄ)をＴＲＵＥに設定する。未入力状態ならコントロール２の必須入力(Ｒｅｑｕｉｒｅｄ)をＦａｌｓｅに設定する。
【０１０１】
ステップＳ１４７のように、ｏｐｅｒａｔｏｒ１＝ｎｏｎｉｎｐｕｔｔｅｄであれば、ステップＳ１４８において、コントロール１のフォーカスアウトイベントで、コントロール１が未入力状態ならコントロール２の必須入力(Ｒｅｑｕｉｒｅｄ)をＴＲＵＥに設定する。入力状態ならコントロール2の必須入力(Ｒｅｑｕｉｒｅｄ)をＦａｌｓｅに設定する。
【０１０２】
以上のようにして、例えば、「フィールドＩＤのＣｏｎｔｅｎｔが入力済みならＡｎｓｅｗｅｒＤａｔｅ（回答日）が必須入力などというような、複数の入力項目同士の相互制限事項である関連入力制限を設定することができる。
【０１０３】
図１５は、役割毎のフォームの表示処理に沿った表示例と、関連入力制限処理に応じた表示例とを示した図であり、図１５（ａ）が、役割が正社員の場合の回答フォームの表示例であり、顧客が株式会社Ａであることが表示されている。一方、図１５（ｂ）が、役割が正社員でない場合の回答フォームの表示例であり、顧客が株式会社Ａであることは表示されていない（非表示）。このようにすることで、例えば、役割上不要な情報を非表示にすることができる。
【０１０４】
さらに、回答が入力状態である場合には、回答日は入力必須の設定とするなど、関連入力制限処理に応じた表示とすることが可能である。
【０１０５】
（プロセスの各ノードにフォームを設定する処理例）
次に、サーバ１側における、プロセスの各ノードにフォームを設定する処理例について説明する。図１６は、ノードに起票というフォームを設定する例を示すイメージ図である。
【０１０６】
図１７は、その処理の流れの一例を示すフローチャート図であり、図１８は、処理に沿った各テーブルの構成を示す図である。
【０１０７】
まず、処理が開始すると（Ｓｔａｒｔ）、クライアント２３−１から、プロセス名を含むプロセスの作成要求を受信する（ステップＳ５１）。
【０１０８】
ステップＳ５２において、図１８（ａ）のプロセス定義テーブルに、プロセス名（例として、問い合わせ回答）を登録する。ステップＳ５３において、ノード定義テーブルに、開始／起票／完了ノードを、ノードＩＤ、プロセスＩＤとともに登録する（図１６参照）。ステップＳ５４において、以下の処理を行う。
【０１０９】
図１８（ｃ）のエッジ定義テーブルにノードの前後関係を登録（図１８（ｂ）も参照）。
・先行ノード：開始ノード、後続ノード：起票ノード
・先行ノード：起票ノード、後続ノード：完了ノード
次いで、クライアント２３−１に、成功可否情報を送信し、クライアント２３−１が、その情報を受信する。
以上の処理により、プロセスの新規作成を行うことができる。
【０１１０】
次に、プロセスの各ノードに、フォームを定義する処理について図２およびその説明も参照しながら詳細に説明する。
【０１１１】
図１９は、当該処理の流れの一例を示すフローチャート図である。図２０は、図１９の処理に沿った、各種テーブルの構成例を示す図である。
【０１１２】
まず、ステップＳ６１において、例えば、クライアント２３−１が、その入力部３５からの入力により、プロセスの作成要求をサーバ１に送り、その要求をサーバ１が受け取る。
【０１１３】
次に、ステップＳ６２において、指定されたプロセスが図２０（ａ）に示すプロセス定義テーブルに存在するかどうかをチェックする。指定されたプロセスが存在しない場合は、エラー通知をクライアントに送信する。指定されたプロセスが存在する場合は（Ｐｒｏｃｅｓｓ（プロセス）００１）、次のステップＳ６３に進む。
【０１１４】
ステップＳ６３において、指定されたノード（図２も参照）が図２０（ｅ）のノード定義テーブルに存在するかどうかをチェックする。指定されたノードが存在しない場合は、エラー通知をクライアントに送信する。指定されたノードが存在する場合は（例えば、回答など）、次に進む。ここで、図２０（ｂ）と図２０（ｃ）とは、太線で囲まれた列名と列とがリンクしている。
【０１１５】
ステップＳ６４において、指定されたフォーム（フォームＩＤ）が、図２０（ｄ）のフォーム定義テーブルに存在するかどうかをチェックする。指定されたフォーム（フォームＩＤ）が存在しない場合は、エラー通知をクライアントに送信する。指定されたフォーム（フォームＩＤ）が存在する場合は（例えば、Ｆｏｒｍ００１）、次に進む。尚、フォーム定義テーブルのレイアウトには、ＪＳＯＮ文字列がＤＢ２１に登録されている。
【０１１６】
ステップＳ６５において、図２０（ｅ）に示すノード定義テーブルに指定されたフォーム（例えば、Ｆｏｒｍ００１）を登録する。
次いで、ステップＳ６６において、成功可否をクライアント２３−１へ送信し、処理が終了する（Ｅｎｄ）。
【０１１７】
図２１は回答フォームのレイアウトの詳細な例を示す図である。レイアウト情報は、ＪＳＯＮ文字列のキー名とＪＳＯＮ文字列の値とが含まれている。
図２２は回答確認フォームのレイアウトの詳細な例を示す図である。レイアウト情報は、ＪＳＯＮ文字列のキー名とＪＳＯＮ文字列の値とが含まれている。
【０１１８】
図２３は、プロセスの各ノードにフォームを設定する時の状態の一例を示す図である。
図２３に示すように、各フォームに表示するデータは同じである。相違点は、入力必須項目や編集禁止項目の設定値である。例えば、回答フォームでは、タイトルが必須入力、確認者／差し戻し理由が編集禁止項目になっている。
回答確認フォームでは、確認者が必須入力、タイトル／回答担当者／回答／回答日が編集禁止項目になっている。
【０１１９】
図２４は、回答フォームと回答確認フォームを示す図である。
回答フォームと回答確認フォームが参照しているフィールドＩＤはともに同じである。つまり、各フォームともに同じデータが表示される。回答フォームと回答確認フォームでは、編集可否や必須入力項目を異なるようにすることができる。
【０１２０】
以上のように、プロセスの各ノードに、フォームＩＤで識別される任意のフォームを定義することができる。
【０１２１】
以上に説明したように、本実施の形態によれば、業務情報のフォーム管理、業務プロセスの管理において、フォームの入力やレイアウトなどを、下位組織において一意に設定することが可能となる。
【０１２２】
そして、サーバにクライアントが作成した下位組織のフォームをフォームＩＤに基づいて永続的に記憶させることがきる。
【０１２３】
従って、クライアントは、フォームＩＤに基づいて、いつでも、サーバ側から、クライアント独自（下位組織独自の）のフォームを取得して表示、入力等することができる。
【０１２４】
クライアントには、フォームＩＤと名称などの、形式的な情報のみを記憶させれば良いので、業務が複雑になっても、サーバ側（ＤＢ）にレイアウト情報を保存しておけば、クライアントにおけるメモリの記憶領域の占有を抑制することができる。
【０１２５】
以上に説明したように、本実施の形態によれば、業務情報のフォーム管理、業務プロセスの管理において、フォームの入力やレイアウトなどの下位組織（利用部門）における設定が可能となる。
【０１２６】
つまり業務システムを開発するときに、今まではＩＴ専門技術を保有した技術者（情報システム部門）しかできなかったことが、ＩＴ専門技術を保有していない、業務システムを実際に利用する部門でも開発（フォーム定義、プロセス定義、マスタ定義）できるようになった。そして、フォーム定義とプロセス定義そして文書管理が一体となって業務システムを開発でき、その中でも「業務プロセスの役割に応じたフォーム定義」「フォームの表示・入力可否制御処理」「フォームの各項目間の制御処理」が簡単に定義できるようになった。すなわち、利用者が開発環境を編集することが容易になる。
【０１２７】
処理および制御は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）やＧＰＵ（Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）によるソフトウェア処理、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）やＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）によるハードウェア処理によって実現することができる。
【０１２８】
上記の実施の形態において、添付図面に図示されている構成等については、これらに限定されるものではなく、本発明の効果を発揮する範囲内で適宜変更することが可能である。その他、本発明の目的の範囲を逸脱しない限りにおいて適宜変更して実施することが可能である。
【０１２９】
また、本発明の各構成要素は、任意に取捨選択することができ、取捨選択した構成を具備する発明も本発明に含まれるものである。
【０１３０】
また、本実施の形態で説明した機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより各部の処理を行ってもよい。尚、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。
【産業上の利用可能性】
【０１３１】
本発明は、業務プロセス管理システムとして利用可能である。
【符号の説明】
【０１３２】
Ａ…業務プロセス管理システム、１…サーバ、２１…データベースＤＢ、２３…クライアント、３１…制御部、３１−１…フォーム編集（作成）処理部、３３…通信部、３５…入力部、３７…表示部、４１…メモリ。
【図１Ａ】
2017199075.tif 000003
【図１Ｂ】
2017199075.tif 000004
【図２】
2017199075.tif 000005
【図３】
2017199075.tif 000006
【図４】
2017199075.tif 000007
【図５】
2017199075.tif 000008
【図６Ａ】
2017199075.tif 000009
【図６Ｂ】
2017199075.tif 000010
【図６Ｃ】
2017199075.tif 000011
【図６Ｄ】
2017199075.tif 000012
【図６Ｅ】
2017199075.tif 000013
【図６Ｆ】
2017199075.tif 000014
【図６Ｇ】
2017199075.tif 000015
【図６Ｈ】
2017199075.tif 000016
【図６Ｉ】
2017199075.tif 000017
【図６Ｊ】
2017199075.tif 000018
【図６Ｋ】
2017199075.tif 000019
【図７】
2017199075.tif 000020
【図８】
2017199075.tif 000021
【図９Ａ】
2017199075.tif 000022
【図９Ｂ】
2017199075.tif 000023
【図９Ｃ】
2017199075.tif 000024
【図１０】
2017199075.tif 000025
【図１１】
2017199075.tif 000026
【図１２】
2017199075.tif 000027
【図１３】
2017199075.tif 000028
【図１４】
2017199075.tif 000029
【図１５】
2017199075.tif 000030
【図１６】
2017199075.tif 000031
【図１７】
2017199075.tif 000032
【図１８】
2017199075.tif 000033
【図１９】
2017199075.tif 000034
【図２０】
2017199075.tif 000035
【図２１】
2017199075.tif 000036
【図２２】
2017199075.tif 000037
【図２３】
2017199075.tif 000038
【図２４】
2017199075.tif 000039