JP2021068384A - Workflow system and server device - Google Patents

Abstract

To set browsing authority in view of relation between parties in a case where a workflow system is used between a client, an intermediary, and a proposer.SOLUTION: A workflow system which identifies IDs respectively provided to a drafter who drafts a request, a proposer who creates a proposal based on the request, and an intermediary who intervenes between the drafter and the proposer includes: a first creation unit 402 which accepts inputs by a plurality of users including the drafter and the proposer in predetermined input order and creates a request document; a second creation unit 404 which accepts input by the proposer after the creation of the request document and creates a proposal document; a reception unit 401 which receives the approval of the proposal document from the plurality of users in order opposite to the input order; a setting unit 408 which is capable of setting, on an individual user ID basis, whether or not there is browsing authority for information included in the request document; and a providing unit 410 which is capable of providing authority for setting the browsing authority to at least one of the ID of the intermediary and the ID of the proposer.SELECTED DRAWING: Figure 14

Description

The present disclosure relates to a workflow system and a server device capable of creating a proposal among a plurality of users.

In this type of workflow system, an administrator having administrator authority sets the viewing authority for the sheet processed in the workflow for each user. For example, the administrator grants the creator or approver of the sheet processed in the workflow the viewing authority for the sheet. Patent Document 1 describes a technique that enables a drafter or an approver, in addition to an administrator, to give a viewing authority to a sheet to a user who does not have the viewing authority. According to the technique described in Patent Document 1, the drafter or the approver can have a user who does not have the viewing authority check the contents of the sheet, if necessary.

Japanese Unexamined Patent Publication No. 2011-237927

The workflow system is used in various situations, and it is not limited to the situation where the drafter asks the superior for approval of the draft content. For example, after intervening between the requester who requests some kind of proposal, the proposer who receives the request and formulates the proposal, and the requester and the proposer, the request contents of the requester are made more concrete. , It is conceivable to use a workflow system with an intermediary who requests the proposer.

In this case, the client drafts a request form for requesting a proposal. The draft request form will be made available for viewing by the intermediary. The intermediary makes corrections to the request form. The request form modified by the intermediary will be made available to the proposer.

The proposer browses the request form and creates a proposal based on the contents of the request form. The intermediary browses the proposal proposed by the proposer and approves the proposal if there is no problem with the proposal. If approved by the intermediary, the proposal will be made available to the client.

In this way, assuming that the workflow system is used between the requester, the intermediary, and the proposer, either the requester, the intermediary, or the proposer depends on the business relationship of each person. It is assumed that some of the information entered by the user does not want to be shown equally to all the persons who have the authority to be involved in the workflow. However, in the conventional workflow system, the requester, the intermediary, and the proposer are uniformly given the authority to view the request form, so that when each person views the request form, everything included in the request form is included. There was a problem that the information of was able to be browsed.

This disclosure is made to solve the above-mentioned problems, and the purpose in a certain aspect is to use the workflow system among the client, the intermediary, and the proposer. It is to provide a technology that can set viewing authority in consideration of the relationship.

According to certain aspects of this disclosure, it was granted to each of the drafter who drafts the request, the proposer who creates the proposal based on the request, and the intermediary between the drafter and the proposer. A workflow system for identifying IDs, in which input by a plurality of users including a drafter and an intermediary is accepted for the plurality of users in a predetermined input order, and thus items input by the plurality of users. The first preparation department that creates a request form including the above, the second preparation department that creates a proposal by accepting the input by the proposer after the request form is created by the first preparation department, and the approval of the proposal. The reception unit that accepts the information from multiple users in the reverse order of the input order, the setting unit that can set the presence / absence of viewing authority for the information contained in the request form for each user ID, and the setting unit that sets the viewing authority. It is provided with an granting unit that can grant the authority to perform to at least one of the ID of the intermediary and the ID of the proposer.

In some aspects, the proposal includes matters where the object is placed in the layout plan.
In one aspect, the layout is made visible in all of the user's IDs.

In a certain aspect, the information whose viewing is restricted by the viewing authority is at least one of the target amount proposed by the proposal, the information about the target requester proposed by the proposal, and the deadline for preparing the proposal. Including.

In a certain aspect, the workflow system causes the terminal device to display the status of the request form and the proposal form by ID.

In a certain aspect, the state of the request and the proposal is any one of a plurality of predetermined states.

In one aspect, the workflow system creates a request and a proposal if a termination operation is performed on the terminal device logged in by either the drafter's ID, the proposer's ID, or the intermediary's ID. End the process to be performed.

In a certain aspect, the first creation unit receives inputs by a plurality of users including the drafter and two or more intermediaries in a predetermined input order, and thereby receives a request form including matters input by the plurality of users. create.

In a certain aspect, the first creation unit receives inputs by a plurality of users including the drafter and the first intermediary in a predetermined input order for the plurality of users, so that the plurality of users input the inputs. By creating a first-class request form that includes the above-mentioned items and accepting inputs by a plurality of users including the drafter and the second intermediary in a predetermined input order for the plurality of users, the plurality of requests are received. The second type of request form including the items input by the user of the first type is created, and the second creation unit accepts the input by the first proposer after the first type of request form is created, so that the first type of request form is created. After the proposal of the second type is created and the request form of the second type is created, the proposal of the second type is created by accepting the input by the second proposer.

In a certain aspect, the second preparation department prepares the first proposal by accepting the input by the first proposer after the request is prepared by the first preparation department, and the first proposal is prepared. Later, the second proposal is created by accepting the input by the second proposer.

According to another aspect of this disclosure, it is granted to each of the drafter who drafts the request, the proposer who creates the proposal based on the request, and the intermediary between the drafter and the proposer. A server device included in a workflow system that identifies an ID, and the server device receives inputs by a plurality of users including a drafter and an intermediary in a predetermined input order for the plurality of users. Creates a proposal by receiving input from the proposer after the request is created by the first creation unit and the first creation unit that create a request form that includes the items entered by the plurality of users. A second creation unit, a reception unit that accepts approval of proposals from multiple users in the reverse order of input, and a setting unit that can set whether or not to have viewing authority for the information contained in the request form for each user ID. , An granting unit that can grant the authority to set the viewing authority using the setting unit to at least one of the ID of the intermediary and the ID of the proposer is provided.

According to the present disclosure, when the workflow system is used between the client, the intermediary, and the proposer, it is possible to set the viewing authority in consideration of the relationship of each person.

The above and other objectives, features, aspects and advantages of the invention will become apparent from the following detailed description of the invention as understood in connection with the accompanying drawings.

It is a figure for demonstrating the configuration example of the workflow system of this embodiment. It is a figure for demonstrating the image diagram of the transmission and reception of information between each user. It is a figure for demonstrating an example of the 1st request form. It is a figure for demonstrating an example of the 2nd request form. It is a figure for demonstrating an example of a proposal. It is a figure for demonstrating the flow of the main processing and the like. It is a figure for demonstrating an example of a list screen. It is a figure for demonstrating an example of a confirmation screen. It is a figure for demonstrating an example of the input screen for creating a request form. It is a figure for demonstrating an example of the input screen for creating a proposal. It is a figure for demonstrating the transmission and reception of the main information in a workflow system. It is a figure for demonstrating the state change condition and the like. It is a figure for demonstrating the hardware configuration of a server apparatus and the like. It is a figure for demonstrating the functional configuration example of a server apparatus and the like. It is a figure for demonstrating the image of a viewing authority. It is a figure for demonstrating whether or not there is an access restriction of each information of a request form. It is a figure which shows an example of the flowchart of the workflow system. It is a figure which shows an example of the flowchart of the workflow system. It is a figure for demonstrating the workflow system of 2nd Embodiment. It is a figure for demonstrating an example of the 3rd request form. It is a figure for demonstrating whether or not there is an access restriction of each information of the request form of 2nd Embodiment. It is a figure for demonstrating the workflow system of the modification of the 2nd Embodiment. It is a figure for demonstrating the workflow system of 3rd Embodiment. It is a figure for demonstrating the workflow system of 4th Embodiment.

The workflow system according to the embodiment based on the present invention will be described below with reference to the drawings. In addition, the same parts and equivalent parts may be given the same reference number, and duplicate explanations may not be repeated. In addition, it is planned from the beginning to use at least a part of the configurations in each embodiment in appropriate combinations.

[First Embodiment]
[Overall configuration of workflow system 10]
FIG. 1 shows the configuration of the workflow system 10 of the present embodiment. The workflow system 10 includes a first terminal device 100, a second terminal device 200, a third terminal device 300, a server device 400, and a network 50. Information can be transmitted and received between the first terminal device 100 and the server device 400 via the network 50. Information can be transmitted and received between the second terminal device 200 and the server device 400 via the network 50. Information can be transmitted and received between the third terminal device 300 and the server device 400 via the network 50. The first terminal device 100, the second terminal device 200, and the third terminal device 300 are any one of a tablet, a smartphone, a personal computer, a wearable terminal, and the like, respectively.

The first terminal device 100, the second terminal device 200, and the third terminal device 300 are referred to as one terminal device group (that is, one group). A plurality of terminal device groups are connected to the server device 400 via the network 50. In addition, an ID is assigned to each of the terminal device groups. In the example of FIG. 1, the ID of the terminal device group is also referred to as a “group ID”. In the example of FIG. 1, a terminal device group having a group ID = A1 and a terminal device group having a group ID = An are described. However, n is an integer of 2 or more.

[Sending and receiving information in workflow system]
FIG. 2 is a diagram for explaining an image diagram of information transmission / reception between each user. In this embodiment, for example, an example in which the workflow system 10 is used to create a proposal for designing a house will be described. A proposal is a document for making a proposal to the owner of a house. Proposals are also called "deliverables." The workflow system 10 of the present embodiment shall create a proposal regarding the installation of lighting in a house. The workflow system 10 is used by a person in charge of a house maker who undertakes the design of a house, a sales person in charge of a lighting maker, and a planner of a lighting maker. The person in charge of the house maker is also called simply "house maker", the sales person of the lighting maker is also called simply "sales person", and the planner of the lighting maker is simply called "planner". The person in charge of the house maker is also referred to as the first user. The sales person in charge of the lighting manufacturer is also called a second user. The planner of the lighting manufacturer is also called a third user. The first user, the second user, and the third user are collectively referred to as a "user".

The person in charge of the house maker uses the first terminal device 100. The sales person of the lighting maker uses the second terminal device 200. The lighting manufacturer's planner uses the third terminal device 300. The first terminal device 100, the second terminal device 200, and the third terminal device 300 are collectively referred to as a "terminal device".

The person in charge of the house maker who undertakes the design of the house receives an order for the design of the house from the owner or the like. The person in charge of the house maker creates a request form (hereinafter, also referred to as “first request form”) reflecting the request from the owner using the first terminal device 100. The request from the owner is, for example, a floor plan or a budget for lighting equipment. In the present embodiment, the person in charge of the house maker inputs the first item on the input screen described with reference to FIG. 9, and the server device 400 creates the first request form. The first item is a plurality of items constituting the first request form. The plurality of items in the first request form are, for example, items such as a budget for lighting equipment, a floor plan, and a family structure. When the first request form is completed, the second terminal device 200 can display the first request form.

The sales person in charge of the lighting manufacturer visually recognizes the first request form displayed on the second terminal device 200. The sales person in charge of the lighting manufacturer creates a request form (hereinafter, also referred to as “second request form”) in the second terminal device 200 based on the first request form. In the present embodiment, the sales person of the lighting maker inputs the second item to the input screen described with reference to FIG. 9, and the server device 400 creates the second request form. The second item is a plurality of items constituting the second request form. When the second request form is completed, the third terminal device 300 can display the second request form. The planner of the lighting manufacturer visually recognizes the second request form displayed on the third terminal device 300. The lighting manufacturer's planner prepares a proposal with the third terminal device 300 based on the second request form. When the proposal is completed, the second terminal device 200 can display the proposal.

Next, the sales person visually recognizes the proposal displayed on the second terminal device 200. The sales person visually recognizes the proposal, and if there is no defect in the proposal, approves the proposal. This approval is, for example, operating an approval button. When the proposal is approved by the second terminal device 200, the first terminal device 100 can display the proposal.

Next, the house maker visually recognizes the proposal (that is, the proposal approved by the sales person) displayed on the first terminal device 100. The house maker visually recognizes the proposal and approves the proposal if it is complete. This approval is, for example, operating an approval button. The house maker then submits a proposal (ie, a proposal approved by the house maker) to the owner.

An ID (Identification) is assigned to each of the house maker, the sales person, and the planner. For example, when a user (that is, a house maker, a sales person, and a planner) performs a predetermined operation on the terminal device, the user is newly registered in the workflow system 10. The server device 400 assigns an ID to a newly registered user. As a result, the server device 400 can manage the user's ID. The house maker, the sales person, and the planner can use the workflow system 10 by inputting their own IDs into the terminal device. More specifically, the person in charge of the house maker can access the server device 400 by inputting the ID of the person in charge of the house maker into the first terminal device 100. Further, the sales person of the lighting maker can access the server device 400 by inputting the ID of the person in charge of the lighting maker into the second terminal device 200. Further, the planner of the lighting maker can access the server device 400 by inputting the ID of the person in charge of the lighting maker into the third terminal device 300. “Accessing the server device 400” means, for example, “transmission and reception of information between the terminal device and the server device 400”. In the present embodiment, for convenience, the terminal device used by the house maker is referred to as the first terminal device 100, the terminal device used by the sales person is referred to as the second terminal device 200, and the terminal device used by the planner is referred to as the first terminal device. 3 It is called a terminal device 300. However, at least two of the house maker, the sales person, and the planner may use the same terminal device.

Further, in FIG. 2, FIGS. 19 and 22 to 24 described later, it is shown that the request form and the proposal form are transmitted between the terminal devices for convenience. However, in reality, the request form and the proposal form are transmitted to each terminal device via the server device 400.

[About request form and proposal]
Next, the first request form, the second request form, and the proposal form will be described. FIG. 3 is a diagram for explaining an example of the first request form 700 created by the first terminal device 100. As shown in FIG. 3, the items of the first request form 700 include the project name 702, the plan name 704, the budget 706, the submission deadline 708, and the floor plan file 710.

The project name 702 includes the place where the house is built and the name of the client (for example, the owner) of the construction of the house. In the example of FIG. 3, the project name 702 is "Osaka City, Yamada-sama's residence". The plan name 704 is "A plan". The budget 706 is "400,000 yen". The deadline for submission 708 is "September 20th". When the floor plan file 710 is clicked, the floor plan is displayed on the terminal device displaying the first request form. The first request form 700 is created based on the items by the server device 400 that has received the input of the items of the first request form.

FIG. 4 is a diagram for explaining an example of the second request form 800 created by the server device 400. As shown in FIG. 4, the items of the second request form 800 include the project name 802, the plan name 804, the budget 806, the submission deadline 808, the floor plan file 810, and the equipment information 812.

The project name 802 includes the place where the house is built, but does not include the name of the client who built the house. In the example of FIG. 4, the project name 802 is "Osaka City". The plan name 804 is "A plan". The budget 806 is "400,000 yen". The deadline for submission 808 is "September 13th". When the floor plan file 810 is clicked, the floor plan is displayed on the terminal device displaying the second request form. This floor plan is the same as the floor plan described with reference to FIG. Instrument information 812 includes instrument M1 and instrument M2. The second request form 800 is created based on the items by the server device 400 that has received the input of the items of the second request form.

FIG. 5 is a diagram for explaining an example of the proposal 900. As shown in FIG. 5, the proposal 900 includes a floor plan 830 and instrument information 834 associated with each point 836 of the floor plan 830. Each point 836 is information indicating a place where the lighting fixture indicated by the fixture information 834 is arranged. Instrument information 834 includes instrument names (eg, instrument A and instrument B) and instrument descriptions. In the example of FIG. 5, the description of the instrument is simplified as "...". In the example of FIG. 5, each point 836 is indicated by a black circle. By visually recognizing the proposal 900, the user or the owner can specify the place where the lighting fixture indicated by the fixture information 834 is arranged.

[About the display screen]
Next, an example of processing performed by each user will be described. FIG. 6 is a diagram for explaining an example of processing and the like performed by each user. Further, the parentheses in FIG. 6 indicate a screen displayed on the terminal device.

First, in step (A1), the house maker enters the house maker's ID on the login screen (not shown) to log in to the workflow system. Next, in step (A2), the house maker newly creates a request on the list screen. Next, in step (A3), the house maker determines the request destination. In the present embodiment, the request destination is a sales person in charge of the lighting manufacturer. Next, in step (A4), the items of the first request form (see FIG. 3) are input from the input screen. By inputting the contents of this request, the first request form described with reference to FIG. 3 is created. Next, in step (A5), the house maker requests the next requestee to create a proposal.

In step (A6), the sales representative of the lighting manufacturer enters the ID of the sales representative on the login screen (not shown) to log in to the workflow system. Next, in step (A7), the sales representative of the lighting manufacturer confirms that a new request has arrived on the list screen. Next, in step (A8), the sales representative of the lighting manufacturer determines the request destination. In this embodiment, the request destination is a planner. Next, in step (A9), the items of the second request form (see FIG. 4) are input from the input screen. By inputting the contents of this request, the second request form described with reference to FIG. 4 is created. Next, in step (A10), the sales of the lighting manufacturer requests the next requestee to create a proposal.

In step (A11), the planner inputs the planner's ID on the login screen (not shown) to log in to the workflow system. Next, in step (A12), the planner confirms that a new request has arrived on the list screen. Next, in step (A13), the planner activates the proposal creation application on the third terminal device 300. Next, in step (A14), the items of the proposal (see FIG. 5) are input from the input screen. By inputting the contents of this request, the proposal described in FIG. 5 is created. Next, in step (A15), the planner submits a proposal to the sales person who is the requester.

Next, in step (A16), the sales person confirms the proposal and submits it to the house maker on the list screen. Next, in step (A17), the house maker confirms the proposal submitted by the sales person. When the confirmation is completed, the house maker submits a proposal to the owner.

Further, as shown in B of FIG. 6, the floor plan is shared by the house maker, the sales staff, and the planner. That is, the same floor plan can be displayed on the first terminal device 100, the second terminal device 200, and the third terminal device 300. This means that house makers, salespeople, and planners can view the same floor plan.

Further, as shown in C of FIG. 6, the request contents are added and modified in the order of house maker, sales, and planner.

FIG. 7 is an example of the list screen described in step (A2), step (A7), step (A12) and the like in FIG. The list screen is a screen showing a list of proposals to be created. FIG. 7 shows a case where the number of proposals to be created is six. On the list screen, the submission deadline, the status 862, the matter name 864, the request source 866, the request destination 868, and the operation button group are displayed. A set of "submission deadline, status, case name, request source, request destination, and operation button group" is collectively referred to as "1 request information" or simply "request information".

The submission deadline indicates the submission deadline of the proposal. State 862 indicates the state (or status) regarding the preparation of the request and the proposal. The matter name indicates the name of the matter. The request source refers to the output source of the request form (in the example of FIG. 6, the first terminal device 100 of the house maker, the second terminal device 200 of the sales person or the like). The request destination refers to the output destination of the request form (in the example of FIG. 6, the second terminal device 200 of a sales person or the like or the third terminal device 300 of the planner). The operation button group includes various buttons. The operation button group includes a request content confirmation button 882, a request button 884, a create / edit button 886, a document confirmation button 888, a duplicate button 890, a submit button 892, and a completion button 894. In addition to the operation buttons, a newly created button 880 is also displayed. The new creation button 880 may be displayed by the second terminal device 200 so that an intermediary can operate the new creation button 880. When the new creation button 880 is operated, a confirmation screen is displayed in a pop-up.

FIG. 8 is a diagram showing an example of the confirmation screen 895. In addition, the request button 896 is displayed in the confirmation screen 895. In the example of FIG. 8, the input area of the matter name, the document name, the request source, and the request destination is displayed. When the request button 896 is operated after the information is input to these input areas, a new request for the proposal is created as described in step (A2).

Further, the display of the state 862 in FIG. 7 of the present embodiment has six states of "new", "waiting for creation", "submitted", "confirming", "creating", and "completed". .. “New” is a state indicating that a new request has arrived, as described in step (A7) of FIG. "Waiting for creation" indicates that the state is after the request form has been created and before the proposal has been created. "Submitted" indicates that the proposal has been prepared by the planner. "Submitted" is a state displayed on the third terminal device 300. "Confirming" indicates that the state is after the proposal has been prepared by the planner. "Confirming" is a state displayed by the first terminal device 100 and the second terminal device 200. "Confirming" is a state indicating that the person in charge of the house maker or the sales person in charge of the lighting maker is in the process of confirming the proposal. “Creating” is a state displayed on the third terminal device 300, indicating that the proposal is being created. "Completed" is a state indicating that "the proposal creation flow has been completed". "Complete" is a state displayed when the completion button 894 is operated.

As will be described later with reference to FIG. 14, the server device 400 stores the first request form, the second request form, and the proposal form. When the request content confirmation button 882 of FIG. 7 is operated, the request form can be displayed on the terminal device on which the request content confirmation button 882 is operated. For example, if the request content confirmation button 882 of the first terminal device 100 is operated after the first request form is created, the first terminal device 100 sends the first request form to the server device 400. Request. Upon receiving the first request form from the server device 400, the first terminal device 100 temporarily stores the first request form in a predetermined storage area (for example, RAM) and displays the first request form.

If the request content confirmation button 882 of the second terminal device 200 is operated after the first request form is created, the second terminal device 200 requests the server device 400 for the first request form. .. When the second terminal device 200 receives the first request form from the server device 400, the second terminal device 200 temporarily stores the first request form in a predetermined storage area (for example, RAM) and displays the first request form.

If the request content confirmation button 882 of the second terminal device 200 is operated after the second request form is created, input the selection of whether to display either the first request form or the second request form. Display a possible selection screen (not shown). The second terminal device 200 requests the server device 400 for the selected request form when either the first request form or the second request form is selected by the user. When the second terminal device 200 receives the request form from the server device 400, the second terminal device 200 temporarily stores the request form in a predetermined storage area (for example, RAM) and displays the request form.

If the request content confirmation button 882 of the third terminal device 300 is operated after the second request form is created, the third terminal device 300 requests the server device 400 for the second request form. .. When the third terminal device 300 receives the second request form from the server device 400, the third terminal device 300 temporarily stores the second request form in a predetermined storage area (for example, RAM) and displays the second request form.

When the request button 884 is operated, the planner's terminal device (that is, the third terminal device 300) is requested to create a proposal. When the create / edit button 886 is operated, the request form creation application or the proposal creation application can be started. When the create / edit button 886 of the first terminal device 100 or the second terminal device 200 is operated, the request form creation application is activated. When the request form creation application is started, the input screen of FIG. 9 described later is displayed. Further, when the create / edit button 886 of the third terminal device 300 is operated, the proposal creation application is activated. When the proposal creation application is started, the input screen of FIG. 10 described later is displayed.

When the document confirmation button 888 is operated, the proposal can be displayed on the terminal device on which the document confirmation button 888 is operated. When the duplicate button 890 is operated, the terminal device on which the duplicate button 890 is operated can duplicate the request form or the proposal. When the submit button 892 is operated, the request form can be displayed on the requesting terminal device (for example, the first terminal device 100) of the terminal device on which the submit button 892 is operated. When the completion button 894 is operated, the proposal creation flow can be terminated. The completion button 894 is operated, for example, when the house maker receives an order from the owner, but the order is canceled by the time the proposal is created.

Note that, for convenience, all types of states and all types of operation buttons are shown in FIG. 7, but in reality, depending on the terminal device, there are states that are not displayed and operation buttons that are not displayed. For example, the state "waiting for creation" is not displayed on the third terminal device 300.

FIG. 9 is a diagram showing an example of an input screen displayed on the first terminal device 100 in step (A4) of FIG. The input screen of FIG. 9 is a screen for creating the first request form. The input screen of FIG. 9 displays input areas for various input items. Items are input to the input area by the user's operation on the terminal device. For example, a budget (for example, 500,000 yen) is input to the budget input area 902. The floor plan data is input to the floor plan input area 904. The family structure data is input to the family structure input area 906.

The request destination is input to the request destination input area 910 by the operation of the user. In the example of FIG. 9, "sales" is input to the request destination input area 910. The house maker operates the request button 912 when the input to the input screen is completed. In step (A5), the first terminal device 100 requests the request destination input in the request destination input area 910. In the processing of steps (A5) and (A6), specifically, a request form based on the items input from the input screen is displayed on the terminal device of the request destination input in the request destination input area 910. .. Then, the request form (that is, the first request form) based on the items input from the input screen can be displayed by the terminal device (that is, the second terminal device 200) sold by the lighting manufacturer.

Further, the second terminal device 200 displays the first request form in step (A9), for example. The sales person confirms the first request form and displays the input screen. This input screen is also the screen shown in FIG. The sales of the lighting manufacturer corrects the items of the first request form by inputting the information from the input screen for the items to be corrected. For example, when the sales person wants to change the budget, he / she inputs the budget in the budget input area 902. When the input to the input screen is completed, the lighting maker's business operates the request button 912 after inputting "planner" in the request destination input area in step (A10). In addition, there may be items that cannot be input on the input screen displayed by the first terminal device 100. In addition, there may be items that cannot be input on the input screen displayed on each of the second terminal devices 200.

FIG. 10 is an example of an input screen displayed when the proposal creation application is started in the step (A13). This input screen is displayed on the third terminal device 300. On the input screen in the example of FIG. 10, the floor plan 830 and the appliance list information 832 are displayed. The floor plan 830 is the same as the floor plan displayed when the floor plan file 710 shown in FIG. 3 and the floor plan file 810 shown in FIG. 4 are clicked.

The instrument list information 832 is information composed of the instrument information A to the instrument information F. The appliance information of 1 is information including a product number, an amount of money, and the like. When the planner of the lighting manufacturer specifies a desired position in the floor plan 830, the point 831 is displayed at the designated position, and the fixture information A to the fixture information F can be selected. The lighting manufacturer's planner selects any of the fixture information from the fixture information A to the fixture information F, so that the selected fixture information is associated with the designated position (displayed point 831). When the planner completes the input to the input screen of FIG. 10, the submit button (not shown) is operated so that it can be displayed on the first terminal device 100 and the second terminal device 200. ..

[Sending and receiving information in workflow system]
FIG. 11 is a diagram for explaining the transmission and reception of main information in the workflow system 10. In step (1), the house maker inputs an item on the input screen (see FIG. 9) displayed by the first terminal device 100. When the request button 912 (see FIG. 9) is operated by the house maker, in step (2), the first terminal device 100 transmits the input items of the first request form to the server device 400.

Next, in step (3), the server device 400 transmits a state change signal to the first terminal device 100 and the second terminal device 200. The state change signal is a signal for changing the state 862 shown in FIG. The state before the change and the state after the change by the state change signal will be described with reference to FIG.

Further, after receiving the state change signal, the second terminal device 200 displays the first request form in response to the operation of the user (that is, the sales person). Next, in step (5), the sales person who confirmed the first request form inputs an item on the input screen (see FIG. 9) displayed on the second terminal device 200. When the request button 884 is operated by the sales person, in step (6), the second terminal device 200 transmits the input items of the second request form to the server device 400.

In step (7), the server device 400 transmits a state change signal to the second terminal device 200 and the third terminal device 300. Further, after receiving the state change signal, the third terminal device 300 displays the second request form in response to the operation of the user (that is, the planner). Next, in step (8), the planner who confirmed the second request form inputs an item on the input screen (see FIG. 10) displayed by the third terminal device 300. When the submit button 892 is operated by the planner, in step (9), the third terminal device 300 transmits the input items of the proposal to the server device 400.

Next, in step (10), the server device 400 transmits a state change signal to the second terminal device 200. Further, after receiving the status change signal, the second terminal device 200 displays the proposal in response to the operation of the user (that is, the sales person) (for example, in response to the operation of the document confirmation button 888). To do. The sales person may be able to make amendments to this proposal. Next, in step (11), the sales person confirms the proposal and approves the submission. This approval is made by operating the submit button 892 by the sales person. In step (12), the second terminal device 200 transmits an approval signal to the server device 400.

Next, in step (13), the server device 400 transmits a state change signal to the first terminal device 100. Further, after receiving the state change signal, the first terminal device 100 displays the proposal in response to the operation of the user (that is, the house maker) (for example, in response to the operation of the document confirmation button 888). .. The house maker may be able to make amendments to this proposal. Next, in step (14), the house maker confirms the proposal and approves the submission. This approval is made by operating the submit button 892 by the house maker. In step (15), the first terminal device 100 transmits an approval signal to the server device 400.

[Conditions for state change]
FIG. 12 is a diagram showing an example of a state change condition in which the state 862 changes. As shown in FIG. 12, when a new request is created (that is, when the new creation button 880 is operated), the request information is newly created and a new "" is displayed on the list screen. "Request information" is displayed. "New" is displayed as the state 862 included in the request information displayed on the first terminal device 100.

Next, when the input items of the first request form are transmitted from the first terminal device 100 to the server device 400, the state displayed by the first terminal device 100 becomes "waiting for creation" and the second terminal. The state displayed by the device 200 is "new". Next, when the input items of the second request form are transmitted from the second terminal device 200 to the server device 400, the state displayed on the first terminal device 100 is maintained as "waiting for creation", and the first The state displayed by the two terminal devices 200 is "waiting for creation", and the state displayed by the third terminal device 300 is "new".

Next, when the proposal creation application is started on the third terminal device 300, the state displayed on the first terminal device 100 is a state in which "waiting for creation" is maintained and displayed on the second terminal device 200. Is maintained as "waiting for creation", and the state displayed on the third terminal device 300 is "creating". Next, when the input items of the proposal are transmitted from the third terminal device 300 to the server device 400, the state displayed on the first terminal device 100 is maintained as "waiting for creation", and the second terminal The state displayed by the device 200 is "confirming", and the state displayed by the third terminal device 300 is "submitted".

Next, when the approval signal is transmitted from the second terminal device 200 to the server device 400, the state displayed by the first terminal device 100 becomes "confirming" and is displayed by the second terminal device 200. The state is "submitted", and the state displayed on the third terminal device 300 is maintained as "submitted". Next, when the approval signal is transmitted from the first terminal device 100 to the server device 400, the state displayed by the first terminal device 100 becomes "submitted" and is displayed by the second terminal device 200. The state of "submitted" is maintained, and the state displayed on the third terminal device 300 is maintained as "submitted".

[Hardware configuration of server devices, etc.]
FIG. 13 is a diagram for explaining a hardware configuration of the server device 400 and the like. It is a figure which showed the hardware configuration of the server apparatus 400. With reference to FIG. 2, the server device 400 includes a CPU (Central Processing Unit) 491 that executes a program, a ROM (Read Only Memory) 492 that stores data non-volatilely, and a RAM (RAM) that stores data volatilely. It includes a Random Access Memory) 493 and a communication IF (Interface) 494.

The CPU 491, the ROM 492, and the RAM 493 are connected to each other by a data bus. The processing in the server device 400 is realized by a program executed by the CPU 491. Such a program is stored in ROM 492 in advance.

Further, although a hardware configuration example of the terminal device is not particularly shown, the terminal device includes a CPU, a ROM, a RAM, an input device, and a display device.

[Example of functional configuration of server device, etc.]
FIG. 14 is a diagram for explaining a functional configuration example of the server device 400 and the like. The first terminal device 100 includes an input device 102, a control device 104, and a display device 106. The second terminal device 200 has the functions of the input device 202, the control device 204, and the display device 206. The third terminal device 300 has the functions of the input device 302, the control device 304, and the display device 306. The input device 102, the input device 202, and the input device 302 are collectively referred to as an "input device". The control device 104, the control device 204, and the control device 304 are collectively referred to as a "control device". The display device 106, the display device 206, and the display device 306 are collectively referred to as a "display device".

An operation from the user is input to the input device. The input device is composed of, for example, a mouse, a keyboard, and the like. The control device performs various controls on the terminal device. The control device is composed of a CPU, RAM and ROM. The display device displays various information and various images under the control of the control device. In addition, the control device transmits and receives various information to and from the server device via the communication IF. Further, the input device and the display device may be integrated. In this case, the input device and the display device function as a touch panel.

The server device 400 has a control device 420 and a storage device 440. The control device 420 has functions of a reception unit 401, a first creation unit 402, a second creation unit 404, a setting unit 408, and an imparting unit 410.

The first creation unit 402 receives input by a plurality of users including the drafter and an intermediary in a predetermined input order for the plurality of users, and includes items input by the plurality of users. Create 1 request form and 2 request form. In the present embodiment, the predetermined input order is that the first is the drafter (that is, the house maker) and the second is the intermediary (that is, the sales person) (see FIG. 2). The first creation unit 402 creates the first request form based on the input items transmitted in step (2) of FIG. The first creation unit 402 creates a second request form based on the input items transmitted in step (6) of FIG. The first request form created by the first preparation unit 402 is the first request form shown in FIG. The second request form prepared by the first preparation unit 402 is the second request form shown in FIG.

The second creation unit 404 creates a proposal by receiving input from the proposer (that is, the planner) after the request form (in the present embodiment, the second request form) is created by the first creation unit 402. To do. The second creation unit 404 creates a proposal based on the input items transmitted in step (9) of FIG.

The first request form and the second request form created by the first creation unit 402 are stored in the document DB 442 (database). Further, the first request form and the second request form are stored in association with, for example, the ID of the creator. In the present embodiment, since the first request form is created by the house maker with ID = 1, the first request form is stored in association with ID = 1. Further, since the second request form is created by the sales person with ID = 2, the second request form is stored in association with ID = 2.

Further, the proposal prepared by the second preparation unit 404 is stored in the document DB 442. Further, this proposal is stored in association with, for example, the ID of the creator. In the present embodiment, since the proposal is created by the planner with ID = 3, the proposal is stored in association with ID = 3. Further, the proposal may be modified by the sales person in the second terminal device 200. Further, the proposal may be modified by the house maker with the first terminal device 100. When the proposal is modified, the modified proposal is stored in association with the ID of the user who modified the proposal.

The reception unit 401 receives approval for the proposal from a plurality of users in the reverse order of the above input order. Here, in the above-mentioned input order, the first is the drafter (that is, the house maker), and the second is the intermediary (that is, the sales person). Therefore, the reverse order of the input order is that the first is the intermediary (that is, the sales person) and the second is the drafter (that is, the house maker).

The setting unit 408 can set whether or not to have viewing authority for each of the information contained in the request form (in the present embodiment, the first request form and the second request form) for each user ID. Here, the "viewing authority" refers to the authority to allow the user to view the information contained in the request form (in the present embodiment, the first request form and the second request form). The granting unit 410 can grant the authority to set the viewing authority using the setting unit 408 to at least one of the ID of the intermediary (that is, the sales person) and the ID of the proposer (that is, the planner). .. In the present embodiment, the granting unit 410 grants the ID of the intermediary (that is, the sales person) the authority to set the viewing authority. In the example of FIG. 14, the "user ID 2" is stored in the storage area 444 of the "authority for setting the viewing authority" in the storage device 440. This "user ID 2" is the ID of the intermediary (that is, the sales person). As a modification, the granting unit 410 may grant the proposer the authority to set the viewing authority.

In addition, the sales person who is granted the authority to set the viewing authority can restrict the viewing of information to the user designated by the sales person. Restricting the viewing of information is also referred to as "viewing restriction" or "setting viewing restriction". The viewing restriction of this information can be set by, for example, a terminal device logged in by the ID of a sales person. Typically, a terminal device logged in with the ID of a sales person displays a setting screen (not shown), and the setting screen sets restrictions on information viewing. The viewing restriction is executed by the server device 400. For example, as shown by the “x” in FIG. 16 described later, the user (ID = 3 lighting) has a “submission deadline set by the house maker (ID = 1)” (that is, information included in the request form). Viewing by the manufacturer's planner) is restricted. Further, "restricting the viewing of information to a designated user" means "preventing the information from being displayed on the terminal device logged in with the user ID of the designated user".

FIG. 15 is a diagram for explaining an image of viewing authority. As shown in FIG. 2, from the viewpoint of information flow, the house maker (house maker ID) is higher, and the intermediary (intermediary ID) is lower than the house maker (house maker ID). The planner (planner's ID) is lower than the intermediary (intermediary's ID).

On the other hand, as shown in FIG. 15, from the viewpoint of the authority to set the viewing authority, the intermediary (intermediary ID) is higher than the house maker (house maker ID) and the planner (planner ID). ing. That is, the authority to set the viewing authority is given to the intermediary ID (see user ID 2 in FIG. 14). In other words, the viewing authority of the request form (first request form and second request form) can be set by the terminal device logged in with the intermediary ID (see user ID 2 in FIG. 14).

[Example of viewing restrictions]
FIG. 16 is a diagram showing an example in which whether or not to restrict viewing of each information of the request form (first request form and second request form) is set for each user ID. Further, FIG. 16 will be described with reference to the first request form described with reference to FIG. 3 and the second request form described with reference to FIG. In FIG. 16, “◯” indicates that the display device of the terminal device can display, that is, the viewing restriction is not set. “X” indicates that the display device of the terminal device cannot be displayed, that is, the viewing restriction is set. In addition, a request form ID is assigned to the created request form. For example, a request form ID associated with the terminal device for which the request is newly created is given to the request form. FIG. 16 is a diagram showing whether or not there is a restriction on viewing each information of the request form of the request form ID associated with the terminal device for which the request is newly created.

In the examples of FIGS. 3, 4 and 16, the project name (“Osaka City” in the examples of FIGS. 3 and 4) is the first terminal device 100, the second terminal device 200, and the third terminal device 300 (in the example of FIGS. 3 and 4, “Osaka City”). ID1 to ID3) are set to be displayable.

In the examples of FIGS. 3, 4 and 16, the name of the client (“Yamada-sama's house” in the example of FIG. 3) is displayed by the first terminal device 100 (ID1) and the second terminal device 200 (ID2). It is possible. On the other hand, the name of the client cannot be displayed on the third terminal device 300 (ID3).

In the examples of FIGS. 3, 4 and 16, the budget (“400,000 yen” in the examples of FIGS. 3 and 4) is provided by the first terminal device 100, the second terminal device 200, and the third terminal device 300. It can be displayed.

In the examples of FIGS. 3, 4 and 16, the first terminal device 100 and the second terminal device 200 can display the submission deadline (that is, September 20) set by the first terminal device 100. There is. On the other hand, the third terminal device 300 cannot display the submission deadline (that is, September 20) set by the first terminal device 100.

Further, the second terminal device 200 and the third terminal device 300 can display the submission deadline (that is, September 13) set by the second terminal device 200. On the other hand, the submission deadline (that is, September 13) set by the second terminal device 200 cannot be displayed by the first terminal device 100.

In the examples of FIGS. 3, 4 and 16, the floor plan can be displayed by the first terminal device 100, the second terminal device 200, and the third terminal device 300.

Further, the second terminal device 200 and the third terminal device 300 can display the device information (device M1 and device M2) set in the second terminal device 200. On the other hand, the first terminal device 100 cannot display the device information (device M1 and device M2) set in the second terminal device 200.

As shown in FIG. 16, the setting unit 408 can set whether or not to restrict viewing of each information of the request form (first request form and second request form) for each user ID. As described above, the authority to set the viewing authority is given to the intermediary ID. Therefore, the intermediary can freely browse the desired information of the first request form and the second request form.

[Flowchart of workflow system processing]
FIG. 17 is a diagram showing an example of a flowchart of the workflow system 10. In the example of FIG. 17, a process to be executed after the request is newly created and the display of the state 862 of the first terminal device 100 becomes “new” will be described.

First, in step S102, the first terminal device 100 accepts the input of the items of the first request form from the house maker. Next, in step S104, the first terminal device 100 transmits the input items of the first request form to the server device 400. In step S402, the server device 400 creates the first request form (see FIG. 3) based on the input items. Next, in step S404, the server device 400 transmits a state change signal to the first terminal device 100 and the second terminal device 200. In step S106, the first terminal device 100 changes the display of the state 862 from "new" to "waiting for creation" by receiving this state change signal. Further, in step S202, the second terminal device 200 displays "new" as the state 862 by receiving this state change signal.

Next, in step S204, the second terminal device 200 accepts the input of the items of the second request form from the sales person. Next, in step S206, the second terminal device 200 transmits the input items of the second request form to the server device 400. In step S406, the server device 400 creates a second request form (see FIG. 4) based on the input items. Next, in step S408, the server device 400 transmits a state change signal to the second terminal device 200 and the third terminal device 300. In step S208, the second terminal device 200 changes the display of the state 862 from "new" to "waiting for creation" by receiving this state change signal. Further, in step S302, the third terminal device 300 displays "new" as the state 862 by receiving this state change signal.

Next, in step S308, the third terminal device 300 accepts the input of the items of the proposal from the planner. Next, in step S310, the third terminal device 300 transmits the input items of the proposal to the server device 400. In step S412, the server device 400 creates a proposal (see FIG. 5) based on the input items. Next, in step S414 of FIG. 18, the server device 400 transmits a state change signal to the second terminal device 200 and the third terminal device 300. In step S210, the second terminal device 200 changes the display of the state 862 from "waiting for creation" to "under confirmation" by receiving this state change signal. Further, in step S312, the third terminal device 300 changes from "creating" to "submitted" as the state 862 by receiving this state change signal.

Next, in step S212, the sales person who confirmed the proposal operates the submit button 892 of the second terminal device 200 to transmit the approval signal to the server device 400. When the server device 400 receives the approval signal in step S416, the server device 400 transmits the state change signal to the first terminal device 100 and the second terminal device 200 in step S418. In step S214, the second terminal device 200 changes from "confirming" to "submitted" as the state 862. In step S108, the first terminal device 100 changes from "waiting for creation" to "under confirmation" as the state 862.

Next, in step S110, the house maker who confirmed the proposal operates the submit button 892 of the first terminal device 100 to transmit the approval signal to the server device 400. When the server device 400 receives the approval signal in step S420, the server device 400 transmits the state change signal to the first terminal device 100 in step S422. In step S112, the first terminal device 100 changes from "confirming" to "submitted" as the state 862.

[Brief Summary]
(1) The workflow system 10 of the present embodiment includes a drafter who drafts a request (a house maker in the present embodiment), a proposer who creates a proposal based on the request (a planner in the present embodiment), and a drafter. The ID given to each of the intermediary (in this embodiment, the sales person) intervening between the person and the proposer is identified. In this embodiment, the house maker has ID = 1, the sales person has ID = 2, and the planner has ID = 3.

The first creation unit 402 receives inputs by a plurality of users including the drafter and an intermediary to the plurality of users in a predetermined input order, and thereby requests the plurality of users to include items input by the plurality of users. Create a document (first request form and second request form). The second preparation unit 404 prepares the proposal by accepting the input by the proposer (planner) after the request (first request and the second request) is prepared by the first preparation unit 402. Further, the reception unit 401 receives approval for the proposal from a plurality of users in the reverse order of the input order.

Therefore, the first creation unit 402 accepts inputs by a plurality of users including the drafter and the intermediary in a predetermined input order for the plurality of users, so that the matters input by the plurality of users can be received. By creating the request form including the request form, it is possible to create a request form that reflects the intentions of a plurality of users. Further, since the reception unit 401 accepts the approval of the proposal in the reverse order of the input order, it is possible to have the drafter and the intermediary who input the matters for creating the request form approve the proposal. Further, the server device 400 of the workflow system 10 collectively creates a request form, creates a proposal form, and accepts approval. Further, the server device 400 stores the request form and the proposal form. Therefore, the server device 400 can collectively manage the request form and the proposal form. Further, while the server device 400 collectively manages the request form and the proposal form, the user can feel that a system for transmitting and receiving information between the terminal devices is virtually constructed. ..

Further, in the present embodiment, the authority to set the viewing authority for the information included in the request form is given to the intermediary ID (see the storage area 444 of "authority to set the viewing authority" in FIG. 14). ..

For example, when the workflow system 10 is used to create a proposal for a lighting fixture as in the present embodiment, the intermediary (sales representative of the lighting maker) uses the lighting of his / her own lighting maker. I think the equipment will be used. However, for example, it may be discovered that the inventory of the luminaires proposed in the proposal is not significantly reduced (that is, the luminaires proposed in the proposal are not used). If it is discovered that the luminaire proposed in the proposal is not being used, the lighting manufacturer's sales representative may want to check all requests and proposals. That is, the sales representative of the lighting manufacturer may want to check the past log of the request form and the past log of the proposal. Therefore, in the present embodiment, the sales person in charge of the lighting manufacturer, that is, the ID of the intermediary is given the authority to set the viewing authority for the information included in the request form. Therefore, the intermediary can freely browse the desired information of the first request form and the second request form by removing the viewing restrictions of the first request form and the second request form. As a result, the intermediary can freely check the past log of the request form and the past log of the proposal. Therefore, in the workflow system 10 of the present embodiment, it is possible to set the viewing authority in consideration of the relationship between each person.

For example, suppose a sales person thinks that luminaire X will be used. However, it is assumed that the sales person intends to input the lighting fixture X as the input item of the second request form, but mistakenly inputs the lighting fixture Y. In addition, a proposal was made by the planner to the effect that luminaire Y would be used, but the salesperson was unaware that luminaire Y would be used in the proposal and was erroneous in response to this proposal. And approve it. In this case, the luminaire Y (that is, the luminaire different from the luminaire assumed by the sales person) is used to build the house. After that, the sales person notices that the lighting fixture Y is being used. In this case, since the sales person can confirm all the request forms, the sales person must specify that the lighting fixture Y has been mistakenly entered as the input item of the second request form. Can be done.

Further, the proposal before the modification and the proposal after the modification may be displayed on the second terminal device 200 (that is, the terminal device logged in with the ID of the intervener). As a result, even if the proposal is amended, the intermediary can view the proposal before the amendment and the proposal after the amendment. Therefore, for example, even if the house maker amends the proposal in the first terminal device 100, the amended proposal can be confirmed. For example, suppose that the proposal approved by the intermediary stated that the luminaire X was used, but the house maker changed the luminaire X to the luminaire Y. Even in this case, since the intermediary can view the revised proposal, the intermediary can specify that "the house maker has modified the lighting fixture X to the lighting fixture Y".

(2) Further, as shown in FIG. 5, the proposal of the present embodiment includes a matter in which an object (for example, instrument information 834) is arranged in a layout drawing (for example, floor plan 830). Therefore, in the workflow system 10 of the present embodiment, it is possible to appropriately create a proposal in which the object is arranged in the floor plan 830.

(3) Further, the floor plan 830 can be viewed with all of the user's IDs (see, for example, B in FIG. 6). Therefore, since all users can confirm the floor plan 830, the recognition of the floor plan 830 can be shared.

(4) Further, as shown in FIGS. 3 and 16, the first terminal device 100 and the second terminal device 200 display the name of the client. On the other hand, as shown in FIGS. 4 and 16, the third terminal device 300 does not display the requester's name because the viewing of the requester's name is restricted. As a result, the privacy of the client can be protected. The information about the client (that is, the owner) may be other information as long as it is about privacy. Other information may be, for example, the address of the requester or my number.

Further, in the examples of FIGS. 3, 4 and 16, the submission deadline (that is, September 20) set by the first terminal device 100 can be displayed by the first terminal device 100 and the second terminal device 200. It has become. On the other hand, the third terminal device 300 cannot display the submission deadline (that is, September 20) set by the first terminal device 100.

Further, the second terminal device 200 and the third terminal device 300 can display the submission deadline (that is, September 13) set by the second terminal device 200. On the other hand, the submission deadline (that is, September 13) set by the second terminal device 200 cannot be displayed by the first terminal device 100.

The submission deadline (that is, September 20) set by the first terminal device 100 is information that is not necessary for the planner. Therefore, in the third terminal device 300 used by the planner, the viewing restriction is set on the submission deadline (that is, September 20) set in the first terminal device 100. Further, the submission deadline (that is, September 13) set by the second terminal device 200 is information that is not necessary for the house maker. As described above, in the present embodiment, it is possible to prevent unnecessary information from being displayed by setting the viewing restriction on the terminal device that does not need to display the deadline for submitting the proposal. In this way, the information included in the request form can be viewed by the terminal device in which this information is set and the next terminal device, while viewing restrictions are set in the other terminal devices. The next terminal device is the next terminal device in the above-mentioned "predetermined input order".

For example, the deadline for submitting a proposal (9/20), which is information contained in a request form, can be viewed by the first terminal device 100 and the next second terminal device 200 in which this information is set, while others. In the third terminal device 300 of the above, viewing restrictions are set. In addition, the deadline for submitting the proposal (9/13), which is the information included in the request form, can be viewed by the second terminal device 200 in which this information is set and the next third terminal device 300, while others. In the first terminal device 100 of the above, viewing restrictions are set.

(5) Further, the workflow system 10 causes the terminal device to display the status of the request form and the proposal form for each ID. In this embodiment, for example, as shown in FIG. 12, the state 862 (see FIG. 7) is displayed for each terminal device (for each ID). This allows the user to easily identify the status of the request and proposal.

(6) Further, the state of the request form and the proposal (for example, the state related to the preparation of the request form and the proposal) is one of the six predetermined states. In the present embodiment, as shown in FIG. 7, the six states are "new", "waiting for creation", "submitted", "confirming", "creating", and "unnecessary". Assuming that in a workflow system in which the displayed state is not predetermined, the user is not accustomed to displaying the state, which causes a problem that the user has difficulty in understanding the state. In the present embodiment, since the terminal device displays one of the six states, it is possible to make it easier for the user to understand the states of the request form and the proposal form.

(7) Further, when the workflow system 10 executes the termination operation on the terminal device logged in by any of the drafter's ID, the proposer's ID, and the intermediary's ID, the workflow system 10 makes a request and a proposal. End the process of creating. The end operation of the present embodiment is an operation to the completion button 894 (see FIG. 7). By operating the completion button 894, the "request information of 1" including the operated completion button 894 is deleted. By this erasure, even if the request and the proposal are incomplete, the process of creating the request and the proposal is completed. For example, a house maker may receive an order from the owner, but the order may be canceled by the time the proposal is created. In this case, the house maker can delete the request information by operating the completion button 894, and as a result, the process of creating the request form and the proposal can be appropriately terminated. As a modification, the completion button 894 is displayed so that the request can be operated by the newly created terminal device (that is, the terminal device in which the newly created button 880 is operated), and cannot be operated by other terminal devices. The completion button 894 may be displayed so as to be.

<Second Embodiment>
FIG. 19 is a diagram for explaining the second embodiment. FIG. 19 is a modified view of FIG. In the first embodiment, as shown in FIG. 2, the intermediary is described as one of the sales personnel. In the second embodiment, as shown in FIG. 19, there are two intermediaries, a sales person and a planner of the lighting manufacturer. In addition, the proposer is a planner of a company different from the lighting manufacturer (hereinafter referred to as "external planner").

In addition, ID = 1 is given to the house maker. ID = 2 is given to the sales person. ID = 3 is given to the planner of the lighting manufacturer. ID = 4 is given to the planner outside the company. Further, the terminal device used by the house maker (that is, the terminal device logged in with ID = 1) is referred to as the first terminal device 100. The terminal device used by the sales person (that is, the terminal device logged in with ID = 2) is referred to as the second terminal device 200. The terminal device used by the planner of the lighting manufacturer (that is, the terminal device logged in with ID = 3) is referred to as the third terminal device 300. The terminal device used by the external planner (that is, the terminal device logged in with ID = 4) is referred to as the fourth terminal device 350. Although not particularly shown, the workflow system of the present embodiment includes a server device 400 in addition to the first to fourth terminal devices. The functional configuration of the server device 400 is as shown in FIG.

The first creation unit 402 of the second embodiment includes a plurality of drafters (house maker in the example of FIG. 19) and two or more interveners (sales person and planner of a lighting maker in the example of FIG. 19). By accepting the input by the user in the predetermined input order, a request form including the items input by a plurality of users is created. Here, this request form is a first request form, a second request form, and a third request form. Further, in the predetermined input order, the first is the drafter (that is, the house maker), the second is the first intermediary (that is, the sales person), and the third is the second. An intermediary (that is, a lighting manufacturer's planner).

The first request form 700 is as shown in FIG. 3, and the second request form 800 is as shown in FIG. FIG. 20 is an example of the third request form 850. The planner of the signature maker inputs the items of the third request form from the input screen. The third terminal device 300 transmits the input items of the third request form to the server device 400. The first creation unit 402 of the server device 400 creates the third request form 850 based on the items from the third terminal device 300. As shown in FIG. 21, the items of the third request form 850 include the project name 852, the plan name 854, the budget 856, the submission deadline 858, the floor plan file 860, and the equipment information 861.

The project name 852 includes the place where the house is built, but does not include the client of the house construction. In the example of FIG. 2, the project name 852 is "Osaka City". The plan name 854 is "A plan". The budget of 856 is "300,000 yen". The deadline for submission 858 is "September 6th". In other words, the lighting manufacturer has set a budget to obtain a gain of 100,000 yen (400,000-300,000 yen). Further, when the floor plan file 860 is clicked, the floor plan is displayed on the terminal device displaying the third request form. This floor plan is the same as the floor plan described with reference to FIG. Instrument information 861 includes instrument M1, instrument M2, and instrument M3. The third request form 850 is created based on the items by the server device 400 that has received the input of the items of the third request form.

FIG. 21 is a diagram showing an example in which whether or not to restrict viewing of each information of the request forms (first request form, second request form, and third request form) of the present embodiment is set for each user ID.

In the examples of FIGS. 3, 4, 20, and 21, the project name (“Osaka City” in the examples of FIGS. 3, 4, and 20) is the first terminal device 100, the second terminal device 200, The third terminal device 300 and the fourth terminal device 350 (ID1 to ID4) are set to be displayable.

In the examples of FIGS. 3, 4, 20, and 21, the client name (“Yamada-sama's house” in the example of FIG. 3) is the first terminal device 100 (ID1) and the second terminal device 200 (ID2). ) Can be displayed. On the other hand, the name of the client cannot be displayed on the third terminal device 300 (ID3) and the fourth terminal device 350 (ID4).

In the examples of FIGS. 3, 4, 20, and 21, the first terminal device 100 and the second terminal device 200 can display the budget (that is, 400,000 yen) set by the first terminal device 100. ing. On the other hand, the budget set by the first terminal device 100 (that is, 400,000 yen) cannot be displayed by the third terminal device 300 and the fourth terminal device 350.

Further, the budget set by the second terminal device 200 (that is, 400,000 yen) can be displayed by the second terminal device 200 and the third terminal device 300. On the other hand, the budget set by the second terminal device 200 (that is, 400,000 yen) cannot be displayed by the first terminal device 100 and the fourth terminal device 350.

Further, the third terminal device 300 and the fourth third terminal device 300 can display the budget set by the third terminal device 300 (that is, 300,000 yen). On the other hand, the budget set by the third terminal device 300 (that is, 300,000 yen) cannot be displayed by the first terminal device 100 and the second terminal device 200.

In this way, the "budget", which is the information included in the request form, can be viewed by "the terminal device in which this information is set and the next terminal device, while viewing restrictions are set in other terminal devices. It is the restriction information. Further, in the example of FIG. 21, the restriction information includes the deadline for submitting the proposal and the device information.

Further, the authority to set the viewing authority is given to at least one of the ID of the intermediary and the ID of the proposer. For example, the authority to set the viewing authority is given to the ID of the sales representative of the lighting manufacturer among the intermediaries.

According to the present embodiment, the first creation unit 402 includes items input by a plurality of users by accepting inputs by a plurality of users including the drafter and the intermediary 2 in a predetermined input order. Create request forms (first request form, second request form, and third request form). Therefore, it is possible to appropriately form a workflow system that can create a proposal while increasing the number of people who create a request.

Further, for example, if the budget (400,000 yen) set in the first terminal device 100 can be displayed on the fourth terminal device 350, there is a possibility that troubles may occur between users regarding the budget. Therefore, in the present embodiment, as shown in FIG. 21, the restriction information includes the amount of money of the object (for example, installation of lighting equipment) proposed by the proposal. Therefore, the workflow system of the present embodiment can reduce the occurrence of troubles between users regarding the budget.

FIG. 22 is a diagram showing a modified example of the second embodiment. In the example of FIG. 22, it is assumed that there are three intermediaries: a person in charge of wholesale of electrical materials, a person in charge of sales, and a planner of a lighting manufacturer. The person in charge of wholesale of electrical materials is, for example, a person who decides which of a plurality of lighting manufacturers to request. In addition, the proposer is an outside planner of the lighting manufacturer.

In addition, ID = 1 is given to the house maker. ID = 2 is given to the sales person. ID = 3 is given to the planner of the lighting manufacturer. ID = 4 is given to the planner outside the company. ID = 5 is given to the person in charge of wholesale of electrical materials.

Further, the terminal device used by the house maker (that is, the terminal device logged in with ID = 1) is referred to as the first terminal device 100. The terminal device used by the sales person (that is, the terminal device logged in with ID = 2) is referred to as the second terminal device 200. The terminal device used by the planner of the lighting manufacturer (that is, the terminal device logged in with ID = 3) is referred to as the third terminal device 300. The terminal device used by the external planner (that is, the terminal device logged in with ID = 4) is referred to as the fourth terminal device 350. The terminal device used by the person in charge of electrical material wholesale (that is, the terminal device logged in with ID = 5) is referred to as the fifth terminal device 360.

As shown in FIG. 22, even if the number of intermediaries is 3 or more, it is possible to appropriately form a workflow system capable of creating a proposal while increasing the number of request forms.

<Third Embodiment>
The workflow system of the first embodiment and the second embodiment has been described as creating one type of request (request for lighting equipment) and one type of proposal (proposal for lighting equipment). The workflow system of the third embodiment creates a request form of the first type and a proposal form of the first type, and a request form of the second type and a proposal form of the second type.

FIG. 23 is a diagram for explaining the workflow system of the third embodiment. FIG. 23 is a modified view of FIG. In the first embodiment, as shown in FIG. 2, the intermediary is described as one sales person of the lighting maker, and the proposer is the planner of one lighting maker. In the third embodiment, as shown in FIG. 23, the interveners are the sales person of the lighting maker and the sales person of the curtain maker, and the proposers are the planner of the lighting maker and the planner of the curtain maker. .. A curtain maker is, for example, a maker who newly installs a curtain in a house.

The sales representative of the lighting manufacturer corresponds to the "first intermediary" of the present disclosure. The lighting manufacturer's planner corresponds to the "first proposer" of the present disclosure. The sales representative of the curtain maker corresponds to the "second intermediary" of the present disclosure. The planner of the curtain maker corresponds to the "second proposer" of the present disclosure.

The first type of request form is a request form for lighting equipment. The first type of request form is the first request form described with reference to FIG. 3 and the second request form described with reference to FIG. The first type of proposal is a proposal for lighting equipment. The first type of proposal is the proposal described with reference to FIG.

The second type of request is a curtain request. Although the request form of the second type is not particularly illustrated, for example, the project name, the document name, the budget, the submission deadline, the floor plan file, etc. are described as in FIGS. 3 and 4. Further, as shown in FIG. 4, the device information may be described in the second request form of the second type. The appliance information is information indicating a curtain.

Although not particularly illustrated, the second type of proposal is, for example, the floor plan 830 described with reference to FIG. 5 in which a curtain is associated.

In addition, ID = 1 is given to the house maker. ID = 2 is given to the sales person of the lighting manufacturer. ID = 3 is given to the planner of the lighting manufacturer. ID = 4 is given to the sales person of the curtain maker. ID = 5 is given to the planner of the curtain maker.

Further, the terminal device used by the house maker (that is, the terminal device logged in with ID = 1) is referred to as the first terminal device 100. The terminal device used by the sales person of the lighting manufacturer (that is, the terminal device logged in with ID = 2) is referred to as the second terminal device 200A. The terminal device used by the planner of the lighting manufacturer (that is, the terminal device logged in with ID = 3) is referred to as the third terminal device 300A. The terminal device used by the sales staff of the curtain maker (that is, the terminal device logged in with ID = 4) is referred to as the second terminal device 200B. The terminal device used by the planner of the curtain maker (that is, the terminal device logged in with ID = 5) is referred to as the third terminal device 300B. Although not particularly shown, the workflow system of the present embodiment includes a server device 400 in addition to the first to third terminal devices. The functional configuration of the server device 400 is as shown in FIG.

The first creation unit 402 accepts inputs by a plurality of users including the drafter and the first intervener in a predetermined input order for the plurality of users, and thereby receives the matters input by the plurality of users. Create a request form of the first type including.

Here, the "drafter" is the "house maker" in the example of FIG. 23, and the "first intermediary" is the "sales person in charge of the lighting maker". Further, in the predetermined input order, the first is the drafter (that is, the house maker), and the second is the first intermediary (that is, the sales person of the lighting maker) (see FIG. 23). ). Further, in the example of FIG. 23, the request form of the first type is the first request form of the first type and the second request form of the first type.

Further, the first creation unit 402 receives inputs by a plurality of users including the drafter and the second intermediary in a predetermined input order for the plurality of users, so that the plurality of users input the inputs. Create a second type request form that includes the items.

Here, the "drafter" is the "house maker" in the example of FIG. 23, and the "second intermediary" is the "sales person in charge of the curtain maker". Further, in the predetermined input order, the first is the drafter (that is, the house maker), and the second is the second intermediary (that is, the sales representative of the curtain maker) (see FIG. 23). ). Further, in the example of FIG. 23, the second type request form is the second type first request form and the second type second request form.

The second creation unit 404 first prepares the first type of request form after the first type of request form is created (that is, after both the first type of first request form and the first type of second request form are created). By accepting the input by the proposer, the first type of proposal is created. Here, the first proposer is a planner of a lighting manufacturer.

Further, the second creation unit 404 will perform after the second type request form is created (that is, after both the second type first request form and the second type second request form are created). By accepting the input by the second proposer, the second type of proposal is created. Here, the second proposer is a planner of a curtain maker.

In the present embodiment, the number of types of request forms and proposals created by the workflow system has been described as "2". However, the number of types of request forms and proposals created by the workflow system may be 3 or more. For example, in addition to the example shown in FIG. 23, there may be a sales representative of the housing equipment manufacturer as the third intermediary, and a planner of the housing equipment manufacturer as the third proposer.

With the workflow system of this embodiment, it is possible to create a plurality of types of request forms and proposals.

<Fourth Embodiment>
The workflow system of the fourth embodiment completes the proposal by further modifying the proposal created by the proposer by another proposer.

FIG. 24 is a diagram for explaining the workflow system of the fourth embodiment. FIG. 24 is a modified view of FIG. In the first embodiment, as shown in FIG. 2, the sales person approves the proposal prepared by the planner of the lighting maker, and then the house maker approves it. In the fourth embodiment, the proposal prepared by the planner of the lighting manufacturer is amended by the external planner. Then, the sales person approves the proposal revised by the external planner, and then the house maker approves it.

The lighting manufacturer's planner corresponds to the "first proposer" of the present disclosure. The external planner corresponds to the "second proposer" of this disclosure.

Further, the terminal device used by the house maker (that is, the terminal device logged in with ID = 1) is referred to as the first terminal device 100. The terminal device used by the sales person of the lighting manufacturer (that is, the terminal device logged in with ID = 2) is referred to as the second terminal device 200. The terminal device used by the planner of the lighting manufacturer (that is, the terminal device logged in with ID = 3) is referred to as the third terminal device 300A. The terminal device used by the external planner (that is, the terminal device logged in with ID = 4) is referred to as the fourth terminal device 350. Although not particularly shown, the workflow system of the present embodiment includes a server device 400 in addition to the first to fourth terminal devices. The functional configuration of the server device 400 is as shown in FIG.

After the request form is created by the first creation unit 402 (that is, after the first request form and the second request form are created), the second preparation unit 404 is the first proposer (that is, the lighting manufacturer). The first proposal is created by accepting the input by the planner). The second terminal device 200 displays the first proposal. In addition, the sales representative of the lighting manufacturer outputs a correction request for the first proposal to the external planner via the server device 400. The external planner prepares the second proposal by modifying the first proposal. That is, the second creation unit 404 creates the second proposal by accepting the input by the second proposer after the first proposal is created.

After that, the sales representative of the lighting manufacturer approves the second proposal. The house maker then approves the second proposal.

In the workflow system of the present embodiment, the second proposer modifies the proposal created by the first proposer. Therefore, the workflow system of the present embodiment can create a proposal that reflects the intentions of the two proposers.

<Modification example>
(1) One embodiment of the first to fourth embodiments may be applied to another embodiment. For example, when the second embodiment (see FIG. 19) is applied to the third embodiment (see FIG. 23), at least one of the interventions of the lighting maker and the intervention of the curtain maker is two or more. May be an intermediary.

(2) In the above-described embodiment, the target of the proposal to be prepared is "house design (for example, lighting equipment, curtain)". However, the subject of the proposal may be another subject. The target of the proposal may be the design of an automobile, the design of a computer, or the like.

(3) Further, the other device may have at least one function of each function of the server device 400. For example, the terminal device may have the functions of the first creation unit 402 and the second creation unit 404. According to such a configuration, since the terminal device can create the request form and the proposal, the burden on the server device 400 can be reduced.

In addition, each embodiment disclosed this time should be considered to be exemplary in all respects and not restrictive. The scope of the present invention is shown not by the above description but by the scope of claims, and is intended to include all modifications within the meaning and scope equivalent to the scope of claims. In addition, the inventions described in the embodiments and the modifications are intended to be implemented, either alone or in combination, wherever possible.

100 1st terminal device, 102, 202, 302 input device, 104, 204, 304, 420 control device, 106, 206, 306, 3006 display device, 200, 200A, 200B 2nd terminal device, 300, 300A, 300B 3 terminal device, 350 4th terminal device, 360 5th terminal device, 400 server device, 401 reception unit, 402 1st creation unit, 404 2nd creation unit, 408 setting unit, 410 granting unit, 440 storage device, 444 storage Area, 492 ROM, 493 RAM, 700 1st request, 800 2nd request.

Claims (11)

It is a workflow system that identifies the IDs given to each of the drafter who drafts the request, the proposer who creates the proposal based on the request, and the intermediary between the drafter and the proposer. hand,
By accepting inputs by a plurality of users including the drafter and the intermediary to the plurality of users in a predetermined input order, a request form including items input by the plurality of users is created. 1 Creation Department and
After the request form is created by the first preparation unit, the second preparation unit that creates the proposal by accepting the input by the proposer, and
A reception unit that accepts approval for the proposal from the plurality of users in the reverse order of the input order.
A setting unit that can set the presence or absence of viewing authority for the information included in the request form for each user ID, and
A workflow system including an granting unit that can grant the authority to set the viewing authority to at least one of the intervener's ID and the proposer's ID using the setting unit. The workflow system according to claim 1, wherein the proposal includes a matter in which an object is arranged in a layout drawing. The workflow system according to claim 2, wherein the layout drawing can be viewed by all of the user's IDs. The information whose viewing is restricted by the viewing authority includes at least one of the target amount proposed by the proposal, the information about the target requester proposed by the proposal, and the deadline for preparing the proposal. The workflow system according to any one of claims 1 to 3, which includes the workflow system. The workflow system according to any one of claims 1 to 4, wherein the workflow system displays the states of the request form and the proposal form on the terminal device for each ID. The workflow system according to claim 5, wherein the state of the request form and the state of the proposal is any one state of a plurality of predetermined states. In the workflow system, when the termination operation is executed on the terminal device logged in by any of the ID of the drafter, the ID of the proposer, and the ID of the intermediary, the request form and the proposal form. The workflow system according to any one of claims 1 to 6, which terminates the process of creating the above. The first creation unit receives inputs by a plurality of users including the drafter and two or more intermediaries in the predetermined input order, and thereby includes the matters input by the plurality of users. The workflow system according to any one of claims 1 to 7, wherein a document is created. The first preparation unit
By accepting inputs by a plurality of users including the drafter and the first intermediary to the plurality of users in a predetermined input order, a request of the first type including items input by the plurality of users. Create a book,
By accepting inputs by a plurality of users including the drafter and the second intermediary to the plurality of users in a predetermined input order, a second type of request including items input by the plurality of users. Create a book,
The second preparation unit
After the request form of the first type is created, the proposal form of the first type is created by accepting the input by the first proposer.
The workflow according to any one of claims 1 to 8, wherein a proposal of the second type is created by accepting an input by the second proposer after the request form of the second type is created. system. The second preparation unit
After the request form is created by the first preparation unit, the first proposal is created by accepting the input by the first proposer.
The workflow system according to any one of claims 1 to 9, wherein a second proposal is created by accepting an input by the second proposer after the first proposal is created. Included in the workflow system that identifies the IDs assigned to each of the drafter who drafts the request, the proposer who creates the proposal based on the request, and the intermediary between the drafter and the proposer. It is a server device
The server device
By accepting inputs by a plurality of users including the drafter and the intermediary to the plurality of users in a predetermined input order, a request form including items input by the plurality of users is created. 1 Creation Department and
After the request form is created by the first preparation unit, the second preparation unit that creates the proposal by accepting the input by the proposer, and
A reception unit that accepts approval for the proposal from the plurality of users in the reverse order of the input order.
A setting unit that can set the presence or absence of viewing authority for the information included in the request form for each user ID, and
A server device including an granting unit that can grant the authority to set the viewing authority using the setting unit to at least one of the ID of the intervener and the ID of the proposer.

Images