• Nem Talált Eredményt

of monotonicity, i.e., sometimes the addition of a tasks to an activity decreases the throughput time of the activity. This phenomenon, known as the Braess paradox [38], is illustrated in Fig 2.13.

t dt r(t) t1 4 r1

t2 1 r3 t3 1 r1 t4 4 r2 t5 1 r1 t6 1 r1

t7 6 r3

t8 1 r2

t5

t4

t3

t2

t1

t8

t7

t6

t5

t4

t3

t2

t1

A2

A1

r3

t3

t1 t5

t4

t2

0 10

t6 t3 t1 t5

t8

t4

t2 t7

0 8 r1

r2

r3

r1

r2

Figure 2.13: Two activities illustrating the non-monotonicity of weight functions based on priority rules. AlthoughA1is a subset of activityA2, its execution according to the LFT priority rule (see page 55) takes 10 time units, while the execution ofA2 needs only 8 time units.

2.5.2 Hand-tailoring the Production Plan

A production planning system, even if it uses the most sophisticated models and the most powerful solution algorithms, is not applicable in practice if it is unable to handle occasional requirements or preferences of production engineers. This prerequisite calls for the application of mixed-initiative techniques and the support for the hand-tailoring of the production plan. Below we suggest several ways of interaction between the PPS system and the human planner.

Obviously, the plan can be edited by local modifications of the model, such as setting the time windows, or even directly the intensities of individual activities. The system then should check the consistency of the manual settings and complete the draft to a complete plan. However, applying the local modifications consistently is difficult and time consuming, especially if the changes concern many activities. In

38 2.5 Discussion

contrast,global modifications, such as the fine-tuning of the security factors, can han-dle several typical scenarios in a semi-automated way. We suggest semi-automated modifications based on thecriticality indicesof resources and activities in the specific detailed scheduling problems [4, 50, 88]. These indices measure how much a resource or an activity contributes to the objective value (e.g., makespan or maximum delay) of the given scheduling problem.

Given that the feasibility of the aggregation/disaggregation procedure cannot be guaranteed, sometimes the solutions of detailed scheduling problems do not respect every resource capacity and temporal constraint. If the capacity constraints are considered hard in the short-term scheduling problems, then this effect results in delayed tasks. Since in practice the delays will concern a few tasks only, it is likely that these tasks can be simply re-allocated to the neighboring aggregate time units.

If an application requires to treat delays already on the production planning level, then delays can be resolved by decreasing the security factors of the projects and resources whose criticality index is high.

A revision of the production plan can also be motivated by preferences that are not considered in our aggregate planning model, such as levelled resource usage.

Unless project time windows are too tight, peaks of oscillating load on a specific resource can be flattened by applying a lower, resource-specific security factor, or by specifying a finite extra capacity constraint. If the criticality index of the given resource is relatively low somewhere in the neighborhood of the overloaded time units, then flattening is possible without introducing new demand for extra capacities.

Finally, although we apply aggregate project models with minimal height, even the induced minimal project throughput times can be too high in the case of rush orders . These throughput times can be decreased further by applying higher, project-specific activity security factors. This can be realized without the risk of an inexe-cutable production plan if there are only a few rush orders.

2.5.3 Extensions and Future Research

We regard the proposed aggregation/disaggregation procedure as abasisfor aggregate production planning in make-to-order project-oriented systems. However, different practical applications may require various extensions of the presented methods. For instance, in our industrial application we considered tasks that require several re-sources for their execution (machines and human workforce), and have specificsetup

and transportation times. All this required the extension of the heuristic for the es-timation of activity throughput times, and to adapt the formula for the calculation of the resource requirements of the activities. Another straightforward extension of the model is to allow aggregate time units of different length that represent, e.g., weeks containing national holidays. Such situations can be handled by time-varying intensity boundsjτA= min(1, µd(A)AΘτ) on the activities.

While we assumed that all required raw material is available by the earliest start time of the projects, in some applications raw material arrival can be a realistic bottleneck. In such cases, aggregate project models can be optimized by inserting m pieces of dummy tasks with durations of Θ before each task whose raw materials arrive in themth aggregate time unit, see Fig. 2.14.

1 3

6

8 9 11

2 4 5

7

10 12 13

Switch

Porcelain rod

Figure 2.14: Modification of the sample project tree for the case where the switch and the porcelain rod arrive on the 3nd and 2nd time unit of the aggregate horizon, respectively.

A noteworthy extension of the aggregation procedure would be its adaption to problems where the graph of precedences among the tasks constitutes a directed acyclic graph (DAG), instead of an in-tree. Although such a generalization of the introduced notions is trivial, this extension induces graph partitioning problems that are NP-complete [39]. Accordingly, the construction of appropriate heuristic parti-tioning algorithms is inevitable.

Currently, we are working on the adaptation of the framework to manufacturing systems that carry out a combination of project- and inventory-oriented produc-tion. Inventory-oriented activities produce common components for project-oriented activities, which in turn, are responsible for the satisfaction of customer orders. Com-ponents are not dedicated to projects. Instead, they are treated as non-renewable resources – so-calledreservoirs – produced or consumed by different activities.