Konfigurieren statt programmieren – was ändert das für die Fachbereiche?
Jahrzehntelang galt: Der Fachbereich beschreibt, die IT entwickelt, das nächste Release dauert. Was passiert, wenn eine Änderung an der Unternehmenssoftware kein Entwicklungsprojekt mehr ist, sondern eine Konfiguration – durchgeführt von einer kontrollierten Admin-Rolle statt von Entwicklern?

Wir gehen der Frage ehrlich nach: Wie schnell wird ein Unternehmen, wenn nicht mehr jeder Wunsch durch die Entwicklungs-Pipeline muss – und wie verhindert man, dass aus „geht schnell" ein unkontrolliertes Durcheinander wird. Wer darf was ändern, und woran erkennst du vorab, ob ein Vorhaben in Konfiguration gehört oder echten Code braucht.

Als lebendes Beispiel nehmen wir unsere Datenplattform UDM. Du siehst live, wie ein Admin eine Konfigurationsänderung im Moment des Speicherns produktiv setzt – ohne Deployment, im Browser, mit eingebettetem Code-Layer für die Fälle, wo Klicken nicht reicht. Daten bleiben dabei auf deiner eigenen Datenbank (SQL Server, MySQL, MariaDB), bestehende Systeme (REST, OData, SQL, XML) hängst du an, und Governance – Änderungsprotokoll, Versionierung, DSGVO-Vorbereitung – ist ab Werk dabei. Auch die Frage, wo KI beim Bauen von Strukturen und Regeln wirklich hilft (und wo nicht), klären wir am offenen Beispiel.

Was du mitnimmst – auch ohne UDM: 

- eine Faustregel, 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 geschulter Admin statt eines Entwicklers Änderungen umsetzt
- wie man diese Änderungsmacht kontrolliert vergibt – damit Geschwindigkeit nicht zu Schatten-IT wird

 Für dich, wenn du entscheidest, wie in deinem Unternehmen Software entsteht und geändert wird – und das Warten auf das nächste Release kennst: Geschäftsführung, Fachbereichs- und Abteilungsleitung, Digitalisierungs- und IT-Verantwortliche im Mittelstand. Und für die Admins und Power-User, die solche Anwendungen später betreuen. In Verwaltung, Logistik/ÖPNV, Versorgung oder produktionsnahen Bereichen. Tiefes Technikwissen braucht es nicht.
 
Danach OpenEnd bei Bier und Brezn – Fragen, Widerspruch und Praxisgeschichten ausdrücklich erwünscht.