Operational teams need to continuously improve shop floor processes, while IT is responsible for security and integration. A clear division of responsibilities between IT governance and operational process design can resolve this apparent tension.
Shopfloor Meetings as a starting point for continuous improvement
In many manufacturing companies, two legitimate needs must be reconciled: operational teams need to adapt processes quickly and drive continuous improvement. At the same time, central IT is responsible for information security, system integration and a consistent IT architecture.
Resource constraints often add to the challenge. ERP migrations, IT security, infrastructure, system integration and other strategic initiatives absorb substantial IT resources. Requests from production, lean management and continuous improvement teams compete for the same resources and often end up at the bottom of long priority lists.
The underlying issue is usually not a lack of willingness to collaborate, but differences in responsibilities, priorities and the pace of change.
Resource constraints often add to the challenge. ERP migrations, IT security, infrastructure, system integration and other strategic initiatives absorb substantial IT resources. Requests from production, lean management and continuous improvement teams compete for the same resources and often end up at the bottom of long priority lists.
The underlying issue is usually not a lack of willingness to collaborate, but differences in responsibilities, priorities and the pace of change.
When continuous improvement meets IT priorities
Shop floor processes are constantly evolving. New performance indicators are added, meeting structures are adjusted, escalation paths are refined and new continuous improvement workflows are introduced. These changes are fundamental to continuous improvement.
However, when such adjustments become formal IT requests, a structural bottleneck can emerge. Changes need to be specified, prioritized and implemented technically. For operational teams, this means waiting. For IT, it creates additional work through a steady stream of small operational requests.
In practice, operational teams therefore often turn to pragmatic alternatives. Excel spreadsheets, locally maintained lists and other digital tools enable quick action in the short term, but create new problems over time: information becomes scattered across different tools, information flows are disrupted and similar processes are implemented differently across departments. This makes central coordination and standardization increasingly difficult.
The underlying problem therefore lies less in the differing requirements than in the existing division of responsibilities: as long as even minor process adjustments depend on IT resources, the digital development of operational processes is held back by IT capacity and priorities.
However, when such adjustments become formal IT requests, a structural bottleneck can emerge. Changes need to be specified, prioritized and implemented technically. For operational teams, this means waiting. For IT, it creates additional work through a steady stream of small operational requests.
In practice, operational teams therefore often turn to pragmatic alternatives. Excel spreadsheets, locally maintained lists and other digital tools enable quick action in the short term, but create new problems over time: information becomes scattered across different tools, information flows are disrupted and similar processes are implemented differently across departments. This makes central coordination and standardization increasingly difficult.
The underlying problem therefore lies less in the differing requirements than in the existing division of responsibilities: as long as even minor process adjustments depend on IT resources, the digital development of operational processes is held back by IT capacity and priorities.
Combining IT governance with operational flexibility
One possible approach is to separate responsibility for technical integration from responsibility for operational process design.
IT remains responsible for the technical foundation. This includes system integration, data access, permissions, information security and overarching architectural standards.
Within this defined framework, designated experts from operational teams can further develop their operational applications independently. No-code technologies allow them to adapt shop floor boards, KPI visualizations, workflows, shop floor meetings and continuous improvement processes without initiating a new software project for every change.
The key principle is that no-code does not mean bypassing IT. It enables operational teams to make changes within clearly defined technical and organizational guardrails. This allows IT governance and operational flexibility to work together.
IT remains responsible for the technical foundation. This includes system integration, data access, permissions, information security and overarching architectural standards.
Within this defined framework, designated experts from operational teams can further develop their operational applications independently. No-code technologies allow them to adapt shop floor boards, KPI visualizations, workflows, shop floor meetings and continuous improvement processes without initiating a new software project for every change.
The key principle is that no-code does not mean bypassing IT. It enables operational teams to make changes within clearly defined technical and organizational guardrails. This allows IT governance and operational flexibility to work together.
Less dependence on IT, more room for continuous improvement
This division of responsibilities reduces the effort required for coordination and implementation on both sides.
Rather than repeatedly coordinating individual change requests between operational teams, IT and, where necessary, external service providers, key users can make many process-related changes independently.
IT can then focus more of its resources on architecture, integration, security and strategic priorities. Operational teams, in turn, can respond to new requirements without having to wait for available development capacity for every minor process change.
This adaptability is particularly valuable for continuous improvement, where processes rarely follow a fixed, predefined design. Instead, they are tested, evaluated and refined step by step. The software in use needs to support this evolution without turning every adjustment into a separate IT project.
Rather than repeatedly coordinating individual change requests between operational teams, IT and, where necessary, external service providers, key users can make many process-related changes independently.
IT can then focus more of its resources on architecture, integration, security and strategic priorities. Operational teams, in turn, can respond to new requirements without having to wait for available development capacity for every minor process change.
This adaptability is particularly valuable for continuous improvement, where processes rarely follow a fixed, predefined design. Instead, they are tested, evaluated and refined step by step. The software in use needs to support this evolution without turning every adjustment into a separate IT project.
How Visual Shop Floor supports this approach
Visual Shop Floor follows this principle. The software platform combines data and information from different systems with a flexibly configurable workspace for operational processes.
Designated key users can adapt shop floor boards, KPI visualizations, workflows, shop floor meetings and continuous improvement processes to their organization’s requirements. At the same time, existing systems and data sources can be integrated to provide a shared foundation of operational information.
Visual Shop Floor thus supports a clear division of responsibilities: IT defines and maintains the technical and security framework, while operational teams can independently develop and refine their processes within it.
