Software, die Ihren Prozess abbildet – und die Sie behalten

Der teuerste Fehler in Softwareprojekten ist eine Anforderung, die niemand hinterfragt hat. Wir beginnen deshalb immer mit einer Analysephase: Wir begleiten die betroffenen Mitarbeitenden am Arbeitsplatz, lassen uns den Ablauf zeigen statt beschreiben und dokumentieren, wo Zeit verloren geht, wo Daten mehrfach erfasst werden und wo Fehler entstehen.

Dabei stellt sich regelmäßig heraus, dass ein Teil der gewünschten Funktionen aus einer historischen Einschränkung stammt, die es gar nicht mehr gibt. Diese Punkte streichen wir gemeinsam, bevor sie Entwicklungsaufwand erzeugen.

Das Ergebnis ist ein Konzept mit Prozessbeschreibung, Datenmodell im Entwurf, Schnittstellenübersicht, Aufwandsschätzung in Spannen und einer Priorisierung nach Nutzen. Diese Analyse ist ein abgeschlossenes Beratungsergebnis – Sie können damit auch zu einem anderen Anbieter gehen.

Eigenentwicklung ist kein Selbstzweck. Sie lohnt sich dort, wo Ihr Prozess ein Wettbewerbsvorteil ist und Standardsoftware ihn nur unter Verlusten abbilden könnte – oder wo die Anpassung eines Standardprodukts über Jahre teurer wird als eine schlanke Eigenentwicklung.

Gegen Individualsoftware spricht dagegen fast immer, wenn es um regulierte Kernbereiche mit ständigen gesetzlichen Änderungen geht. Buchhaltung, Lohnabrechnung und Kassensysteme sollten Sie nicht selbst bauen lassen; die Pflege der Vorschriften allein übersteigt den Nutzen bei Weitem.

Häufig ist die beste Antwort weder das eine noch das andere: Ein Standardsystem bleibt als Datenhaltung bestehen, und wir entwickeln nur die fehlenden Teile – eine Schnittstelle, eine Erfassungsoberfläche, eine Auswertung. Das reduziert Aufwand und Risiko erheblich.

In fast jedem mittelständischen Unternehmen gibt es sie: die zentrale Tabelle für Kalkulation, Disposition, Projektübersicht oder Bestandsführung. Sie ist über Jahre gewachsen, enthält Makros, die niemand mehr nachvollzieht, existiert in mehreren Versionen und blockiert beim gleichzeitigen Zugriff. Sie ist gleichzeitig geschäftskritisch und unversichert.

Wir lösen solche Konstruktionen nicht durch Verbieten ab, sondern durch Nachbauen. Zuerst analysieren wir die Tabelle vollständig, einschließlich der Formeln und Sonderfälle, die sich niemand gemerkt hat. Daraus entsteht ein sauberes Datenmodell mit Beziehungen, Pflichtfeldern und Plausibilitätsprüfungen.

Die neue Anwendung bietet dann das, was die Tabelle nie konnte: gleichzeitigen Zugriff mehrerer Personen, Rechteverwaltung, Änderungshistorie mit Nachvollziehbarkeit, automatische Sicherung und verlässliche Auswertungen. Den vertrauten Ablauf behalten wir dabei bewusst bei, damit die Einführung nicht am Widerstand der Anwender scheitert.

Ein großer Teil unserer Entwicklungsarbeit besteht nicht aus neuen Anwendungen, sondern aus Verbindungen zwischen bestehenden. Warenwirtschaft und Onlineshop, Zeiterfassung und Lohnvorbereitung, CRM und Buchhaltung, Maschinendaten und Auswertung – überall dort, wo heute exportiert, umformatiert und wieder importiert wird, lässt sich Zeit und Fehlerquote deutlich reduzieren.

Wir entwickeln dafür REST-APIs, nutzen vorhandene Herstellerschnittstellen und bauen Verarbeitungsstrecken, die geplant laufen, Fehler protokollieren und im Störungsfall alarmieren. Wichtig ist dabei die Nachvollziehbarkeit: Jede Übertragung muss im Nachhinein prüfbar sein, sonst entsteht ein neues Vertrauensproblem an anderer Stelle.

Wo keine Schnittstelle existiert, prüfen wir den direkten Datenbankzugriff oder eine dateibasierte Strecke. Das ist weniger elegant, aber oft die einzige praktikable Lösung bei älteren Fachanwendungen – und mit sauberer Fehlerbehandlung durchaus stabil zu betreiben.

Wir arbeiten überwiegend mit .NET und C# im Backend, TypeScript im Frontend und Python für Datenverarbeitung und Automatisierung. Als Datenbanken kommen PostgreSQL oder Microsoft SQL Server zum Einsatz. Die Auswahl richtet sich nach Ihrer bestehenden Landschaft – eine Anwendung, die niemand in Ihrem Umfeld betreuen kann, ist keine gute Lösung, egal wie modern der Technologiestapel ist.

Das Vorgehen ist iterativ. Alle zwei bis drei Wochen erhalten Sie eine lauffähige Version zum Ausprobieren. Das kostet in der Summe etwas mehr Abstimmung, verhindert aber den klassischen Projektverlauf, bei dem nach acht Monaten etwas übergeben wird, das am Bedarf vorbeigeht.

Abgerechnet wird bei überschaubarem, klar umrissenem Umfang zum Festpreis, sonst nach Aufwand mit vereinbarter Obergrenze und monatlicher Transparenz über den Stand. Welches Modell passt, entscheiden wir nach der Analysephase gemeinsam – vorher wäre jede Festpreiszusage eine Schätzung mit Risikoaufschlag, den Sie bezahlen.

Software wird länger gepflegt als entwickelt. Deshalb entscheidet die Wartbarkeit über die Gesamtkosten weit stärker als der Aufwand der ersten Version. Wir schreiben Code, der auch in fünf Jahren noch von einem fremden Entwickler gelesen werden kann: klare Struktur, sprechende Bezeichnungen, keine überflüssige Abstraktion, keine exotischen Bibliotheken ohne guten Grund.

Automatisierte Tests decken die fachlich kritischen Berechnungen und Abläufe ab. Sie ersetzen keine Abnahme, verhindern aber, dass eine spätere Änderung unbemerkt etwas zerstört, das seit Jahren funktioniert.

Für den Betrieb richten wir Bereitstellungsprozesse ein, die reproduzierbar sind, sowie Protokollierung und Überwachung, damit Störungen auffallen, bevor Anwender sie melden. Ob die Anwendung bei Ihnen lokal oder in einer Cloud-Umgebung läuft, entscheiden wir nach Datenlage und Anforderung.

Individualsoftware ist nur dann eine Investition, wenn sie Ihnen gehört. Quellcode, Repository-Historie, Datenbankschema und Dokumentation gehen vollständig in Ihr Eigentum über – nicht als Kopie am Projektende, sondern durchgehend während der Entwicklung in einem Repository, auf das Sie Zugriff haben.

Zur Übergabe gehört mehr als der Code selbst: Eine technische Dokumentation mit Architekturübersicht, Datenmodell und Schnittstellenbeschreibung, eine Anleitung zum Aufsetzen der Entwicklungsumgebung, die Bereitstellungsprozesse und eine Anwenderdokumentation. Damit kann ein anderer Entwickler oder ein interner Mitarbeitender die Arbeit fortsetzen.

Wir betrachten das nicht als Risiko für uns, sondern als Voraussetzung für eine ehrliche Zusammenarbeit. Wer nur deshalb Kunde bleibt, weil ein Wechsel technisch unmöglich gemacht wurde, ist kein zufriedener Kunde.