Excel durch eine Web-App zu ersetzen lohnt sich, wenn die Daten am gemeinsamen Arbeiten scheitern: Freitextfelder, die unbemerkt Geschäftsregeln tragen, Dubletten, die niemand zusammenführen kann, und Statusspalten mit zwei Bedeutungen. Unterhalb dieser Schwelle ist das Behalten des Sheets die günstigere Entscheidung.
webvise baut interne Tools als Kerngeschäft und hat trotzdem schon ganz bewusst Excel als Ausgabeformat ausgeliefert.
Ihr Workbook trägt einen echten Prozess, und ein Großteil der Ratgeber im Netz erklärt, ein ernsthafter Betrieb müsse weg von Tabellen. Dieser Artikel benennt die drei Datenfehler, die einen Build tatsächlich rechtfertigen, gezogen aus realen webvise-Migrationen. Dazu kommt der Gegenfall: ein ausgeliefertes Projekt, in dem Excel bewusst im Einsatz blieb, und die Situationen, in denen ein Build der falsche Kauf ist.
- Drei Datenfehler rechtfertigen einen Build: Geschäftsregeln in Freitextfeldern, Dubletten, die niemand zusammenführen kann, und Statusspalten mit mehr als einer Bedeutung.
- Excel darf als Prüfoberfläche bleiben. Für das Bauunternehmen MP Bau schreibt ein webvise-KI-Tool Mengenermittlungen nach Excel, weil der Kalkulator dort jede Zeile prüft.
- Das qualifizierende Muster ist ein Team, das aus Tabellen, verstreuten Admin-Oberflächen oder Statusmeetings heraus arbeitet. Ein sorgfältiger Einzelbearbeiter mit wenig Volumen behält das Sheet.
- Das Budget ist eine eigene Frage. Der Kostenguide für individuelle Webanwendungen behandelt Preise; dieser Artikel behandelt die Entscheidung zwischen Bauen und Behalten.
Läuft einer Ihrer Kernprozesse über ein geteiltes Workbook, beginnt webvises Angebot für interne Tools und Dashboards mit genau dieser Diagnose: welchen der drei Fehler das Sheet zeigt und ob ein Build die Schwelle überhaupt erreicht.
Die drei Datenfehler, die einen Build rechtfertigen
Raster, Formeln und Filter halten erstaunlich lange durch. Zuerst scheitern die Daten darunter, und über webvise-Migrationen hinweg scheitern sie auf dieselben drei Arten.
Der erste Fehler sind Geschäftsregeln im Freitext. Eine Notizspalte voller Zeilen wie "immer netto 14 Tage" oder "vor Lieferung anrufen" enthält Logik, die keine Software sieht und kein neuer Kollege findet. In der Anwendung werden aus diesen Notizen echte Spalten, Zahlungsziel und Lieferhinweis als eigene Felder, mit Validierung, die ein Speichern bei Regelbruch blockiert.
Der zweite Fehler sind Dubletten. Derselbe Kunde steht dreimal im Sheet, in drei Schreibweisen, und jede Zeile trägt einen Teil der Wahrheit. Eine Tabelle zwingt niemanden zum Zusammenführen, deshalb macht oft erst die Datenbankmigration den Konflikt sichtbar. In realen webvise-Migrationen hat genau dieser Schritt Datensätze ans Licht gebracht, die nie jemand abgleichen musste.
Der dritte Fehler ist mehrdeutiger Status. In einer webvise-Migration wirkten zwei Statusspalten redundant, und beide erfassten am Ende Unterschiedliches, das nur die Person erklären konnte, die das Sheet gebaut hatte. Die neue Anwendung behielt beide Felder und dokumentierte beide Bedeutungen. Das war die gesamte Korrektur.
| Symptom im Sheet | Was dahintersteckt | Was die Web-App daraus macht |
|---|---|---|
| Notizspalte mit Regeln wie "immer netto 14 Tage" | Geschäftslogik im Freitext, unsichtbar für Software und neue Kollegen | Eigene Felder mit Validierung, die regelwidriges Speichern blockiert |
| Derselbe Kunde dreimal erfasst, drei Schreibweisen | Dubletten, zu deren Zusammenführung das Sheet nie zwingt | Ein Datensatz pro Kunde, ein Merge-Schritt, eine Dublettenwarnung bei der Eingabe |
| Zwei scheinbar redundante Statusspalten | Zwei verschiedene Bedeutungen, die nie jemand aufgeschrieben hat | Beide Felder bleiben, jedes mit dokumentierter Bedeutung und definierten Werten |
Das Projekt, das Excel bewusst behalten hat
MP Bau, ein deutsches Bauunternehmen, arbeitet mit einem von webvise gebauten KI-Tool, das Mengenermittlungen aus Bauplänen erstellt. Die Ausgabe ist eine Excel-Datei, und das ist eine bewusste Designentscheidung. Der Kalkulator prüft jede Zeile einer Mengenermittlung vor der Verwendung, und diese Prüfung findet in Excel statt.
Das Tool hat das Abtippen ersetzt. Die Prüfung blieb genau dort, wo sie war, in einem Raster, dem der Kalkulator vertraut und das er Zeile für Zeile durchgehen kann.
Das Prinzip lässt sich verallgemeinern: Die Prüfoberfläche des Menschen bleibt vertraut. Ein Ersatz verdient sein Geld, wenn Erfassung, Übergaben und Statusverfolgung in die Anwendung wandern. Das Format, in dem ein Mensch Ergebnisse prüft, darf eine Tabelle bleiben, denn eine neue Prüfoberfläche bringt Umlernrisiko mit und behebt keinen der drei Datenfehler.
Wann Sie nicht bauen sollten
webvise qualifiziert interne Tool-Projekte über ein Muster: ein Team, das aus Tabellen, verstreuten Admin-Oberflächen oder wiederkehrenden Statusmeetings zum Sheet heraus arbeitet. Fehlt das Team, fällt der größte Teil der Begründung für einen Build weg.
- Ein sorgfältiger Einzelbearbeiter. Ein Workbook, das eine einzige Person pflegt, hat keine Fehler aus gemeinsamem Arbeiten zu beheben, weil ein Kopf weiterhin den gesamten Kontext hält.
- Ad-hoc-Analysen und Einmalmodelle. Eine Quartalsprognose oder eine Schnellrechnung ist genau der Einsatzzweck von Excel, und ihr Nachbau als Software ist bezahlter Scope Creep.
- Keine Übergaben. Mehrdeutige Statusspalten schmerzen erst, wenn Zeilen zwischen Personen wandern. Ein Sheet, das nie den Besitzer wechselt, darf sein privates Vokabular behalten.
- Saubere Daten, hässliche Datei. Ein Workbook mit soliden Spalten, ohne Dubletten und mit einem Bearbeiter braucht eine Formatierungsrunde und null Code.
Greift das Muster doch, wird das Budget zum nächsten Filter. Der Kostenguide für individuelle Webanwendungen zeigt, was Builds dieser Form 2026 kosten und welche Treiber den Preis bewegen.
Was in die Anwendung wandert
Das Ziel, das webvise unter interne Tools und Dashboards verkauft, ist ein verlässliches System für den Betrieb, das Tabellen, Postfächer und verstreute Einzeltools als Arbeitsort ablöst. Konkret: Die Erfassung bekommt Validierung, Datensätze bekommen Verantwortliche, Status bekommt definierte Werte, und Berichte kommen aus dem System selbst, ohne Copy-Paste-Schritt.
Sobald Externe auf Daten im Sheet warten, ändert das Projekt seine Form und wird ein Portal mit eigenem Login und Rollen. Diese Variante, samt dem, was webvise darin ausgeliefert hat, behandelt der Guide zu Kundenportalen.
Zeigt ein geteiltes Workbook einen der drei Fehler, beschreiben Sie kurz, was das Sheet tut und wer es bearbeitet, und schicken Sie das über das Kontaktformular an webvise. Die Antwort ist eine ehrliche Einschätzung: welcher Fehler vorliegt, ob ein Build die Schwelle erreicht und was in Excel bleiben sollte.