Shift rosters that check rest periods upfront

The best known reference value is the rest period. The German Working Hours Act requires an uninterrupted rest period of at least eleven hours after the end of the daily working time. For a planning system this is a very convenient rule, because it follows entirely from two timestamps: the end of the previous shift and the start of the next one. Which is exactly why it is so frustrating that it is still breached in day-to-day operations. The late shift ends at 22:00, the early shift starts at 06:00, and eight hours lie in between. Nobody plans that deliberately; it happens because a swap only looks at staffing levels and not at the previous day.

The second reference value is duration. Daily working time must not exceed eight hours and may only be extended to up to ten hours if an average of eight hours per working day is maintained over six calendar months or 24 weeks. The same framework applies to night work, but with a much tighter reference period of one calendar month or four weeks. A plan that does not keep those two windows apart calculates too generously for night workers and reports the excess only once compensation no longer fits into the period. Anyone currently keeping such calculations in a spreadsheet will recognise the typical consequences in replacing spreadsheet workarounds.

A table like this is not a program, it is an agreement. It records which rule applies with which parameter, when the check runs and what the check triggers. Only after that does the technical question arise of where the rule is calculated - in an existing planning module, in a small service beside it, or in the system that already holds the recorded times. We usually build this check as an automation attached to the existing landscape, described under process automation. What matters is not the tool but the fact that the parameters live in one place rather than in three people's heads.

A checked plan is a good start, but it remains an intention. The work happens differently: a shift starts later, a handover drags on, a fault extends an assignment, somebody steps in. Those deviations are normal and no sign of poor planning. It only becomes a problem when they do not come together anywhere. Then two truths exist side by side: the plan that dispatch worked from, and the recording that payroll settles against. Bringing them together produces a single figure that can actually be managed - the variance per shift, per workstation and per week.

The feedback loop matters just as much as the planning itself. If a shift regularly runs three quarters of an hour longer than planned, the issue is not the workforce but the stored target value. Feedback of that kind is already arriving whenever order and machine data are captured; how that works without paper is described in shop floor feedback without paper. The plan does not become more rigid as a result, it becomes more honest: it describes what is actually needed rather than what was once set as a guideline.

Three figures are enough for reporting at the start: the share of shifts with a variance above a defined threshold, the number of rule alerts per week before publication, and the number of deliberate deviations with a justification. The first figure shows whether the plan is realistic, the second whether it is produced cleanly, the third where a rule does not fit the operation. Which key figures carry beyond that, and how they can be produced without additional effort, is described under metrics and reporting.

Shift planning rarely stands alone. It supplies target times to time recording, premium types to payroll, availability to order or tour dispatch and hours to post-calculation. In return it needs absences from personnel administration, orders from the ERP system and downtime from maintenance. Each of these connections can be built as a file, as an interface or as a scheduled reconciliation. The expensive mistake is not the technology but duplicate maintenance: as soon as an absence has to be entered in two places, the only open question is which of the two lists goes stale first.

The connection points differ markedly by sector. In manufacturing the plan hangs off orders, setup times and machine availability, described under processes in production. In logistics it hangs off tours, time windows and loading appointments, plus driving and rest times that bring their own rules for drivers - more on that under processes in logistics. For service providers it is appointment scheduling at the customer site. The core stays the same: planning needs demand, rules and availability in one view, otherwise it is produced from experience rather than from data.

One item belongs on the agenda early rather than at the end: a system that plans working time and logs deviations is as a rule subject to co-determination. Inviting the works council only for the final acceptance costs weeks and sometimes the entire project. How such involvement works in practice, which documents are useful and which evaluations are better excluded from the outset is described in involving the works council in IT projects. Experience shows that the question of monitoring conduct and performance is settled faster when the reporting scope is limited in writing.

The route from the board to a checked plan can be taken in stages, and the first stage is small. To begin with only checks are run, nothing is blocked: the plan is produced as before, an overnight run reports conflicts, and after two weeks there is a list that provides figures instead of assumptions. That list makes it obvious which rule should be enforced first. In most companies it is the rest period, because it produces the most hits and can be resolved with a single swap.

To put the effort in context: a process analysis starts at 1,900 EUR net, delivery per automation or interface at 4,900 EUR net, ongoing support at 190 EUR net per month. Prices as of September 2026. The ongoing services can be cancelled monthly; there is no minimum term. The overview is available under pricing, and a first conversation can be arranged via contact. Related reading: packaging reporting driven by the item master for reporting duties built on master data, and interim payments and variations on building sites for an orderly cash flow on long-running jobs.