JP2022044139A - Information processing device, information processing method and program - Google Patents

Abstract

To meet the needs for the provision of technology with which it is possible to more efficiently extract the requirements of stakeholders and more effectively put these in order.SOLUTION: Provided is a business process management device comprising: a stakeholder extraction unit for extracting a first entity in charge of activity as a first stakeholder and extracting a second entity in charge of activity as a second stakeholder, on the basis of a business process that includes the respective entities in charge of first and second activities; a request acquisition unit for acquiring the requests of the first stakeholder; and a dependency relation extraction unit for extracting a dependency relation in which the requests of the first stakeholder, the elements which the requests of the first stakeholder depend on, and the second stakeholder are associated with each other, when the elements which the requests of the first stakeholder depend on and the elements which the second stakeholder can supply agree with each other.SELECTED DRAWING: Figure 1

Description

Application for application of Article 30, Paragraph 2 of the Patent Law was applied. Announced at the 2019 Smart SE Regular Student Completion Ceremony / Symposium on October 29, 1st Reiwa [Publications, etc.] February 28, 2nd Reiwa Electronic Information and Communication Technical Report Journal, Academic Technical Report, vol. 119, no. 467, KBSE2019-49, pp. Published in 19-24, March 2020

The present invention relates to an information processing apparatus, an information processing method and a program.

In recent years, various techniques for extracting and organizing the demands of stakeholders involved in a certain business have been proposed (see, for example, Patent Documents 1 to 3).

For example, in Patent Document 1, for the purpose of automating a business process, a technique that eliminates personal judgment in each of the four phases of the business process: definition design, development, management / monitoring, and analysis optimization. Has been proposed.

Patent Document 2 proposes a technique for extracting and managing stakeholders involved in business together with a strategy. With this technology, strategies of multiple stakeholders are modeled and organized based on the Balanced Scorecard.

Patent Document 3 proposes a technique for modeling interactions between stakeholders involved in a business as network nodes. Such technology provides visibility into the interactions between stakeholders.

Japanese Patent No. 5655326 Japanese Patent No. 5435210 Japanese Patent No. 5931383

Shuichiro Yamamoto, "Goal-Oriented-System Requirements Management Techniques", Soft Research Center, 2007

Here, stakeholder requirements can be fulfilled by interaction between stakeholders. Therefore, it is considered effective to sort out what kind of interaction between stakeholders realizes the demands of stakeholders. Furthermore, if stakeholder requirements are automatically extracted without personal judgment, it is considered that stakeholder requirements can be efficiently extracted.

Therefore, it is desired to provide a technology that can more efficiently extract the demands of stakeholders and organize them more effectively.

In order to solve the above problem, according to a certain viewpoint of the present invention, the person in charge of the first activity is the first person in charge of the first activity based on the business process including the person in charge of each of the first activity and the second activity. The stakeholder extraction department that extracts the entity in charge of the second activity as the second stakeholder, the request acquisition department that acquires the request of the first stakeholder, and the request of the first stakeholder. When the element on which the second stakeholder depends and the element that can be provided by the second stakeholder match, the element on which the request of the first stakeholder and the request of the first stakeholder depend and the second stakeholder correspond. A business process management device is provided that includes a dependency extraction unit that extracts the attached dependencies.

The business process management device decomposes the request of the first stakeholder into the first request and the second request, and then decomposes the request of the first stakeholder into the first request and the second request. The dependency extraction unit includes a requirement decomposition unit that decomposes into requirements, and the dependency extraction unit is a first dependency relationship in which the first requirement, the element on which the first requirement depends, and the second stakeholder are associated with each other. Then, the dependency may be updated to the second dependency in which the second request, the element on which the second request depends, and the second stakeholder are associated with each other.

The requirement decomposition unit includes the elements to which the first requirement and the second requirement depend when the requirement of the first stakeholder depends on the first requirement and the second requirement. If the factors that can be provided by the second stakeholder match, it may be determined that the requirements of the first stakeholder can be decomposed into the first requirement and the second requirement.

The requirement decomposition unit decomposes the decomposable requirement as long as the first requirement and the second requirement include the decomposable requirement, and the dependency extraction unit decomposes the decomposable requirement. Even if the decomposeable requirement is updated to the decomposed requirement and the element on which the decomposeable requirement depends is updated to the element on which the decomposed requirement depends. good.

When the request of the first stakeholder includes a third request and a fourth request that can be aggregated into one request, the dependency extraction unit combines the third request and the fourth request into one. When the elements that are aggregated into the requirements and the aggregated requirements depend on and the elements that can be provided by the second stakeholder match, the elements that the aggregated requirements and the aggregated requirements depend on and the first. Dependencies associated with two stakeholders may be extracted.

The dependency extraction unit has the third request and the third request depending on whether or not the sub-charger, which is a unit smaller than the responsible body, is the same in the third request and the fourth request. It may be determined whether or not the fourth request can be aggregated.

When the request of the first stakeholder includes a third request and a fourth request that cannot be integrated into one request, the stakeholder extraction unit sets the first stakeholder as a sub-responsible entity of the third request. When the element on which the third request depends and the element that can be provided by the second stakeholder match, the dependency extraction unit decomposes the element into the sub-sub-responsible entity of the fourth request, and the dependency extraction unit determines the first. You may extract the dependency relationship in which the element 3 depends on the request 3 and the third request and the second stakeholder are associated with each other.

When the third request and the fourth request can be aggregated, the dependency extraction unit converts the third request and the fourth request into the third request and the fourth request. It may be aggregated into one dependent request.

The dependency extraction unit may acquire from the storage unit the elements on which the request of the first stakeholder depends and the elements that can be provided by the second stakeholder.

The element on which the first stakeholder's requirements depend may include at least one of resources, tasks and requirements.

In the business process management device, when the first dependency and the second dependency are extracted by the dependency extraction unit, the first dependency and the second dependency have a predetermined pattern. When the pattern search unit for determining whether or not the first dependency and the second dependency match the pattern, the element of the first dependency and the second dependency A pattern application unit that associates an element of the dependency with an element that can be provided by a third stakeholder may be provided.

In the pattern, the element of the first dependency is the first resource, the element of the second dependency is the second resource, and the request of the first dependency. The stakeholder to which the second dependency belongs and the stakeholder who can provide the second resource of the second dependency match, and the stakeholder to which the request of the second dependency belongs belongs to the first dependency. The condition is that the stakeholder who can provide the first resource in the relationship matches, and the elements that can be provided by the third stakeholder are the first task applicable to the first resource and the first task. It may include a second task applicable to the second resource.

In the pattern, the element of the first dependency is the first resource, the element of the second dependency is the second resource, and the request of the first dependency. The stakeholder to which the first dependency belongs and the stakeholder who can provide the first resource of the first dependency match, and the stakeholder to which the request of the second dependency belongs belongs to the second dependency. The condition is that the stakeholder who can provide the second resource of the relationship matches, and the element that can be provided by the third stakeholder is applicable to the first resource and the second resource, respectively. It may include a task.

In the pattern, the element of the first dependency is the first resource, the element of the second dependency is the second resource, and the request of the first dependency. The stakeholder to which the request belongs, the stakeholder to which the request of the second dependency belongs, the stakeholder who can provide the first resource of the first dependency, and the second dependency. The condition that the third stakeholder can provide the second resource is the same as the stakeholder who can provide the second resource, even if the element that can be provided by the third stakeholder includes the first resource and the task applicable to the second resource. good.

Further, according to another viewpoint of the present invention, the entity in charge of the first activity is extracted as the first stakeholder based on the business process including the entity in charge of each of the first activity and the second activity. At the same time, extracting the entity in charge of the second activity as the second stakeholder, acquiring the request of the first stakeholder, the element on which the request of the first stakeholder depends, and the second. Extracting the dependency relationship between the element on which the request of the first stakeholder and the request of the first stakeholder depend and the element on which the second stakeholder is associated, when the elements that can be provided by the stakeholder are the same. And, a business process management method is provided.

Further, according to another aspect of the present invention, the computer is the subject in charge of the first activity as the first stakeholder based on the business process including the entity in charge of each of the first activity and the second activity. The stakeholder extraction department that extracts the entity in charge of the second activity as the second stakeholder, the request acquisition department that acquires the demands of the first stakeholder, and the demands of the first stakeholder depend on each other. When the element to be provided matches the element that can be provided by the second stakeholder, the element on which the request of the first stakeholder and the request of the first stakeholder depend and the second stakeholder are associated with each other. A program that functions as a business process management device including a dependency extraction unit that extracts the dependencies is provided.

As described above, according to the present invention, there is provided a technique capable of extracting stakeholder requests more efficiently and organizing them more effectively.

It is a block diagram which shows the functional structure example of the business process management apparatus which concerns on embodiment of this invention. It is a flowchart which shows the operation example of the business process management apparatus which concerns on embodiment of this invention. It is a figure which shows the example of the business process generated by the stakeholder extraction department. It is a figure which shows the example of the stakeholder information. It is a figure which shows the example of the element correspondence information. It is a figure which shows the component of the i * framework. It is a figure which visualized the example of the requirement model after the dependency is reflected. It is a figure which shows the data structure example of the request model after the dependency is reflected. It is a figure which visualized the example of the requirement model which reflected the dependency updated based on the requirement decomposition. It is a figure which shows the example of the requirement model which reflected the dependency updated based on the requirement decomposition. It is a figure which shows the specific example of the dependency extraction and the requirement decomposition. It is a figure which shows the example of the resource technology information in which "resource" and "the technology possessed by the analysis department which uses the corresponding resource" are associated. It is a figure which shows the 1st example of a reference pattern. It is a figure which shows the 2nd example of a reference pattern. It is a figure which shows the 3rd example of a reference pattern. It is a figure which shows the model of the i * framework representation which applied the Mediator pattern of a design pattern to the 1st example of a reference pattern. It is a figure which shows the model of the i * framework representation which applied the Template Method pattern of the design pattern to the 2nd example of a reference pattern. It is a figure which shows the model of the i * framework representation which applied the Observer pattern of a design pattern to the 3rd example of a reference pattern. It is a figure which shows the example which applied the Mediator pattern to the design department and the maintenance department in the ATM manufacturing supply chain. It is a figure which shows the example which applied the Template Method pattern to the design department, the production department, and the procurement department in the ATM manufacturing supply chain. It is a figure which shows the example which applied the Observer pattern to the maintenance department in the ATM manufacturing supply chain. It is a figure which shows the hardware configuration of the information processing apparatus as an example of the business process management apparatus which concerns on the same embodiment.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the present specification and the drawings, components having substantially the same functional configuration are designated by the same reference numerals, so that duplicate description will be omitted.

Further, in the present specification and the drawings, a plurality of components having substantially the same functional configuration may be distinguished by adding different numbers after the same reference numerals. However, if it is not necessary to distinguish each of a plurality of components having substantially the same functional configuration, only the same reference numerals are given. Further, similar components of different embodiments may be distinguished by adding different alphabets after the same reference numerals. However, if it is not necessary to distinguish each of the similar components of different embodiments, only the same reference numerals are given.

(0. Outline of Embodiment)
An outline of the embodiment of the present invention will be described. In the embodiment of the present invention, we propose a technique for extracting and organizing the requests of stakeholders involved in the business by a method different from the method related to the technique described in the above-mentioned Patent Documents 1 to 3.

The technique according to the embodiment of the present invention is based on the i * (Aistar) framework, which is one of the goal-oriented requirements analysis. By using the i * framework, it is possible to organize the dependencies of each request distributed to multiple stakeholders as a diagram. Dependencies will be described later.

As described in Non-Patent Document 1 described above, the i * framework is an "actor" who is interested in and responsible for achieving the requirement, and a "goal" which is a clear requirement whether or not the requirement is achieved. A "soft goal" that is an unclear requirement whether or not it has been achieved, a "task" that is a procedure for achieving the requirement, and a "physical or informational entity" that is used to fulfill the requirement or execute the task. It is composed of "resources".

In the embodiment of the present invention, by applying the i * framework modeling procedure to the stakeholder's request, the stakeholder's request is extracted by excluding personal judgment, and how the stakeholder's request is. We propose a technology to sort out whether it is realized by interaction between various stakeholders. In the following, organizing what kind of interaction between stakeholders realizes the demands of stakeholders is also called "modeling". In addition, what kind of interaction between stakeholders realizes the requirements of stakeholders is also called a "model" or "requirement model".

Further, in the embodiment of the present invention, by applying a design pattern, which is a software design pattern classification, to a model generated based on the i * framework, the requirements of a plurality of stakeholders can be efficiently realized. Propose technology. The features of the technique according to the embodiment of the present invention compared with the techniques described in each of Patent Documents 1 to 3 are shown below.

Patent Document 1 does not mention a plurality of stakeholders involved in the business, and the technology described in Patent Document 1 cannot be applied when interacting between stakeholders. On the other hand, since the technology according to the embodiment of the present invention organizes the requirements based on the i * framework, the requirements of a plurality of stakeholders can be organized in a unified manner.

In the technique described in Patent Document 2, extraction of a plurality of stakeholders requires personal judgment, and there is a possibility that the generated model may be omitted. On the other hand, the technique according to the embodiment of the present invention can automatically extract stakeholders excluding personal judgment by systematically generating a model based on the i * framework. In addition, in general, when the number of stakeholders to be extracted increases, the number of requests increases accordingly, and the management of requests may become complicated. On the other hand, in the embodiment of the present invention, not only the visibility of the requirement is given by the i * framework, but also the efficient realization method of the requirement is grasped by applying a specific design pattern to the model. obtain.

Similar to the technique described in Patent Document 2, the technique described in Patent Document 3 also requires personal judgment in extracting a plurality of stakeholders, and there is a possibility that the generated model may be omitted. .. Furthermore, since the technology described in Patent Document 3 can only express global interactions between stakeholders as a metamodel, it is necessary to separately consider how to efficiently realize the requirements. On the other hand, the technique according to the embodiment of the present invention breaks down the requirements to a level that can be realized by the i * framework, and even if the requirements increase, the increased requirements are aggregated by applying the design pattern. It can be realized efficiently.

(1. Details of the embodiment)
Subsequently, the details of the embodiment of the present invention will be described.

(1-1. Functional configuration example)
First, a functional configuration example of the business process management device according to the embodiment of the present invention will be described.

FIG. 1 is a block diagram showing a functional configuration example of the business process management device according to the embodiment of the present invention. As shown in FIG. 1, the business process management device 10 according to the embodiment of the present invention includes a requirement model generation block 100, an efficient requirement model generation block 200, an input unit 310, a data storage unit 320, and an output. A unit 330 is provided.

The requirement model generation block 100 is a block that generates a model for managing requirements distributed to a plurality of stakeholders based on the i * framework. As shown in FIG. 1, the requirement model generation block 100 has a stakeholder extraction unit 110, a requirement acquisition unit 120, a dependency extraction unit 130, and a requirement decomposition unit 140 as constituent elements. Further, the request model generation block 100 has a request model storage unit 150 in which the models generated by each of these units are sequentially stored.

The efficient requirement model generation block 200 is a requirement model that can be efficiently realized by applying a design pattern (hereinafter, also simply referred to as “pattern”) to a model based on the i * framework (hereinafter, “Pattern”). It is a block that generates an "efficient request model"). As shown in FIG. 1, the efficient request model generation block 200 has a pattern search unit 220 and a pattern application unit 230, respectively, as components. Further, the efficient request model generation block 200 includes a reference pattern storage unit 210 that stores the pattern referenced by the pattern search unit 220 in advance, and an efficient request model storage unit 240 that stores the generated efficient request model. Have.

The stakeholder extraction unit 110, the request acquisition unit 120, the dependency extraction unit 130, the request decomposition unit 140, the pattern search unit 220, and the pattern application unit 230 include an arithmetic unit such as a CPU (Central Processing Unit), and a ROM (Read Only Memory). ) Is expanded into the RAM by the arithmetic unit and executed, so that the function can be realized. At this time, a computer-readable recording medium on which the program is recorded may also be provided. Alternatively, these blocks may be configured by dedicated hardware or may be configured by a combination of a plurality of hardware.

The request model storage unit 150, the reference pattern storage unit 210, the efficient request model storage unit 240, and the data storage unit 320 are composed of a memory such as a RAM (Random Access Memory), a hard disk drive, or a flash memory.

The input unit 310 accepts operations by the user. As an example, the input unit 310 accepts input of information about the business, as will be described later. In the embodiment of the present invention, it is mainly assumed that the input unit 310 is a mouse and a keyboard. However, the form of the input unit 310 is not limited. For example, the input unit 310 may include a touch panel, an electronic pen, or another input device.

The output unit 330 has a function of outputting various information. For example, the output unit 330 may output a requirement model and an efficient requirement model. Here, the form of the output unit 330 is not particularly limited. For example, the output unit 330 may be a display. The display may be a liquid crystal display (LCD) device or an OLED (Organic Light Emitting Diode) device.

The functional configuration example of the business process management apparatus 10 according to the embodiment of the present invention has been described above.

(1-2. Operation example)
Subsequently, an operation example of the business process management device 10 according to the embodiment of the present invention will be described with reference to FIGS. 1 and 2 (with reference to other figures as appropriate).

FIG. 2 is a flowchart showing an operation example of the business process management device 10 according to the embodiment of the present invention.

(Information about business)
First, the input unit 310 accepts the input of information about the business. The information about the business may be at least information including a series of activities related to the target business and information indicating the person in charge of each activity. For example, information about a business may be information organized by modeling techniques, such as a business model canvas, pictograms, or multiple use cases that represent business activities. Information about the business may be received from other devices or may be read from a recording medium.

(Business process generation S11)
The stakeholder extraction unit 110 generates a business process based on information about the business (S11). As mentioned above, business information includes a series of business activities and information indicating the person in charge of each activity. Therefore, the stakeholder extraction unit 110 extracts a series of activities in the business and the entity in charge of each activity from the information about the business.

The method for extracting a series of activities is not limited as long as the series of activities can be extracted without omission. As an example, as a method for extracting a series of activities, Business Process Model & Notation (BPMN) defined in IOS 19510 and the like can be used. The stakeholder extraction unit 110 generates information including a series of activities and the entity in charge of each activity as a business process.

FIG. 3 is a diagram showing an example of a business process generated by the stakeholder extraction unit 110. Referring to FIG. 3, a business process 410 is shown as an example. Here, as an example of business, the manufacture of an automated teller machine (ATM) is assumed. For ATM products, each process is executed in the order of design, production, and operation. Therefore, the stakeholder extraction unit 110 extracts the flow of “design” → “production” → “operation” as a series of processes from the information related to the business process. Since the process corresponds to an activity in manufacturing, the activity according to the embodiment of the present invention is not limited to the process.

Further, the stakeholder extraction unit 110 extracts the "design department" as the main body in charge of the process "design" from the information about the business process, extracts the "production department" as the main body in charge of the process "production", and extracts the "production department" as the main body in charge of the process "production". Extract the "operation department" as the main body in charge of. The "department" is an example of the person in charge. Therefore, another responsible entity may be used instead of the "department".

As an example, in the example shown in FIG. 3, each department belonging to the same company is in charge, but the company in charge of the process "operation" is different from the company in charge of the process "design" and "production". (That is, it is also possible that only the process "operation" is outsourced to another company). In such a case, the entity in charge of the process "operation" is the operation company. That is, there is no restriction that stakeholders must belong to the same company, and they can be appropriately extracted according to the actual state of the business process.

Further, since each process extracted here is later aggregated (S14) or decomposed (S18), the particle size of the process extracted by the stakeholder extraction unit 110 may be any size. Therefore, here, it suffices to extract a plurality of processes and a department in charge of each of the plurality of processes.

(Stakeholder extraction S12)
Subsequently, the stakeholder extraction unit 110 extracts the departments in charge of each of the plurality of processes as stakeholders involved in the business based on the generated business process (S12). In the example shown in FIG. 3, "design department", "production department" and "operation department" are each extracted as stakeholders. Each stakeholder extracted by the stakeholder extraction unit 110 corresponds to an "actor" in the i * framework described later.

(Requirement model registration S13)
The stakeholder extraction unit 110 registers each extracted stakeholder in the request model storage unit 150 (S13). In this way, information is sequentially associated with each stakeholder registered in the request model storage unit 150 in the request model registration S13 in a later step (S16 and S19).

(Top request generation S14)
Subsequently, the request acquisition unit 120 acquires the request of each stakeholder, and the dependency extraction unit 130 generates the top-level request of each stakeholder. Stakeholder information, which is information about stakeholders, is used to obtain the requirements of each stakeholder. In addition, element correspondence information indicating the relationship between elements is used to generate the top-level request. It should be noted that the element may include at least one of a requirement (goal or soft goal), a resource and a task. With reference to FIGS. 4 and 5, acquisition of each stakeholder's request and generation of top-level request will be described.

FIG. 4 is a diagram showing an example of stakeholder information. As shown in FIG. 4, the stakeholder information 420 is information registered in advance in the data storage unit 320, and the “department”, the “department”, the “request”, and the “provable element” are associated with each other. Information. As mentioned above, the "department" is an example of the person in charge of the activity.

"Department" is an example of a sub-charger, which is a unit smaller than the person in charge. Therefore, another sub-in charge may be used instead of the "department". In the example shown in FIG. 4, the "operation department" belongs to the "maintenance department", the "repair department", and the "call center department".

A "request" is a request of each department and belongs to the corresponding "department". In the example shown in FIG. 4, "requirement A" is associated with "design department", "requirement B" is associated with "production department", and "requirement C" is associated with "operation department". , "Request D" and "Request E" are associated with each other. The "request" can also be associated with a "department" belonging to the "department". For example, "request C" is associated with "maintenance department", "request D" is associated with "repair department", and "request E" is associated with "call center department".

The "provable element" is an element that can be provided by each department and belongs to the corresponding "department". In the example shown in FIG. 4, "task 2" is associated with "design department" as "provable element", and "task 1" corresponds to "production department" as "provable element". It is attached, and "task 3" and "resource 1" are associated with "operation department" as "provable elements". Similar to the "request", the "provable element" can be associated with the "department" belonging to the "department".

FIG. 5 is a diagram showing an example of element correspondence information. As shown in FIG. 5, the element correspondence information 430 is information registered in advance in the data storage unit 320, and is information in which an "element" and a "dependent element" are associated with each other. The "element" depends on the corresponding "dependent element". As an example, "request A" depends on "request A1", "request A2", "request A3" and "resource 3". That is, "request A" depends on "request A1", "request A2", "request A3", and "resource 3". In order for "Requirement A" to be realized, it is necessary that "Requirement A1", "Requirement A2" and "Requirement A3" are realized and "Resource 3" is provided.

As described above, when each of the "design department", "production department" and "operation department" is extracted as a stakeholder by the stakeholder extraction unit 110, the request acquisition unit 120 will perform the element correspondence information 430 to the "design department". Acquire "Requirement A" corresponding to "", acquire "Requirement B" corresponding to "Production Department", and acquire "Requirement C", "Requirement D" and "Requirement E" corresponding to "Operation Department". do.

Here, the dependency extraction unit 130 may use the request corresponding to the department as the highest-level request as it is. For example, since the dependency extraction unit 130 acquires only one "requirement A" as a request corresponding to the "design department", the "requirement A" corresponding to the "design department" is used as it is in the "design department". It may be a higher-level request. Similarly, since the dependency extraction unit 130 acquires only one "request B" as a request corresponding to the "production department", the "element B" corresponding to the "production department" is used as it is in the "production department". It may be the highest request.

On the other hand, as the requirements corresponding to the "operation department", three requirements "request C", "request D" and "request E" are acquired. At this time, the dependency extraction unit 130 may determine whether or not the three requests "request C", "request D", and "request E" can be aggregated into one request. Here, the determination as to whether or not the three requests can be aggregated may be performed in any way. As an example, whether the dependency extraction unit 130 can aggregate three requests depending on whether or not the "department" in charge is the same in "request C", "request D", and "request E". You may decide whether or not.

It is assumed that the dependency extraction unit 130 determines that the three requests "request C", "request D", and "request E" can be integrated into one request. In such a case, it is desirable that the dependency extraction unit 130 aggregates the three requests into one request and makes the aggregated request the highest-level request. In this way, by restricting the requirements of one stakeholder to one, only the elements on which one request depends are searched in the subsequent dependency extraction S15, so that the search range can be reduced. The effect of becoming can be enjoyed.

There is no limitation on what kind of requirements the three requirements are aggregated into. If there is a request that depends on the three requests, the dependency extraction unit 130 may aggregate the three requests into the request (for example, in the element correspondence information 430, "request C", "request D" and If there is one request as an "element" having "request E" as a "dependent element", the dependency extraction unit 130 may aggregate the three requests into the request). Although the case where three requests are aggregated has been described here as an example, two requests or four or more requests can be aggregated in the same manner.

In the example shown in FIG. 4, the "departments" corresponding to the three requirements "request C", "request D" and "request E" are different. In such an example, the dependency extraction unit 130 determines that the three requirements "request C", "request D", and "request E" cannot be aggregated into one request, and the stakeholder extraction unit 110 again determines. Stakeholders are disassembled in S12. More specifically, the stakeholder extraction unit 110 refers to the stakeholder "operation department" to which the three requests belong, the "maintenance department" corresponding to "request C", the "repair department" corresponding to "request D", and the "request". Disassemble into "call center departments" corresponding to "E". At this time, the dependency extraction unit 130 sets each of "request C", "request D", and "request E" as the highest-level request.

(Dependency extraction S15)
Next, the Dependency Extraction Unit 130 applies the i * framework to the top-level requirements of each stakeholder, and organizes what kind of interaction between the stakeholders realizes the requirements of each stakeholder. (Model).

FIG. 6 is a diagram showing the components of the i * framework. Dependency extraction unit 130 sets the beneficiary (“depender” shown in FIG. 6) in the dependency relationship between stakeholders as the highest-level request, and each stakeholder (shown in FIG. 6) in order to realize the highest-level request. The element (“stakeholder” shown in FIG. 6) given by the “stakeholder”) is extracted. The element includes at least one of a state desired by the dependant (a request of the dependator, ie, a goal or a soft goal), an activity (task) performed by the dependant, a physical entity and an information entity (resource).

By limiting the dependencies in this way, the search range of the dependencies is limited, and while preventing the omission of the dependencies, it is possible to sequentially extract from the dependencies that greatly contribute to the demands that the stakeholders should realize.

More specifically, the dependency extraction unit 130 acquires from the data storage unit 320 the elements on which the top-level request of each stakeholder depends and the elements that can be provided by each stakeholder. Stakeholders are assumed to be the "design department," "production department," and "maintenance department," "repair department," and "call center department" after the "operation department" has been disassembled. Therefore, the dependency extraction unit 130 acquires "element A1", "element A2", "element A3" and "resource 3" from the element correspondence information 430 as the elements on which the request A of the "design department" depends. As an element that can be provided by the "design department", "task 2" is acquired from the stakeholder information 420.

Similarly, the dependency extraction unit 130 acquires "element B1" from the element correspondence information 430 as an element on which the request B of the "production department" depends, and "task 1" as an element that can be provided by the "production department". Is obtained from stakeholder information 420. Similarly, the dependency extraction unit 130 acquires "element C1" and "request C2" from the element correspondence information 430 as elements on which the element C of the "maintenance department" depends, and the element that the "maintenance department" can provide. As a result, "task 3" and "resource 1" are acquired from the stakeholder information 420.

On the other hand, the dependency extraction unit 130 acquires "element D1" and "request D2" from the element correspondence information 430 as elements on which the element D of the "repair department" depends, but the element that the "repair department" can provide. Is not obtained from stakeholder information 420 (because it is not registered in stakeholder information 420). Similarly, the dependency extraction unit 130 acquires "element E1" and "request E2" from the element correspondence information 430 as elements on which the element E of the "call center department" depends, but the "call center department" can provide the elements. The element is not obtained from stakeholder information 420 (because it is not registered in stakeholder information 420).

In these stakeholders, the dependency extraction unit 130 detects the case where the element on which the request of the first stakeholder depends and the element that can be provided by the second stakeholder match. Then, the dependency extraction unit 130 generates (extracts) a dependency by associating the request of the first stakeholder, the element on which the request of the first stakeholder depends, and the second stakeholder. At this time, the stakeholder to which the request belongs is the first stakeholder.

When a plurality of requests are aggregated into one request, the aggregated request may be treated as the request of the first stakeholder and the dependency relationship may be extracted in the same manner. That is, when the element on which the request after aggregation depends and the element that can be provided by the second stakeholder match, the dependency extraction unit 130 determines the request after aggregation and the element on which the request after aggregation depends. , Dependencies may be generated by associating with the second stakeholder.

(First update S16 of the request model)
As described above, the request model storage unit 150 updates the information of the request model storage unit 150 according to the dependency (S16). More specifically, each stakeholder extracted by the stakeholder extraction unit 110 in S13 is already registered in the requirement model storage unit 150. Therefore, the dependency extraction unit 130 responds to each stakeholder already registered in the request model storage unit 150 by the request belonging to that stakeholder, the element on which the request depends, and the stakeholder who can provide the request. Create a request model by associating the attached dependencies.

FIG. 7 is a diagram showing an example of the requirement model after the dependency is reflected by visualizing it. In the example shown in FIG. 7, "Stakeholder A" corresponds to "Design Department", "Stakeholder B" corresponds to "Production Department", and "Stakeholder C" corresponds to "Maintenance Department" of "Operation Department". Applicable (see Fig. 4).

Referring to FIGS. 4 and 5, stakeholder A's top-level request A depends on task 1 (via request A2), and task 1 can be provided by stakeholder B. Therefore, in the example shown in FIG. 7, the dependency relationship in which the highest request A of the stakeholder A is the depender, the task 1 is the dependent, and the stakeholder B is the dependent is extracted.

Similarly, referring to FIGS. 4 and 5, stakeholder B's top-level request B depends on task 2 (via request B1), and task 2 can be provided by stakeholder A. Therefore, in the example shown in FIG. 7, the dependency relationship in which the highest request B of the stakeholder B is the depender, the task 2 is the dependent, and the stakeholder A is the dependent is extracted.

Referring to FIGS. 4 and 5, stakeholder A's top-level request A depends on task 3 (via request A1), which can be provided by stakeholder C. Therefore, in the example shown in FIG. 7, the dependency relationship in which the highest request A of the stakeholder A is the depender, the task 3 is the dependent, and the stakeholder C is the dependent is extracted.

Also, referring to FIGS. 4 and 5, stakeholder A's top-level request A depends on resource 1 (via request A2), and resource 1 can be provided by stakeholder C. Therefore, in the example shown in FIG. 7, the dependency relationship in which the highest request A of the stakeholder A is the depender, the resource 1 is the dependent, and the stakeholder C is the dependent is extracted.

As in stakeholder C, the number of dependents associated with one stakeholder is not limited to one, but may be multiple (resource 1 and task 3 in the example shown in FIG. 7).

FIG. 8 is a diagram showing an example of data configuration of the request model after the dependency is reflected. As shown in FIG. 8, the request model 441 after the dependency is reflected includes "ID", "element", "type", "affiliation", "superior element" and "depender". Will be done.

The "ID" is information for uniquely identifying an element. "Element" corresponds to the name of the element (arbitrary character string) attached to the element. The "type" is a type of element and is information for identifying any of a request (goal or soft goal), a resource, and a task. "Affiliation" is the stakeholder to which the element belongs. If an element is a requirement, "affiliation" corresponds to the stakeholder who has that element. On the other hand, if the element is dependent, the "affiliation" corresponds to the stakeholder who provides the element.

"Upper element" corresponds to the name of the upper (decomposition source) element of the element when the element is a request. The "depender" is the ID of the dependent in the dependency of the element. In an embodiment of the invention, when an element is a dependent, the depender is subject to the requirement that the element be provided. Further, in the embodiment of the present invention, when the element is a dependent, the stakeholder (that is, "affiliation") who provides the element corresponds to the dependent in the dependency. When an element is a requirement, the dependency in the dependency is the stakeholder who provides the element.

At the time of S16, since the top-level request has not been decomposed, the "element" is either a "top-level request" or a "dependence (here, a task or resource)", and is a "superior element". Is set to "None".

(Business process subdivision S17)
Subsequently, the requirements decomposition unit 140 subdivides the activities of each stakeholder in the target business. This subdivides the business process. As a method for subdividing the activities of each stakeholder, an existing method such as Business Process Model & Notation (BPMN) defined in IOS19510 can be used.

More specifically, the requirement decomposition unit 140 subdivides each element of the requirement model registered in the requirement model storage unit 150 based on the element correspondence information 430. As an example, in the element correspondence information 430, "request A1", "request A2", and "request A3" are registered as requests depending on "request A". Therefore, the requirement decomposition unit 140 acquires "requirement A1", "requirement A2", and "requirement A3" as the elements after the subdivision of "requirement A".

(Required decomposition S18)
Subsequently, the requirement decomposition unit 140 of the first stakeholder when the top-level requirement of the first stakeholder can be decomposed into the first requirement and the second requirement based on the fragmented business process. The top-level requirement is decomposed into a first requirement and a second requirement (S18). Here, any method may be made to determine whether or not the top-level requirement can be decomposed into the first requirement and the second requirement. As an example, the requirements decomposition unit 140 includes a first stakeholder's top-level requirement that depends on the first and second requirements, and an element on which the first and second requirements depend. If the factors that can be provided by the second stakeholder match, it may be determined that the top-level requirements of the first stakeholder can be decomposed into the first requirement and the second requirement.

For example, as described above, the subdivided elements of the "highest-level request A" include "request A1" and "request A2". Then, as shown in FIGS. 4 and 5, the element “task 3” on which “request A1” depends and the “task 3” that can be provided by stakeholder C match, and the element on which “request A2” depends. "Resource 1" and "Resource 1" that Stakeholder C can provide match. In such a case, the request decomposition unit 140 determines that the "highest request A" can be decomposed into "request A1" and "request A2", and "highest request A" is changed to "request A1" and "request A2". It may be disassembled into.

(Second update of request model S19)
When the top-level requirements of the first stakeholder are decomposed into the first requirement and the second requirement, returning to S15, the dependency extraction unit 130 is the first in the requirement model registered in the requirement model storage unit 150. The elements on which the first and first requirements depend on the dependency relationship between the top-level requirements of one stakeholder, the top-level requirements of the first stakeholder, and the second stakeholder. Updated to the first dependency in which and the second stakeholder are associated, and the second dependency in which the second requirement and the element on which the second requirement depends and the second stakeholder are associated. do.

For example, when the "highest level requirement A" is decomposed into "requirement A1" and "requirement A2" by the requirement decomposition unit 140, the dependency extraction unit 130 is a stakeholder in the requirement model registered in the requirement model storage unit 150. The dependency relationship in which the element "task 3" and the element "resource 1" on which the "top request A" of A and the "top request A" of stakeholder A depend and the stakeholder C are associated with each other is "request A1". , The first dependency in which the element "task 3" on which "request A1" depends and the stakeholder C, and the element "resource 1" on which "request A2" and "request A2" depend. , And update to the second dependency with which stakeholder C is associated (S19).

In this way, it can be expected that a model without omissions will be generated by sequentially updating the dependencies while sequentially decomposing the top-level request. The request model registered in the request model storage unit 150 may be appropriately output from the output unit 330. This allows the user to recognize the requirement model.

FIG. 9 is a diagram showing an example of a requirement model that reflects the updated dependency based on the requirement decomposition. In FIG. 9, the highest level requirement A of stakeholder A is decomposed into request A1 and request A2, the highest level request B of stakeholder B is decomposed into request B1, and the highest level request C of stakeholder C is decomposed into request C1 and request C2. Is represented. Along with this, the task 1, task 3, and resource 1 associated with the highest-level request A are changed so as to be associated with either request A1 or request A2. Similarly, the task 2 associated with the top-level request B is changed so as to be associated with the request B2.

FIG. 10 is a diagram showing an example of a requirement model that reflects the updated dependency based on the requirement decomposition. In the example shown in FIG. 10, the difference points from the data configuration example of the request model after the dependency relationship shown in FIG. 8 is reflected are shown in shading. The difference points are that the decomposed request is added as a record and that the item of the dependent is changed so that the dependent in the dependent can be associated with the requested after the decomposition.

FIG. 11 is a diagram showing specific examples of dependency extraction and requirement decomposition. Dependency extraction and requirement decomposition when the stakeholder is the design department and the highest requirement A is "design of a product that is hard to break" in the ATM manufacturing supply chain will be described.

Task 4 "Field data feedback", Task 5 "Field reproduction", Task 2 "Repeat test", Task 1 "Use pseudo deteriorated parts" are required to "realize the design of a product that is hard to break". Therefore, resource 2 "part life data" generated by repeated tests and resource 1 "pseudo-deterioration data" using pseudo-deteriorated parts are required. These four tasks and two resources are dependent on the top-level request.

Further, among the above-mentioned dependents, the task 2 "repetition test" is carried out based on the request A1 "I want to know the broken parts" in the highest requirement A "design of a product that is hard to break". Further, task 1 "use pseudo deteriorated parts" is carried out based on request A2 "I want to know the cause of breakage". By subdividing the top-level requirements based on the dependency in this way, the requirements can be decomposed.
Figure 9 shows the model of the i * framework to which the dependency extraction and requirement decomposition in the design department are applied.

The requirement decomposition unit 140 may decompose the decomposable requirement as long as the first requirement and the second requirement include the decomposable requirement. At this time, every time the decomposable request is decomposed, the dependency extraction unit 130 updates the decomposable request to the decomposed request, and after decomposing the element on which the decomposable request depends. It may be updated to the element on which the request of is dependent. Such recursive request decomposition may make it easier to realize multiple post-decomposition requirements than a single pre-decomposition request.

(Pattern search S20)
In the following, it is mainly assumed that the analysis department possesses the technology for utilizing resources, and by providing the technology possessed by the analysis department, a requirement model that enables efficient implementation is generated. However, the department that provides the technology is not limited to the analysis department. First, resource technology information in which resources and technologies are associated is registered in advance in the data storage unit 320.

FIG. 12 is a diagram showing an example of resource technology information in which "resources" and "technology owned by an analysis department using the relevant resources" are associated with each other. As an example, in the resource technology information 450, it is registered that the analysis department possesses the "time series prediction technology" as a technology for using the resource "parts procurement data". If the resource technology information 450 is used, the technology for utilizing the resource can be provided by the analysis department.

The pattern search unit 220 searches the request model stored in the request model storage unit 150 for a request model that matches the reference pattern registered in advance in the reference pattern storage unit 210 (S20). As an example, when the first dependency and the second dependency are extracted by the dependency extraction unit 130, whether or not the first dependency and the second dependency match the reference pattern is determined. to decide.

FIG. 13 is a diagram showing a first example of the reference pattern. FIG. 14 is a diagram showing a second example of the reference pattern. FIG. 15 is a diagram showing a third example of the reference pattern. In each of the examples shown in FIGS. 13 to 15, "*" indicates an arbitrary value.

In the reference pattern 461 according to the first example shown in FIG. 13, two stakeholders have a “goal” and a “resource”, respectively, and the “resource” of one stakeholder is the request (goal) of the other stakeholder. It shows that it is a stakeholder. That is, in the first example shown in FIG. 13, in the reference pattern, the "element" in the first dependency is the resource A, and the "element" in the second dependency is the resource B. Yes, the stakeholder B to which "request B" of the first dependency belongs and the stakeholder B who can provide the resource B of the second dependency match, and the stakeholder B of the second dependency has. It is a condition that the stakeholder A to which the "request A" belongs and the stakeholder A who can provide the resource A in the first dependency match.

The reference pattern 462 according to the second example shown in FIG. 14 indicates that the plurality of stakeholders are "dependences" for their own "goals". That is, in the reference pattern according to the second example shown in FIG. 14, the "element" in the first dependency is the resource A, and the "element" in the second dependency is the resource B. Yes, the stakeholder A to which the "request" of the first dependency belongs and the stakeholder A who can provide the resource A of the first dependency match, and the "request" of the second dependency is ". It is a condition that the stakeholder B to which the "request" belongs and the stakeholder B who can provide the resource B in the second dependency match.

In the reference pattern 463 according to the third example shown in FIG. 15, a stakeholder has a “goal” and a plurality of “resources”, and the plurality of “resources” are the same “goal” dependency. Represents that. That is, in the reference pattern according to the third example shown in FIG. 15, the "element" in the first dependency is the resource A1, and the "element" in the second dependency is the resource A2. Yes, stakeholder A to which the "request" of the first dependency belongs, stakeholder A to which the "request" of the second dependency belongs, and the first resource of the first dependency. It is a condition that the stakeholder A who can provide the second dependency and the stakeholder A who can provide the second resource of the second dependency match.

(Pattern application S21)
Subsequently, the pattern application unit 230 generates a requirement model (efficient requirement model) that enables efficient implementation by applying a design pattern to the requirement model stored in the requirement model storage unit 150. (S21). More specifically, if the first dependency and the second dependency match the reference pattern, then the element of the first dependency and the element of the second dependency have a third stakeholder. Associates the elements that can be provided.

In the following, it is assumed that the third stakeholder is the analysis department, and the element that the third stakeholder can provide is a resource. It is mainly assumed that the analysis department possesses the technology to utilize the resources, and by providing the technology possessed by the analysis department to other departments, a requirement model that enables efficient implementation is generated. .. However, the department that provides the technology is not limited to the analysis department.

FIG. 16 is a diagram showing a model of the i * framework representation to which the Mediator pattern of the design pattern is applied to the first example of the reference pattern (FIG. 13). FIG. 17 is a diagram showing a model of the i * framework representation to which the Template Method pattern of the design pattern is applied to the second example (FIG. 14) of the reference pattern. FIG. 18 is a diagram showing a model of the i * framework representation to which the Observer pattern of the design pattern is applied to the third example of the reference pattern (FIG. 15).

In FIGS. 16 to 18, what is described as "technology" indicates the task required to realize each requirement (for example, an algorithm that gives a solution based on data such as a machine learning method or a statistical analysis method). ing. Specifically, in the examples shown in FIGS. 16 to 18, the stakeholders described as "Mediator", "Template Method", and "Observer" are assumed to be "data analysis departments" and have a request. Select and provide appropriate technology (technology possessed by the "resources" necessary to realize the stakeholder who has the demand) to the stakeholders.

In the Mediator pattern shown in FIG. 16, a new stakeholder (Mediator) that mediates the interaction between stakeholders can be newly given, and the demands (goals) of both parties can be approached efficiently. From the perspectives of stakeholders A and B shown in FIG. 16, instead of providing their own "resources" to others, it becomes a model that receives the "resources" of others that contribute to the realization of their own demands (goals). ing. In addition, from the perspective of Mediator, by reusing "resources" that are factors for fulfilling the demands of each stakeholder from the other stakeholder, we aim to reduce the time and effort required to generate new resources (that is, acquire data).

In the Template Method pattern shown in FIG. 17, the processing required to realize each requirement is entrusted to the abstract technology of a new stakeholder (Tempate Method), and the processing can be changed by changing the implementation.

The Observer pattern shown in FIG. 18 is a model for monitoring changes in a plurality of resources using a common technique, and is expected to be applied to an abnormality detection technique.

FIG. 19 is a diagram showing an example of applying the Mediator pattern to the design department and the maintenance department in the ATM manufacturing supply chain. More specifically, in the example shown in FIG. 19, the elements that can be provided by the analysis department are the time series prediction technology applicable to the resource "part life data" and the "descriptive description" applicable to the resource "maintenance performance data". Includes "statistical technology".

In response to the request of the design department "I want to know the cause of the break", it was necessary to carry out "field reproduction" in my own department in the past, but I received "maintenance performance data" from the maintenance department and applied "descriptive statistical technology". By using and analyzing, it is possible to realize a design based on actual field data. On the other hand, in response to the maintenance department's request "I want to know the signs of breakage", by applying the "time series prediction technology" to the "part life data" of the design department, state-based maintenance using the specifications of individual parts is realized. can.

FIG. 20 is a diagram showing an example in which the Template Method pattern is applied to the design department, the production department, and the procurement department in the ATM manufacturing supply chain. In the example shown in FIG. 20, the elements that can be provided by the analysis department include time series forecasting technology applicable to each of the resource “parts procurement data”, the resource “requested number of parts data”, and the resource “production performance data”. .. In this example, an abstract time-series prediction technology is prepared as a technology used by the analysis department, and the requirements of each department are realized by changing the data used by the time-series prediction technology. For example, the life forecast is calculated by applying the "time series forecasting technology" to the "parts procurement data", and the production volume forecast is calculated by applying the "time series forecasting technology" to the "requested number of parts data". It can be expected that the demand forecast will be calculated efficiently by applying the "time series technology" to the "production record data".

FIG. 21 is a diagram showing an example in which the Observer pattern is applied to the maintenance department in the ATM manufacturing supply chain. In the example shown in FIG. 21, the elements that the analysis department can provide include anomaly detection techniques applicable to the resource "part life data", the resource "deterioration information data" and the resource "returned product data". In this example, the state change alert in the abnormality detection is expressed as an Observer pattern. In this case, the anomaly detection technology that arranges changes in a plurality of resources as observers aggregates them as multidimensional variables, which enables more efficient detection than when an anomaly detection model is created for each resource.

(Efficient model registration S22)
Subsequently, the pattern application unit 230 is added with the technology and the analysis department that provides the technology for the resource of the requirement model accumulated in the requirement model storage unit 150 (S22). In this way, the requirement model to which the technology and the analysis department are added is registered in the efficient requirement model storage unit 240 as an efficient requirement model by the pattern application unit 230. The efficient request model registered in the efficient request model storage unit 240 may be appropriately output from the output unit 330. This allows the user to recognize an efficient requirements model.

The operation example of the business process management apparatus 10 according to the embodiment of the present invention has been described above.

(2. Hardware configuration example)
Subsequently, a hardware configuration example of the business process management device 10 according to the embodiment of the present invention will be described.

Hereinafter, as a hardware configuration example of the business process management apparatus 10 according to the embodiment of the present invention, a hardware configuration example of the information processing apparatus 900 will be described. The hardware configuration example of the information processing device 900 described below is only an example of the hardware configuration of the business process management device 10. Therefore, as for the hardware configuration of the business process management device 10, an unnecessary configuration may be deleted from the hardware configuration of the information processing apparatus 900 described below, or a new configuration may be added.

FIG. 22 is a diagram showing a hardware configuration of an information processing apparatus 900 as an example of the business process management apparatus 10 according to the embodiment of the present invention. The information processing device 900 includes a CPU (Central Processing Unit) 901, a ROM (Read Only Memory) 902, a RAM (Random Access Memory) 903, a host bus 904, a bridge 905, an external bus 906, and an interface 907. , An input device 908, an output device 909, a storage device 910, and a communication device 911.

The CPU 901 functions as an arithmetic processing device and a control device, and controls the overall operation in the information processing device 900 according to various programs. Further, the CPU 901 may be a microprocessor. The ROM 902 stores programs, calculation parameters, and the like used by the CPU 901. The RAM 903 temporarily stores a program used in the execution of the CPU 901, parameters that appropriately change in the execution, and the like. These are connected to each other by a host bus 904 composed of a CPU bus or the like.

The host bus 904 is connected to an external bus 906 such as a PCI (Peripheral Component Interconnect / Interface) bus via a bridge 905. It is not always necessary to separately configure the host bus 904, the bridge 905, and the external bus 906, and these functions may be implemented in one bus.

The input device 908 includes input means for the user to input information such as a mouse, keyboard, touch panel, buttons, microphones, switches and levers, and an input control circuit that generates an input signal based on the input by the user and outputs the input signal to the CPU 901. And so on. By operating the input device 908, the user who operates the information processing device 900 can input various data to the information processing device 900 and instruct the processing operation.

The output device 909 includes, for example, a CRT (Cathode Ray Tube) display device, a liquid crystal display (LCD) device, an OLED (Organic Light Emitting Diode) device, a display device such as a lamp, and an audio output device such as a speaker.

The storage device 910 is a device for storing data. The storage device 910 may include a storage medium, a recording device for recording data on the storage medium, a reading device for reading data from the storage medium, a deleting device for deleting data recorded on the storage medium, and the like. The storage device 910 is composed of, for example, an HDD (Hard Disk Drive). The storage device 910 drives a hard disk and stores programs and various data executed by the CPU 901.

The communication device 911 is a communication interface composed of, for example, a communication device for connecting to a network. Further, the communication device 911 may support either wireless communication or wired communication.

The hardware configuration example of the business process management apparatus 10 according to the embodiment of the present invention has been described above.

(3. Summary)
As described above, according to the embodiment of the present invention, it is possible to effectively organize what kind of interaction between stakeholders realizes the demands of stakeholders. For example, according to the embodiment of the present invention, the requirements and owned resources of a plurality of stakeholders can be extracted and centrally managed by modeling by the i * framework. In addition, representing the requirements of multiple stakeholders and the resources they own in a diagram is useful for taking a bird's-eye view and considering the interaction of the requirements between each stakeholder.

Further, according to the embodiment of the present invention, a model based on the i * framework can be systematically generated, and the stakeholder's request is automatically extracted without personal judgment. Stakeholder requirements can be efficiently extracted. In addition, the possibility of omission from the model based on the i * framework can be reduced. Furthermore, a method of applying a design pattern to a model represented by the i * framework may provide a method of efficiently addressing complex requirements.

Although the preferred embodiments of the present invention have been described in detail with reference to the accompanying drawings, the present invention is not limited to these examples. It is clear that a person having ordinary knowledge in the field of technology to which the present invention belongs can come up with various modifications or modifications within the scope of the technical ideas described in the claims. , These are also naturally understood to belong to the technical scope of the present invention.

10 Business process management device 100 Request model generation block 110 Stakeholder extraction unit 120 Request acquisition unit 130 Dependency extraction unit 140 Request decomposition unit 150 Request model storage unit 200 Efficient request model generation block 210 Reference pattern storage unit 220 Pattern search unit 230 Pattern Applicable unit 240 Efficient requirement model storage unit 310 Input unit 320 Data storage unit 330 Output unit

Claims (16)

Based on the business process including the responsible entity for each of the first activity and the second activity, the responsible entity for the first activity is extracted as the first stakeholder, and the responsible entity for the second activity is the first. Stakeholder extraction department to extract as 2 stakeholders,
The request acquisition department that acquires the requirements of the first stakeholder,
When the element on which the request of the first stakeholder depends and the element that can be provided by the second stakeholder match, the element on which the request of the first stakeholder and the request of the first stakeholder depend. Dependency extraction unit that extracts the dependency associated with the second stakeholder,
A business process management device. The business process management device is
A requirement decomposition unit that decomposes the request of the first stakeholder into the first requirement and the second requirement when the requirement of the first stakeholder can be decomposed into the first requirement and the second requirement. Equipped with
The dependency extraction unit includes a first dependency in which the first request, an element on which the first request depends, and the second stakeholder are associated with each other, and the second request and the second. The dependency is updated to the second dependency in which the element on which the request of 2 depends and the second stakeholder are associated with each other.
The business process management device according to claim 1. The requirement decomposition unit includes the elements to which the first requirement and the second requirement depend when the requirement of the first stakeholder depends on the first requirement and the second requirement. If the factors that can be provided by the second stakeholder match, it is determined that the request of the first stakeholder can be decomposed into the first request and the second request.
The business process management device according to claim 2. The requirement decomposition unit decomposes the decomposable requirement as long as the first requirement and the second requirement include the decomposable requirement.
Each time the decomposable requirement is decomposed, the dependency extraction unit updates the decomposable requirement to the decomposed requirement, and decomposes the element on which the decomposable requirement depends. Update to the element that the later request depends on,
The business process management device according to claim 2 or 3. The dependency extraction unit is
When the requirements of the first stakeholder include a third requirement and a fourth requirement that can be aggregated into one requirement.
After the aggregation, the third requirement and the fourth requirement are aggregated into one requirement, and when the element on which the aggregated requirement depends and the element that can be provided by the second stakeholder match, the aggregation is performed. Extract the dependency relationship in which the element on which the request of the above and the request after the aggregation depend and the second stakeholder are associated with each other.
The business process management device according to any one of claims 1 to 4. The dependency extraction unit is
The third requirement and the fourth requirement can be aggregated depending on whether or not the sub-responsible entity, which is a unit smaller than the responsible entity, is the same in the third requirement and the fourth requirement. Judging whether or not it is,
The business process management device according to claim 5. The stakeholder extraction department
When the requirements of the first stakeholder include a third requirement and a fourth requirement that cannot be aggregated into one requirement, the first stakeholder is referred to the sub-responsible entity of the third requirement and the fourth requirement. Disassembled into sub-chargers
The dependency extraction unit is
When the element on which the third requirement depends and the element that can be provided by the second stakeholder match, the element on which the third requirement, the third requirement depends, and the second stakeholder are determined. Extract the associated dependencies,
The business process management device according to claim 6. When the third request and the fourth request can be aggregated, the dependency extraction unit converts the third request and the fourth request into the third request and the fourth request. Consolidate into one dependent request,
The business process management device according to any one of claims 5 to 7. The dependency extraction unit acquires from the storage unit the elements on which the request of the first stakeholder depends and the elements that can be provided by the second stakeholder.
The business process management device according to any one of claims 1 to 8. The elements on which the first stakeholder's requirements depend include at least one of the resources, tasks and requirements.
The business process management device according to any one of claims 1 to 9. The business process management device is
When the first dependency and the second dependency are extracted by the dependency extraction unit, it is determined whether the first dependency and the second dependency match a predetermined pattern. Pattern search section and
When the first dependency and the second dependency match the pattern, a third stakeholder is assigned to the element of the first dependency and the element of the second dependency. Equipped with a pattern application unit that associates elements that can be provided by
The business process management device according to any one of claims 1 to 10. The pattern is
The element of the first dependency is the first resource, and the element of the second dependency is the second resource.
The stakeholder to which the request of the first dependency belongs and the stakeholder who can provide the second resource of the second dependency match, and the request of the second dependency is It is a condition that the stakeholder to which the stakeholder belongs and the stakeholder who can provide the first resource of the first dependency match.
The elements that can be provided by the third stakeholder include a first task applicable to the first resource and a second task applicable to the second resource.
The business process management device according to claim 11. The pattern is
The element of the first dependency is the first resource, and the element of the second dependency is the second resource.
The stakeholder to which the request of the first dependency belongs and the stakeholder who can provide the first resource of the first dependency match, and the request of the second dependency is It is a condition that the stakeholder to which the stakeholder belongs and the stakeholder who can provide the second resource of the second dependency match.
The elements that can be provided by the third stakeholder include tasks applicable to each of the first resource and the second resource.
The business process management device according to claim 11. The pattern is
The element of the first dependency is the first resource, and the element of the second dependency is the second resource.
The stakeholder to which the request of the first dependency belongs, the stakeholder to which the request of the second dependency belongs, and the stakeholder who can provide the first resource of the first dependency. And the stakeholder who can provide the second resource of the second dependency is the same.
The elements that can be provided by the third stakeholder include the task applicable to the first resource and the second resource.
The business process management device according to claim 11. Based on the business process including the responsible entity for each of the first activity and the second activity, the responsible entity for the first activity is extracted as the first stakeholder, and the responsible entity for the second activity is the first. Extracting as 2 stakeholders and
Acquiring the requirements of the first stakeholder and
When the element on which the request of the first stakeholder depends and the element that can be provided by the second stakeholder match, the element on which the request of the first stakeholder and the request of the first stakeholder depend. Extracting the dependencies associated with the second stakeholder,
A business process management method. Computer,
Based on the business process including the responsible entity for each of the first activity and the second activity, the responsible entity for the first activity is extracted as the first stakeholder, and the responsible entity for the second activity is the first. Stakeholder extraction department to extract as 2 stakeholders,
The request acquisition department that acquires the requirements of the first stakeholder,
When the element on which the request of the first stakeholder depends and the element that can be provided by the second stakeholder match, the element on which the request of the first stakeholder and the request of the first stakeholder depend. Dependency extraction unit that extracts the dependency associated with the second stakeholder,
A program that functions as a business process management device.

Images