Service plan generation system and method thereof

Abstract

The invention provides a service plan generation method, which comprises the following steps of: receiving a service request which comprises a plurality of characteristic volume labels, selecting a plurality of recommended items from an item database according to the plurality of characteristic volume labels, calculating a plurality of item failure rates according to a plurality of historical execution records of the plurality of recommended items, and generating a service plan according to the plurality of item failure rates, the server receives a plurality of item failure rates, calculates a plurality of rework times corresponding to the plurality of recommended items according to the plurality of item failure rates, generates a plurality of buffer items corresponding to the plurality of recommended items according to the plurality of rework times, and schedules according to the plurality of recommended items and the plurality of buffer items to generate a service plan.

Description

Technical Field

[0001] The present application relates to a request for quotation, and in particular to a service plan generation system and method thereof. Background Art

[0002] A Request for Quotation (RFQ) is a request for services such as design, production or testing, followed by the creation of a service plan to review the cost of the required resources. The resources include, but are not limited to, manpower, equipment, materials and environment. The RFQ process is core to business because customers need reliable and reasonable service plan quotes that are also profitable for the service provider. However, there are several shortcomings in the current process as follows:

[0003] The first is time-consuming. Each functional team manually converts business requirements into technical service projects and then schedules them accordingly. This approach is very time-consuming because it requires multiple parties to participate in discussions, which increases complexity and takes a long time to respond to customers.

[0004] The second is inaccurate cost estimates, which often exceed expectations because some service items may not be delivered to customers as expected and need to be redone to ensure service quality. The existing approach is to add a simple "risk factor" and multiply the ideal (no failure) cost by it to ensure that the service plan is still profitable. However, simple factors are often too conservative, resulting in higher prices and lost business opportunities during the bidding process. In addition, during the negotiation process, there is no way to quantitatively assess the trade-off between high cost and high risk. Summary of the invention

[0005] In view of this, the present application proposes a service plan generation system and method thereof, which can automatically generate service plan quotations, minimize human intervention, and thus save time and cost.

[0006] A first aspect of the present application provides a service plan generation method, comprising executing with a computing device: receiving a service request, the service request comprising a plurality of feature tags, selecting a plurality of recommended items from a project database based on the plurality of feature tags, calculating a plurality of project failure rates based on a plurality of historical execution records of the plurality of recommended items, calculating a plurality of redo times corresponding to the plurality of recommended items based on the plurality of project failure rates, generating a plurality of buffer items corresponding to the plurality of recommended items based on the plurality of redo times, and performing a schedule based on the plurality of recommended items and the plurality of buffer items to generate a service plan.

[0007] The second aspect of the present application provides a service plan generation system, including: a project database, a project selector, a failure rate calculator and a service scheduler. The project database is used to store multiple standardized projects. The project selector is used to select multiple recommended projects from the multiple standardized projects in the project database according to multiple feature tags included in a service request. The failure rate calculator is used to calculate multiple project failure rates according to multiple historical execution records of the multiple recommended projects, calculate multiple retry times corresponding to the multiple recommended projects according to the multiple project failure rates, and generate multiple buffer projects corresponding to the multiple recommended projects according to the multiple retry times. The service scheduler is used to perform a schedule based on the multiple recommended projects and the multiple buffer projects to generate a service plan. In summary, the present application proposes a service calculation generation system and method thereof, which can automatically generate a service plan quotation, minimize human intervention, and thus save time and cost. The service plan quotation includes a work item list, a service item operation schedule and a cost estimate. The customer sends a request containing project information or criteria with a terminal device, and the system reviews the historical execution records to provide a recommended service item list, while estimating the project operation time and considering the risk of failure. Next, a schedule and cost estimate can be established and responded to the customer's device. The benefits of this application are as follows: First, time saving: the above process is not only digital but also automated, so it can save time and increase service flexibility; and second, transparent and adjustable cost estimates: the cost structure can be tracked from the historical execution records displayed item by item, and the service confidence level of this plan can also be displayed. For business negotiations, the recommended cost can still be adjusted to meet the customer's budget, and the selected service confidence level can reflect the risk of this plan.

[0008] The above description of the disclosed contents and the following description of the implementation modes are used to demonstrate and explain the spirit and principle of the present application, and to provide a further explanation of the scope of the patent application of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 Shown is an architectural diagram of the service plan generation system described in an embodiment of the present application.

[0010] Figure 2 Shown is a schematic diagram of the recommended items and buffer items described in an embodiment of the present application.

[0011] Figure 3 Shown is an architectural diagram of the service plan generation method described in an embodiment of the present application.

[0012] Component number description

[0013] 10 Project Database

[0014] 20 Project Selector

[0015] 30 Failure Rate Calculator

[0016] 40 Service Scheduler

[0017] R1, R2, R3 Resources

[0018] 1, 2, 3, 7, 8, 9, 10 Recommended items

[0019] 2', 3', 7, (8, 9, 10)' Buffer items

[0020] Steps S1 to S9 DETAILED DESCRIPTION

[0021] The detailed features and characteristics of the present application are described in detail in the following embodiments, and the content is sufficient to enable any person skilled in the relevant art to understand the technical content of the present application and implement it accordingly, and according to the content disclosed in this specification, the scope of the patent application and the drawings, any person skilled in the relevant art can easily understand the relevant concepts and characteristics of the present application. The following examples further illustrate the viewpoints of the present application in detail, but do not limit the scope of the present application in any way.

[0022] The present application proposes a service plan generation system, which is implemented in the form of a computing device executing software. In one embodiment, the computing device can be implemented using one or more of the following examples: a personal computer, a network server, a microcontroller (MCU), an application processor (AP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system-on-a-chip (SOC), a deep learning accelerator, or any electronic device including similar functions. The present application does not limit the hardware type of the computing device. In addition, the present application does not limit the number of computing devices. For example, each module in the software can be executed on an independent computing device, and multiple computing devices can be communicated with each other.

[0023] Figure 1 is an architecture diagram of a service plan generation system according to an embodiment of the present application. Figure 1 As shown, the service plan generation system includes a project database 10 , a project selector 20 , a failure rate calculator 30 , and a service scheduler 40 .

[0024] The project database 10 is used to store a plurality of standardized projects. In one embodiment, each standardized project includes: service name, execution steps, time / material / cost required for the service, correlation with other services, etc., but is not limited to the above examples. In one embodiment, the service provider generates these plurality of standardized projects and feature tag sets in advance based on the historical execution records of the plurality of services, and the generation method is described in detail later.

[0025] The item selector 20 is used for selecting a plurality of recommended items from a plurality of standardized items in the item database 10 according to a plurality of characteristic tags included in a service request.

[0026] In one embodiment, the service request is a contract or a document. The project selector 20 can apply natural language processing (NLP) technology to analyze the service request text to select feature tags. In another embodiment, the customer or service provider selects feature tags associated with the service request from the feature tag set provided by the system and inputs them into the project selector 20. In another embodiment, the text data of the service request is input into an artificial intelligence chat robot program (such as ChatGPT), and the reply text of the program is then disassembled into multiple phrases to match the matching feature tags from the project database 10.

[0027] An example of a service request is as follows: "Goal: Organize a birthday party for a 10-year-old girl who likes strawberries, approximately 20 children aged 8 to 10 and their parents, no peanuts and no chocolate for allergies". An example of a feature tag set is shown in Table 1 below, and an example of a standardized and recommended item is shown in Table 2 below.

[0028] Table 1. Examples of feature label sets.

[0029]

[0030] Table 2. Examples of standardized and recommended items.

[0031] Serial number Standardization Project Recommended Projects 1 Banana Soda 2 Strawberry Ice Cream yes 3 Chocolate Cake … ... …

[0032] The failure rate calculator 30 is used to calculate multiple item failure rates according to multiple historical execution records of the multiple recommended items, calculate multiple retry times corresponding to the multiple recommended items according to the multiple item failure rates, and generate multiple buffer items corresponding to the multiple recommended items according to the multiple retry times.

[0033] In one embodiment, the failure rate calculator 30 calculates the project failure rate based on Bayesian Inference in the following manner:

[0034]

[0035] F adjusted is the project failure rate, which is F prior and F item The weighted sum of F prior F is the intrinsic failure rate of each standardized project in the project database 10, and its default value may be the average of the project failure rates of all standardized projects in the project database 10. item is the average historical failure rate of the recommended items. N item is the historical execution count of the recommended item. N conf is a constant representing the number of times each standardization item needs to be executed before including credibility, and its default value may be the average number of executions of all standardization items in the item database 10 .

[0036] In one embodiment, the failure rate calculator 30 calculates the number of retry times N of each recommended item using the following method 2: redo :

[0037]

[0038] Among them, N Failure is the sum of the failure times of the recommended item itself and the average failure times of the standardized item, N Success It is the sum of the number of successes of the recommended project itself and the average number of successes of the standardized project.

[0039] Examples of recommended items and their failure rates and retry times are shown in Table 3 below.

[0040] Table 3. Examples of recommended items and their failure rates and retry times.

[0041]

[0042] In Table 3, the recommended items are sorted according to the running time of the recommended items, from small to large.

[0043] As shown in Table 3, the expected number of retry times calculated according to Formula 2 will be a floating point number, but in fact the number of executions of the project can only be an integer. Therefore, the failure rate calculator 30 is further used to convert the floating point part of each expected number of retry times into an integer according to a quantization threshold. For example, the example in Table 3 uses a quantization threshold of 0.5, that is, rounding is used to convert the expected number of retry times into a quantized number of retry times.

[0044] As shown in Table 3, if the expected number of retry times for a certain recommended item is greater than 1, its quantized number of retry times must be more than 1. If the expected number of retry times for a certain recommended item is less than 1 and less than the quantized threshold, its quantized number of retry times will be 0. However, for multiple recommended items with the same running time, such as three recommended items with serial numbers 8, 9, and 10, although their respective expected number of retry times is less than 1, the sum of their expected number of retry times is greater than 1 (0.4748+0.3287+0.4976=1.3011>1), it is necessary to add an additional number of retry times for these three recommended items to cope with the situation where any of the three recommended items fails.

[0045] In one embodiment, after calculating the failure rates of multiple items, the failure rate calculator 30 is further used to compare an overall failure rate threshold with each item failure rate to screen recommended items. Taking Table 3 as an example, when the overall failure rate threshold is set to 0.4, recommended items 1, 8, 9, and 10 may be excluded. Whether to exclude recommended items that are higher than the overall failure rate threshold or to exclude recommended items that are lower than the overall failure rate threshold depends on the content of the service request. For example, when the service request is for hardware fault testing, recommended items with high failure rates should be retained to ensure that faulty hardware can be detected.

[0046] In one embodiment, after calculating the failure rates of multiple items, the failure rate calculation can write the failure rates of multiple items back to the historical execution record, thereby updating the average value F of the historical failure rate of each standardized item. item The service provider can also refer to the most recent project failure rate and manually adjust the F of a certain standardized project. prior value.

[0047] In one embodiment, the service plan generation system pre-calculates the project failure rates of all standardized projects in the project database 10 so as to quickly respond to the computing requirements brought by the service request. In another embodiment, when the service plan generation system receives K service requests cumulatively, it recalculates the project failure rates of all current recommended projects and then updates them to the project database 10, where the K value is greater than or equal to 1, which is not limited in this application.

[0048] After the failure rate calculator 30 calculates the quantized retry times, it can generate a plurality of buffer items corresponding to each recommended item. Based on the example values ​​in Table 3, Figure 2 is a schematic diagram of recommended items and buffer items. Figure 2 As shown in , recommended items that use the same resources are arranged in the same column. For example, recommended items 1, 2, and 7 use resource R1 when executed, recommended items 3 and 8 use resource R2 when executed, and recommended items 9 and 10 use resource R3 when executed. Figure 2In the example, the execution period of the buffered items is arranged after the corresponding recommended items. For example, the quantized retry times of recommended item 3 is 4; therefore, recommended item 3 is arranged at running time 0-20, and 4 buffered items 3' are arranged continuously at running time 20-100. In addition, Figure 2 The buffer entry labeled (8,9,10)' in the figure represents the merged buffer entry shared by recommendation items 8, 9 and 10.

[0049] The service scheduler 40 is used to schedule all recommended projects and all buffered projects to generate a service plan. When scheduling, the resource requirements, running time and execution cost of each project are also taken into account so that the total running time and total cost can be presented in the final output service plan. In practice, the service scheduler 40 can use existing scheduling software, such as Siemens Opcenter APS, to optimize the schedule and output a Gantt chart. In addition, Figure 2 It can be regarded as a scheduling result of the service scheduler 40 (the recommended items 4 to 6 are only illustrative items and are not included in the list). Figure 2 middle).

[0050] In one embodiment, after calculating the failure rates of multiple items, the failure rate calculator 30 is further used to calculate the confidence level of the service plan, which is the ratio of the cumulative quantitative rework time to the cumulative expected rework time. An example of calculating the confidence level is shown in Table 4 below.

[0051] Table 4, Example of calculation of confidence level.

[0052]

[0053] In Table 4, the fields such as project running time, expected number of retry times, and quantified number of retry times follow the example of Table 3. The expected retry time is the product of the project running time and the expected number of retry times (such as 20×4.2000=84.0000). The quantified retry time is the product of the project running time and the quantified number of retry times (such as 20×4=80). The cumulative expected retry time is the total expected retry time accumulated from sequence number 1 to the current sequence number (such as 0.8960+21.5370+84.0000≒106.43). The cumulative quantified retry time is the total quantified retry time accumulated from sequence number 1 to the current sequence number (such as 2+40+80=100). Therefore, the confidence level of the service plan including recommended projects 1 to 10 is 250 / 258.38=0.85. The numerical value of the confidence level can allow service providers to include more room for discussion during the negotiation process with customers, such as convincing customers to increase the service cost, informing them of the risk of extending the service schedule, or modifying the service items to meet the cost requirements specified in the service request.

[0054] Figure 3 is a flow chart of a method for generating a service plan according to an embodiment of the present application. The method is executed by a computing device Figure 3 Steps S1 to S9 are shown.

[0055] In step S1, a customer or service provider provides a service request including multiple feature tags, which is then input into the project selector 20 of the service plan generation system. In one embodiment, the service request also includes a cost requirement specified by the customer, such as a total cost of 1 million yuan or a total execution time of three months.

[0056] In step S2 , the item selector 20 selects a plurality of recommended items from a plurality of standardized items in the item database 10 according to a plurality of feature tags.

[0057] In step S3, the failure rate calculator 30 calculates multiple project failure rates according to multiple historical execution records of the multiple recommended projects. In one embodiment, after calculating multiple project failure rates, the failure rate calculator 30 further compares the overall failure rate threshold with each project failure rate to filter the recommended projects.

[0058] In step S4, the failure rate calculator 30 calculates a plurality of retry times corresponding to the plurality of recommended items according to the plurality of item failure rates. In one embodiment, the failure rate calculator 30 converts each retry time from a floating point number to an integer according to a quantization threshold.

[0059] In step S5, the failure rate calculator 30 generates a plurality of buffer items corresponding to the plurality of recommended items according to the plurality of retry times. In one embodiment, it is assumed that the plurality of recommended items include a first item, a second item, and a third item, which respectively correspond to the first retry times, the second retry times, and the third retry times among the plurality of retry times. When the first retry times corresponding to the first item are greater than 1, the failure rate calculator 30 generates a corresponding number of first buffer items according to the first retry times as part of the plurality of buffer items. When the sum of the second retry times corresponding to the second item and the third retry times corresponding to the third item is greater than 1, the failure rate calculator 30 generates a corresponding number of merged buffer items according to the sum as another part of the plurality of buffer items.

[0060] In step S6, the service scheduler 40 performs a schedule based on the multiple recommended items and the multiple buffer items to generate a service plan. In one embodiment, after determining the consumption of resources (such as time, manpower), the service scheduler 40 further calculates the service cost based on the unit price corresponding to each recommended item. In one embodiment, the service plan includes a list of service items, a schedule, a cost estimate, and a confidence level corresponding to the service plan. Before formally submitting it to the customer, additional review checkpoints are required, as shown in step S7.

[0061] In step S7, the service provider conducts an internal review of the service plan. If the internal review passes, the service plan is provided to the customer as the final version. As shown in step S8. On the contrary, if the service plan fails the internal review, or the service cost calculated according to the service plan does not meet the cost requirements specified in the service request, step S9 is executed, and the service provider manually adjusts the overall failure rate threshold, the quantitative threshold or the inherent failure rate of the recommended project, or negotiates with the customer to adjust the cost requirements in the service request (such as raising prices, extending the time schedule), and then returns to step S1 and re-executes the service plan generation method of an embodiment of the present application. Adjusting the overall failure rate threshold can be used to filter out service projects with lower risks. Adjusting the inherent failure rate or quantitative threshold of the recommended project can increase the number of buffer projects when failure occurs, reducing the risk of affecting the overall service quality due to the failure of a certain service project.

[0062] In one embodiment, the service plan generation system further includes: a preprocessing module and a standardized project module. The method for generating standardized projects includes the following steps: analyzing multiple instances in the service record to generate multiple feature labels, generating multiple word frequency scores corresponding to the multiple feature labels as word frequency vectors based on the multiple instances, and performing multiple aggregation procedures. Each aggregation procedure includes: executing a clustering algorithm to divide the multiple feature vectors corresponding to the multiple instances into multiple groups, wherein each feature vector includes a word frequency vector; in each group, analyzing multiple variable parts and a fixed part of the feature vector; outputting the multiple variable parts as a feature label set, and using the fixed part as a group index; when the stop condition of the aggregation procedure is detected, the index generated by the aggregation procedure for the last time is used as a standardized project and stored in the project database 10. The following is a detailed description of each step.

[0063] The preprocessing module analyzes multiple instances in the historical execution records to generate multiple feature tags. In one embodiment, these feature tags include text information (such as task description, hardware configuration), time information (such as date, duration, frequency), risk information (such as failure or success status, difficulty) and related items. In one embodiment, the preprocessing module uses stemming technology.

[0064] Examples of the input (historical execution record) and output (feature label) of the preprocessing module are shown in Table 5 and Table 6 below, respectively. Please refer to Table 5. The historical execution record includes multiple instances and their serial numbers. For the sake of brevity, Table 5 only records the instance name. In one embodiment, in addition to the instance name, Instance 1 also includes a large amount of information such as the production steps, the time and cost required for each step, the probability of production failure, and the equipment required for production. It is also worth noting that the instances in the historical execution record may have erroneous information, for example: Instance 12 is actually the same as Instance 1, but the instance name is mistyped. This situation will be corrected by human intervention in the following steps.

[0065] Table 5. Example of historical execution record.

[0066]

[0067]

[0068] Table 6. Examples of feature labels.

[0069] Feature number Feature Tags 1 banana 2 Birthday 3 blueberry 4 cake 5 cherry 6 chocolate 7 Ice Cream 8 ice 9 lemon 10 milkshake 11 pound 12 strawberry 13 intersect … …

[0070] The standardized project module generates multiple word frequency scores corresponding to the feature labels as multiple word frequency vectors based on the instance. In one embodiment, the word frequency score can adopt TF (term frequency) and tf-idf (termfrequency-inverse document frequency). The execution result using TF is shown in Table 7, where the unmarked fields represent 0 values. Please refer to Table 5 and Table 6. The banana ice cream with actual serial number 1 corresponds to the feature labels of serial numbers 1, 7 and 8; therefore, in Table 7, the word frequency vector of instance serial number 1 is [1 0 0 0 0 0 1 1…]. Please note that using TF and tf-idf for the same instance will generate different word frequency vectors. The numerical range in the word frequency vector can be 0 or 1, or it can be any real number, which depends on the calculation method of the word frequency score. Generally speaking, the larger the word frequency score, the more representative the feature label is.

[0071] Table 7. Examples of word frequency vectors.

[0072]

[0073]

[0074] The standardized item module performs the aggregation process multiple times to output a feature tag set and generate multiple standardized items. Each aggregation process includes the following steps 1 to 6.

[0075] In step 1, the standardized project module executes a clustering algorithm to divide a plurality of feature vectors into a plurality of groups, each feature vector including a plurality of feature dimensions, including at least a word frequency vector. In one embodiment, the feature vector further includes time information, risk information and other information, as shown in Table 8 below. The time information, risk information and other information can be converted into a numerical vector form using a specified conversion mechanism or according to a distribution state. For example: Friday, October 21, 2022 can be converted into a 19-dimensional vector form of [0000100, 000000000100], and the conversion mechanism of this vector is: the seven values ​​on the left correspond to Monday to Sunday (because the example is Friday, the fifth value from the left is 1, and the rest are 0), and the twelve values ​​on the right correspond to January to December (because the example is October, the third to last value is 1, and the rest are 0).

[0076] Table 8. Examples of eigenvectors.

[0077]

[0078] In one embodiment, the clustering algorithm is a hierarchical clustering method. Table 9 is an example of grouping of feature vectors. For simplicity, only the word frequency vectors in the feature vectors are presented, and the numerical values ​​in the vectors are replaced by instance names for easier understanding.

[0079] Table 9. Example of grouping of feature vectors.

[0080]

[0081]

[0082] In step 2, the standardized project module extracts multiple feature vectors in a group and analyzes multiple variable parts and a fixed part of these feature vectors. For the example of Table 9, four feature vectors of group 1 (corresponding to instances 1, 2, 3 and 12, respectively) are first extracted. In one embodiment, the standardized project module uses natural language processing (NLP) technology in artificial intelligence to analyze the same dimensions (such as ice cream) in these feature vectors as the fixed part, and the different dimensions of these feature vectors (such as banana, blueberry, cherry, intersection) as the variable part.

[0083] In step 3, the standardized project module outputs the variable part as a feature label set, and uses the fixed part as the index of the group. Continuing from the previous example, the first feature label set output includes four labels: "banana, blueberry, cherry, intersection". The index of group 1 is "ice cream", and the purpose of the index is to make it easy for people to understand the nature of the group. In one embodiment, the longest identical phrase in the fixed part can be used as a group name that is easy for humans to recognize. If the text part is missing, human intervention can be used to name it. In one embodiment, the system administrator reviews the feature labels output by the system each time, and removes or corrects the wrong labels, such as removing the label "intersection" or correcting it to "banana".

[0084] In step 4, the standardized project module determines whether the analysis of all groups is completed. If it is determined to be yes, step 5 is executed. If it is determined to be no, the module returns to step 1 and selects another group to repeat the process of steps 2 to 4.

[0085] In step 5, the standardization project module determines whether the stopping condition of the aggregation process is detected. If the judgment is yes, execute step 6. If the judgment is no, return to step 1 and regroup the existing groups. Each regrouping will reduce the number of groups. In one embodiment, the stopping condition is that the number of groups is less than a threshold (such as 100 groups), or the similarity between groups is lower than another threshold (such as 0.6). The similarity is calculated, for example, using the Jaccard similarity coefficient or cosine similarity.

[0086] In step 6, the standardized item module stores the index generated by the last aggregation process as a standardized item in the item database 10. For example, in Table 5, after executing the aggregation process multiple times, the instances in Group 2 (pound cake) and Group 3 (birthday cake) may be classified into the same large group, and "cake" is used as the standardized item.

[0087] It is worth noting that common NLP only focuses on the analysis of fixed parts, so after obtaining the fixed parts, the original feature vector is no longer processed. In addition to extracting the fixed parts in the feature vector, this application also needs to extract the variable part as a feature label set output. This application is different from common NLP. This application regroups the feature vector multiple times, outputs the feature label set in each grouping process, and outputs the standardized items based on the final grouping results.

[0088] In summary, the present application proposes a service calculation generation system and method, which can automatically generate a service plan quotation, minimize human intervention, and thus save time and cost. The service plan quotation includes a work item list, a service item operation schedule, and a cost estimate. The customer sends a request containing project information or criteria with a terminal device, and the system reviews the historical execution records to provide a recommended service item list, while estimating the project operation time and considering the risk of failure. Next, a schedule and cost estimate can be established and replied to the customer's device. The effects of the present application are as follows: first, time saving: the above process is not only digital but also automated, so it can save time and increase service flexibility; and second, transparent and adjustable cost estimates: the cost structure can be tracked from the historical execution records displayed item by item, and the service confidence level of this plan can also be displayed. For business negotiations, the recommended cost can still be adjusted to meet the customer's budget, and the selected service confidence level can reflect the risk of this plan.

[0089] Although the present application is disclosed in the above embodiments, it is not intended to limit the present application. Any changes and modifications that do not depart from the spirit and scope of the present application are within the scope of patent protection of the present application. Please refer to the attached claims for the scope of protection defined by the present application.

Claims

1. A method for generating a service plan, characterized in that: Execute on a computing device: Receiving a service request, wherein the service request includes a plurality of characteristic tags; selecting a plurality of recommended items from an item database according to the plurality of feature tags; Calculating multiple project failure rates based on multiple historical execution records of the multiple recommended projects; Calculating a plurality of retry times corresponding to the plurality of recommended items according to the plurality of item failure rates; generating a plurality of buffer items corresponding to the plurality of recommended items according to the plurality of redo times; as well as A scheduling is performed according to the plurality of recommended items and the plurality of buffer items to generate a service plan.

2. The service plan generation method according to claim 1, characterized in that: The generating of a plurality of buffer items corresponding to the plurality of recommended items according to the plurality of redo times comprises: When a first retry count corresponding to the first item is greater than 1, generating a corresponding number of first buffer items according to the first retry count as a part of the plurality of buffer items; and When the sum of the second retry count corresponding to the second item and the third retry count corresponding to the third item is greater than 1, generating a corresponding number of merged buffer items according to the sum as another part of the plurality of buffer items; The first item, the second item and the third item are three of the plurality of recommended items, and the first retry count, the second retry count and the third retry count are three of the plurality of retry counts.

3. The service plan generation method according to claim 1, characterized in that: Also includes: After calculating a plurality of project failure rates according to a plurality of historical execution records of the plurality of recommended projects, an overall failure rate threshold is compared with each of the plurality of project failure rates to screen the plurality of recommended projects.

4. The service plan generation method according to claim 1, characterized in that: The calculating of the number of retry times corresponding to the plurality of recommended items according to the plurality of item failure rates comprises: The plurality of retry times are converted from floating point numbers to integers according to a quantization threshold.

5. The service plan generation method according to claim 4, characterized in that: Also includes: Calculating a service cost according to the service plan; as well as When the service cost does not reach a cost requirement specified in the service request, the service plan generation method as described in request item 1 is re-executed after changing the quantification threshold.

6. A service plan generation system, characterized in that: include: Project database, used to store multiple standardized projects; An item selector, for selecting a plurality of recommended items from the plurality of standardized items in the item database according to a plurality of characteristic tags included in a service request; as well as a failure rate calculator, configured to calculate a plurality of project failure rates according to a plurality of historical execution records of the plurality of recommended projects, calculate a plurality of retry times corresponding to the plurality of recommended projects according to the plurality of project failure rates, and generate a plurality of buffer projects corresponding to the plurality of recommended projects according to the plurality of retry times; as well as The service scheduler is used for performing a schedule according to the plurality of recommended items and the plurality of buffer items to generate a service plan.

7. The service plan generation system according to claim 6, characterized in that: The service scheduler generates a plurality of buffer items corresponding to the plurality of recommended items according to the plurality of redo times, including: When a first retry count corresponding to the first item is greater than 1, generating a corresponding number of first buffer items according to the first retry count as a part of the plurality of buffer items; and When the sum of the second retry count corresponding to the second item and the third retry count corresponding to the third item is greater than 1, generating a corresponding number of merged buffer items according to the sum as another part of the plurality of buffer items; The first item, the second item and the third item are three of the plurality of recommended items, and the first retry count, the second retry count and the third retry count are three of the plurality of retry counts.

8. The service plan generation system according to claim 6, characterized in that: The failure rate calculator is further configured to compare an overall failure rate threshold with each of the plurality of item failure rates to screen the plurality of recommended items after calculating the plurality of item failure rates according to the plurality of historical execution records of the plurality of recommended items.

9. The service plan generation system according to claim 6, characterized in that: The failure rate calculator calculates the number of retry times corresponding to the plurality of recommended items according to the plurality of item failure rates, including: The plurality of retry times are converted from floating point numbers to integers according to a quantization threshold.

10. The service plan generation system according to claim 9, characterized in that: The service scheduler further calculates a service cost according to the service plan; and The service calculation generation system is further configured to modify the quantization threshold to operate again when the service cost does not reach a cost requirement specified in the service request.

Images