Workflow management method and workflow management apparatus

A disclosed workflow management method includes a workflow starting step of determining a workflow based on one or more tags attached to a workflow document, attaching a status tag and a participant tag to the workflow document, and starting the workflow; and a review/approval step of requesting review and/or approval of the workflow document based on the status tag and the participant tag and updating the status tag and the participant tag after the review and/or approval.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention generally relates to a workflow management method and a workflow management apparatus.

2. Description of the Related Art

Various types of workflow systems for electronically reviewing and approving documents in an organization such as a company have been proposed (see, for example, patent document 1).

In a conventional workflow system, a creator (or a drafter) of a document determines a workflow by referring to rules in one's organization and assigns participants to the workflow who review and/or approve the document in sequence.

A conventional workflow system as described above has the following problems:

(1) It is troublesome for a creator of a document to determine a workflow by referring to rules in one's organization.

(2) A conventional workflow system normally uses a dedicated architecture for handling workflow documents and tasks. Such a workflow systemRequires complicated maintenance.Requires a dedicated client application.Lacks in flexibility and scalability.Cannot cooperate with an existing document management system having no workflow function.

SUMMARY OF THE INVENTION

Embodiments of the present invention provide a workflow management method and a workflow management apparatus that solve or reduce one or more problems caused by the limitations and disadvantages of the related art.

An embodiment of the present invention provides a workflow management method including a workflow starting step of determining a workflow based on one or more tags attached to a workflow document, attaching a status tag and a participant tag to the workflow document, and starting the workflow; and a review/approval step of requesting review and/or approval of the workflow document based on the status tag and the participant tag and updating the status tag and the participant tag after the review and/or approval.

Another embodiment of the present invention provides a workflow management apparatus including a workflow starting unit configured to determine a workflow based on one or more tags attached to a workflow document, to attach a status tag and a participant tag to the workflow document, and to start the workflow; and a review/approval unit configured to request review and/or approval of the workflow document based on the status tag and the participant tag and to update the status tag and the participant tag after the review and/or approval.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1is a drawing illustrating a configuration of an exemplary workflow system according to an embodiment of the present invention.

As shown inFIG. 1, the exemplary workflow system includes a metadata management unit1that manages tags attached to workflow documents (i.e. documents to be circulated and reviewed and/or approved in workflows) as metadata and is a central unit of the exemplary workflow system; a workflow determining unit2for determining workflows according to requests from the metadata management unit1; a document registration unit3for storing information on workflow documents; an authentication unit4for authenticating users according to requests from the metadata management unit1or the document registration unit3; and user terminals5(5A,5B, . . . ) such as personal computers (PCs) operated by users of the exemplary workflow system. In the exemplary workflow system, the above components are connected to each other via a network.

The metadata management unit1includes a user request handling unit11for handling requests from users; a metadata managing unit12for managing metadata; a UI generating unit13for generating user interfaces (UI; e.g. screens) to be displayed on the user terminals5; an RSS generating unit14for generating and sending metadata of workflow documents in an RSS format in response to requests from the user terminals5(RSS stands for Resource Description Framework (RDF) Site Summary, Rich Site Summary, or Really Simple Syndication); a tag analysis unit15for analyzing tags attached to workflow documents; a workflow determination requesting unit16for requesting the workflow determining unit2to determine workflows; a workflow status management unit17for managing statuses of workflows; a metadata database (DB)18for storing tags attached to workflow documents as metadata; and a tag definition database (DB)19for storing definitions of tags. The RSS generating unit14includes a request receiving unit141for receiving RSS feed requests via the user request handling unit11; a tag search unit142for causing the metadata managing unit12to search the metadata DB18for workflow documents based on tags; a metadata generating unit143for generating metadata (RSS data or RSS feeds) of workflow documents found by the tag search unit142; and a response sending unit144for sending the generated RSS feeds to the requesting user terminals5.

The workflow determining unit2includes a workflow server21for responding to accesses via a network and a workflow database (DB)22for storing workflow definitions.

The document registration unit3includes a document registration WWW server31for responding to accesses via a network and a document registration database (DB)32for storing information on workflow documents. The document registration WWW server31may be provided for each document type.

The authentication unit4includes an authentication server41for responding to accesses via a network and an organization/authentication information database (DB)42for storing organization information (indicating divisions, departments, etc., where users belong) and authentication information of users. The organization/authentication information DB42may be divided into an organization DB and an authentication DB.

Each of the user terminals5includes an RSS reader51for receiving RSS feeds and a browser52for browsing pages indicated by links in the received RSS feeds.

FIGS. 2A through 2Eshow variations of the exemplary workflow system.FIG. 2Ashows a variation where the metadata management unit1, the workflow determining unit2, and the authentication unit4are provided separately.FIG. 2Bshows a variation where the metadata management unit1and the authentication unit4are integrated.FIG. 2Cshows a variation where the workflow determining unit2and the authentication unit4are integrated.FIG. 2Dshows a variation where the metadata management unit1, the workflow determining unit2, and the authentication unit4are integrated.FIG. 2Eshows a variation where the metadata management unit1and the workflow determining unit2are integrated.

FIG. 3shows an example of the metadata DB18. Each record in the metadata DB18includes an ID for identifying the record, a document ID for identifying the corresponding workflow document, and one or more tags attached to the workflow document. A tag is a part of metadata. Metadata include information on a workflow document such as a document URL and tags.

Examples of tags relating to a workflow include: tags indicating types of tasks or documents, e.g. “Invention_Report”, “Technical_Report”, and “Request_For_Decision”; tags indicating organizational units, e.g. “XYZ_Laboratory” and “ABC_Department”; tags indicating informal groups, e.g. “XXX_Subcommittee” and “YYY_StudyGroup”; and tags indicating statuses, e.g. “In_Preparation”, “In_Preparation:name”, “Requesting_Review”, “Approved:name”, “Rejected”, “To:name”, “CC:name”, and “To:archive”. The exemplary workflow system may be configured such that tags indicating organizational units cannot be attached to a workflow document unless the users are authenticated.

Tags indicating the statuses of workflows and workflow documents are preferably protected from being altered without authorization or by mistake. Therefore, in this embodiment, tags indicating the statuses of workflows and workflow documents are treated as system tags that are automatically generated and altered by the exemplary workflow system and cannot be altered by the users. Examples of system tags include “Creator:name”, “Creator:name(2006-08-31/23:59:59)”, “Altered:name”, “Altered:name(2006-08-31/23:59:59)”, “To:name”, “CC:name”, “Requesting_Review”, “Reviewed:name”, “Reviewed:name(2006-08-31/23:59:59)”, “Requesting_Approval”, “Approved:name”, “Approved:name(2006-08-31/23:59:59)”, “Rejected”, “Rejected:name”, and “Rejected:name(2006-08-31/23:59:59)”.

FIG. 4shows an example of the tag definition DB19. Each record in the tag definition DB19includes an ID for identifying the record, a tag, and the definition of the tag. InFIG. 4, each definition is written in a human-readable format. In actual implementation, however, each definition is expressed, for example, by a function executable by the workflow system.

FIG. 5shows an example of the workflow DB22. Each record in the workflow DB22includes one or more tags, a corresponding workflow, and a description of the workflow. Thus, in the workflow DB22, workflows are associated with a tag or a combination of tags. This configuration makes it possible to assign multiple workflows to the same tag. Also, the descriptions of workflows make it easier to maintain the workflows in the workflow DB22.

FIG. 6shows an example of the document registration DB32. Each record in the document registration DB32includes an ID for identifying the record, a document name, and a URL indicating the storage location of the document.

FIG. 7shows an example of the organization/authentication information DB42. Each record in the organization/authentication information DB42includes an ID for identifying the record, a user name, an organizational unit where the user belongs, a position of the user, and a password for authentication.

FIG. 8is a flowchart showing an outline of a process in the exemplary workflow system.

As shown inFIG. 8, a creator (or a drafter) creates a workflow document on one of the user terminals5(step S1), and attaches a tag or tags for determining a workflow to the created workflow document to register the workflow document in the workflow system (step S2).

The workflow system determines a workflow based on the tags attached by the creator (step S3) and attaches a participant tag indicating the first workflow participant and a status tag indicating a workflow status to the workflow document after confirmation by the creator (step S4).

Then, the workflow system delivers the metadata (including a title, a description, a URL, etc.) of the workflow document as an RSS feed to the first workflow participant (step S5).

When receiving the RSS feed, the first workflow participant reviews and/or approves the workflow document (step S6). Then, the workflow system updates the status tag based on the result of the review and/or approval, and updates the participant tag to indicate the next workflow participant if there is one (step S7). If there is another workflow participant, the workflow system repeats steps S5through S7.

If no workflow participant is left or the workflow document is rejected by a workflow participant, the workflow system terminates the workflow (step S8).

FIG. 9is a flowchart showing a process via a network.

As shown inFIG. 9, the creator attaches one or more tags to a workflow document and requests the metadata management unit1to register the workflow document (step S11). The metadata management unit1causes the authentication unit4to authenticate the creator (step S12) and causes the workflow determining unit2to determine a workflow for the workflow document (step S13). Then, the creator uploads the workflow document to the document registration unit3(step S14).

Meanwhile, when receiving an RSS feed from the metadata management unit1, each of users A, B, and C (workflow participants) reviews and/or approves the workflow document registered in the document registration unit3, and returns the result to the metadata management unit1(steps S15and S16). When each of the users A, B, and C accesses the document registration unit3, the authentication unit4authenticates each of the users A, B, and C (step S17).

FIG. 10is a drawing illustrating a process by a user.FIG. 10illustrates, in more detail, interactions of the user A, B, or C with the metadata management unit1and the document registration unit3shown inFIG. 9. InFIG. 9, the interactions are illustrated in a simplified manner as also shown in the right side ofFIG. 10.

As shown inFIG. 10, a user XX receives an RSS feed from the metadata management unit1with the RSS reader51of the user terminal5(step S21), browses a workflow document registered in the document registration unit3by following a document link in the RSS feed with the browser52(step S22), and returns a review result to the metadata management unit1by using the browser52(step S23).

FIGS. 11 and 12are sequence charts showing exemplary steps of registering a document through to starting a workflow.

As shown inFIG. 11, a creator sends a request for registration of a workflow document to the user request handling unit11of the metadata management unit1from the user terminal5(step S101). The user request handling unit11requests the UI generating unit13to generate a registration UI (step S102), receives the created registration UI (step S103), and sends the registration UI to the user terminal5(step S104).FIG. 13shows an example of a registration UI. The registration UI includes a document name entry field501for entering the document name of a workflow document to be registered, a document URL entry field502for entering a URL indicating the registration destination of the workflow document (e.g. a URL indicating a location on the document registration WWW server31), a tag entry field503for entering tags used to determine a workflow for the workflow document (tags may be entered directly in the field or may be selected from a tag selection field504), the tag selection field504providing a list of tags to be entered in the tag entry field503, and a “Display WF” button505for searching for and displaying a workflow based on the conditions specified in the above fields.

Referring back toFIG. 11, the creator enters a document name, a URL, and tags on the registration UI using the user terminal5and clicks on the “Display WF” button505(requests to register the workflow document and to display a workflow) (step S105). Then, the user request handling unit11of the metadata management unit1sends a request for registration of the workflow document together with the document name and the URL to the document registration WWW server31of the document registration unit3(step S106).

The document registration server31requests the authentication server41of the authentication unit4to authenticate the creator. When requested, the authentication server41requests the UI generating unit13to generate an authentication UI (step S108). The UI generating unit13generates an authentication UI and sends it to the user request handling unit11(step S109). Then, the user request handling unit11sends the authentication UI to the user terminal5(step S110).

When the creator enters an ID and a password on the authentication UI using the user terminal5(step S111), the user request handling unit11of the metadata management unit1sends the entered authentication information to the authentication server41of the authentication unit4(step S112). The authentication server41checks the authentication information against information stored in the organization/authentication information DB42(steps S113and S114), and if the creator is a legitimate user, sends the authentication result to the document registration WWW server31of the document registration unit3(step S115). The document registration WWW server31requests the user terminal5to upload the workflow document via the user request handling unit11of the metadata management unit1(steps S116and S117).

In response to the request, the user terminal5sends the workflow document to the document registration WWW server31of the document registration unit3(step S118). The document registration WWW server31registers the workflow document in the document registration DB32(step S119). Then, the document registration WWW server31sends a registration report and an ID of the registered workflow document (document ID) to the user request handling unit11of the metadata management unit1(step S120).

Referring toFIG. 12, the user request handling unit11of the metadata management unit1sends the document ID and the tags to the metadata managing unit12(step S121). The metadata managing unit12registers the document ID and the tags in the metadata DB18(step S122).

Next, the user request handling unit11sends a request to generate a workflow together with the tags to the workflow status management unit17(step S123). The workflow status management unit17sends the request and the tags to the workflow determination requesting unit16(step S124).

The workflow determination requesting unit16sends a request to determine a workflow together with the tags to the workflow server21of the workflow determining unit2(step S125). The workflow server21searches the workflow DB22based on the tags and thereby determines a workflow (steps S126and S127).

Then, the workflow server21requests the authentication server41of the authentication unit4to obtain information on the workflow participants based on a tag indicating an organizational unit (step S128). The authentication server41searches the organization/authentication information DB42(steps S129and S130) and returns the search result to the workflow server21of the workflow determining unit2(step S131). For example, when a tag indicates “XYZ_Laboratory” and the workflow includes a participant “leader”, the authentication server41searches for a user whose organizational unit is “XYZ_Laboratory” and position is “leader”, and obtains the name of the user “Sato”.

The workflow server21sends workflow information including the search result to the workflow status management unit17(step S132). The workflow status management unit17sends the workflow information to the user request handling unit11(step S133).

When receiving the workflow information, the user request handling unit11requests the UI generating unit13to generate a confirmation UI (step S134). The UI generating unit13generates the confirmation UI (step S135) and sends it to the user terminal5via the user request handling unit11(step S136).FIG. 14shows an example of a confirmation UI for confirming a workflow. The confirmation UI includes a document name511, a document URL512, tags513, workflow participants514, a “Start WF” button515for starting the workflow, and a “Previous” button516for returning to the registration UI.

Referring back toFIG. 12, when the creator clicks on the “Start WF” button515to start the workflow using the user terminal5(step S137), the user request handling unit11requests the tag analysis unit15to send tags to be attached to the workflow document (step S138). The tag analysis unit15retrieves necessary tags from the tag definition DB19(steps S139and S140) and sends the retrieved tags to the user request handling unit11(step S141). For example, the tag analysis unit15retrieves a workflow participants tag “WFZ:name:name: . . . ”, indicating workflow participants, a status tag “Review_Requested” indicating that review of the workflow document is being requested, and a participant tag “To:name” indicating the next workflow participant.

The user request handling unit11sends the document ID and the tags to the metadata managing unit12(step S142). The metadata managing unit12registers the document ID and the tags in the metadata DB18(step S143). Take, for example, a workflow shown inFIG. 14. When the “Start WF” button515is clicked on to start the workflow, the following tags are attached to the workflow document: “Invention_Report XYZ_Laboratory WFZ:Suzuki:Sato:Tanaka Creator:Yamada Requesting_Review To:Suzuki”.

Referring back toFIG. 12, when receiving an RSS feed request from the user terminal5, the user request handling unit11of the metadata management unit1requests the RSS generating unit14to generate an RSS feed (step S144). The RSS generating unit14generates an RSS feed of the corresponding workflow document(s) and delivers it to the user terminal5(step S145).

FIG. 15is a drawing used to describe how RSS feeds are filtered in an RSS delivery process. Assuming that there are three workflows of documents having tags “To:userA”, “To:userB”, and “To:userC”, respectively, RSS feeds are filtered and only an RSS feed having a tag “To:userA” is delivered to the user A. RSS feeds may also be filtered by tags indicating document types such as “Invention_Report” and “Technical_Report”. Thus, the exemplary workflow system of this embodiment can handle various types of documents and tasks with the same mechanism and enables organic integration of different systems which is difficult with a conventional workflow system.

FIGS. 16A through 16Hshow examples of RSS feed requests sent from the RSS reader51of the user terminal5to the metadata management unit1.FIG. 16Ashows a first format of an RSS feed request. InFIG. 16A, “http://server/” indicates the address of a server (i.e. the metadata management unit1) sending RSS feeds, and “tag/” following “http://server/” and “/rss” at the end of the request indicate the start and end of tags used to select desired RSS feeds. Also inFIG. 16A, “[tags]” indicates a tag and “[value]” indicates a value of the tag. Specifying a tag such as “To”, which has a special meaning in the workflow system, and its value separately in an RSS feed request makes it easier for the workflow system to analyze the tag.FIG. 16Bshows an example of the first format shown inFIG. 16A. This example requests RSS feeds of workflow documents having a tag “To:userA”. When the request receiving unit141of the RSS generating unit14receives the RSS feed request shown inFIG. 16B, the tag search unit142causes the metadata managing unit12to search the metadata DB18based on the tag “To” and the value “userA” and thereby identifies the corresponding workflow document(s). Then, the metadata generating unit143generates an RSS feed of the identified workflow document(s), and the response sending unit144sends the generated RSS feed to the user terminal5.

FIG. 16Cshows a second format of an RSS feed request. InFIG. 16C, “http://server/” indicates the address of a server (i.e. the metadata management unit1) sending RSS feeds, and “tag/” following “http://server/” and “/rss” at the end of the request indicate the start and end of tags used to select desired RSS feeds. In this case, “[tags]” indicates a tag or tags and no value field “[value]” is provided.FIG. 16Dshows a first variation of the second format where one tag “tag1” is specified as “[tags]”, andFIG. 16Eis an example of the first variation. This example requests RSS feeds of workflow documents having a tag “XYZ_Laboratory”.

FIG. 16Fshows a second variation of the second format where two tags “tag1” and “tag2” are specified as “[tags]”. In the second variation, “tag1” and “tag2” are separated by “%20” that is the URL encoded representation of a blank character.FIG. 16Gis an example of the second variation that requests RSS feeds of documents having a tag “XYZ_Laboratory” and a tag “Invention_Report”.

FIG. 16Hshows another example of the second variation where the tag “To” and its value “userA” are separated by a blank character “%20”. This example has the same effect as that of the RSS feed request shown inFIG. 16B. When a tag, such as “To”, having a special meaning in the workflow system is specified as “tag1”, “tag2” is not treated as a tag but as the value of “tag1”.

FIGS. 17A and 17Bare drawings illustrating source code and a display on the user terminal5of an RSS feed of workflow documents having a tag “To:XYZ”. In this example, clicking on “For Review” shown inFIG. 17Bdisplays a list of workflow documents having tags “To:XYZ Requesting_Review”, and clicking on “For Approval” displays a list of workflow documents having tags “To:XYZ Requesting_Approval”.

FIGS. 18A and 18Bare drawings illustrating source code and a display on the user terminal5of an RSS feed of workflow documents having tags “To:XYZ Requesting_Review”. In this case, as shown inFIG. 18B, a list of workflow documents to be reviewed by user XYZ is displayed.

FIG. 19is a sequence chart showing an exemplary review process.

As shown inFIG. 19, when an RSS feed is sent from the RSS generating unit14of the metadata management unit1to the user terminal5of a reviewer (step S151), the reviewer sends a request for a workflow document by clicking on a document link in the RSS feed from the user terminal5to the document registration WWW server31of the document registration unit3(step S152).

The document registration WWW server31requests the workflow status management unit17to obtain information on the workflow of the requested workflow document (step S153). Then, the workflow status management unit17requests the tag analysis unit15to analyze the tags attached the workflow document (step S154).

The tag analysis unit15refers to the tag definition DB19(steps S155and S156) and returns the analysis result (including workflow status, workflow participants, and the next step to be taken) to the workflow status management unit17(step S157). The workflow status management unit17returns the workflow status to the document registration WWW server31of the document registration unit3(step S158).

Then, the document registration server31requests the authentication server41of the authentication unit4to authenticate the reviewer (step S159). The authentication server41sends an authentication request to the user terminal5(step S160). In response to the authentication request, the reviewer sends authentication information including an ID and a password to the authentication server41of the authentication unit4(step S161).

The authentication server41checks the authentication information against information stored in the organization/authentication information DB42(steps S162and S163) and returns the authentication result to the document registration WWW server31of the document registration unit3(step S164). The document registration WWW server31sends the authentication result to the user request handling unit11of the metadata management unit1(step S165).

The document registration WWW server31retrieves the requested workflow document from the document registration DB32(steps S166and S167) and sends the retrieved workflow document to the user terminal5(step S168).

Meanwhile, the user request handling unit11of the metadata management unit1requests the UI generating unit13to generate a review UI (step S169). The UI generating unit13generates the review UI (step S170) and sends it to the user terminal5via the user request handling unit11(step S171).FIG. 20shows an example of a review UI. The review UI includes a document name521, a document URL522, an “Open” button523, workflow participants524, an “Accept” button525, and a “Reject” button526.

Referring back toFIG. 19, when the reviewer sends a review result by clicking on either the “Accept” button525or the “Reject” button526(step S172), the user request handling unit11of the metadata management unit1receives the review result and reports the review result to the workflow status management unit17(step S173). The workflow status management unit17requests the tag analysis unit15to generate a tag corresponding to the review result (step S174).

When receiving the request, the tag analysis unit15refers to the tag definition DB19(steps S175) and requests the metadata managing unit12to update the metadata of the reviewed workflow document (step S176). Then, the metadata managing unit12updates the metadata in the metadata DB18(step S177). Take, for example, a case where the tags of the workflow document shown inFIG. 20are “Invention_Report XYZ_Laboratory WFZ:Suzuki:Sato:Tanaka Creator:Yamada Requesting_Review To:Suzuki” before the review. If the reviewer accepts the workflow document, the tags are updated to “Invention_Report XYZ_Laboratory WFZ:Suzuki:Sato:Tanaka Creator:Yamada Reviewed:Suzuki To:Sato”. If the reviewer rejects the workflow document, the tags are updated to “Invention_Report XYZ_Laboratory WFZ:Suzuki:Sato:Tanaka Creator:Yamada Rejected: Suzuki To:Yamada”.

Referring back toFIG. 19, the workflow status management unit17of the metadata management unit1requests the RSS generating unit14to generate an RSS feed (step S178) and the RSS generating unit14generates and delivers the RSS feed (step S179).

FIG. 21Ashows an exemplary configuration of a tag management unit6for automatically presenting tags.FIG. 21Bshows an example of a tag management database62. As shown inFIG. 21A, the tag management unit6includes a tag management server61for responding to accesses via a network and a tag management database (DB)62for storing tags assigned to users and organizational units. The tag management unit6is connected to the network shown inFIG. 1and functions as a part of the exemplary workflow system.

Each record in the tag management DB62includes an ID for identifying the record, a user or an organizational unit, and tags assigned to the user or the organizational unit.

FIG. 22is a sequence chart showing an exemplary process of registering a workflow document in the exemplary workflow system including the tag management unit6. Steps following the exemplary process shown inFIG. 22are substantially the same as those shown inFIG. 12.

As shown inFIG. 22, when the creator sends a request to register a workflow document to the user request handling unit11of the metadata management unit1from the user terminal5(step S201), the user request handling unit11requests the authentication server41of the authentication unit4to authenticate the creator (step S202). The authentication server41requests the UI generating unit13of the metadata management unit1to generate an authentication UI (step S203). The UI generating unit13generates an authentication UI and sends it to the user request handling unit11(step S204). Then, the user request handling unit11sends the authentication UI to the user terminal5(step S205).

When the creator enters an ID and a password on the authentication UI using the user terminal5(step S206), the user request handling unit11of the metadata management unit1sends the entered authentication information to the authentication server41of the authentication unit4(step S207). The authentication server41checks the authentication information against information stored in the organization/authentication DB42(steps208and209), and if the creator is a legitimate user, sends the authentication information to the user request handling unit11of the metadata management unit1(steps S210).

The user request handling unit11of the metadata management unit1sends the authentication information to the tag management server61of the tag management unit6(step S211). The tag management server61retrieves a list of tags assigned to the corresponding user or organizational unit from the tag management DB62(steps S212and S213) and sends the list to the user request handling unit11of the metadata management unit1(step S214).

When receiving the list of tags, the user request handling unit11requests the UI generating unit13to generate a registration UI (step S215). The UI generating unit13generates a registration UI and sends it to the user request handling unit11(step S216). Then, the user request handling unit11sends the registration UI to the user terminal5(step S217). The registration UI generated in step S216is substantially the same as that shown inFIG. 13except that the tags obtained from the tag management unit6are automatically entered in the tag entry field503.

Referring back toFIG. 22, the creator enters a document name and a URL of the workflow document on the registration UI using the user terminal5(in this case, tags are already entered) and clicks on the “Display WF” button505(requests to register the workflow document and to display a workflow) (step S218). Then, the user request handling unit11of the metadata management unit1sends a request for registration of the workflow document together with the document name and the URL to the document registration WWW server31of the document registration unit3(step S219). The document registration WWW server31requests the user terminal5to upload the workflow document via the user request handling unit11of the metadata management unit1(steps S220and S221).

In response to the request, the user terminal5sends the workflow document to the document registration WWW server31of the document registration unit3(step S222). The document registration WWW server31registers the workflow document in the document registration DB32(step S223). Then, the document registration WWW server31sends a registration report and an ID of the registered workflow document (document ID) to the user request handling unit11of the metadata management unit1(step S224).

FIG. 23shows another example of a registration UI. With this registration UI, a creator can specify tags by selecting document type buttons and organizational unit buttons. The registration UI shown inFIG. 23includes a document name entry field531for entering the document name of a workflow document, a document URL entry field532for entering a URL indicating the registration destination of the workflow document (e.g. a URL indicating a location on the document registration WWW server31), a document type selection field533including categorized buttons indicating document types (buttons are represented by rectangles containing document types such as “Budget”, “Purchase”, “Technical”, and “Sales”), an organizational unit selection field534including buttons indicating organizational units (buttons are represented by rectangles containing organizational units such as “XYZ Laboratory” and “ABC Branch”), and a “Display WF” button535for searching for and displaying a workflow based on the conditions specified in the above fields.

FIG. 24shows exemplary code describing relationships between tags and buttons representing the document types and organizational units on the registration UI shown inFIG. 23. The exemplary code shown inFIG. 24includes for each organizational unit a description D1enclosed between “<dept . . . >” and “</dept>”. The description D1includes a description D2enclosed between “<doc_type>” and “</doc_type>”. The description D2includes for each category a description D3enclosed between “<item . . . >” and “</item>”. Further, the description D3includes multiple descriptions D4enclosed between “<button” and “>”. Each of the descriptions D4defines a button and a tag assigned to the button.

In the first line of the description D1provided for each organizational unit, a label such as “XYZ Laboratory” is specified as the value of an attribute “name”. In the first line of the description D3provided for each category, a label such as “Accounting” is specified as the value of an attribute “name”. In the description D4provided for each button, a label such as “Budget” is specified as the value of an attribute “name”, and a tag such as “Budget_Document” is specified as the value of an attribute “tag”.

The code described above is stored in the metadata management unit1(alternatively, the code may be stored in another server). The UI generating unit13obtains a list of organizational units from the values of the attributes “name” of the descriptions D1, and generates, based on the obtained list, HTML data representing the organizational unit selection field534ofFIG. 23including organizational unit buttons. The UI generating unit13also obtains a list of categories from the values of the attributes “name” of the descriptions D3, obtains a list of document types from the values of the attributes “name” of the descriptions D4, and generates, based on the obtained lists, HTML data representing the document type selection field533ofFIG. 23including document type buttons. When there are duplicates in the lists of categories and document types obtained from the descriptions D1of multiple organizational units, the UI generating unit13sorts and merges the items in each of the lists before generating the HTML data.

When a user clicks on the buttons in the document type selection field533and the organizational unit selection field534, corresponding tags are selected according to the relationship shown inFIG. 24. For example, when a user clicks on “Budget” in the document type selection field533and on “XYZ Laboratory” in the organizational unit selection field534, the first one of the descriptions D1shown inFIG. 24is identified based on the organizational unit “XYZ Laboratory” and the tag “Budget_Document” is selected based on the document type “Budget”.

As described above, embodiments of the present invention provide the following advantages:

(1) A creator of a workflow document can determine a workflow just by attaching intuitive tags indicating the content of the workflow document. Therefore, a workflow system according to an embodiment of the present invention makes it easier to determine a workflow compared with a conventional workflow system where a creator of a workflow document has to determine a workflow by referring to rules in one's organization.

(2) A workflow system of an embodiment of the present invention does not employ a dedicated architecture for handling workflow documents and tasks. Therefore, the systemDoes not require complicated maintenance.Allows using a normal Web browser as a client.Has high flexibility and scalability.Can cooperate even with a document management system having no workflow function.

(3) An RSS reader has a function to periodically obtain RSS feeds. Therefore, using an RSS feeder eliminates the need to request the users to review and/or approve workflow documents by, for example, sending emails. This improves efficiency of information delivery in a workflow system.

(4) Using an RSS reader makes it easier for a user to browse review/approval requests and thereby improves working efficiency.

An embodiment of the present invention provides a workflow management method that makes it unnecessary for a user to determine a workflow by oneself.

Another embodiment of the present invention provides a highly flexible and highly scalable workflow management apparatus that makes it unnecessary for a user to determine a workflow by oneself.

In the present application, the user request handling unit11, the metadata managing unit12, the UI generating unit13, the workflow determination requesting unit16, the workflow status management unit17, and the workflow determining unit2may correspond to a workflow starting unit. Also in the present application, the user request handling unit11, the metadata managing unit12, the UI generating unit13, the RSS generating unit14, and the workflow status management unit17may correspond to a review/approval unit.

The present application is based on Japanese Priority Application No. 2006-305429 filed on Nov. 10, 2006, and Japanese Priority Application No. 2007-271529 filed on Oct. 18, 2007, the entire contents of which are hereby incorporated herein by reference.