🔄 Change process for the transformation of the technical implementation process

From the rigid system to the integrated, agile production environment

Successful digitization and automation in manufacturing require not only new technologies but also a structured approach to changing existing mindsets and ways of working. This change process offers a practical roadmap for transforming technical implementation processes – with a focus on integration, efficiency and future viability.

---

1. 🧩 Starting point: Analysis of the current situation

1.1 Challenges in the classical environment

• Fragmented systems Mechanics, electrical, IT and OT work in isolation. This leads to coordination issues, friction losses and a lack of transparency.

• Inflexible processes Existing workflows respond too slowly to market changes or new product requirements.

• High coordination costs Coordination across departmental boundaries is time-consuming, error-prone and expensive.

• Data is not used Sensor and process data remain unused instead of being applied for optimization or predictive maintenance.

1.2 Assessment of the current situation

Criterion	Status
Efficiency	Low, due to media disruptions and manual handovers
Costs	High, e.g. due to failures and rework
Time	Long project durations and commissioning times
Risks	High process uncertainty due to missing linkage of data, processes and functions

---

2. 🎯 Target image: The desired situation

2.1 Vision of a modern implementation

• Fully integrated systems IT, OT, mechanics and electronics work together based on models. This reduces interfaces and misunderstandings.

• Flexible, modular architecture Platform engineering, digital twins and clearly defined state models enable quick changes and extensions.

• Data-driven decisions Real-time data flows into control, maintenance and optimization – consistently from sensor to HMI.

• Automation from the model Processes are not programmed but modeled – deterministic, documented, testable.

2.2 Benefits and potentials

Criterion	Improvement
Efficiency	Higher through automation and process clarity
Costs	Lower through more precise planning and shorter iterations
Time	Significantly reduced through reusability and model-based implementation
Risks	Lower thanks to transparency, standardization and digital verification

---

3. 🔧 Change management process

How the change succeeds

3.1 Preparation

• Identify stakeholders Who is affected? Who decides? Who implements?

• Communicate the vision The Why and What for clearly explain: What does the change bring – individually and organizationally?

---

3.2 Planning

• Develop a transformation plan With concrete milestones, responsibilities and resource requirements.

• Technological and personnel alignment Where is training needed? Which systems must be replaced, extended or integrated?

---

3.3 Implementation

• Conduct pilot projects Prototypes or pilot lines validate the new methodology and ensure experience is gained.

• Training and enablement Users and developers must understand, apply and help shape the new approach.

• Incorporate feedback loops Learn early from the system – iterative, not top-down.

---

3.4 Monitoring and control

• Define metrics (KPIs) Progress, quality and acceptance must be measurable.

• Allow adjustments The plan is not a dogma – but an orientation. Learning is part of the process.

---

3.5 Anchoring

• Establish a culture of learning and modeling Move away from the “quick programmer” toward the structured process designer.

• Make successes visible Communicate good practice, acknowledge contributions, strengthen motivation.

---

🧠 Conclusion: Technical implementation needs transformation

The change of technical implementation processes is more than a software change – it is a cultural, methodological and organizational step toward:

• integrated thinking (process + function + responsibility)

• model-based working (instead of just code)

• formalized procedures (traceable, verifiable, legally secure)

👉 Selmo provides the methodological backbone for this change: With formal state models, clear bit-control assignments, fully documented processes – and code that emerges from the process.

---

🔁 See also:

• What is the Selmo-PTF model?

• How does Selmo support formal verification and legal certainty?

• Why “model instead of code” is the future of automation