SAP Scheduling

Scheduling calculates when each operation and the overall order should start and finish, based on the routing (operation times), work-center data, and the required date. It can schedule forwards (from a start date), backwards (from a due date), or use other strategies, producing a time-phased plan for production.

• Forward vs backward scheduling.
• Lead-time scheduling using routing times.
• Reduction strategies to meet dates.
• Basic vs detailed scheduling.

Worth separating two things that are both called scheduling. Lead time scheduling uses the routing and produces operation dates, which is what this page covers. Basic date scheduling uses only the material's in-house production time and produces order start and finish dates without touching operations. MRP does the second when creating planned orders, and the first happens when the order is created, which is why dates sometimes shift at conversion.

Scheduling runs in one of two directions and understanding when each is used explains most of the dates you will see.

Backward scheduling is the default. Start from the required date and work back through the operations using their durations, to arrive at a start date. It is what you want, because it says the latest you can start and still be on time.

Forward scheduling starts from today and works forward. The system falls back to it automatically when backward scheduling produces a start date in the past, because a plan that begins yesterday is not executable.

That fallback is the thing to recognise. An order whose finish date has moved out beyond what was requested has usually been forward scheduled, and the message telling you so is easy to miss. It is not a fault; it is the system saying this cannot be done in the time available.

The duration of each operation comes from the routing's standard values run through the work centre's formulas, plus float before and after production, which is deliberate slack, and move time between operations.

The float is worth knowing about because it is where planners hide uncertainty. Generous float produces plans that are always achievable and always start earlier than necessary, which ties up capacity.

Half an hour, and it demonstrates the levers in order.

1. Create a production order with a finish date two weeks out and read the operation dates. They were scheduled backwards from your date.
2. Change the finish date to tomorrow and reschedule. The start date is now in the past, so the system forward schedules and the finish moves out.
3. Increase a standard value on the routing and reschedule again. Every date shifts, because duration comes from the routing.
4. Change the float before production and observe the start date move without any operation changing.
5. Look at the capacity requirements the order generated. They sit on the days the operations were scheduled, which is what capacity evaluation reads.

Step two is the one people meet in production without recognising it, and knowing the fallback exists turns a confusing date into an obvious message.

Scheduling turns "make 100 units" into "start operation 10 at this time on this work center, finish by this date", enabling shop-floor execution and coordination with material availability and capacity. Accurate routing times and work-center data are prerequisites; without them, schedules are unrealistic and dates are missed.

It matters commercially as well as operationally, because these dates reach the customer. A sales order for a made-to-order product takes its availability date from what production scheduling says, so optimistic routings and generous floats both end up as promises somebody has to keep.

• Finite or infinite. Infinite scheduling ignores whether capacity exists and produces dates that look fine. Finite respects capacity and produces dates the plant can meet, at the cost of more configuration and better master data.
• How much float. Slack absorbs variability and hides it. Too little and every disruption is a late order; too much and capacity is reserved for work that has not started.
• Scheduling type on the order type. Backwards, forwards, or current date, set as the default per order type rather than chosen each time.
• Whether reduction is allowed. The system can compress float and overlap operations to meet a date, in defined strategies, and whether that is permitted is a decision.

When backward scheduling produces a start date in the past, the system can compress rather than simply falling forward, and the strategies are worth knowing because they are how a plant meets a date it should not.

Reducing float is the first lever. The slack before and after production is deliberate padding, and removing it buys days without changing any operation.

Overlapping operations lets the next operation start before the previous one finishes, which is realistic where a batch moves in parts rather than as a whole.

Splitting an operation runs it on several capacities at once, halving elapsed time if two machines are free.

Reducing move times removes the transfer allowance between operations.

These are configured as reduction levels, applied in order until the dates fit, and each level is a promise about how the plant will actually behave. That is the part to be careful about: a schedule that achieves a date by assuming three machines run in parallel is only real if three machines are free.

The honest use is as a planning aid that shows what would have to be true, rather than as a way to make an impossible date look possible.

Every date scheduling produces comes from master data, and knowing which field feeds which is what makes a wrong date diagnosable.

Operation durations come from the routing's standard values through the work centre's formulas. Wrong standard values move every date on every order using that routing.

Interoperation times, the queue, wait and move times, come from the work centre or the routing, and they are frequently left at defaults that were never reviewed.

Float before and after production comes from the material's scheduling margin key, which is a small field with a large effect: it is deliberate slack applied to every order.

The factory calendar on the plant and the work centre decides which days count at all, and a calendar that has not been maintained for the current year schedules work on holidays.

In-house production time on the material master is a simpler, order-independent lead time used by MRP for planning before an order exists, and it should be consistent with what detailed scheduling produces. When planning and execution disagree about how long something takes, these two disagreeing is usually why.

• Inaccurate times/work-center data, unrealistic dates.
• Wrong scheduling direction for the scenario.
• Ignoring capacity, schedules that cannot be met.

• Missing the forward scheduling message. The dates are then read as a plan rather than as a warning that the request was impossible.
• Work centre calendars left at defaults. A plant scheduled as working seven days produces dates nobody will staff.
• Blaming scheduling for a routing problem. See capacity planning, PP configuration and MRP for the surrounding pieces.

• Scheduling margin keys left unassigned. The float is then zero and every order is scheduled to start at the last possible moment, with no allowance for anything going wrong.

Reading dates is straightforward, and configuring scheduling so the plan is one the plant can execute is the part you do in the course.

The habit worth building is reading the scheduling messages on an order rather than only the dates. The message that says the order was forward scheduled is telling you the request was impossible, and the dates alone do not.