JP5651895B2 - Axiom service design method, equipment, program - Google Patents

Description

  The present invention relates to a service design system, a service design method, and a service design program, and more particularly to a service design system, a service design method, and a service design program based on a design axiom.

  Non-Patent Document 1 proposes a basic concept of an axiomatic design (AXIOMATIC DESIGN) mainly in the field of mechanical engineering as a concept of a procedure for converting user requirements into design information. This basic concept knows customer needs, sets up problems that must be solved to meet the needs, conceptualizes solutions through integration, performs analysis to optimize solutions, and confirms design solutions, etc. For the items common to the design act, each act is expressed in a mapping relationship. Customer needs (CUSTOMER ATTRIBUTE: CA) are transcribed into functional requirements (FUNCTIONAL REQUIREMENTS: FR), FR is transcribed into design parameters (DESIGN PARAMETER: DP), and DP is transcribed into process variables (PROCESS VARIABLE: PV) ( FIG. 1).

  This basic concept confirms two axioms. Axiom 1 is called INDEPENDENCE AXIOM, and the required function (FR) is defined as the “minimum number of independent requirements” that describe the design goals, so that FR independence is always maintained. Axiom 2 is called an information axiom (INFORMATION AXIOM), and the design that has the minimum necessary information amount among the designs that satisfy the independent axiom is the best design.

  This basic concept is applied to design methods for substances, products, such as software, structures, large systems, substances and materials. However, the fact is that axiomatic design concepts have not been applied to service design.

  There exists patent document 1 as a design based on an axiom. Patent Document 1 aims to provide a UI design verification device capable of automatically verifying a UI (User Interface) behavior specification of a product expressed in a graphical notation such as UML (Unified Modeling Language). It has a statement conversion axiom and a verification axiom. Patent Document 1 is intended for UI, and is similar to Non-Patent Document 1 and is intended for substances and products, and it is difficult to verify a function expressed as a human action such as an operator. Further, Patent Document 1 verifies design information after function design using an axiom, and it is difficult to verify a design process using an axiom.

  As a service design process method, there is a method proposed in Patent Document 2. Patent Document 2 describes a design method for identifying a physical function to be provided from a service provider and a function provided by a human system such as an operator based on the behavior of a service user. This method shows a method of developing a service function in service design, and can optimize the function and its quality for the user.

JP 2006-285626 A Japanese Patent Application No. 2009-078308

Nam P. Shu, Axiomatic Design Theory for Systems, Research in Engineering Design, pp. 189-209, 1998

  In Patent Document 2, no consideration is given to optimizing a provision process of designed functions in view of resources within a service provider. Furthermore, Patent Document 2 statically evaluates design information at a specific time point, and does not describe a coping method in the case of dynamically fetching requests issued at different time points.

  Furthermore, even if the axiomatic design described in Non-Patent Document 1 is applied to service design, individual parameters such as FR, DP, and PV used in the axiomatic design concept are mapped to product functions. It was difficult to apply to the design. The reason is that human actions such as an operator are not visible functions, and the expression method is not defined, so that it is difficult to parameterize.

  On the other hand, a problem in the development of new services is that it is often difficult to perform the design and implementation phase development processes on schedule. The reason is that, at the time of new service development, the current service is usually provided and coexists with the current service provision. This is because new service development is subject to requests and restrictions from stakeholders, processes and resources related to the current service.

  In consideration of the above points, the present invention defines a time process from a user request to designing and providing a service function step by step, that is, dynamically in general service development. By formalizing constraints, we propose a service development method that performs efficiently in the design process.

  In other words, the basic concept of the present invention is that, in the development of new services, the design process from user requirements to functional design and functional implementation is subdivided as standard in the process common to service development, and the determination of design parameters and design constraints is performed. Is to provide a system that facilitates transition between service design processes and facilitates management of the service design process.

  The conceptual configuration of the present invention will be described with reference to FIG. The service design stage, that is, the phase (1) captures the user's request and the service provider's request, and (2) designs the function that the role in the service provider plays in realizing the request. For this reason, the present invention recognizes a service provider as an internal organization. In this case, as shown in the upper part of FIG. 2, the organization within the service provider can conceptually be recognized as the organization domain 1 that meets the requests of the user and the service provider, and this organization domain 1 is The personal domain 2, the role domain 3, and the resource domain 4 can be subdivided, and the functions according to each domain are made to correspond to the requests of users and service providers, and designed functions can be obtained. Further, (3) the designed function is implemented using material resources and human resources (lower part of FIG. 2). When transitioning from (1) to (2), the overall organizational goal cannot be expanded to individual roles because there is an actual business, and there are restrictions (that is, conflicts or contradictions in individuals or role domains 2 or 3). Occurs). In addition, when transitioning to (2) to (3), each design information has funds and resource amounts used in the actual business, so that necessary and sufficient resources cannot always be secured and restrictions occur (that is, in the resource domain). Collisions and inconsistencies).

  That is, the concept of the present invention is to set a design domain index related to a service as a requirement, associate a service function and a service resource according to the requirement, and determine whether there is a constraint related to the resource.

  More specifically, function requirement items, design parameters, resource items, etc. related to the service are defined in each phase of the service development process, and are defined in the previous phase when moving to the next phase. The step of transferring the item to the item specified in the next phase is repeated. Although this method uses an axiomatic design method, the present invention defines the non-transferable element as a constraint that can occur in the design when an untransferable element that occurs during the transfer process is encountered. It is characterized in that it defines an index group and a determination mechanism. As described above, the present invention is different from Patent Document 2 in that a dynamic service design method along the time axis is realized by performing sequential transfer.

  An axiomatic service design method according to an embodiment of the present invention that realizes such a concept includes a design domain index selection stage for setting and selecting a design domain index related to a service, and a design domain index storage stage for storing the design domain index. And a design information determination stage for determining the validity of the design information using the design domain index, and a design constraint display stage for displaying a design constraint when the validity of the design information is not recognized. An axiomatic service design method characterized by

  An axiomatic service design apparatus according to another aspect of the present invention includes a selection unit that selects a design domain index related to a service, a storage unit that stores a design domain index, a design information determination unit, and a design constraint display unit. And consist of

  An axiomatic service design program, which is still another aspect of the present invention, causes a computer to operate as a design domain index selection unit, a design domain index storage unit, a design information determination unit, and a design constraint display unit.

  The first effect is that the service design act becomes standard and mechanical service production becomes possible.

  The reason is that the service design act is specified to be decomposed into requirements, service functions for realizing the requests, and resources for realizing the functions, and the respective items are related to each other. This is also because the design constraints and design parameter vectors can formally grasp design constraints.

  The second effect is that concurrent engineering in service development is possible, and it is possible to determine whether to start production examination at the design stage.

Product design uses existing process variables (PV) when existing processes must be used to minimize capital investment in new equipment, so when selecting design parameters (DP) They act as constraints. In product development, product design and process design must be considered simultaneously, which is called concurrent engineering. in this case,
Both the product design indicated by {FR} = [A] {DP} and the process design indicated by {DP} = [B] {PV} must satisfy the independent axiom.

  At this time, the condition for satisfying the independence axiom is that the product of the matrix [C] = [A] [B] is diagonal or triangular.

  The reason why the second effect can be obtained is that the feasibility of concurrent engineering can be determined in the same manner as the product development. In other words, if a diagonal or triangular matrix [C] is obtained, concurrent engineering is possible in service development.

It is a figure which shows a design area. It is a figure which shows an axiomatic service design area. It is a figure which shows an axiomatic service design apparatus. It is a figure which shows an example of the component of an organization domain parameter | index. It is a figure which shows an example of the component of a role domain parameter | index. It is a figure which shows an example of the component of a resource domain parameter | index. It is a figure which shows an example of a design matrix. It is a figure which shows an example of a design parameter vector. 5 is a flowchart for explaining the operation of the axiomatic service design apparatus 100. It is a figure which shows an example of a structure of an education service. It is a figure which shows an example of the design matrix of an education service. It is a figure which shows an example of the design parameter vector of an education service.

  An axiomatic service design apparatus 100 according to an embodiment of the present invention will be described with reference to FIGS. 3, 4, 5, 6, 7, and 8.

  The axiomatic service design apparatus 100 shown in FIG. 3 includes a service design domain index 110, a domain information editing unit 120, a domain information storage unit 130, a design information determination unit 140, and a design constraint display unit 150.

  The illustrated service design domain index 110 includes an organization domain index 111, a role domain index 112, and a resource domain index 113. In terms of hardware, the organization domain index 111, the role domain index 112, and the resource domain A memory for storing the index 113 is used. The domain information editing unit 120 and the design information determination unit 140 may be software executed by the CPU or may be configured by a hardware circuit. Further, the domain information storage unit 130 is configured by a main memory, and the design constraint display unit 150 is configured by a display device.

  The illustrated design information determination unit 140 includes a design matrix management unit 141 and a design parameter vector management unit 142.

  The organization domain index 111 is a request item of a service provider's business department or service provider. FIG. 4 shows an example of the organization domain index 111. The organization domain index 111 includes, as elements, requirements regarding functions and quality that the user expects from the service provider, and requirements within the service provider such as sales and employees. That is, the organization domain index 111 is obtained by quantifying the requirement items of the service department and service provider.

  The role domain index 112 is a request item of a small organization in the service provider that executes the request of the organization domain in order to achieve the organization domain index 111. This small organization plays a shared role such as a delivery department or an operator department. FIG. 5 shows an example of the role domain index 112. The role domain indicator 112 includes, as elements, indicators that are set according to the role of the small organization, such as a production plan achievement rate and maintenance quality.

  The resource domain index 113 indicates a resource required for service development in order to achieve the role domain index 112. FIG. 6 shows an example of the resource domain index 113. The resource domain index 113 includes indices (numerical values) such as raw material costs, equipment costs, and labor force as elements.

  FIG. 7 shows a design matrix. FIG. 7 illustrates the relationship between the function requests FR1 to FR1 and the design parameters DP1 to DP9. FIG. 7 shows a case where DP corresponding to FR5 does not exist (DP5, DP8, and DP9 are 0), and shows a case where there is a design constraint. Here, the design constraint is either a function constraint or a resource constraint.

  FIG. 8 shows design parameter vectors in the case where knowledge, process, and management are respectively associated with x, y, and z axes of three-dimensional coordinates. In FIG. 8, a difference between an ideal design resource (organizational goal vector) and an actual resource determined by three role goal vectors is a vector shift, and the shift indicates the degree of restriction.

  Next, the operation of the axiomatic service design apparatus 100 shown in FIG. 3 will be described. Here, one embodiment of the present invention will be described with reference to FIG. The organization domain is described in the domain information editing unit 120 using the organization domain index 111 (step S111). This stage is a design domain index selection stage for selecting the service design domain index 110, and the domain information editing unit 120 constitutes a design domain index selection unit.

  Next, the role domain is described in the domain information editing unit 120 using the role domain index 112 (step S112). These pieces of information are stored in the domain information storage unit 130. This accumulation stage is a design domain index storage stage, and the domain information storage unit 130 constitutes a design domain index storage unit.

  The design information determination unit 140 reads the information stored in the domain information storage unit 130, creates a design matrix, and determines the validity of the design using the design matrix (step S113). Thus, the design information determination unit 140 executes the design information determination stage.

  If it is determined in the design information determination stage that there is interference design, the process returns to step S111 and the design is reviewed so that the interference design is reduced. Similarly, when it is determined that there is a redundant design, the process returns to step S111 and the design is reviewed so that the interference design is reduced. Here, as shown in FIG. 7, DP items on the horizontal axis that are not in correspondence with the FR on the vertical axis of the design matrix are defined as function constraints. The function constraint is displayed on the design constraint display unit 150.

  When it is determined that there is no interference design, the design information determination unit 140 describes the currently owned role domain (AsIs role domain) corresponding to the role domain description designed in step S112 (step S121). Next, the items of the organization domain and the role domain are compared with the design matrix, and the function restriction is extracted (step S122). At this time, the design parameter vector of the design parameter vector management unit 142 is used to compare the attribute value amounts of the items of the role domain designed in step S112 and the current role domain described in step S121, and determine the difference. You may extract in detail.

  In addition, the design information determination unit 140 describes a resource domain corresponding to the role domain in a process independent of step S121 (step S131). Further, similarly to step S121, the resource domain (AsIs resource domain) that is currently held is described (step S132). Next, using the design matrix of the design matrix management unit 141, the role domain and resource domain items are compared to extract resource constraints (step S133). At this time, the design parameter vector may be used to compare the attribute value amount of the item of the resource domain designed in step S131 and the current resource domain described in step S132, and the difference may be compared in detail ( Step S133). A quasi-independent / independent design decision is made using the design matrix used in steps S122 and S133 (step S141). In the case of quasi-independent / independent design, resource preparation may be started in parallel with the detailed design of the function.

  Next, an example based on the first embodiment will be described more specifically with reference to FIGS. 10, 11, and 12.

  FIG. 10 shows the relationship of stakeholders when an e-learning service provider provides a service to a user company. The relationship between the service provider (for example, the system vendor in FIG. 9) and the service consumer (for example, the client company) is an educational content creator, a learning system operator, an educational course planner, an educational course administrator, It is broken down into stakeholder relationships such as personnel education personnel and students. Actions provided by the human system that constitutes the service are also treated as functions, so that the requests (FR) for the services from these stakeholders, the functions (DP) that realize the requests, and the process variables (PV) that realize the functions Are arranged as shown in FIG.

  Specifically, in the case of the example shown in FIG. 10, the service request from the stakeholder is a course organization request FR1, a system operation design request FR2, a component creation request FR3, an E-learning content development request FR4, a course notification. The request is divided into a request FR5, a learning progress confirmation request FR6, a student support request FR7, a report submission request FR8, and a course evaluation request FR9. Of these, the course organization request, which is a service request indicated by FR1, is subdivided into a course proposal creation request FR11 and a group training organization request FR12. The system operation design request FR2 is subdivided into a system safety ensuring request FR21, a system support request FR22, and an operation role determination request FR23. Further, the E-learning content development request FR4 is a logical and physical design request FR41. And an upload request FR42 for uploading content to the server.

  Further, the learning progress confirmation request FR6 is divided into a learning state management request FR61 and a learning state report request FR62, and a report submission request FR8 is divided into a completion state report request FR81 and a questionnaire collection request FR82. The course evaluation request FR9 is divided into an objective achievement evaluation request FR91 and a reflection request FR92 that reflects a user request for the course.

  FIG. 11 describes the functions DP11 to DP92 that realize the above-described requests FR11 to FR92. Further, process variables (PV) PV11 to PV92 that realize the functions DP11 to DP92, that is, the resource capacity and the like are defined. It has been.

  In FIG. 12, the correspondence between each item of FR and PV is evaluated using a design matrix. In the illustrated design matrix, it can be determined that the corresponding portions of FR and PV indicated by x are on a diagonal line and the independence is maintained. That is, FIG. 12 shows the result of associating, that is, associating, indices between domains.

  When the attributes of each PV are further compared, the PV attribute expected from the FR and the PV attribute of the real resource can be compared using a vector, and the degree of deviation can be quantified in detail.

  According to the present invention, it is possible to formally extract function restrictions, and thus it is possible to determine a quality degradation factor that occurs in a service development process when a service provider develops a new service. In addition, since the resource constraints can be extracted formally, the service designer can consider the service operation resources currently provided when developing a new service.

100 Axiom Service Design Device 110 Service Design Domain Index 111 Organization Domain Index 112 Role Domain Index 113 Resource Domain Index 120 Domain Information Editing Unit 130 Domain Information Storage Unit 140 Design Information Determination Unit 141 Design Matrix Management Unit 142 Design Parameter Vector Management Unit 150 Design constraint display

Claims (10)

Select the required items related services to be designed, and storing the domain information storage unit sets the design domain indices linked resources for human resources and costs required to the request item, the request item A process / determination step of performing a process of creating the human resource and the resource design matrix corresponding to the request item, and determining whether the human resource and the resource do not interfere with each other; and An axiomatic service design method comprising: a design constraint display step for displaying a design constraint when it occurs, and designing the service using a computer . 2. The axiomatic service design method according to claim 1, wherein the design domain index includes an organization domain index and a role domain index as the human resource, and includes a resource domain index including a raw material cost as the resource . 2. The axiomatic service design method according to claim 1 , further comprising the step of: extracting an item as the design constraint from the created design matrix and determining the validity of the design. A domain information storage unit for storing a request item related to a service to be designed, a design domain index that associates resources related to human resources and expenses necessary for the request item, and the request item is selected, and the request item is selected. A process / determination unit that determines whether or not interference occurs in the human resource and the resource while performing the process of creating the corresponding human resource and the design matrix of the resource, and when the interference occurs, An axiomatic service design apparatus comprising: a design constraint display unit that displays design constraints; and designing the service using a computer. 5. The axiom service design apparatus according to claim 4, wherein the design domain index includes an organization domain index and a role domain index as the human resources, and includes a resource domain index including a raw material cost as the resources . 5. The axiomatic service design apparatus according to claim 4, wherein the processing / determination unit extracts an item serving as the design constraint from the created design matrix, and determines the validity of the design. Select the required items related services to be designed, and storing the domain information storage unit sets the design domain indices linked resources for human resources and costs required to the request item, the request item A process / determination step of performing a process of creating the human resource and the resource design matrix corresponding to the request item, and determining whether the human resource and the resource do not interfere with each other; and An axiomatic service design program characterized by causing a computer to execute a design constraint display stage for displaying a design constraint when it occurs . 8. The axiomatic service design program according to claim 7, wherein the design domain index includes an organization domain index and a role domain index as the human resources, and includes a resource domain index including raw material costs as the resources. 9. The axiomatic service according to claim 8, wherein in the processing / determination step, an item that becomes the design constraint is extracted from the created design matrix and the validity of the design is determined by a computer. Design program. In the processing / determination step, a matrix between a function request for the design domain and a process variable for the function request is created as the design matrix, and it is determined whether the matrix is a diagonal matrix or a triangular matrix. 10. The axiomatic service design program according to claim 9, wherein the computer determines whether the design is interference design, and if the process variable corresponding to the function request for the design domain is not in a correspondence relationship, it is determined as a function restriction. .

Images