Experiment 1 (Small Scale): The company has 16 employees for 16 corresponding tasks () at the operational level (Level 1). To represent the quality of skills, employees are divided into 4 groups of qualifications and can only be assigned to the corresponding subsets of tasks, as dictated by the binary qualification mask. To manage the generated workload and systemic backlog, 4 managers () are distributed across 4 processing nodes () at the managerial level (Level 2).
To account for stochastic variability, a symmetric triangular distribution was applied to the values of the curve. The choice of this distribution allows the natural variation in human behaviour to be captured without distorting the basic dynamics of the change curve used as the basis for the model.
In this paper, the basic attributes of the Classical Change Management Model (CCMM) are adopted and used as a reference (ground-truth) curve for the design of new simulation experiments.
4.1. Small Scale Experiment and Algorithm Implementation
The application of the proposed CoMoRe hierarchical algorithm begins at time , which corresponds to the initial baseline and the start of the change period. In the first (small-scale) experiment, operational level (Level 1) consists of 16 employees and 16 corresponding tasks, resulting in the construction of a employee performance table . At the same time, for the managerial level (Level 2), 4 managers and 4 processing nodes are defined, with a corresponding managerial performance table .
In contrast to the original (single-level) formulation of CoMoRe, in the proposed model the assignment of employees to tasks is not completely free. A binary suitability mask is used, which describes the constraints on qualifications, so that each employee can only be assigned to a suitable task subset. In the first experiment, the 16 employees are grouped into 4 qualification groups, and each group can only take on the corresponding subset of tasks.
At time , the initial performance values of employees and managers are defined as high-performance starting conditions, while the initial systemic backlog is set to zero, i.e., for all processing nodes k. In addition, the basic managerial capacities used to calculate the effective processing capacity at the second level are initialized.
As an initial condition of the algorithm, the performance of each employee for each possible task is randomly generated within the range 90–100 (i.e., 90–100%). An indicative set of values is presented in
Table 2.
Consequently, the initial performance table is combined with the
binary qualification matrix mask, shown in
Table 3, to define the optimal assignment before the first optimization step.
At the same time, for the managerial level, a
initial performance matrix of managers–nodes is created and randomly generated within the high initial performance range of 90–100 (i.e., 90–100%), presented in
Table 4, so that the system starts from a state of high managerial efficiency.
In addition, the base capacity of each manager (
) is initialized. In the small-scale experiment, each manager’s basic capacity is generated from a symmetric triangular distribution (minimum 380, mode 400, maximum 420), ensuring that managers have sufficient capacity to handle the maximum workload generated by employees (
units). Based on the capacities (
) and initial performance (
), the effective capacity
is calculated, using Equation (
12), as presented in
Table 5.
According to Algorithm 1, in Step 2, the assignment of employees to level 1 tasks is optimized using the Hungarian algorithm to maximize overall performance, subject to the constraints of quality
of Equation (
8). The masked employee performance matrix
after applying
is shown in
Table 6 and the resulting optimal allocation at
is reported in
Table 7.
The total performance at
is computed as the sum of the performance values corresponding to the optimal assignment, with the detailed results provided in
Table 7. As a theoretical upper bound, if all 16 employees achieved a performance of 100 on their assigned tasks, the maximum total performance would be 1600 (
). In the case we are examining here, the optimal allocation results in a total return of 1562.
The third step of the algorithm is based on the optimal level 1 allocations determined in step 2. The workload generated at each management node,
, is calculated using Equation (
10). Since the backlog is initialized to zero,
, it follows that
at the initial time step. For
, the computed values are summarized in
Table 8.
A defining feature of the proposed Hierarchical CoMoRe framework is the dynamic relationship between the work performance of Level 1 employees and the resulting workload for Level 2 managers. In this hierarchical structure, an employee’s performance () does not simply represent the accomplishment of a task, but is directly translated into processing demand for the corresponding managerial node. Specifically, the cumulative operational output of all employees assigned to the tasks of node k constitutes the newly generated workload .
Consequently, high operational efficiency at the lower tier generates a proportionally high supervisory or administrative demand. As established, since the system backlog at is zero (), the initial demand is strictly equal to the generated workload . So in this first time period the total initial performance of employees, amounting to 1562 units, translates directly into 1562 units of managerial workload, distributed across the four nodes. To maintain system stability, the appointed managers must have effective capacity () to process this incoming demand. Otherwise, the unserviced workload will be converted into system backlog for the next time period.
In the initial execution (
), in Step 4, the Hungarian algorithm is applied at the managerial level. Managers are assigned to processing nodes via the decision variable
to minimize the total unserviced workload, as defined in Equation (
13). To determine the optimal allocation, the algorithm first calculates a scoring matrix for all possible manager–node combinations. Each element of this matrix represents the negative value of the potential backlog (deficit), which is explicitly calculated as
. These results, shown in
Table 9, represent the unserviced workload. In this experiment, at the initial execution (
), the fact that all entries are negative indicates that no manager has sufficient capacity to fully satisfy the demand of any node, making some backlog unavoidable.
Based on this scoring matrix, the algorithm calculates the optimal binary assignment, represented by the decision variables
in
Table 10. A value of 1 indicates the selected manager–node combination that minimizes total unserviced workload.
Next, in Step 5,
Table 11 shows what actually results from these optimal assignments. At each node, the workload that is finally processed
cannot exceed the available effective capacity of the manager assigned there. Any task that cannot be processed becomes backlog
and is carried over to the next period.
is calculated from Equation (
17) and
is updated from Equation (
19), with
for the manager assigned to the node. With this optimal allocation, the total backlog passing at
is kept to a an optimal (minimum) of 39.1 units.
This optimal allocation and the initial values of all parameters (for employees and managers) are used as a common “starting point” for both the proposed framework and the CCMM. That is, both models start at with exactly the same conditions across the hierarchy: the same initial performances, the same available capacities, and zero resistance. Furthermore, to ensure that luck does not influence the results, exactly the same resistance matrices are used in both models at each time step. Thus, any difference in the results is caused by the way each mode operates and not by different input data.
After the calculations in Step 5, the algorithm proceeds to Step 6 to calculate the RtC for employees and managers. As shown in
Table 1, in the initial state (
t = 0) the resistance is considered zero.
Therefore, in Step 7, the new performance values are recalculated for the next time step according to Equations (
21) and (
22). The performance capacities for
remain unchanged. Therefore, as the simulation progresses to
, the Layer1 temporarily exhibits optimal initial performance. However,
marks the beginning of the change implementation, resulting in resistance to change that affects both levels of the hierarchical model. As shown in
Table 1, the algorithm samples the first non-zero resistance values from a symmetric triangular distribution with parameters (0, 10, 20). The realized resistance values for the managerial level at this time step are reported in
Table 12.
Using the same stochastic approach, RtC for employees is generated by random sampling from a triangular distribution. That is, for each assignment of employee
i to task
j, the algorithm samples a random resistance value
from a triangular distribution defined by three limits
as in
Table 1. All
values are collected in
matrix. The matrix for
is shown in
Table 13 and shows that employees exhibit different levels of RtC.
Using the updated performance matrices using Equations (
21) and (
22) and the accumulated system backlog, the optimization procedure is repeated iteratively until the simulation ends at time
T. At Level 1 (Operational), the Hungarian algorithm is re-applied to reallocate employees to tasks, maximizing total achievable performance subject to the quality constraints
. The resulting output is calculated at the processing nodes to compute the workload
and the total demand
. At Level 2 (Managerial), a second Hungarian optimization reallocates managers to nodes, accounting for the dynamically updated effective capacities
and minimizing unserviced work. Finally, the processed workload
is computed and any remaining unmet demand is carried forward as backlog
.
The key innovation of Hierarchical CoMoRe is that it does not keep assignments “fixed” as changes progress. Instead, it continuously monitors the situation and anticipates resources at two levels: at the operational level (tasks/employees) and at the managerial level (managers/nodes). Thus, when performance drops and a backlog begins to accumulate, the model adjusts assignments to address the problem. This is a key advantage over CCMM, which keeps assignments the same and does not “react” when conditions change. As a result, Hierarchical CoMoRe makes better use of resources and reduces the risk of excessive workload accumulation, which could lead to a collapse of the operation and, ultimately, to the failure of change plans.
4.2. Small Scale Experiment, Results and Analysis
To thoroughly test how effective and reliable the Hierarchical CoMoRe is, simulations are run many times, from 100 to 100,000 repetitions. This shows whether the results are stable and do not change simply due to random, temporary fluctuations. Also, as the repetitions increase, it is checked whether the algorithm can withstand a larger scale and remains stable. The goal of the experiments is to show that HCoMoRe remains better than CCMM, regardless of how many repetitions are made.
For each scenario, the average total processed work per time step was calculated across all independent runs. Since the results obtained from 10,000 repetitions exhibited no significant deviation from those of 100,000 repetitions, it was concluded that the system had reached convergence, rendering further increases in the number of repetitions unnecessary.
Figure 4 compares the average processed work of the proposed Hierarchical CoMoRe method with that of the CCMM, which is based on the classical change curve. Additionally,
Table 14 summarizes the corresponding numerical values used to generate the curves in
Figure 4.
The comparison of the curves shows that Hierarchical CoMoRe has an advantage over CCMM because it can adaptively reallocate resources on two levels. At the beginning (from to ), the two models perform the same and process approximately 1500 units, as they start with the same initial assignments. The difference appears when resistance to change is high (from to ). In both models, performance declines, but HCoMoRe shows better results: at its lowest point , it reaches approximately 500 units, while CCMM drops to approximately 350 units. HCoMoRe responds more quickly and allocates resources more efficiently. In the recovery phase (from to ), HCoMoRe increases more sharply and stabilizes around 2150 units towards the end (from to ). In contrast, CCMM stabilizes at a lower level, around 1900 units, because its static assignments continue to accumulate backlog.
Table 14 provides numerical data that is also shown in
Figure 4. Particularly at 100,000 repetitions, it is clear that the adaptive redistribution of the Hierarchical CoMoRe significantly improves performance. At the lowest point of change (
), where resistance is at its maximum, CCMM drops very low (358.57 units), while Hierarchical CoMoRe maintains a significantly higher performance (518.17 units). Towards the end (
), Hierarchical CoMoRe also stabilizes at a better level (2145.20) compared to CCMM (1886.12). This is also evident in the total sum of the processed work: in 100,000 repetitions, Hierarchical CoMoRe reaches 25,579.93 units, while CCMM reaches 22,101.48. Therefore, overall, Hierarchical CoMoRe performs better. Finally, because the results at 1000, 10,000, and 100,000 repetitions are very close to each other, this shows that the model has essentially converged and the significant results do not change as the repetitions increase. This leads us to the practical conclusion that there is no reason to increase the number of repetitions significantly.
In addition to evaluate the effectiveness of the two models in practice,
Table 15 shows the backlog (pending tasks) that accumulates at each time step for different numbers of repetitions (100 to 100,000). At the starting point (
), both models begin with approximately the same, tiny amount of backlog. However, because CCMM holds static assignments and does not adapt when conditions change, it quickly begins to accumulate backlog. For example, at 100,000 repetitions, by
, the CCMM’s backlog reaches 565.78 units, while the Hierarchical CoMoRe keeps it lower, at 387.85 units. The biggest difference is seen at the end (
): the CCMM achieves a backlog of 1895.79 units, while the Hierarchical CoMoRe, as a result of adaptive reallocation, limits it to 1252.35 units. This shows that HCoMoRe is better and keeps the system more under control.
In summary, the results indicate that Hierarchical CoMoRe’s two-level adaptive reallocation not only enables faster recovery but also improves long-run stability by limiting sustained performance degradation and backlog accumulation. To complement these visual observations with a larger-scale assessment and quantify the framework’s impact under more realistic organizational complexity, we next apply the Hierarchical CoMoRe model to a larger company setting with 160 employees and 40 managers.
4.3. Large Scale Experiment and Algorithm Implementation
In the second experiment, we extend the organizational hierarchy to a hypothetical company with 160 employees and 160 corresponding tasks (
). To preserve the two-level structure, we introduce a management layer with 40 nodes (
). This larger setting is used to evaluate the effectiveness, efficiency, and computational scalability of the proposed Hierarchical CoMoRe framework under increased organizational complexity. The change process horizon, which captures behavioural reactions and resistance accumulation during change, is fixed at 20 time steps (
). Simulations are run for 100, 1000, 10,000, and 100,000 repetitions using the same stochastic sampling procedure as in the first experiment.
Table 16 present the total processed work per time step for Hierarchical CoMoRe and the static CCMM baseline.
Table 17 compares the Total Processed Work Improvement (TPWI) in percentage between the two methods across all time intervals while
Table 18 presents the corresponding accumulated backlog per time step. The contents of the Tables are explained in more detail below.
Table 16 shows the total work processed for a system consisting of 160 employees and 40 managers. The results clearly show that as the size of the organization increases, the absolute benefits of Hierarchical CoMoRe adaptive reallocation become more significant. Although the general pattern of behavior remains consistent with smaller-scale experiments, confirming the stability of the model, the performance gap during the change period is notable. At the peak of the RtC (
), the CCMM’s performance drops to 3703.43 units, while HCoMoRe successfully captures the RtC, achieving 5800.02 units. Furthermore, reaching the final stabilization point (
), HCoMoRe reaches 22,328.28 points per time step, far exceeding the 18,979.74 points of CCMM. Ultimately, this improved real-time adaptability translates into a huge cumulative advantage: Hierarchical CoMoRe processes a total of 268,307.95 units, compared to 223,517.48 for CCMM. This remarkable difference of almost 45,000 units clearly demonstrates that the proposed dynamic reallocation is not only scalable, but absolutely necessary to prevent serious bottlenecks in large enterprise change processes.
Table 17 compares the Total Processed Work Improvement (TPWI) in percentage between the two methods across all time intervals. The Total Processed Work Improvement is defined as follows:
where
and
denote the total processed work achieved by the proposed Hierarchical CoMoRe and the classic CCMM methods, respectively.
As shown in
Table 17 the Total Processed Work (TPWI) index clearly quantifies the potential advantage of Hierarchical CoMoRe over the CCMM approach. As demonstrated in
Table 17, the Total Processed Work (TPWI) index is found to be most significant during the critical points of the change period (
and
). At these points, the CoMoRe framework achieves an exceptional improvement of approximately 56.8%. This highlights the critical ability of the model to monitor in real time and assign human resources to nodes precisely when the system experiences the greatest drop in performance. As the change process and the system recovers, the improvement rate stabilizes. This ultimately leads to an extremely significant overall cumulative improvement of approximately 20% across all iteration levels. This steady 20% gain on total workload highlights the significant operational and business value of applying the Hierarchical CoMoRe model in large-scale organizational environments.
The most decisive evidence of Hierarchical CoMoRe’s superiority is presented in
Table 18, which depicts the accumulated workload (backlog) per time step for the large-scale organizational structure. These results reveal a catastrophic failure of the static CCMM approach when applied to large-scale environments. While both models maintain a small backlog at the start of the simulation (
), CCMM’s inability to adapt to changes in RtC causes the backlog to grow uncontrollably. At the final time step (
), the traditional CCMM method results in a huge accumulated workload of 16,424.13 pending tasks. In contrast, Hierarchical CoMoRe successfully suppresses bottlenecks, maintaining a low final backlog of just 18.06 units across all iteration levels. The evidence indicates that in complex, large-scale business change process, dynamic resource reallocation is not simply an option for enhancing performance. It is an operational necessity to prevent a possible complete collapse of the system.
To address the practical constraints arising from multiple reallocations of human resources in real-world conditions,
Table 19 presents a sensitivity analysis based on a “reallocation threshold.” In the real world, continuous reallocations of human resources are not always practical, even if they are mathematically optimal. Each reallocation requires time for coordination and information, causes a temporary loss of productivity when adapting to a new position or task, and creates administrative costs. For this reason, a threshold is necessary to allow reallocations only when a real benefit is expected and prevent small and insignificant reallocations. This threshold defines the minimum performance improvement required for a reallocations to be approved, acting essentially as a means of avoiding unnecessary reallocations.
At the 50% threshold, the organization performs only 58.9% of employee reallocations and 55.0% of manager reallocations compared with the 0% threshold case. At the same time, it preserves 98.5% of maximum performance and keeps the final backlog low (55). Furthermore, at the 90% reallocation threshold, the system keeps almost the same performance and the backlog remains relatively low (1872), with only 33 employee reallocations and 55 manager reallocations.
In contrast, increasing the threshold to 100% strictly prohibits all reallocations, returning the system to the static behaviour of CCMM, which leads to operational collapse with 16,424 pending tasks. This analysis demonstrates that the Hierarchical CoMoRe framework works well in extensive simulations, but the reallocation threshold results should be interpreted as a simulation-based evidence of a trade-off between performance and reallocation frequency, rather than as a direct proof of real-world effectiveness.
The proposed hierarchical framework solves two assignment problems at each time step, one at the employee level and one at the managerial level. As both subproblems are solved using the Hungarian algorithm, their theoretical time complexity is
and
, respectively. Hence, the dominant complexity per time step is approximately
.
Table 20 complements this theoretical result with an empirical execution-time analysis for different organizational sizes.
Table 20 reports the execution times of the Hungarian-based assignment component, the remaining update operations, and the total runtime for different organizational sizes. The results show that the total execution time increases with problem size, while remaining computationally manageable within the tested setting. For the largest tested case
, the average total runtime was 2.3257 s. The Hungarian-based assignment component accounts for approximately 21% of the total runtime, while the remaining update operations account for the larger share of the computational cost. These results indicate that the proposed framework remains feasible for large organizational units, although the non-assignment update steps constitute the dominant cost in the current implementation.