Schedule device, scheduling method, and program

Abstract

To provide a schedule device capable of planning a maintenance plan corresponding to continuous use of a computer system in which contract of a work system is also taken into consideration.SOLUTION: A schedule device comprises: contract monitoring means which starts before termination of contract of a work system, based on contract information related to the work system which becomes a maintenance plan object, and receives setting of a target day on which continuation of operation of the work system is scheduled; individual product version-up planning means which receives the setting of a version-up day indicating a predetermined period before a support deadline, and plans version-up for each product up to the target day when performing the version-up on the version-up day before the support deadline; and risk calculation means which calculates risk values up to the target day for each product when performing the planning in a time-sequential manner, and calculates an average value of the calculated risk values for each product as a risk when performing the planning.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to a scheduling device, a scheduling method, and a program. [Background technology]

[0002] In computer systems, there is a trend toward a shift from on-premises systems, where companies procure and own their own IT (Information Technology) equipment and resources, to cloud systems, where systems built by service providers are used over the Internet. This is because cloud systems eliminate the need to procure IT resources in-house, offering benefits such as lower initial costs, less procurement time, and no asset management. Furthermore, with cloud services, users often use the system on an ongoing basis, often through a subscription contract, where users pay a regular monthly or yearly fee. Maintenance and management of these cloud-based systems is handled by the system provider. Furthermore, cloud-based systems consist of multiple hardware and software products, and system administrators must maintain and manage these multiple pieces of hardware and software.

[0003] For example, Patent Document 1 describes a technology for creating a maintenance plan for a railway vehicle that includes information on maintenance items and information on the dates on which the maintenance items will be performed, based on maintenance information, track number information, and maintenance staff information. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Publication No. 2022-181069 Summary of the Invention [Problem to be solved by the invention]

[0005] The technology described in Patent Document 1 is intended for maintenance of railway vehicles, and therefore cannot be applied to the creation of maintenance plans that also address the circumstances of computer systems, i.e., the continuous use of cloud-based computer systems by users under subscription contracts. Furthermore, while program version upgrades are also subject to maintenance management for computer systems, the technology described in Patent Document 1 does not take this into consideration.

[0006] An object of the present disclosure is to provide a scheduling device, a scheduling method, and a program that solve the above-mentioned problems. [Means for solving the problem]

[0007] A scheduling device according to one aspect of the present disclosure comprises a contract monitoring means that is started up before the contract for a business system that is the subject of a maintenance plan expires, based on contract information related to the business system, and receives the setting of a target date for the continuation of operation of the business system; an individual product upgrade planning means that receives a set upgrade date for maintenance of the business system, which indicates a predetermined time before a support deadline, and plans an upgrade for each product up to the target date based on information related to the upgrade release date and support deadline for each product that constitutes the business system, in the case where an upgrade will be performed on the upgrade date before the support deadline; and a risk calculation means that chronologically calculates risk values ​​for each product up to the target date for the case where the plan is implemented, based on information related to the risk for each product, and calculates the average of the calculated risk values ​​for each product as the risk for the case where the plan is implemented.

[0008] A scheduling method according to one aspect of the present disclosure is carried out by a computer, which executes the following steps based on contract information related to a business system that is the subject of a maintenance plan: starting the business system before the contract expires, receiving a target date for the planned continued operation of the business system; receiving a set upgrade date for maintenance of the business system that indicates a predetermined time before the support deadline; planning an upgrade for each product up to the target date based on information regarding the upgrade release date and support deadline for each product that constitutes the business system, in the case where an upgrade will be performed on the upgrade date before the support deadline; calculating a risk value for each product in chronological order up to the target date if the plan is implemented based on information regarding the risk for each product; and calculating the average of the calculated risk values ​​for each product as the risk if the plan is implemented.

[0009] A program according to one aspect of the present disclosure causes a computer to perform the following operations: based on contract information for a business system that is the subject of a maintenance plan, start the business system before the contract expires, receive a target date for the planned continued operation of the business system, receive a set upgrade date for maintenance of the business system that indicates a predetermined time before the support deadline, plan an upgrade for each product up to the target date based on information about the upgrade release date and support deadline for each product that constitutes the business system, in the case where an upgrade will be performed on the upgrade date before the support deadline, calculate a risk value for each product in chronological order up to the target date if the plan is implemented based on information about the risk for each product, and calculate the average of the calculated risk values ​​for each product as the risk if the plan is implemented. [Effects of the Invention]

[0010] According to the above aspect, it is possible to formulate a maintenance plan that accommodates the continuous use of a computer system, taking into consideration the contract for the business system that is the computer system. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 2 is a diagram illustrating functional blocks of a scheduling device according to an embodiment of the present disclosure. [Figure 2] FIG. 10 is a diagram showing an example of a predicted upgrade timing and probability for a certain product. [Figure 3] FIG. 1 is a diagram illustrating an example of a support period for each version of a certain product. [Figure 4] FIG. 1 is a diagram showing an example of the reliability of a certain product. [Figure 5] FIG. 10 is a diagram showing an example of a product version upgrade date and a usage plan for that version. [Figure 6] FIG. 10 is a diagram showing an example of costs incurred over time when a plan drawn up for a business system is implemented. [Figure 7] A diagram showing an example of the risks that may arise when implementing a plan for a business system [Figure 8] FIG. 10 is a diagram showing an example of costs involved in implementing a proposed plan in a case where a subscription model is adopted. [Figure 9] FIG. 10 is a diagram illustrating an example of the risks involved in implementing a proposed plan that corresponds to a subscription model. [Figure 10] FIG. 10 is a diagram illustrating an example of costs and risks associated with updating content, regardless of the upgrade date, in accordance with a subscription model. [Figure 11] FIG. 10 is a diagram illustrating the operation of the scheduling device. [Figure 12] FIG. 10 is a diagram illustrating the details of the processing in steps S4 and S6. [Figure 13] 10A and 10B are diagrams showing an example of a version upgrade timing prediction, a probability graph, and a method for determining a version upgrade date obtained from the graph. [Figure 14] FIG. 10 is a diagram showing an example of a version upgrade release date and a support deadline from the present date to a target date for a certain product that constitutes a business system, which are set in step S2. [Figure 15] FIG. 10 is a diagram illustrating an example in which the version upgrade date is set three months before the normal support expiration date. [Figure 16] FIG. 10 is a diagram showing an example of planning when the version upgrade date is set to three months before the extended support deadline. [Figure 17] FIG. 10 is a diagram illustrating an image of dependency resolution in a product. [Figure 18] FIG. 10 is a diagram showing an example of the results of determining a time-series risk value s of a target product. [Figure 19] FIG. 20 is a diagram showing an example of calculation of "s_total" in the example of FIG. 18. [Figure 20] FIG. 1 is a diagram illustrating a configuration example of a scheduling device according to an embodiment of the present disclosure. [Figure 21] FIG. 2 is a block diagram illustrating an example of a hardware configuration of a scheduling device according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0012] Each embodiment will be described below with reference to the drawings. In all drawings, the same or corresponding components are denoted by the same reference numerals, and common descriptions will be omitted. FIG. 1 is a diagram showing functional blocks of a scheduling device according to an embodiment of the present disclosure. As shown in FIG. 1, the scheduling device 100 includes a planning unit. This planning unit includes an individual product upgrade planning unit 101, an upgrade timing calculation unit 102, a dependency resolution unit 103, a cost / risk calculation unit 104, a mechanical deadline setting unit 105, and a license contract monitoring unit 106. Furthermore, the scheduling device 100 includes a business system configuration management unit 200, a business system contract management unit 201, and a product information acquisition unit 300.

[0013] The scheduling device 100 receives a target date 501, upgrade date information 502, and business AP information 503 as information input by the administrator of the business system 000 to be managed. The scheduling device 100 also receives product information 504 using external information. In addition, the scheduling device 100 receives product forecast information 505 prepared by the administrator. The scheduling device 100 then outputs a plan proposal 601 using this information.

[0014] In the following description, the system for which the maintenance / upgrade plan is to be created is assumed to be business system 000, and business system 000 is assumed to be a system used by others based on a subscription contract.

[0015] Next, each unit constituting the scheduling device 100 will be described.

[0016] The individual product upgrade planning unit 101 plans an upgrade plan for each product constituting the business system 000 based on input information, set information, and information from other processing units, and creates and outputs a plan 601 including the risk / cost for each planned plan. The individual product upgrade planning unit 101 also receives input of the upgrade date from the administrator and sets it as upgrade date information 502.

[0017] The upgrade timing calculation unit 102 refers to the target date 501, upgrade date information 502, product forecast information 505, etc., and also receives information from the business system configuration management unit 200, and outputs and sets the upgrade release date and support deadline for each product that makes up the business system 000 from the present to the target date 501 as upgrade release date setting information 506. The "target date" will be explained separately.

[0018] The dependency resolving unit 103 refers to the product information 504 and receives information from the business system configuration management unit 200 to resolve version-related dependencies between products that constitute the business system 000 .

[0019] The cost / risk calculation unit 104 refers to business AP information 503, product information 504, product forecast information 505, etc., and also receives information from the business system configuration management unit 200 to calculate the costs, risks, and SI (System Integration) costs involved in implementing the proposed plan.

[0020] The mechanical deadline setting unit 105 refers to the product information 504 and receives information from the business system configuration management unit 200, estimates the upgrade release date and support deadline from the present to the target date 501, and outputs and sets it as upgrade release date setting information 506.

[0021] The license contract monitoring unit 106 monitors information from the business system contract management unit 201, and urges the administrator to make a plan before the contract renewal by subscription of the business system 000 or before the contract expiration of any of the products that make up the business system 000. The license contract monitoring unit 106 also receives input of a target date from the administrator and sets it as the target date 501.

[0022] The business system configuration management unit 200 manages the latest information on all products that make up the business system 000 that is the target of planning. The business system contract management unit 201 manages the contract information of the target business system 000, as well as the contract status and contract period of each product of the business system 000, based on the information from the business system configuration management unit 200.

[0023] The product information acquisition unit 300 acquires product configuration information at a certain point in time in the business system 000, product information 504 relating to the constituent products, and information on the actual state of the constituent products from the outside via a network or the like, and provides this to the planning unit.

[0024] Next, input and output information to and from the scheduling device 100 will be described.

[0025] The target date 501 indicates the date up to which the administrator wishes to continue operation of the target business system 000.

[0026] The upgrade date information 502 includes the following information:

[0027] Tentative candidate date 1: This is a tentative upgrade date for the products that make up the business system 000, with ample time before the support deadline, and is a date indicating a predetermined time before the support deadline, for example, three months before the support deadline. Note that the time is variable. Tentative candidate date 2: A tentative upgrade date for the products that make up business system 000, after the support period has expired and extended support is being used, such as three months before the extended support period. Note that the timing is variable. Candidate date: One or more candidate upgrade dates are determined based on the planning plan obtained from the upgrade dates shown in Candidate Date 1 and Candidate Date 2, taking into consideration the actual system operation.

[0028] The business AP information 503 consists of the following information: -Costs for modifying business applications in response to changes (such as version upgrades) in the products that make up the business system 000

[0029] The product information 504 is information provided by product vendors of products that constitute the business system 000 and is obtained via the Internet or directly from the product vendors, and includes the following information: - Release timing and plans for shipped products Support deadlines for shipped products and future plans Support / subscription fees for shipped products Support details for shipped products (standard support, extended support) Inter-product dependencies (when upgrading one product A, it is necessary to upgrade another product B accordingly) Risk Information -Version incompatibility information

[0030] The product forecast information 505 consists of the following information: -Prediction and probability of upgrade timing for each product (This is the probability that an upgrade will be made by this time, and is graphed with the time on the horizontal axis and the probability on the vertical axis. Figure 2 shows an example of the prediction and probability of upgrade timing for a certain product.) Support period (Figure 3 shows an example of the support period for each version of a product.) Product reliability (products become stable over time. However, they are unstable immediately after an upgrade release. This can be expressed as a graph with time on the horizontal axis and reliability on the vertical axis, taking into account factors such as the product's reliability. Figure 4 shows an example of a product's reliability.) Subscription costs Service content / function changes Risk Information

[0031] The upgrade release date setting information 506 is information for determining the upgrade release date from the above-mentioned product forecast information 505, and is the upgrade release date calculated based on the probability that the products constituting the business system 000 will be upgraded by a certain date, etc.

[0032] The schedule proposal 601 outputted from the scheduling device 100 comprises the following information:

[0033] - Upgrade dates and usage plans for each product up to the target date (Figure 5 shows an example of product upgrade dates and usage plans for that version) Costs incurred when implementing a proposed plan (Figure 6 shows an example of the costs incurred over time when implementing a proposed plan) Risks that may arise when implementing a planned plan (Figure 7 shows an example of the risks that may arise when implementing a planned plan. Figure 7 shows an example of (a) the risk that the support period for the program product (PP) will expire before the version upgrade date, and (b) the risk related to the reliability of the product.)

[0034] Costs of implementing a proposed plan when a subscription model is used. Figure 8 shows an example of the costs of implementing a proposed plan when a subscription model is used. Figure 8 shows that, when it comes to version upgrades, costs are spread over the entire period with a subscription model, compared to an on-premise one-time purchase model (purchase + maintenance). It also shows an example that takes into account incompatibility information between versions. For example, it shows that costs increase if a program contains a lot of SJIS code, but that updating to a specific version, such as updating from RHEL7 to RHEL8, has higher compatibility and lower system integration costs than updating from RHEL6 to RHEL7.

[0035] Risks that arise when implementing a drawn-up plan in the event of a subscription model. Figure 9 shows an example of the risks that arise when implementing a drawn-up plan in the event of a subscription model. Figure 9 outputs the following risks related to the timing of version upgrades. The following items are shown as risks related to the expiration of support for program products (PPs) and responding to failures, etc.

[0036] - Risk of unexpectedly high maintenance costs (A) - Risks related to the reliability of PP (a) - Security risk (c) - Risk of breach of contract... (D) - Risk of a decrease in the number of engineers for XX products (proprietary software, so-called proprietary products)... (O) - Risk of degradation / deprecation of unused features... (F)

[0037] Costs and risks associated with updating provided content, regardless of the upgrade date, when a subscription model is used. Figure 10 shows an example of costs and risks associated with updating provided content, regardless of the upgrade date, for example, a minor version update, in accordance with a subscription model. The costs are reflected using a prediction function for provided content such as functions. In addition, parts that cannot be reflected in costs are output as risks. Examples of costs and risks shown in Figure 10 are as follows:

[0038] (1) What can be reflected in costs Subscription costs -Additions (changes) of functions that have been announced in advance - Cost reduction through improved performance (reducing virtual CPUs, etc.) (2) Things that cannot be reflected in costs (output as risks) Degradation / deprecation of unused features Security risks

[0039] Next, a description will be given of the operation of scheduling device 100. Fig. 11 shows the operation of scheduling device 100.

[0040] The license contract monitoring unit 106 of the scheduling device 100 starts a planning process (S0) by monitoring the business system contract management unit 201 to prompt the administrator to create a plan before the contract renewal by subscription of the business system 000 or before the contract expiration of any of the products based on the contract management information of the products that make up the business system 000. This starts the operation of creating a plan for the maintenance of the business system, including the version upgrade, by the scheduling device 100.

[0041] The license contract monitoring unit 106 prompts the administrator to set a target date for the target business system, and sets the input date as the target date 501 (S1). As mentioned above, the "target date 501" is the date up to which the administrator wishes to continue operation of the target business system 000.

[0042] The upgrade timing calculation unit 102 sets the upgrade release date and support deadline for all products used in the business system from the present date to the target date (S2). Details of this process are shown as steps S21 to S23.

[0043] First, the upgrade timing calculation unit 102 determines whether product forecast information 505 of a target product among the products that make up the business system is available (S21). If the product forecast information 505 is available (S21: Yes), the upgrade timing calculation unit 102 uses the configuration information of the business system obtained by the business system configuration management unit 200, product information 504 of the products that make up the business system obtained by the product information acquisition unit 300, and the product forecast information 505 to predict the upgrade release date and support deadline from the present date to the target date, and sets the result as upgrade release date setting information 506 (S22).

[0044] If the product forecast information 505 cannot be obtained (S21: No), the mechanical deadline setting unit 105 estimates the upgrade release date and support deadline from the present to the target date based on the product information 504, and sets them as the upgrade release date setting information 506 (S23).

[0045] The operations in steps S22 and S23 will be described in more detail below.

[0046] Product forecast information 505 is information obtained from a product forecasting expert, and step S22 is performed when the product forecast information 505 is available. In this case, the upgrade timing calculation unit 102 uses the upgrade timing prediction, probability, and support period from the product forecast information 505. The upgrade release date setting information 506 indicating the probability of an upgrade obtained by the administrator is input to the scheduling device 100, and the upgrade timing calculation unit 102 determines the upgrade release date and support deadline. FIG. 13 is a diagram showing an upgrade timing prediction and probability graph, and an example of determining the upgrade release date obtained from the graph. In FIG. 13, for example, when the input is 90%, the upgrade release date is determined to be the date on which the cumulative upgrade probability from the current date becomes 90%. In addition, the support deadline is determined to be the date obtained by adding the support period to the determined upgrade release date.

[0047] On the other hand, if product forecast information 505 is not available, the mechanical deadline setting unit 105 estimates and sets the upgrade release date and support deadline from the present to the target date based on the product information 504. The estimation method is as follows. The mechanical deadline setting unit 105 obtains the average interval between upgrades from the most recent four upgrade release dates from the product information 504 of the target product, and predicts a future upgrade release date by assuming that upgrades will be performed at the average interval from the latest existing upgrade release date. Similarly, for the support deadline, the mechanical deadline setting unit 105 obtains the average support period from the support periods of the most recent four versions, and sets the date as the upgrade release date obtained by adding the average support period to the obtained upgrade release date. Note that "the most recent four" is just an example and is not limited to this, and any of the most recent information may be used.

[0048] FIG. 14 shows an example of the upgrade release date and support deadline from the present to the target date for a certain product that constitutes a business system, which are set in step S2.

[0049] The individual product upgrade planning unit 101 prompts the administrator to input two tentative upgrade dates for each product, and sets the input tentative upgrade dates as tentative candidate date 1 and tentative candidate date 2 in the upgrade date information 502 (S3). Here, the two tentative upgrade dates to be input are: 1) The first tentative upgrade date indicating a specific time before the end of the support period for the target product. 2) A second tentative upgrade date indicating a specific time before the extended support period for the applicable product. Let's say.

[0050] The individual product upgrade planning unit 101 and the cost / risk calculation unit 104 plan an upgrade plan for the two input upgrade periods. The cost / risk calculation unit 104 also calculates and outputs cost information and risk information for the planned upgrade plan (S4). Details of the processing by the individual product upgrade planning unit 101 and the cost / risk calculation unit 104 will be explained separately.

[0051] The individual product upgrade plan formulation unit 101 prompts the administrator to input multiple upgrade timing candidates and sets the input candidate dates as candidate dates in the upgrade date information 502 (S5). At this time, the administrator provides multiple upgrade timing candidates with reference to the two upgrade plans output by the processing of step S5. For example, the administrator sets candidate dates at one-month intervals between the two candidate dates input in step S4. Note that in the setting work by the administrator here, the administrator can set one or more further candidate dates while checking the trends in risk and cost for the two candidate upgrade dates input in step S4.

[0052] The individual product upgrade planning unit 101 and the cost / risk calculation unit 104 create upgrade plans for the multiple input candidate upgrade dates, and calculate risk and cost information for each created plan (S6). The processing here is the same as the processing in step S4, except for the candidate dates that are the subject of planning and calculation. Details of the processing in the individual product upgrade planning unit 101 and the cost / risk calculation unit 104 will be explained separately.

[0053] The scheduling device 100 outputs the results of planning and calculation in step S6 (S7). The manager refers to risks and costs from the multiple plans that have been output, and adopts the most appropriate one as a proposed plan.

[0054] The scheduling device 100 operates in the above manner.

[0055] Next, the processing of steps S4 and S6 in Fig. 11 will be described in detail. Fig. 12 is a diagram for explaining the details of the processing of steps S4 and S6. Hereinafter, the operations of the individual product upgrade planning unit 101 and the cost / risk calculation unit 104 will be described with reference to Fig. 12.

[0056] First, the individual product upgrade planning unit 101 creates an upgrade plan for use up to the target date 501 for all versions of each product, assuming that the product will be upgraded on the input upgrade date (S101).

[0057] The individual product upgrade planning unit 101 uses information managed by the business system configuration management unit 200, information acquired by the product information acquisition unit 300, and product forecast information 505. Fig. 15 is a diagram showing an example of a case where the upgrade date is set three months before the normal support expiration date. Fig. 16 is a diagram showing an example of planning when the upgrade date is set three months before the extended support expiration date. The individual product upgrade planning unit 101 uses the following conditions as prerequisites for upgrading the plan.

[0058] Products that use Extended Support, consistent with past history and future plans, will always use Extended Support.

[0059] · Products that do not use extended support do not always use extended support.

[0060] When upgrading, upgrade to the latest version available at the time.

[0061] Furthermore, when planning the upgrade timing, the individual product upgrade planning unit 101 classifies the target product into patterns based on whether or not extended support is used, and on the settings of the target date 501 and the upgrade date. For example, the patterns are classified into the following eight patterns:

[0062] ○Pattern when extension support is not used (Pattern 1) The target date 501 is before the end of the standard support period for the currently used version, and the specified upgrade date is before the end of the standard support period for the currently used version. (Pattern 2) If the target date 501 is before the end of the normal support period for the version that will be the latest on the specified upgrade date (Pattern 3) If the target date 501 is after the normal support period of the version that will be the latest on the specified upgrade date (Pattern 4) If there is no version available for upgrade on the specified upgrade date, regardless of the target date 501.

[0063] ○Pattern when using extended support When there are multiple types of extended support, the individual product upgrade planning unit 101 classifies the patterns according to the type of extended support.

[0064] (Pattern 5) The target date 501 is before the end of the extended support period for the currently used version, and the specified upgrade date is before the end of the extended support period for the currently used version. (Pattern 6) If the target date 501 is before the end of the extended support period for the version that will be the latest on the specified upgrade date (Pattern 7) If the target date 501 is after the end of the extended support period for the version that will be the latest on the specified upgrade date (Pattern 8) If there is no version available for upgrade on the specified upgrade date, regardless of the target date 501

[0065] The individual product upgrade planning unit 101 creates an upgrade plan for each classified pattern as follows: The individual product upgrade planning unit 101 continues creating the upgrade plan until the upgrade plan reaches the target date 501 or until it becomes clear that there is no upgrade path and planning is impossible.

[0066] Planning for when extended support is not used (In the case of pattern 1) Propose a plan to continue using the version currently in use.

[0067] (In the case of pattern 2) A plan is made to upgrade to the latest version on the upgrade date specified by the user.

[0068] (In the case of pattern 3) The version is upgraded to the latest version on the upgrade date specified by the user. After that, it is determined which of patterns 1 to 4 the relationship between the upgrade release date and support expiry date from the current date to the target date 501 created earlier and the upgraded version matches, and processing of that pattern is performed. This is repeated until pattern 1 or 2 is met.

[0069] (In the case of pattern 4) Notify the administrator that planning is not possible for the specified version upgrade date.

[0070] Planning for Extended Support (For pattern 5) Plan to continue using the version you are currently using (use extended support if necessary).

[0071] (Pattern 6) Plan to upgrade to the latest version on the upgrade date specified by the user. (If necessary, use extended support before upgrading.)

[0072] (In the case of pattern 7) The version is upgraded to the latest version on the upgrade date specified by the user. After that, it is determined which of patterns 5 to 8 the relationship between the upgrade release date and support deadline from the current date to the target date 501 created earlier and the upgraded version matches, and processing for that pattern is performed. This is repeated until it matches pattern 5 or 6. (If necessary, extended support is used before each upgrade.)

[0073] (In the case of pattern 8) Notify the administrator that planning is not possible for the specified version upgrade date.

[0074] Once the creation of an upgrade plan for each product that constitutes the business system is complete, the dependency resolution unit 103 resolves the dependency relationships for each product in the following procedure based on the product information 504 (S102). This dependency resolution involves re-creating an upgrade plan for each product. Note that the dependency resolution unit 103 also follows the prerequisites for creating an upgrade plan in step S101 when re-creating an upgrade plan for each product.

[0075] FIG. 17 is a diagram illustrating dependency resolution between products. Dependency resolution between products will be described using FIG. 17. FIG. 17 shows an example of dependency between two products, product A and product B. When product A is upgraded from version 1 to version 2, it is assumed that the current version 1 of product B corresponds to version 2 of product A. In this case, when product A is upgraded from version 1 to version 2 at the timing shown in FIG. 17, product B can remain at version 1 and does not need to be upgraded. When product A is upgraded from version 2 to version 3, it is assumed that the current version 1 of product B does not correspond to version 3 of product A. In this case, a dependency occurs in which when product A is upgraded from version 2 to version 3 at the timing shown in FIG. 17, product B needs to be upgraded from version 1 to version 2 at the same time as product A is upgraded.

[0076] In this process, the dependency resolving unit 103 performs dependency resolving processing starting from the product with the earliest support deadline from the current point of view among all the products.

[0077] First, the starting product is upgraded on the entered upgrade date. Dependencies with all other products other than the starting product are checked, and products that have dependencies and require an upgrade are upgraded on the upgrade date, while products that do not require an upgrade are used as is.

[0078] Next, the system focuses on the next product whose support period is about to expire, and upgrades the product on the entered upgrade date. It checks the dependencies with all other products other than the product whose support period is about to expire, and upgrades the dependent products, while continuing to use products that do not require an upgrade. This process is repeated until the upgrade date of the product of interest reaches the target date.

[0079] Next, the cost / risk calculation unit 104 calculates the cost and risk of implementing the plan drawn up in step S102 (S103). Note that risk calculation takes into account risk factors, which can be flexibly set / added to the scheduling device 100. Examples of risk factors are shown below.

[0080] Hardware lifespan - MTBF(Mean Time Between Failures) - MTTR(Mean Time To Repair(Recovery)) Software support life cycle - Reliability - Vulnerability detection rate

[0081] In the risk calculation, the cost / risk calculation unit 104 performs calculation using risk elements as follows.

[0082] Apply an appropriate multiplying factor to each risk element and combine all elements into one formula. For example, each risk element can take a value between 0 and 1, with "1" representing an unacceptable state = 100% risk, and "0" representing no risk. Alternatively, values ​​derived independently from each risk element can be used.

[0083] Specific examples of risk elements are as follows: The cost / risk calculation unit 104 performs risk calculation using one or more of the risk elements shown below.

[0084] Hardware failure rate (reciprocal of MTBF) f1(t): Usually, the failure rate increases in the initial stage of the product and at the end of the product's life, forming a bathtub curve. · Repair time (MTTR) f2(t): Risk factor when maintenance personnel rush to the scene to replace parts. It is set to a constant value during the maintenance period. Note that the allowable value differs depending on the application and configuration, so it is determined by the user (administrator). For example, if the allowable time until part replacement is one hour, then the value should be set to "1" (unacceptable) if it exceeds one hour.

[0085] Repair cost f3(t): Constant during the maintenance period, but becomes undefined if spot repairs are implemented thereafter. For example, the cost is fixed at XX yen during the maintenance period, and spot repairs are a risk function based on probability x part cost (yen).

[0086] - Trouble occurrence rate f4(t): Usually increases with version upgrades, gradually decreases, and increases after the support period, though it is unknown - Security hole discovery rate f5(t): Remains constant within the support period, but increases thereafter - Elements related to propeller product engineers. There are two elements to this element: 1) Cost increase curve f6(t) 2) Correction time curve f7(t)

[0087] Here, the weight of each risk element is determined by the user (administrator) taking into account the severity of the risk. The cost / risk calculation unit 104 calculates an abstracted time-series risk value for the target product for each risk element using the following formula, which multiplies and adds a coefficient to a function f, which uses time as a variable. s = a1 x f1(t) + a2 x f2(t) + …

[0088] The above formula s may be arbitrarily determined by the user (administrator). Formula s may also be a linear, non-linear, or other function. By integrating this formula s over time, for example, integrating from the start to shutdown of the business system, the total risk of the target product can be determined. Figure 18 shows an example of the results of determining the time-series risk value s of the target product. Figure 18 shows the risk value s when the target product is built on platform PF-A (e.g., UNIX (registered trademark)) and when it is built on platform PF-B (e.g., Linux (registered trademark)).

[0089] In the example shown in Figure 18, the risk value for the "renewal date (ts)" is calculated. The "renewal date (ts)" is changed sequentially, and PF-A is used "until" the renewal date (ts), and PF-B is used "from" the renewal date (ts). The sum of s calculated for each is the "s_total" on the renewal date (ts). Figure 19 is a diagram showing an example of calculating "s_total" in the example shown in Figure 18.

[0090] The calculation of this "s_total" can be written more generally as follows:

[0091] s_total = s_a + s_b + .... The "renewal date (ts)" that minimizes this s_total is the "best renewal date for the product for that user."

[0092] As the number of risk factors used increases, the minimum value of s_total increases in dimensions, such as two or three, and the amount of calculation required to find the minimum value increases. In this case, s_total is solved using numerical calculations such as Newton's method, neural networks, and annealing.

[0093] The cost / risk calculation unit 104 determines the risk of the proposed plan as the average of all products' risk values ​​s_total of each product when upgrading (or updating) according to the proposed plan.

[0094] If the contract information for the business system is a subscription-based contract, the cost / risk calculation unit 104 adds risk factors such as risk factors for dealing with failures when the support period for the target product expires and factors explained in the explanation about the subscription.The cost / risk calculation unit 104 then uses these risk factors to calculate the risk value in chronological order up to the target date for the target product.

[0095] Furthermore, the cost / risk calculation unit 104 calculates the cost for each product when implementing the drawn up plan, and also calculates the total amount of the calculated costs, using the business AP information 503, product information 504, and input information from the business system configuration management unit 200. The cost / risk calculation unit 104 calculates the total amount of the calculated costs for each drawn up plan.

[0096] As described above, the administrator registers contract information related to the business system in advance in the scheduling device 100, and the scheduling device 100 prompts the administrator to create a maintenance plan before the contract expires, based on the contract information registered in the business system contract management unit 201. As a result, even if the business system is based on a subscription model contract in which it is possible for the system to be used for a long period of time, a maintenance plan for the business system can be created before the contract based on the subscription model is renewed, reducing the risk of breaching the contract based on the subscription model and enabling continuous operation and management of the business system. Furthermore, even if the contract for a product that constitutes the business system expires, maintenance management for that purpose is possible.

[0097] In addition, the administrator sets a target date (hereafter referred to as the target date) for the business system in question, up to which they would like to continue operation. This makes it possible to create a maintenance plan for the business system that takes the target date into consideration.

[0098] Furthermore, the scheduling device 100 receives product information and product forecast information as input and sets the upgrade release date and support deadline from the current date to the target date for all products used in the system. If product forecast information is not available, it is also possible to mechanically set the upgrade release date and support deadline based on the product information.

[0099] Furthermore, based on the upgrade release date and support expiration date, the administrator can set a tentative upgrade date for each product and create a rough draft plan. The tentative upgrade date can be set in two ways: a pattern in which the upgrade is carried out well before the support expiration date (e.g., three months before the support expiration date (this time can be variable)), or a pattern in which the upgrade is carried out after the support expiration date and extended support is used (e.g., three months before the extended support expiration date (this time can be variable)). Note that a single tentative upgrade date can also be set.

[0100] The two draft plans obtained by inputting the two upgrade dates above include cost and risk information, allowing managers to understand the cost / risk trends resulting from the difference between the two upgrade dates.

[0101] Furthermore, the administrator can refer to the results of the two plans above and determine multiple candidate upgrade dates that take system operations into consideration. The candidate upgrade dates can be set between the two tentative upgrade dates above or outside that range, for example, every X months. If set every month, the update dates can also be two months before the support expiration date, one month before the support expiration date, the support expiration date, two months before the extended support expiration date, one month before the extended support expiration date, or the extended support expiration date.

[0102] Furthermore, the maintenance / upgrade schedule device creates plans for each of the determined upgrade date candidates, and the administrator can check the risks and costs associated with each. Therefore, the administrator can select the optimal plan from among the multiple plans created, taking into account cost and risk information, and use it as the final plan.

[0103] As described above, the scheduling device 100 according to an embodiment of the present disclosure manages contract information of a target business system, notifies the administrator before the contract expires, and formulates an upgrade plan.

[0104] In addition, the scheduling device 100 has changed to a subscription model, and the content and costs of services have changed from fixed to continuously updated, so product information and expert forecast information can be added as inputs. Furthermore, the scheduling device 100 can incorporate various risks, such as security risks and a shortage of professional engineers, as factors. In addition, the scheduling device 100 can incorporate security risks as some kind of function.

[0105] The scheduling device 100 can then create a timely version upgrade plan in a cloud environment system that takes into account licenses, operation periods, and repair costs.

[0106] FIG. 20 is a diagram illustrating an example configuration of a scheduling device 100 according to an embodiment of the present disclosure. The scheduling device 100 includes a contract monitoring unit 110, an individual product upgrade plan creation unit 120, and a risk calculation unit 130. The contract monitoring unit 110 receives, based on contract information related to a business system that is the target of a maintenance plan, a target date for launching the business system before the contract expiration date and for continuing operation of the business system. The individual product upgrade plan creation unit 120 receives a set upgrade date for maintenance of the business system, which indicates a predetermined time before the support deadline, and creates a plan for upgrading each product up to the target date based on information related to the upgrade release date and support deadline for each product that constitutes the business system, in the case where the upgrade is to be performed on the upgrade date before the support deadline. The risk calculation unit 130 chronologically calculates risk values ​​for each product up to the target date based on information related to the risk for each product, and calculates the average of the calculated risk values ​​for each product as the risk for implementing the plan.

[0107] 21 is a block diagram showing an example of the hardware configuration of the scheduling device 100. The hardware configuration of the scheduling device 100 includes a CPU 51, a RAM (Random Access Memory) 52, a ROM (Read Only Memory) 53, and a recording device 54. The ROM 53 and the recording device 54 store programs and information that implement the functions of the scheduling device 100, namely, the planning unit, the business system configuration management unit 200, the business system contract management unit 201, and the product information acquisition unit 300. The RAM 52 is used as a work area for temporarily storing data used by the CPU 51 and other units during operation. The scheduling device 100 also includes an input / output port 55 that serves as an interface with input / output devices such as a display device, a mouse, and a keyboard. The input / output port 55 also functions as a communication port for communication with other information processing devices. The ROM 53 may be configured with an EEPROM (Electrically Erasable Programmable Read-Only Memory) or the like, and the recording device 54 may be configured with a hard disk, SSD, or the like, so that the computer programs for realizing each function of the scheduling device 100 can be updated in the ROM 53 or the recording device 54.

[0108] Although the present disclosure has been described above with reference to the embodiments, the present disclosure is not limited to the above-described embodiments. Various modifications that can be understood by those skilled in the art can be made to the configuration and details of the present disclosure within the scope of the present disclosure. Furthermore, each embodiment can be combined with other embodiments as appropriate.

[0109] Some or all of the above-described embodiments can be described as, but are not limited to, the following supplementary notes.

[0110] (Appendix 1) a contract monitoring means for starting up a business system to be maintained before the contract expires, based on contract information relating to the business system, and receiving a target date for planning continued operation of the business system; an individual product upgrade planning means for receiving a set date of an upgrade date for maintenance of the business system, the set date indicating a predetermined time before the support deadline, and for planning an upgrade for each product up to the target date based on information about the upgrade release date and the support deadline for each product constituting the business system, in the case where an upgrade is to be performed on the upgrade date before the support deadline; a risk calculation means for calculating a risk value for each product in chronological order up to the target date when the planning is implemented based on the information on the risk for each product, and calculating an average value of the calculated risk values ​​for each product as the risk when the planning is implemented; A scheduler comprising:

[0111] (Appendix 2) the individual product upgrade planning means receives settings of a first upgrade date indicating a predetermined time before the support deadline, a second upgrade date indicating a predetermined time before the extension period of the support deadline, and a plurality of upgrade dates between the first upgrade date and the second upgrade date, and plans an upgrade for each of the products for each of the first upgrade date, the second upgrade date, and the plurality of upgrade dates; the risk calculation means calculates an average value of the risk values ​​calculated for each product for the first upgrade date, the second upgrade date, and the plurality of upgrade dates as the risk when the plan is implemented; 2. The scheduling device of claim 1.

[0112] (Appendix 3) When planning a version upgrade for each product, the individual product upgrade planning means plans a version upgrade for the product based on whether the product to be planned receives extended support or not, and based on the target date, the upgrade date, and the support deadline of the product to be planned. 3. The scheduling device of claim 2.

[0113] (Appendix 4) a dependency resolving means for, when the product to be planned is upgraded on the upgrade date based on information regarding the dependency relationship between the upgrade of each product and the upgrade of other products, if there is a product that depends on the upgrade of the product to be planned, correcting the upgrade of the dependent product to be the upgrade date; 4. The scheduling device according to claim 2 or 3, further comprising:

[0114] (Appendix 5) an upgrade timing calculation means for, when there is no information about an upgrade release date and a support period for any of the products constituting the business system, determining the upgrade release date as the date on which a cumulative value of the upgrade probability from the shipping date of the product becomes equal to or exceeds a predetermined value based on data on the chronological upgrade probability of the product, and setting the support period as the date obtained by adding the estimated support period from the determined upgrade release date; 5. The scheduling device according to claim 2, further comprising:

[0115] (Appendix 6) a mechanical deadline setting means for, when there is no information regarding the upgrade release date and support expiration date for any of the products constituting the business system, calculating an average interval between upgrade releases from the most recent multiple upgrade release dates for the product, and predicting a future upgrade release date by adding the calculated average interval to the most recent upgrade release date, calculating an average support expiration date from the most recent multiple support expiration dates for the product, and predicting a future support expiration date by adding the calculated average to the future upgrade release date, and setting the future upgrade release date and future support expiration date as the upgrade release date and support expiration date for the product; 6. The scheduling device according to any one of Supplementary Note 2 to Supplementary Note 5, further comprising:

[0116] (Appendix 7) The information about the risk of each product includes at least one item of a hardware failure rate, a repair time, a repair cost, a trouble occurrence rate, a security hole detection rate, and a factor related to a product engineer; the risk calculation means calculates a risk value for each product constituting the business system in chronological order up to the target date of the target product based on items included in the information on the risk for each product; 7. A scheduling device according to any one of Supplementary Note 2 to Supplementary Note 6.

[0117] (Appendix 8) When the contract information regarding the business system is a subscription-based contract, the information regarding the risk for each product constituting the business system further includes information regarding items for responding to failures when the support period for the products constituting the business system expires, When the contract information regarding the business system is a subscription-based contract, the risk calculation means calculates a risk value in chronological order up to the target date of the target product, also using items for troubleshooting when the support period for a product constituting the business system expires. 8. The scheduling device of claim 7.

[0118] (Appendix 11) Based on contract information related to the business system that is the subject of the maintenance plan, a target date is set for starting up the business system before the contract expires and continuing operation of the business system is planned, receiving a set date for the upgrade date for maintenance of the business system, the set date indicating a predetermined time before the support deadline, and based on information regarding the upgrade release date and the support deadline for each product constituting the business system, planning an upgrade for each product up to the target date in the case where the upgrade will be performed on the upgrade date before the support deadline; Based on the information on the risk for each product, a risk value is calculated in chronological order up to the target date for each product in the case where the planning is implemented, and the average value of the calculated risk values ​​for each product is calculated as the risk in the case where the planning is implemented. A scheduling method in which tasks are performed by a computer.

[0119] (Appendix 12) receiving a first upgrade date indicating a predetermined time before the support deadline, a second upgrade date indicating a predetermined time before the extension period of the support deadline, and a plurality of upgrade dates between the first upgrade date and the second upgrade date, and planning an upgrade for each of the products for each of the first upgrade date, the second upgrade date, and the plurality of upgrade dates; calculating an average value of the risk values ​​calculated for each of the first upgrade date, the second upgrade date, and the plurality of upgrade dates as a risk when the plan is implemented; 12. The scheduling method of claim 11, further comprising:

[0120] (Appendix 13) When planning a version upgrade for each product, the plan for the version upgrade of the product to be planned is made based on whether or not the product to be planned will have extended support, and based on the target date, the version upgrade date, and the support deadline of the product to be planned. 13. The scheduling method of claim 12, further comprising:

[0121] (Appendix 14) When the product to be planned is upgraded on the upgrade date based on information about the dependency relationship between the upgrade of each product and the upgrade of other products, if there is a product that depends on the upgrade of the product to be planned, the upgrade of the dependent product is corrected to be the upgrade date. 14. The scheduling method of claim 12 or 13, further comprising:

[0122] (Appendix 15) If there is no information about the upgrade release date and support period for any of the products that make up the business system, the upgrade release date is determined as the date on which the cumulative value of the upgrade probability from the shipping date of the product becomes equal to or exceeds a predetermined value, based on the data on the chronological upgrade probability of the product, and the support period is set as the date calculated by adding the estimated support period from the upgrade release date. 15. The scheduling method of any one of Supplementary Notes 12 to 14, further comprising:

[0123] (Appendix 16) If there is no information regarding the upgrade release date and support expiration date for any of the products that make up the business system, the system calculates the average interval between upgrade releases from the most recent multiple upgrade release dates for the product, and adds the calculated average interval to the most recent upgrade release date to predict a future upgrade release date; the system calculates the average support expiration date from the most recent multiple support expiration dates for the product, and adds the calculated average to the future upgrade release date to predict a future support expiration date; and sets the future upgrade release date and future support expiration date as the upgrade release date and support expiration date for the product. 16. The scheduling method of any one of Supplementary Notes 12 to 15, further comprising:

[0124] (Appendix 17) The information about the risk of each product includes at least one item of a hardware failure rate, a repair time, a repair cost, a trouble occurrence rate, a security hole detection rate, and a factor related to a product engineer; the risk calculation means calculates a risk value for each product constituting the business system in chronological order up to the target date of the target product based on items included in the information on the risk for each product; 17. The scheduling method of any one of Supplementary Notes 12 to 16, further comprising:

[0125] (Appendix 18) When the contract information regarding the business system is a subscription-based contract, the information regarding the risk for each product constituting the business system further includes information regarding items for responding to failures when the support period for the products constituting the business system expires, When the contract information regarding the business system is a subscription-based contract, the risk calculation means calculates a risk value in chronological order up to the target date of the target product, also using items for troubleshooting when the support period for a product constituting the business system expires. 18. The scheduling method of claim 17, further comprising:

[0126] (Appendix 21) Based on contract information related to the business system that is the subject of the maintenance plan, a target date is set for starting up the business system before the contract expires and continuing operation of the business system is planned, receiving a set date for the upgrade date for maintenance of the business system, the set date indicating a predetermined time before the support deadline, and based on information regarding the upgrade release date and the support deadline for each product constituting the business system, planning an upgrade for each product up to the target date in the case where the upgrade will be performed on the upgrade date before the support deadline; Based on the information on the risk for each product, a risk value is calculated in chronological order up to the target date for each product in the case where the planning is implemented, and the average value of the calculated risk values ​​for each product is calculated as the risk in the case where the planning is implemented. A program that makes a computer do something.

[0127] (Appendix 22) receiving a first upgrade date indicating a predetermined time before the support deadline, a second upgrade date indicating a predetermined time before the extension period of the support deadline, and a plurality of upgrade dates between the first upgrade date and the second upgrade date, and planning an upgrade for each of the products for each of the first upgrade date, the second upgrade date, and the plurality of upgrade dates; calculating an average value of the risk values ​​calculated for each of the first upgrade date, the second upgrade date, and the plurality of upgrade dates as a risk when the plan is implemented; 22. The program of claim 21, further causing a computer to execute the steps.

[0128] (Appendix 23) When planning a version upgrade for each product, the plan for the version upgrade of the product to be planned is made based on whether or not the product to be planned will have extended support, and based on the target date, the version upgrade date, and the support deadline of the product to be planned. 23. The program of claim 22, further causing a computer to execute the steps.

[0129] (Appendix 24) When the product to be planned is upgraded on the upgrade date based on information about the dependency relationship between the upgrade of each product and the upgrade of other products, if there is a product that depends on the upgrade of the product to be planned, the upgrade of the dependent product is corrected to be the upgrade date. 24. The program according to claim 22 or 23, further causing a computer to execute the following:

[0130] (Appendix 25) If there is no information about the upgrade release date and support period for any of the products that make up the business system, the upgrade release date is determined as the date on which the cumulative value of the upgrade probability from the shipping date of the product becomes equal to or exceeds a predetermined value, based on the data on the chronological upgrade probability of the product, and the support period is set as the date calculated by adding the estimated support period from the upgrade release date. 25. The program according to any one of appendices 22 to 24, further causing a computer to execute the following.

[0131] (Appendix 26) If there is no information regarding the upgrade release date and support expiration date for any of the products that make up the business system, the system calculates the average interval between upgrade releases from the most recent multiple upgrade release dates for the product, and adds the calculated average interval to the most recent upgrade release date to predict a future upgrade release date; the system calculates the average support expiration date from the most recent multiple support expiration dates for the product, and adds the calculated average to the future upgrade release date to predict a future support expiration date; and sets the future upgrade release date and future support expiration date as the upgrade release date and support expiration date for the product. 26. The program according to any one of appendices 22 to 25, further causing a computer to execute the following.

[0132] (Appendix 27) The information about the risk of each product includes at least one item of a hardware failure rate, a repair time, a repair cost, a trouble occurrence rate, a security hole detection rate, and a factor related to a product engineer; the risk calculation means calculates a risk value for each product constituting the business system in chronological order up to the target date of the target product based on items included in the information on the risk for each product; 27. The program according to any one of appendices 22 to 26, further causing a computer to execute the following.

[0133] (Appendix 28) When the contract information regarding the business system is a subscription-based contract, the information regarding the risk for each product constituting the business system further includes information regarding items for responding to failures when the support period for the products constituting the business system expires, When the contract information regarding the business system is a subscription-based contract, the risk calculation means calculates a risk value in chronological order up to the target date of the target product, also using items for troubleshooting when the support period for a product constituting the business system expires. 28. The program of claim 27, further causing a computer to execute the steps.

[0134] 000 Business System 100 Scheduler 101 Individual Product Upgrade Planning Department 102 Version upgrade time calculation section 103 Dependency Resolution Unit 104 Risk Calculation Department 105 Mechanical deadline setting section 106 License Agreement Monitoring Department 200 Business System Configuration Management Department 201 Business Systems Contract Management Department 300 Product information acquisition department 501 Target Date 502 Version update date 503 Business AP information 504 Product Information 505 Product Forecast Information 506 Version upgrade release date setting information 601 Plan

Claims

1. a contract monitoring means for starting up a business system to be maintained before the contract expires, based on contract information relating to the business system, and receiving a target date for planning continued operation of the business system; an individual product upgrade planning means for receiving a set date of an upgrade date for maintenance of the business system, the set date indicating a predetermined time before the support deadline, and for planning an upgrade for each product up to the target date based on information about the upgrade release date and the support deadline for each product constituting the business system, in the case where an upgrade is to be performed on the upgrade date before the support deadline; a risk calculation means for calculating a risk value for each product in chronological order up to the target date when the planning is implemented based on the information on the risk for each product, and calculating an average value of the calculated risk values ​​for each product as the risk when the planning is implemented; A scheduler comprising:

2. the individual product upgrade planning means receives settings of a first upgrade date indicating a predetermined time before the support deadline, a second upgrade date indicating a predetermined time before the extension period of the support deadline, and a plurality of upgrade dates between the first upgrade date and the second upgrade date, and plans an upgrade for each of the products for each of the first upgrade date, the second upgrade date, and the plurality of upgrade dates; the risk calculation means calculates an average value of the risk values ​​calculated for each product for the first upgrade date, the second upgrade date, and the plurality of upgrade dates as the risk when the plan is implemented; 2. The scheduling device according to claim 1.

3. When planning a version upgrade for each product, the individual product upgrade planning means plans a version upgrade for the product to be planned based on whether the product to be planned will have extended support or not, and based on the target date, the upgrade date, and the support deadline of the product to be planned.

3. The scheduling device according to claim 2.

4. a dependency resolving means for, when the product to be planned is upgraded on the upgrade date based on information regarding the dependency relationship between the upgrade of each product and the upgrade of other products, if there is a product that depends on the upgrade of the product to be planned, correcting the upgrade of the dependent product to be the upgrade date; The scheduling device of claim 2 further comprising:

5. an upgrade timing calculation means for, when there is no information about an upgrade release date and a support period for any of the products constituting the business system, determining the upgrade release date as the date on which a cumulative value of the upgrade probability from the shipping date of the product becomes equal to or exceeds a predetermined value based on data on the chronological upgrade probability of the product, and setting the support period as the date obtained by adding the estimated support period from the determined upgrade release date; The scheduling device of claim 2 further comprising:

6. a mechanical deadline setting means for, when there is no information regarding the upgrade release date and support expiration date for any of the products constituting the business system, calculating an average interval between upgrade releases from the most recent multiple upgrade release dates for the product, and predicting a future upgrade release date by adding the calculated average interval to the most recent upgrade release date, calculating an average support expiration date from the most recent multiple support expiration dates for the product, and predicting a future support expiration date by adding the calculated average to the future upgrade release date, and setting the future upgrade release date and future support expiration date as the upgrade release date and support expiration date for the product; The scheduling device of claim 2 further comprising:

7. The information regarding the risk for each product includes at least one item of a hardware failure rate, a repair time, a repair cost, a trouble occurrence rate, a security hole detection rate, and a factor related to a product engineer; the risk calculation means calculates a risk value for each product constituting the business system in chronological order up to the target date of the target product based on items included in the information on the risk for each product; 3. The scheduling device according to claim 2.

8. When the contract information regarding the business system is a subscription-based contract, the information regarding the risk for each product constituting the business system further includes information regarding items for responding to failures when the support period for the products constituting the business system expires, When the contract information regarding the business system is a subscription-based contract, the risk calculation means calculates a risk value in chronological order up to the target date of the target product, also using items for troubleshooting when the support period for a product constituting the business system expires.

8. The scheduling device according to claim 7.

9. Based on contract information related to the business system that is the subject of the maintenance plan, a target date is set for starting up the business system before the contract expires and continuing operation of the business system is planned, receiving a set date for the upgrade date for maintenance of the business system, the set date indicating a predetermined time before the support deadline, and based on information regarding the upgrade release date and the support deadline for each product constituting the business system, planning an upgrade for each product up to the target date in the case where the upgrade will be performed on the upgrade date before the support deadline; Based on the information on the risk for each product, a risk value is calculated in chronological order up to the target date for each product in the case where the planning is implemented, and the average value of the calculated risk values ​​for each product is calculated as the risk in the case where the planning is implemented. A scheduling method in which tasks are performed by a computer.

10. Based on contract information related to the business system that is the subject of the maintenance plan, a target date is set for starting up the business system before the contract expires and continuing operation of the business system is planned, receiving a set date for the upgrade date for maintenance of the business system, the set date indicating a predetermined time before the support deadline, and based on information regarding the upgrade release date and the support deadline for each product constituting the business system, planning an upgrade for each product up to the target date in the case where the upgrade will be performed on the upgrade date before the support deadline; Based on the information on the risk for each product, a risk value is calculated in chronological order up to the target date for each product in the case where the planning is implemented, and the average value of the calculated risk values ​​for each product is calculated as the risk in the case where the planning is implemented. A program that makes a computer do something.

Images