(57)【要約】【課題】ワークフローの完結条件や継続条件を定義することなく、ワークフローを自由、かつ簡単に増減できるワークフローシステムを提供する。【解決手段】本実施形態に係るワークフローシステムは、製品の品質管理に係る業務の業務コードおよび親業務コードの組合せをフロー制約情報として予め記憶するフロー制約情報記憶手段と、業務においてユーザから入力された情報に、固有の情報番号および業務コードを付加した業務情報を記憶する業務情報記憶手段と、業務情報の業務コードとフロー制約情報の親業務コードとを比較し、その比較結果が一致するフロー制約情報の業務コードをユーザが次に選択可能な業務として画面上に順次提示するワークフロー構築手段と、を備える。【選択図】図２
2015087859.tif 000002
【特許請求の範囲】
【請求項１】
製品の品質管理に係る業務の業務コードおよび親業務コードの組合せをフロー制約情報として予め記憶するフロー制約情報記憶手段と、
前記業務においてユーザから入力された情報に、固有の情報番号および前記業務コードを付加した業務情報を記憶する業務情報記憶手段と、
前記業務情報の前記業務コードと前記フロー制約情報の前記親業務コードとを比較し、その比較結果が一致する前記フロー制約情報の前記業務コードを前記ユーザが次に選択可能な業務として画面上に順次提示するワークフロー構築手段と、
を備えることを特徴とするワークフローシステム。
【請求項２】
前記フロー制約情報が、同一の前記親業務コードに対して任意の数の前記業務コードを組み合わせて定義されている場合に、前記ワークフロー構築手段は、前記業務コードの各々について次に選択可能な業務を並列的に抽出することを特徴とする請求項１記載のワークフローシステム。
【請求項３】
前記ユーザが前記業務を完了した際に、その業務に係る前記情報番号と親業務に係る前記情報番号の組合せをフロー構築情報として順次記憶するフロー構築情報記憶手段を更に備えることを特徴とする請求項１または請求項２記載のワークフローシステム。
【請求項４】
製品の品質管理に係る業務の業務コードおよび親業務コードの組合せをフロー制約情報として予め記憶するフロー制約情報記憶ステップと、
前記業務においてユーザから入力された情報に、固有の情報番号および前記業務コードを付加した業務情報を記憶する業務情報記憶ステップと、
前記業務情報の前記業務コードと前記フロー制約情報の前記親業務コードとを比較し、その比較結果が一致する前記フロー制約情報の前記業務コードを前記ユーザが次に選択可能な業務として画面上に順次提示するワークフロー構築ステップと、
を有することを特徴とする動的ワークフローの構築方法。
【請求項５】
前記フロー制約情報が、同一の前記親業務コードに対して任意の数の前記業務コードを組み合わせて定義されている場合に、前記ワークフロー構築ステップにおいて、前記業務コードの各々について次に選択可能な業務を並列的に抽出することを特徴とする請求項４記載の動的ワークフローの構築方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、ワークフローシステムおよび動的ワークフローの構築方法に関する。
【背景技術】
【０００２】
一般に、製造業における製品の不具合調査は、複数のタスク・工程からなる所定の品質管理業務フロー（以下、ワークフローという。）に基づいて行われ、不具合の内容や調査の過程で判明した内容によって調査依頼先は様々に変更される。また、ワークフロー定義ファイルに工程の組み合わせを予め定義しておき、このワークフロー定義ファイルを参照しながら複数の工程を組み合わせることで、ワークフローを動的に変更可能とするワークフローシステムも知られている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平９−８１６３７号公報
【特許文献２】特開平１０−２７２０３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来型のワークフロー定義ファイルにおいて定義できる工程は、それぞれ独立した作業を組み合わせることを前提としている。例えば銀行業におけるワークフローでは、顧客業務に合わせてワークフロー定義ファイルを定義することで、顧客ごとの対応が可能である。これに対し、製造業におけるワークフローでは前工程の結果が後続の工程に影響を及ぼすことがある。しかし、工程を組み合わせたワークフローの中では処理を分岐させることは出来ない。このため、作業開始以降は終了するまで作業工程を変更することはできないという問題があった。
【０００５】
更に、製造業における不具合管理のワークフローでは、不具合の調査結果に応じて不具合対処の有無が変動し、作業の依頼先も一定に定まらず常に変更可能な状態におく必要があるため、ワークフローの終了点が一定ではない。これに対し、従来技術は、作業の開始点と終了点を必要とする構成のため、ワークフローが固定的になってしまうという問題があった。
【０００６】
このように、従来型のワークフローシステムは、事前に設定されたワークフローに基づいて処理を行うことを想定しており、処理の追加は可能であるが、大幅な変更、多数の分岐、分岐先での中断など、変更が大きく、事前設定自体が意味を持たないようなワークフロー定義に対しては効率的に管理できなかった。また、製造業の不具合調査では、ワークフローの完結条件や、継続条件が明確ではなく、そもそも定義自体が困難である。
【０００７】
そこで、本発明は、ワークフローの完結条件や継続条件を定義することなく、ワークフローを自由、かつ簡単に増減できるワークフローシステムおよび動的ワークフローの構築方法を提供することを解決しようとする課題とする。
【課題を解決するための手段】
【０００８】
本実施形態に係るワークフローシステムは、製品の品質管理に係る業務の業務コードおよび親業務コードの組合せをフロー制約情報として予め記憶するフロー制約情報記憶手段と、前記業務においてユーザから入力された情報に、固有の情報番号および前記業務コードを付加した業務情報を記憶する業務情報記憶手段と、前記業務情報の前記業務コードと前記フロー制約情報の前記親業務コードとを比較し、その比較結果が一致する前記フロー制約情報の前記業務コードを前記ユーザが次に選択可能な業務として画面上に順次提示するワークフロー構築手段と、を備える。
【図面の簡単な説明】
【０００９】
【図１】本発明の一実施形態に係るワークフローシステムが定義するワークフローの具体例を示す図である。
【図２】本発明の一実施形態に係るワークフローシステムの全体構成例を示す図。
【図３】不具合報告に対して生じる品質管理業務の広がりと深さを説明する図。
【図４】図２に示す業務情報データベースに格納される業務情報の具体例を示す図。
【図５】図２に示すフロー構築情報データベースに格納されるフロー構築情報の具体例を示す図。
【図６】図２に示すフロー制約情報データベースに格納されるフロー制約情報の具体例を示す図。
【図７】販売会社側アプリケーションサーバおよびメーカー側アプリケーションサーバにおける次業務提示処理の具体例を示すフローチャートである。
【図８】フロー制約情報の設定例を示す図。
【図９Ａ】図８に示すフロー制約情報に従って業務を進めた結果として作成されたフロー構築情報および業務情報の具体例を示す図。
【図９Ｂ】図８に示すフロー制約情報に従って業務を進めた結果として作成されたフロー構築情報および業務情報の具体例を示す図。
【図９Ｃ】図９Ａおよび図９Ｂに示す手順を階層表示で説明する図。
【発明を実施するための形態】
【００１０】
以下、本発明の実施形態について図面を用いて詳細に説明する。
【００１１】
図１は、本発明の一実施形態に係るワークフローシステム１が定義するワークフローの具体例を示す図である。ここでは、破線で囲まれた領域が本システムの適用範囲であり、顧客からのクレームに対して販売会社、メーカーおよび部品仕入先会社に３社に跨って種々の業務が連続的に実行されることが示されている。
【００１２】
図１において、販売された製品は顧客から販売会社へクレームという形で報告されると、販売会社では当該クレームが不具合報告（図１（１））として業務処置され、不具合報告がシステムに入力される。入力された不具合報告は、製品の製造元であるメーカーへ連携され、メーカー側では同種調査（図１（９））を経て受付業務（図１（２））の対象となる。受付業務以降は、不具合の原因調査をメーカー内の設計部署や製造・組立部署に依頼する調査依頼業務（図１（３））を行う。その後、設計部署や製造・組立部署は、調査（図１（４））を行い、その調査結果に基づいて調査依頼に対する回答業務（図１（１０））を行う。また、同じメーカー内でも不具合の内容によっては、調査回答の後に不具合が発生した同一部品に対する調査・対処の横展開（図１（５））、今後製造される部品に対する再発防止対策（図１（７））がなされる場合があることも示されている。
【００１３】
このように、製造業における不具合管理のワークフローでは、不具合の調査結果に応じて不具合対処の有無が変動し、その後の業務が分岐して行われることが多い。しかし、不具合管理に関連する複数の業務を個別に見ていくと、特定の業務の完了後に行うべき業務の候補は業種内容に応じて必然的に定まるため、予め定義することができる。そこで、本実施形態に係るワークフローシステム１では、先行する業務を親業務、親業務の次に行われるＮ個（Ｎ≧１）の業務を子業務とし、連続する業務の親子関係をフロー制約情報として予め定義することで、親業務をそれぞれ完了したタイミングで次に選択できる子業務をユーザに順次提示できる仕組みを提供する。
【００１４】
以下、ワークフローシステム１のシステム構成を具体的に説明する。図２は、本発明の一実施形態に係るワークフローシステム１の全体構成例を示す図である。同図に示されるように、ワークフローシステム１は、販売会社側業務システム２とメーカー側業務システム３が広域ネットワーク４を介して接続されて構築されている。
【００１５】
販売会社側業務システム２は、複数の販売会社側ユーザ端末５、販売会社側アプリケーションサーバ６および販売会社側データベースサーバ７がＬＡＮを介して接続されたシステムである。販売会社側ユーザ端末５は、販売会社の社員が業務に使用するパーソナルコンピュータ等の端末である。販売会社側アプリケーションサーバ６は、販売会社側データベースサーバ７を参照しつつ、販売会社側ユーザ端末５からの要求に応じた業務処理を行う各種のアプリケーションがインストールされたサーバコンピュータである。
【００１６】
メーカー側業務システム３は、複数のメーカー側ユーザ端末８、メーカー側アプリケーションサーバ９およびメーカー側データベースサーバ１０がＬＡＮを介して接続されたシステムである。メーカー側ユーザ端末８は、メーカーの社員が業務に使用するパーソナルコンピュータ等の端末である。メーカー側アプリケーションサーバ９は、メーカー側データベースサーバ１０を参照しつつ、メーカー側ユーザ端末８からの要求に応じた業務処理を行う各種のアプリケーションがインストールされたサーバコンピュータである。
【００１７】
また、販売会社側データベースサーバ７およびメーカー側データベースサーバ１０は、ユーザによって入力された業務情報を保持する領域である業務情報データベース７Ａ，１０Ａ、調査依頼や対処依頼がどの部署に対して行われたのか保持する領域であるフロー構築情報データベース７Ｂ，１０Ｂ、調査依頼や対処依頼などの業務を行う際に必要最低限の制約を保持する領域であるフロー制約情報データベース７Ｃ，１０Ｃをそれぞれ備えたサーバコンピュータである。販売会社側データベースサーバ７とメーカー側データベースサーバ１０は、それぞれ通信機能を備えており、異なるシステムを跨ってワークフローを実行するために、各システムにおける業務完了時など所定のタイミングでデータベース間の同期処理が行われるものとする。
【００１８】
例えば、不具合報告業務（図１（１））は販売会社側ユーザ端末５を使用し、帳票形式の入力フォームから不具合報告の入力が行われる。販売会社側ユーザ端末５から入力された情報は、ＬＡＮを介して販売会社側アプリケーションサーバ６に伝送され、販売会社側アプリケーションサーバ６で入力内容に対する入力必要条件のチェックを受けた後に、販売会社側データベースサーバ７の業務情報データベース７Ａに蓄積される。蓄積された業務情報は販売会社側データベースサーバ７が備える通信機能を用いて、広域ネットワーク４を経由して、メーカー側データベースサーバ１０の業務情報データベース１０Ａに移送される。
【００１９】
受付業務（図１（２））および調査依頼業務（図１（３））以降の業務を行うメーカー側業務システム３を利用するユーザは、メーカー側ユーザ端末８を使用してメーカー側アプリケーションサーバ９にアクセスし、販売会社側業務システム２から移送されて業務情報データベース１０Ａに蓄積されている業務情報に対して受付（図１（２））以降の業務を行う。受付（図１（２））以降の業務は、不具合報告（図１（１））の場合と同様に、メーカー側ユーザ端末８から帳票形式の入力・閲覧フォームを利用し、不具合の調査や調査結果、不具合原因に対する対処指示や対処結果などを入力する。なお、本システムでは必要な情報を特定のユーザにのみ閲覧させる、あるいは、調査・対処の内容によって業務を行うユーザが変動するため、調査・対処指示の依頼先は常に変動することが考慮されているものとする。
【００２０】
また、本実施形態では、製造業の不具合調査における一般的なワークフローが持つ完結条件や継続条件を持たないフローにも対応している。具体的には、各フローを構成する最小作業においても二次的フローが発生することに着目し、フロー制約を二段構成として捉え、分離・構成し直すことでフローの制御・管理を簡易化している。ここで、「二次的フロー」とは、不具合調査の依頼や回答が、調査依頼者およびその承認者、あるいは、調査回答者およびその承認者によって行われる情報の起票から承認までの作業を指す。この部分は、顧客による差異が少なく、フローの発生後に最終承認までの手順の増減が行われることもあるが、最終承認となる終点が必ず存在する。このため、終点に達した後、再度フローを発生させる必要があったとしても、終点に達したフローを復元させる必要はなく、新しくフローを発生させることで対応が可能である。
【００２１】
図３は、不具合報告に対して生じる品質管理業務の広がりと深さを説明する図である。縦方向の矢印Ａは調査依頼における依頼先の数や依頼回数など業務の広がりを表し、横方向の矢印Ｂは調査依頼に対する調査回答の状況や、調査回答に対する対処依頼指示の発生など業務の深さを表している。このように、業務情報、フロー構築情報およびフロー制約情報は階層化された形で表現することができ、この形をそれぞれの格納領域に分割して保持している。
【００２２】
図４は、図２に示す業務情報データベース７Ａ，１０Ａに格納される業務情報の具体例を示す図である。業務情報は、業務においてユーザから入力された情報に、ユーザが業務を完了した際に発行される固有の情報番号および業務コードを付加した情報である。ここでは、業務情報のデータ項目として、情報番号、業務コード、件名／概要、起票者、発行日、お客様名、調査の依頼先、回答期限などが例示されている。なお、本システムが扱う業務情報は、１００項目以上の車両情報や不具合発生情報から構成されるのが一般的であるため、上記以外にも販売会社名、陸運支局登録Ｎｏ、排気ガス記号、車両型式、エンジン型式、エンジン機号、不具合状況、修理内容、部位コード、現象コード、生産日、不具合レベル、プロジェクト番号などをデータ項目として備えているものとする。
【００２３】
図５は、図２に示すフロー構築情報データベース７Ｂ，１０Ｂに格納されるフロー構築情報の具体例を示す図である。ここでは、フロー構築情報のデータ項目として、ユーザが完了した業務に係る固有の情報番号と親業務に係る情報番号（親情報番号）を保持している。このフロー構築情報をキーとして上記業務情報を参照することにより、実際の調査依頼や対処依頼がどの設計部署、製造・組立部署に対して行われたのかを把握することができる。
【００２４】
図６は、図２に示すフロー制約情報データベース７Ｃ，１０Ｃに格納されるフロー制約情報の具体例を示す図である。ここでは、フロー制約情報が、業務定義とフロー定義に分かれて定義されている。業務定義のデータ項目としては、本システムで使用する顧客ごとに変動する業務の業務コードと業務名称の対応関係を保持している。フロー定義のデータ項目としては、業務コードとその親業務に係る業務コード（親業務コード）の親子関係を保持している。すなわち、業務定義において定義した業務を本システムにおいてどのような順序で業務を行えるかを階層型で保持している。
【００２５】
以下、上記のように構成されたワークフローシステム１の動作を図面に基づいて詳細に説明する。
【００２６】
図７は、販売会社側アプリケーションサーバ６またはメーカー側アプリケーションサーバ９のワークフロー構築アプリケーションがフロー制約情報に基づいて実行する次業務提示処理の具体例を示すフローチャートであり、図８は、フロー制約情報の設定例を示す図であり、業務コード同士の相関関係を図８（Ａ）では階層表示、図８（Ｂ）では親子表示、図８（Ｃ）ではデータテーブル表示で説明している。なお、販売会社側アプリケーションサーバ６とメーカー側アプリケーションサーバ９は共通のワークフロー構築アプリケーションを備えているため、ここでは販売会社側の業務を行った場合を例としてフローチャートの説明をする。
【００２７】
Ｓｔｅｐ１において、販売会社側アプリケーションサーバ６は、ユーザから実施要求された業務に対して親業務が存在するか否かを判定する。ここで、親業務が存在しないと判定した場合（Ｓｔｅｐ１：Ｎｏ）は、Ｓｔｅｐ２へ進む。これに対し、親業務が存在すると判定した場合（Ｓｔｅｐ１：Ｙｅｓ）は、Ｓｔｅｐ３へ進む。
【００２８】
Ｓｔｅｐ２において、販売会社側アプリケーションサーバ６は、フロー制約情報に含まれるフロー定義に基づいて親業務コードが存在しない業務の業務コードを取得し、Ｓｔｅｐ５へ進む。
【００２９】
Ｓｔｅｐ３において、販売会社側アプリケーションサーバ６は、親業務となる業務コードを業務情報の中から取得する。
【００３０】
Ｓｔｅｐ４において、販売会社側アプリケーションサーバ６は、Ｓｔｅｐ３で取得された親業務の業務コードを親業務コードとする業務コードをフロー定義（フロー制約情報）から取得し、Ｓｔｅｐ５へ進む。
【００３１】
Ｓｔｅｐ５において、販売会社側アプリケーションサーバ６は、Ｓｔｅｐ２あるいはＳｔｅｐ４で取得された業務コードに対応する業務をユーザが次に行える業務として販売会社側ユーザ端末８の画面上に選択可能に表示し、処理を終了する。
【００３２】
以下、ユーザが実際に業務を行った際に、上記図７のフローチャートに基づいてデータベース上で情報がどのように登録・更新されるのかを具体的に説明する。図９Ａおよび図９Ｂは、図８に示すフロー制約情報に従って業務を進めた結果として作成されたフロー構築情報および業務情報の具体例を示す図である。また、図９Ｃは、図９Ａおよび図９Ｂに示す手順を階層表示で説明する図である。
【００３３】
・手順１について
販売会社に所属するユーザは、顧客から報告されるクレーム情報を販売会社側ユーザ端末５を用いて販売会社側業務システム２へ登録する業務を行う。この業務は一番最初に行う業務であり、親となる業務は存在しない。そのため、図７のＳｔｅｐ１ではＮｏと判定され、続いてＳｔｅｐ２の処理を実行する。Ｓｔｅｐ２の処理では図８に示すフロー定義に基づいて親業務コードが存在しない業務コードＧ０１を取得する。続いて、Ｓｔｅｐ５によりユーザが行える業務は不具合報告として決定され、ユーザが不具合報告を完了した場合には、図９Ａの手順１に示すように、フロー構築情報および業務情報に情報番号Ｄ０００１のデータを登録する。ユーザが不具合報告を行う際に入力した情報、例えば不具合に関する車両情報や不具合発生情報（販売会社、陸運支局登録Ｎｏなど）は、情報番号と業務コードと共に業務情報の中に格納される。また、情報番号は意味を持たない乱数列で構成され、システム上で一意に特定するためのデータとして使用されユーザへは表示されないものとする。
【００３４】
・手順２について
不具合報告を行った後、業務情報は広域ネットワーク４を介して、メーカー側業務システム３へ転送・保存される。メーカーに所属するユーザは、メーカー側ユーザ端末８を使用し、不具合報告（情報番号：Ｄ０００１）に対する次の業務を行う。この際、不具合報告（情報番号：Ｄ０００１）を親の業務として扱うことになる。メーカー側アプリケーションサーバ９は、ワークフロー構築アプリケーションを実行し、Ｓｔｅｐ１の処理で情報番号Ｄ０００１について親となる業務有りと判定し、続いてＳｔｅｐ３の処理を実行する。Ｓｔｅｐ３では、手順１において業務情報データベース１０Ａに保存された情報番号Ｄ０００１の業務情報（不具合報告）の中から業務コードＧ０１を取得する。
【００３５】
続いて、Ｓｔｅｐ４により、フロー定義の親業務コードがＧ０１である業務コードＧ０２（不具合受付）を取得する。更に、Ｓｔｅｐ５において、ユーザが行える業務は不具合受付として決定し、ユーザが不具合受付を完了した場合には、フロー構築情報および業務情報に情報番号Ｄ０００２のデータを登録する。この際、フロー構築情報には情報番号Ｄ０００２の親情報番号として情報番号Ｄ０００１を関連付けた状態で登録する。ユーザが不具合受付を行う際に入力した、不具合レベル、情報レベル、プロジェクト番号などの属性情報は業務情報に格納する。
【００３６】
また、不具合受付を行った後、不具合受付（情報番号：Ｄ０００２）に対してユーザが次の業務を行う際には、メーカー側アプリケーションサーバ９のワークフロー構築アプリケーションは不具合受付（情報番号：Ｄ０００２）を親の業務として扱う。このため、Ｓｔｅｐ１の処理では情報番号Ｄ０００２の業務情報が存在することで親となる業務有りと判定し、Ｓｔｅｐ３の処理を実行する。Ｓｔｅｐ３では図９Ａの手順２で業務情報データベース１０Ａに保存した情報番号Ｄ０００２の業務情報（不具合受付）から業務コードＧ０２を取得する。続いて、Ｓｔｅｐ４の実行により、フロー定義の親業務コードがＧ０２である業務コードＧ０５,Ｇ０６,Ｇ０３を取得する。そして、後続のＳｔｅｐ５ではＳｔｅｐ４で取得した業務コードＧ０５,Ｇ０６,Ｇ０３によりユーザが行える業務を調査依頼、調査結果もしくは不具合回答と決定し、ユーザへどの業務を行うのか選択肢を提供する。このとき、ユーザは不具合報告や不具合受付に係る業務情報（情報番号：Ｄ０００１，Ｄ０００２）を参照することで、不具合報告の車両型式、車台番号、部位コード、現象コードなどの内容に応じて調査依頼、調査結果または不具合回答の業務を選択することが可能となる。例えば、不具合の内容が初見の内容の場合は、原因の調査依頼を発行する業務となる。これに対し、不具合の内容が既報と判断できる場合は、原因の調査依頼は行わずに既に調査済として調査結果または不具合回答の業務を行う事となる。ユーザがいずれかの業務を行った場合、上記の手順と同様にフロー構築情報および業務情報を登録する。
【００３７】
・手順３について
手順３では、ユーザが選択する業務を調査依頼とし、不具合報告の内容から社内の３つの部署に対して調査依頼を行う場合の登録内容を示している。手順３においてフロー構築情報には、調査依頼として新たに情報番号Ｄ０００３,Ｄ０００４,Ｄ０００５のデータを登録している。また、不具合受付が親業務となっているため、情報番号Ｄ０００２を親情報番号として関連付けた状態で格納している。更に、業務情報には情報番号Ｄ０００３,Ｄ０００４,Ｄ０００５に係る業務が調査依頼であることを示す業務コードＧ０５と共に調査依頼として入力された内容を件名／概要、依頼先、回答期限などのデータ項目として格納している。
【００３８】
手順３で示すように、複数の調査依頼先を選択して調査依頼発行業務を行った場合には、依頼先ごとの調査依頼としてフロー構築情報および業務情報を登録する。手順３では同一の不具合の内容から調査依頼先が３つの部署に存在することを想定しており、このように調査依頼が複数ある場合には調査の内容が同一でも、調査依頼された部署が回答を行う際に、回答内容が異なることを考慮し、依頼先ごとにフロー構築情報および業務情報を保持している。
【００３９】
また、手順３で示すように、実際に構築されたフロー構築情報の情報番号Ｄ０００３,Ｄ０００４,Ｄ０００５と情報番号Ｄ０００２の関係は、親業務である情報番号Ｄ０００２側から見ると１対３の関係になっており、図８に示すフロー制約情報（フロー定義）のいずれとも異なる階層状態を示すこととなるが、動的かつ柔軟なワークフローの構築が必要であるため、数的関係は制約に対する違反とは判断せずに、あくまでもＳｔｅｐ３〜５で導かれる業務コード同士の相関関係、すなわち、不具合受付の業務コードＧ０２を親業務コードとしてこれに関連する業務コードＧ０５（調査依頼），Ｇ０６（調査結果），Ｇ０３（不具合回答）が導かれることを制約として動作するものとする。
【００４０】
・手順４〜７について
手順４では調査依頼（情報番号：Ｄ０００３）に対して調査結果を回答する業務（情報番号：Ｄ０００６）、手順５では調査依頼（情報番号：Ｄ０００４）に対して調査依頼を更に行う業務（情報番号：Ｄ０００７）、手順６では手順５の調査依頼（情報番号：Ｄ０００７）に対する調査結果の回答業務（情報番号：Ｄ０００８）、手順７では調査依頼（情報番号：Ｄ０００２）に対して調査結果を回答する業務（情報番号：Ｄ０００９）をそれぞれ行った場合のデータベースの登録情報をそれぞれ示している。手順４〜手順７に示すようにデータベースへフロー構築情報および業務情報の登録を繰り返すことで、ユーザ自身が予め定めた制約の元でその時々に応じた業務を選択して業務を進めることができる。また、本システムでは不具合報告や不具合受付などの各業務を行う際に、それぞれ担当者から承認者の承認を経るまでの承認フローの仕組みを具備しているが、その承認フローを業務ごとに重ねていき、業務そのものの繰り返し回数や調査依頼の依頼先のような分岐数についての制限は持たせずにフロー制約情報の定義のみで対応している。
【００４１】
・手順８、９について
手順８、９は、不具合管理業務の区切りを示している。メーカーに所属するユーザは、販売会社側ユーザ端末５で登録された不具合報告の業務情報に対してメーカー側ユーザ端末８から不具合回答業務を行い、販売会社のユーザに対して結果を提示する。手順１とは逆に、メーカー側ユーザ端末８で登録された不具合回答業務の情報は、広域ネットワーク４を介して、販売会社側データベースサーバ７の業務情報データベース７Ａに格納され、販売会社側ユーザ端末５を利用して販売会社に所属するユーザも閲覧可能となる。
【００４２】
なお、不具合管理業務では、不具合回答までを一連の業務の区切りとして考えられるが、本システムの管理対象となる車両は市場でのライフサイクルが数年〜十数年と長いため、不具合の再発などにより原因調査・確認の業務も状況に応じて何度か繰り返さなければならない状況が生まれる。このため、本システムとしてワークフローの完了状態は持たせず、手順１〜３の操作により新たに業務情報を階層的に付加することによりユーザの意図したワークフローが提供される。
【００４３】
このように、本実施形態に係るワークフローシステムによれば、ユーザは予めフロー制約情報に定義された範囲の中で、自由に業務を行う事ができ、業務の継続・完結を任意の事由によって決定することが可能となる。すなわち、各企業における一定の業務ルール（制約）に従いつつワークフローを自由に増減して構築することができる。
【００４４】
なお、上記図４等に示す業務情報は、通常１００項目以上の車両情報や不具合発生情報から構成されるのが一般的である。このため、本システムではデータを保持するための枠のみ保持し、実際にどのような情報を格納・保持できるか否かはユーザによって定義可能なレイアウト情報として別々に管理すると好適である。業務情報を保持する領域と、業務情報の定義情報を分離管理することで、顧客の業務に合せて自由に選択・カスタマイズが可能となる。
【００４５】
また、上記実施形態では、不具合報告に対する品質管理業務のワークフローシステムとしているが、本ワークフローの考え方は、ワークフローが事前に設定しづらい業務、特に依頼先が多岐にわたる、依頼の階層が多層となる、あるいは、完結条件が分かりにくいなど、種々の条件がある業務にも流用可能である。また、従来の仕組みで実現されている単一フローとしての業務定義も可能である。このため、既に同様のワークフローシステムを導入している顧客にとっては、従来からの業務に影響を与えずに将来の業務拡張にも対応させる理由から、既存システムから本システムへ完全に置き換えることも可能である。すなわち、本システムは、下位互換性を兼ね備えている。
【００４６】
以上、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施することが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００４７】
１…ワークフローシステム、
２…販売会社側業務システム、
３…メーカー側業務システム、
４…広域ネットワーク、
５…販売会社側ユーザ端末、
６…販売会社側アプリケーションサーバ、
７…販売会社側データベースサーバ、
７Ａ，１０Ａ…業務情報データベース、
７Ｂ，１０Ｂ…フロー構築情報データベース、
７Ｃ，１０Ｃ…フロー制約情報データベース、
８…メーカー側ユーザ端末、
９…メーカー側アプリケーションサーバ、
１０…メーカー側データベースサーバ。
【図１】
2015087859.tif 000003
【図２】
2015087859.tif 000004
【図３】
2015087859.tif 000005
【図４】
2015087859.tif 000006
【図５】
2015087859.tif 000007
【図６】
2015087859.tif 000008
【図７】
2015087859.tif 000009
【図８】
2015087859.tif 000010
【図９Ａ】
2015087859.tif 000011
【図９Ｂ】
2015087859.tif 000012
【図９Ｃ】
2015087859.tif 000013