Bauen Sie einen Cycle-Count-Workflow, um Zähl-Batches zu erstellen, Abweichungen zu erfassen, große Deltas an Supervisoren zu leiten und Bestandsanpassungen sauber zu buchen.
Inventar ist oft am ersten Tag korrekt und driftet dann nach und nach. Meist ist es nicht ein großer Fehler, sondern viele kleine, normale Ereignisse, die jedes Mal leicht anders gehandhabt werden.
Kommissionieren ist eine häufige Fehlerquelle. Ein Picker nimmt den richtigen Artikel aus dem falschen Fach, entnimmt zu wenig mit dem Plan, später zurückzukommen, oder scannt ein Etikett, das für eine andere Kiste gedruckt wurde. Rücksendungen verstärken die Drift: Artikel kommen geöffnet oder mit fehlenden Teilen zurück oder werden „vorübergehend“ irgendwo abgelegt und vergessen. Beschädigungen und Schwund tragen ebenfalls dazu bei, besonders wenn Leute kaputte Artikel wegwerfen, ohne das zu erfassen, weil es schneller erscheint.
Falsch etikettierte Artikel sind der stille Killer. Ein schlechtes Etikett kann später Dutzende „mysteriöser Abweichungen" erzeugen.
Cycle Counting ist die kleine, häufige Variante der Bestandsprüfung. Statt einmal oder zweimal pro Jahr alles herunterzufahren für eine vollständige Inventur, zählt man nach einem Zeitplan nur eine begrenzte Menge an Artikeln oder Orten. Ziel ist es, Probleme früh zu finden, solange sie noch leicht zu erklären sind.
„Gute Genauigkeit“ ist keine perfekte Zahl im Report. Es bedeutet, dass die tägliche Arbeit vorhersehbar bleibt: Bestellungen werden ohne Last-Minute-Ersatz versendet, Einkauf bestellt nicht übermäßig „sicherheitshalber“, und der Kundensupport entschuldigt sich nicht für vermeidbare Fehlbestände.
Teams haben meist aus den gleichen Gründen Probleme. Zählungen sind inkonsistent (verschiedene Einheiten, beschädigte Artikel werden übersprungen). Abweichungen haben keinen klaren Besitzer, also „korrigieren“ Leute sie durch Raten. Große Änderungen werden ohne Prüfung gebucht, sodass ein Fehler zu einer echten Anpassung wird. Und Anpassungen werden nicht erklärt (kein Grundcode, keine Notizen, keine Prüfhistorie), sodass sich die gleichen Probleme wiederholen.
Eine Cycle-Count-App wirkt am besten, wenn sie richtige Schritte schwer überspringbar und riskante Schritte unmöglich macht, still zu erledigen.
Ein Cycle-Count-Workflow ist ein wiederholbarer Weg, um einen kleinen Ausschnitt von Inventar zu prüfen, Fehler zu korrigieren und festzuhalten, was passiert ist. Eine gute App macht daraus einen einfachen Pfad, dem Personen ohne Rätsel folgen können.
Die meisten Teams nutzen denselben Kernfluss: einen Count-Batch planen, auf dem Boden zählen, mit dem System vergleichen, Ausnahmen genehmigen und dann Bestandsanpassungen buchen.
Halten Sie Rollen klar:
Zwei Begriffe sind beim Vergleich wichtig: Abweichung (variance) und Delta. Die Abweichung ist die vorzeichenbehaftete Differenz zwischen Systemerwartung und gezähltem Bestand. Delta ist die Größe dieser Differenz.
Beispiel: Das System sagt, Bin A hat 120 Einheiten. Der Zähler findet 95.
Genehmigungsschritte existieren, weil große Unterschiede echte Probleme oder einfache Fehler sein können. Ein Fehlscan, die falsche Mengeneinheit oder das Zählen des falschen Fachs kann ein großes Delta erzeugen. Die Prüfung großer Deltas verhindert, dass eine falsche Anpassung gebucht wird und ein größeres Chaos verursacht als der ursprüngliche Fehler.
Nach der Genehmigung sollte die Anpassung kontrolliert gebucht werden, mit der Information, wer genehmigt hat, wann und warum – alles im Datensatz festgehalten.
Bevor Sie eine Cycle-Count-App bauen, klären Sie, welche Daten der Workflow erfassen muss. Fehlen die Grundlagen, werden Leute vor Ort raten und die Ergebnisse halten einer Prüfung nicht stand.
Beginnen Sie mit den minimalen Stammdaten: Artikel (SKU, Name, Mengeneinheit, aktiv/inaktiv), Standorte (Lager- und Fachstruktur und ob ein Fach zählbar ist) und der aktuelle Soll-Bestand pro Artikel pro Standort. Wenn Sie Lose oder Seriennummern nutzen, brauchen Sie außerdem Los-/Seriennummer, Verfallsdatum und Status.
Als Nächstes definieren Sie, was ein Count-Batch in Ihrem Geschäft bedeutet. Ein Batch ist der Container, der eine Zählung handhabbar und nachverfolgbar macht. Er sollte den Umfang (Standorte oder SKU-Gruppe), geplante Daten, zugewiesene Zähler und ein einfaches Statusmodell wie Draft, In Progress, Submitted, Approved und Posted enthalten.
Auf Zeilenebene (jede Position, die jemand zählt) erfassen Sie gerade genug, um die Rechnung später zu erklären: Artikel, Standort, Systemmenge, gezählte Menge und die Abweichung (Einheiten und, falls hilfreich, Prozent).
Schließen Sie von Anfang an Genehmigungsdaten ein, auch wenn Sie sie zunächst nicht nutzen. Sie brauchen eine Abweichungsschwelle (was als „großes Delta“ zählt), Grundcodes (Beschädigung, Fehlpick, Wareneingangsfehler), eine Supervisor-Entscheidung (approve/reject) und Notizen.
Beispiel: Wenn Bin A3 im System 24 anzeigt, der Zähler aber 10 erfasst, sollte die App einen Grund verlangen und die Zeile zur Prüfung weiterleiten, bevor eine Bestandsanpassung gebucht wird.
Eine Cycle-Count-App funktioniert nur, wenn Batches machbar wirken. Öffnet jemand einen Batch mit 120 Standorten, wird er hetzen, überspringen oder ihn abbrechen. Beginnen Sie mit Batches, die für eine Person in einer Schicht machbar sind, mit Zeit, offensichtliche Probleme zu beheben (fehlende Etiketten, gemischte Produkte, beschädigte Verpackungen).
Wählen Sie aus, was gezählt wird, mit Regeln, die Ihre Schmerzpunkte treffen, nicht was im Report hübsch aussieht. Gängige Ansätze sind ABC-Abdeckung (A-Artikel öfter, C seltener), Fast Movers, wiederkehrende Problem-Bins und ein kleiner Anteil Zufall, um stille Drift zu entdecken.
Halten Sie jeden Batch eng: eine Zone, ein Gangbereich oder ein Cluster benachbarter Fächer. Wenn die Laufzeit hoch ist, ist der Batch zu groß. Ein praktischer Startwert sind 20 bis 40 Standorte pro Batch für manuelle Zählung; passen Sie das an, nachdem Sie gemessen haben, wie lange Ihr Team tatsächlich braucht.
Entscheiden Sie, wie Sie mit Bewegungen während der Zählung umgehen. Die sauberste Option ist, Picks und Putaways für die Fächer eines aktiven Batches zu sperren. Wenn das nicht geht, nutzen Sie eine Zeitstempel-Cutoff: alles nach dem Cutoff ist ausgeschlossen und wird in einer Nachfolgebearbeitung behandelt.
Klare Status verhindern Verwirrung und reduzieren Nacharbeit. Verwenden Sie Namen, die das widerspiegeln, was Leute tun:
Wenn Sie das in AppMaster bauen, können Sie Batches, Standorte und Status im Data Designer modellieren und Regeln im Business Process Editor hinzufügen, sodass die App nach dem Posten keine Bearbeitungen mehr zulässt.
Die schnellsten Zählungen entstehen, wenn der Bildschirm das zeigt, was eine Person gerade mit den Händen macht. Das heißt meist eine einfache Eingabemaske, die in einem lauten Gang mit Handschuhen, Blendung und schlechter WLAN-Verbindung funktioniert.
Beschränken Sie Eingaben auf das, was ein Zähler wirklich überprüfen kann: Artikel, Fach (oder Standort), gezählte Menge und eine optionale Notiz. Wenn Fotos helfen, später Streitfälle zu klären, machen Sie sie optional und per Ein-Klick verfügbar. Alles, was sich wie Papierkram anfühlt, wird übersprungen oder schlimmer, geraten.
Bieten Sie Scanfunktionen an, aber machen Sie sie nicht zwingend. Barcodes sind großartig, wenn Etiketten sauber sind, doch Sie brauchen immer einen manuellen Fallback für zerrissene Etiketten, tote Scanner oder gemischte Verpackungen. Ein solides Muster ist: Artikel scannen (oder suchen), Fach bestätigen, Menge eingeben.
Zeigen Sie die Systemmenge, aber nur lesbar. Zähler sollten die Zahl nicht vor Ort „korrigieren" können. Die erwartete Menge kann ihnen helfen, offensichtliche Fehler zu erkennen, darf aber nicht das physisch Gezählte überschreiben.
Zwei Fälle verwirren und verdienen explizite Behandlung:
In beiden Fällen erfassen Sie trotzdem das Fach und die Zählung (auch wenn sie null ist). So bleibt der Datensatz für die Prüfung und Anpassung nutzbar.
Wenn Sie das in AppMaster bauen, halten Sie den Eingabebildschirm minimal mit einer mobilen UI, nutzen Scanner-Eingaben wenn verfügbar und speichern Fotos und Notizen zu jeder Zählzeile, damit Supervisoren prüfen können, ohne Leute hinterherlaufen zu müssen.
Eine Cycle-Count-App ist nur so vertrauenswürdig wie ihre Abweichungsregeln. Sobald jemand eine fehlerhafte Zählung durch das direkte Bearbeiten einer Zahl „korrigieren“ kann, ist der Prozess keine Kontrolle mehr, sondern eine Empfehlung.
Verwenden Sie auf jeder Zeile einfache Mathematik:
Prozentuale Differenz hilft, große Probleme bei niedrigem Bestand zu erkennen. Einheiten-Differenz zeigt kostspielige Schwankungen bei hochvolumigen Artikeln. Wenn die Systemmenge 0 ist, behandeln Sie das als Sonderfall und leiten die Zeile automatisch zur Prüfung weiter.
Nutzen Sie Schwellen, die zu Ihrem Betrieb passen. Viele Teams kombinieren absolute Einheiten und Prozent, damit weder kleine Artikel noch schnell drehende Artikel durchs Raster fallen.
Beispielsweise:
Halten Sie die Regel leicht erklärbar. Leute akzeptieren Kontrollen, wenn sie sie verstehen.
Fordern Sie als Nächstes bei jeder Abweichung ungleich null einen Grundcode an. Das erzwingt ein kurzes „Warum“, solange der Artikel noch vor dem Zähler liegt, und macht Berichte später nützlich. Typische Grundcodes sind beschädigt/abgelaufen, Fehlpick/fehlende Lieferung, verlagert (Fachwechsel), Wareneingang nicht gebucht und Etikett- oder Mengeneinheit-Probleme.
Schließlich verhindern Sie riskante Änderungen. Sobald ein Zähler einen Batch (oder eine Zeile) zur Prüfung einreicht, sperren Sie sie. Falls wirklich eine Korrektur nötig ist, machen Sie eine beaufsichtigte Nachzählung, die einen neuen Eintrag erzeugt und das Original intakt lässt. Diese eine Regel schützt Ihre Prüfhistorie und verhindert stille Änderungen nachträglich.
Die Prüfung durch den Supervisor sollte Minuten dauern, nicht Stunden. Der Trick ist, dem Entscheider den Kontext auf einem Bildschirm zu zeigen und die Aktionen einfach zu halten.
Supervisoren brauchen selten nur die rohe Zahl. Sie benötigen die jüngere Historie eines Artikels: vorige Cycle Counts, den erwarteten Soll-Bestand und was sich seit der letzten sauberen Zählung geändert hat (Wareneingänge, Picks, Rücksendungen, Transfers). Wenn Ihre App diese Timeline neben der Abweichung zeigen kann, hören Supervisoren auf zu raten.
Praktisch bleiben:
Aktionen sollten dem echten Leben entsprechen: genehmigen, ablehnen, Nachzählung anfordern oder den Batch aufteilen, wenn nur wenige Zeilen fragwürdig sind, damit der Rest weitergehen kann.
Bei großen Deltas verlangen Sie einen Kommentar vor der Genehmigung. Machen Sie die Eingabe konkret (z. B. Schaden gefunden, Fehlpick bestätigt, Wareneingang nicht gebucht, Mengeneinheit-Problem).
Jede Entscheidung sollte automatisch protokollieren: wer entschieden hat, wann, welche Aktion, welche Schwelle die Prüfung ausgelöst hat und den Text des Grundes. In AppMaster erfassen Sie diese Felder als Teil des Genehmigungsschritts, sodass der Datensatz jedes Mal erstellt wird, ohne auf Erinnerung angewiesen zu sein.
Buchen ist der Moment, in dem sich Ihre Zahlen ändern. Es bedeutet, Soll-Bestände zu aktualisieren und eine permanente Aufzeichnung dessen zu speichern, was sich wann und warum geändert hat.
Behalten Sie Genehmigung und Buchen als zwei getrennte Schritte bei. Genehmigung ist eine Entscheidung. Buchen ist ein Schreibvorgang im Inventar. Wenn Sie beides mischen, kann ein Fehlklick oder eine halb fertig gestellte Prüfung den Bestand ändern, bevor jemand es bemerkt.
Eine einfache Regel: nur genehmigte Abweichungen dürfen Anpassungen erzeugen, und nur Anpassungen dürfen den Soll-Bestand aktualisieren.
Erstellen Sie pro Artikel und Standort einen Anpassungseintrag (eine Zeile pro SKU und Fach), selbst wenn Sie einen ganzen Batch auf einmal buchen. Jede Zeile sollte dieselben Verweise tragen, damit Sie später prüfen können: Count-Batch-ID, Artikel, Standort/Fach, Systemmenge, gezählte Menge, Delta, Grundcode, genehmigt von, genehmigt am und wer gebucht hat.
Bevor Sie einem Benutzer das Buchen erlauben, fügen Sie ein paar Sicherheitsprüfungen ein:
Das Buchen sollte auf dem Bildschirm explizit sein. Zeigen Sie eine Zusammenfassung, wie viele Zeilen sich ändern werden und das gesamte Delta, damit der Benutzer genau weiß, was passieren wird.
Planen Sie Integrationen frühzeitig, auch wenn Sie sie nicht sofort bauen. Wenn Ihr ERP oder WMS die Quelle der Wahrheit ist, behandeln Sie das Buchen als „exportiere genehmigte Anpassungen" und lassen Sie das andere System sie anwenden. In AppMaster können Sie Anpassungen als Tabelle modellieren und später einen Export nach CSV oder einen API-Aufruf hinzufügen, ohne den Zähl-Workflow zu ändern.
Ein Picker startet eine Zählung für Bin A-14 (Artikel: 10mm Schrauben). Das System zeigt erwartete 50 Einheiten basierend auf dem letzten Wareneingang und jüngsten Picks. Vor Ort zählt der Picker 43.
Die Lücke von 7 Einheiten kann einfache Ursachen haben: eine Kiste wurde während eines Rushes in ein benachbartes Fach geräumt, ein Pick wurde durchgeführt, aber nicht bestätigt, eine Rücksendung wurde ohne Buchung zurückgelegt oder das Fachetikett ist so abgenutzt, dass jemand falsch eingeräumt hat.
In der App tippt der Picker auf Submit Count. Die App berechnet das Delta (-7 bzw. -14 %). Da die Lagerregel sagt, dass alles über 10 % genehmigt werden muss, erlaubt sie noch keine Anpassung zu buchen. Stattdessen wird die Zählung in den Status Needs Review geleitet und eine kurze Nachzählung angefordert.
Bei der Nachzählung findet der Picker eine kleine ungeöffnete Karton hinter einem größeren und aktualisiert die Nachzählung auf 45. Die Abweichung ist jetzt -5 (noch -10 %). Die App hält die Zeile weiter in Prüfung und fordert eine kurze Notiz wie „Versteckte Karton gefunden, Nachzählung durchgeführt“.
Der Supervisor öffnet die Review-Queue und sieht die ursprüngliche Zählung, die Nachzählung, Zeitstempel und wer gezählt hat. Sie wählen eine Aktion:
Nach Genehmigung bucht die App eine Bestandsanpassung von 50 auf 45 mit vollständiger Prüfhistorie. Das Team dokumentiert außerdem die Erkenntnis: Fach umräumen, damit Kartons nicht versteckt werden, und Erinnerung, Picks vor Verlassen des Gangs zu bestätigen.
Die meisten Probleme beim Cycle Counting entstehen nicht durch mangelnden Einsatz, sondern durch kleine Lücken im Workflow, die Ihre Zahlen still und leise zur Schätzung werden lassen.
Einer der größten Fehler ist, Leuten zu erlauben, die Systemmenge zu überschreiben. Das wirkt schnell, zerstört aber die Prüfhistorie. Eine Zählung sollte eine Abweichung erzeugen und dann eine geprüfte Bestandsanpassung, damit Sie immer sehen können, was sich wann und warum geändert hat.
Ein weiterer häufiger Fehler ist, ein sich bewegendes Ziel zu zählen. Wenn während der Zählung weiter gepickt, geliefert oder umgelagert wird, ist Ihre Abweichung bedeutungslos. Selbst ein einfacher Cutoff hilft, z. B. Bewegungen für einen Standort pausieren solange ein Batch läuft oder Nachzählung verlangen, wenn eine Bewegung während des Zählfensters stattfand.
Die Batch-Größe ist wichtiger, als viele Teams erwarten. Zu große Batches laufen über Schichten, Leute verlieren den Kontext und der Batch schließt nie. Kleinere Batches erzeugen einen schnelleren Rhythmus und sauberere Daten.
Einige wiederkehrende Fehlerbilder: fehlende Grundcodes für Abweichungen, Genehmigungen per Chat ohne Aufzeichnung, unklare Einheiten (Stück vs. Karton), Korrekturen einzeln statt über einen konsistenten Batch-Workflow und erlaubte „schnelle Änderungen“, die das Buchen von Anpassungen umgehen.
Ein kurzes Beispiel: Ein Zähler findet 12 Einheiten in einem Fach, das System sagt 20. Ohne Grundcode wissen Sie später nicht, ob es Diebstahl, Beschädigung, Pickfehler oder Wareneingangsmissmatch war. Wenn die Genehmigung in einer Nachricht erfolgt, können Sie auch nicht nachweisen, wer das Risiko akzeptiert hat.
Eine gute Cycle-Count-App verhindert diese Fehler durch Design: Systemmengen sperren, Grundcodes verlangen und eine Genehmigungsstufe, die protokolliert wird, bevor irgendeine Bestandsanpassung gebucht wird.
Vor der ersten echten Zählung machen Sie einen Trockenlauf mit einem Gang oder einem kleinen Lagerraum. Sie testen nicht die Leute, sondern den Prozess.
Stellen Sie sicher:
Wenn Sie das in AppMaster bauen, legen Sie diese Regeln einfach in Ihrem Business Process fest: Scope validieren, Schwellen erzwingen, Genehmigung verlangen, dann buchen und sperren.
Starten Sie klein, damit Sie schnell lernen. Wählen Sie eine Lagerzone, eine Produktfamilie und eine kurze Liste von Grundcodes (Beschädigung, Fehlpick, Schwund, Wareneingang nicht gebucht). Ein enger Pilot macht es leichter zu sehen, wo der Workflow verwirrend ist, wo Zählungen zu lange dauern und welche Abweichungsregeln zu häufig auslösen.
Führen Sie den Pilot eine Woche lang durch und straffen Sie den Workflow basierend auf dem, was tatsächlich auf dem Boden passiert ist. Halten Sie das Ziel einfach: Batches rechtzeitig abschließen und Abweichungen leicht erklärbar und genehmigbar machen.
Ein praktischer Plan für die erste Woche:
Wenn die Grundlagen funktionieren, wählen Sie die nächsten Automatisierungen. Die meisten Teams erzielen schnelle Verbesserungen mit ein paar Ergänzungen: Benachrichtigungen, wenn ein Batch zugewiesen oder überfällig ist, automatisches Routing an Nachzählung bei Überschreiten von Schwellen und ein täglicher Report mit Abschlussraten, wiederkehrenden Abweichungs-SKUs und ausstehenden Genehmigungen.
Wenn Sie eine Cycle-Count-App ohne viel Programmierung bauen möchten, ist AppMaster (appmaster.io) eine Option: Sie können Ihre Bestandsdaten modellieren, Genehmigungsschritte für Abweichungen einrichten und denselben Workflow als Web- und Mobile-App erzeugen.
Was ist Cycle Counting und wie unterscheidet es sich von einer vollständigen physischen Inventur?Cycle Counting überprüft regelmäßig nur eine kleine Menge an Artikeln oder Lagerplätzen statt einer einmaligen vollständigen Inventur. Der Hauptvorteil ist, dass Abweichungen früh entdeckt werden, solange die Ursachen noch frisch und einfach zu klären sind.
Wie groß sollte ein Cycle-Count-Batch sein, damit Personen ihn tatsächlich fertigstellen?Beginnen Sie mit einer Größe, die eine einzelne Person in einer Schicht ohne Hast abschließen kann. Für viele Lager sind 20–40 Standorte pro Batch ein praktikabler Ausgangswert; passen Sie die Größe dann anhand der tatsächlichen Zeiten und Laufwege an.
Sollten wir Bestandsbewegungen einfrieren, während ein Cycle Count läuft?Sperren Sie Picks und Putaways für die Bins eines aktiven Batches, wann immer möglich, denn so bleibt die Zählung kein sich bewegendes Ziel. Wenn das nicht möglich ist, verwenden Sie eine klare Cutoff-Zeit und verlangen Sie eine Nachzählung, falls während des Zählfensters Transaktionen stattgefunden haben.
Brauchen wir Barcode-Scanning oder reicht manuelle Eingabe?Nutzen Sie Scanning, wenn Etiketten zuverlässig sind, aber behalten Sie immer eine manuelle Alternative für zerrissene Etiketten, gemischte Verpackungen oder ausgefallene Scanner. Ein einfacher sinnvoller Ablauf ist: Artikel identifizieren, Bin bestätigen, Menge eingeben und dann absenden.
Sollen Zähler die Systemmenge während der Zählung sehen?Zeigen Sie die Systemmenge an, aber als schreibgeschützt, damit Zähler Zahlen nicht sofort ändern können. Eine Zählung sollte eine Abweichung erzeugen; nur eine genehmigte Anpassung darf den Soll-Bestand ändern.
Wie legen wir eine sinnvolle Schwelle für „große Abweichungen“ fest?Starten Sie mit einer kombinierten Regel, die sowohl große Stückzahlen als auch prozentuale Abweichungen erfasst, z. B. „10+ Einheiten oder 5 %“, und passen Sie sie an die Lautstärke Ihres Bestands an. Jede Zählung mit Systemmenge 0 sollte automatisch überprüft werden, da sie oft auf Fehlplatzierung oder fehlende Buchungen hinweist.
Welche Grundcodes sollten wir verlangen, wenn es eine Abweichung gibt?Verwenden Sie eine kurze Liste, die reale Ursachen abdeckt: beschädigt/abgelaufen, Fehlkommissionierung/fehlende Lieferung, Wareneingang nicht gebucht, Umlagerung und Etikett- oder Mengeneinheit-Problem. Einheitliche Codes machen Berichte aussagekräftig statt voller Einzelausreden.
Was sollte ein Supervisor während der Abweichungsprüfung tun?Lassen Sie Supervisoren genehmigen, zurückweisen oder eine Nachzählung anfordern, und verlangen Sie bei großen Abweichungen eine kurze Notiz, damit die Entscheidung später erklärbar ist. Der Prüfbildschirm sollte genug Kontext bieten, z. B. letzte Zählungen und jüngste Bewegungen für diesen Artikel und Ort.
Wie buchen wir Bestandsanpassungen sicher, ohne neue Fehler zu schaffen?Trennen Sie Genehmigung und Buchen: nur genehmigte Zeilen dürfen gebucht werden. Das Buchen sollte einen dauerhaften Anpassungseintrag erstellen (wer gezählt hat, wer genehmigt hat, was sich geändert hat und warum) und Doppelbuchungen durch ein Flag und Zeitstempel verhindern.
Kann man das als einfache No-Code-App bauen und trotzdem Prüfspuren behalten?Ja. Wenn die App den Workflow erzwingt – z. B. durch Sperren eingereichter Zählungen, Verlangen von Grundcodes und automatische Aufzeichnung von Genehmigungen – bleibt sie prüfbar. In AppMaster können Sie Batches und Zählzeilen modellieren, Genehmigungsregeln in einem Business Process anlegen und Web- sowie Mobile-Apps aus demselben Workflow erzeugen.
21. Jan. 2026
8 Min
20. Jan. 20268 Min
20. Jan. 20268 MinExperimentieren Sie mit AppMaster mit kostenlosem Plan.
Wenn Sie fertig sind, können Sie das richtige Abonnement auswählen.
