Enterprise project schedule deviation attribution scheduling method and system

Abstract

The application discloses a kind of enterprise project schedule deviation attribution scheduling method and system, it is related to computer data processing and project schedule management technical field, for solving the problem that existing project management system only according to upstream delivery version change or task dependency relationship overall judgment downstream task is influenced, partial achievement failure is easily mistaken for downstream task execution delay;The method obtains the version difference information of upstream delivery and the input consumption information of downstream achievement, judges whether version change influences downstream achievement;When corresponding failure event occurs in downstream achievement, determine the failure processing segment, and correct schedule deviation according to this, generate scheduling instruction;The application can improve the accuracy of schedule deviation attribution, reduce task over-rearrangement and scheduling misplacement.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method and system for attributing and scheduling project schedule deviations. Background Technology

[0002] Enterprise projects typically consist of multiple tasks with dependencies. Deliverables from upstream tasks, such as solution documents, design drawings, interface documents, bills of materials, test cases, approval materials, requirement specifications, parameter configuration tables, or code files, often serve as input for downstream tasks to generate deliverables. Existing project management systems can usually record task plans, task status, deliverable versions, and actual task progress, and can generate schedule deviations based on the difference between planned and actual times. When upstream deliverables undergo version changes, the system can also mark the relevant downstream tasks as pending updates, pending confirmation, or requiring reprocessing based on the version number, task dependencies, or process status.

[0003] However, existing methods typically treat tasks, deliverables, or versions as a whole for evaluation. When an upstream deliverable is updated from a base version to a newer version, the system often only checks whether the upstream version has changed or whether a downstream task depends on the upstream deliverable, without further identifying whether the specific changes have already been used by a downstream outcome. For the same upstream deliverable, different downstream outcomes may only use a portion of its input content. If the new version only changes content that has not been used by a downstream outcome, then that downstream outcome may not necessarily need to be redone. Only if the changes made by the new version are actually used by the downstream outcome will the corresponding processing segment become invalid.

[0004] Therefore, existing technologies still have the following problems: after an upstream deliverable undergoes a version change, they cannot combine version difference information with the input consumption information corresponding to the downstream results to accurately identify whether the downstream results have truly been affected by the version change; they cannot determine the failure handling segment when a failure event corresponding to the upstream deliverable version change occurs in the downstream results; and they cannot attribute and correct the progress deviation of the downstream tasks based on this failure handling segment. As a result, the system can easily misjudge the local result failure caused by the upstream deliverable version change as low execution efficiency of the downstream tasks, thus leading to inaccurate deviation attribution, excessive task rescheduling, and misaligned scheduling measures. Summary of the Invention

[0005] This application provides a method and system for attributing and scheduling project schedule deviations. After an upstream deliverable undergoes a version change, it first determines whether the version difference content matches the input content of the upstream deliverable actually consumed by downstream results. Then, it determines a failure handling segment based on the retracement relationship between failure events and the difference content, and uses this failure handling segment to attribute and correct the schedule deviations of downstream tasks. The technical solution is as follows: On the one hand, a method for attributing and scheduling project schedule deviations is provided. The method includes: acquiring version difference information of upstream deliverables in the project, where the version difference information characterizes the differences in content between different versions of the upstream deliverables; acquiring input consumption information corresponding to downstream results that depend on the upstream deliverables, where the input consumption information characterizes the upstream deliverable input content actually used when the downstream results are generated; determining, based on the version difference information and the input consumption information, whether the difference content matches the upstream deliverable input content actually used by the downstream results; if it is determined that the difference content matches the upstream deliverable input content actually used by the downstream results, and a failure event occurs in the downstream results pointing back to the difference content, determining the failure handling segment corresponding to the downstream results; performing attribution correction on the schedule deviation of the downstream tasks to which the downstream results belong, based on the failure handling segment, and generating scheduling instructions based on the attribution correction results.

[0006] In one possible implementation, obtaining version difference information of upstream deliverables in an enterprise project includes: obtaining a baseline version and an updated version of the upstream deliverable, wherein the baseline version refers to the version of the upstream deliverable referenced when the downstream result is generated, and the updated version refers to the submitted, confirmed, frozen, or released version of the upstream deliverable after the downstream result is generated; parsing the baseline version and the updated version into content units according to the deliverable type of the upstream deliverable; comparing the content units of the baseline version and the content units of the updated version to obtain a set of difference content, and determining the version difference information based on the set of difference content.

[0007] In one possible implementation, the content unit includes at least one of fields, parameters, paragraphs, code blocks, drawing objects, table units, list items, interface items, or approval items; at least one of content identifiers, content locations, or content summaries is used as the comparison basis to identify newly added, deleted, or changed content units as differing content.

[0008] In one possible implementation, obtaining the input consumption information corresponding to the downstream result that depends on the upstream deliverable includes: obtaining the upstream deliverable input content actually used when the downstream result is generated by using at least one of system log-based acquisition, result submission-bound acquisition, or content matching acquisition; and generating the input consumption information based on at least one of the content identifier, content location, content summary, version identifier, or consumption time of the upstream deliverable input content.

[0009] In one possible implementation, determining whether the differing content matches the upstream deliverable input content actually used by the downstream result, based on the version difference information and the input consumption information, includes: extracting the differing content from the version difference information and extracting the consumed input content from the input consumption information; matching the differing content and the consumed input content in the order of content identifier consistency, content position consistency, preset correspondence match, and preset association match; and determining that the differing content matches the upstream deliverable input content actually used by the downstream result when any one of the following conditions is met: content identifier consistency, content position consistency, preset correspondence match, or preset association match.

[0010] In one possible implementation, the preset correspondence includes at least one of the following: correspondence between interface fields and code variables, correspondence between bill of materials items and purchase requisition items, correspondence between drawing objects and construction list objects, or correspondence between approval items and execution conditions; the preset association includes at least one of the following: synonym relationship, parent-child relationship, inheritance relationship, reference relationship, or computational dependency relationship; the preset correspondence or the preset association is determined by at least one of the following: project template, deliverable structure tree, interface dependency table, material association table, drawing object relationship table, or administrator configuration.

[0011] In one possible implementation, the downstream result experiencing a failure event that refers back to the differing content includes: obtaining the result status change record of the downstream result, the result status change record including at least one of result withdrawal record, result overwrite record, result redo record, result return record, result resubmission record, or result modification record; if the reason information of the result status change record involves the differing content, or if the result modification content after the result status change record involves the hit consumed input content, then it is determined that the downstream result has experienced a failure event that refers back to the differing content.

[0012] In one possible implementation, the extent of the result modification represented by the result modification record is determined by the content difference ratio, which satisfies: R = Cd / Ct; where R represents the content difference ratio, Cd represents the number of difference result units that have been added, deleted, replaced, or have undergone content changes between the first result content and the second result content, and Ct represents the total number of result units contained in the first result content. The first result content refers to the downstream result content before the failure event occurs, and the second result content refers to the downstream result content after the failure event occurs. When the content difference ratio R reaches a preset modification ratio threshold, and the difference result unit corresponds to the hit difference content, it is determined that the extent of the result modification corresponding to the result modification record has reached the preset condition.

[0013] In one possible implementation, determining the failure handling segment corresponding to the downstream result includes: determining the moment when the downstream result first consumes the upstream deliverable input content that was hit as the start point of the failure handling segment, and determining the failure confirmation moment of the failure event as the end point of the failure handling segment; if the moment when the upstream deliverable input content that was hit was not recorded, then the start processing moment or the result submission moment of the downstream result is determined as the start point of the failure handling segment.

[0014] In one possible implementation, the step of attributing and correcting the schedule deviation of the downstream task to which the downstream result belongs based on the failure handling segment, and generating scheduling instructions based on the attribution correction result, includes: when there are multiple failure handling segments, first merging the overlapping time periods among the multiple failure handling segments to obtain a merged failure handling segment set; then determining the failure attribution deviation duration based on the merged failure handling segment set; determining the corrected execution duration based on the actual execution duration and the failure attribution deviation duration; then determining the corrected schedule deviation based on the corrected execution duration and the planned execution duration; when the cause information of the failure event clearly points to the quality defects of the downstream result itself, human error, new customer requirements, or changes in approval strategies, the failure handling segment is not attributed to the upstream deliverable version change affecting the downstream result; finally, generating scheduling instructions based on the corrected schedule deviation.

[0015] On the other hand, an enterprise project schedule deviation attribution scheduling system is provided. The system includes: a deviation acquisition module, used to acquire version deviation information of upstream deliverables in an enterprise project; a consumption acquisition module, used to acquire input consumption information corresponding to downstream results that depend on the upstream deliverables; a hit determination module, used to determine whether the deviation content hits the input content of the upstream deliverable actually used by the downstream result based on the version deviation information and the input consumption information; a segment determination module, used to determine the failure handling segment corresponding to the downstream result when it is determined that the deviation content hits the input content of the upstream deliverable actually used by the downstream result, and the downstream result has experienced a failure event that points back to the deviation content; and an attribution scheduling module, used to perform attribution correction on the schedule deviation of the downstream task to which the downstream result belongs based on the failure handling segment, and generate scheduling instructions based on the result of the attribution correction.

[0016] The enterprise project schedule deviation attribution and scheduling scheme provided in this application does not simply determine whether downstream tasks are affected based on whether upstream deliverables have undergone version changes or whether downstream tasks depend on these upstream deliverables. Instead, it combines version difference information of upstream deliverables with input consumption information corresponding to downstream results to determine whether the version difference content matches the upstream deliverable input content actually used by the downstream results. When a failure event occurs in the downstream results that refers back to the difference content, it identifies the failure handling segment. Thus, it can distinguish the failure handling segment caused by upstream deliverable version changes from the execution deviation of downstream tasks, thereby improving the accuracy of schedule deviation attribution and scheduling instruction generation.

[0017] In one possible implementation, this application does not simply determine whether downstream tasks will be affected based on version changes of upstream deliverables or dependencies between tasks. Instead, it first examines the differences in the version difference information to see if they match the upstream deliverable inputs actually consumed by the downstream results. Then, it checks whether the failure events generated by the downstream results point back to those matched differences. Only when a continuous correspondence of "matched difference content - failure event backlink - failure handling fragment determination" is formed can the failure handling fragment be used to attribute and correct the progress deviation of downstream tasks. In this way, the risk of incorrect attribution caused by quality defects in downstream results, human error, new customer requirements, and changes in approval strategies can be reduced.

[0018] If the difference content in the version difference information does not match the input content of the upstream deliverable actually consumed by the downstream result, or if the failure event occurs before the updated version of the upstream deliverable is formed, or if the cause information of the failure event points to downstream result quality defects, human error, new customer requirements, changes in approval strategies, personnel delays, or resource occupation, the processing segment corresponding to the failure event will not be determined as a failure processing segment caused by the version change of the upstream deliverable. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram of the implementation environment for an enterprise project schedule deviation attribution and scheduling method provided in an embodiment of this application; Figure 2 This is a flowchart of an enterprise project schedule deviation attribution and scheduling method provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating a process for matching version difference information and input consumption information, as provided in an embodiment of this application. Figure 4 This is a schematic diagram of a failure handling segment determination process provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an enterprise project schedule deviation attribution scheduling system provided in an embodiment of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings; it should be understood that the terms "first", "second", etc. used herein are only used to distinguish one concept from another and should not be construed as limiting the order or quantity.

[0022] Figure 1This is a schematic diagram of an implementation environment provided in an embodiment of this application; the implementation environment includes a project management server, a deliverable version repository, a result record repository, a task status repository, and a task execution terminal; the project management server can be connected to the deliverable version repository, the result record repository, the task status repository, and the task execution terminal via a wired or wireless network; the deliverable version repository is used to store version data of each deliverable in the enterprise project; the result record repository is used to store downstream results and their input consumption information; the task status repository is used to store task plans, task status, processing records, and result status change records; the task execution terminal is used to receive scheduling instructions and display them to the person in charge of the task.

[0023] Optionally, the project management server can be a standalone server, a server cluster, a cloud server, or a computer device with project management programs deployed; this application embodiment does not limit the specific type of project management server.

[0024] Figure 2 This is a flowchart illustrating an enterprise project schedule deviation attribution and scheduling method provided in this application embodiment; this application embodiment is executed by a computer device, which can be a project management server; see also Figure 2 The method includes the following steps: S201. Computer equipment acquires version difference information of upstream deliverables in enterprise projects; Upstream deliverables refer to project output documents or project data referenced by one or more downstream tasks; for example, upstream deliverables can be solution documents, design drawings, interface documents, bills of materials, test cases, approval materials, requirements specifications, parameter configuration tables, or code files, etc.; version difference information is used to characterize the differences in upstream deliverables between different versions.

[0025] Optionally, the computer equipment obtains the baseline version and the updated version of the upstream deliverable, compares the content differences between the baseline version and the updated version to obtain a set of differences, and determines the version difference information based on the set of differences; the baseline version is the version of the upstream deliverable referenced when the downstream result is generated, and the updated version is the submitted version, confirmed version, frozen version or published version of the upstream deliverable after the downstream result is generated.

[0026] Optionally, the computer device invokes the corresponding content parser based on the type of deliverable to parse the baseline version and the updated version into comparable content units. For text documents, content units can be title numbers, paragraph numbers, fields, or paragraph content. For interface documents, content units can be interface names, request fields, return fields, error codes, or authentication parameters. For drawing files, content units can be drawing object numbers, layers, coordinates, dimension parameters, or installation locations. For tables or lists, content units can be row identifiers, column identifiers, cell values, or list item numbers. For code files, content units can be function names, interface call statements, configuration items, or code block summaries. For approval materials, content units can be approval nodes, approval objects, approval item numbers, or approval conclusions.

[0027] Optionally, the computer device uses the content identifier, content location, or content summary of the content unit as a comparison basis to determine the content unit that has been added, deleted, or whose content has changed between the baseline version and the updated version, and identifies the content unit as the difference content; the difference content may include at least one of fields, parameters, paragraphs, code blocks, drawing objects, table units, list items, interface items, or approval items.

[0028] S202. Computer equipment acquires input consumption information corresponding to downstream results that depend on upstream deliverables; Downstream deliverables refer to the results generated during the execution of downstream tasks; for example, downstream deliverables may be quotations, development code, construction preparation lists, test scripts, implementation plans, procurement requests, configuration files, or acceptance reports, etc.; input consumption information is used to characterize the upstream deliverables input content actually used when downstream deliverables are generated.

[0029] Optionally, the input consumption information can be generated through at least one of the following methods: system log-based acquisition, result submission-bound acquisition, or content matching acquisition.

[0030] In the system log-based acquisition method, when a downstream task opens, reads, calls, imports, references, parses, copies, or downloads upstream deliverable input content through the project platform, the project platform records the content identifier, content location, content summary, version identifier, and consumption time of the upstream deliverable input content used.

[0031] In the deliverable submission-bound acquisition method, when a downstream deliverable is submitted to the project platform, the project platform receives the binding relationship between the downstream deliverable and the upstream deliverable version and the upstream deliverable input content it references, and generates input consumption information based on the binding relationship.

[0032] In the content matching acquisition method, the project platform performs content identifier matching, content summary matching, or text similarity matching on the downstream deliverables and the upstream deliverables to identify interface fields, material numbers, drawing object numbers, approval item numbers, or parameter names appearing in the downstream deliverables, and generates input consumption information based on the identification results.

[0033] It is important to note that input consumption information differs from declarative dependencies of downstream tasks on upstream deliverables. Declarative dependencies only indicate that a downstream task depends on a certain upstream deliverable in the process, while input consumption information is used to characterize the specific upstream deliverable input content actually used by the downstream output during the generation process. That is, only when the downstream output reads, calls, references, parses, imports, binds, copies, or is identified by content matching as using a certain upstream deliverable content unit is that content unit recorded as consumed input content. In this way, it is possible to avoid directly identifying the entire downstream task as an affected task simply because a task-level dependency exists.

[0034] Optionally, the input consumption information includes at least one of the following: result identifier, downstream task identifier, upstream deliverable identifier, upstream deliverable version identifier, consumed input content identifier, consumed input content location, consumed input content summary, consumption method, and consumption time; wherein, the consumption method is used to indicate that the consumed input content was used by the downstream result through reading, calling, referencing, parsing, importing, binding, copying, or content matching; the project management server can establish the actual consumption relationship between the downstream result and the upstream deliverable content unit based on the above information.

[0035] For example, during the process of generating code deliverables in a development task, the computer equipment records the interface fields, interface document versions, and reference times referenced by the code deliverables; during the process of generating a purchase requisition in a procurement task, the computer equipment records the bill of materials items, bill of materials versions, and reference times read by the purchase requisition; during the process of generating a construction list in a construction preparation task, the computer equipment records the drawing objects, drawing versions, and reference locations referenced by the construction list.

[0036] S203. Computer equipment, based on version difference information and input consumption information, determines whether the difference content matches the upstream deliverable input content actually used by the downstream results; Optionally, the computer device extracts the difference content from the version difference information and extracts the consumed input content from the input consumption information; when the difference content is the same as the consumed input content, or when the difference content and the consumed input content satisfy a preset correspondence or preset association relationship, it is determined that the difference content matches the upstream deliverable input content actually used by the downstream results.

[0037] Optionally, the computer device may make the following judgments in the following order: First, determine whether the content identifier of the difference content is consistent with that of the consumed input content; if they are inconsistent, determine whether the content position of the difference content is consistent with that of the consumed input content; if they are still inconsistent, query the preset content mapping table to determine whether the difference content and the consumed input content satisfy a preset correspondence or preset association relationship; if any of the above conditions are met, determine that the difference content matches the upstream deliverable input content actually used by the downstream results.

[0038] Optionally, the computer device performs layered matching on the difference content and the consumed input content. The first layer of matching is content identifier matching. If the field name, parameter name, material number, drawing object number, interface item number, or approval item number in the difference content is consistent with the identifier corresponding to the consumed input content, then it is determined that the difference content matches the consumed input content. The second layer of matching is content location matching. If the content location of the difference content in the deliverable is consistent with the location recorded in the consumed input content, then it is determined that the difference content matches the consumed input content. The content location mentioned here includes at least one of the following: field path, table row and column position, drawing layer and coordinate position, paragraph number, or code block position. The third layer of matching is preset correspondence matching. When there is a correspondence between the difference content and the consumed input content in the preset content mapping table, it is determined that the difference content matches the consumed input content. The fourth layer of matching is preset association matching. If there is a synonym relationship, parent-child relationship, inheritance relationship, reference relationship, or computational dependency relationship between the difference content and the consumed input content, then it is determined that the difference content matches the consumed input content.

[0039] Optionally, the preset content mapping table includes source content identifier, target content identifier, relationship type, source deliverable type, target result type, and effective status; the relationship type includes at least one of field variable correspondence, list item correspondence, drawing object correspondence, approval item execution condition correspondence, reference relationship, and calculation dependency relationship; the preset content mapping table can be generated using project templates, deliverable structure trees, interface dependency tables, material association tables, drawing object relationship tables, approval process configurations, or administrator configurations; when performing matching, the computer equipment will prioritize content identifier matching and content location matching; only if there is no direct match will the preset content mapping table be called to perform correspondence or association matching.

[0040] Optionally, the computer equipment performs hierarchical matching of the discrepancy content and the consumed input content. The first layer of matching is content identifier matching; when the field name, parameter name, material number, drawing object number, interface item number, approval item number, or code block identifier of the discrepancy content matches the corresponding identifier of the consumed input content, it is determined that the discrepancy content matches the consumed input content; the second layer of matching is content location matching. When the content location of the discrepancy content in the upstream deliverable matches the location of the consumed input content record, it is determined that the discrepancy content matches the consumed input content, wherein the content location includes at least one of the following: field path, table row and column position, drawing layer and coordinate position, paragraph number, list item position, or code block position.

[0041] The third layer of matching is a preset correspondence matching; when a correspondence exists between the difference content and the consumed input content in the preset content mapping table, the difference content is determined to match the consumed input content. The preset correspondence includes at least one of the following: correspondence between interface fields and code variables, correspondence between bill of materials items and purchase requisition items, correspondence between drawing objects and construction list objects, and correspondence between approval items and execution conditions. The fourth layer of matching is a preset association relationship matching. When a synonym relationship, parent-child relationship, inheritance relationship, reference relationship, or computational dependency exists between the difference content and the consumed input content, the difference content is determined to match the consumed input content.

[0042] Optionally, the preset content mapping table includes source content identifier, target content identifier, relationship type, source deliverable type, target result type, effective status, and configuration source; the configuration source includes at least one of project template, deliverable structure tree, interface dependency table, material association table, drawing object relationship table, approval process configuration, or administrator configuration; when the computer device performs matching, it prioritizes content identifier matching and content location matching; if no direct match is found, the preset content mapping table is then called to perform preset corresponding relationship or preset association relationship matching.

[0043] The preset correspondence can include the correspondence between interface fields and code variables, the correspondence between bill of materials items and purchase requisition items, the correspondence between drawing objects and construction list objects, or the correspondence between approval items and execution conditions; the preset association can include synonym relationships, parent-child relationships, inheritance relationships, reference relationships, or computational dependency relationships; the preset content mapping table can be generated from project templates, deliverable structure trees, interface dependency tables, material association tables, drawing object relationship tables, or administrator configuration.

[0044] For example, if a returned field in an upstream interface document changes, and the input consumption information of a downstream code deliverable indicates that the code deliverable has already used that returned field, then the difference content corresponding to that returned field is determined to match the upstream deliverable input content actually used by the code deliverable; if an equipment number in an upstream drawing changes, and the downstream construction list has already referenced that equipment number, then the difference content corresponding to that equipment number is determined to match the upstream deliverable input content actually used by the construction list.

[0045] See Figure 3 The computer equipment can first compare the content differences between the baseline version and the updated version of the upstream deliverable to obtain version difference information or difference content; at the same time, the computer equipment obtains the input consumption information generated during the downstream result generation process to obtain the consumed input content actually used by the downstream result; the computer equipment matches the difference content with the consumed input content, and when the two are the same, or satisfy the preset correspondence relationship or preset association relationship, it determines that the difference content matches the upstream deliverable input content actually used by the downstream result.

[0046] S204. When it is determined that the discrepancy content matches the upstream deliverable input content actually used by the downstream result, and a failure event occurs in the downstream result pointing back to the discrepancy content, the computer equipment determines the failure processing segment corresponding to the downstream result; Among them, failure events are used to characterize that downstream results cannot continue to be used as valid results after the version of upstream deliverables changes, or need to be reconfirmed, resubmitted, regenerated or reprocessed; failure events may include at least one of the following: result withdrawal, result overwriting, result redoing, result return, result resubmission, or result modification reaching a preset condition.

[0047] Optionally, the failure event references the hit difference content, meaning there is an identifiable correspondence between the failure event and the consumed input content that has been hit by the version difference information. The computer device can determine the reference relationship based on the cause information of the failure event, the modified content of the result, the record of the change in the result status, or the review comments. If the return reason, withdrawal reason, redo explanation, review comments, audit comments, or task log includes the content identifier, content location, field name, object number, list item number, or interface item number of the hit difference content, then it is determined that the failure event references the hit difference content.

[0048] Optionally, if the modifications made to the deliverables after the failure event involve the consumed input content that was hit, or if there is a pre-defined correspondence or association between the failed deliverable unit and the hit difference content, then the failure event will be determined to point back to the hit difference content. For example, if the returned fields of the upstream interface document change, and the downstream code deliverable modifies the corresponding code variables after being returned, then the return event will be determined to point back to the hit difference content. Or, for example, if the material model in the upstream bill of materials changes, and the downstream purchase requisition modifies the corresponding purchase requisition items after being resubmitted, then the resubmission event will be determined to point back to the hit difference content.

[0049] To avoid misattributing returns, withdrawals, or redoes unrelated to changes in upstream deliverable versions to upstream causes, the computer equipment also determines whether the failure event points back to the difference content. Optionally, if the cause information in the result status change record involves the difference content, or if the result modification content after the result status change record involves the consumed input content that was hit, then it is determined that a failure event pointing back to the difference content has occurred in the downstream result. The cause information can come from the return reason, withdrawal reason, redo instructions, review comments, audit comments, or task log.

[0050] Optionally, the preset modification percentage threshold can be determined based on the deliverable type, project type, or historical return records. For example, for text-based deliverables, the preset modification percentage threshold can be set to 10% to 30%; for code-based deliverables, the preset modification percentage threshold can be set to 5% to 20%; for list-type or table-type deliverables, the preset modification percentage threshold can be set to the proportion of the number of modified rows or cells to the total number of rows or cells reaching 10% to 25%. The above thresholds are just examples, and the project management server can dynamically adjust them based on the modification records of deliverables that have been confirmed as invalid in historical projects.

[0051] Optionally, the failure event references the hit difference content, meaning there is an identifiable correspondence between the failure event and the consumed input content that has been hit by the version difference information. The computer equipment can determine the reference relationship based on the cause information of the failure event, the modified content of the result, the record of the change in the result status, the review comments, the audit comments, or the task log. If the return reason, withdrawal reason, redo explanation, review comments, audit comments, or task log contains the content identifier, content location, field name, object number, list item number, or interface item number of the hit difference content, then the failure event references the hit difference content.

[0052] Optionally, if the modified content of the result after the failure event involves the consumed input content that was hit, or if there is a preset correspondence or preset association between the failed result unit and the hit difference content, then the failure event is determined to refer back to the hit difference content. For example, if the returned field of the upstream interface document changes, and the downstream code result modifies the code variable corresponding to the returned field after being returned, then the return event is determined to refer back to the hit difference content. Or, for example, if the material model in the upstream bill of materials changes, and the downstream purchase application modifies the corresponding purchase application item after being resubmitted, then the resubmission event is determined to refer back to the hit difference content.

[0053] Optionally, the computer device can also determine whether a failure event meets the conditions for referencing back by combining the time sequence; if the failure event occurs after the upstream deliverable update version is formed, and the cause information, result modification content, or status change record of the failure event points to the hit difference content, then it is determined that the failure event refers back to the hit difference content; if the failure event occurs before the upstream deliverable update version is formed, it is not determined that the failure event refers back to the difference content in the update version.

[0054] Optionally, if there are both upstream deliverable version change reasons and non-version change reasons, the computer equipment can determine the attribution result based on the cause priority. The cause priority may include: manually confirmed non-version reasons take precedence over automatically identified version change reasons; clearly identified quality defect reasons take precedence over content hit reasons; when the failure event cause information directly points to the hit difference content, version change reasons take precedence over ordinary delay reasons. Through the above misattribution elimination judgment, it is possible to avoid attributing ordinary task delays, quality returns, or new requirement errors to upstream deliverable version changes.

[0055] Optionally, the extent of modification of the deliverable reaches a preset condition, including: obtaining the first deliverable content before the failure event and the second deliverable content after the failure event; breaking down the first and second deliverable contents into deliverable units, which can be fields, paragraphs, code blocks, drawing objects, table units, list items, or configuration items; counting the number of deliverable units that are added, deleted, replaced, or have changed content to obtain the number of differential deliverable units; determining the content difference ratio based on the ratio between the number of differential deliverable units and the total number of deliverable units contained in the first deliverable content; and determining that the extent of modification of the deliverable has reached the preset condition when the content difference ratio reaches a preset modification ratio threshold and the differential deliverable unit corresponds to the upstream differential content that was hit.

[0056] Optionally, the preset modification percentage threshold can be determined based on the deliverable type, project type, or historical rollback records. For example, for text deliverables, the preset modification percentage threshold can be set to 10% to 30%; for code deliverables, the preset modification percentage threshold can be set to 5% to 20%; for list or table deliverables, the preset modification percentage threshold can be set to 10% to 25% of the total number of rows or cells modified. The thresholds mentioned above are just examples, and the project management server can dynamically adjust them based on the modification records of deliverables that have been confirmed as invalid in historical projects. Optionally, the starting point of a failure handling segment will be preferentially selected from the moment when the downstream deliverable first consumes the input content of the upstream deliverable that was hit; if no first consumption moment is recorded, then the moment when the downstream deliverable begins processing will be selected; if no start processing moment is recorded, then the moment when the downstream deliverable is first submitted will be selected; the ending point of a failure handling segment will be preferentially selected from the moment of failure event confirmation; if the moment of failure event confirmation is missing, then the moment when the result is withdrawn, overwritten, redone, returned, resubmitted, or a high proportion of modification record is formed will be selected; if there is overlap between multiple failure handling segments, the computer device will first merge the overlapping parts and then calculate the duration of failure attribution bias.

[0057] Optionally, the content difference ratio R satisfies: R=Cd / Ct; where R represents the content difference ratio; Cd represents the number of difference result units between the first result content and the second result content that have been added, deleted, replaced or changed; Ct represents the total number of result units contained in the first result content; the preset modification ratio threshold can be set according to the project type, result type or historical return records, for example, it can be set to 20%, 30% or other ratios.

[0058] Optionally, the computer equipment acquires the processing records and status change records of downstream results, determines the moment when the downstream result first consumes the input content of the upstream deliverable that was hit based on the processing records, determines the failure confirmation moment of the failure event based on the status change records, and defines the time segment between the moment when the input content of the upstream deliverable that was first consumed and the failure confirmation moment as the failure processing segment; if the moment when the first consumption was not recorded, the start time of processing of the downstream result is taken as the starting point of the failure processing segment; if the system only records the submission time of the result, the submission time of the result is taken as the starting point of the failure processing segment; the failure confirmation moment can be the moment when the record of withdrawal, overwriting, redoing, return, resubmission, or the result modification reaches the preset conditions is formed.

[0059] For example, if the interface documentation modifies the return field in an updated version, and the downstream code consumes the return field for the first time at the first moment, and is rejected at the third moment due to the change in the return field, and the reason for the rejection includes the return field or the relevant interface name, then the computer device will determine the time segment between the first moment and the third moment as the failure processing segment of the code.

[0060] Optionally, the starting point of the failure handling segment is preferentially adopted as the moment when the downstream result first consumes the input content of the upstream deliverable that was hit; if the moment of first consumption is not recorded, the moment when the downstream result begins processing is adopted; if the moment of start processing is not recorded, the moment when the downstream result is first submitted is adopted; the ending point of the failure handling segment is preferentially adopted as the moment when the failure event is confirmed; if the moment when the failure event is confirmed is missing, the moment when the record is formed when the result is withdrawn, the result is overwritten, the result is redone, the result is returned, the result is resubmitted, or the result modification reaches the preset condition is adopted; through the above start and end boundary rules, the computer equipment can determine the computable failure handling segments at different record granularities.

[0061] Optionally, if the same downstream task corresponds to multiple downstream results, or the same downstream result corresponds to multiple failure events, the computer device determines the candidate failure processing segment corresponding to each failure event respectively; for candidate failure processing segments with time overlap, the computer device first merges the overlapping parts and then calculates the failure attribution bias duration; for candidate failure processing segments that fail to pass the misattribution exclusion judgment, the computer device does not include them in the failure attribution bias duration.

[0062] See Figure 4 The failure handling segment is not obtained directly from any failure event in the downstream result, but is determined after the difference content hits the consumed input content, the failure event points back to the hit difference content and the misattribution exclusion rule is not triggered. Figure 4 In this context, t1 represents the moment when the downstream deliverable first consumes the upstream deliverable input content that was hit, and t2 represents the moment when the failure event is confirmed. The time segment between t1 and t2 is the failure processing segment. If t1 or t2 is missing, the computer equipment can determine the start and end points of the failure processing segment according to the above-mentioned alternative boundary rules. The computer equipment can determine the moment t1 when the downstream deliverable input content was first consumed based on the processing record of the downstream deliverable, and determine the failure confirmation moment t2 of the failure event based on the deliverable status change record. If the failure event refers back to the hit difference content, the computer equipment will determine the time segment between t1 and t2 as the failure processing segment. Thus, the system can distinguish the failure processing segment from the normal execution time of the downstream task and use it for subsequent schedule deviation attribution correction.

[0063] S205. The computer equipment performs attribution correction on the schedule deviation of the downstream tasks to which the downstream results belong based on the failure handling segment, and generates scheduling instructions based on the attribution correction results; Among them, schedule deviation can be the difference between the actual execution time and the planned execution time of a downstream task, or the difference between the actual completion time and the planned completion time of a downstream task; attribution correction is used to distinguish the deviation cause corresponding to the failure handling segment from the execution cause of the downstream task itself, and reattribute it to the impact of the upstream deliverable version change on the downstream result.

[0064] Optionally, if there are multiple failure handling segments, the computer device first merges the overlapping time periods in the multiple failure handling segments to obtain a merged set of failure handling segments; determines the failure attribution deviation duration based on the merged set of failure handling segments; determines the corrected execution duration based on the actual execution duration and the failure attribution deviation duration; and determines the corrected schedule deviation based on the corrected execution duration and the planned execution duration.

[0065] Optionally, the computer equipment generates scheduling instructions based on the failure handling fragment, the status of the affected deliverables, and the consumption status of subsequent tasks. When the affected downstream deliverables are still in a modifiable state and have not yet been consumed by subsequent tasks, a partial redo instruction is generated. This partial redo instruction instructs the responsible party to modify only the deliverable units corresponding to the hit discrepancies. When the affected downstream deliverables have been submitted but it has not yet been confirmed whether a redo is necessary, a deliverable review instruction is generated. This deliverable review instruction instructs the reviewer to confirm whether the failure event has been reflected back to the hit discrepancies. When the affected downstream deliverables have been consumed by subsequent tasks, an affected task postponement instruction is generated. This affected task postponement instruction is used to adjust the planned time of subsequent tasks that continue to depend on the deliverables.

[0066] Optionally, when the duration of the failure attribution deviation reaches a preset duration threshold, or when the difference between the corrected schedule deviation and the original schedule deviation reaches a preset deviation threshold, an execution baseline reset instruction will be generated. The preset duration threshold mentioned above can be 4 hours, 1 working day, or a preset percentage of the project's planned execution time. The preset deviation threshold mentioned above can be 10% to 30% of the planned execution time. When the version difference originates from unconfirmed, pending, or unfrozen upstream deliverable versions, an upstream deliverable confirmation instruction will be generated to prompt the upstream responsible party to confirm whether this updated version can be used as the basis for the continued execution of downstream tasks.

[0067] Optionally, the scheduling instruction includes the instruction type, target result identifier, target task identifier, associated upstream deliverable identifier, associated upstream deliverable version, hit difference content identifier, failure event identifier, start and end times of the failure handling segment, triggering reason, responsible party, and execution period; the project management server will send the scheduling instruction to the task execution end, and display the reason for the deviation attribution and the corresponding handling suggestions on the task execution end.

[0068] Optionally, the corrected execution duration Tcorr satisfies: Tcorr = Tact - Tinv; the corrected schedule deviation Dcorr satisfies: Dcorr = Tcorr - Tplan; where Tcorr represents the corrected execution duration; Tact represents the actual execution duration of the downstream task, which can be the time between the actual completion time and the actual start time of the downstream task; Tinv represents the failure attribution deviation duration, which is the total duration after merging one or more failure handling segments; Tplan represents the planned execution duration of the downstream task; and Dcorr represents the corrected schedule deviation.

[0069] Optionally, Tinv only includes the duration of failure handling segments that simultaneously meet the following conditions: the difference content in the version difference information matches the upstream deliverable input content actually consumed by the downstream result; the failure event refers back to the matched difference content; the failure handling segment is not excluded by the misattribution exclusion rule; if any condition is not met, the corresponding handling segment is not included in Tinv; through this limitation, the correction execution time Tcorr can be reduced only for failure handling segments caused by changes in the upstream deliverable version, without reducing the time consumed by normal execution, downstream quality defects, or human resource reasons.

[0070] Optionally, the corrected schedule deviation Drorr is used to distinguish between the execution deviation of downstream tasks themselves and the attribution deviation of upstream deliverable version changes. The project management server can record Tinv as the duration of upstream deliverable version change attribution and record the remaining deviation corresponding to Tcorr as the execution deviation of downstream tasks themselves, thereby displaying the duration and handling suggestions corresponding to different deviation causes at the task execution end.

[0071] To avoid misattribution, optionally, when the cause information of the failure event clearly points to a quality defect in the downstream deliverable itself, human error, new customer requirements, or changes in approval strategies, the computer equipment will not attribute the failure processing segment to the impact of an upstream deliverable version change on the downstream deliverable; optionally, when the failure event occurs before the upstream deliverable update is formed, or when the version difference content does not match the consumed input content of the downstream deliverable, or when the modification content after the failure is unrelated to the matched difference content, the failure processing segment will not be attributed to the impact of an upstream deliverable version change on the downstream deliverable.

[0072] Optionally, the computer equipment generates scheduling instructions based on the cause of the deviation; the scheduling instructions may include instruction type, target result identifier, target task identifier, associated upstream deliverable version, triggering reason, responsible party, and execution deadline; the instruction type may include at least one of the following: partial redo instruction, result review instruction, execution benchmark reset instruction, affected task postponement instruction, or upstream deliverable confirmation instruction.

[0073] Optionally, when the affected downstream deliverables are still modifiable and not consumed by subsequent tasks, a partial redo instruction is generated; when the affected downstream deliverables have been submitted but not yet confirmed as to whether they need to be redone, a deliverable review instruction is generated; when the failure attribution deviation duration reaches a preset duration threshold, an execution baseline reset instruction is generated; when the affected downstream deliverables have been consumed by subsequent tasks, an affected task postponement instruction is generated; when the version difference originates from unconfirmed or pending confirmation upstream deliverables, an upstream deliverable confirmation instruction is generated.

[0074] Optionally, the computer equipment generates scheduling instructions based on the failure handling segment, the status of the affected deliverables, and the consumption status of subsequent tasks; when the affected downstream deliverables are still modifiable and have not yet been consumed by subsequent tasks, a partial redo instruction is generated, which instructs the responsible party to modify only the deliverable units corresponding to the hit difference content; when the affected downstream deliverables have been submitted but it has not yet been confirmed whether a redo is needed, a deliverable review instruction is generated, which instructs the reviewer to confirm whether the failure event refers back to the hit difference content; when the affected downstream deliverables have been consumed by subsequent tasks, an affected task postponement instruction is generated, which adjusts the planned time of subsequent tasks that continue to rely on the deliverables.

[0075] Optionally, when the failure attribution deviation duration reaches a preset duration threshold, or when the difference between the corrected schedule deviation and the pre-correction schedule deviation reaches a preset deviation threshold, an execution baseline reset instruction is generated. The preset duration threshold can be 4 hours, 1 working day, or a preset percentage of the project's planned execution time; the preset deviation threshold can be 10% to 30% of the planned execution time. When the version difference originates from an unconfirmed, pending, or unfrozen upstream deliverable version, an upstream deliverable confirmation instruction is generated to prompt the upstream responsible party to confirm whether the updated version should be used as the basis for continuing the execution of downstream tasks.

[0076] Optionally, the scheduling instruction includes the instruction type, target result identifier, target task identifier, associated upstream deliverable identifier, associated upstream deliverable version, hit difference content identifier, failure event identifier, start and end times of failure handling segment, triggering reason, responsible party, and execution period; the project management server sends the scheduling instruction to the task execution end and displays the deviation attribution reason and corresponding handling suggestions on the task execution end.

[0077] The enterprise project schedule deviation attribution scheduling method provided in this application does not simply adjust downstream tasks based on whether upstream deliverables have undergone version changes, nor does it directly attribute the deviation based on whether downstream tasks are delayed. Instead, it determines whether the deviation content matches the actual input content consumed by the downstream deliverables through version difference information and input consumption information, and identifies the failure processing segment when the downstream deliverables experience a failure event that points back to the deviation content. Thus, failure processing segments caused by upstream deliverable version changes can be distinguished from downstream task execution deviations, thereby improving the accuracy of deviation attribution and scheduling instruction generation.

[0078] Figure 5 This is a schematic diagram of the structure of an enterprise project schedule deviation attribution and scheduling system provided in an embodiment of this application; see also Figure 5 The system includes a difference acquisition module, a consumption acquisition module, a hit determination module, a fragment determination module, and an attribution scheduling module.

[0079] The difference acquisition module is used to acquire version difference information of upstream deliverables in enterprise projects; the consumption acquisition module is used to acquire input consumption information corresponding to downstream deliverables that depend on upstream deliverables; the hit determination module is used to determine whether the difference content hits the input content of the upstream deliverables actually used by the downstream deliverables based on the version difference information and input consumption information; the fragment determination module is used to determine the failure handling fragment corresponding to the downstream deliverables when it is determined that the difference content hits the input content of the upstream deliverables actually used by the downstream deliverables, and the downstream deliverables experience a failure event that points back to the difference content; the attribution scheduling module is used to attribute and correct the progress deviation of the downstream tasks to which the downstream deliverables belong based on the failure handling fragments, and generate scheduling instructions based on the attribution and correction results.

[0080] It should be noted that the above modules can be implemented by software, hardware, or a combination of both; each step in the above method embodiment can be implemented by the processor in the project management server executing the computer program stored in the memory.

Claims

1. A method for attributing and scheduling project schedule deviations, characterized in that, The method includes: Obtain version difference information of upstream deliverables in enterprise projects; obtain input consumption information corresponding to downstream results that depend on the upstream deliverables, wherein the input consumption information is used to characterize the input content of upstream deliverables actually used when the downstream results are generated; Based on the version difference information and the input consumption information, determine whether the difference content in the version difference information matches the upstream deliverable input content actually used by the downstream result; When it is determined that the difference content in the version difference information matches the upstream deliverable input content actually consumed by the downstream result, and the downstream result experiences a failure event that points back to the matched difference content, the failure processing segment corresponding to the downstream result is determined. Based on the failure handling segment, the schedule deviation of the downstream task to which the downstream result belongs is attributed and corrected, and scheduling instructions are generated according to the attribute correction results.

2. The method according to claim 1, characterized in that, The acquisition of version difference information of upstream deliverables in enterprise projects includes: Obtain the baseline version and the updated version of the upstream deliverable. The baseline version is the version of the upstream deliverable referenced when the downstream result is generated. The updated version is the submitted version, confirmed version, frozen version, or published version of the upstream deliverable after the downstream result is generated. Based on the deliverable type of the upstream deliverable, the baseline version and the updated version are respectively parsed into content units; The content units of the baseline version and the content units of the updated version are compared to obtain a set of differences in content, and the version difference information is determined based on the set of differences in content.

3. The method according to claim 2, characterized in that, The content unit includes at least one of the following: field, parameter, paragraph, code block, drawing object, table unit, list item, interface item, or approval item; The comparison of the content units of the baseline version and the content units of the updated version to obtain a set of differing content includes: Using at least one of content identifier, content location, or content summary as a comparison criterion, the newly added, deleted, or content-changed content units between the baseline version and the updated version are determined. The newly added, deleted, or changed content units are defined as the differing content.

4. The method according to claim 1, characterized in that, The step of obtaining input consumption information corresponding to downstream results that depend on the upstream deliverables includes: The upstream deliverable input content actually used when the downstream result is generated is obtained through at least one of the following methods: system log-based acquisition, result submission-bound acquisition, or content matching acquisition. The input consumption information is generated based on at least one of the content identifier, content location, content summary, version identifier, or consumption time of the upstream deliverable input content; The system log-style acquisition is used to record the reading, calling, referencing, parsing, importing, binding, or copying operations of the input content of the upstream deliverables during the downstream result generation process.

5. The method according to claim 1, characterized in that, The step of determining whether the difference content in the version difference information matches the upstream deliverable input content actually used by the downstream result, based on the version difference information and the input consumption information, includes: Extract the difference content from the version difference information and extract the consumed input content from the input consumption information; when the difference content and the consumed input content have the same content identifier, the same content position, satisfy at least one of the preset correspondence relationship or the preset association relationship, determine that the difference content matches the upstream deliverable input content actually consumed by the downstream result.

6. The method according to claim 5, characterized in that, The preset correspondence includes at least one of the following: correspondence between interface fields and code variables, correspondence between bill of materials items and purchase requisition items, correspondence between drawing objects and construction list objects, or correspondence between approval items and execution conditions; The preset association relationship includes at least one of the following: synonym relationship, parent-child relationship, inheritance relationship, reference relationship, or computational dependency relationship; The preset correspondence or preset association is determined by at least one of the following: project template, deliverable structure tree, interface dependency table, material association table, drawing object relationship table, or administrator configuration.

7. The method according to claim 1, characterized in that, The downstream result experiencing a failure event that refers back to the differing content includes: Obtain the result status change records of the downstream results, which include at least one of the following: result withdrawal record, result overwrite record, result redo record, result return record, result resubmission record, or result modification record; When the cause information of the result status change record involves the difference content, or when the result modification content after the result status change record involves the hit consumed input content, it is determined that the downstream result has experienced a failure event that points back to the difference content; The reason information includes at least one of the following: reason for return, reason for withdrawal, explanation of redo, review comments, audit comments, or task log.

8. The method according to claim 7, characterized in that, The extent of modification of the results, as represented by the result modification record, is determined by the content difference ratio, which satisfies: R=Cd / Ct; Where R represents the content difference ratio, Cd represents the number of difference result units between the first result content and the second result content that have been added, deleted, replaced or have changed content, Ct represents the total number of result units contained in the first result content, the first result content is the downstream result content before the failure event occurs, and the second result content is the downstream result content after the failure event occurs. When the content difference ratio R reaches a preset modification ratio threshold, and the difference result unit corresponds to the hit difference content, it is determined that the result modification range corresponding to the result modification record has reached a preset condition.

9. The method according to claim 1, characterized in that, Determining the failure handling segment corresponding to the downstream result includes: acquiring the processing record and result status change record of the downstream result; The moment when the downstream result first consumes the upstream deliverable input content that was hit is determined as the start point of the failure handling segment; the moment when the failure event is confirmed is determined as the end point of the failure handling segment. If the moment when the upstream deliverable input content of the first consumption is hit is not recorded, then the start time of the downstream result processing or the result submission time is determined as the starting point of the failure processing segment. The failure confirmation time is the time when the record is formed when the result is withdrawn, the result is overwritten, the result is redone, the result is returned, the result is resubmitted, or the result modification reaches the preset conditions.

10. The method according to claim 1, characterized in that, The step of attributing and correcting the progress deviation of the downstream task to which the downstream result belongs based on the failure handling segment, and generating scheduling instructions based on the attribution correction results, includes: When there are multiple failure handling segments, the overlapping time periods in the multiple failure handling segments are merged to obtain a merged failure handling segment set. The failure attribution deviation duration is determined based on the merged failure handling fragment set; the corrected execution duration is determined based on the actual execution duration and the failure attribution deviation duration; and the corrected schedule deviation is determined based on the corrected execution duration and the planned execution duration. When the cause information of the failure event clearly points to a quality defect in the downstream deliverable itself, human error, new customer requirements, or changes in approval strategies, the failure processing segment shall not be attributed to the impact of changes in the version of the upstream deliverable on the downstream deliverable. The scheduling instructions are generated based on the corrected schedule deviation. The scheduling instructions include at least one of the following: partial redo instruction, result review instruction, execution baseline reset instruction, affected task postponement instruction, or upstream deliverable confirmation instruction.

Images