Dieser Artikel dient als Leitfaden, um die richtige technologische Basis f\u00fcr Ihre Fertigung zu finden. Wie \u00fcbersetzen wir Architekturideen in sinnvolle Entscheidungen auf Microsoft Azure, und zwar aus der Perspektive von OT-, IT- und Datenteams? Auf Azure f\u00fchren diese Fragen heute h\u00e4ufig zu zwei Grundrichtungen: entweder Platform as a Service (PaaS) mit einem aus Azure-Bausteinen zusammengesetzten Stack oder zu einer st\u00e4rker integrierten L\u00f6sung als Software as a Service (SaaS) mit Microsoft Fabric. Keine dieser Richtungen ist per se \u00fcberlegen; entscheidend sind Anwendungsfall, Betriebsmodell und vorhandene Kompetenzen. Als ZEISS Digital Innovation begleiten wir Fertigungsunternehmen genau bei dieser Transformation. Dieser Artikel ist bewusst kein Produktkatalog, sondern eine Entscheidungshilfe, die auf unseren Erfahrungen aus realen Projekten basiert. Wir starten vom konkreten Anwendungsfall, stellen die richtigen Fragen und zeigen, in welche Richtung die Antworten auf Azure f\u00fchren. Dabei wird eines klar werden: Verwaltete Dienste nehmen viel Infrastrukturarbeit ab, aber die fachliche Architektur und Governance bleiben projektspezifische Aufgaben.<\/p>\n\n\n\n
Ein wesentlicher Aspekt ist von Anfang an mitzudenken: die Kostenstruktur im t\u00e4glichen Betrieb. Falsche Architekturentscheidungen \u2013 etwa Streaming statt Batch, fehlende Storage-Lifecycle-Policies oder unn\u00f6tige Datenredundanz \u2013 f\u00fchren schnell zu unerwartet hohen Cloud-Kosten. Aus unserer Projekterfahrung wissen wir: Wirtschaftlich tragf\u00e4hige Architekturen entstehen, wenn Kosten von Beginn an mitgedacht und sorgf\u00e4ltig im Kontext des Betriebsmodell abgewogen werden.<\/p>\n\n\n\n
Kurzer R\u00fcckblick: Die Grundprinzipien<\/h2>\n\n\n\n
Moderne Fertigungsunternehmen k\u00e4mpfen mit Hunderten bis Tausenden Datenquellen in Silos. Eine industrielle Datenplattform schafft eine zentrale Infrastruktur, um diese Daten zu sammeln, zu verarbeiten und nutzbar zu machen. Dabei haben wir gelernt, dass nicht jeder Anwendungsfall Echtzeitdaten ben\u00f6tigt. Die Spanne reicht von Millisekunden f\u00fcr Prozesssteuerung bis zu Tagen f\u00fcr Management-Reports. Echte Regelkreise im Millisekundenbereich bleiben dabei in der Automatisierungsebene oder am Edge; die zentrale Datenplattform unterst\u00fctzt vor allem Monitoring, Analyse und Koordination. Die richtige Einordnung spart Kosten und Komplexit\u00e4t.<\/p>\n\n\n\n
Die Medaillon-Architektur strukturiert den Datenfluss: Bronze f\u00fcr Rohdaten, Silver f\u00fcr bereinigte Daten, Gold f\u00fcr aggregierte Business-Sichten. Und je nach Latenzanforderung und Netzwerkbedingungen entscheiden wir, ob Batch-Ingestion ausreicht oder Streaming n\u00f6tig ist, ob wir am Edge vorverarbeiten oder direkt in die Cloud gehen. Mit diesem Grundverst\u00e4ndnis k\u00f6nnen wir nun konkret werden: Wie \u00fcbersetzen sich diese Prinzipien in konkrete Technologie? F\u00fcr das Microsoft-\u00d6kosystem bedeutet dies eine gezielte Auswahl passender Dienste.<\/p>\n\n\n\n
Von Anwendungsf\u00e4llen zu Technologieentscheidungen<\/h2>\n\n\n\n
Starten wir aber nicht mit Technologie, sondern mit typischen Anwendungsf\u00e4llen aus der Fertigung. Die drei folgenden Szenarien sind als Ausbaustufen mit steigender Komplexit\u00e4t zu verstehen: von einfachem Reporting \u00fcber laufendes Monitoring bis zu maschinellem Lernen (ML). In der Praxis w\u00e4chst eine industrielle Datenplattform oft genau in dieser Reihenfolge. F\u00fcr jeden Fall skizzieren wir zun\u00e4chst den L\u00f6sungsansatz und leiten daraus sp\u00e4ter passende Technologiepfade ab.<\/p>\n\n\n\n Zun\u00e4chst betrachten wir den klassischen Fall: Mitarbeitende der Fertigung und F\u00fchrungskr\u00e4fte m\u00f6chten t\u00e4gliche oder w\u00f6chentliche Berichte \u00fcber Produktionszahlen, Ausschuss und Energieverbrauch sehen. Die Datenquellen sind \u00fcberschaubar, die Netzanbindung ist stabil, und eine Aktualisierung im Stunden- oder Tagesrhythmus reicht aus. Hier gen\u00fcgt ein klarer Batch-Ansatz: Daten werden per Batch-Ingestion \u00fcbernommen, in Bronze, Silver und Gold strukturiert und anschlie\u00dfend f\u00fcr Dashboards bereitgestellt. Der Hauptaufwand liegt weniger in der Technik als in Datenmodellierung, Definition der Key Performance Indicators (KPIs) und Governance.<\/p>\n\n\n\n Jetzt wird es anspruchsvoller: Der Mitarbeitende im Leitstand braucht sekunden- bis minutengenaue Anzeigen von Maschinenstatus und Gesamtanlageneffektivit\u00e4t (Overall Equipment Effectiveness, OEE) \u00fcber mehrere Produktionslinien hinweg. Hier wird Streaming relevant. Maschinendaten werden per Streaming-Ingestion aufgenommen, nahezu in Echtzeit verarbeitet und parallel f\u00fcr historische Analysen abgelegt. Bei instabilen Netzen oder harten OT-Sicherheitszonen empfiehlt sich zus\u00e4tzliche Edge-Verarbeitung am Shopfloor. Technisch ist das beherrschbar, organisatorisch aber nur erfolgreich, wenn OT, IT und Datenteam den Ende-zu-Ende-Pfad gemeinsam verantworten.<\/p>\n\n\n\n Predictive Maintenance vereint das Beste und Anspruchsvollste aus beiden Welten. Sie brauchen Jahre historischer Zeitreihendaten zum Modelltraining und gleichzeitig aktuelle Streams f\u00fcr Vorhersagen, die zur\u00fcck ins Tagesgesch\u00e4ft flie\u00dfen, etwa als Wartungsauftr\u00e4ge im Computerized Maintenance Management System (CMMS). Der passende Ansatz ist hybrid: Streaming-Ingestion f\u00fcr aktuelle Sensordaten, historisierte Zeitreihen im Lakehouse und eine Machine-Learning-Umgebung f\u00fcr Training und Inferenz. Gerade hier zeigt sich der Unterschied zwischen Plattform-Bausteinen und Projektarbeit besonders deutlich: Microsoft liefert Werkzeuge, aber Modellauswahl, Merkmalsbildung und Integration ins CMMS bleiben projektspezifisch. <\/p>\n\n\n\n Statt eine endlose Produktliste abzuspulen, schauen wir uns Azure-Dienste nach Aufgabenfeldern an. Das hilft, die richtige Technologie f\u00fcr die jeweilige Herausforderung zu finden.<\/p>\n\n\n\n Grunds\u00e4tzlich ergeben sich dabei zwei gut begr\u00fcndbare Wege: ein PaaS-Ansatz, bei dem Sie einzelne Dienste je Aufgabenfeld kombinieren, oder ein st\u00e4rker integrierter Ansatz mit Microsoft Fabric, bei dem einzelne Funktionen enger verzahnt sind. Keiner der Wege ist automatisch besser. Entscheidend sind die gew\u00fcnschte Integrationsdichte, das Betriebsmodell und die Frage, wie viel Plattformkomposition Ihr Team selbst \u00fcbernehmen will.<\/p>\n\n\n\n Wie gelangen Daten von Maschinen und Sensoren ebenso wie Daten aus Datenbanken, Dateien oder Application Programming Interfaces (APIs) in die Plattform?<\/p>\n\n\n\n Tabelle 1: Azure-Bausteine f\u00fcr die Anbindung von Datenquellen und die Datenaufnahme<\/em><\/p>\n\n\n\n F\u00fcr kontinuierliche Datenstr\u00f6me von Maschinen und Sensoren sind Azure IoT Hub, Azure Event Hubs, Azure Event Grid sowie die Edge-Dienste die naheliegenden Bausteine. Azure IoT Hub eignet sich, wenn Sie Ger\u00e4teidentit\u00e4ten, sichere Kommunikation und den Ger\u00e4telebenszyklus mitdenken m\u00fcssen. Azure Event Hubs ist dagegen f\u00fcr reines Hochvolumen-Streaming ohne Ger\u00e4teverwaltung gedacht. Azure Event Grid passt besonders zu MQTT- oder eventgetriebenen Architekturen. F\u00fcr Edge-Szenarien gibt es heute zwei gleichwertige Wege: Azure IoT Edge passt gut zu containerisierter Logik auf einzelnen Ger\u00e4ten oder Gateways, Azure IoT Operations ist st\u00e4rker, wenn Sie auf Azure Arc\/Kubernetes standardisierte industrielle Datenfl\u00fcsse mit MQTT, OPC UA und vordefinierten Cloud-Zielen aufbauen m\u00f6chten.<\/p>\n\n\n\n F\u00fcr die Batch-Ingestion aus Systemen wie MES, ERP, SQL-Datenbanken, Dateifreigaben, SFTP oder APIs ist dagegen Azure Data Factory meist der passendere Baustein. Mit seinen vielen Konnektoren und einer Self-Hosted Integration Runtime lassen sich auch On-Premises-Quellen in die Plattform einbinden. Damit wird deutlich: Datenaufnahme in die Plattform ist breiter als reine Ger\u00e4tekommunikation. Die passende Azure-L\u00f6sung h\u00e4ngt von Quelle, Latenzklasse und Betriebsmodell ab.<\/p>\n\n\n\n Wie speichern wir Daten strukturiert, versionieren sie, historisieren sie und bereiten sie f\u00fcr Analysen vor?<\/p>\n\n\n\n Tabelle 2: Azure-Bausteine f\u00fcr Datenspeicherung und Aufbereitung<\/em><\/p>\n\n\n\n Azure Data Lake Storage (ADLS) Gen2 ist der kosteneffiziente Standardspeicher f\u00fcr alle Daten. Ein Tabellenformat wie Apache Iceberg oder Delta Lake kommt hinzu, wenn Sie Transaktionen gem\u00e4\u00df ACID-Prinzip (Atomicity, Consistency, Isolation, Durability) und Historisierung mit Schema-Evolution brauchen, typisch f\u00fcr Silver und Gold. Wenn Sie gro\u00dfe Telemetrie- und Zeitreihendaten interaktiv analysieren wollen, ist Azure Data Explorer h\u00e4ufig die pr\u00e4zisere Wahl. Microsoft Fabric deckt diese Schicht integrierter ab: OneLake als zentrale Speicherbasis, Lakehouse f\u00fcr Aufbereitung und gemeinsame Datennutzung \u00fcber mehrere Workloads hinweg. Das Medaillon-Modell mappt so: Bronze speichert Rohdaten unver\u00e4ndert, Silver bereinigt und harmonisiert in Tabellen, Gold aggregiert f\u00fcr Business-Sichten.<\/p>\n\n\n\n Wie steuern, transformieren und aggregieren wir Datenfl\u00fcsse \u2013 im Batch oder Streaming?<\/p>\n\n\n\n Tabelle 3: Azure-Bausteine f\u00fcr Orchestrierung und Verarbeitung<\/em><\/p>\n\n\n\n Im PaaS-Ansatz eignet sich Azure Data Factory f\u00fcr klassische ETL-Jobs. Azure Databricks kommt bei komplexen Transformationen, gro\u00dfen Datenmengen und ML-Integration zum Einsatz. Azure Stream Analytics ist passend f\u00fcr einfache Streaming-Szenarien mit SQL, w\u00e4hrend Azure Functions kleine, ereignisgetriebene Aufgaben \u00fcbernehmen. Beim Einsatz von Microsoft Fabric decken Data Factory und Real-Time Intelligence gro\u00dfe Teile dieser Aufgaben in einer Plattform ab, von der Ingestion \u00fcber Eventstreams bis zur Analyse in Eventhouse oder Power BI.<\/p>\n\n\n\n Wie machen wir Daten f\u00fcr Endnutzer und Anwendungen zug\u00e4nglich?<\/p>\n\n\n\n Tabelle 4: Azure-Bausteine f\u00fcr Nutzung und Integration<\/em><\/p>\n\n\n\n Power BI ist oft die Standardwahl f\u00fcr Dashboards. Bei Microsoft Fabric ist es direkt in der Plattform eingebettet. Azure API Management eignet sich f\u00fcr das Bereitstellen von Daten und ML-Modellen als APIs. Azure Digital Twins ist sinnvoll, wenn Sie Anlagen, R\u00e4ume oder Prozessbeziehungen semantisch modellieren wollen. Azure App Service oder Azure Container Apps kommen ins Spiel, wenn individuelle Anwendungen oder Microservices ben\u00f6tigt werden.<\/p>\n\n\n\n Um die Theorie greifbar zu machen, folgen drei konkrete Stack-Beispiele zu den eingangs dargestellten Szenarien. Jedes Beispiel zeigt zun\u00e4chst den PaaS-Ansatz und eine m\u00f6gliche Alternative mit Microsoft Fabric. Anforderungen<\/strong>:<\/em><\/p>\n\n\n\n Azure-Stack<\/strong>:<\/em><\/p>\n\n\n\n Alternative mit Microsoft Fabric<\/strong>: Fabric Data Factory l\u00e4dt die Daten nach OneLake, ein Lakehouse bildet Bronze, Silver und Gold ab, und Power BI greift direkt auf dieselbe Plattform zu. Dieser Weg ist besonders dann attraktiv, wenn Datenintegration, Governance und BI m\u00f6glichst eng in einer SaaS-Umgebung verzahnt sein sollen.<\/p>\n\n\n\n Hinweis<\/strong>: Dieser Stack ist nahezu schl\u00fcsselfertig. Der Hauptaufwand liegt in der Datenmodellierung, der Definition von KPIs und der Governance (Wer darf welche Daten sehen?).<\/p>\n\n\n\n <\/p>\n\n\n\n Anforderungen<\/strong>:<\/em><\/p>\n\n\n\n Azure-Stack<\/strong>:<\/em><\/p>\n\n\n\n Alternative mit Microsoft Fabric<\/strong>: Real-Time Intelligence \u00fcbernimmt Ingestion, Eventstreams und Echtzeitanalyse, w\u00e4hrend OneLake und Eventhouse die Datenbasis bilden. Power BI oder Real-Time-Dashboards visualisieren die Ergebnisse. Das ist besonders interessant, wenn Streaming, Analyse und Visualisierung in einer Plattform zusammengef\u00fchrt werden sollen.<\/p>\n\n\n\n Hinweis<\/strong>: Azure bringt Streaming- und Visualisierungsbausteine mit, aber die Edge-Architektur (Filterlogik, Offline-Handling) und die OEE-Berechnungslogik sind projektspezifisch. OT muss Maschinen anbinden, IT muss Edge-Infrastruktur betreiben, das Datenteam muss die Streaming-Logik entwickeln.<\/p>\n\n\n\n <\/p>\n\n\n\n Anforderungen<\/em><\/strong>:<\/p>\n\n\n\n Azure-Stack<\/strong>:<\/em><\/p>\n\n\n\n Alternative mit Microsoft Fabric<\/strong>: Microsoft Fabric kombiniert OneLake, Data Engineering, Data Science und Power BI in einer Plattform. F\u00fcr Streaming-nahe Analysen kann Real-Time Intelligence die aktuellen Daten aufnehmen, w\u00e4hrend Modelle auf den historischen Daten in OneLake trainiert und ausgewertet werden. Wenn Vorhersagen sehr nah an der Anlage entstehen m\u00fcssen, bleibt der Edge-Teil weiterhin eine eigenst\u00e4ndige Architekturentscheidung.<\/p>\n\n\n\n Hinweis<\/strong>: Hier wird der Unterschied zwischen Plattform-Bausteinen und individueller Entwicklung besonders deutlich. Azure liefert ML-Tools, APIs und Bereitstellungsmechanismen, aber das Modell selbst, die Auswahl passender Datenmerkmale, das Konzept zum erneuten Trainieren des Modells und die Integration ins CMMS sind reine Projektarbeit. Ein enger Austausch zwischen Data-Science-Fachleuten, OT und IT ist dabei essenziell.<\/p>\n\n\n\n <\/p>\n\n\n\n Die drei Szenarien und der Azure-Werkzeugkasten verdeutlichen: Es gibt keine universelle Antwort auf die Frage, welcher Stack der Richtige ist. Entscheidend ist, konsequent in aktuellen und insbesondere zuk\u00fcnftigen Anwendungsf\u00e4llen zu denken. Latenzanforderungen, Datenvolumen, Nutzergruppen und organisatorische Rahmenbedingungen bestimmen, welche Kombination aus Ingestion, Speicherung, Verarbeitung und Visualisierung sinnvoll ist.<\/p>\n\n\n\n Microsoft stellt daf\u00fcr zwei belastbare Richtungen bereit: den komponierten Azure-PaaS-Weg mit Diensten wie Azure IoT Hub, Azure Event Hubs, Azure Data Factory, ADLS Gen2, Azure Data Explorer oder Power BI, und den st\u00e4rker integrierten SaaS-Weg \u00fcber Microsoft Fabric mit OneLake, Data Factory, Real-Time Intelligence und Power BI in einer Plattform. Die vorgestellten Stack-Beispiele zeigen typische Einstiegspunkte \u2013 vom minimalen Batch-Reporting bis zum ML-getriebenen Predictive-Maintenance-Setup.<\/p>\n\n\n\n Doch mit der Wahl des richtigen Stacks ist es nicht getan. Im zweiten Teil <\/a>dieses Artikels gehen wir auf die Fragen ein, die \u00fcber den reinen Tool-Einsatz hinausgehen: Wann brauchen Sie Edge-Verarbeitung, wann reicht die Cloud? Wo h\u00f6ren die verwalteten Dienste auf, und wo beginnt die eigentliche Projektarbeit? Wie gestalten Sie Governance, moderne Softwareentwicklung und Betrieb so, dass die Plattform langfristig tragf\u00e4hig bleibt? Und welche Fehlentscheidungen sollten Sie von Anfang an vermeiden?<\/p>\n\n\n\n![\"Drei](\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2026\/05\/Abbildung-1_Szenario1bis3-1024x576.jpg\")
Szenario 1: KPI-Reporting und Management-Dashboards<\/h4>\n\n\n\n
Szenario 2: OEE-Monitoring und Live-Dashboards<\/h4>\n\n\n\n
Szenario 3: Predictive Maintenance<\/h4>\n\n\n\n
<\/p>\n\n\n\nAzure-Bausteine: Nicht als Produktliste, sondern als Werkzeugkasten<\/h2>\n\n\n\n
Anbindung von Datenquellen und Datenaufnahme<\/h3>\n\n\n\n
Service<\/strong><\/td> Wof\u00fcr geeignet?<\/strong><\/td> Typische Einordnung<\/strong><\/td><\/tr><\/thead> Azure IoT Hub<\/td> Bidirektionale Kommunikation mit Ger\u00e4ten, Ger\u00e4teidentit\u00e4ten und Ger\u00e4telebenszyklus<\/td> Near-Real-Time<\/td><\/tr> Azure Event Hubs<\/td> Hochskalierendes Streaming f\u00fcr Millionen Events pro Sekunde, keine Ger\u00e4teidentit\u00e4t<\/td> Near-Real-Time<\/td><\/tr> Azure Event Grid<\/td> Event-basierte Architekturen, MQTT-Unterst\u00fctzung, Pub\/Sub<\/td> Near-Real-Time<\/td><\/tr> Azure IoT Edge<\/td> Containerisierte Logik auf Ger\u00e4ten oder Gateways, lokale Vorverarbeitung, Offline-F\u00e4higkeit<\/td> Edge-nahe Verarbeitung<\/td><\/tr> Azure IoT Operations<\/td> Edge-Datenebene auf Azure Arc\/Kubernetes mit MQTT-Broker, OPC-UA-Anbindung und Streaming<\/td> Edge-nahe Verarbeitung<\/td><\/tr> Azure Data Factory<\/td> Anbindung von Datenbanken, Datei- und API-Quellen, auch aus On-Premises-Umgebungen<\/td> Haupts\u00e4chlich Batch<\/td><\/tr> Partner-L\u00f6sungen (z. B. OPC UA Gateways)<\/td> Protokoll-\u00dcbersetzung und Maschinenanbindung im Brownfield<\/td> Abh\u00e4ngig vom Setup<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Datenspeicherung und Aufbereitung<\/h3>\n\n\n\n
Service<\/strong><\/td> Wof\u00fcr geeignet?<\/strong><\/td> Medaillon-Rolle<\/strong><\/td><\/tr><\/thead> Azure Data Lake Storage Gen2<\/strong><\/td> Skalierbarer, g\u00fcnstiger Objektspeicher f\u00fcr strukturierte und unstrukturierte Daten<\/td> Bronze, Silver, Gold<\/td><\/tr> Apache Iceberg oder Delta Lake (z.<\/strong> B. auf Azure Databricks)<\/strong><\/td> ACID-Transaktionen, Zeitreisen, Schema-Evolution auf dem Data Lake<\/td> Silver, Gold<\/td><\/tr> Microsoft Fabric (OneLake und Lakehouse)<\/strong><\/td> Integrierte SaaS-Plattform f\u00fcr Speicherung, Aufbereitung, Nutzung und Governance<\/td> Bronze, Silver, Gold<\/td><\/tr> Azure Data Explorer<\/td> Hochperformante Analyse von Telemetrie-, Log- und Zeitreihendaten<\/td> Silver, Gold<\/td><\/tr> Azure SQL Database \/ Azure Cosmos DB<\/strong><\/td> Relationale oder NoSQL-Datenbanken f\u00fcr spezifische Anwendungsf\u00e4lle<\/td> Gold (f\u00fcr Anwendungen)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Orchestrierung und Verarbeitung<\/h3>\n\n\n\n
Service<\/strong><\/td> Wof\u00fcr geeignet?<\/strong><\/td> Batch\/Streaming<\/strong><\/td><\/tr><\/thead> Azure Data Factory<\/strong><\/td> Orchestrierung, ETL\/ELT, viele Konnektoren, GUI-basiert<\/td> Haupts\u00e4chlich Batch<\/td><\/tr> Azure Databricks<\/td> Spark-basiert, flexibel f\u00fcr Batch und Streaming, ML-Workflows<\/td> Batch und Streaming<\/td><\/tr> Azure Stream Analytics<\/td> SQL-basiertes Streaming, einfach f\u00fcr einfache Transformationen<\/td> Streaming<\/td><\/tr> Microsoft Fabric mit Data Factory \/ Real-Time Intelligence<\/strong><\/td> Integrierte Orchestrierung, Eventstreams, Eventhouse und Echtzeitanalytik<\/td> Batch und Streaming<\/td><\/tr> Azure Functions<\/td> Serverless, ereignisgetrieben, f\u00fcr kleine Verarbeitungsschritte<\/td> Batch und Streaming<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Nutzung und Integration<\/h3>\n\n\n\n
Service<\/strong><\/td> Wof\u00fcr geeignet?<\/strong><\/td><\/tr><\/thead> Power BI<\/td> Business Intelligence, Dashboards, Reports, Datenanalyse in Fachbereichen<\/td><\/tr> Azure API Management<\/td> APIs bereitstellen, absichern, monitoren, versionieren<\/td><\/tr> Azure Digital Twins<\/td> Digitale Zwillinge f\u00fcr komplexe Anlagen, Raum- und Prozessmodelle<\/td><\/tr> Azure App Service \/ Azure Container Apps<\/strong><\/td> Web-Apps, individuelle Benutzeroberfl\u00e4chen, Microservices<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Technologie-Stack-Beispiele<\/h2>\n\n\n\n
<\/p>\n\n\n\n![\"Drei](\"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/wp-content\/uploads\/sites\/2\/2026\/05\/Abbildung-1_Beispiel1bis3-1024x576.jpg\")
Beispiel 1: Minimaler Stack f\u00fcr Reporting<\/h3>\n\n\n\n
\n
\n
\n
Beispiel 2: Near-Real-Time OEE f\u00fcr mehrere Linien<\/h3>\n\n\n\n
\n
\n
\n
\n
\n
Beispiel 3: Predictive Maintenance mit ML<\/h3>\n\n\n\n
\n
\n
\n
\n
Zwischenfazit: Vom Anwendungsfall zum Azure-Stack<\/h2>\n\n\n\n