Vier Blöcke, ein großer Live-Praxisteil, am Ende eine ehrliche Einordnung der Grenzen und der Unterschied zum Wettbewerb. Danach Bier und Brezn.
Der Anspruch hinter dem Titel und die zwei grundverschiedenen Wege zu Software.
Die Bandbreite der Plattform und ein großer Live-Praxisteil von rund 20 Minuten.
Warum ein Unternehmen so etwas braucht, wie es beherrschbar bleibt und wo es sich bewährt.
Wo UDM nicht hinwill, für wen es ist, der Unterschied zum Wettbewerb und OpenEnd.
Im Titel stecken drei Aussagen. Jede ist ein Versprechen, und jede ist ein roter Faden durch die nächste Stunde.
Nicht die Feldhilfe, die heute jedes Programm hat. Sondern maßgeschneiderte Oberfläche, Feldhilfe und Anleitungs-Popup, alle direkt am selbstgebauten Dialog gepflegt, an einer einzigen Stelle.
Fachprozesse werden von einer kontrollierten Rolle konfiguriert, nicht entwickelt. Kein Projekt, kein Release.
Für die Fachbereiche: Tempo, Kosten und Kontrolle. Darum geht es bis zum Schluss.
Die zwei Wege: fertige Software kaufen, oder eine Plattform konfigurierbar machen. Der Unterschied steckt in der DNA.
Die konfigurierbare Welt aus dem letzten Bild ist kein Konzept auf Papier. Sie kommt aus der Praxis, nicht vom Reißbrett.
Jahre in der Betriebsdokumentation. Jeder Wunsch der Fachbereiche wurde zum Entwicklungsprojekt mit Wartezeit.
Eine Plattform, auf der Fachprozesse konfiguriert statt programmiert werden. Daten beim Kunden, Änderungen ohne Release.
DVG Duisburg. Baustein für Baustein gewachsen, von der Fahrerkontrolle bis zu den Ausfahrten. Kein Großprojekt, sondern Etappen.
Das Besondere ist nicht die einzelne Funktion, sondern wie viel davon ab Werk dabei ist und sich per Konfiguration kombinieren lässt.
Ein Dutzend Ansichten und Eingabeformen auf einer Datenbasis. Eine Ansicht hinzufügen oder umschalten ist ein Klick, kein Projekt.
Jede Ansicht folgt demselben Bedienmuster, und die Hilfe wird direkt am selbstgebauten Dialog gepflegt: maßgeschneiderte Oberfläche, Feldhilfe und Anleitungs-Popup an einer Stelle. Kein separates Handbuch, keine Schulungsbudgets.
Tabelle für die Sachbearbeitung, Karte für die Leitstelle, Dashboard für die Leitung, alles auf denselben Daten und mit denselben Berechtigungen. Kein Export, keine zweite Wahrheit.
Erst ein paar echte Live-Systeme, damit klar wird, wie UDM aussieht. Dann eine Änderung im AdminClient, die sofort im UserClient sichtbar ist. Und zum Schluss baut der KI-Assistent eine App.
Nach der Demo steht meist dieselbe Frage im Raum: Lohnt sich so ein Weg für ein ganzes Unternehmen? Der Nutzen reicht nämlich weiter als die einzelne Fachabteilung.
KI verändert vor allem, wie schnell gebaut wird. Sie ändert aber nichts daran, dass ein Unternehmen eine kontrollierte, eigene Plattform braucht, auf der alles strukturiert und nachvollziehbar läuft. UDM ist nicht der Gegenspieler der KI, sondern ihre Landebahn. Der KI-Assistent baut bereits heute innerhalb von UDM. Je besser die KI wird, desto wertvoller wird eine Plattform, die das Erzeugte beherrscht, statt es zum Wildwuchs werden zu lassen.
Kein Review, kein Staging, ein Versehen sofort live? Diese Sorge nehme ich ernst und löse sie hier auf.
Jede Konfigurationsänderung an einem Element, ob Feld, Dialog, Datenquelle oder Regel, wird automatisch protokolliert: wer, wann, was, alter und neuer Wert. Bis in verschachtelte Einstellungen hinein.
Wer einen harten Gate will, arbeitet in einer Testumgebung. Die geprüfte Konfiguration wird in Paketen bewusst nach Produktiv transportiert, auf Wunsch im Vier-Augen-Prinzip, und lässt sich im Zweifel zurückrollen. Kein Auto-Durchgriff, kein Versehen.
Vieles davon stammt aus dem öffentlichen Verkehr, einer Branche mit kompromisslosen Anforderungen an Datenhoheit, Offline-Fähigkeit und Nachweis. Die Plattform selbst ist branchenneutral.
Ehrlich über Grenzen zu reden, ist auf einem Festival mehr wert als jede Werbefolie.
Wer komplett im Microsoft-365-Kosmos lebt, für den ist PowerApps oft die natürliche Wahl. Mendix und OutSystems sind für große Dev-Teams gebaut. UDM ist die Plattform neben euren großen Fachsystemen, nicht statt ihnen.
Konfiguration ist mächtig, aber sie gehört in geschulte Hände. Der Hebel ist die kontrollierte Admin-Rolle, nicht ungebremstes Citizen-Development.
KI hilft an immer mehr Stellen und steht auf der Roadmap. Der entscheidende Hebel ist heute aber die Konfiguration, weil sie greifbar bleibt und der Fachbereich sie nachvollziehen kann.
Zwei Zielgruppen, drei Mitnahmen. Auch wenn du nie eine Zeile UDM anfasst.
Wann eine Änderung Konfiguration ist und wann sie echte Softwareentwicklung bleibt.
Was es für Tempo, Kosten und die Rolle der IT bedeutet, wenn ein Admin statt eines Entwicklers ändert.
Wie man diese Änderungsmacht kontrolliert vergibt, damit Tempo nicht zu Schatten-IT wird.
Die Frage höre ich am häufigsten, deshalb hier kompakt die Punkte, die im Betrieb wirklich zählen. Wer es genauer wissen will, fragt mich nachher oder schreibt mir.
Direkt auf SQL Server, PostgreSQL und MySQL, bis zu drei davon parallel. On-Premise, auf Wunsch ganz ohne Internet. Kein Datenumzug, kein zweites Silo.
Wird ein Prozess speziell, deckt ihn der eingebettete C#-Code-Layer ab, im selben Werkzeug, ohne Wechsel. So reicht UDM dorthin, wo reine No-Code-Plattformen aufgeben.
GIS offline, mobiler Client, Reporting und KI-Assistent sind dabei. Keine Premium-Konnektoren, keine Module zum Nachkaufen.
Der Preis folgt dem, was UDM leistet, nicht der Zahl der Anwender. Genau hier trennt sich UDM am deutlichsten von den Generalisten.
System und App: eine komplexe Datenquelle wird einmal definiert und in beliebig vielen Apps wiederverwendet, ohne Doppelpflege. Admin und User: der Admin baut Sichten, Dialoge und Abläufe, der Anwender bekommt eine fertige, geführte Oberfläche, keinen Baukasten.
Lizenzen pro Nutzer summieren sich mit jedem Rollout. PowerApps Premium liegt bei rund 18 € je Nutzer und Monat, bei 800 Anwendern also über 14.000 € monatlich, allein für die Lizenz. UDM rechnet nutzerunabhängig: der Preis folgt dem gelieferten Wert, nicht der Kopfzahl. Gerade beim breiten Rollout, etwa alle Fahrer mobil, macht das den Unterschied.
Fragen, Widerspruch und Praxisgeschichten sind ausdrücklich erwünscht. Bei Bier und Brezn.
Erzähl mir von dem Prozess in deinem Haus, der dich heute am meisten Zeit kostet. Oft sieht man in zehn Minuten, ob Konfiguration der richtige Weg wäre oder eben nicht.
Kein Vertriebsgespräch nötig. Wenn dich die Frage „konfigurieren statt programmieren“ umtreibt, ist das hier genau der richtige Ort, um sie auszudiskutieren.
Drei Ebenen, je nachdem ob es um Geschäftsdaten oder um die Konfiguration selbst geht.
Pro Datenobjekt aktivierbar: wer hat wann welches Feld von welchem auf welchen Wert geändert. Optional Pflicht-Kommentar. Einträge revisionssicher, nicht löschbar.
Grenze: erfasst erst ab Aktivierung, nicht rückwirkend.Historisierung von Feldwerten mit Gültigkeitszeitraum (z. B. Preis-Historie). Die Ansicht zeigt immer den zum Stichtag gültigen Wert.
Jede Änderung an einem UdmElement (Feld, Dialog, Datenquelle, Regel) wird protokolliert, bis hin zum Pfad-Diff in verschachtelten Einstellungen. Änderungen sammeln sich in Paketen: exportierbar (Test nach Produktiv), kuratierbar, rückrollbar.
Ehrlich: DDL/Schema-Operationen werden transportiert, aber nicht zurückgerollt. Feinschliff/Tests laufen noch.