Formilo erstellt Formulare – rund 90% unseres Geschäfts. Die übrigen 10% sind Zusatzleistungen, die entstehen, weil Formulare in der Praxis selten isoliert stehen.
Wenn wir Zusatzleistungen rund um Formulare anbieten, geht es nicht um ein beliebiges Portfolio, sondern um typische Ergänzungen, die aus realen Anforderungen entstehen. Ein Formular löst die Datenerfassung – doch in vielen Organisationen ist der Nutzen erst dann voll da, wenn die Daten korrekt verarbeitet, weitergeleitet, geprüft, angereichert oder in bestehende Systeme integriert werden. Genau an diesen Punkten kommt es sonst zu Medienbrüchen, manuellen Zwischenschritten oder Schatten-IT.
Kunden starten mit einem Formularwunsch, benötigen aber zusätzlich Logik, Rollen oder Prozessschritte, damit das Ergebnis im Alltag funktioniert.
Sobald z. B. Login, Benutzerverwaltung, persistente Datenmodelle oder komplexe Zustandslogik erforderlich sind, sprechen wir transparent über „Software“ statt das Ganze künstlich „Formular“ zu nennen.
Datenerfassung ist selten das Endziel. Häufig müssen Daten in CRM, ERP, DMS, Ticketsysteme oder Data-Warehouses übertragen oder daraus vorbefüllt werden.
Neben Formular-Integrationen entstehen Aufträge, auch Fremdsysteme miteinander zu verbinden, weil die gleichen Datenflüsse und Qualitätsanforderungen gelten.
Manche Kunden unterschätzen anfangs den Hebel, wenn man den Prozess um das Formular herum mitdenkt. In der Beratung zeigen wir Optionen und Konsequenzen, ohne unnötig zu vergrößern.
Wenn der Bedarf durch etablierte Standardsoftware besser abgedeckt wird, empfehlen wir das offen – auch wenn wir dadurch weniger Entwicklungsumfang verkaufen.
Wichtig ist: Diese Zusatzleistungen verändern nicht den Schwerpunkt. Sie entstehen fast immer direkt aus Formularprojekten oder aus dem Umfeld, in dem Formulare erst ihren Wert entfalten. Deshalb bleibt unsere Positionierung klar: Formilo ist ein Formularunternehmen. Alles Weitere ist entweder eine Erweiterung eines Formulars oder eine begleitende Lösung, die den Formularprozess erst praxistauglich macht.
Für Kunden hat das einen konkreten Vorteil: Sie bekommen nicht nur „ein schönes Formular“, sondern eine belastbare Lösung, die in ihrem Alltag funktioniert – mit sauberer Abgrenzung, transparenter Beratung und einem Fokus darauf, dass Formulare weiterhin das Zentrum bleiben.
Viele Anfragen starten mit der Formulierung „Wir brauchen ein Formular“. In der Praxis steckt dahinter oft ein kompletter Prozess: Daten sollen nicht nur eingegeben, sondern gespeichert, geprüft, verändert, freigegeben, ausgewertet oder mit Berechtigungen gesteuert werden. Ab einem bestimmten Punkt ist das Ergebnis nicht mehr sinnvoll als „Formular“ zu beschreiben, sondern als kleine Anwendung oder individuelle Softwarelösung.
Für Formilo ist diese Abgrenzung wichtig, weil sie Erwartungsmanagement schafft: Ein Formularprojekt folgt anderen Prinzipien als eine Anwendung mit Nutzerkonten, Rollen, Zuständen und Datenmodellen. Wir sprechen das früh an, damit Aufwand, Risiken und Nutzen realistisch geplant werden können – ohne Marketingbegriffe, sondern anhand klarer Kriterien.
Die Konsequenz ist pragmatisch: Solange das Ziel primär Datenerfassung ist, bleibt es ein Formularprojekt – selbst wenn es anspruchsvoll ist. Wenn jedoch die Anwendung selbst zum Produkt wird (z. B. Nutzerverwaltung, Workflows, Datenhaltung und Auswertungen als Kern), wechseln wir transparent in den Modus der individuellen Softwareentwicklung. So bleibt die Lösung sauber definiert und die Umsetzung passend zum tatsächlichen Bedarf.
mit Passwort-Reset, Sessions und Zugriffsschutz
mit Rollen, Rechten und Mandantenfähigkeit
mit Status, Freigaben und Eskalationen
mit Historie, Versionierung und Audit-Trail
mit Abhängigkeiten, Berechnungen und Regeln über mehrere Datensätze
Erfassung, Prüfung, Bearbeitung, Administration, Reporting
mit Berechtigungen, Ablagekonzept und Nachweispflichten
(z. B. E-Mail, Queue, Reminder, SLA)
statt Einzel-Submit
(bidirektional, synchron/asynchron, Fehlerbehandlung)
die Architekturentscheidungen erzwingen (Last, Datenvolumen, Performance)
Wenn ein Formular nicht mehr nur Daten erfasst, sondern ein Prozess- oder Arbeitswerkzeug wird, ist individuelle Softwareentwicklung oft der sauberere Rahmen. Das heißt nicht, dass wir „vom Formular weg“ gehen. Im Gegenteil: In vielen Fällen bleibt das Formular der zentrale Einstiegspunkt, nur wächst darum herum eine Anwendungsschicht, die den tatsächlichen Arbeitsablauf abbildet. Entscheidend ist, dass wir das Konstrukt fachlich korrekt benennen und so planen, dass es stabil, wartbar und sicher betrieben werden kann.
Wir orientieren uns nicht am Wort „Formular“, sondern daran, was im Alltag passieren muss: wer erfasst, wer prüft, wer entscheidet, wer nacharbeitet.
Sobald Zustände, Rollen, Datenmodelle und Logik zusammenkommen, braucht es eine Struktur, die spätere Änderungen nicht teuer macht.
Das Frontend kann weiterhin „formularartig“ wirken, während Backend, Datenhaltung und Prozesslogik die eigentliche Leistung tragen.
Individuelle Lösungen müssen über Jahre anpassbar bleiben. Das gelingt nur mit klaren Verantwortlichkeiten, Testbarkeit und nachvollziehbarer Logik.
Sobald personenbezogene oder geschäftskritische Daten im Spiel sind, reichen einfache Formularmechanismen oft nicht mehr aus.
Wir entwickeln individuell, wenn es echte Differenzierung oder notwendige Spezifik gibt. Wenn Standard besser passt, sagen wir das offen.
Für Kunden ist der Nutzen konkret:
Sie starten häufig mit einem Formularbedarf, erhalten aber eine Lösung, die den gesamten Ablauf zuverlässig trägt. Gleichzeitig bleibt unsere Spezialisierung sichtbar: Das Zentrum ist fast immer Datenerfassung und Prozessstart über ein Formular – nur eben in einer Form, die dem tatsächlichen Bedarf entspricht.
Formulare erzeugen Daten. In der Praxis entsteht der Wert aber erst, wenn diese Daten dort ankommen, wo gearbeitet wird: in CRM-, ERP-, DMS-, Ticket- oder Fachsystemen. Deshalb gehören Schnittstellen und Integrationen zu den häufigsten Zusatzleistungen rund um Formulare. Dabei geht es nicht nur um „Daten exportieren“, sondern um stabile Datenflüsse mit klaren Verantwortlichkeiten, Fehlerbehandlung und nachvollziehbaren Ergebnissen.
Viele Kunden wollen außerdem Daten aus bestehenden Systemen in das Formular zurückspielen: zur Vorbefüllung, zur Plausibilisierung oder um Doppelerfassungen zu vermeiden. Spätestens dann wird Integration zum Kernbestandteil des Projekts – auch wenn das eigentliche Frontend weiterhin ein Formular bleibt.
Unser Anspruch ist dabei pragmatisch: Eine Integration muss im Betrieb zuverlässig funktionieren, auch wenn Systeme zeitweise nicht erreichbar sind oder Daten nicht wie erwartet ankommen. Genau deshalb ist Schnittstellenarbeit mehr als ein technischer „Connector“ – sie ist ein Bestandteil der Gesamtlösung rund um das Formular.
inklusive Dublettenprüfung und Zuständigkeiten
aus Formularen im Helpdesk/Ticketsystem
mit Rückgabe einer Vorgangsnummer
aus Kundendaten, Stammdaten oder Vertragsdaten aus Drittsystemen
und Ablage im DMS/Archiv mit Metadaten
Formular startet Workflow, Status fließt zurück ins Formular oder Dashboard
Verfügbarkeit prüfen, Buchung auslösen, Bestätigung automatisiert versenden
E-Mail/Teams/Slack-Events basierend auf Regeln, Empfängergruppen und Zuständigkeiten
Adressvalidierung, Produktkataloge, Kostenstellen, Standortlisten
Übergabe strukturierter Daten an Data-Warehouse, ETL oder Analytics-Tools
Übergabe an Storage/DMS, optional mit Virenprüfung und Berechtigungslogik
Bearbeitungsstand, Ablehnung, Nachforderung, Abschlussinformationen
Wenn wir Formulare integrieren, entsteht zwangsläufig ein Überblick über die Datenflüsse eines Unternehmens: Welche Daten gibt es wo, in welcher Qualität, mit welchen Zuständigkeiten und welchem Ziel. Genau deshalb fragen Kunden häufig nach, ob wir nicht auch Schnittstellen zwischen Systemen entwickeln können, die gar nicht von Formilo stammen. Aus Kundensicht ist das logisch: Wer ohnehin ein Datenmodell, Feldlogiken und Zielprozesse gemeinsam sauber definiert, kann die angrenzenden Integrationen oft effizienter und konsistenter umsetzen.
Wenn Felddefinitionen, Validierungen und Zuständigkeiten bereits geklärt sind, lassen sich weitere Datenflüsse konsistent anschließen, ohne widersprüchliche Regeln in mehreren Komponenten zu bauen.
In vielen IT-Landschaften liegen Probleme nicht im einzelnen System, sondern an den Übergängen: unterschiedliche IDs, Datenformate, Pflichtfelder, Statusmodelle und Timing.
Kunden möchten nicht drei Anbieter koordinieren, die sich bei Fehlern gegenseitig die Zuständigkeit zuschieben. Eine Schnittstelle braucht einen verantwortlichen Umsetzungs- und Diagnosepunkt.
Eine Integration muss auch funktionieren, wenn ein System kurzzeitig nicht erreichbar ist oder Daten nicht dem erwarteten Format entsprechen. Dafür braucht es Wiederholstrategien und nachvollziehbare Fehlermeldungen.
Oft wird zuerst das Formular sauber gemacht. Danach folgt die Integration weiterer Systeme. Schnittstellenentwicklung ermöglicht diese Etappen, ohne die Architektur jedes Mal neu zu erfinden.
Wenn ähnliche Muster mehrfach vorkommen (Mapping, Validierung, Authentifizierung, Logging), ist eine zentrale Umsetzung wirtschaftlicher als viele Einzellösungen.
Auch hier gilt: Das ist keine Abkehr von Formularen. Es ist die konsequente Fortsetzung des gleichen Ziels: Datenerfassung und Prozessanstoß so umzusetzen, dass die Daten im Unternehmen wirklich nutzbar werden. Schnittstellen zwischen Fremdsystemen sind für viele Kunden der logische nächste Schritt, wenn die Formularbasis steht.
Eine Integration ist nur so gut wie ihre Datenqualität und ihr Verhalten im Fehlerfall. „Daten übertragen“ klingt simpel, scheitert aber in der Praxis oft an widersprüchlichen Felddefinitionen, fehlenden Pflichtwerten, unklaren Zuständigkeiten oder stillen Ausfällen, die erst Wochen später auffallen. Deshalb behandeln wir Datenflüsse rund um Formulare als eigene, saubere Disziplin: mit klaren Regeln, definierten Übergabepunkten und nachvollziehbarem Betrieb.
Ziel ist nicht maximale Komplexität, sondern verlässliche Routine: Wenn ein Formular Daten erzeugt, muss klar sein, wie diese Daten in Zielsysteme gelangen, wie sie dort interpretiert werden und was passiert, wenn etwas schiefgeht. Genau diese Robustheit unterscheidet „eine Anbindung“ von einer Integration, die im Tagesgeschäft Bestand hat.
(Semantik statt nur „gleiches Label“)
(z. B. Datumsformate, Nummern, Länder-/Regionscodes)
abgestimmt auf Zielsysteme
gegen Stammdaten und gültige Wertelisten
(kein mehrfaches Anlegen bei Wiederholung)
(validierungsbedingt vs. systembedingt vs. berechtigungsbedingt)
statt „still scheitern“
(was wurde wann wohin übertragen)
IDs/Status aus Zielsystemen zurück an Prozess oder UI
Damit das zuverlässig funktioniert, braucht es klare Schnittstellenspezifikation und saubere Verantwortlichkeiten: Wer pflegt Wertelisten, wer entscheidet bei Validierungsfehlern, wer bekommt welche Fehlermeldung, und wie wird ein Problem reproduzierbar diagnostiziert. Wenn diese Punkte geklärt sind, sind Integrationen keine „Sonderfälle“ mehr, sondern ein stabiler Bestandteil des Formularprozesses.
gleiche Bezeichnungen, aber unterschiedliche Bedeutung in Quell- und Zielsystem
(führt zu Abbrüchen oder Nacharbeit)
Wiederholungen erzeugen doppelte Datensätze
fehlendes Logging, keine Alerts, Fehler werden erst spät über Fachabteilungen entdeckt
unklar, wer wie entscheidet, wenn Validierungen scheitern oder Daten fehlen
synchroner Zwang führt zu Timeouts und instabilem Betrieb
Änderungen brechen unerwartet abhängige Systeme
Wertelisten, Mappingregeln und Empfängerlogik sind nicht wartbar
Token-Handling, Rechte und Zugriffe sind nicht durchdacht
fehlende Plausibilisierung, Referenzprüfungen und Normalisierung
keine reproduzierbaren Testdaten, keine Abnahmekriterien, keine Regressionstests
Betrieb, Monitoring und Wartung sind nicht eingeplant
Nicht jede Anforderung ist ein Fall für ein individuelles Formular oder eine individuelle Software. Manchmal beschreibt die Anforderungsliste eines Kunden sehr eindeutig ein Produkt, das am Markt bereits etabliert ist und genau diese Aufgabe als Standard abdeckt. In diesen Fällen ist die wirtschaftlich und organisatorisch beste Lösung häufig: Standardsoftware einsetzen und nur dort individuell ergänzen, wo der Prozess wirklich spezifisch ist.
Wenn der Bedarf typische Standardfunktionen beschreibt (z. B. CRM, Ticketsystem, DMS, Terminbuchung, E-Signatur, Umfrage-Tool), ist „bauen“ oft unnötig.
Wenn ein Prozess schnell stabil laufen muss, ist ein fertiges System häufig schneller produktiv als Individualentwicklung.
Individuelle Lösungen brauchen Pflege, Updates, Monitoring und Weiterentwicklung. Standardsoftware bringt diese Routinen meist als Produktleistung mit.
Wir empfehlen Individualentwicklung vor allem dort, wo Standardsoftware den Kernprozess nicht sauber abbildet oder wo echte Spezifik Wettbewerbsvorteile schafft.
Auch bei Standardsoftware sind Formulare oft sinnvoll: als schlanke Erfassungsoberfläche, als Vorstufe, als geführter Prozessstart oder als Kanal für externe Beteiligte.
Wenn eine fertige Lösung objektiv besser passt, sagen wir das offen, auch wenn weniger Entwicklungsvolumen entsteht.
Das Ergebnis ist für Kunden kalkulierbarer: Sie investieren dort individuell, wo es wirklich notwendig ist, und nutzen Standard dort, wo er stark ist. Formilo bleibt dabei der Partner für Formulare und formularnahe Prozesse – inklusive ehrlicher Einordnung, ob „bauen“ überhaupt sinnvoll ist.
Viele Projekte starten mit einer klaren Formulierung: „Wir brauchen ein Formular für Zweck X.“ Im Gespräch zeigt sich dann oft, dass das Formular nur ein Teil eines größeren Ablaufs ist. Beratung bedeutet hier nicht, Anforderungen künstlich aufzublähen, sondern den tatsächlichen Prozess zu klären: Was passiert vor dem Formular, was passiert danach, und welche Risiken entstehen, wenn man nur den Eingabeschritt digitalisiert.
In manchen Fällen bleibt es bewusst beim schlanken Formular – weil das den größten Nutzen bei geringstem Aufwand bringt. In anderen Fällen ist der Hebel deutlich größer, wenn man ein Stück weiter denkt: z. B. mit Rollen, Freigaben, Datenanreicherung oder Integration in bestehende Systeme. Genau diese Abwägung ist der Mehrwert: Optionen transparent machen, Konsequenzen benennen und eine Lösung bauen, die im Alltag funktioniert.
Ziel, Beteiligte, Verantwortlichkeiten, Ergebnisdefinition
Formular vs. Workflow vs. Anwendung (kein Begriffsnebel)
Welche Daten fehlen, welche sind vorhanden, welche sind „Single Source of Truth“
Minimal nutzbar vs. sinnvoll erweitert (Value vs. Aufwand)
Fehlerfälle, Nacharbeit, Compliance-Anforderungen, Betrieb
Welche Systeme müssen angebunden werden, welche nicht
So entsteht häufig aus einem Formularwunsch eine bessere Lösung, ohne die Positionierung zu verwässern: Das Formular bleibt Startpunkt und Kern, ergänzt um genau die Bausteine, die den Prozess komplett und belastbar machen.
