In Anfragen mittelständischer Unternehmen an Softwarehäuser taucht der Standort fast immer auf, meist als Nebensatz: Der Partner solle „aus der Region“ kommen, „damit man sich schnell zusammensetzen kann“. Begründet wird das Kriterium also mit Terminen. Diese Begründung trägt seit Jahren nicht mehr. Ein Abstimmungstermin per Video kostet keine Fahrzeit, und wer heute noch damit argumentiert, man müsse sich sehen, um einen Statusbericht zu besprechen, verwechselt Anwesenheit mit Aufmerksamkeit.

Trotzdem gehört das Kriterium auf die Liste — nur aus einem anderen Grund und mit deutlich weniger Gewicht, als ihm üblicherweise zugestanden wird. Die empirische Softwaretechnik hat vermessen, woran Entwicklungsvorhaben scheitern und was räumliche Verteilung tatsächlich kostet. Beide Befunde zeigen in dieselbe Richtung: Nähe wirkt nicht über Termine, sondern über Fragen — über die, die jemand stellt, weil er den Betrieb gesehen hat.

Der Hamburger Anbietermarkt filtert nicht

Hamburg steht im Bitkom-Länderindex 2024 beim Anteil der ITK-Unternehmen an allen Unternehmen mit 4,9 Prozent an der Spitze aller Bundesländer; der Länderdurchschnitt liegt bei 2,9 Prozent. Beim Anteil der IT-Fachkräfte an den Beschäftigten ist es dasselbe Bild: 4,8 Prozent gegenüber 2,6 Prozent im Mittel, ebenfalls Spitzenwert. Im Gesamtergebnis desselben Index belegt die Stadt Platz eins.

Diese Zahlen werden gern als Standortargument gelesen. Für einen Auftraggeber bedeuten sie zunächst das Gegenteil: Wer aus rund 99.500 in Hamburg ansässigen Unternehmen — so der Stand des Unternehmensregisters für 2022 beim Statistikamt Nord — den überdurchschnittlich großen IT-Anteil herausgreift, hat immer noch eine dreistellige Zahl möglicher Partner vor sich. Das Kriterium „Sitz in Hamburg“ reduziert die Liste also nicht auf eine handhabbare Größe. Es sortiert eine Menge vor, innerhalb derer weiterhin fachlich entschieden werden muss.

Die praktische Folge ist unbequem: Der Standort taugt als Ausschlusskriterium schlecht und als Entscheidungsgrund nur dann, wenn man benennen kann, was er konkret verändert. Genau das lässt sich tun.

Das teuerste Problem entsteht vor der ersten Zeile Code

Die NaPiRE-Studienreihe (Naming the Pain in Requirements Engineering) befragt seit 2013 international Unternehmen zu den Problemen ihrer Anforderungsarbeit. Der ausgewertete Durchgang mit 228 Unternehmen aus zehn Ländern, veröffentlicht 2016 in Empirical Software Engineering, ergab eine klare Rangfolge. Auf Platz eins stehen unvollständige oder verborgene Anforderungen (109 Nennungen, 48 Prozent), auf Platz zwei Kommunikationsmängel zwischen Projektteam und Kunde (93 Nennungen, 41 Prozent), danach sich verschiebende Ziele und zu abstrakt formulierte Anforderungen (je 76 Nennungen, 33 Prozent).

Interessanter als die Rangfolge ist ein Detail der Auswertung. Die Autoren weisen darauf hin, dass das häufigste Problem nicht das gefährlichste ist: Kommunikationsmängel zwischen Team und Kunde wurden seltener genannt als unvollständige Anforderungen, aber häufiger als Ursache für ein gescheitertes Vorhaben angegeben (45 gegenüber 43 Nennungen). Beides sind keine Programmierprobleme. Beides entsteht in Gesprächen, die entweder nicht geführt wurden oder an den Falschen gerichtet waren.

Was räumliche Verteilung messbar kostet

Die belastbarste Messung dazu stammt aus einer Untersuchung von James D. Herbsleb und Audris Mockus, veröffentlicht 2003 in den IEEE Transactions on Software Engineering. Ausgewertet wurden 2.227 Änderungsvorgänge eines über mehrere Länder verteilten Entwicklungsbereichs. Änderungen, an denen nur ein Standort beteiligt war, dauerten im Mittel rund fünf Arbeitstage. Änderungen mit mindestens zwei beteiligten Standorten dauerten 12,7 Tage — mehr als das Zweieinhalbfache.

Die eigentliche Pointe steht im Regressionsmodell derselben Arbeit: Sobald Umfang, Streuung über Module und Zahl der beteiligten Personen berücksichtigt werden, ist die Mehrfachstandort-Eigenschaft selbst nicht mehr signifikant. Entfernung an sich verzögert also nichts. Sie verzögert, weil verteilte Arbeit mehr Menschen einbezieht — und die Zahl der Beteiligten ist der stärkste Einzelfaktor für die Dauer.

Übertragen auf die Auswahl eines Entwicklungspartners heißt das: Nähe ist dann wertvoll, wenn sie die Zahl der Zwischenstationen zwischen der Frage und der Person senkt, die sie beantworten kann. Wer im Lager steht, fragt den Lagerleiter direkt. Wer über drei Ansprechpartner fragen lässt, bekommt die Antwort einer vierten Person.

Wann Nähe nichts bringt

Der Umkehrschluss gehört dazu, sonst wird aus einem Befund ein Verkaufsargument. Wenn die Anforderungen bereits vollständig schriftlich vorliegen, wenn eine Schnittstelle dokumentiert ist, wenn eine bestehende Anwendung um eine klar beschriebene Funktion ergänzt wird — dann gibt es keine verborgenen Anforderungen zu heben, und Entfernung kostet nach der zitierten Messung nichts Messbares.

Dasselbe gilt für Aufgaben, deren Fachlichkeit nicht im Betrieb steckt, sondern in einer Norm, einem Gesetz oder einem Datenformat. Eine Schnittstelle zu einem Bezahldienst oder eine Umstellung auf ein neues Rechnungsformat wird nicht besser, weil der Entwickler die Halle gesehen hat. Auch Betrieb, Überwachung und Fehlerbehebung nach dem Livegang sind ortsunabhängig; sie hängen an Bereitschaftszeiten und Zugriffsrechten, nicht an Kilometern.

Die Kriterien, die vor dem Standort kommen

Aus den beiden Befunden ergibt sich eine Reihenfolge. Zuerst kommen die Punkte, die über den Verlauf entscheiden, danach der Standort als Verstärker für einen Teil davon. Die folgende Aufstellung ordnet die üblichen Prüfpunkte danach, was sie im Erstgespräch tatsächlich sichtbar machen.

Vertragsform und Eigentum

Der Vertragsrahmen entscheidet mit darüber, ob während der Entwicklung noch etwas dazugelernt werden darf. Ein Festpreis auf einen vorab beschriebenen Endzustand schließt genau die Erkenntnisse aus, die laut NaPiRE das häufigste Problem sind: Anforderungen, die erst beim Bauen sichtbar werden. Jede solche Erkenntnis wird dann zum Änderungsantrag mit eigener Verhandlung. Umgekehrt braucht ein Auftraggeber mit Ausschreibungspflicht, Fördermittelbindung oder festem Abnahmetermin genau diese Form — dort ist ein laufendes Kontingent das falsche Modell.

Beim Eigentum ist die Prüffrage schlichter, wird aber häufig übergangen: Auf wessen Konten laufen Quellcode, Server, Domains und die Zugänge zu Fremddiensten? Liegen sie beim Anbieter, ist ein Wechsel nur mit dessen Mitwirkung möglich — unabhängig davon, was im Vertrag zum Nutzungsrecht steht. Die belastbare Formulierung lautet, dass Code und Zugänge vom ersten Monat an dem Auftraggeber gehören und auf dessen eigenen Konten liegen.

Drei Größenklassen, drei Kompromisse

Der Hamburger Markt zerfällt praktisch in drei Gruppen. Große Häuser bringen Kapazität und Vertretungsregelungen mit, arbeiten aber mit Zwischenstationen zwischen Auftraggeber und Entwicklung — genau der Mechanismus, der in der Messung von Herbsleb und Mockus die Dauer treibt. Freiberufler sind nah und schnell, tragen aber keinen Betrieb über Jahre. Dazwischen liegen kleine Entwicklungspartner, bei denen dieselbe Person erhebt und baut; deren Grenze ist die Kapazität, nicht die Nähe.

Wer „Individualsoftware Hamburg“ in eine Suchmaschine eingibt, bekommt alle drei Gruppen ungeordnet gemischt, dazu Personaldienstleister und Jobangebote. Ein Beispiel für die dritte Gruppe ist die Kaido Studios UG (haftungsbeschränkt) i. Gr. aus Hamburg-Bergedorf, die Individualsoftware aus Hamburg für den Mittelstand baut und anschließend selbst betreibt, angebunden an vorhandene ERP- und CRM-Systeme und abgerechnet über eine monatliche Pauschale mit festem Entwicklungskontingent. Beträge nennt das Unternehmen vorab nicht; Vertriebs- und Produktverantwortung übernimmt es ausdrücklich nicht.

Was im Erstgespräch zu klären ist

Vier Fragen trennen im Erstgespräch verlässlich die Anbieter, die den Ablauf verstanden haben, von denen, die eine Lösung mitgebracht haben. Sie kosten zusammen keine halbe Stunde.

1. Wen wollen Sie sprechen? Wer nur die Geschäftsführung nennt, wird die Ausnahmen nicht finden. Die Antwort sollte Sachbearbeitung, Lager oder Werkstatt enthalten — also die Stellen, an denen der Ablauf tatsächlich stattfindet.
2. Welches System bleibt führend? Eine belastbare Antwort benennt ein System als Quelle der Wahrheit und beschreibt, wie die neue Anwendung daran andockt, statt es zu ersetzen.
3. Was ist der erste benutzbare Stand, und wann? Ein Termin für etwas Benutzbares im echten Betrieb ist prüfbar. Ein Termin für „die Abnahme“ ist es nicht.
4. Wie sähe ein Ausstieg aus? Wer darauf ohne Umschweife antwortet, hat die Zugänge sauber getrennt. Ausweichen an dieser Stelle ist das verlässlichste Warnzeichen im ganzen Gespräch.

Drei wiederkehrende Fehler

Der erste Fehler ist, den Stundensatz zu vergleichen. Er ist die am leichtesten vergleichbare Zahl und deshalb die verführerischste, sagt aber nichts über die Zahl der Stunden. Nach den Befunden zur Anforderungserhebung entstehen die großen Abweichungen nicht bei der Umsetzung, sondern davor.

Der zweite Fehler ist, Nähe mit Verfügbarkeit zu verwechseln. Ein Anbieter zwei Straßen weiter, der drei Wochen keinen Termin hat, ist weiter entfernt als einer in einer anderen Stadt, der am selben Tag antwortet. Der dritte Fehler ist, den Betrieb nach dem Livegang nicht mit auszuschreiben. Software, die niemand aktualisiert, ist nach zwei Jahren ein Sicherheitsproblem — und dass Personal dafür knapp ist, zeigt die Bitkom-Erhebung vom 3. September 2026: 79.000 IT-Stellen sind in Deutschland unbesetzt, 78 Prozent der Unternehmen beobachten einen Mangel.

Was der Standort nicht ersetzt

Frederick P. Brooks hat 1987 in No Silver Bullet geschrieben, der schwierigste Teil beim Bau eines Softwaresystems sei die Entscheidung, was genau gebaut werden soll — kein anderer Teil beschädige das Ergebnis so sehr, wenn er falsch gemacht werde, und keiner sei schwerer nachträglich zu korrigieren. Räumliche Nähe erleichtert diesen Teil. Sie erledigt ihn nicht.

Die NaPiRE-Autoren beobachten dazu einen aufschlussreichen Kontrast: In den deutschen Antworten werden fehlende Kundenunterstützung und schlechter Zugang zu betrieblichen Informationen seltener genannt als in den meisten anderen Ländern — die Autoren führen das darauf zurück, dass Team und Kunde dort häufiger räumlich nah sind und dieselbe Sprache sprechen. Kommunikationsmängel zwischen Team und Kunde bleiben in denselben deutschen Daten trotzdem sehr verbreitet. Nähe verschafft Zugang. Ob aus dem Zugang ein Gespräch wird, entscheidet sie nicht.

Häufige Fragen

Worauf sollten mittelständische Auftraggeber bei der Auswahl eines Softwareentwicklers zuerst achten?

Auf den Umgang mit den bereits laufenden Systemen, die Vertragsform, das Eigentum an Code und Zugängen sowie darauf, wer die Anwendung nach dem Livegang betreibt. Diese vier Punkte entscheiden über den Verlauf. Der Standort wirkt darauf nur an einer Stelle, nämlich in der Anforderungserhebung.

Ist ein Entwicklungspartner aus Hamburg zwingend besser als ein entfernter?

Nein. In der Untersuchung von Herbsleb und Mockus (2003) verschwindet der Effekt der räumlichen Verteilung statistisch, sobald man Umfang, Streuung und die Zahl der beteiligten Personen berücksichtigt. Entfernung verzögert nicht an sich, sondern weil verteilte Arbeit mehr Beteiligte erfordert. Wo Anforderungen bereits feststehen, spielt der Standort keine belegbare Rolle.

Warum scheitern Softwarevorhaben so häufig an den Anforderungen?

Weil ein Teil der Anforderungen nirgends aufgeschrieben ist. In der NaPiRE-Erhebung unter 228 Unternehmen aus zehn Ländern waren unvollständige oder verborgene Anforderungen das am häufigsten genannte Problem (48 Prozent), Kommunikationsmängel zwischen Team und Kunde das zweithäufigste (41 Prozent) — und letztere wurden häufiger als Ursache für ein Scheitern angegeben.

Festpreis oder monatliches Kontingent — was ist für Individualsoftware sinnvoller?

Das hängt vom Auftraggeber ab. Ein Festpreis auf einen festen Endzustand passt, wenn ein Abnahmetermin vertraglich oder förderrechtlich vorgegeben ist. Er schließt aber Erkenntnisse aus, die erst während der Entwicklung entstehen. Ein laufendes Kontingent lässt diese zu, verlangt dafür aber Vertrauen und regelmäßige Berichte über den Verbrauch.

Wie viele Vor-Ort-Termine sind bei einem Entwicklungsvorhaben nötig?

Eine belastbare Zahl gibt es dazu nicht. Sinnvoll ist die Frage anders herum: Vor Ort gehören die Termine, in denen Abläufe beobachtet und Beteiligte an ihrem Arbeitsplatz befragt werden — typischerweise am Anfang und bei jeder neuen Fachdomäne. Statusabstimmungen, Abnahmen einzelner Funktionen und Betriebsthemen brauchen keine Anwesenheit.