Aktuelle Themen
Ob Fachartikel, Whitepaper oder Live-Event – wir teilen unser Know-how aus über 400 Projekten.
In 3 Schritten von Abhängigkeit zu Handlungsspielraum – herstellerneutral, mit Souveränitätsscore,
Risikoradar & umsetzbarer Roadmap. Umfasst Cloud, Daten, KI und den digitalen Arbeitsplatz
Sie möchten IT-Trends nicht nur verfolgen, sondern von Experten erklärt bekommen? In über 20 aktuellen Events und Webinaren teilen unsere Spezialisten praxisnahes Wissen.
Sie suchen Antworten auf konkrete IT-Herausforderungen in Ihrem Unternehmen? In über 800 Fachbeiträgen beleuchten unsere Berater aktuelle Themen. Praxisnah, verständlich und mit dem Know-how aus hunderten Kundenprojekten.
Sie wollen fundierte Entscheidungsgrundlagen für Ihre IT-Strategie? Unsere über 120 Whitepaper liefern Ihnen tiefgehende Analysen, Vergleiche und Best Practices. Kostenlos und sofort verfügbar für Ihr nächstes Projekt.
Firmenhandys und -laptops sind längst nicht mehr nur im Büro im Einsatz. Mitarbeitende arbeiten von zu Hause, aus dem Zug oder beim Kunden und greifen dabei auf dieselben Unternehmensdaten zu wie am Schreibtisch vor Ort. Das ist praktisch, schafft aber auch Angriffsfläche. Ein verlorenes Gerät oder ein gestohlenes Passwort kann ausreichen, damit Unbefugte Zugang zu sensiblen Informationen erhalten. Multi Faktor Authentifizierung bei MDM-Geräten hilft bei diesem Problem, indem sie den Zugriff an mehrere unabhängige Nachweise knüpft. Was das konkret bedeutet und wie Unternehmen das sinnvoll umsetzen, zeigen wir in diesem Artikel.
Alle Mitarbeitenden und Freelancer, die sich in das Unternehmenssystem einloggen wollen, müssen sich ausweisen. Das ist grundsätzlich nichts Neues. Lange Zeit reichte dafür ein Passwort. Passwörter können allerdings erraten, gestohlen oder durch Phishing abgegriffen werden. Die Multi Faktor Authentifizierung löst das Problem, indem der Zugriff an mindestens zwei voneinander unabhängige Nachweise geknüpft wird.
Diese Nachweise lassen sich in drei Kategorien einteilen:
Bei MDM-verwalteten Geräten kommt zusätzlich der Vorteil dazu, dass das Gerät selbst im System registriert und bekannt ist. So entsteht die Möglichkeit, das Gerät als zusätzlichen Faktor zu nutzen. Der Zugriff ist also nur dann möglich, wenn das richtige Gerät, die richtige Person und der richtige Nachweis zusammenkommen. Das ist ein deutlich höheres Sicherheitsniveau als eine reine Passwortverwaltung ermöglicht.
Mobile Device Management bringt viele Vorteile für Unternehmen. Es ermöglicht, Geräte zentral zu verwalten, Sicherheitsrichtlinien durchzusetzen und im Verlustfall Daten aus der Ferne zu löschen. MDM schützt also das Gerät an sich, allerdings nicht den Zugang dazu. Gerade im Alltag können Situationen entstehen, in denen ein Passwort allein nicht ausreicht und ohne MFA Lücken aufkommen können:
Multi Faktor Authentifizierung bei MDM-Geräten senkt die Risiken durch solche Situationen deutlich. Ein abgegriffenes Passwort allein genügt nicht mehr, um sich Zugang zum Gerät zu verschaffen, weil der zweite Faktor fehlt. Damit scheitert der Angriff in den meisten Fällen an dieser Hürde.
MFA im MDM-Umfeld einzuführen ist grundsätzlich kein Mammutprojekt. Allerdings braucht es eine durchdachte Umsetzung, damit Sicherheit und Nutzerfreundlichkeit zusammen funktionieren. Besonders wichtig ist es, MFA bereits in den Einrichtungsprozess neuer Geräte zu integrieren. Nimmt ein Mitarbeiter ein Firmengerät zum ersten Mal in Betrieb, sollte von Anfang an MFA eingerichtet werden. Ist das Modell fester Bestandteil des Prozesses, ist die Akzeptanz höher und Mitarbeitende müssen sich nicht nachträglich mit Veränderungen auseinandersetzen.
Darüber hinaus gibt es einige Punkte, die Unternehmen bei der Planung berücksichtigen sollten.
MDM und Multi Faktor Authentifizierung lösen unterschiedliche Probleme und ergänzen sich deshalb gut. MDM sorgt dafür, dass Geräte sicher verwaltet und im Ernstfall kontrolliert werden können. MFA stellt sicher, dass nur die richtigen Personen Zugang erhalten. Zusammen arbeiten sie gegen die häufigsten Ursachen für Cyberangriffe. Wichtig ist, MFA von Beginn an in Prozesse zu integrieren, Mitarbeitende zu schulen und die Nutzerfreundlichkeit im Blick zu halten. Benötigen Sie Unterstützung in der Einführung von MDM oder möchten sich zum Thema Multi Faktor Authentifizierung beraten lassen, nehmen Sie gerne Kontakt zu uns auf.
Die neue Automation Anywhere Version 40 (Stand: 30.03.2026) markiert einen weiteren bedeutsamen Fortschritt in der Welt der Automatisierung. Mit den aktuellen Erneuerungen entwickelt sich die Plattform einen Schritt weiter in Richtung autonomen, agentischen Prozessautomatisierung, der Agentic Process Automation (APA).
Im Fokus der neuen Version stehen zentrale Themen wie die AI Governance, UI Agents, Agent Interoperability, AI Agent Studio, Automator AI und Co-Pilot sowie der Automation Workspace. Während vorherige Versionen sich insbesondere auf AI Agents, Generative Automation und agentische Prozesse zentrierten, legt diese Version den Schwerpunkt wesentlich auf Skalierbarkeit, Kontrolle und den Einsatz produktiver Unternehmensabläufe. Ziel ist es nicht nur leistungsstärker, sondern auch effizienter, transparenter und einfacher die Gestaltung der Automatisierung zu gewährleisten. Ein besonderes Highlight der neuen Version stellt die Funktion des Kopierens von Projekten dar. Diese Funktion erlaubt es, Änderungen und neue Ansätze separat vorzunehmen und diese auszutesten, ohne dabei das ursprüngliche Projekt zu beeinflussen.
Die AI Governance erfüllt die notwendige Kontrollfunktion eines Automatisierungsablaufs und stellt damit sicher, dass die AI Agents einen korrekten und idealen Handlungsablauf gewährleisten. Eine zentrale Erweiterung stellt die Einführung der AI Evaluation dar. Diese ermöglichen sowohl manuelle als auch automatische Bewertungen sowie der Erstellung von Leistungsanalysen, um die Qualität gezielt zu überprüfen. Damit wird die Struktur der AI Agents insgesamt nachvollziehbarer sowie kontrollierbarer. Das Bewertungssystem ist lizenzgebunden und dabei an AI Credits gekoppelt.
Ergänzend dazu protokollieren die Agent Logs nun die einzelnen Handlungsschritte. Auch hier besteht das Ziel der Nachvollziehbarkeit und bei Bedarf entsprechende Maßnahmen zur individuellen Optimierung zu ergreifen. Zusammen mit der Funktion der Observability, die eine übersichtliche Darstellung ermöglicht, entsteht eine verbesserte Transparenz und Steuerbarkeit von AI-basierten Automatisierungen.
Die Weiterentwicklung der UI Agents stellt eines der zentralen Highlights der neuen Version 40 dar und erzielt eine erhebliche Zeitersparnis. Zuvor war es den UI Agents nur selektorbasiert möglich, Anweisungen auf Benutzeroberflächen auszuführen. Änderungen an den Oberflächen führten bisher zu erhöhten Anpassungsaufwänden. Mit der neuen Version wurde dies optimiert: Die KI-Systeme können nun auf Basis natürlicher Sprache trotz wechselnder oder angepasster Benutzeroberfläche zugeteilte Aufgaben weiterhin verstehen und gewissenhaft durch dynamische Anpassung ausführen.
Mit der Erneuerung im Bereich der Agent Interoperability lassen sich erstmals Systeme und AI Agents von Drittanbietern im Unternehmensprozess der Automatisierung sicher integrieren. Jegliche Handlungsausführungen wie das Aufrufen von Task Bots, Prozessen und API Tasks werden vollständig unterstützt.
Die Unterstützung des Model Context Protocol (MCP) gewährleistet ein einheitliches Verständnis zwischen verschiedenen KI-Systemen und -Agents. Damit schafft diese Einführung in Automation Anywhere einen vereinfachten Integrationsprozess ohne weitere relevante Feautures aufgeben zu müssen. Konkret verbessert sich damit der externe KI-Workflow, außerdem verhilft es zu erweiterten Variablenverwaltungen ohne Blockierungen mit klareren Einsichten und einer einfacheren Anwendung ohne Zwischenschritte.
Um verbesserte Reasoning-Funktionen und robustere generative Automatisierungsfunktionen bereitzustellen, lassen sich nun in der neusten Version verschiedene Arten der GenAI-Modelle flexibel anbinden, die dadurch ein besseres Denken der Agenten erzielen. Zugelassen und unterstützt werden zum Beispiel die Modelle Amazon Bedrock oder Google Vertex AI. In der Praxis bedeutet das zum Beispiel: E-Mails werden nicht einfach zusammengefasst, sondern im weiteren Schritt der Automatisierung analysiert und darauf basierend werden weitere Handlungsschritte eingeleitet. Damit entwickelt sich das AI Agent Studio insgesamt zu einer deutlich leistungsfähigeren und kompetenteren Plattform für moderne Automatisierung.
Die Automator AI ist ebenfalls mit dieser Version einfacher als je zuvor zu nutzen. Eingaben können nun in einfacher Sprache erfolgen und fördern somit eine schnellere sowie einfachere Erstellung. Gleichzeitig bleiben weiterhin alle benötigten Sicherheitsmaßnahmen enthalten.
Auch die Funktionen des Co-Piloten wurden hinsichtlich ihrer Effizienz erweitert. Dieser arbeitet nun schneller, einfacher und mit weniger technischer Hürden. Aber was heißt das konkret? Die AI-Agent-Erkennung, -Suche sowie -Bereitstellung wird ab Version 40 in Automation Anywhere unterstützt. Damit können die AI-Agents gleichermaßen optimiert interagieren. Darüberhinaus wurde die Benutzeroberfläche des Co-Pilotens angepasst sowie das Unterstützen von benutzeridentifizierten Paketen veranlasst. Mit diesen Erneuerungen unterstützt die neue Version auch hier eine effizientere Entwicklung der Automatisierung.
Der Hauptbereich der Automation Anywhere unterlag ebenfalls Erneuerungen und Verbesserungen, darunter die neue Connector-Building mit OAuth-Unterstützung, eine bessere Verwaltung, direkte Dateizugriffslinks im Process Editor sowie eine neue Paketübersicht im Process Composer. Eine besondere sichtbare Änderung stellt die Umbenennung des Bots Stores in Agentic App Store dar. Diese Umbenennung unterstreicht den Wandel der Plattform von der klassischen Bot-Automation hin zu agentischer Automatisierung.
Die neue Automation Anywhere Version V.40 zeigt, dass sich die Plattform stetig weiterentwickelt und den Fortschritt einer agentischen Prozessautomatisierung anstrebt. Die Einführung der aufgelisteten Funktionen verdeutlichen das Ziel der weiterhin angestrebten Effizienz in der Arbeitsweise, der erhöhten Transparenz der einzelnen Arbeitsschritte sowie der Vereinfachung in der Nutzung und Anwendung durch vereinfachte Sprache oder dem Kopieren der Projekte. Für Unternehmen bedeutet diese neue Version in erster Linie: mehr Steuerung, erhöhte Nachvollziehbarkeit und die Möglichkeit der Skalierungen. Der Fortschritt der Plattform ist stark zu spüren und lässt neugierig auf die nächsten Erneuerungen warten.
Mit dem STACKIT Managed VPN stellt STACKIT einen Managed‑Service für sichere Site‑to‑Site‑VPN‑Verbindungen bereit. Der Dienst befindet sich aktuell in der Beta‑Phase, ist kostenlos nutzbar, jedoch derzeit ausschließlich per API verfügbar. Eine grafische Oberfläche existiert aktuell noch nicht.
Für Umgebungen, die bereits auf Infrastructure‑as‑Code setzen, ist das Managed VPN dennoch gut nutzbar und sauber in bestehende Automatisierungsprozesse integrierbar.
Das Managed VPN kann nur in Verbindung mit einer STACKIT Network Area genutzt werden. Die Network Area fungiert als zentrales Routing‑Konstrukt und ermöglicht es, Netzwerke, Projekte und deren virtuelle Netze übergreifend miteinander zu verbinden.
Das VPN Gateway erhält eine zentrale IP‑Adresse aus der Network Area, und über statische Routen werden die CIDR‑Ranges weiterer Netzwerke dorthin geleitet. Dadurch eignet sich der Service besonders gut für Hub‑and‑Spoke‑Architekturen.
Das STACKIT Managed VPN unterscheidet zwischen zwei Ressourcentypen:
Das VPN Gateway bildet den zentralen Einstiegspunkt und definiert die grundlegenden Eigenschaften der VPN‑Anbindung:
Für jede angegebene Availability Zone wird automatisch ein eigenes Tunnel Interface erzeugt. Dadurch entstehen immer zwei Tunnel, was eine hochverfügbare Anbindung ermöglicht.
Ein VPN Gateway kann mit einer oder mehreren VPN Connection‑Ressourcen verknüpft werden.
In diesen Objekten wird die eigentliche Site‑to‑Site‑Verbindung definiert:
STACKIT unterstützt alle gängigen modernen Verschlüsselungs‑ und Integritätsalgorithmen, was eine sehr gute Interoperabilität mit gängigen Gegenstellen ermöglicht.
Die Hochverfügbarkeit ist integraler Bestandteil des Designs:
Das erhöht zwar minimal den Konfigurationsaufwand, sorgt aber für eine ausfallsichere Verbindung.
Die Konfiguration erfolgt aktuell ausschließlich über die STACKIT API. In der Praxis lässt sich das sehr gut mit Terraform umsetzen, beispielsweise über Local Blocks und den offiziellen STACKIT Terraform Provider. Auch Beta‑Ressourcen werden unterstützt. Es ist nur eine Frage der Zeit, bis der das Managed VPN vollwertig mit eigenen STACKIT Terraform Resource-Blocks unterstützt wird.
Für IaC‑getriebene Umgebungen ist das Managed VPN dadurch gut reproduzierbar und versionskontrolliert betreibbar.
Unsere bisherigen Erfahrungen mit dem STACKIT Managed VPN sind sehr positiv. Der Tunnelaufbau funktionierte in mehreren Szenarien problemlos und auch über längere Zeiträume hinweg zeigte sich die Verbindung stabil. Die Unterstützung moderner IPsec‑Algorithmen sorgt für eine saubere und zuverlässige Konnektivität.
Der aktuell größte Nachteil ist das fehlende Benutzerinterface. Die komplette Konfiguration muss per API erfolgen, was nicht für jede Zielgruppe ideal ist. Als Ausgleich ist der Service in der Beta‑Phase jedoch kostenlos nutzbar.
Das STACKIT Managed VPN ist bereits in der Beta ein technisch ausgereifter Dienst:
Sobald eine GUI verfügbar ist, dürfte der Service auch für weniger IaC‑affine Teams interessant werden. Für automatisierte und hybride Architekturen ist das Managed VPN jedoch bereits heute eine sehr solide Lösung.
Die Cloud verspricht Flexibilität, schnelle Skalierung und moderne Infrastruktur. Viele Unternehmen erleben jedoch nach den ersten Monaten eine unangenehme Überraschung: Die monatliche Rechnung wächst schneller als der Mehrwert. Dabei liegt das Problem selten an der Cloud selbst. Vielmehr liegt es darin, wie sie genutzt wird. Möchten Unternehmen ihre Cloud-Kosten nachhaltig im Griff halten, brauchen sie mehr als nachträgliche Sparmaßnahmen. Wir zeigen in diesem Artikel, wie Unternehmen die Kostenoptimierung in der Cloud von der Wahl des Abrechnungsmodells bis hin zur Berücksichtigung von Kosten schon im Cloud Platform Engineering erfolgreich umsetzen können.
Wer zum ersten Mal eine Cloud-Rechnung aufschlüsselt, steht oft vor einer langen Liste an Posten: Rechenleistung, Speicher, Datentransfer, Support-Tarife. Der Grund für diese Komplexität liegt im Grundsatz vieler Cloud-Modelle: Anders als klassische On Premises IT-Infrastruktur wird Cloud-Nutzung in der Regel nicht pauschal abgerechnet, sondern verbrauchsabhängig. Verstehen Unternehmen, welches Modell wann sinnvoll ist, ist das ein Kostenvorteil. Andernfalls kann es jedoch schnell zur Kostenfalle werden. Die meisten Cloud Provider arbeiten mit ähnlichen Abrechnungsformen, die sich je nach Anbieter in Name und Details unterscheiden können.
Zusätzlich dazu bieten viele Anbieter weitere Einsparmöglichkeiten, die sich je nach Situation lohnen können:
Die Herausforderung für Unternehmen liegt vor allem darin, die Abrechnungsformen sinnvoll miteinander zu kombinieren. Viele Unternehmen starten mit nutzungsbasierter Abrechnung und vergessen, die Abrechnungsform später anzupassen, obwohl ein Großteil der Workloads mittlerweile stabil und planbar wäre. Mit diesem Verständnis beginnt die eigentliche Kostenoptimierung in der Cloud.
Die Kostenoptimierung der Cloud-Umgebung ist ein kontinuierlicher Prozess. Zwei Faktoren sind dabei besonders wichtig: Automatisierung und Kostentransparenz. Beide sollten unbedingt schon beim Aufbau der Cloud-Infrastruktur berücksichtigt werden, um zuverlässige Kostenoptimierung zu ermöglichen.
Beim Cloud Platform Engineering geht es um den strukturierten Aufbau einer internen Plattform, auf der Entwicklungsteams ihre Anwendungen betreiben. Dabei geht es besonders auch darum, wie Ressourcen von Grund auf verantwortungsvoll genutzt werden können. Schon im Aufbau der Cloud-Plattform hat das Team demnach die Aufgabe, entsprechende Maßnahmen nach Möglichkeit in die Plattform zu integrieren, zum Beispiel:
Neue Projekte starten so von Beginn an in einer Umgebung, die kosteneffizientes Verhalten unterstützt, etwa durch vordefinierte Budgetgrenzen pro Team oder automatische Warnmeldungen bei ungewöhnlich hohem Verbrauch.
Einer der häufigsten Kostentreiber in der Cloud ist denkbar simpel: Systeme laufen, obwohl sie gerade niemand braucht, Testumgebungen bleiben am Wochenende aktiv, Rechenleistung läuft nachts auf vollen Touren, obwohl keine Anfragen eingehen.
Durch automatisiertes Skalieren können Cloud-Teams dieses Problem lösen, indem Kapazitäten dynamisch an den tatsächlichen Bedarf angepasst werden: nach oben bei hoher Last, nach unten oder ganz aus bei Leerlauf. Was früher manuelle Eingriffe erfordert hätte, lässt sich heute regelbasiert steuern. Unternehmen können selbst definieren, wann eine Umgebung läuft und wann nicht und haben so einen starken Einfluss auf ihre Cloud-Kosten.
Wichtig: Eine automatische Abschaltung der Ressourcen ist allerdings nicht in jeder Umgebung möglich, etwa wenn Systeme rund um die Uhr verfügbar sein müssen. In solchen Fällen ist zuverlässiges Alerting umso wichtiger: Warnmeldungen bei ungewöhnlich hohem Verbrauch oder ungeplanten Laufzeiten helfen Unternehmen, teure Ressourcen zu erkennen, bevor sie die nächste Rechnung in die Höhe treiben.
Automatisierung funktioniert nur, wenn überhaupt sichtbar ist, welche Ressourcen und Prozesse wann laufen. Deshalb ist Kosten-Reporting ein so wichtiger Faktor. Dashboards und Auswertungen machen sichtbar, welche Teams, Projekte oder Anwendungen wie viel verbrauchen und wo es noch Optimierungspotenzial gibt. Viele Cloud-Anbieter stellen dafür eigene Tools bereit wie etwa Azue Advisor, die konkrete Einsparpotenziale aufzeigen. Sie identifizieren beispielsweise überdimensionierte Ressourcen und schlagen eine bedarfsgerechte Anpassung vor.
Im Rahmen von FinOps, einem Framework, das Finanz-, Entwicklungs- und Betriebsteams bei Cloud-Kosten zusammenbringt, ist Transparenz die Grundlage für alle weiteren Entscheidungen. Indem Teams Kosten sichtbar machen, ermöglichen sie Verantwortlichkeit: Sie sehen, was ihre Entscheidungen kosten und können entsprechend gegensteuern. Wichtig ist dabei außerdem, frühzeitig zu klären, wie lange Kostendaten aufbewahrt werden sollen. Manche Anbieter speichern historische Kostendaten nur für einen begrenzten Zeitraum. Sollen langfristige Auswertungen oder Vergleiche angestellt werden, sollten die Daten regelmäßig exportiert und extern gesichert werden.
Wie kann Kostenoptimierung konkret aussehen, wenn sie schon im Plattformaufbau berücksichtigt wird? Potenzial liegt oft in verschiedenen Bereichen.
Kostenoptimierung in der Cloud ist kein einmaliges Projekt, das nach einigen Wochen oder Monaten abgeschlossen ist. Vielmehr geht es darum, Kostenbewusstsein von Anfang an als Teil der Plattform zu verstehen: eingebaut in Prozesse, Automatisierungen und Reporting-Strukturen. Das FinOps Framework liefert den organisatorischen Rahmen, Cloud Platform Engineering schafft das technische Fundament. Bringen Unternehmen beides zusammen, schaffen sie eine Infrastruktur, die mit neuen Anforderungen wachsen kann, effizient und transparent läuft und deren Kosten dauerhaft unter Kontrolle bleiben.
Viele Unternehmen starten ihren Weg in die Cloud mit einem Wunsch: schnelle Migration, günstige Umsetzung und unkomplizierter Einstieg. Alle Workloads sollen einfach in die Cloud übertragen werden und schon ist die Migration abgeschlossen. Danach folgt dann jedoch oft die Ernüchterung: Die Kosten steigen, die Systeme laufen langsamer als erwartet und wirklich flexibel ist das neue Modell auch nicht. Hintergrund dafür ist oft die Migration nach dem Lift & Shift Ansatz. Was es damit auf sich hat, wo der Ansatz an seine Grenzen kommt und wie eine durchdachtere Strategie aussehen kann, erklären wir in diesem Artikel.
Die Lift & Shift Methode beschreibt eine Cloud-Migrationsstrategie, bei der bestehende IT-Systeme ohne größere Änderungen aus der On Premises Umgebung in die Cloud übertragen werden. Das System bleibt wie es ist und wird einfach verschoben. Damit ist dieser Ansatz der unkomplizierteste und schnellste in der Cloud-Migration. In einigen Szenarien ist es durchaus sinnvoll, Workloads mit dem Lift & Shift Ansatz zu migrieren:
Vor allem als temporäre Lösung oder bei sehr simplen Workloads kann Lift & Shift sinnvoll sein. Als dauerhafter Zustand entstehen dadurch jedoch fast immer Probleme. Die Cloud ist kein eins zu eins Ersatz für ein Rechenzentrum, sondern zeigt ihre Vorteile dann, wenn Cloud-native Ansätze zum Einsatz kommen.
Verschieben Unternehmen ihre IT-Infrastruktur unverändert in die Cloud, verschieben sie auch alle Probleme mit. In der Cloud können diese Probleme jedoch deutlich teurer werden als noch zuvor in der On Premises Umgebung.
Im eigenen Rechenzentrum läuft der Server rund um die Uhr, die Kosten dafür sind in der Regel fix. In der Cloud sind die Kostenmodelle meist komplexer: Oft handelt es sich um Pay-as-you-go-Modelle oder monatliche Abonnements, deren Kosten von der tatsächlichen Nutzung abhängen. Systeme, die nicht auf die Cloud ausgelegt sind, lassen sich jedoch nicht abhängig von der Nutzung skalieren und laufen dauerhaft auf Hochtouren. Daraus ergibt sich am Monatsende eine höhere Rechnung als die vorherige Servermiete.
Cloud-Umgebungen bieten zahlreiche Möglichkeiten: automatisches Hoch- und Runterskalieren bei Lastspitzen, integrierte Sicherheitsfunktionen und einfaches Testen neuer Features. Übertragen Unternehmen ihre Infrastruktur per Lift & Shift jedoch unverändert in die Cloud, entfallen häufig einige der zentralen Vorteile:
Zwar erscheint der Lift & Shift Ansatz anfangs oft günstiger als Neuentwicklungen oder Anpassungen, der Weg sorgt allerdings häufig für höheren Kosten und dafür, dass Vorteile der Cloud nicht ausgeschöpft werden können.
Eine funktionierende Cloud-Migrationsstrategie beginnt mit einer Frage: Was soll die Cloud für das Unternehmen leisten? Je nach Antwort unterscheiden sich die nächsten Schritte stark.
In der Praxis kommen meist verschiedene Wege zum Einsatz, abhängig vom jeweiligen Workload und den Zielen. Diese drei finden besonders häufig Anwendung.
Welcher Weg der richtige ist, hängt vom jeweiligen System, dem Zeitrahmen und dem Budget ab. Nicht jede Anwendung muss vollständig neu gebaut werden, aber Unternehmen sollten jede Anwendung bewusst einordnen.
Unabhängig vom gewählten Migrationspfad braucht es einige Grundlagen, damit die Cloud langfristig Vorteile schafft:
Lift & Shift ist grundsätzlich kein falscher Ansatz, sondern ein guter Weg für simple Anwendungen oder den ersten Start in der Cloud. Grundsätzlich gilt aber: Verschieben Unternehmen Systeme einfach in die Cloud, ohne ihre Eignung zu prüfen und sie anzupassen, entgehen ihnen die Vorteile nativer Cloud-Anwendungen und die Kosten können in die Höhe schnellen. Für eine bedachte Migration sollten Systeme deshalb immer bewusst eingeordnet, klare Ziele definiert und Schritt für Schritt modernisiert werden. Dieser Weg braucht zwar Planung, sorgt aber am Ende für eine saubere Cloud-Infrastruktur, in der die Vorteile voll ausgenutzt werden können.
2026 verschärft Microsoft die Standards für Kerberos in Active Directory: Die veraltete RC4-Verschlüsselung wird schrittweise deaktiviert. Ziel ist es, bekannte Risiken zu reduzieren und die Sicherheitslücke CVE-2026-20833 zu adressieren. Mit den Sicherheitsupdates des ersten Halbjahres im Jahr 2026 wird das Standardverhalten am Key Distribution Center (KDC) phasenweise angepasst. Ohne saubere Vorbereitung kann das zu Authentifizierungsfehlern und Zugriffsproblemen führen.
Der Artikel gibt Ihnen einen kompakten Überblick und zeigt, wie Sie Ihr Unternehmen rechtzeitig dafür prüfen und vorbereiten können.
Um die Änderung einordnen zu können, lohnt sich ein Blick ins Jahr 2022: Damals hat Microsoft ein grundlegendes Standardverhalten definiert. Microsoft steuert die zulässigen Kerberos-Verschlüsselungsalgorithmen über zwei Registry-Einträge: Der eine steuert das domänenweite Standardverhalten (DefaultDomainSupportedEncTypes) und der andere (msds-SupportedEncryptionTypes) steuert das Verhalten dezidiert für Computer und Serverdienste. Mit den Updates aus 2022 und 2026 ändert sich jeweils der implizite Standardwert von DefaultDomainSupportedEncTypes. Wenn man einen anderen Wert möchte, muss man ihn explizit setzen. Der KDC orientiert sich immer dann an DefaultDomainSupportedEncTypes, wenn msds-SupportedEncryptionTypes entweder nicht gesetzt oder 0 entspricht. Beide Werte bestimmen den genutzten Verschlüsselungsalgorithmus für die Kerberos Anmeldung. Das Key Distribution Center ist die Steuerzentrale für das Active Directory und übernimmt die Rolle eines Türstehers, der den Einlass kontrolliert.
Vereinfacht gesagt: vor 2022 akzeptierte der KDC entweder RC4 oder AES – je nachdem, was angefragt wurde. Seit 2022 gilt implizit ein Default von 0x27. Ab 2026 wird der Standardwert auf 0x18 gesetzt.
| Wert | Übersetzung | Bewertung |
| 0x18 | AES-128, AES-256 | ✅ |
| 0x27 | DES, RC4, AES-256-SK | ❌ |
| 0x1C | RC4, AES-128, AES-256 | ⚠️ |
| 0x1F | DES, RC4, AES-128, AES-256 | ❌ |
Wird der Standard auf 0x18 gesetzt, können ältere Systeme oder alte Konfiguration scheitern, wenn Sie auf RC4 angewiesen sind. Der KDC erlaubt nur Algorithmen, die effektiv erlaubt sind.
| Betriebssystem | DES_CBC_CRC | DES_CBC_MD5 | RC4_HMAC_MD5 | AES128_HMAC_SHA1 | AES256_HMAC_SHA1 |
| Windows 2003, Windows XP und älter |
Supported | Supported | Supported | No support | No support |
| Windows Vista | Supported | Supported | Supported | Supported | Supported |
| Windows 2008 | Supported | Supported | Supported | Supported | Supported |
| Windows 2008R2 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 7 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 2012 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 2012R2 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 10 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 2016 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 2022 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 11 | Deactivated | Deactivated | Supported | Supported | Supported |
| Windows 2025 | No support | No support | Deactivated | Supported | Supported |
Die automatische Umsetzung wird über den im Januar 2026 eingeführten Wert RC4DefaultDisablementPhase gesteuert. Je nachdem, wie dieser eingestellt ist, werden RC4 Versuche zugelassen, blockiert oder protokolliert.
Bei aktiviertem RC4DefaultDisablementPhase wird AES zum Standard und setzt damit DefaultDomainSupportedEncTypes implizit auf den Wert 0x18. Bei einem aktivierten Audit Wert werden Meldungen generiert, die die fehlende Unterstützung kenntlich machen.
Eine vorzeitige Überprüfung Ihrer Umgebung ist daher dringendst zu empfehlen. Nach Abschluss der Umstellung wird RC4 für Kerberos in einer Active Directory Umgebung deaktiviert und daher erstmal nicht mehr nutzbar sein.
Microsoft unterteilt die Umstellung in drei Phasen:
Visualisierung der drei Update Phasen für Kerberos Änderung
Die erste Phase ist die Audit Phase. In dieser Phase werden zusätzliche Telemetriedaten und Events eingeführt, um Probleme zu identifizieren, bevor die Durchsetzung greift. Ziel ist es, die RC4-Abhängigkeiten sichtbar zu machen und erforderliche Anpassungen rechtzeitig umzusetzen. Optional kann die Deaktivierung von RC4 bereits in dieser Phase manuell vorgezogen werden. Eine vorzeitige Deaktivierung sollte dennoch unbedingt vorab geprüft werden, da sie ansonsten zu Authentifizierungsabbrüchen und damit zu Dienstunterbrechungen führen kann. Für die Auswertung der Events bietet sich eine zentrale Stelle zur Protokollanalyse an (bspw. über Windows Eventlog Forwarding oder SIEM). Die Event ID’s 201-209, 4768-4769 sind zu prüfen.
In der zweiten Phase wird der Standard von RC4 auf AES automatisch gesetzt. Diese Umstellung kann noch rückgängig gemacht werden. Diese Phase ist die letzte Phase, in der Administratoren noch die Flexibilität haben, RC4DefaultDisablementPhase zurückzudrehen. Bevor es zur dritten Phase geht, sollte sichergestellt werden, dass kein Gerät mehr auf RC4 angewiesen ist, da ansonsten die Authentifizierung fehlschlägt.
Die dritte Phase ist die letzte Phase. In dieser Phase gibt es kein einfaches Entrinnen mehr. Die Durchsetzung greift ein und deaktiviert RC4. Eine Reaktivierung über RC4DefaultDisablementPhase ist dann nicht mehr möglich. Wenn Sie diese Phase überstanden haben und Ihre Serverdienste weiterhin laufen, haben Sie gute Arbeit geleistet.
Beides sind weitverbreitete Verschlüsselungsalgorithmen. RC4 war lange Bestandteil von vielen Softwares, da es im Vergleich zu AES effizienter und eine größere Abwärtskompatibilität gewährleistet.
Der Rivest Cipher 4 (RC4) Verschlüsselungsalgorithmus ist kryptografisch unsicher und kann durch sogenannte „Roasting Attacken“ wie dem Kerberoasting ausgenutzt werden. Hierbei fordert ein Angreifer ein Kerberos Ticket an und „brute forced“ offline das Passwort des Authentifizierungstickets. Gelingt es, das Passwort zu knacken, sind u.a. weitergehende Ticket-Manipulation wie dem Silver Ticket möglich, um sich Zugriff auf Dienste zu verschaffen.
Sie müssen handeln, wenn Sie eine Active Directory oder Hybrid-Umgebung nutzen. Sobald sich ein Legacy Gerät im Netzwerk befindet und das Update eingespielt wird, schlägt die Kerberos Authentifizierung fehl und es kommt zu einem Fallback zu NTLM. Bei NTLM gibt es ganz andere Angriffsvektoren, die zu beheben sind. Wenn Sie NTLM bereits erfolgreich unterbunden haben, schlägt die Anmeldung grundlegend fehl. Ggf. müssen Sie regulatorische Anforderungen (wie NIS2, DORA, ISO/IEC 27001 etc.) nachkommen und wollen daher beim Audit glänzen. Das können Sie nur, wenn Sie RC4 deaktivieren und AES die Bühne geben.
Um obiges kurz und knapp zusammenzufassen, hier eine Handlungsempfehlung zu der bevorstehenden technischen Umstellung seitens Microsofts. Es ist wichtig, dass Sie sich unbedingt vorab ein Bild Ihrer Umgebung machen. Die Umstellung findet automatisch statt und kann im schlimmsten Fall den Zugriff auf Serverdienste einschränken.
Bei Fragen oder Anregen zum Thema Active Directory oder Kerberos Authentfizierung stehen wir Ihnen gerne beratend zur Seite. Wir freuen uns auf Ihre Kontaktaufnahme.
SAP hat angekündigt, SAP Build Apps als eigenständiges Standalone‑Produkt zum 30. September 2026 einzustellen.
Für viele Unternehmen ist das mehr als eine übliche Produktabkündigung. Bestehende Anwendungen lassen sich nicht einfach „umstellen“. Sie müssen neu gedacht und in vielen Fällen manuell neu aufgebaut werden.
Genau deshalb ist eine Build Apps Migration kein reines Technikprojekt. Sie ist eine geplante Transition, die mehrere Ebenen betrifft: das Applikationsportfolio, die Architektur, den Betrieb und nicht zuletzt die benötigten Skills.
Dieser Artikel ordnet die Entscheidung der SAP ein, beschreibt die wichtigsten technischen Konsequenzen und zeigt realistische Handlungsoptionen auf. Dazu zählen der Wechsel in das neue SAP Build Angebot, ein Neubau mit SAPUI5 und CAP sowie der Einsatz von Drittanbieter‑Plattformen.
Die Zielgruppe sind IT‑Leitungen, Enterprise‑ und Solution‑Architekt:innen, Product Owner sowie Verantwortliche für SAP BTP, die bestehende Build‑Apps‑Anwendungen absichern und eine tragfähige Nachfolgestrategie entwickeln müssen.
Um die Tragweite der Abkündigung zu verstehen, hilft ein kurzer Blick in die Vergangenheit: SAP übernahm AppGyver im Februar 2021 und integrierte die No‑Code‑/Low‑Code‑Plattform später als SAP Build Apps in die SAP BTP. Der Ansatz passt zur propagierten Clean‑Core‑Strategie, da so Erweiterungen außerhalb des S/4HANA‑Kerns ermöglicht wurden.
Bereits zuvor gab es erste Einschnitte. Die AppGyver Community Edition verlor ihren Support zum 30. September 2024. Im April 2025 folgte schließlich der Launch des Unified SAP Build Ansatzes. Apps, Prozesse und Work‑Zone‑Themen wurden stärker zusammengeführt und in eine gemeinsame Lobby integriert.
Die Abkündigung der Standalone‑Variante ist eine Weiterführung dieser Konsolidierung. SAP möchte die Werkzeuge für Anwendungen, Prozessautomatisierung und Portale in einem integrierten Angebot bündeln.
Auf dem Papier wirkt das vereinfachend. Für Bestandskunden bedeutet es jedoch einen harten Schnitt. Das frühere Standalone Build Apps basiert technologisch auf anderen Grundlagen als das neue Unified‑Umfeld.
Die wichtigste technische Aussage lässt sich klar zusammenfassen: Für Frontend‑Projekte existiert kein automatisierter Migrationspfad.
Konkret bedeutet das, dass Seiten, Datenbindungen, Logikflüsse, Navigationen und individuelle Komponenten in der Zielumgebung manuell neu aufgebaut werden müssen.
Was viele Teams an Build Apps überzeugt hat – die visuelle Modellierung von Logikflüssen – wird in der Transition zur größten Herausforderung. Es gibt kein Werkzeug, das visuelle Logikdiagramme automatisiert in die neue Architektur überführt. Der Grund hierfür liegt in den unterschiedlichen Grundlagen der Systeme. Während das ursprüngliche Build Apps unter anderem auf steroids.js und AngularJS basierte, orientiert sich das neue Unified‑Angebot an SAP‑Standards wie SAPUI5 und dem Cloud Application Programming Model (CAP).
Das bedeutet nicht, dass ein Migrationspfad grundsätzlich unmöglich gewesen wäre. SAP hat sich jedoch bewusst dagegen entschieden, auch für Standardszenarien einen solchen bereitzustellen.
In der Praxis müssen bestehende Anwendungen daher zunächst sauber dokumentiert und anschließend neu implementiert werden. Betroffen sind unter anderem Variablenbindungen, Formeln, Event‑Handler, Navigationslogik sowie Custom‑JavaScript‑Komponenten.
Für Backend‑Projekte beschreibt SAP zumindest einen rudimentären Weg, Daten zu übernehmen. Dieser Ansatz ist jedoch eher eine manuelle Datenrettung als eine Migration im klassischen Sinn.
Entitäten werden einzeln aus dem Datenbrowser als CSV‑Dateien exportiert. In der Zielumgebung – idealerweise in einem CAP‑Projekt – müssen passende Tabellen manuell angelegt werden. Anschließend erfolgt der Import der CSVs.
Nicht automatisch übernommen werden dabei Beziehungen zwischen Entitäten, Metadaten, Berechtigungsstrukturen und weitere implizite Regeln. Genau diese Aspekte sind in produktiven Anwendungen häufig kritisch. Zusätzlich entsteht ein Integrationsrisiko: Wenn bestehende Frontends Services konsumieren, sollten neue CAP‑Services möglichst kompatible API‑Signaturen bereitstellen, um den Anpassungsaufwand im Frontend zu begrenzen.
Wenn Sie SAP Build Apps produktiv einsetzen, sollten Sie die Situation nicht als „ein Projekt“ betrachten, sondern als Portfolio‑Entscheidung.
Nicht jede Anwendung benötigt denselben Zielpfad.
Ein strukturiertes Application‑Portfolio‑Management hilft, Prioritäten zu setzen. Typische Kriterien sind strategische Relevanz, technische Komplexität und Änderungsdynamik.
SAP garantiert den weiteren Betrieb bis zum Ende laufender Verträge. Das gilt unabhängig vom Lizenzmodell. SLAs und Wartungszusagen bleiben bestehen.
Diese Option ist jedoch mit Einschränkungen verbunden. Für die Standalone‑Version sind keine neuen Funktionen vorgesehen. Neue Sicherheitsstandards oder Innovationen wie die tiefere Integration von Joule fließen primär in das Unified Offering.
Zudem wird es zunehmend schwieriger, qualifizierte Fachkräfte für eine auslaufende Technologie zu finden.
Abwarten kann daher sinnvoll sein, wenn Anwendungen stabil sind oder ohnehin vor September 2026 abgelöst werden. Für alle anderen stellt es meist nur einen zeitlichen Aufschub dar.
Der offizielle SAP‑Pfad ist der Umstieg auf das vereinheitlichte SAP Build Angebot.
Der Mehrwert liegt nicht in einer automatisierten Migration, sondern in einer konsolidierten Entwicklungsumgebung. Low‑Code, Pro‑Code und KI‑gestützte Funktionen sind zentral gebündelt.
Viele Unternehmen nutzen den Neubau gezielt, um technische Schulden abzubauen. Anwendungen werden auf einer moderneren Architektur neu aufgesetzt – mit klarer Trennung von Frontend, Services und Datenmodell.
Gleichzeitig sollte kritisch geprüft werden, ob und in welchem Umfang Investitionen in ein weiteres SAP‑Innovationsprodukt sinnvoll sind, dessen langfristige Stabilität sich erst bewähren muss.
Für geschäftskritische Anwendungen ist der Einschnitt ein Anlass, wieder stärker auf Pro‑Code zu setzen.
CAP und SAPUI5 gelten als strategische SAP‑Standards. Sie bieten langfristige Wartbarkeit und reduzieren die Abhängigkeit von kurzfristigen Tool‑Entscheidungen.
CAP strukturiert die Service‑Entwicklung und etabliert bewährte Enterprise‑Patterns. UI5 – ergänzt durch Fiori Elements – kann die Entwicklung standardisierter Oberflächen beschleunigen.
Der höhere Schulungsaufwand ist real, rechnet sich aber häufig über den Lebenszyklus zentraler Anwendungen.
Einige Unternehmen evaluieren bewusst Alternativen außerhalb des SAP‑Portfolios. Das ist insbesondere dann sinnvoll, wenn Fachbereiche stark eingebunden sind, Time‑to‑Market im Fokus steht oder mobile Szenarien besondere Anforderungen stellen.
Plattformen wie Simplifier, Neptune DXP oder Mendix adressieren unterschiedliche Schwerpunkte – von schneller Fiori‑Entwicklung über ABAP‑nahe Architekturen bis hin zu komplexen, systemübergreifenden Anwendungen.
Gleichzeitig erhöht ein Drittanbieter die Abhängigkeiten, beeinflusst Lizenzkosten und steigert die Komplexität der Landschaft. Dieser Weg sollte daher gut abgewogen sein.
Die größte Gefahr in solchen Umbruchphasen ist Aktionismus: Einzelne Apps werden hektisch neu gebaut, während das Gesamtportfolio unklar bleibt. Besser ist ein klarer Ablauf, der technische und organisatorische Arbeitspakete verbindet.
Der erste Schritt ist eine vollständige Inventarisierung Ihrer SAP Build Apps Lösungen:
Daraus entsteht eine Priorisierung nach strategischer Relevanz und technischer Komplexität. So vermeiden Sie, dass knappe Kapazitäten in Apps fließen, die ohnehin abgelöst werden.
Zum Schluss entscheidet die Umsetzungsgeschwindigkeit oft über Erfolg oder Stillstand. Deshalb ist es sinnvoll, frühzeitig Pilot‑Apps auszuwählen: eine einfache, eine mittelkomplexe und eine kritische App. Auf dieser Basis können Sie Standards für Architektur, Security, Naming, Transport/Deployment und Tests definieren und diese Standards danach konsequent für die restliche Build Apps Migration anwenden.
SAP setzt stark auf generative KI, um den Neubau zu beschleunigen. Joule soll in SAP Build Code und Build Apps helfen, Anforderungen schneller in umsetzbare Strukturen zu übersetzen. Der Trend geht damit von reinem Low‑Code stärker in Richtung „KI‑assistierter“ Entwicklung, bei der Menschen Ergebnisse prüfen, integrieren und absichern.
Wichtig ist hier aber die Erwartungshaltung: KI kann Zeit sparen, sie ersetzt aber nicht die Kernarbeit der Transition – also saubere Zielarchitektur, klare Verantwortlichkeiten, Sicherheitskonzept, Tests und Betriebsprozesse.
Cloud-Umgebungen wachsen oft schneller als Teams sie manuell verwalten können. Zwar sind sie in kleinen Infrastrukturen noch überschaubar, können allerdings schnell zum Problem werden, sobald die Infrastruktur komplexer wird. Änderungen dauern zu lange, Fehler können sich einschleichen und Entwickler warten auf Ressourcen, um weiterarbeiten zu können. Um sowohl Entwicklern als auch dem Platform-Team die Arbeit zu erleichtern, können verschiedene Prozesse automatisiert werden. In diesem Artikel geben wir einen Überblick, wie Automatisierung im Cloud Platform Engineering aussehen kann und welche Vorteile sie Unternehmen bringt.
Ohne Automatisierung ist Cloud Platform Engineering komplex: Jede Entwicklungsumgebung muss manuell aufgesetzt werden. Dadurch können sich Releases verzögern, Umgebungen inkonsistent sein und eine aufwendige Koordination ist nötig. Auch das Fehlerpotenzial ist entsprechend höher: Je mehr manuelle Eingriffe ein Prozess erfordert, desto wahrscheinlicher wird ein Versehen und desto schwerer lässt sich das Problem im Nachhinein nachvollziehen.
In der Praxis bedeutet das: Tickets stapeln sich, Teams verschieben Deployments und das Platform-Team wird zum Flaschenhals, weniger zum Enabler. Gerade beim Aufsetzen der Umgebungen gibt es jedoch zahlreiche wiederkehrende und regelbasierte Aufgaben, die sich an Anforderungen und Compliance-Richtlinien des Unternehmens orientieren. Um das Platform-Team zu entlasten und verlässlich und schnell Umgebungen aufsetzen zu können, kann Automatisierung auf verschiedenen Wegen umgesetzt werden.
Im Cloud Platform Engineering gibt es nicht die eine Automatisierung oder das eine Automatisierungs-Tool. Vielmehr können Unternehmen in mehreren Bereichen Tools und Konzepte einsetzen, die sich gegenseitig ergänzen. Dabei kann es beispielsweise um die Bereitstellung der Infrastruktur gehen, die eigenständige Arbeit der Entwickler oder den permanenten Blick auf den Betrieb.
Bei CI/CD-Pipelines handelt es sich um einen automatisierten Prozess, der Änderungen am Code kontinuierlich integriert (Continuous Integration), testet und bereitstellt (Continuous Deployment). Das Prinzip dahinter, Infrastructure as Code, sorgt dafür, dass Umgebungen nicht mehr per Hand konfiguriert werden müssen. Stattdessen entstehen sie durch reproduzierbare, beschreibbare Vorlagen.
In einer automatisierten Pipeline durchläuft jede Änderung an der Infrastruktur mehrere Schritte, bevor sie in den Release geht: automatische Validierung, Sicherheitschecks und Testläufe. Fehler werden so früh erkannt und nicht erst dann, wenn sie bereits Auswirkungen haben. So entstehen konsistentere Umgebungen, weniger manuelle Eingriffe und deutlich kürzere Durchlaufzeiten bei Änderungen.
Die wichtigsten Vorteile auf einen Blick:
Gerade in wachsenden IT-Teams entsteht oft die gleiche Herausforderung: Entwickler müssen auf Ressourcen warten, weil jede Anfrage über das Platform-Team läuft. Mit Self-Service-Portalen können Unternehmen dieses Problem lösen, indem sie standardisierte Bausteine bereitstellen, die Entwickler eigenständig nutzen können. Dafür brauchen sie kein technisches Spezialwissen und sparen sich Wartezeiten.
Die Plattform dabei stellt sicher, dass alles, was über das Portal geschieht, den internen Standards für Sicherheit und Compliance entspricht. Entwickler arbeiten schneller und unabhängiger. Das Platform-Team wiederum gewinnt Zeit im Arbeitsalltag.
Die wichtigsten Vorteile auf einen Blick:
Neben dem Rollout gibt es auch im laufenden Betrieb Möglichkeiten zur Automatisierung. Vom Monitoring bis zur automatischen Reaktion auf Probleme können Unternehmen verschiedene Automatisierungen umsetzen.
Wichtig ist vor allem der Unterschied zwischen klassischem Monitoring und moderner Observability: Monitoring zeigt auf, dass etwas nicht stimmt, Observability hingegen gibt Aufschluss darüber, warum etwas nicht stimmt. Durch automatisierte Alarme, strukturierte Protokolle und nachvollziehbare Metriken können Teams proaktiv handeln. Teilweise gibt es bereits Systeme, die bekannte Probleme selbstständig korrigieren können, ohne dass ein Mensch eingreifen muss.
Die wichtigsten Vorteile auf einen Blick:
Die Wirkung von Automatisierung im Cloud Platform Engineering zeigt sich auf verschiedenen Ebenen, von der Geschwindigkeit bis zur Kosteneffizienz.
Automatisierung ist ein wichtiger und grundlegender Bestandteil im Cloud Platform Engineering. Durchdachte Automatisierungsstrukturen schaffen die Voraussetzungen für schnellere Entwicklung, höhere Zuverlässigkeit und Cloud Plattformen, die mit den Anforderungen des Unternehmens wachsen können. Zwar lohnt es sich schon von Anfang an, Automatisierung in die Cloud Infrastruktur zu integrieren, aber auch nachträglich können Tools und Konzepte integriert werden. Dabei ist es am sinnvollsten, mit den Bereichen zu beginnen, die den größten Engpass verursachen und von dort aus strukturiert weiterzubauen. So entsteht mit der Zeit eine zuverlässige Automatisierungsstruktur.
Hinter jeder schnellen Lösung steht ein echter Mensch, der genau weiß, was er tut. Unsere zertifizierten IT-Experten sind da, um Ihre Probleme schnell, freundlich und stressfrei zu lösen.
Stehen Sie vor der Frage, wie Ihre Lagerstrategie unter SAP S/4HANA aussehen soll? In diesem Webinar vergleichen wir SAP Stock Room Management, SAP EWM und SAP Logistics Management (LGM) inklusive klarer Entscheidungskriterien, Vor-/Nachteilen und typischen Einsatzszenarien aus der Praxis.
Im Webinar erhalten Sie Antworten auf die Fragen:
Viele Unternehmen nutzen historisch SAP WM und müssen im Zuge von S/4HANA ihre zukünftige Lagerlösung festlegen.
Stock Room Management basiert technisch auf WM (Tabellen/Customizing/Transaktionen), bietet aber eingeschränkten Funktionsumfang und ist eher für einfachere, manuell geprägte Lager gedacht.
SAP EWM ist die strategische, langfristig ausgerichtete Lösung für Lagerprozesse, geeignet von „einfach“ bis „hochkomplex“ (inkl. Varianten Embedded/Dezentral und Basic/Advanced).
SAP Logistics Management (LGM) ist die neue, cloud-basierte SAP-Lösung, die Warehouse Execution und Transportation Dispatching plus Network Collaboration in einer Plattform kombiniert und explizit auf kleine bis mittelkomplexe Versand-/Lagerstandorte zielt (inkl. AI-Assistenz).
Im Webinar ordnen wir ein, für wen welche Lösung passt, wo die Grenzen liegen und wie man daraus eine Roadmap ableitet.
Let’s talk IT – seien Sie dabei
Die Teilnahme ist kostenlos – melden Sie sich an und bringen Sie gerne konkrete Fragen aus Ihrer Lager-/S/4HANA-Roadmap mit.
Digitale Souveränität ist in zahlreichen Unternehmen in den Fokus gerückt. Ob Cloud, KI oder Datensicherheit: Für Expert:innen entstehen konkrete technische und regulatorische Herausforderungen, die verschiedenste Fragen aufwerfen. Wie können wir Cloud-Infrastrukturen gestalten, die Unabhängigkeit und Performance verbinden? Welche Governance-Modelle brauchen wir, um KI-Systeme unter verschärften Compliance-Anforderungen zu betreiben? Wie können wir Datenschutz und Verfügbarkeit in einem unsicheren geopolitischen Umfeld gewährleisten? In unserem Networking-Event (unterstützt durch STACKIT) gehen wir diesen Fragen auf den Grund.
Unsere Veranstaltung „Digitale Souveränität: Cloud, KI & Datensicherheit im Fokus“ bringt Spezialist:innen aus den Bereichen Cloud Computing, Artificial Intelligence und Cyber sowie Data Security zusammen und möchte den Raum für Austausch öffnen. Wir diskutieren digitale Souveränitätsstrategien aus der Praxis, geben Beispiele zur Einführung deutscher Cloud Technologien mit STACKIT, diskutieren Best Practices und kommen so in Vorträgen, Diskussionen und beim abendlichen BBQ über den Dächern Stuttgarts ins Gespräch.
Donnerstag, 21. Mai 2026, 14:00 Uhr
OutOfOffice Stuttgart
Am Fruchtkasten 3
70173 Stuttgart
BBQ und Getränke inklusive
Schwarz Gruppe, ARD, TRUMPF, dm, SWR, Bosch Health Campus, Röchling, Deutsche Bahn, thyssenkrupp, WDR, DÜRR und viele mehr
Die Bedeutung von Nachhaltigkeit in der Informationstechnologie nimmt stetig zu, sowohl aus ökologischer als auch aus ökonomischer Perspektive. In diesem Webinar vermitteln wir Ihnen grundlegendes Wissen zu IT Sustainability und zeigen auf, wie Sie Nachhaltigkeitsprinzipien effektiv in Ihrer IT-Strategie verankern können.
Sie erfahren, wie sich nachhaltige IT auf den Energieverbrauch, die Reduzierung von CO2-Emissionen und die Verlängerung der Lebensdauer von IT-Komponenten auswirkt. Wir besprechen, wie Unternehmen durch die Implementierung grüner IT-Praktiken nicht nur die Umwelt schützen, sondern auch langfristig Kosten einsparen können.
Zusätzlich erhalten Sie Einblick in erfolgreiche Fallstudien und lernen Best Practices kennen, mit denen Sie Ihre IT-Prozesse und -Systeme nachhaltiger gestalten können.
Willkommen bei unserem exklusiven Support für Bestandskunden. Hier finden Sie alle nötigen Informationen, um schnell und unkompliziert Hilfe bei technischen Anfragen zu erhalten.
Für eine direkte Unterstützung per Fernwartung, laden Sie bitte unser TeamViewer-Modul herunter:
Bitte beachten Sie: Dieser Kanal ist speziell für technische Anfragen unserer Bestandskunden vorgesehen. Für allgemeine Anfragen, Informationen zu unseren Dienstleistungen oder eine Erstberatung nutzen Sie bitte unser Kontaktformular oder schreiben Sie eine E-Mail an [email protected].
