Ein Formular für Urlaubsanträge, eine Freigabe für Bestellungen, eine Liste, die sich aus dem Postfach füllt: Solche Dinge lassen sich heute ohne Programmierer entwickeln. Werkzeuge wie Microsoft Power Apps und Power Automate, Zapier, Make, Airtable oder Ninox versprechen genau das - Anwendungen zusammenklicken statt schreiben. Das Wort dafür ist Low-Code: wenig Programmcode, viel Oberfläche.

Die Frage kommt in fast jedem Erstgespräch: „Können wir das nicht selbst mit Power Apps machen?“ Oft lautet die Antwort ja. Manchmal lautet sie: ja, aber nicht lange. Dieser Beitrag hilft, die beiden Antworten auseinanderzuhalten.

Was Low-Code bedeutet

Low-Code-Werkzeuge stellen fertige Bausteine bereit: Formulare, Tabellen, Freigabeschritte, Verbindungen zu Diensten wie Microsoft 365, SharePoint, Shopify oder einem Postfach. Sie ordnen die Bausteine in einer Oberfläche an und legen fest, was wann passiert. Programmiert wird wenig oder gar nicht. Grob gibt es zwei Arten:

  • Anwendungsbaukästen wie Power Apps, Airtable oder Ninox. Daraus entstehen Oberflächen mit Tabellen und Formularen, in denen Mitarbeiter Daten erfassen und ansehen.
  • Ablaufwerkzeuge wie Power Automate, Zapier oder Make. Sie verbinden Dienste miteinander: Kommt eine E-Mail mit Anhang, lege ihn in SharePoint ab und trage eine Zeile in die Liste ein.

Wofür Baukästen gut sind

Beispiele aus dem Betrieb, die mit einem Baukasten gut laufen:

  • Der Außendienst erfasst Besuchsberichte in einem Formular am Handy, statt sie abends in eine E-Mail zu tippen.
  • Bestellungen über einem bestimmten Betrag laufen durch eine Freigabe: Antrag, Prüfung durch die Leitung, Rückmeldung an den Antragsteller.
  • Eine Liste offener Reklamationen, die mehrere Kollegen gleichzeitig pflegen, ohne Excel-Dateien hin- und herzuschicken.
  • Neue Bestellungen aus dem Onlineshop landen automatisch im Buchhaltungsprogramm, ohne dass jemand sie abtippt.

Gemeinsam ist diesen Beispielen: wenige Nutzer, ein klarer Ablauf, Daten, die bisher in einer Excel-Liste oder gar nicht lagen, und Dienste, die ohnehin in der Cloud laufen. Für die Excel-Liste, die zu groß geworden ist, ist ein Baukasten oft der passende nächste Schritt.

Wo Baukästen enden

Die Grenze zeigt sich selten am Anfang. Sie zeigt sich, wenn die Anwendung erfolgreich ist und wächst.

Viele Nutzer

Was für eine Handvoll Kollegen gut läuft, wird mit der ganzen Belegschaft zäh. Listen werden lang, Ansichten langsam, und jede Anpassung berührt alle zugleich. Dazu kommt das Lizenzmodell: Viele Anbieter rechnen pro Nutzer ab. Wer die ganze Belegschaft anschließt, zahlt für jeden Einzelnen.

Rechte, die von Kunde und Abteilung abhängen

Wer darf was sehen? Der Vertrieb die Verkaufspreise, aber nicht die Einkaufskonditionen; der Standort Nord seine Aufträge, nicht die vom Standort Süd; der Monteur nur seine eigenen Einsätze. Baukästen kennen Rechte, aber meist grob: bearbeiten oder lesen, Tabelle ja oder nein. Sobald Rechte von Kunde, Abteilung und Status zugleich abhängen, wird es zur Bastelei - oder es entstehen Kopien der Anwendung, eine je Abteilung.

Anbindung an das eigene ERP

Zu Cloud-Diensten gibt es fertige Verbindungen. Zum ERP im eigenen Haus, zur Warenwirtschaft oder zur alten Access-Datenbank meist nicht. Dann braucht es einen Zwischenschritt, der Daten holt und zurückschreibt - und der ist oft mehr Programmierung als der Rest der Anwendung. Ob eine Verbindung möglich ist, hängt vom System ab; sie lässt sich nach Möglichkeit herstellen, aber nicht vorab versprechen.

Abhängigkeit vom Anbieter

Die Anwendung läuft nur in diesem Baukasten. Ändert der Anbieter Funktionen oder Lizenzmodell, ändern sich Ihre Möglichkeiten und Kosten mit. Umziehen lässt sich eine Power App nicht.

Pflege durch eine Person

Meist hat ein Kollege die Anwendung entwickelt, der den Ablauf gut kennt. Er ist dann der Einzige, der sie versteht. Wechselt er die Abteilung oder das Unternehmen, steht die Anwendung ohne Betreuer da. Das ist kein Vorwurf an den Kollegen: Der Betrieb hat ihm die Aufgabe überlassen, weil sonst niemand da war.

Baukasten oder mit KI entwickelt?

Neben den Baukästen gibt es inzwischen einen zweiten Weg: Werkzeuge wie Lovable oder Cursor schreiben auf Anweisung echten Programmcode. Das Ergebnis sieht aus wie individuelle Software und ist es der Form nach auch. Der Unterschied zum Baukasten: Der Code liegt bei Ihnen und läuft überall, aber der Rahmen fehlt, den der Baukasten mitbringt - Anmeldung, Rechte, Backups, Betrieb. Was da typischerweise fehlt, steht in Mit KI selbst entwickelt. Beide Wege haben ihren Platz; keiner ersetzt den anderen.

Woran Sie merken, dass Sie über den Baukasten hinaus sind

  • Die Anwendung hat mehr Ausnahmen als Regeln, und jede neue Anforderung braucht länger als die letzte.
  • Rechte werden über getrennte Kopien der Anwendung gelöst.
  • Daten aus dem ERP werden von Hand in den Baukasten übertragen - oder zurück.
  • Der Ablauf hängt an einem Kollegen, und niemand sonst traut sich an die Anwendung.
  • Die Lizenzrechnung wächst mit jedem Nutzer, obwohl die Anwendung dieselbe bleibt.
  • Aus dem kleinen Hilfsmittel ist das eigentliche Arbeitswerkzeug einer Abteilung geworden - und dafür war es nie gedacht.

Wie Sie vorgehen

  1. Fangen Sie mit dem Baukasten an, wenn der Ablauf klein und die Nutzer wenige sind.
  2. Schreiben Sie auf, was die Anwendung tut, wo ihre Daten liegen und wer sie pflegt - eine Seite reicht.
  3. Gehen Sie die Liste oben regelmäßig durch, am besten zusammen mit dem Kollegen, der die Anwendung entwickelt hat.
  4. Ist die Grenze erreicht, nehmen Sie den Baukasten als Vorlage. Er zeigt genau, welche Felder, Schritte und Freigaben der Ablauf braucht - der beste Ausgangspunkt für individuelle Software, die Rechte, Anbindung und viele Nutzer von Anfang an vorsieht.

Bei uns ist dieser Übergang der übliche Weg: Anmeldung, Rechte, Arbeitsbereiche und Zusammenarbeit bringt ElbDesk mit, die Grundlage, auf der wir bauen - entwickelt wird nur noch Ihr Ablauf. Haben Sie ein ERP, bleibt es - Buchhaltung und Lager bleiben aus.