P2p型工作流系統、信息處理裝置及工作流支持系統的製作方法

2023-09-17 16:03:25 1

專利名稱：P2p型工作流系統、信息處理裝置及工作流支持系統的製作方法
技術領域：
本發明涉及一種工作流系統，其用於在例如企業等中，對由多個工序構成且經由多個作業者處理的一連串作業進行支持。
背景技術：
隨著個人電腦(PC)的普及及網絡環境的完善等，在很多企業中，廣泛地實現業務的電子化。作為用於通過該電子化進行支持而高效地開展業務的一種方法，已知工作流系統。工作流系統通常由伺服器統一管理作業的進展狀況等，各個工序的作業者使用與伺服器和網絡連接的PC，在適當的時候實施所承擔的作業。並且，關於該工作流系統，目前已提出各種方案(例如，參照專利文獻1等)。專利文獻1 日本特開2008-117258號公報

發明內容
在目前一般的伺服器型工作流系統中，在未收容在同一個系統中的用戶之間組合過程(工作流)的情況下，可以通過重新收容到同一個系統中，或使收容各個過程的系統之間連接而應對，但是，存在收容的系統的準備，或者，系統管理者的調整或連接作業麻煩的課題。另外，在目前一般的伺服器型工作流系統中存在以下課題，S卩，因為由伺服器管理過程或任務，所以要使從不同系統提供的過程間連接或協調，各個系統的管理者之間必須在調整後進行系統修正等連接作業，非常麻煩(這裡的管理者包含有責任進行過程改善的職責)。另外，對於同一個系統提供的過程的改善也相同，一般來說，為了進行過程修正，管理者很麻煩。其結果是，為了對於管理成本的效果最大化，將系統中的支持範圍縮減為整體最優的標準過程，除此之外的分支業務過程通過郵件或表計算工具等在系統外應對，或在系統的生成中組合業務而應對的情況不少。如果本身使用的多個系統間無聯繫，則也存在對於每個系統加強例如自身分解或相對於跨越的過程之間二次投入等自身調節的情況。另夕卜，即使是系統支持的業務過程，系統修正也無法跟得上圍繞業務的環境變化，從而通過郵件或表計算工具完成業務過程，在事後向系統加入數據的情況也不少。本發明是考慮上述情況提出的，目的在於提供一種工作流系統、信息處理裝置及工作流支持程序，其不會麻煩系統管理者，即可在希望改善過程的當事人之間實現可以改善的應用。為了實現上述目的，本發明的工作流系統為，將由多個任務組成的過程搭載在大於或等於1臺計算機上，通過分配到上述多個任務中的至少1個任務的多個工作流支持程序依次進行處理，上述多個工作流支持程序分別具有組生成單元，其定義作為成員而歸屬的各個工作流程序的職責，並生成組；過程定義單元，其指定應承擔各個任務的成員的職責，並且定義由多個任務組成的過程；以及過程處理單元，其處理通過上述過程定義單元定義的過程內的任務，將包含表示上述過程相關的各個任務的處理結果及進展狀況的信息的消息，傳送給已定義要承擔下一個任務的職責的工作流支持程序，在通過上述組生成單元生成的組內，通過在上述多個工作流支持程序之間依次傳送與該過程相關的信息，處理通過上述過程定義單元定義的過程。發明的效果根據本發明，可以實現不麻煩系統管理者，即可在要改善過程的當事人之間實現可以改善的運用。


圖1是表示本發明的實施方式涉及的工作流系統的動作環境的圖。圖2是用於在說明該實施方式的工作流中形成的組的結構的圖。圖3是表示實現該實施方式的工作流程序的過程支持工具(工作流支持程序)的功能框圖的圖。圖4是表示在該實施方式的工作流系統中使用的使用許可信息的一個結構例的圖。圖5A是用於說明該實施方式的工作流系統中使用的成員信息的一個結構例的第 1圖。圖5B是用於說明該實施方式的工作流系統中使用的成員信息的一個結構例的第 2圖。圖6A是用於說明該實施方式的工作流系統中使用的連結信息的一個結構例的第 1圖。圖6B是用於說明該實施方式的工作流系統中使用的連結信息的一個結構例的第 2圖。圖7是表示該實施方式的工作流系統中使用的歸屬許可信息的一個結構例的圖。圖8A是用於說明在該實施方式的工作流系統中定義的過程的一個結構例的第1 圖。圖8B是用於說明在該實施方式時的工作流系統中定義的過程的一個結構例的第 2圖。圖9是用於說明在該實施方式的工作流系統中，多個過程支持工序協同動作而處理過程的原理的概念圖。圖10是表示該實施方式的工作流系統中的過程(信息)的處理順序的一個例子的流程圖。圖11是表示在該實施方式的工作流系統中提示的作業畫面的一個例子的圖。圖12是用於說明相對於該實施方式的工作流系統中的信息的處理結果信息的追記順序的一個例子的概念圖。圖13是表示在該實施方式的工作流系統中追記處理結果信息的消息的一個例子的圖。圖14是用於說明在該實施方式的工作流系統中協調多個過程的一個例子的圖。
圖15是用於說明在該實施方式的工作流系統中將某個過程的編輯項目通過其他過程細分的一個例子的圖。標號的說明L···發起人Web伺服器2…計算機10…過程支持工具1L···組成員管理部12…過程定義部13…任務處理部14…用戶接口部15…通信處理部16…公鑰密碼部50…資料庫51…成員信息52…連結信息53…歸屬許可信息討…使用許可信息55…過程56…消息100 …組A…網絡B …LAN
具體實施例方式下面，參照附圖，說明本發明的一個實施方式。圖1是表示本發明的實施方式涉及的工作流系統進行動作的環境的一個例子的圖。本工作流系統，通過分別安裝在PC或伺服器等計算機2上的多個過程支持工具 10 (工作流支持程序)，經由網絡(A，B)進行協同動作而實現。過程支持工具10例如是記錄在計算機2可以讀取的0D(0ptical disc)等中而發布、或者通過從發起人Web伺服器下載而獲取的程序。發起人Web伺服器1是該過程支持工具10的發布源(發起人)開設的Web伺服器，過程支持工具10的使用需求者(用戶)經由網絡A向發起人Web伺服器1申請其使用許可，並獲取使用許可信息。該使用許可信息包含過程支持工具10與其他過程支持工具10 協同動作而實現工作流系統所需的信息，其詳細內容如後所述。本工作流系統是P2P型工作流系統，其通過將已從發起人Web伺服器1獲取使用許可信息的各個過程支持工具10組成組100，從而可以適當地定義並使用經由各個過程支持工作具10的用戶之間的過程(工作流)。在圖1的例子中，多個PC之間經由網絡A組成組100 (組1)，另夕卜，由在N公司的區域內鋪設的LAN⑶上的伺服器及PC組成組100 (組2)，同樣地，由在S公司區域內鋪設的LAN(B)上的伺服器及PC組成組100 (組3)。此外，在 N公司及S公司這兩個公司的伺服器之間組成組100(組4)。因此，各個過程處理工具10 之間的組100的形成，完全不受安裝終端的計算機2放置狀況的限制。此外，在圖1中，表示各個用戶分別使用計算機2，在各自的計算機2上分別安裝過程支持工具10的例子，但本工作流系統並不限定於這種方式，例如，在多個用戶共同使用1 臺計算機2的情況下，通過在該1臺計算機2上安裝與用戶數量對應的過程支持工具10，可以在共用該1臺計算機2的多個用戶之間使用工作流系統。圖2是用於說明由實現本工作流系統(分別安裝在計算機2上)的多個過程支持工具10形成的組100的結構的圖。如圖2所示，作為在該工作流系統中形成的組100，構成該組100的過程支持工具 10中的一個承擔上級職責，而其他過程支持工具10承擔下級職責。另外，各個過程支持工具10可以歸屬於多個組100。在圖2所示的例子中，作為下級加入組5的過程支持工具 10(圖2的al)，作為上級而形成組6。S卩，過程支持工具10同時具有用於作為上級而形成組100的上級功能，和用於作為下級而加入組100的下級功能。圖3是表示實現本工作流系統的過程支持工具10的功能框圖。如圖3所示，過程支持工具10具有組成員管理部11、過程定義部12、任務處理部 13、用戶接口部14、通信處理部15、公鑰密碼處理部16等。其中，組成員管理部11及過程定義部12是為了實現上級功能而設置的模塊，任務處理部13、用戶接口部14、通信處理部 15、公鑰密碼處理部16 (與上級或下級任務無關)是為了實現共通功能而設置的模塊。此外，用戶接口部14是用於經由鍵盤或指針設備等接收來自用戶的數據輸入，並且經由顯示器等向用戶進行數據輸出的模塊，通信處理處理部15是用於在與其他計算機2 之間收發電子郵件等消息的模塊，公鑰密碼處理部16是用於進行由公鑰密碼方式進行數據加密/解密或電子籤名及其驗證的模塊。另外，過程支持工具10具有資料庫50，使用該資料庫50管理成員信息51、連結信息52、歸屬許可信息53、使用許可信息54、過程55、消息56等各種信息。使用許可信息M的獲取，例如，通過發起人提供的「使用許可申請」過程進行。過程的動作基於後述的過程的動作原理。由此獲得的使用許可信息M由資料庫50管理。在圖4中表示使用許可信息M的一個結構例。使用許可信息M，例如作為由XML(Extensible markup language，可擴展標記語言)記載的文本數據而生成，包含唯一分配給過程支持工具10的「工具ID」、電子郵件地址等「用於消息交換的信息」、「用戶公鑰」，除此之外，還可以包含「用戶名」、「使用期限」等。 發起人將上述信息作為例如對過程支持工具10的用戶進行費用管理的信息使用。使用許可信息M標記發起人的電子籤名，向過程支持工具10發送。在本實施方式中，公鑰假定為以CA(certificate authority)局發布的證書形式處理的情況。發起人本身作為CA局，也可以以證書形式發布使用許可信息M。另外，包含該使用許可信息M在內，之後使用電子籤名的各種數據的驗證全部使用公鑰密碼處理部16執行。各個過程支持工具10根據所管理的公鑰·私鑰的信息，和使用許可信息M中記載的工具ID ·公鑰，對自身進行識別。下面，對於如上所述分別獲取了使用許可信息M的多個過程支持工具10協同動作，形成組100而對工作流進行定義·處理的基本原理進行說明。
在使用過程支持工具10的用戶之間形成組100的情況下，如前所述，某一個用戶的過程支持工具10成為上級。上級以外的用戶的過程支持工具10通過上級的過程支持工具10獲得歸屬許可信息53。歸屬許可信息53的獲取，例如，通過發起人提供的「組形成」 過程進行。過程的動作根據後述的過程的動作原理。首先，通過「組形成」過程讀入該組100相關的成員文件，根據該信息，組成員管理部11生成成員信息51。圖5A是表示在成員信息51的生成中由用戶生成的成員文件的一個例子的圖，另一方面，圖5B是表示成員信息51的一個例子的圖。成員文件例如以表計算軟體的工作表的形式生成。如圖5A所示，包含「工具ID」 區域、「組名」區域、「可使用過程」區域、「職責」區域的值。在組100中使用與使用許可信息M不同的「用戶名」、「用於消息交換的信息」、「用戶的公鑰」的情況下，也包含上述信息。 在這裡，所謂過程，是指由多個工序組成的一連串的作業(工作流)，將過程內的各個工序稱為任務。對於職責的詳細內容如後所述。在圖5A的例子中，將所形成的組100的名稱設定為「B部門」。另外，成員「佐藤一郎」定義為，可以參與「批准」過程、「特別許可」過程，在「批准」過程中承擔「職員」的職責、 在「特別許可」過程中承擔「特別許可負責」的職責。成員「田中二郎」定義為，僅參與「批准」過程，「批准」過程中的職責是「課長」，另外，成員「鈴木三郎」、「青木四郎」定義為，僅參與「批准」過程，在「批准」過程中的職責是「部長」 「部門長」。並且，根據該成員文件，組成員管理部11生成圖5B所示的成員信息51，由資料庫50管理。作為成員信息51，例如作為以XML記載的文本數據而生成。圖5B中「組ID」被分配為唯一的值，以使得在多個組100 之間不會重複，例如成為上級的用戶的過程支持工具10的「工具ID」 +每當該過程支持工具10成為上級而形成組100時遞增的序列號等。此外，在由該(成為上級的用戶的過程支持工具10的)組成員管理部11進行成員信息51的生成時，在成為下級的其他用戶的過程支持工具10中，對應於來自上級的要求，返回本身的使用許可信息M，上級確認其內容，進行與成員使用相關的正當性驗證或成員文件不包含公鑰的情況下的公鑰獲取。此外，不僅是「組形成」過程這種上級主動地構成成員的方法，還存在例如通過發起人提供的「組加入申請」過程，由希望加入的用戶申請而更新成員信息51的方法。然後，通過「組形成」過程或「組加入申請」過程，讀入與該組100相關的連結文件， 根據該信息，組成員管理部11生成連結信息52。圖6A是表示在連結信息52生成中由用戶生成的連結文件的一個例子的圖，另一方面，圖6B是表示連結信息52的一個例子的圖。連結文件例如以表計算軟體的工作表的形式生成。在圖6A的例子中，定義成員 「佐藤一郎」(職責「職員」)一成員「田中二郎」(職責「課長」)一成員「鈴木三郎」(職責 「部長」)一成員「青木四郎」(職責「部門長」)這種(在將要形成的組100內)的成員間的連結。通過該連結文件中的定義，例如，在該組100內存在多個課長或部長時，在以成員 「佐藤一郎」為起點生成「職員」一「課長」一「部長」這種流程的情況下，可以使該過程可靠地在已有的多個課長或部長中以成員「田中二郎」、成員「鈴木三郎」的順序流通。此外，在根據過程而所使用的連結不同的情況下，也在「使用過程」欄中預先設定。並且，根據該連結文件，組成員管理部11生成圖6B所示的連結信息52，由資料庫50管理。連結信息52例如作為由XML記載的文本數據生成。如上所述，由組成員管理部11生成的成員信息51及連結信息52(在圖3中標記陰影的數據)，由形成該組100的上級的過程支持工具10的資料庫50管理。因此，在某個過程支持工具10歸屬於η個組100，對於其中m個組100，成為上級而形成·管理這些組100 的情況下，在該過程支持工具10的資料庫50中，分別存在m個成員信息51及連結信息52。此外，通過「組形成」過程或「組加入申請」過程，組成員管理部11根據按照上述方式生成的成員信息51和連結信息52，生成歸屬於(也包含自身在內的)組100內的各個成員的歸屬許可信息53，分配給各成員。圖7表示歸屬許可信息53的一個結構例。圖7所示的歸屬許可信息53，是對於成員「佐藤一郎」生成的歸屬許可信息53的例子。此外，該組100假定成員「青木四郎」的過程支持工具10為上級而形成。因此，其工具ID "OOQKffkweoq"(參照圖5A) +序列號「001，，分配作為該組100的組ID。組成員管理部11對於成員信息51中記載的各個成員，參照連結信息52，檢測與該成員具有直接或間接的連結的其他成員。並且，包含「上級(自身的信息)」、「本人信息 (該成員信息)」、「成員(檢測到的其他成員的信息)」，並且，生成以上述內容為範圍的標記電子籤名的數據，作為該成員用的歸屬許可信息53。歸屬許可信息53分別由分配終端的各個成員的過程支持工具10的資料庫50管理。歸屬許可信息53例如作為由XML記載的文本數據而生成。根據圖6B所示的連結信息52，可知成員「佐藤一郎與成員「田中二郎」(直接地) 具有關聯，然後，因為該成員「田中二郎」與成員「鈴木三郎」(直接地)具有關聯，所以還可以知道，「佐藤一郎」與「鈴木三郎」(間接地)具有關聯。由此，通過追蹤連結信息52，生成圖7所示的成員「佐藤一郎」的歸屬許可信息53。此外，在連結信息內設定了應用過程的情況下，在關聯成員的信息中設定「應用過程」。因為該歸屬許可信息53中包含上級的公鑰及上級的電子籤名，所以可以適當地驗證其未被更改。在某個過程支持工具10歸屬於η個組 100的情況下，在該過程支持工具10的資料庫50中(與上級或下級的職責無關)存在η個歸屬許可信息53。如上所述，基於「組形成」過程或「組加入申請」過程的由組成員管理部11進行的組100的形成完成後，成為上級的過程支持工具10，根據例如發起人提供的「過程定義」過程，通過過程定義部12執行在該組100內處理的過程55的定義。按照圖8Α及圖8Β，對於過程55的一個結構例進行說明。圖8Α是表示在過程55的定義中由用戶生成的過程文件的一個例子的圖，另一方面，圖8Β是表示根據該過程文件，過程定義部12生成的過程55的一個例子的圖。如前所述，過程由一連串的任務構成，根據過程文件，定義各個任務的處理內容、 用於處理各個任務的成員的職責及任務的處理順序。在圖8Α的例子中，「批准」過程按照 「提案」任務一「提案書整理」任務一「提案人籤名」任務一「確認」任務一…「完成」任務這一順序定義。另外，如果以「提案」任務為例進行說明，則處理該「提案」任務的是承擔「職員」職責的成員，其處理內容定義為變量「文件名」、「批准內容」、「批准金額」、「金額單位」及 「批准種類」的編輯。即，通過承擔「實施者」區域的職責的成員按照「參數」區域的指定執行「控制語句」區域的命令，從而依次處理「任務ID」區域的任務。過程文件例如以表計算軟體的工作表的形式生成。並且，根據該過程文件，過程定義部12生成圖8B所示的過程55。這時，各個過程55被分配唯一的值作為過程ID，例如組 ID (OOQKffkeoq 001) +在組100內每當生成過程55時遞增的序列號(001)等。另外，因為在各個過程55中包含上級的電子籤名，所以可以使用歸屬許可信息53中包含的上級的公鑰， 從而適當地驗證該過程55未被更改。過程55，例如使用由XML記載的文本數據而生成。通過從發起人Web伺服器1等獲取定義典型內容的過程的過程模板，在該過程模板中標記作為組100的過程ID和過程名稱、由上級進行的電子籤名，作為過程55進行定義，可以從而可以節省上級的過程生成的麻煩。過程55由組100內的至少處理該過程55的成員的過程支持工具10發布，分別由資料庫50管理。也可以取而代之，例如，由組100內的全部成員的過程支持工具10，利用可以使用的共享文件伺服器等進行管理。下面，參照圖9至圖15，說明在如上所述(通過生成成員信息51、連結信息52及歸屬許可信息53)形成組100，並且定義過程55的本工作流系統中，歸屬於該組100的多個成員的過程支持工具10按照怎樣的順序協同動作而處理過程55。圖9是用於說明在本工作流系統中，多個過程支持工具10協同動作處理過程55 的原理的概念圖。各個過程支持工具10中的過程55的處理，通過任務處理部13執行。這裡，假定希望成員「佐藤一郎」起草並提出批准書。定義該批准書相關的一連串作業(工作流)的過程為「批准」過程。因此，成員「佐藤一郎」使用過程支持工具10，(從多個過程中)進行選擇「批准」 過程的操作。接受該操作，任務處理部13首先根據歸屬許可信息53 (上級的公鑰)，驗證作為過程55之一而管理的「批准」過程未被更改，另外，通過檢查在該歸屬許可信息53中作為可以使用的過程而記載有「批准」過程，並檢查記載最初的「提案」任務的職責「職員，，的職責，而確認成員「佐藤一郎」可以啟動「批准」過程。如果能夠驗證正當性，確認可以啟動， 則任務處理部13生成消息56，執行初始的「提案」任務。然後，該消息56在承擔要處理由過程55定義的各個任務的職責的過程支持工具10之間流通。消息56在各個過程支持工具10中，通過作為消息管理部起作用的處理部13，由資料庫50管理。在啟動過程55時，即生成消息56時，任務處理部13將自身的歸屬許可信息53存儲在該消息56內。因為在該歸屬許可信息53中包含存在於該消息56的流通路徑上的成員的公鑰，所以，以後各個成員可以使用該歸屬許可信息53適當地進行該消息56內的各種數據的驗證。該「批准」過程按照「提案」任務一「提案書整理」任務一「提案者籤名，，任務的流程進行處理，但因為上述任務定義應該由職責「職員，，的成員執行，所以通過啟動該「批准」 過程的成員「佐藤一郎」的過程支持工具10，在任務處理部13的控制下連續地執行。任務處理部13每次處理對象的任務時，將其處理結果追記在該消息56內，標記電子籤名。另一方面，其後的「確認」任務定義為應由職責「課長」的成員執行。因此，(成員 「佐藤一郎」的過程支持工具10的)任務處理部13，參照歸屬許可信息53，識別對於成員 「佐藤一郎」來說的「課長」是成員「田中二郎」，使用歸屬許可信息53中包含的「用於消息交換的信息」，向成員「田中二郎」的過程支持工具10，傳送該消息56。並且，收到該消息56的(成員「田中二郎」的過程支持工具10的)任務處理部13，使用歸屬許可信息53中包含的前一個任務的成員的公鑰，驗證追記在該消息56內的標記電子籤名之前的處理結果，如果其正當性得到驗證，則開始自身的「確認」任務的處理。下面，同樣地，將由成員「田中二郎」進行的任務的處理結果追記在該消息56內，根據歸屬許可信息53識別相對於成員「田中二郎」的部長是成員「鈴木三郎」，並將該消息56傳送給成員「鈴木三郎」。此外，在同一個組100內，在其他課或部，即不是由成員「田中二郎」、成員「鈴木三郎」任「課長」、「部長」的(職責「職員」的)成員啟動該「批准」過程的情況下，該消息56 根據該成員的歸屬許可信息53，適當地確定相對於該成員的「課長」、「部長」並傳送。在各個過程支持工具10中，任務處理部13根據作為控制語句而預先定義的語句處理各個任務。控制語句例如可以如下設定。 變量值向用戶的顯示、變量由用戶進行的編輯、向變量的代入、運算、字符串操作·由用戶的私鑰進行的電子籤名·常數定義、變量的層次定義·時間戳(相對於e文檔(標記電子籤名的電子文檔)，獲取服務提供者的時間戳) 向數據文件或資料庫的寫入、讀出。向e文檔的文件夾或資料庫的保管·條件分支(包含下一個任務控制)、待機、重複·其他消息生成(其他過程啟動)除了變量值的編輯等必需用戶操作的情況以外，按照任務的規定，自動地進行處理。例如，在圖8A中，「提案者籤名，，任務是「sign」，生成由「提案日」或「文件名，，等組成的「批准書」，通過職員的私鑰進行電子籤名，但與變量相對應的動作全部通過「參照」而僅引用在以前的任務中已經使用的值，自動地處理。此外，任務處理部13在任務的控制語句中引用變量的情況下，依次追溯以前的任務的處理結果信息，將初始檢測到的處理結果中的設定值視為此時的值，進行處理或顯示。圖10是表示本工作流系統中的過程55(消息56)的處理順序的一個例子的流程圖。首先，在歸屬於某一個組100的某一個過程支持工具10的任務處理部13的控制下，進行該組100中定義的某一個過程55的選擇(步驟Al)。在進行該選擇時，任務處理部 13根據該過程55中標記的上級的電子籤名、歸屬許可信息53中包含的上級的公鑰，驗證該過程55的正當性(步驟A2)，此外，根據歸屬許可信息53，驗證是否可以啟動該過程55 (步驟 A3)。在經過該過程55的正當性的驗證及可否啟動的確認後，任務處理部13生成消息 56 (步驟A4)。消息56例如作為由XML記載的文本數據生成，包含消息ID、組ID (包含在過程ID內的情況下不需要)、過程ID、提出者的歸屬許可信息53。消息ID是在系統整體中作為唯一值而在此時生成的。例如，通過該過程支持工具10的工具ID+生成時刻信息+每當在單位生成時刻內生成消息而遞增的序列號的組合分配。另外，也可以包含提出者的使用許可信息M或過程本身。使用許可信息M用於後述的初始用戶處理等。並且，任務處理部13開始由過程55定義的初始任務的處理(步驟A5)。如果假定生成由圖8A及圖8B例示的「批准」過程相對應的消息56，則初始的任務是「提案」任務，其控制語句是「edit」，即「編輯」，任務處理部13例如提示圖11所示的作業畫面，促使用戶進行各個項目的輸入。如圖8A及圖8B所示，因為該「提案」任務是在變量「文件名」、變量「批准內容」、變量「批准金額」、變量「金額單位」及變量「批准類型」中輸入值，所以，將這些輸入區域配置在作業畫面上而進行提示。這時，任務處理部13使用用戶接口部14。如果該任務處理完成，則任務處理部13首先將其處理結果(成功/失敗等)或作業畫面上的輸入值或運算處理結果等，作為處理結果信息記錄在消息56中(步驟A6)。另夕卜，任務處理部13將自身的工具ID (處理者信息)同樣地作為處理結果信息記錄在消息56 中(步驟A7)。此外，任務處理部13例如將作業結束時刻等(其他關聯信息)同樣地作為處理結果信息記錄在消息56中(步驟A8)。如果將處理結果信息記載在消息56中，則任務處理部13檢查當前任務是否是最後的任務(「完成」；控制語句「terminate」)(步驟A9)。如果是最後的任務(步驟A9中的否)，則確定下一個任務，將其任務ID作為(下一個)處理結果信息存儲在消息56中(步驟A10)。在下一個任務ID未被指定為任務的處理結果的情況下，選擇過程55中當前任務的下一行記載的任務。另外，任務處理部13根據對應的過程55和歸屬許可信息53，確定前面確定的下一個任務的處理者，將其工具ID(處理者信息)作為(下一個)處理結果信息記錄在消息56 中(步驟All)。下一個任務處理者作為任務的處理結果也被確定。如果該負責人信息未包含在消息內的歸屬許可信息53中，則在該負責人當值時，將該負責人的歸屬許可信息53追記在消息56中(用於相對於處理結果的電子籤名的驗證)。並且，任務處理部13以相對於消息56追記之前的記錄內容為範圍，追加電子籤名 (步驟A12)。在這裡，參照圖12及圖13，說明如上所述通過過程支持工具10的任務處理部13 附加處理結果信息的消息56的一個結構。圖12是用於說明相對於消息56的處理結果信息的追記順序的一個例子的概念圖。區域bl的信息在前一個任務完成時，由前一個任務的處理者設定為下一個任務信息。 另外，區域1^2表示初始的任務處理者標記電子籤名時的範圍的例子，區域b3表示下一個任務處理者標記電子籤名時的範圍的例子。另一方面，圖13是表示按照上述順序追記處理結果信息的消息56的一個例子的圖。然後，任務處理部13判定前面確定的下一個任務的處理者是否是其他用戶(步驟 A13)。並且，如果是其他用戶(步驟A13的是)，則任務處理部13根據歸屬許可信息53，向該其他用戶的過程支持工具10發送消息56(步驟A14)。另一方面，在作為下一個任務處理者的用戶的過程支持工具10中，任務處理部13 根據上一個任務之前的處理者標記的電子籤名和包含在歸屬許可信息53中的上一個任務之前的處理者的公鑰，驗證該消息56的正當性(步驟A15)，並且，根據該過程55附帶的上級的電子籤名和歸屬許可信息53中包含的上級的公鑰，驗證與該消息56相對應的過程55 的正當性(步驟A16)。並且，在經過該消息56的正當性及與該消息56相對應的過程55的正當性的驗證之後，任務處理部13開始由前一個任務的處理者追記在消息56中的當前任務的處理(步驟A17)。
以後，與前一個任務的處理者(的任務處理部13)同樣地，任務處理部13實施從步驟A6開始的處理，執行向消息56的處理結果信息的追記等。並且，在當前任務為最後任務的情況下(步驟A9的是)，任務處理部13向處理結果信息標記電子籤名，結束與該消息 56相關的處理(步驟A18)。任務處理部13可以通過用戶接口部14向用戶提示消息56的一覽表，或消息56 的處理結果信息或進展狀況。在消息56中作為過程處理結果的成果物生成e文書。在圖8A所示的「批准」過程的情況下，「提案者籤名」任務的「sign」即由佐藤一郎的電子籤名後的「提案日」、「文件名」、「提案者」等組成的e文書「批准書」生成在圖12的「(作為成果物的e文書)」的位置。並且，在該「批准」過程中，職員電子籤名後的批准書中重複課長、部長的電子籤名，成為通過其後的任務標記「文件名，，的文件名，存儲在任務內指定的文件夾中。流通的信息(使用許可信息54、歸屬許可信息53、過程55、消息56)，全部通過電子籤名驗證是否未被更改，對於無正當的籤名或不正確的消息，不進行處理，而將錯誤消息通知給用戶。如圖2所示，在本工作流系統中，1個過程支持工具10有可能歸屬於多個組100。 因此，在本工作流系統中，通過消息協調或其他消息生成，也包括在不同的組100之間，實現過程的協調。S卩，在本工作流系統中設置控制語句，其作為過程55內的1個任務，用於任務處理部13進行(在本身許可的範圍內)過程55的啟動(消息56的生成)。另外，相對於本身當值的消息56，可以在控制語句中進行設定，以根據組ID、過程ID、任務ID、消息ID、變量值等檢索該消息56或監視該消息56到達，在檢測到的情況下，進行特定的處理。也可以在控制語句中記載為，在檢測對象的消息56為用戶等待編輯的任務的情況下，自動處理向該任務的編輯對象變量的代入。另外，也可以在控制語句中設定為，相對於檢測對象的消息56，將編輯對象的變量細分化。在圖1所示的例子中，S公司的X部門伺服器、N公司的Y部門伺服器分別歸屬於組3、組2，與此同時，這各個伺服器也歸屬於組4。參照圖14，說明在這種狀況下，在歸屬於這3個組100的各個伺服器中，使組4的過程55、組3的過程55、組2的過程55協調的一個例子。首先，在S公司(X部門)-N公司(Y部門)之間的組4中，假定已經定義「訂貨/ 接受訂貨」過程。作為該「訂貨/接受訂貨」過程，相對於X部門的過程支持工具10、γ部門的過程支持工具10，各個公司的負責人可以直接輸入編輯項目，開展任務，但是，進行改善以使得在各個公司間使各自的過程協調，以減少人手介入的情況。即，在S公司中使用於在組3中訂貨的「訂貨管理」過程與「批准」過程協調，在N公司中，使組2中「接受訂貨處理」 過程協調。結果是，從在S公司的訂貨批准提案經由公司間的」訂貨/接受訂貨」到N公司的「接受訂貨處理」過程，跨過組100而使過程協調。在這種情況下，S公司X部門在組3中，承擔管理用於(在S公司內的)訂貨的批准文件的職責，並且，接受該職責後，在組4中承擔(相對於N公司)發布訂貨書的職責，另一方面，N公司Y部門在組4中承擔接受(來自S公司的)訂貨書的職責，並且，接受該職責，在組2中承擔啟動(N公司內的)「接受訂貨處理」過程的職責。首先，如果S公司的職員C啟動「訂貨管理」，則最初的「批准過程生成」任務啟動 「批准」過程。這是以職員C的「批准」過程啟動許可記載在歸屬許可信息53內的情況為前提。然後，通過「編輯項目細分化」任務將「批准」過程的「提案」任務中的用戶編輯項目「批准內容」，細分為「合約目的」、「合約文件名」、「合約金額」、「成果物」、「繳納期」、「甲」、 「乙」、「合約目標選定理由」。該處理後的「批准」過程的啟動畫面例子如圖15所示，雖然是與圖11相同的過程、相同的任務，但將「批准內容」細分化(圖15的Cl)。由此，可以不變更主幹過程本身，而通過使「訂貨管理」過程這樣的分支過程協調化，而改善過程整體。然後，「訂貨管理」過程在X部門中，在「批准書監視」任務中，以消息ID和批准書內的變量值為基礎，監視該批准被認可。如果檢測到批准被認可，則在「訂貨/接受訂貨過程生成」任務中生成「訂貨/接受訂貨」過程，在「訂貨書記錄」任務中從批准書向訂貨書轉記所需的項目。此外，在圖14中，一定時間內未檢測到批准書的情況下的處理等例外處理任務全部省略。「訂貨/接受訂貨」過程由「訂貨管理」過程自動地生成，通過由「訂貨書記錄」任務自動設定相對於初始的任務即「訂貨書發布」任務需要編輯的全部項目而完成任務，作為 「申請書發布」任務向N公司Y部門傳送。在N公司Y部門，預先啟動的「訂貨處理」過程通過「訂貨監視」任務監視「訂貨/ 接受訂貨」過程的到達，如果檢測到，則通過「接受訂貨處理過程生成」任務，啟動其他的「接受訂貨處理」過程，以用於後續的「訂貨/接受訂貨」過程監視，而自身則通過後面的「訂貨內容轉記」任務，從訂貨書獲取必要的信息並存儲在變量中，在「申請書發布」任務中設定相對於自身承擔的「接受訂貨，，過程的「申請書發布」任務所需的編輯項目，進入「訂貨處理」 任務。此外，在上述流程中，在N公司「接受訂貨，，過程中不生成「訂貨處理」過程，而在檢測到「接受訂貨」過程到達的情況下，使「訂貨處理」過程通過，但這是以「接受訂貨」過程不僅是N公司、S公司而是多個公司之間可以使用，且無法變更規格為前提。在這種情況下，也可以使分支過程的「訂貨處理」與主幹過程即「訂貨/接受訂貨」的過程協調，從而改
善過程整體。說明過程協調的構造。通過由消息生成記載的任務生成的消息56或在控制語句設定的條件下檢測到的消息56，其消息ID作為標的消息記錄在處理結果信息中，在後面的任務中，檢測到新的標的消息之前，或者，在實施者改變之前，在任務控制時作為標的消息處理。標的消息可以按照 、的方式處理多個標的消息。在控制語句中，通過指定「標的消息1(變量1)」，可以與本過程55內的變量同樣地進行代入處理。此外，可以代入處理的，是用戶等待標記標的消息的任務的情況。在成為其他消息56的標的所需的項目全部設定了值的情況下，通過例如過程55 的控制語句內記載該內容而進行控制，如果已經設定，則立即完成任務，或是為了保留用戶再編輯的餘地而完成需要用戶主動地進行意思表示。如果執行控制語句中設定的任務而將編輯對象細分化，則細分化對象的變量(在圖15的例子中是「批准內容」)和下級變量(在圖15的例子中是「合約目的」、「合約文件名」等)的定義信息，被記錄在標的消息側的當時的任務的處理結果信息中，在其後的任務中顯示促使用戶編輯而設定的信息時，處理細分化後的下級變量。在檢測到的標的消息側檢測到的一側的消息ID及「已啟動」標誌被設定在消息內，控制使其不再啟動，即不再作為標的消息進行處理。在檢測一側的過程55的控制語句中設定啟動類別，通過將其作為「已啟動」標誌記錄，相對於該過程55的該任務不再啟動，但可以接受來自不同過程55或任務的啟動。另外，也可以不設定「已啟動」標誌，而進行任意重新啟動多次的指定。此外，因為在檢測到一側的標的消息的管理，及檢測到的標的消息側的啟動源消息ID、「已啟動」標誌的管理是僅當值的用戶管理即可的信息，所以，並不是記錄在消息內， 而是可以作為消息管理的附屬信息，在過程支持工具10內另外管理。由此，在本工作流系統中，因為使自身承擔的任務作為消息自行管理，所以不實現現有一般的伺服器型的工作流系統中必需的對系統管理者的調整，可以在承擔的範圍內， 自行衡量而進行由過程協調進行的改善。例如，可以本身作為上級，使分擔業務的成員和組聯合，通過重新定義用於實現本身承擔的任務的過程並使其協調，實現任務的細分化和妥協。由此，例如，在本公司內定義主幹過程，對應於事業內容或事業展開的國情，在事業部中增加定義分支過程，對應於所處理的業務內容或負責人的特性 技能，增加定義分支過程，從而通過對應於實際的組織構造或職責，將過程層次化而定義並使其協調，作為整體，可以形成最優過程。通過特定的負責人或崗位而可以進行局部的過程改善，如果是良好的過程，則可以依次轉用至相鄰的崗位，最終，可以將「要加入事業部的標準過程」 「要加入整個公司過程」這種流程加入日常業務。由此，可以配合環境變化，實現過程的進化。另外，本工作流系統通過由P2P型實現工作流系統，從而可以以當事人的衡量將希望聯繫的用戶組成組，定義過程並使其協調。在希望聯繫的主體之間，因為可以依次聯繫，所以可以認為作為系統整體具有無限的收容能力，可以實現無限的過程協調。此外，在本工作流系統中，因為可以作為e文書生成過程的處理結果或成果物，所以容易進行證據 證跡的確認，容易分段進行過程改善。另外，可以實現證據 證跡的層次化、反覆流通，可以以相同的形式，通過電子方式實現使用紙張在真實世界進行的傳送·蓋章·附加·保管等過程，例如附加他人發布的保證書而提出申請書等。此外，本工作流系統並不限定於上述實施方式中說明的內容，可以進行各種變形。如果是在目錄伺服器的使用等中，在需要的時候容易獲取所需的成員的公鑰的環境，則成員信息51或歸屬許可信息53中的成員的公鑰保持不是必需的。可以選擇使消息大小或消息處理時間中的哪一個優先。在消息56的基礎上，通過控制消息的收發，可以實現消息送達確認或進展通知、 用戶控制信息傳遞(過程中止、返回等)等。在消息發送的過程中，在發送消息56中的全部信息的方式的基礎上，也可以採用下述方式，即，消息56本身由來自關聯成員可訪問的伺服器的共享文件夾或資料庫管理， 僅將包含保存位置和消息ID的當值通知作為控制消息發送。在多個類似過程55中，設定相同的「業務種類」，在歸屬許可信息53中也可以以「業務種類」為單位設定許可過程。另外，歸屬許可信息53和過程55可以分別包含年代編號、有效期信息等。在信息有更新的情況下，使年代編號增大。在預約變更的情況下，在當前信息中分配追記「結束日期」的版本和最新信息的版本(標明開始日期)這兩個信息。另外，也可以定義初始用戶處理過程，即使在歸屬許可信息53中未許可，其也可以由組成員中的某一位提出，或使組成員以外的用戶可以提出或承擔任務。在這種情況下， 在該任務處理中對應於需要，相對於該成員賦予該過程55內的職責。在成員以外的用戶的情況下，向消息56中取代歸屬許可信息53而添加使用許可信息M。這是為了使向處理結果信息的籤名驗證用的公鑰信息流通。在目錄伺服器使用等中，在需要的時候可以容易地獲取所需的用戶公鑰的環境的情況下或不需要用戶公鑰等的情況下，也並非必須添加使用許可信息M。也可以定義不需要向處理結果的籤名的過程。在過程定義中，可以取代職責，設定確定過程支持工具10的工具ID。組織內的多個用戶可以登錄到圖1中的X部門等的組織用的過程支持工具10。通常最大只有1個人賦予任務執行的權限，而其他用戶僅可以參照。在僅賦予參照權的用戶必須進行作業的情況下，在自己用的過程支持工具10中進行作業，通過定義使結果進行過程協調的過程並運用，可以適當地保持內部統一管理。
權利要求
1.一種工作流系統，其利用多個工作流支持程序依次對由多個任務組成的過程進行處理，該多個工作流支持程序搭載在大於或等於1臺計算機中，被分配上述多個任務中的至少1個任務，其特徵在於，上述多個工作流支持程序分別具有組生成單元，其定義作為成員而歸屬的各個工作流程序的職責，並且生成組；過程定義單元，其定義過程，該過程由多個任務組成，並指定應承擔各個任務的成員的職責；以及過程處理單元，其處理由上述過程定義單元定義的過程內的任務，將包含表示與該過程相關的各個任務的處理結果及進展狀況的信息的消息，向定義為應承擔下一個任務的職責的工作流支持程序傳送，在通過上述組生成單元生成的組內，通過在上述多個工作流支持程序之間依次傳送與該過程相關的信息，對通過上述過程定義單元定義的過程進行處理。
2.如權利要求1所述的工作流系統，其特徵在於，上述組生成單元包含下述單元對於歸屬於組的每一個成員，生成歸屬信息，並將該歸屬信息分別向作為成員的組內其他工作流支持程序提供，該歸屬信息定義該成員在該組內與過程的處理相關的動作可能範圍及與相關聯的其他成員的聯繫，上述過程處理單元包含下述單元根據上述歸屬信息，判斷可否對上述過程內的任務執行處理，並且，確定上述消息的傳送目標。
3.如權利要求1或2所述的工作流系統，其特徵在於，上述過程處理單元包含下述單元將表示各個任務的處理結果及進展信息的信息追記在上述消息內。
4.如權利要求1至3中任意一項所述的工作流系統，其特徵在於，上述過程定義單元包含下述單元將與定義的過程相關的信息，分別向通過上述組生成單元而成為成員的組內其他工作流支持程序提供，上述過程處理單元包含下述單元根據與上述過程相關的信息， 對上述過程內的任務進行處理。
5.如權利要求1所述的工作流系統，其特徵在於，上述多個工作流支持程序，分別在可以作為成員而歸屬於多個組，並且，可以作為成員而歸屬於其他工作流支持程序通過上述組生成單元生成的組的狀態下，可以通過自身的上述組生成單元生成新的組。
6.如權利要求1所述的工作流系統，其特徵在於，上述過程定義單元可以在1個工作流支持程序中，定義包含下述任務的過程，該任務是生成不同過程，以用於作為第1過程內的任務處理而生成第2過程。
7.如權利要求1所述的工作流系統，其特徵在於，上述過程定義單元在1個工作流支持程序中，可以定義包含下述任務的過程，該任務是檢測與不同的過程相關的消息，執行對該檢測到的消息的處理，以用於作為第1過程內的任務處理而取代應由第2過程執行的處理。
8.如權利要求1所述的工作流程序，其特徵在於，上述過程處理單元包含下述單元將上述過程的處理結果或成果物，作為標記了電子籤名的電子文書附加在上述消息中。
9.如權利要求3所述的工作流系統，其特徵在於，上述多個工作流支持程序分別還具有篡改對策單元，其相對於上述歸屬信息、上述與過程相關的信息、上述消息內追記的表示各個任務的處理結果及進展信息的信息中的至少一個，標記電子籤名，或者，通過上述信息中附帶的電子籤名驗證從其他工作流支持程序接收到的上述信息未被更改。
10.一種信息處理裝置，其與經由網絡連接的其他信息處理裝置協同動作，處理由多個任務構成的過程，其特徵在於，具有組生成單元，其定義作為成員而歸屬的信息處理裝置的各自的職責，並且生成組； 過程定義單元，其定義過程，該過程由多個任務組成，並指定應承擔各個任務的成員的職責；以及過程處理單元，其處理由上述過程定義單元定義的過程內的任務，將包含表示與該過程相關的各個任務的處理結果及進展狀況的信息的消息，向定義為應承擔下一個任務的職責的信息處理裝置傳送。
11. 一種工作流支持程序，其特徵在於，使與經由網絡連接的其他信息處理裝置協同動作，處理由多個任務構成的過程的計算機作為下述單元起作用組生成單元，其定義作為成員而歸屬的計算機的各自的職責，並且生成組； 過程定義單元，其定義過程，該過程由多個任務組成，並指定應承擔各個任務的成員的職責；以及過程處理單元，其處理由上述過程定義單元定義的過程內的任務，將包含表示與該過程相關的各個任務的處理結果及進展狀況的信息的消息，向定義為應承擔下一個任務的職責的信息處理裝置傳送。
全文摘要
本工作流系統通過多個過程支持工具(10)經由網絡協同動作而構成。使某個過程支持工具(10)成為上級，形成組(100)，定義組(100)的各個成員的職責和由多個任務構成的工作流(過程55)。並且，該組(100)的各個成員根據定義的成員的職責，確定下一個任務的處理者，同時處理過程(55)，並使追記其結果的消息(56)依次在成員間流通。
文檔編號G06Q10/00GK102576429SQ20098016183
公開日2012年7月11日 申請日期2009年10月7日 優先權日2009年10月7日
發明者中島裕文 申請人:中島裕文