Geschäftsanwendungen per Dialog ändern: Felder, Workflows, Ansichten und Automatisierung
Der eigentliche Produktwert eines AI Builders liegt in kontinuierlicher dialogischer Weiterentwicklung: Felder, Workflows, Ansichten, Berechtigungen und Automatisierungen können auf der Metadatenebene sicher evolvieren.
Kurz gesagt: Der eigentliche Wert, Systeme per Dialog zu ändern, liegt nicht im „Chatten, und es ändert sich“ – sondern darin, dass jedes hinzugefügte Feld, jeder geänderte Workflow und jede angepasste Berechtigung in einer überprüfbaren, rückrollbaren Metadatenebene landet. Schnell zu ändern und sicher zu ändern.
Nach dem Go-live einer Geschaftsanwendung beginnt die eigentliche Arbeit erst.
Der Support-Leiter möchte ein weiteres Feld. Die Vertriebsleiterin will eine Phase ändern. Finance braucht einen zusätzlichen Genehmigungsschritt. Legal möchte Risikoregeln anpassen. Operations braucht ein weiteres Dashboard. IT will Berechtigungen enger ziehen. In klassischer Softwareentwicklung werden daraus Tickets: schätzen, planen, entwickeln, testen, ausrollen.
Das wichtigste Versprechen eines AI Builders ist, dass ein großer Teil dieser Änderungen nicht mehr als “Anforderung einreichen”, sondern als “im Dialog anpassen” funktioniert.
Dabei muss man präzise bleiben. Dialogische Änderung bedeutet nicht, dass KI ein System beliebig verändert. Es bedeutet, dass natürliche Sprache einen erklärbaren, bestätigbaren und rückrollbaren Metadaten-Änderungsplan erzeugt.
Woruber Leser sich sorgen
Aus Sicht von Low-Code-Nutzern klingt “eine App per Dialog andern” bequem, aber auch riskant.
Naheliegende Fragen sind:
- Ändert die KI vielleicht das falsche Objekt?
- Beeinflusst ein neues Feld bestehende Formulare?
- Verändert ein Workflow laufende Genehmigungen?
- Öffnet eine Berechtigungsänderung sensible Daten?
- Sendet eine Automatisierung falsche Benachrichtigungen?
- Führt ein Agent Aktionen außerhalb seiner Rechte aus?
- Kann man nach der Änderung zurückrollen?
Ein Artikel über AI Builder sollte deshalb nicht nur sagen: “Mit einem Satz die App ändern.” Entscheidend ist, wie die Plattform aus einem Satz eine kontrollierte Änderung macht.
Änderungstyp 1: Ein Feld ergänzen
Der Nutzer sagt:
Fuge bei Kunden ein Feld “Verlangerungsrisiko” hinzu, mit den Optionen niedrig, mittel und hoch. Hochriskante Kunden sollen im Board der Customer-Success-Manager erscheinen.
Ein professioneller AI Builder sollte das nicht sofort ausführen, sondern zuerst einen Änderungsplan erzeugen:
| Änderung | Plan |
|---|---|
| Objekt | customer andern |
| Feld | Enum-Feld renewal_risk erganzen |
| Formulare | In Detail- und Bearbeitungsseiten anzeigen |
| Ansicht | Board “High-risk renewal customers” anlegen |
| Berechtigungen | Customer Success darf bearbeiten, Sales nur lesen |
| Automatisierung | Verantwortliche informieren, wenn Risiko hoch wird |
| Agent | Kundenzusammenfassungen durfen das Feld nutzen |
Erst nach Bestatigung werden die Metadaten verandert.
Das ist mehr als “eine Spalte hinzufugen”. Das Feld wird Teil der gesamten Laufzeit der Anwendung, nicht nur Teil einer Datenbanktabelle.
Änderungstyp 2: Einen Workflow ändern
Der Nutzer sagt:
Wenn eine Erstattung über 3.000 liegt, soll zuerst die direkte Führungskraft genehmigen, danach der Finance Manager. Wenn das verknüpfte Projektbudget nicht reicht, muss zusätzlich der Budgetverantwortliche bestätigen.
Dieser Satz betrifft Bedingungen, Genehmigungsknoten, Status, Benachrichtigungen, Ausnahmen und Audit.
Der Builder sollte erzeugen:
- Eine Betragsbedingung;
- Einen Genehmigungsknoten für die direkte Führungskraft;
- Einen Genehmigungsknoten für den Finance Manager;
- Eine Prufung des Projektbudgets;
- Einen Knoten für den Budgetverantwortlichen;
- Pfade für Ablehnung und Nachforderung von Unterlagen;
- Kommentare und Zeitstempel im Audit.
Gleichzeitig sollte er den Wirkungsbereich erklären: Gilt der neue Workflow nur für neu eingereichte Erstattungen oder auch für bereits laufende Genehmigungen? Wenn laufende Instanzen betroffen sind, braucht es eine Migration?
Das ist ein professionelles Detail, das in Low-Code-Plattformen sehr wichtig ist. Ein Workflow ist nicht fertig, nur weil er auf einer Leinwand gezeichnet wurde. Er muss auch mit laufenden Prozessinstanzen umgehen.
Änderungstyp 3: Eine Ansicht generieren
Ansichten eignen sich besonders gut für dialogische Generierung, weil Nutzer oft genau wissen, was sie sehen wollen, aber nicht wissen, wie Filter und Sortierung konfiguriert werden.
Der Nutzer sagt:
Erstelle für Projektmanager eine Ansicht “Hochriskante Projekte dieser Woche”, sortiert nach erwarteten Verzögerungstagen, und zeige nur Projekte, für die ich verantwortlich bin.
Die Plattform sollte erzeugen:
- Objekt: Projekt;
- Filter: Risikostufe hoch und erwarteter Einfluss auf einen Meilenstein dieser Woche;
- Berechtigung: nur Projekte, die dem aktuellen Nutzer gehoren oder an denen er beteiligt ist;
- Sortierung: erwartete Verzogerungstage absteigend;
- Felder: Projektname, Verantwortlicher, Meilenstein, Risikogrund, nachste Aktion;
- Darstellung: Liste oder Board.
Ein guter Builder sollte Nachfragen erlauben:
Fuge noch die Spalte “letzter Meeting-Beschluss” hinzu.
Dann sollte er die Seite nicht neu bauen, sondern die Metadaten der Ansicht andern.
Änderungstyp 4: Berechtigungen anpassen
Berechtigungen sind der sensibelste Teil dialogischer Änderungen.
Der Nutzer sagt:
Sales-Mitarbeiter sehen nur eigene Kunden, Regionalmanager sehen Kunden ihrer Region, und die Geschaftsleitung sieht alle Kunden.
Das klingt klar, aber die Plattform muss daraus eine sichtbare Berechtigungsmatrix erzeugen:
| Rolle | Datensatzbereich | Feldbereich | Erlaubte Aktionen |
|---|---|---|---|
| Sales | Eigene Kunden | Kosten und sensible Vertragsklauseln ausblenden | Follow-ups anlegen, Aktivitaten aktualisieren |
| Regionalmanager | Kunden der eigenen Region | Zusammengefasste Betrage sichtbar | Verantwortliche zuweisen, Risiken anzeigen |
| Management | Alle Kunden | Zusammenfassungen sichtbar, nicht zwingend editierbar | Berichte ansehen, Export nur mit Genehmigung |
Auch Agent-Abfragen müssen diese Rechte erben. Wenn ein Sales-Mitarbeiter fragt: “Welche Kunden sind hochriskant?”, darf das System nur Kunden zurückgeben, die dieser Nutzer sehen darf.
KI kann bei der Konfiguration helfen, aber sie darf Berechtigungen nicht beilaufig oder leichtfertig wirken lassen.
Änderungstyp 5: Automatisierung und Agent-Aktionen erstellen
Der Nutzer sagt:
Jeden Montagmorgen sollen Customer-Success-Manager eine Zusammenfassung hochriskanter Kunden erhalten, und für die Verantwortlichen sollen Follow-up-Aufgaben erstellt werden.
Die Plattform sollte das zerlegen in:
- Einen geplanten Trigger;
- Eine Abfrage hochriskanter Kunden;
- Gruppierung nach Verantwortlichen;
- Eine interne Zusammenfassung;
- Erstellung von Follow-up-Aufgaben;
- Protokolle der Automatisierungslaufe;
- Benachrichtigung des Administrators bei Fehlern.
Außerdem muss sie das Aktionsrisiko unterscheiden:
- Interne Zusammenfassung: niedriges Risiko;
- Aufgabe erstellen: niedriges bis mittleres Risiko;
- Kundenrisiko andern: mittleres Risiko, Bestatigung erforderlich;
- E-Mail an Kunden senden: hohes Risiko, Genehmigung oder manueller Versand erforderlich.
Der Kern dialogischer Automatisierung ist nicht “mehr automatisch tun”. Der Kern ist, sauber zu trennen, was automatisierbar ist und was bestätigt werden muss.
Vier Produktdetails, die ein guter Conversational Builder braucht
Erstens: den Änderungsplan zeigen. Nutzer sollten sehen, welche Objekte, Felder, Ansichten, Workflows, Berechtigungen und Automatisierungen die Plattform ändern will.
Zweitens: den Wirkungsbereich zeigen. Besonders bei Berechtigungen, Workflows und Automatisierungen muss klar sein, welche Rollen, Daten und laufenden Instanzen betroffen sind.
Drittens: Vorschau und Rollback unterstützen. Vor der Änderung sollte man prüfen können, nach der Änderung sollte eine Rückkehr zur vorherigen Version möglich sein.
Viertens: Audit hinterlassen. Wer hat die Änderung angefragt, wie hat die KI sie begründet, wer hat bestätigt, und was wurde tatsächlich geändert?
Ohne diese vier Details wird “Apps per Dialog andern” zu einer gefahrlichen Blackbox.
Der Wert von ObjectStack
ObjectStack eignet sich für dialogische App-Iteration, weil die Anwendungsstruktur auf der Metadatenebene liegt.
Felder, Ansichten, Workflows, Berechtigungen, Automatisierungen und Agent-Tools sind nicht über Code verstreut. Sie sind Business-Strukturen, die erzeugt, erklärt, verändert, versioniert und auditiert werden können.
Business-Nutzer beschreiben die Änderung in natürlicher Sprache. Die Plattform erzeugt einen Änderungsplan. Ein Administrator oder Business Owner bestätigt ihn. Die Laufzeit arbeitet danach mit den neuen Metadaten, und Agents erben dieselben Objekt-, Rechte- und Aktionsgrenzen.
Das ist der Schlüssel, um Geschäftssysteme per Dialog zu ändern: KI flickt nicht kurzfristig ein Feature. Das System wird dauerhaft durch Business-Sprache formbar und bewahrt trotzdem die Governance, die eine Low-Code-Plattform braucht.