Production Planning and Scheduling

Abstract

Assuming that the master plan has been generated, we can now derive detailed plans for the different plants and production units. In the following we will describe the underlying decision situation (Sect. 10.1) and outline how to proceed from a model to a solution (Sect. 10.2). Some of these steps will be presented in greater detail, namely model building (Sect. 10.3) and updating a production schedule (Sect. 10.4). Whether Production Planning and Scheduling should be done by a single planning level or by a two-level planning hierarchy largely depends on the production type of the shop floor. This issue will be discussed together with limitations of solution methods in Sect. 10.5.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Assuming that the master plan has been generated, we can now derive detailed plans for the different plants and production units. In the following we will describe the underlying decision situation (Sect. 10.1) and outline how to proceed from a model to a solution (Sect. 10.2). Some of these steps will be presented in greater detail, namely model building (Sect. 10.3) and updating a production schedule (Sect. 10.4). Whether Production Planning and Scheduling should be done by a single planning level or by a two-level planning hierarchy largely depends on the production type of the shop floor. This issue will be discussed together with limitations of solution methods in Sect. 10.5.

1 Description of the Decision Situation

Production Planning and Scheduling aims at generating detailed production schedules for the shop floor over a relatively short interval of time. A production schedule indicates for each order to be executed within the planning interval its start and completion times on the resources required for processing. Hence, a production schedule also specifies the sequence of orders on a given resource. A production schedule may be visualized by a gantt-chart (see Fig. 10.4).

The planning interval for Production Planning and Scheduling varies from 1 day to a few weeks depending on the industrial sector. Its “correct” length depends on several factors: On the one hand it should at least cover an interval of time corresponding to the largest throughput time of an order within the production unit. On the other hand the planning interval is limited by the availability of known customer orders or reliable demand forecasts. Obviously, sequencing orders on individual resources is useful only if these plans are “reasonably” stable, i.e. if they are not subject to frequent changes due to unexpected events like changing order quantities or disruptions.

For some production types (like a job shop) Production Planning and Scheduling requires sequencing and scheduling of orders on potential bottlenecks. For other production types (like group technology) an automated, bucket-oriented capacity check for a set of orders to be processed by a group within the next time bucket(s) will suffice. Sequencing of orders may then be performed manually by the group itself.

Planning tasks can and should be done decentrally, utilizing the expertise of the staff at each location and its current knowledge of the state of the shop floor (e.g. the availability of personnel). Readers interested in the daily business of a planner and scheduler and resultant requirements for decision support are referred to McKay and Wiers (2004).

The master plan sets the frame within which Production Planning and Scheduling at the decentralized decision units can be performed. Corresponding directives usually are:

• The amount of overtime or additional shifts to be used

• The availability of items from upstream units in the supply chain at different points in time

• Purchase agreements concerning input materials from suppliers—not being part of “our” supply chain.

Furthermore, directives will be given by the master plan due to its extended view over the supply chain and the longer planning interval. As directives we might have

• The amount of seasonal stock of different items to be built up by the end of the planning horizon (for production units facing a make-to-stock policy)

• Given due dates for orders to be delivered to the next downstream unit in the supply chain (which may be the subsequent production stage, a shipper or the final customer).

2 How to Proceed from a Model to a Production Schedule

The general procedure leading from a model of the shop floor to a production schedule will be described briefly by the following six steps (see Fig. 10.1).

Fig. 10.1

General procedure for production scheduling

2.1 Step 1: Model Building

A model of the shop floor has to capture the specific properties of the production process and the corresponding flows of materials in a detail that allows to generate feasible plans at minimum costs.

Only a subset of all existing resources on the shop floor—namely those which might turn out to become a bottleneck—will have to be modeled explicitly, since the output rate of a system is limited only by these potential bottlenecks. Details on model building are presented in Sect. 10.3.

2.2 Step 2: Extracting Required Data

Production Planning and Scheduling utilizes data from

• An ERP system

• Master Planning

• Demand Planning.

Only a subset of the data available in these modules will be used in Production Planning and Scheduling. Therefore, it is necessary to specify which data will actually be required to model a given production unit (see step 2 in Fig. 10.1).

2.3 Step 3: Generating a Set of Assumptions (A Scenario)

In addition to the data received from sources like the ERP system, Master Planning and Demand Planning the decision-maker at the plant or production unit level may have some further knowledge or expectations about the current and future situation on the shop floor not available in other places (software modules). Also, there may be several options with respect to available capacity (e.g. due to flexible shift arrangements).

Therefore, the decision-maker must have the ability to modify data and thereby to set up a certain scenario (step 3, Fig. 10.1: A dotted frame indicates that this step has to be performed by the decision-maker and is optional).

2.4 Step 4: Generating a (Initial) Production Schedule

Next, a (initial) production schedule will be generated for a given scenario, automatically (step 4, Fig. 10.1). This may be done either by a two-level planning hierarchy or in one step (for more details see Sect. 10.4).

2.5 Step 5: Analysis of the Production Schedule and Interactive Modifications

If there is a bucket-oriented upper planning level then this production plan may be analyzed first before a detailed schedule is generated (step 5, Fig. 10.1). Especially, if the production plan is infeasible, the decision-maker may indicate some course of action interactively to balance capacities (like the introduction of overtime or the specification of a different routing). This may be easier than modifying a detailed sequence of operations on individual resources (lower planning level). Infeasibilities—like exceeding an order’s due date or an overload of a resource—are shown as alerts (see Sect. 13.1).

Also, a solution generated for a scenario may be improved by incorporating the experience and knowledge of the decision-maker, interactively. However, to provide real decision support, the number of necessary modifications should be limited.

2.6 Step 6: Approval of a Scenario

Once the decision-maker is sure of having evaluated all available alternatives, he/she will choose the most promising production schedule relating to a scenario.

2.7 Step 7: Executing and Updating the Production Schedule

The production schedule selected will be transferred to

• The MRP module to explode the plan (Chap. 11)

• The ERP system to execute the plan

• The Transport Planning module for generating routes and vehicle loadings to deliver customer orders.

The MRP module performs the explosion of all planned activities on bottleneck resources to those materials that are produced on non-bottleneck resources or those to be purchased from suppliers. Furthermore, required materials will be reserved for certain orders.

The schedule will be executed up to a point in time where an event signals that a revision of the production schedule seems advisable (loop II; Fig. 10.1). This may be an event like a new order coming in, a breakdown of a machine or a certain point in time where a given part of the schedule has been executed (for more details on updating a production schedule see Sect. 10.4).

Changing the model of the plant is less frequent (loop I; Fig. 10.1). If the structure remains unaltered and only quantities are affected (like the number of machines within a machine group or some new variants of known products), then the model can be updated automatically via the data that is downloaded from the ERP system. However, for major changes, like the introduction of a new production stage with new properties, a manual adaptation of the model by an expert is advisable.

We will now describe the task of modeling the production process on a shop floor in greater detail.

3 Model Building

A model of the shop floor has to incorporate all the necessary details of the production process for determining (customer) order completion times, the input required from materials and from potential bottleneck resources. The time grid of a production schedule is either very small (e.g. hours) or even continuous.

3.1 Level of Detail

The model can be restricted to operations to be performed on (potential) bottlenecks, since only these restrict the output of the shop floor.

Since Production Planning and Scheduling is (currently) not intended for controlling the shop floor (which is left to the ERP system) some details of the shop floor—like control points monitoring the current status of orders—can be omitted.

All processing steps to be executed on non-bottleneck resources in between two consecutive activities modeled explicitly are only represented by a fixed lead-time offset. This recommendation is no contradiction to the well-known statement that Advanced Planning yields lead-times as a result of planning and not as an a priori given constant. Here, the lead-time offset consists only of processing and transportation times on preceding non-bottleneck resources, since in general waiting times will not exist.

The model can be defined by the associated data. We discriminate between structural data and situation-dependent data.

Structural data consists of

• Locations

• Parts

• Bill of materials

• Routings and associated operating instructions

• (Production) resources

• Specification of suppliers

• Setup matrices

• Timetables (calendars).

In a large supply chain with many plants at different locations it may be advantageous to attribute all the data to a specific location. Consequently, a part can be discriminated by its production location even if it is the same in the eyes of the customer.

The bill of materials is usually described on a single-level basis (stored in a materials file). There, each part number is linked only to the part numbers of its immediate predecessor components. A complete bill of materials for a given part may be constructed easily on a computer by connecting the single-level representations.

The resource consumption per item can be obtained from the routings and operating instructions . Both the number of items per order as well as the resource consumption per item are required for sequencing and scheduling of individual orders. Hence, a combination of the two representations called Production Process Model (abbreviated by PPM) concept is appealing.

As an example the PPMs in Fig. 10.2 describe the two-stage production of ketchup bottles of a specific size and brand. The first PPM represents production of the liquid—including cleaning the tub, stirring the ingredients and waiting to be filled up in bottles. Once the liquid is ready it has to be bottled within the next 24 h. The liquid can be used in bottles of different sizes. For each size there will be an individual PPM. Also the liquid ketchup can be used up for different bottle sizes simultaneously.

Fig. 10.2

A Production Process Model (PPM) for a two stage ketchup production

A PPM is made up of at least one operation while each operation consists of one or several activities . An operation is always associated with one primary resource (like a tub). Secondary resources—like personnel—can also be attributed to an activity.

Activities may require some input material and can yield some material as an output. Surely, it has to be specified, at which point in time an input material is needed and when an output material is available. The technical sequence of activities within an operation—also called precedence relationships—can be represented by arcs. Like in project planning activities can be linked by

• End-start, end-end, start-end and start-start relationships together with

• Maximal and minimal time distances.

This allows a very precise modeling of timing restrictions between activities including the parallel execution of activities (overlapping activities).

The timing as well as the resource and material requirements of a (customer) order may be derived by linking the associated PPMs by the so-called pegging arcs (bolt and dotted arcs in Fig. 10.3). Pegging arcs connect the input material (node) of one PPM with the respective output material (node) of the predecessor (upstream) PPM. Consequently, exploding an order (see order C505X in Fig. 10.3) and the corresponding PPMs, starting with the final production stage, yields information about resource and material consumption within respective time windows. These time windows may be used directly when generating a feasible schedule (see also Vollman et al. 1997, p. 804).

Fig. 10.3

Pegging: linking two Production Process Models (PPMs)

PPMs may be stored and updated solely within an APS. This option allows to take into account more details—like timing restrictions—than are usually stored and maintained in an ERP system. On the other hand operating instructions and routings are also kept in an ERP system. As one can imagine this may give rise to inconsistencies. Hence, some APS vendors propose to take (only) the data from the ERP system and to transfer the BOM, operating instructions and routings to the APS whenever a new production schedule will be created. From these so called runtime objects are created resulting in the PPMs needed for an APS. Instead of using runtime objects also flat (ASCII) files may be used.

The (factory) calendar indicates breaks and other interruptions of working hours of resources. Another information included will be whether a plant (or resource) is operated in one, two or three shifts. Usually Advanced Planning Systems offer several typical calendars to choose from.

Situation-dependent data varies with the current situation on the shop floor. It consists of

• Initial inventories, including work-in-process

• Setup state of resources

• Set of orders to be processed within a given interval of time.

Operational procedures to be specified by the user may consist of

• Lot-sizing rules

• Priority rules or

• Choice of routings .

Although rules for building lot sizes should ideally be based on the actual production situation—like utilization of resources and associated costs—Advanced Planning Systems often require to input some (simple) rules a priori. Such rules may be a fixed lot size, a minimum lot size or a lot size with a given time between orders. Software packages might either offer to pick a rule from a given set of rules or to program it in a high level programming language. Note that fixing lot sizes to the Economic Order Quantity (EOQ) does not seem wise in many cases because even large deviations only result in small cost increases (regarding setup and inventory holding costs). Instead, lot-sizing flexibility should be regarded a cheap means to smooth production and to avoid overtime (see Stadtler 2007 for a detailed analysis). Rules for determining sequences of orders on a certain resource are handled in a similar fashion (for more details on priority rules see Silver et al. 1998, p. 676).

If alternative routings exist to perform a production order then one should expect that the system chooses the best one in the course of generating a production schedule. However, we experienced that the user has to pick one “preferred” routing. Sometimes alternative routings are input as a ranked list. Only if a preferred routing leads to infeasibilities the solver will try the second best routing, then the third best etc.

3.2 Objectives

Last but not least objectives will have to be specified. These guide the search for a good—hopefully near optimal—solution. As objectives to choose from within Production Planning and Scheduling we observed mainly time oriented objectives like minimizing the

• Makespan

• Sum of lateness

• Maximum lateness

• Sum of throughput times

• Sum of setup times.

Three objectives referring to costs should be mentioned, too, namely the minimization of the sum of

• Variable production costs

• Setup costs

• Penalty costs.

Although the degree of freedom to influence costs at this planning level is rather limited one can imagine that the choice of different routings, e.g. declaring an order to be a standard or a rush order, should be evaluated in monetary terms, too.

Penalty costs may be included in the objective function, if soft constraints have been modeled (e.g. fulfilling a planned due date for a make-to-stock order).

If the decision-maker wants to pursue several of the above objectives, an “ideal” solution, where each objective is at its optimum, usually does not exist. Then a compromise solution is looked for. One such approach is to build a weighted sum of the above individual objectives. This combined objective function can be handled like a single objective, and hence, the same solution methods can be applied (for more details on multi-objective programming see Ehrgott 2006, Eiselt and Sandblom 2012, p. 105).

3.3 Representation of Solutions

There are several options for representing a model’s solution, namely the detailed production schedule. It may simply be a list of activities with its start and completion times on the resources assigned to it. This may be appropriate for transferring results to other modules.

A decision-maker usually prefers a gantt-chart of the production schedule (see Fig. 10.4). This can be accomplished by a gantt-chart showing all the resources of the plant in parallel over a certain interval of time. Alternatively, one might concentrate on a specific customer order and its schedule over respective production stages. Likewise, one can focus attention on one single resource and its schedule over time.

Fig. 10.4

Gantt-chart for four orders on one machine with due dates and sequence dependent setup times

If the decision-maker is allowed to change the production schedule interactively—e.g. by shifting an operation to another (alternative) resource—a gantt-chart with all resources in parallel is the most appropriate.

Now, we will point our attention to the options of updating an existing production schedule.

4 Updating Production Schedules

Production Planning and Scheduling assumes that all data is known with certainty, i.e. the decision situation is deterministic. Although this is an ideal assumption, it may be justified for a certain interval of time. To cope with uncertainty—like unplanned variations of production rates or unexpected downtime of resources—software tools allow monitoring deviations from our assumptions taking place on the shop floor immediately, resulting in updated expected completion times of the orders. Whether these changes are that large that a reoptimized schedule is required will be based on the decision-maker’s judgment. Current software tools will enhance this judgment by providing extensive generation and testing facilities of alternative scenarios (also called simulation) before a schedule is actually delivered to the shop floor (see also steps three to five; Fig. 10.1).

Another feature to be mentioned here is a two step planning procedure—also called incremental planning. Assume that a new order comes in. If it falls into the planning horizon of Production Planning and Scheduling the activities of this new customer order may be inserted into the given sequence of orders on the required resources. Time gaps are searched for in the existing schedule such that only minor adjustments in the timing of orders result. If feasibility of the schedule can be maintained a planned due date for the new customer order can be derived and sent back to the customer.

Since this (preliminary) schedule may be improved by a different sequence of orders, reoptimization is considered from time to time, aiming at new sequences with reduced costs.

The following example will illustrate this case. Assume there are four orders that have to be scheduled on a certain machine with given due dates and the objective is to minimize the sum of sequence dependent setup times (Tables 10.1 and 10.2). Then the optimal sequence will be A-B-C-D (see Fig. 10.4). The current time is 100 (time units). Processing times for all orders are identical (one time unit). Sequence dependent setup times are either 0, 1/3, 2/3 or 1 time unit.

Table 10.1 Data: due dates

Table 10.2 Data: matrix of setup times

After having started processing order A, we are asked to check whether a new order E can be accepted with due date 107. Assuming that preemption is not allowed (i.e. interrupting the execution of an order already started in order to produce another (rush) order), we can check the insertion of job E in the existing sequence directly after finishing orders A, B, C or D (see Fig. 10.5). Since there is a positive setup time between order A and E this sub-sequence will not be feasible since it violates the due date of order B. Three feasible schedules can be identified, where alternative c has the least sum of setup times. Hence, a due date for order E of 107 can be accepted (assuming that order E is worth the additional setup time of one time unit).

Fig. 10.5

Generating a due date for the new customer order E

Once reoptimization of the sequence can be executed, a new feasible schedule—including order E—will be generated reducing the sum of setup times by 1/3 (see Fig. 10.6).

Fig. 10.6

Reoptimized schedule

Generating new sequences of orders is time consuming and usually will result in some nervousness. We discriminate nervousness due to changes regarding the start times of operations as well as changes in the amount to be produced when comparing an actual plan with the previous one. Nervousness can lead to additional efforts on the shop floor—e.g. earlier deliveries of some input materials may be necessary which has to be checked with suppliers. In order to reduce nervousness usually the “next few orders” on a resource may be firmed or fixed, i.e. their schedule is fixed and will not be part of the reoptimization. All orders with a start time falling within a given interval of time—named frozen horizon —will be firmed.

5 Number of Planning Levels and Limitations

5.1 Planning Levels for Production Planning and Scheduling

As has been stated above, software modules for Production Planning and Scheduling allow to generate production schedules either within a single planning level or by a two-level planning hierarchy. Subsequently, we will discuss the pros and cons of these two approaches.

Drexl et al. (1994) advocate that the question of decomposing Production Planning and Scheduling depends on the production type given by the production process and the repetition of operations (see Chap. 3 for a definition). There may be several production units within one plant each corresponding to a specific production type to best serve the needs of the supply chain. Two well-known production types are process organization and flow lines.

In process organization there are a great number of machines of similar functionality within a shop and there are usually many alternative routings for a given order. An end product usually requires many operations in a multi-stage production process. Demands for a specific operation occurring at different points in time may be combined to a lot size in order to reduce setup costs and setup times. Usually many lot sizes (orders) have to be processed within the planning interval.

In order to reduce the computational burden and to provide effective decision support the overall decision problem is divided into two (hierarchical) planning levels. The upper planning level is based on time buckets of days or weeks, while resources of similar functionality are grouped in resource groups. These big time buckets allow to avoid sequencing. Consequently, lot-sizing decisions and capacity loading will be much easier. Given the structure of the solution provided by the upper planning level, the lower planning level will perform the assignment of orders to individual resources (e.g. machines) belonging to a resource group as well as the sequencing. The separation of the planning task into two planning levels requires some slack capacity or flexibility with respect to the routing of orders.

For (automated) flow lines with sequence dependent setup times a separation into two planning levels is inadequate. On the one hand a planning level utilizing big time buckets is not suited to model sequence dependent setup costs and times. On the other hand sequencing and lot-sizing decisions cannot be separated here, because the utilization of flow lines usually is very high and different products (lot sizes) have to compete for the scarce resource. Luckily, there are usually only one to three production stages and only a few dozen products (or product families) to consider, so Production Planning and Scheduling can be executed in a single planning level.

In the following some definitions and examples illustrating the pros and cons of the two approaches will be provided.

A time bucket is called big, if an operation started within a time bucket has to be finished by the end of the time bucket. The corresponding model is named a big bucket model. Hence, the planning logic assumes that the setup state of a resource is not preserved from one period to the next. Usually, more than one setup will take place within a big time bucket of a resource (see Fig. 10.7).

Fig. 10.7

A big bucket model

In a model with small time buckets the setup state of a resource can be preserved. Hence, the solution of a model with small time buckets may incur less setup times and costs than the solution of a model with big time buckets (see operation B in Fig. 10.8). Usually, the length of a time bucket is defined in such a way that at most one setup can take place (or end) in a small time bucket on a resource (a further example is given by Haase 1994, p. 20).

Fig. 10.8

Gantt-chart: a small bucket model (time buckets of one time unit and two resources M1 and M2)

An aggregation of resources to resource groups automatically leads to a big bucket model, because the setup state of an individual resource as well as the assignment of operations to individual resources is no longer known.

Note that although a feasible big bucket oriented production plan exists, there may be no feasible disaggregation into a production schedule on respective resources. This can occur in cases such as

• Sequence dependent setup times

• Loading of resource groups, or

• A lead-time offset of zero time units between two successive operations.

Sequence dependent setup times cannot be represented properly within a big bucket model, since the loading of a time bucket is done without sequencing. Usually a certain portion of the available capacity is reserved for setup times. However, the portion may either be too large or too small. The former leads to unnecessarily large planned throughput times of orders while the latter may result in an infeasible schedule. Whether the portion of setup times has been chosen correctly is not known before the disaggregation into a schedule has been performed.

Another situation where a feasible disaggregation may not exist is related to resource groups. As an example (see Fig. 10.9), assume that two resources have been aggregated to a resource group, the time bucket size is three time units, thus the capacity of the resource group is six time units. Each operation requires a setup of one time unit and a processing time of one time unit. Then the loading of all three operations within one big time bucket is possible. However, no feasible disaggregation exists, because a split of one operation such that it is performed on both machines requires an additional setup of one time unit exceeding the period’s capacity of one machine. To overcome this dilemma one could reduce the capacity of the resource group to five time units (resulting in a slack of one time unit for the lower planning level). Then only two out of the three operations can be loaded within one time bucket. However, one should bear in mind that this usually will lengthen the planned throughput time of an order.

Fig. 10.9

An example of no feasible schedule when resource groups are loaded

For a multi-stage production system with several potential bottlenecks on different production stages, a feasible schedule might not exist if an order requiring two successive operations is loaded in the same big time bucket. As an example (see Fig. 10.10) depicting a two-stage production system with operation B being the successor of operation A each with a processing time of 9 h. A production stage is equipped with one machine (M1 and M2 respectively). A time bucket size of 16 h (one working day) has been introduced. Although the capacity of one time bucket is sufficient for each operation individually, no feasible schedule exists that allows both operations to be performed in the same time bucket (assuming that overlapping operations are prohibited).

Fig. 10.10

An example of no feasible schedule in multi-stage production with lead-time offset zero

A feasible disaggregation can be secured if a fixed lead-time offset corresponding to the length of one big time bucket is modeled. Again this may incur larger planned throughput times than necessary (32 h instead of 18 h in our example).

Consequently, it has to be considered carefully which of the above aggregations makes sense in a given situation. Usually, the answer will depend on the production type. Surely, an intermediate bucket oriented planning level can reduce the amount of detail and data to be handled simultaneously, but may also require some planned slack to work properly leading to larger planned throughput times than necessary.

In order to combine the advantages of both the big and the small bucket model a third approach—a big time bucket with linked lot sizes—has been proposed in Sürie and Stadtler (2003). Here, several lots may be processed within a time bucket without considering its sequence (hence a big bucket model). However, a “last” lot within a time bucket is chosen which can be linked with a “first” lot in the next time bucket. If these two lots concern the same product a setup will be saved. While this effect may only seem to be marginally at first sight, it also allows to model the production of a lot size extending over two or more time buckets with only one initial setup—like in a small bucket model.

Last but not least a fourth approach has to be mentioned which does not use time buckets at all, instead a continuous time axis is considered (Maravelias and Grossmann 2003). Although this is the most exact model possible it usually will result in the greatest computational effort. For a comparison with small bucket models see Sürie (2005).

5.2 Limitations Due to Computational Efforts

For finding the best production schedule one has to bear in mind that there are usually many alternatives for sequencing orders on a resource (of which only a subset may be feasible). Theoretically, one has to evaluate n! different sequences for n orders to be processed on one resource. While this can be accomplished for five orders quickly by complete enumeration (5! = 120), it takes some time for ten orders (10! > 3. 6 ⋅ 10⁶) and cannot be executed within reasonable time limits for 20 orders (20! > 2. 4 ⋅ 10¹⁸). Furthermore, if one has the additional choice among parallel resources, the number of possible sequences again rises sharply. Although powerful solution algorithms have been developed that reduce the number of solutions to be evaluated for finding good solutions (see Chap. 31), computational efforts still increase sharply with the number of orders in the schedule.

Fortunately, there is usually no need to generate a production schedule from scratch, because a portion of the previous schedule may have been fixed (e.g. orders falling in the frozen horizon) . Similarly, decomposing Production Planning and Scheduling into two planning levels reduces the number of feasible sequences to be generated at the lower planning level, due to the assignment of orders to big time buckets at the upper level.

Also, incremental planning or a reoptimization of partial sequences specified by the decision-maker will restrict computational efforts.

Further details regarding the use of Production Planning and Scheduling are presented in Kolisch et al. (2000), Pinedo (2009, p. 195), and Chap. 22.