A cross-organizational project collaboration management method, system, medium and product

Abstract

A cross-organization project collaboration management method, system, medium and product, wherein the method comprises: in response to a project creation request of a target user, verifying the project creation permission of the target user; if the target user passes the project creation permission verification, constructing a cross-tenant virtual organization corresponding to a target project in the project creation request; determining the cross-tenant virtual organization as a project node in a preset project tree, generating creation event data of the project node, and the project node comprising a plurality of project sub-nodes; obtaining a task dependency relationship between the plurality of first project sub-nodes, constructing a cross-organization collaboration network based on the creation event data and the task dependency relationship; in response to a state change event of a source project sub-node in the cross-organization collaboration network and generating a state synchronization instruction, based on the task dependency relationship, sending the state synchronization instruction to one or more second project sub-nodes associated with the source project sub-node. The present application can improve the efficiency of cross-organization project collaboration management.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of cross-organizational project collaboration management, in particular to a cross-organizational project collaboration management method, system, medium and product. BACKGROUND

[0002] Under the background of continuous deepening of digital transformation, business cooperation between enterprises is becoming more frequent, and project management is gradually moving towards a cross-organizational and cross-platform collaboration mode. Especially in typical scenarios such as large-scale engineering projects, joint research and development, and supply chain collaboration, deep participation of multiple organizational entities is often involved, which puts forward higher requirements for project collaboration management.

[0003] The prior art usually takes one organization as the main responsible person of the project (i.e. the source tenant), which creates a project space in the platform. Subsequently, the project administrator can invite members of external collaboration organizations (i.e. external collaboration tenants) to join the specific project space as external collaborators or visitors. Within the project, the project manager can create explicit pre- and post-dependency relationships between tasks managed by different members. When the status of a pre-task changes, the system will automatically send notifications or update the task status of the post-task manager based on these pre-set, point-to-point task associations, thereby achieving a certain degree of automated collaboration.

[0004] However, when the project scale expands and the number of participating collaboration organizations increases, and there are complex cooperation relationships between organizations (such as general contracting, subcontracting, and suppliers), since the system only reflects the association between tasks in structure, and all external personnel exist as individual collaborators in the same plane, the management complexity of overall progress control in a complex collaboration network is increased, which affects the efficiency of cross-organizational project collaboration management. SUMMARY

[0005] The present application provides a cross-organizational project collaboration management method, system, medium and product, which solves the technical problem that multiple parties cannot effectively control the overall progress when collaborating on a project, and improves the efficiency of cross-organizational project collaboration management.

[0006] In a first aspect of the present application, a cross-organization project collaboration management method is provided, which comprises: in response to a project creation request of a target user, performing project creation permission verification on the target user, the target user being a user affiliated to any tenant, the tenant including a source tenant and an external collaboration tenant; if the target user passes the project creation permission verification, constructing a cross-tenant virtual organization corresponding to a target project in the project creation request, the cross-tenant virtual organization being used to map the organization collaboration relationship between the source tenant and the external collaboration tenant in the target project; determining the cross-tenant virtual organization as a project node in a preset project tree, and generating creation event data of the project node, the project node including a plurality of project sub-nodes, and the creation event data including a node identifier of the project node and the cross-tenant virtual organization; obtaining a task dependency relationship between a plurality of first project sub-nodes, constructing a cross-organization collaboration network based on the creation event data and the task dependency relationship, the first project sub-node being any project sub-node in any of the target projects, and the cross-organization collaboration network being used to represent the collaboration relationship between the first project sub-nodes in the plurality of target projects; in response to a state change event of a source project sub-node in the cross-organization collaboration network and generating a state synchronization instruction, and based on the task dependency relationship, sending the state synchronization instruction to one or more second project sub-nodes associated with the source project sub-node, the source project sub-node being any first project sub-node.

[0007] Optionally, the project creation permission verification on the target user specifically comprises: when the target user is affiliated to the external collaboration tenant, obtaining an external collaboration tenant identifier of the target user and project feature information of a target project to be created in the project creation request; traversing each collaboration contract in a preset collaboration contract library, and matching a target collaboration contract with a matching value of a keyword in the project feature information greater than a preset matching threshold and an authorized tenant identifier same as the external collaboration tenant identifier; when the matching is successful, determining that the target user passes the project creation permission verification; and when the matching fails, determining that the target user does not pass the project creation permission verification.

[0008] Optionally, a cross-tenant virtual organization corresponding to the target project in the project creation request is constructed, specifically including: obtaining organization unit data of the source tenant and the external collaborative tenant in the target project, the organization unit data including organization hierarchical relationship, function attribute, personnel role information, and function attribute; based on a preset organization mapping template, performing structural similarity calculation on the organization unit data of the source tenant and the external collaborative tenant with the same function attribute, determining the tenants with structural similarity greater than a preset similarity threshold as an organization unit pair; combining the organization unit pairs with the same function attribute as a virtual collaboration unit, and establishing an initial organization collaboration relationship between the virtual collaboration units based on the organization hierarchical relationship between the organization unit pairs; based on the initial organization collaboration relationship, establishing a hierarchical association relationship between the virtual collaboration units to obtain a cross-tenant virtual organization, and configuring a dynamic linkage rule for the virtual collaboration unit, the dynamic linkage rule being used to update the organization collaboration relationship when an organization adjustment occurs in the tenant in the virtual collaboration unit.

[0009] Optionally, a cross-organization collaboration network is constructed based on the creation event data and the task dependency relationship, specifically including: constructing a directed dependency graph based on the task dependency relationship, and performing loop detection in the directed dependency graph to determine a circular dependency path between the first project child nodes; obtaining resource information required by each first project child node in each circular dependency path, the resource information including resource type, resource ownership tenant, and resource occupation time; determining whether each circular dependency path has a deadlock risk caused by resource mutual exclusion according to the resource information; if there is a deadlock risk in the circular dependency path, calculating a resource deprivation cost for each first project child node in the circular dependency path based on a preset resource arbitration rule, the resource deprivation cost being used to measure the loss caused by interrupting the task of the first project child node; determining a collaboration priority of each first project child node based on the organization collaboration relationship in the creation event data, and correcting the resource deprivation cost according to the collaboration priority to obtain a target resource deprivation cost; reconstructing each circular dependency path in the directed dependency graph based on the target resource deprivation cost, and determining the reconstructed directed dependency graph as the cross-organization collaboration network.

[0010] Optionally, each circular dependency path in the directed dependency graph is reconstructed based on the target resource deprivation cost, specifically including: in the circular dependency path, determining the first project child node with the lowest target resource deprivation cost as an interrupt node; adding a collaboration arbitration node between the interrupt node and a directly preceding dependency node of the interrupt node, and setting the target resource deprivation cost and a preset inter-tenant transfer compensation rule as built-in judgment attributes of the collaboration arbitration node to obtain the reconstructed circular dependency path.

[0011] Optionally, the method further comprises: obtaining a project security level of the target project and a preset tenant security policy of the external collaborative tenant in the target project; when the project security level is greater than a target security level, generating a security agent node of the target external collaborative tenant in the cross-tenant virtual organization and reconstructing the organizational collaboration relationship, the target security level being a maximum security level allowed by the tenant security policy of any external collaborative tenant, and the target external collaborative tenant being an external collaborative tenant whose project security level is greater than the target security level; and configuring an access control rule set for the security agent node based on a difference value between the project security level and the target security level, the access control rule set being used to limit access to project information when the project information flows to the target external collaborative tenant.

[0012] Optionally, the reconstructing the organizational collaboration relationship specifically comprises: splitting a collaboration task directly performed by the source tenant and the target external collaborative tenant in the target project into a first collaboration path for interaction between the source tenant and the security agent node and a second collaboration path for interaction between the security agent node and the target external collaborative tenant, wherein information interaction in the second collaboration path is subject to the access control rule set.

[0013] In a second aspect, an embodiment of the present application provides a cross-organizational project collaboration management system, which comprises: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is configured to store computer program code, the computer program code comprising computer instructions, and the one or more processors are configured to invoke the computer instructions to enable the cross-organizational project collaboration management system to perform the method described in the first aspect and any possible implementation manner of the first aspect.

[0014] In a third aspect, an embodiment of the present application provides a computer-readable storage medium comprising instructions, which, when executed on a cross-organizational project collaboration management system, enable the cross-organizational project collaboration management system to perform the method described in the first aspect and any possible implementation manner of the first aspect.

[0015] In a fourth aspect, an embodiment of the present application provides a computer program product comprising instructions, which, when executed on a cross-organizational project collaboration management system, enable the cross-organizational project collaboration management system to perform the method described in the first aspect and any possible implementation manner of the first aspect.

[0016] In summary, the one or more technical solutions provided by the present application have at least the following technical effects or advantages:

[0017] 1. By verifying the permissions of target users in the project creation stage, it is ensured that the project is only initiated by users with permissions, ensuring the clarity of the organizational boundaries of project collaboration. On this basis, the system constructs a cross-tenant virtual organization according to the project creation request, clearly maps the organizational collaboration relationship between the source tenant and the external collaboration tenant, and incorporates the virtual organization as a project node into the project tree structure, generating node creation event data, thereby establishing a collaboration hierarchy between multiple organizations at the project structure level. Further, the system constructs a cross-organizational collaboration network by analyzing the task dependency relationship between project sub-nodes, combined with the creation event data, not only realizing the management of task relationships, but also embodying the systematic expression of the collaboration structure between organizations. This collaboration network supports a state synchronization mechanism based on task dependency. When the source project sub-node state changes, the system can automatically send a state synchronization instruction to the associated second project sub-node, realizing the automatic flow of task state between multiple organizations. It breaks through the existing technology which only takes a single organization as the dominant, external collaborators participate in an individual way, and relies on point-to-point task notification collaboration mode, solves the problem of being unable to control the overall progress in complex projects involving multiple organizations and multiple levels, and improves the efficiency of cross-organizational project collaboration management.

[0018] 2. By introducing a collaboration contract mechanism, fine-grained management of target user project creation permissions in external collaboration tenants is realized. When the target user belongs to an external collaboration tenant, the system matches and searches in the preset collaboration contract library based on the tenant identifier and the project characteristic information of the target project, and determines whether there is a target collaboration contract according to whether the keyword matching value exceeds the preset matching threshold and whether the authorized tenant identifier is consistent with the external collaboration tenant identifier. Only when there is a matching contract, the target user can pass the project creation permission verification. Through this mechanism, the system not only prevents the risk of external members arbitrarily initiating projects in unauthorized scenarios, but also ensures the compatibility of project creation behavior with existing collaboration relationships between organizations, thereby establishing a controllable and compliant collaboration portal between the source tenant and the external collaboration tenant, solving the problem of organizational collaboration structure confusion and high management complexity caused by the unclear permission boundaries of external personnel and the generalization of project collaboration portals in existing technologies, and further improving the security and controllability of cross-organizational project collaboration.

[0019] 3. By introducing a directed dependency graph and a cyclic dependency path detection mechanism when constructing a cross-organization collaboration network, potential resource conflicts and deadlock risks among multi-organization tasks can be identified. Based on the resource information of each first project sub-node, the system combines resource arbitration rules and collaboration priority to calculate and correct resource deprivation cost, thereby determining the optimal interruption node, and reconstructing the cyclic path by introducing a collaboration arbitration node. Thus, not only is the dynamic avoidance of cross-organization task dependency deadlock achieved, but also the inter-organizational coordination in the resource scheduling process is ensured, effectively solving the task blocking and low efficiency of collaboration caused by the flat collaboration structure and the difficulty in reconciling resource conflicts in the background technology. BRIEF DESCRIPTION OF DRAWINGS

[0020] Figure 1 is a flowchart of a cross-organization project collaboration management method in an embodiment of the present application;

[0021] Figure 2 is another flowchart of a cross-organization project collaboration management method in an embodiment of the present application;

[0022] Figure 3 is a structural diagram of a cross-organization project collaboration management system in an embodiment of the present application;

[0023] BRIEF DESCRIPTION OF DRAWINGS DETAILED DESCRIPTION

[0024] In order for those skilled in the art to better understand the technical solutions in the specification, the technical solutions in the specification will be clearly and completely described below in conjunction with the drawings in the embodiments of the specification. Obviously, the described embodiments are only some of the embodiments of the present application, not all.

[0025] In the description of the embodiments of the present application, for example, or for example, the words used to represent an example, illustration or illustration. Any embodiment or design scheme described as an example or for example in the embodiments of the present application should not be interpreted as more preferred or more advantageous than other embodiments or design schemes. Rather, the use of for example or for example is intended to present the relevant concept in a specific manner.

[0026] In the description of the embodiments of the present application, the term plurality means two or more. For example, a plurality of systems means two or more systems, and a plurality of screen terminals means two or more screen terminals. In addition, the terms first and second are used only for the purpose of description, and cannot be understood as indicating or implying relative importance or implicitly indicating the technical features indicated. Therefore, the features defined with first and second can explicitly or implicitly include one or more features. The terms include, contain, have and their variants mean include but are not limited to, unless otherwise specifically emphasized.

[0027] Figure 1 is a flowchart of a cross-organizational project collaborative management method in the embodiments of the present application.

[0028] Please refer to Figure 1 The cross-organizational project collaborative management method in the embodiments of the present application comprises:

[0029] S101, in response to a project creation request of a target user, performing project creation permission verification on the target user, the target user being a user affiliated to any tenant, the tenant including a source tenant and an external collaborative tenant;

[0030] The target user can be affiliated to any tenant, and the tenant is a logical organizational unit for isolating management of resources and permissions in the platform, usually corresponding to an enterprise, department or organization entity in reality. According to different collaboration modes, the tenants are divided into source tenants and external collaborative tenants. The source tenant is usually the initiator or master of the project, while the external collaborative tenant is other organizations that collaborate with the source tenant. In this context, permission verification is not only related to the security control of the platform, but also directly affects the compliance and rationality of cross-organizational collaboration. It should be noted that although the source tenant is usually the initiator or master of the project in most collaboration scenarios, in order to improve the collaboration flexibility of the platform, the present application does not limit the project creation request to be initiated only by the source tenant user. The system supports any tenant user to initiate a project under the premise of passing the permission verification, including the external collaborative tenant user, to ensure the diversity and compliance of the collaboration mode.

[0031] After receiving the project creation request initiated by the target user, the system extracts the tenant identification from the user identity data, which includes the source tenant identification and the external collaborative tenant identification. The tenant identification is coded information used to uniquely identify the tenant organization in the platform, usually generated based on the unique tenant ID or tenant domain name assigned when the tenant is registered. The system determines whether the target user belongs to the source tenant or the external collaborative tenant according to the tenant identification. When the target user belongs to the source tenant, the project creation permission verification focuses on the organization management rules and permission control system within the source tenant, which is different from the verification method of the external collaborative tenant relying on cross-tenant collaboration contract. Its verification mechanism focuses more on the role system and resource authorization rules within the tenant.

[0032] After receiving the project creation request, the system retrieves the permission node associated with the target user from the permission control module of the source tenant, and further extracts the set of project operation capabilities that the user has under the current organizational structure. The set of project operation capabilities is a permission abstraction collection defined by the invention, which is used to describe the project-level operations that the user can perform in the platform, including creation, archiving, transfer, changing scope, etc. Each operation capability is bound to factors such as job responsibilities, department budget permissions, and business scenarios.

[0033] The system matches the project feature information (such as budget size, project level, business line, etc.) of the target project requested to be created by the target user with its operation capability set, and determines whether it has project creation permission of corresponding level or business scope. For example, if the user only has project creation capability below 500,000, he / she cannot initiate a project exceeding this amount; or if the user only has the right to internal R&D projects, he / she cannot initiate external cooperation projects.

[0034] In addition, this embodiment further introduces a dynamic approval verification mechanism as a supplementary measure when the source tenant's internal permission is insufficient. When the system identifies that the target user's permission does not completely match the target project, but there is a rule that can enhance the permission, the system can automatically trigger a pre-set internal approval flow, which is confirmed and approved by the superior supervisor or permission holder. After approval, it is considered that the target user temporarily has the creation permission. This mechanism ensures the flexibility and controllability of the source tenant's internal permission system, avoiding the decline of collaboration efficiency due to strict permission boundaries.

[0035] When the target user comes from an external collaborative tenant, the system cannot rely on traditional organizational roles or post permissions for judgment because he does not belong to the permission control system of the source tenant. Therefore, the application introduces a collaborative contract mechanism to establish a structured and computable cross-tenant permission judgment model to ensure that external users have project creation permissions only within the scope of explicit authorization. Specifically, it can include the following steps: when the target user belongs to an external collaborative tenant, the external collaborative tenant identifier of the target user and the project characteristic information of the target project to be created by the project creation request are obtained; each collaborative contract in the preset collaborative contract library is traversed, and the target collaborative contract whose matching value of the key word in the project characteristic information is greater than the preset matching threshold and whose authorized tenant identifier is the same as the external collaborative tenant identifier is matched; when the matching is successful, it is determined that the target user passes the project creation permission verification; when the matching fails, it is determined that the target user does not pass the project creation permission verification.

[0036] In the specific implementation process, the system parses the structured fields and unstructured description information in the project creation request message and extracts the project characteristic information of the target project. The project characteristic information is a set of key data used to describe the business attributes of the project in the platform, usually including business type, industry, cooperation form, project budget, project cycle, target region, etc. For subsequent matching processing, the system performs keyword vectorization processing on the information, extracts and standardizes the core words in the text description, forms a keyword set, and uses it to represent the semantic characteristics of the target project. The processing logic of this step is based on the bag-of-words model or word vector model in natural language processing, ensuring accurate modeling of project content. The purpose of obtaining the external collaborative tenant identifier and the project characteristic information is to provide a dual-dimensional verification basis for subsequent collaborative contract matching, ensuring that the calling permission belongs to a valid organization and that the project content meets the authorized scope.

[0037] After obtaining the external collaborative tenant identifier and the project characteristic information, the system enters the collaborative contract matching stage. The collaborative contract library is a structured data set preset by the platform and maintained by the source tenant, which is used to record the cooperation agreement reached between the source tenant and the external collaborative tenant. Each collaborative contract includes authorized tenant identifier, key word label, cooperation range, permission validity, project constraint condition, etc. Among them, the key word label is used to describe the project type to which the contract applies, which is usually set by the source tenant when signing the cooperation agreement, and is the core field for semantic matching.

[0038] The system reads the keywords in each collaboration contract in the collaboration contract library by traversing each collaboration contract, and performs semantic similarity calculation with the keyword set in the project feature information of the target project. The matching value can be calculated by using the TF-IDF model based on the cosine similarity, or by using a deep semantic matching network such as the BERT language model to score the semantic correlation of the two sets of keywords. The matching value is used to quantify the correlation between the project features and the contract keywords. The system compares the matching value with the preset matching threshold. Only when the matching value exceeds the threshold and the authorized tenant identifier in the collaboration contract is consistent with the external collaborative tenant identifier of the target user, the contract is identified as the target collaboration contract, that is, the matching is successful.

[0039] The purpose of setting the matching threshold is to prevent low correlation or ambiguous projects from being incorrectly identified as authorized projects, and to ensure the accuracy and controllability of the authorized scope. Through the dual judgment mechanism of semantic matching and tenant identifier consistency, the system can accurately identify whether there is a legal authorization basis.

[0040] When the matching is successful, that is, there is at least one contract with a keyword matching value higher than the matching threshold and an authorized tenant identifier consistent with the external collaborative tenant identifier, the system takes the contract as the basis for permission judgment and considers that the current project request has obtained the source tenant authorization. The system records the ID and matching details of the matching contract and stores them as audit information in the permission verification log, and returns the result that the project creation permission verification is passed.

[0041] At this time, the system allows the target user to enter the next stage of the project creation process, including project resource allocation, task structure initialization, and other operations. Through the verification method based on collaboration contracts, not only the traceability of permission judgment is ensured, but also the source tenant can manage cross-organization cooperation permissions in a structured and contractual manner, replacing the traditional manual approval or static whitelist method, greatly improving the automation and compliance of permission control.

[0042] For example, if the target project feature is medical device design and the external collaborative tenant identifier is cooperation unit X, the system retrieves a collaboration contract with keywords medical, device, and design and an authorized tenant identifier of cooperation unit X from the contract library, the matching value is 0.84, the threshold is set to 0.75, and the matching conditions are met. The user obtains the creation permission.

[0043] When traversing the collaboration contract library, the system cannot find any collaboration contract that meets both the condition of keyword matching value greater than the matching threshold and the condition of authorized tenant identifier consistency, indicating that the current project request is not within the cooperation scope authorized by the source tenant to the external collaborative tenant. At this time, the system determines that the target user does not have the project creation permission and rejects the creation request, and returns the permission verification failure prompt.

[0044] To improve user experience and explainability, the system will provide a reason for the matching failure, including matching value score, authorized tenant inconsistency, etc. It can also suggest that the external collaborative tenant and the source tenant re-initiate the cooperation contract signing process and expand the authorized scope. This mechanism effectively prevents unauthorized project creation and prevents potential inter-organizational data leakage and business conflict risks. It also provides a clear boundary management mechanism for inter-organizational cooperation.

[0045] S102, if the target user passes the project creation permission verification, a cross-tenant virtual organization corresponding to the target project in the project creation request is constructed, and the cross-tenant virtual organization is used to map the organizational collaboration relationship between the source tenant and the external collaborative tenant in the target project;

[0046] The cross-tenant virtual organization is a logical structure used to structure and dynamically manage the organizational collaboration relationship between the source tenant and the external collaborative tenant in a multi-tenant collaboration environment. This virtual organization does not correspond to a physical organizational structure, but rather maps and reorganizes the organizational units between two or more tenants with equivalent functions and responsibilities to support deep collaboration and permission linkage at the project level. Constructing a cross-tenant virtual organization corresponding to the target project in the project creation request can include the following steps:

[0047] Obtain the organizational unit data of the source tenant and the external collaborative tenant in the target project, including organizational hierarchy, function attribute, personnel role information, and function attribute; based on a preset organizational mapping template, calculate the structural similarity of the organizational unit data of the source tenant and the external collaborative tenant with the same function attribute, and determine the tenant with a structural similarity greater than a preset similarity threshold as an organizational unit pair; combine the organizational unit pairs with the same function attribute into a virtual collaboration unit, and establish an initial organizational collaboration relationship between the virtual collaboration units based on the organizational hierarchy relationship between the organizational unit pairs; based on the initial organizational collaboration relationship, establish a hierarchical association relationship between the virtual collaboration units to obtain a cross-tenant virtual organization, and configure a dynamic linkage rule for the virtual collaboration unit. The dynamic linkage rule is used to update the organizational collaboration relationship when an organizational adjustment occurs in the tenant in the virtual collaboration unit.

[0048] In the implementation process, the system obtains the organization unit data of the source tenant and the external collaborative tenant involved in the target project. The organization unit data is an abstract representation of the internal organization structure of the tenant by the platform, which includes three core fields: organizational hierarchical relationship, functional attribute, and personnel role information. The organizational hierarchical relationship is used to describe the superior-inferior membership structure within the organization and is the basis for building the organizational structure graph. The functional attribute is used to identify the responsibility positioning of the organization unit in the business process, such as project management, architectural design, and drawing support, which is a key element for organization equivalence judgment. The personnel role information reflects the division of labor within the organization unit, such as project manager, main designer, and business responsible person, which is an important basis for collaboration granularity control. The functional attribute is a descriptive meta-information used by the platform to identify the type of capability and interface capability range that the organization unit can provide in collaboration tasks, which is a cross-tenant collaboration extension field that distinguishes from traditional organization structure modeling. Its main function is to clarify the "explicit capability" of each organization unit in business collaboration, i.e., the functional responsibility that the unit can undertake, respond to, and output, which is commonly used to realize the capability mapping and task matching between virtual collaboration units. The system extracts the above data from the organization information systems of the two tenants through interface calling in this stage, and performs unified data structuring processing to ensure comparability and consistency in the subsequent calculation process. For example, the hierarchical path of the project development department, the function of project management, and the role of development manager are extracted from the source tenant, and are structurally aligned with the customer interface group data in the external collaborative tenant.

[0049] After completing the acquisition of organization unit data, the system loads a set of pre-set organization mapping templates and performs structure similarity calculation on the organization unit data of the source tenant and the external collaborative tenant based on the templates. The organization mapping template is a set of structure alignment rules embedded in the platform, which is used to guide how to identify functionally equivalent organization units between different tenants. The structure similarity calculation is an algorithm process that measures the similarity of organizational structure, which considers the matching degree of organizational hierarchical position, functional semantic content, and role configuration. The system respectively calculates the weighted sum of the hierarchical depth difference, the functional attribute semantic similarity (which can be calculated by BERT or Word2Vec word vector model), and the overlap degree of the role set between each organization unit pair, and obtains the structure similarity value. When the value exceeds the similarity threshold set by the platform (such as 0.75), it is considered that the tenants in the organization unit pair have comparability in organizational structure, and the system identifies them as an organization unit pair, i.e., functionally equivalent organization entities in collaboration. It can be understood that the organization unit pair contains at least two tenants, which can include the source tenant or the external collaborative tenant. For example, if the architectural design department in the source tenant has a structure similarity of 0.82 with the scheme design group in the external collaborative tenant in terms of function and role configuration, the system will form an organization unit pair.

[0050] After identifying multiple pairs of organizational units, the system combines pairs of organizational units with the same functional attributes to generate virtual collaboration units. A virtual collaboration unit is the smallest collaboration entity built by the platform in the cross-tenant collaboration process, and is used to carry the collaboration responsibilities of the source tenant and the external collaborative tenant in a specific function. The core of this step is to screen pairs of organizational units with the same functional attributes, for example, two organizational units both undertake the task of structural deepening design, and can be combined into a structural design collaboration unit. Subsequently, the system builds the initial organizational collaboration relationship between virtual collaboration units by analyzing the superior-inferior relationship of these pairs of organizational units in their respective tenant organizational structures, that is, who is the superior collaboration unit and who is the inferior collaboration unit. This collaboration relationship is recorded in the platform in the form of a directed graph, which is used to simulate the task transfer path between real organizations. For example, if the project management collaboration unit is above the design collaboration unit in both tenants, a collaboration path of project management collaboration unit → design collaboration unit is built in the virtual organization.

[0051] After the initial collaboration relationship is established, the system further builds the complete hierarchical relationship based on the collaboration path to form the final cross-tenant virtual organization. This virtual organization exists in the form of a graph structure, where each node represents a virtual collaboration unit, and the edges between the nodes represent the collaboration relationship between the upstream and downstream organizations. To enhance the adaptability and stability of the virtual organization in the multi-tenant collaboration process, the system configures a corresponding dynamic linkage rule for each virtual collaboration unit. The dynamic linkage rule is a set of response mechanisms bound to organizational structure events, which is used to automatically trigger the corresponding organizational collaboration relationship update when the internal organizational structure of the tenant is adjusted. For example, when the source tenant splits the architectural design department into a conceptual design group and a construction drawing group, the system recalculates the structural similarity according to the linkage rule, splits the original design collaboration unit into two new collaboration units, and updates the collaboration path. The dynamic linkage rule relies on the organizational structure change event listening mechanism and the structure matching engine to work together to ensure that the cross-tenant virtual organization is always aligned with the actual organizational structure, avoiding collaboration failure or permission mismatch caused by organizational adjustment.

[0052] Through the cooperative work of the above steps, the system can automatically build a set of cross-tenant virtual organization system that is highly consistent with the project structure, has clear responsibilities, clear relationships, and can dynamically evolve at the initial stage of the target project, providing organizational foundation support for subsequent task collaboration, permission inheritance, process driving, etc. For example, in a residential development project involving real estate enterprise A and design agency B collaboration, the system can automatically identify multiple cross-tenant collaboration units such as project management collaboration unit, architectural design collaboration unit, and budget control collaboration unit, and establish a collaboration path from project management to design to budget, forming a complete collaboration structure diagram, significantly improving the efficiency and controllability of inter-organizational collaboration.

[0053] If the target user fails to pass the project creation permission verification, the system will determine that the current user does not have the legal project creation qualification. At this time, the system will not enter the construction process of the cross-tenant virtual organization, but will perform the following processing logic: terminate the project creation process: the system immediately suspends the current project creation request, avoiding the initialization of unauthorized organization collaboration structure. Generate permission rejection feedback information: the system returns structured rejection response data to the user, including rejection reason code (such as no permission, organization restriction, policy conflict, etc.), rejection description text, suggested operation instructions, etc., to help the user understand the failure reason and guide subsequent processing. Record audit logs: the platform writes this permission verification failure event into the permission audit log, including user ID, operation time, request content, failure reason, etc. information, for subsequent security audit and behavior analysis. Trigger notification or alarm: if the permission verification failure frequency is high or the source is abnormal, the system can automatically trigger administrator notification or platform security alarm according to the tenant security policy, prompting potential permission abuse or risk behavior.

[0054] S103, determining the cross-tenant virtual organization as a project node in the preset project tree, and generating creation event data of the project node, the project node including a plurality of project sub-nodes, and the creation event data including a node identifier of the project node and the cross-tenant virtual organization;

[0055] The project node is a core constituent unit in the preset project tree structure, and is used to represent an independently manageable project entity. The project tree is a tree-shaped data structure used to express the hierarchical relationship and collaboration structure between projects, and has a unique root node and a plurality of branch structures. Each project node can include a plurality of project sub-nodes, achieving hierarchical division of the project structure. In the method, the cross-tenant virtual organization is mapped to one of the project nodes, meaning that the organization collaboration subject has independent task scheduling, permission management and state perception capabilities in the entire project system. By embedding the cross-tenant virtual organization into the project tree, the system can uniformly manage the collaboration paths between multiple tenants in the form of a graph structure, solving the problems of unclear organization boundaries and unclear responsibilities in traditional project collaboration.

[0056] To achieve the above mapping, the system first constructs a new project node instance for the current target project and assigns a unique node identifier. The node identifier is a number or code used to uniquely identify each node in the project tree, usually using a hash value or distributed ID generation mechanism to ensure that it is not repeated in the global scope. The node identifier is not only used to identify the node position in the data structure, but also is a key index for subsequent event listening, state synchronization, permission inheritance and other operations.

[0057] After the node identifier is generated, the system constructs the creation event data of the project node. The creation event data is a structured event description information used to trigger the initialization process of the project node within the system. The data includes at least two key contents: one is the node identifier mentioned above, and the other is the organizational collaboration relationship in the cross-tenant virtual organization. The organizational collaboration relationship refers to the hierarchical relationship and collaboration path between the virtual collaboration units in the constructed cross-tenant virtual organization, which is the collaboration graph structure generated by the structure similarity calculation and function mapping in the previous step. The system maps the organizational collaboration relationship into the event data, so that the project node can have a complete organizational collaboration model at the initial stage of creation, realizing the automation of multi-organizational task division, permission configuration and process initialization.

[0058] After the project node is constructed, the system further generates multiple project sub-nodes under the project node based on the task granularity and function splitting logic within the cross-tenant virtual organization. The project sub-node is the basic unit in the project task structure, usually corresponding to a specific task package, a phased goal or a set of responsibilities of the responsible person, used to support task allocation, progress tracking and status synchronization. Each project sub-node can inherit the collaboration path and permission control model of its superior node, and can also establish task dependency relationship with other project sub-nodes, providing node basis for subsequent construction of cross-organizational collaboration network.

[0059] For example, in a cross-organizational project related to architectural design, the system maps the cross-tenant virtual organization composed of real estate development enterprises and design companies into a project node in the project tree, and assigns it a node identifier PRJ-9831. In the creation event data, the system writes the organizational collaboration path of project management collaboration unit → design collaboration unit → cost control collaboration unit into the event data structure, and generates multiple project sub-nodes such as preliminary design sub-node, construction drawing design sub-node, design budget sub-node, etc. under the project node. After the above process is completed, the system can start the collaboration network construction and task state perception mechanism based on the structure, ensuring the consistency and controllability of the cross-organizational project in structure, permission and process.

[0060] Through the above implementation steps, S103 not only realizes the organic integration of the cross-tenant virtual organization into the project management structure, but also provides structural support and event basis for subsequent collaboration network construction, task flow control and project state linkage, embodying the systematicness, flexibility and engineering applicability of the project management method in the multi-organizational collaboration environment.

[0061] S104, acquire task dependency relationships between a plurality of first project sub-nodes, the first project sub-node being any project sub-node in any of the target projects, and construct a cross-organization collaboration network based on the creation event data and the task dependency relationships, the cross-organization collaboration network being used to represent collaboration relationships between the first project sub-nodes in the plurality of target projects;

[0062] The core of step S104 is to realize the flow control and state linkage of project sub-tasks in a multi-tenant and cross-organization scenario. The essence is to structurally couple the organization collaboration structure and the task execution process, and ensure that the task advancement process is still controllable and consistent when crossing the organization boundary.

[0063] The task dependency relationship refers to a logical constraint relationship between project sub-nodes in terms of execution order, input and output, or resource occupation, and is important structural information for describing the task execution process in project management. In the present method, the task dependency relationships acquired by the system include not only the task dependencies between project sub-nodes under the same project node, but also the collaboration dependencies between project sub-nodes across project nodes and tenants. To achieve unified modeling and management of these complex dependency relationships, the system extracts information such as input and output points, trigger conditions, and role responsibilities of each project sub-node by analyzing the task definition information carried in the project creation request, the historical project structure template, and the organization collaboration graph, and constructs a task dependency graph. Each edge in the dependency graph represents a dependency relationship of one task sub-node to another task sub-node, and the dependency types can include sequential dependency, data dependency, resource dependency, etc.

[0064] After acquiring the task dependency relationships, the system constructs a cross-organization collaboration network in combination with the cross-tenant virtual organization structure information carried in the aforementioned creation event data. The cross-organization collaboration network is a graph structure, in which the nodes represent project sub-nodes, and the edges represent task dependency relationships, with organization collaboration paths and permission inheritance rules attached to the edges, for dynamically judging the executability of tasks and the legality of collaboration paths during task scheduling. The key to the construction process is to structurally fuse the organization structure and the task structure, i.e., not only to establish the task flow path, but also to bind the task execution organization entity, so as to realize organization perception and permission control of task scheduling. When constructing the collaboration network, the system binds each project sub-node to its virtual collaboration unit, and establishes directed edges between the nodes according to the task dependency relationships, while recording the dependency trigger conditions, execution permission control strategies, and state transfer rules for each edge. In the implementation process, to ensure that the task dependency relationships do not cause execution blockage or resource deadlock problems in the complex collaboration network, the system needs to perform topological analysis and resource scheduling prediction on the task dependency structure during the construction of the cross-organization collaboration network, which can include steps S1041-S1046:

[0065] S1041, construct a directed dependency graph based on the task dependency relationship, and perform loop detection in the directed dependency graph to determine the circular dependency path between the first project child nodes;

[0066] After obtaining the task dependency relationship between the plurality of first project child nodes, the system constructs a directed dependency graph based on these dependency relationships. The directed dependency graph is a graph data structure, where each node corresponds to a project child node, and each directed edge represents an explicit task dependency relationship, such as task A must be executed after task B is completed. The graph is used to represent the order constraint relationship between tasks and is a commonly used data model in task scheduling systems.

[0067] After construction, the system performs a loop detection algorithm on the directed dependency graph to identify whether there is a circular dependency path. A circular dependency path refers to one or more closed loop structures formed between several tasks, such as task A→task B→task C→task A. If such structures are not broken, it will lead to tasks being unable to start or waiting for resources forever, thus causing a logical deadlock. The system can use a topological sorting algorithm based on depth-first search (DFS) to traverse the graph, and if topological sorting cannot be completed or a back edge is detected, it means that there is a circular path.

[0068] For example, in a task chain involving design review, customer feedback, and drawing modification, if it is found that drawing modification depends on customer feedback, customer feedback depends on design review, and design review in turn depends on drawing modification, the system will identify that the three nodes form a closed loop path.

[0069] S1042, obtain resource information required by each first project child node in each circular dependency path, including resource type, resource ownership tenant, and resource occupation time;

[0070] After detecting the circular dependency path, the system needs to further analyze the resource requirement information of each first project child node in the path. Resource information refers to the physical or virtual resources required by the task during execution, and its structured data includes the following fields:

[0071] Resource type: such as human resources (designers, auditors), software licenses, hardware devices, network bandwidth, etc.

[0072] Resource ownership tenant: indicates which tenant provides or manages the resource, which is the basis for implementing resource permission control;

[0073] Resource occupation time: indicates the time lock segment of the resource during task execution, which is used to determine whether the resource conflicts with other tasks in time.

[0074] The system extracts the aforementioned resource information by calling the resource management interface, combining the task definitions and execution plans of the project's sub-nodes, and binds it to each node in the loop path, thereby establishing a task-resource mapping relationship. This mapping relationship will serve as the preliminary data input for deadlock risk analysis.

[0075] For example, in an architectural design process, if a construction drawing modification task requires the use of structural design software license resources, which belong to the design company tenant, and the usage period is from day 5 to day 8, this information will be recorded and associated with that task node.

[0076] S1043. Determine whether there is a risk of deadlock due to resource mutual exclusion for each circular dependency path based on resource information;

[0077] Based on the above task-resource mapping relationship, the system analyzes whether there is a risk of deadlock due to resource mutual exclusion in each circular dependency path. Resource mutual exclusion refers to multiple tasks competing for the same resource within the same time period, and that resource can only be exclusively used by one task at a given time. When there are cross-dependencies between multiple mutually exclusive resources, a typical deadlock condition can be formed.

[0078] The system employs resource allocation graph and deadlock waiting graph models for deduction. In the resource allocation graph, nodes consist of tasks and resources, and edges represent the relationship of tasks requesting or occupying resources. Based on the graph structure, the system calculates whether a closed waiting cycle exists, i.e., each task is waiting for a resource occupied by another task and cannot continue execution; this is considered a deadlock risk.

[0079] For example, if task A occupies resource X and waits for resource Y, while task B occupies resource Y and waits for resource X, a typical mutually exclusive waiting loop is formed, and the system marks this path as having a deadlock risk.

[0080] S1044. If there is a deadlock risk in the circular dependency path, the resource preemption cost is calculated for each first project sub-node in the circular dependency path based on the preset resource arbitration rule. The resource preemption cost is used to measure the loss caused by interrupting the task of the first project sub-node.

[0081] Once a deadlock risk is detected, the system must break the waiting cycle through a resource arbitration mechanism. To this end, the platform calculates the corresponding resource preemption cost for each project sub-node in the circular dependency path based on preset resource arbitration rules. The resource preemption cost refers to the price incurred in forcibly releasing the resources occupied by a task to resolve the deadlock. This price can be time delays caused by task interruption, loss of completed work, contract default risks, or personnel scheduling costs, etc.

[0082] The system quantitatively models according to factors such as task importance, execution progress, resource exclusivity, etc. For example, the following formula can be set: resource deprivation cost = basic task value × proportion of time used when interrupted × resource exclusivity factor. The calculation result is used to select the task with the minimum cost as the resource release party in multi-task conflicts, so as to break the deadlock waiting structure at the minimum cost.

[0083] For example, if the task C deprivation cost is 1800 yuan and the task D deprivation cost is 750 yuan, the system preferentially selects task D to interrupt and release resources.

[0084] S1045, determine the cooperation priority of each first project sub-node based on the organization cooperation relationship in the creation event data, and modify the resource deprivation cost according to the cooperation priority to obtain a target resource deprivation cost;

[0085] Although the resource deprivation cost can reflect the economic cost of task interruption, in the cross-organization scenario, the importance of the task is also affected by its position in the organization cooperation relationship. In order to more reasonably perform resource arbitration, the system introduces cooperation priority as a correction factor to weight and adjust the original resource deprivation cost to obtain the target resource deprivation cost.

[0086] The cooperation priority is a task priority value calculated according to the organization cooperation relationship recorded in the creation event data. The value reflects the key degree of the virtual cooperation unit to which the project sub-node is bound in the cross-tenant organization structure. For example, if the cooperation unit in which a task node is located is an upper unit or a coordination party, the cooperation priority will be higher than that of an execution type cooperation unit. The system can comprehensively evaluate the cooperation priority through dimensions such as hierarchical depth, role weight, and task dependency breadth.

[0087] The correction method usually adopts the following logic: target resource deprivation cost = original deprivation cost × (1 + cooperation priority weight).

[0088] For example, if the deprivation cost of task E is 1000 yuan and the cooperation priority weight is 0.3, the target cost is 1300 yuan; if another task F has a cost of 1200 yuan but a cooperation priority of 0.1, the corrected cost is 1320 yuan, and the system finally selects to deprive task E to protect the continuous execution of high-priority task F.

[0089] S1046, reconstruct each circular dependency path in the directed dependency graph based on the target resource deprivation cost, and determine the reconstructed directed dependency graph as the cross-organization cooperation network.

[0090] Step S1046 is based on the target resource deprivation cost to reconstruct each circular dependency path in the directed dependency graph, and finally determines the optimized dependency graph as a new cross-organization collaboration network by introducing adjustable nodes and arbitration mechanisms. This process is not only a structural reconstruction, but also a comprehensive embodiment of task scheduling and policy coordination between tenants, ensuring that the cross-tenant collaboration process is controllable in the logical layer and conflict-resolving in the resource layer. Step S1046 can include the following steps: in the circular dependency path, determine the first project child node with the lowest target resource deprivation cost as the interrupt node; add a collaboration arbitration node between the interrupt node and the direct predecessor node of the interrupt node, and set the target resource deprivation cost and the preset inter-tenant transfer compensation rule as the built-in judgment attributes of the collaboration arbitration node, to obtain the reconstructed circular dependency path.

[0091] The system analyzes each identified circular dependency path one by one, and determines the task node with the lowest resource release cost in the path as the interrupt node based on the target resource deprivation cost calculated in the previous step. The interrupt node is a task node that is preferentially selected to break the dependency loop while maintaining the minimum cost of overall task scheduling. The selection principle is the project child node with the lowest deprivation cost and relatively low collaboration priority. The deprivation cost has been considered in the previous step, taking into account task importance, resource usage, and collaboration weight, so it is directly used as the basis for sorting in this stage, and the most suitable interrupt point in the path is automatically selected by the system.

[0092] Once the interrupt node is determined, the system does not directly delete or modify its original dependency relationship, but introduces a new structural node, the collaboration arbitration node, between the interrupt node and its direct predecessor node to achieve encapsulation and control of the original dependency relationship. The collaboration arbitration node is a virtual logical node used to carry out inter-organizational resource coordination and transfer logic during task scheduling. The node does not represent an actual task execution unit, but is a scheduling control point used by the system to interrupt the deadlock path in the graph structure. The collaboration arbitration node contains two core attributes: one is the target resource deprivation cost, which is used to indicate the minimum cost evaluation result of the current interrupt path; the other is the preset inter-tenant transfer compensation rule, which comes from the inter-organizational collaboration agreement or platform policy setting, and is used to compensate the resource ownership tenant when the resource is forcibly released, such as through task postponement rights, resource usage quota, or fee settlement methods to achieve compensation balance.

[0093] The system inserts the cooperation arbitration node as an intermediate node in the original path in the graph structure, specifically: the original edge pre-task is split into two edges pre-task→ cooperation arbitration node→ interrupt task, and a condition triggering mechanism is set at the cooperation arbitration node. When the system task scheduling engine detects a deadlock risk trigger, it will automatically execute the interrupt decision or cooperation adjustment according to the deprivation cost and compensation rules in the arbitration node, realizing the dynamic controllability of the path.

[0094] For example, in a cross-organization design and review process, if a loop dependency is found between a structure modification task and a customer feedback processing task, and the target resource deprivation cost of the structure modification task is the lowest, the system will set it as an interrupt node and insert a cooperation arbitration node between it and the structure review task. The built-in deprivation cost of this node is 800 yuan, and the compensation rule is set as follows: if the design unit releases resources, the customer unit needs to provide feedback data support or bear part of the design adjustment cost in the subsequent process. In this way, the unified modeling of path reconstruction and organizational responsibility transfer is realized.

[0095] Through the above path reconstruction mechanism, the system not only breaks the logically unschedulable loop dependency structure, but also realizes the organizational responsibility allocation and decision transparency of resource conflict processing through cooperation arbitration nodes, providing a solid structural foundation and scheduling security for the entire cross-organization cooperation network. This reconstruction method preserves the business logic continuity of the original task relationship while introducing a controllable intervention mechanism.

[0096] When detecting that there is cross-tenant resource competition in the loop dependency path, the resource priority score of each project sub-node is calculated based on the preset resource arbitration rules, and the resource priority score is used to determine the resource allocation order; according to the resource priority score, the project sub-nodes in the loop dependency path are mapped to cooperation network nodes with priority attributes, and a resource scheduling sub-network is constructed in the cross-organization cooperation network; when a deadlock risk occurs in the resource scheduling sub-network, the resource priority score is dynamically adjusted based on the preset inter-tenant transfer compensation mechanism, and a resource reallocation process is triggered.

[0097] In a multi-tenant collaborative work platform, a key challenge is to handle execution conflicts between projects of different tenants (i.e., different enterprise organizations) due to the sharing of limited resources. When the system analyzes the dependency graph and detects a loop dependency path, and the path contains project sub-nodes belonging to different tenants that compete for the same exclusive resource, cross-tenant resource competition is formed. Without intervention, this situation will lead to a stalemate where all related projects are waiting indefinitely.

[0098] To achieve automated arbitration, a resource priority score is computed for deciding the order of resource access. The resource priority score is a composite dynamic weight value designed to go beyond simple first-come-first-serve queues by incorporating non-technical factors such as the business value of the project, time sensitivity, and service level of the tenant, thus aligning resource allocation decisions with the overall business goals of the organization.

[0099] The specific implementation process is as follows: when cross-tenant resource contention is identified, the resource arbitration module is activated. The resource arbitration module first collects relevant metadata of the project child nodes of each competing resource in the circular dependency path. The collected metadata includes at least four key dimensions: first, the business value weight of the project, a value set by the project initiator at the time of creation, representing the expected business return of the project; second, the deadline urgency factor, a dynamic value obtained by calculating the remaining time from the current time to the project deadline and taking the reciprocal, the shorter the remaining time, the higher the factor value; third, the tenant service level agreement (SLA) level, a preset multiplier representing the level of the tenant's purchased service package, for example, the multiplier of a platinum-level tenant is 1.5, and that of a gold-level tenant is 1.2; fourth, the waiting time cost, a record of the cumulative waiting time of the project child node since the resource request was sent.

[0100] After obtaining the metadata of all dimensions, the resource arbitration module uses a preset weighted sum formula to calculate the final resource priority score of each project child node. An example calculation formula is: resource priority score = (business value weight x deadline urgency factor) x tenant service level agreement level + waiting time cost. By applying this formula, each competing node will obtain an accurate, comparable floating-point score.

[0101] The final effect of this is that the originally chaotic and disordered resource contention state is transformed into a clear and ordered priority list. The project child node with the highest score is given the right to acquire resources first. This approach not only solves the circular dependency problem in a deterministic and repeatable way, but also ensures that scarce resources on the platform are always prioritized for tasks that have the highest overall business value, the most urgent time requirements, and the highest service level, maximizing resource allocation efficiency and business value.

[0102] After the resource priority scores of each project subtask are calculated, the system only gets a static order list. In order to convert this order into an executable and monitorable dynamic scheduling plan, there must be a structured way to express and manage the cooperative relationship between nodes. If only relying on a simple list, the system will be difficult to handle exceptions during execution, and it is also difficult to intuitively show the flow path of resources between different tenants. Therefore, it is necessary to map these discrete nodes and their priority relationships to a network structure specially used for resource scheduling. The cooperative network node is a logical abstract representation of a specific project subtask in the platform, which encapsulates all attributes of the task, including the tenant ID to which it belongs, the project ID, and the resources required for execution, etc. In the context of the present embodiment, a key additional attribute of the cooperative network node is the resource priority score just calculated. The resource scheduling subnetwork is a temporary, directed acyclic graph (DAG), and its purpose of creation is to visualize and execute a clear resource handover process in this resource competition resolution process.

[0103] The specific construction implementation process is as follows: the system will traverse all project subtasks involved in the circular dependency path. For each project subtask, the system will instantiate a corresponding cooperative network node object in memory, and write the calculated resource priority score as a core attribute to this object. After mapping all nodes, the system begins to construct the resource scheduling subnetwork. The starting point of construction is the cooperative network node with the highest resource priority score among all competing nodes. The system sets this node as the root node of the subnetwork, and from the root node, the next cooperative network node is connected in order according to the resource priority score from high to low, forming a one-way path representing the flow of resources. For example, the highest scoring node A is connected to the second highest scoring node B, node B is connected to the third highest scoring node C, and so on, until the lowest scoring node. The outgoing edge of the last node points to a virtual terminal node representing resource release.

[0104] In this way, an abstract priority order is materialized into a structured resource scheduling subnetwork. This subnetwork provides a clear, distributed execution blueprint for the platform's resource manager. The resource manager can pass the exclusive use of resources from one cooperative network node (i.e., a tenant's project) to the next along the directed path defined in the subnetwork. The entire resource scheduling process becomes transparent and traceable, and due to its graphical structure, it is extremely convenient to monitor the execution status, predict potential bottlenecks, and intervene in the event of a failure, thereby improving the manageability of cross-tenant resource scheduling.

[0105] In the process of building and executing the resource scheduling subnetwork, a more complex risk of deadlock may occur. For example, the highest-scoring collaborative network node A (from tenant A) needs to wait for the resource, which is being held by a lower-scoring node D (from tenant B) that is executing an uninterruptible long-time-consuming operation. If the resource of node D is forcibly deprived, it may cause data corruption or violation of the service agreement of tenant B. At this time, only static priority sorting cannot solve the problem, and a more flexible and more business logic dynamic coordination mechanism is needed.

[0106] To deal with this high-level risk of deadlock and maintain the fairness of the platform to all tenants, a cross-tenant compensation mechanism is further introduced. The cross-tenant compensation mechanism is an automated negotiation and incentive system designed based on economic principles. Its core idea is that when a low-priority task needs to give way to a high-priority task, the tenant that performs the giving way behavior (i.e., resource transfer) will receive systematic and valuable compensation, thereby encouraging cooperation and avoiding conflict escalation.

[0107] When the resource scheduling monitor of the system detects the above-mentioned risk of deadlock in the resource scheduling subnetwork (i.e., a high-priority node waiting for a low-priority node for more than a preset maximum tolerance waiting time), the cross-tenant compensation mechanism is triggered. After triggering, the mechanism will first automatically generate a compensation package for tenant B to which the low-priority node D holding the resource belongs. The content of the compensation package is defined in advance in the platform rules and may include: providing a temporary global resource priority score enhancement coefficient for all project tasks of tenant B within the next 24 hours; or issuing a certain number of resource priority coupons to the account of tenant B, which can be used to forcibly enhance the priority of a task in any future resource competition; or directly reducing a portion of the service fee for the next period.

[0108] After the compensation package is generated and recorded, the system sends a cooperative interruption signal to node D holding the resource, requesting node D to perform a checkpoint operation (save the current progress) and release the resource gracefully. Once the resource is released, the cross-tenant compensation mechanism immediately dynamically adjusts the resource priority scores of the relevant nodes. Specifically, it may temporarily reduce the score of node D that has just transferred the resource to a very low value to ensure that it does not immediately participate in competition again. At the same time, it may slightly increase the scores of other waiting nodes to reflect the increase in waiting time cost.

[0109] After completing the dynamic adjustment of the scores, the system immediately triggers a resource reallocation process. In this process, the resource manager re-evaluates the resource allocation in the resource scheduling subnetwork based on the updated resource priority scores, and at this time, the originally waiting node A with the highest score can obtain the resource without any suspense, thereby breaking the deadlock.

[0110] By providing explicit compensation, the tenants who give up resources not only do not lose, but also gain future advantages, so they are willing to actively cooperate. This not only resolves the complex deadlock risk and ensures the smooth progress of the highest value task, but more importantly, it establishes a positive cooperative game relationship between tenants, improving the stability and user satisfaction of the entire multi-tenant platform.

[0111] S105, in response to the state change event of the source project subnode in the cross-organization collaboration network and generating the state synchronization instruction, based on the task dependency relationship, sending the state synchronization instruction to one or more second project subnodes associated with the source project subnode, the source project subnode being any first project subnode.

[0112] After the cross-organization collaboration network is constructed, in order to ensure the real-time linkage of task state and the synchronization of work between multiple organizations in the project execution process, the system needs to have the perception ability of task state change and the cross-node linkage mechanism. Step S105 listens to the state change event of any source project subnode in the cross-organization collaboration network, generates a state synchronization instruction based on the task dependency relationship, and sends the instruction to one or more second project subnodes associated with the source project subnode, thereby realizing the dynamic linkage and state consistency control between tasks.

[0113] The source project subnode refers to the node whose state changes and triggers the event perception, which belongs to any one of the first project subnode set managed by the system. The project subnode is the basic task unit in the project network, which corresponds to a specific task, stage or deliverable in the project, and is usually bound to a virtual collaboration unit and has an independent state life cycle. The state change event refers to the process of the task state of the subnode changing from one state to another state, such as changing from not started to in progress or from under review to completed. The event perception mechanism is usually implemented by a scheduling engine or a state listener, which realizes real-time monitoring of the task state through timed polling or triggered callback.

[0114] When the change of the state of the source project subnode is detected, the system will combine the task dependency relationship constructed in the foregoing to determine whether there is one or more task subnodes, i.e., second project subnodes, that depend on the node. The second project subnode refers to the successor task node that has a directed edge relationship with the source project subnode in the task dependency graph, and its execution usually depends on the completion of the source node or the state meeting a certain condition. The system determines whether to update the state or activate the task of these second project subnodes by looking up the adjacent nodes in the dependency graph and combining the trigger conditions on the dependency edges.

[0115] Once it is determined that there is a second project sub-node that meets the dependency condition, the system immediately generates a state synchronization instruction. The state synchronization instruction is a control instruction used by the platform to implement task state transfer, and the structured content usually includes fields such as identification of the source project sub-node, current state, trigger time, flag indicating whether the dependency condition is met, target sub-node identification, and recommended state update value. After the instruction is generated, it is sent to the corresponding second project sub-node through an internal message bus or a multi-tenant integration channel, and is received and processed by the collaboration unit or task agent to which it belongs, thereby realizing cascading update of the state and automatic advancement of the task.

[0116] For example, in a residential development project involving collaboration between a design institute and a developer, if the project approval sub-node of the developer changes from in progress to completed, the system identifies it as the source project sub-node and queries the task dependency graph to find that the subsequent scheme design start sub-node is responsible for the design institute and the dependency condition is completion of project approval. At this time, the system generates a state synchronization instruction including the source node identification, the state completed, the target sub-node scheme design start, and the recommended state executable, and sends the instruction to the collaboration unit service server bound to the design institute to automatically trigger the subsequent task flow.

[0117] Through the above mechanism, step S105 realizes state linkage and collaborative closed-loop control of cross-organizational project tasks during execution, avoids the problem of state transfer lag and inconsistent task start in traditional multi-organizational collaboration, and significantly improves the real-time performance, controllability, and automation level of project collaboration in a multi-tenant environment. This mechanism constitutes the core engine of task-driven collaboration in a cross-organizational collaboration network and is a key technical support for realizing linkage and scheduling of tasks inside and outside the organizational boundary.

[0118] Figure 2 is another flowchart of a cross-organizational project collaboration management method in an embodiment of the present application.

[0119] Referring to Figure 2 A cross-organizational project collaboration management method in an embodiment of the present application, the method further includes:

[0120] In a cross-organizational project collaboration scenario, there are usually significant differences between different tenants in security policies, data protection levels, and access control requirements, especially when the project involves multiple organizations and multiple system boundaries. Information sharing and permission configuration can easily lead to security risks. By introducing a project security level mechanism and tenant security policy linkage control, the overall security level of the project is compared with the maximum security level acceptable by each external collaboration tenant. In the case of risk level mismatch, a security proxy node is automatically generated and access control rules are configured to achieve dynamic isolation and permission downgrading of information flow. This mechanism can effectively prevent sensitive data or control permissions in high-security-level projects from being directly accessed by low-security-level tenants, thereby maintaining collaboration efficiency while ensuring data security, permission boundaries, and compliance requirements. It is a key technology support for secure and controllable collaboration in a multi-tenant environment, which can include steps S201-S203:

[0121] S201, obtaining a project security level of a target project and a preset tenant security policy of an external collaboration tenant in the target project;

[0122] The project security level is a security attribute marked by the platform for each project, which represents the overall level requirements of the project in terms of data sensitivity, permission control, access audit, etc. It is usually represented by a level identifier (such as L1-L5) or a score identifier (such as 1-100). The level can be specified by the project initiator or generated by a task content automatic identification algorithm.

[0123] The system also needs to obtain the preset tenant security policy of all external collaboration tenants in the project. The preset tenant security policy is a set of declarative files configured by the tenant administrator when the tenant enters the platform, which describes the security capabilities, compliance certifications, and acceptable data processing terms of the tenant's own environment. The purpose of this policy is to provide an objective basis for the platform's understanding of the tenant's security carrying capacity. The purpose of this step is to identify potential security level mismatch risks before information interaction occurs. Specifically, when a source tenant initiates a collaboration process in a target project that requires the participation of an external collaboration tenant, the system's policy management service is triggered. The service reads the attributes of the target project and obtains its project security level. Then, the service iterates through all participants in the project, identifies external collaboration tenants, and retrieves the corresponding preset tenant security policy documents from the database in the tenant management center.

[0124] S202, when the project security level is greater than the target security level, generating a security proxy node for the target external collaboration tenant in the cross-tenant virtual organization, and restructuring the organizational collaboration relationship, the target security level being the maximum security level allowed by the tenant security policy of any external collaboration tenant, and the target external collaboration tenant being an external collaboration tenant whose project security level is greater than the target security level.

[0125] The system determines the maximum security level from the tenant security policy of each external collaboration tenant, which represents the highest information sensitivity that the tenant environment can legally and compliantly handle. The system then compares the project security level of the project with the maximum security level of each external collaboration tenant. When it is determined that the maximum security level of a target external collaboration tenant is lower than the project security level of the project, the system considers that direct data interaction will constitute a security breach.

[0126] In order to bridge this security gap without interrupting business, the system must generate a security proxy node for the target external collaboration tenant in the cross-tenant virtual organization and reconfigure the organizational collaboration relationship. This can include the following steps: splitting the collaboration tasks in the target project that are directly performed by the source tenant and the target external collaboration tenant into a first collaboration path that is interacted with by the source tenant and a security proxy node, and a second collaboration path that is interacted with by the security proxy node and the target external collaboration tenant, wherein the information interaction in the second collaboration path is subject to the access control rule set.

[0127] The cross-tenant virtual organization is not a physical network structure, but a logical topology diagram defined at the software level, which depicts how different tenants interact and depend on each other in a specific project through metadata, and is used to make permission and data flow management flexible and visual. The security proxy node is a virtual service instance dynamically generated and hosted by the platform, which is not a real user or organization, and is used as a mandatory information flow intermediary and security policy enforcement point.

[0128] In implementation, after identifying the security level mismatch, the system control plane immediately invokes the service orchestration engine to instantiate a security proxy node for the target external collaboration tenant in the cross-tenant virtual organization. Then, the system modifies the routing table of the virtual organization to perform reconfiguration of the organizational collaboration relationship. The specific operation of reconfiguration is that the system splits the collaboration task path in the target project that is originally directly performed by the source tenant and the target external collaboration tenant into two logically independent paths: the first is a first collaboration path that is interacted with by the source tenant and the newly generated security proxy node, and the second is a second collaboration path that is interacted with by the security proxy node and the target external collaboration tenant. All information interactions in the second collaboration path will be strictly subject to the access control rule set configured later. The effect of this step is that a logical isolation barrier is established between the source tenant and the target external collaboration tenant, and all potential risk interactions are taken over by the security proxy node, a security valve, thereby creating a necessary technical prerequisite for subsequent refined information filtering and permission control.

[0129] S203, based on the difference value between the project security level and the target security level, configure the access control rule set for the security proxy node, and the access control rule set is used for access restriction of the project information when the project information of the target project flows to the target external collaborative tenant.

[0130] The security proxy node is only a structural placeholder at the beginning of generation, and must be configured with a policy to function. The system will configure a set of access control rules for the security proxy node based on the difference value between the project security level of the project and the target security level of the target external collaborative tenant. The security level difference value is a value calculated by quantifying the security level (such as internal level = 2, confidential level = 3), and its purpose is to provide a dynamic and adaptive measure for the strictness of the security policy. The access control rule set is a collection of specific instructions defined in a structured format (such as JSON or YAML) for guiding the security proxy node to restrict access to project information when the information flows. The purpose of configuring the access control rule set is to ensure that even in a high-level information environment, the data flowing to a low-level tenant is properly downgraded to meet the security carrying capacity of the recipient.

[0131] In the implementation process, the policy engine of the system will select and generate a suitable set of access control rules from the preset policy template library according to the calculated security level difference value. For example, a small difference value may only trigger audit and logging rules, while a large difference value may trigger multiple strict rules including field desensitization, file watermarking, and even API write permission disabling. Subsequently, the system loads the generated access control rule set into the policy execution engine of the target security proxy node through a configuration pushing mechanism. When the project information of the target project flows into the security proxy node from the first collaboration path and is ready to flow to the target external collaborative tenant in the second collaboration path, the policy engine in the proxy node will activate the access control rule set to perform real-time inspection and processing on the project information. The final effect of this step is that the security proxy node is transformed from a passive structural node to an active security execution body, which can intelligently filter and restrict data content and user behavior according to the risk level, thereby fundamentally ensuring the information security of high-security-level projects when collaborating with low-security-capability tenants.

[0132] Next, a cross-organizational project collaboration management system in the embodiment of the present application is described from the perspective of hardware processing. Please refer to Figure 3 is a structural diagram of a cross-organizational project collaboration management system in the embodiment of the present application.

[0133] It should be noted that, Figure 3The structure of the cross-organizational project collaboration management system shown is only one example and should not impose any limitations on the functions and use range of the embodiments of the present application.

[0134] As shown in Figure 3 A cross-organizational project collaboration management system includes a central processing unit (CPU) 301, which can perform various appropriate actions and processes, such as the methods described in the above embodiments, according to programs stored in a read-only memory (ROM) 302 or programs loaded from a storage section 308 into a random access memory (RAM) 303. Various programs and data required for system operation are also stored in the RAM 303. The CPU 301, the ROM 302, and the RAM 303 are connected to each other through a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0135] The following components are connected to the I / O interface 305: an input section 306 including an audio input device, a push button switch, and the like; an output section 307 including a liquid crystal display (LCD), an audio output device, an indicator lamp, and the like; the storage section 308 including a hard disk and the like; and a communication section 309 including a network interface card such as a LAN (Local Area Network) card, a modem, and the like. The communication section 309 performs communication processing via a network such as the Internet. A drive 310 is also connected to the I / O interface 305 as necessary. A removable media 311 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, and the like is attached to the drive 310 as necessary, so that a computer program read therefrom is installed in the storage section 308 as necessary.

[0136] In particular, the processes described above with reference to the flowcharts can be implemented as a computer software program according to embodiments of the present application. For example, embodiments of the present application include a computer program product including a computer program carried on a computer-readable medium, the computer program containing a computer program for executing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network by the communication section 309 and / or installed from the removable media 311. When the computer program is executed by the central processing unit 301, various functions defined in the present application are performed.

[0137] Note that specific examples of computer-readable storage media can include without limitation: electrical connection having one or more wires, portable computer diskette, hard disk, random access memory, read-only memory, erasable programmable read-only memory, flash memory, fiber optic media, portable compact disc read-only memory, optical storage device, magnetic storage device, or any suitable combination of the foregoing. In the present disclosure, computer-readable storage media can be any tangible medium that can contain, or store computer programs for use by or in connection with an instruction execution system, apparatus, or device.

[0138] The flow diagrams and the block diagrams in the drawings are illustrations of architectures, functional processes and operations that can be implemented in systems, methods and computer program products according to various embodiments of the present application. It will be understood that each block of the flow diagrams and / or block diagrams, and combinations of blocks in the flow diagrams and / or the block diagrams, can be implemented by computer program instructions. Such instructions can be implemented by one or more software programs or code segments. It should also be noted that each block of the flow diagrams and / or the block diagrams and a combination of blocks in the flow diagrams and / or the block diagrams can be implemented by hardware, software, firmware or a

[0139] In particular, the cross-organizational project collaborative management system of the embodiment includes a processor and a memory, and the memory stores a computer program. When the computer program is executed by the processor, the cross-organizational project collaborative management method provided in the above embodiment is implemented.

[0140] As another aspect, the present application also provides a computer-readable storage medium. The storage medium can be included in the cross-organizational project collaborative management system described in the above embodiment, or can exist independently without being assembled into the cross-organizational project collaborative management system. The storage medium carries one or more computer programs. When the one or more computer programs are executed by a processor of the cross-organizational project collaborative management system, the cross-organizational project collaborative management system implements the cross-organizational project collaborative management method based on Internet of Things data encryption transmission provided in the above embodiment.

Claims

1. A cross-organizational project collaborative management method, characterized in that, The method comprises: in response to a project creation request of a target user, performing project creation permission verification on the target user, the target user being a user affiliated to any tenant, the tenant including a source tenant and an external collaborative tenant; if the target user passes the project creation permission verification, constructing a cross-tenant virtual organization corresponding to a target project in the project creation request, the cross-tenant virtual organization being used to map an organizational collaboration relationship between the source tenant and the external collaborative tenant in the target project; determining the cross-tenant virtual organization as a project node in a preset project tree, the project node including a plurality of project sub-nodes, and generating creation event data of the project node, the creation event data including a node identifier of the project node and the cross-tenant virtual organization; obtaining a task dependency relationship between a plurality of first project sub-nodes, constructing a cross-organizational collaboration network based on the creation event data and the task dependency relationship, the first project sub-node being any project sub-node in any target project, and the cross-organizational collaboration network being used to represent a collaboration relationship between the first project sub-nodes in a plurality of target projects; in response to a state change event of a source project sub-node in the cross-organizational collaboration network and generating a state synchronization instruction, based on the task dependency relationship, sending the state synchronization instruction to one or more second project sub-nodes associated with the source project sub-node, the source project sub-node being any first project sub-node; the constructing a cross-organizational collaboration network based on the creation event data and the task dependency relationship specifically comprises: constructing a directed dependency graph based on the task dependency relationship, and performing loop detection in the directed dependency graph to determine a circular dependency path between the first project sub-nodes; obtaining resource information required by each first project sub-node in each circular dependency path, the resource information including resource type, resource ownership tenant, and resource occupation time; determining whether each circular dependency path has a deadlock risk caused by resource mutual exclusion according to the resource information; if the circular dependency path has the deadlock risk, calculating a resource deprivation cost for each first project sub-node in the circular dependency path based on a preset resource arbitration rule, the resource deprivation cost being used to measure a loss caused by interrupting a task of the first project sub-node; determining a collaboration priority of each first project sub-node based on the organizational collaboration relationship in the creation event data, and correcting the resource deprivation cost according to the collaboration priority to obtain a target resource deprivation cost; reconstructing each circular dependency path in the directed dependency graph based on the target resource deprivation cost, and determining the reconstructed directed dependency graph as the cross-organizational collaboration network; the reconstructing each circular dependency path in the directed dependency graph based on the target resource deprivation cost specifically comprises: in the circular dependency path, determining the first project sub-node with the lowest target resource deprivation cost as an interrupt node; A collaborative arbitration node is added between the interrupt node and the direct preceding dependency node of the interrupt node, and the target resource deprivation cost and preset inter-tenant transfer compensation rule are set as built-in judgment attributes of the collaborative arbitration node, to obtain a reconstructed circular dependency path.

2. The method of claim 1, wherein, The project creation permission verification on the target user specifically includes: When the target user belongs to the external collaborative tenant, the external collaborative tenant identifier of the target user and the project characteristic information of the target project to be created in the project creation request are obtained; Each collaborative contract in a preset collaborative contract library is traversed, and a target collaborative contract with a matching value of a keyword in the project characteristic information greater than a preset matching threshold and an authorized tenant identifier identical to the external collaborative tenant identifier is matched; When the matching is successful, it is determined that the target user passes the project creation permission verification; When the matching fails, it is determined that the target user does not pass the project creation permission verification.

3. The method of claim 1, wherein, The cross-tenant virtual organization corresponding to the target project in the project creation request is constructed, specifically including: The organization unit data of the source tenant and the external collaborative tenant in the target project is obtained, and the organization unit data includes organizational hierarchical relationship, functional attribute, personnel role information and functional attribute; Based on a preset organization mapping template, structure similarity calculation is performed on the organization unit data of the source tenant and the external collaborative tenant with the same functional attribute, and the tenants with the structure similarity greater than a preset similarity threshold are determined as organization unit pairs; The organization unit pairs with the same functional attribute are combined into virtual collaborative units, and an initial organizational collaboration relationship is established between the virtual collaborative units based on the organizational hierarchical relationship between the organization unit pairs; Based on the initial organizational collaboration relationship, a hierarchical association relationship is established between the virtual collaborative units, to obtain the cross-tenant virtual organization, and a dynamic linkage rule is configured for the virtual collaborative units, which is used to update the organizational collaboration relationship when an organization adjustment occurs in the tenants in the virtual collaborative units.

4. The method of claim 1, wherein, The method further includes: The project security level of the target project and the preset tenant security policy of the external collaborative tenant in the target project are obtained; When the project security level is greater than the target security level, a security proxy node of the target external collaborative tenant is generated in the cross-tenant virtual organization, and the organizational collaboration relationship is reconstructed, the target security level being the maximum security level allowed by the tenant security policy of any external collaborative tenant, and the target external collaborative tenant being the external collaborative tenant with the project security level greater than the target security level; Based on the difference value between the project security level and the target security level, an access control rule set is configured for the security proxy node, which is used to restrict access to the project information when the project information of the target project flows to the target external collaborative tenant.

5. The method of claim 4, wherein, The reconstructed organizational collaboration relationship specifically includes: The collaboration task directly performed by the source tenant and the target external collaborative tenant in the target project is split into a first collaboration path of interaction between the source tenant and the security proxy node, and a second collaboration path of interaction between the security proxy node and the target external collaborative tenant, wherein information interaction in the second collaboration path is subject to the access control rule set.

6. A cross-organizational project collaboration management system, characterized by, The cross-organization project collaboration management system comprises one or more processors and a memory; the memory is coupled to the one or more processors; the memory is configured to store computer program code, the computer program code comprises computer instructions, and the one or more processors invoke the computer instructions to enable the cross-organization project collaboration management system to perform the method according to any one of claims 1-5.

7. A computer-readable storage medium comprising instructions, wherein: The instructions, when executed on a cross-organization project collaboration management system, cause the cross-organization project collaboration management system to perform the method according to any one of claims 1-5.

8. A computer program product, characterised in that, The computer program product, when executed on a cross-organization project collaboration management system, causes the cross-organization project collaboration management system to perform the method according to any one of claims 1-5.

Images