专利名称：工作流系统及工作流系统的管理方法
技术领域：
本发明涉及一种工作流系统，详细地说是涉及一种按照被定义的顺序推进各工序的确认处理或完成通知的处理的工作流系统。
背景技术：
历来，在企业中的业务进度中通常都要涉及到大量的担当者。具体地说，例如在一个担当者处理了某个作业内所决定的工序后，将作业转交给下一个担当者，被转交的下一个担当者接着上述工序进行下一工序的处理。通过这种反复来完成1个作业。另外有时通过多个作业构成一个业务。
作为管理这种预定作业中的各工序的进度的手段，引入了工作流系统。用于预定计划的确认的工作流系统有时也叫做组件。例如，当某计划需要上级确认时，使用利用了计算机网络的传阅方式从营业员开始请求主任、科长、部长甚至总经理进行确认，如果没有问题则作为计划而被许可(执行)。另外，在管理作业的进度时，各担当者处理自己所负责的“作业的一部分”即工序，当转交给下一个担当者时将该工序已完成的意旨(完成的通知)等作为进度状况输入到工作流系统中。通过该输入，下一个担当者就能够处理下一工序，同时作业整体的进度情况就得以管理。
特开平9-138824号公报。
发明内容
目前的工作流系统只以比较简单的作业作为对象，但是在规模较大的情况下存在着复杂的作业，即业务。这里，将由多个担当者顺次处理的多个工序所构成的情况定义为作业。进一步，定义为包括相互关联的工序的多个作业构成业务。这里所说的“相互关联”是指构成一个作业的工序和构成其他作业的工序之间有关系。
上述业务的一例表示在图13中。业务1301由多个作业(作业1～作业4)构成，该各作业由多个担当者(担当者A～I)并行进行。另外，作业1由多个工序(工序1A～工序1C)构成。
在这种情况下，在工作流系统中只按每个作业独立地进行确认(工序)或作业完成的通知(工序)，有时将产生确认或作业的浪费。
即，一个业务1301被所有的担当者所确认，或所有的作业完成后才作为业务成立。例如考虑尽管作业1顺利地被担当者A～担当者C确认或完成，但是其他的作业3未能被担当者G承认或完成的情况。在这种情况下，业务1301结果未能被确认。因此，将会产生以下问题，即，由担当者A、B、C、D、E、F、H、I进行的确认工序的处理或未完成的作业自身就成为浪费。
具体地说，例如在同时进行新产品开发(许可)的请求和其样品的发送的请求时，尽管对于样品的发送准备的处理已全部完成，但是如果新产品开发未被许可，则有关样品的所有作业就会浪费。
本发明就是根据上述目前的状况所提案的，其目的是提供一种即使是由多个作业组成的业务也可没有浪费地管理进度状况的工作流系统及其管理方法。
本发明为了达到上述目的而采用以下方法。即，本发明以管理由多个担当者顺序处理的多个工序所组成的作业的进度状况的工作流系统作为前提。
在这种工作流系统中，定义信息存储单元存储工作流定义信息，上述工作流定义信息预先将作业类别和多个担当者处理构成该作业的各工序的顺序对应起来。
通过将输入画面发送到担当者的终端，接受输入到该输入画面的内容，请求接受单元将包括相互关联的工序的多个作业作为1个业务来接受。
担当者决定单元针对请求接受单元所接受的业务，根据上述工作流定义信息、按构成业务的每个作业，决定处理该作业的各工序的担当者和该处理的顺序。接着，当由担当者处理了构成一个作业的工序时，判断单元判断是否已对构成其他作业并和该被处理的工序相关的其他工序进行了处理。
当判断单元判断上述相关的其他工序全部被处理时，处理许可单元对构成该业务的作业许可进行下一工序的处理。
通过以上处理，当一个担当者在某个工序中进行了不得不中断业务的执行的处理(判断)时，就可未然地防止先行进行了结果并不需要的其他工序之类的问题。
再有，作为赋予许可的构成，具有以下构成，即，只有在对于来自担当者的询问，与对应询问的作业相关的工序处理被许可的情况下，处理接受单元发送用于处理的画面。
该构成中，由于担当者不能取得未被许可的处理的画面，所以其结果就不能对未被许可的工序进行处理。
再有，当担当者进行的工序的处理是表示不可继续该作业的处理时，处理许可单元通过停止关于该业务的所有进度来结束业务本身。
作为上述工序的处理，有作业的确认处理或作业完成的通知处理等，作业完成的通知处理是表示接受、回答、进货、发货等已完成的通知等。
这里，上述工作流系统能够利用计算机进行实现。这时候，除存储单元的上述各单元通过在计算机上运行程序而被实现。另外，存储单元通过HDD(Hard Disk Drive)或各种存储器而被实现。
在本发明的工作流系统中，按作业决定处理各工序的担当者及该工序的顺序，当处理各工序时，判断是否对其他的作业进行了对应的工序，如果尚未进行就停止业务的进度。这样，当一个担当者进行了不得不中断业务的执行的处理时，就可未然地防止先行进行了结果并不需要的其他处理之类的问题。
图1是构成工作流系统的终端、应用服务器、DB服务器的概要功能框图。
图2是应用服务器的概要构成图。
图3是表示工作流系统的系统构成例的图。
图4是表示工作流定义信息的一例的图。
图5是工作流主信息的一例及业务的形象示意图。
图6是表示工作流信息的状态转换的图。
图7是请求处理的流程图。
图8是各作业处理的流程图。
图9是表示请求输入画面的一例的图。
图10是表示工作流主画面的一例的图。
图11是表示工序处理画面的一例的图。
图12是表示工序处理画面的其他例子的图。
图13是说明以往的工作流系统中的业务转换的图。
具体实施例方式
以下，参照附图对本发明的实施方式进行说明，以供对本发明的理解。另外，以下的实施方式是将本发明具体化了的一例，并不具有限定本发明的技术范围的性质。另外，如图1所示那样，本发明的工作流系统通过网络将终端101、应用服务器102、DB(数据库)服务器103分别可通信地进行连接，但例如也可将应用服务器102和DB服务器103设置在同一个计算机上。
<实施方式1>
下面，关于本发明的实施方式1的工作流系统的处理进行说明。
图1是构成工作流系统100的终端101、应用服务器102、DB服务器103的概略功能框图，有关各单元的处理等将在后面论述。
另外，图2是应用服务器的概略构成图，通过内部总线206将CPU201(中央处理器)、RAM(随机存取存储器)202、ROM(只读存储器)203、HDD204及网络I/F(接口)205进行连接。上述CPU201例如将RAM202作为作业区域进行利用，通过执行存储在ROM203和HDD204等中的程序作为上述图1所示的各单元进行动作。上述网络I/F205和网络相连，可与其他设备进行数据的收发。另外，终端101、DB服务器103的构成也和上述应用服务器102一样，可利用上述所存储的不同程序，而执行不同的处理。
图3是工作流系统100的系统构成例，多个请求者终端101(担当者终端113)、应用服务器102、以及DB服务器103通过因特网301或内联网302等网络可通信地进行连接。另外，在请求者终端101或担当者终端113与应用服务器102进行通信的前段，例如通过认证系统303对利用该担当者终端113的用户(担当者)进行认证，但是由于和本发明没有直接关系故省略其细节。
接着，对工作流系统100中的处理进行说明。另外，为了便于理解，将以下所处理的业务具体地设为“与移动电话的下期模型相关的业务”。在该业务中，作为营业担当的请求者将以下4个相关联的作业，即4个工作流作为1个业务进行登录。
作业1·请求移动电话事业部新开发移动电话作业2·进而请求经理部决定移动电话的销售价格作业3·进而请求3个用于分配给销售方的样品作业4·请求用于发放给相同销售方的移动电话的英文版说明书1份和日文版说明书一份最初，如图7所示，作为营业担当的请求者利用请求者终端101进行用于登录业务的请求处理。这时，在请求者终端101，请求者在终端上启动该终端中所安装的请求输入单元(请求画面)，或者通过向应用服务器102要求请求输入单元而取得请求画面(图7S701)。再有，这里假设从应用服务器102取得请求画面。
这时，请求接受单元105根据请求者的指示把预先存储在例如DB服务器103内的工作流定义信息存储单元107中的、可作为程序操作的脚本作为请求输入单元104发送到请求者终端101(图7S702→S703)。上述请求输入单元104在请求者终端101上被执行，例如图9所示的请求输入画面900被显示在请求者终端101的显示器等显示单元上。
上述请求输入画面900中，作为当前正利用请求者终端101的用户(这里设有“伊藤”)的名称的请求者名称901、可唯一识别该请求者的请求者代码902以及由多个作业所构成的业务期限903被可输入地进行显示。
另外，设置有作为构成上述业务的作业的作业类别905的项目。作业类别905在这里由样品906、技术资料907、价格裁决908、新产品开发909构成，请求者可选择多个希望请求的作业类别。
这里，上述样品906是用于把预定的样品送到预定的地点的请求，若选择样品906，则下级的“样品请求”项目变成可输入状态。在“样品请求”项目中可输入(选择)例如样品名称910、样品件号911、数量912、作为样品交货期的指定交货期913以及样品的发送目的地914等。该处理相当于上述“作业3.”。
另外，上述技术资料907是把例如技术资料发送给请求者的请求，若选择技术资料907，则下级的“技术资料”项目成为可输入状态。在“技术资料”项目中可输入(选择)例如技术资料名称920、技术资料No.921、英语文献数量922、日语文献数量923等。该处理相当于上述“作业4.”。
进而，上述价格裁决908是对例如商品裁决的担当部署的请求，若选择价格裁决908，则下级的“价格裁决”项目成为可输入状态。在“价格裁决”项目中可输入(选择)例如担当部署930、商品名931、商品的原价932、交货个数933等。该处理相当于上述“作业2.”。
进而，上述新产品开发909是对例如新产品开发的许可的请求，若选择新产品开发909，则下级的“新产品开发”项目成为可输入状态。在“新产品开发”项目中可输入(选择)例如请求部署940、请求内容明细941等。该处理相当于上述“作业1.”。
另外，上述作业类别以及各项目的内容只不过是一例，工作流系统应管理的作业类别、项目等根据系统的不同设置必要的项目即可。本发明可在1个业务中混合存在多个作业类别。
另外，在本实施方式中，如请求输入画面900所示那样，设输入了请求者名称901“伊藤”、请求者代码902“IT0045”、业务期限903“2004/12/10”，在作业类别905中选择了样品906、技术资料907、价格裁决908、新产品开发909中的全部。
进而，设在“样品请求”项目中输入了样品名称910“移动电话”、样品件号911“MBP228”、数量912“3”、指定交货期913“2005/2/1”、发送目的地914“营业2课”。
另外，设在“技术资料”项目中输入了技术资料名称920“移动电话说明书”、技术资料No.921“MBPEXP228”、数量(英语)922“1”、数量(日语)923“1”。
进而，设在“价格裁决”项目中输入了担当部署930“经理部”、商品名931“移动电话”、原价932“10000日元”、交货个数933“2000个”。
进而，设在“新产品开发”项目中输入了请求部署940“移动电话事业部”、请求内容明细941“请求120g以下的小型移动电话的开发许可”。
请求者根据需要输入上述项目，请求者通过按下输入按钮950，该请求内容由上述接受单元105所接收(图7S705→S706)。
当上述请求接受单元105接受上述请求内容后，担当者决定单元106将业务No.(这里例如为“A00101”)附加给接受到的业务，根据工作流定义信息存储单元107中所存储的工作流定义信息，按构成该业务的每个作业(样品、技术资料、价格裁决、新产品开发)来决定进行构成该作业的各工序的处理的担当者以及该处理的顺序(图7S707)。
这里，对上述担当者决定单元106的处理的具体细节进行说明。图4中示出上述工作流定义信息的一例。在图4所示的工作流定义信息401中存储有作业类别402、附加信息406、工序403、顺序404、担当者405。
另外，作业类别402是明示何种作业的项目，对应上述所说明的作业类别905。再有，这里所示的作业类别是一例，按照作业准备各种各样的作业类别。
另外，附加信息406保存着可确定所对应的作业类别的担当部署的信息。例如即使是相同的作业类别“样品”，由于担当部署(管理部署)因样品的类别而各种各样，所以例如从所输入的请求内容和该附加信息406来确定是哪个作业类别“样品”。换言之，在样品411和样品415中后述的担当者完全不同。因此，即使构成业务的作业类别相同，工作流的流程控制也完全不同。
例如在这里，根据样品名称910“移动电话”以及样品件号911“MBP228”来选择样品411。同样，根据请求内容来选择技术资料412、新产品开发413、价格裁决414。
工序403记述着选择上述作业类别时所进行的处理的内容，例如对应“样品”的处理内容为“接受”“回答”“进货”“出库”。但是，在工作流系统仅仅管理单一种类的处理时则未必需要。
顺序404表示进行上述处理内容的顺序。另外，担当者405是进行上述工序的担当者的名称。
另外，上述例子中，担当者决定单元106根据工作流定义信息401及请求输入的内容而自动决定作业类别，但是例如请求接受单元105将上述工作流定义信息401作为一览列表发送到请求者终端101，由请求者直接选择作业类别也无妨。
该担当者决定单元106所决定的担当者及工序的顺序，作为图5A所示的工作流主信息500被存储在DB服务器103的工作流主信息存储单元108中(图7S708)。这时，在该工作流主信息500中，除上述项目外，还存储着在请求输入画面900所输入的各项目。再有，虽然为了说明而存储为工作流主信息，但是不一定非要作为工作流主信息进行存储，例如在更新后述的工作流信息时每次参照工作流定义信息的情况下，就不需要后述的工作流主信息。
进而，为了便于理解，在图5B中示出上述图5A所示的工作流主信息的形象图。如该形象图所示的那样，业务(A00101)501由作业“样品”、“技术资料”、“新产品开发”、“价格裁决”所构成，按每个构成各作业的工序登录至少一个担当者。例如，样品的各工序的担当者为顺序“1”的工序“接受”是“田中”、顺序“4”的工序“回答”是“铃木”、顺序“5”的工序“进货”及顺序“7”的工序“出库”都是“小林”。当然，该内容对应于上述工作流定义信息401的样品411。另外，在各工序前所附加的数字意味着处理的顺序。另外，“-”符号表示没有担当者。
通过上述图5B可以得知，所选择的各种作业在本实施方式中，首先是进行各作业的“接受”，然后进行“新产品开发”的“回答”及“确认”。在得到“新产品开发”的确认后，并行进行“样品”和“技术资料”的作业，假定在这2个作业的“进货”工序的基础上有需要进行“价格裁决”的“回答”的业务。这种条件是根据工作流定义信息401的顺序404而决定的。
进而，上述担当者决定单元106创建如图6所示的工作流信息A，并存储在DB服务器103内的工作流信息存储单元109中(图7S709→S710)。该工作流信息A是根据上述工作流主信息或由上述请求输入单元104所发送的信息而作成的，图6所示的是一例，只要可由后述的判断单元111进行处理，则可以是任何形态。
存储上述工作流主信息500后，上述请求接受单元105将请求者输入的业务已被正常登录的信息通知给请求者终端101，该请求者终端101显示上述通知(图7S711→S712)。
通过以上的处理来完成业务的请求(登录)处理。
接着，对输入可否完成或确认与各担当者自己所担当的作业相关的处理的手续进行说明。
担当各工序的担当者，在希望自己所担当的工序的处理(输入)时，通过担当者终端113访问应用服务器102的处理接受单元110(图8S801)。另外，担当者终端113的构成也和上述请求者终端104相同。
在访问上述处理接受单元110时，由于经上述认证系统，所以在处理接受单元110可以知道是谁在进行访问。
这里假定上述担当者是“山下”。当山下进行访问时，处理接受单元110参照上述工作流信息，在“担当者”项目中检索有“山下”的信息。现在，工作流信息是工作流信息A的状态，不存在担当者项目为“山下”的作业。因此，处理接受单元110在作为程序所记载的脚本中存储“没有当前的担当作业”意旨的信息，并发送到作为担当者作业显示单元114的担当者终端113(图8S802)。由于这里没有担当者“山下”的作业，所以担当者不输入(确认)作业而结束处理(图8S802→结束)。
通过上述处理，即便在与担当者有关的作业被登录到业务中的情况下，在工作流信息的“担当者”中也不显示。因此，针对例如若在“新产品开发”未被确认的情况下进行该作业将有可能成为浪费的工序，担当者就不能够着手作业。
再有，即使工作流信息中没有担当者，处理接受单元110也可以暂时显示工作流主画面。工作流主画面的一例在图10中表示。工作流主画面1000中显示有当前正利用工作流系统的担当者名称1001、关于工作流的新到达信息1002和工作流列表1003。关于工作流主画面的具体例及各项目的详细，用下面的“后藤”的例子来说明。
上述工作流信息A的“担当者”以及“状态”根据各担当者通过上述请求输入单元104所发送的信息进行更新。例如，当由“田中”输入作业类别“样品”的“接受”工序的完成后，后述的处理接受单元110将对应于上述工作流信息A的“样品”的“状态”从“等待接受”更新为“完成”。另外，其他作业也并行地由其他担当者进行处理，当由“渡边”输入了作业类别“技术资料”的“接受”工序的完成后，同样，将对应于上述工作流信息A的“技术资料”的“状态”从“等待接受”更新为“完成”。同样，当由“林”输入了作业“价格裁决”的“接受”工序的完成后，将对应于上述工作流信息A的“价格裁决”的“状态”从“等待接受”更新为“完成”。
再有，上述处理接受单元110的详细处理内容也用下面的“后藤”的例子来进行说明。
根据上述各担当者“田中”、“渡边”、“林”的输入，上述工作流信息A被更新为图6的工作流信息B。工作流信息B，关于作业类别“样品”、“技术资料”、以及“价格裁决”，其状态为“完成”，关于作业类别“新产品开发”，其状态为“等待接受”。
接着，假定例如担当者“后藤”同样进行了访问。当接受该访问后，处理接受单元110将在工作流信息的担当者的项目中有“后藤”的业务全部抽出，显示在上述工作流主画面1000的工作列表1003中。这里，根据该工作流信息A的管理NO“A00101”以及作业类别“新产品开发”，由存储在工作流主信息存储单元108中的工作流主信息500取得相应工序的项目。作为取得的项目，例如是业务No.1005、业务期限903、请求者名称901、请求者代码902、作业类别905、工序1006。这里，业务No.1005是由请求接受单元105在请求的登录时所分配的业务No.(这里为“A00101”)。其他的业务期限903、请求者名称901、请求者代码902、作业类别905也是由已在请求输入画面中输入的信息和担当者决定单元106所决定的信息。另外，在已根据工作流信息取得时，在状态1004中记为“未处理”。另外，也可以将取代工作流信息而在工作流主信息中包括“后藤”的业务，全部抽出不包括在工作流信息中的信息。这时，还能够抽出如工作列表1003所示那样，状态1004为“已处理”的信息和虽然相当于工序的担当但尚不能输入的处理的信息(状态1004＝“预定”)。
取得了上述项目的处理接受单元110根据该取得项目创建工作流主画面1000，并作为作业输入单元115发送到担当者终端113(图8S802)。
接着，若担当者“后藤”通过工作流主画面1000，选择状态1004为“未处理”、即未处理的工序1007，则进行了该选择的意旨被发送到处理接受单元110。
接受了该意旨的处理接受单元110根据业务No.1005“A00101”由工作流主信息取得预定的项目。具体地说，就是对应业务No.“A00101”和担当者“后藤”的作业类别“新产品开发”、处理内容“接受”、以及请求时所输入的、对应于请求部署940的“移动电话事业部”、和对应于请求内容明细941的“请求120g以下的小型移动电话的许可开发”等。
接着，上述处理接受单元110根据上述所取得的项目创建例如图11所示的工序处理画面1100，并作为作业输入单元115发送到担当者终端113，由此显示在担当者终端113的显示装置上。
在该工序处理画面1100上显示有上述的业务No.1005、作业类别1101、工序类别1102、请求者名称901、请求者代码903。进而，在内容详细1103上显示请求时所输入的、对应于请求部署940的“移动电话事业部”和对应于请求内容明细941的“请求120g以下的小型移动电话的许可开发”。
另外，在上述工序处理画面1100上除上述显示外，还追加有担当者可输入的输入项目1103和辅助输入项目1104。在该输入项目1103上设置有对工序“接受”表示OK的“对应”1105、表示NG的“对应拒绝”1106、表示对应保留的“对应保留”1107以及可自由输入的“其他传达事项”1108。进而，在上述辅助输入项目1104上设置有可根据各对应来选择/输入的项目。
若显示上述工序处理画面1100，则担当者“后藤”进行与处理相应的必要的输入(图8S803)。这里，设例如选择了作为表示工序“接受”完成的输入的“对应”。当进行上述输入并按下输入按钮1110时，该所输入的信息被发送到上述处理接受单元110中(图8S804)。
若上述处理接受单元110接收上述工序完成的输入信息，则将对应上述工作流信息A的“新产品开发”的“状态”从“等待接受”变更为“完成”(未图示)(图8S806→S807)。
当由上述处理接受单元110进行的工作流信息变更完成后，接着判断单元111判断是否由“后藤”进行的、对应于顺序“1”的其他作业“样品”、“技术资料”、“价格裁决”的与顺序“1”相对应的工序已全部进行(图8S808)。这里所说的相对应的工序是具有相同的顺序404的工序。就是说，对即使并列进行处理也没有问题的处理附给相同的顺序。换句话说，也可作为优先顺序。
这里，具有对应于图5B的顺序“1”的工序的作业还有“样品”、“技术资料”、“价格裁决”，若看到工作流信息B，其他作业的状态就成为“完成”。因此，关于其他的作业，对应于顺序“1”的工序全部完成。由此，上述判断单元111的判定就判断为“全部完成”(图8S808是→S809)。
当由上述判断单元111判断为“全部完成”时，处理许可单元112对有关“A00101”的所有作业许可下一担当者的处理。具体地说，分别根据工作流主信息500的顺序“2”(502)，将工作流信息B的“新产品开发”的担当者变更为“后藤”，根据处理内容“回答”将状态变更为“等待回答”。这时，由于在对应于工作流主信息500的顺序“2”(502)的其他作业“样品”、“技术资料”、“价格裁决”中不存在担当者，所以各自的担当者的项目是“-”，状态为“保留”。结果，工作流信息B被更新为图6所示的工作流信息C(图8S809)。
工作流信息B被上述处理许可单元112更新后，上述处理接受单元110将(接受)处理完成的消息发送给担当者终端113，并显示于担当者终端113(图8S809Yes→S810)上。另外，即使在工作流信息B未被更新的情况下，上述处理接受单元110将(接受)处理完成的消息发送给担当者终端113，并显示于担当者终端113上(图8S808否→S810)。
接着在“后藤”利用上述担当者终端同样进行工序“回答”的处理时，上述判断单元111同样判断关于其他作业中对应于顺序“2”的处理是否全部完成。这里，在对应图5B的顺序“2”的作业中所登录的担当者只是“后藤”，工作流信息C(但是，“等待回答”已变更为“完成”)中的其他作业的状态为“保留”。这里若“保留”被视为和“完成”相同，则关于其他作业的对应于顺序“2”的工序全部完成。由此，上述判断单元111判断为对应于顺序“2”的处理全部完成，并且工作流信息C如图6所示的工作流信息D那样进行更新。
接着，当作业“新产品开发”的工序“确认”的担当者“小泉”同样进行了工序的处理时，上述判断单元111同样判断为关于其他作业中对应于顺序“3”的处理全部完成。然后，上述工作流信息D如图6所示的工作流信息E那样被更新。这里，对应于“样品”的担当者被更新为“铃木”，状态被更新为“等待回答”，对应于“技术资料”的担当者被更新为“山下”，状态被更新为“等待回答”。关于作业“价格裁决”，由于没有对应于顺序“4”的工序，所以状态保持原样。
此外，“新产品开发”的状态也可以被更新为“完成”，但这里被更新为“作业结束”。再有，作业结束同样被判断单元111判断为“完成”。
如上所述，在该例中，在最初结束全部作业的接受后，首先进行“新产品开发”的回答处理、确认处理，仅当这些处理结束后才可以进行对于“样品”或“技术资料”的“回答”处理。由此，当进行了对于“样品”或“技术资料”的“回答”处理后，“新产品开发”请求被否认，作为结果就可以防止以下状态，即关于其新产品的所有其他作业、例如“样品”和“技术资料”的“回答”处理变成浪费。
相反，各作业在结束接受处理后就等待“新产品开发”请求的回答处理、确认处理，所以在“新产品开发”请求被确认之后，就可以迅速地开始后续的处理。
另外，当单独进行了例如关于已有产品的“样品”请求时，各处理一结束，就能够进入后面处理。
上述“后藤”以及“小泉”的情况下的判断单元111的处理是相同的，例如，当“铃木”接着“小泉”进行了回答处理时，工作流信息E如图6所示的工作流信息F那样，对应于“样品”的“状态”被更新为“完成”。这种状态下上述判断单元111针对不是“样品”的其他作业判断和顺序“4”对应的工序是否全部完成。这里，如上述工作流信息F所示那样，对应于“技术资料”的“状态”成为“等待回答”。就是说，“山下”未进行所担当的工序(回答)的处理，上述判断单元111判断为其他作业(这里为技术资料)中和顺序“4”对应的工序未完成。
从而，上述处理许可单元112不对工作流信息F进行作为下一担当者的处理的许可的、“用于许可下一担当者的更新”(图8S809)。因此，对应于下一处理、即顺序“5”的“进货”的“小林”、“中村”不能共同用担当者终端113处理自己的工序。
在这种状态下，当例如担当“技术资料”的“4.回答”的“山下”未进行该工序的处理时，或者选择了“对应拒绝”等不可继续业务的意旨时，该业务(A00101)不再向前进行。就是说，不进行通过“山下”的处理而成为不必要的、以后的技术资料的各工序“5.进货”“6.出库”、样品的各工序“5.进货”“7.出库”、价格裁决的“6.回答”之类的工序的处理而结束。另外，在着眼于以往可并行地独立进行处理的2个作业，即图5B的样品和技术资料时，在本发明中按各工序检查相互的处理。由此，当技术资料的接受担当“渡边”没有被许可该工序时，样品也不会进入到“回答”以后的处理，所以可以防止样品的工序进入到进货后，技术资料的接受被拒绝，对于样品的各工序的处理成为浪费。
另外，将对应于技术资料的“中村”的“出库”的处理作为工序处理的其他例子来进行说明。在该技术资料的作业流程中，由“渡边”通过“接受”来接受作业，由“山下”通过“回答”来判断技术资料可否公开。这里若成为“对应”，中村就进行技术资料的“进货”“出库”(实际上是“邮购”和“发送”)。该“出库”的处理通过例如图12所示的工序处理画面1200来处理。在工序处理画面1200中具体显示有作业类别1201技术资料、和工序类别1202出库。另外，内容明细1203中显示有技术资料名称920“移动电话说明书”、技术资料No.921“MBPEXP228”、英语文献的数量922“1”、日语文献的数量923“1”。其他项目和上述图11相同。
在这样的状态下，中村发送技术资料时，例如可以发送电子数据的技术资料。这时，例如在技术资料发送日1204输入例如发送日“2004/9/10”，在资料附件1205上例如附加两个电子数据“MBPEXP228ENG.doc”及“MBPEXP228JPN.doc”作为技术资料，这样才可选择“对应”。就是说，如果不附加任何电子数据就不能选择“对应”。
这样，在系统上检查有没有在进行作业中成为必须需要的文件等，如果没有问题(如果被附加)才可以将作业推进到下一个工序。由此，不仅是各作业(这是，样品、技术资料、价格裁决、新产品开发)间的合作，还可控制1个作业(这里例如是技术资料)内的进度。上述成为必须需要的文件根据工作流所管理的业务而各种各样，作为例子，可列举出报价单、请求书、结算书、诊断书等。
当包括上述“山下”“中村”在内的以下所有的担当者没有问题地处理了自己所担当的工序时，经图6的工作流信息G如工作流信息H那样被更新。
如上所述，决定按照每个构成业务的作业来处理各工序的担当者和处理的顺序，在各工序被处理时，判断关于其他作业是否进行了所对应的工序，如果尚未进行就停止业务的进度。由此，当一个担当者进行了不得不中断业务的执行的处理(判断)时，就可未然地防止先行进行了结果并不需要的其他处理之类的问题。
由于本发明的工作流系统可以防止先行进行结果并不需要的其他处理之类的问题，所以作为管理由多个担当者顺次处理的多个作业组成的业务的处理状况的工作流系统等是有用的。
权利要求
1.一种工作流系统，管理由多个担当者顺次处理的多个工序所组成的作业的进度状况，其特征在于，具备定义信息存储单元，存储工作流定义信息，该工作流定义信息预先将作业类别和多个担当者处理构成该作业的各工序的顺序对应起来；请求接受单元，将包括相互关联的工序的多个作业作为1个业务来接受；担当者决定单元，针对上述请求接受单元所接受的业务，根据上述工作流定义信息来决定按构成该业务的每个作业来处理该作业的各工序的担当者和该处理的顺序；判断单元，当由担当者处理了构成一个作业的工序时，判断是否已对构成其他作业并和该被处理的工序相关的其他工序进行了处理；处理许可单元，当上述判断单元判断上述相关的其他工序全部被处理时，对构成该业务的作业许可进行下一工序的处理。
2.如权利要求1所述的工作流系统，其特征在于，进一步具有处理接受单元，在对于来自担当者的询问，就对应于该询问的工序已由上述处理许可单元许可该担当者进行处理时，发送用于该工序处理的画面。
3.如权利要求1所述的工作流系统，其特征在于，当由上述担当者进行的工序的处理是不可继续进行该工序所属的作业的处理时，上述处理许可单元对该作业所属的业务停止所有的进度。
4.如权利要求3所述的工作流系统，其特征在于，上述工序的处理是作业的确认和/或预定处理完成的通知。
5.一种工作流系统的管理方法，该工作流系统管理由多个担当者顺次处理的多个工序所组成的作业的进度状况，其特征在于，具备请求接受步骤，将包括相互关联的工序的多个作业作为1个业务来接受；担当者决定步骤，针对在上述请求接受步骤中所接受的业务，决定按构成该业务的每个作业来处理该作业的各工序的担当者和该处理的顺序；判断步骤，当由担当者处理了构成一个作业的工序时，判断是否已对构成其他作业并和该被处理的工序相关的其他工序进行了处理；处理许可步骤，当在上述判断步骤判断上述相关的其他工序全部被处理时，对构成该业务的作业许可进行下一工序的处理。
6.一种程序，使管理由多个担当者顺次处理的多个工序所组成的作业的进度状况的计算机执行以下步骤请求接受步骤，将包括相互关联的工序的多个作业作为1个业务来接受；担当者决定步骤，针对在上述请求接受步骤中所接受的业务，决定按构成该业务的每个作业来处理该作业的各工序的担当者和该处理的顺序；判断步骤，当由担当者处理了构成一个作业的工序时，判断是否已对构成其他作业并和该被处理的工序相关的其他工序进行了处理；处理许可步骤，当在上述判断步骤判断上述相关的其他工序全部被处理时，对构成该业务的作业许可进行下一工序的处理。
7.一种记录了程序的计算机可读取的记录介质，该程序使管理由多个担当者顺次处理的多个工序所组成的作业的进度状况的计算机执行以下步骤请求接受步骤，将包括相互关联的工序的多个作业作为1个业务来接受；担当者决定步骤，针对在上述请求接受步骤中所接受的业务，决定按构成该业务的每个作业来处理该作业的各工序的担当者和该处理的顺序；判断步骤，当由担当者处理了构成一个作业的工序时，判断是否已对构成其他作业并和该被处理的工序相关的其他工序进行了处理；处理许可步骤，当在上述判断步骤判断上述相关的其他工序全部被处理时，对构成该业务的作业许可进行下一工序的处理。
全文摘要
本发明提供一种即使是由多个作业组成的业务也可毫无浪费地管理进度状况的工作流系统及其管理方法。其中包括定义信息存储单元，存储预先将作业类别和多个担当者处理各工序的顺序对应起来的工作流定义信息；请求接受单元，将包括相互关联的工序的多个作业作为1个业务来接受。所接受的业务，通过担当者决定单元根据工作流定义信息来决定担当者和处理的顺序。然后，当由担当者处理了构成一个作业的工序时，通过判断单元判断是否已对构成其他作业并和该被处理的工序相关的其他工序进行了处理；当判断为相关的其他工序全部被处理时，处理许可单元对属于该业务的作业许可进行下一工序的处理。
文档编号G06Q10/00GK1598853SQ20041007873
公开日2005年3月23日 申请日期2004年9月17日 优先权日2003年9月18日
发明者田中满, 稻垣雄一 申请人:松下电器产业株式会社