Stefan Gregorzik

Digital Operational Excellence in Practice

Operational Excellence is the ability of a company to continuously improve its value chain in terms of efficiency and effectiveness. It is the ultimate discipline in the manufacturing industry. Companies face constant pressure to optimize their manufacturing processes and increase productivity. However, there are several hurdles to overcome, such as lack of coordination, paper-based processes, and a multitude of labor-intensive manual activities.

For sustainable production optimization, digitalization through Manufacturing Operations Management (MOM) systems is a fundamental cornerstone. It’s crucial that IT activities go hand in hand with the design of processes and methods, and their integration into the shop floor organization, which often faces challenges such as limited resources, skill gaps, and restricted operational capacity.

Based on our project experiences, we have summarized the following typical steps for you to achieve increased OEE (Overall Equipment Effectiveness) and EBIT:

Qualification and involvement

Early involvement of employees as ambassadors significantly contributes to the success of the project. Therefore, the project team and leadership are trained at the project’s outset. This fosters a shared understanding and ensures sustainable integration of activities. Additionally, to assess the coverage of process threads with the standard software and to create mock-ups for the target system as needed, key users must be involved early on.

Equipment and Asset Management

A simple system solution without smart machine integration often generates significant benefits in the initial phase of the project. This is particularly true for maintenance. Asset management documents the condition of the equipment ‘as maintained.’ This allows similar groups of systems to be managed in a standardized manner and to identify deviations (benchmarking). Further potential lies in the standardized spare parts management.

Cross-System Data Logistics

The next step typically involves the integration into company-wide data logistics. To achieve this, leading systems and consumers are identified and matching is designed at their interfaces. Companies should not underestimate this design phase, which is often the most challenging part of establishing a stable data logistics. In terms of technical implementation, certified interfaces for standard systems like SAP are preferable, as individual approaches are often maintenance-intensive and not future-proof.

Optimization of Shop Floor Control

Once order data (from upstream systems) and equipment are available in the MOM system, the optimization of processes surrounding production and shop floor control continues: Error-prone Excel tools are replaced, planning consistency is enhanced, and manual efforts are reduced.

For instance, through effective shop floor data collection (SFDC), operators can report causes and quantities of defects, improving the information basis for control. By digitally providing manufacturing documents, manual efforts and sources of errors can be reduced. All of these measures significantly increase the acceptance of digitally available information among operators.

Machine Integration and Data Preparation

The integration of machines and equipment into the MOM system (Machine Data Acquisition) creates a comprehensive picture of the current manufacturing situation. This enables companies to implement condition-based and predictive maintenance measures. Another particularly important aspect is the implementation of a cross-functional energy management on this basis, as the system provides data for calculating the CO2 footprint throughout the entire production chain.

Digital Shop Floor Management

Digital Shop Floor Management (SFM) serves as a central interface between IT and process optimization. SFM is the key lever for continuous improvement in production and is methodically supported by cascading rule meetings. This allows insights and issues to be visualized and addressed from the workshop floor to the site level, from OEEs and loss reasons at a single facility in one shift to the impact on operational performance and site EBIT.

Stabilizing and Improving OEE

The focus on improving OEE often revolves around reducing downtime and reasons for disruptions. This is based on the consolidated overview from Machine Data Acquisition (MDE) and Shop Floor Data Collection (BDE), identifying measurable causes of losses for each machine. A typical insight, applicable to many companies, is that OEE losses are not solely due to equipment failures but often stem from organizational issues. Therefore, alongside initiatives such as setup workshops, machine cleaning measures, and employee training, projects in office areas are also of significant importance (e.g., order processing, planning/scheduling, and product development/master data).

Enterprise-wide Benefits

Digitization through MOM software establishes a foundation for companies to optimize their production sustainably. In typical cases such as in medium-sized mechanical engineering, improvements of the average OEE across all machines by more than 10 percentage points and an increase in site EBIT by more than 2 percentage points are quite realistic. As long as there are sufficient orders, increased productivity is immediately reflected in higher EBIT. At the same time, improved process quality and responsiveness have a positive impact on customer relationships.

You have the opportunity to discuss more about this topic live with our subject matter experts at the Hannover Messe from April 22nd to 26th, 2024.

Black Box IoT?

Who wants to buy a pig in a poke? Especially when you are entering completely new territory with it… The first stroller, for example: you are already aware that you need it, but the decision between a small pack format or the bicycle trailer combination is more difficult.

The last time I bought a baby carriage was some time ago (now I am an expert in buying skateboards). But if you’re just about to make a choice, I recommend a dark model, because you can’t see the dirt so clearly.

An IoT system is usually not as sensitive to dirt, but its selection is all the more complex. Especially since many companies are breaking new ground with it and can already despair of the selection of the right criteria.

Here I have two good news for you. First: Which IoT solution fits is easy to try out. A Proof of Concept is a very good way to test a solution without major risks before you decide on a system. And secondly, as much as IoT offers new opportunities, smart business processes are based on good old business virtues:

Are you sure what your IoT business will look like and that it will stay that way for a long time? Probably not. IoT is a very volatile market where a lot is happening right now. So your IoT system needs to be responsive and best adaptable by the business department itself. The keyword behind this is “low code”, which means no time-consuming programming to map your processes. And if that’s not enough, the system should be so modular that you can simply “reload” additional components.
Does your IoT business emerge on the greenfield or does it expand your existing business? If the second is the case, then your IoT system should be able to talk to the rest of the IT world in your company: Spare parts orders, for example, should generally have passed through financial accounting once. Open or even certified interfaces are the most important thing here as well.
Do you manufacture industrial goods? Do you also have to do with spare parts and maintenance? Then your new best friend in IoT new territory becomes the “Digital Twin”. But only if it’ s also suitable for industrial use: it must be able to map the components of your system in detail (preferably with the corresponding 3D model), know the current parameters such as software statuses and, in particular, be able to document changes after maintenance or conversion.

To be honest, the connection of devices is usually only a question of fiddling, but usually not a fundamental problem. Step by step, standard protocols for machine-to-machine (M2M) communication such as MQTT (Message Queuing Telemetry Transport) or OPC/UA (Unified Architecture) are gaining acceptance and making life easier for everyone involved.

So: Just try it out with a Proof of Concept! If you also pay attention to the three touchstones, you’re in the running. Then the possibilities of “Analytics”, “Big Data”, “Data Driven Processes” or “Predictive Maintenance” are open to you.

Dieses „M“, das doch eigentlich viel sein sollte, als heiße Luft…

Der Begriff [‘mänätschmänt] blickt auf eine langjährige Karriere als inhaltsleere Füllwortmasse in allen Bereichen des Lebens zurück. Im Wesentlichen ist sie dazu da, das Ausatmen bei der Vertonung komplexer Wortgebilde zu erleichtern. Und auch unser aller Lieblingsabkürzung wurde leider nicht davon verschont – wo sie doch mit „P“ und „L“ so einen schmissigen Anfang genommen hat.

Machen wir das Beste draus, wagen wir das Experiment, das „M“ einmal ernst zu nehmen. Was wäre denn die Quintessenz vom „managen“ beim „productlifecyclen“? Kosten im Griff behalten – ja klar, zentral wichtig, aber im Kern die Ägide des Controllings. Termine? Macht das Projektmanagement (hoffentlich). Last but not least: Der Kern des „PL-“ Managements liegt für mich darin, den Reifegrad des Produktes unter Kontrolle zu haben.

Reifegrad hat dabei zwei Perspektiven:

1. Der Grad, in dem ein Produkt das macht, was es soll.

2. Der Grad, in dem das Produkt so hergestellt werden kann, wie man es haben will.

Diese beiden Sichtweisen werden gerne als Produkt- und Prozessreifegrad bezeichnet

Um so einen Reifegrad zu bestimmen oder gar zu steuern, ist es von Vorteil, erst einmal zu beschreiben, wogegen man messen will. Ich hätte dazu noch einen Begriff mit Füllwortende im Angebot: Anforderungsmanagement. Mit dem Vehikel „Anforderung“ beschreibe ich klassisch, was ein Produkt machen soll. Reicht aber nicht! Ich muß auch beschreiben, wie ich ein Produkt herstellen will! Das nennt sich dann „Front-Loading“ und hilft ganz gewaltig, den Zielraum für eine Produktentwicklung zu konkretisieren.

Wie aber das Wort „Entwicklung“ schon sagt, steuere ich hier gegen ein bewegliches Ziel, Produkt und Prozess wachsen weiter, machen manchmal auch einen Schritt rückwärts. Der Reifegrad muß also auch ein Ausdruck dafür sein, wie erfolgreich meine verschiedenen Konzeptalternativen sind bzw. wie weit ich den Trichter möglicher Optionen schon eingeengt habe (letztes Buzzword für heute: Set-Based Engineering).

So ergibt sich ein Korridor von Fakten, gegen den die Produktentwicklung reflektiert werden kann: Hat meine Entwicklung alle Anforderungen im Blick (Abdeckungsgrad)? Kann ich die Anforderungen auch bedienen (Erfüllungsgrad)?

Zum Thema „Abdeckungsgrad“ empfehle ich den Blog-Beitrag von Michael Wendenburg zum Systems Engineering, das ist eine Frage der intelligenten Verdrahtung von Informationen untereinander. Der Erfüllungsgrad wiederum ist eine Frage der Absicherung – und hier wird’s jetzt ein bißchen heterogen…

Absicherung stand lange Zeit synonym für den guten alten Versuch: Hält es noch, wenn man dran rüttelt? Läuft irgendwo Öl ‘raus? Entschuldigung an alle Kollegen aus dem Versuch für die saloppe Formulierung. Was ich damit verdeutlichen will, ist die Krux, daß der Versuchsplan sich in Ermangelung an klar formulierten Anforderungen auch nicht an solchen orientieren kann. Was man im Versuch herausfindet, wird klassischerweise so gut wie möglich gegen einzelne Teile oder Baugruppen dokumentiert und daraus ein (Produkt-) Reifegrad interpretiert.

Das Gleiche gilt grundsätzlich auch für die Absicherung der anderen Reifegrad-Perspektive. Aber Herstellbarkeitsprüfungen, Verbauuntersuchungen, Try-Outs zur Prozess-Stabilität… müssen eher noch ein härteres Schicksal tragen: Ergebnisse wie „läßt sich nicht mit dem Schrauber erreichen“ können wenigstens noch auf einen Bauraum bezogen werden, aber „zu breit für die Lackierkabine“ ist schon deutlich schlechter aufzulösen. Und es geht ja auch noch weiter: Sind die Logistik-Prozesse reif, klappt die IT-Versorgung für die Produktion und und und …

Nun existiert dazu auch noch eine veritable Parallelwelt: Simulation hat Ihren Platz in den Entwicklungsorganisationen gefunden, sowohl für Produkt-, als auch Prozessthemen. Allerdings ringen viele Beteiligte noch mit der Verdrahtung doch unterschiedlicher Prozesswelten. Typische Rückmeldungen aus der Simulation lauten in etwa „würde halten, wenn Du den Radius etwas kleiner machst“ – und das womöglich in sehr frühen Konzeptphasen, wo es kaum eine ausgegorene Produktstruktur als Referenz gibt.

Spätestens hier wird also der Zusammenhang zwischen Reifegrad und Alternativen besonders deutlich: Messe ich das eine, bewerte ich das andere.

Um managen zu können, brauchen ich ein gemeinsames Raster für Entwicklung und Absicherung, an dem Ergebnisse der sehr unterschiedlichen Aktivitäten gespiegelt werden. Egal ob Simulation oder physische Absicherung, frühe Konzepte oder B-Muster – ich benötige eine vereinheitlichte Aussage über den Reifegrad meiner Ergebnisse. Und nur auf der Ebene von Anforderungen habe ich ein hinreichend abstraktes Vehikel, um so ein Raster darzustellen und alle genannten Fraktionen abzuholen.

Wenn man „Management“ ernst nehmen will, dann sind wir hier – glaube ich – an einer guten Stelle dafür angelangt.