Hinweis: Dieser Beitrag ist eine grundlegend überarbeitete Fassung des älteren Artikels „Software mit Sinn?“ vom 22. Januar 2017. Übernommen wurde der Kern: Software ist ein Werkzeug. Neu geschrieben wurde der Beitrag für die heutige Arbeit an internen Tools, MVPs und AI-Workflows.
Software ist kein Selbstzweck. Sie ist auch kein Beweis dafür, dass ein Unternehmen modern ist. Gute Software löst eine konkrete Aufgabe besser als der bisherige Weg.
Das klingt einfach. In Projekten wird es trotzdem schnell vergessen. Dann wird über Frameworks, Plattformen, AI-Modelle, Dashboards oder Integrationen gesprochen, bevor klar ist, welche Arbeit eigentlich leichter, sicherer oder schneller werden soll.
Die bessere erste Frage lautet nicht: „Welche Software bauen wir?“
Sie lautet: „Welche Aufgabe ist wichtig genug, dass sich bessere Software dafür lohnt?“
Gute Software beginnt beim Engpass
In vielen Unternehmen sind die besten Hinweise auf sinnvolle Softwareprojekte längst sichtbar:
- Excel-Listen werden mehrfach kopiert.
- Freigaben laufen über E-Mail-Ketten.
- Kunden- oder Partnerdaten liegen in mehreren Systemen.
- Reporting kostet jede Woche manuelle Arbeit.
- Fachwissen steckt in einzelnen Köpfen.
- Mitarbeiter prüfen immer wieder dieselben Fälle.
- Bestehende Systeme können etwas fast, aber nicht richtig.
Das sind keine bloßen Unsauberkeiten. Es sind Hinweise auf relevante Arbeit. Ein gutes internes Tool, ein kleiner Workflow oder eine passende AI-Unterstützung kann dort viel Wert erzeugen, wenn der Engpass klar genug verstanden ist.
Nicht jedes Problem braucht individuelle Software
Individuelle Software ist nicht automatisch die beste Antwort. Manchmal reicht ein besserer Prozess. Manchmal ist Standardsoftware sinnvoller. Manchmal ist eine kleine Automatisierung besser als eine neue Plattform.
Deshalb sollte vor der Umsetzung geklärt werden:
- Ist der Prozess wiederkehrend und wichtig?
- Sind Fehler teuer oder riskant?
- Betrifft das Problem mehrere Personen oder Teams?
- Gibt es eine Standardlösung, die gut genug passt?
- Entsteht durch Workarounds dauerhaft Aufwand?
- Wird die Lösung betrieben, gepflegt und fachlich verantwortet?
Wenn diese Fragen nicht beantwortet sind, wird Software schnell zu zusätzlicher Komplexität. Dann ersetzt sie kein Problem, sondern schafft ein weiteres.
Kleine Lösungen sind gut, wenn sie das Richtige treffen
Ein MVP ist nicht deshalb gut, weil er klein ist. Er ist gut, wenn er eine zentrale Annahme prüft oder einen echten Engpass löst.
Bei internen Tools kann das ein einziger sauberer Import sein. Bei AI-Workflows kann es eine überprüfbare Zusammenfassung aus freigegebenen Quellen sein. Bei einer Webanwendung kann es ein kleiner Freigabeprozess sein, der E-Mail-Pingpong ersetzt.
Entscheidend ist nicht, ob die Lösung beeindruckend wirkt. Entscheidend ist, ob sie Arbeit verbessert und eine gute nächste Entscheidung ermöglicht.
AI ändert die Frage nicht
AI macht Prototyping schneller und eröffnet neue Möglichkeiten. Sie ändert aber nicht die Grundregel: Erst die Arbeit verstehen, dann das Werkzeug wählen.
Ein Sprachmodell hilft wenig, wenn Daten unklar, Rechte ungeklärt oder Qualitätskriterien nicht definiert sind. Ein AI-Assistent ist kein Produktivitätsgewinn, wenn Menschen seine Ergebnisse nicht prüfen können. Ein automatisierter Workflow wird gefährlich, wenn niemand weiß, wo menschliche Kontrolle nötig ist.
Gute AI-Projekte beginnen deshalb ebenfalls beim konkreten Arbeitsprozess. Das Modell kommt später.
Woran man gute Software erkennt
Gute Software muss nicht groß sein. Sie muss passen.
Sie macht einen wichtigen Ablauf verlässlicher. Sie reduziert doppelte Arbeit. Sie macht Daten auffindbar. Sie verhindert Fehler an den richtigen Stellen. Sie lässt sich betreiben, ändern und erklären. Und sie bleibt verständlich genug, dass das Unternehmen nicht von einem einzelnen Entwickler oder Anbieter abhängig wird.
Das ist weniger glamourös als ein großes Digitalisierungsprogramm. Es ist aber oft der Unterschied zwischen Software, die benutzt wird, und Software, die nur existiert.
Fazit
Software lohnt sich, wenn sie konkrete Arbeit verbessert. Nicht, weil sie neu ist. Nicht, weil sie technisch interessant ist. Nicht, weil ein Trend gerade Druck erzeugt.
Wer gute Software bauen will, beginnt mit dem Engpass, prüft die Alternativen und baut dann den kleinsten tragfähigen Schritt. Alles andere ist Werkzeug ohne Aufgabe.