特許 6857989 処理フロー管理システム及び処理フロー管理方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6857989

(24)【登録日】2021年3月25日

(45)【発行日】2021年4月14日

(54)【発明の名称】処理フロー管理システム及び処理フロー管理方法

(51)【国際特許分類】

   G06Q 10/10 20120101AFI20210405BHJP

【ＦＩ】

   G06Q10/10 310

【請求項の数】4

【全頁数】14

(21)【出願番号】特願2016-188722(P2016-188722)

(22)【出願日】2016年9月27日

(65)【公開番号】特開2018-55277(P2018-55277A)

(43)【公開日】2018年4月5日

【審査請求日】2019年6月6日

(73)【特許権者】

【識別番号】514275772

【氏名又は名称】三菱重工航空エンジン株式会社

(74)【代理人】

【識別番号】110002147

【氏名又は名称】特許業務法人酒井国際特許事務所

(72)【発明者】

【氏名】政井 佑介

(72)【発明者】

【氏名】花田 忠之

【審査官】 松田 岳士

(56)【参考文献】

【文献】 特開２００２−２３０２４７（ＪＰ，Ａ）

【文献】 特開２０１３−００３８８４（ＪＰ，Ａ）

【文献】 特開２００２−０３２５４４（ＪＰ，Ａ）

【文献】 特開２０１０−１４６０９１（ＪＰ，Ａ）

【文献】 特開２０１０−１２９０６５（ＪＰ，Ａ）

【文献】 特開２００２−２３０２５０（ＪＰ，Ａ）

【文献】 特開２０００−３４８１１１（ＪＰ，Ａ）

【文献】 特開２００２−２６９３０５（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００２／０１８４０７０（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００−９９／００

(57)【特許請求の範囲】

【請求項1】

複数のシステムとデータの送受信を行って処理フローを管理する処理フロー管理システムであって、
複数の処理が設定された順序で組み合わさった処理フローを読み出す処理フロー読出し部と、
前記処理フローに基づき、前記複数の処理から、これから実行する処理である現在実行処理を決定する処理決定部と、
前記現在実行処理に基づき前記複数のシステムから対象システムを選択し、前記対象システムに前記現在実行処理を実行する旨の指令を出力する処理指令部と、
前記対象システムからデータを受信して、そのデータが前記現在実行処理を実行した旨の実行データであるかを判断する実行データ判断部と、
前記現在実行処理を開始したタイミングである開始タイミング、前記実行データを受信して前記現在実行処理を終了したタイミングである終了タイミング、及び前記実行データを送信した前記対象システムを、前記現在実行処理に関連付けて履歴情報として記憶する履歴記憶部と、
前記履歴情報に基づき、前記処理を終了するのに要する時間を算出する履歴分析部と、
を有し、
前記履歴分析部は、前記処理を終了するのに要する時間から、前記処理フローの処理の順番を入れ替える、
処理フロー管理システム。

【請求項2】

前記複数のシステムは、互いに異なる処理を実行し、かつ、互いにデータの通信が遮断されている、請求項１に記載の処理フロー管理システム。

【請求項3】

新しい処理フローを実行する旨の処理要求を取得する処理要求取得部と、
複数種類の処理フローを記憶する処理フロー記憶部と、を更に有し、
前記処理フロー読出し部は、前記処理要求取得部が取得した処理要求と前記処理フロー記憶部が記憶する処理フローとが一致した場合に、前記処理フロー記憶部から一致した処理フローを読み出す、請求項１又は請求項２に記載の処理フロー管理システム。

【請求項4】

複数のシステムとデータの送受信を行って処理フローを管理する処理フロー管理方法であって、
複数の処理が設定された順序で組み合わさった処理フローを読み出す処理フロー読出しステップと、
前記処理フローに基づき、前記複数の処理から、これから実行する処理である現在実行処理を決定する処理決定ステップと、
前記現在実行処理に基づき前記複数のシステムから対象システムを選択し、前記対象システムに前記現在実行処理を実行する旨の指令を出力する処理指令ステップと、
前記対象システムからデータを受信して、そのデータが前記現在実行処理を実行した旨の実行データであるかを判断する実行データ判断ステップと、
前記現在実行処理を決定したタイミングである立ち上げタイミング、前記実行データを受信したタイミングである終了タイミング、及び前記実行データを送信した前記対象システムを、前記現在実行処理に関連付けて履歴情報として記憶する履歴記憶ステップと、
前記履歴情報に基づき、前記処理を終了するのに要する時間を算出する履歴分析ステップと、
を情報処理装置が実行し、
前記履歴分析ステップにおいて、前記処理を終了するのに要する時間から、前記処理フローの処理の順番を入れ替える、
処理フロー管理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、処理フロー管理システム及び処理フロー管理方法に関する。

【背景技術】

【0002】

物流システムをある１つの企業の内部に限定することなく、複数の企業間で統合的に構築された物流システムを、サプライチェーンと呼ぶ場合がある。サプライチェーンは、例えば複数の部品から構成される１つの製品を生産する場合に用いられる。この場合、一つの企業が自身の業務（例えば１つの部品の生産）を完了した後に、他の企業が別の業務を実行して、１つの製品を作り上げる。言い換えれば、サプライチェーンは、各企業などが担当する複数の処理が、順番に組み合わさった処理フローであるということができる。

【0003】

このようなサプライチェーン（処理フロー）では、各企業や各部署同士が、データのやり取りを行う必要があるため、近年、サプライチェーン全体を統括的に管理することが求められている。例えば特許文献１には、サプライチェーン全体を管理するサプライチェーンマネージメントシステムについて記載されている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００７−２６２８０号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

ところで、サプライチェーン（処理フロー）において業務（処理）を行う各企業や各部署は、自身の担当する業務を遂行するために、コンピュータシステムを利用している場合が多い。これらのシステムは、例えば他の企業からはアクセスができなかったりするため、処理フロー（サプライチェーン）の統合的な管理が困難となる。統合的な管理が困難になると、例えばリードタイムの削減など、処理フローの改善が困難となるおそれがある。

【0006】

従って、本発明は、複数のシステムが用いられている場合においても、処理フロー全体を適切に管理できる処理フロー管理システム及び処理フロー管理方法を提供することを目的とする。

【課題を解決するための手段】

【0007】

上述した課題を解決し、目的を達成するために、本開示に係る処理フロー管理システムは、複数のシステムとデータの送受信を行って処理フローを管理する処理フロー管理システムであって、複数の処理が設定された順序で組み合わさった処理フローを読み出す処理フロー読出し部と、前記処理フローに基づき、前記複数の処理から、これから実行する処理である現在実行処理を決定する処理決定部と、前記現在実行処理に基づき前記複数のシステムから対象システムを選択し、前記対象システムに前記現在実行処理を実行する旨の指令を出力する処理指令部と、前記対象システムからデータを受信して、そのデータが前記現在実行処理を実行した旨の実行データであるかを判断する実行データ判断部と、前記現在実行処理を開始したタイミングである開始タイミング、前記実行データを受信して前記現在実行処理を終了したタイミングである終了タイミング、及び前記実行データを送信した前記対象システムを、前記現在実行処理に関連付けて履歴情報として記憶する履歴記憶部と、を有する。

【0008】

この処理フロー管理システムは、処理毎の進捗状況を履歴情報として記憶する。例えば管理者は、履歴情報を参照して、処理毎の進捗状況を容易に確認することが可能となるため、処理フロー全体を適切に管理し、かつ、各処理を改善することも容易となる。従って、この処理フロー管理システムは、複数のシステムが用いられている場合においても、処理フロー全体を適切に管理することが可能となる。

【0009】

前記処理フロー管理システムにおいて、前記複数のシステムは、互いに異なる処理を実行し、かつ、互いにデータの通信が遮断されていることが好ましい。この処理フロー管理システムは、このような場合のおいても、処理フロー全体を適切に管理することが可能となる。

【0010】

前記処理フロー管理システムは、前記履歴情報に基づき、前記処理を終了するのに要する時間を算出する履歴分析部を更に有することが好ましい。この処理フロー管理システムは、処理を終了するのに要する時間を算出するため、処理を適切に改善することができる。

【0011】

前記処理フロー管理システムは、新しい処理フローを実行する旨の処理要求を取得する処理要求取得部と、複数種類の処理フローを記憶する処理フロー記憶部と、を更に有し、前記処理フロー読出し部は、前記処理要求取得部が取得した処理要求と前記処理フロー記憶部が記憶する処理フローとが一致した場合に、前記処理フロー記憶部から一致した処理フローを読み出すことが好ましい。この処理フロー管理システムは、予め定められた処理フローを読み出して処理内容を決定するため、処理フロー全体を適切に管理することが可能となる。

【0012】

上述した課題を解決し、目的を達成するために、本開示に係る処理フロー管理方法は、複数のシステムとデータの送受信を行って処理フローを管理する処理フロー方法であって、複数の処理が設定された順序で組み合わさった処理フローを読み出す処理フロー読出しステップと、前記処理フローに基づき、前記複数の処理から、これから実行する処理である現在実行処理を決定する処理決定ステップと、前記現在実行処理に基づき前記複数のシステムから対象システムを選択し、前記対象システムに前記現在実行処理を実行する旨の指令を出力する処理指令ステップと、前記対象システムからデータを受信して、そのデータが前記現在実行処理を実行した旨の実行データであるかを判断する実行データ判断ステップと、前記現在実行処理を決定したタイミングである立ち上げタイミング、前記実行データを受信したタイミングである終了タイミング、及び前記実行データを送信した前記対象システムを、前記現在実行処理に関連付けて履歴情報として記憶する履歴記憶ステップと、を有する。この処理フロー管理方法は、複数のシステムが用いられている場合においても、処理フロー全体を適切に管理することが可能となる。

【発明の効果】

【0013】

本発明によれば、複数のシステムが用いられている場合においても処理フロー全体を適切に管理することができる。

【図面の簡単な説明】

【0014】

【図1】図１は、本実施形態に係る処理フローシステムのブロック図の一例である。

【図2】図２は、処理フロー管理システムのブロック図である。

【図3】図３は、製品の設計変更の場合に必要な処理を示すフローチャートである。

【図4】図４は、処理フローの一例を示す図である。

【図5】図５は、履歴情報の一例を示す説明図である。

【図6】図６は、処理フロー管理システムによる処理フローの管理を説明するフローチャートである。

【発明を実施するための形態】

【0015】

以下に添付図面を参照して、本発明の好適な実施形態を詳細に説明する。なお、この実施形態により本発明が限定されるものではなく、また、実施形態が複数ある場合には、各実施形態を組み合わせて構成するものも含むものである。

【0016】

図１は、本実施形態に係る処理フローシステムのブロック図の一例である。本実施形態に係る処理フローシステム１は、処理フローを実行するためのシステムの集合体である。処理フローとは、複数の処理が設定された順序で組み合わさって１つの業務プロセスを構成するものである。複数の処理が設定された順序で組み合わさっているとは、ある処理が実行された後に、他の処理が実行されており、その処理順序が予め設定されていることを意味する。

【0017】

図１に示すように、処理フローシステム１は、処理フロー管理システム１０と、複数のシステム１００とを有する。処理フロー管理システム１０は、複数のシステム１００とデータの送受信が可能なシステムである。処理フロー管理システム１０の詳細は後述する。複数のシステム１００同士は、互いに異なる動作（処理）を行うものであり、かつ、互いにデータの通信が遮断されている。すなわち、システム１００同士は、直接データのやりとりを行うことができない。なお、システム１００は、処理フローを構成する各処理を行うためのシステムであるが、これに限られず、例えば電子メールを行うメールシステムなど、処理フロー管理システム１０に対してデータ通信を行うことが可能なシステムであればよい。

【0018】

さらに詳しくは、処理フローシステム１は、サプライチェーンを管理するシステムである。サプライチェーンは、複数の企業間で統合的に構築された物流システムであり、以下の例では、複数の部品から構成される１つの製品の生産を管理するものとする。本実施形態のサプライチェーンにおいては、一つの企業や部署が自身の処理（例えば１つの部品の生産管理）を完了した後に、他の企業が別の処理を実行して、統合的に１つの製品を管理する。従って、サプライチェーンは、各企業などが担当する複数の処理が、設定された順序で組み合わさった処理フローであるということができる。なお、処理フローは、複数の処理が設定された順序で組み合わさって１つの業務プロセスを構成するものであればよく、１つの製品の生産管理プロセスに限られない。

【0019】

本実施形態における処理フローは、製品を製造する企業（製造企業）の設計部と、製造企業のＱＡ（Quality Assurance）部と、設計企業の購買部と、第１サプライヤと、第２サプライヤによって実行される。設計部は、製品の設計を監理する部署である。ＱＡ部は、製品の品質保証を管理する部署である。購買部は、第１サプライヤ及び第２サプライヤからの部品の購買を管理する部署である。第１サプライヤは、製造企業とは別の企業であり、製品を構成する一部の部品を製造する企業である。第２サプライヤは、製造企業とは別の企業であり、製品を構成する他の一部の部品を製造する企業である。すなわち、設計部とＱＡ部と購買部と第１サプライヤと第２サプライヤとは、処理フロー内の各処理を実行し、それぞれが実行する処理の内容は互いに異なる。ただし、これらの部署及び企業は一例である。処理フロー内の各処理を実行する部署や企業は、処理フローの内容によって任意に設定される。

【0020】

図１に示すように、本実施形態における複数のシステム１００は、設計システム１０１と、ＱＡシステム１０２と、購買システム１０４と、監査システム１０６と、第１サプライヤシステム１１０と、第２サプライヤシステム１２０とを有する。設計システム１０１とＱＡシステム１０２と購買システム１０４とは、製品を製造する製造企業が管理するシステム（コンピュータシステム）である。設計システム１０１は、設計部が設計管理のために用いるシステムである。ＱＡシステム１０２は、ＱＡ部が品質保証管理のために用いるシステムである。購買システム１０４は、購買部が購買管理のために用いるシステムである。また、第１サプライヤシステム１１０は、第１サプライヤが部品製造を管理するために用いるシステムである。そして、第２サプライヤシステム１２０は、第２サプライヤが部品製造を管理するために用いるシステムである。ただし、システム１００は、これらに限られず、実行する処理フローによって任意のシステムが含まれる。

【0021】

図２は、処理フロー管理システムのブロック図である。図２に示すように、処理フロー管理システム１０は、処理フロー記憶部２０と、処理要求取得部２２と、処理フロー読出し部２４と、処理要求保存部２６と、処理フロー表示制御部２８と、処理フロー管理部３０と、履歴記憶部３２と、履歴分析部３４とを有する。

【0022】

処理フロー記憶部２０は、複数種類の処理フローの内容を記憶している。さらに詳しくは、処理フロー記憶部２０は、処理フローに含まれる各処理の内容とその処理の配列順とを、処理フロー毎に記憶している。処理フロー記憶部２０が記憶する処理フローの内容、すなわち各処理の内容と配列順とは、処理フロー管理システム１０への管理者の入力により設定される。ただし、後述のように、履歴分析部３４が、履歴の分析結果により、処理の内容と配列順とを更新してもよい。処理フロー記憶部２０が記憶する処理フローの種類は、処理フロー管理システム１０への管理者の入力により更新されてもよい。

【0023】

処理フロー記憶部２０は、複数種類の処理フローを記憶可能であるが、量産された製品の設計変更の場合の処理フローを、一例として以下に説明する。図３は、製品の設計変更の場合に必要な処理を示すフローチャートである。図３に示すように、製品の設計変更を行う場合、設計部が設計の観点から変更可否を判断し（ステップＳ１）、ＱＡ部が品質保証の観点から変更可否を判断する必要がある（ステップＳ２）。さらに、購買部が、例えばコストの観点から製品設計変更に伴う部品の設計変更の可否を判断し（ステップＳ４）、第１サプライヤ及び第２サプライヤが部品の設計変更の可否を判断し（ステップＳ６）、監査部が最終判断を行う必要がある（ステップＳ８）。なお、監査部は、製造企業において設計変更の可否の最終判断を行う責任部署である。

【0024】

図４は、処理フローの一例を示す図である。設計変更においては、図３に示すような処理が必要であるが、処理フロー記憶部２０は、この設計変更の処理フローを、例えば図４に示すような処理の内容及び処理順序のものとして記憶している。図４は、設計変更の処理フローを、処理フロー表示制御部２８がディスプレイである表示部５０に表示した状態を示している。

【0025】

図４に示すように、処理フロー表示制御部２８は、表示部５０の上部表示画面５２に、処理フローの名称（ここでは、「設計変更フロー Ａ−００１」）を表示する。また、処理フロー表示制御部２８は、表示部５０の中央表示画面５４に、処理フローの内容を表示する。設計変更の処理フローは、担当部起草処理（ステップＳ１０）と、設計部判断処理（ステップＳ１２）と、ＱＡ部判断処理（ステップＳ１４）と、購買部判断処理（ステップＳ１６）と、第１サプライヤ判断処理（ステップＳ１８）と、第２サプライヤ判断処理（ステップＳ２０）と、監査部判断処理（ステップＳ２２）と、の各処理が設定された順序で組み合わされたものである。この処理フローは、処理フロー管理部３０によって管理されるが、その管理方法については後述する。

【0026】

図２に戻り、処理要求取得部２２は、システム１００のいずれかから処理要求を取得する。処理要求とは、新しい処理フローを実行する旨を要求する情報である。すなわち、本実施形態における処理要求は、製品の設計変更の処理フローを立ち上げることを要求する情報である。この処理要求は、複数のシステム１００のいずれから送信されるものであるが、例えば、管理者により処理フロー管理システム１０に直接入力されてもよい。

【0027】

処理要求取得部２２は、処理要求に対応する処理フローを、処理フロー記憶部２０が記憶している複数の処理フローと照合する。そして、処理要求取得部２２は、処理要求と一致する処理フローを、処理フロー記憶部２０が記憶しているかを判断する。すなわち、処理要求取得部２２は、処理要求に対応する処理フローが、処理フロー管理システム１０によって処理内容が定義されていない新しい処理フローであるかを判断する。処理要求取得部２２は、処理フロー記憶部２０が一致する処理フローを記憶している場合、すなわち、処理要求に対応する処理フローの内容が定義されている既存のものである場合、その旨及びその処理フローの内容を、処理フロー読出し部２４に伝達する。処理要求取得部２２は、処理フロー記憶部２０が一致する処理フローを記憶していない場合、すなわち、処理要求に対応する処理フローの内容が定義されていない新規のものである場合、その旨を処理要求保存部２６に伝達する。

【0028】

処理フロー読出し部２４は、処理フロー（今回の例では設計変更の処理フロー）を読み出す。具体的には、処理フロー読出し部２４は、処理要求取得部２２から、処理フロー記憶部２０が処理要求に一致する処理フローを記憶している旨の情報と、その一致する処理フローの内容とを取得する。言い換えれば、処理フロー読出し部２４は、処理要求取得部２２が取得した処理要求と、処理フロー記憶部２０が記憶する処理フローとが一致した場合に、処理フロー記憶部２０からその一致した処理フローの内容を読み出す。

【0029】

処理要求保存部２６は、処理要求取得部２２から、処理フロー記憶部２０が処理要求に一致する処理フローを記憶していない旨の情報と、その処理要求に対応する処理フローとを取得し、その処理フローを記憶する。すなわち、処理要求保存部２６は、処理フロー管理システム１０によって処理内容が定義されていない新しい処理フローを記憶する。処理要求保存部２６に記憶された処理フローは、処理フロー管理部３０によって管理されず、各部署の担当者によって個別に管理される。ただし、処理要求保存部２６に記憶された処理フローは、作業者によって処理内容が新たに設定されて処理フロー記憶部２０に記憶された後に、処理フロー管理部３０によって管理されてもよい。

【0030】

処理フロー表示制御部２８は、処理フロー読出し部２４が読み出した処理フローの表示を制御する。具体的には、処理フロー表示制御部２８は、図４に示したように、処理フロー読出し部２４が読み出した処理フローを、ディスプレイである表示部５０に表示する。

【0031】

処理フロー管理部３０は、処理決定部４０と処理指令部４２と実行データ判断部４４とを有する。処理決定部４０は、処理フロー読出し部２４が読み出した処理フローに基づき、その処理フロー内の複数の処理から現在実行処理を決定する。現在実行処理とは、処理フロー内の処理のうち、これから実行する処理を指す。処理決定部４０は、処理フロー内の最初の処理（図４では担当部起草処理）が実行されていない場合は、その最初の処理を、現在実行処理として決定する。処理決定部４０は、処理フロー内で既に実行が終了した処理がある場合は、最後に終了した処理の次の処理を、現在実行処理として決定する。

【0032】

処理指令部４２は、処理決定部４０が決定した現在実行処理に基づき、複数のシステム１００から対象システムを選択する。処理指令部４２は、選択した対象システムに対し、現在実行処理を実行する旨の指令を出力する。処理指令部４２は、現在実行処理の処理内容を読み出し、処理を誰が行うかを判断することで、対象システムを選択する。例えば、処理指令部４２は、現在実行処理が設計部による設計変更の確認を行う旨の内容であれば、設計部がその処理を行うと判断し、設計システム１０１を対象システムとして選択する。そして、処理指令部４２は、設計システム１０１に設計変更の確認を行う旨の指令を出力する。

【0033】

実行データ判断部４４は、対象システムからデータを受信する。実行データ判断部４４は、その受信したデータが実行データであるかを判断する。実行データとは、処理指令部４２によって指示された現在実行処理を実行した旨の情報である。すなわち、対象システムは、現在実行処理を実行した場合に、その旨を実行データとして実行データ判断部４４に出力する。実行データ判断部４４は、その実行データを受信する。なお、実行データ判断部４４は、選択した対象システム以外から、その現在実行処理に対するアクセス（ここでは実行データの送信）を制限し、対象システムのみから現在実行処理に対するアクセス（データの送信）を受けつけるようにしてもよい。

【0034】

実行データ判断部４４は、実行データを受信した場合、その旨を処理決定部４０に通知する。処理決定部４０は、実行データを受信した旨の情報を受信すると、その現在実行処理を終了し、その次の処理を現在実行処理として決定する。その後の処理は同様である。

【0035】

以上の処理決定部４０と処理指令部４２と実行データ判断部４４との処理の一例を、図４に示す設計変更の処理フローを例として、具体的に説明する。図４に示すように、設計変更の処理フローは、最初に担当部起草処理が実行される（ステップＳ１０）。具体的には、処理決定部４０は、担当部起草処理を現在実行処理に決定する。処理指令部４２は、担当部起草処理の内容を読み出す。担当部起草処理は、処理要求を送信した担当者が、その処理フローの詳細内容を入力する処理である。ここでは、担当者が、設計変更の詳細内容、すなわちどの製品をどのように設計変更するかを入力する処理である。処理指令部４２は、処理要求を送信した担当者が設計部判断処理を行うと判断して、その担当者が管理するシステム１００を対象システムとして選択する。そして、処理指令部４２は、そのシステム１００に対し、担当部起草処理を行う旨の指令を出力する。なお、処理要求を送信した担当者は、例えば設計部や第１サプライヤなど、どの部署や企業に属する者であってよい。

【0036】

担当部起草処理を行う旨の指令を取得したシステム１００は、担当者に担当部起草処理を受信した旨を通知する。担当者は、担当部起草処理を行う旨の指令の内容を確認した旨の情報をそのシステム１００に入力する。システム１００、指令の内容を確認した旨の情報を処理フロー管理システム１０に出力する。そして、担当者は、システム１００に、設計変更の詳細内容、すなわちどの製品をどのように設計変更するかを入力する。システム１００は、設計変更の詳細内容を、実行データとして実行データ判断部４４に出力する。実行データ判断部４４は、受信した実行データ（設計変更の詳細内容）を記憶し、実行データを受信した旨を処理決定部４０に通知する。処理決定部４０は、担当部起草処理の実行データを受信した旨の通知により、担当部起草処理を終了する。

【0037】

担当部起草処理が終了した後は、設計部判断処理が実行される（ステップＳ１２）。具体的には、処理決定部４０は、担当部起草処理が終了した後、次の処理である設計部判定処理を現在実行処理に決定する。処理指令部４２は、設計部判断処理の内容を読み出す。設計部判断処理は、設計部が設計変更の可否を判断する処理である。処理指令部４２は、設計部が設計部判断処理を行うと判断して、設計システム１０１を対象システムとして選択する。そして、処理指令部４２は、設計システム１０１に対し、設計部判断処理を行う旨の指令を出力する。

【0038】

設計部判断処理を行う旨の指令を取得した設計システム１０１は、設計部の担当者に設計部判断処理を受信した旨を通知する。設計部の担当者は、指令の内容を確認した旨の情報を、設計システム１０１に入力する。設計システム１０１は、指令の内容を確認した旨の情報を、処理フロー管理システム１０に出力する。そして、設計部の担当者は、設計システム１０１を介して実行データ判断部４４が記憶した設計変更の詳細内容を読み出し、設計変更の可否を判断する。設計部の担当者は、設計システム１０１に設計変更可否の判断結果を入力する。設計システム１０１は、設計変更可否の判断結果を、実行データとして実行データ判断部４４に出力する。実行データ判断部４４は、受信した実行データが、設計変更が可能である旨の情報である場合、その旨を処理決定部４０に通知する。実行データ判断部４４は、受信した実行データが、設計変更が不可能である旨の情報である場合、処理決定部４０にステップＳ１０に戻る旨の指令を出し、処理要求を送信した担当者に対し、設計変更の詳細内容を変更する旨の通知を行う。

【0039】

設計部判断処理が終了した後は、ＱＡ部判断処理が実行される（ステップＳ１４）。ＱＡ部判断処理は、ＱＡシステム１０２を介してＱＡ部に設計変更可否の判断を指令する旨の処理である。ＱＡ部判断処理の処理手順は、設計部判断処理と同様であるため、説明を省略する。

【0040】

ＱＡ部判断処理が終了した後は、購買部判断処理が実行される（ステップＳ１６）。購買部判断処理は、購買システム１０４を介して購買部に設計変更可否の判断を指令する旨の処理である。購買部判断処理の処理手順は、設計部判断処理と同様であるため、説明を省略する。

【0041】

購買部判断処理が終了した後は、第１サプライヤ判断処理（ステップＳ１８）及び第２サプライヤ判断処理（ステップＳ２０）が実行される。第１サプライヤ判断処理は、第１サプライヤシステム１１０を介して第１サプライヤに担当する部品の設計変更可否の判断を指令する旨の処理である。第２サプライヤ判断処理は、第２サプライヤシステム１２０を介して第２サプライヤに担当する部品の設計変更可否の判断を指令する旨の処理である。第１サプライヤ判断処理及び第２サプライヤ判断処理の処理手順は、設計部判断処理と同様であるため、説明を省略する。

【0042】

第１サプライヤ判断処理及び第２サプライヤ判断処理が終了した後は、監査部判断処理が実行される（ステップＳ２２）。監査部判断処理は、監査部が管理するシステムを介して監査部に製品の設計変更の最終的な判断を行う旨を指令する処理である。監査部判断処理の処理手順は、設計部判断処理と同様であるため、説明を省略する。この監査部判断処理の終了により、設計変更の処理フローは終了し、設計変更が実行される。

【0043】

処理決定部４０と処理指令部４２と実行データ判断部４４とは、以上のように、各システム１００とデータの送受信を行い、処理フロー全体を管理する。ただし、以上の説明は設計変更の処理フローの一例であり、処理の手順は、処理フローの種類によって異なる。処理フローの内容は、上述のように任意であるが、設計変更以外の例としては、サプライヤで起こった不適合品の判定（救済、廃却、補修）を行う処理、注文内容の変更を行い、どの時点から変更の適用を実施するかを決定する処理、サプライヤ側からの設計や作業工程変更要求の実施可否を判断して判断結果を通知する処理、製品仕様書（図面、付帯仕様書など）をサプライヤに提供して見積もりを依頼し、必要に応じて問い合わせに対応して、最終的な見積もり回答を受領する処理などが挙げられる。

【0044】

図２に戻り、履歴記憶部３２は、処理フロー内の各処理の実行状況の履歴である履歴情報を記憶する。具体的には、履歴情報は、その処理の内容と、立ち上げタイミングと、確認タイミングと、終了タイミングと、その処理を行った担当者とを含む。立ち上げタイミングは、その処理を現在実行処理として開始したタイミングである。すなわち、立ち上げタイミングは、対象システムに対し、現在実行処理を実行する旨の指令を出力したタイミングである。また、確認タイミングは、処理フロー管理システム１０が、指令を確認した旨の情報を、対象システムから取得したタイミングである。終了タイミングは、現在実行処理を終了したタイミングである。すなわち、終了タイミングは、対象システムから実行データを受信したタイミングである。また、履歴情報は、その処理を行った担当者の情報の代わりに、実行データを出力した対象システムの情報を含んでもよい。

【0045】

図５は、履歴情報の一例を示す説明図である。図５に示すように、履歴情報は、立ち上げタイミングと、確認タイミングと、終了タイミングと、その処理を行った担当者とが、その処理の内容に関連付けられたものである。履歴記憶部３２は、終了した全ての処理（図５の例では、担当部起草処理と設計部判定処理）を、立ち上げタイミングと確認タイミングと終了タイミングとその処理を行った担当者とに関連付けて記憶している。管理者は、履歴情報により、どの処理にどれだけ時間を要しているかを容易に確認することが可能となり、処理の改善を行うことが可能となる。

【0046】

図２に示す履歴分析部３４は、履歴記憶部３２が記憶する履歴情報に基づき、処理を終了させるのに要する時間を、処理毎に算出する。さらに詳しくは、履歴分析部３４は、相関分析を行い、処理フローの全体のリードタイムにおいて、どの処理がボトルネックになっているかを分析する。また、履歴分析部３４は、例えば、処理を終了させるのに要する時間の算出結果から、処理フローの内容を修正し、その修正した処理フローを更新して処理フロー記憶部２０に記憶させてもよい。例えば、履歴分析部３４は、算出結果に基づき、処理フロー内の処理順番を入れ替えてもよい。具体的には、履歴分析部３４は、処理を終了させるのに要する時間の長い処理を後ろに移動させてもよい。これによって短時間で終了する処理を先に行わせることで、前の処理が終わらずに待ちの状態となっている部署を少なくすることが可能となる。

【0047】

次に、処理フロー管理システム１０による処理フローの管理を、フローチャートに基づき説明する。図６は、処理フロー管理システムによる処理フローの管理を説明するフローチャートである。図６に示すように、最初に、処理フロー管理システム１０は、処理要求取得部２２が、処理要求を取得する（ステップＳ４０）。

【0048】

処理要求を取得した後、処理フロー管理システム１０は、処理要求取得部２２が、処理フロー記憶部２０が記憶する処理フローと処理要求とを照合して、処理要求に一致する処理フローがあるか判断する（ステップＳ４２）。具体的には、処理要求取得部２２は、処理フロー記憶部２０が、処理要求と一致する処理フローを記憶しているかを判断する。処理要求に一致する処理フローがある場合（ステップＳ４２；Ｙｅｓ）、処理フロー読出し部２４は、処理フロー記憶部２０からその一致する処理フローを読み出す（ステップＳ４４）。なお、処理要求に一致する処理フローが無いと判断した場合（ステップＳ４２；Ｎｏ）、処理フロー管理システム１０は、その処理要求を処理要求保存部２６に保存して、本処理を終了する。

【0049】

処理フローを読み出した後、処理フロー管理システム１０は、処理決定部４０により、処理フロー内の各処理から、現在実行処理を決定する(ステップＳ４６)。具体的には、処理決定部４０は、処理フロー内の最初の処理が実行されていない場合は、その最初の処理を、現在実行処理として決定する。処理決定部４０は、処理フロー内で既に実行が終了した処理がある場合は、最後に終了した処理の次の処理を、現在実行処理として決定する。

【0050】

現在実行処理を決定した後、処理フロー管理システム１０は、処理指令部４２により、複数のシステム１００から対象システムを選択し、現在実行処理を実行する旨の実行指令を出力する（ステップＳ４８）。対象システムの担当者は、その実行指令に基づき現在実行処理を実行する。対象システムは、現在実行処理を実行した旨の実行データを、実行データ判断部４４に出力する。

【0051】

処理フロー管理システム１０は、実行データ判断部４４により、対象システムからデータを受信したら（ステップＳ５０）、そのデータが実行データであるかを判断する（ステップＳ５２）。実行データである場合（ステップＳ５２；Ｙｅｓ）、処理フロー管理システム１０は、処理決定部４０により、現在実行処理を終了する（ステップＳ５４）。なお、実行データでない場合（ステップＳ５２；Ｎｏ）、ステップＳ５０に戻り、データの受信を続ける。

【0052】

現在実行処理を終了した後、処理フロー管理システム１０は、処理決定部４０により、処理フロー内に次の処理があるかを判断し（ステップＳ５６）、次の処理がある場合（ステップＳ５６；Ｙｅｓ）、ステップＳ４６に戻り、次の処理を現在実行処理に決定し、同様の処理を繰り返す。次の処理が無い場合（ステップＳ５６；Ｎｏ）、処理フロー管理システム１０は、処理フローを終了し（ステップＳ５８）、本処理を終了する。履歴記憶部３２は、この処理の最中において、履歴情報をその都度記憶する。

【0053】

以上説明したように、本実施形態に係る処理フロー管理システム１０は、複数のシステム１００とデータの送受信を行って処理フローを管理するものであり、処理フロー読出し部２４と、処理決定部４０と、処理指令部４２と、実行データ判断部４４と、履歴記憶部３２とを有する。処理フロー読出し部２４は、複数の処理が設定された順序で組み合わさった処理フローを読み出す。処理指令部４２は、処理フローに基づき、複数の処理から、これから実行する処理である現在実行処理を決定する。処理指令部４２は、現在実行処理に基づき、複数のシステム１００から対象システムを選択し、対象システムに現在実行処理を実行する旨の指令を出力する。実行データ判断部４４は、対象システムからデータを受信して、そのデータが現在実行処理を実行した旨の実行データであるかを判断する。履歴記憶部３２は、開始タイミング、終了タイミング、及び対象システムを、現在実行処理に関連付けて履歴情報として記憶する。

【0054】

処理フローは、複数の処理を順次実行するフローである。この複数の処理は、例えば異なる企業などに所属する異なる担当者によって実行される。ある担当者の処理が終了すれば、他の担当者が次の処理を実行する。従って、各部署や企業は、互いに処理が完了した旨などのデータのやりとりが必要となる。しかし、各部署や企業は、図１に示すシステム１００のように、互いに異なるシステムを用いている場合がある。従って、このような処理フローを管理する場合、処理フロー全体を監視して一元管理することが困難となるおそれがある。しかし、本実施形態に係る処理フロー管理システム１０は、システム１００とデータの送受信を行って、各システム１００にそれぞれの処理を実行する旨の指令を出し、その実行した旨の結果を取得して、処理フロー中の各処理の進捗状況を管理する。そして、処理フロー管理システム１０は、処理毎の進捗状況を履歴情報として記憶する。例えば管理者は、履歴情報を参照して、処理毎の進捗状況を容易に確認することが可能となるため、処理フロー全体を適切に管理し、かつ、各処理を改善することも容易となる。従って、この処理フロー管理システム１０は、複数のシステム１００が用いられている場合においても、処理フロー全体を適切に管理することが可能となる。また、処理フロー管理システム１０は、複数のシステム１００に対して実行する処理を規定するため、それぞれのシステム１００の設定を変更することなく、種々の処理フローを実行することができる。また、処理フロー管理システム１０によると、処理フローの処理内容が変更になった場合でも、システム１００の設定を変更する必要が無くなる。

【0055】

また、複数のシステム１００は、互いに異なる処理を実行し、かつ、互いにデータの通信が遮断されている。このようなシステム１００を用いて処理フローを実行する場合、システム１００の全体の状況を確認できる担当者がいなくなるため、処理フロー全体の管理が困難となる。しかし、この処理フロー管理システム１０は、これらのシステム１００に対してデータのやりとりを行って、全ての処理の進捗状況を管理することが可能となる。従って、この処理フロー管理システム１０は、このような場合のおいても、処理フロー全体を適切に管理することが可能となる。

【0056】

また、処理フロー管理システム１０は、履歴情報に基づき、処理を終了するのに要する時間を算出する履歴分析部３４を更に有する。この履歴分析部３４は、処理を終了するのに要する時間を算出するため、管理者が、どの処理を重点的に改善する必要があるか、すなわちどの処理の処理時間を重点的に短縮する必要があるかを容易に認識することが可能となる。従って、処理フロー管理システム１０によると、処理を適切に改善することができる。

【0057】

また、処理フロー管理システム１０は、新しい処理フローを実行する旨の処理要求を取得する処理要求取得部２２と、複数種類の処理フローを記憶する処理フロー記憶部２０と、を更に有する。処理フロー読出し部２４は、処理要求取得部２２が取得した処理要求と処理フロー記憶部２０が記憶する処理フローとが一致した場合に、処理フロー記憶部２０から一致した処理フローを読み出す。この処理フロー管理システム１０は、予め定められた処理フローを読み出して処理内容を決定するため、処理フロー全体を適切に管理することが可能となる。

【0058】

以上、本発明の実施形態を説明したが、この実施形態の内容により実施形態が限定されるものではない。また、前述した構成要素には、当業者が容易に想定できるもの、実質的に同一のもの、いわゆる均等の範囲のものが含まれる。さらに、前述した構成要素は適宜組み合わせることが可能である。さらに、前述した実施形態の要旨を逸脱しない範囲で構成要素の種々の省略、置換又は変更を行うことができる。

【符号の説明】

【0059】

１ 処理フローシステム
１０ 処理フロー管理システム
２０ 処理フロー記憶部
２２ 処理要求取得部
２４ 処理フロー読出し部
２６ 処理要求保存部
２８ 処理フロー表示制御部
３０ 処理フロー管理部
３２ 履歴記憶部
３４ 履歴分析部
４０ 処理決定部
４２ 処理指令部
４４ 実行データ判断部
１００ システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】