Self-organization on the shop floor: planning by skills

Teams on the shop floor can organize themselves with software if planning sets the framework and the team distributes the work within it. The software translates orders into qualification requirements, takes rules and capacities into account and shows which deployments are possible. The team decides who takes on which task. Deviations that the framework does not absorb are clarified by designated people responsible. Planning is not lost in the process. It shifts from assigning individual people to designing the framework.

What self-organization means in shift operations

In shift operations, self-organization means that a team makes some of the deployment decisions itself, such as who takes on which workstation or order and who swaps with whom. This works when three levels are clearly separated:

Level	Content	Who decides
Framework	Orders, qualification requirements, capacities and shift times	Planning and the people responsible
Rules	Requirements that every assignment must meet, for example necessary qualifications	Company
Room to decide	Distribution of tasks and workstations, swaps among team members	Team

The agileASSEMBLY research consortium focused on agile self-organization concepts enabled by digital assistance systems. According to the interim results in the project description, combining digital planning and communication solutions with agile ways of working can enable situational self-coordination of teams.

A use case report from the consortium describes how planning is preserved in this setting. The ERP system remains the binding basis, while assignment at the daily level passes to the employees in assembly. AI-supported optimization runs in the background, prescribes nothing and checks what is feasible. Employees receive a selection of feasible options, and the final choice of order remains their decision.

Which prerequisites are needed

For a team to decide for itself, it needs to see what is needed and what is permitted. This results in five prerequisites:

• Translating orders into qualification requirements: For assignment, what counts is which skills an order requires, not just the number of people. The basis for this is a well-maintained qualification matrix.
• Up-to-date data from existing systems: Orders, master data, absences and recorded times come from SAP or other ERP systems, HR software, MES and time tracking. Outdated data leads to decisions on the wrong basis.
• Cross-training: Room to decide only arises when several people can take on the same task. A paper from agileASSEMBLY calls cross-functional qualification of employees a critical factor for agile, self-organized production.
• A simple interface for the team: The team needs the current plan, open requirements and possible options at a glance. It does not need to see the calculations behind them.
• Clear responsibilities: For cases that the team cannot resolve itself, designated people are needed who decide and approve changes. The article on shift planning with AI shows how proposal and approval work together.

What Hawk IVO Plan takes on

Hawk IVO Plan is the functional core for planning logic, rules, optimization and plan versions. It plans your team according to qualifications and in step with your customer orders. It imports master data, orders and personnel movements from SAP and other ERP systems, and production data and recorded times flow in from MES and time tracking. The platform’s scope of services to date includes a qualification matrix with qualification-based matching, dynamic requirements when order volumes fluctuate, shift swaps and a mobile app in which employees see their shift schedule and submit absence requests.

The work interfaces of Hawk IVO Plan are the visual operating interface for planning, analysis and control scenarios. They present planning in a user-specific way. Planners and teams see the current state of the plan for their role, and short-notice changes and conflicts become visible. The people responsible choose an option and approve it, and approved changes flow back into planning.

In this way, Hawk IVO Plan provides the framework and rules and at the same time makes them visible to teams and the people responsible. The assignment of individual features to Hawk IVO Plan or a solution package is currently being confirmed. We will clarify the right scope for you in a conversation.

Practical example: IMS Gear in the agileASSEMBLY research consortium

IMS Gear, a manufacturer of gear and transmission technology, was an industrial partner in the BMBF research consortium agileASSEMBLY (opens in a new tab) from 2023 to 2026. The partners included Fraunhofer IAO, the IAT of the University of Stuttgart, the WZL of RWTH Aachen and Diehl Metering. Hawk contributed Hawk IVO Plan, then getaiPlan, as the software foundation.

The public video case study “AI Workforce Management: Wenn die Technik dem Menschen eine echte Hilfe ist” (in German) from January 20, 2026 was produced with IMS Gear. It describes a solution that does not prescribe, but enables employees on the shop floor to organize themselves. The planning software connected existing systems, with SAP, HR software and MES named in the video, and translated production orders into qualification requirements. A dedicated interface for the shop floor hid the complexity from the employees. The video cites self-organization within the team and planning based on skills instead of rigid patterns as results. Cedric Oette sums up the approach in the video in one sentence: “Es ist ein Miteinander.” (“It’s about working together.”)

The video still shows the former product names. The planning software and the shop floor interface are now both part of Hawk IVO Plan. You can find more details in the IMS Gear case study and in the news item on the video case study.

Limits and common objections

Self-organization changes who makes decisions in everyday work. This raises legitimate questions:

• “Then nobody plans anymore”: Planning remains and sets the framework. Rules and qualification requirements apply to every decision the team makes, and deviations go to the people responsible.
• “Responsibility becomes blurred”: This can be avoided if it is clear in advance which decisions the team makes and which require approval.
• “This is too complicated for employees”: This is where the interface matters. It should show what needs to be done and which options exist, and keep the planning calculations in the background.

There are also limits that no software can remove. Where only a few people are allowed to take on a task, the room to decide remains small until cross-training expands. If capacity is lacking, the team cannot create it through swaps, and demand planning remains the job of planning. The effect of self-organization depends on the area, the qualification structure and the order situation and can only be tested in your own operations.

How to get started

We recommend starting with a clearly defined area and testing the approach in a pilot with real users. This shows which decisions the team can take on and which data is still missing. If you have such an area in mind, we would be happy to discuss it with you via our contact page.